Cloudflare의 11 월 18 일 Outage - 요약

2025년 11월 18일, 인터넷의 거대한 부분이 무너졌습니다.
ChatGPT, X(트위터), 리그 오브 레전드, Shopify, 코인베이스 또는 수많은 소규모 사이트를 열면 Cloudflare 브랜드의 5xx 오류 페이지가 표시되거나 사이트가 전혀 로드되지 않았습니다. 처음에는 "인터넷이 망가졌다"는 또 다른 큰 문제처럼 보였던 것이 알고 보니 Cloudflare의 자체 인프라 내부에서 발생한 자해성 버그인 것으로 밝혀졌습니다.

아래에서 어제(2025년 11월 18일) 발생한 Cloudflare 서비스 중단의 원인, 발생 이유, 영향을 받은 사람, 인프라 팀이 이로부터 얻어야 할 교훈에 대해 자세히 살펴보세요.

어제 실제로 무슨 일이 있었나요?

2025년 11월 18일 화요일, 늦은 아침(UTC) 무렵, Cloudflare는 네트워크를 통과하는 트래픽에 대해 대량의 HTTP 5xx 서버 오류를 반환하기 시작했습니다. 최종 사용자에게는 많은 인기 웹사이트와 앱에 액세스하려고 할 때 "내부 서버 오류" 또는 "게이트웨이 오류" 페이지가 표시되는 것을 의미했습니다.

Cloudflare의 사고 발생 후 블로그에 따르면, 서비스 중단은 다음과 같이 시작되었습니다:

• 11:28 UTC에 고객 HTTP 트래픽에 영향을 미치기 시작함

• 핵심 CDN 및 보안 서비스 전반에 걸쳐 5xx 오류가 광범위하게 발생했습니다.

• 13:05-14:30경(UTC) 주요 완화 조치 실시

• 17:06 UTC에 5xx 오류 볼륨을 기준선으로 복귀시킴 Cloudflare 블로그

Cloudflare는 이 장애가 단순히 하나의 기능이나 대시보드에만 영향을 미친 것이 아니라 네트워크를 통해 대부분의 고객 트래픽을 라우팅하는 핵심 프록시 계층을 중단시켰기 때문에 2019년 이후 최악의 장애라고 설명했습니다. Cloudflare 블로그

타사 모니터링이 이를 뒷받침했습니다. Cisco ThousandEyes는 네트워크 경로 자체는 정상적으로 보였지만 X, OpenAI(ChatGPT), Anthropic과 같은 서비스에서 시간 초과 및 5xx 오류가 발생하면서 Cloudflare에 영향을 미치는 글로벌 서비스 중단을 목격했습니다. 이는 ISP 수준이나 라우팅 문제가 아닌 백엔드 서비스 장애를 강력하게 시사하는 것이었습니다. ThousandEyes

누가 영향을 받았나요?

Cloudflare는 인터넷의 상당 부분을 차지하고 있기 때문에( 웹 사이트의 약 20%가 성능과 보안을 위해 Cloudflare에 의존하고 있음), 폭발 반경이 엄청나게 넓었습니다. AP News+1

영향을 받은 것으로 보고된 서비스 중

• ChatGPT / OpenAI

• X(이전의 트위터)

• Canva, Shopify, Dropbox, Coinbase

• 리그 오브 레전드 및 기타 게임 플랫폼

• 뉴저지 트랜짓과 프랑스 SNCF 철도 디지털 시스템을 포함한 다양한 대중교통 및 정부 사이트 AP News+1

다운디텍터와 같은 정전 추적기는 최고조에 달했을 때 수천 건의 동시 문제 보고를 기록했습니다. 로이터 통신은 한때 X에서만 약 5,000명의 사용자가 영향을 받았다고 보고했지만, 수정 사항이 배포되면서 그 수가 감소했습니다. Reuters

사용자 관점에서 보면 다음과 같이 나타났습니다:

• 사이트가 전혀 로드되지 않음

• 로그인 흐름이 중단되거나 실패하는 경우(특히 Cloudflare Access 또는 Turnstile이 관련된 경우)

• 간헐적으로 또는 5xx 오류로 응답하는 API

