Nestjs를 쓰고 느낀점

회사 업무로 인해 NestJS를 사용하게 되었다. 클라이언트와 서버가 같은 언어(TypeScript)를 사용한다는 장점이 있었고 동료분들이 전부 js개발자여 해당 언어를 골라 개발을 하게 되었다. 간단히 단점에 대해서 적는다면 다음과 같은것이 있다고 생각한다.

NestJS의 단점

1. 모듈 시스템의 강제성

NestJS는 스프링(Spring)처럼 모듈 시스템을 도입했다. 이론적으로는 모듈 기반 아키텍처가 유지보수성과 확장성을 높이는 데 유리할 수 있지만, 실제 개발 과정에서는 오히려 자유도를 제한하는 요소가 되었다.

모듈 기반 구조는 코드의 뼈대 자체가 모듈이 되어야 한다는 점에서 개발자에게 지나치게 많은 제약을 부여한다. 특정 기능을 추가하려고 할 때도 반드시 모듈을 만들어야 하며, 풀더 구조도 강제화가되어 개발자의 자유도를 오히려 뺏는다

2. 타입이 있어도 결국은 반쪽짜리 타입

TypeScript는 JavaScript의 문제를 해결하기 위해 등장한 언어다. 가장 대표적인 개선점은 정적 타입 시스템을 제공하는 것이다.

이를 통해 코드 작성 시점에 오류를 잡을 수 있어 유지보수성과 개발 생산성이 향상된다. 문제는 반쪽 짜리 정적 타입 시스템이라는 점이다. 덕분에 웹개발에서는 특수한 케이스가 발생한다.

웹개발 지식은 그리 어려운 개념이 많이 없다. 하지만 운영의 난이도가 웹개발의 99%라고 생각한다. 그래서 어떻게든 IDE를 최대한 활용할려고 하는 습관이 있어 service에 값을 넘길때 DTO나 HTTP의 request,response을 전부 따로 class로 만든다.

예로 다음과 같은 AAADto가 있고 BBBResponse라는 객체가 있다고 하자. 아래의 코드를 실행시켜보자

class BBBResponse {
    a!: number;
    b!: number;
}

class AAADto {
    a!: number;
    b!: number;
    c!: number;
}

function main() {
    let objB = new AAADto();
    objB.a = 1;
    objB.b = 2;
    objB.c = 3;
    let objA: BBBResponse = objB;
    console.log(objA); 

}

main();

결과는 BBB { a: 1, b: 2, c: 3 } 가 나온다. 예상은 BBB { a: 1, b: 2 }

이지만 그 이유는 단순한데 타입스크립트는 TypeScript에서는 타입이 아니라 구조(프로퍼티의 형태)를 기준으로 타입 검사를 수행한다.

TypeScript를 사용하는 주된 이유 중 하나인 "정적 타입 검증"의 장점을 퇴색시키는 요소가 된다.