리스크 티어(Risk tiers)

FDAI가 내리는 모든 결정이 자동 실행되어야 하는 것은 아닙니다. 리스크 티어는 컨트롤 플레인이 작업을 자동 실행할지, 사람 승인(hil 결정)을 기다릴지, 아니면 거부할지 결정하는 방식입니다.

세 가지 결정

제안된 모든 작업에는 위험 분류가 포함됩니다. FDAI는 이벤트, 대상 리소스, 환경, 작업에 선언된 영향 범위(계약의 blast_radius 필드)를 바탕으로 위험을 분류합니다. 분류 결과는 다음 세 가지 중 하나로 결정됩니다:

• AUTO: 직접 실행해도 안전할 만큼 위험이 낮습니다. 감사 기록에는 여전히 누가, 무엇을, 언제, 왜를 기록합니다.
• 사람 승인(hil): 운영자가 승인해야 합니다. FDAI는 실행을 멈추고 Teams, 재인증이 구성된 Slack, 수정 pull 요청 검토처럼 신원을 확인할 수 있는 채널로 요청을 보냅니다.
• DENY: 강제 규칙이 요청 주체와 관계없이 작업을 거부합니다. BreakGlass는 deny를 hil이나 auto로 바꾸지 않습니다. 정책이 허용한 긴급 승인에 참여할 자격만 임시로 줍니다.

shadow_only는 네 번째 결정이 아니라 실행 모드입니다. 결정을 계산하고 기록하지만 대상을 바꿀 수는 없습니다. abstain은 또 다릅니다. 판단 티어가 어떤 결정도 뒷받침하지 못해서, 실행 없이 검토를 위해 보류한다는 뜻입니다.

최종 판정 계산 방식

먼저 위험 분류 테이블을 평가합니다. 규칙은 deny, 사람 승인(hil), auto, 마지막으로 사람 승인을 요청하는 기본 규칙 순서로 평가합니다. 처음 일치한 규칙이 기준 결정이 됩니다.

FDAI는 이 기준 결정을 신뢰 티어, ActionType, 선언된 영향 범위와 실시간 영향 범위, 호출자 역할, 환경, 컨트롤 플레인 상태에서 오는 자율성 상한과 비교합니다. 가장 엄격한 결과를 선택합니다. 상한은 자동 실행을 사람 승인, 관찰 전용 모드, 거부로 낮출 수 있지만 기준 결정보다 자율성을 높일 수는 없습니다.

예시: 되돌릴 수 있고 단일 리소스에 한정된 변경이 auto 규칙과 일치해도 인벤토리 그래프가 오래되었다면 안전성 검토가 거부합니다. Owner 역할이나 더 허용적인 ActionType 상한도 이를 hil 또는 auto로 다시 높일 수 없습니다.

사람 승인이 필요한 조건

다음 조건은 사람 승인이 필요할 가능성을 높이거나 자율성 상한을 낮춥니다.

• 영향 범위: 프로덕션, 다중 리전, 공유 테넌시 대상은 격리된 개발 리소스보다 훨씬 자주 승인을 요구합니다.
• 되돌릴 수 있는지 여부: 명확한 롤백 경로가 없는 데이터 마이그레이션이나 리소스 삭제는 기본적으로 사람 승인을 요청합니다.
• 새로움: 트러스트 라우터가 T2로 올린 결과에는 더 엄격한 상한이 적용됩니다. T2 결과는 품질 검토를 통과해도 관찰 전용(shadow_only)입니다.
• 신호 신뢰도: 합성된 이상 신호는 검증된 정책 위반보다 낮게 평가됩니다.

자동 실행에 필요한 7개 보호장치

실행 가능한 모든 작업은 다음 7개 보호장치를 모두 갖춰야 합니다.

1. 중단 조건: 환경이 예상과 다르게 반응하면 변경을 멈추는 측정 가능한 상태입니다.
2. 롤백 경로: 미리 계산하고 테스트했으며 감사 기록에서 참조할 수 있습니다.
3. 영향 범위 제한: 범위, 배치 크기, 처리 속도에 명시적인 상한을 둡니다.
4. Dry-run receipt: 정확한 대상과 개정 버전에 대해 성공한 what-if 결과입니다.
5. 논리 대상 잠금: 같은 대상의 다른 작업과 충돌하지 않도록 실제 변경을 확정할 때까지 유지합니다.
6. 멱등성 키: 전달을 재시도해도 중복 실행을 막는 안정적인 키입니다.
7. 2단계 감사: 실제 변경 전에 의도를 추가 전용으로 기록하고, 실행 및 독립적으로 관찰한 결과를 포함해 최종 종결 기록을 남깁니다.

