Skip to content
←

Split View: 컨텍스트 예산 — 무엇을 넣을지가 아니라 무엇을 뺄지가 설계입니다

✨ Learn with Quiz
|

컨텍스트 예산 — 무엇을 넣을지가 아니라 무엇을 뺄지가 설계입니다

창은 남았는데 정확도가 떨어집니다

에이전트 세션이 길어지면 이상한 일이 생깁니다. 컨텍스트 창은 아직 한도에 닿지 않았는데, 초반에 준 지시를 잊고, 이미 확인한 파일을 다시 읽고, 앞에서 정한 규칙과 어긋나는 코드를 씁니다. 이 묘사는 특정 측정이 아니라 구성한 상황이지만, 방향 자체는 공개된 관찰과 일치합니다. Anthropic의 컨텍스트 엔지니어링 글은 토큰이 쌓일수록 회수 정확도가 떨어지는 현상을 컨텍스트 부식이라 부르고, 그 원인으로 어텐션이 토큰 쌍 단위로 분산되는 구조와 짧은 시퀀스 중심의 학습 분포를 듭니다.

결론은 단순합니다. 컨텍스트 창은 채우라고 있는 저장소가 아니라 배분해야 하는 주의 예산입니다. 예산이라면 지출 항목이 있어야 하고, 삭감 기준이 있어야 합니다.

컨텍스트 엔지니어링은 프롬프트 엔지니어링의 확장입니다

같은 글은 두 작업의 관계를 이렇게 정리합니다. 프롬프트 엔지니어링이 지시문을 잘 쓰는 일이라면, 컨텍스트 엔지니어링은 추론 시점마다 창에 들어갈 최적의 토큰 집합을 큐레이션하고 유지하는 일입니다. 시스템 프롬프트만이 아니라 도구 정의, 외부 자료, 메시지 이력까지 전부가 대상입니다. 한 번 잘 쓰면 끝나는 문서 작업이 아니라, 턴마다 반복되는 편집 결정이라는 점이 다릅니다.

하네스 관점에서 이 정의가 중요한 이유는 명확합니다. 컨텍스트 정책은 하네스의 여섯 손잡이 중 하나이고, 코드로 배포되는 결정입니다. "매 턴 무엇을 넣고 무엇을 빼는가"에 대한 답이 리포지토리 어딘가에 함수로 존재해야 합니다.

도구 스키마도 예산을 먹습니다

자주 잊히는 지출 항목이 도구 스키마입니다. 모델에게 노출한 모든 도구는 이름, 설명, 파라미터 스키마로 매 턴 창의 일부를 차지합니다. 도구를 21개 노출하면 모델이 아무 도구도 부르기 전에 이미 예산의 한 조각이 사라져 있습니다. 도구 수가 늘수록 선택도 흔들리므로, 스키마 비용은 토큰만의 문제가 아닙니다. 이 절충은 3편 도구 표면 설계에서 따로 다룹니다.

반대 방향의 절약 수단이 적시 로딩입니다. 자료 전체를 미리 창에 싣는 대신 파일 경로, 질의, 링크 같은 가벼운 참조만 두고 필요한 순간에 도구로 불러옵니다. 사람이 문서를 통째로 외우는 대신 어디에 있는지만 기억하는 것과 같은 구조이고, Anthropic 글이 권하는 기본 전략 중 하나입니다.

프롬프트 누적에서 플레이북으로

가장 흔한 컨텍스트 정책은 정책이 없는 것입니다. 새로 배운 규칙이 시스템 프롬프트 끝에 계속 붙고, 문서는 자라기만 합니다. 한 달 뒤에는 서로 모순되는 지시가 공존하고, 어느 항목이 아직 유효한지 아무도 모릅니다. 이 상태에서는 삭제가 불가능합니다. 지울 근거가 없기 때문입니다.

Lilian Weng의 하네스 글이 소개하는 에이전트 컨텍스트 엔지니어링 접근은 이 문제를 구조로 풉니다. 컨텍스트를 진화하는 플레이북으로 다루고, 항목을 만드는 역할과 되돌아보는 역할과 추려 내는 역할을 나눕니다. 항목 하나는 대략 이렇게 생겼습니다.

