IT/일반 IT

무역 서류는 어떻게 디지털화될까?

BBungyaLog 2026. 10. 24. 14:12

DCSA와 전자선하증권으로 이해하는 디지털 무역

무역 문서를 디지털화하려면 내용뿐 아니라 발급·이전·제출 과정에서 발생하는 권리와 책임도 함께 다뤄야 한다.

 

해외 거래처에 상품을 판매했다고 가정해 보자.

물건을 포장해 컨테이너에 싣고, 배가 출항했다. 판매자는 운송 서류를 준비하고, 구매자는 대금을 지급한다. 은행은 필요한 서류를 확인하며, 도착지에서는 통관과 화물 인도 절차가 진행된다.

 

이 과정에는 여러 기관의 시스템과 문서가 등장한다. 화물은 이동하고 있는데 서류가 도착하지 않거나, 기관마다 입력한 정보가 달라 추가 확인이 필요할 수도 있다.

 

이런 문제를 줄이려는 접근이 디지털 무역과 해운 데이터 표준화다.

이번 글에서는 컨테이너 해운의 표준을 만드는 DCSA, 전자선하증권인 eBL, 그리고 전자문서의 법적 인정과 플랫폼 간 연결을 살펴본다.

1. 디지털 무역은 어떤 정보를 연결하는 일일까?

국제 무역에서는 물건의 이동과 함께 여러 종류의 정보가 오간다.

상업송장·Commercial Invoice 상품과 거래 금액 등 매매 정보
포장명세서·Packing List 포장 단위, 수량, 중량 등
선하증권·Bill of Lading 화물 수령, 운송계약, 문서에 결부된 권리
원산지증명서 상품의 원산지
세관 신고정보 수출입 신고와 규제 관련 사항
운송 이벤트 적재·출항·도착 등 진행 상황

같은 회사명, 상품 정보, 중량 등이 여러 문서에 반복될 수 있다.

이 정보를 기관마다 다시 입력하면 시간과 오류가 늘어난다. 따라서 문서를 디지털로 교환하면서 같은 데이터가 같은 의미로 재사용되도록 하는 것이 중요하다.

ICC 디지털표준이니셔티브의 KTDDE 프로젝트도 36개 핵심 무역 문서의 데이터와 표준을 분석해 공급망 전반의 정합성과 상호운용성을 다룬다. ICC의 KTDDE 설명

다만 문서마다 법적 기능은 다르다. 상품 내용을 설명하는 문서와, 이전 자체가 권리 행사에 영향을 주는 문서를 동일한 파일 교환 문제로 취급해서는 안 된다.

2. DCSA는 무엇을 하는 조직일까?

DCSA는 Digital Container Shipping Association의 약자다.

컨테이너 해운 분야에서 참여자들이 공통된 방식으로 데이터를 교환할 수 있도록 표준을 만든다. 선사뿐 아니라 화주, 기술 제공자 등 공급망 참여자의 상호운용성을 지원하는 것이 목적이다. DCSA 공식 소개

공개 표준에는 다음과 같은 영역이 포함된다.

Booking 운송 예약
Bill of Lading 선적지시와 운송 문서
Track & Trace 화물·운송·장비 관련 가시성 정보
Schedules 운항 일정
Port Call 기항 관련 정보 교환
Arrival Notice 도착 통지
Verified Gross Mass 검증된 총중량 정보

구체적인 범위와 버전은 각 표준 문서에서 확인해야 한다. DCSA 공개 표준 목록

DCSA의 표준은 국제 무역 전체를 하나의 시스템으로 통합하는 규정이 아니다. 세관, 은행, 보험, 매매계약 등과 연결하려면 해당 영역의 요건도 함께 고려해야 한다.

3. 선하증권은 왜 중요한 문서일까?

선하증권은 Bill of Lading, 줄여서 B/L이라고 부른다.

대표적인 기능은 세 가지다.

  1. 운송인이 화물을 수령했다는 증거
  2. 운송계약의 증거
  3. 화물에 관한 권리의 행사·이전과 연결되는 권리증권적 기능

