JS 개발자를 위한 용어 정리: 모듈 vs 패키지 vs 라이브러리

 

들어가며

현업에서 자바스크립트 개발을 하다 보면 ‘모듈’, ‘패키지’, ‘라이브러리’라는 용어가 마치 같은 의미인 양 사용되는 경우가 많습니다! 예를 들어, 기능 단위를 분리한다는 의미로 ‘모듈’을, 배포 단위를 묶는다는 의미로 ‘패키지’를, 재사용 가능한 코드 집합이라는 의미로 ‘라이브러리’를 언급하지만, 서로 교차해 쓰이면서 실제 회의나 문서화 과정에서 혼선이 자주 발생합니다.

 

얼마 전 저희 팀에서 React-Native 도입 여부를 논의하던 회의에서도 같은 일이 벌어졌습니다..

• React 웹 개발자는 “이 기능은 모듈로 쪼개서 관리하면 좋겠습니다”라고 제안했고,
• Android 개발자는 “패키지는 이미 설치돼 있는데요?”라며 반문했으며,
• iOS 개발자는 “라이브러리 의존성이 겹치는 것 같습니다”라고 지적했습니다.

각자가 익숙한 맥락에서 용어를 사용했지만, 정작 모두가 동일한 개념을 떠올린 것은 아니었습니다. 그 결과 회의는 예상보다 길어졌고, 논의는 원점으로 되돌아갔습니다. 이처럼 용어 정의가 명확하지 않으면 협업 과정에서 소통 효율이 떨어지고, 불필요한 시간 낭비로 이어지기 쉽습니다.

 

따라서 이 글에서는

1. 일상적 의미와 타 산업군 사례를 통해 ‘모듈’, ‘패키지’, ‘라이브러리’의 기본 개념을 살펴보고,
2. 자바스크립트 생태계에 도입된 시기와 형태를 정리한 뒤,
3. 세 용어의 차이점을 명확히 한 다음,
4. 용어 혼동이 발생하는 원인을 분석해보겠습니다.

이번 글은 제가 공부하고 이해한 개념을 바탕으로 작성하였으며, 각 용어는 플랫폼·개발자·직군 별로 다르게 정의할 수 있습니다!

 

---

모듈

일상 속에서의 모듈이란?

기계적인 무언가?

 

일상에서 ‘모듈’이라 함은 독립적인 기능을 수행하면서도 필요에 따라 손쉽게 연결·분리할 수 있는 구성 요소를 뜻합니다. 예를 들어, 레고 블록은 각 블록이 고유한 형태와 기능을 지니되, 서로 결합하여 다양한 구조물을 완성할 수 있습니다. 가구 모듈화의 사례를 보더라도, 책장 한 칸 단위로 구매하여 원하는 대로 배열하거나 추가할 수 있다는 특징을 떠올릴 수 있습니다. 이처럼 모듈은 ‘전체 시스템을 이루는 최소 단위이면서도, 다른 단위와 유연하게 결합 가능한 부품’으로 이해할 수 있습니다.

 

타 산업군에서의 모듈이란?

‘모듈’ 개념은 소프트웨어를 넘어 다양한 산업군에서 널리 활용됩니다. 대표적인 사례 두 가지를 살펴보겠습니다.

• 자동차 산업의 모듈러 아키텍처
  • 현대 자동차 제조사들은 차체·파워트레인·인테리어·전장(전자장치) 등을 ‘모듈’ 단위로 설계합니다.
  • 예를 들어, 동일한 섀시(차대) 위에 서로 다른 엔진 모듈이나 인포테인먼트(AV) 모듈을 결합해 다양한 차종을 생산할 수 있습니다.
  • 이로 인해 생산 라인의 유연성이 높아지고, 부품 재사용률이 증가하며, 모델별 맞춤형 구성이 쉬워집니다.
• 공장 자동화 라인의 모듈화
  • 제조 공정에서는 ‘작업 스테이션’이나 ‘로봇 셀’이 하나의 모듈로 취급됩니다.
  • 각 모듈(용접 모듈, 페인팅 모듈, 조립 모듈 등)을 필요에 따라 배치하거나 제거함으로써 공정 변경 및 확장이 용이해집니다.
  • 예를 들어, 생산 제품이 변경될 때 전체 라인을 재구성할 필요 없이, 해당 모듈만 교체하거나 재배치하면 됩니다.

이처럼 물리적 ‘부품’이나 ‘공정 단위’에서도 모듈은 ‘독립성’과 ‘결합 가능성’을 동시에 지닌 최소 단위로 이해됩니다.

 

