토큰맥싱이란 무엇인가? 스스로 무너진 AI 메트릭

30일 동안 메타 직원들은 소비량에 따라 순위를 매기는 내부 리더보드를 통해 약 60조 개의 AI 토큰을 소비했으며, 이는 대부분 보여주기식 일에 사용된 것으로 추정되는 1억 달러 이상의 비용을 발생시켰습니다. 90일 후, 리더보드는 사라졌고 회사는 AI 사용을 엄격히 제한하기 시작했습니다.

이러한 흐름을 ‘토큰맥싱(tokenmaxxing)’이라고 부릅니다. 이는 AI 토큰 사용량을 극대화하는 것을 성과 점수이자 생산성의 지표로 삼는 현상을 말합니다. 이후 기업들은 이를 깨달았고, 일부는 ‘토큰마이닝(tokenminning)’이라 불리는 현상으로 과도하게 대응하기도 했습니다. 이는 컴퓨팅 비용을 줄이기 위해 가능한 한 적은 수의 AI 토큰을 사용하는 것을 의미합니다. 두 접근 방식 모두 토큰 수를 AI 주도 성장의 신뢰할 수 있는 지표로 간주하기 때문에 실패하게 됩니다.

이 글에서는 토큰맥싱이 실제로 어떤 비용을 초래하는지, 엔지니어들이 이를 어떻게 악용했는지, 그리고 숫자 조작에 능한 사람들조차 속일 수 없는 측정 설정에 대해 다룰 것입니다.

토큰맥싱이란 무엇인가?

토큰맥싱(Tokenmaxxing)이란 AI 토큰 소비를 극대화하고, 사용량이 많을수록 생산성이나 AI 도입 수준이 높다는 증거로 간주하는 관행을 말합니다. 토큰은 AI 모델이 입력으로 처리하고 출력으로 생성하는 단위입니다.

토큰 사용량은 가시성이 높고 정량화 가능하며, 이미 많은 AI 플랫폼에서 추적하고 있기 때문에 매력적인 메트릭으로 부상했습니다. 덕분에 시간 절감, 의사결정 개선, 수익 창출과 같은 결과보다 보고하기가 더 쉽습니다. 하지만 토큰은 유용한 작업이 아닌 계산 활동을 측정할 뿐입니다. 반복적인 프롬프트, 실패한 에이전트 루프, 무의미한 출력 등은 아무런 결과도 만들어내지 않으면서도 수치를 부풀릴 뿐입니다.

AI 에이전트는 이 문제를 더욱 악화시킵니다. 에이전트는 맥락을 파악하고, tools를 호출하며, 자신의 작업을 수정하고, 다른 에이전트에게 작업을 넘깁니다. 이 모든 단계에서 토큰이 소모됩니다. 활동이 많아지면 더 유용한 작업이 이루어질 수 있지만, 동시에 비효율적인 워크플로우와 비용 증가로 이어질 수도 있습니다.

간단히 말해, 토큰맥싱의 근본적인 결함은 팀이 가시적인 수치는 최대치로 끌어올리면서도 생산성, 품질, 투자 수익률은 그대로 유지한다는 점입니다.

토큰맥싱은 왜 인기를 끌게 되었을까요?

토큰맥싱이 인기를 끌었던 이유는 경영진이 기업 내 AI 도입이 실제로 진행되고 있음을 입증할 수 있는 메트릭이 필요했기 때문입니다. 그리고 토큰 사용량은 청구 콘솔에 표시되는 유일한 메트릭이었습니다.

엔비디아(Nvidia)의 젠슨 황(Jensen Huang) CEO는 2026년 초 ‘올인(All-In)’ 팟캐스트에 출연해 고액 연봉을 받는 엔지니어의 토큰 비용에 대한 사고 실험을 제시하며 분위기를 주도했습니다.

“만약 연봉 50만 달러짜리 엔지니어가 최소 25만 달러 상당의 토큰을 소비하지 않았다면, 저는 크게 우려할 것입니다.”라고 그는 말했다. 만약 그 답이 5,000달러로 나왔다면? 그는 화가 머리끝까지 치밀어 오를 것이다.

AI 활용도는 누가 시대에 뒤처지지 않고 있는지 가늠할 수 있는 가시적인 지표가 되었습니다. 이는 모든 기획 회의에서 AI가 어떤 역할을 대체할지에 대한 의문이 제기되던 시기에 일어났습니다. 토큰을 소비한 엔지니어들은 새로운 패러다임에 적응하고 있는 것처럼 보였지만, 그렇지 않은 이들은 문제아로 비칠 위험이 있었습니다.

