초장문 컨텍스트 시대의 RAG 경계와 컨텍스트 예산 설계

100만 토큰 컨텍스트 모델에서 직접 투입과 RAG를 구분하고, 프롬프트 캐싱·리랭킹·권한 검증을 포함한 컨텍스트 예산 설계를 다룬다.

2026-08-31 · 최초 발행 2026-07-27

창 크기보다 먼저 정해야 할 것은 컨텍스트 예산이다

OpenAI는 2026년 7월 9일 GPT-5.6을 Sol·Terra·Luna로 구분해 GA로 공개했다. 세 모델은 모두 100만 토큰 컨텍스트, 최대 출력 128,000 토큰, 2026년 2월 지식 컷오프를 제공한다.

Sol은 복잡한 추론·코딩·장기 에이전트 작업을 위한 플래그십이고, Terra는 상시 사용을 겨냥한 균형형 티어다. Luna는 대량 워크로드를 위한 최저 단가 티어로 제시됐다. 100만 토큰 기준 단가는 Sol이 입력 $5·출력 $30, Terra가 $2.50·$15, Luna가 $1·$6이다. 같은 발표에는 다중 시간 단위 프로젝트를 수행하는 ChatGPT Work와 Sol을 최대 750 토큰/초로 서빙하는 추론 파트너십도 포함됐다.

문서를 자르고 검색해 필요한 조각만 넣는 대신, 문서 전체를 한 번에 모델에 전달하는 방식이 현실적인 선택지가 됐다. 그러나 창의 최대 크기와 실제로 활용할 수 있는 정보량은 다르다. 컨텍스트 중간에 놓인 정보의 활용도가 앞뒤 구간보다 낮아지는 현상은 여전히 관측되며, 100만 토큰을 Sol에 모두 넣으면 입력 비용만 호출당 $5가 든다. 반복 호출에서는 이 비용이 선형으로 증가한다.

따라서 롱컨텍스트는 RAG를 밀어내는 기능이라기보다, 어떤 정보를 얼마만큼 넣을지 관리하는 컨텍스트 예산 설계를 요구한다.

장문 입력 경로를 구성하는 요소

장문 입력에서는 시퀀스 길이에 따라 어텐션 연산량이 증가하고 KV 캐시 메모리도 함께 커진다. 입력이 길수록 지연과 단가가 동시에 높아지는 이유다. 출력 토큰 단가는 입력의 6배 수준이므로, 장문 입력에 짧은 출력을 결합하는 형태가 단가 면에서 가장 효율적이다.

반복 호출에는 프롬프트 캐싱을 적용할 수 있다. 시스템 프롬프트, 고정 문서, 도구 정의처럼 반복되는 접두를 캐시하면 재처리를 피할 수 있다. 고정 내용은 프롬프트 앞에 두고 변동 내용은 뒤로 보내야 한다. 이 순서가 바뀌면 캐시가 매 호출 무효화된다. 캐시가 실제로 작동하는지는 적중률을 지표로 노출해야 확인할 수 있다.

컨텍스트를 줄이는 방법은 요약 기반 압축, 질의와 관련된 문장만 골라 넣는 추출 기반 압축, 요약을 다시 요약하는 계층 압축으로 나뉜다. 토큰을 절약하는 대신 원문의 세부가 사라질 수 있다. 수치·인용·조건절이 중요한 문서에서는 그 손실이 치명적일 수 있다.

청킹은 문서를 의미 단위로 나누는 작업이다. 분할 경계가 문맥을 끊으면 검색 품질부터 흔들린다. 1차 검색 결과는 리랭킹으로 다시 정렬해 상위 소수만 컨텍스트에 넣는다. 이는 제한된 컨텍스트 예산을 유지하는 핵심 수단이다.

예산에는 시스템 프롬프트, 도구 정의, 대화 이력, 검색 결과, 사용자 입력, 출력 여유분이 포함된다. 각 항목의 상한과 초과 시 잘라내는 규칙을 명시하지 않으면 대화 이력이 예산을 잠식하고 검색 결과가 밀려난다. 100만 토큰은 목표가 아니라 상한이며, 실제 투입량은 정확도 실측으로 결정해야 한다.

아니오아니오적중미적중실패통과사용자 질의문서 총량이 예산 상한 이내?문서 전체 직접 투입검색 (임베딩 · 키워드)리랭킹 (상위 소수 선별)여전히 예산 초과?컨텍스트 압축 (요약 · 추출)컨텍스트 조립고정 접두 배치 (시스템 · 도구정의)프롬프트 캐시 적중?모델 호출 (입력 단가 절감)정보 소실 검증 (needle테스트)응답 반환 · 토큰 계측

직접 투입과 검색 계층을 가르는 기준

문서 단위가 명확하고 총량이 예산 안에 있으며 문서 전체의 상호 참조가 필요한 업무에는 직접 투입이 적합하다. 계약서 검토, 단일 코드베이스 분석, 회의록 요약이 여기에 해당한다.

반대로 지식 베이스가 계속 늘어나거나, 질의마다 특정 구간만 필요하거나, 같은 코퍼스에 반복 질의하는 환경에서는 검색이 유리하다. 판단의 중심은 문서 총량과 질의당 필요한 구간의 비율이다. 필요한 구간이 좁다면 전체 직접 투입은 비용 낭비가 된다.

