의사결정 시스템 — 결정이 기록되고 검증되는 법

조직의 아키텍처는 결정의 축적이다. 그런데 결정이 회의록이나 기억 속에만 살면, 세 달 뒤에는 "왜 이렇게 했지?"가 반복된다. 이 문서는 워크스페이스가 결정을 일급 자산으로 다루는 장치 — Decision Record, 스펙 레지스트리, 거버넌스 백로그, 반영 검증 — 를 다룬다.

출처: ai-workspace-standards ADR-0061 Decision Record Standard · ADR-0055 Spec Registry Enforcement · ADR-0059 Governance Reflection Validators · docs/designs/2026-08-16-governance-backlog-design.md · scripts/validate-decisions.ts · scripts/ticket.ts

개요 — 결정도 자산이다

코드는 리뷰받고 테스트를 거치지만, 결정은 그렇지 않은 경우가 많다. "이 스킬은 실험적 관계로만 둔다", "이 variant는 승격 보류다" 같은 판단이 대화와 기억에만 있으면 조직은 같은 논쟁을 반복한다. 워크스페이스의 답은 결정을 파일로 쓰고, 체인으로 근거를 묶고, 기계로 검증한다는 것이다. 참고 C의 그래프가 결정 기록을 노드로 품는 이유도 이 때문이다 — 관계와 근거가 한 지도에 놓여야 탐색이 된다.

Decision Record의 구조

Decision Record는 docs/decisions/DEC-YYYYMMDD-NN.md 파일로, Agent → Skill → Knowledge → Evidence → Rule → Decision의 체인을 닫는 문서다. 필수 프론트매터는 id, date, agent, decision, alternatives, status이고, 선택 배열로 evidence_refs, knowledge_refs, rules_applied, skills_used가 있다.

• 증거 장부 — docs/evidence/ledger.md. (주장, 출처, URL/참조, 검증 방법, 상태)의 행을 가지며 행 ID는 EV-YYYYMMDD-NN 형식. 결정 기록의 evidence_refs는 이 장부의 행 ID만 가리킬 수 있다
• 게이트 시점 기록 — PM 에이전트는 게이트 순간의 결정(스페셜리스트 선정, 설계 승인 등)에 대해 배포가 계속되기 전에 기록을 남겨야 한다
• supersession-only 변경 모델 — 결정 기록은 지우지 않는다. 뒤집힌 결정은 새 기록이 옛 기록을 계승(supersede)한다. "결정의 역사"는 덧씌워지는 게 아니라 연결된다

validate-decisions.ts의 7가지 검사

scripts/validate-decisions.ts는 모든 DEC-*.md에 대해 다음을 검사한다.

1. 프론트매터 존재 여부
2. 여섯 개 필수 필드 완비
3. id와 파일명 접미 일치
4. status 어휘 (proposed | accepted | superseded)
5. evidence_refs가 장부 행 ID의 부분집합인지
6. knowledge_refs가 실제 존재하는 파일인지
7. rules_applied 형식(<PREFIX>-R<N>)과 skills_used의 실제 스킬 해결 가능 여부

이 검증은 fail-closed다 — error 수준 문제가 하나라도 있으면 exit 1. "경고만 뜨는 소프트 검사"와 달리, 결정 기록이 깨진 채로는 동기화가 진행되지 않는다.

참고로 2026-09부터 governed 등급의 variant 템플릿에는 결정 게이트(decisions/gates.yaml)가 도입됐다. 게이트는 "어느 지점에서 어떤 판정을 통과해야 하는가"라는 규칙 선언이고, 결정 기록은 실제 내려진 판정의 기록이다 — 게이트에서 나온 판정이 record_kind: DEC로 결정 기록에 남는다. 자세한 내용은 13장 · Domain Operating Model 참조.

스펙 레지스트리와 E1–E5 면제

결정의 앞단에는 설계(spec)가 있다. ADR-0055의 스펙 레지스트리(docs/specs/registry.json)는 설계 문서를 id·제목·파일·상태(proposed | approved | implemented)·최종 갱신일로 추적한다.

