Tokenmaxxing은 죽었다, Tokenmaxxing 만세: 분석 노트

2026-06-29 · 2026-06-29_tokenmaxxing-is-dead-long-live-tokenmaxxing.md

#AI #LLM #tokenmaxxing #기업전략 #기술도입 #교육

원문 출처

Tokenmaxxing은 죽었다, Tokenmaxxing 만세: 분석 노트

한 줄 요약

Tokenmaxxing(토큰 과다 소비 현상)은 처음에 경영진이 AI 도구를 전사에 강제로 퍼뜨리기 위한 '둔탁한 정책'이었지만, 이제는 모델이 오래 실행될수록 정확도가 올라가는 '누적 정확성(compounding correctness)' 패러다임 덕분에 진짜 생산성 전략으로 변하고 있다. 그러나 비용 폭등과 CFO의 압박, 두 가지 서로 다른 형태의 tokenmaxxing(개발자용 vs 파이프라인용) 사이의 혼란은 여전히 과제로 남아 있다.

원문 핵심 내용

### Tokenmaxxing의 정의와 등장 배경: 경영진의 '의도된 강제' 전략

원문 필자인 Amol(Agentics)은 tokenmaxxing을 "경영진이 실수로 직원들에게 쓸모없는 작업에 토큰을 낭비하게 한 현상"이라는 통념을 정면으로 반박한다. 대표 사례는 Meta. 한 Meta 직원이 "토큰 사용량을 올리기 위해 두 AI 에이전트를 하루 종일 서로 대화하게 했다"고 증언할 정도로 극단적이었다. 하지만 Amol은 이 현상을 "경영진이 일부러 직원들이 무의미한 토큰을 태우도록 장려한 것"이라고 해석한다. 이유는 간단하다. 몇 달 전만 해도 시니어 인력 대다수가 AI 도구 사용을 극도로 거부했고, 설득에 성공해도 의도적으로 나쁜 방식으로 사용했기 때문이다. 위에서 내려오는 토큰 사용 압박은 둔탁한 강제 수단(blunt force policy) 이었고, 덕분에 지금은 거의 모든 팀이 적어도 Cursor 사이드바 정도는 쓴다.

### 구체적인 수치와 비용 구조: 두 가지 극단의 가격 비교

원문은 모델별 토큰 가격을 상세히 비교한다.

  • 오픈 모델 GLM 5.2: 입력 100만 토큰당 약 $1.4, 출력 100만 토큰당 약 $4.
  • Opus 4.X 시리즈(Anthropic 최상위): 입력 100만 토큰당 $5, 출력 100만 토큰당 $25.
  • Haiku 4.5: 입력 $1, 출력 $5 (GLM 5.2보다 성능이 낮음).

즉, GLM 5.2는 Haiku보다 강력하면서도 일부 벤치마크에서는 GPT 5.5를 능가하는데 가격은 1/5 수준이다. 이 차이가 향후 tokenmaxxing의 중심을 오픈 모델로 옮길 핵심 동력이 된다. 또한 보안 분야 사례: AISI(미국 AI 안전 연구소)가 Mythos 모델 테스트에 1회당 100M 토큰(약 $12,500)을 예산으로 잡았고, 10회 실행에 $125,000를 썼다. 더 놀라운 점은 이 토큰 예산 범위 내에서 수익 체감(diminishing returns)이 전혀 나타나지 않았다는 사실이다.

### 누적 오류에서 누적 정확성으로: 게임 체인저

과거에는 에이전트를 오래 실행할수록 작은 오류(환각 포함)가 쌓여 되돌릴 수 없는 '누적 오류(compounding error)'가 발생했다. 따라서 인간 감독이 필수였고, 에이전트를 24시간 돌릴 이유도 없었다. 그러나 최근 '누적 정확성(compounding correctness)' 환경이 도래했다. "더 많은 토큰을 쓰면 더 좋은 결과를 얻는다"는 계산이 성립하게 된 것이다. 저자는 이것이 원래의 무의미한 tokenmaxxing을 진짜 가치 있는 tokenmaxxing으로 바꾸는 핵심이라고 주장한다. 특히 '루프(loop)' 기술 덕분이다. Boris Cherny(Claude Code 창시자)가 무대에서 'loops'를 언급하자 모두 열광했다. 루프의 본질은 에이전트가 자기 턴을 마치면 같은 프롬프트를 다시 시작하게 함으로써 복잡한 명세를 자동으로 분할·해결하게 하는 구조다. 2024년 7월부터 존재했지만, 누적 정확성이 없으면 제대로 작동하지 않았다.

