StudyDad Loop 제품을 만들며 배운 운영과 설계를 기록합니다.

FamBlend를 중심으로 실제 구현, 운영 메모, GitHub 포트폴리오를 연결해 쌓아가는 StudyDad의 작업 기록입니다.

성장과 기술/개발과 자동화

내부 공유 채널에 RCA 초안을 올리는 워크플로우

박세식 2026. 7. 24. 23:00

AI 장애 분석 포스트모템 시리즈 9/9

포스트모템 초안이 만들어지면 다음에는 공유 방식이 남았습니다. 공유 대상이 Mattermost, Teams, 사내 게시판, GitLab issue 중 무엇이든 원칙은 같았습니다. AI는 초안을 만들고, 최종 확정은 사람이 합니다.

자동 공유 전에 두는 단계

바로 자동 전송을 붙이지 않았습니다. 먼저 이 순서로 여러 번 사람이 돌려본 뒤 반복되는 단계만 골라서 자동화 후보로 옮겼습니다.

  1. 사람이 시간 범위와 서비스명을 입력합니다.
  2. AI가 Datadog/AWS/Git 데이터를 조회합니다.
  3. AI가 포스트모템 초안을 만듭니다.
  4. 사람이 fact와 assumption을 검토합니다.
  5. 민감정보를 제거합니다.
  6. 내부 공유 채널에 초안을 올립니다.
  7. 승인 후 공식 포스트모템으로 이동합니다.

사람 검토와 민감정보 제거 없이 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 뒤에만 붙입니다.

한 화면에서 결론을 확정하지 않는 것. 결국 시리즈에서 남긴 건 결국 이 순서였습니다.

Next Step 이 글은 StudyDad 작업 루프의 한 조각입니다.

글에서 정리한 생각은 GitHub의 코드와 포트폴리오로 이어지고, 일부는 FamBlend 같은 제품 실험으로 확장됩니다.