💡 03. 서비스와 프로바이더 — 비즈니스 로직과 제어의 역전(IoC)

📋 목차

• 📌 이 문서를 읽기 전에
• 🤔 왜 알아야 하는가
• 🏗️ 비유로 먼저 이해하기
• 🧩 서비스 (Service) — 요리를 전담하는 셰프 🟡
• 🧩 의존성 주입 (DI) — 똑똑한 인사관리 시스템 🟢
• 🧪 따라해보기: 실전 CRUD 서비스 깎아보기
• 💼 베스트 프랙티스와 실무 팁
• ⚠️ 에러 해결 카탈로그
• 🗂️ 치트시트
• 📝 마무리 퀴즈

📌 이 문서를 읽기 전에

⏱️ 예상 읽기 시간: 20분 (전체) / 핵심 파트만: 10분

🧳 전제 지식 체크리스트

• 02장 컨트롤러의 역할(요청 수신 및 응답 반환)을 완전히 이해했다.
• TypeScript의 constructor(private readonly ...) 문법이 무엇을 의미하는지 안다.
• (선택) 객체지향 프로그래밍의 '인터페이스(Interface)' 개념을 들어본 적이 있다.

🗺️ 이 문서의 흐름
서비스의 필요성 → DI(의존성 주입)의 강력함 → 실전 DB 연결 코드 작성 → 커스텀 프로바이더 → 순환 참조 에러 해결법

🎯 이 문서를 다 읽으면 할 수 있는 것

• 컨트롤러에서 비즈니스 로직을 완벽하게 분리하여 서비스로 옮길 수 있다.
• "의존성 주입을 왜 쓰나요?" 라는 질문에 당당하게 대답할 수 있다.
• 인터페이스를 활용해 테스트하기 쉬운(Mocking 가능한) 코드를 짤 수 있다.

🤔 왜 알아야 하는가

초보 개발자들은 흔히 "라우터 파놓고 그 안에서 DB도 부르고, 계산도 하고, 에러도 뱉으면 되는 거 아니야?" 라고 착각해.
하지만 로직이 복잡해질수록 컨트롤러는 뚱뚱해지고, 나중에 "결제 로직"만 똑 떼어서 "스케줄러"에서 재사용하고 싶어도 떼어낼 수가 없어.
서비스를 분리하고 DI를 활용하면 레고 블록처럼 코드를 자유자재로 뗐다 붙였다(재사용) 할 수 있고, 무엇보다 테스트 코드 작성이 100배 쉬워져.

🏗️ 비유로 먼저 이해하기

🧒 5살에게 설명한다면?

컨트롤러에 로직을 다 짜는 것 (❌)
= 웨이터가 손님 주문을 받자마자, 본인이 주방으로 달려가서 프라이팬을 잡고 고기를 굽는 거야. 그러다 손님 오면 또 뛰어나가고! 식당이 엉망진창이 되겠지?
서비스를 만들고 의존성을 주입하는 것 (✅)
= 웨이터는 주문만 받고 주방에 토스해. 주방에는 '이탈리안 셰프', '한식 셰프(서비스들)'가 각자의 메뉴표를 들고 대기하고 있어.
웨이터가 출근할 때 "저 오늘 이탈리안 셰프랑 일할게요!" 라고 하면, 식당 지배인(NestJS DI 컨테이너) 이 알아서 그날 컨디션이 제일 좋은 이탈리안 셰프를 웨이터 파트너로 딱! 배정해 주는 거야.

🧩 서비스 (Service) — 요리를 전담하는 셰프 🟡

🎯 이 섹션을 읽고 나면:

• @Injectable()의 의미를 알고, 비즈니스 로직의 위치를 확정할 수 있다.

서비스는 비즈니스 로직 을 담당하는 평범한 TypeScript 클래스야. 단 하나의 차이점은 머리 위에 @Injectable() 이라는 왕관을 쓰고 있다는 점이지.

import { Injectable } from '@nestjs/common';
 
// "이 클래스는 NestJS 메뉴얼에 등록된 정식 셰프입니다!"
@Injectable()
export class UsersService {
 
  // 실제 비즈니스 로직
  calculateTax(amount: number) {
    return amount * 0.1;
  }
}

📖 용어: Provider (프로바이더)
NestJS에서 DI(의존성 주입) 시스템이 관리하는 모든 클래스를 통틀어 '프로바이더'라고 불러. 서비스는 프로바이더의 가장 흔한 90%짜리 형태일 뿐이야. 나중에는 팩토리도 프로바이더고, 설정값 문자열도 프로바이더로 만들 수 있어.

🧩 의존성 주입 (DI) — 똑똑한 인사관리 시스템 🟢

이 파트가 NestJS의 심장이야.

❌ 의존성을 직접 만들면 생기는 비극:

