토큰 절약법 찾다가 토큰 다 태워 먹음
I burned all my tokens researching how to save tokens
핵심 요약
Claude Code 기반의 딥 리서치 파이프라인을 구축하며 겪은 시행착오와 효율적인 에이전트 설계 경험을 공유함.
- 에이전트 설계 — 무분별한 에이전트 확장을 막고 역할 분담을 명확히 함
- 모델 최적화 — 작업 난이도에 따라 비용 효율적인 모델을 적재적소에 배치함
- 검증 프로세스 — 출처 URL과 인용구 확인 등 엄격한 검증 규칙을 도입함
- 시스템 아키텍처 — 모델 성능뿐만 아니라 메모리, 캐싱, 오케스트레이션의 중요성을 강조함
Claude Code를 중심으로 Claude, Codex, Gemini, 그리고 에이전트 간 공유 메모리를 활용한 딥 리서치 파이프라인을 구축했다.
첫 실행 결과는 완전히 엉망이었다:
- 111개의 에이전트가 실행됨
- 123개의 주장이 검증 대기 상태
- Claude Max 5회 제한이 약 30분 만에 소진됨
- 최종 보고서가 생성되지 않음
가장 쉽게 내릴 수 있는 결론은 서브 에이전트가 나쁘다는 것이다.
하지만 난 그렇게 생각하지 않는다.
분리된 컨텍스트와 독립적인 분석은 더 큰 작업을 수행할 때 매우 유용하다. 진짜 문제는 통제되지 않은 팬아웃(fan-out), 불분명한 책임 소재, 그리고 더 저렴한 모델로도 처리할 수 있는 작업에 비싼 모델을 사용한 것이었다.
그래서 역할을 더 명확하게 나누어 파이프라인을 재구축했다:
- Sonnet: 정보 탐색
- Opus: 주장 검증
- Fable: 계획, 오케스트레이션 및 판단
- Codex: 도구 실행 및 검사
- Gemini: 교차 검증(second opinion)
- 모든 에이전트가 로컬 메모리를 공유함
또한 더 엄격한 검증 규칙을 추가했다:
- 정보를 찾은 에이전트는 해당 정보를 직접 검증할 수 없음
- 수락된 모든 주장에는 1차 출처 URL이 필요함
- 모든 출처에는 정확한 인용구가 포함되어야 함
- 수치는 반드시 출처 페이지에 실제로 나타나야 함
- 프로젝트 전체가 아닌, 뒷받침되지 않는 주장만 거부함
이러한 변경 후, 파이프라인은 기존에 구독 중인 비용 내에서 약 10배 더 오래 실행될 수 있었다.
이번 경험을 통해 얻은 가장 큰 교훈은 모델 자체가 시스템의 일부일 뿐이라는 점이다. 에이전트 팬아웃, 컨텍스트 분리, 메모리, 검증, 캐싱, 그리고 오케스트레이션이 모델만큼이나 중요할 수 있다.
여러분은 어떤 기준으로 작업에 별도의 에이전트와 컨텍스트가 필요한지 결정하는가?
내가 일하는 Quesma를 위해 아키텍처, 스크립트, 실패 사례, 교훈을 담은 전체 분석 글을 작성했다:
https://quesma.com/blog/custom-deep-research-pipeline/?utm_source=chatgpt.com
