두 번째 물류 프로젝트 회고(2023년 2월 23일 ~ 2023년 8월 31일)

개발자로 갔지만, PL 역할도 해보고, PM도 해봤다.

---

약 7개월동안 진행되었던 두 번째 물류 프로젝트가 2023년 8월 31일 부로 끝이 났다. 최대한 프로젝트를 진행하면서 주마다 TIL을 작성하여 무엇을 했는지를 기록하려고 했지만, 처음에는 시간을 들여 작성을 했다가 프로젝트의 후반을 달려갈 때 시간과 여유가 없어 조금 흐지부지 작성을 하게 됐다. 그래도, 이번 프로젝트에서도 배운 것은 언제나 있어서 뜻깊은 프로젝트 회고를 시작한다.

---

WMS 구축 프로젝트

2023년 2월 23일날 WMS 구축 프로젝트 멤버로 초청(?)을 받아 프로젝트를 수행하게 되었다. 기존에 WMS 솔루션이 있으니, 해당 솔루션을 가지고 와서 확장 개념으로 구축하면 된다라는 말에 쉽게 끝날 수 있다라는 계산이 끝나 참여를 한 프로젝트였다.

 

2월에 프로젝트에 투입이 되어 소스 분석을 가장 먼저 진행을 했고, 기존에 PM과 PL이 있으니 나는 소스 분석만 진행을 했는데, PM 분도 이 프로젝트 금액의 PM이 처음이었고, PL 분도 PL 경험이 전혀 없는 분이 오셨다. 프로젝트를 진행하는데 있어서 경험이 적은 PM 분과 무경험의 PL이 있으니 굉장히 부담스러웠다. 과연, 일정도 잘 지키면서 프로젝트가 온전히 끝날 수 있을까? 라는 생각이 강하게 들었다. 결국엔 PL 분이 PL의 역할을 제대로 수행하지 못해 내가 같이 PL 업무를 진행해야 하는 상황이 발생했고, 이 때부터 뭔가 프로젝트에 빨간불을 띄워 긴급성을 알려야 한다라는 생각이 강하게 들었다.

 

 

내가 프로젝트에서 맡은 것은 인터페이스 개발이었다. 신규 인터페이스 건이 있어 개발을 진행하고 있는데, 4월이 되어 개발에 대한 일정이 조금씩 밀리기 시작했다. 개발이 조금씩 밀리니, 내가 하던 일도 얼른 끝내서 지원을 해주는데도 전혀 진척도가 나아지질 않았고, 확인을 해보니 프리랜서 분의 일정이 조금씩 밀리기 시작했다.

 

아무리 생각을 해도, PL에 대한 선택이 잘못되도 너무 잘못되어 이 프로젝트의 방향성이 술에 취해 비틀비틀 거린게 분명하다고 생각한다.

 

PL 분이 제대로 설계를 하지 못해, PM이 설계를 하고 있고 프로젝트의 전반적인 프로세스도 이해를 하지 못해 전체적인 프로세스를 제대로 확립해야 하는 것도 없었고, 탄탄한 프로세스 로직을 세우기에 영향이 매우 적어 PM에게 프로젝트의 분석/설계를 거의 도맡아서 업무의 집중도가 높아졌다. 그러다 보니, 나도 프로젝트의 위급성을 조금 느낀 것인지 전반적인 프로세스와 분석 및 설계에 참여를 하면서 PM분을 도왔고 결국엔 PL로 오신 분은 개발자가 되었고, 개발자 신분으로 온 나는 PL의 역할을 하게 되었다.

 

프리랜서의 급여가 정말 높았는데 PL의 역할을 제대로 하지 못하니 그 돈을 나에게 줬으면 더 열심히 하지 않았을까?라는 생각이 많이 든다. 

 

엎친데 덮친격으로 프리랜서 분이 맡은 파트에서 개발 지연이 일어 났고, 프로젝트 진행도를 높이기 위해 내가 맡은 인터페이스 개발에 시간을 정말 많이 쏟았다. 빨리 인터페이스를 끝내고, 다른 파트라도 개발을 빨리 해서 진행도를 높이기 위해서. 개발 초창기에 야근하고, ERP 담당자를 꼬셔 매 주마다 주말에 출근해서 모든 인터페이스 개발과 테스트를 끝냈다.(물론, 추후에 고객사 요청으로 인터페이스 방식을 바꿔달라고 하여 다시 수정하고, 프로세스 바뀌어 수정하고 수정을 정말 대규모로 진행했다.)

 

