NestJS 12의 주요 변화인 ESM 전환, CLI 개선, Vitest와 oxlint 기본 도입, Standard Schema 지원, 그리고 기존 프로젝트에 미칠 영향을 살펴봅니다.
NestJS 12가 다가오고 있습니다. 다음 메이저 릴리스를 향한 작업은 이미 메인 프레임워크 리포지토리에서 진행 중이며, 상위 수준 계획은 이제 이 릴리스 PR에서 공개되어 있습니다.
현재 목표 시점은 2026년 3분기 초이며, 릴리스는 아직 진행 중이지만 방향은 이미 분명합니다. NestJS 12는 ESM을 중심으로 플랫폼을 현대화하고, 기본 툴링을 새롭게 정비하며, 많은 사람들이 기다려 온 몇 가지 새로운 프레임워크 기능을 도입할 예정입니다.
NestJS를 잘 모르신다면, NestJS는 엔터프라이즈급의 효율적이고 확장 가능한 Node.js 애플리케이션을 구축할 수 있도록 도와주는 TypeScript Node.js 프레임워크입니다.
게시: Lei Hwang
무엇이 바뀌는지 살펴보겠습니다.
이번 릴리스는 하나의 고립된 기능에 관한 것이 아닙니다. 패키지 형식, CLI 기본값, 테스트, 린팅, 그리고 일부 프레임워크 내부 요소까지 아우르는 더 넓은 플랫폼 업데이트입니다.
가장 중요한 주제는 다음과 같습니다.
v12에서 가장 큰 아키텍처 변화는 NestJS 코어 패키지 전반에 걸쳐 CommonJS에서 ESM으로 이동하는 것입니다.
‼️ 중요한 미묘한 차이는, 이것이 몇 년 전 ESM 마이그레이션이었을 때보다 훨씬 덜 파괴적일 것으로 예상된다는 점입니다. 최신 Node.js는 이제 require(esm)을 지원하므로, 많은 기존 프로젝트가 대대적인 재작성 없이도 새 패키지를 도입할 수 있을 것입니다. ‼️
그렇다 해도 이것은 여전히 큰 변화이므로, 다음 항목들은 검토해야 한다고 생각하셔야 합니다.
tsconfig.json의 모듈 해석 가정Nest가 최신 Node.js 모듈 체계를 완전히 수용하기를 기다려 왔다면, v12가 바로 그 릴리스입니다.
NestJS는 모든 프로젝트를 하룻밤 사이에 하나의 모듈 형식으로 강제하지 않습니다.
Nest CLI는 CommonJS 프로젝트를 생성할지 ESM 프로젝트를 생성할지 선택하도록 묻습니다. 이는 점진적으로 이동하려는 팀에게 마이그레이션 경로를 훨씬 더 현실적으로 만들어 준다는 점에서 중요한 세부사항입니다.
기본 툴링은 그 선택에 따라 달라집니다.
이렇게 하면 모든 기존 코드베이스에 한 번에 변화를 강요하지 않으면서도, 팀이 새 스택을 실험해 볼 수 있습니다.
또 하나 눈에 띄는 툴링 변화는 NestJS CLI 흐름에서 webpack을 Rspack이 대체한다는 점입니다.
현재 설정이 webpack 전용 동작, 사용자 정의 플러그인, 또는 CLI 통합에 의존한다면, 프리릴리스 패키지를 시험하는 동안 이 영역은 초기에 평가해 봐야 할 부분 중 하나입니다.
릴리스 논의에서 나온 한 가지 점도 짚고 넘어갈 만합니다.
tsc는 여전히 기본 컴파일러로 남아 있습니다. 빌드 파이프라인은 진화하고 있지만 TypeScript 컴파일러가 사라지는 것은 아닙니다. 앞으로는 예정된 TypeScript-Go 버전의 컴파일러도 지원할 계획이지만, 현재로서는tsc가 여전히 기본값입니다.
NestJS 12는 생태계 전반의 Vitest 전환 흐름을 이어갑니다.
내부적으로 프레임워크 리포지토리와 샘플 애플리케이션은 Jest, Mocha, Chai, Sinon에서 Vitest 기반 설정으로 이동하고 있습니다. 새 ESM 프로젝트를 시작하는 개발자에게 이는 기본 제공 테스트 경험이 더 넓은 최신 TypeScript 생태계와 훨씬 더 잘 맞는다는 뜻입니다.
동시에 CommonJS 사용자가 소외되는 것은 아닙니다. CJS 스키매틱은 여전히 Jest 기반 프로젝트를 생성하므로, 기존 팀이 점진적으로 도입하기 더 쉬워질 것입니다. 또한 기존 Jest 기반 프로젝트는 강제 마이그레이션 없이 계속 Jest를 사용할 수 있으므로, 이 변화는 주로 새 프로젝트와 기본 경험에 관한 것입니다!
NestJS 12는 기본적으로 eslint 대신 oxlint를 사용합니다.
새 애플리케이션의 경우 이는 주로 더 빠른 설정과 더 현대적인 린팅 기본값을 의미합니다. 기존 프로젝트의 경우 실질적인 의미는, v12를 사용자 정의 린트 규칙, 로컬 eslint 플러그인, 그리고 더 이상 새 기본값에 맞지 않을 수 있는 리포지토리 규약을 점검하는 좋은 기회로 봐야 한다는 점입니다.
다시 말하지만, 이것은 강제 마이그레이션이 아닙니다. 원한다면 팀은 계속 eslint를 사용할 수 있지만, 기본 경험은 oxlint 쪽으로 이동합니다!
v12에서 가장 흥미로운 프레임워크 수준 추가 사항 중 하나는 @Body(), @Query() 및 유사한 파라미터 데코레이터의 새로운 schema 지원입니다.
새 옵션은 Standard Schema 호환 객체를 받으며, 이를 통해 다음과 같은 라이브러리를 기반으로 한 검증 흐름이 가능해집니다.
이것은 요청 검증에서 class-validator에 대한 일급 대안을 팀에 제공한다는 점에서 의미 있는 변화입니다. 같은 아이디어는 serializer interceptor에도 계획되어 있어, 스키마 주도형 요청 및 응답 처리가 훨씬 더 일관되게 될 것으로 보입니다.
@Post()create(@Body({ schema: createCatSchema }) createCatDto: CreateCatDto) { return this.catsService.create(createCatDto);}
또는 데코레이터 안에서 Zod를 직접 사용하는 방식도 가능합니다.
@Get(':id')findOne(@Param('id', { schema: z.coerce.number().int().positive() }) id: number) { return this.catsService.findOne(id);}
이미 스키마 우선 검증을 중심으로 Nest 애플리케이션을 구축해 왔다면, v12는 매우 중요한 릴리스가 될 것으로 보입니다.
분명히 말씀드리면, 이것은
class-validator를 대체하는 것이 아닙니다! 데코레이터나 클래스 기반 검증에 의존하지 않고도 팀이 스키마 우선 접근 방식을 사용할 수 있게 해 주는 추가 옵션입니다. 문서에서는 대부분의 사용 사례에 대해 여전히class-validator를 기본으로 권장할 예정이지만, 다른 접근 방식을 선호하는 팀에게는 이 새로운 스키마 지원이 반가운 추가 사항입니다.
이 릴리스 PR은 점진적인 프레임워크 변경 사항의 긴 목록도 추적하고 있습니다. 그중 비교적 눈에 띄는 것들은 다음과 같습니다.
HttpExceptionOptions에서 errorCode 전달 지원이 변경들 중 어느 하나만으로 릴리스를 정의하지는 않지만, 함께 보면 v12는 단순히 패키징만 바뀌는 메이저 버전이 아니라 상당한 플랫폼 업데이트처럼 느껴집니다.
좋은 소식은, 더 넓은 ESM 및 툴링 전환을 제외하면 릴리스 계획에서 명시적으로 언급된 파괴적 변경이 경미한 수준에 그친다는 점입니다.
그럼에도 NestJS 12가 프로젝트에 몇 가지 구체적인 방식으로 영향을 줄 것이라고 예상해야 합니다.
다르게 말하면, v12의 가장 큰 이야기는 하나의 큰 런타임 호환성 파괴가 아닙니다. 전반적인 개발 경험의 현대화입니다.
프리릴리스 패키지는 next 태그로 배포되고 있으므로, 커뮤니티는 latest에 도달하기 전에 다가오는 메이저 버전을 테스트할 수 있습니다.
기존 프로젝트에서 새 릴리스를 시험해 보고 싶다면, 사용하는 Nest 패키지를 next에서 설치하면 됩니다.
npm i @nestjs/common@next @nestjs/core@next @nestjs/platform-express@next### For other packages, just replace {package_name} with the package you want to install:### npm i {package_name}@next
다가오는 CLI를 사용해 새 프로젝트를 생성하고 싶다면 다음을 사용하세요.
npx @nestjs/cli@next new
이미 전역으로 설치된 Nest CLI 바이너리가 있다면, 새 생성기를 테스트하는 동안 버전 불일치를 피하기 위해 일치하는 로컬 schematics 패키지도 함께 두는 것이 좋을 수 있습니다.
npm i -D @nestjs/schematics@next
이는 특히 전역 바이너리가 이전 기본값을 가져오는 반면, 로컬 워크스페이스는 v12 프리릴리스 흐름을 대상으로 해야 하는 경우에 중요합니다.
NestJS 12는 프레임워크 내부 변화만을 의미하지 않습니다. 더 넓은 NestJS 생태계 역시 시각적 새 단장을 진행 중이며, 이는 약 9년 만의 첫 대규모 웹사이트 리디자인입니다.
디자인: Jakub Staron
새 웹사이트는 프로젝트의 온라인 존재감을 오늘날의 최신 개발자 플랫폼에 기대되는 방식에 더 가깝게 만듭니다. 더 깔끔하고, 더 빠르며, 더 집중되어 있고, 더 쉽게 탐색할 수 있습니다.
이번 리디자인은 원래 웹사이트가 출시된 이후 NestJS 생태계가 얼마나 많이 성장했는지를 보여 줍니다. 가벼운 프레임워크 프로젝트로 시작했던 것이 이제는 훨씬 더 큰 커뮤니티, 더 넓은 문서 범위, 그리고 다양한 통합 생태계를 갖춘 엔터프라이즈급 Node.js 애플리케이션 구축 플랫폼으로 발전했습니다.
웹사이트 리디자인은 NestJS 12에 포함되는 기술적 변화와는 별개이지만, 그것이 나타내는 큰 방향성은 같습니다. NestJS를 인기 있게 만든 핵심 가치인 생산성, 확장성, 그리고 백엔드 애플리케이션 구축에 대한 구조화된 접근 방식을 유지하면서 프로젝트를 현대화하는 것입니다.
디자인: Jakub Staron
NestJS 12는 분명한 장기 목표를 가진 릴리스로 보입니다. 즉, 마이그레이션 과정을 불필요하게 고통스럽게 만들지 않으면서 프레임워크를 현대화하는 것입니다.
ESM으로의 이동, CJS와 ESM으로 나뉜 새 CLI, 새 ESM 프로젝트용 Vitest, 기본 oxlint, 그리고 라우트 데코레이터에서의 Standard Schema 지원은 모두 같은 방향을 가리킵니다. Nest는 현행 Node.js 및 TypeScript 생태계에 발맞추는 동시에, 기존 팀을 위한 실용적인 경로도 보존하려고 노력하고 있습니다.
Nest 애플리케이션을 유지보수하고 있다면, 지금이 next 패키지를 테스트하고, 툴링에 대한 가정을 검증하며, 릴리스 형태가 아직 만들어지고 있는 동안 문제를 드러내기에 좋은 시점입니다.
진행 중인 작업과 논의는 v12 release PR에서 확인할 수 있습니다.