Agentic AI Investigator: Starling Bank의 17초 자금세탁 경보 조사 에이전트, 무엇으로 믿을 수 있나

Starling Bank는 자금세탁 의심 경보 1건을 조사부터 결정까지 17초에 끝내는 에이전트를 자체 코어뱅킹 안에서 돌립니다. 이런 에이전트를 실제 업무에 쓰려면 속도보다 먼저 네 가지를 시험해야 합니다. 무엇을 놓치는지, 언제 사람에게 넘기는지, 기록이 실제 조사와 맞는지, 데이터가 끊겼을 때 어떻게 행동하는지입니다.

요약

영국 디지털 은행 Starling Bank는 거래 모니터링(transaction monitoring, 의심 거래를 규칙과 모델로 걸러 경보를 띄우는 체계) 경보를 받아 조사하고, 그 과정을 기록하고, 결정까지 내리는 agentic AI investigator(스스로 조사 단계를 밟는 AI 조사관)를 운영한다고 밝혔습니다. 경보 1건에 걸리는 시간은 17초입니다. 분석가에게 사건 요약을 건네는 보조 도구와 달리, 조사 전 과정을 맡아 결론까지 냅니다. 최고고객·뱅킹책임자 Bernadette Smith는 Finextra 인터뷰에서 이 에이전트가 자사 코어뱅킹 플랫폼 안에 들어 있다고 설명했습니다. 데이터와 모델을 은행이 직접 갖고 있어 실시간 텔레메트리, 과거 행동 패턴, 거래 맥락을 바로 조회하고, 외부 앱을 붙일 때 생기는 지연과 변경 요청 비용이 없다는 것입니다.

QA Financial의 Michiel Willems는 이 발표를 품질 보증(QA) 관점에서 읽습니다. 공개된 내용에는 17초를 어떻게 쟀는지, 어떤 경보 유형을 맡는지, 사람 승인이 어디에 남는지가 나와 있지 않다고 짚습니다. 또 Smith가 그린 미래상, 곧 분석가를 늘리거나 규칙 엔진을 빠르게 하는 대신 내장 AI 에이전트로 컴플라이언스를 한다는 구상은 17초라는 수치와 별개의 주장이라고 구분합니다. 둘 다 조사의 정확성이나 운영 회복력을 보여 주지는 않는다는 것입니다. 그래서 그는 시험 대상을 넷으로 좁힙니다. 놓친 증거, 상향 보고 시점, 기록의 충실도, 장애 때의 행동입니다. 아래에서는 이 네 가지를 시험 설계와 현업 운영 계획으로 풀어 봅니다.

핵심 메커니즘

Embedded Investigator: 코어뱅킹 안에 들어간 조사관

조사 에이전트를 별도 앱으로 두지 않고 계정·거래 원장이 있는 코어뱅킹 시스템 안에 넣는 방식입니다. 입력은 거래 모니터링이 띄운 경보입니다. 에이전트는 같은 플랫폼 안에서 실시간 텔레메트리, 그 고객의 과거 행동 패턴, 해당 거래의 맥락을 조회해 조사를 진행합니다. 출력은 조사 기록과 결정입니다. Smith가 든 이점은 데이터와 모델을 은행이 소유한다는 점과 외부 연동의 지연, 변경 요청, 외부 비용, 개발 제약이 없다는 점입니다. 이 구조는 코어 시스템을 직접 고칠 수 있는 은행에 맞습니다. 상용 코어뱅킹 위에 여러 시스템이 얽힌 은행이라면 데이터 접근 경로부터 따로 설계해야 합니다. 가상 예시로, 해외 송금 경보가 뜨면 에이전트가 같은 화면 뒤에서 그 고객의 최근 90일 송금 내역과 접속 기기 정보를 곧바로 읽는 식입니다.

Beyond Historical Agreement: 과거 판단과의 일치만으로는 부족하다

조사 에이전트를 평가할 때 가장 쉬운 방법은 이미 분석가가 닫은 경보를 다시 돌려 결론이 같은지 보는 것입니다. 원문은 이 방법만으로는 부족하다고 봅니다. 과거 분석가의 판단에도 오류와 불일치가 섞여 있어, 일치율이 높다는 것은 그 오류까지 따라 했다는 뜻일 수 있습니다. 그래서 시험 세트를 넓힙니다. 독립된 검토자가 다시 판정한 사례, 판단이 엇갈리는 모호한 사례, 정보가 빠졌거나 서로 모순되는 사례, 처음 보는 거래 패턴을 넣습니다. 과거 판단 일치는 출발점으로는 쓸모가 있습니다. 다만 그것만으로 운영 투입을 정하면 안 됩니다. 가상 예시로, 분석가들이 늘 정상 처리하던 소액 분할 입금 유형을 독립 검토자가 다시 보니 일부가 의심 사례였다면, 그 유형은 일치율이 높아도 따로 시험해야 합니다.

