라우터 또한 하나의 레이어인가 — 아니면 누가 어떤 모델이 답변할지 결정하는가?

이번 시리즈의 열 번째 에세이를 통해, 핵심 주장은 변하지 않았습니다. 즉, 당신이 소유하지 않은 레이어가 당신을 소유하게 된다는 것입니다. 우리는 배포(distribution) (#45), 모델(#46), 정체성(identity) (#47), 접근(access) (#48), 하네스(harness) (#49), 미터(meter) (#50), 런타임(runtime) (#51), 데이터(#52), 책임성(accountability) (#53), 그리고 레일(#54)이라는 이름을 붙여왔습니다. 오늘 다룰 레이어는 당신과 모든 모델 사이에 조용히 자리 잡고 있는 것입니다.

라우터(The router). 요청마다 어떤 모델이 실제로 답변할지 결정하는 그 무언가입니다.

이 글을 쓰게 된 계기

새로운 프런티어 모델인 StepFun의 'Step 5 Preview'라는 1M 컨텍스트 혼합 전문가(mixture-of-experts)가 이번 주 OpenRouter에 등장했습니다 (HN에서 84점). 같은 주에는 'DeepSeek 4.1 Flash' 스레드가 메인 페이지 상단을 장식하기도 했습니다 (370점). 두 개의 다른 연구소, 두 개의 다른 모델 세대가 동일한 추상화 속으로 발표되었습니다. 즉, 개발자가 특정 공급업체의 어떤 모델을 사용해야 할지 확정하지 않고도 '모델'을 가리킬 수 있게 해주는 라우터입니다.

이러한 편리함은 실재합니다. 하지만 이것 또한 하나의 레이어입니다.

왜 라우터가 그 자체로 하나의 레이어인가

수년 동안 모델 자체가 공급업체와의 관계였습니다. 당신은 OpenAI나 Anthropic 또는 오픈 웨이트(open-weights) 제공업체를 선택했고, 당신의 통합 방식은 그 선택에 의해 — 종종 갇히게 되면서 — 형성되었습니다. 라우터는 이 결속을 끊습니다. 이제 당신은 게이트웨이로 작성하고, 기능을 명명하며, 게이트웨이가 업스트림(upstream)을 선택하도록 맡깁니다. 이를 통해 장애 조치(failover), 가격 차익 거래(price arbitrage), 그리고 재작성 없이 제품의 두뇌를 교체할 수 있는 능력을 얻습니다.

또한 당신은 스택에서 가장 중요한 결정을 제3자에게 위임하게 됩니다.

라우터가 결정합니다:

• 사용자가 어떤 모델 품질을 얻게 될지. 'GPT-6급'이나 '프론티어(frontier)' 같은 것은 마케팅 라벨일 뿐, 명세가 아닙니다. 게이트웨이는 요청을 오늘날 동등하다고 판단하는 어떤 것으로 매핑합니다. 내일은 더 저렴한 모델로 대체될 수 있고, 여러분의 제품은 조용히 멍청해집니다. 버전 업데이트도 없고, 변경 로그도 없고, 경고도 없습니다.
• 어떤 관할권이 데이터를 처리할지. 프롬프트를 국가가 아닌 _라우터(router)_에 보냅니다. 실제로 데이터가 어디에 도착하는지는 라우터의 업스트림(upstream)과 폴백(fallback) 로직에 달려 있습니다. 여러분의 데이터 주권 이야기는 이제 다른 사람의 라우팅 테이블이 됩니다.
• 무엇을 지불하고, 어떻게. 라우팅은 가격 차익 거래(price arbitrage)가 발생하는 곳입니다. 누군가가 모델의 리스트 가격과 여러분에게 청구되는 금액 사이의 스프레드(spread)를 가로챕니다. 여러분은 하나의 숫자만 보지만, 마진은 눈에 보이지 않습니다.
• 새벽 3시에 작동할지 여부. 페일오버(failover)는 라우터의 판매 포인트이자 단일 실패 지점입니다. 게이트웨이 자체가 저하되면, 그 뒤에 있는 모든 모델이 함께 다운되고, 여러분은 실제 연구소 중 어느 곳과도 직접적인 레버를 가질 수 없습니다.

핵심: 추상화처럼 보이지만 의존성처럼 작동한다

가장 위험한 레이어는 스스로를 알리지 않습니다. 모델 변경은 자신을 드러냅니다(프롬프트가 깨집니다). 런타임 변경은 자신을 드러냅니다(컨테이너가 부팅되지 않습니다). _라우터(router)_는 정상성의 외관 속에 실패합니다: 호출은 200으로 반환되고, 응답은 그럴듯해 보이지만, 품질 저하, 거주지 관련 놀라움, 또는 청구서에 대해서는 나중에야 알아차리게 됩니다.

그리고 여기에는 2차적인 함정이 있습니다. 라우터가 공급업체들을 더 잘 추상화할수록, 그 공급업체들은 여러분에게 더욱 동일해집니다. 이것이 바로 라우터가 이들을 상호 교환 가능한 것으로 취급할 수 있는 조건이며, 여러분은 그때 차이를 알아차릴 수 없습니다.

실제로 무엇을 해야 하는지

• 모델을 명시하고, 단순히 기능을 언급하지 마십시오. 품질이 중요한 경우 특정 모델 버전을 지정하고, '자동 라우팅(auto-routing)'은 기본 설정이 아닌 저가형 티어의 최적화 기능으로 취급해야 합니다.
• 직접적인 폴백(fallback) 방안을 유지하십시오. 제품 전체 흐름이 하나의 게이트웨이를 통과한다면, 추가 단계가 필요한 단일 공급업체에 의존하게 됩니다. 최소한 하나 이상의 상위 시스템(upstream)에 직접 접근하는 방법을 알아야 합니다.
• 실제로 답변한 내용을 기록하십시오. 모든 응답에는 어떤 모델과 어느 지역에서 서비스되었는지 명시되어야 합니다. 나중에 이를 재구성할 수 없다면, 품질 편차나 데이터 거주지(residency)를 감사할 수 없습니다.
• 추상화에 가격을 책정하십시오. 라우터의 마진은 원가(COGS)의 일부입니다. 이는 나중에 발견한 세금이 아니라 비용처럼 모델링해야 합니다.
• 라우팅 정책을 계약서로 읽으십시오. 이 정책은 품질, 위치, 비용, 가동 시간 — 사람들이 보통 자신이 통제한다고 생각하는 네 가지 요소 — 를 결정합니다. 하지만 사람들은 그렇지 못합니다.

한 줄 요약 버전

라우터는 당신과 다른 모든 것 사이의 공간에 임대하는 레이어입니다. 이 라우터가 사용자가 느끼는 모델 품질, 데이터가 접촉하는 관할권, 지불하는 마진, 그리고 시스템이 작동하지 않을 때도 작동 여부를 결정합니다. 편리함은 판매 제안이며, 의존성이 비즈니스 모델입니다. 라우터를 사용하되, 핸들을 놓지 마십시오. 왜냐하면 모델을 선택하는 레이어가 당신 제품의 두뇌를 선택하는 레이어이기 때문입니다.

분배(Distribution), 모델(Model), 신원(Identity), 접근(Access), 하네스(Harness), 측정기(Meter), 런타임(Runtime), 데이터(Data), 책임성(Accountability), 레일(Rail) — 그리고 그 사이를 관통하는 라우터. 이것을 명명하거나, 그것이 당신의 다음 장애 시간을 명명할 것입니다.

시리즈: 분배 → 모델 → 신원 → 접근 → 하네스 → 측정기 → 런타임 → 데이터 → 책임성 → 결제 레일(Payment Rail) → 라우터(Router). 당신이 소유하지 않은 모든 레이어는 당신이 책임을 져야 하는 레이어가 됩니다.