이것은 하나의 실험이며, 저는 이것이 무엇을 증명하고 무엇을 증명하지 않는지에 대해 정확하게 말하고 싶습니다. 저는 공식 Apify MCP 서버를 통해 Claude를 4개의 라이브 컴플라이언스 (compliance) 데이터 소스에 연결하고, 단 하나의 평이한 영어 지침을 주었습니다. 그리고 Claude가 실제 실사 (due-diligence) 체크를 처음부터 끝까지 수행할 수 있는지 지켜보았습니다. 즉, 어떤 소스를 쿼리할지 결정하고, 실행하며, 결과를 교차 참조하고, 리스크 점수를 매긴 뒤, 모든 주장이 소스를 가리키는 메모를 제출할 수 있는지 확인한 것입니다.

모의 화면(mocked screens)은 없습니다. 아래의 모든 레지스트리 기록, 제재 적발 사례, SEC 공시 내용은 실제 채팅에서 캡처된 라이브 소스에 대한 실제 조회 결과이며, 재현할 수 있도록 옆에 Apify 실행 ID가 인쇄되어 있습니다. 흥미로운 점은 도구가 데이터를 반환했다는 것이 아닙니다. 아무도 Claude에게 어떤 도구를 호출해야 하는지, 혹은 어떤 순서로 호출해야 하는지 말해주지 않았다는 점입니다. Claude는 요청을 읽고, 체크 항목을 선택하고, 스스로 증거를 정리했습니다.

대담한 버전의 홍보 문구는 다음과 같습니다: 프롬프트 하나로 끝내는 실사 (due diligence). 회사 이름을 말하면, 에이전트가 서류를 작성합니다.

제가 연결한 4가지 도구

거래 상대방에 대한 실사 (due-diligence) 체크는 실제로는 서로 다른 권위 기관이 답변하는 4가지 별개의 질문과 같습니다:

1. 법적 실체가 실존하며 현재 활성 상태인가? 송장에 적힌 이름만으로는 아무것도 증명할 수 없습니다. 회사는 해산되거나, 청산되거나, 서류상의 이름으로 존재하지 않았을 수도 있습니다.
2. 해당 당사자가 미국 제재 명단에 있는가? 미국 재무부의 OFAC 명단에 있는 엔티티에 송금하는 것은 엄격 책임(strict-liability)이 따르는 연방 범죄입니다. "몰랐다"는 변명이 되지 않습니다.
3. EU 명단에도 있는가? 두 번째 관할권은 적발 사례를 확증하거나 노출 범위를 넓힙니다.
4. 공시를 수행하며, 식별자가 일치하는가? SEC에 10-K를 제출하는 회사는 레지스트리와 교차 확인할 수 있는 종이 기록(paper trail)을 남깁니다.

저는 각각에 대해 하나의 Apify Actor를 연결했으며, 모두 단일 MCP 엔드포인트를 통해 Claude에 노출되었습니다:

• Sunbiz Florida Business Registry & Officers Scraper (전체 등록 기록: 법인명, 상태, 문서 번호, 임원, 등록 대리인 및 이벤트 이력 포함).
• OFAC Sanctions List Screening Scraper는 이름을 특별 지정 대상자 (SDN) 목록과 대조하여 프로그램, 별칭, 주소 및 연관 엔티티를 반환합니다.
• EU Consolidated Sanctions List Scraper (유럽 목록에 대해 동일한 스크리닝을 수행하며, 규정 참조 및 식별자 포함).
• SEC EDGAR Filings Scraper는 CIK, 접근 번호(accession numbers) 및 제출 날짜와 함께 기업의 제출 서류(10-K, 10-Q, 8-K)를 가져옵니다.

네 개의 도구, 한 줄의 설정, glue code(연결 코드) 없음. 그런 다음 저는 채팅창을 열고 문장 하나를 입력했습니다.

하나의 프롬프트, 그리고 에이전트가 결정한 나머지 과정

