대형언어모델의 성능이 올라갈수록 애플리케이션과 하네스를 만드는 사람들은 오히려 예상치 못한 숙제를 떠안는다. 데이터 분석가이자 저술가인 드루 브루니그(Drew Breunig)는 AGNTCon에서 진행한 "Context Fails & Fixes" 강연을 통해 지난 한 해 맥락 엔지니어링(context engineering)이 어떻게 변해 왔고 앞으로 어디로 향할지를 정리했다. 그는 O'Reilly에서 준비 중인 책 『The Context Engineering Handbook』을 거론하며, 모델이 아무리 좋아져도 '무엇을 하고 무엇을 하지 말라'는 지시를 일관되고 잡음 없이 전달하는 일은 영원히 어려울 것이라고 말한다. 사람끼리도 의도를 정확히 전달하기 어려운데, 모델은 사람이 아니라 학습과 최적화 과정에서 비롯된 고유한 실패 양식을 갖기 때문이다.
'RAG는 죽었다'는 착각
한때 업계에는 컨텍스트 창을 충분히 키우면 인터넷 전체를 집어넣을 수 있고, 굳이 선별하거나 에이전트 시스템을 설계할 필요 없이 AI가 해결된다는 기대가 있었다. 이른바 'RAG는 죽었다'던 시기다. 실제로 Gemini 1.5를 기점으로 12만 8천 토큰 수준이던 컨텍스트 창은 100만 토큰대로 도약했고, 구글은 1천만 토큰 모델을 예고하기도 했다. 그러나 1천만 토큰을 먼저 내놓은 것은 Llama 4 Scout였는데, 추론 효율 문제로 기대에 못 미쳤고 널리 쓰이지 못했다. 결국 '모든 것을 컨텍스트에 넣고 모델이 알아서 정리하게 하라'는 전략은 환상에 가까웠다. 컨텍스트가 길어질 공간은 곧 더 많은 오류가 들어설 공간이기도 했다.
긴 맥락이 불러오는 네 가지 실패
브루니그는 긴 컨텍스트의 실패를 네 가지로 나눈다. 첫째, 맥락 오염(poisoning)은 환각이나 잘못된 사실이 컨텍스트에 끼어들어 모델이 그것을 떨치지 못하는 경우다. 둘째, 맥락 산만(distraction)은 컨텍스트가 지나치게 길어지면서 모델이 자신의 기반 지식보다 축적된 기록에 더 의존하는 현상이다. 셋째, 맥락 혼동(confusion)은 당면 문제와 무관한 사실이 끼어들어 모델이 사용자가 누구인지 멋대로 가정하게 만드는, 추적하기 까다로운 실패다. 넷째, 맥락 충돌(clash)은 도구 호출과 스킬 등 하네스 내부 정보가 서로 어긋나며 예상치 못한 방향으로 작동하는 경우다. 그는 ChatGPT나 Claude의 메모리 기능을 꺼 둔다고 밝혔는데, 업무 대화와 개인 프로젝트를 모델이 뒤섞어 기록하면서 혼란이 커지기 때문이다.
맥락 오염의 대표 사례로 그는 포켓몬을 든다. 1996년 게임보이용 포켓몬 레드에서는 목마른 경비원에게 레모네이드를 줘야 길을 통과할 수 있었지만, 2004년 게임보이 어드밴스용 파이어레드에서는 같은 장면이 아이스티로 바뀌었다. Gemini 2.5 기술 보고서에 따르면, 모델은 구버전을 플레이하면서도 가중치에 각인된 파이어레드의 '아이스티' 과제를 떠올려 경비원에게 차를 주려고 몇 시간을 허비했다. 한번 할 일 목록에 올라간 잘못된 정보를 모델이 스스로 지우지 못한 것이다.
맥락 산만을 보여주는 연구로는 카롤리나 카마사와 데릭 실러의 「Do as I Say, Not as I Do」가 인용된다. 연구진은 모든 질문에 러시아어로 답하라고 지시한 뒤, 대화 기록에는 프랑스어로 답한 예시들을 섞어 두었다. 그러자 Gemma 3 12B 같은 작은 모델은 상반된 예시가 몇 개만 쌓여도 지시를 따르는 비율이 절반 아래로 떨어졌고, 성능이 뛰어난 Opus 4.6조차 예시가 많아지면 같은 현상을 보였다. Gemini 2.5 역시 포켓몬 플레이에서 컨텍스트가 10만 토큰을 크게 넘어서자 새 계획을 세우기보다 과거 행동을 반복하기 시작했다고 보고서 부록에 적혀 있다.
여섯 가지 도구와 실무적 함의
다행히 대응 도구는 비교적 정립되어 있고, 새로운 문제가 생겨도 이 목록은 크게 변하지 않았다. 관련 정보를 끌어오는 맥락 증강(RAG·스킬), 모델에 노출할 도구와 스킬을 선별하는 툴 로드아웃, 빈 기록에서 시작하는 하위·동료 에이전트를 활용한 맥락 격리, 불필요해진 도구 결과를 덜어내는 맥락 가지치기, 마크다운이나 데이터베이스에 정보를 보관하는 맥락 오프로딩, 그리고 압축(compaction)으로 알려진 맥락 요약이 그것이다. 브루니그는 한 기업이 엔지니어마다 600개의 스킬을 시작 시점에 모두 불러오면서 에이전트 성능이 급락했고, 로드아웃 함수로 걸러내 해결한 사례를 전한다.
그는 이런 패턴이 생각보다 단순하다는 점을 DSPy로 보여준다. 에이전트는 결국 입력을 ReAct 모듈에 넘기고 누적된 기록을 이어가는 while 루프이며, 큰 모델로 Claude Sonnet 4.5를, 빠른 판단용 소형 결정 모델로 'Jev'를 둔다. 도구가 필요한지 하나씩 물어 선별하고, 각 대화 turn이 아직 필요한지 판단해 잘라내며, 압축 전에 무엇이 중요한지 먼저 가려낸 뒤 요약하는 식이다. 네 가지 수정과 하나의 루프를 더해도 약 16줄 수준이라는 것이 그의 설명이다. 실무자 입장에서 더 유용한 교훈은 맥락 관리가 '기술 부족'이 아니라 '설계 선택'의 문제라는 점이다. 그는 코딩 작업 중 컨텍스트가 20만~30만 토큰에 이르면 큰 작업을 앞두고 새로 리셋한다고 밝혔는데, 이는 100만 토큰을 끝까지 채우는 것이 오히려 품질을 떨어뜨릴 수 있다는 경험적 신호다.
정작 어려운 것은 기술이 아니라 언어라고 그는 짚는다. 용어와 개념이 날마다 바뀌어 따라잡기 힘들다는 것이다. 다만 이 글이 다루지 않은 맥락 혼동의 작동 메커니즘처럼 아직 충분히 규명되지 않은 영역이 남아 있고, DSPy 예시의 소형 결정 모델 구성도 범용 해법이라기보다 시연을 위한 단순화라는 점은 감안해야 한다. 그는 "미래가 만들어지는 곳을 알고 싶다면 새로운 언어가 발명되고 변호사가 모여드는 곳을 보라"는 스튜어트 브랜드의 말을 인용하며 강연을 맺는다. 맥락 엔지니어링이 여전히 언어가 끓어오르는 최전선에 있다는 뜻이다.