### 두 가지 tokenmaxxing과 소프트웨어 팩토리로의 귀결

저자는 tokenmaxxing에 두 가지 형태가 있다고 구분한다.

  1. 개발자용 토큰 지출: 엔지니어가 Claude Code 같은 도구로 루프를 돌며 생산성을 높이는 경우. 생산성 향상이 비용을 정당화한다.
  2. 파이프라인용 토큰 지출: 개발자가 여전히 손으로 코드를 짜고, 그 코드로 일회성 에이전트를 만들어 특정 작업(예: 데이터 라벨링)을 수행하게 하는 경우. 이 에이전트는 비결정적이고 취약하며, 정확도를 높이기 위해 '품질 확인 에이전트'를 또 붙이면 토큰 비용이 3배로 뛴다. 저자는 이 방식이 "잘 작동하지 않으며" 돈 낭비라고 평가한다.

자연스러운 종착점은 소프트웨어 팩토리(software factory) 또는 다크 팩토리(dark factory) 다. 인간이 명세만 입력하면 코드베이스가 자동으로 코드를 작성·리뷰·테스트·버그 수정까지 하는 구조다. StrongDM 사례: 하루 $1000 토큰을 목표로 한다는 주장은 과장이지만, 자체 팩토리는 월 $600 정도를 쓴다. 저자는 "아직 확산되지는 않았지만 잠재적 인센티브는 분명히 존재한다"고 결론짓는다.

Hacker News 커뮤니티 반응

댓글 처리 기록: HN 댓글 166개를 읽음. 댓글 생략 없음. 처리 방식: 전체 댓글을 2개 chunk로 먼저 읽고 중간 요약한 뒤 최종 노트에서 통합.

댓글 처리 기록: HN 댓글 2개 chunk(원댓글 + 대댓글 포함 다수)를 읽고 아래 12개 이상의 세부 논점으로 정리.

### [aurareturn] "Tokenmaxxing은 일시적 전환 장치였다" vs [herval] "지나치게 자비로운 해석"

  • 주장: aurareturn은 원문 저자와 같은 입장. 경영진은 AI 도입 속도가 너무 느리다고 판단해 단순한 메시지로 전사 변화를 강제할 필요가 있었다. Dan Luu의 트윗을 인용해 "대규모 조직은 한 번에 하나의 단순한 메시지만 전달할 수 있다"고 지적.
  • 근거: 자신이 일하는 회사에서 실제로 같은 논리로 결정을 내렸다고 주장. 직원들이 강제적 토큰 사용을 통해 AI 환경에 적응했다는 경험담.
  • 반론/대댓글: herval은 "대부분의 회사는 '다들 하니까' 하는 FOMO나 '프로그래머 한 명으로 팀 전체를 대체할 수 있는지 시험'하려는 목적이었다"며 반박. "토큰 소비가 적다는 이유로 해고된 사례도 있다"고 주장했지만, no-name-here가 "출처를 요구하며 검색되지 않는다"고 지적해 논점이 약화됨.
  • 대표 작성자: aurareturn, herval, no-name-here
  • 내 판단: aurareturn의 주장은 대규모 조직의 변화 관리 관점에서 설득력이 있다. 그러나 herval의 지적처럼 모든 경영진이 그렇게 전략적이었다고 보기는 어렵다. 실제 사례가 혼재되어 있으므로 '의도된 경우와 무작정 따른 경우가 공존'한다는 결론이 합리적.

