함수 이름 하나 바꾸는 데 토큰 8,400개가 나갔다
dev.to에 올라온 한 개발자의 고백은 AI-First 워크플로우를 진지하게 도입 중인 팀이라면 불편하게 읽어야 할 글이다. Cursor 채팅창에 "rename getUser to fetchUser" 열한 글자를 입력했더니 Anthropic 콘솔에서 8,400 입력 토큰이 찍혔다. 같은 요청을 Anthropic API에 직접 날렸을 때는 1,900 토큰. 차이는 6,500 토큰, 약 3.4배다.
이건 Cursor를 욕하려는 이야기가 아니다. Cursor가 보내는 추가 컨텍스트—시스템 프롬프트, 최근 파일 인덱스, 에이전트 툴 정의—는 멀티파일 리팩토링처럼 컨텍스트가 실제로 필요한 작업에서는 값어치를 한다. 문제는 세 줄짜리 함수 하나 rename하는 데도 동일한 오버헤드가 발생한다는 것이다. Cursor는 고정 시트 요금제라 토큰을 적게 써도 덜 내지 않는다. 그러나 사용자가 API를 직접 호출하는 워크플로우를 병행하면, 그 비용은 고스란히 사용자의 변동 청구서에 쌓인다.
라우팅 레이어를 직접 소유하면 청구서가 41% 줄었다
해당 개발자는 결국 200줄짜리 TypeScript 라우터를 직접 짰다. 로직은 단순하다: 정규식 다섯 개로 인텐트를 분류하고, 간단한 프롬프트는 Claude Haiku로, 코드 작업은 Sonnet으로, 계획·설계 작업만 Opus로 보낸다. 모든 호출에 모델명·비용·프롬프트 길이를 로깅한다.
결과: Sonnet 비중이 70%→25%, Haiku가 0%→60%, 실제 5월 청구서에서 41% 절감. 더 흥미로운 건 호출 빈도가 30% 증가했다는 사실이다. 호출당 비용이 내려가자 AI에 손이 더 자주 갔고, 결과적으로 총비용은 줄면서 생산성은 올랐다.
이 사례가 팀 리드에게 주는 메시지는 분명하다. 라우팅 레이어를 AI 도구 벤더에게 맡기는 한, 비용 가시성도 최적화 주도권도 넘겨주는 셈이다. Cursor, GitHub Copilot, Windsurf 모두 최근 모델 드롭다운을 추가했다. '선택지를 준다'는 명분이지만, 벤더 입장에서 라우팅을 사용자에게 넘기지 않으면 그들이 남는 게 채팅 패널과 자동완성뿐이라는 현실 인식이 더 크다.
비용만 문제가 아니다: 기획 단계 병목도 AI로 뚫린다
AI 비용 최적화와 별개로, 또 다른 개발자는 소프트웨어 딜리버리에서 가장 과소평가된 병목—요구사항 분석—을 AI로 자동화하는 실험을 공개했다. 'Gemma Functional Analyst Copilot'이라는 이름의 이 도구는 Gemma 4(26B MoE 모델)를 백엔드로 삼아, 슬랙 스레드·회의록·반쪽짜리 티켓 같은 날것의 입력을 유저 스토리·인수 조건·QA 테스트 케이스·리스크 매트릭스로 변환한다.
팀 리드 입장에서 이 프로젝트가 흥미로운 이유는 기술 스택이 아니라 워크플로우 포지셔닝 때문이다. 단순한 챗봇이 아니라 분석가·PM·QA 엔지니어가 이미 쓰는 산출물 형식—Jira 티켓, Confluence 문서, 테스트 플랜—을 직접 겨냥했다. AI가 초안을 만들고, 사람이 검토·수정하는 구조다. 여기서 중요한 점: Gemma 4를 선택한 이유가 '불완전한 요구사항에서 추론하고, 알 수 없는 정보를 안다고 가장하지 않는' 특성 때문이라고 명시했다. AI 도구 선택 기준이 마케팅 벤치마크가 아니라 실제 작업 특성에서 출발한 판단이다.
리뷰 파이프라인: AI가 직접 설계한 자동 수정 루프
세 번째 사례는 각도가 다르다. 커리큘럼 제작 AI 에이전트가 반복적인 수정 사이클에 지쳐 직접 리뷰 파이프라인을 설계했다는 이야기다(물론 실제 설계는 사람이 했고, AI 1인칭 서술은 편집 장치다). 핵심 아이디어는 두 가지다.
첫째, Google Drive를 메시지 버스로 쓴다. 에이전트는 HTML 파일을 드라이브 폴더에 쓰고, 리뷰어 UI는 20초마다 폴더를 폴링해 변경을 감지한다. API 연동도, SDK도, 인증 레이어도 없다. 파일을 쓰고 읽는 것이 전부다.
둘째, 문서 단위가 아닌 단락 단위로 플래그를 건다. 리뷰어가 'S2-P1의 용어가 부정확하다'고 표시하면, 워크오더 HTML에 해당 단락 ID와 수정 지침이 담기고, 에이전트는 그 단락만 수정한다. 4,000단어 레슨 전체를 재생성하지 않으니 새로운 오류 유입도 없고, 리뷰 컨텍스트도 최소화된다.
이 아키텍처가 가르쳐주는 교훈은 AI 에이전트 도입보다 리뷰 루프 설계가 더 중요하다는 것이다. 아무리 빠르게 생성해도 수정이 불투명하고 반복적이면 오히려 총 비용이 오른다. 토큰 비용과 리뷰 루프 비용은 같은 문제의 두 얼굴이다.
내일 팀에 적용할 수 있는 세 가지 액션
세 사례를 하나로 묶으면 'AI 워크플로우 비용은 도구 가격이 아니라 설계에서 결정된다'는 결론이 나온다.
1. 토큰 로그를 먼저 켜라. Anthropic 콘솔이든 자체 로깅이든, AI 호출당 입력 토큰·모델·비용을 1주일만 찍어보라. 데이터 없이 최적화는 없다. 팀 전체가 쓰는 Cursor 시트 비용보다 직접 API 호출 비용이 더 빠르게 자라고 있다면, 그 순간이 라우터를 짤 타이밍이다.
2. 인텐트별 모델을 분리하라. rename, 린트 수정, 짧은 설명 요청은 Haiku급으로 충분하다. 멀티파일 리팩토링, 아키텍처 검토는 Sonnet. 장기 계획, 트레이드오프 분석은 Opus나 o3. 200줄 라우터가 부담스럽다면 팀 공유 프롬프트 가이드라인부터 시작해도 된다.
3. 리뷰 루프의 단위를 줄여라. PR 전체, 문서 전체 단위의 AI 리뷰는 재생성 비용이 크다. 단락·함수·청크 단위로 플래그를 달고, AI가 그 범위만 수정하게 설계하면 총 토큰 소비와 리뷰 사이클 모두 줄어든다.
전망: 라우팅을 누가 소유하느냐가 AI 도구 시장을 가른다
앞으로 2분기 안에 AI 도구 구독료를 진지하게 감사하는 팀이 늘어날 것이다. 벤더들은 이미 알고 있다. 모델 드롭다운은 그 방어 전략이다. 하지만 팀이 자체 라우팅을 갖추면, 벤더가 파는 것은 결국 채팅 패널과 인라인 자동완성뿐이고, 그 가격은 $20이 아니라 $5~10 수준이 적정하다는 계산이 나온다.
요구사항 분석 자동화(Gemma 4 Copilot)와 단락 단위 리뷰 루프는 이 맥락에서 같은 방향을 가리킨다. AI 도구의 ROI는 구독 버튼을 누르는 순간이 아니라, 워크플로우 어디에 어떤 모델을 얼마짜리 컨텍스트로 배치하느냐를 팀이 직접 설계할 때 비로소 실현된다. 비용 가시화는 사치가 아니라 AI-First 팀의 기본 인프라다.