100만 토큰 롱컨텍스트에서 정보 보존을 관리하는 방법

넓어진 창이 없애지 못한 제약

Anthropic이 2026년 7월 24일 공개한 Claude Opus 5는 입력 컨텍스트 100만 토큰과 최대 출력 128K 토큰을 제공한다. 지식 컷오프는 2026년 5월로 Claude 계열 중 최신이다.

이 변화로 문서를 전부 넣을지, 청킹·임베딩 기반 검색 계층을 계속 유지할지는 구현 세부사항이 아니라 아키텍처 선택이 됐다. 질문도 “검색 계층이 필요한가”에서 “검색 계층이 비용 대비 이득을 주는가”로 바뀐다.

다만 창이 넓어도 두 가지 제약은 사라지지 않는다. 긴 입력의 중간에 놓인 정보가 희석되는 lost in the middle 문제와 입력 토큰 증가에 따른 호출당 비용이다. 입력 100만 토큰당 5달러 기준에서는 컨텍스트를 가득 채운 단일 호출의 입력 비용만 5달러다. 반복 호출 워크로드라면 예산 압박으로 곧 이어진다.

입력량은 첫 토큰 지연(TTFT)도 늘린다. 대화형 서비스에서는 정확도보다 응답 시작 지연이 먼저 운영 문제가 될 수 있다. 따라서 컨텍스트는 무한한 저장 공간이 아니라, 우선순위와 상한을 가진 유한 예산으로 다뤄야 한다.

컨텍스트 조립을 별도 설계 대상으로 두기

전체 창은 시스템 지시, 참조 문서, 대화 이력, 도구 출력, 출력 여유분으로 나눌 수 있다. 각 영역에 상한이 없으면 어느 한쪽이 다른 영역을 잠식한다. 특히 출력 여유분을 먼저 확보하지 않으면 입력이 창을 거의 채웠을 때 긴 응답이 절단될 수 있다.

문서를 넣는 순서도 품질에 영향을 준다. 위치별 주의 감쇠를 전제로 가장 중요한 근거는 앞과 뒤에 배치하고, 중간 구간에는 보조 정보를 둔다. 질의 관련성 점수로 문서를 정렬하되, 하나의 문서 안에서도 핵심 절을 앞쪽으로 옮길 수 있다.

반복 재사용되는 시스템 지시와 참조 문서는 프롬프트 캐시의 접두부에 고정한다. 캐시는 접두부 일치를 기준으로 동작하므로 사용자 질의나 타임스탬프처럼 변하는 요소는 뒤에 두어야 적중률을 유지할 수 있다.

대화 이력은 원문을 계속 쌓는 대신 구조화된 요약으로 바꾸고, 도구 출력은 필요한 필드만 남기는 스키마 기반 형태로 줄인다. 다만 압축에는 정보 손실이 따른다. 업무별로 손실 허용 범위를 정하고, 수치·식별자·인용은 압축 대상에서 제외해야 한다.

롱컨텍스트를 채택해도 후보 선별 단계까지 없어지는 것은 아니다. 검색으로 관련 후보를 좁힌 뒤, 그 결과를 충분히 넓게 투입하는 방식이 현실적인 절충안이다. 리랭커는 상위 후보의 순서를 결정하므로 문서 위치 배치와 직접 맞물린다.

⤢✕

전량 투입 전에 확인할 운영 조건

계약서 전체 검토, 단일 대형 명세서 분석, 코드베이스 단위 리팩터링 검토처럼 문서 경계가 분명하고 상호 참조가 많은 작업은 전량 투입에 잘 맞는다. 반대로 수만 건 문서에서 소량의 근거만 찾는 질의응답, 고빈도 반복 호출, 저지연이 중요한 대화형 서비스는 검색 주입이 더 적합하다.

반복 호출 워크로드에서는 캐시 적중률을 1차 KPI로 둘 수 있다. 적중률이 낮다면 프롬프트 구조를 다시 배치해야 한다. 참조 문서의 갱신 주기와 캐시 수명이 맞지 않을 때 오래된 근거가 계속 쓰일 수 있으므로, 캐시 무효화 조건도 문서화해야 한다.

정보 보존 검증은 실제 조직 문서에서 정답이 분명한 문항을 뽑아 시작·중간·끝으로 근거 위치를 옮겨 가며 정확도를 재는 방식으로 구성한다. 투입량은 10만·30만·60만·100만 토큰 구간별로 측정해 실사용 상한을 경험적으로 확정한다. 위치별 정확도 격차가 임계값을 넘으면 투입량을 줄이거나 배치 전략을 조정한다. 이를 측정하지 않으면 조용한 품질 저하가 누적된다.

정확도가 동등하다면 비용과 지연이 낮은 방식을 택한다. 롱컨텍스트가 정확도 우위를 보이는 구간만 전량 투입으로 바꾸는 편이 낫다. 검색 계층을 없애기 전에는 코퍼스 증가 시나리오도 점검해야 한다. 지금 창에 들어가는 문서량이 내년에도 들어갈 수 있는지가 판단 근거다.