특히 유통성 선하증권에서는 문서의 이전과 화물에 대한 권리가 연결될 수 있다. 따라서 누가 문서를 보유하고 어떤 절차로 이전했는지가 중요하다. DCSA의 선하증권 설명

다만 모든 선하증권을 같은 방식으로 해석할 수는 없다. 문서 종류와 적용법에 따라 유통성과 효과가 달라진다. 선하증권 이전이 모든 상황에서 상품 소유권의 이전을 자동으로 확정한다고 단순화해서도 안 된다.

Sea Waybill과는 어떻게 다를까?

DCSA는 Sea Waybill·해상화물운송장을 화물 수령과 운송계약을 증명하는 비유통성 문서로 설명한다.

지정된 수하인에게 화물을 인도하는 구조이며, 선하증권과 같은 권리증권으로 다루지 않는다. DCSA 운송 문서 구분

같은 해상운송 문서라도 기능이 다르므로 전자화할 때 필요한 통제도 문서에 맞춰 설계해야 한다.

4. 전자선하증권은 PDF와 무엇이 다를까?

eBL은 electronic Bill of Lading, 전자선하증권이다.

화면에 선하증권을 표시하거나 PDF를 보내는 것은 정보 전달을 디지털화한 것이다. 하지만 권리의 이전과 연결되는 문서라면 추가로 해결해야 할 문제가 있다.

파일은 복사하기 쉽다. 같은 파일을 여러 사람에게 보냈을 때 누가 정당하게 통제하는지 파일 내용만으로 알기는 어렵다.

따라서 다음 질문에 답할 수 있어야 한다.

현재 유효한 전자기록은 무엇인가?
             ↓
누가 그 기록을 통제하는가?
             ↓
이전이 완료되면 이전 통제자의 권한은 어떻게 바뀌는가?
             ↓
문서의 무결성과 변경 이력은 유지되는가?

UNECE의 관련 백서도 전자적 이전 가능 기록에서 무결성, 유일성, 배타적 통제, 인도와 배서 등을 주요 요건으로 설명한다. UNECE 전자적 권리 이전 백서

여기서 복사본이 전혀 존재해서는 안 된다는 뜻은 아니다. 여러 사람이 내용을 열람하더라도, 독립된 여러 주체가 서로 충돌하는 유효한 통제권을 행사하지 못하도록 관리하는 것이 핵심이다.

5. DCSA는 문서의 어떤 과정을 표준화할까?

DCSA의 선하증권 표준은 문서 데이터와 함께 관련 업무 흐름을 다룬다.

대표적으로 다음 과정이 있다.

  • 선적지시, Shipping Instructions 제출과 수정
  • 운송 문서 초안 작성과 승인
  • 문서 발급
  • 정정을 위한 반납과 무효화·재발급
  • 화물 인도를 위한 반납

DCSA Industry Blueprint에도 이런 단계가 구분돼 있다. DCSA Shipment Journey

이를 단순화하면 다음과 같다.

선적지시 제출
      ↓
운송 문서 초안
      ↓
내용 확인·승인
      ↓
문서 발급
      ↓
필요한 이전·제출 절차
      ↓
반납 및 후속 처리

이 그림은 전체 구조를 설명하기 위한 것이다. 실제 상태 전이와 역할은 적용하는 표준과 플랫폼 규칙에 따라 확인해야 한다.

반납과 화물 인도 완료는 같은 상태일까?

문서를 반납하는 Surrender는 중요한 업무 상태다. 그러나 반납됐다고 통관과 현장 인도까지 모두 완료됐다고 처리해서는 안 된다.

DCSA 기술 지침도 정정을 위한 반납과 인도를 위한 반납을 구분한다. 예를 들어 SURRENDERED_FOR_AMENDMENT와 SURRENDERED_FOR_DELIVERY는 목적이 다른 상태다. DCSA eBL 구현 지침

문서, 권리, 실제 화물의 상태를 연결하되 서로 구분해서 관리해야 한다.

6. API가 같아지면 무엇이 좋아질까?

가상의 물류 플랫폼이 여러 선사의 시스템과 연결된다고 가정해 보자.

