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

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 없이 빠른 전파

교훈

1. **Config change도 배포**: Canary 필수

2. **Central control의 양날**: 속도 vs 폭발 반경

3. **BGP은 위험**: 실수가 인터넷 단위

4. **투명한 포스트모템**: 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 처리 불가

교훈

1. **Regex는 위험**: 복잡해지면 ReDoS 공격 가능

2. **WAF rule은 global change**: 한 수정이 전 세계

3. **CPU 테스트 필요**: Latency + throughput도

4. **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 폭발

교훈

1. **Multi-tenancy의 위험**: 한 고객이 모두에게 영향

2. **Dormant bugs**: 몇 주/몇 달 후 터짐

3. **Fast recovery**: Fastly 1시간 안에 복구 (인상적)

4. **고객 테스트 한계**: 실제 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시간

교훈

1. **인간의 실수는 불가피**: 도구로 방어해야

2. **Automation의 빈자리**: 파괴적 명령 확인 X

3. **Blast radius**: 모든 subsystem 같은 AZ

4. **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 손실

교훈

1. **Dead code 제거**: 쓰지 않는 코드는 위험

2. **배포 자동화**: 수동 8개 서버 업데이트는 에러 온상

3. **Feature flag 재사용 금지**: 같은 flag를 다른 의미로 쓰면 재앙

4. **Circuit breaker**: 비정상 주문 자동 차단 X

5. **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로 실시간 복구 과정 공개**.

수만 명 시청. 투명성의 극치.

교훈

1. **백업은 테스트**: 안 복구해봤으면 백업 X

2. **여러 백업 종류**: 하나 실패해도 다른 것

3. **인간 실수 방지**: Destructive command는 double-check

4. **투명성**: 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 광고 복원

교훈

1. **Out-of-band access**: 주 네트워크 죽어도 들어갈 경로

2. **Dependency loop**: 모든 것을 Internet에 의존 시 self-lockout

3. **물리적 접근**: 디지털 인프라도 물리 공간 필요

4. **BGP의 위험**: 반복되는 패턴

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

무슨 일

2021년 4월

Heroku의 GitHub OAuth integration 토큰 유출

공격자가 수천 Heroku 계정의 GitHub repos 접근

Heroku가 초기에 제대로 알리지 않아 신뢰 상실

교훈

1. **Secret 관리**: OAuth token도 secret

2. **Rotation**: 주기적 교체

3. **신속한 disclosure**: 숨기면 더 큰 위기

4. **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 공동 포스트모템**. 벤더와 고객이 함께 분석.

교훈

1. **Service discovery dependency**: 핵심은 극단적 안정

2. **Chaos testing**: 부하 테스트에서 잡았어야

3. **Vendor collaboration**: 책임 공유 모델

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

무슨 일

2022년 4월

775 Atlassian 고객 (Jira, Confluence 등)

14일간 복구 중

스크립트 오류로 데이터 삭제

원인

legacy 기능 deprecation 스크립트

"사이트" 단위로 삭제해야 했는데 "앱" 단위로 잘못 인자

→ 고객 전체 사이트 데이터 삭제

복구: 백업에서, but 고객 데이터이므로 각각 수작업

교훈

1. **Destructive script는 dry-run 필수**

2. **Backup per tenant**: SaaS 멀티테넌시 복구 핵심

3. **Restore 속도**: 백업은 있어도 복구 느리면 의미 반감

4. **고객 communication**: Atlassian이 초기 대응 부실로 비난받음

12부 — 실패 패턴 10가지

모든 postmortem에서 보이는 패턴:

1. **수동 작업 + 실수** (Knight, AWS, GitLab)

2. **Config change without staging** (Cloudflare)

3. **Dead code / 사용 안 하는 기능** (Knight)

4. **Global rollout without canary** (Cloudflare, Fastly)

5. **BGP** (Facebook, Cloudflare)

6. **Backup 작동 안 함** (GitLab)

7. **Dependency loop** (Facebook, AWS S3 dashboard)

8. **Multi-tenant blast radius** (Fastly, Atlassian)

9. **Third-party integration risk** (Heroku)

10. **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

작성 팁

1. **사건 후 48시간 이내** 초안

2. **여러 사람 리뷰** (관련자 모두)

3. **Action item은 SMART** (Specific, Measurable, ...)

4. **Follow-up**: 2주, 4주 후 status 체크

5. **공개 고려**: 일부라도 외부 공유

14부 — 체크리스트 12개

- [ ] Postmortem 템플릿 팀에 도입

- [ ] Blameless 문화 명시 + 훈련

- [ ] Action item tracking (Jira/Linear)

- [ ] 2주/4주 follow-up 미팅

- [ ] 백업 복구 **실제** 테스트 (분기 1회)

- [ ] Chaos Engineering 시작 (간단한 것부터)

- [ ] Canary / Progressive rollout 강제

- [ ] Out-of-band access (건물/네트워크)

- [ ] Destructive command safeguard (--confirm)

- [ ] Dead code 정기 정리

- [ ] Incident response runbook

- [ ] Company-wide Game Day (연 1회)

15부 — 안티패턴 10가지

1. **누가 했는지 찾기** → 비난 문화

2. **Postmortem 공개 안 함** → 같은 팀이 같은 실수

3. **Action item 추적 X** → 종이 호랑이

4. **1시간 미팅으로 끝** → 깊이 없음

5. **Root cause를 하나로** → 복잡한 사건은 여러 원인

6. **"Just human error"** → 시스템 설계 문제 회피

7. **SEV1 아니면 postmortem X** → 작은 것에서 배움

8. **백업 있다고 안심** → 복구 테스트 안 함

9. **Chaos Engineering 미룸** → 프로덕션이 Chaos

10. **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 회사들의 변곡점

다음 글에서.