KYC 에이전트가 합격/불합격(pass/fail)을 직접 결정해서는 안 되는 이유

전체 KYC(Know Your Customer) 검토에는 컴플라이언스(Compliance) 팀이 영업일 기준 7~10일이 소요됩니다. 우리가 구축하는 에이전트는 동일한 기초 작업을 10분 이내에 수행합니다. 그 부분은 쉽습니다. 어려운 부분은 규제 기관이 그 결과물을 수용할 수 있도록 구축하는 것이며, 모델이 아닌 바로 그 제약 사항이 여러분의 아키텍처(Architecture)를 결정합니다.

"KYC 자동화" 내부에 숨겨진 엔지니어링 문제는 라우팅(Routing) 문제입니다. 어떤 결정은 LLM(Large Language Model)으로 보내고, 어떤 것은 규칙 엔진(Rules engine)으로, 어떤 것은 ML(Machine Learning) 모델로 보내며, 어떤 것은 절대 인간을 떠나지 않게 할 것인가의 문제입니다. 경계 설정을 잘못하면 쓸모가 없거나(인간이 여전히 모든 것을 수행함) 불법적인(모델이 규제 보고서를 제출함) 결과물을 출시하게 됩니다. 대부분의 팀은 동일한 방식으로 이 경계를 잘못 설정합니다.

요약 (TL;DR)

KYC/AML(Anti-Money Laundering) 자동화는 단일 에이전트가 아니라 계층화된 파이프라인(Pipeline)입니다. 5개 계층: 추출(Extraction) → 스크리닝(Screening) → 스코어링(Scoring) → 내러티브(Narrative) → 인간 대기열(Human queue).
전체 시스템이 의존하는 단 하나의 결정 사항: LLM은 절대 최종 판결을 내리지 않습니다. LLM은 추출하고 초안을 작성할 뿐입니다. 규칙과 ML이 결정하며, 인간이 최종 승인합니다.
실제 수치: 추출 5분 → 10초 미만; 전체 검토 7~~10일 → 10분 미만 + 인간 검토; 구축 기간은 한 관할 구역(Jurisdiction)당 10~~14주, 추가 관할 구역당 4~6주가 소요됩니다.
어려운 부분은 ML이 아닙니다. 감사 추적(Audit trail), 오탐(False-positive) 피드백 루프, 그리고 관할 구역별 규칙 세트(Rulesets)입니다. 이 세 가지 모두 첫날부터 설계에 반영되어야 합니다.
자율적인 SAR(Suspicious Activity Report, 의심 거래 보고) 제출은 미국, 영국, EU에서 불법입니다. "초안 작성 및 제시(Draft and present)" 방식으로 구축하되, 절대 "초안 작성 및 제출(Draft and submit)" 방식으로 만들지 마십시오.

이것이 단순한 래퍼(Wrapper)가 아닌 실제 엔지니어링 문제인 이유

유혹에 빠지기 쉽습니다. 이를 프런티어 모델(Frontier model) 위의 얇은 계층으로 취급하는 것입니다. 문서, 거래 내역, 제재 목록(Sanctions list)을 입력하고 "이 고객이 위험한가요?"라고 묻는 식입니다. 이렇게 하면 주말 사이에 제품을 출시할 수 있을 것 같아 보입니다.

그러한 설계는 모델의 품질과는 전혀 상관없는 이유로 실제 운영 환경에서 실패합니다. LLM은 동일한 입력에 대해서도 일관되지 않은 답변을 내놓으며, 컴플라이언스 (Compliance) 분야는 동일한 입력에 대해 항상 동일한 결정과 그에 따른 근거가 도출되어야 하는 영역이기 때문입니다. 모호한 거래 내역을 채팅 모델에 두 번 실행하면, 한 번은 "의심스러움"이라고 하고 다른 한 번은 "의심스럽지 않음"이라고 답할 수 있습니다. 규제 기관이 왜 한 고객은 플래그(flag)를 지정하고, 동일한 다른 고객은 지정하지 않았는지 물었을 때, 그 답변이 샘플링 온도 (Sampling temperature) 때문이라고 한다면 받아들여질 수 있는 답변은 없습니다.

