[2025.08.22 주간 개발 트렌드] Next.js 15.5 정리 (Turbopack 빌드, Middleware, Typed Routes)

![주간 개발 트렌드](https://librarian-blog-images.s3.ap-northeast-2.amazonaws.com/b28d786c-9ec3-46ec-8055-adcd53a303c5_thumbnail_2.png)

# Node.js에도 양자내성 서명이 들어왔다

node:crypto를 보면 해시, 암호화, 전자서명처럼 이름은 익숙한데 정확히 구분하려면 한번 더 생각하게되는 기능이 많다.

이번주 8월 14일에 나온 [Node.js 24.6.0](https://nodejs.org/en/blog/release/v24.6.0)에는 ML-DSA 키와 서명·검증 지원이 추가됐다. 양자내성 암호라고하니 지금 쓰는 암호화를 전부 바꿔야하나 싶을 수 있다..

그런데 이번 변경은 우선 전자서명에 대한 지원으로 봐야한다. 파일을 숨기는 암호화와 작성자·변조 여부를 확인하는 서명은 다른 기능이다.

이번주 개발트렌드로 ML-DSA가 무엇이고 Node.js에서 어떤 의미가 있는지 정리해보려고 한다.

# 1. 우선 서명이 하는 일부터 살펴보자

예를 들어 서버에서 업데이트 파일과 서명을 함께 배포한다고 해보자. 받는 쪽에서는 공개키로 파일과 서명을 검증한다.

```text
만드는 쪽
원본 데이터 + 개인키 → 서명 생성

받는 쪽
원본 데이터 + 서명 + 공개키 → 검증
```

이때 파일 내용이 감춰지는것은 아니다. 검증을 통해 신뢰하는 키로 서명한 데이터인지, 중간에 내용이 바뀌었는지 확인하는것이다.

물론 공개키 자체도 믿을 수 있는 경로로 받아야한다. 공격자가 파일과 서명, 공개키까지 전부 바꿔줬는데 아무 키나 믿으면 서명을 붙인 의미가 줄어든다.

ML-DSA는 이런 전자서명을 위한 양자내성 알고리즘이다. NIST의 FIPS 204로 표준화되어있고, 대규모 양자컴퓨터를 가진 공격자에 대한 내성을 목표로 한다. [ML-DSA 표준 설명](https://csrc.nist.gov/pubs/fips/204/final)

즉 이번 기능을 추가했다고 서비스의 모든 통신이나 저장 데이터가 자동으로 양자내성으로 바뀌는것은 아니다.

# 2. Node.js에서는 어떻게 쓰는건가

24.6.0에서는 기존 crypto API에서 ML-DSA 키를 생성하고 서명과 검증에 사용할 수 있다. 지원하는 키 종류에는 ml-dsa-44, ml-dsa-65, ml-dsa-87이 있다.

간단한 흐름을 코드로 보면 다음과 같다. Node.js 24.6.0과 필요한 OpenSSL 지원이 있는 환경을 기준으로 한 예시다.

```javascript
// signature.mjs
import { generateKeyPairSync, sign, verify } from "node:crypto";

const { publicKey, privateKey } = generateKeyPairSync("ml-dsa-65", {});

const original = Buffer.from("release-version=1.0.0");
const signature = sign(null, original, privateKey);

console.log(verify(null, original, publicKey, signature));

const changed = Buffer.from("release-version=9.0.0");
console.log(verify(null, changed, publicKey, signature));
```

정상적인 실행이라면 원본은 true, 수정된 데이터는 false가 나와야한다. 서명할때 사용한 데이터와 검증할때의 데이터가 같아야한다는걸 확인하는 예제다.

여기서 sign과 verify의 첫번째 인수에 null을 넣었다. ML-DSA에서는 알고리즘이 키 종류에 따라 정해지므로 이 인수는 null 또는 undefined여야한다. 평소 쓰던 해시 이름을 그대로 넣으면 안된다. [24.6.0 crypto API 설명](https://nodejs.org/download/release/v24.6.0/docs/api/crypto.html)

예제는 실행할때마다 새 키를 만든다. 실제 운영에서 이 방식으로 키를 매번 바꿔버리면 이전 서명을 어떻게 검증할지부터 문제가 된다. 키 식별자와 보관·교체 정책은 별도로 설계해야한다.

# 3. 서명 알고리즘만 바꾸면 끝일까

실제 시스템에서는 서명을 만드는 서버만 확인해서는 안된다. 검증하는 프로그램도 같은 형식과 알고리즘을 이해해야한다.

기존 클라이언트가 RSA나 ECDSA만 처리하는데 서버가 갑자기 ML-DSA 서명만 보내면 검증할 수 없다. 라이브러리, 인증서나 메시지 형식, 키 저장 장치의 지원 여부도 확인해야한다.

또한 키와 서명의 크기, 생성·검증 비용이 기존 방식과 다를 수 있다. 데이터베이스 컬럼이나 네트워크 메시지 크기를 작게 가정한 부분이 있는지도 봐야한다.

그래서 전환은 보통 다음처럼 나눠서 생각하는게 좋겠다.

1. 어디에서 어떤 서명을 사용중인지 목록을 만든다.
2. 서명을 만들고 확인하는 시스템을 같이 찾는다.
3. 새 알고리즘을 별도 환경에서 비교한다.
4. 이전 형식과 새 형식을 구분할 방법을 정한다.
5. 점진적으로 전환하고 이전 검증 경로도 확인한다.

이건 알고리즘 조합을 직접 설계하자는 의미는 아니다. 기존 프로토콜과 사용하는 라이브러리의 지원 방식을 기준으로 호환성을 검토하는 과정이다.

# 4. 일반 웹 서비스도 바로 적용해야할까

이번 릴리스가 나왔다고 로그인 토큰이나 HTTPS 설정을 당장 바꿔야하는것은 아니다. Node.js 24.6은 지금 Current 계열이고, 운영 중인 런타임을 바꾸는 일도 별도로 검토해야한다.

개인적으로는 먼저 암호 기능이 어디에 묶여있는지 보는게 좋을것 같다. 알고리즘 이름이 코드 여기저기에 박혀있으면 나중에 전환할때도 수정 범위가 커진다.

```text
확인할 부분
├── 사용하는 알고리즘과 라이브러리
├── 키를 만들고 보관하는 위치
├── 검증하는 외부 시스템
├── 오래 보관하는 서명 데이터
└── 알고리즘과 키 버전을 구분하는 방법
```

특히 오랫동안 검증해야하는 문서나 소프트웨어 배포 서명을 다룬다면 현재 키를 바꾼 뒤에도 과거 데이터를 어떻게 검증할지 생각해야한다.

이번 지원은 그런 실험을 Node.js 기본 API에서 시작할 기반이 생겼다는 의미로 읽으면 좋겠다. 새로운 API가 생긴것과 서비스 전체의 전환 준비가 끝난것은 다르다.

# 마무리

이번 Node.js 업데이트에서 중요한건 양자컴퓨터 때문에 당장 모든 암호가 깨진다는 이야기가 아니다. 런타임에서도 양자내성 알고리즘을 실제로 다루기 위한 지원이 들어오고있다는 점이다.

ML-DSA는 서명 기능이므로 암호화나 키 교환과 구분하고, 기존 시스템과의 호환성부터 확인해야한다.

새 알고리즘을 바로 운영에 넣는것보다 지금 어떤 키와 서명을 어디에서 사용하는지 파악하는게 먼저인것 같다. 암호 기능은 평소에는 잘 안보이는데 바꾸려고하면 생각보다 연결된곳이 많을것 같다..


[2025.08.15 주간 개발 트렌드] Node.js 24.6 정리 (ML-DSA, 양자내성 서명)

독자의 메모