추출된 BOL 데이터를
수동 재입력 없이 TMS에 연동하는 방법

진짜 문제는 데이터 추출이 아닙니다 — 추출과 TMS 사이의 간극입니다

BOL에서 데이터를 가져오는 것은 이미 해결된 문제입니다. 현대 AI 추출은 Maersk, MSC, Hapag-Lloyd 또는 지역 NVOCC 하우스 선하증권 등 모든 운송사 형식에서 발송인 이름, 수하인 정보, 컨테이너 번호, 중량, 항구 정보를 몇 초 만에 추출할 수 있습니다. 더 어려운 부분은 그 다음입니다. 추출된 데이터는 스프레드시트에 남아 있고, TMS는 사람이 직접 입력할 때까지 기다려야 합니다.

이 '데이터 추출'과 'TMS 입력' 사이의 간극 때문에 포워더들은 매일 몇 시간씩 낭비하고 있습니다. 한 포워더가 Reddit에 이렇게 말했습니다: "제가 이야기해본 대부분의 포워더들은 수동 데이터 입력에 허덕이고 있으며, 그 시간에 화물을 예약하거나 고객을 관리하는 데 쓰고 싶어합니다." (출처)

운송사 다양성에 따라 문제는 더 악화됩니다. Hapag-Lloyd BOL은 선박명을 오른쪽 상단 헤더 블록에 배치하고, MSC BOL은 로고 아래 표 셀에 넣으며, 지역 NVOCC의 하우스 선하증권은 본문 텍스트에 묻어둘 수 있습니다. 이 문서들을 읽는 운영자는 매 문서마다 각 필드를 시각적으로 찾아낸 후, 해당 TMS 필드에 다시 입력해야 합니다 — 이 과정을 반복합니다. 하루 30개의 BOL을 처리하는 중형 포워더는 운영 업무를 시작하기 전에 순수 타이핑 작업만으로 5~7시간을 소모합니다 (출처). 선적당 수동 BOL 입력 비용은 단순한 생산성 항목이 아닙니다 — 여러분 책상을 통과하는 모든 컨테이너에 부과되는 숨은 세금입니다.

하지만 이 문제를 해결하기 위해 TMS를 교체하거나, 청구 파이프라인을 재구축하거나, 팀을 재교육할 필요는 없습니다. 여러분에게 필요한 것은 TMS가 이미 가지고 있는 가져오기 도어의 형태에 맞는 브리지일 뿐입니다. 모든 TMS에는 이런 도어가 있습니다.

모든 TMS에는 가져오기 도어가 있습니다 — 여기서 찾으세요

추출 도구를 평가하기 전에 TMS의 가져오기 경로를 먼저 파악하세요. 포워더가 사용하는 주요 시스템은 모두 구조화된 데이터 가져오기를 지원합니다. 일반적으로 CSV나 Excel을 통해 이루어지지만, 경로와 필드 요구 사항은 플랫폼마다 다릅니다.

CargoWise One. 대량 업로드 엔진은 사전 형식화된 Excel 또는 CSV 템플릿을 허용하며, 최종 제출 전에 데이터 정확성, 형식 및 중복 여부를 확인하는 내장 검증 기능이 있습니다. 직접적인 프로그래밍 방식 통합을 위해 CargoWise는 XML을 수용하는 eHub 및 Universal Gateway API를 제공하지만, 개발자 참여와 CargoWise 버전 업데이트에 따른 지속적인 유지보수가 필요합니다(출처). CSV 가져오기 경로는 IT 지원 없이도 모든 사용자가 사용할 수 있습니다.

Descartes Forwarder TMS. SaaS 기반 플랫폼은 웹 네이티브 아키텍처를 통해 일반적으로 CSV 매핑을 통해 구조화된 데이터 업로드를 수용합니다. Descartes는 또한 통신사 통신 및 통관 신고를 위한 EDI를 지원하지만, 내부 BOL 데이터 입력의 경우 CSV 가져오기가 대부분의 포워딩 팀에게 가장 진입 장벽이 낮은 브리지로 남아 있습니다.