### [SR2Z] "목수 비유: 전동공구를 샀다면 톱밥을 확인하라"

  • 주장: "직원들이 AI를 안 쓴다면 사용량(톱밥)을 확인하는 게 합리적이다. FAANG 경영진이 나쁜 지표의 위험을 모를 리 없다."
  • 근거: 전동공구(예: Cursor)를 구매했는데 직원들이 손도구만 고집한다면, 경영진이 '톱밥'(토큰 사용량)을 체크하는 것은 자연스러운 반응이라는 비유.
  • 반론/대댓글: JoshTriplett은 "톱밥 세지 말고 질(quality)과 피드백을 측정하라"고 제안. 이에 대해 no-name-here는 "대규모 조직에서 완고한 직원을 바꾸는 더 나은 방법이 있는가?"라고 반문하며 실용성 논쟁으로 전환.
  • 대표 작성자: SR2Z, JoshTriplett, no-name-here
  • 내 판단: SR2Z의 비유는 직관적이지만, 톱밥만 확인하면 톱밥을 의도적으로 많이 만들기 위해 쓸데없는 절단까지 하게 된다. Meta 사례가 이를 증명.

### [TeMPOraL] "이미 3년간 실험·워크숍·상담을 했고 결론은 명백했다 – 강제가 필요했다"

  • 주장: "직원에게 물어보면 되지 않느냐"는 반론에 대해, 이미 수년간 모든 소프트 채널을 동원했지만 일부 직원은 완고하게 거부했다. 따라서 강제가 유일한 해결책이었다.
  • 근거: 자신이 경험한 조직 사례를 근거로 "당근(교육·동기부여)이 실패했으므로 채찍(토큰 지표)을 썼다. 엔지니어 중 상당수는 점수판(scoreboard)이 있으면 무의식적으로 속는다"고 주장.
  • 반론/대댓글: cyphar는 "전동공구를 사기 전에 직원과 상의해야 한다"는 원칙론을 폈지만, TeMPOraL은 "이미 상의했고 도구도 저렴하며 강제는 최후 수단"이라고 반박.
  • 대표 작성자: TeMPOraL, cyphar
  • 내 판단: 매우 현실적인 주장. 이상적인 의사소통만으로 조직 변화가 가능하다는 환상을 깨준다. 다만 '강제'가 장기적으로 직원의 내재적 동기를 죽일 위험도 고려해야 한다.

### [Aurornis] "토큰 불안(Token Anxiety) 현상: 리더보드가 없어도 직원들이 선점 소비"

  • 주장: 소셜미디어에서 tokenmaxxing 정책이 확산되면서, 자사에는 리더보드가 없음에도 직원들이 "내 토큰 사용량이 평가될까" 불안해하기 시작했다. 그 결과 토큰 예산이 생기고 선점 소비(선제적 토큰 사용) 가 벌어지는 역설이 발생.
  • 근거: 실제 관찰된 현상. "경영진이 토큰 사용량을 보진 않지만, 혹시 볼까 봐 미리 써두는" 심리.
  • 반론/대댓글: 이 현상에 대해 다른 댓글러들은 "자기 충족적 예언"이라고 평가.
  • 대표 작성자: Aurornis
  • 내 판단: 문화적 전염 효과의 좋은 예다. 토큰 불안은 tokenmaxxing이 단순한 정책을 넘어 조직 심리학적 현상으로 확장되었음을 보여준다.

### [watwut] "강제로 AI를 의미 있게 활용하게 하는 방법? 그런 결과를 낸 적 없다"

  • 주장: "경영진의 비이성적 불안이 원인일 뿐, tokenmaxxing 정책이 실제로 의미 있는 AI 활용을 강제한 적은 없다."
  • 근거: 자신이 본 여러 회사에서 tokenmaxxing 정책은 형식적 사용(무의미한 대화 등)만 양산했고, 진정한 생산성 향상으로 이어지지 않았다고 단언.
  • 반론/대댓글: vineyardmike는 "자사 경영진이 명시적으로 'AI를 업무의 여러 부분에 던져보고 피드백을 받자'고 목표를 공유했으며, 실제로 유용한 워크플로가 여러 개 나왔다"고 반박. 즉, 의도와 실행이 중요하다는 입장.
  • 대표 작성자: watwut, vineyardmike
  • 내 판단: watwut의 회의론은 실제로 많은 기업이 tokenmaxxing을 도입했으나 실패한 경우와 일치한다. 그러나 vineyardmike의 사례처럼 명확한 목표가 있는 경우는 성공 가능성이 높다. 결국 정책의 설계와 피드백 루프가 성패를 가른다.

