AI 기반 기능을 출시한 경험이 있는 개발자라면 누구나 그 순간을 알고 있습니다. 로그에는 500 에러나 타임아웃(timeout)이 가득 차고, 사용자들은 장애를 보고하며, 당신의 첫 본능은 새 탭을 열고 "is OpenAI down"을 입력하는 것입니다. 상태 페이지(status page)는 초록색으로 표시됩니다. 잠시 그 화면을 응시하다가, 당신은 트위터(Twitter)를 확인하러 갑니다.

"무언가 분명히 잘못되었다"는 느낌과 "상태 페이지가 무언가 잘못되었음을 인정하는" 시점 사이의 그 간극이 바로 실제 장애(incident)가 발생하는 지점이며, 이것이 우리가 Prismix를 구축하게 된 동기입니다.

데이터 수집 방법

지난 6주 동안 Prismix는 5분마다 77개의 AI 서비스를 대상으로 공식 상태 페이지를 폴링(polling)하고 직접적인 API 상태 프로브(health probes)를 실행해 왔습니다. 여기에는 OpenAI, Anthropic, Gemini, Mistral, Groq, Perplexity, GitHub Copilot, DeepSeek와 같은 명백한 서비스들은 물론, ElevenLabs, Runway, Replicate, Stability AI 등 급증하고 있는 이미지, 오디오, 비디오 생성 서비스 수십 개가 포함됩니다.

각 프로브는 응답 지연 시간(latency), HTTP 상태 코드(status codes), 그리고 공식 상태 페이지가 우리가 실제로 보고 있는 상황과 일치하는지 여부를 기록합니다. 그 결과, 작고 사소한 장애부터 중대한 장애까지 아우르는 서비스당 수천 번의 폴링 사이클을 포함하는 데이터셋이 구축되었습니다.

우리가 발견한 내용은 다음과 같습니다.

OpenAI는 장애 발생 건수에서 앞서고, Anthropic은 해결 속도에서 앞선다

단순 장애 발생 횟수 측면에서, OpenAI는 우리 데이터셋 내의 다른 어떤 제공업체보다 더 많은 상태 이벤트(status events)를 기록했습니다. 이것은 그들의 신뢰성에 대한 비판이 아니라, 서비스 범위(surface area)의 함수입니다. OpenAI는 가장 많은 제품을 운영하고, 가장 넓은 API 범위를 가지고 있으며, 가장 많은 트래픽을 처리합니다. 움직이는 부품이 많을수록 무언가 성능 저하(degraded)를 보고할 기회도 많아집니다.

흥미로운 점은 Anthropic과의 대조입니다. Anthropic은 건수 기준으로는 더 적은 장애(incident)를 기록하지만, 눈에 띄는 패턴은 **해결 시간 (resolution time)**입니다. Anthropic이 "조사 중 (investigating)" 상태를 게시하면, 카테고리 평균보다 더 빠르게 "해결됨 (resolved)" 상태로 전환되는 경향이 있습니다. 이것이 영향 범위 (blast radius)가 작기 때문인지, 더 긴밀한 장애 대응 매뉴얼 (runbooks) 때문인지, 아니면 단순히 가동 중인 서비스가 적기 때문인지는 알 수 없으나, 결과는 동일합니다. 즉, 평균 해결 시간 (mean time to resolution)이 더 짧다는 것입니다.

"조사 중" 단계는 개발자들이 패닉에 빠지는 구간이지만 — 보통 빠르게 종료됩니다

상태 페이지 (status page)가 녹색에서 "조사 중 (investigating)"으로 바뀌면, 개발자들은 트리아지 (triage, 우선순위 결정) 모드에 돌입합니다. 다른 모델로 폴백 (fallback)해야 할까요? 요청을 큐 (queue)에 쌓아두고 기다려야 할까요? 담당자에게 호출 (page)을 해야 할까요?

데이터에 따르면: 80% 이상의 사례에서 "조사 중 (investigating)" → "해결됨 (resolved)" 단계가 2시간 이내에 완료됩니다. 대부분의 장애는 이보다 짧습니다. 수 시간 동안 지속되는 치명적인 중단 (outage)도 존재하며 — 실제로 여러 건을 기록했습니다 — 하지만 이는 패턴이 아닌 예외적인 경우입니다.

실질적인 시사점: 처음 30~60분 동안 지수 백오프 (exponential backoff)를 적용한 재시도 루프 (retry loop)를 구성하면, 대부분의 장애를 최종 사용자에게 투명하게(영향 없이) 처리할 수 있습니다. 전체 서킷 브레이커 (circuit-breaker) 로직과 교차 제공자 라우팅 (cross-provider routing)은 중앙값 (median)이 아닌 꼬리 부분 (tail, 극단적 사례)을 위해 중요합니다.

상태 페이지는 현실보다 10~20분 뒤처집니다 — 일관되게

이것은 우리를 가장 놀라게 하지 않았지만, 개발자들이 명시적으로 들어야 할 가장 중요한 발견입니다: 공식 상태 페이지는 체계적으로 늦습니다.

