성수기 물류 서버 삼키는 WMS 통지, API 격리가 메일함 지킨다

물류 성수기의 통신 장애는 네트워크 단선에서만 오지 않는다. 물동량이 평소의 서너 배로 치솟는 연말이면 대형 물류사의 서버실에서는 다른 종류의 병목이 터져 나온다. 화물 운송장 번호와 배차 승인 내역, 통관 서류를 외부 협력사와 주고받는 메일 서버가 기간계 물류 시스템(WMS·TMS)의 호출을 감당하지 못하고 멈춰 서는 일이다.

화면 밖에서 도는 트래픽의 맹점

많은 물류 기업이 메일 시스템의 성능을 논할 때 직원이 웹 브라우저나 모바일 앱을 띄우는 속도만을 측정한다. 그러나 성수기 현장에서 메일 서버에 가해지는 부하의 70% 이상은 사용자의 클릭이 아니라 물류 관리 시스템(WMS)과 화물 추적 시스템이 API를 통해 쏘아 올리는 기계적 발송 요청이다.

화물 하나가 허브 터미널에 입고되고 출차될 때마다 시스템은 협력 운송사, 관세사, 화주 담당자에게 통지 메일을 발송한다. 초당 수십 건에서 수백 건씩 쏟아지는 이 발송 트래픽은 일반 임직원이 주고받는 업무 메일과 동일한 SMTP 큐(Queue)에 쌓인다. 결과적으로 대량 화물 통지 메일이 큐를 독점하면서, 정작 현장 소장이 보낸 긴급 우회 배차 품의 알림이나 선적 서류 송부가 제시간에 도달하지 못하는 지연이 발생한다.

수도권 복합물류센터의 한 전산운영팀장은 "블랙프라이데이와 명절 성수기에는 WMS에서 생성된 통관 증빙 메일이 대기열에 수만 건씩 쌓여 일반 업무 메일 발송이 3~4시간씩 밀리기도 했다"며 "화주 측에서는 서류가 오지 않아 하역을 못 하고 있다는 항의가 빗발쳤다"고 말했다.

사용자 트래픽과 시스템 API의 분리

이러한 문제를 겪는 엔터프라이즈 물류 기업들은 API 연동 아키텍처 자체를 뜯어고치는 방식을 택한다. 핵심은 사용자 메일 발송망과 백엔드 시스템의 트랜잭션 메일 발송망을 논리적·물리적으로 격리하는 구조다.

WMS나 TMS가 메일을 호출할 때 표준 REST API나 전용 웹훅(Webhook) 엔드포인트를 통과하도록 구성하고, 이 트래픽을 처리하는 전용 발송 풀(Pool)을 별도로 둔다. 대량 호출이 들어오더라도 사전 설정된 레이트 리밋(호출 제한)과 로드밸런서를 거치며 단계적으로 처리되도록 통제하는 것이다.

메일 본문에 대용량 선적 내역이나 인보이스가 포함되는 경우, 이를 메일 서버 디스크에 직접 쓰는 대신 오브젝트 스토리지 링크로 변환해 발송하는 전처리 파이프라인도 필수적이다. 메일 데이터 용량 자체가 줄어들면 SMTP 세션 점유 시간이 짧아져 대기열 해소 속도가 빨라진다.

인터페이스 연동 전 점검할 요소

물류 시스템과 그룹웨어 메일 API를 연동할 때는 단순히 '데이터가 오가는가'를 넘어 장애 격리 능력을 살펴야 한다. WMS 서버의 오류로 동일한 발송 요청이 무한 루프를 돌며 메일 서버로 유입될 때, 이를 비정상 트래픽으로 인지하고 차단하는 서킷 브레이커(Circuit Breaker) 로직이 메일 게이트웨이에 구비되어 있는지 점검하는 것이 우선이다.

아울러 외부 협력사 도메인의 수신 정책(SPF, DKIM, DMARC)과 맞물려 대량 발송 메일이 스팸으로 분류되거나 IP 평판이 떨어지지 않도록 발송 도메인과 IP를 용도별로 분리해 두는 운영 설계가 뒷받침되어야 한다. 시스템 간 연동이 촘촘해질수록 한쪽의 부하가 전체 통신망을 마비시키지 않도록 방화벽을 세우는 작업이 선행되어야 한다는 점을 성수기 물류 현장은 보여준다.