원문: 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 = 선언을 통해 구현됩니다.

1
2
3
4
5

{
  using myFile = open(fileURL);
  const someBytes = myFile.read();
  // myFile은 블록의 끝에서 자동으로 닫히고, 관련 리소스가 해제됩니다.
}

이 제안은 이미 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개 요소씩 오프셋된 겹치는 청크를 생성합니다.

1
2

[1, 2, 3, 4].values().chunks(2);  // [1,2], [3,4]
[1, 2, 3, 4].values().windows(2); // [1,2], [2,3], [3,4]

제안자는 2.7단계를 요청할 계획이었지만, 위원회가 .windows 동작 변경을 요청함에 따라 불가능했습니다. n개 미만의 요소를 가진 이터레이터에서 크기 n의 윈도우를 요청할 때 어떻게 해야 하는가에 대한 문제였습니다. 여러 옵션을 고려했습니다.

1. 크기 n의 윈도우를 생성할 수 없으므로 배열을 생성하지 않음
2. 예상 길이에 맞추기 위해 끝에 일부 패딩(undefined?)이 있는 배열을 생성
3. 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단계에 도달했습니다. 다른 제안들도 사려 깊은 논의와 반복을 통해 계속 발전했습니다.

읽어주셔서 감사합니다. 작업이 진행됨에 따라 업데이트를 계속 공유할 것입니다. 다음 회의에서 만나뵙겠습니다!

원문: https://deno.com/blog/history-of-javascript

올해 자바스크립트가 30살이 되었습니다.

지난 30년 동안 자바스크립트는 단 10일 만에 만들어진 이상한 스크립트 언어에서 세계에서 가장 인기 있는 프로그래밍 언어로 성장했습니다. 자바스크립트가 어떻게 발전해왔고 앞으로 어떤 방향으로 나아갈지를 보여주는 역사적 순간들을 살펴보겠습니다.

1
2
3
4
5
6
7
8
9
10
11
12

var ExcelSheet;
ExcelSheet = new ActiveXObject("Excel.Sheet");
// Make Excel visible through the Application object.
ExcelSheet.Application.Visible = true;
// Place some text in the first cell of the sheet.
ExcelSheet.ActiveSheet.Cells(1,1).Value = "This is column A, row 1";
// Save the sheet.
ExcelSheet.SaveAs("C:TEST.XLS");
// Close Excel with the Quit method on the Application object.
ExcelSheet.Application.Quit();
// Release the object variable.
ExcelSheet = "";

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

// How to send an HTTP request in IE5.
// IE5에서 HTTP 요청을 보내는 방법.

<script type="text/javascript">
  function makeRequest() {
    // Create the ActiveXObject (specific to IE5/IE6)
    // ActiveXObject 생성 (IE5/IE6 전용)
    var xhr = new ActiveXObject("Microsoft.XMLHTTP");

    // Open a GET request (async = true)
    // GET 요청 열기 (비동기 = true)
    xhr.open("GET", "https://example.com/data.txt", true);

    // Define a callback to run when the response is ready
    // 응답이 준비되면 실행할 콜백 정의
    xhr.onreadystatechange = function() {
      if (xhr.readyState === 4 && xhr.status === 200) {
        alert("Response received: " + xhr.responseText);
      }
    };

    // Send the request
    // 요청 전송
    xhr.send();
  }
</script>

<button onclick="makeRequest()">Send HTTP Request</button>

1
2
3
4
5
6
7
8
9

/**
 * Adds two numbers together and returns the result.
 * * 두 숫자를 더하고 결과를 반환합니다.
 * @param {number} value1 The first value
 * @param {number} value2 The second value
 */
function addNumbers(value1, value2) {
  return value1 + value2;
}

1
2
3
4
5
6
7

<html><head><script>
  document.domain = 'fudco';
  parent.session.receive(
    { to: "session", do: "test",
      text: "Hello world" }
  )
</script></head></html>

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

<script type="text/javascript">
  function createXHR() {
    if (window.XMLHttpRequest) {
      // Modern browsers (Mozilla, Safari, IE7+)
      // 현대 브라우저 (Mozilla, Safari, IE7+)
      return new XMLHttpRequest();
    } else if (window.ActiveXObject) {
      // Older versions of IE (IE5, IE6)
      // 이전 버전의 IE (IE5, IE6)
      try {
        return new ActiveXObject("Msxml2.XMLHTTP");
      } catch (e) {
        try {
          return new ActiveXObject("Microsoft.XMLHTTP");
        } catch (e) {
          alert("AJAX not supported in your browser.");
          return null;
        }
      }
    }
    return null;
  }

  function loadData() {
    var xhr = createXHR();
    if (!xhr) return;

    xhr.onreadystatechange = function() {
      if (xhr.readyState === 4) {
        if (xhr.status === 200) {
          document.getElementById("result").innerHTML = xhr.responseText;
        } else {
          alert("Request failed: " + xhr.status);
        }
      }
    };

    xhr.open("GET", "/messages/latest", true); // Simulated Gmail-style endpoint
                                               // Gmail 스타일 엔드포인트 시뮬레이션
    xhr.send(null);
  }
</script>

<button onclick="loadData()">Load Latest Message</button>
<div id="result">Waiting for response...</div>

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

<script src="https://code.jquery.com/jquery-1.0.0.min.js"></script>
<script type="text/javascript">
  function sendRequest() {
    $.ajax({
      url: "https://example.com/data",
      type: 'GET',
      success: function(res) {
        document.getElementById("result").innerHTML = res;
      },
      error: function(xhr, status, error) {
        alert("Request failed: " + status);
      }
    });
  }
</script>

<button onclick="sendRequest()">Fetch data</button>
<div id="result">Waiting for response...</div>

1
2
3

function add(x: number, y: number): number {
  return x + y;
}

1
2
3
4
5
6
7
8
9
10
11
12
13

(function Module(stdlib, foreign, heap) {
  "use asm";

  function add(x, y) {
    x = x | 0;
    y = y | 0;
    return (x + y) | 0;
  }

  return { add: add };
})(this, {}, new ArrayBuffer(1024));

console.log(Module.add(10, 20)); // Outputs: 30

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

<script type="text/javascript">
  function getData() {
    fetch("https://api.example.com/data")
    .then(response => {
      if (!response.ok) {
        throw new Error("Network response was not ok: " + response.status);
      }
      return response.text(); // or response.json() for JSON APIs
                              // JSON API의 경우 response.json() 사용
    })
    .then(data => {
      document.getElementById("result").textContent = data;
    })
    .catch(error => {
      console.error("Fetch error:", error);
      alert("Error fetching data.");
    });
  }
}

<button onclick="getData()">Fetch data</button>
<div id="result">Waiting for response...</div>

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

<script>
  async function getData() {
    try {
      const response = await fetch("https://api.example.com/data");

      if (!response.ok) {
        throw new Error("HTTP error " + response.status);
      }

      const data = await response.text(); // or response.json() for JSON
                                          // JSON의 경우 response.json() 사용
      document.getElementById("result").textContent = data;
    } catch (error) {
      console.error("Fetch failed:", error);
      alert("Something went wrong!");
    }
  }
</script>

<button onclick="getData()">Load Data</button>
<pre id="result">Waiting for response...</pre>

자바스크립트는 지난 30년 동안 놀라운 발전을 이뤄왔습니다. 단순한 스크립팅 언어로 시작했지만, 이제는 동적 프론트엔드부터 풀스택 애플리케이션, 네이티브 앱, 심지어 AI 도구까지 모든 것을 구동하는 현대 웹 개발의 핵심이 되었습니다. 이러한 진화는 오픈소스 정신, 열정적인 커뮤니티, 지속적으로 성장하는 생태계, 그리고 끊임없는 혁신 덕분에 가능했습니다. 자바스크립트의 30년을 축하하는 동시에, 앞으로의 발전 방향에 대해서도 큰 기대를 갖게 됩니다. 더 빠른 런타임, 더 똑똑한 도구, 그리고 지금보다 훨씬 더 접근하기 쉽고 강력하며 창의적인 웹을 향한 여정 말입니다. 경계를 넘나드는 다음 30년을 기대해봅시다!

이터레이터 헬퍼?

이터레이터 헬퍼(Iterator Helper)는 ECMAScript 2025(ES2025)에 새롭게 추가될 기능으로, 이터레이터를 더욱 편리하게 사용할 수 있도록 돕는 다양한 인터페이스의 집합입니다.

ES2015에서 이터레이터 프로토콜이 도입된 이후, 필요한 기능을 직접 구현하거나 배열로 변환하여 배열 메서드를 사용하는 방법 외에는 이터레이터를 폭넓게 활용하기가 어려웠습니다. 하지만 필요한 기능을 직접 구현하면 오류 발생 확률이 높을 뿐 아니라 제한된 기능만 활용하게 되기 쉽고, 배열로 변환하면 지연 평가라는 이터레이터의 장점을 잃고 불필요한 메모리를 낭비하게 되어 비효율적입니다.

이제 이터레이터 헬퍼 메서드를 체이닝하여 이터레이터의 지연 평가 기능을 적극 활용하면, 코드 가독성을 높이고 순회 횟수를 줄임으로써 성능을 크게 개선할 수 있게 되었습니다.

이 글에서는 지연 평가를 위한 이터레이터 메서드 체이닝의 동작 원리를 알아보고, 이터레이터 헬퍼 메서드의 종류 및 성능상 이점을 테스트해 본 다음, 실무에서 데이터 타입 별로 기존 코드를 이터레이터 헬퍼로 대체하기 위한 다양한 기법 및 유의사항을 살펴보겠습니다.

지연 평가?

이터레이터의 next 메서드는 { value: 반환값, done: boolean } 객체를 반환합니다. for ... of 문법은 내부적으로 next 메서드를 done이 true가 될 때까지 반복 호출합니다. 단순한 순회 명령만 보면 배열의 메서드와 큰 차이가 없어 보일 수 있습니다.

