2nd/10_Wiki/Topics/아키텍처 결정 기록 (Architecture Decision Records, ADR).md

---
id: P-REINFORCE-WIKI-72DF8E05
category: Unified
confidence_score: 0.95
tags: ['아키텍처-결정-기록-(architecture-decision-records,-adr)', 'atam-(architecture-trade-offs-analysis-method)', 'iso-25010-quality-model', 'architecture-erosion-(아키텍처-침식)', 'technical-debt-(기술-부채)', 'process-methodology']
last_reinforced: 2026-05-02
---

# [[아키텍처 결정 기록 (Architecture Decision Records, ADR)]]

## 📌 Brief Summary
아키텍처 결정 기록(ADR)은 소프트웨어 아키텍처에 대한 결정 사항과 그 기술적 배경, 검토된 대안, 그리고 예상되는 결과 및 위험을 체계적으로 문서화한 기록입니다 [1, 2]. 이는 시간이 지나면서 아키텍처 설계의 맥락이 잊혀지는 것을 방지하고, 관련 이해관계자들을 위한 **단일 진실 공급원(Single source of truth)** 역할을 수행하여 시스템의 지속적인 진화를 지원합니다 [2, 3].

## 📖 Core Content
*   **ADR의 핵심 구성 요소**
    전형적인 ADR은 아키텍처 결정을 명확히 하기 위해 다음 항목들을 포함해야 합니다 [1, 2, 4].
    *   **Context (컨텍스트):** 결정이 내려지게 된 초기 상황과 기술적 배경
    *   **Decision (결정 사항):** 궁극적으로 어떤 선택을 내렸는지에 대한 명시
    *   **Reason (이유 및 근거):** 이 특정한 선택을 내리게 된 논리적 기반과 정당성
    *   **Alternatives (대안):** 거절된 다른 옵션들은 무엇이며, 왜 기각되었는지에 대한 설명
    *   **Risks and consequences (위험과 결과):** 이 결정이 단기 및 장기적으로 시스템에 미치는 영향과 내재된 리스크

*   **아키텍처 안티패턴(Anti-pattern) 방지**
    아키텍처 결정을 이메일 등으로 임시로 소통하거나 문서화하지 않으면, 결정 사항이 잊혀지거나 오해를 낳아 문제 해결 없이 반복적인 논의만 이어지는 안티패턴이 발생할 수 있습니다 [3]. ADR은 이러한 문제를 해결하기 위해 고안되었으며, 위키(wiki)와 같이 접근 가능한 저장소에 유지하여 조직 내 **단일 진실 공급원**을 확립하는 데 사용됩니다 [3].

*   **시스템 진화와 의사소통을 위한 전략적 자산**
    아키텍처 결정은 한 번 내려지면 변경 비용이 매우 높기 때문에 그 배경을 문서화하는 것이 필수적입니다 [2, 5]. 기록된 ADR은 새로운 팀원의 온보딩, 감사(Auditors), 이해관계자와의 소통, 그리고 미래의 시스템 개발 방향을 결정하는 데 가장 중요한 자산이 됩니다 [1, 2]. 시스템 부하, 사용자 행동, 팀의 기술 역량 등 프로젝트 맥락은 계속 변화하며, ADR은 이러한 변화의 궤적을 단계별로 기록하여 시스템이 변화에 적응하도록 돕습니다 [1].

## ⚖️ Trade-offs & Caveats
*   **지속적인 리뷰와 업데이트 책임:** ADR은 한 번 작성하고 끝나는 정적인 문서가 아닙니다. 사용량 증가, 새로운 통합 요구사항 발생, 인프라 운영 현실의 변화 등 **컨텍스트가 변경되면 아키텍처도 반드시 적응해야 하며 ADR 역시 함께 갱신**되어야 합니다 [4, 6]. 이를 방치하면 문서와 실제 아키텍처 간의 괴리(침식)가 발생할 수 있습니다.
*   **비즈니스 가치와의 정렬 필수:** ADR에 기록된 아키텍처 결정은 단순히 기술적 만족을 위한 것이 아니라, 비용, 사용자 만족도, 시장 출시 시간 등 **구체적인 비즈니스 가치에 대한 정당성을 포함**해야 합니다 [3]. 만약 명확한 비즈니스 가치를 제공하지 못하거나 이해관계자의 목표와 엇나간다면, 해당 결정은 재고되어야 합니다 [3].
*   **분석 마비(Analysis Paralysis)의 위험:** 꼼꼼한 문서화와 완벽한 결정을 내리려는 압박감 때문에 결정을 지연시키는 현상을 경계해야 합니다 [3]. 결정은 충분한 정보를 확보한 **'마지막 책임 순간(last responsible moment)'**에 이루어져야 하며, 개발 팀과의 긴밀한 협력을 통해 진행해야 합니다 [3].

## 🔗 Knowledge Connections

### Related Concepts

