타입스크립트, 리액트쿼리 도입

파트너스 레거시 코드 리팩토링(1)

안녕하세요, 플랫폼 개발팀 프론트엔드 개발자 제리입니다.

 오늘은 자사 서비스 중, 카카오헤어샵에 입점한 점주분들의 매장관리 웹사이트인 "파트너스 서비스"의 리팩토링을 진행한 이야기를 소개하려 합니다.

 

리팩토링의 필요성을 합의하기

레거시 코드를 꼭 리팩토링 해야하는 것은 아닙니다. 프로젝트의 규모가 커질수록, 복잡해지는 dependency 때문에 라이브러리와 코어 프레임워크의 버전 관리가 어려워지고, 레거시 코드는 필연적으로 존재하게 됩니다.

리팩토링은 효율성을 위한 것이다. 즉, 개발자의 편의를 위한 것이므로, 요구사항을 해결하는 데 걸리는 시간이 지저분한 코드 때문에 걸리는 시간이 더 많이 소모되어야 리팩토링이 의미가 있는 것이다.
- Clean Code ( 로버트 마틴)

하지만 필요한 시기에 리팩토링이 되지 않은 프로젝트는 지속적으로 성장하고 발전하는 서비스가 될 수 없습니다. 오래되어 버전의 안정성이 보장되지 않는 라이브러리나, 결합도가 너무 높아 수정 시에 어디서 에러가 터질지 모르는 코드를 손대고 싶어 하는 개발자는 없습니다. 따라서 리팩토링은 투자 대비의 효용성이 예상되는 프로젝트에 대해 시간적, 인원적 자원이 확보된 상황에서 충분한 논의를 거쳐 그 필요성을 합의해야 합니다. 

 저희 팀은, 파트너스 페이지의 리브랜딩과 기능 확장 및 개편을 앞둔 상황, 그리고 비용(시스템 운영), 인원 등의 개발 리소스가 충분하다고 판단하여 파트너스 페이지 리팩토링 진행에 대해 합의하였습니다.
 

리팩토링의 범위와 내용을 정하기

 기존에 있던 프로젝트 전체를 리팩토링 하는 것은 아주 긴 시간이 소요될 것입니다. 따라서 저희 팀은 리브랜딩과 기능 개편 시에 작업될 페이지에 대해 리팩토링 범위를 선정했고, 차후 작성될 코드가 새로 도입된 버전의 기술스택으로 작성될 수 있도록 환경을 구성하는 것을 목표로 정하였습니다. 그리고 다음과 같은 장점을 기대하며  Typescript와 React-query  그리고 함수형 컴포넌트를 도입하기로 결정하였습니다.

- Typescript 도입으로 휴먼에러를 줄이고, 우리의 의도대로 작동하는 예측가능한 코드 작성을 위해.

- React-query 도입으로 코드 가독성을 간결하게 하고, 서버 사이드의 데이터를 효율적으로 관리하기 위해

- 클래스형 컴포넌트 -> 함수형 컴포넌트로 전환을 통해 직관적인 코드 스타일로 개선.

리팩토링을 통해 얻게 된 것들

프론트 코드의 컨벤션 확립

  팀 내의 프론트 코드 컨벤션을 잡아나갈 수 있었습니다. 파트너스 페이지에는 린트 에러가 산재해 있었습니다. ESLint는 같은 프로젝트를 작업하는 팀원들 간의 코드스타일에 대한 규칙을 잡아줍니다. 이러한 린트 Rule을 팀원들과 함께 수정하고 합의하는 과정을 통해 자연스럽게 프론트 팀의 코드 컨벤션을 정립할 수 있었습니다. 추가적으로 저희 팀만의 import order Rule을 설정하여, 팀 내의 누가 작성하더라도 같은 순서로 import문이 정리되어 통일성 있는 코드를 구성할 수 있게 되었습니다. 

새로운 기술에 대한 토의와 탐구

새로 도입하는 기술에 대해 팀원들과 많은 이야기를 나눌 수 있었습니다. 어떤 방식이 좋을지에 대한 충분한 탐구와 토의가 진행되며 자연스럽게 같이 공부를 할 수 있었고, 다양한 의견을 주고받으며 개발자로서 성장하는 기분을 느낄 수 있었습니다. 특히 리액트 쿼리를 도입하며, 파일 구조, 변수명, 호출 기본 옵션, 데이터/에러 처리 등에 대해 함께 고민하는 시간을 통해 리액트 쿼리에 대한 깊은 이해를 할 수 있었을 뿐 아니라 팀워크를 북돋는 계기가 되기도 하였습니다. 이에 대한 자세한 내용은 추후 포스팅하겠습니다.

개발 효율성 향상 및 안정적인 서비스 구성

리팩토링 이후 적용된 typescript로 컴파일 단계에서 사전에 에러를 잡아낼 수 있게 되었고, 오타 같은 휴먼에러를 줄일 수 있게 되었습니다. 그리고 node버전 업그레이드를 통해 안정적인 서비스를 보장할 수 있게 되었습니다.

 리액트 쿼리를 도입하고 난 후, 단지 데이터를 가져오고 상태를 관리하기 위해 작성되었던 수많은 코드가 사라지며 선언부가 깔끔해졌고, 코드의 가독성이 좋아졌습니다. useEffect를 이용하여 데이터를 가져오는 로직도 삭제되어 예상밖의 Side effect를 줄이도록 개선되었습니다.

리팩토링을 마치며

리팩토링을 시작할 때, 새로운 기술을 도입하는 것에 대한 막연한 두려움이 있었습니다. 기존에 작동되던 기능에 이상이 생길까 봐, 버전끼리의 peer dependency가 맞지 않을까 봐 걱정했었고, 실제로 리팩토링 간에 그 이슈들을 마주했습니다. 하지만 팀원들과 함께 고민하고 여러 시도를 해보며 이슈들을 헤쳐나갔습니다. 한 번에 완벽한 마이그레이션을 할 순 없다고 생각합니다. 따라서 만약 리팩토링을 진행하신다면 예상되는 이슈에 대응하는 기간까지 꼭 일정에 산정하시길 바랍니다. 지속적으로 발전하고 성장하는 서비스를 위해 리팩토링이 필요한 시기를 꼭 놓치지 마세요!