같은 업무라도 선사마다 데이터 이름과 처리 방식이 다르면 별도의 연동 코드와 변환 규칙이 필요하다.

공통 표준이 있으면 다음 항목을 맞추는 데 도움이 된다.

표준화 대상 기대할 수 있는 변화
데이터 의미 같은 항목을 다르게 해석하는 문제 감소
필수·선택 조건 누락 정보에 대한 판단 기준 정렬
API 동작 요청·응답과 예외 처리의 일관성
업무 상태 발급·승인·수정 등의 의미 공유
참조번호 관련 문서와 거래를 연결하기 쉬워짐

DCSA는 선하증권 데이터와 프로세스를 표준화하고 API를 통해 수작업 개입을 줄이는 방향을 제시한다. DCSA Bill of Lading Standard

다만 표준을 지원한다는 선언만으로 모든 연동이 완성되지는 않는다. 버전, 선택 기능, 데이터 품질, 실제 업무 처리 결과까지 확인해야 한다.

특히 API가 요청을 받았다는 사실과 업무가 완료됐다는 사실은 다르다. DCSA 구현 지침에서도 비동기 처리와 202 Accepted 응답을 다룬다. DCSA 기술 구현 지침

7. 전자서명은 무엇을 증명할까?

전자문서에서는 발급 출처와 변경 여부를 검증하는 것이 중요하다.

DCSA의 운송 문서 디지털 서명 가이드는 인증서 교환, 발급 매니페스트 생성·서명, 결과 검증 등을 다룬다. DCSA 디지털 서명 가이드

그러나 다음 세 질문은 구분해야 한다.

질문 필요한 확인
서명이 유효한가? 서명과 키·인증서 검증
서명자에게 발급 권한이 있는가? 조직 관계와 역할·권한 확인
문서의 내용이 실제 화물과 일치하는가? 별도의 업무·현장 증거 확인

유효한 서명이 있다고 해서 화물의 상태나 모든 기재 내용까지 자동으로 사실이 되지는 않는다.

앞선 LEI, vLEI 글과 연결하면, 기업 식별과 조직 역할 증명은 권한 검토를 지원할 수 있다. 다만 어떤 신원 체계와 증명을 인정할지는 해당 서비스와 표준의 요건에 맞춰야 한다.

8. 법적으로 인정되는 전자문서는 어떻게 만들까?

국제 무역에서는 기술적으로 안전한 시스템과 법적으로 인정되는 기록을 함께 설계해야 한다.

관련된 대표 문서가 UNCITRAL의 MLETR·Model Law on Electronic Transferable Records다.

전자적 이전 가능 기록이 종이 문서와 동등한 기능을 수행할 수 있도록, 기록의 식별, 통제, 무결성에 관한 틀을 제시한다. 특히 전자기록의 통제(Control)를 종이 문서의 점유에 대응하는 핵심 개념으로 다룬다. UNCITRAL MLETR

MLETR가 있으면 모든 국가에서 바로 인정될까?

MLETR는 국가가 입법에 참고하는 모델법이다. 그 자체가 모든 거래에 직접 적용되는 세계 공통 법률은 아니다.

실제 거래에서는 적용법, 각국의 입법, 계약과 플랫폼 규칙 등을 확인해야 한다. MLETR 역시 관련 문서에 적용되는 실체법을 모두 대체하는 구조가 아니다.

또한 특정 블록체인을 의무화하지 않는다. 등록부, 토큰, 분산원장 등 여러 기술을 수용하는 기술중립성을 따른다. UNCITRAL 공식 설명

영국의 입법 사례

영국의 Electronic Trade Documents Act 2023은 신뢰할 수 있는 시스템을 이용한 문서 식별, 무단 변경 방지, 통제와 이전 등의 요건을 규정한다.

단순 열람과 통제도 구분하며, 공동으로 행동하는 사람들의 경우를 별도로 다룬다. 영국 법률 제2조

이처럼 ‘전자문서’라는 이름보다 어떤 기능과 신뢰성을 갖췄는지가 중요하다.

9. 플랫폼이 다르면 eBL을 주고받을 수 있을까?

