100만 토큰 AI 코딩 에이전트의 컨텍스트 부패(Context Rot)를 방지하는 방법: 메모리 예산 책정 및 세션 규율에 관한 실무 가이드

거대한 컨텍스트 윈도우(Context Window)가 회상(Recall)을 보장하지는 않습니다. 장기 실행되는 코딩 에이전트의 정확도를 유지하고 비용을 낮추기 위해 압축(Compaction), 엄격한 세션 예산(Session Budgets), 그리고 무자비한 프롬프트 가지치기(Prompt Pruning)를 사용하십시오.

100만 토큰이 망각을 방지하지 못한다는 사실을 받아들이십시오

에이전트는 100만 토큰의 컨텍스트 윈도우(Context Window)를 가지고 있어도 요구 사항을 잊어버립니다. 실제로 에이전트는 20번의 요청을 거친 후, 10분 전에 당신이 무엇을 요청했는지 놓칠 수 있습니다. 연구에 따르면 컨텍스트가 커질수록 모델의 성능은 지속적이고—재앙적으로—저하되며, 일부 모델의 경우 약 10K 토큰 부근에서 이러한 현상이 나타나고 50K를 넘어서면 가속화됩니다. 엔지니어링 없는 더 큰 윈도우는 단순히 대규모의 값비싼 환각(Hallucination)을 생성할 뿐입니다.

컨텍스트 윈도우를 창고가 아닌 예산으로 취급하십시오. 100만 토큰의 상한선이 100만 토큰의 신뢰할 수 있는 작업 메모리(Working Memory)를 가졌음을 의미하지는 않습니다. 사용량이 저하가 시작되는 임계값을 넘어서면, 이론적 한계와 상관없이 회상 정밀도(Recall Precision)가 떨어집니다. 실시간 토큰 수를 모니터링하고 품질이 붕괴하기 전에 엄격한 차단(Hard Cutoffs)을 시행하십시오. 수십만 개의 토큰에 걸쳐 세밀한 디테일을 모델이 유지할 것이라고 기대하는 것은 관찰된 실패 패턴을 무시하는 것입니다.

일반적인 접근 방식은 50K 토큰에서 자동화된 가드레일(Guardrail)을 설정하는 것입니다:

def within_context_budget(current_tokens: int) -> bool:
    # 재앙적인 저하 구역에 도달하기 전 엄격한 중단
    return current_tokens < 50_000

예산이 소진되면 텍스트를 더 추가하기보다 아카이브하거나 요약하십시오. 보수적인 관행에 따르면, 사용 가능한 윈도우의 50%에 도달했을 때 새로 시작하거나 포괄적인 요약(Summarization)을 트리거하는 것이 좋습니다. 전체 윈도우를 무료 저장 공간으로 취급한다면, 당신은 오류율을 능동적으로 높이는 토큰에 비용을 지불하고 있는 것입니다. 세션을 제한하고, 실제 사용량을 측정하며, 예산 임계값을 넘어서는 모든 것은 이미 잊혔다고 가정하십시오. 윈도우 크기는 리소스 제한이지, 유지(Retention)의 보장이 아닙니다.

모든 세션을 윈도우의 50%로 제한하기

보수적인 메모리 예산 책정(Memory budgeting)은 한계치에 도달하기 전에 리셋을 요구합니다. 주요 작업을 완료한 후 새롭게 시작하거나, 세션이 사용 가능한 윈도우(Window)의 50%에 도달하면 강제 중단(Hard stop)을 시행하십시오. 이 임계값은 컨텍스트(Context)가 품질 저하를 일으킬 만큼 커지는 것을 방지합니다. 제한에 걸리면 새로운 대화 스레드를 생성하거나, 깨끗한 에이전트(Agent)를 인스턴스화하거나, 컨텍스트를 효과적으로 재부팅하는 포괄적인 요약(Summarization)을 실행하십시오.

오케스트레이션 계층(Orchestration layer)에서 토큰 수를 모니터링하고, 경계선을 넘는 즉시 핸드오프(Handoff)를 트리거하십시오. 일반적인 접근 방식은 매 턴(Turn)마다 누적 사용량을 확인하는 가드(Guard)로 에이전트 루프를 감싸는 것입니다:

def run_turn(agent, messages, limit: int):
    used = count_tokens(messages)
    if used > limit // 2:
...

터미널 기반 워크플로우의 경우, 제공자(Provider)의 사용량 페이로드(Usage payload)에 대한 쉘 사전 점검(Shell pre-flight check)을 통해 동일한 제한을 적용하십시오:

USED=$(cat session.json | jq '.usage.total_tokens')
HALF=$(($CONTEXT_LIMIT / 2))
if [ "$USED" -gt "$HALF" ]; then
...

윈도우의 후반부를 사용 가능한 용량이 아닌, 보호된 비상 예비군(Emergency reserve)으로 취급하십시오. 중간 지점에서 리셋을 강제하면 응답 정확도를 유지할 수 있으며, 전체 윈도우가 비대해진 후에 뒤따르는 품질 저하(Quality collapse)를 방지할 수 있습니다.

이력을 쌓아두는 대신 압축하기

가공되지 않은 메시지 로그(Raw message logs)는 토큰을 가장 빠르게 소모하고 컨텍스트 부패(Context rot)를 유발하는 방법입니다. 매 턴마다 수백 또는 수천 개의 토큰이 추가되므로, 긴 코딩 세션은 100만 토큰(1M-token) 윈도우 내에서도 효과적인 회상 임계값(Recall threshold)을 빠르게 초과합니다. 해결책은 컨텍스트 압축(Context compaction)입니다. 최근의 턴(Turn)들은 상세하게 유지하면서, 오래된 대화들은 밀도 높은 요약본으로 축소하십시오. 이렇게 하면 대화의 흐름을 놓치지 않으면서도 작업 세트(Working set)를 작게 유지할 수 있으며, 압축 후에는 과금되는 토큰이 줄어들기 때문에 긴 스레드에서의 API 비용을 직접적으로 낮출 수 있습니다.

일반적인 접근 방식은 각 하위 작업(sub-task)이 완료될 때마다 압축(compaction)을 실행하는 것입니다. 그 시점에 생성된 요약(summary), 현재 파일 상태, 그리고 마지막 몇 개의 사용자-어시스턴트(user-assistant) 대화 내용만을 활성 메모리(active memory)에 저장합니다. 그 이전의 모든 내용은 아카이브하거나 폐기합니다. 요약을 시스템 레벨 메시지(system-level message)로 취급하여, 에이전트가 이전 단계에서의 결정 사항과 제약 조건(constraints)을 유지할 수 있도록 합니다.

def compact_turns(history, keep_last=3):
    stale = history[:-keep_last]
    recent = history[-keep_last:]
...

이때 현재의 파일 트리(file tree)나 핵심 코드 조각(key snippets)을 동시에 주입하면, 다음 프롬프트가 쓸모없는 수정 사항들을 끌고 오지 않으면서도 정확한 상태를 기반으로 유지될 수 있습니다. 이는 컨텍스트를 무한정 늘리기보다 주요 마일스톤(milestone)에 도달했을 때 컨텍스트를 초기화하는 보수적인 관행을 반영한 것입니다. 정보를 쌓아두는 대신 압축함으로써, 토큰 팽창(token bloat) 없이 정확성을 유지하고 긴 세션 동안 에이전트의 응답성(responsiveness)을 유지할 수 있습니다.

스킬 파일과 시스템 프롬프트를 극한까지 다이어트하기

스킬 파일(skill file)의 모든 토큰은 호출될 때마다 활성 컨텍스트(active context)에 로드되므로, 비대해진 파일은 부패(rot)를 직접적으로 가속화합니다. 모든 스킬 정의에 대해 200라인을 엄격한 상한선(hard ceiling)으로 간주하십시오. 만약 파일이 이 임계값을 넘는다면, 하위 작업별로 분할하거나 재사용 가능한 헬퍼(helpers)를 별도의 모듈로 추출하십시오. 먼저 파일을 세 가지 필수 요소, 즉 도구 스키마(tool schema), 최소한의 파라미터 정의(parameter definition), 그리고 하나의 간결한 사용 예시(usage example)로 압축하는 것부터 시작하십시오. 배경 이론, 장황한 인라인 주석(inline comments), 여러 페이지에 달하는 튜토리얼, 그리고 장식용 메타데이터(metadata)는 모두 제거하십시오. 에이전트에게 스키마가 필요하다면, 전체 주석이 달린 OpenAPI 명세서 대신 JSON 스켈레톤(skeleton)을 제공하십시오. 목표는 모델이 도구를 올바르게 호출할 수 있을 만큼의 구조만 제공하고 그 외의 것은 주지 않는 것입니다. 모든 추가적인 주석이나 사용되지 않는 속성(property)은 세션 후반부에 사용자의 코드를 밀어내는 토큰이 됩니다.

