Domain Operating Model — 템플릿이 실행 가능한 SOP가 되는 법

11장과 12장에서 우리는 variant 템플릿을 만들고 승격하는 절차를 배웠다. 그런데 2026-09부터 정식 variant 템플릿에는 새로운 기준이 적용된다. 템플릿이 "에이전트·스킬·설정의 파일 묶음"을 넘어, 무엇을 어떤 순서로 진행하고(스테이지), 누가 책임지며(RACI), 어떤 판정을 통과해야 다음 단계로 나아가는지(결정 게이트)를 기계가 읽을 수 있는 형태로 스스로 선언하는 것이다. 이 구조의 공식 이름은 Domain Operating Model이고, 설계 근거는 ADR-0083과 ADR-0084에 있다.

출처: ai-workspace-standards (GitHub)

도메인 운영 체제로서의 템플릿

워크스페이스 소유자는 한때 이런 제안을 했다. "각 variant 템플릿이 자기 도메인의 운영 체제처럼 동작하게 하자. 프로세스와 스킬, 에이전트팀, 책임 체계, 산출물, 결정 규칙을 템플릿 안에 한데 모으고, 이들을 잇는 그래프까지 갖추자." 2026-09-19의 검증 패스는 흥미로운 사실을 확인했다. 절차 스키마(ADR-0063)와 스킬 그래프(ADR-0060) 덕분에 제안된 구조의 상당 부분이 이미 만들어져 있었고, 진짜 빠진 부분은 훨씬 좁았다 — 도메인 스테이지 축, RACI의 C/I(자문·통보), 일반화된 아티팩트·결정 모델, 그리고 이들을 잇는 그래프 어휘였다. ADR-0083은 이 빈 부분을 채우는 5단계 계획(P1–P5)으로 실행됐다.

이름은 반드시 풀네임으로

이 프레임워크의 공식 명칭은 Domain Operating Model이며, 워크스페이스는 약어 사용을 금지한다. "DOM"으로 줄이면 브라우저의 Document Object Model과 충돌한다. co-deck·co-design·co-game처럼 HTML·CSS를 다루는 variant에게 DOM은 이미 살아있는 용어다. "AOM"도 금지다. "Agent"라는 말은 이미 PM 게이트웨이의 전문 에이전트를 가리키는 말이고, 프레임워크를 자기 하위 구성요소 중 하나의 이름으로 부를 수는 없다. 문서·스키마·스크립트·커밋 메시지 어디에서도 약어가 허용되지 않는다. 하나의 용어가 하나의 뜻만 가진다는 규칙(2장의 "용어는 자산이다")의 좋은 예다.

4개의 구성 그룹

Domain Operating Model의 핵심(Core)은 4개 그룹으로 구성된다. 각 그룹은 템플릿 안의 특정 파일과 연결된다.

비유하면 조립 라인에 가깝다. Process는 공정이 어떤 순서로 늘어서 있는지 정한 라인 배치도이고, Governance는 각 공정 앞에 붙은 담당자 명패이며, Execution은 각 공정이 만들어내는 부품과 다음 라인으로 넘어가기 전 통과해야 하는 품질 검사대다. 그리고 Graph는 이 라인 전체를 내려다보며 "지금 부품이 어디에 있고, 누가 만들었고, 어떤 검사를 거쳤는지"를 한눈에 답해주는 관제탑이다. 아래 그림은 이 네 그룹이 어떻게 하나의 그래프로 모이는지 보여준다.

계층 구조도 명확하다. AI Workspace가 스키마와 계약을 소유하고(레이어 L0·L1), Domain Operating Model이 그 위에서 각 도메인의 운영 원리를 정의하며, Template(templates/co-*/)이 정확히 하나의 도메인을 패키징하고, Project(L3)가 그것을 실제 업무에 인스턴스화한다. 5장에서 본 L0→L1→L2→L3 계층과 도메인 운영 모델이 어떻게 포개지는지를 보여주는 것이다.

Process — 스테이지 축

가장 먼저 채워진 빈 부분은 스테이지(stage) 축이다. 절차 스키마에는 원래 phase 필드가 있었지만, 이것은 PM이 작업을 실행하는 축(0–6: 설계 승인부터 실행·QA까지)이지 도메인 업무의 흐름이 아니다. 컨설팅 프로젝트가 "조사 → 분석 → 보고"로 흘러가는 것, 발표 자료가 "리서치 → 스토리라인 → 빌드 → 출력"으로 흘러가는 것 — 그 도메인만의 진행 단계가 선언된 곳이 없었던 것이다. ADR-0083은 process/stages.yaml에 이 축을 선언한다.

# templates/co-deck/process/stages.yaml (발췌)
schema_version: '1.0'
variant: co-deck
stages:
  - id: S1
    title: Deck Source Research
    order: 1
    owner_agent: version
  - id: S2
    title: Version Export Control
    order: 2
    owner_agent: version
  - id: S3
    title: Deck Publish and Versioning
    order: 3
    owner_agent: pdf-export

