지능형 라우팅 — 질문이 싼 AI로 갈까 비싼 AI로 갈까

한 줄로

지능형 라우팅(intelligent model routing) 은 AI 서비스가 사람 질문을 받을 때, 「이 질문은 가벼운 모델로 충분한가, 비싼 최상위 모델이 필요한가」를 보고 어디로 보낼지 고르는 통로다. 식당 웨이터가 「이 주문은 바에서, 저건 주방에서」 나누는 것과 비슷하게 들릴 수 있지만, 비유는 감만 잡게 하고 — 실제로는 비용·속도·품질을 맞추고, 더 아래층에서는 어느 데이터센터·어느 서버 풀로 보낼지까지 겹친다.

잘되면 싸게·빠르게·필요한 만큼 좋은 답을 준다. 잘못되면 답이 이상해지거나, 심하면 아예 서비스가 안 된다.

---

개념이 뭔지 — 질문이 「어느 AI」로 가나

채팅창에 뭘 치든, 그 요청은 곧바로 「하나의 거대한 AI 뇌」로만 가지 않는다. 서비스 뒤에는 보통 여러 등급의 모델이 있다. 가벼운 것, 중간, 최상위. 같은 브랜드 안에서도 「짧은 대화용」과 「아주 긴 문맥용」처럼 설정이 다른 서버 무리(풀) 가 갈라져 있는 경우가 많다.

그 앞에 라우터가 있다. 라우터는 대략 이런 걸 본다.

• 질문이 짧은가, 긴가
• 단순 요약인가, 복잡한 추론·코딩인가
• 지금 그 모델·풀에 여유(용량)가 있는가
• 응답을 빨리 줘야 하는가

그래서 「요약만 해 줘」는 가벼운 쪽으로, 「이 레포 전체 구조를 잡고 리팩터 설계해 줘」는 무거운 쪽으로 보내는 식이다. 사람이 매번 모델을 고르지 않아도, 서비스가 대신 길을 고른다는 게 지능형 라우팅의 핵심이다.

웨이터·교통정리 비유는 「앞에서 나눠 보낸다」는 그림만 잡으면 되고, 메커니즘 자체를 그걸로 대체하진 않는다. 실제로는 규칙·분류기·부하 상태·계약된 모델 옵션 같은 것들이 겹쳐서 「보낼 곳」을 정한다.

---

AI 서비스가 왜 이렇게 처리하나 — 비용·속도·품질

모든 요청을 최상위 모델에만 보내면 어떨까. 품질은 평균적으로 올라갈 수 있다. 그런데 서비스 입장에서는 바로 문제가 생긴다.

비용. 최상위 모델은 요청 한 번이 비싸다. 「오늘 날씨 어때」 수준의 질문까지 전부 최상위로 보내면, 사용자 수가 조금만 늘어도 계산 비용이 감당이 안 된다.

속도. 큰 모델은 같은 조건에서 더 느리거나, 대기열이 길어질 수 있다. 짧은 답인데 10초씩 기다리면 체감이 나쁘다. 가벼운 모델로도 충분한 일은 빠르게 끝내는 편이 낫다.

품질. 품질은 「항상 최상위만」이 정답이 아니다. 쉬운 일에 과한 모델을 쓰면 돈과 시간만 쓰고, 어려운 일에 가벼운 모델을 쓰면 답이 빈약해진다. 라우팅의 목표는 「항상 최고」가 아니라 필요한 만큼의 품질을, 감당 가능한 비용·속도로 맞추는 쪽에 가깝다.

그래서 「모든 요청을 최상위에 안 보낸다」는 게 인색해서가 아니라, 서비스를 계속 돌리려면 저울이 필요해서다. 라우팅이 그 저울을 자동으로 잡는 장치다.

---

데이터센터가 둘 이상인 이유 — 요청이 다른 건물을 거치는 까닭

모델 등급만 나누는 게 아니다. 큰 AI 서비스는 데이터센터(DC)를 여러 곳에 두고, 그 안에서도 서버 풀을 나눈다. 비개발자 기준으로만 풀면 이유가 네 가지 정도다.

1) 장애 대비. 한쪽 건물이 정전·네트워크·하드웨어 문제로 죽어도, 다른 쪽이 받을 수 있게 한다. 「한 건물만」이면 그 건물이 곧 전체 장애다.

2) 용량. GPU·전력이 많이 드는 장비를 한 건물에 무한히 넣을 수 없다. 냉각·전원·공간 한계가 있다. 그래서 여러 지역·여러 건물에 나눠 넣는다.

3) 지연(레이턴시). 사용자와 가까운 쪽에서 받으면 왕복 시간이 줄어든다. 멀리 있는 서버만 쓰면 「생각」 전에 이동 시간부터 길어진다.

