토큰맥싱과의 작별: AI 사용량보다 에이전틱 성과가 중요한 이유

URL: https://www.youtube.com/watch?v=H5h_GUaR-bU 날짜: 2026-09-24 채널: Tech Bridge

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==AI를 얼마나 많이 썼는지가 아니라, AI가 업무 시스템에 어떤 측정 가능한 결과를 만들어냈는지를 최적화해야 한다.==

• 토큰 소비량은 AI가 사용되고 있는지 보여주는 도입·활동 지표일 뿐, 가치 자체를 측정하지 못한다.
• 토큰을 무작정 늘리는 ‘토큰 맥싱(token maxing)’과 무작정 줄이는 ‘토큰 최소화(token minimization)’는 모두 소비량을 중심에 둔 동일한 함정에 빠진다.
• 에이전틱 AI는 코드 생성 외에도 계획 수립, 저장소 분석, 도구 호출, 테스트, 여러 시스템 간 조율을 수행하므로 단순 토큰 수로 성과를 판별하기 더 어려워졌다.
• 배포 완료 수, 절약한 개발 시간, 피한 재작업, 해결한 취약점처럼 운영 결과와 연결된 지표가 AI 사용량을 정당화해야 한다.

AI가 일상적인 인프라가 될수록 차별화 요소는 특정 모델에 접근할 수 있는지보다 모델을 둘러싼 시스템의 효과성에 놓인다. 컨텍스트 관리, 워크플로 오케스트레이션, 거버넌스, 비용 최적화를 함께 설계하고, 개발자·플랫폼 리더·플랫폼 도구가 소비를 결과로 연결해야 한다.

1. 사용량을 성과로 착각하게 만드는 측정 방식

활동량을 관리하기 쉬운 목표로 바꾸면 숫자는 올라가지만 실제 목표 달성 여부는 보장되지 않는다.

1.1. 영업 활동량과 AI 사용량의 공통 함정

1. 활동 지표의 한계

   1. 팀은 AI가 어떻게 사용되는지 파악하기 위해 활동 지표를 활용한다.
   2. 지표가 성공의 대리 지표가 되는 순간, 원래의 활동 측정 목적을 넘어 성과 자체인 것처럼 취급된다.

2. 통화량으로 실적을 판단하는 영업 사례

   1. 영업 담당자가 통화량에 집중하면 매주 활동 목표를 달성할 수 있다.
   2. 통화량만으로는 분기별 최소 실적을 달성할 궤도에 올라 있는지 알 수 없다.
   3. 활동량을 채우는 것과 실제 매출 목표를 달성하는 것은 별개의 문제다.

1.2. AI 도입기의 토큰 맥싱

1. 채택 지표의 확산

   1. 지난 1년 동안 많은 팀이 AI 도입을 ‘몇 명이 AI를 사용하는가’로 측정했다.
   2. ‘토큰을 얼마나 소비하는가’도 대표적인 질문이 됐다.
   3. 토큰은 AI 모델이 텍스트를 처리하는 기본 단위이므로 AI 사용량과 비용을 추적하기 쉬운 숫자였다.

2. 토큰 소비가 참여도의 대리 지표가 된 과정

   1. 토큰 소비량은 AI에 대한 참여도처럼 취급됐다.
   2. 무겁게 사용할수록 더 좋은 결과가 나올 것이라는 믿음으로 광범위한 AI 사용을 장려하는 팀이 생겼다.
   3. ‘토큰 맥싱’은 활동량이 많을수록 가치도 커진다고 보고 AI 사용량을 최대화하는 접근이다.
   4. 도입 신호로서는 유용했지만, AI가 일상 인프라로 확장되면서 사용량과 가치 사이의 간극이 드러났다.

