여러 선사의 선하증권을 일괄 처리하여
하나의 스프레드시트로 통합

단일 BOL 대 500건: 단일 문서 튜토리얼이 다루지 못하는 효율성 격차

AI 기반 추출을 통해 단일 선하증권을 Excel로 추출하는 데는 5~10초가 소요되며, 이는 수동 입력보다 약 18배 빠릅니다. 이는 문서 수준 자동화의 표준 벤치마크이며, BOL을 Excel로 추출하는 작업을 한 번에 하나씩 수행하면 안정적으로 달성할 수 있습니다.

그러나 단일 문서 처리 속도는 운영 규모에서 병목 현상이 아닙니다. 병목 현상은 문서 사이의 공간에 있습니다. Maersk BOL, MSC BOL, COSCO 템플릿, Hapag-Lloyd 형식, ONE 레이아웃 간 전환 — 각각 필드 위치, 명명 규칙, 테이블 구조가 다릅니다 — 그리고 모든 행에서 B/L 번호가 동일한 의미를 갖는 통합 스프레드시트를 생성하는 데 누적되는 마찰입니다.

화물 포워더 운영에 대한 Expedock 분석에 따르면, 운영 직원은 하루에 2~4시간을 운송 관리 시스템에 데이터를 입력하고 감사하는 데 사용합니다. 월 300건의 선적을 처리하는 팀의 경우, 데이터 입력만으로 150시간이 소모됩니다. 이는 요율 협상, 예외 처리 또는 고객 서비스에 사용할 수 없는 시간입니다. 비용은 문서당 몇 분이 아니라, 여러 운송사에 걸쳐 매월 누적되는 시간에 있습니다.

다중 운송사 BOL이 템플릿 기반 추출을 무너뜨리는 이유

해상 화물 업계는 소수의 주요 선사들 — 머스크, MSC, CMA CGM, COSCO, 하팍로이드, ONE, 에버그린, HMM, 양밍, ZIM — 이 장악하고 있으며, 각 선사는 자체 독점 템플릿으로 선하증권을 발행합니다. 차이점을 살펴보겠습니다:

• 항목 명칭. 머스크가 "선박/항차"라고 표기하는 것을 MSC는 사이드바 패널에 "선박명"으로, 지역 선사는 본문에 "운송 선박"이라고 부릅니다. 동일한 정보에 세 가지 다른 명칭이 사용됩니다.
• 위치. B/L 번호는 한 선사 템플릿의 오른쪽 상단에, 다른 선사는 왼쪽 하단에 위치할 수 있습니다. 컨테이너 번호는 헤더 테이블, 여러 줄 목록, 또는 화물 설명과 함께 인라인으로 표시될 수 있습니다.
• 데이터 형식. 한 선사는 날짜를 DD/MM/YYYY로, 다른 선사는 MM-DD-YYYY로 표기합니다. 중량은 무역 항로와 선사 관행에 따라 킬로그램, 파운드 또는 미터톤으로 표시될 수 있습니다.
• 페이지 구조. 단일 컨테이너 BOL은 1페이지입니다. 동일 선사의 다중 컨테이너 BOL은 5페이지까지 늘어날 수 있으며, 다른 선사는 다중 컨테이너 화물을 완전히 다른 방식으로 구성합니다.

국제 무역 분야에서 1,500개 이상의 회원사와 110,000명의 직원을 대표하는 미국 관세사 및 포워더 협회(NCBFAA)의 회원사 중에는 미국 전체 수입 신고의 97% 이상을 처리하는 포워더들이 포함되어 있습니다. 이 포워더들은 매일 매시간 선사별 다양한 형식을 처리해야 합니다.

템플릿 기반 추출 도구는 이러한 다양성에 대응하기 위해 각 운송사의 레이아웃에 맞는 별도의 템플릿을 필요로 합니다. 15개 운송사와 거래한다면 15개의 템플릿을 만들어야 합니다. 운송사가 BOL 디자인을 업데이트할 때(리브랜딩, 규정 준수, 시스템 마이그레이션 등), 템플릿은 조용히 깨집니다. 수동 입력을 없애기 위한 도구가 템플릿 관리라는 새로운 유지보수 부담을 만들어낸 것입니다. 문제는 운송사 수에 비례해 확장되며, 템플릿 업데이트의 계기는 항상 누군가 데이터 흐름이 멈춘 것을 인지할 때입니다.

국제복합운송협회(FIATA)는 전자 FBL 데이터 표준을 통해 표준 수준에서 형식 파편화 문제를 해결하고 있습니다. 이는 UN/CEFACT 복합운송 참조 데이터 모델에 매핑된 양도성 복합운송 선하증권(FBL)의 오픈소스 디지털 버전입니다. 그러나 운송사들의 eFBL 채택은 점진적이며, 오늘날 포워더의 받은편지함에 도착하는 종이 및 PDF BOL은 표준 수렴을 기다리지 않습니다. 포워더는 어떤 형식이든 도착하는 데이터를 추출해야 합니다.

