Supabase 다운된 이유 | Cloudflare 다운된 이유 | Supabase is not working

1 전 세계가 함께 멈춘 11월 18일, 무엇이 진짜 문제였나

클라우드플레어가 멈추던 순간, 우리 눈앞에서 멈춘 건 트래픽 그래프가 아니라 ‘당연히 항상 켜져 있을 것 같은’ 인터넷에 대한 믿음이었다. 새벽 6시(ET) 무렵 시작된 이번 장애로 X, ChatGPT, Shopify, Dropbox, Coinbase, League of Legends까지 대형 서비스가 줄줄이 먹통이 됐다.[CF_CODE, 00:56] 클라우드플레어는 전 세계 웹 트래픽의 상당 부분을 처리하는 CDN이자 보안 레이어라, 한 번 삐끗하면 실제로 “반쪽짜리 인터넷”이 되는 구조다. 이번 사태는 거의 6시간에 걸쳐 이어졌고, 다운디텍터 신고 건수는 수천 건을 찍었다.(ABC)

사건의 핵심은 해킹도, DDoS도 아니었다. 클라우드플레어 CTO는 “봇 미티게이션을支撑하는 서비스에 잠복해 있던 버그(latent bug)가, 일상적인 설정 변경을 계기로 크래시를 일으켰고 이것이 네트워크 전체로 연쇄 확산됐다”고 밝혔다.[CF_CODE, 01:34] 이어 공개된 포스트모텀을 보면, 봇 트래픽을 관리하는 자동 생성 설정 파일이 예상보다 비정상적으로 커지면서, 해당 파일을 로드하는 소프트웨어가 한계 값을 넘기고 크래시 → 전 세계 엣지 노드로 잘못된 설정이 전파되며 장애가 증폭되는 전형적인 ‘구성 파일 한 장이 인터넷을 멈춘’ 사건이었다.(The Cloudflare Blog)

문제는 이 구조가 클라우드플레어만의 특이 케이스가 아니라는 점이다. 같은 달에 AWS, Microsoft도 대형 장애를 겪었고, Supabase 역시 status에서 “Global upstream provider outage”와 “upstream provider issue”를 반복적으로 기록하고 있다.(eaglestatus.io) 오늘 우리가 겪은 Supabase 장애도, 결국 상위 클라우드/네트워크 레이어에서 한 번 삐끗하면 그 아래에 앉아 있는 PaaS·BaaS들이 줄줄이 멈추는 구조의 일부였다.

2 보안 레이어가 스스로 만든 ‘자기 DDoS’

Fireship 영상은 이번 사건을 “인터넷을 지키려던 방패가 스스로 DDoS를 만들어 낸 날”이라고 요약한다.[CF_CODE, 01:52] 봇을 막기 위해 쌓아 올린 규칙과 구성 파일이 점점 비대해지다, 결국 그걸 처리하는 라우팅 소프트웨어의 한계를 넘어서면서 네트워크 전체를 다운시킨 것이다. 보안 레이어가 복잡해질수록, 장애의 원인은 점점 “악의적 트래픽”이 아니라 “우리 스스로 쓴 코드와 설정”으로 이동하고 있다는 걸 상징적으로 보여준다.(Medium)

Awesome 채널 영상은 클라우드플레어의 위치를 더 직설적으로 설명한다. 클라우드플레어는 DNS, CDN, DDoS 보호, SSL 종료, 캐싱, WAF, 레이트 리미팅까지 “네트워크 다이어그램에 나오는 온갖 약자를 다 맡고 있는 회사”이고, 사용자는 그 앞에 서비스 하나만 얹으면 전 세계에 안전하게 배포된 것 같은 기분을 얻는다.[CF_BAD, 01:40] 문제는 모두가 그 편리함을 선택하면서, 사실상 “AWS(us-east-1) + Cloudflare + 매니지드 DB”라는 동일한 조합 위에 쌓이고 있다는 점이다.[CF_BAD, 02:45] 보안과 가용성을 높인다고 붙인 레이어들이, 실제로는 단일 실패 지점을 더 두껍게 감싸고 있을 뿐이라는 지적이다.[CF_BAD, 03:33]

