다양한 해운사의 선하증권을 배치 처리하여
하나의 스프레드시트로 통합
중견 포워더는 월 평균 약 500건의 선하증권을 10~20개의 서로 다른 해운사를 통해 처리합니다. 문서당 10~15분이 소요되는 읽기, 입력, 검증 작업 — CSA Software의 포워딩 수동 데이터 입력 분석에서 제시된 기준 — 은 매월 83~125시간의 인력이 단순 전사 작업에만 투입되는 셈입니다. 예외 처리도, 해운사 후속 조치도, 화물 이동을 위한 의사 결정 업무도 아닙니다. 단지 PDF에서 스프레드시트로 데이터를 옮기는 작업일 뿐입니다. 그리고 근본 원인은 물량이 아닙니다. 각 해운사가 동일한 정보를 서로 다른 형식으로 출력하기 때문입니다.

B/L 1건 vs. 500건: 단일 문서 튜토리얼이 다루지 못하는 효율성 격차
AI 기반 추출로 선하증권 1건을 Excel로 변환하는 데는 5~10초가 소요되며, 이는 수동 입력보다 약 18배 빠른 속도입니다. 이는 문서 수준 자동화의 표준 벤치마크이며, B/L을 Excel로 추출하는 작업을 한 건씩 수행하면 이 속도를 안정적으로 달성할 수 있습니다.
하지만 운영 규모에서 병목 현상은 단일 문서 처리 속도가 아닙니다. 병목은 문서 사이의 공간에 있습니다. Maersk B/L, MSC B/L, COSCO 템플릿, Hapag-Lloyd 형식, ONE 레이아웃 간 전환 — 각각 필드 배치, 명명 규칙, 테이블 구조가 다르며 — 이를 하나의 통합 스프레드시트로 만들어 모든 행에서 B/L 번호가 동일한 의미를 갖도록 하는 데서 발생하는 누적 마찰이 바로 그것입니다.
Expedock의 포워더 운영 분석에 따르면, 운영 직원은 하루 2~4시간을 TMS에 데이터를 입력하고 검증하는 데 사용합니다. 월 300건의 화물을 처리하는 팀의 경우, 데이터 입력만으로 월 150시간이 소요되며, 이는 운임 협상, 예외 처리, 고객 서비스에 사용할 수 없는 시간입니다. 비용은 문서당 몇 분이 아니라, 해운사별로 월간 누적되는 시간에 있습니다.
B/L 1건은 몇 초 만에 추출됩니다. 하지만 15개 해운사의 B/L 500건은 단순히 그 숫자의 배수가 아닙니다. 이는 템플릿 기반 도구가 해결하도록 설계되지 않은 형식 관리 문제가 됩니다.
복수 해운사 B/L이 템플릿 기반 추출을 무너뜨리는 이유
해운 업계는 Maersk, MSC, CMA CGM, COSCO, Hapag-Lloyd, ONE, Evergreen, HMM, Yang Ming, ZIM 등 소수의 주요 해운사가 지배하며, 각 해운사는 자체 독점 템플릿으로 선하증권을 발행합니다. 차이점을 살펴보겠습니다:

