📜 JavaScript의 모듈화와 npm의 등장 배경

1. JavaScript의 발전과 모듈화의 필요성

초기 JavaScript는 웹 페이지에 간단한 동적 기능을 추가하는 데 주로 사용되었습니다. 하지만 점차 웹 애플리케이션이 복잡해지고 규모가 커지면서 코드의 재사용성과 유지보수를 고려한 모듈화(Moduleization)가 중요한 요소로 떠올랐습니다.

기본적으로 JavaScript는 하나의 전역 스코프(Global Scope)에서 실행되므로, 여러 개발자가 협업할 때 전역 변수의 충돌 문제가 발생할 가능성이 높았습니다. 이를 해결하기 위해 다양한 모듈 시스템이 등장하게 되었습니다.

---

2. JavaScript 모듈 시스템의 발전 과정

🏛️ 1) IIFE (즉시 실행 함수 표현식)

모듈화의 초기 방식 중 하나는 즉시 실행 함수 표현식(IIFE, Immediately Invoked Function Expression)을 활용하는 것이었습니다. 이 방식은 전역 변수의 오염을 막기 위해 사용되었습니다.

(function() {
    var privateVariable = "이 변수는 외부에서 접근할 수 없습니다.";
    
    function privateFunction() {
        console.log("이 함수도 외부에서 호출할 수 없습니다.");
    }
})();

📌 문제점

• 모듈 간의 의존성을 해결하기 어렵고, 각 모듈을 직접 관리해야 하는 부담이 컸습니다.
• 재사용성과 유지보수가 어려웠습니다.

---

🏛️ 2) CommonJS (서버 사이드 JavaScript)

Node.js가 등장하면서 서버 환경에서도 JavaScript를 활용할 수 있게 되었고, 이에 맞는 모듈 시스템인 CommonJS가 도입되었습니다. CommonJS는 require와 module.exports를 사용하여 모듈을 불러오고 내보낼 수 있도록 설계되었습니다.

// 모듈 내보내기
module.exports = {
    sayHello: function() {
        console.log("Hello, CommonJS!");
    }
};

// 모듈 불러오기
const myModule = require('./myModule');
myModule.sayHello(); // Hello, CommonJS!

📌 문제점

• CommonJS는 동기적(Synchronous)으로 동작하므로, 브라우저 환경에서는 효율적으로 동작하지 않았습니다.

---

🏛️ 3) AMD (Asynchronous Module Definition)

CommonJS의 동기적 로딩 문제를 해결하기 위해, 브라우저 환경에서는 비동기적으로 모듈을 불러오는 AMD(Asynchronous Module Definition) 방식이 등장했습니다. 대표적으로 RequireJS가 사용되었습니다.

define(['moduleA', 'moduleB'], function(moduleA, moduleB) {
    moduleA.doSomething();
    moduleB.doSomething();
});

📌 문제점

• 코드가 복잡하고 가독성이 떨어졌습니다.
• CommonJS와 AMD가 서로 다른 방식으로 동작하여 호환성 문제가 발생했습니다.

---

🏛️ 4) ES6 모듈 (ECMAScript 2015)

2015년, ES6(ECMAScript 2015)에서 공식적인 모듈 시스템이 도입되었습니다. import와 export를 사용하여 모듈을 불러오고 내보낼 수 있으며, 최신 JavaScript 환경에서는 가장 권장되는 방식입니다.

// 모듈 내보내기
export function greet() {
    console.log("Hello, ES6 Modules!");
}

// 모듈 불러오기
import { greet } from './myModule.js';
greet(); // Hello, ES6 Modules!

✅ 장점

• 브라우저와 서버 모두에서 동작 가능
• 모듈 간 의존성 해결이 용이
• 코드의 가독성과 유지보수성 향상

---

3. npm(Node Package Manager)의 등장 배경

앞서 살펴본 모듈 시스템의 발전과 함께, JavaScript 프로젝트에서 다양한 외부 라이브러리를 사용하는 것이 일반화되었습니다. 그러나 기존에는 이러한 라이브러리를 직접 다운로드하여 프로젝트 폴더에 보관하고 관리해야 하는 불편함이 있었습니다.

<script src="https://code.jquery.com/jquery-3.6.0.min.js"></script>
<script src="lightbox.js"></script>
<script src="fancybox.js"></script>

이러한 방식에는 여러 가지 문제가 있었습니다.

• 라이브러리 간 버전 충돌: 특정 라이브러리는 jQuery 1.x를 요구하고, 다른 라이브러리는 jQuery 3.x를 요구하는 경우 충돌이 발생할 수 있었습니다.
• 파일 관리의 어려움: 각 라이브러리를 일일이 수동으로 다운로드하고 업데이트해야 했습니다.
• 의존성 문제: 특정 라이브러리가 다른 라이브러리에 의존하는 경우, 이를 수동으로 찾아서 설치해야 했습니다.

이를 해결하기 위해 2010년, npm(Node Package Manager)이 등장하였습니다.

---

4. npm의 주요 기능과 역할

📦 1) 패키지 설치 및 관리

npm을 사용하면 특정 라이브러리를 쉽게 설치할 수 있습니다.

npm install express

이 명령어를 실행하면 node_modules 폴더에 해당 패키지가 설치되고, package.json 파일에 추가되어 프로젝트의 의존성을 자동으로 관리할 수 있습니다.

---

📜 2) package.json을 통한 프로젝트 관리

package.json 파일은 프로젝트에서 사용하는 패키지 목록과 정보를 저장하는 역할을 합니다.

{
  "name": "my-project",
  "version": "1.0.0",
  "dependencies": {
    "express": "^4.17.1",
    "lodash": "^4.17.21"
  }
}

팀원들이 프로젝트를 다운로드한 후 한 줄만 입력하면 동일한 환경을 구축할 수 있습니다.

npm install

---

🚀 3) npm 스크립트를 통한 실행 자동화

npm은 반복적인 작업을 자동화할 수 있도록 scripts 섹션을 지원합니다.

"scripts": {
    "start": "node app.js",
    "test": "jest"
}

이제 애플리케이션을 실행할 때 다음 명령어만 입력하면 됩니다.

npm start

---

5. npm 이후의 발전: Yarn과 pnpm

npm의 등장 이후, 성능과 안정성을 개선하기 위한 다양한 패키지 관리 도구들이 등장했습니다.

• Yarn (2016년, Facebook 개발)
  npm보다 더 빠른 속도와 일관된 패키지 관리를 목표로 개발되었습니다.

  • 병렬 설치
  • 오프라인 캐시 기능

• pnpm
  디스크 공간을 절약하고 빠른 설치 속도를 제공하는 패키지 관리 도구입니다.

  • 동일한 패키지를 중복 저장하지 않음
  • 의존성 해결 최적화

이러한 도구들은 프로젝트의 특성과 요구 사항에 따라 선택적으로 활용할 수 있습니다.

---

🎯 결론: npm이 해결한 문제

문제점	npm 등장 이전	npm 등장 이후
패키지 설치	직접 다운로드	npm install 명령어로 간단하게 설치
의존성 관리	수동으로 관리	package.json을 통해 자동 관리
버전 충돌	각 개발자가 다른 버전 사용 가능	package-lock.json을 통해 동일한 버전 유지
실행 자동화	명령어를 직접 입력해야 함	npm 스크립트로 간소화

npm의 도입으로 JavaScript 개발 환경이 획기적으로 개선되었으며, 현재는 프론트엔드(React, Vue)와 백엔드(Node.js) 개발에서 필수적인 도구로 자리 잡았습니다.