티스토리 뷰

카테고리 없음

Booking Confirmation과 실제 Schedule이 다를 때 무엇을 확인할까? 선박·ETD·Cut-off 변경 대응 순서

은동의 물류·무역 노트 2026. 8. 30. 12:00

해상운송 업무를 처음 배우면 Booking Confirmation을 받는 순간 일정이 확정됐다고 생각하기 쉽다. 나도 처음이었다면 PDF에 Vessel, Voyage, ETD와 ETA가 적혀 있으니 이후에는 그 일정을 기준으로 화물이 움직인다고 생각했을 것 같다.

그런데 실제 운송에서는 Booking Confirmation을 받은 뒤에도 Schedule이 변경될 수 있다. 처음 받은 Booking Confirmation에는 ETD가 8월 20일로 되어 있는데 며칠 뒤 Carrier Portal에서는 8월 22일로 보일 수도 있고, Vessel이나 Voyage까지 달라져 있을 수도 있다.

이런 상황을 처음 만나면 조금 혼란스럽다.

메일함에 있는 Booking Confirmation은 공식적으로 받은 문서이고, Carrier 홈페이지에 표시되는 Schedule도 공식정보처럼 보이기 때문이다. 그래서 자연스럽게 “둘 중 어느 것이 맞는 일정이지?”라는 질문이 생긴다.

나는 물류 업무를 경험하면서 이런 상황에서 어느 한쪽을 무조건 정답으로 고르는 방식은 조심하는 편이 좋다고 느꼈다.

중요한 것은 두 자료가 서로 다른 시점의 정보를 보여주고 있는 것은 아닌지 확인하는 것이다. Booking Confirmation을 발행한 이후 Carrier의 Transport Plan이 변경됐다면 처음 받은 PDF는 당시에는 정상적인 정보였지만 현재 기준으로는 오래된 Schedule이 될 수 있다.

이후 물류 IT 업무에서 시스템 데이터를 다룰 때도 비슷한 상황을 자주 생각하게 됐다. 화면 A와 화면 B의 값이 다르면 어느 시스템이 틀렸다고 바로 판단하기보다 각 데이터가 언제 업데이트되었고 어느 Source를 기준으로 만들어졌는지를 확인해야 했다.

Booking Confirmation과 최신 Schedule을 비교할 때도 같은 방식이 도움이 된다고 생각한다.

이번 글에서는 Booking Confirmation 자체의 개념을 길게 설명하기보다, 처음 받은 Booking Confirmation과 현재 Carrier Schedule이 다를 때 신입이 실제로 무엇부터 확인하면 좋은지를 중심으로 정리했다.

핵심 요약

Booking Confirmation을 받았더라도 이후 Vessel Schedule과 Transport Plan은 변경될 수 있다.
처음 받은 PDF와 현재 Carrier Portal의 일정이 다르면 어느 한쪽을 임의로 정답이라고 고르기보다 정보의 확인시점부터 비교한다.
Booking Number로 같은 Shipment를 보고 있는지 먼저 확인하고 Vessel·Voyage·ETD·ETA를 기존값과 현재값으로 나누어 비교한다.
Carrier에서 Revised Booking Confirmation을 발행했다면 기존 Confirmation과 어떤 항목이 변경됐는지 확인한다.
Vessel이나 Sailing이 변경되었다면 CY·SI·VGM Cut-off도 다시 확인하는 편이 좋다.
ETD만 변경됐다고 ETA를 임의로 계산하지 않고 Carrier가 제공하는 최신 Transport Plan을 확인한다.
이미 Container가 Gate-in되었는지 아직 Pickup 전인지에 따라 Schedule 변경의 실제 영향이 달라질 수 있다.
고객에게 이전 일정을 이미 안내했다면 변경 전과 변경 후 Schedule을 함께 전달하는 편이 이해하기 쉽다.
개인적으로는 Booking Confirmation을 한번 받은 뒤 끝나는 문서라기보다 최초 계획의 기준점으로 보고 이후 변경이력을 함께 관리하는 편이 실무를 이해하기 쉬웠다.

1. Booking Confirmation과 최신 Schedule은 왜 달라질까?

Booking Confirmation을 이해할 때 나는 먼저 “이 문서는 어느 시점의 계획을 확인해 준 것인가?”라는 질문을 붙이는 편이 좋다고 생각한다.

Carrier가 Booking을 접수하고 확정하면 Booking Confirmation에서 Vessel, Voyage, Schedule, Equipment와 각종 Booking 관련 정보를 확인할 수 있다. 하지만 해상운송의 특성상 이후의 실제 운항계획까지 절대로 바뀌지 않는다고 볼 수는 없다.

Carrier 운영상황이나 Vessel Schedule 조정 등으로 Transport Plan이 변경되면 현재 Carrier 시스템에 표시되는 일정과 처음 발행된 Booking Confirmation 사이에 차이가 생길 수 있다.

2026년 7월 Maersk는 이런 Schedule Change나 Operational Disruption이 발생했을 때 Booking별로 공식적인 Transport Plan Change Notice를 다운로드할 수 있도록 했다고 안내했다.

해당 문서에는 영향을 받은 Booking과 Container를 기준으로 업데이트된 Vessel, Port와 각 Leg의 ETD·ETA, 변경사유가 포함될 수 있다고 설명하고 있다.

나는 이 기능 자체가 하나의 중요한 힌트를 준다고 생각한다.

처음 Booking된 일정과 현재 Transport Plan은 실제 운송과정에서 달라질 수 있으며, 변경되었다면 최신 상태와 변경근거를 다시 확인해야 한다는 것이다.

Booking Confirmation은 처음부터 잘못된 문서였다고 볼 필요는 없다

