같은 날 세 개의 AI 제공업체가 다운되었을 때, 영향을 받지 않은 아키텍처는 무엇일까

2026년 6월 2일, Claude, ChatGPT, Grok 모두 같은 시간대에 서비스 중단(outage)을 겪었습니다. Anthropic의 상태 페이지에는 10:42 UTC에 수정이 배포되었다고 표시되었으며, 다른 서비스들도 비슷한 시기에 복구되었습니다. 많은 팀들에게 이는 자신들의 제품이 다운되었다는 것을 의미했습니다. 그 이유는 코드 자체의 문제가 아니라, 단일 공급업체의 상태 페이지에 시스템 가동 여부(uptime)를 연결했기 때문입니다.

이를 단순히 '공급업체 문제'로 치부하기 쉽습니다. Anthropic이 다운되었고, OpenAI도 다운되었습니다. 그들에게는 힘든 하루였습니다. 하지만 이러한 틀 자체가 함정이며, 명확히 말할 가치가 있습니다:

LLM 제공업체에 대한 단일 공급업체 의존성은 '어떤 제공업체가 신뢰할 수 있는가'의 문제가 아니라 아키텍처 문제입니다.

모든 주요 모델 제공업체들이 올해 서비스 중단을 겪었습니다. 따라서 대체할 만한 '신뢰할 수 있는 하나'는 존재하지 않습니다. 어제에 대한 답변이

1. 하드코딩된 모델 맵이 아닌, 역량 버킷(Capability-bucket) 기반의 페일오버(Failover). "GPT-5.4가 실패하면 Claude Opus를 시도하라"와 같은 방식은 원치 않습니다. 대신 "이 요청에는 대규모 추론(large reasoning) 모델이 필요합니다. 제가 키를 보유한 모든 제공업체의 대규모 추론 모델 목록은 다음과 같습니다. 이 중 상태가 양호한 모델로 라우팅하세요"와 같은 방식이 필요합니다. 우리는 카탈로그를 역량 계층(capability tiers) — 소형 / 중형 / 대형 / 프런티어(frontier) / 코드(code) / 추론(reasoning) / 롱 컨텍스트(long-context) — 으로 분류하며, 버킷 내에서 페일오버를 수행합니다. 이를 통해 대체 모델이 진정으로 동등한 성능을 보장하며, 장애 발생 시 품질이 소리 없이 저하되는 것을 방지합니다. (이는 몇 개의 모델을 넘어가는 순간 유지보수가 불가능해졌던 $O(N^2)$ 방식의 명시적 모델 간 폴백(fallback) 맵을 대체한 것입니다.)

2. 가라앉는 제공업체로 트래픽을 보내지 않도록 하는 상태 가중치 기반 라우팅(Health-weighted routing). 매 요청마다 죽어있는 제공업체에 재시도하는 페일오버는 한 제공업체의 장애를 귀사의 레이턴시(latency) 급증으로 변질시킬 뿐입니다. 우리는 Redis에 각 제공업체의 최근 성공률을 이동 창(rolling window) 방식으로 기록하고, 이를 기준으로 라우팅 가중치를 조절합니다. 최근 기록이 없는 제공업체는 전체 가중치로 시작하고, 상태가 양호한 제공업체(성공률 $\ge$ 95%)는 전체 가중치를 유지하며, 상태가 악화되는 제공업체(성공률 $\ge$ 50%)는 가중치를 10분의 1로 줄입니다. 그리고 명확히 다운된 제공업체(성공률 < 50%)는 가중치를 0으로 낮추어 복구될 때까지 완전히 건너뜁니다. 시스템은 장애를 향해 달려가는 대신, 장애를 우회하여 라우팅합니다.

3. 기다릴 수 없는 요청을 위한 선택적 헤징(Optional hedging). 레이턴시에 민감한 호출의 경우, 두 제공업체를 병렬로 실행(racing)하여 먼저 응답하는 쪽을 채택하고(패배한 쪽은 취소) 하면, 제공업체의 불안정한 상태를 포함한 p99 테일(tail) 레이턴시를 p50 수준으로 바꿀 수 있습니다. 헤징된 호출에는 약 1.3배의 토큰 비용이 발생하므로, 이는 기본 설정이 아니라 그럴 가치가 있는 트래픽에 대해서만 조절하는 노브(knob)로 사용합니다.

이 중 어느 것도 생소한 기술이 아닙니다. 이는 "게이트웨이(gateway)"라는 단어가 암시해야 하지만 대개는 그렇지 못한, 지루하지만 필수적인 인프라입니다. 상세한 진행 과정을 알고 싶다면, 저희가 구현한 구체적인 사례인 — 20분간의 Anthropic 장애를 우회하는 방법 — 을 확인해 보시기 바랍니다.

솔직한 주의사항

솔직한 주의사항

