첫 번째 물류 프로젝트 회고(2021년 10월 5일 ~ 2022년 9월 5일)

프로젝트 처음해 본 신입인데용?

프로젝트가 끝난지 거의 2주가 넘었다. 원래, 프로젝트 철수를 한 다음주에 프로젝트에 대한 회고를 작성하려고 했는데, 다른 준비를 하다보니 회고가 늦어졌다.
약 1년 기간동안 프로젝트에 투입이 되면서 성공적으로 프로젝트를 끝나기를 원했지만, 그래도 배운 것이 많았다라는 이점을 가지고 회고를 시작한다.

 

SCM 통합 물류 구축

---

SCM 통합 물류 구축 프로젝트에 대한 회고를 기간 별로 할지, 프로젝트 안에서도 배정된 소규모 프로젝트 별로 할 지를 고민하다가 소규모 프로젝트로 선택했다.

1. TPL WMS(Third-Party Logistics WMS) 구축

SCM 통합 물류 구축 프로젝트에 투입되면서 가장 먼저 배정받은 프로젝트가 TPL WMS(Third-Party Logistics WMS) 구축 프로젝트였다.
프레임워크에 대한 지식도 없었고, 빠른 프로젝트 투입으로 신입 OJT도 제대로 받지 않은 상태에서 투입된 케이스라 정말로 프로젝트에서 일을 하면서 배워야 하는 프로젝트였다.

 

왜 그랬는지는 모르겠지만, 분석 및 설계가 되어 있지 않았고 본사에 상주했던 팀장님(현, 부장님)을 필두로 9명(현업 5명, 신입사원 4명)이 프로젝트에 급하게 투입된 케이스였다.
신입으로 들어온 케이스고, 첫 프로젝트라 어떤게 맞는지, 어떤게 틀린지를 모르는 상태였고, 빨리 화면과 기능 개발을 해야 한다는 상황이 되었다. 여기서 같이 으쌰으쌰 했던 동기가 Honey다. Honey는 독일에서 10년 살고온 동기인데, 그냥 독일인이라 부른다. 영어 이름이 Honey라고 한다. 오해하지 말길.

그래도, 정말 다행이었던 건 내가 개발한 화면에 대해서 테스트를 진행하면서도, 테스트를 해주는 분(팀장님 포함 4명)이 세세한 테스트를 해주니 많은 요구사항을 쳐낼 수 있었던 프로젝트다. 처음으로 진행하는 해외 프로젝트라 해외에 갈 수도 있겠다라는 가능성을 열어뒀었고, 그 기대가 프로젝트를 버틸 수 있는 원동력이 되었다고도 할 수 있겠다.

 

정말 독일 출장을 가고 싶었는데, 비행기 티켓까지 예약하고 3일 전에 출장 지연이 되더니 취소가 되었다.
도르륵..

이 첫 번째 소규모 프로젝트에서는 프레임워크에 대한 이해와 물류 비지니스에 대한 정보 습득이 가장 절실했고, 이에 대한 지식들을 많이 얻어간 케이스가 되었다. 이 케이스를 기반으로, 물류와 인적 네트워크에서 가지를 형성할 수 있는 좋은 계기가 될 수 있었다.

 

2. TPL TMS(Third-Party Logistics TMS) 구축 - Manual

이 프로젝트를 시작으로 신입이라는 타이틀로 긍정적인 이미지를 심어줬던 프로젝트이자 인프라 및 서비스에 대한 관심을 갖게된 프로젝트다.
정말 큰 대기업에서 이직을 하신 분이 내 사수가 되었고, 지금까지도 연락을 하면서 물류 이야기를 할 수 있고 전망에 대한 이야기를 할 수 있게 되었다.
이 사수의 닉네임을 Manual이라고 하겠다.(Manual최고!)

TPL WMS 구축 프로젝트에서 프레임워크에 대한 관심이 컸던 터라 다른 회사의 WMS도 경험해보고 싶은 욕구가 강했고, 이 프로젝트에서 S 회사의 WMS + Manual의 노하우가 들어간 TMS를 구축할 수 있었다. 거기에, Manual의 효율적인 비지니스 설계로 각 로직에 대한 재사용이 가능한 컴포넌트를 개발해 볼 수 있었고, 물류 TMS 프로세스의 다양한 케이스의 예외 처리를 수월하게 할 수 있는 설계로 업무의 효율성을 강조하게 되었던 프로젝트였다.

