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

자바스크립트 라이브러리와 프레임워크의 차이점

Umar Hansa

이 도움말에서는 웹브라우저에서 실행되는 코드인 클라이언트 측 JavaScript 환경 맥락에서 프레임워크와 라이브러리의 차이점을 설명합니다. 그러나 라이브러리와 프레임워크는 네이티브 모바일 앱 개발과 같은 여러 소프트웨어 엔지니어링 분야의 일부이므로 이 도움말에서 제기된 몇 가지 사항은 다른 환경에도 적용됩니다.

이 게시물에서는 라이브러리와 프레임워크 간의 양적 차이가 아닌 질적 차이에 중점을 둡니다. 예를 들면 다음과 같습니다.

정량적: 프레임워크는 일반적으로 컨트롤 반전 원칙을 준수합니다.
질적: 프레임워크 경험은 구직 시 미래 고용주의 관심을 더 많이 끌 수 있습니다.

라이브러리와 프레임워크를 배워야 하는 이유

웹에서 JavaScript 라이브러리와 프레임워크가 광범위하게 사용됩니다. 다른 모든 웹사이트는 JavaScript 리소스의 일부로 서드 파티 코드를 사용하는 것 같습니다. 시간이 지남에 따라 웹페이지 크기가 점점 커져 사용자에게 영향을 미칩니다. JavaScript는 전체 페이지 크기에 큰 영향을 미치는 요소이며, 서드 파티 라이브러리와 프레임워크는 종종 이 JavaScript로 구성됩니다.

프레임워크는 개발자에게 큰 이점을 제공하므로 'JavaScript 프레임워크 사용을 중지하세요'라고 말하는 것만으로는 충분하지 않습니다. 프레임워크를 사용하면 효율적으로 코딩하고 기능을 빠르게 제공하는 등 다양한 이점을 얻을 수 있습니다. 대신 필요할 때 정보에 입각한 결정을 내릴 수 있도록 스스로 학습해야 합니다.

'오늘 라이브러리와 프레임워크 중 무엇을 사용해야 하나요?'라는 질문은 흔하지 않습니다. 라이브러리와 프레임워크는 서로 매우 다른 개념입니다. 하지만 라이브러리와 프레임워크는 종종 혼동되며, 두 가지에 대해 더 많이 알면 알수록 이를 사용하는 데 관해 정보에 입각한 결정을 내릴 가능성이 높아집니다.

라이브러리 및 프레임워크의 예

서드 파티 코드는 위젯, 플러그인, 폴리필, 패키지와 같은 다른 이름으로 표시될 수 있습니다. 하지만 일반적으로 모두 라이브러리 또는 프레임워크 카테고리에 속합니다. 기본적으로 두 도구의 차이점은 다음과 같습니다.

라이브러리의 경우 앱 코드가 라이브러리 코드를 호출합니다.
프레임워크의 경우 프레임워크에서 앱 코드를 호출합니다.

라이브러리

라이브러리는 프레임워크보다 간단하고 기능 범위가 좁습니다. 메서드에 입력을 전달하고 출력을 수신하는 경우 라이브러리를 사용했을 가능성이 큽니다.

lodash 라이브러리의 예를 살펴보세요.

import lodash from 'lodash'; // [1]
const result = lodash.capitalize('hello'); // [2]
console.log(result); // Hello

많은 라이브러리의 경우와 마찬가지로, 이 코드를 읽고 어떤 기능을 하는지 이해하는 것이 실용적입니다. 마법과도 같은 방법은 거의 없습니다.

import 문은 lodash 라이브러리를 JavaScript 프로그램으로 가져옵니다.
capitalize() 메서드가 호출됩니다.
단일 인수가 메서드에 전달됩니다.
반환 값은 변수에 캡처됩니다.

프레임워크

프레임워크는 라이브러리보다 크기가 크고 전체 페이지 크기에 더 큰 영향을 미칩니다. 사실 프레임워크에는 라이브러리가 포함될 수 있습니다.

