React SPA + REST API, 정말 최선의 선택일까?

1. 브라우저가 서버로부터 거의 빈 HTML 앱 셸을 받습니다.

2. <script src="/assets/index-abc123.js">

   같은 해시된 자바스크립트 파일을 다운로드하고 실행합니다.
3. React가 초기화되고, 라우터가 현재 URL(/shop)을 읽어 적절한 페이지 컴포넌트를 로드합니다.
4. 페이지 컴포넌트는 window.__INITIAL_DATA__ 같은 전역 변수에 담긴 부트스트랩 데이터를 사용하거나, REST API를 호출해 필요한 데이터를 가져옵니다.
5. 데이터가 도착하면 React가 DOM을 그리고, 상품 목록이 최종적으로 화면에 표시됩니다.

이 과정의 핵심 문제는 '모든 콘텐츠가 자바스크립트 실행에 의존한다'는 점입니다. 초기 HTML에는 상품 이름, 가격, 설명 같은 중요한 정보가 전혀 없습니다. 검색엔진 크롤러가 자바스크립트를 실행하지 못하거나, 실행 결과를 기다리지 못하면 페이지가 텅 빈 상태로 색인될 위험이 있습니다.

1.2 상품 데이터의 문제점: '상품 중심'에서 '변형 중심'으로

REST API의 상품 스키마를 분석해 보면 몇 가지 아키텍처적 문제점이 드러납니다.

• 재고(stock)가 상품 레벨에 있음: variants(색상, 사이즈별 상품) 배열이 따로 존재하지만, stock 필드는 최상위 상품 객체에 있습니다. 이는 Black/M과 Black/L의 재고를 개별적으로 관리해야 하는 실제 운영과 맞지 않습니다.
• 옵션 값의 비정규화: sizes에는 XXL, 2XL이, colors에는

  ink navy

  ,

  Ink Navy

  가 혼재되어 있습니다. 이런 비일관성은 필터링, 분석, 이미지 매핑의 오류를 유발합니다.
• 중복되거나 불명확한 필드: image와 images가 공존하고, type, isbn 같은 제네릭한 필드가 상품 스키마에 포함되어 있습니다.

이러한 문제는 'SKU(Stock Keeping Unit)와 재고 관리는 변형(Variant) 레벨에서 이루어져야 한다'는 이커머스 데이터 모델링의 기본 원칙을 위반합니다. 소규모 카탈로그(16개 상품)에서는 큰 문제가 없을 수 있지만, 상품이 수백, 수천 개로 늘어나면 심각한 관리 이슈가 됩니다.

1.3 홈페이지 빌더와 레이아웃: 유연하지만 위험한 설계

/api/homepage와 /api/layout 엔드포인트는 홈페이지와 전체 레이아웃이 데이터에 의해 동적으로 구성될 수 있음을 보여줍니다.

• 장점: 마케팅 팀이 코드 배포 없이도 홈페이지의 섹션 순서를 바꾸거나, 특정 블록(히어로, 프로모션, 상품 리스트)을 켜고 끌 수 있습니다. 이는 매우 강력한 CMS(콘텐츠 관리 시스템) 기능입니다.
• 단점: 현재 API 설계는 section_order, 각 섹션의 enabled 토글, 실제 payload(데이터)가 느슨하게 연결되어 있습니다. ann과 announcement가 공존하는 등, 스키마 변경 이력이 깔끔하게 관리되지 않고 있습니다. 이는 데이터 정합성 문제를 일으킬 수 있습니다.

보다 나은 설계는 각 블록이 id, kind, enabled, position, payload, schema_version을 포함하는 단일 리스트로 관리되는 것입니다. 이렇게 하면 순서, 상태, 데이터가 하나의 애그리게이트(Aggregate) 안에 있어 동기화 오류가 줄어듭니다.

1.4 결제 흐름: 핵심은 '서버가 모든 것을 계산한다'

PayPal 결제는 create-order → 승인 → capture의 3단계로 이루어집니다. 이 흐름은 업계 표준을 잘 따르고 있습니다. 하지만 실제 보안과 정확성을 위해서는 다음과 같은 사항이 반드시 검증되어야 합니다.

• 멱등성 키(Idempotency Key): 사용자의 더블 클릭이나 네트워크 재시도로 인해 동일한 결제가 두 번 생성되지 않도록 해야 합니다.
• 트랜잭션 및 잠금: 동시에 여러 사용자가 마지막 1개 남은 상품을 구매하려 할 때, '오버셀(Oversell)'을 방지하기 위한 데이터베이스 수준의 잠금 또는 트랜잭션 처리가 필요합니다.
• 가격 검증:

  POST /api/paypal/create-order

  에서 서버는 절대 브라우저가 보낸 가격을 신뢰해서는 안 됩니다. 서버는 데이터베이스의 현재 가격, 할인 규칙, 배송비를 직접 조회해 총액을 계산해야 합니다. 그렇지 않으면 사용자가 악의적으로 요청을 변조해 할인을 받을 수 있습니다.

