인사이트리포트

들어가며

매년 6월 마다 ECMAScript(ES)^[1]의 새로운 명세가 공개된다. 이번 글에서는 올해 ES2024에 포함된 새로운 명세가 어떤 것인지 살펴보고 어떤 변화가 있는지 알아보고자 한다.
ECMAScript란 ECMA International이 ECMA-262 기술 규격에 따라 정의하고 있는 표준화 된 스크립트 프로그래밍 언어를 의미하며, JavaScript는 ECMAScript 표준을 준수하는 언어 중 하나이다.
그렇다면 매년 ECMAScript 표준에 새로운 명세가 추가되기 위해서 어떤 과정을 거치는 걸까? 이 과정은 공식적으로 정해져 있으며, 누구나 참여할 수 있다. 간단히 적자면 Technical Committee 39(TC39) 라는 위원회에 먼저 새로운 명세를 제안해야 한다. 그리고 위원회에서는 제안을 검토하고 합의하여 제안 프로세스 마지막 단계인 Stage 4를 통과해야만 비로소 ECMAScript 명세에 포함될 수 있다. 이 프로세스는 투명하게 운영되고 있으며, 각 단계별 제안에 대한 자세한 설명과 진행 상황은 GitHub 문서^[2]에서 확인할 수 있다.
그럼 이제 ES2024에 포함된 새로운 명세에 대한 기능과 변화에 대해 자세히 살펴보도록 하자.

올바른 형식의 유니코드 문자열

JavaScript에서 유니코드 문자열을 처리하는 방식을 개선하기 위해 String.prototype.isWellFormed^[3] 메서드와 String.prototype.toWellFormed^[4] 메서드가 추가되었다. isWellFormed 메서드는 유니코드 문자열이 쌍을 이루지 않은 단일 surrogate를 포함하는 경우 형식에 맞지 않으므로 false를 반환한다. 예를 들어 아래 [코드 예제1]처럼 encodeURL 인자로 단일 surrogate를 포함한 문자열을 전달하는 경우 URIError가 발생한다. 이러한 문제를 피하기 위해 toWellFormed 메서드를 통해 문자열이 올바른 형식을 갖도록 변환하여 사용할 수 있다.

그런데, 여기서 surrogate는 무엇일까? 유니코드는 다양한 언어와 기호 문자를 표현하는데, 유니코드에서 surrogate는 기본 다국어 평면(Basic Multilingual Plan, BMP)에 속하지 않는 문자를 나타내기 위해 사용하는 코드 포인트이다. Surrogate는 항상 leading surrogate과 trailing surrogate로 쌍을 이루어져야 하는데, 쌍을 이루지 않는 경우에는 올바른 문자를 표현할 수 없어 문제가 될 수 있다. [코드 예제2]를 보면 단일 surrogate가 있는 경우 toWellFormed 메서드 호출 결과 단일 surrogate를 U+FFFD(REPLACEMENT CHARACTER) 로 대체하여 � 표시되는 것을 확인할 수 있다.

정규 표현식의 v 플래그

ES2024부터 정규식 뒤에 u 플래그(unicode 모드)의 업그레이드 버전으로 v 플래그(unicodeSets^[5] 모드)를 붙일 수 있게 됐다. v 플래그와 함께 숫자, 알파벳과 같은 특정 집합에 포함된 문자를 찾기 위한 문자 클래스^[6]에 대해 집합 연산을 지원하는 기능이 추가되었다. [코드 예제3] 집합 연산에서 A와 B에는 문자 클래스(예, [a-z]) 또는 유니코드 속성 집합에 포함된 문자 (예, \p{Emoji}) 또는 임의의 문자열이 올 수 있다.

[코드 예제4] 처럼 v 플래그와 함께 한글에서 공백 문자를 제외한 문자열을 찾고자 할 때 이전 보다 직관적이고 간단하게 정규식 패턴을 만들 수 있다. 개발에 도움이 될만한 다양한 사례를 알고 싶다면, v8 JavaScript Engine 문서^[7]에서 확인할 수 있다.

또한, u 플래그 보다 개선된 2가지 기능에 대해 알아보자. 먼저 v 플래그가 도입되면서 여러 유니코드 관련 속성(Basic_Emoji, Emoji_Keycap_Sequence, RGI_Emoji 등)을 사용할 수 있게 되었다.  [코드 예제5]를 보면 u 플래그는 여러 코드 포인트로 구성된 emoji를 매칭 할 수 없었는데, v 플래그와 RGI_Emoji 속성을 같이 사용하면 올바르게 매칭 할 수 있게 된다.

