[회고] 1년간의 프로젝트를 통해 배운것

지금은 이직을 했지만, 전 직장에서 1년 3개월 정도 장기 프로젝트를 진행했었다.

외주 프로젝트였고, 클라이언트 회사의 차세대 물류 프로젝트의 일부 파트를 맡게 되었다.

 

처음엔 새로운 프로젝트를 만드는 거라 너무 재미있는 마음으로 시작을 했었다.

Next.js로 처음 프로젝트를 해보는 것도 좋았고, 잠깐 짬을 내서 만든 디자인시스템을 드디어 프로젝트에 적용해 볼 기회라 즐겁게 했었다

 

하지만 끝없는 야근과 주말출근,.,. 그리고 끊임없는 수정요청을 경험하면서 정신적으로 정말 지쳤고 너무너무 우울했었다.

( 진짜 몇 개월 동안 얼굴이 이랬음 )

그때 당시엔 힘들다는 생각밖에 없었는데, 지금 다시 돌이켜보면 그 1년 동안 스스로 많이 성장하고 경험치를 쌓았다고 생각이 들어서 이 경험에 대해서 꼭!꼭! 글로 남기고 싶었다.

배운 것

물류 도메인

우선 물류는 경험해보지 못했던 도메인이었다. 일단 물류는 용어 자체가 너무 어렵다.

그래서 프로젝트 투입되어서 용어를 익히는데 꽤나 시간이 걸렸었다.

프로젝트 온보딩기간도 따로 가지기도 했고, 기획문서를 보면서 흐름을 파악하려고 애쓰면서 물류라는 걸 배워갔다.

 

이 프로젝트가 화면자체의 복잡도도 높았어서 프론트엔드 개발자가 흐름을 파악하지 않고 구현하면 클라이언트의 생각과 다르게 구현되는 경우도 있었기 때문에 더더욱 기획을 이해하려고 하면서 개발을 했다.

 

그리고 클라이언트의 요구사항이 애매한 상태로 개발하면 1000000% 수정요청이 들어오기 때문에, 프로젝트 후반부에는 클라이언트가 요구사항을 적어주시면 기획의 상세 부분을 내가 정하기도 했고 기획 논의 회의를 들어가서 방향제안도 드리기도 했었다.

사실 이때는 "이 업무가 왜 나한테까지 넘어오지?"라고 생각을 자주 했었다.

근데 내가 상세기획을 하면서 물류가 재미있다는 걸 조금씩 느꼈다....ㅎ

 

그래서 난 물류 쪽으로 커리어를 쌓아볼까라는 고민을 하다가 지금은 물류, 풀필먼트 회사로 이직했다.

비개발자와 소통하기

이 프로젝트에서는 클라이언트, 컨설턴트분들과 많이 소통해면서 진행을 했었다.

화면이 많이 복잡하기도했고, 정상동작인지 버그인지 구분이 안 되는 기능들도 많았어서(ㅋㅋㅋ.....) 나한테 질문이 많이 들어왔다.

그럴 때마다 사실 많이 답답하긴 했다. 내가 이 화면을 제일 잘 아는 사람이라니ㅠㅜ 내가 이 프로젝트에서 나가면 어떻게 하려고 그러나 싶었다ㅠㅜ

그래도 최대한 많이 설명드리고 나오고자 했었고, 비개발자분들 또는 리액트를 많이 안써보신 분들에게 설명을 했었어야 해서 최대한 개발 용어를 제외하고 개념을 쉽게 이해할 수 있는 방식을 많이 고민했던 것 같다.

 

처음엔 나는 너무 나의 관점에서만 설명을 했었어서 만족스럽게 설명을 못 드린 적도 많았다. 이 과정을 반년정도 진행하다 보니 설명을 들으시는 분의 개발레벨을 고려하면서 설명을 했었고, 이러한 과정을 통해서 비개발자와 소통하는 연습이 많이 되었다.

그리고 내가 클라이언트를 설득하지 못하면 개발난이도가 확 올라가는 경우도 있었어서 어떻게든 클라이언트를 설득하고자 최대한 상대를 이해시키고자 했었다.

 

이러한 과정 속에서 자연스럽게 소통 훈련이 된 것 같다

답답한 경우도 많았고, 상대방의 말을 이해 못 한 적도 종종 있었지만 서로의 의견을 조율하는 과정 자체도 경험해 봐서 좋은 경험이었다고 생각한다.

