11월 18일, 갑자기 챗GPT가 멈추고 X(트위터)가 먹통이 되더니 전 세계 인터넷의 절반이 사라진 것 같은 기분이 들었다. ‘내 와이파이 문제인가?’ 하고 공유기를 껐다 켜 봤지만 범인은 따로 있었다. 인터넷의 관문이자 방패인 클라우드 클레어가 멈춘 것이다. 도대체 무슨 일이 있었던 걸까?
리스트
전 세계가 멈춘 날, 범인은 누구인가?
지난 11월 18일 오후(한국 시간 기준 저녁), 개발자들은 물론 일반 사용자들까지 패닉에 빠졌다. 업무에 필수적인 ChatGPT가 답변을 거부하고, Discord 알림이 멈췄으며, Spotify에서 음악이 재생되지 않았다. 심지어 이 상황을 확인하러 들어간 Downdetector(장애 확인 사이트)조차 접속이 안 되는 아이러니한 상황이 벌어졌다.
처음엔 대규모 디도스(DDoS) 공격을 의심했다. 하지만 증상은 조금 달랐다. 단순히 느려지는 게 아니라, 명확한 500 Internal Server Error나 502 Bad Gateway를 뱉어내고 있었다.
이 사태의 중심에는 전 세계 웹 트래픽의 상당 부분을 처리하는 클라우드 클레어(Cloudflare)가 있었다. 인터넷의 신호등 역할을 하는 그들이 멈추니, 신호를 받던 모든 차들이 도로 한복판에 멈춰 선 꼴이 된 것이다.
From some random page, but hilarious!!😆
byu/VenjeR84 inCloudFlare
왜 터졌을까? : 디도스가 아닌 ‘내부의 적’
공식 발표를 뜯어보니, 원인은 외부 공격이 아니라 내부 시스템의 설정 오류(Configuration Error) 였다. 조금 더 깊이 들어가 보자. 개발자로서 이 부분은 꽤 흥미로우면서도 등골이 서늘한 지점이다.
1. ClickHouse 데이터베이스와 권한 변경
Cloudflare 엔지니어들은 분산 데이터베이스인 ClickHouse의 쿼리 성능을 개선하기 위해 권한 설정을 변경하고 있었다. 평소라면 문제없었을 루틴한 작업이었다. 하지만 이 작은 변경이 나비효과를 불러왔다.
2. 봇 관리(Bot Management) 시스템의 오작동
이 권한 변경으로 인해 봇(Bot)을 탐지하고 차단하는 로직에 사용되는 기능 파일(Feature File) 생성 과정에 버그가 발생했다.
문제의 핵심:
데이터베이스 쿼리가 중복된 행(Rows)을 반환하기 시작했고, 이로 인해 설정 파일의 크기가 예상치 못한 수준으로 거대해졌다(Oversized).
3. 시스템 셧다운
원래라면 이 파일은 가볍게 각 엣지(Edge) 서버로 전송되어야 했다. 하지만 파일이 너무 커지자, 이를 받아 처리해야 하는 전 세계의 Cloudflare 프록시 시스템들이 “나 이거 못 받아!” 하고 뻗어버린 것이다. 메모리 한계에 도달했거나 처리 타임아웃이 발생했을 것이다.
에러 로그로 보는 현장 상황
당시 우리의 모니터링 대시보드는 온통 빨간색이었다. 만약 당신이 당시 API를 호출하고 있었다면 아래와 같은 응답을 지겹도록 봤을 것이다.
// 11월 18일 장애 당시 흔한 API 응답
HTTP/1.1 502 Bad Gateway
Date: Tue, 18 Nov 2025 12:15:00 GMT
Content-Type: application/json
Server: cloudflare
{
"error": {
"code": 502,
"message": "Bad Gateway",
"details": "Cloudflare worker failed to respond within the limit."
}
}보통 502는 서버가 죽었을 때 뜨지만, 이번엔 서버 앞단에 있는 문지기(Cloudflare) 가 넘어져서 서버 근처에도 못 가고 에러가 난 케이스다.
우리는 무엇을 배웠나? (개발자의 관점)
이 사건은 우리에게 “절대 죽지 않는 시스템은 없다”는 진리를 다시 한번 상기시켜 준다. 초보 개발자로서, 혹은 서비스를 운영하는 입장에서 우리는 어떻게 대비해야 할까?
1. 단일 실패 지점 (SPOF)의 공포
Cloudflare는 너무 편리하고 강력하다. 그래서 우리는 모든 것을 그들에게 맡긴다. 하지만 그들이 멈추면 우리 서비스도 멈춘다. 이를 단일 실패 지점(Single Point of Failure) 이라고 한다.
- 생각해 볼 점: “만약 CDN이 죽으면 우리 서비스는 최소한의 안내 페이지라도 띄울 수 있는가?”
2. 그레이스풀 데그레이데이션 (Graceful Degradation)
완벽한 복구는 힘들더라도, 사용자가 망가진 화면을 보게 해서는 안 된다.
- 프론트엔드에서 API 호출이 502를 뱉을 때, 무한 로딩을 돌리는 대신 “현재 네트워크 상황이 불안정합니다. 잠시 후 다시 시도해주세요” 라는 친절한 UI를 띄우는 처리가 필수적이다.
3. 상태 페이지(Status Page)의 중요성
장애가 났을 때 가장 먼저 해야 할 일은 내 코드를 의심하는 것이고, 두 번째는 공식 상태 페이지를 확인하는 것이다.
- 이번 사태 때도 Cloudflare Status 페이지를 먼저 확인한 개발자는 헛수고를 덜었다. (물론 그 페이지조차 접속이 잘 안 됐지만…)
기술은 완벽하지 않기에 아름답다(?)
11월 18일의 악몽은 끝났다. Cloudflare 팀은 빠르게 롤백했고, 인터넷은 다시 평화를 되찾았다. 하지만 이번 사건은 거대 IT 기업조차 작은 설정 파일 하나에 무너질 수 있다는 것을 보여주었다.
우리가 작성하는 코드 한 줄, 설정 하나가 전 세계에 영향을 미칠 수 있다는 무게감을 느낀 하루였다. 오늘 저녁은 터미널을 잠시 끄고, 연결의 소중함을 느끼며 산책이라도 다녀와야겠다. 물론, 스마트폰이 인터넷에 잘 연결되어 있는지 확인하면서 말이다.