역사상 가장 큰 규모의 IPO(기업공개) 3개가 동일한 시기에 몰려오고 있습니다. SpaceX는 6월 12일에 $1.77조의 기업 가치로 상장하며 역사상 최대 규모의 상장을 기록했습니다. Anthropic은 약 9,650억 달러 규모로 비공개 상장 신청을 완료했습니다. OpenAI는 그 뒤를 이어 거의 8,520억 달러 규모로 등장했습니다. 어떤 상장 서류를 열어보더라도, 1년 전만 해도 대부분의 월스트리트(Wall Street)가 알지 못했던 단어 하나를 마주하게 됩니다. SpaceX의 투자설명서에는 "토큰 (token)"이라는 단어가 62번이나 사용되었습니다.

토큰을 둘러싼 모든 담론의 밑바닥에는 단 하나의 베팅이 깔려 있습니다. 이러한 기업 가치 산정은 두 가지 수치가 영원히 상승할 것이라는 가정에 기반합니다. 바로 세상이 얼마나 많은 토큰을 소모하는가, 그리고 _기업들이 그 토큰을 소모할 최고의 모델을 위해 얼마나 많은 비용을 지불할 것인가_입니다. 첫 번째 가정은 안전해 보입니다. 하지만 두 번째 가정은 이미 균열이 가고 있으며, 그 균열은 엔터프라이즈 소프트웨어에서 가장 지루한 비용 관리 습관 때문에 발생하고 있습니다. AI 연구소(Labs)들의 가장 핵심적인 고객들이 이제 모든 작업을 처리 가능한 가장 비싼 모델로만 보내는 것을 멈추는 법을 배우고 있기 때문입니다.

그 습관에는 이제 이름이 생겼습니다. 바로 모델 라우팅 (Model routing)입니다. 이것이 바로 수표를 쓰는 사람들이 투자설명서를 읽기 전에 엔지니어링 조직의 AI 비용 청구서를 먼저 읽어야 하는 이유입니다.

보조금이 끝났다

6월 1일, GitHub는 모든 플랜에 대해 Copilot을 사용량 기반 과금 방식 (usage-based billing)으로 전환했습니다. 이제 모든 에이전트적 (agentic) 작업은 API 요율에 따라 크레딧을 소모합니다. 많은 엔지니어링 리더들이 수년간 고정 비용으로 취급했던 항목이 비용을 천정부지로 치솟게 만드는 숫자가 되었으며, 우리가 최근 방문한 Gartner 서밋에서 그 반발이 가시적으로 나타났습니다.

게다가 기업들은 연간 토큰 예산 전체를 단 몇 달 만에 소진하고 있다고 보고합니다. Uber는 2026년 전체 AI 코딩 예산을 4월까지 단 4개월 만에 모두 써버렸으며, 이후 직원당 월 한도를 1,500달러로 제한했습니다. Uber는 Copilot을 사용하고 있지도 않았습니다. 대신 Claude Code와 Cursor를 실행하고 있었습니다. 핵심은 이것이 구조적인 문제라는 점입니다. 에이전트 워크플로우 (Agentic workflows)는 그 어떤 고정된 인당 예산으로도 감당할 수 없을 만큼 빠르게 토큰을 소모하며, 특정 벤더 (vendor)에 종속될 경우 그들의 다음 가격 정책 변경은 당신에게 직접적인 타격을 줍니다.

당연한 해석은 AI가 너무 비싸졌고 붐 (boom)이 식어가고 있다는 것입니다. 하지만 데이터는 다른 것을 말해줍니다.

650배의 격차

Ramp는 실제 기업 지출 데이터를 기반으로 한 AI 인덱스 (AI Index)를 발표합니다. TechCrunch가 보도한 최신 자료는 이 흐름이 어디로 향하는지를 보여주는 가장 명확한 그림입니다.