클라이언트 회사 개발자들과 리액트 스터디 진행

내가 프로젝트를 시작할 때 리액트 18 공식문서가 새로 나온 시기랑 비슷한 걸로 기억하는데(아닐 수도 있음) 동료분이랑 공식문서 읽는 스터디를 같이 진행하자는 얘기를 했었다.

그래서 방식을 고민하다가 클라이언트 측 회사에도 개발자분들이 계셔서 혹시 리액트 스터디 수요가 있으면 같이 하자는 아이디어가 나와서 조사를 해보니 같이 하고 싶다고 하시는 분들이 많으셔서 외주로 들어간 회사에서 리액트스터디를 진행했었다.

 

스터디는 나랑 동료분이 일주일에 한 번씩 번갈아가면서 공식문서를 순서대로 발표하는 방식으로 진행했었다. 생각보다 참석인원이 많이 계셔서 준비를 힘들게 했었다. 1시간 정도 발표를 했었고 ppt도 만들어서 진행했다.

이 스터디를 하면서 나랑 내 동료분은 엄청 공부가 많이 됐다. 남에게 내 지식을 전달하기 위해서는 내 머릿속으로 완벽하게 이해를 한 상태여야 하기 때문에 준비자료를 몇 번씩 읽으면서 계속 머릿속에 넣었기 때문에 1년이 지난 지금도 그때의 내용이 선명하게 기억에 남아있다.

 

이런 발표형 스터디를 하면 가장 도움 되는 사람은 발표자 자신이라는 것을 이 스터디를 하면서 깨달았다. 다른 사람의 발표를 들으면 시간이 지날수록 기억이 희미해지는데, 발표자는 몇 번씩 확인하면서 준비하기 때문에 그런 것 같다.

 

그래서 준비할 때는 좀 힘들긴 했는데, 지금 생각해 보면 너무 좋은 기회였다.

워터폴 방법론

화면의 복잡도가 높았었기 때문에 개발하기 전에 데이터구조나 화면 설계를 충분히 고민하면서 개발을 했었다.

하지만 요구사항이 확 바뀌어버릴 때마다 데이터구조나 설계를 변경해야 하는 경우가 있었기 때문에 그때마다 극심한 스트레스를 받았었다.  중요한 데이터의 구조를 바꿔야 하는 경우도 있었고, 코드분리가 유지가 안되기도 했었다.

 

그러다 보니 나도 점점 기획과 디자인이 확실히 정해지지 않으면 개발을 시작하고 싶지 않았고, 기획을 명확하게 정해 달라는 요청을 많이 드렸었다. 물론 이게 나쁜 건 아니라고 생각한다. 개발시작하기 전에 기획/디자인이 명확하게 정해지면 일할 때 편하긴 하다.

 

하지만.,., 아래의 글을 보고 나서 약간 머리를 한 대 맞은듯한 느낌이 들었다.

내가 개발하는 방식이 애자일과 정 반대였다는 걸 깨달았고, 그래서 애자일방법론에 대해서 막 찾아봤었다.

대부분의 스타트업씬에서는 애자일방법론을 선호하고 적용하고 있기 때문에 내가 일하는 방법을 바꿔보자생각했음..!!

디자인시스템 사용

이 프로젝트에 들어가기 전에 2달 정도 짬이 나서 디자인시스템을 만들었다. 컴포넌트를 만들면서 구조에 대한 고민도 하고, 컴포넌트 사용자의 입장에서 편리한 방법이 무엇인지도 많이 공부했었다.

디자인시스템은 npm에 배포를 해서 물류 프로젝트에서 사용했었는데, 미리 컴포넌트를 만들어놓으니 너무 편하고 개발속도도 확 줄었다.

그리고 내가 만든 컴포넌트라 컴포넌트의 구조를 잘 알고 있었기 때문에 사용할 때도 너무 편했다.

 

하지만 디자인시스템을 수정해야 할 일이 생기면 그걸 고쳐서 배포하고 이 프로젝트에 다시 install 하는 과정자체는 좀 귀찮긴 했다..^_^;

지금은 모노레포에서 디자인시스템을 관리하고 있는데, 수정이 쉬워서 오히려 안정화가 안된 디자인시스템은 모노레포로 만들어서 사용하는 것도 좋은 것 같다.