아이러니한 점은, 최초의 토큰 순위표가 애초에 경쟁을 목적으로 만들어진 것이 아니라는 사실입니다. Shopify는 상위 고객들이 왜 그렇게 많은 금액을 지출하는지 파악하기 위해 이 순위표를 구축했을 뿐, 고객들끼리 순위를 매기기 위한 것이 아니었습니다. 부사장 겸 엔지니어링 총괄 책임자인 파르한 타와르(Farhan Thawar)는 나중에 이 tool이 어떻게 발전해 왔는지 설명했습니다.

이 회사는 이를 ‘사용 대시보드’로 명칭을 변경하고, 서킷 브레이커와 지출 알림 기능을 추가했으며, 이 데이터를 활용해 통제 불능 상태에 빠진 에이전트와 인프라 버그를 파악했습니다. 파르한은 다음과 같이 썼습니다:

토큰맥싱은 논란의 여지가 있는 주제입니다. 더 많이 사용한다고 해서 더 좋은 것은 아닙니다. 우리는 최초의 AI 토큰 순위표를 만들었습니다. 그 후 사고방식을 발전시켰고, 이는 사용 현황 대시보드로 거듭났습니다. 데이터는 동일하지만 해석의 틀이 달라진 것입니다. 서킷 브레이커와 지출 급증 지표를 추가했고, 통제 불능 상태에 빠진 에이전트를 포착했으며, 우리 인프라의 버그도 발견했습니다. 진정한 핵심은 누가 가장 많이 지출했는지가 아니라, 토큰을 통해 가장 큰 영향을 창출한 사람들이 누구인지입니다. 바로 그 엔지니어들과 대화를 나누고 싶습니다.

Shopify의 리더보드 방식을 모방한 대부분의 기업은 AI 지출을 분석하기보다는 직원 순위를 매기는 데 이를 활용했습니다. 아래 테이블은 각 기업에서 이러한 방식이 어떻게 적용되었는지 보여줍니다.

이 테이블에 나타난 패턴은 일관적입니다. 토큰 데이터를 활용해 고액 지출을 조사한 조직들은 유효한 신호를 유지했습니다. 반면, 이를 직원 순위 매기기에 사용한 다른 조직들은 분기 내에 그 신호를 잃어버렸습니다.

엔지니어들은 어떻게 토큰 사용량을 부풀렸을까?

엔지니어들은 출시할 계획조차 없었던 비용이 많이 드는 AI 활동을 생성함으로써 토큰 사용량을 부풀렸습니다. 『The Pragmatic Engineer』는 메타, Microsoft, 세일즈포스에서 나타난 이러한 행태를 보고 네 가지 공통된 전술을 밝혀냈습니다. 이 중 어느 것도 악의적인 의도는 없었습니다. 사람들은 단순히 가시성이 높은 수치를 보고, 구조조정을 우려하여 AI를 많이 사용하면 자신을 보호할 수 있을 것이라고 생각했을 뿐입니다:

많은 엔지니어들이 동료들이 얼마나 소비하고 있는지 확인했습니다. 그리고는 평균보다 약간 높은 수준을 유지할 만큼만 소비했습니다. 1위를 차지하는 것보다, AI를 충분히 활용하지 않는다는 이유로 지적받는 것을 더 원치 않았기 때문입니다.

Amazon에서는 직원들이 키로랭크(Kirorank) 점수를 높이기 위해 AI 에이전트에게 사소하거나 임의로 지어낸 작업을 할당했습니다. 이로 인해 비즈니스 성과는 전혀 창출되지 않은 채 클라우드 비용만 증가했습니다. Amazon이 이 순위표를 폐지했을 때, 데이브 트레드웰 수석 부사장은 직원들에게 이 시스템이 선의에서 만들어졌다고 설명했습니다. 그리고는 다음과 같이 단호하게 당부했습니다. “AI를 단지 AI를 사용한다는 이유만으로 활용하지 말아 주십시오.”

이러한 변화의 일환으로, Amazon은 이제 AI가 생성한 코드가 제대로 작동하고 가치를 제공하는지 여부를 추적하고 있습니다. 토큰 소비량은 더 이상 우선순위가 아닙니다.

토큰맥싱은 기업들에게 얼마나 큰 비용을 초래했는가?

토큰맥싱은 메타(Meta)에 단 한 달 만에 1억 달러 이상의 비용을 초래했을 가능성이 높으며, 우버(Uber)의 연간 AI 예산을 4개월 만에 소진시켰습니다. 메타에 대한 이 추정치는 간단한 산술 계산에서 나온 것입니다. (뉴스가 보도된 당시) 클로드 오퍼스(Claude Opus)의 API 가격표에 따르면, 60.2조 개의 토큰은 약 9억 달러에 해당합니다. 메타와 같은 크기의 기업은 상당한 할인을 협상하겠지만, 설령 그렇다 해도 비용은 1억 단위(nine figures)에 달할 수 있습니다.