• 대시보드 및 관리자 패널의 시간 초과

즉, 근본 원인이 단일 제공업체의 내부 시스템에 집중되어 있음에도 불구하고 인터넷의 상당 부분이 "다운된 느낌"을 받았습니다.

Cloudflare의 정상 작동 방식(간단한 용어)

이번 서비스 중단이 왜 그렇게 심각했는지 이해하려면 Cloudflare 네트워크를 통한 요청의 대략적인 경로를 파악하는 것이 도움이 됩니다.

Cloudflare는 역방향 프록시 CDN 및 보안 계층 역할을 합니다:

1. 브라우저 또는 앱이 원본 사이트에 직접 연결하는 대신 Cloudflare에 연결합니다.

2. Cloudflare는 에지에서 TLS 및 HTTP를 종료합니다.

3. 요청은 FL("프론트라인 ") 및 최신 세대 FL2라고 하는 Cloudflare의 핵심 프록시 시스템으로 흐릅니다.

4. 이 핵심 프록시:

   • WAF(웹 애플리케이션 방화벽) 규칙 적용

   • 봇 관리 모델 실행

   • DDoS 보호, 캐싱, 오리진으로의 이그레스 처리

   • Workers, R2, Access 등과 같은 다른 내부 제품으로 트래픽을 라우팅합니다. Cloudflare 블로그

한 데이터 센터에 문제가 발생하면 다른 데이터 센터를 통해 트래픽을 라우팅하고, 구성 변경을 신중하게 적용하며, 개별 기능에 장애가 발생하면 제어된 방식으로 장애를 처리하는 등 정상적인 운영에서는 이 아키텍처의 복원력이 매우 높습니다.

어제 발생한 장애는 공통 프록시 경로 자체에 장애가 발생했고, 전 세계적으로 자주 자동으로 푸시되는 구성 파일과 긴밀하게 연결되어 있었기 때문에 정확하게 나쁜 일이었습니다.

근본 원인: 불량 봇 관리 기능 파일

Cloudflare의 공식 설명은 한 가지 주요 원인을 지적합니다:
봇 관리 시스템에서 사용하는 기능 구성 파일입니다. Cloudflare 블로그

사건의 연쇄를 쉽게 설명하면 다음과 같습니다:

1. 봇 관리는 "기능 파일"을 사용합니다.

   • Cloudflare의 봇 탐지 모델은 사람인지 봇인지 판단하는 데 사용되는 각 요청에 대한 신호인 "기능" 집합에 의존합니다.

   • 이러한 기능은 몇 분마다 재생성되고 전 세계에 배포되는 구성 파일에 번들로 제공되므로 Cloudflare는 새로운 공격 패턴에 빠르게 적응할 수 있습니다. Cloudflare 블로그

2. ClickHouse 쿼리 동작의 변경

   • 기능 파일은 ClickHouse 데이터베이스에 대한 쿼리에 의해 생성됩니다.

   • Cloudflare는 분산 쿼리에 대한 보안 및 권한을 개선하기 위해 11:05경(UTC) 사용자가 기본 스키마뿐만 아니라 기본 r0 테이블의 메타데이터도 볼 수 있도록 변경했습니다. Cloudflare 블로그

   • 기능 목록을 작성하는 쿼리가 데이터베이스 이름별로 필터링되지 않고 갑자기 기본 및 r0에서 중복 열을 가져오기 시작하여 기능 행의 수가 두 배로 늘어났습니다.

3. 피처 파일의 크기가 폭발적으로 증가함

   • 봇 관리 모듈에는 수용 가능한 기능 수에 대한 엄격한 제한이 있습니다(일반적으로 사용되는 최대 60개보다 훨씬 많은 200개로 설정됨).

   • 새로 생성된 파일이 이 제한을 초과하자 모듈은 오류 값에 Result::unwrap()을 사용한 Rust 코드에서 처리되지 않은 오류로 인해 한도에 도달하여 당황했습니다. Cloudflare 블로그