JS 생태계에서의 정의

자바스크립트 생태계에서 ‘모듈’은 코드의 재사용성과 유지보수성을 높이기 위해 도입된 독립 실행 단위를 말합니다. 대표적으로 다음 두 가지 사양이 널리 사용됩니다.

CommonJS (CJS)

• Node.js에서 채택된 모듈 방식으로, require() 함수로 다른 파일을 불러오고 module.exports 또는 exports 객체에 값을 할당해 모듈을 내보냅니다.
• 동기적으로 파일을 로드하기 때문에 서버 사이드 실행 환경에 적합하며, 파일 경로 기반으로 모듈을 해석합니다.

// utils.js
function sum(a, b) {
  return a + b;
}
module.exports = { sum };

// index.js
const { sum } = require('./utils');
console.log(sum(2, 3)); // 5

ECMAScript Module (ESM)

• ES6(ES2015) 표준에 추가된 모듈 방식으로, import/export 키워드를 사용해 정적 분석이 가능하고 트리 쉐이킹(tree shaking)을 통해 불필요한 코드를 제거할 수 있습니다.
• 브라우저와 Node.js(12.x 이상) 모두에서 네이티브로 지원되며, 비동기 로딩을 통해 성능 최적화가 가능합니다.

// math.js
export function multiply(a, b) {
  return a * b;
}

// app.js
import { multiply } from './math.js';
console.log(multiply(4, 5)); // 20

 

이외에도 AMD(Asynchronous Module Definition)나 UMD(Universal Module Definition) 같은 과도기적 사양이 있었으며, 번들러(Webpack, Rollup 등)는 이러한 모듈 사양을 통합·변환하여 다양한 환경에서 호환되도록 돕습니다.

 

자바스크립트에서는 모듈을 사용함으로써 코드 간 충돌을 방지하고, 각 기능 단위를 명확히 구분해 보다 견고한 애플리케이션 구조를 설계할 수 있습니다!

 

---

패키지

일상 속에서의 패키지란?

 

일상에서 ‘패키지(package)’라 함은 여러 개의 물품이나 요소를 하나로 묶어 보호·운반·보관하기 쉽게 만든 형태를 뜻합니다. 예를 들어, 쇼핑몰에서 구매한 여러 상품이 하나의 박스에 담겨 배송되는 모습이나, 선물 상자에 리본을 묶어 여러 가지 선물을 하나로 구성하는 경우를 떠올릴 수 있습니다. 이처럼 패키지는 ‘여러 개의 개별 품목을 하나의 단위로 포장한 묶음’으로 이해할 수 있으며, 내부 구성물을 외부 충격으로부터 보호하고, 분류·이동·관리의 편의성을 높여 줍니다.

 

또는 여행 패키지

 

타 산업군에서의 패키지란?

‘패키지’ 개념은 다양한 산업 분야에서 ‘묶음’과 ‘배포 단위’를 의미하며, 다음과 같은 사례로 확인할 수 있습니다.

• 물류택배 산업의 패키지
  • 여러 개의 제품을 하나의 박스나 팔레트에 포장하여 운송·보관하는 단위를 말합니다.
  • 예컨대, 이커머스 물류센터에서는 고객 주문에 따라 서로 다른 상품을 한 박스에 담아 패키징하고, 패키지 레이블로 목적지·무게·크기를 관리합니다.
  • 이를 통해 개별 상품을 일일이 취급하는 데서 오는 손실을 줄이고, 운송 효율성을 높일 수 있습니다.
• 소프트웨어 배포의 패키지
  • 운영체제나 플랫폼에서 설치 가능한 일련의 파일과 메타데이터를 묶은 형태를 뜻합니다.
  • 리눅스 환경에서는 .deb(Debian)나 .rpm(Red Hat) 패키지로 애플리케이션을 배포하며, 설치·업데이트·의존성 관리를 자동화합니다.
  • 윈도우에서는 설치 프로그램(Setup.exe)이나 MSI 패키지로, 모바일에서는 APK·IPA 파일이 패키지로 동작합니다.

이처럼 ‘패키지’는 “여러 요소를 한데 묶어 외부로 전달하거나 설치·보관·관리하기 용이한 단위”로 이해할 수 있습니다.

 

JS 생태계에서의 정의

