서론
평소 나는 오픈소스에 관심이 많은 덕분에, 적절한 오픈소스를 검색해서 응용하거나 적용하는 방법을 자연스럽게 익혔다.
그런데 주변 개발자들과 이야기해보면, 생각보다 많은 사람들이 최신 트렌드나 오픈소스 생태계에 떠오르는 라이브러리를 잘 모르는 경우가 많다. 아무래도 자신이 익숙하게 써오던 것만 계속 사용하는 경향 때문인 것 같다.
프로젝트를 하다 보면 수많은 오픈소스 중에서 하나를 선택해야 하는 순간이 자주 온다. 예를 들어, 기존에 사용하던 오픈소스 라이브러리가 특정 브라우저에서 제대로 동작하지 않는다거나, edge case에서 에러가 자주 발생한다거나, 번들 사이즈가 너무 크다거나, 혹은 새로운 기능을 추가하기 위해 다른 선택지를 고려해야 하는 경우가 있다.
그래서 이번 글에서는 어떻게 하면 수많은 옵션들 중에서 적절한 오픈소스를 잘 선택할 수 있을지, 그 방법에 대해 이야기해보려고 한다.
선택 기준
최근에 회사에서 캘린더 라이브러리를 활용한 컴포넌트를 만들어야 하는 일이 있었다. 요구사항은 다음과 같았다.
- 행사 기간을 리스트뷰가 아닌 캘린더뷰에서 확인할 수 있어야 한다.
- 월 단위 또는 2주 단위로 뷰를 전환할 수 있어야 한다.
- 기존 UI에 맞게 쉽게 커스텀할 수 있어야 한다.
이 요구사항을 바탕으로 다음과 같은 기준을 세웠다.
- 커스터마이징이 쉽다.
- 레퍼런스가 많고, 커뮤니티가 활발하다.
- 번들 사이즈가 작다.
검색부터 선택까지
1. Best Of JS — 빠르게 후보군 좁히기
Best Of JS는 오픈소스 트렌드를 한눈에 살펴볼 수 있는 사이트다.
카테고리별로 인기 프로젝트를 정리해주기 때문에, 관련 키워드만 입력하면 어떤 라이브러리들이 지금 활발하게 사용되고 있는지 바로 파악할 수 있다.
나는 ‘calendar’ 키워드로 검색했고, 다음과 같은 후보군을 빠르게 추릴 수 있었다.
🔗 Best Of JS - calendar 검색 결과
- FullCalendar
- ToastUI Calendar
- Big Calendar
- React Calendar
- Schedule-X
이 중에서는 FullCalendar와 Schedule-X를 후보군으로 남겼다.
공식 문서, GitHub Stars, 번들 사이즈 등을 고려한 결과다.
2. Perplexity — 요구사항 기반의 맞춤 검색
요즘은 일반 검색엔진보다 Perplexity를 자주 사용한다.
검색의 질을 높이기 위해, 내 요구사항과 기준을 구체적으로 적고 마지막에 “공식 문서 또는 공신력 있는 문서에서 찾아줘”라는 문장을 덧붙인다.
예를 들어 캘린더 라이브러리를 찾을 때 이렇게 검색했다.
빠르고 쉽게 커스텀할 수 있는 리액트 캘린더 라이브러리를 알려줘. 레퍼런스가 많았으면 좋겠고, 번들 사이즈가 작으면 좋아. 비교해서 테이블 형태로 보여줘. 그리고 공식 문서 또는 공신력 있는 문서에서 찾아줘.
이렇게 질문하면 단순한 추천뿐 아니라 각 라이브러리의 특징, 장단점, 번들 사이즈, GitHub 스타 수, 공식 문서 링크까지 정리된 형태로 답변이 나오기 때문에 훨씬 효율적으로 비교할 수 있다.
Perplexity를 쓸 때는 질문을 구체적으로 작성할수록 더 유의미한 답을 얻을 수 있다.
3. Reddit - 실사용자 후기 살펴보기
라이브러리를 직접 사용해본 개발자들의 이야기가 궁금할 때는 Reddit을 찾는다.
실사용자들의 댓글을 통해 다양한 선택지를 파악할 수 있고, 특히 사용 후기나 불만 사항을 통해 단점까지 미리 파악할 수 있다는 점이 좋다.
최종 선택
최종적으로 나는 FullCalendar를 선택했다.
레퍼런스가 풍부하고, 커뮤니티도 활발해 개발 중 막히는 부분을 비교적 쉽게 해결할 수 있었다. 특히 나는 Windsurf를 사용해 캘린더 컴포넌트를 개발했는데, 관련 질문이나 예제가 많아 검색 시 원하는 정보를 빠르게 얻을 수 있었다.
PoC 단계에서는 Schedule-X도 사용해봤다. 처음에는 번들 사이즈가 작고 커스터마이징이 쉬워 보여서 기대했지만, 막상 적용해보니 사용 사례가 많지 않아 문서만으로는 원하는 기능을 구현하기 어려웠다. 커뮤니티가 아직 작다 보니 문제 상황에 대한 해결 방법을 찾는 데 시간이 오래 걸렸고, 결국 안정성과 생산성 측면에서 FullCalendar가 더 적절한 선택이라고 판단했다.
물론 FullCalendar도 단점이 없는 건 아니다. 기본 제공 스타일이 많아서 커스터마이징이 다소 번거롭고, 처음 셋업할 때 다소 복잡하게 느껴질 수 있다. 하지만 요구사항과 개발 일정, 팀 내 경험치를 고려했을 때 합리적인 선택으로 판단했다.
마무리
오픈소스를 선택하는 과정은 단순히 “좋은 라이브러리”를 찾는 일이 아니라, 지금 내 상황에 가장 적합한 도구를 고르는 일이라고 생각한다.
개발자마다 환경과 요구사항이 다르고, 프로젝트마다 중요하게 여기는 기준도 다르기 때문에, 자신만의 선택 기준과 탐색 루트를 갖고 있는 것이 중요하다.
앞으로도 새로운 오픈소스를 탐색할 때마다 이 과정을 반복하면서, 나만의 판단 기준을 점점 더 정교하게 다듬어가게 될 것 같다.
누군가에겐 당연하게 느껴질 수도 있지만, 이 글이 오픈소스 선택에 어려움을 겪는 누군가에게 작은 힌트가 되었으면 한다.