우버는 리더보드 제도를 운영한 적이 없기 때문에 이 비용을 가장 명확하게 보여줍니다. 이 회사는 약 5,000명의 엔지니어에게 비용 지출 모델 없이 자율적 코딩 tools를 제공했습니다. 한 달 만에 자율적 사용자로 분류된 엔지니어의 비율은 32%에서 84%로 급증했습니다 . 연간 전체 예산은 4개월 만에 소진되었습니다 .

CTO인 프라빈 네팔리 나가(Praveen Neppalli Naga)는 회사가 초기 가정에 대해 “다시 원점으로 돌아갔다”고 인정했습니다. 엔지니어 1인당 월간 비용의 범위는 500달러에서 2,000달러였으며, 해결책은 단호했습니다. 바로 엔지니어 1인당 코딩 도구별 월 1,500달러 상한선을 설정하는 것이었습니다.

비슷한 일을 수행하는 엔지니어들이 지출하는 금액이 이토록 큰 차이를 보인다는 것은, ‘올바른 사용’이 무엇인지 아무도 명확히 정의하지 못했음을 보여줍니다. 따라서 각 엔지니어는 자신만의 정의를 만들어 냈습니다. 우버의 앤드류 맥도날드 최고운영책임자(COO)는 이 점을 인정하며, 포춘(Fortune)과의 인터뷰에서 AI가 지원한 코드와 실제로 출시되는 유용한 기능 사이를 “구분 짓기가 매우 어렵다”고 말했습니다.

LeadDev의 ‘AI 임팩트 보고서’에 따르면, 엔지니어링 리더 중 단 19%만이 토큰맥싱을 효과적인 전략으로 평가했습니다. 이들 중 57%는 토큰맥싱이 실제 가치를 제대로 측정하지 못한다고 답했습니다.

자금이 이렇게 빠르게 움직이는 이유는 다음과 같습니다. 코드 변경을 계획하는 에이전트는 저장소를 읽고, tools를 호출하며, 테스트를 실행하고, 성공할 때까지 재시도합니다. 단 한 번의 루프만으로도 수만 개의 토큰이 소모될 수 있으며, 프롬프트 캐시 읽기는 그 수치를 더욱 높입니다.

재무 팀들은 AI 예산을 마치 좌석 라이선스처럼 책정했습니다. 하지만 AI는 실제로는 클라우드 컴퓨팅과 같은 방식으로 작동합니다. 여러 공급업체에 걸쳐 AI 스택을 구축하면서 누구에게도 소유권이 부여되지 않을 때에도 동일한 회계상의 괴리가 발생합니다. 이는 관리되지 않은 도구 난립과 동일한 실패 양상이지만, 한 단계 더 높은 수준에서 나타나는 문제입니다.

토큰마이닝이란 무엇인가요?

토큰마이닝(Tokenminning)은 AI 토큰 소비를 최소화하고 낮은 사용량을 목표로 삼는 관행입니다. 소개에서 논의한 바와 같이, 이는 과도한 교정 조치이며 그 결과 또한 좋지 않습니다. 이 용어는 ‘토큰 최소화(token minimizing)’의 줄임말로, 토큰맥싱에 대한 대응책으로 등장했습니다. 뉴욕타임스는 여러 기업에서 이러한 변화가 일어나고 있다고 보도했습니다.

메타는 비용이 “기하급수적으로 증가”한 후 직원들에게 AI 사용을 제한하겠다고 알렸습니다. 우버는 월간 지출 한도를 설정했고, 월마트는 도구 사용 제한을 두었으며, Amazon과 메타는 모두 순위표를 삭제했습니다. 불과 몇 주 만에, 가장 많은 AI를 사용하던 직원들을 칭찬했던 바로 그 기업들이 이제는 모든 직원에게 AI 사용을 절약하도록 가르치고 있었습니다.

이번 조정 조치는 바로잡으려 했던 실수를 반복하고 있습니다. 굿하트의 법칙이 이를 가장 잘 설명해 줍니다 . ‘지표가 목표가 되면, 더 이상 좋은 지표가 될 수 없다’는 것입니다. 따라서 AI 토큰 사용량을 목표로 설정하면, 사람들은 본래의 의도를 훼손하는 대가를 치르더라도 그 메트릭을 최적화할 방법을 찾게 될 것입니다. 굿하트의 법칙은 ‘토큰맥싱’과 ‘토큰마이닝’에 대한 경고를 담고 있습니다.

팀에 토큰 소각을 장려하면, 필요 없는 토큰까지 소각해 버릴 것입니다. 팀에 토큰 절약을 장려하면, 버그를 발견할 수 있었던 AI 실행을 건너뛰게 될 것입니다. 혹은 한 번의 철저한 세션을 세 번의 형편없는 세션으로 나누어, 각각 더 피상적인 결과만 내놓을 수도 있습니다. 두 팀 모두 토큰 사용 목표는 달성하지만, 실제 일의 질은 떨어지게 됩니다.