- 필드 명칭. Maersk가 "Vessel / Voyage"라고 표기하는 것을 MSC는 사이드바 패널에 "Vessel Name"으로, 지역 해운사는 본문 텍스트에서 "Carrier Vessel"이라고 부릅니다. 동일한 정보에 대해 세 가지 다른 명칭이 사용됩니다.
- 위치. B/L 번호는 한 해운사 템플릿의 오른쪽 상단에, 다른 해운사의 왼쪽 하단에 위치할 수 있습니다. 컨테이너 번호는 헤더 테이블, 여러 줄 목록 또는 화물 설명과 함께 인라인으로 나타날 수 있습니다.
- 데이터 형식. 한 해운사는 날짜를 DD/MM/YYYY로, 다른 해운사는 MM-DD-YYYY로 표기합니다. 중량은 무역 항로와 해운사 관례에 따라 킬로그램, 파운드 또는 미터톤으로 표기될 수 있습니다.
- 페이지 구조. 단일 컨테이너 B/L은 1페이지입니다. 동일한 해운사의 다중 컨테이너 B/L은 5페이지까지 늘어날 수 있으며, 다른 해운사는 다중 컨테이너 화물을 완전히 다른 방식으로 구성합니다.
미국 관세사·포워더 협회(NCBFAA)는 국제 무역 분야에서 1,500개 이상의 회원사와 110,000명의 직원을 대표하며, 그 회원사 중에는 미국 전체 수입 신고의 97% 이상을 처리하는 포워더들이 포함되어 있습니다. 이들 포워더는 매일 매시간 다양한 해운사 형식을 처리해야 합니다.
템플릿 기반 추출 도구는 이러한 다양성에 대응하기 위해 각 해운사의 레이아웃별로 별도의 템플릿을 요구합니다. 15개 해운사와 거래한다면 15개의 템플릿을 만들어야 합니다. 해운사가 B/L 디자인을 업데이트하면 — 리브랜딩, 규정 준수, 시스템 마이그레이션 등 어떤 이유로든 — 템플릿은 조용히 깨집니다. 수작업 입력을 없애주는 도구가 오히려 템플릿 관리라는 새로운 유지보수 부담을 만들어낸 것입니다. 문제는 해운사 수에 비례해 커지며, 템플릿 업데이트의 계기는 항상 누군가 데이터 흐름이 멈춘 것을 발견하는 때입니다.
국제포워더협회연맹(FIATA)은 전자 FBL 데이터 표준을 통해 표준 수준에서 형식 분산 문제를 해결하고 있습니다. 이는 UN/CEFACT 복합운송 참조 데이터 모델에 매핑된 FIATA의 복합운송 선하증권(FBL)의 오픈소스 디지털 버전입니다. 그러나 해운사들의 eFBL 채택은 점진적이며, 오늘날 포워더의 수신함에 도착하는 종이 및 PDF BOL은 표준 통합을 기다리지 않습니다. 포워더는 도착하는 어떤 형식에서든 데이터를 추출해야 합니다.
하나의 열 목록, 모든 해운사: BOL 형식 전반에 걸친 시맨틱 추출의 작동 방식
해운사별 템플릿의 대안은 열 이름 추출입니다. 특정 해운사 페이지에서 각 값이 어디에 위치하는지 정의하는 대신, 찾고자 하는 정보 범주가 무엇인지 정의합니다. AI는 문서를 시맨틱하게 읽습니다 — 각 데이터 조각의 의미를 이해하며 좌표가 아닌 의미로 파악합니다 — 그리고 값이 나타나는 위치가 아니라 값이 무엇인지에 따라 값을 찾습니다.
구체적인 예를 들어보겠습니다. "B/L 번호"라는 열을 정의합니다. AI가 헤더에 "Bill of Lading No. MAEU123456789"가 있는 Maersk BOL을 만나면 패턴을 인식하고 "MAEU123456789"를 추출합니다. B/L 번호가 사이드바 박스에 "MEDU987654321"로 다른 형식으로 표시된 MSC BOL을 만나면 "MEDU987654321"을 추출합니다 — AI가 둘 다 선하증권 식별자임을 이해하기 때문이며, 같은 픽셀 좌표에 있기 때문이 아닙니다. 정의한 열 이름이 대상 개념입니다. AI는 모든 해운사의 형식에서 해당 값을 찾습니다.
다음은 일반적인 포워더 BOL 추출 워크플로우에 필요한 필드 목록이며, 수정 없이 모든 해운사에서 작동합니다:
B/L 번호 | 예약 번호 | 송하인 이름 | 수하인 이름 | 통지 당사자
선박 이름 | 항차 번호 | 적재항 | 양륙항
컨테이너 번호 | 봉인 번호 | HS 코드 | 포장 수량
총 중량 | 화물 설명 | 운임 조건
수령 장소 | 인도 장소 | 해운사 이름이 열 이름들을 한 번만 정의하면 됩니다. 일회성 설정이지, 문서별 작업이 아닙니다. 이 이름들이 출력 스프레드시트의 헤더가 됩니다. 모든 해운사에서 처리하는 모든 B/L은 원본 문서의 레이아웃, 라벨링, 페이지 수와 관계없이 동일한 순서로 동일한 열을 가진 행을 생성합니다. 12개 해운사의 B/L 50건을 배치로 처리하면 수작업으로 이어 붙일 필요 없는 하나의 테이블이 생성됩니다.
이 방식은 전혀 다른 형태의 B/L 유형도 처리합니다. 해운사가 포워더에게 발행하는 해상 마스터 선하증권 (MBL), 포워더가 화주에게 발행하는 해상 하우스 선하증권 (HBL), 그리고 항공운송장 — 시각적 레이아웃, 필드 이름, 데이터 모델이 모두 다른 세 가지 문서가 동일한 열 구조의 행을 생성합니다. AI는 위치가 아닌 의미를 읽기 때문에 문서 유형에 자동으로 적응합니다.
핵심 통찰: 선하증권의 정보는 보편적입니다 — 화주, 수하인, 선박, 화물, 중량, 컨테이너. 달라지는 것은 각 해운사가 이를 표시하는 방식뿐입니다. 시맨틱 추출은 정보를 표시 방식에서 분리하여 해운사 형식을 무의미한 변수로 만듭니다.
배치 워크플로: 해운사 받은 편지함에서 관리 스프레드시트까지

