물류개발자 첫 프로젝트 후기 번외편(아직 프로젝트 진행하고 있음)

2021년 9월 1일에 입사하여, 2021년 10월 5일 프로젝트에 투입됐다. 벌써, 프로젝트에 투입된지 10개월이 되고 있다. 이 블로그를 봤으면 알다시피 원래는 웹개발에 관심이 전혀 없었고, 웹개발을 하기 위해 취업을 하지도 않았다. 데이터 분석과 AI 분야로 취업을 하려고 했는데, 팀을 웹개발로 배정을 받아 처음에는 직무가 맞지 않아 퇴사에 대한 생각이 많았다. 근데, 웹개발도 해보면 재밌지 않을까? 라는 생각으로 퇴사를 하지 않고 지냈다.

 

그렇게, 2021년 10월 5일 규모에 비해 프로젝트 비용이 말도 안되는 가격을 받고 진행하는 프로젝트에 투입 됐다. 지금 이 글을 작성하고 있는 2022년 07월 19일까지의 프로젝트를 진행하면서 겪었던 것과 배웠던 것 프로젝트를 진행할 때 정상적인 프로젝트가 어떤지를 기록한다.

 

프로젝트 안에서도 여러 개의 중규모 프로젝트로 나뉘었다. 그래서, 아래의 목차는 중규모 프로젝트 순으로 리스트를 적는다.

---

첫 번째 중규모 프로젝트 : TPL WMS(Third Party Logistics Warehouse Management System)

아무것도 모르는 상태에서 투입된 프로젝트다. 이 TPL WMS(Third Party Logistics Warehouse Management System)의 프로젝트는 독일의 함부르크와 코퍼에 있는 물류 센터에 적용될 시스템을 개발했다.

 

그래서, 처음에는 솔루션을 익히기 위해 화면 1개를 배정 받아 개발을 시작했다. 팀장님과 다른 PL님이 서포트를 해주시고, 개발은 혼자 진행했다. 개발한 화면은 WMS의 프로세스 중 피킹(Picking)이었다. 이제 출고 오더를 내리면, 저장되어 있는 곳에 가서 물품을 어떤 것을 가져와서 패킹(Packing)을 할건지에 대한 처리를 할 수 있도록 하는 것이었다. 여기서 처음으로, 오전 9시에 출근해서 새벽 6시에 퇴근하는 경험을 얻었다. 21시간 근무는 조금 너무하지 않나...?

 

1. 코드 컨벤션(Code Convention) 필요성

프로젝트를 진행하면서, 코드가 정말 중구난방으로 되어 있었다. 개인마다 코드 컨벤션이 달라 어떤건 카멜 로우, 어떤건 카멜 어퍼 케이스로 되어 있고, 그냥 대문자인 메서드들도 있었다. 여기서, 확실히 기업마다 코드 컨벤션(Code Convention)이 필요하다고 느끼고 개인적으로 코드 컨벤션을 만들었는데 묵살 당하여 지금은 내 노션에 남게 되었다.

 

2. 코드 리뷰의 필요성

인턴 경험과 회사의 짤막한 맛보기를 하면서 코드 리뷰를 하는 모습을 많이 봤었다. 근데, 여기는 코드 리뷰도 따로 없었고, 일하기 바쁜 모습만 보였었다. 원래는 PL급 분들이 코드리뷰를 해줬으면 좋겠었는데 그런 기회가 전혀 없었다. 그래서, 결국엔 혼자서 공부하고 혼자서 판단해야 하고, 혼자서 개발을 해야 한다는 것에 아쉬움을 느꼈다.

 

3. 협업의 즐거움

1번, 2번과 같이 확실히 기술에 대한 것은 부족했지만, 일이 힘들어도 사람이 좋으면 기분 좋게 일을 할 수 있고, 업무의 효율성도 높아진다고 확실히 깨달았다. 아침 9시에 출근해서 밤 9시나 10시까지 남으면서 일을 해도 강력한 서포트와 세세한 부분의 업무 프로세스를 알려주다 보니, 오히려 재밌는 감정이 힘들었던 감정보다 더 높아 프로젝트를 재밌게 했다. 협업을 하면서 따로 협업툴을 사용한 것은 없다. 원래는 SSAFY 교육에서도 JIRA를 사용하여 일정 관리와 협업 관리를 했었는데, 협업툴이 없는건 조금 아쉬웠다.

 

