Tokenmaxxing은 정말 낭비일까: AI Agent 비용을 아껴야 할 때와 과감하게 써야 할 때

2026년 AI 개발 업계에서 꽤 재미있는 논쟁이 벌어지고 있다.

한쪽에서는 이렇게 말한다.

Token 아끼지 마라.

Agent를 많이 돌려라.

병렬로 여러 방법을 시도해라.

지금 비싼 비용보다
AI를 먼저 제대로 사용하는 경험이 더 중요하다.

반대쪽에서는 완전히 다른 이야기가 나온다.

Agent 사용량이 폭증했다.

비용도 폭증했다.

그런데 생산성이
그만큼 증가했는지는 모르겠다.

이제 Token부터 최적화해야 한다.

최근 Y Combinator CEO Garry Tan은 스타트업 창업자들이 적극적으로 AI Token을 사용하는 이른바 Tokenmaxxing을 해야 한다는 쪽에 서 있다.

반면 Uber에서는 AI 사용을 적극 장려한 뒤 예상보다 훨씬 빠르게 AI 예산을 소진하면서 이제는 무조건 Token을 많이 사용하는 방식보다 효율을 높이는 쪽으로 방향을 바꾸고 있다.

표면적으로 보면 서로 반대되는 주장이다.

하지만 Agent를 실제 개발에 사용해 보면 둘 다 맞는 이야기라는 것을 알 수 있다.

핵심은 이것이다.

Token을 많이 쓰느냐

vs

Token을 적게 쓰느냐

가 아니다.

어떤 단계에서
어떤 Token을
어떤 결과를 얻기 위해 쓰느냐

가 중요하다.

이번 글에서는 Tokenmaxxing을 무조건 낭비라고 보지도 않고, 반대로 AI Agent에 Token을 무제한으로 태우는 것도 권장하지 않는다.

대신 실제 Coding Agent를 운영할 때 사용할 수 있는 Token 투자 전략을 만들어본다.

---

1. Tokenmaxxing이란 무엇인가

Tokenmaxxing은 정식 AI 기술 용어라기보다 최근 AI 업계에서 생긴 표현이다.

개념은 단순하다.

AI를 적극적으로 사용한다.

↓

더 많은 Agent를 실행한다.

↓

더 많은 Context를 제공한다.

↓

더 많은 방법을 탐색한다.

↓

더 많은 Token을 사용한다.

초기에는 특히 Coding Agent 사용과 함께 많이 등장했다.

Codex나 Claude Code 같은 Agent에게 작은 질문 하나만 던지는 것이 아니라:

Repository 전체 분석

Architecture 조사

여러 구현 방법 비교

Subagent 병렬 실행

Test 생성

Review

재수정

까지 맡긴다.

당연히 Token 사용량이 크게 증가한다.

하지만 이 과정에서 사람이 하루 종일 하던 작업을 Agent가 대신한다면 Token 비용 자체가 반드시 낭비라고 볼 수는 없다.

---

2. Token 비용만 보면 판단을 잘못할 수 있다

예를 들어 개발자가 하루 동안 Bug 하나를 조사한다고 하자.

사람이 직접 하면:

Repository 조사       2시간

로그 분석             1시간

원인 추적             2시간

수정                  1시간

Test                  1시간

-------------------------

총 7시간

Agent를 사용했는데:

Agent Cost

$18

가 들었다고 하자.

Token만 보면:

AI에 $18이나 썼다.

가 된다.

하지만 개발자의 5시간을 줄였다면 전혀 다른 계산이 된다.

따라서 Agent 경제성은:

Token Cost

가 아니라

Token Cost

vs

Human Time Saved

+

Task Quality

+

Delivery Speed

로 봐야 한다.

---

3. 반대로 Token을 많이 썼다고 생산적인 것도 아니다

문제는 반대 방향에서도 생긴다.

Agent가 다음 행동을 반복한다고 하자.

Repository Search

↓

잘못된 가설

↓

다시 Search

↓

Subagent 생성

↓

같은 파일 다시 읽음

↓

새 가설

↓

또 다른 Agent

↓

Context 증가

↓

Retry

결과:

Token 4M

을 사용했다.

그런데 최종 결과는:

Bug 수정 실패

다.

이 경우 Token 사용량은 생산성이 아니다.

단순 소비다.

그래서 이런 지표는 별 의미가 없다.

개발자 A

이번 달 1억 Token 사용

개발자 B

이번 달 2천만 Token 사용

A가 더 AI를 잘 사용한다고 판단할 수 없다.

---

4. 실제 Agent Task의 Token 소비는 상당히 불규칙하다

최근 Coding Agent의 Token 소비를 분석한 연구에서 재미있는 결과가 나왔다.

같은 Task라도 Agent 실행에 따라 사용 Token이 크게 달라질 수 있었다.

즉:

동일 Task

Run A
────────
300K Token

Run B
────────
1.2M Token

Run C
────────
4M Token

같은 현상이 발생할 수 있다는 것이다.

더 중요한 부분은:

Token ↑

=

Accuracy ↑

가 아니었다는 점이다.

일정 수준 이후에는 Token을 더 사용해도 성공률이 거의 증가하지 않거나 오히려 비효율적인 경우가 있었다.

Agent에서는 생각을 많이 하는 것과 같은 생각을 반복하는 것을 구분해야 한다.

---

5. 그래서 Tokenmaxxing을 두 단계로 나눠야 한다

가장 실용적인 방법은 다음이다.

EXPLORE

↓

OPTIMIZE

초기에는 과감하게 Token을 사용한다.

좋은 Workflow를 찾으면 최적화한다.

---

6. EXPLORE 단계에서는 Token을 아끼지 않는다

새로운 문제를 처음 자동화한다고 하자.

예:

iOS Release Agent

처음부터 Token을 최소화하려고 하면 Agent에게 매우 좁은 작업만 준다.

version 올려.

끝.

그러면 Agent가 실제 어디까지 할 수 있는지 알 수 없다.

처음에는 오히려 넓게 시도한다.

Release Branch 확인

↓

Version 분석

↓

Change Log 생성

↓

Build

↓

Test

↓

Signing 확인

↓

TestFlight 준비

↓

Release Risk 분석

여러 Agent를 병렬로 돌려볼 수도 있다.

Release Planner

Build Agent

Test Agent

Store Validator

Reviewer

비용은 많이 든다.

하지만 이 단계의 목적은 비용 절감이 아니다.

무엇을 자동화할 수 있는가?

를 발견하는 것이다.

---

7. 새로운 Agent Workflow를 찾을 때 Tokenmaxxing은 꽤 합리적이다

예를 들어 처음 Bug Investigation Agent를 만든다고 하자.

한 Agent만 실행한다.

Agent A

와 여러 전략을 동시에 사용하는 구조를 비교한다.

Agent A

Call Graph 분석

Agent B

Git History 분석

Agent C

Test Failure 분석

Agent D

최근 PR 분석

↓

Main Agent

Evidence 통합

이런 병렬 탐색은 분명 Token을 더 사용한다.

하지만 복잡한 Bug라면 탐색 공간을 빠르게 줄이는 데 돈을 쓰는 것이다.

이런 Token 사용은 단순 낭비와 다르다.

---

8. Security 문제도 Token을 과감하게 쓸 가치가 있다

예를 들어 Security Review를 한다.

인증

권한

Credential

Dependency

Network

Input Validation

을 각각 다른 Agent가 분석할 수 있다.

Auth Reviewer

Dependency Reviewer

Secret Reviewer

Network Reviewer

↓

Security Coordinator

비용은 증가한다.

하지만 중요한 취약점 하나를 놓치는 비용과 비교하면 Token 비용은 작을 수 있다.

즉 Token Budget은 Task Risk와 연결해야 한다.

---

9. Migration도 Token을 많이 써볼 만한 영역이다

예:

UIKit

→ SwiftUI

RxSwift

→ async/await

Legacy Android

→ Compose

같은 작업이다.

Agent에게 단순히:

전환해.

라고 하기보다

Repository 조사

↓

Migration Plan

↓

Dependency Graph

↓

Risk 분석

↓

작은 Pilot

↓

Implementation

↓

Regression Review

를 수행하게 하는 편이 낫다.

이런 작업에서는 Token을 너무 아끼면 오히려 재작업 비용이 커질 수 있다.