첫 번째 실행을 위해 의도적으로 깨끗한 대상을 선택했습니다: 플로리다의 식료품 체인인 Publix Super Markets입니다. 실제로 활동 중이며 플로리다에 법인이 설립되어 있고, 마침 SEC에 서류를 제출하는 기업으로, 에이전트가 지시를 받지 않고도 적절한 도구 조합을 찾아내는지 테스트하기에 좋은 대상입니다.

제가 에이전트에게 준 전체 지침과 그 후에 일어난 일은 다음과 같습니다:

저는 단 하나의 도구 이름도 언급하지 않았습니다. Claude는 요청을 네 가지 확인 사항으로 분해하고 합리적인 순서(엔티티 확립을 위한 등록 정보 확인을 먼저 수행한 후, 두 개의 제재 목록 확인, 마지막으로 SEC 제출 서류 확인)로 실행했으며, 호출 사이사이에 자신의 추론 과정을 설명했습니다. 모든 호출은 실제 Apify 실행입니다:

• Sunbiz → pDNlZeA1aBU6oCQrS 실행: ACTIVE (활성), PUBLIX SUPER MARKETS, INC., Florida Profit Corporation, 문서 번호 #112252, 1921년 등록, 지정된 임원 명시 (CEO Kevin S. Murphy, President John L. Goff, Jr., CFO David P. Phillips).
• OFAC → GSsSWcL3Kd2CoN63s 실행: 일치 항목 없음 (0 matches).
• EU consolidated list (EU 통합 리스트) → mOYdsujWKycKzbakB 실행: 일치 항목 없음 (0 matches).
• SEC EDGAR → PDMwwh0FVfgzytjCu 실행: CIK 0000081061로, 2025-12-27에 종료되는 회계연도에 대해 2026-03-02에 제출된 10-K 서류.

그다음 Claude는 제가 실제로 지켜보고 있었던 행동을 했습니다. SEC 제출 서류(SEC filing)에 기재된 EIN(59-0324412)이 플로리다 등록 기록(Florida registry record)의 FEI 번호와 _정확히 일치(exact match)_한다는 점을 포착한 것입니다. 두 개의 독립적인 정부 소스를 통해 동일한 법인임이 확인되었습니다. 아무도 데이터베이스 간의 식별자(identifiers)를 대조하라고 요청하지 않았습니다. Claude는 교차 검증(cross-check)을 할 가치가 있다고 판단하고 이를 수행했습니다.

점수가 매겨진 보고서 (The scored dossier)

데이터는 결정이 아닙니다. 마지막 단계이자 보통 분석가의 오후 시간을 통째로 잡아먹는 단계는, 네 개의 가공되지 않은 결과물을 파일에 첨부하고 감사인(auditor)에게 방어할 수 있는 무언가로 변환하는 것입니다. 저는 Claude에게 리스크 점수를 매기고 보고서를 작성하라고 요청했습니다.

Claude는 Publix의 리스크를 **낮음 (LOW)**으로 평가했으며, 각 행마다 실행 ID(run ID)가 포함된 표 형식으로 추론 과정을 나열했습니다: 등록 PASS, OFAC CLEAR, EU CLEAR, SEC VERIFIED, 그리고 신원 교차 검증 MATCH.
권고 사항은 "온보딩(onboarding)을 진행하십시오"였으며, 명시적으로 인간의 승인(human sign-off)을 조건으로 합니다.

마지막 조항은 단순히 장식용이 아닙니다. 이 점수는 에이전트가 수집한 증거에 적용하는 휴리스틱(heuristic)이며, 인간을 대체하는 판결이 아니라 인간을 위한 시작점입니다. 에이전트가 제거한 것은 기계적인 노동(탭 전환, 복사 및 붙여넣기, 마감 압박 속에서 검토를 누락할 위험)이지, 판단(judgment)이 아닙니다.

