선적 일정 추적 — 언제 물어볼지를 자동화한다

가져올 수 없는 정보가 있다

선적 일정을 시스템이 알아서 가져오게 하고 싶었습니다. 선사 사이트를 긁어오는 방법도 검토했습니다.

포기했습니다.

선사마다 형식이 다름
부킹이 중간에 변경됨 (사이트 반영이 늦음)
실제 상황은 포워더가 전화로 알려주는 경우가 대부분
환적 구간은 아예 조회가 안 되는 경우도 있음

자동 수집을 만들어도 신뢰할 수 없는 값이 됩니다. 그리고 신뢰할 수 없는 값이 화면에 있으면 없느니만 못합니다.

방향을 바꿨다

정보를 자동으로 가져오는 대신, 확인해야 할 시점을 자동으로 띄우기로 했습니다.

수출 건 하나에는 정해진 단계가 있습니다.

예상 시점이 지났는데 상태가 안 바뀌면 담당자에게 "확인 필요"가 뜹니다.

시스템이 답을 아는 게 아닙니다. 물어볼 때를 아는 겁니다.

지연을 사고가 아니라 상태로 다뤘다

처음엔 지연되면 경고를 띄웠습니다. 그런데 수출에서 지연은 예외가 아니라 일상입니다. 경고가 늘 켜져 있으면 의미가 없습니다.

현장 데이터 연재의 알림 실패와 정확히 같은 함정이었습니다. 그때 배운 걸 여기서 바로 썼습니다.

그래서 지연 자체는 경고하지 않고, 지연 사유가 기록되지 않은 것을 경고하게 바꿨습니다.

출항 예정   2026-06-11
실제 상태   미출항 (D+2)
사유 기록   없음                 ← 이것만 경고

사유를 적으면
  "선사 스케줄 변경, 06-15로 재부킹"
  → 경고 해제, 새 예상 시점 06-15 설정

늦는 건 괜찮습니다. 왜 늦는지 모르는 게 문제입니다.

바이어 통지는 분리했다

내부 확인 알림과 바이어 통지는 성격이 완전히 다릅니다. 내부 알림은 자주 가도 됩니다. 바이어에게는 확정된 정보만 나가야 합니다.

그래서 바이어 통지는 자동으로 보내지 않고 초안만 만들어 두고 사람이 보내게 했습니다. 문구는 미리 채워집니다.

보내기 버튼 하나를 남기는 것과 완전 자동은 실무에서 아주 다릅니다. 잘못된 통지 한 번이 몇 달 쌓은 신뢰를 깎기 때문입니다.

예상 시점은 어디서 나왔나

D-14, D-3 같은 기준은 처음부터 알고 있던 게 아닙니다. 지난 2년치 선적 기록에서 뽑았습니다.

단계별 실제 소요 (중앙값 기준, 최근 24개월)
  발주 확정 → 부킹        3.2일
  부킹 → 반입             9.8일
  반입 → 출항             2.1일
  출항 → 서류 발송        1.4일
  출항 → 도착 (주요 항로) 17.6일

여기에 여유를 조금 얹어 예상 시점을 잡았습니다. 항로별로 다르면 항로별로 따로 뒀습니다.

경험으로 "대충 2주쯤"이라고 알고 있던 것과 실제 중앙값이 며칠씩 달랐습니다. 그 차이만큼 확인 시점이 어긋나고 있었던 겁니다.

예상하지 못한 수확

건별 상태를 물어보는 내부 문의가 크게 줄었습니다. 전에는 담당자에게 카톡으로 물어봤는데, 이제 화면을 보면 됩니다.

그런데 더 큰 게 따로 있었습니다.

예상 시점과 실제 시점을 계속 기록하다 보니, 어느 구간이 늘 늦는지가 눈에 보이기 시작한 겁니다.

구간별 평균 지연 (최근 6개월)
  부킹 → 반입          +0.4일
  반입 → 출항          +0.8일
  출항 → 서류 발송     +4.1일   ← 특정 항로에서만
  서류 발송 → 도착     +0.2일

특정 항로의 서류 발송 단계가 평균 4일씩 밀리고 있었습니다. 아무도 그걸 문제로 인식하지 못하고 있었습니다. 늘 그랬으니까요.

측정하지 않으면 만성적인 것은 보이지 않습니다.

다음 편에서 할 것

시스템 안의 상태는 정리됐습니다. 그런데 실제 합의는 여전히 메일 안에서 이뤄지고 있었습니다.

수량 조정도, 선적 분할도, 조건 변경도 전부 메일 본문에 있습니다. 그리고 그게 시스템에 반영되는 건 담당자가 기억해서 옮길 때뿐이었습니다.