AI를 많이 쓰는 사람이 일을 잘하는 사람일까요, 아니면 그저 회사 돈으로 더 큰 청구서를 만드는 사람일까요. 이제 이 질문은 농담이 아닙니다. AI 사용량이 대시보드에 잡히고, 팀별 순위가 매겨지고, 비용까지 연결되면 직원은 "좋은 결과"만큼이나 "AI를 쓰고 있다는 신호"를 관리하게 됩니다.
최근 아마존에서는 내부 AI 에이전트 도구인 MeshClaw를 이용해 불필요한 작업까지 자동화하며 토큰 사용량을 늘리는 사례가 보도됐습니다. 아마존은 개발자 80% 이상이 매주 AI 도구를 쓰도록 목표를 세웠고, 내부 리더보드로 사용량을 추적한 것으로 알려졌습니다.1 문제는 여기서부터입니다. 토큰 사용량은 분명 관찰하기 쉬운 숫자지만, 생산성을 설명하기에는 너무 거칠기 때문입니다.
토큰 수는 왜 매력적이지만 위험한 지표인가
토큰은 AI 모델이 입력과 출력을 처리하는 기본 단위입니다. 대략 몇 글자 단위로 쪼개진 텍스트 조각이며, 대부분의 AI 서비스 비용도 이 사용량을 기준으로 계산됩니다.2 그래서 기업 입장에서는 토큰 사용량이 매력적인 관리 지표처럼 보입니다. 누가 AI를 쓰는지, 얼마나 쓰는지, 팀별 도입률이 어떤지 한눈에 보이기 때문입니다.
하지만 "많이 썼다"는 말은 두 가지로 해석될 수 있습니다. 하나는 복잡한 문제를 AI로 잘 분해해 더 빠르게 해결했다는 뜻입니다. 다른 하나는 긴 프롬프트, 반복 재시도, 불필요한 에이전트 루프, 과도한 컨텍스트 입력으로 비용만 태웠다는 뜻입니다.
특히 에이전트형 AI에서는 이 차이가 더 커집니다. 사람이 한 번 묻고 답을 받는 방식과 달리, 에이전트는 코드베이스를 훑고, 하위 작업을 만들고, 여러 앱과 상호작용하며 계속 토큰을 씁니다. 좋은 자동화라면 업무 병목을 줄이지만, 잘못 설계된 자동화라면 "일하는 척하는 기계"가 됩니다.
아마존 사례가 보여준 것은 기술보다 인센티브다
아마존의 MeshClaw는 코드 배포, 이메일 분류, Slack 상호작용 같은 작업을 수행할 수 있는 내부 에이전트 플랫폼으로 소개됐습니다.1 이런 도구 자체는 나쁘지 않습니다. 반복 업무를 줄이고, 개발자가 더 중요한 판단에 시간을 쓰게 만들 수 있습니다.
문제는 도구가 아니라 신호 체계입니다. 회사가 "AI 사용률"을 강조하고, 관리자와 팀이 숫자를 볼 수 있고, 직원이 그 숫자가 평가에 영향을 줄지 모른다고 느끼면 행동은 바뀝니다. 아마존은 토큰 통계가 성과평가에 쓰이지 않는다고 밝혔지만, 직원들은 관리자가 수치를 보고 있다고 느낀 것으로 보도됐습니다.1
이것이 토큰맥싱의 핵심입니다. 직원들이 반드시 게으르거나 부정직해서가 아닙니다. 측정되는 것이 곧 관리되는 것이고, 관리되는 것이 곧 경쟁이 됩니다. 과거 코드 줄 수로 개발자를 평가하면 장황한 코드가 늘어났듯, 토큰 수로 AI 활용을 평가하면 토큰을 태우는 워크플로가 늘어납니다.
더 나은 질문은 "얼마나 썼나"가 아니라 "무엇이 달라졌나"다
토큰 사용량을 완전히 무시하자는 뜻은 아닙니다. 사용량은 AI 도입 여부를 보는 빠른 신호입니다. 다만 단독 지표로 쓰면 위험합니다. Business Insider가 전한 업계 논쟁에서도 "토큰 지출로 엔지니어를 순위 매기는 것은 마케팅팀을 지출액으로 평가하는 것과 같다"는 비판이 나왔습니다.3
실무적으로는 다음 질문이 더 낫습니다.
같은 결과물을 만드는 데 걸린 시간이 줄었는가
리뷰, 버그 수정, 재작업이 줄었는가
AI가 만든 초안이 최종 결과에 실제로 반영됐는가
사람이 놓치던 대안이나 리스크를 발견했는가
유용한 결과물 1개당 토큰 비용은 얼마인가
이렇게 보면 토큰은 "연료 사용량"이지 "도착 여부"가 아닙니다. 자동차를 많이 몰았다고 목적지에 잘 도착한 것은 아니듯, AI를 많이 호출했다고 좋은 의사결정이 보장되지는 않습니다.
건강한 고강도 AI 사용을 위한 개인·팀 규칙
AI를 적극적으로 쓰는 것과 토큰맥싱에 빠지는 것은 다릅니다. 차이는 사용 전 의도와 사용 후 검증에 있습니다.
개인은 프롬프트를 넣기 전에 먼저 목표를 한 줄로 적어야 합니다. "문서 요약"이 아니라 "회의 전에 쟁점 3개를 뽑아 의사결정 시간을 줄인다"처럼 결과 기준을 정해야 합니다. 초안 작성이나 분류처럼 낮은 난도의 작업은 작은 모델이나 저비용 도구로 처리하고, 복잡한 추론이 필요할 때만 고성능 모델을 쓰는 방식도 필요합니다.
팀은 에이전트 실행에 상한을 둬야 합니다. 몇 분 이상 반복되면 중단하고, 큰 컨텍스트를 매번 통째로 넣기보다 요약본을 재사용해야 합니다. 또한 성공한 워크플로는 "프롬프트 모음"이 아니라 "어떤 문제에서 어떤 비용으로 어떤 결과를 냈는지"까지 기록해야 합니다.
관리자는 리더보드를 만들더라도 원시 토큰 수를 순위화해서는 안 됩니다. 대신 결과물 단위의 비용, 배포 속도, 장애 감소, 고객 응답 품질처럼 업무 결과와 연결된 지표를 함께 봐야 합니다. AI 사용을 장려하려면 "많이 쓴 사람"보다 "반복 가능한 좋은 사용법을 만든 사람"을 보상해야 합니다.
토큰맥싱은 사라질 유행어일 수 있습니다. 하지만 그것이 드러낸 문제는 오래갑니다. AI가 업무 도구에서 업무 감시 지표로 바뀌는 순간, 조직은 생산성보다 사용량을 최적화할 위험에 빠집니다. 지금 신경 써야 할 사람은 AI를 쓰지 않는 사람이 아니라, AI 사용을 숫자로 관리하려는 팀장과 리더입니다. 앞으로의 기준은 간단해야 합니다. 토큰을 얼마나 태웠는가가 아니라, 그 토큰이 더 나은 판단과 더 적은 낭비로 이어졌는가입니다.
참고
1"Tokenmaxxing" spreads at Amazon as employees game internal AI leaderboards
2Tokenmaxxing Explained: Why AI Use Is Becoming a Workplace Status Symbol
3'Tokenmaxxing' has techies debating if leaderboards tracking AI token use are a good idea
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.