Google은 AI 기술을 사용하여 콘텐츠를 사용자의 기본 언어로 번역합니다. AI 번역에는 오류가 있을 수 있습니다.

JavaScript 라이브러리 또는 프레임워크 선택

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가 일반적인 코딩 규칙을 따르지 않는 경우 프록시 패턴과 같은 JavaScript 디자인 패턴을 사용하여 라이브러리와의 모든 상호작용을 코드베이스의 단일 파일로 래핑하고 포함할 수 있습니다. 그러면 프록시가 코드베이스 내의 다른 코드 부분에 더 직관적인 API를 제공할 수 있습니다.

규칙은 사용 편의성에 큰 역할을 합니다. 직관적인 API가 포함된 라이브러리는 파악하는 데 많은 실험이 필요한 직관적이지 않은 API와 비교할 때 많은 시간 또는 며칠 분량의 인시를 절약할 수 있습니다.

업데이트

예를 들어 몇 가지 수학 계산을 수행하는 완전히 작동하는 라이브러리의 경우 업데이트가 거의 필요하지 않을 수 있습니다. 사실, 끊임없이 변화하는 웹 개발 세계에서 모든 기능을 갖춘 라이브러리는 찾아보기 어렵습니다. 하지만 라이브러리 작성자가 신속하게 대응하고 기꺼이 업데이트를 제공하기를 바라는 경우도 있습니다. 새로운 연구와 발견을 통해 더 나은 방법을 찾을 수 있으므로 라이브러리와 프레임워크에 사용되는 기술은 언제든지 변경될 수 있습니다.

라이브러리나 프레임워크를 선택할 때는 업데이트가 처리되는 방식에 주의를 기울이고 이러한 결정이 다음과 같은 영향을 미칠 수 있음을 유의하세요.

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

라이선스

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

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

의문이 있는 경우 전문적인 법률 자문을 구하거나 회사 내 법무팀에 문의하세요.

커뮤니티

사용자/참여자로 구성된 대규모 커뮤니티가 있는 라이브러리나 프레임워크가 유용할 수 있지만, 이것이 보장되지는 않습니다. 일반적으로 라이브러리나 프레임워크의 사용자가 많을수록 이점을 얻을 가능성이 높습니다. 개발 커뮤니티 참여의 장단점은 다음과 같습니다.

장점:

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

단점:

사용자층이 크고 다양한 프로젝트는 지속적인 기능 추가로 인해 비대해질 수 있습니다. 비대해진 라이브러리는 웹 성능에 악영향을 미칠 수 있습니다.
활발하고 참여도가 높은 커뮤니티가 있는 프로젝트는 작성자와 유지관리자에게 스트레스를 줄 수 있으며, 커뮤니티 운영에 많은 노력이 필요할 수 있습니다.
빠르게 성장하지만 적절한 지원이 없는 프로젝트는 유해한 커뮤니티의 징후를 보이기 시작할 수 있습니다. 예를 들어 초보 또는 주니어 웹 개발자는 게이트키핑으로 인해 특정 커뮤니티에서 환영받지 못한다고 느낄 수 있습니다.

문서

JavaScript 라이브러리나 프레임워크가 얼마나 단순하든 복잡하든 소프트웨어 문서는 항상 도움이 될 수 있습니다. 경험이 풍부한 개발자도 코드를 직접 파악하기보다는 문서를 사용합니다. 문서에는 사용해야 하는 API와 사용 방법이 명시되어 있습니다.

문서에는 샘플 코드도 포함되어 있어 빠르게 시작하는 데 도움이 됩니다. 라이브러리나 프레임워크를 평가할 때 다음과 같은 질문을 할 수 있습니다.

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

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

결론

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

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

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