클라우드플레어, 3주 만에 또 장애… 국내외 서비스 잇따라 접속 불안

1. 이번 장애, 무엇이 어떻게 발생했나

국내 시간 기준 오후 시간대, 클라우드플레어의 네트워크 구성 요소 일부에서 이상이 감지됐고, 대시보드/API 레벨에서 오류 표기가 발생했습니다. 현상은 지역과 서비스별로 달랐습니다. 어떤 곳은 응답 지연만 있었고, 어떤 곳은 아예 연결 실패가 났습니다. 대체로 수십 분 내 복구가 진행됐고 이후 관찰 단계로 전환됐습니다.

특징은 ‘단일 기능 고장’이 아니라 API·대시보드와 연계된 트래픽 경로, 정책 적용 경로가 영향을 받았다는 점입니다. 사용 중인 제품 조합(WAF, CDN, DNS, Bot Management, Zero Trust 등)에 따라 체감 증상이 달랐고, 결과적으로 비즈니스 로그인이 막히거나, 정적 리소스가 느리게 내려오거나, 일부 라우팅에서 타임아웃이 발생했습니다.

2. 영향권: 배민·게임·커머스까지 순차적인 흔들림

국내에서는 배달앱, 일부 게임 서비스(접속 끊김·매칭 지연), 커머스/커뮤니티, 통신사 관련 페이지 등에서 일시적 접속 문제가 보고됐습니다. 금융·가상자산 쪽에서도 접속 지연을 호소하는 공지가 있었고, 몇몇 서비스는 수분 단위로 정상화 알림을 재발송했습니다.

장애가 ‘전면 중단’ 형태로 동일하게 나타난 것은 아닙니다. 같은 서비스 안에서도 사용자 위치, 통신사, 캐시 적중 여부에 따라 결과가 달랐습니다. 엣지 캐시가 살아 있는 정적 콘텐츠는 상대적으로 무난히 내려왔고, API 인증이나 대시보드 연동처럼 실시간 상호작용이 필요한 경로는 영향이 컸습니다.

결론적으로 “일부 구간의 불안정”이었다고 정리되지만, 사용자 입장에서는 체감이 큽니다. 결제 버튼이 멈추거나 게임 접속이 튕기는 일은 경험적으로 ‘먹통’으로 받아들여지기 때문입니다.

3. 왜 클라우드플레어 이슈가 대규모로 번질까

클라우드플레어는 CDN과 DNS, 보안 게이트웨이, L3~L7 보호, API 가속 등 웹 운영의 ‘중간자’ 역할을 넓게 맡습니다. 전 세계 트래픽의 유의미한 비중이 이 네트워크를 지나기 때문에, 구성 오류나 특정 POP의 이상은 곧바로 광범위한 서비스 체감으로 이어집니다.

글로벌 엣지 구조의 명암

장점은 빠른 응답과 뛰어난 방어력입니다. 반대로, 공통 플랫폼에서 설정·정책이 실시간 전파되는 구조라면, 실수나 버그가 빠르게 ‘전 세계적으로’ 전파될 가능성도 있습니다. 지난 이슈에서도 내부 권한·정책 관련 오류가 원인으로 지목된 바 있고, 이번에도 대시보드/API 레벨의 영향을 받았다는 점이 유사성을 떠올리게 합니다.

의존도와 카스케이딩

많은 기업이 DNS, CDN, WAF를 묶어 하나의 사업자에 의존합니다. 비용 최적화와 운영 단순화라는 합리적인 이유가 있지만, 문제가 생길 때는 장애가 계단식으로 확산됩니다. 이른바 ‘카스케이딩 장애’입니다. 복구가 빠르더라도, 그 짧은 구간이 비즈니스에 준 타격은 작지 않습니다.

4. 내부 오류 vs 공격 가능성: 우리가 확인한 단서

공식 커뮤니케이션이 시작되기 전까지는 단정이 어렵습니다. 다만 최근 유사 사례에서 외부 공격보다는 내부 설정/권한/정책의 전파 과정에서 오류가 발생한 전례가 있었습니다. 이번에도 대시보드/API를 사용하는 고객이 오류를 경험했다는 안내는 내부 구성 변경의 영향을 떠올리게 합니다.

