Promise.try가 이제 기준으로 새로 제공됩니다.  |  Articles  |  web.dev

이제 Promise.try가 모든 주요 브라우저 엔진에 출시되어 기준을 새로 사용할 수 있습니다.

https://web.dev/blog/promise-try-baseline?hl=ko

Promise.try 이것이 표준으로 올라왔다고 했을때, 살펴봤었지만. 무엇을 위한 것인지를 바로 이해하기는 쉽지 않았다. 분명 어떤 목적을 가지고 탄생했을텐데… 오히려 엄청난 기능이면 몰라도, 이런 소소한 것이 추가된 것에는 분명 스토리가 있을 것 같았다. 설령 대단한 이야기는 아니더라도. 오늘은 고고학자가 되어 이번 기회에 그 기원과 제안과정, 그리고 구현에 대해서 같이 살펴보자.

Promise.try()

Promise의 정적메서드 라인업에 새로이 추가된 메서드이다. 간단하게 설명하자면, Promise.try(fn, …args)는 콜백 fn을 즉시(동기적으로) 실행한 뒤 결과를 프로미스로 감싸 돌려준다. 무슨말인가 하면 이렇다. 예시를 들어보자.

동기일 수도 있고 비동기일 수도 있는 함수 f가 있다고 하자. (async await 은 잠시 제쳐두고)

function f() {
  // 동기일수도 있고 비동기 일수도 있다.
  if (Math.random() < 0.5) {
    throw new Error("sync fail");
  }
  return Promise.reject(new Error("async fail"));
}

f가 만약 그냥 동기 함수 였다면 에러를 이렇게 처리했을 것이다.

try {
  f();
} catch (e) {
  console.log(e.message);
}

반대로 f가 Promise를 반환하는 함수였다면 이렇게 처리했을 것이다.

f().catch(console.log);

그런데 만약 f가 동기일 수도 있고 비동기일 수도 있다면 어떻게 해야할까? 뭐 그럴 상황은 많이 없겠지만 만약 있다면 이렇게 해야할 것이다.

Promise.resolve().then(f).catch(console.log);

이렇게 사용하면 어떤 문제가 있을까?
f의 실행시점이 달라지게 된다. 이벤트루프의 동작 순서를 생각해보자. Promise.resolve().then(f).catch(console.log) 의 실행 흐름은 다음과 같다.

1. Promise.resolve()는 이미 fulfilled 상태인 프라미스를 즉시 반환한다.
2. .then(f)는 f를 onFulfilled 핸들러로 등록하고, 해당 Reaction Job을 microtask 큐에 넣는다.
3. 현재 콜스택이 모두 비워진 뒤, 이벤트 루프가 그 microtask를 처리하면서 f 를 실행한다.
4. f가 동기적으로 예외를 던지면, 그 예외는 .then이 반환한 새 프라미스의 reject 상태로 변환되고, 이어진 .catch가 이를 받는다.

결과적으로 f는 다음 tick에서 실행되게 된다. 그로인해 콜스택이 끊기게 되고, 이는 디버깅을 어렵게 만들고, 예외 전파도 한 박자 늦어진다.

이때 Promise.try가 이 모든것을 바로잡고자 등장하게 된다.

Promise.try(f).catch(console.log);

이렇게 사용하게 되면 Promise.try 안에서 f를 즉시 실행하고 값이면 resolve, throw 이면 reject로 처리해준다. 물론 비동기이면 그대로 비동기로 처리해준다. 동기일 때의 케이스를 비동기와 균일하게 처리해주는 용도라고 보면 된다. 이렇게 되면 f의 실행시점이 밀리지도 않고, 동기인 에러를 만날 때에도 현재 콜스택에서 실행,트레이스가 끊기지 않는다.

그런데 의문이 들 수 있다.

우선 Promise 의 타임라인을 짧게 훑고 가자.

ES6에서 Promise 가 등장하게 된다. 그 이후 ES2017에서 async await 가 등장하게 된다.

당신은 이제 저 사이, async await이 등장하기 이전 개발자라고 생각해보자.

파일을 읽어서 json 파싱하는 코드를 작성해야 한다고 하자. 이때 파일이 json 파일인지 확인하고, 맞으면 파싱하고, 아니면 에러를 던지는 코드를 작성해야 한다. 아래와 같이 작성 해볼 수 있을 것이다.

const fs = require("fs").promises;

