NestJS에서 provider는 의존성으로 주입될 수 있는 모든 클래스이며, service는 가장 일반적인 종류 — 비즈니스 로직을 담는 클래스입니다. 클래스에 @Injectable()을 표시하면 NestJS의 DI 시스템이 생성하고 주입할 수 있는 provider가 됩니다.
{ } ;
()
{
users = [];
() { .; }
() { ..( u. === id); }
() { ..(data); data; }
}
@Injectable() decorator는 이 클래스가 dependency injection에 참여한다고 NestJS에 알립니다 — controller나 다른 provider에 주입될 수 있습니다.
@Controller("users")
export class UsersController {
// NestJS가 이 파라미터를 보고 UsersService 인스턴스를 자동으로 주입합니다
constructor(private usersService: UsersService) {}
@Get()
findAll() {
return this.usersService.findAll(); // 주입된 service 사용
}
}
의존성을 생성자 파라미터로 선언하면 NestJS가 인스턴스를 생성하고 공급합니다 — new UsersService()를 직접 작성하지 않습니다.
@Module({
controllers: [UsersController],
providers: [UsersService], // DI가 해석할 수 있도록 provider 등록
exports: [UsersService], // 이 module을 import하는 다른 module에서 사용 가능하게 함
})
export class UsersModule {}
Provider는 DI가 인식할 수 있도록 module의 providers 배열에 등록되어야 하며, exports는 다른 module과 공유합니다.
기본적으로 NestJS는 각 provider의 인스턴스를 애플리케이션 전체에 대해 하나만
생성합니다 (singleton scope) → 효율적이고 공유되는 상태.
(다른 scope도 존재합니다: REQUEST-scoped, TRANSIENT — 하지만 싱글톤이 기본입니다.)
Controller → HTTP 처리 (라우팅, 요청/응답)
Service → 비즈니스 로직 처리 (규칙, 데이터 접근, 계산)
→ 분리하면 로직이 재사용 가능(여러 controller가 하나의 service 사용),
테스트 가능(service를 독립적으로 테스트), 체계적이 됩니다.
Provider와 service는 NestJS 아키텍처와 그 dependency-injection 기반 설계의 핵심입니다.
Service는 애플리케이션의 비즈니스 로직을 담으며, controller(HTTP 관심사만 처리)와 분리됩니다 — 이 관심사의 분리는 로직을 여러 controller에서 재사용 가능하고, 독립적으로 쉽게 테스트 가능하며, 잘 체계화되게 만듭니다.
@Injectable()이 클래스를 주입 가능한 provider로 표시한다는 것, provider가 module에 등록되고 생성자를 통해 주입된다는 것(DI가 인스턴스를 대신 생성), 그리고 기본적으로 싱글톤이라는 것을 이해하는 것은 기본적인 일상 NestJS 지식입니다.
Provider/service 패턴은 controller, module과 결합하여 모든 NestJS 애플리케이션의 근간을 이룹니다 — 이를 숙달하는 것은 잘 구조화되고 유지보수 가능한 백엔드를 구축하는 데 필수적이며 프레임워크에서 가장 먼저 배워야 할 개념 중 하나입니다.