이 예에서는 라이브러리가 없는 일반 프레임워크를 보여주며 인기 있는 JavaScript 프레임워크인 Vue를 사용합니다.

<!-- index.html -->
<div id="main">
  {{ message }}
</div>

<script type="module">
import Vue from './node_modules/vue/dist/vue.esm.browser.js';

new Vue({
  el: '#main',
  data: {
    message: 'Hello, world'
  }
});
</script>

이 프레임워크 예시를 이전 라이브러리 예시와 비교하면 다음과 같은 차이점이 있습니다.

프레임워크 코드는 여러 기법을 포함하고 이를 자체적인 API로 추상화합니다.
개발자는 작업이 발생하는 방식과 시점을 완전히 제어할 수 없습니다. 예를 들어 Vue가 'Hello, world' 문자열을 페이지에 쓰는 방법과 시점은 개발자가 알 필요가 없습니다.
Vue 클래스의 인스턴스화는 프레임워크를 사용할 때 일반적인 몇 가지 부작용을 수반하지만 라이브러리는 순수 함수를 제공할 수 있습니다.
프레임워크는 자체 템플릿 시스템을 사용하는 대신 특정 HTML 템플릿 시스템을 규정합니다.
Vue 프레임워크 문서 또는 대부분의 다른 프레임워크 문서를 자세히 읽어보면 프레임워크가 사용할 수 있는 아키텍처 패턴을 규정하는 방식을 확인할 수 있습니다. JavaScript 프레임워크를 사용하면 이를 직접 알아낼 필요가 없으므로 인식적 부담이 줄어듭니다.

라이브러리와 프레임워크 중 어느 것을 사용해야 하는 경우

라이브러리와 프레임워크 간의 비교를 읽어본 후에는 어느 쪽을 사용해야 하는지 이해할 수 있습니다.

프레임워크를 사용하면 개발자가 복잡성을 줄일 수 있습니다. 앞서 설명한 대로 프레임워크는 로직, 동작, 심지어 아키텍처 패턴까지 추상화할 수 있습니다. 특히 새 프로젝트를 시작할 때 유용합니다. 라이브러리는 복잡성을 완화하는 데 도움이 될 수 있지만 일반적으로 코드 재사용에 중점을 둡니다.
프레임워크 작성자는 개발자가 생산적으로 작업할 수 있기를 바라며, 프레임워크를 효과적으로 사용하는 데 도움이 되는 추가 도구, 디버깅 소프트웨어, 종합 가이드 등의 리소스를 개발하는 경우가 많습니다. 라이브러리 작성자도 개발자가 생산적으로 작업할 수 있기를 바라지만 라이브러리에는 전문 도구가 드뭅니다.
대부분의 프레임워크는 웹 앱을 빠르게 빌드할 수 있도록 스켈레톤 또는 상용구와 같은 기능적 시작점을 제공합니다. 라이브러리는 이미 설정된 코드베이스의 일부가 됩니다.
일반적으로 프레임워크는 코드베이스에 약간의 복잡성을 도입합니다. 복잡성은 처음에는 명확하지 않을 수 있지만 시간이 지남에 따라 드러날 수 있습니다.

라이브러리와 프레임워크는 서로 다른 작업을 수행하는 서로 다른 개념이므로 일반적으로 라이브러리를 프레임워크와 비교하지 않습니다. 하지만 두 가지에 대해 더 많이 알면 알수록 자신에게 가장 적합한 방법을 결정할 수 있습니다. 프레임워크 또는 라이브러리를 사용할지 여부는 궁극적으로 요구사항에 따라 다릅니다.

교체 가능성

라이브러리나 프레임워크는 매주 변경하지 않습니다. 하지만 생태계에 종속되는 패키지의 단점을 이해하는 것이 좋습니다. 또한 서드 파티 패키지를 사용하기로 한 개발자가 패키지와 앱 소스 코드 간의 느슨한 결합 생성에 어느 정도 책임이 있다는 점을 이해하는 것이 좋습니다.