Ramp가 "AI-pilled"라고 부르는 상위 1% 기업들은 직원 1인당 월 약 7,500달러를 지출합니다. 이는 1인당 연간 90,000달러에 달하는 금액입니다. 반면 중간값에 해당하는 기업은 약 11.38달러를 지출합니다. 대략 엔터프라이즈 계정(enterprise seat) 하나 정도의 비용입니다.

선두 그룹과 중간 그룹 사이에는 650배 이상의 격차가 존재하며, 상위 지출 기업들이 가속화함에 따라 이 격차는 점점 더 벌어지고 있습니다. 이들의 직원 1인당 지출은 지난달에만 14.1% 성장했습니다. 10개월 전인 2025년 8월, 우리는 개발자당 연간 AI 비용이 100,000달러에 달할 것이라고 예측하는 글을 게시했습니다. 당시에는 무리한 예측처럼 보였으나, Ramp의 수치는 90,000달러를 기록하며 계속 상승하고 있습니다. 우리는 약 1/4 정도 앞서 예측했던 셈입니다.

하지만 실제로 곤경에 처한 이들은 그 곡선의 상단에 있는 기업들이 아닙니다. 바로 자신의 전체 워크플로우 (workflow)를 단일 벤더 (vendor)에 걸고, 그것이 실제로 어떤 비용을 초래하는지 깨닫기 시작한 기업들입니다. Ramp가 언급했듯이, 상위 1%는 다르게 행동합니다. 그들은 여러 프론티어 모델 (frontier models)과 더 저렴한 오픈 웨이트 (open-weight) 액세스를 제공하는 플랫폼들을 혼합하여 사용하며(mix and match) 그 사이를 오갑니다.

상위 1% 기업들은 여러 프론티어 모델과 더 저렴한 오픈 소스 (open source) 모델에 대한 액세스를 제공하는 플랫폼들을 번갈아 선택하며 혼합하여 사용하는 경향이 있습니다.

승자는 자신의 작업을 적절한 모델에 오케스트레이션 (orchestrate)하는 이들이며, 이는 반드시 해당 작업을 수행할 수 있는 가장 비싼 모델과 동일하지는 않습니다.

라우팅 (routing)이 지금 작동하는 이유

정가 (list price)를 무시하면 경제 논리는 간단합니다. 모델이 비싼 이유는 토큰당 요율 (per-token rate)이 높기 때문이 아닙니다. 하나의 작업을 완료하기 위해 얼마나 많은 토큰을 소모하느냐가 비싼 이유이며, 가장 강력한 모델들은 답변에 도달하는 과정에서 더 오래 추론하고 더 많은 내용을 작성하기 때문에 가장 많은 토큰을 소모합니다. 모든 것을 기본적으로 가장 좋은 모델로 설정하면, 프리미엄 요율에 프리미엄 토큰 수까지 곱해진 비용을 지불하게 됩니다. 모델을 작업에 맞게 매칭하면 동일한 작업에 비용이 아주 적게 듭니다.

1년 전에는 함정이 있었습니다. 하위 모델로 라우팅 (routing down)한다는 것은 결과가 더 나빠진다는 것을 의미했기에, 중요한 작업에 이를 실행하는 진지한 기업은 아무도 없었습니다. 하지만 상황이 변했습니다. 오픈 웨이트 (open-weight) 모델들이 실제 에이전틱 코딩 (agentic coding) 분야에서 폐쇄형 프론티어 (closed frontier) 모델과의 격차를 상당 부분 좁혔으며, 우리는 모델을 직접 실행하고 있기 때문에 이를 수치로 증명할 수 있습니다. KiloBench는 각 모델을 Terminal Bench 2.0 상의 Kilo 실제 에이전트 하네스 (agent harness)에 통과시켜 실제 비용과 정확도를 보고합니다.

