> AX 사례 · 해운
운임 견적·실적 조회용 전산 세 화면 요약 기준 정리
외근 중에도 받고 싶던 견적 요약, 화면마다 읽는 칸이 달랐습니다.
01 · BACKGROUND
배경
수입영업팀은 화주가 운임 견적이나 인하를 요청하면 화주 실적, 해당 월 부킹량, 타업체 운임, 현지 장비 상황을 전산 화면에서 하나씩 찾아 판단합니다. 주 10회 이상 반복되고, 외근 중에는 확인이 어렵습니다.
02 · PROBLEM
핵심 문제
견적 한 건마다 전산 화면 서너 개를 오가며 숫자를 모아야 했고, 외근 중에는 확인 자체가 어려웠습니다. 실적은 피벗 테이블로 따로 정리해야 해서 주 3회 이상 같은 작업이 반복됐습니다.
03 · CAUSES
구조적 원인
- 01실적 자료의 지역 코드가 화남 항구를 CN이 아닌 SC로 따로 묶어, 지역별 요약에서 중국 물량이 절반 넘게 빠질 수 있었습니다.
- 02부킹 현황은 한 항차가 항구별로 네 줄이고 TEU·중량 비율이 따로 있어, 어느 칸을 읽느냐에 따라 부킹률이 36%에서 176%까지 달라졌습니다.
- 03타업체 운임표에는 컨테이너 종류와 크기 조건이 다른 줄이 섞여 있어, 그대로 평균 내면 같은 조건의 평균보다 1.5배 높게 나왔습니다.
04 · SOLUTION
해결 과정
아래 사례는 실제 참가자의 업무를 적용한 프로젝트 결과를 바탕으로 합니다.
단, 업무 데이터 등의 보안을 위하여 이미지는 AI를 활용하여 제작하였습니다.
세 화면을 요약해 주면 끝날 줄 알았다
수입영업팀에는 일주일에 열 번 넘게 견적 요청이 옵니다. 그때마다 화주 실적, 그달 부킹량, 타업체 운임을 전산 화면에서 하나씩 찾아봅니다.
사전 설문에 적힌 바람은 한 줄이었습니다.
"AI가 전산 확인 후 요약해서 알림"
결과물 예시도 구체적이었습니다. 화주의 최근 6개월 구간별 실적, 해당 구간의 이번 달 부킹률, 타업체 평균 운임.
이 세 줄이 휴대폰으로 오면 외근 중에도 바로 답할 수 있으니까요.
저희도 처음엔 화면 세 개를 내려받아 요약만 시키면 되겠다고 봤습니다. 그런데 함께 받은 파일을 한 칸씩 짚어 보니, 세 줄 모두 어느 칸을 읽느냐에 따라 숫자가 달라졌습니다.
1 TEU | 36% / 176% | $377 / $249 |
|---|---|---|
지역 코드로 묶었을 때 | 같은 항차의 부킹률 | 타업체 40피트 운임 평균 |
A포워딩의 중국 실적이 1 TEU?
실적 자료는 올해 1~8월 수입 2,648줄입니다. 지역별로 묶으려면 'Area POL' 칸을 쓰면 될 것 같았습니다.
살펴보니 지역 코드가 다섯 개였습니다. VN, CN, TH, ID, 그리고 SC. 산터우·서커우·샤먼 같은 화남 항구는 CN이 아니라 SC로 따로 묶여 있었습니다.
CN으로만 세면 중국 물량은 1,896 TEU입니다. SC를 더하면 4,131 TEU로, 절반 넘게 빠져 있던 셈이죠.
A포워딩은 더 극단적이었습니다. CN은 1 TEU, SC는 1,215 TEU였습니다.
설문 예시에 적힌 첫 구간도 CNXMN, 샤먼이었습니다. 지역 코드 그대로 요약하면 바로 그 구간이 '중국' 밖으로 나갑니다.
지역은 Area 코드가 아니라 저희가 정한 지역표로 묶는다. SC를 중국에 넣을지는 사람이 한 번 정해 둔다.
냉동 컨테이너도 따로 봐야 했습니다. 설문에는 RF는 빼 달라고 적혀 있었는데, 냉동 수량은 FCL 칸 안에 함께 들어가 있습니다.
'Reefer 20'' 같은 이름의 열이 일곱 번 반복돼서, 몇 번째 열인지까지 정해 줘야 정확히 뺄 수 있습니다.
같은 항차, 부킹률은 36%와 176%
부킹 현황 화면은 한 항차가 항구별로 네 줄입니다. 선적량이 항구를 지날수록 쌓이기 때문에, 첫 항구와 마지막 항구의 비율이 크게 다릅니다.
2604항차 | TEU 기준 | 중량 기준 |
|---|---|---|
A PORT (첫 항구) | 36% | 27% |
B PORT | 93% | 82% |
C PORT | 159% | 149% |
D PORT (마지막 항구) | 176% | 134% |
설문 예시에는 'E/BOUND LAST PORT 기준'이라고 적혀 있었습니다.
담당자는 마지막 항구를 보지만, 기준을 알려 주지 않으면 AI는 표의 첫 줄을 읽기 쉽습니다. 그러면 꽉 찬 배가 '자리 넉넉'으로 요약되는 거죠.
'8월'도 한 번 더 따져야 했습니다. 네 항차 모두 지연 중이었고, 계획상 8월 15일 출항이던 2603항차는 실제로는 9월 2일로 밀려 있었습니다.
계획일과 실제일 중 무엇으로 8월을 자를지도 기준이 필요합니다.
타업체 평균은 무엇을 평균 낸 값인가
운임 현황 화면에는 업체 여덟 곳의 계약 줄이 있습니다. 그런데 줄마다 조건이 같지 않았습니다.
Type 칸 — GP, RE(냉동), PC가 섞여 있음
크기 칸 — 20피트 없이 40피트 값만 있는 줄이 세 개
업체명·계약번호 없는 줄 — 위 계약에 딸린 운임으로 보이는 줄이 세 개
계약 기간 — 8월 31일, 9월 30일에 끝나는 계약이 다섯 개
40피트 칸을 전부 평균 내면 $377, 일반 컨테이너(GP)끼리만 내면 $249입니다.
설문에 적힌 "SUPER ALL IN, ALL IN 조건 시 데이터 왜곡 가능성"이 바로 이 자리입니다.
PC 줄이 어떤 조건인지는 파일만으로 알 수 없어 '확인 필요'로 남겼습니다.
Claude에게 맡기기 전에 정한 네 가지
지역표 한 장 — 항구 코드를 CN·VN·TH 등으로 묶는 표. SC 처리는 사람이 정합니다.
부킹률은 마지막 항구, TEU 기준 — 지연 항차는 계획일과 실제일을 함께 보여 줍니다.
운임 평균은 같은 조건끼리 — 같은 Type·같은 크기, 그달에 유효한 계약만. 조건이 불분명한 줄은 빼고 표시합니다.
견적은 산출까지 — 화주에게 나가는 금액은 사람이 정합니다.
과정 둘째 날에는 기획서의 '가장 위험한 가정' 칸을 채웁니다. 이 업무라면 "표의 첫 줄이 기준이다"가 그 가정입니다.
넷째 날 권한표에서는 전산이 연결되지 않을 때의 방법을 정하는데, 세 화면을 내려받아 폴더에 넣는 것으로 충분합니다.
Claude에게 맡길 일 | 사람이 볼 일 |
|---|---|
화주별 최근 6개월 구간 실적, 지역표로 요약 | 지역표와 SC 처리 결정 |
해당 구간 마지막 항구 부킹률, 지연 항차 표시 | '8월'을 무엇으로 자를지 결정 |
같은 조건끼리 타업체 운임 평균 | 조건 불분명 줄 확인 |
견적 판단용 요약 초안 | 견적 금액 결정과 회신 |
외근 중에 견적 요청이 온 날
단계 | 교육 전 | 교육 뒤 |
|---|---|---|
화주 실적 | 전산 조회 후 피벗으로 정리 | 지역표 기준 요약이 바로 옴 |
부킹량 | 항차별 화면을 열어 확인 | 마지막 항구 비율과 지연 표시 |
타업체 운임 | 운임 화면을 훑어 판단 | 같은 조건끼리 낸 평균 |
외근 중 | 사무실 복귀 후 확인 | 요약을 보고 바로 판단 |
전산 화면도, 피벗 테이블도 그대로입니다. 세 화면을 내려받아 폴더에 넣어 두기만 하면 됩니다.
견적은 한 번 나가면 되돌리기 어렵다
화주에게 나간 숫자는 다시 고치기 어렵습니다. 그래서 외근 중에 받는 요약일수록, 어느 칸을 읽고 만든 숫자인지가 분명해야 합니다.
전산 화면 세 개만 내려받아 오시면 됩니다. 칸마다 기준을 정하는 데는 교육 기간이면 충분하고, 그다음부터 휴대폰으로 오는 요약은 직접 본 숫자와 같아집니다.
본 프로젝트는 솔트룩스x헬로월드랩스의 공동 개발 및 운영 교육 과정을 통해 진행되었습니다.
05 · RESULTS
성과
핵심 성과 지표
A포워딩 중국 실적 1 → 1,216 TEU