비용 통제 자체가 실수는 아닙니다. 우버의 예시에서 보듯이, 월 1,500달러 한도는 회사가 1년 치 예산을 4개월 만에 소진한 후에 내려진 예산 결정입니다. 하지만 지출 한도를 설정하는 것은 재무적 문제만 해결할 뿐입니다. 구매한 토큰이 유용한 무언가를 가져왔는지에 대한 답은 되지 않습니다.

해결책은 두 가지 유형의 수치를 구분하는 것입니다. 바로 ‘주목해야 할 신호’와 ‘목표로 삼아야 할 결과’입니다. 토큰 사용량, 채택률, AI가 작성한 코드의 비중은 시스템 내부에서 무슨 일이 일어나고 있는지 보여주는 신호입니다. 이러한 지표들은 문제를 조사할 때는 유용하지만, 목표로는 부적합합니다. 각 지표는 고객이 아무런 차이를 느끼지 못하는 사이에도 크게 변동할 수 있기 때문입니다.

조직은 대신 결과를 목표로 삼아야 합니다. 이는 잘 구축된 소프트웨어 개발 KPI 세트와 동일한 논리를 따릅니다. 즉, 초기 신호를 그것이 예측해야 할 결과와 연결하는 것입니다. Shopify의 대시보드 전환율이 그 템플릿입니다. 동일한 데이터를 사용하지만, 그 결과와 연계된 순위표는 없습니다.

IBM 컨설팅의 수석 부사장인 닐 다르(Neil Dhar)는 AI 비용에 관한 에세이에서 이러한 혼란이 어떻게 확산되는지 설명했습니다.

#Tokenmaxxing이 최근 모든 헤드라인을 장식하고 있습니다. 가능한 한 많이, 가능한 한 빨리 AI를 사용하려는 조직의 노력은 결국 사용량을 값의 지표로 삼는 결과를 낳았습니다. 이제 그 대가를 치러야 할 때가 왔습니다. AI 비용이 수익을 앞지르자, 본능적으로 예산을 삭감하려는 움직임이 나타나고 있습니다. 하지만 지출을 줄이는 것만으로는 근본적인 ROI 문제를 해결할 수 없습니다.

IBM에 따르면, 해결책은 사용량을 신호로 간주하고 이를 위조할 수 없는 결과와 연계하는 것입니다.

토큰 사용량이 많을수록 생산성도 높아질까요?

아니요, 토큰 사용량이 많다고 해서 생산성이 높은 것은 아닙니다. 현재 이용 가능한 최대 규모의 데이터셋에 따르면, 이 두 가지 지표는 서로 독립적으로 움직이는 것으로 나타났습니다. 개발자 인텔리전스 플랫폼 DX의 연구에 따르면, AI 도입률은 포화 상태에 가까워진 반면, 측정된 생산성 향상 폭은 정체된 상태였습니다.

DX의 CTO 로라 타초(Laura Tacho)가 관련 수치를 공유했습니다. 개발자 중 92.6%는 현재 최소한 한 달에 한 번은 AI 코딩 어시스턴트를 사용하고 있으며, 약 75%는 매주 사용하고 있습니다. AI는 프로덕션 코드의 26.9%를 작성합니다. 그러나 개발자들이 직접 보고한 시간 절감 효과는 1년 넘게 주당 약 4시간 수준에 머물러 있습니다. 또한 초기 10%의 생산성 향상은 더 이상 증가하지 않았습니다.

사용량은 계속 증가했지만 결과는 제자리걸음을 면치 못했습니다. 사용량만을 추적하는 메트릭은 실제로는 일어나지 않은 성공을 보고해 온 셈입니다.

구글 클라우드의 DORA 보고서는 동일한 tools가 왜 이렇게 다른 결과를 낳는지 설명합니다. 이 보고서에 따르면 AI 도입은 배포 속도는 향상시켰지만 배포 안정성은 저해한 것으로 나타났습니다. 이 보고서는 AI를 ‘증폭기’로 묘사하며, AI가 잘 운영되는 조직의 강점은 더욱 부각시키고, 어려움을 겪는 조직의 약점은 더욱 부각시킨다고 설명합니다.

DX의 자체 데이터는 이러한 증폭 효과가 실제로 작용하고 있음을 보여줍니다. 67,000명의 개발자로 구성된 한 그룹에서, 동일한 기간 동안 동일한 tools를 사용했음에도 불구하고 일부 조직에서는 고객 관련 인시던트가 두 배로 증가한 반면, 다른 조직에서는 절반으로 줄어든 것으로 나타났습니다. 타코(Tacho)는 데이터가 가리키는 대로 책임을 명확히 합니다:

이는 사실 관리상의 문제입니다. 과대광고로 인해 AI를 시도하기만 해도 자동으로 성과가 나올 것처럼 들렸습니다. 하지만 지금까지 대부분의 tools는 개별 코딩 작업에만 사용되어 왔습니다. 실질적인 효과를 보려면, 단순한 개별 작업이 아닌 조직 차원에서 AI를 활용해야 합니다.

