월별 선복임대차 계산 자동화와 검증 기준 정리

아래 사례는 실제 참가자의 업무를 적용한 프로젝트 결과를 바탕으로 합니다.
단, 업무 데이터 등의 보안을 위하여 이미지는 AI를 활용하여 제작하였습니다.

검증 칸이 OK면 계산이 맞은 줄 알았습니다

기획관리팀의 월별 선복임대차 계산은 다른 선사와 맺은 선복 판매·구매 계약을 매출 항차 기준으로 정산하는 일입니다.

CIS에서 파일 네 가지를 내려받아 500여 줄짜리 엑셀을 채웁니다.

사전 설문에 적힌 어려움 다섯 가지 중 마지막은 이랬습니다.

"수식 범위 검증 : 행 추가·삭제 시 합계 수식의 범위가 이탈하는 오류 발생 가능 (500여 행 수동 점검 필요)"

저희도 처음엔 파일 네 개를 넣으면 엑셀이 자동으로 채워지고, W열 검증이 OK인지만 보면 되겠다고 봤습니다.

그런데 검증 수식을 한 칸씩 따라가 보니, OK가 무엇을 확인하는지부터 다시 봐야 했습니다.

W열 검증은 같은 범위를 두 번 더한 값

판매 합계 L3는 =SUM(L6:L516), 맨 아래 G.TOTAL L517도 =SUM(L6:L516)입니다. W3은 이 두 칸이 같으면 OK를 냅니다.

두 칸이 같은 6행부터 516행을 더하니, 값은 언제나 같습니다.

516행 아래로 줄이 늘어나도 둘 다 같이 빠뜨리고, 검증은 그대로 OK입니다. 구매 쪽 P열도 같은 구조였습니다.

설문에서 가장 걱정하신 '범위 이탈'을, 지금의 검증 칸은 잡을 수 없는 구조였습니다.

설문에는 CIS 6528 정산 결과와 정합성을 확인한다는 목적도 적혀 있었습니다. 진짜 검증은 엑셀 안의 두 합계가 아니라 엑셀 밖의 정산 결과와 맞대는 것이어야 한다고 봤습니다.

교차운항 28줄, 항차수가 모두 0

항차수(H열)는 전산항차 시트에서 항로·선박·방향이 같은 줄을 세는 수식입니다. 교차운항 항로는 여기에 포트(CHB/SMZ)까지 맞춰 셉니다.

포트를 정하는 수식을 확인해 보니, 항로 이름이 "항로A" 같은 글자로 수식 안에 박혀 있었습니다.

받은 사본처럼 항로 칸의 이름이 바뀌면 포트가 비고, 교차운항 28줄의 항차수가 전부 0이 됩니다.

그래도 W열은 OK입니다. 0을 곱한 줄도 합계에는 문제없이 더해지니까요.

나머지 11줄은 계약은 걸려 있는데 이번 달 항차가 없는 줄입니다. 퇴선한 선박인지, 이번 달만 쉬는 건지는 엑셀만으로 알 수 없습니다.

과정 둘째 날에는 값이 빠진 자료를 넣고 AI가 빈칸을 지어내는지 시험합니다.

이 업무에서는 '항차 0'이 그 빈칸입니다. 0으로 조용히 계산되면 안 되고, 이유를 붙여 따로 보여야 합니다.

계약은 9999년까지, 고르는 기준은 항차 범위

Slot 계약 파일을 살펴보니, 같은 선박·거래처·항로·방향에 계약이 여러 건 걸린 경우가 판매 68곳, 구매 74곳이었습니다.

• 계약 끝 날짜로는 못 고릅니다. 판매 536건 중 506건, 구매 949건 중 902건이 '9999-09-01'까지입니다.

• 항차 범위(AW~AX)가 기준입니다. 범위끼리 겹치는 곳은 없었지만, 범위가 빈 계약이 판매 23건·구매 73건 있었습니다.

• 금액 0인 계약도 섞여 있습니다. 비고에 'DATA를 끌어 오기 위한 계약'이라고 적힌 줄입니다.

• Slottage가 두 묶음입니다. 계약 파일엔 Contract와 Settlement 칸이 나란히 있고, 계산 시트 171줄은 모두 Contract 쪽 값과 같았습니다.

Claude에게 맡기기 전에 정한 다섯 가지

1. 계약은 선박·거래처·항로·방향 + 항차 범위로 고른다. 범위가 빈 계약이 걸리면 '확인 필요'로 멈춥니다.

2. 금액 0인 계약은 계산에서 뺀다. 데이터를 끌어오기 위한 계약인지 비고로 확인합니다.

3. Slottage는 Contract 칸을 쓴다. 지금 계산 방식 그대로이고, 바꿀 때는 사람이 정합니다.

4. 항차가 0인 줄은 이유와 함께 따로 모은다. 교차운항 포트 미배정, 퇴선 후보를 나눠 보여 줍니다.

5. 검증은 엑셀 밖과 맞댄다. 합계를 CIS 6528 정산 결과와 비교하고, 금액 확정은 사람이 합니다.

다음 달 초, 실적 보고 전에

CIS도, 선복임대차 엑셀 양식도 그대로입니다. 바뀌는 건 OK라는 글자를 믿기 전에 무엇과 비교했는지 묻는 순서입니다.

검증 칸이 OK라고 말하는 동안

이 엑셀은 W열의 OK를 확인하며 매달 정산에 쓰이고 있었습니다.

따라가 보지 않았다면 항차가 0인 39줄은 다음 달에도 0으로 더해졌을 겁니다. 516행 아래로 줄이 늘어난 달에도, 검증 칸은 똑같이 OK를 띄웠겠죠.

합계 옆에 검증 칸을 둔 엑셀이라면 사정이 크게 다르지 않습니다.

그 칸이 같은 범위끼리 비교하고 있다면, OK는 아무것도 확인하지 않은 셈입니다.

필요한 건 정산 결과라는 바깥 기준 하나와, 0인 줄을 이유와 함께 꺼내는 규칙입니다.

이 둘을 Claude에게 넘기면 500여 줄을 눈으로 훑는 대신, 차이 난 줄만 보면 됩니다.

매달 OK를 보고 넘기는 그 정산표를 가져오세요.

저희 과정에서는 그 검증 칸이 실제로 무엇과 무엇을 비교하는지부터 같이 뜯어보고, 바깥 기준과 맞대는 지시문까지 함께 만듭니다.

OK만 보고 넘겼다면 다음 달에도 0으로 더해졌을 39줄. 여러분 정산표의 검증 칸이 무엇을 보고 있는지, 이번 마감 전에 저희와 직접 확인하셔야 합니다.

본 프로젝트는 솔트룩스x헬로월드랩스의 공동 개발 및 운영 교육 과정을 통해 진행되었습니다.