적하목록 신고 자동화
규제와 기술 사이에서
"이거 잘못하면 관세청에서 연락 올 수도 있어요"
"PM님, 적하목록 신고는 진짜 조심해야 해요. 하나 잘못 신고하면 화물이 통관 못 하고, 심하면 과태료 나와요."
운영팀 대리님의 진지한 표정을 보면서, 나는 이 프로젝트가 BL 자동 발행과는 차원이 다르다는 걸 직감했다. 2024년 8월, 수출 서비스 런칭 프로젝트 시작 후 시작된 적하목록 신고 자동화 프로젝트. 이 프로젝트는 단순히 "편리함"을 넘어 "정확성"과 "컴플라이언스"가 최우선이었다.
적하목록(Cargo Manifest)은 선박이나 항공기에 실린 화물의 상세 내역을 관세청에 신고하는 필수 서류다. 수입의 경우 입항 24시간 전, 수출의 경우 출항 전까지 신고해야 하고, 신고 내용이 실제 화물과 다르면 통관이 지연되거나 과태료가 부과된다.
기존에는 운영자가 선사로부터 받은 부킹 정보와 화주가 제공한 서류를 바탕으로, 유니패스(관세청 통관 시스템)에 일일이 입력했다. 한 건당 20~30분이 걸렸고, 입력 오류로 인한 반려율이 40%나 됐다.
"이거 자동화하면 얼마나 걸릴 것 같아요?" 개발팀장님이 물었다. "글쎄요... 2주?" 나는 조심스럽게 답했다.
지난 BL 프로젝트에서 '2주'가 '3개월'이 됐던 경험이 있어서, 이번엔 애초에 보수적으로 잡았다. 하지만 역시나 현실은 달랐다.
수출입 규제 이해하기: 법률 문서와의 전쟁
프로젝트를 시작하기 전, 나는 관세법과 관세청 고시를 읽어야 했다. PM이 법률 문서를 읽는다니, 입사 초기엔 상상도 못 했던 일이었다.
적하목록이 뭐길래
적하목록은 단순한 화물 리스트가 아니다. 관세청이 테러, 밀수, 밀입국을 방지하기 위해 입출항하는 모든 화물을 추적하는 핵심 시스템이다. 그래서 신고 항목이 엄청나게 많고, 하나라도 누락되거나 틀리면 안 된다.
필수 신고 항목만 해도:
선박 정보 (선명, IMO번호, 입출항일시, 항차)
화물 정보 (품명, HS Code, 중량, 포장 단위)
컨테이너 정보 (컨테이너 번호, 봉인번호, 크기)
화주 정보 (송하인, 수하인, 통지처)
운송 경로 (선적항, 양하항, 환적항)
문제는 이 정보들이 여러 곳에 흩어져 있다는 거다. 선박 정보는 선사 시스템에, 화물 정보는 화주가 제공한 CI/PL에, 컨테이너 정보는 터미널 시스템에 있다.
"이걸 다 모아서 자동으로 신고한다고요?" 개발자가 의심스러운 표정으로 물었다. "네... 그게 목표예요." 나는 자신 없이 답했다.
관세법의 함정들
법률 문서를 읽으면서 가장 당황스러웠던 건, 예외 규정이 너무 많다는 거였다.
예를 들어 HS Code(품목 분류 코드)는 10자리여야 하는데, 특정 품목은 8자리만 입력해도 되고, 또 어떤 품목은 12자리를 요구한다. 중량은 킬로그램 단위로 신고해야 하는데, 컨테이너 자중은 포함하지 않고, 포장재 무게는 포함해야 한다.
"이거 규칙이 몇 개나 돼요?" 개발자가 한숨을 쉬었다. "지금까지 센 것만... 83개?" 나는 엑셀 시트를 보여줬다.
더 큰 문제는 이 규칙들이 예고 없이 바뀐다는 거였다. 관세청 고시가 개정되면, 우리 시스템도 바로 업데이트해야 한다. 하드코딩으로 규칙을 박아놓으면 유지보수 지옥이 될 게 뻔했다.
mermaid code 활용"이거 왜 이렇게 만들었대요?" 개발자가 황당해했다. "아마 메인프레임 시절 레거시일 거예요." 나는 추측했다.
공인인증서의 늪
유니패스 연동의 최대 난관은 공인인증서였다. 브라우저가 아닌 서버에서 API를 호출하려면, 공인인증서를 파일로 변환해서 서버에 저장해야 한다. 그리고 인증서는 1년마다 갱신해야 한다. "인증서 갱신은 누가 해요?" 개발자가 물었다. "운영팀에서 해야죠." 나는 답했다. "그럼 서버 재시작은요?" "그것도 운영팀이..." "아, 이거 장애 날 조짐이 보이는데요?" 결국 인증서 갱신 프로세스를 문서화하고, 만료 30일 전 자동 알림을 보내는 시스템을 추가로 만들어야 했다.
mermaid code 활용컴플라이언스를 고려한 기능 설계
법률과 레거시 시스템의 제약을 이해한 후, 이제 실제 기능을 설계할 차례였다. 핵심은 "자동화"와 "컴플라이언스"의 균형을 맞추는 것이었다.
데이터 검증의 3단계
BL 프로젝트에서 배운 교훈을 적용해서, 데이터 검증을 3단계로 설계했다.
1단계: 형식 검증
필수 항목이 모두 입력됐는가?
데이터 타입이 맞는가? (숫자, 문자, 날짜)
길이 제한을 지켰는가?
2단계: 규칙 검증
HS Code가 유효한 코드인가?
중량이 컨테이너 최대 적재량을 초과하지 않는가?
입항일이 신고일보다 미래인가?
3단계: 컴플라이언스 검증
수출입 금지 품목이 아닌가?
원산지 표기가 올바른가?
특별한 허가가 필요한 품목인가?
각 단계마다 검증 실패 시 대응 방법을 달리했다. 형식 검증 실패는 자동 보정을 시도하고, 규칙 검증 실패는 경고를 표시하며, 컴플라이언스 검증 실패는 무조건 운영자 확인을 받도록 했다.
규칙 엔진의 탄생
83개의 관세법 규칙을 하드코딩하는 대신, 규칙 엔진을 만들기로 했다. 규칙을 데이터베이스에 저장하고, 코드 수정 없이 규칙을 추가하거나 변경할 수 있도록.
규칙 테이블 구조는 이렇게 설계했다:
규칙 ID
규칙 이름
검증 대상 필드
검증 조건 (SQL 표현식)
실패 시 메시지
자동 보정 가능 여부
우선순위
"이거 관세청 고시 바뀌면 DB만 업데이트하면 되겠네요?" 개발자가 긍정적으로 반응했다. "맞아요. 코드 배포 없이 즉시 반영 가능해요." 나는 만족스러웠다.
AI Parsing과 Fallback의 협업
BL 프로젝트에서 사용한 AI Parsing을 적하목록에도 적용했다. 화주가 업로드한 CI, PL, Invoice에서 필요한 정보를 자동 추출하는 거다.
하지만 적하목록은 BL보다 훨씬 정확도가 중요하다. 실패율 40%에서 시작해서, 10% 미만으로 줄이는 게 목표였다.
실패율을 줄인 방법:
다중 검증 시스템 AI가 추출한 데이터를 규칙 엔진으로 검증 신뢰도 낮은 필드는 다른 소스와 교차 검증 예: HS Code는 품명으로 역산해서 확인
학습 데이터 축적 운영자가 수정한 내역을 저장 동일한 화주/품목의 패턴 학습 3개월 후 해당 화주의 정확도 95% 달성
Smart Fallback 완전 실패 시: 이전 신고 내역 불러오기 부분 실패 시: 성공한 부분만 표시하고 나머지 입력받기 규칙 위반 시: 구체적인 수정 가이드 제공
mermaid code 활용현실의 벽: 테스트가 안 돼요
기능 개발이 70% 정도 진행됐을 때, 가장 큰 문제가 터졌다. 유니패스 테스트 서버로는 제대로 된 테스트가 불가능하다는 거였다.
"PM님, 이거 진짜 신고가 되는지 확인할 수가 없어요." 개발자가 답답해했다. "테스트 서버에서 확인하면 되잖아요?" 나는 당연하다는 듯 답했다. "테스트 서버는 실제 관세청 데이터베이스랑 연결이 안 돼요. 그냥 200 OK만 반환하고 끝이에요."
충격이었다. 그럼 실제 신고가 성공하는지는 운영 서버에 배포해봐야만 안다는 건가?
단계적 배포 전략
결국 리스크를 최소화하기 위한 단계적 배포 전략을 세웠다.
Phase 1: Shadow Mode (2주)
자동 신고 기능을 켜지만, 실제 전송은 하지 않음
기존 수동 신고와 병행하며, 자동 생성된 데이터가 수동과 일치하는지 비교
불일치 케이스 분석 및 보완
Phase 2: Soft Launch (2주)
신뢰도 높은 화주 5개사만 대상
운영자가 자동 생성된 데이터를 최종 확인 후 신고
문제 발생 시 즉시 수동으로 전환
Phase 3: Full Launch
전체 화주사로 확대
자동 신고 비율 50% 목표
지속적인 모니터링 및 개선
"이렇게 하면 혹시 문제 생겨도 영향을 최소화할 수 있겠네요." 개발팀장님이 동의했다.
운영 중 터진 문제들
2024년 11월, Phase 2를 시작하고 3일째 되던 날, 운영팀에서 급한 전화가 왔다.
"PM님, 신고가 전부 반려됐어요!"
심장이 쿵 내려앉았다. 급히 로그를 확인해보니, 유니패스에서 "선박 IMO번호 오류"라는 에러를 반환하고 있었다.
"이상한데, 어제까지는 잘 됐는데요?" 나는 혼란스러웠다.
알고 보니 선사 시스템에서 IMO번호 형식이 바뀌었다. 기존에는 "IMO1234567" 형태였는데,갑자기 "1234567"로 접두어 없이 오기 시작한 거다.
"이거 선사에 확인해봐야 할 것 같은데요?" 개발자가 말했다. "근데 오늘 신고해야 하는 건들은 어떡해요?" 운영자가 급했다.
긴급 패치를 해야 했다. IMO번호에 접두어가 없으면 자동으로 "IMO"를 붙여주는 로직을 추가했다. 하지만 이게 맞는 건지, 나중에 또 바뀌는 건 아닌지 불안했다.
모니터링 시스템 강화
이 사건 이후, 실시간 모니터링을 대폭 강화했다.
모니터링 대시보드 항목:
시간대별 신고 성공률
반려 사유 Top 5
평균 신고 소요 시간
AI 파싱 정확도
외부 시스템 응답 시간
성공률이 90% 아래로 떨어지면 자동으로 슬랙에 알림이 가고, 80% 아래로 떨어지면 자동 신고를 일시 중지하도록 설정했다.
"이제 문제가 생기면 바로 알 수 있겠네요." 개발자가 안심했다.
그래서 결과는?
2024년 12월, 3개월간의 개발과 안정화를 거쳐 적하목록 신고 자동화는 성공적으로 안착했다.
주요 성과:
신고 실패율: 40% → 10% 미만 (3개월 평균)
평균 신고 소요 시간: 25분 → 8분
운영자 업무 부담: 60% 감소
신고 정확도: 지속적 향상 (학습 효과)
하지만 숫자보다 의미 있었던 건, 운영팀의 변화였다.
"PM님, 이제 적하목록은 거의 신경 안 써도 되요. 예외 케이스만 보면 되니까 훨씬 편해요."
그리고 무엇보다, 3개월간 단 한 건의 과태료도 발생하지 않았다. 컴플라이언스를 지키면서 자동화를 달성한 거다.
배운 것들
이 프로젝트를 통해 배운 가장 중요한 교훈들:
1. 규제 산업에서는 편리함보다 정확성이 우선이다
자동화의 목표는 "빠르게"가 아니라 "틀리지 않게"였다. 수동보다 느려도, 정확하다면 가치가 있다.
2. 레거시 시스템과의 연동은 인내심 싸움이다
SOAP, 공인인증서, 고정 길이 포맷... 최신 기술이 아니라고 무시할 수 없다. 현실을 받아들이고, 그 안에서 최선을 찾아야 한다.
3. 규칙은 변한다는 전제로 설계해야 한다
하드코딩된 규칙은 유지보수 지옥의 시작이다. 규칙 엔진을 만들어서 유연성을 확보한 게 가장 잘한 결정이었다.
4. 단계적 배포는 선택이 아니라 필수다
테스트 환경이 불완전하다면, 운영 환경에서 조심스럽게 검증할 수밖에 없다. 리스크를 최소화하는 배포 전략이 중요하다.
5. 컴플라이언스는 협상 불가다
법률과 규제를 어기는 순간, 모든 게 무너진다. 비즈니스 요구사항과 법적 요구사항이 충돌하면, 항상 법이 우선이다.
다음 편 예고
적하목록 자동화를 하면서 외부 데이터를 다루는 경험을 많이 쌓았다. 그런데 가장 복잡하고 어려웠던 건 따로 있었다.
바로 "운송 트래킹 고도화"다. 선사, 터미널, 포워더 등 여러 소스에서 들어오는 이벤트를 하나의 일관된 흐름으로 보여주는 작업. 데이터 프로바이더만 5개, 이벤트 타입은 30개 이상.
다음 편에서는 이 복잡한 데이터를 어떻게 사용자 친화적인 UI로 만들었는지, 그리고 VOC를 월 평균 12건에서 3건으로 줄인 이야기를 들려주겠다.
질문 있나?
규제 산업에서 프로덕트를 만들어본 경험이 있다면, 어떤 어려움이 있었는지 공유해달라. 특히 레거시 시스템과의 연동 경험담이 있다면 꼭 듣고 싶다!
본 글은 실제 프로젝트 경험을 바탕으로 작성되었으며, 관세청 시스템의 보안을 고려해 일부 내용은 각색되었다.