백엔드 도메인 내부의 기술 결정을 BD-## 번호로 기록합니다 — "왜 그렇게 정했나"와 그때 검토한 트레이드오프. 상태가 Accepted인 것은 확정된 결정이며 구현이 따라야 합니다.
파트 간 합의 자체는 여기서 정하지 않습니다. 파트 간 영향이 있는 결정의 원본은 docs/ai/proposals/의 P 번호 절차와 공용 계약(Team-PinLog/docs의 static/)에 둡니다.
다만 그 합의를 백엔드가 어떻게 수용했고 구현에서 무엇을 감수하는지는 BD로 기록합니다. 이때 원본 근거를 옮겨 적지 않고 링크만 겁니다 — 같은 결정에 원본이 둘이 되면 반드시 어긋납니다.
| 어디에 | |
|---|---|
| 파트 간 합의의 원본 | P## · 공용 계약 static/ |
| 백엔드 도메인 내부 결정 | BD |
| 합의의 수용과 백엔드 구현 경계 | BD (원본은 링크) |
번호는 dev에 머지된 기록을 기준으로 다음 값을 씁니다. 미머지 브랜치가 파일명으로 선점한 번호는 예약이 아니며, 머지 순서대로 확정됩니다.
이 폴더는 결정 이력을 기록합니다. 폐기·대체된 결정도 삭제하지 않고 상태만 갱신합니다. 회고에서 "왜 그때 그렇게 정했고, 왜 바꿨는가"를 추적하기 위함입니다.
- 결정 유지 →
상태: Accepted - 새 결정으로 대체 → 문서 유지 +
상태: Superseded by BD-## - 철회 → 문서 유지 +
상태: Rejected(사유) - 삭제 → 하지 않음. 잘못 작성된 문서도 정정으로 처리
TEMPLATE.md를 복사해 시작합니다.
- **상태**: Accepted | Proposed | Rejected | Superseded by BD-##
- **날짜**: 결정한 날
- **관련**: PR·커밋·Jira 링크
본문은 맥락 → 선택지(트레이드오프) → 결정 → 결과 순서입니다.
문서는 결정하면서 함께 씁니다(CLAUDE.md 10번). 그러지 못하고 나중에 쓰게 되면 헤더에 한 줄을 덧붙여 그 사실을 드러냅니다. 이 줄이 없으면 결정할 때 쓴 문서입니다.
- **작성 시점**: 2026-07-27 — 결정 이후에 정리
이때 **날짜**는 여전히 결정한 날이며, 날짜가 추정이면 근거가 되는 커밋·PR을 맥락에 밝힙니다.
「결정」 절에서 왜 그렇게 정했는지를 아래 넷 중 하나로 분류합니다. 나중에 쓰는 문서만의 규칙이 아닙니다 — 오늘 내리는 결정도 기본값을 그대로 쓴 것이거나 외부가 정해준 것일 수 있고, 그 구분이 나중에 되돌릴 때 값을 합니다.
| 분류 | 쓰는 방식 |
|---|---|
| 능동적 선택 | 대안을 실제로 검토함 → 선택지 표를 정상 작성 |
| 기본값 수용 | 프레임워크·생성기 기본을 그대로 씀 → "바꿀 이유를 찾지 못했다"고 적음 |
| 제약으로 주어짐 | 조직 표준·공용 계약·외부 요건이 정함 → 제약을 명시하고 그 안에서 무엇을 골랐는지 씀 |
| 근거 소실 | "당시 판단 근거를 재구성할 수 없다"고 적고 재검토 트리거를 강하게 검 |
없는 이유를 지어내지 않습니다. 이 기록의 가치는 정확성에 있고, 그럴듯하게 꾸며낸 이유 하나가 나머지 전부를 믿을 수 없게 만듭니다.
목록 표를 두면 모든 브랜치가 같은 파일을 고치게 되어 PR끼리 충돌하고, 손으로 옮겨 적은 사본이라 실제로 어긋납니다(back#133, BD-45). 각 문서의 H1이 번호와 요약을, 헤더가 상태를 원본으로 갖고 있으므로 폴더에서 직접 읽습니다.
grep -h '^# B' docs/backend/decisions/BD-*.md | sort # 전체 목록
grep -H '^- \*\*상태\*\*' docs/backend/decisions/BD-*.md # 상태별로 훑기