1.5 보안 취약점: 공개된 엔드포인트의 위험

/api/track(트래킹), /api/newsletter(뉴스레터), /api/contact(문의), /api/reviews(리뷰) 같은 엔드포인트는 모두 공개된 POST 요청을 받습니다. 이는 다음과 같은 공격 표면(Attack Surface)을 만듭니다.

• 데이터베이스/로그 오염: 임의의 JSON 데이터를 계속 전송해 로그를 채우거나 데이터베이스를 비대하게 만들 수 있습니다. 화이트리스트 기반의 이벤트 네임/속성 검증이 필요합니다.
• PII(개인 식별 정보) 노출: /api/orders/track?reference=123 같은 형태는 주문 번호만 알면 누구든지 주문 내역을 조회할 수 있습니다. 인증된 토큰 또는 주문번호+이메일 조합을 요구하고, 속도 제한을 걸어야 합니다.
• 봇 공격: CAPTCHA나 rate limiting 없이 공개된 /api/contact는 스팸 메일 폭탄이 될 수 있습니다.

2. 커스텀 SPA vs 우커머스: 핵심 비교

많은 사람들이 'React/Vite로 만든 커스텀 사이트 = 더 좋은 사이트'라고 오해합니다. 하지만 기술 스택 자체가 성능이나 품질을 보장하지는 않습니다. 다음은 주요 항목별 비교입니다.

2.1 성능 (Performance)

결론: 커스텀 SPA가 '절대적으로 느리다'는 것은 아닙니다. SSR(Server-Side Rendering), SSG(Static Site Generation), ISR(Incremental Static Regeneration)을 적용하면 첫 로딩 성능을 획기적으로 개선할 수 있습니다. 문제는 현재의 단순 CSR(Client-Side Rendering) 방식입니다.

2.2 SEO (검색엔진 최적화)

Google은 자바스크립트를 실행하고 그 결과를 색인에 반영할 수 있습니다. 하지만 이것이 CSR이 SEO에 안전하다는 의미는 아닙니다.

CSR의 SEO 리스크:

• 색인 지연(Indexing Delay): Google이 페이지를 방문해 JS를 실행하고, 그 결과를 색인하는 데 며칠에서 몇 주가 걸릴 수 있습니다. SSR/SSG라면 이 과정이 필요 없습니다.
• 소프트 404(Soft 404): 존재하지 않는 상품 페이지(/product/없는-상품)에 접속해도 서버는 앱 셸을 200 OK로 반환합니다. React는 나중에 '찾을 수 없음' 메시지를 표시하지만, Google은 이를 정상적인 페이지로 오해할 수 있습니다. 404 HTTP 상태 코드를 반환하거나, noindex 메타 태그를 추가해야 합니다.
• 소셜 미디어 미리보기 미작동: 페이스북, 트위터, 카카오톡 등은 대부분 자바스크립트를 실행하지 않고 Open Graph(og:title, og:image) 태그만 읽습니다. CSR에서는 이 태그들이 JS로 동적으로 생성되므로, 링크를 공유할 때 잘못된 제목이나 이미지가 표시될 수 있습니다.

해결책 (SSR/ISR로의 전환):

1. SSG/ISR 적용: 상품, 카테고리, 콘텐츠 페이지를 빌드 시점이나 요청 시점에 정적 HTML로 미리 생성합니다. Next.js, Nuxt.js 같은 최신 프레임워크가 이 기능을 제공합니다.
2. 메타데이터 서버 생성: title, description,

   canonical URL

   , og:title, og:image, 그리고 JSON-LD 구조화된 데이터(Product, BreadcrumbList, Organization)를 서버에서 HTML에 포함시킵니다.
3. 올바른 HTTP 상태 코드: 존재하지 않는 리소스에 대해 반드시 404 또는 410을 반환하도록 라우팅을 구성합니다.

Google은 '다이나믹 렌더링(Dynamic Rendering, 크롤러에게만 미리 렌더링된 HTML을 보여주는 방식)'을 **'임시방편(workaround)'**이자 **'장기적인 해결책이 아니다'**라고 명시하고 있습니다. SSR, SSG, hydration을 권장합니다.

2.3 유지보수 (Maintenance)

• 핵심 트레이드오프: 커스텀은 '모든 것을 통제할 수 있는 자유'를 얻는 대신 '모든 것을 개발하고 유지보수해야 할 책임'을 집니다. 우커머스는 '기능을 바로 사용할 수 있는 편리함'을 얻는 대신 '플러그인 종속성과 업데이트 관리'라는 부담을 집니다.

2.4 비용 (Cost)

많은 사람이 '우커머스는 라이선스 비용이 없으니 공짜'라고 생각하지만, 호스팅, 프리미엄 플러그인, 테마, 유지보수 인건비를 합치면 결코 적지 않은 비용이 듭니다. 반면, 커스텀 SPA는 초기 개발 비용이 높지만, 트래픽이 많아질수록 CDN과 정적 파일 캐싱을 통해 호스팅 비용을 낮출 수 있습니다.

