MemTool, 턴당 도구 90% 제거해도 정확도 유지

2025년 7월의 한 연구 결과는 에이전트 빌더들이 계속 피하던 질문에 명확한 숫자를 붙였다. 정확도가 무너지기 전까지, 매 턴마다 도구 목록을 얼마나 덜어낼 수 있을까? 성능이 충분한 모델이라면 답은 거의 전부다.

도구를 90% 덜어내도 되는 이유

공격적인 도구 가지치기는 한 턴의 컨텍스트에서 에이전트가 사용할 수 있는 도구 대부분을 제거해도 작업 정확도가 유지되는 방식이다. 단, 모델이 자신이 제외한 것이 무엇인지 추론할 만큼 충분히 강해야 한다. MemTool(arXiv 2507.21428)에서 추론형 LLM은 세 윈도 평균 기준 90–94%의 도구 제거 효율을 보였고, 중간 규모 모델은 0–60% 범위에 머물렀다 . 이 차이는 프롬프트를 더 잘 다듬어 메울 수 있는 튜닝 격차가 아니다. 공격적인 가지치기를 애초에 안전하게 시도할 수 있는지 가르는 능력의 절벽이다.

가지치기가 해가 아니라 도움이 되는 이유는 어텐션이 작동하는 방식에 있다. Anthropic은 이 실패 양상을 "context rot"이라고 설명한다. 모든 토큰이 다른 모든 토큰을 바라보기 때문에 관계 수가 n²로 늘어나고, 비대한 도구 목록은 각 스키마가 작더라도 한정된 어텐션 예산을 소모한다 . 더 큰 윈도도 이 문제를 해결하지 못했다. 단순히 "전부 넣는" 전략은 성능을 측정 가능하게 떨어뜨린다.

"If even a human engineer cannot confidently choose a tool," 에이전트는 더 나쁜 결과를 낸다. 비대하고 서로 겹치는 도구 세트가 선택을 혼란스럽게 만들기 때문이다. — Anthropic, Effective context engineering for AI agents (source: Anthropic, 2025-09)

서로 독립적인 두 신호도 같은 방향을 가리킨다. LangChain은 도구 설명에 RAG를 적용했을 때 도구 선택 정밀도가 대략 3배 개선됐다고 보고했다 . OpenAI의 Agents SDK도 이 논리를 구조적으로 강제한다. 네임스페이스는 10개 함수 미만으로 유지하고, 나머지는 런타임까지 미루라는 방식이다 . 관점은 이렇게 바뀐다. 성능이 충분한 모델에서는 사용할 수 있는 도구를 덜 넣는 위험보다, 추론 페이로드를 과하게 채우는 위험이 더 크다. 이 실무자 논의도 같은 논쟁이 현장에서 진행 중임을 보여준다.

컨텍스트 엔지니어링이 실제로 뜻하는 것 — 도구 가지치기 뒤의 원칙

컨텍스트 엔지니어링은 LLM이 각 추론 단계에서 정확히 어떤 토큰을 보게 할지 선별하는 분야이며, 도구 가지치기는 그 안의 한 가지 전술이다. Andrej Karpathy는 2025년 6월 25일 이 용어를 널리 알리며, 이를 "the delicate art and science of filling the context window with just the right information for the next step"라고 정의했다 . 최적화 대상은 단일 호출의 문구가 아니라, 수백 턴에 걸쳐 모든 토큰을 선별하고, 줄이고, 정렬하는 상태ful 파이프라인이다.

이렇게 보면 컨텍스트는 수동적인 프롬프트 부록이 아니라 실행 표면이 된다. 시스템 지침, 도구 스키마, 검색된 사실, 중간 로그, 핸드오프 요약처럼 각 호출에 보이는 모든 것이 여기에 포함된다. Devin을 만든 Cognition 팀은 그 중요성을 이렇게 직설적으로 말한다.