보호장치가 하나라도 없으면 작업은 불완전하며 실행할 수 없습니다. 사람 승인으로 누락된 안전 계약을 메울 수는 없습니다. ActionType을 고치고 검증한 뒤에야 파이프라인에 다시 들어갈 수 있습니다.

더 안전한 쪽을 고르는 사례

상위 프로젝트 기본값은 불확실할수록 자율성을 낮춥니다.

상황	결과	이유
정책 검증기가 작업을 거부	거부	이 경로에서는 사람 승인이 결정론적 정책 결과를 면제할 수 없음
인벤토리 그래프가 오래됨	거부	영향 범위가 오래된 관계를 기준으로 계산될 수 있음
구독 전체 범위의 변경	거부	자동 변경은 구독 전체에 걸쳐 실행할 수 없음
되돌릴 수 없는 작업	사람 승인, 정족수 2명	서로 다른 승인자 두 명이 필요하며 자기 승인은 불가
환경이 누락되거나 인식되지 않음	프로덕션으로 처리	누락된 메타데이터가 위험을 낮출 수 없음
월별 비용 영향이 알려지지 않음	사람 승인	알 수 없는 비용은 설정된 자동 임계값 이상으로 처리
어떤 규칙과도 일치하지 않음	사람 승인	기본 규칙이 더 안전한 사람 검토를 선택

승인 대기 중에 일어나는 일

사람 승인이 필요한 결정이 내려지면 대기 중인 작업을 저장하고 제어권을 이벤트 루프에 돌려줍니다. 신원을 확인할 수 있는 채널에는 권한 자체가 아니라 내부 정보를 노출하지 않는 승인 참조를 전달합니다. 승인자가 응답하면 API는 작업을 재개하기 전에 승인자를 다시 인증하고 작업 해시, 멱등성 키, 역할, 정족수, 유효 기간(TTL), 자기 승인 금지 규칙을 검사합니다.

승인하면 동일한 대기 작업을 정확히 한 번만 재개합니다. 거부와 시간 초과는 모두 실행하지 않고 감사 기록에 남깁니다. 중복되거나 충돌하는 응답은 작업을 다시 실행할 수 없습니다. 이메일, SMS, 호출 시스템은 승인 대기 사실을 알릴 수 있지만 승인 결정을 제출할 수는 없습니다.

저하 및 긴급 상태

컨트롤 플레인 상태도 자율성을 낮추기만 하는 상한입니다. 필수 의존성에 문제가 생기면 관련 작업을 shadow_only 또는 거부로 제한합니다. 운영자 비상 정지도 안전한 범위에서 판단과 감사를 유지하면서 변경을 막습니다. 의존성이 복구되어도 작업을 조용히 적용 모드로 전환하지 않고 정상적인 위험 평가를 다시 수행합니다.

운영자 제어도 경계 안에서 동작

권한 있는 운영자는 대기 중인 작업을 거부하거나 비상 정지를 활성화할 수 있습니다. 규칙 재정의는 카탈로그에서 코드로 관리하는 별도의 제어입니다. 제한된 범위에서 승인된 규칙 하나의 적용 범위를 좁히거나, 자율성 수준을 낮추거나, 비활성화할 수 있습니다. 자율성을 높이거나 원래 발견된 문제를 지우거나 거부 결정을 우회할 수는 없습니다. 모든 제어 작업은 감사 기록에 남습니다.

과거 결정을 설명하는 근거

감사 기록에는 일치한 위험 규칙, 결정 당시의 특성 벡터 스냅샷, 위험 카탈로그 버전, 필요한 정족수, 모든 자율성 상한, 최종적으로 적용된 가장 엄격한 축, 최종 실행 경로가 포함됩니다. 이 resolved_ceiling 근거를 사용하면 현재 설정으로 다시 계산하지 않고도 “왜 사람 승인이 필요했는가?”와 “무엇이 자동 실행을 막았는가?”를 확인할 수 있습니다.

다음 단계

학습 대상	문서
라우터가 어떤 티어를 고르는지	deterministic-first-ko.md
새 작업이 관찰에서 자동 실행으로 넘어가는 방식	관찰 모드-then-enforce-ko.md
사람 승인의 일상 운영자 관점	../guides/approve-change-ko.md
전체 리스크 분류 규정	../../roadmap/decisioning/risk-classification-ko.md
자율성 상한과 승인 재개 계약	../../roadmap/decisioning/execution-model-ko.md