또한, u 플래그는 case-insensitive 매칭이 항상 올바르게 동작하지 않은 문제가 있었는데, v 플래그에서 개선하였다. 아래 [코드 예제6]를 보면 정규식 `re1`과 `re2` 는 둘 다 모든 소문자를 `X`로 치환하는데, i 플래그 (ignoreCase 모드)와 함께 사용하고 있으므로 결국 모든 대소문자를 `X`로 치환해야 한다. 즉, 정규식 `re1`과 `re2`의 동작은 같은 의미를 갖고 있는데 u 플래그일때는 올바르지 않게 동작하고 있는 것을 확인할 수 있다. 하지만 [코드 예제7]에서 v 플래그에서는 이러한 문제를 개선하여 올바른 결과를 보여주고 있다.

Object.groupBy 와 Map.groupBy 메서드

데이터를 그룹화하는데 유용한 Object.groupBy^[8], Map.groupBy^[9] 정적 메서드가 추가 되었다. 두 메소드는 특정 속성을 기준으로 배열, 객체, 맵에 담긴 데이터를 그룹별로 분할하여 별도로 데이터를 처리하거나 reduce를 이어 사용하여 연산을 연속적으로 수행할 수 있다.

참고로 이번에 추가된 메서드는 원래 Array 프로토타입 메서드로 있었으나, 웹 호환성 이슈로 인해 정적 메서드로 이름을 변경하였다.

Promise.withResolvers 메서드

Promise.withResolvers^[10] 정적 메서드는 새로운 Promise 객체와 이를 resolve, reject 하는 함수를 반환한다. [코드 예제9]는 메서드 문법에 대한 설명이다. 메서드의 반환된 resolve, reject는 기존 Promise 생성자의 매개변수인 `executor` 함수 안에서 전달된 resolve, reject와 일치한다.

[코드 예제9]에서 알 수 있듯이 해당 메서드는 개발자들이 자주 사용하는 코드 패턴의 대안으로 제안되었다. 가장 큰 개선점은 Promise.withResolvers는 resolve, reject가 Promise 객체와 동일한 scope에 위치하여 `executor` 안에서 발생하는 중첩을 줄이므로 훨씬 간결하게 코드를 작성할 수 있게 한다.

Atomics.waitAsync 메서드

Atomics 객체^[11]는 아토믹 연산을 지원하기 위한 정적 메서드를 제공하며, SharedArrayBuffer^[12], ArrayBuffer^[13] 객체와 함께 사용한다. 최근 추가된 Atomics.waitAsync^[14] 정적 메서드는 Int32Array, BigInt64Array의 지정된 index 위치에 있는 값이 예상 value와 동일한지 비동기적으로 대기하고 Promise를 반환한다. 이 메서드는 Atomics.wait^[15] 정적 메서드와 비슷한 기능을 제공하지만, 논블럭킹이므로 메인스레드에서도 사용할 수 있다. 아래 [코드 예제10]는 이를 간단하게 보여준다.

크기 조절 가능한 ArrayBuffer

ES2024에서 ArrayBuffer 객체에 대해 크기 조절 기능과 전송 기능이 추가되었다. resize^[16] 메서드를 통해 ArrayBuffer 크기를 조절할 수 있다. 특히 새로운 크기의 버퍼를 사용하기 위해, 이전처럼 메모리 할당 및 복사하는 비효율적인 작업을 줄여줄 것으로 보인다. 그리고 WebAssembly 메모리 크기가 증가할 수 있는 상황에 맞춰 JavaScript 에서도 크기를 조절할 수 있는 기능은 유용할 것이다. 하지만 브라우저에서 ArrayBuffer의 크기를 동적으로 조절하는 것은 보안적인 측면에서 주의가 필요해 보인다. 만약 잘못 사용한다면 메모리 부족 문제나 민감한 데이터에 접근할 수 있는 보안 취약점을 초래할 수 있기 때문이다.

두 번째 기능으로 transfer^[17] 메서드를 통해 ArrayBuffer 객체는 Web Worker, Service Worker 와 같이 다른 실행 문맥 간에 전송될 수 있다. 이때 원본 ArrayBuffer와 동일한 바이트 내용을 가진 새로운 ArrayBuffer 생성한 다음 원본 ArrayBuffer를 분리하고, 이렇게 ArrayBuffer가 전송되면 원본은 더 이상 사용할 수 없는 분리 상태가 된다.

마치며

2024년 4월 26일 기준으로 ES2024 공식 명세에 추가될 stage 4 명세에 대해 살펴보았다. 매년 활발하고 신뢰할 수 있는 ECMAScript 표준화 과정 덕분에 명세가 공식적으로 확정되기 이전에도 이미 사용 가능한 기능이 있다. 이러한 기능의 브라우저 및 Node.js 지원율은 “ECMAScript compatibility table” ^[18]을 참고하면 된다.

이 아티클을 작성하면서 ECMAScript 명세를 읽고 그 도입 배경 및 관련 지식을 이해하기 쉽지 않았다. 그러나 새로운 기능을 활용하면서 기술적으로 더 깊이 있는 이해를 위해 명세를 읽는 것이 중요하다는 것을 깨달았다. 이 글이 앞으로 JavaScript 프로그래밍을 더욱 편리하고 효율적으로 할 수 있도록 도움이 되길 바란다.