대조군: 잘못된 이름의 사례

깨끗한 결과(clean result)는 동일한 워크플로우가 잘못된 결과(dirty one)를 잡아낼 수 있을 때만 의미가 있습니다. 그래서 저는 문제가 될 것이 확실한 이름인 러시아 국영 무기 수출업체 Rosoboronexport를 대상으로 동일한 지침을 실행했습니다.

에이전트는 먼저 미국 리스트를 스캔하여 일치하는 항목을 발견했고, (중단하는 대신) 보고하기 전에 두 번째 관할 구역을 확인하는 것이 가치가 있다고 판단했습니다. 두 번의 실행 결과 모두 양성(positive)으로 나왔습니다:

• OFAC → MLnvX5XE9E8vZYPK7 실행: 1개의 SDN 일치 항목. 세 가지 프로그램(UKRAINE-EO13662, RUSSIA-EO14024, IRAN-CON-ARMS-EO) 하에 ROSOBORONEKSPORT OAO로 등재되어 있으며, State Corporation Rostec와 연결되어 있고, 주소는 27 Stromynka Ul., Moscow입니다.
• EU 통합 리스트(EU consolidated list) → wEU9R9n6McPW5SAfh 실행: 1개 일치 항목, 참조 EU.7808.66, 프로그램 UKR, 2022-03-15 지정.

그리고 다시 한번 에이전트가 스스로 교차 참조(cross-reference)를 수행했습니다. 에이전트는 두 리스트가 **동일한 세금 식별 번호(tax ID, 7718852163)와 동일한 등록 번호(registration number, 1117746521452)**를 가지고 있다는 점을 포착했습니다. 이는 이름이 모호하게 일치하는 우연이 아니라, 두 개의 독립적인 기관에 의해 확인된 동일한 법적 실체(legal entity)임을 의미합니다. 에이전트는 거래 상대방을 **HIGH(고위험)**로 평가하고, STOP 판결을 내렸으며, 해당 당사자를 차단하고 법무팀에 보고할 것을 권고했습니다. 컴플라이언스 담당자가 조치를 취하는 데 필요한 모든 사항이 증거와 함께 첨부되어 제공되었습니다.

에이전트가 실제로 한 일과 하지 않은 일

저는 경계선에 대해 솔직해지고 싶습니다. 왜냐하면 여기서 흥미로운 주장은 매우 좁은 범위에 국한되어 있으며, 과장하기가 매우 쉽기 때문입니다.

에이전트가 한 일:

• 도구 선택 (Chose the tools). 단 한 문장으로부터, 에이전트는 작업을 적절한 4가지 점검 항목으로 분해하고 각 항목에 맞는 소스를 선택했습니다. 이는 스크립트를 따르는 방식이 아니었습니다.
• 작업 순서 구성 (Sequenced the work). 등록(Registry)을 먼저, 그다음 제재(Sanctions)를, 마지막으로 공시(Filings)를 확인했습니다. 제재 대상이 발견되었을 때, 에이전트는 무작정 모든 것을 실행하는 대신 보고하기 전에 두 번째 관할 구역(jurisdiction)을 확인했습니다.
• 식별자 교차 참조 (Cross-referenced identifiers). 요청받지 않았음에도 두 개의 데이터베이스에서 EIN을 FEI와 매칭하고, 두 개의 제재 목록에서 세금 ID(tax ID)를 대조했습니다. 이는 단순한 이름 조회(name lookup)와 실제 점검(real check)을 구분 짓는 종류의 상호 확인(corroboration)입니다.
• 점수 산정 및 인용 (Scored and cited). 원시 기록(raw records)을 모든 줄에 소스 실행 ID(source run ID)가 포함된 리스크 범위(risk band)로 변환했습니다.

에이전트가 하지 않은 일:

• 최종 결정을 내리지 않았습니다. '낮음(LOW)'과 '높음(HIGH)'은 권장 사항일 뿐입니다. 온보딩(onboarding) 또는 차단 여부에 대한 최종 승인은 여전히 사람이 합니다.
• 무언가를 지어내지 않았습니다. 모든 수치는 지난 몇 분 내의 실시간 소스에서 가져왔으며, 실행 ID(run ID)와 함께 출력되었습니다. OFAC와 EU에서 Publix에 대한 결과가 나오지 않았을 때, 에이전트는 '깨끗함(clean)'이 아니라 '일치 항목 없음(no match)'이라고 보고했습니다. 이는 에이전트가 명확하게 구분해낸 중요한 차이입니다.
• 컴플라이언스 프로그램을 대체하지 않았습니다. 모호한 이름(fuzzy-name)의 예외 사례, 실소유자(beneficial-ownership) 추적, 부정적 언론 보도(adverse-media) 확인은 여전히 사람의 영역입니다. 이 시스템은 첫 번째 단계인 기계적인 검토(mechanical pass)를 자동화합니다.

이러한 역할 분담(데이터 가져오기와 1차 점수 산정은 자동화하고, 판단과 승인은 사람이 담당하는 것)은 정확히 올바른 방식이며, 이것이 바로 결과물이 블랙박스(black box)가 아닌 기본적으로 감사 가능(audit-ready)한 상태가 되는 이유입니다.

동일한 에이전트 구축하기

위의 모든 과정은 현재 무료 Apify 계정과 MCP 지원 클라이언트(Claude Desktop, Cursor 또는 자체 에이전트)를 통해 재현 가능합니다:

1. Apify Console의 Settings → Integrations에서 Apify API 토큰을 가져옵니다.
2. 공식 Apify MCP 서버를 추가하고 tools 파라미터에 4개의 Actor를 나열합니다:

{
  "mcpServers": {
    "apify": {
...

1. 클라이언트를 재시작하고, 평이한 영어로 특정 기업에 대한 실사(due diligence)를 수행하라고 요청합니다. 그러면 모델이 각 질문에 적합한 도구를 선택하여 실행하고, 그 결과를 점수화할 것입니다.

📌 참고: 각 도구 호출(tool call)은 귀하의 Apify 계정으로 비용이 청구되는 실제 Actor 실행이며, 이 Actor들은 각각 결과당 비용이 발생하는 방식(pay-per-result)으로, 조회당 1센트 미만의 아주 적은 비용이 소요됩니다. 수천 개의 거래 상대방을 지속적으로 스크리닝해야 하는 경우, 채팅당 한 번씩 호출하는 대신 Apify API를 통해 Actor를 스케줄에 따라 실행하십시오.

🏹 확장하기: 동일한 패턴을 모든 관할 구역이나 검사 항목으로 확장할 수 있습니다. 영국 법인을 위해 UK Companies House를 추가하거나, 거래 상대방이 위치한 시장에 맞는 기업 등록(company-registry) Actor를 tools 목록에 추가하기만 하면, 단 한 줄의 새로운 코드 없이도 에이전트가 더 넓은 범위를 커버할 수 있습니다.

이 실험의 핵심은 스크레이퍼(scraper)가 기록을 가져올 수 있다는 점이 아닙니다. 그것은 이미 수년 전부터 가능했던 일입니다. 핵심은 유능한 모델이 적절한 도구와 하나의 명확한 지침을 받았을 때, 이제는 조립(assembly)(무엇을 확인할지 결정하고, 이를 대조하며, 점수를 매기고, 출처를 인용하는 과정)을 수행할 수 있으며, 인간에게는 인간의 영역으로 남아야 할 단 한 가지, 즉 '의사 결정'만을 남겨줄 수 있다는 점입니다.

이 실험에 사용된 Actor들: Sunbiz Florida Business Registry & Officers Scraper, OFAC Sanctions List Screening Scraper, EU Consolidated Sanctions List Scraper, 그리고 SEC EDGAR Filings Scraper.