# Cloudflare 2025년 12월 5일 장애

> Clean Markdown view of GeekNews topic #24867. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=24867](https://news.hada.io/topic?id=24867)
- GeekNews Markdown: [https://news.hada.io/topic/24867.md](https://news.hada.io/topic/24867.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2025-12-06T09:46:46+09:00
- Updated: 2025-12-06T09:46:46+09:00
- Original source: [blog.cloudflare.com](https://blog.cloudflare.com/5-december-2025-outage/)
- Points: 1
- Comments: 1

## Topic Body

- 2025년 12월 5일 08:47 UTC에 **Cloudflare 네트워크 일부가 심각한 장애**를 겪었으며, 약 25분 후인 09:12에 완전히 복구됨  
- 전체 **HTTP 트래픽의 약 28%** 가 영향을 받았고, 특정 조건을 만족한 고객만 장애를 경험함  
- 원인은 **React Server Components 취약점(CVE-2025-55182)** 대응 중 수행된 **WAF(body parsing logic) 변경**으로, 사이버 공격과는 무관함  
- **FL1 프록시의 코드 오류**로 인해 HTTP 500 오류가 발생했으며, 새 **Rust 기반 FL2 프록시**에서는 동일 오류가 발생하지 않음  
- Cloudflare는 11월 18일 장애 이후에도 유사한 문제가 반복된 점을 인정하고, **배포 안전성·복원력 강화 프로젝트**를 최우선 과제로 진행 중임  

---

### 장애 개요
- 2025년 12월 5일 08:47 UTC에 Cloudflare 네트워크 일부에서 장애 발생  
  - 09:12에 모든 서비스 복구, 총 25분간 영향  
  - 전체 HTTP 트래픽의 약 28%가 영향을 받음  
- 장애는 **사이버 공격이나 악의적 행위와 무관**, 내부 설정 변경 중 발생  
- React Server Components의 신규 취약점 대응을 위한 **WAF 본문 파싱 로직 수정**이 원인  

### 장애 원인 및 기술적 배경
- Cloudflare WAF는 악성 페이로드 탐지를 위해 **HTTP 요청 본문을 메모리에 버퍼링**  
  - 기존 버퍼 크기 128KB에서 1MB로 확장 중이었음  
- 내부 테스트 도구가 새 버퍼 크기를 지원하지 않아 **테스트 도구를 비활성화하는 두 번째 변경**을 수행  
  - 이 변경은 **전역 설정 시스템**을 통해 즉시 전체 서버에 전파됨  
- FL1 프록시에서 이 변경이 **오류 상태를 유발**, HTTP 500 응답 발생  
  - 오류 메시지: `attempt to index field 'execute' (a nil value)`  
- 문제는 즉시 식별되어 09:12에 변경이 되돌려짐  

### 영향 범위
- **FL1 프록시**를 사용하고 **Cloudflare Managed Ruleset**을 적용한 고객만 영향  
  - 해당 사이트의 모든 요청이 HTTP 500 오류 반환  
  - `/cdn-cgi/trace` 등 일부 테스트 엔드포인트는 예외  
- 중국 네트워크 및 다른 구성의 고객은 영향 없음  

### 런타임 오류 상세
- Cloudflare의 **rulesets 시스템**은 요청마다 규칙을 평가  
  - 규칙은 필터와 액션으로 구성되며, `execute` 액션은 다른 규칙 세트를 호출  
- 내부 로깅 시스템이 `execute`를 사용해 테스트 규칙을 평가  
- **killswitch 시스템**이 오작동 규칙을 비활성화하도록 설계되어 있으나,  
  - `execute` 액션이 포함된 규칙에 killswitch를 적용한 것은 이번이 처음  
- `execute` 객체가 존재하지 않는 상태에서 접근 시도하여 **Lua 오류 발생**  
- 이 오류는 **수년간 존재했으나 탐지되지 않았던 단순 코드 버그**  
  - **Rust로 작성된 FL2 프록시**에서는 동일 오류가 발생하지 않음  

### 11월 18일 장애 이후의 개선 진행 상황
- 11월 18일에도 유사한 **전역 배포로 인한 광범위 장애** 발생  
- 당시 고객 수백 명과 직접 소통하며 **단일 업데이트의 전면 확산 방지 계획**을 공유  
- 해당 개선 작업이 아직 완료되지 않아 이번 장애에 영향을 미침  
- Cloudflare는 이를 **조직 전체의 최우선 과제**로 지정  

### 진행 중인 복원력 강화 프로젝트
- **Enhanced Rollouts & Versioning**  
  - 위협 대응용 데이터 및 설정 변경에도 **점진적 배포·건강 검증·신속 롤백 기능** 적용  
- **Streamlined Break Glass Capabilities**  
  - 내부 서비스 및 제어 플레인 상호작용 시에도 **비상 조작 가능성 확보**  
- **Fail-Open 오류 처리**  
  - 구성 파일 오류 시 요청을 차단하지 않고 **기본 정상 상태로 전환하거나 트래픽 통과**  
  - 일부 서비스는 **fail-open/fail-closed 선택 옵션** 제공 예정  
- 다음 주 내에 모든 복원력 프로젝트의 세부 내역 공개 예정  
- 그 전까지 **네트워크 변경을 전면 중단(lockdown)** 상태로 유지  

### 타임라인 (UTC)
- 08:47 – 구성 변경 배포 및 네트워크 전파 시작  
- 08:48 – 전체 영향 발생  
- 08:50 – 자동 경보로 사고 선언  
- 09:11 – 변경 되돌리기 시작  
- 09:12 – 복구 완료, 모든 트래픽 정상화  

### 결론
- Cloudflare는 **두 차례 연속된 장애의 심각성**을 인정하고 고객 및 인터넷 전체에 사과  
- 향후 **배포 안전성, 오류 허용성, 복원력 강화**를 통해 유사 사고 방지 계획 추진

## Comments



### Comment 47290

- Author: neo
- Created: 2025-12-06T09:46:47+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46162656)   
- 이번 **Cloudflare 장애**는 단순한 Lua 버그가 아니라, 근본적인 **아키텍처 문제**를 드러낸 사건임  
  원래의 분산형 웹 구조는 이런 전역 장애에 훨씬 강했음. 반면 Cloudflare처럼 **동질적인 중앙집중형 시스템**은 한 번의 실수로 전 세계 서비스가 동시에 멈출 수 있음. Rust로 짜도 사람은 실수함. 결국 **견고한 설계**가 중요함  
  - 결국 Cloudflare나 AWS 같은 거대 사업자에 의존할수록 웹의 **안정성**이 떨어진다는 뜻임  
  - “말벌 1,000마리 vs 개 1마리” 비유처럼, 전역 장애든 지역 장애든 고통의 형태만 다를 뿐임. Cloudflare가 멈추면 수백 명의 엔지니어가 즉시 대응하지만, 내 서버가 멈추면 담당자는 산속 별장에 있을 수도 있음  
  - 독점이 나쁘다는 논의는 제쳐두고, Cloudflare의 **장기적 가동률**을 보면 오히려 개별 사이트가 직접 인프라를 운영하는 것보다 낫다고 봄. 모든 서비스가 동시에 1시간 멈추는 게, 각각 따로따로 1시간씩 멈추는 것보다 사용자 입장에서는 낫다는 논리임. 다만 Cloudflare의 **안정성이 평균 이하**로 떨어진다면 그 가치는 사라짐  
  - 초당 8천만 요청을 처리하는 규모라면, 애초에 **하나의 제품이 이렇게 커지는 구조** 자체가 문제라고 생각함  
  - Cloudflare는 여전히 전 세계 어디서나 가장 빠르게 **글로벌 인프라를 복구**하는 회사 중 하나임. 이번에도 28% 네트워크 장애를 25분 만에 해결했고, 다른 클라우드보다 **다운타임이 객관적으로 적음**  
  
- 어젯밤 Cloudflare 500 오류를 여러 사이트에서 봤음. 그런데 **상태 페이지**에는 아무 언급이 없고, 예정된 유지보수 공지만 있었음  
  - 대부분의 상태 페이지가 그렇듯, 실제 문제를 인식하고 업데이트하기까지 시간이 걸림. 완전 자동화되기 전까지는 Cloudflare도 예외가 아님. 더 걱정되는 건 최근 **AWS, Azure, Cloudflare**가 연달아 다운된 점임. 내 직감으로는 LLM 사용 증가, 인력 부족, 팬데믹 여파, 정치적 불안 등이 복합적으로 작용하는 듯함  
  - 이런 상태 페이지 문제는 **공개적인 비판**을 통해서만 개선될 것 같음. “Cloudflare는 장애 감지조차 제대로 못 한다”는 피드백이 많아져야 함  
  
- Cloudflare의 **품질 엔지니어링**이 생산 속도를 따라가지 못하는 듯함. 예전 방산업계에서는 품질팀이 항상 더 숙련됐다고 들었는데, 소프트웨어 업계는 반대인 것 같음  
  - 방산업계에서도 **메모리 누수**를 알고도 “사용 시간 내엔 문제없다”며 무시한 적이 있었다는 일화가 떠오름  
  - 이런 일이 한 달에 두 번 일어났는데 “칭찬할 일”은 아님. 반복은 변명의 여지가 없음  
  
- 인터넷의 **패킷 스위칭 구조**는 원래 이런 전역 장애를 견디도록 설계된 것임.  
  냉전 시절 **DARPA 네트워크**는 핵 공격 상황에서도 지휘 체계를 유지하려는 목적이 있었음.  
  지금이야말로 인터넷의 **로컬 우선(local-first)** 패러다임으로 돌아가야 할 때임  
  - 참고: [The Real Internet Architecture](https://press.princeton.edu/books/paperback/9780691255804/the-real-internet-architecture)  
  - 참고: [Local-first software](https://www.inkandswitch.com/essay/local-first/)  
  
- 최근 Cloudflare가 인터넷을 더 **느리고 불편하게** 만들고 있다고 느낌. “당신이 인간임을 증명하세요” 같은 절차가 늘었고, 페이지 로딩도 지연됨.  
  이는 사이트 보호보다는 **AI 크롤링 과금 정책** 때문인 듯함 ([Pay-per-crawl 소개](https://blog.cloudflare.com/introducing-pay-per-crawl/))  
  - 이런 인간 인증 절차가 **구형 브라우저**와 호환되지 않아, 아예 접근이 불가능한 사이트도 생김  
  - 하지만 AI가 무단으로 콘텐츠를 긁어가는 것도 문제임. Cloudflare는 사이트 주인에게 **콘텐츠 보호 옵션**을 제공하는 셈이고, 원치 않으면 끌 수도 있음  
  - “이제는 우리를 몰래 감시조차 못 하네”라는 냉소도 나옴  
  
- Cloudflare의 **전역 설정 시스템**이 점진적 롤아웃 없이 몇 초 만에 전체 네트워크로 퍼지는 구조라 위험함.  
  설정 변경이 오류를 일으킬 때 즉시 상관관계를 파악할 수 있는 체계가 필요함  
  - 문제는 **경보가 너무 늦게 울린 것**임. 2분 만에 알림이 왔는데, 초 단위로 감지했어야 함.  
    배포 담당자는 실시간 지표를 보며 즉시 **롤백 버튼**을 눌렀어야 함.  
    코드 라인까지 명확히 로그에 찍혔는데, 배포팀과 코드 이해팀이 **단절**돼 있었던 듯함  
  - 경고 신호를 보고 롤백을 시도했는데, 그 과정이 오히려 문제를 일으킨 것으로 보임  
  - 내부 도구는 종종 **오탐지**가 많고, 스스로 깨져 있는 경우도 많음  
  - “엔진 경고등이 계속 켜지길래 그냥 전구를 뽑았다”는 농담처럼 들림  
  
- Cloudflare의 **가동률이 99.9% 아래**로 떨어졌음. 내 집 PC보다 못한 수준임  
  - AWS도 마찬가지임. 클라우드의 존재 이유가 “더 높은 가용성”인데, 비싸고 불안정하다면 **직접 호스팅**할 이유가 충분함  
  - 하지만 자가 호스팅은 하드웨어 고장이나 백업 실패 시 **복구에 며칠** 걸릴 수도 있음  
  - 지역 정전이 잦은 곳에서는 노트북과 배터리로 버티기도 힘듦. 가끔은 **자급자족형 인프라**를 꿈꾸기도 함  
  - 현재 Cloudflare의 정확한 **업타임 통계**를 어디서 확인할 수 있는지 궁금함  
  - 그래도 개인 PC와 Cloudflare를 단순 비교하는 건 **무의미한 비유**임  
  
- Cloudflare 규모라면 반드시 **테스트 환경**이 있어야 함.  
  모든 변경은 격리된 모델 환경에서 시뮬레이션 후 점진적으로 배포해야 함.  
  **강한 타입 시스템**보다 중요한 건 **절차적 안전장치**임  
  - 우리 회사는 세 단계 배포 체계를 씀: 개발 → 내부 통합 → 프로덕션.  
    실수 잦은 팀은 속도를 늦추고, 신뢰도 높은 팀은 빠르게 진행함.  
    결국 **기술적 속도는 선택의 문제**임. SLA 위협이 생기면 속도를 줄이고 테스트를 강화해야 함  
  - 무료 사용자들을 **테스트 베드**로 삼고, 유료 고객에게는 안정된 버전을 제공하는 것도 방법임  
  - “강한 타입 시스템이 널 구해주지 않는다”는 말은, **절차적 실패** 앞에서는 언어가 무력하다는 뜻임  
  
- Cloudflare의 **소프트웨어 품질**이 흔들리는 듯함.  
  엔터프라이즈 전용 기능의 접근 검증이 **마지막 단계**에서만 이뤄지는 버그도 있었음  
  - 나도 Cloudflare API에서 **롤백이 불가능한 설정**을 경험했음.  
    지원팀을 거쳐야만 변경 가능했고, 수정까지 며칠 걸렸음  
    [관련 사례 링크](https://www.answeroverflow.com/m/1234405297787764816)  
  - 이런 버그는 **AI가 작성한 코드**일 가능성도 있다고 봄  
  - “마지막 단계에서만 체크한다”는 게 무슨 뜻인지 더 구체적으로 듣고 싶음  
  
- Cloudflare의 **운영 문화**가 궁금함.  
  보안 이슈 대응 중 오류가 발생했는데, 롤백 대신 **전역 배포**를 또 진행했다는 건 위험한 결정임.  
  “의심스러우면 롤백하라”는 기본 원칙을 어긴 셈임  
  - 다만 이번은 **React Server RCE 취약점** 대응처럼 긴급한 상황이었음.  
    배포를 늦추면 고객이 실제로 해킹당할 수 있었기에, **속도가 곧 보안**이 되는 케이스였음  
  - 롤백이 항상 정답은 아님. **절차가 익숙하지 않으면** 그 자체가 리스크가 됨  
  - 사실 두 번의 배포는 **서로 다른 컴포넌트**였음.  
    첫 번째 수정이 두 번째의 잠재 버그를 드러낸 셈이라, **롤백보다 전진 배포(roll forward)** 가 더 현실적일 때도 있음  
  - Cloudflare는 빠른 성장 속에서 **기술 부채**를 쌓아왔을 가능성이 큼.  
    최근의 잦은 장애는 그 부채가 드러나는 신호일 수 있음