첫 번째 문제 아래에는 두 번째 문제가 숨어 있습니다. 바로 사람들이 AI가 가져다주는 속도 향상을 과대평가한다는 점입니다. 비영리 연구소인 METR은 무작위 대조 실험을 진행했습니다. 16명의 숙련된 오픈소스 개발자들이 평균 5년 동안 관리해 온 저장소에서 246건의 실제 문제를 완료했습니다. 작업을 시작하기 전, 개발자들은 AI 덕분에 작업 속도가 24% 빨라질 것이라고 예측했습니다. 작업을 마친 후, 그들은 AI 덕분에 속도가 약 20% 빨라졌다고 추정했습니다. 그러나 스톱워치 측정 결과, 실제로는 19% 더 느려진 것으로 나타났습니다.

후속 업데이트에서 연구팀은 다음 실험에서 교정할 수 없는 선택 편향(selection effects)에 직면했다고 설명했습니다. 또한, 주로 에이전트 기반 도구 덕분에 개발자들이 이제 AI를 활용해 실제로 더 빠르게 작업할 수 있게 되었다고 덧붙였습니다. 남은 교훈: 자가 보고된 생산성은 측정된 생산성을 대체할 수 없으며, 두 지표 간의 격차는 어느 쪽으로든 나타날 수 있습니다.

토큰 사용량 대신 무엇을 측정해야 할까요?

토큰 사용량 대신 팀 차원, 나아가 조직 차원에서 결과를 측정하세요. 토큰 사용량은 순위를 매기는 기준이 아닌 비용 신호로만 간주하십시오. 중요한 것은 창출된 결과입니다.

실천해야 할 한 가지 실용적인 원칙: 공개하는 모든 신호에는 그 신호로 부풀릴 수 없는 결과를 반드시 곁들여야 합니다. 팀은 어떤 결과물도 내놓지 않고 토큰을 소각할 수는 있습니다. 하지만 변화 실패율의 하락을 조작할 수는 없습니다.

이 구조는 엔지니어링 리더들이 이미 신뢰하고 있는 측정 프레임워크에서 비롯되었습니다. DORA는 배포 속도와 안정성을 포괄하며, AI가 이 두 가지 요소를 모두 증폭시킨다는 DORA의 연구 결과가 바로 이 두 요소의 결합이 중요한 이유입니다.

DX Core 4는 속도, 효과성, 품질, 비즈니스 영향력이라는 네 가지 차원을 측정합니다. 아비 노다(Abi Noda)와 로라 타초(Laura Tacho)는 DORA, 스페이스, DevEx를 개발한 연구원인 니콜 포스그렌(Nicole Forsgren) 및 마가렛-앤 스토리(Margaret-Anne Storey)와 함께 이 지표를 구축했습니다. 이 네 가지 차원은 의도적으로 서로 상충되도록 설계되었습니다.

한 쪽을 개선하는 대가로 다른 쪽을 희생시키는 팀은 그 상충 관계를 즉시 드러냅니다. 두 프레임워크 모두 토큰 관련 메트릭을 포함하지 않았으며, 이후에도 추가하지 않았습니다.

다음 세 가지 규칙이 실제로 페어링이 유지되도록 합니다:

직원들이 악용하지 않을 AI 사용 정책은 어떻게 설정해야 할까요?

직원들이 조작할 수 없는 AI 사용 정책을 설정하려면, 개인의 평가에서 가시성이 높은 번호를 모두 제거하고 다음 다섯 가지 결정을 내려야 합니다:

1. 데이터를 수집하기 전에 그 번호가 어떤 목적을 위한 것인지 먼저 결정하세요

정책에 포함된 모든 메트릭은 첫 번째 대시보드가 출시되기 전에 그 목적을 문서로 명시해야 합니다. Shopify의 리더보드는 초기에는 효과적이었습니다. 경영진은 이를 활용해 지출액이 많은 사용자와 그들이 구축 중인 프로젝트에 대해 대화를 시작했습니다. 그 번호는 조사를 촉발하는 계기가 되었습니다. 그러나 동일한 번호가 일에 대한 질문을 던지기보다 개인에 대한 결론을 내리는 데 사용되면, 그것은 곧바로 점수로 변모합니다. 그리고 점수는 관리 대상이 됩니다.

각 메트릭별로 다음 세 가지를 기록해 두세요:

‘무조치’ 기준선이 가장 많은 일을 합니다. 직원들은 이 기준선을 바탕으로 정책을 검증하기 때문입니다. ‘지출이 급증하면 어떻게 되나’라는 질문에 대한 솔직한 답변에 누군가의 입지가 관련된다면, 여러분은 불필요한 단계가 추가된 순위 체계를 구축한 것입니다.

2. 팀 단위로 예산을 설정하세요