---

10. 반대로 Token을 거의 쓰면 안 되는 작업도 있다

예를 들어 파일 이름을 바꾼다.

ProfileViewModel

→ UserProfileViewModel

Agent 5개를 돌릴 이유가 없다.

Search

↓

Rename

↓

Compile

↓

끝

이면 된다.

또:

Version Number 증가

Generated File 정리

Formatter

Lint Fix

Known Pattern Migration

처럼 결과가 거의 결정론적인 작업도 마찬가지다.

이런 곳에 Frontier Model + Ultra Reasoning + Subagent 8개를 사용하면 명백한 낭비다.

---

11. 가장 나쁜 Token 사용은 “이미 아는 일을 다시 생각하는 것”이다

Agent가 매번 이런 작업을 반복한다고 하자.

Architecture 조사

↓

결론

↓

Task 종료

다음 Task:

Architecture 조사

↓

같은 결론

또 다음 Task:

Architecture 조사

↓

같은 결론

이 Token은 거의 전부 낭비다.

앞서 다룬 Agent Memory와 연결되는 부분이다.

결과를 저장한다.

.ai/
└── memory/
    └── architecture/
        └── auth.md

다음부터:

Memory

↓

현재 Source 확인

↓

작업 시작

으로 바꾼다.

---

12. Tokenmaxxing의 다음 단계는 Skillification이다

최근 Tokenmaxxing을 옹호하는 쪽에서 흥미로운 주장이 하나 나온다.

처음에는 Agent에게 Token을 많이 써보면서 어떤 작업이 실제 자동화 가능한지를 찾는다.

그리고 반복 가능한 Workflow가 발견되면 이를 Skill로 고정한다.

예:

처음

Agent에게 매번 설명

↓

Token 많이 사용

작업이 안정화된다.

Release Workflow 발견

↓

Skill 생성

↓

다음부터 Skill 실행

즉:

Tokenmaxxing

↓

Workflow Discovery

↓

Skillification

↓

Token Optimization

이다.

이 관점은 꽤 합리적이다.

---

13. 예를 들어 PR Review를 처음 만든다고 하자

초기 Prompt:

이 PR을 자세히 분석해.

Architecture 문제,
Concurrency 문제,
Security,
테스트 누락,
Breaking Change를 모두 검토해.

필요하면 Repository도 조사해.

Agent는 상당히 많은 Token을 사용한다.

몇십 번 사용해보니 항상 같은 절차가 반복된다.

Diff 확인

↓

관련 File 확인

↓

Public API 변경 확인

↓

Concurrency 확인

↓

Test 확인

↓

Risk Report

그러면 이걸 Skill로 만든다.

skills/
└── pr-review/
    ├── SKILL.md
    ├── checklist.md
    └── scripts/

다음부터 Agent가 절차를 새로 설계할 필요가 없다.

---

14. 더 나아가 결정론적인 부분은 Script로 뺀다

PR Review Skill에서:

Changed File 찾기

Diff 통계

Test File 존재 확인

Lint

같은 것은 LLM이 할 필요가 없다.

Script로 만든다.

git diff --name-only origin/main...HEAD

swiftlint

./gradlew lint

Agent는 결과를 해석한다.

LLM

판단해야 하는 부분

만 맡긴다.

이게 실제 Token 최적화다.

---

15. Token을 줄인다는 것은 Agent를 덜 쓰는 것이 아니다

잘못된 비용 절감:

Agent 사용 금지

↓

Token 절약

보다 좋은 비용 절감:

Agent는 계속 사용

↓

불필요한 Reasoning 제거

↓

반복 Workflow Skill화

↓

결정론적 작업 Script화

↓

Task별 Model Routing

↓

Context 재사용

이다.

목표는:

Minimum Token

이 아니라

Minimum Cost per Successful Outcome

이다.

---

16. 여기서 Model Routing이 등장한다

모든 Task를 가장 강한 모델에 보낼 필요가 없다.

예를 들어:

Repository Search

→ Fast Model

File Classification

→ Fast Model

Boilerplate 생성

→ Mid Model

Architecture 판단

→ Frontier Model

최종 Review

→ Frontier Model

처럼 나눌 수 있다.