핵심은 스펙 관련성 게이트다. 코드 변경이 있는데 그 변경과 관련된 스펙 활동(레지스트리 건드림, 7일 이내 갱신된 approved/implemented 스펙)이 없으면, 감사가 실패한다. "코드는 바꿨는데 설계 기록은 얼어 있다"는 상태를 구조적으로 잡아내는 장치다.

물론 모든 변경에 설계 문서를 요구하면 과하다. 그래서 면제 코드가 다섯 개뿐으로 제한된다.

임의 면제는 금지고, 존재하지 않는 면제 코드를 쓰는 것 자체가 하드 실패다. 면제의 남용은 거버넌스 위반이다.

거버넌스 백로그

모든 결정이 지금 내려져야 하는 것은 아니다. "언젠가 판단할 필요가 있는 것"은 거버넌스 백로그 티켓으로 미뤄진다. 서비스 티켓(7장)이 일회성 작업 요청이라면, 거버넌스 백로그 티켓은 git에 추적되는 미래의 결정이다.

• scripts/ticket.ts로 관리되며 tickets/governance/에 git 추적 파일로 저장
• kind: manual 티켓에 not_before 날짜를 달면, 그 날짜가 지나기 전엔 list --ready --kind manual에 나오지 않는다 — 숙성(soak) 예약
• 상태 기계는 backlog → waiting → review → done
• 세션 시작이나 주간 점검 때 준비된 티켓이 표면화되면, PM은 순수 판단은 스스로 리뷰→완료 처리하고, 구현이 필요한 건 정규 PM 게이트웨이로 배포한다

"지금 결정하지 않겠다"는 것 자체를 기록으로 남기는 장치다. 망각이 아니라 예약이다.

거버넌스 반영 검증

ADR-0059가 태어난 계기는 구체적 사고였다 — 어떤 ADR이 거버넌스 문서 어디에도 참조되지 않은 채 승인돼, 실제로 아무도 따르지 않게 된 것. scripts/verify-adr-governance.ts는 두 가지를 검출한다.

• 연결 없는 ADR — 기준일(2026-08-23) 이후 승인됐는데 CONSTITUTION·docs/constitution/·docs/governance/ 어디에도 언급이 없는 ADR. "승인됐지만 반영 안 됨" 상태다
• 마커 해시 드리프트 — 헌법 원본에서 복제된 문서 구간(마커로 묶인 intentional duplicate)의 해시가 원본과 어긋난 경우. 원본이 바뀌었는데 사본이 따라가지 못했다는 신호

--strict에서 이 둘은 /sync를 막는다. 마커 드리프트의 치유 절차는 정해져 있다 — 복제 구간을 검토·갱신하고 --update-marker-hashes로 해시를 다시 심은 뒤 재동기화.

결정의 수명

결정 관련 시간 규칙을 정리하면 둘이다. 헷갈리기 쉬우니 범위를 정확히 하자.

• 7일 soak(ADR-0055) — 스펙 레지스트리 강제가 burn-in 기간 동안 경고 수준으로만 동작하도록 한 도입 유예. 최근 7일 안에 갱신된 스펙은 "활동 중"으로 인정된다
• 90일 규칙(ADR-0060) — 스킬 그래프 오버라이드의 실험적 관계 전용. 프론트매터로 승격하지 않고 90일이 지나면 낡음 경고가 뜬다(참고 C)

실전 — 결정 하나의 여정

1. 설계 단계 — 변경이 사소하지 않다면 설계 문서를 쓰고 레지스트리에 등록한다(proposed → approved).
2. 구현+기록 — 구현과 함께, 게이트 순간의 판단을 Decision Record로 남긴다. 증거는 장부에 먼저 적고 EV- ID로 참조.
3. 검증 단계 — /sync가 audit(스펙 관련성)·validate-decisions.ts·거버넌스 반영 검증을 통과시킨다. 하나라도 Fail이면 진행 불가.
4. 거버넌스 반영 — 승인된 ADR은 거버넌스 문서에 연결돼야 한다. 연결 없이 두면 ADR-0059 검증이 잡아낸다.
5. 판단 미루기 — 지금 판단할 근거가 부족하면 백로그 티켓으로 not_before와 함께 예약한다. 기억이 아니라 티켓이 책임진다.