### [linsomniac] "우리 회사는 $50/월 한도였는데, Claude Code의 가치를 깨닫지 못하는 직원들"

  • 주장: 자사는 AI 지출에 매우 인색했다. 평균 직원은 $50/월, 리더인 본인도 $100/월 한도였다. Claude Code가 큰 도움이 된다는 걸 깨달은 후에도 대부분의 직원은 비용 최대화(cost-maxing) 에 갇혀 "왜 세션 한도에 걸리냐"고 불평했다.
  • 근거: 1인당 적은 예산으로는 실제 생산성 향상을 체험할 시간이 부족하다는 경험.
  • 반론/대댓글: 이 댓글은 tokenmaxxing 반대 상황(예산 부족)에서도 문제가 발생함을 보여준다.
  • 대표 작성자: linsomniac
  • 내 판단: 흥미로운 대조점. tokenmaxxing의 반대 극단(예산 극도 제한)도 AI 도입을 저해한다. 적절한 '실험 예산'의 중요성을 시사한다.

### [metaltyphoon] "우리 회사는 6개월 내 3.5~6만 달러를 토큰에 쓰도록 강제했다"

  • 주장: "tokenmaxxing은 애초에 널리 퍼진 현상이 아니다"는 behnamoh의 주장을 정면 반박. 자신의 회사는 명시적으로 6개월 내 그 정도 지출을 강제하는 정책을 도입했다.
  • 근거: 구체적인 금액과 기간을 제시. 이는 소수의 기업만 tokenmaxxing을 했다는 주장에 반하는 실제 사례다.
  • 반론/대댓글: behnamoh는 "지나친 소음"이라고만 응수했지만, 구체적인 수치 앞에서는 설득력이 약해졌다.
  • 대표 작성자: metaltyphoon, behnamoh
  • 내 판단: metaltyphoon의 사례는 tokenmaxxing이 단순한 소문이 아니라 실제 대규모 예산이 동원된 현상임을 증명한다. 다만 이 정도 강제가 지속 가능한지는 의문.

### [minraws] "포춘 500대 기업 여러 곳이 분기당 10억 달러 이상을 토큰에 지출"

  • 주장: tokenmaxxing은 실제 대규모로 발생하고 있다. 포춘 500대 기업 중 다수가 분기당 수십억 토큰을 소비하며, 총 지출액이 10억 달러를 넘는 경우도 있다.
  • 근거: 구체적인 기업명은 밝히지 않았지만, 업계 관계자로서 내부 정보를 근거로 제시.
  • 반론/대댓글: 이 주장은 다른 댓글러들 사이에서 "과장"이라는 반응이 있었으나, 명확한 반박은 없었다.
  • 대표 작성자: minraws
  • 내 판단: 사실이라면 놀라운 규모다. 하지만 출처가 불분명하므로 검증이 필요하다. 그래도 tokenmaxxing이 '일부 기업의 과장된 사례'가 아닐 가능성을 시사한다.

### [fraywing] "토큰을 많이 써서 긍정적 결과를 강제해도 이해·책임 문제는 해결되지 않는다"

  • 주장: 엔지니어가 비인간 추상화 파이프라인의 검토 터미널이 되는 미래를 우려. "코드가 어떻게 만들어졌는지 이해하지 못한 채 PR 승인만 누르는 상황"을 경고.
  • 근거: leptons의 댓글과 연결되어, 자신의 회사에서 30년 경력 SWE가 "PR 코드를 읽지 말고 Approve만 누르라"는 지시를 받은 일화를 인용.
  • 반론/대댓글: leptons이 동의하며 "이것은 30년 경력의 소모"라고 강조.
  • 대표 작성자: fraywing, leptons
  • 내 판단: tokenmaxxing의 진짜 위험은 비용보다 엔지니어링 문화의 붕괴일 수 있다. 책임과 이해 없이 양만 늘리는 생산성은 지속 불가능하다.

