
존재하지 않는 VAT 번호로 결제될 뻔했던 국경 간 벤더 이야기
요약
국경 간 거래 시 발생하는 복잡한 법인 및 VAT 번호 검증 과정을 Claude와 Apify MCP 서버를 활용해 자동화한 사례를 소개합니다. 수동으로 진행하던 기업 등록부 및 VAT 조회를 AI 에이전트가 직접 수행하도록 설정하여 업무 효율을 높였습니다.
핵심 포인트
- 싱가포르 UEN 및 EU VAT 번호의 유효성 검증 중요성
- Apify MCP 서버를 통한 외부 데이터 소스와 Claude의 연결
- AI 에이전트를 활용한 기업 실체 및 세무 정보 자동 조회
이것은 거의 그대로 통과될 뻔했던 계약과, 이를 막아낸 20분간의 설정에 관한 이야기입니다. 가짜 화면이나 테스트 데이터는 없습니다. 아래의 모든 레지스트리 기록, UEN, VAT 결과는 실제 채팅에서 캡처된, 라이브 공식 소스를 대상으로 한 실제 조회 결과입니다.
설정 (The setup)
Marcus는 미국 소프트웨어 기업에서 수익 운영 (Revenue Operations)을 담당하고 있습니다. 비즈니스 팀이 새로운 벤더와 계약을 체결하면, 그는 법무팀의 최종 서명과 재무팀의 수취인 설정이 이루어지기 전 마지막 관문을 책임집니다. 대부분의 경우 이 관문은 형식적인 절차에 불과합니다. 하지만 이번 주는 달랐습니다.
해당 벤더는 국경 간 (Cross-border) 거래 업체였으며, 바로 이 지점에서 거래가 까다로워집니다. 계약 당사자는 **싱가포르 법인 (Singapore entity)**이었습니다. 하지만 인보이스는 프랑스에 있는 **별도의 EU 법인 (separate EU entity)**으로부터 발행될 예정이었으며, 재무팀이 세무 처리를 할 수 있도록 VAT 번호가 기재되어 있었습니다. 두 개의 법적 실체, 두 개의 관할권, 그리고 이 모든 것을 구속하려는 하나의 서명이 존재했습니다.
Marcus는 계약서상의 이름은 아무런 증거가 되지 않으며, 인보이스의 VAT 번호는 권위 있는 기관에서 달리 확인하기 전까지는 그저 숫자 나열일 뿐이라는 것을 뼈아픈 경험을 통해 배웠습니다. 그가 계약을 진행하기 전에는 반드시 다음 두 가지가 사실이어야 했습니다.
- 싱가포르 회사가 실제로 등록된 활성 법인이어야 하며, 유사한 이름을 가진 유령 회사가 아닌 수취인을 정확히 설정하기 위해 해당 회사의 UEN (Unique Entity Number, 고유 엔티티 번호)이 필요합니다.
- 인보이스에 기재된 EU VAT 번호가 유효해야 하며, 실제로 우리에게 청구하는 법인과 일치해야 합니다. 그렇지 않으면 재무팀은 매입 부가가치세 (Input VAT)를 환급받을 수 없으며, 다음 감사 시 계약의 리스크가 노출됩니다.
수년 동안 이는 두 개의 정부 웹사이트, 두 개의 검색창, 그리고 읽을 줄 모르는 언어로 된 화면을 뚫어지게 쳐다보는 것을 의미했습니다. 서두르지 않을 때만큼은 신뢰할 수 있는 방식이었지만, 온보딩 (Onboarding) 과정은 언제나 서두르게 마련입니다.
그래서 몇 주 전, Marcus는 다른 방식을 시도했습니다. 그는 공식 Apify MCP 서버를 사용하여 두 데이터 소스를 Claude에 도구 (Tools)로 직접 연결했고, 모델이 데이터를 가져오도록 했습니다. 단 하나의 설정 블록과 재시작만으로 가능했습니다.
그가 연결한 두 가지 도구는 다음과 같습니다:

- Singapore ACRA Company Registry Scraper는 공식 ACRA 기업 등록부에서 모든 싱가포르 기업을 조회하여 UEN(고유 엔티티 번호), 엔티티 상태, 설립일, 등록 주소, 산업 코드 및 이전 명칭을 반환합니다.
- EU VAT VIES Validation Scraper는 유럽 위원회(European Commission)의 VIES 서비스에 대해 하나 또는 여러 개의 EU VAT 번호를 검증하며, 회원국에서 제공하는 경우 등록된 사업자 명칭과 주소를 반환합니다.

두 도구 모두 단일 MCP (Model Context Protocol) 엔드포인트를 통해 Claude에 노출되었습니다. Marcus의 작업 방식에는 다른 어떤 것도 변하지 않았습니다. 그는 채팅창을 열고 평범한 영어로 입력하기만 하면 됩니다.
하나만 확인해 보죠: 싱가포르 기업이 실존하나요?
서류상의 계약 주체는 "DBS Bank Ltd"였습니다. Marcus는 Claude에 해당 이름을 붙여넣고, 회사가 활성 상태인지 확인하고 UEN을 가져오라고 요청했습니다.

