1. 들어가며
ㅁ2025년 11월 18일 저녁, 전 세계 수많은 인터넷 서비스를 마비시킨 Cloudflare의 글로벌 네트워크 장애가 발생했습니다. 우리 서비스 역시 예외는 아니었습니다.
이 글은 긴박했던 장애 상황에서 우리 팀이 어떻게 문제를 인지하고 대응했는지, 특히 모바일과 PC 환경에서 나타난 상이한 증상을 어떻게 분석했는지를 기록합니다. 또한, 향후 유사한 ‘외부 인프라 장애(Outage)’에 대비하기 위해 수립한 구체적인 개선 계획을 공유하여, 같은 고민을 하는 엔지니어링 팀들에게 도움이 되고자 합니다.
2. 장애 개요 (Incident Overview)
원인 (Root Cause)
Cloudflare의 사후 분석에 따르면, 이번 장애의 핵심 원인은 Bot Management 기능에 있었습니다.
“Bot Management 구성 파일을 생성하는 로직의 버그로 인해 트래픽 처리 경로의 소프트웨어 일부가 크래시(Crash)되었으며, 이 오류가 글로벌 엣지(Edge)로 전파되었습니다.”
주요 증상
- 연결 실패: 웹 서비스 접속 시 간헐적인 5xx 에러 및 타임아웃 발생.
- 리소스 누락: CDN을 타는 정적 리소스(이미지, CSS 등) 로딩 실패.
- 관리 도구 마비: Cloudflare 대시보드 및 API 접근 불가로 인한 설정 변경의 어려움.
- 플래핑(Flapping): 지역별 엣지 서버 상태에 따라 “됐다가 안 됐다가”를 반복하는 불안정한 양상.
🔍 특이점: 모바일 Web vs PC Web의 차이
이번 장애에서 가장 흥미로웠던 기술적 발견은 클라이언트 환경별로 영향도가 달랐다는 점입니다.
- 모바일 웹 (In-App Webview 등): 앱 컨테이너의 네트워크 경계와 독자적인 쿠키/스토리지 정책으로 인해 PC 웹과는 전혀 다른 오류 패턴을 보였습니다.
- 캐시 키(Cache Key)의 파편화: 서브도메인 및 경로(Path)별로 캐시 키 정책이 달랐던 탓에, 동일한 도메인임에도 불구하고 장바구니는 죽고 홈페이지는 살아있는 일관성 없는 패턴이 관찰되었습니다.
3. 대응 타임라인 (Timeline)
긴박했던 4시간의 기록입니다. (KST 기준)
| 시각 | 단계 | 주요 내용 |
| 20:33 | 🚨 최초 감지 | 외부 접속 이슈 제보 급증, Cloudflare 대시보드 접근 불가 확인 |
| 21:00 | 🧐 범위 파악 | iOS/Android/Web 간헐적 장애 재현, Cloudflare Status 글로벌 공지 확인 |
| 21:05 | 📞 라인 확보 | 파트너사 유선 연락 및 비상 지원 채널 확보 |
| 21:10 | 🛠 우회 시도 | DNS Only 모드 전환 (Proxy 우회) 결정 및 실행 → 일부 경로 개선 확인 |
| 22:00 | 📈 점진적 복구 | 도메인/엣지별 순차 회복 관찰 (잔여 이미지 로딩 오류 지속) |
| 24:28 | ✅ 공식 종료 | Cloudflare “Resolved” 선언 |
| 익일 | 🔄 정상화 | Proxy 모드 원복 및 임시 보안 설정 롤백 |
4. 대응 회고 (Retrospective)
👍 잘한 점 (Good)
- 신속한 결단 (Speed): 장애 감지 후 40분 이내에 DNS Only 모드로 전환하여 오리진 서버로 직접 트래픽을 돌리는 결단을 내렸습니다.
- 즉각적인 모니터링 구축: 대시보드가 먹통인 상황에서 Datadog Synthetic 룰을 즉시 생성하여 Cloudflare Status API와 연동, 실시간 상태를 추적했습니다.
- 안전한 롤백: 서비스 정상화 확인 후, 보안 홀을 막기 위해 즉시 Proxy 모드로 원복했습니다.
👎 아쉬웠던 점 (Improvement Needed)
- SOP(표준 운영 절차)의 부재: DNS Only 전환은 WAF와 DDoS 방어를 포기하는 위험한 결정입니다. 이에 대한 사전 승인 프로세스가 없어 의사결정에 시간이 소요되었습니다.
- 가시성(Visibility) 한계: 지역별, 그리고 앞서 언급한 ‘모바일 vs PC’ 간의 차이를 실시간으로 보여주는 대시보드가 없어 상황 판단이 경험에 의존했습니다.
- 커뮤니케이션 포맷: 내부 및 고객 공지의 톤앤매너, 업데이트 주기가 사전에 정의되지 않아 혼선이 있었습니다.
5. 향후 개선 과제 (Action Plan)
우리는 이번 장애를 계기로 다음과 같은 5가지 핵심 개선 과제를 도출했습니다.
① 외부 인프라 장애 대응 SOP 수립
- 심각도 정의: Cloudflare Status(Investigating ~ Resolved)에 따른 내부 대응 레벨 매핑.
- 비상 연락망: 대시보드 접근 불가 시 벤더 핫라인 및 우회 경로 체크리스트화.
- 공지 원칙: 공급사가 “Resolved”를 띄우기 전까지는 보수적으로 “복구 중” 톤을 유지.
② 우회 전략(Bypass Strategy) 사전 정의
가장 중요한 것은 “Cloudflare가 없을 때 우리는 어떻게 생존할 것인가?“입니다.
- DNS Only 전환 프로토콜:
- 누가 승인하는가? (CTO/Lead급 위임)
- 감수할 리스크는 무엇인가? (Bot 차단 불가, 캐시 미스 급증)
- CDN 이중화 검토: AWS CloudFront나 Fastly 등을 예비(Standby)로 두거나, 트래픽을 분산하는 Multi-CDN 전략 검토.
③ 캐시 및 오리진 보호 정책 표준화
- 캐시 키 정규화: 쿼리스트링 순서 정렬, 불필요한 쿠키 제외 등을 통해 캐시 적중률(Hit Ratio)을 높이고 장애 시 변수 최소화.
- 레이어드 캐시(Layered Cache): Browser TTL, Edge TTL, Origin TTL을 분리하여 Edge가 죽어도 브라우저 캐시로 버틸 수 있는 시간 확보.
- 민감 경로 보호: 결제 등 핵심 로직은 no-store 원칙을 엄격히 적용.
④ 모니터링의 다층화
- API 연동: Datadog에 Cloudflare Status API를 연동하여 status.indicator 변경 시 즉시 알림 발송.
- Bot Score 추적: 이번 장애의 원인이었던 Bot Management의 이상 징후를 미리 알기 위해 Bot Score 급변 구간 모니터링 추가.
- 플랫폼별 헬스체크: 단순히 curl을 날리는 것을 넘어, 실제 모바일 User-Agent를 헤더에 포함한 헬스체크 프로브(Probe) 추가.
- https://www.cloudflarestatus.com/api/v2/status.json GET 요청으로 모니터링
let body = JSON.parse(dd.response.body);
let indicator = body['status']['indicator'];
// none or minor = PASS
dd.assert(
indicator === 'none' || indicator === 'minor',
`indicator must be none or minor, but got: ${indicator}`
);
⑤ 실행 체크리스트 (Playbook)
- [ ] 외부 CDN/DNS 장애 대응 플레이북 문서화
- [ ] DNS Only 전환 및 롤백 시뮬레이션
- [ ] Datadog Synthetic 룰 정식 등록
- [ ] 사내/대고객 커뮤니케이션 템플릿 작성
6. 결론
외부 인프라 장애는 언제든 다시 발생할 수 있습니다. 중요한 것은 장애를 막는 것이 아니라, 장애가 발생했을 때 얼마나 빠르고 우아하게 대처하느냐입니다.
이번 Cloudflare 사태를 통해 우리는 “CDN 의존성에 대한 대안”과 “플랫폼별 네트워크 특성의 차이”를 뼈저리게 배웠습니다. 이 기록이 안정적인 서비스를 고민하는 모든 팀에게 의미 있는 참고 자료가 되기를 바랍니다.
참고 자료:
- Cloudflare 공식 블로그
- Cloudflare Status Dashboard
- Cloudflare Incident Log (2025-11-18)
- GeekNews: Cloudflare 장애 토픽
Twodragon에서 더 알아보기
구독을 신청하면 최신 게시물을 이메일로 받아볼 수 있습니다.