팀별 공동 예산 한도는 개인별 상한선을 대체하며, 이 차이는 회계적 차원이 아닌 행동적 차이에 기인합니다. 유사한 업무를 수행하는 엔지니어들 사이에서 월 500달러에서 2,000달러까지 편차가 나타나는 우버의 사례는, 공통된 기준점이 없을 때 어떤 일이 벌어지는지 잘 보여줍니다. 각자 ‘합리적’이라는 기준을 제멋대로 정하게 되는 것입니다. 예산 한도 제도는 흩어진 AI 지출을 하나의 책임 있는 곳으로 통합하려는 다른 모든 노력과 동일한 방식으로 작동합니다.

이 ‘여유’를 통해 1인당 상한선으로는 얻을 수 없는 세 가지 이점을 얻을 수 있습니다:

관측된 데이터를 바탕으로 첫 번째 예산의 크기를 설정하세요. 팀의 최근 3개월 평균을 기준으로 삼고, 비용이 많이 드는 프로젝트 하나를 위한 여유분을 추가하세요. 추측에 기반해 설정된 예산의 크기는 2주 만에 초과되어, 이 정책이 형식적일 뿐이라는 사실을 모두에게 깨닫게 합니다.

3. 비용이 많이 드는 경로의 가시성을 높여라

엔지니어들에게 지출 한도를 설정하는 대신 각 실행 건당 비용을 보여주세요. 테스트 실패 시 반복되는 에이전틱(Agentic) 실행이 예산을 소진시키는 주된 원인이며, 이로 인해 엄격한 지출 한도 설정이 필수적입니다. 또 다른 방법은 상급자에게 보고하지 않고, 해당 실행을 트리거한 엔지니어에게만 실행 건당 비용을 공개하는 것입니다.

재시도 루프로 인해 40달러가 낭비되는 것을 지켜보는 엔지니어는 그 루프를 수정할 것입니다. 반면, 보고가 우려되는 엔지니어는 비용이 많이 드는 실행이 올바른 결정이었던 경우를 포함해 에이전트 사용을 아예 중단해 버릴 것입니다.

Shopify의 서킷 브레이커는 다음과 같이 작동합니다. 시스템이 이상 징후를 감지하면, 해당 일에 가장 가까운 담당자가 어떻게 대응할지 결정합니다. 가시성은 사용 제한보다 더 빠르게 행동을 변화시키며, 일에서 발생하는 비용이 정당화될 때는 비싸지만 올바른 운영 방식을 유지할 수 있게 해줍니다.

4. AI 도입 목표와 성과 평가를 분리하세요

해고 주기 동안 구두로 한 약속은 무의미해지므로, 해고 주기 동안의 조건을 서면으로 명시해 두세요. 『The Pragmatic Engineer』에 자신의 메트릭을 부풀렸다고 밝힌 Microsoft 엔지니어는 상을 노린 것이 아니었습니다. 그들은 AI를 명분으로 한 해고가 잇따르던 한 해 동안, 특정 라벨을 달지 않기 위해 그렇게 했던 것입니다.

사람들이 사용 데이터가 보정 회의에 반영된다고 믿는다면, 다른 사람들이 공개적으로 뭐라고 말하든 상관없이 데이터를 관리할 것입니다.

정책 문구는 정확히 두 줄이면 충분합니다:

그런 다음 두 가지 모두를 존중하세요. 리뷰에서 사용량 데이터가 드러나는 것을 처음 목격한 엔지니어는 이를 모두에게 알릴 것이며, 그 결과 해당 메트릭이 불필요하다는 사실이 입증될 것입니다.

5. 분기마다 페어링을 검토하세요

매 분기마다, 각 진단 항목이 여전히 해당 결과와 연관성이 있는지 점검하십시오. 모델 가격 책정, 캐싱 동작, 에이전트 아키텍처는 모두 연간 계획 주기보다 더 빠르게 변화합니다.

팀들이 계획 수립 및 보고에 AI를 적용하는 방식은 끊임없이 변화하고 있습니다. 1월에는 특정 의미를 지녔던 토큰 수치가, 두 차례의 가격 인하와 에이전트 업그레이드를 거친 6월이 되면 완전히 다른 의미를 갖게 됩니다.

이 리뷰는 메트릭별로 솔직한 결과를 제시합니다. 여전히 페어링된 결과를 예측하고 있는 메트릭, 새로운 가격에 맞춰 재보정해야 하는 메트릭, 더 이상 아무런 설명도 제공하지 못해 별다른 절차 없이 폐기되는 메트릭 등이 있습니다. 팀들은 메트릭 폐기에 가장 강력히 저항합니다. 하지만 이는 매우 중요한 문제입니다. 왜냐하면 그 의미를 상실한 채로 남아 있는 메트릭야말로 리더보드 시대가 구축된 기반이 된 바로 그 수치이기 때문입니다.

