ai-rules › handbook › 우회 정책 관리 기준

우회 정책 관리 기준

`SKIP_E2E`, 수동 승인 우회, 조건부 배포 같은 예외 경로가 무질서하게 퍼지지 않도록, 허용 범위와 감사 기준을 명확히 정의한다.

guide docs/guide/BYPASS_POLICY.md

목적: SKIP_E2E, 수동 승인 우회, 조건부 배포 같은 예외 경로가 무질서하게 퍼지지 않도록, 허용 범위와 감사 기준을 명확히 정의한다. 관련 문서:

왜 bypass 정책이 필요한가

실무에서는 모든 검증을 항상 완전하게 통과시키고 나서만 진행할 수 없는 순간이 있다.

예:

  • 긴급 장애 대응
  • CI 인프라 일시 장애
  • flaky E2E 테스트
  • staging만 우선 배포해야 하는 상황

문제는 bypass가 명시적 정책 없이 허용되면:

  • 우회가 기본값이 되고
  • 실패 학습이 사라지며
  • 품질 기준이 프로젝트마다 무너진다

따라서 bypass는 "편의 기능"이 아니라 명시적 예외 프로토콜이어야 한다.

bypass의 정의

bypass란 원래 통과해야 하는 검증/승인/절차를 예외적으로 건너뛰는 모든 행동을 의미한다.

예:

  • SKIP_E2E=1
  • 특정 status check 무시
  • conditional 판정 상태에서 강행 배포
  • 일반 승인 절차 생략
  • 일부 threshold 미달 상태에서 merge/deploy 진행

기본 원칙

1. bypass는 기본값이 될 수 없다

  • bypass는 항상 예외여야 한다
  • 문서화되지 않은 bypass는 금지

2. bypass는 흔적이 남아야 한다

  • 누가
  • 왜
  • 무엇을
  • 언제까지

우회했는지 기록되어야 한다

3. bypass 뒤에는 후속 검증이 따라야 한다

  • nightly audit
  • post-deploy verify
  • 후속 PR 또는 revert 준비

4. 민감 영역은 bypass 허용 범위가 더 좁다

다음은 일반 영역보다 훨씬 엄격하게 다뤄야 한다.

  • payment
  • auth
  • personal_data
  • migration_safety

bypass 분류

1. 허용 가능한 bypass

조건부로 허용 가능:

  • flaky E2E 일시 건너뛰기
  • staging 배포에서 일부 non-critical smoke test 우회
  • CI 인프라 장애 시 대체 검증으로 전환

2. 제한적 허용 bypass

상위 승인과 강한 기록이 있을 때만 허용:

  • production 배포에서 conditional 상태 강행
  • threshold 일부 미달 상태에서 merge
  • post-merge recovery 전제로 진행

3. 금지 bypass

원칙적으로 허용 불가:

  • 보안 검증 완전 생략
  • DB 파괴 명령어 안전 규칙 우회
  • 보호 브랜치 보호 장치 우회
  • force push 허용
  • 민감 정보 노출 가능성이 있는 우회

승인 주체

일반 프로젝트

  • staging bypass: 프로젝트 책임자 또는 사용자 승인
  • production bypass: 사용자 명시 승인 필수

민감 SaaS / AITEM 계열

  • staging bypass: 책임자 승인 + 후속 검증 계획 필요
  • production bypass: 명시 승인 + audit 기록 + rollback 준비 필수

bypass 기록 최소 형식

모든 bypass는 아래 정보를 남긴다.

# Bypass Record

- project: aitem
- environment: staging
- type: SKIP_E2E
- reason: flaky test on checkout flow
- approved_by: user
- expires_at: 2026-04-02
- follow_up:
  - nightly audit required
  - checkout E2E fix PR required

이 기록은 PR 코멘트, deployment report, 또는 별도 audit log 어디에 남기든 의미가 보존되어야 한다.

후속 검증 의무

bypass가 사용되면 아래 중 하나 이상이 반드시 따라야 한다.

  • nightly audit 자동 실행
  • post-deploy smoke test 강화
  • 후속 수정 PR 생성
  • rollback readiness 확인
  • FAILURE_LOG 또는 audit log 기록

threshold와의 관계

DOMAIN_THRESHOLD_MODEL.md에서 정의한 축 중 다음은 bypass 비용이 높다.

  • payment
  • auth
  • personal_data
  • migration_safety

이 축이 기준 미달일 때는:

  • 단순 conditional이 아니라
  • 추가 승인 필요 또는
  • 배포 금지

로 올릴 수 있다.

AITEM 기준 적용

AITEM에서는 bypass가 완전 금지가 아니라 강한 통제 하의 예외로 다뤄져야 한다.

예:

  • SKIP_E2E는 일반 기본값이 아니라 긴급 상황 전용
  • 사용 시 nightly audit 또는 후속 수정이 자동 연결되어야 함
  • 결제/인증/개인정보 관련 축 미달 상태에서는 bypass 허용 범위를 더 좁게 잡아야 함

즉 AITEM의 bypass는 "빠르게 넘기기"가 아니라 운영 비용을 명시적으로 떠안는 결정이어야 한다.

프로젝트 기본값 제안

기본 프로젝트

  • flaky test 우회 가능
  • staging bypass 허용 가능
  • production bypass는 명시 승인 필요

일반 SaaS

  • staging bypass 제한적 허용
  • production bypass 매우 제한적 허용
  • auth/api_contract 미달 시 추가 승인 필요

AITEM형 민감 서비스

  • bypass 사용 시 audit log 필수
  • production bypass는 강한 승인 + rollback readiness 필요
  • payment, auth, personal_data, migration_safety 축은 hard-fail 후보

Capability Matrix와의 연결

이 정책은 이후 PROJECT_CAPABILITY_MATRIX.md에서 아래처럼 관리한다.

  • bypass 허용 여부
  • bypass 기록 방식
  • audit 후속 의무
  • hard-fail domain 존재 여부

한 줄 결론

bypass는 허용 여부보다 기록, 승인, 후속 검증이 더 중요하다.
ai-rules는 우회를 "편의"가 아니라 감사 가능한 예외 절차로 다뤄야 한다.