자바스크립트 라이브러리 또는 프레임워크 선택

우마르 한사

이 문서에서는 웹 애플리케이션 내에서 사용할 라이브러리나 프레임워크를 선택하는 방법에 대한 유용한 정보를 공유합니다. 여기서 설명하는 내용은 해결하려는 비즈니스 문제에 적합한 JavaScript 라이브러리 또는 프레임워크를 찾는 데 있어 장단점을 따져볼 수 있도록 도와줍니다. 여러 가지 상황에 적용되는 장점과 단점을 이해하는 것이 사용 가능한 수많은 JavaScript 라이브러리 선택사항을 검사하는 데 핵심입니다.

JavaScript 라이브러리 및 프레임워크란?

JavaScript 라이브러리란 무엇인가요? 가장 간단한 형태의 JavaScript 라이브러리는 특정 작업을 수행하기 위해 프로젝트의 코드에서 호출할 수 있는 미리 작성된 코드입니다.

이 게시물에서는 주로 '라이브러리'를 언급합니다. 그러나 많은 논의가 프레임워크에도 적용될 수 있습니다. 기본적으로 이 둘의 차이점은 다음과 같이 요약할 수 있습니다.

  • 라이브러리의 경우 애플리케이션 코드가 라이브러리 코드를 호출합니다.
  • 프레임워크의 경우 애플리케이션 코드는 프레임워크에 의해 호출됩니다.

다음은 차이점을 설명하는 데 도움이 되는 실제 예입니다.

자바스크립트 라이브러리 호출 예

JavaScript 라이브러리는 특정 작업을 수행한 다음 애플리케이션에 컨트롤을 반환합니다. 라이브러리를 사용하면 애플리케이션 흐름을 제어하고 언제 라이브러리를 호출할지 선택할 수 있습니다.

다음 예에서는 애플리케이션 코드가 lodash 라이브러리에서 메서드를 가져옵니다. 함수가 완료되면 제어 권한이 애플리케이션으로 반환됩니다.

import capitalize from 'lodash.capitalize';
capitalize('hello'); // Hello

lodash.capitalize 메서드가 실행되면 이 메서드는 문자열의 첫 번째 문자를 대문자로 표기하는 미리 작성된 JavaScript 코드를 호출합니다.

JavaScript 프레임워크 사용 예

JavaScript 프레임워크는 애플리케이션 동작을 구성하는 데 사용되는 사전 정의된 코드 템플릿입니다. 즉, 프레임워크를 사용하면 프레임워크가 애플리케이션 흐름을 제어합니다. 프레임워크를 사용하려면 커스텀 애플리케이션 코드를 작성해야 합니다. 그러면 프레임워크가 애플리케이션 코드를 호출합니다.

다음 예는 Preact JavaScript 프레임워크를 사용하는 코드 스니펫을 보여줍니다.

import { createElement } from 'preact';

export default function App() {
  return (
    <p class="big">Hello World!</p>
  )
}

이 예에서 프레임워크가 개발자가 작성하는 코드를 훨씬 더 세부적으로 제어할 수 있으며, 경우에 따라서는 프레임워크가 코드를 실행할 시기를 제어합니다.

라이브러리를 사용해야 하는 이유

JavaScript 라이브러리를 사용하면 불필요한 코드 반복을 방지할 수 있습니다. 라이브러리는 날짜 조작이나 금융 계산과 같은 복잡한 로직을 추상화할 수 있습니다. 또한 라이브러리를 사용하면 모든 코드를 처음부터 작성할 필요 없이 초기 제품을 도출할 수 있습니다. 시간이 오래 걸릴 수 있습니다.

일부 클라이언트 측 JavaScript 라이브러리는 웹 플랫폼의 특이점을 추상화하는 데 도움이 됩니다. 라이브러리는 학습 도구 역할을 할 수도 있습니다. 예를 들어 애니메이션 이징 함수에 익숙하지 않은 경우 라이브러리의 소스 코드를 통해 이러한 이징의 작동 방식을 알 수 있습니다.

일부 라이브러리는 대규모 기업의 지원을 받아 라이브러리를 최신 상태로 안전하게 유지하기 위해 시간과 비용을 투자합니다. 많은 라이브러리에는 광범위한 문서가 함께 제공되므로, 이를 통해 사용자와 사용자 팀은 라이브러리의 사용법을 빠르게 익힐 수 있습니다.

