— AWS 장애가 드러낸 페인 포인트

2026년 6월 · 인프라 집중도 분석

냉각기 몇 대가 멈추자, 거래소가 멈췄다

2026년 5월 7일 밤(미 동부시간 7시 48분경), 코인베이스의 거의 모든 거래가 멈췄다. 원인은 시장도, 해킹도 아니었다. AWS us-east-1의 한 가용 영역(use1-az4)에서 다수의 냉각기(chiller)가 동시에 고장 나 데이터센터의 한 홀이 과열됐고, 열 안전 차단(thermal-safety shutdown)이 작동하면서 해당 랙의 EC2 인스턴스와 EBS 볼륨이 통째로 전원을 잃었다. 물리적 사건이었다. 냉각이 사고 이전 수준으로 안정화되기까지는 약 20시간이 걸렸다.[1][2]

코인베이스가 최근 공개한 포스트모템은 그날의 시간선을 건조하게 기록했다. 거래 중단은 약 8시간, 완전 복구까지는 약 12시간. 정족수(quorum)는 자정 직후(12시 06분) 회복됐지만, 시장 재개는 새벽 3시 49분에야 이뤄졌다. 그 사이의 공백이 이 사건의 핵심이다.[1][3]

“멀티-AZ니까 괜찮다”는 믿음이 무너진 지점

표면적으로 코인베이스는 정석대로 설계되어 있었다. 하나의 가용 영역 전체가 죽어도 나머지 영역으로 서비스를 이어 간다. 이것이 AWS 고객 대부분이 의지하는 아키텍처 원칙이고, 하이퍼스케일러가 존 경계에서 장애를 흡수하도록 설계된 구조이다. 그런데 이번에는 그 원칙이 작동하지 않았다. 두 가지 이유에서다.[2]

첫째, 지연(latency)에 가장 민감한 핵심, 거래 매칭 엔진은 설계상 단일 존에서 돌고 있었다. 밀리초 단위의 속도를 위해 의도적으로 한 존에 묶어 둔 구성이, 바로 그 존이 죽자 단일 장애점이 됐다.[4]

둘째, 더 뼈아픈 부분은 자동 복구가 조용히 실패했다는 것이다. 코인베이스는 이벤트 스트리밍의 상당 부분을 AWS 관리형 Kafka 서비스(MSK)에 올려 두었다. 관리형 서비스의 약속은 명확하다.

브로커 일부가 죽으면 자동으로 파티션 리더를 재선출해 남은 브로커로 트래픽을 계속 처리한다. 존 하나의 상실은 “가용성 상실”이 아니라 “용량 감소”여야 한다. 그러나 MSK 제어 평면의 결함이 자동 파티션 리더 재선출을 막았다. 두 개의 MSK 클러스터가 “치유 중(healing)” 상태에 갇혀 프로듀서가 쓰기를 하지 못했고, 그 여파가 수수료 서비스를 막고, 그것이 다시 호가(quoting)를 막았다. 사용자가 체감한 “깨진 거래와 호가”는 이렇게 만들어졌다. 게다가 한 Kafka 클러스터는 2-AZ 구성이어서 폭발 반경(blast radius)을 키웠다.[1][4][5]

이중화를 설계해 둔 시스템에서, 그 이중화 자체가 작동하지 않아 엔지니어들이 수동으로 재해 복구 절차를 돌려야 했다. 브라이언 암스트롱 CEO는 이를 “결코 용납될 수 없는 일”이라고 표현했다. 코인베이스는 리전 차원의 이중화 강화, Kafka 구성의 2-AZ→3-AZ 확장, 복원력 테스트 확대를 약속했다.[3][1]

여기서 끌어낼 교훈은 분명하다. “우리는 멀티-AZ다”는 “우리는 존 하나의 상실을 견딘다”와 같은 말이 아니다. 실제 존 상실 조건에서 지속적으로 검증되지 않은 이중화는 이중화가 아니라 이중화의 연극이다. 그리고 관리형 서비스의 추상화는, 당신이 손댈 수 없는 실패 양식을 그 안에 숨겨 둔다.

7개월 사이 세 번 반복된 같은 교훈

이 사건이 일회성 불운이라면 칼럼의 주제가 되지 못했을 것이다. 문제는 반복성이다.

  • 2025년 10월 20일, AWS us-east-1의 DynamoDB 내부 DNS 자동화에서 발생한 경쟁 상태(race condition)가 70여 개 서비스로 연쇄 전파됐다(약 15시간). 코인베이스가 멈췄고, L2 네트워크 Base가 내려갔으며, 컨센시스의 Infura RPC가 죽으면서 블록체인의 핵심 지갑 서비스인 메타마스크가 끊겼다. Polygon·Optimism·Arbitrum·Linea·Scroll의 프론트엔드와 릴레이가 줄줄이 영향받았다.[6][7][8][9]
  • 2025년 11월 18일, Cloudflare의 봇 관리 기능 파일이 데이터베이스 권한 변경으로 두 배로 부풀어 전 세계 엣지로 전파됐고, 인터넷 트래픽의 5분의 1을 담당하는 회사가 약 3시간 동안 5xx 에러를 토했다. BitMEX·DeFiLlama·Arbiscan, 그리고 또다시 코인베이스와 Ledger가 서비스 에러를 토하며 체면을 잃었다.[12][13][14]
  • 2026년 5월 7일, 앞서 본 냉각기 고장.[1]

