NestJS와 Next.js로 구축하는 풀스택 이커머스 아키텍처 도입기

2026. 2. 5.
NestJSNext.jsPostgreSQLPrismaMonorepo

1. 전자상거래 플랫폼, 어떤 기술 스택으로 시작해야 할까?

단순한 블로그가 아닌 사용자, 상품, 주문, 결제, 리뷰 등 복잡한 비즈니스 로직이 얽혀있는 전자상거래 플랫폼을 기획하면서 기술 스택 선정에 많은 고민이 있었습니다.

이번 포스팅에서는 안정적인 서비스 운영과 효율적인 팀 협업을 위해 선택한 아키텍처와 그 "이유"에 대해 이야기해보려 합니다.

2. 프론트엔드: SEO와 성능을 위한 Next.js

프론트엔트는 비교적 쉽게 학습 가능하고 생태계가 압도적인 React를 기반으로 하되, 다음과 같은 이유로 Next.js 프레임워크를 선택했습니다.

  • 포기할 수 없는 SEO (SSR & SSG): 쇼핑몰에서 상품 상세 페이지의 검색 엔진 노출(SEO)은 매출과 직결됩니다. 서버 사이드 렌더링과 정적 사이트 생성을 활용하면 검색 엔진 봇이 페이지 콘텐츠를 완벽하게 수집할 수 있습니다.
  • 이미지 최적화: next/image 컴포넌트는 수많은 상품 이미지를 자동으로 최신 포맷(WebP 등)으로 변환해주고, 디바이스 해상도에 맞춰 적절한 크기로 리사이징하여 로딩 성능을 비약적으로 높여줍니다.

3. 백엔드: 왜 Spring 대신 NestJS를 선택했을까?

백엔드 프레임워크를 정할 때 Java/Spring 진영과 Node.js 진영 사이에서 결론적으로 NestJS를 선택했습니다.

Express의 자유로움이 독이 될 때

Node.js 생태계에서 가장 유명한 Express는 자유도가 높지만, 프로젝트가 커질수록 아키텍처가 무너지고 '스파게티 코드'가 될 확률이 높습니다. 반면 NestJS는 모듈, 컨트롤러, 서비스 기반의 아키텍처를 강제하여 복잡성을 체계적으로 관리할 수 있습니다.

팀 협업과 코드 일관성

NestJS는 의존성 주입(DI), 데코레이터 등 명확한 디자인 패턴을 제시합니다. 누가 개발하든 비슷한 구조의 코드를 작성하게 되므로 코드 리뷰가 수월해지고 유지보수성이 크게 향상됩니다.

Context Switching 비용 최소화 (Why not Spring?)

  • 단일 언어의 힘: 프론트엔드 개발에 익숙한 팀원들에게 Java, Spring, JVM 생태계를 학습시키는 것은 런닝 커브를 과도하게 높이는 일입니다. Typescript 하나로 풀스택을 구성하면 프론트와 백엔드 전환 시 발생하는 인지 부하(Context Switching)를 획기적으로 줄여 생산 속도를 극대화할 수 있습니다.
  • 빠른 피드백 루프: NestJS는 Spring에 비해 프로젝트 재시작 및 빌드 속도가 뛰어나 피드백 루프가 짧습니다. 방대한 NPM 생태계를 통해 필요한 기능을 즉각 도입할 수 있는 점도 큰 장점입니다.

성능 이슈 대비 (Fastify 마이그레이션)

추후 트래픽이 몰려 성능 이슈가 발생하더라도, 설정 약간의 변경으로 내부 엔진을 Express에서 Fastify로 교체할 수 있는 유연성을 확보했습니다.

4. 데이터베이스: 이커머스의 심장, PostgreSQL과 Prisma

RDBMS의 필요성과 ACID 트랜잭션

주문 시스템에서 결제, 재고 감소 로직 등은 반드시 하나의 원자적 단위(트랜잭션)로 묶여야 합니다. 하나라도 실패하면 롤백되어 정합성을 지켜야 합니다. PostgreSQL은 ACID 트랜잭션을 완벽히 지원하며 촘촘히 엮인 데이터의 JOIN 처리에 최적화되어 있습니다.

PostgreSQL의 강력한 JSONB 활용

상품별 특수 옵션(색상, 사이즈, 커스텀 속성) 같은 비정형 데이터를 유연하게 다루기 위해 JSONB 타입을 도입했습니다. {"color": "blue", "size": "L"} 같은 옵션을 JSONB 컬럼에 저장하고 인덱싱할 수 있어, MySQL보다 빠르고 강력한 도구를 제공합니다.

타입 공유의 끝판왕, Prisma ORM

Prisma는 DB 스키마를 기반으로 완벽한 TypeScript 타입을 자동 생성해 줍니다. 백엔드에서 생성된 이 타입을 프론트엔드(Next.js)와 완벽하게 공유하여 런타임 오류가 발생할 확률을 극단적으로 낮출 수 있었습니다.

5. 인프라 및 아키텍처 환경 구성

  • 모노레포 (Monorepo): pnpm workspace와 Turborepo를 도입했습니다. (개발기: 모노레포 초기 세팅 시 공통 패키지의 dependencies와 devDependencies 분류 차이로 인해 TS 서버 속도나 동작에 이슈가 발생하는 경험을 겪고 수정하기도 했습니다.)
  • 인프라: Docker와 Docker Compose로 로컬 환경 파편화를 막고, GitHub Actions를 통해 CI/CD 파이프라인을 완전 자동화했습니다.
  • Git Hooks & 로깅: husky를 활용해 commit 전 Lint/Test를 강제하고, Winston을 도입해 파일 저장 및 포맷팅이 가능한 시스템을 구축했습니다.

결과적으로 이 기술 스택은 엔터프라이즈급 견고한 구조적 장점을 가져오면서도, 빠른 개발 속도와 유연성을 동시에 취할 수 있는 최적의 조합이라고 확신합니다.

NestJS와 Next.js로 구축하는 풀스택 이커머스 아키텍처 도입기 | NSRBSG 개발 블로그