벤치마크 결과: 메모리 시스템을 탑재한 클로드 에이전트 스웜, 토큰 비용 30-43% 절감 효과 확인

Claude 에이전트 스웜을 위한 메모리 시스템 벤치마크

한 개발자가 9개월 동안 파일 기반에서 SQLite, PostgreSQL로 발전시킨 Stompy라는 메모리 시스템을 구축해 왔습니다. 목표는 Claude 에이전트 스웜을 실행할 때 토큰 사용량을 최소화하는 것이었습니다. 그들은 메모리 시스템을 적용한 경우와 적용하지 않은 경우의 성능을 비교하는 벤치마크를 실시했습니다.

테스트 설정

벤치마크는 백엔드, 프론트엔드, 테스트를 포함한 완전한 예약 기능이 필요한 40점짜리 코딩 작업을 사용했습니다. 6개의 에이전트로 구성된 스웜을 Sonnet 4.6, Opus 4.6, Haiku 4.5 세 가지 다른 Claude 모델을 리더로 하여 테스트했습니다. 모든 테스트는 동일한 코드베이스, 동일한 팀원, 동일한 채점 시스템을 사용했습니다. 팀원 에이전트는 리더 모델과 관계없이 항상 Opus를 실행했습니다.

벤치마크 결과

• Sonnet 4.6 + 메모리: 40/40, $3.98, 6.5분, 2턴
• Sonnet 4.6 메모리 없음: 40/40, $7.04, 9.6분, 4턴
• Opus 4.6 + 메모리: 40/40, $4.34, 9.6분, 29턴
• Opus 4.6 메모리 없음: 40/40, $7.65, 10.0분, 70턴
• Haiku 4.5 + 메모리: 39/40, $4.95, 7.5분, 2턴
• Haiku 4.5 메모리 없음: 0/40, $3.97, 5.8분, 3턴

주요 발견 사항

메모리를 적용한 Opus와 Sonnet은 메모리를 적용하지 않은 경우에 비해 약 43%의 비용을 절감했습니다. 개발자는 이러한 모델들이 메모리 없이도 작업을 완료할 만큼 충분히 똑똑하지만, 메모리 시스템이 제거하는 코드베이스 탐색에 토큰을 낭비한다고 지적했습니다.

Haiku 결과는 예상치 못했습니다: 메모리 없이는 0/40점을 기록했지만, 메모리를 적용하면 39/40점을 기록했습니다. 개발자는 Haiku가 프로젝트 구조를 이해하지 못하면 Opus 팀원 에이전트들을 조율할 수 없지만, 메모리 접근 권한을 갖추면 유능한 리더가 된다고 관찰했습니다.

메모리를 적용한 Sonnet은 전반적으로 가장 우수한 구성이었으며, 모든 지표에서 메모리가 없는 Opus를 약 절반의 비용으로 능가했습니다. 결론은 비싼 모델을 사용하는 것보다 프로젝트 지식을 모델에 제공하는 것이 더 중요하다는 것입니다.

기술적 세부 사항

메모리 시스템은 Stompy라고 불리며 MCP/API/CLI 기반으로 Claude Code와 함께 작동합니다. 벤치마크 설정은 다른 사람들이 사용하거나 개선할 수 있도록 GitHub에서 이용 가능합니다. 개발자는 현재까지 조건당 n=1이므로 더 많은 실행을 계획하고 있다고 언급했습니다.