Process Fidelity: 결론이 맞아도 조사 과정이 맞는지 본다

결론이 맞았다고 조사가 제대로 됐다는 뜻은 아닙니다. 에이전트가 관련 증거를 놓치고도 우연히 맞는 결론을 낼 수 있고, 자기가 밟은 단계를 실제와 다르게 설명할 수도 있습니다. 원문은 자동으로 생성된 감사 기록(audit trail)이 있다고 해서 방어할 수 있는 절차가 되지는 않는다고 봅니다. 기록이 실제로 열어 본 증거, 실제로 취한 조치, 결정의 근거를 정확히 담고 있어야 합니다. 이를 확인하려면 에이전트가 쓴 기록과 시스템이 독립적으로 남긴 접근 로그를 대조해야 합니다. 기록에는 있는데 로그에는 없는 조회가 있으면 에이전트가 과정을 지어낸 것이고, 로그에는 있는데 기록에 없으면 근거를 숨긴 것입니다. 규제 당국이나 내부 감사가 결정 근거를 물을 때 이 대조 결과가 답이 됩니다.

Failure-First Testing: 데이터가 끊긴 상황을 일부러 만든다

Starling은 예전부터 일부러 장애를 일으키는 시험을 써 온 은행입니다. 원문은 같은 원리를 조사 에이전트에 적용합니다. 인프라 회복력과 판단 품질은 시험 방법이 다르지만, 둘 다 성공 시연에서는 드러나지 않는 조건을 마주해야 합니다. 시험할 조건은 넷입니다. 거래 데이터가 늦게 들어오는 경우, 고객 기록을 불러올 수 없는 경우, 조사가 중간에 끊기는 경우, 같은 경보가 두 번 오는 경우입니다. 에이전트는 정보가 빠졌다는 것을 알아차리고, 진행 상태를 보존하고, 사람에게 넘겨야 합니다. 빠진 데이터로 그럴듯한 완성 결론을 내면 실패입니다. 중단 뒤 재개할 때는 증거를 조용히 잃거나 조치를 두 번 하거나 기록과 결과가 어긋나서는 안 됩니다. 원문은 불확실성 처리, 상향 보고, 복구를 처음부터 워크플로에 넣어야 한다고 봅니다.

Shared Model Regression: 공유 모델이 바뀌면 사용처마다 다시 시험한다

Starling은 Nvidia와 함께 트랜잭션 파운데이션 모델(거래 데이터로 학습한 범용 모델)을 만들고 있습니다. 원문은 이 모델이 조사 에이전트와 다른 것이라고 분명히 합니다. 다만 여러 기능이 한 모델을 함께 쓰기 시작하면 시험 문제가 생깁니다. 사기 탐지를 좋게 하려고 모델을 고쳤는데 다른 기능의 동작이 바뀔 수 있습니다. 그래서 모델을 바꿀 때마다 영향을 받는 사용처별로 회귀 시험(이전에 통과한 사례가 여전히 통과하는지 다시 보는 시험) 증거를 남기고, 배포 뒤에도 성능 저하를 감시해야 합니다. 원문은 모델을 영국 안에서 호스팅한다는 사실만으로는 정확성이나 안정된 동작이 증명되지 않는다고도 덧붙입니다.

Local Validation: 증거는 은행을 옮겨 가지 않는다

Starling에는 코어뱅킹 플랫폼을 다른 은행에 파는 Engine 사업이 있습니다. 원문은 조사 에이전트가 Engine 고객에게 제공된다는 근거는 없다고 밝히면서도, 비슷한 방식을 다른 은행이 들일 때의 원칙을 짚습니다. 데이터 품질, 고객 행동, 시스템 연동, 조사 정책이 은행마다 다르므로 Starling에서 나온 증거를 그대로 옮겨 쓸 수 없습니다. 최신 시스템과 레거시가 섞인 은행에서는 Starling만큼 데이터 접근이 매끄럽지 않을 수 있습니다. 플랫폼을 도입해도 자기 서비스 안에서 그 동작을 시험할 책임은 도입한 은행에 남습니다. 국내 은행이 해외 솔루션의 조사 자동화 수치를 볼 때도 같은 원칙이 적용됩니다.