자바스크립트 생태계에서 ‘패키지(package)’란, npm 또는 yarn 같은 패키지 매니저를 통해 등록, 배포, 설치되는 코드의 묶음을 의미합니다. 주요 특징은 다음과 같습니다.

• 메타데이터를 담은 package.json
• 패키지 이름(name), 버전(version), 진입점(main 혹은 module), 의존성(dependencies/devDependencies) 등을 기술하는 파일입니다.

{
  "name": "my-utils",
  "version": "1.0.0",
  "main": "index.js",
  "scripts": {
    "test": "jest"
  },
  "dependencies": {
    "lodash": "^4.17.21"
  },
  "devDependencies": {
    "jest": "^29.0.0"
  }
}

• 레지스트리와 퍼블리싱
  • 기본적으로 npm 레지스트리(registry.npmjs.org)에 공개되며, 사내 전용 레지스트리(예: Verdaccio, Nexus)에도 배포할 수 있습니다.
  • npm publish 명령어로 버전 단위의 패키지를 등록하며, 버전 관리에는 Semantic Versioning(SemVer) 규칙이 일반적으로 적용됩니다.
• 의존성 관리
  • dependencies에 등록된 패키지는 런타임 시 필요하고, devDependencies는 개발·테스트 도구로 사용됩니다.
  • 설치된 패키지는 node_modules 디렉터리에 트리 구조로 저장되며, 중첩된 의존성도 자동으로 해결해 줍니다.
• 범용성 & 호환성
  • 패키지 내부는 모듈 사양(CJS, ESM 등)과 트랜스파일 결과(Babel, TypeScript 등)에 따라 다양한 형태로 배포될 수 있습니다.
  • 번들러나 런타임이 해당 형식을 해석해 주기 때문에, 작성자는 표준 사양만 맞추면 됩니다.

이처럼 JS 패키지는 “코드와 메타데이터, 의존성 정보를 함께 묶어 공유·설치할 수 있는 단위”로 이해할 수 있습니다.

 

---

라이브러리

일상 속에서의 라이브러리란?

누가봐도 도서관

 

일상에서 ‘라이브러리(library)’라 하면, 특정 주제나 목적을 위해 체계적으로 모아 놓은 ‘참고 자료 집합’이라고 할 수 있습니다. 예를 들어:

• 도서관(Library) : 여러 종류의 책과 참고문헌을 주제별·분야별로 분류해 비치해 두고, 이용자가 필요할 때 꺼내 볼 수 있도록 한 공간입니다.
• 사전·백과사전 : 단어·용어의 정의, 개념, 예시 등을 모아 놓은 자료집으로, 언제든지 찾아보며 참고할 수 있다는 점에서 ‘라이브러리’의 본질을 잘 보여 줍니다.
• 공구 상자(Tool Library) : 여러 도구를 분류·보관해 놓고, 필요할 때 꺼내 쓰도록 한 개념 역시 ‘라이브러리’의 확장된 의미라고 할 수 있습니다.

이처럼 일상에서의 ‘라이브러리’는 “필요한 정보를 모아 두고, 언제든 꺼내서 참고·재사용할 수 있는 자료의 집합”이라는 특징을 지닙니다.

 

타 산업군에서의 라이브러리란?

‘라이브러리’ 개념은 소프트웨어를 넘어 다양한 분야에서 ‘참고·재사용 가능한 자산의 집합’으로 활용됩니다. 대표적인 사례를 살펴보면 다음과 같습니다.

• 공공 도서관(Physical Library)
  • 여러 주제의 책과 참고문헌을 주제별·분야별로 분류해 비치해 두고, 이용자가 필요할 때 꺼내 볼 수 있도록 한 공간입니다.
  • 대출·반납 시스템을 통해 버전 관리(발행판)와 접근 권한(회원 등급)을 운영합니다.
  • 디지털 아카이브(전자책 라이브러리)로 확장되면서 메타데이터(저자, 출판사, 키워드) 기반 검색·추천 기능을 제공합니다.
• 미디어 자산 라이브러리(Media Asset Library)
  • 사진·영상·음원·아이콘 등 다양한 미디어 파일을 중앙 저장소에 축적하여, 프로젝트별로 꺼내 써 먹을 수 있도록 한 시스템입니다.
  • 예: 방송사 스톡 영상 라이브러리, 음원 프로덕션의 사운드 이펙트 라이브러리
  • 태그·카테고리·저작권 정보 등을 메타데이터로 관리해 손쉽게 검색하고, 버전별로 자산을 추적합니다.
