당신의 AI 에이전트는 모든 걸 잊는다: 컨텍스트 비대를 고치는 MCP 기법

아무도 광고하지 않는 문제

AI 코딩 에이전트 데모는 늘 똑같다. 깔끔한 터미널, 명확한 지시, 정돈된 결과. 하지만 3시간째의 모습을 보여주는 사람은 없다. 그 시점에 에이전트는 파일 마흔 개를 읽고, 테스트 스위트를 열댓 번 돌렸으며, 지금까지 실행한 모든 명령의 소음 섞인 출력으로 컨텍스트 윈도우를 가득 채운 상태다. 그 지점에서 에이전트는 더 똑똑해지지 않는다. 오히려 둔해지고, 잘 잊어버리며, 이미 끝낸 작업을 자신 있게 반복한다.

이것은 에이전트 코딩에서 가장 눈에 안 띄고 가장 보편적인 문제다. 컨텍스트는 에이전트의 작업 기억이며 유한하다. 에이전트가 읽는 모든 것이 같은 공간을 두고 경쟁하고, 그 대부분은 쓰레기다. 빌드 로그, 스택 트레이스, 디렉터리 목록, 한 줄만 필요했는데 전문을 읽어들인 파일들. 윈도우는 침전물로 차오르고, 애초에 에이전트를 쓸모 있게 만들었던 추론 능력은 밀려난다.

이 문제를 고치는 도구는 벤치마크 비교에서 이기는 부류의 도구가 아니다. 배관이다. 그리고 이번 10월, GitHub 트렌드에 오른 것은 바로 그 배관이었다.

도구 출력 sandboxing의 발상

떠오른 프로젝트 중 특히 흥미로운 하나는 코딩 에이전트용 컨텍스트 최적화 계층으로, 문제의 근원을 공략한다. 대표적인 숫자는 모델에 도달하는 도구 출력량이 약 98% 줄어든다는 것이다.

메커니즘은 개념상 단순하다. 명령의 원시 출력을 대화로 그대로 쏟아붓는 대신, sandbox 안에서 실행하고 결과에서 모델이 필요로 하는 것만 건넨다. 요약, 종료 상태, 쿼리에 일치한 특정 줄들. 전체 기록은 모델이 원할 때 직접 가져올 수 있게 남아 있지만, 혹시나 관련 있을까 봐 윈도우 자리를 차지하고 있지는 않는다.

이는 유능한 엔지니어가 습관적으로 지키는 규율과 같다. 오류 한 줄이 핵심이라면 로그 전체를 채팅에 붙여넣지 않는다. 제멋대로 놔둔 에이전트는 정확히 그 반대를 한다.

여기엔 청구서가 따라온다. 그래서 이 도구들이 단순한 엔지니어링 사치가 아닌 것이다. 컨텍스트 윈도우는 공짜가 아니다. 모델이 처리해야 하는 모든 토큰은 돈과 시간을 먹고, 기억해야 하는 모든 토큰은 주의를 먹는다. 빌드 출력 10만 토큰을 세션에 쏟아붓는 도구는 당신에게 두 번 청구한다. 토큰 값으로 한 번, 신호가 묻혀서 모델의 판단력이 떨어지는 값으로 또 한 번. 이 98% 감소는 실은 비용 절감 옷을 입은 품질 개선이다.

세션보다 오래 사는 기억

문제의 나머지 절반은 에이전트가 세션 안에서만이 아니라 세션을 넘어서도 잊는다는 점이다. 터미널을 닫으면 컨텍스트는 사라진다. 다음 날 다시 열어도 에이전트는 당신이 무엇을 결정했고, 어떤 접근을 버렸고, 코드가 왜 지금 모습인지 전혀 모른다. 당신은 다시 설명하고, 에이전트는 다시 도출하며, 어디선가 같은 결정이 두 번 내려진다.

이 영역의 영속 메모리 도구들은 서로 다른 접근을 취한다. 가장 눈에 띄는 하나는 세션 동안 에이전트가 한 일을 포착하고, 모델로 압축한 뒤, 관련된 부분을 앞으로의 세션에 주입한다. 홍보 문구는 화려하지 않지만 맞다. 프로젝트의 윤곽을 기억하는 에이전트가 단일 작업에서 약간 더 똑똑한 에이전트보다 가치 있다. 주요 모델 벤더들도 같은 방향으로 움직여, subagent가 부모 대화보다 더 일찍 자기 context를 압축할 수 있는 손잡이를 추가했다. 전혀 필요 없는 작업에 세션 전체의 이력을 끌고 들어가지 않기 위해서다.