처음 받은 Booking Confirmation에는 ETD가 20일인데 지금 홈페이지에는 22일이라고 표시되어 있다고 가정해 보자.

이때 “Booking Confirmation이 잘못 발행됐다”고 바로 생각할 수 있다.

하지만 20일이라는 일정이 발행 당시에는 정상적인 Schedule이었고 이후 22일로 변경되었다면 두 자료가 각각 다른 시점의 정상정보일 수 있다.

이 부분은 내가 시스템 업무를 하면서 꽤 중요하게 느꼈던 개념이다.

데이터가 다르다는 것과 데이터가 틀렸다는 것은 같은 말이 아니었다.

오전 9시에 조회한 데이터와 오후 3시에 조회한 데이터 사이에 실제 업무변경이 있었다면 두 화면의 값이 다르는 것은 자연스러운 결과일 수 있다.

그래서 Booking Confirmation과 Portal Schedule이 다르면 먼저 언제 발행된 Confirmation이고, 현재 Schedule은 언제 업데이트된 것인지를 확인하는 편이 좋다고 생각한다.

Vessel은 같고 ETD만 변경될 수도 있다

34화에서 ETD 변경을 자세히 다뤘지만 이번에는 Booking Confirmation 비교라는 관점에서만 짚고 넘어가려고 한다.

예를 들어 아래와 같은 상황이다.

항목	Original Booking Confirmation	현재 Schedule
Vessel	VESSEL A	VESSEL A
Voyage	001E	001E
ETD	8월 20일	8월 22일
ETA	8월 30일	9월 1일

위 표는 개념을 설명하기 위한 가상의 일정이다.

이 경우에는 Vessel과 Voyage는 그대로인데 Schedule만 변경된 상태로 볼 수 있다.

따라서 40화에서 다룬 Roll-over와 바로 같은 상황이라고 볼 필요는 없다.

나는 이런 이유 때문에 “일정 변경”이라는 말 하나만 듣지 않고 정확히 어떤 Field가 변경되었는지를 비교하는 습관이 필요하다고 생각한다.

Vessel과 Voyage 자체가 변경될 수도 있다

반대로 처음 Booking한 Vessel과 현재 Schedule의 Vessel이 완전히 다를 수도 있다.

이 경우에는 ETD만 수정하고 끝내기보다 Transport Plan이 실제로 어떻게 변경됐는지를 조금 더 넓게 볼 필요가 있다.

40화의 Vessel Roll-over일 수도 있고 Carrier의 Schedule 조정이나 다른 Booking Amendment가 반영된 상황일 수도 있다.

중요한 것은 화면을 보고 원인을 추측하는 것이 아니라 실제 Carrier Notice나 Revised Booking Confirmation을 확인하는 것이다.

Hapag-Lloyd가 Schedule Change를 안내했던 실제 고객 공지에서도 특정 Vessel의 Port Call이 변경되면서 Export Booking이 다음 Vessel로 이동했고, 이에 따라 Revised Booking Confirmation이 시스템에서 발행될 예정이라고 안내한 사례를 확인할 수 있다.

이런 사례를 보면 Vessel이 바뀌었을 때 Booking Confirmation도 변경된 운송계획을 기준으로 다시 확인해야 하는 이유를 이해하기 쉽다.

현재 Carrier Schedule은 최신 계획을 확인하는 데 도움이 된다

Carrier 홈페이지의 Schedule 기능은 실제 업무에서 현재 계획을 확인하는 중요한 자료가 될 수 있다.

Hapag-Lloyd는 현재 Vessel Schedule에서 실시간에 가까운 업데이트 정보를 제공하고 있으며 Vessel Name, Voyage Number, ETA·ETD뿐 아니라 Cut-off와 Terminal 정보 등도 확인할 수 있다고 안내하고 있다.

그래서 내가 기존 Booking Confirmation과 Schedule이 다른 상황을 만난다면 오래된 PDF만 반복해서 확인하지 않고 Carrier의 최신 Shipment Detail과 Schedule을 같이 볼 것 같다.

다만 일반 Schedule Search에서 같은 Route의 다른 Sailing을 찾았다는 이유만으로 그것이 내 Booking의 새 Vessel이라고 생각해서는 안 된다.

일반적인 Vessel Schedule과 실제 나의 Booking에 연결된 Transport Plan은 구분해서 볼 필요가 있다.

나는 이 차이가 꽤 중요하다고 생각한다.

같은 부산-로테르담 Route에 여러 Vessel이 보인다고 해서 가장 가까운 Vessel이 자동으로 내 Container의 변경 Vessel이라는 뜻은 아니기 때문이다.

사용자가 직접 Booking을 변경해서 Confirmation이 달라질 수도 있다

Schedule 차이가 항상 Carrier의 일방적인 변경으로 발생하는 것도 아니다.

실제 업무 중 Booking Amendment를 요청해 Vessel이나 Equipment 등 Booking Detail을 변경했을 수도 있다.

Maersk의 현재 온라인 안내에서는 Booking Amendment를 제출해 Schedule이나 Container Type 등의 Booking Detail을 변경할 수 있고, 변경이 Confirm되면 Updated Detail이 포함된 Revised Booking Confirmation이 발행된다고 설명하고 있다.

따라서 처음 받은 Confirmation과 현재 Confirmation이 다르다면 Carrier Schedule Change뿐 아니라 회사 내부에서 Booking Amendment를 요청한 이력이 있는지도 확인할 필요가 있다.

개인적으로는 이런 부분에서 이메일 제목만 보고 판단하지 않고 실제 Amendment History가 있다면 같이 보는 편이 좋다고 생각한다.

