[2편] “우리 서비스가 잘못된 줄 알았다” 클라우드플레어 장애에서 IT 기획자가 배운 것들
[2편] “우리 서비스가 잘못된 줄 알았다”
클라우드플레어 장애에서 IT 기획자가 배운 것들
이 글은 클라우드플레어 11월 18일·12월 5일 네트워크 장애 분석 2편입니다.
1편에서 타임라인과 기술 원인을 정리했다면, 2편에서는 실무 인사이트와 체크리스트에 집중합니다.
1편 링크: [1편] “우리 서비스가 잘못된 줄 알았다” 개발자들을 멘붕시킨 클라우드플레어 네트워크 장애 분석
📚 목차
1. 두 장애의 공통점과 차이점 – “코드 한 번·설정 한 번이 전 세계를 멈춘다”
1-1. 공통점
- 둘 다 사이버 공격이 아니라, 내부 변경이 만든 ‘자가 사고’입니다.
- “한 번에 전 세계에 전파되는 변경”이 핵심 원인입니다.
- 트래픽 흐름 자체는 정상이지만, 중간 계층(프록시·WAF·Bot Management)이 500을 뿜으며 전체 체인을 끊어버린 구조입니다.
- “CDN/보안 계층 하나가 죽자, 서비스는 멀쩡한데 유저는 접속을 못 하는” 클래식한 상황을 연출했습니다.
1-2. 차이점
- 11월 18일: 데이터 분석·구성 파일 생성 로직 → 과도한 피처 수 → 메모리·에러 핸들링 문제 → 장시간 장애
- 12월 5일: 보안 취약점 대응 중 WAF 설정 변경 → Lua 예외 → 25분 내 롤백 성공
- 11월은 “구성이 점점 망가져서 크게 터진 케이스”, 12월은 “구성 한 번에 바로 크게 터졌지만 빠르게 롤백한 케이스”에 가깝습니다.
2. 장애 당시, 현장에서 개발자·기획자가 겪는 상황과 대응 흐름
이런 글로벌 인프라 장애가 올 때, 실제 서비스 운영팀·개발팀·기획팀에서는 보통 이런 흐름을 겪습니다.
- 모니터링 알람 폭주 – 응답 시간 급등, 5xx 비율 상승, 전환율 급락 등
- “우리 배포가 문제냐?” 1차 자책 – 직전 배포·설정 변경 로그를 확인하고, 필요하면 즉시 롤백
- 내부 시스템 헬스 체크 – 애플리케이션, DB, 내부 API는 멀쩡한지 확인
- 외부 인프라 확인 – Cloudflare Status, 다른 CDN·DNS·클라우드 벤더 상태 페이지 및 트위터/X 등 확인
- 원인 범위가 “우리 밖”이라는 판단이 서면
→ 긴급 공지, 장애 페이지 노출, 고객센터/CS 스크립트 업데이트 - 임시 완화 – 가능하다면 특정 기능을 끄거나, 캐시 TTL 늘리기, 다른 경로로 일부 우회하기 등
문제는, 이 모든 일이 “수 분 안에” 돌아가야 한다는 점입니다.
그래서 장애가 터지기 전에 아래와 같은 것들을 미리 준비해 두면 실제 멘탈 데미지가 줄어듭니다.
- “전 세계 장애일 때 확인할 체크리스트” 문서
- Cloudflare·AWS·GCP·Azure 등 인프라 상태 페이지 링크 모음
- “우리 쪽 문제일 때”와 “외부 인프라 문제일 때” 각각의 안내 문구 템플릿
- 경영진·CS팀에 짧게 설명할 수 있는 3줄짜리 요약 포맷
3. IT 기획자·SRE가 가져가야 할 실무 인사이트 5가지
3-1. 단일 인프라에 대한 “맹목적 신뢰”는 설계가 아니다
Cloudflare, AWS, GCP 같은 기업들은 업계 최고 수준의 기술력을 갖고 있습니다.
하지만 “사고가 안 난다”가 아니라, “사고가 나도 빨리 복구한다”에 가까운 존재입니다.
- “Cloudflare니까 괜찮겠지”가 아니라,
- “Cloudflare가 죽었을 때 우리 서비스는 어떻게 보일까?”를 설계 단계에서 같이 고민해야 합니다.
3-2. Multi-CDN / Multi-path는 “고급 옵션”이 아니라 점점 “필수 옵션”
예산과 복잡도 때문에 쉽지는 않지만, 최소한 이런 질문은 해야 합니다.
- DNS 레벨에서 Cloudflare 완전 장애 시 대체 경로를 줄 수 있는가?
- Cloudflare WAF·Bot Management가 죽었을 때, 기본적인 정적 페이지라도 직접 제공할 수 있는가?
- 최소한 중요 API는 다른 경로(예: 직접 오리진 접속)로라도 살아 있을 수 있는 구조인지?
3-3. 장애 시 “그레이드 다운(기능 축소)” 시나리오를 사전에 정의하자
모든 기능을 100% 유지하려다 같이 죽는 것보다, 핵심 기능만 살려서 최소한의 서비스라도 제공하는 전략이 낫습니다.
- 로그인·결제 같은 핵심 기능은 최대한 빠르게 살리고
- 부가 기능(추천, 알림, 실시간 통계 등)은 과감히 끌 수 있는 스위치 준비
- “장애 모드 UI”를 미리 만들어 두고, CDN 앞단에서 최소 HTML만 캐시해도 되는지 설계
3-4. 인프라 장애를 “팀 학습 소재”로 활용하기
이번 11월·12월 클라우드플레어 장애는, 사실 무료로 제공된 고급 교재에 가깝습니다.
- 사건 타임라인을 팀 위키에 정리
- “같은 일이 우리에게도 일어난다면?”을 가정한 미니 워게임·시뮬레이션
- 우리 모니터링·알람·대응 프로세스가 어디까지 커버하는지 점검
3-5. 기획 문서에도 “의존성 다이어그램”이 필요하다
IT 기획 문서를 쓸 때, 화면·플로우만 그리지 말고 최소한 이런 그림도 같이 넣어두면 좋습니다.
- 유저 → 브라우저/앱 → DNS → CDN/보안 계층 → 오리진 → 내부 서비스 → DB
그리고 각 단계마다 “여기가 죽으면 유저가 보는 화면은 무엇인지”를 한 줄씩 적어두는 것만으로도 장애 대응 퀄리티가 확 달라집니다.
4. 클라우드플레어 장애 대비 체크리스트 – IT 기획자를 위한 8가지 질문
위에서 인사이트를 개념적으로 정리했다면, 이제는 실제 문서에 그대로 붙여 넣어도 되는 수준의 체크리스트가 필요합니다.
아래 8개 질문을 팀 위키나 기획서 하단에 박아두고, 분기별로 한 번씩만 점검해도 장애 체감이 많이 달라집니다.
-
트래픽 경로를 그림으로 그려 본 적이 있는가?
유저 → 브라우저/앱 → DNS → Cloudflare(CDN/WAF) → 오리진 → 내부 서비스 → DB 구조를 한 번이라도 다이어그램으로 정리했는지 확인합니다. -
Cloudflare 장애 시, 유저 화면이 어떻게 보이는지 알고 있는가?
접속 불가? 5xx 에러 페이지? 우리 자체 장애 페이지? 어떤 화면이 뜨는지 시뮬레이션해 본 적이 있는지 체크합니다. -
외부 인프라 상태 페이지 링크 모음이 팀에 공유되어 있는가?
Cloudflare Status, 주요 클라우드 벤더(Status/AWS/GCP 등), 국내 통신사 공지 링크를 한 곳에 모아두었는지 확인합니다. -
장애 모드 공지/배너/랜딩 페이지 문구가 준비되어 있는가?
“현재 외부 인프라 장애로 서비스 이용이 원활하지 않습니다” 같은 문구를 미리 작성해 두었는지 확인합니다. -
Multi-CDN 또는 최소 우회 옵션을 검토한 적이 있는가?
모든 트래픽이 Cloudflare 한 군데로만 가는지, DNS/오리진 직접 접속 등 최소한의 대체 경로 가능성을 검토해 봤는지 체크합니다. -
CS·경영진용 3줄 설명 템플릿이 준비되어 있는가?
“무슨 문제인지 / 우리 쪽 문제인지 / 예상 대응 방향”을 3줄로 설명할 수 있는 템플릿을 문서화했는지 확인합니다. -
배포/설정 변경과 외부 인프라 장애를 구분하는 운영 플로우가 있는가?
알람이 울렸을 때 “직전 배포 확인 → 내부 헬스 체크 → 외부 인프라 상태 확인” 순서를 팀 차원에서 합의해 두었는지 봅니다. -
정기적으로 외부 인프라 장애를 주제로 회고/시뮬레이션을 해 보았는가?
“Cloudflare가 30분 죽었다고 가정하고, 우리 서비스·조직이 어떻게 움직일지”를 미리 연습해 본 적이 있는지 체크합니다.
위 8개 중 절반만 “예”라고 답할 수 있어도 이미 평균보다는 한참 앞서 있는 팀입니다.
목표는 처음부터 완벽해지는 것이 아니라, “장애가 터질수록 체크리스트의 빈 칸이 줄어드는 것”입니다.
5. 결론 – “클라우드플레어를 쓴다”는 건, 편리함 + 책임을 같이 산다는 뜻
두 번의 장애는 우리에게 이런 질문을 던집니다.
- “우리는 인터넷의 어느 층(layer)에 의존하고 있는가?”
- “그 층이 무너졌을 때, 우리는 유저에게 뭐라고 말할 수 있는가?”
클라우드플레어를 포함한 거대 인프라 기업들은 앞으로도 계속 쓰게 될 가능성이 큽니다. 속도·보안·운영 편의성 측면에서 얻는 이득이 너무 크기 때문입니다.
그래서 현실적인 결론은 이 정도일 것 같습니다.
- “클라우드플레어를 쓰지 말자”가 아니라,
- “클라우드플레어가 또 한 번 멈췄을 때 우리는 이전보다 덜 멘붕할 수 있을까?”
이 2편이, 그 질문에 대한 체크리스트 한 장 정도가 되어주면 충분합니다.
다음 장애 때 알람이 울리면, 최소한 이렇게 말할 수 있게 되는 거죠.
“일단 우리 서비스 로그는 멀쩡한지 보고, 다음은 인프라 상태부터 확인하자.”
FAQ – 자주 나올 법한 질문들
Q 이렇게 자주 장애 나는데, 그냥 클라우드플레어 안 쓰는 게 낫지 않나요?
A
완전히 배제하기는 현실적으로 어렵습니다.
DDoS 방어, 글로벌 캐싱, WAF, Bot Management 등 “혼자 만들기에는 너무 비싼 기능”들을 묶어서 제공하기 때문입니다.
대신,
- “모든 것을 Cloudflare에 의존할지” vs “핵심 기능만 Cloudflare를 타게 할지”를 구분하고
- 장애 시 최소한의 우회 경로를 설계해 두는 쪽이 실용적인 선택입니다.
Q 우리 서비스에서는 최소한 무엇부터 점검해야 할까요?
A- ① 현재 트래픽 경로(유저 → DNS → CDN → 오리진)를 그림으로 한번 그려 보고
- ② 각 단계 장애 시 유저 화면이 어떻게 보이는지 확인하고
- ③ “장애 모드 페이지”와 “CS·경영진용 3줄 설명” 템플릿을 준비하는 것부터 추천합니다.
Q 팀 회고에서 이 사건을 어떻게 활용하면 좋을까요?
A- 11/18, 12/5 실제 타임라인을 짧게 요약해서 공유하고
- “같은 일이 났을 때 우리 Alert는 어디서 울릴까?”를 화이트보드에 적어 보고
- 그림을 그려가며 “우리의 Single Point of Failure(SPOF)가 어디인지” 찾는 연습 재료로 쓰면 좋습니다.