[Frontend] 패키지 매니저

목차 (OPEN)

• 🖼️ 렌더링이란
• ⚙️ 브라우저의 렌더링 과정
• 💡 렌더링 방식의 세 가지 분류
• ⚖️ CSR vs SSR vs SSG 비교
• 🙄 어떤 방식을 선택해야 할까?
• 🔚 결론

 

 

 

📦 패키지 매니저란

프론트엔드 개발을 처음 시작할 때,

가장 먼저 접하게 되는 건

React와 axios, react-router 등과 같은

수많은 라이브러리들이다.

 

이러한 라이브러리들은 보통 아래와 같이

import 또는 require 구문으로 사용한다.

import React from 'react';
import {sum} from '@/utils';
const _ = require('lodash');

 

 

처음에는 단순히 "저 이름만 쓰면 가져다 쓸 수 있는 거구나 ~"하고 넘겼지만,

문득 "도대체 이 React는 어디서, 어떻게, 어떤 버전으로 가져오는 거지?" 하는 의문이 생기기 시작했다.

 

 

우리가 만약 위의 예시처럼

import React from 'react';라고만 쓰면,

Java Script는 입장에서는 아래와 같은 궁금증에 빠질 것이다.

 

🤔 'react'라는 건 어디에 있는 거지?

🤔 정확히 어떤 버전의 React를 불러오라는 거지?

🤔 React 내부에서 또다른 의존성을 쓰고 있으면, 그건 어디서 어떻게 가져와야 하지?

 

 

✅ 바로 이러한 질문들에 대한 답을 자동으로 내려주고,

✅ 필요한 파일들을 적절한 디렉토리에 정리해주며,

✅ 우리가 사용할 수 있도록 연결해주는 시스템이

패키지 매니저 (Package Manager)이다.

 

 

---

 

 

🔗 우리가 쓰는 코드와 실제 파일 경로의 차이

Java Script의 표준 명세인 ECMAScript에 따르면,

모듈을 import 할 때는 정확한 경로를 명시해야 한다고 한다.

 

예를 들면, 정말 표준대로 하면 아래와 같이 써야 한다.

import React from '/Users/myUser/node_modules/react/index.js';

 

하지만 이렇게 길고 하드코딩된 경로를 직접 쓰면

너무 불편하고, 유지보수도 지옥일 것이다 ....

그래서 현실에서는 대부분 아래처럼 심플하게 쓴다.

import React from 'react';

 

그리고, 이러한 심플한 코드를 이해해서

실제 물리적 경로로 매핑해주는 것이 패키지 매니저의 역할이다.

 

패키지 매니저는 우리가 'react'라고만 적어도,

그게 실제로는 node_modules/react/index.js에 있다는 것을 알아채고,

실제 물리적인 경로와 연결(mapping) 해준다.

 

🧾 정확한 버전 관리 (package.json)

우리는 단순히 React를 쓰기만 하면 되는 것이 아니라,

어떤 버전을 쓸 지 결정해야 한다.

 

왜냐하면 React 17과 React 18은 내부 동작이 다른 것처럼

버전이 다르면 버그가 생기거나 API 사용법이 달라질 수 있기 때문이다.

 

그래서 우리는 package.json 파일에

아래와 같이 의존성(Dependencies)과 버전 범위(Range)를 명시하게 된다.

 

{
  "dependencies": {
    "react": "^18.2.0",
    "lodash": "~4.17.21"
  }
}

 

여기서 의미하는 것은 아래와 같다.

1️⃣ "^18.2.0" 👉🏻 18.2.0 이상, 19.0.0 미만의 최산 버전이면 Ok

2️⃣ "~4.17.21" 👉🏻 4.17.x 중에서 4.17.21 이상이면 Ok

 

참고로,

 📌 ^ 👉🏻 마이너 버전까진 유연하게 허용

📌  ~ 👉🏻 패치 버전만 유연하게 허용

이라는 의미라고 한다.

 

아무튼 이렇게 애매한 범위로만 써놓아도

패키지 매니저는 알아서

💡 가능한 최신 버전을 찾고,

💡 공식 저장소에서 다운로드하고,

💡 그걸 node_modules에 설치한 후,

💡 우리가 import 했을 때 실제 파일을 연결해준다.

 

 

---

🤯 의존성의 의존성

여기서 끝이 아니라, 사실 진짜 중요한 포인트는 이 다음에 있다.

 

우리가 직접 사용하는 패키지 (ex. react) 만 설치하면 끝일까?

 

정답은 ❌

이런 패키지들 자체도 또 다른 패키지에 의존하고 있을 수도 있다.

 

아래와 같은 예시를 보자.

import { useOverlay } from '@/use-overlay';

 

dl @/user-overlay는 내부적으로 react에 의존한다.

그런데, react는 또 다른 라이브러리들 (ex. loose-envify 등)을 참조할 수 있을 것이다.

 

즉,

🧱 하나의 패키지를 설치하면 →
🔗 그 패키지가 필요로 하는 다른 패키지들을 찾아야 하고 →
🔗 또 그 의존성들이 필요로 하는 패키지까지 …

⛓️ 연쇄적으로 설치가 이루어져야 한다.

 

만약 이 과정을 사람 손으로 하나하나 설치하고 관리한다고 생각하면 끔직할 것이다 🙀

 

그래서 패키지 매니저가 전체 의존성 트리를 자동으로 파악하고,

필요한 버전들까지 한 번에 쭉 설치해주는 것이다.

 

그리고 이러한 복잡한 버전 정보들은

yarn.lock 또는 package-lock.json 같은 lock 파일에 정리되어 저장된다.

 

우리는 이 lock 파일 덕분에

모든 개발자가 동일한 환경에서 동일한 패키지를 사용할 수 있는 것이다.