호출당 최대 입력 토큰은 정책으로 강제할 필요가 있다. 상한 없이 컨텍스트를 조립하면 언젠가는 창을 가득 채우게 된다. 상한을 넘겼을 때 자동 절단, 요약 압축, 오류 반환 가운데 어떤 동작을 택할지도 업무 성격에 맞춰 정의한다.

계측 대상은 호출당 입력 토큰, 캐시 적중률, TTFT, 위치별 정확도, 작업당 총비용이다. 컨텍스트 조립 로직은 결과물 품질을 좌우하는 코드이므로 형상관리와 리뷰 대상이어야 한다.

전량 투입과 검색 주입의 선택 기준

구분	1M 전량 투입	RAG 검색 주입
정확도(소규모 코퍼스)	높음	검색 품질 의존
정확도(대규모 코퍼스)	창 초과로 불가	유지
호출당 비용	높음	낮음
첫 토큰 지연	김	짧음
구축 복잡도	낮음	높음(색인·임베딩·리랭킹)
상호 참조 추론	유리	청크 경계에서 손실
최신성 반영	즉시	색인 주기 의존

전량 투입은 구축이 단순하고 문서 사이의 상호 참조를 추론하는 데 강점이 있다. 그러나 호출당 비용과 지연이 크며, 코퍼스가 창을 넘는 순간 선택지가 될 수 없다. 검색 주입은 비용과 지연이 낮고 코퍼스 규모에 확장적이지만, 청크 경계에서 문맥이 끊기고 검색 실패가 그대로 오답으로 이어진다.

프롬프트 캐싱을 적용하지 않으면 프롬프트 구조에 제약이 없고 별도 구현도 필요 없다. 대신 같은 시스템 지시와 참조 문서에 매 호출 전액이 과금된다. 접두부를 고정하는 제약을 받아들이면 반복 호출의 단가는 크게 낮아진다. 호출 빈도가 높고 참조 문서가 고정적인 워크로드일수록 이 차이가 커진다.

문서 전체를 넣으면 근거 자체가 누락될 위험은 줄지만, 중간 구간 희석으로 정보가 들어 있어도 활용하지 못하는 상태가 생길 수 있다. 상위 청크만 선별하면 정보 밀도를 높여 위치 감쇠를 줄일 수 있지만, 선별에 실패하면 근거가 아예 사라진다. 위치별 보존율을 측정하지 않은 전량 투입은 정보 보존을 가정하는 선택이며, 투입량이 커질수록 그 가정은 약해진다.

지식과 비용을 함께 통제하는 관점

컨텍스트 조립은 질의 시점에 조직 지식을 다시 구성하는 행위다. 무엇을 넣을지 정하는 규칙이 곧 지식 활용 정책이 된다. 창이 넓어졌다고 선별을 생략하면 지식 품질을 관리하는 지점도 사라진다. 넓은 창은 선별 부담을 없애는 대신 선별 기준을 바꾼다.

전량 투입은 문서 자체의 품질에 직접 의존한다. 중복 문서, 폐기 대상 문서, 서로 상충하는 개정판이 함께 들어가면 모델의 판단이 흐려진다. 문서 생애주기 관리인 개정·폐기·보존기간이 선행되지 않으면 롱컨텍스트는 잡음 증폭기가 된다.

컨텍스트 예산은 IT 비용 항목으로도 다뤄야 한다. 호출당 토큰 상한과 부서별 예산 배분을 함께 정해야 통제가 성립한다. 관리 지표는 단가보다 작업당 총 토큰이 되어야 한다. 창이 넓어질수록 단가만으로는 예측하기 어렵다.

2026년에 예상되는 운영 변화

컨텍스트 예산 배분 로직은 애플리케이션 코드에서 독립 모듈로 분리되고, 형상관리와 테스트 대상에 편입될 전망이다. 위치별 정보 보존 검증도 모델 채택 절차의 표준 항목으로 자리 잡으며, 벤더가 제공하는 벤치마크만으로는 채택 근거가 부족하다는 인식이 확산될 수 있다.

프롬프트 캐싱 적중률은 AI 서비스 운영의 핵심 KPI로 들어가고, 캐시 친화적 프롬프트 구조는 설계 관행으로 정착할 가능성이 있다. 롱컨텍스트와 검색 계층은 하이브리드가 기본형이 되며, RAG 제거보다 RAG 축소가 현실적인 전환 경로로 수렴할 전망이다.

100만 토큰 컨텍스트는 검색 계층을 없애는 기능이라기보다, 검색 계층의 이유를 정확도에서 비용과 지연으로 옮기는 변화에 가깝다. 중간 구간 정보 희석과 호출당 토큰 비용은 창이 넓어져도 남는다. 구획별 상한, 출력 여유분, 캐시 구조, 위치별 정보 보존 검증을 함께 설계해야 전량 투입 여부를 검증 가능한 운영 판단으로 만들 수 있다.