4. 핵심 프록시 서비스가 5xx 오류를 반환하기 시작함

   • 봇 관리가 코어 프록시 경로에 통합되어 있기 때문에, 해당 모듈에 의존하는 모든 트래픽에 대한 HTTP 5xx 응답으로 패닉이 나타났습니다.

   • 새로운 FL2 엔진에서 고객들은 명시적인 5xx 오류를 목격했습니다.

   • 구형 FL 엔진에서는 봇 점수가 자동으로 0이 되어 봇 차단 규칙에서 오탐을 일으킬 수 있었습니다. Cloudflare 블로그

5. 정말 끔찍한 부분: 파일이 "양호"와 "불량" 사이를 계속 넘나듦

   • ClickHouse 클러스터는 점진적으로 업데이트되고 있었고, 기능 파일은 5분마다 다시 생성되었습니다.

   • 때로는 업데이트된 노드(나쁜 파일 생성)에서 쿼리가 실행되기도 하고, 때로는 업데이트되지 않은 노드(좋은 파일 생성)에서 쿼리가 실행되기도 했습니다.

   • 즉, 한동안 Cloudflare의 네트워크는 서로 다른 버전의 파일이 전파되면서 정상 작동과 장애 사이에서 진동했습니다. Cloudflare 블로그

이러한 진동은 내부적으로 상황을 매우 혼란스럽게 만들었습니다. 처음에는 오류 패턴이 단순한 소프트웨어 충돌처럼 보이지 않았기 때문에 Cloudflare 팀은 대규모 DDoS 공격을 의심했습니다. 자체 인프라 외부에서 호스팅되는 Cloudflare 상태 페이지에서도 잠시 오류가 발생했는데, 이는 우연의 일치로 외부 공격에 대한 의심을 더욱 부추겼습니다. Cloudflare 블로그+1

공통 요소가 봇 기능 파일이라는 사실을 알게 된 후에야 상황은 명확해졌습니다.

사건의 타임라인

Cloudflare의 사후 조사 및 타사 보고서를 바탕으로 2025년 11월 18일의 대략적인 타임라인을 정리할 수 있습니다: Cloudflare 블로그+2ThousandEyes+2

• 11:05 UTC - ClickHouse에 데이터베이스 액세스 제어 변경이 배포됨.

• 11:20-11:30(UTC ) - 봇 관리 기능 파일의 잘못된 버전이 생성 및 전파되기 시작합니다.

• 11:28 UTC - 첫 번째 고객 영향: 고객 트래픽에서 HTTP 5xx 오류 증가.

• 11:30-11:32 UTC - 외부 모니터링 도구와 자동화된 테스트가 간헐적인 장애를 감지하기 시작합니다.

• 11:35 UTC - Cloudflare가 내부 인시던트 콜을 열고 조사 시작.

• ~11:48 UTC - Cloudflare가 인시던트를 확인하는 상태 업데이트를 게시합니다. 재전송

• 11:30~13:05(UTC ) - 팀이 성능 저하로 보이는 Workers KV 동작에 집중하고 여러 가능한 원인(공격 시나리오 포함)을 조사합니다.

• 13:05 UTC - 주요 완화: 핵심 프록시를 우회하도록 Workers KV 및 Cloudflare Access가 전환되어 영향이 감소합니다. Cloudflare 블로그

• 14:30 UTC - 근본 원인 파악; 잘못된 기능 파일의 생성 및 전파가 중지되었습니다. 알려진 정상 구성 파일이 수동으로 삽입되고 코어 프록시가 다시 시작됩니다. 대부분의 코어 트래픽이 정상으로 돌아옵니다. Cloudflare 블로그

• 14:40-15:30 UTC - 턴스타일과 인증 시도의 백로그가 2차 부하 급증을 일으키면서 대시보드 및 로그인 문제가 지속됩니다. Cloudflare 블로그

• 17:06 UTC - 오류율이 기준선으로 돌아옴; Cloudflare는 시스템이 완전히 정상이라고 선언합니다. Cloudflare 블로그

사용자의 관점에서 볼 때, 서비스 중단은 UTC 기준 늦은 오전에서 이른 오후에 가장 심하게 느껴졌지만, 정확한 영향 기간은 지역과 각 서비스가 의존하는 Cloudflare 제품에 따라 다릅니다.

이번 서비스 중단이 중요한 이유

