이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.
- 네트워크 장애 회고에서 status code보다 더 중요한 증거는 무엇인가?
- 임시 완화, 근본 원인, 재발 방지, 관측 개선을 어떻게 분리하는가?
- 회고가 실제 다음 장애 대응 속도를 높이려면 어떤 action item이 필요하는가?
개요
네트워크 장애 회고는 “502가 났다”, “DNS 문제였다”, “인프라 설정 오류였다”로 끝나면 안 된다. 회고의 목표는 다음 장애에서 더 빨리 감지하고, 더 좁게 진단하고, 더 안전하게 완화할 수 있게 만드는 것이다.
좋은 회고는 계층별 증거, timeline, 놓친 관측 지점, 임시 완화와 근본 수정, 남은 위험을 분리한다. 누구의 실수인지보다 시스템이 왜 그 실수를 사용자 영향으로 키웠는지를 본다.
왜 백엔드 개발자가 알아야 하는가
백엔드 개발자는 장애 회고에서 앱 코드뿐 아니라 요청 경로 전체를 설명해야 한다.
- 사용자가 본 504가 proxy timeout인지 app timeout인지 DB timeout인지 밝혀야 한다.
- app log가 없었다면 요청이 어느 계층에서 멈췄는지 남겨야 한다.
- request id가 끊겼다면 다음에 연결되도록 개선해야 한다.
- 임시로 timeout을 늘렸다면 자원 점유 증가라는 남은 위험을 기록해야 한다.
- WAF rule을 완화했다면 보안 위험과 재강화 계획을 남겨야 한다.
회고는 학습 문서이자 운영 부채 목록이다.
요청 흐름에서의 위치
회고는 장애가 끝난 뒤 요청 경로를 다시 재구성한다.
사용자 증상
→ 응답 주체
→ 마지막 정상 계층
→ 실패 계층
→ 완화 조치
→ 근본 원인
→ 재발 방지
→ 관측 개선장애 중에는 빠른 완화가 먼저일 수 있지만, 회고에서는 증거를 다시 연결해 원인과 개선을 분리해야 한다.
원리
네트워크 장애 회고는 네 가지 질문에 답해야 한다.
| 질문 | 예시 |
|---|---|
| 사용자는 무엇을 경험했는가? | POST /orders 502, 일부 region 30분 영향 |
| 요청은 어디까지 도달했는가? | CDN/LB log 있음, app access log 없음 |
| 왜 그 지점에서 실패했는가? | health probe Host header 불일치로 target unhealthy |
| 다음에는 어떻게 더 빨리 알 것인가? | target health reason alert, probe config test |
root cause만 쓰면 부족하다. 감지 지연, 진단 지연, 완화 지연, 재발 방지 실패 가능성을 함께 봐야 한다.
회고 템플릿
1. 요약
2. 사용자 영향
3. 감지 경로와 감지 시각
4. 요청 경로와 실패 계층
5. timeline
6. 확인한 증거
7. 임시 완화
8. 근본 원인
9. 잘 동작한 것
10. 부족했던 관측 지점
11. 재발 방지 action item
12. 남은 위험과 owner회고 문서는 읽는 사람이 다음 장애에서 바로 runbook으로 쓸 수 있어야 한다.
Timeline 작성법
timeline은 “무슨 일이 있었는가”와 “무엇을 알게 되었는가”를 구분한다.
14:05 alert: ALB 502 증가
14:07 user report: POST /orders 실패
14:09 curl: DNS/TCP/TLS 정상, first_byte 0.06s, 502
14:12 ALB log: elb_status_code=502, target_status_code="-"
14:15 target health: unhealthy, reason=Health checks failed
14:18 recent change: health probe Host header 변경
14:22 rollback probe config
14:25 healthy target 회복
14:30 5xx 정상화이 timeline은 다음 장애에서 “즉시 502 + app log 없음 + target_status_code 없음” 패턴을 더 빨리 찾게 해 준다.
실무에서 자주 만나는 문제
- 원인을 한 문장으로만 남긴다.
- “LB 설정 오류”만 쓰면 다음에 무엇을 확인해야 하는지 남지 않는다.
- 어떤 설정, 어떤 증거, 어떤 영향이었는지 적는다.
- 임시 완화와 근본 수정을 섞는다.
- timeout 증가는 완화일 수 있지만 근본 원인은 slow dependency일 수 있다.
- action item을 분리한다.
- 잘 동작한 것을 기록하지 않는다.
- 어떤 alert, dashboard, 사람의 판단이 도움이 되었는지 남겨야 반복 가능해진다.
- 운영 역량은 좋은 패턴을 재사용하면서 커진다.
- 남은 위험을 숨긴다.
- WAF 예외, timeout 증가, fallback 임시 적용은 위험이 남는다.
- owner와 만료일을 둔다.
디버깅 방법
회고에서는 장애 중 수집한 증거를 계층별로 재정렬한다.
DNS:
TCP:
TLS:
HTTP status/header:
CDN/WAF:
LB/Gateway:
Proxy:
Application:
DB/API:
Client/browser:그리고 각 계층에 대해 묻는다.
- 이 계층이 정상이라는 증거가 있었는가?
- 이 계층이 실패했다는 증거가 있었는가?
- 이 계층의 로그를 장애 중 바로 볼 수 있었는가?
- 다음에는 어떤 metric이나 alert가 필요했는가?
코드로 확인하기
action item은 실행 가능해야 한다.
나쁜 action item:
네트워크 모니터링 강화
좋은 action item:
ALB target_status_code가 "-"인 502가 5분간 20건 이상이면
order-api oncall에 alert를 보낸다.
dashboard에 elb_status_code, target_status_code, target_health_reason을 추가한다.
owner: platform-team
due: 2026-07-07runbook 업데이트도 구체적으로 남긴다.
Runbook 추가:
즉시 502 + app log 없음 + target_status_code="-"이면
target health reason, health probe Host header, backend port/protocol을 확인한다.주니어가 자주 하는 오해
- 회고는 잘못한 사람을 찾는 자리라고 생각한다.
- 좋은 회고는 시스템이 왜 실패를 키웠는지 보고 다음 대응 능력을 올린다.
- root cause만 찾으면 회고가 끝났다고 생각한다.
- 감지, 진단, 완화, 재발 방지, 남은 위험이 모두 필요하다.
- 임시 완화가 성공하면 위험이 사라졌다고 생각한다.
- 임시 설정은 부작용과 만료일을 가져야 한다.
- 증거 없이 기억으로 timeline을 쓴다.
- 로그, metric, ticket, deploy 기록을 기준으로 작성해야 한다.
시니어의 설계 판단 기준
- 회고 action item은 owner, due date, 검증 방법이 있어야 한다.
- 기술 수정과 관측 개선을 함께 둔다.
- “다음에는 더 빨리 감지할 수 있는가”를 반드시 묻는다.
- 인프라와 앱 팀의 경계에서 사라진 신호를 복구한다.
- 회고 문서를 runbook, alert, dashboard, test로 연결한다.
인프라 협업 포인트
- 인프라 팀이 제공한 로그와 앱 팀 로그를 같은 timeline에 둔다.
- 인프라 설정 변경과 앱 배포를 같은 변경 목록에 넣는다.
- WAF/firewall/LB 임시 완화는 만료일과 재검토 owner를 둔다.
- 회고에서는 “인프라가 막았다”보다 “어떤 rule이 어떤 요청을 왜 차단했고 app은 어떤 신호를 제공하지 못했는가”로 쓴다.
실전 팁
- 회고 시작 전에 request id, dashboard screenshot, deploy log, config diff를 모은다.
- 회고 중에는 사실, 가설, 의견을 분리한다.
- 장애가 작아도 runbook 한 줄을 추가하면 다음 장애에서 이득이 난다.
- 개인 프로젝트에서도 장애 노트를 쓰면 운영 감각이 빠르게 쌓인다.
위험 신호!
- 회고가 “인프라 이슈” 한 줄로 끝난다.
- action item에 owner와 due date가 없다.
- 임시 완화가 영구 설정이 된다.
- 다음에 더 빨리 알 수 있는 alert나 dashboard 변경이 없다.
- 같은 유형의 장애가 반복되는데 runbook이 업데이트되지 않는다.
확인 질문
확인 질문
- 네트워크 장애 회고에서 status code보다 더 중요한 것은 무엇인가?
- 요청이 어느 계층까지 도달했고 누가 응답을 만들었으며 어떤 증거로 그렇게 판단했는지다.
- 좋은 action item의 조건은 무엇인가?
- 구체적이고 실행 가능하며 owner, due date, 검증 방법이 있어야 한다.
- 임시 완화와 근본 수정을 분리해야 하는 이유는 무엇인가?
- 임시 완화는 사용자 영향을 줄이는 조치이고, 근본 수정은 같은 장애가 반복되지 않게 하는 조치이기 때문이다.