유명 포스트모템 해부 — Cloudflare·Fastly·AWS·Knight Capital·GitLab의 실패에서 배우기

프롤로그 — "실패는 최고의 선생이다"

2025년 4월, 당신의 서비스가 오전 3시 다운됐다.

원인: 모름
복구: 2시간
책임자: 어젯밤 커밋한 누군가
분위기: "누가 그랬어?"

이것은 Blame culture — 실패에서 배울 수 없는 환경.

반대로, 세계적 기업들은 Postmortem을 공개한다. Cloudflare, Google, AWS, GitLab. "우리가 이렇게 망쳤고, 이렇게 배웠다"는 투명성은 업계 전체를 학습시킨다.

Season 3 Ep 1에서 회사들의 성공 아키텍처를 봤다면, Ep 2는 실패에서 배운다.

이 글은 공개된 postmortem에서 추출한 실전 교훈. 같은 실수를 다른 사람 비용으로 피하자.

1부 — Postmortem이란

정의

Postmortem (사후 분석): 사건 발생 후 원인, 영향, 타임라인, 교훈을 문서화.

Google SRE 북의 5요소

1. Incident summary
2. Impact (누가, 얼마나)
3. Root cause (기술적 + 프로세스)
4. Timeline (분 단위)
5. Action items (구체적)

Blameless Postmortem 핵심

나쁜 예: "Alice가 잘못된 config push 했다"
좋은 예: "Config validation이 부재했다.
         Alice의 change가 통과한 것은 시스템의 격차."

철학: 사람이 아닌 시스템을 고침. 비난하면 다음 사람이 숨김.

2부 — Cloudflare 2022-06-21 — BGP로 반이 다운

무슨 일

2022년 6월 21일 06:27 UTC
Cloudflare의 19개 데이터센터(세계 절반의 트래픽) 다운
1시간 30분 동안 고객 서비스 영향

원인

BGP 경로 변경 중 실수:

Cloudflare가 네트워크 표준화 중
일부 데이터센터에서 BGP configuration 롤아웃
Config 변경: 일부 prefix 광고 중단 → 트래픽 갈 곳 없음

왜 전체가?

중앙 control plane이 config 전파
여러 DC가 동시에 영향받는 구조
Canary 없이 빠른 전파

교훈

Config change도 배포: Canary 필수
Central control의 양날: 속도 vs 폭발 반경
BGP은 위험: 실수가 인터넷 단위
투명한 포스트모템: Cloudflare가 몇 시간 내 공개

Action items (Cloudflare 발표)

Config 변경 workflow 재설계
더 강한 staging 환경
Progressive rollout 강제
Alert 개선

3부 — Cloudflare 2019-07-02 — 정규식이 CPU 100%

무슨 일

2019년 7월 2일
Cloudflare WAF rule 업데이트 → 전 세계 CPU 100%
27분 동안 HTTP 50x 증가

원인 — Catastrophic Backtracking