하나의 컬럼 목록, 모든 운송사: BOL 형식 전반에서 의미론적 추출이 작동하는 방식

운송사별 템플릿의 대안은 컬럼명 추출입니다. 각 값이 특정 운송사 페이지의 어디에 있는지 정의하는 대신, 찾고자 하는 정보 카테고리를 정의합니다. AI는 문서를 의미론적으로 읽어 데이터의 좌표가 아닌 의미를 이해하며, 값이 나타나는 위치가 아닌 값의 정체성에 따라 값을 찾습니다.

구체적인 예시입니다. "B/L 번호"라는 열을 정의합니다. AI가 Maersk BOL에서 헤더에 "Bill of Lading No. MAEU123456789"를 발견하면 패턴을 인식하여 "MAEU123456789"를 추출합니다. MSC BOL에서 B/L 번호가 사이드바 상자에 다른 형식으로 "MEDU987654321"이라고 표시되어 있어도 AI는 둘 다 선하증권 식별자임을 이해하므로 "MEDU987654321"을 추출합니다. 이는 두 값이 동일한 픽셀 좌표에 있기 때문이 아니라, 정의한 열 이름이 대상 개념이기 때문입니다. AI는 모든 선사의 형식에서 해당 값을 찾아냅니다.

일반적인 포워더 BOL 추출 워크플로에 필요한 필드 목록이며, 수정 없이 모든 선사에서 작동합니다:

이 컬럼명들은 한 번만 정의하면 됩니다. 문서마다 설정할 필요 없이, 출력 스프레드시트의 헤더로 고정됩니다. 이후 모든 운송사에서 처리하는 모든 BOL은, 원본 문서의 레이아웃, 라벨, 페이지 수와 관계없이 동일한 순서의 동일한 컬럼으로 행이 생성됩니다. 12개 운송사에서 들어온 50개의 BOL을 배치 처리하면, 수동으로 이어붙여야 할 12개의 표가 아닌, 하나의 표가 만들어집니다.

이 방식은 전혀 다른 형태의 BOL 유형도 처리합니다. 운송사가 포워더에게 발행하는 해상 Master B/L(MBL), 포워더가 화주에게 발행하는 해상 House B/L(HBL), 그리고 항공화물운송장(AWB) — 시각적 레이아웃, 필드명, 데이터 모델이 모두 다른 세 문서가 동일한 컬럼 구조의 행을 생성합니다. AI는 위치 기반이 아닌 의미 기반으로 읽기 때문에 문서 유형에 자동으로 적응합니다.

배치 워크플로우: 운송사 받은 편지함에서 관리 스프레드시트까지

포워더의 월요일 아침은 대개 주말에 출항한 선사의 BOL PDF가 도착하면서 시작됩니다. 이메일 첨부파일, 운송사 포털 다운로드, 또는 선적지 에이전트가 전달한 문서 등 다양한 경로로 들어옵니다. 여기서 중요한 것은 단 하나의 BOL을 빠르게 추출하는 것이 아니라, 고객이 선적 상태 업데이트를 묻기 전에 모든 BOL을 추적 스프레드시트에 입력하는 것입니다.

다음은 일괄 처리 워크플로우(여러 파일을 한 번에 업로드하면 AI가 동일한 열 정의를 사용하여 모두 처리하고 하나의 통합 결과물을 생성)가 아침 업무를 어떻게 변화시키는지 보여줍니다:

단일 BOL 페이지의 처리 시간은 5~10초 범위입니다. 50페이지 분량의 단일 BOL 일괄 처리는 몇 분 안에 완료됩니다. 제한 요소는 형식 다양성이 아닌 총 페이지 수입니다. 워크플로우에 16번째 운송사를 추가해도 추가 설정 시간이 전혀 들지 않습니다. 의미론적 추출은 작업하는 운송사 수에 관계없이 작동하기 때문입니다.

모든 운송사 형식의 선하증권 데이터 추출에 대한 자세한 내용은 전용 변환기 도구를 참조하세요.

문제 발생 시 대처: 대규모 예외 처리

단일 문서 추출에서 예외는 불편함에 불과합니다. 수정하고 넘어가면 됩니다. 그러나 15개 운송사에 걸친 일괄 처리에서 예외를 효율적으로 해결하는 것이 오후 3시에 퇴근할지 7시에 퇴근할지를 결정합니다. 이 규모에서의 예외 처리 방식은 이상적인 경로보다 훨씬 중요합니다.

다중 운송사 BOL 일괄 처리에서 가장 흔한 세 가지 실패 유형:

운송사 템플릿 업데이트. 머스크가 BOL 레이아웃을 재설계(특정 필드 이동, 테이블 재구성, 페이지 구조 조정)했을 때, 템플릿 기반 추출 도구는 누군가 템플릿을 다시 구축할 때까지 해당 필드를 추적하지 못했습니다. 열 이름 추출은 이와 다르게 처리합니다. AI가 픽셀 위치에 고정되지 않기 때문에, 정보 내용이 동일하게 유지되는 한 레이아웃 변경이 추출을 중단시키지 않습니다. B/L 번호는 재설계된 페이지의 어디에 나타나든 여전히 B/L 번호입니다.