그렇게 인터페이스를 마무리 하니, 이제는 넘어야 할 산이 너무 많았다. 기존의 WMS를 가져와서 사용한다고 보기에는 요구사항이 너무 많았고, 챙겨야 하는 것도 정말 많았으며, 참고해야 하는 레퍼런스도 정말 많았다. A 시스템을 이미 사용하고 있는데, A 시스템과 B 시스템, C 시스템 총 3개를 고려하여 새로운 것을 만들어야 하니 시간이 너무 부족했다. 이러다 보니, 분석해야 하는 사람도 많이 적어 혼자 진행하기에는 너무 무리가 됐다.

 

 

이 프로젝트를 진행하면서 PL의 부재가 정말 컸다. 나도 PL을 해본 적이 없는 터라 무엇을 챙겨야 하는지 모르고, 그저 프로세스만 제대로 분석만 해서 그것에 맞게 개발만 진행했을 뿐 설계를 내가 맡아 하지 않아 조금씩 문제가 생겼다. 그렇게 일정이 조금씩 밀리면서 오픈 날이 다가왔다.

 

오픈을 하기에는 우리도 문제가 있었지만, 고객사에서 오픈을 해도 준비를 하지 못해 고객사 측에서 먼저 오픈 연기 요청을 했다. 이렇게 우리에게도 시간이 조금 번 셈이 되었고, 울산과 김해를 출장 다니면서 실질적으로 인터페이스와 입고, 재고의 대부분을 제외하곤 프리랜서 PL 분이 맡은 출고 파트는 출장 가서 개발이 완료되었다고 해도 무방했다.

 

이 프로젝트가 이렇게 힘들게 진행됐던 것은 다양한 요인이 있었다.

 

1. 고객사 측의 운영 업무 진행과 타업무 병행으로 인한 프로젝트 관심도 저하 및 PM 변경

이 문제가 제일 컸다. 계약 관계가 갑, 을, 병 형태로 계약이 됐었고, 우리는 병 형태로 되어 있었다. 근데, 갑에서도 프로젝트에 대한 관심도 낮았고, 을에서도 PM이 변경되어도 프로젝트 관심이 높지는 않았다. 그렇다 보니, 화면 설계를 하여 중간 보고를 통해 화면 컨펌을 받았는데도, 나중에 되어 왜 이렇게 설계를 했냐는 식이 너무 많았다. 그 전에, 이렇게 화면을 개발하겠다라고 보고까지 했는데도 말이다.

 

2. 확립되지 않은 요구사항

처음에 요구사항을 받는데, 요구사항이 명확하지 못했다. 매번 출장을 가서 업무 협의를 받게 되면 항상 요구사항이 바뀌었고, 이에 따라 설계와 개발 방법들이 정말 크게 바뀌었다. 그렇게 계속 변경이 되니, 다른 부분에도 영향이 가서 조금씩 기능의 오류가 발생하기 시작했다.

 

이 외에도, 우리 쪽에서도 출고 파트 개발 지연이 있다.

 

계속 이 문제들이 발생을 하다 보니, 2차 오픈 지연이 발생했다. 이번 오픈 지연은 우리 측은 어느 정도 준비가 되었지만, 고객사 측에서 만족을 하지 못했는지 오픈 연기를 했다. 근데, 이 때부터 물류 프로세스 요구사항이 조금씩 구멍이 생겼는지 고객사 측에서 이것저것 바꿔주세요 라는 말이 정말 많이 나왔다. 기존에 A라는 것을 만들어 달라고 해서 A를 만들었는데 왜 그렇게 만들었냐고 B로 다시 만들어 달라고 하고, 그래서 B로 만들었는데 이제는 또 다시 미안하다고 A로 다시 바꿔달라고 하라는 식의 요구사항이 최소 10가지 이상은 되었다.

 

이렇게 계속 변경이 되어 버리니 개발과 테스트 하는 것에 시간이 정말 많이 소비되었다.

 

결국 이 프로젝트는 2번의 오픈 연기와 함께 내부의 적과 외부의 적이 프로젝트 종료에 큰 영향을 주었고, 결국엔 8월 14일날 오픈을 하게 되었다.

 