2. 두 Schedule이 다를 때 무엇부터 확인해야 할까?

실제 상황을 하나 만들어 보자.

메일함의 Booking Confirmation에는 Vessel A / Voyage 001E / ETD 20일로 적혀 있는데, Carrier Portal에 로그인해서 Shipment를 조회했더니 Vessel B / Voyage 003E / ETD 24일이 보인다.

이런 상황이라면 나는 새로운 ETD 24일부터 내부 Excel에 입력하지 않을 것 같다.

먼저 왜 두 정보가 다른지 확인하고, 실제 현재 Booking의 Transport Plan이 무엇인지부터 정리하고 싶다.

1단계: Booking Number부터 맞춘다

가장 먼저 같은 Booking을 비교하는 것이 맞는지 확인한다.

너무 단순한 단계처럼 보이지만 여러 Shipment를 동시에 처리한다면 생각보다 중요하다.

Booking Number
Shipment Number
Customer Reference
Container Number
POL / POD
Vessel / Voyage

Carrier Portal에서 다른 Booking을 열었거나, 이메일에 첨부된 다른 Shipment의 Confirmation을 보고 있는 가능성을 먼저 제외한다.

나는 시스템 데이터를 검증할 때도 항상 식별자부터 맞추는 습관이 있었다.

화면 두 개가 서로 다른 값을 보여준다고 한참 원인을 찾았는데 알고 보니 다른 Order를 비교하고 있었다면 그동안의 분석이 모두 의미가 없어지기 때문이다.

2단계: Booking Confirmation 발행일과 현재 조회시점을 본다

다음은 시간이다.

처음 Confirmation이 언제 발행됐는지 확인하고 현재 Carrier Portal의 Schedule은 언제 기준인지 본다.

예를 들어 Booking Confirmation은 일주일 전 발행되었고 Carrier에서 어제 Schedule Change Notice를 보냈다면 현재 Portal과 Confirmation이 다른 이유가 어느 정도 설명될 수 있다.

반대로 같은 날 발행된 Revised Booking Confirmation과 Portal 정보가 계속 다르다면 추가 확인이 필요할 수 있다.

나는 이런 이유 때문에 날짜 데이터만큼 데이터의 Update Time도 중요하게 생각한다.

3단계: Original과 Current Schedule을 표로 나눈다

두 자료가 다르다는 사실이 확인되면 실제로 무엇이 바뀌었는지를 적어본다.

항목	Original	Current	변경 여부
Vessel	VESSEL A	VESSEL B	변경
Voyage	001E	003E	변경
ETD	8월 20일	8월 24일	+4일
ETA	8월 30일	9월 4일	변경
POL	BUSAN	BUSAN	동일
POD	ROTTERDAM	ROTTERDAM	동일

위 표는 이해를 위한 가상 예시다.

이렇게 적으면 “Schedule이 바뀌었다”에서 한 단계 더 나아가 Vessel과 Voyage까지 변경됐고 Port는 그대로라는 사실을 한눈에 볼 수 있다.

내가 업무 중 변경내용을 전달할 때도 이런 Before / After 방식이 가장 편했다.

긴 설명보다 실제 차이가 바로 보이기 때문이다.

4단계: Revised Booking Confirmation이 있는지 확인한다

Carrier에서 Transport Plan을 변경했거나 Booking Amendment가 처리되었다면 Revised Booking Confirmation이 발행됐는지 확인한다.

Maersk는 현재 Booking Amendment가 Confirm되면 업데이트된 정보를 담은 Revised Booking Confirmation을 발행한다고 안내한다.

따라서 이메일의 첫 번째 Booking Confirmation만 가지고 있지 말고 Document 영역이나 최신메일에서 수정본이 있는지 확인할 수 있다.

나는 파일명에 FINAL이라고 붙어 있다고 해서 무조건 최신이라고 생각하지 않는 편이다.

32화에서도 이야기했지만 실제 업무에서는 Final 이후 Revised가 생기는 일이 충분히 가능하기 때문이다.

파일 이름보다 실제 발행시점과 현재 업무에서 사용 중인 Version이 무엇인지 확인하는 편이 더 중요하다.

5단계: Transport Plan Change Notice나 Carrier 공지를 확인한다

Schedule이 변경된 이유까지 확인해야 하는 상황이라면 Carrier가 제공하는 Change Notice를 확인한다.

Maersk는 2026년 6월 24일부터 Schedule Change나 Operational Disruption이 발생한 Booking에 대해 Transport Plan Change Notice를 다운로드할 수 있도록 했다고 안내하고 있다.

이 문서에는 Booking별로 업데이트된 Transport Plan과 Vessel, Port, ETD·ETA 및 변경사유가 포함될 수 있다.

이런 공식자료가 있다면 고객에게 원인을 설명할 때도 개인적인 추측보다 훨씬 명확한 근거가 된다.

개인적으로는 “아마 Port Congestion 때문일 것 같다”는 설명보다 공식 변경사유를 한 줄 전달하는 편이 훨씬 낫다고 생각한다.

6단계: 새 Cut-off를 다시 확인한다

Vessel이나 Schedule이 변경되었다면 36화에서 다룬 Cut-off도 다시 확인한다.

CY / Gate-in Cut-off
SI Cut-off
VGM Cut-off
Terminal 관련 Deadline

특히 아직 Container가 Gate-in되지 않은 상황이라면 새로운 Vessel의 Cut-off가 실제 운영에 바로 영향을 줄 수 있다.

반대로 이미 Container 반입과 SI·VGM 제출까지 끝난 상태라면 어떤 추가조치가 필요한지는 Carrier와 현재 Booking 상태를 기준으로 확인해야 한다.

