관세 데이터 관리가 포워더가
생각보다 더 많은 비용을 초래하는 이유

종이 없는 역설

정부는 지난 30년 가까이 디지털 관세 인프라를 구축하는 데 투자해 왔습니다. 미국은 2016년 기존 자동 상업 시스템을 ACE로 전환했고, 영국은 Customs Declaration Service로 이전했으며, 인도는 ICEGATE를 구축했습니다. 수십 개국이 WCO 데이터 모델 프레임워크에 따라 Single Window 플랫폼을 출시했습니다. 모든 공식 지표에 따르면, 관세는 그 어느 때보다 디지털화되었습니다.

중간 규모 관세사무소의 업무 현장에 들어가 보면 상황은 달라 보입니다. 엔트리 작성자는 화주로부터 받은 PDF 상업 인보이스를 엽니다 — 포워더의 메시지에 첨부된 이메일로 도착한 것이죠. 그녀는 수하인 이름, HS 코드, 신고 가액, 원산지, 인코텀즈를 읽고 — 그것들을 다른 소프트웨어, 즉 데이터를 ACE로 전송하는 ABI 신고 플랫폼에 입력합니다. 나중에 다른 직원이 동일한 선적 정보를 운영 추적을 위해 회사 TMS에 다시 입력할 것입니다. 그리고 또 다른 직원이 청구를 위해 회계 시스템에 다시 입력합니다. 인보이스 한 장에서 수작업 데이터 입력이 세 차례 반복됩니다. Partner Government Agency가 관련된 선적 — 식품의 경우 FDA, 화학물질의 경우 EPA — 이라면 네 번째 시스템이 추가됩니다.

이것이 종이 없는 역설입니다. 관세 당국은 디지털 포털을 보유하고 있습니다. 중개인은 종이 서류 대신 컴퓨터를 사용합니다. 그러나 사람의 손이 선적 데이터와 만나는 지점에서, 업무 흐름은 1990년대 이후 근본적으로 변하지 않았습니다. 문서는 팩스 대신 PDF가 되었고, 신고 소프트웨어는 현대적인 UI를 갖추고 있습니다. 그러나 핵심 활동 — 한 화면에서 정보를 읽고 다른 화면에 입력하는 것 — 은 동일합니다.

동일한 선적 데이터를 네 가지 시스템에 입력하는 이유

이 문제가 운영상의 문제가 아니라 구조적 문제인 이유를 이해하려면 단일 선적의 데이터 이동 경로를 추적해 보십시오:

1단계 — 송하인에서 포워더로. 선전의 수출업자가 상업 송장과 패킹 리스트를 포워더에게 보냅니다. 이 서류는 PDF 또는 스캔 이미지로 도착합니다. 포워더의 운영 담당자가 문서를 열고 선적 세부 정보 — 송하인 이름, 수하인, 상품 설명, 중량, 수량, 신고 가액 — 를 포워더의 TMS(대부분 CargoWise)에 입력합니다. 이로써 예약, 통합, 운송사 커뮤니케이션에 사용되는 선적 기록이 생성됩니다.

2단계 — 포워더에서 관세사로. 포워더는 동일한 상업 송장과 패킹 리스트를 목적지 국가의 관세사에게 전달합니다. 관세사의 통관 담당자는 PDF를 열고 동일한 수하인, 동일한 HS 코드, 동일한 금액을 ABI 인증 신고 소프트웨어(미국 기준) 또는 해당 국가 플랫폼에 다시 입력합니다. 포워더의 TMS와 관세사의 신고 소프트웨어는 서로 연동되지 않습니다. 두 회사가 모두 CargoWise를 사용하더라도 서로 다른 법인이 운영하는 별도 인스턴스 간에 데이터가 자동으로 흐르지 않습니다.

3단계 — 신고에서 PGA 포털로. 상품이 PGA(Partner Government Agency) 관할에 해당하는 경우 — 의료기기는 FDA, 농산물은 USDA, 화학물질은 EPA — 서로 다른 필드 요구 사항을 가진 별도 포털을 통해 별도의 데이터 제출이 이루어집니다. 데이터는 관세사의 ABI 신고에 존재하지만 PGA 시스템에 자동으로 채워지지 않습니다. 누군가 다시 입력하거나 복사하여 붙여넣어야 합니다.

