ARCHIVE
Deprecated
ADR
ADR 표준 템플릿

ADR 표준 템플릿

ADR 표준 템플릿 v2

1. 기본 정보

  • ADR ID:
  • 제목:
  • 상태: (Proposed | Accepted | Superseded | Deprecated)
  • 작성일:
  • 작성자:
  • 관련 ADR:
  • Supersedes: (없으면 N/A)
  • Superseded By: (없으면 N/A)

2. 배경 (Context)

  • 이 결정을 해야 했던 상황
  • 해결하려는 문제
  • 당시의 제약 조건
  • 사업/기술/운영 맥락

핵심은 “왜 이 시점에 이 결정을 했는가”를 설명하는 것이다.

3. 결정 (Decision)

  • 실제로 채택한 선택을 단정형으로 서술
  • 적용 시작 시점 (예: 배포 버전/날짜)
  • 적용 범위 (In Scope)
  • 비적용 범위 (Out of Scope)

모호한 표현 금지
예: “~을 고려한다” -> 금지
예: “~을 채택한다” -> 사용

4. 경계 및 책임 (Boundaries)

  • 시스템/팀 경계: 누가 무엇을 책임지는가
  • 데이터 경계: 어떤 데이터만 다루는가
  • 비즈니스 경계: 어떤 정책은 다른 문서(예: Product Policy)에서 관리하는가

중복 방지를 위해 경계 밖 항목은 이 ADR에서 새로 정의하지 않는다.

5. 단일 원천(SoT) 참조

  • 상태 모델 SoT:
  • 수량/동시성 SoT:
  • 결제 검증 SoT:
  • UX 표현 SoT:
  • 운영/플랜 정책 SoT:

복수 문서가 같은 규칙을 다루는 경우, 이 섹션에 원천 문서를 명시한다.

6. 대안 (Alternatives Considered)

각 대안에 대해:

대안 A

  • 설명
  • 장점
  • 단점
  • 미채택 이유

최소 2개 이상 기록하는 것을 원칙으로 한다.

7. 결과 (Consequences)

긍정적 결과

  • 구조적 장점
  • 운영상 이점
  • 단기 효과

부정적 결과

  • 제약
  • 비용
  • 향후 리스크

ADR은 트레이드오프 기록이다.

8. 영향 범위 (Impact)

  • 기술 구조에 미치는 영향
  • UX에 미치는 영향
  • 운영 정책에 미치는 영향
  • 향후 확장 시 제약

9. 검증 및 운영 확인 (Validation)

  • 테스트/검증 방식 (예: 시나리오, 모니터링 항목)
  • 실패 시 롤백/완화 전략
  • 관찰할 핵심 지표(KPI/SLI)

10. 재검토 조건 (Revisit Conditions)

이 결정은 언제 다시 검토할 것인가?

예:

  • DAU가 일정 수준 이상
  • 매출이 일정 규모 도달
  • 특정 KPI 악화
  • 외부 의존성(PG/API/법규) 변경

이 항목이 없으면 ADR은 영구 고정이 된다.

ADR 작성 규칙

  1. 한 ADR은 하나의 결정만 다룬다.
  2. 1~2페이지 내에서 핵심만 기록한다.
  3. 추상적 철학이 아니라 실행 가능한 결정만 기록한다.
  4. 변경되면 Superseded로 남기고 새 ADR을 작성한다.
  5. 감정/당위 표현 금지 (“당연히”, “반드시” 등).
  6. 경계 밖 항목은 SoT 문서를 링크하고 중복 정의하지 않는다.

ADR 상태 정의

  • Proposed: 논의 중
  • Accepted: 채택됨
  • Superseded: 다른 ADR로 대체됨
  • Deprecated: 더 이상 의미 없음
Buy me a coffee Buy me a coffee