지난 2025년 11월, 전 세계 수많은 웹사이트와 온라인 서비스를 마비시켰던 대규모 클라우드플레어 장애 사태를 기억하시나요? 처음에는 대규모 분산 서비스 거부(DDoS) 공격으로 의심받았지만, 놀랍게도 그 원인은 내부에 있었습니다. 과연 무엇이 인터넷을 멈추게 했을까요? 이번 사태의 숨겨진 진실과 함께 클라우드플레어 시스템 내부에서 어떤 문제가 발생했는지 자세히 알아보겠습니다.
“DDoS 공격” 오해와 진짜 원인: 내부 시스템의 허점
2025년 11월 18일, 클라우드플레어에 대규모 장애가 발생했을 때, 회사는 초기 대응팀에서 이를 “하이퍼스케일 DDoS 공격”으로 판단했어요. 클라우드플레어의 공동 창립자이자 CEO인 매튜 프린스(Matthew Prince)는 내부 채팅룸에서 악명 높은 아이수루(Aisuru) 봇넷의 공격 가능성을 우려하기도 했죠. 하지만 심층 조사를 통해 문제는 외부 공격이 아닌 내부 시스템의 오작동에서 비롯되었다는 사실이 밝혀졌습니다. 클라우드플레어의 핵심인 CDN(콘텐츠 전송 네트워크)과 보안 서비스, 그리고 여러 다른 서비스들이 이 내부 문제로 인해 영향을 받았답니다.
사태의 진실은 클라우드플레어의 봇 관리 시스템이 사용하는 ‘특징 파일(feature file)’이라는 중요한 파일이 예기치 않게 크기가 두 배로 커지면서 네트워크 전체에 잘못 전파된 것이었습니다. 이 파일은 머신러닝 모델을 사용하여 보안 위협으로부터 보호하는 시스템의 핵심적인 요소인데, 이 파일의 갑작스러운 변화가 시스템을 마비시킨 거죠.
클라우드플레어 봇 관리 시스템, 무엇이 문제였을까?
클라우드플레어의 봇 관리 시스템은 네트워크를 통과하는 모든 요청에 대해 ‘봇 점수’를 생성하는 머신러닝 모델을 사용해요. 이 봇 점수를 통해 고객들은 어떤 봇이 자신의 사이트에 접근하는 것을 허용하거나 차단할지 결정한답니다. 이 시스템은 ‘특징’이라고 불리는 개별 특성들을 활용하여 요청이 자동화된 것인지 아닌지를 예측하는데요. 이 특징들은 ‘특징 파일’에 기록되어 5분마다 업데이트되고 네트워크 전체에 게시됩니다. 이렇게 빈번하고 신속한 업데이트는 새로운 유형의 봇이나 공격에 빠르게 대응하기 위해 필수적이죠.
문제는 클라우드플레어가 데이터베이스 시스템의 권한을 변경하면서 시작되었습니다. 이 권한 변경으로 인해 데이터베이스는 기존에 예상했던 것보다 더 많은 메타데이터를 쿼리 응답으로 출력하게 되었어요. 클라우드플레어 직원들은 쿼리가 기본 데이터베이스의 컬럼만 반환할 것이라고 예상했지만, 데이터베이스 이름에 대한 필터가 없었기 때문에 쿼리가 컬럼의 중복 항목을 반환했던 것입니다. 이 추가 메타데이터가 응답의 행 수를 두 배 이상 늘렸고, 최종적으로 특징 파일의 행 수(즉, 특징의 수)가 엄청나게 증가하는 결과를 초래했어요.
예기치 않은 데이터 폭증: 시스템 마비의 시작
특징 파일의 크기가 예기치 않게 두 배로 커지자, 클라우드플레어 네트워크의 모든 머신에 이 ‘비정상적인’ 파일이 전파되었습니다. 이 머신들은 클라우드플레어 네트워크 전반의 트래픽을 라우팅하는 소프트웨어를 실행하며, 끊임없이 변화하는 위협에 대응하기 위해 이 특징 파일을 읽어서 봇 관리 시스템을 최신 상태로 유지합니다. 그런데 이 소프트웨어에는 특징 파일의 크기에 대한 제한이 있었고, 크기가 두 배로 커진 파일은 이 제한을 초과해 버렸습니다. 결국 소프트웨어는 오류를 일으키고 시스템 패닉 상태에 빠져 버렸어요.
클라우드플레어의 프록시 서비스는 과도한 메모리 소비를 방지하기 위한 제한을 두는데, 봇 관리 시스템 역시 런타임에 사용할 수 있는 머신러닝 특징 수에 제한(200개)이 있었습니다. 실제 사용되는 특징 수보다 훨씬 많은 양이었지만, 잘못된 파일이 200개 이상의 특징을 가지고 서버에 전파되면서 이 제한에 부딪히게 된 것이죠. 결과적으로 시스템은 오류를 뿜어내며 정상적인 작동을 멈추고 말았습니다.
전 세계를 뒤흔든 5xx 오류: 복구 과정의 난항
잘못된 특징 파일이 네트워크에 퍼진 후, 클라우드플레어 네트워크가 제공하는 5xx 오류 HTTP 상태 코드의 수는 평소에는 매우 낮았지만, 이 사태로 인해 급격히 치솟았습니다. 이 스파이크와 이후의 변동은 시스템이 잘못된 특징 파일을 로드하여 실패했음을 명확히 보여주었어요. 특히 주목할 만한 점은 시스템이 한동안 복구되었다가 다시 실패하는 비정상적인 동작을 보였다는 것입니다.
이러한 비정상적인 동작은 특징 파일이 ClickHouse 데이터베이스 클러스터에서 실행되는 쿼리에 의해 5분마다 생성되고 있었기 때문이었어요. 이 클러스터는 권한 관리를 개선하기 위해 점진적으로 업데이트되고 있었죠. 그래서 쿼리가 업데이트된 클러스터 부분에서 실행될 때만 잘못된 데이터가 생성되었습니다. 결과적으로 5분마다 정상적인 또는 잘못된 구성 파일이 생성되어 네트워크 전체에 빠르게 전파될 가능성이 있었던 것이죠. 이러한 변동은 초기에는 공격에 의한 것으로 오해하게 만들었지만, 결국 모든 ClickHouse 노드가 잘못된 구성 파일을 생성하게 되면서 시스템은 안정적으로 실패 상태에 머물게 되었습니다. 클라우드플레어 팀은 잘못된 특징 파일의 생성 및 전파를 중단하고, 알려진 정상 파일을 수동으로 특징 파일 배포 큐에 삽입한 다음, 핵심 프록시를 강제로 다시 시작하여 문제를 해결했습니다.
클라우드플레어의 사과와 재발 방지 노력
매튜 프린스 CEO는 “오늘 우리가 인터넷에 끼친 고통에 대해 클라우드플레어 팀 전체를 대표하여 사과하고 싶다”며, “클라우드플레어가 인터넷 생태계에서 중요하기 때문에 어떤 장애도 용납할 수 없다”고 밝혔습니다. 이번 장애는 2019년 이후 클라우드플레어에게는 최악의 사태였습니다.
클라우드플레어는 앞으로 유사한 장애를 방지하기 위해 여러 조치를 취하고 있습니다. 클라우드플레어가 생성하는 구성 파일의 인제스트(ingestion) 과정을 사용자 입력과 동일한 방식으로 강화하고, 기능에 대한 더 많은 전역 킬 스위치를 활성화하며, 핵심 덤프나 다른 오류 보고서가 시스템 리소스를 압도하지 않도록 하는 조치들이 포함됩니다. 또한, 모든 핵심 프록시 모듈에서 오류 조건에 대한 실패 모드를 검토하여 시스템의 취약점을 보완할 예정입니다. 프린스 CEO는 미래에 똑같은 규모의 장애가 발생하지 않을 것이라고 장담할 수는 없지만, 이전의 장애들이 항상 더 새롭고, 더 탄력적인 시스템을 구축하는 계기가 되었다고 강조했습니다. 클라우드플레어는 이번 경험을 통해 더욱 강력한 인터넷 인프라를 만들어나갈 것입니다.
마무리
2025년 11월의 클라우드플레어 장애는 인터넷의 광범위한 상호 연결성을 다시 한번 일깨워주는 중요한 사건이었습니다. 단순한 내부 데이터베이스 권한 변경이 어떻게 전 세계적인 인터넷 대란으로 이어질 수 있는지 보여주었죠. 기술 기업들이 끊임없이 시스템을 개선하고 재발 방지책을 마련하는 이유이기도 합니다. 클라우드플레어는 이번 일을 계기로 더욱 안정적이고 신뢰할 수 있는 서비스를 제공하기 위해 노력할 것입니다. 여러분은 이번 클라우드플레어 장애 사태를 통해 어떤 교훈을 얻으셨나요?