따라서 모델이 판결을 직접 내려서는 안 됩니다. 하지만 모델은 판결을 내리기 '주변'의 업무에는 진정으로 탁월하며, 그 업무가 분석가 업무 시간의 60~70%를 차지합니다. 이러한 분리를 진지하게 받아들임으로써 전체 아키텍처 (Architecture)가 완성됩니다.

핵심 추상화: 각 레이어에 허용된 결정 권한

파이프라인은 다섯 개의 레이어로 축소되며, 중요한 것은 각 단계에서 어떤 도구가 결정을 내릴 수 있도록 허용되는가 하는 점입니다.

레이어	역할	도구	결정 가능 여부?
1. 문서 추출 (Document extraction)	신분증, 주소 증명서, 등록 서류에서 필드 추출	LLM / VLM	아니요 — 구조화된 데이터 생성
...

한 줄로 요약한 원칙: 추출과 초안 작성에는 LLM을, 결정에는 규칙 (Rules)과 머신러닝 (ML)을, 최종 승인에는 인간을 사용하십시오. 여러분의 규칙 엔진 (Rules engine)은 제재 대상 일치 여부를 환각 (Hallucination)하지 않을 것입니다. 여러분의 LLM은 프롬프팅 (Prompting) 없이 원시 JSON으로부터 일관된 서사를 작성하지 못할 것입니다. 각 레이어는 자신이 틀릴 리 없는 일을 수행합니다.

본론: LLM이 제 역할을 다하는 곳

레이어 1 — 문서 추출 (Document extraction)

여권에서 이름, 생년월일, 문서 번호, 만료일을 읽어내는 작업은 분석가에게 5분의 시간이 소요됩니다. 비전 모델 (Vision model)은 필기체 필드, 비라틴 문자, 저화질 스캔본을 포함하여 10초 이내에 이를 수행합니다. 하루에 100개의 문서를 처리한다면, 매일 7~8시간의 분석가 업무 시간을 확보할 수 있습니다.

여기서의 설계 결정은 **자유 텍스트가 아닌 스키마 제약 출력 (Schema-constrained output)**입니다. 추출 결과는 다시 파싱 (Parsing)해야 하는 산문이 아니라, 검증 가능한 타입 객체 (Typed object)를 반환합니다.

from dataclasses import dataclass
from datetime import date

...

confidence < 0.85라는 코드는 단순한 세부 사항이 아닙니다. 그것은 인간 작업 큐(Human queue)에 얼마나 많은 업무가 할당될지를 결정하는 다이얼이며, 여러분은 이를 조정하기 위해 수개월을 보낼 것입니다 (보정(Calibration)에 대해서는 아래에서 더 자세히 다룹니다).

레이어 2 — 스크리닝(Screening), LLM이 매칭하고 규칙이 결정하는 단계

OFAC, UN, EU, 그리고 HM Treasury 목록에는 다양한 음차(Transliteration)와 별칭(Alias)으로 된 이름들이 포함되어 있습니다. 정확히 일치하는 것만 찾는 규칙 엔진(Rules engine)은 목록에 "Muhammad Al Rasheed"라고 되어 있을 때 "Mohammed Al-Rashid"를 놓치게 됩니다. LLM은 이러한 변형을 자연스럽게 처리합니다.

하지만 대부분의 팀이 경계를 흐리는 지점이 바로 여기입니다: LLM은 후보 매칭(Candidate match)을 제안하고, 모델이 아닌 규칙 엔진이 스크리닝 결과(Screening result)를 기록해야 합니다. 모델의 역할은 재현율(Recall, 실제 매칭을 놓치지 않는 것)이며, 결정론적 레이어(Deterministic layer)가 기록된 결정과 증거를 소유해야 합니다.

def screen_name(name: str, sanctions_list: list[SanctionsEntry]) -> ScreeningResult:
    # LLM은 음차/별칭 전반에 걸쳐 후보를 제안합니다 — 높은 재현율(High recall).
    candidates = llm_name_match(name, sanctions_list)
...

레이어 4 — 내러티브 생성 (Narrative generation)

