Tokenmaxxing은 죽었다, Tokenmaxxing 만세

• 기업의 AI 도입 초기에 토큰 사용량을 성과 평가와 연결한 tokenmaxxing은 무의미한 비용을 만들었지만, AI 도구 사용을 조직에 강제로 퍼뜨리는 역할도 했음
• Meta에서는 개인별 토큰 사용량이 평가와 연결되자, 토큰 수치를 올리기 위해 두 에이전트를 하루 종일 대화시키는 식의 형식적 사용까지 나타남
• 과거 장시간 에이전트 실행은 작은 오류가 쌓이는 누적 오류(compounding error) 때문에 위험했지만, 최근에는 더 많은 토큰이 더 나은 결과를 만드는 누적 정확성(compounding correctness) 흐름이 부상함
• 보안 분야에서는 Mythos 같은 모델에 큰 토큰 예산을 투입해 취약점을 찾는 방식이 등장했고, 방어자가 공격자보다 더 많은 계산을 써야 하는 구조가 만들어지고 있음
• 앞으로는 비싼 최상위 모델에 무제한 지출하기보다, 저렴한 오픈 모델을 루프로 더 많이 돌리는 방식이 tokenmaxxing의 실용적 중심이 될 수 있음

무의미한 토큰 소모로 시작된 tokenmaxxing

• tokenmaxxing은 임원이 직원들에게 많은 토큰을 쓰도록 유도하면서, 실제 가치가 낮은 작업에도 토큰이 소모되는 현상을 가리킴
• 대표 사례로 Meta는 성과 평가를 개인별 토큰 사용량과 연결했다는 비판을 받음
  • 한 Meta 직원은 토큰 수치를 올리기 위해 두 에이전트를 하루 종일 서로 대화하게 했다고 전함
• 겉으로는 경영진이 수익 없이 비용만 태우는 것처럼 보였지만, AI 도구 사용을 강제로 확산하려는 정책으로도 볼 수 있음
• 몇 달 전만 해도 조직 안에는 AI 도구 사용을 강하게 거부하는 시니어 인력이 많았고, 설득에 성공해도 도구를 이상하거나 나쁜 결과가 나오기 쉬운 방식으로 쓰는 일이 있었음
• 이런 상황에서 위에서 내려오는 토큰 사용 압박은 벽을 뚫기 위한 둔탁한 강제 수단으로 작동함

비용 압박으로 끝난 첫 번째 무제한 사용 정책

• tokenmaxxing 정책은 일정 부분 효과를 냈고, 지금은 거의 모든 팀이 최소한 조금은 AI로 코딩하는 상태가 됨
• 많은 팀은 아직 Ramp Inspect나 Stripe Minions 같은 자체 시스템을 만들지는 못했지만, 기본적으로 Cursor를 사이드바에서 쓰는 수준에는 도달함
• 토큰 사용량이 크게 늘어난 가운데 OpenAI와 Anthropic은 상장을 추진하는 상황에서 구독 제공량을 제한하고 API 가격을 올림
• 토큰 보조금도 줄어들면서, 무제한 토큰 사용 정책을 되돌리는 팀이 생김
• 기존 의미의 무제한 tokenmaxxing은 비용 검토를 버티기 어려운 단계에 가까워짐

누적 오류에서 누적 정확성으로

• AI 도구의 기대는 사람이 계속 감독하지 않아도 어렵고 지루한 작업을 처리하게 하는 데 있음
  • 대규모 코드 마이그레이션
  • 매일 아침 경쟁사 조사
  • 인바운드와 아웃바운드 흐름 처리
• 과거에는 AI를 오래 실행할수록 모델의 작은 오류와 환각이 프로젝트 안에 쌓여 되돌리기 어려워졌음
• 이 현상은 누적 오류(compounding error) 로 불렸고, 사람의 감독이 많이 필요했기 때문에 에이전트를 24시간 돌릴 이유도 적었음
• 지금은 더 많은 토큰을 쓰면 정답 가능성이 높아지는 누적 정확성(compounding correctness) 환경으로 바뀌고 있음
• 토큰 지출이 결과 품질과 연결된다면, 다시 토큰을 많이 쓰려는 인센티브가 생김

보안 분야에서 먼저 보이는 토큰 예산 경쟁

• 사이버 보안에서는 이미 토큰 지출이 성과와 직접 연결되는 사례가 나타남
• Cybersecurity is Proof of Work Now는 Anthropic의 Mythos를 예로 들며, 시스템을 강화하려면 공격자가 악용에 쓰는 것보다 더 많은 토큰을 취약점 발견에 써야 한다고 봄
• AISI는 Mythos 시도 1회당 100M 토큰을 예산으로 잡았고, 이는 시도당 $12,500, 10회 실행에 $125,000 규모임
• 100M 토큰 예산을 받은 모델들은 수익 체감 징후를 보이지 않았고, AISI는 테스트된 토큰 예산 범위에서 모델들이 예산이 늘수록 계속 진전했다고 밝힘
• 이 구조에서는 영리함보다 계산 작업량과 지불 가능한 토큰 예산이 더 중요해짐

