5노드 Raft에서 3노드가 한꺼번에 죽은 이유 — Coinbase 2026년 5월 7일 장애 읽기

들어가며 — 남의 포스트모템이 교과서보다 정확할 때
무슨 일이 있었나
쿼럼 산수의 숨은 전제 — 장애의 독립성
그런데 Coinbase는 그 선택을 철회하지 않는다
재해 때만 도는 코드는, 테스트된 적 없는 코드다
매니지드 서비스는 위험을 없애지 않고 옮긴다
가장 정직한 대목 — 3-AZ였어도 막지 못했다
타임라인을 다시 읽으면, 단일 원인 서사가 무너진다
AZ는 장애의 최소 단위가 아니다
그래서 실무에서 뭘 바꿔야 하나
마치며 — 그리고 이 글이 모르는 것
참고 자료

들어가며 — 남의 포스트모템이 교과서보다 정확할 때

분산 시스템 글의 8할은 같은 문장에서 시작합니다. "Raft는 2f+1 노드로 f개의 장애를 견딘다." 맞는 말이고, 시험에도 나오고, 실무에서 아무도 이걸 몰라서 죽지 않습니다. 사람들이 죽는 건 저 문장에 적혀 있지 않은 전제 때문입니다.

2026년 6월 1일, Coinbase가 5월 7일 장애에 대한 포스트모템을 공개했습니다. 이 글이 읽을 가치가 있는 이유는 "우리가 바보 같은 실수를 했습니다" 류의 이야기가 아니기 때문입니다. 오히려 반대입니다 — 의도적이고, 문서화돼 있고, 그 도메인에서는 변호 가능한 아키텍처 선택이, 바로 그 선택이 없는 셈 치고 있던 장애 모드와 정면으로 만난 이야기입니다. 그리고 Coinbase는 그 선택을 지금도 철회하지 않습니다.

이 글은 그 포스트모템을 근거로 읽어 나갑니다. 모든 시각과 수치는 Coinbase가 직접 밝힌 것이고, 출처가 다르면 다르다고 적겠습니다.

무슨 일이 있었나

시작은 소프트웨어가 아니라 물리학이었습니다. Coinbase의 서술로는, 미 동부시간 5월 7일 오후 7시 20분에 AWS us-east-1 리전의 가용 영역 use1-az4 안에 있는 데이터 홀 한 곳에서 칠러 여러 대가 동시에 고장 났습니다. 냉각이 끊기자 해당 랙들이 열 보호 셧다운에 들어갔고, 그 건물의 EC2 인스턴스와 EBS 볼륨이 오프라인이 됐습니다.

AWS 쪽 서술도 같은 그림입니다. The Register와 Network World가 인용한 AWS 상태 대시보드 문구에 따르면, AWS는 태평양시 오후 5시 25분 업데이트에서 영향받은 하드웨어의 EC2 인스턴스와 EBS 볼륨이 "thermal event 동안의 전력 상실"로 영향받았다고 적었고, 이튿날 오전 업데이트에서는 온도가 운영 임계치를 넘어서 하드웨어를 보호하기 위해 서버가 자동으로 셧다운됐다고 설명했습니다. 소프트웨어로 우회할 수 있는 종류의 고장이 아니었다는 뜻입니다 — 냉각을 되살려야 하드웨어에 다시 전기를 넣을 수 있으니까요.

Coinbase가 공개한 타임라인은 이렇습니다. 모두 미 동부시간입니다.

5월 7일
  7:20 PM  use1-az4 의 데이터 홀 한 곳에서 칠러 다수가 동시 고장
           냉각 상실 -> 해당 랙 열 보호 셧다운 -> EC2 / EBS 오프라인
  7:48 PM  Coinbase 거래 대부분 중단
  9:29 PM  AWS가 배치 그룹 내 EC2 인스턴스들을 종료
           체결 엔진 5노드 중 3노드 다운 -> 쿼럼 상실