class UsersController {
  // 웨이터가 출근할 때마다 자기 돈으로 셰프를 직접 고용함
  private usersService = new UsersService(new DatabaseService());
}

이러면 DatabaseService가 바뀌면 컨트롤러의 코드까지 함께 뜯어고쳐야 해. 강한 결합(Tight Coupling)의 전형이지.

✅ NestJS의 강력한 DI 해결책:

@Controller('users')
export class UsersController {
  // "지배인님, 저 UsersService 할 줄 아는 사람 한 명 배정해주세요"
  constructor(private readonly usersService: UsersService) {}
}

우리는 단지 constructor의 파라미터 타입표시(: UsersService)만 적어주면 끝이야.
NestJS가 실행될 때, 똑똑한 지배인(IoC Container)이 이 타입을 보고 미리 만들어둔 UsersService 인스턴스를 알아서 쏙 넣어줘.

이걸 제어의 역전(IoC, Inversion of Control) 이라고 불러! 개발자(나)가 new를 안 하고 프레임워크가 알아서 해준다는 뜻이야.

프로바이더의 생명주기 (Scope)

기본적으로 지배인은 셰프를 딱 1명만 고용해서, 모든 웨이터가 돌려쓰게 해 (** 싱글톤, Singleton**). 메모리를 아끼기 위해서지.
하지만 특별한 옵션을 줄 수도 있어.

사용법: @Injectable({ scope: Scope.REQUEST })

🧪 따라해보기: 실전 CRUD 서비스 깎아보기

말보단 코드지. 실무에서 가장 많이 짜게 될, Drizzle ORM을 붙인 유저(주식) 게시판 CRUD 뼈대야.

import { Injectable, NotFoundException } from '@nestjs/common';
import { eq } from 'drizzle-orm';
import { stocks, Stock, NewStock } from '@repo/schema';
 
@Injectable()
export class StocksService {
  // 1. DB 서비스 주입받기
  constructor(private readonly db: DatabaseService) {}
 
  // 2. 생성 (Create)
  async create(data: NewStock): Promise<Stock> {
    const [stock] = await this.db.insert(stocks).values(data).returning();
    return stock;
  }
 
  // 3. 단일 조회 (Read)
  async findBySymbol(symbol: string): Promise<Stock> {
    const stock = await this.db.query.stocks.findFirst({
      where: eq(stocks.symbol, symbol),
    });
 
    // 🔥 중요: 컨트롤러 대신 서비스에서 일찍 에러를 던진다!
    if (!stock) {
      throw new NotFoundException(`증권 심볼 '${symbol}'을(를) 찾을 수 없습니다.`);
    }
    return stock;
  }
 
  // 4. 삭제 (Delete)
  async remove(symbol: string): Promise<void> {
    await this.findBySymbol(symbol); // 있나 확인부터 하고 (없으면 위에서 예외 발생)
    await this.db.delete(stocks).where(eq(stocks.symbol, symbol));
  }
}

🤔 능동적 회상 트리거: 여기서 만약 NotFoundException을 주석 처리하면, 컨트롤러에서 빈 값을 받았을 때 사용자에게 어떤 응답이 내려갈까? (정답: 빈 객체이거나, 200 OK와 함께 내용이 없는 응답이 내려가서 버그를 유발해! 서비스에서 컷 치는 게 맞아.)

💼 베스트 프랙티스와 실무 팁 🟡

1. 거대한 서비스를 더 작게 쪼개기

UsersService 하나가 2,000줄이 넘어가면 위험 신호야. 관련된 서비스들을 더 쪼개고, 그 서비스끼리 서로 주입받게 해.
예: UserAuthService, UserProfileService, UserPointsService

2. 인터페이스 기반 프로그래밍 (커스텀 프로바이더 꿀팁)

외부 메일 발송 서비스(예: SendGrid)를 직접 주입받으면, 나중에 AWS SES로 갈아탈 때 컨트롤러를 다 수정해야 해.

// 1. 규격을 정함
export interface IEmailService {
  send(to: string, content: string): Promise<void>;
}
 
// 2. 구현체
@Injectable()
export class SendGridEmailService implements IEmailService { ... }
 
// 3. 모듈에서 '바꿔치기' 설정 (사용하는 쪽 코드 변경 X)
@Module({
  providers: [
    {
      provide: 'EMAIL_SERVICE',        // 이름표
      useClass: SendGridEmailService,  // 실제 쓸 클래스 (추후 이걸 AwsEmailService로 한 줄만 바꾸면 끝!)
    }
  ]
})

사용할 때는 컨트롤러에서 @Inject('EMAIL_SERVICE') private emailService: IEmailService 로 받으면 돼. 이걸 완벽히 이해하면 넌 더 이상 초보가 아니야.