에이전트는 가공되지 않은 점수(Raw score)를 반환하는 대신, 다음과 같이 사례를 작성합니다: "이 엔티티는 고위험 관할 구역에 등록된 주소를 가지고 있으며, 실소유자(UBO)는 OFAC SDN 목록의 이름 변형과 일치하고, 3분기 부정적 미디어(Adverse-media) 언급 중 두 건이 해당 국가의 규제 조사를 참조하고 있음." 분석가는 숫자가 아닌 맥락(Context)을 전달받습니다. 의심거래보고(SAR) 초안 작성만으로도 보고 건당 2~~3시간을 절약할 수 있으며, 월 10건의 SAR를 작성한다면 매달 20~~30시간을 확보하게 됩니다.

내러티브는 결정의 일부가 아니라 결정의 결과물(Downstream)입니다. 이는 레이어 1~3의 구조화된 출력(Structured outputs)을 읽고 이를 설명합니다. 내러티브는 결론을 절대 다시 심판(Re-litigate)하지 않습니다.

아무도 경고해주지 않는 부분들

이 지점이 프로젝트의 실제 성패가 갈리는 곳입니다. 이 중 어느 것도 모델 작업이 아닙니다.

1. 감사 추적(Audit trail)은 스키마(Schema) 결정이지, 사후에 추가하는 로깅(Logging)이 아니다

FinCEN (미국), FCA (영국), 그리고 AMLD6 (EU)는 컴플라이언스 (Compliance) 분야에서 AI 사용을 금지하지 않습니다. 대신 이들은 설명 가능성 (Explainability)과 인간의 책임 (Human accountability)을 요구합니다. 규제 심사 (Regulatory exam) 시, 귀하는 특정 사례에 대한 전체 결정 추적 (Decision trail)을 제출하라는 요구를 받게 될 것입니다. 즉, 고려된 모든 증거, 모든 추론 단계, 모든 인간의 개입 사항이 타임스탬프 (Timestamp)와 함께 기록되어 있어야 합니다.

"모델이 그렇게 말했다"는 규제 기관이 받아들일 수 있는 답변이 아닙니다. 이는 추론 과정이 첨부되지 않은 채 점수만 반환하는 에이전트는 자산이 아니라, 운영 환경 (Production)에 배포된 부채 (Liability)라는 것을 의미합니다. 이를 사후에 보완하는 것은 매우 고통스러운 작업입니다. 결정 기록 (Decision record)을 먼저 설계하고, 모든 계층이 이를 기록하도록 만드십시오:

@dataclass
class DecisionRecord:
    case_id: str
...

model_version (모델 버전)에 유의하십시오. 6개월 후에 추출 모델 (Extraction model)을 업그레이드했을 때, 규제 기관이 문제를 제기하는 결정이 어떤 버전에 의해 생성되었는지 알아야 합니다. 모델 버전을 데이터베이스 마이그레이션 (Database migration)처럼 취급하십시오. 즉, 추론 과정에서 추적 가능하고, 날짜가 기록되며, 되돌릴 수 있어야 합니다.

2. 오탐 (False positives)은 도입 단계의 문제이며, 해결책은 피드백 루프 (Feedback loop)이다

초기 AML (자금세탁방지) 경보 시스템은 약 95%의 합법적인 거래를 잘못 식별하는 것으로 악명이 높았습니다. 업계 분석(McKinsey, 원문 인용 — 인용 전 출처 재확인 필요)에 따르면, 대부분의 은행에서 거래 모니터링 (Transaction-monitoring) 경보의 90% 이상이 오탐입니다. 하루에 1,000건의 거래를 검토하는 에이전트의 오탐률이 10%라면, 컴플라이언스 팀에 매일 100건의 잘못된 경보를 전달하게 됩니다. 그들은 일주일 안에 해당 시스템을 신뢰하지 않게 될 것입니다.