4. 업무 프로세스의 습득

이 프로젝트가 WMS의 거의 정통된 프로세스라고 할 수 있다. 제품이 입하부터 입고 예정, 입고, 적치, 피킹, 패킹, 출고까지. WMS의 모든 프로세스를 볼 수 있었던 프로세스라 확실히 더 인상 깊었다고 할 수 있다. 더 나아가, 지금 위치에서는 이 TPL WMS 운영 및 헬프 데스크를 운영하기까지 그 기간 동안, 프로시저와 데이터의 흐름을 혼자서 살펴본 경험 시간이 축적되어 더욱 프로세스에 통달할 수 있었다.

 

5. 경험

이 프로젝트를 통해서 얻어가는 것은 아래와 같다.

 

1) WMS 프로세스

프로젝트의 WMS 프로세스를 공부하기 좋다. 정통적인 WMS 프로세스에 따라서, 데이터 플로우, 업무 처리 프로세스, 프로시저 등을 파악할 수 있었고, 각 프로세스에 대한 업무 특수 처리에 대해 알 수 있었다.

 

2) 솔루션 기능 파악

솔루션에 정의되어 있는 기능들을 파악하기에 너무 좋은 프로젝트였다. 추가적으로, 스크립트와 백엔드의 MVC 패턴에 대해 조금은 공부했던 프로젝트였다.

 

6. 개발 환경

- Eclipse 2021-06 4.20.0 Version(Build id : 20210612-2011)

- Spring 4.3.25.RELEASE

- JDK 1.8

- 소스 형상 관리 : SVN 사용 후 GitLab으로 전환

- 배포 : Jenkins

---

두 번째 중규모 프로젝트 : TPL TMS(Third Party Logistics Transportation Management System)

1. PL의 책임감

이 프로젝트는 대기업에서 이직하신 사수님과 3년차 선배와 함께 3명이서 TPL TMS(Third Party Logistics Transportation Management System) 프로젝트를 진행했다. 여기서, PL을 맡고 계신 사수님께서 업무를 분배했는데, 여기서 명언을 던지셨다. "일을 기간 안에 못해도 된다. 내가 업무를 분배 했고, 업무에 대한 일정도 내가 잡았으니 내가 책임 진다. 그러니까 걱정하지 말고, 조급해 하면서 하지 마"라는 말에 진짜 정말 감동을 받았다. 지금까지, 대기업에서 이직하신 사수1님과 또 다른 사수2님이 이 마인드를 가지고 계셨다. 그래서, 지금 프로젝트를 해도 이 사수님들과의 추억이 너무 그립다. 같이 저녁 식사하고, 지하철 막차까지 야근을 하며, 다음날 아침에 같이 커피 한 잔하는 그 시간들이.

 

2. 첼로 스퀘어의 맛보기

사수님과 같이 프로젝트를 진행하면서 리뷰같은 스터디성 회의를 많이 했다. 그러면서, 삼성 SDS의 첼로 스퀘어를 눈으로 맛보기를 해봤고, 첼로 스퀘어를 보면서 우리 솔루션도 이렇게 변하면 어떨까? 하는 생각도 많이 들긴 했다. 이것 때문에 다른 회사의 솔루션들도 궁금해지기 시작했고, 솔루션 개발 경험도 쌓아 보고 싶은 마음도 생겼다. 사수1님과 사수2님도 솔루션 개발에 큰 관심을 가져 이직을 하셨지만, 해보지 못하고 다른 곳으로 이직을 하셨다. 같이 했으면 바람이 있었는데 아쉽다.

 

3. TMS(Transportation Management System) 프로세스