DNS 버그, 설정 파일, 냉각기. 원인은 매번 다르지만 결과는 같다. 그리고 세 번 모두, 멈춘 것은 블록체인의 합의 계층이 아니었다.

무엇이 멈췄고, 무엇이 살아남았는가?

정확히 구분해야 한다. 10월 장애에서 이더리움, 솔라나의 합의 계층(consensus layer)에는 프로토콜 차원의 이상이 없었다. 블록은 계속 생성됐고 온체인 자산은 안전했다. 5월 코인베이스 사건에서도 사용자 자금은 온체인에서 멀쩡했다.[10]

그렇다면 사용자는 왜 아무것도 할 수 없었나. 오늘날 한 명의 사용자가 “탈중앙 앱”을 쓸 때, 그 요청은 대략 이런 계층을 통과한다.

  1. 엣지/CDN 계층 — Cloudflare 같은 사업자가 프론트엔드 도메인·DDoS 방어·캐싱을 담당한다.
  2. 호스팅 계층 — 디앱 프론트엔드와 노드, 거래소의 매칭 엔진까지 AWS·구글 클라우드·알리바바 클라우드 위에서 돈다.
  3. RPC/릴레이 계층 — Infura, Alchemy 같은 소수 게이트웨이가 지갑과 체인을 중개한다.
  4. 합의 계층 — 비로소 여기서, 분산된 노드들이 블록을 검증한다.

진짜 탈중앙화는 4번에만 존재한다. 13번, 곧 사용자가 실제로 마주하는 “운영 표면(operational surface)” 전체가 극소수 클라우드 사업자에게 묶여 있다. 냉각기 고장이든 DNS 버그든 13번을 무너뜨리면, 4번이 아무리 건강해도 사용자에게는 네트워크 전체가 죽은 것과 구별되지 않는다.

숫자가 말하는 집중도

이것은 정서적 비판이 아니라 측정 가능한 사실이다. Ethernodes 기준으로 10월 장애 당시 이더리움 실행 계층 노드의 약 36%(약 2,368개)가 AWS 위에 있었다. 노드의 약 70%가 어떤 형태로든 클라우드에 의존하고, 지리적으로는 절반에 가까운 노드가 미국에 몰려 있다.[16][17][18]

문제는 단일 사업자 의존만이 아니다. us-east-1은 AWS 안에서도 특별한 리전이다. IAM 인증, CloudFront, Route 53, DynamoDB Global Tables 같은 글로벌 서비스가 다른 리전에 배포된 자원을 위해서도 us-east-1 엔드포인트에 의존한다. “멀티 리전으로 분산했다”는 구성조차 단일 리전의 제어 평면(control plane)에 매여 있을 수 있다는 뜻이다. 그리고 5월 사건은 한 계단 더 내려가, “멀티 AZ”조차 제어 평면 결함 앞에서는 보장이 아니라는 것을 보여 줬다. 분산의 외형 아래마다 단일 장애점이 한 겹씩 숨어 있다.[6][19]

알리바바 클라우드와 Cloudflare는 다른 축에서 같은 위험을 만든다. 알리바바 클라우드는 아시아권, 특히 중국계 프로젝트의 노드, 인프라가 쏠리는 지점이고, Cloudflare는 호스팅과 무관하게 거의 모든 웹3 프론트엔드가 통과하는 엣지 관문이다. AWS에 노드를 두지 않은 프로젝트라도 도메인 앞단에 Cloudflare를 세워 두었다면 11월 18일에는 똑같이 서비스 불능 상태에 빠졌을 것이다.[15]

왜 이렇게 되었나? — 이상이 아니라 경제학

이 집중은 게으름이나 탈중앙화의 배신의 결과가 아니다. 합리적 선택이 누적된 결과다. 풀 노드를 자체 운용하려면 상당한 스토리지, 대역폭, 인력이 필요하고, 클라우드는 그것을 몇 분 만에 예측 가능한 비용으로 준다. 사용자는 200ms의 지연도 참지 못하므로 프로젝트는 가장 빠른 엣지를 택하고, 거래소는 매칭 엔진을 단일 존에 묶어 레이턴시를 줄인다. 개별 프로젝트 입장에서 이 선택들은 거의 언제나 합리적이다.

문제는 모두가 같은 합리적 선택을 했을 때 발생한다. 개별적 최적화의 총합이 시스템 차원의 취약성이 된다. 각자가 가장 견고한 사업자를, 가장 빠른 구성을 고른 결과, 생태계 전체가 같은 몇 개의 바구니에 알을 담았다. 그리고 그 바구니가 흔들릴 때, 분산되어 있어야 할 위험이 완벽하게 상관(correlated)된 위험으로 드러난다.