포워더의 월요일 아침은 대개 주말에 출항한 해운사로부터 B/L PDF가 도착하면서 시작됩니다. 이메일 첨부 파일, 해운사 포털 다운로드, 또는 오리진 에이전트가 전달한 문서 형태로 옵니다. 우선순위는 단일 B/L을 빠르게 추출하는 것이 아니라, 고객이 선적 상태 업데이트를 문의하기 전에 모든 B/L을 추적 스프레드시트에 넣는 것입니다. 이러한 업데이트는 대개 각 B/L의 추적 번호로 해운사 추적 스크린샷을 캡처하는 것에서 시작됩니다.
여러 파일을 한 번에 업로드하고 AI가 동일한 열 정의를 사용하여 모든 파일을 처리하여 하나의 통합 출력을 생성하는 배치 처리 워크플로가 그 아침 업무를 어떻게 변화시키는지 살펴보겠습니다:
출력할 열을 한 번만 정의하세요. 추출할 필드 이름을 입력하세요 — B/L 번호, 송하인, 수하인, 선박, 적재항, 컨테이너 번호, 총중량 등. 이 필드들이 처리하는 모든 B/L에서 스프레드시트의 열 머리글이 됩니다. 이 설정은 배치나 해운사별 작업이 아닌 일회성 단계입니다. 다운스트림 TMS나 추적 스프레드시트가 특정 헤더 이름을 기대한다면 여기에 그 정확한 이름을 사용하세요 — 시스템이 읽는 이름이 "Container Number" 대신 "ContainerNo"라면 그 이름을 사용하세요 — 그리고 내보내기 후 재포맷 단계를 없앨 수 있습니다.
모든 B/L을 단일 배치로 업로드하세요. PDF, 스캔 문서, B/L 사진을 끌어다 놓으세요 — 해운사, 문서 유형, 페이지 수에 관계없이. Maersk PDF, MSC 스캔본, COSCO 다중 페이지 문서, 지역 해운사 B/L 스크린샷은 모두 동일한 업로드에 들어갑니다. AI가 이들을 그룹으로 처리하며, 모든 문서에 동일한 필드 정의를 사용합니다. 문서 분류, 해운사 그룹화, 사전 처리 없이 가능합니다.
모든 필드가 아닌 플래그된 추출 결과만 검토하세요. AI는 낮은 신뢰도의 결과를 표시합니다 — 원본 문서의 스캔 품질이 낮거나, 형식이 모호하거나, 예상치 못한 데이터 패턴이 있는 필드입니다. 먼저 플래그된 항목을 검토하세요. 높은 신뢰도 점수를 가진 나머지는 수동 개입이 필요 없는 경우가 대부분입니다. 월 500개의 B/L과 95% 이상의 필드 수준 신뢰도에서 검토 단계는 500개 문서의 라인별 검증이 아닌 약 25개 문서 분량의 예외 사례에만 집중합니다.
통합 스프레드시트 하나로 내보내세요. 출력은 모든 B/L이 행이 되는 단일 Excel 파일입니다. 모든 열은 모든 해운사에서 동일합니다. XLSX 또는 CSV로 내보내고 TMS에 직접 가져오거나 — Google Sheets에서 작업하는 경우 — Google Sheets 애드온을 사용하여 Sheets를 벗어나지 않고 추출된 데이터를 활성 스프레드시트에 직접 작성할 수 있습니다. 구조는 일관됩니다. 1행은 Maersk B/L, 2행은 MSC B/L, 3행은 COSCO B/L이며 — 세 행 모두 동일한 열 레이아웃을 가집니다.
단일 B/L 페이지의 처리 시간은 5~10초 범위입니다. 50개의 단면 B/L 배치는 몇 분 안에 완료됩니다 — 제한 요소는 형식 다양성이 아닌 총 페이지 수입니다. 워크플로우에 16번째 해운사를 추가하는 데는 추가 설정 시간이 전혀 들지 않습니다. 시맨틱 추출은 작업하는 해운사 수에 관계없이 동작하기 때문입니다.
다양한 해운사 형식의 선하증권 데이터 추출에 대한 자세한 내용은 전용 변환 도구를 참조하세요.
문제 발생 시 대처: 대규모 예외 처리
단일 문서 추출에서 예외는 단순히 불편한 정도에 그칩니다. 수정하고 넘어가면 되니까요. 그러나 15개 해운사를 대상으로 한 배치 처리에서는 예외를 효율적으로 해결하는 것이 근무 종료 시간을 오후 3시로 할지, 오후 7시로 할지 결정합니다. 이 규모에서의 예외 처리는 정상적인 처리 경로보다 더 중요합니다.

