FE ChapterADR 1: ADR 작성의 필요성
Architecture Decision Record (ADR) 도입에 대한 결정
Status
Accepted
Context
현재 프로젝트에서는 중요한 아키텍처 결정들이 팀 내에서 구두로만 공유되거나, 명확히 기록되지 않고 있어요. 이는 시간이 지나면서 팀원 간의 이해 차이를 초래하거나, 새로운 팀원이 합류했을 때 혼란을 야기할 가능성이 있어요. 또한, 기존 결정을 재검토하거나 수정할 때 과거의 결정 배경을 이해하기 어려운 문제가 발생하고 있어요.
Decision
FE팀에서 주요 아키텍처 결정을 기록하는 방안으로 Architecture Decision Record (ADR) 를 도입하는 것을 제안합니다. 이를 통해 각 결정의 배경, 이유, 그리고 그 결과를 체계적으로 정리할 수 있을 거예요.
ADR은 다음과 같은 방식으로 관리하는 것을 제안해요:
- 프로젝트의
docs/adr폴더 하위에 ADR을 작성해요. - 각 ADR은 고유 번호와 명확한 제목을 가져야 해요.
- Markdown 형식으로 작성해서 접근성과 가독성을 높이세요.
- 별도의 CHANGELOG를 작성하지 않아요. Git의 커밋 히스토리가 변경 로그 역할을 하기 때문이에요.
Consequences
이 제안이 수락되는 경우 다음과 같은 결과가 예상돼요:
- 의사소통 향상: 모든 팀원이 아키텍처 결정을 쉽게 이해할 수 있어 협업이 원활해질 거예요.
- 온보딩 효율화: 새로운 팀원이 과거 결정을 빠르게 파악하고 프로젝트에 적응할 수 있을 거예요.
- 투명성 강화: 모든 결정을 체계적으로 문서화하여 추적 가능성을 높일 수 있어요.
- 시간 소요: 초기 도입과 관리에는 일정한 시간과 노력이 필요할 거예요.
- 변화 관리: 팀 내에서 ADR 작성 문화를 정착시키기 위한 추가적인 노력이 요구될 수 있어요.