ADR 도입 배경 + 결정 이유·대안·트레이드오프 구조 + 기준점으로 활용 경험
팀 프로젝트와 수업에서 아키텍처 결정 기록(ADR)을 처음 작성해봤습니다. ADR을 쓰기 시작한 계기는 왜 이 기술을 선택했는지 나중에 아무도 기억하지 못하는 상황을 경험한 뒤였습니다. 문서 작성에서 가장 중요하게 여긴 건 결정 내용보다 왜 이렇게 결정했는지, 어떤 대안을 왜 버렸는지를 남기는 것이었습니다. 배경·결정·대안·트레이드오프를 고정된 섹션 구조로 쓰니, 나중에 읽는 사람이 맥락을 빠르게 파악할 수 있게 됐습니다. 기술 검토서에서는 성능·비용·팀 역량·운영 부담을 비교 기준으로 명시해서 선택 이유가 문서에 남도록 했습니다. 한 번 쓴 문서가 이후 비슷한 결정 상황에서 기준점이 되는 경험을 하면서, 문서 작성이 그 순간만을 위한 게 아니라는 걸 느꼈습니다.
좋은 설계 문서는 무엇을 결정했냐보다 왜 그 결정을 했냐에 답하는 자리라고 생각합니다.