구조:

Task

↓

Router

├── Search Worker
├── Coding Worker
├── Test Worker
└── Frontier Reviewer

Tokenmaxxing에서 비용 효율화 단계로 넘어갈 때 가장 중요한 변화 중 하나다.

---

17. “Modelmaxxing”이라는 표현이 나오는 이유도 이것이다

2026년 들어 일부 팀에서는 단순히 Token을 많이 사용하는 방식에서 벗어나 Task에 맞는 모델을 골라 쓰는 방식으로 이동하고 있다.

복잡한 문제:

강한 Model

단순 반복:

빠르고 저렴한 Model

Search:

작은 Model

최종 판단:

Frontier Model

이다.

비용 제한을 먼저 거는 것보다 어디에 비싼 추론을 사용할지를 정하는 것이다.

---

18. Agent Runtime에 세 가지 Budget Mode를 만들 수 있다

실전에서는 다음 정도면 충분하다.

EXPLORE

BALANCED

ECONOMY

---

19. EXPLORE

새로운 문제.

mode: explore

reasoning:
  budget: high

subagents:
  max: 6

retries:
  max: 3

parallel_exploration: true

verification:
  level: high

Token을 적극적으로 쓴다.

목적:

가능한 Workflow 발견

---

20. BALANCED

일반 개발 작업.

mode: balanced

reasoning:
  budget: medium

subagents:
  max: 2

retries:
  max: 2

parallel_exploration: conditional

verification:
  level: standard

대부분의 Coding Agent 작업은 여기에 들어간다.

---

21. ECONOMY

이미 잘 알려진 반복 작업.

mode: economy

reasoning:
  budget: low

subagents:
  max: 0

retries:
  max: 1

parallel_exploration: false

verification:
  level: deterministic

예:

Formatting

Version Update

Known Migration

Generated Code

Simple Test Generation

등이다.

---

22. 개발자가 매번 Mode를 선택할 필요도 없다

Agent Router가 판단할 수 있다.

type TokenMode =
  | "explore"
  | "balanced"
  | "economy";

function selectMode(task: Task): TokenMode {
  if (
    task.novelty === "high" ||
    task.risk === "high"
  ) {
    return "explore";
  }

  if (
    task.repeatability === "high" &&
    task.knownProcedure === true
  ) {
    return "economy";
  }

  return "balanced";
}

정교한 AI Router까지 필요 없다.

Rule 기반으로 시작해도 충분하다.

---

23. Token Budget을 Agent에게 명시한다

무제한 Agent Loop를 막는다.

budget:

  max_input_tokens: 800000

  max_output_tokens: 100000

  max_tool_calls: 80

  max_subagents: 4

  max_retries: 2

  max_wall_time_minutes: 45

이 숫자는 예시다.

프로젝트마다 실제 사용량을 측정해서 결정한다.

---

24. Retry Budget이 특히 중요하다

Agent가 실패했다고 무조건 Retry하면 비용이 크게 증가한다.

Attempt 1

실패

↓

Attempt 2

같은 Context

같은 전략

실패

↓

Attempt 3

같은 전략

실패

이건 Retry가 아니라 Token 낭비다.

Retry 전 질문이 하나 필요하다.

무엇이 달라졌는가?

---

25. Retry는 전략이 바뀌었을 때만 한다

예:

Attempt 1

코드 검색 기반

실패.

다음:

Attempt 2

Git History 기반

실패.

다음:

Attempt 3

Test Trace 기반

이라면 의미가 있다.

반대로 같은 Prompt 재실행은 제한한다.

---

26. Stop Condition을 반드시 둔다

Agent에게:

될 때까지 계속해.

는 위험하다.

대신:

다음 조건 중 하나면 중단.

1. 테스트 통과
2. 동일 원인으로 2회 실패
3. 새로운 Evidence 없음
4. Token Budget 80% 도달
5. Human Decision 필요

처럼 둔다.

---

27. Context도 가장 큰 Token 비용 중 하나다

Agent 비용을 줄인다고 Output을 짧게 만들려고 하는 경우가 많다.

하지만 Coding Agent에서는 입력 Context가 훨씬 커질 수 있다.

Repository File

Tool Result

Build Log

Conversation

