llm-wiki/raw/official-docs/registry-adr-official.md

title, source_type, url, archive_url, status, confidence, tags, related_projects, related_branches, created, last_reviewed

title	source_type	url	archive_url	status	confidence	tags	related_projects	related_branches	created	last_reviewed
Architecture Decision Records (ADR) — 공식 사이트	official-doc	https://adr.github.io/		raw	high	adr governance registry decision-record ca-skeleton official-doc	ca-skeleton-operational-contract	feature-contract-registry-governance feature-implementation-readiness-scorecard	2026-05-22	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: (미작성)