소규모 상점(16개 상품)에서는 커스텀이 오버엔지니어링(over-engineering)일 가능성이 높습니다. 우커머스로 충분히 빠르고, 관리가 쉬운 사이트를 만들 수 있습니다. 커스텀이 의미를 가지려면, 브랜드 경험에 대한 차별화된 비전이나, 여러 채널(웹, 앱, 키오스크)을 동시에 공략할 계획이 있어야 합니다.

3. 권장 전략: 완전한 재구축, 하지만 더 똑똑하게

분석 결과, 현재 사이트는 완전히 새로운 방향으로 재구축될 필요가 있습니다. 현재의 SPA 방식을 고수하는 것이 아니라, 더 나은 현대적 접근 방식을 채택해야 합니다.

3.1 권장 스택

프론트엔드 (Storefront): Next.js App Router + React + TypeScript

• 이유: App Router는 서버 컴포넌트, SSR, SSG, ISR을 모두 지원합니다. 필요한 페이지만 정적으로 생성하고, 동적인 부분만 클라이언트에서 처리하는 '하이브리드 렌더링'이 가능합니다.
• 데이터 검증은 Zod 같은 라이브러리를 사용해 API 경계에서 타입 안전성을 확보합니다.
• TanStack Query는 서버 상태 관리에 사용하되, 서버에서 이미 렌더링된 데이터를 다시 가져오지 않도록 주의해야 합니다.

백엔드 (API): NestJS (Fastify 어댑터) + PostgreSQL + Prisma/Drizzle ORM

• 이유: 엔터프라이즈급 구조화, 타입 안전성, 강력한 모듈 시스템을 제공합니다. 상품, 주문, 결제 등 복잡한 비즈니스 로직을 체계적으로 관리할 수 있습니다.
• PostgreSQL은 신뢰성이 높은 관계형 데이터베이스로서, 재고, 가격, 주문 상태 등 정합성이 중요한 데이터를 안전하게 관리합니다.
• Redis는 처음부터 도입할 필요가 없습니다. 트래픽이 적은 초기에는 단일 데이터베이스 인스턴스로 충분합니다.

3.2 이행 계획

1. 데이터 모델 재설계: 상품-변형-재고의 정규화된 모델을 설계합니다. SKU를 변형 레벨에서 관리하고, 옵션 값(색상, 사이즈)은 미리 정의된 마스터 데이터를 참조하도록 합니다.
2. API 재구축: 새로운 데이터 모델에 맞게 REST API를 다시 만듭니다. 이전 API의 엔드포인트 명명 규칙이나 응답 형식을 닮지 않고, 깔끔하고 일관된 설계를 목표로 합니다.
3. 스토어프론트 개발: Next.js를 사용해 홈페이지, 상품 목록, 상품 상세, 장바구니, 결제 페이지를 새로 구축합니다. 서버 컴포넌트와 클라이언트 컴포넌트를 명확히 구분해 사용합니다.
4. 점진적 이전 (Strangler Fig 패턴): 트래픽이 적은 시간에 새로운 사이트를 배포하고, DNS와 CDN 설정을 변경해 트래픽을 새로운 스토어프론트로 전환합니다.
5. 모니터링 및 최적화: Core Web Vitals, 전환율, 오류율을 지속적으로 모니터링하고 개선합니다.

4. 결론: 기술이 아닌 '목표'가 선택의 기준

커스텀 React SPA가 우커머스보다 '더 좋다'거나 '더 나쁘다'고 단정할 수 없습니다. 중요한 것은 **'지금 당장의 필요'와 '미래의 비전'**입니다.

• 우커머스가 더 나은 선택인 경우: 빠른 출시가 필요하고, 표준적인 이커머스 기능만으로 충분하며, 엔지니어링 리소스가 제한적인 경우.
• 커스텀이 더 나은 선택인 경우: 독창적인 브랜드 경험을 제공하고자 하며, 유연한 백오피스와 다채널 전략이 필요하고, 이를 지속적으로 개발/운영할 수 있는 엔지니어링 팀이 있는 경우.

현재의 사이트는 장점(유연한 CMS, 독립적인 UI)이 있지만, CSR의 근본적인 약점(SEO 리스크, 첫 로딩 지연)을 해결하지 못했습니다. 단순히 '커스텀이니까 좋다'는 생각을 버리고, SSR/ISR 하이브리드 아키텍처로 전환하는 것이 가장 현명한 선택입니다. Next.js와 같은 현대적인 프레임워크를 사용하면, 자체 구축의 장점은 유지하면서도 SEO와 성능 문제를 함께 해결할 수 있습니다.

결론: 지금 필요한 것은 '우커머스로 갈 것인가, 말 것인가'의 이분법적 선택이 아니라, '현재의 아키텍처를 어떻게 개선할 것인가'에 대한 전략적 판단입니다. SSR/ISR 기반의 재구축은 가장 많은 장점을 제공하는 최적의 경로입니다.