5월 8일
 12:06 AM  쿼럼 복구
  2:25 AM  체결 엔진을 취소 전용(cancel-only) 모드로 오픈
  3:00 AM  손상된 브로커에서 토픽을 빼내기 위한 수동 파티션 재할당
  3:49 AM  전 종목 거래 정상 재개
  5:30 AM  coinbase.com / 모바일 앱 거래가 축소된 상태로 복구
  9:30 AM  P0 / P1 토픽 완전 복구
  9:53 AM  coinbase.com / 모바일 앱 완전 복구
  2:00 PM  남은 이벤트 스트리밍 토픽 백로그 해소

Coinbase 자신의 요약은 이렇습니다 — 거래, 입금, 출금을 비롯해 고객이 의존하는 대부분의 표면이 "대략 8시간" 동안 불가용하거나 축소 운영됐고, 모든 시스템의 완전 복구에는 "추가로 12시간"이 더 걸렸습니다. 참고로 오후 7시 48분(거래 중단)부터 오전 3시 49분(전 종목 재개)까지가 정확히 8시간 1분이니, 저 "대략 8시간"은 타임라인과 앞뒤가 맞습니다.

쿼럼 산수의 숨은 전제 — 장애의 독립성

Coinbase Exchange의 체결 엔진은 Raft 기반 복제 클러스터로, AWS 클러스터 배치 그룹(Cluster Placement Group) 안에서 돕니다. 노드는 5개이고, Raft의 산수대로라면 2개까지의 장애를 견딥니다. 3개가 살아 있으면 과반이니 계속 진행할 수 있습니다.

3개가 죽었습니다. 그것도 한 번에.

여기서 중요한 건 "3개가 죽었으니 5노드로는 모자랐다"가 아닙니다. 노드를 7개로 늘렸어도 같은 일이 났을 겁니다. 진짜 문제는 저 산수의 전제입니다. "5노드는 2개의 장애를 견딘다"는 문장의 정확한 형태는 5노드는 2개의 독립적인 장애를 견딘다입니다. 그리고 클러스터 배치 그룹은 그 독립성을 일부러 없애는 물건입니다.

AWS 자신의 배치 그룹 문서가 이 트레이드오프를 그대로 적어 두고 있습니다. 문서는 배치 전략을 이렇게 구분합니다.

Cluster — 인스턴스를 가용 영역 하나 안에 "가깝게 밀집시킨다"(packs instances close together). 목적은 HPC처럼 노드 간 통신이 촘촘히 엮인 워크로드에 필요한 저지연 네트워크 성능을 얻는 것.
Partition — 인스턴스를 논리 파티션으로 나눠, 서로 다른 파티션의 인스턴스 그룹이 같은 하드웨어를 공유하지 않게 한다. 문서가 예로 드는 게 Hadoop, Cassandra, 그리고 Kafka입니다.
Spread — 소수의 인스턴스를 서로 구별되는 하드웨어에 엄격히 배치해 "상관 장애를 줄인다"(reduce correlated failures).

그리고 문서에는 이런 문장도 있습니다 — 배치 그룹을 아예 안 쓰면 EC2는 기본적으로 인스턴스를 하드웨어 전반에 퍼뜨려 "상관 장애를 최소화"(minimize correlated failures)하려 시도한다고요.

즉 AWS 문서에서 "correlated failure"라는 단어는 Spread와 기본 동작을 설명할 때 나오고, Cluster를 설명할 때는 나오지 않습니다. Cluster는 그 반대편을 사는 전략입니다. 지연 시간을 사고 독립성을 파는 거래이고, 그 거래는 문서 첫 화면에 적혀 있습니다.

그러니 이 사건의 한 줄 요약은 이렇게 됩니다. 쿼럼은 노드를 세지만, 장애는 노드를 세지 않는다. 장애는 실패 도메인을 셉니다. 배치 그룹 안의 5노드는 Raft에게는 5로 보이고, 칠러에게는 1로 보입니다.

