애자일 프로젝트에서는 모든 아키텍처 결정을 시작할 때 한꺼번에 내리지 않으므로, 결정의 이유와 결과를 작고 갱신하기 쉬운 기록으로 남기는 방식이 제안됐다. 이 글은 이런 기록을 아키텍처 결정 기록(ADR)이라 부르며, 프로젝트에 새로 합류한 사람이 과거 결정을 맹목적으로 받아들이거나 이유를 모른 채 뒤집는 일을 피하는 데 목적을 둔다.
ADR은 구조, 비기능적 특성, 의존성, 인터페이스 또는 구현 기법에 영향을 주는 중요한 결정 하나를 기록한다. 프로젝트 저장소의 doc/arch/adr-NNN.md에 Markdown이나 Textile 같은 가벼운 형식으로 보관하고, 번호는 순서대로 부여하며 재사용하지 않는다. 결정이 바뀌면 이전 기록을 삭제하지 않고 대체됐다고 표시한다.
각 기록에는 짧은 제목, 결정에 영향을 준 기술적·정치적·사회적·프로젝트별 맥락, 그에 대한 대응인 결정, 제안 또는 승인 등의 상태, 긍정적·부정적·중립적 결과를 담는다. 문서는 한두 페이지를 목표로 하며, 미래의 개발자와 대화하듯 완전한 문장과 문단으로 쓴다. 한 ADR의 결과는 이후 ADR의 맥락이 될 수 있다.
글에서 소개한 경험으로는 몇 개 프로젝트에서 8월 초부터 ADR을 사용했고, 6~10명의 개발자가 프로젝트를 오가며 기록을 읽은 뒤 제공된 맥락을 긍정적으로 평가했다. 장기 계획을 남기면 현재 시스템을 안정화하는 작업이 이후의 대규모 재설계를 어렵게 만들지 않는 데도 도움이 됐다고 전한다. 버전 관리 시스템에 익숙하지 않은 프로젝트 관리자나 고객 관계자가 기록을 보기 어려울 수 있지만, 해당 프로젝트들은 대부분 GitHub 비공개 저장소를 사용했고 최신 기록 링크를 공유할 수 있었다. GitHub의 Markdown 처리로 위키 페이지와 비슷하게 읽을 수 있었다는 설명이다.
댓글 (0)
로그인하면 이 기사에 내 생각을 남길 수 있어요