농심 인천 복합물류센터 WCS 프로젝트 회고

처음으로 사회에 나와 신입 개발자로 참여한 뜻 깊은 프로젝트입니다.

물류자동화의 대부분의 프로세스가 담겨있는 대형 프로젝트 입니다.

더 많은것을 해보고 싶었다

초기에는 MSS라고 부르는 모니터링 애플리케이션을 담당했습니다. Nexacro로 개발했으며 설비에서 주기적으로 데이터를 가져와(Polling) 각 설비의 위치와 상태를 화면에 표시하는 프로그램이었습니다.

신입 개발자가 맡기에는 적절한 업무였을지도 모릅니다. 비교적 리스크가 낮고 시간이 오래걸리는 작업이기 때문입니다.

개인적으로는 아쉬움이 있었습니다. Backend 의 작은 역할이라도 직접 맡아보고 싶었습니다. 그래서 조금 무리해서 모니터링 애플리케이션을 빠르게 구성한 뒤 당시 상사이자 현 스승인 분에게 솔직하게 이야기했습니다.

백앤드의 작은 파트라도 맡아보고 싶습니다.

커리어의 욕심이 있었을수도 있습니다. 이 프로젝트에서 모니터링 프로그램만 담당하고 싶진 않았습니다.

신입에게 새로운 업무를 맡기는 것이 오히려 시간이 더 오래 걸리고 프로젝트 입장에서도 리스크가 있다는 것을 알고 계셨을 겁니다. 그럼에도 기회를 주셨습니다.

미니로더, 소터 설비의 인터페이스 파트 및 데이터 처리를 추가로 담당하게 되었습니다. 그리고 작은 기능이었지만 향후 세관검사를 위한 유틸리티 기능으로 ASRS 크레인을 수동으로 조작할 수 있는 기능도 개발했습니다.

이국의 개발자

미니로더와 소터는 모두 외산 설비였습니다. 그리고 저와 인터페이스를 담당하는 개발자는 스페인, 중국 사람이었습니다. 번역기가 큰 도움이 되었습니다. 언어의 장벽은 있었지만 개발자라는 배경이 같아서인지 생각보다 할 만했습니다.

통신 전문을 하나씩 주고받으며 서로의 프로그램이 어떻게 동작하는지 확인했습니다. 이해가 되지 않는 부분은 번역기로 다시 물어보고 테스트하며 하나씩 맞춰갔습니다. 신기하게도 개발에 필요한 이야기는 언어가 달라도 크게 다르지 않았습니다.

무엇을 보내고 무엇을 받아야 하는지. 이 값은 무엇을 의미하는지. 어떤 상황에서 어떤 응답을 보내야 하는지. 추상적이지 않고 명확했기에 더 수월했던것 같습니다. 처음으로 해외 개발자와 협업하며 하나의 시스템을 만들어가는 경험이었고 개인적으로는 즐거운 경험이었습니다.

비즈니스 로직을 어디다 둬야할까?

이번 프로젝트는 고객의 요청으로 비즈니스 로직을 SP(Stored Procedure)로 작업했습니다. SP의 존재는 알고 있었지만 당시까지 데이터베이스는 그저 데이터를 저장하는 곳이라는 인식이 강했습니다.

개인적으로는 Procedure가 좋은 경험으로 남지는 않았습니다. 애플리케이션이 비즈니스 로직을 수행하기보다는 그저 Procedure를 호출하는 역할만 하는 것처럼 느껴졌습니다. 물론 장점은 있습니다. DB에서 직접 처리하기 때문에 애플리케이션과 DB 사이에서 데이터를 여러 번 주고받을 필요가 없습니다. 그리고 애플리케이션을 수정하고 배포하지 않고도 DB의 Procedure만 변경하면 로직을 바로 반영할 수 있어 일종의 비즈니스 로직 핫스왑도 가능했습니다.

다만 저의 경험에서는 단점이 더 크게 다가왔습니다.

가장 어려웠던 것은 디버깅이었습니다. 테스트를 하고 로그를 남기고 싶어도 애플리케이션 코드처럼 쉽게 확인하기 어려웠습니다. 테스트를 위해 직접 데이터를 준비해야 했고 Breakpoint를 걸어 실행 흐름을 따라가는 것도 쉽지 않았습니다. 버전 관리 역시 어려웠습니다. 실제로 프로젝트 중 한 프리랜서 개발자가 Procedure를 덮어쓴 일이 있었는데 이전 버전으로 복원하는 것조차 쉽지 않았습니다.

당시의 경험을 기준으로는 DB는 데이터의 저장소로 두고 비즈니스 로직은 애플리케이션 코드에서 관리하는 것이 유지보수 측면에서 더 좋은 구조라고 생각합니다.

누가 데이터를 만들고 바꾸고 있는거지?

특정 테이블에 데이터가 추가되면 Trigger가 동작하고 그 결과 다른 테이블에 데이터를 기록하거나 추가적인 작업을 수행하는 프로세스가 있었습니다. 로그 테이블처럼 원본 데이터의 변경 이력을 남기는 용도라면 꽤 유용하다고 생각합니다.

다만 개인적으론 만약 이 존재를 알지 못하면 코드만 봐선 알수가 없겠구나 싶었습니다. 어떤 업무 플로우를 이해하기 위해 코드 뿐 아니라 Trigger 까지 확인을 해야하는 것입니다.

Trigger가 나쁜 기능은 아닙니다 로그 기록이나 데이터 무결성을 DB에서 자동으로 처리하는 것이 적절한 경우도 있다고 생각합니다. 처음이라 어색한걸수도 있지만 개인적으론 가능하면 데이터의 변경 흐름이 코드에서 명확하게 드러나는 구조를 선호하게 되었습니다.

제가 Trigger를 잘 활용하지 못했던 것일 수도 있습니다. 하지만 적어도 편리함보다 보이지 않는 동작을 추적해야 하는 부담이 더 크게 느껴졌습니다.

마치며

첫 프로젝트였던 만큼 아직도 인상이 깊은 프로젝트입니다.

처음부터 큰 프로젝트에 참여하여 물류자동화의 전반적인 프로세스를 경험할 수 있었습니다. 그리고 돌이켜보면 이때 처음으로 개발 철학이 생기기 시작했던 것 같습니다.