인터넷이 단일장애점이 되었다 — 클라우드 의존 리스크의 SRE 해부학

“자가치유 시스템이 자가파괴 시스템이 되는 순간, 우리는 자동화의 역설과 마주한다.”

들어가며: 2025-2026 클라우드 장애 연표

지난 18개월간 글로벌 인터넷 인프라는 전례 없는 연쇄 장애를 겪었다. 개별 사건이 아니라 구조적 패턴이다.

일시	사건	영향 범위	근본 원인
2024.07.19	CrowdStrike 글로벌 장애	850만 Windows 디바이스 BSOD	설정 업데이트 글로벌 즉시 배포
2025.09.26	한국 NIRS 데이터센터 화재	858TB 정부 데이터 영구 소실	동일 건물 내 백업, DR 센터 미가동
2025.10.19	AWS US-EAST-1 DynamoDB 장애	14.5시간, 1,000개+ 서비스 중단	DNS 레이스 컨디션
2025.11.18	Cloudflare 1차 장애	인터넷 트래픽 20-25% 영향	설정 변경 글로벌 전파, Rust panic
2025.12.05	Cloudflare 2차 장애	HTTP 트래픽 28% 영향	동일 패턴 반복 (17일 만에)
2026.02.20	Cloudflare 3차 장애	BYOIP 프리픽스 25% 삭제	API 빈 문자열 쿼리 → 전체 삭제

이 사건들은 하나의 테제로 수렴한다: 인터넷 자체가 하나의 단일장애점(Single Point of Failure)이 되어가고 있다. 클라우드 인프라의 집중, 자동화의 복잡성, 그리고 디지털 주권의 부재가 만들어낸 구조적 취약성이다.

이 글에서는 세 가지 축으로 분석한다.

레이스 컨디션 → 글로벌 장애: 단일 버그가 어떻게 인터넷을 멈추는가
인프라 집중의 역설: “Too Big to Fail”이 된 클라우드 인프라
디지털 주권 전쟁: 서버 위치가 아닌 컨트롤 플레인이 결정하는 관할권

Part 1: 레이스 컨디션 → 글로벌 장애

DynamoDB가 인터넷에서 사라진 밤

2025년 10월 19일 밤 11시 48분(PDT). dynamodb.us-east-1.amazonaws.com의 DNS 레코드가 비었다. IP 주소가 0개. DynamoDB가 말 그대로 “인터넷에서 사라졌다.”

Signal, Slack, Zoom, Reddit, Snapchat, Roblox, Venmo, Robinhood, Coinbase, Duolingo, Ring 카메라, Amazon 리테일, Prime Video, Alexa — 1,000개 이상의 서비스가 연쇄적으로 멈췄다. 프리미어리그 축구 경기까지 영향을 받았다.

근본 원인은 DNS 관리 시스템의 **잠복 레이스 컨디션(latent race condition)**이었다.

기술적 상세: DNS Planner와 Enactor의 충돌

DynamoDB의 DNS 관리는 두 컴포넌트로 구성된다:

DNS Planner: 로드 밸런서 상태를 모니터링하고 트래픽 가중치가 포함된 “DNS 플랜”을 생성
DNS Enactor: DNS 플랜을 Route 53에 적용. 3개 가용영역에 각 1개씩, 총 3개 인스턴스가 독립적으로 운영

핵심 설계 결정이 있었다. Enactor 인스턴스들은 의도적으로 분산 락(distributed lock) 없이 운영되었다. 글로벌 데드락을 피하기 위해서였다. “이벤추얼 컨시스턴시로 충분하다”는 가정 — 정상 상태에서는 맞는 말이었다.

장애 시퀀스는 이렇다:

1. Enactor #1이 비정상적으로 느려짐 (원인 미상)
2. 동시에 Planner가 비정상적으로 빠르게 새 플랜을 생성 (원인 미상)
3. Enactor #2가 최신 플랜을 빠르게 전체 엔드포인트에 적용
4. Enactor #2 완료 → 오래된 플랜 세대에 대한 정리(cleanup) 프로세스 트리거
5. 이 순간, 느렸던 Enactor #1이 훨씬 오래된 플랜을 리전 엔드포인트에 적용 완료
   → 최신 플랜을 덮어씀