이 구조는 그대로 Supabase에도 투영된다. Supabase는 자체적으로 고가용성을 설계하지만, 실제 인프라는 특정 리전의 클라우드 공급자 위에 서 있다. Supabase 상태 페이지가 “upstream provider issue in us-east-1”을 반복해서 언급하는 이유도 여기에 있다.(status.supabase.io) 오늘 우리가 본 Supabase 장애 역시, 클라우드플레어처럼 “보안/플랫폼 레이어에 한 번 문제가 나면 그 아래의 수많은 SaaS·데이터베이스가 한꺼번에 멈추는” 체인의 일부라는 점을 잊기 어렵다.

3 ‘클라우드라서 안전하다’는 착각과, Supabase 개발자가 해야 할 일

Awesome 영상의 후반부는 꽤 불편한 메시지로 끝난다. 우리는 “클라우드 네이티브”라는 말에 안도하며, 기본 리전(us-east-1), 기본 플랜, 기본 툴을 선택하고 “자동으로 스케일하니까 괜찮겠지”라고 생각한다.[CF_BAD, 03:04] 그러나 금융, 헬스케어, 공공 서비스까지 같은 마인드로 설계되면, 대형 클라우드나 네트워크 사업자가 한 번 재채기할 때마다 사회 전체가 동시에 감기 몸살을 겪는다.[CF_BAD, 03:24] 클라우드가 리스크를 분산시키기보다는 소수의 거대 사업자에게 리스크를 집중시켜 버렸다는 것이다.[CF_BAD, 03:33]

이 과정에서 잃어가고 있는 건 “실패를 가정하고 설계하는 능력”이다. 영상은 새로운 세대의 개발자들이 구성 마법사와 AI 도우미에 익숙해지면서, 실제로 어떤 장애 시나리오가 가능한지 상상하고 대비하는 능력이 줄어들고 있다고 경고한다.[CF_BAD, 03:58] 이번 클라우드플레어 장애와 함께, Supabase 역시 “upstream provider outage”로 플랫폼·프로젝트 레벨 기능이 영향을 받았다는 공지를 반복하고 있다.(eaglestatus.io) 오늘 Supabase가 잠시 멈추는 걸 보며, 우리는 “Supabase가 다운됐다”에서 멈추지 말고 “내 아키텍처는 어디까지, 누구에게 실패를 아웃소싱하고 있지?”라는 질문까지 같이 던져볼 필요가 있다.

4 오늘 Supabase 장애를 위한 현실적인 ‘개발자 모드’ 결론

짧은 뉴스 클립은 이번 사건을 “대형 플랫폼이 한 번에 꺼진 사건”으로 요약하면서, 이것이 일회성 스파이크인지, 아니면 클라우드 인프라의 구조적 취약점인지 질문을 던진다.[CF_NEWS, 00:05][CF_NEWS, 00:49] Fireship와 Awesome의 분석, 그리고 클라우드플레어·Supabase 공식 포스트모텀을 종합하면 답은 꽤 분명하다. 이건 일회성 사고가 아니라, 단일 사업자·단일 리전에 지나치게 쏠린 인터넷 구조가 드러난 예고편이다.(The Cloudflare Blog)

Supabase는 지금은 “All Systems Operational” 상태지만, 최근 이벤트 로그에는 “Global upstream provider outage”, “us-east-1 지역 upstream issue”, “EU/APAC 리전 용량 부족으로 프로젝트 생성·업그레이드 제한” 같은 경고들이 촘촘히 쌓여 있다.(eaglestatus.io) 우리가 해야 할 일은 “Supabase가 또 멈췄네”라고 불평하는 게 아니라, 내 서비스가 그 위에 어떻게 올라가 있는지, 실패를 어디까지 상정해 두었는지를 개발자의 언어로 재점검하는 것이다. 오늘의 장애는, 우리 코드보다 먼저 인프라 다이어그램을 열어보라는 알람에 가깝다.

