코드 리팩토링을 되돌아 보며(시작)

어쩌다 시작하게 되었을까?

사내 Saas 프로젝트에서 MVP기능을 구현한지 얼마 안된 시점이었다. 새로운 팀장님께서 오신 후 가장 먼저 각 팀원들과 1대1 면담을 하며 현재 코드나 업무에서 개선이 필요한 사항을 파악해 나가셨다. 나는 평소에 말수가 많지 않지만 그날 만큼은 한풀이 하듯이 내가 생각하는 문제점들을 말씀드렸다. 팀장님께서 공감을 하셨고 나중에 꼭 리팩토링을 해야할 것 같다고 하셨다. 그 후 팀원들과 코딩 컨벤션에 대해 논의를 가지기 시작했다. 하지만 정해야할 내용이 생각보다 많고 다른 업무에 치어서 컨벤션에 대한 논의나 리팩토링은 저 먼 곳으로 잊혀저 가는 듯 했다. 하지만 팀내 업무를 새로 나누면서 내가 Saas 프로젝트의 주 담당자가 되었다. 그리고 Saas 프로젝트에서 MVP이외의 기능을 추가해야했다. 이에 나는 팀장님께 기술부채가 너무 쌓여 새로운 기능을 추가하기 어려워 우선 코드 리팩토링이 필요하다고 건의드렸고 팀장님께서 받아주셨다. 새로운 기능 개발 전 1.5주 동안 리팩토링을 진행하기로 하였다.

무엇을 개선하였나?

1. 디렉토리 구조
   기존 디렉토리 구조는 단조로웠다. 프로젝트에서 동일한 기능을 하는 파일들을 한 디렉토리에서 관리하였다. 예를 들면 프로젝트 내에서 api request에 사용되는 axios 파일들은 모두 api 폴더 내에서 관리했다. 물론 기능별로 나누기는 했지만 프로젝트의 기능이 추가되면 될 수록 파일을 찾기가 힘들었다. 그리고 컴포넌트들은 atomic 구조로 분리하여 관리했다. molecules, cell, species 등등.. 그런데 경계가 참 모호하였다. 개인의 의견이 반영되는 구조이기에 헷갈리는 부분이 있었다. molecule을 포함하여 cell에 두어야 하는데 cell이라고 하기에는 기능이 너무 무거운 컴포넌트들이 있었다. 이런 모호함이 쌓여 일관성을 해치고 이는 유지보수의 비용증가로 이어졌다.

2. 파일, 변수명 통일
   5명의 팀원들이 사전 협의 없이 코드를 작성하다 보니 개인의 스타일이 잘 드러났다. 변수명이나 파일명등 여러 부분에서 통일성이 부족했다. 리팩토링을 하며 왜 구성원들과 컨벤션을 합의하고 지켜나가는지 깨달았다. 우선 파일이름이나 변수명을 봐도 어떤 기능을 하는 파일, 함수, 변수인지 파악하기가 힘들었다. 그래서 코드 한줄 한줄 읽으며 "아, 이런 기능을 하는 함수구나"를 반복해야했다. 모든 변수와 파일명을 통일하기는 어렵지만 그래도 반복되는 부분은 통일시키려 노력했다.

3. 사용자 입력 컴포넌트 개선
   서비스 내에서 사용자의 입력을 받는 페이지는 정말 많다. 프런트엔드 페이지는 사용자와 데이터를 주고받아야 하는데 사용자가 원하는 데이터를 받는 방식이 사용자 입력 컴포넌트 이기 때문이다. 하지만 아무렇게나 받을 수 없기 때문에 컴포넌트 내에서 사용자 입력 로직이 점차 거대해졌다. 그리고 이러한 로직 구현을 위한 부수적인 state들과 useEffect들이 점점 늘어났다. 하지만 useEffect와 여러 state들의 상호관계로 코드는 점점 파악하기 힘들고 버그들이 늘어났다. 그래서 useReducer와 forwardRef를 통해 사용자 입력 로직을 외부 함수로 분리하여 컴포넌트 내 코드를 단순화 하였다. 그리고 기존에는 form태그를 사용하지 않았지만 form 태그를 사용하는 방향으로 코드를 변경하였다.(이전에는 Form 태그를 사용하지 않아 엔터 입력을 keydown eventlistener를 통해 구현하였다.)

4. 전역 상태관리
   이전에는 redux toolkit을 통해 전역 상태관리를 하였다. 화면의 레이아웃을 결정하는 단순한 상태들도 있었고 db의 데이터를 나타내는 상태들도 있었다. 이러한 상태를 설정할 때는 try catch문 안에서 api response를 dispatch 시켰다. 하지만 리팩토링을 위해 자료를 조사해보니 대부분 회사들에서 redux saga나 useQuery를 통해 전역 상태를 관리하였다. 사실 처음 자료를 찾아볼 때는 왜 굳이 문법이 어려운 redux saga나 학습이 더 필요한 useQuery를 사용하는지 이해가 안갔다. 하지만 아래 블로그를 보고 왜 위 두가지 방법들을 채택했는지 조금 공감이 갔다.

   https://min9nim.vercel.app/2020-04-23-redux-saga/

   하지만 redux-saga나 useQuery를 새로 익히며 적용하기에는 시간이 부족했다. 그래서 좀 더 찾아보니 redux-toolkit에 기본적으로 redux-thunk를 지원한다는 것을 알았다. 그래서 학습 비용이 적고 사용이 간단한 redux-thunk를 사용하여 비즈니스 로직을 컴포넌트에서 분리하였다.
   

5. 라우터 구조 변경
   리팩토링 진행 전에는 레이아웃을 공유하는 페이지들의 라우터 구조가 상이하여 같은 레이아웃이지만 다른 파일들로 관리하였다. 이러한 비효율성을 개선하기 위해 라우터 구조를 새로 짜고 react-router-dom 버전을 6.4로 적용하려 했다. 하지만 prompt(페이지 이탈방지)기능 때문에 다시 6.3으로 원복하고 말았다. 그래도 하나의 레이아웃을 여러 페이지가 공유하면서 파일의 개수나 코드의 양을 줄이려 했다.

느낀점

약 1.5주간 정말 리팩토링만 했다. 나의 개인시간까지 모두 투자할 정도로 리팩토링에 대한 의지가 강했다. 사실 이렇게까지 하지 않아도 괜찮았을 것 같지만 내 욕심이 컸다. 그간 공부했던 내용들을 현업에 적용해 볼 수 있는 좋은 기회라 생각했기 때문이다. 그리고 통일성과 규칙, 아키텍처구조를 왜 잘 설정해두고 프로젝트를 시작해야 하는지 몸으로 느끼게 되었다. 그리고 1.5주동안 코드를 고쳤지만 아직도 부족한 부분이 너무 많다.

위에 작성한 5가지 말고도 많은 부분을 변경했다. 그래서 우선 5가지를 각각의 글에 자세하게 적고 소소한 부분들을 한 글에 모아서 작성해 보려고 한다. 글을 적으며 앞으로 내가 더 공부해야 하고 다듬어야 하는 부분을 알 수 있을 것 같다.