6. Enactor #1의 stale-check가 실패 — 자신의 플랜이 삭제 대상인 것을 인식 못 함
7. 정리 프로세스가 오래된 플랜 감지 → 리전 DynamoDB 엔드포인트의 모든 IP를 삭제
8. 자동 복구 불가능한 비일관 상태에 빠짐 → 수동 개입 필요

Gergely Orosz(Pragmatic Engineer)가 지적했듯이, AWS는 포스트모템에서 Enactor #1이 왜 느려졌는지, Planner가 왜 가속했는지, 정리 프로세스가 왜 선택적이 아닌 전체 삭제를 수행했는지 설명하지 않았다. “무엇이 실패했는지”만 말했을 뿐, “무엇이 실패를 유발했는지”는 말하지 않은 것이다.

복구가 장애보다 어려운 이유

DynamoDB DNS는 약 2시간 37분 만에 복구되었다. 하지만 전체 인시던트는 14.5시간 지속되었다. 왜?

DynamoDB가 복구되자 EC2의 내부 시스템인 DWFM(DropletWorkflow Manager)이 일제히 리스 재확립을 시도했다. 이것이 congestive collapse(혼잡 붕괴)를 일으켰다. 각 리스 시도가 타임아웃되고, 타임아웃된 요청이 큐에 쌓이고, 큐가 처리 속도보다 빠르게 성장하는 양성 피드백 루프. 고전적인 thundering herd 패턴이다.

DynamoDB 복구 (2:25 AM)
  → DWFM 전체 플릿 동시 재접속 시도
    → 리스 타임아웃 > 리스 완료 속도
      → 큐가 처리보다 빠르게 성장
        → congestive collapse (4:14 AM까지 지속)
          → 수동 스로틀링 + 선택적 호스트 재시작으로 개입

그리고 두 번째 파도가 왔다. NLB(Network Load Balancer)의 헬스체크가 네트워크 상태가 아직 전파되지 않은 새 EC2 인스턴스를 “비정상”으로 판정하고, 자동 AZ DNS 페일오버를 트리거해서 멀티-AZ 로드 밸런서의 용량을 제거했다. 이로 인해 Lambda의 내부 플릿이 언더스케일링되었고, 오전 7시에 두 번째 장애 파도가 일어났다.

복구 시스템이 복구 과정에서 새로운 장애를 만들어냈다. 복구가 장애보다 어려웠다.

SRE 교훈: 자가치유가 자가파괴가 되는 역설

DEV Community의 분석이 핵심을 찌른다: “복원력을 위해 설계된 자가치유 시스템이 장애의 주요 벡터가 되었다.” AWS는 복구를 시작하기 위해 전 세계의 자동화를 중단해야 했다.

여기서 SRE가 가져갈 것들:

자동 복구에 하드 세이프티 바운드가 필요하다. 정리 프로세스가 “모든 DNS 레코드 삭제”를 실행할 수 있어서는 안 된다. 삭제 상한선이 있어야 한다.
이벤추얼 컨시스턴시는 크리티컬 패스 DNS에 위험하다. 분산 락의 데드락 리스크를 피하려다 전체 리전 장애 리스크를 만들었다.
서킷 브레이커가 의존성 경계마다 필요하다. EC2, Lambda, STS, IAM, Connect, NLB — 모두 DynamoDB에 의존했지만 효과적인 서킷 브레이커가 없었다. DynamoDB가 죽자 다 같이 죽었고, 살아나자 다 같이 stampede했다.
복구 모드의 임계값은 정상 상태와 달라야 한다. NLB 헬스체크는 정상 상태의 판정 기준으로 복구 중인 인스턴스를 평가했다. 복구 중에는 다른 임계값이 필요하다.

Part 2: 인프라 집중의 역설

Cloudflare 3연속 장애 — 동일 안티패턴의 반복

Cloudflare는 2025년 11월부터 2026년 2월까지 4개월 동안 세 차례 대규모 장애를 겪었다. 세 사건 모두 동일한 구조적 결함을 공유한다: 설정 변경의 글로벌 즉시 전파, 카나리 배포 부재.

