[소프트웨어] 리팩토링을 대하는 자세

Overview

리팩토링은 소프트웨어 엔지니어라면 뗄 수 없는 업무입니다.
소프트웨어의 레거시를 하나씩 새로운 코드로 갈아 끼우거나, 쌓여있는 기술 부채를 청산하는 행위를 리팩토링이라고 합니다.
좋은 소프트웨어를 만들기 위해서는 반드시 리팩토링이 필요하고, 소프트웨어의 수명을 연장하기 위해서도 리팩토링이 필요합니다.
이번 포스팅에서는 리팩토링을 대하는 자세에 대한 생각을 남겨봅니다.
 
요 근래 회사에서 많은 리팩토링을 진행하고 있습니다.
보통 리팩토링을 한다면 작은 범위에서의 리팩토링을 진행하며 예측할 수 있는 범위 내에서 모듈 단위의 리팩토링을 생각하고는 합니다. 하지만 최근 제가 진행하고 있는 리팩토링은 프로덕트 프론트엔드의 수명을 연장하기 위해 진행하고 있는 리팩토링 입니다.
 

잠깐, 수명을 연장하는 리팩토링이 뭘까?

수명을 연장하는 리팩토링은 또 무엇일까요? 요즘의 프론트엔드는 다양한 라이브러리에 의존하고 있습니다. 자바스크립트 런타임 환경인 Node.js부터 React와 서드파티 라이브러리 등 프로젝트 내에서 다양한 라이브러리를 사용하고 있습니다.
가장 중요한 것은 소프트웨어 버전에는 EOL(End of Life)가 존재한다는 것 입니다. 

단편적인 예시로 Vite가 지원하지 않는 Node.js의 버전이 존재합니다. 만약 프로젝트에서 사용하는 소프트웨어의 버전 관리를 제때 하지 않는다면 기술 부채가 쌓이게 되어 청산하기 어려워질 수 있습니다. 이런 경우에 최신 환경으로 프로젝트를 새로 포팅해야 한다는 점에 더욱 많은 비용이 소모할 수 있습니다.

 
저의 사례를 살펴보겠습니다.
기존의 프로덕트 환경은 Node(14v), npm, Webpack4, React(16v), TypeScript(3v)를 사용하고 있었습니다. 물론 해당 버전들이 아주 레거시이다, 생명주기가 끝났다 라고는 볼 수 없습니다. 아직도 사용하고 계신 분들이 많을 것 이니깐요.
 
제품을 개발하다가 문득 불편함을 느꼈습니다. 저의 하드디스크 용량이 256GB인데 레포지토리 용량이 90G가 넘었기 때문입니다. 이를 살펴보니 Webpack4를 사용하면서 HMR되는 모듈을 모두 빌드하고 node_modules에 저장하고 있기 때문이였습니다. 또한 Webpack4의 특성 상 코드를 수정하면 HMR을 위해 재빌드를 하는데 이 과정에서 상당한 시간이 소요된다는 점이 있었습니다.
또 npm을 사용하며 팬텀 디팬던시와 디스크 효율성에 대한 불편함, 빌드와 의존성 설치 시간이 상당 시간 소요된다는 점이 눈에 띄게 불편하다는 생각을 했습니다.
 
이러한 불편함과 지금의 버전이 점점 최신 버전과 멀어져가고 있었고 개선 없이 계속 프로젝트를 진행하게 된다면, 앞으로 최신 환경에 익숙한 개발자분들이 합류 한다면 저희 프로젝트에 온보딩 하기 어려울 것이라고 생각했습니다.
 
결국 프로덕트 프론트엔드의 수명을 늘리기 위해서는 최신의 환경으로 마이그레이션 해야한다는 생각으로 대규모 리팩토링을 시작하게 됐습니다.
 

리팩토링을 대하는 자세

리팩토링을 대하는 자세가 따로 있을까요? 레거시라고 생각하는 모듈은 팀원들과 협의하여 그냥 개선하면 되지 않을까요?
물론 현재 진행중인 팀원들과 협의하에 리팩토링을 진행하는 것은 아주 중요한 자세라고 생각합니다. 하지만 제일 중요하다고 생각하는 점은 레거시에 대한 존중이라고 생각합니다.
 
프로젝트를 진행하다 레거시 코드를 보고 이거 왜 이렇게 만들었지? 라는 생각을 많이 해보셨을 것 이라고 생각합니다. 필자인 저도 레거시 코드를 보면 그런 생각도 들고, 심지어 제가 작성한 코드를 보고도 그런 생각이 들기 때문입니다. 하지만 그렇게 만든 것은 다 이유가 있었기 때문입니다.
 
소프트웨어 엔지니어는 항상 그 시점의 최선의 선택을 합니다. 여기서 중요한 점은 최고의 선택을 한다는 것이 아닌, 최선의 선택을 한다는 것 입니다. 누구나 보기 좋은 클린 코드 조금 더 깊게 고민해서 만드는 코드도 중요합니다. 하지만 조금 더 중요한 것은 기한을 지키며 문제를 해결할 수 있는 코드입니다.
 