- id: pb-041
  rule: 'integration 테스트는 -j1 로 돌린다. 병렬이면 포트가 충돌한다.'
  scope: 'repo:payments-api / task:test'
  added: '2026-07-18'
  last_used: '2026-08-07' # 오래 안 쓰이면 큐레이션 대상
  helped: 23 # 이 항목이 실제로 도움이 된 횟수

요점은 형식이 아니라 메타데이터입니다. 언제 추가됐고, 어떤 상황에 적용되며, 최근에 도움이 됐는지가 기록되면 삭제가 가능해집니다. 컨텍스트 관리의 어려운 절반은 넣는 쪽이 아니라 빼는 쪽이고, 뺄 수 있으려면 항목에 근거가 붙어 있어야 합니다.

드롭 정책과 컴팩션: 무엇을, 언제

예산이 넘치면 무언가는 나가야 합니다. 무엇이 나가는지는 정책이 정합니다. 오래된 것부터 미는 정책은 구현이 공짜지만 초반의 핵심 규칙부터 잃습니다. 큰 덩어리부터 자르는 정책은 토큰은 아끼지만 중요도를 모릅니다. 플레이북처럼 적용 가능성이 낮은 항목부터 내리는 정책만이 "지금 이 과제에 덜 필요한 것"을 기준으로 삼습니다. 어느 쪽이든, 드롭 정책은 하네스의 명시적 결정이어야 합니다. 기본값에 맡기면 오래된 것부터 밀리는 정책을 선택한 것과 같습니다.

요약, 즉 컴팩션은 드롭의 보완입니다. 한도 근처에서 지금까지의 진행을 압축 요약하고 그 요약으로 새로 시작합니다. Anthropic 글은 이때 보존할 것으로 아키텍처 결정, 미해결 버그, 구현 세부를 꼽습니다. 반대로 말하면, 무엇을 보존할지 명시하지 않은 컴팩션은 그 세 가지를 잃는 방식으로 실패합니다. 함께 쓰이는 기법이 구조화된 메모입니다. 진행 상황을 창 밖의 파일에 적어 두고 필요할 때 다시 읽으면, 요약이 실패해도 복구 지점이 남습니다.

서브에이전트 위임: 깨끗한 창을 사고, 토큰으로 냅니다

컨텍스트 예산의 마지막 수단은 창을 나누는 것입니다. 탐색이 넓은 하위 과제를 서브에이전트에게 넘기면, 서브에이전트는 자기만의 깨끗한 창에서 일하고 압축된 요약만 본대에 돌려줍니다. 본대의 예산은 결론만 지불하면 됩니다.

공짜는 아닙니다. Anthropic의 멀티 에이전트 시스템 글은 자사 시스템 기준으로 에이전트가 일반 채팅의 약 4배, 멀티 에이전트 구성이 약 15배의 토큰을 쓴다고 보고합니다. 위임이 정당해지는 것은 과제의 가치가 그 비용을 넘을 때이고, 위임할 때도 목표, 출력 형식, 도구 안내, 과제 경계를 명시해야 중복 탐색과 폭주를 막을 수 있다는 것이 같은 글의 교훈입니다. 서브에이전트는 컨텍스트 문제의 탈출구가 아니라, 예산을 더 큰 단위로 재배분하는 손잡이입니다.

직접 연습하기

하네스 엔지니어링 RPG의 4티어 "컨텍스트 예산"이 이 글의 실습입니다. 프롬프트 누적, 잘라내기, 플레이북, 큐레이션 네 정책을 같은 시나리오에 끼워 보면, 드롭 정책이 결과를 어떻게 바꾸는지 직접 보입니다. 도구 스키마가 예산을 먹는 것도 게임 안의 수치로 확인할 수 있습니다.

참고 자료

The Context Budget — Design Is What You Leave Out, Not What You Put In

The window has room, but accuracy is falling

Strange things happen as an agent session gets long. The context window has not hit its limit, yet the agent forgets instructions given early on, rereads files it already checked, and writes code that contradicts rules it agreed to. This description is a constructed situation, not a specific measurement, but the direction matches published observations. The Anthropic post on context engineering calls the phenomenon context rot — retrieval accuracy degrades as tokens pile up — and points at the pairwise structure of attention and a training distribution centered on shorter sequences as reasons.