4단계 — 운영에서 회계로. 통관 후 선적 세부 정보는 청구 시스템에 도달해야 합니다. 포워더는 고객에게 청구서를 발행해야 하고, 관세사는 신고 건에 대해 청구해야 하며, 관세 금액은 실제 납부 금액과 일치해야 합니다. 회계 소프트웨어 — 통합 ERP 모듈이든 독립 플랫폼이든 — 는 관세 데이터를 기본적으로 소비하는 경우가 드뭅니다. 다시 한번: 데이터 재입력이 발생합니다.

5단계 — 내부 보고. 누군가 TMS, ABI 시스템, 회계 시스템에서 데이터를 추출하여 주간 운영 보고서용 스프레드시트에 입력합니다. 세 개의 소스 시스템, 하나의 Excel 통합 문서, 전부 수작업입니다.

각 단계마다 새로운 오류 확률이 발생합니다. 물류 환경에서 표준 수동 데이터 입력 오류율은 약 1~4%입니다. 월 10,000건의 거래 기준으로 100~400건의 데이터 오류가 발생합니다. 통관에서 오류는 단순한 수정이 아니라 선적 보류, CBP 양식 28 정보 요청, 잠재적 벌칙으로 이어집니다. 국제운송주선인연맹(FIATA)은 "시스템 간 상호운용성 부족과 데이터 품질 및 데이터 표준의 불일치"를 업계의 근본적인 과제로 명시적으로 지적합니다. 이 문제는 최고 수준에서 인식되고 있습니다. 그러나 이를 유지하는 구조는 변하지 않았습니다.

아무도 준비하지 못한 호환성 문제

문제가 단순히 "기업들이 서로 다른 소프트웨어를 사용한다"는 것뿐이라면 API로 해결할 수 있을 것입니다. 더 근본적인 문제는 세관 데이터 표준 자체가 국가별로 호환되지 않는다는 점이며, 때로는 단일 국가 내에서도 호환되지 않는다는 점입니다.

WCO는 1990년대부터 데이터 모델을 발표하고 유지 관리해 왔습니다. 이는 국가 간 데이터 교환을 상호 운용 가능하게 만들기 위해 설계된 조화롭고 표준화된 데이터 정의 및 전자 메시지 형식의 집합입니다. WCO 데이터 모델은 전 세계 Single Window 환경의 데이터 기반입니다. 이는 물품 신고, 화물 보고, 운송 보고, 그리고 허가/승인/증명서를 위한 재사용 가능한 "정보 패키지"를 정의합니다. 문서상으로는 국경 간 무역 데이터의 보편적 언어입니다.

실제로는 APEC의 Single Window 상호 운용성 모범 사례 편람에 따르면 회원 경제들은 WCO 데이터 모델의 존재에도 불구하고 "다양한 데이터 형식(UN/EDIFACT, ANSI X12, XML 및 독점 형식)"을 사용하고 있습니다. 말레이시아의 uCustoms, 인도의 ICEGATE, 미국의 ACE 시스템, 영국의 CDS는 각각 서로 다른 기술 아키텍처, 서로 다른 필드 매핑, 서로 다른 검증 규칙을 사용합니다. EU 내부에서도 UCC가 온라인 신고를 의무화하고 있지만, 구현 세부 사항은 회원국마다 다릅니다. 독일과 프랑스로 물품을 통관시키는 브로커는 동일한 UCC 프레임워크 아래 운영되면서도 서로 다른 국가 시스템 인터페이스를 마주하게 됩니다.

그 결과, 디지털화가 국가별로, 플랫폼별로 진행되고 구속력 있는 상호 운용성 의무가 없는 글로벌 세관 인프라가 탄생했습니다. 각 국가 시스템은 디지털 섬입니다. 물품은 국경을 넘지만 데이터는 넘지 못합니다.

관세 데이터 오류의 실제 비용

관세 비효율성을 설명하는 언어는 추상적입니다. "병목 현상", "마찰", "지연" 같은 표현이죠. 하지만 재입력 과정에서 발생하는 모든 오류에는 가격표가 붙어 있고, 그 비용은 빠르게 눈덩이처럼 불어납니다.

