Tokenmaxxing 논쟁은 요점을 놓치고 있다

I’m happy to translate the article for you, but I’ll need the full text of the post (the content you’d like translated). Could you please paste the article’s body here? Once I have the content, I’ll provide a Korean translation while keeping the source link and all formatting exactly as you requested.

Introduction

Jensen Huang은 모든 엔지니어가 매일 100,000 토큰을 소비해야 한다고 말합니다. Shopify의 CTO는 실제 지표는 그것을 어떻게 활용하느냐라고 말합니다. 두 사람 모두 옳습니다. 두 사람 모두 위험합니다.

토큰맥스킹 서사

“tokenmaxxing” 대화는 Huang의 키노트 주장 이후 급속히 퍼졌다: 연간 6자리 수 토큰을 소모하지 않는 $200K 엔지니어는 AI를 충분히 활용하지 못하고 있다는 것이다. 논리는 타당해 보인다—토큰이 많을수록 AI 지원이 늘고 생산성이 높아진다. 하지만 실제로는 그렇지 않다.

Shopify의 Mikhail Parakhin은 지구상에서 가장 AI‑집약적인 엔지니어링 조직 중 하나를 운영한다. 내부 데이터에 따르면 2025년 12월이 일일 활성 사용량이 급격히 상승한 전환점으로 나타났다. 그러나 분포는 크게 치우쳐 있다: 상위 10 % 사용자가 하위 75 %보다 기하급수적으로 더 많이 소비한다. 이 추세가 지속되면 “한 사람이 모든 토큰을 소비하는” 상황이 된다.

이것이 원시 볼륨 지표의 문제점이다: 움직임을 최적화할 뿐, 실제 진전을 최적화하지 않는다.

토큰‑집약 워크플로우의 안티패턴

Parakhin은 서로 소통하지 않는 여러 에이전트를 병렬로 실행하는 안티패턴을 설명합니다. 이는 토큰을 효율적으로 소모합니다—만약 목표가 토큰을 소모하는 것이라면 말이죠. 반복 없이 병렬 생성은 단지 비용이 많이 드는 주사위 굴리기와 같습니다.

Shopify 데이터에 따르면 실제로 효과적인 것은 폭보다 깊이입니다:

• 연속 연구 루프 – 한 에이전트가 구축하고, 다른 에이전트가 다른 모델로 비판하며, 첫 번째 에이전트가 피드백을 기반으로 수정합니다.
• 높은 지연 시간, 높은 품질, 죽음의 길에 낭비되는 토큰 감소.

이는 실제 시스템에 적용됩니다: 최고 벤치마크 점수를 가진 코딩 모델은 종종 부풀린 diff를 생성합니다(예: GPT‑5.4 과다 편집; Opus 4.6 부족 편집). 진정으로 중요한 평가 지표는 pass@1이 아니라, 수정에 세 파일을 건드렸는지 혹은 삼십 파일을 건드렸는지입니다. 인지적 복잡성이 토큰 수보다 우선합니다.

토큰 예산을 KPI로 제도화하기

• 마이크로서비스 부활 – 팀이 독립적으로 배포하고 병렬로 더 많은 토큰을 소모할 수 있게 합니다.
• PR 리뷰 대기열이 병목 – 인간이 느리기 때문이 아니라 AI가 생성한 코드 양이 어떤 리뷰 역량보다도 빠르게 증가하기 때문입니다.

Shopify의 내부 솔루션은 생성보다 리뷰에 더 많은 비용을 투자하고 있습니다. 그들의 비판‑대‑생성 토큰 비율은 대부분의 팀과는 의도적으로 반대로 설정되었습니다. 검증에는 가장 강력한 모델(Opus 4.6, GPT‑5.4 Pro)을 사용하고, 생성은 저렴하고 빠릅니다. 검증은 느리고 비용이 많이 듭니다.

메트릭 전환: 소비에서 결과로

올바른 방향의 주장은 개발 루프에 더 많은 AI 연산이 필요하다는 것이지만, 이를 “엔지니어당 토큰 예산”으로 표현하면 잘못된 인센티브를 만들게 됩니다. 이는 결과보다 소비가 목표라는 인식을 심어줍니다.

2000년대의 라인‑오브‑코드(LOC) 메트릭이 그와 비슷합니다. 우리는 코드가 많을수록 버그, 유지보수 비용, 기술 부채가 늘어난다는 것을 고통스럽게 배웠습니다. 사이클로매틱 복잡도, 테스트 커버리지, 배포 빈도 등을 측정하기 시작하면서 LOC는 허영 메트릭이 아니라는 것이 밝혀졌습니다. 토큰 소비도 같은 진화를 필요로 합니다.

중요한 것은 배포된 가치와 토큰 사용량의 비율입니다.

• 50 토큰 프롬프트 하나가 생산 현장의 사고를 해결하는 것이 50,000 토큰을 사용한 추측성 아키텍처 탐색보다 가치가 높습니다.
• 병합 전 보안 결함을 잡아내는 단일 리뷰 루프는 경쟁 구현을 생성하는 열 개의 병렬 에이전트보다 더 큰 가치를 가집니다.

인프라에 대한 베팅은 단순히 더 큰 컨텍스트 윈도우나 저렴한 추론이 아닙니다. 바늘을 실제로 움직인 것을 이해하는 트레이스 기반 평가 시스템입니다. 파라킨은 Shopify가 다음과 같은 내부 텔레메트리를 구축하고 있다고 언급합니다:

• PR 병합 속도
• AI‑생성 변경에 대한 롤백 비율

— “엔지니어당 소비된 토큰”이 아니라.

올바른 접근 방식의 장점

이 방식을 제대로 구현한 팀은 복합적인 이점을 누립니다:

• 비판 에이전트가 혼란을 방지하기 때문에 코드베이스가 더 깔끔해집니다.
• 검토 병목 현상이 자동화되어 과부하가 없으므로 배포 파이프라인이 더 빨라집니다.
• 엔지니어는 수렴하는 반복 루프에 토큰을 사용하고, 발산하는 병렬 브랜치에는 사용하지 않습니다.

이번 분기에 AI 예산을 설정한다면 질문을 뒤바꿔 보는 것을 고려하세요:

• “우리가 감당할 수 있는 토큰 수는 얼마인가?” 대신 “우리의 비판‑대‑생성 비율은 얼마인가?” 라고 물어보세요.
• 소비량을 추적하는 대신 프롬프트에서 실제 제품으로의 전환율을 추적하세요.

Conclusion

Tokenmaxxing은 함정이다. 이 단계에서 승리하는 팀은 토큰 최소화 팀이며—토큰당 출력량을 최대화하고, 달러당 토큰 수를 최대화하는 것이 아니다.