통념과 다른 주장

저자가 든 사례

Starling 조사 에이전트: 경보 1건을 17초에 결정까지

구분	내용
상황	거래 모니터링 경보를 분석가가 조사하는 업무
한 일	조사·기록·결정까지 하는 에이전트를 자체 코어뱅킹에 내장. 데이터와 모델은 은행 소유
결과	경보 1건 조사~결정 17초. 측정 방식, 경보 유형, 사람 승인 위치는 원문에서 밝히지 않음
연결	Embedded Investigator, Process Fidelity

컨설턴트 Geoff Kates는 이것이 정확하고 규모를 키울 수 있다고 확인되면 AI가 보조에서 조사관으로 옮겨 가는 것이라고 평했고, 광범위한 시험을 강조했습니다.

Starling의 chaos testing: 서버를 무작위로 끄던 은행

구분	내용
상황	클라우드 위에서 은행 플랫폼을 운영
한 일	사내에서 만든 chaos daemon이 AWS API로 서버를 무작위로 종료
결과	전 CTO Greg Hawkins는 실패를 일상적으로 겪게 하면 엔지니어가 실패를 전제로 설계하게 된다고 InfoQ 회고에서 설명
연결	Failure-First Testing. 원문은 같은 원리를 AI 조사의 불확실성·상향 보고·복구 설계에 적용

Nvidia와 만드는 트랜잭션 파운데이션 모델

구분	내용
상황	여러 기능이 쓸 거래 데이터 기반 모델이 필요
한 일	Nvidia와 함께 영국 sovereign cloud 안에서 학습·호스팅
결과	2027년 초 운영 예상. 사기 탐지에 먼저 쓰고 이후 AI Starling Assistant를 보강, 장기적으로 Starling Intelligence라는 공유 지능 계층 구상. 조사 에이전트와는 별개
연결	Shared Model Regression

Engine: 다른 은행에 파는 코어뱅킹 플랫폼

구분	내용
상황	레거시를 현대화하려는 미국 은행·신용조합 시장
한 일	Engine 최고경영자 Sam Everington은 올해 초점이 북미, 특히 미국이라고 Financial Times에 밝힌 것으로 전해짐
결과	그룹 최고경영자 Raman Bhatia는 Engine을 자산이 가볍고 규제 경계 밖에 있으며 수수료 수입과 회복력을 주는 사업으로 설명. 원문은 이것이 사업 모델의 회복력이지 은행이 입증해야 할 운영 회복력과는 다르다고 구분
연결	Local Validation. 조사 에이전트가 Engine 고객에게 제공된다는 근거는 원문에 없음

기술 디테일: 조사 에이전트를 시험 가능하게 만들려면

평가 세트를 세 층으로 짜려면 (Beyond Historical Agreement와 연결) 경보 유형별로 최소 200건 이상을 모읍니다. 첫 층은 분석가가 이미 닫은 경보, 둘째 층은 독립 검토자 두 명이 다시 판정해 합의한 경보, 셋째 층은 모호하거나 데이터가 빠졌거나 처음 보는 패턴의 경보입니다. 둘째 층에서 두 검토자가 갈린 사례는 버리지 말고 셋째 층으로 옮깁니다. 지표는 층마다 따로 냅니다. 의심 사례를 정상으로 닫은 비율(놓침)과 사람에게 넘긴 비율(상향 보고)을 핵심으로 보고, 전체 일치율은 참고만 합니다.

결정을 구조화 출력으로 받으려면 (Process Fidelity와 연결) 에이전트의 최종 출력을 자유 문장이 아니라 고정 스키마로 받습니다. 도구를 부를 때마다 evidence 항목이 하나씩 쌓이게 하고, 각 항목에 시스템 접근 로그와 같은 call_id를 붙입니다.

{
  "alert_id": "TM-2026-000123",
  "alert_type": "rapid_movement",
  "evidence": [
    {"call_id": "c-01", "source": "transactions", "query": "customer=…, last_90d", "rows": 42, "ts": "2026-11-14T09:00:03Z"},
    {"call_id": "c-02", "source": "device_history", "query": "customer=…", "rows": 0, "ts": "2026-11-14T09:00:05Z"}
  ],
  "missing_data": ["device_history 비어 있음"],
  "decision": "escalate",
  "rationale_refs": ["c-01"],
  "confidence": 0.62,
  "model_version": "inv-2026.11.1"
}

