비용이 터진 다음에야 설계를 시작하는 팀이 너무 많다. dev.to에 공개된 한 자율 에이전트 스튜디오의 포스트모텀은 그 대가를 숫자로 보여준다. 1억 3600만 토큰. 산출물은 거의 없었다. 원인은 놀랍도록 단순했다. 에이전트가 타이머로 자기 자신을 재호출하면서, 매 턴마다 800K 토큰짜리 컨텍스트를 캐시 TTL이 만료된 상태로 전체 재전송하고 있었던 것이다. LLM은 무상태(stateless)다. 세션이 길어질수록 입력 토큰은 선형이 아니라 지수적으로 불어난다. 그리고 프런티어 모델 가격으로 그 비용을 고스란히 치른다.
이 사고가 불편한 이유는 예외적 상황이 아니기 때문이다. 같은 dev.to의 또 다른 사례를 보자. 월 €47.80을 AI API에 쓰던 솔로 개발자가 지출 감사 후 €5.00으로 줄였다. 89.5% 절감. 방법은 단순했다. 스팸 분류 같은 단순 작업에 GPT-4o($2.50/M 토큰)를 쓰던 것을 DeepSeek V4 Flash($0.10/M 토큰)로 바꿨을 뿐이다. 코드 한 줄, model 파라미터 하나. 품질 차이는 체감되지 않았다. 문제는 기술이 없어서가 아니었다. '습관'이 기본값이었던 것이다. 프런티어 모델을 디폴트로 놓고, 모든 작업을 동일한 가격으로 처리하는 습관.
개인 수준에서는 습관의 문제지만, 팀 수준에서는 아키텍처의 문제다. geeknews에서 소개된 'AI 코딩 비용 최적화' 논의는 선택지를 세 가지로 정리한다. 자가 호스팅, 오픈소스 API 대여, 프런티어 구독 최적화. 그리고 실전에서 가장 효과적인 방식은 이 셋의 혼합 전략이다. 프런티어 구독은 어려운 판단과 명세 작성에, 오픈소스 API는 기계적·반복적 작업에. '비싼 모델이 좋은 모델'이라는 전제를 버리고, 작업 유형에 따라 모델을 다르게 배정하는 구조를 팀이 명시적으로 설계해야 한다.
그렇다면 라우팅 기준은 어떻게 세울 것인가. 앞서 소개한 에이전트 스튜디오 사례는 네 가지 원칙을 제시한다. 첫째, 프런티어 모델은 '진짜 판단'이 필요한 순간에만, 짧고 깨끗한 세션으로 호출한다. 둘째, 파일 읽기·출력 포매팅·조건 체크 같은 기계적 단계는 DeepSeek·Gemini Flash 같은 저비용 API 모델이나 Ollama 기반 로컬 모델로 라우팅한다. 산업 전반의 보고된 절감 폭은 60~86%, 이 팀의 실제 절감은 '한 자릿수 배율' 수준이었다. 셋째, 저비용 모델의 출력은 결정론적 검증 게이트(테스트 스위트, 린터, 스키마 체크)로 통과 여부를 확인한다. 신뢰를 낮추는 것이 아니라 검증 구조를 설계하는 것이다. 넷째, 에이전트별 하드 캡과 비용 귀속을 구성한다. 136M 토큰 소각이 실시간으로 감지되지 않았던 이유는 단 하나다. 어떤 에이전트가 얼마를 쓰는지 아무도 보고 있지 않았기 때문이다.
솔직히 말하면, 이 라우팅 전략이 기본값으로 제공되지 않는 이유도 짚어야 한다. 에이전트 프레임워크 벤더들은 토큰 사용량이 늘어날수록 수익이 증가하는 구조다. 모델 프로바이더 역시 마찬가지다. 비용을 줄이는 가장 효과적인 레버를 아무도 디폴트로 제공하지 않는 것은 인센티브의 문제다. 이 사실을 인지하는 것 자체가 팀 리드의 역할이다. 도구가 알아서 최적화해줄 거라는 기대를 버리고, 팀이 직접 라우팅 기준을 설계해야 한다.
실행 수준에서 당장 할 수 있는 것은 세 가지다. 우선 지난 한 달 API 호출을 작업 유형별로 분류하라. 분류·추출·단순 리라이트가 전체의 몇 퍼센트를 차지하는지 보면 충격적인 숫자가 나올 것이다. 다음으로, 비중이 높은 기계적 작업부터 저비용 모델로 교체 테스트를 돌려라. OpenRouter 같은 게이트웨이를 쓰면 코드 변경 없이 model 파라미터 하나로 전환이 가능하다. 마지막으로 에이전트별 비용 귀속과 스펜드 캡을 설정하라. 월말 합산 청구서로는 문제를 진단할 수 없다.
모델 라우팅은 비용 절감 기술이 아니다. AI-First 팀이 지속 가능하게 달리기 위한 인프라 설계다. 프런티어 모델만 단독으로 운영하는 팀은 결국 마진을 잃는다. 반대로 라우팅 구조를 명시적으로 설계한 팀은 같은 예산으로 훨씬 높은 밀도의 자동화를 운영할 수 있다. '어떤 모델을 쓸까'가 개발자 개인의 감각이 아니라 팀의 아키텍처 결정으로 다뤄지기 시작할 때, AI-First 전환의 ROI가 실제로 계산 가능해진다.