SAP Transportation Management. SAP TM은 NWBC 인터페이스를 통해 화물 주문 생성을 처리하며, 프로그래밍 방식 통합을 위해 서비스 인터페이스(SOAP/XML)를 통해 데이터를 수용합니다. 전담 SAP TM 개발자가 없는 팀의 경우 SAP의 데이터 마이그레이션 도구를 통한 구조화된 파일 업로드는 사용자 지정 코드 없이도 실용적인 대안을 제공합니다.

BluJay / E2open TMS. 이 플랫폼은 가격 책정, 입찰, 자동 적재 할당을 지원하며, CSV와 EDI가 일반적인 데이터 수집 형식입니다.

모든 TMS에서 패턴은 동일합니다. TMS는 이미 구조화된 데이터를 가져오는 방법을 알고 있습니다. 병목 지점은 TMS가 아니라, BOL 데이터를 일일이 입력하지 않고 구조화된 형식으로 만드는 것입니다. 이 간극만 해결하면 나머지 워크플로우는 그대로 유지됩니다.

추출 결과를 TMS 가져오기 템플릿에 맞게 조정하기

대부분의 자동화 시도를 무산시키는 미묘한 마찰점이 있습니다. 데이터를 추출한 후에도 TMS 가져오기 형식에 맞게 출력 결과를 다시 포맷팅해야 한다는 점입니다. CargoWise 대량 업로드 템플릿이 B열에 "Ref No"를 요구하는데, 추출 결과가 D열에 "PRO Number"를 넣는다면, 수동 작업 하나를 다른 수동 작업으로 바꾼 것에 불과합니다. 이것이 자동화를 시도한 팀에서도 수동 BOL 입력이 지속되는 이유입니다. 포맷팅 단계에서 시간 절감 효과가 사라지기 때문입니다.

해결책은 처음부터 추출 열 이름을 TMS 가져오기 템플릿과 일치시키는 것입니다. 이 열 이름 기반 추출 방식은 기존 OCR과 다르게 작동합니다. 페이지의 모든 텍스트를 스캔하여 파일에 덤프한 후 다시 파싱하는 대신, TMS가 요구하는 정확한 필드 이름("SHIPPER_NAME", "CONTAINER_NO", "VESSEL_VOYAGE")을 지정합니다. 추출 엔진은 데이터의 위치가 아닌 의미를 이해하여 각 BOL 페이지에서 해당 값을 찾습니다. Maersk BOL, MSC BOL, 지역 NVOCC 하우스 선하증권 모두 동일한 열 구성으로 읽을 수 있습니다. 운송사별 템플릿 설정 없이 모든 운송사의 BOL 데이터를 구조화된 열로 추출할 수 있습니다.

CargoWise 가져오기 템플릿에 "SHIPPER", "CONSIGNEE", "CONTAINER", "WEIGHT_KG", "VOYAGE"가 필요하다면, 추출 열 이름을 정확히 이렇게 설정하세요. 추출된 결과는 미리 매핑되어 제공됩니다. 즉, 열 머리글이 TMS 가져오기 템플릿과 일대일로 일치합니다. CSV로 내보낸 후 바로 가져오기만 하면 됩니다. 재포맷, 열 재정렬, 수동 변환 테이블이 필요 없습니다. 한 번만 설정하면 이후 모든 BOL이 동일한 경로를 따릅니다.

이 원칙은 모든 TMS에 동일하게 적용됩니다. Descartes 가져오기 매핑, SAP TM 데이터 마이그레이션, BluJay CSV 수집 등 모두 구조화된 필드 이름을 받아들입니다. 유일한 변수는 TMS 가져오기 템플릿이 요구하는 특정 필드 이름이며, 이를 한 번만 설정하면 됩니다.

