tokenmaxxing #

올해 들어서 AI 코딩 도구를 쓰는 개발자들 사이에 “이번 주에 토큰 2,100억 개 썼다"는 식의 자랑이 유행하고 있습니다. 보도에 따르면 Meta는 임직원 8만여 명의 토큰 사용량을 순위로 보여주는 사내 대시보드를 운영했는데 한 달에 2,810억 토큰을 쓴 직원이 1위에 올랐다고 합니다. 어떤 회사에서는 토큰 사용량을 직원의 인사평가에 반영하기도 한다네요. 이처럼 토큰을 아끼는 게 아니라 더욱 더 많이 쓰는 것을 옹호하는 쪽에서는 이를 token maximalism (tokenmaxxing) 이라고 부릅니다.

저는 개인적으로 tokenmaxxing에 대해서는 회의적입니다. AI에게 모두 맡기는 작업들과 사용자가 귀찮은 것을 피하기 위해 토큰 사용량이 늘어나는것은 아닐까 하는 생각이 있거든요. 그래서 실제로 tokenmaxxing이라는 트랜드가 생겨나게 된 과정과 이를 옹호하는 곳과 반대하는 곳 각각의 의견을 한번 정리해보고, 실제로 어느 작업에 토큰을 많이 사용하는지 확인함으로써 tokenmaxxing이 실질적으로 작업량에 도움을 주는지도 확인해보려고 합니다.

1. 이 트렌드가 어디서 왔고 어떤 논리로 굴러가는지
2. 반대쪽에서는 뭐라고 하는지
3. 실제로 토큰이 어디에 쓰이는지

트랜드의 시작 #

토큰을 많이 쓰자는 움직임은 갑자기 나타난 것이 아닙니다.

2024년 9월, OpenAI가 o1을 내놓으면서 “추론 시점에 토큰을 더 쓰면 답이 더 좋아진다"는 test-time compute scaling 방식을 제안했고, 이것이 새로운 스케일링 축으로 자리 잡았습니다. 이때부터 토큰을 더 태우는 것이 곧 성능이라는 생각이 시작되었습니다.

2024년 11월, a16z의 Guido Appenzeller가 LLMflation이라는 글에서 “같은 성능 기준으로 LLM 추론 비용은 매년 약 10배씩 떨어진다.” 는 놀라운 수치를 발표했습니다. 실제로 GPT-3 수준의 토큰이 2021년에는 100만 토큰당 60달러였는데 2024년에는 0.06달러까지 떨어졌습니다. 자그마치 3년 만에 1,000분의 1로 감소한 것입니다.

2025년 1월, DeepSeek 쇼크로 AI 주가가 흔들리던 날, Microsoft CEO 사티아 나델라가 제본스의 역설을 언급했습니다. 이 역설은 자원을 쓰는 효율이 좋아지면 소비가 줄어드는 게 아니라 오히려 폭증한다는 19세기 경제학 명제를 나타내는데요, 이때부터 많은 사람들이 토큰이 싸질수록 토큰 소비는 늘어난다고 생각하기 시작했습니다.

2025년 3월, Steve Yegge라는 사람이 Revenge of the Junior Developer에서 “코딩 에이전트 하나가 시간당 10~12달러어치 토큰을 태우는데, 개발자 한 명에게 하루 80~100달러의 토큰 예산을 주면 생산성이 몇 배가 되며 이것은 고민할 필요도 없는 장사(no-brainer)“라는 결론을 내놓았습니다. 링크드인에서는 수많은 사업가들이 AI를 ‘24시간 쉬지않고 일해주는 존재’라고 표현했고, 이는 AI 사용에 필요한 토큰의 가격이 나름 합리적이며 충분히 지출할만한 가치가 있다는 분위기를 만들기 시작했습니다.