AI 도입을 측정할 때 팀이 흔히 저지르는 실수

가장 흔한 네 가지 실수는 채택률을 최종 목표로 삼는 것, 자체 보고된 시간 절감 효과를 맹신하는 것, 개인별 순위표를 공개하는 것, 그리고 안정성을 측정하지 않은 채 속도만 측정하는 것입니다. 비용이 크게 발생하기 전에 이러한 실수들을 미리 파악할 수 있습니다.

1. 채택을 최종 목표로 삼는 것

도입 대시보드에 90%가 표시되자 경영진은 AI 이니셔티브가 완료되었다고 선언했지만, 그 하류에서 무엇이 바뀌었는지는 아무도 묻지 않았습니다. DX의 데이터는 대규모로 이 함정을 드러냈습니다. 도입률은 92.6%였지만 생산성은 10% 수준에서 정체되어 있었습니다. 도입률은 단지 도구가 사용자에게 전달되었음을 확인해 줄 뿐입니다. 도구가 무엇을 변화시켰는지에 대해서는 아무것도 말해주지 않습니다.

해결책: 출시가 끝나면 채택률 차트를 폐기하고, 신호와 결과를 연계한 지표로 대체하세요.

2. 자체 보고된 시간 절감 효과에 대한 신뢰

한 설문조사에 따르면 팀은 주당 5시간을 절약한다고 하지만, 사이클 시간은 지난 두 분기 동안 변동이 없었습니다. METR의 실험은 이 두 수치가 일치하지 않는 이유를 보여줍니다. AI를 사용했을 때 작업 속도가 눈에 띄게 느려졌던 개발자들조차, AI 사용 후에는 작업 속도가 20% 빨라졌다고 추정했습니다. 사람들이 믿는 것과 시계가 기록하는 것은 서로 다른 측정값입니다.

해결책: 인식이 중요한 개발자 경험에 대해서는 설문조사를 유지하세요. 시간과 관련된 주장을 할 때는 시스템 데이터를 활용하세요.

3. 순전히 재미를 위해 개인별 순위표 공개하기

누군가가 오후 한나절 만에 사내 wiki에 이를 구축하고, 유쾌한 제목을 붙여주면 팀원들은 약 3주 동안 진심으로 이를 즐깁니다. 그러다 인센티브가 앞서는 순간이 옵니다. 메타의 ‘클로드노믹스(Claudeonomics)’와 Amazon의 ‘키로랭크(Kirorank)’는 모두 풀뿌리 차원의 재미로 시작되었습니다. 두 회사 모두 게임적 요소가 열정을 압도하게 되자 이를 중단했습니다.

해결책: 데이터를 팀 단위로 집계하거나, 아예 배포하지 마세요.

4. 안정성을 측정하지 않고 속도만 측정하기

처리량이 증가하면 모두가 기뻐하지만, 다른 팀의 대시보드에서는 인시던트 건수가 급증합니다. DORA 보고서는 바로 이러한 양면성을 지적했습니다. 속도는 향상되지만 안정성은 악화되는 현상입니다. 두 수치를 서로 다른 대시보드에 분리해 두면 이 문제는 눈에 띄지 않게 됩니다.

해결책: 변경 실패율을 별도의 신뢰성 검토 항목에 포함시키지 말고, 속도 메트릭과 같은 화면에 표시하십시오. 별도의 검토 항목은 아무도 참조하지 않기 때문입니다.

ClickUp에서 AI의 영향을 추적하는 방법

ClickUp에서 AI의 영향을 추적하려면, AI가 가속화해야 했던 작업, 스프린트, 결과물 등 실제 업무와 나란히 결과를 측정하세요. 대부분의 토큰 대시보드는 해당 업무를 직접 수행하는 곳과는 거리가 먼 제공자 콘솔에 위치해 있습니다. 결과 메트릭을 작업 공간으로 옮기면 이러한 격차를 해소할 수 있습니다.

앞서 언급한 ‘신호와 결과’의 연관성은 이 플랫폼에 그대로 반영됩니다:

점수를 매기지 않고 토큰 수만 확인하세요

이 모든 이야기는 한 가지 규칙으로 귀결됩니다. 토큰 데이터를 질문을 던지는 데는 사용하되, 사람을 평가하는 데는 절대 사용하지 말라는 것입니다. Shopify는 ‘가장 많은 비용을 지출하는 고객들은 무엇을 만들고 있는가?’라고 물었고, 통제 불능 상태의 에이전트와 인프라 버그를 발견했습니다. Meta와 Amazon은 ‘누가 AI를 가장 많이 사용하고 있는가?’라고 물었고, 가짜 작업, 수백만 달러의 낭비, 그리고 무용지물이 된 순위표를 얻었습니다.