그러나 배열 메서드는 한 번에 모든 순회 대상을 메모리에 적재한 뒤 처리하는 반면, 이터레이터는 next()를 호출하기 전까지 아무 작업도 하지 않고 대기합니다. next()가 호출되는 시점에 비로소 순회 대상의 ‘다음’ 요소를 평가합니다. 이를 지연 평가(Lazy Evaluation)라고 합니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

// 1. 배열
const arr = Array.from({ length: 5 }, (_, i) => i + 1)
const arrSum = arr.reduce((a, c) => a + c, 0)
console.log(arrSum) // 15

// 2. 이터레이터
function* generator() {
  let i = 0
  while (i < 5) yield ++i
}
let iterSum = 0
for (const v of generator()) {
  iterSum += v
}
console.log(iterSum) // 15

결과만 보면 배열과 이터레이터 사이에 차이가 없는 것처럼 보입니다. 하지만 동작 방식에는 큰 차이가 있습니다. 코드 곳곳에 로그를 추가해 확인해 보겠습니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

console.group('array')
const arr = Array.from({ length: 5 }, (_, i) => {
  console.log('generate', i)
  return i + 1
})
const arrSum = arr.reduce((a, c) => {
  console.log('reduce', c)
  return a + c
}, 0)
console.groupEnd('array')

console.group('iterator')
function* generator() {
  let i = 0
  while (i < 5) {
    console.log('generate', i)
    yield ++i
  }
}
let iterSum = 0
for (const v of generator()) {
  console.log('reduce', v)
  iterSum += v
}
console.groupEnd('iterator')

위 코드를 실행하면 개발자 도구 콘솔에 다음과 같은 내용이 출력됩니다.

배열 결과		이터레이터 결과

배열 코드에서는 generate가 5번 출력된 후 reduce가 5번 출력되었습니다. 반면, 이터레이터 코드에서는 generate와 reduce가 번갈아 출력되었습니다. 즉, 배열은 모든 요소를 생성한 뒤 연산을 수행했지만, 이터레이터는 값을 하나 생성하고 바로 연산을 수행한 뒤 다시 값을 생성하는 방식으로 진행되었습니다.

for ... of 문법은 내부적으로 next 메서드를 호출하여 done이 true가 될 때까지 반복합니다. next가 호출되면 제너레이터 함수의 실행이 시작되고, yield를 만나면 멈춥니다. 이후 다시 next가 호출되면 멈췄던 자리에서 실행을 재개합니다. 이처럼 for ... of는 필요한 순간까지 기다렸다가(지연) 평가를 수행합니다.

이터레이터 메서드 체이닝

좀 더 복잡한 연산 과정을 살펴보겠습니다. 다음은 배열의 filter와 map 메서드를 체이닝한 코드입니다.

1
2
3
4
5
6
7
8
9
10
11

const arr = Array.from({ length: 5 }, (_, i) => i + 1)
const arrResult = arr
  .filter(v => {
    console.log('filter', v)
    return v % 2 === 0
  })
  .map(v => {
    console.log('map', v)
    return v ** 2
  })
console.log(arrResult)

위 코드를 실행하면 개발자 도구 콘솔에 다음과 같은 내용이 출력됩니다.

배열 메서드 체이닝

filter 메서드는 배열의 모든 요소를 순회하고, map 메서드는 필터링 된 결과 배열을 다시 순회합니다. 따라서 전체 순회 횟수는 filter에서 한 번, map에서 한 번으로 총 두 번입니다. 이를 한 번의 순회로 처리하려면 어떻게 해야 할까요? 일단 메서드 체이닝으로 분리된 내용을 for ... of 내부로 옮겨봅시다.

1
2
3
4
5
6
7
8
9
10
11
12
13

function* generator() {
  let i = 0
  while (i < 5) yield ++i
}
const iterResult = []
for (const v of generator()) {
  console.log('filter', v)
  if (v % 2 !== 0) continue

  console.log('map', v)
  iterResult.push(v ** 2)
}
console.log(iterResult)

유사 지연 평가

위 코드는 한 번의 순회로 원하는 결과를 얻을 수 있었습니다. 실제 지연 평가도 위 코드에서 여러 명령을 순차적으로 수행한 것과 비슷하게 진행됩니다. 여러 메서드를 체이닝했을 때, 이터레이터의 각 항목에 대해 연결된 메서드를 순차적으로 실행하고, 모든 메서드 실행이 종료되면 비로소 다음 항목으로 넘어가 동일한 순서를 반복합니다.

다음은 직접 만든 지연 평가 메서드의 예시 코드입니다.

※ 주의 ※
다음 예제 코드는 Iterator.prototype에 직접 메서드를 추가합니다. 이는 전역 객체를 수정하여 다른 라이브러리와 충돌하거나 예기치 않은 동작을 유발할 수 있습니다. 따라서 실제 프로젝트에서는 Iterator.prototype을 직접 확장하지 않는 것을 권장합니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

Iterator.prototype._filter = function* (fn) {
  console.log(this, iter)
  console.log('_filter iteration')
  for (const item of this) {
    console.log('_filter', item)
    if (fn(item)) yield item
  }
}
Iterator.prototype._map = function* (fn) {
  console.log(this)
  console.log('_map iteration')
  for (const item of this) {
    console.log('_map', item)
    yield fn(item)
  }
}

const arr = [1, 2, 3, 4, 5]
const iter = arr
  .values()
  ._filter(v => {
    console.log('_filterFn', v)
    return v % 2 === 0
  })
  ._map(v => {
    console.log('_mapFn', v)
    return v ** 2
  })
console.log(iter)
// Iterator._map {<suspended>}

_filter와 _map은 제너레이터 메서드입니다. 변수 iter는 제너레이터를 실행한 결과물인 이터레이터에 불과하며, 아직 평가가 이루어지지 않은 상태입니다. 따라서 마지막 줄에서 중단된 상태의 이터레이터(Iterator._map {<suspended>})가 출력됩니다.

이제 iter.next()를 호출하면 다음과 같은 순서로 코드가 진행됩니다.

1. ^L25)Iterator._map 이터레이터에 대해 첫 번째 평가가 이루어집니다. 이제부터 Iterator._map은 <running> 상태가 됩니다. 이터레이터 내부에서 yield를 만날 때까지 코드를 진행합니다.
2. ^L9)_map 내부에서 this는 메서드 체이닝 상 Iterator._filter입니다. ^L12)for (const item of this)에서 this가 이터레이터이므로 해당 이터레이터(^L21)_filter(...))를 먼저 평가합니다. _filter에서 yield를 만나면 _filter를 빠져나오면서 이 값을 item에 할당하고, ^L12)for ... of 내부 코드를 진행합니다.
3. ^L1)_filter 내부에서 this는 메서드 체이닝 상 Array Iterator입니다. ^L4)for (const item of this)에서 this가 이터레이터이므로 해당 이터레이터(^L20)values())를 먼저 평가합니다. values에서 yield를 만나면 values를 빠져나오면서 이 값을 item에 할당하고, ^L4)for ... of 내부 코드를 진행합니다.
4. ^L20)values는 첫 번째 이터레이션에서 { value: 1, done: false }를 yield 합니다.
5. ^L1)_filter의 ^L4)for ... of문에서 item에는 위 4번에서 yield한 객체의 value 값, 즉 1이 할당됩니다. ^L6)fn(1)의 실행 결과 1 % 2 !== 0으로 false가 되므로, 조건문을 충족하지 않아 yield하지 않고, 다음 이터레이션으로 넘어갑니다.
6. 다시 ^L20)values()에 대한 평가를 합니다. values는 두 번째 이터레이션에서 { value: 2, done: false }를 yield 합니다.
7. ^L1)_filter의 ^L4)for ... of문에서 item에는 위 2가 할당됩니다. ^L6)fn(2)의 실행 결과 2 % 2 === 0으로 true가 되므로, 조건문을 충족하여 2를 yield 합니다.
8. ^L9)_map의 ^L12)for ... of문에서 item에는 위 7번에서 yield한 객체의 value 값, 즉 2가 할당됩니다. ^L14)fn(2)의 실행 결과 2 ** 2 = 4로 4가 반환되어, { value: 4, done: false }를 yield 합니다. 이로써 Iterator._map에 대한 next() 호출의 결과를 반환하였으므로, 이터레이션을 멈추고 다시 <suspended> 상태로 돌아갑니다.

같은 방식으로 iter.next()를 반복하여 실행한 결과는 다음과 같습니다.

/* L숫자) : 위 코드 블락의 줄 번호를 의미합니다. */
iter.next()
// L10) Iterator._filter {<suspended>}
// L11) _map iteration
// L02) Array Iterator {}, Iterator._map {<running>}
// L03) _filter iteration
// L05) _filter 1
// L22) _filterFn 1
// L05) _filter 2
// L22) _filterFn 2
// L13) _map 2
// L26) _mapFn 2
// 결과) {value: 4, done: false}

console.log(iter)
// Iterator._map {<suspended>}

iter.next()
// L05) _filter 3
// L22) _filterFn 3
// L05) _filter 4
// L22) _filterFn 4
// L13) _map 4
// L26) _mapFn 4
// 결과) {value: 16, done: false}

console.log(iter)
// Iterator._map {<suspended>}

iter.next()
// L05) _filter 5
// L22) _filterFn 5
// 결과) {value: undefined, done: true}

console.log(iter)
// Iterator._map {<closed>}

for ... of는 done이 true일 때까지 next 메서드를 반복 호출하므로, 위 코드의 전체 iter.next()를 대체할 수 있습니다.

for(const value of iter) {
  console.log(value)
}
// ... 첫 번째 이터레이팅 과정 중에 출력되는 로그 생략
// 결과) 4
// ... 두 번째 이터레이팅 과정 중에 출력되는 로그 생략
// 결과) 16
// ... 세 번째 이터레이팅 과정 중에 출력되는 로그 생략

