utils는 해롭다

어떤 코드가 어디 파일과 디렉토리에 위치하느냐가 프로그램의 단단함을 결정지을 때가 있다. 제 위치에 있는 모듈과 함수들은 잘 맞물린 톱니바퀴처럼 프로그램을 부드럽게 동작시킨다. 각 파일이 프로그램의 구성하는 모듈처럼 명확하고 표현력있는 이름과 코드 구성을 가질 때 우리는 이해하기 쉬우면서 고치기도 쉬운 어플리케이션을 만들 수 있다.

때때로 우리가 숨쉬듯이 사용하지만 그 위험성에 대해 간과하는 것은 utils에 있다고 생각한다. 보통 utils라는 이름을 많이 쓰는데 utility, common, lib, helpers 등등 다른 이름이 될 수도 있다. 이름에 따른 미묘한 차이가 있지만, 공통적인 로직 혹은 분리가 필요한 로직들을 담는데 사용되고 있는 것 같다.

utils는 무엇을 위해 존재하는 걸까? 사실 utility라는 목적성은 모호하다. 모든 함수가, 모듈이 제각기 어느정도의 기능성을 담고 있기 때문이다. 어플리케이션 내의 역할로 본다면, 분명 유틸리티라는 역할이 있기 마련이다. 조그만 스위스 군용 나이프 같은 그런 기능들. 그러나 우리가 실제로 담는 유틸리티는 무엇일까? 유틸리티라는 역할은 쉽게 오해를 사게 된다. 우리는 개발하다보면은 조그마한 기능성을 가진 함수들을 모두 다 유틸리티로 여기고는 한다.

하지만 utils는 아주 매력적인 선택지기도 하다. 나도 개인적으로 작성하는 코드에서는 utils를 쓰게 된다. 분명 어딘가에는 속하지 않는데, 곳곳에서 꼭 쓰게되는 작은 함수들이 몇몇 생기기 마련이다. 그러다보면 utils는 비대해진다. 어디서 쓰이는 지, 어떻게 쓰이는 지 명확하지 않은 함수들이 중복 구현되기도 하고, 곳곳에 쌓이게 된다.

그런 함수들이 좀 쌓일 수도 있지.라고 생각할 수도 있다. 그러나 우리가 지향하는 건 이런 게 아니다. 함수들이 자신을 필요로 하는 위치에 있고, 알아볼 수 있는 명확한 이름과 네임스페이스를 가지는 것. 이것이 바로 아키텍쳐를 존중하고 구조를 추구하는 이유다.

나도 utils라는 디렉토리를 만드는 것을 좋아했으나 점점 만연해지는 코드 분리와 각 모듈마다 쌓여가는 utils 디렉토리 혹은 파일들이 많아지는 걸 보고 아차 싶어질 때가 많다. 다른 회사에 다니시는 개발자분과 이것에 대해 이야기했는데, 그 분은 회사 내 utils에 관한 명확한 규칙이 존재했고, 잘 관리되는 걸로 보였다.

1. 레포지토리 전체에 하나의 utils만 존재한다.

2. 둘 이상의 명확한 사용 사례가 있는 경우에만 utils로 분류될 수 있다.

꼭 이 룰을 따를 필요는 없지만, utils에 대한 간단하면서도 명확한 기준이 좋은 코드 구조를 만들 수 있는 것 같다. 그렇지 못하다면 utils는 해롭다.