같이 프로젝트를 진행했던 사수1님과 같이 프로젝트를 진행했는데, 물류 비지니스 및 개발 쪽에서 10년 경력이 있다보니, WMS와 TMS에 대해 교육을 정말 많이 받았다. 확실히 이러한 시간을 많이 보내니 입사한 지 1년이 안됐는데, 지금 하고 있는 프로젝트의 프로세스를 쉽게 파악할 수 있었다. 물론, 큰 틀에서의 프로세스는 쉽게 파악할 수 있었다. 세부적인 프로세스는 소스를 까보면서 해야하긴 하지만 말이다. 그래서, 이 프로세스의 교육이 정말 중요하고 물류 개발로 가려면 필수적인 것을 알게된 계기가 되었다.

 

4. 개발환경

- Eclipse 2021-06 4.20.0 Version(Build id : 20210612-2011)

- Spring 4.3.25.RELEASE

- JDK 1.8

- 소스 형상 관리 : GitLab

- 배포 : Jenkins

 

---

세 번째 프로젝트 : 통합 WMS/TMS 물류 구축 시스템

이 프로젝트가 진또배기 프로젝트다. 이 프로젝트가 전체 프로젝트 중 약 70~80%를 차지한다고 봐도 무방하다. 이 프로젝트도 지금까지 하고 있다. 이 프로젝트를 진행 할 때, TA 파트와 BM 정산 파트를 진행했다. 이 중에서도, BM 정산 파트는 진짜로 구멍난거 막으러 다니는 걸로 지금 하고 있고, TA 파트에서 정말 많은 것을 배웠다. 정말 많은 것도 배운만큼, 잡다한 것들도 혼자하고 있다.

 

1. TA

TA 업무를 하면서 했던 업무들은 정말 많은데, 이것은 조금씩 수정해서 추가를 하겠다.

 

1) MVC 패턴

웹개발을 많이 해본 터가 아니라, MVC 패턴부터 새로 공부를 시작했다. 지금은 MVC 패턴을 더 나아가서, MVP 패턴과 MVVM 패턴 등을 더 쉽게 이해할 수 있었고, MVC 패턴을 알고 있으니, 데이터의 처리 방법과 dispatcherservlet의 과정들을 확연히 알아 개발에도 정말 용이하게 잘 사용했다. 예를 들어, 인터럽트라던지? 아니면 interceptor 라던지? 로그인 처리를 하면서 interceptor에 대해 더욱 공부할 수 있었고, 이것만 알고 있으니 데이터의 흐름은 쉽게 파악할 수 있었다.

 

 

2. BM(정산)

정산 쪽은 결함 치기 바빴다. 정산 프로세스는 큰 틀로는 이해를 하고 있는데, 이제 세부적인 프로세스를 모르고 TA 업무를 하다가 BM 쪽 대응해 주려고 온거라 프로세스보다 기능적인 측면이 너무 에러가 많아서 여기는 주구장창 해결하고 있다. 이제 좀 기능 에러를 치고 나면, 프로세스를 파악해야 할 정도다.

 

3. 개발환경

- Eclipse 2021-06 4.20.0 Version(Build id : 20210612-2011)

- Spring 4.3.25.RELEASE

- JDK 1.8

- 소스 형상 관리 : GitLab

- 배포 : Jenkins

---

프로젝트를 진행하면서 좋았던 점

1. 웹개발 실력 향상

솔직히 말해서 웹개발 실력이라기 보다는 신기술에 대한 개발 경험을 보유한 것이 더 맞다. 이 프로젝트를 하면서 로그인, SSO 로그인, SSO Token 체크, Session Clustering, Redis 등 기술들을 적용함으로 정말 배운게 많았다. 이 블로그를 보면 TA 업무를 진행하면서 혼자 공부할 수 있는 시간과 정리할 수 있는 시간이 있었고, 같이 일하는 사수에게 물어보면서 개발 지식을 확립하는 과정을 가졌다. 이 과정이 이 프로젝트를 진행하면서 가장 큰 수확이라고 할 수 있고, 웹개발의 재미를 느꼈던 곳이 바로 이 분야다.

 

2. 인적 네트워킹 형성

필자는 개발 0년차다. 아무것도 모르고, 어떠한 지식도 없어 항상 부족한 사람이다. 그렇기에, 누군가가 나를 이끌어 줄 수 있는 사수가 필요했다. 그 사수가 위에서 설명한 TPL WMS와 TPL TMS를 하면서 인적 네트워킹을 쌓아나갔다. 한 분은 웹 개발을, 한 분은 물류 프로세스와 물류에 대한 경험이 정말 많으신 분이었고, 지금도 기회가 생긴다면 같이 또 일하고 싶을 정도다. 그 분들 덕분에 프로젝트도 정말 재밌게 진행할 수 있었고, 일하는 재미를 알아가게 된 계기가 되었다. 아직도 그립다.

 