이 프로젝트에서 모든 페이지 및 기능들에 대해 최대한 동적으로 관리할 수 있도록 하면서, 유지보수의 효율성과 사용자 입장에서 컨트롤 확장 가능성을 열어둔 시스템이었다.
기존 레거시 시스템에서는 거의 모든 것을 다 정적으로 해서 효율성이 정말 떨어졌고, 기존에 개발했던 것을 CTRL + C, CTRL + V를 해서 조금만 수정을 하던 터라, 꼭 유지보수를 해야만 바꿀 수 있는 것들이 너무 많아 레거시에 대한 불만이 생겨나기 시작했었다.
지금 생각해도, 재사용을 할 수 있는 부분에 대해서는 재사용을 해야 하는데, 공장에서 제품을 찍어내듯이 만들어 버리니, 코드는 길어지고 코드의 재사용성이 많이 떨어졌다.(역시 Manual은 최고의 사수 :D)

TPL TMS 개발을 하면서, Manual은 TA에 대한 업무도 어느 순간에 조금씩 하고 있었다.(프로젝트에서 인건비를 아끼려던 건지 모르겠지만, TA 업무도 MANUAL에게 갔다) Manual이 하는 업무를 조금씩 받아가면서 하다 보니, 자연스레 인프라에 대한 관심이 커져 갔고, 여기서 TPL TMS의 개발 환경에 대한 업그레이드를 맡게 되었다.

Spring 3.0과 IBatis를 사용하던 프로젝트에서 Spring 4.0과 MyBatis로 버전업을 진행했다. Maven의 라이브러리를 다시 맞춰가면서, IBatis에서 MyBatis를 바꾸려고 하니 문법도 안맞아 정규 표현으로 모든 문법들을 바꿔나가 업무를 끝냈다. 거기에, 소스 형상 관리로 GitLab을 사용했는데, GitLab에 소스를 올려 연결시켜 소스 형상 관리 및 Jenkins 배포까지 할 수 있도록 진행했다.

이 업무를 진행해야 하는 프리랜서 TA 분이 있었는데, 업무를 받자마자 몸이 아프셔서 구급차가 오고 응급실에 가셨다. 그래서, 업무를 내가 받아 진행을 했고, 지금은 쾌차하셨다고 하니 다행이다.
이 업무를 진행하면서, TA 프리랜서 분과 새로오신 분과 함께 이야기를 하면서 웹 서비스에 대한 관심이 많이 생긴 케이스가 되었고, 이 업무를 계기로 PM님께서도 TPL TMS 프로젝트가 끝나고 TA 파트로 배정했다.

Manual은 TPL TMS 개발을 끝마치고 인수인계를 하고 퇴사했다. 도르륵. Manual은 아직까지도 최고의 사수면서, 지금까지도 같이 프로젝트를 끝까지 해보고 싶다.

 

3. TPL TMS(Third-Party Logistics TMS) 구축 - Emily

Manual과 함께 TPL TMS를 구축했는데, 새로운 변화에 대한 거부감이 있었는지는 모르겠지만 이 TMS를 새로 재구축을 해야하는 경우가 생겼다. 그래서, Manual과 함께 만든 것을 기반으로 새로 구축했다. 재사용성을 위해 만들어 놓은 컴포넌트를 사용하지 않고, TPL WMS와 인터페이스 통신을 하면서 말이다.

솔직히, 지금 TMS보다 Manual과 함께 만든 TMS가 더 효율성이 좋고, 로직도 더 간단해서 좋다고 아직도 느끼고 있다. Emily도 Manual의 TMS 보고 굉장히 좋아했는데, PM님의 지시로 프로세스를 바꿨다.

여기서 새로운 사수인 Emily와 함께 진행을 했다. Emily는 TPL WMS 구축을 함께 했었고, Emily의 첫 PL 역할로 업무가 정말 과다하게 Emily에게 몰려 업무를 줄여주기 위해 일을 많이 했던 프로젝트다. 여기서도 Emily와 함께 같이 호흡을 맞추면서 지금까지도 Emily와 함께 업무적인 연락과 조언을 듣기 위해 연락을 하고 있다.