중앙 집중화 위험

Cloudflare는 주요 클라우드 플랫폼(AWS, Azure, GCP) 및 기타 대형 CDN과 함께 소규모 중앙 인터넷 인프라 제공업체의 일부입니다. 이러한 업체 중 하나에 장애가 발생하면 그 영향은 광범위하고 명확하지 않은 경우가 많습니다.

이번 서비스 중단은

• BGP 라우팅 사고나 ISP 케이블 단절로 인한 것이 아닙니다.

• (초기 의심과는 달리) 악의적인 공격으로 인한 것이 아닙니다.

• 내부 구성 요소의 단일 구성 및 제한 버그로 인해 발생했습니다.

이는 복잡하고 긴밀하게 연결된 시스템이 외부의 간섭 없이도 얼마나 치명적인 장애를 일으킬 수 있는지를 보여주기 때문에 중요합니다. 많은 조직이 동일한 공급업체를 기반으로 구축하면 해당 공급업체는 사실상 인터넷에서 시스템적으로 중요한 부분이 됩니다.

'소프트' 종속성 역시 피해

영향을 받은 서비스 중 일부는 단순히 Cloudflare를 단순한 CDN으로 사용하는 것이 아니었습니다. 실제로 그랬죠:

• 인증 및 제로 트러스트 액세스를 위해 Cloudflare Access 사용.

• 내부 제어 평면의 일부로 Workers KV 사용.

• 봇 방지 로그인을 위해 Turnstile을 사용합니다. Cloudflare 블로그+1

이러한 제품에 장애가 발생하면 웹사이트 콘텐츠만 다운되는 것이 아니라 로그인, 관리 기능, 내부 API도 중단됩니다. 상태 페이지, 인시던트 도구 또는 관리자 UI도 방금 장애가 발생한 바로 그 공급업체에 의존할 수 있기 때문에 복구가 더 복잡해집니다.

Cloudflare가 말하는 변경 사항

Cloudflare의 블로그에서는 유사한 문제가 반복되는 위험을 줄이기 위해 이미 취하고 있는 몇 가지 해결 단계에 대해 설명합니다: Cloudflare 블로그

1. 자동 생성 구성 파일 수집 강화
   롤아웃 전에 엄격한 스키마 및 크기 검사를 포함하여 내부적으로 생성된 구성을 사용자가 제공한 입력과 동일한 회의주의와 검증을 통해 처리합니다.

2. 더 많은 글로벌 킬 스위치
   문제가 있는 내부 모듈(예: 봇 관리)을 네트워크 전반에서 신속하게 비활성화하여 전체 프록시 경로를 패닉 상태로 만드는 대신 해당 모듈이 열리지 않도록 하세요.

3. 오류 폭풍으로부터 시스템 리소스 보호
   오류가 급증하기 시작할 때 코어 덤프, 디버그 메타데이터 및 통합 가시성 도구가 CPU와 메모리를 압도하지 않도록 하세요.

4. 코어 프록시 모듈 전반의 장애 모드 검토
   예기치 않은 입력 또는 구성에서 각 내부 모듈이 어떻게 작동하는지 체계적으로 감사하고, 전역 장애 대신 점진적인 성능 저하를 보장하세요.

5. 롤아웃 및 격리 개선
   이 인시던트는 자세히 설명하지는 않았지만, Cloudflare가 새로운 구성과 DB 동작이 전파되는 방식을 더욱 세분화하여 하나의 잘못된 변경이 전체 제품군에 영향을 미칠 가능성을 줄일 수 있음을 시사합니다.

또한 이 사건을 "용납할 수 없는" 사건으로 규정하고 고객과 일반 인터넷 사용자 모두에게 피해를 입힌 것을 명시적으로 인정하면서 복원력에 대한 기대에 완전히 실패한 사건으로 규정했습니다. Cloudflare 블로그

인프라 및 SRE 팀을 위한 교훈

Cloudflare와 같은 대규모 서비스를 운영하지 않더라도 이번 서비스 중단을 통해 매우 실용적인 설계 및 운영 교훈을 얻을 수 있습니다:

내부 구성을 신뢰할 수 없는 입력처럼 취급하세요