고객사 측에서 정말 대단하신 분도 있었다. 원래 팔은 안으로 굽는다고 하는데 안도 밖도 굽히지 않는 분이 계시는데, 확실히 IT 지식에 대한 레벨도 높고, 개발 역량도 높으신 분이 있다. 그 분은 소속 회사든, 소속 회사가 아니든 잘못된게 있으면 바로 지적을 하고, 거기에 대한 해결책이나 트러블슈팅을 할 수 있도록 방향을 잡아 주는게 너무 멋있었다. 그 분처럼 되는 것이 내 모토가 되는 것처럼 꾸준하게 공부를 해야하는 이유도 만들어졌다.

---

프로젝트를 진행하면서 아쉬웠던 점

1. 고객사와의 협업 부재

1) 필요 정보에 대한 요청 시 늦은 응대

지금 프로젝트를 진행하면서 고객사와 함꼐 프로젝트를 진행하는 것이 아니라 거의 수행사만 프로젝트를 진행하는 느낌을 강하게 받았다. 물류 프로세스에 대한 마스터 데이터만 해도 정말 중요하다. 기존에서 사용하고 있던 마스터 데이터를 받기까지 진짜 반 년 이상이 걸린듯 하다. 이미 이러한 것은 분석 및 설계 단계에서 실질적인 데이터를 보면서 진행을 했어야 하는데, 이게 개발이 거의 끝나는 시점에 주고 있으니 프로젝트가 잘 진행되는 것도 신기할 따름이다. 이게 가장 대표적인 케이스다.

 

이 외에도, 필요한 데이터가 있어서 제공 요청을 하면 거기에 대한 회신은 정말 느리게 왔었다. 물론, 고객사도 그 만큼 바쁘다는 것을 안다. 그래도 몇 번이나 요청을 했는데도 회신조차 없으면 이게 프로젝트를 진행하라는 건지 모르겠다.

 

2) 현업 고객사와 본사 고객사의 소통 부재

이게 정말 스트레스를 많이 받았다. 실질적으로, 솔루션을 사용하는 입장은 현업에서 많이 사용한다. 그래서, 현업이 요청하는 것에 따라 요구사항 및 수정사항을 적용해놨더니 본사 고객사에서는 왜 이렇게 했냐고 하니 어떤 입장에 맞춰서 개발을 진행해야 할지 모르겠다. 그리고, 프로젝트를 진행하면서 요구사항 정의서까지 컨펌을 받아서 진행한 것인데, 계속적으로 추가하고 변경하고 원래 프로젝트가 이런 것인지는 모르겠다. 이 사항에 대해서는 현업과 본사 프로젝트 진행을 하는 사람끼리 소통을 통해 입장을 제시해야 프로젝트도 수월하게 진행할 수 있는데 이 점은 정말 아쉽다.

 

2. 컨설팅 팀의 부재

프로젝트를 진행하면서 누가 컨설팅 팀을 고용하는지 모르겠지만, 프로젝트 중간에 들어왔을 때 컨설팅 팀이 없었다. 프로젝트 업무 컨설팅 팀도 따로 없어서 수행사 측에서 컨설팅을 진행하고, IT 인프라 쪽도 컨설팅이 없어서 이 부분에 대해서는 고객사 측에서 맡았다. 근데, 이것도 수행사 측에 던져버리니... 인프라 구성도, 인프라 개발도, 인프라 테스트도 수행사가 하고 있으니 제 입장에서는 불만이 한가득. 컨설팅 팀이 없으니 설계 쪽에 자꾸 구멍이 생기는게 당연사가 아닐까?

 

3. 수행사

고객사와의 문제가 있었다면, 수행사인 우리 측에서도 문제가 많았다.

 

1) 인력 문제