일괄 처리는 이를 더욱 확장합니다. 8개 다른 선사의 BOL 20개를 한 번에 업로드하고, TMS에 매핑된 열 머리글로 단일 CSV에 함께 추출한 다음, 전체 배치를 TMS 대량 업로드로 한 번에 가져올 수 있습니다. BOL당 소요 시간이 분 단위에서 초 단위로 단축됩니다.

선사 PDF에서 TMS 레코드까지: 종단 간 경로

CargoWise One을 사용하는 포워더를 위한 구체적인 워크스루입니다. 하지만 이 패턴은 CSV 가져오기 기능이 있는 모든 TMS에 적용됩니다.

BOL 3건의 총 소요 시간: 2분 미만, 대부분은 검토 시간입니다. 동일한 BOL 3건을 수동으로 입력하면 30~45분이 소요되며, 컨테이너 번호와 중량을 수기로 옮기는 과정에서 오류율이 높아 대부분의 팀이 어차피 2차 검토 주기를 추가합니다. 검토 단계를 추가하는 것이 아니라, 30분의 타이핑을 30초의 확인으로 대체하는 것입니다.

변하지 않는 것: 다운스트림 워크플로우는 그대로 유지

CSV로 가져온 데이터가 TMS에 입력되면, 시스템은 이를 수동 입력 데이터와 구조적으로 구분하지 못합니다. 송장 모듈, 세관 신고, 고객 포털 모두 동일한 필드와 기록을 참조합니다.

송장 처리. TMS가 자동 생성하든 청구팀이 수동 작성하든, 송장의 발송인·수하인 정보, 중량, 컨테이너 데이터는 모두 동일한 데이터 구조에서 가져옵니다. 송장 템플릿이나 청구 워크플로우를 변경할 필요가 없습니다. 미수금 팀은 불일치 참조번호 문의가 줄어든 것 외에는 차이를 느끼지 못합니다.

세관 신고. CargoWise의 자동 세관 신고는 기존 선적 기록에서 발송인, 수입자, 선하증권 데이터를 가져옵니다. 세관 모듈은 항상 동일한 위치에서 데이터를 읽습니다. 컨테이너 번호 한 자리 오류는 검사 지연을 초래할 수 있지만, 추출 엔진은 피곤한 작업자와 달리 숫자를 잘못 입력하지 않습니다.

고객 커뮤니케이션. 추적 포털, 이정표 알림, 선적 상태 이메일은 모두 TMS 선적 데이터를 활용합니다. 시스템 관점에서 데이터 소스는 변경되지 않았으며, 데이터 입력 방식만 달라졌을 뿐입니다. 다운스트림 시스템은 동일한 기록에서 동일한 필드를 읽습니다.

이것이 워크플로우 통합의 핵심입니다. 추출 계층은 기존 시스템의 상위에 위치하며, 입력 방식만 변경할 뿐 시스템 자체는 바꾸지 않습니다. 마치 적재장에 컨베이어 벨트를 추가하는 것과 같습니다. 창고, 재고 시스템, 트럭은 그대로입니다.

CSV 브릿지가 직접 API 통합보다 더 적합한 경우

두 방식 모두 유효합니다. 선택은 데이터 규모, 기술 리소스, 실시간 데이터 흐름의 필요성에 따라 달라집니다.

직접 API 통합(CargoWise eHub, SAP TM 서비스 인터페이스, Descartes EDI 커넥터 등)은 추출된 데이터를 CSV 중간 단계 없이 TMS 레코드에 직접 전송합니다. 배포는 일반적으로 4~8주가 소요되며, 발견, 구축, 테스트, 라이브 단계를 포함합니다(출처). 장점은 추출과 TMS 입력 사이에 수동 단계가 없다는 점입니다. 단점은 XML 스키마 매핑을 위한 개발자 작업, TMS API 변경에 따른 지속적인 유지보수, 그리고 다른 TMS로 전환할 수 없는 벤더 종속적 구현이 필요하다는 점입니다. EDI 및 직접 API 방식은 나름의 장점이 있지만, 구현에 상당한 노력이 필요합니다.