3. 대시보드가 게임되는 이유

   1. IBM Consulting의 수석 부사장 닐 다르(Neil Dar)는 진정한 지표가 없으면 팀이 사용량 대시보드를 만들게 된다고 지적했다.
   2. 사람들은 곧 대시보드를 게임하는 법을 배웠고, 사용량은 빠르게 가치의 대리 지표가 됐다.
   3. 숫자를 올리는 행동은 쉬워도 그 숫자가 업무 결과를 개선했는지는 별도로 검증해야 한다.

2. 에이전틱 AI가 토큰 지표를 더 불충분하게 만드는 이유

에이전틱 시스템의 작업 범위가 넓어질수록 토큰 수는 활동의 규모만 보여주고 결과의 품질은 보여주지 못한다.

2.1. 코드 생성에서 업무 수행으로의 확장

1. 에이전트가 수행하는 연속 작업

   1. 에이전틱 AI는 코드를 생성하는 데서 멈추지 않고 워크플로를 계획한다.
   2. 코드 저장소를 분석하고, 필요한 도구를 호출하며, 해결책을 테스트한다.
   3. 여러 시스템 사이에서 작업을 조율해 하나의 업무를 끝까지 진행한다.

2. 능력과 토큰 소비의 관계

   1. 더 유능한 에이전트는 자연스럽게 더 많은 토큰을 소비한다.
   2. 그러나 토큰 소비량만으로는 그 활동이 실제 성과인지 단순한 활동인지 구분할 수 없다.
   3. 팀은 AI 사용량이 증가했다는 사실은 볼 수 있지만, 그 사용으로 어떤 가치가 생산됐는지는 명확히 알기 어렵다.

2.2. 비용이 증가한 뒤 등장한 질문

1. 성과와 비용의 연결이 끊긴 상태

   1. 대시보드에는 사용량 증가가 나타나고 토큰 수는 계속 올라간다.
   2. 하지만 그 활동과 시스템 수준의 결과가 어떻게 연결되는지는 불분명하다.
   3. “이 모든 비용을 지불해야 한다면 실제로 무엇을 얻었는가?”라는 질문이 다음 단계의 논의를 촉발한다.

2. 소비량 중심 사고의 한계

   1. 토큰 수가 많다는 사실은 복잡한 작업을 수행했다는 신호일 수 있다.
   2. 같은 숫자가 불필요한 반복, 잘못된 계획, 실패한 도구 호출을 나타낼 수도 있다.
   3. 따라서 소비량을 단독 목표로 삼으면 성공과 낭비를 같은 숫자로 집계하게 된다.

3. 토큰 최소화도 같은 함정이다

비용이 커졌다고 해서 입력 토큰을 일괄적으로 줄이면 복잡성이 사라지는 것이 아니라 다른 단계로 이동한다.

3.1. 비용 압박에 따른 제한 정책

1. 가장 눈에 잘 보이는 숫자에 집중하기

   1. AI 비용이 오르자 팀은 가장 쉽게 볼 수 있는 지표인 토큰 소비량을 줄이려 했다.
   2. 새로운 모델 사용을 제한하거나, 사용 가능한 모델을 낮추거나, 컨텍스트 윈도우를 축소하는 정책이 등장했다.
   3. 프롬프트 길이를 줄이는 방식도 함께 사용됐다.

2. 토큰 맥싱과 토큰 최소화의 공통점

   1. 토큰 맥싱은 더 많이 소비하면 더 많은 가치가 나온다고 가정한다.
   2. 토큰 최소화는 더 적게 소비하면 더 효율적이라고 가정한다.
   3. 두 접근 모두 운영 결과를 직접 측정하지 않고 토큰 소비량을 1차 목표로 삼는다는 점에서 같은 함정에 빠진다.

3.2. 컨텍스트를 잘라서 생기는 재작업

1. 합리적인 제거와 위험한 제거의 경계

   1. 지나치게 큰 도구 카탈로그나 오래된 컨텍스트처럼 명백한 비효율을 제거하는 것은 타당하다.
   2. 그러나 절감 작업을 계속하다 보면 작업 설명, 도메인 제약조건, 아키텍처 컨텍스트처럼 핵심 정보를 삭제하게 된다.
   3. 좋은 최적화는 불필요한 정보를 줄이는 것이지, 올바른 판단에 필요한 정보를 없애는 것이 아니다.