1차 장애 (2025.11.18): ClickHouse DB 권한 변경이 Bot Management 피처 파일의 메타데이터를 2배로 증가시켜 하드코딩된 200개 한계를 초과. Rust 코드의 .unwrap()이 panic을 일으켰다. 설정은 수초 내에 전 세계 플릿에 전파되었다. 카나리 없음, 검증 게이트 없음. 결과: 인터넷 트래픽의 20-25% 영향, ChatGPT·Spotify·Discord·Claude 등 월간 활성 사용자 24억 명이 영향권.

더 심각한 문제가 있었다. Cloudflare의 대시보드 로그인이 Turnstile(CAPTCHA)에 의존하고, Turnstile은 Workers KV에 의존하는데, 세 서비스 모두 다운되었다. 엔지니어가 장애를 수정하기 위해 접속해야 할 대시보드가 장애 중인 서비스에 의존하는 순환 의존성. SRE 안티패턴의 교과서적 사례다.

2차 장애 (2025.12.05): CVE-2025-55182 대응을 위한 WAF 버퍼 증가 롤아웃 중, 테스트 도구 비호환성을 발견한 엔지니어가 글로벌 설정 시스템으로 테스트 도구를 비활성화. FL1 프록시 서버에서 Lua nil 참조 에러. HTTP 트래픽의 28% 영향. 1차 장애로부터 17일 후. 1차 포스트모템에서 약속한 단계적 설정 배포를 “아직 구현하지 못했다”고 인정.

3차 장애 (2026.02.20): 자동 정리 서브태스크가 BYOIP 프리픽스를 조회할 때 ?pending_delete 파라미터를 값 없이 전달. 서버가 빈 문자열을 “전체 조회”로 해석. 약 1,100개의 BYOIP 프리픽스(전체의 25%)가 삭제되고 BGP 경로가 철회되었다. Uber Eats, Bet365, Wikipedia 등이 접속 불가. 결함이 있는 코드는 15일 전에 머지되었지만 스테이징 환경의 목 데이터로는 잡히지 않았다.

CrowdStrike와의 비교: 동일한 안티패턴

차원	CrowdStrike (2024.07)	Cloudflare (2025.11)
트리거	설정 업데이트	설정 업데이트 (피처 파일)
검증	자동 검증기가 놓침	검증 없음
배포 방식	글로벌, 즉시	글로벌, 수초
카나리	없음	없음
영향 범위	850만 Windows 디바이스	인터넷 트래픽 20%+
실패 모드	BSOD (크래시)	Rust panic (.unwrap())

4sysops의 분석: “Cloudflare는 CrowdStrike의 실수를 반복했다 — 소규모 호스트 그룹에서 먼저 테스트하지 않고 전체 인프라를 업데이트했다.”

이것은 개별 기업의 실수가 아니라 산업 전체의 구조적 문제다. Meta(2021, BGP 설정), Datadog(2023, Ubuntu 업데이트), Google Cloud(2024, Spanner 쿼터) — 모두 동일 패턴이다.

”Too Big to Fail” — 인프라 판 리먼 브라더스

수치로 보자:

Cloudflare는 전 세계 웹사이트의 20.4%, 상위 100만 사이트의 **48.7%**를 서비스
리버스 프록시 시장 점유율 81.5-82.3% (2위 Amazon CloudFront는 1.6%)
초당 5,000만+ HTTP 요청 처리
CDN 시장 HHI 지수(Herfindahl-Hirschman Index): 3,410 (2,500 이상은 “고집중” 판정)
인터넷 트래픽의 **20-25%**가 Cloudflare를 통과

2008년 금융위기와의 비유가 적확하다. 당시 규제 당국은 특정 금융기관의 붕괴가 연쇄적 경제 실패를 유발한다는 것을 인식하고 “시스템적으로 중요한 금융기관(SIFI)” 지정과 규제 프레임워크를 구축했다. 인터넷 인프라도 동일한 문제를 안고 있지만, 규제 프레임워크나 안전망이 없다.

더 나아가 보안 차원의 리스크가 있다. Krebs on Security가 지적했듯이, Cloudflare 장애 시 기업들이 Cloudflare에 위임한 SQL 인젝션 방어, 크리덴셜 스터핑 방어, XSS 차단, 봇 완화가 모두 사라진다. 공격자에게는 보호 레이어가 벗겨진 공격 윈도우가 열리는 것이다.