기계가 먼저 만들고, 사람이 다듬는다

스테이지 축은 bootstrap-stages.ts가 절차 간 아티팩트 인계 흐름(어떤 절차의 산출물이 다음 절차의 입력이 되는지)을 분석해 자동으로 클러스터링하는 방식으로 만들어졌다. 단순히 phase별로 묶는 게 아니라 실제 산출물의 손이 바뀌는 지점을 기준으로 삼는다. 다만 기계가 만든 1차 결과는 purpose나 진입·종료 조건이 PENDING_REVIEW로 남아 있다. 구조는 자동으로, 의미는 사람이 — 워크스페이스의 일관된 분업 방식이다.

여기에는 최소한의 자격 조건도 있다. DEG-P-01 불변식은 "스테이지가 phase와 다르게 구별되어야 한다"고 요구한다. 절차 수와 phase 수와 스테이지 수가 모두 같아 1:1 대응이라면, 그건 새로운 축이 아니라 phase의 이름을 바꾼 것에 불과하다. 이 검사를 통과한 9개 variant(co-abap, co-consult, co-deck, co-design, co-export, co-game, co-hr, co-price, co-security)는 governed 등급을 받았고, 통과하지 못한 4개(co-develop, co-news, co-safety, co-work)는 사람이 스테이지를 직접 작성할 때까지 core에 머문다. 강제가 아니라 등급으로 성숙도를 표현하는 방식이다.

Governance — RACI 매트릭스

두 번째 그룹은 책임 체계다. governance/raci.yaml은 각 스테이지의 각 활동(절차)에 대해 Accountable(최종 책임)과 Responsible(실행)이 누구인지 선언한다. RACI는 원래 프로젝트 관리의 고전 도구다 — Responsible, Accountable, Consulted, Informed의 네 역할로 "누가 무엇을 하는가"를 정리한다. 새로운 점은 이것이 사람이 읽는 문서가 아니라 생성되고 검증되는 데이터라는 것이다.

# templates/co-deck/governance/raci.yaml (발췌)
schema_version: '1.0'
variant: co-deck
generated_from: procedures/
rows:
  - stage: S2
    activity: procedure.co-deck.deck-build-and-export
    accountable: version
    responsible:
      - html-build
      - measure
      - pdf-export

매트릭스는 generate-raci.ts가 절차의 owner_agent와 단계 데이터에서 도출한다. 워크스페이스의 원칙대로, 근거 없는 값을 합성하지는 않는다. Consulted와 Informed는 지금 근거가 되는 데이터가 없어서 의도적으로 비워 두었다. "나중에 사람이 채울 빈칸"을 기계가 억지로 채우지 않기로 한 것이고, 이 공백은 문서화된 갭이다. 만들어진 매트릭스는 validate-raci.ts가 검증하며, 선언된 역할 키가 실제 에이전트 파일이나 사람 역할 레지스트리로 해석되는지(DEG-R-04)를 fail-closed로 확인한다.

Execution — 아티팩트 모델과 결정 게이트

세 번째 그룹은 "무엇이 나오고, 무엇을 통과해야 하는가"다. 두 조각이 있다. 하나는 아티팩트 모델이다. procedures/_output-types.yaml은 각 variant가 만들 수 있는 산출물 유형의 폐쇄형 목록인데, 스키마가 1.1로 올라가며 각 산출물 유형이 실제로 어느 절차가 만드는지(owner_agent, description)를 기록하게 됐다. 다른 하나는 결정 게이트다. decisions/gates.yaml은 진행 중에 판정이 필요한 지점을 go/no-go 형식으로 선언한다.

# templates/co-deck/decisions/gates.yaml (발췌)
schema_version: "1.0"
variant: co-deck
gates:
  - id: DG-DECK-01
    title: "Layout gate passes with zero violations before export."
    stage: S2
    decider_agent: version
    inputs:
      - pdf_deck
    outcomes:
      - proceed
      - rework
    record_kind: DEC

참고 B에서 다룬 Decision Record(DEC-*.md)와 헷갈리기 쉽다. 둘의 관계는 이렇다. 게이트는 절차 속의 판정 지점이다("출력 전에 레이아웃 검사를 통과해야 한다"라는 규칙 선언). 결정 기록은 실제로 내려진 판정의 기록이다("2026-09-20 판정: proceed"). record_kind: DEC가 두 세계를 잇는 다리로, 게이트에서 나온 판정은 결정 기록으로 남는다.

이 마이그레이션으로 9개 governed 템플릿의 절차에서 서술형 quality_gates 필드가 완전히 제거됐다. 품질 기준이 문장으로 흩어져 있는 대신, 이름과 담당자·입력·판정 결과를 가진 데이터가 된 것이다.