• 건축·엔지니어링 자재 라이브러리
  • 건축 설계·시공 시 반복적으로 쓰이는 벽돌·창호·기둥·부속품 등의 CAD 블록이나 재료 샘플을 모아둔 컬렉션입니다.
  • 설계자는 미리 정의된 모듈(블록)을 드래그&드롭해 빠르게 설계 초안을 완성합니다.
  • 자재별 규격·강도·가격 정보를 메타데이터로 연동해, 시공 계획과 예산 수립에 활용합니다.

이처럼 ‘라이브러리’는 “필요할 때 꺼내 참고·사용할 수 있도록 체계적으로 모아 둔 자산의 집합”이라는 공통된 특징을 지닙니다.

 

JS 생태계에서의 정의

자바스크립트 생태계에서 ‘라이브러리(library)’란, 특정 기능을 재사용 가능한 형태로 묶어놓은 코드 집합을 말합니다. 주요 특징은 다음과 같습니다.

• API 제공 중심
• 라이브러리는 문자열 처리, 날짜 계산, UI 렌더링 등 특정 영역의 기능을 함수나 클래스 형태로 제공합니다.
• 개발자는 import 또는 require로 라이브러리를 불러와, 라이브러리가 제공하는 API를 직접 호출하여 애플리케이션 로직을 구현합니다.

// lodash 라이브러리 활용 예
import _ from 'lodash';
const nums = [1, 2, 3, 4];
console.log(_.shuffle(nums)); // [2,4,1,3]처럼 무작위 순서 반환

• 배포 방식
  • 대부분 npm 레지스트리에 라이브러리 단위로 퍼블리시되며, package.json의 dependencies에 추가하여 설치합니다.
  • 하나의 ‘패키지’ 안에 여러 모듈 형식(CJS, ESM)을 포함할 수 있으며, 그중에서 라이브러리 API를 제공하는 부분이 핵심입니다.
• 대표적 예시
  • React: UI 컴포넌트 생성 및 렌더링 API를 제공하는 라이브러리
  • Lodash: 배열·객체·문자열 처리 유틸리티 함수 집합
  • Axios: HTTP 요청을 간편하게 수행하는 API 집합

이처럼 JS 라이브러리는 “개발자가 직접 호출해 쓰는, 특정 기능에 특화된 코드 묶음”으로 이해할 수 있습니다.

 

---

그래서 결국 뭐가 다른데?

 

지금까지 살펴본 ‘모듈’, ‘패키지’, ‘라이브러리’의 정의를 바탕으로 세 용어의 차이점을 정리해 보겠습니다.

 

모듈 vs 패키지

• 모듈(Module)
  • 독립된 기능 단위를 책임지는 코드 파일 혹은 파일 묶음입니다.
  • 코드 내부에서 import/require로 불러와 사용하며, 재사용성과 테스트 용이성에 초점을 맞춥니다.
• 패키지(Package)
  • 모듈이나 라이브러리, 리소스, 메타데이터(package.json)를 묶어 배포·설치할 수 있도록 만든 단위입니다.
  • npm/Yarn 같은 패키지 매니저를 통해 버전 관리와 의존성 해결이 자동으로 이뤄집니다.
• 차이점
  • 모듈은 “코드 분리·재사용의 최소 단위”라면, 패키지는 “그 모듈(들)을 설치·배포하기 위한 묶음 단위”입니다.

 

패키지 vs 라이브러리

• 패키지(Package)
  • 설치 가능한 형식적 단위로, package.json에 정의된 메타데이터를 포함합니다.
• 라이브러리(Library)
  • 특정 기능(API)을 제공하는 코드 집합체로, 개발자가 직접 호출해 사용합니다.
• 차이점
  • 패키지는 “배포·설치 단위”라는 물리적 형식에 가깝고, 라이브러리는 “기능 제공·재사용 단위”라는 논리적 의미에 가깝습니다.
  • 실제로 많은 라이브러리가 npm 패키지 형태로 배포되므로, 구분할 때는 ‘배포 형태(Package)’와 ‘기능 목적(Library)’을 나누어 생각하면 도움이 됩니다.

 

모듈 vs 라이브러리

• 모듈(Module)
  • 파일 단위로 책임을 쪼갠 코드 덩어리입니다. 예를 들어 math.js 파일에 add, subtract 함수를 정의했다면, 이것은 “모듈”입니다.