가령 어떤 문제를 해결하기 위해 A, B의 선택지가 존재하며 A의 선택지가 최고의 해결책이라고 판단이 듭니다. 하지만 A를 선택하기 위해서는 러닝 커브가 발생하며 때에 따라서 의존성 문제가 발생할 수 있고 시간의 문제가 발생할 수 있습니다. 이럴때 경험 깊은 개발자는 B 선택지를 선택하고 기술 부채로 쌓아 놓습니다. 물론 청산을 한다는 가정하에 쌓아 놓습니다. 결국 기술 부채는 쌓이게 되고 레거시가 됩니다. 이런 선택에는 그 당시의 이유가 존재 했습니다.
 

레거시를 존중하기

그럼 왜 레거시를 존중해야 한다는 것 일까요?
만약 레거시를 무시하고 무작정 개선을 시작한다고 합시다. 그 개발자는 레거시를 무시하기 때문에 과거 히스토리 조차 무시하고 무작정 리팩토링을 시작합니다. 시간이 흐르고 개발자는 왜 그런 선택지를 선택했는지 이해하게 되고 결국 시간을 낭비하고 리팩토링을 진행했던 코드를 롤백하게 됩니다. 이런 방식은 팀의 비용을 소모하고 팀원과의 불화를 만들수도 있습니다.
 
당장 저의 사례를 말씀드려 보겠습니다.
이전에 리팩토링을 진행하던 당시 React 프로젝트의 src 디렉토리 하위에 jQuery 라이브러리 파일이 그대로 존재했습니다. 또한 React 프로젝트에서 jQuery를 사용하는 것이 이해가 안됐습니다.
저는 해당 아이템을 필히 개선해야하는 ACTION 아이템이라고 생각하고 jQuery를 걷어내기 위해 몰두 했습니다. 하지만 결과론적으로 jQuery 자체를 걷어내는 것에는 실패 했습니다. 프로젝트에서 사용중인 sdk 코드에서 jQuery를 사용하고 있었고 SDK 자체가 jQuery와 강하게 결합하고 있었기 떄문에 대체할 수 없었기 때문입니다.
결국 jQuery 자체를 걷어내기 보다는 jQuery 라이브러리 소스를 걷어내는 것이 집중 했습니다. jQuery 파일의 가장 최소 압축 파일을 public 폴더에 넣어놓고 script로 해당 파일을 읽었습니다. 그리고 jQuery 소스를 참조할 수 있게 하기 위해 window 객체에 jQuery를 주입했습니다. window 객체는 전역 객체이기 때문에 전역 스코프가 오염될 수 있다는 점이 있었지만 그 당시 제가 할 수 있는 최선의 선택이였습니다. 만약 제가 레거시를 존중하고 코드를 살펴봤다면 jQuery 자체를 걷어내기 위해 쏟았던 시간을 절약할 수 있었을 겁니다. 
 
결국 레거시를 존중하는 행위는 그때 당시의 히스토리를 이해할 수 있는 좋은 방법이고, 결국엔 시간과 비용을 절약할 수 있는 방법입니다.
 

내가 작성하는 코드도 결국엔 레거시가 된다

내가 지금 최선의 코드, 최고의 코드라고 생각하고 작성하고 있는 코드도 결국엔 레거시가 됩니다.
추후 다른 개발자가 프로젝트 코드를 살펴봤을때 만약 팀에 남아있다면 히스토리를 직접적으로 알려줄 수 있습니다. 하지만 만약 내가 퇴사하게 된다면 레거시 코드와 그 개발자 사이에는 아무런 연결 선이 존재하지 않습니다.
 
가급적 어떤 선택지를 선택한다면 히스토리를 남기는 것이 좋습니다. 작성한 코드는 되도록 분자 단위의 커밋으로 쪼개어 커밋 메세지를 잘 작성하거나, PR/MR을 올릴 경우 상세하게 어떤 작업을 했는지 기술하는 것이 좋습니다. Jira의 이슈나, Notion, Confluence, 팀의 드라이브 등 어떤 선택지가 될 수 있을것 같습니다. 나의 선택지, 미래의 레거시 코드와 그의 연결선을 남겨 놓는다면 인수인계 받은 개발자가 다시 한번 최선의 선택을 할 수 있지 않을까라는 생각입니다.
 
또 코드를 작성할 때 나의 코드가 직접적으로 비즈니스 로직을 머리속에 그려줄 수 있다면 가장 좋을 것 같습니다. 아주 추상화 된 영역의 코드라면 주석을 통해 해당 코드의 역할을 설명해주는 것도 좋은 방법일 것 같습니다.
 

마치며

이전에 리팩토링에 대한 좋은 번역글을 살펴보고 후기 글을 남겼습니다. 그 글에서 지양해야 할 점으로 큰 단위의 리팩토링을 이야기 했는데, 지금 제가 큰 단위의 리팩토링을 진행하고 있네요.😂

[소프트웨어] 리팩토링 글을 읽고

 
좋은 소프트웨어에는 항상 리팩토링이 따르고, 리팩토링을 진행하는 코드는 항상 그 당시의 최선의 선택이였습니다. 과거를 존중하고 미래로 나아가는 것은 좋은 자세인 것 같습니다.
 
온고지신 이라는 사자성어가 있습니다. 옛 것을 익히고 새 것을 안다는 것 입니다.
이번 포스팅에 아주 잘 어울리는 사자성어 인 것 같습니다.