NestJS는 왜 TypeScript를 사용할까?

NestJS를 사용할 때 JavaScript가 아닌 TypeScript를 고집하는 이유는 단순히 '유행' 때문이 아닙니다. NestJS 자체가 TypeScript의 기능을 최대한 활용하도록 설계된 프레임워크이기 때문이죠.

만약 NestJS에서 TypeScript를 빼버린다면, 마치 엔진(NestJS)은 슈퍼카인데 연료(JS)가 저옥탄가인 상황과 비슷해집니다. 그 구체적인 이유는 다음과 같습니다.

---

1. 데코레이터(Decorators) 기반의 설계

NestJS 코드를 보면 @Controller(), @Get(), @Injectable() 같은 코드들이 자주 보이죠? 이것이 바로 데코레이터입니다.

• TypeScript의 특권: 데코레이터는 클래스와 메서드에 메타데이터를 추가하는 기능으로, TypeScript에서 아주 강력하게 지원합니다.
• 가독성과 구조화: 복잡한 설정 파일 대신 코드 바로 위에 @ 기호를 붙여 이 클래스가 어떤 역할을 하는지 직관적으로 정의할 수 있습니다.

---

2. 의존성 주입(Dependency Injection, DI)의 마법

NestJS의 핵심은 객체를 직접 생성하지 않고 프레임워크가 관리해주는 '의존성 주입'입니다.

• 타입 기반 주입: TypeScript에서는 constructor(private userService: UserService)라고만 써도, UserService라는 타입을 보고 NestJS가 알아서 해당 객체를 찾아 넣어줍니다.
• JS의 한계: JavaScript는 타입 정보가 없기 때문에, 일일이 이름을 지정하거나 복잡한 설정을 추가해야 하므로 이 편리함을 누리기 어렵습니다.

---

3. 강력한 아키텍처와 객체지향 프로그래밍(OOP)

NestJS는 Angular의 영향을 받아 만들어졌으며, 객체지향적인 아키텍처를 권장합니다.

• 인터페이스와 추상 클래스: 대규모 백엔드 시스템에서는 코드의 규격(Interface)을 맞추는 것이 중요합니다. TypeScript를 쓰면 서버의 각 계층(Controller, Service, Repository) 간의 데이터 흐름을 엄격하게 관리할 수 있습니다.
• 실수 방지: API 응답 값의 구조를 미리 정의해두면, 엉뚱한 필드명을 프론트엔드에 전달하는 대참사를 막을 수 있습니다.

---

4. 안정적인 확장성 (Scalability)

NestJS의 이름(Nest) 자체가 '확장 가능한(Scalable)' 구조를 지향합니다.

• 대규모 팀 협업: 수십 명의 개발자가 하나의 서버 코드를 건드릴 때, TypeScript의 타입 체크는 서로의 코드를 망가뜨리지 않게 지켜주는 최후의 보루가 됩니다.
• 문서화 자동화: Swagger 같은 도구를 쓸 때, TypeScript 타입을 기반으로 API 문서를 자동으로 생성해주는 기능이 매우 강력합니다.

---

요약하자면

"NestJS를 JavaScript로 쓰는 것은 가능하지만, NestJS가 제공하는 진정한 생산성과 안정성의 80%를 포기하는 것과 같습니다."