Emily와 함께 진행한 TPL TMS 프로젝트는 TA 업무보다는 TMS 물류 비지니스 로직에 좀 더 집중해서 프로젝트를 진행했다. 그래서, 단위테스트도 다 끝나고 통합테스트만을 남겨뒀는데, 고객사 측에서 오픈 일정 연기 요청으로 프로젝트가 홀드됐다.

아쉬운 마음과 함께 이 프로젝트는 철수를 할 때까지 오픈을 하지 못했다. 아쉬울 따름. 여기서 Emily도 유럽 통합 TMS를 하다가 퇴사했다.

따흐흑..

 

4. 유럽 통합 물류 구축 TA

SCM 통합 물류 구축 프로젝트에서 가장 재밌게 했고, 가장 많이 배울 수 있었고, 가장 성과가 컸던 파트가 유럽 통합 물류 구축 TA 파트다. 이 TA 업무를 하면서, Client가 로그인을 하여 업무를 처리하고 로그아웃까지의 모든 서비스를 개발하였고, 추가적으로 기술들을 적용할 수 있었다.

여기서 새로운 사수를 또 만났다. 새로운 사수의 닉네임은 HIS라고 하겠다.

사실, HIS의 닉네임은 따로 없어서 주석을 달 때, 이니셜로 적혀 있어서 여기에서는 HIS라고 하겠다.

HIS를 사수로 두고 일을 한 것은 기술적인 측면에서 최고였다. HIS는 우리 회사 직원이 아닌 아웃소싱을 통한 프리랜서 분이셨다. 유럽 통합 물류 구축 프로젝트에서 프레임워크 및 TA 개발이 아닌 컨설팅을 목적으로 오셨다. 그런데, 어느 순간에 개발 업무를 맡게 되셨고, 그 업무를 진행하면서 같이 TA 개발을 일하던 프리랜서(HIS X) 분이 계약 연장이 안되어 그 자리를 인수인계 받아 내가 가게 되었다.

TA 개발 프리랜서 분이 HIS 포함 총 3명이었다. 근데, HIS를 제외한 2분은 계약 연장이 안되어 나가셨고, 그 2분의 업무를 내가 인수인계 받았다.

사실, 나는 웹개발자도 아니었다. 원래, 회사를 입사할 때에도 데이터 분석과 머신러닝, AI 쪽으로 지원을 했는데, 어느 순간부터 웹개발을 하고 있게 되었다. 그래서, 인수인계를 받았을 때 "인수인계를 받긴 했는데 어떻게 해야하나...?"라고 걱정을 많이 했고, 그 때부터 퇴근 후 웹개발에 정식적으로 공부를 하게 되었다.

Spring FrameWork 에 대한 구조와 원리, 구동 방식 등 프레임워크를 시작으로 매일 퇴근하고도 야근을 하면서 공부를 시작했다. 거기에, 로그인할 때 사용하는 Token, SSO를 가장 처음으로 시작했다. 로그인 처리에 대한 이해를 하면서, 해당 프레임워크의 로직 플로우를 파악했다.

처음에 SSO에 대한 개념도 몰라 매일 구글링과 테스트 프로젝트를 만들어 구동원리를 다 뜯어봤다. 개발자의 또 하나의 스승이 바로 구글이라는 것은 변함이 없다.

이제 로그인에 필요한 기술에 대한 이해와 로직은 충분히 파악하고, 소스를 수정할 수 있는 단계에 오면서 중간 보스인 이 프로젝트의 가장 큰 핵심 WAS 및 DB 서버 분리에 대한 업무가 튀어나왔다.

솔직히 이게 제일 골치가 아팠다. WAS 서버와 DB 서버가 각 업무 모듈 별로 나뉘었다. 원래는 1개의 WAS와 1개의 DB로도 프레임워크가 돌 수 있었는데, 제대로 된 인프라 구성을 하지 않고, 서버 분리를 하려고 하니, 인프라부터 다시 시작했다.