우리는 API 프로브 (probe)가 해당 상태 페이지에서 무언가를 인정하기 훨씬 전부터 높은 에러율, 저하된 지연 시간 (latency), 또는 429 폭풍 (429 storms)을 보여준 수십 건의 장애를 기록했습니다. 전형적인 지연 시간은 10~20분입니다. 어떤 경우에는 이보다 더 길기도 합니다.

공식적인 인정이 있기 전에 API가 에러를 반환하거나 현저히 느려지는 "조용한 성능 저하 (silent degradation)"는 예외적인 사례가 아니라 기본 장애 패턴입니다. 만약 당신의 알림 (alerting)이 오로지 상태 페이지 웹훅 (webhook)에만 의존한다면, 설계 구조상 10~20분의 사각지대를 갖게 됩니다.

가장 안정적인 서비스는 당신을 놀라게 할 수도 있습니다

우리 데이터셋에서 장애 발생 건수가 가장 적었던 서비스는 Groq, Mistral, 그리고 Cerebras입니다. 이 세 곳 모두 비교적 최근에 등장한 업체들로, API 표면(API surfaces)을 좁게 운영하며 다중 제품 생태계를 운영하기보다는 거의 전적으로 추론 (inference)에만 집중하고 있습니다. 통합된 기능이 적을수록 장애 영역 (failure domains)도 적어집니다.

이것이 영구적인 특성은 아닙니다. 이러한 플랫폼들이 성장함에 따라 복잡성도 뒤따르는 경향이 있기 때문입니다. 하지만 현재로서 워크로드의 가용 시간 (uptime)이 최우선 순위라면, 규모가 작은 추론 제공업체들이 기대 이상의 성능을 보여줍니다.

OpenAI와 Anthropic의 장애는 상관관계가 없습니다

시스템 설계 측면에서 매우 유용한 발견 중 하나는 OpenAI의 장애 발생 시간대와 Anthropic의 장애 발생 시간대가 유의미하게 겹치지 않는다는 점입니다. 이들의 인프라, 확장 이벤트 (scaling events), 그리고 장애 모드 (failure modes)는 대체로 독립적입니다.

이는 여러 제공업체에 걸쳐 라우팅 (routing)을 해야 한다는 실증적인 근거가 됩니다. 만약 OpenAI 호출에서 동등한 Anthropic 호출로 넘어가는 폴백 (fallback) 경로를 구축해 두었다면, 두 장애 확률은 더해지는 것이 아니라 곱해집니다. 이러한 중복성 (redundancy)은 이론적인 것이 아니라 실재하는 것입니다.

이것이 구축 방식에 의미하는 바

6주간의 데이터를 통해 얻은 몇 가지 실질적인 결론은 다음과 같습니다:

성능 저하 상태 (degraded state)를 고려하여 설계하십시오. 대부분의 AI API 장애는 완전한 블랙아웃이 아니라 지연 시간 (latency) 증가나 에러율 상승과 같은 부분적인 형태로 나타납니다. 타임아웃을 포함한 스트리밍 (Streaming), 캐시된 응답으로의 우아한 폴백 (graceful fallbacks), 그리고 사용자에게 보여줄 "현재 AI 응답이 느립니다"와 같은 메시지 처리는 API가 단순히 작동하거나 작동하지 않는 이진법적 상태라고 가정하는 것보다 훨씬 효과적입니다.

상태 페이지 (status page)를 실시간 신호로 사용하지 마십시오. 상태 페이지는 장애 상황 공지나 사후 분석 (post-mortems) 용도로 사용하십시오. 실시간 탐지를 위해서는 자체적인 프로브 (probes)가 필요합니다.

독립적인 장애 영역 (failure domains) 간에 라우팅하십시오. OpenAI와 Anthropic의 상관관계 데이터가 이를 직접적으로 뒷받침합니다. 단순히 모델의 능력만을 기준으로 제공업체를 상호 교체 가능한 것으로 취급하는 것은 신뢰성 (reliability) 차원을 놓치는 것입니다.

자체 모니터링에 상태 확인 기능을 추가하십시오

Prismix는 API 키가 필요 없는 공개 REST 엔드포인트를 제공합니다:

GET https://prismix.dev/api/v1/statuses

이 엔드포인트는 단일 JSON 응답으로 77개 서비스 전체의 현재 상태를 반환합니다. 이를 기존의 헬스 체크 (health check) 파이프라인, Grafana 대시보드, 또는 온콜 런북 (on-call runbook)에 바로 적용해 보세요.

대시보드 자체는 **prismix.dev**에서 확인할 수 있으며, 계정 생성 없이 무료로 이용 가능합니다. 만약 AI API를 기반으로 서비스를 구축하고 있으면서 의존하고 있는 업스트림 (upstream) 서비스들을 모니터링하고 있지 않다면, 이것이 가장 적은 노력으로 시작할 수 있는 방법입니다.

데이터셋이 확장됨에 따라 새로운 조사 결과들을 계속해서 게시할 예정입니다. 6주는 시작일 뿐이며, 6개월이 되면 더욱 흥미로운 결과가 나올 것입니다.