펼치기 문법(Spread Syntax, ...)은 연속된 iter.next()의 각 value를 나열하므로, 마찬가지로 전체 iter.next()를 대체할 수 있습니다.

const resultArray = [...iter]
console.log(resultArray)
// ... 전체 이터레이팅 과정 중에 출력되는 로그 생략
// 결과) [4, 16]

혹은, 다음과 같이 메서드 체이닝을 활용하는 방안도 좋습니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

Iterator.prototype._toArray = function () {
  const result = []
  for (const item of this) {
    result.push(item)
  }
  return result
}

const arr = [1, 2, 3, 4, 5]
const iter = arr
  .values()
  ._filter(v => v % 2 === 0)
  ._map(v => v ** 2)
  ._toArray()
console.log(iter)
// ... 전체 이터레이팅 과정 중에 출력되는 로그 생략
// 결과) [4, 16]

이터레이터 헬퍼

사실 앞서 Iterator.prototype에 추가한 여러 메서드(_filter, _map, _toArray)에서 접두어 _를 제거하면, ES2025에 추가될 이터레이터 헬퍼 메서드(filter, map, toArray)와 동일합니다. 지금 브라우저 개발자 도구의 콘솔 탭에서 다음 코드를 실행해 보세요. 이미 주요 브라우저(크롬 및 크롬 기반 브라우저, 파이어폭스, 사파리)가 이터레이터 헬퍼 메서드를 지원하고 있습니다. (브라우저 및 OS 업데이트가 필요할 수 있습니다.)

각 메서드에 대한 정확한 지원 여부는 Can I Use - Iterator.map에서 확인하시기 바랍니다.

1
2
3
4
5
6
7
8

const arr = [1, 2, 3, 4, 5]
const iter = arr
  .values()
  .filter(v => v % 2 === 0)
  .map(v => v ** 2)
  .toArray()
console.log(iter)
// [4, 16]

아래 그림은 MDN - Iterator() constructor 페이지의 스크린숏입니다. 그림의 좌측 목록에 보이는 모든 항목이 2025년 3월에 새롭게 Baseline에 추가된 기능들입니다.

추가된 이터레이터 헬퍼 기능들을 간략히 살펴보겠습니다.

1. 이터레이터를 소비하지 않는 메서드

여기서 소개하는 이터레이터 헬퍼 메서드는 모두 실행 결과로 새로운 이터레이터를 반환합니다. 즉, 이 메서드들을 호출하는 것만으로는 평가가 이루어지지 않습니다. 평가를 위해서는 뒤에 등장할 이터레이터를 소비하는 메서드를 체이닝하거나, 이터레이터의 next 메서드를 호출해야 합니다.

1-1. .map(mapperFn) • Iterator.prototype.map

map 메서드는 이터레이터(this)의 각 요소에 대해 인자로 받은 함수(mapperFn)를 실행하여, 실행 결과들로 구성된 새로운 이터레이터를 반환합니다. 배열의 Array.prototype.map 메서드와 유사합니다.

1-2. .filter(filtererFn) • Iterator.prototype.filter

filter 메서드는 이터레이터(this)의 각 요소에 대해 인자로 받은 함수(filtererFn)를 실행하여, 실행 결과가 true인 요소들만으로 구성된 새로운 이터레이터를 반환합니다. 배열의 Array.prototype.filter 메서드와 유사합니다.

1-3. .take(limit) • Iterator.prototype.take

take 메서드는 이터레이터(this)의 요소 중 처음부터 인자로 받은 수(limit)만큼의 요소만 포함하는 새로운 이터레이터를 반환합니다. 배열에서 arr.slice(0, limit)를 실행하는 것과 유사합니다.

1-4. .drop(limit) • Iterator.prototype.drop

drop 메서드는 이터레이터(this)의 요소 중 처음부터 인자로 받은 수(limit)만큼의 요소를 제외한 나머지 요소들로 구성된 새로운 이터레이터를 반환합니다. 배열에서 arr.slice(limit)를 실행하는 것과 유사합니다.

1-5. .flatMap(mapperFn) • Iterator.prototype.flatMap

flatMap 메서드는 이터레이터(this)의 각 요소에 대해 인자로 받은 함수(mapperFn)를 실행하여, 실행 결과를 단일 깊이로 평탄화(flatten) 한 새로운 이터레이터를 반환합니다. 배열의 Array.prototype.flatMap 메서드와 유사합니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

const nestedArray = [[1, 2], [3, 4], [5]]
const flattened = nestedArray
  .values()
  .flatMap(arr => arr.map(v => v * 2))
  .toArray()
console.log(flattened)
// [2, 4, 6, 8, 10]

const words = ["hello world", "iterator helpers"]
const result = words
  .values()
  .flatMap(word => word.split(" "))
  .toArray()
console.log(result)
// ["hello", "world", "iterator", "helpers"]

2. 이터레이터를 소비하는 메서드

여기서 소개하는 이터레이터 헬퍼 메서드는 모두 실행 시 이터레이터를 소비하여, 그 결과로 이터레이터가 아닌 값을 반환합니다. 이터레이터를 소비하므로, 이후로는 이터레이터 헬퍼 메서드를 체이닝할 수 없습니다.

2-1. .reduce(reducer [, initialValue ]) • Iterator.prototype.reduce

reduce 메서드는 이터레이터(this)의 각 요소에 대해 인자로 받은 함수(reducer)를 실행한 결과를 누적하여 최종 값을 반환합니다.

2-2. .toArray() • Iterator.prototype.toArray

toArray 메서드는 이터레이터(this)의 각 요소로 구성된 배열을 반환합니다.

2-3. .forEach(fn) • Iterator.prototype.forEach

forEach 메서드는 이터레이터(this)의 각 요소에 대해 인자로 받은 함수(fn)를 실행합니다. 배열의 Array.prototype.forEach 메서드와 유사합니다.

2-4. .some(fn) • Iterator.prototype.some

some 메서드는 이터레이터(this)의 요소 중 인자로 받은 함수(fn)를 실행한 결과가 하나라도 true이면 true를, 그렇지 않으면 false를 반환합니다. 배열의 Array.prototype.some 메서드와 유사합니다.

2-5. .every(fn) • Iterator.prototype.every

every 메서드는 some 메서드와 반대로, 이터레이터(this)의 요소 중 인자로 받은 함수(fn)를 실행한 결과가 모두 true이면 true를, 그렇지 않으면 false를 반환합니다. 배열의 Array.prototype.every 메서드와 유사합니다.

2-6. .find(fn) • Iterator.prototype.find

find 메서드는 이터레이터(this)의 요소 중 인자로 받은 함수(fn)를 실행한 결과가 true인 첫 번째 요소를 반환합니다. 결괏값이 true인 요소가 하나도 없다면 undefined를 반환합니다. 배열의 Array.prototype.find 메서드와 유사합니다.

3. 정적 메서드

3-1. Iterator.from(object)

Iterator.from은 이터레이터 또는 이터러블 객체를 인자로 받아 Iterator 클래스의 인스턴스를 반환합니다.

이터러블 객체란, 이터레이터를 반환하는 [Symbol.iterator] 메서드를 보유한 객체를 의미합니다. [Symbol.iterator]는 이터레이터 프로토콜을 따르는 객체를 반환해야 합니다. 이터레이터 프로토콜이란 ‘이터레이터’로 인정받기 위한 최소한의 규약으로, next 메서드를 소유하고, next 메서드는 호출 시 불리언 done 프로퍼티를 포함한 객체를 반환해야 합니다.

이 규약만 충족하면 내용은 개발자가 자유롭게 구현할 수 있습니다. 따라서 [Symbol.iterator] 메서드는 제너레이터일 수도 있고, Iterator 인스턴스를 반환하는 함수일 수도 있으며, 커스텀 객체를 반환하는 함수일 수도 있습니다. 앞의 두 방식은 이터레이터 헬퍼 메서드를 사용할 수 있습니다(제너레이터는 Iterator를 상속받음). 그러나 마지막 방식은 이터레이터 프로토콜을 충족했을 뿐, Iterator 클래스를 상속한 인스턴스는 아니므로 헬퍼 메서드를 사용할 수 없습니다. 이런 경우 Iterator.from은 원본 이터레이터를 Iterator 인스턴스로 변환하여 반환합니다.

정리하면, Iterator.from은 다음과 같은 동작을 수행합니다.

1. 대상이 Iterator 인스턴스라면, 대상을 그대로 반환합니다.

   1 2 3 4 5 6 7

   const generatedIterator = (function* () { yield 1 })() // 제너레이터(Iterator의 서브 클래스)의 인스턴스 const newIter1 = Iterator.from(generatedIterator) console.log(generatedIterator instanceof Iterator) // true console.log(newIter1 === generatedIterator) // true

2. 대상이 이터레이터 프로토콜을 따르는 일반 객체라면, 이를 Iterator 인스턴스로 변환하여 반환합니다.

   1 2 3 4 5 6 7 8 9 10 11 12

   const normalIterator = (() => { let i = 0 return { next() { return { value: i, done: i++ > 3 } } } })() // Iterator의 인스턴스가 아님 const newIter2 = Iterator.from(normalIterator) console.log(normalIterator instanceof Iterator) // false console.log(newIter2 instanceof Iterator) // true

3. 대상이 이터러블 객체라면, [Symbol.iterator] 메서드를 실행하여 반환된 값(이터레이터)에 위의 1번 또는 2번 항목의 동작을 적용합니다.

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

   const generatedIterableObject = { [Symbol.iterator]() { return generatedIterator } } const normalIterableObject = { [Symbol.iterator]() { return normalIterator } } const newIter1 = Iterator.from(generatedIterableObject) const newIter2 = Iterator.from(normalIterableObject) console.log(newIter1 === generatedIterator) // true console.log(normalIterator instanceof Iterator) // false console.log(newIter2 instanceof Iterator) // true

성능

여기서는 성능 측정을 위한 함수를 작성하여 공통적으로 사용하겠습니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