다중 해운사 B/L 배치 처리에서 가장 흔한 세 가지 실패 유형:
해운사 템플릿 업데이트. 머스크가 B/L 레이아웃을 개편했을 때 — 특정 필드 이동, 테이블 재구성, 페이지 구조 조정 — 템플릿 기반 추출 도구는 누군가 템플릿을 재구축할 때까지 해당 필드를 놓쳤습니다. 열 이름 추출은 이 문제를 다르게 처리합니다. AI가 픽셀 위치에 고정되지 않으므로 정보 내용이 동일하다면 레이아웃 변경은 추출을 중단시키지 않습니다. B/L 번호는 개편된 페이지의 어디에 있든 여전히 B/L 번호입니다.
스캔 품질 편차. 머스크 시스템에서 깔끔한 PDF로 도착한 B/L과 형광등 창고 조명 아래에서 촬영되어 선적 대리점이 전달한 B/L은 동일한 입력이 아닙니다. 흐릿한 컨테이너 번호, 번진 중량 필드, 기울어진 페이지 방향은 추출 신뢰도를 낮춥니다. AI는 이를 검토 대상으로 표시하며, 작업자는 올바르게 추출된 데이터 행을 뒤질 필요 없이 어떤 필드에 주의가 필요한지 확인할 수 있습니다. B/L의 중요한 수기 수정(중량 조정, 봉인 번호 수기 추가)의 경우, 저품질 스캔에서 완전 자동 추출을 기대하기보다는 빠른 검토 과정을 계획하십시오.
누락 및 모호한 필드. 모든 해운사가 모든 B/L에 모든 필드를 포함하는 것은 아닙니다. 지역 해운사는 HS 코드를 생략할 수 있습니다. LCL 통합 B/L은 봉인 번호를 비워둘 수 있습니다. 템플릿 기반 도구는 누락된 필드를 추출 실패로 처리하는 경우가 많습니다. 시맨틱 추출은 다르게 처리합니다. 필드는 단순히 빈 값으로 반환되고, 작업자는 다른 문서(패킹 리스트, 상업 송장)에서 누락된 데이터를 가져올지 아니면 그대로 진행할지 결정합니다. 패킹 리스트와 B/L을 동일한 배치에서 함께 처리하고 문서 유형 간 중복되는 필드를 활용하는 것은 이 워크플로우의 자연스러운 확장입니다.
실질적인 결과: 열 이름 추출로 처리된 50개 B/L 배치의 경우, 검토 단계는 플래그가 지정된 약 2~5개 문서에 집중되며, 50개 문서 전체를 줄 단위로 검증할 필요가 없습니다. 추출 도구를 선택하기 전에 여전히 비교 중이라면, 저희의 9개 물류 문서 추출 도구의 정면 비교 테스트에서 바로 이러한 다중 해운사 형식 차이를 다룹니다.
모든 항구에서 B/L이 도착할 때: 수집 링크
포워더의 문서 흐름은 정의상 지리적으로 분산되어 있습니다. 상하이 선적항에서 실물 B/L을 처리하는 사람은 로테르담이나 시카고 본사에서 관리 스프레드시트를 담당하는 사람이 아닙니다. 데이터 입력 데스크에 도달해야 하는 모든 실물 문서는 한 번의 인수인계를 더 거치게 되며 — 이메일 전달, 포털 다운로드, WhatsApp 사진 — 모든 인수인계는 잠재적 지연이나 전송 오류의 원인이 됩니다.
수집 링크는 이러한 배포 문제를 직접 해결합니다. 수집 링크는 고유하고 공유 가능한 업로드 페이지(예: /c/xxxx 형식의 URL)로, 이를 생성하여 원산지에서 문서를 처리하는 담당자(창고 직원, 선박 대리점, 파트너 포워더, 픽업 기사)에게 배포합니다. 수신자는 링크를 열고 짧은 인증 코드를 입력한 후 B/L을 직접 업로드합니다. 계정 생성, 로그인, 교육이 필요 없습니다. 문서는 처리 대기열에 들어가며, 대시보드에서 검토하고 내보낼 수 있습니다.
이 방식은 중간 단계를 완전히 제거합니다. "원산지 에이전트가 B/L PDF를 운영 데스크에 이메일로 발송 → 운영팀이 첨부 파일 다운로드 → 폴더에 저장 → 추출 도구에 업로드" 대신, 흐름은 "원산지 에이전트가 수집 링크 열기 → B/L 업로드 → 문서가 검토 및 내보내기 대기열에 표시"로 바뀝니다. 인수인계가 3회 줄어들고, 문서는 발행 후 몇 분 내에 처리 가능해집니다 — 때로는 선박이 선적항을 떠나기 전에 완료됩니다.
여러 무역 항로와 시간대에 걸쳐 B/L을 관리하는 포워더의 경우, 전 세계 각지에서 24시간 문서가 도착하는 상황에서 수집 링크는 순차적이고 이메일에 의존하는 인수인계 체인을 병렬적이고 직접적인 업로드 파이프라인으로 전환합니다. 모든 항구의 모든 에이전트가 동일한 목적지로 업로드합니다.
자주 묻는 질문
단일 배치에서 몇 개의 B/L을 처리할 수 있나요?
하드 제한은 없습니다 — 한 배치에 필요한 만큼 파일을 업로드할 수 있습니다. 현실적으로 여러 해운사의 B/L 50~100건은 몇 분 내에 처리됩니다. 총 처리 시간은 형식 다양성이 아닌 페이지 수에 비례합니다. AI가 동일한 열 정의를 사용하여 각 문서를 독립적으로 읽기 때문입니다.
해상과 항공 화물 문서를 같은 배치에서 처리할 수 있나요?
가능합니다. 해상 B/L, 항공운송장(AWB), 패킹 리스트는 동일한 열 정의를 사용하여 같은 배치에서 처리할 수 있습니다 — 지정한 필드(송하인, 수하인, 화물 설명, 중량)가 해당 문서 유형에 모두 존재하는 한 말입니다. AI는 문서 유형을 자동으로 구분하고 읽기 방식을 조정합니다. 한 문서 유형에만 고유한 필드(AWB의 공항 코드, 해상 B/L의 컨테이너 번호)의 경우, 해당 열은 데이터가 있는 곳에서 채워지고 없는 곳에서는 비어 있습니다.
필기나 도장이 있는 B/L은 어떻게 처리되나요?
명확한 블록체 필기와 도장 텍스트는 안정적으로 추출됩니다. 읽을 수 있는 필기체 중량 수정, 운전자 메모, 봉인 번호 변경은 정확히 처리됩니다. 필기체가 심한 경우, 흐릿한 카본 사본, 번진 잉크 도장은 신뢰도가 낮아져 해당 필드는 수동 검토로 표시됩니다. 저품질 원본에서 완전 자동 처리를 기대하기보다는 필기 필드에 대한 빠른 검토를 권장합니다.
TMS 내장 문서 인식 기능과 어떻게 다른가요?
CargoWise, Descartes, Magaya를 포함한 대부분의 TMS 플랫폼의 내장 OCR 문서 인식은 템플릿 기반(해운사별 구성 필요)이거나 TMS 공급업체가 설정한 고정 필드 집합으로 제한됩니다. 열 이름 추출은 해운사별 또는 내부 참조 필드를 포함해 추출할 필드를 직접 제어할 수 있어 일반 B/L OCR 모델이 다루지 못하는 부분까지 처리합니다. Excel/CSV 출력은 파일 업로드를 지원하는 모든 TMS에 가져올 수 있어 기존 시스템을 대체하지 않고 함께 작동합니다.
중국어, 일본어 또는 기타 언어의 B/L도 처리할 수 있나요?
네. AI는 여러 언어의 B/L을 처리합니다. 중국어 COSCO B/L과 영어 Maersk B/L을 같은 배치에서 처리할 수 있습니다. 영어로 정의한 열 이름이 추출 대상이 되며, AI는 문서 언어와 관계없이 해당 값을 찾습니다. 다양한 무역 경로에서 화물을 처리하는 국제 물류 팀은 단일 워크플로우로 작업할 수 있습니다.
더 넓은 물류 문서 워크플로우를 처리하는 팀을 위해 포장 명세서와 배송 메모 배치 추출 및 공급업체별 구매 주문서 배치 처리 가이드를 참조하세요. 수동 데이터 입력 비용을 평가 중이라면 수동 데이터 입력의 숨은 비용에 대해 읽어보세요.
이 워크플로우의 단일 문서 버전(필드별 추출, 해운사 형식 처리, 단계별 설정 포함)은 API나 IT 설정 없이 선하증권 데이터를 Excel로 추출하는 방법을 참조하세요.