const readFile = (file) => {
  if (!file.endsWith(".json")) {
    throw new Error("not json");
  }
  return fs.readFile(file, "utf8");
};

이 함수는 파일명에 따라 동기적으로 처리되거나 비동기적으로 처리된다. 그에 따라 위에서 살펴봤던것 과같이 처리하면 아래와 같이 된다.

Promise.resolve()
  .then(() => readFile("some.json"))
  .then(JSON.parse)
  .catch(handleError);

코드의 의도를 파악하는데 불필요한 요소들이 개입하게 되게된다. resolve와 then 은 단지 Promise로 감싸주는 역할만 할뿐 일종의 트릭이다.

당시에도 이런식의 문제를 해결하기 위해 지금의 Promise.try 와 같은 형태의 라이브러리들을 만들어 사용했다. 대표적으로 Bluebird 라이브러리에서는 아래와 같이 사용할 수 있었다.

Bluebird.try(readJsonFile, "some.json").catch(handleError);

구현을 살펴보면 throw된 값을 다시 프로미스로 감싸서 반환하는 형태로 구현되어 있다. (코드는 살짝 간추렸다.)

// https://github.com/petkaantonov/bluebird/blob/master/src/method.js
Promise.attempt = Promise["try"] = function (fn) {
  var ret = new Promise(INTERNAL);
  ret._captureStackTrace();
  ret._pushContext();

// 동기 호출
var value = tryCatch(fn)();

// 결과를 프로미스로 감싸서 반환
ret.\_resolveFromSyncValue(value);
return ret;
};

이렇게 보면 Promise.try 는 꽤나 획기적인 편리한 메서드로 보인다.
그런데 위와 같은 불편함을 느껴본적이 많은가? 나는 그렇게 많이 느껴본적은 없었다.

왜냐하면 우리에겐 async await가 있기 때문이다. 위의 코드를 다시 async await 로 작성하면 아래와 같이 된다.

const readJsonFile = async (file) => {
  if (!file.endsWith('.json')) {
    throw new Error('not json');
  }
  return fs.readFile(file, 'utf8');
}

const processJsonFile = async () => {
  try {
    const data = await readFile('some.json');
    return JSON.parse(data);
  } catch (e) {
    console.log(e.message);
  }
}

이렇게 되면 동기일 때와 비동기일 때 모두 동일하게 처리할 수 있다.

다른 예시로는 copy도 들어볼 수 있겠는데.

const copy = (text) => {
  return Promise.try(() => {
    if (navigator.clipboard) return navigator.clipboard.writeText(text);
    // ... some code for document.execCommand
    document.execCommand("copy");
  });
};

clipboard가 지원되는경우는 Promise를 return하는 메서드인 navigator.clipboard.writeText 을 사용하고, 지원되지 않는 경우는 동기 메서드인 document.execCommand 를 사용한다. 이럴때 써볼 수 있을 것이다. 하지만 async await 를 사용하면 더 깔끔하게 처리할 수 있다.

const copy = async (text) => {
  if (navigator.clipboard) {
    await navigator.clipboard.writeText(text);
  } else {
    // ... some code for document.execCommand
    document.execCommand("copy");
  }
};

그렇다면 왜 이제야 Promise.try 가 등장했을까? 위에도 언급했지만 Promise.try 는 Promise의 등장 이후 그리고 async await 가 등장하기 이전 그 사이에 제안되었다. [tc39]Proposal Promise-try의 첫 커밋을 살펴보면 2016년도이다. 그리고 라이브러리 형태의 구현체는 그보다 전부터 있어왔다.

2016년도에 제안되었는데 왜 이제야 등장했을까?

치열한 설득

Promise.try가 2016년 제안되고 2024년 최종적으로 Stage 4로 승격되고 배포 되기까지 어떤 과정들이 있었는지 살펴보자.

Stage 1 - 2016.9~11