그런데 Coinbase는 그 선택을 철회하지 않는다

여기가 이 포스트모템에서 제일 흥미로운 대목입니다. 보통 이런 글은 "우리는 단일 실패 지점을 만들었고 반성합니다"로 흘러갑니다. Coinbase는 그렇게 쓰지 않았습니다.

포스트모템은 코로케이션을 의도적 선택이라고 명시하고, 그 이유를 이렇게 답니다 — 진지한 시장의 지연 시간과 처리량 요구를 만족하는 체결 엔진은 투표에 참여하는 클러스터 멤버 사이에 가용 영역을 건너뛰는 네트워크 홉을 감당할 수 없다고요. 그리고 분산 합의의 물리학과 공정하고 유동성 있는 호가창을 굴리는 경제학이 같은 답, 즉 코로케이션을 가리킨다고 적습니다.

이 주장을 진지하게 받아들일 필요가 있습니다. Raft에서 커밋 지연은 리더가 팔로워 과반의 응답을 받는 데 걸리는 시간에 묶이고, 그건 곧 투표 멤버 간 왕복 지연입니다. AZ를 건너뛰면 그 왕복이 길어지고, 그 비용은 커밋 하나마다 붙습니다. 이건 저지연 트레이딩 시스템에서 커널 튜닝으로 마이크로초를 깎는 사람들에게는 협상 대상이 아닌 종류의 제약입니다. (Coinbase는 구체적인 지연 수치를 공개하지 않았고, 저도 여기서 숫자를 지어내지 않겠습니다.)

그래서 Coinbase 자신의 진단은 코로케이션이 아니라 그 옆에 있습니다. 포스트모템의 표현으로, 아키텍처상의 문제는 다른 가용 영역으로 자동 페일오버할 능력이 없었다는 것이었습니다. 배치 그룹을 쓴 게 아니라, 배치 그룹에서 빠져나올 자동 경로가 없던 게 문제였다는 겁니다.

이건 말장난이 아니라 실무적으로 완전히 다른 처방으로 이어집니다. "배치 그룹 쓰지 마세요"는 이 팀에게는 쓸모없는 조언입니다 — 그러면 체결 엔진이 요구 성능을 못 냅니다. 반면 "실패 도메인을 의도적으로 묶었다면, 거기서 나오는 문을 만들고 그 문을 정기적으로 열어 봐라"는 실행 가능한 조언입니다. 실제로 Coinbase의 개선 항목 첫 줄이 그것입니다 — 체결 엔진의 웜 크로스존 스탠바이 설계를 개선하고, 정기적인 주기로 프로덕션 페일오버 훈련을 하겠다, 가장 큰 거래소는 점검 시간대에 참여시키고 나머지는 샌드박스 주기로 돌리겠다고요.

재해 때만 도는 코드는, 테스트된 적 없는 코드다

포스트모템에서 제가 가장 오래 들여다본 문장은 사실 이겁니다. 쿼럼을 되살리기 위해 Coinbase는 장애 대응 중에 긴급 코드 변경을 배포해야 했고, 그 내용은 다섯 노드 전부가 resolve 가능해야 한다는 기동 시점 가정을 제거하는 것이었습니다.

이 한 줄을 천천히 읽어 보십시오. 클러스터를 살리려는데, 클러스터가 뜨질 않습니다. 왜냐하면 기동 코드가 자기가 태어난 토폴로지를 사실로 알고 있었기 때문입니다. 노드 다섯이 전부 이름을 풀 수 있어야 뜬다 — 평상시엔 참이고, 배포할 때도 참이고, 스테이징에서도 참입니다. 노드 셋이 재가 된 밤에만 거짓입니다. 그러니까 이 가정은 다른 모든 날에는 옳고, 필요한 그 하루에만 틀린 종류의 코드입니다.

