AI 에이전트를 실제 운영 환경(production)에서 몇 주 동안 실행해 보면 다음과 같은 현상을 발견하게 될 것입니다. 에이전트와 나누는 새로운 대화는 매우 날카롭고 명확합니다. 하지만 동일한 에이전트에게 40개의 메시지 이력을 제공하면, 이전의 결정을 번복하거나, 제약 사항을 잊어버리며, 세션 시작 시점보다 더 나쁜 결과물을 만들어내기 시작합니다.

이는 무작위적인 현상이 아닙니다. 구조적인 문제입니다. 컨텍스트 윈도우 (Context window)는 고정된 크기의 작업 메모리이며, 당신은 그곳을 노이즈로 채우고 있는 것입니다.

저는 이를 '컨텍스트 부패 (Context rot)'라고 부릅니다. 즉, 누적된 컨텍스트가 오래된 데이터, 반복되는 상용구(boilerplate), 그리고 무관한 대화 내용으로 인해 신호(signal)를 밀어내면서 에이전트의 성능이 점진적으로 저하되는 현상을 말합니다. 여기에서 그 원인이 무엇인지, 어떻게 측정하는지, 그리고 이를 진정으로 해결할 수 있는 세 가지 패턴을 소개합니다.

실제로 일어나고 있는 일

언어 모델 (Language models)은 호출 간에 지속적인 메모리를 갖지 않습니다. 모든 요청은 당신이 제공하는 전체 토큰 시퀀스에 대한 새로운 추론 (inference)입니다. '메모리'는 전적으로 컨텍스트 윈도우 (context window)에 의존합니다.

대화가 길어짐에 따라 다음과 같은 몇 가지 실패 모드 (failure modes)가 발생합니다:

1. 어텐션 (Attention)에서의 최신성 편향 (Recency bias). 트랜스포머 (Transformer)의 어텐션은 컨텍스트 전체에 균일하게 분포되지 않습니다. 경험적으로 모델은 중간 부분보다 최근의 토큰과 컨텍스트의 맨 앞부분에 더 큰 가중치를 두는 경향이 있으며, 이는 종종 "중간에서 길을 잃는 (lost in the middle)" 현상이라고 불립니다. 3번째 턴(turn)에서의 중요한 지침이 35번째 턴에 이르면 기능적으로 보이지 않게 될 수 있습니다.

2. 지침 희석 (Instruction dilution). 당신의 시스템 프롬프트 (system prompt)가 "항상 JSON으로 응답하라"고 말하고 있다고 가정해 봅시다. 20번째 턴에 이르면, 모델이 산문(prose)으로 응답한 사례가 19개나 쌓여 있을 수 있습니다 (사용자가 자연어로 후속 질문을 했기 때문입니다). 이러한 산문 예시들은 가중치를 가집니다. 모델의 사전 확률 (priors)이 변하는 것입니다.

3. 오래된 상태 오염 (Stale state pollution). 에이전트는 8번째 턴에서 당시에는 사실이었던 정보에 기반하여 결정을 내렸습니다. 30번째 턴에 이르면 그 사실들은 변했지만, 8번째 턴의 추론 과정은 여전히 컨텍스트에 남아 하류(downstream)의 모든 것에 조용히 영향을 미칩니다.

4. 토큰 예산 압박 (Token budget pressure). 컨텍스트가 모델의 최대 한도에 도달할수록, 모델은 제한 범위 내에 머물기 위해 스스로의 추론을 생략하거나, 요령을 피우거나, 더 짧고 품질이 낮은 출력을 생성하기 시작할 수 있습니다.

이를 감지하는 방법

어떠한 해결책을 적용하기 전에, 실제로 컨텍스트 부패 (Context rot)가 발생하고 있는지 확인하십시오. 가장 간단한 테스트 방법은 다음과 같습니다:

import anthropic

client = anthropic.Anthropic()
...

실제 에이전트 시스템 프롬프트(system prompt)와 현실적인 대화 기록(conversation history)을 대상으로 이를 실행해 보십시오. 만약 지시 이행 (instruction-following) 능력이 10~15턴 이후부터 저하된다면, 컨텍스트 관리 방식을 개선해야 합니다.

해결책 1: 요약을 활용한 슬라이딩 윈도우 (Sliding window with summaries)

가장 간단한 해결책은 전체 대화 기록을 모두 유지하지 않는 것입니다. 가장 최근의 N개 턴을 유지하는 롤링 윈도우 (rolling window)를 구성하고, 그 윈도우 이전의 모든 내용은 압축된 요약본으로 유지하십시오.

from dataclasses import dataclass

@dataclass
...

claude-haiku-4-5를 이용한 압축 단계는 비용이 매우 적게 듭니다 (압축된 메시지는 저렴한 입력 토큰이며, 출력 또한 짧습니다). 이를 통해 얻는 이점은 고가의 모델이 40턴 분량의 데이터 덤프가 아닌, 깨끗하고 집중된 컨텍스트 위에서 항상 작동하게 된다는 점입니다.

해결책 2: 원시 기록 대신 상태 추출 (State extraction instead of raw history)

작업 진행 상황, 사용자 선호도, 수집된 데이터 등 상태 (state)를 추적하는 에이전트의 경우, 원시 대화 기록을 그대로 저장하는 것은 잘못된 추상화입니다. 매 턴이 끝난 후 상태를 명시적으로 추출하여 구조화된 데이터 (structured data)로 주입하십시오.

STATE_SCHEMA = """
{
  "task_status": "in_progress" | "complete" | "blocked",
...

이는 더 어려운 아키텍처적 전환이지만, 장기 실행 워크플로우 (long-running workflows)를 위해서는 올바른 방향입니다. 각 턴에서의 컨텍스트는 대화 길이 $O( ext{conversation length})$가 아닌 상태 크기 $O( ext{state size})$가 됩니다. 상태 크기는 대략 일정하게 유지되지만, 대화 길이는 무한히 늘어납니다.

해결책 3: 핵심 지침 재고정 (Re-anchor critical instructions)

컨텍스트 관리 구조를 재편성할 수 없는 더 단순한 사례의 경우, 가장 중요한 지침들을 주기적으로 다시 주입하는 것이 빠른 해결책입니다. 매 턴마다 수행하는 것이 아니라 (이는 토큰을 낭비합니다), N번째 턴마다 또는 모델이 제약 사항을 위반하는 것이 감지될 때 수행하십시오.

CRITICAL_INSTRUCTIONS = """
타협 불가능한 규칙 재확인:
1. 항상 정의된 스키마와 일치하는 유효한 JSON으로 응답하십시오.
...

이는 적절한 컨텍스트 관리 (Context management)에 비하면 임시방편에 불과하지만, 효과가 있으며 20분 내에 구현 가능한 임시방편입니다.

적절한 해결책 선택하기

시나리오	최적의 해결책
채팅 에이전트, 가변적인 세션 길이	슬라이딩 윈도우 (Sliding window) + 압축
...

프로덕션 에이전트의 경우, 저는 보통 슬라이딩 윈도우와 상태 추출 (State extraction)을 결합하여 사용합니다. 슬라이딩 윈도우는 자연스러운 흐름을 위해 최근의 턴들을 있는 그대로 유지하고, 구조화된 상태 객체 (Structured state object)는 실제로 유지되어야 하는 정보를 추적합니다. 이렇게 하면 컨텍스트가 예측 가능한 크기를 넘어 성장하지 않습니다.

근본적인 원리

컨텍스트 윈도우 (Context window)는 로그 파일이 아닙니다. 그것은 작업 기억 (Working memory)입니다. 작업 기억은 잘 큐레이션되었을 때 가장 잘 작동합니다. 즉, 신호 (Signal)는 밀도 있게 채우고, 노이즈 (Noise)는 제거하며, 가장 중요한 정보는 주의 (Attention)가 자연스럽게 머무는 곳(처음과 끝)에 배치해야 합니다.

컨텍스트 윈도우를 채팅 기록처럼 취급하여 무제한으로 성장하게 두는 것은 에이전트 개발에서 가장 흔히 발생하는 컨텍스트 관리 실수입니다. 모델은 히스토리가 많아진다고 해서 더 똑똑해지지 않습니다. 오히려 더 느려지고, 비용이 많이 들며, 더 혼란스러워질 뿐입니다.

조기에 가지치기(Prune)하고, 자주 압축(Compress)하며, 상태(State)를 명시적으로 추출하십시오.

무료 Reliable Agent Field Guide에서는 컨텍스트 관리, 신뢰성 패턴 (Reliability patterns), 그리고 프로덕션 배포에 대해 더 심도 있게 다룹니다: penloomstudio.com/field-guide.html