오픈을 하기 전, 서울에서 대응하는 팀과 센터에서 대응하는 팀을 나눠 진행을 했다. 그 중 나는 센터에서 대응하는 팀으로 김해로 내려가게 되었고, 오픈 후에 발생하는 문제에 대해 거의 내가 다 처리를 하고 있었다. 그런데도 화나는게 출고 파트에서 계속 에러가 발생했고, 애초에 설계도 잘못하여 뜯어고쳤다. 물론 내가 다 뜯어 고쳤다. 아무런 케이스를 고려하지 않고 개발을 하니 대표적인 케이스가 나와도 진행이 되질 않았다.

 

내가 처리하지 못하는 부분은 서울에서 대응하는 팀에게 문제들을 올려 보내는데, 대응하는데 걸리는 시간과 방법이 너무나도 잘못됐다. 문제가 발생하여 그 문제를 해결하면 그 문제와 연관되어 있거나 유사한 것들이 있으면 그것까지 고려하여 수정을 해야 하는데, 단지 그 부분만 수정을 하니 매번 똑같은 문제가 발생할 수 밖에 없는 구조였다. 이 파트를 담당하고 있는 프리랜서의 책임감이 너무나도 떨어지는게 확연하게 보였다.

 

 

솔직히 말해서, 프리랜서 분에게 과도한 업무를 지시한 것도 아니었다. 원래는 A부터 D까지의 업무를 하기로 계약을 했는데, B,C,D는 커녕 A도 제대로 끝내지 못해 A도 내가 가져가고, B도 가져가고, 결국엔 만들어 놓은 C와 D도 의도한 것과는 너무 달라 다 뜯어고쳤다.

 

정말 많은 글에서 프리랜서는 자기가 맡은 일만 잘하면 된다라는 글을 정말 많이 봤다. 자기가 맡은 일만 잘하면 얼마나 좋을까 라는 생각을 매번 들게 했던 프로젝트였다. 물론, 누가 야근하는 것을 좋아하겠는가? 나도 야근하는 것은 정말 싫고 하고 싶지도 않다. 하지만, 자기가 해야 하는 일은 데드라인 내에서는 개인 일정에 맞게 잘 끝내고 가야하지 않을까? 라는 생각이 아직도 짙고, 결국엔 계약 종료까지 이기적인 모습으로 마지막 인상이 남겨졌다.(업무를 하면서 간단하게 인터넷 서칭이나 핸드폰을 하는 것은 아무렇지 않지만, 드라마 또는 유튜브를 계속 틀어놓고 일을 하는 모습을 보면 왜 문제가 발생을 하는 지는 너무 확연하게 보였다.)

 

이제는 프리랜서 분이 남겨주신 문제들을 남은 사람들이 다 치워야 할 때가 왔다. 이게 정말로 너무 컸다. 이것만 아니었으면 정상적인 오픈을 하고 이미 프로젝트 철수까지 하는 기간이었는데 이 문제로 인해 8월 31일까지 연장이 되었다.

---

오픈을 했을 때의 그 긴장감은 너무나도 컸다. 내가 맡은 파트는 인터페이스와 입고, 재고, 협력사 파트였다. 다만, 원래 나는 인터페이스만 하기로 했는데, 다른 사람들이 저 부분을 못하겠다고 하니 나라도 맡아서 개발하고 진행을 했다. 무튼, 오픈은 월요일이었는데, 실질적인 오픈은 일요일에 오픈을 했다. SAP에서 PO와 DO가 내려오면서 운영 데이터가 흘러가기 시작했고, 월요일에 작업하는 것들을 준비 함으로 오픈이 진행됐다.

 

월요일 아침 제품 출고가 있었다. 근데, 시작부터 출고 파트의 피킹이 제대로 진행되질 않았다. 현장에 있는 작업자 분들의 안된다는 소리와 함께 제품을 다 실고 출발해야 하는 차도 나가질 못해서 기다리고 있는 상황에 결국엔 PDA가 아닌 WEB에서 처리를 하여 진행을 했었다. 여기서 정말 간절했던 것은 출고 파트 담당자는 왜 오픈할 때 센터에서 대응하는 팀으로 오지 않았냐는 것이었다. 인터페이스만 챙기기도 바쁜데, 입고와 재고, 협력사도 맡게 되었고, 나아가서 출고까지 봐야 하니 울화통이 터졌다.

 

