CS | JS 프레임워크 정리

🥔 JS 프레임워크 요약

구분	이름	정체	보통 함께 쓰는 것	주 용도
언어	JavaScript	브라우저·서버 어디서나 쓰는 스크립트 언어	–	전반적 웹 개발 전반
언어(타입 시스템)	TypeScript	JS에 정적 타입을 더한 언어	Node.js, React, NestJS, Next.js	대규모/안정성 높은 개발
런타임	Node.js	JS를 서버에서 돌리는 실행 환경	Express, Nest, Prisma 등	백엔드·CLI·실시간 처리
서버 프레임워크(경량)	Express.js	최소한만 제공하는 웹 서버 프레임워크	Node.js, TS, Prisma	API 서버, 소규모/커스텀 자유도
서버 프레임워크(기업급)	NestJS	Angular 철학(모듈/DI) 기반의 구조화 프레임워크	TypeScript, TypeORM/Prisma	대규모 백엔드, 마이크로서비스
프론트 라이브러리	React	UI를 컴포넌트로 만드는 뷰 라이브러리	Vite/CRA, Redux/Zustand	SPA, 복잡한 프론트 UI
풀스택/메타 프레임워크	Next.js	React에 라우팅+SSR/SSG/ISR를 얹은 풀스택	TypeScript, Prisma, Tailwind	SEO, 하이브리드 렌더링, 서버액션

기억 포인트:

• JavaScript/TypeScript는 “언어”, Node.js는 “실행 환경(런타임)”, Express/Nest는 “서버 프레임워크”, React는 “프론트 UI 라이브러리”, Next.js는 “React 기반 풀스택 프레임워크”입니다.

---

🥔 각 기술 상세 정리

JavaScript

• 정체: 브라우저가 이해하는 표준 스크립트 언어(ECMAScript).
• 강점: 생태계가 가장 큼, 러닝 커브 낮음, 어디서든 구동.
• 약점: 타입 안전성 부족(→ TS로 보완).
• 언제: 빠른 프로토타입, 소규모 프로젝트, 학습 초반.

TypeScript

• 정체: JS + 정적 타입(컴파일 단계에서 오류 검출).
• 강점: 대규모 협업/유지보수에 유리, IDE 자동완성/리팩토링 강력.
• 약점: 초기 진입 장벽, 빌드 스텝 필요.
• 언제: 장기 운영, 팀 개발, API/도메인 복잡도가 클 때(추천).

Node.js

• 정체: V8 기반 JS 서버 런타임(이벤트 루프, 비동기 I/O).
• 강점: I/O 위주 작업, 실시간 통신(WebSocket), 한 언어로 풀스택.
• 약점: CPU 바운드에 약함(멀티스레딩·워커로 완화 가능).
• 언제: REST/GraphQL API, 실시간(채팅/알림), BFF(Backend for Frontend).

Express.js

• 정체: 최소 코어 + 미들웨어 조합형 경량 서버 프레임워크.
• 강점: 자유도 최고, 러닝 커브 낮음, 생태계 풍부.
• 약점: 규칙/관례 부족 → 대규모에서 구조가 쉽게 흩어짐.
• 언제: 작은/중간 규모 API, 빠른 PoC, 커스텀 많은 서비스.

NestJS

• 정체: 의존성 주입(DI), 모듈 시스템, 데코레이터 기반의 기업급 구조화 프레임워크.
• 강점: 테스트 용이, 계층적 구조, 마이크로서비스/모노레포 친화.
• 약점: 초기 학습량, 자유도는 Express보다 낮음(대신 일관성↑).
• 언제: 대규모/장기 운영 백엔드, 팀 협업, 도메인 복잡.

React

• 정체: 컴포넌트 기반 UI 라이브러리(상태→UI 동기화).
• 강점: 선언적, 생태계/커뮤니티 최강, 재사용성↑.
• 약점: 라우팅/데이터패칭/상태관리 등은 직접 선택 필요.
• 언제: SPA 개발, 복잡한 인터랙션 UI.

