Token Economics — 청구서가 왔다

이전 이야기에서: 지민은 Agent Memory로 세션을 넘어 학습이 축적되는 시스템을 만들었다. "드디어 경력사원이네." 하지만 론칭 전 마지막 스퍼트에서 3개의 Opus 에이전트를 동시에 돌렸다. 다음 날 아침, 비용 대시보드를 열었다...

Harness = Tools + Knowledge + Context + Permissions

Token Economics는 Context의 비용을 의식적으로 관리한다. "무한한 지능, 유한한 예산"

"이 청구서가 맞아?"

론칭 전날, 지민은 3개의 Opus 에이전트를 동시에 돌렸다.

backend-agent, frontend-agent, qa-agent. 각각 4시간씩 작업했다.

다음 날 아침, API 사용량 대시보드를 열었다.

일일 비용 리포트:
  backend-agent  (Opus):  $47.20   (입력 280K + 출력 45K 토큰)
  frontend-agent (Opus):  $38.50   (입력 220K + 출력 40K 토큰)
  qa-agent       (Opus):  $29.80   (입력 170K + 출력 30K 토큰)
  ─────────────────────────────────
  합계:                   $115.50 / 하루

소연에게 이 비용을 보고할 수 있을까? 매일 $115?

지민은 자문했다. "qa-agent한테 Opus가 정말 필요했을까?"

모델 선택: 적재적소

Claude에는 세 가지 모델이 있다. 각각 능력과 비용이 다르다.

모델 비교 (대략적):

Opus 4.6  — 가장 똑똑함, 가장 비쌈
  강점: 복잡한 아키텍처 결정, 깊은 추론, 어려운 버그
  비용: $$$$
  속도: 느림

Sonnet 4.6 — 균형형
  강점: 일반 개발 작업, 코드 작성, 리팩토링
  비용: $$
  속도: 보통

Haiku 4.5  — 가장 빠름, 가장 저렴
  강점: 간단한 분석, 패턴 추출, 경량 작업
  비용: $
  속도: 빠름

모델 라우팅 전략

모든 작업에 Opus를 쓸 필요가 없다:

작업별 최적 모델:

Opus가 필요한 경우:
  → 복잡한 아키텍처 결정
  → 멀티파일 리팩토링 (파일 간 의존성 추론)
  → 미묘한 보안 취약점 분석
  → 새로운 시스템 설계

Sonnet으로 충분한 경우:
  → 일반적인 기능 구현
  → 코드 리뷰
  → 테스트 작성
  → 문서 생성

Haiku가 적합한 경우:
  → 로그 분석, 패턴 추출
  → 단순한 파일 변환
  → 백그라운드 모니터링
  → 코드 포맷팅 검사