이 페이지는 Cloud Translation API를 통해 번역되었습니다.

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

Umar Hansa

이 도움말에서는 웹 애플리케이션 내에서 사용할 라이브러리나 프레임워크를 선택하는 방법에 대한 유용한 정보를 공유합니다. 이 섹션의 내용을 통해 해결하려는 비즈니스 문제에 적합한 JavaScript 라이브러리 또는 프레임워크를 찾을 때의 장단점을 고려할 수 있습니다. 다양한 상황에서 적용되는 장단점을 이해하는 것은 사용 가능한 많은 수의 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 라이브러리를 사용하면 시간을 절약할 수 있습니다.

라이브러리 사용량에 관심을 가져야 하는 이유

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

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

짐작할 수 있듯이 특성에 따라 웹 애플리케이션에 미치는 영향도 다를 수 있습니다. 결정이 그렇게 깊지 않을 때도 있으며 마음에 들지 않는 라이브러리는 안전하게 교체할 수 있습니다. 그러나 라이브러리가 작업과 웹 애플리케이션에 상당한 영향을 미칠 수 있으므로 더 많은 정보를 바탕으로 접근하는 것이 필요할 수 있습니다.

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

성능

JavaScript 라이브러리가 클라이언트 측 웹 애플리케이션에 미치는 성능 효과는 무시해서는 안 됩니다. 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 페이지(있는 경우)를 검사합니다. 미해결 보안 문제가 있는지, 이전 보안 문제가 적절한 기간 내에 해결되었는지 조사합니다.
다른 서드 파티 코드를 사용하는 서드 파티 코드는 종속 항목이 없는 라이브러리에 비해 위험성이 더 높습니다. 이 위험에 유의하세요.

접근성

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

클라이언트 측 JavaScript 기반 라이브러리(또는 프레임워크)는 웹사이트의 접근성을 높이거나 낮출 수 있습니다. 페이지에 이미지 슬라이더를 추가하는 서드 파티 JavaScript 라이브러리를 생각해 보세요. 이미지 슬라이더가 웹 접근성을 고려하지 않으면 웹 개발자가 이러한 중요한 기능을 간과하고 슬라이더를 키보드로 탐색할 수 있는 기능과 같은 중요한 기능이 누락된 제품을 출시할 수 있습니다.

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

이러한 접근성 요구사항을 충족하려면 웹 개발자의 어느 정도 참여가 필요할 수 있습니다. 예를 들면 다음과 같습니다.

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

규칙

확립된 코딩 규칙을 사용하는 소프트웨어 라이브러리는 작업하기가 더 쉽습니다. 라이브러리가 들어본 적이 없는 코딩 규칙을 사용하는 경우 개발자와 팀이 이러한 라이브러리를 사용하는 것이 어려울 수 있습니다.

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

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

관례는 사용 편의성에 큰 역할을 합니다. 직관적인 API가 포함된 라이브러리는 직관적이지 않고 많은 실험을 거쳐야 하는 API에 비해 몇 시간, 심지어 며칠까지 소요되는 시간을 절약할 수 있습니다.

업데이트

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

라이브러리 또는 프레임워크를 선택할 때는 업데이트가 처리되는 방식에 주의를 기울이고 이러한 결정이 개발자에게 영향을 미칠 수 있음을 인식해야 합니다.

라이브러리에 적절한 출시 일정이 있나요? 예를 들어 소스 코드 저장소는 자주 업데이트될 수 있지만 이러한 업데이트가 적절하게 '게시' 또는 '출시'되지 않으면 이러한 업데이트를 다운로드하기가 어려울 수 있습니다.
라이브러리가 적절한 소프트웨어 버전 관리 체계로 업데이트를 출시하나요? 라이브러리는 시간을 절약해 줍니다. 라이브러리 버전을 업데이트할 때마다 예기치 않게 코드를 변경해야 하는 경우, 애초에 해당 라이브러리의 사용 목적이 무효화될 수 있습니다. 브레이킹 체인지는 피할 수 없는 경우도 있지만, 이상적인 환경에서는 변경 횟수가 드물고 라이브러리 소비자에게 강제로 적용되지 않는 것이 이상적입니다.
라이브러리가 하위 호환성에 노력을 투자하나요? 소프트웨어 업데이트에는 중대한 변경사항이 포함될 수 있지만 하위 호환성 레이어도 제공할 수 있습니다. 이를 통해 라이브러리 소비자는 코드를 최소한만 변경하여 최신 라이브러리 버전을 사용할 수 있습니다.