유일한 해결책은 분석가의 결정이 모델로 다시 들어가는 루프를 만드는 것입니다. 만약 첫날부터 "분석가가 이 경보를 무시함"과 같은 사항을 라벨링된 학습 데이터 (Labeled training data)로 캡처하지 않는다면, 오탐률은 결코 개선되지 않으며 출시 당시의 상태로 고착될 것입니다. 에이전트 시스템 (Agentic systems)은 제재 경보 (Sanctions alerts)의 55~75%를 자동으로 해결할 수 있지만, 이는 오직 해당 루프가 구축되었을 때만 가능합니다. 이것은 3분기에 급하게 덧붙이는 기능이 아니라, 데이터 파이프라인 (Data-pipeline) 차원의 약속입니다.

3. 글로벌 표준이 아닌 관할 구역별 규칙 세트

FinCEN이 요구하는 사항은 FCA가 요구하는 사항도 아니며, AMLD6가 요구하는 사항도 아닙니다. 만약 하나의 글로벌 규칙 세트 (ruleset)를 구축한다면, 한 시장에서는 과잉 준수 (over-compliant)를 하게 되어 온보딩 전환율 (onboarding conversion)을 떨어뜨리는 동시에, 다른 시장에서는 미준수 (under-compliant) 상태가 되어 실제적인 리스크를 초래하게 됩니다. 스크리닝 (screening) 및 스코어링 (scoring) 레이어는 관할 구역 (jurisdiction)별로 매개변수화 (parameterized)되어야 하며, 각 케이스별로 해결되어야 합니다. 설령 하나의 규칙 세트로 시작하더라도 여러 규칙 세트를 고려하여 구축하십시오. 나중에 그 경계(seam)를 추가하는 데는 막대한 비용이 듭니다.

4. 자동화가 법적으로 금지된 단 한 가지

자율적인 의심거래보고 (SAR) 제출은 미국, 영국, EU에서 불법입니다. SAR을 제출하기 전에는 반드시 지정된 개인이 승인해야 합니다. SAR의 내용을 미리 채우고 초안을 작성하는 에이전트는 가치가 있습니다. 하지만 SAR을 직접 제출하는 에이전트는 규제 사고 (regulatory incident)입니다. 이에 따른 아키텍처적 결과는 다음과 같습니다: 레이어 5는 선택 사항이 아니며, "제출 (submit)" 동작은 서비스 계정 (service account)이 아닌 인간의 신원 (human identity)을 통해 제어되어야 합니다.

시퀀싱 (Sequencing): 다섯 개의 레이어를 한꺼번에 구축하지 마세요

한 번의 스프린트 (sprint) 안에 전체 스택 (full stack)을 출시하려는 팀은 3개월 동안 아무것도 출시하지 못합니다. 반면, 하나의 레이어를 출시하고 검증한 뒤 확장해 나가는 팀은 12~16주 안에 프로덕션 시스템 (production system)을 갖추게 됩니다. 다음 순서대로 구축하십시오:

1~4주 차 — 문서 추출 (Document extraction) 전용. 가장 높은 처리량, 가장 낮은 복잡도, 개별 KYC 케이스를 다룹니다. 라벨링된 데이터 세트(labeled set)를 기준으로 추출 정확도를 검증하십시오. 감사 추적(audit trail)이 실제로 유지되는지 확인하십시오. 신뢰도가 낮은(low-confidence) 경로가 케이스를 상담원 대기열(human queue)로 제대로 전달하는지 확인하십시오.
5~8주 차 — 제재(Sanctions) + PEP 스크리닝. 규칙 엔진(rules engine)을 연결하십시오. 알려진 참/거짓 일치 사례(true/false matches)를 바탕으로 MATCH_THRESHOLD를 조정하십시오. 분석가의 재량 결정(analyst overrides)을 지금부터 기록하기 시작하십시오. 이것이 향후 여러분의 학습 데이터(training data)가 됩니다.
9~12주 차 — 리스크 점수 산정 (Risk scoring). 일반적인 모델이 아닌, 여러분의 과거 결정 데이터를 바탕으로 학습시키십시오. 점수와 함께 기여 신호(contributing signals)를 출력하십시오.
12~16주 차 — 서술형 보고서(Narrative) + SAR 초안 준비. 마지막 단계입니다. 이는 위의 모든 과정이 구조화되고 신뢰할 수 있어야 가능하기 때문입니다. 요구 사항이 유의미하게 다른 관할 구역(jurisdiction)이 추가될 때마다 4~6주를 더하십시오. 그리고 화려하지는 않지만 필수적인 전제 조건이 있습니다: 기술적인 구축을 마친 후가 아니라, 구축 전에 컴플라이언스 법률 고문(compliance counsel)과 협의하십시오. 여기서는 요구 사항이 아키텍처(architecture)를 정의합니다. 규제가 진정으로 스키마(schema)를 주도해야 하는 몇 안 되는 구축 사례 중 하나입니다. 동일한 시스템에서 결제 데이터(payment data)를 다루고 있다면, 이러한 사전 제약 조건 준수 원칙은 앱 빌더를 위한 당사의 PCI DSS 노트에서도 확인할 수 있습니다.

