타임아웃이나 사용자 취소를 붙여 놓았는데도, 정작 긴 작업은 끝까지 돌아가 버리는 경우가 있습니다. 이럴 때 흔한 원인은 취소 신호는 만들어 뒀지만, 작업 중간에 실제로 멈출 지점을 넣지 않았기 때문입니다.

AbortSignal.throwIfAborted()는 이런 문제를 꽤 단순하게 정리해 줍니다. 핵심은 작업 흐름 곳곳에 “여기서 취소 여부를 확인한다”는 체크포인트를 명시적으로 넣을 수 있다는 점입니다.

AbortSignal.throwIfAborted가 필요한 이유

H3. 취소 신호만 전달하고 실제 중단은 안 되는 코드가 많다

예를 들어 아래처럼 AbortController를 연결해도, 내부 루프가 취소 여부를 확인하지 않으면 작업은 계속됩니다.

async function processItems(items, { signal }) {
  const results = [];

  for (const item of items) {
    const result = await heavyTransform(item);
    results.push(result);
  }

  return results;
}

이 코드는 signal을 받아도 중간에 멈추지 않습니다. 특히 CPU 작업, 배치 처리, 여러 단계의 비동기 파이프라인에서는 이런 문제가 자주 나옵니다.

H3. 체크포인트가 없으면 취소는 정책이 아니라 희망사항이 된다

취소를 제대로 동작하게 만들려면 아래 둘이 함께 있어야 합니다.

  1. 바깥에서 취소를 요청할 수 있어야 한다
  2. 안쪽 작업이 적절한 지점에서 취소를 확인해야 한다

AbortSignal.throwIfAborted()는 두 번째를 아주 짧게 표현합니다. 예외를 직접 만들 필요 없이, 중단 조건을 코드 한 줄로 드러낼 수 있다는 점이 실무에서 꽤 큽니다.

취소 신호를 여러 원인과 함께 묶는 기본 구조는 Node.js AbortSignal.any 가이드: 여러 취소 신호를 한 번에 묶어 안전하게 다루는 법과 같이 보면 더 잘 연결됩니다.

AbortSignal.throwIfAborted 기본 사용법

H3. 작업 시작 전과 반복 중간에 체크포인트를 둔다

async function processItems(items, { signal }) {
  signal?.throwIfAborted();

  const results = [];

  for (const item of items) {
    signal?.throwIfAborted();

    const result = await heavyTransform(item);
    results.push(result);
  }

  return results;
}

이 패턴의 장점은 분명합니다.

  • 함수 진입 직후 빠르게 중단할 수 있다
  • 긴 루프 중간에도 취소 응답성을 확보할 수 있다
  • if (signal.aborted) { ... } 분기보다 의도가 더 선명하다

H3. abort reason을 그대로 전달할 수 있다

const controller = new AbortController();
controller.abort(new Error('작업 시간이 초과되었습니다.'));

try {
  controller.signal.throwIfAborted();
} catch (error) {
  console.error(error.message);
}

이 방식의 좋은 점은 취소 사유를 상위 레이어까지 비교적 자연스럽게 전달할 수 있다는 것입니다. 단순히 true/false로만 끝내지 않고, 왜 멈췄는지 함께 남길 수 있어 디버깅에도 도움이 됩니다.

실무에서 자주 쓰는 패턴

H3. 배치 처리 루프의 초반에 넣는다

async function syncUsers(users, { signal }) {
  for (const user of users) {
    signal?.throwIfAborted();
    await saveUser(user);
  }
}

한 명씩 저장하는 배치 작업은 도중 취소가 특히 중요합니다. 체크포인트가 없으면 이미 필요 없어진 작업도 끝까지 실행해 DB, 큐, 외부 API를 더 두드리게 됩니다.

긴 루프의 응답성을 높이는 관점은 Node.js scheduler.yield 가이드: 긴 작업 중 이벤트 루프 응답성을 지키는 법과도 잘 맞습니다.

H3. 네트워크 호출 전후로 경계를 분리한다

async function loadProfile(userId, { signal }) {
  signal?.throwIfAborted();

  const response = await fetch(`https://api.example.com/users/${userId}`, {
    signal,
  });

  signal?.throwIfAborted();

  return response.json();
}

fetch 자체에 signal을 넘기는 것도 중요하지만, 호출 전후의 후처리 단계도 별개입니다. 특히 응답을 받은 뒤 JSON 변환, 정규화, 후속 저장까지 이어진다면 각 경계에서 한 번씩 체크하는 편이 안전합니다.

타임아웃과 취소를 함께 설계할 때는 Node.js timers/promises setTimeout 가이드: 지연·재시도 로직을 읽기 좋게 다루는 법도 함께 참고할 만합니다.

H3. 여러 단계 파이프라인에서 공통 진입 규칙으로 쓴다

async function runPipeline(input, { signal }) {
  signal?.throwIfAborted();

  const parsed = await parseInput(input);
  signal?.throwIfAborted();

  const validated = await validateInput(parsed);
  signal?.throwIfAborted();

  return persist(validated);
}

이 구조는 각 단계가 길어질수록 효과가 커집니다. “단계 전환 전에 취소를 확인한다”는 규칙만 팀 내에서 합의해도, 취소 누락 버그를 꽤 줄일 수 있습니다.

언제 특히 유용한가

H3. 오래 도는 루프, 큐 워커, 마이그레이션 작업

아래 같은 코드에서 특히 체감이 큽니다.

  • 대량 레코드 배치 처리
  • 큐 소비 워커
  • 파일 변환/압축 작업
  • 페이지네이션 기반 동기화 작업
  • 여러 단계의 후처리 파이프라인

이런 작업은 한 번 시작하면 길게 이어지기 쉽기 때문에, 취소 체크포인트 하나가 운영 부담을 크게 줄여 줍니다.

H3. 취소 자체보다 취소 응답 시간이 중요할 때

실무에서는 “취소 가능 여부”보다 얼마나 빨리 멈추는가가 더 중요할 때가 많습니다. 사용자가 취소 버튼을 눌렀는데 수 초에서 수십 초 동안 계속 일하는 시스템은 체감상 거의 취소가 안 되는 것과 비슷합니다.

AbortSignal.throwIfAborted()는 이런 응답 시간을 짧게 만드는 가장 단순한 도구 중 하나입니다.

사용할 때 주의할 점

H3. 체크포인트가 너무 드물면 효과가 약하다

루프 맨 앞에서만 한 번 확인하고, 그 안에서 5초짜리 작업이 계속 이어진다면 취소 반응은 여전히 느립니다. 중요한 것은 API를 아는 것보다 어디에 배치할지입니다.

보통은 아래 지점부터 점검하면 좋습니다.

  1. 함수 진입 직후
  2. 반복문 각 사이클 시작 지점
  3. 네트워크/디스크 작업 전후
  4. 단계가 바뀌는 경계

H3. 모든 예외를 같은 실패로 뭉개면 안 된다

throwIfAborted()가 던진 예외를 일반 처리 실패와 똑같이 로그/알림에 섞어 버리면 운영 해석이 꼬일 수 있습니다. 취소는 종종 정상적인 제어 흐름이기도 하므로, 아래처럼 분리하는 편이 좋습니다.

try {
  await runPipeline(input, { signal });
} catch (error) {
  if (signal?.aborted) {
    console.log('취소로 종료됨');
    return;
  }

  throw error;
}

오류 원인을 상위 문맥과 함께 전달하는 방식은 Node.js Error cause 가이드: 감싼 에러에서도 원인을 잃지 않는 법과도 이어집니다.

추천 적용 체크리스트

H3. 도입 전에 이 다섯 가지를 보면 실수가 줄어든다

  1. 긴 작업 함수가 signal을 실제로 받고 있는가?
  2. 함수 시작 직후 체크포인트가 있는가?
  3. 루프나 단계 경계마다 추가 체크포인트가 있는가?
  4. 취소와 일반 실패를 로그에서 구분하는가?
  5. 취소 사유를 상위 호출부까지 전달할 수 있는가?

이 다섯 가지만 챙겨도 취소 로직은 훨씬 덜 형식적이 됩니다.

마무리

AbortSignal.throwIfAborted()는 거창한 기능은 아니지만, 취소를 실제로 작동하는 정책으로 바꾸는 가장 실용적인 체크포인트 도구입니다. 특히 오래 도는 루프나 단계형 파이프라인이 많은 Node.js 코드에서는 한 줄짜리 확인만으로도 운영 경험이 꽤 좋아집니다.

정리하면 이렇게 기억하면 편합니다.

  • 취소 신호를 전달만 하지 말고 중간에 확인한다
  • 체크포인트는 함수 시작, 루프, 단계 경계에 둔다
  • 취소와 일반 오류는 로그와 제어 흐름에서 구분한다

함께 보면 좋은 글