2. 아키텍처 컨텍스트를 삭제한 사례

   1. 아키텍처 컨텍스트를 토큰 절약을 위해 제거하면 AI는 고립된 환경에서는 작동하는 코드를 만들 수 있다.
   2. 그 코드는 더 넓은 시스템의 설계와 충돌하거나 시스템 전체를 깨뜨릴 수 있다.
   3. 입력에서 500토큰을 절약해도 디버깅과 재작업에 5,000토큰을 추가로 쓸 수 있다.
   4. 비용은 사라지지 않고 워크플로의 다른 단계로 이동한다.

3. 효율성의 올바른 판단 기준

   1. 입력 토큰이 줄었다는 사실만으로 효율성이 높아졌다고 축하할 수 없다.
   2. 전체 작업 완료에 들어간 토큰, 시간, 재작업, 품질을 함께 봐야 한다.
   3. 컨텍스트가 부족해 발생한 복잡성을 나중에 지불하는 방식은 진짜 절감이 아니다.

4. 소비량에서 결과로 전환하는 ‘가치 맥싱’

‘가치 맥싱(value maxing)’은 AI를 많이 또는 적게 쓰는 논쟁을 끝내고, 사용이 만들어낸 운영 결과를 최적화 대상으로 삼는다.

4.1. 가치 맥싱의 정의와 질문

1. 개념의 제안

   1. Nebius의 최고수익책임자(CRO) 마크 보로디츠키(Mark Boroditsky)가 ‘가치 맥싱’이라는 표현을 만들었다.
   2. 핵심 전환은 “토큰을 몇 개 사용했는가?”에서 “어떤 결과를 만들었는가?”로 질문을 바꾸는 것이다.

2. 운영 결과 지표

   1. 완료된 배포는 몇 건인가?
   2. 개발자 시간을 얼마나 절약했는가?
   3. 재작업을 얼마나 피했는가?
   4. 해결한 보안 취약점은 몇 건인가?
   5. 이런 지표가 AI가 측정 가능한 결과를 만들었는지 판단하고, 추가 토큰 사용이 정당한지 판별한다.

3. 토큰 소비가 정당화되는 조건

   1. 토큰 사용량 자체가 좋은 소프트웨어와 성공적인 소프트웨어 개발 생명주기(SDLC) 결과로 이어져야 한다.
   2. 더 많은 소비가 더 높은 품질, 빠른 배포, 줄어든 재작업으로 이어진다면 비용 증가에는 이유가 있다.
   3. 반대로 결과가 개선되지 않은 소비는 사용량이 높더라도 가치 맥싱이 아니다.

4.2. 성과 측정의 단위 바꾸기

1. 입력 중심 측정

   1. 프롬프트 토큰, 모델 호출 수, 총 토큰 수는 AI가 얼마나 움직였는지를 보여준다.
   2. 이 수치는 비용 관리와 이상 징후 탐지에는 필요하지만 최종 성과 지표로 충분하지 않다.

2. 결과 중심 측정

   1. 배포, 개발 시간, 재작업, 취약점 해결은 AI 사용과 실제 업무 성과를 연결한다.
   2. 팀은 사용량을 줄이는 대신 같은 비용으로 더 좋은 결과를 내거나, 더 높은 결과를 위해 필요한 소비를 허용할 수 있다.

5. 모델 경쟁에서 시스템 경쟁으로

모델이 인프라의 일부가 되면 우수한 모델에 접근하는 것만으로는 충분하지 않고, 모델을 업무에 연결하는 시스템이 성과를 좌우한다.

5.1. 모델 접근성의 차별화 약화