이게 왜 벌어지는지는 뻔합니다. 정상 경로는 초당 수천 번 실행되고, 복구 경로는 몇 년에 한 번 실행됩니다. 그리고 실행되지 않는 코드는 테스트되지 않은 코드입니다. 우리가 "복구 절차가 있다"고 말할 때 실제로 뜻하는 건 대개 "복구 절차를 적어 둔 문서가 있다"입니다. 문서는 컴파일되지 않습니다.

Coinbase가 그날 밤에 실제로 한 일의 목록이 이 지점을 그대로 보여 줍니다 — 긴급 코드 변경을 배포하고, 손상된 배치 그룹 바깥에 새 노드 그룹을 만들고, 3-of-5 쿼럼을 되살리기 위한 조심스러운 시퀀스를 밟았습니다. 이 셋 중 어느 것도 버튼 하나가 아니었습니다. 전부 그 밤에 처음 해 본 일에 가깝습니다.

그래서 개선 항목에 "정기적인 프로덕션 페일오버 훈련"이 들어간 겁니다. 훈련의 목적은 사람이 절차에 익숙해지는 것보다도, 복구 경로가 실행되는 코드가 되게 만드는 것입니다. 한 번도 안 돌아 본 페일오버는 페일오버가 아니라 가설입니다.

매니지드 서비스는 위험을 없애지 않고 옮긴다

두 번째 실패 모드는 완전히 다른 층에서 왔습니다. Coinbase 이벤트 스트리밍의 상당 부분이 AWS의 관리형 Kafka인 MSK 위에서 돕니다.

관리형 Kafka의 약속은 명확합니다. 포스트모템이 정리한 표현으로, 개별 브로커가 죽으면 서비스가 알아서 파티션 리더를 재선출하고 남은 브로커로 트래픽을 계속 처리한다, 가용 영역 전체가 날아가면 결과는 용량 감소지 불가용이 아니어야 한다는 것입니다.

그렇게 되지 않았습니다. Coinbase의 서술에 따르면, AWS MSK 컨트롤 플레인의 결함이 자동 파티션 리더 재선출을 막았고, MSK 클러스터 두 개가 "healing" 상태에 갇힌 채 프로듀서가 쓰기를 하지 못했습니다.

여기서 두 가지를 짚고 싶습니다.

첫째, 이건 크래시가 아니라 회색 장애입니다. "healing"은 죽음이 아닙니다. 죽음이면 오히려 쉽습니다 — 헬스체크가 빨간불이 되고, 알림이 뜨고, 페일오버가 돕니다. "healing"은 시스템이 스스로 "나 지금 낫는 중이야"라고 말하는 상태이고, 그 말은 참일 수도 있고 영원히 참이 아닐 수도 있습니다. 그동안 프로듀서는 쓰지 못합니다. 대시보드는 초록도 빨강도 아닌 노란색이고, 노란색에는 자동화가 붙어 있지 않습니다.

둘째, 고칠 수 없다는 게 진짜 비용입니다. 자체 관리 Kafka였다면 리더 재선출을 손으로 강제하거나 컨트롤러를 재기동하는 선택지가 있었을 겁니다. MSK에서는 그 손잡이가 내 것이 아닙니다. Coinbase가 결국 한 일은 오전 3시에 AWS 엔지니어링과 함께 실시간으로 수동 파티션 재할당을 수행해 토픽을 손상된 브로커에서 옮기는 것이었습니다. 그리고 개선 항목 중 하나는 "MSK를 통해서는 우리에게 제공되지 않는 Kafka 제어 수단"을 위한 도구와 런북을 만들겠다는 것입니다. 이 문장은 관리형 서비스의 청구서를 아주 정확하게 요약합니다 — 운영 부담을 벤더에게 넘기면, 벤더가 못 고칠 때 나도 못 고칩니다. 그때의 복구 시간은 내 엔지니어링 역량이 아니라 벤더의 대응 속도로 결정됩니다.

