Gemini 1.5: 100만 토큰 컨텍스트가 바꾼 애플리케이션 설계

핵심 판단: 100만 토큰 컨텍스트는 RAG를 없애는 기능이 아니라 검색·캐시·전체 읽기 사이의 비용 경계를 다시 그린 기능이었다.

긴 컨텍스트 발표를 “파일을 전부 넣으면 된다”로 이해하면 설계가 오히려 나빠진다. 입력 한도를 늘리는 것, 긴 입력에서 필요한 근거를 찾는 것, 근거들을 조합해 정확한 답을 만드는 것은 서로 다른 능력이다. Gemini 1.5의 의미는 이 세 문제를 한 번에 해결했다는 데 있지 않고, 애플리케이션이 선택할 수 있는 입력 전략의 범위를 크게 넓힌 데 있다.

발표를 한눈에 보기

• 발표 주체: Google
• 공식 발표일: 2024-02-15
• 대상: Gemini 1.5 Pro
• 발표 당시 상태: 제한된 개발자·기업 고객 프리뷰
• 이 글의 질문: 긴 컨텍스트가 검색 증강 생성과 애플리케이션 비용 구조를 어떻게 바꿨는가?

긴 문서, 코드 저장소, 긴 영상·오디오를 한 프롬프트에서 분석하는 예시와 제한된 개발자 프리뷰가 공개됐다.

기술 구조: 무엇이 실제로 달라졌나

희소 MoE가 입력에 따라 일부 전문가 네트워크를 활성화하며, 긴 컨텍스트의 특정 정보를 찾는 needle-in-a-haystack 평가가 강조됐다.

Gemini 1.5는 Mixture-of-Experts 구조로 요청마다 일부 전문가 네트워크를 활성화했다. 발표의 중심은 구조 이름보다 멀티모달 장문 입력이었다. 대규모 코드베이스, 긴 영상, 오디오를 하나의 요청에 넣고 서로 떨어진 단서를 찾는 사례가 제시됐다.

하지만 컨텍스트 창은 저장소가 아니다. 입력 토큰이 늘면 첫 응답 지연, 처리 비용, 캐시 전략, 근거 추적 난도가 함께 증가한다. RAG는 필요한 조각을 좁혀 비용과 잡음을 줄이고, 전체 컨텍스트는 문서 전체의 관계를 보존한다. 둘을 대체재가 아니라 단계별 도구로 봐야 한다.

작동 흐름: 원본 자료 정규화 → 변경이 적은 공통 컨텍스트 캐시 → 질의별 검색으로 후보 축소 → 필요 구간과 전역 요약을 모델에 제공 → 인용 근거 검증

이 구조에서 개발자가 가져갈 설계 원칙은 다음과 같다:

• 컨텍스트 한도가 아니라 유효 컨텍스트 길이와 위치별 회상률을 측정한다.
• 매 요청마다 전체 저장소를 보내지 말고 변경 빈도와 재사용률에 따라 캐시 단위를 정한다.
• 긴 입력에서도 답변 문장마다 원문 위치를 되돌릴 수 있도록 문서 식별자와 구간 메타데이터를 보존한다.

발표가 바꾼 것과 바꾸지 않은 것

RAG로 잘게 쪼개던 입력을 모델이 직접 읽는 선택지가 생기면서 검색, 캐싱, 비용 최적화 설계가 다시 비교 대상이 됐다.

이후 모델 API 비교에서 컨텍스트 길이는 기본 사양이 됐다. 동시에 “검색 없이 전부 넣기”의 낭비도 더 분명해졌다. 긴 입력은 법률 문서의 교차 참조나 저장소 전역 리팩터링처럼 관계 보존이 중요한 작업에 유리하고, 단순 FAQ처럼 근거가 국소적인 작업은 검색이 더 예측 가능하다.

다만 다음 문제까지 해결됐다고 확대 해석해서는 안 된다:

• needle-in-a-haystack 회상률은 여러 근거를 조합하는 실제 추론 품질과 동일하지 않다.
• 최대 토큰을 수용해도 중간 위치의 정보 손실과 지시 충돌이 사라지는 것은 아니다.
• 민감한 원문 전체를 외부 API로 보내면 최소 수집 원칙과 접근 제어 범위가 넓어진다.

직접 평가한다면 이렇게 본다

발표사의 종합 점수 하나를 재현하는 것보다, 실제 제품의 입력과 실패 비용에 맞춘 평가가 더 유용하다. 이 주제라면 다음 순서로 확인한다:

• 10K·100K·500K·1M 구간에서 동일 질의를 실행해 정확도와 첫 토큰 지연을 곡선으로 본다.
• 전체 입력, 벡터 검색, 키워드 검색, 검색과 전체 요약 결합을 같은 데이터로 비교한다.
• 근거가 입력 앞·중간·끝에 있을 때와 서로 떨어진 두 구간에 있을 때를 분리한다.
• 입력·출력 토큰 비용, 캐시 적중률, 근거 없는 답변률을 한 대시보드에 묶는다.

품질 1점의 이득이 요청당 비용과 지연을 얼마나 늘리는지 함께 보지 않으면 긴 컨텍스트의 사업적 가치를 판단할 수 없다.

내 판단

긴 컨텍스트는 검색 인프라를 삭제할 이유가 아니라 더 정교하게 계층화할 이유다. 기본 경로는 검색으로 좁히고, 문서 전역 관계가 필요한 요청만 큰 컨텍스트로 승격하는 라우팅이 현실적이다. 최대 길이를 제품 메시지로 소비하기보다, 어느 길이까지 근거 추적과 비용이 통제되는지를 팀의 사양으로 만들어야 한다.

긴 입력을 수용하는 것과 전체 내용을 안정적으로 추론하는 것은 다르며 지연 시간, 비용, 중간 정보 손실을 별도로 측정해야 했다.

검증 범위

이 글은 공식 발표와 공개된 기술 자료를 바탕으로 구조와 제품 영향을 분석했다. 직접 벤치마크나 장기 운영 검증은 수행하지 않았으며, 발표사가 제시한 수치는 해당 기관의 평가 조건에 한정해 해석했다. 업데이트 시점은 2026년 7월 18일이다.