챗GPT 한국어 릴리스 노트는 영어판보다 17일 늦어요 — 최신 7건이 빠지고 옛 항목 14건이 남았어요
챗GPT 도움말의 릴리스 노트를 영어와 한국어를 포함한 여덟 언어로 받아 날짜 헤딩을 전수로 셌어요. 영어만 8월 21일이고 나머지 일곱은 8월 4일에 멈춰 있었어요. 한국어판 상단은 6시간 전 수정이라고 적혀 있고요. 2026년 8월 22일 오후 관측이에요.
챗GPT 상태 페이지 실측 — 공식 API의 사고 25건이 전부 minor 이하이고, 가입과 로그인이 다 막혔다는 건도 minor예요
🤖
HowtoAI 편집팀AI 전문 에디터
AI 기술을 누구나 쉽게 활용할 수 있도록 실전 가이드를 작성합니다. ChatGPT, Claude, AI 자동화, SEO 분야를 전문으로 다룹니다.
목차 보기
- 어떤 조건에서 쟀는지 먼저 못박을게요
- 사고 25건의 등급을 세어 봤어요
- 가입도 로그인도 다 막혔다는 건도 minor로 적혀 있어요
- minor가 어디서 오는지 25쪽을 전부 열어 봤어요
- 어느 사고도 부품에 연결돼 있지 않아요
- 그 목록은 같은 도메인의 RSS에 그대로 있어요
- 부품이 가장 많이 걸린 사고는 가장 긴 사고가 아니에요
- 25는 그 기간의 사고 수가 아니라 피드의 상한이에요
- 더 나아가 JSON은 자기 창 안의 사고도 하나 빠뜨려요
- 지속시간을 재 보니 중앙값 84.9분이고 음수가 하나 나와요
- 음수는 왜 나오나요
- 부품 목록은 엔드포인트마다 개수가 달라요
- 공식 규격과 대조해 봤어요
- 이 상태 페이지를 만드는 곳은 Atlassian이 아니에요
- 직접 확인하실 때의 순서
- 확인하지 못한 것도 적어 둘게요
- 정리하면
챗GPT가 안 될 때 제일 먼저 여는 곳이 공식 상태 페이지예요. 그 페이지가 기계에게는 어떤 데이터를 주는지 직접 받아서 세어 봤어요.
결론부터 적을게요. status.openai.com 의 공개 API가 내준 사고는 25건이고, 등급은 minor 22건과 none 3건이 전부예요. major 와 critical 은 0건이에요. 그 25건 안에는 제목이 Chatgpt.com is down - all signups and logins are down as of right now 인 사고가 들어 있는데, 이 건의 impact 값도 minor 예요.
그리고 하나 더 있어요. 25건 중 어느 것도 부품에 연결돼 있지 않아요. 사고 객체에 components 키를 가진 건이 0건이에요. 그런데 사고 본문에는 "the impacted services"라는 표현이 계속 나와요.
말을 먼저 맞춰 둘게요. 이 글에서 등급은 API 응답의 impact 필드값을 가리켜요. 부품은 상태 페이지가 개별로 관리하는 구성요소, 그러니까 Login 이나 Conversations 같은 항목이에요. 그리고 이 글은 챗GPT가 실제로 얼마나 잘 돌았는지를 재지 않았어요. 상태 페이지가 기록해 둔 내용만 읽었어요.
먼저 잰 범위부터 밝힐게요. 이 글의 숫자는 전부 2026년 8월 24일 오후 4시 48분에서 4시 54분 사이(한국 시각) 에 파이썬으로 직접 받아 센 값이에요. 스크립트가 찍은 시각을 그대로 옮겼어요.
어떤 조건에서 쟀는지 먼저 못박을게요
값이 조회 시점에 묶이는 종류의 측정이라 조건이 숫자보다 먼저예요.
| 항목 | 값 |
|---|---|
| 데이터 출처 | OpenAI 공식 상태 페이지의 공개 상태 API |
| 주 엔드포인트 | https://status.openai.com/api/v2/incidents.json |
| 대조 엔드포인트 | summary.json · status.json · components.json · history.rss |
| 인증 | 없음. 키 없이 열리는 공개 경로 |
| 요청 방식 | 파이썬 urllib 로 직접 호출, 응답 원본 저장 |
| HTTP 상태 | 200, 응답 34,365바이트 |
| 응답 최상위 키 | page, incidents |
| 사고 객체 수 | 25 |
| 사고 객체 키 | 9개, 25건 전부 동일 |
| 사고 상세 페이지 | 25쪽 전수 확인, 실패 0건 |
| 조회 시각 | 2026년 8월 24일 오후 4시 48분에서 4시 54분 (한국 시각) |
200이 왔다고 데이터가 온 건 아니에요. 그래서 응답 앞부분에 <html 이 들어 있는지 먼저 확인했어요. 없었고, 첫 바이트가 {"page":{"id":"01JMDK9XYNY6RXSED6SDWW50WY","name":"OpenAI", 로 시작하는 JSON이었어요.
이 확인이 왜 필요한지는 바로 옆에서 증명됐어요. 같은 규격에 있는 incidents/unresolved.json 은 HTTP 404를 주면서 본문으로 65,779바이트짜리 HTML을 돌려줘요. 상태 코드를 안 보고 파싱하면 오류 페이지를 데이터로 착각하게 돼요.
사고 25건의 등급을 세어 봤어요
impact 필드값을 전부 모아 세면 이렇게 나와요.
impact 값 | 사고 수 |
|---|---|
minor | 22 |
none | 3 |
major | 0 |
critical | 0 |
| 합계 | 25 |
22 더하기 3은 25예요. 그리고 25건의 status 는 전부 resolved 예요. 미해결 사고는 0건이고요.
시간이 지나면서 바뀌는 값일 수 있으니 1분쯤 뒤에 한 번 더 받아 봤어요. 두 번째 응답도 똑같았어요.
RECHECK incidents n = 25
RECHECK impact = {'minor': 22, 'none': 3}
RECHECK any major/critical = False
RECHECK components key present on any incident = False
여기서 조심할 게 있어요. 이 분포를 보고 "챗GPT 장애는 다 사소하다"고 읽으면 틀려요. 아래에서 보겠지만 이 등급은 사고의 체감 크기를 재는 값이 아니에요. 그리고 25건이 그 기간 사고의 전량도 아니고요. 두 가지 다 따로 확인했어요.
가입도 로그인도 다 막혔다는 건도 minor로 적혀 있어요
25건 중 제목이 가장 강한 건이 이거예요.
name : Chatgpt.com is down - all signups and logins are down as of right now
impact : minor
status : resolved
created_at : 2026-08-20T00:02:08Z
resolved_at : 2026-08-20T00:54:17Z
제목은 사이트가 다 죽었다고 말하는데 등급은 minor 예요. 이게 축소인지 아닌지를 판단하려면 누가 그 값을 붙였는지부터 봐야 해요. 그래서 이 사고의 상세 페이지를 열어 봤어요.
상세 페이지 안에는 API가 보여 주지 않는 원본 기록이 들어 있어요.
"affected_components": [
{"component_id": "01JMXBNJXG1S2D9V65P1ZZTD94",
"current_status": "operational", "status": "degraded_performance"}],
"component_impacts": [
{"component_id": "01JMXBNJXG1S2D9V65P1ZZTD94",
"start_at": "2026-08-20T00:35:03.462Z",
"end_at": "2026-08-20T00:54:17.03Z",
"status": "degraded_performance"}],
"status_summaries": [
{"start_at": "00:02:08", "end_at": "00:03:27", "worst_component_status": "operational"},
{"start_at": "00:03:27", "end_at": "00:25:41", "worst_component_status": "operational"},
{"start_at": "00:25:41", "end_at": "00:35:03", "worst_component_status": "operational"},
{"start_at": "00:35:03", "end_at": "00:54:17", "worst_component_status": "degraded_performance"}]
위 블록은 상세 페이지 원본에서 키 일부를 덜어 내고 시각을 시·분·초까지만 줄여 옮긴 거예요. 원본의 start_at 은 2026-08-20T00:02:08.25Z 처럼 날짜와 밀리초까지 들어 있어요. 값 자체는 그대로예요.
읽어 보면 이래요. 걸린 부품은 Login 하나예요. 그리고 그 부품이 성능 저하로 기록된 구간은 00시 35분에서 00시 54분까지, 즉 19.2분이에요. 사고 전체 길이 52.1분 중 앞의 32.9분은 부품 기록상 정상으로 남아 있어요.
그리고 이게 중요해요. 이 상세 페이지 HTML 12만 바이트 안에서 minor 라는 문자열은 0회 나와요. major 도 0회예요. 사람이 보는 화면의 어휘는 Operational, Degraded, Partial outage, Full outage 네 가지예요.
즉 minor 는 사람이 골라 적은 단어가 아니라 /api/v2/ 경로가 내보내는 값이에요. 챗GPT가 안 열릴 때 증상별로 원인을 갈라 보는 순서는 챗GPT 접속 안 될 때 자가진단 7단계에 따로 정리해 뒀어요. 이 글은 그 페이지가 기계에게 무엇을 주는가만 다뤄요.
minor가 어디서 오는지 25쪽을 전부 열어 봤어요
한 건만 보고 규칙을 말하면 안 되니까 사고 상세 페이지 25쪽을 전부 받았어요. 25쪽 다 HTTP 200이었고 실패는 0건이에요.
각 쪽에서 component_impacts 의 상태값을 뽑아 모았더니 이렇게 나왔어요.
FETCHED 25 / 25 FAILS 0
ALL_component_impacts_status_VALUES {'degraded_performance': 56}
ANY_partial_outage False
ANY_full_outage False
impact=none with 0 affected components : 3 / 3
impact=minor with >=1 affected component: 22 / 22
두 가지가 한 번에 확정돼요.
첫째, impact 는 부품이 하나라도 표시됐는지에 1대1로 대응해요. 부품이 0개면 none 이고 하나 이상이면 minor 예요. 25건 전부 예외가 없어요. 사고가 얼마나 컸는지가 아니라 부품이 찍혔는지 아닌지를 나타내는 값에 가까워요.
둘째, 이 25건에서 부품에 찍힌 상태값은 degraded_performance 하나뿐이에요. 56건 전부 그래요. partial_outage 도 full_outage 도 한 건도 없어요.
그래서 결론이 이렇게 정리돼요. 이 기간에는 minor 보다 높은 등급이 나올 수가 없었어요. 등급을 낮게 매긴 게 아니라 등급을 올릴 입력값이 한 번도 들어오지 않은 거예요. 이 둘은 완전히 다른 이야기고, 이 자료로 확인되는 건 뒤쪽이에요.
| 물음 | 확인된 답 |
|---|---|
25건 중 major 이상이 있었나 | 없어요 |
부품이 partial_outage 로 찍힌 적이 있나 | 이 25건에서는 없어요 |
| 그래서 벤더가 축소한 것인가 | 이 자료로는 말할 수 없어요 |
partial_outage 는 어떤 등급이 되나 | 사례가 없어 확인 못 했어요 |
어느 사고도 부품에 연결돼 있지 않아요
앞에서 잠깐 나온 이야기를 제대로 볼 차례예요. 사고 객체가 가진 키는 아홉 개예요.
created_at · id · impact · incident_updates · name · page_id · resolved_at · status · updated_at
25건 전부 이 아홉 개고, components 는 없어요. 그러니까 API 응답만 읽는 프로그램은 어떤 기능이 영향을 받았는지 알 방법이 없어요.
그런데 사고 본문은 계속 목록을 가리켜요. 갱신 88건의 본문을 모아 세어 보니 이렇게 나와요.
| 본문 문구 | 등장 |
|---|---|
All impacted services have now fully recovered. | 22건 |
We have applied the mitigation and are monitoring the recovery. | 19건 |
We have identified that users are experiencing elevated errors for the impacted services. | 12건 |
We are investigating the issue for the listed services. | 6건 |
"impacted services" 또는 "listed services" 라는 표현이 88건 중 41건에 나와요. 정관사가 붙은 "the impacted services"·"the listed services" 만 세면 19건이고요. 위 표의 맨 윗줄 22건이 All impacted services ... 라서 정관사가 없거든요. 어느 쪽으로 세든 목록을 가리키는 문장은 있는데, 그 목록이 응답에 없어요. 서로 다른 본문은 88건 중 29종뿐이라 대부분이 정형 문구예요.
그 목록은 같은 도메인의 RSS에 그대로 있어요
버려진 게 아니라 다른 경로에 남아 있어요. https://status.openai.com/history.rss 를 받아 보면 항목마다 설명 안에 부품 목록이 들어 있어요. 로그인 사고 항목의 원본이 이래요.
<title><![CDATA[Chatgpt.com is down - all signups and logins are down as of right now]]></title>
<pubDate>Thu, 20 Aug 2026 00:54:17 GMT</pubDate>
<description><![CDATA[<b>Status: Resolved</b>All impacted services have now fully recovered.
<b>Affected components</b>
<ul>
<li>Login (Operational)</li>
</ul>]]></description>
같은 사고 25건을 두 경로에서 나란히 놓으면 이렇게 갈려요.
| 항목 | JSON incidents.json | RSS history.rss |
|---|---|---|
| 부품이 붙은 사고 수 | 0 / 25 | 22 / 25 |
| 부품 언급 총 줄 수 | 0 | 56 |
| 등장한 부품 이름 종류 | 0 | 31 |
RSS의 56줄은 상세 페이지에서 센 component_impacts 56건과 정확히 같아요. 두 경로가 같은 원본을 보고 있다는 뜻이에요. JSON만 그 연결을 떨어뜨리고 있어요.
부품이 안 붙은 3건은 정확히 impact 가 none 인 3건과 같아요. 앞 절의 1대1 대응이 여기서도 그대로 맞아떨어져요.
부품이 가장 많이 걸린 사고는 가장 긴 사고가 아니에요
이 대목이 등급을 크기로 읽으면 안 되는 이유를 잘 보여 줘요.
| 사고 제목 | 지속 | impact | RSS 부품 줄 수 |
|---|---|---|---|
Elevated error rates | 21.6분 | minor | 31줄 |
Elevated errors affecting ChatGPT conversations | 2,542.7분(42.4시간) | minor | 1줄 |
Elevated Errors for Thinking mode in ChatGPT | 175.5분 | minor | 3줄 |
21.6분짜리 사고가 부품 30종을 건드렸고, 42.4시간짜리 사고는 부품 하나만 걸려 있어요. 둘 다 minor 예요. 짧고 넓은 사고와 길고 좁은 사고가 같은 값을 받는 거죠.
21.6분짜리 쪽의 부품 목록은 이래요.
ChatGPT Atlas · ChatGPT Work · Deep Research · Sora · Chat Completions · Fine-tuning
Realtime · Responses · Image Generation · Codex in ChatGPT Desktop · Login · Conversations
Batch · Files · Embeddings · Codex API · Audio · GPTs · VS Code extension · Codex Web
File uploads · Voice mode · Images · Agent · CLI · Search · Moderations · Sites
Compliance API · Connectors/Apps · Login
31줄인데 이름 종류로는 30종이에요. Login 이 두 번 나오거든요. 이유는 아래 부품 목록 절에서 나와요.
25는 그 기간의 사고 수가 아니라 피드의 상한이에요
여기가 이 글에서 제일 조심해야 할 자리예요. 25건의 created_at 은 2026년 7월 25일부터 8월 21일까지 걸쳐 있어요. 27.3일이죠. 그래서 "27.3일에 25건"이라고 계산하고 싶어져요. 그렇게 쓰면 틀려요.
먼저 페이지를 넘겨 봤어요.
| 시도한 요청 | 응답 |
|---|---|
?page=2 | 200, 34,365바이트, 같은 25건 |
?page=3 | 200, 34,365바이트, 같은 25건 |
?per_page=100 | 200, 34,365바이트, 같은 25건 |
?limit=100 | 200, 34,365바이트 |
바이트 수까지 같아요. 파라미터가 아예 안 먹어요. 참고로 Atlassian 공식 API 문서에서 per_page 라는 문자열은 0회 나와요. 애초에 규격에 없는 파라미터예요.
그다음 같은 도메인의 아카이브 피드를 받아 봤어요.
| 경로 | 응답 크기 | 사고 수 | 기간 |
|---|---|---|---|
api/v2/incidents.json | 34,365바이트 | 25 | 2026-07-25에서 2026-08-21 |
history.rss | 97,292바이트 | 93 | 2026-05-26에서 2026-08-21 |
history.atom | 94,937바이트 | 93 | 같음 |
같은 상태 페이지가 한쪽으로는 25건, 다른 쪽으로는 93건을 줘요. 기간으로는 27.3일 대 87.1일이에요. JSON의 25건은 전부 RSS 안에 들어 있고, JSON에서 가장 오래된 건은 RSS에서 93건 중 26번째예요.
더 나아가 JSON은 자기 창 안의 사고도 하나 빠뜨려요
여기서 한 발 더 들어가 봤어요. JSON이 커버하는 구간 안쪽만 놓고 두 피드를 맞춰 본 거예요.
JSON 이 커버하는 구간 : 2026-07-25T11:57:02Z 에서 2026-08-21T23:15:09Z
그 구간 안의 RSS 항목 : 26건
그 구간 안의 JSON 항목: 25건
JSON 에 없는 1건 : Image generation unavailable in ChatGPT
종료 2026-07-27T19:04:42Z
id 01KY23YCPJ9M5BFFT6ZHKQE9MP
자기 구간 안에서도 전량이 아니에요. 그리고 이 누락은 눈으로 대조하면 놓치기 쉬워요. 같은 제목의 다른 사고가 같은 날 20시 24분에 끝난 채로 JSON에 들어 있거든요. 제목만 맞춰 보면 "있네" 하고 넘어가게 돼요.
그래서 이 엔드포인트로 할 수 있는 말과 없는 말이 갈려요.
| 쓸 수 있는 문장 | 쓰면 안 되는 문장 |
|---|---|
| 이 피드가 내준 25건이 전부 minor 이하다 | 27.3일 동안 사고가 25건 일어났다 |
| 25건 중 부품에 연결된 것이 0건이다 | 한 달에 사고가 평균 몇 건이다 |
| 25건의 중앙값 지속시간이 84.9분이다 | 이 기간 챗GPT 가동률이 몇 퍼센트다 |
공식 페이지가 실제로 내주는 것과 기대되는 것이 어긋나는 사례는 이 사이트에 하나 더 있어요. 챗GPT 한국어 릴리스 노트가 영어판보다 17일 늦는 걸 실측한 기록도 같은 방식으로 세어 본 글이에요.
지속시간을 재 보니 중앙값 84.9분이고 음수가 하나 나와요
created_at 에서 resolved_at 까지를 분으로 계산했어요.
| 항목 | 값 |
|---|---|
| 중앙값 | 84.9분 |
| 평균 | 264.0분 |
| 최댓값 | 2,542.7분 (42.4시간) |
| 양수 중 최솟값 | 3.0분 |
| 실제 최솟값 | -36.6분 |
| 60분 초과 | 15건 |
| 8시간 초과 | 5건 |
| 0분에서 60분 | 9건 |
15 더하기 9 더하기 1(음수)은 25예요.
평균이 중앙값의 세 배가 넘어요. 42.4시간짜리 한 건이 끌어올린 값이라 평균은 기준으로 쓰기 어려워요. 기억하실 숫자는 중앙값 84.9분과 8시간 초과 5건 쪽이에요.
긴 쪽 다섯 건은 이래요.
| 사고 | 지속 | impact |
|---|---|---|
Elevated errors affecting ChatGPT conversations | 2,542.7분 | minor |
Increased error rates | 763.7분 | minor |
Elevated errors in ChatGPT conversations for Free users | 518.5분 | minor |
Elevated errors with image generation | 506.8분 | minor |
Error while creating custom RBAC roles for Enterprise users | 503.1분 | none |
맨 아랫줄을 봐 주세요. 8시간 23분 동안 열려 있던 사고의 등급이 none 이에요. 앞에서 본 규칙 그대로예요. 부품이 하나도 찍히지 않아서 none 이 된 거고, 길이와는 무관해요.
음수는 왜 나오나요
한 건은 종료가 시작보다 앞서 있어요.
{"name": "We're seeing elevated latency, timeouts, and interrupted streaming ...",
"created_at": "2026-07-27T18:06:39Z",
"resolved_at": "2026-07-27T17:30:00Z",
"incident_updates": [
{"status": "resolved", "created_at": "2026-07-27T20:52:18Z", "display_at": "2026-07-27T17:30:00Z"},
{"status": "investigating", "created_at": "2026-07-27T18:06:39Z", "display_at": "2026-07-27T15:30:00Z"}]}
기전이 이거예요. 갱신에는 시각이 두 개 있어요. 실제로 쓴 시각인 created_at 과 화면에 보일 시각인 display_at 이에요.
- 사고의
created_at은 첫 갱신의created_at을 따라가요. - 사고의
resolved_at은 마지막 갱신의display_at을 따라가요. 25건 전부에서 그랬어요.
이 사고는 운영자가 display_at 을 실제 작성 시각보다 앞당겨 적어 뒀어요. 그래서 서로 다른 종류의 시각 두 개를 빼는 계산이 됐고 음수가 나온 거예요.
88건의 갱신 중 두 시각이 어긋난 건 4건이고 사고로는 3건이에요. 드물지만 있어요. 그러니 지속시간을 자동으로 계산하는 코드를 짤 거라면 음수 방어를 넣어 두셔야 해요.
부품 목록은 엔드포인트마다 개수가 달라요
부품이 몇 개인지 물으면 답이 갈려요.
| 엔드포인트 | 부품 수 | position 범위 |
|---|---|---|
summary.json | 25 | 0에서 24 |
components.json | 34 | 0에서 33 |
summary.json 쪽이 잘려 있어요. components.json 에만 있는 아홉 개는 이래요.
File uploads · Chat Completions · Login · Ads Manager · CLI
Conversations · GPTs · Image Generation · ChatGPT Work
여기서 하나 짚고 갈게요. 이름만으로 차집합을 구하면 여덟 개로 나와요. 실제 개수 차이는 아홉 개고요. 이름이 Login 인 부품이 두 개라서 이름으로 세면 하나가 겹쳐 사라지거든요. position 3번과 27번이고 id 가 서로 달라요. 왜 두 개인지는 확인하지 못했어요.
이게 앞 절에서 본 31줄과 30종의 차이이기도 해요. 21.6분짜리 사고에 Login 이 두 번 적힌 건 실제로 두 부품이 다 걸렸기 때문이에요.
부품 객체의 필드도 얇아요. 두 엔드포인트 모두 키가 일곱 개고, Atlassian 문서의 예시에 있는 description 조차 없어요. group 이나 group_id 도 없고요. 그래서 사람이 보는 화면의 묶음 구조는 이 두 엔드포인트로는 재현할 수 없어요.
조회 시점 기준으로 34개 부품이 전부 operational 이었고, 34개 전부 updated_at 이 2026년 7월 9일이었어요.
공식 규격과 대조해 봤어요
이 API가 따르는 규격은 Atlassian Statuspage의 공개 API예요. 그래서 그 문서를 직접 받아서(HTTP 200, 96,816바이트) 필드 이름을 세어 봤어요.
문서가 인쇄한 사고 객체 예시는 키가 열한 개예요. 실측은 아홉 개고요. 차이는 정확히 두 개예요.
| 필드 | 문서 등장 횟수 | status.openai.com |
|---|---|---|
shortlink | 10회 | 없음 |
monitoring_at | 10회 | 없음 |
incident_updates | 10회 | 있음 |
page_id | 14회 | 있음 |
started_at | 0회 | 없음 |
맨 아랫줄을 봐 주세요. started_at 은 애초에 이 규격의 필드가 아니에요. 문서 안에서 0회 나와요. 그러니 "표준의 started_at 이 빠졌다"고 쓰면 없는 표준을 만들어 내는 셈이에요. 실제로 빠진 건 shortlink 와 monitoring_at 두 개예요.
엔드포인트도 규격보다 좁아요. 문서가 /api/v2/ 아래로 인쇄한 경로는 여덟 개예요.
| 규격이 선언한 경로 | status.openai.com 응답 |
|---|---|
summary.json | 200 |
status.json | 200 |
components.json | 200 |
incidents.json | 200 |
incidents/unresolved.json | 404 (본문 65,779바이트 HTML) |
scheduled-maintenances.json | 404 (본문 0바이트) |
scheduled-maintenances/upcoming.json | 404 |
scheduled-maintenances/active.json | 404 |
200을 주는 건 넷뿐이에요. 문서가 선언한 여덟 경로 중 절반만 살아 있어요. 그리고 404들의 성격이 서로 달라요. scheduled-maintenances.json 만 본문이 비어 있고 나머지는 HTML 오류 페이지를 돌려줘요.
표에 안 넣은 경로도 하나 밝혀 둘게요. 규격에 없는 incidents/all.json 도 시험 삼아 넣어 봤는데 역시 404 에 64,537바이트짜리 HTML 본문이 왔어요. 다만 이건 문서가 선언한 경로가 아니에요. 문서 안에서 all.json 이라는 문자열은 0회 나와요. 이걸 위 표에 섞어 넣으면 바로 앞에서 started_at 을 두고 지적한 것과 똑같은 잘못, 그러니까 없는 표준을 만들어 내는 셈이 돼요. 부품 하나를 지정하는 components/부품ID.json 형태도 같은 이유로 표에 넣지 않았어요. 문서 안에 components/ 라는 문자열이 0회 나오거든요. 공식 문서를 그대로 옮겨 적은 안내와 실제 응답이 어긋나는 경우를 확인하는 습관은 챗GPT 계정 삭제 문서에서 30일이 네 갈래로 갈리는 걸 세어 본 기록에도 같은 방식으로 적어 뒀어요.
이 상태 페이지를 만드는 곳은 Atlassian이 아니에요
규격이 Atlassian 것이라 오해하기 쉬운데, 운영 주체는 달라요. 응답 헤더와 첫 화면 HTML에서 확인했어요.
| 근거 | 관측값 |
|---|---|
응답 헤더 Server | Vercel |
| 첫 화면 안 사고 링크 | statuspage.incident.io/openai-1/incidents/... 형태로 85회 |
첫 화면 안 Atlassian 문자열 | 0회 |
| 로고 파일 경로 | incident-io-status-page-logos 아래 |
세는 기준을 밝혀 둘게요. 도메인만 떼어 incident.io 로 세면 87회가 나오는데, 그중 사고 링크는 85개이고 나머지 2회는 incident.io 자체로 가는 링크예요. 위 표의 85는 사고 링크만 센 값이고, 중복 없이 서로 다른 사고 코드 85개예요.
즉 /api/v2/ 는 다른 회사가 제공하는 Statuspage 호환 층이에요. 규격에 있는데 없는 필드와 404가 나는 경로가 여기서 설명돼요. 다만 "호환 층이라서 빠졌다"는 건 제 해석이고, 그렇게 적힌 문서를 찾은 건 아니에요.
직접 확인하실 때의 순서
키가 필요 없어서 바로 돌아가요.
curl -s https://status.openai.com/api/v2/incidents.json > inc.json
head -c 40 inc.json
먼저 앞 40바이트를 눈으로 보세요. {"page": 로 시작하면 JSON이 온 거고, <html 이 보이면 오류 페이지를 받은 거라 그 파일로는 아무것도 세면 안 돼요.
그다음 세는 코드는 이래요.
import json
from collections import Counter
d = json.load(open('inc.json', encoding='utf-8'))
inc = d['incidents']
print('건수', len(inc))
print('등급', Counter(i['impact'] for i in inc))
print('부품 연결된 건', sum(1 for i in inc if i.get('components')))
print('가장 오래된 건', min(i['created_at'] for i in inc))
정리하면 확인 순서는 이렇게 돼요.
- HTTP 상태 코드를 먼저 본다. 404여도 본문이 오는 경로가 있다.
- 첫 바이트가
{인지 본다.<html이면 거기서 멈춘다. len(incidents)를 센다. 딱 25면 상한에 닿았을 가능성을 먼저 의심한다.- 가장 오래된
created_at을 본다. 최근 한 달이면 그 이전은 이 응답에 없다. - 더 필요하면
history.rss를 받는다. 같은 도메인에서 93건이 온다. - 어떤 기능이 걸렸는지 알아야 하면 JSON이 아니라 RSS의 설명이나 사고 상세 페이지를 본다.
- 지속시간을 계산한다면 음수 방어를 넣는다.
- 가동률을 계산할 생각이라면 3번과 4번 때문에 분자가 이미 잘려 있다는 걸 기억한다.
3번과 5번을 굳이 나눠 적은 이유가 있어요. 25건만 보고 판단하면 그 이전 68건이 통째로 안 보여요. 그리고 그 사실이 응답 어디에도 표시되지 않아요. 총 개수 필드도, 다음 페이지 링크도, 잘렸다는 표시도 없어요. 그냥 25개가 담긴 정상 응답으로 보여요.
이건 조심하세요
이 글의 숫자는 2026년 8월 24일 오후 4시 48분에 받은 응답 하나의 스냅샷이에요. 사고 피드는 계속 밀려나니까 25건의 내용도 등급 분포도 며칠 뒤엔 달라져요. 그러니 숫자를 외우지 마시고 위 확인 순서를 쓰세요. 그리고 이 관측은 상태 페이지가 기록해 둔 내용만 읽은 것이라, 그 시각에 챗GPT가 실제로 어땠는지는 재지 않았어요. 등급이 minor라는 건 부품이 성능 저하로 기록됐다는 뜻이지, 그때 서비스가 쓸 만했다는 뜻이 아니에요.
확인하지 못한 것도 적어 둘게요
이 글이 말하지 않는 것들이에요.
첫째, 25가 상한이라는 걸 문서로 확인하지 못했어요. 파라미터 네 개가 안 먹고 RSS가 93건을 준다는 관측으로 판단한 거예요. "25건까지만 준다"고 적어 둔 문서는 찾지 못했어요.
둘째, RSS의 93건이 전량인지도 몰라요. 93은 100보다 작아서 상한에 안 닿았을 가능성이 크지만, RSS 쪽 상한값을 확인하지 못했어요. 2026년 5월 26일 이전 사고는 이 방법으로 못 봐요.
셋째, impact 산출 규칙을 문서로 확인하지 못했어요. 25건 전부에서 "부품 0개면 none, 하나 이상이면 minor"가 성립했지만 이건 25건짜리 표본의 관측이에요. 그리고 partial_outage 나 full_outage 가 어떤 등급이 되는지는 이 기간에 사례가 하나도 없어서 확인할 수 없었어요.
넷째, 부품 상태를 누가 언제 찍는지 몰라요. 자동인지 수동인지, 모니터링이 판단하는지 사람이 판단하는지 확인하지 못했어요. 그러니 minor 라는 값이 축소인지 아닌지도 이 자료로는 말할 수 없어요. 확인된 건 "부품이 성능 저하로만 기록됐고 그게 API 어휘로 minor가 된다"까지예요.
다섯째, 실제 서비스 품질을 재지 않았어요. 챗GPT를 직접 호출해 응답률이나 지연을 잰 적이 없어요. 그래서 "실제로는 더 심했다"고 쓸 근거도 없어요.
여섯째, 사고 제목을 누가 썼는지 몰라요. Chatgpt.com is down - all signups and logins are down as of right now 같은 문장이 사람이 쓴 것인지 다른 경로로 들어온 것인지 확인하지 못했어요.
일곱째, summary.json 이 왜 25개에서 잘리는지 몰라요. 부품 쪽에도 25가 상한으로 걸린 것인지 다른 이유인지 확인하지 못했어요. 25라는 수가 사고 쪽과 부품 쪽에 함께 나타난다는 관측까지예요.
여덟째, 이름이 같은 Login 부품 두 개의 관계를 몰라요. id 가 다르다는 것까지만 확인했어요. 하나가 옛것인지, 서로 다른 묶음에 속하는지는 못 봤어요.
아홉째, 화면의 묶음 구조가 어디서 오는지 몰라요. group 과 group_id 필드가 두 엔드포인트 모두 없어서, 사람이 보는 화면의 묶음 표시가 어느 경로에서 오는지 확인하지 못했어요.
열째, 다른 회사 상태 페이지와 비교하지 않았어요. 같은 규격을 다른 서비스가 어떻게 채우는지는 안 봤어요. 이 관측은 status.openai.com 한 곳에 한정돼요.
열한째, page.updated_at 이 엔드포인트마다 다른 이유를 몰라요. incidents.json 은 2026년 8월 21일, status.json 은 2026년 7월 9일이에요.
열두째, 이 숫자들은 한 번의 스냅샷이에요. 며칠 뒤에 다시 받으면 25건의 구성도 등급 분포도 달라져요. 그래서 본문에 확인 절차를 함께 적어 뒀어요.
정리하면
| 물음 | 2026년 8월 24일 오후 4시 48분 기준 답 |
|---|---|
| 공개 API가 내준 사고는 | 25건 |
| 등급 분포는 | minor 22 · none 3 |
major 이상은 | 0건 |
| 미해결 사고는 | 0건 |
| 가입과 로그인이 다 막혔다는 건의 등급은 | minor |
| 그 건에서 부품이 저하로 기록된 시간은 | 52.1분 중 19.2분 |
| 부품에 연결된 사고는 | 0 / 25 |
| 같은 사고를 RSS는 몇 건에 연결해 두나 | 22 / 25 |
| 지속시간 중앙값은 | 84.9분 |
| 8시간을 넘긴 건은 | 5건 |
| 지속시간이 음수인 건은 | 1건 |
| 같은 도메인 RSS가 주는 사고는 | 93건 |
| 25건이 그 기간 전량인가 | 아니에요 |
| 부품은 몇 개인가 | summary.json 25 · components.json 34 |
| 실제 서비스 품질은 | 재지 않았어요 |
상태 페이지의 등급은 그 순간 부품이 어떻게 표시됐는지를 옮긴 값이에요. 사고가 얼마나 컸는지, 얼마나 오래 갔는지, 몇 명이 겪었는지는 그 값에 들어 있지 않아요. 42.4시간짜리와 21.6분짜리가 같은 minor 를 받고, 8시간 23분짜리가 none 을 받는 이유가 그거예요.
그래서 챗GPT 장애를 기록으로 남기실 거라면 등급 하나만 옮겨 적지 마시고 지속시간과 부품 목록을 함께 적어 두시는 편이 나아요. 그리고 그 부품 목록은 JSON 쪽에 없으니 RSS나 사고 상세 페이지에서 가져오셔야 해요.
확인한 자료: https://status.openai.com/api/v2/ 아래 incidents.json(HTTP 200, 34,365바이트, 사고 25건) · summary.json(5,290바이트) · components.json(6,928바이트) · status.json(202바이트) 응답 전문과, 404를 돌려준 여섯 경로(규격이 선언한 넷과 규격 밖 둘)의 상태 코드 및 본문 크기. 같은 도메인의 history.rss(97,292바이트, 93건)와 history.atom(94,937바이트, 93건). 사고 상세 페이지 25쪽 전수(전부 HTTP 200, 실패 0건)와 첫 화면 HTML 290,119바이트. 규격 대조용으로 Atlassian Statuspage 공개 API 문서 https://metastatuspage.com/api(HTTP 200, 96,816바이트) 한 쪽. 모두 2026년 8월 24일 오후 4시 48분 4초에서 4시 54분 34초 사이(한국 시각)에 파이썬 urllib 로 직접 받은 값이고, 스크립트가 찍은 시각을 그대로 옮겼어요.
❓ 자주 묻는 질문 (FAQ)
챗GPT 상태 페이지의 공개 API는 사고를 몇 건이나 주나요?
2026년 8월 24일 오후 4시 48분(한국 시각)에 status.openai.com 의 incidents.json 을 받아 보니 정확히 25건이었어요. 그런데 이 25건은 그 기간에 일어난 사고 전량이 아니에요. 같은 도메인의 history.rss 는 같은 시각에 93건을 주거든요. 그리고 페이지 파라미터를 붙여도 소용이 없어요. page=2, page=3, per_page=100, limit=100 을 각각 시도했는데 네 번 다 응답 바이트 수까지 똑같은 그 25건이 왔어요. 그러니 25는 그 기간의 사고 수가 아니라 이 엔드포인트가 내주는 상한으로 읽어야 해요.
사고 등급이 전부 minor라던데 사실인가요?
제가 받은 25건 기준으로는 사실이에요. impact 필드값이 minor 22건, none 3건이고 major 와 critical 은 0건이었어요. 두 번 따로 받아 두 번 다 같은 값이 나왔고요. 다만 여기에는 이유가 있어요. 사고 상세 페이지 25쪽을 전부 열어 부품에 찍힌 상태값을 뽑아 보니 56건 전부가 degraded_performance 하나였어요. partial_outage 도 full_outage 도 이 기간에는 한 건도 없었어요. 즉 등급을 낮게 매긴 게 아니라 등급을 올릴 입력값이 이 기간에 들어온 적이 없어요.
사이트가 다 죽었다는 사고도 minor로 적혀 있다는 게 무슨 뜻인가요?
제목이 'Chatgpt.com is down - all signups and logins are down as of right now' 인 사고가 있어요. 2026년 8월 20일 00시 02분에 열려 00시 54분에 닫혔고, API 의 impact 값은 minor 예요. 상세 페이지의 원본 기록을 보면 걸린 부품은 Login 하나이고, 그 부품이 degraded 로 기록된 구간은 00시 35분에서 00시 54분까지 19.2분뿐이에요. 앞의 32.9분은 부품 기록상 정상이에요. 그래서 제목과 등급이 어긋나 보이는 거예요. minor 라는 단어를 사람이 골라 적은 건 아니에요. 사고 상세 페이지 HTML 에서 minor 라는 문자열은 0회 나와요.
어떤 기능에 문제가 생겼는지 API로 알 수 있나요?
이 25건으로는 알 수 없어요. 사고 객체가 가진 키는 아홉 개인데 그중에 components 가 없어요. 25건 전부 없어요. 그런데 사고 본문에는 'impacted services' 나 'listed services' 라는 표현이 88건의 갱신 중 41건에 나와요. 정관사가 붙은 'the impacted services'·'the listed services' 만 세면 19건이에요. 목록을 가리키는 문장은 있는데 목록 자체가 응답에 없는 셈이에요. 대신 같은 도메인의 history.rss 는 항목 설명 안에 Affected components 목록을 넣어 줘요. 같은 사고 25건 중 22건에 부품 이름이 붙어 있고, 총 56줄이에요.
상태 페이지가 선언한 부품은 몇 개인가요?
물어보는 엔드포인트에 따라 갈려요. summary.json 은 25개를 주고 components.json 은 34개를 줘요. position 값을 보면 summary 쪽이 0에서 24까지만 주고 있어서 잘려 있는 쪽이 summary 예요. 그리고 34개 중에 이름이 Login 인 부품이 두 개 있어요. id 가 서로 달라요. 그래서 이름만으로 세면 하나가 겹쳐 사라져 33종으로 보여요. 왜 두 개인지는 확인하지 못했어요.
사고 지속시간은 얼마나 되나요?
created_at 에서 resolved_at 까지를 재면 중앙값 84.9분, 평균 264.0분이에요. 25건 중 15건이 60분을 넘고 5건은 8시간을 넘어요. 가장 긴 건이 2,542.7분, 그러니까 42.4시간이에요. 양수 중 가장 짧은 건은 3.0분이고요. 양수 중이라고 적은 이유가 있어요. 25건 중 한 건은 지속시간이 마이너스 36.6분으로 계산돼요. 종료 시각이 시작 시각보다 앞서 있어요.
종료 시각이 시작보다 앞선다는 게 오류인가요?
데이터가 깨진 건 아니고 필드를 채우는 방식 때문이에요. 사고 객체의 resolved_at 은 마지막 갱신의 display_at 을 그대로 따라가요. 25건 전부에서 그랬어요. 반면 created_at 은 갱신의 created_at 을 따라가고요. 문제의 사고는 운영자가 display_at 을 실제 작성 시각보다 앞당겨 적어 뒀어요. 갱신 작성은 18시 06분인데 표시 시각은 15시 30분, 종료 작성은 20시 52분인데 표시 시각은 17시 30분이에요. 그래서 계산상 종료가 시작보다 앞서요. 88건의 갱신 중 두 시각이 어긋난 건 4건이고 사고로는 3건이에요.
이 API로 챗GPT 가동률을 계산해도 되나요?
권하지 않아요. 세 가지가 막아요. 첫째, 25건은 전량이 아니라 상한이라 분자가 이미 잘려 있어요. 둘째, 그 25건이 커버하는 구간 안에서도 한 건이 빠져 있어요. RSS 에는 있는데 JSON 에는 없는 사고가 하나 있거든요. 셋째, 어느 사고도 부품에 연결돼 있지 않아서 어떤 기능이 몇 분 동안 어땠는지 분해할 수가 없어요. 기록을 훑어보는 용도라면 괜찮지만 가동률 수치를 뽑는 용도로는 이 엔드포인트 하나로 부족해요.
공유하기
챗GPT 계정 삭제 — 한 문서에 30일이 여덟 번, 그중 일곱 번이 네 갈래로 갈려요
챗GPT 계정 삭제 문서 한 편에 30일이 여덟 번 나오는데 그중 일곱 번이 네 갈래로 갈려요. 데이터 삭제는 상한, 이메일 재사용은 하한이라 방향이 반대예요. 애플 앱스토어 구독은 계정을 지워도 안 끊기고, 비활성화된 계정은 30일을 기다려도 안 풀려요.
챗GPT 광고 설정 — 개인화를 꺼도 광고는 남고, 지운 광고 데이터는 30일 남는다
챗GPT 광고 설정 화면에서 문서가 Ads controls 항목으로 열거하는 것은 네 줄이고, 광고를 없애는 플랜 전환은 같은 화면의 다섯 번째 줄이에요. 개인화를 꺼도 광고는 그대로 남고, 광고를 없애는 항목은 메시지 한도를 깎고, 지운 광고 데이터는 서버에서 빠지는 데 최대 30일이 걸려요. OpenAI 헬프센터 원문 문장으로 경계를 갈라 정리했어요.
올라마 모델 기본 태그 실측 — 219개 중 196개가 4비트이고, 크기가 여럿인 97개 중 75개는 작은 쪽에 가까운 크기를 받아요
이름만 적고 받으면 어떤 파일이 오는지, 올라마 공식 라이브러리 235개의 기본 태그를 레지스트리에서 전수로 열어 봤어요. 219개가 응답했고 그중 196개가 4비트였어요. 크기 선택지가 여럿인 97개 중 75개는 작은 쪽에 가까운 크기에 붙어 있고, 82개는 제일 큰 선택지의 숫자가 기본보다 컸어요. 2026년 8월 24일 오후 4시 48분에서 4시 56분 사이(한국 시각) 관측이에요.
n8n 템플릿 11,665개 중 값이 붙은 것은 1,255개 — 창작자 2,441명 가운데 값을 붙인 사람은 264명이에요
n8n 공식 템플릿 라이브러리를 47페이지 전수로 받아 11,665편을 셌어요. 값이 붙은 것은 1,255편(결제 링크 기준으로는 1,265편), 중앙값은 20달러, 가장 흔한 가격표는 25달러예요. 창작자 2,441명 중 값을 붙인 사람은 264명이고, 그중 114명은 유료가 딱 한 편이에요. 2026년 8월 24일 오전 관측이에요.