여기서 업무 모듈 별 서버를 A, B, C, D라고 하겠다. 한 가지 업무에 대해 A와 B서버에 있는 테이블에 있는 데이터를 사용해야 하는데 1 DB 서버인 경우에는 그냥 Join을 걸어서 가져오면 됐었다. 근데, DB 서버가 분리가 되고, 고객사 측에서는 DB Link를 사용하지 못하게 하니, 이 해결 방법을 Restful API를 구현하여 데이터를 가져왔다. 그렇다 보니, API로 타 모듈 서버로 접근하여 데이터를 가져오고, 그것을 다시 Join을 사용할 수 있게 데이터를 가공하다 보니 속도가 정말 느려졌다. 이 DB에 대한 서버 분리를 하면서 가장 큰 이슈가 속도 이슈 문제였다.

그리고, WAS 서버에 대한 분리도 골치 아팠다. WAS 서버에서도 각 DB 모듈 별 서버에 맞게 WAS 서버도 똑같이 분리가 되었다. 그래서, 각 화면마다 서버에 대한 위치도 달랐고 그러다 보니, 각 서버 간의 데이터 통신도 신경써야 했다. 거기에, 이 분리된 서버의 세션들을 1개로 묶기 위해 세션 클러스터링을 해야 했다.

각 모듈별 WAS에 대해서, 로그인을 하고 다른 WAS에 대한 서비스를 사용하려면 로그인을 하여 세션을 만들어 줘야 하는데 이 과정을 세션 1개로 묶어서 사용하는 세션 클러스터링을 구현하려고 했다.

이 세션 클러스터링에서도 이슈가 있었다. 세션 클러스터링 같은 경우에는 코드로 하는 것보다 서버 단에서 설정을 해줬으면 할 수 있었다. 근데, 서버에 대한 인프라 쪽은 우리에게 권한이 없었고, 고객사 인프라 쪽에서 해주면 됐는데 고객사에서 서버에 대한 설정을 못하다 보니 세션 클러스터링을 위해 Redis를 사용했다.

세션 클러스터링만 하면 세션이 한 개로 묶여 사용할 수 있는데, 굳이 Redis를 쓰면서까지 해야 하나 싶을 정도로 약간 의미 없는 작업이 되긴 했다. Redis로 구현을 할 때에도 결국엔 세션이 있는지 없는지 체크하고, 세션 ID 비교하고 같지 않으면 세션 안에 데이터를 채워주는 등 큰 틀로 보면 그저 노가다 작업이었다. 세션에 없는 데이터들을 Redis 서버에서 꺼내와서 다시 채워주는 작업이니까 말이다.

물론, 의미 없는 작업은 아니긴하다. Redis에 대한 설치부터 서버 구성, 거기에 따른 Redis 코드까지 직접 짜보면서 Redis에 대한 이해를 할 수 있었고, 좋은 경험이 되긴 했다.

그리고 나서, 로그인 관련 업무에 대해 인수인계를 받았으니, 계약 종료가 된 다른 프리랜서 분의 업무를 인수인계받았다. 이제는 Spring Batch 부분이다. 여기도 정말 막막했긴 했는데, 로그인 관련 업무를 이어 받으면서 어떻게 해야 하는지 파악을 했던 터라 자신감은 있었다.

그렇게, 이제는 Spring Batch에 대한 공부를 시작했다. Spring Batch를 사용하면서 기존에 사용했던 Java Scheduler는 사용하지 않고, 자바 스케쥴러 대신 Quartz를 사용했다. 그래서, Spring Batch에 대한 환경 설정과 공부를 하면서 샘플 데이터 및 테스트 케이스를 여러 개 만들었고, 기존 Chunk 방식과 Tasklet에 대한 가이드를 직접 제공하면서 Batch에 대한 문의 및 업무를 하나씩 쳐내고 지금까지 했던 것 중 깔끔하게 잘 돌아가는 업무가 되었다.

다른 협력사 분과 함께 Batch에 대한 업무를 진행하니 정도 많이 들었고, Batch에 따라 고객사 측 IT 팀과 메일과 메신저로 박터지게 대화를 나눴다. 이게 큰 자산이라고 생각한다 :D

이제 Spring Batch Job을 Jenkins에서 관리를 하고 싶었는데, 고객사 IT 인프라 팀에서 해주지를 않고, 우리에게는 이런 인프라 권한도 없으니 그저 테스트를 JUnit으로 단위테스트를 진행하고, 메타 테이블을 통해서 Job 관리를 했다. 결국엔 이 메타 테이블을 기준으로 Job에 대한 것을 조회할 수 있도록 만들었다.

