1M 롱컨텍스트 시대의 RAG 경계와 컨텍스트 예산 설계
1M 롱컨텍스트 환경에서 RAG, 프롬프트 캐싱, 컨텍스트 예산, 위치별 회수율을 기준으로 검색 계층 경계를 설계하는 방법
2026-08-31 · 최초 발행 2026-07-28
창 크기가 커져도 사라지지 않는 설계 문제
GPT-5.6 Sol·Terra·Luna 전 티어가 2026년 7월 9일 GA와 함께 1M 토큰 컨텍스트를 제공하면서, 컨텍스트 크기는 티어 선택의 기준에서 빠졌다. 이제 아키텍처의 질문은 RAG가 필요한지 여부가 아니다. 업무별로 검색으로 어디까지 후보를 좁히고, 어느 범위부터 원문을 그대로 넣을지 정하는 일이 핵심이 됐다.
컨텍스트 창이 커져도 긴 입력 중간의 정보가 희석되는 문제는 남는다. 입력 토큰을 늘리면 호출당 비용은 선형으로 증가하고, 대량 입력은 첫 토큰 지연도 키운다. 창의 최대 크기는 목표가 아니라 상한으로 다뤄야 한다.
표준 구간을 넘는 롱컨텍스트 요청은 티어별 단가가 약 2배로 상승한다. Sol은 $10/$45, Terra는 $5/$22.50, Luna는 $2/$9 per 1M tokens다.
컨텍스트를 채우기 전에 예산부터 정한다
컨텍스트 예산에는 시스템 지시, 도구 정의, 대화 이력, 검색 결과, 원문 문서, 출력 여유분이 함께 들어간다. 각 항목의 비중을 명시하고 총합에 상한을 둬야 한다. 이 상한은 창 크기가 아니라 목표 단가와 목표 TTFT에서 역산한다. 1M 창에 1M을 넣는 구성은 대부분 설계 실패다.
문서의 위치마다 정보 보존율은 같지 않다. 핵심 문서는 앞과 뒤에 배치하고, 참조성 자료는 중간에 둔다. 이때 검색 점수만 보지 말고 문서 신선도, 권위도, 업무 관련성을 함께 반영해야 한다.
대화 이력 요약, 도구 출력 절단, 중복 문단 제거는 토큰을 줄일 수 있다. 다만 압축에는 정보 손실이 따른다. 손실을 허용할 수 있는 항목에만 적용하고, 원문 보존이 필요한 규제 문서는 압축 대상에서 제외하는 규칙을 둬야 한다.
검색 계층을 유지하더라도 청크 수를 늘려 컨텍스트를 채우는 방식이 답은 아니다. 리랭킹으로 상위 소수만 남기는 편이 정확도가 높은 경우가 많다. 청크 경계가 문맥을 자르면 리랭킹 품질도 낮아지므로, 고정 길이보다 문서 구조 기반 청킹이 유리하다.
프리픽스는 비용 구조의 일부다
시스템 지시와 공통 문서를 고정 프리픽스로 두면 반복 호출에서 프리필을 생략할 수 있다. 롱컨텍스트일수록 절감 효과가 크다.
캐시를 활용하려면 프리픽스가 바이트 단위로 같아야 한다. 앞부분에 타임스탬프나 요청 ID를 넣으면 적중률은 0이 된다. 고정 부분인 시스템 지시·공통 문서와 가변 부분인 질의를 분리해 배치하고, 캐시 적중률을 지표로 등록해야 한다. 프롬프트 변경 배포와 이 지표를 연결하면 변경이 비용에 미친 영향도 추적할 수 있다.
직접 투입과 검색 주입의 선택 기준
| 구분 | 1M 직접 투입 | RAG 검색 주입 |
|---|---|---|
| 정확도 | 교차 참조 강함, 중간 소실 위험 | 검색 품질에 종속 |
| 지연 | 프리필 부담 큼 | 검색 추가, 프리필 작음 |
| 호출당 비용 | 높음 | 낮음 |
| 구축 복잡도 | 낮음 | 인덱싱·갱신 파이프라인 필요 |
| 출처 표기 | 어려움 | 자연스러움 |
| 적합 상황 | 문서 한정·교차 참조 | 대규모 지식·반복 질의 |
문서 규모가 창 안에 확실히 들어가고 문서 간 교차 참조가 필요하며 검색 누락 위험이 큰 업무라면 롱컨텍스트 직접 투입이 맞다. 계약 검토와 코드베이스 분석이 여기에 해당한다.
반대로 지식 규모가 창을 훨씬 넘거나 동일 질의가 대량 반복되면 토큰 비용이 누적된다. 이 경우 RAG가 비용과 지연 양쪽에서 우세하다. 지식 총량 대비 창 크기, 질의 반복률, 갱신 빈도, 출처 표기 요구를 판단 축으로 삼는다. 출처 표기가 필수인 업무는 검색 계층을 유지하는 편이 구현이 간단하다.
실제 구성은 하이브리드인 경우가 많다. 검색으로 후보 범위를 좁힌 뒤, 그 범위를 통째로 넣는다. 문서 수가 적고 상호 참조가 많으면 전량 투입이, 문서 수가 많고 질의가 국소적이면 상위 청크 선별이 유리하다.
전량 투입은 이론상 정보 보존율이 100%지만, 중간 구간 회수율이 낮으면 실제 보존율은 그보다 낮다. 상위 청크 선별은 관련 없는 정보를 제거해 판단을 선명하게 만들지만, 선별에서 빠진 정보는 완전히 소실된다.
평균 정확도로는 중간 구간 실패를 찾을 수 없다
위치별 회수 검증은 동일한 정답을 문서의 앞·중간·뒤에 각각 심고 회수율을 측정하는 방식으로 구성한다. 구간별 격차가 실사용 위험의 크기다. 평균 정확도만 보면 중간 구간 실패를 놓치므로, 구간별 분해 보고를 표준 형식으로 정해야 한다.
테스트셋은 조직의 실제 문서로 만든다. 공개 벤치마크는 문서 특성이 달라 조직의 위험을 대변하지 못한다. 모델을 교체하거나 컨텍스트 구성을 바꿀 때 회귀 항목으로 실행하고, 결과를 배포 게이트로 사용한다.
요청당 토큰 상한도 코드 수준에서 강제해야 한다. 상한이 없으면 사용자 첨부 문서 하나가 예산을 소진할 수 있다. 상한을 넘었을 때는 거부, 자동 압축, 검색 모드 전환 중 하나를 업무별로 지정한다.
평균 입력 토큰, 롱컨텍스트 진입률, 캐시 적중률, 위치별 회수율, 요청당 비용을 함께 관찰한다. 특히 롱컨텍스트 구간 진입률을 별도 지표로 관리해야 단가 배증의 원인을 사후에 설명할 수 있다.
검색 계층이 맡던 통제를 직접 배치해야 한다
컨텍스트 창 확대가 지식 조직화의 필요성을 없애지는 않는다. 무엇을 넣을지 결정하는 작업은 검색에서 예산 배분으로 이름만 바뀌었을 뿐이다. 문서 신선도와 권위도 메타데이터는 검색 방식과 직접 투입 방식 모두에서 우선순위 정렬의 근거가 된다.
원문을 통째로 모델에 넣는 방식은 문서 접근통제와 충돌할 수 있다. 검색 계층이 수행하던 권한 필터링이 사라지면 권한 없는 내용이 컨텍스트에 들어간다. 직접 투입 경로에도 호출 전 단계의 문서 단위 접근 권한 검증을 반드시 둬야 한다.
대량 원문 투입은 데이터 유출 경로이기도 하다. 데이터 분류 등급별 투입 허용 범위와 로그 보존 정책을 함께 규정해야 한다.
유효 컨텍스트를 기준으로 비교하게 되는 흐름
컨텍스트 창 크기는 모델 선택 변수에서 빠지고, 해당 길이에서 실제로 회수되는 정보량인 유효 컨텍스트가 비교 지표로 이동한다. 검색 계층의 역할도 정확도 확보에서 비용·지연 최적화로 재정의된다. RAG를 유지하되 청크 수를 줄이는 구성이 표준화될 수 있다.
프롬프트 캐싱은 비용 설계의 1급 항목이 되며, 프롬프트 조립 순서를 아키텍처 문서에 명시하는 관행이 확산될 전망이다. 위치별 정보 보존율 측정도 도입 검증 절차의 필수 항목으로 편입되고, 평균 정확도만을 단독 보고하는 방식은 부적절한 것으로 인식될 것이다.
Sources
- GPT-5.6: Frontier intelligence that scales with your ambition | OpenAI
- GPT-5.6 pricing (2026): Sol, Terra, and Luna costs explained | eesel AI
- GPT-5.6 Pricing 2026: Sol, Terra and Luna Tiers Explained | Finout
- GPT-5.6 Sol: Benchmarks, Pricing & API Access Guide 2026 | Eden AI
- OpenAI API Pricing (July 2026) | BenchLM.ai
- GPT-5.6 Pricing: Definitive Sol, Terra & Luna Guide 2026 | Techjack Solutions