METHODOLOGY

AIWatch는 어떻게 동작하는가 — 측정 방법론

AI 서비스 신뢰도를 독립적이고 투명하게 측정합니다 — 계정도, 개인정보도 필요 없습니다.

37개 서비스 · 5분 간격 폴링 · UTC 기준

측정할 수 있는 것은 공개하고, 측정할 수 없는 것은 분명히 밝힙니다.

측정 대상

AIWatch는 LLM API 15개, 코딩 에이전트 6개, 음성 3개, 추론·인프라 7개, 영상 2개, AI 앱 4개 — 총 37개 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 — 24개 AI 서비스의 API 엔드포인트 직접 측정

보안 이슈 모니터링

상태·신뢰도 측정과는 별개로, AI 스택에 영향을 주는 보안 이슈도 함께 추적해 월간 리포트에 집계합니다. 이 데이터는 AIWatch Score나 인시던트 집계에는 반영되지 않습니다.

  • OSV.dev — SDK 취약점 (PyPI · npm 24개 추적 패키지), GitHub Advisories로 상세 보강
  • Hacker News — AI 서비스 관련 보안 뉴스 (Algolia 검색 API)

상태 결정

서비스별 상태는 계층화된 우선순위 체인으로 결정되며, 화면에는 Operational · Partial Outage · Major Outage 로 표기됩니다. 규칙은 위에서부터 순서대로 확인하며, 처음 일치하는 규칙에서 상태가 결정됩니다.

1 · worst-of
멀티 컴포넌트 worst-of
하나의 서비스가 여러 컴포넌트로 구성된 경우(예: Cursor의 IDE + Cloud Agents + CLI), 그중 가장 심각한 상태를 서비스 배지에 표시합니다 (Major Outage > Partial Outage > Operational).
2 · component match
컴포넌트 매칭
해당 서비스의 주요 컴포넌트가 지정되어 있으면 그 컴포넌트의 상태를 사용합니다.
3 · overall indicator
전체 인디케이터 폴백
컴포넌트를 찾지 못하면 상태 페이지의 전체 인디케이터로 폴백합니다. 단, 필터링 후 관련된 미해결 인시던트가 없으면 정상으로 간주해, 공유 상태 페이지에서 다른 서비스의 인시던트가 섞이는 것을 막습니다(예: ChatGPT 인시던트가 OpenAI API 상태에 영향을 주지 않도록).
4 · incidentExclude bypass
incidentExclude 컴포넌트 우회
제목 기반 제외 패턴에 걸리더라도, 인시던트의 컴포넌트 태그가 해당 서비스의 주요 컴포넌트로 시작하면 포함합니다. 제목 문자열 매칭보다 컴포넌트 태그를 더 우선하기 때문입니다.
5 · component-status filter
컴포넌트 상태 인시던트 필터
컴포넌트는 정상인데 제공사가 모든 컴포넌트에 인시던트를 일괄로 연결한 경우, 미해결 인시던트를 제거합니다(해결됨·모니터링은 유지). 이렇게 하면 무관한 인시던트가 정상 컴포넌트에 잘못 표시되지 않습니다.
6 · fetch-failure cross-validation
수집 실패 보정
상태 페이지를 못 읽어 저하로 잡혔더라도 probe RTT가 정상이면 다시 정상으로 되돌립니다. 같은 플랫폼의 70% 이상이 동시에 실패하면 플랫폼 자체 장애로 판단해 모두 정상으로 처리합니다. 확실한 근거가 있을 때만 보수적으로 덮어씁니다.

규칙의 전체 순서와 각 규칙의 근거는 오픈소스 저장소의 status-determination 문서에 공개되어 있습니다.

Uptime

Uptime%는 출처에 따라 세 가지 방식으로 나뉩니다.

  • Official — 상태 페이지가 공개한 %를 그대로 읽습니다(페이지마다 집계 기간이 다름).
  • Platform — 상태 페이지 플랫폼(Better Stack)이 자체 모니터로 측정한 가동률 (Together · Fireworks · HuggingFace · Modal · Luma). 제공사 공식 SLA가 아닌 플랫폼 측정치입니다.
  • Estimate — 공식 수치가 없는 서비스(Bedrock·Azure OpenAI)는 최근 90일의 라이브·아카이브 인시던트를 합쳐 추정합니다. 영향을 준 인시던트가 없으면 %를 아예 산출하지 않습니다.

Atlassian 가중 영향 일수: 다운타임은 단순 인시던트 건수가 아니라, 각 날짜를 그날의 가장 심각한 영향도로 가중한 "영향 일수"로 집계합니다 — critical · major = 1.0 (Major Outage / Partial Outage), minor = 0.3 (Degraded), 정보성/null = 제외. uptime과 score 모두 같은 가중 방식을 씁니다.

측정 한계와 그 이유

아래 서비스는 공식 상태 페이지에 비교 가능한 30일 롤링 uptime%가 없습니다. 임의로 추측해 채우는 대신 "— Not provided"로 명확히 표시합니다.