### [ambicapter] "누적 정확성(compounding correctness)은 작가가 재정적 이득을 보기 때문 아닌가?"

  • 주장: "더 많은 토큰이 더 좋은 결과를 낸다"는 주장은 과도한 단순화이며, NVDA 주식을 보유한 저자가 자기 이익을 위해 쓴 것이라는 의심.
  • 근거: baddash는 "LOC(코드 라인 수) 숭배와 비슷한 오류"라고 덧붙임.
  • 반론/대댓글: NateEag은 "NVDA 주식을 보유했을 수도 있다"며 가능성을 인정했지만, 구체적인 반박은 없음.
  • 대표 작성자: ambicapter, baddash, NateEag
  • 내 판단: 기술적 논쟁보다 이해 충돌 의심에 가깝다. 그러나 누적 정확성 개념 자체는 AISI의 실험 결과(토큰 예산 증가에 따른 성능 향상)가 뒷받침하므로, 완전히 무시할 수는 없다.

### [IceHegel] "이제는 경영진이 '자유롭게 돈을 써라'고 말하면 직원이 'ROI는 어디 있나?'고 묻는 역전 현상"

  • 주장: tokenmaxxing이 확산된 후, 오히려 직원들이 비용을 의식하게 되어 경영진이 권장해도 쉽게 받아들이지 않는 역전이 발생했다.
  • 근거: "몇 달 전만 해도 경영진이 ROI를 묻고 직원이 자유를 원했는데, 지금은 역할이 바뀌었다"는 관찰.
  • 반론/대댓글: 이에 대해 m3kw9는 "진짜 엔지니어라면 tokenoptimizing(토큰당 최고 품질)을 할 것"이라며 tokenmaxxing은 반대라고 주장.
  • 대표 작성자: IceHegel, m3kw9
  • 내 판단: tokenmaxxing의 역설적 결과를 잘 보여준다. 조직 내 권력 관계와 비용 인식의 변화를 반영한다.

### [et1337] "보안 취약점 탐색에서는 tokenmaxxing이 효과적, 업계가 고가의 연속 퍼저를 도입 중"

  • 주장: 일반적인 코딩 작업에서는 누적 정확성이 아직 입증되지 않았지만, 보안 분야(취약점 탐색)에서는 tokenmaxxing이 확실히 효과를 본다. 그래서 업계에서 고가의 연속 퍼저(fuzzer)를 도입하고 있다.
  • 근거: 자신이 경험한 사례와 업계 동향.
  • 반론/대댓글: seattle_spring은 "주당 5만 달러 AI 교육은 사기"라며 비용 대비 효과에 의문을 제기. rezonant와 codegladiator가 금액을 두고 농담을 주고받음.
  • 대표 작성자: et1337, seattle_spring, rezonant, codegladiator
  • 내 판단: 보안 분야는 이미 '작업 증명(proof of work)' 구조로 전환 중이라는 원문의 주장과 일치한다. 일반 개발 작업과 보안 작업의 차이를 인식하는 것이 중요하다.

### [theanonymousone] "Loop의 의미가 무엇인가?" from 루프 엔지니어링 논쟁

  • 주장: "loop"가 단순히 반복 실행을 의미하는지, 아니면 더 복잡한 구조인지 질문.
  • 근거: throwaway89201이 "LLM 스스로 완료 기준을 판단하는 Ralph Wiggum Loop"라고 설명. SchemaLoad는 테스트 실행을 완료 조건으로 정의하는 자신만의 방법을 제시.
  • 반론/대댓글: untwerp는 "Loop engineering이 프롬프트 엔지니어링처럼 유행하고 있다"며 GitHub Topics 링크 제공. panarky는 "토큰맥싱을 해보면 이해할 것"이라고 냉소.
  • 대표 작성자: theanonymousone, throwaway89201, SchemaLoad, untwerp, panarky
  • 내 판단: loop의 개념은 여전히 혼란스럽다. 구체적인 구현이 아닌 아이디어 수준에서 유행하는 경향이 있어, 실무자 사이에서도 정의가 분분하다.

