확장 가능한 KYC 심사 큐 설계

KYC 심사 큐는 기계가 스스로 처리하지 못한 신원 확인 건을 사람 앞에 올려놓는 백오피스 워크플로입니다. 대부분의 신청은 자동으로 통과되어야 하고, 큐는 그렇지 못한 건을 위해 존재합니다. 설계 목표는 큐를 작게 유지하는 것, 즉 진짜 모호한 건만 담는 것입니다. 기계가 판단했어야 할 건으로 가득 찬 큐는 통제 수단이 아니라 가입자 수에 비례해 커지는 병목이기 때문입니다. 큐를 제대로 설계하면 백오피스는 거래량이 아니라 예외 건수에 맞춰 확장됩니다.

의도적으로 작게 유지한다는 이 하나의 원칙이 이후의 모든 결정을 좌우합니다. 먼저 큐를 작게 유지하는 구분부터 보겠습니다.

목표는 스트레이트 스루, 큐는 예외

스트레이트 스루 처리(STP)는 신청이 사람의 손을 거치지 않고 처음부터 끝까지 완료되는 것을 뜻합니다. 문서 판독, 신원 대조, 제재 및 PEP 스크리닝 이상 없음, 라이브니스 통과, 결정 기록까지 모두 자동으로 이루어집니다. 이것이 일반적인 경로여야 하며, 이 경로를 타는 신청의 비율인 STP 비율이 큐가 확장 가능한지를 알려 주는 단일 지표입니다. 90퍼센트 이상이 자동 통과되면 사람이 보는 큐는 감당 가능한 수준의 소량이 되지만, 절반이 심사로 떨어지면 성장 속도에 맞춰 심사 인력을 채용해야 합니다. 큐는 KYC가 이루어지는 곳이 아닙니다. 자동화된 KYC가 확신하지 못한다고 인정하는 곳입니다. STP 비율을 높이면 다른 모든 지표가 저절로 개선됩니다. 큐에 쌓이는 건이 줄고, 대기 시간이 짧아지고, 채용할 심사 인원도 줄어듭니다. 직접 개선할 가치가 충분합니다. 클라이언트에서의 문서 촬영 품질을 높이고, 촬영 전에 더 명확히 안내하고, 과도하게 보수적인 규칙 때문에 정상 고객이 거절되지 않도록 매칭 임계값을 조정하십시오. 여기서 회복한 1퍼센트포인트마다 누군가의 오후를 차지할 건이 하나 사라집니다.

큐에 들어오는 건과 그 이유

심사로 넘어오는 건에는 구체적이고 명명 가능한 사유가 있으며, 이 사유가 각 건이 지닌 가장 중요한 속성입니다. 문서 사진이 너무 흐려서 읽을 수 없는 경우, 신분증의 이름이 신청서의 이름과 다른 경우, 제재 또는 PEP 스크리닝에서 사람이 확인하거나 기각해야 할 잠재 일치가 나온 경우, 주소를 어떤 출처로도 검증할 수 없는 경우, 라이브니스 확인에 실패했거나 동일한 얼굴이나 문서가 이미 다른 계정에 존재하는 경우가 그렇습니다. 각각 필요한 작업과 판단의 종류가 다른데, 이를 구분 없이 하나의 더미에 섞는 것이 심사 큐가 저지르는 첫 번째 실수입니다. 같은 사유라도 무게는 크게 다를 수 있습니다. 이름 불일치는 결혼 후 성이 바뀐 대수롭지 않은 차이일 수도 있고 신분 도용의 첫 징후일 수도 있습니다. 큐의 역할은 그 차이를 구분할 수 있는 사람에게 건을 보내는 것이며, 신중한 판단이 필요한 건에 즉흥적인 결론을 강요해서는 안 됩니다.

하나의 큐로는 부족합니다: 사유별로 분리

큐가 하나이면 모든 심사자가 제너럴리스트여야 하고, 모든 건이 관련 없는 건 뒤에서 기다려야 합니다. 사유별로 나누면 두 문제가 모두 해결됩니다. 제재 잠재 일치 큐는 스크리닝과 처리 방식을 교육받은 인력이 맡고, 문서 품질 큐는 주니어 심사자가 몇 초 만에 끝내는 빠른 육안 확인이며, 중복 계정 큐는 사기 조사 업무입니다. 각 세그먼트는 고유한 라우팅, 필요 역량, 서비스 수준 목표를 가집니다. 흐릿한 사진은 몇 분 안에 해결해야 하지만, 실제 제재 적중 건은 서두르지 않고 신중하게 처리해야 하기 때문입니다. 세분화를 통해 처리량과 엄격성이 맞바꾸는 관계가 아니라 공존할 수 있게 됩니다.

검토 대기열은 검토자를 늘린다고 확장되지 않습니다. 애초에 검토가 필요 없는 건을 정확히 가려내고, 검토가 필요한 건은 사유별로 분류된 상태로 도착하게 할 때 확장됩니다.

사유 필수, 감사 가능한 조치

