에이전트가 '멍청해진다'는 건 비유가 아니다
AI 에이전트를 프로덕션에 붙여본 팀이라면 한 번쯤 이 경험을 한다. 처음 몇 턴은 날카롭다. JSON으로 응답하라는 지시를 잘 따르고, 이전 결정을 일관되게 유지한다. 그런데 대화가 30~40턴을 넘어가는 순간, 에이전트는 자기가 5턴 전에 한 말을 모순하고, 포맷 지시를 슬그머니 어기고, 출력 품질이 눈에 띄게 떨어진다. 버그가 아니다. 구조적 필연이다.
dev.to에 올라온 'Context rot: why your AI agent gets dumber the longer it runs'는 이 현상에 이름을 붙인다. 컨텍스트 rot(context rot)—누적된 대화 히스토리가 컨텍스트 윈도우를 오염시키면서 에이전트 성능이 점진적으로 저하되는 현상이다. LLM에는 호출 간 영구 메모리가 없다. 매 요청마다 제공된 토큰 시퀀스 전체를 새로 추론한다. 즉, '기억'의 실체는 컨텍스트 윈도우 그 자체다.
왜 길어질수록 나빠지는가: 네 가지 실패 모드
구조를 이해하면 대응이 보인다. 컨텍스트가 누적될수록 나타나는 실패 모드는 크게 네 가지다.
첫째, 최근성 편향. Transformer 어텐션은 컨텍스트 전체에 균등하게 분산되지 않는다. 가장 최근 토큰과 컨텍스트 맨 앞쪽에 가중치가 집중된다. 3턴에 박아둔 중요한 지시사항이 35턴에는 사실상 '보이지 않는' 상태가 된다. 이른바 'lost in the middle' 현상이다.
둘째, 지시 희석. 시스템 프롬프트에 "항상 JSON으로 응답하라"고 적혀 있어도, 20턴 동안 자연어 산문으로 응답한 예시가 쌓이면 모델의 사전 분포가 산문 쪽으로 흘러간다. 명시적 지시보다 누적된 예시가 더 강한 신호가 되는 것이다.
셋째, 낡은 상태 오염. 8턴에서 내린 결정이 당시 사실 기반으로는 옳았더라도, 30턴에서는 그 사실이 이미 바뀌어 있을 수 있다. 문제는 8턴의 추론이 컨텍스트에 여전히 남아 이후 모든 추론에 조용히 영향을 미친다는 점이다.
넷째, 토큰 예산 압박. 컨텍스트가 모델의 최대 한도에 가까워지면 모델은 스스로 추론을 축약하고, 출력을 짧게 자르기 시작한다. 품질 저하가 아니라 물리적 한계다.
대규모 코드베이스에서는 시작부터 터진다
컨텍스트 rot이 '오래 돌린 에이전트'의 문제라면, 코드베이스 규모는 '시작부터' 컨텍스트를 낭비하게 만드는 문제다. 같은 dev.to에 올라온 'Context OS' 프로젝트는 이 두 번째 문제를 정면으로 다룬다.
Claude나 Copilot에 작업을 넘길 때 팀은 보통 세 가지 중 하나를 선택한다. 관련 없는 파일까지 통째로 붙여 넣어 컨텍스트 윈도우의 80%를 태우거나, 파일을 직접 골라 넣다가 결정적인 import 하나를 빠뜨리거나, 더 큰 컨텍스트 윈도우를 돈 주고 사서 같은 문제를 더 큰 스케일로 반복하거나. 세 선택지 모두 근본 해결책이 아니다.
ContextOS는 이 문제를 'AI 에이전트와 레포 사이의 지능형 컨텍스트 레이어'로 접근한다. 작업 설명을 입력하면 키워드 매칭, import 그래프 중심성, AST 심볼 오버랩, git 변경 빈도, 시크릿 파일 패널티 다섯 가지 신호를 조합해 실제로 필요한 파일만 추려 패킹한다. LLM 호출 없이, 로컬에서, 오프라인으로 동작한다는 점이 실용적이다. 보고된 토큰 절감 수치는 최대 87%—이건 단순한 최적화가 아니라 컨텍스트 설계 문제를 도구로 해결한 사례다.
팀이 당장 적용할 수 있는 세 가지 패턴
두 기사가 수렴하는 지점이 있다. 컨텍스트는 흘러가는 대로 두면 안 된다. 설계의 대상이다. 실전에서 쓸 수 있는 패턴 세 가지를 정리하면:
패턴 1: 슬라이딩 윈도우 + 요약 압축. 전체 대화 히스토리를 그대로 넘기지 않는다. 최근 N턴만 원문으로 유지하고, 그 이전 히스토리는 저렴한 모델(예: claude-haiku 계열)로 압축 요약한다. 결정 사항, 확인된 사실, 미해결 질문만 추려 구조화된 요약으로 주입한다. 비용 대비 효과가 가장 빠르게 나오는 방식이다.
패턴 2: 원시 히스토리 대신 상태 추출. 장기 실행 에이전트라면 대화 히스토리를 쌓는 대신 매 턴마다 구조화된 상태를 추출해 주입하는 방식이 옳다. 컨텍스트 크기가 대화 길이에 비례해 커지지 않고, 상태 크기에 비례해 일정하게 유지된다. 아키텍처 변경이 필요하지만, 장시간 에이전트 루프에서는 유일하게 지속 가능한 패턴이다.
패턴 3: 핵심 지시사항 재앵커링. 컨텍스트 구조를 바꾸기 어려운 상황이라면, 중요한 지시사항을 매 10턴마다 또는 위반이 감지될 때 재주입한다. 모든 턴에 넣으면 토큰 낭비지만, 주기적 재앵커링은 '지시 희석' 문제에 빠르게 대응하는 현실적인 임시 방편이다.
시사점: 에이전트 품질은 모델이 아니라 컨텍스트 설계가 결정한다
더 강한 모델로 바꾸면 해결될 것 같지만, 구조적 문제는 모델 업그레이드로 사라지지 않는다. 컨텍스트 윈도우가 커져도 'lost in the middle' 현상은 남고, 노이즈가 많은 컨텍스트에서 좋은 추론을 기대하기 어렵다는 사실도 변하지 않는다.
팀이 AI 에이전트를 프로덕션 워크플로우에 붙이는 순간, 컨텍스트 관리는 선택 사항이 아니라 운영 필수 항목이 된다. '에이전트가 요즘 왜 이렇게 이상하지?'라는 질문이 나오기 전에, 컨텍스트 rot 탐지 루틴과 슬라이딩 윈도우 전략을 팀 표준 워크플로우에 넣어두는 것이 맞다.
전망: 컨텍스트 엔지니어링이 프롬프트 엔지니어링을 대체한다
짧은 일회성 프롬프트 시대에는 프롬프트를 잘 쓰는 것이 전부였다. 에이전트가 장기 실행되고, 코드베이스와 연결되고, 여러 도구를 호출하는 시대로 넘어오면서 '무엇을 넣을 것인가'보다 '무엇을 넣지 않을 것인가'가 더 중요한 설계 질문이 됐다.
ContextOS처럼 컨텍스트 패킹을 도구화하는 시도, 그리고 상태 추출과 윈도우 압축을 아키텍처 패턴으로 표준화하는 움직임은 앞으로 AI-First 팀의 기본 인프라가 될 가능성이 높다. 에이전트 성능의 천장은 모델이 아니라, 그 모델에게 무엇을 얼마나 깔끔하게 제공하는가에서 결정된다.