### [gausswho] "Tokenmaxxing은 메타버스, 블록체인과 같은 열병의 일부"

  • 주장: tokenmaxxing은 이전의 메타버스, 블록체인, 클라우드 과대광고와 동일한 패턴의 '열병(fever)'이다. 미디어 조작과 주주의 인형 조종이 진짜 원인.
  • 근거: "우리는 모든 과대광고가 지나간 후에 배우지만, 또다시 같은 패턴을 반복한다"는 통찰.
  • 반론/대댓글: 특별한 반박 없음. 다만 tokenmaxxing이 다른 과대광고와 달리 실제 생산성 향상 사례가 있다는 주장이 원문에 있으므로, gausswho의 주장은 과도한 일반화일 수 있다.
  • 대표 작성자: gausswho
  • 내 판단: 역사적 패턴 비교는 유용하지만, tokenmaxxing이 단순한 유행인지 기술적 패러다임 전환인지는 아직 결론나지 않았다. gausswho의 시각은 회의론자들에게 공감을 얻지만, 지나친 비관은 경계해야 한다.

### [j45] "Tokenmaxxing은 돈에 불을 지르는 행위, 스케일링은 효율성이 핵심"

  • 주장: "기업은 비효율을 오래 견딜 수 없다. tokenmaxxing은 취한 선원의 지출과 같다."
  • 근거: solenoid0937이 반박하며 "나는 훨씬 많은 일을 처리하므로 비용이 무시할 만하다. 스타트업은 계속 tokenmaxxing하고 대기업은 보수적이 될 것"이라고 주장.
  • 반론/대댓글: solenoid0937의 반박은 개인 생산성 향상 사례에 의존. 하지만 j45는 "스타트업도 언젠가는 비용을 통제해야 한다"고 재반박.
  • 대표 작성자: j45, solenoid0937
  • 내 판단: 생산성 향상이 비용을 정당화하는지가 핵심. solenoid0937처럼 실제로 생산성이 극적으로 오른 경우에는 tokenmaxxing이 합리적일 수 있다. 그러나 모든 작업에 적용 가능한지는 의문.

새로운 시각

### Tokenmaxxing은 '강제적 도입'에서 '자발적 의존'으로 진화 중

원문과 댓글을 종합하면, tokenmaxxing은 1단계(경영진 강제 정책)에서 2단계(비용 압박으로 일시 후퇴)를 거쳐, 지금은 3단계(누적 정확성으로 인한 자발적 대량 사용)에 접어들고 있다. 그러나 이 3단계는 모든 영역에 동일하게 적용되지 않는다. 보안과 같은 특수 영역에서는 명백히 효과적이지만, 일반 코딩에서는 아직 논쟁 중이다. 기업은 '강제 없이도 직원들이 AI를 많이 쓰게 만드는' 환경을 설계해야 한다. 예를 들어, 토큰 예산을 낮게 잡아서 부족함을 느끼게 하는 '역발상 tokenmaxxing'이 더 효과적일 수 있다.

### '책임 없는 생산성'의 딜레마

fraywing과 leptons의 사례가 보여주듯, tokenmaxxing은 코드 작성량을 폭발적으로 늘리지만, 그 코드를 이해하고 책임질 수 있는 능력은 오히려 줄어든다. 이는 '생산성 역설(productivity paradox)'의 새로운 변종이다. 미래에는 '무결점(faultless) 코드'보다 '이해 가능한(comprehensible) 코드'가 더 중요한 가치가 될 수 있다. 학교 교육에서도 단순히 AI를 많이 쓰는 법을 가르치는 대신, AI가 생성한 결과를 비판적으로 검토하고 책임질 수 있는 능력을 가르쳐야 한다.

### 의료 분야 함의: tokenmaxxing의 교훈을 진단 보조에 적용

사용자가 의료(소화기·내시경·종양학) 분야 종사자라는 점에서, tokenmaxxing의 개념은 의료 AI 진단 시스템 도입에도 비슷한 패턴으로 적용될 수 있다. 예를 들어, 병원이 AI 진단 도구(예: 내시경 영상 분석)의 사용량을 의사 평가에 연동하면, 의사들이 필요 이상으로 많은 스캔을 요청하거나 무의미한 재확인을 유발할 위험이 있다. 반대로, 누적 정확성 패러다임을 활용해 AI가 스스로 학습을 반복할수록 진단 정확도가 높아지는 구조를 만들면, tokenmaxxing(여기서는 '진단 토큰'의 과다 사용)이 진짜 가치를 창출할 수 있다. 의료 분야에서는 오류가 생명에 직결되므로, 누적 오류보다는 누적 정확성으로 전환하는 것이 더욱 절실하다.

자녀와 미래에 대한 시