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월 기준)