이제, 로그인 파트도 됐고, 스프링 배치도 됐고, 이제는 WAS에 대한 서버 이중화 작업까지 하고 나니 이제 자잘한 기능 개선 문제가 남았다. 근데, 이 때 TA에 대한 안정화가 거의 다 됐던 터라 나는 그만 가서는 안되는 곳에 팔려가고 말았다.

 

5. 유럽 통합 물류 구축 BMS

여기는 다른 프로젝트를 하면서 "어? 여기가 이제 맨 바닥인가?" 하는 순간 지하실로 떨어져 버렸다. 프로젝트를 하면서 가장 힘들었던 프로젝트면서, 가장 스트레스를 많이 받아 아팠던 프로젝트였고, 같이 일했던 PL의 책임감이 없고, 책임에 대한 회피를 하면서 추악함과 이기적인 면모를 봤던 프로젝트였다.

 

정산 프로세스는 기존의 AS-IS를 그대로 컨버팅하고 약간의 로직만 수정된 채 TO-BE로 설계되었다. 근데, 로직에 대해서 물어보면 "나도 모르지!, 원래 AS-IS가 원래 그렇게 되어 있었어!"가 가장 먼저 나오는 대답이었다.

AS-IS에 대한 분석을 기반으로 TO-BE 프로세스를 그렸을텐데 AS-IS가 원래 그렇게 되어 있었다고 대답을 한거면 분석조차 하지 않은게 아닐까 싶은 생각이 너무 많이 들었다.

 

다른 도메인은 개발도 완료가 됐고, 프로세스에 데이터를 두 번 이상 흘려볼 때 정산 도메인은 흘리기는 커녕 단위테스트조차 되지 않을 정도로 부족했다. 아니다. 부족한 것도 아닌 개발도 끝내질 못했다.

아직까지 생각해도 저 상황을 생각하면 화가 난다.

그래서, TA 업무는 인수인계를 하고 정산 도메인 파트로 옮겨갔다. 정산 파트에 나랑 HF라는 사수와 함께 지원을 갔다. 추가적으로, 프리랜서 분인 TF까지 총 3명이 정산 파트로 지원갔다.

정산 파트는 다른 협력사에 턴키를 주어 그 업체에서 완료를 했어야 했다. 근데, 정산 파트를 맡은 개발자들이 하드 코딩은 물론, 기능에 대한 단위테스트를 하지 않았는데 테스트를 진행했다고 거짓된 테스트 결과서를 만들어 놓고 갔다.

이렇게 인수 인계를 거짓으로 해놓고 나니 개발 기간은 진작에 끝나고 통합 테스트까지 얼마 남지도 않았는데, 테스트를 다시 전체적으로 해야 하는 상황이 벌어졌다.

 

진짜 그 개발자 아직도 생각하면 화가 난다.

HF와 TF는 정산에 대한 프로세스를 파악할 때, 나는 단위테스트들을 확인하면서 쿼리 수정하고, 기능 에러 고쳐나갔다.

정산 파트의 단위테스트에 대한 이슈의 수는 400건이 넘었다. 테스트 관리 시스템에 등록된 건만 400건이 넘었고, 이 외에 엑셀 파일 및 사용자 교육을 진행하면서 정리한 건들에 대해서도 약 200건이었다. 물론, 추가 개발 건은 시작도 못한게 15건 이상이었다.

이 단위테스트에 대한 이슈를 쳐가면서 생각한 것이 기능에 대한 것도 이렇게 이슈가 발생하는데, 업무 로직도 의심이 가기 시작했던 그 때 터지고 말았다.

기존 C#으로 되어 있던 것을 Java로 컨버팅을 했는데, 이마저도 로직이 빠져 있고 정말 비효율적으로 코드를 짜놓으면서 속도 이슈와 정확하지 않은로직으로 인한 데이터 부정합, 비효율적인 쿼리 등 다양한 이슈들이 터져버렸다.

 

같이 일했던 HF와 TF는 매일 주먹을 꽉 쥐고 일을 했다. 물론 나도.. 전에 개발을 한 사람들이 원망스러울 정도로 거의 2달동안 새벽 퇴근을 하는 케이스가 정말 많았다. 거기에, PL은 자꾸 기분 상하게 말을 하니 더 화가 나는 상황까지 만들어졌다.

 