MCP Result

Subagent Result

가 계속 누적되기 때문이다.

따라서:

Output을 500 Token 줄임

보다

필요 없는 Build Log 40K Token 제거

가 훨씬 효과적일 수 있다.

---

28. 긴 Log는 파일로 내린다

나쁜 방식:

Build Log 50,000줄

↓

Main Agent Context

좋은 방식:

Build Log

↓

Artifact 저장

↓

Error 추출

↓

관련 부분만 Context

예:

rg "error:|fatal error:|BUILD FAILED" build.log

Agent는 필요한 부분만 읽는다.

---

29. Subagent 결과도 전체를 Main Agent에게 반환하지 않는다

나쁜 방식:

Explorer Agent

20K Token 결과

↓

Main Agent

4개면:

80K Token

이다.

대신:

{
  "summary": "Race originates in SessionCoordinator.",
  "evidence": [
    "SessionCoordinator.swift:142",
    "SessionRefreshTests.swift:81"
  ],
  "artifact": ".ai/artifacts/auth-investigation.md"
}

만 반환한다.

원본은 Artifact에 둔다.

---

30. Cache를 잘 쓰면 반복 Context 비용을 줄일 수 있다

Agent에는 계속 반복되는 Context가 많다.

System Instructions

AGENTS.md

Tool Definition

Architecture Rule

Skill Definition

이 부분은 매 Task마다 거의 같다.

Provider가 Prompt/Input Caching을 지원한다면 정적 Prefix를 안정적으로 유지해 Cache Hit가 발생하기 쉽게 만드는 것이 유리하다.

즉 Prompt 순서도 중요해진다.

Stable Context

↓

Variable Task Context

구조를 유지한다.

---

31. AGENTS.md도 무한히 키우면 Token 낭비다

예:

AGENTS.md

2,500줄

Agent가 모든 Task에서 읽는다.

하지만 현재 Camera 작업에:

Billing Architecture

Release Policy

Analytics Rule

Database Migration

까지 필요하지 않을 수 있다.

따라서 Root에는 Map만 둔다.

Architecture:
docs/architecture/

Release:
docs/release/

Camera:
docs/camera/

필요한 Context만 읽는다.

---

32. Tokenmaxxing에서 가장 위험한 것은 Subagent Fan-out이다

Main Agent가 쉽게 이렇게 할 수 있다.

Subagent 1

Subagent 2

Subagent 3

Subagent 4

Subagent 5

Subagent 6

각 Agent가 또 Subagent를 만든다.

6 × 4

순식간에 실행량이 증가한다.

그래서:

delegation:
  max_depth: 2
  max_agents: 6

같은 제한이 필요하다.

---

33. 병렬 Agent는 서로 다른 질문을 할 때만 가치가 있다

나쁜 병렬화:

Agent A

Bug 원인 찾아.

Agent B

Bug 원인 찾아.

Agent C

Bug 원인 찾아.

모두 같은 방식으로 조사할 가능성이 있다.

좋은 병렬화:

Agent A

Call Graph

Agent B

Git History

Agent C

Runtime Logs

Agent D

Tests

탐색 축을 나눈다.

Token이 실제로 정보량을 증가시킨다.

---

34. Token 효율의 핵심 지표는 Cost per Successful Task다

월 AI 비용:

$30,000

만 보면 많아 보일 수 있다.

하지만:

완료 Task

1,500

라면:

$20 / Successful Task

다.

반대로:

AI Cost

$5,000

Successful Tasks

50

이면:

$100 / Task

다.

두 번째가 더 비효율적이다.

---

35. Task 유형별로 따로 봐야 한다

예:

Bug Investigation

평균 $9

Unit Test 추가

평균 $3

Dependency Upgrade

평균 $4

Architecture Migration

평균 $72

이 데이터를 보면 어떤 작업을 Agent에게 맡길지 판단하기 쉬워진다.

---

36. 성공률까지 넣는다

예:

Model A

평균 비용     $7
성공률        62%

Model B

평균 비용     $18
성공률        94%

실패하면 사람이 다시 해야 한다.

따라서 단순 Task 비용보다:

Expected Cost per Success

를 보는 편이 낫다.

---

37. Agent Usage Dashboard

