가장 싼 AI 모델이 선택받지 않는 이유: 100조 토큰 데이터로 본 모델 라우팅
지난 주, 대구에서 열리는 가장 큰 기술 박람회 FIX 2026에 에이아이브(AIEEV)도 참석했습니다. 올해는 ‘AI, 기술을 넘어 일상이 되다’를 주제로 588개 기업이 참여하며 역대 최대 규모로 진행되었는데요. 작년에 이어 올해 다시 참가해, PNP 코리아 스타트업 아레나에서 부스를 운영했습니다. AI 트렌드가 워낙 빠르게 변한다고는 하지만, 현장에서 직접 보니 작년과 올해가 정말 달랐습니다. 작년까지만 해도 AI가 의사결정을 바로 수행하는 형태 보다는 업무 보조 방식의 서비스가 훨씬 비율이 높았는데요. 이제는 AI가 시스템을 실행하고, 운전하고, 컨트롤하는 '결정'의 영역으로 AI 서비스 비율이 더 많아졌습니다. 이렇게 AI의 업무 책임이 높아질 수록, 그 밑단의 인프라, 데이터, 보안의 중요성도 커지고 있는데요. 이번 글에서는 현장에서 체감한 이 변화를 바탕으로 인프라 단에 어떤 요구가 더해지고 있는지, AI 서비스를 만드는 팀에게 도움되는 내용을 관련 연구와 함께 정리드리려고 합니다.
🧭 판단부터 단순 처리까지, 작업에 맞는 모델 선택
현장에서 접한 의사결정 지원 서비스도 그 안의 모든 작업에 같은 수준의 추론이 필요한 것은 아닙니다. 판단에 필요한 자료를 분류하고 요약하는 작업과, 그 자료를 종합해 선택지를 비교하는 작업은 요구하는 성능이 다릅니다. 예를 들어 고객 대응을 돕는 AI라면, 문의 유형을 분류할 때는 처리 비용이 중요하고, 복잡한 불만에 대한 대응 방향을 제안할 때는 답변의 정확성과 맥락 이해가 중요합니다. 고객과 실시간으로 대화하는 단계에서는 응답 속도도 확보해야 합니다. 하나의 서비스 안에서도 작업마다 정확도·비용·속도의 우선순위가 달라집니다. 이 차이에 맞춰 적합한 모델로 요청을 보내는 방식이 모델 라우팅입니다. 아래는 요청의 특성과 운영 조건에 따라 모델을 선택하는 구조를 단순화한 예시입니다.
이 흐름의 앞단에는 라우팅이 있습니다. 요청이 얼마나 복잡한지, 비용을 얼마까지 쓸 수 있는지, 얼마나 빨리 답해야 하는지를 따져 고정확도 모델, 가성비 모델, 저지연 모델 중 어디로 보낼지 정하는 단계입니다. LiteLLM, OpenRouter, Not Diamond 같은 도구가 이 역할을 맡고 있습니다. 기업 현장의 숫자도 같은 방향을 가리킵니다. a16z가 2025년 기업 CIO 100명을 조사한 결과, 5개 이상의 모델을 쓰는 기업은 1년 사이 29%에서 37%로 늘었습니다. 즉 여러 모델을 프로덕션에 함께 배포하는 것이 이제는 시장 표준이 되었고, 그 주된 이유가 벤더 종속 회피보다 작업별 성능 차이에 있다고 볼 수 있습니다.
📊 숫자로 본 변화: 요청은 무거워지고, 가격은 빠르게 움직입니다
왜 지금 라우팅이 화두가 됐는지는 데이터에서 더 분명하게 보입니다. 현재 300개 이상 모델이 등록되어 있는 대표적인 라우팅 플랫폼 OpenRouter의 실제 사용 기록을 분석한 연구를 살펴보시죠.
첫째, 요청 하나가 무거워지고 있습니다. 추론(reasoning) 모델이 처리한 토큰 비중은 2025년 초 미미한 수준에서 1년 만에 50%를 넘었습니다. 요청 1건당 평균 토큰 수도 2023년 말 2,000개 미만에서 2025년 말 5,400개 이상으로 약 3배가 됐고, 코딩 요청은 일반 요청보다 3~4배 길었습니다. 연구진은 이를 여러 단계를 거치며 도구를 호출하는 '에이전트형 추론'이 기본값이 되는 신호로 해석했습니다.
둘째, 선택지가 넓어졌습니다. 오픈소스 모델은 2025년 말 전체 토큰의 약 3분의 1을 처리했습니다. 특히 중국 오픈소스 모델은 2024년 말 주간 비중 1.2%에서 출발해 일부 주에는 30% 가까이까지 올라갔고, 1년 평균 약 13%를 기록했습니다. 한두 개 모델로 모든 작업을 처리하던 구조가 여러 모델을 골라 쓰는 구조로 바뀌고 있다는 뜻입니다.
셋째, 가격이 매우 빠르게 움직입니다. Epoch AI 분석에 따르면 같은 성능을 내는 데 드는 추론 가격은 벤치마크에 따라 연 9배에서 900배까지 떨어졌습니다. 몇 달 전에 짠 최적의 모델 조합이 지금도 최적이라는 보장이 없습니다. 요청마다, 그리고 시점마다 달라지는 최적값을 사람이 계속 따라가기는 어렵습니다. 이 문제는 학계에서 오래전부터 다뤄 왔습니다. 스탠퍼드의 FrugalGPT 연구는 LLM API 요금이 최대 100배까지 차이 난다는 점에 주목했고, 여러 모델을 단계적으로 호출하는 방식으로 GPT-4와 같은 성능을 최대 98% 낮은 비용에 낼 수 있음을 보였습니다. LMSYS의 RouteLLM 연구도 강한 모델과 약한 모델 사이를 라우터가 오가게 해 일부 벤치마크에서 품질 저하 없이 비용을 2배 이상 줄였습니다. 이런 연구가 이제 LiteLLM, OpenRouter, Not Diamond 같은 실제 도구로 시장에 들어와 있는거죠.
👀 우리가 주목한 것: 모델을 고르는 주체가 바뀌고 있습니다
라우팅을 기술 구조로만 보면 효율을 높이는 도구입니다. 시장의 관점에서 보면 의미가 하나 더 있습니다. 모델과 인프라를 고르는 주체가 사람에서 소프트웨어로 옮겨 가고 있다는 점입니다.
예전에는 사람이 여러 벤더를 비교하고, 하나를 골라 계약하고, 한동안 그 선택을 유지했습니다. 이 과정에서는 브랜드 인지도, 영업 관계, 바꾸는 데 드는 수고가 큰 역할을 했습니다. 라우팅이 들어오면 선택은 요청 하나하나마다 일어나고, 판단 기준은 미리 정해 둔 조건이 됩니다. 사람은 조건을 정하고, 고르는 일은 라우터가 맡습니다. 비슷한 구조는 전력 시장에 이미 있습니다. 전력 시장은 어느 회사 발전소인지 따지지 않고, 그 시점의 수요를 맞출 수 있는 발전기를 비용이 낮은 순서대로 가동합니다. 이를 메리트 오더(merit order)라고 부릅니다. 라우터가 하는 일도 같습니다. 조건을 만족하는 선택지 가운데 가장 효율적인 곳을 요청마다 고릅니다.
⚖️ 그런데 라우터는 최저가를 고르지 않습니다
그러면 결국 가장 싼 곳이 이기는 거 아닌가? 라고 생각할 수 있습니다. 하지만 오픈라우터 데이터를 보면, 모델별 가격과 사용량을 비교해 보았을 때 둘의 상관관계는 거의 평평했습니다. 가격을 10% 내려도 사용량은 0.5~0.7% 정도 늘어나는 데 그쳤습니다. 가격만으로는 수요가 크게 움직이지 않는다는 뜻입니다.
대신 시장은 뚜렷하게 나뉘어 있었습니다. 연구진은 모델을 네 유형으로 구분했습니다. 100만 토큰당 약 2달러로 비싸지만 많이 쓰이는 '프리미엄 주력', 0.4달러 미만으로 저렴하면서 많이 쓰이는 '효율형 대량 처리', 수 센트로 매우 싸지만 잘 쓰이지 않는 '롱테일', 약 35달러로 소수의 고위험 작업에만 쓰이는 '프리미엄 특화'입니다. 이 구분은 폐쇄형 모델이 결과의 가치가 큰 작업을, 오픈소스 모델이 저렴한 대량 작업을 맡는 구조와 겹칩니다. 연구진은 이를 두고 LLM이 아직 일반 상품(commodity)처럼 움직이지 않는다고 정리했습니다. 라우터가 하는 일도 결국 이것입니다. 모든 요청을 가장 싼 모델로 보내지 않고, 요청을 몇 개의 칸으로 나눈 뒤 칸마다 조건에 맞는 곳으로 보냅니다. 경쟁은 시장 전체가 아니라 각 칸 안에서 일어납니다.
🧩 칸마다 이기는 조건이 다릅니다
결과의 가치가 큰 칸에서는 품질과 신뢰가 기준입니다. 연구진은 비싼 모델이 높은 사용량을 유지하는 이유를 이렇게 설명합니다. 개발자의 한 시간을 아껴 주는 코드라면 API 비용 몇 달러는 문제가 되지 않는다는 것입니다. 호출량이 많은 칸에서는 가격이 중요합니다. 조사에 참여한 한 기업 리더는 "대부분의 작업에서 이제 모든 모델이 충분히 잘하기 때문에 가격이 훨씬 중요한 요소가 됐다"고 답했습니다. 단순하거나 내부용인 작업은 모델 선택이 사실상 비용으로 결정된다는 것입니다. 다만 연구는 싸기만 해서는 충분하지 않다는 점도 함께 보여 줍니다. 가격이 0에 가까운데도 잘 쓰이지 않는 롱테일 모델이 많았고, 그 이유는 작업에 맞는 성능이 부족하거나 결과가 안정적이지 않아서 개발자가 깊이 연동하기를 망설였기 때문이었습니다. 그래서 연구진은 판단 기준이 토큰당 비용에서 성공한 결과당 비용으로 옮겨 간다고 봤습니다.
간단한 예로 계산해 보면 차이가 보입니다. 호출 단가가 100원이지만 성공률이 60%인 선택지는 성공 1건을 얻는 데 평균 1.67번 호출해야 하므로 약 167원이 듭니다. 호출 단가가 140원이어도 성공률이 95%라면 약 147원으로 더 저렴합니다. 실제 서비스에서는 재시도에 따른 지연과 사람의 검수 시간까지 더해지므로 차이는 더 커집니다.
🔒 반대 방향의 힘: 한 번 맞으면 잘 바꾸지 않습니다
라우터가 요청마다 고른다고 해서 모든 선택이 매번 새로 이뤄지는 것은 아닙니다. 같은 데이터에는 반대 방향의 힘도 함께 나타납니다. State of AI 연구진은 이를 '신데렐라 유리 구두 효과'라고 불렀습니다. 새 모델이 나온 직후 특정 작업에 딱 맞는다고 판단한 초기 사용자는 이후에 들어온 사용자보다 훨씬 오래 그 모델을 계속 썼습니다. 작업과 모델이 한 번 맞물리면 그 위에 워크플로와 습관이 쌓이기 때문입니다. a16z 조사에서도 에이전트 워크플로가 복잡해지면서 모델 교체에 상당한 엔지니어링 시간이 든다는 응답이 나왔습니다. 결국 요청 단위의 선택은 라우터로 넘어가고 있지만 어떤 선택지를 라우터의 후보에 올릴지는 여전히 팀이 워크플로를 설계하는 시점에서 정해집니다. 그 시점에 검증된 선택지로 자리 잡는 것이 이후의 반복 선택으로 이어지게 되죠.
✅ 모델 라우팅을 붙이기 전에 점검할 네 가지
앞에서 본 것처럼 어떤 모델과 인프라를 후보에 올릴지는 워크플로를 설계하는 시점에 정해지고, 한 번 정해지면 잘 바뀌지 않습니다. 그래서 라우팅 도구를 고르기 전에 우리 서비스의 요청부터 들여다보는 것이 순서입니다. LLM API로 AI 서비스를 만들고 있다면 아래 세 가지를 먼저 체크하세요.
요청을 칸으로 나눠 본 적이 있는지. 가장 자주 호출되는 작업이 무엇이고, 그 작업에 지금 어떤 모델을 쓰고 있는지부터 확인해 보세요. 비용은 대개 가장 비싼 작업이 아니라 가장 자주 부르는 작업에서 결정됩니다.
모델을 바꾸는 데 얼마나 걸리는지. 설정 한 줄로 바꿀 수 없다면 라우팅 계층이나 표준 API 도입을 검토할 시점입니다. 가격이 연 단위로 수십 배씩 움직이는 시장에서는 교체 비용이 곧 기회비용입니다.
비용을 무엇 기준으로 재고 있는지. 토큰당 가격만 비교하면 재시도와 검수에 드는 비용이 빠집니다. 성공한 결과당 비용으로 다시 계산해 보면 다른 선택지가 보일 수 있습니다.
🌏 AIEEV가 이 흐름에서 점검하는 것
AIEEV의 Air API와 Air Cloud는 이 지도에서 호출량이 많은 칸을 맡는 인프라에 가깝습니다. 물리적 데이터센터 없이 분산된 GPU를 연결하는 구조라서 비용 면에서는 유리한 출발점에 있습니다. 하지만 위 데이터가 보여 주듯, 이 칸에서도 저렴하다는 것만으로 선택받기는 어렵습니다.
저희도 지난달 직접 칸을 나눠 써 봤습니다. 사내 리서치 에이전트를 만들면서 단계마다 다른 모델을 배정했고, 52,406번 호출하는 데 Air API 비용으로 $2.41이 들었습니다. 요청마다 판단하는 동적 라우팅은 아니었고, 단계별로 모델을 미리 정해 둔 가장 단순한 형태의 배분이었습니다.
결과는 이 글의 내용과 같은 방향이었습니다. 전체 호출의 83%를 차지한 분류 단계는 작은 9B 모델에 맡겼고, 이 단계가 전체 비용의 절반을 차지했습니다. 문장 이해가 더 필요한 추출과 요약 단계에는 35B 모델을 썼습니다. 모든 단계를 9B 모델로 처리했다면 $1.59였겠지만, 품질을 위해 $0.82를 더 쓰는 쪽을 택했습니다. 칸을 나누면 비용은 가장 자주 부르는 칸에서 결정되고, 나머지 칸에서는 품질을 위한 선택이 가능해집니다.
Air API는 OpenAI 호환 API를 제공해 기존 코드에서 API 키와 base URL만 바꾸면 연결할 수 있습니다. 최근에 1년 사이 아시아의 AI 추론 지출 비중이 13%에서 31%로 두 배 이상 늘어났다는 기사를 봤습니다. 결국 이 지역 수요를 가까운 곳에서 안정적으로 처리하려면 저렴한 가격만으로는 부족하고, 응답 지연과 가용성 같은 지표를 꾸준히 지키는 일도 함께 따라와야 합니다. AIEEV도 이 방향으로 서비스를 운영하고 있습니다. 같은 요청에 일정한 품질로 응답하도록 서빙 품질과 요청의 특성에 맞는 모델과 자원을 더 효율적으로 연결할 수 있는 라우팅 기술을 연구하고 있습니다. 성공한 결과당 비용을 낮추는 인프라가 되는 것이 저희의 다음 목표라고 할 수 있습니다.
