도메인별 검증 임계값 모델

프로젝트별 verifier/judge 시스템이 공통 점수 축을 공유하면서도, 도메인 민감도에 따라 추가 임계값을 선택적으로 활성화할 수 있도록 기준 모델을 정의한다.

목적: 프로젝트별 verifier/judge 시스템이 공통 점수 축을 공유하면서도, 도메인 민감도에 따라 추가 임계값을 선택적으로 활성화할 수 있도록 기준 모델을 정의한다. 관련 문서:

• AITEM_TO_COMMON_GOVERNANCE.md
• DEPLOYMENT_CONTRACT.md

---

왜 threshold 모델이 필요한가

모든 프로젝트가 같은 수준의 위험을 가지는 것은 아니다.

• 단순 문서/대시보드 프로젝트
• 일반 SaaS 프로젝트
• 인증/결제/개인정보를 다루는 서비스

이 차이를 무시하고 동일한 confidence 기준을 적용하면:

• 민감한 프로젝트는 너무 느슨해지고
• 단순 프로젝트는 불필요하게 엄격해진다

따라서 ai-rules는 공통 기본 축 + 프로젝트별 선택 축 구조로 threshold를 정의해야 한다.

---

모델 구조

threshold는 두 층으로 나눈다.

1. 기본 축 (모든 프로젝트 공통)

반드시 존재해야 하는 공통 평가 축:

• structure
• convention
• domain

2. 선택 축 (프로젝트 성격에 따라 활성화)

도메인 민감도에 따라 추가:

• payment
• auth
• personal_data
• api_contract
• migration_safety
• error_handling
• dependencies

---

기본 축 정의

structure

무엇을 보는가:

• 파일/모듈 구조 적절성
• 책임 분리
• 과도한 결합
• 컴포넌트/서비스 경계

낮은 점수 예시:

• 한 파일에 구현 과도 집중
• controller/service/repo 경계 붕괴
• 중복 구조 증가

convention

무엇을 보는가:

• 코드 스타일 일관성
• 네이밍
• 기존 패턴 준수
• 규칙 위반 여부

낮은 점수 예시:

• 기존 프로젝트 패턴 무시
• 예외적 구현 방식 도입
• 금지 규칙 우회

domain

무엇을 보는가:

• 요구사항 충족 여부
• 핵심 비즈니스 흐름 보존 여부
• 의도와 실제 구현의 일치

낮은 점수 예시:

• 요구사항 일부 누락
• 주요 사용자 플로우 깨짐
• 회귀 가능성 높은 변경

---

선택 축 정의

payment

활성화 대상:

• 결제
• 정산
• 청구
• 환불

무엇을 보는가:

• 금액/상태 전이 안정성
• 중복 결제/누락 결제 방지
• 결제 후속 흐름 유지

auth

활성화 대상:

• 로그인
• 로그아웃
• 세션
• 토큰
• 권한

무엇을 보는가:

• 인증 흐름 보존
• 권한 우회 가능성
• 세션 만료/복구 처리

personal_data

활성화 대상:

• 개인정보
• 민감 프로필 데이터
• 고객 식별 정보

무엇을 보는가:

• 노출 위험
• 저장/전달 경로 안전성
• 마스킹/필터링

api_contract

활성화 대상:

• frontend-backend 계약
• 외부 API 연동
• SDK/공용 인터페이스

무엇을 보는가:

• 시그니처 변화
• 응답 형식 회귀
• 하위 호환성

migration_safety

활성화 대상:

• DB schema 변경
• migration
• seed/transform

무엇을 보는가:

• 파괴적 변경 위험
• rollback 가능성
• 데이터 보존성

error_handling

활성화 대상:

• 사용자 오류 처리
• API 에러 처리
• 재시도/복구 흐름

무엇을 보는가:

• 실패 시 사용자 피드백
• 예외 누락
• 삼켜지는 에러

dependencies

활성화 대상:

• 신규 패키지 도입
• 버전 업그레이드
• 런타임 의존성 변경

무엇을 보는가:

• 불필요한 라이브러리 도입
• 보안/호환성 위험
• 운영 부담 증가

---

프로젝트 타입별 권장 활성화

1. 기본 프로젝트

활성 축:

• structure
• convention
• domain

2. 일반 SaaS

활성 축:

• structure
• convention
• domain
• auth
• api_contract
• error_handling

3. 민감 SaaS / AITEM 계열

활성 축:

• structure
• convention
• domain
• payment
• auth
• personal_data
• api_contract
• migration_safety
• error_handling
• dependencies

---

권장 threshold 예시

기본 프로젝트

복사domains:
  structure: 60
  convention: 60
  domain: 55
overall_min_score: 58

일반 SaaS

복사domains:
  structure: 70
  convention: 70
  domain: 65
  auth: 72
  api_contract: 70
  error_handling: 68
overall_min_score: 69

AITEM형 민감 서비스

복사domains:
  structure: 70
  convention: 70
  domain: 68
  payment: 90
  auth: 85
  personal_data: 88
  api_contract: 75
  migration_safety: 90
  error_handling: 72
  dependencies: 70
overall_min_score: 78

---

판정 원칙

PASS

• 전체 점수 통과
• 필수 선택 축도 모두 통과

CONDITIONAL

• 전체 점수는 근접하지만
• 일부 축이 threshold 미달
• 수정 조건이 명확함

FAIL

• 전체 점수 미달
• 또는 민감 축(payment, auth, migration_safety) 중 하나라도 심각 미달

---

운영 원칙

1. 기본 축은 항상 유지

프로젝트 규모와 무관하게:

• structure
• convention
• domain

은 항상 존재해야 한다.

2. 선택 축은 profile에서 활성화

프로젝트별로:

• 어떤 축을 켤지
• 최소 점수를 얼마로 할지
• 어떤 축이 hard-fail인지

를 profile 또는 governance config에서 결정한다.

3. 민감 축은 hard-fail 가능

다음 축은 프로젝트에 따라 hard-fail 대상으로 승격 가능:

• payment
• auth
• personal_data
• migration_safety

---

AITEM 기준 적용 방향

AITEM은 기본 SaaS보다 민감도가 높다.

따라서 AITEM은 공통 기본 축 외에도 아래를 강하게 활성화해야 한다.

• payment
• auth
• personal_data
• api_contract
• migration_safety

그리고 이 구성을 AITEM 전용 strict mode가 아니라, 향후 민감 SaaS preset의 기준값으로 일반화할 수 있다.

---

다음 연결 문서

이 문서를 기준으로 이어서 정의할 것:

• BYPASS_POLICY.md
• PROJECT_CAPABILITY_MATRIX.md

---

한 줄 결론

도메인 검증은 하나의 점수로 끝내면 안 된다.
ai-rules는 공통 기본 축 + 프로젝트별 선택 축 구조로 threshold를 관리해야 하며, AITEM은 그중 가장 엄격한 민감 서비스 preset의 기준 사례가 된다.