SRE 교훈: 의존성 격리와 fail-open

Cloudflare의 “Code Orange” 대응은 그 자체로 SRE 교훈이다:

설정을 코드처럼 취급하라. Cloudflare는 소프트웨어 릴리스에는 적용하던 보호 게이트를 설정 변경에는 적용하지 않았다. Health Mediated Deployment(HMD) — 직원 트래픽 먼저, 그 다음 고객 비율을 점진적으로 올리고, 이상 감지 시 자동 롤백하는 구조가 필요하다.
Fail-open 설계. Bot Management 실패가 5xx를 반환하는 대신, 트래픽을 통과시켜야 한다. 가용성이 우선인 경로에서는 미지의/에러 상태가 “허용”을 기본값으로 가져야 한다.
인시던트 대응 도구는 모니터링/제어 대상 시스템과 독립적이어야 한다. 대시보드 → Turnstile → Workers KV의 순환 의존성은 장애 시 엔지니어의 접근 자체를 차단했다.
서킷 브레이커로 전파를 차단하라. 설정 배포 중 비정상 에러율을 감지하면 즉시 롤아웃을 중단하는 메커니즘, 삭제 작업이 예상 범위를 초과하면 중단하는 메커니즘이 필요하다.
프로덕션 Rust 코드에서 .unwrap()은 금지다. 에러 경로에서의 .unwrap()은 C/C++ 프로덕션에서의 assert()와 같다. 세이프티 크리티컬 코드는 모든 에러 경로를 명시적으로 처리해야 한다.

Part 3: 디지털 주권 전쟁

한국 NIRS 화재 — 주권은 있었으나 복원력이 없었던 사례

2025년 9월 26일, 대전 국가정보자원관리원(NIRS) 데이터센터에서 리튬이온 배터리가 유지보수 중 폭발했다. 결과:

858TB의 정부 데이터 영구 소실 — 2018년부터 2025년까지의 행정 결재, 정책 연구, 공공 서비스 기록
745개 정부 시스템 영향, 700개+ 디지털 서비스 중단
모바일 신원 확인, 세금 처리, 응급 대응 시스템, 우편 서비스 마비
75만 명의 공무원 데이터 영향
10월 중순까지 약 1/3만 복구; 대부분의 소실 데이터는 영구적으로 복구 불가

왜 이렇게 되었나? G-Drive 시스템(2017년 구축)은 데이터 주권 확보와 보안 극대화를 위해 설계되었다. 치명적 결함: 백업이 동일 건물 내 별도 장비에 저장되어 있었다. 화재가 원본과 백업을 동시에 파괴했다. 공주에 있는 재해복구센터는 13년간 지연되어 건설은 완료했지만 예산 부족으로 가동하지 못했다. 2025년 할당 예산은 16억 원(110만 달러)에 불과했다.

254억 원의 2024년 IT 인프라 개선 예산은 집행되지 않았다. 장비의 34.6%가 노후화된 상태였다.

ASPI Strategist의 평가가 정곡을 찌른다: “국가 소유는 이중화를 보장하지 않았다. 형식적 통제는 엔지니어링 규율을 대체하지 못했다.”

이 사건은 디지털 주권 논의의 핵심 역설을 보여준다. 주권을 위해 모든 것을 국내에, 정부 통제하에 두었지만, 주권 없는 복원력은 단일장애점이 된다. 하이퍼스케일 클라우드 환경이 맞춤형 국가 시스템보다 복원력 설계에서 우위에 있는 경우가 많다.

US CLOUD Act과 FISA 702 — 서버 위치가 아닌 제공자 국적이 관할권을 결정한다

디지털 주권의 다른 축은 법적 관할권이다. 여기서 핵심 법률 두 가지:

US CLOUD Act (2018): 미국 정부가 전자통신 서비스 제공자에게 데이터 공개를 강제할 수 있다 — 데이터가 물리적으로 어디에 저장되어 있든. 프랑크푸르트, 도쿄, 서울의 서버에 저장된 데이터도 제공자가 미국 법인이면 접근 가능하다. “EU 데이터 리전”을 선택해도 CLOUD Act 노출은 변하지 않는다. 어떤 계약도 이를 무효화할 수 없다.