• 라이브러리 (Library)
  • 여러 모듈을 모아 놓은 “기능 묶음” 또는 “API 집합”입니다. 예컨대, math.js, string.js, date.js 같은 여러 유틸 모듈을 한 디렉터리에 모아서 utils라는 이름으로 관리하면, 개념적으로는 이미 작은 라이브러리라 볼 수 있습니다.
• 차이점
  • 모듈은 기능 한 조각이라면, 라이브러리는 그 조각들을 모아 주제별로 패키징한 덩어리입니다.
  • 라이브러리는 내부적으로 여러 모듈을 재배치·추상화해 단일 API 표면을 제공하지만, 모듈은 자체 API만 노출합니다.
  • 재사용 관점: 모듈은 앱 내부 재사용이 주 목적, 라이브러리는 내·외부 프로젝트 전반 재사용을 전제로 설계됩니다.

 

---

 

왜 혼동이 생길까?

모듈·패키지·라이브러리 용어가 혼용되는 배경에는 여러 가지 이유가 있습니다. 주요 원인을 정리해 보겠습니다.

 

플랫폼별 관점 차이

• 웹 개발(React 등) : 웹 개발자는 주로 ES 모듈이나 CommonJS 같은 코드 단위(파일) 수준의 분리를 ‘모듈’이라 정의합니다.
• Android 개발(Java/Kotlin) : Java/Kotlin에서는 com.foo.bar 같은 네임스페이스를 ‘패키지’라 부르고, 배포 시에는 동일 용어가 AAR(라이브러리 아카이브) 단위로도 사용됩니다.
• iOS 개발(Swift/Objective-C) : iOS에서는 CocoaPods/SPM 패키지 안에 .framework 혹은 .a 형식 라이브러리가 담겨 배포됩니다.

각 플랫폼마다 오래도록 사용해 온 용어 관습이 달라, 같은 단어가 전혀 다른 개념을 가리키면서 혼란이 발생합니다.

 

역사적·도구적 진화 관점

자바스크립트 생태계가 성장해 오면서, 각 단계의 도구와 표준이 서로 다른 용어를 사용해 왔기에 ‘모듈’, ‘패키지’, ‘라이브러리’가 자연스럽게 뒤섞이게 되었습니다.

• 초기 브라우저 환경: 글로벌 스크립트 (1995 ~ 2008)
  • <script src="…"> 태그로 여러 파일을 불러오면서 모든 코드는 전역(global) 네임스페이스를 공유했습니다.
  • 이 시기에 ‘모듈’이라는 개념은 없었고, 모두가 그냥 “스크립트 파일” 혹은 “라이브러리”라고 불렀습니다.
• Node.js와 CommonJS (2009)
  • 서버 사이드 JS가 부상하면서 require()·module.exports 방식이 표준처럼 굳어졌습니다.
  • Node 진영에선 “모듈”이라 하면 곧바로 CommonJS 단위(파일)로, “패키지”라 하면 package.json 기반의 배포 단위로 구분하게 되었습니다.
• AMD와 RequireJS (2010 ~ 2011)
  • 비동기 로딩을 위해 define()·require() 방식이 도입되며 ‘모듈’이라는 용어가 처음 쓰이기 시작했습니다.
  • 하지만 이때 ‘라이브러리’라 하면 여전히 jQuery·Lodash 같은 코드 묶음을 가리켰고, 패키지 배포 개념은 따로 없었습니다.
• npm 레지스트리의 확장 (2010 ~ 2014)
  • 2010년 npm 레지스트리가 공개되고, 2013 ~ 2014년 사이 패키지 수가 폭발적으로 늘었습니다.
  • 전 세계 개발자가 의존성을 공유하면서, ‘패키지(package)’라는 용어가 배포·버전 관리의 대명사가 되었습니다.
  • 이 시점부터 “라이브러리”는 주로 기능 제공 목적의 패키지를, “패키지”는 그 배포 단위를 의미하는 용어로 자리잡았습니다.
• 번들러와 트랜스파일러의 등장 (2012 ~ 2015)
  • Webpack (2012), Babel (2014), Rollup (2015) 등이 CJS·ESM·AMD를 모두 처리하면서, 개발자는 ‘모듈 포맷(module format)’과 ‘패키지 설정(package configuration)’을 동시에 다뤄야 했습니다.
  • 개발자는 모듈 포맷과 패키지 설정을 동시에 신경 써야 했고, 용어 혼선이 가속화됐습니다.
