
자바스크립트를 공부하다 보면 클로저라는 개념을 마주하게 된다. 클로저는 자바스크립트를 학습하는 많은 사람들에게 머리를 아프게한다. 그 이유는 클로저를 제대로 이해하기 위해 필요한 선행 지식들이 상당히 어렵고, 이를 충분히 숙지하지 못하면 개념 자체를 이해하기 어려워지기 때문이다.

## 클로저를 이해하기 위한 선행지식

클로저를 제대로 이해하기 위해 반드시 알아야 할 선행 지식들이 필요하다.

- 렉시컬 스코프
- 실행 컨텍스트
- 일급 객체
- 생명 주기
- 함수형 프로그래밍

## 클로저란

클로저란 `함수가 선언된 렉시컬 환경을 기억하며, 외부 함수의 실행이 종료된 이후에도 외부 변수에 접근할 수 있는 함수`를 말한다. MDN 문서에서는 클로저를 다음과 같이 설명한다.

> A closure is the combination of a function and the lexical environment within which that function was declared.
> 클로저는 함수와 그 함수가 선언됐을 때의 렉시컬 환경(Lexical environment)과의 조합이다.

이 문장은 이해하기 어려울 수 있지만, 밑의 내용을 읽고 나서도 이해가 되지 않는다면, 그때는 관련된 선행 지식들을 다시 공부하는 것이 좋다. 위 문장을 구조적인 측면으로 쪼개어 설명하면 다음과 같다.

### 함수가 선언된 렉시컬 환경이란?

자바스크립트는 렉시컬 스코프(Lexical Scope)를 따르며, 함수가 어디에서 정의되었는지에 따라 상위 스코프를 기억한다. 렉시컬 환경은 함수가 선언될 당시의 식별자와 스코프, 그리고 외부 렉시컬 환경에 대한 참조(상위 스코프)가 들어있는 환경이다. 따라서, `"함수가 선언된 렉시컬 환경"`이란 함수가 정의된 위치를 기준으로 구성된 변수와 스코프 정보를 의미한다고 이해할 수 있다.

### 외부 함수의 실행이 종료된 이후에도 변수에 접근할 수 있는 함수란?

우선 위 문장을 이해하려면 생명 주기에 대해 알아야 한다. 생명 주기란 식별자(변수, 함수 등)가 메모리에 생성되어 사용되고, 더 이상 참조되지 않을 때 가비지 컬렉터에 의해 제거되는 과정을 말한다. 일반적으로, 함수가 실행을 마치면 그 함수의 실행 컨텍스트와 함께 해당 함수 내의 변수는 메모리에서 제거된다. 하지만 어떤 함수가 해당 변수를 참조하고 있다면, 해당 변수는 참조가 유지되기 때문에 메모리에 남아있게 된다.

스코프 체인과 렉시컬 환경 덕분에 함수는 선언된 위치의 상위 스코프에 있는 식별자에 계속 접근할 수 있다. 이러한 특성 덕분에 함수는 외부 함수의 실행이 종료된 이후에도 상위 스코프의 식별자에 접근할 수 있다.

즉, `외부 함수의 실행이 종료된 이후에도 외부 변수에 접근할 수 있는 함수`란, 함수가 선언된 렉시컬 환경을 기억하고 있어, 외부 함수 실행이 종료된 이후에도 해당 변수를 참조할 수 있는 함수를 말한다. 이러한 함수는 상위 스코프의 렉시컬 환경을 참조하기 때문에, 관련된 변수는 메모리에 유지된다.

이러한 동작이 가능한 이유는 JavaScript에서 함수가 일급 객체로 취급되기 때문이다. 즉, 함수는 다른 값처럼 변수에 저장되거나 반환값으로 사용할 수 있어, 상위 스코프의 렉시컬 환경을 함께 담아둘 수 있다.

### 함수형 프로그래밍과 어떤 연관이 있을까?

함수형 프로그래밍은 상태와 부작용을 최소화하고, 코드를 선언적으로 작성하는 프로그래밍 패러다임이다. 이 패러다임의 핵심은 동일한 입력에 대해 항상 동일한 결과를 반환하는 순수 함수와 변경할 수 없는 값, 즉 불변성을 사용하는 것이다.