2025년 6월, Anthropic이 멀티에이전트 리서치 시스템이라는 글에서 “토큰을 많이 쓸수록 좋은 결과를 가져온 작업들이 전체의 80% 이상이었다"는 결론을 제시했습니다. 심지어 하나의 에이전트에서 오래 일하는 것보다, 가장 똑똑한 모델을 팀장으로 임명해서 가벼운 모델들에게 일을 나눠서 시키는 멀티 에이전트 방식이 약 90.2% 좋은 결과를 받았다고도 했습니다. 물론 이렇게 멀티 에이전트를 사용하기 위해 단일 에이전트 대비 약 15배나 많은 토큰을 사용해야 했죠. 결국 “성능을 올리고 싶으면 토큰을 더 쓰게 하라"는 결론이 나오게 되었고, 이게 token maximizing 진영의 핵심 근거로 자리잡았습니다. 단 토큰을 많이 사용하는만큼, 그 비용을 정당화할 만큼 가치 있는 작업에만 쓰라고 언급하기도 했습니다.

2025년 중반부터 최근까지 Claude Code의 “ultrathink” 키워드(생각 토큰 예산을 3만 2천 개까지 늘리는 숨은 명령어), 프롬프트를 무한 루프로 다시 먹이는 Ralph Wiggum 루프, 에이전트 20~30개를 병렬로 돌리는 Yegge의 Gas Town 같은 실천법이 계속해서 쏟아지기 시작했습니다. 사용자들은 리더보드에 ccusage로 뽑은 토큰 사용량을 올리면서 게임처럼 경쟁하고 자랑하기 시작했습니다.

찬성: 토큰은 싸고, 사람은 비싸다 #

tokenmaxxing에 대해 긍정적으로 생각하는 사람들은 “토큰 가격은 매년 10분의 1로 떨어지고 있지만 개발자 시급은 그대로인 시장에서, 사람 시간을 아껴주는 토큰 지출은 전부 남는 장사” 라고 이야기합니다.

• Anthropic에서 공식적으로 제시한 문구에 의하면, 성능은 토큰에 비례합니다. 검증 에이전트를 병렬로 붙이고, 여러 에이전트 사이의 심판을 세우고, 최대한 넓은 범위의 탐색을 시키는 것 모두가 더 많은 토큰을 태워 품질을 사는 방법입니다.
• In Defense of Tokenmaxxing에서는 현재 수많은 조직이 AI 활용법을 학습하는 시기이므로 “가치 있는 실수에 토큰을 태우는 것을 두려워하지 말라"고 주장합니다. 글에서는 600달러짜리 Claude 청구서보다 23달러짜리 배달비 결제를 더 깐깐하게 보는 문화에 대해 비판하고 있습니다.
• Token Maximalism이라는 에세이애서 저자는 “오늘 비싼 것은 내일 저렴해지며, 모든 가치는 비용보다 중요하다"며 현재 단가가 아니라 확보 가능한 능력을 기준으로 토큰 사용을 아끼지 말라고 합니다.

반대: 토큰과 생산성은 별개다 #

2026년 2분기부터 토큰의 샤용량이 꼭 생산성과 비례하지 않다는 의견이 점점 많아지기 시작했습니다.