나는 “Schedule이 늦어졌으니 모든 Cut-off도 자동으로 늦어졌겠지”라고 생각하지 않는 편이 좋다고 본다.

실제 최신 Deadline을 다시 확인하는 것이 안전하다.

7단계: Container가 현재 어디에 있는지 확인한다

Schedule이 변경됐을 때 현재 Container 위치를 보면 실제 영향범위를 훨씬 쉽게 판단할 수 있다.

아직 Empty Container Pickup 전이라면 Pickup 일정이나 Packing 계획을 조정할 여지가 있을 수 있다.

이미 Full Container가 Terminal에 Gate-in되어 있다면 새로운 Vessel을 기다리는 동안 별도로 확인해야 할 운영사항이 생길 수도 있다.

40화에서도 Roll-over 상황에서 Container의 위치를 중요하게 봤는데, Booking Confirmation과 Schedule 차이를 확인할 때도 마찬가지다.

일정이 얼마나 바뀌었는지와 지금 화물이 어디까지 진행됐는지를 같이 봐야 실제 영향이 보인다.

8단계: Pickup이나 Inland 일정에 영향이 있는지 확인한다

ETD가 변경됐다는 이유만으로 Pickup 일정을 내가 임의로 똑같은 날짜만큼 옮기고 싶지는 않다.

Inland 운송이나 Container Pickup, Terminal 반입은 별도의 운영계획과 Deadline을 가지고 있기 때문이다.

인턴으로 운송사와 Pickup 관련 내용을 확인하면서도 이 부분을 느꼈다.

선박 일정 하나가 정해졌다고 차량 일정까지 자동으로 정해지는 것은 아니었다.

실제 차량이 언제 움직여야 하는지와 화물이 언제 준비되는지는 다시 확인해야 했다.

따라서 Schedule이 변경되면 Pickup 관련 계획에도 영향이 있는지 해당 담당자와 확인하는 편이 좋다고 생각한다.

9단계: Draft B/L과 Documentation 영향도 본다

이미 Shipping Instruction을 제출했거나 Draft B/L이 발행된 상태라면 Transport Plan 변경정보가 Documentation에도 제대로 반영되는지 확인한다.

37화에서 Draft B/L 정정절차를 자세하게 다뤘기 때문에 여기에서는 반복하지 않겠다.

이번 글에서 중요한 것은 Schedule Change가 단순 Tracking 화면 하나의 문제가 아니라 다른 Document와 시스템 정보에도 영향을 줄 수 있다는 점이다.

나는 시스템 데이터를 다룰 때도 Source에서 날짜 하나가 바뀌면 해당 값을 사용하는 Interface나 Report가 어디까지 연결되어 있는지 확인하는 습관이 생겼다.

물류 Schedule도 같은 관점으로 보는 편이 좋다고 생각한다.

10단계: 고객에게 이전 Schedule을 이미 안내했는지 확인한다

고객에게 이미 Original Booking Confirmation 기준의 ETD와 ETA를 안내했다면 내부 시스템만 최신화해서는 정보가 맞지 않게 된다.

특히 고객이 ETA를 기준으로 재고나 생산계획을 세우고 있다면 변경된 일정을 빨리 알아야 할 수 있다.

나는 고객에게 Schedule Change를 안내한다면 아래처럼 이전값과 새로운 값을 같이 보여주는 방식을 선호한다.

Previous Vessel/Voyage: VESSEL A / 001E
Revised Vessel/Voyage: VESSEL B / 003E
Previous ETD: 20 Aug
Revised ETD: 24 Aug
Previous ETA: 30 Aug
Revised ETA: 4 Sep

이렇게 하면 고객도 메일함에서 과거 Schedule을 다시 찾을 필요가 줄어든다.

11단계: 내부 시스템과 관리자료의 Schedule도 확인한다

회사에서 ERP, TMS, 별도 운영관리표나 고객 Portal을 동시에 사용한다면 Schedule 정보가 여러 곳에 존재할 수 있다.

Carrier Portal은 24일로 바뀌었는데 내부 ERP에는 아직 20일이 남아 있을 수도 있다.

이런 상황에서는 어느 시스템이 Source이고 자동 Interface가 되는지, 사람이 별도로 수정해야 하는 정보가 무엇인지 확인해야 한다.

내가 물류 IT 업무에서 가장 많이 봤던 문제 중 하나도 이런 데이터 동기화였다.

한 곳을 수정했다고 모든 화면이 자동으로 바뀌는 것은 아니었다.

그래서 Schedule 변경에서도 이 날짜가 어디까지 이미 사용되고 있는가라는 질문을 한번 해보고 싶다.

12단계: 실제 Departure가 확인될 때까지 변경된 일정도 여전히 Estimated라는 점을 기억한다

Revised Booking Confirmation에 ETD 24일이라고 적혀 있다고 해서 24일 실제 출항이 완료된 것은 아니다.

34화에서 ETD와 ATD를 구분했듯 Revised ETD 역시 Actual Departure가 확인되기 전까지는 예상정보다.

그래서 일정이 이미 한 번 변경된 Shipment라면 실제 ATD까지 Tracking하는 편이 마음이 편하다.

개인적으로는 Schedule Update를 등록한 시점보다 실제 Vessel이 출항한 시점에서 일정 관련 불확실성이 하나 줄어든다고 생각한다.

