adr

name	adr
description	Architecture Decision Record(ADR)를 작성한다. 기술적 결정사항, 설계 선택, 트레이드오프를 문서화하여 나중에 "왜 이렇게 했지?"를 알 수 있게 한다. 다음 상황에서 반드시 이 스킬을 사용한다: - "ADR 써줘", "결정사항 문서화해줘", "이 결정 기록해줘" - 기술 방향 선택 후 ("A 대신 B 쓰기로 했어") - 설계 논의가 끝났을 때 - 나중에 이 결정이 왜 내려졌는지 설명이 필요할 것 같을 때 - "/adr" 직접 호출 ARGUMENTS: 결정 내용 또는 결정 번호 (없으면 대화에서 추출)

adr

결정사항을 ADR 문서로 남긴다. 나중에 합류하는 팀원이나 미래의 자신이 "왜 이렇게 됐지?"를 이해할 수 있게 하는 것이 목표.

---

Step 1. 기존 ADR 번호 확인

docs/adr/ 디렉토리를 읽어 가장 최근 번호를 확인한다:

ls docs/adr/ | sort | tail -5

다음 번호를 사용한다. (없으면 0001부터 시작)

---

Step 2. 결정 내용 추출

ARGUMENTS 또는 대화 맥락에서 다음을 파악한다:

• 무엇을 결정했나? (핵심 선택)
• 왜 이 선택을 했나? (근거, 트레이드오프)
• 무엇을 선택하지 않았나? (대안과 제거 이유)
• 어떤 결과가 예상되나? (긍정적 영향, 제약사항)

명확하지 않은 부분이 있으면 작성 전에 질문한다.

---

Step 3. ADR 파일 작성

파일명: docs/adr/{번호}-{kebab-case-제목}.md 예: docs/adr/0003-use-postgresql-over-mysql.md

템플릿

# ADR-{번호}: {제목}

- **상태:** Accepted | Proposed | Deprecated | Superseded by ADR-{번호}
- **결정일:** YYYY-MM-DD
- **결정자:** {팀/사람}

---

## 배경

[이 결정이 필요하게 된 이유. 어떤 문제가 있었나?]

---

## 결정

**[한 문장으로 핵심 결정]**

[상세 설명]

---

## 근거

[왜 이 선택을 했는가. 비교표가 있으면 좋음]

---

## 결과

### 긍정적 영향
- ...

### 제약 사항 / 주의사항
- ...

### 재검토 조건 (선택)
[언제 이 결정을 다시 검토해야 하나?]

---

## 관련 문서

- [링크]

---

Step 4. 상태값 사용 기준

상태	의미
Proposed	논의 중, 아직 확정 안 됨
Accepted	결정 완료, 현재 적용 중
Deprecated	더 이상 권장하지 않지만 코드는 남아있음
Superseded by ADR-{번호}	이후 ADR이 이 결정을 대체함

---

Step 5. 좋은 ADR의 기준

작성 후 스스로 체크:

• "왜 A가 아니라 B를 선택했는가"가 명확한가?
• 나중에 합류한 팀원이 이 문서만 읽고 결정 맥락을 이해할 수 있는가?
• 대안들을 검토했다는 것이 보이는가?
• 이 결정의 한계/제약이 솔직하게 적혀있는가?
• 재검토가 필요한 조건이 적혀있는가?

---

주의사항

• ADR은 결정 시점의 snapshot이다. 나중에 틀렸더라도 수정하지 않고 새 ADR을 써서 supersede한다.
• 완벽한 문서보다 있는 것이 낫다. 짧아도 괜찮다.
• "당연한 것"도 적어라. 미래에는 당연하지 않을 수 있다.