98 lines
7.0 KiB
Markdown
98 lines
7.0 KiB
Markdown
---
|
|
title: Architecture Decision Records (ADR) — 공식 사이트
|
|
source_type: official-doc
|
|
url: https://adr.github.io/
|
|
archive_url:
|
|
status: raw
|
|
confidence: high
|
|
tags: [adr, governance, registry, decision-record, ca-skeleton, official-doc]
|
|
related_projects: [ca-skeleton-operational-contract]
|
|
related_branches: [feature-contract-registry-governance, feature-implementation-readiness-scorecard]
|
|
created: 2026-05-22
|
|
last_reviewed: 2026-05-27
|
|
---
|
|
|
|
# Architecture Decision Records (ADR) — 공식 사이트
|
|
|
|
> Layer: `raw/official-docs/` — adr.github.io 공식 사이트 발췌. registry governance/scorecard 의 "결정 사항" 섹션을 ADR 포맷으로 보완할지 평가용.
|
|
|
|
## Parent / 활용 branch (필수)
|
|
|
|
| Branch | 이 자료가 정당화하는 결정 |
|
|
|---|---|
|
|
| [[raw/branch-notes/feature-contract-registry-governance]] | ADR (Nygard/MADR) 가 registry 의 "결정 사항" 라인과 어떻게 매핑되는지 비교 근거 |
|
|
| [[raw/branch-notes/feature-implementation-readiness-scorecard]] | scorecard "결정 사항 누적" 모델과 ADR 의 1-decision-1-file 모델의 trade-off 비교 |
|
|
|
|
## 컨텍스트
|
|
|
|
`feature-contract-registry-governance`와 `feature-implementation-readiness-scorecard`는 **결정 사항**을 누적한다. ADR 포맷(Nygard 또는 MADR)이 본 skeleton의 "결정 사항(decisions)" 섹션과 어떻게 매핑되는지, registry 변경 절차의 단계 1–6에 ADR을 끼울 가치가 있는지 평가하려고 보관.
|
|
|
|
## 출처 / Source
|
|
|
|
- 원본 URL: https://adr.github.io/
|
|
- 아카이브 URL: (미수집)
|
|
- 저자/조직: ADR community (originally Michael Nygard, 2011)
|
|
- 발행일: 지속적으로 갱신
|
|
- 마지막 확인일: 2026-05-27
|
|
|
|
## 핵심 인용 / Key quotes (verbatim)
|
|
|
|
> [§What is an Architectural Decision] "An Architectural Decision (AD) is a justified design choice that addresses a functional or non-functional requirement that is architecturally significant."
|
|
|
|
> [§What is an ADR] "An Architectural Decision Record (ADR) captures a single AD and its rationale; Put it simply, ADR can help you understand the reasons for a chosen architectural decision, along with its trade-offs and consequences."
|
|
|
|
> [§History / popularization] "Documenting Architecture Decisions is the blog post from 2011 by Michael Nygard that popularized the concept."
|
|
|
|
## Claims Extracted / 추출된 주장
|
|
|
|
| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|
|
|---|---|---|---|---|---|
|
|
| REG-ADR-C1 | Architectural Decision (AD) 는 architecturally significant 한 functional/non-functional requirement 를 다루는 정당화된 design choice 이다 | [§What is an Architectural Decision] "An Architectural Decision (AD) is a justified design choice that addresses a functional or non-functional requirement that is architecturally significant." | `official-reference` | 결정 사항이 "AD" 로 분류되는 조건 정의 | 모든 결정이 AD 라는 뜻은 아님 — "architecturally significant" 판정 기준은 별도 |
|
|
| REG-ADR-C2 | ADR (Architectural Decision Record) 는 단일 AD 와 그 rationale 을 기록하며, 선택의 이유 / trade-offs / consequences 를 함께 포함한다 | [§What is an ADR] "An Architectural Decision Record (ADR) captures a single AD and its rationale; Put it simply, ADR can help you understand the reasons for a chosen architectural decision, along with its trade-offs and consequences." | `official-reference` | ADR 파일 1개당 결정 1개 모델 채택 평가 | 결정의 "재평가/철회" 처리가 같은 파일 수정인지 새 ADR 발행인지는 본 인용에 명시 없음 (Status 필드 별도) |
|
|
| REG-ADR-C3 | Michael Nygard 의 2011 블로그 글 "Documenting Architecture Decisions" 가 ADR 개념을 대중화시킨 출처이다 | [§History] "Documenting Architecture Decisions is the blog post from 2011 by Michael Nygard that popularized the concept." | `official-reference` | ADR 개념의 origin 식별 | 해당 글이 정의한 정확한 4-section 템플릿 (Status/Context/Decision/Consequences) 이 공식 표준임을 본 페이지가 직접 명시하지는 않음 — 본문은 Y-statement 등 다른 변형도 언급 |
|
|
|
|
### Strength 허용값 사용
|
|
|
|
- `official-reference` — adr.github.io 는 ADR 커뮤니티의 공식 reference 사이트 (단, 단일 벤더 제품 문서가 아니라 community-curated reference 이므로 `official-vendor-doc` 가 아닌 `official-reference` 로 분류)
|
|
|
|
## Usage Boundaries / 적용 경계
|
|
|
|
- **이 자료가 직접 증명하는 것**:
|
|
- `REG-ADR-C1`: AD 의 정의 (architecturally significant 한 design choice + 정당화)
|
|
- `REG-ADR-C2`: ADR 의 정의 (1 AD + rationale + trade-offs + consequences)
|
|
- `REG-ADR-C3`: Nygard 2011 blog 가 popularization origin
|
|
- **이 자료가 증명하지 않는 것**:
|
|
- Nygard 의 정확한 4-section (Status, Context, Decision, Consequences) 템플릿이 **공식 표준** 이라는 사실 — 본 페이지는 해당 4 섹션을 verbatim 으로 명시하지 않음. 4-section 은 Nygard 원문(2011) 또는 별도 도구 (adr-tools) 에 기재됨
|
|
- MADR (Markdown Any Decision Records) 의 구체적 schema
|
|
- ADR 을 registry 와 함께 쓸 때 변경 절차에 끼울 정확한 위치 (이는 본 wiki 의 자체 결정)
|
|
- **내 프로젝트에 적용하려면 추가 확인이 필요한 것**:
|
|
- Nygard 원문 (2011 blog) 의 verbatim 4-section 정의 확인 (보조 source 필요)
|
|
- MADR 공식 spec 비교 (별도 raw 자료)
|
|
- ca-tmpl 의 branch-note 가 이미 mini-ADR 역할을 하므로 ADR 별도 파일이 중복인지 비-중복인지 결정 (본 wiki 결정 영역, source 가 증명하지 않음)
|
|
|
|
## 메모 / Notes (내 프로젝트 해석)
|
|
|
|
> 본 섹션은 자료 직접 인용 아님. ca-tmpl 결정 컨텍스트 해석.
|
|
|
|
- 본 skeleton의 branch note는 사실상 **branch당 mini-ADR + Work Item Contract 표**. Status는 `status_label`, Context는 "목표/WHY", Decision은 "결정 사항", Consequences는 "테스트 계약 + Failure condition".
|
|
- 즉 ADR 별도 파일을 또 만드는 것은 중복. **결정 사항 라인이 곧 ADR id로 작동**할 수 있다 (예: `2026-05-22: registry row의 공통 필수 column은 ...`).
|
|
- ADR을 별도 도입한다면 registry **변경 절차의 step 1.5**로 "ADR row 작성"을 추가하는 형태가 자연스러움.
|
|
- 결론: ADR은 alternative source로 인용은 하되, ca-tmpl 결정으로 **별도 ADR 파일 생성은 out-of-scope** 권장.
|
|
|
|
## 관련 ca-tmpl branch / contract
|
|
|
|
- 적용 branch-note:
|
|
- [[raw/branch-notes/feature-contract-registry-governance]]
|
|
- canonical contract 섹션:
|
|
- [[raw/project-notes/ca-skeleton-operational-contract#21. Contract Registry]]
|
|
- 대안 그룹: **Group G-G — Skeleton Governance** (registry governance)
|
|
- 본 source의 위치: 대안 1 — ADR (Architectural Decision Record) 별도 파일
|
|
|
|
## Related / 관련
|
|
|
|
- 같은 주제 다른 official-doc: (미수집 — Nygard 2011 원문, MADR spec 후보)
|
|
- 인용하는 branch:
|
|
- [[raw/branch-notes/feature-contract-registry-governance]]
|
|
- [[raw/branch-notes/feature-implementation-readiness-scorecard]]
|
|
- 인용하는 wiki: (미작성)
|