// 01
측정 대상
AIWatch는 LLM API 16개, 코딩 에이전트 6개, 음성 3개, 추론·인프라 8개, 관측 3개, 영상 2개, 이미지 2개, AI 앱 4개 — 총 44개 AI 서비스를 최대 5분 간격으로 폴링합니다. 모든 시각은 UTC 기준입니다.
데이터 출처
상태·인시던트·uptime 데이터는 각 서비스의 공식 상태 페이지에서 수집됩니다. 제공사가 공개한 데이터가 1차 출처이며, 없는 값을 자체 추정으로 채우지 않습니다 — 공식 uptime이 없는 경우의 처리는 아래 Uptime 섹션에서 다룹니다.
- Atlassian Statuspage — 다수의 주요 제공사
- incident.io — 컴포넌트 단위 인시던트 + 영향도
- Google Cloud Status · AI Studio Status — Gemini API (Google Cloud 상태 + AI Studio 컴포넌트 인시던트 병합)
- Better Stack, Instatus, OnlineOrNot — 그 외 상태 페이지 플랫폼 (인시던트 RSS + 가동률 JSON)
- Flashduty — DeepSeek 상태 피드 정규화 (status.deepseek.com)
- AWS Health Dashboard — Amazon Bedrock — 공개 이벤트 JSON API(인시던트 start/end), 가동률 API 없음
- RSS incident feeds — Azure Status(Azure OpenAI) · xAI(status.x.ai) — 가동률 API 없이 인시던트 RSS만 수집
- Direct RTT probes — 33개 AI 서비스의 엔드포인트 직접 측정
보안 이슈 모니터링
상태·신뢰도 측정과는 별개로, AI 스택에 영향을 주는 보안 이슈도 함께 추적해 월간 리포트에 집계합니다. 이 데이터는 AIWatch Score나 인시던트 집계에는 반영되지 않습니다.
- OSV.dev — SDK 취약점 (PyPI · npm 24개 추적 패키지), GitHub Advisories로 상세 보강
- NVD — 자사 제품 CVE (Claude Code · Codex · ChatGPT 앱 등)
- Hacker News — AI 서비스 관련 보안 뉴스 (Algolia 검색 API)
// 02
상태 결정
서비스별 상태는 계층화된 우선순위 체인으로 결정되며, 화면에는 Operational · Partial · Degraded · Down 로 표기됩니다. 규칙은 위에서부터 순서대로 확인하며, 처음 일치하는 규칙에서 상태가 결정됩니다.
Partial은 다중 컴포넌트 서비스(Better Stack 기반 — Together · Fireworks · HuggingFace · Modal · Luma)에서 전체 서비스는 정상이지만 일부 컴포넌트(예: 특정 모델)만 영향받은 중간 상태입니다. 서비스 전체를 'degraded'로 격상시키지는 않되, 영향받은 컴포넌트의 실제 장애는 uptime · 인시던트 집계를 통해 AIWatch Score · 랭킹에 그대로 반영됩니다.
규칙의 전체 순서와 각 규칙의 근거는 오픈소스 저장소의 status-determination 문서에 공개되어 있습니다.
// 03
Uptime
Uptime은 제공사가 공개한 장애 기록을 AIWatch가 직접 30일치로 계산합니다. 제공사가 자기 페이지에 표시하는 값을 그대로 쓰지는 않습니다 — 그 값은 페이지마다 집계 기간(30·60·90일)이 다르고, 어떤 상태를 다운타임으로 볼지도 달라서 서비스끼리 비교할 수 없기 때문입니다. 모든 서비스가 같은 30일, 같은 가중 방식입니다.
왜 30일로 맞추나. 제공사마다 uptime 집계 기간이 30일·60일·90일로 제각각입니다. 기간이 다르면 서비스끼리 비교할 수 없으니, AIWatch가 30일로 통일해 계산합니다. AIWatch Score의 나머지 항목(인시던트·복구)도 같은 30일치로 계산합니다.
- Official — 제공사 상태 페이지가 공개한 일별 장애 기록·장애 구간으로 AIWatch가 최근 30일치를 직접 계산합니다. 우리 숫자가 제공사 페이지의 숫자와 다를 수 있습니다. 감추지 않습니다 — 제공사가 발표한 값이 우리 계산과 다르면 서비스 상세 페이지에 그 값을 집계 기간과 함께 나란히 보여드립니다. 상태 페이지에 uptime %를 공개하지 않는 서비스(ElevenLabs · Replicate · Stability)는 비교할 값이 없어 우리 계산값만 보여줍니다. 제공사 기록이 30일에 못 미치면(상태 페이지를 옮긴 경우 등) 실제 며칠치인지 밝힙니다.
- Platform — 같은 30일, 같은 가중 방식으로 계산하지만 근거가 다릅니다 (Together · Fireworks · HuggingFace · Modal · Luma · Helicone). 이 6개 서비스의 상태 페이지는 Better Stack이 운영하며, 장애 기록이 제공사의 인시던트 선언이 아니라 Better Stack 모니터가 직접 측정한 다운타임입니다. 제공사가 보증하는 SLA가 아니라는 뜻이라 라벨을 구분합니다.
장애 시간 가중 집계: 다운타임은 인시던트 건수가 아니라 영향받은 시간으로 셉니다. 심각도에 따라 전면 장애는 1.0, 부분 장애·성능 저하는 0.3으로 가중하고, 정보성 공지와 사전 공지된 정기 점검은 빼줍니다(미리 알린 점검까지 감점할 이유는 없습니다). uptime과 Score가 같은 방식을 씁니다. 모든 서비스에 같은 기간과 같은 기준을 적용하다 보니, 우리 숫자가 제공사 페이지의 숫자와 다를 수 있습니다.
인시던트 건수와 uptime은 서로 다를 수 있습니다. 일부 제공사는 짧은 성능 저하를 가용성 기록에는 남기되 별도 인시던트로는 발행하지 않습니다(예: fal · Hugging Face의 수분~1시간 degraded). uptime은 그 실제 다운타임 시간을 반영하므로, "최근 인시던트 없음"인데도 uptime이 100%보다 낮게 나올 수 있습니다 — 제공사가 공식 발표하지 않았을 뿐 장애는 실제로 있었기 때문입니다.
아래 서비스는 상태 페이지에 계산할 장애 기록 자체가 없습니다. 임의로 추측해 채우지 않고 "— Not provided"로 표시하며, 인시던트와 복구 시간만으로 점수를 냅니다.
| 서비스 | 측정 불가 사유 |
|---|---|
| Amazon Bedrock · Azure OpenAI | 공식 롤링 uptime% 미공개 — 인시던트 피드만 존재 |
| Gemini · Deepgram | 상태 페이지가 비교 가능한 롤링 30일 % 미노출 |
| xAI | 재시작 이후 엔드포인트별 성공률만 노출 — 30일 수치와 비교 불가 |
| Character.AI | 공식 상태 페이지가 비활성화됨 — 읽을 기록이 없음 (API는 직접 probe로 확인) |
// 04
레이턴시 (Probe RTT)
33개 AI 서비스의 엔드포인트를 Cloudflare Workers 엣지에서 5분 간격으로 직접 측정합니다. p50 / p75 / p95 분위수를 산출합니다.
Probe RTT는 네트워크 왕복 시간을 측정합니다. 모델의 추론(토큰 생성) 레이턴시가 아닙니다. "이 서비스가 얼마나 빨리 토큰을 만드나"가 아니라 "엔드포인트가 네트워크 계층에서 얼마나 빨리 응답하나"를 나타냅니다.
Probe 미적용: 레이턴시 랭킹은 직접 probe하는 API 서비스와 자체 API를 가진 코딩 에이전트(예: Cursor)를 대상으로 합니다 — 앱(Character.AI는 probe하되 상세 페이지에만 표시), 자체 API가 없는 코딩 에이전트, probe하지 않는 나머지 3개 AI 서비스는 제외됩니다.
// 05
인시던트 · MTTR · 탐지
인시던트 집계
인시던트 수는 서비스별 영향 컴포넌트를 모두 반영합니다. 제공사마다 인시던트를 세분화하는 정도가 다릅니다 — Anthropic은 모델별(Opus/Sonnet/Haiku)로 따로 보고해, 서비스 단위로 묶어 보고하는 곳보다 건수가 부풀려집니다. 따라서 건수가 많다고 신뢰도가 낮은 것은 아니며, 제공사끼리 비교할 때는 이 세분화 차이를 감안해야 합니다.
복구 시간 (MTTR)
Score의 Recovery 항목은 30일 중앙값을 사용합니다. 반면 ServiceDetails의 "Recovery" 카드는 7일 중앙값 + 최악값("일반 15분 · 최악 29시간34분")을 보여줍니다. 두 값은 같은 중앙값 방식을 쓰지만 관측 기간(7일 vs 30일)이 달라 서로 다를 수 있으며, 이는 정상입니다.
탐지 (Detection)
탐지 지표는 두 가지입니다 — MTTD(평균 탐지 시간, AIWatch가 인시던트를 감지하기까지 걸린 시간)와 RTT 저하 탐지(probe RTT 급증으로 잡는 조기 신호). 상태 페이지 폴링은 공식 발표보다 늦을 수밖에 없으므로, AIWatch는 "공식 상태 페이지보다 빠르다"고 절대 주장하지 않고 이 두 지표로만 정직하게 표현합니다. 이 지표는 월간 리포트에 집계되며, AIWatch Score나 대시보드 숫자에는 반영되지 않습니다.
최근 항목만 짧게 노출되는 출처(Azure·Bedrock)는 잠깐 발생했다 사라지는 인시던트를 놓칠 수 있습니다.
// 06
AIWatch Score
AIWatch Score는 uptime, 인시던트 영향 일수, 복구 시간, (probe 대상 API 서비스의 경우) 응답성을 종합한 0~100점 신뢰도 지표입니다. 30일 데이터를 기준으로 합니다.
Uptime Score (0~40)
| 입력 | 점수 |
|---|---|
| 100% | 40 |
| 99.5% | 36 |
| 99.0% | 32 |
| 97.0% | 16 |
| 95% 이하 | 0 |
Incident Score (0~25)
| 입력 | 점수 |
|---|---|
| 0 일 | 25.0 |
| 5 일 | 15.2 |
| 10 일 | 9.2 |
| 18 일 | 4.1 |
| 30 일 | 1.2 |
표의 값은 critical/major 영향(가중치 1.0)을 기준으로 합니다. minor만 발생한 날은 가중치 0.3입니다 — 예: minor 5일 ≈ 가중 1.5일 ≈ 21.5점.
영향 일수를 쓰는 이유: 일부 서비스(Anthropic 등)는 모델별(Opus/Sonnet/Haiku)로 인시던트를 따로 보고해 같은 장애가 여러 건으로 집계됩니다. 그래서 건수가 아닌 영향 일수를 쓰고, 각 날짜를 그날의 가장 심각한 영향도로 가중합니다 — critical/major = 1.0, minor = 0.3, 정보성/null = 제외.
Recovery Score (0~15)
| 입력 | 점수 |
|---|---|
| 30 분 | 13.2 |
| 1 시간 | 11.7 |
| 2 시간 | 9.1 |
| 4 시간 | 5.5 |
| 10 시간 | 1.2 |
MTTR은 해결된 인시던트 지속 시간의 30일 중앙값입니다(3건 미만인 소표본에서는 지나치게 긴 값만 1시간 기준값 쪽으로 완화 — 단일 장기 인시던트가 인시던트 적은 서비스를 과도하게 깎지 않도록).
Responsiveness Score (0~20)
5분 간격 health-check probe로 실제 엔드포인트의 응답 속도와 안정성을 측정합니다(33개 AI 서비스). 응답 속도와 일관성을 함께 반영합니다.
10 × exp(−max(p50, 50ms) / 400ms)
10 × exp(−CV_combined / 0.5)
대부분의 앱은 측정할 공개 API 엔드포인트가 없어 probe 대상이 아닙니다. Character.AI는 예외로, 상태 페이지 폐지 후 백엔드 health 엔드포인트로 probe합니다(상세 페이지에만 표시하고 레이턴시 랭킹에서는 제외). 코딩 에이전트는 자체 API가 있으면 직접 probe하며(예: Cursor), Claude Code·Codex는 기반 API(Claude·OpenAI)의 응답성을 상속받습니다. probe 세트(33개)에 들지 않는 나머지 3개 AI 서비스(Bedrock · Azure OpenAI · Modal)도 probe하지 않습니다.
이 경우 80점 만점을 100점으로 환산합니다(가용 컴포넌트만으로 산정).
probe-less: base 80 → 100 환산
새로 추가된 probe 대상 서비스는 7일치 데이터가 쌓이기 전까지 5% 페널티를 적용합니다.
Uptime 미제공 서비스
일부 서비스(Gemini·xAI·Bedrock 등)는 공식 uptime 수치가 없습니다. 가정값을 넣지 않고 uptime 컴포넌트(40점)를 제외한 뒤 나머지 가용 컴포넌트만으로 100점 환산합니다. probe가 있는 서비스(Gemini·xAI 등)는 인시던트·복구·응답성으로 점수를 산정해 랭킹에 포함합니다. probe도 없는 서비스(Bedrock·Azure)는 측정 신호가 인시던트·복구뿐이라 신뢰할 점수를 낼 수 없어, 점수를 산출·표시하지 않고 인시던트 추적만 제공합니다.
등급 기준
// 07
독립성 · 프라이버시
AIWatch는 AI 서비스 신뢰도를 중립적으로 측정합니다. 그 결과를 데이터로 보여주고, 누구의 영향도 받지 않고 공개합니다.
이 중립성이 AIWatch 데이터를 의사결정에 쓸 수 있게 하는 핵심입니다 — AIWatch는 측정한 것만 말하고, 측정할 수 없는 것은 분명히 밝힙니다.