🎆서비스 좀 꺼줄래? 내 봇 좀 보게.

구독자님 안녕하세요!🐣

2025년 11월 18일, 전 세계 곳곳에서 대다수의 서비스에서 접속을 할 수 없다는 이슈가 발생했었는데요. 구독자님도 평소처럼 열리던 웹사이트가 멈추고, 로그인이 끝없이 실패하거나 게임 접속도 평소처럼 이어지지 않던 경험을 하지 않으셨나요? 정체는 서비스들을 호스팅해주던 클라우드플레어(Cloudflare)에서 문제가 생겨 발생한 장애였는데요.

이번 뉴스레터에서는 이번 클라우드플레어 사건이 어떻게 시작되었는지, 또한 어째서 전 세계로 확산되었는지, 그리고 클라우드플레어가 어떤 조치로 복구했는지까지 핵심 흐름을 함께 살펴보겠습니다! 🧐

🔎Cloudflare 사건 개요  

[출처 경향신문] 오류가 발생한 ChatGPT 웹페이지

이번 장애는 한국 시간 기준 2025년 11월 18일 오후 8시 20분부로 발생하였어요. 전 세계에서 동시에 접속 지연과 서비스 불능 현상이 나타났고, 클레우드플레어를 사용하는 수많은 웹사이트들이 이에 영향을 받게 되었습니다.

클라우드플레어가 공식 발표한 타임라인은 다음과 같아요.

문제는 오후 8시 20분쯤, 클라우드플레어 내부에서 트래픽을 처리하는 핵심 경로에 이상이 생기면서 시작되었습니다. 처음에는 '조금 느린가' 싶은 수준이었지만, 곧바로 전 세계 사용자들의 접속 요청이 연쇄적으로 실패하기 시작했죠. 이어 10시 5분경, 클라우드플레어는 Workers KV와 일부 인증, 보안 기능을 우회하는 임시 조치를 적용했고, 이 시점부터 일부가 복구되기 시작했습니다. 이후 11시 30분에 주요 영향이 해결되고, 다음 날 새벽 2시 6분인 11월 19일 드디어 모든 서비스가 완전히 복구되었어요. 무려 3시간 이상 인터넷의 상당 부분이 제대로 작동하지 않았던 거죠.

[출처 X]

이 한 줄이 그날의 상황을 잘 보여주는데요. 문제를 알리고 싶어도, 정작 그 문제 때문에 알릴 수조차 없었던 순간들이 반복되었어요. 이 시간 동안 클라우드플레어를 사용하는 수백만 개의 웹사이트가 영향을 받게 되었다고 해요. CDN, DNS, 보안 서비스와 같은 핵심 기능들이 불안정해지게 되면서 서비스 접속이 눈에 띄게 느려지거나 아예 접속이 불가능해지는 상황들이 벌어졌습니다. 😢

🤖범인은 봇 관리 시스템?

클라우드플레어 측의 공식 발표에 따르면, 이번 사고는 사이버 공격이 아니라 내부 시스템 업데이트 과정에서 발생한 실수였다고 해요. 클라우드플레어는 Bot Management라는 시스템을 사용해서 서비스 요청이 사람이 보낸 요청인지, 봇이 보낸 요청인지를 판단합니다. 이 시스템은 머신러닝을 기반으로 동작하는데, 이때 피처 파일(feature file)이라는 설정 파일⚙️을 통해 머신러닝 모델이 참고할 여러 가지 특성들을 저장하는 구조로 되어 있어요.

문제는 보안을 강화하기 위한 설정 변경으로부터 시작되었어요. 클라우드플레어 개발자들은 오후 8시 5분쯤, 보안을 강화하기 위해 Bot Management가 참고하는 데이터를 저장하는 ClickHouse 데이터베이스의 접근 권한을 수정했다고 해요. 그런데 15분 뒤부터 데이터베이스 쿼리가 비정상적으로 동작하기 시작하며, 동일한 데이터를 중복으로 두 배씩 가져오기 시작하는 현상이 발생하게 되었습니다.😱

이 영향은 그대로 Bot Management 시스템에 전달되었어요. Bot Management 시스템의 피처 파일의 원래 약 60개 정도 수준이던 특성이 갑자기 200개를 초과하여 담기게 된 것이죠.👨‍👨‍👧‍👧 문제는 여기에서 발생했는데, 해당 시스템은 최대 200개까지만 처리하도록 설계되어 있었기 때문에 제한을 넘는 순간 시스템은 정상적으로 요청을 처리하지 못하고 오류 상태에 빠지게 되었습니다.

이렇게 생성된 비정상적으로 커진 피처 파일은 클라우드플레어 전 세계 모든 서버로 배포되었고 각 서버가 해당 파일을 읽는 과정에서 동일한 오류를 겪게 되어, 그 결과 HTTP 5xx 오류가 전 세계적으로 급증하는 대규모 장애로 이어졌다고 해요.

[출처 Cloudflare] 사건 당시 Cloudflare에서 발생한 5xx 오류 HTTP 상태 코드의 발생량

이 그래프는 장애가 발생한 이후 HTTP 5xx 오류 응답이 얼마나 급격하게 증가했는지📈를 보여줍니다. 살펴보면 요청 흐름이 무너진 채, 전 세계에서 실패한 요청이 한꺼번에 쏟아지며 장애가 빠르게 확신된 모습이 그대로 드러나는데요. 이런 상황 속에서 클라우드플레어의 상태 페이지마저 다운되면서 내부적으로 DDoS 공격이 아닐까 했다고도 하네요.😨 실제 수치로만 보면 공격처럼 보일 만큼 혼란스러운 상황이었기 때문이에요.