Next.js

• 정체: React + 파일 기반 라우팅 + SSR/SSG/ISR + 서버액션. 풀스택 가능(app router).
• 강점: SEO/성능 우수, 서버와 클라이언트를 한 프로젝트에서, 엣지/서버리스 배포 친화.
• 약점: 개념(SSR/CSR/SSG/ISR, 캐시/라우팅) 학습 필요.
• 언제: 콘텐츠/커머스/블로그/대부분의 서비스 프론트, API까지 한 저장소에서 운영.

🥔 상황별 추천

A. “빠르게 API 서버 만들고 싶어요”

• 소규모/유연함: Express + TypeScript + Prisma
• 중·대규모/팀 협업: NestJS + TypeScript + Prisma/TypeORM
• 실시간 필요 시: 위 조합 + Socket.IO 또는 Nest WebSockets

B. “SEO가 중요하고, 프론트와 백을 한 저장소에서”

• Next.js(React) + TypeScript + 서버액션/Route Handlers + Prisma
• 사내 관리자/콘솔도 함께: Next.js 내에 Admin UI(React)와 API 동거

C. “프론트만 필요(백엔드는 별도)”

• React(SPA) + Vite + Router + 상태관리(Zustand/Redux)
  → 백엔드는 Nest/Express/Spring 등과 분리 배포

D. “기업용 백엔드, 마이크로서비스/도메인 복잡”

• NestJS + TypeScript + 모듈화 + DI + 테스트

  • 메시지 브로커(NATS/Kafka) / 이벤트 주도 아키텍처

E. “CPU 무거운 작업”

• Node만으로 힘들면:

  1. 워커 스레드/큐(BullMQ)로 비동기 처리,
  2. 해당 로직만 Rust/Go로 마이크로서비스 분리.

🥔 비교 요약

서버 사이드

항목	Express.js	NestJS
철학	경량/자유도	규칙/일관성/테스트 용이
규모	소~중	중~대, 엔터프라이즈
학습 난이도	낮음	중간~높음
의존성 주입/모듈	수동 구성	내장(DI/Module/Decorator)
마이크로서비스	직접 구성	공식 지원 패턴 풍부
추천 케이스	빠른 PoC, 커스텀 많은 API	팀 협업, 복잡 도메인, 장기 운영

프론트/풀스택

항목	React(SPA)	Next.js
렌더링	클라이언트 중심(CSR)	SSR/SSG/ISR + CSR 혼합
SEO	상대적으로 약함	강함(서버 렌더링)
라우팅	직접 도입(react-router 등)	파일 기반 내장
데이터 패칭	라이브러리 선택	서버 컴포넌트/서버액션/Route handlers
권장 용도	사내툴/앱형 UI	대부분의 웹 서비스(SEO/퍼포먼스 중요)

🥔 렌더링 용어 미니 사전

• CSR(Client-Side Rendering): 브라우저가 JS로 화면 구성. 초기 로드 느릴 수 있음, SPA.
• SSR(Server-Side Rendering): 서버가 HTML 완성본을 전달. 초기 표시 빠름, SEO 유리.
• SSG(Static Site Generation): 빌드 타임에 정적 HTML 생성. 속도/비용 우수, 변경 적은 콘텐츠.
• ISR(Incremental Static Regeneration): SSG + 부분적 재생성(Next.js). 최신성·성능 균형.

🥔 함께 쓰면 좋은 조합(실무 레시피)

• Next.js + TS + Prisma + PostgreSQL + Auth(NextAuth/Custom)
  → “프론트/백 한 저장소”로 빠르고 견고한 웹 서비스
• NestJS + TS + Prisma + PostgreSQL + Swagger
  → 문서화/테스트/모듈화 깔끔한 기업용 API
• Express + TS + Zod + Prisma
  → 경량이지만 타입 안전, 빠른 PoC
• 로그/모니터링: Pino/Winston, OpenTelemetry, Sentry
• 배포: Vercel(Next.js), AWS Lambda/Fargate, Docker + K8s