[PROJECT] 두번째 프로젝트 리뷰

두번째 프로젝트를 하고서야 이 바닥을 알게 된 신입개발자

 

이번엔 두번째 프로젝트에 대한 이야기를 써볼까 한다. 내가 경력이 이제서야 1년이다보니 사실 상 이게 가장 최근 프로젝트고 끝난지도 얼마 안됐는데, 지금 써놓는게 담 플젝 하고 나서 다 까먹은 뒤에 엉엉 울며 쓰는거보단 낫다는 생각이 들어 일단 회고를 한번 해보려는거다.

 

2023.06.15 - [Dev/Project 수행기] - [PROJECT] 내 인생 첫 프로젝트 리뷰

[PROJECT] 내 인생 첫 프로젝트 리뷰

위의 링크를 보면 알겠지만 이 프로젝트는 내 첫프로젝트에 비해 상당히 난이도가 쉬웠다. 첫 프로젝트가 사실 말도 안되는거였긴함.

하여튼 이번에야말로 어이없는 상황 속에서 어이없이 굴러가는 프로젝트가 아니라, 진짜 제대로 Doc도 다 전달 받은 상태에서 리드개발자의 디렉션에 따라 차근차근 개발하는 거였는데, 진짜 하면서 아니 이렇게 행복할 수 있다고? 라는 생각이 들었다. 

 

직전 프로젝트은 레거시임에도 불구하고 테이블 정의서 하나 없어서 진짜 싹 다 DB 까뒤집고, 소스코드 한줄한줄 봐가면서 아 이게 이거하는거구나... 이렇게 개발했었는데 이번엔 아예 새로 만드는거 + 앱 구조나 이런건 나같은 팔로워들은 전혀 알 필요없고 내가 전담하고 있는 화면 컴포넌트랑 데이터 플로우만 잘 만들어주면 되는 거 였기 때문에 그냥 애초에 초석부터 행복 개발 시작이었던거임.

자 그럼 시작해보자.

 

1. 프로젝트의 개발환경
MSA인건 동일했는데, 개발팀 내부적으로 앱의 구조와 상태관리 라이브러리를 바꾸자는 논의가 나왔다. 기존 MSA 의 문제점을 해결하기 위한 것 이었는데, 기본적으로 이전엔 MS 개발 후 넥서스에 MS를 배포한 뒤 App에서 dependency로 추가하고 이걸 인스톨 해오는 방식이었다보니, MS 개발 후 빌드 + 배포, App 개발 후 빌드 + 배포 이런 식으로 일을 두 번 해야한다는 문제를 한번 해결해보고자 한 것 같다. 또, 상태관리 라이브러리의 경우 UI를 위한 상태들과 서버 발 Data 상태들이 복잡하게 얽혀있다보니, 유지보수의 효율성이 떨어져 React-Query와 Jotai의 조합으로 상태관리의 분리를 시도하자. 라는 의견으로 보였다. 
이렇게 기존에 사용하던 환경에서 새로운 환경으로의 전환이 이뤄졌다.

2. 나의 업무
처음에 받았던 업무의 경우엔 그냥 메뉴 하나 만들어주는 거였다. 그리드 두개 띄워두고, 한쪽에는 카테고리의 역할을 하는 요소, 한쪽에는 엘리먼트의 역할을 하는 요소를 띄워주고, 각 카테고리에 해당 요소들을 매핑 시켜주는 시스템이었는데, 그닥 어렵지 않은 내용이었고, 서비스 로직의 경우엔 대부분 리드개발자 분들이 개발해주는 케이스였던터라, 핵심이 되는 서비스 로직에 비하면 상당히 간단한 로직 정도만 구현하면 됐기 때문에 무난하게 개발해냈다. 그러다보니 개발이 더딘 파트의 개발을 일부 떼어와서 내가 하고, 앱 전체적으로 Custom Hook 사용과 Error Handling 가이드라인을 제시하는데 참여했다. 

3. 내가 마주했던 문제들
1) TypeScript 
이건 문제랄 것도 없지만 이 프로젝트의 경우에 내가 처음으로 TypeScript를 사용했다보니 Type에 대한 고민을 많이 하게 됐다. 물론 대부분 라이브러리를 통해 개발을 하다보니 관련 타입들은 해당 라이브러리 내부적으로 정의가 되어 있었던 터라 찾는 시간이 좀 들었을 뿐이지만, 그래도 Generic을 선언한다거나, Props에도 interface 를 통해 Type을 지정해준다던가  등등 TypeScript에 적응하는 시간이 좀 됐었던 것 같다.

2) React-Query 사용
조금 안타깝다라는 생각이 드는 문제였는데, React-Query에서 제공하고 있는 파워풀한 옵션들을 이 개발에선 다 끄고 사용했다. 내가 잘 몰라서 그런 것일지도 모르겠지만, React-Query의 사용자 경험 향상을 위한 옵션들이 이번 프로젝트 안에서는 오히려 방해가 되는 경우가 많았고 (대표적인 예시가 자동으로 데이터를 쿼리해온다거나 이런 것 없이 유저가 이벤트를 통해서 특정 시점에 데이터를 조회해와야 하는 기능이 많이 요구 됐기 때문에 refetch를 통제해야했음.) 그런 문제들을 해결하기 위해 default 로 제공하는 기능들을 모두 끄고 사용하는 방향으로 개발을 이어나갔다.

3) hook 사용 규칙에 대한 커뮤니케이션 부분 (협업에 대한 요소)
이건 커뮤니케이션에 조금 문제가 있었던 건데, Error Handling을 함에 있어서 hook의 규칙이 조금 위반되는 케이스가 있었다. 함수 안에서 hook을 선언한다거나 이런 기본적인 Hook 규칙에 위배되는 부분이 많았다. 근데 아무래도 신입 개발자들이 많은 편이라, 다  그게 잘못된지 모르고 사용하고 있었고, 그냥 해결책은 custom hook을 만들어서 사용하면 해결 할 수 있는 부분이었는데 좀 설득하는데 애를 먹었다. 이러이러해서 규칙에 어긋난다. 라고 얘기를 해야하니 당연히 공부를 해가서 사실과 근거를 바탕으로 설득을 해야했고, "별거 아닌데, 꼭 그래야해요?" 라는 질문이 있었어서 상당히 난감했다. 

 

회고 

아쉬웠던 점이 많은데, 아무래도 내가 처음부터 맡았던 부분에 대한 것들 보다는 전체적으로 이 프로젝트에 대한 룰을 정하는 것 중 다른 개발자들과 소통하는 부분에서 상당히 아쉬웠던 점이 많았다. 원래의 앱구조로 개발했더라면 MS별로 단절되어있기 때문에 이렇게나 소통할 이유도 없었던 거였는데, 아무래도 MonoRepo를 채용해 개발하다보니 동일한 프로젝트 안에서 개발하고 있단 점에서 서로 간의 의견 마찰이나 이런 부분도 많았고, 실제로 모든 개발자들이 선호하는 분야가 다른데 어쨌든 회사에서 시키는 파트를 하는거다보니, 각자 알고 있는 것들에 차이가 있어서 설득과 논의의 시간이 많이 필요하단 것을 알 수 있었다. 

 

또한, 기술적인 면에서는 새로운 상태관리 라이브러리를 사용한다고 해서 들떠있었으나, 이것을 제대로 알아보고 본래 기능들을 능숙하게 사용해볼 새도 없이 모든 옵션들을 끄고 사용했다보니 일하면서 공부도 할 수 있었다기보단, 너무 개발에 급급하지 않았나 라는 아쉬움이 있다.