decision은 close, escalate, file_report 세 값만 허용합니다. missing_data가 비어 있지 않으면 close를 금지하는 규칙을 스키마 검증 단계에 둡니다. 매일 밤 evidence[].call_id와 접근 로그를 join해 한쪽에만 있는 호출을 불일치로 집계합니다. 불일치가 1건이라도 나오면 그 유형은 자동 결정을 멈춥니다.

편차를 재려면 (Process Fidelity와 연결) temperature를 0으로 두어도 도구 응답 순서나 시각에 따라 결과가 달라질 수 있습니다. 평가 세트의 각 경보를 3~5회 반복 실행해 decision이 한 번이라도 갈리는 경보 비율을 봅니다. 갈리는 경보는 그 자체로 모호한 사례 후보이므로 셋째 층에 넣고, 운영에서는 자동 결정 대상에서 뺍니다.

장애 주입 시험을 돌리려면 (Failure-First Testing과 연결) 시험 환경에서 데이터 피드와 API 앞에 장애 주입 계층을 둡니다. 거래 피드를 지연시키고, 고객 기록 API가 오류를 내게 하고, 조사 도중 프로세스를 죽이고, 같은 경보를 두 번 보냅니다. 재개 시 조치가 두 번 실행되지 않도록 모든 조치에 alert_id와 단계 번호로 만든 멱등 키(같은 요청을 여러 번 보내도 한 번만 처리되게 하는 키)를 붙입니다. 통과 기준은 장애 조건에서 close 결정 0건, 재개 후 기록과 결과 불일치 0건입니다.

모델을 바꿀 때는 (Shared Model Regression과 연결) 평가 세트 세 층을 회귀 시험 세트로 그대로 씁니다. model_version을 바꿀 때마다 사용처별로 놓침 비율과 상향 보고 비율을 이전 버전과 나란히 비교하고, 어느 한 사용처라도 놓침이 늘면 배포를 멈춥니다. 배포 뒤에는 주 단위로 상향 보고 비율, 사람이 에이전트 결정을 뒤집은 비율, 불일치 건수를 대시보드로 봅니다.

현업 실행 디테일: 누가, 언제, 무엇을

아래 역할과 일정은 원문에 없는 내용으로, 비슷한 에이전트를 들이려는 금융사가 실제로 돌릴 때 필요한 것을 정리한 가상 예시입니다.

역할	하는 일	산출물
자금세탁방지 책임자	에이전트가 맡을 경보 유형과 사람 승인 위치 결정	위임 범위 문서
조사 분석가 리드	독립 재검토, 모호 사례 선별, 오판 검토	평가 세트 2·3층
QA 엔지니어	장애 주입, 회귀 시험, 반복 실행 편차 측정	시험 결과표
데이터 엔지니어	접근 로그 확보, call_id 대조 파이프라인	일일 불일치 리포트
모델 리스크 관리	모델 변경 승인, 사용처별 회귀 결과 검토	변경 승인 기록
내부 감사	기록 표본 추출과 실제 접근 대조	감사 의견

시작 전 준비물: 최근 12개월 경보와 분석가 결정, 경보별 조사 메모, 시스템 접근 로그 보존 확인, 경보 유형 분류표, 현재 분석가 1건당 처리 시간 측정치(비교 기준)를 모읍니다. 17초 같은 수치를 내부에서 말하려면 무엇부터 무엇까지 쟀는지 정의도 먼저 정합니다.

인터뷰·확인 질문

• 이 경보 유형에서 분석가가 결론 전에 반드시 보는 데이터는 무엇인가?
• 판단이 가장 자주 갈리는 유형은 무엇이고, 그때 누가 최종 결정을 하나?
• 고객 기록이 비어 있을 때 지금은 어떻게 처리하나?
• 감사나 감독기관이 결정 근거를 물으면 어떤 자료를 내나?
• 에이전트 결정을 사람이 뒤집었을 때 그 기록은 어디에 남기나?

진행 판정 기준(가상 예시): 섀도 운영 4주 동안 평가 세트 2층의 놓침 비율이 분석가 기준보다 높지 않고, 장애 주입 시험에서 close 0건, 기록과 접근 로그 불일치 0건이면 해당 경보 유형에 한해 자동 결정을 켭니다. 하나라도 못 넘으면 에이전트는 조사와 기록만 하고 결정은 사람이 합니다.

