[2025.10.24 주간 개발 트렌드] Next.js 16 정리 (Turbopack, 캐시, React Compiler)

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

# Node.js 25에서는 실행 환경의 역할이 더 커졌다

Node.js 버전이 올라오면 보통 V8 성능이나 새로운 문법부터 보게된다. 그런데 서버를 운영하는 입장에서는 어떤 자원에 접근하고 어떤 API를 기본으로 제공하는지도 중요하다.

이번주 10월 15일에 [Node.js 25](https://nodejs.org/en/blog/release/v25.0.0)가 Current 버전으로 공개됐다. V8 14.1과 함께 네트워크 권한 제어, Web Storage 기본 활성화, portable compile cache 등이 들어왔다.

이번주에는 새로운 기능을 바로 운영에 적용하기보다 런타임이 담당하는 범위가 어떻게 넓어지고있는지 정리해보려고 한다.

# 1. 우선 Current와 LTS를 구분하자

새 메이저 버전이 나왔다고 장기 운영의 기본 버전이 바로 바뀌는것은 아니다. 이번 Node.js 25는 Current다.

기존 서비스에서 바로 버전만 바꾸기보다는 의존성과 실행 환경을 검증하는 대상으로 접근하면 좋겠다. 패키지가 설치된다는것과 서버가 같은 동작을 한다는것도 다르다.

```text
검토할 순서
새 기능 확인 → 테스트 실행 → 의존성 호환성 확인
            → 실제 워크로드 비교 → 운영 채택 판단
```

특히 NestJS나 다른 프레임워크를 사용한다면 직접 작성한 코드만 확인해서는 부족하다. 네이티브 애드온이나 빌드 도구, 로깅과 관측 도구도 같은 프로세스 안에서 동작하기 때문이다.

# 2. Permission Model에 네트워크 제어가 들어왔다

Node.js의 Permission Model은 프로세스가 사용할 수 있는 자원을 제한하는 기능이다. 25에서는 네트워크 접근을 허용하는 --allow-net 옵션이 추가됐다.

권한 모델은 --permission으로 활성화해야한다. Node.js 25로 실행하기만 하면 모든 애플리케이션에 제한이 자동 적용되는것은 아니다.

```text
애플리케이션이 사용하는 자원
├── 설정과 데이터 파일 읽기
├── 로그와 임시 파일 쓰기
├── 외부 API와 DB 연결
└── 하위 프로세스와 Worker
```

실제로 적용하려면 위의 항목을 먼저 알아야한다. 직접 호출하는 API뿐 아니라 사용중인 라이브러리가 필요한 자원도 포함된다.

처음부터 모든 접근을 허용해서 오류만 없애기보다는 어떤 작업에서 무엇이 필요한지 확인하면 실행 환경을 이해하는데도 도움이 되겠다.

[권한 모델 문서](https://nodejs.org/download/release/v25.0.0/docs/api/permissions.html)는 이를 신뢰하는 코드의 실수를 줄이는 장치로 설명한다. 악성 코드를 안전하게 실행하는 격리 환경으로 보장하지는 않는다.

따라서 외부에서 받은 코드를 실행하는 서비스라면 컨테이너나 별도의 격리, 운영체제와 네트워크 정책도 함께 설계해야한다. 런타임 옵션 하나가 그 경계를 전부 대신하지는 않는다.

# 3. 서버의 Web Storage는 누구의 저장소일까

이번 버전에서는 Web Storage가 기본 활성화됐다. 브라우저에서 익숙한 이름의 API를 서버에서도 만나게 되는것이다.

하지만 같은 API 이름이 있다고 실행 환경까지 같아지는것은 아니다. 브라우저의 한 사용자 화면과 여러 사용자가 공유하는 서버 프로세스는 구조가 다르다.

예를 들어 로그인한 사용자의 정보를 저장하고 다음 요청에서 읽는 코드를 생각해보자. 서버 전체에서 공유되는 공간을 사용자별 저장소처럼 취급하면 요청 사이에 데이터가 섞일 수 있다.

```text
브라우저에서 익숙한 생각
내 화면 → 내 저장소

서버에서 먼저 확인할것
여러 사용자 → 여러 요청 → 공유 프로세스
```

그래서 실제 저장 수명과 공유 범위, 재시작 시 동작을 확인해야한다. 사용자 세션과 영속 데이터는 서비스의 요구에 맞는 저장소와 키 구조로 관리하는게 좋겠다.

여러 인스턴스로 확장했을때도 생각해보자. 한 프로세스에 저장한 값을 다른 프로세스가 같은 방식으로 읽을 수 있는지는 별개의 문제다.

브라우저와 공통으로 사용하는 코드가 늘어나는건 편하지만 API가 존재하는지 확인하는것 다음에 의미가 같은지도 확인해야한다.

# 4. 성능 개선도 실제 작업으로 비교하자

V8 14.1에는 JSON.stringify 성능 개선과 Uint8Array의 base64/hex 변환 같은 변화가 포함됐다. portable compile cache도 새로 들어왔다.

여기서 JSON 직렬화가 빨라졌다는것과 API 전체가 같은 비율로 빨라진다는것은 다르다. 응답 시간의 대부분을 데이터베이스나 외부 API에서 기다린다면 런타임 연산의 개선은 일부에 해당한다.

```text
요청 처리 시간
인증 → DB 조회 → 데이터 가공 → JSON 직렬화 → 응답
```

서비스에서 어디에 시간을 쓰는지 먼저 보면 비교할 지표를 정하기 쉽다. 큰 응답을 자주 반환하는 API와 작은 작업을 반복하는 CLI는 중요한 부분이 다를 수 있다.

컴파일 캐시도 첫 실행과 재실행을 나눠서 확인하면 좋겠다. 캐시가 준비된 결과만 비교하면 실제 배포 직후의 시작 시간을 잘못 예상할 수 있다.

운영과 같은 컨테이너와 CPU 제한에서 메모리, 시작 시간, 동시 요청의 지연 시간을 같이 기록해보자. 로컬에서 한번 실행한 숫자만으로 전환을 결정하기는 어렵겠다.

# 5. 제거된 API도 함께 확인하자

새 기능이 추가되는 메이저 버전에는 기존 동작의 정리도 따라온다. 이번 버전에서도 SlowBuffer를 비롯한 오래된 API 제거와 변경이 포함됐다.

직접 해당 API를 사용하지 않더라도 의존 패키지 내부에서 호출할 수 있다. 테스트를 실행하고 경고와 오류가 어느 패키지에서 발생하는지 확인하는게 좋겠다.

런타임 변경과 의존성 전체 업데이트를 한꺼번에 진행하면 문제가 생겼을때 원인을 찾기 어렵다. 먼저 같은 의존성으로 실행 버전을 바꾸고 차이를 확인하는 식으로 범위를 줄일 수 있다.

CI에서도 새 버전을 비교 대상으로 추가하면 개발자의 로컬 환경에서만 발견하는 문제를 줄일 수 있겠다. 운영에서 쓰는 버전과 다음 검토 버전을 구분해서 관리하면 좋다.

# 마무리

이번 Node.js 25에서는 JavaScript 실행 성능뿐 아니라 권한과 Web API, 시작 비용까지 런타임이 담당하는 영역이 넓어지고있다.

개인적으로는 네트워크 접근까지 실행 정책으로 표현할 수 있다는 부분이 눈에 들어왔다. 동시에 권한 모델이 제공하는 범위와 격리 환경의 역할을 구분하는게 중요해보인다.

우선 Current 버전에서 우리 코드와 의존성이 어떻게 동작하는지 확인해보면 좋겠다. 새 버전이 나왔다는 이유보다 어떤 문제를 해결하는지부터 살펴봐야겠다..


[2025.10.17 주간 개발 트렌드] Node.js 25 정리 (권한 모델, Web API, Current)

독자의 메모