최소 다음 정도면 충분하다.

AI AGENT — WEEKLY

Successful Tasks       428

Failed Tasks             51

Total Tokens          184M

Cached Tokens          91M

Cost                 $3,820

Cost / Success        $8.93

Retry Rate             14%

Repeated Investigation  7%

Subagent Fan-out       2.1

Human Rework            9%

이런 Dashboard라면:

이번 달 Token 2억 사용

보다 훨씬 의미가 있다.

---

38. Token 사용량을 개발자 KPI로 쓰면 안 된다

다음 같은 Leaderboard를 만들면:

1위 김개발

92M Token

2위 이개발

81M Token

사람들은 자연스럽게 Metric을 최적화한다.

필요 없는 Agent 실행

긴 Context

과도한 Subagent

불필요한 Retry

가 생길 수 있다.

Token은 Resource Metric이지 생산성 Metric이 아니다.

---

39. 좋은 Tokenmaxxing은 Learning Investment다

Token을 많이 써도 되는 가장 명확한 상황은:

아직 무엇이 가능한지 모를 때

다.

새로운 Agent Workflow를 만든다.

여러 Model을 비교한다.

다양한 Task를 Agent에게 맡긴다.

많이 실패한다.

그 과정에서 발견한다.

이 작업은 Agent가 정말 잘한다.

이 작업은 사람이 더 빠르다.

이 작업은 Skill로 만들 수 있다.

이 작업은 Script가 낫다.

이 Learning에 Token을 쓰는 것은 합리적이다.

---

40. 나쁜 Tokenmaxxing은 Steady State에서 계속 발생한다

6개월째 같은 작업인데:

매번 Repository 조사

매번 Architecture 조사

매번 Tool 선택

매번 Plan 생성

매번 긴 Reasoning

을 반복한다면 문제가 있다.

이미 Workflow가 알려졌는데도 계속 Discovery 비용을 내고 있는 것이다.

이 시점에는:

Skill

Template

Script

Memory

Cache

Router

로 전환해야 한다.

---

41. 결국 Token 전략은 Exploration과 Exploitation 문제다

Agent 개발 초기:

Exploration

비중을 높인다.

여러 Agent

여러 Model

넓은 Context

여러 전략

↓

좋은 Workflow 발견.

운영 단계:

Exploitation

으로 이동한다.

Skill

Model Routing

Cache

Script

Memory

Budget

↓

비용 감소.

---

42. 실제 Coding Agent 운영 정책

Repository에 다음 정도를 둘 수 있다.

.ai/
├── policies/
│   └── token-policy.yaml
│
├── skills/
├── memory/
└── artifacts/

token-policy.yaml

version: 1

modes:

  explore:
    maxSubagents: 6
    maxRetries: 3
    reasoning: high

  balanced:
    maxSubagents: 2
    maxRetries: 2
    reasoning: medium

  economy:
    maxSubagents: 0
    maxRetries: 1
    reasoning: low

stop:
  sameFailure: 2
  noNewEvidence: true
  budgetThreshold: 0.8

특정 Codex나 Claude Code의 공식 설정 파일이라는 의미는 아니다.

팀 정책을 표현하기 위한 예시다.

---

43. AGENTS.md에도 간단한 규칙을 넣는다

# Token Policy

## Exploration

새로운 Architecture, 원인 불명의 Bug,
Security Review에서는 충분한 탐색을 허용한다.

## Repeated Tasks

이미 Skill이나 Script가 있는 작업은
새로운 Workflow를 만들지 않는다.

## Subagents

Subagent는 서로 다른 탐색 목적이 있을 때만 생성한다.

동일 Task를 복제한 Agent를 여러 개 만들지 않는다.

## Retry

동일 전략으로 실패한 작업을 반복하지 않는다.

Retry 전 반드시 새로운 Evidence 또는 전략이 있어야 한다.

## Context

긴 로그와 Tool 결과를 Main Context에 복사하지 않는다.

Artifact로 저장하고 필요한 부분만 읽는다.

## Validation

Token 절약을 이유로 Build, Test,
Security Validation을 생략하지 않는다.

마지막 줄이 중요하다.

---

44. 절대 줄이면 안 되는 Token도 있다

