(번역) 자바스크립트의 명시적 리소스 관리

February 26, 2026

원문 : Explicit resource management in JavaScript

자바스크립트에서 무언가(파일, 스트림, 락, 데이터베이스 연결 등)를 열 때는, 반드시 정리(cleanup)하는 것도 기억해야 합니다. 솔직히 말해서, 그 정리는 항상 이루어지지는 않습니다. 저 역시 한두 번이 아니라 여러 번 놓친 적이 있습니다.

자바스크립트는 항상 이 문제를 개발자의 책임으로 남겨두었습니다. 우리는 try / finally에 의존하고, 스스로 조심하겠다고 다짐하며, 혹시라도 예외 케이스를 놓치지 않았기를 바랄 뿐입니다. 대개는 동작하지만, 코드가 장황해지고 미묘하게 틀리기 쉬우며, 하나 이상의 리소스를 다루기 시작하면 확장성도 급격히 나빠집니다.

이제야 그 상황이 바뀌기 시작했습니다. 명시적 리소스 관리는 “이것은 반드시 정리되어야 하며, 런타임이 그걸 보장한다”라고 선언할 수 있는 1급(first-class) 언어 수준의 방법을 자바스크립트에 제공합니다.

관례나 패턴이 아니라, 언어 자체의 일부로 말이죠.

우리는 정리를 잘 못합니다 (그리고 언어도 돕지 않습니다)

아래 패턴은 익숙하게 느껴질 겁니다.

const file = await openFile("data.txt");

try {
  // 파일로 무언가를 수행합니다.
} finally {
  await file.close();
}

이 코드는 괜찮습니다. 하지만 동시에 아래와 같은 특징을 가지고 있습니다.

장황합니다
반복적입니다
복잡도가 커질수록, 특히 리팩터링 중에, 쉽게 실수할 수 있습니다

이제 리소스를 하나 더 추가해 봅시다.

const file = await openFile("data.txt");
const lock = await acquireLock();

try {
  // file과 lock으로 작업
} finally {
  await lock.release();
  await file.close();
}

이제 정리 순서가 중요해졌습니다. 에러 경로도 중요해졌습니다. 이 모든 것을 논리적으로 추론할 수는 있지만, 그에 따른 인지적 부담은 계속 쌓입니다. 그리고 그 부담이 커질수록, 버그도 따라오기 마련입니다.

다른 언어들은 이 문제를 수년 전에 해결했습니다. 자바스크립트는 (아주 천천히) 따라잡고 있는 중입니다.

📌 비동기를 더 깊이 파보기 루프 안에서의 await는 생각한 것과 다르게 동작하는 경우가 많습니다. 여기서부터 문제가 복잡해지기 시작합니다.

`using`: 정리하되, 런타임의 책임으로

개념적으로, using은 스코프를 벗어날 때 자동으로 정리될 리소스를 선언합니다.

코드로 보면 다음과 같습니다.

using file = await openFile("data.txt");

// 파일로 무언가를 수행

// 파일은 이 스코프의 끝에서 자동으로 닫힙니다

try도 없고, finally도 없으며, “닫는 걸 잊지 않았나?”라는 걱정도 없습니다.

핵심적인 변화는 정리가 제어 흐름이 아니라 변수의 수명에 묶인다는 점입니다.

정리는 실제로 어떻게 동작할까요

리소스는 잘 알려진 심볼을 구현하는 방식으로 이 기능을 활성화(opt-in)합니다.

Symbol.dispose — 동기식 정리
Symbol.asyncDispose — 비동기식 정리

예를 들면 다음과 같습니다.

class FileHandle {
  async write(data) {
    /* ... */
  }

  async [Symbol.asyncDispose]() {
    await this.close();
  }
}

값이 이 메서드 중 하나를 가지고 있으면 using과 함께 사용할 수 있습니다.

중요한 점은, using이 파일을 “마법처럼” 닫아주는 것이 아니라, 각 라이브러리가 제각각 구현하던 정리 방식을 표준화한다는 점입니다.

`await using`이 필요한 경우

정리 작업이 비동기적인 경우, 일반적으로 await using을 아래와 같이 사용합니다.

await using file = await openFile("data.txt");

// 파일로 비동기 작업

스코프가 끝나면 자바스크립트는 정리가 끝날 때까지 기다린 뒤 다음으로 진행합니다.

동기식 리소스(락, 메모리 내 구조체 등)는 일반 using을 사용할 수 있습니다. 처음에는 어색하게 느껴질 수 있지만, 이는 자바스크립트가 다른 곳에서도 동기와 비동기의 경계를 구분해 온 방식과 일치합니다. 중요한 건, 스코프 종료 시점에 정리가 보장된다는 것입니다.

📌 비동기를 고려한 설계 Array.fromAsync()는 자바스크립트가 마침내 비동기를 1급 개념으로 다루기 시작했다는 신호 중 하나입니다. 현대적인 비동기 반복 처리 방식에 대한 글을 참고하세요.

머리 아플 일 없이 리소스 쌓기

여기서부터 진짜 개선이 체감되기 시작합니다.

기존에는 이렇게 작성했습니다.

const file = await openFile("data.txt");
const lock = await acquireLock();

try {
  // 작업 수행
} finally {
  await lock.release();
  await file.close();
}

이제는 이렇게 작성할 수 있습니다.

await using file = await openFile("data.txt");
using lock = await acquireLock();

// 작업 수행

정리는 자동으로 수행되며, 스택처럼 역순으로 이루어집니다.

lock이 해제되고
file이 닫힙니다

추가적인 구문도 없고, 에러가 발생해도 정리가 중단되지 않으며, 정리 순서도 명확히 정의되어 있습니다.

핵심은 스코프입니다

using 선언은 const나 let과 마찬가지로 스코프를 가집니다.

{
  await using file = await openFile("data.txt");
  // 파일은 여기서 유효합니다
}

// 파일은 여기서 정리됩니다

이는 자연스럽게 더 좁은 스코프로 유도하고, 자바스크립트가 역사적으로 표현하기 어려웠던 리소스의 수명을 코드 자체에 드러내도록 만듭니다. 코드에서 수명이 한 번 보이기 시작하면, 다시는 안 보이던 시절로 돌아가기 어렵습니다.

`using`으로 부족할 때

모든 리소스가 블록에 깔끔하게 들어맞는 것은 아닙니다. 때로는 획득이 조건부이거나, 기존 코드를 리팩터링 하는 과정에서 새로운 스코프를 여기저기 추가하고 싶지 않을 수도 있습니다.

그럴 때를 위해 DisposableStack과 AsyncDisposableStack이 있습니다.

const stack = new AsyncDisposableStack();

const file = stack.use(await openFile("data.txt"));
const lock = stack.use(await acquireLock());

// 파일과 락으로 작업

await stack.disposeAsync();

using과 동일한 안전성을 제공하면서 더 많은 유연성을 줍니다. using이 깔끔한 선언적 케이스라면, 스택은 탈출구에 해당합니다.

이것은 백엔드 전용 기능이 아닙니다

처음 보면 서버 사이드 기능처럼 느껴질 수 있지만, 프런트엔드나 플랫폼 코드에도 그대로 적용됩니다.

Web Streams
navigator.locks
옵저버와 구독
IndexedDB 트랜잭션

subscribe() / unsubscribe() 또는 open() / close()를 써본 적이 있다면, 이 기능은 한 번쯤 눈여겨볼 만합니다.

이건 단순히 정확성의 문제가 아닙니다. 리소스의 수명을 관례나 주석에 숨기는 대신, 코드에서 드러내는 것에 관한 이야기입니다.

한계는 무엇일까요?

2026년 초 기준으로, Chrome 123+, Firefox 119+, Node.js 20.9+에서 이 기능들이 모두 지원됩니다. 사파리 지원은 아직이지만, 이미 로드맵에는 올라가 있습니다.

지금 당장 전면 도입하기보다는, 실험해 보거나, 특히 라이브러리나 플랫폼 수준의 추상화를 유지보수한다면 API 설계 단계에서부터 염두에 둘 만한 기능입니다. 당장 using을 쓰지 않더라도, 이 모델 자체는 충분히 주목할 가치가 있습니다.

정리를 위한 더 나은 기본값

명시적 리소스 관리는 try / finally를 대체하지 않습니다. 여전히 세밀한 제어가 필요할 때는 사용할 것입니다.

하지만 이 기능이 제공하는 것은 더 나은 기본값입니다. 보일러플레이트는 줄어들고, 누수는 줄어들며, 의도는 더 명확해지고, 코드 가독성도 훨씬 좋아집니다. 자바스크립트가 점점 더 시스템 수준의 책임을 떠안게 되는 지금, 이런 기능들은 있으면 좋은 것(nice-to-have)이 아니라 필수 요소(table stakes)처럼 느껴집니다.