며칠 전, Systima라는 영국 AI 컨설팅 회사가 재미난 벤치마크를 공개했다. Claude Code와 OpenCode를 같은 모델(claude-sonnet-4-5), 같은 머신, 같은 작업에 올려놓고 API 경계에서 주고받은 모든 토큰을 측정한 결과다.

결론은 이렇다: Claude Code는 사용자 프롬프트가 도착하기 전에 이미 33,000토큰을 소비한다. OpenCode는 7,000토큰. 무슨 말이냐면, “안녕” 한 마디를 입력하기 전에 Claude Code는 33k 토큰어치의 시스템 프롬프트, 툴 스키마, 인젝션된 스캐폴딩을 이미 모델로 보냈다는 뜻이다. OpenCode는 그 5분의 1만 보낸다.

4.7배. 같은 모델, 같은 작업에 대해.

무엇을 측정했나

Systima는 두 하네스와 모델 엔드포인트 사이에 로깅 프록시를 박았다. HTTP 요청 본문과 응답 usage 블록을 전부 캡처한 것이다. 측정은 세 가지 작업으로 나눴다:

T1: “Reply with exactly: OK” — 한 줄. 고정 오버헤드 측정. T2: 파일 읽고 요약 — 단일 툴 호출. T3: write-run-test-fix 루프 — 다단계 작업.

그리고 이 베이스라인 위에 실제 운영 환경을 시뮬레이션한 multiplier 레이어를 하나씩 쌓았다. 정직한 측정이다.

숫자가 말해주는 것

첫 번째 요청 페이로드: Claude Code ~32,800토큰, OpenCode ~6,900토큰. 차이의 주범은 툴 스키마다. Claude Code는 27개 툴(99,778자)을, OpenCode는 10개 툴(20,856자)을 보낸다. 시스템 프롬프트도 Claude Code가 3블록 27,344자인 반면 OpenCode는 1블록 9,324자다.

다단계 작업(T3)에서는 격차가 좁혀진다. Claude Code가 툴 호출을 병렬 배치로 묶어 3번의 요청으로 처리한 반면, OpenCode는 툴당 한 번씩 9번 요청했다. 누적 입력 토큰은 Claude Code ~121k, OpenCode ~132k로 비슷했다. 큰 베이스라인이지만 적게 요청하는 하네스 vs 작은 베이스라인이지만 많이 요청하는 하네스 — total cost는 작업 형태에 따라 달라진다.

더 새로운 모델(Fable 5)에서는 격차가 3.3배로 줄었다. Claude Code가 모델에 따라 시스템 프롬프트를 다르게 보내기 때문이다. OpenCode는 모델과 무관하게 바이트 동일했다.

캐시 불안정성이 진짜 차이다

이 벤치마크에서 내가 가장 주목한 건 여기다.

OpenCode는 모든 요청에서 프리픽스(툴 + 시스템 블록)가 바이트 단위로 동일했다. 세 번의 T1 세션이 동일한 툴 바이트, 동일한 시스템 바이트, 동일한 메시지 바이트를 보냈다. 캐시 쓰기는 제로, 캐시 읽기만 발생했다.

Claude Code는 세션 내에서도 프리픽스가 달라졌다. 같은 파일 요약 작업에서 Claude Code는 53,839토큰의 캐시 쓰기를 다섯 번의 요청 동안 기록했고, 그중 한 번은 작업 중간에 전체 ~43k 프리픽스를 통째로 다시 썼다. OpenCode는 1,003토큰.

이 차이는 모델과 무관하게 재현됐다. Sonnet 4.5에서 54배, Fable 5에서 52배. 캐시 쓰기는 프리미엄으로 과금된다(1.25배). 그러니까 Claude Code는 더 큰 페이로드를 보낼 뿐만 아니라, 그 페이로드를 더 자주 다시 쓰고, 더 높은 요금으로 지불한다.

