[React] 가상화폐 자동거래 프로젝트 리팩토링하기(1/2)

학부 시절 소프트웨어 공학에서 리팩토링을 배우고 난 뒤, 리팩토링이 매우 중요한 과정 중 하나라는 것을 항상 생각하고 다녔다. 동아리 후배들과 얘기를 할 상황이 생기면 언제나 '여러분 리팩토링은 중요해요 !'라고 말하곤 했다.

그런데 돌아보면 정작 나는 리팩토링을 하고 있지 않았다. 논문을 써야하네 어쩌네 이런 변명들을 앞세워서 정작 중요하다고 말한 리팩토링을 단 한 번도 해본적이 없다는 것을 깨달았다. 마침 최근 회고한 프로젝트에 리팩토링할 것들이 산재되어 있었기 때문에, 작더라도 리팩토링을 진행하고 그 과정을 기록으로 남겨보려고 한다.

가상화폐 자동거래 프로젝트 회고

리팩토링(Refactoring)이란?

글의 시작부터 리팩토링을 계속해서 외쳤는데 대체 리팩토링은 무엇인지에 대해서 정리하는 시간을 가졌다. 미국의 소프트웨어 공학자이신 마틴 파울러(Martin Fowler)님은 저서인 리팩토링(Refactoring)에서 리팩토링을 다음과 같이 정의하고 있다.

 

Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.[1]

 

리팩토링이란 "결과의 변경 없이 코드 내부의 구조를 재구조하는 기술" 정도로 해석할 수 있는 말이다. 우리가 작성한 코드가 수행하는 결과는 유지하되 작성한 코드 내부의 구조를 바꾸는 것 행위를 리팩토링이라고 한다는 것이다. 주의해야 할 점은 리팩토링은 버그를 고치거나 새로운 기능을 추가하는 작업은 포함하지 않는다는점이다. 정의 그대로 내부의 구조 또는 논리를 개선하는 작업인 것이다.

그렇다면 왜 우리는 리팩토링을 해야 하는 것일까 ? 여러 이유가 있겠지만 가장 대표적인 이유를 꼽자면 역시 코드의 가독성과 유지보수성을 개선하기 위해서이다. 코드의 가독성과 유지보수성은 일정 수준의 연관성을 갖고 있다. 코드의 가독성이 좋다는 뜻은 코드가 실행되는 과정을 쉽게 이해할 수 있다는 것이고, 이는 추후 문제가 발생했을 때, 또는 새로운 기능을 추가해야 할 때 개발자가 빠르게 코드 내에서 해당 부분을 찾을 수 있다는 것이다.

코드를 작성하는 동안은 요구사항에 맞는 기능을 빠르게 개발하는데 초점이 맞춰지다 보니 가독성과 유지보수성과 같은 부분까지는 고려하기 어렵기 마련이다. 작은 범위 내에서야 괜찮겠지만 이런 것들이 쌓이고 쌓여 큰 규모가 되었을 때는 문제가 발생하였을 때 매우 난감할 가능성이 높다. 리팩토링은 개발 과정에서 단순 기능 구현이 아닌 그 이후의 과정까지 생각한 일종의 예방책이라고 할 수 있다.

 

이렇게 봐서는 꽤나 거창할 작업일 것 같지만 사실 작은 부분에서 이루어지는 행위들도 디테일하게 따지자면 리팩토링으로 볼 수 있는 것이다. 예를 들어, 나이를 저장하는 a라는 이름의 변수를 의미가 있는 이름인 age라고 바꾸는 것과 같이 말이다.

지금부터 진행했던 가상화폐 자동거래 프로젝트에서 진행한 작은 리팩토링들을 하나씩 기록해보겠다.

컴포넌트 모듈화 방식의 변경

첫 번째로 진행한 것은 컴포넌트 모듈화 방식의 변경이다. 리액트는 여러 컴포넌트들로 분할되어 관리된다. 하나의 페이지를 구성한다면 해당 페이지를 여러 작은 단위로 나누어 컴포넌트로 만들어 합치는 방식으로 코드를 작성한다.

