Architecture Decision RecordAWS 아키텍처 의사결정 기록 프로세스
아키텍처 의사결정 기록(architectural decision record, ADR)은 팀이 구축하려고 계획 중인 소프트웨어 아키텍처의 중요한 측면에 대해 내리는 선택을 설명하는 문서입니다. 각 ADR은 아키텍처 결정, 그 맥락, 그리고 그 결과를 설명합니다. ADR에는 상태가 있으므로 수명 주기를 따릅니다. ADR의 예는 부록을 참조하십시오.
ADR 프로세스는 아키텍처 의사결정 기록의 모음을 산출합니다. 이 모음이 결정 로그를 이룹니다. 결정 로그는 프로젝트 맥락과 더불어 상세한 구현 및 설계 정보를 제공합니다. 프로젝트 구성원은 각 ADR의 제목을 훑어보고 프로젝트 맥락의 개요를 파악합니다. 그리고 ADR을 읽으며 프로젝트 구현과 설계 선택을 깊이 이해합니다.
팀이 ADR을 수락하면 그 ADR은 불변이 됩니다. 새로운 통찰로 인해 다른 결정이 필요하면 팀은 새 ADR을 제안합니다. 팀이 새 ADR을 수락하면 그것이 이전 ADR을 대체합니다.
ADR 프로세스의 범위
프로젝트 구성원은 소프트웨어 프로젝트나 제품에 영향을 미치는 아키텍처상 중요한 모든 결정에 대해 ADR을 작성해야 하며, 여기에는 다음이 포함됩니다(Richards and Ford 2020):
구조(예: 마이크로서비스와 같은 패턴)
비기능 요구사항(보안, 고가용성, 내결함성)
의존성(컴포넌트의 결합)
인터페이스(API 및 공개된 계약)
구축 기법(라이브러리, 프레임워크, 도구, 프로세스)
기능 요구사항과 비기능 요구사항은 ADR 프로세스에 가장 흔히 입력되는 정보입니다.
ADR의 내용
팀이 ADR의 필요성을 확인하면 팀 구성원이 프로젝트 전반의 템플릿을 바탕으로 ADR 작성을 시작합니다. (템플릿 예시는 GitHub의 ADR 조직을 참조하십시오.) 템플릿은 ADR 작성을 단순화하고 ADR이 모든 관련 정보를 담도록 보장합니다. 최소한 각 ADR은 결정의 맥락, 결정 자체, 그리고 프로젝트와 그 산출물에 대한 결정의 결과를 정의해야 합니다. (이러한 섹션의 예는 부록을 참조하십시오.) ADR 구조의 가장 강력한 측면 중 하나는 팀이 어떻게 구현했는지가 아니라 결정의 이유에 초점을 둔다는 점입니다. 팀이 왜 그 결정을 내렸는지 이해하면 다른 팀 구성원이 그 결정을 받아들이기 쉬워지고, 의사결정 과정에 참여하지 않았던 다른 아키텍트가 나중에 그 결정을 뒤집는 일을 막을 수 있습니다.
ADR 도입 프로세스
모든 팀 구성원이 ADR을 작성할 수 있지만 팀은 ADR의 소유권 정의를 정해야 합니다. ADR의 소유자인 각 작성자는 ADR 내용을 적극적으로 유지 관리하고 전달해야 합니다. 이 소유권을 분명히 하기 위해 이 가이드는 이후 섹션에서 ADR 작성자를 ADR 소유자라고 부릅니다. 다른 팀 구성원은 언제든지 ADR에 기여할 수 있습니다. 팀이 ADR을 수락하기 전에 ADR의 내용이 바뀌면 소유자가 이러한 변경을 승인해야 합니다.
팀이 아키텍처 결정과 그 소유자를 확인하고 나면 ADR 소유자는 프로세스 초반에 Proposed(제안됨) 상태의 ADR을 제시합니다. Proposed 상태의 ADR은 검토할 준비가 된 것입니다.
그런 다음 ADR 소유자는 해당 ADR의 검토 프로세스를 시작합니다. ADR 검토 프로세스의 목표는 팀이 ADR을 수락할지, 재작업이 필요하다고 판단할지, 아니면 ADR을 거부할지를 결정하는 것입니다. 소유자를 포함한 프로젝트 팀이 ADR을 검토합니다. 검토 회의는 ADR을 읽기 위한 전용 시간으로 시작해야 합니다. 평균적으로 10~15분이면 충분합니다. 이 시간 동안 각 팀 구성원은 문서를 읽고 불분명한 주제를 표시하기 위해 의견과 질문을 추가합니다. 검토 단계가 끝나면 ADR 소유자가 각 의견을 읽고 팀과 논의합니다.
팀이 ADR을 개선하기 위한 조치 항목을 찾으면 ADR의 상태는 Proposed로 유지됩니다. ADR 소유자는 조치를 정리하고 팀과 협력하여 각 조치에 담당자를 지정합니다. 각 팀 구성원은 조치 항목에 기여하고 이를 해결할 수 있습니다. 검토 프로세스의 일정을 다시 잡는 것은 ADR 소유자의 책임입니다.
팀은 ADR을 거부하기로 결정할 수도 있습니다. 이 경우 ADR 소유자는 같은 주제에 대한 향후 논의를 막기 위해 거부 사유를 추가합니다. 소유자는 ADR 상태를 Rejected(거부됨)로 변경합니다.
팀이 ADR을 승인하면 소유자는 타임스탬프, 버전, 이해관계자 목록을 추가합니다. 그런 다음 소유자는 상태를 Accepted(수락됨)로 갱신합니다.
ADR과 이를 통해 만들어지는 결정 로그는 팀이 내린 결정을 나타내며 모든 결정의 이력을 제공합니다. 팀은 가능한 경우 코드 및 아키텍처 검토 시 ADR을 참조로 사용합니다. 코드 검토, 설계 작업, 구현 작업을 수행하는 것 외에도 팀 구성원은 제품의 전략적 결정에 대해 ADR을 참고해야 합니다.
좋은 실천 방법으로서 모든 소프트웨어 변경은 동료 검토를 거쳐야 하며 최소 한 번의 승인이 필요합니다. 코드 검토 중에 검토자가 하나 이상의 ADR을 위반하는 변경을 발견할 수 있습니다. 이 경우 검토자는 코드 변경 작성자에게 코드를 수정하도록 요청하고 ADR 링크를 공유합니다. 작성자가 코드를 수정하면 동료 검토자의 승인을 받고 메인 코드베이스에 병합됩니다.
ADR 검토 프로세스
팀은 ADR을 수락하거나 거부한 후에는 불변 문서로 취급해야 합니다. 기존 ADR을 변경하려면 새 ADR을 작성하고, 새 ADR의 검토 프로세스를 수립하고, ADR을 승인해야 합니다. 팀이 새 ADR을 승인하면 소유자는 이전 ADR의 상태를 Superseded(대체됨)로 변경해야 합니다.