수행사 측에서 사람이 정말 많이 나갔다. 프로젝트도 프로젝트지만, 반말과 윽박 등 같이 일하는 입장에서 정말 해서는 안될 것들을 하고 있다. 사람에 대한 매너와 적절한 행동들은 거의 없었으니 기존에 있던 프리랜서 분들과 협력 업체, 우리 회사의 사람들도 다들 떠나갔다. 이 문제로, 필자와 호흡을 정말 잘 맞췄던 사수들이 대거 나갔다. 이 문제에서는 진짜 해결이 되어야 하는데, 그런게 없으니 인력 문제가 날 수 밖에 없었다.

 

2) 인력 문제로 인한 인력 채워 넣기

지금 이 문제로 필자가 정말 스트레스를 많이 받는다. TA 업무로 오랜 시간동안 진행을 하고 있었는데, 다른 파트에 문제가 생겼으니 인력 땜빵으로 팔려갔다. TA 업무만 하다가 다시 물류 업무로 돌아오니 처음에 적응할 수 있는 시간도 제공해야 하는데, 당장 결함부터 해결하라고 하니 누가 할 수 있는지 모르겠다. 이런 압박과 되도 않는 일정으로 지금까지 스트레스를 받고 있다. 지금까진 프로젝트를 성공적으로 수행을 해야 하니, 시간 분배를 해서 해결하고 있는데 30분마다 "어디까지 진행 됐어?" 계속 압박을 주니 개발자 입장에서는 얼마나 난감하고 화가 나겠는지. 이게 필자 뿐만 아니라 같이 진행하고 있는 사수들도 받고 있으니 미쳐버리겠다.

 

3) 인력 누수 현상에 대한 태도

인력 문제에 따라 인력 누수가 생겨 났다. 근데, 인력 누수 현상을 그냥 보기만 하고 제대로 된 포지션도 취하지 않은 채 그냥 보내버렸다. 어느 정도 퇴사하는 사람들을 잡을 수 있도록 액션을 취해야 하는데, 그것 조차 안하고 보내버리니 프로젝트를 어떻게 진행하려고 이런 어텐션을 취하는 것인지 모르겠다. 정말 문제가 많은게 바로 이런 문제다.

 

4) 강제적인 야근

수행사 측에서 야근을 하지 않는 사람을 대상으로 공무원 이냐고 하는 사람이 있다. 이게 지금 시기에 나오는 말인지 모르겠다. 야근 안하면 욕부터 박고 있으니 프로젝트 하는 사람들에게는 강제적인 야근을 할 수 밖에 없다. 이게 웃긴게 오픈 직전이나 테스트 전에 야근하는 건 그렇다고 할 수 있는데 그 시기도 아닌데 야근하라고 강요하는건 WBS를 애초부터 잘못 잡은게 아니지 않나 의심이 된다.

 

5) 기술 스택 부족

처음 프로젝트에 투입 됐을 때, 기술 스택에 대해서 너무 깜짝 놀랐다. SSAFY 교육을 받을 때, Vue.js와 스프링 부트, JPA, MyBatis를 사용했는데, 여기 와서는 Vanilla Js, 스프링 레거시, IBatis를 쓰고 있었다. 여기서부터 개발 환경에 대해 정말 심히 고민했고, 거기에 솔루션에 대한 테크니컬 리더가 없었다. 테크니컬적인 부분을 프리랜서로 채워서 진행하다 보니 우리 솔루션이 맞는지 심히 의심스러웠던 것 중 하나다. 기술 스택이 없다보니 기술에 대해 물어볼 사람도 없었고, 혼자 터득해야 하는 상황과 구글링을 통한 시간 소요가 너무 많다 보니 일의 효율도 나지 않았다.

 

그리고, 소스 형상 관리를 SVN에서 GitLab으로 변경을 하니 Git을 사용한 경험이 없는 사람들이 너무 없었다. 그래서, 2달 동안 여기 저기 불려다니기만 했다. 소스 충돌 났을 때 해결 방법에 대한 것을 메일로 배포를 해도 직접 하시지를 않으니 계속 혼자만 불려다녔다. 정말 100번 이상 소스 충돌로 불려다니고, 반복되는 작업에 프로젝트를 진행하면서 정말 많이 지쳤다.

---