📌 클라우드플레어가 터졌는데, 왜 내 사이트는 멀쩡했을까?
Cloudflare 장애를 보면서 대부분의 개발자와 운영자는 비슷한 감정을 느낀다.
“대형 사이트들이 줄줄이 500인데… 왜 내 사이트는 멀쩡하지?”
이 상황이 오히려 더 불안하게 느껴지기도 한다.
이번 글에서는 Cloudflare 장애가 실제로 어떤 레이어에서 일어났는지,
그리고 왜 어떤 사이트는 무너졌고, 어떤 사이트는 아무 일 없이 지나갔는지
구조적으로 정리해본다.
✅ 1. Cloudflare 장애는 ‘전체 장애’가 아니다많은 사람들이 “Cloudflare가 터졌다 = 전 세계 DNS가 죽었다”로 이해하지만,
실제로 Cloudflare는 여러 계층으로 나누어져 있다.
Cloudflare 구조(단순화)DNS 레이어 – 도메인을 IP로 연결
Proxy/CDN 레이어 – 오렌지 클라우드 (캐싱/프록시)
Security·Rules 엔진 – WAF, Transform Rules, Redirect Rules 등
Workers 런타임 – 엣지에서 실행되는 코드
Dashboard/API – 사용자가 설정 변경하는 콘솔Cloudflare 장애가 난다고 해서 이 모든 레이어가 동시에 죽는 게 아니다.
오히려 일부 레이어만 죽는 경우가 대부분이다.
✅ 2. 이번 장애는 “Workers / Rules / Dashboard” 층에서 발생했다이번 Cloudflare 이슈의 핵심은 다음 두 가지였다.
북미 일부 POP(시카고, 디트로이트)의 유지보수
Cloudflare Dashboard/API 오류
Rules/Workers 레이어에서의 응답 장애즉, Cloudflare 프록시 네트워크 전체가 죽은 것이 아니라,
특정 기능 계층만 문제가 발생했다.
❌ 그래서 죽은 사이트들은 공통점이 있었다장애를 크게 맞은 대형 사이트들은 대부분 다음 기능에 의존하고 있었다.
Workers 기반 라우팅
WAF 규칙
Redirect Rules
로드밸런서 + Edge 인증
복잡한 조건 기반 트래픽 분기이 레이어가 터지면 사용자 요청이 오리진 서버까지 도달하지 못하고
Cloudflare 엣지에서 500을 뱉는다.
즉,
“내 서버 문제”가 아니라
“Cloudflare가 내 요청을 서버까지 보내주지 못한 것”이다.
✅ 3. 그런데 왜 내 사이트는 멀쩡했을까?이유는 아주 단순하고 명확하다.
→ 너는 Cloudflare의 ‘위험한 레이어’를 거의 안 쓰고 있기 때문이다.대부분의 개인 서버나 소규모 서비스는 아래만 쓴다.
DNS
기본 Proxy/CDN
기본 SSL
약간의 Cache 설정이 수준은 Cloudflare의 기능 중 가장 안정적인 계층이며,
이번 장애의 영향권에도 포함되지 않았다.
반대로 대형 서비스는 Cloudflare에서 더 많은 기능을 사용한다.
즉, 의존성이 높을수록 장애 영향을 크게 받는다.
🔥 즉, 네 사이트가 멀쩡했던 이유는 ‘운’이 아니라 ‘구조’다.DNS → 정상
기본 Proxy POP → 정상
Rules/Workers → 너는 사용 안 함
Dashboard API 장애 → 실제 서비스에는 영향 없음그래서 네 사이트만 불안할 정도로 멀쩡하게 돌아간 것이다.
이건 Cloudflare 장애의 전형적인 패턴이다.
“복잡하게 쓴 사이트일수록 장애에 취약하고,
단순하게 쓴 사이트일수록 장애에 강하다.”
✅ 4. 이번 일을 통해 배울 수 있는 IT 지식① 클라우드 서비스는 ‘레이어별 장애’를 이해해야 한다DNS, CDN, WAF, Edge Runtime은 전혀 다른 시스템이다.
“Cloudflare 터졌다”는 말은 실제로는 “그중 한 층이 터졌다”는 뜻.
② 장애 복원력은 ‘서비스가 어떤 기능에 의존하는가’로 결정된다Workers, Rules, LB에 의존할수록 장애에 취약해진다.
단순하게 쓰면 쓰는 만큼 복원력이 커진다.
③ Edge 기반 서비스는 편리하지만, 장애 시 리스크가 크다서버에 도달하기 전에 Cloudflare가 모든 요청을 처리한다.
즉, 엣지가 터지면 서버까지 도달조차 못 한다.
④ 관찰 지표는 '내 서버'가 아니라 'Cloudflare POP 경로'내 서버는 멀쩡해도
POP → Edge 기능 → Routing이 터지면 500이 뜬다.
🎯 5. 결론: Cloudflare 장애에 휘둘리지 않는 방법불필요한 Rules / Workers 사용 줄이기
핵심 API는 가능하면 Proxy OFF 고려
장애 때는 시크릿창 + VPN으로 POP 경로 확인
Cloudflare Status 페이지보다 실제 레이어 상태 보는 게 중요
🧩 마무리“내 사이트만 멀쩡해서 불안하다”는 감정은 아주 자연스럽다.
하지만 구조적으로 보면
네 사이트는 Cloudflare에서 ‘장애가 안 나는 층’만 쓰고 있었기 때문에
영향을 안 받은 것이다.
Cloudflare 같은 글로벌 인프라는 거대한 건물이 아니라
여러 층으로 되어 있는 복합 시스템이며,
이번 사건은 그 구조를 이해할 수 있는 좋은 학습 기회다.
gpt가 쓴글
