# 결정 규칙과 임계값

Source: https://help.didit.me/ko/workflows/decision-rules
Updated: 2026-10-12

경고마다 통과, 검토, 거절 중 하나를 매핑합니다. 거절은 워크플로우를 중단시켜 이후 단계와 과금이 없으므로 순서가 곧 비용입니다.

각 단계는 자신의 **경고**를 통과, 검토, 거절 중 하나의 액션에 매핑합니다. 거절로 구성된 단계는 **워크플로우를 중단시키므로** - 이후 단계는 절대 실행되지 않고, 그에 대한 과금도 없습니다. 그래서 규칙 순서는 위험 결정인 동시에 비용 결정이기도 합니다.

[Video: 조건부 워크플로: AML 위험 점수로 사용자 라우팅 - Didit Academy](https://www.youtube.com/watch?v=Qp3qzFDvTC8&t=91)

## 결정이 실제로 이루어지는 곳

워크플로우를 "내가 실행하는 검사들"로만 생각하기 쉽습니다. 하지만 검사는 절반에 불과합니다. 나머지 절반 - 그리고 승인율을 결정하는 절반 - 은 각 검사의 **경고**가 무엇을 하도록 설정되어 있는가입니다.

![기능 노드와 Publish 버튼이 있는 Didit 워크플로우 빌더](https://help.didit.me/screenshots/workflow-builder-light.webp)

*각 노드는 자신의 결과를 결정하고, 워크플로우는 그것이 무엇을 의미하는지 결정합니다.*

모든 단계에 대해, 발생할 수 있는 각 경고는 세 가지 액션 중 하나에 매핑됩니다.

| 액션 | 효과 |
|---|---|
| **Approve**(또는 무시) | 경고는 기록되지만 결과를 바꾸지 않음 |
| **Review** | 세션이 In Review로 이동해 사람이 판단 |
| **Decline** | 세션이 거절되고 워크플로우가 중단됨 |

이 매핑이 곧 구성으로 표현된 여러분의 정책입니다.

## 거절은 워크플로우를 중단시킵니다

이는 사람들을 가장 놀라게 하는 동작이므로 명확히 짚고 넘어갈 가치가 있습니다. 어떤 단계가 거절되면 실행은 그 자리에서 멈춥니다. 그 이후의 단계는 **절대 실행되지 않습니다**.

두 가지 결과가 따릅니다.

1. **결과에는 예상했던 검사가 빠져 있을 것입니다.** 실패한 것이 아니라 애초에 실행되지 않은 것입니다. 신분증 인증 단계에서 거절된 세션에는 라이브니스도, 얼굴 일치도, AML도 없습니다.
2. **그에 대한 과금이 없습니다.** 과금은 완료된 기능 단위이므로, 실행되지 않은 단계는 비용이 들지 않습니다.

## 규칙 순서로 비용 제어하기

거절이 플로우를 중단시키므로, 단계 순서는 지출을 조절하는 지렛대입니다. 비용이 큰 묶음 앞에 저렴한 위험 검사를 배치하면, 어차피 통과하지 못했을 트래픽이 비싼 부분에 비용이 들기 전에 멈추게 됩니다.

$0.03짜리 기기 및 IP 분석을 전체 KYC 플로우 앞에 두는 것이 표준적인 예입니다. 어차피 거절할 트래픽을 저렴하게 걸러냅니다.

> **Warning:** 여기서 절충되는 것은 사용자 경험과 오탐(false positive)입니다. 기기 및 IP 신호는 Didit이 제공하는 검사 중 가장 노이즈가 많습니다 - 기업 네트워크, 통신사 NAT, 클라우드 브라우저는 모두 정상 사용자를 공유 주소 뒤에 놓습니다. 전체 플로우를 여기에 걸어 거절로 두면 실제 고객까지 차단하게 되므로, 자체 트래픽을 직접 측정하지 않았다면 거절이 아니라 **검토**로 라우팅하세요.

## 자동화보다 판단이 필요한 규칙

일부 경고는 명확하며 거절해야 합니다. MRZ 체크섬 실패, 발급 기관까지 체인이 이어지지 않는 칩 서명, 블록리스트에 있는 얼굴 등입니다. 이런 것들은 무결성 실패입니다.

반면 다음은 거의 언제나 검토가 더 낫습니다.

- 주소 증빙에서의 부분 주소 일치 - 형식이 국가마다 다릅니다.
- 데이터베이스 검증에서의 부분 이름 일치 - 공식 출처마다 이름 기록 방식이 다릅니다.
- 신뢰도가 낮은 AML 후보 히트 - 흔한 이름은 계속해서 이를 발생시킵니다.
- 경계선상의 얼굴 일치 - [얼굴 일치 점수와 임계값](https://help.didit.me/ko/liveness-biometrics/face-match-thresholds)을 참고하세요.
- 중복 얼굴 플래그 - 신규 계정이라면 사기이고, 재방문 고객이라면 정상입니다.

그리고 일부는 판정이 아니라 **재시도**가 어울리는 사용성 문제입니다. 읽히지 않은 NFC 칩, 흐릿한 캡처, 끊긴 카메라 프레임 등입니다.

## 연령 정책

최소 연령과 최대 연령은 워크플로우별로 설정하며, 위반 시 어떤 액션을 취할지는 여러분이 선택합니다. `MINIMUM_AGE_NOT_MET`은 곧바로 거절할 수도 있고, 정책상 증빙과 함께 예외를 허용한다면 검토로 라우팅할 수도 있습니다. 둘 다 타당한 선택이니 신중하게 고르세요.

## 추출된 데이터에 대한 커스텀 규칙

경고별 매핑 외에도, 단계가 추출한 데이터를 기준으로 규칙을 작성할 수 있습니다. 예를 들어 추출된 필드가 특정 값을 가질 때 거절하는 식입니다. 두 가지를 기억하세요.

- 규칙은 해당 단계가 실제로 생성한 데이터에 대해서만 작동할 수 있습니다. OCR이 그 필드를 추출하지 못했다면 규칙이 판단할 대상이 없습니다.
- 거절하는 규칙도 위와 동일하게 워크플로우를 중단시킵니다.

보호 대상 특성(protected characteristic)을 기준으로 작동하는 규칙을 만들고 있다면, 엔지니어링 문제이기 전에 컴플라이언스 팀과 함께 검토해야 할 법률적 문제로 다루세요.

## 단계뿐 아니라 규칙도 테스트하세요

워크플로우의 단계는 눈으로 보고 쉽게 검증할 수 있습니다. 규칙은 그렇지 않습니다 - 경고가 생각한 대로 라우팅되는지 아는 유일한 방법은 실제로 그 경고를 발생시켜 보는 것입니다.

샌드박스는 바로 이를 위해 존재합니다. 각 시나리오는 특정 경고 하나를 강제하므로 각 규칙의 액션을 처음부터 끝까지 확인할 수 있습니다. `decline_document_expired`, `review_face_match_borderline`, `decline_aml_hit`, `review_poa_partial_match` 등이 있습니다. [샌드박스에서 테스트하기](https://help.didit.me/ko/getting-started/sandbox-and-testing)를 참고하세요.

> **Tip:** 거절 경로만큼이나 **검토** 경로도 꼼꼼히 테스트하세요. 검토로 라우팅되는 규칙은 실제로 누군가 그 큐를 처리할 때만 쓸모가 있으며, 여러분의 검토 프로세스가 실제로 작동하는지 알아보는 방법은 실제 고객이 기다리기 전에 합성 세션을 그 경로로 통과시켜 보는 것입니다.

## 변경 사항은 새 세션에 적용됩니다

워크플로우를 수정해도 이미 생성된 세션에는 소급 적용되지 않습니다. 세션은 생성 당시의 구성을 그대로 유지하므로, 규칙을 변경한 뒤에는 기존 세션을 다시 확인하지 말고 **새** 세션으로 테스트하세요.