프로젝트 리딩

이 프로젝트를 하면서 내가 어쩌다 보니 프로젝트 리딩? 매니징? 비슷한 역할도 같이 하게 되었다. 일정관리가 너무 안되어서 답답한 마음에 별도의 합의 없이 내가 동료들에게 태스크분배도 하고 프로젝트 일정을 정리했었다.

 

약간 자랑이긴 하지만, 프로젝트 후반으로 갈수록 나의 역할을 인정받기도 했고 다른 회사분들에게도 좋은 인상을 준 것 같다..! 리딩하면서 정신적으로 정말 힘들기도 했지만 성취감도 컸기 때문에 좋은 경험이었다.

 

무튼 리딩을 하면서도 느꼈던 게 뭐냐면 태스크를 분배할 때는 동료분들의 역량을 파악하는 게 제일 중요하다는 걸 배웠다. 이분이 어느 쪽에 지식이 빠삭한지, 작업 속도는 어떤지 등을 어느 정도 파악을 하고 태스크를 분배해야 전체프로젝트가 순조롭게 흘러간다.

그리고 태스크의 우선순위와 예상완료날짜 진행상태를 지속적으로 업데이트해주는 게 프로젝트 관리에 중요하다. 본인의 태스크 상태를 잘 관리하면 소통하는 데에 드는 시간도 줄어들기 때문에 나는 이 부분을 동료분들에게 계속 강요하면서 프로젝트를 진행했었다. 귀찮을 수도 있겠지만 이런 부분이 너무너무 중요하다는 걸 배웠다.

리팩토링

사실 이건 개발자의 역량문제일수도 있는데, 난 초반엔 사소한 부분들에 대해 선 크게 고려하지 않았다. 공통적인 부분은 나중에 수정하자~라고 생각하고 개발을 했었는데, 나중이 되니깐 수정할 시간이 없었다. 태스크는 산더미처럼 밀려있고 에러도 계속 들어왔다. 그러다 보니 공통적이어야 하는 부분들이 개발자마다 구현이 달라지니 프로젝트 전반적으로 완성도가 떨어지기도 했었고, 클라이언트분들도 이런 부분을 많이 집어주시고 좋지 않은 피드백도 많이 들었다. 이건 정말 나의 잘못이라고 생각한다ㅠㅜ!!

 

그래서 개발을 하다가 잠깐 짬이 나면 바로 코드정리를 했었다. 페이지가 70개 정도 되었는데, 정말.,. 페이지 하나하나 찾아다니면서 코드 정리하고 공통적으로 적용하기도 했다.

작은 단위의 코드 정리가 이 프로젝트를 진행하면서 도움이 많이 되었다. 후반으로 갈수록 코드도 점점 깔끔해지고 페이지마다 공통적이어야 하는 부분이 통일이 되니 점점 코드에 애착이 생기기도 했다.

 

최근에 읽은 책중에 tidy first라는 책이 있는데, 이 책에서도 말하는 게 리팩토링은 작은 단위로 진행을 해봐라는 것이다. 나는 작은 단위의 리팩토링이 쌓이고 쌓여서 전반적인 코드의 퀄리티가 개선되는 것을 경험을 했었기 때문에 너무 좋은 접근방법이라고 생각하고, 지금 회사에서도 조금씩 적용하고 있다!

결론

사실..... 1년 동안 정말 많이 힘들었다. 이 프로젝트를 하면서 힘들다는 감정이 제일 크긴 했는데, 어느 정도 멘탈이 회복되고 나서 생각을 해보니 사실 프로젝트 자체는 재미있었다. 단지 외주의 특성을 견디기 힘들었었던 것 같다. 야근과 시간압박 때문에 정말 힘들었지만 복잡한 화면을 만들면서 재미있긴 했다.

 

무엇보다 좋은 동료분들이 있어서 그래도 버틸 수 있었다. 힘들때마다 서로 농담도하고, 같이 야근도 하면서 내가 많이 의지했던것같다ㅠㅜ

좋은 동료가 최고의 복지라는말이 맞는것같다. 그들이 없었다면 나도 많이 무너졌을것이다.

 

글로 정리해보니 생각보다 많은걸 배웠구나 싶다.

다음 프로젝트가 끝나면 또 회고를 해봐야겠다.