핵심은, 공격이든 내부 오류든 ‘복구 절차와 우회 전략’이 준비되어 있느냐입니다. 원인이 달라도 대응 프레임은 크게 다르지 않습니다.

실무적으로는, 공격 징후가 없더라도 레이어별 지표(HTTP 5xx, TLS handshake error, DNS NXDOMAIN 스파이크, 오리진 에러율)를 따로 확인해야 합니다. 단일 사업자 이슈로 오판하고 내부 문제를 놓치면, 복구 골든타임을 흘리게 됩니다.

5. 서비스 운영자 체크리스트(즉시/단기/중기)

즉시 점검(실시간)

• 상태 페이지·벤더 알림 구독: 벤더 공지의 타임스탬프와 우리의 에러 피크를 대조해 장애 상관관계를 잡습니다.
• 에러 버짓 확인: 현재 5xx 비율, P95/P99 지연 시간, 실패 트랜잭션 수를 모니터링 대시보드 상단에 고정합니다.
• 페일오버 룰 가동: DNS 헬스체크 기반 이중화가 있다면 즉시 전환을 검토합니다. 정적 리소스는 서브도메인으로 분리해 다른 CDN으로 라우팅합니다.
• 캐시 TTL 임시 상향: 변동이 적은 정적 자산의 TTL을 높여 오리진 부하와 엣지 의존을 동시에 줄입니다.
• 장바구니/결제 보호: 결제 API 타임아웃을 늘리고, 재시도 정책을 ‘지수 백오프 + 멱등키’로 전환합니다.

단기 개선(1~2주)

• 멀티-CDN 파일럿: 주요 정적 리소스와 이미지 도메인부터 이원화해 트래픽 분산 룰을 시험합니다.
• 권한·정책 변경의 릴리스 게이트: 인프라 정책은 애플리케이션 릴리스와 분리해 카나리 배포를 적용합니다.
• 런북 업데이트: ‘벤더 장애 의심’ 시 수행할 체크 항목, 롤백 기준, 커뮤니케이션 템플릿을 문서화합니다.
• 장애 훈련: 분기 1회, DNS 전환/오리진 스케일아웃/리전 격리 훈련을 실제 도메인으로 리허설합니다.

중기 전략(분기~반기)

• DNS 레지질리언스: 권위 DNS를 이중화(서로 다른 사업자)하고, 헬스체크와 가중치 라우팅을 병행합니다.
• API 게이트웨이 이원화: 인증·결제·검색 등 핵심 API는 경로를 분산하고, 클라이언트 SDK 수준에서 백업 엔드포인트를 내장합니다.
• 오리진 독립성 강화: 이미지·파일 업로드는 사전 서명 URL로 전환하고, 엣지 함수 의존 로직은 코어 경로에서 분리합니다.
• SLO 재설계: 사용성 기준(체감 지연/실패 허용치)으로 서비스 목표를 재정의하고, 가시화 지표를 표준화합니다.

6. 기술적 배경: CDN, DNS, WAF, API의 얽힘

현대적 웹은 ‘경로가 하나’가 아닙니다. 브라우저는 HTML을 받은 뒤 수십~수백 개의 정적 리소스를 병렬로 요청합니다. 그 과정에서 CDN 캐시, 이미지 최적화, JS 번들, 폰트, API 호출이 얽혀 있습니다. 이 중 하나라도 병목이 생기면 전체 로드가 체감상 멈춥니다.

CDN과 캐시 적중

캐시는 장애 시 생명줄입니다. 하지만 캐시 키가 엣지마다 달라지거나, 쿠키·쿼리스트링이 캐시 정책을 무효화하면 적중률이 떨어집니다. 장애 대비 관점에서, 정적 자산 도메인은 가능한 한 쿠키 프리로 운영하는 것이 안전합니다.

DNS와 헬스체크

DNS는 트래픽 분산의 첫 관문입니다. TTL을 지나치게 길게 두면 장애 시 전환이 더딥니다. 반대로 너무 짧으면 평시 오버헤드와 레졸버 캐시 미스가 늘어납니다. 핵심 도메인과 서브도메인별로 TTL 전략을 다르게 가져가는 게 현실적입니다.