팀을 이렇게 나눴던 결정에 정말로 큰 회의감이 느꼈다. 출고가 되질 않아 나는 긴박함과 긴장감, 그리고 조졌다라는 그 생각이 머리에 맴돌고 해결 방법을 부리나케 찾고 있는데, 서울에서 대응하는 팀은 핸드폰 보고 놀면서 있었다라는 그 말 한마디가 현타오게 만들었다. 처음으로 이 문제들을 가지고 PM님과 울분터지는 대화를 하게 되었고, 나중에 식사하는 자리에서도 왜 이런 결정을 했는지 또 물었다.(진짜 너무 억울했고, 나는 개발자 신분인데 PL이 PL역할을 하지 못해 내가 조금 대리로 진행했던 터라, 고객사에서도 내가 PL인 줄 알고 거의 모든 협의를 나와 함께 진행을 했고, 이러다 보니 업무가 너무 몰려 현타왔다.)

 

이렇게 울분을 토하면서 대화를 하는 이유는 있었다. 정규직은 아직 만 2년이 안된 나와 만 1년이 안된 신입사원 딱 2명이었다. 아직 경험이 부족해서 소규모 파트를 맡아 경험을 쌓고 있는 와중인데도 출고 파트를 담당하는 사람은 왜 놀고 있고 문제가 생기면 우리가 해결을 해야 하는 건지에 대한 생각이 너무 깊었다. 출고 파트에 문제가 생겨 그 문제를 신입사원과 밤 늦게까지 해결하고 있는데, 출고 파트를 맡은 프리랜서는 왜 퇴근 안시켜주냐고 온갖 짜증을 부리는데 너무 억울했다. 물론, PM님도 개발 경험이 많아 데이터적인 문제는 같이 찾아주셨지만, 신입사원 분도 출력물 파트를 맡아서 진행했던 터라 나도 일이 많았고, 신입사원 분도 많았었다. 그 와중에 출고 파트가 터지니 이 문제는 온전히 나랑 신입사원 분이 맡아서 해야 하는 상황이 왔고, 결국엔 마지막까지 보완과 요청사항을 해결하고 프로젝트의 막을 내렸다.

 

물론, 지금도 가끔 전화가 오긴 한다.

 

이번 프로젝트에서 득보다는 실이 너무 많았다.

 

인터페이스 개발 경험과 물류 프로세스가 좀 더 견고해 졌지만, 내 시간이 없어졌고, 주말도 없어졌고, 스트레스와 업무 강도는 더욱 높아졌고, 제대로 된 보상도 받지를 못했다.

 

프로젝트 팀이 있으면 같이 으쌰으쌰해서 성공하자!라는 생각은 우리 정규직끼리만 생각을 하고, 프리랜서는 일정에 제외를 하고 시작해야 한다는 것도 알게 되었다. 물론, 지금까지 프로젝트를 진행하면서 나랑 정말 잘 맞는 분들이 더 많으셨다.(이번이 좀 특이 케이스였다.)

 

환상을 접고 이제는 현실적으로 냉정하고 이성적으로 프로젝트를 진행하고, 프리랜서와는 단순 계약 관계로 맨 처음 계약할 때의 요구사항들을 정상적으로 에러가 없이 진행이 됐는지를 매번 체크하면서 진행을 해야 하는게 맞다는 것을 알게 되었다. 지금까지 "나한테만 피해가 없으면 돼!" 라는 마인드로 친하게 지냈는데, 한 번 겪고 나니 진짜 열불 터진다.(서로 상생 관계로 도와가면서 진행을 했다면 인적 친밀도가 높아져 괜찮았을텐데, 나는 도와줬는데도 내가 부탁을 하니 왜 추가 요건 받았냐고 되려 받아치니 화가 안날 수가 없었다.)

 

다른 외부 개발자분이 오셨는데, 그 분은 너무 잘해주시고 가셔서 다음에 프로젝트를 진행할 때 오히려 같이 하자고 하고 싶은 분이셨다. 개발 속도도 빠르지만, 오히려 에러율도 낮아서 너무 만족스러운 분이셨다. 저도 많이 그 분에게 배워갈 수 있었던 경험이었으니까 말이다. 감사합니다! 덕분에 잘 끝났습니다.

 

이렇게 프로젝트를 마무리하고, 이젠 팀을 옮긴다. 원래 AI와 데이터 분석을 전공했던 터라 AI로봇팀이 새로 생겨 팀 이동을 지원하였고, 이제는 그 팀에서 프로젝트를 진행할 것 같다.

 

무튼, 두 번째 물류 프로젝트 회고(2023년 2월 23일 ~ 2023년 8월 31일)

 

끝.