NestFactory.create() 한 줄에서 시작해 DI 컨테이너, 모듈 시스템, 요청 라이프사이클, 플랫폼 추상화까지 — NestJS 소스코드를 직접 추적하는 시리즈
NestJS로 서버를 만들 때마다 실행하는 NestFactory.create(AppModule) 한 줄. 이 한 줄이 내부에서 DI 컨테이너 생성, 모듈 스캔, 인스턴스 로딩, Express 바인딩까지 5단계를 거친다는 사실을 NestJS 소스코드를 직접 추적하며 확인합니다.
@Injectable() 하나 붙이면 DI가 된다는 건 알지만, 이 데코레이터가 정확히 무슨 일을 하는 걸까요? NestJS 소스코드와 TypeScript 컴파일러 출력을 직접 추적하며, 데코레이터가 '실행'이 아니라 '등록'이라는 사실을 확인합니다.
@Injectable()이 메타데이터를 저장하는 것과 실제로 인스턴스를 생성해서 주입하는 것은 다른 문제입니다. NestContainer, InstanceLoader, Injector — 세 클래스가 협력하여 의존성을 해결하는 과정을 NestJS 소스코드에서 직접 추적합니다.
NestJS 앱은 하나의 거대한 provider 목록이 아니라, @Module()로 나뉜 여러 모듈의 조합입니다. @Module() 데코레이터가 메타데이터를 저장하고, DependenciesScanner가 모듈 그래프를 구축하는 전 과정을 소스코드에서 추적합니다.
NestJS에서 HTTP 요청 하나가 컨트롤러 메서드에 도달하기까지 거치는 6단계를 소스코드로 추적합니다. Middleware, Guard, Interceptor, Pipe, ExceptionFilter — 각 레이어가 왜 존재하고 어떤 순서로 실행되는지 RouterExecutionContext 소스를 통해 확인합니다.
NestJS에서 @CurrentUser(), @Roles() 같은 커스텀 데코레이터가 내부에서 어떻게 동작하는지 소스코드로 추적합니다. createParamDecorator가 메타데이터를 저장하고, Pipe가 값을 추출하고, SetMetadata + Reflector + Guard가 연결되는 전체 흐름을 확인합니다.
NestJS는 Express 위에서 동작한다고 하지만, 정확히 어떻게 감싸고 있는 걸까요? AbstractHttpAdapter 소스코드를 추적하며 Express와 Fastify를 교체 가능하게 만드는 어댑터 패턴의 실체를 확인합니다. NestJS Deep Dive 시리즈 마지막 편.