소스 코드에 연결된 패키지는 삭제하고 다른 패키지로 교체하기가 더 어렵습니다. 다음과 같은 경우 패키지를 교체해야 할 수 있습니다.

더 이상 유지보수되지 않는 패키지를 업데이트해야 합니다.
패키지가 너무 버그가 많아 사용할 수 없다는 것을 알게 되었습니다.
요구사항에 더 잘 맞는 새로운 패키지에 대해 알게 됩니다.
제품 요구사항이 변경되어 패키지가 더 이상 필요하지 않습니다.

다음 예를 살펴보세요.

// header.js file
import color from '@package/set-color';
color('header', 'dark');

// article.js file
import color from '@package/set-color';
color('.article-post', 'dark');

// footer.js file
import color from '@package/set-color';
color('.footer-container', 'dark');

이전 예에서는 3개의 개별 파일에서 서드 파티 @package/set-color 패키지를 사용합니다. 이 코드에서 작업하고 서드 파티 패키지를 교체해야 하는 경우 세 곳에서 코드를 업데이트해야 합니다.

또는 유지보수를 간소화하고 라이브러리 사용을 한곳으로 추상화할 수 있습니다. 다음 예를 참고하세요.

// lib/set-color.js file
import color from '@package/set-color';

export default function color(element, theme = 'dark') {
  color(element, theme);
}

// header.js file
import color from './lib/set-color.js';
color('header');

// article.js file
import color from './lib/set-color.js';
color('.article-post');

// footer.js file
import color from './lib/set-color.js';
color('.footer-container');

이전 예에서는 직접 라이브러리 사용이 추상화되었습니다. 따라서 서드 파티 패키지를 교체해야 하는 경우 파일 하나만 업데이트하면 됩니다. 또한 내부 set-color.js 파일이 사용할 기본 색상 테마를 설정하므로 코드 작업이 더 쉬워졌습니다.

사용 편의성

프레임워크에 복잡한 API가 있을 수 있지만 프레임워크는 전반적으로 더 쉽게 사용할 수 있는 개발자 도구를 제공할 수 있습니다. 사용 편의성은 여러 요인에 따라 달라질 수 있으며 매우 주관적일 수 있습니다. 프레임워크가 사용하기 어려운 이유는 다음과 같습니다.

프레임워크에는 본질적으로 복잡한 API가 있습니다.
프레임워크는 제대로 문서화되어 있지 않으며 문제를 해결하려면 많은 시행착오를 거쳐야 합니다.
프레임워크가 나와 내 팀에 익숙하지 않은 기법을 사용합니다.

프레임워크는 다음과 같은 일반적인 권장사항을 통해 이러한 문제를 완화할 수 있습니다.

이 프레임워크는 디버깅을 더 쉽게 할 수 있는 개발자 및 진단 도구를 제공합니다.
이 프레임워크에는 무료 문서, 가이드, 튜토리얼, 동영상을 공동작업하는 개발자 커뮤니티가 있습니다. 이 콘텐츠를 소비하면 프레임워크를 사용하여 생산성을 높일 수 있습니다.
이 프레임워크는 일반적인 코딩 규칙을 따르는 API를 제공합니다. 이전에 이러한 규칙을 배웠고 코딩 스타일에 익숙해져 프레임워크를 효율적으로 사용할 수 있습니다.

이러한 포인트는 일반적으로 프레임워크에 기인하지만 라이브러리에 기인할 수도 있습니다. 예를 들어 D3.js JavaScript 라이브러리는 강력하며 워크숍, 가이드, 문서 등 다양한 리소스를 제공하는 대규모 생태계를 보유하고 있어 사용 편의성에 영향을 미칩니다.

또한 프레임워크는 일반적으로 웹 앱의 아키텍처를 규정하는 반면 라이브러리는 일반적으로 기존 아키텍처와 호환됩니다.

