GOVERNANCE
AGENTS.md가 AI의 행동 규칙을 정의하듯, GOVERNANCE.md는 제품의 구조적 약속을 정의한다. 진단(레이더) 결과를 바탕으로 아래 4개 영역을 작성하고, OCLS 루프를 돌 때마다 갱신한다.
GOVERNANCE.md란
프로젝트 루트에 두는 한 장짜리 문서다. 누가 무엇을 소유하고, 어떤 조건에서 판단하며, 어떻게 협업하고, 무엇을 기준으로 개선하는지를 선언한다. 구조가 문서화되지 않으면 순환과 실행은 방향을 잃는다.
검증 가능한 명세
GOVERNANCE.md는 사람이 읽기 위한 가이드인 동시에, governance-reviewer 스킬이 PR 단위로 검증하는 명세다. 섹션 순서·필수 구성·금지 신호가 룰로 표현된다.
OWN→CONTRACT→LAYER→SHARPEN — 누락 또는 순서 위반은 린터 룰에서 막힌다.
린터 룰
각 룰은 governance-reviewer 스킬이 PR diff에서 검출한다. error는 머지 전 해소가 원칙, warning은 리뷰 코멘트로 남긴다.
| 룰 | 강도 | 검사 대상 |
|---|---|---|
missing-section | error | §01–§05 중 하나 이상이 비어 있음 |
section-order | error | OWN → CONTRACT → LAYER → SHARPEN 순서 위반 |
authority-sprawl | warning | OWN 섹션에 권한 범위가 선언되지 않음 |
contract-gap | error | CONTRACT 섹션에 input·output·reject_when 누락 |
observability-gap | warning | LAYER 섹션에 trace·log 명세 누락 |
validation-gap | error | SHARPEN 섹션에 metric·임계값·리뷰 주기 누락 |
broken-ref | error | frontmatter의 참조가 본문에서 정의되지 않음 |
머신 가독 frontmatter
사람용 마크다운과 동등한 YAML 표현. 본문은 사람을, frontmatter는 린터·코딩 에이전트를 향한다. 두 표현이 어긋나면 broken-ref가 발생한다.
---
version: 0.1
product: 고객 상담 AI
maturity: 3
agents:
intake:
type: ai
owner: support-team
authority: [classify.read]
response:
type: ai
owner: support-team
authority: [reply.draft, refund.draft]
cs-manager:
type: human
authority: [refund.approve, escalation.resolve]
contracts:
intake:
input: { message: string }
output: { category: enum, urgency: enum }
reject_when: ["len(message) > 5000"]
response:
input: { category: "ref(contracts.intake.output)", history: ref }
output: { reply: string, reasoning: string }
reject_when: ["contains(pii)", "mentions(competitor)"]
metrics:
accuracy: { target_min: 0.95, review: weekly }
cost_per_call_krw: { target_max: 500, review: daily }
escalation_rate: { target_max: 0.05, review: weekly }
---진단 스냅샷
Assessment Snapshot — /assessment 결과를 최상단에 요약한다
- 최종 진단 날짜와 선택한 프리셋을 기재한다.
- Top 3 우선 패턴과 점수를 나열한다 — 어떤 패턴이 가장 시급한지 한눈에 보인다.
- 핵심 긴장 관계 1-2개와 대응 가이드를 기재한다 — 트레이드오프 의사결정의 근거.
- 추천 성숙도 단계를 요약한다 — 지금 어디에 있고 다음은 무엇인지.
- 전체 진단 리포트는 `docs/assessment-YYYY-MM-DD.md`로 보관하고 경로를 참조한다.
단계별 산출물
현재 단계가 무엇을 요구하는지. /assessment 결과의 추천 단계와 비교한다.
1. 단일 에이전트 시작
핵심 산출물- 모듈별 입출력 계약 초안
- 기본 실행 로그 (호출 횟수, 비용, 성공/실패)
- 역할 간 충돌이 관측된 지점 목록
- 로그 없이 2단계로 넘어가면 분할 기준이 직관에 의존해 잘못된 경계를 만든다
- 계약 없이 분할하면 에이전트 간 인터페이스가 암묵적이 되어 협업 장애가 증가한다
2. 책임 분리
핵심 산출물- 에이전트별 책임 정의서
- 핸드오프 규칙과 컨텍스트 전달 스키마
- 에이전트별 독립 평가 기준
- 지나치게 세분화하면 핸드오프 오버헤드가 단일 에이전트보다 더 큰 비용을 만든다
- 경계를 잘못 나누면 하나의 책임이 두 에이전트에 걸쳐 누구의 실패인지 다시 불분명해진다
3. 멀티에이전트 협업
핵심 산출물- 안정화된 협업 흐름도
- 컨텍스트 라우팅 규칙
- 상태/기억 분리 정책
- 거버넌스 없이 규모를 키우면 비용 폭증, 품질 저하, 보안 사고가 동시에 발생한다
- 거버넌스를 너무 일찍 도입하면 아직 불안정한 경계에 경직된 규칙을 씌워 진화를 막는다
4. 거버넌스 내재화
핵심 산출물- 자동화된 평가와 가드레일 파이프라인
- 승인 분류 매트릭스와 에스컬레이션 규칙
- OCLS 루프 기반 정기 리뷰 프로세스
- 거버넌스가 형식적이 되면 지표만 관리하고 실제 품질은 방치되는 '거버넌스 극장'이 된다
- 거버넌스 계층이 병목이 되면 에이전트의 자율성과 처리 속도가 불필요하게 제한된다
## 진단 스냅샷
> 최종 진단: YYYY-MM-DD
> 프리셋: <프리셋 이름>
> 전체 리포트: docs/assessment-YYYY-MM-DD.md
### Top 3 우선 패턴
1. **<패턴명>** (<점수>/100)
2. **<패턴명>** (<점수>/100)
3. **<패턴명>** (<점수>/100)
### 핵심 긴장 관계
- <긴장 설명> — <대응 가이드>
### 추천 성숙도
**Stage N — <단계명>**소유 구조
OWN — 누가(사람 또는 AI) 어떤 결과를 소유하는가
- 제품의 핵심 결과물과 각 결과물의 소유자를 나열한다.
- 소유자가 사람인지 AI인지 명시한다 — 소유 주체의 종류에 따라 계약의 엄격도가 달라진다.
- AI 소유: 모든 판단 조건이 명시적이어야 하고, 가드레일과 에스컬레이션이 필수다.
- 사람 소유: 맥락적 판단이 가능하지만, 판단 기준을 문서화해야 팀이 공유할 수 있다.
- 소유자가 불명확한 영역(회색 지대)을 식별하고 배정한다.
# 소유 구조
| 결과물 | 소유자 | 유형 | 거버넌스 수준 |
|--------|--------|------|-------------|
| 문의 분류 | Intake Agent | AI | 계약 기반 자동 실행, 오분류 시 사람 에스컬레이션 |
| 응답 품질 | Response Agent | AI | 가드레일 + 사후 QA 검토 |
| 환불 승인 (50만원 초과) | CS 매니저 | 사람 | 사전 승인 필수 |
| 비용 한도 준수 | Ops 팀 | 사람 | 일간 대시보드 모니터링 |
| 규제 준수 | Compliance Officer | 사람 | 외부 감사 대응 |에이전트가 늘어나면서 누가 어떤 권한을 가지는지 추적할 수 없게 된다. 에이전트 ID, 접근 범위, 실행 권한이 암묵적으로 확장되어 보안 사고와 책임 공백이 동시에 발생한다.
판단 계약
CONTRACT — 어떤 조건에서 어떤 판단을 내리는가
- 각 실행 단위의 입력 조건, 출력 형식, 거절 조건을 선언한다.
- 자동 승인 / 사후 검토 / 사전 승인의 분류 기준을 정의한다.
- 실패 시 복구 경로와 폴백 동작을 명시한다.
# 판단 계약
## 분류 기준
- 자동 승인: 비용 < 10만원, 기존 정책 범위 내
- 사후 검토: 비용 10만~50만원, 신규 케이스
- 사전 승인: 비용 > 50만원, 법적 책임, 고객 약속
## 거절 조건
- PII 포함 응답 → 차단
- 경쟁사 비교 발언 → 에스컬레이션모듈과 에이전트의 입출력, 거절 조건, 실패 모드가 문서화되지 않은 채 운영된다. 모듈 교체나 프롬프트 변경 시 부작용을 예측할 수 없고, 평가 기준도 세울 수 없다.
협업 규칙
LAYER — 주체 간 정보 전달과 승인 흐름
- 주체 간 정보 전달 시 포함/제외할 컨텍스트 범위를 정의한다.
- 협업 순서와 의존 관계를 명시한다.
- 병렬 실행 가능한 영역과 순차 의존 영역을 구분한다.
# 협업 규칙
## 정보 전달 범위
- 분류 → 응답: 카테고리, 감정 분석, 이전 대응 이력
- 응답 → QA: 응답 초안, 참조한 정책, 판단 근거
- QA → 운영: 품질 점수, 위반 항목, 개선 제안
## 의존 관계
- 분류 완료 → 응답 시작 (순차)
- 응답 + 비용 계산 (병렬)
- QA는 모든 응답에 비동기 실행에이전트의 추론 경로, 의사결정 근거, 핸드오프 사유가 기록되지 않는다. 장애 발생 시 원인을 특정할 수 없고, 시스템 전체가 블랙박스가 된다.
개선 기준
SHARPEN — 무엇을 측정하고 언제 구조를 보정하는가
- 핵심 품질 지표와 목표치를 정의한다.
- 비용 추적 단위와 예산 한도를 설정한다.
- 구조 보정을 촉발하는 시그널(리뷰 주기, 임계값)을 명시한다.
# 개선 기준
## 핵심 지표
| 지표 | 목표 | 리뷰 주기 |
|------|------|----------|
| 응답 정확도 | > 95% | 주간 |
| 토큰 비용/건 | < 500원 | 일간 |
| 에스컬레이션율 | < 5% | 주간 |
## 보정 시그널
- 정확도 < 90% 3일 연속 → 소유 구조 재검토
- 비용 예산 80% 도달 → 모델 배정 재조정
- 신규 거절 패턴 10건 이상 → 계약 갱신평가 기준과 가드레일이 부재하거나 형식적으로만 존재한다. 품질 편차가 커지고, 위험한 동작이 사후에야 발견되며, 개선을 위한 피드백 루프가 끊어진다.
관련 패턴
각 거버넌스 약속을 어떤 구현 패턴으로 만들 수 있는지. 패턴명을 누르면 카탈로그 항목으로 이동한다.
| 거버넌스 약속 | 구현 패턴 | 연결 방식 |
|---|---|---|
| 책임 분할 |
| 상위 에이전트가 목표를 하위 책임으로 분해하고 위임하는 구조. 병렬 처리가 가능한 책임은 Fan-out으로, 순차 의존성이 있는 책임은 Hierarchical로 구현한다. |
| 모듈 계약 |
| 계약의 입출력 스키마가 실행 가능한 스펙이 되어 코드, 문서, mock을 자동 생성한다. MCP Tool Definition이 모듈 계약의 구현 형태가 될 수 있다. |
| 컨텍스트 라우팅 |
| 파이프라인의 각 단계에서 다음 에이전트에 전달할 컨텍스트를 필터링·구조화하는 규칙. Routing Pattern은 문의 유형에 따라 적절한 에이전트로 분기하는 구현. |
| 상태와 기억 제어 |
| 주로 인프라 설계 영역이다. 세션 스토어(단기)와 벡터 DB/지식 베이스(장기)의 분리, 읽기/쓰기 권한 제어가 핵심 구현 과제. |
| 평가와 가드레일 |
| 생성 에이전트의 출력을 검증 에이전트가 평가하는 구조. 사전 가드레일은 실행 전 차단, 사후 평가는 Generator-Critic 루프로 구현한다. |
| 인간 승인 |
| 비동기 승인 큐와 승인/거절 콜백이 핵심 구현 요소. 승인 대기 중에도 다른 작업을 계속하는 비동기 구조를 기본으로 한다. |
| 비용 통제 |
| 경로별 모델 선택(고위험=고성능, 저위험=경량), 에이전트별 토큰 예산 할당, 캐시·배치 전략을 결합하여 비용 곡선을 통제한다. |
| 의사결정 추적 |
| 에이전트별 의사결정 로그를 구조화된 형태(JSON, OpenTelemetry spans)로 수집하고, 인과 관계를 추적할 수 있는 트레이싱 인프라를 구현한다. |
리뷰 체크리스트
GOVERNANCE.md 작성·갱신 시 점검할 거버넌스 계층 질문. 전체는 /checklist 참조.
- SHARPEN평가 기준이 정량적으로 정의되어 있는가?
- SHARPEN고위험 작업의 인간 승인 기준이 명시적인가?
- SHARPEN모든 의사결정을 사후에 추적할 수 있는가?
- SHARPEN보안 위반 시도의 실시간 탐지와 자동 차단 메커니즘이 구현되어 있는가?
- SHARPENSLA 위반 추세를 자동으로 감지하고 알림하는 시스템이 있는가?
- SHARPEN모든 의사결정 로그가 규제 감사 요구에 부합하는 보존 기간과 형식으로 저장되는가?
- SHARPEN자동화된 평가 파이프라인이 에이전트 출력을 지속적으로 검증하는가?
- SHARPEN수집된 데이터의 품질과 신선도가 주기적으로 검증되는가?
- SHARPEN에이전트별·모듈별 비용이 실시간으로 추적되고 예산 한도가 설정되어 있는가?
- SHARPENAI의 자율 판단 범위를 정기적으로 검토하고 조정하는 프로세스가 있는가?
- SHARPEN시스템 품질 저하가 매출 지표에 미치는 영향을 실시간으로 모니터링하는가?
- SHARPEN고객 만족도와 시스템 성능 간의 상관관계를 추적하고 있는가?
- SHARPEN도메인 규칙 변경 시 영향을 받는 에이전트를 자동으로 식별할 수 있는가?
- SHARPEN이해관계자 간 우선순위 충돌을 해소하는 거버넌스 규칙이 있는가?
- SHARPEN의사결정 품질을 비즈니스 결과와 연결하여 추적하고 있는가?
- SHARPEN경쟁 환경 변화가 제품 우선순위에 반영되는 피드백 루프가 있는가?
- SHARPEN사용자 규모 증가에 따른 비용 곡선이 예측되어 있는가?
근거 — 왜 OCLS인가
네 개 원칙이 OCLS 4페이즈로 구현된다. 페이즈 순서는 원칙 순서를 그대로 잇는다.
기능이 아니라 책임 단위로 설계한다
에이전트는 기능 호출기가 아니라 지속적으로 설명 가능한 책임 주체여야 한다.
모듈은 호출 가능한 도구가 아니라 계약을 가진 실행 단위다
모듈이 계약을 가져야 평가, 교체, 권한 제어, 테스트가 가능한 구조가 된다.
확장은 분류·구조화를 통해 거버넌스될 때 가능하다
에이전트가 늘어날수록 카테고리·계층·경계로 구조화해야 거버넌스가 유지되고 확장이 지속 가능해진다.
아키텍처는 운영 중 진화하는 시스템이다
실패 로그와 평가 결과를 바탕으로 책임 경계와 정책을 계속 조정해야 한다.
완성된 예시
고객 상담 AI 제품을 기준으로 작성한 GOVERNANCE.md 전체 예시. 프로젝트 루트에 이 파일을 두고 OCLS 루프를 돌 때마다 갱신한다.
# GOVERNANCE.md — 고객 상담 AI
> 제품: AI 기반 고객 상담 자동화 시스템
> 단계: 3. 멀티에이전트 협업
> 최종 갱신: 2026-04-17
> 다음 리뷰: 2026-05-01
---
## 진단 스냅샷
> 최종 진단: 2026-04-17
> 프리셋: 고객 대면 서비스
> 전체 리포트: docs/assessment-2026-04-17.md
### Top 3 우선 패턴
1. **컨텍스트 라우팅** (87/100)
2. **평가와 가드레일** (82/100)
3. **모듈 계약** (79/100)
### 핵심 긴장 관계
- 풍부한 고객 경험과 응답 속도의 충돌 — 핵심 응답은 즉시, 부가 컨텍스트는 스트리밍 또는 비동기로 보완한다.
- 신중한 의사결정과 빠른 응답의 충돌 — 고영향 판단은 동기적 검증, 저영향은 비동기 사후 검증으로 분리한다.
### 추천 성숙도
**Stage 3 — 멀티에이전트 협업**
협업 규칙과 정보 전달 체계를 정의해 제품 흐름을 안정화한다.
---
## 0. reopt architecture 컨텍스트
이 문서는 reopt architecture 방법론에 따라 작성되었다.
코딩 에이전트는 이 섹션을 읽고 구조적 판단의 근거로 사용한다.
### OCLS 루프
모든 구조적 판단은 4단계 루프를 따른다:
- **OWN**: 이 결과의 소유자는 누구인가? 사람인가, AI인가?
- **CONTRACT**: 판단 조건, 거절 조건, 실패 경로가 명시되어 있는가?
- **LAYER**: 주체 간 정보 전달과 협업 규칙이 정의되어 있는가?
- **SHARPEN**: 운영 결과로 구조를 개선하는 기준이 있는가?
---
## 1. 소유 구조 (OWN)
각 결과물의 소유자와 권한 범위를 다음 표로 선언한다. 거버넌스 수준은 자동 실행 가능 여부를 결정한다.
| 결과물 | 소유자 | 유형 | 권한·거버넌스 수준 |
|--------|--------|------|---------------------|
| 문의 분류 | Intake Agent | AI | classify.read 권한. 오분류율 > 10% 시 사람 리뷰 |
| 응답 생성 | Response Agent | AI | reply.draft 권한 + 가드레일 + QA Agent 사후 검토 |
| 응답 품질 검증 | QA Agent | AI | 전수 검사. 위반 시 자동 차단 + 사람 알림 |
| 환불 판단 (10만원 이하) | Response Agent | AI | refund.draft 권한 + 자동 승인 + 일간 샘플링 사후 검토 |
| 환불 판단 (10만원 초과) | CS 매니저 | 사람 | refund.approve 권한 — 사전 승인 필수 |
| 비용 한도 | Ops 팀 | 사람 | 일간 대시보드. 예산 80% 시 알림 |
| 규제 준수 | Compliance Officer | 사람 | 월간 감사. PII 관련 즉시 대응 |
### 회색 지대
- 고객이 법적 조치를 언급하는 경우 → CS 매니저 즉시 에스컬레이션
- 기존 정책에 없는 신규 요청 유형 → 주간 리뷰에서 소유자 배정
---
## 2. 판단 계약 (CONTRACT)
### Intake Agent
- 입력: 고객 메시지 (텍스트)
- 출력: { category, sentiment, urgency, language }
- 거절: 메시지 길이 > 5000자 → "메시지를 나눠서 보내주세요" 응답
- 실패: 분류 신뢰도 < 0.7 → "기타" 분류 + 사람 리뷰 플래그
### Response Agent
- 입력: { category, sentiment, customerHistory, relevantPolicies }
- 출력: { response, referencedPolicies, reasoning }
- 거절: PII 포함 요청 → 차단. 경쟁사 비교 → 에스컬레이션
- 모델: 일반 문의 = 경량 모델, 복잡 문의 = 고성능 모델
### QA Agent
- 입력: { response, reasoning, category }
- 출력: { score, violations[], approved }
- 기준: 정확성 ≥ 0.9, 톤 일관성 ≥ 0.85, 정책 준수 = 100%
- 위반 시: score < 0.8 → 자동 차단 + Response Agent 재생성
### 승인 분류
| 등급 | 기준 | 처리 |
|------|------|------|
| 자동 | 기존 정책 범위 + 비용 < 10만원 | 즉시 실행 |
| 사후 검토 | 비용 10만~50만원 또는 신규 케이스 | 실행 후 24시간 내 리뷰 |
| 사전 승인 | 비용 > 50만원, 법적 언급, 고객 약속 | CS 매니저 승인 후 실행 |
---
## 3. 협업 규칙 (LAYER)
모든 핸드오프는 구조화 로그(trace_id, decision, reasoning)로 기록된다.
### 정보 전달 범위
| 출발 | 도착 | 포함 | 제외 |
|------|------|------|------|
| Intake | Response | category, sentiment, 이전 대응 이력 | 원본 메시지 전문 (요약만 전달) |
| Response | QA | 응답 초안, 참조 정책, 판단 근거 | 고객 개인정보 |
| QA | Ops 대시보드 | 품질 점수, 위반 항목 | 개별 응답 내용 |
### 흐름
```
고객 메시지 → Intake (분류) → Response (응답 생성)
↓
QA (품질 검증)
↓
[통과] → 고객 전달
[차단] → Response 재생성 (최대 2회)
[2회 실패] → 사람 에스컬레이션
```
### 비용 배분
- Intake: 경량 모델 고정 (건당 ~50원)
- Response: 복잡도별 모델 선택 (건당 100~800원)
- QA: 경량 모델 고정 (건당 ~30원)
- 에이전트별 일간 예산 한도 설정
---
## 4. 개선 기준 (SHARPEN)
### 핵심 지표
| 지표 | 현재 | 목표 | 리뷰 주기 |
|------|------|------|----------|
| 응답 정확도 | 93% | > 95% | 주간 |
| 오분류율 | 8% | < 5% | 주간 |
| 평균 응답 시간 | 4.2초 | < 3초 | 일간 |
| 토큰 비용/건 | 420원 | < 500원 | 일간 |
| 에스컬레이션율 | 7% | < 5% | 주간 |
| QA 차단율 | 12% | < 8% | 주간 |
| 고객 만족도 (CSAT) | 4.1 | > 4.3 | 월간 |
### 보정 시그널
| 시그널 | 임계값 | 조치 |
|--------|--------|------|
| 정확도 하락 | < 90% 3일 연속 | 소유 구조 재검토. Response Agent 프롬프트/모델 점검 |
| 비용 급증 | 일간 예산 80% 도달 | 모델 배정 재조정. 캐시 전략 점검 |
| 신규 거절 패턴 | 10건/주 이상 | 계약 갱신. 새 거절 조건 추가 |
| 에스컬레이션 급증 | > 10% 2일 연속 | 승인 분류 기준 재검토 |
| CSAT 하락 | < 3.8 | 전면 리뷰. 응답 톤/정책 재점검 |
### 리뷰 일정
- 일간: 비용 대시보드, 에러 로그 확인 (Ops)
- 주간: 품질 지표 리뷰, 계약 갱신 여부 판단 (팀 전체)
- 월간: GOVERNANCE.md 전체 리뷰 + Assessment 재진단