Graph — Domain Execution Graph

네 번째 그룹은 관계층이다. 참고 C에서 배운 스킬 관계 그래프(docs/skill-graph.json)는 매 /sync마다 원천 파일에서 다시 생성되는 투영(projection)이며, 그 자체는 1차 저장소가 아니다. Domain Execution Graph는 이 그래프 위에 얹는 어휘 프로파일이다 — 그래프에 graph_profile: "deg/v1" 표식이 붙고, 새 노드와 엣지 유형이 추가된다.

• stage 노드와 in_stage·stage_follows 엣지 — 어떤 활동이 어느 스테이지에 속하고 스테이지끼리 어떤 순서인지
• step_uses_skill·step_by_agent·produces — 절차의 단계가 어떤 스킬을 쓰고 누가 수행하며 무엇을 만드는지(ADR-0060 Amendment 5에서 이미 존재)
• accountable_for·consulted_on·informed_of — RACI에서 도출되는 책임 관계
• decision_gate 노드와 gated_by·decides_on — 어떤 활동이 어떤 게이트의 판정을 기다리는지

요점은, 흩어져 있던 네 그룹의 데이터가 하나의 그래프에서 연결된 실행 지식이 된다는 것이다. "이 활동은 S2에 속하고(html-build가 실행하며), 스킬 X를 쓰고, pdf_deck를 만들며, DG-DECK-01 게이트를 통과해야 한다"를 한 번의 그래프 조회로 답할 수 있게 된다. 참고 C의 원칙 — 원천에서 재생성되며 자문적(advisory)이라는 — 은 그대로 계승된다. ADR-0084는 여기에 그래프 델타 로그를 더했다. 매 /sync마다 재생성되는 그래프의 구조 변화를 기록해 두면, 운영 모델 자체가 어떻게 진화했는지를 시간순으로 추적할 수 있다.

확장 — 액터 모델·증거 백포팅·델타 로그

ADR-0083은 액터 모델, 증거 모델, SkillHone 진화 루프 같은 확장 후보를 "이름은 정했지만 설계는 나중"(named, not designed) 상태로 남겨 두었다. 이어지는 ADR-0084는 그중 액터 모델을 구현하고, 증거 백포팅과 그래프 델타 로그라는 두 경로를 새로 더했다.

• 액터 모델 — s3에서 본 actor_type 도출. 레지스트리와 파일 존재만으로 사람·에이전트를 구분하며, 손으로 기록하지 않는다.
• 증거 백포팅 — 각 프로젝트(L3)에서 쌓이는 실행 증거를 템플릿(L2)으로 되돌려 반영할 후보를 찾는 읽기 전용 스캐너(evidence-backport-scan.ts). project-resync 파이프라인의 "선택적 백포트 검토"에 증거라는 표면이 추가된 것이다.
• 그래프 델타 로그 — s5의 그래프 변화 이력 기록.

남은 확장 — 더 풍부한 증거 모델과 SkillHone 진화 루프 — 는 여전히 설계되지 않은 상태로, 필요성이 실제 데이터로 확인될 때까지 열어 둔다. "미리 만들지 않는다"는 원칙은 이 핸드북 8장의 로드맵 이야기와 같은 맥락이다.

실전 — 검증과 새 variant

이 구조를 직접 다뤄야 할 때는 크게 두 가지다. 첫째, 기존 governed 템플릿의 운영 모델을 확인하거나 검증할 때. 둘째, 11장에서 만든 새 variant가 승격될 때다. 승격 파이프라인을 통과한 정식 템플릿이 되려면, 이제 스테이지·RACI·게이트의 상태가 등급으로 기록된다. 검증 커맨드를 모아 보면 다음과 같다.

# 워크스페이스 루트에서 실행
bun scripts/validate-process.ts    # 스테이지 축 검증 (DEG-P-01 포함)
bun scripts/validate-raci.ts       # RACI 매트릭스 + 액터 모델 검증 (DEG-R 계열)
bun scripts/validate-procedures.ts # 절차 스키마 검증 (ADR-0063, 기존)
bun scripts/verify-skill-graph.ts  # 그래프 재생성 일관성 (ADR-0060, 기존)

등급 체계의 의미를 표로 정리하면 다음과 같다. "governed"가 우월하고 "core"가 열등한 것이 아니다. core는 "기계가 대신 만들 수 없어서 사람의 작성을 기다리는" 정직한 상태 표시다.

다음 장인 14장은 이 핸드북의 마지막 실습이다. 나만의 반복 업무를 골라 문제 정의부터 검증·회고까지 직접 설계하게 된다. 그 설계에서 "순서(stage), 책임(RACI), 판정(gate)"을 미리 정하는 감각이 바로 이 장에서 본 Domain Operating Model의 감각이기도 하다 — 템플릿에게 배운 것을 나의 설계에 적용해 보자.