MVP 개발을 돌아보며

Gn0lee·2022년 9월 13일
1

Tech 이모저모

목록 보기
5/18

회고의 순간

내가 처음 입사한지 3개월이 넘어갔다. 약 3개월 동안 새로운 Saas 서비스를 쉼없이 만들어 왔다. 현재는 버그들을 잡거나 디자인이나 기능 변경이 되면 그에 따라 수정하고 있다. 아직 결재 기능을 위한 심사가 진행되고 있어 따로 기능을 구현할 일이 없다. 잠시 쉬어가는 기간같기도 하다. 그래서 이럴때가 지난 3개월을 돌아보고 코드를 개선할 수 있는 절호의 기회라 생각한다. 때마침 우리팀에 드디어 팀장님이 합류하셨다. 팀장님의 첫 미션은 회사 제품과 우리가 구현한 코드를 이해하고 그것을 개선하는 것이라 하셨다. 항상 업무하면서도 동아리 수준의 내 코드가 부끄러웠는데 무언가 고칠 기회가 생긴것 같아 안도했다.

무엇을 고쳐야 하는가?

지난주 팀장님과 그동안 내가 한 업무와 앞으로 개선하고 싶은 부분을 이야기 했다. 30분이면 충분할 줄 알았는데 이야기하다보니 1시간 30분이 지났다. 처음 내가 한 업무를 말씀드리려 했을 때 뭔가 정리가 잘 되지 않았다. 무언가 정말 많이 했는데 말로 표현이 잘 안되었다. 그래도 나름 정리해서 말씀 드리고 앞으로 개선해야 할 점에 대해서 말씀드릴 때 말문이 트인 것 같았다. 아무래도 그동안 답답한 점이 튀어나온 것 같았다. 개선할 점을 모아보면 대부분 팀원간 합의가 구체적으로 이루어지지 않아 각자의 개성이 너무 드러나서인 것 같다. 이래서 서로 많이 이야기하며 방향을 맞춰 나가는 것이 중요하다는 것을 한번 또 깨달았다.

코딩 컨벤션

FE팀에서 진행되고 있는 여러 프로젝트가 있는데 프로젝트간 코딩 스타일이 너무 다르다. 그리고 내가 맡은 Saas 프로젝트는 3명이 담당해서 프로젝트 안에서도 통일성이 부족했다. 예를들면 import 방식, 파일 이름, 변수 이름, 에러 핸들링 방법, 사용하는 라이브러리(예를 들면 나는 axios를 주로 사용하는데 다른 팀원은 usequery를 사용하고 있다.)등이 프로젝트마다, 파일마다 매우 달랐다. 그리고 FE팀은 atomic 기반으로 컴포넌트를 나누고 있는데 기준이 애매해서 같은 단계안에서도 컴포넌트의 성격이 너무 다랐다. 같은 Molecule인데 molecule답지 않게 너무 비대한 컴포넌트들이 많았다. 이런 부분들은 애매하게 정해진 룰안에서 각자의 해석이 더해져 만들어진 결과물 같았다. 현재 eslint도 가장 기본만 설정되어 있어 airbnb를 적용하여 코딩 컨벤션을 최대한 맞춰 나갈 예정이다.

개발 환경 관리(라이브러리, 버전..)

현재 모든 프로젝트에서 상태관리는 useState와 redux를 사용하고 있다. 그렇다면 왜 redux를 사용하는가?에 대한 답변은 그리 시원하지 않다. 당시 전역 상태관리가 필요했는데 관련된 라이브러리를 경험해 본건 나를 포함해 세명이었다. 그리고 그 세명은 모두 redux만 사용해봤다. recoil이나 새로 만들어진 라이브러리들을 사용해 보기엔 시간적 여유가 없었다. 그리고 현재 react 18 버전을 사용하고 있다. 이유는 딱히 없다. 그래서 패키지 설치 시 엄청난 경고문구가 뜬다. 그리고 eslint 경고문구도 엄청 많다. 나는 내가 작성한 코드에서는 eslint 경고 문구가 없게 끔 설정하고 있는데 여전히 많다. 이렇게 사용중인 라이브러리에 대한 명확한 이유가 없어 논의가 필요하며 경고문구는 제발 해결했으면 좋겠다.

Git 관리 방식

현재 Saas프로젝트는 develop, QA, prod 세가지 브랜치로 관리한다. 그리고 각 브랜치들은 다른 도메인에 배포되어있으며 jenkins로 자동화 작업을 마쳤다. 하지만 다른 팀원분들이 develop을 통해 버그를 알려주시고 우리는 develop에서 수정하고 있다. 힘겹게 자동화 작업을 했는데 매우 슬픈 부분이다. 그리고 한 이슈에 대해 브랜치를 만들 때 어느정도 구현을 해야하는지 애매했다. 기능 도중에 병합을 시키는 경우도 꽤 있었다. BE작업을 기다리기 애매한 경우도 있었고 기능이 너무 많아서 중간에 병합을 해야겠다고 생각했기 때문이었다. 하지만 이제는 자동화가 이루어지고 있기 때문에 기능개발이 덜 된채로 배포되어 팀내 합의가 필요할 것 같다.

정리한 이유

이러한 점 말고도 고쳐야 할 것은 매우 많다. 블로그에 이렇게 정리한 이유는 사이드 프로젝트나 다른 업무에서 충분히 마주칠 수 있는 문제들이며 항상 생각해야하는 부분들이라 생각했기 때문이다. 팀원간 소통도 중요하지만 일단 내가 해당 내용을 잘 알아야 어떤 것을 맞춰야 하는지 아는 것 같다. 결국 나의 공부가 필요하다..🥲

profile
정보보다는 경험을 공유하는 테크 블로그입니다.

0개의 댓글