신입 개발자로 취업하기 위해 여러 회사에 이력서를 돌리고, 면접을 봤다. 그리고 입사할 회사를 고르고 골라서 물류 회사에 신입 개발자로 입사하게 됐다.
우리 회사 개발팀은 물류 업무에 사용하는 창고 관리 시스템(WMS), 운송 관리 시스템(TMS) 등을 개발하고 있다. 나는 각 시스템에서 사용하는 EDI 문서들을 다른 회사들과 연계하는 EDI 팀에서 일을 시작하게 됐다.
EDI란 물류 협력사, 기관, 고객사와 물류 업무에 필요한 데이터를 네트워크를 통해 정의된 포맷으로 확실하게 전달할 수 있도록 지원하는 데이터 전송 및 수신 기능이다.
EDI 팀에서는 우리 회사의 거래 파트너들과 주문서, 송장, 선적서, 통관 신고 등과 같은 문서를 전자적으로 교환할 수 있게 만든다. EDI 시스템은 개발팀에서 직접 개발한 것이 아니라 타 회사의 솔루션을 사용 중이다. 나는 이 솔루션을 이용해서 파트너사와 EDI 연계를 하거나 EDI 문서 연계를 위해 우리 회사 현업 물류 데이터들을 조합해서 EDI 문서를 만드는 업무를 주로 한다.
우리 회사는 신입사원으로 입사하면 3개월 간 수습기간을 가진다. 이 기간 동안 회사 개발팀 동료들에게 간단하게 OJT도 받고 일을 할 수 있는 준비를 한다.
우리 회사엔 수습기간 종료 발표라는 문화가 있다. 개발팀 팀장님과 EDI 팀 리더분께서 과제를 정해주시고 수습 기간 내에 과제를 마무리하고 개발팀 인원들이 전부 모인 자리에서 수습기간 동안 했던 과제에 대해 발표하면 된다. 이 과제 문화로 수습기간 3개월을 알차게 보낼 수 있었다고 생각한다.
입사하고 한 달 정도 후에 과제를 받았다. 내가 받은 과제는 해상 수출 파트에서 진행하는 AMS(Automated Manifest System) 신고를 우리 회사 물류 시스템 내부에서 진행할 수 있게 만드는 것이었다.
그럼 AMS 신고는 무엇일까? AMS 신고는 미국으로 들어가는 모든 화물에 대한 모든 정보를 선적 전에 미국 세관에 EDI 형태로 신고하는 제도이다. 이 제도는 미국에서 9.11 테러 사건 이후에 미국으로 들어오는 해상, 항공 등의 화물을 통한 테러 위험으로부터 사전에 차단하기 위해 실시했다고 한다.
우리 회사는 AMS 신고를 하기 위해 KTNET(한국무역정보통신)에서 제공하는 신고 서비스를 사용한다. 그래서 KTNET에서 제공해 주는 AMS 신고 양식에 따라 우리 회사에서 수출하는 화물에 대한 데이터를 조합하고 구조화해서 KTNET에 EDI 문서 형태로 전달한다. 그 후에 KTNET에서 미국 세관으로 우리가 전송한 EDI 문서를 토대로 AMS 신고가 진행되는 방식이다.
정리하면 KTNET과 EDI 연계를 통해 사내 물류 시스템에서 AMS 신고를 할 수 있도록 만드는 것이 나의 수습기간 과제이다.
이 기능을 만들기 위해 가장 먼저 사내 물류 시스템과 EDI 시스템이 서로 어떻게 연결되어 있는지, EDI 연계 시스템에서 어떻게 다른 회사들과 문서들을 연계하는지 알아봤다.
위 그림은 연계 구조를 간단하게 표현한 것이다. EDI 전송 기능 API 호출을 하면 DB 프로시저를 통해 업무 DB에서 필요한 데이터를 추출해서 EDI DB로 데이터를 옮겨준다. 그러면 EDI 연계 시스템은 EDI DB에 있는 데이터들을 가져와서 전송해야 할 문서를 만들고 각 연계 회사들과 사전에 합의된 방식에 따라 문서들을 전송해 준다. 이렇게 구조를 파악하고 나니 내가 과제를 구현하기 위해서 해야할 일이 명확해졌다.
내가 할 일을 아래와 같이 순서대로 정리해봤다.
가장 먼저 KTNET에서 외부 연계를 가이드해 주는 분들과 업무 협의를 하면서 AMS 신고 문서에 대해 파악했다. 이 과정에서 모르는 부분은 메일이나 전화로 계속 문의하고 문서에 들어가는 요소들이 이 데이터들이 맞는지 확인하고, 우리 사내 시스템에서 이 데이터를 관리하는지 안 하는지 이런 것들을 계속 파악했다. 그러다 보니 KTNET 직원분과 사내 물류 시스템을 사용하는 현업 분들과 의사소통을 상당히 많이 했다.
그리고 테이블 설계 후, 프로시저를 구현했다. 프로시저는 처음 다뤄봐서 문법들을 하나하나 검색해 가면서 구현했다. 그래서 기능에 비해 시간이 좀 오래 걸렸던 기억이 난다.
마지막으로 EDI 시스템에서 문서를 만들 때 사용하는 데이터 변환 문서 정의를 하고 KTNET에 전송 테스트를 하면서 과제를 마무리했다.
회사 내부적으로 개발이 어떻게 이루어지는지 자세하게 글로 작성할 수는 없을 것 같아서 간단하게 작성해 봤다. 이번 과제를 진행하면서 개발을 하면서 거의 다 처음 해본 일이라 정말 서툴렀던 것 같다. 다른 업무 관계자들과 소통하면서 업무진행한 경험, 프로시저 구현, 처음 보는 솔루션으로 타회사와 통신 연계 등은 지금까지 개발을 하면서는 경험하지 못했던 것이라 큰 경험이 된 것 같다.
개발팀 인원이 30명쯤 되는데, 그 앞에서 발표를 하려니 조금 떨렸다. 안 그래도 발표를 잘하는 타입이 아니라서 긴장을 좀 했는데 틈틈이 연습을 많이 해서 잘 마무리했다. EDI 관련 주제의 수습 종료 발표는 처음이어서 다들 발표를 흥미롭게 잘 들어주셨다.
수습기간에 그냥 방치하는 것이 아니라 동료 개발자들과 네트워크 할 수 있는 기간이 있던 점이 좋았다. 그리고 수습 과제와 발표를 통해 회사 업무 파악을 원활하게 할 수 있는 점도 너무 좋았다. 이런 것은 문화로 정착시키기 힘들 거 같은데, 지속적으로 진행되는 모습이 인상 깊었다.
개발적으로는 처음 겪어보는 일들이 꽤 많아서 장점이 될 수도 있겠다고 생각했다. 개발환경, 프로시저 개발, EDI 연계 시스템 관리 등 업무 전반적으로 다 낯선 환경이다. 그래서 ‘이 회사에서 새로운 경험을 하겠구나’ 하는 생각이 들었다.
좋았던 점에서 말했던 낯선 개발환경, 프로시저 개발, EDI 연계 시스템 관리 등은 반대로 아쉬운 점이기도 하다.
개발환경은 너무 레거시한 환경이다. 백엔드는 Spring 4 버전을 쓴다. 버전이 낮은 것과는 별개로 사내 개발 컨벤션이 어느 정도 정해져 있는데, 이 방법이 객체지향을 적용할 수 없는 방법이다. 구체적으로 말하긴 어렵지만 회사에서 백엔드 개발을 할 때 정해놓은 규칙들이 있는데, 내 기준에서는 이해하기 힘든 방식이다. 그리고 회사에서 사용 중인 프론트엔드 프레임워크가 있는데, 레퍼런스가 너무 적은데 제대로 된 문서도 없기 때문에 기존에 개발된 화면들의 코드를 복사 붙여 넣기를 하는 방식으로 개발해야 한다.
프로시저 개발은 이번에 처음 해봤는데, 개발해 보면서 느낀 점은 백엔드 쪽에 있어야 할 비즈니스 로직들을 프로시저가 다 가지고 있는 점이 단점이 아닐까? 하는 생각이 들었다. 내가 이번에 개발한 API도 프로시저를 호출하는 API였고, API 호출 시 일어나는 로직들은 전부 다 프로시저에 담겨있었다. 이렇게 되면 개발할 때 디버깅, 테스트 등이 어렵지 않을까? 하는 생각이 들면서 이런 개발 방법은 좀 아쉽다고 느꼈다.
이 두 개의 목표를 달성하려고 노력을 해야겠다.
객체지향 패러다임의 관점에서 핵심은 역할, 책임, 협력이다. 객체지향의 본질은 협력하는 객체들의 공동체를 창조하는 것이다. 영화…
객체지향 프로그래밍에서 고려할 점 대부분의 사람들은 클래스를 결정한 후에 클래스에 어떤 데이터와 메서드를 만들지 생각한다.…
티켓 판매 어플리케이션 Chapter1에서 간단하게 티켓 판매 어플리케이션 구현을 해본다. 그리고 객체지향 설계가 안 된…