Anthropic 에이전트 루프에서 컨텍스트 윈도우 비대화 해결하는 법 (Opus + Sonnet 아키텍처)
How I stopped context window bloat in continuous Anthropic agent loops (Opus + Sonnet architecture)
핵심 요약
Claude 3 Opus와 3.5 Sonnet을 활용해 에이전트 루프의 컨텍스트 비대화를 방지하는 아키텍처 패턴을 공유합니다.
- KV 프롬프트 캐싱 — 핵심 지침과 정적 컨텍스트를 캐싱하여 루프 반복 속도를 향상함.
- 동적 도구 로딩 — 에이전트 라우팅에 필요한 도구 스키마만 선택적으로 로드하여 비대화를 방지함.
- 어드바이저 전략 — Sonnet을 실행기로, Opus를 복잡한 추론용 어드바이저로 분리하여 비용과 성능을 최적화함.
다중 에이전트 아키텍처를 배포하면서 많은 시간을 보냈는데, 지속적인 에이전트 루프를 실행할 때 가장 큰 병목 현상 중 하나가 컨텍스트 제한에 도달하고 그로 인해 API 지연 시간이 급증하는 것이었습니다.
Claude 3 Opus와 3.5 Sonnet을 사용하여 메모리와 컴퓨팅 자원을 관리하는 데 효과적이었던 아키텍처 패턴을 공유하고자 합니다.
이 설정의 세 가지 주요 구성 요소는 다음과 같습니다:
- KV 프롬프트 캐싱(Latency 최적화): 매 턴마다 전체 시스템 프롬프트를 보내는 대신, KV 캐싱을 활용해 지연 시간을 격리합니다. 핵심 지침과 정적 컨텍스트는 캐시된 상태로 유지되어 루프 반복 속도가 크게 빨라집니다.
- 도구 스키마 로딩 지연: 초기 컨텍스트에 모든 가능한 도구 스키마를 채워 넣는 것이 보통 비대화의 원인입니다. 에이전트의 초기 라우팅에서 필요하다고 판단될 때만 도구 스키마를 동적으로 로드하도록 변경했습니다.
- "어드바이저 전략" (역할 분리): 비용과 추론 성능의 균형을 맞추기 위해 실행 계층과 자문 계층을 분리했습니다. Claude 3.5 Sonnet을 표준 라우팅 및 도구 호출을 위한 고속 "실행기(Executor)"로 사용합니다. 로직이 너무 복잡해지거나 오류 디버깅이 필요할 때, (메모리 압축/요약 단계를 거친) 컨텍스트를 Opus로 라우팅합니다. Opus는 순수하게 "어드바이저(Advisor)" 역할을 수행한 뒤 다시 Sonnet에 제어권을 넘깁니다.
여러분은 에이전트 루프에서 메모리 압축과 장기 기록을 어떻게 처리하고 계신지 궁금합니다. 요약 후 교체 방식을 쓰시나요, 아니면 다른 방식을 쓰시나요?