루프와 장시간 에이전트 실행

• Boris Cherny가 Claude Code 무대에서 말한 loops에 대한 관심도 같은 흐름과 연결됨
• loops의 기본 구조는 에이전트가 자기 턴을 끝낼 때까지 실행한 뒤, 끝나면 같은 프롬프트를 다시 시작하는 방식임
• 무거운 명세를 자동으로 나누고, 에이전트가 시간이 지나며 부분별로 해결하게 만들 수 있음
• 이 개념은 새로운 것은 아니며, 지난해 7월부터 있었고 한때 “Ralph Wiggum loop”라고 불림
• 예전에는 프롬프트 설계와 에이전트 동작에 대한 깊은 이해가 필요했지만, 누적 정확성 덕분에 반복할수록 더 나아지는 근사적 결과를 기대하기 쉬워짐

오픈 모델이 만드는 비용 대비 반복 실행

• 장기적으로 tokenmaxxing의 승자는 오픈 모델 플랫폼일 수 있음
• 최상위 연구소 모델에 토큰을 대량 지출하는 방식은 CFO 검토를 통과하기 어려움
• 오픈 모델이 좋아질수록, 저렴한 모델을 루프 안에서 더 많이 돌리는 방식이 매력적이 됨
• 예를 들어 Claude가 반복당 1.1배 개선을 주고 GLM 5.2가 1.05배 개선을 주지만 비용이 약 5분의 1이라면, GLM 5.2 루프를 5배 더 돌리는 편이 더 나을 수 있음
• “Other things” 섹션에서도 GLM 5.2는 최첨단은 아니지만 frontier 모델보다 훨씬 저렴하다고 평가됨
  • GLM 5.2: 입력 100만 토큰당 약 $1.4, 출력 100만 토큰당 약 $4
  • Opus 4.X 시리즈: 입력 100만 토큰당 $5, 출력 100만 토큰당 $25
  • Haiku 4.5: 입력 100만 토큰당 $1, 출력 100만 토큰당 $5
  • GLM 5.2는 Haiku보다 강하고, 일부 벤치마크에서는 GPT 5.5보다 강한 경우도 있다고 함

개발자용 지출과 파이프라인용 지출의 차이

• tokenmaxxing에는 서로 다른 두 형태가 있음
• 첫 번째는 개발자용 토큰 지출임
  • 개발자가 Claude Code 같은 도구를 쓰고 loops를 실행하며 많은 토큰을 소비함
  • 엔지니어 생산성을 높인다면 좋은 지출이 될 수 있음
• 두 번째는 파이프라인용 토큰 지출임
  • 개발자는 여전히 손으로 코드를 쓰고, 그 코드로 특정 작업을 위한 일회성 에이전트를 만듦
  • 이 에이전트들은 비결정적이고 취약한 방식으로 동작하면서 많은 토큰을 소비함
  • 파이프라인이 실제로 작동할 때만 좋은 지출이지만, 그런 에이전트들은 결정적 파이프라인만큼 정확하지 않았음
• 환각 비용을 줄이려 품질 확인 에이전트를 추가하고, 그 확인 에이전트의 오류를 잡기 위해 또 다른 에이전트를 붙이면 토큰 비용이 3배가 됨
• 일회성 파이프라인형 도구는 특정 작업용 에이전트보다, 특정 작업에 맞춘 외피를 씌운 범용 플랫폼으로 처리되는 흐름이 커지고 있음

소프트웨어 팩토리와 극단적 토큰 지출

• 자연스러운 종착점은 소프트웨어 팩토리, 더 나아가 다크 팩토리임
• 이 구조에서는 코드베이스가 사람의 감독 없이 코드를 만들고, 리뷰하고, 버그를 고치고, 테스트를 작성함
• 사람은 명세를 넣고 애플리케이션을 받는 역할만 맡음
• StrongDM의 소프트웨어 팩토리는 이 방향을 극단까지 밀고 나간 사례로 언급됨
• StrongDM 쪽은 엔지니어가 하루 $1000의 토큰을 쓰는 것을 목표로 해야 한다고 주장했지만, 이는 과장과 홍보 성격이 강하다고 평가됨
• 자체 소프트웨어 팩토리는 월 $600 정도를 쓴다고 하며, 지금 엔지니어 1명당 시니어 Google 엔지니어 수준의 비용을 토큰에 쓰는 것은 과하다고 봄
• 다만 토큰에 큰돈을 쓰려는 인센티브는 잠재적으로 존재하며, 아직 확산을 기다리는 상태임