WAF/보안 정책

정책 업데이트가 전 세계 엣지에 전파될 때, 특정 룰의 오탐이 4xx/5xx 폭증으로 이어질 수 있습니다. 룰 변경은 반드시 ‘모니터 모드(로그만)’ 구간을 거쳐야 합니다. 또한 비즈니스 크리티컬 경로(결제, 로그인)는 화이트리스트를 별도로 유지합니다.

API와 백오프

클라이언트가 실패 후 즉시 재시도하면 오리진은 더 힘들어집니다. 지수 백오프, 멱등키, 서킷 브레이커는 장애 시 필수입니다. 모바일 앱은 백업 엔드포인트를 내장하고, 서버가 5xx인 경우 사용자에게 즉시 재시도를 유도하기보다 “잠시 후 자동 재연결” 경험을 설계하는 편이 낫습니다.

7. 사용자 관점: 접속 오류 때 할 수 있는 현실적 조치

일반 사용자도 할 수 있는 건 있습니다. 먼저, 같은 서비스라도 웹/앱이 다르게 동작하니 전환을 시도해보세요. 모바일 데이터와 Wi‑Fi를 바꿔보는 것도 한 방법입니다. DNS 캐시를 비우면 도움이 될 때가 있습니다. PC라면 브라우저 강력 새로고침(Ctrl + F5)을 해보고, 그래도 안 되면 잠시 시간을 두는 것이 현실적으로 가장 스트레스를 줄입니다.

• 결제 중단 시: 결제 완료 여부를 두 채널(앱 알림·이메일 등)로 확인한 뒤 재시도하세요. 멱등 처리가 안 된 서비스는 중복 결제가 날 수 있습니다.
• 게임 접속 실패 시: 재로그인보다 잠깐 대기 후 재시도가 효율적입니다. 빈번한 재시도는 서버에 부담을 줘 오히려 지연을 키울 수 있습니다.
• 업무 서비스: VPN이나 보안 게이트웨이를 경유한다면, 임시로 직결 접속을 시도해 차이를 확인합니다.

8. 재발 방지 흐름: 관측(Observability)과 런북

관측은 단순한 모니터링을 넘습니다. 벤더 상태, 우리 오리진, 클라이언트 측 Web‑Vitals를 함께 봐야 “어디가 문제인지”를 빠르게 식별할 수 있습니다. APM, RUM, 로그, 벤더 상태 페이지를 하나의 뷰에서 비교하는 대시보드를 만들어 두면, 의사결정 속도가 달라집니다.

좋은 런북의 조건

• 트리거: 어떤 지표가 얼마를 넘으면 가동하는가
• 행동: DNS 전환·라우팅 변경·룰 비활성화 순서
• 커뮤니케이션: 언제 누구에게 무엇을 알릴지(사용자 공지 템플릿 포함)
• 롤백: 정상화 신호와 관찰 시간, 재전개 기준

그리고 정기 리뷰가 필요합니다. 매번 장애가 다르게 오기 때문에, 이전 케이스의 배움을 반영하지 않으면 런북은 금세 낡습니다.

9. 마무리 정리: ‘의존’에서 ‘회복탄력성’으로

클라우드플레어는 여전히 업계에서 신뢰받는 인프라입니다. 복구 속도, 글로벌 커버리지, 보안 역량 모두 검증되어 있습니다. 다만, 최근처럼 짧은 간격으로 이슈가 반복되면 기업 측도 운영 철학을 점검할 필요가 있습니다. 핵심은 의존을 줄이는 것이 아니라, 실패를 전제한 회복탄력성을 설계하는 것입니다.

멀티 벤더 도입이 만능은 아닙니다. 운영 복잡도가 커지고 비용도 늘어납니다. 그럼에도 결제·로그인·검색처럼 핵심 경로만큼은 이원화를 검토할 가치가 있습니다. 장애는 언제든 옵니다. 중요한 건, 사용자 입장에서 ‘서비스가 멈추지 않았던 것처럼’ 느끼게 만드는 준비입니다.