NestJS, Standard Schema 지원을 통한 검증 라이브러리 유연성 확보 방안 논의

핵심 기술: NestJS 생태계에서 Class-Validator 외의 다양한 스키마 검증 라이브러리(Zod, Yup, Valibot 등)를 더욱 유연하게 통합하기 위한 논의가 진행 중입니다. Standard Schema라는 공통 인터페이스 도입을 통해 개발자가 검증 라이브러리 선택의 폭을 넓히고, NestJS의 공식 Pipe 지원을 기대하는 내용입니다.

기술적 세부사항:
* 현재 문제점: NestJS는 기본적으로 Class-Validator에 의존하며, 다른 라이브러리를 사용하려면 직접 Pipe를 구현하거나 써드파티 라이브러리에 의존해야 합니다.
* Standard Schema 등장: 다양한 스키마 검증 라이브러리들의 공통 인터페이스를 정의하여 라이브러리 간 호환성을 높이고 일관된 사용 경험을 제공합니다.
* NestJS의 잠재적 지원: Standard Schema 인터페이스를 만족하는 공식 Pipe 지원 제안이 논의되고 있습니다. 이를 통해 개발자는 검증 라이브러리 선택만 하면 됩니다.
* 도입의 장벽: Class-Validator가 아직 Standard Schema를 공식 지원하지 않으며, NestJS가 Class-Validator 파이프라인을 유지하면서 새로운 Pipe를 추가하는 것에 대한 breaking change 우려 및 유지보수 부담이 제기됩니다.
* 대안 논의: 기존 ValidationPipe를 유지하며 Standard Schema를 지원하는 새로운 공식 Pipe를 별도로 추가하는 방안이 제시되었습니다.
* 현실적 전망: Class-Validator 측의 움직임이 활발하지 않고, NestJS 메인테이너 입장에서는 추가적인 Pipe 관리 부담과 향후 Class-Validator의 Standard Schema 지원 시 발생할 수 있는 포지셔닝 애매함 때문에 core에 새로운 Pipe를 추가할 가능성은 낮게 전망됩니다.

개발 임팩트:
* 개발자는 선호하는 검증 라이브러리를 NestJS 프로젝트에 보다 쉽게 통합할 수 있습니다.
* 타입 안전성 및 코드 재사용성이 향상될 수 있습니다.
* NestJS의 검증 로직 유연성이 증대됩니다.

커뮤니티 반응:
* GitHub 이슈에서 Standard Schema 지원에 대한 제안이 있었고, 이에 대한 개발자들의 의견 교환이 이루어졌습니다.
* 기존 Class-Validator 의존성 및 breaking change에 대한 우려, 써드파티 라이브러리 의존성의 이점을 비교하는 코멘트 등이 있었습니다.
* Class-Validator 업데이트의 비활성화를 지적하는 의견도 있었습니다.