#### [아키텍처 평가 및 결정 (Architecture Evaluation & Decision)]
*   [[ATAM (Architecture Trade-offs Analysis Method)]]
    *   연결 이유: ADR 작성 전, 여러 아키텍처의 장단점(Trade-offs)을 시나리오 기반으로 분석하고 평가하는 핵심 방법론입니다 [7, 8].
    *   이 개념을 통해 더 깊게 이해할 수 있는 부분: ADR의 '대안(Alternatives)' 및 '위험(Risks)' 섹션에 채워 넣을 객관적인 지표와 상충 관계를 어떻게 도출하는지 원리를 이해할 수 있습니다.

*   [[ISO 25010 Quality Model]]
    *   연결 이유: 아키텍처 결정 시 기반이 되는 기능 적합성, 성능, 확장성 등의 비기능적 품질 속성 평가 기준을 제공합니다 [9, 10].
    *   이 개념을 통해 더 깊게 이해할 수 있는 부분: ADR의 '이유(Reason)' 항목을 작성할 때, 어떤 품질 기준을 근거로 아키텍처의 우위를 판단했는지 체계적인 근거를 마련할 수 있습니다.

#### [소프트웨어 생명주기 관리 (Software Lifecycle Management)]
*   [[Architecture Erosion (아키텍처 침식)]]
    *   연결 이유: 아키텍처 결정이 제대로 문서화(ADR)되지 않아 '지식 증발(knowledge vaporization)'이 일어날 때 발생하는 시스템 구조의 붕괴 현상입니다 [11].
    *   이 개념을 통해 더 깊게 이해할 수 있는 부분: 왜 ADR을 통한 철저한 기록이 장기적인 시스템의 수명과 유지보수 비용 절감에 직결되는지 그 위험성을 학습할 수 있습니다.

### Deeper Research Questions
*   애자일(Agile) 환경에서 "마지막 책임 순간(last responsible moment)"에 내리는 적시의 아키텍처 결정과 ADR 작성 사이의 속도와 문서화의 균형을 어떻게 맞출 수 있는가?
*   요구사항이나 트래픽 프로필이 크게 바뀌어 과거 ADR의 결정 사항이 무효화될 때, 이전 ADR을 어떤 버전 관리 기준으로 보관하고 갱신해야 하는가?
*   ATAM과 같은 평가 기법으로 도출된 식별된 위험(Sensitivity points)들을 ADR 문서 템플릿에 어떻게 정량적이고 구체적으로 매핑할 것인가?
*   ADR에 기술적 논거 외에도 비용 최적화, 시장 출시 속도 등 비즈니스 이해관계자를 위한 정당성(Justification)을 효과적으로 융합하는 실무 사례는 무엇인가?
*   초기 프로토타입(Prototype) 및 기술 검증(Proof of Concept)의 결과를 ADR 작성 과정에 편입시켜 결정을 검증(Validation)하는 가장 이상적인 타이밍은 언제인가?

### Practical Application Contexts
*   **Implementation:** 새로운 데이터베이스나 클라우드 제공자를 프로젝트에 도입할 때, 결정의 배경과 검토했다가 거절한 기술 스택을 ADR로 남겨 후임 개발자들의 중복 검토를 방지합니다.
*   **System Design:** 모놀리식에서 마이크로서비스(MSA)로 전환하는 등 거시적 아키텍처 변경을 기획할 때, 기술적 대안들과 트레이드오프 분석 결과를 문서로 기록하여 의사결정을 공식화합니다.
*   **Operation / Maintenance:** 운영 중 시스템 부하가 예상치를 초과하거나 팀 규모가 변경되었을 때, 기존 ADR을 리뷰하고 현재 컨텍스트에 맞게 아키텍처를 진화시킬지 결정하는 기준점으로 삼습니다.
*   **Learning Path:** 소프트웨어 아키텍트 지망생이 아키텍처 안티패턴(결정 지연, 이메일 기반의 휘발성 소통)을 학습하고, 이를 극복하기 위한 체계적인 문서화 및 지식 관리 프로세스를 실습하는 데 적용됩니다.
*   **My Project Relevance:** 현재 진행 중인 개인 혹은 팀 프로젝트의 위키(Wiki) 공간에 ADR 템플릿을 도입하여, 팀원들과 시스템 구조에 대한 단일 진실 공급원(SSOT)을 구축하는 기준으로 활용합니다.

### Adjacent Topics
*   [[Technical Debt (기술 부채)]]
    *   확장 방향: 아키텍처의 의도와 구현이 틀어지거나 문서화의 부재로 인해 발생하는 기술 부채의 원인과 이를 측정하고 리팩토링하는 과정을 조사합니다.
*   [[Architecture Decision Matrix (아키텍처 결정 매트릭스)]]
    *   확장 방향: 대안들을 객관적으로 비교하기 위해 확장성, 개발 노력, 유지보수성 등 동일한 기준으로 여러 아키텍처를 스코어링(scoring)하는 평가 도구의 활용법을 학습합니다.

---
*Last updated: 2026-05-02*