그리고 이 두 번째 실패 모드가 실제로 얼마나 비쌌는지는 타임라인이 말해 줍니다. 쿼럼은 오전 12시 06분에 복구됐지만, 시장은 오전 3시 49분에야 열렸습니다. 3시간 43분의 간격입니다. Coinbase는 그 지연이 대체로 MSK 문제 때문이었다고 직접 밝힙니다. 합의 클러스터를 되살린 것과 서비스를 되살린 것은 같은 일이 아니었습니다.

가장 정직한 대목 — 3-AZ였어도 막지 못했다

포스트모템에는 대부분의 2차 보도가 조용히 빠뜨린 문장이 하나 있습니다. Coinbase는 Kafka 클러스터 중 하나가 2-AZ 구성이어서 영향 범위(blast radius)와 복구 시간을 키웠다고 인정한 뒤, 곧바로 이렇게 덧붙입니다 — 다만 MSK 컨트롤 플레인 결함은 2-AZ 클러스터와 3-AZ 클러스터에 비슷하게 영향을 줬다고요.

이건 자기변호가 아니라 정확성입니다. 그리고 이 문장을 지우면 이 사건에서 배울 게 반으로 줄어듭니다.

여기서 나오는 교훈은 이겁니다. 데이터 플레인의 중복은 컨트롤 플레인의 고장을 고치지 못합니다. 세 번째 AZ를 추가한다는 건 "브로커가 하나 더 있는 곳이 하나 더 생긴다"는 뜻입니다. 그런데 문제가 브로커가 없는 게 아니라 리더를 뽑아 주는 주체가 리더를 못 뽑는 것이라면, AZ를 하나 더 붙여도 리더 못 뽑힌 브로커가 한 무더기 더 생길 뿐입니다. 중복은 컨트롤러가 살아 있을 때 값을 합니다.

주목할 건 Coinbase가 그럼에도 2-AZ 클러스터를 3-AZ로 옮기겠다고 적었다는 점입니다. 이게 옳습니다 — 3-AZ는 여전히 2-AZ보다 낫고, 이번에 도움이 안 됐다는 게 앞으로도 도움이 안 된다는 뜻은 아니니까요. 다만 그걸 "이번 장애의 해결책"으로 포장하지 않았습니다. 개선 항목이 근본 원인 해결인 척하지 않는 포스트모템은 생각보다 드뭅니다.

타임라인을 다시 읽으면, 단일 원인 서사가 무너진다

이 사건은 지금 대체로 이렇게 이야기됩니다. "Raft 클러스터가 쿼럼을 잃어서 Coinbase가 멈췄다." 깔끔하고, 기억하기 쉽고, 타임라인과 맞지 않습니다.

거래가 멈춘 건 오후 7시 48분입니다. 체결 엔진이 쿼럼을 잃은 건 오후 9시 29분입니다. 거래는 쿼럼이 깨지기 1시간 41분 전에 이미 멈춰 있었습니다.

그럼 7시 48분에 무엇이 거래를 멈췄을까요. 포스트모템은 이걸 명시적으로 말하지 않습니다. 다만 MSK 문제를 설명하면서, 그 파급이 수수료 서비스를 막았고, 수수료 서비스가 막히자 호가 산출이 막혔으며, 그래서 대부분의 고객이 이 사건을 Kafka 장애가 아니라 깨진 체결과 깨진 호가로 경험했다고 적습니다. 원장 파이프라인 일부와 결제, 여러 데이터 파이프라인도 같은 방식으로 영향을 받았다고 하고요.

정황은 그쪽을 가리키지만, 포스트모템이 7시 48분의 인과를 명시하지 않은 이상 저도 단정하지 않겠습니다. 여기서 확실히 말할 수 있는 건 더 조심스럽지만 더 유용합니다 — 타임라인만으로도 단일 원인 서사는 틀렸다는 게 증명됩니다. 그리고 Coinbase 자신의 프레이밍이 정확히 그것입니다. 국지적인 클라우드 사업자 사건을 여러 시간짜리 플랫폼 장애로 키운 건 두 개의 실패 모드였고, 각각은 독립적으로 복구 가능했지만 겹치자 증폭됐다는 것.

