본문 바로가기
개발

1인 커머스 플랫폼 개발기 #02 - 기술스택 선정

by owel.dev 2026. 5. 3.

MVP 범위와 확장을 위한 설계 원칙을 정했으니, 이번 글에서는 실제로 어떤 기술 스택으로 개발할지 정리해 보겠습니다.

프론트엔드

1. 언어 - TypeScript

프론트엔드 언어 후보는 JavaScript와 TypeScript 두 가지였고, TypeScript를 선택했습니다.

 

TypeScript의 장점은 다음과 같습니다.

  • null safety, 타입 강제 변환에 의한 에러 등을 런타임이 아닌 컴파일 타임에 감지할 수 있습니다.
  • 타입 정보가 코드의 문서 역할을 해서 코드 가독성이 올라갑니다.
  • 함수 시그니처나 객체 타입의 구조를 변경했을때 관계된 다른 코드에 문제가 생기지 않는지 컴파일러가 자동으로 검사해 주므로, 수정 비용이 낮아집니다.

커머스 플랫폼은 코드베이스가 매우 커질 가능성이 높고 실제 사용자에게 배포될 애플리케이션이므로, 위 장점들이 중요하다고 판단했습니다.

2. 라이브러리 및 프레임워크 - React + Next.js

라이브러리 후보로는 jQuery, React, Vue 등이 있었으며, 그중 React를 선택했습니다.

  • 선언적 UI: 데이터 변경에 따라 수많은 UI가 함께 변경되어야 하는 커머스 환경에 잘 맞습니다.
  • 컴포넌트 모델: 상품 카드, 버튼처럼 다양하고 재사용되는 UI가 많은 커머스 환경에 잘 맞습니다.
  • 단방향 데이터 흐름: 한 데이터에 여러 UI가 빈번하게 연결되는 커머스 환경에서 디버깅이 수월합니다.
  • 업계에서 대부분 사용하고 있다는 점: 업계에서 가장 많이 사용되어 자료가 풍부하고, 보안 및 결함 패치가 우선적으로 적용됩니다.

React만 단독으로 사용할 수도 있지만, 이 프로젝트에서는 Next.js 프레임워크 위에서 사용하기로 했습니다. 이유는 다음과 같습니다.

  • SEO(검색 엔진 최적화): 커머스는 검색엔진을 통해 유입되는 트래픽이 중요합니다. React의 CSR 방식은 초기 HTML에 내용이 없기에 검색엔진 인덱싱에 불리하지만, Next.js의 SSR 기능은 서버에서 완성된 HTML을 응답해 SEO에 유리합니다.
  • OG(Open Graph) 태그: SNS 공유 기능 사용 시 보이는 미리보기 화면은 자바스크립트를 실행하지 않습니다. 따라서 CSR 방식에서는 상품 공유 시 썸네일을 표시할 수 없지만, Next.js에서는 SSR 기능으로 OG 태그를 HTML에 포함시켜 썸네일을 표시할 수 있습니다.
  • ISR(Incremental Static Regeneration): 상품 수가 매우 많은 커머스에서 모든 상품 정보를 매번 SSR로 처리하면 서버에 부담이 큽니다. 자주 조회되는 상품들에 대해서는 Next.js는 자주 조회되는 페이지를 HTML을 캐시해 부담을 줄여주는 ISR 기능을 기본  제공합니다.
  • 이미지 최적화: 커머스 페이지 용량의 대부분은 이미지가 차지하므로, 이미지 데이터 처리 효율이 중요합니다. Next.js의 <Image> 컴포넌트는 반응형 사이징, WebP/AVIF 변환, lazy loading, blur placeholder, CLS 방지를 자동으로 처리해 줍니다.

1인 개발 환경에서 위 Next.js에서 제공하는 기능들을 직접 구현하려면 많은 시간이 들 것이므로, Next.js를 도입하는 것이 효율적이라 판단했습니다.

3. 스타일링 - Tailwind CSS

CSS 스타일링 솔루션 후보로는 CSS Modules, CSS-in-JS, Vanilla Extract, Tailwind가 있었으며, 그 중 Tailwind를 선택했습니다.

 

각 후보의 특징은 다음과 같습니다.

  • CSS Modules: React 같은 컴포넌트 모델 사용 시, 스타일 클래스명을 지역화해 충돌을 막아주는 솔루션입니다. 순수 CSS를 사용해 학습비용이 거의 없지만, 디자인 토큰 사용을 강제할 수 없고, 클래스 네이밍 규칙을 직접 관리해야 한다는 단점이 있습니다.
  • CSS-in-JS: JS로 스타일을 정의하고 props 기반 동적 스타일링이 가능해 컴포넌트 모델과 잘 어울리지만, 사용자 브라우저에서 JS가 실행된 후 CSS가 생성되는 런타임 방식이라, 페이지 로딩 성능이 불리해 사용자 경험과 SEO에서 손해를 보는 단점이 있습니다.
  • Vanilla Extract: TypeScript로 스타일을 작성하고 빌드 타임에 CSS가 생성되는 방식입니다. 런타임 비용이 없고 디자인 토큰 외의 값을 사용하면 컴파일 에러를 발생시켜 디자인 토큰을 강제할 수 있다는 장점이 있습니다. 다만 shadcn/ui 같은 검증된 컴포넌트 자산을 활용할 수 없어 1인 개발 시 직접 구현 비용이 발생합니다. 자체 디자인 시스템과 컴포넌트 자산이 갖춰진 큰 조직에 적합한 솔루션입니다.

