AI 장애 분석 포스트모템 시리즈 9/9
포스트모템 초안이 만들어지면 다음에는 공유 방식이 남았습니다. 공유 대상이 Mattermost, Teams, 사내 게시판, GitLab issue 중 무엇이든 원칙은 같았습니다. AI는 초안을 만들고, 최종 확정은 사람이 합니다.
자동 공유 전에 두는 단계
바로 자동 전송을 붙이지 않았습니다. 먼저 이 순서로 여러 번 사람이 돌려본 뒤 반복되는 단계만 골라서 자동화 후보로 옮겼습니다.
- 사람이 시간 범위와 서비스명을 입력합니다.
- AI가 Datadog/AWS/Git 데이터를 조회합니다.
- AI가 포스트모템 초안을 만듭니다.
- 사람이 fact와 assumption을 검토합니다.
- 민감정보를 제거합니다.
- 내부 공유 채널에 초안을 올립니다.
- 승인 후 공식 포스트모템으로 이동합니다.
사람 검토와 민감정보 제거 없이 6번을 자동화하면 안 됐습니다.
최소 구조
처음에는 아래 정도로 시작해도 됐습니다.

Trigger를 자동화하지 않아도 됐습니다. 처음에는 사람이 이 정도 입력하는 것으로 시작했습니다.
Investigate account-service incident.
Time: 2026-06-12 13:00-15:30 KST
Use read-only APIs.
Create postmortem draft.
초안 저장 위치
조사 작업은 워크벤치 프로젝트를 따로 두는 편이 편했습니다.
incident-rca-workbench/
prompts/
scripts/
outputs/
이 시리즈에서는 같은 역할을 generated/와 evidence/가 나눠 맡았습니다.
blog-series-ai-incident-postmortem/
evidence/
generated/
포스트모템 초안은 generated/에 뒀습니다.
generated/2026-06-12-account-service-postmortem-draft.md
파일로 남기니 diff를 볼 수 있었고, 사람 검토가 쉬웠고, 민감정보 제거를 확인할 수 있었습니다.
공유 전에 제거한 것
공유 채널이 내부라도 모든 정보를 그대로 올리지 않았습니다. 제거 또는 치환한 것은 아래 항목이었습니다:
- API key
- Datadog Application Key
- AWS account id
- task arn
- private ECR URL
- internal host
- customer identifier
- employee name
- raw cookie/header
- exact IP list
내부 포스트모템에는 일부 실명이 필요할 수 있지만 채널 공유용 초안에는 최소한으로 줄였습니다.
채널에 올린 메시지 형식
채널에는 포스트모템 전체를 붙이지 않았습니다. 대신 요약과 링크만 올렸습니다.
[RCA Draft] account-service incident, 2026-06-12
Summary:
- GET /v3/auth traffic increased 6-10x from mobile web users.
- Auth/session lookup exhausted the R2DBC write pool.
- /heartbeat shared the same DB path and timed out.
- ECS health checks triggered repeated task replacement.
Current confidence:
- Trigger: high
- Failure mechanism: high after code review
- Traffic source business trigger: still needs confirmation
Draft:
generated/2026-06-12-account-service-postmortem-draft.md
Needs review:
- owner for R2DBC pool timeout
- owner for /heartbeat redesign
- owner for ECS slow start / CodeDeploy alarm gate
이 정도면 채널에서 토론이 시작됐습니다.
자동화할 수 있는 것과 하면 안 되는 것
자동화한 것:
- Datadog query
- AWS read-only query
- GitLab read-only query
- timeline 초안
- evidence table
- missing evidence list
- action item 후보
- 민감정보 패턴 검사
자동화하지 않은 것:
- root cause 최종 확정
- owner 자동 지정
- 고객 공지문 발송
- 외부 공개
- 설정 변경
- monitor mute
- deploy/rollback
read-only에서 시작해서 쓰기 권한은 마지막까지 분리해두었습니다.
조사 진행 중에 실제로 공유한 흐름
이번 사건에서는 조사 단계마다 채널에 이런 메시지를 올렸을 것입니다. 1차 조사 후에는 이렇게 공유할 수 있습니다:
/heartbeat가 원인이 아니라 symptom일 가능성이 큽니다.
auth/account endpoint long span과 ECS task churn이 같이 보입니다.
Metric 권한 부족으로 GC/CPU 검증은 아직 못 했습니다.
2차 조사 후:
GC/CPU는 원인이 아닌 것으로 보입니다.
GET /v3/auth traffic이 6-10x 증가했고, Old Gen 증가는 stuck request retention 증상으로 보입니다.
AWS 조사 후:
ALB health check가 /heartbeat를 60s interval / 30s timeout으로 보고 있고, slow start가 0입니다.
ECS replacement loop가 장애를 증폭했을 가능성이 큽니다.
코드 분석 후:
R2DBC write pool acquire timeout이 없고, /heartbeat도 같은 pool을 기다립니다.
APM에 SQL child span이 없던 이유는 SQL 전 connection acquire wait였을 가능성이 큽니다.
단계별로 공유하면 팀이 결론의 변화를 따라올 수 있었습니다.
확장할 때도 review gate는 유지했습니다
처음 자동화는 이 흐름에서 시작했습니다.
Manual trigger
-> AI read-only investigation
-> Markdown postmortem draft
-> human review
-> internal channel summary
-> official postmortem page
이게 반복되면 아래 정도로 확장할 수 있었습니다.
Datadog monitor
-> EventBridge or webhook
-> investigation job
-> draft generation
-> reviewer notification
이 확장에서도 자동 공개는 붙이지 않았습니다. review gate는 그대로 둡니다.
시리즈를 돌아보고 남긴 한 문장
처음 단서는 /heartbeat 30초와 Old Gen 증가였습니다. 마지막에 정리된 내용은 아래와 같았습니다.
모바일 유입 증가
-> GET /v3/auth 6-10x traffic surge
-> R2DBC write pool acquire wait
-> /heartbeat DB ping도 같은 pool에서 대기
-> ALB health check timeout
-> ECS task replacement loop
한 화면에서 나온 결론이 아니었습니다. Datadog, AWS ECS/ALB, RDS, traffic source, code path를 차례로 붙였기 때문에 나왔습니다. AI가 잘한 일은 정답을 대신 낸 것이 아니었습니다. 사람이 놓치기 쉬운 증거들을 빠르게 연결하고, 무엇이 사실이고 무엇이 가설인지 드러낸 쪽에 가까웠습니다.
다음 조사에서 실제로 바꾼 것
이 시리즈 이후 아래는 문서에 남겨뒀습니다.
- 조사 시작 전에 API가 metric, host, task tag까지 응답하는지 확인합니다.
- 포스트모템 템플릿 파일을 먼저 열어두고 프롬프트를 짭니다.
- 초안을 볼 때 fact / assumption / hypothesis / ruled out / action이 자기 자리에 있는지 확인한 뒤 문장을 손봅니다.
- 자동 공유는 review gate 뒤에만 붙입니다.
한 화면에서 결론을 확정하지 않는 것. 결국 시리즈에서 남긴 건 결국 이 순서였습니다.
'성장과 기술 > 개발과 자동화' 카테고리의 다른 글
| RCA 초안을 사실, 가설, 액션아이템으로 나누기 (0) | 2026.07.24 |
|---|---|
| 포스트모템 템플릿을 먼저 정해야 하는 이유 (0) | 2026.07.24 |
| GitLab 배포 이력과 장애 시점을 연결하기 (0) | 2026.07.24 |
| AWS 지표로 Datadog 가설을 검증하기 (0) | 2026.07.24 |
| APM Trace, 로그, JVM 지표를 하나의 증거로 묶기 (0) | 2026.07.24 |
글에서 정리한 생각은 GitHub의 코드와 포트폴리오로 이어지고, 일부는 FamBlend 같은 제품 실험으로 확장됩니다.