서비스측정 불가 사유
Amazon Bedrock · Azure OpenAI공식 롤링 uptime% 미공개 — 인시던트 피드만 존재 → 추정 전용
Gemini · OpenRouter · Deepgram상태 페이지가 비교 가능한 롤링 30일 % 미노출
xAI재시작 이후 엔드포인트별 성공률만 노출 — 30일 수치와 비교 불가

레이턴시 (Probe RTT)

24개 AI 서비스의 API 엔드포인트를 Cloudflare Workers 엣지에서 5분 간격으로 직접 측정합니다. p50 / p75 / p95 분위수를 산출합니다.

핵심 한계 — 네트워크 RTT ≠ 추론 레이턴시

Probe RTT는 네트워크 왕복 시간을 측정합니다. 모델의 추론(토큰 생성) 레이턴시가 아닙니다. "이 서비스가 얼마나 빨리 토큰을 만드나"가 아니라 "엔드포인트가 네트워크 계층에서 얼마나 빨리 응답하나"를 나타냅니다.

Probe 미적용: 레이턴시 랭킹은 직접 probe하는 24개 AI 서비스만 대상입니다 — 앱·코딩 에이전트, 그리고 probe하지 않는 나머지 3개 AI 서비스는 제외됩니다.

인시던트 · 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)는 잠깐 발생했다 사라지는 인시던트를 놓칠 수 있습니다.

AIWatch Score

AIWatch Score는 uptime, 인시던트 영향 일수, 복구 시간, (probe 대상 API 서비스의 경우) 응답성을 종합한 0~100점 신뢰도 지표입니다. 30일 데이터를 기준으로 합니다.

AIWatch Score = Uptime + Incidents + Recovery + Responsiveness
40
Uptime
25
Incidents
15
Recovery
20
Responsiveness

Uptime Score (0~40)

(uptime% − 95%) / 5% × 40
입력점수
100%40
99.5%36
99.0%32
97.0%16
95% 이하0

Incident Score (0~25)

25 × exp(−weighted_days / 10)
입력점수
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)

15 × exp(−MTTR_hours / 4)
입력점수
30 13.2
1 시간11.7
2 시간9.1
4 시간5.5
10 시간1.2

MTTR은 해결된 인시던트 지속 시간의 30일 중앙값입니다(3건 미만이면 평균으로 폴백).

Responsiveness Score (0~20)

5분 간격 health-check probe로 실제 API 엔드포인트의 응답 속도와 안정성을 측정합니다(24개 AI 서비스). 응답 속도와 일관성을 함께 반영합니다.

Speed (0~10) — p50 RTT 지수 감쇠
10 × exp(−max(p50, 50ms) / 400ms)
Stability (0~10) — 결합 변동계수 지수 감쇠
10 × exp(−CV_combined / 0.5)

앱과 코딩 에이전트는 측정할 API 엔드포인트가 없어 probe 대상이 아니며, probe 세트(24개)에 들지 않은 나머지 3개 AI 서비스(Bedrock · Azure OpenAI · Modal)도 probe하지 않습니다.

이 경우 80점 만점을 100점으로 환산하고, 응답성 신호가 없으므로 5% 페널티를 적용합니다.

Score = (Uptime + Incidents + Recovery) × 0.9 → ×(100/80)
probe-less: base 80 → 100 환산 + 5% 신뢰도 페널티

새로 추가된 probe 대상 서비스는 7일치 데이터가 쌓이기 전까지 5% 페널티를 적용합니다.

Uptime 미제공 서비스

일부 서비스(Gemini, xAI 등)는 공식 uptime 수치가 없습니다. 이 경우 업계 평균(99.5%, 40점 척도에서 36점)을 가정하고 10% 페널티를 적용합니다.

Score = (36 + Incidents + Recovery) × 0.9

등급 기준

90+Excellent
75+Good
55+Fair
40+Degrading
<40Unstable

독립성 · 프라이버시

AIWatch는 AI 서비스 신뢰도를 중립적으로 측정합니다. 그 결과를 데이터로 보여주고, 누구의 영향도 받지 않고 공개합니다.

🆓 무료 · 무가입
공개 대시보드는 완전 무료이며, 계정이나 로그인 없이 누구나 이용할 수 있습니다. 개인정보(PII)는 수집하지 않습니다.
🔍 오픈소스
상태 결정, 점수 산정, 수집 로직 전부가 AGPL-3.0으로 공개되어 있습니다. 방법론을 직접 검증할 수 있습니다.
⚖️ 성과 기반
Score와 Fallback 추천은 객관적으로 측정된 신뢰도에만 근거합니다. 순위나 추천은 비용으로 살 수 없습니다.
🔒 프라이버시
익명 사용 통계(GA4)만, 동의 시에만 수집합니다. 동의 없이는 분석·광고 쿠키가 저장되지 않습니다.

이 중립성이 AIWatch 데이터를 의사결정에 쓸 수 있게 하는 핵심입니다 — AIWatch는 측정한 것만 말하고, 측정할 수 없는 것은 분명히 밝힙니다.