이것이 실제 사례에서 어떻게 나타나는지 보여드리겠습니다. 동일한 작업에 대해 GLM-5.2와 Kimi K2.7 Code를 비교했을 때, 두 오픈 웨이트 (open-weight) 모델은 계획 (planning) 단계에서 점수가 갈렸습니다. GLM의 계획 점수는 9.0이었고 Kimi는 8.1이었지만, 두 모델 모두 동일한 사양으로부터 거의 동일하게 작동하는 완전한 서비스를 구축했습니다. 여기서 얻을 수 있는 교훈은 빌드 (build) 품질의 대부분이 계획 단계에서 결정된다는 것입니다. 따라서 가장 강력한 모델을 계획에 사용하고, 실제 빌드는 더 저렴한 모델에 맡겨도 동일한 서비스를 출시할 수 있습니다. 이런 방식으로 사용한다면 라우팅 (routing)은 타협이 아닙니다. 각 모델이 최상의 성과를 낼 수 있는 곳에 배치하는 것입니다.

함정은 기본값(default)에 있다

Anthropic의 Claude Fable 5는 가장 깔끔한 경고 사례였습니다. 정확히 말하자면, 그것이 매우 뛰어난 모델이었기 때문에 기본값 (default)으로 사용하기에 위험했습니다. 이 모델은 거의 모든 벤치마크 (benchmark)에서 1위를 차지했고, 가격 또한 입력 토큰 100만 개당 약 10달러, 출력 토큰 100만 개당 50달러로 그에 맞춰 책정되었습니다. 그리고 더 오래 추론 (reasoning)했기 때문에 동일한 작업에 더 많은 토큰을 소모했고, 더 저렴한 모델이 끝낼 수 있는 작업에 대해 예산에서 조용히 돈을 새어나가게 만들었습니다.

그러다 그 모델은 사라졌습니다. 출시 며칠 후, 미국의 수출 통제 지침 (export-control directive)으로 인해 Anthropic은 유료 기업 고객과 Anthropic 자체 직원을 포함한 모든 사용자에 대해 Fable 5와 그 형제 모델인 Mythos 5를 철수시켜야 했습니다. 시장에서 가장 유능한 코딩 모델이 하루 만에 활성화되었다가 다음 날 사라졌고, 워크플로 (workflow)를 해당 모델에 연결해 두었던 팀들은 아무런 구제책이 없었습니다. 서비스를 계속 출시하는 데 있어 그 정도의 성능 한계치 (ceiling)는 필요하지 않았습니다. KiloBench에서 Kimi K2.7 Code, GLM 5.2, MiniMax M3는 모두 최첨단 (frontier) 모델 가격의 극히 일부만으로도 견고한 완료율 (completion rates)을 기록합니다. 가격은 두 배로 뛸 수 있고, 조건은 당신도 모르는 사이에 바뀔 수 있으며, 벤더(vendor)의 누구도 통제할 수 없는 지침에 의해 모델 전체가 취소될 수도 있습니다. 이것이 바로 당신의 워크플로를 단 하나의 모델에 거는 것이 가져다주는 결과입니다.

권력이 구매자에게로 이동하고 있습니다

라우팅 (Routing)이 미국 기업 전반으로 확산됨에 따라, 가격 결정권 (Pricing power)은 프리미엄 AI를 판매하는 기업에서 이를 구매하는 기업으로 재편되고 있습니다. 구매자가 일상적이고 대량인 업무를 더 저렴한 모델로 라우팅함에 따라, 프론티어 랩 (Frontier labs)들은 그들의 최고의 추론 능력이 진정으로 필요한 복잡한 작업, 즉 어려운 작업에서 점점 더 수익을 얻게 됩니다. 그러한 작업은 가장 높은 비용을 지불하는 작업이기도 하므로 매출이 사라지지는 않지만, 매출의 형태가 변하며 그에 따라 레버리지 (Leverage)를 쥐는 주체도 변합니다. 변화하는 것은 일부 기업 가치 평가 (Valuations)가 의존하고 있는 가정, 즉 구매자가 적합성 (Fit)보다는 기본값 (Default)으로 프리미엄 모델을 선택할 것이라는 가정입니다.

