바퀴를 다시 발명하지 마라

이 이야기는 소프트웨어의 오랜 격언이고, 매우 좋은 말입니다. 미리 만들어진 바퀴는 일반적으로 더 견고하며, 시간을 절약해주고, 문서화도 잘 되어 있으며 다른 사람들도 해당 바퀴의 사용법을 알기에 인수인계하기도 좋습니다.

하지만 어떤 이유에서인지 종종 이 말은 의도보다 더 큰 영향을 미치는 것 같습니다. 분명 바퀴를 재발명하지 말라고 했는데 - 다른 사람이 만든 바퀴에 올라탄다거나 맞지도 않는 바퀴를 억지로 끼워맞추다가 고장나는 상황이 자주 발생합니다.

라이브러리, 프레임워크, 메타프레임워크

일반적으로 라이브러리, 프레임워크, 메타프레임워크 순으로 무게감이 있는 느낌을 보이지만 사실 이 셋을 구분하는 건 어렵습니다. react 는 라이브러리이지만 react 를 이용하다 보면 react 가 원하는 대로 코드를 구현하게 되기 때문에 프레임워크라고 불리기도 합니다. next 는 react 라는 라이브러리를 이용하는 프레임워크이지만 react 를 프레임워크라고 부를 경우 구분을 위해 메타프레임워크 라고 부르게 됩니다. 모든 도구들은 서로 엮여있기에 사실 이들을 구분하는 건 큰 의미가 없습니다.

아무튼 모든 도구들은 라이브러리의 형태로 제공되며 semantic versioning 으로 버전이 매겨져 registry 에 배포되므로 이 글에서는 이 셋을 통합하여 라이브러리 라고 칭하겠습니다.

라이브러리를 쓰지 않을 이유들

해결하고자 하는 문제가 다를 경우

라이브러리 제작자는 자신이 해결하고 싶은 문제를 해결하는 도구를 개발하고, 잘 만든 도구라면 많은 사람들이 써주길 바라며 배포합니다. 오픈소스 생태계를 지탱해주는 너무 좋은 행동이지만, 사실관계만 따진다면 라이브러리 제작자는 제가 해결하고 싶은 문제를 알지 못합니다. 따라서 제가 해결하고자 하는 문제와 라이브러리가 해결하는 문제는 다를 수 있습니다.

가령 next.js 를 이용하는 개발자들은 인증을 처리하기 위해 next-auth 라이브러리를 종종 이용합니다. next 와 auth 가 붙어 있어서 "넥스트에서 인증 처리를 하려면 next-auth 를 쓰면 되겠구나!" 라고 자연스럽게 생각하게 될 수 있습니다. 하지만 이 라이브러리는 인증에 관한 통합 구성을 제공해주는 데에 초점이 맞춰져 있기에 백엔드 개발자가 인증을 구성해뒀다면 이를 적용하는 데에는 적합하지 않습니다.

더 심각한 상황은, 라이브러리가 해결해주는 문제에 내 문제를 끼워맞추기 위해 없는 문제를 만들어내기도 합니다. 가령 오늘 내일 중에 선택할 수 있는 radio ui이면 될 것을 기획자와의 논의 중에 날짜 이야기가 나왔으니 날짜 라이브러리를 리서치하고, 날짜 인풋을 기깔나게 만들어주는 라이브러리를 찾았고, 얘를 설치하려고 굳이 기획을 변경하는 상황도 생기곤 합니다.

라이브러리를 먼저 알아보기보단 풀고 싶은 문제를 명확하게 정의하고, 라이브러리가 필요한지 고민하고, 해당 문제를 풀어주는 라이브러리를 리서치한 다음, 해당 라이브러리가 내 문제를 풀어주는 것이 맞는지 판단해야 합니다.

필요한 라이브러리가 아직 확실하지 않을 경우

라이브러리를 너무 일찍 설치하는 것도 문제가 될 수 있습니다. 일반적인 어플리케이션은 기획이 조금씩 나오면서 성장해가고, 점점 기능이 붙으면서 문제가 생기게 됩니다.

하지만 아직 어느 기능이 나올지 / 어떤 문제가 생길지 확실하지 않은 상황에서 라이브러리를 먼저 설치하는 경우도 있습니다. 이렇게 되면 결국 라이브러리가 해결해주는 문제와 내가 해결해야 하는 문제가 달라 씨름하게 됩니다. how to use localStorage in next.js server component 와 같은 것들을 검색하고, 불가능하단 것에 좌절하고, 어떻게 해결할지 다시 리서치하고, 다 해결하고 보니 결국엔 next.js 를 쓰는 의미가 하나도 없었던 - 이런 상황을 맞게 됩니다.

