개발자 회고, 프로젝트 회고 | 2023년 1월 회고

2022년 12월 ~2023년 1월 - L○전자 PDM 프로젝트

    빗○ N○○ 프로젝트 종료 후 두 달간 임시로 투입된 프로젝트였다. 해당 프로젝트에서 리액트를 잘 안 써본 사람들이 리액트를 배우면서 프로젝트를 하다보니 어려움이 많아 프론트엔드 지원을 나갔다. 전형적인 SI 프로젝트여서 협력사 분들도 많았고, 나잇대가 굉장히 높았다. 처음부터 리액트를 많이 써본 사람이 프로젝트 구성을 잡은 게 아니라 구조 자체가 굉장히 복잡했다. (폴더구조는 아마도 인터넷강의나 책에 나오는 폴더구조를 그대로 사용한듯 했다.) useMemo, useCallback을 부적절하게 남발하여 의도대로 코드가 동작하지 않은 부분이 많았다. 개발 할 때 가장 어려웠던 점은 파일명과 함수명이 아주 평범한 이름으로 통일되어있고, 폴더로만 그 쓰임새가 구분되어 코드를 쫓아가기 힘들었던 점이다. 수십 개의 파일명이 다 index.tsx, Container.tsx 등이었다. 
 
    이미 상당히 프로젝트가 진행된 상황에서 내가 할 수 있는 건 구조를 뜯어 고치기보단 기존 소스를 다듬고 신규 기능을 추가하는 일이었다. 공통화되지 못하고 ctrl + C, ctrl + V 로 쓸데없는 코드까지 복제되어있던 부분을 조금씩 다듬고 공통화시키며 개발을 진행했다.
 
    또 다른 어려운 점이 있었다면, git 브랜치 전략이 전혀 없다는 점이었다. 개발자가 40-50명정도 되는데 아무도 브랜치를 따지 않고 모두가 develop브랜치에 푸쉬를 했다. 실시간으로 푸쉬되니, 내가 푸쉬하려고 푸쉬버튼을 누르면 최신소스를 pull 받으라고 알림이 뜨고, pull 받고 다시 push 하려고 하면 또 pull 받으라고 뜨고... 결국 점심시간 등 한가한 시간에 push를 해야 그나마 소스를 올릴 수 있었다. git을 제대로 사용하는 법을 전파하기 위해 우리 센터에서 세미나도 하고 교육도 열었지만, 다들 "왜 굳이 복잡하게 그렇게 브랜치를 따고 컨플릭트를 해소하고 머지를 하는지" 전혀 이해하지 못하고 공감하지 못했다고 한다. 써보기 전까지 그 편리함을 알 수 없는게 맞지... 이런식으로 Git을 쓸거면 차라리 svn을 쓰는게 훨씬 낫다고 생각했다. 
 
    대신 위와 같은 어려움 속에서 소스트리의 다양한 기능을 익히게 되었다. 모두가 권한의 제한 없이 소스를 올리다보니 에러가 있는 코드, 버그가 있는 코드를 마구잡이로 올렸다. 그러다보니 언게부터 이 버그가 생겼는지 트래킹을 해야할 때가 많았다. 커밋 id별로 체크아웃 받아서 돌려보고, 체리픽도 해보고 tag도 써보고 하는 기회가 되었다. 혹자는 git cli를  쓰는 게 멋지다고 생각하겠지만 그건 너무나 단편적인 기능만 사용하기 때문일거라 확신한다. 큰 프로젝트에서 수많은 개발자와 개발하다보면 툴이 괜히 생긴게 아니라는걸 깨달을 수 있다. 
 
    이번 프로젝트에서 느낀 것은 아무리 좋은 것도 쓰는 사람이 준비되지 않으면 오히려 해가 된다는 것이었다. 준비되지 않은 상태에서 리액트를 도입하고, 리액트 중에서 리덕스가 가장 유명하니 리덕스를 도입하고.. 쓰임을 잘 모르지만 좋다고 하니 useCallback을 아무데나 넣어두고.. 요새 누가 svn 쓰냐고 git은 써야지! 하고 도입은 했지만 git 브랜치전략에는 공감하지 못하고. 그로써나오는 비효율은 프로젝트의 비용으로 고스란히 반영되었다. 신기술도 중요하지만 인건비가 높은 이 시대인만큼 더 배우기 쉽고 적용하기 쉬운 프레임워크를 채택하고, 무엇이든 일단 받아들여볼 자세가 되어있는 구성원으로 프로젝트인원을 구성하는 것이 성공하는 프로젝트를 위해 가장 우선해서 고려되어야할 점이라 생각한다.
 
    애초에 두 달만 지원하기로 한 프로젝트였지만 어찌저찌한 이유로 투입기간 연장이 되었는데... 나는 2월에 안식휴가를 가게 되어서 무사히 해당 프로젝트에서 탈출(?)할 수 있었다.

 아무것도 없는 공간에 테이블만 있는 아주 널찍한 사무실 그리고 매우 좁았던 책상....

화장실이 바깥에 있는게 너무 싫었다. 궁뎅이 시려워...