const test = (title, initTarget, func, trial = 10) => {
  let tryCount = 0
  const result = []
  const call = () => {
    const target = initTarget()
    const t0 = performance.now()
    func(target)
    const t1 = performance.now()
    result.push(t1 - t0)
  }
  while(tryCount++ < trial) {
    call()
  }
  console.log(`${title}: ${
    (result.reduce((r, c) => r + c) / trial).toFixed(3)
  } ms`)
}

모든 테스트는 다음 환경에서 실행하였습니다.

- MacBook Pro (M1, 2021)- macOS Sequoia 15.4.1- Node.js v22.12.0- Chrome 138.0.7158.0- Firefox 138.0.1- Safari 18.4

브라우저에 따라 대규모 데이터에 대한 단일 순회에서의 처리 속도가 다른데, 전반적으로 현재까지는 이터레이터가 기존 메서드에 비해 다소 느린 편입니다.

const arr = Array.from({ length: 50_000_000 }, (_, i) => [i, i])

let count = 0
test('배열', () => arr, target => 
  target.forEach(v => { count++ })
)
test('이터레이터', () => arr.values(), target => {
  for(const v of target) { count++ }
})

/*
-- 크롬 브라우저에서 실행한 결과 --
배열 307.480 ms
이터레이터 380.080 ms

-- 파이어폭스 브라우저에서 실행한 결과 --
배열 327.800 ms
이터레이터 183.600 ms

-- 사파리 브라우저에서 실행한 결과 --
배열 744.800 ms
이터레이터 873.200 ms

-- node.js에서 실행한 결과 --
배열 326.346 ms
이터레이터 1056.682 ms
*/

데이터 크기가 작은 경우에는 유의미한 성능 차이가 없습니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

const arr = Array.from({ length: 10_000 }, (_, i) => [i, i])
// 이하 코드 생략

/*
-- 크롬 브라우저에서 실행한 결과 --
배열 0.100 ms
이터레이터 0.180 ms

-- 파이어폭스 브라우저에서 실행한 결과 --
배열 0.200 ms
이터레이터 0.100 ms

-- 사파리 브라우저에서 실행한 결과 --
배열 0.200 ms
이터레이터 0.200 ms

-- node.js에서 실행한 결과 --
배열 0.103 ms
이터레이터 0.235 ms
*/

위 결과와 같이, 단일 순회에서는 (일부 브라우저에서) 이터레이터가 배열의 forEach 메서드보다 느립니다. 하지만 이는 단일 순회에 한정된 문제일 뿐이며, 그 차이도 크지 않습니다. 오히려 다음과 같이 메서드 체이닝을 사용하는 경우, 이터레이터가 훨씬 더 효율적일 수 있습니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

const pageSize = 10
const arr = Array.from(
  { length: 50_000_000 }, 
  (_, i) => ({ isVisible: i % 3 !== 0, index: i })
)

const getPageDataArray = (offset = -1) => target => 
  target
    .slice(offset + 1)
    .filter(v => v.isVisible)
    .slice(0, pageSize)
    .map(v => v.index)
test('배열', () => arr, getPageDataArray(10))

const getPageDataIterator = (offset = -1) => target => 
  target
    .drop(offset + 1)
    .filter(v => v.isVisible)
    .take(pageSize)
    .map(v => v.index)
    .toArray()
test('이터레이터', () => arr.values(), getPageDataIterator(10))

/*
-- 크롬 브라우저에서 실행한 결과 --
배열 665.720 ms
이터레이터 0.010 ms

-- 파이어폭스 브라우저에서 실행한 결과 --
배열 826.900 ms
이터레이터 0.100 ms

-- 사파리 브라우저에서 실행한 결과 --
배열 1160.100 ms
이터레이터 0.800 ms

-- node.js에서 실행한 결과 --
배열 0.010 ms
이터레이터 0.004 ms
*/

배열은 filter 단계에서 이미 5백만 개의 데이터를 처리하느라 메모리 사용량이 급증하거나, 연산 시간이 길어질 수 있습니다. 반면, 이터레이터는 지연 평가 덕분에 필요한 데이터만 처리하므로 훨씬 빠르고 효율적입니다. 이처럼 단일 순회에서의 성능 저하보다, 순회 횟수를 줄임으로써 얻는 이점이 훨씬 큽니다. 또한, 대규모 데이터 처리 시 메모리 초과로 인해 서비스가 중단되는 위험을 줄일 수 있다는 점도 큰 장점입니다.

더 나아가, 주요 브라우저 벤더들은 자바스크립트 성능 최적화를 위해 지속적으로 노력하고 있습니다. 예를 들어, ES2015 도입 초기에는 let, const 및 블록 스코프의 성능 문제가 제기되었지만, 몇 년 사이에 이러한 논란은 사라졌고, 경우에 따라 더 빠른 성능을 보이기도 했습니다. 이러한 흐름을 고려할 때, 이터레이터의 성능도 시간이 지남에 따라 개선될 가능성이 높습니다.

데이터 타입별 이터레이터 도입 기법

이터레이터 헬퍼는 기존에 사용하던 모든 순회 문법을 대체할 만큼 강력한 기능을 제공합니다. 아래에서는 다양한 데이터 타입에 대해 이터레이터를 활용하는 실용적인 방법을 소개합니다.

1. 배열(Array)

배열은 Symbol.iterator가 구현된 이터러블 객체입니다. 따라서 [Symbol.iterator] 메서드를 통해 이터레이터로 변환할 수 있습니다. Iterator.from 및 values 메서드도 동일하게 동작합니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

const pageSize = 5
const arr = Array.from(
  { length: 5_000_000 },
  (_, i) => ({ isVisible: i % 3 !== 0, index: i })
)

const getPageData = (iter, offset = -1) =>
  iter
    .drop(offset + 1)
    .filter(v => v.isVisible)
    .take(pageSize)
    .map(v => v.index)
    .toArray()

getPageData(arr[Symbol.iterator]())
// [1, 2, 4, 5, 7]
getPageData(Iterator.from(arr), 7)
// [8, 10, 11, 13, 14]
getPageData(arr.values(), 14)
// [16, 17, 19, 20, 22]

2. 맵(Map), 셋(Set)

맵과 셋은 처음부터 이터레이터를 사용할 목적으로 설계된 자료구조입니다. 복잡한 연산이 필요할 때 entries, keys, 또는 values 메서드를 사용해 이터레이터로 변환한 뒤 연산을 수행하고, 마지막에 다시 맵 또는 셋으로 변환하면 됩니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

const map = new Map([
  ['a', 1],
  ['b', 2],
  ['c', 3],
  ['d', 4],
  ['e', 5],
])

const filteredMap = new Map(
  map.entries().filter(([k, v]) => v % 2 === 0)
)
console.log(filteredMap)
// Map { 'b' => 2, 'd' => 4 }

const droppedValueSet = new Set(
  map.values().drop(2)
)
console.log(droppedValueSet)
// Set { 3, 4, 5 }

const set = new Set(['a', 'b', 'c', 'd', 'e'])
const reducedKeys = set.values().reduce((a, c) => a + c, '')
console.log(reducedKeys)
// abcde

[Symbol.iterator] 메서드와 Iterator.from은 entries 메서드와 동일하게 동작합니다.

1
2
3
4
5
6
7
8
9
10
11

const filteredArray = map[Symbol.iterator]()
  .filter(([k, v]) => v % 2 === 0)
  .toArray()
console.log(filteredArray)
// [['b', 2], ['d', 4]]

const filteredSet = new Set(
  Iterator.from(set).filter(v => v !== 'c')
)
console.log(filteredSet)
// Set { 'a', 'b', 'd', 'e' }

3. 객체(Object)

객체는 원래 순회에 적합하지 않은 자료구조입니다. 내부를 순회하는 방법이 몇 가지 있긴 하지만, 모두 한계가 있습니다.

우선 객체의 for ... in 문법은 프로토타입 체인 상의 상위 프로퍼티까지 모두 열거하여 순회합니다. 따라서 대상 객체의 프로퍼티만 출력하려면 hasOwn으로 필터링해야 합니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

const Rectangle = {
  name: '사각형',
  getSize() {
    return this.width * this.height
  }
}
const square = Object.create(Rectangle, {
  width: { value: 10, enumerable: true },
  height: { value: 10, enumerable: false }
})

for (const key in square) {
  console.log(key, square[key])
}
// width 10
// name 사각형
// getSize() { ... }

for (const key in square) {
  if (Object.hasOwn(square, key)) console.log(key, square[key])
}
// width 10

Object.entries, Object.keys, Object.values는 hasOwn 필터링이 필요하지 않습니다. 하지만 이들은 하위 호환성을 위해 배열을 반환합니다. (배열, Map, Set의 entries, keys, values 메서드는 이터레이터를 반환합니다.)

console.log(Object.entries(square)) // [['width', 10]]
console.log(Object.keys(square))    // ['width']
console.log(Object.values(square))  // [10]

일반 객체 자체로는 for ... of를 사용할 수 없습니다. 필요할 때마다 Object.entries, Object.keys, Object.values 등을 사용해 변환할 수 있지만, 이터레이터 변환 메서드를 적용하면 더 편리합니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

const IterableObject = {
  entries() {
    return Iterator.from(Object.entries(this))
  },
  keys() {
    return Iterator.from(Object.keys(this))
  },
  values() {
    return Iterator.from(Object.values(this))
  }
}
const toIterable = (obj) => {
  Object.setPrototypeOf(obj, IterableObject)
  return obj
}

const idols = {
  rwice: { name: '르와이스', company: 'jyb' },
  itze : { name: '잇제', company: 'jyb' },
  btx: { name: '비티엑스', company: 'hype' },
  nuzinse: { name: '누진세', company: 'hype' }
}
const iterableIdols = toIterable(idols)

console.log([...iterableIdols.entries()])
// [['rwice', { ... }], ['itze', { ... }], ['btx', { ... }], ['nuzinse', { ... }]]