The conclusion is simple. The context window is not storage to be filled; it is an attention budget to be allocated. And a budget needs line items and cut criteria.

Context engineering is the extension of prompt engineering

The same post frames the relationship between the two jobs like this. If prompt engineering is writing instructions well, context engineering is curating and maintaining the optimal set of tokens that enter the window at each inference step. Not just the system prompt: tool definitions, external material, and message history are all in scope. The difference is that it is not a document you write well once — it is an editing decision that repeats every turn.

From the harness point of view, this definition matters for a clear reason. The context policy is one of the six knobs of the harness, a decision deployed as code. The answer to "what goes in and what comes out each turn" should exist as a function somewhere in your repository.

Tool schemas spend the budget too

The line item most often forgotten is tool schemas. Every tool you expose occupies part of the window every turn — name, description, parameter schema. Expose 21 tools and a slice of the budget is gone before the model calls anything. And since choice gets shakier as the tool count grows, schema cost is not only about tokens. That trade-off gets its own treatment in part 3 on tool surface design.

The savings lever in the opposite direction is just-in-time retrieval. Instead of preloading whole documents into the window, keep lightweight references — file paths, queries, links — and fetch at the moment of need with a tool. It is the same structure as a person remembering where the document lives instead of memorizing it, and it is one of the default strategies the Anthropic post recommends.

From prompt accumulation to a playbook

The most common context policy is having none. Newly learned rules keep getting appended to the end of the system prompt, and the document only grows. A month later, contradictory instructions coexist and nobody knows which items still hold. In this state, deletion is impossible — there are no grounds to delete on.

Lilian Weng's harness post introduces an agentic context engineering approach that solves this with structure. Treat context as an evolving playbook, and split the roles that generate entries, reflect on them, and curate them. A single entry looks roughly like this.

- id: pb-041
  rule: 'Run integration tests with -j1. Parallel runs collide on ports.'
  scope: 'repo:payments-api / task:test'
  added: '2026-07-18'
  last_used: '2026-08-07' # long-unused entries become curation candidates
  helped: 23 # how many times this entry actually helped

The point is not the format but the metadata. Once each entry records when it was added, where it applies, and whether it recently helped, deletion becomes possible. The hard half of context management is not the adding but the removing, and removal needs grounds attached to each item.

Drop policies and compaction: what, and when

When the budget overflows, something has to go. What goes is decided by policy. Pushing out the oldest first is free to implement but loses the early core rules first. Cutting the biggest chunks first saves tokens but knows nothing about importance. Only a policy that drops the least applicable items first — the playbook approach — uses "less needed for the task at hand" as its criterion. Either way, the drop policy must be an explicit harness decision. Leaving it to defaults is the same as choosing oldest-first.

Summarization — compaction — is the complement of dropping. Near the limit, compress the progress so far into a summary and restart from it. The Anthropic post lists what to preserve: architectural decisions, unresolved bugs, implementation details. Put the other way around, a compaction that does not specify what to preserve fails precisely by losing those three. A companion technique is structured note-taking: write progress to a file outside the window and reread it when needed, so even a failed summary leaves a recovery point.

Subagent delegation: buying a clean window, paying in tokens

The last resort of the context budget is splitting the window. Hand a wide-exploration subtask to a subagent, and the subagent works in its own clean window and returns only a condensed summary. The main agent's budget pays only for the conclusion.

It is not free. Anthropic's multi-agent system post reports, for their own system, that agents use roughly 4 times the tokens of ordinary chat, and multi-agent setups roughly 15 times. Delegation becomes justified when the value of the task clears that cost — and when you do delegate, the same post's lesson is to state the objective, the output format, tool guidance, and task boundaries, or you get duplicated exploration and runaway searches. Subagents are not an escape hatch from the context problem; they are a knob that reallocates the budget at a larger granularity.

Practice it yourself

Tier 4 of the harness engineering RPG, "Context budget", is the exercise for this post. Plug the four policies — append, trim, playbook, curation — into the same scenario and you can watch the drop policy change the outcome. You can also see tool schemas eating the budget as an in-game number.

References