한 플랫폼 안에서 전자선하증권을 사용하는 것과, 다른 플랫폼으로 이전하는 것은 난도가 다르다.

수출자: 플랫폼 A 사용
은행:   플랫폼 B 사용
수입자: 플랫폼 C 사용

서로 문서 내용을 읽을 수 있어도 이전을 완료했다고 인정하는 방식과 책임 관계가 다를 수 있다.

플랫폼 간 상호운용성에서는 최소한 다음을 함께 다뤄야 한다.

  • 데이터와 API
  • 문서 식별과 상태
  • 통제의 이전
  • 참여자 간 계약과 책임
  • 실패·분쟁 처리

ICC가 소개한 DCSA 상호운용성 프레임워크도 PINT API, 공통 법적 프레임워크, 통제 추적 레지스트리를 함께 설명한다. ICC의 DCSA 상호운용성 설명

따라서 다른 플랫폼으로 파일을 전송하는 기능만으로 권리 이전까지 해결됐다고 판단해서는 안 된다.

실제 도입은 어디까지 왔을까?

DCSA는 2025년 5월 CargoX와 edoxOnline 사이의 실거래 상호운용 사례를 소개한다. 이어 2026년 6월에는 다섯 제공자가 상호운용성 표준 부속서 버전 2를 채택하고 International Group of P&I Clubs의 승인을 받았다고 설명한다. DCSA의 상호운용성 현황

이는 구체적인 진전이지만, 모든 플랫폼·은행·관할에서 자동으로 사용할 수 있다는 뜻은 아니다. 해당 승인도 세계 모든 국가의 법적 인정과 동일하게 해석해서는 안 된다.

10. 문서 상태와 실제 운송 상태도 구분해야 한다

eBL 외에도 해운 데이터 표준이 필요한 이유가 있다.

사용자는 화물이 어디에 있고 언제 도착할지 알고 싶어 한다. 이를 위해서는 문서뿐 아니라 운송 이벤트를 일관되게 교환해야 한다.

DCSA Track & Trace 표준은 화물·운송·장비 등 가시성 정보를 공통 구조로 설명하고 교환하도록 한다. DCSA Track & Trace

시스템에서는 다음 상태를 섞지 않아야 한다.

문서 초안, 발급, 정정, 반납
운송 적재, 출항, 도착
화물 인도 인도 요청, 승인, 실제 반출
금융 서류 심사, 지급, 최종 결제

‘배가 도착했다’는 이벤트만으로 서류 심사와 대금 지급이 끝났다고 볼 수 없다. 마찬가지로 ‘문서가 발급됐다’고 화물의 실제 적재까지 단정해서도 안 된다.

이 상태들을 연결하면서 각각의 근거를 유지하는 것이 디지털 무역 시스템의 중요한 과제다.

11. 무역금융과 연결하면 무엇이 추가될까?

은행이 무역 서류를 처리하는 거래에서는 전자기록의 제출과 심사 조건도 맞아야 한다.

ICC의 eUCP는 전자적 제출을 수용하기 위한 신용장 규칙의 보충 규칙이다. eUCP 2.1은 전자적 이전 가능 기록과 관련된 내용을 반영한다. ICC eUCP 2.1

다음 세 가지를 구분하면 이해하기 쉽다.

구분 다루는 문제
eBL의 법적 인정 전자기록이 어떤 법적 기능을 수행하는가?
플랫폼의 상호운용성 기록과 통제를 어떻게 교환하는가?
신용장의 제출·심사 조건 어떤 기록을 어떤 방식으로 제출하고 심사하는가?

한 영역의 요건을 충족했다고 나머지까지 자동으로 충족되는 것은 아니다.

이전 국제 금융 글에서 다룬 결제도 별도 상태로 연결된다. 전자선하증권을 받았다는 사실, 은행이 제출 서류를 인정했다는 사실, 대금 지급이 최종 완료됐다는 사실은 각각 확인해야 한다.

12. 실제 서비스에서는 어떤 흐름을 만들 수 있을까?