이제 Object.entries, Object.keys, Object.values 대신 이터러블 객체에서 직접 entries, keys, 또는 values 메서드를 호출해 이터레이터를 사용할 수 있습니다. 필요에 따라 Map이나 Set으로 변환할 수도 있습니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

const jybIdols = Object.fromEntries(
  iterableIdols
    .entries()
    .filter(([, { company }]) => company === 'jyb')
)
console.log(jybIdols)
// {itze: {name: '잇제', company: 'jyb'}, rwice: {name: '르와이스', company: 'jyb'}}
console.log(jybIdols.rwice === idols.rwice)
// true

const idolSetEndsWithS = new Set(
  iterableIdols
    .values()
    .filter(({ name }) => name.endsWith('스'))
    .map(({ name }) => name)
)
console.log(idolSetEndsWithS)
// Set {'르와이스', '비티엑스'}

4. 문자열

문자열은 배열과 마찬가지로 Symbol.iterator가 구현된 이터러블 객체입니다. 따라서 [Symbol.iterator] 메서드나 Iterator.from으로 이터레이터로 변환할 수 있습니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

const crypt = adder => str =>
  Iterator.from(str).reduce((a, c) => {
    const ascii = c.charCodeAt(0)
    return `${a}${String.fromCharCode(ascii + adder)}`
  }, '')
const encrypt = crypt(-1)
const decrypt = crypt(1)

const originalString = 'Hello, World! This is iterator helpers.'
const encrypted = encrypt(originalString)
console.log(encrypted)
// Gdkkn+Vnqkc Sghrhrhsdq`snqgdkodqr-

const decrypted = decrypt(encrypted)
console.log(decrypted)
// Hello, World! This is iterator helpers.

마치며

이제 이터레이터 헬퍼의 도입으로 순회 작업이 더욱 간결하고 효율적으로 개선되고 있습니다. ES2025에서는 동기(sync) 이터레이터 헬퍼가 도입되었으며, 비동기(async) 헬퍼는 별도의 제안으로 분리되어 현재 Stage 2에 올라 있습니다. 동시성 관련 문제가 해결되면, 머지않아 비동기 이터레이터 헬퍼도 정식으로 도입될 것입니다.

단일 순회에서는 아직 이터레이터가 기존 메서드나 명령어보다 다소 느린 경향이 있습니다. 하지만 성능이 극도로 중요한 경우가 아니라면, 이터레이터로 전환할 때 얻는 실익이 더 크다고 생각합니다. 게다가 앞서 살펴보았듯, 단일 순회를 제외한 대부분의 복잡한 연산에서 이터레이터는 성능과 안정성 측면에서 탁월한 결과를 보여줍니다.

본문에서 자세히 다루지는 않았지만, 이터레이터 헬퍼는 함수형 프로그래밍과도 매우 잘 어울립니다. 앞서 직접 구현한 _filter, _map 등과 같이, 필요한 메서드들을 차곡차곡 쌓아 자신만의 함수형 프로그래밍 체계를 만들어 보는 것도 좋은 방법입니다. Lodash로부터의 해방?!

사파리 브라우저는 2025년 3월 말에야 이터레이터 헬퍼를 정식으로 지원하기 시작했기 때문에, 당장은 일부 오류를 발견하거나 성능 저하를 경험할 가능성이 있습니다. 하지만 몇 달 내로 안정성이 크게 향상될 것이라고 기대합니다.

혹시 제가 빠뜨리거나 잘못 소개한 내용이 있다면 댓글로 알려주세요. 실용적인 예시를 공유해 주신다면 더욱 감사하겠습니다. 다양한 의견과 정보 교류를 통해 함께 성장하는 기회가 될 수 있다면 좋겠습니다.

참고 문헌

• TC39 Proposal - Iterator Helpers
• MDN - Iterator

원문: React Reconciliation: The Hidden Engine Behind Your Components

조정 엔진(Reconciliation Engine)

이전 글들(1, 2)에서 React.memo의 작동 방식과 컴포지션을 활용한 성능 최적화 방법을 살펴보았습니다. 하지만 리액트 성능을 제대로 정복하기 위해서는 리액트의 핵심 엔진, 즉 조정(Reconciliation) 알고리즘을 깊이 이해해야 합니다.

조정은 리액트가 DOM을 컴포넌트 트리와 일치하도록 업데이트하는 과정입니다. 이를 통해 리액트의 선언형 프로그래밍 모델이 가능해집니다. 개발자가 원하는 결과를 선언적으로 기술하면, 리액트가 이를 효율적으로 구현하는 방법을 찾아 적용하는 것입니다.

컴포넌트 정체성(Identity)과 상태 유지(State Persistence)

우선, 리액트가 컴포넌트 정체성을 어떻게 다루는지 보여주는 흥미로운 동작을 살펴보겠습니다.

다음은 텍스트 인풋을 토글하는 간단한 예제입니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

const UserInfoForm = () => {
  const [isEditing, setIsEditing] = useState(false);

  return (
    <div className="form-container">
      <button onClick={() => setIsEditing(!isEditing)}>
        {isEditing ? "Cancel" : "Edit"}
      </button>

      {isEditing ? (
        <input
          type="text"
          placeholder="Enter your name"
          className="edit-input"
        />
      ) : (
        <input
          type="text"
          placeholder="Enter your name"
          disabled
          className="view-input"
        />
      )}
    </div>
  );
};

인풋에 텍스트를 입력한 후 “Cancel” 버튼을 클릭하고 다시 “Edit” 버튼을 클릭하면, 입력한 텍스트가 그대로 남아 있습니다. 두 input 요소가 서로 다른 props(클래스 명 및 비활성화 여부)를 가지고 있음에도 불구하고 말이죠.

리액트는 두 요소가 동일한 타입(input)이고, 요소 트리 내에서 같은 위치에 있을 때, 해당 DOM 요소와 그 상태를 그대로 유지합니다. 이때 리액트는 단순히 기존 요소의 props만 업데이트할 뿐, 새로 생성하지 않습니다.

코드를 다음과 같이 변경하고 다시 테스트해봅시다.

1
2
3
4
5
6
7

{
  isEditing ? (
    <input type="text" placeholder="Enter your name" className="edit-input" />
  ) : (
    <div className="view-only-display">Name will appear here</div>
  );
}

이번에는 편집 모드를 토글하면 입력한 텍스트가 사라집니다. 완전히 다른 요소가 언마운트(input) 및 마운트(div)되기 때문입니다.

이는 리액트의 조정에서 요소 타입이 컴포넌트의 정체성을 결정하는 중요한 요소임을 보여줍니다. 이 개념을 이해하는 것이 리액트 성능을 마스터하는 핵심 열쇠입니다.

가상 DOM이 아닌 “요소(Element)” 트리

흔히 리액트가 업데이트를 최적화하기 위해 “가상 DOM”을 사용한다고 알려져 있지만, 그보다는 화면에 표시되어야 할 내용을 간단히 기술한 “요소 트리”로 생각하는 것이 더 정확합니다.

다음과 같이 JSX를 작성해 봅시다.

1
2
3
4
5
6
7
8

const Component = () => {
  return (
    <div>
      <h1>Hello</h1>
      <p>World</p>
    </div>
  );
};

리액트는 이를 다음과 같은 단순한 자바스크립트 객체 트리로 변환합니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

{
  type: 'div',
  props: {
    children: [
      {
        type: 'h1',
        props: {
          children: 'Hello'
        }
      },
      {
        type: 'p',
        props: {
          children: 'World'
        }
      }
    ]
  }
}

div나 input 같은 DOM 요소의 “type”은 문자열입니다. 반면, 커스텀 리액트 컴포넌트의 “type”은 실제 함수에 대한 참조입니다.

1
2
3
4
5
6
7

{
  type: Input, // Input 함수 자체에 대한 참조
  props: {
    id: "company-tax-id",
    placeholder: "Enter company Tax ID"
  }
}

조정이 작동하는 방식

UI를 업데이트하고자 할 때(상태 변경 또는 재렌더링 시), 리액트는 다음의 과정을 거칩니다.

1. 컴포넌트를 호출하여 새로운 요소 트리를 생성합니다.
2. 이전 트리와 비교합니다.
3. 실제 DOM을 새로운 트리와 일치시키기 위해 작업이 필요한 DOM을 파악합니다.
4. 파악한 작업을 효율적으로 수행합니다.

비교 알고리즘은 다음의 주요 원칙을 따릅니다.

1. 요소 타입이 정체성을 결정합니다.

리액트는 먼저 요소의 “type”을 확인하고, 타입이 변경되면 전체 하위 트리를 다시 빌드합니다.

1
2
3
4
5
6
7
8
9

// 첫 번째 렌더링
<div>
  <Counter />
</div>

// 두 번째 렌더링
<span>
  <Counter />
</span>

div가 span으로 변경되었으므로 리액트는 이전 트리 전체를 제거하고 새 트리를 처음부터 다시 빌드합니다.

2. 트리에서의 위치가 중요합니다.

리액트의 조정 알고리즘은 트리 구조 내에서 컴포넌트의 위치에 크게 의존합니다. 위치는 비교 과정에서 주요 정체성 지표로 작용합니다.

1
2
3
4

// showDetails = true: <UserProfile userId={123} />
<>
  {showDetails ? <UserProfile userId={123} /> : <LoginPrompt />}
</>

1
2
3
4

// showDetails = false: <LoginPrompt />
<>
  {showDetails ? <UserProfile userId={123} /> : <LoginPrompt />}
</>

이 조건부 렌더링 예제에서, 리액트는 프래그먼트의 첫 번째 자식 위치(위치 1)를 단일 “슬롯”으로 처리합니다. showDetails가 true에서 false로 변경되면, 리액트는 해당 위치에서 렌더링 간의 내용을 비교하여 컴포넌트 타입이 서로 다름(UserProfile과 LoginPrompt)을 파악합니다. 위치 1의 컴포넌트 타입이 변경되었으므로, 리액트는 이전 컴포넌트를 완전히 언마운트(상태 포함)하고 새 컴포넌트를 마운트합니다.

