컨텍스트를 줄였는데 호출은 늘었다: 요약·검색·참조의 비용 비교
토큰 절감과 실제 작업 비용을 분리한다. 최신 상태를 잃는 예제와 요약·재조회 비용 계산으로 네 가지 컨텍스트 정책의 비교 기준을 설명한다.
오래된 지시와 긴 도구 실행 결과가 그대로 남아 있으면, 토큰과 지연 시간만 늘어나고 성공률은 나아지지 않을 수 있다. 이번 비교의 목적은 필요한 정보가 아예 누락된 경우와 입력에는 있었지만 모델이 놓친 경우를 구분하는 데 있다.
Anthropic은 context engineering을 매 추론 시점에 어떤 토큰을 모델에 넣을지 관리하는 문제로 설명한다. 핵심은 컨텍스트 윈도우를 채우는 것이 아니라, 원하는 행동에 필요한 신호를 가장 작은 토큰 예산으로 보존하는 것이다.
컨텍스트가 길어질 때 생기는 문제
긴 컨텍스트가 치르는 비용은 토큰 요금만이 아니다.
첫째, 오래된 상태가 현재 상태와 경쟁한다. 사용자가 목적지를 바꾸거나 도구가 최신 값을 반환해도 이전 값이 입력에 계속 남아 영향을 준다.
둘째, 도구 출력이 대화의 대부분을 차지한다. 검색 결과, 스키마, 로그, HTML은 분량이 길지만 다음 판단에 실제로 필요한 정보는 일부에 불과한 경우가 많다.
셋째, 실패 원인을 구분하기 어려워진다. 필요한 정보가 없어서 틀렸는지, 정보는 있었지만 긴 입력 속에서 놓쳤는지, 아니면 서로 충돌하는 내용 중 잘못된 쪽을 선택했는지 따로 살펴봐야 한다.
넷째, 에이전트가 같은 작업을 반복할 수 있다. 이전 도구 호출에서 얻은 결론을 찾지 못하면 다시 검색하거나 같은 API를 중복 호출하게 된다. 이러면 비용과 지연이 늘어날 뿐 아니라 외부 시스템에 미치는 부작용도 커진다.
따라서 컨텍스트 정책은 압축률 하나로 평가할 수 없다. 반드시 보존해야 할 상태와 버려도 되는 기록이 무엇인지 먼저 정의해야 한다.
비교할 네 가지 정책
비교 조건에서는 모델, system prompt, 도구, 작업, 최대 출력 토큰, 재시도 정책을 고정한다. 달라지는 것은 매 턴 모델에 전달하는 컨텍스트뿐이다.
A. 전체 기록 유지 시스템 지시, 전체 대화, 모든 도구 호출과 결과를 시간순으로 유지한다. 가장 구현하기 쉽고 원문 손실이 없다. 반면 실행이 길어질수록 토큰과 지연이 늘어나며, 오래된 정보와 긴 도구 결과가 계속 남는다. 컨텍스트 한도에 도달했을 때 앞부분을 단순 절단하면 초기에 합의한 목표나 제약이 사라질 수 있다.
B. 오래된 기록의 구조화 요약 최근 대화는 원문으로 두고 오래된 기록은 구조화된 요약으로 바꾼다. 요약할 때는 목표, 제약, 결정, 완료된 작업, 남은 문제, 최신 상태를 분리해 저장한다. 토큰을 크게 줄일 수 있지만, 요약 과정에서 빠진 정보는 이후 턴에서 복구하기 어렵다. 잘못된 요약이 다음 요약에 다시 반영되면서 오류가 굳어질 수도 있다.
C. 필요한 과거 기록 검색 전체 기록은 외부 저장소에 두고 현재 요청과 관련된 과거 메시지·결정·도구 결과만 검색해 가져온다. 최근 몇 턴과 핵심 상태는 항상 포함하고, 나머지는 필요할 때 회수한다. 과거 원문을 다시 볼 수 있다는 장점이 있다. 다만 현재 질문과 의미적으로 닮지 않은 제약은 검색에서 빠질 수 있다. “언제나 읽기 전용으로 실행” 같은 전역 규칙을 일반 대화와 함께 벡터 검색에 맡기면 위험하다. 영구적인 제약과 권한은 검색 대상이 아니라 고정 컨텍스트로 관리해야 한다.
D. 큰 도구 결과를 참조로 대체 대화와 결정은 유지하되 오래되고 큰 도구 결과는 제거하거나 참조 포인터로 바꾼다. 예를 들어 파일 검색 결과 전체를 남기는 대신 선택한 파일 경로와 근거가 되는 줄만 남긴다. 데이터베이스 조회라면 원본 행 수천 개 대신 쿼리, 스냅샷 ID, 집계 결과, 검증용 해시를 보존한다. 필요하다면 원본 artifact를 다시 읽는다. 이 방식은 도구 출력이 컨텍스트 대부분을 차지하는 에이전트에 잘 맞는다. 그러나 결과를 너무 일찍 버리면 같은 도구를 다시 호출하거나 당시 판단의 근거를 재구성하지 못한다.
goal: 현재 작업 목표
constraints: 반드시 지켜야 할 조건
decisions: 확정된 선택과 근거
completed: 끝난 작업과 산출물
open_issues: 남은 문제
current_state: 최신 도구 결과에서 확정한 상태공정하게 비교하기 위한 두 단계
정책마다 입력 토큰 수가 다르기 때문에 한 번의 비교만으로는 결론을 내리기 어렵다. 그래서 실험을 두 단계로 나눈다.
1단계: 정책의 자연스러운 비용 비교 각 정책을 실제 운영 방식대로 실행한다. Full History는 가능한 한 전체 기록을 유지하고, 나머지는 설계한 요약·검색·가지치기 정책을 적용한다. 여기서는 최종 성공률과 함께 실제 토큰, 지연 시간, 도구 호출 수를 측정한다.
2단계: 동일 토큰 예산 비교 모든 정책에 같은 입력 토큰 상한을 둔다. Full History가 상한을 넘으면 사전에 정의한 절단 규칙을 적용한다. 이 단계는 같은 예산에서 어떤 정책이 더 중요한 정보를 잘 보존하는지 보여 준다.
두 결과는 함께 봐야 한다. 자연 비용 비교에서는 정확하지만 지나치게 비싼 정책이 있을 수 있고, 고정 예산 비교에서는 요약 오류가 크게 드러날 수 있다.
가상의 10턴 작업에서 전체 기록 정책이 매번 10,000 입력 토큰을 쓴다면 합계는 100,000토큰이다. 압축 정책이 매번 4,000토큰을 쓰고 별도 요약 호출에 입력 30,000토큰을 쓴다면 입력 합계는 70,000토큰이다. 겉으로 보이는 턴당 입력은 60% 줄지만 요약까지 합친 감소 폭은 30%다. 출력 토큰·캐시·검색 비용·단가가 빠진 설명용 계산이므로 실제 요금 절감률로 읽으면 안 된다.
참조로 바꾼 로그를 세 번 다시 가져왔다면 재조회 지연과 도구 호출도 더한다. 같은 토큰 예산에서 핵심 제약을 놓친 실행은 비용이 저렴하더라도 성공한 실행과 동등하게 비교할 수 없다. 먼저 성공 조건을 맞추고 완료한 작업당 총비용을 비교해야 한다.
상태 시험에는 ‘초기 PDF 요청 → 이후 Markdown으로 변경 → 마지막에 결과 형식 확인’ 같은 짧은 충돌을 넣을 수 있다. 요약에 PDF만 남았다면 쓰기 단계의 누락이고, 검색이 옛 PDF 요청만 회수했다면 회수 실패다. 최신 Markdown 요청이 입력에 있었는데도 PDF를 만들었다면 판단 실패다. 같은 최종 오류라도 이렇게 세 가지 원인으로 나누면 어느 정책을 고쳐야 할지가 달라진다.
시험 작업 유형
짧은 질의응답만 사용하면 네 정책의 차이가 거의 드러나지 않는다. 15~30턴을 출발점으로 삼아, 중간에 상태가 바뀌고 도구 출력이 누적되는 작업을 골라야 한다.
작업 유형: - 여러 문서를 조사한 뒤 조건에 맞는 후보를 비교하는 작업 - 스키마를 탐색하고 SQL을 수정하며 결과를 검증하는 작업 - 여러 파일을 읽고 일부를 수정한 뒤 테스트하는 코딩 작업 - 예약 조건이 중간에 바뀌는 일정·여행 계획 작업 - 고객 요구사항과 과거 결정 사항을 반영해 제안서를 갱신하는 작업
각 task에는 의도적으로 다음 사건을 넣는다. - 초기에 제시한 중요한 제약을 후반에 다시 사용 - 중간에 사용자 선호 또는 목표를 변경 - 오래된 값과 충돌하는 최신 도구 결과 제공 - 매우 긴 도구 결과 속에 필요한 근거를 한두 개 배치 - 이전 결정을 취소하거나 조건부로 변경 - 과거 근거를 다시 인용해야 하는 질문 추가
이렇게 구성해야 단순한 기억력뿐 아니라 최신 상태 선택, 충돌 해결, 근거 회수 능력까지 평가할 수 있다.
평가 기준
최종 작업 성공 최종 결과가 작업의 성공 조건을 충족하는지 본다. 단순 문자열 비교보다 파일 상태, 데이터베이스 상태, 테스트 통과 여부처럼 검증 가능한 end state를 우선한다.
초기 제약의 유지 초기에 주어진 제약 중 마지막까지 지킨 비율을 측정한다. 이때 보안·권한 제약과 사용자 선호는 따로 집계한다. 실패했을 때 치르는 비용이 다르기 때문이다.
최신 상태의 일관성 충돌하는 정보가 있을 때 최신 유효 상태를 사용했는지 본다. 취소된 지시나 이전 도구 결과를 다시 사용하면 stale-state error로 기록한다.
근거 검색과 답변의 근거 일치 정답에 필요한 과거 근거가 모델 입력에 들어왔는지, 그리고 최종 주장이 그 근거와 일치하는지 분리해 측정한다. 이렇게 해야 Retrieval 정책이 실패했는지, 아니면 생성 모델이 근거를 놓쳤는지 구분할 수 있다.
도구 재호출과 재시도 비용 총 도구 호출 수, 중복 호출 수, 실패 후 재시도 횟수를 기록한다. Tool-result pruning은 입력 토큰을 줄이는 대신 재호출을 늘릴 수 있으므로 두 값을 함께 봐야 한다.
비용과 지연 시간 - 입력·출력 토큰 - 요약 생성에 사용한 추가 토큰 - retrieval 및 reranking 시간 - p50·p95 전체 응답 시간 - task 하나를 끝내는 데 든 총 모델 호출 수
요약과 검색은 공짜가 아니다. 모델에 전달한 토큰만 세면 정책 자체를 운영하는 데 드는 비용을 놓치게 된다.
계측은 토큰의 출처까지 나눠야 한다
각 모델 호출에서 입력 토큰을 다음 범주로 나누어 기록한다.
그래야 토큰이 늘어난 이유를 알 수 있다. Tool-result pruning이 효과가 없었다면 원래부터 도구 출력이 짧았을 수 있고, Retrieval 비용이 비쌌다면 검색 결과의 중복이 원인일 수 있다.
모든 run에는 정책 버전도 함께 기록한다. summary-v2, retrieval-top5-rerank-v1처럼 남겨 두어야 정책 변경 전후를 재현할 수 있다.
system_instructions
tool_definitions
recent_messages
historical_messages
summary
retrieved_history
tool_results정책별 예상 실패
평균 성공률만 보면 이러한 차이가 가려진다. 작업 길이, 도구 출력 크기, 상태 변경 횟수, 초반 정보 재사용 여부에 따라 slice를 나눠서 봐야 한다.
| 정책 | 먼저 확인할 실패 | 디버깅 질문 |
|---|---|---|
| Full History | 오래된 지시 선택, 토큰·지연 증가 | 필요한 정보가 있었는데 왜 최신 것을 고르지 못했나 |
| Rolling Summary | 제약 누락, 잘못된 상태 고착 | 어느 요약 시점에 정보가 사라졌나 |
| Retrieval | 관련 기록 미회수, 중복 검색 | query와 metadata filter가 필요한 근거를 찾았나 |
| Tool-result Pruning | 근거 손실, 도구 재호출 | 제거한 결과를 다시 읽을 경로가 있었나 |
구현 시 지킬 경계
영구 정보와 임시 정보를 분리한다 시스템 지시, 권한, 보안 규칙은 요약이나 검색에 맡기지 않는다. 작업 목표와 확정된 결정은 durable state에 저장한다. 검색 결과와 원본 로그는 필요할 때 다시 읽는 episodic history로 둔다.
요약은 자유문보다 구조화한다 자유로운 문단 요약은 사실과 추론이 섞이기 쉽다. 목표, 제약, 결정, 근거, 미해결 항목을 분리하고 각 항목에 출처 이벤트 ID를 붙인다. 요약이 틀렸을 때 원문으로 돌아갈 수 있어야 한다.
제거 대신 포인터를 남긴다 긴 도구 결과를 컨텍스트에서 빼더라도 artifact ID, 생성 시각, 도구 입력, 핵심 결과는 남긴다. “전에 확인했다”는 문장만 남아 있으면 에이전트가 무엇을 확인했는지 검증할 수 없다.
중요한 상태는 검색 점수에 맡기지 않는다 최근 선택, 권한, 완료 여부는 명시적인 상태 저장소에서 읽어 온다. 벡터 검색은 관련 원문을 찾는 데 쓰고, 시스템의 현재 상태를 결정하는 유일한 근거로 사용하지 않는다.
외부 결과 참고
2026년에 공개된 한 장기 도구 사용 연구에서는 특정 비용 처리 업무를 대상으로, 최근 도구 호출은 남기고 오래된 기록을 요약하는 조건을 전체 기록 유지와 비교했다. 그 결과 요약한 조건에서 완료율이 더 높았고 토큰 사용량은 더 낮았다. 다만 이 결과를 모든 에이전트에 그대로 일반화할 수는 없다. 데이터셋이 특정 기업 업무에 국한되었고 도구 출력의 형태도 제한돼 있었기 때문이다.
이 결과는 전체 기록을 유지하는 정책이 언제나 가장 유용한 입력을 만든다는 보장이 없음을 보여 준다. 따라서 도입할 시스템의 작업 길이·상태 변화·도구 출력 분포를 반영한 평가셋에서 직접 다시 확인해야 한다.
기본 구조 검토
실무에서는 네 정책 중 하나만 고르기보다 역할을 분리해 조합하는 편이 현실적이다.
- 최근 대화 몇 턴은 원문으로 유지한다. - 목표, 제약, 확정된 결정은 구조화된 상태로 관리한다. - 오래된 대화와 근거는 검색 가능한 저장소에 둔다. - 큰 도구 결과는 artifact로 보관하고 컨텍스트에는 포인터와 요약만 남긴다. - 작업 단계가 바뀔 때 summary를 갱신하되 원문 event ID를 연결한다.
다만 처음부터 조합 정책으로 시작하면 각 요소의 개별 효과를 알기 어렵다. 먼저 네 가지 단일 정책을 각각 비교해 실패 원인이 드러난 뒤에 결합해야 한다.
단일 정책 실패 확인 후 조합
첫 비교에서는 네 정책을 각각 실행하고, 실패 원인을 제약 누락·오래된 상태 선택·근거 미회수·재호출로 나눠 기록한다. 이때 정책 자체를 운영하는 데 드는 요약·검색 비용도 함께 포함한다.
단일 정책에서 확인한 문제에 맞춰 요소들을 결합하면, 조합을 유지해야 하는 이유와 그에 따른 추가 비용을 명확히 설명할 수 있다. 단순히 컨텍스트가 짧아졌다는 사실만으로 개선 여부를 판단하지 않는다.
참고 자료
Effective context engineering for AI agents — Anthropic (https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents (새 창))
Demystifying evals for AI agents — Anthropic (https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents (새 창))
Less Context, Better Agents: Efficient Context Engineering for Long-Horizon Tool-Using LLM Agents (https://arxiv.org/abs/2606.10209 (새 창))