단일 모델의 입장에서 이는 이제 일상적인 업무에 충분히 성능이 좋은 저렴한 모델들의 경쟁 속에서, 오직 각 작업의 가치만으로 수익을 창출해야 함을 의미합니다. 습관 때문에 구매자를 붙잡아 둘 요소는 거의 없습니다. 기업들이 하나의 플래그십 (Flagship) 모델에 의존함으로써 프리미엄 AI가 누릴 것이라 가정했던 우위는, 이제 구매자가 모든 작업에 대해 다시 던지는 질문이 됩니다: "여기에는 어떤 모델이 가장 적합한가?"

이것이 바로 라우팅 레이어 (Routing layer)를 모델 레이어 (Model layer)와 분리하여 유지하는 것이 가장 좋은 이유이기도 합니다. 모델 벤더 (Model vendor)가 구축한 라우터는 당연히 자사의 카탈로그를 선호할 것이며, 이미 해당 스택 (Stack)을 사용 중인 팀에게는 그 역할을 잘 수행할 수 있습니다. 하지만 여러 제공업체 사이에서 옵션을 검토하는 구매자에게는, 선호할 자체 모델이 없으며 오직 업무를 어디서든 승리하는 모델에 매칭하는 것만을 유일한 임무로 하는 레이어가 더 유용합니다.

이제 당신은 모델을 직접 선택하지 않습니다

가치는 모델에서 모델 간의 선택을 수행하는 레이어(layer)로 이동하고 있으며, 그 레이어는 신뢰를 얻기 위해 중립적이어야 합니다. 그것이 바로 우리가 Kilo를 구축한 목적입니다. 모든 이가 한두 개의 제공업체로 통합될 것이라는 지배적인 견해가 있을 때, 우리는 반대로 베팅했습니다. 오픈 소스(open source), 사용자 본인의 API 키 사용(bring your own keys), 마진 제로(zero markup), 500개 이상의 옵션에 걸친 진정한 모델 선택권, 그리고 실제 사용 데이터와 공개 벤치마크(public benchmarks)를 따르는 라우팅(routing)을 통해, 특정 모델이 왜 특정 작업에서 승리했는지 확인할 수 있도록 했습니다.

그 누구도 모든 작업의 매 단계마다 서로 다른 가격을 가진 수백 개의 모델을 일일이 비교하고 싶어 하지 않습니다. 따라서 정답은 질문 자체를 사라지게 만드는 레이어입니다. 그 레이어가 바로 Auto Model입니다. Frontier, Balanced, 또는 Free 티어 중 하나를 선택하면, 모든 요청은 작업에 가장 적합한 모델로 전달됩니다. 비용 효율이 필요한 곳에는 저렴한 모델이나 오픈 웨이트(open-weight) 모델을 사용하고, 비용만큼의 가치를 하는 고도의 추론이 필요한 곳에는 Frontier 모델을 사용합니다. 실행 중에는 비용을 보여주며, 사용자가 직접 제어하고 싶을 때는 즉시 물러납니다.

오늘 우리는 라우팅이 세션(session) 자체에 의해 구동되는 Auto Efficient의 출시와 함께 이를 한 단계 더 발전시키고자 합니다. Auto Efficient를 켜면, 귀하의 세션은 먼저 작업의 종류에 따라 분류됩니다. 그런 다음 이 분류를 우리의 공개 벤치마크인 KiloBench 및 PinchBench와 결합하여, Kilo는 해당 특정 세션에서 승리할 모델을 선택합니다. 귀하는 작업마다 모델이나 티어를 선택하는 것이 아닙니다. 세션이 라우터(router)에게 무엇이 필요한지 알려주면, 라우터는 벤치마크가 최선이라고 말하는 모델로 응답합니다. Auto Efficient는 KiloBench에서 기존 Frontier 모델의 완성도를 71% 수준으로 유지하면서 비용은 72% 더 낮게 제공합니다.

앞서 나가는 팀들은 자신의 로드맵을 단일 모델에 거는 것을 멈춘 팀들입니다. 그것이 바로 Auto Efficient가 구축된 이유입니다. 귀하는 더 이상 모델을 선택하지 않습니다. 모델을 선택하는 '방식'을 선택할 뿐입니다.

Auto Efficient 사용해보기