도구 호출(tool call) 2초 만에, 그는 공식 등록부로부터 직접 얻은 깔끔한 답변을 얻었습니다. **DBS BANK LTD.**는 활성 기업 (Live Company), UEN 196800306E, 1968년 7월 16일에 설립된 주식 유한 공사 (Public Company Limited by Shares), 등록 주소 12 Marina Boulevard로 확인되었으며, 기록에는 이전 명칭(The Development Bank of Singapore)까지 포함되어 있었습니다.
하지만 유용한 부분은 Marcus가 미처 찾아볼 생각조차 못 했던 것이었습니다. 동일한 검색을 통해 이름이 거의 흡사한 DBS PTE. LTD. (UEN 197700546G)가 검색되었는데, 이 회사는 구성원 자발적 청산 (members' voluntary winding up)을 통해 **해산 (Dissolved)**된 상태였습니다. Claude는 요청하지 않았음에도 이를 포착했습니다. 이름이 혼동될 정도로 유사하지만 서로 다른 법적 실체(legal entity)임을 지적하며, 대금 수령인과 계약이 명부에 바로 옆 줄에 앉아 있는 죽은 이름의 회사가 아니라, 현재 유효한 196800306E로 설정되었는지 확인하라고 경고했습니다.
이것이 바로 바쁜 팀들이 빠지기 쉬운 함정입니다. 이름은 일치하지만, UEN(고유 엔티티 번호)은 일치하지 않습니다. 재무 부서가 잘못된 번호로 설정하게 되면, 법적으로 더 이상 존재하지 않는 실체로 돈을 송금하게 됩니다. 에이전트는 이를 포착하여 명부를 증거로 제시하며 어떤 UEN을 신뢰해야 하는지 알려주었습니다.
두 번째 확인: VAT 번호가 유효한가?
싱가포르 측은 통과되었습니다. 이제 EU 청구 실체(billing entity) 차례입니다. 송장 초안에는 프랑스 VAT 번호가 기재되어 있었고, 벤더의 마스터 데이터 양식에는 확실히 하기 위해 두 개의 번호가 더 나열되어 있었습니다. Marcus는 Claude에게 이 모든 번호를 VIES(유럽 부가가치세 정보 교환 시스템)를 통해 검증하고, 재무 부서가 실제로 지급할 수 있는 번호가 무엇인지 알려달라고 요청했습니다.
그 결과가 송장 발행을 중단시켰습니다.
송장에 인쇄된 번호인 FR99999999999는 **유효하지 않음 (INVALID)**으로 확인되었습니다. VIES에는 해당 등록 정보가 없었습니다. 쉽게 말해, 만약 재무 부서가 송장 그대로 대금을 지급했다면, 매입 부가가치세 (input VAT)를 환급받을 수 없었을 것이며 해당 문서는 감사 (audit)를 통과하지 못했을 것입니다. 그것은 유효한 등록 번호가 아니라, 단지 적절한 길이를 가진 그럴싸해 보이는 문자열에 불과했습니다.
수정된 프랑스 번호인 FR40303265045는 **유효(VALID)**한 것으로 확인되었으며, 더 나아가 11 Rue Ampere, 26600 Pont de l'Isere에 위치한 실제 등록 사업자인 SA SODIMAS로 확인되었습니다. 이것이 바로 VIES를 단순한 Yes/No 체크 이상의 도구로 만드는 요소입니다. VIES가 반환하는 이름과 주소는 Marcus가 계약서에 기재된 EU 법인과 대조하여 일치 여부를 확인할 수 있는 근거가 됩니다. 단순히 유효한 것만이 아니라, 유효하면서 동시에 일치하는 것이 기준입니다.
세 번째 번호인 독일 부가가치세(VAT) 번호(DE811193231) 역시 **유효(VALID)**했습니다. 다만 Claude는 독일의 경우 VIES를 통해 사업자 이름을 반환하지 않고 확인 결과만 제공한다는 점을 주의 깊게 언급했습니다. 따라서 이 번호는 이름이 아닌 번호를 통해 계약서와 대조해야 합니다. 이는 VIES가 실제로 제공하지도 않은 이름 일치라는 잘못된 안도감을 주는 대신, 묻지 않아도 스스로 드러낸 정직한 주의 사항이었습니다.
결과적으로 상황은 이랬습니다: 벤더는 실제로 유효한 EU VAT 등록을 보유하고 있었으나, 그들의 인보이스(Invoice)에 기재된 번호는 그것이 아니었습니다.
메모 (The memo)
마지막 단계는 예전에 가장 많은 시간을 잡아먹었던 단계입니다. 바로 다른 사람이 그 결정을 신뢰할 수 있도록 문서화하는 것입니다. Marcus는 Claude에게 계약 승인서에 스테이플러로 찍어둘 수 있도록 모든 내용을 하나의 Go/No-go(진행/중단) 표로 정리해 달라고 요청했습니다.

각 식별자에 연결된 다섯 줄의 내용입니다. 싱가포르 거래 상대방: UEN 196800306E에 따라 GO(진행). 해산된 동명 업체: 사용 금지. EU 법인 SA SODIMAS: 일치하는 이름을 반환하는 유효한 VAT에 따라 GO(진행). 인보이스에 실제로 기재된 번호: NO-GO(중단), 거절 및 재발행 요청. 보조 독일 VAT: 문제없음, 번호로 대조.
에이전트가 작성한 최종 결론은 "승인(approved)"도, "차단(blocked)"도 아니었습니다. 그것은 정확하고 방어 가능한 내용이었습니다: "벤더가 유효한 VAT 번호로 인보이스를 재발행하면 서명 가능(cleared to sign once the vendor re-issues the invoice against the valid VAT number)." 두 번의 조회 모두 그날 아침 공식 출처를 대상으로 수행되었고, 두 실행 ID(run IDs)가 메모에 포함되어 있었으므로, 승인 파일은 작성되는 즉시 감사(audit)를 받을 준비가 되어 있었습니다.
실제로 변화한 것
Marcus의 판단력 중 기계로 넘어간 것은 아무것도 없습니다. 어떤 벤더를 온보딩(onboard)할지, 언제 서명을 보류할지는 여전히 그가 결정합니다. 변화한 것은 시간 압박 속에서 실패하기 쉬운 기계적인 부분입니다:
- 데이터 가져오기(fetch)가 자동화되었습니다. Claude는 대화 과정에서 데이터가 필요한 즉시 실시간 ACRA 기록을 가져오고, Marcus가 직접 탐색할 필요가 없는 관할 구역과 언어로 VIES를 통해 VAT 번호를 스스로 실행합니다.
- 증거가 보존됩니다. 모든 답변은 UEN 또는 VAT 번호와 해당 정보가 추출된 실행(run) 기록을 인용합니다. 따라서 출력물은 누군가 캡처했다가 분실해버린 스크린샷 대신, 기본적으로 감사 준비가 된 상태가 됩니다.
- 검증이 일관됩니다. 누가 시간을 확인하고 있든 상관없이, 첫 번째 벤더와 50번째 벤더에 대해 동일한 2단계 스크리닝(screening)이 수행됩니다.
계약서가 발송되기 전 두 가지 문제가 포착되었습니다: 지급인이 될 수도 있었던 해산된 동명 기업(dissolved namesake), 그리고 몇 달 후 감사 결과로 드러났을 무효한 VAT 번호입니다. 기존의 두 개의 탭을 사용하는 방식의 급박한 온보딩 과정이었다면, 이 중 적어도 하나는 놓쳐졌을 것입니다.
동일한 에이전트 구축하기
이 이야기의 모든 내용은 현재 무료 Apify 계정과 MCP 지원 클라이언트(Claude Desktop, Cursor 또는 자체 에이전트)를 통해 재현 가능합니다:
- Apify Console의 Settings → Integrations에서 Apify API 토큰을 가져옵니다.
- 클라이언트에 공식 Apify MCP 서버를 추가하고
tools파라미터에 두 개의 Actor를 나열합니다:
{
"mcpServers": {
"apify": {
...
- 클라이언트를 재시작한 다음, 평이한 영어(plain English)로 싱가포르 거래 상대방을 확인하고 송장의 부가가치세(VAT) 번호를 검증해 달라고 요청하세요. 클라이언트는 각 단계에 적합한 도구(tool)를 선택할 것입니다.
📌 참고: 각 도구 호출(tool call)은 귀하의 Apify 계정으로 비용이 청구되는 실제 Actor 실행입니다 (두 가지 모두 결과당 과금 방식이며, 조회당 1센트 미만의 비용이 발생합니다). 전체 벤더 마스터(vendor master)를 지속적으로 스크리닝하려면, 채팅당 한 번씩 호출하는 대신 Apify API를 통해 Actor를 스케줄에 따라 실행하세요.
🏹 확장하기: 동일한 패턴을 모든 관할 구역이나 검증 항목으로 확장할 수 있습니다. 영국 거래 상대방을 위해 UK Companies House를 추가하거나, 동일한 당사자를 미국 재무부 명단과 대조하여 스크리닝하기 위해 OFAC Sanctions List Screening Scraper를 추가하면, 단 한 줄의 새로운 코드 없이도 온보딩 에이전트(onboarding agent)의 업무 범위를 넓힐 수 있습니다.
이 사례에 사용된 Actor: Singapore ACRA Company Registry Scraper 및 EU VAT VIES Validation Scraper.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기