EDI 구축 회고록

전 회사는 중고차 해외 유통, 물류업계라 해운 선사와 협업이 많았다. 수출 물량이 많을 때면 선적관리팀이 선하증권을(이하 B/L) 발급받기 위해 밤낮 고생을 하면서 수기로 서류작업을 했다. EDI는 이럴 때 필요하다.

1. EDI는 뭘까?

구글링하면 여러 개념이 나오는데, 간단히 말해서 두 기업이 사전에 약속한 포맷으로 (Json, XML 등) 사업에 필요한 데이터를 주고 받는 시스템이다. 그럼 왜 필요할까?

2. EDI로 얻는 기업의 이익

일단 EDI는 EDI서비스를 제공하는 업체 솔루션을 사도 되고, 자체적으로 구축해도 된다. EDI가 필요해지는 시기는 사업의 규모가 커지며, 데이터가 많아지지만 인력 충원은 없을 때 특히 빛을 발한다. 일단 서류 작업이 없어지고, 휴먼 에러 방지, 내부 인력의 업무 효율 증가로 비즈니스 주기가 빨라진다. 또한, 내부 시스템으로 구축하면 입맛에 맞게 커스텀을 할 수 있다.

---

3. EDI 설계

이해관계자들과 미팅 후 Task는 다음과 같았다.

1. 기업의 서로 다른 도메인 데이터를 요구사항에 맞게 전처리
2. 데이터 포맷은 XML
3. 기업 간 양방향 송수신이 가능해야함
4. 잘못된 데이터가 들어올 경우 오류 회피 전략 수립
5. 수신된 데이터로 B/L을 PDF로 생성해서 실무진이 사용해야함

< System Architecture >

 

2021년 당시엔 코로나로 인한 해운 물류 대란이 있었다. 인천항 야드도 포화상태였고, 코로나 때문에 주문량이 엄청 났다. 빨리 물량을 처리해야해서 새로운 기술을 마구 접목하기 보단, 아는 지식에서 최선의 트레이드 오프가 필요했다.

이 때 Spring Batch를 써보고 싶었지만, R&D할 시간이 없어서 이미 알고 있던 Spring Scheduler를 사용했다. 5분마다 파일서버에 파일 업로드 체크 후, B/L 생성 로직을 태웠다.

1. 순차적인 작업을 하다가 에러가 발생하면 작업된 파일은 Backup 폴더로 이동
2. 에러난 파일만 제외하고 쭉 B/L 생성 작업을 함.
3. 에러 파일을 최대 3번 재시도함. (다음 cron time에 먼저 작업하게 함)
4. 그래도 안되면 error 폴더에 옮기고 업무 담당자에게 Alert 메일 전송 (로그를 포함)
5. 로그와 메일 내용을 기반으로 원인 파악 & 해결
6. 서버에 파일 삭제 주기는 3개월로 설정

에러가 발생할 경우는 흔치 않았지만, 간혹 파트너사의 XML에서 사전에 약속한 코드값이 아닌 다른 값을 줌으로써 발생했다. 우리는 데이터 100개 보냈는데 파트너사에서 101개 보내서 에러나면 아무것도 모르는 불쌍한 선적팀은 멘붕에 빠졌다...  그래서 업무 관계자들에게 오류보고 메일을 보내고, 인지와 대처를 할 수 있도록 했다... 더 좋은 방법은 없었을까?..

4. 후기

결론적으로 EDI 덕에 물들어 올 때 노를 저을 수 있어서, 당시 물류 매출액은 전년 대비 50억 정도 늘었다고 들었다. 우쭐해서 하는 말은 아니지만 아쉬움이 많이 남았다. 원래는 Lambda 같은걸 써서 S3에 파일이 올라가면 전처리하는 서버리스로 해보고 싶었다. 그래도 시간과 비용 문제도 있고, 빠른 대응으로 좋게 마무리 되서 다행..!