롱컨텍스트를 도입해도 검색 계층을 유지해야 하는 이유는 코퍼스 증가 대응, 출처 표기, 접근 권한별 필터링, 비용 상한에 있다. 특히 접근 권한 필터링은 검색 계층에서만 실효적으로 구현된다. 문서 전체를 넣는 방식은 권한 경계를 넘어 노출될 위험을 만든다.

대화형 서비스라면 이력 누적으로 접두가 계속 변할 수 있다. 이력 요약 주기를 정해 접두의 안정성을 확보하고, 고정 문서는 접두에, 변동 질의는 후미에 두는 프롬프트 레이아웃을 표준으로 정할 필요가 있다.

정보 소실은 문서의 여러 위치에 검증용 사실인 needle을 넣고 위치별 회수율을 측정해 확인한다. 이 결과로 실제 안전 투입량을 산출해 예산 상한에 반영한다. 벤더가 공표한 창 크기를 그대로 상한으로 사용해서는 안 되며, 모델을 교체하면 세대별 위치 회수 특성이 달라질 수 있으므로 다시 측정해야 한다.

호출당·사용자당·일별 토큰 상한은 게이트웨이 계층에서 강제한다. 롱컨텍스트는 한 번의 호출로 예산을 소진할 수 있다. 호출당 평균 입력 토큰, 캐시 적중률, 티어별 호출 비중, 예산 초과 차단 건수는 함께 모니터링할 지표다.

직접 투입과 RAG의 역할은 다르다

구분 1M 컨텍스트 직접 투입 RAG 검색 기반 주입
구현 복잡도 낮음 높음(색인·검색·리랭킹)
호출당 비용 높음(입력 토큰 비례) 낮음
코퍼스 확장성 창 크기에 제한 사실상 무제한
문서 간 상호 참조 강함 약함
출처 표기 어려움 용이
권한별 필터링 어려움 검색 단계에서 적용
중간 구간 정보 소실 위치 의존 발생 상위 선별로 완화
지연 입력 길이에 비례 증가 검색 오버헤드 + 짧은 입력

문서 총량이 예산 이내이고 상호 참조가 핵심이면 직접 투입이 정확도와 구현 단순성에서 유리하다. 코퍼스가 계속 커지고 질의별 필요 구간이 좁다면 RAG가 비용, 확장성, 출처 표기 측면에서 앞선다. 둘은 대체 관계가 아니라 예산 상한에 따라 분기하는 하이브리드 구성의 일부다.

동일한 접두를 반복하는 워크로드에서는 캐싱이 입력 단가를 크게 낮추고 지연도 줄인다. 다만 접두가 호출마다 변하면 캐시는 무효가 된다. 절감 효과는 프롬프트 레이아웃에서 나오며, 적중률을 계측하지 않으면 그 효과는 추정에 머문다.

세 티어는 같은 창 크기를 제공하지만 장문 입력에서의 추론 품질은 상위 티어가 앞선다. 입력 기준 단가 차이는 5배($1 vs $5)다. 구조가 단순한 장문 요약·추출은 하위 티어로 보내고, 문서 간 상충 판단이 필요한 작업만 상위 티어에 배정하는 편이 총비용에 유리하다.

지식·문서·비용 통제로 이어지는 설계

컨텍스트 창이 커져도 지식을 조직해야 하는 이유는 남는다. 무엇을 투입할지 결정해야 하기 때문이다. 이는 분류와 색인이라는 기존 지식관리 과제와 연결된다. 출처 표기가 필요한 업무에서 검색 계층은 필수이며, 근거를 추적할 수 있다는 성질은 창 크기로 대체되지 않는다.

문서 전체 투입은 사실상 전체 열람과 같은 정보 노출을 만든다. 컨텍스트를 조립하는 단계에서 문서 분류 등급과 접근 권한을 검증해야 한다. 압축·요약을 거친 컨텍스트는 원문과 다른 산출물이므로, 요약 결과를 근거로 판단하는 업무라면 원문 참조 경로도 남겨야 한다.

컨텍스트 예산 표준은 문서화하고, 상한을 넘는 투입에 대한 승인 절차를 정의한다. 롱컨텍스트에 넣는 문서의 분류 등급과 권한 검증 절차도 명시해야 한다. 문서 전체 투입은 전체 열람에 해당하므로 권한 검토가 먼저 이뤄져야 한다.

창 크기 경쟁 이후의 변화

100만 토큰이 티어 전반의 기본 스펙으로 확산되면 경쟁의 초점은 창 크기에서 장문 구간의 실제 회수율로 옮겨간다. 프롬프트 캐싱은 선택적 최적화가 아니라 단가 산정의 기본 전제로 편입되고, 프롬프트 레이아웃 표준은 조직 자산으로 관리될 수 있다.

롱컨텍스트와 RAG를 예산 기준으로 분기하는 하이브리드 구성은 사실상 표준 아키텍처로 정착하는 흐름이다. 동시에 컨텍스트에 들어가는 문서의 권한 검증은 감사 항목으로 편입되고, 검색 계층은 접근통제 지점으로 다시 평가받게 된다.

Sources

롱컨텍스트RAG프롬프트 캐싱AI 아키텍처컨텍스트 예산