여기서 흥미로운 설계 질문은 무엇을 기억할지다. 모든 것을 기억하면 원래 문제를 더 느린 형태로 다시 만든 셈이다. 너무 적게 기억하면 기억은 쓸모없다. 탄력을 받는 프로젝트는 선택적으로 기억하는 쪽이다. 지난 한 달의 좋은 요약이 지난 한 시간의 완벽한 기록을 이긴다는 이론이다.

컨텍스트 전략으로서의 routing

퍼즐의 세 번째 조각은 routing이다. 작업이 실행되기 전에 어떤 모델과 어떤 도구가 필요한지 정해서, 결코 쓰지 않을 능력으로 채워지지 않게 하는 것. 열일곱 가지 서로 다른 통합을 안내받은 모델은 작업이 그중 하나만 필요해도 열일곱 가지 모두에 컨텍스트를 쓴다. 플랫폼 전반에서 routing을 강제하는 것은 인프라 세부사항처럼 들린다. 실상은 변장한 컨텍스트 예산 결정이다.

여기서 문제는 캐싱 문제로 보이기를 멈추고 시스템 설계로 보이기 시작한다. 에이전트의 컨텍스트 윈도우는 자원이며, 메모리와 디스크가 자원인 것과 같다. 그리고 그것을 자원으로 다루는 도구가 긴 작업 내내 에이전트를 일관되게 유지한다. sandboxing, 기억, routing 프로젝트가 수렴하는 것은 우연이 아니다. 같은 희소성의 세 가지 시점이다.

subagent 패턴이 가장 명확한 예다. 에이전트가 좁은 작업을 할 조수를 만들어낼 때, 그 조수는 대화 전체를 물려받을 필요가 없다. 당면한 작업만 담은 깨끗한 컨텍스트를 건네는 편이 더 싸고 더 정확하다. 그래서 최신 harness들은 subagent가 부모보다 더 일찍 자기 context를 압축하도록 한다. 부모는 긴 이력을 지키고, 자식은 새 책상을 받는다. 일주일짜리 리팩터링에 에이전트를 돌려본 팀들은 대개 이 규칙에 스스로 도달한다. 흔히 어떤 subagent가 필요하지도 않은 대화를 다시 읽느라 윈도우를 다 써버리는 걸 지켜본 뒤에.

왜 지금인가

이 문제들은 하나도 새롭지 않다. 첫 에이전트가 돌기 시작한 때부터 에이전트는 컨텍스트를 잃어왔다. 달라진 것은 이제 에이전트가 몇 시간씩, 많은 세션을 넘어, 중요한 작업을 하며 돌아가기를 기대받는다는 점이다. 장난감은 잊어도 잃을 게 없다. 팀이 일주일짜리 리팩터링에서 의지하는 도구는 잊으면 훨씬 큰 걸 잃는다.

시장은 알아챘다. 2년 전에는 "우리 에이전트는 200k 컨텍스트 윈도우가 있다"가 세일즈 포인트였다. 지금 유용한 질문은 그 윈도우 중 얼마만큼이 신호에 쓰이는가다. 이를 이해한 벤더들은 압축 제어와 subagent context 격리를 내놓고 있다. 커뮤니티는 나머지를 견딜 만하게 만드는 배관을 내놓고 있다.

화려하지 않은 결론

10월의 에이전트 뉴스를 더 똑똑한 모델과 더 교묘한 플러그인에 관한 이야기로 읽고 싶은 유혹이 있다. 하지만 더 조용하고 더 오래가는 이야기는 위생(hygiene)에 관한 것이다. 에이전트는 오래 돌릴 만큼 쓸모 있어졌고, 오래 돌리면 자기 기억을 관리하는 방식의 모든 약점이 드러난다.

트렌드 차트를 오르는 프로젝트는 평범한 진실을 받아들인 것들이다. 자율 작업의 병목은 순수한 지능인 경우가 드물다. 자기 메모에 빠지지 않고 작업에 머무는 능력이 병목이다. 기억을 고치고, 소음을 sandbox에 가두고, 능력을 routing하면, 그저 유능한 모델이 갑자기 훌륭해 보인다. 이것들을 틀리면 최전선 모델조차 오후를 다섯 번이나 읽은 로그 파일을 다시 읽으며 보낸다.