이게 큰 장애가 실제로 생기는 방식입니다. 하나의 근본 원인이 아니라, 평소엔 서로를 모르는 두 개의 결함이 같은 밤에 만나는 것. 그리고 사후에 우리는 그중 제일 그림이 잘 나오는 하나("합의 클러스터가 쿼럼을 잃었다")를 골라 사건 전체의 이름으로 씁니다. 그 순간 나머지 절반의 교훈은 사라집니다. 참고로 이런 식의 재구성을 경계하자는 게 비난 없는 포스트모템 문화가 실제로 지키려는 것이기도 합니다.

AZ는 장애의 최소 단위가 아니다

마지막으로 이 사건이 흔든 멘탈 모델이 하나 더 있습니다.

Coinbase는 자기들이 (그리고 대부분의 AWS 고객이) 설계 기준으로 삼는 원칙을 포스트모템에 명시적으로 적어 뒀습니다 — 가용 영역 하나는 통째로 죽을 수 있고, 제대로 설계된 시스템은 남은 영역들로 계속 서비스해야 한다. 그리고 이런 종류의 고장은 하이퍼스케일 사업자가 가용 영역 경계에서 흡수하도록 설계된 것이라고요.

그런데 실제로 죽은 건 가용 영역이 아니었습니다. 데이터 홀 하나였습니다. AZ보다 작습니다.

여기에 아이러니가 있습니다. 장애가 AZ보다 작았는데도 5노드 클러스터의 3노드를 가져갔습니다. 왜냐하면 배치 그룹의 영향 범위도 AZ보다 작았기 때문입니다. 두 개의 작은 원이 겹친 겁니다. "AZ 단위로 생각한다"는 습관은 AZ보다 큰 장애(리전 전체의 컨트롤 플레인 문제)뿐 아니라 AZ보다 작은 장애에 대해서도 눈을 가립니다. 내 복제본들이 몇 개의 AZ에 흩어져 있느냐가 아니라, 내 복제본들이 몇 개의 실제 실패 도메인에 흩어져 있느냐가 답해야 할 질문입니다. 그리고 클러스터 배치 그룹을 쓰는 순간, 그 답은 AZ 개수보다 훨씬 작아집니다.

CAP 정리 같은 추상이 실무에서 자주 무력한 이유가 여기 있습니다. P(분단)는 이론에서 확률변수 하나지만, 현실에서는 칠러의 배관 구조입니다.

그래서 실무에서 뭘 바꿔야 하나

이 사건에서 정직하게 가져갈 수 있는 것들입니다.

복제본이 아니라 실패 도메인을 세십시오. "우리 etcd는 5노드예요"는 답이 아닙니다. 질문은 "그 5노드가 동시에 죽는 단일 사건이 존재하는가"입니다. 같은 랙, 같은 스위치, 같은 전원, 같은 데이터 홀, 같은 배치 그룹, 같은 Kubernetes 노드 그룹, 같은 AMI, 같은 배포 파이프라인. 이 목록 어디서든 겹치면 쿼럼 산수는 그만큼 거짓말이 됩니다.

의도적으로 묶었다면, 나오는 문을 만들고 열어 보십시오. 코로케이션 자체는 죄가 아닙니다. Coinbase 자신의 진단이 그것입니다. 문제는 묶어 놓고 탈출 경로를 자동화하지 않은 것이었습니다. 지연 시간을 위해 독립성을 팔았다면, 그 대가로 산 건 "언젠가 손으로 풀어야 하는 밤"입니다. 그 밤을 미리 예약해서 리허설하십시오.

기동 코드에서 토폴로지 가정을 찾아 지우십시오. "전체 N개 노드가 resolve돼야 뜬다"는 조건은 평시에는 건강 체크처럼 보이고 재해 시에는 자물쇠가 됩니다. 축소된 클러스터로 부팅이 되는지, 그걸 아는 유일한 방법은 축소된 클러스터로 부팅해 보는 것입니다.

