아키텍처 결정 기록
ADR은 18개월 후에도 누군가가 왜 결정이 내려졌는지 모른 채 해결된 질문을 다시 열지 않도록 하고, 문맥이 변경될 때 결정을 의도적으로 재검토할 수 있도록 존재합니다.
위치
docs/adr/NNNN-짧은-제목.md 형식으로 순차적으로 번호를 매깁니다. 디렉터리에서 다음 번호와 팀 템플릿을 확인하고, 템플릿이 있으면 따릅니다.
템플릿
# NNNN. <결정 형태의 제목: "주문 서비스에 Aurora PostgreSQL 사용">
날짜: YYYY-MM-DD
상태: 제안됨 | 승인됨 | NNNN으로 대체됨 | 폐기됨
결정자: <이름 또는 팀>
## 맥락
<어떤 요소가 작용하고 있는가: 요구사항, 제약 조건, 현재의 문제점, 마감일, 규정
준수, 팀 기술, 비용 범위. 2~4문단. 사실이지 의견이 아님.>
## 결정
<한두 문장, 현재 시제: "우리는 … 할 것입니다">
## 고려한 옵션
### 옵션 A: <이름>
장점 / 단점 / 대략적 비용 / 운영 부담
### 옵션 B: <이름>
…
## 결과
<무엇이 쉬워지고, 무엇이 어려워지며, 이제 무엇을 해야 하는가 (마이그레이션, 교육,
새로운 런북), 명시적으로 감수하기로 한 위험.>
## 후속 조치
- [ ] <소유자가 알려진 구체적인 작업>
작성 지침
- 문맥을 작성할 때는 신규 팀원이 결정을 읽기 전에 문제가 실제임을 동의하도록 하세요.
- 옵션을 동일한 기준으로 비교하세요: 비용, 운영 부하, 종속성, 팀 친숙도, 제공 시간, 보안/규정 준수. 가능한 숫자를 포함하세요 (월 예상 비용, RTO/RPO, 처리량).
- 선택되지 않은 옵션의 장점에 대해 솔직하세요. 대안을 허수아비로 만드는 ADR은 신뢰를 잃습니다.
- 결과에는 부정적인 것도 포함됩니다. "이제 백업해야 할 데이터베이스가 두 개가 되었다"는 거기에 속합니다.
- 2페이지 미만으로 유지하세요. 인라인으로 넣지 말고 스파이크, 벤치마크, 티켓에 링크하세요.
- 대체할 때는 이전 ADR의 상태를 업데이트하고 양방향으로 링크하세요.
$ARGUMENTS가 주어진 경우
제목으로 사용하고, 파일 이름은 그로부터 파생합니다.