L0 런타임 & 프레임워크 입구
L0 런타임 & 프레임워크 입구
섹션 제목: “L0 런타임 & 프레임워크 입구”분류: Layer 0 - 런타임 & 프레임워크 기초
핵심 질문
섹션 제목: “핵심 질문”NestJS 서버를 이해할 때, 무엇을 Node.js 실행 환경의 문제로 보고 무엇을 TypeScript와 프레임워크의 객체 구성 문제로 봐야 하는가?
3줄 요약
섹션 제목: “3줄 요약”- L0는 서버 코드가 언제 실행되는지 보는 Node.js 런타임 축과, 객체가 어떻게 구성되는지 보는 TypeScript → NestJS 축으로 나뉜다.
- 두 축은 서로의 필수 선행 경로가 아니다. 지금 해결하려는 질문에 맞는 축부터 시작한다.
- 두 축은 NestJS 애플리케이션이 부팅된 객체 그래프로 요청과 이벤트를 처리하는 지점에서 합쳐진다.
1. 이 레이어는 무엇을 가능하게 하나
섹션 제목: “1. 이 레이어는 무엇을 가능하게 하나”L0를 지나면 NestJS 서버를 하나의 덩어리로 보지 않고 두 층으로 나눠 질문할 수 있다.
첫 번째는 런타임 층이다. 요청이 몰릴 때 왜 어떤 코드는 다른 요청까지 늦추는지, 기다리는 작업과 계산하는 작업은 무엇이 다른지 판단하는 층이다.
두 번째는 프레임워크 층이다. TypeScript로 적은 타입과 데코레이터 정보 중 무엇이 실행 시점에 남는지, NestJS가 그 정보를 이용해 객체를 만들고 연결하는지 판단하는 층이다.
실무에서는 두 층의 실패가 비슷한 “서버가 느리다” 또는 “앱이 뜨지 않는다”로 보일 수 있다. L0의 목적은 세부 API를 외우는 것이 아니라, 문제를 런타임 실행 문제와 프레임워크 구성 문제로 먼저 분리하는 데 있다.
선행 관점의 한계와 이 레이어의 등장
섹션 제목: “선행 관점의 한계와 이 레이어의 등장”함수와 클래스 문법만으로는 서버가 왜 한 작업 때문에 느려지는지, 객체가 왜 생성되지 않는지 설명하기 어렵다. 런타임과 프레임워크를 한 경로로만 익히면 실행 지연과 구성 실패를 같은 종류의 문제로 오해하기 쉽다. 그래서 L0는 Node.js 실행 모델과 TypeScript·NestJS 객체 구성 모델을 두 학습 축으로 나눠 제시한다. 이 관점은 문제의 원인이 실행 방식에 있는지 객체 구성에 있는지 먼저 구분하고, 필요할 때 두 축을 합쳐 판단하게 한다.
2. 한 줄 선행 경로의 한계 - 두 학습 축과 합류 지점
섹션 제목: “2. 한 줄 선행 경로의 한계 - 두 학습 축과 합류 지점”Node.js 런타임 축
섹션 제목: “Node.js 런타임 축”이 축의 질문은 “실행 중인 Node.js 프로세스가 여러 작업을 어떻게 번갈아 처리하는가”다. 비동기 코드, I/O 대기, CPU 점유가 서버 응답성에 어떤 차이를 만드는지 알고 싶을 때 content/topics/L0/nodejs-event-loop.mdx부터 읽는다.
이 문서는 TypeScript 컴파일 원리나 NestJS DI를 먼저 알아야 읽을 수 있는 토픽이 아니다. Node.js 서버의 동시성과 지연을 이해하는 독립 입구다.
TypeScript → NestJS 프레임워크 축
섹션 제목: “TypeScript → NestJS 프레임워크 축”이 축의 질문은 “소스에 적은 선언이 어떻게 실행 가능한 객체 그래프가 되는가”다. content/topics/L0/typescript-compiler-basics.mdx에서 시작해 content/topics/L0/di-ioc.mdx로 이어진다. 컴파일 결과에 남은 런타임 정보가 NestJS의 객체 생성과 주입 판단으로 연결되기 때문에 이 둘은 실제 선수 관계다.
content/topics/L0/nestjs-discovery-module.mdx은 그다음 선택 심화다. 이미 만들어진 객체 그래프에서 표시된 대상을 찾아 자동 등록하는 구조가 필요할 때 읽는다. 일반적인 NestJS DI를 이해하는 데 반드시 Discovery까지 끝낼 필요는 없다.
합류 지점
섹션 제목: “합류 지점”두 축은 학습 순서가 아니라 실행 중인 NestJS 애플리케이션에서 합쳐진다. 프레임워크 축이 부팅 과정에서 객체 그래프와 연결 규칙을 준비하면, 런타임 축은 그 객체들의 코드가 요청과 이벤트를 처리하도록 실행한다.
따라서 “주입할 객체를 찾지 못해 시작하지 못한다”면 프레임워크 축을 먼저 보고, “시작은 했지만 한 작업이 다른 요청까지 늦춘다”면 런타임 축을 먼저 본다. 서버 전체의 부팅과 응답 지연을 함께 설명해야 할 때 두 축을 합쳐 읽는다.
3. 들어가기 전 최소 선수지식
섹션 제목: “3. 들어가기 전 최소 선수지식”L0 전체를 시작하기 위해 다른 레이어를 먼저 끝낼 필요는 없다. 아래 전제만 현재 선택한 축에 맞춰 확인하면 된다.
- 공통 최소 전제: JavaScript/TypeScript의 함수, 객체, 클래스 코드를 읽고 Node.js 프로젝트가 소스 코드를 실행한다는 정도를 안다.
- 런타임 축 전제: Promise와
async/await이 작업 완료를 기다리는 문법이라는 정도면 충분하다. 실행 순서나 내부 큐는 첫 토픽에서 배운다. - 프레임워크 축 전제: 클래스와 생성자, 데코레이터가 코드에 표시를 붙인다는 정도면 충분하다. 컴파일러 내부나 NestJS 컨테이너 동작을 미리 알 필요는 없다.
- 첫 회독 경계: 운영 명령, 튜닝 값, 컴파일러 내부 단계, 프레임워크 내부 API는 준비 조건이 아니다. 각 일반 토픽에서 개념과 실패 신호를 먼저 잡는다.
저장소 안에 L0보다 앞선 선수 레이어는 없다. JavaScript 기본 문법이나 Promise 자체가 낯설다면 이를 억지로 L0 문서에서 보충하기보다 해당 언어 기초를 먼저 확인한 뒤 돌아오는 편이 낫다.
4. 핵심 경로와 선택 경로
섹션 제목: “4. 핵심 경로와 선택 경로”| 지금 필요한 판단 | 추천 경로 | 이 경로를 고르는 이유 |
|---|---|---|
| Node.js 서버의 지연과 동시성을 구분하고 싶다 | Node.js Event Loop | 런타임 축만 독립적으로 읽어도 I/O 대기와 CPU 점유를 나눌 수 있다. |
| NestJS가 객체를 만들고 주입하는 원리를 알고 싶다 | TypeScript 컴파일 원리 → DI / IoC | 런타임에 남는 정보와 그 정보를 사용하는 객체 그래프가 실제 선수 관계로 이어진다. |
| 데코레이터 기반 자동 등록 구조가 필요하다 | TypeScript 컴파일 원리 → DI / IoC → Nest.js Discovery Module | Discovery는 이미 만들어진 Provider 그래프와 메타데이터를 전제로 한다. |
| NestJS 서버의 부팅과 요청 처리 전체를 설명하고 싶다 | Node.js Event Loop + TypeScript 컴파일 원리 → DI / IoC | 런타임 실행과 프레임워크 구성을 각각 잡은 뒤 애플리케이션 실행 지점에서 합친다. |
여기서 +는 앞 문서를 끝내야 다음 문서를 읽을 수 있다는 뜻이 아니다. 두 독립 축의 관점을 함께 사용한다는 뜻이다.
5. 첫 네 토픽을 읽는 순서와 이유
섹션 제목: “5. 첫 네 토픽을 읽는 순서와 이유”아래 순서는 저장소의 learning_order를 따른다. 다만 10번과 20번 사이에는 선수 관계가 없고, 40번은 필요에 따라 미뤄도 된다.
L0 추천 학습 지도
- 10. Node.js Event Loop - 런타임 축의 독립 입구
서버가 대기와 계산을 어떻게 다르게 다루는지 먼저 본다. 지연·동시성 판단이 당장 필요하지 않다면 프레임워크 축을 먼저 시작해도 된다.
- 20. TypeScript 컴파일 원리 - 프레임워크 축의 입구
타입과 데코레이터 정보가 실행 시점에 어떤 형태로 남는지 잡는다. Event Loop를 끝내지 않아도 시작할 수 있다.
- 30. DI / IoC - 프레임워크 축의 핵심
TypeScript 문서에서 본 런타임 정보를 NestJS가 객체 생성, 연결, 모듈 경계 판단에 어떻게 사용하는지 이어서 본다.
- 40. Nest.js Discovery Module - 선택 심화
DI가 만든 객체 그래프에서 표시된 대상을 찾아 자동 등록하는 구조가 필요할 때 확장한다. 일반 DI 학습의 필수 종착점은 아니다.
처음부터 네 문서를 모두 같은 깊이로 읽을 필요는 없다. 서버 응답 지연이 현재 문제라면 10번을 먼저 끝내고, NestJS 구조 이해가 우선이라면 20번과 30번을 이어 읽는다. 두 질문이 만나는 작업을 맡았을 때 나머지 축을 보충한다.
6. 어렵게 느껴지는 지점과 돌아갈 곳
섹션 제목: “6. 어렵게 느껴지는 지점과 돌아갈 곳”| 막히는 느낌 | 보통 부족한 전제 | 돌아갈 문서 |
|---|---|---|
| L0에서 무엇부터 골라야 할지 모르겠다 | 레이어와 현재 목표를 연결하는 기준 | content/roadmap.md, 이 문서의 “핵심 경로와 선택 경로” |
| 비동기 문법과 서버 동시성이 같은 말처럼 보인다 | 런타임 축의 목표와 첫 독서 경계 | content/topics/L0/nodejs-event-loop.mdx의 “첫 독서의 목표와 경계” |
| 타입이 사라진다는데 NestJS가 타입을 읽는다는 말이 모순처럼 보인다 | 타입 공간과 런타임 정보의 구분 | content/topics/L0/typescript-compiler-basics.mdx |
Provider, Token, Module이 한꺼번에 섞인다 | NestJS 객체 그래프의 기본 역할 구분 | content/topics/L0/di-ioc.mdx의 “핵심 용어를 먼저 잡기” |
| Discovery 문서의 스캔 대상과 메타데이터가 너무 추상적이다 | TypeScript 메타데이터와 DI 컨테이너의 연결 | content/topics/L0/typescript-compiler-basics.mdx → content/topics/L0/di-ioc.mdx |
| Node 문제인지 NestJS 구성 문제인지 판단하기 어렵다 | 실행 중 지연과 부팅 중 구성 실패의 구분 | 지연이면 content/topics/L0/nodejs-event-loop.mdx, 부팅·주입 실패면 content/topics/L0/di-ioc.mdx |
7. 들을 준비가 된 상태
섹션 제목: “7. 들을 준비가 된 상태”L0 Readiness check
- Node.js 런타임 축과 TypeScript → NestJS 프레임워크 축이 서로의 필수 선행 경로가 아니라고 설명할 수 있다.
- 서버가 느린 문제와 애플리케이션이 부팅하지 못하는 문제를 먼저 다른 축에서 살펴봐야 함을 안다.
- NestJS 객체 생성 원리를 배우려면 TypeScript 컴파일 원리 다음에 DI / IoC를 읽어야 하는 이유를 말할 수 있다.
- Discovery Module은 일반 DI의 필수 다음 단계가 아니라 자동 탐색이 필요할 때 고르는 선택 심화임을 안다.
- 막힐 때 현재 어려움에 맞는 실제 문서 경로를 하나 고를 수 있다.
모든 항목에 완벽히 답할 필요는 없다. 첫 번째와 마지막 항목이 잡혔다면 원하는 축의 첫 문서로 들어갈 준비가 된 상태다.
8. 이 레이어의 핵심 한 문장
섹션 제목: “8. 이 레이어의 핵심 한 문장”L0는 하나의 긴 선수 경로가 아니다. Node.js가 코드를 실행하는 방식과 TypeScript·NestJS가 객체를 구성하는 방식을 별도 축으로 배운 뒤, 실행 중인 NestJS 애플리케이션에서 두 관점을 합치는 레이어다.