• 엔지니어링 분석 업체 Jellyfish가 개발자 7,548명의 2026년 1분기 데이터를 분석한 결과(TechCrunch 보도), “토큰을 가장 많이 쓴 그룹이 PR을 가장 많이 만들었다. 이 과정에서 토큰 비용은 10배 사용했지만, 생산성은 2배 증가했다” 고 발표했습니다. 결국 토큰의 사용량에 비해 생산성의 증가는 그렇게 크지 않았습니다. 같은 보도에서 인용된 다른 데이터에서도 비슷한 방향이 보였는데요, AI를 많이 사용한 그룹에서 AI로 작성한 코드를 다시 고치는 churn 작업이 최대 861% 늘었다는 분석도 내놓았습니다.
• METR에서 진행한 무작위 대조 실험에서는 숙련 오픈소스 개발자들이 AI를 쓸 때 실제로는 19% 느려졌는데, 본인들은 20% 빨라졌다고 믿었다고 발표했습니다. 단순히 1%의 차이로 느껴질 수 있지만, 사람이 체감적으로 느끼는 생산성의 척도가 실제로 AI를 통해 향상되는 생산성과 동일하지 않다는 논리를 제시했습니다.
• 토큰으로 코드 작성은 무한정 늘릴 수 있지만, 그 코드를 읽고 검토하고 책임지는 것은 여전히 사람이라는 의견입니다. AI를 많이 사용하는 팀에서 PR 머지가 98% 늘어나는 동안 리뷰 시간은 91%만 늘었다는 분석이 있습니다(일부에서는 AI를 통해 리뷰할 내용이 정리되어 있기 때문에 시간이 항상 비례할 필요는 없다고 말합니다). 이에 curl 메인테이너 Daniel Stenberg는 “AI는 루프 안의 인간 능력을 늘려주지 않는다. 비용을 리뷰로 옮길 뿐이다"라고 표현하기도 했습니다.
• 토큰 사용량이 지표가 되는 순간, 정작 생산성의 기준이 되는 중요한 항목들은 모두 판단에서 제외된다는 의견입니다. Don’t Tokenmax라는 글에서는 토큰 사용량 리더보드가 “코드 라인 수로 측정되는 KPI"라고 지적하며, 토큰당 산출이 아니라 작성된 후 계속해서 유지되는 코드(retention) 를 기준으로 삼아야 한다고 제안합니다. Uber는 Claude Code 확산 넉 달 만에 연간 AI 예산을 소진했고, Meta는 결국 사내 토큰 지출에 상한을 걸었다는 보도도 존재합니다.
• Stanford와 Microsoft Research의 연구진이 SWE-bench로 프론티어 모델 8개의 토큰 소비를 분석한 논문(How Do AI Agents Spend Your Money?)에 따르면, 에이전트 작업은 채팅 대비 약 1,000배의 토큰을 쓰는데 그 비용의 대부분은 에이전트가 행동할 때마다 지금까지의 맥락 전체를 다시 읽는 “입력토큰(context snowball)“에서 들어간다고 표햔했습니다. 심지어 같은 작업 안에서도 실행할때마다 토큰이 최대 30배까지 널뛰고, 정확도는 중간 수준의 토큰 지출에서 이미 최고점을 갱신하는 경우도 많았습니다. 결국 토큰을 더 많이 쓴다고해서 결과물이 항상 좋아지지는 않는다는거죠.

직접 체크해보기 #

직접 확인해보기 위해, 최근에 Claude Code로 작업한 세션 중 4개를 선정해서 나의 토큰은 어디에 쓰였는지 확인해보기로 했습니다. Claude Code는 세션 기록을 로컬 JSONL 파일(~/.claude/projects/…)애 저장하고 있는데, 모델 응답마다 입력·출력·캐시 토큰의 내용을 기록하고 있습니다. 저는 10일간 Go 기반의 백엔드 프로젝트를 작업한 4개의 세션을 기준으로 삼았습니다.

• 작업한 세션 수: 4개
• 사람 턴: 333개
• 모델 응답: 5,507개

여기서 사람 입력 하나와 그에 따른 모델 응답들을 한 “턴"으로 묶고, 턴 안에서 사용한 도구를 패턴으로 분석해서 카테고리로 삼았습니다.

실측 데이터는 필자의 Claude Code 세션 4개(2026년 7월, 모델 응답 5,507개)를 규칙 기반으로 분류한 근사치입니다. 분류 스크립트는 transcript JSONL의 메시지별 usage 필드를 집계했으며, 비용은 API 정가 환산 기준으로 계산했습니다(구독 요금제 실 지출과 다를 수 있습니다). 그러므로 일반화에는 주의가 필요합니다.

• 파일이 편집되면 모두 코드 작성으로 분류하였으며, 그중 도구 실행 에러(빌드 실패, 테스트 실패 등) 이후의 응답은 재처리
• 커밋·푸시·머지·이슈 close 명령이 있으면 정리
• 편집이 없으면 계획 분석, 사용자에게 질문하고 끝나는 턴은 확인·질문, 나머지는 탐색·계획

턴 단위로 토큰 사용량을 측정하게 되면 오차가 생기기 쉽고, 특히 도구의 상태에 따라 재처리 판정도 주관적일 수 밖에 없습니다. 이에 측정결과가 보수적일 수 있지만, 정밀 측정이 목적이 아닌 토큰 사용의 흐름을 대략적으로 파악하기 위한 것이니 그점을 감안하고 봐주시면 감사하겠습니다.

결과는 아래와 같으며, 비용은 API 정가(Opus 4.8 기준 입력 $5 / 출력 $25 per MTok, 캐시 읽기는 입력의 0.1배, 캐시 쓰기는 1.25~2배)로 환산했습니다.

