출처 https://youtu.be/tUoO4ucrNc0 · 채널 Claude (Code w/ Claude 행사) · 길이 27:52 발표자 Stefano Amorelli — qonto Senior Staff Software Engineer 포맷 슬라이드·아키텍처 도표·코드·라이브 데모가 섞인 anthropic 컨퍼런스 발표. 금융범죄 수사 2차 방어선을 AI로 자동화한 실전 사례를 보안·컴플라이언스 관점에서 정리 원본 자막: 2026-07-12-fighting-financial-crime-with-claude-cowork (raw/transcripts, 기계 생성) · 관련 이정표: moc-ai-agents · moc-ai-agents-harness
한눈에 보는 요약
- 금융범죄는 금융업의 1순위 문제다. 전 세계에서 매년 2~5조 달러가 세탁되고, AI 덕에 “나쁜 놈들”도 점점 정교해진다. Qonto(프랑스 기반 핀테크, SME 대상 온라인 비즈니스 뱅킹, 고객 60만+·유럽 8개+ 시장)는 이 문제의 2차 방어선(수동 수사 단계)을 AI로 공략한다.
- 수사의 병목은 “판단”이 아니라 “정보 수집·정리”다. 수상한 거래 → 자동 알림(1차 방어선, 예측 AI/전통 ML) → 알림 생성 시 사람이 케이스를 집어 우선순위를 매기고 구글 검색·서드파티 툴·내부 대시보드 등 수십 개 탭을 오가며 데이터를 모아 큰 문서를 만든 뒤 판단한다. 몇 시간씩 걸리는 이 수작업을 Opus 4.7 기반 플러그인이 “몇 분 안에, 하나의 인터페이스에서” 끝내게 한다.
- 모델은 Opus 4.7, UI는 Claude Cowork. 수사 한 건은 수십만 토큰의 잡다한 증거 뭉치라, 흩어진 사실을 잇는 롱컨텍스트 추론이 결정적이다. GraphWalks 벤치마크에서 Opus 4.7이 시장 선두(1M 컨텍스트에서 흩어진 사실 연결)이고, Cowork는 비기술 조사관도 쉽게 온보딩되며 스킬+툴+MCP를 묶은 복잡한 플러그인을 실을 수 있다.
- 핵심 명제: “데이터 접근이 이걸 작동시키고, 경계(boundary)가 그 접근을 정당화한다.” 아무리 똑똑한 모델도 데이터에 접근 못 하면 쓸모없다 → 데이터 접근 = MCP. 하지만 MCP는 보안·컴플라이언스 팀의 눈살을 찌푸리게 한다(“MCP의 S는 Security를 뜻한다”는 농담). 해법은 보안·컴플라이언스를 처음부터 설계에 넣는 것 — 경계를 만들고 규정 준수·보안 하네스를 구현한다.
- 아키텍처의 심장은 MCP Gateway다. Claude Cowork(조사관 UX) → MCP Gateway(SSO·PASETO·RBAC·Audit = “신뢰 경계”) → 언어 불문 federated 다운스트림 MCP 서버들(knowledge-base·osint·internal-db·kyc-kyb·backend-api…) → 내부 API. 게이트웨이가 인증·역할기반 접근제어(RBAC)·감사(append-only 로그)를 한곳에서 처리하므로, 새 데이터 소스를 붙이면 감사·신원관리·RBAC가 자동으로 딸려 온다.
- 다섯 가지 제약을 처음부터 못 박았다: OAuth 2.1 + SSO(신원 전파) · 짧게 사는 PASETO 토큰(유출돼도 안전, 폐기 가능) · RBAC(중앙 정책, Terraform으로 버전 관리) · 감사(append-only, 구조화) · 중요 결정엔 HITL(사람이 판단 유지 — 법적 책임 때문). 다운스트림 MCP 서버는 Kubernetes에 배포돼 게이트웨이로만 접근 가능하고 stateless streamable HTTP로 손쉽게 확장한다.
- 플러그인은 “오케스트레이터 + 원자적 서브스킬” 구조 + evals로 신뢰를 증명한다. 1000줄짜리 프롬프트 대신 서브스킬로 쪼개고, XML 구조화 프롬프트에 각 스킬이 쓸 MCP/툴을 명시하며, 마지막엔 메타 스킬(case-self-review)이 결과를 검증한다. evals는 ① 올바른 툴을 올바른 순서로 부르는가(F1·tool selection) ② 응답이 실제 데이터에 grounded 됐는가 ③ 맞는 답을 맞는 이유로 냈는가(LLM-as-a-judge)를 측정한다.
- 이 패턴은 금융범죄 밖에서도 플라이휠이 된다. MCP Gateway와 첫 플러그인이 생기자 다른 팀들이 같은 게이트웨이·MCP 서버를 재사용해 자기 플러그인을 며칠 만에 만든다. 감사·RBAC·강한 인증·신원관리가 기본 제공되니, 큰 조직에서 보안·컴플라이언스를 지키며 AI 도입을 가속한다. 최종 비전은 HITL → human-on-the-loop → human-out-of-the-loop로, evals로 정확도를 입증하며 단계적으로 올라가는 것.
장면별 상세 설명
[00:20] 1. 발표자와 Qonto — 금융범죄의 규모
발표자는 Qonto의 Senior Staff Software Engineer인 Stefano Amorelli다. Qonto는 프랑스에 기반을 둔 핀테크로 중소기업(SME) 대상 온라인 비즈니스 뱅킹과 금융 도구를 제공하며, 고객이 60만 명 이상이고 유럽 8개국 이상에서 운영한다. 금융업에 몸담아 봤다면 알겠지만 금융범죄는 1순위 우선과제다. 규모 감을 주자면 전 세계에서 매년 2조~5조 달러가 세탁되는데, 범죄자에게는 큰 비즈니스이고 AI 덕분에 “나쁜 놈들”도 점점 능숙해지고 있다 — 다만 이를 막는 쪽도 마찬가지로 발전하고 있다. 발표의 주제는 Qonto가 AI·클라우드로 어떻게 보안과 컴플라이언스를 최우선으로 하는 시스템을 만들어, 매우 민감한 데이터를 다루는 크리티컬한 환경에 AI를 적용했는가다.
[02:29] 2. 금융범죄 수사의 라이프사이클 — 수작업이 몇 시간
수사는 다섯 단계로 흐른다: Alert(룰 엔진 + ML 스코어) → Open case(분석가가 컨텍스트를 끌어모음) → Enrich(거래·KYC/B·OSINT·독점 데이터) → Reason(교차 출처 평가) → Decide(HITL 리뷰·결정). 누군가 수상한 거래를 하면 완전 자동화된 알림 시스템이 경보를 만들고, 그 순간부터 수작업이 시작된다. 사람 조사관이 케이스를 집어 우선순위를 매기고, 구글 웹 검색·서드파티 툴·내부 대시보드 등 수많은 출처에서 데이터를 긁어모은다. 실제 금융 조사관은 모니터를 최소 3대씩 켜고 수십 개의 브라우저 탭을 띄운 채 문서를 모아 큰 보고서를 만들고, 일부는 머릿속에 일부는 적어가며 그 정보 위에서 추론해 범죄 행위인지 판단한다. 매우 수동적이고 오래 걸리는, 사실상 “비인간적인” 과정이다. 슬라이드 하단이 이를 요약한다 — “수동 수사는 몇 시간이 걸린다. 분석가는 여러 툴에서 컨텍스트를 끌어와 손으로 패턴을 찾는다. 우리는 Opus 4.7을 활용하는 Claude 플러그인을 만들어, 분석가가 하나의 인터페이스에서 몇 분 만에 수사를 끝내게 했다.”
[04:15] 3. AI 도입 곡선 — 3단계 중 “2차 방어선”을 노린다
AI 적용을 세 단계로 나눈다. Phase 1 · Assistants(범용 도구): 문서 요약, SAR(의심거래보고서) 섹션 초안 작성 등 범위가 한정된 일반 사용. 조직의 AI 리터러시를 키우고 결과물을 신뢰하도록 가르친다. Phase 2 · Native AI(1차 방어선): 모든 거래에 실시간 ML 스코어링. 빠르고 결정적이며 좁다. 새로운 게 아니라 이미 자리 잡은 베이스라인으로, 여기서는 생성형 AI가 아니라 예측 AI(전통 머신러닝) + 결정론적 룰이 주인공이고 속도·정확도가 중요해 Gen AI는 최적이 아니다. Phase 3 · Agentic AI(2차 방어선): 다단계 추론·툴 사용·롱컨텍스트가 필요한 영역으로, 바로 Claude Cowork가 앉는 자리다. 업계에서 이 단계(수동 수사)에 에이전틱 AI를 도입한 곳은 많지 않다. 발표는 이 Phase 3에 집중한다.
[05:25] 4. 왜 Opus 4.7 + Claude Cowork인가
모델 선택은 쉬웠다 — Opus 4.7. “수사 한 건은 수십만 토큰의 뒤섞인 증거이고, 모델은 그 안에서 잘 추론해야 한다”는 부제 아래 세 축을 든다. Long Context: 수사 한 건의 데이터가 100만 토큰 컨텍스트 윈도우에 들어간다. Judgment: Opus 4.7은 거래·KYC·과거 케이스·공공 기록이 뒤섞인 큰 컨텍스트에서 추론하는 데 탁월하다. Atomic Skills: 메인 스킬을 진입점으로 두고 원자적 서브스킬을 붙인 Claude 플러그인은 유지·확장·평가가 쉽다. 발표자는 “코딩을 포함해 모든 일에 Opus 4.7이 필요한 건 아니고 더 싼 모델로 버틸 수도 있지만, 이렇게 많은 정보를 다루려면 긴 컨텍스트를 가로질러 추론할 수 있는 모델이 필요하고 지금 시장에 그보다 나은 프론티어 모델은 없다”고 못 박는다. Cowork를 조사관용 UI로 쓴 이유는 ① 비기술 이해관계자도 쉽게 온보딩되고 ② 여러 스킬과 툴·MCP 서버를 묶은 복잡한 플러그인을 만들기에 강력해서다.
[06:48] 5. 롱컨텍스트를 숫자로 — GraphWalks 벤치마크
왜 Opus 4.7이 이런 작업에서 빛나는지를 수치로 보여준다. GraphWalks 벤치마크는 LLM이 문서를 가로질러 추론하며 곳곳에 흩어진 사실을 찾아내는 능력을 측정한다 — 컨텍스트 윈도우에서 서로 가까이 있는 사실이 아니라, 전체 컨텍스트에 걸쳐 있는 연결을 찾아내는 능력이다. 정보가 사실상 컨텍스트 전역에 흩뿌려진 수사에서 딱 봐야 할 벤치마크이고, Opus 4.7이 현재 시장 선두다. 차트(“Long-context reasoning · GraphWalks”)는 두 지표를 비교한다: Parents 1M — Opus 4.7 75.1 vs Opus 4.6 71.1, BFS 1M — Opus 4.7 58.6 vs Opus 4.6 41.2. 슬라이드 좌측 문구 그대로 “1M 컨텍스트 윈도우에서 비할 데 없는 추론”이다.
[07:41] 6. 발표의 명제 — 데이터 접근과 경계
핑크색 “The thesis” 슬라이드가 발표의 중심 명제를 던진다 — “데이터 접근이 이걸 작동시킨다. 경계(boundaries)가 그 접근을 얻어내는 방법이다.” 아무리 모델이 똑똑해도 데이터에 접근할 수 없으면 멋지지도 유용하지도 않다. “데이터 접근”이라고 하면 떠오르는 답을 청중에게 묻자 여기저기서 “MCP”라는 답이 나온다. 그런데 MCP를 리스크·컴플라이언스·보안 팀에 꺼내면 눈썹이 올라간다(“MCP의 S가 Security(보안)를 뜻한다”는 농담까지 있다). 하지만 이 우려는 해결할 수 있다 — 보안 우선·컴플라이언스 우선으로 설계해 반론에 답할 근거를 만들면 된다. 방법은 경계를 만들고, 규정을 준수하며 안전한 하네스(harness)를 구현하는 것. 이것이 발표의 메인 테이크어웨이다.
[09:03] 7. 데이터가 사는 곳 — 각기 다른 권한의 다섯 출처
특히 범죄 수사에서 데이터는 수많은 출처에 흩어져 있고, 각 출처는 저마다의 권한을 갖는다. 다섯 종류를 든다: Knowledge base(내부 문서·플레이북·런북), OSINT(공개 데이터, open-source intelligence), Internal databases(거래 및 독점 데이터), KYC/KYB data(신원·소유구조·스크리닝), Backend endpoints(내부 API·서비스 — 여기로 자동화된 액션도 취한다). 게다가 멀티모달리티까지 얽힌다. 문제는 이 모든 진입점이 서로 다른 프로그래밍 언어를 쓰고 내부·외부가 뒤섞여 “엉망(a mess)“이라는 것. 목표는 이 경험을 안전하고 규정을 지키는 방식으로 통일하는 것이다.
[10:35] 8. 처음부터 못 박은 다섯 제약
“우리가 처음에 세운 다섯 제약”을 카드로 나열한다. OAuth 2.1 + SSO(“신원이 전파된다”) — 원격 MCP 서버를 중앙에서 관리·모니터링하고 OAuth를 기본으로 강한 인증을 건다. Short-lived PASETO Tokens(“짧게 살고 폐기 가능”) — PASETO(Platform-Agnostic Security Tokens, 2018년에 나온 비교적 새 기술)는 짧게 사는 보안 토큰에 딱 맞아, 세션 토큰이 유출돼도 큰 보안 우려가 아니게 만든다. RBAC(“중앙화된 정책”) — 특정 데이터를 특정 사람만 접근하게 한다. Auditing(“append-only, 구조화”) — 누가·무엇을·언제 접근했는지 append-only 로그로 남긴다. HITL on critical decisions(“사람이 판단을 유지”) — 컴플라이언스상 아직 완전 자동화하지 않고, 법적 결과가 따르는 중요한 결정은 사람이 판단을 쥔다.
[11:25] 9. 시스템의 모양 — MCP Gateway = 신뢰 경계
아키텍처의 전체 모양이다. Claude Cowork(AFC 분석가 UX)가 진입점이고, 화살표는 MCP Gateway로 향한다. 게이트웨이는 위로 SSO/IdP, 아래로 Audit log에 연결되며 그 안에 “SSO · PASETO · RBAC · Audit”을 품은 **the trust boundary(신뢰 경계)**다. 게이트웨이는 다시 federated 다운스트림 MCP 서버 목록(mcp-knowledge-base, mcp-osint, mcp-internal-db, mcp-kyc-kyb, mcp-backend-api, …and more)으로, 그리고 그 뒤 Downstream APIs로 이어진다. MCP Gateway의 역할은 ① 사용자 인증 ② RBAC(신원 기반으로 특정 데이터만 접근) ③ 감사(모든 행위를 append-only DB에 기록)다. 멋진 점은 다운스트림 MCP 서버를 Go·Python·TypeScript 무엇으로든(COBOL만은 제발 하지 말라는 농담) 구현할 수 있다는 것 — 언어에 무관하므로 새 데이터 소스를 붙이기 쉽고, 붙이는 순간 감사 로그·신원관리·RBAC가 기본으로 딸려 온다. 심지어 사용자는 자기 권한 밖의 MCP 서버는 보이지도 않는다.
한편 이 Cowork 플러그인은 엔지니어들이 조사관과 나란히 앉아 실제 수사 3건을 함께 진행하며 그들의 도메인 지식·전문성을 바탕으로 만들었다. 중앙에서 배포되고 버전 관리되는 아티팩트라, 조사관 스스로도 쉽게 업데이트할 수 있다.
[14:00] 10. MCP 호출의 엔드투엔드 흐름
한 번의 요청이 처음부터 끝까지 어떻게 흐르는지 시퀀스로 보여준다: User → 1. login → Claude Cowork → 2. session → SSO/IdP → 3. tool call (user ctx) → MCP Gateway(옆에 Audit) → 4. PASETO + RBAC check → MCP Downstream server → 5. data fetch → Downstream APIs → 6. response → 7. tool result가 게이트웨이로 돌아온다. 사용자가 로그인돼 있지 않으면 SSO 페이지가 신원 공급자(identity provider)에 연결되고, 공급자가 로그인 사용자의 신원을 게이트웨이에 넘긴다. 이 시점에 이미 모든 것이 감사·기록되며, 인증되고 올바른 권한이 있으면 그때 MCP 서버 툴 콜을 수행할 수 있다. 게이트웨이의 역할을 다시 정리하면 OAuth 토큰 검증 → 신원 해석·요청 인가 → 다운스트림 MCP 서버로 전달이다. RBAC 자체는 GitHub 레포에 버전 관리되는 Terraform 파일로 정의해, 어떤 팀이 신원에 따라 어떤 MCP 서버에 접근하는지를 감사·이력 추적 가능하게 관리한다.
[15:44] 11. 더 자세한 아키텍처 — 게이트웨이 내부와 PASETO
같은 아키텍처를 더 파고든다. Claude Cowork → (OAuth 2.1 + PKCE / Bearer token) → Authorization Gateway (auth + TLS) → (Identity headers: email, perms) → mcp-gateway (this repo): Token auth plugin · Permissions → teams · Gateway bootstrap · OAuth proxy + DCR stub. 게이트웨이는 오픈소스 패키지 mcp-context-forge(IBM OSS) 기반이며, 그 아래로 **Downstream MCP servers(federated)**가 이어진다. 동작은 이렇다 — Authorization Gateway가 SSO/OAuth에서 토큰을 받아 진위를 검증하고 신원에서 권한을 얻은 뒤, 짧게 사는 PASETO 토큰(bearer) 을 발행(mint)해 다운스트림 MCP 서버와 공유한다. SSO에서 온 토큰을 그대로 넘기지 않는 게 핵심이다. 다운스트림 MCP 서버 설정은 YAML로 관리하고 Kubernetes 클러스터에 배포돼 게이트웨이로만 도달 가능하며(직접 접근 불가), 기본이 stateless streamable HTTP라 확장이 쉽다. 서버 내부에서는 bearer 토큰의 진위를 PASETO public token으로 검증하는데, 페이로드는 base64 인코딩돼 암호화되지 않았지만(노출돼도 설계상 정상) 서명돼 있어 내용 변조 여부를 확인할 수 있다. 감사를 위해 모든 MCP 툴 콜은 표준 OTel + (아직 표준에 없는) 추가 필드로 계측한다.
[18:12] 12. 라이브 데모 — Cowork가 그리는 인터랙티브 대시보드
빠르게 돌린(그리고 고객 데이터라 일부 마스킹한) 데모다. 핵심은 Cowork가 여러 출처에서 정보를 모으는 것에 그치지 않고 위젯을 즉석에서 렌더링한다는 점 — 예전의 아티팩트보다 훨씬 빠른 인라인 위젯이고 인터랙티브하다. 화면(“Financial crime analysis for ENT-1001”)에는 Composite risk 100/100, 인바운드/아웃바운드를 나눈 Transactions 차트, Ownership(UBO 1 60%·UBO 2 40%, controlling UBO flagged 표시), Screening hits(Sanctions=Critical, Adverse media=High/Medium, Court record=Low), 그리고 하단 Quick actions(Escalate, Close investigation)가 있다. 조사관은 액션을 트리거하고 드롭다운으로 차트 시각화를 바꿀 수 있다. 예전엔 여러 툴을 오가며 데이터를 모아 추론했지만, 이제는 하나의 인터페이스에서 대시보드가 만들어지고 AI의 제안·추론까지 얹힌다. (입력창 모델 선택기에 Opus 4.7이 보인다.)
[19:28] 13. 백엔드의 감사 — Grafana + ClickHouse
백엔드에서는 프로덕션 Grafana 대시보드가 돌고, 감사 추적에 완벽하게 맞는 ClickHouse를 데이터베이스로 쓴다. 하루 동안 일어난 모든 툴 콜과 인가 흐름, 그리고 누가 무엇에 접근하는지를 볼 수 있다 — 사용자, 툴 이름, 호출 수, 소요 시간까지 모두 추적·계측된다. 화면에는 ”# of tool calls (daily)”, ”# of distinct users” 패널이 보인다.
[20:00] 14. 플러그인 구조 — 오케스트레이터·서브스킬·메타 스킬
도메인 지식이 잔뜩 든 복잡한 플러그인을 어떻게 구조화했는지가 배울 점이다. 첫째, 좋은 프롬프트 위생 — 1000줄짜리 거대 프롬프트 하나 대신 여러 서브스킬로 쪼갠다. 메인 스킬(오케스트레이터)이 조사관이 각 단계에서 하려는 작업에 따라 서브스킬을 참조한다. 둘째, 프로젝트 끝에서 항상 돌며 결과를 검증하는 메타 스킬(case-self-review.md)을 둔다. 셋째, 각 스킬 프롬프트 안에서는 XML 구조화 프롬프트를 쓰고(전통적 프롬프팅보다 효율적), 그 스킬이 사용할 MCP 서버·툴을 명시해 LLM이 툴을 탐색하는 시간을 아낀다. 슬라이드가 실제 오케스트레이터(fincrime-analysis)를 보여준다 — <role>은 “너는 금융범죄 케이스의 수석 조사관이다. 모든 계층을 직접 하지 말고 각 수사 계층을 집중된 서브스킬에 위임한 뒤, 그 구조화된 출력을 하나의 분석가 스타일 케이스 파일로 조립하라. 너의 가치는 시퀀싱·병렬화·증거 보존·자기 검토다”이고, <when_to_use>는 “ENT-XXXX에 대해 전체 fincrime/AML 체크 실행”, “이 고객 조사 / SAR 초안 작성”, “ENT-1001 vs ENT-2044 비교”, “리스크 점수화”, “자금 흐름 추적” 같은 예시를 든다. 단일 툴 출력만 필요하면(예: “ENT-1001의 UBO는 누구?”) 오케스트레이터를 건너뛰고 MCP 툴을 직접 부르라고 안내한다. <sub_skills>는 각 서브스킬이 하나의 수사 관심사만 소유하고 자기 MCP 툴을 부른다고 정의한다(예: Step 1 kyc-snapshot = “서류상 이 고객은 누구인가” → fincrime-kyc).
[21:46] 15. 무엇을 평가할 것인가 — evals의 세 축
플러그인을 만들고 나면 이해관계자들이 묻는다 — “멋진데, 그래서 작동하나? 믿을 수 있나?” 이 질문에 답하는 좋은 방법이 evals다. 플러그인이 기대대로 동작한다는 정량적 사실·데이터를 가져오는 것이다. 이 유스케이스에서 가장 중요한 세 가지를 든다. F1 score + tool selection accuracy: 모델이 올바른 툴을, 올바른 순서로 쓰는가? Grounding / faithfulness: 응답이 실제 데이터에 근거하는가? — 대시보드에 표시되는 모든 데이터는 반드시 참조 문서에 grounded 돼야 하고 환각이면 안 된다. Reasoning: 모델이 맞는 답을 맞는 이유로 냈는가? — 출력만이 아니라 그 뒤의 추론까지 평가하며, 이는 LLM-as-a-judge로 한다. evals의 효용은 세 방향이다 — 엔지니어링(플러그인 반복 개선, 모델 교체, 회귀 감지), 컴플라이언스(데이터가 맞고 정확도가 요구사항을 충족함을 증명해 “밤에 편히 잠”), 최종 사용자(새 도구를 신뢰하고 매번 의심하지 않게).
[23:48] 16. 플라이휠 — 새 유스케이스일수록 더 싸진다
이 모든 학습(보안·컴플라이언스, 데이터 접근을 안전·규정 준수로 감싸는 사고방식)은 다른 유스케이스에도 그대로 쓸 수 있다. Qonto는 MCP 게이트웨이와 첫 플러그인이 생긴 지금, 더 많은 팀이 같은 MCP 서버·게이트웨이를 재사용해 자기 플러그인을 만든다 — 올바른 프롬프팅 역량만 있으면 누구나 할 수 있고 매우 저렴하며, 새 MCP 서버가 필요해도 며칠이면 배포된다. 슬라이드는 이를 플라이휠로 그린다: The AFC Investigator Plugin(도메인 지식으로 구축) → Domain MCP(필요한 데이터에 맞춰 구축) → Shipped(리드타임 몇 주) → New team/use case(전문성 유입) → 다시 순환하고, 중심에는 **MCP Gateway(공유 신뢰 경계)**가 있다. 게이트웨이가 감사·RBAC·강한 인증·신원관리를 기본 제공하므로, 특히 큰 기업에서 보안·컴플라이언스를 지키며 사내 AI 도입을 가속한다. 초기 프로젝트는 몇 주가 걸렸지만 새 유스케이스는 며칠 만에 도입된다.
[25:07] 17. AI 성숙도 — HITL → HOTL → HOOTL
지금은 시작에 불과하다. 오늘 본 것은 여전히 사람이 루프 안에 있는(HITL, human-in-the-loop) 단계 — “We are here”다. 세 단계를 든다: L1 HITL — 사람이 워크플로에 통합돼 결정을 능동적으로 승인·정제한다. L2 HOTL(human-on-the-loop) — 시스템이 자율적으로 작동하되 사람이 과정을 감독하고 필요하면 개입한다. L3 HOOTL(human-out-of-the-loop) — 의사결정에 사람 개입이 전혀 없다. 하단 문구대로 “AFC 같은 크리티컬 워크플로는 여전히 사람의 판단과 의사결정이 필요하다.” 비전은 evals로 정확도를 계속 측정·개선하며 human-on-the-loop(사람이 AI의 자율 결정을 리뷰)로 나아가고, 더 장기적으로는 정확도를 입증할 수 있다면 human-out-of-the-loop(AI가 모든 결정)라는 “꿈의 시나리오”로 향하는 것이다.
[25:50] 18. 세 가지 테이크어웨이
1. Start with evals. evals는 단 하나의 툴 콜이 프로덕션에 닿기 전에 “무엇이 좋은 것인가”에 모두를 정렬시키는 수단이다. 발표자는 evals를 TDD에 비유한다 — 소프트웨어 엔지니어라면 익숙한 테스트 주도 개발처럼, 크리티컬한 워크플로를 만든다면 언젠가 evals가 필요해질 테니 가능한 한 일찍 투자해 나중에 더 빨라지라는 것. 2. (access to) Data is king. 올바른 데이터가 없는 어시스턴트는 그냥 챗봇이다. 플러그인과 MCP 서버가 그것에 실제 도달 범위를 준다 — LLM에 필요한 힘을 주되 안전·규정 준수 방식으로. 3. Security and compliance are not an afterthought. 보안·컴플라이언스를 설계 안으로 끌고 들어와라. 게이트웨이·RBAC·감사·HITL이 제품의 핵심이다.
마무리로 규모를 다시 상기시킨다 — 매년 2~5조 달러가 세탁되지만, 더 걱정스러운 건 그중 아주 작은 비율만 당국에 탐지·압류된다는 사실이다. 그래서 이건 “멋진 걸 만드는” 것을 넘어 사회에 큰 영향을 주는 좋은 AI 활용 사례다. 금융범죄나 헬스케어 같은 민감한 산업에 있지 않더라도, 이 테이크어웨이들을 각자의 일에 적용해 더 신뢰할 수 있는 AI를 함께 만들자는 당부로 끝맺는다.
부록 — 실전 체크리스트
- 데이터 접근은 MCP로 열되, “경계”부터 설계하라. MCP를 붙이기 전에 인증·인가·감사가 통과하는 지점(게이트웨이)을 먼저 정의한다. 보안·컴플라이언스를 나중에 붙이면 반론에 답할 근거가 없다.
- 원격 MCP 서버 + 중앙 게이트웨이 패턴을 기본으로. OAuth 2.1 + SSO로 신원을 전파하고, 게이트웨이에서 RBAC·감사를 한곳에 몰아 새 데이터 소스가 이 세 가지를 자동으로 얻게 한다.
- 다운스트림에는 SSO 토큰을 넘기지 말고 짧게 사는 토큰을 발행하라. PASETO처럼 서명되고(변조 검출) 짧게 사는(유출 피해 최소화) 토큰을 mint해 전달한다. 서버 내부에서 반드시 진위를 검증한다.
- 다운스트림 MCP 서버는 게이트웨이로만 접근 가능하게 격리하라. Kubernetes에 배포해 직접 도달을 막고, stateless streamable HTTP로 확장성을 확보한다.
- 크리티컬 결정에는 HITL을 유지하라. 법적 책임이 따르는 판단은 사람이 쥔다. 자동화 확대는 evals로 정확도를 입증한 만큼만.
- 거대 프롬프트 대신 오케스트레이터 + 원자적 서브스킬로 쪼개라. 각 서브스킬은 하나의 관심사만 소유하고 자기 MCP 툴만 부른다. XML 구조화 프롬프트에 사용할 MCP/툴을 명시해 툴 탐색 비용을 줄인다.
- 끝에 항상 도는 메타 스킬(자기 검토)을 둬라. 결과를 스스로 검증하는 단계를 파이프라인 마지막에 고정한다.
- evals는 세 축으로 설계하라. ① 툴을 올바른 순서로 부르는가(코드 기반 F1·tool selection) ② 응답이 실제 데이터에 grounded 됐는가(환각 차단) ③ 맞는 답을 맞는 이유로 냈는가(LLM-as-a-judge로 추론 자체를 평가).
- 모든 것을 계측·감사하라. 표준 OTel + 필요한 추가 필드로 모든 툴 콜을 남기고, ClickHouse 같은 append-only 친화 DB로 “누가·무엇을·언제”를 조회 가능하게 한다.
- 한 번 만든 게이트웨이를 플라이휠로 재사용하라. 같은 게이트웨이·MCP 서버 위에 팀별 플러그인을 며칠 단위로 얹어, 큰 조직에서 보안·컴플라이언스를 지키며 AI 도입을 가속한다.
원문 인용 모음
자동 생성 자막 기반. 고유명사 음성인식 오류는 문맥에 맞게 보정함(예: QUANTO→Qonto, cloud→Claude, GraphWorks→GraphWalks, passetto→PASETO, hotel→OTel).
- [00:52] “If you work in finance, you probably know that financial crime is the number one priority.” — 금융범죄가 금융업의 1순위 문제.
- [01:00] “Between two and five trillion US dollars are laundered every year in the world.” — 세탁 규모.
- [03:01] “These financial investigators have three different monitors, at least, and dozens of browser tabs.” — 수동 수사의 현실.
- [04:50] “What’s interesting is how we can apply agentic AI to the second line of defense.” — 노리는 지점(2차 방어선).
- [05:49] “There is no better frontier model right now in the market than Opus 4.7.” — 모델 선택 근거.
- [07:28] “No matter how intelligent the model is, if it doesn’t have access to data, it’s not as useful.” — 데이터 접근의 중요성.
- [08:26] “Some people even say that the S in MCP stands for security.” — MCP 보안 우려에 대한 농담.
- [08:33] “You can build it security first and compliance first in mind so that you can build a case and address these objections.” — 발표의 메인 테이크어웨이.
- [09:35] “We want to unify the experience so that it’s secure and compliant.” — 흩어진 데이터 소스 통합 목표.
- [11:02] “For compliance reasons, we do not want to fully automate the process just yet. So we want to keep human judgment, at least on the critical decisions.” — HITL을 유지하는 이유.
- [12:33] “It’s cool because it’s agnostic. So it becomes very easy to link a new MCP server… and you get audit log, identity management, and role-based access control by default, out of the box.” — MCP Gateway가 주는 기본 제공 이점.
- [22:15] “All the data that is displayed on the dashboard must be grounded into the reference documents.” — grounding/faithfulness eval의 기준.
- [22:44] “We also want to know that the reasoning behind that, how it reached the conclusion, is also correct.” — 추론 자체를 평가하는 이유(LLM-as-a-judge).
- [25:53] “I like to compare evals to TDD.” — evals를 TDD에 비유.
- [26:16] “Access to data is king.” — 두 번째 테이크어웨이.
- [27:38] “I hope you can still apply some of these takeaways… so that we can build together a more trustworthy AI.” — 맺음말.
관련 노트
- 2026-07-12-elicit-aepl-verifiable-agentic-workflows — 같은 Code w/ Claude 컨퍼런스, Elicit의 검증 가능한 DSL ‘ÆPL’ — evals(F1·grounding·LLM-as-judge)로 신뢰를 입증하는 이 노트의 접근과 legible·faithful desiderata가 짝을 이룸
- 2026-07-12-proactive-agent-workflow-claude-code — 같은 컨퍼런스, Claude Code Routines의 트리거·컨텍스트·스티어링 설계 — HITL을 유지하며 자동화 범위를 단계적으로 넓히는 문제의식 공유
- qonto — 이 사례의 주체 기업(프랑스 핀테크)
- moc-ai-agents-harness — 오케스트레이터+원자적 서브스킬 구조, MCP Gateway 신뢰 경계를 하네스 설계 사례로 보강