※ 본 글은 2025년 11월 18일 한국 시간, Cloudflare Status와 주요 국내·외 언론 보도를 기준으로 정리한 내용입니다. 상황은 계속 변동될 수 있으므로 최신 현황은 반드시 Cloudflare Status 페이지에서 재확인하세요.
1. 지금 무슨 일이 벌어졌나?
2025년 11월 18일(한국 시간) 저녁, 글로벌 CDN·보안 인프라 기업인 Cloudflare(클라우드플레어)에서 대규모 장애가 발생하면서 전 세계 인터넷의 상당 부분이 동시에 흔들렸습니다. 국내외 사용자는 X(구 트위터), OpenAI의 ChatGPT, 리그 오브 레전드(LoL), 스포티파이(Spotify) 등 여러 서비스 접속 시 HTTP 500 계열 오류나 페이지 로딩 실패를 경험했습니다.
Cloudflare는 자사 상태 페이지를 통해 “Cloudflare Global Network experiencing issues”라는 제목으로 글로벌 네트워크 관련 내부 서비스 저하(Internal service degradation)를 공지했고, 일부 서비스에서 간헐적인 오류가 발생하고 있다고 밝혔습니다. 이후 점진적인 복구가 진행 중이지만, 평소보다 높은 오류율이 계속될 수 있다고 안내한 상태입니다.
2. Cloudflare는 어떤 회사인가?
Cloudflare는 전 세계 수백만 개 웹사이트와 API, 모바일 앱 뒤에 숨어 있는 인터넷 인프라 기업입니다. 대표적인 역할은 다음과 같습니다.
- CDN(Content Delivery Network) – 전 세계 엣지 서버를 통해 정적·동적 콘텐츠를 캐싱하고, 지연 시간을 줄여줍니다.
- DNS 및 Anycast 네트워크 – 도메인 이름을 빠르게 IP로 변환하고, 가장 가까운 엣지 POP으로 트래픽을 라우팅합니다.
- 보안(WAF·DDoS 방어) – 웹 애플리케이션 방화벽, 봇 차단, 대규모 DDoS 공격 방어 기능을 제공합니다.
- Zero Trust / SASE – Cloudflare Access, WARP, Gateway 등으로 VPN 대체 및 사내 애플리케이션 보호를 지원합니다.
- 개발자 플랫폼 – Workers, KV, R2, Stream, Images 등 서버리스·스토리지·미디어 서비스를 제공합니다.
즉, “원래 서비스 서버 + Cloudflare” 구조로 서비스하는 기업이 매우 많기 때문에, Cloudflare에 장애가 발생하면 개별 서비스의 서버가 멀쩡하더라도 전 세계에서 동시에 접속 장애가 발생할 수 있습니다. 이번 사고가 “인터넷 마비급”으로 체감된 이유가 바로 여기에 있습니다.
3. 이번 Cloudflare 장애 타임라인 (한국 시간 기준 정리)
여기서는 국내·외 보도와 Cloudflare Status를 기준으로, 한국 시간(KST)에 맞춰 타임라인을 재구성했습니다.
- 20:20 KST (11:20 UTC) 경 – Cloudflare 측은 특정 서비스에서 “비정상적인 트래픽 급증(unusual traffic spike)”을 감지했다고 밝혔습니다. 이 시점부터 일부 트래픽에서 오류가 증가하기 시작했습니다.
- 20:48 KST (11:48 UTC) – Cloudflare Status에 “내부 서비스 저하(Internal service degradation)” 공지가 등록됩니다. 일부 서비스가 간헐적으로 영향을 받을 수 있다고 안내했습니다.
- 21:21 KST (12:21 UTC) – “서비스 복구가 진행되고 있으나, 오류율이 평소보다 높게 유지될 수 있다”는 업데이트가 올라옵니다. 즉, 부분적인 복구가 시작된 상황입니다.
- 22:09 KST (13:09 UTC) – Cloudflare는 상태 페이지에서 “이슈 원인을 식별했으며, 수정 작업을 적용 중”이라고 밝힙니다.
- 22:13 KST (13:13 UTC) – Access, WARP와 관련된 오류 수준이 사고 이전 수준으로 돌아왔으며, 런던 지역에서 일시적으로 중단했던 WARP도 재활성화했다고 공지했습니다.
- 22:35~22:58 KST (13:35~13:58 UTC) – 애플리케이션 서비스 고객에 대한 복구 작업을 계속 진행 중이라는 업데이트가 이어지며, 여전히 일부 트래픽에는 오류가 남아 있을 수 있다고 안내했습니다.
정리하면, 한국 시간 기준 20시대 후반부터 전 세계적으로 장애가 체감되기 시작했고, Cloudflare는 약 1~2시간 내에 문제를 식별하고 수정 작업에 들어간 상태입니다. 다만 글로벌 네트워크 특성상, 지역·서비스별로 체감 복구 시점은 조금씩 다를 수 있습니다.
4. 어떤 서비스들이 영향을 받았나?
Cloudflare의 고객 기반이 워낙 크기 때문에, 이번 장애는 다양한 카테고리의 서비스에 파급되었습니다. 언론 및 모니터링 서비스가 언급한 대표적인 사례는 다음과 같습니다.
- X(구 트위터) – 타임라인 로딩 실패, 게시물/이미지 로딩 지연 등 간헐적인 접속 장애
- OpenAI · ChatGPT – 일부 지역에서 사이트 접속 및 응답이 느려지거나 오류가 발생한 사례가 보고되었습니다.
- 리그 오브 레전드(LoL) – 게임 클라이언트 패치 서버·웹 리소스 등의 접속 오류가 간헐적으로 발생한 것으로 전해졌습니다.
- Spotify 등 글로벌 콘텐츠 서비스 – 스트리밍 및 웹 클라이언트 일부 기능에서 로그인/재생 관련 오류 보고
- 크립토 거래소·DeFi 프론트엔드 – 여러 암호화폐 거래소 및 디파이 서비스의 웹 프론트엔드가 Cloudflare 500 오류와 함께 일시적으로 중단
- 전자 비자(e-Visa) 포털 – 일부 국가의 공식 e-Visa 포털도 Cloudflare 인프라 의존으로 인해 일시적으로 접속이 어려운 사례가 보고되었습니다.
- Downdetector 등 모니터링 사이트 – 아이러니하게도, 장애를 집계하는 사이트 자체도 Cloudflare를 사용하고 있어 접근이 원활하지 않았습니다.
국내에서도 “X·챗GPT·LoL·스포티파이 접속 오류”, “클라우드플레어 장애로 전 세계 인터넷 마비”와 같은 제목의 기사들이 잇따라 보도되며, Cloudflare의 존재를 잘 몰랐던 사용자들도 이번 사건을 통해 “인터넷 뒤의 인프라 회사”를 인지하게 된 상황입니다.
5. 현재까지 알려진 장애 원인 (2025-11-18 기준)
현재(2025년 11월 18일, Cloudflare Status 마지막 업데이트 기준)까지 공식적으로 공개된 내용은 다음과 같습니다.
- Cloudflare는 특정 서비스에서 “비정상적인 트래픽 급증(unusual traffic)”이 발생했다고 설명했습니다.
- 이로 인해 Cloudflare 네트워크를 경유하는 일부 트래픽에서 HTTP 500 계열 오류와 서비스 지연이 증가했습니다.
- Cloudflare Status에서는 이를 “internal service degradation(내부 서비스 저하)”로 정의하고, 전사적으로 복구 작업에 집중하고 있다고 밝혔습니다.
- 이후 Cloudflare는 “원인을 식별했고, 수정 작업을 적용 중”이라고 업데이트했지만, 구체적인 기술적 근본 원인(RCA)은 아직 공개되지 않았습니다.
- 일부 보도와 전문가들은 사이버 공격보다는 내부 시스템 문제 또는 특정 트래픽 패턴과의 상호작용 가능성에 무게를 두고 있으나, 이것은 해석에 가깝고 Cloudflare가 공식적으로 “공격으로 인한 장애”라고 밝힌 적은 없습니다.
또한 장애 발생 시각 전후로 여러 데이터센터 정기 점검이 예정되어 있었으나, Cloudflare와 외신 모두 “현 시점에서 점검과 장애의 직접적인 연관성은 확인되지 않았다”는 입장입니다. 자세한 근본 원인은 Cloudflare의 사후 기술 블로그(Incident Postmortem)에서 별도로 공개될 가능성이 큽니다.
6. 5xx 오류는 무엇이고, 왜 이렇게 크게 체감됐을까?
이번 장애 동안 많은 사용자가 “500 Internal Server Error”, “5xx 오류”를 마주쳤습니다. HTTP에서 5xx 오류는 클라이언트(브라우저)가 아니라 서버 또는 중간 인프라 쪽에서 문제가 발생했다는 뜻입니다. Cloudflare를 경유하는 경우, 다음과 같은 상황에서 5xx가 발생할 수 있습니다.
- Cloudflare 엣지 서버 자체가 응답을 처리하지 못할 때 – 내부 시스템 문제 또는 특정 구성 오류
- Cloudflare와 원본(origin) 서버 사이의 통신에 문제가 생길 때 – 네트워크 단절, 타임아웃 등
- 방화벽·보안 정책이 과도하게 트래픽을 차단할 때
이번 사고에서는 Cloudflare 측이 자사 네트워크 문제를 공식적으로 인정했고, 상당수 서비스에서 Cloudflare 특유의 오류 페이지와 500 계열 코드가 노출되면서 사용자 입장에서는 “내가 쓰는 서비스가 동시에 다 고장 난 것처럼” 느껴지는 결과를 낳았습니다.
7. 이번 장애의 의미
서비스 사용자 입장에서는 “또 인터넷이 멈췄네” 정도로 끝날 수 있지만, 기술 리더 입장에서는 이번 사건을 아키텍처 관점에서 재점검해야 할 타이밍입니다.
7-1. 단일 CDN·단일 벤더 의존성의 리스크
Cloudflare, AWS, Azure, GCP 등 소수 사업자가 글로벌 인프라를 사실상 장악한 상황에서 한 벤더에 대한 과도한 의존은 곧바로 비즈니스 리스크로 이어집니다. 이번 장애는 “우리 서비스가 어느 정도로 특정 벤더에 묶여 있는지”를 냉정하게 점검하라는 신호에 가깝습니다.
- 도메인 네임(DNS)이 Cloudflare에만 의존하고 있는가?
- 정적·동적 트래픽 모두가 Cloudflare를 통해서만 나가는 구조인가?
- 관리 콘솔, API, SSO, 내부 관리자 페이지까지 Cloudflare Zero Trust에 전부 물려 있는가?
7-2. 멀티 CDN / 멀티 DNS 전략 재정비
이번 장애를 계기로, 멀티 CDN·멀티 DNS 전략을 다시 세워야 한다는 목소리가 커지고 있습니다. 꼭 Cloudflare를 버리자는 의미가 아니라, “장애 시 우회할 수 있는 2차 경로”를 준비하자는 접근입니다.
- 핵심 서비스(결제, 로그인, 주문 등)에 한해서라도 보조 CDN·DNS 벤더를 준비
- DNS TTL을 충분히 짧게 유지해 장애 시 빠르게 레코드를 전환할 수 있도록 구성
- Cloudflare 전용 기능(Workers, Turnstile 등)을 쓰는 경우, 최소한의 fallback 시나리오를 문서화
7-3. Zero Trust·SASE 도입 회사가 특히 조심할 부분
Cloudflare Access, WARP, Gateway 등 Zero Trust·SASE 서비스를 깊게 도입한 조직에서는 이번과 같은 중앙 인프라 장애가 곧 임직원 업무 중단으로 이어질 수 있습니다.
- 사내 필수 시스템(그룹웨어, ERP, 코드 레포 등)에 “벤더 장애 시 비상 접근 경로”를 마련했는가?
- 임직원용 VPN/프록시를 100% 단일 벤더에 올려두고 있지는 않은가?
- Zero Trust 정책이 과도하게 엄격해, 장애 시에도 우회할 수 있는 백도어가 전혀 없는 구조는 아닌가?
Zero Trust는 보안을 강화하지만, 단일 제어 평면이 실패할 경우 생산성 전체가 멈출 수 있다는 점도 함께 고려해야 합니다.
7-4. SLA만 믿지 말고, BCP/DR 시나리오를 구체화하라
Cloudflare, AWS 등은 높은 SLA를 제공하지만, “가끔은 반드시 장애가 난다”는 것도 사실입니다. 이번처럼 글로벌 사업자가 동시에 흔들릴 때, SLA 크레딧보다 중요한 것은 비즈니스 연속성(BCP)입니다.
- Cloudflare 장애 시, 서비스의 MTPD(Maximum Tolerable Period of Disruption)를 어떻게 정의할 것인가?
- 비즈니스 스폰서(대표·이사회)와 합의된 RTO/RPO는 있는가?
- 장애 발생 시, 엔지니어·CS·마케팅·경영진 간 커뮤니케이션 라인은 미리 정의돼 있는가?
8. 우리 서비스는 어떻게 대비해야 하나? (체크리스트)
기술 리더를 위한 실천형 체크리스트를 정리해 보겠습니다.
8-1. Cloudflare 의존도 인벤토리 만들기
- 어떤 도메인이 Cloudflare DNS를 사용 중인지 목록화
- 어떤 서비스가 Cloudflare CDN·WAF·Workers 등을 사용하는지 시스템 다이어그램으로 정리
- 내부 시스템(사내용 도메인, 관리자 콘솔 등)도 Cloudflare를 경유하는지 확인
8-2. “Origin 직접 접속” 백업 경로 설계
- 유저 또는 내부 운영자가 Cloudflare를 우회해 원본 서버로 접근할 수 있는 비상 경로 설계
- 예: 별도의 관리용 도메인(Cloudflare 미사용), 고정 IP 기반의 운영자 전용 VPN 등
- 방화벽·보안 정책 상, 이 경로가 실제로 작동하는지 정기적으로 점검
8-3. 멀티 CDN / 멀티 DNS PoC 진행
- 트래픽의 일부(예: 5~10%)를 다른 CDN으로 분산하여, 평상시에도 멀티 벤더 운영 경험을 쌓기
- DNS 레벨에서 가중치 기반 라우팅, 헬스 체크 등을 활용해 “자동 우회” 시나리오 PoC
- 외부 DNS·CDN 교체에 필요한 IaC(Terraform 등) 템플릿을 미리 준비
8-4. 모니터링·알림·커뮤니케이션 정비
- Cloudflare Status·Twitter(X)·RSS 등 공식 상태 페이지 알림을 사전 구독
- 자체 RUM(Real User Monitoring)·Synthetic Monitoring으로 실제 사용자 경험 지표를 수집
- 장애 시 공지용 랜딩 페이지(예: status.yourdomain.com)를 별도 인프라에 구성해 두기
8-5. 사후 분석(Postmortem) 문화 정착
- 이번 장애로 우리 서비스에 어떤 영향이 있었는지 수치로 기록 (에러율, 응답 시간, 매출 영향 등)
- “Cloudflare가 또 장애 났네”로 끝내지 말고, 우리 아키텍처의 취약점을 구체적으로 문서화
- 비난 없는 포스트모템을 통해 개선 과제를 도출하고, 일정에 반영
9. 정리: 인터넷은 생각보다 ‘몇 개 회사’에 많이 의존한다
이번 Cloudflare 대규모 장애는, 몇 년 전부터 반복되어 온 “특정 클라우드/인프라 사업자 장애 → 전 세계 동시 접속 오류” 패턴의 연장선입니다. AWS, Azure, GCP, Cloudflare 등 소수 사업자의 장애가 곧바로 인터넷 전체 문제처럼 느껴지는 시대가 된 셈입니다.
기술 리더에게 이번 사건은 다음과 같은 메시지를 던집니다.
- 벤더는 반드시 실패한다. 실패를 전제로 설계해야 한다.
- 멀티 벤더 전략은 비용이 아니라 리스크 보험에 가깝다.
- 장애 시점의 커뮤니케이션 능력은 기술 역량만큼 중요하다.
Cloudflare가 곧 구체적인 기술 분석과 재발 방지 대책을 내놓을 가능성이 큽니다. 그 보고서가 공개되면, 우리 조직의 아키텍처와 비교·분석해보는 시간을 꼭 가져보시길 추천드립니다.
자주 묻는 질문 (FAQ)
Q1. 이번 Cloudflare 장애는 완전히 해결됐나요?
2025년 11월 18일 기준으로 Cloudflare는 문제 원인을 식별하고 수정 작업을 진행 중이라고 밝혔으며, 일부 서비스는 정상 수준으로 복구되었지만 전 구간이 완전히 평상시 수준으로 돌아왔다고 공식 선언한 단계는 아닙니다. 최신 상태는 항상 Cloudflare Status에서 확인해야 합니다.
Q2. 이번 장애가 해킹이나 DDoS 공격 때문인가요?
현재까지 Cloudflare와 주요 외신이 공개한 내용만 보면, 특정 서비스에서 비정상적인 트래픽 급증이 있었고 이것이 네트워크 전반에 영향을 준 것은 맞지만, Cloudflare가 이를 “외부 공격에 의한 것”이라고 공식적으로 규정한 적은 없습니다. 일부 전문가들은 대규모 공격 가능성보다는 내부 시스템·트래픽 처리 과정에서의 문제일 가능성을 더 높게 보고 있습니다만, 이는 어디까지나 추정이며 공식 근본 원인 분석 보고서를 기다려야 합니다.
Q3. 우리 회사가 Cloudflare를 쓰는지 어떻게 알 수 있나요?
간단하게는 서비스 도메인에 대해 DNS 조회 또는 HTTP 응답 헤더를 확인해볼 수 있습니다. 브라우저 개발자 도구(F12)를 열어 네트워크 탭에서 응답 헤더에 cf-ray, cf-cache-status 등의 값이 보인다면 Cloudflare를 사용하는 경우가 많습니다. 다만, 정확한 확인을 위해서는 사내 인프라 담당자나 DevOps 팀에 직접 문의하는 것이 가장 확실합니다.
Q4. 이번 일을 계기로 Cloudflare를 당장 다른 벤더로 바꿔야 할까요?
Cloudflare는 여전히 가장 널리 쓰이는 CDN·보안 인프라 중 하나이고, 경쟁사들도 유사한 수준의 장애를 경험해 왔습니다. 중요한 것은 “어느 벤더가 더 완벽한가?”보다는 “특정 벤더 장애 시, 우리 서비스가 어떻게 버티게 설계되어 있는가?”입니다. 벤더를 바꾸는 것보다는, 멀티 벤더 전략·DR 시나리오·모니터링·커뮤니케이션 체계를 정비하는 것이 더 실질적인 대응일 수 있습니다.
Q5. 장애 상황에서 엔지니어·CS·마케팅은 각각 무엇을 해야 하나요?
- 엔지니어 – 상태 페이지 모니터링, 내부 모니터링 지표 점검, 우회 경로(직접 원본 접속, 대체 CDN) 검토 및 적용
- CS 팀 – 장애 사실·영향 범위·예상 복구 시간 등 확인된 사실만을 기반으로 고객 응대 스크립트 정리
- 마케팅/커뮤니케이션 – 서비스 상태 공지, SNS·홈페이지·이메일 등을 통한 투명한 상황 공유, 과장된 표현·원인 단정은 지양
이 세 축이 잘 맞물릴수록, 장애 자체보다 더 큰 리스크인 신뢰도 하락을 줄일 수 있습니다.