궁극적으로, JavaScript 라이브러리를 사용하면 시간을 절약할 수 있습니다.

라이브러리 사용에 신경 써야 하는 이유는 무엇인가요?

기술적으로는 웹 애플리케이션을 처음부터 개발할 수 있지만 무료 (오픈소스) 소프트웨어를 사용하거나 장기적으로 시간과 비용을 절약할 수 있는 솔루션을 구매할 수 있는데 왜 문제를 겪어야 할까요? 다양한 자바스크립트 라이브러리와 프레임워크가 제공되며, 각각 고유한 문제 해결 방법을 제공하고 서로 다른 특성을 가지고 있습니다. 예를 들면 다음과 같습니다.

  • 라이브러리는 서드 파티가 아닌 내부적으로 작성하고 유지관리할 수 있습니다.
  • 라이브러리에는 웹 애플리케이션에 적합하거나 적합하지 않은 특정 법적 라이선스가 있을 수 있습니다.
  • 라이브러리가 오래되었거나 관리되지 않을 수 있습니다.
  • 라이브러리를 사용하면 복잡한 작업을 간소화하고 많은 시간과 비용을 절약할 수 있습니다.
  • 라이브러리는 커뮤니티에서 널리 사용될 수 있으며 개발자 사이에 잘 알려져 있습니다.

예상하셨겠지만 각 특성은 여러 가지 방식으로 웹 애플리케이션에 영향을 미칠 수 있습니다. 때로는 그렇게 깊지 않은 결정을 내리고 마음에 들지 않을 경우 라이브러리를 안전하게 교체할 수 있습니다. 그러나 때로는 라이브러리가 작업과 웹 애플리케이션에 상당한 영향을 미칠 수 있으므로 정보에 입각한 접근 방식이 필요할 수 있습니다.

서버 (클라우드 환경에서 실행) 또는 Raspberry Pi와 같은 일부 비 클라이언트 측 JavaScript 환경에서는 라이브러리와 프레임워크를 검사하는 데 사용하는 기준을 조정해야 할 수 있습니다.

성능

클라이언트 측 웹 애플리케이션에서 자바스크립트 라이브러리가 미치는 성능 영향은 무시해서는 안 됩니다. 대규모 자바스크립트 라이브러리는 페이지 로드 성능을 저하시킬 수 있습니다. 단, 밀리초는 수백만 초를 차지합니다.

애니메이션에 JavaScript 라이브러리를 사용하는 시나리오를 생각해 보겠습니다. 어떤 라이브러리는 수십 킬로바이트, 어떤 경우에는 수백 킬로바이트를 쉽게 추가할 수 있습니다. 이와 같은 자바스크립트 리소스는 브라우저에서 코드를 다운로드, 파싱, 컴파일, 실행해야 하므로 페이지 로드가 상당히 지연될 수 있습니다.

JavaScript 라이브러리가 클수록 사용자에게 미치는 성능 영향이 큽니다.

