Gemini 3.5 Pro 200만 토큰, 통짜 입력 vs RAG

200만 토큰 컨텍스트, 처음으로 “통째로 넣기"가 진짜 선택지가 되다

지금까지 “AI에게 대량의 문서를 먹여야 한다"는 이야기가 나오면 답은 거의 항상 하나였다. 먼저 RAG(검색 증강 생성)를 구축하는 것이다. 모델이 한 번에 읽을 수 있는 내용에는 한계가 있으니, 문서를 미리 조각내고 인덱스를 만든 다음, 질문할 때마다 가장 관련성 높은 몇 조각만 골라 넣어야 했다.

이 전제가 흔들리고 있다. 시장에 흘러나온 소식에 따르면, 새로 개발된 Gemini 3.5 Pro는 200만 토큰의 컨텍스트 창을 탑재할 예정이며, 단일 작업 세션에서 대폭 확장된 텍스트, 코드, 데이터를 처리할 수 있다고 한다 [Source: https://www.inside.com.tw/article/41814-gemini-3-5-pro-rumors-roundup]. 이게 어느 정도냐면, 대략 환산했을 때 200만 토큰은 여러 권의 책 분량에 해당한다. 1인 기업이나 프리랜서에게는 “RAG를 구축하지 않고 데이터 전체를 통째로 붙여넣어 질문하는 것"이 처음으로 실제로 실현 가능한 선택지가 된 것이다.

문제는 이것이다. 통째로 넣는 것이 정말로 더 정확하고 더 간편할까? 아니면 RAG라는 작업을 여전히 해야 할까? 아래에서 세 가지 기준으로 나눠서 살펴보고, 마지막에는 이미 RAG를 구축해 본 사람들을 위한 고급 선택 팁도 준비했다. 기술적 세부 사항을 전혀 접해보지 않았다면 결정표까지만 읽어도 충분하니, 고급 부분은 편하게 건너뛰어도 된다.

통째로 넣기 vs RAG 구축, 쉽게 설명하면

먼저 두 가지 방법을 명확히 짚어보자.

• 통째로 넣기: 손에 있는 계약서, 제품 문서, 회의록 등을 전부 대화창에 붙여넣고 바로 질문하는 방식. 조각낼 필요도, 인덱스를 만들 필요도 없이 바로 쓸 수 있다.
• RAG 구축: 문서를 먼저 검색 가능한 데이터베이스로 처리해두고, 질문할 때마다 시스템이 자동으로 가장 관련성 높은 조각을 골라내 모델에 그 부분만 먹이는 방식.

직관적으로는 통째로 넣기가 “게으른 사람 친화적"이라는 점에서 이기고, RAG는 “정확하고 저렴하다"는 점에서 이긴다. 하지만 실제로는 그렇게 단순하지 않으며, 핵심은 정확도, 지연 시간, 비용 세 가지 기준에 있다.

세 가지 비교: 정확도, 지연 시간, 비용

정확도: 길다고 정확한 것은 아니다

컨텍스트가 200만 토큰을 담을 수 있다고 해서 모델이 모든 구석까지 똑같이 집중한다는 뜻은 아니다. 롱 컨텍스트에는 흔히 간과되는 위험이 있다. 내용이 길수록 모델이 중간에 끼어 있는 세부 사항을 놓치기 쉽다는 점이다. 분명 질문하려는 내용을 붙여넣었는데도 모호하게 답하거나 아예 답을 빠뜨리는 경우가 생긴다. 이것이 바로 실무에서 고빈도, 정밀 적중이 필요한 검색 시나리오에서 여전히 캐싱과 함께 RAG를 사용하는 것을 선호하고, 무작정 컨텍스트 전체에 밀어 넣지 않는 이유다. 같은 가이드에서도 RAG로 회수한 조각의 형태가 매우 다양하다는 점을 지적하는데, 이것이 롱 컨텍스트의 품질을 일률적으로 판단하기 어려운 이유 중 하나다 [Source: https://www.nxcode.io/resources/news/gemini-3-5-flash-vs-3-1-pro-when-to-use-which-2026].

또 하나 간과하기 쉬운 신호가 있다. 이번 3.5 Pro가 기존 기반 모델을 버리고 재사전학습을 한 이유에 대해, 외신이 인용한 바로는 기존 아키텍처가 다단계 수학 추론과 SVG 장면 생성에서 성능 한계에 부딪혔기 때문이라고 한다 [Source: https://www.inside.com.tw/article/41814-gemini-3-5-pro-rumors-roundup]. 즉, 컨텍스트를 100만에서 200만으로 늘린 것은 “담을 수 있는 양"을 보완한 것이지, 반드시 “추론이 더 정확해진 것"을 의미하지는 않는다. 다단계 추론이 필요한 검색 질의응답에는 길이가 만능 해결책이 아니다.

한마디로 정리하면, 문서량이 적고 질문이 명확할 때는 통째로 넣기만으로도 충분히 정확하다. 문서가 복잡하고 많으며 특정 조항이나 숫자를 반복적으로 정확히 찾아야 할 때는 RAG의 적중률이 보통 더 안정적이다.

지연 시간: 매번 전체를 다시 읽으니 기다림이 체감된다

통째로 넣기의 대가 중 하나는 속도다. 질문할 때마다 모델은 원칙적으로 전체 내용을 다시 “읽어야” 한다. 문서가 클수록 응답 전 대기 시간이 눈에 띄게 늘어난다. RAG는 매번 검색된 소수의 조각만 먹이기 때문에 응답이 일반적으로 더 빠르다. “하루에 수십 번씩 질문해야 하는” 고빈도 워크플로우에서는 이 차이가 누적되어 체감상 명확한 격차로 쌓인다.

비용: 통째로 넣기는 “질문할 때마다 한 번씩 다시 지불"하는 구조

이 부분이 가장 빠지기 쉬운 함정이다. 통째로 넣기의 숨은 비용은 이것이다. 질문 한 번을 할 때마다 전체 내용을 다시 한 번 보내는 셈이 되어, 입력 비용을 매번 새로 지불하게 된다. 열 번 질문하면 열 번 보내는 것이다. RAG는 검색된 조각만 보내기 때문에 한 번당 입력량이 훨씬 적다.

모델 자체의 가격 차이도 따져볼 만하다. 어느 선택 가이드는 “같은 작업으로 100만 토큰을 출력"한다고 가정할 때, Gemini 3.1 Pro는 약 12달러, 3.5 Flash는 9달러에 불과하다고 추산했다 [Source: https://maplefeather.com/article/gemini-model-guide-2026]. 같은 문서에서는 저자가 일상 업무의 약 80%를 더 저렴한 Flash에 맡기고 있다고도 언급한다. 초안 작성, 요점 정리, 일반적인 코드 수정, 다소 긴 질문에 대한 응답 등이다 [Source: https://maplefeather.com/article/gemini-model-guide-2026]. 다시 말해, 많은 사람이 최상급 Pro와 통째로 넣기가 필요하다고 생각하지만, 실제로는 저렴한 모델과 정밀한 검색만으로도 대부분의 문제를 해결할 수 있다.

결정표 한 장: 붙여넣어야 할까, 검색해야 할까

이론을 외울 필요 없이 세 가지 질문만 대조해보면 된다.

간단한 원칙은 이렇다. 일회성이고 분량이 적으면 → 붙여넣기. 고빈도, 대량, 정밀함이 필요하면 → 검색. “모델이 담을 수 있다"는 이유만으로 통째로 넣기가 최선이라고 기본 전제하지 말자. 담을 수 있다는 것이 경제적이라는 뜻도, 가장 정확하다는 뜻도 아니다.

여기까지 읽었다면 결정을 내리기에 이미 충분하다. 이어지는 부분은 이미 직접 문서를 조각내고 청크를 조정하고 평가를 돌려본 사람들을 위한 고급 내용이다. 이런 용어가 낯설다면 뒤쪽의 “민감한 파일을 붙여넣기 전 세 가지"로 바로 넘어가도 핵심을 놓치지 않는다.

이미 RAG를 구축해 본 사람들을 위해: 과소평가되기 쉬운 세 가지 판단 포인트

이미 직접 RAG를 만들어봤다면, “붙여넣기 vs RAG"라는 양자택일은 사실 너무 단순한 프레임이다. 판단에 넣어둘 만한 더 세밀한 포인트 세 가지가 있으며, 각 항목 뒤에는 한 줄 요약을 붙였다.

1. 선택은 2차원 문제다: 모델 등급 × 검색 여부. 문제를 “Pro + 통째로 넣기” 대 “Flash + RAG"로 단순화하지 말자. 어느 선택 가이드는 저자가 일상 업무의 약 80%를 더 저렴한 Flash에 맡기고 있으며, Flash도 100만 토큰 컨텍스트와 “사고” 능력을 함께 갖추고 있다고 지적한다 [Source: https://maplefeather.com/article/gemini-model-guide-2026]. 즉 진짜로 선택해야 할 것은 “Flash vs Pro"와 “붙여넣기 vs 검색"이라는 두 개의 스위치이며, 많은 작업 부하는 어느 검색 경로를 택하든 결국 Flash로 귀결된다.

   쉽게 말하면, “어떤 모델을 쓸지"를 먼저 제대로 고르는 것이 “붙여넣을지 말지"를 고민하는 것보다 종종 더 절약된다.

2. 캐싱은 “질문할 때마다 한 번씩 다시 지불"이라는 계산식을 바꿔놓는다. 통째로 넣기의 비용 통증은 입력을 반복해서 지불하는 데 있지만, 고빈도 RAG라는 작업 부하에 대해 선택 가이드가 내린 결론은 “무조건 검색을 더 하라"가 아니라 “Flash + 적극적인 캐싱"이며, “하루 수만 건의 쿼리, 고정된 3천 토큰 시스템 프롬프트를 동반하는” 시나리오를 구체적으로 지목한다 [Source: https://www.nxcode.io/resources/news/gemini-3-5-flash-vs-3-1-pro-when-to-use-which-2026]. 캐싱이 흡수하는 것은 정적인 부분(고정된 시스템 프롬프트, 안정적인 문서 말뭉치)이므로, 말뭉치가 충분히 안정적일 때 반복 질의의 한계 비용은 크게 눌러진다.

   쉽게 말하면, 말뭉치가 안정적일수록 캐싱의 절약 효과가 커지고, RAG만의 순수한 비용 우위도 함께 줄어든다. 이때 비교해야 할 것은 “인덱스 유지"와 “캐시 운영” 중 어느 쪽의 엔지니어링 비용이 더 낮은가다.

3. “문서 크기"가 아니라 작업 부하 기준으로 선택하라. 어느 가이드는 작업 부하별로 하나씩 분석하며, MCP 에이전트, 도구 집약형 워크플로우, 200페이지 문서 검색, 고빈도 RAG, ARC 스타일 추론이라는 다섯 가지 실제 시나리오를 중심으로 조언을 제시한다 [Source: https://we0.ai/zh-HK/articles/article-1780312880183]. 핵심은 “200페이지 일회성 검색"과 “고빈도 RAG 루프"가 완전히 다른 성격의 작업이라는 점이다. 전자는 보통 통째로 넣기만으로 충분해서 인덱스를 굳이 유지할 가치가 없고, 후자야말로 인덱스+캐싱+평가라는 엔지니어링이 진짜로 본전을 뽑는 지점이다.

   쉽게 말하면, “문서가 얼마나 큰가"보다 “이게 어떤 종류의 작업 부하인가"를 먼저 묻는 것이 RAG를 구축해야 하는지 판단하는 데 더 도움이 된다.

민감한 파일을 붙여넣기 전, 반드시 생각해야 할 세 가지

통째로 넣기의 가장 큰 함정은 기술이 아니라, “한 번의 클릭으로 붙여넣기"가 너무 편리해서 붙이면 안 되는 것까지 붙여넣기 쉽다는 점에 있다. 실행하기 전에 이 세 가지 관문을 반드시 통과하자.

1. 이 파일 안에 유출되면 안 되는 내용이 있는가? 고객 명단, 미공개 재무 정보, 개인정보가 포함된 표, API 키, 내부 경로 등. 붙여넣기 전에 스스로 물어보자. 이 내용이 유출되면 내가 감당할 수 있는가? 감당할 수 없다면 먼저 가리거나 빼야 한다.

2. 이 서비스는 붙여넣은 데이터를 어떻게 처리하는가? 학습에 사용되는지, 얼마나 오래 보관되는지, 기업용 버전에 데이터 미보관 옵션이 있는지 등을 붙여넣기 전에 확인해야지, 붙인 뒤에 후회하면 안 된다.

3. “비식별화"된 버전으로 대체할 수는 없는가? 많은 경우 원하는 것은 모델이 구조를 분석하고 요점을 짚어주는 것이지, 실제 이름과 실제 숫자가 꼭 필요한 것은 아니다. 민감한 항목을 코드명으로 바꿔서 붙여넣어도 원하는 답을 얻을 수 있는 경우가 많으며, 위험은 훨씬 낮아진다.

결론: “담을 수 있다"와 “담아야 한다"를 분리해서 생각하자

200만 토큰 컨텍스트는 분명 게임의 규칙을 바꿔놓았다. RAG를 구축하지 않고 통째로 넣는 것이 1인 기업이 진지하게 고려할 수 있는 선택지가 된 것은 이번이 처음이다. 하지만 이것이 해결한 것은 “담을 수 있는가"이지, “정확한가, 빠른가, 경제적인가"를 해결한 것은 아니다.

가져갈 수 있는 한 문장은 이것이다. 일회성이고 분량이 적은 작업은 통째로 넣기가 가장 간편하다. 고빈도, 대량, 답이 틀리면 안 되는 작업은 해야 할 검색을 여전히 해야 한다. 저렴한 모델에 정밀한 검색을 결합하는 것이 최상급 모델에 통째로 넣기를 결합하는 것보다 더 똑똑한 경우가 많다. 그리고 이미 RAG를 구축해 본 사람에게 진짜 지렛대는 먼저 작업 부하를 명확히 구분하고 모델 등급과 캐싱 이 두 가지를 제대로 맞추는 데 있다. 민감한 파일에 대해서는, 편리함이 안전보다 우선한 적은 없다. 붙여넣기 전에 30초만 더 생각하면 나중에 큰 번거로움을 덜 수 있다.

더 완전한 모델 성능과 개발자 관점은 Gemini 3.5 개발자 가이드를 참고할 수 있다 [Source: https://www.developersdigest.tech/blog/gemini-3-5-pro-developer-guide-2026].