특히 next.js 와 같은 프레임워크는 다른 프레임워크로 마이그레이션하기도 쉽지 않기에 개발자는 눈물을 머금고 수 년 간 계속 고통받아야 합니다.

모든 문제를 해결해주는 라이브러리는 없고 내가 무슨 문제를 해결해야 할지 훌륭하게 예측할 수도 없기에 라이브러리 선택은 신중해야 하며, 가능한 선택사항을 오랫동안 열어둬야 하며, 언제든 다른 라이브러리로 갈아끼울 수 있게 신경써야 합니다.

라이브러리를 신뢰하기 어려울 경우

기본적으로 라이브러리의 관리 권한은 내가 아닌 라이브러리 제작자에게 있습니다. 때문에 라이브러리에 버그가 생겼을 때 해결하고 배포하는 것도, 새로운 퍼스트파티 버전이 나왔을 때 대응하는 것도 라이브러리 제작자가 해야 할 일입니다.

이런 상황을 생각해볼까요?

• 어떤어떤 기능을 구현하기 위해 @somerandomuser/somelibrary 를 설치해서 1년간 이용합니다.
• 1년이 지났으니 새로운 노드 버전이 나왔고, 사용하는 프레임워크가 이전 노드 버전 지원을 중단했습니다.
• 하지만 @somerandomuser/somelibrary 는 새 노드 버전을 지원해주지 않고, 이에 issue 를 올렸지만 메인테이너는 감감무소식입니다.
• 해당 라이브러리의 커뮤니티가 거대해서 어떤 용기있는 사람이 라이브러리를 포크해서 메인테이닝했다면 문제가 해결될 수 있었겠지만, 커뮤니티도 너무 작았고 그런 사람은 나타나지 않습니다.
• 결국 참다참다 라이브러리를 제거하고 비슷한 기능을 지원하는 새로운 라이브러리로 마이그레이션하는 데에 3주를 소모합니다.

라이브러리 제작자라는 한 사람/팀에 의존하기보단 라이브러리를 이용하는 커뮤니티 생태계에 의존해야 합니다. 커뮤니티가 너무 작은 라이브러리는 주의해야 합니다.

라이브러리가 기능에 비해 과한 요구를 할 경우

라이브러리를 이용하기 위해 코드베이스를 과하게 변경해야 하거나, 많은 양의 코드를 해당 라이브러리에 의존하도록 구현하길 요구할 수 있습니다. 가령 next.js 의 file system based routing 이 그 예시입니다.

next 정도 되는 라이브러리라면 그 정도 요구를 할 수 있을 만큼 많은 기능을 제공해주지만, 그렇지 않은 라이브러리들도 있습니다. 이런 라이브러리들을 위해 코드의 많은 부분을 희생한다면 나중에 라이브러리를 변경하고 싶을 때 큰 고통을 감수해야 할 것입니다.

라이브러리를 사용할 때 주의할 점

이 섹션은 사실상 앞의 섹션에서 했던 이야기를 다시 하는 것인데요,

먼저 라이브러리가 내가 가지고 있는 문제를 해결해주는 게 맞는지 꼼꼼히 확인해야 합니다. 내가 가지고 있는 문제를 명확하게 정의하고, 라이브러리가 해결해주는 문제를 명확하게 리서치해야 합니다.

또한 신뢰할 수 있는 라이브러리인지 확인해야 합니다. breaking change 를 너무 자주/많이 만든다거나 사용자 수가 너무 적다면 주의해야 합니다.

또한 언제든 다른 라이브러리로 갈아탈 수 있는 상태를 유지해야 합니다. 라이브러리는 유행과도 같아서 항상 더 좋은 게 등장하고, 라이브러리가 스스로 맛이 가는 사태도 종종 발생하니 특정 라이브러리에 의존하는 코드의 양을 최대한 줄이는 것이 좋습니다.

마지막으로, 라이브러리 이름에 오타가 없는지 꼼꼼히 확인해야 하고, 라이브러리를 설치할 때는 버전을 고정하는 게 좋습니다. faker.js & colors.js 사태를 보면 알 수 있듯 캐럿 (^) 은 오히려 치명적인 버그를 만들 수 있습니다.

결론

물론 라이브러리를 쓰면 안 된다는 것은 아닙니다. NIH 신드롬이라는 말이 있듯 라이브러리를 너무 불신하고 스스로 모든 걸 만들려고 하는 것도 많은 심각한 문제를 낳을 수 있습니다.

항상 조심해서 라이브러리들을 대하고 이용한다면 라이브러리가 가져다 주는 좋은 점들만 취하고 나쁜 점들로 인한 피해는 최소화하면서 편하게 개발할 수 있을 것입니다.