오늘 내가 체크할 것

Supabase status에서 내 리전 관련 과거 사건(용량 문제, upstream outage) 히스토리 Cloudflare·Supabase·AWS 등 핵심 의존 서비스의 상태 페이지와 RSS/웹훅을 한 데 묶은 알림 채널(예: EagleStatus, Slack) 구성 여부(eaglestatus.io) “장애 시에도 반드시 살아 있어야 하는 최소 기능(결제? 로그인? 공지?)” 정의와 우선 복구 순서 주기적으로 실행하는 장애 복구 연습(게임데이, 롤백 리허설)이 실제 운영 매뉴얼과 맞물려 있는지 [참고 영상 & 타임스탬프]

[클라우드/인프라]

This Cloudflare outage is bad and the web is NOT OK… (Awesome)

https://www.youtube.com/watch?v=eNRKc5WiAMk&t=96s (01:36 – Cloudflare가 담당하는 DNS/CDN/DDoS/WAF 역할 설명) [CF_BAD, 01:36] https://www.youtube.com/watch?v=eNRKc5WiAMk&t=213s (03:33 – “빅테크 한 곳이 재채기하면 웹 전체가 감기 걸린다” 비유) [CF_BAD, 03:33] https://www.youtube.com/watch?v=eNRKc5WiAMk&t=243s (04:03 – 새로운 세대 개발자가 실패를 전제로 설계하지 않는 문제 지적) [CF_BAD, 04:03] The entire internet just crashed… again (Fireship, The Code Report)

https://www.youtube.com/watch?v=tF_4baiIUiQ&t=56s (00:56 – 6시(ET)경 시작된 Cloudflare ‘internal service degradation’ 타임라인) [CF_CODE, 00:56] https://www.youtube.com/watch?v=tF_4baiIUiQ&t=94s (01:34 – CTO가 밝힌 “latent bug in bot mitigation service” 인용) [CF_CODE, 01:34] https://www.youtube.com/watch?v=tF_4baiIUiQ&t=112s (01:52 – 과도하게 커진 설정 파일이 라우팅 소프트웨어를 크래시시킨 루트 원인 설명) [CF_CODE, 01:52] Why Cloudflare Was Down (쇼츠)

https://www.youtube.com/shorts/RfXa6L8t5mo?t=5 (00:05 – ChatGPT, X, DownDetector 등 주요 서비스가 동시에 다운된 상황 요약) [CF_NEWS, 00:05] https://www.youtube.com/shorts/RfXa6L8t5mo?t=24 (00:24 – 원인이 아직 확정되지 않았으며, 트래픽 스파이크를 조사 중이라는 초반 브리핑) [CF_NEWS, 00:24] https://www.youtube.com/shorts/RfXa6L8t5mo?t=49 (00:49 – “일회성 스파이크냐, 클라우드의 구조적 취약점이냐”라는 질문 제기) [CF_NEWS, 00:49] [상태 페이지 & 포스트모텀]

Cloudflare – 18 November 2025 Outage Post-Mortem

(공식 블로그) – Bot Management 구성 파일 버그와 설정 파일 사이즈 초과로 인한 전 세계적 장애 원인 분석(The Cloudflare Blog) Supabase – Status & Incidents

https://status.supabase.com – us-east-1 리전의 upstream provider issue, EU/APAC 프로젝트 생성 용량 이슈, 플랫폼 수준 운영 중단 기록(status.supabase.io) https://eaglestatus.io/services/supabase – “Global upstream provider outage” 등 최근 이벤트 타임라인 정리(eaglestatus.io)