1. 순수 코딩은 3분의 1뿐이다 #

“계획대로 코드를 쓰는” 토큰은 전체의 36%로 나왔으며, 나머지 3분의 2는 계획을 맞추고, 예상 못 한 문제를 다시 처리하고, 커밋·문서·린트를 정리하는 데 소비되었습니다. 토큰 총량을 생산성으로 읽으면 안 되는 이유가 여기 있었는데요, 토큰의 대부분은 코드가 아니라 코드 작업을 위한 일에 사용되는 것으로 확인되었습니다. 린트의 경우에는 코드 작업과 연관되어 있지만, 제가 작업하는 방식이 ‘코드 작업을 지시한 이후에 검토 작업으로 린트와 문서작성을 지시’해서 이런 결과가 나온 것 같습니다.

2. 재처리에 대한 높은 빈도수 #

계획에 없던 문제를 만나 다시 고치는 재처리(rework)가 코드 작성 토큰(3.93M)의 31%, 전체 비용의 19.5%를 차지했습니다. 이건 저의 코딩 습관과도 연관되어있는데, 저는 AI에게 코드 작업을 부탁한 뒤 대부분 코드에 대한 검토를 한번더 부탁하고 누락되거나 잘못된 부분을 확인하는 편이라서 이렇게 측정된 것 같습니다.

반대로 “설명이 부족해서 되묻는” 확인·질문은 비용의 7.8%가 나왔습니다. 개인적으로 Claude Code의 응답 말투가 너무 이해하기 어려워 되묻는 경우가 많아서 이렇게 나온 것 같습니다. 한편으로는 우선 물어보고 나중에 고치는 방식에 대해 꼬집은 내용처럼 token maximizing 반대 측의 “나쁜 스펙이 토큰을 태운다"는 주장을 실제 측정값에서 보여준 것은 아닌가 하는 생각도 들었습니다.

3. 비용의 70%는 기억을 유지하기 위해 사용된다 #

만약 토큰 수가 아니라 비용 구성으로 보면 그림이 완전히 달라집니다.

• 처리된 입력 토큰의 98.6%가 프롬프트 캐시 재읽기였고, 이게 비용의 70%나 되었습니다.
• 모델이 실제로 생산한 출력은 비용의 10%에 불과합니다. 조심스럽게 대시보드에 나온 수많은 토큰 사용량은 이러한 캐시 재읽기일수도 있겠다 생각했습니다.
• 겉보기 토큰 수는 폭발적이어도 단가는 정가의 10분의 1. tokenmaxxing이 숫자만큼 무모하지 않은 이유이며 동시에 토큰 총량이 지표로서 크게 의미없을 수 있다는 생각이 들었습니다.

결론 #

결국 tokenmaxxing이 토큰당 비용이 아니라, 검증까지 끝난 결과물당 비용에 집중한다고 볼때, 비싼 모델로 한번에 작업을 마무리하는 것이 저렴한 모델에서 여러번 재시도하는 것보다 유리하다는 결론을 얻을 수 있었습니다. 토큰의 사용량만 가지고는 생산성을 판단할 수 없으며, 실제로도 생산성은 토큰의 사용량이 아닌 얼마나 좋은 모델을 위해 토큰을 적절하게 사용하는 것이냐에 달려있었습니다.

내가 개발자라면, 실무 과정에서 아래 4가지를 챙기면서 작업하면 훨씬 좋을 것 같습니다.

1. 계획과 확인 질문에 좋은 모델을 이용하여 많은 토큰을 사용합니다.
2. 검증에 토큰을 많이 사용합니다. 특히 좋은 모델을 이용하여 병렬 검증·테스트·리뷰를 작업할 때 효율적인 지출로 성능을 올릴 수 있습니다.
3. 토큰 사용량이 지표가 되면 안됩니다. 살아남는 코드와 결과물당 비용을 기준으로 삼아야 합니다.
4. 가능하다면 내 토큰이 어디로 가는지 확인합니다. 나의 사용처를 정확히 아는 것이, 어디에 토큰을 쓰고 아껴야할지 확인할 수 있는 첫걸음입니다.