더 간단한 다음 예시에서는 위치 기반 정체성 덕분에 컴포넌트가 상태를 유지합니다.

1
2
3
4
5
6
7
8

// isPrimary = true: <UserProfile userId={123} role="primary" />
<>
  {isPrimary ? (
    <UserProfile userId={123} role="primary" />
  ) : (
    <UserProfile userId={456} role="secondary" />
  )}
</>

1
2
3
4
5
6
7
8

// isPrimary = false: <UserProfile userId={456} role="secondary" />
<>
  {isPrimary ? (
    <UserProfile userId={123} role="primary" />
  ) : (
    <UserProfile userId={456} role="secondary" />
  )}
</>

isPrimary 값에 상관없이, 리액트는 위치 1에 렌더링할 컴포넌트 타입이 동일함(UserProfile)을 파악합니다. 따라서 컴포넌트를 다시 마운트하지 않고 props만 업데이트하여 컴포넌트 인스턴스를 유지합니다.

이 위치 기반 접근 방식은 대부분의 시나리오에서 잘 작동하지만, 다음과 같은 경우에는 문제가 될 수 있습니다.

1. 컴포넌트 위치가 동적으로 변경될 때(예: 리스트를 동적으로 정렬(sort)하는 경우)
2. 컴포넌트가 다른 위치로 이동하더라도 상태를 보존하고자 할 때
3. 컴포넌트의 재마운트 시점을 제어하고자 할 때

이러한 상황에서는 리액트의 key 시스템이 유용합니다.

3. key는 위치 기반 비교보다 우선합니다.

key 속성은 리액트의 기본적인 위치 기반 식별 방식보다 우선 적용되어, 개발자가 명시적으로 컴포넌트 정체성을 제어할 수 있도록 합니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

const TabContent = ({ activeTab, tabs }) => {
  return (
    <div className="tab-container">
      {tabs.map((tab) => (
        // key는 위치 기반 비교에 우선합니다.
        <div key={tab.id} className="tab-content">
          {activeTab === tab.id ? (
            <UserProfile
              key="active-profile"
              userId={tab.userId}
              role={tab.role}
            />
          ) : (
            <div key="placeholder" className="placeholder">
              Select this tab to view {tab.userId}'s profile
            </div>
          )}
        </div>
      ))}
    </div>
  );
};

UserProfile 컴포넌트가 조건부 렌더링에서 서로 다른 위치에 나타나더라도, 리액트는 동일한 key를 가진 컴포넌트를 동일한 컴포넌트로 간주합니다. 어떤 탭이 활성화되든, 활성화된 탭의 “active-profile” key는 일정하게 유지되므로, 리액트는 컴포넌트의 상태를 보존함으로써 탭 간 전환을 더 부드럽게 처리할 수 있습니다.

역자주: 두 개의 탭이 존재한다고 했을 때, activeTab의 값이 "1"일 때와 "2"일 때의 렌더링 결과는 다음과 같습니다.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

/* const tabs = [{ id: "1", userId: "a", role: "aa" }, { id: "2", userId: "b", role: "bb" }] */ // activeTab === "1"일 때 ( <div className="tab-container"> <div key="1" className="tab-content"> <UserProfile key="active-profile" userId="a" role="aa" /> </div> <div key="2" className="tab-content"> <div key="placeholder" className="placeholder"> Select this tab to view {tab.userId}'s profile </div> </div> </div> ) // activeTab === "2"일 때 ( <div className="tab-container"> <div key="1" className="tab-content"> <div key="placeholder" className="placeholder"> Select this tab to view {tab.userId}'s profile </div> </div> <div key="2" className="tab-content"> <UserProfile key="active-profile" userId="b" role="bb" /> </div> </div> )

7번 줄과 26번 줄의 컴포넌트 타입 및 key가 동일하므로, 리액트는 이를 동일한 컴포넌트로 파악하여 재렌더링하지 않고 props만 변경합니다.

이처럼 key는 렌더 트리의 구조적 위치와 상관없이 컴포넌트 정체성을 유지할 수 있는 방법을 제공하는, 리액트의 컴포넌트 계층구조조정 방식을 제어할 수 있는 강력한 도구입니다.

key의 마법

key는 주로 리스트에서 쓰이는 것으로 알려져 있지만, 실은 리액트의 조정 과정에서 더 깊은 의미를 가집니다.

리스트에 key가 필요한 이유

리스트를 렌더링할 때, 리액트는 key를 통해 어떤 항목이 추가, 제거, 또는 재정렬 되었는지를 파악합니다.

1
2
3
4
5

<ul>
  {items.map((item) => (
    <li key={item.id}>{item.text}</li>
  ))}
</ul>

key가 없으면, 리액트는 리스트 내에서의 요소의 위치만을 기준으로 판단하게 됩니다. 이때 만약 리스트의 맨 앞에 새로운 항목을 삽입하면, 리액트는 모든 요소가 위치를 변경한 것으로 이해하여 전체 리스트를 다시 렌더링할 것입니다.

key를 사용하면, 리액트는 위치의 변경과 무관하게, 변경 전후의 렌더링 과정에서 변경된 요소 및 변경되지 않은 요소를 정확히 파악할 수 있습니다.

1. 배열이 아닌 경우의 key?

리액트는 정적인 요소에 대해 key를 강제하지 않습니다.

1
2
3
4
5

// key가 필요하지 않습니다.
<>
  <Input />
  <Input />
</>

위 예제에서 두 인풋은 정적 요소로써 리액트가 트리에서의 위치를 파악할 수 있으므로 key가 필요하지 않습니다.

그러나 다음과 같이, key는 리스트가 아닌 경우에도 강력한 기능을 제공합니다.

1
2
3
4
5
6
7
8
9
10

const Component = () => {
  const [isReverse, setIsReverse] = useState(false);

  return (
    <>
      <Input key={isReverse ? "some-key" : null} />
      <Input key={!isReverse ? "some-key" : null} />
    </>
  );
};

isReverse가 토글될 때, key 'some-key'가 한 인풋 요소에서 다른 인풋 요소으로 이동하여 리액트가 컴포넌트의 상태를 두 위치 간에 “이동”하도록 만듭니다!

역자주: isReverse = true일 때 6번 줄의 Input과, isReverse = false일 때 7번 줄의 Input은 모두 동일한 key('some-key')를 가지므로, 리액트는 이를 동일한 컴포넌트가 6번 줄에서 7번 줄로 이동한 것으로 파악합니다.

2. 동적 요소와 정적 요소 혼합

흔히 동적 리스트의 뒷부분에 정적 요소를 추가하면 정적 요소의 정체성이 변경될지를 우려합니다.

1
2
3
4
5
6

<>
  {items.map((item) => (
    <ListItem key={item.id} />
  ))}
  <StaticElement /> {/* items가 변경되면 이 부분도 다시 마운트 될까요? */}
</>

리액트는 이를 지능적으로 처리합니다. 리액트는 전체 동적 리스트를 하나의 단위로 취급하므로, StaticElement는 리스트 변경과 상관없이 항상 동일한 위치와 정체성을 유지합니다.

리액트가 이를 내부적으로 어떻게 표현하는지 살펴보면 다음과 같습니다.

1
2
3
4
5
6
7
8

[
  // 전체 동적 배열이 단일 자식으로 처리됨
  [
    { type: ListItem, key: "1" },
    { type: ListItem, key: "2" },
  ],
  { type: StaticElement }, // 항상 두 번째 위치를 추적
];

리스트에 항목을 추가하거나 제거하더라도, StaticElement는 부모 배열에서 두 번째 위치를 유지합니다. 따라서 리스트 변경으로 인해 정적 요소가 다시 마운트 되지 않습니다. 이는 리액트가 불필요한 재마운트를 방지하고자 영리하게 최적화한 결과입니다.

3. 전략적인 DOM 제어를 위한 key

리액트에서 key는 리스트만을 위한 것이 아닙니다. key는 리액트에서 컴포넌트와 DOM 요소의 정체성을 제어하는 강력한 도구입니다. 서로 다른 뷰 간에 리액트 컴포넌트 상태를 유지할지를 판단하는 기준으로 key와 컴포넌트 타입이 함께 쓰인다는 점을 기억하세요. 동일한 key를 가진 컴포넌트라도 타입이 다르면 여전히 언마운트 및 리마운트가 발생합니다. 이러한 경우에는 상태를 상위 컴포넌트로 끌어올리는 것이 일반적으로 더 나은 접근 방식입니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

// 상태를 다른 뷰 간에 보존하기 위한 접근법 - 상태 끌어올리기 (여기서는 key가 효과적이지 않습니다.)
const TabContent = ({ activeTab }) => {
  // 탭 변경 간에 보존하고자 하는 상태

  const [sharedState, setSharedState] = useState({
    /* 초기 상태 */
  });
  return (
    <div>
      {activeTab === "profile" && (
        <ProfileTab state={sharedState} onStateChange={setSharedState} />
      )}
      {activeTab === "settings" && (
        <SettingsTab state={sharedState} onStateChange={setSharedState} />
      )}
      {/* 나머지 탭 */}
    </div>
  );
};

이 경우, 탭 간에 타입(및 참조)이 다르기 때문에 key를 유지하는 것만으로는 충분하지 않습니다.

하지만 key와 비제어 컴포넌트를 사용하는 다음 예제를 살펴보세요.

1
2
3
4
5
6
7
8
9
10
11
12

const UserForm = ({ userId }) => {
  return (
    <form>
      <input
        key={userId}
        name="username"
        defaultValue=""
      />
      {/* 나머지 인풋 */}
    </form>
  );
};

