Files
2nd/10_Wiki/Topic_Programming/Backend/Lessons Learned.md
T
Antigravity Agent 9148c358d0 docs(10_Wiki): 위키 전체 재구성 — Topic_* 폴더를 4개 카테고리로 통합 + 대규모 중복 제거
Topic_Agent/Topic_Blog/Topics/Topics_Biz/Topics_Meeting/Topics_Rag의 마크다운 지식 문서를
Topic_General/Topic_Programming/Topic_Graphic/Topic_Business 4개 카테고리로 재분류.

- 중복 제거: frontmatter의 status:duplicate/merged + duplicate_of/redirect_to 필드로
  자기 자신을 중복으로 선언한 리다이렉트 stub 1032개 제거, 완전 동일 내용 파일 472개 제거,
  동일 파일명·다른 내용 충돌 시 더 큰(완전한) 버전만 유지(162개 제거) — 총 1639개 중복 제거.
- 분류: 폴더 단위로 명확한 항목(AI_and_ML/Coding/Architecture 등 → Programming,
  Comfyui/Visual_Effects → Graphic, Topics_Biz/Topics_Meeting/사업 등 → Business,
  Poetic_Blog_Writing/창의성/Game_Design 등 → General)은 폴더 우선순위로,
  나머지 혼재 폴더(Topic_Agent/Topic_Blog/Topics 루트/Thinking & Reasoning/Other/UI_UX_Assets)는
  title/tags 키워드 스코어링으로 파일 단위 분류(불명확한 경우 General로 폴백).
  원본 폴더명은 "From_*" 서브폴더로 보존해 추적 가능성 유지.
- 최종 배치: Programming 2784 / General 1608 / Graphic 285 / Business 249 = 4926개 문서.
- 에이전트 운영 상태(.astra/.agent/.obsidian/sessions/memory/_company/docs/lessons/_shared/src)는
  지식 콘텐츠가 아니므로 재분류 대상에서 제외하고 원위치 유지.
- Topics/Topic_email(상위 보호 폴더 Topic_email과 파일명 100% 중복) 삭제 — 보호 폴더 자체는 미변경.
- 완전히 비게 된 Topic_Agent/Topic_Blog/Topics_Biz/Topics_Rag 폴더 제거.
2026-07-05 00:33:48 +09:00

164 lines
3.8 KiB
Markdown

---
id: wiki-2026-0508-lessons-learned
title: Lessons Learned
category: 10_Wiki/Topics
status: verified
canonical_id: self
aliases: [Postmortem, Retrospective, After-Action Review]
duplicate_of: none
source_trust_level: A
confidence_score: 0.9
verification_status: applied
tags: [process, postmortem, learning, sre]
raw_sources: []
last_reinforced: 2026-05-10
github_commit: pending
tech_stack:
language: n/a
framework: n/a
---
# Lessons Learned
## 매 한 줄
> **"매 institutionalized regret-into-knowledge transformer"**. 매 1940s US Army After-Action Review (AAR) 의 origin → 매 2003 Google SRE 의 blameless postmortem 의 modern form. 매 each incident 매 paid-for data; throwing it 매 paying twice.
## 매 핵심
### 매 mechanism
1. Incident / project ends.
2. Timeline 매 reconstructed.
3. Root causes (plural) 매 identified.
4. Action items 매 owned + scheduled.
5. Doc 매 published, indexed, re-read.
### 매 modern best practices (Google SRE)
- **Blameless** — 매 systems 매 fail, not people.
- **Concrete action items** with owners + due dates.
- **5 Whys** or **Causal Analysis using STAMP** (no single root cause).
- **Public** within org (searchable).
### 매 응용
1. Production incidents (PagerDuty integration).
2. Project retros (sprint, quarter).
3. Security incidents (legal-friendly variant).
## 💻 패턴
### Postmortem template (Google SRE-style)
```markdown
# Incident YYYY-MM-DD: <short title>
## Summary
1-2 sentences.
## Impact
- Users affected: ...
- Duration: ...
- Revenue: ...
## Root causes (plural)
1. ...
2. ...
## Trigger
What event started the incident.
## Resolution
What stopped it.
## Detection
How we knew (and how late).
## Timeline (UTC)
| Time | Event |
|---|---|
| 14:32 | Deploy started |
| 14:34 | Error rate spike |
| ... | ... |
## What went well
- ...
## What went poorly
- ...
## Where we got lucky
- ...
## Action items
| ID | Action | Owner | Due | Type |
|---|---|---|---|---|
| AI-1 | Add canary deploy | @alice | 2026-05-20 | prevent |
| AI-2 | Improve alert | @bob | 2026-05-15 | detect |
```
### Action item tracker (GitHub-issue export)
```bash
gh issue create \
--title "AI-1: Add canary deploy" \
--label "postmortem,prevent" \
--assignee alice \
--milestone "Q2 2026"
```
### 5 Whys (causal chain)
```
Why did the site go down? Server OOM.
Why OOM? Cache grew unbounded.
Why unbounded? No eviction policy.
Why no policy? PR review missed it.
Why missed? Checklist had no cache item.
→ Root: missing checklist item (process), not the engineer.
```
### Aggregation across postmortems (yearly review)
```sql
SELECT root_cause_category, COUNT(*) AS n, SUM(downtime_minutes) AS total_dt
FROM postmortems
WHERE date >= '2025-01-01'
GROUP BY root_cause_category
ORDER BY total_dt DESC;
```
### Embedded retro into sprint
```markdown
- ✅ Did → keep
- 🔄 Did → improve
- ❌ Did → stop
- 💡 Didn't → start
```
## 매 결정 기준
| 상황 | Format |
|---|---|
| Production incident | Google SRE postmortem |
| Sprint end | Sailboat / Start-Stop-Continue |
| Project end | After-Action Review |
**기본값**: Blameless, concrete action items, public, re-read at 30 days.
## 🔗 Graph
- 부모: [[SRE]]
- 변형: [[After-Action-Review]]
## 🤖 LLM 활용
**언제**: post-incident, project end, security event.
**언제 X**: trivial bug fix (use commit message instead).
## ❌ 안티패턴
- **Blame culture**: 매 hides root causes.
- **No follow-through on action items**: 매 same incident again.
- **Single root cause**: 매 systems-thinking 매 missed.
- **Document then forget**: 매 unread postmortem 매 worthless.
## 🧪 검증 / 중복
- Verified (Google SRE Book Ch. 15; Etsy "blameless postmortem" essay; US Army AAR doctrine).
- 신뢰도 A.
## 🕓 Changelog
| 날짜 | 변경 |
|---|---|
| 2026-05-08 | Phase 1 |
| 2026-05-10 | Manual cleanup — Lessons Learned FULL with SRE template |