AI Sparkup

최신 AI 쉽게 깊게 따라잡기⚡

Claude Code vs Pi, 같은 작업에서 토큰 사용이 10배 차이 나는 이유

피보나치 수열을 출력하는 파이썬 스크립트 하나를 만들었을 뿐인데, Claude Code는 83,000 토큰을 썼고 Pi는 8,000 토큰을 썼습니다. 같은 작업, 같은 결과물인데 토큰 소비가 10배나 차이 났습니다. 그 차이는 코드의 복잡도가 아니라 에이전트가 자기 자신에게 쓰는 ‘보이지 않는 비용’에 있었습니다.

사진 출처: Portkey Blog

AI 게이트웨이 서비스 Portkey가 세 개의 코딩 에이전트(Pi, OpenAI Codex, Claude Code)에 동일한 요청을 보내고 모든 요청 로그를 캡처했습니다. 실제 작업 토큰과 하네스(harness) 오버헤드를 분리해 측정한 결과, 에이전트마다 수만 토큰에 달하는 숨겨진 비용이 있었습니다.

출처: The Harness Tax: The Dead Weight Inside Your Coding Agent – Portkey Blog

하네스 세금이란?

하네스(harness)는 에이전트가 모델에게 요청을 보낼 때 사용자 메시지와 함께 딸려 보내는 모든 부가 정보입니다. 툴 정의 목록, 시스템 프롬프트, 메모리 지시, 행동 라우팅 규칙, 대화 히스토리가 여기에 포함됩니다. 이 모든 게 매 요청마다 통째로 모델에게 전달됩니다.

Portkey는 이를 “하네스 세금(Harness Tax)“이라고 부릅니다. 에이전트가 실제 작업에 토큰을 쓰기 전에, 자기 자신을 위해 먼저 치르는 비용입니다. 측정 결과는 이렇습니다.

  1. Pi: 요청당 약 2,600 입력 토큰 (하네스 오버헤드)
  2. Codex: 요청당 약 15,000 토큰
  3. Claude Code: 요청당 약 27,000 토큰

차이의 핵심은 툴 설계 철학에 있습니다. Pi는 파일 읽기, 쓰기, 편집, 셸 명령 실행 — 딱 네 가지 툴만 갖추고 있습니다. Claude Code는 28개의 툴을 정의해뒀고, 이 정의들은 실제로 사용하지 않아도 매 요청마다 모두 전송됩니다.

비용 문제에서 그치지 않는 이유

토큰을 더 쓰면 돈이 더 드는 건 명확합니다. 하지만 Portkey가 지적하는 더 근본적인 문제는 컨텍스트 품질 저하입니다.

코딩 에이전트는 대화를 이어가면서 이전 응답을 히스토리에 누적합니다. 그런데 에이전트의 응답 자체가 장황한 툴 호출 포맷으로 부풀어 있기 때문에, 히스토리도 함께 빠르게 팽창합니다. 실제 코딩 세션은 보통 30~50 턴 정도 진행되는데, Claude Code 기준으로 40턴 세션이면 약 110만 입력 토큰을 소비하고, 그 절반이 하네스 오버헤드입니다.

이 문제를 Portkey는 “Context Rot(컨텍스트 부패)“라고 표현합니다. 200,000 토큰 컨텍스트 창에 28,000 토큰의 하네스가 들어 있다면, 모델이 실질적으로 활용할 수 있는 공간은 172,000 토큰으로 줄어들고, 모델의 주의(attention)는 실제 코드와 파일 대신 프레임워크 배관(plumbing)에 분산됩니다.

모델이 좋아질수록 하네스는 가벼워져야 한다

Portkey가 인용한 Anthropic 엔지니어링팀의 사례가 이 흐름을 잘 보여줍니다. Claude Sonnet 4.5 시절에는 컨텍스트 창이 꽉 차면 에이전트가 조기에 작업을 마무리하려는 현상이 있었고, 이를 막기 위한 컨텍스트 리셋 로직이 하네스에 포함돼 있었습니다. Opus 4.5가 나오자 리셋이 불필요해졌고, Opus 4.6에서는 스프린트 분해 기능 자체를 하네스에서 걷어냈는데도 더 잘 작동했습니다. 세 번의 모델 업그레이드, 세 번의 하네스 축소입니다.

하네스는 모델이 스스로 처리하지 못하는 부분을 보완하는 도구입니다. 그런데 모델이 발전하면서 그 전제가 달라지면, 어제의 보조 장치가 오늘의 짐이 됩니다.

Pi가 보여주는 방향은 단순합니다. 모델이 이미 수백만 개의 셸 세션과 GitHub 레포를 학습했다면, ls -lagrep -r 같은 기본 명령을 스스로 조합할 수 있습니다. 별도로 list_directorysearch_files 툴을 정의할 필요가 없다는 얘기입니다.

Portkey는 에이전트의 구조를 세 층으로 나눕니다. 복잡성은 위로(모델의 추론과 자기 수정)와 아래로(라우팅, 관측, 비용 제어 같은 인프라)로 밀어내야 하고, 중간의 하네스는 최대한 가볍게 유지해야 한다는 것입니다.

이번 벤치마크는 두 개의 메시지, 하나의 간단한 작업을 대상으로 한 좁은 실험입니다. Claude Code의 풍부한 툴셋이 복잡한 작업에서는 그 오버헤드를 충분히 상쇄할 수 있습니다. 하지만 오버헤드가 실재하고, 측정 가능하며, 거의 아무도 들여다보지 않는다는 사실은 명확합니다. 실제 토큰 사용 내역이 어떤지 확인해본 적 없다면, 직접 한 번 확인해볼 만한 이유가 생겼습니다.

참고자료:


AI Sparkup 구독하기

최신 게시물 요약과 더 심층적인 정보를 이메일로 받아 보세요! (무료)

Comments

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다