Tailwind를 선택한 이유는 빌드 타임에 CSS 를 생성하여 런타임 비용이 없고, 디자인 토큰을 강제할 수 있으며 스타일 클래스 네이밍 관리 부담을 줄여주는 장점이 있습니다. 무엇보다 shadcn/ui를 통해 검증된 컴포넌트 자산(자주 쓰이는 UI, 웹 접근성 처리, 관련 동작 처리 등)을 바로 가져다 쓸 수 있어, 1인 개발에서 가장 적합하다고 판단하였습니다.

 

백엔드

1. 언어 및 프레임워크 - Java + Spring Boot

Go, Node.js, Python 등 업계에서 활발히 사용되는 언어들도 있었으나 Java + Spring Boot를 선택했습니다.

  • 풍부한 트랙잭션 기능: @Transactional 기능으로 전파,격리,롤백 규칙을 간단하게 적용할 수 있고 @TransactionalEventListener(AFTER_COMMIT) 같은 커밋 훅 기능으로 외부 시스템 연동 시 동작의 정합성을 간편하게 보장할 수 있습니다.
  • 잘 갖춰진 동시성 지원: JVM의 멀티스레드/공유 힙 메모리 모델 위에 HikariCP 커넥션 풀, Redisson 분산 락 등 동시성 관련 기능이 다른 언어 환경에 비해 풍부하게 제공됩니다. Java 21의 Virtual Thread 도입으로 동기 스타일 코드의 가독성을 유지하면서도 비동기 처리의 이점을 누릴수 있게 되었습니다.
  • 성숙한 ORM 지원: JPA 영속성 컨텍스트, @Version, @Lock 같은 락 관련 기능 등 ORM에 필요한 기능들이 다른 언어의 ORM에 비해 잘 갖춰져 있습니다.
  • 국내 PG/배송사 API 지원: 국내 주요 PG사 공식 SDK와 배송사 API가 Java + Spring을 최우선 순위로 지원합니다.
  • 오랜 역사와 넣은 사용자 풀: Spring은 20년 넘게 활발히 사용된 프레임워크로 트랜잭션, 보안 같은 핵심 영역에서 많은 패치가 이루어졌고, 기술 블로그와 트러블 슈팅 사례가 다른 언어에 비해 풍부합니다.

2. DB 접근 방식 - JPA(ORM)

전반적인 DB 접근 방식은 JPA(ORM)과 MyBatis(SQL Mapper) 중 JPA를 선택했습니다. 이유는 다음과 같습니다.

  • 영속성 컨텍스트 활용: JPA 사용 시 1차 캐시, 변경 감지, 쓰기 지연 등 영속성 컨텍스트가 제공하는 기능을 활용할 수 있습니다.
  • 스키마 변경 비용 절감: SQL Mapper 방식에서는 필드 변경이 발생하면 관련 SQL 코드를 모두 수정해야 합니다. 커머스 플랫폼처럼 테이블이 많고 관계가 복잡한 환경에서는 이 비용이 매우 커집니다.
  • 컴파일 타입 검증: 테이블 변경 시 관련 작업 코드에 변경사항이 잘 반영되었는지 컴파일 타임에 검사할 수 있습니다.

3. DBMS - PostgreSQL

DBMS 후보로는 Oracle, MongoDB, MariaDB, PostgreSQL이 있었으며, 그중 PostgreSQL을 선택했습니다.

 

다른 후보를 제외한 이유는 다음과 같습니다.

  • Oracle: 1인 개발 환경에는 라이선스 비용이 과도합니다. (가장 저렴한 Standard Edition 2도 NUP 최소 구성 기준 첫해 약 4,000달러 이상)
  • MongoDB: 커머스 핵심 기능(주문, 결제, 재고 관리)은 데이터간 관계가 복잡해 중복을 막기 위한 정규화가 필요하고, 하나의 작업이 여러 데이터를 동시에 변경하기에 트랜잭션 관리 기능이 필요한데, MongoDB를 비롯한 NoSQL DB는 이러한 기능에 대한 지원이 RDBMS에 비해 제한적입니다.
  • MariaDB: 커머스에서 유용한 범위 타입, EXCLUDE 제약, 부분 인덱스를 지원하지 않고, 집계에 필요한 LATERAL JOIN과 AI 추천에 활용 가능한 벡터 검색도 지원하지 않습니다.

PostgreSQL은 위 기능들을 모두 지원하면서도 오픈소스라 라이센스 부담이 없어, 1인 개발 환경에서 가장 적합한 선택지였습니다.


이번 글에서는 아래와 같이 프로젝트의 기술스택을 선정하였습니다.

  • 프론트엔드
    • 언어 : TypeScript
    • 라이브러리 및 프레임워크: React + Next.js
    • 스타일링: Tailwind CSS + shadcn/ui
  • 백엔드
    • 언어 및 프레임워크: Java + Spring Boot
    • DB 접근 방식: JPA(ORM)
    • DBMS: PostgreSQL

 

다음 글에서는, 본격적인 개발 전 알아두어야 할 커머스 플랫폼 운영 시 필요한 법적 제약사항들을 알아보겠습니다.