순서	확인할 내용
1. 대상	Booking Number와 Shipment 확인
2. 시점	Booking Confirmation 발행일과 현재 Update 시점 확인
3. 비교	Original / Current Vessel·Voyage·ETD·ETA 비교
4. 수정본	Revised Booking Confirmation 확인
5. 근거	Transport Plan Change Notice 또는 Carrier 안내 확인
6. Cut-off	CY·SI·VGM Deadline 재확인
7. Container	현재 위치와 Gate-in 상태 확인
8. Inland	Pickup·운송계획 영향 확인
9. 서류	SI·Draft B/L 영향 확인
10. 고객	기존·변경 Schedule 공유
11. 시스템	내부 시스템과 관리자료 업데이트 확인
12. Actual	실제 ATD 확인

3. 운송사 연락과 물류 시스템 업무에서 느낀 일정 확인 방법

나는 선사에서 Booking Confirmation을 발행하거나 Vessel Schedule을 직접 계획했던 경험은 없다.

대신 물류 인턴으로 운송사와 연락하면서 일정과 Pickup 관련 내용을 확인했고, Invoice와 SAP 데이터를 다뤘으며 이후 물류회사 IT팀에서는 여러 시스템의 날짜와 Status를 비교했다.

그 경험을 돌이켜보면 Booking Confirmation과 최신 Schedule이 다를 때 적용할 수 있는 습관이 꽤 많았다.

경험 1: 공식 문서라고 해서 영원히 최신정보인 것은 아니라고 느꼈다

처음에는 PDF나 공식 메일로 받은 자료가 있으면 그 값을 가장 신뢰하고 싶어진다.

문서 형태로 발행됐다는 것 자체가 확정된 느낌을 주기 때문이다.

하지만 실제 업무에서는 공식적으로 발행된 문서도 이후 업무변경이 발생하면 과거정보가 될 수 있었다.

나는 이 경험 때문에 자료를 볼 때 “공식인가?”만큼이나 “최신인가?”를 중요하게 생각하게 됐다.

Booking Confirmation도 마찬가지라고 본다.

공식적으로 발행된 문서는 맞지만 이후 Revised Confirmation이 나왔다면 현재 업무에서는 최신 Version을 기준으로 봐야 한다.

경험 2: 다른 값을 보면 틀렸다고 하기 전에 Timestamp부터 찾게 됐다

물류 IT 업무에서는 같은 Shipment를 서로 다른 시스템에서 조회했을 때 날짜가 다르게 보이는 경우를 생각할 수 있었다.

처음에는 Interface Error를 의심하고 싶어지지만 실제로는 한쪽이 몇 시간 전 데이터일 수도 있었다.

이런 경험 이후에는 값을 비교할 때 Update Time부터 보는 습관이 생겼다.

Booking Confirmation ETD와 Portal ETD가 다르다면 나 역시 같은 질문부터 할 것 같다.

“어느 정보가 더 나중에 업데이트됐지?”

이 질문 하나만으로 원인범위를 크게 줄일 수 있다고 생각한다.

경험 3: 현재값만 덮어쓰면 나중에 설명하기 어려웠다

일정이 20일에서 24일로 변경됐을 때 Excel의 20일을 지우고 24일을 입력하면 현재값은 정확해진다.

하지만 한 달 뒤에는 최초 ETD가 무엇이었는지 알 수 없다.

나는 이런 이유로 중요한 변경값은 상황에 따라 History를 확인할 수 있는 구조가 필요하다고 느꼈다.

그렇다고 모든 Shipment마다 개인 Excel을 새로 만들자는 뜻은 아니다.

회사 시스템에 변경이력이 남는다면 그 기능을 활용하는 편이 더 좋을 수 있다.

중요한 것은 Original Schedule과 Current Schedule을 나중에도 구분할 수 있는가라고 생각한다.

경험 4: ‘최신 Schedule’이라는 말도 어느 기준인지 명확해야 했다

운송사와 연락할 때 “최신 일정 부탁드립니다”라고 물어볼 수 있다.

그런데 Shipment Reference가 없으면 상대방도 어느 Booking의 Schedule인지 다시 확인해야 한다.

내가 인턴으로 운송 관련 내용을 확인할 때 느꼈던 것은 어려운 영어보다 대상정보를 정확하게 주는 것이 훨씬 중요하다는 점이었다.

Booking Number나 Container Number를 같이 전달하면 상대방도 바로 조회하기 쉽다.

그래서 Schedule Change 문의에서도 나는 항상 Shipment 식별정보를 먼저 준비하고 싶다.

경험 5: Schedule Search 결과와 내 Booking을 혼동하지 않으려고 할 것 같다

Carrier 홈페이지에서 Route를 검색하면 여러 Sailing이 나온다.

지금 Booking보다 빠른 Vessel도 보일 수 있고 비슷한 날짜의 다른 Service가 보일 수도 있다.

이런 화면을 보면 “이 Vessel이 더 빠른데 왜 우리 화물은 이쪽으로 안 가지?”라는 생각이 들 수 있다.

하지만 실제 Booking에는 Space, 계약, Equipment, Route와 여러 운영조건이 연결되어 있을 수 있다.

그래서 일반 Schedule Search에서 보이는 가장 빠른 Vessel을 내 Booking의 새로운 계획이라고 생각하지 않고 실제 Shipment Detail과 Revised Confirmation을 기준으로 확인하는 편이 좋다고 생각한다.

경험 6: 일정 변경은 고객에게 보내기 전에 내가 먼저 이해해야 했다

운송사 메일을 받은 뒤 그대로 Forward하면 가장 빠르기는 하다.

하지만 고객이 “기존 ETA보다 며칠 늦어진 건가요?”, “Vessel도 바뀐 건가요?”라고 물어보면 다시 확인해야 할 수 있다.

그래서 나는 고객에게 안내하기 전에 최소한 Previous와 Revised Vessel·Voyage·ETD·ETA 정도는 스스로 정리하고 싶다.

