Node.js 26.12.0: 웹어셈블리 미지원 오류 명확화, 웹소켓 마스킹 함수 추가

1. 미지원 환경의 실패 원인을 구분한다

웹어셈블리는 별도로 컴파일된 모듈을 실행하는 기술이다. 오류 처리 변경 설명에 따르면 이를 쓸 수 없는 환경에서 해당 모듈을 가져오면 ERR_WEBASSEMBLY_NOT_SUPPORTED가 발생한다. 프로그램에서 잡아 처리할 수 있는 오류로 기능 부재를 알리는 방식이다.

다만 오류 처리 변경을 이전에는 실패하지 않던 기능이 새로 실패하는 것으로 읽어서는 안 된다. 검토 대화에서는 이미 발생하던 오류를 더 적절하게 알리는 개선이라고 설명했다.

외부 라이브러리 함수를 고속으로 호출하는 경로도 대상이다. 다른 호출 요건을 갖췄더라도 코드를 읽고 실행할 수 있는 메모리의 지원 여부 검사에 실패하면 ERR_RX_MEMORY_NOT_SUPPORTED로 원인을 알린다. 콜백 할당 실패 뒤에도 이 지원 여부를 진단하되, 플랫폼별 정적 호출 연결 방식과 다른 오류는 보존한다.

필요한 실행 능력이 없을 때 대체 경로를 보장하지 않는다는 점도 문서에 명시했다. 즉, 오류를 잡을 수 있다는 것은 해당 기능을 다른 방식으로 실행해 준다는 뜻이 아니다. 즉석 컴파일을 끈 실행과 리눅스 시스템 호출 제한 환경에 대한 회귀 테스트도 추가됐다.

2. 웹소켓의 반복 연산을 내장 기능으로 옮긴다

웹소켓의 클라이언트는 보내는 프레임, 즉 전송 단위마다 4바이트 키를 반복 적용해 데이터를 가린다. 서버는 같은 연산으로 이를 되돌린다. 양쪽 비트가 다르면 1이 되는 배타적 논리합을 적용하므로, 같은 키를 다시 쓰면 원래 데이터로 돌아온다.

http.websocketMask()는 원본과 출력 위치를 받아 가리는 연산을 하고, http.websocketUnmask()는 받은 버퍼 자체에서 이를 되돌린다. 범용 데이터 가리기가 아니라 웹소켓의 정해진 키 길이에 맞춘 기능이다.

기존의 네이티브 확장 모듈인 bufferutil과 인자 형태를 맞췄다. 따라서 이를 쓰던 라이브러리는 새 함수가 있는지 확인한 뒤 전환할 수 있다. 변경 제안의 작성자는 해당 확장이 설치되는 비율을 ws 다운로드의 약 3%로 설명하며, 나머지 사용자는 주로 자바스크립트 반복문에 의존한다고 밝혔다.

3. 키를 준비하는 책임은 남는다

마스크는 메모리의 일정 구간을 바라보는 ArrayBufferView로 받는다. 검토 과정에서는 숫자 배열도 받자는 제안 대신 기존 확장과의 호환성을 유지했다. 작성자는 통신 라이브러리의 기존 버퍼에서 4바이트 구간을 꺼내 프레임별 배열 할당을 피하는 방식을 제안했다. 원문에 나온 표현은 다음과 같다.

buffer.subarray(bufIdx, bufIdx += 4)

이는 새 함수의 전체 호출 예제가 아니라 키를 담을 메모리 구간을 얻는 표현이다. 연산이 내장됐다고 키 선택까지 생략할 수 있는 것은 아니다. 검토 대화에서 인용한 규격은 프레임마다 예측하기 어려운 새 키를 요구하며, 서버에는 실제로 가려진 데이터가 들어온다는 점도 지적됐다.

4. 성능 이득은 입력 크기와 함께 읽어야 한다

웹소켓 변경의 커밋 설명은 자바스크립트 반복문 대비 1 KiB 입력에서 약 20배, 64 KiB에서 약 40배 빠르다고 밝혔다. 기존 확장보다 빠른 범위는 32바이트 이상으로 제시했다. 반면 작성자는 24바이트 미만에서는 내부 함수 호출 비용 때문에 반복문이 더 빠르다고 설명했다. 측정 하드웨어와 운영체제는 제시되지 않았다.

이익은 별도 확장 설치 없이 반복 연산을 내장 구현으로 옮길 수 있다는 점이다. 대신 라이브러리 개발자에게는 구버전과의 기능 유무 확인, 입력 크기에 따른 경로 선택을 검토하는 일이 남는다. 따라서 제시된 연산 속도 차이를 웹소켓 서비스 전체의 처리량 향상으로 바꾸어 해석하지 않는 편이 타당하다.

이번 버전은 일반 애플리케이션의 기능 확대보다 제한된 실행 환경과 웹소켓 구현을 다루는 개발자에게 의미가 큰 업데이트다.