검토자가 내리는 모든 결정(승인, 거절, 에스컬레이션, 추가 서류 요청)에는 반드시 사유가 필요하고 기록이 남아야 합니다. 나중에 덧붙이는 자유 서술이 아니라, 조치를 취하는 시점에 그 이유를 구조화된 선택지로 남겨야 합니다. 이는 형식적인 절차가 아니라 대기열을 방어 가능하게 만드는 장치입니다. 규제 기관, 감사인, 또는 이후의 검토자가 플래그가 있었는데 왜 계정을 승인했는지 물으면, 답은 얼버무림이 아니라 검토자 실명, 타임스탬프, 명시된 사유여야 합니다. 감사 추적은 추가 전용(append-only)이므로 결정을 사후에 조용히 고쳐 쓸 수 없고, 정정은 기존 기록을 덮어쓰는 수정이 아니라 새 항목으로 남습니다. 우리 스택에서는 이 대기열과 감사 모델이 운영자 콘솔인 Protocore Center(/products/center)에 있습니다. 모든 권한 있는 조치에 사유가 필요하며, 몰래 변경할 수 없는 로그에 기록됩니다.

four-eyes 대상 건

어떤 결정은 한 사람이 내리기에는 영향이 너무 큽니다. 실제 제재 대상 적중 건을 해소하거나, 고위험 프로필을 승인하거나, 자동 거절을 번복하는 경우에는 두 번째 검토자의 확인이 필요해야 합니다. 이것이 maker-checker, 즉 four-eyes 원칙입니다. 첫 번째 검토자가 사유와 함께 제안하면, 권한을 가진 두 번째 검토자가 사유를 밝히며 확인하거나 거절합니다. 두 조치 모두 기록됩니다. 검토자를 불신해서가 아니라, 위험도가 가장 높은 승인일수록 단 한 번의 실수가 가장 큰 비용을 낳고, 두 번째 시선이 그에 대한 가장 저렴한 보험이라는 인식에서 나온 방식입니다. 대기열은 검토자의 기억에 맡기지 말고, 사유에 따라 이런 건을 자동으로 2단계 처리로 보내도록 설계해야 합니다. 다만 2단계 처리는 중대한 건에만 의도적으로 적용하십시오. 모든 건에 적용하면 대기열 전체의 비용이 두 배가 되고, 검토자가 두 번째 서명을 형식적으로 찍게 되어 이중 승인의 취지가 조용히 무너집니다.

물량에 대비한 설계: 에이징, 우선순위, SLA

늘어나기만 하는 대기열은 실패한 대기열입니다. 대기열이 계속 흘러가도록 압력을 설계에 넣어야 합니다. 건의 에이징(경과 시간)을 눈에 보이게 하여 잊힌 채 방치되는 건이 없도록 하고, 세그먼트마다 서비스 수준 목표를 두어, 수 분 단위 SLA를 넘긴 흐릿한 사진 건과 더 긴 SLA 안에 있는 제재 건이 서로 다르게 드러나게 합니다. 우선순위는 실질적인 선택입니다. 오래된 건부터 처리하는 방식은 공정하고 단순하지만, 잠재 노출이 가장 큰 건을 먼저 보는 위험 우선 방식이 더 적절한 경우가 많습니다. 이때 에이징을 동점 기준으로 써서 저위험 건도 굶지 않고 처리되게 합니다. 검토자 화면은 골라 가는 목록이 아니라, 이미 라우팅과 우선순위가 정해진 다음 건을 보여 줘야 합니다. 사람이 골라 가는 대기열에서는 까다로운 건이 끝내 선택되지 않기 때문입니다. 에이징이 보이지 않는 대기열은 조용히 썩습니다. 어려운 건은 바닥에 가라앉고 쉬운 건만 위에서 돌아가는데, 이를 드러낼 유일한 지표인 가장 오래된 미결 건의 경과 시간은 고객이 항의하기 전까지 아무도 보지 않는 숫자입니다.

대기열 측정

네 가지 숫자로 설계가 제대로 작동하는지 알 수 있습니다. STP 비율은 사람의 손이 필요 없었던 건이 얼마나 되는지 보여 줍니다. 대기열 깊이와 그 추세는 처리 속도가 유입을 따라가는지 뒤처지는지 알려 줍니다. 세그먼트별로 SLA와 비교해 추적하는 결정까지의 시간은 고객이 온보딩을 너무 오래 기다리고 있는지 보여 줍니다. 그리고 나중에 뒤집힌 결정의 비율인 재오픈율은 검토자가 정확하게 판단하는지, 아니면 빠르게만 판단하는지 알려 줍니다. 이 지표들은 서로 상충하므로 함께 봐야 합니다. 재오픈율이 오르는데 결정까지의 시간만 줄었다면, 실수를 대가로 속도를 산 것입니다. 건강한 대기열은 규모가 작고, 계속 움직이며, 정확하게 결정하고, 아직 열려 있는 건에 대해 솔직합니다.

사람들이 떠올리는 백오피스, 즉 직원들이 방 가득 앉아 신청서를 일일이 입력하는 모습은 자동화가 너무 적게 처리하고 대기열이 구분 없는 하나의 더미일 때 나타납니다. 확장되는 백오피스는 그 반대입니다. 대부분의 신청은 사람에게 가지 않고, 가는 건은 사유와 우선순위별로 분류되어 도착하며, 모든 조치는 사유와 함께 추가 전용 로그에 남고, four-eyes가 필요한 결정은 이중으로 확인합니다. 대기열을 예외 처리용으로 만들면 성장해도 작게 유지됩니다. KYC가 일어나는 장소로 만들면 가입자가 늘 때마다 함께 커집니다.