AI 토큰을 많이 소비할수록 우수한 개발자인가
요즘 들어 이런 생각이 든다. AI 없이 소프트웨어를 어떻게 만들었을까? 물론 그렇게 했다는 사실은 안다. 가능한 일이었다. 하지만 AI를 쓰면 롤러스케이트에 로켓 팩까지 달고 달리는 것 같다. 당연히 개발자가 이 놀라운 힘을 받아들이도록 독려하고 싶어진다.
그런데 역시나 IT 업계는 이 모든 것을 복잡하게 뒤틀어버리는 방법을 찾아냈다. 합리적인 계획 대신, 순수한 토큰 사용량을 우수성의 척도로 삼아 AI 활용을 최악의 방식으로 게임화하는 획일적인 지표가 등장했다.
‘토큰맥싱(tokenmaxxing)’의 당혹스러운 세계에 온 것을 환영한다.
코드 라인 수보다 나쁜 지표
코드 라인 수(LOC)를 많이 쓸수록 더 생산적인 개발자라는 말이 있다. 정말 그럴까?
틀렸다. 완전히 틀렸다. 생산된 코드의 양보다 더 잘못된 소프트웨어 성공 지표를 상상하기 어렵다. LOC는 사실 시스템이 얼마나 비대한지, 즉 장애 가능성이 있는 표면적이 얼마나 넓은지를 나타내는 지표다. 잘 설계된 시스템은 오히려 LOC를 줄이는 방향을 지향한다. 간결한 시스템에는 실제 코딩보다 훨씬 많은 사고와 정제 과정이 담겨 있다.
그렇다면 AI를 사용할 때 소비하는 토큰의 양은 어떨까? LOC보다도 나쁜 지표다. 계획 없이 무분별하게 코드를 쏟아내는 것을 암시할 뿐 아니라, 실제로 작동하는 소프트웨어를 만들 의도 없이 프롬프트에 불필요한 내용을 채워 넣어 소비량만 높이는 행태를 부추길 수도 있다.
예상대로 토큰맥싱은 조잡한 소프트웨어와 낮은 생산성이라는 두 가지 폐해를 낳는다. 놀랍게도, 인프라를 위협하기까지 한다.
토큰맥싱의 단점이 업계에 서서히 알려지고 있지만, 여전히 현재 진행형 문제다. 개발자가 AI를 효과적으로 활용하도록 유도하는 좋은 방법을 찾고 있는 것은 맞다. 토큰맥싱은 결코 그 방법이 될 수 없다.
‘세션 임모털’
토큰맥싱의 가장 충격적인 사례는 메타에서 나왔다. 한 직원이 ‘클로드노믹스(Claudeonomics)’라는 사내 리더보드를 구현했다. 클로드노믹스는 8만 5,000명 이상 직원의 AI 사용량을 집계해, 순수하게 소비한 토큰 수만을 기준으로 상위 250명의 파워유저 순위를 매겼다.
리더보드 상위권 직원은 깔끔한 코드나 우아한 아키텍처가 아닌 순수한 토큰 소비량으로 보상받았다. 우승자에게는 ‘토큰 레전드(Token Legend)’, ‘세션 임모털(Session Immortal)’ 같은 게임스러운 칭호가 주어졌다. 단 30일 만에 클로드노믹스는 메타 직원이 가히 충격적인 규모인 60조 2,000억 개의 AI 토큰을 소비하도록 부추겼다.
결과는 예상대로였다. 더 프래그매틱 엔지니어(The Pragmatic Engineer)의 분석에 따르면, 컴퓨팅 소비량이 기업 내 지위의 상징으로 자리잡으면서 엄청난 낭비가 발생했다. 개발자는 토큰 소모만을 위해 사내 에이전트를 실행하며, 실질적인 효과가 거의 없는 일회성 결과물을 양산했다.
더 심각한 것은, 토큰 소비 광풍이 자사 인프라를 손상시켰다는 점이다. 엔지니어는 세션 임모털 지위 달성에만 집중한 개발자의 무분별한 AI 코드 생성이 사이트 장애를 직접 유발했다고 보고했다.
불멸은 아닐지 몰라도, 일종의 악명 정도는 얻은 셈이다. 그럼에도 이 트렌드 이면에는 기술, 특히 AI에 대한 거의 어린아이 같은 맹목적인 믿음이 깔려 있는 것처럼 보인다. 경영진은 AI의 가능성을 진심으로 믿어야만 수익에서 이토록 아낌없이 투자를 쏟아부을 수 있다. 반복되는 이야기처럼 들릴 수 있지만, 숙련된 수석 개발자의 지성과 통찰력, 그리고 개발 루프에서 나오는 피드백을 대체할 수 있는 것은 없다.
키로랭크의 실패
메타만이 이 함정에 빠진 빅테크 기업은 아니다.
아마존에서도 AI 도입 경쟁이 ‘키로랭크(Kirorank)’라는 비공식 단기 리더보드를 탄생시켰다. 자사 키로(Kiro) IDE에서의 직원 활동을 추적하기 위해 설계된 대시보드였지만, 엔지니어가 시스템을 게임화하면서 순식간에 부조리한 상황으로 전락했다. 개발자는 순위를 올리는 가장 쉬운 방법이 효율적인 코드 작성이 아니라 자율형 AI 에이전트를 실행시켜 의미 없는 작업을 할당하는 것임을 깨달았다. 아마존은 자사 엔지니어가 허영 지표를 쫓기 위해 컴퓨팅 비용을 청구하고 있다는 사실을 파악한 뒤, 불과 몇 주 만에 키로랭크 서비스를 종료했다.
트렌드에 따른 재정적 역풍은 심각했다. 한때 무제한적인 AI 도입을 환호하던 기업이 이제는 출혈을 막으려 안간힘을 쓰고 있다. 세일즈포스와 도어대시(DoorDash) 같은 대기업은 AI 사용 의무화 정책에서 급선회해, 급증하는 API 비용을 관리하기 위해 AI 사용량을 적극적으로 할당량으로 통제하기 시작했다.
맹목적인 AI 소비 추구가 얼마나 극단적이었는지는 우버(Uber)의 사례만 봐도 알 수 있다. 우버는 2026년 전체 AI 예산을 불과 1분기 만에 소진했다고 전해진다.
납품되는 소프트웨어의 품질보다 소비된 토큰의 절대적인 양을 우선시하면, 디지털 전환은 이루어지지 않는다. 손에 남는 것은 매우 값비싼 생산성의 환상뿐이다.
이 구도에서 승자는 AI 공급업체다. 아마존의 경우처럼, 직간접적으로 토큰을 소모하는 주체가 동시에 빅테크 플레이어이기도 한 경우가 있다. 토큰을 태우는 쪽과 수익을 거두는 쪽이 같은 기이한 생태계다.
코드 교체율 폭증
토큰맥싱은 불필요한 코드를 양산할 뿐 아니라 아키텍처 품질도 저하시킨다. 최근 몇 년간의 데이터를 살펴보면, 무분별한 코드 생성의 결과는 암울하다. 2026년 6월 약 6억 건의 코드 변경을 분석한 결과에 따르면, AI 작성 코드의 비중이 높아지면서 코드 블록 중복이 81% 급증했다. 코드 블록을 복사·붙여넣기할 때마다 코드 스멜(code smell)로 간주해야 한다는 오랜 격언을 기억하는가? AI 기반 개발에서는 이 복사·붙여넣기가 엄청난 규모로 일어나고 있지만, 아무도 주목하지 않는 것처럼 보인다.
같은 기간 리팩토링(실제 사고와 정제 과정)은 2022년 대비 70% 급감했다.
AI가 생성하는 코드의 상당 부분은 일회용이다. (바라건대) 즉각적인 목적에 부합하지만, 시스템 전반의 문제를 해결할 의도로 작성된 것은 아니다. 단기 코드 교체율(작성 후 2주 이내에 대폭 수정되거나 삭제되는 코드 비율)은 2021년 AI 도입 이전 기준치 3.3%에서 2025년 7.1%로 두 배 이상 증가했다. 2026년 5월 발표된 연구에 따르면, 자율형 에이전트 사용이 개발자의 커밋 횟수를 최대 180%까지 늘렸지만, 실제 릴리즈 증가율은 고작 30%에 그쳤다.
잡음은 많고 신호는 적은 상황이다. 이전 어느 때보다 많은 코드를 작성하고 있지만, 더 빠른 속도로 버려지고 있다.
괴리의 본질
토큰맥싱 현상의 근본 원인은 AI가 실제 엔지니어링 작업과 어떻게 맞닿아 있는지에 대한 오해에 있다. 1976년 찰스 굿하트는 어떤 측정값이 목표가 되는 순간 좋은 측정값으로서의 기능을 잃는다는 ‘굿하트의 법칙(Goodhart’s Law)’을 제시했다. AI 프로젝트 관리는 현재 스스로가 이 함정에 걸려 있음을 깨닫고 있다. 업무의 처음부터 끝까지 걸리는 시간이나 시스템 품질 개선 여부를 추적하는 대신, 경영진은 AI가 생성한 코드 비율이나 순수 토큰 사용량처럼 쉽게 정의되고 (그만큼 쉽게 조작되는) 대시보드 지표에 의존하는 경향이 있다.
이 지표가 완전히 놓치는 것은 ‘비코드(non-code)’ AI 작업의 막대한 가치다. AI 어시스턴트와의 가장 가치 있는 상호작용 중에는 스택 트레이스(stack trace) 디버깅, 모호한 비즈니스 요구사항 분석, 엣지 케이스(edge case) 파악 등이 포함된다. 한 엔지니어가 대규모 언어 모델과 1시간 동안 대화를 나눠 근본 원인을 정확히 파악하고, 결국 단 세 줄의 깔끔한 코드 수정으로 문제를 해결했다고 가정해 보자. 탁월하고 효율적인 엔지니어링이다. 그러나 토큰맥싱 체계에서는, 그 엔지니어가 에이전트에게 500줄의 스파게티 코드를 뽑아내도록 지시한 동료보다 관리자 대시보드에서 생산성이 낮은 것처럼 보인다.
AI의 가장 탁월한 활용 사례 중 일부는 깊이 있는 학습, 탐구, 설계 분야에 있다. 소프트웨어 개발의 근간을 항상 형성해 온 브레인스토밍, 화이트보드 작업, 대화처럼, 이런 방식의 AI 활용 가치는 추정하거나 지표로 압축하는 것이 거의 불가능하다.
낭비의 경제학
소프트웨어 공학의 건전성을 평가하는 지표가 실제 현실과 너무 동떨어지면, 재무 역학은 기업에 치명적으로 작용한다. 경제적 관점에서 토큰은 산출 가치가 아닌 투입 비용이다. 더 심각한 것은, 최상위 프론티어 모델에서 출력 토큰의 비용이 입력 토큰보다 최대 5배 비쌀 수 있다는 점이다. 코드 생성에 인센티브를 부여하면, IT 예산에서 극도로 레버리지가 높은 부분을 압박하는 셈이다.
이 부조리한 상황은 AI 핀옵스(AI finops)라는 새로운 분야를 급속도로 성장시키고 있다. 기업은 실제 ROI에 대한 인사이트를 얻고 비용 낭비에 경계를 설정하기 위해, 합리적인 가드레일, 서킷 브레이커(circuit breaker), 속도 제한, 가상 라우팅 레이어를 서둘러 구축하고 있다.
낭비는 주로 명백한 실패에서 비롯된다. 개발자가 정밀한 입력 대신 전체 코드베이스를 프롬프트에 통째로 쏟아 넣는 ‘컨텍스트 스터핑(context stuffing)’이나, 자율형 에이전트가 자기 자신을 재귀적으로 호출하는 ‘에이전트 루프(agent loop)’가 대표적이다. 빈 고층빌딩의 조명을 켜두는 것과 재정적으로 동일한 행위다.
소프트웨어 공학으로의 회귀
AI라는 ‘롤러스케이트와 로켓 팩’을 도랑에 빠지지 않고 제대로 활용하려면, 소프트웨어 개발의 낡지만 변하지 않는 철학으로 돌아가야 한다. 바로 그 철학이 토큰맥싱으로 대표되는 경향에 본질적으로 저항한다.
소프트웨어 공학의 탁월함은 항상 불필요한 것을 걷어내고 핵심을 부각하는 데 있었다. 코드를 생성하기 전에 먼저 생각하고, 정제하고, 계획하는 것이다. AI는 이 과정을 가속화하는 훌륭한 도구이지만, 우리가 책임감 있는 관리자로 남아 있을 때만 그 진가를 발휘한다.