userId를 기반으로 비제어 인풋에 key를 부여하면, userId가 변경될 때마다 리액트가 완전히 새로운 DOM 요소를 생성하도록 보장할 수 있습니다. 비제어 인풋의 상태는 리액트 상태가 아닌 DOM 자체에 존재하므로, 다른 사용자로 전환하면 인풋이 초기화됩니다. 그래서 이런 경우에는 key만으로도 충분합니다.

꽤 흥미롭지 않나요? 😊

상태의 지역화(State Colocation): 강력한 성능 패턴

상태의 지역화는 상태를 사용하는 곳에 최대한 가깝게 유지하는 패턴입니다. 이 접근법은 상태 변경으로 인해 영향을 받는 컴포넌트만 업데이트 되도록 보장하여 불필요한 재렌더링을 최소화합니다.

다음 예제를 살펴봅시다.

1
2
3
4
5
6
7
8
9
10
11
12
13

// 성능 낮음 - 필터가 변경되면 맵 전체를 다시 렌더링함
const App = () => {
  const [filterText, setFilterText] = useState("");
  const filteredUsers = users.filter((user) => user.name.includes(filterText));

  return (
    <>
      <SearchBox filterText={filterText} onChange={setFilterText} />
      <UserList users={filteredUsers} />
      <ExpensiveComponent />
    </>
  );
};

filterText가 변경되면, ExpensiveComponent처럼 필터와 관련 없는 컴포넌트를 포함하여 전체 App 컴포넌트가 재렌더링됩니다.

반면, 필터 상태를 실제로 사용하는 컴포넌트 내부로 옮기면 다음과 같이 됩니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

const UserSection = () => {
  const [filterText, setFilterText] = useState("");
  const filteredUsers = users.filter((user) => user.name.includes(filterText));

  return (
    <>
      <SearchBox filterText={filterText} onChange={setFilterText} />
      <UserList users={filteredUsers} />
    </>
  );
};

const App = () => {
  return (
    <>
      <UserSection />
      <ExpensiveComponent />
    </>
  );
};

필터가 변경될 때 UserSection만 재렌더링됩니다. 이 패턴은 성능을 향상시킬 뿐 아니라, 각 컴포넌트가 실제로 사용해야 할 상태만 관리하도록 설계하여 더 나은 컴포넌트 구조를 만듭니다.

컴포넌트 설계: 변경에 대한 최적화

보통 성능 최적화는 컴포넌트 설계 문제에서부터 시작합니다. 컴포넌트가 너무 많은 일을 하면 불필요하게 재렌더링될 가능성이 높아집니다.

React.memo를 사용하기 전에 다음 질문을 던져보세요.

1. 이 컴포넌트가 여러 가지 책임을 지고 있나요?
   여러 관심사를 처리하는 컴포넌트는 더 자주 재렌더링될 가능성이 있습니다.
2. 상태가 너무 높은 위치로 끌어올려져 있나요?
   상태가 필요 이상으로 트리 상단에 위치하면 더 많은 컴포넌트가 재렌더링됩니다.

다음 예제를 봅시다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

// 문제 있는 설계 - 여러 가지 책임을 지는 컴포넌트
const ProductPage = ({ productId }) => {
  const [selectedSize, setSelectedSize] = useState("medium");
  const [quantity, setQuantity] = useState(1);
  const [shipping, setShipping] = useState("express");
  const [reviews, setReviews] = useState([]);

  // 제품 상세 정보와 리뷰를 모두 가져옴
  useEffect(() => {
    fetchProductDetails(productId);
    fetchReviews(productId).then(setReviews);
  }, [productId]);

  return (
    <div>
      <ProductInfo
        selectedSize={selectedSize}
        onSizeChange={setSelectedSize}
        quantity={quantity}
        onQuantityChange={setQuantity}
      />
      <ShippingOptions shipping={shipping} onShippingChange={setShipping} />
      <Reviews reviews={reviews} />
    </div>
  );
};

사이즈, 수량, 배송 옵션이 변경될 때마다 페이지 전체가 재렌더링되며, 리뷰 섹션과 같은 관련 없는 부분도 영향을 받습니다.

더 나은 설계는 이러한 책임을 분리하는 것입니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

const ProductPage = ({ productId }) => {
  return (
    <div>
      <ProductConfig productId={productId} />
      <ReviewsSection productId={productId} />
    </div>
  );
};

const ProductConfig = ({ productId }) => {
  const [selectedSize, setSelectedSize] = useState("medium");
  const [quantity, setQuantity] = useState(1);
  const [shipping, setShipping] = useState("express");

  // 제품 관련 로직

  return (
    <>
      <ProductInfo
        selectedSize={selectedSize}
        onSizeChange={setSelectedSize}
        quantity={quantity}
        onQuantityChange={setQuantity}
      />
      <ShippingOptions shipping={shipping} onShippingChange={setShipping} />
    </>
  );
};

const ReviewsSection = ({ productId }) => {
  const [reviews, setReviews] = useState([]);

  useEffect(() => {
    fetchReviews(productId).then(setReviews);
  }, [productId]);

  return <Reviews reviews={reviews} />;
};

이 구조는 제품 사이즈를 변경해도 리뷰가 재렌더링되지 않도록 보장합니다. 메모이제이션 없이도 컴포넌트 경계를 잘 설정하면 성능을 최적화할 수 있습니다.

조정(Reconciliation)과 클린 아키텍처

리액트의 조정 알고리즘은 클린 아키텍처 원칙과 완벽하게 일치합니다.

1. 단일 책임 원칙(Single Responsibility Principle)
   각 컴포넌트는 변경 이유가 하나여야 합니다. 컴포넌트가 단일 책임에 집중하면 불필요한 재렌더링이 줄어듭니다.
2. 의존성 역전 원칙(Dependency Inversion)
   컴포넌트는 구체적인 구현이 아닌 추상화에 의존해야 합니다. 이를 통해 컴포지션을 통해 성능을 최적화하기가 더 쉬워집니다.
3. 인터페이스 분리 원칙(Interface Segregation)
   컴포넌트는 최소한의 집중된 인터페이스를 가져야 합니다. 이는 props 변경으로 인해 불필요한 재렌더링이 발생할 가능성을 줄여줍니다.

실용적인 가이드라인

조정에 대한 심층 분석을 바탕으로 다음과 같은 실용적인 가이드라인을 제안합니다.

1. 컴포넌트 정의를 부모 컴포넌트 외부로 이동하여 재마운트를 방지하세요.
2. 상태를 하위로 이동하여 재렌더링 경계를 분리하세요.
3. 동일한 위치에서 일관된 컴포넌트 타입을 유지하여 언마운트를 방지하세요.
4. key를 전략적으로 사용하세요. 리스트뿐만 아니라 컴포넌트 정체성을 제어하고 싶을 때도 유용합니다.
5. 재렌더링 문제를 디버깅할 때, 요소 트리와 컴포넌트 정체성을 기준으로 생각하세요.
6. React.memo는 단지 도구일 뿐입니다. 조정 알고리즘의 제약 내에서 작동하며, 근본적인 알고리즘을 변경하지는 않습니다.

결론

리액트의 조정 알고리즘을 이해하면 많은 리액트 성능 패턴의 “이유”를 파악할 수 있습니다. 컴포지션이 효과적인 이유, 리스트에 key가 필요한 이유, 나아가 컴포넌트를 내부에 정의하는 것의 문제점을 드러냅니다.

이 지식은 리액트 애플리케이션의 성능을 자연스럽게 끌어올릴 수 있는 더 나은 아키텍처를 결정하는 데 도움을 줍니다. 과도한 메모이제이션으로 리액트의 조정 알고리즘과 싸우는 대신, 리액트가 컴포넌트를 식별하고 업데이트하는 방식에 맞춰 컴포넌트 구조를 설계함으로써 이를 활용할 수 있습니다.

다음에 리액트 애플리케이션을 최적화할 때, 컴포넌트 구조가 조정 과정에 어떤 영향을 미치는지 생각해 보세요. 때때로 가장 좋은 최적화는 리액트가 컴포넌트를 식별하고 업데이트하는 방식을 고려하여 더 간단하고 집중된 컴포넌트 트리를 만드는 것입니다.

리액트의 조정 프로세스를 다룰 때 여러분이 가장 효과적이라고 생각한 패턴은 무엇인가요? 여러분의 경험을 듣고 싶습니다. 댓글 남겨주세요 🤓

원문: The Forensics of React Server Components (RSC)

간단 요약: 클라이언트 사이드 렌더링은 서버의 무거운 연산 부담을 덜어줍니다. 그 대신 초기 페이지 로드 시 빈 HTML 페이지가 보이는 점에서 사용자 경험에 좋지 않습니다. 반면, 서버 사이드 렌더링은 빠른 CDN을 통해 정적 자산(static assets)을 제공함으로써 초기 페이지 로드 시 충분한 정보를 제공할 수 있게 해줍니다. 그러나 동적 콘텐츠가 많은 대규모 프로젝트에는 서버 사이드 렌더링이 적합하지 않습니다. 리액트 서버 컴포넌트는 두 방식의 장점을 결합한 기술로, 저자 Lazar Nikolov은 RSC가 페이지 로드 타임라인에 미치는 영향을 깊이 있게 살펴봅니다.

이 글에서는 리액트 서버 컴포넌트(React Server Components, 이하 RSC)를 깊이 있게 살펴봅니다. RSC는 리액트 생태계의 혁신적인 최신 기술로, 서버 사이드 렌더링과 클라이언트 사이드 렌더링, 스트리밍 HTML을 활용하여 가능한 한 빠르게 콘텐츠를 전달합니다.

RSC가 리액트 구조 속에서 어떻게 자리 잡는지, 컴포넌트 렌더링 라이프사이클에 대해 어느 정도의 제어권을 제공하는지, 그리고 RSC가 적용된 페이지 로드는 어떤 모습인지 완벽하게 이해하기 위해 세세하게 파고들 것입니다.