4) 모델·설정별 서버 풀이 다름. 같은 이름표의 모델이라도, 짧은 문맥용과 초장문맥용(예: 아주 긴 대화를 한 번에 넣는 설정) 은 메모리·배치·최적화가 달라서 서버 무리가 갈라지는 경우가 있다. 라우터는 「어느 모델」뿐 아니라 「어느 풀」로 보낼지도 고른다.

여기서 층위를 나눠 보면 헷갈림이 줄어든다.

둘은 겹친다. 「어느 AI」를 고르는 일과 「그 AI가 돌아가는 올바른 서버 무리」를 고르는 일은 한 파이프라인 안에서 이어진다. 다만 같은 한 문장으로 뭉개면 나중에 장애 기사를 읽을 때 「모델이 나빠졌다」와 「길을 잘못 갔다」를 구분하기 어렵다.

---

잘못 라우팅되면 어떻게 되나 — 공개된 사례

이론만 있으면 「아 그렇구나」로 끝난다. 실제로 길을 잘못 고른 기록이 공개된 적이 있다. 출처 있는 사실만 적는다. 추측·과장 없음.

Anthropic — 짧은 요청이 초장문맥 서버로

Anthropic이 엔지니어링 포스트모템으로 밝힌 내용이다. 2025년 8~9월, Claude 품질이 들쭉날쭉하다는 보고가 쌓였고, 그중 하나가 컨텍스트 창 라우팅 오류였다.

• 무엇이: Sonnet 4 요청 일부가, 예정된 1M(백만) 토큰 컨텍스트용 서버로 잘못 라우팅됨.
• 얼마나: 초기 약 0.8%. 이후 로드밸런싱 변경이 겹치며, 최악 시간대에는 약 16%까지 영향.
• 누가: 그 기간 Claude Code로 요청한 사람 중 약 30%가 최소 1건 잘못된 서버를 탐.
• 왜 더 아팠나: 라우팅이 sticky(한 번 붙으면 이어지는 요청도 같은 쪽으로 가기 쉬움)라, 한 번 잘못 가면 대화가 같은 잘못된 서버에 이어질 수 있음.
• 타임라인 요약: Aug 5 전후 시작 → Aug 29 로드밸런싱 변경으로 악화 → Sep 4 수정 배포(이후 플랫폼별 롤아웃).

요지는 「모델이 일부러 나빠졌다」가 아니라, 짧은 문맥 요청이 초장문맥용 풀로 들어가 설정이 안 맞아 품질이 깨졌다는 쪽이다. 서버 풀 라우팅이 품질로 바로 이어지는 예시.

OpenAI — 2026-09-03, 라우팅 오류로 일부 불가

2026년 9월 3일, ChatGPT·Codex 일부가 잠시 안 됐던 건이 있다. OpenAI 대변인 코멘트(WIRED 등 보도) 기준으로:

• 원인 표현: routing error(라우팅 오류)
• 시작: 약 7:43am PT
• 조치: 약 8:17am PT 전후 솔루션 적용·모니터링

같은 날 Anthropic·xAI 쪽에도 장애 창이 겹쳤다. 다만 Anthropic은 당시 공개 코멘트에서 원인을 「라우팅」으로 단정하지 않았고, xAI/SpaceX 쪽은 Memphis 컴퓨트 센터 장애를 언급한 바 있다. 세 회사 장애를 한 데이터센터·한 원인으로 묶는 건 공개 기록상 맞지 않는다. OpenAI가 말한 건 자사 라우팅 오류이고, 나머지는 각자 다른 설명(또는 비공개)이다.

라우팅이 「어느 모델로」뿐 아니라 「요청을 살릴 통로 자체」에도 쓰인다는 걸, 이 건이 짧게 보여 준다. 길이 막히면 품질 저하가 아니라 접속 불가까지 간다.

---

정리

• 지능형 라우팅 = 질문을 보고 싼·빠른 모델과 비싼·강한 모델 중 어디로 보낼지 고르는 통로. 더 아래에서는 어느 DC·어느 서버 풀인지도 고른다.
• 모든 요청을 최상위에 안 보내는 이유 = 비용·속도·품질 저울. 서비스를 지속하려면 나눌 수밖에 없다.
• DC가 여럿인 이유 = 장애 대비 · 용량 · 지연 · 설정별 풀 분리.
• 모델 라우팅과 DC/풀 라우팅은 겹치는 층위다. 잘못되면 Anthropic 사례처럼 품질이 깨지거나, OpenAI 사례처럼 일부 서비스가 멈춘다.
• 라우팅이 잘되면 비용·속도가 살고, 잘못되면 품질 저하·장애까지 간다.

이름은 거창하지만 하는 일은 단순하다. 질문을 맞는 길로 보내는 일. 그 길이 모델 등급이기도 하고, 건물·서버 무리이기도 하다.