RoyJung _ dev blog

원문: https://blogs.igalia.com/compilers/2025/07/03/summary-of-the-may-2025-tc39-plenary/
소개
안녕하세요! 지난 몇 번의 회의와 마찬가지로, TC39 회의에서 일어나는 새로운 논의들과 우리의 기여 방식을 알려드릴 수 있어서 기쁩니다.
이번 회의는 특별히 더 의미가 깊습니다. Igalia가 갈리시아의 A Coruña 본사에서 직접 개최할 수 있었기 때문입니다. 우리 고향 도시에서 모든 훌륭한 대표단들을 맞이할 수 있어서 영광이었습니다. 참여해주신 모든 분들께 감사드리며, 다시 한 번 개최할 수 있기를 기대합니다!
함께 가장 흥미로운 업데이트들을 살펴보겠습니다.
전체 의제와 회의록은 GitHub에서도 읽을 수 있습니다.
진행 상황 보고: 4단계 제안
Array.fromAsync 4단계 진입
Array.from은 동기 이터러블을 배열로 변환하는 자주 사용되는 메서드입니다. 하지만 비동기 이터레이터에는 사용할 수 없었습니다. Array.fromAsync가 이 문제를 해결합니다. for await가 for의 비동기 버전인 것처럼, Array.fromAsync는 Array.from의 비동기 버전입니다. 이 제안은 이미 모든 자바스크립트 엔진에 배포된 지 1년 이상 지났고(Baseline 2024), 개발자들이 많이 요청한 기능입니다.
하지만 공식 절차상 이 제안은 실제로 3단계가 아니었습니다. 2022년 9월에 세 명의 ECMAScript 명세 편집자 모두의 서명을 조건으로 3단계로 진입했습니다. 편집자들은 실제 변경사항을 담은 풀 리퀘스트를 요청했지만, 이는 최근까지 열리지 않았습니다. 이번 회의에서 편집자들의 실제 검토를 조건으로 4단계로 진입했습니다.
발표자: J. S. Choi
명시적 리소스 관리 4단계 진입
명시적 리소스 관리 제안은 렉시컬 스코프를 기반으로 객체의 암묵적 클린업 콜백을 도입합니다. 이는 새로운 using x =  선언을 통해 구현됩니다.
이 제안은 이미 Chrome, Node.js, Deno에서 제공되고 있으며, Firefox에서는 실험적 기능으로 설정되어 있습니다. 이에 따라 Ron Buckton은 회의 중 4단계 승인에 대한 합의를 요청했고, 승인받았습니다!
단, Array.fromAsync와 마찬가지로 아직 완전한 4단계는 아닙니다. ECMAScript 표준에 포함되기 전에 아직 해결해야 할 사항들이 남아 있기 때문입니다. test262 테스트를 병합해야 하고, ECMAScript 명세 편집자가 제안된 명세서를 승인해야 합니다.
발표자: Ron Buckton
Error.isError 4단계 진입
Error.isError(objectToCheck) 메서드는 주어진 값이 실제 Error 인스턴스인지 확인할 수 있는 신뢰할 만한 방법을 제공합니다. 이 제안은 원래 2015년에 Jordan Harband가 제시했습니다. 자바스크립트에서는 숫자나 불린을 포함한 모든 것을 throw할 수 있기 때문에, 주어진 값이 실제로 오류 객체인지 감지하기 어렵다는 문제를 해결하기 위한 것이었습니다. 이번 회의에서 마침내 ECMAScript 표준의 일부가 되었습니다.
발표자: Jordan Harband
Intl.Locale#variants 추가
Intl.Locale 객체는 유니코드 로케일 식별자를 나타냅니다. 이는 언어, 스크립트, 지역, 정렬 방식, 달력 유형 등의 선호도를 조합한 것입니다.
예를 들어, de-DE-1901-u-co-phonebk는 “1901년 전통 독일어 철자법과 전화번호부 정렬을 사용하는 독일의 독일어”를 의미합니다. 로케일 식별자는 language를 기본으로 하며, 선택적으로 다음 요소들이 추가됩니다.
script (즉, 알파벳)
region
하나 이상의 variants (예: “1901년의 전통적인 독일어 철자법”)
추가 수정자 목록 (예: 정렬)
Intl.Locale 객체는 이미 여러 속성을 쿼리할 수 있었지만, variants에 대한 것이 누락되어 있었습니다. 위원회는 이를 동일한 방식으로 노출하는 것에 합의했습니다.
발표자: Richard Gibson
진행 상황 보고: 3단계 제안
Intl.Locale Info 3단계 업데이트
Intl.Locale Info 3단계 제안은 개별 로케일에 특화된 메타데이터를 쿼리할 수 있게 합니다. 예를 들어, “ms-BN 로케일에서 어떤 날들이 주말인가?”라는 질문에 답할 수 있습니다.
위원회는 텍스트 방향 정보에 대한 변경에 합의했습니다. 일부 로케일은 왼쪽에서 오른쪽, 다른 로케일은 오른쪽에서 왼쪽으로 텍스트를 작성하며, 일부는 방향을 알 수 없습니다. 이제 방향을 알 수 없는 경우 기본값 대신 undefined를 반환합니다.
발표자: Shane F. Carr
Temporal 상태 업데이트
Philip Chimento는 자바스크립트의 날짜/시간 지원을 위한 Temporal 제안에 대한 상태 업데이트를 발표했습니다. 가장 큰 소식은 Temporal이 최신 Firefox에서 사용 가능하다는 것입니다! Ladybird, Graal, Boa 자바스크립트 엔진 모두 거의 완전한 구현을 가지고 있습니다. 위원회는 UTC 오프셋의 초(:00) 구성 요소 해석에 대한 사소한 변경에 동의했습니다. (UTC 오프셋을 단 20초만큼 이동한 시간대가 있었다는 것을 알고 계셨나요?)
발표자: Philip Chimento
불변 ArrayBuffer 업데이트
불변 ArrayBuffer 제안은 읽기 전용 데이터에서 ArrayBuffer를 생성할 수 있게 합니다. 일부 경우에는 제로 카피 최적화도 가능합니다. 제안자들은 이번 총회를 위해 테스트를 준비하고 3단계를 요청하려 했지만 시간 내에 완료하지 못했습니다. 대신 매우 견고한 테스트 계획을 수립했습니다. 이를 통해 이 제안을 “지금까지 본 표준 라이브러리에서 가장 잘 테스트된 부분”으로 만들 계획입니다. 모든 테스트가 작성되면 3단계 진입을 요청할 예정입니다.
발표자: Peter Hoddie, Richard Gibson
진행 상황 보고: 2.7단계 제안
Iterator Sequencing 업데이트
Iterator Sequencing 2.7단계 제안은 이터레이터 목록을 받아서 모든 요소를 생성하는 이터레이터를 반환하는 Iterator.concat 메서드를 도입합니다. 이는 Array.prototype.concat의 이터레이터 버전이지만 정적 메서드입니다.
Michael Ficarra는 원래 3단계로 진입을 요청할 계획이었습니다. test262 테스트 등 서류상 준비를 마친 상태였기 때문입니다.
하지만 위원회가 “이터레이터 결과” 객체 재사용에 대한 변경사항을 논의했기 때문에 불가능했습니다. Iterator.concat(x).next()가 x.next()와 동일한 객체를 반환해야 하는가, 아니면 새로 생성해야 하는가에 대한 문제였습니다.
발표자: Michael Ficarra
진행 상황 보고: 2단계 제안
Iterator Chunking 업데이트
Iterator Chunking 2단계 제안은 두 개의 새로운 Iterator.prototype.* 메서드를 도입합니다. chunks(size)는 이터레이터를 겹치지 않는 청크로 분할하고, windows(size)는 1개 요소씩 오프셋된 겹치는 청크를 생성합니다.
제안자는 2.7단계를 요청할 계획이었지만, 위원회가 .windows 동작 변경을 요청함에 따라 불가능했습니다. n개 미만의 요소를 가진 이터레이터에서 크기 n의 윈도우를 요청할 때 어떻게 해야 하는가에 대한 문제였습니다. 여러 옵션을 고려했습니다.
크기 n의 윈도우를 생성할 수 없으므로 배열을 생성하지 않음
예상 길이에 맞추기 위해 끝에 일부 패딩(undefined?)이 있는 배열을 생성
n개 미만의 요소가 있는 배열을 생성
위원회는 (1)과 (3) 모두 유효한 사용 사례가 있다고 결론지었습니다. 이에 따라 제안은 .windows()를 두 개의 별도 메서드로 분할하도록 업데이트할 예정입니다.
발표자: Michael Ficarra
AsyncContext 웹 통합 브레인스토밍
AsyncContext는 제어의 비동기 흐름에서 상태를 유지할 수 있게 하는 제안입니다. 자바스크립트의 비동기성에 대한 쓰레드-로컬 스토리지 같은 개념입니다. 제안자들은 비동기 흐름이 await뿐만 아니라 setTimeout과 이벤트를 발생시키는 API(예: xhr.send())를 통해서도 흐른다고 믿습니다. 하지만 이 제안은 브라우저 엔지니어들의 구현 복잡성 우려로 인해 지연되고 있습니다.
이번 TC39 세션에서 우리는 웹 API와의 일부 통합 지점을 제거하는 것에 대해 브레인스토밍했습니다. 특히, 비동기적으로 발생한 이벤트를 통한 컨텍스트 전파에 대해 논의했습니다. 이는 웹 프레임워크에는 잘 작동하지만, ‘AsyncContext’의 다른 주요 사용례인 추적 도구에는 작동하지 않습니다. 컨텍스트가 이벤트를 통해 암시적으로 전파되지 않는다면, 개발자들이 불필요할 때도 컨텍스트를 스냅샷해야 할 수도 있으며, 이는 메모리 누수로 이어질 수 있습니다. 일반적으로, 참석자들은 컨텍스트가 이벤트를 통해 전파되어야 한다고 동의했습니다. 최소한 구현이 가능한 경우에는 말입니다.
이번 TC39 논의는 제안을 크게 진행시키지 못했고, 우리도 그럴 것으로 기대하지 않았습니다. TC39의 브라우저 대표들은 대부분 핵심 자바스크립트 엔진(SpiderMonkey나 V8과 같은)을 다루는 엔지니어들이고, 이 우려는 웹 API를 다루는 엔지니어들로부터 나왔기 때문입니다. 하지만 이번 TC39 총회 이후 주에, Igalia는 A Coruña에서 Web Engines Hackfest를 조직했고, 거기서 관련된 사람들과 이 대화를 재개할 수 있었습니다. 결과적으로, 우리는 이벤트를 통해 컨텍스트를 전파하는 제안에 대한 가능한 전진 경로에 대해 Mozilla 엔지니어들과 긍정적인 논의를 가졌고, 전파가 더 복잡할 것으로 예상되는 일부 특정 API의 복잡성을 더 자세히 분석했습니다.
발표자: Andreu Botella
Math.clamp 2단계 진입
Math.clamp 제안은 범위의 두 끝점 사이에서 숫자 값을 클램핑하는 메서드를 추가합니다. 이 제안은 지난 2월에 1단계에 도달했고, 이번 총회에서 일부 해결되지 않은 이슈들을 논의하고 해결했습니다.
첫 번째는 정적 메서드 Math.clamp(min, value, max)로 할지, Number.prototype의 메서드로 만들어 value.clamp(min, max)처럼 사용할지에 대한 논의였습니다. 정적 메서드는 인수 순서가 명확하지 않을 수 있어 후자를 선택했습니다.
두 번째는 BigInt도 지원해야 하는지에 대한 논의였습니다. clamp를 Number의 메서드로 만들기로 했으므로 자바스크립트 숫자 타입만 지원하기로 결정했습니다. 후속 제안에서 BigInt.prototype에도 추가할 수 있습니다.
마지막으로 min이 max보다 크거나 같을 때 예외를 던져야 하는지, 특히 양의 0과 음의 0을 어떻게 처리할지 논의했습니다. 위원회는 이를 2단계에서 결정하기로 합의했습니다.
이와 함께, Math.clamp(또는 오히려 Number.prototype.clamp) 제안이 2단계로 진입했습니다. 제안자는 원래 2.7단계에 도달하기를 희망했지만, 제안된 명세서에 대한 계획된 변경사항이 보류되어 있어서 결국 제안하지 않았습니다.
발표자: Oliver Medhurst
시드 PRNG 2단계 진입
현재 자바스크립트의 (의사)난수 생성 기능은 _시드(seed)_를 받지 않습니다. 시드는 난수 생성의 시작점을 고정하는 데이터로, Math.random을 반복 호출할 때 항상 같은 값 시퀀스를 생성하도록 보장합니다. 이는 테스트 등 다양한 상황에서 유용합니다. 예를 들어, Math.random을 호출하는 함수를 테스트할 때 결과를 예측할 수 없다면 어떻게 테스트할 수 있을까요? 이 제안은 난수 생성에 시드를 사용할 수 있는 새로운 최상위 객체 Random을 추가합니다. 제안은 호평을 받아 2단계로 진입했습니다.
발표자: Tab Atkins-Bittner
진행 상황 보고: 1단계 제안
더 많은 랜덤 함수들 1단계 진입
시드 PRNG 제안을 발표한 Tab Atkins-Bittner는 “더 많은 랜덤 함수들”로 비슷한 맥락을 이어갔습니다. 아이디어는 배열을 섞기, 구간에서 난수 생성하기, 랜덤 불린 생성하기 등 자주 사용되는 함수들의 집합을 정하는 것입니다. 여기서 상상할 수 있는 재미있는 아이디어들이 많이 있고, 위원회는 추가 탐색을 위해 이 제안을 1단계로 진입시키는 것에 기뻐했습니다.
발표자: Tab Atkins-Bittner
Intl.NumberFormat과 Intl.PluralRules에서 후행 0 유지 1단계 진입
Mozilla의 Eemeli Aro는 자바스크립트의 국제화 API의 두 부분에 대한 깔끔한 버그 수정을 제안했습니다. 현재 "123.456"과 같은 숫자 문자열이 Intl.PluralRules와 Intl.NumberFormat API에 주어지면, 문자열이 Number로 변환됩니다. 이는 일반적으로 괜찮지만, "123.4560"과 같이 후행 0을 포함하는 숫자 문자열은 어떨까요? 현재로서는 그 후행 0이 제거되고 복구할 수 없습니다. Eemeli는 그러한 숫자들을 유지하자고 제안합니다. 이는 "1.0 stars"와 같이 숫자 포맷팅 및 단어의 복수화에서 차이를 만듭니다. 이 제안은 1단계로 진입했으며, NumberFormat과 PluralRules API의 일부 기존 옵션들이 그러한 문자열을 처리할 때 어떻게 이해되어야 하는지 명확히 하기 위해 일부 작업이 필요합니다.
발표자: Eemeli Aro
Decimal 1단계 업데이트
우리는 Decimal 제안과 Intl과의 잠재적 통합에 대한 최신 개발 사항을 공유했으며, amounts 개념에 초점을 맞췄습니다. 이는 소수점 숫자를 정수 “정밀도”와 쌍을 이루도록 설계된 경량 래퍼 클래스로, 컨텍스트에 따라 유효 숫자 수 또는 소수점 이하 숫자 수를 나타냅니다. 이 논의는 Intl.NumberFormat과 Intl.PluralRules에서 후행 0을 유지하는 것에 대한 이전 논의의 자연스러운 후속이었습니다. decimal에 대한 논의에서, 우리는 amounts의 문자열 기반 버전이라는 아이디어를 제기했지만, 이는 새로운 진행 중인 아이디어였습니다. 위원회는 기본 decimal 제안에 대해 일반적으로 만족하는 것 같지만, amount 개념의 필요성에 대해 아직 확신하지 못하는 것 같습니다. Decimal은 1단계에 머물러 있습니다.
발표자: Jesse Alama
Comparisons 1단계 진입
오늘날 많은 자바스크립트 환경에서 일종의 assertion 함수를 제공합니다. (예: console.assert, Node.js의 node:assert 모듈, NPM의 chai 패키지.) 위원회는 Jacob Smith가 제시한 새로운 제안인 Comparisons를 논의했으며, 이는 이러한 종류의 기능이 ECMAScript 표준의 일부여야 하는지 탐구합니다. 이 제안은 1단계에 도달했으므로, 조사와 범위 설정이 계속될 예정입니다. 풍부한 동등성 비교를 다뤄야 하는가, 테스트 스위트 통합이 있어야 하는가, 별도의 디버그 및 프로덕션 모드가 있어야 하는가? 이러한 질문들은 향후 회의에서 탐구될 예정입니다.
발표자: Jacob Smith
ECMAScript를 위한 IDL
HTML, DOM, 기타 웹 플랫폼 기능의 명세를 보면, 그 안에 Web IDL 스니펫을 놓칠 수 없습니다. 이 IDL은 웹 브라우저 자바스크립트 환경에서 사용 가능한 모든 인터페이스와 각 함수 인수가 어떻게 처리되고 검증되는지를 설명하는 데 사용됩니다.
IDL은 명세에만 적용되는 것이 아닙니다! IDL 코드는 또한 웹 브라우저의 코드베이스에 직접 복사되며, 때로는 약간의 수정과 함께 C++ 코드를 생성하는 데 사용됩니다.
Mozilla의 Tooru Fujisawa (Arai)는 오랜 공백 후에 이 제안을 위원회에 다시 가져왔습니다. 그는 ECMAScript 명세에서도 점진적으로 같은 방식을 적용할 수 있는 비전을 제시했습니다. 이는 웹 브라우저뿐만 아니라 모든 자바스크립트 엔진의 유지 관리 비용을 낮출 수 있습니다. 하지만 함수 인수를 처리하는 방식이 웹 플랫폼 API와 ECMAScript 명세 사이에 상당히 다르기 때문에, 동일한 Web IDL을 그대로 사용하는 것은 불가능합니다.
Tooru는 이 문제를 해결하기 위한 몇 가지 방법을 제시했습니다. 기존 Web IDL에 새로운 주석을 추가하거나, ECMAScript 스타일의 작업을 지원하는 새로운 구문을 정의하는 방법입니다.
발표자: Tooru Fujisawa
커뮤니티 이벤트
목요일 회의 후에, 우리는 지역 기술 커뮤니티의 도움을 받아 커뮤니티 이벤트를 공동 조직했습니다. 통찰력 있고 독특한 발표들로 가득 찬 흥미로운 의제와 간식을 먹으며 이어지는 활발한 네트워킹 세션을 통해, 우리는 커뮤니티에서 흥미로운 대화를 시작하고 주변의 자바스크립트 개발자들이 이러한 주제에 대한 관심을 가지게 되었기를 희망합니다.
결론
2025년 5월 총회는 자바스크립트 언어와 국제화 기능 전반에 걸쳐 흥미로운 진전으로 가득했습니다. 특히 Igalia에게는 고향인 A Coruña에서 회의를 개최할 수 있어 특별한 순간이었습니다. Array.fromAsync, Error.isError, 명시적 리소스 관리와 같이 오랫동안 기다려온 제안들이 4단계에 도달했습니다. 다른 제안들도 사려 깊은 논의와 반복을 통해 계속 발전했습니다.
읽어주셔서 감사합니다. 작업이 진행됨에 따라 업데이트를 계속 공유할 것입니다. 다음 회의에서 만나뵙겠습니다!

2025년 5월 TC39 총회 요약 (번역)

댓글