그러니 이번 분기에는 세 가지를 실천하세요. 토큰 추적 시스템을 팀 단위로 전환하고, 개인 이름이 표시되는 항목은 모두 삭제하세요. 정책에 사용 데이터가 절대 성과 평가에 반영되지 않는다는 내용을 명시하세요. 그리고 보고하는 모든 속도 메트릭과 동일한 화면에 하나의 품질 메트릭(실패율 변화율이 가장 간단합니다)을 함께 표시하세요.

별도의 보고 도구 대신 실제 업무 바로 옆에서 해당 화면을 확인하고 싶다면, 지금 바로 ClickUp을 무료로 시작해 필요해지기 전에 대시보드를 구축해 두세요.

토큰맥싱에 관한 자주 묻는 질문(FAQ)

토큰맥싱의 ‘30% 규칙’이란 무엇인가요?

토큰맥싱에 특화된 공식적인 ‘30% 규칙’은 존재하지 않습니다. 이 표현은 대개 사람들이 혼동하는 두 가지 별개의 사실을 요약한 것입니다. 첫째 , AI는 측정된 엔지니어링 생산성을 30%가 아닌 약 10% 정도 향상시키는 경향이 있다는 점 , 둘째, 개발자들은 대개 20~30% 정도의 생산성 향상을 예상하지만 실제로는 실현되지 않는다는 점입니다. 어떤 고정된 비율도 달성해야 할 목표가 아니라 조사해야 할 진단 지표로만 간주하십시오.

토큰 100만 개는 대략 75만 단어의 영어 텍스트에 해당합니다. 토큰 하나당 평균 약 3/4단어 정도이기 때문입니다. 비용은 전적으로 모델과 입력/출력 비율에 따라 달라집니다. 2026년 최첨단 모델 요율 기준으로, 100만 개당 몇 달러에서 수십 달러 초반까지 범위가 다양합니다. 에이전트 기반 세션은 각 루프마다 컨텍스트를 다시 읽기 때문에 토큰을 빠르게 소모하며, 프롬프트 캐시 읽기 횟수도 토큰 수에 추가됩니다.

“토큰맥싱(Tokenmaxxing)”은 “토큰(token)”과 특정 특성을 극대화한다는 의미의 인터넷 접미사 “-maxxing”을 결합한 신조어입니다. 2026년 초, 메타(Meta)와 Amazon의 내부 토큰 순위표가 언론에 유출되면서 엔지니어링계에 널리 퍼졌습니다. 비즈니스 인사이더(Business Insider)는 2026년 4월 이를 “실리콘밸리의 새로운 AI 논쟁”이라고 칭했습니다. 이후 바이버랭크(Viberank)와 tokenmaxxing.sh 같은 공개 순위표들이 이 라벨을 채택하여, 전 세계 개별 개발자들을 API 사용량 기준으로 순위를 매기기 시작했습니다.

대체로 그렇습니다. 2026년 5월, 메타, Amazon, Microsoft, 우버가 토큰 순위표를 철회하거나 폐지한 후, 포춘(Fortune)은 토큰맥싱이 끝났다고 선언했습니다. 리드데브(LeadDev)의 ‘AI 임팩트 보고서’에 따르면, 응답자의 19%만이 토큰맥싱이 AI 가치를 측정하는 데 효과적이라고 평가한 반면, 57%는 완전히 실패했다고 답했습니다. 취미 차원의 공개 순위표는 여전히 존재하지만, 이는 경영 관행이 아닌 단순한 게임으로 남아 있습니다.

정립된 벤치마크는 없습니다. 우버가 이 시스템을 도입했을 때 엔지니어 1인당 월별 비용의 범위는 500달러에서 2,000달러까지였지만, 이후 회사는 tool당 지출 한도를 1,500달러로 제한했습니다. 엔비디아의 젠슨 황 CEO는 연봉 50만 달러짜리 엔지니어가 연간 25만 달러 상당의 토큰을 소비해야 한다고 주장한 바 있지만, 이는 표준이라기보다는 도발적인 발언에 가깝습니다. 조사 결과에 따르면 유사한 일 간에도 큰 차이가 나타나는데, 이는 ‘적절한 사용’이 무엇인지 아직 누구도 정의하지 못했음을 의미합니다.

바이브 코딩(Vibe coding)은 작업 방식입니다. 즉, 구현 작업을 AI 에이전트에게 위임하고 결과에 따라 방향을 조정하는 방식입니다. 토큰맥싱(Tokenmaxxing)은 측정 방식입니다. 소비한 토큰을 생산성의 증거로 간주하는 것이죠. 바이브 코딩은 효율적으로 할 수도 있고 낭비적으로 할 수도 있습니다. 토큰맥싱은 소비량만을 집계하기 때문에 낭비적인 방식을 장려합니다. 토큰맥싱을 막기 위해 토큰 사용 한도를 설정했던 기업들은 그 과정에서 정당한 자율적 작업을 저해하는 결과를 초래하곤 했습니다.