제가 Prism (위와 같은 기능을 수행하는 OpenAI 호환 게이트웨이)를 구축했으니, 이 내용을 적절히 비판적인 시각으로 받아들여 주십시오. 그리고 한계점에 대해서는 솔직하게 말씀드리겠습니다. 왜냐하면 신뢰성을 과장하는 것이 그 자체로 실패 모드이기 때문입니다:

• 게이트웨이는 마법이 아닙니다. 모든 요청을 게이트웨이를 통해 단일 제공업체로 라우팅한다면, 트래픽 경로에 추가적인 단계(hop)를 넣었을 뿐이며 여전히 단일 장애 지점(single point of failure)을 유지한 것입니다. 이득은 게이트웨이 자체에서 오는 것이 아니라, 실제로 연결해 놓은 여러 제공업체 간의 페일오버입니다.
• 게이트웨이 역시 의존성입니다. 저희 제품은 현재 단일 리전(Mumbai)에 원본 서버를 두고 글로벌 엣지 네트워크로 앞에 배치했습니다. 여러 제공업체 간의 페일오버는 제공업체 장애로부터 보호해 주지만, 우리 자신이나 어떤 게이트웨이도 자체적인 문제로부터 면역이 되게 하지는 못합니다. 자신의 프록시가 100% 가동 시간을 보장한다고 말하는 사람은 무언가를 팔고 있는 것입니다.
• 동등하다는 것이 동일하다는 뜻은 아닙니다. 한 프론티어 모델에서 다른 프론티어 모델로 페일오버를 하는 것은 시스템을 작동하게 유지하지만, 대체 모델은 고유의 특성(quirks)을 가질 것입니다. 다운되는 것보다는 괜찮은 대부분의 프로덕션 트래픽에는 큰 문제가 없지만, 특정 모델에 맞춰 정교하게 조정된 출력을 다룬다면 테스트가 필요합니다.

이는 업계 전체가 배우고 있는 교훈입니다

신뢰성 측면이 이번 주 가장 체감되는 이슈이지만, 비용 측면과도 맥을 같이 합니다. 장애가 발생했던 바로 그날, Microsoft는 Build에서 OpenAI에 대한 의존도를 줄이고 비용을 낮추기 위해 자체 모델들을 공개했습니다. DeepSeek V4는 코딩 벤치마크에서 최고 수준의 성능(near-parity)을 보이면서도 토큰당 $0.86이라는 가격으로 플래그십급 출력을 제공하고 있습니다. 이는 선두 주자들(frontier incumbents)보다 약 28배 저렴한 비용이며, 팀들이 단일 제공업체의 가격 구조에서 벗어나고 싶어 하는 니즈를 정확히 파고들어 시장 점유율을 확보하고 있습니다.

가동 시간과 비용은 같은 이야기를 두 번 반복하는 것과 같습니다. 제품의 성공을 단 하나의 AI 제공업체에 걸지 마십시오. 어제 사건만으로도 신뢰성 측면이 무시하기 어려울 정도로 중요해졌습니다.

그렇다면 실제로 무엇을 해야 할까요?

• 취미 프로젝트이거나 트래픽이 발생하기 전이라면: 아직은 이것이 필요하지 않습니다. 하나의 제공업체(provider)를 직접 호출하고 넘어가십시오. 성급한 장애 조치 (failover)는 그 자체로 복잡성 비용 (complexity tax)을 발생시킵니다.
• 실제 사용자가 있고 실제 비용을 지불하고 있다면: 앱과 제공업체 사이에 진정한 교차 제공업체 (cross-provider), 상태 가중치 기반 (health-weighted), 기능 버킷화 (capability-bucketed) 장애 조치 (failover) 기능을 갖춘 게이트웨이를 배치하십시오. 이를 구매하든 직접 구축하든 하되, 직접 구축한다면 반드시 제대로 구축해야 합니다. 단순한 try/except 방식은 정작 그것이 절실히 필요한 날에 당신을 실망시킬 것입니다.
• 도입을 결정하기 전에 측정해보고 싶다면: Prism은 OpenAI와 호환되므로, Base-URL만 변경하면 바로 테스트해 볼 수 있습니다. 또한 자신의 제공업체 키를 직접 가져와서 사용 (bring your own provider keys)할 수 있으며, 추가 마진은 없습니다. 당신의 키와 비용을 그대로 사용하면서, 그 위에 장애 조치 (failover)와 캐싱 (caching) 계층을 얹는 방식입니다. 이미 비용을 지불하고 있는 제공업체들을 연결하여, 다음 장애 발생 시 그 뒤에서 어떤 느낌인지 확인해 보십시오.

한 제공업체의 불운한 날이 당신의 불운한 날이 되게 하지 마십시오. 또 다른 사건은 반드시 일어날 것입니다.

— Ravi Patel, Ssimplifi의 Prism 창립자