FISA Section 702: CLOUD Act가 개별 영장 기반이라면, FISA 702는 연간 프로그램 수준의 승인으로 외국인 통신의 대량 수집을 허용한다. 개별 영장 없이. EU 거주자의 데이터가 당사자나 유럽 기관이 모르는 사이에 접근될 수 있다.

이것은 추상적인 법률 문제가 아니다. 실제 선례가 있다:

Microsoft가 이스라엘 군 부대(Unit 8200)의 Azure 접근을 차단
X(트위터)/일론 머스크가 1.2억 유로 벌금 후 유럽위원회의 광고 계정을 차단
미국이 우크라이나와의 정보 공유를 일시 중단
바이든 행정부의 AI 확산 규칙이 유럽 동맹국에 대한 고급 칩 판매를 제한

킬스위치 시나리오 — 컨트롤 플레인 의존성의 정치적 리스크

Andrea Fortuna의 분석(2026년 1월): “병원이 환자 시스템에 로그인할 수 없다. 세금 포털이 ‘서비스 이용 불가’를 표시한다.”

미국 정부가 클라우드 접근을 차단할 수 있는 법적 메커니즘은 이미 존재한다:

IEEPA(국제비상경제권한법): 국가안보/외교정책/경제 관련 비상사태 선언 시 상거래 규제 권한
수출통제: 상무부 Entity List를 통한 기술 수출 제한
연방계약 권한: 미국 기술 기업에 대한 계약 위협

핵심 약점은 컨트롤 플레인 의존성이다:

IAM/SSO (인증·인가)
빌링 및 계약 집행
컨트롤 플레인 API
키 관리 시스템
플랫폼 거버넌스 및 서비스 약관

“그 스위치가 외부 관할권에 속할 때, 의존성은 설계상 정치적이 된다.”

유럽의 대응: GAIA-X에서 EURO-3C까지

유럽은 미국 클라우드 의존도를 줄이기 위한 다중 이니셔티브를 추진 중이다:

GAIA-X: 2020년 프랑스-독일 공동 출범, 100억 달러+ 투입, 180개+ 데이터 스페이스. 하지만 미국 기업(AWS, Google, Microsoft)이 참여하면서 “빅테크의 트로이 목마”라는 비판.

EuroStack: 10년간 3,000억 유로 투자 계획, 초기 100억 유로 기술 펀드.

EURO-3C (2026.03 발표): Telefonica 주도, 유럽위원회 지원, 70개+ 엔티티 참여. 새 플랫폼을 처음부터 구축하는 대신 기존 국가 인프라를 연합 네트워크로 연결하는 현실적 접근. Telefonica CDO: “유럽이 처음부터 하이퍼스케일러를 만드는 것은 매우 어렵다. 유럽은 지금 기술을 사용하는 것뿐 아니라 기술을 만드는 데 투자해야 한다.”

프랑스 SecNumCloud 3.2: ANSSI의 최고 클라우드 보안 기준. FISA에 대응해 유럽법의 배타적 적용을 요구하며 역외 미국법을 배제. OVHcloud, 3DS OUTSCALE이 인증 취득.

Gartner 예측: 유럽 소버린 클라우드 IaaS 지출이 2025년 69억 달러에서 2026년 126억 달러로 83% 성장. 2027년에는 북미를 추월 전망.

일본의 하이브리드 모델: 기술·운영·재정 3축 주권

일본은 다른 접근을 택했다. 고립이 아닌 하이브리드 모델 — 주권적 통제를 유지하면서 최첨단 기술에 대한 접근도 확보.

정부 클라우드 시스템이 671개에서 2,918개로 335% 증가, 약 330개 보안 벤치마크 요건으로 관리.

3축 주권 모델:

기술 주권: 민감 정보를 다루는 모든 데이터센터, 네트워크, 서버가 일본 내에 위치
운영 주권: 일본 인력이 운영, 암호화 키 관리, 네트워크 모니터링, 패치 사이클 담당
재정 지원: 경제안전보장추진법(METI, 2024)으로 국내 클라우드 공급망 지원