관리형 서비스에는 이 질문을 하십시오 — 고장 난 게 컨트롤 플레인이면 나는 뭘 할 수 있나. 답이 "지원 티켓을 연다"라면, 그게 당신의 RTO입니다. 그 RTO를 받아들일 수 있는지가 관리형이냐 자체 운영이냐를 가르는 실제 기준이고, "운영 부담"이라는 말로 뭉뚱그려지는 것보다 훨씬 구체적인 질문입니다.

데이터 플레인 중복과 컨트롤 플레인 중복을 구분하십시오. AZ를 늘리는 건 전자입니다. 컨트롤러가 못 움직이는 고장에는 값을 하지 않습니다.

그리고 과잉 학습하지 마십시오. 이게 제일 중요할지도 모릅니다. Coinbase는 투표 멤버 간 AZ 홉을 감당할 수 없는 체결 엔진을 굴리는 거래소입니다. 당신의 서비스가 그런 제약을 갖고 있지 않다면 — 대부분은 아닙니다 — 애초에 클러스터 배치 그룹을 쓸 이유가 없고, AWS의 기본 동작(하드웨어 전반에 퍼뜨려 상관 장애를 최소화)이 이미 옳은 선택입니다. 이 포스트모템에서 "저지연을 위해 노드를 밀집시켜야 한다"를 배워 가면 정확히 잘못 배운 겁니다. 배울 건 그 반대입니다 — 밀집시킬 진짜 이유가 있는 사람조차 그 대가를 이렇게 치렀다는 것.

마치며 — 그리고 이 글이 모르는 것

Coinbase 포스트모템의 마지막 문단에 이런 취지의 문장이 있습니다. 우리의 기준은 AWS에 장애가 있었느냐에 달려 있지 않고, 그걸 견딜 만큼 튼튼한 시스템을 우리가 지었느냐에 전적으로 달려 있다고요. 이 문장이 이 글 전체의 요약입니다. 클라우드 사업자의 장애는 당신의 장애에 대한 변명이 되지 않습니다 — 그건 당신이 설계 문서에 적어 둔 가정에 대한 채점일 뿐입니다.

이제 이 글의 한계를 적겠습니다.

우리는 한쪽 이야기만 갖고 있습니다. AWS의 post-event summary 목록을 확인해 보면, 이 5월 2026 열 사건에 대한 공식 요약도, MSK 컨트롤 플레인 결함에 대한 공식 요약도 올라와 있지 않습니다(가장 최근 항목은 2025년 10월 DynamoDB 사건입니다). 그러니 MSK 결함에 관해 이 글에 적힌 모든 내용 — 리더 재선출이 막혔다, 클러스터가 "healing"에 갇혔다, 2-AZ와 3-AZ가 비슷하게 영향받았다 — 은 Coinbase의 서술입니다. AWS가 검증했거나 확인한 사실이 아닙니다. Coinbase 자신도 6월 1일 시점에 이 결함을 AWS와 함께 아직 근본 원인 분석 중이라고 적었습니다. 그러니 이 부분은 잠정적으로 읽는 게 맞습니다.

그리고 우리는 7시 48분을 모릅니다. 앞서 적었듯 포스트모템은 첫 거래 중단의 인과를 명시하지 않습니다. 정황은 있지만 확인은 없습니다.

이런 빈칸이 남는다는 게 이 장르의 현실입니다. 포스트모템은 진실의 사본이 아니라, 그걸 쓴 조직이 그 시점에 알고 있었고 말할 수 있었던 것의 사본입니다. 그럼에도 Coinbase의 글은 읽을 값을 합니다 — 자기 선택을 변호하면서 동시에 그 선택의 대가를 적었고, 자기 개선 항목이 근본 원인을 고치지 못한다는 것까지 적었으니까요. 그 두 가지를 동시에 하는 글은 흔하지 않습니다.