결정을 기록하지 않으면 같은 논의가 반복된다 — 결정 기록의 최소 형식

반복되는 논의의 정체

몇 달 전에 정한 것을 다시 논의하게 되는 상황이 있다. 대개 이렇게 진행된다.

"이거 왜 이렇게 돼 있죠?"
"예전에 정한 건데... 이유가 뭐였더라"
"다시 검토해봅시다"

결론은 남아 있는데 근거가 사라져서 재논의가 시작된다. 그리고 대개 같은 결론에 도달한다. 그 사이의 시간이 순수한 손실이다.

회의록과 다른 것

회의록은 오간 이야기를 순서대로 적는다. 나중에 결론을 찾으려면 전체를 읽어야 하고, 근거는 대화 속에 흩어져 있다.

결정 기록은 별개 문서다. 하나의 결정에 하나의 기록이고, 검색 가능한 제목을 갖는다.

최소 형식 다섯 항목

```markdown

결정: 배포를 주 2회에서 주 1회로

상태

확정 (2026-08-28)

배경

주 2회 배포에서 화요일 배포 후 장애 대응이 목요일 배포 준비와 겹침.

최근 3개월 중 4회 발생.

결정

목요일 주 1회로 통합. 긴급 수정은 핫픽스 절차로 별도 처리.

고려한 대안

• 화/목 유지 + 대응 인원 증원: 인원 여유 없음
• 주 3회로 늘려 배포 단위 축소: 준비 비용이 선형 증가

재검토 조건

배포 대기 큐가 2주 이상 밀리거나, 핫픽스가 월 3회를 넘으면

```

'재검토 조건'이 핵심 항목이다. 이것이 있으면 "지금 이 결정을 뒤집어야 하는가"를 감이 아니라 기준으로 판단할 수 있다.

무엇을 기록할 것인가

전부 기록하면 부담이 되어 지속되지 않는다. 기준:

| 기록할 것 | 안 해도 되는 것 |

|---|---|

| 되돌리기 비용이 큰 것 | 쉽게 바꿀 수 있는 것 |

| 여러 팀에 영향 | 한 사람 안에서 끝나는 것 |

| 나중에 "왜?"가 나올 것 | 자명한 것 |

| 대안이 있었던 것 | 선택지가 하나였던 것 |

대략 한 달에 2~5건 정도면 적정 수준이다.

어디에 둘 것인가

찾을 수 있는 곳이어야 한다. 흔한 방식:

• 저장소 안 docs/decisions/ (코드와 함께 버전 관리됨)
• 위키의 결정 목록 페이지
• 이슈 트래커의 특정 라벨

중요한 것은 한 곳으로 모으는 것이다. 여기저기 흩어지면 없는 것과 같다.

뒤집을 때

기존 결정을 바꿀 때 이전 기록을 지우지 않는다. 새 기록을 만들고 관계를 명시한다.

```markdown

결정: 배포를 다시 주 2회로

상태

확정 (2026-11-15) — [배포 주 1회 통합] 결정을 대체

배경

재검토 조건 중 "배포 대기 큐 2주 이상"에 도달.

...

```

이렇게 하면 결정의 변천사가 남는다. 나중에 "왜 이렇게 자주 바뀌었지"를 볼 때 근거가 있다.

시작하는 방법

과거 결정을 소급해서 다 적을 필요는 없다. 다음 결정부터 시작하고, 재논의가 발생한 항목만 그때 기록한다.

몇 달 지나면 자주 논의되는 주제부터 자연히 기록이 쌓인다.

최종 수정 2026-08-28