JavaScript 라이브러리나 프레임워크를 평가하거나 사용할 때 성능 개선을 위해 다음 제안을 고려하세요.

  • 큰 JavaScript 라이브러리가 있을 경우, 더 작은 대안을 사용하는 것이 좋습니다. 예를 들어, date-fns는 다른 옵션보다 더 적절한 크기로 많은 기능을 제공합니다.
  • 이전의 date-fns 예시에 이어 import { format } from 'date-fns'와 같이 필요한 함수만 가져옵니다. 이 접근 방식을 트리 쉐이킹과 결합하여 최소한의 JavaScript 페이로드가 빌드되어 사용자에게 전송되도록 해야 합니다.
  • Lighthouse와 같은 성능 테스트 도구를 사용하여 특정 JavaScript 라이브러리 사용 시 성능 효과를 관찰합니다. 라이브러리에서 페이지 로드 시간에 1초 지연이 추가된 경우 (테스트 중에 네트워크와 CPU를 제한해야 함) 원하는 라이브러리를 재평가해야 할 수 있습니다. 페이지 로드를 확인하는 것 외에도 해당 라이브러리에서 코드를 호출하는 모든 웹페이지 동작을 프로파일링해야 합니다. 페이지 로드 성능이 모든 것을 알려주지는 않습니다.
  • 도서관 작성자가 댓글을 환영한다면 성과에 대한 의견, 제안, 프로젝트에 대한 기여를 제출해 주세요. 오픈소스 커뮤니티가 중요한 역할을 합니다. 기부를 하기로 결정했다면 먼저 고용주에게 문의해야 할 수도 있습니다.
  • bundlesize와 같은 자동 번들 추적 도구를 사용하여 라이브러리에 예기치 않게 대규모 업데이트가 있는지 확인합니다. 일반적으로 JavaScript 라이브러리는 시간이 지남에 따라 증가합니다. 기능 추가, 버그 수정, 특이 사례 등은 모두 라이브러리의 파일 크기에 추가될 수 있습니다. 본인 또는 팀이 라이브러리 사용에 동의하면 라이브러리 업데이트로 인한 문제는 덜하고 의문사항이 많지 않을 수 있습니다. 이런 상황에서 자동화를 사용하면 유용합니다.
  • 라이브러리에 대한 요구사항을 살펴보고 웹 플랫폼이 동일한 기능을 기본적으로 제공하는지 여부를 평가하세요. 예를 들어 웹 플랫폼에서는 이미 색상 선택 도구를 제공하므로 동일한 기능을 구현하기 위해 서드 파티 JavaScript 라이브러리를 사용할 필요가 없습니다.

보안

서드 파티 모듈을 사용하면 몇 가지 내재적인 보안 위험이 발생합니다. 웹 애플리케이션 코드베이스 내의 악성 패키지는 개발팀과 사용자의 보안을 손상시킬 수 있습니다.

NPM 생태계에 게시된 라이브러리를 생각해 보세요. 이러한 택배는 합법적인 것일 수도 있습니다. 그러나 시간이 지남에 따라 패키지가 손상될 수 있습니다.

타사 코드를 사용하거나 평가할 때 고려해야 할 몇 가지 보안 팁은 다음과 같습니다.

  • GitHub를 사용하는 경우 코드의 보안 제품(예: Dependabot)을 고려하세요. 또는 snyk.io와 같이 코드의 취약점을 스캔하는 대체 서비스를 고려해 보세요.
  • 사용 중인 서드 파티 코드를 수동으로 감사할 수 있는 엔지니어팀인 코드 감사 서비스를 사용하는 것이 좋습니다.
  • 종속 항목을 특정 버전으로 고정해야 하는지 또는 버전 제어 내에서 서드 파티 코드를 커밋해야 하는지 평가합니다. 이렇게 하면 종속 항목을 하나의 특정 버전(안전하다고 간주할 수 있음)으로 고정하는 데 도움이 될 수 있습니다. 아이러니하게도 라이브러리의 중요한 업데이트를 놓칠 수 있기 때문에 보안에 역효과가 발생할 수 있습니다.
  • 프로젝트 홈페이지 또는 GitHub 페이지(있는 경우)를 스캔합니다. 해결되지 않은 보안 문제가 있는지, 이전의 보안 문제가 합리적인 기간 내에 해결되었는지 여부를 조사합니다.
  • 다른 서드 파티 코드를 사용하는 서드 파티 코드는 종속 항목이 0인 라이브러리보다 위험할 수 있습니다. 이러한 위험에 유의하세요.

접근성

소프트웨어 라이브러리가 웹 접근성과 어떤 관계가 있는지 궁금하실 것입니다. 소프트웨어 라이브러리는 다양한 환경에서 사용할 수 있지만 클라이언트 측 JavaScript 기반 라이브러리 맥락에서는 웹 접근성이 매우 중요합니다.