"Context engineering is effectively the #1 job of engineers building AI agents." — Cognition (source: Don't Build Multi-Agents)

가지치기가 중요한 이유는 단순히 "전부 넣는" 전략이 작업 완료율을 측정 가능하게 해치기 때문이다. Anthropic의 2025년 9월 29일 가이드는 100만 개 이상의 토큰 윈도도 "context rot"을 해결하지 못했다고 지적한다. 토큰 수가 늘어날수록 회상 성능은 여전히 떨어진다. 어텐션은 유한하고, 모든 토큰이 다른 모든 토큰을 바라보기 때문이다 . Anthropic은 또한 순서를 지켜야 하는 두 하위 목표를 구분한다. 먼저 압축과 구조화된 노트 작성으로 회상을 최대화하고, 그다음 정밀도를 위해 덜어내야 한다. 둘을 혼동하면 압축 과정에서 에이전트가 실행 중에 여전히 필요로 하는 사실까지 버리게 된다.

LangChain의 컨텍스트 분류로 도구 프루닝 적용하기

LangChain의 네 가지 작업 모델인 write, select, compress, isolate는 도구 프루닝을 설명할 어휘를 제공하며, 각 작업은 특정 런타임 결정과 맞닿아 있다 . MemTool처럼 턴마다 도구를 제거하는 방식은 스키마에 select 레버를 적용한 것이지만, 나머지 세 가지가 갖춰져 있을 때만 안정적으로 작동한다. 네 개의 독립적인 요령이 아니라 하나의 시스템으로 다뤄야 한다.

Write는 활성 컨텍스트 창이 가득 차기 전에 상태를 외부에 저장한다. Anthropic의 멀티 에이전트 연구 시스템은 컨텍스트가 약 200,000토큰을 넘으면 실행 중간에 잘릴 수 있기 때문에 계획을 외부 메모리 저장소에 저장한다 . 장기 실행 에이전트에게 이는 선택 사항이 아니다. 프루닝된 도구가 세 턴 뒤 다시 필요해진다면, 그 호출 계약은 모델이 다시 읽을 수 있는 어딘가에 남아 있어야 한다.

Select는 현재 하위 작업에 필요한 스키마만 로드한다. OpenAI의 호스팅 도구 검색은 큰 도구 표면을 런타임까지 지연시키며, 네임스페이스별로 나누고 가능하면 네임스페이스당 함수 10개 미만을 권장한다 . 이것이 MemTool이 모델 수준에서 구현하는 아키텍처 메커니즘이며, 추론형 LLM은 세 개 창 평균 기준 90~94%의 도구 제거 효율을 보였다 .

Compress는 연속성을 잃지 않으면서 예산을 회수한다. Claude Code는 창의 약 95%가 소비되면 자동으로 압축을 트리거하며, 그 명세는 “먼저 회상을 최대화하고, 그다음 정밀도를 위해 줄인다”는 것이다. 오래된 것부터 자르는 방식이 아니다 . 순서가 중요하다. 가장 오래된 턴을 무턱대고 버리면 에이전트가 여전히 의존하는 도구 결과를 잃을 수 있다.

Isolate는 하위 에이전트 사이의 범위를 분리한다. Anthropic의 연구 평가에서 각 하위 에이전트는 오케스트레이터에게 1,000~2,000토큰으로 압축한 요약만 반환했고, 이 시스템은 내부 벤치마크에서 단일 에이전트 Opus 4보다 90.2% 더 나은 성능을 냈다 . 반대로 전체 추적을 공유하면 어긋난 결정이 끼어들기 쉽다. Cognition의 “Flappy Bird” 사례에서는 한 하위 에이전트가 마리오 스타일 배경을 만들고, 다른 하위 에이전트는 그와 맞지 않는 새를 만들었다 .

핸드오프와 메모리: 공격적인 도구 프루닝이 빗나가는 지점

공격적인 도구 프루닝은 뒤의 에이전트가 여전히 필요로 하는 컨텍스트까지 제거할 때 깨진다. Anthropic은 모든 하위 에이전트 핸드오프에 네 가지 필드, 즉 목표, 출력 형식, 소스/도구 지침, 명확한 범위 경계를 담으라고 명시한다 . 하나라도 빠지면 에이전트는 물려받았어야 할 내용을 다시 찾아내야 하고, 프루닝으로 아끼려던 토큰을 태우게 된다.

두 번째 실패 지점은 메모리다. LangChain은 긴 컨텍스트를 쓰는 에이전트도 오래된 내용 때문에 느려지고, 비용이 커지고, 주의가 흐트러진다고 경고한다. 따라서 약 200,000토큰을 넘는 실행에서는 창이 가득 차기 전에 외부 저장소에 상태를 쓰는 일이 선택 사항이 아니다 . 쓰기 전에 잘라 버리면 실행 도중 계획과 도구 계약을 잃는다.

세 번째는 병렬성이다. Cognition의 규칙은 검색, 요약처럼 읽기 전용인 하위 에이전트는 병렬 실행해도 안전하지만, 쓰기 작업은 단일 스레드로 유지해야 한다는 것이다. 병렬 쓰기는 서로 충돌하는 암묵적 결정을 만들고, 나중에 그럴듯하지만 틀린 진행 경로로 드러난다 .

마지막으로 도구 수준의 스키마 모호성은 규모가 커질수록 더 크게 누적된다. Anthropic의 Building Effective Agents 부록은 파일 편집 도구가 절대 경로를 요구하도록 바꾸자 반복되던 SWE-bench 실패가 해결됐다고 적고 있다 . 모호성을 줄이는 작은 변경은 수천 턴에 걸쳐 효과를 낸다.

도구 프루닝을 단계적으로 도입하기

재작성부터 하지 말고 감사부터 시작하라. 턴마다 로드되는 모든 도구 스키마를 기록하고 Anthropic의 휴리스틱을 적용하라. 인간 엔지니어가 그중에서 자신 있게 고를 수 없다면 모델도 그럴 수 없다 . 겹치고 모호한 그 묶음이 프루닝 후보 목록이다. 다음으로 압축 임계값을 정하라. Claude Code의 문서화된 트리거는 창이 약 95% 찼을 때 작동한다 . 다만 이를 조정하기 전에는 자신의 작업 유형에서 회상 성능을 벤치마크해야 한다. 기대치는 기본 모델 등급별로 나눠야 한다. MemTool의 90~94% 도구 제거 효율은 추론형 LLM에서 측정된 반면, 중간급 모델은 0~60% 범위에 머물렀다 . 따라서 중간급 배포에서는 턴별 공격적 프루닝에 들어가기 전에 선택적 로딩과 명시적 작업 게이팅을 함께 써야 한다. 마지막으로 MCP 도구 설명을 감사하라. Invariant Labs는 2025년 4월 1일 숨은 지시문을 통한 도구 포이즈닝을 공개했다 . 노출하는 모든 스키마는 그 표면을 넓힌다. 프루닝은 토큰 비용과 공격 표면을 함께 줄인다.

자주 묻는 질문

MemTool은 정확히 무엇을 가지치기하나요 — 도구 호출인가요, 스키마인가요?

MemTool은 도구 스키마, 즉 컨텍스트 창을 차지하는 설명과 매개변수 명세를 가지치기합니다. 실제 도구 구현을 제거하는 것은 아닙니다. 함수 자체는 계속 호출할 수 있고, 에이전트가 추론 턴마다 보게 되는 스키마 수만 줄어듭니다. MemTool의 선택적 로딩은 현재 작업 상태와 관련 있는 하위 집합만 노출한 뒤, 다음 턴에서 다시 평가합니다. arXiv 평가에서 추론형 LLM은 세 개 창 평균 기준 90–94%의 도구 제거 효율을 보였고, 중간 규모 모델은 0–60% 범위였습니다 . 이 효율은 레지스트리에서 도구를 삭제한 것이 아니라, 활성 컨텍스트에서 제거된 스키마를 기준으로 측정한 값입니다.

컨텍스트 엔지니어링이 프롬프트 엔지니어링을 대체하나요?

아닙니다. 둘은 최적화하는 대상이 다릅니다. 프롬프트 엔지니어링은 단일 호출을 위한 지시문 표현을 다듬고, 컨텍스트 엔지니어링은 수백 턴에 걸쳐 무엇을 기록하고, 선택하고, 압축하고, 격리할지 결정하는 상태 기반 파이프라인을 설계합니다 . Andrej Karpathy는 2025년 6월 게시물에서 이 분야를 다음 단계에 필요한 “정확히 알맞은 정보”로 컨텍스트 창을 채우는 일이라고 설명했습니다 . 에이전트 규모에서는 컨텍스트 엔지니어링이 신뢰성 문제의 대부분을 포괄하고, 프롬프트 엔지니어링은 개별 지시문의 남은 품질을 다룹니다.

서브 에이전트를 격리해야 할 때와 전체 컨텍스트를 공유해야 할 때는 언제인가요?

검색, 요약, 코드 스캔처럼 읽기 전용이거나 범위가 제한된 하위 작업에서는 격리하는 편이 좋습니다. 이런 경우 서브 에이전트는 1,000–2,000토큰 분량의 압축 요약을 오케스트레이터에게 돌려줄 수 있습니다 . 에이전트들이 서로의 상태에 의존해 쓰기 결정을 내려야 한다면 더 충분한 컨텍스트를 공유해야 합니다. Cognition의 원칙은 전체 추적을 공유하면 서로 충돌하는 암묵적 결정을 막을 수 있다는 것이며, 이는 “Don't Build Multi-Agents” 게시물에서 설명됩니다 . 경험칙은 간단합니다. 읽기는 격리하고, 쓰기는 단일 흐름으로 처리합니다.

Anthropic의 압축은 오래된 메시지를 잘라내는 방식과 어떻게 다른가요?

압축은 먼저 회상을 극대화합니다. 전체 대화를 밀도 높은 표현으로 요약한 다음, 정밀도를 위해 다듬습니다. 단순 잘라내기는 에이전트가 작업 중간에 여전히 필요로 하는 정보인지 고려하지 않고 가장 오래된 토큰을 버립니다. Claude Code는 창의 약 95%가 소진되면 자동 압축을 트리거합니다 . 정밀도보다 회상을 먼저 두는 이 순서가, 순진한 잘라내기가 조용히 버리는 작업 중간 상태를 보존합니다.

가지치기를 적용한 멀티 에이전트로 이동할 때 어느 정도의 토큰 오버헤드를 예상해야 하나요?

Anthropic이 측정한 수치는 다음과 같습니다. 에이전트는 채팅보다 대략 4배 많은 토큰을 사용하고, 멀티 에이전트 시스템은 약 15배를 사용합니다 . 같은 연구에서 토큰 사용량만으로 BrowseComp 성능 변동의 80%가 설명됐고, 토큰 사용량, 도구 호출, 모델 선택을 합치면 95%가 설명됐습니다 . 가지치기는 호출당 스키마 오버헤드를 줄이지만, 오케스트레이션에도 자체 비용이 붙습니다. 절감분이 자연스럽게 상쇄된다고 가정하지 말고 양쪽 비용을 모두 명시적으로 예산에 반영해야 합니다.

이 글이 도움이 되셨다면, 새 글이 올라올 때마다 이메일로 받아보세요.

구독하기