SoftBank+Oracle의 소버린 클라우드(Oracle Alloy 기반, 2026년 4월 동일본 론칭), Fujitsu의 Takane LLM(퍼블릭 클라우드를 사용할 수 없는 데이터용) 등 민간 파트너십도 활발하다.

SRE 교훈: 의존성을 설계하라

멀티클라우드는 운영 모델이다. Gartner에 따르면 기업의 76%가 2개 이상의 퍼블릭 클라우드를 사용한다. 단순한 트렌드가 아니라 운영 모델로서의 멀티클라우드.
컨트롤 플레인 소유권이 진정한 주권이다. 데이터센터 위치가 아니라 IAM, 빌링, API, 키 관리, ToS가 진정한 통제 지점이다.
키 관리 주권은 타협 불가다. 암호화 키가 클라우드 제공자가 아닌 조직/국가 엔티티에 의해 관리되어야 한다.
클라우드 제공자의 API 접근이 철회되는 시나리오를 아키텍처에 반영하라. 정치적 리스크를 엔지니어링 문제로 전환해야 한다.

결론: SRE가 할 수 있는 것

이 세 가지 축의 분석은 하나의 결론으로 수렴한다: 의존성은 숨어 있고, 장애는 의존성을 따라 전파되며, 복구는 장애보다 어렵다.

다음은 SRE 팀이 내일부터 실행할 수 있는 체크리스트다.

백업과 복원력

3-2-1-1-0 백업 규칙 준수: 3개 복사본, 2가지 미디어, 1개 오프사이트, 1개 에어갭/불변, 0개의 복구 테스트 에러
백업이 프라이머리와 물리적으로 분리된 위치에 있는지 확인 (NIRS의 교훈: 같은 건물 = 백업 없음)
분기별 DR 테스트 — 백업의 존재가 아닌 실제 복구를 검증

배포와 변경 관리

모든 설정 변경에 카나리 배포 적용 (코드뿐 아니라 설정도)
설정 변경의 글로벌 즉시 전파 금지 — 직원 트래픽 → 1% → 5% → 25% → 100% 단계
이상 감지 시 자동 롤백 메커니즘
설정 파일을 신뢰할 수 없는 입력처럼 검증

서킷 브레이커와 장애 격리

모든 외부/크리티컬 의존성 경계에 서킷 브레이커 구현
가용성 우선 경로에서 fail-open 설계 (에러/미지 상태 → 허용)
의존성 맵 작성 — 2차, 3차 의존성까지 (“의존성의 의존성은 당신의 의존성이다”)
인시던트 대응 도구가 모니터링/제어 대상과 독립적인지 확인

복구 설계

복구 모드의 임계값을 정상 상태와 분리 (헬스체크, 용량 제거 속도)
thundering herd 방지: 백오프, 지터, 큐 기반 레이트 리미팅
자동 복구 로직에 하드 세이프티 바운드 (삭제 상한, 변경 속도 제한)

디지털 주권과 멀티클라우드

클라우드 제공자 API 접근 철회 시나리오 문서화 및 대응 계획
암호화 키 관리가 제공자 독립적인지 확인
데이터 분류 기반 워크로드 배치 — 주권 필수 vs. 퍼블릭 클라우드 허용
추상화 레이어(Kubernetes, Terraform)로 포터빌리티 확보

시장 집중 리스크 대응

멀티-CDN 전략 (액티브-액티브, 단순 백업이 아닌)
멀티-프로바이더 DNS
동일 인프라 위의 백업은 허위 보안임을 인식
완전한 제공자 장애를 시뮬레이션하는 정기적 페일오버 테스트

2025년 산업 통계: 100%의 조직이 장애 관련 매출 손실을 경험. 대기업 기준 장애당 평균 50만 달러 손실. 조직은 연간 86시간의 다운타임을 견딤. 그러나 정기적 페일오버 테스트를 수행하는 곳은 1/3 미만.

인터넷이 단일장애점이 되는 것을 막을 수는 없다. 하지만 우리의 시스템이 인터넷의 단일장애점에 의존하는 방식은 바꿀 수 있다. 그것이 SRE의 일이다.

이 글에서 다룬 장애 사례의 기술적 상세는 각 서비스 제공자의 공식 포스트모템과 독립 분석을 기반으로 합니다.

참고 자료: