코딩 에이전트와 한 세션에서 몇 시간째 작업하다 보면 어느 순간 모델이 둔해졌다는 느낌이 든다. 방금 고친 함수를 다시 고치겠다고 나서거나 아까 실패한 방법을 그대로 또 시도한다. 컨텍스트는 80만 토큰에 가까워졌지만 최대 100만 토큰까지 들어간다니 아직 여유가 있다고 믿고 계속 대화를 이어 가게 된다.
이럴 때 흔히 “모델이 너프된 것 아니냐”는 불평이 나오지만 실제로는 모델이 멍청해진 게 아니라 길어진 대화 이력이 모델을 엉뚱한 쪽으로 끌고 가는 경우가 대부분이다. 오라일리에서 『The Context Engineering Handbook』을 준비 중인 드류 브루니그(Drew Breunig)는 2026년 10월 AGNTCon에서 「Context Fails & Fixes」라는 발표를 했고 10월 24일 자기 블로그에 슬라이드와 발표록을 올렸다. 2024년 말부터 지금까지 컨텍스트를 다루는 방식이 어떻게 바뀌었는지 한눈에 짚어 주는 기록이다.
흐름의 뼈대는 단순하다. 모델 제작사가 새 능력을 내놓을 때마다 그 능력이 새로운 실패 유형을 만들고 모델을 감싸서 도구와 입력을 관리하는 바깥 프로그램인 ‘하네스(harness)’가 그 수습을 떠맡아 왔다는 것이다. 100만 토큰짜리 긴 컨텍스트가 처음 나왔을 때도 그랬고 오래 달리는 에이전트 모델이 등장한 지금도 똑같은 일이 벌어지고 있다.
백만 토큰 컨텍스트가 약속한 것과 실제로 벌어진 일
2024년 말에는 “RAG(필요한 문서 조각만 찾아 프롬프트에 넣어 주는 기법)는 죽었다”는 말이 한창이었다. 모델이 한 번에 읽는 컨텍스트 창만 충분히 키우면 자료를 통째로 넣으면 그만이니 무엇을 골라 넣을지 고민할 필요도 없고 에이전트 시스템을 지을 필요도 없다는 기대였다. 모델 제작사들도 그쪽을 겨냥해 Gemini 1.5를 시작으로 약 12만 8천 토큰이던 컨텍스트 창을 100만 토큰으로 단숨에 키웠고 홍보 자료에는 연구실에 1천만 토큰짜리 모델이 있다는 예고까지 붙었다.
그 1천만 토큰은 Llama 4 Scout가 먼저 들고 나왔지만 추론 비용이 발목을 잡아 널리 쓰이지 못했다. 그래도 100만 토큰은 남았으니 전부 넣고 보자는 분위기가 이어졌다. 문제는 컨텍스트가 커진 만큼 틀린 정보나 잡음이 들어갈 자리도 함께 커졌다는 점이다.
긴 컨텍스트에서 나타나는 실패는 네 가지로 나뉜다. 환각이나 틀린 사실이 한 번 컨텍스트에 들어간 뒤 모델이 거기서 벗어나지 못하는 ‘오염(poisoning)’, 컨텍스트가 너무 길어져 모델이 원래 학습한 지식보다 눈앞의 이력에 기대기 시작하는 ‘주의 분산(distraction)’, 지금 문제와 상관없는 정보가 섞여 들어와 답을 엉뚱한 방향으로 비트는 ‘혼동(confusion)’, 그리고 도구 호출과 스킬, 하네스 안의 정보가 서로 어긋나며 발목을 잡는 ‘충돌(clash)’이다.
포켓몬 레드의 레모네이드와 파이어레드의 아이스티
컨텍스트 오염을 가장 잘 보여 주는 사례는 포켓몬 실험이다. 1996년 게임보이용 포켓몬 레드와 2004년 게임보이 어드밴스용 파이어레드는 그래픽과 소리만 다듬었을 뿐 거의 같은 게임이다. 둘 다 경비원에게 마실 것을 줘야 지나갈 수 있는데 원작에서는 레모네이드를 주고 파이어레드에서는 아이스티를 준다. Gemini 2.5 기술 보고서에 실린 실험에서 모델은 원작을 플레이하면서도 아이스티를 구해야 한다고 거듭 확신했다. 모델의 학습 가중치(훈련 과정에서 저장된 지식)에 있던 파이어레드 정보가 컨텍스트로 흘러나와 할 일 목록에 박히자 거기서 빠져나오지 못한 것이다.
It spent hours trying to find or give the guard tea. Once it had been added to its to-do list, the model could not get past it.
주의 분산 현상은 카롤리나 카마사와 데릭 실러의 논문 「Do as I Say, Not as I Do」에서 실험으로 확인됐다. 모델에게 “모든 질문을 러시아어로 번역해 답하라”고 지시한 다음 대화 이력에 프랑스어로 답한 예시를 잔뜩 깔아 두었다. 지시가 바뀐 것도 아니고 그저 과거 예시만 쌓였는데도 그 수가 늘수록 모든 모델이 지시를 덜 따랐다. Gemma 3 12B 같은 작은 모델은 어긋난 예시 몇 개만으로 지시 준수율이 절반 아래로 떨어졌고 Opus 4.6은 훨씬 오래 버텼지만 예시가 계속 쌓이자 결국 같은 일이 벌어졌다.
Gemini 2.5 보고서 부록에도 같은 맥락의 관찰이 실려 있다. 컨텍스트가 10만 토큰을 크게 넘어서면 에이전트가 새 계획을 세우는 대신 이전 이력에 있던 행동을 그대로 반복하기 시작했다는 기록이다. 브루니그 자신은 컨텍스트가 20만에서 30만 토큰 사이에 이르면 상태를 살피고 큰 작업을 앞두고 있으면 아예 새로 시작한다. 정작 발표장 청중에게 물었을 때는 절반 가까이가 100만 토큰까지 채워 쓴다고 손을 들었다.
하네스로 옮겨간 여섯 가지 처방
다행히 대응 도구는 일찍 자리를 잡았고 새 문제가 나타난 뒤에도 이 여섯 가지 목록은 바뀌지 않았다. 필요한 정보를 밖에서 끌어오는 쪽에는 RAG와 스킬처럼 관련 자료를 가져오는 ‘컨텍스트 보강(augmentation)’과 이번 작업에 쓸 도구만 골라 노출하는 ‘도구 선별(loadout)’이 있다. 실제로 어느 기업 팀의 에이전트가 갑자기 엉망이 된 원인을 파고들었더니 시작할 때마다 스킬 600개를 한꺼번에 불러오고 있었다. 별도 작업은 빈 대화 이력을 가진 서브에이전트에게 맡겨 본체의 컨텍스트를 지키는 ‘격리(quarantine)’도 함께 쓰인다.
나머지 셋은 쌓인 컨텍스트를 덜어내는 기술이다. 더 필요 없는 이전 턴을 잘라 내는 ‘가지치기(pruning)’는 Claude Code와 Codex가 사용자가 눈치채지 못하는 사이에 오래된 도구 실행 결과를 지우는 방식으로 이미 돌아가고 있다. 당장 안 쓰는 정보를 마크다운 파일이나 데이터베이스에 내려놓고 나중에 다시 꺼내 쓰는 ‘외부 저장(offloading)’, 그리고 흔히 컴팩션이라 부르는 대화 이력 ‘요약(summarization)’이 뒤를 받친다.
이 여섯 가지는 구현도 단순하다. 브루니그가 든 DSPy 예제에서 기본 에이전트는 요청을 받아 ReAct 모듈에 넘기고 쌓이는 이력을 다음 턴으로 전달하는 열두 줄짜리 while 루프다. 여기에 작은 판단용 모델로 필요한 도구만 고르는 선별 함수, 도구로 노출한 서브에이전트, 턴마다 불필요한 이력을 자르는 가지치기, 오래된 턴을 요약으로 바꾸는 컴팩션까지 네 가지를 더해도 코드는 열여섯 줄 안팎만 늘어난다.
용어도 이 흐름을 따라 바뀌었다. 2023년에는 입력 문구를 다듬는다는 뜻에서 프롬프트 엔지니어링이라 불렀고 2025년에는 시스템이 실행 중에 맥락을 조립한다는 뜻에서 컨텍스트 엔지니어링이라 불렀다. 이제 그 도구들이 코드 안으로 옮겨가면서 하네스 엔지니어링이라는 말이 붙었다. 이름은 바뀌었지만 방향은 같다. 컨텍스트를 조립하는 일을 그때그때 결과가 달라지는 확률적인 모델 호출에서 언제나 똑같이 동작하는 결정론적인 코드로 옮기는 것이다.
오래 달리는 에이전트가 새로 만든 실패 두 가지
2026년에 들어서는 컨텍스트 창을 키우는 대신 모델이 하네스를 직접 다루며 자기 컨텍스트를 스스로 관리하게 가르치는 쪽으로 목표가 옮겨갔다. AI 평가 기관 METR 측정으로 GPT-5는 3.4시간짜리 작업을, Gemini 3.1은 6.4시간짜리 작업을 혼자 다룰 수 있었고 Opus 4.6은 12시간 안팎까지 올라왔다. 하지만 이 방향도 새로운 실패 유형 두 가지를 데려왔다.
하나는 ‘가중치와의 싸움(fighting the weights)’이다. 하네스를 잘 쓰도록 훈련할수록 모델은 훈련에 쓰인 특정 도구와 환경에 과적합된다. Haiku처럼 작은 모델이 브라우저 제어용 Playwright MCP 서버를 부를 때 첫 시도에서 잘못 호출했다가 오류를 보고 고쳐 부르는 모습이 그 증상이다. 모델 제작사도 예외가 아니어서 Claude Code 시스템 프롬프트는 독립적인 도구 호출을 동시에 하라는 지시를 일곱 번, 네 번, 두 번, 세 번 거듭 반복한다. 훈련 환경이 오랫동안 도구를 하나씩 순서대로 부르는 직렬 방식이었던 탓이다. 시스템 프롬프트에 같은 말의 반복과 대문자 강조가 보인다면 학습된 가중치의 버릇과 싸우고 있을 가능성이 크다.
다른 하나는 ‘컨텍스트 관성(context inertia)’이다. 모델이 처음 세운 가설이나 하위 작업에 지나치게 매달려 멈춰야 할 시점을 지나서도 계속 밀어붙이는 현상으로 발표 직전 한 주 동안에만 네 곳이 같은 결과를 내놓았다. Anthropic은 모델의 자기 복제 가능성을 시험하는 Memento 하네스에서 에이전트가 오래 달리면 해법 하나에 고착되어 같은 시도를 되풀이하는 현상을 확인했다. 처방은 간단해서 한 시간 반마다 에이전트가 짧은 인수인계 메모를 남기고 컨텍스트를 비우게 했다. 환경과 결과물은 그대로 남지만 대화 이력은 사라져 새 눈으로 다시 시작한다. Microsoft Research의 「Fork-and-Flush」도 성능 곡선이 큰 도약 뒤 평평해지는 구간을 뜯어봤더니 에이전트가 아이디어 하나에 집착해 작은 수정만 반복하고 있었다고 짚었고 UC 버클리 샹인 탄 연구팀의 「Scaling Discovery Requires Forgetting」 역시 산출물은 남기고 컨텍스트만 주기적으로 비울 때마다 성능이 한 계단씩 올랐다고 보고했다.
새로 훈련된 모델의 새 문제인데도 해결 도구는 격리와 외부 저장, 이력 삭제라는 예전 그대로다. 요즘 누군가 “코딩 에이전트가 이상하다”고 말할 때 브루니그가 되묻는 질문도 하나다. 컨텍스트가 얼마나 쌓였느냐고 물어서 80만 토큰이라는 답이 돌아오면 당장 지우라고 권한다. 그에게 20만 토큰은 경고선이다.
어디까지 코드로 정하고 어디서부터 모델에게 맡길 것인가
다음 문제가 어디서 나올지도 조짐이 보인다. Hermes나 OpenClaw처럼 스스로 스킬을 만들어 기억에 쌓는 개인 에이전트를 여섯 달 넘게 돌려 본 사람은 아직 드물다. 브루니그가 여섯 달째 써 온 Hermes 에이전트를 들여다봤더니 에이전트가 만들고 고쳐 온 스킬의 해법이 갈수록 나빠지고 있었다. 비슷한 문제를 매번 조금씩 다른 방식으로 풀면서 기묘한 땜질이 쌓이고 옛 기억과 새 지시가 서로 부딪히기 시작한 것이다. 기억에 공을 들일수록 무엇을 언제 잊을지 정하는 ‘전략적 망각’도 함께 풀어야 하는데 아직 답을 낸 곳은 없다.
결국 우리가 보는 출력은 모델의 가중치와 지금 넣어 준 컨텍스트가 맞물린 결과다. 모델이 무엇으로 훈련됐는지는 기술 보고서로 파악해 두고 제품을 만드는 쪽이 실제로 손댈 수 있는 영역은 어떤 컨텍스트를 조립해 넣을지뿐이다. 에이전트가 헤맬 때 더 큰 모델을 쓰거나 더 오래 생각하게 하거나 컨텍스트를 고치는 세 길 가운데 싸고 빠른 쪽은 컨텍스트를 고치는 길 하나뿐이다.
Our job is to choose when to be deterministic (what to put in code) and when to be probabilistic (when to let the model drive).
컨텍스트 창이 커져도 틀린 사실 하나에 고착되는 문제는 사라지지 않았고 모델이 하네스를 직접 다루게 되자 이번에는 멈출 줄 모르는 관성이 생겼다. 다음 능력이 또 어떤 낯선 문제를 들고 오더라도 어디까지를 결정론적인 코드에 못 박고 어디서부터 확률적인 모델에게 맡길지 경계를 긋는 일만큼은 계속 사람의 몫으로 남는다.
출처: Drew Breunig, The State of Context Engineering, 2026년 10월 24일.