# 나쁜 예: 400라인 이상의 거대한 단일 스킬
description: |
  This tool handles user authentication...
...

# 좋은 예: 200라인 미만, 스키마 + 예시 하나
name: auth_user
parameters:
...

시스템 프롬프트(System prompts) 또한 동일한 절약 원칙을 따라야 합니다. 모든 전역 지침을 하나의 거대한 단일 블록(monolithic block)에 쏟아붓는 대신, 작업 유형 플래그(task-type flags)를 통해 컨텍스트를 제어하십시오. 일반적인 접근 방식은 프롬프트 조각(prompt fragments)의 딕셔너리를 유지하고, 현재 작업과 일치하는 조각만 주입하는 것입니다. 에이전트가 세션 시작 시 이미 로드한 프로젝트 전반의 컨벤션(conventions)을 다시 언급하는 것은 피해야 합니다.

TASK_PROMPTS = {
    "refactor": "기존 스타일을 따를 것. 공개 API의 이름을 변경하지 말 것.",
    "test": "pytest를 사용할 것. 외부 HTTP 호출은 모킹(Mock)할 것.",
...

이렇게 하면 에이전트가 매 턴(turn)마다 무관한 지침에 대해 반복적인 토큰 세금(token tax)을 지불하지 않고, 정확히 필요한 제약 조건만을 전달받을 수 있습니다.

주요 작업 경계에서의 재부팅 (Reboot on Major Task Boundaries)

세션이 표류하게 두지 말고 의도적으로 종료하십시오. 기능 브랜치 병합(merging a feature branch), 풀 리퀘스트(pull request) 종료, 또는 코드 리뷰 완료와 같은 주요 작업을 마친 직후에는 다음 작업 단위를 시작하기 전에 즉시 리셋하십시오. 이러한 경계 설정은 오래된 가정(stale assumptions), 버려진 변수명, 그리고 오래된 파일 내용이 관련 없는 로직으로 흘러 들어가는 것을 방지합니다.

먼저 저장소(repository)에서 경계를 표시하십시오:

git checkout main
git merge --no-ff feature/payments
git branch -d feature/payments

작업이 종료되면 새로운 대화 스레드를 시작하거나 새로운 에이전트 인스턴스를 생성하십시오. 전체 대화 기록(transcript)을 그대로 가져가는 것은 모델이 이전의 구현 방식이나 거부된 접근 방식에 계속 가중치를 두게 만들기 때문에 작업 간 오염(cross-task pollution)을 보장하는 꼴이 됩니다. 각 주요 결과물(deliverable)을 자체적인 깨끗한 상태를 가진 별개의 부트 컨텍스트(boot context)로 취급하십시오.

만약 세션 간의 연속성을 유지해야 한다면, 전체 채팅 기록을 다음 창에 쏟아붓는 대신 압축된 인수인계 문서(handoff document)를 전달하십시오. 인수인계 문서에는 아키텍처 결정 사항(architectural decisions), 중요한 파일 포인터(file pointers), 그리고 미결 작업 항목(outstanding action items)만 포함되어야 합니다. 이를 작은 마크다운(markdown) 파일로 생성하십시오:

cat > handoff.md << 'EOF'
Decision: 송장 생성을 위해 비동기 작업 큐(async job queue) 채택
Files: src/jobs/invoice.ts, src/queue/redis.ts
...

해당 파일만 새 세션에 입력합니다. 주요 경계 지점에서 컨텍스트를 재부팅(rebooting)하고 정제된 상태(distilled state)만을 가져옴으로써, 에이전트의 작업 메모리(working memory)를 현재 작업에 집중시키고 컨텍스트 부패(context rot)를 유발하는 누적 노이즈를 방지할 수 있습니다.

제어 루프(Control Loop) 내 컨텍스트 엔지니어링의 실행

컨텍스트 엔지니어링(Context engineering)은 컨텍스트 인플레이션(Context inflation)보다 효과적입니다. 에이전트의 컨텍스트 윈도우(context window)를 런타임 가드레일(runtime guardrails)이 있는 엄격한 메모리 예산으로 취급하십시오. 어떤 기술(skill)이 실행되기 전에 해당 페이로드(payload)를 검증해야 합니다. 예를 들어, 로드된 기술 파일이 200행 이내로 유지되는지 확인(assert)하십시오. 만약 파일이 제한을 초과하면, 작성자가 로직을 분할하거나 불필요한 예시를 제거할 때까지 로드를 거부하십시오. 이 단일 점검만으로도 진입 단계에서 발생하는 토큰 팽창(token bloat)의 주요 원인을 제거할 수 있습니다.

다음으로, 세션 깊이(session depth)를 지속적으로 모니터링하도록 제어 루프(control loop)에 계측(instrument)을 적용하십시오. 세션 임계값의 50%에 도달하면 요약(summarization)을 자동으로 트리거하십시오. 이는 조용한 축적을 방지하고, 검색 품질(retrieval quality)이 저하되기 전에 '압축 후 계속(compress-and-continue)' 체크포인트를 강제합니다. 중간 지점을 부드러운 권장 사항이 아닌 엄격한 회로 차단기(circuit breaker)로 취급하십시오.

도구 출력(Tool outputs) 또한 계획되지 않은 성장의 또 다른 흔한 경로입니다. 컨텍스트 윈도우를 예산 초과로 몰아넣는 모든 응답은 거부하거나 잘라내십시오(truncate). 가벼운 사전 삽입 필터(pre-insertion filter)를 사용하면 에이전트가 장황한 로그에 빠져 허우적거리는 것을 방지할 수 있습니다.

def insert_tool_output(ctx, output, limit=1_000_000):
    projected = ctx.token_count + estimate_tokens(output)
    if projected > limit * 0.5:
...

마지막으로, 프롬프트 템플릿(prompt templates)에 코드 리뷰(code-review) 규율을 적용하십시오. 함수를 리뷰하는 것과 동일한 방식으로 리뷰하십시오. 특정 블록이 현재 작업에 직접적으로 기여하지 않는다면 제거하십시오. 도입부의 미사여구, 중복된 XML 래퍼(wrappers), 주제에서 벗어난 퓨샷(few-shot) 예시들을 제거하십시오. 모든 토큰은 그 자리에 있을 가치를 증명해야 합니다. 그 결과, 예산 내를 유지하면서 실제로 중요한 정보를 보존하는 에이전트를 얻을 수 있습니다.

추가 읽기를 위한 참고 문헌

이 가이드를 조사하는 동안 참고한 출처들입니다. 세부 사항을 검증하거나 더 깊이 파고들 수 있도록 포함하였습니다. 이 목록을 나열하는 것이 모든 문장을 독립적으로 팩트 체크했다는 주장은 아닙니다.

• AI 코딩 에이전트의 컨텍스트 부패(Context Rot): 정의 및 방지 방법
• LLM의 컨텍스트 창(Context Window)에 정보를 채워 넣는 것을 멈추세요, César Soto Valero 작성
• 컨텍스트 창의 함정: 왜 100만 토큰이 당신의 AI 에이전트를 구원하지 못하는가
• AI 에이전트는 100만 토큰의 컨텍스트 창이 있어도 잊어버립니다 - LinkedIn
• AI 에이전트를 위한 컨텍스트 엔지니어링(Context Engineering) 심층 분석 | clara 작성 | 2026년 5월 | Code Like A Girl

처음부터 직접 연결하는 대신 복사하여 붙여넣기를 선호하는 분들을 위해, 위의 설정을 바로 사용할 수 있는 키트인 — 부패하지 않는 컨텍스트 (12개 템플릿) (Context That Doesn't Rot (12 Templates)) — 로 패키징했습니다: https://unfairhq.gumroad.com/l/vszzu.