앞서,
개발을 하면서 우리는 많은 외부 라이브러리들의 도움을 받는다.
라이브러리들마다 가지고 있는 기능들은 다르지만, 만약 내가 원하는 기능을 여러 라이브러리가 모두 가지고 있다면 어떤 기준으로 선택하면 좋을지 고민해보게 됐다.
이 글은 기준 없이 기능만 동작하면 라이브러리를 가져다 썼던 과거의 내가 겪었던 고민들을 공유하고, 같은 고민을 하는 분들에게 도움이 되고자 작성했다.
어떤 것을 기준으로 보면 좋을까 ?
1. 번들 사이즈
번들포비아(bundlephobia)에서 패키지를 검색해보면 다음과 같은 중요한 정보들을 확인할 수 있다.
예를 들어 캐러셀(슬라이드) 기능을 가진 대표적인 라이브러리들을 비교해보면,
- swiper
- react-slick
- React Responsive Carousel
이러한 라이브러리들이 있다.
swiper > react-slick > slick-carousel 순으로 번들 사이즈가 큼을 알 수있다.
예전에는 기능만 되면 무조건 설치했지만, 이제는 번들 사이즈도 고려해야 한다.
번들포비아에서 패키지를 검색해보면, 아래와 같은 정보를 얻을 수 있다.
각 항목들에 대해 정리해보자
bundle size - minified
코드 최소화 후의 크기
gzipped
gzip 압축 알고리즘을 적용한 후의 크기
download time
네트워크 환경별 예상 다운로드 시간
🔥 Composition
라이브러리의 의존성 구조와 각 의존성이 전체 번들에서 차지하는 비율을 나타 냄
react-slick의 경우 다음과 같은 구성을 보인다.
- self(81%): 라이브러리 자체 코드가 차지하는 비율
- resize-observer-polyfill (11.1%) :이 의존성 라이브러리가 번들의 11.1%를 차지
- lodash.debounce (3.1%) : 슬라이드 이벤트 최적화를 위한 디바운스 기능 의존성, 의존성 라이브러리가 번들의 3.1%를 차지
- enquire.js (2.9%) : 반응형 캐러셀 구현을 위한 미디어 쿼리 처리 의존성,이 의존성 라이브러리가 번들의 2.9%를 차지
- ...기타
React-slick은 전체 번들 크기 중 81%가 자체 코드이며, 나머지 19%는 캐러셀 기능 구현을 위해 필요한 외부 라이브러리들로 구성되어 있다.
번들 사이즈가 실제 프로덕트에 미치는 영향
- 큰 번들 사이즈는 다음과 같은 실질적인 영향을 미친다:
- 초기 로딩 시간 증가
- 메모리 사용량 증가
- 불필요하게 큰 라이브러리는 브라우저 메모리를 더 많이 차지
- 번들 크기가 클수록 자바스크립트 파싱과 실행 시간 증가
따라서 단순히 기능이 동작한다고 해서 큰 라이브러리를 선택하기보다는, 실제로 필요한 기능만 포함된 가벼운 라이브러리를 선택하거나, 간단한 기능이라면 직접 구현하는 것을 고려해볼 필요가 있다.
2. 필요한 기능에 맞는 적절한 규모
예를 들어, 단순한 캐러셀 기능만 필요한데 Swiper 같은 큰 라이브러리를 사용하면 오버스펙이 될 수 있다.
또 다른 예시로 lodash의 경우, 전체 라이브러리를 설치하면 실제로 사용하지 않는 많은 기능들까지 포함되어 불필요하게 번들 크기가 커질 수 있다.
만약 구현하고자 하는 기능이 단순하고 시간적 여유가 있다면, 직접 구현하는 것도 좋은 선택이다.
3. 커뮤니티의 크기
이 부분은 간략하게만 쓰고 넘어가겠다.
커뮤니티가 클수록 문제 해결에 필요한 자료를 찾기 쉽다. 같은 문제를 겪은 다른 개발자들의 해결책을 참고할 수 있는 가능성이 높아지기 때문이다.
4. 유지보수가 되는 라이브러리 인지
실제 경험한 사례를 통해 유지보수의 중요성을 설명해보겠다.
- 외부 솔루션 Docs와 맞게 타입을 정의했음에도 계속 타입 에러가 발생하는 이슈가 있었다.
라이브러리 내부 코드를 확인해보니 공식문서와 다르게 정의되어있는 타입임을 확인했고 커뮤니티를 통해 질문을 남겨놓아 피드백으로 Docs에 맞게 타입 수정 후 라이브러리 버전을 올려주었다.
- 외부 솔루션 자체에서 엣지케이스를 처리하지 않고 넘기는 바람에 우리 로직에까지 영향이 미친 이슈
팀원분이 발견한 케이스였는데, 누군가는 그 에러를 마주할 수도 있기에 회사 팀원분께서 그 코드를 수정하는 PR을 올렸다.
하지만 유지보수가 되고 있지 않아서인지 아직까지도 그 PR은 Merge되지 않고 방치되어 있다.
같은 문제였지만 유지보수가 되고있는지 아닌지에 따라 결과는 달랐다.
유지보수 되지 않을 때 해결방안으로는 아래의 두가지 방식을 고려해 볼 수 있을 것이다.
해결방안 1: 프로덕트 단에서 처리
- 라이브러리 로직을 타기 전에 타입가드 추가
- 엣지케이스 핸들링 추가
해결방안 2: 라이브러리 커스터마이징
- 라이브러리의 내부를 수정하여 커스텀 버전 패키지 사용
yarn berry를 활용하여 패키지를 커스텀 했던 경험이 있다.
5. 라이브러리의 버전이 release 1.0 이상으로 업그레이드된 버전인지
이 부분은 무조건적으로 중요하다라고 말할 수 있는 부분은 아니지만,
고려해봐서 나쁜점은 없다고 볼 수 있다.
프론트엔드 상태관리 라이브러리로 Recoil, Zustand, Jotai가 동시에 주목받던 시기가 있었다. (적어도 내가 느끼기에는 그랬다.)
그 당시 Recoil은 1.0 버전이 아닌 실험적인(experimental) 라이브러리였지만,
리덕스에 비해 간편한 보일러플레이트를 제공한다는 점에서 개인적으로 선호하여 선택해 사용했었다.
하지만 몇 년이 지난 지금, Recoil은 결국 1.0 버전까지 릴리즈되지 못한 채 2025년 1월 1일부로 공식적으로 아카이브(보관) 처리되었다.
즉, 더 이상 유지보수되지 않는 라이브러리가 된 것이다.
당시 Recoil 커뮤니티도 활발했고, 정식 릴리즈될 것이라고 생각했지만 그렇지 않았다.
내가 Recoil을 사용했던 프로젝트는 현재 더 이상 개발되지 않고 있으며, 새로운 프로젝트에서는 다른 상태관리 라이브러리를 사용하고 있다.
이 경험을 통해 커뮤니티의 크기도 중요하지만, 릴리즈 버전 또한 신중하게 고려해야 한다는 점을 깨달았다.
물론, 작은 기능을 가진 라이브러리라면 1.0 이상이 아니어도 큰 문제가 되지 않을 수 있다.
하지만 우리가 깊게 활용하고 확장할 기능을 포함하는 라이브러리라면 릴리즈 버전도 고려해야 한다.
💡 version 1.0 의 차이점
- 하위호환성 보장없음, 버그 가능성 상대적 높음 등이 있다.
그래서 어떻게 찾나?
1. 검색
(~~~best library) 와 비슷하게 검색하면 추천 글을 쉽게 볼 수 있다.
2. AI 이용하기
3. 번들포비아 패키지 하나 검색하고 하단을 보면 비슷한 기능의 패키지를 추천해준다.
어떤 능력을 키워야 할까 ? (개인적 견해)
사실 이런 부분들은 개발 업무에 비하면 사소할 수도 있다.
하지만 우리가 사용하는 기술과 선택하는 라이브러리에 의미를 두고 고민한다면,
다음 선택에서도 더 신중하게 결정할 수 있는 습관을 기를 수 있다.
의도적으로라도 "왜 이걸 선택했을까?" 를 고민해보는 것이다.
빠르고 쉽게 문제를 해결해야 한다면 외부 라이브러리를 사용하는 것이 좋은 선택일 수 있다.
하지만 라이브러리를 사용하다가 문제가 발생했을 때 어떻게 디버깅할 것인지도 중요한 능력이다.
- 라이브러리 내부를 까본다거나
- 검색을 통해 문제를 해결한다거나
- AI 같은 도구를 쓰거나
최근 팀 내부에서도 이런 이야기가 나왔는데,
우리가 사용하는 A 라이브러리는 B 라이브러리를 참조할 수 있고,
B 라이브러리는 C 라이브러리를 참조하고,
C는 D를 참조하고…
결국 끝없는 추상화 끝에 A 라이브러리가 우리에게 도달한 것이다.
만약 그렇다면 우리는 굉장히 추상화된 레이어의 라이브러리를 사용하고 있는 것이고,
기본적인 코어 개념과는 점점 멀어지게 된다.
우리는 이 점을 간과하면 안되고,
문제가 생겼을 때 내부코어까지 접근해서 문제해결할 수 있는 능력, 문제를 파악할 수 있는 능력을 갖춰야한다.
사실 말이 쉽지 결국에는 다 경험을 통해 얻는 인사이트인 것 같다...
최근에 내부 팀원들과 이런 얘기를 하면서 코어 로직에 대해 좀더 깊이 있는 스터디를 진행해보자고 말이 나온 상태다.
팀원들과 대화를 통해 나도 다시 한번 더 경각심을 갖게됐고, 라이브러리를 고르는 내용속에 이 내용을 녹여서 써야겠다고 생각했다.
마치며,
사실 작년 중순쯤에 이 내용을 임시저장으로 써놓고 묵혀두었던 글인데,
작업하고 있는 사이드프로젝트 스택을 정하게되면서 다시 한번 정리하고자 글을 남기게 되었다.
누군가에게는 도움이 되는 글이 되었으면 좋겠다.
의견은 환영입니다.