클라이언트 측 JavaScript 기반 라이브러리 (또는 프레임워크)는 웹사이트의 접근성을 늘리거나 줄일 수 있습니다. 페이지에 이미지 슬라이더를 추가하는 타사 자바스크립트 라이브러리를 생각해 보세요. 이미지 슬라이더가 웹 접근성을 고려하지 않는다면 웹 개발자가 이러한 중요한 기능을 간과하여 키보드 탐색이 가능한 슬라이더와 같이 중요한 기능을 놓치는 제품을 출시할 수 있습니다.

  • 반응형 서체 플러그인이 페이지를 확대하거나 축소하는 사용자를 지원하나요?
  • 파일 업로더 플러그인이 보조 기기에서의 파일 업로드를 지원하나요?
  • 감소된 모션을 선호하는 사용자를 애니메이션 라이브러리에서 지원하나요?
  • 대화형 지도 플러그인이 키보드 전용 사용을 지원하나요?
  • 오디오 플레이어 라이브러리가 스크린 리더에서 적절한 환경을 제공하나요?

이러한 접근성 요구사항을 충족하려면 웹 개발자인 여러분의 개입이 어느 정도 필요하다는 것이 당연합니다. 예를 들면 다음과 같습니다.

  • 누락된 기능이 있는 경우 해당 라이브러리를 계속 사용하는 중에도 코드베이스 내에 이러한 기능을 구현할 수 있습니다.
  • 도서관 작성자가 도서관에 기여할 수 있다면 고용주의 도움을 받아 도서관에 누락된 기능을 제공할 수 있습니다.
  • 라이브러리 작성자와 대화를 열 수 있습니다. 예를 들어 이러한 특정 접근성 기능이 로드맵에 포함되어 있나요? 도서관에 속해 있다는 데 동의하시나요?
  • 인기 있는 사용 사례의 경우 접근성이 더 높은 대체 라이브러리 옵션을 살펴볼 수 있습니다. 이러한 옵션은 존재할 수 있지만 찾기 어렵습니다.
  • 극단적인 경우에는 라이브러리를 완전히 버리고 기능을 처음부터 구현해야 할 수도 있습니다. 이러한 상황은 라이브러리나 프레임워크의 초기 사용 시 접근성이 저하되고 라이브러리나 프레임워크에서 무료로 제공하는 많은 것을 실행 취소해야 할 때 발생할 수 있습니다.

규칙

기존의 코딩 규칙을 사용하는 소프트웨어 라이브러리는 사용하기가 더 쉽습니다. 라이브러리에서 전례가 없는 코딩 규칙을 사용하는 경우 사용자 및 팀이 이러한 라이브러리로 작업하기 어려울 수 있습니다.

라이브러리가 일반적인 코딩 규칙 (예: 공통 스타일 가이드)을 따르지 않는 경우 즉시 고칠 수 있는 방법은 많지 않습니다. 하지만 몇 가지 옵션이 있습니다.

  • 라이브러리 소스 코드와 라이브러리 사용자에게 노출되는 API를 구분해야 합니다. 내부 소스 코드는 익숙하지 않은 규칙을 사용할 수 있지만 API (상호작용하는 라이브러리의 일부)가 익숙한 규칙을 사용한다면 걱정할 필요가 없습니다.
  • 라이브러리 API가 일반적인 코딩 규칙을 따르지 않는 경우 프록시 패턴과 같은 자바스크립트 디자인 패턴을 사용하여 라이브러리와의 모든 상호작용을 코드베이스의 단일 파일로 래핑하고 포함할 수 있습니다. 그러면 프록시가 코드베이스 내 코드의 다른 부분에 더 직관적인 API를 제공할 수 있습니다.

규칙은 사용 편의성과 관련하여 중요한 역할을 합니다. 직관적인 API를 포함하는 라이브러리는 알아내기 위해 많은 실험이 필요한 직관적이지 않은 API와 비교할 때 몇 시간 또는 며칠의 시간을 절약할 수 있습니다.

업데이트

예를 들어, 몇 가지 수학 계산을 수행하는 완전히 작동하는 라이브러리의 경우, 이러한 라이브러리는 업데이트가 거의 필요하지 않을 수 있습니다. 실제로 완전한 기능을 갖춘 라이브러리는 끊임없이 변화하는 웹 개발 세계에서는 거의 찾아볼 수 없습니다. 그러나 라이브러리 작성자가 응답하고 기꺼이 업데이트하기를 원하는 경우도 있습니다. 새로운 연구와 결과를 통해 더 나은 작업 방식을 발견할 수 있으므로 라이브러리와 프레임워크에서 사용되는 기술은 항상 변경될 수 있습니다.