[출처 Cloudflare] Matthew Prince(Cloudflare CEO)가 남긴 우려 코멘트

특히 장애가 발생하기 직전부터 대규모 Aisuru DDoS 공격이 빈번하게 관측되고 있었기 때문에, 엔지니어들은 이번 사고 역시 그 연장선일 가능성을 염려하고 있었어요. 공격자가 엣지 인프라와 상태 페이지를 동시에 노려 의도적으로 상황 인지를 어렵게 만들고 있다는 가설이 세워졌지만, 결과적으로는 서로 연관되지 않은 단순한 우연에 불과했다고 하네요. 😀

🌊 어쩌다가 이렇게 되었나

[출처 Cloudflare] 클라우드플레어의 핵심 프록시 구조도

Bot Management 시스템은 클라우드플레어의 코어 프록시 시스템인 Frontline과 연결되어 있었어요. 이 프록시 계층은 인터넷 트래픽이 반드시 거쳐 가는 핵심 경로로, 웹사이트 접속과 보안 검증 등을 처리하는 역할을 한다고 해요.🔗

그런데 잘못 생성된 피처 파일이 이 Frontline으로 전파되면서, 프록시 처리 과정에서 오류가 발생하기 시작했어요. 그 결과 CDN, 보안 서비스, 로그인 처리 등 핵심 기능들이 연쇄적으로 영향을 받게 되었습니다. Turnstile이라는 봇 차단 서비스가 이로 인해 작동을 멈췄고, 내부적으로 사용되는 Workers KV 데이터 저장소와 접근 인증 서비스 역시 정상적으로 동작하게 않게 되었습니다.

클라우드플레어는 원래 시스템이 무한정 메모리를 사용하지 않도록 피처 수를 최대 200개로 제한하는 안전장치를 두고 있었다고 해요. 하지만 이번 사고에서는 이 제한을 초과하게 되어 시스템 내부에서 오류가 발생하게 되면서, 프록시 내부에서 요청을 처리하지 못하는 오류 상태로 빠지게 된 것이죠!⛔

공식 보고서에 따르면, 만약 해당 제한이 없었다면 메모리 사용량은 증가했겠지만 서비스 자체는 멈추지 않고 계속 동작했을 가능성이 있다고 설명하였습니다.

⚡Cloudflare 사건에서의 시사점

이번 장애는 데이터베이스 권한 하나를 바꾸는 아주 작은 작업에서 시작되었어요. 보안을 강화하려는 의도 자체는 분명히 옳았지만, 그 변경이 전체 시스템에 미칠 영향을 충분히 검증하지 못한 것이 문제였습니다.

클라우드플레어는 이후 다음과 같이 개선하겠다고 밝혔어요.🩹

이번 사건은 클라우드플레어 하나에만 의존하면 단일 장애점(SPOF)이 된다는 것을 분명히 보여주었어요. 특히 DNS를 포함한 트래픽 처리와 보안, 인증 경로를 하나의 제공업체에 맡기고 있던 서비스와 기업일수록, 장애가 발생한 시간 동안 서비스가 잠시 인터넷에서 사라진 것처럼 느껴질 수밖에 없었으니까요! 중요한 서비스일수록, 여러 제공업체를 함께 사용하는 다중 제공업체 전략은 이제 선택이 아니라 필수에 가까워지고 있어요.👀

이런 고민이 채 가시기도 전에 불과 보름 뒤인 12월 5일, 클라우드플레어는 React 생태계에서 큰 화제였던 React2Shell 이슈에 대응하기 위한 방화벽 설정 과정에서 또 다시 한 차례 장애를 겪게 되기도 했어요.💢 보안 취약점에 빠르게 대응하는 과정에서의 구성 변경이 다시 한 번 서비스 안정성에 영향을 준 사례가 된 것이죠.

❗React2Shell에 대한 자세한 내용이 궁금하다면 해키보이즈 블로그를 참고해주세요!

🎬 마무리하며

이번 사고는 거대한 인터넷 인프라가 가지는 중앙화의 딜레마를 보여주었어요. 클라우드플레어처럼 전 세계의 수많은 서비스가 단일 서비스에 의존하는 구조에서는 인프라에 대한 의존도가 높아질수록 한 곳의 작은 결함 하나가 인터넷 전체에 미치는 충격이 커질 수 밖에 없게 됩니다. 🤯 이번 사고 역시 내부 구성 파일의 비정상적 증가라는 단순한 오류였지만, 그 여파는 글로벌 서비스 장애로 이어진 것처럼요.

그럼에도 주목할 만한 점은 사고 이후의 대응 방식에 있어요. 클라우드플레어는 장애 당일 공식 블로그를 통해 원인, 대응 과정, 향후 개선 계획까지 투명하게 설명했습니다. 이런 대응은 인프라 제공업체와 사용자 간의 신뢰를 유지하는 데 있어 분명 의미 있는 선택이었다고 볼 수 있죠.

만약 그날처럼 인터넷의 중요한 일부가 갑자기 멈춰버리는 상황이 다시 온다면, 우리는 얼마나 준비되어 있고, 또 어떻게 대비할 수 있을까요? 구독자님의 생각을 댓글로 남겨주세요!

구독자님, 오늘 뉴스레터는 어떠셨나요?
해킹/보안 관련 콘텐츠를 계속 받아보고 싶으시다면 구독 부탁드려요! 🙌