지나가는 21세기 개발자의 이야기

실무 Promise 아키텍처: 취소, 타임아웃, 재시도, 메모리와 작업 수명

토리나나 — Thu, 25 Jun 2026 08:00:48 +0900

Promise와 async/await 깊이 이해하기 4/4

들어가며

Promise 코드를 작성하는 것은 어렵지 않다.

어려운 것은 작업의 생명주기를 설계하는 일이다.

사용자가 페이지를 떠나면 요청을 중단해야 하는가?
timeout이 발생하면 실제 네트워크 요청도 종료되는가?
부모 작업이 실패하면 자식 작업은 어떻게 되는가?
어떤 오류를 재시도해도 안전한가?
영원히 pending인 Promise는 무엇을 메모리에 유지하는가?
하나가 아닌 여러 비동기 값은 무엇으로 표현해야 하는가?

Promise는 성공과 실패를 표현하지만 다음 요소를 직접 제공하지 않는다.

취소
timeout
자원 소유권
재시도 정책
멱등성
backpressure
구조적 동시성

이 요소들은 애플리케이션 아키텍처가 별도로 설계해야 한다.

1. Promise에는 취소가 없다

Promise는 작업 자체가 아니라 결과를 관찰하는 객체다.

이 차이는 취소 설계에서 중요하다.

const sharedRequest = fetch("/api/config");

const consumerA = sharedRequest.then(useForA);
const consumerB = sharedRequest.then(useForB);

하나의 요청 결과를 두 소비자가 함께 사용하고 있다.

consumerA가 더 이상 결과를 원하지 않는다고 해서 실제 네트워크 요청을 중단하면 consumerB도 영향을 받는다.

결과 관찰을 중단한다
≠

실제 작업을 중단한다

Promise 객체 자체에 보편적인 cancel()이 없는 이유를 이 관점에서 이해할 수 있다.

취소 권한은 Promise보다 작업을 생성하고 소유한 계층에 있어야 한다.

2. AbortController와 AbortSignal

웹 플랫폼에서는 취소 의사를 전달하는 표준 구조로 AbortController와 AbortSignal을 사용한다.

const controller = new AbortController();

const request = fetch("/api/users", {
  signal: controller.signal,
});

controller.abort();

각 역할은 다음과 같다.

AbortController
= 취소를 발생시키는 주체

AbortSignal
= 취소 상태와 이유를 전달하는 객체

Fetch는 요청에 연결된 AbortSignal을 통해 취소 상태를 관찰한다. DOM Standard는 signal의 취소 상태와 signal 결합·timeout 관련 연산을 정의하고, Fetch Standard는 Request가 AbortSignal을 갖도록 정의한다.

취소는 기본적으로 협력적이다.

controller.abort()
→ 취소 의사를 전달

실제 작업
→ signal을 관찰하고 정지해야 함

아무 연산이나 AbortSignal을 전달한다고 자동으로 중단되는 것은 아니다.

해당 API가 signal을 지원해야 한다.

3. timeout과 취소 신호 결합

DOM Standard에는 timeout signal과 여러 signal을 결합하는 구조가 정의되어 있다.

const timeoutSignal = AbortSignal.timeout(3000);

외부 취소와 timeout을 결합할 수 있다.

function createRequestSignal({
  signal,
  timeoutMs,
}) {
  const signals = [
    AbortSignal.timeout(timeoutMs),
  ];

  if (signal) {
    signals.push(signal);
  }

  return AbortSignal.any(signals);
}

사용 예시는 다음과 같다.

async function fetchJson(
  url,
  {
    signal,
    timeoutMs = 3000,
  } = {},
) {
  const requestSignal = createRequestSignal({
    signal,
    timeoutMs,
  });

  const response = await fetch(url, {
    signal: requestSignal,
  });

  if (!response.ok) {
    throw new Error(
      `HTTP ${response.status}: ${url}`,
    );
  }

  return response.json();
}

이제 작업은 두 경우 중 먼저 발생하는 이유로 취소된다.

외부 signal 취소
또는
timeout 만료

배포 환경에서 해당 정적 메서드를 지원하지 않는다면 AbortController와 setTimeout()으로 같은 정책을 직접 구현할 수 있다.

4. Promise.race timeout의 한계

다음 timeout 구현은 결과 대기를 중단하지만 실제 작업은 중단하지 않는다.

function timeout(ms) {
  return new Promise((_, reject) => {
    setTimeout(() => {
      reject(new Error("Timeout"));
    }, ms);
  });
}

await Promise.race([
  fetch("/api/data"),
  timeout(3000),
]);

3초 뒤 timeout Promise가 먼저 reject되면 호출자는 실패를 관찰한다.

그러나 원래 fetch() 요청은 계속 진행될 수 있다.

Promise.race에서 패배
≠ 작업 취소

실제 요청을 중단하려면 요청 자체에 signal을 전달해야 한다.

const response = await fetch("/api/data", {
  signal: AbortSignal.timeout(3000),
});

Promise 조합자는 결과 선택 정책을 정의할 뿐 작업 생명주기를 관리하지 않는다.

5. 취소, timeout, 실패는 같은 의미가 아니다

Promise API에서는 이 세 상황이 모두 rejection으로 나타날 수 있다.

네트워크 실패
사용자 취소
timeout

그러나 도메인 의미는 다르다.

실패
= 완료하려 했으나 성공하지 못함

취소
= 더 이상 완료를 원하지 않음

timeout
= 정해진 시간 안에 완료되지 않음

이를 모두 일반 Error로 처리하면 다음 문제가 생길 수 있다.

사용자 취소가 오류 모니터링에 보고됨
timeout과 서버 오류를 구분할 수 없음
취소된 요청이 자동 재시도됨
잘못된 사용자 안내 메시지가 표시됨

예외 클래스를 분리할 수 있다.

class TimeoutError extends Error {
  constructor(message = "작업 시간이 초과되었습니다.") {
    super(message);
    this.name = "TimeoutError";
  }
}

class UserCanceledError extends Error {
  constructor(message = "사용자가 작업을 취소했습니다.") {
    super(message);
    this.name = "UserCanceledError";
  }
}

또는 예상 가능한 결과를 tagged union으로 표현할 수 있다.

type OperationResult<T> =
  | {
      type: "success";
      value: T;
    }
  | {
      type: "canceled";
      reason: unknown;
    }
  | {
      type: "timeout";
      duration: number;
    }
  | {
      type: "failure";
      error: Error;
    };

Promise rejection은 제어 채널일 뿐이다.

도메인 오류 분류는 별도의 설계다.

6. Floating Promise와 작업 소유권

다음 함수는 두 작업을 시작하지만 기다리지 않는다.

async function updateUser() {
  saveAuditLog();
  sendNotification();

  return updateDatabase();
}

saveAuditLog()와 sendNotification()이 Promise를 반환한다고 가정해보자.

이 Promise들은 부모 함수의 완료 조건에 포함되지 않는다.

updateUser 완료
├─ saveAuditLog는 계속 실행될 수 있음
└─ sendNotification도 계속 실행될 수 있음

이런 Promise를 흔히 floating Promise라고 부른다.

문제는 작업의 소유자가 불분명해진다는 것이다.

오류는 누가 처리하는가?
요청이 끝난 뒤에도 실행되어도 되는가?
부모가 취소되면 자식은 어떻게 되는가?
테스트는 언제 완료되었다고 판단하는가?

부모가 자식 작업을 소유한다면 명시적으로 기다려야 한다.

async function updateUser({
  signal,
}) {
  await Promise.all([
    saveAuditLog({ signal }),
    sendNotification({ signal }),
    updateDatabase({ signal }),
  ]);
}

의도적인 fire-and-forget이라면 그 사실과 오류 정책을 드러내야 한다.

void sendTelemetry()
  .catch((error) => {
    reportTelemetryError(error);
  });

다음 코드보다는 낫다.

sendTelemetry();

void가 작업을 안전하게 만드는 것은 아니다.

다만 결과를 기다리지 않는 선택이 의도적이라는 것을 코드에 표시한다.

7. 구조적 동시성이라는 관점

구조적 동시성의 핵심 아이디어는 비동기 작업의 생명주기를 코드 블록의 생명주기에 묶는 것이다.

부모 scope가 끝나기 전에
→ 자식 작업을 기다린다.

부모가 취소되면
→ 자식에게 취소를 전달한다.

자식이 실패하면
→ 형제 작업 처리 정책을 명시한다.

JavaScript Promise는 이러한 규칙을 자동으로 강제하지 않는다.

개발자가 다음 수단으로 직접 구조를 만들어야 한다.

await
Promise.all
AbortSignal 전달
try/finally
자원 cleanup
명시적인 오류 경계

다음 함수는 작업 수명이 함수 블록 안에 묶여 있다.

async function loadPage({
  signal,
}) {
  const userPromise = loadUser({
    signal,
  });

  const settingsPromise = loadSettings({
    signal,
  });

  const [user, settings] = await Promise.all([
    userPromise,
    settingsPromise,
  ]);

  return {
    user,
    settings,
  };
}

loadPage()의 Promise가 완료될 때는 자신이 소유한 두 작업도 완료된 상태다.

8. 재시도 대상은 Promise가 아니라 함수다

다음 구조로는 작업을 다시 실행할 수 없다.

const promise = fetch("/api/data");

await retry(promise);

이미 생성된 Promise를 다시 기다려도 같은 결과만 관찰한다.

재시도 함수는 새로운 Promise를 만들 수 있는 함수를 받아야 한다.

await retry(() => {
  return fetch("/api/data");
});

signal을 지원하는 지연 함수를 먼저 작성해보자.

function delay(
  ms,
  {
    signal,
  } = {},
) {
  return new Promise((resolve, reject) => {
    if (signal?.aborted) {
      reject(signal.reason);
      return;
    }

    const timerId = setTimeout(() => {
      cleanup();
      resolve();
    }, ms);

    function handleAbort() {
      clearTimeout(timerId);
      cleanup();
      reject(signal.reason);
    }

    function cleanup() {
      signal?.removeEventListener(
        "abort",
        handleAbort,
      );
    }

    signal?.addEventListener(
      "abort",
      handleAbort,
      {
        once: true,
      },
    );
  });
}

재시도 함수는 다음처럼 작성할 수 있다.

async function retry(
  operation,
  {
    attempts = 3,
    baseDelayMs = 200,
    signal,
    shouldRetry = () => true,
  } = {},
) {
  let lastError;

  for (
    let attempt = 1;
    attempt <= attempts;
    attempt += 1
  ) {
    signal?.throwIfAborted();

    try {
      return await operation({
        attempt,
        signal,
      });
    } catch (error) {
      lastError = error;

      const isLastAttempt =
        attempt === attempts;

      if (
        isLastAttempt ||
        !shouldRetry(error, attempt)
      ) {
        throw error;
      }

      const exponentialDelay =
        baseDelayMs * 2 ** (attempt - 1);

      const jitter =
        Math.random() * baseDelayMs;

      await delay(
        exponentialDelay + jitter,
        {
          signal,
        },
      );
    }
  }

  throw lastError;
}

사용 예시는 다음과 같다.

const response = await retry(
  ({ signal }) => {
    return fetch("/api/data", {
      signal,
    });
  },
  {
    attempts: 3,
    signal,
    shouldRetry(error) {
      return error instanceof TypeError;
    },
  },
);

9. 재시도와 멱등성

기술적으로 재시도할 수 있다고 해서 안전한 것은 아니다.

GET 요청
→ 일반적으로 재시도하기 쉬움

결제 승인
→ 중복 결제 가능

이메일 전송
→ 중복 발송 가능

주문 생성
→ 중복 주문 가능

재시도 안전성은 Promise가 아니라 작업의 도메인 의미에 달려 있다.

부수 효과가 있는 요청에는 다음과 같은 설계가 필요할 수 있다.

멱등성 키
중복 요청 식별자
서버 측 deduplication
트랜잭션
처리 상태 조회
보상 작업

예를 들어 결제 요청에 고유한 멱등성 키를 전달할 수 있다.

await retry(
  ({ signal }) => {
    return fetch("/api/payments", {
      method: "POST",
      headers: {
        "Idempotency-Key": paymentRequestId,
      },
      body: JSON.stringify(payment),
      signal,
    });
  },
);

재시도 정책은 오류 종류에 따라서도 달라져야 한다.

일시적 네트워크 실패
→ 재시도 가능

인증 실패
→ 자동 재시도 의미 없음

유효성 검사 실패
→ 같은 입력으로 재시도해도 실패

서버 rate limit
→ Retry-After 정책 고려

10. 예상 가능한 실패와 예외적 실패

모든 비정상 결과를 rejection으로 표현할 필요는 없다.

사용자 검색 결과가 없는 상황을 생각해보자.

검색 결과 없음

이것은 시스템 오류가 아니라 정상적인 도메인 결과일 수 있다.

type SearchResult<T> =
  | {
      type: "found";
      value: T;
    }
  | {
      type: "not-found";
    };

구현은 다음과 같이 만들 수 있다.

async function searchUser(
  userId,
  {
    signal,
  },
) {
  const response = await fetch(
    `/api/users/${userId}`,
    {
      signal,
    },
  );

  if (response.status === 404) {
    return {
      type: "not-found",
    };
  }

  if (!response.ok) {
    throw new Error(
      `HTTP ${response.status}`,
    );
  }

  return {
    type: "found",
    value: await response.json(),
  };
}

제어 흐름을 다음처럼 분리할 수 있다.

예상 가능한 도메인 분기
→ fulfillment 안의 tagged result

예외적 인프라 실패
→ rejection

모든 상황을 rejection으로 보내면 정상적인 분기까지 try/catch에 의존하게 된다.

11. pending Promise와 메모리 유지

Promise는 후속 반응 목록을 유지한다.

각 반응 handler는 클로저이므로 외부 변수를 참조할 수 있다.

const never = new Promise(() => {});

function registerHandler() {
  const largeData = new Array(
    1_000_000,
  ).fill("data");

  never.then(() => {
    console.log(largeData.length);
  });
}

never가 영원히 settle되지 않는다면 등록된 handler도 계속 필요하다.

handler가 largeData를 참조하므로 해당 데이터도 도달 가능한 상태로 남을 수 있다.

pending Promise
  └─ fulfillment reaction
       └─ handler closure
            └─ largeData

이를 반복하면 반응과 데이터가 계속 누적될 수 있다.

setInterval(registerHandler, 1000);

Promise가 settle되면 명세 알고리즘은 저장된 반응 목록을 꺼내 Job을 생성하고 Promise 내부 목록을 정리한다. 반대로 영원히 pending인 Promise는 반응 목록을 계속 유지할 수 있다.

Promise 자체가 메모리 누수는 아니다.

문제는 다음 조합이다.

장기간 pending인 Promise
+
계속 추가되는 handler
+
handler가 참조하는 큰 객체

12. 중단된 async 함수의 상태

다음 async 함수는 await에서 영원히 중단된다.

async function holdLargeData() {
  const largeData = new Array(
    1_000_000,
  ).fill("data");

  await neverSettlingPromise;

  return largeData.length;
}

await 이후에 largeData가 필요하다.

따라서 중단된 실행은 재개를 위해 필요한 상태를 보존해야 한다.

중단 지점
지역 변수
렉시컬 환경
외부 Promise 결과
재개 함수

ECMAScript의 Await 과정도 현재 async 실행 컨텍스트를 캡처한 반응을 생성하고, Promise가 완료되면 해당 컨텍스트를 재개하도록 정의한다.

엔진이 불필요한 값을 최적화할 수는 있지만, 향후 실행에서 필요할 수 있는 상태는 의미론적으로 유지되어야 한다.

따라서 다음 가정은 안전하지 않다.

현재 실행 중이 아닌 async 함수는
메모리를 거의 사용하지 않을 것이다.

13. Promise는 여러 값의 흐름을 표현하지 못한다

Promise는 단 하나의 최종 결과를 표현한다.

0회 또는 1회의 settlement

다음과 같이 시간에 따라 계속 값이 발생하는 시스템에는 맞지 않을 수 있다.

WebSocket 메시지
마우스 이벤트
스트리밍 응답
파일 청크
실시간 가격 데이터

단일 메시지를 Promise로 기다리는 것은 가능하다.

function nextMessage(socket) {
  return new Promise((resolve) => {
    socket.addEventListener(
      "message",
      resolve,
      {
        once: true,
      },
    );
  });
}

하지만 지속적인 메시지 흐름에는 다음 문제들이 생긴다.

생산자가 소비자보다 빠르면 어떻게 하는가?
버퍼는 얼마나 유지하는가?
소비자가 중단하면 listener는 어떻게 정리하는가?
일부 메시지를 버릴 수 있는가?

이런 문제에는 다음 추상화가 더 적합할 수 있다.

AsyncIterator
ReadableStream
Observable
이벤트 채널
메시지 큐

Async Iterator는 next() 호출이 다음 IteratorResult를 담은 Promise를 반환하는 프로토콜이며, for await...of로 소비할 수 있다.

for await (const chunk of stream) {
  await processChunk(chunk);
}

이 구조에서는 다음 값을 요청하는 시점과 처리 완료 시점을 연결해 backpressure를 표현할 수 있다.

Promise
= 하나의 최종 결과

AsyncIterator
= 시간에 따라 도착하는 여러 결과

14. 종합 예제: 필수 데이터, 선택 데이터, timeout, 취소

대시보드에 다음 데이터가 필요하다고 가정하자.

사용자 정보
= 필수

주문 정보
= 필수

추천 정보
= 선택

분석 정보
= 선택

전체 timeout
= 5초

페이지 이탈
= 모든 요청 취소

HTTP 오류를 표현하는 클래스를 만든다.

class HttpError extends Error {
  constructor(
    status,
    url,
  ) {
    super(`HTTP ${status}: ${url}`);

    this.name = "HttpError";
    this.status = status;
    this.url = url;
  }
}

JSON 요청 함수를 작성한다.

async function fetchJson(
  url,
  {
    signal,
  },
) {
  const response = await fetch(url, {
    signal,
  });

  if (!response.ok) {
    throw new HttpError(
      response.status,
      url,
    );
  }

  return response.json();
}

선택 데이터의 실패를 값으로 변환한다.

단, 전체 취소는 삼키지 않는다.

async function optional(
  operation,
  {
    signal,
  },
) {
  try {
    return {
      ok: true,
      value: await operation(),
    };
  } catch (error) {
    if (signal.aborted) {
      throw signal.reason ?? error;
    }

    return {
      ok: false,
      error,
    };
  }
}

대시보드 로더는 다음과 같다.

async function loadDashboard(
  userId,
  {
    signal,
    timeoutMs = 5000,
  } = {},
) {
  const signals = [
    AbortSignal.timeout(timeoutMs),
  ];

  if (signal) {
    signals.push(signal);
  }

  const requestSignal =
    AbortSignal.any(signals);

  const userPromise = fetchJson(
    `/api/users/${userId}`,
    {
      signal: requestSignal,
    },
  );

  const ordersPromise = fetchJson(
    `/api/users/${userId}/orders`,
    {
      signal: requestSignal,
    },
  );

  const recommendationsPromise = optional(
    () => {
      return fetchJson(
        `/api/users/${userId}/recommendations`,
        {
          signal: requestSignal,
        },
      );
    },
    {
      signal: requestSignal,
    },
  );

  const analyticsPromise = optional(
    () => {
      return fetchJson(
        `/api/users/${userId}/analytics`,
        {
          signal: requestSignal,
        },
      );
    },
    {
      signal: requestSignal,
    },
  );

  const [
    user,
    orders,
    recommendations,
    analytics,
  ] = await Promise.all([
    userPromise,
    ordersPromise,
    recommendationsPromise,
    analyticsPromise,
  ]);

  return {
    user,
    orders,

    recommendations:
      recommendations.ok
        ? recommendations.value
        : [],

    analytics:
      analytics.ok
        ? analytics.value
        : null,

    warnings: [
      recommendations.ok
        ? null
        : recommendations.error,

      analytics.ok
        ? null
        : analytics.error,
    ].filter(Boolean),
  };
}

React에서는 컴포넌트 생명주기와 연결할 수 있다.

useEffect(() => {
  const controller = new AbortController();

  loadDashboard(userId, {
    signal: controller.signal,
  })
    .then(setDashboard)
    .catch((error) => {
      if (controller.signal.aborted) {
        return;
      }

      setError(error);
    });

  return () => {
    controller.abort(
      new DOMException(
        "Page changed",
        "AbortError",
      ),
    );
  };
}, [userId]);

이 설계에는 다음 정책이 명시되어 있다.

독립 작업은 동시에 시작한다.

필수 데이터 실패
→ 전체 작업 실패

선택 데이터 실패
→ 부분 결과와 warning 반환

페이지 이탈
→ 모든 요청 취소

5초 초과
→ 모든 요청 timeout

취소
→ 선택 데이터 실패로 오인하지 않음

중요한 것은 사용한 문법이 아니다.

다음 설계 결정을 코드로 드러낸 것이 핵심이다.

작업 소유자는 누구인가?
어떤 실패가 전체 실패인가?
부분 실패를 허용하는가?
작업은 언제 종료되어야 하는가?
취소는 어디까지 전달되는가?

15. 실무 설계 체크리스트

비동기 API를 설계할 때 다음 질문을 확인할 수 있다.

이 함수 호출 시 작업이 즉시 시작되는가?

같은 Promise를 재사용하는가,
매번 새 작업을 만드는가?

timeout은 누가 책임지는가?

외부에서 작업을 취소할 수 있는가?

부모 취소가 자식 작업에 전파되는가?

필수 작업과 선택 작업은 무엇인가?

부분 실패를 허용하는가?

어떤 오류를 재시도할 수 있는가?

재시도해도 부수 효과가 중복되지 않는가?

동시에 몇 개의 작업까지 실행할 것인가?

영원히 pending될 가능성이 있는가?

handler가 큰 객체를 오래 참조하지 않는가?

하나의 결과인가,
여러 값의 흐름인가?

마무리

Promise는 결과와 오류를 표현하는 강력한 추상화다.

그러나 Promise만으로는 완전한 비동기 아키텍처를 만들 수 없다.

실무에서는 다음 층이 추가로 필요하다.

취소
timeout
작업 소유권
오류 분류
재시도
멱등성
동시성 제한
메모리 관리
backpressure

좋은 비동기 코드는 단순히 모든 함수를 async로 만드는 코드가 아니다.

작업이 언제 시작되고, 누가 소유하며, 언제 종료되고, 실패와 취소가 어디로 전파되는지를 명시한 코드다.

참고 자료

WHATWG DOM Standard, AbortController와 AbortSignal.
WHATWG Fetch Standard, Request와 AbortSignal.
ECMA-262, Promise 반응 목록과 Await 실행 컨텍스트.
ECMA-262, Async Iterator Interface.

Promise 동시성 설계: 순차 실행, 조합자, Critical Path

토리나나 — Wed, 24 Jun 2026 18:10:15 +0900

Promise와 async/await 깊이 이해하기 3/4

들어가며

async/await 코드는 읽기 쉽다.

그러나 너무 자연스럽게 읽히기 때문에 오히려 불필요한 순차 실행을 만들기 쉽다.

const user = await fetchUser();
const settings = await fetchSettings();

두 작업이 서로 독립적이라면 이 코드는 존재하지 않는 의존 관계를 만들어낸다.

fetchUser 완료
        ↓
fetchSettings 시작

Promise 동시성 설계의 핵심은 Promise.all()을 외우는 것이 아니다.

다음 질문에 답하는 것이다.

어떤 작업이 다른 작업의 결과를 필요로 하는가?
어떤 작업은 동시에 시작할 수 있는가?
실패했을 때 나머지 작업은 어떻게 해야 하는가?
동시에 몇 개까지 실행해도 되는가?

1. 동시성과 병렬성

동시성과 병렬성은 같은 개념이 아니다.

동시성
= 여러 작업의 진행 구간이 겹칠 수 있도록 구조화하는 것

병렬성
= 여러 실행 주체가 같은 시간에 실제로 작업하는 것

브라우저의 메인 JavaScript 실행은 일반적으로 한 번에 하나의 JavaScript 작업을 수행한다.

그러나 네트워크 요청처럼 외부 시스템에 위임된 작업은 여러 개가 동시에 진행될 수 있다.

const a = fetch("/api/a");
const b = fetch("/api/b");
const c = fetch("/api/c");

세 Promise를 만들었다고 JavaScript 코드 세 개가 메인 스레드에서 병렬 실행되는 것은 아니다.

하지만 세 네트워크 요청의 대기 시간은 겹칠 수 있다.

JavaScript 병렬 실행
≠

외부 I/O 작업의 동시 진행

2. 비동기 프로그램은 의존성 그래프다

비동기 작업을 방향성 그래프로 표현해보자.

G = (V, E)

V는 작업이고 E는 의존 관계다.

A → B

는 B를 시작하거나 완료하기 위해 A의 결과가 필요하다는 뜻이다.

예를 들어 다음 코드는 실제 의존성이 있다.

const user = await fetchUser();

const orders = await fetchOrders(user.id);

fetchOrders()에는 user.id가 필요하다.

fetchUser → fetchOrders

이 순차 실행은 올바르다.

반면 다음 작업들이 서로 독립적이라고 가정해보자.

const locale = await fetchLocale();
const featureFlags = await fetchFeatureFlags();

코드는 다음 의존성을 만든다.

fetchLocale → fetchFeatureFlags

하지만 실제 요구사항에는 이 간선이 없다.

fetchLocale

fetchFeatureFlags

성능 최적화는 단순히 await을 줄이는 작업이 아니다.

실제로 존재하지 않는 의존 간선을 제거하는 작업이다.

3. Critical Path

전체 작업 완료 시간은 가장 긴 의존 경로에 의해 제한된다.

단순화하면 다음과 같다.

전체 완료 시간
≥ 가장 긴 의존 경로의 작업 시간 합

두 작업을 순차 실행하면 다음과 같다.

const a = await taskA();
const b = await taskB();

예상 시간은 다음에 가깝다.

T ≈ Ta + Tb

두 작업을 함께 시작하면 다음과 같다.

const aPromise = taskA();
const bPromise = taskB();

const [a, b] = await Promise.all([
  aPromise,
  bPromise,
]);

예상 시간은 다음에 가깝다.

T ≈ max(Ta, Tb) + 조정 비용

예를 들어 두 요청에 각각 1초가 걸린다고 하자.

순차 실행
≈ 2초

동시 시작
≈ 1초

실제 시간은 네트워크, 서버, 브라우저 요청 제한 등 여러 환경 요인의 영향을 받지만, 의존성 그래프 관점에서는 이 차이가 핵심이다.

4. 작업 시작과 결과 대기를 분리하라

다음 코드는 순차 실행이다.

const user = await fetchUser();
const settings = await fetchSettings();

fetchSettings() 호출 자체가 첫 번째 요청 완료 이후에 일어난다.

동시 실행을 원한다면 먼저 작업을 시작해야 한다.

const userPromise = fetchUser();
const settingsPromise = fetchSettings();

const user = await userPromise;
const settings = await settingsPromise;

또는 다음처럼 결합할 수 있다.

const [user, settings] = await Promise.all([
  fetchUser(),
  fetchSettings(),
]);

중요한 사실은 Promise.all()이 작업을 시작하는 것이 아니라는 점이다.

fetchUser();
fetchSettings();

함수를 호출하는 시점에 작업이 시작된다.

Promise.all()은 이미 시작된 작업들의 완료 조건을 결합한다.

함수 호출
= 작업 시작

Promise.all
= 여러 결과의 완료 규칙 정의

await
= 결합된 결과를 현재 async 흐름에서 기다림

5. 의존성과 독립성이 섞인 경우

실무에서는 모든 작업이 완전히 독립적이거나 완전히 순차적이지 않다.

다음 요구사항을 생각해보자.

사용자 정보가 있어야 주문 정보를 요청할 수 있다.
설정 정보는 사용자 정보와 독립적이다.

좋지 않은 구조는 다음과 같다.

const user = await fetchUser();
const orders = await fetchOrders(user.id);
const settings = await fetchSettings();

전체 그래프가 불필요하게 직렬화된다.

user → orders → settings

더 나은 구조는 독립 작업을 먼저 시작하는 것이다.

const userPromise = fetchUser();
const settingsPromise = fetchSettings();

const user = await userPromise;

const ordersPromise = fetchOrders(user.id);

const [orders, settings] = await Promise.all([
  ordersPromise,
  settingsPromise,
]);

그래프는 다음과 같다.

fetchUser → fetchOrders
       \
        독립적으로 fetchSettings 진행

이 구조에서 critical path는 다음 둘 중 긴 경로다.

fetchUser + fetchOrders

fetchSettings

6. Promise 조합자는 실패 정책을 표현한다

Promise 조합자는 단순한 편의 함수가 아니다.

각 조합자는 서로 다른 완료 조건과 실패 정책을 나타낸다.

조합자성공 조건실패 조건의미

Promise.all	모든 입력 fulfill	하나라도 reject	모두 필요
Promise.allSettled	모든 입력 settle	입력 rejection으로는 집계 Promise가 reject되지 않음	모든 결과 관찰
Promise.any	하나라도 fulfill	모두 reject	하나의 성공이면 충분
Promise.race	하나가 먼저 settle	첫 settlement가 rejection이면 reject	가장 빠른 결과 채택

ECMAScript 명세도 각 조합자의 완료 규칙을 별도로 정의한다. Promise.all()은 하나라도 reject되면 거부되고, allSettled()는 모든 상태를 모으며, any()는 첫 성공 또는 전체 실패를, race()는 첫 settlement를 채택한다.

7. Promise.all: 모두 필요하다

const [user, orders, settings] = await Promise.all([
  fetchUser(),
  fetchOrders(),
  fetchSettings(),
]);

세 결과가 모두 있어야 다음 단계로 갈 수 있을 때 사용한다.

결과 배열은 작업 완료 순서가 아니라 입력 순서를 보존한다.

const slow = new Promise((resolve) => {
  setTimeout(() => resolve("slow"), 100);
});

const fast = Promise.resolve("fast");

const result = await Promise.all([
  slow,
  fast,
]);

console.log(result);

출력은 다음과 같다.

["slow", "fast"]

fast가 먼저 완료되어도 결과 인덱스는 입력 순서를 따른다.

8. Promise.allSettled: 부분 실패를 데이터로 다룬다

모든 요청 결과를 확인해야 하고 일부 실패를 허용해야 한다면 Promise.allSettled()가 적합하다.

const results = await Promise.allSettled([
  fetchMainContent(),
  fetchRecommendations(),
  fetchAdvertisement(),
]);

결과는 다음 형태를 가진다.

[
  {
    status: "fulfilled",
    value: mainContent,
  },
  {
    status: "rejected",
    reason: error,
  },
  {
    status: "fulfilled",
    value: advertisement,
  },
]

처리 예시는 다음과 같다.

for (const result of results) {
  if (result.status === "fulfilled") {
    render(result.value);
    continue;
  }

  reportError(result.reason);
}

allSettled()는 실패를 없애는 것이 아니다.

실패를 예외 제어 흐름에서 명시적인 결과 데이터로 바꿔준다.

9. Promise.any: 하나의 성공이면 충분하다

여러 공급자 중 하나만 성공해도 되는 경우가 있다.

const data = await Promise.any([
  fetchFromPrimaryCDN(),
  fetchFromSecondaryCDN(),
  fetchFromBackupServer(),
]);

먼저 reject된 작업이 있어도 다른 작업의 성공 가능성을 계속 기다린다.

모든 작업이 실패하면 AggregateError로 reject된다.

try {
  await Promise.any([
    Promise.reject(new Error("A failed")),
    Promise.reject(new Error("B failed")),
  ]);
} catch (error) {
  console.log(error instanceof AggregateError);
  console.log(error.errors);
}

Promise.any()는 “가장 빨리 끝난 작업”이 아니라 “가장 먼저 성공한 작업”을 선택한다.

10. Promise.race: 첫 settlement를 채택한다

const result = await Promise.race([
  operationA(),
  operationB(),
]);

race()는 첫 성공을 고르는 것이 아니다.

가장 먼저 settle된 Promise의 상태를 채택한다.

첫 번째 Promise가 fulfill
→ 결과 fulfill

첫 번째 Promise가 reject
→ 결과 reject

따라서 timeout 구현에 자주 사용된다.

function timeout(ms) {
  return new Promise((_, reject) => {
    setTimeout(() => {
      reject(new Error("Timeout"));
    }, ms);
  });
}

const result = await Promise.race([
  fetchData(),
  timeout(3000),
]);

그러나 이 코드는 fetchData()를 취소하지 않는다.

호출자가 timeout 결과를 먼저 관찰할 뿐, 원래 작업은 계속 실행될 수 있다.

11. fail-fast는 cancellation이 아니다

Promise.all()은 하나의 입력이 reject되면 집계 Promise를 빠르게 reject한다.

await Promise.all([
  saveUser(),
  saveOrder(),
  sendNotification(),
]);

saveOrder()가 먼저 실패해도 나머지 작업이 자동으로 중단되는 것은 아니다.

Promise.all 결과
→ 빠르게 reject

saveUser 작업
→ 이미 실행 중일 수 있음

sendNotification 작업
→ 계속 진행될 수 있음

Promise.all()이 제공하는 것은 다음뿐이다.

결과 관찰의 fail-fast

다음은 제공하지 않는다.

작업 취소
부수 효과 롤백
트랜잭션
원자성

예를 들어 다음 구조에서 주문 저장이 실패해도 사용자 저장이나 알림 전송이 이미 완료될 수 있다.

await Promise.all([
  updateUser(),
  createOrder(),
  sendEmail(),
]);

all-or-nothing이 필요하다면 Promise 조합자가 아니라 별도의 도메인 설계가 필요하다.

데이터베이스 트랜잭션
보상 작업
멱등성 키
사가 패턴
명시적 취소 신호

12. 조합자는 iterable을 동기적으로 소비한다

다음 호출은 비동기적으로만 동작하는 것처럼 보인다.

Promise.all(iterable);

그러나 Promise.all()은 전달받은 iterable을 현재 호출 흐름에서 순회한다.

const iterable = {
  *[Symbol.iterator]() {
    console.log("yield 1");
    yield Promise.resolve(1);

    console.log("yield 2");
    yield Promise.resolve(2);
  },
};

const resultPromise = Promise.all(iterable);

console.log("after");

출력은 다음과 같다.

yield 1
yield 2
after

iterator에서 값을 꺼내고 각 값을 Promise로 정규화하는 과정은 호출 중에 진행된다.

ECMAScript의 Promise 조합자 알고리즘도 전달받은 iterator를 순회하면서 각 원소를 Promise로 변환하고 반응을 연결한다.

따라서 무한 iterable을 넘기면 호출 자체가 끝나지 않을 수 있다.

function* infinite() {
  while (true) {
    yield Promise.resolve(1);
  }
}

Promise.all(infinite());

13. 무제한 동시성 문제

다음 코드는 간결하다.

const profiles = await Promise.all(
  users.map((user) => {
    return fetchProfile(user.id);
  }),
);

사용자가 10명이라면 문제가 없을 수 있다.

10만 명이라면 호출 즉시 매우 많은 작업을 시작하려 할 수 있다.

병목은 Promise 객체 자체가 아니라 작업이 사용하는 자원이다.

네트워크 연결
브라우저 요청 큐
서버 rate limit
메모리
데이터베이스 연결
외부 API 사용량
파일 디스크립터

독립 작업이라고 해서 모두 동시에 시작하는 것이 최적은 아니다.

14. 제한된 동시성 구현

다음 함수는 동시에 실행할 worker 수를 제한한다.

async function mapConcurrent(
  items,
  limit,
  mapper,
) {
  if (!Number.isInteger(limit) || limit < 1) {
    throw new RangeError(
      "limit은 1 이상의 정수여야 합니다.",
    );
  }

  const results = new Array(items.length);

  let nextIndex = 0;

  async function worker() {
    while (true) {
      const index = nextIndex;
      nextIndex += 1;

      if (index >= items.length) {
        return;
      }

      results[index] = await mapper(
        items[index],
        index,
      );
    }
  }

  const workerCount = Math.min(
    limit,
    items.length,
  );

  await Promise.all(
    Array.from(
      { length: workerCount },
      () => worker(),
    ),
  );

  return results;
}

사용 방법은 다음과 같다.

const profiles = await mapConcurrent(
  users,
  5,
  async (user) => {
    const response = await fetch(
      `/api/users/${user.id}`,
    );

    if (!response.ok) {
      throw new Error(
        `HTTP ${response.status}`,
      );
    }

    return response.json();
  },
);

동시에 최대 다섯 개의 작업만 진행된다.

worker 1: item 0 → item 5 → ...
worker 2: item 1 → item 6 → ...
worker 3: item 2 → item 7 → ...
worker 4: item 3 → item 8 → ...
worker 5: item 4 → item 9 → ...

결과는 완료 순서가 아니라 원래 입력 순서에 저장된다.

이 구현에도 한계는 있다.

mapper 하나가 실패하면 반환된 Promise.all()은 reject되지만, 이미 실행 중인 다른 mapper 작업은 자동으로 중단되지 않는다.

동시성 제한
= 새 작업 시작 수 제한

실행 중 작업 취소
= 별도의 AbortSignal 필요

취소와 작업 수명은 4부에서 다룬다.

15. Promise는 CPU 병렬화 도구가 아니다

다음 코드는 세 계산을 Promise로 감쌌지만 병렬 계산을 만들지 않는다.

const results = await Promise.all([
  Promise.resolve().then(() => heavyA()),
  Promise.resolve().then(() => heavyB()),
  Promise.resolve().then(() => heavyC()),
]);

각 handler는 여전히 같은 JavaScript 실행 주체에서 순서대로 실행된다.

Promise 동시성
≠ CPU 병렬 실행

CPU 집약 작업을 실제로 분산하려면 별도의 실행 주체가 필요하다.

브라우저에서는 대표적으로 Web Worker를 사용할 수 있다.

네트워크 대기 시간 겹치기
→ Promise 동시성

CPU 계산을 다른 코어에서 실행
→ Worker 등 별도 실행 환경

16. 동시성 설계 원칙

비동기 코드를 작성할 때 다음 순서로 생각하면 좋다.

첫째, 작업 사이의 실제 의존성을 찾는다

B가 A의 결과를 필요로 하는가?

필요하다면 순차 실행이 맞다.

둘째, 독립 작업은 먼저 시작한다

const aPromise = taskA();
const bPromise = taskB();

셋째, 요구사항에 맞는 완료 정책을 고른다

모두 필요
→ Promise.all

모든 성공과 실패를 확인
→ Promise.allSettled

하나의 성공이면 충분
→ Promise.any

첫 결과만 필요
→ Promise.race

넷째, 동시 실행 수를 제한해야 하는지 판단한다

데이터 수가 작고 통제됨
→ Promise.all 가능

데이터 수가 크거나 외부 제한 존재
→ worker pool 또는 queue

다섯째, 실패 시 실행 중인 작업을 어떻게 할지 결정한다

계속 진행
중단
부분 결과 사용
재시도
보상 작업 실행

마무리

Promise 동시성 설계의 핵심은 문법이 아니라 그래프다.

작업
의존 관계
실패 전파
자원 제한
완료 조건

await은 동시성을 만들지 않는다.

Promise.all()도 작업을 시작하지 않는다.

작업을 시작하는 것
= 비동기 함수를 호출하는 것

결과를 결합하는 것
= Promise 조합자를 사용하는 것

현재 흐름을 중단하는 것
= await하는 것

좋은 비동기 코드는 단순히 Promise.all()을 많이 사용하는 코드가 아니다.

실제 의존 관계만 남기고, 시스템이 감당할 수 있는 범위 안에서 작업을 진행하며, 실패 정책을 명시적으로 표현한 코드다.

참고 자료

ECMA-262, Promise Concurrency Methods.
ECMA-262, Promise Objects 및 Promise Reaction 처리.

async/await의 실행 원리: Job, 마이크로태스크, 실행 컨텍스트

토리나나 — Tue, 23 Jun 2026 23:05:44 +0900

Promise와 async/await 깊이 이해하기 2/4

들어가며

async/await은 Promise 코드를 동기 코드처럼 읽을 수 있게 만든다.

async function loadUser() {
  const response = await fetch("/api/user");
  const user = await response.json();

  return user;
}

하지만 코드가 동기적으로 보이는 것과 실제로 동기적으로 실행되는 것은 다르다.

await은 스레드를 멈추지 않는다.

Promise를 제거하지도 않는다.

실제로는 다음과 같은 과정이 일어난다.

async 함수 실행
→ await 지점에서 실행 컨텍스트 중단
→ Promise 반응 등록
→ 호출자에게 제어권 반환
→ Promise 완료
→ Job을 통해 실행 컨텍스트 재개

이를 정확히 이해하려면 JavaScript 언어 명세와 브라우저 호스트 환경을 분리해서 봐야 한다.

1. ECMAScript와 브라우저는 서로 다른 층이다

JavaScript의 Promise 실행 순서를 설명할 때 흔히 “마이크로태스크 큐에 들어간다”고 말한다.

실무적으로는 맞지만, 명세 수준에서는 두 층이 존재한다.

ECMAScript
= Promise와 Promise Job의 의미를 정의

HTML 호스트 환경
= Job을 마이크로태스크 큐와 이벤트 루프에 통합

ECMAScript는 Promise 반응을 실행할 Job을 만든다.

그 Job을 실제로 언제 실행할지는 HostEnqueuePromiseJob이라는 호스트 훅에 맡긴다.

브라우저에서는 HTML 명세가 이 Job을 마이크로태스크 처리 모델과 연결한다.

따라서 다음 표현이 더 정확하다.

Promise handler는 ECMAScript의 Promise Reaction Job이다.

브라우저에서는 이 Job이 마이크로태스크로 처리된다.

이 분리 때문에 브라우저와 다른 JavaScript 런타임의 세부 큐 정책이 완전히 같을 필요는 없다.

2. task와 microtask

브라우저 이벤트 루프를 단순화하면 다음과 같다.

task 하나 실행
→ JavaScript 호출 스택이 비워짐
→ microtask checkpoint 수행
→ 렌더링 기회가 있으면 렌더링
→ 다음 task 실행

대표적인 task에는 다음이 있다.

초기 스크립트 실행
setTimeout callback
사용자 입력 이벤트
네트워크 이벤트
메시지 이벤트

대표적인 microtask에는 다음이 있다.

Promise reaction
queueMicrotask callback
일부 DOM 반응

HTML 명세의 microtask checkpoint는 큐에 있는 마이크로태스크를 하나만 실행하지 않는다.

큐가 빌 때까지 계속 실행한다. 실행 중 새로운 마이크로태스크가 추가되면 그 작업도 같은 checkpoint에서 처리된다.

3. 기본 실행 순서 분석

다음 코드를 보자.

console.log("A");

setTimeout(() => {
  console.log("D");
}, 0);

Promise.resolve()
  .then(() => {
    console.log("B");
  })
  .then(() => {
    console.log("C");
  });

console.log("E");

출력은 다음과 같다.

A
E
B
C
D

실행 흐름을 나누면 다음과 같다.

현재 task

console.log("A")
setTimeout 등록
첫 번째 then 반응 등록
console.log("E")

현재 task가 끝났을 때 마이크로태스크 큐에는 첫 번째 then 반응이 있다.

microtask queue: [B]

B가 실행되면서 다음 then 반응인 C가 추가된다.

microtask queue: [C]

큐가 빌 때까지 실행하므로 C도 같은 checkpoint에서 처리된다.

그다음 새로운 task인 setTimeout callback이 실행된다.

4. Promise 체인은 원자적으로 실행되지 않는다

다음 코드를 보자.

Promise.resolve()
  .then(() => {
    console.log("A");
  })
  .then(() => {
    console.log("C");
  });

Promise.resolve().then(() => {
  console.log("B");
});

출력 결과는 다음과 같다.

A
B
C

처음 등록되는 마이크로태스크는 A와 B다.

queue: [A, B]

A를 실행한 후에야 C가 등록된다.

queue: [B, C]

따라서 B가 C보다 먼저 실행된다.

Promise 체인 전체는 하나의 원자적인 작업이 아니다.

각 then() 단계는 별도의 Promise Reaction Job이다.

then 1
→ 하나의 Job

then 2
→ 앞 단계가 완료된 뒤 등록되는 또 다른 Job

이 때문에 서로 다른 Promise 체인의 연속성이 중간에 섞여 실행될 수 있다.

5. 마이크로태스크 starvation

마이크로태스크는 우선순위가 높아 보이지만, 과도하게 생성하면 이벤트 루프를 굶길 수 있다.

function spin() {
  queueMicrotask(spin);
}

spin();

각 마이크로태스크가 다음 마이크로태스크를 예약한다.

microtask 실행
→ 새로운 microtask 추가
→ 큐가 비지 않음
→ 다음 task로 이동하지 못함

그 결과 다음 작업들이 지연될 수 있다.

사용자 입력 처리
타이머 callback
화면 렌더링
기타 task

다음 코드도 UI에 제어권을 양보하는 확실한 방법은 아니다.

async function processItems(items) {
  for (const item of items) {
    heavyCalculation(item);
    await Promise.resolve();
  }
}

await Promise.resolve() 이후의 실행은 마이크로태스크로 재개된다.

다음 task나 렌더링 기회로 반드시 넘어가는 것이 아니다.

await Promise.resolve()
= 마이크로태스크 경계

렌더링에 양보
= 반드시 보장되지 않음

CPU 집약 작업을 처리해야 한다면 다음 선택지가 더 적합할 수 있다.

작업을 작은 task 단위로 분할
requestAnimationFrame 활용
스케줄러 사용
Web Worker에서 계산

Promise는 CPU 작업을 별도 스레드에서 실행해주는 도구가 아니다.

6. await는 무엇을 하는가

await value의 의미를 단순화하면 다음과 같다.

value를 Promise 형태로 정규화한다.
현재 async 실행 컨텍스트를 중단한다.
성공 시 재개할 반응을 등록한다.
실패 시 재개할 반응을 등록한다.
호출자에게 제어권을 반환한다.
Promise가 완료되면 Job을 통해 중단 지점 이후를 재개한다.

ECMAScript의 Await(value) 추상 연산은 값을 intrinsic Promise로 정규화하고, 현재 async 실행 컨텍스트를 캡처한 fulfillment·rejection 함수를 만든다. 이후 PerformPromiseThen으로 반응을 등록하고 현재 컨텍스트를 중단한다.

다음 코드에서 중요한 것은 await이 현재 스레드를 멈추지 않는다는 점이다.

async function load() {
  const result = await fetchData();

  return result;
}

fetchData()가 완료될 때까지 JavaScript 엔진 전체가 멈추는 것이 아니다.

load 함수의 현재 실행만 중단된다.
이벤트 루프는 다른 작업을 처리할 수 있다.

7. async 함수는 첫 await 전까지 동기적으로 실행된다

console.log(1);

async function run() {
  console.log(2);

  await 0;

  console.log(4);
}

run();

console.log(3);

출력은 다음과 같다.

run() 호출 시 함수 본문은 즉시 시작한다.

console.log(2);

까지는 현재 호출 스택에서 실행된다.

await 0을 만나면 함수가 중단되고 이후 코드는 Promise 반응으로 예약된다.

현재 task

1
2
3

microtask

4

따라서 다음 두 문장은 모두 부정확하다.

async 함수는 전부 비동기로 실행된다.
async 함수는 호출 즉시 나중으로 밀린다.

정확한 설명은 다음과 같다.

async 함수는 호출 즉시 실행을 시작한다.
첫 await 전까지는 동기적으로 실행된다.
await 이후의 연속성이 비동기적으로 재개된다.

8. 일반 값을 await해도 실행 순서가 바뀐다

async function example() {
  console.log("before");

  await 42;

  console.log("after");
}

example();

console.log("outside");

출력은 다음과 같다.

before
outside
after

42는 비동기 계산이 아니다.

이미 존재하는 원시값이다.

하지만 await은 해당 값을 Promise처럼 정규화하고 후속 실행을 Promise 반응으로 연결한다.

따라서 다음 코드는 단순한 대입과 실행 시점이 다르다.

const value = 42;

const value = await 42;

결과값은 같지만 두 번째 코드에는 async 중단·재개 경계가 생긴다.

불필요한 await은 다음 변화를 만든다.

현재 실행의 분할
마이크로태스크 예약
다른 Promise 반응과의 실행 순서 변화
비동기 스택 경계 생성

9. async 함수는 항상 새로운 Promise를 반환한다

const original = Promise.resolve(1);

async function identity() {
  return original;
}

const returned = identity();

console.log(returned === original); // false
console.log(await returned);        // 1

identity()가 반환한 Promise와 original은 동일한 객체가 아니다.

async 함수가 호출되면 해당 함수의 완료를 나타내는 새로운 Promise가 만들어진다.

함수가 다른 Promise를 반환하면 새 Promise는 기존 Promise의 최종 상태를 채택한다.

객체 정체성
= 서로 다름

최종 fulfillment 값과 rejection
= 연결됨

ECMAScript async 함수는 호출마다 새로운 Promise 결과를 생성하며, 반환값이나 예외를 그 Promise의 완료 상태로 연결한다.

10. rejection이 await를 만나면 예외가 된다

다음 코드는 rejected Promise를 만들지만 현재 호출 스택에서 예외를 던지지는 않는다.

try {
  Promise.reject(new Error("failure"));
} catch (error) {
  console.log("실행되지 않는다.");
}

반면 다음 코드는 오류를 잡는다.

try {
  await Promise.reject(new Error("failure"));
} catch (error) {
  console.log(error.message); // failure
}

await은 Promise가 reject되면 중단된 async 실행 컨텍스트를 throw 완료 상태로 재개한다.

Promise rejection
        ↓ await
async 함수 내부의 throw
        ↓
try/catch로 관찰

try/catch가 Promise를 직접 이해하는 것은 아니다.

await이 rejection을 async 함수의 예외 제어 흐름으로 변환하는 것이다.

11. return promise와 return await promise

다음 두 함수의 최종 결과는 대체로 같다.

async function loadA() {
  return repository.load();
}

async function loadB() {
  return await repository.load();
}

하지만 현재 함수의 catch가 rejection을 처리해야 한다면 차이가 생긴다.

async function loadUser() {
  try {
    return repository.loadUser();
  } catch (error) {
    throw new Error("사용자를 불러오지 못했습니다.", {
      cause: error,
    });
  }
}

repository.loadUser()가 Promise를 반환하고 나중에 reject되면, 현재 try 블록은 해당 rejection을 잡지 못할 수 있다.

반환 시점에는 loadUser()의 동기 실행이 이미 끝났기 때문이다.

async function loadUser() {
  try {
    return await repository.loadUser();
  } catch (error) {
    throw new Error("사용자를 불러오지 못했습니다.", {
      cause: error,
    });
  }
}

이번에는 rejection이 await 지점에서 throw로 변환된다.

따라서 현재 catch가 오류를 변환할 수 있다.

과거에는 return await이 추가 마이크로태스크를 만든다는 이유로 피하라는 조언이 있었다. 현재 ESLint는 관련 규칙을 폐기했으며, return await이 추가 마이크로태스크를 만들지 않고 더 나은 비동기 스택 추적을 제공할 수 있다고 설명한다.

선택 기준은 다음과 같다.

현재 함수의 catch 또는 finally가 rejection을 처리해야 함
→ return await

단순히 하위 Promise 결과를 전달
→ return 또는 return await 모두 가능

명확한 async stack trace가 중요
→ return await 고려

12. async Promise executor가 위험한 이유

다음 코드는 문법적으로 가능하다.

const promise = new Promise(async (resolve, reject) => {
  const value = await loadValue();

  resolve(value);
});

하지만 구조적으로는 두 개의 Promise가 생긴다.

1. new Promise가 만든 외부 Promise
2. async executor 호출이 반환한 내부 Promise

Promise 생성자는 executor의 반환값을 사용하지 않는다.

따라서 다음 코드는 외부 Promise를 reject시키지 못한다.

const promise = new Promise(async () => {
  throw new Error("failure");
});

실행 구조는 다음과 같다.

async executor 실행
→ 별도의 Promise 반환
→ throw로 내부 Promise reject

외부 Promise
→ resolve도 reject도 호출되지 않음
→ 계속 pending

ESLint도 async executor 내부에서 발생한 오류가 새로 생성한 외부 Promise를 reject시키지 못할 수 있다는 이유로 no-async-promise-executor 규칙을 권장한다.

이미 Promise를 반환하는 작업에는 new Promise()가 필요하지 않다.

async function load() {
  return await loadValue();
}

new Promise()는 callback 기반 API를 Promise로 변환하는 경계에서 주로 사용한다.

function readFile(path) {
  return new Promise((resolve, reject) => {
    legacyReadFile(path, (error, data) => {
      if (error) {
        reject(error);
        return;
      }

      resolve(data);
    });
  });
}

13. 처리되지 않은 rejection은 시간의 문제이기도 하다

다음 Promise는 생성 즉시 reject된다.

const promise = Promise.reject(
  new Error("failure"),
);

같은 실행 흐름에서 바로 handler를 등록하면 처리된 rejection으로 관찰된다.

promise.catch(handleError);

그러나 다음 task에서 늦게 handler를 등록하면 호스트가 먼저 처리되지 않은 rejection으로 보고할 수 있다.

const promise = Promise.reject(
  new Error("failure"),
);

setTimeout(() => {
  promise.catch(handleError);
}, 0);

unhandled rejection은 단순히 “Promise가 reject되었다”는 상태만으로 결정되지 않는다.

Promise가 reject되었는가?
적절한 시간 안에 handler가 연결되었는가?
호스트가 언제 이를 검사했는가?

ECMAScript는 HostPromiseRejectionTracker로 호스트가 rejection 처리 여부를 추적할 수 있게 하며, HTML 명세는 microtask checkpoint와 처리되지 않은 rejected Promise 보고 절차를 연결한다.

마무리

async/await은 Promise를 없애지 않는다.

Promise 위에 실행 컨텍스트 중단과 재개라는 구조를 제공한다.

async 함수
= 호출 시 새로운 Promise를 생성하는 함수

await
= 현재 async 실행을 중단하고
  Promise 반응을 통해 나중에 재개하는 연산

이를 이해하면 다음 현상이 자연스럽게 설명된다.

async 함수가 첫 await 전까지 동기 실행되는 이유
await 42도 실행 순서를 바꾸는 이유
rejection을 try/catch로 잡을 수 있는 이유
Promise 체인 사이에 다른 microtask가 들어오는 이유
microtask를 반복해도 렌더링에 양보되지 않을 수 있는 이유
async executor가 외부 Promise를 pending으로 남길 수 있는 이유

async/await은 비동기를 동기식 실행으로 바꾸는 문법이 아니다.

비동기 연속성을 사람이 읽기 쉬운 선형 코드로 표현하는 문법이다.

참고 자료

ECMA-262, Promise Objects, Async Functions, Await 추상 연산.
WHATWG HTML, 이벤트 루프와 microtask checkpoint.
ESLint, no-return-await.
ESLint, no-async-promise-executor.

Promise의 의미론: 비동기 작업이 아닌 단일 할당 상태 기계

토리나나 — Mon, 22 Jun 2026 22:35:03 +0900

Promise와 async/await 깊이 이해하기 1/4

들어가며

Promise는 흔히 “나중에 값을 받기 위한 객체”라고 설명된다.

이 설명은 입문 단계에서는 유용하지만, 다음 질문에는 충분히 답하지 못한다.

resolve()를 호출했는데도 왜 Promise가 여전히 pending일 수 있는가?
then()은 왜 항상 새로운 Promise를 반환하는가?
Promise 안에 Promise를 반환해도 왜 중첩되지 않는가?
Promise와 thenable은 무엇이 다른가?
이미 만들어진 Promise를 다시 기다리면 작업도 다시 실행되는가?

이 질문들에 답하려면 Promise를 단순한 비동기 문법이 아니라 다음 세 가지 관점에서 바라봐야 한다.

Promise = 단일 할당 상태 기계
        + 미래 결과를 관찰하는 프로토콜
        + 후속 계산을 연결하는 구조

Promise라는 개념은 JavaScript에서 처음 등장한 것이 아니다. Liskov와 Shrira는 1988년 논문에서 비동기 호출의 결과와 예외를 나중에 안전하게 다룰 수 있는 언어적 구조로 Promise를 연구했다. 현대 JavaScript Promise와 완전히 같은 모델은 아니지만, 미래의 결과를 값처럼 다룬다는 핵심 발상은 같은 계보에 있다.

1. Promise는 비동기 작업이 아니다

가장 먼저 구분해야 할 것은 작업과 작업의 결과다.

비동기 작업
= 네트워크 요청, 타이머, 파일 읽기, 사용자 이벤트 등

Promise
= 해당 작업의 최종 결과를 관찰하기 위한 객체

다음 코드를 보자.

const request = fetch("/api/users");

fetch() 호출은 네트워크 작업을 시작하고 Promise를 반환한다.

반환된 request는 네트워크 작업 자체가 아니다. 요청의 최종 성공 또는 실패를 관찰할 수 있는 핸들에 가깝다.

const firstResult = await request;
const secondResult = await request;

console.log(firstResult === secondResult);

같은 Promise를 두 번 await한다고 네트워크 요청이 두 번 실행되지는 않는다. 동일한 결과를 두 번 관찰할 뿐이다.

작업을 다시 실행하려면 Promise가 아니라 Promise를 만드는 함수가 필요하다.

const request = () => fetch("/api/users");

await request();
await request();

두 구조는 의미가 다르다.

Promise<Response>
= 이미 생성된 결과 객체

() => Promise<Response>
= 새로운 작업을 시작할 수 있는 작업 기술

이 차이는 재시도, 지연 실행, 동시성 제한에서 중요하다.

다음 코드는 올바른 재시도 구조가 아니다.

retry(fetch("/api/users"));

fetch()는 retry()가 호출되기 전에 이미 시작되었다.

올바른 구조는 다음과 같다.

retry(() => fetch("/api/users"));

이제 retry는 실패할 때마다 새로운 작업을 시작할 수 있다.

2. Promise executor는 동기적으로 실행된다

Promise를 생성하면 executor 함수가 전달된다.

const promise = new Promise((resolve, reject) => {
  // executor
});

executor 내부 코드는 자동으로 비동기가 되지 않는다.

console.log("A");

const promise = new Promise((resolve) => {
  console.log("B");
  resolve(1);
});

promise.then(() => {
  console.log("D");
});

console.log("C");

출력 결과는 다음과 같다.

A
B
C
D

Promise 생성자는 executor를 생성 즉시 동기적으로 호출한다.

반면 then()에 등록된 handler는 현재 호출 스택에서 실행되지 않는다. Promise가 이미 fulfilled된 상태여도 후속 반응은 Job으로 예약된다.

new Promise(executor)
        ↓
executor는 즉시 실행

promise.then(handler)
        ↓
handler는 후속 Job으로 실행

ECMAScript 명세도 Promise 생성 과정에서 executor를 바로 호출하고, Promise의 fulfillment와 rejection 반응은 별도의 Promise Reaction Job으로 실행하도록 정의한다.

따라서 다음 설명은 정확하지 않다.

new Promise를 사용하면 코드가 비동기로 실행된다.

더 정확한 설명은 다음과 같다.

Promise executor는 동기적으로 실행된다.
Promise의 후속 반응은 비동기 Job으로 실행된다.

3. Promise는 단일 할당 상태 기계다

Promise를 추상적인 상태 기계로 표현해보자.

P = ⟨state, result, fulfillReactions, rejectReactions, handled⟩

각 요소는 다음을 의미한다.

state
= pending | fulfilled | rejected

result
= fulfillment value 또는 rejection reason

fulfillReactions
= 성공 시 실행할 후속 반응 목록

rejectReactions
= 실패 시 실행할 후속 반응 목록

handled
= rejection handler가 연결되었는지 나타내는 정보

상태 전이는 다음 두 방향만 가능하다.

pending ── fulfill(value) ──▶ fulfilled(value)

pending ── reject(reason) ──▶ rejected(reason)

한 번 완료된 Promise는 다시 바뀌지 않는다.

fulfilled ──X──▶ rejected
rejected  ──X──▶ fulfilled

다음 코드에서 첫 번째 호출만 유효하다.

const promise = new Promise((resolve, reject) => {
  resolve(1);
  reject(new Error("failure"));
  resolve(2);
});

console.log(await promise); // 1

Promise는 최초의 유효한 결정만 채택한다.

resolve(1)
→ Promise의 운명 결정

reject(...)
→ 무시

resolve(2)
→ 무시

이 특성 때문에 Promise를 single-assignment cell, 즉 단 한 번만 값이 결정되는 셀로 볼 수 있다.

ECMAScript Promise는 내부적으로 상태, 결과, fulfillment 반응 목록, rejection 반응 목록, 처리 여부 등을 관리하며, 완료된 이후 다시 상태가 바뀌지 않는다.

4. fulfilled, rejected, settled, resolved는 다르다

Promise를 이해할 때 가장 혼동하기 쉬운 개념이 resolved다.

먼저 settled는 다음 두 상태를 가리킨다.

fulfilled 또는 rejected

즉, 더 이상 pending이 아닌 상태다.

반면 resolved는 더 넓다.

fulfilled되었거나
rejected되었거나
다른 Promise의 최종 상태를 따르도록 운명이 고정된 상태

따라서 Promise는 resolved이면서 pending일 수 있다.

다음 예제를 보자.

let resolveInner;

const inner = new Promise((resolve) => {
  resolveInner = resolve;
});

let resolveOuter;

const outer = new Promise((resolve) => {
  resolveOuter = resolve;
});

resolveOuter(inner);
resolveOuter(100);

outer.then(console.log);

setTimeout(() => {
  resolveInner("done");
}, 1000);

출력은 1초 후 다음과 같다.

done

resolveOuter(inner)가 호출되는 순간 outer는 inner의 최종 상태를 따르도록 결정된다.

그러나 inner는 아직 pending이다.

outer
= resolved
= pending

이후 호출한 다음 코드는 영향을 주지 못한다.

resolveOuter(100);

이미 outer의 운명이 inner를 따르도록 결정되었기 때문이다.

시간 흐름을 표현하면 다음과 같다.

t0
outer: pending, unresolved
inner: pending

t1
resolveOuter(inner)

outer: pending, resolved
inner: pending

t2
resolveOuter(100)

이미 resolved이므로 무시

t3
resolveInner("done")

inner: fulfilled("done")
outer: fulfilled("done")

ECMAScript 명세 역시 resolved Promise가 pending 상태일 수 있다고 명시한다. 다른 Promise의 상태를 따르도록 고정된 Promise는 아직 최종 값이 없더라도 이미 resolved다.

5. resolve는 값을 저장하는 함수가 아니다

resolve(value)는 Promise 내부에 값을 단순히 저장하는 함수처럼 보인다.

하지만 실제 의미는 다음에 가깝다.

주어진 값이 일반 값인지, Promise인지, thenable인지 검사한 뒤 그 값의 최종 상태를 현재 Promise가 채택하도록 한다.

개념적인 resolution algorithm은 다음과 같다.

resolve(x)

이미 resolve 또는 reject가 호출되었다면 종료한다.
x가 현재 Promise 자신이라면 TypeError로 reject한다.
x가 객체나 함수가 아니라면 x로 fulfill한다.
x.then을 읽는다.
then을 읽는 과정에서 예외가 발생하면 reject한다.
then이 함수가 아니라면 x 자체로 fulfill한다.
then이 함수라면 별도의 Job에서 호출한다.
then이 전달한 결과를 같은 규칙으로 다시 해석한다.

이 과정 때문에 Promise는 중첩 결과를 자동으로 평탄화한다.

const promise = Promise.resolve(
  Promise.resolve(
    Promise.resolve(42),
  ),
);

console.log(await promise); // 42

최종 타입은 개념적으로 다음과 같다.

Promise<number>

다음처럼 끝없이 중첩된 구조가 아니다.

Promise<Promise<Promise<number>>>

6. thenable assimilation

Promise와 비슷하게 동작하지만 실제 Promise 인스턴스가 아닌 객체를 thenable이라고 부른다.

const thenable = {
  then(resolve) {
    resolve(42);
  },
};

const value = await Promise.resolve(thenable);

console.log(value); // 42

Promise.resolve()는 단순히 객체를 fulfillment 값으로 저장하지 않는다.

객체의 then 프로퍼티가 callable이면 해당 객체의 최종 상태를 채택하려 한다.

객체에 호출 가능한 then이 존재한다
→ Promise처럼 동작할 가능성이 있는 객체로 취급

이 구조 덕분에 서로 다른 Promise 구현과 라이브러리가 상호 운용될 수 있다.

그러나 thenable assimilation은 외부 사용자 코드를 실행하는 지점이기도 하다.

const thenable = {
  get then() {
    console.log("then getter");

    return (resolve) => {
      console.log("then called");
      resolve(1);
    };
  },
};

console.log("A");

const promise = Promise.resolve(thenable);

console.log("B");

await promise;

실행 순서는 다음과 같다.

A
then getter
B
then called

then 프로퍼티를 읽는 작업은 현재 흐름에서 일어난다.

읽어온 then 함수를 호출하는 작업은 별도의 Promise Job으로 예약된다.

또한 getter 자체가 예외를 던질 수 있다.

const thenable = {
  get then() {
    throw new Error("getter failed");
  },
};

const promise = Promise.resolve(thenable);

promise.catch(console.error);

이 경우 반환된 Promise는 getter에서 발생한 오류로 reject된다.

ECMAScript의 Promise resolution procedure는 객체의 then을 읽고, callable이면 별도의 Thenable Job을 통해 호출하며, 자기 자신으로 resolve하려는 경우에는 TypeError로 거부하도록 정의한다.

7. 악의적이거나 잘못 구현된 thenable

thenable은 여러 번 resolve와 reject를 호출할 수도 있다.

const hostileThenable = {
  then(resolve, reject) {
    resolve(1);
    reject(new Error("late rejection"));
    resolve(2);

    throw new Error("late throw");
  },
};

const value = await Promise.resolve(hostileThenable);

console.log(value); // 1

최종 결과는 1이다.

첫 번째 호출이 Promise의 운명을 결정한 이후 나머지 호출은 상태를 바꾸지 못한다.

resolve(1)
→ 최종 운명 결정

reject(...)
→ 무시

resolve(2)
→ 무시

throw
→ 이미 결정되었으므로 최종 결과를 바꾸지 못함

이 규칙은 잘못 구현된 thenable이 Promise를 여러 번 결정하는 것을 막는다.

그러나 실행된 부수 효과까지 되돌려주는 것은 아니다.

const thenable = {
  then(resolve) {
    chargePayment();
    resolve("success");
    sendEmail();
  },
};

Promise는 한 번만 완료되지만 chargePayment()와 sendEmail()은 모두 실행된다.

Promise의 단일 할당 규칙은 결과의 일관성을 보호한다.

다음 항목은 보호하지 않는다.

부수 효과의 원자성
트랜잭션
롤백
중복 실행 방지

8. then은 결과를 꺼내는 함수가 아니다

다음 코드를 보자.

const nextPromise = promise.then(
  onFulfilled,
  onRejected,
);

then()은 원본 Promise를 변경하지 않는다.

원본 Promise에 후속 반응을 등록하고 새로운 Promise를 반환한다.

타입 수준에서 단순화하면 다음과 같이 표현할 수 있다.

then:
Promise<A>
× (A → B | PromiseLike<B>)
× (unknown → B | PromiseLike<B>)
→ Promise<B>

새 Promise의 결과는 handler가 무엇을 하느냐에 따라 결정된다.

handler가 일반 값 y를 반환
→ 새 Promise는 y로 fulfill

handler가 Promise를 반환
→ 새 Promise는 해당 Promise의 상태를 채택

handler가 예외를 던짐
→ 새 Promise는 해당 오류로 reject

예제를 보자.

const result = Promise.resolve(1)
  .then((value) => value + 1)
  .then((value) => Promise.resolve(value + 1))
  .then((value) => {
    if (value === 3) {
      throw new Error("stopped");
    }

    return value;
  });

result.catch((error) => {
  console.log(error.message); // stopped
});

각 then()은 하나의 새로운 계산 단계를 만든다.

Promise 1
  ↓ handler
Promise 2
  ↓ handler
Promise 3
  ↓ handler
Promise 4

Promise 체인은 값이 담긴 상자를 순서대로 여는 구조라기보다, 결과와 오류가 흐르는 비동기 계산 그래프에 가깝다.

9. handler가 없을 때의 전파 규칙

다음 코드에는 fulfillment handler가 없다.

const nextPromise = promise.then();

원본 Promise가 fulfill되면 값이 다음 Promise로 그대로 전달된다.

개념적으로 다음 함수가 들어간 것과 같다.

(value) => value

rejection handler가 없으면 오류도 다음 Promise로 전달된다.

개념적으로는 다음과 같다.

(error) => {
  throw error;
}

따라서 다음 체인의 오류는 마지막 catch()까지 전파된다.

fetchData()
  .then(parseData)
  .then(normalizeData)
  .then(renderData)
  .catch(handleError);

어느 단계에서든 오류가 발생하면 handler가 없는 구간을 통과해 아래로 전달된다.

10. then의 두 번째 인자가 놓치는 오류

다음 코드는 미묘한 차이를 가진다.

sourcePromise.then(
  (value) => parse(value),
  (error) => recover(error),
);

두 번째 인자인 recover는 sourcePromise 자체가 reject된 경우에만 실행된다.

첫 번째 handler인 parse() 내부에서 발생한 오류는 잡지 못한다.

Promise.resolve("{ invalid json")
  .then(
    (value) => JSON.parse(value),
    (error) => {
      console.log("여기서는 잡히지 않는다.");
    },
  )
  .catch((error) => {
    console.log("여기에서 잡힌다.");
  });

이유는 두 handler가 같은 원본 Promise에 연결된 형제 반응이기 때문이다.

                 ┌─ onFulfilled
sourcePromise ───┤
                 └─ onRejected

onFulfilled가 던진 오류는 원본 Promise의 실패가 아니다.

onFulfilled가 생성한 다음 Promise의 실패다.

sourcePromise fulfilled
        ↓
onFulfilled 실행
        ↓ throw
nextPromise rejected

따라서 성공 handler 내부 오류까지 잡으려면 하류에 catch()를 둬야 한다.

sourcePromise
  .then((value) => parse(value))
  .catch((error) => recover(error));

11. Promise를 이해하는 핵심 모델

Promise는 다음과 같이 이해할 수 있다.

Promise는 작업이 아니다.
Promise는 작업 결과를 관찰하는 객체다.

Promise는 단 한 번 결정된다.
완료된 이후 상태는 바뀌지 않는다.

resolve는 값을 저장하지 않는다.
값 또는 thenable의 최종 운명을 채택한다.

then은 원본 Promise를 수정하지 않는다.
후속 계산을 나타내는 새로운 Promise를 만든다.

Promise 체인은 값의 배열이 아니다.
결과와 오류가 흐르는 방향성 계산 그래프다.

이 모델을 이해하면 이후에 다룰 async/await, 마이크로태스크, 동시성 조합자, 취소 구조도 자연스럽게 연결된다.

마무리

Promise는 단순히 “나중에 값을 주는 객체”가 아니다.

더 정확히 말하면 Promise는 다음을 하나의 언어 구조로 만든다.

미래의 결과
결과의 성공과 실패
결과에 연결된 후속 계산
다른 비동기 결과와의 결합

Promise를 단일 할당 상태 기계로 이해하면 다음 현상들이 하나의 원리로 설명된다.

resolve를 여러 번 호출해도 첫 호출만 유효한 이유
다른 pending Promise로 resolve할 수 있는 이유
thenable이 자동으로 흡수되는 이유
중첩 Promise가 평탄화되는 이유
then이 항상 새 Promise를 반환하는 이유
오류가 체인 아래로 전파되는 이유

Promise는 비동기를 실행하는 엔진이 아니다.

Promise는 비동기 계산의 결과와 후속 관계를 프로그램 안에서 값으로 표현하는 프로토콜이다.

참고 자료

Liskov, Shrira, Promises: Linguistic Support for Efficient Asynchronous Procedure Calls in Distributed Systems.
ECMA-262, Promise Objects 및 Promise Resolution Procedure.

JavaScript 클로저 완전 정복: 함수는 어떻게 자신이 태어난 환경을 기억하는가

토리나나 — Sat, 20 Jun 2026 20:26:12 +0900

프론트엔드 개발자 면접에서 자주 나오는 JavaScript 질문 중 하나가 바로 클로저(Closure) 다.

많은 개발자가 클로저를 “함수 안의 함수” 또는 “외부 변수에 접근하는 내부 함수” 정도로 기억한다. 하지만 이 설명은 절반만 맞다. 클로저를 제대로 이해하려면 단순히 코드 패턴을 외우는 것이 아니라, JavaScript가 스코프를 어떻게 결정하는지, 함수가 어떤 환경을 기억하는지, 그리고 그 특성이 실무에서 상태 관리, 이벤트 핸들러, 비동기 처리, React Hooks, 메모리 관리와 어떻게 연결되는지까지 이해해야 한다.

이 글에서는 클로저를 기초부터 깊이 있게 정리해본다.

1. 클로저를 한 문장으로 정의하면

클로저는 함수와 그 함수가 선언될 당시의 렉시컬 환경이 함께 묶인 구조다.

조금 더 쉽게 말하면 다음과 같다.

클로저는 함수가 자신이 만들어진 위치의 변수와 스코프를 기억하고, 나중에 다른 위치에서 실행되더라도 그 변수에 접근할 수 있게 해주는 JavaScript의 특성이다.

가장 기본적인 예시를 보자.

function createCounter() {
  let count = 0;

  return function increment() {
    count += 1;
    return count;
  };
}

const counter = createCounter();

console.log(counter()); // 1
console.log(counter()); // 2
console.log(counter()); // 3

createCounter 함수는 이미 실행이 끝났다. 일반적으로 함수 실행이 끝나면 내부 변수도 사라질 것처럼 느껴진다. 그런데 counter()를 호출할 때마다 count 값은 계속 유지된다.

왜 그럴까?

increment 함수가 만들어질 때, 자신이 선언된 환경인 createCounter의 렉시컬 환경을 기억했기 때문이다. 그래서 createCounter의 실행은 끝났지만, increment가 여전히 count에 접근할 수 있다.

이것이 클로저다.

2. 클로저는 “함수 안의 함수”가 아니다

클로저를 처음 배울 때 흔히 이렇게 외운다.

함수 안에 함수가 있고, 내부 함수가 외부 함수의 변수에 접근하면 클로저다.

입문 단계에서는 괜찮은 설명이다. 하지만 정확한 설명은 아니다.

클로저의 핵심은 “중첩 함수” 자체가 아니라, 함수가 선언될 때의 외부 렉시컬 환경을 기억한다는 점이다.

다음 예제를 보자.

let name = "Hyun";

function sayName() {
  console.log(name);
}

name = "Kwak";

sayName(); // Kwak

sayName은 전역 스코프에서 선언되었고, 전역 변수 name에 접근한다. 이 함수도 자신이 선언된 렉시컬 환경을 참조한다. 넓은 의미에서 JavaScript의 함수는 모두 자신이 생성된 환경을 기억한다.

하지만 보통 면접이나 실무에서 “클로저”라고 말할 때는 다음과 같은 상황을 주로 가리킨다.

function outer() {
  const message = "Hello Closure";

  return function inner() {
    console.log(message);
  };
}

const fn = outer();
fn(); // Hello Closure

즉, 외부 함수의 실행이 끝난 뒤에도 내부 함수가 외부 함수의 변수에 접근하는 상황에서 클로저의 특징이 가장 잘 드러난다.

3. 렉시컬 스코프를 먼저 이해해야 한다

클로저를 이해하려면 먼저 렉시컬 스코프(Lexical Scope) 를 알아야 한다.

렉시컬 스코프란, 변수의 유효 범위가 함수를 어디서 호출했는지가 아니라 어디서 선언했는지에 따라 결정되는 규칙이다.

다음 코드를 보자.

const value = "global";

function outer() {
  const value = "outer";

  function inner() {
    console.log(value);
  }

  return inner;
}

const fn = outer();

function run() {
  const value = "run";
  fn();
}

run(); // outer

fn()은 run 함수 안에서 호출되었다. run 함수 안에도 value가 있다. 그런데 출력 결과는 "run"이 아니라 "outer"다.

왜냐하면 inner 함수는 run 안에서 선언된 것이 아니라 outer 안에서 선언되었기 때문이다. JavaScript는 함수가 실행되는 위치가 아니라 선언된 위치를 기준으로 상위 스코프를 결정한다.

이것이 렉시컬 스코프다.

클로저는 이 렉시컬 스코프 규칙 위에서 동작한다.

4. 클로저의 핵심: 값이 아니라 “환경”을 기억한다

클로저를 이해할 때 중요한 포인트가 있다.

클로저는 단순히 외부 변수의 “값”을 복사해서 저장하는 것이 아니다. 함수가 선언될 당시의 변수 바인딩이 들어 있는 환경을 참조한다.

예제를 보자.

let count = 0;

function logCount() {
  console.log(count);
}

count = 10;

logCount(); // 10

만약 함수가 변수를 만들 당시의 값을 복사했다면 0이 출력되어야 할 것 같다. 하지만 실제로는 10이 출력된다.

이유는 logCount가 count라는 값을 복사한 것이 아니라, count라는 변수 바인딩에 접근하기 때문이다.

다른 예시도 보자.

function createCounter() {
  let count = 0;

  return {
    increase() {
      count += 1;
    },
    decrease() {
      count -= 1;
    },
    getCount() {
      return count;
    },
  };
}

const counter = createCounter();

counter.increase();
counter.increase();
counter.decrease();

console.log(counter.getCount()); // 1

increase, decrease, getCount는 모두 같은 count를 공유한다. 각 함수가 count 값을 따로 복사해서 가지고 있는 것이 아니라, 같은 렉시컬 환경 안의 count 바인딩을 참조하고 있기 때문이다.

이 특성 덕분에 클로저는 상태를 은닉하고 공유하는 강력한 도구가 된다.

5. 클로저가 만들어지는 과정

다음 코드를 기준으로 클로저가 어떻게 만들어지는지 단계별로 보자.

function createUser(name) {
  const createdAt = new Date();

  return function getUserInfo() {
    return {
      name,
      createdAt,
    };
  };
}

const getUserInfo = createUser("Hyun");

console.log(getUserInfo());

실행 흐름은 다음과 같다.

첫째, createUser("Hyun")이 호출된다.

name = "Hyun"
createdAt = new Date()

둘째, getUserInfo 함수가 생성된다.

이 함수는 자신이 선언된 위치의 렉시컬 환경을 기억한다. 즉, name과 createdAt에 접근할 수 있는 환경을 참조한다.

셋째, createUser는 getUserInfo 함수를 반환하고 종료된다.

일반적인 지역 변수라면 createUser 실행이 끝난 뒤 사라져도 이상하지 않다. 하지만 반환된 getUserInfo 함수가 여전히 그 환경을 참조하고 있기 때문에, 해당 환경은 메모리에서 해제되지 않는다.

넷째, 나중에 getUserInfo()를 호출한다.

이 함수는 자신이 기억하고 있던 환경을 통해 name과 createdAt에 접근한다.

즉, 클로저는 다음 구조로 이해할 수 있다.

getUserInfo 함수
  └── 자신이 선언된 렉시컬 환경 참조
        ├── name: "Hyun"
        └── createdAt: Date 객체

6. 클로저의 대표적인 활용 1: private state 만들기

JavaScript에서 클로저는 private한 상태를 만드는 데 자주 사용된다.

function createBankAccount(initialBalance) {
  let balance = initialBalance;

  return {
    deposit(amount) {
      if (amount <= 0) {
        throw new Error("입금액은 0보다 커야 합니다.");
      }

      balance += amount;
      return balance;
    },

    withdraw(amount) {
      if (amount > balance) {
        throw new Error("잔액이 부족합니다.");
      }

      balance -= amount;
      return balance;
    },

    getBalance() {
      return balance;
    },
  };
}

const account = createBankAccount(10000);

account.deposit(5000);
account.withdraw(3000);

console.log(account.getBalance()); // 12000
console.log(account.balance); // undefined

balance는 외부에서 직접 접근할 수 없다.

account.balance = 100000000;

이렇게 해도 내부의 balance 값은 바뀌지 않는다. 외부에서 만든 account.balance는 단지 새로운 프로퍼티일 뿐이고, 클로저 내부의 balance와는 별개다.

이 패턴은 클래스의 private 필드가 널리 쓰이기 전부터 JavaScript에서 캡슐화를 구현하는 대표적인 방식이었다.

7. 클로저의 대표적인 활용 2: 함수 팩토리

클로저는 특정 설정을 기억하는 함수를 만들 때 유용하다.

function createMultiplier(multiplier) {
  return function multiply(value) {
    return value * multiplier;
  };
}

const double = createMultiplier(2);
const triple = createMultiplier(3);

console.log(double(10)); // 20
console.log(triple(10)); // 30

double은 multiplier = 2인 환경을 기억하고, triple은 multiplier = 3인 환경을 기억한다.

같은 함수 구조를 사용하지만, 각각 다른 환경을 기억하는 별도의 함수가 만들어진다.

실무에서는 다음과 같은 형태로 활용할 수 있다.

function createApiClient(baseUrl) {
  return async function request(path, options) {
    const response = await fetch(`${baseUrl}${path}`, options);

    if (!response.ok) {
      throw new Error("API 요청에 실패했습니다.");
    }

    return response.json();
  };
}

const userApi = createApiClient("/api/users");
const orderApi = createApiClient("/api/orders");

userApi("/1");
orderApi("/recent");

userApi는 "/api/users"를 기억하고, orderApi는 "/api/orders"를 기억한다.

이렇게 클로저를 사용하면 반복되는 설정 값을 매번 넘기지 않아도 된다.

8. 클로저의 대표적인 활용 3: 이벤트 핸들러

프론트엔드에서는 이벤트 핸들러에서 클로저를 매우 자주 사용한다.

function bindClickLogger(button, pageName) {
  button.addEventListener("click", function handleClick() {
    console.log(`${pageName} 페이지에서 버튼 클릭`);
  });
}

handleClick 함수는 pageName을 기억한다. 실제 클릭 이벤트는 나중에 발생하지만, 핸들러는 자신이 등록될 당시의 환경에 접근할 수 있다.

React에서도 같은 원리로 동작한다.

function ProductCard({ product }) {
  function handleClick() {
    console.log(`${product.name} 클릭`);
  }

  return (
    <button onClick={handleClick}>
      상품 보기
    </button>
  );
}

handleClick은 product에 접근한다. 이 역시 클로저다.

우리는 React에서 매일 클로저를 쓰고 있다. 다만 너무 자연스럽게 쓰고 있어서 클로저라고 의식하지 않을 뿐이다.

9. 클로저의 대표적인 활용 4: 디바운스와 쓰로틀

디바운스와 쓰로틀은 클로저의 실무 활용을 보여주는 좋은 예시다.

디바운스

디바운스는 이벤트가 연속으로 발생할 때 마지막 이벤트만 처리하는 기법이다.

function debounce(callback, delay) {
  let timerId;

  return function (...args) {
    clearTimeout(timerId);

    timerId = setTimeout(() => {
      callback(...args);
    }, delay);
  };
}

사용 예시는 다음과 같다.

const search = debounce((keyword) => {
  console.log(`검색어: ${keyword}`);
}, 300);

search("r");
search("re");
search("rea");
search("react");

여기서 반환된 함수는 timerId, callback, delay를 기억한다. debounce 함수 실행은 이미 끝났지만, 반환된 함수가 계속 timerId에 접근하면서 이전 타이머를 취소할 수 있다.

이것이 클로저의 힘이다.

쓰로틀

쓰로틀은 일정 시간 동안 한 번만 실행되도록 제한하는 기법이다.

function throttle(callback, delay) {
  let lastExecutedTime = 0;

  return function (...args) {
    const now = Date.now();

    if (now - lastExecutedTime >= delay) {
      lastExecutedTime = now;
      callback(...args);
    }
  };
}

스크롤 이벤트나 리사이즈 이벤트처럼 짧은 시간에 매우 자주 발생하는 이벤트를 제어할 때 사용된다.

const handleScroll = throttle(() => {
  console.log("스크롤 처리");
}, 1000);

window.addEventListener("scroll", handleScroll);

반환된 함수는 lastExecutedTime을 기억한다. 그래서 이전 실행 시점을 기준으로 다음 실행 여부를 판단할 수 있다.

10. 반복문과 클로저: var가 만드는 고전적인 문제

클로저를 설명할 때 자주 등장하는 문제가 있다.

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

많은 사람이 0, 1, 2가 출력될 것이라고 예상한다. 하지만 실제 결과는 다음과 같다.

3
3
3

왜 그럴까?

var는 함수 스코프를 가진다. 반복문 블록마다 새로운 i가 만들어지는 것이 아니라, 하나의 i를 세 번의 콜백이 공유한다. setTimeout의 콜백이 실행될 때는 이미 반복문이 끝난 뒤이고, 그 시점의 i 값은 3이다.

이를 해결하는 가장 간단한 방법은 let을 사용하는 것이다.

for (let i = 0; i < 3; i++) {
  setTimeout(function () {
    console.log(i);
  }, 1000);
}

결과는 다음과 같다.

0
1
2

let은 블록 스코프를 가지며, 반복문에서는 각 반복마다 새로운 바인딩이 만들어진다. 그래서 각 콜백은 서로 다른 i를 기억한다.

과거에는 IIFE를 사용해서 이 문제를 해결하기도 했다.

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

currentIndex는 IIFE가 실행될 때마다 새로 만들어지는 매개변수다. 각 콜백은 서로 다른 currentIndex를 기억하기 때문에 원하는 결과를 얻을 수 있다.

11. 비동기 코드와 클로저

클로저는 비동기 코드에서도 매우 중요하다.

function fetchUser(userId) {
  return fetch(`/api/users/${userId}`)
    .then((response) => response.json())
    .then((user) => {
      console.log(`${userId}번 유저 정보`, user);
    });
}

마지막 then 콜백은 userId를 사용한다. 이 콜백은 나중에 실행되지만, fetchUser가 호출될 당시의 userId에 접근할 수 있다.

async/await를 사용해도 마찬가지다.

async function fetchUser(userId) {
  const response = await fetch(`/api/users/${userId}`);
  const user = await response.json();

  console.log(`${userId}번 유저 정보`, user);
}

비동기 함수 내부의 코드는 중간에 멈췄다가 나중에 이어서 실행된다. 이때도 함수는 자신의 렉시컬 환경을 유지한다.

실무에서는 이 특성 덕분에 요청 당시의 인자, 설정값, 상태값을 비동기 콜백 안에서 사용할 수 있다.

12. React에서 자주 만나는 stale closure

React를 사용한다면 클로저를 반드시 깊게 이해해야 한다. 특히 useEffect, 이벤트 핸들러, 타이머, 비동기 요청에서 stale closure 문제가 자주 발생한다.

stale closure란, 함수가 최신 값이 아니라 함수가 만들어질 당시의 오래된 값을 참조하는 현상이다.

다음 예제를 보자.

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

  function handleAlert() {
    setTimeout(() => {
      alert(count);
    }, 3000);
  }

  return (
    <>
      <p>{count}</p>
      <button onClick={() => setCount(count + 1)}>증가</button>
      <button onClick={handleAlert}>3초 뒤 알림</button>
    </>
  );
}

사용자가 count가 0일 때 “3초 뒤 알림” 버튼을 누르고, 바로 증가 버튼을 여러 번 눌렀다고 하자. 3초 뒤 알림에는 최신 count가 아니라 버튼을 누르던 시점의 count가 표시될 수 있다.

왜 그럴까?

React 함수 컴포넌트는 렌더링될 때마다 함수가 다시 실행된다. 각 렌더링은 자신만의 count 값을 가진다. handleAlert 안의 setTimeout 콜백은 그 렌더링 시점의 count를 기억한다.

즉, React의 상태가 바뀌었다고 해서 이미 만들어진 클로저가 자동으로 최신 값을 바라보는 것은 아니다.

이 문제를 해결하는 방법은 상황에 따라 다르다.

방법 1: 함수형 업데이트 사용

상태 업데이트가 이전 상태에 의존한다면 함수형 업데이트를 사용한다.

setCount((prev) => prev + 1);

예를 들어 다음 코드는 문제가 생길 수 있다.

function handleClick() {
  setCount(count + 1);
  setCount(count + 1);
  setCount(count + 1);
}

이 경우 의도는 3 증가일 수 있지만, 실제로는 같은 count 값을 기준으로 업데이트가 계산될 수 있다.

더 안전한 방식은 다음과 같다.

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

방법 2: 최신 값을 ref에 저장

타이머나 이벤트 리스너에서 최신 값을 계속 참조해야 한다면 useRef를 사용할 수 있다.

function Counter() {
  const [count, setCount] = useState(0);
  const latestCountRef = useRef(count);

  useEffect(() => {
    latestCountRef.current = count;
  }, [count]);

  function handleAlert() {
    setTimeout(() => {
      alert(latestCountRef.current);
    }, 3000);
  }

  return (
    <>
      <p>{count}</p>
      <button onClick={() => setCount((prev) => prev + 1)}>증가</button>
      <button onClick={handleAlert}>3초 뒤 알림</button>
    </>
  );
}

ref.current는 렌더링 사이에서도 같은 객체를 유지한다. 그래서 비동기 콜백 안에서 최신 값을 읽어야 할 때 유용하다.

방법 3: 의존성 배열을 정확히 작성

useEffect에서 외부 값을 사용한다면 의존성 배열을 정확히 작성해야 한다.

useEffect(() => {
  const id = setInterval(() => {
    console.log(count);
  }, 1000);

  return () => clearInterval(id);
}, [count]);

count를 의존성 배열에 넣지 않으면, effect 내부의 콜백이 오래된 count를 계속 참조할 수 있다.

하지만 의존성 배열에 값을 넣으면 effect가 자주 재실행될 수 있다. 이때는 최신 값을 ref로 관리할지, effect 구조를 바꿀지, 상태 업데이트 방식을 바꿀지 판단해야 한다.

React에서 클로저를 이해한다는 것은 단순히 JavaScript 개념을 아는 것을 넘어, 렌더링과 상태의 스냅샷 모델을 이해한다는 뜻이기도 하다.

13. 클로저와 메모리 관리

클로저는 매우 유용하지만, 잘못 사용하면 예상보다 오래 메모리를 잡고 있을 수 있다.

다음 예제를 보자.

function registerHandler() {
  const largeData = new Array(1000000).fill("data");

  const button = document.querySelector("#button");

  button.addEventListener("click", function handleClick() {
    console.log(largeData.length);
  });
}

registerHandler();

registerHandler 함수 실행은 끝났다. 하지만 handleClick 이벤트 핸들러가 largeData를 참조하고 있다. 그리고 버튼에 이벤트 핸들러가 등록되어 있는 동안 handleClick은 살아 있다.

그 결과 largeData도 메모리에서 해제되지 않을 수 있다.

클로저 자체가 메모리 누수는 아니다. 문제는 더 이상 필요 없는 데이터가 클로저를 통해 계속 참조되는 상황이다.

이벤트 리스너를 제거하면 참조를 끊을 수 있다.

function registerHandler() {
  const largeData = new Array(1000000).fill("data");
  const button = document.querySelector("#button");

  function handleClick() {
    console.log(largeData.length);
  }

  button.addEventListener("click", handleClick);

  return function cleanup() {
    button.removeEventListener("click", handleClick);
  };
}

const cleanup = registerHandler();

// 필요 없어졌을 때
cleanup();

React에서는 effect cleanup이 같은 역할을 한다.

useEffect(() => {
  function handleResize() {
    console.log(window.innerWidth);
  }

  window.addEventListener("resize", handleResize);

  return () => {
    window.removeEventListener("resize", handleResize);
  };
}, []);

클로저를 사용할 때는 다음 질문을 해봐야 한다.

이 함수가 어떤 외부 값을 참조하고 있는가?
그 외부 값이 큰 객체나 DOM 노드인가?
이 함수는 언제까지 살아 있는가?
필요 없어진 뒤 참조를 끊는 코드가 있는가?

이 질문을 할 수 있다면 클로저로 인한 메모리 문제를 훨씬 잘 다룰 수 있다.

14. 클로저는 상태 관리의 가장 작은 단위다

클로저를 단순히 면접용 개념으로만 보면 아쉽다. 클로저는 상태 관리의 가장 작은 원리 중 하나다.

다음 코드를 보자.

function createStore(initialState) {
  let state = initialState;
  const listeners = new Set();

  function getState() {
    return state;
  }

  function setState(nextState) {
    state =
      typeof nextState === "function"
        ? nextState(state)
        : nextState;

    listeners.forEach((listener) => listener(state));
  }

  function subscribe(listener) {
    listeners.add(listener);

    return function unsubscribe() {
      listeners.delete(listener);
    };
  }

  return {
    getState,
    setState,
    subscribe,
  };
}

간단한 store를 만들었다.

const store = createStore({ count: 0 });

const unsubscribe = store.subscribe((state) => {
  console.log("state changed:", state);
});

store.setState((prev) => ({ count: prev.count + 1 }));
store.setState((prev) => ({ count: prev.count + 1 }));

console.log(store.getState()); // { count: 2 }

unsubscribe();

여기서 state와 listeners는 외부에서 직접 접근할 수 없다. 하지만 getState, setState, subscribe는 같은 렉시컬 환경을 공유하면서 상태를 읽고 변경한다.

Redux, Zustand 같은 상태관리 라이브러리의 내부 구현은 훨씬 복잡하지만, 기본적인 아이디어는 이와 크게 다르지 않다.

클로저는 단순한 문법 기능이 아니라, JavaScript에서 상태와 행위를 묶어 추상화하는 핵심 메커니즘이다.

15. 클로저와 모듈 패턴

ES Module이 보편화되기 전에는 클로저를 활용한 모듈 패턴이 많이 사용되었다.

const userModule = (function () {
  let currentUser = null;

  function login(user) {
    currentUser = user;
  }

  function logout() {
    currentUser = null;
  }

  function getCurrentUser() {
    return currentUser;
  }

  return {
    login,
    logout,
    getCurrentUser,
  };
})();

userModule.login({ id: 1, name: "Hyun" });

console.log(userModule.getCurrentUser());
console.log(userModule.currentUser); // undefined

IIFE를 실행해 private한 스코프를 만들고, 외부에 필요한 메서드만 반환한다. 이 메서드들은 모두 같은 private 상태인 currentUser를 공유한다.

현대 JavaScript에서는 ES Module과 #private class field 등 다른 선택지도 있다. 그래도 클로저 기반 모듈 패턴을 이해하면 JavaScript가 추상화를 어떻게 구현하는지 더 잘 이해할 수 있다.

16. 클로저와 this는 다르다

클로저를 공부하다 보면 this와 헷갈릴 때가 있다. 하지만 둘은 완전히 다른 개념이다.

클로저는 함수가 선언된 렉시컬 환경을 기억하는 것이다.

this는 함수가 어떻게 호출되었는지에 따라 결정되는 실행 컨텍스트의 값이다.

예를 들어보자.

const user = {
  name: "Hyun",

  sayLater() {
    setTimeout(function () {
      console.log(this.name);
    }, 1000);
  },
};

user.sayLater(); // undefined 또는 예상과 다른 값

setTimeout 안의 일반 함수에서 this는 user를 가리키지 않는다. 이 문제는 클로저와 직접적인 문제가 아니라 this 바인딩 문제다.

과거에는 다음처럼 this를 변수에 담아 클로저로 해결했다.

const user = {
  name: "Hyun",

  sayLater() {
    const self = this;

    setTimeout(function () {
      console.log(self.name);
    }, 1000);
  },
};

user.sayLater(); // Hyun

현대 JavaScript에서는 화살표 함수를 사용해 더 간단히 해결할 수 있다.

const user = {
  name: "Hyun",

  sayLater() {
    setTimeout(() => {
      console.log(this.name);
    }, 1000);
  },
};

user.sayLater(); // Hyun

화살표 함수는 자신만의 this를 만들지 않고, 바깥 스코프의 this를 사용한다.

정리하면 다음과 같다.

클로저: 함수가 선언된 환경의 변수에 접근하는 능력
this: 함수가 호출되는 방식에 따라 결정되는 값

17. 클로저를 사용할 때 흔히 하는 오해

오해 1. 클로저는 내부 함수가 반환될 때만 생긴다

아니다. 함수가 외부 스코프의 값을 참조하면 클로저의 성격이 나타난다. 반환되는 내부 함수는 클로저를 가장 쉽게 관찰할 수 있는 대표적인 패턴일 뿐이다.

function outer() {
  const message = "hello";

  setTimeout(function () {
    console.log(message);
  }, 1000);
}

여기서 내부 함수는 반환되지 않는다. 하지만 setTimeout 콜백은 message를 기억한다. 이것도 클로저다.

오해 2. 클로저는 값을 복사한다

아니다. 클로저는 값을 복사하는 것이 아니라 변수 바인딩이 들어 있는 환경에 접근한다.

let value = 1;

function logValue() {
  console.log(value);
}

value = 2;

logValue(); // 2

오해 3. 클로저는 항상 메모리 누수를 만든다

아니다. 클로저는 정상적인 언어 기능이다. 문제는 필요 없어진 함수나 이벤트 리스너가 큰 객체를 계속 참조할 때 발생한다.

오해 4. 클로저는 면접용 개념일 뿐이다

아니다. 디바운스, 쓰로틀, 이벤트 핸들러, React Hooks, 상태관리, 모듈 패턴, 함수형 프로그래밍 등 프론트엔드 실무 전반에서 사용된다.

18. 면접에서 클로저를 어떻게 설명하면 좋을까?

면접에서는 너무 길게 설명하기보다, 핵심을 정확히 말하고 예시로 증명하는 것이 좋다.

주니어 레벨 답변

클로저는 함수가 선언될 당시의 외부 변수에 접근할 수 있는 JavaScript의 특성입니다. 외부 함수의 실행이 끝난 뒤에도 내부 함수가 외부 함수의 변수에 접근할 수 있습니다.

function outer() {
  let count = 0;

  return function inner() {
    count += 1;
    return count;
  };
}

const counter = outer();

counter(); // 1
counter(); // 2

미드 레벨 답변

클로저는 함수와 그 함수가 생성될 당시의 렉시컬 환경이 함께 묶인 구조입니다. JavaScript는 렉시컬 스코프를 따르기 때문에 함수가 어디서 호출되는지가 아니라 어디서 선언되었는지를 기준으로 외부 변수에 접근합니다. 클로저는 디바운스, 쓰로틀, 이벤트 핸들러, private state 구현 등에 자주 사용됩니다. 다만 클로저가 큰 객체를 계속 참조하면 메모리 해제가 지연될 수 있어 이벤트 리스너 정리 같은 처리가 필요합니다.

시니어 레벨 답변

클로저는 함수 객체가 생성될 때 자신의 외부 렉시컬 환경을 참조하면서 발생하는 구조입니다. 중요한 점은 값을 복사하는 것이 아니라 변수 바인딩이 있는 환경을 참조한다는 것입니다. 이 특성 덕분에 상태 은닉, 함수 팩토리, 모듈 패턴, 비동기 콜백, React Hooks 같은 패턴을 구현할 수 있습니다. 반대로 React에서는 각 렌더링이 별도의 상태 스냅샷을 만들기 때문에 stale closure 문제가 발생할 수 있고, 타이머나 이벤트 리스너에서는 오래된 상태를 참조하지 않도록 의존성 배열, 함수형 업데이트, ref 등을 적절히 선택해야 합니다. 또한 클로저가 참조하는 객체는 함수가 살아 있는 동안 GC 대상이 되지 않을 수 있으므로, 장기적으로 살아 있는 핸들러에서는 참조 범위와 cleanup을 신경 써야 합니다.

19. 클로저를 제대로 이해했는지 확인하는 질문

다음 질문에 답할 수 있다면 클로저를 꽤 깊게 이해한 것이다.

클로저는 값을 저장하는가, 변수 바인딩을 참조하는가?
함수가 호출되는 위치와 선언되는 위치 중 무엇이 스코프를 결정하는가?
var 반복문에서 setTimeout 콜백이 모두 같은 값을 출력하는 이유는 무엇인가?
let은 왜 반복문 클로저 문제를 해결할 수 있는가?
React에서 stale closure는 왜 발생하는가?
useEffect 의존성 배열을 잘못 작성하면 어떤 문제가 생기는가?
클로저가 메모리 누수로 이어지는 경우는 언제인가?
디바운스 함수는 어떤 변수를 클로저로 기억하는가?
private state와 클로저는 어떤 관계가 있는가?
클로저와 this는 어떻게 다른가?

20. 마무리

클로저는 JavaScript의 어려운 개념 중 하나로 자주 소개된다. 하지만 본질은 단순하다.

함수는 자신이 선언된 환경을 기억한다.

이 한 문장을 정확히 이해하면 많은 JavaScript 동작이 자연스럽게 연결된다. 비동기 콜백이 외부 변수에 접근하는 이유, 이벤트 핸들러가 특정 데이터를 기억하는 이유, 디바운스가 이전 타이머를 취소할 수 있는 이유, React에서 오래된 상태가 참조되는 이유가 모두 클로저와 연결된다.

클로저는 단순히 면접 질문 하나를 통과하기 위한 지식이 아니다. JavaScript로 상태를 다루고, 추상화를 만들고, UI 이벤트와 비동기 흐름을 설계하기 위한 핵심 기반이다.

프론트엔드 개발자로 성장하고 싶다면 클로저를 “외워야 할 개념”이 아니라 “코드를 읽는 렌즈”로 이해해야 한다.

현업에서 AI 에이전트를 활용하는 방법

토리나나 — Tue, 17 Mar 2026 20:10:55 +0900

AI를 활용한 개발이 이제는 낯선 이야기가 아니게 되었다.

처음에는 자동 완성이나 간단한 질의응답 정도로 시작했지만, 최근에는 한 단계 더 나아가 에이전트(agent) 형태의 도구를 적극적으로 사용하는 개발자들이 많아졌다. 나 역시 최근에는 GitHub Copilot 에이전트 모드를 사용하거나, Claude Code를 통해 실제 코드베이스를 탐색하고 수정하는 흐름을 자주 사용하고 있다. 그리고 체감상 Claude Opus 4.6 모델이 꽤 좋은 결과를 보여줬다.

이번 글에서는 현업에서 AI 에이전트를 어떻게 활용하고 있는지, 그리고 잘 쓰기 위해 어떤 관점이 필요한지 정리해보려 한다.

AI 에이전트란 무엇일까?

간단히 말하자면 AI 에이전트는 답변만 하는 모델이 아니라, 주어진 목표를 해결하기 위해 스스로 탐색하고 도구를 사용하며 여러 단계를 수행하는 형태의 AI라고 볼 수 있다.

기존의 챗봇이 질문 하나에 답변 하나를 주는 데 가까웠다면, 에이전트는 그보다 조금 더 행동에 가깝다. 예를 들어 단순히 “이 에러 원인이 뭐야?”라고 설명하는 데 그치는 것이 아니라, 실제로 프로젝트 파일을 읽고, 관련 코드를 찾고, 수정안을 만들고, 필요한 경우 명령 실행이나 테스트까지 이어가는 식이다. GitHub Copilot 문서도 IDE의 agent mode를 “특정 작업을 주면 어떤 파일을 수정할지 결정하고, 코드 변경과 터미널 명령을 제안하며, 문제가 있으면 반복적으로 수정하는 방식”으로 설명하고 있다.

즉, 에이전트의 핵심은 “더 똑똑한 답변”이 아니라 문제를 해결하기 위한 작업 단위를 스스로 이어갈 수 있느냐에 있다.

현업에서 가장 자주 쓰는 활용 사례

1. 처음 보는 코드베이스를 빠르게 탐색할 때

현업에서는 내가 직접 작성하지 않은 코드가 훨씬 더 많다.

프로젝트에 새로 합류했거나, 예전에 만들어 둔 기능을 다시 볼 때 가장 먼저 드는 생각은 대개 비슷하다.

“이 로직이 어디서 시작되는 거지?”
“상태는 어디서 바뀌는 거지?”
“이 화면은 어느 API 응답을 바라보고 있지?”

이럴 때 에이전트는 꽤 강력하다.

단순히 검색창에 키워드를 넣는 것보다, “사용자 프로필 수정 플로우가 어디서 시작되고 어떤 API를 거쳐서 어떤 상태를 변경하는지 설명해줘”처럼 요청하면 코드 흐름을 훨씬 빠르게 잡아준다. 특히 폴더 구조가 크고 관심사 분리가 복잡한 프로젝트일수록, 에이전트는 사람의 첫 탐색 비용을 줄여주는 역할을 한다.

내가 체감하기로 에이전트의 첫 번째 가치는 “코드를 대신 짜주는 것”보다 “코드베이스를 빨리 이해하게 해주는 것”에 더 가깝다.

2. 반복적인 수정 작업을 맡길 때

현업의 많은 작업은 사실 창의적인 알고리즘 설계보다 반복 수정에 가깝다.

예를 들면 아래와 같은 일들이다.

여러 컴포넌트의 props 이름을 일괄 변경하는 작업
공통 유틸 함수로 로직을 묶는 작업
API 응답 타입이 바뀌었을 때 관련 타입을 전파 수정하는 작업
로딩, 에러, 빈 상태 UI를 여러 화면에 동일하게 붙이는 작업
콘솔 로그 제거, 불필요한 import 정리, lint 경고 해소

이런 작업은 사람이 해도 할 수 있지만, 집중력이 빨리 소모된다. 반면 에이전트는 명확한 규칙만 주어지면 생각보다 꾸준하게 처리한다.

예를 들어 아래처럼 요청할 수 있다.

users 관련 화면 전체에서 isLoading, isError, data 분기 패턴을 공통 훅으로 추출해줘.
기존 UI 구조는 유지하고, 파일 변경 이유를 각 파일마다 설명해줘.

중요한 점은 막연하게 “리팩터링해줘”라고 던지는 것보다, 범위와 제약을 같이 주는 것이다. 에이전트는 자유도가 너무 높아지면 오히려 불필요한 수정까지 하려는 경향이 있다.

3. 리팩터링 초안을 빠르게 잡을 때

리팩터링은 방향을 잡는 데 시간이 많이 든다.

특히 “어디까지 추상화해야 하는가”, “이 로직을 훅으로 빼는 게 맞는가”, “공통 컴포넌트로 묶는 순간 오히려 복잡해지지 않는가” 같은 판단은 늘 어렵다.

이때 에이전트는 정답을 주기보다 초안 몇 개를 빠르게 비교하게 해주는 도구로 쓸 때 좋다.

예를 들어 어떤 화면 컴포넌트가 지나치게 비대해졌다면 아래처럼 요청할 수 있다.

이 컴포넌트를 관심사 기준으로 분리하는 방법을 3가지 제안해줘.
각 방법의 장단점과, 지금 구조에서 가장 부작용이 적은 안을 추천해줘.
그리고 추천안 기준으로 실제 파일 분리 초안까지 만들어줘.

이렇게 하면 바로 완성본을 받는 것이 아니라, 설계안 자체를 비교하면서 생각할 수 있다.

개인적으로는 이 지점이 꽤 중요하다고 본다. 에이전트는 “내 생각을 대체하는 도구”가 아니라, 설계 후보를 빠르게 늘려서 비교 비용을 줄여주는 도구에 더 가깝다.

4. 테스트와 디버깅 보조에 사용할 때

버그 수정은 흔히 “원인을 안다”고 끝나지 않는다.

실제로는 아래 질문들이 더 어렵다.

이 수정이 다른 화면에는 영향이 없을까?
지금 깨진 것은 증상이고, 진짜 원인은 더 아래에 있는 것 아닐까?
테스트를 어디까지 써야 안전할까?

이럴 때 에이전트는 디버깅 보조 역할을 꽤 잘 수행한다.

에러 메시지와 관련 파일 몇 개를 주고 “가능한 원인을 우선순위대로 정리해줘”, “재현 경로를 추정해줘”, “가장 작은 수정으로 막을 수 있는 방법부터 제안해줘”라고 하면, 생각 정리에 도움이 된다.

또 수정 이후에는 다음처럼 활용할 수도 있다.

이 수정이 회귀 버그를 만들 수 있는 지점을 체크리스트로 정리해줘.
가능하면 테스트 코드 초안도 함께 작성해줘.

물론 테스트 코드가 항상 바로 통과하는 수준으로 나오는 것은 아니다. 하지만 최소한 “무엇을 검증해야 하는지”를 빠르게 정리해준다는 점에서 생산성이 높다.

5. 문서화와 인수인계 자료를 만들 때

현업에서는 코드를 작성하는 시간만큼, 그것을 설명하는 시간도 중요하다.

특히 기능을 배포하고 나면 아래 문서들이 자주 필요하다.

PR 설명
릴리즈 노트
기능 명세 초안
QA 체크리스트
회고 문서
팀원 인수인계 문서

에이전트는 이 부분에서도 꽤 유용하다.

실제 수정 diff를 읽게 한 다음 “변경 목적, 영향 범위, QA 포인트를 정리해줘”라고 하면 초안이 금방 나온다. 특히 개발자는 구현 당시 머릿속에는 너무 익숙한 내용이라 오히려 설명문을 쓰기 어려운 경우가 많은데, 에이전트는 그 설명의 첫 문장을 열어주는 역할을 한다.

그렇다면 에이전트에게 어디까지 맡겨도 될까?

여기서 중요한 점이 하나 있다.

에이전트를 많이 쓴다고 해서, 무조건 많은 일을 맡기는 것이 좋은 것은 아니다.

오히려 현업에서는 애매하게 어려운 문제일수록 전부 맡기기보다, 단위를 잘게 쪼개서 맡기는 편이 더 안정적이다.

예를 들어 “우리 서비스의 인증 아키텍처를 전면 개선해줘” 같은 요청은 범위도 넓고 판단 포인트도 많아서 실패하기 쉽다. 반면 아래처럼 나누면 훨씬 좋아진다.

현재 인증 플로우를 먼저 요약한다.
취약한 지점을 찾는다.
refresh token 처리 부분만 개선안을 낸다.
타입/에러 처리/UI 영향 범위를 나눈다.
마지막에 실제 코드 수정으로 들어간다.

즉, 에이전트는 거대한 문제를 한 번에 해결하는 마법 도구라기보다, 잘게 나눈 작업을 빠르게 이어서 처리하는 도구라고 보는 편이 맞다.

잘 쓰는 사람과 잘 못 쓰는 사람의 차이

AI 에이전트를 잘 쓰는 사람은 프롬프트를 화려하게 쓰는 사람이 아니다.

오히려 아래 세 가지를 잘하는 사람이다.

1. 작업의 범위를 명확하게 자른다

“리팩터링해줘”는 나쁜 요청이다.

“이 컴포넌트의 데이터 fetching 로직만 custom hook으로 분리하고, 기존 마크업은 유지해줘”는 좋은 요청이다.

좋은 요청은 목표가 작고, 변경 범위가 명확하고, 성공 조건이 보인다.

2. 제약 조건을 분명히 준다

현업 코드에는 늘 제약이 있다.

라이브러리를 추가하면 안 된다.
public API는 바꾸면 안 된다.
디자인 시스템 컴포넌트만 써야 한다.
기존 테스트를 깨면 안 된다.
성능 특성이 바뀌면 안 된다.

이 제약을 빼먹으면 에이전트는 너무 쉽게 “그럴듯하지만 곤란한 답”을 낸다.

3. 검토는 반드시 사람이 한다

이 부분은 아무리 강조해도 지나치지 않다.

에이전트는 상당히 유용하지만, 여전히 코드의 의미와 서비스의 책임을 최종적으로 지는 주체는 개발자다. 특히 인증, 결제, 권한, 데이터 정합성처럼 중요한 영역에서는 더더욱 그렇다.

나는 개인적으로 AI 에이전트를 사용할 때 아래 기준을 갖고 본다.

구조 제안은 적극적으로 받는다.
반복 수정은 넓게 맡긴다.
핵심 비즈니스 로직은 사람이 중심을 잡는다.
머지 전 최종 판단은 반드시 직접 한다.

실제로 써보며 느낀 한계

에이전트가 잘하는 것도 많지만, 당연히 한계도 있다.

가장 대표적인 것은 문제의 본질을 잘못 정의한 채 부지런히 일할 수 있다는 점이다.

즉, 방향이 틀리면 열심히 틀린 답을 만들어낸다.

예를 들어 어떤 버그의 진짜 원인이 상태 동기화 문제인데, 에이전트가 화면 컴포넌트만 계속 고치고 있을 수도 있다. 또는 현재 프로젝트의 컨벤션을 충분히 이해하지 못한 채, 코드 모양만 그럴듯하게 맞출 수도 있다.

그래서 에이전트를 쓸 때 중요한 것은 “얼마나 많이 시키는가”가 아니라, 중간중간 올바른 방향으로 가고 있는지 체크하는 것이다.

이 점에서는 오히려 사람 시니어 개발자와 일하는 감각과 비슷하다. 일을 던져놓고 기다리는 것이 아니라, 중간 산출물을 보면서 계속 방향을 맞춰야 한다.

결국 중요한 것은 도구보다 작업 분해 능력이다

요즘은 어떤 모델이 더 좋으냐, 어떤 에이전트 도구가 더 강하냐는 이야기가 많다.

물론 체감 차이는 분명히 있다. 실제로 GitHub Copilot은 여러 모델을 지원하고, Claude 쪽도 Claude Code와 Agent SDK, MCP 같은 흐름을 꾸준히 확장하고 있다.

하지만 현업에서 생산성을 가장 크게 가르는 것은 모델 이름 자체보다, 개발자가 문제를 얼마나 잘 쪼개고, 제약을 얼마나 명확히 전달하며, 결과를 얼마나 비판적으로 검토하는가에 더 가깝다고 생각한다.

AI 에이전트는 개발자를 대체하는 존재라기보다, 개발자의 사고 과정을 더 빠르게 순환시키는 도구다.

코드를 대신 쳐주는 도구로만 보면 생각보다 금방 한계를 느낄 수 있다. 반대로 코드베이스 탐색, 반복 수정, 리팩터링 초안 작성, 테스트 보조, 문서화까지 포함한 작업 흐름 전체의 가속 장치로 보면 꽤 강력하다.

결국 중요한 것은 “AI가 얼마나 똑똑한가”보다, 내가 이 도구를 어떤 단위의 일에 어떻게 연결할 수 있는가다.

나 역시 최근에는 AI 에이전트를 단순한 보조 도구가 아니라, 하나의 실무용 인터페이스처럼 다루게 되고 있다.

아마 앞으로의 개발 생산성 차이는 코드를 한 줄 더 빨리 치는 사람보다, AI 에이전트에게 더 정확한 작업을 맡기고 더 정확하게 검토할 수 있는 사람에게서 더 크게 벌어지지 않을까 싶다.

클린 코드가 모호한 개념인 이유, 선언적 프로그래밍과 추상화

토리나나 — Sat, 7 Jan 2023 20:35:58 +0900

클린 코드 (Clean code)

클린 코드는 가독성, 단순성 및 유지 관리 용이성을 강조하는 프로그래밍 스타일이다. 클린 코드의 원칙은 널리 받아들여지고 있지만 클린 코드의 개념은 다소 모호하고 해석의 여지가 있다. 프로그래머마다 무엇이 클린 코드를 구성하는지에 대해 서로 다른 의견을 가질 수 있으며 한 컨텍스트에서 클린 코드로 간주되는 것이 다른 컨텍스트에서는 클린 코드로 간주되지 않을 수 있다.

종종 논의되는 클린 코드의 한 측면으로 주석 사용이 있다. 어떤 프로그래머는 클린 코드가 자명해야 하고 최소한의 주석이 필요하다고 믿는 반면, 다른 프로그래머는 주석이 코드를 문서화하고 다른 프로그래머가 더 쉽게 이해할 수 있도록 만드는 중요한 부분이라고 주장한다.

논쟁의 또 다른 영역은 약어와 두문자어의 사용이다. 일부 프로그래머는 이것이 코드를 더 간결하고 읽기 쉽게 만들 수 있다고 주장하는 반면, 다른 사람들은 특히 사용된 약어와 두문자어에 익숙하지 않은 사람들이 코드를 이해하기 더 어렵게 만들 수 있다고 믿는다.

클린 코드를 작성할 때 코드의 가독성과 유지 관리 가능성에 주의를 기울이는 것이 중요하다. 여기에는 설명 변수 이름 사용, 코드를 논리 블록으로 구성, 공백 및 들여쓰기를 사용하여 코드 가독성을 향상하는 것이 포함된다. 일관된 코딩 스타일을 고수하고 불필요한 복잡성을 피하는 것과 같은 좋은 프로그래밍 관행을 따르는 것도 중요하다.

클린 코드의 주요 장점 중 하나는 이해하고 유지하기가 더 쉽다는 것이다. 깨끗한 코드를 변경하고 버그를 수정하는 것이 더 쉽기 때문에 장기적으로 시간과 노력을 절약할 수 있다. 정리가 잘 되어 있고 읽기 쉬운 코드에서 오류를 더 쉽게 발견할 수 있으므로 클린 코드는 정확할 가능성이 더 높다.

그러나 클린 코드에는 몇 가지 잠재적인 단점도 있다. 한 가지 우려 사항은 세부 사항에 더 많은 주의를 기울이고 가독성에 더 중점을 두어야 하기 때문에 코드를 작성하는 데 시간이 더 오래 걸릴 수 있다는 것이다. 또한 청결도와 성능 또는 효율성과 같은 기타 요인 사이에 트레이드 오프가 있을 수 있다.

결론적으로 클린 코드는 해석의 여지가 있는 주관적인 개념이다. 일반적으로 허용되는 클린 코드의 원칙이 있지만 클린 코드를 구성하는 요소는 코드의 컨텍스트와 목표에 따라 다를 수 있다. 클린 코드를 작성할 때 가독성, 유지 관리성 및 좋은 프로그래밍 방법에 주의를 기울이는 것이 중요하지만 성능 및 효율성과 같은 다른 요소를 고려하는 것도 중요하다.

선언적 프로그래밍 (Declarative programming), 추상화 (Abstraction)

선언적 프로그래밍은 프로그램이 어떻게 달성해야 하는지가 아니라 프로그램이 무엇을 달성해야 하는지에 초점을 맞추는 프로그래밍 패러다임이다. 선언적 프로그래밍에서 프로그래머는 원하는 결과를 지정하고 프로그래밍 언어 또는 프레임워크는 구현 세부 사항을 처리한다. 이렇게 하면 프로그래머가 코드 실행 방법에 대한 하위 수준 세부 사항에 대해 걱정할 필요가 없으므로 코드를 더 쉽게 읽고 이해할 수 있다.

추상화는 클린 코드의 또 다른 중요한 개념이다. 추상화에는 코드 조각의 기본 구현 세부 정보를 외부 동작과 분리하는 작업이 포함된다. 구현의 세부 사항을 추상화하면 프로그래머가 코드가 내부적으로 작동하는 방식에 대해 걱정할 필요가 없으므로 코드를 이해하고 유지 관리하기가 더 쉬워진다.

선언적 프로그래밍 및 추상화는 코드를 더 간결하고 이해하기 쉽게 만드는 데 도움이 되므로 깔끔한 코드를 작성하는 데 유용한 방법이 될 수 있다. 선언적 프로그래밍을 사용함으로써 프로그래머는 구체적인 구현 방법보다는 원하는 코드 결과에 집중할 수 있다. 추상화 또한 구현 세부 사항을 숨기고 코드의 외부 동작에 집중함으로써 코드를 단순화하는 데 도움이 될 수 있다.

그러나 선언적 프로그래밍과 추상화를 적절하게 사용하는 것이 중요하다. 이러한 기술을 과도하게 사용하면 너무 추상적이거나 이해하기 어려운 코드가 될 수 있다. 또한 추상화의 이점과 코드의 구현 세부 사항에 대한 제어를 유지해야 할 필요성 사이에서 균형을 유지하는 것이 중요하다.

결론적으로 선언적 프로그래밍과 추상화는 클린 코드를 작성하는 데 유용한 기술이다. 원하는 결과에 집중하고 구현 세부 사항을 추상화하여 코드를 더 간결하고 이해하기 쉽게 만들 수 있다. 그러나 이러한 기술을 적절하게 사용하고 추상화와 제어 사이의 균형을 맞추는 것이 중요하다.

[JS] 값(value)에 의한 전달과 참조(reference)에 의한 전달

토리나나 — Tue, 3 Jan 2023 17:44:45 +0900

JavaScript의 자료형에는 기본(Primitive) 자료형과 기본이 아닌(Non-primitive) 자료형으로 두 가지 유형의 자료형이 있다.

기본 자료형

JavaScript 언어에서 제공하는 미리 정의된 데이터 유형을 기본 자료형이라고 한다. JavaScript는 Number, String, Boolean, Undefined, Symbol 및 BigInt를 포함하는 여섯 가지 유형의 기본 자료형을 제공한다. 기본 자료형의 크기는 고정되어 있으므로 JavaScript는 콜 스택(실행 컨텍스트)에 기본 자료형을 저장한다.

기본 자료형에 액세스하면 해당 변수에 저장된 실제 값을 조작한다. 따라서 기본 변수는 값에 의해 액세스됩니다. 기본 값을 저장하는 변수를 다른 변수에 할당하면 변수에 저장된 값이 생성되어 새 변수에 복사된다.

참조 자료형

JavaScript 언어의 기본 자료형에서 파생된 데이터 유형을 참조 자료형이라고 한다. 기본이 아닌 자료형 또는 파생 자료형이라고도 한다. JavaScript는 Array, Object 및 Function을 포함하는 세 가지 유형의 참조 자료형을 제공한다. 참조 자료형의 크기는 동적이므로 힙에 저장된다.

참조 자료형에 액세스하면 저장된 실제 값이 아니라 참조를 통해 조작한다. 따라서 참조 값인 변수는 참조로 액세스된다. 한 변수에서 다른 변수로 참조 값을 할당할 때 변수에 저장된 값도 새 변수의 위치로 복사되지만, 차이점은 이제 두 변수에 저장된 값이 힙에 저장된 실제 객체의 주소라는 것이다. 결과적으로 두 변수는 동일한 객체를 참조하고 있으므로, 두 변수에서 원래 객체를 조작할 수 있다.

값에 의한 전달

JavaScript에서 함수에 기본 자료형 값을 인수로 전달하면 인수의 값이 함수에 전달되는데, 이를 값에 의한 전달(pass by value)이라고 한다.

다음은 JavaScript에서 값에 의한 전달의 예다.

function addOne(x) {
  x = x + 1;
  return x;
}

let a = 1;
let b = addOne(a);

console.log(a); // 1
console.log(b); // 2

이 예제에서는 `a`의 값이 인수로 `addOne()` 함수에 전달된다. 이 함수는 `x` 값을 1씩 증가시키고 결과를 반환한다. 그러나 함수 외부의 값은 변경되지 않는다. 이는 `a`의 값이 값에 의한 전달로 함수에 전달되고 함수 내에서 `x`의 값을 변경해도 `a`의 값에 영향을 주지 않기 때문이다.

참조에 의한 전달

JavaScript에서는 참조 자료형을 사용하여 참조에 의한 전달(pass by reference)을 구현할 수 있다. JavaScript에서 객체를 함수에 전달할 때 객체의 값은 여전히 값으로 전달된다. 그러나 객체의 값은 실제 객체 자체가 아니라 객체의 메모리 위치에 대한 참조라고 볼 수 있다. 즉, 함수 내의 객체에 대한 모든 변경 사항이 함수 외부의 원본 객체에 반영된다.

다음은 JavaScript에서 참조에 의한 전달을 구현한 예다.

function addOne(obj) {
  obj.x = obj.x + 1;
}

let obj = { x: 1 };
addOne(obj);

console.log(obj.x); // 2

이 예제에서 `{ x: 1 }` 객체는 `addOne()` 함수에 인수로 전달된다. 이 함수는 `obj.x`의 값을 1씩 증가시킨다. `obj`의 값은 객체의 메모리 위치에 대한 참조이므로 `obj.x`에 대한 변경은 함수 외부의 원본 객체에 반영된다.

이 동작은 기존 참조에 의한 전달과 다르다는 점에 유의해야 한다. JavaScript에서 객체의 값(메모리 위치에 대한 참조)은 함수에 값으로 전달되는 반면, 전통적인 참조에 의한 전달에서는 객체의 메모리 위치가 인수로 함수에 전달된다는 차이가 있다.

[JS] 자바스크립트의 깊은 복사와 얕은 복사

토리나나 — Mon, 2 Jan 2023 22:15:57 +0900

컴퓨터 프로그래밍에서 깊은 복사는 새 메모리 주소로 새 객체를 만들고 원래 객체의 속성 값을 새 객체에 복사하는 객체의 복사본이다. 반면 얕은 복사는 새 메모리 주소로 새 객체를 생성하지만 해당 속성에 대해 원본 객체와 동일한 객체(주소)를 참조하는 객체의 복사본이다.

다음은 자바스크립트를 사용하여 깊은 복사와 얕은 복사를 구현한 예제다.

const original = {
  a: 1,
  b: { c: 2 }
};

// original 객체의 얕은 복사본
const shallowCopy = { ...original };

// original 객체의 깊은 복사본
const deepCopy = JSON.parse(JSON.stringify(original));

// original 객체의 속성 수정
original.a = 10;

console.log(original); // { a: 10, b: { c: 2 } }
console.log(shallowCopy); // { a: 1, b: { c: 2 } }
console.log(deepCopy); // { a: 1, b: { c: 2 } }

// original 객체의 중첩된 속성 수정
original.b.c = 20;

console.log(original); // { a: 10, b: { c: 20 } }
console.log(shallowCopy); // { a: 1, b: { c: 20 } }
console.log(deepCopy); // { a: 1, b: { c: 2 } }

위 예제에서 `original`은 `a`와 `b`라는 두 가지 속성이 있는 객체다. `b` 속성은 그 자체로 속성 `c`를 가진 객체다.

`shallowCopy`는 `original` 객체에 확산(Spread) 연산자(`...`)를 사용하여 만든 얕은 복사본으로 `original`과 동일한 속성 및 값을 가진 새 객체를 포함하지만 속성 `b`에 대한 객체는 `original`과 같은 주소를 참조하는 동일한 객체이다.

예제에서 `deepCopy`는 `original` 객체의 깊은 복사본으로 `original`과 동일한 속성 및 값을 가진 새 객체를 포함하고 있으며, 속성 `b`에 대한 객체도 `original`과 동일한 속성 및 값을 가진 새 객체이다. 깊은 복사는 해당 속성이 다른 객체에 대한 참조인 경우에도 모든 속성에 대해 새 객체를 만드는 객체의 복사본이다. 즉, 깊은 복사본은 `original` 객체와 완전히 독립적이며 복사본을 변경해도 `original`에 영향을 미치지 않는다.

`JSON.parse(JSON.stringify(original))` 메서드는 객체의 깊은 복사본을 만드는 편리한 방법이지만 몇 가지 제한 사항이 있다는 점에 유의해야 한다. 이 방식은 단순한 객체에만 작동하며 깊은 복사 함수나 RegExps, Maps, Sets 및 기타 일부 객체 유형에 대해서는 올바르게 작동하지 않는다. 보다 강력한 솔루션을 위해 Lodash(아래 링크 참고)와 같은 라이브러리 또는 이러한 엣지 케이스를 처리할 수 있는 커스텀 함수를 사용해야 할 수도 있다.

https://lodash.com

Lodash

_.defaults({ 'a': 1 }, { 'a': 3, 'b': 2 });_.partition([1, 2, 3, 4], n => n % 2);DownloadLodash is released under the MIT license & supports modern environments. Review the build differences & pick one that’s right for you.InstallationIn

lodash.com

프로세스(Process)와 스레드(Thread)의 차이 및 개념 정리

토리나나 — Sat, 31 Dec 2022 20:12:03 +0900

컴퓨터 과학에서 프로세스는 실행 중인 프로그램의 인스턴스이고 스레드는 프로세스 내의 별도 실행 경로이다. 프로세스와 스레드는 모두 코드를 실행하고 작업을 수행하는 데 사용되지만 몇 가지 중요한 차이점이 있다.

리소스 소유권 (Resource ownership)

각 프로세스에는 프로세스가 소유하고 관리하는 메모리, 파일 핸들 및 열린 소켓과 같은 고유한 리소스 세트가 있다. 반면 스레드는 상위 프로세스의 리소스를 공유하는 경량 실행 경로이다.

메모리 관리 (Memory management)

프로세스에는 다른 프로세스로부터 보호되는 별도의 메모리 공간이 있다. 이는 각 프로세스가 실행 중인 데이터 및 코드의 별도 사본을 가지고 있음을 의미한다. 반면 스레드는 상위 프로세스의 메모리 공간을 공유하므로 상위 프로세스의 데이터에 액세스하고 수정할 수 있다.

스케줄링 (Scheduling)

일반적으로 프로세스는 CPU 시간의 공평한 분배를 보장하기 위해 운영 체제에 의해 스케줄링된다. 반면에 스레드는 일반적으로 운영 체제 또는 프로그래밍 언어 런타임에 의해 스케줄링된다.

통신 (Communication)

프로세스는 일반적으로 파이프, 소켓 또는 공유 메모리와 같은 IPC(inter-process communication: 프로세스 간 통신) 메커니즘을 사용하여 서로 통신한다. 반면 스레드는 프로그래밍 언어 런타임에서 제공하는 공유 메모리 또는 기타 메커니즘을 사용하여 서로 통신할 수 있다.

전반적으로 프로세스와 스레드는 모두 코드를 실행하고 작업을 수행하는 데 사용되지만 리소스 소유권, 메모리 관리, 스케줄링 및 통신 측면에서 차이가 있다. 프로세스는 일반적으로 별도의 리소스 집합과 다른 프로세스로부터의 보호가 필요한 작업에 사용되는 반면, 스레드는 리소스를 공유하고 병렬 실행의 이점을 얻을 수 있는 작업에 사용된다.