현업 당시의 글인 외부 라이브러리의 사용에 대한 고찰를 연장하고, 수정한 버전입니다.
현재 프론트엔드는 외부 라이브러리 가상 현실 속에 갇힌 듯합니다. 웹 앱 구현을 위한 라이브러리들이 우후죽순 쏟아져 나오고, 라이브러리의 힘을 많이 빌리고 있어 라이브러리 안에서 개발하는 경우가 많아졌거든요. 아님 말고
하지만 이제 우리는 이 라이브러리 안에서 우리만의 '빨간 약'을 먹고 현실을 직시해야 할 때입니다. 그리고 그 '깨달음'을 바탕으로 우리들의 여행을 이어가야 합니다.
이 글에서는 제가 경험한 라이브러리 의존성의 생각과 그 속에서 찾은 저만의 철학에 대해 얘기를 나누고자 합니다.
대 라이브러리 시대 프론트엔드 개발
불쌍한 프론트엔드 개발자들은 이러한 상황을 대응하기 위해, 개발자들은 다양한 라이브러리에 의존하게 되었습니다. 이러한 추세는 개발 효율성을 높이고 있지만, 동시에 새로운 도전과제도 제시하고 있습니다.
라이브러리에 대한 고찰을 시작하기 전에 먼저 라이브러리를 정의해 보겠습니다.
특정 기능 또는 작업을 수행하기 위해 미리 작성되어 있는, 소프트웨어 개발에서 사용되는 코드, 함수, 클래스, 또는 모듈의 모음
라이브러리는 크게 두 가지로 나눌 수 있습니다. npm 설치 등과 같이 프로젝트 외부에서 가져오는 외부 라이브러리와 프로젝트 내부에서 커스텀 훅, 함수화 등을 통해 재사용 가능하게 만드는 내부 라이브러리입니다.
- 재사용성 : 비슷한 작업을 반복해서 구현할 필요를 줄임.
- 모듈화 : 코드를 구조화하고 관리하기 쉽게 만듦.
- 표준화 : 특정 작업에 대한 가장 효율적인 방법론을 제시해 협업 용이.
이러한 용이성 덕분에 시간을 많이 절약할 수 있게 되었고, npm 등의 라이브러리 커뮤니티들의 지원으로 쉽게 등록 및 사용이 가능해졌습니다.
여기서는 외부 라이브러리만 얘기해보겠습니다.
외부 라이브러리 남용 위험성
이런 부분들로 생긴 Side Effect는 바로 남용이 가능해졌다는 겁니다. 우리 모두가 오픈 소스에 접근해 등록된 모든 코드를 가져올 수 있게 됐죠.
하지만 외부 라이브러리가 커뮤니티도 좋고 경험 많은 개발자들이 만들었다고 해서 모든 부분을 외부 라이브러리로 구현하는 것이 좋을까요? '바퀴를 재발명하지 마라'라는 말이 있지만, 모든 '바퀴'를 가져와야 할까요?
이 글에서는 외부 라이브러리를 과도하게 사용할 경우 발생할 수 있는 단점들에 대해 이야기해 보겠습니다. 어느 경우든 예외가 있는 법이니, 참고만 해주시길 바랍니다.
성능 저하
너무 많은 외부 라이브러리를 사용하면 애플리케이션의 성능에 부정적인 영향을 미칠 수 있습니다.
라이브러리들은 추가적인 코드와 리소스를 필요로 하며, 이로 인해 빌드 시간이 오래 걸려 로딩 시간이 증가하고 메모리 사용량이 늘어날 수 있습니다. 특히 성능이 데스크탑보다 낮은 모바일 디바이스에서는 성능 저하가 더 큰 문제가 될 수 있습니다.
또한 외부 라이브러리의 특성상 사용하지 않는 기능들이 사용하는 기능보다 더 많아 리소스 낭비도 쉽게 일어나기 때문에 성능 저하가 특히 문제가 됩니다.
복잡성 증가 및 코드베이스 어려움 심화
너무 많은 외부 라이브러리를 도입하면 프로젝트의 코드베이스가 복잡해지고, 이해하기 어려워집니다.
각 라이브러리는 자체적인 문법과 사용법을 가지며, 이를 효과적으로 조합하려면 많은 노력이 필요합니다.
예를 들어 @tanstack/react-query의 경우 useQuery, useMutation과 같은 Hooks는 수십 가지의 API와 옵션, 리턴값에 대한 사용법을 익혀야 합니다.
더군다나 여러 라이브러리 간의 충돌 문제나 버전 관리도 더 복잡해질 수 있으며, 이로 인해 디버깅과 유지보수가 어려워질 수 있습니다.
따라서 충분한 문서화가 없다면 프로젝트의 복잡성은 증가하고, 새로운 개발자가 프로젝트에 참여하기 어려워질 수 있습니다.
프로젝트 보안을 위협
외부 라이브러리의 업데이트를 소홀히 하거나 관리하지 않으면 보안 취약점이나 호환성 문제가 발생할 수 있습니다.
큰 문제가 뭐나면, 외부 라이브러리이기 때문에 이 리스크를 직접 컨트롤 할 수 없습니다. 직접 그 라이브러리의 코드를 뜯어보고 문제에 대해서 정의 후 수정된 코드를 반영한 다음 프로젝트 자체의 라이브러리로 도입한다면 모르겠지만요.
또한, 라이브러리 개발자가 보안 패치를 배포하더라도, 이를 프로젝트에 적용하지 않으면 해킹 및 보안 위협에 노출될 수 있습니다. 또한 이러한 점에 대해 피드백이 바로 적용되지 못해 보안이 뚫렸음에도 대응을 못한다는 한계가 있습니다.
대규모 프로젝트일수록 정말 정말 치명적이죠!
외부 라이브러리 의존성 심화 => 안정성 저하
라이브러리를 과도하게 사용하면 개발자들이 해당 라이브러리에 지나치게 의존하는 경향이 생길 수 있습니다. 이는 개발자들이 기본적인 개념과 언어의 이해를 소홀히 하거나 라이브러리에 대한 심층적인 이해 없이 개발을 진행할 수 있음을 의미합니다.
결과적으로 의존도가 너무 높아진 나머지 프로젝트 팀은 라이브러리에 종속되어 프로젝트를 유연하게 관리하거나 변경하기 어려워질 수 있습니다.
또한, 라이브러리가 더 이상 지원되지 않는 경우 프로젝트의 안정성이 저하될 수 있습니다. 중요한 기능을 가진 라이브러리를 사용하고 있다가 NPM 및 커뮤니티가 죽어버린다면(몇 개월 이상 개발이 되지 않는다면) 프로젝트도 큰 타격을 받아 안정성에 대해 금이 갈 수 있습니다.
이에 대한 사례는 코딩애플 유튜브의 실수로 npm을 파괴했던 개발자들에 대해서 한 번 시청해보세요. 재밌읍니다.
외부 라이브러리를 사용하기 위한 기준
이제 우리는 아무거나 주워먹으면 배탈 난다는 것을 알았습니다. 그렇다면 이제 무엇을 선택하고 무엇을 버려야 할지 알아야 할 차례입니다.
프로젝트 성격 파악
모든 사람에게 어울리는 옷이 있듯이, 프로젝트의 성격을 정확하게 파악해 어떤 '옷'을 입힐지 생각해야 합니다.
정확히 어떤 기능이 필요하며, 프로젝트의 목표는 무엇인지 이해하고 라이브러리를 사용해야 합니다. 비즈니스적인 목표일 수도 있고, 소프트웨어 개발 목표일 수도 있습니다.
예를 들어 프로젝트의 비즈니스적인 방향성이 다양한 연령층이나 분야의 클라이언트들을 대상으로 한다면 최대한 접근성이 좋은 라이브러리를 써야 하고, 만약 특정 연령층이나 특정 분야에서 필요 없다고 생각하는 라이브러리는 과감히 삭제하는 것이 맞을 것입니다.
라이브러리가 만들어진 이유/배경 학습
라이브러리의 특징과 사용 이유를 진정으로 이해하기 위해서는 해당 라이브러리가 만들어진 이유 및 배경을 학습하는 것이 중요합니다.
사실, 이렇게까지 안해도 되는데 제가 라이브러리를 선택할 때 항상 고려하는 개인적인 철학입니다.
왜 이렇게 다양한 라이브러리들이 존재하는 걸까요? 이는 각 라이브러리가 기존 도구들의 부족한 점을 해결하려는 시도에서 출발합니다.
항상 새로운 라이브러리는 기존의 문제를 보완하는 방식으로 등장하면서, 각기 다른 철학과 접근 방식을 가지게 됩니다.
예시 : 리액트 쿼리는 왜 만들어졌나?
- 배경 : React 애플리케이션에서 서버 상태 관리의 복잡성 증가.
- 문제점 : 기존 상태 관리 라이브러리들은 클라이언트 상태 관리에 초점.
=> 서버와의 무결성, 동기화 등 문제 발생. - 해결책 : 서버 상태에 특화된 기능(캐싱, 자동 리페칭, 에러 처리 등) 제공.
- 철학 : "서버 상태"와 "클라이언트 상태"를 구분하여 관리.
이러한 배경을 이해함으로써, React Query가 어떤 문제를 해결하려 했는지, 그리고 어떤 상황에서 이 라이브러리가 유용할지 더 명확히 파악할 수 있습니다.
라이브러리의 탄생 배경을 학습함으로써 얻을 수 있는 이점은 아래와 같습니다.
- 라이브러리의 핵심 가치와 목적을 이해가 가능합니다.
- 해당 라이브러리가 우리 프로젝트에 적합한지 더 정확히 이입할 수 있어 판단이 용이합니다.
- 라이브러리의 향후 발전 방향을 예측하는 데 도움이 됩니다.
- 유사한 문제를 해결하는 다른 라이브러리들과의 차이점에 대해 분석할 수 있게 됩니다.
따라서 라이브러리를 선택할 때는 단순히 현재의 기능만을 보는 것이 아니라, 그 라이브러리가 왜 만들어졌는지, 어떤 문제를 해결하려 했는지를 깊이 있게 이해하는 것이 중요합니다.
이는 더 나은 기술 선택으로 이어질 뿐만 아니라, 해당 기술을 더 효과적으로 활용할 수 있게 해줍니다.
라이브러리 장단점/성능 파악
어떤 라이브러리를 사용하면 어떤 특정 기능을 빠르게 구현할 수 있는지, 하지만 라이브러리가 가져올 잠재적인 문제나 성능 저하를 일으킬 수 있는지 고려해야 합니다.
라이브러리의 문서와 예제를 통해 기능과 사용법을 확인하고, 다른 실사용자들의 GitHub 이슈 등의 리뷰 및 피드백도 참고해서 장단점을 확실히 해야 합니다.
또한 프로젝트의 성능 요구사항에 따라 라이브러리를 선택해야 합니다.
예를 들어 대규모 애플리케이션이나 디지털 소외 계층을 타겟으로 잡을 경우 성능 최적화가 중요한데, 라이브러리가 어떻게 성능을 처리하고 최적화되어 있는지 고려해야 합니다. 만약 확실치 않다면 성능 테스트와 벤치마킹을 통해 라이브러리의 성능을 확인할 필요가 있습니다.
라이브러리 커뮤니티 지원 규모 파악
라이브러리의 커뮤니티와 지원 규모를 평가해야 합니다. 활발한 커뮤니티와 지속적인 업데이트가 있는 라이브러리를 선택하는 것이 좋습니다.
미래를 예측할 수 없지만 이렇게 하면 라이브러리에 대한 문제나 버그에 대한 지원을 받을 확률이 상승하고, 커뮤니티의 지식과 리소스의 공급이 활발해 학습에 활용할 수 있습니다.
예시
이러한 기준들을 세워서 라이브러리들을 골랐습니다. 고르는 과정 중에서의 예시와 실제 팁들을 소개해 드리고 싶습니다.
배경 및 이유 파악
배경 및 이유를 파악해 이 라이브러리의 성격을 구조화해 우리 프로젝트에 어울리는지 알 수 있습니다.
React Query를 예로 들어 한 번 간단하게 알아보겠습니다.
-
배경
- React 애플리케이션에서 서버 데이터 관리의 복잡성이 증가했습니다.
- 기존 상태 관리 라이브러리(Redux, MobX 등)는 주로 클라이언트 상태 관리에 초점을 맞추고 있었습니다.
- Redux Saga 같은 대체가 있었지만 매우 큰 보일러 플레이트, 강제된 Flux 구조 등의 이유로 불편함이 있었습니다.
-
문제점
- 서버 데이터 fetching, 캐싱, 동기화, 업데이트 등의 작업이 복잡하고 반복적이었습니다.
- 로딩 상태, 에러 처리, 데이터 만료 등을 매번 수동으로 관리해야 했습니다.
- 선언적으로 좀 더 간단하고, 성능이 좋은 서버 상태 관리 라이브러리가 필요했습니다.
-
React Query 해결책
- 서버 상태 관리에 특화된 기능을 제공합니다.
- 자동 캐싱, 백그라운드 업데이트, 페이지네이션 지원 등의 기능을 내장하고 있습니다.
- 선언적인 방식으로 데이터 fetching을 할 수 있게 해줍니다.
-
철학
- '서버 상태'와 '클라이언트 상태'를 명확히 구분합니다.
- 서버 데이터 관리의 복잡성을 추상화하여 개발자 경험을 개선합니다.
- 선언적이어서 현대 프론트엔드 철학과 어울리고, 직관적으로 서버 상태를 관리합니다.
이러한 배경을 이해함으로써, React Query가 어떤 문제를 해결하려 했는지, 그리고 어떤 상황에서 이 라이브러리가 유용할지 더 명확히 파악할 수 있습니다.
예를 들어, 서버와의 데이터 동기화가 중요한 프로젝트에서는 React Query가 큰 도움이 될 수 있습니다. 반면, 순수하게 클라이언트 사이드 상태만 다루는 프로젝트에서는 다른 라이브러리를 찾는 게 좋을 듯 합니다.
이처럼 라이브러리의 탄생 배경과 철학을 이해하면, 프로젝트의 요구사항에 가장 적합한 도구를 선택할 수 있고, 선택한 도구를 더 효과적으로 활용할 수 있습니다.
npm trends
쇼핑으로 치자면 어느 제품이 판매량과 별점이 높은지를 보여주는 사이트입니다. 이를 통해 커뮤니티 규모와 라이브러리 미래 지원 가능성을 알 수 있죠.
실제로 상태관리 라이브러리를 고를 때를 보여드리자면
위 사진을 보면 Redux가 압도적으로 높은 사용량을 보여 거의 표준이라고 봐도 무방합니다.
하지만 실제로 단점을 따져봤을 때 사용하는 기능보다 많은 코드 보일러플레이트, 큰 패키지 용량, 어려운 문법 등의 단점이 있습니다.
또한 Recoil이 문법이 쉽고 편리한 사용성으로 각광을 받았었는데, 위 사진을 보면 알 수 있듯이 크리티컬한 버그가 생겼는지 6개월 전부터 개발이 이루어지지 않고 있습니다.(6 months ago)
그래서 다시 상태관리 라이브러리를 한 곳에 모아놓고 보았는데 Zustand가 작년부터 계속 사용량이 많아지는 것을 볼 수 있습니다.
또한 업데이트 주기도 괜찮고, 패키지 용량도 Redux보다 훨씬 적으며, 문법도 매우 쉬운 편입니다. 이러면 Zustand를 쓰면 프로젝트에 도움이 되는 확률이 높아진다는 것을 알 수 있습니다.
결론적으로 이러한 점들을 npm trends에서 한눈에 보고, GitHub도 확인하니 라이브러리를 보다 쉽게 고를 수 있었습니다.
결론
프론트엔드로 국한하긴 했지만 다양한 언어 및 개발 환경에서 외부 라이브러리는 다양한 개발자들에게 효율성, 모듈화, 표준화 등의 이점을 제공하며 개발 프로세스를 간소화합니다.
그러나 너무 많은 외부 라이브러리를 사용하는 것은 몇 가지 위험성이 도사리고 있어 고찰과 함께 올바르게 선택되어야 합니다.
남용 위험성을 피하면서, 본인만의 기준을 잘 잡고 라이브러리를 추가해준다면 큰 문제는 없을 겁니다.
다시 말하지만, 라이브러리를 선택할 때는 프로젝트의 성격을 정확히 파악하고, 라이브러리의 장단점과 성능을 평가하며, 활발한 커뮤니티와 지원 규모를 고려해야 합니다. 라이브러리 선택에는 신중함과 균형감을 유지하는 것이 중요합니다.
사실 이 모두를 합한다면 라이브러리 선택을 단순한 도구 선택이 아닌 '투자'의 관점에서 바라볼 필요가 있습니다. 새로운 라이브러리를 프로젝트에 도입하는 것은 단기적인 생산성 향상뿐만 아니라 장기적인 프로젝트 건강성과 팀의 기술 스택에 영향을 미치는 중요한 결정입니다. 마치 주식 투자처럼, 라이브러리 선택에도 리스크와 리워드가 존재합니다.
라이브러리 학습 비용, 지속적 발전 및 유지 가능성에 대한 미래 가치, 잘못된 라이브러리로 인한 기회 비용, 이 라이브러리의 확장 가능성 등에 대해 자산 관리자처럼 접근해보면 색다른 관점을 얻을 수 있습니다.
결국, 라이브러리 선택은 프로젝트의 성공과 개발자 팀의 효율성에 큰 영향을 미치는 중요한 '투자 결정'입니다.
따라서 단기적인 편의성뿐만 아니라 장기적인 관점에서의 가치와 리스크를 충분히 고려하여 신중한 판단과 팀원 분들과 다양한 논의를 거쳐 결정해야할 것입니다.
모르겠으면 걍 선임이 좋아하는 라이브러리 쓰면 좋을 듯 합니다.
