개발 환경 설정
Node.js와 패키지 관리자를 준비하고 Nest CLI로 프로젝트를 생성해 개발 서버의 실행 결과까지 확인합니다.
NestJS의 특징과 아키텍처를 확인했으니, 이제 NestJS 개발 환경을 직접 설정합니다.
환경 준비는 명령어를 외우는 일이 아니라 런타임, 패키지 관리자, CLI, 프로젝트, HTTP 응답의 경계를 차례로 통과하는 과정입니다.
| 경계 | 확인 · 실행 | 통과 신호 | 막히면 먼저 볼 곳 |
|---|---|---|---|
| Node.js 런타임 | node --version |
Nest의 최소 요구를 만족하는 현재 지원 중인 LTS를 사용한다. | Node.js release status, 설치 경로, 새로 연 shell의 PATH |
| 패키지 관리자 | npm --version |
선택한 도구가 실행되고 프로젝트에서는 한 종류의 lockfile을 유지한다. | Node.js·npm 설치, shell 재시작, 팀이 정한 npm·Yarn·pnpm 기준 |
| Nest CLI |
또는 |
new 등 CLI 명령 도움말을 확인한다. |
전역 설치 권한·버전·binary 경로 또는 npx의 네트워크 접근 |
| 프로젝트 scaffold |
또는 |
프로젝트 폴더, package.json, src/와 설치된 의존성이 생긴다. |
생성 위치의 쓰기 권한, 네트워크, 선택한 패키지 관리자 |
| 개발 서버와 첫 응답 | npm run start:dev |
애플리케이션이 설정된 포트에서 요청을 받고 기본 route가 응답한다. | package.json이 있는 현재 폴더, 터미널 예외, 포트 충돌, route 경로 |
- 1. Node.js 런타임
- 확인
node --version - 통과 Nest 최소 요구를 만족하는 현재 지원 중인 LTS다.
- 진단 release status, 설치 경로, 새 shell의
PATH를 본다. - 2. 패키지 관리자
- 확인 교재 기준은
npm --version이다. - 통과 선택한 도구가 실행되고 lockfile을 한 종류로 유지한다.
- 진단 Node.js·npm 설치와 팀의 npm·Yarn·pnpm 기준을 확인한다.
- 3. Nest CLI
- 확인
nest --help또는npx @nestjs/cli@latest --help - 통과
new등 명령 도움말이 나온다. - 진단 전역 설치의 권한·버전·경로 또는
npx네트워크를 본다. - 4. 프로젝트 scaffold
- 실행
nest new my-nestjs-app또는npx @nestjs/cli@latest new my-nestjs-app - 통과 프로젝트 폴더,
package.json,src/와 의존성이 생긴다. - 진단 생성 위치 권한, 네트워크, 패키지 관리자 선택을 본다.
- 5. 개발 서버와 첫 응답
- 실행 프로젝트 폴더에서
npm run start:dev - 통과 설정된 포트의 기본 route가 응답한다.
- 진단 현재 폴더, 터미널 예외, 포트 충돌, route 경로를 본다.
start:dev script는 프로젝트에 설치된 Nest CLI를 사용한다. 정확한 로그 문구보다 어느 경계까지 통과했는지를 확인한다.Node.js와 패키지 관리자 준비
NestJS 애플리케이션은 Node.js에서 실행됩니다. Node.js와 npm을 설치한 뒤 먼저 터미널에서 두 명령이 동작하는지 확인합니다.
node --version
npm --versionNestJS 공식 문서의 최소 요구사항은 Node.js 20 이상입니다. 그러나 최소 버전과 현재 유지보수 중인 버전은 같은 뜻이 아닙니다. 새 환경에는 Node.js 릴리스 표에서 Active LTS 또는 Maintenance LTS로 표시되고 Nest의 최소 요구도 만족하는 버전을 선택하세요.
설치는 Node.js 다운로드 페이지 또는 운영체제에 맞는 버전 관리자를 사용합니다. npm 설치 문서도 Node.js와 npm을 함께 설치하고 관리할 수 있는 버전 관리자를 권장합니다.
이 교재의 명령은 npm을 기준으로 합니다. nest new에서 Yarn이나 pnpm을 선택할 수도 있지만, 한 프로젝트에서는 팀이 정한 패키지 관리자와 lockfile을 일관되게 사용하세요.
Yarn은 더 이상 npm install -g yarn을 기본 설치법으로 안내하지 않습니다. Yarn이나 pnpm을 선택한다면 고정된 전역 설치 예제를 따르기보다 각 도구의 현행 설치 문서를 확인하세요.
Nest CLI 준비
Nest CLI는 프로젝트 scaffold, component 생성, 개발 실행과 build 명령을 제공합니다. CLI를 실행하는 방법은 두 가지이며, 아래 방법 중 하나를 선택합니다.
전역 CLI
Nest 공식 가이드가 기본 흐름으로 사용하는 방법입니다.
npm install --global @nestjs/cli
nest --help전역 설치는 nest 명령을 어디서나 바로 쓸 수 있어 편리하지만, 어떤 CLI 버전을 실행하는지는 사용자가 관리해야 합니다.
전역 설치 없는 실행
Nest CLI 문서는 npx를 관리형 대안으로 안내합니다.
npx @nestjs/cli@latest --help프로젝트 생성 때도 같은 접두사를 사용하면 됩니다. 전역 nest와 npx 명령을 연달아 실행할 필요는 없습니다.
첫 NestJS 프로젝트 생성
프로젝트를 만들 상위 디렉터리에서 선택한 CLI 실행 방식에 맞는 명령 하나를 실행합니다.
전역 CLI를 설치했다면:
nest new my-nestjs-app전역 설치 없이 실행한다면:
npx @nestjs/cli@latest new my-nestjs-appCLI는 사용할 패키지 관리자를 묻고, 선택을 마치면 프로젝트 폴더와 설정 파일, src/의 기본 파일을 만들고 의존성을 설치합니다. 질문의 정확한 문구나 생성 로그 형식은 CLI 버전에 따라 달라질 수 있으므로 교재 예시와 한 글자씩 비교하지 않아도 됩니다.
더 엄격한 TypeScript 설정으로 시작하려면 new 명령에 --strict 옵션을 추가할 수 있습니다.
프로젝트 실행 및 확인
생성된 프로젝트 폴더로 이동해 개발 script를 실행합니다.
cd my-nestjs-app
npm run start:devstart:dev는 생성된 package.json의 script이며 프로젝트에 설치된 로컬 Nest CLI를 사용합니다. 파일 변경을 감시하고 애플리케이션을 다시 컴파일해 재실행하므로, 프로젝트 생성에 사용한 전역 CLI와 개발 서버의 실행 경계를 구분해야 합니다.
고정된 날짜, 프로세스 ID, 로그 문구 대신 다음 상태를 확인하세요.
- 명령을
package.json이 있는 프로젝트 폴더에서 실행했는가 - 터미널에 처리되지 않은 예외 없이 애플리케이션이 HTTP 요청을 기다리는가
src/main.ts에 정의된 포트와 브라우저에서 연 포트가 같은가
기본 scaffold를 바꾸지 않았다면 http://localhost:3000/에서 Hello World! 응답을 확인할 수 있습니다. main.ts나 환경 변수로 포트를 바꿨다면 해당 포트로 접속해야 합니다.
- 프로젝트 폴더 확인
package.json과src/main.ts가 있는 생성된 앱 폴더로 이동한다. - 개발 script 실행
npm run start:dev는 프로젝트에 설치된 로컬 Nest CLI를 호출한다. - 애플리케이션 부팅
Nest가 변경을 감시하고 다시 컴파일하며,
main.ts에 정의된 포트에서 HTTP 요청을 기다린다. - HTTP 응답 확인
브라우저에서 설정된 포트의 기본 route를 열어 응답을 확인한다.
package.json, 부팅하지 못하면 터미널 예외와 포트, 부팅했지만 응답이 다르면 URL과 controller route를 확인한다.Node.js와 패키지 관리자, Nest CLI, 첫 프로젝트 생성, 개발 서버의 HTTP 응답까지 확인했습니다.
다음 절에서는 생성된 모듈, 컨트롤러, 서비스가 요청 처리 흐름에서 맡는 책임을 살펴봅니다.