라이브러리나 프레임워크를 선택할 때는 업데이트 처리 방식에 주의를 기울이고 이러한 결정이 나에게 영향을 줄 수 있다는 점에 유의하세요.

  • 라이브러리에 적절한 게시 일정이 있나요? 예를 들어, 소스 코드 리포지토리에 대한 업데이트가 자주 발생할 수 있지만, 이러한 업데이트가 그에 따라 '게시'되거나 '출시'되지 않으면 이러한 업데이트를 다운로드하는 데 어려움을 겪을 수 있습니다.
  • 라이브러리가 적절한 소프트웨어 버전 관리 체계로 업데이트를 출시하나요? 도서관은 시간을 절약해 줍니다. 라이브러리 버전을 업데이트할 때마다 예기치 않게 코드를 변경해야 하는 경우 애초에 이 라이브러리 사용 목적을 무너뜨릴 수 있습니다. 브레이킹 체인지는 불가피한 경우도 있지만, 이상적인 환경에서는 변경이 빈번하지 않고 도서관 소비자에게 강요되지 않습니다.
  • 라이브러리가 이전 버전과의 호환성을 위해 노력을 기울이나요? 소프트웨어 업데이트에 브레이킹 체인지가 수반되는 경우도 있지만 이전 버전과의 호환성 기능이 제공될 수도 있습니다. 이렇게 하면 라이브러리 소비자가 최소한의 코드 변경으로 최신 라이브러리 버전을 사용할 수 있습니다.

라이선스

소프트웨어 라이선스는 서드 파티 소프트웨어 라이브러리 사용에서 중요한 부분입니다. 도서관 제작자는 도서관에 라이선스를 할당할 수 있습니다. 라이브러리 사용을 고려하고 있다면 라이선스 선택이 영향을 받을 수 있습니다.

예를 들어 JavaScript 라이브러리는 비상업적 환경에서 사용하도록 허용하는 소프트웨어 라이선스를 보유하고 있습니다. 개인 취미 프로젝트라면 좋은 선택이 될 수 있습니다. 프로젝트에 상업적 요소가 포함된 경우 엔터프라이즈 라이선스를 고려해야 할 수 있습니다.

의문사항이 있는 경우 전문적인 법률 자문을 받거나 회사 내 법무팀의 자문을 구하는 것이 좋습니다.

커뮤니티

대규모 사용자/기여자 커뮤니티가 있는 라이브러리나 프레임워크가 도움이 될 수 있지만 이를 보장하지는 않습니다. 일반적으로 라이브러리나 프레임워크에 사용자가 많을수록 혜택을 받을 가능성이 커집니다. 개발 커뮤니티에 참여할 경우 다음과 같은 장단점을 고려하세요.

장점:

  • 사용자층이 넓을수록 버그가 조기에 자주 발견될 가능성이 높아집니다.
  • 커뮤니티가 활발하다면 해당 라이브러리나 프레임워크에 더 많은 튜토리얼, 가이드, 동영상, 강좌가 생기기도 합니다.
  • 활발한 커뮤니티가 많으면 포럼과 질문 및 답변 웹사이트에서 더 많은 지원을 받을 수 있으므로 지원 질문에 답변할 가능성이 높아집니다.
  • 참여도 높은 커뮤니티는 라이브러리 또는 프레임워크에 더 많은 외부 참여자를 의미할 수 있습니다. 작성자의 로드맵에 없는 기능을 제공하는 데 도움이 될 수 있습니다.
  • 커뮤니티 내에서 라이브러리나 프레임워크가 널리 사용되는 경우 동료와 동료가 이러한 라이브러리나 프레임워크에 대해 들어보거나 알게 될 가능성이 높아집니다.

단점:

  • 방대하고 다양한 사용자층을 가진 프로젝트는 지속적으로 기능이 추가되면 커질 수 있습니다. 라이브러리가 지나치게 커지면 웹 성능이 저하될 수 있습니다.
  • 적극적이고 참여도 높은 커뮤니티가 있는 프로젝트는 작성자와 유지관리자에게 스트레스를 줄 수 있으며 과도한 커뮤니티 조정이 필요할 수 있습니다.
  • 급격히 성장하고 있으나 적절한 지원을 갖추지 못한 프로젝트는 악의적인 커뮤니티가 존재한다는 징후를 보일 수 있습니다. 예를 들어, 초보 또는 주니어 웹 개발자는 게이트키핑으로 인해 특정 커뮤니티에서 달갑지 않음을 느낄 수 있습니다.

