이런 장면을 상상해 보자. AI 코딩 어시스턴트를 열고 “좋아”라는 두 글자를 입력해 확인을 요청한다. 딱 이 두 글자다. 그런데 AI가 이 두 글자를 실제로 “보기”도 전에, 백그라운드에서는 이미 약 33,000개의 토큰 연산 할당량이 조용히 소모된 뒤다. 반면 기능이 비슷한 또 다른 도구는 같은 상황에서 약 7,000개만 사용했다.
이것은 비유도, 어림짐작도 아니다. Systima 팀이 Anthropic의 API 인터페이스 위에 로깅 프록시를 한 겹 얹고, 매 요청의 원본 데이터를 하나하나 기록해 얻어낸 실측 결론이다. 이들은 블로그에 완전한 실험 방법과 원시 수치를 공개했고, 이 글은 이후 Hacker News에서 400개가 넘는 추천과 200여 개의 토론을 얻었다.
필자는 일반 독자도 이해할 수 있는 방식으로 이 숫자 뒤에 놓인 세 가지 이야기를 풀어 보려 한다. AI 코딩 도구는 “당신의 말을 보기 전에” 대체 무엇을 하고 있는가? 서브에이전트는 왜 진짜 토큰 블랙홀인가? 그리고 종량제 과금 비즈니스 모델은 이 안에서 어떤 역할을 하는가?
토큰이란 무엇인가? 왜 「휘발유」처럼 빠르게 타 버리는가?
구체적인 숫자로 들어가기 전에 핵심 개념 하나를 짚자. 토큰은 AI가 텍스트를 처리할 때의 최소 계량 단위로 이해할 수 있다. “한 글자”가 아니라 대략 영어 0.75단어, 혹은 한자 1~2자 정도에 해당한다. 종량제로 과금되는 AI 서비스를 쓸 때는 토큰 하나를 처리할 때마다 청구서가 쌓인다.
AI 코딩 도구는 일반적인 AI 대화와 다르다. 웹 버전에서 Claude와 채팅하면 Claude가 받는 것은 기본적으로 당신의 질문뿐이다. 하지만 AI 코딩 도구는 당신의 질문 외에도 대량의 “준비 작업”을 추가로 밀어 넣어야 한다. AI에게 자기가 누구인지, 어떤 도구를 호출할 수 있는지, 프로젝트에 어떤 규칙이 있는지, 현재 작업 디렉터리는 어디인지, 운영체제의 환경 정보는 무엇인지 등을 알려주는 것이다.
이 추가 콘텐츠를 “하네스 오버헤드(harness overhead)“라고 부른다. 문제는 이 하네스의 크기 차이가 어마어마하다는 점이다.
33,000 vs 7,000: “OK” 한 번 답하는 데 드는 청구서 비교
Systima의 실험 설계는 매우 직접적이다. 두 AI 코딩 도구—Anthropic 공식의 Claude Code와 오픈소스인 OpenCode—에게 각각 가장 단순한 동일 작업을 시켰다. 바로 “OK”라고 답하는 것이다.
Claude Code는 “OK”라는 두 글자를 읽기 전에 먼저 API로 약 33,000개의 토큰을 보냈다. 이 토큰의 구성은 이렇다. 약 6,500개는 시스템 프롬프트(“너는 누구이고 어떻게 해야 하는가”를 AI에게 알려주는 부분), 약 24,000개는 27개 도구의 정의(파일 읽기, 파일 쓰기, 명령 실행, 서브에이전트 관리, 예약 작업 등등), 그리고 약 2,000개는 주입된 리마인더 블록(작업 상태, 사용 가능한 스킬 목록, 현재 환경 정보)이다.
OpenCode는 약 7,000개만 썼다. 시스템 프롬프트 약 2,000개, 10개 도구 정의 약 4,800개. 별도의 리마인더 블록도 없이 구조가 매우 간결했다.
여기에는 간과하기 쉬운 디테일이 하나 있다. 이 33,000개의 토큰은 “한 번 쓰면 끝”이 아니다. AI 코딩 도구의 작동 방식에서는 대화의 매 라운드마다—모델과의 매 왕복마다—이 하네스 콘텐츠를 다시 보내야 한다. 다시 말해, 당신의 작업이 AI와 10라운드를 오가야 한다면, 하네스만으로 330,000개의 토큰을 소비한다. 실제 코드와 대화는 여기에 포함되지도 않았다.
캐시는 원래 돈을 아껴야 하지만, Claude Code는 이를 망가뜨렸다
AI 서비스 제공자는 보통 “프롬프트 캐싱”이라는 메커니즘을 제공한다. 연속된 요청에서 대부분의 콘텐츠가 바뀌지 않는다면, 다시 계산하는 대신 매우 낮은 가격에 캐시에서 읽어올 수 있다는 것이다. 이는 비용 통제의 핵심 수단이다.
하지만 Systima는 결정적인 차이를 발견했다. OpenCode의 요청 접두부는 매번 바이트 단위로 완전히 동일했다. 이는 캐시를 한 번만 쓰면 그 뒤로는 매번 10분의 1 가격으로 읽어올 수 있음을 뜻한다. 반면 Claude Code는 동일 작업의 연속 요청에서 수만 개의 캐시 토큰을 반복적으로 다시 썼고, 같은 작업에서 캐시에 기록한 횟수는 OpenCode의 54배였다.
캐시 쓰기는 캐시 읽기보다 훨씬 비싸다. 바꿔 말하면, 사용자가 청구서 숫자가 올라가는 것을 보게 되는 이유는 상당 부분 도구가 캐시를 효율적으로 활용하지 못했기 때문이다.
프로덕션 환경의 실제 청구서: 33K에서 85K로
위의 33,000은 아직 “맨몸” 상태다. 프로젝트 설정도, 플러그인도, 추가 도구도 없다. 실제 프로덕션 환경은 어떤 모습일까?
Systima는 “누적 실험”을 진행했다. 먼저 빈 프로젝트에서 테스트한 뒤, 실제 개발 시나리오의 설정을 단계적으로 추가했다.
첫 단계, 72KB짜리 프로젝트 지침 파일(AGENTS.md 또는 CLAUDE.md, 코드 규범을 AI에게 알려주는 용도)을 넣었다. 이 한 단계만으로 요청마다 약 20,000개의 토큰이 추가됐다.
두 번째 단계, 경량 MCP 서버 5개를 연결했다(AI가 메일을 읽고 쓰거나, 작업을 관리하거나, 데이터베이스를 조회할 수 있게 하는 것). 여기서 다시 약 5,000~7,000개가 더해졌다.
이를 누적하면, 실제 개발 환경에서 Claude Code는 사용자의 질문을 읽기도 전에 이미 75,000~85,000개의 토큰을 소비했다. OpenCode도 비슷한 누적 상황에서 부풀어 오르지만, 시작점이 낮은 덕분에 절대값은 여전히 통제 가능한 수준이었다.
서브에이전트: 진짜 토큰 블랙홀
하네스 소비가 “연비가 다소 높은” 정도라면, 서브에이전트는 “연료 탱크가 새는” 격이다.
서브에이전트는 Claude Code의 중요한 기능 중 하나다. 작업이 복잡할 때 메인 에이전트가 여러 “분신”을 파견해 병렬로 일하게 하고, 각 서브에이전트가 독립적으로 코드를 읽고 문제를 분석해 결과를 반환한다. 효율적으로 들리지만, 대가는 놀랍다.
Systima는 같은 작업으로 비교했다. 직접 실행하면 121,000개의 토큰을 소비했다. 두 개의 서브에이전트로 병렬 실행하도록 바꾸자 소비량이 513,000개로 폭증했다. 원래의 4.2배다.
왜 이렇게 차이가 클까? 각 서브에이전트가 독립적인 작업 단위이기 때문이다. 자기만의 시스템 프롬프트(메인 에이전트보다는 간결하지만)가 있고, 자기만의 도구 세트가 있으며, 맥락을 이해하기 위해 프로젝트 파일을 다시 읽어야 한다. 서브에이전트가 작업을 마치면, 그 전체 대화 기록이 다시 메인 에이전트에게 “삼켜져” 참조 자료가 된다. 마치 두 사람에게 자료 조사를 시켰더니, 각자 돌아올 때 답만 가져오는 게 아니라 자기가 뒤진 모든 원본 파일을 한 상자씩 통째로 들고 오는 셈이다.
HN의 한 사용자 경험은 더 극단적이다. 그는 이렇게 썼다. “Claude Code에 비교적 큰 작업을 줬더니, 즉시 7개의 서브에이전트를 띄웠고, 내 예산이 다 타버릴 때까지 단 하나의 서브에이전트도 작업을 완료하지 못했다. 5시간 뒤 다시 시도했지만 결과는 똑같았다.” 반면 같은 작업을 메인 에이전트로 순차 실행하면 아무 문제도 없었다.
Anthropic의 비즈니스 모델 딜레마
여기까지 오면 자연스러운 의문이 떠오른다. 이것은 설계 결함인가, 아니면 비즈니스 모델의 필연인가?
Anthropic의 API는 토큰 단위로 과금된다. Claude Code는 공식 도구로서, 토큰 소비가 클수록 Anthropic의 수익도 커진다. 하지만 이것이 반드시 “의도적 설계”임을 뜻하지는 않는다. 오히려 일종의 구조적 인센티브일 가능성이 크다. 당신의 수익이 사용자가 얼마나 많은 토큰을 소비하느냐에 달려 있을 때, 오픈소스 커뮤니티처럼 하네스를 간결하게 다듬을 강한 동기는 생기지 않는다.
OpenCode가 7,000토큰이라는 “바닥”을 달성할 수 있었던 것은 상당 부분 그것이 오픈소스 프로젝트이기 때문이다. 그 설계 목표에는 API 수익 극대화가 포함되지 않는다. 반면 Claude Code의 27개 도구, 여러 겹의 리마인더 블록, 서브에이전트의 완전한 부트스트랩 메커니즘—각각의 설계 결정에는 “기능이 더 풍부하다”는 정당한 이유가 있다. 하지만 이 “더 풍부한 기능”들이 겹겹이 쌓이면, 사용자의 청구서는 그 부산물이 된다.
하지만 Claude Code가 이기는 순간도 있다
공정하게 말하자면, Systima의 테스트는 Claude Code에 유리한 시나리오도 발견했다.
여러 단계의 조작이 필요한 작업(코드 작성, 테스트 실행, 오류에 따른 수정, 재테스트)에서는 Claude Code의 총 소비량이 오히려 OpenCode보다 낮았다. 이유는 Claude Code가 여러 도구 호출을 하나의 요청에 묶어 처리하는 반면, OpenCode는 도구 호출 하나마다 요청 한 라운드를 돌기 때문이다. Claude Code는 매 요청의 기반부가 더 무겁지만, OpenCode는 묶음 처리 능력이 없어 기반부 오버헤드를 9번 중복 지불했고, 결국 총합은 오히려 더 많아졌다.
이 발견은 미묘한 사실을 드러낸다. 도구의 토큰 효율은 단지 기반부가 얼마나 가벼운가에만 달린 게 아니라, 워크플로를 어떻게 조직하느냐에도 달려 있다. 기반부가 무겁지만 묶을 수 있는 것과, 기반부가 가볍지만 반복해서 돌려야 하는 것—어느 쪽이 나은지는 구체적인 작업에 따라 달라진다.
이것이 일반 사용자에게 의미하는 바는?
당신이 코드를 짜지 않는다면 이것을 “프로그래머의 문제”라고 여길 수도 있다. 하지만 실제로는, AI 도구가 “채팅”에서 “일하기”로 넘어가면서 이런 종량제 과금 모델은 모든 사용자에게 영향을 미치게 된다.
Cursor에서 코드 한 줄을 고치거나, Claude Code에서 AI에게 버그 하나를 고쳐 달라고 할 때, 매 조작 뒤에서는 비슷한 이야기가 벌어지고 있다. 대량의 시스템 지침이 반복 전송되고, 서브에이전트가 백그라운드에서 생겼다 사라지며, 캐시가 반복적으로 다시 쓰인다. 그리고 청구서는 이 보이지 않는 동작들 속에서 조용히 쌓여 간다.
Systima의 실험은 원래 블랙박스 안에 숨겨져 있던 숫자들을 햇빛 아래로 끌어냈다. 사용자로서 이 숫자들의 존재를 아는 것 자체가 일종의 정보 측면의 권한 부여다.
혹은 더 직설적으로 말하면, 다음번에 API 청구서를 볼 때 당신은 알게 될 것이다. 그 위의 숫자 중에서 당신이 실제로 사용한 부분은 아마 극히 일부에 불과하다는 것을.
참고 링크:
- Systima: Claude Code vs OpenCode Token Overhead
- HN 토론 (item?id=48883275)