1. 인프라가 된 모델

   1. 훌륭한 모델에 접근할 수 있는지는 더 이상 가장 큰 차별화 요소가 아니다.
   2. 시스템 효과성은 모델 주변에 어떤 실행 환경을 만들었는지에 따라 더 크게 달라진다.

2. 모델 주변 시스템의 구성요소

   1. 필요한 정보를 적시에 제공하는 컨텍스트 관리가 필요하다.
   2. 여러 단계를 순서대로 수행하는 워크플로 오케스트레이션이 필요하다.
   3. 안전·권한·감사·정책을 다루는 거버넌스가 필요하다.
   4. 품질과 비용을 결과에 맞춰 조정하는 최적화가 필요하다.

5.2. 모델 선택보다 모델 오케스트레이션

1. 효율성의 초점 변화

   1. 결과가 토큰보다 중요해지면 모델 자체보다 시스템이 중요해진다.
   2. 따라서 어떤 단일 모델을 고를지보다 여러 모델과 도구를 어떻게 조율할지가 중요해진다.

2. IDC 전망

   1. IDC는 2028년까지 주요 대규모 AI 배포의 70%가 단일 모델에 의존하지 않고 여러 모델에서 작동할 것으로 예측한다.
   2. 모델별 강점과 비용, 지연시간, 작업 유형을 오케스트레이션 계층에서 조합하는 능력이 플랫폼 경쟁력이 된다.

6. 개발자와 플랫폼 리더의 책임

가치 맥싱은 특정 직무 하나의 절약 캠페인이 아니라 개발·플랫폼·리더십이 공유하는 엔지니어링 운영 원칙이다.

6.1. 개발자가 익혀야 할 AI 효율성

1. AI를 다른 컴퓨팅 자원처럼 다루기

   1. AI 사용을 클라우드 자원, 데이터베이스, 애플리케이션 성능과 같은 엔지니어링 자원으로 생각해야 한다.
   2. 목표는 AI를 덜 사용하는 것이 아니라 AI를 더 효과적으로 사용하는 것이다.

2. 실행 전후의 핵심 습관

   1. 좋은 컨텍스트 위생(context hygiene)은 오래됐거나 중복된 정보는 걷어내면서 올바른 판단에 필요한 정보는 보존한다.
   2. 실행 전에 계획을 세우면 잘못된 도구 호출과 불필요한 반복을 줄일 수 있다.
   3. 비용과 결과 사이의 트레이드오프를 이해하면 더 비싼 작업이 실제로 더 나은 결과를 주는지 판단할 수 있다.

6.2. 플랫폼 리더가 만들어야 할 가시성

1. 비용과 결과를 함께 보기

   1. 플랫폼 리더는 비용만 보여주는 대시보드에 머물지 않고 비용과 결과를 함께 볼 수 있어야 한다.
   2. 사용량을 측정하는 대신 가치를 측정하고, 효율적인 실행을 보상해야 한다.
   3. 팀이 AI의 영향을 이해하고 결과를 추적할 수 있는 도구를 제공해야 한다.

2. 공유 지표를 통한 책임성

   1. AI 효율성 문화를 만들려면 책임성, 가시성, 엔지니어링 워크플로 전반의 공유 지표가 필요하다.
   2. 개발자와 리더에게 책임을 부여하는 것만으로는 부족하며, 사용하는 플랫폼 자체가 소비와 결과를 연결해야 한다.

7. 플랫폼이 소비를 결과로 연결하는 방법

플랫폼은 개발자와 리더가 가치 맥싱을 실천할 수 있도록 통제·분석·실행 기능을 한데 제공해야 한다.

7.1. 관리·분석 계층

1. 관리 기능

   1. 관리용 통제 기능은 예산을 설정한다.
   2. 거버넌스와 가시성을 제공해 AI가 어디서 어떻게 사용되는지 파악하게 한다.