가장 눈에 띄는 비용인 체선료와 체화료부터 살펴보겠습니다. HS 코드 불일치, 신고 가격 차이, 또는 서류 누락으로 통관이 지연되어 화물이 항구에 머무르게 되면, 카운트다운이 시작됩니다. 무료 체선 기간(보통 3~7일)이 지나면 표준 체선료는 컨테이너당 하루 $75~$300입니다. 터미널 밖에서 운송사의 컨테이너를 보관하는 데 드는 체화료는 하루에 추가로 $100~$200가 더해집니다. 첫 주가 지나면 요금은 더 올라갑니다. 단일 컨테이너가 하루 $200의 요율로 10일간 지연되면 계획에 없던 비용이 $2,000 발생합니다. 아시아에서 오는 12개 컨테이너 화물이라면 $24,000입니다. 여기에는 재고 부족 비용, 일정을 만회하기 위한 긴급 운송비, 또는 FBA行 화물의 경우 아마존 재고 부족 패널티는 포함되지 않은 금액입니다.

미주개발은행의 연구에 따르면 입항 지연이 하루 추가될 때마다 총 무역 비용이 0.9% 증가합니다. 평균 수입 지연이 약 8.5일임을 감안하면, 이는 정상적인 착지 원가에 더해지는 7.65%의 비용 프리미엄입니다. $100,000 상당의 화물이라면 관세 관련 지연으로 $7,650이 추가됩니다. 그리고 이 수치는 평균일 뿐입니다. 공항에서의 지연이 해상 항구보다 비용이 더 높은 것으로 나타났으며, 대기업이 불균형적으로 더 높은 비용을 부담했습니다.

그 다음으로 관세 인보이스에는 나타나지 않는 비용이 있습니다. 2025년 영국 중소기업 감사 결과에 따르면 총 운송 지출의 18%가 피할 수 있었던 벌금 — 데이터 오류, 지연 신고, 잘못된 분류로 인한 패널티 — 에 해당했으며, 실제 세금 의무는 아니었습니다. 운송 예산의 거의 5분의 1이 데이터 입력 단계에서 발생한 오류로 인해 사라지는 셈입니다.

덜 눈에 띄는 비용이 아마 더 클 것입니다. 통관 시간을 예측할 수 없을 때 — 때로는 2일, 때로는 10일 — 공급망 관리자는 안전 재고를 쌓아둡니다. 그 재고는 운전 자본을 묶어 둡니다. 개별 데이터 입력 오류는 연쇄적으로 문제를 일으킬 수 있습니다. 잘못 입력된 HS 코드는 상품 보류를 유발하고, 보류는 체선료를 발생시키며, 체선료는 마진을 잠식합니다. 우리는 통관 지연을 일으키는 가장 흔한 관세 데이터 입력 실수 7가지를 자세히 다루었습니다 — 근본 원인은 거의 항상 체인 어딘가의 재입력 오류입니다. 세계은행은 공급망 장벽(관세 절차가 핵심 요소)을 줄이면 모든 수입 관세를 철폐하는 것보다 글로벌 GDP를 최대 6배 더 증가시킬 수 있다고 추정했습니다. 잘못된 관세 데이터의 비용은 단지 체선료 청구서만이 아닙니다. 창고에 묶인 자본, 재고 부족으로 인한 매출 손실, 그리고 예측 불가능한 리드 타임으로 인한 경쟁력 약화까지 포함합니다.

브로커 데스크가 20년 동안 바뀌지 않은 이유

비용이 이렇게 높은데 왜 시장이 해결책을 강요하지 않았을까요? 그 답은 관세 생태계 전체에 흐르는 인센티브 불일치에 있습니다.

관세사는 데이터 품질이 아닌 건수당 보수를 받습니다. 엔트리 작성자의 생산성은 처리량, 즉 하루에 처리하는 엔트리 수로 측정됩니다. 업계 기준은 단순 및 복합 신고를 혼합 처리하는 작성자 기준 월 150~200건입니다. 처리량에 쫓기면 엔트리당 시간이 줄어들어 HS 코드 정확성 검증이나 신고 가격과 증빙 서류의 대조에 쓸 시간이 부족해집니다. 그러나 오류의 비용(통관 지연, CBP 문의, 벌금)은 브로커가 아닌 수입자나 포워더에게 돌아갑니다. 데이터 입력을 담당하는 당사자가 데이터 입력 오류에 대한 비용을 부담하지 않는 구조입니다.

