주의. 이 문서는 2025년 11월에 발생한 특정 사건을 다루고 있습니다. 현재 진행 중인 장애 상황을 확인하려면 Cloudflare System Status를 참조하십시오.
| Cloudflare November 2025 Outage | |
|---|---|
 인터넷의 20%가 사라진 날 | |
| 발생 일시 | 2025년 11월 18일 11:20 (UTC) (한국 시간 2025년 11월 18일 20:20) |
| 종료 일시 | 2025년 11월 18일 17:06 (UTC) (한국 시간 2025년 11월 19일 02:06) |
| 지속 시간 | 약 5시간 46분 |
| 심각도 | Critical (P0) |
| 발생 원인 | 봇 관리(Bot Management) 구성 파일 생성 로직 오류 및 배포 파이프라인 검증 실패 |
| 피해 대상 | Cloudflare CDN/WAF 이용 고객 전체 (전 세계 인터넷 트래픽의 약 20% 영향) |
| 상태 | 해결됨 (Resolved) |
개요[편집 / 원본 편집]
- “ "This was a self-inflicted wound."
(이것은 우리 스스로 자초한 상처였습니다.)”
2025년 11월 Cloudflare Global Network 장애는 2025년 11월 18일(한국 시간 기준 오후 8시 20분), 전 세계 최대의 CDN 및 보안 기업인 Cloudflare의 글로벌 네트워크 전체가 마비된 대규모 인터넷 서비스 장애 사건이다.
단순한 접속 지연을 넘어, Cloudflare를 프록시로 사용하는 전 세계 수백만 개의 웹사이트와 API 서버가 동시에 500 Internal Server Error 또는 502 Bad Gateway를 반환하며 먹통이 되었다. 이로 인해 Discord, Shopify, OpenAI(ChatGPT), Reddit 등 주요 글로벌 IT 서비스가 동시다발적으로 중단되는 초유의 사태가 벌어졌다.
초기에는 트래픽 패턴이 급격히 소멸하는 양상을 보여 대규모 해킹이나 DDoS 공격으로 의심받았으나, 최종적으로는 내부 설정(Config) 배포 시스템의 결함이 원인으로 밝혀졌다. 인터넷 인프라의 단일 실패 지점(SPOF)이 얼마나 큰 파급력을 가질 수 있는지 보여준 대표적인 사례로 기록되었다.
전개[편집 / 원본 편집]
시간은 UTC(협정 세계시)를 기준으로 하며, 괄호 안에 KST(한국 표준시)를 병기한다. 사건의 재구성은 Cloudflare 공식 블로그의 사건 분석 보고서(Incident Report) 및 시스템 상태 페이지(Status Page)의 로그를 기반으로 한다.
장애 발생 및 초기 대응 (11:20 ~ 12:00)[편집 / 원본 편집]
- 11:20 UTC (20:20 KST) - 장애 시작.
- Cloudflare 엔지니어링 팀이 봇 관리(Bot Management) 제품군의 성능 개선을 위한 정기 업데이트를 배포하기 시작했다. 배포 직후, 북미와 유럽 지역의 주요 데이터센터(PoP)를 시작으로 아시아, 남미 등 전 세계 엣지(Edge) 서버에서 HTTP 요청 처리가 실패하기 시작했다.
- 엔지니어들이 사용하는 내부 모니터링 대시보드인 Grafana의 트래픽 그래프가 수직 낙하(Nosedive)했다.
- 11:25 UTC (20:25 KST) - [오판] DDoS 공격 의심.
- 관제 센터(NOC)에 'Global Traffic Drop' 경보가 울렸다. 트래픽이 빠지는 속도가 물리적 케이블 절단 수준으로 빨랐고, 동시에 5xx 에러율이 100%에 육박했다.
- 당시 당직 엔지니어들은 이를 "서비스를 마비시키기 위한 전례 없는 규모의 Layer 7 DDoS 공격"으로 판단, 공격 방어 프로토콜을 가동하고 상위 티어 대응 팀을 호출했다.
- 11:35 UTC (20:35 KST) - 사고 대응 팀(Incident Response Team) 소집.
- 런던, 샌프란시스코, 싱가포르의 시니어 엔지니어들이 긴급 화상 회의(War Room)에 소집되었다. 그러나 보안 팀의 분석 결과, 외부에서 유입되는 악의적인 트래픽 패턴(Attack Signature)이 전혀 발견되지 않았다.
- 대응 팀은 "이것은 공격이 아니라, 내부 시스템의 붕괴(Internal System Failure)"라는 결론을 내리고, 최근 변경 사항(ChangeLog)을 역추적하기 시작했다.
원인 파악 및 고립 (12:00 ~ 13:00)[편집 / 원본 편집]
- 12:03 UTC (21:03 KST) - 공식 장애 공지.
- Cloudflare Status 페이지에 첫 공지가 게시되었다.
- “ Investigating - We are currently investigating widespread issues with our services causing 5xx errors and dashboard inaccessibility.
조사 중 - 현재 5xx 오류 및 대시보드 접속 불가 현상을 유발하는 광범위한 서비스 문제를 조사하고 있습니다.”
- 아이러니하게도 Status 페이지 역시 Cloudflare Workers를 일부 사용하고 있어, 로딩 속도가 매우 느리거나 간헐적으로 접속되지 않는 현상이 발생했다.
- 12:45 UTC (21:45 KST) - 범인 색출.
- 시스템 로그 분석 결과, 전 세계 엣지 서버의 프로세스들이 메모리 부족(OOM, Out of Memory)으로 인해 강제 종료되고 있음을 확인했다.
- 프로세스가 재시작(Restart)되자마자 다시 죽어버리는 무한 재부팅 루프(Crash Loop) 현상이 관측되었다.
복구 및 해결 (13:00 ~ 17:06)[편집 / 원본 편집]
- 13:05 UTC (22:05 KST) - 원인 특정: '봇 관리' 구성 파일.
- 11:20에 배포된 봇 탐지 룰셋(Ruleset) 파일이 평소 크기의 수천 배로 비대해진 것이 확인되었다. 이 거대한 파일이 메모리에 로드되면서 서버를 터뜨린 것.
- 엔지니어들은 즉시 해당 기능을 비활성화하는 '글로벌 킬 스위치(Global Kill-switch)'를 누르려 했으나, 제어부(Control Plane)조차 과부하로 명령 전달이 지연되었다.
- 13:10 UTC (22:10 KST) - 1차 우회(Bypass) 조치.
- 중앙 제어가 실패하자, 데이터센터별로 수동 라우팅 변경(BGP 철회 등)을 통해 트래픽을 우회시키거나 문제의 구성 파일을 무시하도록 하는 긴급 패치를 적용하기 시작했다. 일부 지역에서 간헐적으로 접속이 재개됨.
- 14:24 UTC (23:24 KST) - 롤백(Rollback) 및 배포 차단.
- 문제가 된 데이터베이스 변경 사항을 되돌리고, 정상 작동했던 마지막 버전(Last Known Good Configuration)을 강제로 전체 네트워크에 푸시(Push)했다.
- 14:30 UTC (23:30 KST) - 트래픽 회복세.
- 롤백 설정이 전파되면서 엣지 서버들의 재부팅 루프가 멈췄다. HTTP 요청 성공률이 0%에서 90%대로 급격히 회복되었다.
- 17:06 UTC (익일 02:06 KST) - 완전 해결(Resolved).
- 잔여 로그 처리 및 대기열(Queue) 해소가 완료되었다. Cloudflare는 모든 시스템의 정상화를 선언했다.
원인 상세 분석[편집 / 원본 편집]
이번 사고는 전형적인 "검증 부재가 불러온 나비 효과"로 요약된다. 기술적으로는 데이터베이스 쿼리 실수와 배포 파이프라인의 안전장치 미비가 복합적으로 작용했다.
- 배경 (The Change)
- Cloudflare 엔지니어들은 봇 탐지 정확도를 높이기 위해 봇 신호(Bot Signal)를 처리하는 내부 데이터베이스(ClickHouse 기반)의 스키마를 변경하고 있었다. 이는 통상적인 작업이었다.
- 실수 (The Bug)
- 변경된 데이터베이스 구조에 맞춰 구성 파일(Config)을 생성하는 SQL 쿼리를 업데이트해야 했으나, 권한 설정 오류로 인해 필터링 조건(WHERE 절)이 무시되는 버그가 발생했다.
- 즉, "특정 악성 봇 규칙"만 가져와야 할 쿼리가 데이터베이스에 있는 모든 이력 데이터를 긁어오게 되었다.
- 검증 실패 (Validation Gap)
- 생성된 구성 파일(`rules_v2.bin`)의 크기는 평소 약 20KB 수준이었으나, 버그로 인해 500MB가 넘는 거대 파일이 생성되었다.
- 문제는 배포 파이프라인(CI/CD)에 "구성 파일 크기가 너무 크면 배포를 중단한다"는 검증 로직이 없었다. 시스템은 이를 정상적인 업데이트로 간주하고 전 세계 수만 대의 서버로 전송했다.
- 재앙 (The Crash)
- 각 지역의 엣지 서버(Edge Server)에 있는 프록시 데몬(Daemon)이 이 파일을 수신하고 메모리에 로드(Load)를 시도했다.
- 500MB짜리 구조체를 파싱하여 메모리에 올리는 과정에서 힙(Heap) 메모리가 고갈되었고, 리눅스 커널의 OOM Killer가 해당 프로세스를 강제로 죽여버렸다.
- 워치독(Watchdog) 프로그램이 죽은 프로세스를 다시 살려냈지만, 살아나자마자 다시 거대 파일을 읽고 죽는 과정이 초당 수십 번 반복되었다.
피해 규모[편집 / 원본 편집]
Cloudflare는 전 세계 웹 트래픽의 약 20%를 처리하는 거대한 허브이기 때문에, 그 피해는 광범위했다.
- 주요 서비스 중단:
사후 조치 및 반응[편집 / 원본 편집]
Cloudflare의 대응[편집 / 원본 편집]
사건 발생 3일 후, Cloudflare는 매우 상세한 기술적 사후 분석(Post-mortem)을 블로그에 공개했다. CEO 매튜 프린스(Matthew Prince)는 트위터를 통해 "변명의 여지가 없다. 우리의 테스트 절차에 구멍이 있었다"며 사과했다.
Cloudflare는 다음과 같은 재발 방지 대책을 발표했다.
- 최대 파일 크기 제한(Hard Limit) 도입: 구성 파일이 일정 크기를 초과하면 배포 파이프라인 단계에서 즉시 실패(Fail) 처리하도록 수정.
- 카나리아 배포(Canary Release) 강화: 모든 설정 변경 사항은 내부 테스트베드 → 소규모 PoP → 지역 → 전 세계 순으로 시차를 두고 배포되도록 강제화. (이전에도 있었으나 긴급 패치 경로에서 일부 생략되었던 것을 수정)
- 장애 복구 모드(Panic Mode) 개선: 중앙 제어 시스템이 마비되더라도 엣지 서버가 자동으로 "마지막으로 성공한 설정(Last Known Good)"으로 롤백하는 로직 추가.
여담 및 반응[편집 / 원본 편집]
- "또 너냐?": 2020년, 2022년에 이어 2025년에도 유사한 '설정 오류'로 인한 대형 사고가 터지자 IT 커뮤니티에서는 "인터넷의 왕(Cloudflare)이 재채기를 하면 전 세계가 감기에 걸린다"는 농담 아닌 농담이 돌았다.
- Hacker News와 Reddit의 r/sysadmin 게시판은 아수라장이 되었다. 특히 "회사 서버가 다운됐는데 내가 고칠 수 있는 게 없어서(Cloudflare 문제라서) 오히려 마음 편하게 퇴근했다"는 반응과 "고객사 전화 받느라 지옥을 맛봤다"는 반응이 공존했다.
- 장애 시간 동안 인터넷 트래픽이 급감하자, 일부 인터넷 서비스 제공자(ISP)들은 대역폭 여유분이 넘쳐나는 기현상이 발생하기도 했다.
- 이 사건의 여파로 경쟁사인 AWS CloudFront나 Fastly의 주가가 일시적으로 상승하는 모습을 보였다.
관련 문서[편집 / 원본 편집]
- Cloudflare
- CDN
- 단일 실패 지점 (SPOF)
- 2022년 6월 Cloudflare 장애 - 유사한 원인(라우팅 설정 오류)으로 발생했던 사건.
- 사건 사고 관련 정보
- 인프라 엔지니어링