안그래도 매일 독일에 있는 IT팀과 리뷰 때문에 밤에 늦게 퇴근하는데, 더 강제적으로 새벽에 퇴근하는 상황까지 만들어졌다. 여기서부터 쿼리에 대한 효율적으로 적용하는 튜닝 공부와 효율적인 INDEX 적용 방법 등을 공부해서 비효율적인 쿼리들을 하나씩 고쳐나가면서 이슈들을 해결하면서 오픈이 연기 됨에 따라 좀더 탄탄하게 바닥을 다시 만들고 있었다.

단단해져라..

 

이 프로젝트를 하면서 PL에 대한 역할이 정말로 크다는 것을 알게된 프로젝트다. 정산 파트의 PL은 산출물 관리도 제대로 되지 않았다.

 

솔직히, DB 테이블에 대한 설계도 제대로 하지 않아 개발 및 테스트 기간에도 테이블 컬럼이 계속 변경되었고, 이에 따른 ERD도 수정이 되어야 하는데, ERD도 처음 만들어 놓은 산출물들, 요구사항에 대한 분석 산출물도 최신본 부재 등 거의 모든 산출물에 대해서는 최신본이 없었다. 턴키로 가져간 파트에 대해서 제대로 끝내지도 않고 인수인계에 이런 산출물도 제대로 주지 않은 채 프로젝트에서 철수해 버렸다. 그래놓고선, 개발자 책임이라고 책임을 떠넘기려고 하니 여기서 정말 추악함을 봐버렸다.

 

정산에 대한 프로세스를 경험할 수 있었고, 거기에 효율적인 쿼리 작성을 통한 쿼리 튜닝 및 인덱스 작성법을 알게된 프로젝트였다. 즉, 수확이 없는 프로젝트가 아니었다.

 

이렇게 되다가 어느 순간에 프로젝트에 대한 철수가 결정이 됐다. 그렇게, 2022년 09월 05일 고생이란 고생은 다 하고 제대로 마무리 하지 못한 채로 통합 물류 구축 프로젝트는 끝이 났다.

 

6. 마무리

프로젝트를 진행하면서 블로그로 정리를 시작했고, 위의 기간동안 작성한 글은 401개. 물론, 여기에 알고리즘도 풀었던 글들도 있지만, 100개라고 쳐도 약 300개의 글들을 쓰면서 원활한 프로젝트를 위해 노력을 하고 공부를 했다.

 

이 프로젝트를 하면서 뿌린 씨앗들을 어느 정도 수확을 했던 시기다. 나에 대한 성장도 커졌고, 이에 따라 내가 바라봐야 할 방향도 조금은 정해졌고, 동기부여가 생긴 셈이니 말이다.

 

지금 프로젝트를 철수하고 본사에 들어와 곧 새로운 시작을 하려고 한다. 그 새로운 시작점에서 서비스에 대한 기술 스택을 더 쌓을 수 있도록 노력할 것이고, 항상 아무것도 모르는 개발자 입장에서 블로그에 글들을 기록할 것이다.

 

프로젝트를 하면서 내가 틀림을 인정해야 하는 상황이 정말 많이 발생했다. 제대로 된 정보를 맞다고 우기는 것보단, 인정하고 다시 정리하는게 나에게 도움이 되어 언제나 틀릴 수 있다는 가정을 하고 정보를 전달하려고 노력한다.
그래서 가끔은 상대방과 함께 크로스 체킹을 하면서 맞는지 틀린지 확인을 하거나, 내가 틀릴 수 있다라는 가정을 상대방에게 심어주고 교육을 시작했다.
매번 이렇게 가정하에 진행하면서, 좀 더 단단하게 만들기 위함이다.

 

나의 첫 프로젝트이자 규모가 큰 프로젝트를 아쉽게 끝내지 못했지만, 이 프로젝트 경험을 기반으로 겸손한 자세로 성공적인 프로젝트를 무사히 완료할 수 있게 준비할 것이다.

 

첫 번째 물류 프로젝트 회고(2021년 10월 5일 ~ 2022년 9월 5일)

끝.