# 심사에 머물러 있는 세션과 줄이는 방법

Source: https://help.didit.me/ko/verification-sessions/session-in-review
Updated: 2026-10-12

In Review는 자동 검사가 끝났지만 사람이 승인, 거절, 재제출을 결정해야 한다는 뜻이며 저절로 해결되지 않습니다.

**In Review는 저절로 해결되지 않습니다.** 검사가 무언가를 감지해 팀원의 승인, 거절, 재제출 요청을 기다리고 있다는 뜻입니다.
심사 비율이 높다면 원인은 거의 항상 너무 빡빡하게 설정된 임곗값이지, 사기가 아닙니다.

[Video: 태그, 상태, 세션 채팅: 팀으로 케이스 검토하기 - Didit Academy](https://www.youtube.com/watch?v=bRkH0agxVDc)

> **Warning:** **Didit은 세션을 검토하지 않습니다.** 검토 중 상태의 세션은 Business Console에서 귀사 팀의 담당자를 기다리고 있으며, Didit에서는 아무도 보고 있지 않습니다. Didit 쪽에는 대기열도 예상 소요 시간도 없습니다. 귀사 팀의 누군가가 결정할 때까지 검토 중 상태로 남습니다.

모든 상태 중에서 **In Review**는 지원 문의를 가장 많이 만들어내는 상태입니다. 이유는 단순합니다. 플랫폼이 아직 작업 중인 것처럼 보이지만, 실제로는 플랫폼이 작업을 끝내고 여러분을 기다리고 있는 상태이기 때문입니다.

## In Review가 실제로 의미하는 것

자동화된 검사는 모두 실행되었습니다. 그중 하나 이상이 자동 판정이 아니라 심사로 보내지도록 워크플로우가 설정된 경고를 발생시켰습니다. 이제 이 세션은 사람이 해결할 때까지 큐에 머무릅니다. 시간이 지나면 자동으로 판정되는 타임아웃도 없고, 시스템이 검사를 다시 실행해 스스로 마음을 바꾸게 할 방법도 없습니다.

## 세션 정리하기

1. **심사 큐 열기**

   **신원 확인 → 사용자 인증 → 검토 필요** 또는 **받은편지함 → 결정**을 여세요. A는 승인, D는 거절, R은 재제출 요청, J/K는 이동입니다. 확인 전에 대화상자를 검토하세요.

2. **상태뿐 아니라 경고를 읽기**

   세션을 열고 어떤 검사가 플래그를 세웠는지, 경고에 뭐라고 적혀 있는지 확인하세요. 이것이 실제로 결정해야 할 내용을 알려줍니다. [검증 결과를 읽는 방법](https://help.didit.me/ko/verification-sessions/reading-a-verification-result)을 확인하세요.

3. **결정하기**

   승인, 거절, 또는 실패한 단계만 재제출 요청 중 하나를 선택하세요. 메모를 추가하면 감사 추적의 일부가 됩니다.

4. **백엔드에 알리기**

   결정이 내려지면 `status.updated` webhook이 발생하므로, 수동으로 대조하지 않아도 시스템이 최종 상태를 반영합니다.

![Didit 콘솔에서 Verifications 목록을 In Review 상태로 필터링한 화면](https://help.didit.me/screenshots/sessions-bulk-light.webp)

*큐를 처리하려면 Verifications를 In Review로 필터링하세요.*

## 심사 비율이 높은 이유

대략 다음 순서로 흔합니다.

1. **얼굴 대조 임곗값 간격이 너무 좁음.** 심사 구간이 넓으면 평범한 조명 차이도 그 구간에 걸립니다. [얼굴 대조 점수와 임곗값](https://help.didit.me/ko/liveness-biometrics/face-match-thresholds)을 확인하세요.
2. **AML 심사 임곗값이 낮은 일치 점수로 설정됨.** 흔한 이름은 낮은 일치 점수에서도 후보 히트를 생성합니다. 심사 임곗값을 너무 낮게 설정하면 거의 모든 사람이 심사로 넘어갑니다. [AML 히트 해결하기](https://help.didit.me/ko/aml-screening/resolving-aml-hits)를 확인하세요.
3. **주소 증명 부분 일치.** 주소 형식은 국가마다 크게 다르므로, 축약 표기 차이가 부분 일치로 읽힙니다. 부분 일치를 심사로 보낼지 통과시킬지 의도적으로 결정하세요.
4. **데이터베이스 검증 부분 일치.** 원인은 같습니다. 공신력 있는 출처에 다르게 기록된 이름입니다.
5. **정당한 재방문 사용자에 대한 중복 얼굴 플래그.** 같은 실제 사람이 두 번 이상 검증하면 자기 자신과 일치하게 됩니다. [중복 탐지](https://help.didit.me/ko/verification-sessions/duplicate-detection)를 확인하세요.
6. **"안전을 위해" 모든 경고를 심사로 보냄.** 모든 것을 심사하는 것은 아무것도 심사하지 않는 것과 같습니다. 큐가 처리되지 않게 되기 때문입니다. 정말 판단이 필요한 경고만 선별하세요.

## 워크플로우를 재배치해 더 일찍, 더 저렴하게 심사하기

흐름이 비싸고 그럼에도 많은 세션이 결국 심사로 가고 있다면, 저렴한 리스크 검사를 앞쪽으로 옮기면 비싼 검사가 실행되기 전에 흐름을 멈출 수 있습니다. 전체 KYC 흐름 앞에 $0.03짜리 기기 및 IP 분석을 두면, 어차피 통과하지 못했을 트래픽에 대한 지출을 줄일 수 있습니다.

트레이드오프는 사용자 경험입니다. 첫 단계에서 멈춘 사람은 아무것도 투자하지 않았지만, 왜 그런지도 알지 못합니다. 어느 쪽이 여러분의 퍼널에 더 중요한지 결정하세요.

## Four-eyes 심사

케이스 관리와 2인 검토가 활성화된 경우 두 번째 검토자의 확인이 필요합니다. 사용 여부는 케이스 설정과 권한에 따라 달라집니다.

## In Review가 아닌 것

- **"아직 처리 중"이 아닙니다.** 플랫폼이 끝나기를 기다리는 중이라면 원하는 상태는 In Progress입니다.
- **소프트 거절이 아닙니다.** In Review 세션에는 아직 아무 판정도 없으므로, 자체 시스템에서 이를 "거절됨"으로 매핑하지 마세요. 별도의 대기 상태로 매핑하세요.
- **지원팀이 대신 결정해 줄 수 있는 것이 아닙니다.** 여러분의 고객을 승인하거나 거절할 권한은 오직 여러분의 팀에만 있습니다. 지원팀은 세션이 왜 플래그되었는지 설명해 줄 수 있으며, 그러려면 `session_id`가 필요합니다.

## 상시 모니터링이 승인된 세션을 다시 심사로 되돌릴 수 있습니다

AML 모니터링을 활성화해 두었다면, 일일 재스크리닝에서 심사 임곗값을 넘는 새 히트가 발견될 때 이전에 승인된 세션이 나중에 In Review로 이동할 수 있습니다. 이는 예상된 동작이지 회귀 버그가 아니며, 모니터링의 존재 목적 자체입니다. [상시 AML 모니터링](https://help.didit.me/ko/aml-screening/ongoing-monitoring)을 확인하세요.