WAF rule에 있던 정규식:
(?:(?:\"|'|\]|\}|\\|\d|(?:nan|infinity|true|false|null|undefined|symbol|math)|
`|\-|\+)+[)]*;?((?:\s|-|~|!|{}|\|\||\+)*.*(?:.*=.*)))

"Catastrophic backtracking" 유발
일부 입력에서 지수 시간 실행
→ CPU 100% → HTTP 처리 불가

교훈

Regex는 위험: 복잡해지면 ReDoS 공격 가능
WAF rule은 global change: 한 수정이 전 세계
CPU 테스트 필요: Latency + throughput도
Kill switch: 문제 시 즉시 끄기

Cloudflare의 대응

Re2 (Google) 같은 linear-time regex 엔진 검토
WAF change에 CPU profiling
Rolling deployment (한 번에 전 세계 X)

4부 — Fastly 2021-06-08 — 한 고객이 인터넷 반을 멈추다

무슨 일

2021년 6월 8일 10:00 UTC
Fastly CDN 전 세계 다운 (약 1시간)
영향: Amazon, Reddit, CNN, NYT, PayPal, UK 정부 웹사이트
"인터넷이 절반 멈췄다"고 보도

원인

한 고객이 특정 config 변경
이 config가 Fastly 내부의 softwarebug trigger
→ 전 세계 edge 서버 cache miss + 시스템 오류
→ 85% 트래픽 영향

5월부터 배포된 버그

5월 12일: 소프트웨어 배포 (bug 심어짐)
6월 8일: 특정 고객 config가 버그 trigger
  → 잠복했던 bug 폭발

교훈

Multi-tenancy의 위험: 한 고객이 모두에게 영향
Dormant bugs: 몇 주/몇 달 후 터짐
Fast recovery: Fastly 1시간 안에 복구 (인상적)
고객 테스트 한계: 실제 production mix 시뮬레이션 불가

5부 — AWS S3 2017-02-28 — 오타 하나가 인터넷을 멈추다

무슨 일

2017년 2월 28일 09:37 PST
AWS us-east-1 S3 다운 (약 4시간)
영향: Slack, Quora, Trello, Medium, 수천 사이트
AWS "Service Health Dashboard"도 S3 쓰기 때문에 못 업데이트

원인

엔지니어가 billing 시스템 디버깅:

S3 subsystem 서버 일부를 의도적으로 재시작할 계획
하지만 오타로 더 많은 서버를 재시작

구체적으로:
- Index subsystem + Placement subsystem 핵심 서버 삭제
- 이 subsystem은 S3 core
- 완전 재시작 필요 → 4시간

교훈

인간의 실수는 불가피: 도구로 방어해야
Automation의 빈자리: 파괴적 명령 확인 X
Blast radius: 모든 subsystem 같은 AZ
Dashboard dependency: Status page가 같은 시스템 의존

AWS의 대응

Dangerous operations에 대한 safeguard 추가
Command-line tool 개선 (--confirm 같은)
Service 의존성 재설계
Status page 독립

6부 — Knight Capital 2012-08-01 — 8분에 $440M 잃다

무슨 일

2012년 8월 1일 오전 9:30 (뉴욕 증시 개장)
Knight Capital(미국 주식 시장 주요 market maker)
8분 만에 $440M 손실
→ 회사 거의 파산, 3개월 후 매수

원인 — Dead Code Resurrection

배경:
- Knight의 거래 시스템에 수년 사용 안 한 "Power Peg" 기능
- Dead code로 남아 있음
- 새 기능 배포 중 8개 서버 중 1개에 배포 실수
- 이 서버가 "Power Peg" code를 re-enable flag로 해석
- 시장 개장과 함께 광적인 주문 생성 시작

8분 간:
- 수백만 주문 생성
- 가격에 무관하게 buy high, sell low
- 시장 왜곡
- 총 $440M 손실

교훈

Dead code 제거: 쓰지 않는 코드는 위험
배포 자동화: 수동 8개 서버 업데이트는 에러 온상
Feature flag 재사용 금지: 같은 flag를 다른 의미로 쓰면 재앙
Circuit breaker: 비정상 주문 자동 차단 X
Testing gap: Pre-production에서 문제 잡혔어야

7부 — GitLab 2017-01-31 — DB wipe

무슨 일

2017년 1월 31일 저녁
GitLab.com 데이터베이스 wipe
300GB 데이터 잃을 뻔 (복구 가능: 약 6시간 transaction 손실)

원인 — 인간 실수 + 백업 미작동

상황: DB replication 문제 디버깅
  1차 DB에서 replication 꼬임
  엔지니어가 replica 정리하려 함
  
실수 1: rm -rf를 잘못된 DB에 실행
  → Production DB 일부 삭제

복구 시도:
  백업 1 (daily pg_dump): 오류로 파일 0 bytes
  백업 2 (LVM snapshot): 6시간 전
  백업 3 (S3 upload): 활성화 안 됨
  백업 4 (replica): 문제의 원인이었던 그것
  백업 5 (Azure 디스크 snapshot): 복구 가능

→ 결국 6시간치 transaction 손실

혁신적 대응

Live-stream postmortem: GitLab이 YouTube로 실시간 복구 과정 공개. 수만 명 시청. 투명성의 극치.

교훈

백업은 테스트: 안 복구해봤으면 백업 X
여러 백업 종류: 하나 실패해도 다른 것
인간 실수 방지: Destructive command는 double-check
투명성: GitLab 신뢰 오히려 증가

8부 — Facebook 2021-10-04 — BGP가 또 범인

무슨 일

2021년 10월 4일 15:40 UTC
Facebook, Instagram, WhatsApp 전 세계 6시간 다운
Facebook 직원도 건물 못 들어감 (badge 시스템도 의존)

원인

BGP config 변경 → Facebook의 DNS 서버가 internet에서 사라짐
내부 도구도 모두 internet 의존 → 엔지니어가 복구 못함
물리적 출입증도 영향 → 데이터센터 진입 불가

복구:
- 데이터센터에 물리적으로 진입
- 네트워크 장비 수동 리셋
- BGP 광고 복원

교훈

Out-of-band access: 주 네트워크 죽어도 들어갈 경로
Dependency loop: 모든 것을 Internet에 의존 시 self-lockout
물리적 접근: 디지털 인프라도 물리 공간 필요
BGP의 위험: 반복되는 패턴

9부 — Heroku 2021-04-13 — GitHub OAuth 토큰 유출

무슨 일

2021년 4월
Heroku의 GitHub OAuth integration 토큰 유출
공격자가 수천 Heroku 계정의 GitHub repos 접근
Heroku가 초기에 제대로 알리지 않아 신뢰 상실

교훈

Secret 관리: OAuth token도 secret
Rotation: 주기적 교체
신속한 disclosure: 숨기면 더 큰 위기
Third-party risk: 통합은 취약점 창구

10부 — Roblox 2021-10-28 — 73시간 다운

무슨 일

2021년 10월 28일부터 73시간 다운
5천만 DAU 게임 플랫폼
Black Friday 주말

원인

HashiCorp Consul (service discovery) 클러스터 서버 부하
새 기능이 Consul에 과도한 쓰기 부하 발생
Consul consensus 깨짐 → 전체 downtime

특별한 점

HashiCorp + Roblox 공동 포스트모템. 벤더와 고객이 함께 분석.

교훈

Service discovery dependency: 핵심은 극단적 안정
Chaos testing: 부하 테스트에서 잡았어야
Vendor collaboration: 책임 공유 모델

11부 — Atlassian 2022-04-05 — 14일 다운

무슨 일

2022년 4월
775 Atlassian 고객 (Jira, Confluence 등)
14일간 복구 중
스크립트 오류로 데이터 삭제

원인

legacy 기능 deprecation 스크립트
"사이트" 단위로 삭제해야 했는데 "앱" 단위로 잘못 인자
→ 고객 전체 사이트 데이터 삭제
복구: 백업에서, but 고객 데이터이므로 각각 수작업

교훈

Destructive script는 dry-run 필수
Backup per tenant: SaaS 멀티테넌시 복구 핵심
Restore 속도: 백업은 있어도 복구 느리면 의미 반감
고객 communication: Atlassian이 초기 대응 부실로 비난받음

12부 — 실패 패턴 10가지

모든 postmortem에서 보이는 패턴:

수동 작업 + 실수 (Knight, AWS, GitLab)
Config change without staging (Cloudflare)
Dead code / 사용 안 하는 기능 (Knight)
Global rollout without canary (Cloudflare, Fastly)
BGP (Facebook, Cloudflare)
Backup 작동 안 함 (GitLab)
Dependency loop (Facebook, AWS S3 dashboard)
Multi-tenant blast radius (Fastly, Atlassian)
Third-party integration risk (Heroku)
Chaos testing gap (Roblox)

13부 — Postmortem 템플릿

실전 템플릿

# Incident: [Title]
Date: 2026-04-15
Severity: SEV1/SEV2/SEV3
Duration: 09:30-11:45 UTC (2h 15m)
Impact: X users affected, Y revenue lost

## Summary
[2-3 sentences]

## Impact
- Users: ...
- Revenue: ...
- Services: ...
- Customer communications: ...

## Timeline
- 09:30 UTC: Alert triggered
- 09:35 UTC: Engineer paged
- ...

## Root Cause
[Technical explanation]
Contributing factors:
- ...

## Detection
- How was it detected?
- Time to detect: X min
- Could it have been detected faster?

## Response
- Time to mitigate: X min
- What worked?
- What didn't?

## Recovery
[Steps taken to restore service]

## Lessons Learned
### What went well
- ...

### What went wrong
- ...

### Where we got lucky
- ...

## Action Items
| Item | Owner | Priority | Due |
|---|---|---|---|
| Add canary deployment | @alice | P0 | 2026-04-30 |
| ... | | | |

## Supporting Data
- Graphs, logs, screenshots

작성 팁

사건 후 48시간 이내 초안
여러 사람 리뷰 (관련자 모두)
Action item은 SMART (Specific, Measurable, ...)
Follow-up: 2주, 4주 후 status 체크
공개 고려: 일부라도 외부 공유

14부 — 체크리스트 12개

15부 — 안티패턴 10가지

누가 했는지 찾기 → 비난 문화
Postmortem 공개 안 함 → 같은 팀이 같은 실수
Action item 추적 X → 종이 호랑이
1시간 미팅으로 끝 → 깊이 없음
Root cause를 하나로 → 복잡한 사건은 여러 원인
"Just human error" → 시스템 설계 문제 회피
SEV1 아니면 postmortem X → 작은 것에서 배움
백업 있다고 안심 → 복구 테스트 안 함
Chaos Engineering 미룸 → 프로덕션이 Chaos
Legal/PR이 Postmortem 편집 → 진실 희석

마무리 — "실패는 비싸지만, 배움은 더 비싸지 않다"

Cloudflare, GitLab, AWS — 업계 톱들이 공개 postmortem으로 업계 전체를 가르친다. 그들이 잃은 것: 100M+ 달러. 우리가 얻는 것: 공짜 교훈.

다음번 당신의 서비스가 다운되면:

누구를 탓할 시간에 시스템을 고쳐라
부끄러워할 시간에 문서화해라
숨길 시간에 팀과 공유해라

"실패에서 배울 수 있는 조직이 경쟁력". Google SRE 책이 25년 전부터 했던 말.

다음 글은 Season 3 Ep 3 — 스케일링 변곡점 완전 가이드. 1 → 100 → 10K → 100K → 1M → 10M 사용자별 아키텍처 변화. 언제 DB 샤딩? 언제 Microservices? 언제 CDN? 구체적 임계점.

다음 글 예고 — "스케일링 변곡점 완전 가이드: 100 → 10K → 1M 사용자별 아키텍처 진화"

Season 3 Ep 3은:

100 users: 단일 서버, SQLite
10K users: Rails + Postgres + Redis
100K users: read replica, 캐시, CDN
1M users: read/write split, 샤딩
10M users: Microservices 검토
언제 언어 바꿀까?
Real 회사들의 변곡점

다음 글에서.