스캔 품질 편차. 머스크 시스템에서 깨끗한 PDF로 도착한 BOL과 형광등 창고 조명 아래서 촬영되어 원산지 에이전트가 전달한 BOL은 동등한 입력이 아닙니다. 흐릿한 컨테이너 번호, 번진 중량 필드, 기울어진 페이지 방향은 추출 신뢰도를 낮춥니다. AI는 이를 검토 대상으로 플래그 지정합니다. 작업자는 올바르게 추출된 데이터를 일일이 살펴보지 않고도 어떤 필드에 주의가 필요한지 확인할 수 있습니다. BOL의 중요한 수기 수정 사항(수동으로 추가된 중량 조정, 봉인 번호 변경)의 경우, 저하된 스캔에서 완전 자동 추출을 기대하기보다는 빠른 검토 과정을 계획하세요.

누락 및 모호한 필드. 모든 운송사가 모든 BOL에 모든 필드를 포함하는 것은 아닙니다. 지역 운송사는 HS 코드를 생략할 수 있습니다. LCL 혼재 BOL은 봉인 번호를 비워둘 수 있습니다. 템플릿 기반 도구는 누락된 필드를 추출 실패로 처리하는 경우가 많습니다. 의미 기반 추출은 다르게 처리합니다. 해당 필드는 단순히 비어 있는 상태로 반환되며, 작업자는 다른 문서(패킹 리스트, 상업 송장)에서 누락된 데이터를 가져올지 아니면 그대로 진행할지 결정합니다. 패킹 리스트와 BOL을 동일한 배치에서 함께 처리하고, 문서 유형 간에 중복되는 필드를 활용하는 것은 이 워크플로우의 자연스러운 확장입니다.

실질적인 결과: 열 이름 추출 방식으로 처리된 50개의 BOL 배치에서 검토 단계는 플래그가 지정된 약 2~5개의 문서에 집중되며, 50개 문서 모두를 한 줄씩 확인할 필요가 없습니다.

모든 항구에서 BOL이 도착할 때: 컬렉션 링크

화물 포워더의 문서 흐름은 정의상 지리적으로 분산되어 있습니다. 상하이 선적항에서 실제 BOL을 처리하는 사람과 로테르담이나 시카고 본사에서 관리 스프레드시트를 관리하는 사람은 다릅니다. 데이터 입력 데스크에 도달해야 하는 모든 실제 문서는 한 번의 추가 전달(이메일 전달, 포털 다운로드, WhatsApp 사진)을 의미하며, 모든 전달은 잠재적 지연이나 오발송의 원인이 됩니다.

수집 링크는 이러한 분산 문제를 직접 해결합니다. 수집 링크는 고유하며 공유 가능한 업로드 페이지(예: /c/xxxx와 같은 URL)로, 원본에서 문서를 처리하는 모든 사람(창고 직원, 선적 대리점, 파트너 포워더, 픽업 기사)에게 생성 및 배포합니다. 수신자는 링크를 열고 짧은 확인 코드를 입력한 후 BOL을 직접 업로드합니다. 계정 생성, 로그인, 교육이 필요 없습니다. 문서는 처리 대기열에 도착하며, 대시보드에서 검토 및 내보내기를 수행합니다.

이렇게 하면 중간 단계가 완전히 제거됩니다. "원본 대리점이 BOL PDF를 운영 데스크에 이메일로 전송 → 운영팀이 첨부 파일 다운로드 → 폴더에 저장 → 추출 도구에 업로드" 대신 "원본 대리점이 수집 링크 열기 → BOL 업로드 → 문서가 검토 및 내보내기 대기열에 표시"로 흐름이 바뀝니다. 세 번의 전달이 제거되었으며, 문서는 발행 후 몇 분 내에 처리 가능해집니다. 때로는 선박이 선적항을 떠나기 전에도 가능합니다.

여러 무역 항로와 시간대에 걸쳐 BOL을 관리하며 전 세계 각지에서 24시간 문서가 도착하는 화물 포워더에게 수집 링크는 순차적이고 이메일에 의존하는 전달 체인을 병렬적이고 직접 업로드하는 파이프라인으로 전환합니다. 모든 항구의 모든 대리점이 동일한 목적지로 업로드합니다.

자주 묻는 질문

더 광범위한 물류 문서 워크플로우를 처리하는 팀을 위해 포장 명세서 및 납품서 일괄 추출 및 공급업체별 구매 주문서 일괄 처리 가이드를 참조하세요. 수동 데이터 입력을 계속하는 비용을 평가 중이라면 수동 데이터 입력의 숨은 비용에 대해 읽어보세요.

단일 문서 워크플로우(필드별 추출, 운송사 형식 처리, 단계별 설정 포함)에 대해서는 API나 IT 설정 없이 선하증권 데이터를 Excel로 추출하는 방법을 참조하세요.