문서

자바스크립트 라이브러리 또는 프레임워크가 아무리 간단하거나 복잡하더라도 소프트웨어 문서가 도움이 될 수 있습니다. 숙련된 개발자도 코드를 직접 파악하기보다는 문서를 사용합니다. 사용해야 하는 API와 사용 방법에 대한 설명이 문서에 나와 있습니다.

문서에서 샘플 코드도 제공하므로 더 쉽게 시작할 수 있습니다. 라이브러리나 프레임워크를 평가할 때 다음과 같은 질문을 할 수 있습니다.

  • 라이브러리에 문서가 포함되어 있나요? 그렇지 않은 경우 스스로 알아내는 데 익숙해져야 합니다.
  • 문서가 명확하고 이해하기 쉬우며 모호함이 없는가? 많은 개발자가 문서에 많은 시간을 할애합니다. 사소해 보일 수도 있지만 텍스트 문서 내에서의 명확성은 생산성에 큰 영향을 미칠 수 있습니다.
  • 문서가 완전히 자동으로 생성되나요? 이러한 문서는 이해하기가 어려울 수 있으며 API 사용 방법을 명확하게 안내하지 않는 경우도 있습니다.
  • 문서가 최신 상태인가요? 문서 유지보수는 때때로 부차적인 고려사항으로 간주됩니다. 라이브러리는 업데이트되고 문서는 업데이트되지 않으면 개발 시간이 낭비될 수 있습니다.
  • 문서가 포괄적이고 다양한 형식으로 제공되는가? 사용자 가이드, 샘플 코드, 참조 문서, 라이브 데모 및 튜토리얼은 모두 라이브러리 또는 프레임워크를 성공적으로 사용하는 데 도움이 되는 유용한 문서 형식입니다.

문서화가 항상 완벽할 수는 없으며 괜찮습니다. 조직의 요구사항, 프로젝트 요구사항, 소프트웨어의 복잡성을 평가한 다음 이를 사용하여 필요한 문서 수준을 결정해야 합니다.

결론

라이브러리나 프레임워크를 처음 선택할 때 압박감을 느끼는 것은 정상입니다. 다른 모든 것과 마찬가지로 더 많이 배우고 연습할수록 더 나은 사람이 됩니다. 다음에 사용할 라이브러리나 프레임워크를 선택할 때 이 게시물을 참조하면 도움이 될 수 있습니다. 이 게시물의 제목을 체크리스트로 사용할 수 있습니다. 예: 이 라이브러리는 성능이 우수한가요? 이 라이브러리는 웹 접근성에 대한 비즈니스 표준을 충족하나요?

라이브러리와 프레임워크의 다른 측면을 고려해야 하지만 이 게시물에서 자세히 다루지 않은 측면도 있습니다.

  • 확장성: 맞춤 로직 또는 동작으로 라이브러리를 얼마나 쉽게 확장할 수 있나요?
  • 도구: 해당하는 경우 라이브러리에 코드 편집기 플러그인, 디버깅 도구, 빌드 시스템 플러그인과 같은 도구가 있나요?
  • 아키텍처: 깔끔한 코드가 중요하지만 라이브러리의 전반적인 아키텍처가 합리적인가요?
  • 테스트: 프로젝트에 테스트 모음이 있나요? 프로젝트 웹사이트가 최신 커밋에 대해 테스트 도구 모음이 통과하는 배지나 지표를 사용하나요?
  • 호환성: 라이브러리가 현재 사용 중인 다른 라이브러리 또는 프레임워크와 잘 작동하나요?
  • 비용: 프레임워크의 비용은 얼마인가요? 오픈소스인가, 아니면 구매 가능한가?
  • 가상 측정항목: 기준 목록에서 하위에 위치해야 하거나 완전히 무시해야 하지만 프로젝트 '투표', 프로젝트를 대표하는 소셜 미디어 계정 또는 프로젝트 페이지에 미해결 버그/문제의 수를 고려할 수도 있습니다.