상대방에게 정확한 설명을 하려면 내가 먼저 변화의 내용을 이해해야 하기 때문이다.

개인적으로는 이 작은 준비가 오히려 이메일을 여러 번 주고받는 일을 줄여준다고 생각한다.

경험 7: 변경사유는 내가 만들어내지 않는 편이 좋았다

Schedule이 바뀌면 자연스럽게 원인을 설명하고 싶어진다.

특히 고객이 이유를 물으면 아무 말도 하지 않는 것이 불친절하게 느껴질 수도 있다.

하지만 Carrier가 이유를 제공하지 않았는데 날씨나 Port Congestion이라고 추측해서 설명하는 것은 더 위험할 수 있다.

나는 시스템 장애를 대응하면서도 원인분석이 끝나기 전에 특정 원인을 확정적으로 안내하지 않는 편이 좋다고 느꼈다.

Schedule Change 역시 같은 방식으로 생각한다.

확인된 이유가 있다면 안내하고, 그렇지 않으면 “변경사유는 Carrier에 확인 중”이라고 구분하는 편이 낫다.

경험 8: 하나의 날짜 변경이 생각보다 많은 곳에 연결되어 있었다

IT 업무에서 Master Data 하나를 수정했는데 여러 시스템에 영향을 주는 경우가 있었다.

그래서 어느 순간부터 데이터를 수정하기 전에 “이 값은 어디에서 사용되지?”라는 질문을 자연스럽게 하게 됐다.

ETD도 비슷하다.

내부 출고계획에서 사용될 수 있고 고객에게 전달될 수도 있으며 재고계획과 KPI, Tracking 자료에도 사용될 수 있다.

그래서 Booking Schedule 변경은 Carrier Portal 한 곳의 날짜가 달라진 문제로만 보고 싶지 않다.

이미 그 일정이 어디까지 공유되었는지를 한번 생각해 보는 편이 좋다고 본다.

경험 9: Schedule이 여러 번 바뀌는 Shipment는 별도로 눈에 들어왔다

한 번 변경되는 것은 일반적인 운영변동일 수도 있다.

하지만 ETD가 20일 → 22일 → 24일처럼 반복해서 바뀌면 고객 입장에서도 일정 신뢰도가 떨어질 수 있다.

이런 Shipment는 실제 Departure가 확인될 때까지 조금 더 자주 Tracking하고 싶다.

27화에서 운송사 성과관리를 이야기했는데 장기적으로는 Schedule 변경횟수나 최초 ETA 대비 실제 ATA 같은 정보를 Carrier Performance와 연결해서 볼 수도 있다고 생각한다.

다만 단순히 일정이 많이 바뀌었다는 이유만으로 Carrier의 잘못이라고 판단하지 않고 변경사유를 같이 보는 것이 중요하다.

내가 Booking Confirmation과 최신 Schedule이 다르다면 확인할 순서

Booking Number를 확인한다. 같은 Shipment를 비교하고 있는지부터 본다.
Original Booking Confirmation 발행시점을 확인한다.
Carrier Portal의 현재 Transport Plan을 확인한다.
Original Vessel·Voyage·ETD·ETA를 기록한다.
Current Vessel·Voyage·ETD·ETA를 기록한다.
어떤 항목이 변경됐는지 Before / After로 비교한다.
Revised Booking Confirmation이 발행됐는지 확인한다.
Carrier Change Notice 또는 공식 변경사유가 있는지 확인한다.
CY·SI·VGM Cut-off를 다시 확인한다.
Container의 현재 위치와 Gate-in 여부를 확인한다.
Pickup·Inland 운송일정 영향을 확인한다.
SI·Draft B/L 등 Documentation 영향을 확인한다.
고객에게 이전 일정을 이미 공유했는지 확인한다.
내부 시스템과 관리자료를 최신화한다.
변경된 ETD를 ATD처럼 취급하지 않고 실제 출항을 다시 확인한다.

Booking Schedule 변경 체크리스트

Booking Number가 같은가?
Container Number가 맞는가?
Original Booking Confirmation을 확인했는가?
Confirmation 발행일을 확인했는가?
현재 Carrier Portal 정보를 확인했는가?
Vessel이 변경됐는가?
Voyage가 변경됐는가?
ETD가 변경됐는가?
ETA가 변경됐는가?
POL이 변경됐는가?
POD가 변경됐는가?
Transshipment Plan이 변경됐는가?
Revised Booking Confirmation이 있는가?
오래된 Confirmation만 보고 있지 않은가?
Booking Amendment를 내부에서 요청한 이력이 있는가?
Carrier의 Schedule Change Notice가 있는가?
변경사유가 공식적으로 확인됐는가?
확인되지 않은 변경사유를 추측하지 않았는가?
CY Cut-off를 다시 확인했는가?
SI Cut-off를 다시 확인했는가?
VGM Cut-off를 다시 확인했는가?
Container가 아직 Pickup 전인가?
Container가 이미 Gate-in됐는가?
Pickup 일정 변경이 필요한가?
Draft B/L에 Schedule 변경이 반영되는지 확인했는가?
고객에게 Original Schedule을 이미 안내했는가?
고객에게 Previous / Revised Schedule을 같이 전달했는가?
내부 ERP·TMS·관리표의 일정이 최신인가?
Original Schedule 이력을 나중에도 확인할 수 있는가?
실제 Departure 후 ATD를 확인했는가?

자주 묻는 질문

Q1. Booking Confirmation의 ETD와 Carrier 홈페이지 ETD가 다르면 어느 것이 맞나요?