캘리브레이션(Calibration)이 진정한 지속적 과업입니다

이 시스템을 구동하는 두 가지 임계값(threshold)이 있습니다: 추출 신뢰도(extraction confidence, 레이어 1)와 매칭 점수(match score, 레이어 2)입니다. 두 값 모두 초기에는 추측값으로 시작하여, 실제 운영 데이터(production data)를 바탕으로 수개월 동안 조정 과정을 거칩니다. 추출 신뢰도를 너무 높게 설정하면 모든 데이터가 사람에게 전달되어 자동화가 전혀 이루어지지 않은 상태가 됩니다. 반대로 너무 낮게 설정하면 잘못된 필드(garbage fields)가 심사 결정에 포함됩니다. 매칭 점수에서도 동일한 긴장이 발생합니다. 재현율(recall)을 높게 잡으면 잘못된 탐지(false hits)가 대기열을 가득 채우게 되고, 정밀도(precision)를 높게 잡으면 실제 제재 대상(sanctions) 매칭을 놓치게 되는데, 이는 경력을 끝낼 수도 있는 치명적인 오류 유형입니다. 정답인 고정값은 존재하지 않습니다. 곡선이 존재할 뿐이며, 피드백 루프(feedback loop)가 성숙해지고 분석가들이 어디에서 문제가 발생하는지 알려줌에 따라 그 곡선을 따라 이동하게 됩니다. 만약 실제 배포(rollout)를 앞두고 있다면, 우리가 운영 AI를 위해 사용하는 12주 MVP 시퀀싱(the 12-week MVP sequencing we use for production AI)이 위의 레이어 순서와 깔끔하게 매칭됩니다.

마치며

전체 설계는 하나의 경계에 달려 있습니다: LLM은 결코 판결(verdict)을 소유해서는 안 된다는 것입니다. 만약 이 점에 동의한다면, 다섯 가지 레이어는 거의 저절로 작성될 것입니다. 만약 동의하지 않는다면 — 즉, 충분히 좋은 모델이라면 적절한 가드레일(guardrails) 하에 합격/불합격(pass/fail)을 결정하도록 허용되어야 한다고 생각한다면 — 그 부분은 설계 검토(design review)에서 진지하게 논쟁해보고 싶은 지점입니다. 왜냐하면 팀들이 스스로를 설득하여 구축한 시스템이 나중에 규제 기관(regulator)에 의해 무너지는 것을 보아왔기 때문입니다.

다른 곳에 인용하기 전에 한 가지 주의할 점이 있습니다. 오탐(false-positive) 및 경고 해결(alert-resolution) 수치(90% 이상의 오탐, 55-75%의 자동 해결)는 원문 포스트를 통해 McKinsey의 자료를 따르고 있으므로, 규제 기관이나 이사회에 제시하기 전에 반드시 직접 출처를 확인하십시오. 타임라인과 시간 절감 수치는 실제 구축 사례에서 나온 것이지만, 귀하의 관할 구역(jurisdiction) 혼합에 따라 수치는 달라질 것입니다. 다른 사람들은 LLM과 규칙(rules) 사이의 경계선을 어디에 긋는지, 특히 이름 매칭(name matching)에 있어서는 어떠한지 궁금합니다. 그 부분은 제가 설정한 경계가 유일하게 방어 가능한 경계인지 가장 확신이 서지 않는 레이어입니다.