적용 제언. 국내 은행·카드사·증권사에서는 의심거래보고 전 단계의 경보 조사가 첫 후보입니다. 순서는 이렇습니다. 먼저 경보 유형 가운데 판단 기준이 분명하고 건수가 많은 저위험 유형 하나를 고릅니다. 에이전트에게는 조사와 기록만 맡겨 분석가의 준비 시간을 줄이고, 그동안 평가 세트와 접근 로그 대조 체계를 만듭니다. 결정 위임은 판정 기준을 넘긴 유형부터 하나씩 엽니다. 코어뱅킹을 직접 고치기 어려운 조직이라면 Starling식 내장 대신 읽기 전용 데이터 계층을 먼저 만들어 에이전트가 볼 데이터와 남길 로그를 한곳에 모으는 편이 현실적입니다. 경영진 보고에서는 처리 시간과 함께 놓침 비율, 상향 보고 비율, 기록 불일치 건수를 한 장에 나란히 보여 줘야 합니다.

원문 사례

항목	내용
원문	QA Financial, Michiel Willems, 2026년 11월 9일
대상	Starling Bank(영국 디지털 은행)의 agentic AI investigator
발표 내용	거래 모니터링 경보 1건을 조사·기록·결정까지 17초
구조	자체 코어뱅킹 플랫폼에 내장, 데이터와 모델 은행 소유(Bernadette Smith, Finextra 인용)
공개되지 않은 것	17초 측정 방식, 맡는 경보 유형, 사람 승인 위치
외부 평가	컨설턴트 Geoff Kates: 정확하고 규모를 키울 수 있으면 보조에서 조사관으로, 광범위한 시험 강조
시험 제언	독립 검토·모호·불완전·모순·낯선 사례, 기록과 실제 접근 대조, 데이터 지연·고객 기록 없음·조사 중단·중복 경보 시험
관련 사례	chaos daemon(AWS API로 서버 무작위 종료, 전 CTO Greg Hawkins)
관련 계획	Nvidia와 트랜잭션 파운데이션 모델, 영국 sovereign cloud, 2027년 초 운영 예상, 조사 에이전트와 별개
사업 맥락	Engine(미국 은행·신용조합 대상), Sam Everington, Raman Bhatia 발언

핵심 개념

Transaction monitoring

거래를 규칙이나 모델로 살펴 자금세탁·사기 의심 거래에 경보를 띄우는 체계입니다.

AML

Anti-Money Laundering. 자금세탁을 막기 위한 은행의 고객 확인, 거래 감시, 보고 업무를 묶어 부르는 말입니다.

Core banking platform

계좌, 거래 원장, 고객 정보를 다루는 은행의 중심 시스템입니다.

Audit trail

누가 언제 무엇을 보고 어떤 조치를 했는지 남긴 기록입니다. 나중에 결정의 근거를 설명할 때 씁니다.

Chaos testing

운영 환경과 비슷한 곳에서 서버나 네트워크를 일부러 망가뜨려 시스템이 버티는지 보는 시험입니다.

Sovereign cloud

데이터와 처리가 특정 국가 안에 머물도록 운영하는 클라우드입니다.

Escalation

자동 처리 대상에서 빼고 사람에게 넘기는 것입니다. 여기서는 정보가 모자라거나 판단이 모호할 때의 올바른 행동입니다.

Engine

Starling이 자사 코어뱅킹 기술을 다른 은행에 제공하는 사업입니다.

내 메모

TODO: 내 생각 추가

원문은 QA Financial 「Starling’s 17-sec AI sleuth puts QA on the clock」(Michiel Willems, 2026.11.9)입니다. Bernadette Smith의 설명은 원문이 Finextra를, Sam Everington의 발언은 Financial Times를, Greg Hawkins의 설명은 InfoQ 회고를 인용한 것을 다시 옮겼습니다. 요약, 핵심 메커니즘의 원문 내용, 통념과 다른 주장, 저자가 든 사례는 원문이 언급한 내용을 AX Partners가 다시 정리했습니다. 기술 디테일의 스키마·설정값·통과 기준, 현업 실행 디테일의 역할·일정·판정 기준, 적용 제언, 인포그래픽과 표는 실제로 돌릴 때 필요한 것을 새로 작성한 가상 예시입니다. 전체 내용은 원문에서 볼 수 있습니다.