먼저 두 정보의 확인시점을 비교하는 편이 좋다. Booking Confirmation 발행 이후 Schedule이 변경되었다면 현재 Shipment Detail이나 Revised Booking Confirmation에 최신 계획이 반영되어 있을 수 있다. 해당 Carrier의 최신 Transport Plan을 확인하는 것이 우선이다.

Q2. Booking Confirmation을 받으면 Vessel이 완전히 확정된 건가요?

Booking이 Confirm된 시점의 운송계획을 확인할 수 있지만 이후 실제 운항상황에 따라 Schedule이나 Transport Plan이 변경될 가능성은 있다. 변경이 발생했다면 Revised Information을 다시 확인해야 한다.

Q3. Vessel이 같고 ETD만 바뀌면 Roll-over인가요?

그 사실만으로 Roll-over라고 단정하기 어렵다. 동일 Vessel의 Schedule 자체가 변경된 상황일 수 있다. Vessel·Voyage와 Carrier의 실제 변경안내를 함께 확인하는 편이 좋다.

Q4. Vessel까지 바뀌면 무엇을 먼저 확인해야 하나요?

새 Vessel·Voyage와 ETD·ETA를 확인하고 Revised Booking Confirmation이나 Carrier Change Notice가 있는지 살펴보는 것이 좋다. 새로운 Cut-off와 Container 상태도 함께 확인할 필요가 있다.

Q5. Carrier Schedule Search에서 더 빠른 Vessel이 보이면 그 Vessel로 변경된 건가요?

그렇게 판단하면 안 된다. 일반 Schedule Search에서 가능한 Sailing을 볼 수 있어도 실제 내 Booking에 어떤 Vessel이 연결되어 있는지는 Booking Detail과 Carrier Confirmation을 기준으로 확인해야 한다.

Q6. Schedule이 바뀌면 CY·SI·VGM Cut-off도 자동으로 바뀌나요?

자동으로 같은 만큼 변경된다고 생각하지 않는 편이 좋다. 새로운 Vessel과 Booking Detail에 표시되는 실제 Cut-off를 각각 다시 확인해야 한다.

Q7. Revised Booking Confirmation은 왜 확인해야 하나요?

현재 Booking에 변경된 Vessel, Schedule 또는 기타 Detail이 공식적으로 어떻게 반영됐는지 확인하는 기준자료가 될 수 있기 때문이다. 기존 Confirmation과 비교하면 변경항목도 파악하기 쉽다.

Q8. Schedule 변경사유를 모르면 고객에게 어떻게 안내해야 하나요?

확인되지 않은 이유를 추측하기보다 변경된 Vessel·ETD·ETA 등 확인된 사실을 먼저 전달하고 필요하다면 사유는 Carrier에 확인 중이라고 구분하는 편이 안전하다.

Q9. Booking Confirmation이 바뀌면 기존 파일은 삭제해도 되나요?

회사 문서관리 기준을 따라야 하지만 개인적으로는 Original Schedule과 변경 History를 나중에 확인할 수 있는 구조가 유용하다고 생각한다. 단순히 오래된 파일을 개인적으로 계속 보관하라는 의미가 아니라 회사의 공식 문서관리 방식 안에서 이력이 확인되는 것이 좋다.

Q10. 물류 신입이 Schedule 변경에서 가장 중요하게 봐야 할 것은 무엇인가요?

개인적으로는 어느 일정이 맞는지 감으로 고르는 것보다 Booking Number → 정보 확인시점 → Original Schedule → Current Transport Plan → Revised Confirmation 순으로 비교하는 습관을 먼저 만드는 것을 추천하고 싶다.

정리

Booking Confirmation을 처음 받았을 때는 그 안에 적힌 Vessel과 ETD, ETA가 앞으로 계속 유지될 것처럼 느껴질 수 있다.

나 역시 물류 업무를 처음 배우는 입장이었다면 Confirmation이라는 단어 때문에 더 그렇게 생각했을 것 같다.

하지만 실제 해상운송에서는 Booking 이후에도 Transport Plan이 변경될 수 있고, 그 결과 처음 받은 Booking Confirmation과 현재 Carrier Schedule이 서로 다르게 보일 수 있다.

이때 내가 가장 먼저 하고 싶은 것은 어느 한쪽의 숫자를 바로 틀렸다고 판단하는 것이 아니다.

먼저 두 정보가 만들어진 시점을 확인할 것 같다.

Booking Confirmation은 언제 발행됐고, Carrier Portal의 현재 Schedule은 언제 업데이트되었는지를 보면 두 값이 왜 다른지 이해할 수 있는 실마리가 생기기 때문이다.

이런 습관은 내가 물류 IT 업무를 하면서 더 중요하게 느꼈다.

같은 Shipment인데 시스템 A에는 20일, 시스템 B에는 22일이 보이면 처음에는 Interface Error처럼 보일 수 있었다.

그런데 실제로 확인해 보면 A는 오전 데이터이고 B는 오후에 들어온 변경내용까지 반영된 경우도 생각할 수 있었다.

그래서 값이 다르다는 사실만으로 오류라고 생각하지 않고 Source와 Update Time을 함께 보게 됐다.

Booking Schedule도 나는 같은 방식으로 이해하고 싶다.

처음 Confirmation의 ETD 20일은 당시에는 정상적인 계획이었지만 이후 Vessel Schedule이 변경되면서 22일이 현재 계획이 되었을 수 있다.

그러면 중요한 것은 과거의 20일을 잘못된 데이터라고 지우는 것이 아니라 최초 계획이 20일이었고 현재 계획이 22일이라는 흐름을 이해하는 것이다.

나는 개인적으로 이 차이가 물류 일정관리에서 꽤 중요하다고 생각한다.