반면 CSV 브릿지는 구조화된 파일 가져오기를 지원하는 모든 TMS(사실상 모든 TMS)에서 작동하며, 초기 열 구성 이후에는 IT 개입이 전혀 필요 없고, 설정에 몇 주가 아닌 1시간 미만이 소요됩니다. 단점은 추출과 가져오기 사이에 30초의 검토 단계가 있다는 점입니다.

월 50~500건의 BOL을 처리하는 포워더라면 CSV 브릿지가 거의 항상 올바른 출발점입니다. 구현 노력의 극히 일부만으로 대부분의 시간 절감 효과를 얻을 수 있습니다. BOL 처리를 100건에서 1,000건으로 확장하는 데 첫날부터 API 통합이 필요한 것은 아닙니다. 필요한 것은 CSV 브릿지를 작동하게 하는 열 매핑 규율이며, 이는 나중에 직접 API에 투자할 때 스키마 사양이 됩니다.

볼륨이 증가하여 30초 검토 간격이 주당 몇 시간에 달하게 되면 API 경로에 투자할 가치가 생깁니다. 이미 설정한 열 매핑은 개발자가 필요로 하는 정확한 사양 역할을 합니다.

자주 묻는 질문

BOL이 운전자의 스캔 PDF나 휴대폰 사진으로 도착하면 어떻게 하나요?

최신 AI 추출은 스캔 페이지, 휴대폰 사진, 네이티브 PDF를 읽습니다. PDF에 텍스트 레이어가 필요하지 않습니다. 운전자가 창고 게이트에서 종이 BOL을 찍은 사진도 디지털 생성 Maersk PDF와 동일한 추출 결과를 제공합니다. 여백의 수기 컨시니 노트나 수정 사항도 인쇄된 필드와 함께 읽힙니다.

매주 다른承运人(carrier)의 BOL을 처리해도 작동하나요?

네, 이 접근 방식이 가장 가치 있는 부분입니다. 템플릿 기반 도구는 각承运人(carrier) 형식에 대한 레이아웃을 학습시켜야 합니다. 열 이름 추출은 데이터의 의미("이 페이지에서 선박 이름은 무엇인가?")를 찾기 때문에 위치("선박 이름은 x=300, y=450 좌표에 있다")가 아닌 모든承运人(carrier)의 BOL을 읽습니다. 동일한 열 구성으로 Maersk BOL, MSC BOL, 지역 NVOCC 하우스 선하증권을承运인(carrier)별 설정 없이 처리합니다. 다중承运인(carrier) BOL을 Excel로 추출은 재구성 없이 모든 형식에서 작동합니다.

BOL에서 어떤 TMS 필드를 추출해야 하나요?

대부분의 포워딩 워크플로우를 포괄하는 최소 필드: 선적인 이름 및 주소, 수하인 이름 및 주소, 통지처, 선박명, 항차 번호, 선적항, 양륙항, 컨테이너 번호, 봉인 번호, 화물 설명, 총중량 및 순중량, 개수, MBL 번호, HBL 번호. LTL 화물의 경우 PRO 번호를 추가하세요. 사용하는 열 이름은 TMS 가져오기 템플릿의 이름과 정확히 일치해야 합니다. 기억에 의존하지 말고 템플릿에서 복사하세요.

단일 문서에 여러 컨테이너가 나열된 BOL은 어떻게 처리하나요?

CONTAINER_NO와 SEAL_NO를 별도의 열로 설정하세요. 추출 엔진이 다중 컨테이너 BOL을 컨테이너별 행으로 분할합니다. 각 행에는 고유한 컨테이너 번호, 봉인 번호 및 관련 중량이 할당되므로 TMS는 컨테이너당 하나의 행을 수신합니다. 이는 대부분의 TMS 플랫폼이 기본적으로 선적 기록을 구성하는 방식과 일치합니다.