클로저는 외부 상태를 직접 변경하지 않고, 부작용 없이 안전하게 상태를 관리할 수 있는 기능을 제공한다. 아래의 코드는 순수 함수로 작성된 예시는 아니지만, 상태 관리 측면에서 함수형 프로그래밍의 핵심 원칙을 지키고 있다. `count` 변수는 함수 내부에 은닉되어 있으며, `setCount`를 사용하지 않고는 외부에서 변경할 수 없다. 이처럼 클로저는 외부 상태를 안전하게 캡슐화하여 함수형 프로그래밍의 원칙과 잘 맞아떨어진다.

> 클로저는 자바스크립트 고유의 개념이 아니라 함수를 일급 객체로 취급하는 함수형 프로그래밍 언어(Functional Programming language: 얼랭(Erlnag), 스칼라(Scala), 하스켈(Haskell), 리스프(Lisp)…)에서 사용되는 중요한 특성이다.

### 클로저 사용 예시

```ts
function counterState(initialValue?: number) {
  let count = initialValue ?? 1

  const getCount = () => {
    return count
  }

  const setCount = (value: number) => {
    count = value
  }

  return [getCount, setCount] as const
}

const [getCount, setCount] = counterState(1)

console.log(getCount()) // 1

setCount(5)

console.log(getCount()) // 5
```

## React의 useState는 클로저를 활용하고 있다.

useState는 React 컴포넌트에서 상태 관리를 위해 제공되는 훅으로, 내부적으로 클로저의 특성을 활용해 상태를 유지한다. React에서 리렌더링이 발생하면 컴포넌트 함수가 다시 호출되며, useState도 함께 호출된다. 하지만, useState는 항상 최신 상태를 반환한다.

즉, 렌더링이 반복되더라도 useState가 이전 렌더링에서 변경된 상태 값을 유지하며, 컴포넌트의 상태 일관성이 보장된다. 이를 근거로 useState는 클로저로 동작하고 있다는 것을 알 수 있다.

### React useState 의사코드

```ts
const { render, useState } = (function () {
  const internals: Internals<any> = {
    states: [],
    rootComponent: null,
    currentStateIndex: 0,
  }

  function render<T>(component: Component<T>): ReturnType<Component<T>> {
    internals.rootComponent = component
    return _render()
  }

  function _render() {
    internals.currentStateIndex = 0
    const component = internals.rootComponent!()
    component.render()
    return component
  }

  function useState<T>(initialState: T) {
    const currentIndex = internals.currentStateIndex
    const state = internals.states[currentIndex] ?? initialState

    const setState = (newState: T | Partial<T>) => {
      internals.states[currentIndex] = newState
    }

    internals.currentStateIndex++

    return [state, setState]
  }

  return { render, useState }
})()

function Counter() {
  const [count, setCount] = useState(1)

  return {
    increase() {
      setCount(count + 1)
    },
    decrease() {
      setCount(count - 1)
    },
    render() {
      console.log("count", count)
    },
  }
}

let counterComponent: CounterComponent = render<CounterComponent>(Counter) // 1
counterComponent.increase()
counterComponent = render(Counter) // 2
counterComponent.increase()
counterComponent = render(Counter) // 3
counterComponent.decrease()
counterComponent = render(Counter) // 2
```

`useState`는 React의 상태 관리 훅을 모방한 구현으로, 내부적으로 클로저의 특성을 활용해 상태를 유지한다. 코드가 복잡해 보일 수 있지만, 동작 원리를 이해하려면 `Internals`와 `useState`의 구현을 중심으로 살펴보는 것이 핵심이다.

- **Internals**

  - `Internals`객체는 컴포넌트의 상태와 훅의 인덱스를 저장하고 있다.
  - 이 객체는 외부에서 직접 접근할 수 없으며, 클로저로 캡슐화된 상태로, 반환된 함수(render, useState)를 통해서만 상태를 읽거나 수정할 수 있다.

- **useState**
  - `currentIndex`는 useState 호출 순서를 추적하며, 각 훅의 상태를 고유하게 관리하기 위해 사용된다. (useState는 여러번 호출될 수 있다.)
  - `internals.states`, `currentIndex`를 참조하여 현재 상태가 있다면 반환하고 없다면 초기 상태를 설정하고 있다.
  - `setState` 함수는 `internals.states[currentIndex]`를 참조하여 상태를 변경한다.

이렇듯 클로저는 상태 관리의 핵심 도구로써 매우 유용하게 사용된다. 클로저를 활용하면 내부 상태를 외부로부터 안전하게 보호할 수 있을 뿐 아니라, 상태를 지속적으로 관리하고 유지하는 구조를 구현할 수 있다. React의 useState와 같은 상태 관리 훅은 클로저의 이러한 특성을 효과적으로 활용한 대표적인 예라 할 수 있다.

> 참고로 위 useState의 기능은 아직 부족한 점이 많다. 무엇이 부족한지 고민해보고 기능을 추가해보자!

## 클로저의 장점과 단점

### 장점

- 상태 유지 - 클로저를 통해 외부 함수의 변수를 참조할 수 있다. 이는 함수가 실행된 이후에도 데이터를 유지할 수 있음을 의미하며, 데이터의 일관성을 보장한다.
- 정보 은닉 - 클로저를 사용하면 외부 함수의 변수에 직접 접근할 수 없으며, 정의된 메서드를 통해서만 값을 읽거나 변경할 수 있다. 이를 통해 데이터 보호와 은닉이 가능하다.

### 단점

- 메모리 누수 - 클로저를 남용할 경우, 참조가 끊기지 않은 변수가 메모리에 계속 유지되어 가비지 컬렉터가 메모리를 해제하지 못하는 상황이 발생할 수 있다.

## 마무리

클로저를 설명할 때, 정의와 장단점에 대해 얘기하면 간결할 수 있지만, 깊이를 전달하기에는 한계가 있다고 생각하고 너무 부족한 답변이라는 생각이 든다. 구조적인 측면에서 함께 설명하는 것이 프로그래밍 독해 능력을 보여주고, 자신이 깊이 있는 사고를 가진 사람임을 어필할 수 있는 좋은 방법이라고 생각한다.

추가적으로, 위 React.useState 의사코드의 핵심 로직들은 구글링을 통해 쉽게 얻을 수 있는 정보다. 하지만 구조적인 내용을 제대로 이해하지 못한다면, 이 코드를 여러 번 읽어도 스스로 구현해내는 것은 굉장히 어렵다. 코드가 짧지만, 그 안에는 상태 관리와 클로저를 활용한 많은 고민과 설계가 담겨 있다. 따라서 이 코드를 학습할 때는 단순히 암기하려는 태도보다는, `"왜 이렇게 만들었을까?"`라는 질문을 던지고 분석하려는 시도가 반드시 필요하다고 생각한다.


클로저는 왜 어려울까? 개념만으로는 쉽게 이해되지 않는 경우가 많다. 이를 더 잘 이해하기 위해, 구조적인 측면으로 분석해보자.

구조적 측면으로 클로저 이해하기


Reflow를 공부하는 과정에서 예상과 다른 동작을 발견하게 되었고, 이를 검증하기 위해 직접 테스트를 진행해 보았다. 그러나 테스트 결과는 내가 기대했던 것과 달랐고, 이를 통해 Reflow에 대해 충분히 이해하지 못하고 있다는 사실을 깨달았다. 이후 관련 자료를 심층적으로 조사하면서, 그동안 Reflow에 대해 단편적으로만 알고 있었다는 점을 명확히 인식하게 되었다. 이번 아티클에서는 Reflow의 개념을 자세히 파헤치고, 공부 과정에서 생긴 의문과 예상과 다른 결과의 원인을 체계적으로 분석해 보려 한다.

## Reflow

우선 용어를 정리하자면, Reflow는 Firefox에서 주로 사용되는 용어이며, Chrome과 Safari에서는 Layout이라는 표현을 사용한다. 이러한 차이는 브라우저 개발자 도구를 통해 쉽게 확인할 수 있다. 즉 Reflow, Layout 같은 말이다. 여기서는 Reflow라고 말을 하겠다. Reflow란 **렌더 트리를 기준으로 요소의 레이아웃(크기, 위치, 관계)을 다시 계산하는 과정**을 의미한다. 특히 현대 웹 개발에서 자바스크립트를 사용해 DOM을 조작할 때 Reflow에 신경 써야 한다. Reflow는 `성능 저하`와 `병목 현상`을 초래할 수 있기 때문이다.

> Reflow가 아니더라도 브라우저 렌더링 과정에 대한 것들은 모두 신경써야 한다.

## 우리가 알고있는 Reflow는 생각보다 다르다.

Reflow에 대한 기본적인 지식을 배웠으니, 다음 코드는 Reflow가 몇번 발생하는지 생각해보자.

```ts
const button = document.querySelector("button")! as HTMLButtonElement
const paragraph = document.querySelector("p")! as HTMLParagraphElement

button.addEventListener("click", (event) => {
  for (let i = 1; i <= 10_000; i++) {
    paragraph.innerHTML = String(i)
  }
})
```

대부분의 사람들은(실제 주변 동료들에게 질문한 결과) "반복 횟수만큼 Reflow가 발생한다"라고 답변했다. 하지만 실제로는 Reflow는 한 번만 발생하고 있었다. 위 코드를 Performance로 분석한 결과는 다음과 같다.

![성능 분석 결과](/posts/JavaScript/reflow/no-optimization.png)

지금은 innerHTML을 추가한 것이지만, 위 코드에서 `createElement`를 사용해 `appendChild`로 DOM 추가를 하더라도 Reflow는 한 번만 발생하게 된다. 이러한 이유를 알려면, Asynchronous Reflow와 Synchronous Reflow를 알아야 한다.

### Asynchronous Reflow(비동기식 리플로우)

Asynchronous Reflow란 브라우저가 DOM 변경에 따른 레이아웃 재계산 작업을 지연하거나 최적화하는 과정을 말한다. 비동기식 Reflow는 페인트가 일어나기 전에 실행된다. 위에 이미지를 보면 pre-paint 이전에 Layout이 일어나는 것을 볼 수 있다. 마치 React의 batch와 같이 DOM 업데이트를 모아서 처리한다고 볼 수 있다. 따라서 위 코드와 같이 반복적으로 DOM 업데이트를 시도한다고해서 매번 Reflow가 발생하는건 아니다.

### Synchronous Reflow(동기식, 강제 리플로우)

Synchronous Reflow는 Forced Reflow 라고도 부른다. 이 개념은 우리가 알고있는 Reflow와 같다. 위 코드에서 `paragraph.innerHTML = String(i)`밑에서 `console.log(Reflow를_일으키는_속성_및_메서드)`를 사용하면 이 때 Forced Reflow가 일어나게 된다. 이 과정을 Performance로 분석하면 다음과 같다.

![동기식 Reflow](/posts/JavaScript/reflow/force-reflow.png)

위 그림에서 보라색으로 표시된 부분이 Layout, 즉 Reflow를 의미한다. Reflow는 브라우저가 DOM의 레이아웃을 다시 계산하는 과정으로, 이 작업은 매우 계산 비용이 크다. 특히, 매번 Reflow를 계산하게 되면 병목 현상이 발생하여 성능이 크게 저하되는 모습을 볼 수 있다. 이렇게 단일 작업 및 프레임에서 Reflow가 여러번 발생하는 것을 `레이아웃 쓰레싱(Layout Thrashing)`이라고 한다.

따라서, Forced Reflow는 최대한 사용하지 않는 것이 중요하다. DOM이나 스타일 변경 작업을 효율적으로 설계하고, Reflow를 최소화하는 방법을 고려해야 한다. 예를 들어, 레이아웃 정보를 읽고 쓰는 작업을 분리하거나, `requestAnimationFrame`을 활용하여 렌더링 타이밍에 맞춰 작업을 수행하는 것이 성능 최적화에 도움을 줄 수 있다.

### 레이아웃 쓰레싱의 의문

브라우저는 HTML 파일을 파싱하여 DOM 트리를 생성하고, link 태그를 만나면 CSSOM을 생성한다. 자바스크립트가 DOM을 조작하면, 브라우저는 DOM 트리 생성을 중단하고 자바스크립트 실행을 완료한 후 DOM 트리 생성을 재개한다. 이후, DOM과 CSSOM을 결합하여 Render Tree를 만든다.

이 과정을 살펴보면, `레이아웃 쓰레싱이 어떻게 발생하는지 이해하기 어렵다`. 왜냐하면 Render Tree가 생성된 이후에야 레이아웃 계산(Reflow)이 일어나기 때문이다.

하지만 Render Tree가 완성되기 이전에도 레이아웃 쓰레싱이 발생할 수 있는 이유는 자바스크립트 실행 중에 Forced Reflow가 발생하기 때문이다. Forced Reflow가 발생하면 브라우저는 Recalculate Style 단계를 실행하여 DOM과 CSSOM을 기반으로 Render Tree를 업데이트한다.

따라서, Render Tree는 자바스크립트가 실행되는 동안에도 동적으로 생성되거나 갱신될 수 있으며, 이 과정에서 반복적인 DOM 읽기/쓰기 작업이 강제 Reflow를 유발하면 레이아웃 쓰레싱이 발생할 수 있다.

![Recalculate style](/posts/JavaScript/reflow/layout-thrashing.png)

### 동기식 Reflow에서는 매번 Rendering이 진행될까?

브라우저 렌더링 과정에서 Reflow가 발생하면 Paint, Compositing 단계를 거쳐 DOM에 Commit 된다는 것은 모두 알고 있을 것이다. 하지만 동기식 Reflow에서는 Paint, Commit 단계를 진행하지 않는다. 이러한 점을 보았을 때 Reflow가 된다고해서 반드시 DOM에 Commit되지 않는다는 것을 알 수 있다. 만약 Commit 단계까지 갔다면, 숫자가 카운트되면서 올라가는 애니메이션이 진행되어야하는데, 실제로는 그렇지 않다는것을 알 수 있다.

추가적으로, 자바스크립트가 실행 중일 때 브라우저는 렌더링 작업이 차단된다. 즉, 반복문에서 Reflow를 유발하더라도 자바스크립트 실행이 끝나기 전까지 브라우저는 화면을 렌더링하지 않는다. 이는 브라우저가 싱글 스레드로 동작하며, 자바스크립트와 렌더링 작업을 병렬로 처리하지 않기 때문이다. 따라서, Reflow가 발생하더라도 실제 렌더링은 자바스크립트 실행이 완료된 후에 이루어진다.

만약 자바스크립트가 렌더링을 차단하지 않도록 하기 위해 긴 작업을 작은 단위로 나누고, `setTimeout`이나 `requestAnimationFrame`을 사용해 비동기적으로 작업을 분리하면 브라우저가 렌더링과 자바스크립트 실행을 병행할 수 있다. 이러한 방법은 React에서 긴 동기 작업으로 인해 UI가 멈추는 문제를 해결하기 위해 비동기적으로 동작하는것과 비슷하다.

### 그렇다면 Reflow 최적화를 할 필요가 없을까?

성능 최적화에 관심이 많은 분들은 위 코드(비동기 Reflow)를 최적화하기 위해 다음과 같은 방식을 사용하는 경우를 볼 수 있다

```ts
let text = ""

button.addEventListener("click", () => {
  for (let i = 1; i <= 10000; i++) {
    text = String(i)
  }

  paragraph.innerHTML = text
})
```

비동기식 Reflow를 활용한 코드에서도 Reflow는 한 번만 발생하고, 위 코드에서도 Reflow는 한 번만 발생한다. 따라서 Reflow 측면에서는 결과가 동일하다.

그러나 DOM을 한 번만 업데이트하는 것과 여러 번 업데이트하는 것은 성능에서 매우 큰 차이를 가져온다. 이는 브라우저가 DOM 변경 작업을 처리하는 방식 때문으로, Performance 탭을 통해 분석한 결과에서도 이러한 차이가 명확히 드러난다.

#### 여러번의 DOM 업데이트

![여러번의 DOM 업데이트](/posts/JavaScript/reflow/dom-update.png)

여러 번의 DOM 업데이트가 수행된 Performance 결과를 보면, 파란색 막대가 매우 촘촘하게 나타나는 것을 확인할 수 있다. 이 파란색 막대는 parseHTML 과정을 나타내며, 브라우저가 HTML 문자열을 파싱하여 DOM 트리를 생성하는 작업을 의미한다.

DOM을 반복적으로 업데이트하면 브라우저가 계속해서 DOM 트리를 재생성해야 하므로, 긴 태스크 작업 경고창이 표시되었다(위 빨간색 막대) 이 특정 작업에서는 154.47ms의 시간이 소요되었으며, 병목 현상으로 이어지고 있다.

#### DOM 업데이트 최적화

![DOM 업데이트 최적화](/posts/JavaScript/reflow/dom-update-optimization.png)

최적화된 DOM 업데이트의 Performance 결과를 보면, DOM 트리를 생성하는 파란색 막대(parseHTML)가 보이지 않는 것을 확인할 수 있다. 이는 DOM 업데이트 작업이 효율적으로 수행되어 브라우저가 불필요한 parseHTML 작업을 최소화했음을 의미한다. 또한, 태스크 작업 속도가 1.29ms로 매우 짧게 측정되었으며, 이는 성능이 크게 개선되었음을 보여준다. (비록 위 이미지에는 표시되지 않았지만, 작업이 최적화된 결과 29ms밖에 걸리지 않는다는 점이 결정적인 차이로 나타난다.)

#### 결론

즉, Reflow가 한 번만 발생한다고 해서 성능 최적화를 하지 않아도 된다는 뜻은 아니다. 위 예시에서 살펴본 것처럼, 최적화를 수행하지 않으면 DOM 트리를 생성하는 과정에서 병목 현상이 발생할 수 있다.

따라서, 최적화를 진행할 때는 단순히 Reflow 관점에서만 보지 말고, Performance 분석 도구를 활용하여 병목의 원인을 찾아야 한다. 이렇게 하면 문제를 더 직관적이고 명확하게 이해할 수 있으며, 최적화를 더욱 효과적으로 수행할 수 있다.

## 마무리

Reflow에 대해 학습하면서 몇 가지 의문이 들었다. 이를 해결하기 위해 다양한 자료를 찾아보고, 브라우저의 렌더링 과정과 Performance 탭을 활용하여 더욱 깊이 있게 분석해보았다.

- `Reflow 관련 메서드나 프로퍼티를 사용하면 항상 Reflow가 발생하는가?`,
- `Render Tree가 만들어지기 이전에 어떻게 Reflow가 발생하는가?`,
- `Reflow가 발생하면 DOM에 Commit까지 이어지는가?`

이러한 의문과 고민이 없었다면, 다른 사람들에게 잘못된 정보를 전달했을지도 모른다. 이를 통해, 무엇인가를 배울 때는 항상 검증하는 과정이 필요하다는 것을 다시금 느꼈다. 검증을 통해 내용을 확실히 이해할 수 있을 뿐만 아니라, 더 오래 기억에 남게 된다.


Performance 분석을 통한 Reflow Deep Dive

Reflow 딥다이브 (feat. Performance 분석)


자바스크립트는 싱글 스레드 언어다. 하지만 웹에서 일어나는 일들을 보면 동시에 작업을 하는 것처럼 보인다. 이러한 이유는 이벤트 루프 덕분에 가능하다. 이벤트 루프를 알기 전에 다음과 같은 내용들을 알고 있어야 이해하기 쉽다.

- 자바스크립트 특징
- 자바스크립트 엔진
- 자바스크립트의 런타임 환경
- 동기와 비동기

## 자바스크립트의 특징

자바스크립트는 한 번에 한 가지의 일만 처리할 수 있는데, 이것을 `싱글 스레드`라고 부른다. 자바스크립트 엔진은 하나의 콜 스택으로 이루어져 있기 때문에 동시에 처리할 수 있는 능력이 없다.

> 스레드(thread)는 어떠한 프로그램 내에서, 특히 프로세스 내에서 실행되는 흐름의 단위를 말한다. 일반적으로 한 프로그램은 하나의 스레드를 가지고 있지만, 프로그램 환경에 따라 둘 이상의 스레드를 동시에 실행할 수 있다. 이러한 실행 방식을 멀티스레드(multithread)라고 한다.
> [위키백과](<https://ko.wikipedia.org/wiki/%EC%8A%A4%EB%A0%88%EB%93%9C_(%EC%BB%B4%ED%93%A8%ED%8C%85)>)

## 자바스크립트 엔진과 런타임 환경

자바스크립트는 ECMAScript를 기반으로 만들어진 프로그래밍 언어다. 자바스크립트 엔진은 ECMAScript 엔진이라고 말하는 게 더 정확하지만 일반적으로는 자바스크립트 엔진이라고 말을 한다. 즉 자바스크립트 엔진은 ECMAScript를 구현한 것을 말한다. 자바스크립트 런타임 환경은 자바스크립트가 어느 환경에서 실행되는지에 따라 달라진다. `fetch`, `DOM API`들은 브라우저에서 제공받는다. 따라서 자바스크립트는 ECMAScript + 호스트 객체(자바스크립트가 실행되는 환경에서 제공받는 객체)라고 볼 수 있다.

즉 우리가 말하는 자바스크립트가 런타임 환경을 말하는 것인지 ECMAScript인지 명확하게 구분할 필요가 있다. 앞으로 나올 이벤트 루프는 ECMASCript에 정의되어 있지 않은 내용이다. 자바스크립트 엔진이 아닌 자바스크립트 런타임 환경에서 사용되는 개념이다. 따라서 개념의 혼동이 오면 안 된다.

## 동기와 비동기

![Image](/posts/JavaScript/event-loop/snyc-async.png)
자바스크립트는 한 번에 한 가지의 일만 처리할 수 있기 때문에 요청한 작업에 완료 여부를 따져 순차적으로 처리를 한다. 이것을 동기라고 부른다. 동기는 순서가 보장되지만 요청한 작업이 끝날 때까지 블로킹 된다는 단점이 있다. 비동기는 요청한 작업에 완료 여부랑 상관없이 처리하는 것을 말한다. 즉 순서를 예측할 수 없지만, 작업이 끝날 때까지 기다리지 않고 다음 작업을 이어가기 때문에 동기보다 더 많은 일을 할 수 있다.

## 이벤트 루프

![Image](/posts/JavaScript/event-loop/event-loop.jpg)
자바스크립트는 싱글 스레드 언어이지만, 웹 어플리케이션에서는 많은 일이 동시에 일어나는 것처럼 보인다. 자바스크립트 엔진은 단일 호출 스택(CallStack)을 사용하며 요청이 들어올 때마다 해당 요청을 순차적으로 Call Stack에 담아 처리할 뿐이다. 위 그림에서 볼 수 있듯이 `fetch`, `setTimeout`등 비동기 함수들은 자바스크립트 엔진이 아닌 외부에 있는 Web API에서 처리를 하게 된다. 또한, Event Loop, Callback Queue도 마찬가지로 자바스크립트 엔진 외부에 구현되어 있다.

![Image](/posts/JavaScript/event-loop/nodejs-environment.jpg)

위 그림에서도 브라우저 환경과 비슷한 구조를 볼 수 있다. Node.js는 비동기 IO를 지원하기 위해 `libuv` 라이브러리를 사용하며, 이 라이브러리가 이벤트 루프를 제공한다. 자바스크립트 엔진은 비동기 작업을 위해 Node.js의 API를 호출하며 이때 넘겨진 콜백은 libuv의 이벤트 루프를 통해 스케쥴되고 실행된다.

자바스크립트가 싱글 스레드 기반의 언어라는 말은 ＂자바스크립트 엔진이 하나의 콜 스택을 사용한다＂는 관점에서만 사실이다. 실제 자바스크립트가 실행되는 환경인 브라우저, Node.js에서는 주로 여러 개의 스레드(멀티스레드)를 사용되며, 이러한 실행 환경이 하나의 Call Stack을 사용하는 자바스크립트 엔진과 상호 연동하기 위해 사용하는 장치가 바로 `이벤트 루프`인 것이다.

### CallStack

Call Stack은 자바스크립트 엔진 안에 있고, 함수를 호출하면 새로운 실행 컨텍스트가 생성되어 Call Stack에 추가된다. Call Stack은 먼저 들어온 게 나중에 나가는 FILO의 스택이다. 함수가 값을 반환하면 Call Stack에서 제거된다.

![Image](/posts/JavaScript/event-loop/callstack.gif)

위 gif와 같이 자바스크립트는 한 번에 하나의 작업만 처리할 수 있다. 만약 오래 걸리는 작업을 처리한다고 하면, 다른 작업은 처리할 수 없는 블로킹이 발생하게 된다.

### Web API

![Image](/posts/JavaScript/event-loop/web-api.gif)
Web APIs는 브라우저에서 제공하는 API 모음이라고 볼 수 있다. Web APIs의 일부분은 비동기적으로 실행되는 작업들을 처리한다. 대표적으로 `setTimeout`, `fetch`등이 있고, 콜백 함수 방식과 Promise 기반의 방식을 사용한다.

> 여기서 중요한 건 Web APIs가 모든 것을 비동기적으로 처리하지 않는다. `document.querySelector()` 또는 `console.log()`와 같은 메서드들은 동기적으로 처리된다.

### Callback Queue (Task Queue)

![Image](/posts/JavaScript/event-loop/callback-queue.gif)
`Callback Queue`는 Web APIs에서 처리된 콜백 함수를 대기하는 공간이고, 먼저 들어온 게 먼저 나가는 FIFO 구조다. Callback Queue에는 Task Queue와 Micro task Queue가 있다. 둘의 차이점은 우선순위에 따라 처리되는 순서가 달라진다는 점이다. 위 gif에서는 Geo location API를 다루고 있지만, Web APIs에서 처리된 콜백 함수들은 Callback Queue라는 공간에 대기한다고 볼 수 있다.

### Event Loop

![Image](/posts/JavaScript/event-loop/event-loop.gif)

Event Loop은 Call Stack이 비어있는 상태인지 지속해서 확인하고 비어있는 상태라면 Callback Queue에 있는 함수를 Call Stack으로 옮기고 실행시키는 역할을 한다.

위 gif에서는 `setTimeout`에 대한 예제다. 동작 과정을 설명해보자면 다음과 같다.

1. `setTimeout(() => console.log('2000ms'), 2000)`이 호출되면 CallStack에 푸시된다.
2. setTimeout의 콜백 함수는 Web APIs로 이동해 타이머를 시작한다. 이 때 CallStack에 남아있는 setTimeout 함수는 제거된다.
3. 비동기이기 때문에 바로 다음 함수인`setTimeout(() => console.log('100ms'), 100)`을 호출하고 CallStack에 푸시된다.
4. 2번과 마찬가지로 콜백 함수는 Web APIs로 이동해 타이머를 시작하고 CallStack에 남아있는 setTiemout 함수는 제거된다
5. `console.log('End of Script!')`가 실행되고 콘솔에 출력한다. (동기)
6. 100ms가 지나면 `() => console.log('100ms')` 콜백 함수가 Callback Queue 대기열에 추가된다.
7. 이벤트 루프가 CallStack이 비어있는 상태라는걸 감지한 후 `() => console.log('100ms')`함수를 CallStack에 옮기고 실행한다. console.log("100ms")가 출력된다.
8. 2000ms가 지나면 `() => console.log('2000ms')`콜백 함수가 Callback Queue 대기열에 추가된다.
9. CallStack이 비어있어, Callback Queue에 대기중인 `() => console.log('2000ms')` 콜백 함수를 CallStack에 옮기고 실행해 console.log("200ms")가 출력된다.

자바스크립트가 싱글 스레드 언어임에도 동시에 실행하는 것처럼 보였던 이유는 자바스크립트 엔진과 런타임 환경의 Web APIs와 Callback Queue 이 3가지를 이벤트 루프가 관리를 하고 있기 때문이다.

## Reference

- [자바스크립트와 이벤트 루프](https://meetup.nhncloud.com/posts/89)
- [Event Loop와 비동기](https://pozafly.github.io/javascript/event-loop-and-async/)
- [JavaScript Visualized: Event Loop, Web APIs, (Micro)task Queue](https://www.lydiahallie.com/blog/event-loop)

| 2024-08-10 Promise 내용은 추후에 추가됩니다.


자바스크립트는 한 번에 하나의 작업만 처리하는데, 동시에 처리되는 것처럼 보이는 이유는 무엇일까?