기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
ADR 프로세스
아키텍처 결정 레코드(ADR)는 팀이 구축하려는 소프트웨어 아키텍처의 중요한 측면에 대해 내리는 선택을 설명하는 문서입니다. 각 ADR은 아키텍처 결정, 컨텍스트 및 결과를 설명합니다. ADR에는 상태가 있으므로 수명 주기를 따릅니다. ADR의 예는 부록을 참조하세요.
ADR 프로세스는 아키텍처 결정 레코드 모음을 출력합니다. 이 모은은 결정 로그를 생성합니다. 결정 로그는 프로젝트 컨텍스트와 상세한 구현 및 설계 정보를 제공합니다. 프로젝트 멤버는 각 ADR의 헤드라인을 훑어보면서 프로젝트 컨텍스트의 개요를 파악합니다. 또한 ADR을 읽고 프로젝트 구현 및 설계 선택을 심도있게 살펴봅니다.
팀이 ADR을 수락하면 ADR은 변경할 수 없게 됩니다. 새로운 인사이트를 얻기 위해 다른 결정을 내려야 하는 경우 팀은 새로운 ADR을 제안합니다. 팀에서 새 ADR을 수락하면 이전 ADR이 대체됩니다.
ADR 프로세스 범위
프로젝트 멤버는 다음을 포함하여 소프트웨어 프로젝트 또는 제품에 영향을 미치는 모든 구조적으로 중요한 결정에 대해 ADR을 작성해야 합니다(Richards and Ford 2020).
-
구조(예: 마이크로서비스와 같은 패턴)
-
비기능적 요구 사항(보안, 고가용성, 내결함성)
-
종속성(구성 요소 결합)
-
인터페이스(API 및 게시된 계약)
-
구성 기법(라이브러리, 프레임워크, 도구, 프로세스)
기능적 요구 사항과 비기능적 요구 사항은 ADR 프로세스의 가장 일반적인 입력입니다.
ADR 콘텐츠
팀이 ADR의 필요성을 확인하면 팀원은 프로젝트 전체 템플릿을 기반으로 ADR을 작성하기 시작합니다. 예제 템플릿은 ADR GitHub 조직
ADR 채택 프로세스
모든 팀원이 ADR을 생성할 수 있지만 팀은 ADR에 대한 소유권 정의를 설정해야 합니다. ADR 소유자인 각 작성자는 ADR 콘텐츠를 적극적으로 유지 관리하고 전달해야 합니다. 이 소유권을 명확히 하기 위해 이 가이드에서는 다음 섹션에서 ADR 작성자를 ADR 소유자로 지칭합니다. 다른 팀원들은 언제든지 ADR에 기여할 수 있습니다. 팀이 ADR을 수락하기 전에 ADR 내용이 변경되는 경우 소유자가 이러한 변경을 승인해야 합니다.
다음 다이어그램에서는 ADR 생성, 소유권 및 채택 프로세스를 보여줍니다.
팀이 아키텍처 결정과 해당 소유자를 식별한 후 ADR 소유자는 프로세스 시작 시 제안됨 상태의 ADR을 제공합니다. 제안됨 상태의 ADR은 검토할 준비가 되었습니다.
그러면 ADR 소유자가 ADR에 대한 검토 프로세스를 시작합니다. ADR 검토 프로세스의 목표는 팀에서 ADR을 수락할지, 재작업이 필요하다고 판단할지 또는 ADR을 거부할지를 결정하는 것입니다. 소유자를 포함한 프로젝트 팀이 ADR을 검토합니다. 검토 회의는 ADR을 읽을 수 있는 전용 시간대를 정하고 시작해야 합니다. 평균적으로 10~15분이면 충분합니다. 이 기간 동안 각 팀원은 문서를 읽고 설명과 질문을 추가하여 명확하지 않은 주제에 표시를 합니다. 검토 단계가 끝나면 ADR 소유자가 각 의견을 읽고 팀과 논의합니다.
팀이 ADR 개선을 위한 조치 사항을 찾더라도 ADR은 계속 제안됨 상태입니다. ADR 소유자가 작업을 공식화하고 팀과 협력하여 각 작업에 담당자를 추가합니다. 각 팀원은 조치 사항에 기여하고 해결할 수 있습니다. 검토 프로세스 일정을 변경하는 것은 ADR 소유자의 책임입니다.
팀에서 ADR을 거부하기로 결정할 수도 있습니다. 이 경우 ADR 소유자는 향후 동일한 주제에 대한 논의가 진행되지 않도록 거부 사유를 추가합니다. 소유자가 ADR 상태를 거부됨으로 변경합니다.
팀이 ADR을 승인하면 소유자가 타임스탬프, 버전, 이해관계자 목록을 추가합니다. 그러면 소유자가 상태를 수락됨으로 업데이트합니다.
ADR과 ADR이 생성하는 결정 로그는 팀이 내린 결정을 나타내며 모든 결정의 기록을 제공합니다. 팀은 가능한 경우 코드 및 아키텍처 검토 중 ADR을 참조로 사용합니다. 코드 검토, 설계 작업 및 구현 작업을 수행하는 것 외에도 팀원은 ADR을 참조하여 제품에 대한 전략적 결정을 내려야 합니다.
다음 다이어그램에서는 ADR을 적용하여 소프트웨어 구성 요소의 변경 사항이 합의된 결정을 준수하는지 검증하는 프로세스를 보여줍니다.
모범 사례에 따르면 각 소프트웨어 변경은 동료 검토를 거쳐야 하며 최소한 한 번의 승인이 필요합니다. 코드 검토 중 코드 검토자는 하나 이상의 ADR을 위반하는 변경 사항을 발견할 수 있습니다. 이 경우 검토자는 코드 변경 작성자에게 코드 업데이트를 요청하고 ADR 링크를 공유합니다. 작성자가 코드를 업데이트하면 동료 검토자의 승인을 받고 기본 코드 베이스에 병합됩니다.
ADR 검토 프로세스
팀이 ADR을 수락하거나 거부한 후에 ADR을 변경할 수 없는 문서로 처리해야 합니다. 기존 ADR을 변경하려면 새 ADR을 생성하고, 새 ADR에 대한 검토 프로세스를 수립하고, ADR을 승인해야 합니다. 팀이 새 ADR을 승인하면 소유자는 이전 ADR의 상태를 대체됨으로 변경해야 합니다. 다음 다이어그램에서 업데이트 프로세스를 보여줍니다.