“유사 탈중앙화”라는 불편한 진단

솔직해질 필요가 있다. 블록체인의 탈중앙화는 합의 메커니즘과 자산 소유권 차원에서는 실재한다. 세 번의 장애에서 그 누구의 코인도 사라지지 않았다는 사실이 그 증거다. 그러나 접근성·가용성·검열 저항성이라는, 사용자가 체감하는 차원에서의 탈중앙화는 상당 부분 서사(narrative)에 가깝다.

사토시가 이야기했던 탈중앙화와 가설로서의 탈중앙화와 측정된 탈중앙화 사이에는 큰 간극이 있다.

이는 도덕적 비난이 아니라 엔지니어링 부채(engineering debt)로 다뤄야 할 문제다. 우리는 합의 계층의 탈중앙화에 막대한 지적 자원을 쏟았지만, 그 위에 올라가는 운영 표면은 가장 편리한 중앙화 인프라에 통째로 위탁했다. 합의는 분산했으나 기존 인터넷 망과 클라우드에 올라간 인프라는 Web 2.0에 묶여 있던 것이다.

그렇다면 무엇을 해야 하는가? — 과장 없이

해법을 논할 때 흔한 함정은 “완전한 탈중앙 인프라”라는 유토피아를 파는 것이다. 그것은 정직하지 않다. 현실적인 완화책은 점진적이고, 각각 명확한 트레이드오프를 동반한다.

  • 이중화는 검증된 이중화여야 한다. 코인베이스 사례의 진짜 교훈은 “이중화가 없었다”가 아니라 “이중화가 실제 장애 조건에서 검증되지 않았다”는 것이다. 카오스 엔지니어링과 정기적인 존 상실 훈련 없이 그려 둔 폴백 다이어그램은 가용성을 보장하지 않는다.
  • 관리형 서비스의 추상화를 신뢰하되 의존성은 인지하라. MSK가 자동 페일오버를 약속한다고 해서 그 약속이 모든 장애 양식에서 지켜지는 것은 아니다. 제어 평면 결함처럼 당신이 손댈 수 없는 실패가 존재한다는 전제 위에서 설계해야 한다.
  • 인프라 다양화는 클라우드·리전 다양화에서 시작한다. RPC를 복수 사업자·복수 리전으로 분산하고 폴백 경로를 두는 것만으로 단일 장애점이 줄어든다. 비용과 복잡도는 늘어난다. 그것이 가용성의 가격이다.
  • 탈중앙 RPC·인프라 네트워크(DIN)는 유망하나 미완성이다. 노드 제공을 분산 인센티브로 푸는 시도들이 진행 중이지만, 지연과 일관성에서 중앙화 게이트웨이를 아직 따라잡지 못했다. 과대평가도 과소평가도 경계해야 한다.
  • 가장 정직한 첫걸음은 의존성 인벤토리다. 자신의 스택이 어느 사업자·어느 리전·어느 단일 제어 평면에 실제로 매여 있는지 그려 보는 것. 대부분의 프로젝트는 자신이 생각보다 훨씬 중앙화되어 있다는 사실조차 모른다.

맺으며

블록체인은 신탁(oracle)이 아니라 도구(tool)다. 그것은 합의와 소유권이라는 특정 문제를 우아하게 풀고자 하고 있다. 그러나 그 도구가 작동하는 물리적 토대는 Web이라는 현실이다. 서버, DNS, 엣지, 그리고 냉각기는 여전히 2026년의 클라우드 과점 구조 위에 서 있다. 2025년 10월의 DNS, 11월의 설정 파일, 2026년 5월의 냉각기. 7개월도 안 되는 사이 같은 교훈을 세 번 가르쳤다.

탈중앙화된 미래를 진지하게 꿈꾼다면, 그 꿈을 멈춰 세운 것이 적대적 국가나 정교한 공격이 아니라 냉각기 고장과 설정 파일 한 줄, DNS 버그 하나였다는 사실을 직시해야 한다. 진짜 페인 포인트는 거기에 있다. 우리가 가장 분산되었다고 믿는 시스템이, 가장 평범한 운영 사고 앞에서 가장 취약했다는 것. 그리고 견고하게 설계했다고 믿은 이중화조차, 정작 필요한 순간에 작동하지 않을 수 있다는 것.

탈중앙화는 선언이 아니라 측정의 문제다. 그리고 측정해 보면, 아직 갈 길이 멀다.

참고문헌 (References)

아래 출처는 2025년 10월~2026년 5월 사이의 1차 포스트모템·뉴스 보도 및 노드 분포 통계 자료다. 통계 수치는 게시 시점 기준이며 시간에 따라 변동될 수 있다.

2026년 5월 7일 — AWS us-east-1 냉각 장애 / Coinbase

2025년 10월 20일 — AWS us-east-1 DynamoDB DNS 장애

2025년 11월 18일 — Cloudflare 글로벌 장애

노드·인프라 집중도 통계