위에서 언급했던 것처럼 Promise.try는 2016년 Jordan Harband(https://github.com/ljharb)에 의해 제안되었다.
2016년 9월 처음 Stage1로 제안되었으나, 당시 다른 아젠다에 밀려서 논의되지 못하고 그해 11월에 본격적으로 논의 되었다.

proposal-promise-try/README.md at f2c8fdca4b09305a0c2dbcf16c1339b9d1ce8a58 · tc39/proposal-promise-try · GitHub

ECMAScript Proposal, specs, and reference implementation for Promise.try - proposal-promise-try/README.md at f2c8fdca4b09305a0c2dbcf16c1339b9d1ce8a58 · tc39/proposal-promise-try

https://github.com/tc39/proposal-promise-try/blob/f2c8fdca4b09305a0c2dbcf16c1339b9d1ce8a58/README.md

당시의 근거도 아까 살펴본 예시대로 색깔을 알지 못하는 함수들에 대해서 불필요한 syntax를 사용하는 것을 방지하기 위해서였다.

아래의 미팅내역은 당시 미팅 기록을 보기 좋게 다듬어 본것이다.

function foo(relativeURL) {
  const absoluteURL = new URL(relativeURL, someBaseURL).href;

  return fetch(absoluteURL);
}

foo("http:0"); // 예외 발생!! 이런

function foo(relativeURL) {
  return Promise.try(() => {
    const absoluteURL = new URL(relativeURL, someBaseURL).href;

    return fetch(absoluteURL);
  });
}

function foo(relativeURL) {
  return (async () => {
    const absoluteURL = new URL(relativeURL, someBaseURL).href;

    return fetch(absoluteURL);
  })();
}

async function foo(relativeURL) {
  const absoluteURL = new URL(relativeURL, someBaseURL).href;

  return fetch(absoluteURL);
}

function foo(relativeURL) {
  return async do {
    // ?!?!?!
    var absoluteURL = new URL(relativeURL, someBaseURL).href;

    fetch(absoluteURL);
  };
}

우리가 위에서 살펴봤던 것 처럼 해당 미팅에서도 Promise.try가 필요한 케이스에 대한 의문이 강하게 제기되었다.
그렇게 일단 Stage 1에 머문채로 시간은 흘러 8년의 시간이 흘렀다.

Stage 2 - 2024.2

2024년 2월 긴 시간 끝에 Promise.try에 대한 Stage 2 논의가 시작되었다.

Stage2 로 진입하기 위해서 Promise.try 관련 라이브러리에 사용량으로 설득을 시도했지만, 아직 여전히 Promise.try에 대한 의문은 여전히 남아있었다.
대부분의 사용처는 jest였다고 한다. Jordan Harband도 tape 라는 테스팅라이브러리를 다뤘던 것을 생각하면 이해가 가는 부분이다. 테스팅하는 라이브러리 입장에서는 테스트 콜백이 동기인지, 비동기인지 모를 수 있기 때문에 이를 위해 저런 식의 방법들이 필요하지 않았을까 추측해본다.

Stage 2.7 - 2024.04

Stage2에 접어든 뒤로는 일사천리로 진행되었다.
그러나 여전히 이전과 동일한 의문은 계속 존재하였다. Promise에 기존에 catch, finally가 있으니 try도 있으면 자연스럽다는 의견도 있었고, 분위기는 있으면 유용하긴 할 것 같지만, 막상 본인은 잘 사용할 것 같지 않다라는 의견이 주된 의견이었다.

async IIFE와 동등하지 않냐는 의견도 었었다. 이부분은 가끔 우리가쓰는 패턴에도 적용할 수 것 같다.
잦지는 않지만 가끔 아래와같이 effect 내에서 비동기를 처리하기 위해 아래와 같은 패턴이 쓰이곤 한다. (예시이다)
나 역시도 IIFE 패턴이 조금더 익숙하긴하지만, 그치만 인지적으로 코드를 읽는 과정에선 후자도 충분히 직관적이라는 생각이 든다. 이 논의에서는 await 구문의 트랜스파일링 비용이 더 비싸다는 점을 근거로 들고 있다.

// ① async IIFE 패턴
useEffect(() => {
  (async () => {
    try {
      const res = await fetch("https://api.example.com/data");
      const data = await res.json();
      console.log(data);
    } catch (err) {
      console.error(err);
    }
  })();
}, []);

// ② Promise.try 패턴
useEffect(() => {
  Promise.try(() => fetch("https://api.example.com/data"))
    .then((res) => res.json())
    .then(console.log)
    .catch(console.error);
}, []);

Stage 3 - 2024.06

여기서 부터는 이제 많은 것들이 합의 되었고, 구현이 되기 시작했기에 큰 이견 없이 승격되었다. test262에 테스트가 병합되었고, 브라우저들이 구현을 시작했다. (ECMA-262에 대한 테스트란 의미로 test262라고 부른다.) https://github.com/tc39/test262/tree/main/test/built-ins/Promise/try

Stage 4 - 2024.10

2024년 10월 드디어 최종 승격이 되었다.

어떻게 구현 되었을까?

미팅노트를 쭉 따라오면서 제안이 발의되고 최종 승인되기 까지 과정을 살펴보았다.
그렇다면 실제 구현은 어떻게 이뤄져있을까? 먼저 스펙을 살펴보자.

번역하면 아래와 같다.

스팩의 의사코드 읽는 법은 아래의 두 문서를 참고해보자

ECMAScript® 2026 Language Specification

No description available

https://tc39.es/ecma262/multipage/notational-conventions.html#sec-algorithm-conventions

간단하게 설명해보자면 callback을 받아서 실행하고 그 결과에 따라 Promise로 만들어서 반환한다.

자 그럼 바로 v8상의 구현으로 넘어가보자. 일단은 주석에 집중해보자.

https://source.chromium.org/chromium/chromium/src/+/main:v8/src/builtins/promise-try.tq\ https://github.com/v8/v8/blob/main/src/builtins/promise-reaction-job.tq

// Copyright 2024 the V8 project authors. All rights reserved.
// Use of this source code is governed by a BSD-style license that can be
// found in the LICENSE file.

namespace promise {

// https://tc39.es/proposal-promise-try/#sec-promise.try
@incrementUseCounter('v8::Isolate::kPromiseTry')
transitioning javascript builtin PromiseTry(
    js-implicit context: Context, receiver: JSAny)(...arguments): JSAny {
  // 1. Let C be the this value.
  // 2. If C is not an Object, throw a TypeError exception.
  const receiver = Cast<JSReceiver>(receiver)
      otherwise ThrowTypeError(MessageTemplate::kCalledOnNonObject, 'Promise.try');

  // 3. Let promiseCapability be ? NewPromiseCapability(C).
  const capability = NewPromiseCapability(receiver, False);

  // 4. Let status be Completion(Call(callbackfn, undefined, args)).
  const callbackfn = arguments[0];
  let result: JSAny;
  try {
    if (arguments.length <= 1) {
      result = Call(context, callbackfn, Undefined);
    } else {
      const rest = NewRestArgumentsFromArguments(arguments, 1);
      result = Call(
          context, GetReflectApply(), Undefined, callbackfn, Undefined, rest);
    }
  } catch (e, _message) {
    // 5. If status is an abrupt completion, then
    //   a. Perform ? Call(promiseCapability.[[Reject]], undefined, «
    //      status.[[Value]] »).
    Call(context, UnsafeCast<Callable>(capability.reject), Undefined, e);

    // 7. Return promiseCapability.[[Promise]].
    return capability.promise;
  }

  // 6. Else,
  //   a. Perform ? Call(promiseCapability.[[Resolve]], undefined, «
  //      status.[[Value]] »).
  Call(context, UnsafeCast<Callable>(capability.resolve), Undefined, result);

  // 7. Return promiseCapability.[[Promise]].
  return capability.promise;
}

}  // namespace promise

v8 상의 코드를 잘 보면 위에서 살펴본 스펙의 의사코드가 그대로 주석으로 코드상에 기록되어있다.
얼추 코드를 살펴보면 주석의 의사코드와 거의 동일하게 구현되어있는걸 볼 수 있다. 이 코드는 typescript처럼 닮았는데 확장자를 보면 tq라는 확장자를 쓰고 있다. 이때 이 tq는 torque의 줄임말이다.
막상 구현을 찾아봤을때 c++을 마주할 줄 알았는데 torque라는 언어는 도대체 무엇인가?

Torque

Torque는 v8 에서만 사용되는 DSL(Domain Specific Language)이다.
Torque의 메뉴얼을 참고해보면 위의 의문에 대한 답이 나온다. (https://v8.dev/docs/torque)

V8 Torque is a language that allows developers contributing to the V8 project to express changes in the VM by focusing on the intent of their changes to the VM, rather than preoccupying themselves with unrelated implementation details. The language was designed to be simple enough to make it easy to directly translate the ECMAScript specification into an implementation in V8, but powerful enough to express the low-level V8 optimization tricks in a robust way, like creating fast-paths based on tests for specific object-shapes.

V8 Torque는 V8 프로젝트에 기여하는 개발자가 구현 세부 사항에 얽매이지 않고 “무엇을 바꾸고 싶은지” 그 의도에 집중해 VM 로직을 작성하도록 돕는 언어입니다. ECMAScript 사양을 V8 코드로 손쉽게 옮길 만큼 단순하면서도, 특정 객체 형태를 판별해 빠른 실행 경로를 만드는 등 V8의 저수준 최적화 기법도 튼튼하게 표현할 수 있을 정도로 강력하게 설계되었습니다.

Torque의 목적 자체가 기존 구현에 있어서 조금더 human readable하게 만드는 것을 목표로 하고 있다. 그에 대한 방식으로 최대한 스펙의 의사코드의 의도를 그대로 들어낼 수 있도록 만들어졌다.

탄생 배경

초창기 V8은 내장 함수를 대부분 셀프-호스팅 JavaScript(V8 전용 방언)로 작성되었다. 이 방식이 괜찮긴했는데, Array의 메서드들 같이 호출이 잦고 사양이 복잡한 함수들은 워밍업 과정을 거쳐야 빨라지곤 했다. 그래서 이런 핵심 내장을 아키텍처별 어셈블리로 직접 짜서 **“첫 호출부터 최고 성능”**내려고 열심히 작성되었었다. 그런데 문제는 어셈블리로 작성하다보니 각 플랫폼마다 수만 줄씩 코드를 복제해야 했고, 유지보수가 점점 힘들어지게 되었다.

2015년 TurboFan 최적화 컴파일러가 도입되면서 상황이 달라지게 된다. TurboFan 백엔드가 사용하는 공통 저수준 IR을 사람이 직접 다룰 수 있게 한 C++ DSL **CodeStubAssembler(CSA, 2016)**가 등장하게 된다. 덕분에 한 번 작성한 코드가 모든 플랫폼에 최적화된 어셈블리로 변환되었고, 많은 수제 어셈블리 코드들을 걷어낼 수 있었다.

하지만 CSA조차 사람이 일일이 써야 해 여전히 어렵긴했고, 그로인한 리스크도 존재했다. 그래서 2019년, ECMAScript 의사코드를 거의 그대로 베껴 쓰면 나머지 보일러플레이트와 안전 검사를 컴파일러가 자동 생성하도록 하는 상위 DSL Torque가 등장하게 되었던 것이다. Torque 코드는 중간 단계인 CSA C++ 코드로 변환되고, TurboFan이 다시 머신 코드로 바꿔주게 된다.

정리하면 JS 셀프-호스팅 → 어셈블리 fast-path → CSA(CodeStubAssembler) → Torque 순으로 겹겹이 생겨난 셈이다.

구체적인 내용은 아래의 Tobias Tebbi의 발표를 살펴보면 잘 나와있다.

그렇다면 torque로 구현된 코드는 어떻게 변환될까?
v8내 소스를 보면 torque의 컴파일러도 존재한다. https://github.com/v8/v8/blob/main/src/torque/torque-compiler.cc

이름의 유래

V8과 관련된 툴들의 이름은 대부분 엔진과 관련된 용어들로 지어진다. 대표적으로 Ignition, Sparkplug, TurboFan 등이 있다. 토크도 회전력을 의미하기에 엔진의 힘을 의미하긴 하지만, 다른 작명에 비해 엄청 와닿지는 않는 거 같다. 직접적으로 엔진과 관련되었다기 보단, 토크를 가해서 CSA로 비틀어준다는 그런 은유가 아닐까?

흠

Promise.try의 쓸모를 찾아보다가 이것 저것 많은 것들을 살퍼보았다. 제안과정을 살펴볼때 여러번의 의문제기를 맞는 것을 보며, 괜시리 내가 더 숨이 막혀왔다. 어떤식으로 여러 메서드들이 우리에게 도착하게 되는지 궁금한 이에게 도움이 되었길 바란다.

참고 문헌

1. Promise.try - MDN Web Docs
2. Promise.try() support now enabled in Chrome (web.dev)
3. TC39 Proposal - Promise.try specification
4. Original TC39 Promise.try Proposal README
5. Bluebird - Promise.try documentation
6. What is Promise.try, and why does it matter? (Joepie91’s blog)
7. GitHub - TC39 Promise.try issue discussion
8. V8 Torque documentation
9. V8 Torque Builtins documentation
10. V8 CodeStubAssembler blog post
11. Chromium Source - Promise.try implementation in Torque
12. V8 Torque Compiler source code
13. Jfokus 2020 - V8 Torque: A Typed Language to Implement JavaScript (slides)
14. Tobias Tebbi - V8 Torque: A Typed Language to Implement JavaScript (YouTube)