비용 절감을 시작하면 가장 먼저 Verification을 줄이고 싶어진다.

Reviewer 제거

Test Agent 제거

Security Review 제거

하지만 이건 위험하다.

Agent가 코드를 빠르게 만든 뒤:

Verification 없음

이면 재작업이나 장애 비용이 훨씬 커질 수 있다.

Token Budget에서도:

Generation

↓

절감 가능

Repeated Search

↓

적극 절감

Verification

↓

함부로 줄이지 않음

정도로 구분하는 편이 좋다.

---

45. 가장 먼저 줄여야 하는 Token

순서를 잡으면 이렇다.

1.

중복 Context

2.

반복 File Read

3.

동일 전략 Retry

4.

중복 Subagent

5.

불필요한 Frontier Model 사용

6.

이미 알려진 Workflow의 재탐색

이걸 먼저 줄인다.

---

46. 마지막에 줄여야 하는 Token

Architecture 검증

Security 검증

Critical Test

Migration Review

고위험 의사결정

이다.

비용이 가장 비싼 Agent가 항상 낭비인 것은 아니다.

실패 비용이 높은 작업에 비싼 Agent를 쓰는 것은 보험에 가깝다.

---

47. Tokenmaxxing을 제대로 하려면 결과를 남겨야 한다

Token을 많이 사용했다.

그 결과 발견한 것이 있다.

새 Workflow

좋은 Prompt

Tool 조합

Architecture Pattern

Failure Pattern

그런데 아무것도 남기지 않았다.

다음 사람은 다시 Token을 쓴다.

이건 낭비다.

결과를:

Skill

AGENTS.md

Template

Memory

Script

Eval

중 하나로 남긴다.

---

48. Token을 “소비”하지 말고 “자산으로 변환”한다

좋은 흐름:

$100 Token 사용

↓

새 Release Workflow 발견

↓

Skill 생성

↓

100번 재사용

이면 초기 $100은 R&D 비용이다.

나쁜 흐름:

$100 Token 사용

↓

Task 종료

↓

Knowledge 사라짐

↓

다음 주 다시 $100

이다.

이 차이가 크다.

---

49. 그래서 Tokenmaxxing의 가장 좋은 종료 조건은 Skill이다

Agent가 같은 Task를 세 번 이상 안정적으로 처리한다.

Task

↓

Agent

↓

성공

반복된다.

그 순간 질문한다.

이 Workflow를 Skill이나 Script로
고정할 수 있는가?

가능하다면 Exploration 단계는 끝난다.

---

50. 추천 운영 방식

처음 2~4주:

AI Budget

넉넉하게

목표:

Workflow Discovery

측정:

Task Success

Human Time Saved

Useful Agent Pattern

그다음:

Skillification

Model Routing

Caching

Memory

Budget

을 적용한다.

그리고 이후에는:

Cost per Successful Task

를 관리한다.

---

51. 스타트업과 대기업의 전략도 달라질 수 있다

초기 스타트업:

현금 비용 ↑

하지만

Learning Speed ↑↑

가 중요할 수 있다.

특히:

AI Native Product

Agent Workflow

새로운 개발 방식

을 찾는 회사라면 Token을 공격적으로 사용할 이유가 있다.

반면 수만 명 규모 기업:

Token 20% 증가

만으로도 비용이 크게 변한다.

이 단계에서는:

Governance

Model Routing

Caching

Budget

Usage Visibility

가 중요해진다.

그래서 YC와 Uber의 이야기가 서로 다르게 들리는 것도 자연스럽다.

---

52. 결국 둘 다 맞다

한쪽:

Token을 아끼지 마라.

다른 쪽:

Tokenmaxxing 시대는 끝났다.

둘 중 하나를 고를 필요가 없다.

정확한 전략은:

발견할 때는 많이 쓴다.

반복되기 시작하면 줄인다.

이다.

---

53. 마무리

Tokenmaxxing을 단순히

AI 비용 낭비

라고 보면 중요한 부분을 놓친다.

AI Agent가 실제로 어떤 업무까지 수행할 수 있는지 아직 빠르게 바뀌고 있는 시기에는 충분한 Token을 사용하면서 새로운 Workflow를 발견하는 것 자체가 투자가 될 수 있다.

