2025년 11월 18일 Cloudflare 장애에서 실제로 무슨 일이 있었나? 쉽게 설명

2025년 11월 18일 UTC 오전 11시 20분, 전 세계 수백만 명이 갑자기 인터넷에서 가장 인기 있는 웹사이트 일부에 접속할 수 없게 됐다. ChatGPT, Spotify, X(Twitter), Shopify, Canva가 모두 다운됐다. 첫 반응은? "클라우드가 죽었다!"였다. 하지만 놀라운 사실이 있다: 클라우드는 문제가 없었다. 앱은 정상적으로 돌아가고 있었다. 고장 난 것은 많은 사람이 들어본 적 없는 — Cloudflare였다.

이 사례는 네트워크 장애와 클라우드 장애의 차이를 이해하는 것이 얼마나 중요한지 완벽히 보여준다 — 특히 인터넷에 의존하는 비즈니스를 운영하는 경우(오늘날 거의 모든 비즈니스) 더욱 그렇다.

---

Cloudflare란 무엇이며 왜 중요한가?

인터넷을 거대한 고속도로 시스템처럼 생각해 보자. 웹사이트나 앱은 도로 끝에 있는 가게와 같다. Cloudflare는 고객과 가게 사이에 위치하는 고속도로, 신호등, 보안 검문소와 같다.

구체적으로 Cloudflare는 다음을 제공한다:

• 속도: 전 세계 330곳 이상 거점에서 웹사이트 콘텐츠를 캐시(복사 저장)해 더 빠른 로딩 시간을 실현
• 보안: 해커, 봇, DDoS 공격이 서버에 도달하기 전에 차단
• 라우팅: 트래픽을 효율적으로 분배하는 인터넷 요청용 GPS 역할
• DNS: "google.com" 같은 웹사이트 이름을 컴퓨터가 이해하는 숫자 주소로 변환

핵심은 여기다: Cloudflare는 앱 앞에 서 있다. 그것은 정문이다. Cloudflare가 다운되면 사용자는 앱에 접속할 수 없다 — 앱이 뒤에서 완전히 정상 작동하고 있어도.

---

년 11월 18일에 무슨 일이 있었나?

이 장애는 사이버 공격이나 하드웨어 고장으로 발생한 것이 아니었다. 놀랍도록 단순한 것이 원인이었다: 파일이 너무 커진 것이다.

기술적 내용(쉬운 말로)

Cloudflare는 Bot Management이라는 시스템으로 자동화된 봇(데이터를 스크래핑하거나 공격을 가하는 나쁜 종류)을 식별하고 차단한다. 이 시스템은 새로운 봇 행동 정보로 몇 분마다 업데이트되는 특별한 '피처 파일'에 의존한다.

문제가 된 부분을 설명하자:

1.데이터베이스 권한 변경: Cloudflare 팀이 데이터 저장·분석 시스템인 ClickHouse 데이터베이스 권한을 업데이트하고 있었다 2. 중복 데이터 발생: 이 변경으로 데이터베이스가 봇 피처 파일에 중복 행 정보를 출력하기 시작했다 3. 파일 크기 2배: 평소 관리 가능한 크기였던 파일이 갑자기 2배로 커졌다 4. 시스템 처리 불가: Cloudflare 소프트웨어에는 내장 크기 제한이 있었다. 파일이 그 제한을 넘자 소프트웨어가 크래시했다 5. 전 세계 전파: 이 파일은 몇 분마다 전 세계 330곳 이상 Cloudflare 데이터센터 모두에 배포되므로, 문제는 몇 분 만에 전 세계로 확산했다

혼란을 키운 부분 이 장애 진단을 특히 어렵게 한 것은

깜빡임을 반복 했다는 점이었다. 5분마다 시스템은 새 파일을 생성했다. 때로는

양호했고(쿼리가 오래된 DB 노드에서 실행된 경우), 때로는 불량이었다(업데이트된 노드에서 실행된 경우). 이로 인해

Cloudflare 엔지니어는 처음에 내부 설정 오류가 아니라 대규모 DDoS 공격을 받고 있다고 생각했다.

타임라인

• UTC 11:05- 데이터베이스 권한 변경 적용 -UTC 11:20- 장애 발생; 전 세계 사용자가 오류 페이지를 봄 -UTC 약 14:30- 근본 원인 파악, 수정 배포(알려진 정상 파일로 롤백) -UTC 17:06 - 모든 시스템 완전 복구

총 영향 기간: 약 6시간, 최악의 시기는 약 3시간 지속됐다.

---

Cloudflare 장애 vs 클라우드 장애: 차이는?

많은 사람이 혼란스러워하는 지점이다. 웹사이트가 다운되면 "클라우드가 죽었다"고 말하기 쉽다. 하지만 실제로는 매우 다른 두 종류의 장애가 존재한다:

11월 18일 장애 중 AWS, Azure, Google Cloud는 모두 완벽히 가동됐다. ChatGPT 서버는 정상이었다. Spotify 데이터베이스는 건강했다. 하지만 사용자는 접속할 수 없었다 —경로가 차단됐기때문이다.

---

어떤 서비스가 영향을 받았나?

이 장애는 여러 Cloudflare 서비스에 영향을 줬다:

-코어 CDN과 보안: 주요 문제 — 웹사이트가 HTTP 500 오류 반환

• Turnstile(Cloudflare CAPTCHA 대체): 로딩 실패, 로그인 방해 -Workers KV(엣지 스토리지): 게이트웨이에 요청 도달 불가, 오류 반환 -대시보드: Turnstile 다운으로 대부분 사용자 로그인 불가
• Access(제로 트러스트 인증): 대부분 사용자 인증 실패 -메일 보안: IP 평판 데이터 일시 손실, 스팸 탐지 정확도 하락

---

기업을 위한 핵심 교훈

인터넷에는 단일 장애점이 존재한다

Cloudflare는 인터넷의 거대한 부분을 떠받친다. 다운되면 영향은 막대하다. 이 사례는 최고의 엔지니어링 팀과 인프라를 갖춰도 어떤 시스템도 장애에서 면제되지 않는다는 것을 보여준다.

멀티 CDN 아키텍처는 더 이상 선택이 아니다

이 장애를 최소 혼란으로 넘긴 기업은 멀티 CDN 전략을 사용하고 있었다:

• 프라이머리 CDN: Cloudflare(일반 운영용)
• 세컨더리 CDN: Fastly, Akamai, 또는 AWS CloudFront(페일오버용)
• 헬스 체크: 프라이머리 실패 시 트래픽 전환 자동 모니터링
• DNS 페일오버: 건강한 엔드포인트로 사용자 리다이렉트 지능형 라우팅

이 접근은 중요 업무 구성요소에 여러 공급업체를 두는 것과 비슷하다 — 한 벤더에 완전히 의존하는 것은 피하고 싶다.

우회 방법은 있다(하지만 사용자 친화적이지 않다)

장애 중 일부 사용자는 문제를 우회하는 방법을 찾았다:

• 모바일 앱: 많은 앱이 Cloudflare 프록시를 우회해 계속 작동
• 직접 API 액세스: 개발자는 API를 직접 호출 가능(예: OpenAI API는 정상 작동)
• 직접 IP 액세스: IP 주소를 아는 기술 사용자는 오리진 서버에 직접 연결 가능

하지만 이것들은 일반 사용자에게 실용적 해결책이 아니다. 그래서 아키텍처상 회복력이 매우 중요하다.

작은 변경이 큰 영향을 낼 수 있다

단순한 데이터베이스 권한 변경이 수백만 명에게 영향을 주는 전 세계 장애를 일으켰다. 이는 다음의 중요성을 강조한다:

• 설정 변경의 철저한 테스트
• 즉시 글로벌 배포가 아닌 단계적 배포
• 중요 파일·설정의 크기 제한과 검증
• 이상이 전파되기 전에 탐지하는 더 나은 모니터링

---

Cloudflare의 재발 방지 대책

사후 보고서에서 Cloudflare는 실패를 인정하고 여러 개선책을 제시했다:

• 더 나은 파일 크기 검증: 설정 파일 전파 전 검사
• 단계적 배포: 글로벌 배포 전 소규모 서버 서브셋에서 변경 테스트
• 모니터링 강화: 설정 파일 크기 이상 더 빨리 탐지
• 오류 처리 개선: 시스템이 완전 크래시 대신 우아하게 성능 저하

---

마무리: 회복력 있는 시스템 구축

2025년 11월 18일 Cloudflare 장애는 인터넷이 본질적으로 취약하다는 것을 다시 상기시켰다. 상호 연결된 시스템의 연쇄이며, 단 하나의 약한 고리가 광범위한 혼란을 일으킬 수 있다.

기업에게 교훈은 분명하다:

• 인프라 다양화: 단일 CDN, 클라우드 제공업체, DNS 서비스에 의존하지 않기
• 페일오버 전략 구현: 프라이머리 실패 시 백업 시스템 전환 자동화
• 모든 레이어 모니터링: 엣지, 네트워크, 애플리케이션 수준에서 성능 추적
• 재해 복구 테스트: 페일오버가 실제로 작동하는지 확인하기 위해 정기적으로 장애 시뮬레이션
• 명확한 커뮤니케이션: 서드파티 서비스 실패 시 고객에게 알릴 계획 보유

좋은 소식은? 적절한 아키텍처와 계획이 있으면 이런 피할 수 없는 장애의 영향을 최소화할 수 있다는 것이다. 11월 18일을 무사히 넘긴 기업은 단순히 운이 좋았던 것이 아니다 — 그들은 준비되어 있었다.