성능

예외가 있기는 하지만 일반적으로 프레임워크는 라이브러리보다 성능에 더 많은 영향을 미칠 수 있습니다. 웹 성능은 다양한 주제를 다루는 광범위한 영역이므로 이 섹션에서는 트리 셰이킹과 소프트웨어 업데이트라는 두 가지 주제를 다룹니다.

트리 쉐이킹

번들은 웹 성능의 한 측면일 뿐이지만 특히 대규모 라이브러리의 경우 성능에 큰 영향을 미칩니다. 가져오기 및 내보내기 중에 트리 쉐이킹을 사용하면 앱에 불필요한 코드를 찾아서 정리하므로 성능이 향상됩니다.

JavaScript 코드를 번들로 묶는 경우 트리 쉐이킹이라는 유용한 단계가 있습니다. 이는 프레임워크보다 라이브러리를 사용하는 것이 더 쉽지만 코드에 적용할 수 있는 중요한 성능 최적화입니다.

서드 파티 코드를 소스 코드로 가져올 때는 일반적으로 코드를 하나 또는 몇 개의 출력 파일로 번들로 묶습니다. 예를 들어 header.js, footer.js, sidebar.js 파일은 모두 output.js 파일로 결합되며, 이 파일은 웹 앱에 로드하는 출력 파일입니다.

트리 쉐이킹을 더 잘 이해하려면 다음 코드 예시를 살펴보세요.

// library.js file
export function add(a, b) {
  return a + b;
}

export function subtract(a, b) {
  return a - b;
}

// main.js file
import {add} from './library.js';

console.log(add(7, 10));

데모를 위해 library.js 코드 샘플은 라이브러리가 수천 줄 길이가 될 수 있는 실제 환경에서 볼 수 있는 것보다 의도적으로 작게 유지됩니다.

단순한 번들 프로세스는 다음과 같은 출력으로 코드를 내보낼 수 있습니다.

// output.js file
function add(a, b) {
  return a + b;
}

function subtract(a, b) {
  return a - b;
}

console.log(add(7, 10));

이 앱에는 subtract() 함수가 필요하지 않지만 최종 번들에 포함됩니다. 이와 같은 불필요한 코드는 다운로드 크기, 파싱 및 컴파일 시간, 사용자가 지불해야 하는 실행 비용을 늘립니다. 기본 트리 셰이킹 접근 방식은 불필요한 코드를 삭제하고 다음과 같은 출력을 생성합니다.

// output.js file
function add(a, b) {
  return a + b;
}

console.log(add(7, 10));

코드가 더 짧고 간결합니다. 이 예에서는 성능 개선이 무시할 만하지만 라이브러리가 수천 줄인 실제 앱에서는 성능 효과가 훨씬 더 클 수 있습니다. 흥미롭게도 Parcel, Webpack, Rollup과 같은 최신 번들 도구는 압축과 트리 쉐이킹을 결합하여 고도로 최적화된 번들을 만들기 때문에 한 단계 더 발전합니다. 번들 도구의 효과를 보여주기 위해 Parcel을 사용하여 이전 코드 예시로 번들 파일을 만들었습니다. Parcel은 사용하지 않는 모든 코드를 삭제하고 이 단일 모듈을 내보냈습니다.

console.log(7+10);

Parcel은 import 문, 함수 정의, 다른 항목 중에서 동작을 삭제할 정도로 스마트하여 고도로 최적화된 코드를 만듭니다.

번들은 웹 성능의 한 측면일 뿐이지만 특히 대규모 라이브러리의 경우 성능에 큰 영향을 미칩니다. 트리 쉐이킹은 일반적으로 프레임워크보다 라이브러리에서 더 간단하게 수행할 수 있습니다.

소프트웨어 업데이트