3. 순환 의존성 해결 (Circular Dependency)

가장 짜증 나는 상황: A 서비스가 B를 주입받고, B가 A를 다시 주입받는 상황. 꼬리를 무는 뱀이지.

• **해법 1 (권장):**A와 B가 공통으로 의존하는 C 서비스를 만들어서 분리한다.
• 해법 2 (코드 수정): 부득이하다면 forwardRef를 써서 프레임워크에 "조금만 기다렸다가 주입해줘" 라고 부탁한다.

@Injectable()
export class ServiceA {
  constructor(
    @Inject(forwardRef(() => ServiceB))
    private serviceB: ServiceB,
  ) {}
}

⚠️ 에러 해결 카탈로그

❌ Nest can't resolve dependencies of the UsersController (?).

언제 나오는가?
앱을 켰는데 터미널에 시뻘건 글씨로 위 내용이 출력되며 서버가 중단됨.

원인:
컨트롤러(웨이터)가 1번 파라미터로(0번 인덱스) 무언가를 주입해달라고 했는데, 해당 모듈의 providers: [] 배열에 그 클래스가 빠져있음.

해결책:

• app.module.ts (또는 해당 기능 모듈) 열기
• providers: [UsersService] 처럼 내가 쓸 서비스를 제대로 등록했는지 체크!

❌ Maximum call stack size exceeded

언제 나오는가?
서버를 켜자마자 무한 루프를 돌면서 치명적인 에러를 뱉음.

원인:
위에서 말한 순환 참조 때문이야. Module A -> Module B -> Module A 무한 루프!

해결책:

1. 어느 모듈끼리 꼬였는지 파악 (forwardRef 적용하기).
2. 가장 좋은 건 설계를 고쳐서 양방향 의존을 단방향으로 쪼개는 것.

🗂️ 치트시트

• 단순 서비스 선언: @Injectable() export class MyService {}
• 의존성 주입 받기: constructor(private readonly appService: AppService) {}
• 모듈에 등록하기: @Module({ providers: [MyService] })
• 싱글톤 끄기: @Injectable({ scope: Scope.REQUEST })

📝 마무리 퀴즈

Q1. 당신이 개발 중인 OrderService에서 장바구니 데이터를 위해 CartService를 가져다 쓰고 싶다. 올바른 방법은?

• A) cartService = new CartService(); 라고 직접 할당한다.
• B) @Injectable() 아래에 속성으로 선언해둔다.
• C) constructor(private readonly cartService: CartService) {} 를 통해 의존성을 주입받는다.

✅ 정답: C

💡 **설명:**NestJS의 핵심 철학은 제어의 역전(IoC)! new 키워드는 절대 쓰지 말고 지배인에게 당당히 요구할 것.

Q2. 다음 중 에러가 발생하는 원인은 무엇인가?

@Injectable()
export class UserService {
  constructor(private readonly authService: AuthService) {}
}
 
@Injectable()
export class AuthService {
  constructor(private readonly userService: UserService) {}
}

✅ 정답: 순환 의존성 (Circular Dependency)
설명: 닭과 달걀의 문제지. 유저 서비스를 만들려다 보니 인증이 필요하고, 인증을 만들려니 유저가 필요해서 무한 대기에 빠져. forwardRef를 쓰거나 공통 서비스로 분리해야 해!

Q3. UserService 파일에는 @Injectable()을 달았고, 컨트롤러에서도 constructor로 올바르게 주입받았다. 그런데도 Nest can't resolve dependencies 에러가 난다면, 어떤 파일의 무슨 코드를 빼먹은 것일까?

✅ 정답: user.module.ts 파일(해당 모듈)의 @Module 데코레이터 안 providers: [UserService] 배열에 등록하는 걸 까먹었음!

🐣 영철이의 퇴근 일기

오늘은 DI가 마법이 아니라 객체 생성 책임을 Nest 컨테이너에 맡기는 약속이라는 걸 배웠다. 예전 같으면 필요한 서비스가 보이면 new로 만들었을 텐데, 이제는 그렇게 하면 테스트, 스코프, 순환 의존성에서 바로 빚이 생긴다는 걸 안다.

영수네 주문 로직처럼 장바구니, 결제, 알림이 서로 얽히는 기능에서는 의존성 방향이 곧 유지보수 난이도였다.

💡 "서비스를 주입받는다는 건 객체를 빌리는 게 아니라, 의존성 방향을 팀이 볼 수 있게 선언하는 일이다."

내일은 Nest can't resolve dependencies를 만나면 어느 모듈이 provider를 소유하고 export해야 하는지부터 확인해야겠다.

🔗 더 알아보기

• NestJS 커스텀 프로바이더 딥다이브
• 의존성 스코프 (Scope) 공식 문서
• 04. DTO와 유효성 검사 파이프