중요한 기술적 결정을 어떻게 내리고 문서화합니까?

Question

Accepted Answer

중요한 기술적 결정은 누군가의 머릿속에서 내려졌다가 잊히는 것이 아니라, **신중하고, 투명하며, 기록되어야** 합니다. 좋은 프로세스는 트레이드오프를 드러내고, buy-in을 쌓으며, 미래의 엔지니어가 *무엇*뿐 아니라 *왜*인지 이해하도록 흔적을 남깁니다.

## 의사결정 프레임워크

```text
1. 문제와 제약을 FRAME하라(비용, 시간, 팀 역량, 규모)
2. 현실적인 옵션을 LIST하라 — 보통 2-4개, "아무것도 하지 않기" 포함
3. 각 옵션을 제약과 트레이드오프에 대해 EVALUATE하라
4. DECIDE하고, 그 근거를 명시적으로 밝혀라
5. RECORD하고(ADR) 전달하라
6. 가정이 바뀌면 REVISIT하라
```

## ADR로 기록하라

**Architecture Decision Record**는 짧고 오래 가는 메모입니다.

```markdown
# ADR 014: 새 서비스에 PostgreSQL 사용

## Status: Accepted

## Context
주 데이터스토어가 필요하다. 팀은 SQL을 안다; 데이터는 관계형이다; 규모는 중간이다.

## Decision
PostgreSQL을 사용한다.

## Consequences
+ 강한 일관성, 팀 친숙도, 풍부한 쿼리.
- 나중에 수직 확장 한계; 쓰기량이 10배가 되면 재검토.

## Alternatives considered
DynamoDB(기각: 관계형 데이터, 팀이 익숙하지 않음).
```

## 관리해야 할 트레이드오프

모든 것을 문서화하는 것은 오버헤드이고, 아무것도 문서화하지 않으면 조직적 기억을 잃습니다. ADR은 **되돌리기 비싼** 결정이나 미래의 엔지니어가 의문을 가질 결정에 한정하십시오.

## 왜 중요한가

문서화되지 않은 결정은 끝없이 재논쟁됩니다. 새 엔지니어마다 "왜 이걸 골랐지?"를 다시 묻습니다.

근거를 적는 것은 또한 명료함을 강제합니다. 종이에 정당화할 수 없다면, 아마 충분히 생각하지 않은 것입니다.