많은 라이브러리와 프레임워크의 경우 소프트웨어 업데이트를 통해 기능이 추가되고 버그가 수정되며 시간이 지남에 따라 크기가 커집니다. 업데이트를 다운로드할 필요가 항상 있는 것은 아니지만 버그 수정, 원하는 기능 개선사항 또는 보안 수정이 포함된 업데이트인 경우 업데이트하는 것이 좋습니다. 그러나 유선으로 전송하는 데이터가 많을수록 앱의 성능이 저하되고 사용자 환경에 더 큰 성능 영향을 미칩니다.

라이브러리 크기가 커지면 트리 셰이킹을 사용하여 크기 증가를 완화할 수 있습니다. 또는 JavaScript 라이브러리의 더 작은 대안을 사용할 수 있습니다. 자세한 내용은 교환 가능성을 참고하세요.

프레임워크의 크기가 커지면 트리 셰이킹이 더 어려워질 뿐만 아니라 한 프레임워크를 다른 프레임워크로 교체하기가 더 어려워질 수 있습니다. 자세한 내용은 Swapability를 참고하세요.

고용 가능성

많은 회사들이 특정 프레임워크를 아는 개발자에 대해 엄격한 요구사항을 갖고 있다는 것은 어느 정도 공개적인 비밀입니다. 웹 기본사항에 대한 지식은 무시하고 특정 JavaScript 프레임워크에 대한 지식에만 집중할 수 있습니다. 옳든 그르든 많은 직업에서 이러한 현실이 적용됩니다.

몇 가지 JavaScript 라이브러리를 알고 있으면 채용 지원에 도움이 되지만, 다른 지원자와 차별화되는 데 도움이 될지는 장담할 수 없습니다. 몇 가지 인기 있는 JavaScript 프레임워크를 잘 알고 있다면 현재 웹 개발자 구인 시장에서 이러한 지식을 유리하게 생각하는 고용주가 있을 수 있습니다. 일부 대기업 조직은 매우 오래된 JavaScript 프레임워크를 사용하고 있으며 이러한 프레임워크에 익숙한 지원자를 절실히 찾고 있을 수도 있습니다.

이 공개 비밀을 유용하게 사용할 수 있습니다. 하지만 다음과 같은 고려사항을 염두에 두고 신중하게 취업 시장에 접근하세요.

커리어에서 하나의 프레임워크만 사용하면 더 현대적인 다른 프레임워크를 학습할 기회를 놓칠 수 있습니다.
소프트웨어 개발이나 웹 개발의 기초를 확실히 이해하지 못하지만 프레임워크 개발자로 고용된 개발자를 생각해 보세요. 이러한 개발자는 효과적인 코드를 작성하지 않으며, 이러한 코드베이스로 작업하는 것은 부담스러울 수 있습니다. 경우에 따라 이러한 시나리오가 번아웃으로 이어질 수 있습니다. 예를 들어 코드가 느려서 코드를 리팩터링하거나 코드의 성능을 조정해야 할 수 있습니다.
웹 개발을 학습할 때는 웹 개발, 소프트웨어 개발, 소프트웨어 공학의 기초에 중점을 두고 시작하는 것이 가장 좋습니다. 이러한 강력한 기반을 바탕으로 JavaScript 프레임워크를 빠르고 효과적으로 선택할 수 있습니다.

결론

JavaScript 프레임워크와 라이브러리를 비교하는 방법을 이해하기 위해 노력해 주셔서 감사합니다. 신규 프로젝트에서 작업하거나 컨설턴트로 활동하지 않는 한 프레임워크나 라이브러리를 자주 선택하지는 않습니다. 그러나 그러한 결정이 발생할 때 주제에 대한 더 많은 지식을 쌓을수록 더 나은 결정을 내리는 데 도움이 됩니다.

앞서 배운 것처럼 프레임워크 선택(경우에 따라 라이브러리 선택)은 개발 환경과 최종 사용자(예: 성능)에 상당한 영향을 미칠 수 있습니다.