NestJS, 타입 안전성 부족 논란: 개발자들은 어떻게 생각할까?
NestJS의 타입 안전성(Type Safety) 부족 문제를 지적하며, class-validator의 한계와 데코레이터(Decorators)의 문제점을 제기함
실험적 기능(Experimental Features) 사용으로 인한 잠재적 문제와 OpenAPI 스키마(OpenAPI Schema) 생성의 어려움을 언급함
Express 또는 Spring Boot와 같은 다른 백엔드 프레임워크를 선호하는 의견과 NestJS의 장점을 옹호하는 의견이 공존함
NestJS의 대안으로 tRPC 및 oRPC와 같은 타입 안전성을 강조하는 기술을 제시함
class-validator의 타입 안전성 문제
게시물에서는 NestJS의 기본 설정인 class-validator가 타입 안전성을 완벽하게 보장하지 못한다고 지적한다. 특히 데코레이터(Decorators)가 타입스크립트(TypeScript)에서 제대로 타입 정보를 제공하지 못해, 잘못된 타입 정의에도 컴파일 오류가 발생하지 않는다는 점을 문제 삼았다. 이는 개발자가 런타임(Runtime)에 예상치 못한 오류에 직면할 수 있음을 의미한다.
데코레이터(Decorators)의 한계와 복잡성
게시물은 NestJS에서 데코레이터를 사용하는 방식의 복잡성을 비판한다. 특히, `IsArray`, `IsObject`, `ValidateNested` 등 여러 데코레이터를 조합하여 사용해야 하는 경우, 어떤 조합이 올바른지 명확하지 않다고 지적한다. 이러한 설정의 모호함(Ambiguity)은 개발자가 데코레이터를 잘못 사용할 가능성을 높이고, 코드의 유지보수성을 저해할 수 있다.
실험적 기능(Experimental Features) 사용의 위험성
NestJS가 제대로 작동하기 위해 필요한 `experimentalDecorators` 및 `emitDecoratorMetadata` 옵션이 타입스크립트(TypeScript)의 실험적 기능이라는 점을 강조한다. 이러한 기능은 언제든지 변경되거나 제거될 수 있으며, 다른 컴파일러에서는 지원되지 않을 수 있다. 특히, `emitDecoratorMetadata`는 예상치 못한 임포트(Unexpected Imports)를 발생시켜 코드의 안정성을 저해할 수 있다.
OpenAPI 스키마(OpenAPI Schema) 생성의 어려움
NestJS는 OpenAPI 스키마 생성을 지원하지만, 이 과정에서 몇 가지 문제점이 발생한다고 지적한다. 수동으로 `@ApiProperty` 데코레이터를 사용하여 각 필드를 정의하거나, 타입스크립트 컴파일러 플러그인을 사용하는 두 가지 방법이 있지만, 어느 쪽도 완벽한 타입 안전성을 제공하지 못한다. 특히, 컴파일러 플러그인은 특정 컴파일러에 종속되어 이식성이 떨어진다는 단점이 있다.