2. 분석 기능

   1. 분석 기능은 AI 소비량을 토큰 수에만 묶어두지 않는다.
   2. 소비량을 배포, 시간 절감, 품질, 재작업 같은 운영 결과와 연결한다.

7.2. 워크플로와 통합 계층

1. 불필요한 작업 줄이기

   1. 워크플로 기능은 반복적인 수동 작업을 줄인다.
   2. 스킬과 도구 통합은 에이전트가 필요한 시스템을 직접 연결해 불필요한 중간 작업을 줄인다.

2. 품질에 필요한 컨텍스트 보존

   1. 도구 통합과 워크플로 설계는 작업에 필요한 컨텍스트를 보존한다.
   2. 컨텍스트를 보존하면서 불필요한 정보만 제거해야 고품질 결과를 유지할 수 있다.

주요 발언 모음

“사용량을 보여주는 진정한 지표가 없으면 팀은 사용량 대시보드를 만들고, 사람들은 곧 그 대시보드를 게임하는 법을 배운다.”

“더 많은 활동이 더 많은 가치를 의미한다고 믿고 AI 사용량을 최대화하는 것이 토큰 맥싱이다.”

“비용은 사라지지 않는다. 워크플로의 다른 곳으로 이동할 뿐이다.”

“질문은 ‘토큰을 몇 개 사용했는가?’가 아니라 ‘배포를 몇 건 완료했는가, 개발자 시간을 얼마나 절약했는가, 재작업을 얼마나 피했는가, 취약점을 몇 건 해결했는가?’가 되어야 한다.”

“목표는 AI를 덜 사용하는 것이 아니라 AI를 더 효과적으로 사용하는 것이다.”

“첫 번째 장이 도입이었다면 다음 장은 가치다.”

핵심 데이터 & 수치

• 500토큰 대 5,000토큰: 아키텍처 컨텍스트를 입력에서 빼 500토큰을 절약해도 잘못된 코드의 디버깅과 재작업에 5,000토큰을 쓸 수 있다.
• 2028년 70%: IDC는 주요 대규모 AI 배포의 70%가 여러 모델에서 작동할 것으로 전망한다.
• 8분 15초 내외: 다루는 발표 분량은 약 493초이며, AI 사용량 측정부터 가치 맥싱과 플랫폼 책임까지 이어진다.
• 토큰: AI 모델이 텍스트를 처리하는 기본 단위로, 사용량과 비용을 수치화하기 쉽지만 업무 성과를 직접 나타내지는 않는다.

결론 및 시사점

1. 토큰 수는 AI가 사용됐는지 보여주는 출발점이지 AI가 성공했는지 보여주는 결승선이 아니다.
2. 토큰 맥싱과 토큰 최소화는 서로 반대처럼 보이지만 소비량을 최종 목표로 삼는다는 점에서 같은 오류를 공유한다.
3. 불필요한 도구 카탈로그와 오래된 컨텍스트는 줄이되, 작업 설명·도메인 제약·아키텍처 정보는 품질에 필요한 만큼 보존해야 한다.
4. 배포 완료, 절약한 개발 시간, 회피한 재작업, 해결한 취약점 같은 결과 지표가 추가 토큰 사용의 정당성을 판단해야 한다.
5. 모델 효율성과 비용 구조는 계속 바뀌므로 특정 모델의 현재 가격이나 성능을 영구적인 최적 기준으로 삼을 수 없다.
6. 모델 선택보다 컨텍스트 관리, 워크플로 오케스트레이션, 거버넌스, 최적화를 결합한 시스템 설계가 중요해진다.
7. 개발자는 AI 사용을 클라우드·데이터베이스·애플리케이션 성능처럼 관리하고, 플랫폼 리더는 비용과 결과를 함께 추적해야 한다.
8. AI의 다음 성장 단계는 더 많은 사용량을 만드는 것이 아니라, 같은 사용량으로 더 큰 운영 가치를 만들고 필요한 경우 더 큰 가치에 맞춰 소비를 허용하는 것이다.