반대로:

Token 많이 사용

=

AI 잘 사용

이라고 생각하는 순간 문제가 시작된다.

같은 작업을 반복해서 탐색하고,

같은 Context를 계속 보내고,

같은 실패를 Retry하고,

모든 Task에 가장 강한 모델을 사용하고,

Subagent를 무작정 늘리는 것은 생산성이 아니다.

그래서 Agent Token 전략은 다음 흐름으로 잡는 것이 가장 현실적이다.

Tokenmaxxing

↓

Explore

↓

좋은 Workflow 발견

↓

Skillify

↓

Script화

↓

Memory

↓

Cache

↓

Model Routing

↓

Token Budget

↓

Cost per Successful Task 측정

중요한 것은 Token 자체가 아니다.

이 Token이
새로운 정보를 만들었는가?

좋은 결정을 만들었는가?

사람 시간을 줄였는가?

실패 위험을 낮췄는가?

다음 작업에서도 재사용 가능한
자산을 만들었는가?

를 봐야 한다.

한 줄로 정리하면 이렇다.

Token은 아껴야 하는 자원이지만,
무조건 적게 써야 하는 자원은 아니다.

새로운 Agent Workflow를 발견할 때는
과감하게 쓰고,

Workflow가 반복되기 시작하면
Skill·Cache·Memory·Model Routing으로
빠르게 최적화하는 것이 가장 효율적이다.

결국 AI Agent 시대의 비용 최적화는 Token을 적게 쓰는 기술이 아니라, 가장 가치 있는 곳에 Token을 배분하는 기술에 가까워지고 있다.

---

참고 자료

• Business Insider — Garry Tan says founders who tokenmaxx on AI agents will be 2 years ahead
  Y Combinator CEO Garry Tan이 스타트업 초기에는 AI Agent Token 비용을 지나치게 아끼기보다 적극적으로 사용하며 가능한 Workflow를 발견해야 한다고 주장한 최근 인터뷰.

• Fortune / Yahoo Finance — Uber CTO says the tokenmaxxing era is coming to an end
  Uber가 AI Coding Tool 사용을 공격적으로 확대하면서 연간 AI 예산을 예상보다 빠르게 소비한 뒤 Token당 비용과 사용 효율을 다시 관리하게 된 사례.

• Business Insider — Tokenmaxxing is so over. It’s all about modelmaxxing now
  모든 Task에 동일하게 많은 Token을 사용하는 대신 Task 난이도에 따라 모델을 바꾸는 Model Routing 흐름을 다룬 최근 기사.

• Bai et al. — How Do AI Agents Spend Your Money? Analyzing and Predicting Token Consumption in Agentic Coding Tasks
  Agentic Coding Task에서 Token 소비량·모델별 효율·Task별 변동성을 분석하고, 더 많은 Token 사용이 항상 더 높은 정확도로 이어지지는 않는다는 점을 분석한 연구.

• OpenAI Agents SDK — Usage
  Agent Run별 Request, Input Token, Output Token, Cached Token, Reasoning Token 등의 실제 사용량을 추적해 Budget·Analytics에 활용하는 공식 문서.

핵심 참고 포인트

Tokenmaxxing 논쟁에서 중요한 것은 어느 한쪽의 주장이 절대적으로 맞다는 것이 아니다.

스타트업이나 새로운 Agent Workflow를 탐색하는 단계에서는 충분한 Token을 투입해 가능한 자동화 범위를 빠르게 알아내는 것이 합리적일 수 있다. 반면 이미 Workflow가 알려진 Production 환경에서 동일한 탐색 비용을 계속 지불하는 것은 최적화 대상이다.

따라서 실무에서는 Exploration 단계에서는 Token Budget을 넓게 주고, 성공한 Workflow를 Skill·Script·Template로 고정한 뒤 Production에서는 Model Routing·Cache·Memory·Retry 제한·Subagent Budget을 적용하는 방식이 가장 현실적이다.

최종 KPI 역시 Token 사용량 자체보다 Cost per Successful Task, Human Rework, Retry Rate, Task Success, Human Time Saved처럼 실제 Outcome과 연결된 지표를 사용하는 편이 좋다.