라이선스

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

예를 들어 JavaScript 라이브러리에는 비상업적 환경에서 사용할 수 있는 소프트웨어 라이선스가 있을 수 있습니다. 개인 취미 프로젝트의 경우 훌륭한 선택이 될 수 있습니다. 프로젝트에 상업적인 요소가 있는 경우 엔터프라이즈 라이선스를 고려해야 할 수 있습니다.

확실하지 않은 경우 전문적인 법률 조언을 구하거나 회사 내 법무팀에 문의하세요.

커뮤니티

사용자/참여자 커뮤니티가 큰 라이브러리 또는 프레임워크는 유용할 수 있지만 반드시 그런 것은 아닙니다. 일반적으로 라이브러리나 프레임워크에 사용자가 많을수록 이득을 볼 가능성도 커집니다. 개발자 커뮤니티 참여의 장단점을 고려해 보세요.

장점:

사용자층이 클수록 버그가 조기에 자주 포착될 가능성이 높아집니다.
활발한 대규모 커뮤니티는 해당 라이브러리 또는 프레임워크에 관한 튜토리얼, 가이드, 동영상, 심지어 과정이 더 많다는 의미일 수 있습니다.
활발한 대규모 커뮤니티는 포럼과 질문 및 답변 웹사이트에서 더 많은 지원을 받을 수 있다는 의미이므로 지원 질문에 답변받을 가능성이 높아집니다.
참여도가 높은 커뮤니티는 라이브러리 또는 프레임워크에 더 많은 외부 참여자를 유도할 수 있습니다. 개발자는 개발자 로드맵에 없는 기능을 제공하는 데 도움을 줄 수 있습니다.
커뮤니티 내에서 라이브러리 또는 프레임워크가 인기가 있으면 동료들이 이러한 라이브러리 또는 프레임워크에 대해 들어봤거나 익숙할 가능성이 높아집니다.

단점:

다양하고 규모가 큰 사용자층을 보유한 프로젝트는 끊임없이 기능을 추가하다 보면 불필요한 코드가 늘어날 수 있습니다. 확장된 라이브러리는 웹 성능에 영향을 줄 수 있습니다.
참여도가 높고 활발한 커뮤니티가 있는 프로젝트는 작성자와 유지관리자에게 스트레스를 줄 수 있으며 상당한 수준의 커뮤니티 검토가 필요할 수 있습니다.
빠르게 성장하지만 적절한 지원이 마련되지 않은 프로젝트는 유해한 커뮤니티가 형성되는 조짐을 보이기 시작할 수 있습니다. 예를 들어 초보 웹 개발자나 주니어 웹 개발자는 웹 사이트 운영자의 까다로운 심사 때문에 특정 커뮤니티에서 환영받지 못할 수 있습니다.

문서

JavaScript 라이브러리 또는 프레임워크가 얼마나 단순하거나 복잡하든 소프트웨어 문서는 항상 도움이 될 수 있습니다. 매우 숙련된 개발자도 코드를 직접 알아내는 대신 문서를 사용합니다. 문서에서는 개발자가 사용해야 하는 API와 사용 방법을 명확하게 설명합니다.

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

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

문서가 항상 완전하지는 않을 수 있습니다. 조직의 요구사항, 프로젝트 요구사항, 소프트웨어의 복잡성을 평가하고 이를 토대로 필요한 문서 수준을 결정해야 합니다.

결론

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

라이브러리와 프레임워크에는 고려해야 할 다른 측면이 있으며 이 게시물에서는 자세히 다루지 않았습니다.

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