최초 계획과 현재 계획을 구분할 수 있어야 실제 운송이 얼마나 변경됐는지 알 수 있기 때문이다.

특히 고객에게 이전 ETA를 이미 안내했다면 변경폭을 설명해야 할 수도 있다.

“현재 ETA는 4일입니다”라고만 말하면 고객은 기존 30일에서 얼마나 바뀌었는지를 다시 찾아야 한다.

반면 Previous ETA 30일, Revised ETA 4일이라고 같이 보여주면 변화가 한눈에 들어온다.

운송사와 연락했던 경험에서도 이런 Before / After 방식이 훨씬 편했다.

새로운 값 하나만 전달하는 것보다 무엇이 어떻게 달라졌는지를 같이 보여줄 때 상대방과 같은 상황을 보고 있다는 느낌이 들었다.

Vessel이나 Voyage까지 달라졌다면 더더욱 ETD 하나만 수정하고 끝내고 싶지는 않다.

40화에서 Roll-over를 다뤘던 것처럼 Transport Plan 자체가 바뀌었을 가능성이 있기 때문에 새로운 Vessel과 Voyage, ETA, Cut-off를 다시 확인해야 한다.

Container가 지금 어디에 있는지도 중요하다.

아직 Pickup 전이라면 새로운 Schedule에 맞춰 앞단 계획을 조정할 여지가 있을 수 있지만 이미 Full Container가 Terminal에 들어간 상태라면 다른 영향을 확인해야 할 수도 있다.

이런 이유 때문에 나는 Schedule Change를 날짜 하나의 문제보다 Shipment 전체 진행상태의 변화로 보고 싶다.

또 Carrier의 최신 Schedule을 확인한다고 해서 Route Search 화면에 보이는 Vessel을 바로 내 Booking의 새 Vessel이라고 생각해서도 안 된다고 본다.

Carrier 홈페이지에는 같은 Route의 여러 Sailing이 있을 수 있지만 실제 내 Shipment에 연결된 Transport Plan은 Booking Detail이나 Revised Booking Confirmation을 기준으로 확인해야 하기 때문이다.

나는 시스템 업무에서도 비슷한 경험이 있었다.

선택 가능한 값 목록에 어떤 값이 있다고 해서 실제 내 업무건에 그 값이 적용된 것은 아니었다.

가능한 Option과 실제 확정된 Data를 구분해야 했다.

일정 변경사유 역시 추측하지 않는 편이 좋다고 생각한다.

Schedule이 며칠 늦어지면 Port Congestion이나 Weather 같은 원인이 자연스럽게 떠오를 수 있지만 Carrier가 그렇게 안내하지 않았다면 확정된 사실이 아니다.

2026년 Maersk처럼 Booking별 Schedule Change를 공식문서로 확인할 수 있는 기능이 있다면 그런 자료를 활용하는 편이 고객에게 설명할 때도 훨씬 깔끔하다.

없다면 Carrier의 공식메일이나 Shipment Detail을 기준으로 현재 확인된 사실까지만 전달하고 원인은 별도 확인하는 편이 안전하다고 본다.

그리고 Schedule을 내부 시스템에서 수정할 때도 나는 조금 조심하고 싶다.

새 ETD가 확인되었다고 기존 정보를 무조건 삭제하거나 Actual Date까지 같이 수정하는 것은 피해야 한다.

Revised ETD도 실제 Departure가 확인되기 전에는 여전히 Estimated 정보이기 때문이다.

34화에서 ETD와 ATD를 나눠서 봤던 이유도 여기에 있다.

예정값이 몇 번 바뀌더라도 실제 선박이 출항한 시점에는 ATD라는 별도의 결과값이 생긴다.

나는 이런 Planned와 Actual 구분이 시스템 업무를 이해하는 데 상당히 도움이 됐다.

또 Schedule 변경이 반복되는 Shipment라면 실제 ATD가 확인될 때까지 조금 더 관심 있게 보고 싶다.

한 번 20일에서 22일로 바뀌었다고 해서 22일이 절대로 다시 바뀌지 않는다고 볼 수는 없기 때문이다.

신입 입장에서는 일정이 계속 바뀌면 “도대체 어느 날짜를 믿어야 하지?”라는 생각이 들 수도 있다.

내가 다시 신입으로 돌아간다면 날짜 하나를 믿으려고 하기보다 현재 시점에서 가장 최신의 공식 Transport Plan을 확인하는 방법을 먼저 익힐 것 같다.

Booking Number로 Shipment를 찾고, 최신 Schedule과 Revised Booking Confirmation을 확인하고, 필요한 경우 Change Notice를 확인하는 순서를 알고 있다면 Schedule이 바뀌더라도 어디를 봐야 할지 방향을 잡을 수 있다.

그리고 변경된 내용은 Original과 Current로 나누어 기록하고, Cut-off와 Container 상태, Documentation, 고객 안내까지 영향이 있는지를 하나씩 연결해서 확인하면 된다.

물류 실무에서 모든 일정변경을 미리 막을 수는 없다고 생각한다.

오히려 일정은 바뀔 수 있다는 사실을 전제로 두고 변경이 발생했을 때 최신정보를 찾고 그 영향을 빠르게 연결하는 능력이 더 현실적으로 중요할 수 있다.

내가 생각하는 Booking Confirmation과 실제 Schedule 불일치 대응의 핵심은 어느 문서가 틀렸는지 바로 고르는 것이 아니라, 같은 Booking을 기준으로 정보의 시점과 변경이력을 확인한 뒤 현재 Transport Plan이 무엇인지 정확하게 다시 잡는 것이다.

참고 자료