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

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

Umar Hansa

이 문서에서는 클라이언트 측 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 템플릿 시스템을 사용하는 대신 특정 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 프레임워크에 관한 특정 지식에만 집중할 수 있습니다. 맞든 틀렸든, 이것은 많은 직업의 현실입니다.

몇 가지 JavaScript 라이브러리에 대해 알고 있어도 작업 애플리케이션에 해가 되지는 않지만, 이것이 차별화된다는 보장은 없습니다. 몇 가지 인기 있는 JavaScript 프레임워크를 잘 알고 있다면 고용주가 웹 개발자를 위한 현재의 취업 시장에서 이러한 지식을 긍정적으로 생각할 가능성이 높습니다. 일부 대기업의 조직은 매우 오래된 JavaScript 프레임워크에 갇혀 있으며 이러한 프레임워크에 익숙한 지원자를 절망할 수도 있습니다.

이 공개 비밀번호를 유용하게 사용할 수 있습니다. 그러나 다음 사항을 염두에 두고 주의 깊게 취업 시장에 접근하세요.

하나의 프레임워크만으로 커리어에 많은 시간을 할애하면 더 현대적인 다른 프레임워크를 사용한 학습 경험을 놓칠 수 있습니다.
소프트웨어 개발 또는 웹 개발 기초를 제대로 이해하지 못하지만 프레임워크 개발자로 채용된 개발자를 생각해 보세요. 이 개발자는 효과적인 코드를 작성하지 않으므로 이러한 코드베이스로 작업하는 것이 어렵거나 부담스러울 수 있습니다. 경우에 따라 이 시나리오는 번아웃으로 이어질 수 있습니다. 예를 들어 속도가 느리기 때문에 코드를 리팩터링하거나 코드를 성능을 조정해야 할 수 있습니다.
웹 개발을 학습할 때 가장 좋은 방법은 웹 개발, 소프트웨어 개발, 소프트웨어 엔지니어링의 기초에 중점을 두고 시작하는 것입니다. 이러한 견고한 기반은 JavaScript 프레임워크를 빠르고 효과적으로 선택하는 데 도움이 됩니다.

결론

JavaScript 프레임워크와 라이브러리의 비교 방식을 이해하는 데 수고하셨습니다. 새로운 개발 프로젝트를 진행하거나 컨설턴트로 활동하지 않는 이상 프레임워크나 라이브러리를 자주 선택하지 않습니다. 그러나 이러한 결정이 발생할 경우 해당 주제에 대한 지식이 많을수록 더 정확한 정보에 근거해 결정을 내릴 수 있습니다.

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