추출된 데이터에 오류가 있으면 어떻게 하나요?

추출과 가져오기 사이의 검토 단계가 안전망 역할을 합니다. 이 단계는 자동화되지 않으며, 의도적인 설계입니다. 추출된 스프레드시트를 열고 컨테이너 번호와 중량을 원본 PDF와 대조하여 확인한 후, 잘못된 필드는 가져오기 전에 수정하세요. 이 30초 검토로 완전 자동화 시스템이 완벽하게 처리하지 못하는 예외 사례(번짐이 있는 PDF 스캔, BOL 여백의 수기 수정, 비표준 단위로 기재된 중량 등)를 잡아냅니다. 명확한 트레이드오프가 있습니다. 10~15분의 완전 수동 입력이 30초의 목표 검증으로 전환됩니다.

이 방식은 세관 및 규제 요구 사항을 준수하나요?

데이터 정확도가 향상됩니다. 추출 엔진이 모든 운송사 형식에 일관된 해석을 적용하여, 특히 긴 컨테이너 번호와 단위 변환에서 수동 입력 시 발생하는 전사 오류를 제거합니다. 세관 신고에서 데이터 정확도는 선택 사항이 아닙니다. 입항 신고서의 컨테이너 번호 오류는 검사 지연을 초래할 수 있습니다. 수입 전 검토 단계는 규정 준수 확인 지점을 제공합니다. 다양한 운송사의 BOL 필드에 걸친 데이터 정확도는 본질적으로 어려운 문제입니다. 모든 것을 잡아내는 시스템은 없지만, 추출과 대상 검토를 결합하면 피로한 작업자의 전사보다 확실히 더 신뢰할 수 있습니다.

Excel 대신 Google Sheets에서 사용할 수 있나요?

네. 추출 결과를 Google Sheets로 직접 내보낼 수 있습니다. 팀이 데이터가 TMS에 입력되기 전에 운영 추적을 위해 Sheets에서 작업하는 경우, 흐름은 다음과 같습니다: BOL 데이터를 Sheets로 추출 → 검토 및 확인 → Sheets에서 CSV로 내보내기 → TMS로 가져오기. ImageToTable.ai의 Google Sheets 사이드바 애드온을 사용하면 스프레드시트 작업 공간을 떠나지 않고도 BOL 데이터를 시트에 직접 추출한 다음, 검토된 CSV를 TMS 업로드용으로 내보낼 수 있습니다.

데이터 입력 직원을 더 고용하는 것과 어떻게 다른가요?

데이터 입력 직원은 여전히 BOL당 10~15분이 소요되며, 운송사 형식 변동에 대한 교육이 필요하고, 물량이 증가함에 따라 오류가 누적됩니다. 인원을 추가하면 비용이 운송 물량에 비례하여 선형적으로 증가합니다. CSV 브리지는 한계 비용이 거의 0에 가깝게 확장됩니다. 100개의 BOL을 처리하는 데 드는 문서당 시간은 10개를 처리하는 것과 거의 동일합니다. 작업자의 역할은 데이터 입력에서 예외 처리(플래그가 지정된 필드 검토 및 에지 케이스 해결)로 전환되며, 이는 더 가치 있는 작업입니다.

CSV 브리지는 제품이 아니라 방법론입니다. 구조화된 열을 출력하는 모든 추출 도구와 CSV 가져오기를 지원하는 모든 TMS에서 작동합니다. 핵심은 첫날부터 추출 열 이름을 TMS 가져오기 템플릿에 맞추는 것으로, 대부분의 자동화 시도를 막는 재포맷 단계를 없애는 것입니다. 받은 편지함에서 BOL PDF를 꺼내고, 가져오기 템플릿 열을 한 번만 매핑하면 문서당 10분이 30초로 줄어드는지 확인해보세요. 자신의 BOL로 테스트해보세요 — 오늘 구축하는 브리지는 내일 개발자에게 넘길 API 스키마가 됩니다.