주요 내용
코스: 컴퓨터 프로그래밍 > 단원 6
단원 7: 웹 페이지에 JS 라이브러리 사용하기어떤 JS 라이브러리를 사용해야 할까요?
세상에는 수많은 라이브러리가 있으며, 어떤 기능을 수행하는 라이브러리가 필요할 때, 같은 기능이 있는 라이브러리를 여러 개 찾을 수 있을 겁니다. 예를 들어, 웹상에는 수많은 날짜 선택기 라이브러리가 있는데, 다음과 같은 "Top 15 jQuery DatePickers" 글은 가장 좋은 라이브러리를 선택해서 보여줍니다.
그러나 선택지가 너무 많으면 우리 같은 웹 개발자는 혼란에 빠지게 됩니다. 제일 좋은 것이 무엇인지 어떻게 알 수 있을까요? 만약 잘못된 선택을 한다면 어떡할까요?
웹 개발을 할 때 단 한 개의 "최고의 선택"은 없는 경우가 많습니다. 그러나 어떤 선택이 다른 선택보다 나은 경우는 있습니다. 아래 글은 앞으로 더 나은 선택을 할 수 있도록 도와줄 것입니다.
JS 라이브러리가 사용자와 대면하는 제품을 개발할 때 자주 사용되기 때문에, 해당 라이브러리를 사용하여 코드를 작성하고 유지보수하는 (여러분과 같은!) 개발자뿐만 아니라 이를 사용하는 사용자들 또한 만족시켜야 합니다:
개발자 입장에서 좋을까요?
- 잘 정리된 문서: 함수의 시그니처, 예제, 그리고 자세한 사용법 등을 찾기 쉬워야 합니다.
- 유연성: 문서의 예제가 괜찮아 보이는 것과 상관없이 예제와 다른 방법으로 사용하고 싶을 수도 있습니다. 유연성을 잘 살펴보세요. 다른 구성으로 사용하기 쉽나요? 플러그인 설계에 대한 문서가 있나요? 코드에 연동할 만한 이벤트를 많이 발생시키나요?
- 활발한 유지 보수: 브라우저는 빠르게 변화하고 있습니다. 잘 작동하던 라이브러리도 브라우저의 바뀐 부분에 의존하고 있다면 갑자기 안 될 수도 있습니다. 이는 특히 HTML5 shims, polyfills 같은 경우에 그러한데, 새로운 HTML5 요소의 구현 방식에 맞추어 브라우저들이 빠르게 새 버전을 출시하기 때문입니다. 라이브러리가 언제 업데이트 되었는지는 체인지로그를 통해 확인할 수 있습니다. 체인지로그가 없고 라이브러리가 Github 같은 오픈 소스 리포지터리에서 호스팅 된다면, 마지막 commit의 날짜를 확인하면 됩니다.
- 미래지향성: HTML5의 "shim"을 찾고 있다면 API를 모방하는 shim인 "polyfill"을 추천합니다. 그러면 적어도 이론적으로 모든 사용자가 구현할 기술을 지원하는 브라우저를 사용하게 될 때 코드의 수정 없이도 라이브러리를 아예 사용하지 않을 수 있습니다. 예를 들어 HTML5의
video태그를 사용 가능한 polyfill을 사용하면 오래된 브라우저의 플래시처럼 도태되어가는 기술을 이 태그로 대체해 줍니다. - 테스트: 좋은 라이브러리라면 라이브러리가 잘 작동하는지 확인할 수 있는 테스트 포함해야 합니다. 라이브러리가 테스트 되어 있어야 라이브러리 새 버전의 하위 호환성을 신뢰할 수 있습니다.
- 깨끗한 코딩: 오픈 소스 라이브러리를 블랙박스처럼 다뤄 안을 들여다보지 않는 것도 가능합니다. 하지만 때때로 새로운 기능을 추가하거나 디버깅할 때 라이브러리 코드 안을 살펴보아야 하는 경우가 있습니다. 코드를 한 번 훑어 보고, 큰 주석 처리 된 코드 블록같은 이상 징후가 있는지 확인해 보세요.
- 활발한 커뮤니티: 무조건 궁금한 점이 생기고, 무조건 버그를 맞닥뜨리게 될 것입니다. 가장 좋은 시나리오는 이것들을 라이브러리 관계자던 다른 사용자던, 다른 개발자들과 함께 해결하는 것입니다.
Github와 같은 버젼 컨트롤 사이트에 라이브러리가 등록되어있다면, 다음을 확인해 보세요:
- fork 횟수: 많은 fork(또는 star)는 적어도 그 라이브러리를 fork할 만큼 관심 있는 개발자들이 많이 있다는 것을 의미합니다. 꼭 도움을 줄 수 있는 것은 아니지만 시작은 할 수 있습니다! 큰 라이브러리는 대개 수천 개의 fork를 갖고 있고, 작은 라이브러리는 수백 개 혹은 수십 개의 fork를 갖고 있습니다.
- issue의 개수: 열린 issue가 많나요? 이는 issue에 대응하고 해결하려는 노력이 부족하다는 신호일 수 있습니다. 하지만 개선될 수 있는 방향이 다양한 인기 있는 프로젝트일 수도 있으므로 다음 경우도 고려해보아야 합니다.
- issue의 분위기: issue와 pull requests 를 쭉 읽어보세요. 개발자가 피드백을 적극적으로 받아들이나요? 사용방법에 대한 질문에 답해주나요? 대화에서 긍정적이거나 부정적인 분위기를 느끼나요?
- 외부 커뮤니티: StackOverflow에 그 라이브러리에 대한 질문에 답이 달려있나요? 그 라이브러리를 바탕으로 만들어진 라이브러리가 있나요? 작은 라이브러리는 대부분 외부 커뮤니티를 가질 만큼 크지 않지만 Modernizr나 Backbone과 같이 큰 라이브러리는 유명한 외부 커뮤니티를 갖고 있습니다. 이러한 점은 그 라이브러리를 사용할 큰 동기입니다. 라이브러리에 대해 알고 싶은 게 있으면 인터넷에서 라이브러리 이름을 검색해 그 결과를 확인해 보세요.
사용자 입장에서 좋을까요?
만약 JS 라이브러리가 UI 요소를 생성하지 않는다면, 처음 몇 가지만 신경 쓰면 됩니다.
- 파일 사이즈: 사용자가 다운로드 받을 크기에 얼마나 영향을 미칠까요? 참고로 jQuery는 gzip으로 18k로 압축되며 Select2는 7K로 압축됩니다.
- 성능: 만약 JS 라이브러리가 복잡한 DOM 조작, 그래픽 랜더링, 계산, 동기식 저장소 호출과 같은 특성이 있다면 크기에 상관없이 성능에 영향을 끼칠 수 있습니다. 혹시 성능을 향상하는 방법이 없는지 잘 알아보고, 알아내면 한 번 시도해 보세요.
- 브라우저 지원: 라이브러리가 사용하려는 브라우저를 지원하는지 확인해 보세요. 오늘날의 많은 라이브러리들은 일부러 구식 브라우저를 지원하지 않는데(개발할 웹 페이지의 지원 필요 여부와 관계 없이), 그 이유는 라이브러리가 모바일 브라우저용으로 저용량 설계되었기 때문입니다.
- 접근성: UI 요소를 위한 라이브러리는 보기엔 좋아 보이지만, 접근성이 떨어집니다 (시각 장애가 있는 사용자에게 불편할 수 있습니다). 라이브러리의 접근성을 빠르게 확인해보고 싶으면, WAVE에서 라이브러리의 데모 페이지를 실행해볼 수 있습니다.
- 반응: 만약 사용자들이 라이브러리 UI 요소를 모바일 브라우저 상에서 사용한다면 각자의 모바일 환경에서 잘 작동해야만 합니다. 버튼이 충분히 큰가요? 터치 이벤트를 사용하나요? 작은 화면 크기에 맞춰서 크기가 조절되나요?
기준을 모두 맞춰도 여전히 유용한 라이브러리를 결정하지 못했다면, 아마 친구 찬스를 써보세요. 동료나 개발자 친구들에게 어떤 라이브러리를 사용하는지 물어보세요. 대중들이 좋아하는 라이브러리를 찾을지도 모릅니다.
기억하세요: 단 하나의 정답은 없고, 단 하나의 최선책도 없습니다. 사용하려는 모든 JS 라이브러리를 철저하게 살펴볼 필요도 없습니다. 특히 자신을 위한 프로젝트를 진행한다면 말이죠. 아무 라이브러리를 선택해서 사용하는 동안 마음에 드는 점을 살펴보면 됩니다. 아마 머릿속에 좋아하는 라이브러리 목록과, 라이브러리에 대한 기준을 만들게 될 것이고, 이는 나중에 결정을 내리는 데에 도움을 줄 수 있을 겁니다.