[1편] “우리 서비스가 잘못된 줄 알았다” 개발자들을 멘붕시킨 클라우드플레어 네트워크 장애 분석

-
[1편] “우리 서비스가 잘못된 줄 알았다” 개발자들을 멘붕시킨 클라우드플레어 네트워크 장애 분석

[1편] “우리 서비스가 잘못된 줄 알았다”
개발자들을 멘붕시킨 클라우드플레어 네트워크 장애 분석

2025년 11월 18일, 12월 5일.
많은 개발자·기획자들이 모니터 앞에서 이렇게 외쳤을 것입니다.

“아… 또 우리 코드가 문제인 줄 알고 롤백할 뻔했네.”

서론 – 장애 알람은 울리는데, 우리 로그는 멀쩡한 그날

글로벌 CDN·보안 기업 클라우드플레어(Cloudflare)는 이제 “인터넷의 인프라”라고 불릴 정도로 많은 서비스의 앞단을 맡고 있습니다. 덕분에 빠르고 안전한 웹을 누리는 대신, 클라우드플레어가 멈추면 우리 서비스도 같이 멈추는 구조가 된 곳이 많습니다.

2025년 11월 18일과 12월 5일, 불과 보름 간격으로 두 번이나 글로벌 장애가 발생했습니다.
체감상 “인터넷이 반쯤 멈춘 것 같은 날”이었고, 수많은 개발자와 기획자가 이런 상황을 겪었습니다.

  • APM·모니터링 알람은 폭주하는데
  • 우리 애플리케이션 로그·DB는 멀쩡하고
  • 알고 보니 클라우드플레어 구간에서 500 오류를 마구 뿜던 날

이 1편에서는 두 사건을 타임라인과 기술적인 원인을 중심으로 정리합니다.

  • 2025-11-18: Bot Management 버그로 인한 3시간짜리 대규모 장애
  • 2025-12-05: 취약점 패치 중 방화벽 설정 변경이 만든 25분짜리 장애
    Cloudflare, CDN 장애 이미지

1. 두 번의 장애, 먼저 타임라인부터 훑어보기

1) 2025년 11월 18일 장애 (대략 3시간 이상)

  • UTC 기준 11:28 전후부터, Cloudflare를 경유하던 트래픽에서 대량의 HTTP 5xx 오류 발생
  • ChatGPT, X(트위터), Canva, Shopify, 각종 게임·금융·공공 사이트 접근 장애
  • 클라우드플레어 대시보드·로그인조차 영향을 받아, 운영자들도 상황 파악에 애를 먹음
  • 국내에서도 여러 서비스가 한동안 접속 불안정 또는 완전 장애 상태를 경험
  • 최종적으로는 Bot Management 구성 파일 생성 로직 버그가 원인으로 확인되고, 파일 롤백 및 시스템 완화 조치 후 복구

2) 2025년 12월 5일 장애 (약 25분)

  • UTC 08:47 ~ 09:12 사이, Cloudflare 네트워크 일부에서 심각한 장애 발생 (약 25분)
  • Cloudflare가 처리하던 전체 HTTP 트래픽의 약 28%가 영향을 받을 정도로 큰 규모
  • Zoom, LinkedIn, Canva, Shopify, 각종 트레이딩·예약·디자인 서비스 등에서 500 오류 다수 발생
  • 이번에는 React Server Components 취약점 완화를 위해 WAF 버퍼 설정을 조정하던 중 구성 변경이 트리거가 됨
  • “취약점 패치 → 내부 테스트 도구 비활성화 → 글로벌 구성 시스템을 통한 변경 배포 → FL1 프록시에서 Lua 예외 발생 → 500 오류 폭발”이라는 흐름

한마디로 요약하면, 11월은 Bot Management, 12월은 WAF(방화벽) 쪽 변경이 전 세계를 덮친 사건입니다.

2. 11월 18일 – Bot Management 피처 파일 버그가 만든 3시간짜리 악몽

2-1. 어떤 일이었나?

클라우드플레어는 봇 트래픽을 구분하기 위해 Bot Management라는 기능을 제공합니다. 여기에는 머신러닝 모델, 피처(feature) 파일, 봇 점수 계산 로직 등이 들어 있습니다.