페이지를 구성하는 컴포넌트가 많아진다면 일일히 페이지에 해당하는 컴포넌트들을 모두 import 해서 사용해야 한다. 적은 수의 컴포넌트라면 상관없지만 구성하고 있는 컴포넌트가 매우 많다면 코드에서 컴포넌트를 import 하는 구문이 너무 길어지게 된다.

 

리팩토링 전과 후

 

그림의 Before와 같은 형태로 기존 작업에서는 사용하는 컴포넌트의 경로를 나누어 작성하였고, 이를 실제 사용하는 곳에서 import 해서 사용하였다. 동일한 Pages 경로에 존재하는 3개의 컴포넌트를 각각 import해서 사용하였다. 문제가 있지는 않다. 정상적으로 작성한 컴포넌트가 잘 import 되어 사용할 수 있다. 하지만 만약 컴포넌트가 매우 많은 상황을 가정해보면 이는 리팩토링이 필요한 부분이라고 생각할 수 있다. 만약 10,000개의 컴포넌트가 있다면 컴포넌트 삽입 구문만 10,000줄이 되어야 한다. 만약 내가 이 코드를 수정해야 하는 업무를 맡게 되어서 코드를 열었는데 처음 10,000줄이 컴포넌트 10,000개가 import 된 구문이라면 ? 깊은 한숨이 먼저 나올 것 같다.

 

그래서 다른 사람들은 어떻게 처리하는지 찾아보았다. 주로 index.ts를 작성해서 경로 내의 컴포넌트를 한 번에 export 하는 방법을 많이 사용하고 있어서 이 방법을 적용해보았다. 컴포넌트들이 저장된 Pages 경로 내에 index.ts 파일을 생성하고 아래와 같이 작성하였다.

 

Pages/index.ts

 

단순하다. 그저 기존 Before에서 사용되는 구문을 index.ts로 옮기고, 이렇게 옮긴 컴포넌트들을 index.ts에서 export 하도록 선언해주면 된다. 이를 통해서 기존의 3줄을 차지하던 import 구문을 한 줄로 옮길 수 있었다. 이 작업을 필요한 부분들에 대해 모두 적용해주었다.

 

이런 간단한 리팩토링 작업을 통해 2가지를 얻을 수 있었다.

1. 코드의 크기를 줄일 수 있다. 성능 등에 미치는 영향이 있는 것은 아니지만 코드 내에서 크게 중요하지 않은 부분의 크기를 줄일 수 있다는 것인 꽤 의미있는 작업이라고 생각한다.
2. 사용되는 컴포넌트를 수정하기 위해서는 어떤 경로를 조회해야 하는지에 대한 정보를 새롭게 작성한 한 줄로 알 수 있다. 만약, 이 3개의 컴포넌트들을 수정해야 한다면 나는 Pages 경로에 들어가서 index.ts를 살펴보게 될 것이다. 그렇다면 index.ts에서는 내가 수정해야 할 컴포넌트들은 어디에 있는지 위치를 확인할 수 있을 것이다. 소개한 과정에는 하나의 폴더밖에 없어서 "굳이 이렇게까지 해야하나? 그냥 봐도 알 수 있는 것 아닌가?" 라는 생각이 들 수도 있지만 컴포넌트가 보다 더 세분화되고 여러 경로에 나눠져있는 프로젝트에 대해서는 이 방법이 효과가 있을 것이라고 생각한다.

 

지금은 비록 프로젝트의 규모가 작아 스스로도 '이걸 리팩토링이라고 말해도 되나?'라는 생각이 들 정도의 작고 간단한 작업이었다. 하지만 이런 연습은 결국 언젠가 진행하게 될 큰 규모의 프로젝트에서 유용하게 사용될 수 있는 경험이 될 거라고 생각한다. 생각나는, 할 수 있는 작은 것들부터 하나씩 좋게 만드는 연습을 앞으로도 할 것이다.

---

출처

[1] 마틴 파울러 홈페이지 : Refactoring.com