도구 컨텍스트 관리 (Manage Tool Context)

도구 정의(tool definitions)와 쌓여가는 tool_result 블록은 컨텍스트 윈도우를 계속 잡아먹어요. 도구가 많고 턴(turn)이 많은 장기 실행 에이전트라면, 작업이 끝나기 전에 컨텍스트가 바닥나는 경우도 생기죠. 이 문제를 파이프라인의 서로 다른 지점에서 해결하는 네 가지 접근법이 있습니다.

네 가지 접근법

각 접근법은 컨텍스트 압력의 서로 다른 원인을 겨냥해요. 토큰이 어디로 새고 있는지에 맞는 방법을 고르면 됩니다.

접근법	줄여주는 것	언제 어울리나	자세히 보기
도구 검색 (Tool search)	미리 로드하는 도구 정의	도구가 많고(20+개) 매 턴 대부분의 도구가 필요 없는 경우	Tool search tool
프로그램 방식 도구 호출 (Programmatic tool calling)	tool_result 왕복	하나의 스크립트로 실행할 수 있는 도구 호출 체인	Programmatic tool calling
프롬프트 캐싱 (Prompt caching)	반복되는 도구 정의의 토큰 비용	많은 요청에 걸쳐 안정적인 도구 세트	Tool use with prompt caching
컨텍스트 편집 (Context editing)	이력에 남은 오래된 tool_result 블록	초기 결과가 더 이상 관련 없는 긴 대화	Context editing

도구 검색 (Tool search)

도구 검색은 Claude가 요청하기 전까지 도구 정의를 컨텍스트 윈도우 밖에 보관해요. 50개의 도구 스키마를 처음부터 다 보내는 대신, tool_search 도구 하나만 보내고 나머지 도구는 Claude가 필요할 때마다 찾아서 쓰게 하는 방식이죠. 이렇게 하면 약간의 지연(도구를 찾기 위한 턴 하나)과 큰 폭의 기본 컨텍스트 사용량 절감을 맞바꾸는 셈입니다.

프로그램 방식 도구 호출 (Programmatic tool calling)

프로그램 방식 도구 호출은 일련의 도구 호출을 하나의 코드 블록으로 압축하는데, 그 블록을 Claude가 작성하고 Anthropic의 코드 실행 샌드박스가 실행해요. tool_use와 tool_result 다섯 번 왕복하는 대신, Claude가 다섯 함수를 모두 샌드박스 안에서 호출하는 스크립트 하나를 뱉습니다. 중간 결과는 대화 이력에 들어가지 않아요.

프롬프트 캐싱 (Prompt caching)

프롬프트 캐싱은 컨텍스트의 토큰 수를 줄이는 게 아니라, 이후 요청에서 그 토큰에 대한 비용을 줄여줘요. 도구 정의가 안정적이라면 한 번 캐시해 두고 수천 개의 요청에 걸쳐 캐시된 접두부(prefix)를 재사용할 수 있죠. 도구 세트가 크지만 고정되어 있다면 바로 이 방법이 정답입니다.

컨텍스트 편집 (Context editing)

컨텍스트 편집은 역할을 다한 오래된 tool_result 블록을 대화 이력에서 제거해요. 긴 에이전트 루프에서는 그 당시엔 유용했지만 지금은 죽은 무게가 된 중간 결과가 수백 개 생기기 마련이죠. 컨텍스트 편집을 쓰면 대화를 다시 시작하지 않고도 그걸 잘라낼 수 있습니다.

접근법 조합하기

이 접근법들은 서로 합쳐 쓸 수 있어요. 장기 실행 에이전트는 도구 검색으로 도구 세트를 날씬하게 유지하고, 프롬프트 캐싱으로 나머지 정의의 비용을 분산시키며, 대화가 길어질수록 컨텍스트 편집으로 오래된 결과를 정리할 수 있죠. 각각이 문제의 다른 부분을 해결하기 때문에, 함께 써도 충돌이 없습니다.

고부하(high-volume) 에이전트를 위한 합리적인 출발점은 다음과 같아요.

1. 첫날부터 도구 정의에 프롬프트 캐싱을 켜세요. 캐시 쓰기(cache write)에는 기본 입력 가격보다 25%의 마크업이 붙지만, 그 비용은 두 번째 요청부터 캐시를 읽는 시점에 메워집니다.