포워더는 데이터 관리가 아닌 운송에 대한 보수를 받습니다. 포워더의 수익은 화물 이동(통합, 예약, 경로 지정)에서 발생합니다. 관세 데이터는 핵심 서비스가 아니라 화물에 딸린 필요악입니다. 포워더는 브로커에게 서류를 전달합니다. 서류에 오류가 있으면 브로커가 잡아내거나 세관이 잡아냅니다. 어느 쪽이든 포워더의 보수 구조는 상류의 데이터 품질을 제재하지 않습니다. 체인의 각 당사자는 데이터 문제를 다음 당사자에게 떠넘길 인센티브를 갖습니다.

데이터를 원천에서 바로잡을 최적의 위치에 있는 화주는 직접적인 노출이 가장 적습니다. 국제 운송을 하는 제조업체나 소매업체는 상업 송장과 포장 명세서를 작성합니다. 이 서류는 한 번만 만들어집니다. 화주는 데이터가 자신의 손을 떠난 후 어떻게 처리되는지 거의 보지 못합니다. 재입력 과정을 보지 못합니다. 포워더가 전가하지 않는 한 체화료 청구서도 받지 못합니다. 그리고 그 시점에는 지연을 초래한 데이터 오류가 이를 예방할 수 있었던 사람과 조직상 세 단계나 떨어져 있습니다.

이러한 책임의 분산이 관세 데이터 관리를 소프트웨어 문제가 아닌 구조적 문제로 만듭니다. 세계 최고의 AI 문서 추출 도구를 화주 단계에 배포해도 추출된 데이터가 각 단계에서 사람의 재입력 없이 포워더의 TMS, 브로커의 ABI 소프트웨어, PGA 포털로 직접 흘러들어가지 못한다면, 다섯 단계 체인 중 첫 단계만 디지털화한 것에 불과합니다.

이러한 격차를 메울 기술은 이미 존재합니다. 엔트리 작성자가 수시간 동안 수동으로 읽는 바로 그 서류인 상업 송장, 포장 명세서, 선하증권에서 구조화된 데이터를 추출하는 도구는 이미 작동합니다. 관세 신고 데이터를 Excel로 추출하는 전체 워크플로우를 다룬 적이 있습니다. 핵심 메커니즘은 비전-언어 모델 접근법입니다. 추출할 열(수하인 이름, HS 코드, 신고 가격, 원산지, 인코텀즈)을 정의하고 서류를 업로드하면 AI가 페이지에서의 위치가 아닌 의미를 이해하여 각 값을 찾아냅니다. 출력은 구조화된 테이블(Excel, CSV)로, 모든 다운스트림 시스템의 단일 진실 공급원 역할을 할 수 있습니다. 최소한 추출 단계는 더 이상 수동일 필요가 없습니다.

하지만 추출은 첫 단계일 뿐입니다. 진짜 해결책은 추출된 데이터를 최종적으로 필요한 플랫폼에 연결하는 데 있습니다. 여러 국가에 걸친 화물을 처리하는 포워더의 경우 — 각기 다른 HS 코드 요건을 가진 서로 다른 국가 시스템에 각기 다른 세관 신고서를 제출해야 하는 상황에서 — 여러 세관 신고서를 하나의 스프레드시트로 일괄 처리하면 건별 수동 추출 비용은 최소한 제거할 수 있습니다. 물론 제출 단계에서는 여전히 플랫폼별 제출이 필요하지만요. 바로 여기서 구조적 과제 — 분산된 표준, 비호환적 신고 시스템, 어긋난 인센티브 — 가 운영적 과제와 충돌합니다. 병목은 문서를 읽는 데 있지 않습니다. 그 이후의 과정에 있습니다.

자주 묻는 질문

세관 브로커가 자사 TMS를 세관 당국 시스템에 직접 연결하지 못하는 이유는 무엇인가요?