다음은 수출 거래를 단순화한 설계 예시다. 모든 무역이 같은 순서와 문서를 사용하는 것은 아니다.

거래 당사자·권한 확인
          ↓
운송 예약과 선적지시 제출
          ↓
운송 문서 초안 확인
          ↓
eBL 발급
          ↓
필요한 제출·이전 및 금융 절차
          ↓
도착·통관·인도 관련 절차
          ↓
문서·물류·금융 상태 대사

실제 구현에서는 여러 과정이 병렬로 진행되거나 다시 이전 단계로 돌아갈 수 있다.

예를 들어 수출자가 기재 오류를 발견하면 발급된 기록을 정정하는 절차가 필요하다. 이미 다른 주체가 통제하고 있는 문서라면 그 상태도 고려해야 한다.

단순한 파일 덮어쓰기 방식으로 처리하면 이전 기록과 현재 권리가 충돌할 수 있다.

개발 관점에서는 다음 질문이 중요하다.

식별 예약, 선적, 문서, 컨테이너를 어떻게 연결하는가?
상태 현재 단계에서 허용되는 작업은 무엇인가?
권한 누가 발급, 수정, 이전, 반납을 요청할 수 있는가?
재시도 중복 요청으로 두 번 발급되거나 이전되지 않는가?
장애 플랫폼 간 처리 결과가 엇갈리면 어떻게 복구하는가?
증거 누가 언제 무엇을 승인했는지 확인할 수 있는가?
변경 정정, 재발급, 매체 전환 시 이전 기록을 어떻게 처리하는가?

이는 설계 제안이며 구체적인 구현은 사용하는 표준과 플랫폼 및 적용법에 맞춰야 한다.

13. ‘2030년 100% eBL’은 어떤 의미일까?

DCSA 회원 선사들은 2030년까지 선하증권을 100% 디지털로 발급하겠다는 목표를 제시했다. DCSA 100% eBL 이니셔티브

목표와 현재 달성률, 법적 의무는 구분해야 한다.

 

이 선언이 전 세계 모든 무역 당사자에게 적용되는 법적 의무라는 뜻은 아니다. 선사가 발급할 수 있어도 거래 상대, 은행, 플랫폼과 관련 법적 환경이 함께 준비돼야 실제 사용으로 이어진다.

 

도입을 검토하는 기업은 다음을 확인할 수 있다.

  • 거래 상대방과 은행이 해당 전자기록을 수용하는가?
  • 필요한 플랫폼 간 이전이 가능한가?
  • 계약과 적용법이 전자적 처리를 뒷받침하는가?
  • 정정·장애·분쟁 시 사용할 절차가 있는가?
  • 실제로 수작업과 대기시간이 줄었는가?

‘전자 발급 가능’과 ‘거래 전체의 전자 처리’ 사이에는 차이가 있다.

14. 신원·금융·무역 데이터를 연결하는 마지막 단계

이번 연재의 주제들은 하나의 거래 안에서 만난다.

주제 거래에서 확인하는 질문
디지털 신원 요청한 주체가 누구인가?
기업 신원·LEI·vLEI 어느 조직이며 어떤 역할로 행동하는가?
AML·고객확인 고객과 거래의 위험을 어떻게 판단하는가?
국제 금융 인프라 지급 지시와 최종 결제를 어떻게 연결하는가?
디지털 무역·해운 표준 문서·통제·물류 상태를 어떻게 교환하는가?

이 표는 역할을 연결한 것이며, 모든 거래에서 특정 기술을 의무적으로 사용한다는 의미는 아니다.

디지털 무역 서비스를 설계한다면 이 영역들의 결과가 서로 연결되도록 해야 한다. 신원이 확인된 사람이 유효한 권한으로 문서를 제출했는지, 기록의 통제가 적절하게 이전됐는지, 실제 물류와 금융 상태가 일치하는지 살펴보는 것이다.

 

DCSA와 eBL이 다루는 변화도 여기서 이해할 수 있다. 여러 조직이 같은 정보를 해석하고, 문서의 상태와 권리를 신뢰할 수 있는 방식으로 처리하도록 만드는 일이다.

참고 자료