중요한 기술적 결정은 누군가의 머릿속에서 내려졌다가 잊히는 것이 아니라, 신중하고, 투명하며, 기록되어야 합니다. 좋은 프로세스는 트레이드오프를 드러내고, buy-in을 쌓으며, 미래의 엔지니어가 무엇뿐 아니라 왜인지 이해하도록 흔적을 남깁니다.
의사결정 프레임워크
text
1. 문제와 제약을 FRAME하라(비용, 시간, 팀 역량, 규모)
2. 현실적인 옵션을 LIST하라 — 보통 2-4개, "아무것도 하지 않기" 포함
3. 각 옵션을 제약과 트레이드오프에 대해 EVALUATE하라
4. DECIDE하고, 그 근거를 명시적으로 밝혀라
5. RECORD하고(ADR) 전달하라
6. 가정이 바뀌면 REVISIT하라
ADR로 기록하라
Architecture Decision Record는 짧고 오래 가는 메모입니다.
markdown
주 데이터스토어가 필요하다. 팀은 SQL을 안다; 데이터는 관계형이다; 규모는 중간이다.
PostgreSQL을 사용한다.
강한 일관성, 팀 친숙도, 풍부한 쿼리.
나중에 수직 확장 한계; 쓰기량이 10배가 되면 재검토.
DynamoDB(기각: 관계형 데이터, 팀이 익숙하지 않음).