문제의 시작은 피처 구성 파일을 만드는 ClickHouse 쿼리 동작을 바꾼 것이었습니다. 이 변경 때문에 피처 파일에 중복 행이 대량으로 포함되면서, 기존에 가정하던 “피처 개수 제한”을 넘겨버렸습니다.

2-2. 기술적인 핵심 포인트를 정리하면

  • Bot Management가 사용하는 피처 구성 파일이 자동으로 생성·배포되는데,
  • 쿼리 동작 변경으로 이 파일의 크기와 피처 수가 폭증
  • 프록시 모듈은 “피처는 최대 N개”라고 가정하고 메모리를 사전 할당하는데, 이 가정이 깨지면서 패닉 발생
  • 새로운 FL2 프록시에서는 5xx 오류로 이어졌고, 기존 FL 프록시는 봇 점수를 0으로만 주는 이상 동작 발생
  • 결과적으로 Bot Management에 의존하는 거의 모든 트래픽이 영향을 받는 상태가 됨

2-3. 영향 범위

언론 보도와 클라우드플레어 발표를 종합하면, 이번 장애는 2019년 이후 가장 큰 규모의 중단이었습니다.

  • Cloudflare를 사용하는 주요 웹·앱 서비스에서 대량의 5xx 오류 발생
  • Workers KV, Access, Turnstile 등 내부적으로 프록시에 의존하는 서비스들도 연쇄 영향
  • 일부 구간은 3시간 이상 불안정한 상태가 이어지며, 전 세계적으로 “인터넷이 느려진 날”로 기억될 수준

3. 12월 5일 – 취약점 패치 중 방화벽 설정 변경이 만든 25분짜리 대형 장애

3-1. 취약점 패치 과정에서 발생한 장애

12월 5일 사고의 출발점은 React Server Components 관련 CVE 취약점이었습니다. Cloudflare는 고객을 보호하기 위해 WAF에서 HTTP 요청 본문 버퍼 크기를 늘리고, 내부 테스트 도구를 비활성화하는 변경을 진행했습니다.

문제는 두 번째 변경, 즉 “테스트 도구를 글로벌 구성 시스템에서 비활성화”하는 과정에서 터졌습니다. 이 변경이 특정 프록시 버전(FL1)에서 Lua 예외를 발생시키는 버그를 건드린 겁니다.

3-2. 타임라인 핵심

  • 08:47 UTC – 구성 변경이 전체 네트워크에 전파되기 시작, 장애 발생
  • 08:48 – 최대 영향 구간, HTTP 500 오류 폭발
  • 08:50 – 내부적으로 사고 선언 및 대응 시작
  • 09:11 – 변경 롤백 시작
  • 09:12 – 트래픽 정상화, 장애 종료 (총 약 25분)

이 25분 동안, Cloudflare 네트워크에서 처리되던 HTTP 트래픽의 약 28%가 영향을 받으며 LinkedIn, Zoom, Canva, Shopify, 각종 게임·금융 서비스가 줄줄이 500 오류를 띄웠습니다.

3-3. “보안을 위한 변경이 가용성을 때린” 전형적인 사례

이번 사건이 특히 씁쓸한 이유는, 고객을 보호하기 위한 보안 패치 작업이 오히려 전 세계 가용성을 때린 사례라는 점입니다. “아무것도 안 해서 문제”가 아니라 “좋은 걸 하다가 크게 맞은” 전형적인 장애 패턴입니다.

4. 다음 글(2편) 예고 – 우리가 배워야 할 것들

1편에서는 11월 18일과 12월 5일 장애를 사실과 원인 중심으로 정리했습니다.
이어지는 2편에서는 다음 내용을 다룹니다.

  • 두 장애의 공통점과 차이점
  • 장애 당시, 현장에서 개발자·기획자가 실제로 겪는 상황
  • IT 기획자·SRE가 가져가야 할 실무 인사이트와 체크리스트
  • 클라우드플레어 장애 대비 체크리스트 8가지
  • 결론 및 FAQ

2편 링크: [2편] “우리 서비스가 잘못된 줄 알았다” 클라우드플레어 장애에서 IT 기획자가 배운 것들

출처 및 참고 자료