❓ useRef 를 사용하면 다시 렌더링이 되지 않는다는데 ❓ 왜 다시 렌더링이 안될까요 ?? ❓ 어떤 원리로 다시 렌더링이 안될까요 ?? ❓ useState와 어떤 차이점이 있길래 안될까요 ??

useRef란?

: useRef는 리액트 훅의 한 종류로, Ref는 reference(참조)의 줄임말이다

⬇️ 리엑트 공식문서에서의 정의

useRef 는 렌더링에 필요하지 않은 값을 참조할 수 있는 React Hook이다.

⇒ 컴포넌트가 특정 정보를 기억하도록 하고 싶지만 해당 정보가 새 렌더링을 촉발하지 않도록 하려는 경우 ref를 사용할 수 있다.

useRef를 이용하면 ? (장점)

• 특정한 DOM요소에 접근이 가능하며
• 불필요한 재렌더링을 하지 않는다

useRef 사용방법 및 useRef에 대해서 자세하게 !

컴포넌트의 최상위 레벨에서 useRef를 호출하여 ref를 선언한다.

import { useRef } from 'react';

function MyComponent() {
  const intervalRef = useRef(0); //initialValue에 초기값 넣어주면 된다.
  const inputRef = useRef(null);
  // ...

매개변수 initialValue: ref 객체의 current프로퍼티 초기 설정값이다.

여기에는 어떤 유형의 값이든 지정할 수 있다. 이 인자는 초기 렌더링 이후부터는 무시된다 !

*반환 값 *

useRef는 단일 프로퍼티를 가진 객체를 반환한다 !

• current: 처음에는 전달한 initialValue로 설정되고 나중에 다른 값으로 바꿀 수 있다
• ref 객체를 JSX 노드의 ref어트리뷰트로 React에 전달하면 React는 current프로퍼티를 설정합니다.

주의사항

출처 ⇒ 리액트 공식 문서

렌더링이 뭔데?

: 내부의 변수들이 담고 있는 기존에 저장한 값들이 초기화되고, 함수 로직이 재실행됨을 의미

React에서 상태(state)의 변경을 감지하면 자동으로 컴포넌트가 렌더링이 된다 !

하지만 위의 사진 같이 상태를 변경하는 것이 아닌 그저 값만 변경 했을 때에는

리엑트에서 감지 하지 않기 때문에 UI를 다시 그리지 않는다

⇒ 렌더링은 최초 한 번만 실행됨 ⇒ 따라서 처음 값인 0만 UI에 출력

렌더링이 될 때

위와 같이 useState를 사용해 상태(state)를 변경해주니

리렌더링이 일어나 UI가 계속해서 업데이트 되는 것을 볼 수 있다 !

콘솔 밀림 현상

> import { useState } from "react";
> import "./App.css";
> 
> function App() {
>   const [count, setCount] = useState(0);
> 
>   const clickCount = () => {
>     setCount((prev) => prev + 1);
>     console.log(count);
>   };
> 
>   return (
>     <div>
>       <p>{count}</p>
>       <button onClick={clickCount}>클릭</button>
>     </div>
>   );
> }
> 
> export default App;
> ```
> 이 코드를 실행시키면 
> ![](https://velog.velcdn.com/images/hour_2/post/17899f03-76de-45b1-b9e3-60e7404a28cb/image.png)
> 이런식으로 UI에는 6이 찍히는데 console에는 5가 찍힌다.
> 왜 이렇게 콘솔 밀림 현상이 생기는 걸까?! 라는 궁금증에
> 한번 알아보았다 !
> 먼저 useState의 **`setState`**는 (위의 코드애서는 **`setCount`**) 비동기적으로 작동한다 !
> ```js
> setCount((prev) => prev + 1);
>     console.log(count);  // 여기서 찍히는 count는 > 아직 "업데이트 전" 값
> ```
> 여기에서 setCount를 호출해도 바로 count 값이 변경되지 않는다 ..
> 
> React는 상태 업데이트를 **비동기적으로 처리**해서 렌더링을 <최적 타이밍에 한 번에> 수행하려고 한다.
>
> 그래서 `console.log(count)`는 이전 렌더링의 `count` 값을 출력
> 
> 흐름을 정리해서 말해보자면
> 1. 버튼을 클릭해서 clickCount 함수 실행
> 2. React가 상태 변경 예약 → 이후 렌더링 스케쥴링
> 3. 렌더링 완료되면 count 값이 새로 반영됨

### 상태랑 값 ? 무슨 차이인데 ?

여기서 상태와 값을 혼동할 수 있는데 밑에 간단하게 표로 정리했다

| 용어 | 설명 |
| --- | --- |
| 값 (value) | 변수에 저장된 
일반적인 값 |
| 상태 (state) | React가 추적하고 관리하는 값 |

<br/>

| 항목 | 일반 값 (let, const, var) | 상태 (useState, this.setState) |
| --- | --- | --- |
| 누가 관리 ? | 개발자가 직접 | React가 
내부적으로 관리 |
| 값이 바뀌면 ? | 그냥 **메모리**만 바뀜 | React가 감지해서 **리렌더링 발생** |
| React 추적 | 감지 X | 감지해서 
화면 업데이트 |

여기서 잠깐 ! 리렌더링이 언제 일어나는지도 알아보자 !!

### 리렌더링은 언제 실행될까 ?

> - 자신의 state가 변경될 때
- 부모 컴포넌트에서 전달받은 props가 변경될 때
- 부모 컴포넌트가 리렌더링될 때 (자식에게 변경된 props가 없어도)


사실 리렌더링은 React 컴포넌트가 화면에 변경 사항을 반영하기 위해 반드시 필요한 과정이다. 

그러나 모든 리렌더링이 **의미 있는** 업데이트로 이어지는 것은 아니기 때문에

**불필요한 리렌더링을 줄이는 최적화**가 중요하다

<br/>


**불필요한 렌더링은 피해야 하는데 ..**

상태(state)를 변경하면 자동으로 컴포넌트가 렌더링되는데

**`함수형 컴포넌트`**는 함수 그 자체이기 때문에 리렌더링이 일어나게 되면 함수가 다시 불러와져서

내부에 있는 모든 변수들이 초기화가 된다.  

⇒ 따라서 원하지 않는 렌더링 때문에 곤란해질 때가 있다

> **그래서 useRef를 언제 사용하는거야 ?**
**`useRef`**는 위와 같이 다시 렌더링하지 않고 변경 가능한 값을 저장하고 싶을 때 사용한다 !
> 
> 예를 들어, DOM 요소에 직접 접근하거나 이전 값을 기억하거나 렌더링과 > 상관없는 내부 상태를 저장할 때 유용하다
> 
> 이런 특성 덕분에 `useRef`는 불필요한 리렌더링을 피하면서도 값은 유지할 수 있는 훌륭한 도구가 된다.


### useRef 동작 원리

앞선 위의 내용을 이해했다면 useRef는 충분히 이해할 수 있다

![](https://velog.velcdn.com/images/hour_2/post/a321080b-5a9f-480f-90af-dc9a3cb2192f/image.png)

먼저 useRef를 할당한 ref를 콘솔로 출력해보면

![](https://velog.velcdn.com/images/hour_2/post/526b7b7e-92ca-4ee9-b0ff-2d0ff04ad0e4/image.png)

이렇게 객체의 current라는 프로퍼티(props)를 통해 ref의 current 값에 접근할 수 있다.

```js
import { useRef } from 'react';

export default function Counter() {
  let ref = useRef(0);

  function handleClick() {
    ref.current = ref.current + 1;
    alert('You clicked ' + ref.current + ' times!');
  }

  return (
    <button onClick={handleClick}>
      Click me!
    </button>
  );
}

이것은 값 자체를 변경한다 !! ➡️  ref.current = ref.current + 1;

useRef는 위에 작성한 예시처럼 ref.current = ... 처럼 읽고 쓰는 것이 자유롭고 의도적으로 값을 변경할 수 있다. 리액트가 추적하지 않는다 !

const myRef = useRef("hi");
// myRef = { current: "hi" } => 객체의 형태로 출력됨

앞에서 언급한 것처럼 useRef로 만든 값은 단순한 일반 자바스크립트 객체이다.

따라서 React는 이 객체 안에서 어떤 일이 일어나는지 관찰하지 않기 때문에

리액트 사용자가 언제 변경했는지 모른다 !

이것이 useRef가 값이 변경되어도 리렌더링 되지 않는 이유 !!

즉 useRef는 상태를 변경하는 것이 아닌 값을 보관하고 변경하는 것이기 때문에 react는 이 컴포넌트를 다시 그려야겠다는 판단을 하지 X

다시 흐름을 정리를 하자면

• useRef는 상태를 변경하는 것이 아닌 객체 안의 값을 변경
• useRef는 일반 JS 객체이므로 React가 변경을 감지하지 못해 리렌더링 X
• 값은 유지되지만 렌더링에 반영 X ⇒ UI에 반영 X

그렇다면 react는 어떻게 상태(state) 변경만 인지하고 리렌더링을 하고 직접 한 값 변경은 인지를 못하는 걸까?

useRef를 사용하면 메모리에 어떻게 저장되길래 ?

위에서 봤던 것처럼 useRef()는 일반적익 JS(자바스크릡트) 객체이다

일반적인 프로그래밍 언어와 같이 자바스크립트 역시 heap 영역과 stack 영역에서 메모리를 관리한다.

heap 영역과 stack 영역에서 메모리가 어떻게 관리되는지 간단하게 알아보자

자바스크립트에서 변수들의 메모리 위치는?

• 기본형 데이터(숫자, 문자열 등)는 주로 스택에 저장
• 객체, 배열, 함수 등 참조형 데이터는 힙에 저장
• 변수에 객체가 할당되면, 변수에는 힙에 저장된 객체를 가리키는 주소만 스택에 저장

즉, useRef를 통해 저장된 값들은 heap 영역에 저장된다 !

useRef가 리렌더링이 일어나지 않는 이유 단계적으로 설명하자면

1️⃣ useRef는 heap영역에 저장 ! 2️⃣ heap 영역에 있기때문에 어플리케이션 종료까지 같은 메모리 값을 유지 3️⃣ 그러다 보니 useRef로 관리하는 값이 변경되어도 동일 메모리 주소를 유지 4️⃣ 얕은 비교를 하는 React의 리렌더링 감지에서는 '===' 연산이 항상 true를 반환 5️⃣ 변경사항 감지가 되지 않아 리렌더링 X

useRef를 정확히 어느 상황일 때 사용하면 좋을까 ?

1. 입력창에 focus 주기 (DOM 접근)

React에서 컴포넌트가 마운트되자마자 특정 입력창에 자동으로 focus를 주고 싶을 때 useRef를 사용하면 DOM에 직접 접근

import { useEffect, useRef } from "react";

function App() {
  const idInputRef = useRef<HTMLInputElement>(null);

  useEffect(() => {
    idInputRef.current?.focus(); // 컴포넌트 마운트 시 포커스
  }, []);

  return (
    <div>
      <input ref={idInputRef} placeholder="아이디" />
    </div>
  );
};

2. 로그인 할 때 아이디 값 관리하기

로그인 시 아이디 값을 임시로 저장만 하고 싶고 화면에 보여줄 필요는 없을 때 useState보다 useRef가 적절 !

import { useRef } from "react";

const LoginForm = () => {
  const idRef = useRef("");

  const handleChange = (e) => {
    idRef.current = e.target.value;
  };

  const handleLogin = () => {
    console.log("입력된 아이디:", idRef.current);
  };

  return (
    <div>
      <input placeholder="아이디" onChange={handleChange} />
      <button onClick={handleLogin}>로그인</button>
    </div>
  );
};

재밌는 사실 !

사실 useRef는 React에서 내부적으로 useState를 통해서 구현될 수 있다는 사실 !!

function useRef(initialValue) {
const [ref, _] = useState({ current: initialValue });
return ref;
}

> 초기 렌더링 시 **`useState`**로 `{ current: initialValue }` 객체를 생성하고
> 
> 그 객체를 **그대로 반환**한다.
> 
>  이 객체는 렌더링이 반복되어도 항상 동일한 참조값을 반환하기 때문에
> 
> 컴포넌트가 리렌더링되어도 객체 내부 값은 유지 !
> 
> ### 왜 setter가 필요 없을까?
> 
> `useState`는 값이 바뀌면 리렌더링을 유도하기 위해 `setState`를 제공한다.
> 
> 하지만 `useRef`는 반환된 객체를 **직접 수정**하므로 `setState`와 같은 setter가 필요 없다 !
> 
```jsx
ref.current = "새로운 값";

이렇게 값을 직접 바꾸더라도 리렌더링은 발생하지 X !

마무리

항상 개발을 할때는 정확한 원리를 이해하고 왜 그렇게 동작하는지를 알아가면서 개발하자 !

따라서 오늘은 리액트를 공부하기 이전에 꼭!!! 필요한 JS 개념에 대해서 알아보려고 한다.

💡 자바스크립트의 동등 비교

데이터 타입

원시타입

• boolean
• null
• undefined
• number
• string
• symbol
• bigint

객체타입

• object

null & undefined의 차이점 ?

undefined: 선언한 후 값을 할당하지 않은 변수 또는 값이 주어지지 않은 인수에 자동으로 할당되는 값

null: 아직 값이 없거나 비어 있는 값을 표현할 때 사용

생성방식

let a;
console.log(a); // undefined (값이 할당되지 않음)

let b = null;
console.log(b); // null (명시적으로 '비어 있음'을 표현)

• undefined는 변수가 선언되었지만 값이 전혀 지정되지 않았을 때 자동으로 할당됨.
• null은 개발자가 명시적으로 비어 있음을 표현하기 위해 직접 할당함.

동등성 비교

undefined == null;  // true  (값이 없다는 의미로 느슨하게 같음)
undefined === null; // false (타입이 다름)

• 느슨한 비교(==)에서는 “없음”이라는 공통점 때문에 true.
• 엄격한 비교(===)에서는 타입이 다르기 때문에 false.

JSON 직렬화 시 차이

JSON.stringify({ a: undefined, b: null }); 
// '{"b":null}'

• undefined 프로퍼티는 제외됨.
• null은 그대로 포함됨 → “의도적 비어 있음”으로 간주.

타입 비교

typeof undefined; // "undefined"
typeof null;      // "object"

• undefined는 고유 타입.
• null은 역사적 이유로 "object"를 반환하지만, 실제로는 원시 타입(primitive).

null의 특별한 점! => null의 type을 확인하면 object라는 결과가 나온다 !

typeof null === 'object' 는 자바스크립트 초기 버전의 비트 기반 타입 태그 설계에서 비롯된 버그로 null이 객체 타입 + null 포인터로 표현되었기 때문에 발생한다. 이는 현재로써 해결할 수 있는 기술이지만 이 문제가 수정되면 기존 코드에 부정적인 영향을 미칠 수 있기 때문에 오늘날까지 유지되고 있는 버그이다.

undefined와 null의 차이점을 한 줄로 설명하자면, undefined는 선언됐지만 할당되지 않은 값이고, null은 명시적으로 비어 있음을 나타내는 값으로 사용하는 것이 일반적이다.

값 저장 방식의 차이

원시 타입

let hello = ’hello world'
let hi = 'hello world’

console.log(hello === hi) // true

• hi와 hello 값을 비교하면 true가 나온다 ? => 정답

객체 타입

// 다음 객체는 완벽하게 동일한 내용을 가지고 있다.
var hello = {
greet: 'hello, world',
}

var hi = {
greet: 'hello, world',
}
// 그러나 동등 비교를 하면 false가 나온다.
console.log(hello === hi) // false
// 원시값인 내부 속성값을 비교하면 동일하다.
console.log(hello.greet === hi.greet) // true

• 완벽하게 동일한 내용을 가지고 있는 객체 hello와 hi를 비교하면 true가 나온다 ? => 오답 ㅜ

왜 객체는 객체 안에 동일한 값을 가지고 있어도 값을 비교하면 false이 나올까?

• 원시 타입은 불변 형태의 값을 저장하고 이 값은 변수 할당 시점에 메모리 영역을 차지하고 저장
• 객체는 값을 저장하는 게 아니라 참조를 저장하기 때문에 앞서 동일하게 선언했던 객체라 하더라도 저장하는 순간 다른 참조를 바라보기 때문에 false를 반환 !!

값을 복사한다면 ?

var hello = {
greet: ’hello, world',
}

var hi = hello
console.log(hi === hello) // true

• var hi = hello 를 실행하면 객체의 값이 아니라 “주소”가 복사되기 때문에 true !

Object.js

==, === 와는 또다른 리액트에서 제공하는 비교 방법

사용방법

-0 === +0 // true
Object.is(-0, +0) // false

Number.NaN === NaN // false
Object.is(Number.NaN, NaN) //true

NaN === 0 / 0 // false
Object.is(NaN, 0/0) //true

• ==, === 만으로는 정확하게 구별하지 못하는 특이한 케이스를 비교하기 위해 만들어짐

하지만 객체 비교에서는 여전히 참조(주소) 비교를 하기에 개발자가 의도한대로 원할한 비교가 되지 않는다 ㅜ

Object.is({}, {}) // false

shallowEqual

Object.js의 객체 비교 문제를 해결하기 위한 얕은 비교 함수

function shallowEqual(objA, objB) {
  // 1. Object.is로 먼저 완전 동일한지 비교
  if (is(objA, objB)) return true;

  // 2. 둘 중 하나라도 객체가 아니면 false
  if (typeof objA !== 'object' || objA === null ||
      typeof objB !== 'object' || objB === null) return false;

  // 3. 키 배열 길이가 다르면 false
  const keysA = Object.keys(objA);
  const keysB = Object.keys(objB);
  if (keysA.length !== keysB.length) return false;

  // 4. 같은 키를 순회하며 Object.is로 각 값 비교
  for (let key of keysA) {
    if (!objB.hasOwnProperty(key) || !is(objA[key], objB[key])) return false;
  }

  return true;
}

• shallowEqual은 객체의 1 depth(첫 번째 깊이) 까지는 값을 비교

얕은 비교의 한계

리액트에서는 props가 대부분 단순한 값(문자열, 숫자) 이라서 1 depth까지만 비교해도 대부분 충분하지만 깊은 객체에서는 문제가 생긴다.

const Component = memo((props) => {
  console.log("렌더링됨");
  return <h1>{props.counter}</h1>;
});

const DeeperComponent = memo((props) => {
  console.log("렌더링됨");
  return <h1>{props.counter.counter}</h1>;
});

<Component counter={100} />
<DeeperComponent counter={{ counter: 100 }} />

• 첫 번째 Component는 counter가 원시값이므로 비교 가능 → memo가 잘 작동함

• 두 번째 DeeperComponent는 counter가 객체라서 매 렌더링마다 { counter: 100 }이 새로 생성됨 → 참조가 달라짐 → shallowEqual에서 false

=> 즉, 내부 값은 같지만 객체의 참조가 바뀌어 memo가 무효

근데도 깊은 비교가 아닌 얕은 비교를 하는 이유?

성능의 문제점 객체 안에 객체가 몇 개 들어있을지 모르기 때문에 재귀로 비교하다 보면 렌더링마다 모든 값 전체를 순회해야 한다.

그래서 리액트는 얕은 비교까지만 지원하고 더 깊은 구조를 비교해야 할 땐 개발자가 직접 useMemo, useCallback 등으로 불필요한 객체 생성이나 참조 변경을 막아야 한다.

💡 함수

함수를 정의하는 4가지 방법

1. 함수 선언문

hello();  // "hi"
function hello(){ console.log("hi"); }

• 함수 자체가 호이스팅 됨 => 선언이 스코프 맨 위로 끌어올려져 선언 전 호출 가능.

2. 함수 표현식

console.log(typeof hello); // "undefined"
hello();                   // TypeError
var hello = function(){};

• 변수에 함수를 할당
• 호이스팅은 변수 hello만 됨 !

3. Function 생성자

const add = new Function('a', 'b', 'return a + b');

• 매개변수/본문을 문자열로 작성 → 가독성·성능·보안 불리
• 클로저가 안 생김

4. 화살표 함수

add() //error
const add = (a, b) => a + b;

• 호이스팅 X
• this 바인딩 없음 → 상위 스코프의 this를 캡처(렉시컬 this).
• arguments 없음 → ...rest 사용.
• new로 생성자 호출 불가, prototype 없음.
• 메서드로 쓸 땐 일반 함수 권장(특히 클래스/객체 메서드).

클래스나 객체 메서드 내부에서는 화살표 함수 대신 일반 함수를 쓰기

선언문과 표현식의 차이

선언문과 표현식의 가장 크고 중요한 차이는 바로 호이스팅 !!

호이스팅이 뭔데 ?

MDN 공식문서에서 말하는 호이스팅이란

인터프리터가 코드를 실행하기 전에 함수, 변수, 클래스 또는 임포트(import)의 선언문을 해당 범위의 맨 위로 끌어올리는 것처럼 보이는 현상

즉 함수 선언문이 마치 코드 맨 앞단에 작성된 것처럼 작동하는 현상을 의미한다.

선언문

hello() // hello

function hello() {
console.log('hello')
}

hello() // hello

위의 코드를 보면 함수 선언문 전에 hello() 함수를 실행해도 함수가 잘 실행되는 걸 볼 수 있다. 어떻게 이런일이 일어날 수 있는걸까?

바로 호이스팅이 일어났기 때문이다.

function hello() {
console.log('hello')
}

hello() // hello

hello() // hello

이런식으로 함수 표현식은 위로 끌어올려진 것처럼 작동한다.

실제 호이스팅이 일어나는 이유는 함수 자체가 미리 메모리에 등록하기 때문이다. 따라서 선언 전에 호출이 가능한 것 !

표현식

console.log(typeof hello === 'undefined') // true

hello() // Uncaught TypeError: hello is not a function

var hello = function () {
console.log('hello')
}

hello() // hello

함수 표현식은 함수 선언문과 다르게 정상적으로 호출되지 않고 undefined로 남아있는 것을 볼 수 있다.

//var hello;  // 선언만 호이스팅되어 undefined로 초기화됨

hello; // undefind => 식별자는 이미 존재함 (위로 호이스팅 되었기에)
hello(); // 함수 호출 불가 => hello가 아직 undefined 상태이기 때문

var hello = function () {
console.log('hello')
}

hello(); //hello

함수 표현식은 호이스팅이 일어나지 않는 걸 볼 수 있다. 함수와 다르게 변수는 런타임 이전에 undefined로 초기화되고 할당문이 실행되는 시점, 즉 런타임 시점에 함수가 할당되어 작동하기 때문이다.

좋은 함수 작성 원칙

함수의 부수 효과 최소화

함수의 부수 효과란

함수 내의 작동으로 인해 함수가 아닌 함수 외부에 영향을 끼치는 것을 의 미

이러한 부수 효과가 없는 함수를 순수 함수라 하고 부수 효과가 존재하는 함수를 비순수 함수라고 한다.

부수효과들

부수 효과를 완전히 없앨 수는 없고 제한된 곳에서만 안전하게 처리해야 한다는 게 핵심 !

리액트에서 부수 효과를 다루는 법 → useEffect

리액트는 useEffect를 통해 이런 부수 효과를 제어된 방식으로 실행

function Example({ userId }) {
  const [data, setData] = useState(null);

  // 외부 요청(부수 효과)은 useEffect 내부에서만 수행
  useEffect(() => {
    fetch(`/api/user/${userId}`)
      .then(res => res.json())
      .then(setData);
  }, [userId]);

  return <div>{data?.name}</div>;
}

핵심 포인트:

• 렌더링은 순수하게 유지
• 외부 동작(데이터 요청 등)은 useEffect 내부에서만 수행
• 이렇게 하면 렌더링 로직과 부수 효과 로직이 명확히 분리

하지만 useEffect는 DOM을 생성 후 paint 이후에 동작하기 때문에 렌더링에 영향을 주는 로직에서는 사용하면 X !!

위와 같이 렌더링에 영향을 안주고 외부 세계에 영향을 주거나 의존하는 코드를 처리할 때만 사용해야한다.

부수 효과를 최소화해야하는 이유

가능한 한 함수를 작게 만들기

함수는 한 가지 일만 해야 한다. 한 함수에 여러 기능들이 존재한다면 유지보수성도 어렵고 가독성도 좋지 않고 재사용에 있어서도 좋지 않다.

따라서 단일책임 원칙을 따라야 한다.

ESLint의 max-lines-per-function 규칙은 하나의 함수가 너무 길면 경고를 띄워라라는 규칙이다.

"max-lines-per-function": ["warn", { "max": 50 }]

기본 ESLint 규칙에 있을 정도로 생각하면서 작성해야 할 부분이다.

함수 길이의 적당함 ?

상황에 따라 다르지만, 짧을수록 좋다

하지만 실무에서는 보통 20줄 이내면 읽기 편하고 10줄 내외면 가장 이상적이다.

하지만 한 함수에 하나의 기능을 하지만 코드가 길어질 수 있기 때문에 무조건 짧아야 한다는건 잘못된 생각이다 !!

나쁜 예시

function processOrder(order) {
  if (!order.user) return;
  if (!order.items.length) return;

  // 재고 확인
  for (const item of order.items) {
    if (item.stock === 0) return;
  }

  // 결제 처리
  const result = pay(order.total);
  if (!result.success) return;

  // 알림 전송
  sendEmail(order.user.email);
  sendSMS(order.user.phone);
}

좋은 예시

function validateOrder(order) { /* ... */ }
function checkStock(items) { /* ... */ }
function processPayment(order) { /* ... */ }
function notifyUser(user) { /* ... */ }

function processOrder(order) {
  if (!validateOrder(order)) return;
  if (!checkStock(order.items)) return;
  if (!processPayment(order)) return;
  notifyUser(order.user);
}

누구나 이해할 수 있는 함수명

작은 프로젝트는 코드의 양이 적고, 작성자 본인만 이해하면 충분하기 때문에 temp, data, result 같은 이름을 써도 큰 문제가 없다. 하지만 프로젝트가 커지고 기능이 복잡해지며 여러 사람이 함께 작업하게 되면 이름이 불분명한 변수나 함수는 가독성을 떨어뜨리고 유지보수를 어렵게 만든다.

좋은 네이밍의 조건

이름만 보고 역할이 드러나는 코드

// ❌ 나쁜 예
function processData(a, b) {
  return a * b;
}

// ✅ 좋은 예
function calculateInsuranceFee(insurance, years) {
  return insurance * years;
}

좋은 이름을 짓기 위한 세 가지 원칙

// ✅ 좋은 패턴
handleSubmit();     // 동작 수행
fetchUserData();    // 외부 요청
calculatePrice();   // 계산
getUserInfo();      // 반환

💡 클로저

리액트에서 함수 컴포넌트와 훅이 등장한 16.8 버전을 기점으로 이 클로저라는 개념이 리액트에서 적극적으로 사용되기 시작하면서 클로저를 빼놓고서는 리액트가 어떤 식으로 작동하는지 이해할 수 없다.

클로저의 정의

MDN 공식문서에서 말하는 클로저 정의

함수와 함수가 선언된 어휘적 환경(Lexical Scope)의 조합

렉시컬 스코프 (어휘적 환경)

스코프: 변수의 유효 범위

function add() {
  const a = 10
  function innerAdd() {
    const b = 20
    console.log(a + b)
  }
  innerAdd() // 30
}

add()

• a 변수의 유효 범위는 add 전체
• b 변수의 유효 범위는 innderAdd 전체 => innerAdd는 add 내부에서 선언돼 있어 a를 사용 가능!

즉 렉시컬 스코프는 변수가 코드 내부에서 어디서 선언됐는지를 말하는 것

전역 스코프

전역스코프: 변수를 전역 레벨에 선언하는 것

var global = 'global scope'

function heUo() {
  console.log(global)
}
console.log(global) // global scope

hello() // global scope

console.log(global === window.global) // true

• global이라는 변수를 var와 함께 선언했더니 전역 스코프와 hello 스크프 모두에서 global 변수에 접근 가능

함수 스코프

자바스크립트는 기본적으로 함수 레벨 스코프를 따른다. 즉, {} 블록이 스코프 범위를 결정하지 X

if (true) {
  var global = 'global scope'
}

console.log(global) // 'global scope'
console.log(global === window.global) // true

• {} 내부에서 선언돼 있는데, {} 밖에서도 접근이 가능 => 기본적으로 자바스크립트는 함수 레벨 스코프를 가지고 있기 때문

function hello() {
  var local = 'local variable'
  console.log(local) // local variable
}

hello()
console.log(local) // Uncaught ReferenceError： local is not defined

• 단순한 if 블록과는 다르게 함수 블록 내부에서는 일반적으로 예측하는 것과 같이 스코프가 결정

리액트에서의 클로저

function Component() {
  const [count, setCount] = useState(0);

  function handleClick() {
    setCount((prev) => prev + 1);
  }
}

• 이때 useState는 한 번 실행되고 끝났는데 이후에 setCount는 어떻게 계속 최신 count 값을 알고 있을까? => 바로 클로저 때문

setCount 함수는 useState 내부에서 만들어질 때 count가 저장된 환경(Lexical Environment) 을 함께 기억한다.

그래서 나중에 setCount를 호출해도 useState 실행이 끝난 이후임에도 불구하고 그 당시의 state 변수에 접근할 수 있다.

즉, useState는 내부적으로 클로저를 이용한 상태 은닉 구조를 사용한다.

클로저 주의사항

클로저는 유용하지만 성능이나 메모리에 영향을 줄 수 있다.

1. 잘못된 스코프 바인딩

for (var i = 0; i < 5; i++) {
  setTimeout(function () {
    console.log(i);
  }, i * 1000);
}

의도: 1초 간격으로 0, 1, 2, 3, 4 출력 결과: 전부 5만 출력

이유:

• var는 함수 레벨 스코프라서 for 루프가 끝난 시점에는 전역 i = 5만 남음
• 각 setTimeout은 모두 같은 i(=5) 를 참조

2. 메모리 낭비

function heavyJobWithClosure() {
  const longArr = Array.from({ length: 10000000 }, (_, i) => i + 1);

  return function () {
    console.log(longArr.length);
  };
}

const innerFunc = heavyJobWithClosure();
button.addEventListener('click', innerFunc);

• innerFunc가 longArr를 클로저로 기억
• 브라우저는 longArr를 GC(가비지 컬렉션) 하지 못함

클로저의 단점 정리

따라서 본문에서는 두 도구를 살펴보기 전에 먼저 번들러의 개념과 등장 배경을 정리하고자 한다.

번들러란 무엇이고 왜 필요한가?

프론트엔드 내에서 번들러, 번들링이란 개념은 왜 생겼을까?

웹이 아주 단순하던 시절에는 번들링이 필요하지 않았다.

<script src="./index.js"></script>

위와 같은 한 줄의 코드면 브라우저가 ./index.js 하나의 파일을 받아서 실행했었다.

하지만 이건 웹이 단순했을 시절의 이야기이고, 현재는 이때와 다르다.

현재는 웹 서비스의 기능이 많아지고, 겹치는 공통 코드가 생기고, 여러 사람이 동시에 개발을 하고, 브라우저가 이해하지 못하는 TypeScript, jsx 등의 언어로 코드를 작성하고 있다.

그래서 우리는 자연스럽게 코드를 파일 단위로 쪼개고 모듈로 관리하기 시작했다. (import/export) 예를 들어 React 컴포넌트, util, API 클라이언트, hooks, 타입 정의 등 이런 것들을 전부 하나의 파일에 넣어두면 유지보수가 불가능하기에 기능별로 나눈 것이다.

하지만 최선의 해결 방법이 아니였다. 여기에서도 많은 문제들이 생겼다.

번들러가 등장하기 전에 존재했던 문제점

1. 파일이 너무 많아진다.

모듈을 잘게 나누는 것은 유지보수에 유리하지만 브라우저는 파일 하나를 받을 때마다 새로운 HTTP 요청을 수행해야 한다. 요청이 적으면 큰 문제가 되지 않지만 200개 이상의 모듈을 로드해야하는 상황이라면 성능 저하의 문제로 이어진다. 특히 HTTP/1.1 환경에서는 동시에 처리할 수 있는 요청의 수가 제한되어 있었기에 병목 현상이 심각했다. 이로 인해 개발은 모듈 단위로 / 배포는 묶어서 처리하는 도구가 필요했다.

2. 의존성 순서를 지켜야 한다

모듈 간의 의존성이 존재하는 경우, 불러오는 순서를 반드시 지켜야 한다. 예를 들어 A 모듈이 B를 사용하고 B가 C를 사용한다면, C-> B-> A 순서로 로드되어야 한다. 이러한 순서를 개발자가 <script> 태그를 통해 수동적으로 지정하는 것은 사실상 불가능에 가깝다. 따라서 의존 관계를 자동으로 분석하고 올바른 순서로 묶어주는 도구가 필요했다.

3. 브라우저가 모르는 문법을 쓰고 있다.

현제 프론트엔드 개발에서는 브라우저가 직접적으로 이해하지 못하는 다양한 문법과 언어가 사용된다.

• 최신 ESNext 문법(예: optional chaining, async/await 등)
• TypeScript
• jsx
• javaScript 코드 내에서 스타일을 불러오는 방식 (CSS-in-JS) 이러한 코드들은 브라우저가 그대로 이해할 수 없기 때문에 누군가가 이를 미리 변환해야 한다.

위의 문제들을 해결하기 위해 등장한 것이 바로 번들러이다.

다시 말해 번들러는 웹서비스가 방대해지며 코드를 분리한 모듈로 관리를 하기 위한 도구이다.

번들러의 핵심 아이디어

간단하게 3단계로 설명한다면 아래와 같이 설명할 수 있다.

• 내가 작성한 여러 개의 모듈 파일을
• 의존성 그래프를 따라가면서 하나씩 읽은 다음
• 브라우저가 바로 실행할 수 있는 형태로 묶어서(bundle) 내보내는 도구

위의 3단계를 더 자세하게 설명하자면

• 엔트리(entry) 파일을 정한다. (예시: src/main.tsx)

• 그 파일 안에서 import ... from ... 한 걸 전부 따라가면서 현재 이 프로젝트가 실제로 쓰고 있는 파일 목록을 전부 찾아낸다. 이걸 의존성 그래프(dependency graph) 를 만든다고 한다.

• 이후 브라우저가 이해할 수 있는 순서와 형식으로 재배치하고 하나(또는 여러 개)로 뭉친다.

• 이때 그냥 이어붙이는 게 아닌 아래의 과정을 거친다.

  • 최신 문법을 구버전으로 변환(transpile)
  • 쓰지 않는 코드를 제거(tree-shaking)
  • 변수 이름을 최소화(minify)
  • 소스맵을 만들어서 디버깅 가능하도록
  • CSS나 이미지 같은 리소스도 같이 처리할 수 있도록

즉 개발자 친화적인 코드 → 배포 친화적인 코드로 바꿔주는 변환 과정 전체를 수행한다.

지금은 Vite, Next.js, Remix 같은 프레임워크들이 이 번들 과정을 많이 감춰놓아서 우리가 매번 직접 webpack.config.js 를 쓰지 않아도 되지만 내부적으로는 여전히 의존성을 읽고, 변환하고, 묶어서 내보내는 작업이 돌아가고 있다. 이게 바로 번들러가 필요한 이유다.

번들러에는 여러가지 종류들이 있다.

나는 그 중에서 빠르고 최근에 사람들이 많이 사용 하는 esbuild를 알아볼 예정이다.

그 중 우리가 볼 번들러 esbuild

esbuild를 한 줄로 설명한다면 아래처럼 설명할 수 있다.

esbuild는 웹팩처럼 모든 것을 수행하는 거대한 플랫폼을 목표로 하는 게 아니라, JS/CSS를 빠르게 읽고 변환하고 묶는 그 핵심 부분을 최대한 빠르게 만든 도구다.

왜 esbuild가 빠른걸까?

esbuild의 공식문서에서는 각각의 요인은 단독으로는 미미한 성능 향상을 보이지만 이들이 모두 결합되었을 때 기존 번들러에 비해 수십 배에 달하는 속도 차이를 만들어낸다고 설명하고 있다.

그 중 주요하게 보면 좋을 4가지를 설명하겠다.

1. Go 언어로 작성된 esbuild

대부분의 기존 번들러는 Node.js 위에서 돌아가는 자바스크립트 프로그램이다. (ex=> webpack, Rollup, Parcel ...) 그러나 명령어 실행 후 종료되는 CLI 프로그램 특성상 JIT(Just-In-Time) 컴파일 방식을 사용하는 자바스크립트 언어는 이러한 환경에서 비효율적일 수밖에 없다. 번들러가 실행되는 순간 Node.js는 번들러의 자바스크립트 코드를 해석하는데 상당한 시간을 소비한다.

즉, 실제로 사용자의 코드를 번들링하기도 전에 런타임이 자신의 코드를 파싱하느라 리소스를 낭비하는 구조이다. 조금 더 쉽게 말하면 Node.js는 번들러 코드 자체를 해석하느라 시간이 많이 지체되느라 번들링이 시작도 안되고 있다는 이야기이다.

반면에 esbuild는 Go 언어로 작성되었기에 실행 가능한 바이너라 파일 형태로 컴파일되어 동작한다.

이로 인해 번들링을 시작하기 전 런타임이 자신의 코드를 해석하는 비용이 사실상 존재하지 않는다._ (바이너리 파일 → 이미 기계어로 되어 있어서 운영체제가 프로그램 실행 명령을 내리는 순간 곧바로 CPU가 코드 수행)_

즉 자바스크립트 기반 번들러는 매 실행 시 런타임 초기화 및 파싱 과정을 반복해야하지만, esbuild는 이러한 오버헤드를 Go 기반 네이티브 구조로 완전히 제거하는 것이다.

2. 병렬 처리를 위해 설계된 Go 언어

병렬 처리: 하나의 일을 여러 개의 CPU 코어가 동시에 나누어 처리하는 것

자바스크립트는 워커 스레드_(CPU가 동시에 여러 일을 수행할 수 있도록 하는 작업 단위)_를 통해 병렬 처리를 구현할 수는 있지만 esbuild가 사용하는 Go 언어의 벙렬 처리 모델은 근본적으로 구조가 다르다.

Go는 스레드 간 메모리 공유가 가능하며, 가비지 컬렉션 또한 단일 공유 힙에서 동작한다. 이로 인해 파싱, 코드 생성 등 CPU 집약적인 작업을 여러 스레드가 동시에 수행할 수 있다.

반면 자바스크립트는 워커 간 메모리를 공유하지 못하고 데이터를 직렬화하여 전달해야 하기 때문에 병렬성이 크게 제한된다. 즉, 병렬 처리를 지원하더라도 스레드 간 데이터 이동 비용이 발생하여 효율이 낮다.

esbuild는 이러한 Go의 구조적 장점을 최대한 활용한다. 전체 빌드 과정은 파싱 -> 링크 -> 코드 생성의 세 단계로 구분된다.

파싱과 코드 생성 단계는 병렬화가 용이하여 모든 CPU 코어를 적극적으로 활용한다. 링크 단계는 본질적으로 직렬 처리가 필요한 과정이므로 예외적으로 단일 스레드로 처리된다.

또한 여러 엔트리 포인트가 동일한 라이브러리를 import하는 경우에 esbuild는 텍스트메모리 공유를 통해 중복 파싱을 방지하고 캐시된 데이터를 재활용한다.

3. 모든 기능을 직접 구현

esbuild의 또 다른 특징은 외부 라이브러리에 의존하지 않고 내부 기능을 모두 자체적으로 구현했다는 점이다.

대부분의 번들러는 다음과 같은 구조를 따른다.

• TypeScript 파서는 공식 타입스크립트 컴파일러에 의존
• 이후 Babel을 통해 코드 변환 수행
• 다양한 플러그인 체계를 거쳐 추가 변환 및 최적화 실행

이 과정에서 데이터 구조가 반복적으로 변경되고, 문자열과 AST(Abstract Syntax Tree) 간 변환이 여러 번 일어난다. 이러한 과정은 필연적으로 성능 저하로 이어진다.

반면 esbuild는 다음과 같은 주요 구성 요소를 모두 자체적으로 구현하였다.

• JavaScript/TypeScript 파서
• 코드 변환기
• 번들러
• 코드 생성기

이로 인해 esbuild는 한 번 생성한 AST를 여러 단계에서 재사용하며, 중간 표현 변환을 최소화한다. “이 데이터가 이후에도 재활용될 것”이라는 점을 고려한 구조적 설계를 통해 메모리 접근 횟수를 줄이고, CPU 캐시 효율을 높인다.

공식 문서에 따르면, esbuild는 전체 자바스크립트 AST를 단 세 번만 순회한다.

1. 토큰화, 파싱, 스코프 구성, 심볼 선언
2. 심볼 바인딩, 문법 최소화, JSX/TS → JS 변환, ESNext → ES2015 변환
3. 식별자 및 공백 최소화, 코드 생성, 소스맵 생성

다른 번들러들은 이 과정을 여러 외부 라이브러리에 위임하여 문자열 ↔ AST 변환을 반복하기 때문에 상대적으로 느리다.

즉, esbuild는 일관된 내부 데이터 구조와 최소한의 AST 순회를 통해 뛰어난 성능을 달성한다.

4. 효율적인 메모리 사용

컴파일러 성능의 핵심은 방대한 데이터를 얼마나 적은 연산으로 처리하느냐에 달려 있다. esbuild는 데이터 표현 변환을 최소화하여 CPU 캐시 적중률을 높이고, 메모리 접근 횟수를 줄인다.

Go 언어는 구조체 필드를 메모리상에 밀집하게 배치할 수 있으며, 여러 불리언 값을 1바이트 단위로 압축하여 저장할 수 있다. 또한 값 타입을 직접 구조체 내부에 포함시킬 수 있어(embedding) 불필요한 동적 메모리 할당을 줄인다.

반면 자바스크립트는 이러한 메모리 최적화가 어렵다. JIT 히든 클래스, 박싱된 숫자 객체, 동적 프로퍼티 접근 등으로 인해 동일한 연산을 수행하더라도 더 많은 메모리와 연산 비용이 소모된다.

결과적으로 esbuild는 “작업을 최소화하는 것이 곧 성능 향상으로 이어진다”는 단순한 원칙을 철저히 구현한 번들러이다. AST는 세 번만 순회하며, 불필요한 표현 변환을 최소화하고, 일관된 데이터 구조를 유지한다. 이러한 설계적 일관성이 누적되어, 결과적으로 기존 번들러보다 수십 배 빠른 성능을 제공한다.

실제 벤치마크 결과

공식 문서에서 제시한 벤치마크 결과에 따르면, esbuild의 성능은 다른 주요 번들러와 비교했을 때 압도적으로 빠르다.

테스트 환경: 6코어 MacBook Pro, macOS, 16GB RAM

JavaScript 대규모 프로젝트 시뮬레이션

• esbuild: 0.39초 (기준 1배)
• Parcel 2: 14.91초 (약 38배 느림)
• Rollup 4 + Terser: 34.10초 (약 87배 느림)
• Webpack 5: 41.21초 (약 106배 느림)

TypeScript 대규모 프로젝트 시뮬레이션

• esbuild: 0.10초
• Parcel 2: 6.91초 (약 69배 느림)
• Webpack 5: 16.69초 (약 167배 느림)

이 결과는 다른 번들러의 설계가 잘못되었다는 의미가 아니라 esbuild가 전혀 다른 구조적 접근을 취했기 때문에 가능한 성능 차이임을 보여준다.

많은 번들러는 TypeScript 컴파일러를 그대로 내부에 포함해 사용하는데 이는 본래 정확한 타입 분석을 목표로 만들어졌기 때문에 성능을 우선하지 않는다. 이러한 구조는 메가모픽 객체 사용, 불필요한 동적 프로퍼티 접근 등으로 인해 오버헤드를 유발한다. 반면 esbuild는 TypeScript 파싱 및 트랜스파일 과정을 자체적으로 구현하여 이러한 병목을 근본적으로 제거하였다.

esbuild의 철학: 해주는 것과 하지 않는 것

esbuild의 개발자는 명확한 철학을 가지고 도구를 설계했다.

그는 esbuild를 프론트엔드 개발의 모든 요구를 해결하는 만능 도구로 만들 생각이 없다고 밝힌다.

따라서 다음과 같은 기능들은 의도적으로 제공하지 않는다.

• Elm, Svelte, Vue, Angular 등 타 프레임워크 전용 언어 직접 지원
• TypeScript 타입 검사 기능 (tsc로 분리)
• 커스텀 AST 조작 API
• Hot Module Reloading(HMR)
• Module Federation

그 이유는 명확하다. 지나치게 많은 기능을 수용하면 도구의 복잡도가 증가하고 성능 최적화에 일관성을 유지하기 어렵다.

이러한 이유로 esbuild는 자신을 웹을 위한 링커(linker)로 정의한다. 즉 JavaScript와 CSS를 빠르고 안정적으로 묶어주는 역할에 집중하고 그 외 영역은 다른 도구와 결합하여 사용하는 것을 권장한다.

이러한 철학 덕분에 esbuild의 코어는 가볍고 단순하며, vite와 같은 다른 툴에서 내부 빌드 엔진으로 통합하기에 적합하다. 실제로 vite는 TypeScript 변환 과정에서 esbuild를 사용하고 있다.

생태계 내 활용 사례

esbuild는 아직 1.0.0 버전에 도달하지 않았지만 이미 다양한 프로덕션 환경에서 핵심 빌드 도구로 사용되고 있다.

대표적인 예시는 다음과 같다.

• Vite: TypeScript를 JavaScript로 변환하는 단계에 esbuild를 사용
• AWS CDK: 코드 번들링에 esbuild를 채택
• Phoenix(Elixir 프레임워크): 프론트엔드 빌드 도구로 esbuild를 지원

esbuild는 단독으로 사용되지 않더라도 이미 여러 툴체인 내부에서 필수 구성 요소로 작동하고 있다.

그렇다면 이제 esbuild를 핵심 빌드 도구로 사용하고 있는 도구들 중 하나인 vite에 대해서 자세하게 알아보겠다.

Vite란 정확히 무엇인가?

기존에는 webpack처럼 모든 코드를 번들링한 뒤 브라우저에 제공하는 구조가 일반적이였지만 프로젝트가 커질수록 이 번들링 시간이 너무 오래 걸렸고 HMR(Hot Module Replacement, 코드 수정 후 새로고침 없이 반영)도 느려졌다. 이러한 성능을 해결하기 위해 등장한 것이 vite이다.

vite의 핵심 아이디어는 브라우저가 이미 지원하는 ESM(ES Modules)을 적극적으로 활용하고, 개발 시점과 배포 시점을 다른 전략으로 처리하는 것이다. 개발 중에는 번들링을 하지 않고도 빠른 응답을 제공하며 배포 시에는 여전히 번들링을 통해 최적화된 산출물을 생성하는 방식을 취한다.

이처럼 Vite는 이 문제를 개발 단계와 배포 단계를 완전히 분리함으로써 해결했다.

Vite를 사용해야 하는 이유

1. 기존 번들러가 갖고 있던 구조적 한계

브라우저가 ESM을 네이티브로 지원하기 전까지는 자바스크립트 모듈을 브라우저에서 직접 불러와 실행하는 것이 사실상 불가능했다. 이 때문에 프론트엔드 개발자들은 여러 개의 소스 모듈을 하나의 파일 또는 적은 수의 파일로 묶어주는(bundling) 방식을 사용해야 했다. webpack, Rollup, Parcel과 같은 도구는 이 과정을 자동화하여 개발자의 생산성을 크게 높였다.

그러나 애플리케이션의 규모가 커지고 모듈 수가 수백, 수천 개로 증가하면서 문제가 드러났다. 기존의 번들러는 “개발 서버를 띄우기 전에” 프로젝트 전체를 한 번 훑고 의존성을 분석하고 빌드해야 했다. 모듈 수가 많아질수록 이 초기 단계는 점점 길어졌고, 변화가 잦은 개발 환경에서는 비합리적인 대기 시간으로 이어졌다. 또한 HMR을 지원하더라도, 내부적으로는 여전히 번들 단위로 재처리가 필요했기 때문에 변경 사항이 브라우저에 반영되기까지 수 초가 걸리는 경우도 드물지 않았다. 이런 느린 피드백 루프는 곧바로 개발자의 생산성 저하로 이어졌다.

Vite는 이 문제를 “처음부터 다 번들링하지 않아도 되는 구조”를 도입하는 방식으로 해결하고자 한다. 즉, 번들링이 필요한 시점에만 번들링을 한다는 방향으로 아키텍처를 재구성했다.

2. 모듈을 의존성과 소스 코드로 분리해 다룬다

Vite가 가진 중요한 설계 포인트는 애플리케이션을 다음 두 가지 범주로 나누어 처리한다는 점이다.

1. 의존성(dependencies)

   • 예: Vue, React, UI 라이브러리, 유틸성 패키지 등
   • 개발 중에는 거의 변경되지 않는 코드
   • 대체로 순수한 JavaScript로 되어 있고, 변환 비용이 크지 않다

   • 그러나 모듈 수가 많을 경우(수백 개 이상) 초기 번들링 비용이 매우 크다

   Vite는 이 의존성들을 사전 번들링(pre-bundling) 한다. 이 작업에는 Go로 작성된 esbuild를 사용한다. esbuild는 기존 자바스크립트 기반 번들러 대비 10~100배에 달하는 속도를 제공하므로, 대규모 의존성 번들링에서 병목이 발생하지 않는다.

2. 소스 코드(source code)

   • 예: JSX, TSX, Vue SFC, Svelte 컴포넌트, CSS 등
   • 변환이 필요하고, 개발 중에 자주 변경되는 코드
   • 전체를 한 번에 처리할 필요가 없는 코드

   Vite는 이 소스 코드를 네이티브 ESM 으로 제공한다. 즉, 브라우저가 실제로 요청하는 모듈만 그때그때 변환해서 전달한다. 조건부 import()로 분기되는 코드나 현재 화면에서 사용하지 않는 라우트의 코드는 실제로 접근할 때까지 변환되지 않는다. 이로 인해 초기 구동 속도가 크게 향상된다.

   이 구조를 통해 Vite는 “처음부터 전체 애플리케이션을 번들링해야만 서버를 시작할 수 있는” 기존 번들러의 제약을 제거한다.

3. 서버 구동 속도 개선

기존 번들러 기반 개발 서버는 콜드 스타트 시 프로젝트 전체를 한 번 빌드한 뒤에야 페이지를 제공할 수 있었다. 이는 프로젝트 규모가 커질수록 선형적으로 느려지는 구조였다.

Vite는 다음과 같은 방식으로 이를 개선한다.

• 의존성은 esbuild로 미리 빠르게 묶는다.
• 애플리케이션 소스는 브라우저가 요청하는 시점에만 변환하여 전달한다.
• 브라우저가 ESM을 지원하므로, 의존성 그래프를 브라우저가 직접 따라가게 한다.

이 구조에서는 서버가 “모든 모듈이 준비될 때까지 기다린 뒤 응답”하는 것이 아니라, “응답 가능한 것부터 즉시 제공”하는 방향으로 바뀐다. 그 결과 개발 서버의 시작 시간이 매우 짧아진다.

4. 코드 갱신 속도(HMR)의 일관성

전통적인 번들러 환경에서 파일을 수정하면, 번들러는 변경된 파일뿐 아니라 그 파일과 연결된 번들도 다시 생성해야 했다. 애플리케이션이 커질수록 이 시간은 길어졌고, HMR을 사용하더라도 결국 내부에서 번들 재생성이 일어났기 때문에 대규모 프로젝트에서는 빠른 피드백을 제공하지 못했다.

Vite는 개발 서버에서 번들을 만들지 않는다. 대신 각 모듈을 ESM 단위로 브라우저에 제공한다. 이 구조에서는 어떤 모듈이 변경되었을 때 그 모듈과 그 모듈을 직접 참조하는 모듈만 교체하면 된다. 브라우저는 요청한 모듈만 다시 받으면 되므로, 애플리케이션 크기가 커져도 HMR 속도가 느려지지 않는다.

또한 Vite는 HTTP 캐시를 적극적으로 활용한다.

• 소스 코드는 변경 여부를 판단해 304 Not Modified로 응답하고
• 변하지 않는 의존성은 Cache-Control: max-age=31536000, immutable로 강하게 캐시한다.

이로 인해 네트워크 요청 수가 줄어들고, 결과적으로 전체 페이지 로딩 성능이 개선된다.

배포 시에도 번들링이 필요한 이유

현대 브라우저가 ESM을 지원한다고 해서, 프로덕션 환경에서 “번들링을 전혀 하지 않은” ESM을 그대로 배포하는 것이 항상 최선인 것은 아니다. 이유는 다음과 같다.

1. 중첩된 import가 많을수록 네트워크 요청 수도 함께 증가한다. HTTP/2 환경이라 하더라도 다량의 작은 요청은 초기 로딩에 부담을 줄 수 있다.
2. 트리 셰이킹(tree-shaking), 코드 스플리팅(code splitting), 지연 로딩(lazy loading), 캐시 효율을 위한 청크 분할 등 프로덕션 수준의 최적화는 여전히 번들링 과정에서 수행하는 것이 가장 효과적이다.
3. 개발 서버와 빌드 결과가 다르면 디버깅이 어렵다. 개발 중에 보이던 동작과 배포 후 동작이 달라지지 않도록, Vite는 미리 정해진 빌드 명령과 동일한 파이프라인을 제공한다.

따라서 Vite는 개발 시점에는 번들링을 하지 않지만, 프로덕션 빌드 시점에는 여전히 번들링을 수행한다. 이때 사용하는 번들러는 esbuild가 아니라 Rollup이다.

왜 프로덕션 번들링에는 esbuild를 사용하지 않는가

Vite는 개발 시 “사전 번들링” 단계에서 esbuild를 사용한다. 이 단계에서는 속도가 최우선이므로 esbuild의 선택이 매우 타당하다. 그러나 프로덕션 빌드 전체를 esbuild로 처리하지는 않는다. 이유는 다음과 같다.

1. 플러그인 생태계와의 호환성

   Vite는 Rollup의 플러그인 인프라를 적극적으로 채택하고 있다. 이 인프라는 이미 생태계가 크고, 다양한 프레임워크·언어·리소스에 대응하는 플러그인이 존재한다. esbuild 기반으로 완전히 전환할 경우 이런 유연성이 줄어든다.

2. 유연성과 성능의 트레이드오프

   esbuild는 매우 빠르지만, 현재 시점에서 빌드 파이프라인 전체를 대체할 만큼 유연하지는 않다. Vite는 “현실적인 프로덕션 환경에서 필요한 변환과 최적화를 안정적으로 수행할 수 있는가”를 더 중요하게 보며, 이 지점에서 Rollup이 더 균형 잡힌 선택이다.

3. 향후 대체 가능성

   Rollup은 v4에서 파서를 SWC로 전환하는 등 성능 개선을 계속하고 있으며, Rust로 포팅된 Rolldown 프로젝트도 진행 중이다. 이 흐름이 성숙하면, Vite는 개발과 빌드 사이의 불일치를 더 줄인 형태로 진화할 수 있다.

참고 자료

esbuild 공식 문서: https://esbuild.github.io/faq/#top-level-var vite 공식 문서: https://ko.vite.dev/guide/why.html

클로저란 무엇인가?

클로저(Closure)는 “함수와 그 함수가 선언될 당시의 어휘적 환경(Lexical Environment)의 조합”이다.

조금 어렵게 느껴질 수 있지만, 핵심은 “함수가 선언될 때의 스코프를 기억한다” 는 것이다. 즉, 내부 함수가 외부 함수의 변수에 접근할 수 있는 능력을 말한다.

function makeFunc() {
  const name = "Mozilla";
  function displayName() {
    console.log(name);
  }
  return displayName;
}

const myFunc = makeFunc();
myFunc(); // Mozilla

makeFunc()이 실행된 후라면, 보통 name은 사라졌을 것처럼 보인다. 하지만 displayName 함수는 makeFunc이 실행될 당시의 환경을 기억하고 있다. 이게 바로 클로저다.

어휘적 스코프(Lexical Scope)

자바스크립트는 정적 스코프(static scope), 즉 “코드가 작성된 위치”에 따라 변수의 유효 범위를 결정한다. 이는 런타임이 아니라 컴파일(파싱) 시점에 결정된다.

function init() {
  const name = "Mozilla";
  function displayName() {
    console.log(name);
  }
  displayName();
}
init(); // Mozilla

내부 함수 displayName은 자신이 어디에서 정의되었는지를 기준으로 외부 스코프(init)에 접근한다. 이러한 어휘적 스코프 덕분에 클로저가 가능해진다.

클로저의 실제 동작

클로저가 만들어질 때, 자바스크립트 엔진은 함수가 참조하는 외부 변수들을 별도의 환경 객체(Environment Record) 안에 저장한다. 이 객체는 함수가 반환된 뒤에도 GC(가비지 컬렉션)으로부터 제거되지 않고 남는다. 즉, 함수가 실행될 때마다 새로운 “환경 스냅샷”이 생성되는 것이다.

function makeAdder(x) {
  return function (y) {
    return x + y;
  };
}

const add5 = makeAdder(5);
const add10 = makeAdder(10);

console.log(add5(2)); // 7
console.log(add10(2)); // 12

add5와 add10은 서로 다른 환경을 기억한다. 그래서 각자의 x 값을 따로 유지할 수 있다.

클로저의 실용적 사용 예시

1. 데이터 은닉 (Private 변수)

클로저를 사용하면, 외부에서 접근할 수 없는 “비공개 상태”를 만들 수 있다.

function createCounter() {
  let count = 0;

  return {
    increment() {
      count++;
    },
    decrement() {
      count--;
    },
    getCount() {
      return count;
    },
  };
}

const counter = createCounter();
counter.increment();
console.log(counter.getCount()); // 1

외부에서는 count에 직접 접근할 수 없다. 오직 increment, decrement, getCount를 통해서만 접근 가능하다. 이것은 클래스의 “private 속성”과 같은 효과를 낸다.

2. 이벤트 핸들러나 콜백에서 상태 유지

function makeSizer(size) {
  return function () {
    document.body.style.fontSize = `${size}px`;
  };
}

const size12 = makeSizer(12);
const size16 = makeSizer(16);

document.getElementById("small").onclick = size12;
document.getElementById("large").onclick = size16;

각 버튼은 클릭될 때마다 서로 다른 size 값을 기억하고 있다. 이처럼 클로저는 이벤트 기반 코드에서 상태를 저장하는 강력한 도구로 쓰인다.

클로저 사용 시 주의할 점

1. 루프 안 var 사용 문제

아래 코드는 모든 입력창이 마지막 도움말만 보여준다.

function setupHelp() {
  var helpText = [
    { id: "email", help: "Your email address" },
    { id: "name", help: "Your full name" },
    { id: "age", help: "Your age" },
  ];

  for (var i = 0; i < helpText.length; i++) {
    var item = helpText[i];
    document.getElementById(item.id).onfocus = function () {
      showHelp(item.help); // 마지막 값만 유지
    };
  }
}

해결 방법은 let을 사용해 각 반복마다 별도의 블록 스코프를 생성하는 것이다.

for (let i = 0; i < helpText.length; i++) {
  const item = helpText[i];
  document.getElementById(item.id).onfocus = () => showHelp(item.help);
}

2. 불필요한 클로저 남용

function MyObject(name) {
  this.name = name;
  this.getName = function () {
    return this.name; // 매번 새 함수 생성
  };
}

// 개선
MyObject.prototype.getName = function () {
  return this.name;
};

클로저는 함수가 기억하는 ‘환경’이다. 기억해야 할 건 변수 값이 아니라 변수를 둘러싼 스코프 자체다.

function sayHello(name) {
  var greeting = "Hello";
  console.log(greeting + " " + name);
}
sayHello("Hyerin");

GlobalEC = {
  LexicalEnvironment: {
    EnvironmentRecord: { sayHello: <function> },
    Outer: null,
  },
  VariableEnvironment: {...},
  ThisBinding: window
}

FunctionEC = {
  LexicalEnvironment: {
    EnvironmentRecord: { name: "Hyerin", greeting: undefined },
    Outer: GlobalLexicalEnvironment
  },
  VariableEnvironment: {...},
  ThisBinding: undefined (strict mode 기준)
}

console.log(x); // undefined
var x = 10;

var x; // 선언(등록)
console.log(x);
x = 10; // 초기화(할당)

const x = 1;

function outer() {
  const y = 2;
  function inner() {
    const z = 3;
    console.log(x + y + z);
  }
  inner();
}
outer(); // 6

GlobalLE  →  outerLE  →  innerLE
   ↑           ↑           ↑
  x=1         y=2         z=3

function outer() {
  const x = 10;
  return function inner() {
    console.log(x);
  };
}

const fn = outer();
fn(); // 10

function first() {
  second();
  console.log("End of first");
}

function second() {
  console.log("In second");
}

first();
console.log("End of global");

이런 이유로 이번 글에서는 성능 최적화를 위한 브라우저 동작 원리라는 주제를 다뤄보려 합니다 ㅎㅎㅎ

브라우저 동작 원리에 대해서 알아보자

웹서버로부터 HTML 받아오기

먼저 우리가 주소창에 URL (www.naver.com)을 입력하면 DNS를 조회해서 URL 과 IP주소 를 가지고 요청을 보냅니다.

DNS란 _Domain Name System_의 약자로 사용자가 이해하기 쉬운 도메인 이름을 컴퓨터가 이해할 수 있는 IP 주소 로 변환해주는 역할을 해요.

요청을 받은 웹서버는 응답을 통해 HTML 파일을 브라우저로 보내줘요.

(URL 입력 후 브라우저에서 웹 서버까지 과정에 HTTP, DNS 등 여러 과정들이 있으니까 맨 위에 사진을 참고해주세요 !)

HTML 파싱

간단하게 말하자면 HTML을 파싱하는 과정은 Render Tree를 만들기 위해 DOM과 CSSOM을 만든 뒤 Layout 단계와 Paint 단계를 거쳐 웹사이트를 만드는 과정이에요.

위에 말을 이해하기 쉽도록 아래에서 자세하게 이야기해볼게요

먼저 브라우저가 웹서버로부터 응답을 받은 뒤 HTML 코드를 받으면 이제 브라우저는 HTML을 파싱 하기 시작합니다.

파싱을 하면 아래 과정을 거쳐요

• DOM 생성
• CSSOM 생성
• javaScript 파일 다운로드

파싱을 시작하면 먼저 본격적으로 DOM 생성에 들어가요. 파싱을 하는 과정에서 css <link> 태그를 만나면 외부 리소스를 다운로드해요.

<html lang="ko">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>자기소개 페이지</title>
  <link rel="stylesheet" href="./styles/reset.css"/>
  <link rel="stylesheet" href="./styles/theme.css"/>
  <link rel="stylesheet" href="./styles/styles.css"/>
</head>
<body>
<!-- 내용.. -->
</body>

위의 html 코드를 예시로 보면 css <link> 태그가 있죠 ?

이렇게 브라우저가 HTML을 파싱하다가 CSS <link> 태그를 만나면, DOM 만들던 과정을 잠깐 멈추고 DNS에서 받은 IP주소를 다시 찾아가서 css 파일을 요청해요.

여기서 HTML은 IP주소를 찾았으면 HTML 파싱은 그대로 이어서 진행돼요! 즉 CSS 파일 로딩 자체는 DOM의 생성을 막지 않아요 !

하지만 여기서 헷갈리면 안되는 부분은 CSS 파일이 로딩되고 CSSOM을 만드는 동안, DOM은 Render Tree를 만들기 위해 CSSOM이 완성되기를 기다린다는거에요. 즉 CSS 파일 로딩은 DOM 파싱을 중단시키지는 않지만 Render Tree 생성을 위해 CSSOM이 필요하기 때문에 브라우저는 CSS 파싱이 끝날 때까지 레이아웃 및 페인트를 지연시켜요. 따라서 CSS 로딩 속도는 초기 렌더링 성능에 큰 영향을 줍니다! DOM과 CSSOM이 완성이 돼야 다음 스텝으로 진행할 수 있기 때문에 HTML입장에서는 CSSOM을 최대한 빨리 만드는 것이 중요한거죠.

이 부분을 알면 CSS 라이브러리의 선택이 성능에도 중요하다는 걸 알 수 있어요. CSS 라이브러리 선택의 근거를 가져야 하는 이유죠 ㅎㅎ 이 부분과 관련된 아티클은 다음에 작성해보도록 할게요

이제 태그 중에서 script 태그를 만나는 순간 HTML은 파싱을 잠깐 멈추고 DNS에서 받은 IP주소를 다시 찾아가서 javaScript파일을 요청해요.

여기서 CSS와 다르게 JS 실행중에는 DOM 파싱 자체를 중단시켜요!

JS는 많은 변화가 있을 수 있기 때문에 DOM을 다시 그려야할 가능성이 있기 때문입니다.

script 태그의 위치를 HTML태그 상단에 두게되면 javascript를 실행할 때까지 HTML 태그 그리기를 멈춰놓기 때문에 비효율적이에요. 그래서 script태그를 body 바닥에 위치 시켜야한다고 해요. body 바닥에 두거나 javaScript가 DOM 생성을 막지 않도록 하는 defer, async 옵션을 사용하는 방법도 있어요.

• defer: HTML 파싱과 병렬로 다운로드되고 파싱이 끝난 뒤 실행
• async: HTML 파싱과 병렬로 다운로드되며 다운로드가 끝나는 즉시 실행된다 (HTML 파싱 중단 가능성 있음)

우리가 사용하는 React나 Vue는 defer 옵션을 사용하는 방법을 이용하고 있다고 합니다.

body 바닥에 두는 방법

<html lang="ko">
<head>
  <!-- 내용.. -->
</head>
<body>
<!-- 내용.. -->
  <script src="example.js"></script>
</body>
</html>

defer나 async를 사용하는 방법 (React, Vue가 사용하는 방법)

<html lang="ko">
<head>
  <!-- 내용.. -->
  <script src="/examples/scripts/script_src.js" defer></script>
</head>
<body>
<!-- 내용.. -->
</body>
</html>

이렇게 HTML을 통해서 DOM도 만들었고, javaScript도 불러왔고, CSSOM도 만들었으면 이제 DOM과 CSSOM을 합쳐 Rende Tree를 만들 수 있어요.

Render Tree는 웹사이트를 그리기 위한 최종 설계도에요. Render Tree를 만든 후에는 Layout 단계를 통해 정확한 px를 계산하고 이후 Paint 단계에서 실제 계산한 px를 통해 웹사이트에 그려요.

성능 최적화를 위해서 알아야 할 Reflow

Reflow란 Layout 단계에서 계산이 다시 수행되는 과정입니다.

DOM이나 CSSOM의 변경으로 인해 발생되며 이는 성능에 큰 영향을 줄 수 있어요. Layout이 바뀌면 다시 처음부터 Painting을 해야하기 때문에 최소한으로 바뀌어야 성능개선에 도움이 됩니다.

특히 트리의 상위 요소에서 변화가 발생하면 하위 요소들도 모두 재계산되니 성능에 더 큰 영향을 줄 수 있겠죠 ?

Reflow되는 상황

• 페이지 초기 렌더링 시 (최초 Layout 과정)
• 윈도우 리사이징 시 (Viewport 크기 변경시)
• 노드 추가 또는 제거
• 요소의 위치, 크기 변경(left, top, margin, padding, border, width, height 등)
• 폰트 변경(텍스트 내용)과 이미지 크기 변경(크기가 다른 이미지로 변경 시)

Repaint? Repaint는 레이아웃에 영향을 주지 않는 시각적 속성(색상, 그림자 등)만 다시 그리는 것으로 Reflow가 레이아웃 계산을 다시 해서 성능 비용이 큰 것에 비해 Repaint는 비교적 비용이 상대적으로 적습니다!

useLayoutEffect

브라우저 렌더링 과정의 Layout 단계에 대해서 이제 알았다면 useLayoutEffect를 완전히 이해할 수 있어요. useLayoutEffect의 Layout이 바로 이 브라우저의 Layout 단계를 가리키거든요 ㅎㅎ

공식문서에서는 useLayout을 이렇게 설명하고 있어요 ⬇️

useLayoutEffect는 브라우저가 화면을 다시 그리기 전에 실행되는 useEffect이다.

useEffect는 DOM이 업데이트되고 Layout과 Paint까지 모두 완료된 후 실행됩니다. useLayoutEffect는 DOM이 업데이트되고 Layout이 완료된 직후인 Paint가 시작되기 전에 실행되죠.

useLayoutEffect를 사용하면 Paint가 일어나기 직전이기 때문에 여기서 DOM을 조작하면 사용자가 보기도 전에 화면에 반영할 수 있어 깜빡임 없이 동작시킬 수 있는거죠!

_하지만 공식문서에서는 useLayoutEffect를 권장하진 않아요. _

왜냐하면 useLayoutEffect는 브라우저가 화면을 그리기 직전에 동기적으로 실행되기 때문에 이 안에서 무거운 작업을 하면 브라우저의 페인트가 지연되어 성능이 저하될 수 있기 때문이에요.

특히 React 18 이후에는 동시성 렌더링(Concurrent Rendering)과 전환(Transition)이 도입되어 useLayoutEffect의 남용이 렌더링 중단 및 프레임 드랍으로 이어질 수 있기 때문에 정말 필요한 경우에만 최소한으로 사용하는 것이 중요해요. 따라서 useLayoutEffect는 스크롤 위치를 조정하거나 요소의 크기를 측정해 다른 요소의 스타일을 조정하는 등 페인트 전에 DOM 상태를 읽고 수정해 화면 깜빡임을 방지해야 하는 상황에서만 사용하는 것이 좋다고 명시하고 있어요.

실제 프로젝트에서 useLayoutEffect를 사용해본 경험

저도 프로젝트에서 useLayoutEffect를 사용했던 경험이 있는데요.

아코디언(Accordion) 컴포넌트를 구현할 때였습니다. 아코디언은 열리고 닫힐 때 콘텐츠 영역의 높이(height) 값을 계산해 max-height 스타일에 적용함으로써 부드럽게 열고 닫히도록 애니메이션을 구현하는 방식으로 동작했어요.

import { useLayoutEffect, useRef, useState } from 'react';

export const useMeasureHeight = <T extends HTMLElement>() => {
  const ref = useRef<T>(null);
  const [height, setHeight] = useState(0);

  useLayoutEffect(() => {
    const element = ref.current;
    if (!element) {
      return;
    }

    const measureHeight = () => setHeight(element.scrollHeight);

    measureHeight();
    const resizeObserver = new ResizeObserver(measureHeight);
    resizeObserver.observe(element);

    return () => resizeObserver.disconnect();
  }, []);

  return { ref, height };
};

위에 있는 코드는 아코디언 콘텐츠 영역의 실제 높이를 측정하기 위해 제가 작성했던 커스텀 훅이에요.

아코디언을 열기 전에는 data가 서버에서 넘어오지 않았어요. 따라서 열 때는 먼저 콘텐츠 영역의 실제 높이를 scrollHeight로 읽은 뒤 이 값을 max-height에 적용해야 자연스럽게 펼쳐지는 애니메이션을 만들 수 있습니다.

그런데 이 높이 측정을 useEffect 안에서 처리하면 Paint 이후에 실행되기 때문에, 브라우저가 먼저 접힌 상태를 그린 뒤 높이를 다시 계산하게 됩니다. 이 과정에서 짧은 순간 접힌 상태가 보이거나 화면이 깜빡이는 문제가 발생했어요.

이때 useLayoutEffect를 사용하면 브라우저가 Paint를 하기 직전에 콘텐츠의 높이를 동기적으로 계산하고 스타일을 적용할 수 있어서, 사용자가 깜빡임 없이 부드럽게 아코디언이 열리는 경험을 만들 수 있었습니다.

이런 식으로 레이아웃 측정이나 스타일 적용이 Paint 전에 반드시 이루어져야 할 상황에서 useLayoutEffect를 쓰면 좋을 것 같습니다

참고 레퍼런스 https://ko.react.dev/reference/react/useLayoutEffect https://www.youtube.com/watch?v=Mqh13dNI8jc https://developer.mozilla.org/en-US/docs/Web/Performance/Guides/Critical_rendering_path