# Gemini 3.5 Flash와 3.1 Pro — 어떤 작업에 무엇을 쓸까 AI 도구 활용 · 2026년 6월 긴 문맥 창, Gems, 프롬프트 구조를 중심으로 두 모델의 실질적인 차이를 정리한다. --- AI 도구가 워낙 빠르게 나오다 보니 무엇을 어떻게 써야 하는지 파악하기도 전에 새 버전이 또 나와 있는 경우가 많다. Gemini도 그렇다. 3.5 Flash와 3.1 Pro가 나왔는데 이름만 봐서는 어떤 작업에 무엇을 쓰는 게 맞는지 감이 잘 안 온다. 두 모델을 직접 써보고 기술 문서와 벤치마크 자료를 함께 검토하며 정리한 내용이다. --- - G - Goal. 동사 중심으로 구체적으로 정의한다. "이 데이터를 분석해줘"보다 "첨부된 10종의 기술 백서를 바탕으로 모델 간 아키텍처 차이를 도출해줘"가 훨씬 낫다. ### 1. 긴 문맥 창이 실무를 바꾸는 방식 --- 기존 AI를 쓸 때 가장 자주 부딪히는 벽이 컨텍스트 길이였다. 분량이 긴 문서를 분석하려면 구간을 나눠 붙여넣고 결과를 다시 취합하는 과정을 반복해야 했다. 문서 간 맥락이 끊기는 건 피할 수 없었다. Gemini 3 시리즈는 기본 100만 토큰을, 연구 환경 기준으로는 최대 1,000만 토큰을 단일 입력으로 받는다. 100만 토큰은 대략 75만 단어다. 일반 소설 10권 분량이나 3~5만 줄의 소스 코드에 해당하며, 1시간짜리 고해상도 영상도 단일 프롬프트에서 처리 가능한 수준이다. 단순히 처리 분량이 늘어난 것만이 아니다. NIAH(Needle-In-A-Haystack) 테스트에서 텍스트뿐 아니라 10.5시간 분량의 영상(약 990만 토큰)과 107시간 분량의 오디오(약 970만 토큰)에서도 99% 이상의 정보 회수 정확도를 기록했다. 방대한 데이터를 통째로 올려도 필요한 부분을 정확히 찾아낸다는 의미다. 실무 관점에서 이게 바꾸는 건 전처리 방식이다. 기존 RAG(Retrieval-Augmented Generation) 시스템에서는 문서를 수백 토큰 단위 청크로 잘라 벡터 데이터베이스에 저장하는 과정이 필수였다. 청크 간 논리적 연결이 끊기는 건 구조적 한계였다. 긴 문맥 창을 활용하면 여러 PDF 원본을 그대로 올려 교차 분석을 즉시 수행할 수 있다. 벡터 임베딩이나 별도 전처리 없이. > **현장 메모.** 여러 분기별 보고서를 동시에 올려 종합 분석을 요청할 때 체감 차이가 크다. 이전이라면 문서마다 따로 분석하고 결과를 직접 엮어야 했지만, 원본을 그대로 던져줄 수 있으면 모델이 문서 간 상충 수치를 스스로 비교하고 맥락까지 짚어낸다. ### 2. Gems — 반복 설정을 저장해두는 방법 --- AI를 업무에 붙여두면 매번 같은 배경 설명을 반복하게 된다. 어떤 일을 하는지, 어조는 어떻게 해달라는지, 출력 형식은 어떻게 해달라는지. Gems는 이 설정을 저장해두는 커스텀 AI 에이전트다. 단순 설정 저장을 넘어, 사내 문서나 가이드라인을 지식 베이스로 주입해두면 해당 기준을 따라 작동하는 전문화된 에이전트를 만들 수 있다. 시스템 지시어를 설계할 때 효과가 있는 방식은 네 범주를 명확히 구분하는 것이다. | PERSONA 역할과 전문성을 설정한다. _"15년 차 시니어 데이터 과학자"_ | TASK 수행할 미션과 행동 방식을 서술한다. _요청 유형별 출력 패턴 정의_ | | --- | --- | | Context 최대 10개 파일을 직접 주입한다. 사내 규정집, 브랜드 가이드라인, 표준 계약서 양식을 넣으면 AI가 그 기준을 강제로 따른다. | Format 출력 규격을 제한한다. _Markdown 표 / JSON / 고정 문서 양식_ | 2026년 업데이트된 Memory(Saved Info) 기능은 여기서 한 걸음 더 나아간다. 사용자의 선호도, 직무 환경, 과거 피드백을 장기 기억으로 보존해 매 세션마다 동일한 배경 정보를 반복 입력하는 번거로움이 사라진다. Google Workspace와 통합된 경우 Gmail, Drive, Docs에 흩어진 데이터를 교차 추론(Cross-App Reasoning)하는 것도 가능하다. 다만 Workspace 기업용 계정에서 처리되는 이메일과 드라이브 문서는 모델의 글로벌 학습 데이터로 활용되지 않도록 가드레일이 적용된다는 점은 엔터프라이즈 환경에서 사전에 확인해둘 필요가 있다. ### 3. 프롬프트 구조가 결과 품질을 결정한다 --- 모델이 아무리 복잡한 추론을 잘한다고 해도 프롬프트가 모호하면 결과도 모호해진다. 반대로 구조화된 프롬프트는 모델이 낼 수 있는 성능을 실질적으로 끌어올린다. 엔터프라이즈 환경에서 검증된 GRWC 프레임워크는 네 단계로 구성된다. - W - Warnings. 부정적 제약 조건을 명시한다. "제공된 소스에 없는 수치는 추측하지 말고 '정보 없음'으로 표기할 것", "각 주장에 출처 파일명과 페이지 번호를 인용할 것" 등이 환각을 억제하는 데 효과적이다. - C - Context Dump. 원본 파일을 가감 없이 올린다. 여러 문서를 비교 분석하는 경우, 지시 사항을 입력의 최상단에 두고 각 파일에 `[Paper 1]`, `[Paper 2]` 같은 텍스트 태그를 붙이면 모델의 주의력이 분산되는 걸 줄일 수 있다. - R - Result Format. 출력 규격을 명시적으로 지정한다. Markdown 표, 단계별 실행 계획, 기계가 판독 가능한 JSON 형식 등으로 후속 시스템에 바로 연동될 수 있게 한다. API 레벨에서 함께 챙길 파라미터가 하나 있다. 기존의 `thinkingBudget` 토큰 할당 방식이 폐지되고 `thinkingLevel`이 `minimal`, `low`, `medium`, `high` 네 단계로 단순화됐다. 3.5 Flash는 `medium`이 기본으로 설정되어 있다. 수학적 검증이나 논리적 모순을 찾아야 하는 작업에는 high를 명시적으로 설정해야 내부 사고 토큰 생성과 자가 검증 과정을 충분히 활용할 수 있다. > 참고. 다단계 과업은 하나의 거대한 프롬프트보다 단계를 명시적으로 쪼개는 편이 낫다. "Step 1: 문서에서 핵심 KPI를 추출한다 → Step 2: 전년 대비 하락 원인을 분석한다 → Step 3: 3가지 실행 조언을 도출한다"처럼 구조를 프롬프트 안에 직접 서술하면 모델이 각 단계 결과를 스스로 검증하며 넘어간다. ### 4. Flash와 Pro, 어느 걸 어떤 작업에 --- 두 모델을 나누는 기준은 단순히 빠른 것 vs 정확한 것이 아니다. 처리 방식의 우선순위가 다르다. 3.5 Flash는 초당 약 289 토큰을 생성한다. 유사 모델 대비 약 4배 속도다. 최대 65,536개 출력 토큰을 지원하며, 동적 사고(Dynamic Thinking) 기능이 medium 레벨로 기본 탑재되어 속도와 추론 품질 사이의 균형점에서 작동한다. 대규모 트래픽 처리, 고객 응대 자동화, 긴 코드 마이그레이션처럼 속도와 비용 효율이 핵심인 워크플로우에 적합하다. 3.1 Pro는 초당 60~90 토큰으로 느리고 API 비용도 높다. 대신 Deep Think 모드에서 수만 개의 사고 토큰을 내부적으로 생성해 치열한 자가 검증을 수행한다. ARC-AGI-2 벤치마크에서 77.1%, HLE에서 검색 기능 결합 시 51.4%를 기록했다. 계약서 독소조항 분석, 복잡한 재무 모델링, M&A 실사 보고서 교차 분석처럼 논리적 무결성이 요구되는 작업에는 Pro를 쓰는 편이 맞다. | 항목 | Gemini 3.5 Flash | Gemini 3.1 Pro | | --- | --- | --- | | 최대 입/출력 토큰 | 1,048,576 / 65,536 | 1,048,576 / 65,536 | | 기본 thinkingLevel | medium | high (Deep Think) | | 생성 속도 | ~289 토큰/초 | 60~90 토큰/초 | | API 비용 (입력/출력, 1M당) | $1.50 / $9.00 | $2.00 / $12.00 | | HLE 정확도 (도구 미사용) | 41.0% | 44.4% | | ARC-AGI-2 정확도 | - | 77.1% | | 적합한 워크플로우 | `대규모 CS 자동화` `코드 마이그레이션` `RAG 캐싱` | `계약서 검토` `재무 모델링` `M&A 실사` | 단일 모델에 모든 작업을 몰아주기보다는 작업 성격에 따라 라우팅하는 하이브리드 전략이 현실적이다. 분류하고 요약하는 반복 파이프라인은 Flash에, 깊은 논리 검증이 필요한 최종 판단은 Pro에 맡기는 식이다. ### 마무리 - 기술보다 오래가는 건 다루는 방법이다 --- 두 모델의 차이가 속도와 정확도의 단순한 트레이드오프라기보다는, 어떤 컨텍스트를 어떤 깊이로 다루느냐의 문제라는 게 실제로 써보면 느껴진다. 긴 문맥 창이 제공되어도 결국 어떤 데이터를 올리고 어떤 제약 조건을 걸어두느냐가 결과의 품질을 가른다. 기술 인프라는 빠르게 따라잡을 수 있지만, 그걸 다루는 프레임워크—어떤 데이터를 어떤 맥락에 묶어 모델에게 던지느냐—는 쌓아가는 데 시간이 걸린다. Gems에 어떤 지식 베이스를 주입하고 GRWC 구조를 어떻게 정제하는지가, 동일한 모델을 쓰면서도 결과물 품질을 가르는 지점이 된다. --- Gemini 3 시리즈 기술 문서 및 벤치마크: Google AI for Developers, Google DeepMind Model Cards, OpenRouter API Benchmarks (2026년 6월 기준) For the site tree, see the [root Markdown](https://slashpage.com/blogger.md).