중간에 캐시를 갱신하는 건 어떤 코드 품질 향상도 가져오지 않는다. 같은 내용을 더 비싸게 다시 보내는 것뿐이다. Systima의 표현을 빌리자면: “Re-writing a byte-identical cache prefix mid-session buys no code quality at all. It is the same content, paid for again at premium rates.”

멀티플라이어 레이어

혼자 가볍게 쓰는 세션은 베이스라인이 전부다. 문제는 현실.

72KB AGENTS.md: 요청당 약 20,000토큰 추가. 두 하네스 공통. MCP 서버 5개: 요청당 5,000~7,000토큰 추가. 툴 카운트 27→69 / 10→52. 서브에이전트 2개: 직접 처리 121k → 팬아웃 513k. 4.2배 멀티플라이어. 모든 서브에이전트가 자기 부트스트랩 비용을 내고, 부모가 그 트랜스크립트를 다시 먹는다. “Everything” 설정: 11개 MCP 서버 + 72KB 지시 파일. 첫 요청 콜드 캐시 기준 OpenCode 90,817토큰. 사용자가 한 글자도 입력하기 전에.

이게 내 선택을 검증했다

Drewgent는 처음부터 OpenCode 위에서 돌아가도록 설계했다. 그 결정은 여러 이유에서 비롯됐지만, 비용 통제가 핵심이었다. 모델 라우팅 테이블을 설계할 때 나는 “호출 비용이 2일에 30달러”라는 숫자와 마주했고, 거기서부터 역산해서 아키텍처를 짰다.

Systima의 벤치마크는 그 결정이 옳았다는 걸 보여준다. OpenCode의 7k 베이스라인은 설계 철학의 결과다. 불필요한 툴을 기본으로 탑재하지 않고, 캐시 프리픽스를 안정적으로 유지하며, 서브에이전트에 최소한의 프로파일만 전달한다. 이건 단순히 “가벼워서 좋다”의 문제가 아니라, 비용이 구조에 의해 결정된다는 원칙을 증명한다.

Claude Code의 33k 베이스라인이 나쁘다는 뜻은 아니다. 백그라운드 에이전트, 스킬 매니저, 태스크 오케스트레이션 — 그 33k에는 Claude Code만의 설계 가치가 담겨 있다. 문제는 그 가치가 내 작업에 필요한가다. Drewgent는 이미 자체 오케스트레이션 레이어를 가지고 있고, 모델 라우팅을 통해 비용을 통제한다. OpenCode의 미니멀리즘은 내 아키텍처와 맞아떨어진다.

툴 선택은 취향이 아니라 비용 구조다.

한 가지 더: 방법론이 통제로 이어진다

Systima가 사용한 측정 방법도 주목할 만하다. 185개 요청/응답 레코드를 SHA-256 해시 체인 감사 추적으로 기록했고, 체인 무결성을 검증했다. 이건 EU AI Act Article 12에서 요구하는 로깅 메커니즘과 같은 접근이다.

에이전트가 무엇을 보내고 받는지 측정할 수 있어야, 비용을 통제할 수 있다. 이 원칙은 Drewgent의 GraphRCA나 모델 라우팅과 같은 철학적 기반을 공유한다. 측정하지 않으면 최적화할 수 없다.

정리

Systima의 벤치마크가 보여준 것은 단순한 승패가 아니다. 두 하네스의 설계 철학이 그대로 토큰 소비로 환원된 결과다. OpenCode는 더 적게, 더 안정적으로 보낸다. Claude Code는 더 많이, 더 다양한 프리픽스로 보낸다.

내게 중요한 질문은 하나였다: “내 사용 패턴에서 어떤 설계가 더 유리한가?” 그리고 그 대답은 OpenCode였다. Systima의 숫자는 그 대답이 틀리지 않았다는 걸 확인해줬다.

전체 벤치마크는 Systima 블로그에서 읽을 수 있다. 측정 리그는 약 200줄의 Node.js로 공개되어 있으니, 자신의 설정에서 직접 재현해볼 수도 있다.

—

Built with opencode-drewgent