• ES 모듈 표준화 (2015)
  • 언어 사양 차원에서 import/export가 도입되면서, 브라우저·Node.js 간 모듈 개념이 통합되었습니다.
  • 그러나 “패키지” 필드를 읽어들이는 로더(loader)들이 다양하게 등장하면서, module·main·browser 등 메타데이터 해석 방식이 엇갈려 용어 혼선을 가중시켰습니다.
• 모노레포 & 워크스페이스
  • Lerna (2015), Yarn Workspaces (2017), pnpm Workspaces (2017) 등이 다수 패키지를 하나의 저장소에 관리하는 문화를 퍼뜨렸습니다.
  • 이 과정에서 ‘모듈’은 다시 “패키지 안의 작은 단위”로, ‘패키지’는 “모노레포 내 하나의 배포 단위”로 의미가 세분화되었습니다.
• Node.js 네이티브 ESM 지원 (2020)
  • Node.js 12 LTS(2020)부터 ESM이 안정적으로 지원되면서 서버·클라이언트 모두 동일한 모듈 사양을 사용할 수 있게 되었습니다.

이처럼 각 단계에서 도입된 도구와 표준이 조금씩 다른 용어를 정의해 왔기 때문에, 오늘날 개발자들은 문맥에 따라 같은 단어를 전혀 다른 개념으로 사용하게 된 것입니다.

 

다른 직군과 소통할 때

다른 직군(디자이너 또는 PM 등)은 모듈·패키지·라이브러리라는 단어를 ‘일상적 의미’로 받아들일 가능성이 높습니다. ‘모듈’이라고 하면 기계 부품처럼 기계적인 무언가를 떠올릴 것이고, ‘패키지’라 하면 여행 패키지/선물 패키지, ‘라이브러리’라 하면 도서관을 떠올릴 수 있습니다.

 

---

 

FAQ

package.json 이름은 왜 ‘package’인가?

package.json은 패키지(package) 단위로 코드와 메타데이터를 묶기 위한 설정 파일입니다. 과거 Node.js 생태계 초창기에 npm(Node Package Manager)이 “코드 묶음”을 패키지라고 정의하면서, 그 묶음의 속성을 기록하는 파일로 package.json이 자리잡았습니다.

 

dependencies에 적힌 건 라이브러리일까, 패키지일까?

dependencies 필드에는 설치할 대상을 패키지 단위로 등록합니다. 그 안에 실제로 담긴 것은 특정 기능을 제공하는 라이브러리(library) 일 수도 있고, 단순 모듈일 수도 있습니다.

 

즉, dependencies에는 배포·설치 단위인 패키지 이름이 적히며, 그 패키지 내부에 포함된 코드가 라이브러리나 모듈로 동작하는 구조입니다.

 

node_modules에 설치된 것은 라이브러리인가, 패키지인가?

node_modules 폴더에는 여러 패키지(package) 디렉터리가 위치합니다. 각 디렉터리(예: lodash/, react/)가 하나의 패키지 단위로 설치된 것이고, 그 안에 여러 개의 모듈과 라이브러리가 포함되어 있습니다.

 

따라서 node_modules에는 “라이브러리”나 “모듈”이 들어 있는 여러 패키지가 모여 있다고 이해할 수 있습니다.

 

React 프로젝트에 만든 shared/hooks 또는 shared/components는 모듈일까, 라이브러리일까?

shared/hooks와 shared/components는 프로젝트 내에서 특정 기능(훅, 컴포넌트)을 캡슐화한 모듈(module) 단위로 시작합니다.

그러나 이들을 별도의 배포·버전 관리 단위로 묶어 npm private registry나 mono-repo 방식으로 관리한다면, 라이브러리(library)로 간주할 수 있습니다.

 

퍼스트파티(first-party) 라이브러리란, 내 조직(또는 내 프로젝트)에서 직접 만들고 유지·관리하는 라이브러리를 의미하므로, 위 경우에는 퍼스트파티 라이브러리라고 부를 수 있습니다.

 

---

 

마치며

이번 글에서는 제가 공부하고 이해한 내용을 글로써 정리해보았습니다. 그러나 공부할수록 누구나 공유하는 명확한 정의는 존재하지 않는다는 느낌을 받았습니다. 따라서 이 정의가 옳다고 밀어붙이기보다는 대화의 맥락과 흐름 속에서 서로 같은 이미지를 그릴 수 있다면 더 효율적인 이야기를 할 수 있을 거라고 생각합니다!

저와 같은 경험을 했던 분들에게 이번 글이 도움이 되었으면 좋겠습니다 :)

 

---

 

참조

• https://www.npmjs.com/