그 전에, RSC가 필요하게 된 원인에 대한 맥락을 이해하기 위해, 기존에 리액트가 웹사이트를 렌더링 하던 방식을 되짚어보면 좋겠습니다.

1. 초기: 클라이언트 사이드 렌더링

최초의 리액트 앱은 클라이언트, 즉 브라우저에서 렌더링했습니다(Client-Side Rendering, CSR). 개발자들은 자바스크립트 클래스로 컴포넌트를 작성하고, 웹팩과 같은 번들러를 사용해 모든 코드를 컴파일 및 트리쉐이킹한 상태로 상용 환경에 배포할 수 있는 코드로 패키징했습니다.

서버에서 전달한 HTML에는 다음과 같은 몇 가지 요소가 포함되었습니다.

• HTML 문서. <head>에는 메타데이터가 포함되었으며, <body>에는 빈 <div>가 포함되어 있습니다. 빈 <div>는 DOM에 리액트 앱을 주입하기 위한 요소로 사용됩니다.

• 리액트 핵심 코드와 실제 웹 앱 코드가 포함된 자바스크립트 리소스. 이를 통해 빈 <div> 안에 리액트 앱을 채워 넣고 사용자 인터페이스를 생성할 것입니다.

이 방식을 따르는 웹 앱은 자바스크립트의 작업이 모두 완료된 이후에야 비로소 사용자와 상호작용을 할 수 있습니다. 이는 개발자 경험(DX)에는 좋지만, 사용자 경험(UX)에는 부정적인 영향을 주게 됩니다.

사실, 리액트의 CSR에는 장단점이 존재합니다. 장점은 다음과 같습니다. 화면 전체를 새로고침 하지 않고 업데이트되는 반응형 컴포넌트 덕분에 매끄럽고 빠른 페이지 전환을 제공합니다. 페이지 로딩에 걸리는 시간을 단축합니다. 또한 서버 부담을 줄이고, 빠른 CDN(content delivery network)을 통해 사용자가 지리적으로 가까운 서버에서 콘텐츠를 제공받을 수 있게 해줍니다.

그러나 CSR에는 단점도 있습니다. 예컨대 각 컴포넌트가 독립적으로 데이터를 가져올 수 있어서, 워터폴 네트워크 요청이 발생하면 전체 속도가 현저히 느려질 수 있습니다. 이는 UX 측면에서 단순한 불편함 정도로 여길 수도 있지만, 실은 사용자에게 상당한 손해를 끼칠 수 있는 문제입니다. Eric Bailey의 “Modern Health, frameworks, performance, and harm”은 모든 CSR 작업에 경고하는 이야기라고 할 것입니다.

또 다른 부정적인 CSR 결과로 검색 엔진 크롤러를 들 수 있습니다. 크롤러는 CSR 페이지에 대해 메타데이터와 빈 <div>만 있는 HTML 문서를 접할 수 있을 뿐, 렌더링이 완료된 페이지 전체 정보를 수집하지 못합니다. 최근에는 이 문제가 해결되었지만, 당시 검색 엔진 트래픽에 의존하는 회사 사이트들에는 심각한 문제였습니다.

2. 전환: 서버 사이드 렌더링

변화가 필요했습니다. CSR은 개발자에게 빠르고 인터랙티브한 인터페이스를 구축할 수 있는 강력한 접근 방식을 제공했지만, 전 세계 사용자는 빈 화면과 로딩 인디케이터에 시달려야 했습니다. 해결책은 렌더링 경험을 클라이언트에서 서버로 이전하는 것이었습니다. 개선하기 위해 기존 방식으로 돌아간다는 점이 아이러니해 보일 수도 있겠네요.

그래서 리액트는 서버 사이드 렌더링(Server-Side Rendering, SSR) 기능을 도입했습니다. SSR은 리액트 커뮤니티 내에서 큰 논쟁거리가 되었으며, 한 때 큰 주목을 받기도 했습니다. SSR 도입은 앱 개발 방식에 중대한 변화를 불러왔습니다. 리액트의 동작 방식이 크게 달라졌고, 브라우저 대신 서버를 통해 콘텐츠를 전달할 수 있게 되었습니다.

2.1. CSR 한계 해결

SSR에서는 빈 HTML 문서를 보내는 대신, 서버에서 초기 HTML을 렌더링 하여 브라우저로 전송합니다. 브라우저는 로딩 인디케이터를 보여줄 필요 없이 즉시 콘텐츠를 표시할 수 있습니다. 이는 웹 성능(Web Vitals) 중 First Contentful Paint (FCP) 성능 지표를 크게 개선합니다.

서버 사이드 렌더링은 CSR에서 발생한 SEO 문제도 해결했습니다. 크롤러가 웹사이트의 콘텐츠를 직접 받아 인덱싱할 수 있게 되었기 때문입니다. 또한 클라이언트보다 데이터 소스에 가까운 서버에서 초기 데이터 페칭을 수행하므로, 오류 없이 잘 수행된다면 데이터 요청의 워터폴 현상을 없앨 수 있게 되었습니다.

2.2. 하이드레이션

SSR은 복잡한 과정을 거칩니다. 리액트가 서버에서 받은 정적 HTML을 인터랙티브하게 만들기 위해서는 하이드레이션(Hydration)이 필요합니다. 하이드레이션은 초기 HTML의 DOM을 기반으로 클라이언트 측에서 가상 문서 객체 모델(Virtual DOM)을 재구성하는 과정입니다.

참고: 리액트는 실제 DOM보다 가상 DOM에서 업데이트를 파악하는 것이 빠르기 때문에 자체 Virtual DOM을 사용합니다. UI 업데이트가 필요할 때 가상 DOM과 실제 DOM을 동기화하지만, 변경 사항을 파악하는 알고리즘은 가상 DOM에서 수행됩니다.

이제 리액트에는 두 가지 버전이 존재합니다.

1. 컴포넌트 트리로부터 정적 HTML을 렌더링 하는 서버 사이드 버전

2. 페이지를 인터랙티브하게 만드는 클라이언트 사이드 버전

초기 HTML을 하이드레이트하기 위해서는 리액트와 앱 코드를 브라우저로 전송해야 합니다. 하이드레이션 과정에서 리액트는 서버에서 렌더링 된 DOM과 클라이언트에서 렌더링 된 DOM을 비교하여 차이점을 찾아내는 재조정(reconciliation) 작업을 수행합니다. 만약 두 DOM 사이에 차이가 있다면, 리액트는 컴포넌트 트리를 다시 하이드레이트하고, 컴포넌트 계층 구조를 서버에서 렌더링 된 구조에 맞추어 업데이트하려 합니다. 그래도 해결되지 않는 불일치가 있다면, 리액트는 문제를 알리기 위해 오류를 발생시킵니다. 일반적으로 이를 ‘하이드레이션 오류’라고 합니다.

2.3. SSR의 단점

SSR은 CSR의 한계를 해결하는 만능 해결책은 아닙니다. SSR 역시 단점이 있습니다. 초기 HTML 렌더링과 데이터 페칭을 서버로 옮겼기 때문에, 해당 서버들은 클라이언트에서 모든 것을 로드할 때보다 훨씬 더 큰 부하를 겪게 됩니다.

일반적으로 SSR 도입은 FCP 성능 지표를 개선한다고 합니다. 이는 대체로 맞지만, Time to First Byte (TTFB) 성능 지표 만큼은 그렇지 않습니다. 브라우저는 서버가 필요한 데이터를 페칭하고 초기 HTML을 생성하여 첫 바이트를 전송할 때까지 마냥 기다려야 합니다. TTFB 자체는 핵심 웹 성능에 해당하지 않지만, 다른 성능 지표에 영향을 줍니다. 즉, TTFB가 나쁘면 핵심 웹 성능 지표가 하락합니다.

SSR의 또 다른 단점은 클라이언트 측의 리액트가 하이드레이션을 완료하기 전까지는 전체 페이지가 제대로 동작하지 않는다는 점입니다. 예를 들어, 리액트가 이벤트 리스너를 부착하는 과정을 수행하기 전까지는 인터랙티브 요소들이 사용자 상호작용에 대해 “반응”하지 않습니다. 하이드레이션 과정은 일반적으로 빠르게 이뤄지지만, 사용 중인 기기의 인터넷 연결 상태나 하드웨어 성능에 따라 속도가 눈에 띄게 느려질 수도 있습니다.

3. 현재: 하이브리드 접근 방식

지금까지 리액트 렌더링의 두 가지 형태, 즉 CSR과 SSR에 대해 살펴보았습니다. 이 두 가지 방식이 서로의 한계를 보완하려는 시도였다면, 이제는 CSR과 SSR의 한계를 줄이기 위해 SSR을 다시 세 가지 방식으로 분화한 하이브리드 접근 방식을 취하고 있습니다.

먼저 정적 사이트 생성(Static Site Generation, SSG) 및 증분 정적 재생성(Incremental Static Regeneration, ISR)에 대해 살펴본 후, 세 번째 유형인 RSC로 넘어가겠습니다.

3.1. 정적 사이트 생성 (SSG)

SSG는 요청마다 동일한 HTML 코드를 재생성하지 않습니다. 빌드 타임에 전체 앱을 컴파일하고 구축하여 정적인 순수 HTML과 CSS 파일을 생성하고, 이를 빠른 CDN에 호스팅합니다.

예상할 수 있듯이, 이 접근 방식은 콘텐츠가 크게 변하지 않는 소규모 프로젝트(예: 마케팅 사이트나 개인 블로그)에는 적합하지만, 사용자 상호작용에 따라 콘텐츠가 자주 변경되는 대규모 프로젝트(예: 전자상거래 사이트)에는 적합하지 않습니다.

SSG는 서버의 부담을 줄이는 동시에 서버가 페이지를 다시 렌더링 하기 위해 무거운 작업을 수행할 필요가 없으므로 TTFB와 관련된 성능 지표를 개선합니다.

3.2. 증분 정적 재생성 (ISR)