대부분의 경우 연결할 수 있습니다. 미국의 ABI 소프트웨어는 ACE에 직접 연결되며, 대부분의 선진국에도 유사한 직접 신고 아키텍처가 존재합니다. 문제는 브로커와 세관 간의 연결이 아닙니다. 문제는 그 연결 이전의 모든 과정입니다. 즉, 송하인 문서에서 데이터를 추출하고, 이를 정확하게 브로커 시스템에 입력하며, 별도 플랫폼에 있는 포워더 및 PGA 데이터와 조정하는 일입니다. 세관까지의 마지막 구간은 디지털화되어 있습니다. 그러나 처음 세 구간은 그렇지 않습니다.

WCO 데이터 모델이 상호운용성 문제를 해결해 주지 않나요?

WCO 데이터 모델은 상호운용 가능한 세관 데이터를 위한 어휘를 제공합니다. 즉, 표준화된 데이터 요소, 메시지 형식, 정보 패키지를 제공합니다. 하지만 이 모델이 제공하지 않는 것은 구속력 있는 구현 의무입니다. 각 국가는 이 모델을 자국 세관 IT 인프라에 채택할지, 그리고 어떻게 채택할지를 스스로 결정합니다. 그 결과는 아무도 사용할 의무가 없는 공통 사전입니다. 참고용으로는 유용하지만, 통합을 위한 수단으로는 부족합니다.

AI 문서 추출 도구가 세관 서류의 다양한 형식을 처리할 수 있나요?

상업 송장, 포장 명세서, 선하증권, 원산지 증명서는 국가 내에서조차, 그리고 서로 다른 거래 파트너 간에는 더욱이 매우 상이한 레이아웃을 가지고 있습니다. 최신 AI 기반 추출 도구는 형식에 구애받지 않습니다. 템플릿 패턴이 아닌 의미론적 콘텐츠를 이해하여 문서를 읽기 때문입니다. "수하인" 또는 "HS 코드" 필드가 페이지의 어디에 있든 찾아낼 수 있습니다. 깨끗한 문서의 인쇄 텍스트에 대한 추출 정확도는 99%에 달할 수 있습니다. 한계는 AI의 읽기 능력이 아니라, 생성된 데이터가 이를 소비하는 시스템으로 들어갈 경로가 여전히 필요하다는 점입니다.

화물운송사가 오늘날 관세 데이터 비용을 줄이기 위해 할 수 있는 가장 큰 한 가지는 무엇인가요?

문서 수령 시점에 데이터 품질 문제를 직접 해결하는 것입니다. 선적 서류 PDF를 그대로 브로커에게 전달하는 대신, 문서가 하류로 이동하기 전에 주요 데이터 필드를 구조화된 형식으로 추출하세요. 체인에서 구조화된 데이터를 더 일찍 만들수록 오류 위험을 수반하는 재입력 단계가 줄어듭니다. 브로커에게 전달된 PDF가 아닌 구조화된 선적 데이터를 제공하는 화물운송사는 브로커의 수동 추출 단계와 그에 따른 오류를 제거합니다. 이것이 국가별 세관 시스템 간의 상호운용성 문제를 해결하지는 못하지만, 체인에서 피할 수 있는 비용의 가장 큰 단일 원인을 제거합니다.

관세 데이터 자동화는 IT 팀을 갖춘 대형 화물운송사에게만 가능한가요?

과거에는 TMS 플랫폼과 세관 신고 소프트웨어 간의 맞춤형 통합에 대형 화물운송사만 감당할 수 있는 개발 리소스가 필요했습니다. AI 기반 문서 추출 도구는 이러한 공식을 바꿨습니다. 템플릿 설정 없이 모든 문서에서 작동하고, 표준 형식(Excel, CSV)으로 출력하며, 사용에 API 개발이 필요하지 않습니다. 월 수백 건의 선적을 처리하는 소규모 화물운송사도 상업송장에서 문서당 몇 초 만에 구조화된 데이터를 추출할 수 있습니다. 이는 이전에 전담 데이터 입력 팀이나 값비싼 맞춤형 통합이 필요했던 것과 동일한 기능입니다.