4개 팀이 같은 앱을 각자 다른 AI 모델로 만들었습니다. 과제마다 승자가 달랐습니다.

이건 실험 결과가 아닙니다. AI 업계가 조용히 받아들이기 시작한 현실입니다.

모델 전쟁의 언어는 여전히 벤치마크입니다. SWE-bench 몇 점, MMLU 몇 점. 하지만 에이전트를 프로덕션에서 운영하는 팀에게 그 숫자는 점점 부차적인 정보가 되고 있습니다.

PM이 실제로 봐야 하는 숫자는 달라졌습니다. 1달러당 처리 가능한 작업 수, 달리 말하면 성능 대비 비용입니다.

벤치마크 1위 모델이 최선이라는 착각

karpathy는 이렇게 표현했습니다. “AI 능력 격차는 최신 모델 × 사용 티어의 함수다.” 무료 모델로 1년 전 경험을 일반화한 사용자는 최신 유료 에이전트 모델의 실제 능력을 계속 과소평가한다는 뜻입니다.

반대 방향의 착각도 있습니다. 프론티어 모델을 쓰면 무조건 낫다는 믿음입니다.

동일 앱 빌드 실험 결과는 이 믿음을 정면으로 반박합니다. UI 생성에서는 한 모델이 앞서고, 도구 호출에서는 다른 모델이 50배 저렴하면서 성능이 동등합니다. 장시간 코딩 에이전트 워크플로우에서는 Claude Opus 4.7의 SWE-bench 87.6% 우위가 유효하지만, 단순 반복 실행에서는 GLM-5.2 같은 모델이 비용 1/3에 동급 결과를 냅니다.

“가장 좋은 모델 하나”는 존재하지 않습니다. 작업 유형에 따라 최적 모델이 바뀝니다.

비용 격차는 이미 2~6배

2026년 기준, 동급 성능을 주장하는 모델 사이의 토큰 비용 차이는 무시할 수준이 아닙니다.

Gemini 3.1 Pro는 13개 주요 벤치마크에서 1위를 기록하면서 토큰당 비용은 경쟁 프론티어 모델의 2/3 수준에 있습니다. Google의 TurboQuant 기술은 KV-Cache 압축으로 동일 출력 품질 기준 메모리 비용을 1/6로 줄이는 데 성공했습니다.

벤치마크 점수가 비슷하다면, 비용 차이가 실질 경쟁력입니다. 월 1억 원 추론 비용 팀과 2천만 원 팀이 같은 제품 품질을 낸다면, 그 격차는 운영 마진과 가격 경쟁력에서 그대로 나타납니다.

한국 기업 중 사이냅소프트는 OCR 솔루션에 벡터 양자화를 적용해 LLM 비용을 70% 절감했습니다. 기술 구현이 아니라 라우팅과 최적화 설계의 문제였습니다.

Anthropic이 자기 제품에서 보여준 답

Anthropic이 자체 ‘Advisor’ 서비스 설계에서 선택한 방식을 보면 방향이 보입니다.

복잡한 판단이 필요한 단계는 Opus, 반복 실행 단계는 저비용 모델. 동일 프로바이더 안에서도 모델을 작업 유형별로 나눕니다.

이건 단순한 비용 절감이 아닙니다. 고비용 추론 모델을 전체 파이프라인에 투입하면 오히려 안정성이 떨어집니다. 고급 추론 모델은 짧고 반복적인 실행 작업에서 응답 품질이 들쭉날쭉해지는 경향이 있습니다. 작업 성격과 모델의 설계 목적이 맞지 않기 때문입니다.

Anthropic이 직접 이 설계를 제품에 적용했다는 점이 중요합니다. 이것은 라우팅이 “고급 최적화”가 아니라 기본 운영 설계임을 빅테크 수준에서 확인한 신호입니다.

공급자 단일 의존의 두 가지 리스크

단일 프로바이더에만 의존하는 팀은 지금 두 가지 리스크를 동시에 안고 있습니다.

첫째는 가격 리스크입니다. 프로바이더가 요금제를 바꾸거나 가격을 올릴 때 대안이 없으면 그대로 받아야 합니다. OpenAI Codex가 $100 전용 요금제를 신설하면서 Plus($20)와 Pro($200) 사이 공백을 채운 것처럼, 가격 구조는 언제든 달라집니다.

둘째는 운영 리스크입니다. Claude Code v2.1.116에서 Anthropic이 공개한 사례처럼, 한 모델에 품질 회귀(regression)가 생기면 단일 프로바이더 팀은 전체 파이프라인이 같이 내려갑니다. Anthropic은 당시 1개월간의 코드 생성 품질 저하 원인을 투명하게 공개하고 빠르게 복구했지만, 그 기간 동안 대안 라우팅이 없는 팀의 운영 중단은 피할 수 없었습니다.

멀티 프로바이더 라우팅은 이제 선택이 아닌 운영 기본값에 가까워졌습니다.

PM이 설계해야 하는 것

지금 팀에서 모든 프롬프트를 단일 모델에 보내고 있다면, 이유가 두 가지 중 하나일 겁니다. 라우팅 설계 자체가 없거나, “최고 모델을 쓰면 된다”는 가정이 있거나.

두 번째 가정이 더 위험합니다. 문제가 있다는 걸 모르기 때문입니다.

PM의 역할은 “어떤 모델이 제일 좋냐”를 결정하는 게 아닙니다. 어떤 작업에 어떤 모델을 배치할지 설계하고, 그 배치가 비용과 성능을 동시에 최적화하는지 측정하는 것입니다.

라우팅 설계는 세 단계로 시작할 수 있습니다.

1단계 — 작업 분류: 파이프라인의 각 단계를 “복잡한 판단”과 “반복 실행”으로 나눕니다. 법률 검토나 설계 결정은 전자, 요약·포맷 변환·간단한 분류는 후자입니다.

2단계 — 기준 정의: 각 카테고리에 필요한 성능 기준을 정합니다. 응답 속도, 정확도 기준, 비용 허용치. 이 세 축이 없으면 “어떤 모델이 낫다”는 판단이 감에 의존하게 됩니다.

3단계 — 달러당 성능 점수 비교: 기준에 맞는 후보 모델을 골라 실제 워크로드로 성능 대비 비용을 비교합니다. 그 다음, fallback 경로를 설정합니다. 메인 모델이 응답하지 않을 때 무엇으로 넘어갈지 사전에 결정해야 합니다.

이 설계 없이 “더 나은 모델”을 계속 찾는 건 연료가 새는 엔진을 고치지 않고 고급 휘발유만 넣는 것입니다.

당신의 팀에서 지금 가장 비용이 많이 나가는 파이프라인 단계가 어디인지 알고 있나요? 거기서 라우팅 설계가 시작됩니다.