"자체적으로" 생성한 구성이 항상 정확하다고 생각하기 쉽습니다. 어제는 그것이 왜 위험한지 잘 보여줍니다:

• 구성 파일을 적용하기 전에 항상 크기, 모양, 제한을 확인해야 합니다.

• 작은 트래픽 또는 노드 하위 집합에 먼저 구성을 적용하고 이상 징후에 대해 자동으로 롤백하는 것을 고려하세요.

• 기능 수, 메모리 사전 할당, CPU 사용량에 대해 엄격한 상한선과 회로 차단기를 유지하세요.

부분적인 장애에 대비한 설계

봇 관리 모듈의 버그 하나로 인해 전체 프록시 경로가 패닉 상태에 빠지지 않아야 합니다:

• 일부 보안 레이어에서 장애 개방과 장애 폐쇄를 기본값으로 설정하여 완전한 중단이 발생했을 때를 대비하세요.

• 비핵심 기능에 대해 명확하고 테스트를 거친 킬 스위치를 구축하세요.

• 중요한 하위 시스템(인증, 상태 페이지, 인시던트 툴링)이 성능 저하 모드 또는 대체 경로를 통해 작동할 수 있는지 확인합니다.

올바른 신호 관찰

5분마다 '양호 구성'과 '불량 구성' 사이의 진동으로 인해 신호가 공격 트래픽이나 노이즈가 많은 외부 동작처럼 보이게 됩니다:

• 통합 가시성 파이프라인에 버전별 또는 구성별 상관관계가 있는지 확인하세요.

• 오류 그래프 위에 구성 변경 사항을 시각적으로 명확하게 표시하는 대시보드를 구축하세요.

• 외부 관점에서의 강력한 종합 테스트를 포함시켜 내부 장애와 네트워크/경로 문제를 신속하게 구분할 수 있도록 하세요.

하나의 인프라 바구니에 모든 달걀을 넣지 마세요.

Cloudflare를 사용하는 조직의 경우:

• 진정한 미션 크리티컬 자산을 위해 멀티 CDN 설정을 고려하세요.

• 상태 페이지를 기본 스택과 동일한 공급업체에 전적으로 의존하지 않도록 하세요(Cloudflare가 이를 수행하지만 어제 상태 페이지 호스트에 공교롭게도 문제가 발생하여 혼란을 가중시켰습니다). Cloudflare 블로그+1

• 인증, API 제어 플레인, 프런트엔드 전송을 폴백 경로 없이 동일한 공급업체에 긴밀하게 연결하기 전에 다시 한 번 생각하세요.

더 큰 그림

지난 몇 달 동안만 해도 Microsoft Azure, Amazon Web Services, 그리고 현재 Cloudflare에서 대규모 중단이 발생하여 소비자 및 기업 서비스의 상당 부분이 일시적으로 오프라인 상태가 되었습니다. AP뉴스+2워싱턴 포스트+2

패턴은 분명합니다:

• 인터넷은 점점 더 소수의 거대 인프라 제공업체에 의존하고 있습니다.

• 서비스 중단은 외부 공격이 아닌 복잡한 내부 변화로 인해 자체적으로 발생하는 경우가 많습니다.

• 세계적 수준의 SRE 관행을 갖춘 제공업체도 구성, 데이터베이스 동작, 하드코딩된 제한 간의 예기치 않은 상호 작용으로 인해 문제를 일으킬 수 있습니다.

어제의 Cloudflare 사고는 '클라우드'가 마법이 아니라는 사실을 극명하게 보여줍니다. 결국, 클라우드도 다른 애플리케이션과 동일한 종류의 버그가 발생할 수 있는 사람이 만든 소프트웨어이며, 단지 그보다 훨씬 더 많은 사람들이 의존하고 있을 뿐입니다.

사용자에게 이 사건은 대부분 "그날 아침 X와 ChatGPT가 로드되지 않았던 일"로 기억될 것입니다.
엔지니어에게는 핵심 분산 시스템의 미묘한 구성 버그가 어떻게 글로벌 인터넷 이벤트로 파급될 수 있는지에 대한 교과서적인 사례로 연구될 것입니다.