AITEM 기반 공통 거버넌스 추출

AITEM에서 이미 검증된 AI 개발 운영 방식을 공통 정책으로 추출하고, `ai-rules` 전체에 일반화 가능한 요소와 프로젝트 고유 요소를 구분한다.

guide docs/guide/AITEM_TO_COMMON_GOVERNANCE.md

목적: AITEM에서 이미 검증된 AI 개발 운영 방식을 공통 정책으로 추출하고, ai-rules 전체에 일반화 가능한 요소와 프로젝트 고유 요소를 구분한다.

왜 AITEM을 baseline으로 삼는가

AITEM은 현재 ai-rules가 적용되는 프로젝트들 중에서 가장 강한 운영 통제를 가진 사례다.

AITEM에는 이미 다음 요소가 결합되어 있다:

규칙 기반 개발 (CLAUDE.md, extensions, agents)
hook 기반 사전 차단 (agent-guard.mjs)
3계층 CI 안전망
branch protection
post-merge recovery
nightly audit
verifier/judge 기반 AI governance
문서 우선 작업 흐름

즉, AITEM은 단순한 "규칙 적용 프로젝트"가 아니라, 실제 강제와 측정이 일부 결합된 운영 사례다.

AITEM에서 이미 강제되는 것

1. Git/작업 흐름 사전 차단

PR 생성, 커밋, push 직전 규칙 위반 자동 차단
보호 브랜치 직접 작업 방지
force push 금지

2. CI 기반 병합 차단

PR 시 API 계약, DB migration, 보안, 대규모 변경 검증
실패 시 branch protection으로 병합 차단

3. 병합 후 복구 레일

develop push 후 실패 시 revert 브랜치/PR 생성
긴급 이슈 생성

4. scheduled audit

nightly E2E / 회귀 감시
실패 시 이슈화

AITEM에서 이미 측정되는 것

1. verifier / judge 모델 구성

verifier: 구조/컨벤션/도메인 관점 분석
judge: 최종 판정 및 fallback 구성

2. threshold 기반 판정

domain별 confidence threshold
overall score 기준 판정 가능 구조

3. report 생성 가능성

.ai-governance/config.yaml
.ai-governance/agents.yaml
.ai-governance/thresholds.yaml

즉 AITEM은 정책 + 강제 + 측정의 초기 형태를 이미 갖고 있다.

그대로 공통화 가능한 것

다음 요소는 대부분의 프로젝트에 공통 적용 가능하다.

pre-merge validation
branch protection 전제
post-merge recovery 개념
scheduled audit 개념
verifier/judge 구조
rule 위반 사전 차단
문서/체크리스트 우선 작업 방식

이들은 특정 인프라나 특정 도메인에 종속되지 않는다.

정규화 후 공통화해야 하는 것

1. governance 설정 스키마

현재 AITEM profile과 governance integration plan의 스키마가 다를 수 있다. 공통화를 위해 단일 schema로 통합해야 한다.

정규화 대상:

verifiers
judge
fallback
safe_mode_override
thresholds

2. domain threshold 모델

AITEM은 결제/인증처럼 민감한 도메인을 가진다. 이를 공통화하려면 기본 축과 선택 축을 분리해야 한다.

기본 축:

structure
convention
domain

선택 축:

payment
auth
personal_data
api_contract
migration_safety

3. bypass 정책

AITEM의 긴급 우회 방식은 일반 프로젝트 기본값으로 두면 위험하다. 공통화 시 아래를 명시해야 한다.

bypass 허용 조건
승인 주체
감사 로그 필수 여부
후속 검증 강제 여부
만료 조건

4. deployment contract

서버/배포 환경은 달라도 아래 인터페이스는 공통화 가능하다.

pre_merge_checks
pre_deploy_checks
deploy_staging
deploy_production
rollback
post_deploy_verify

정책은 공통, 실제 실행은 adapter가 담당한다.

AITEM 전용으로 남겨야 하는 것

다음은 공통화보다 AITEM 전용 override로 유지하는 것이 적절하다.

결제/인증 중심의 강화 threshold
AITEM 고유 문서 참조 규칙
AITEM 고유 디자인 토큰 규칙
AITEM에 특화된 배포/운영 모드
AITEM의 긴급 bypass 상세 절차

즉, 공통 정책 위에 AITEM-specific strict mode가 올라가는 구조가 적합하다.

공통 거버넌스 구조 제안

AITEM을 일반화한 공통 구조는 아래 3층으로 정리한다.

1. Common Policy

모든 프로젝트 공통 규칙

어떤 검증이 필수인가
어떤 변경이 승인 필요인가
어떤 작업이 금지인가
어떤 상황에서 rollback 해야 하는가

2. Common Contract

프로젝트가 맞춰야 할 공통 인터페이스

검증 계약
배포 계약
리포트 계약
bypass 계약

3. Project Adapter

프로젝트별 구현

CI provider
deploy target
rollback 방식
verifier/judge 구성
threshold override
project-specific bypass

공통화 우선순위

1순위

governance schema 통일
verifier/judge/threshold 공통 모델 정의

2순위

deployment contract 정의
bypass policy 정의

3순위

capability matrix 도입
benchmark / report schema 통일

한 줄 결론

AITEM은 공통화의 좋은 baseline이다.
다만 그대로 복사하는 것이 아니라, AITEM에서 검증된 운영 방식을 policy / contract / adapter 구조로 추출해서 일반화해야 한다.