호텔 예약 · 결제 통합 플랫폼

1. 프로젝트 개요 및 역할

호텔 객실 조회부터 예약, 결제, 관리자 운영 시스템까지 아우르는 통합 예약 플랫폼을 1인 백엔드로 기획·개발 중인 프로젝트입니다. 고객사 요구사항 정의부터 Core 아키텍처 설계, 동시성 제어, 인프라 트러블슈팅까지 전 과정을 주도했으며, FE 3명과의 협업 속에서 PM·PL도 겸임했습니다. 비즈니스 확장성을 고려한 데이터 모델링과 결제·재고의 정합성 보장이 핵심 목표였습니다.

2. 핵심 챌린지 및 문제 해결

챌린지 1: 파편화된 데이터 구조 탈피와 Core Product 모델링

문제 상황

이전 '화훼 도소매 B2B 주문 플랫폼' 프로젝트에서 상위 Product 개념 없이 상품 테이블이 독립적으로 파편화되어 있던 구조를 경험했습니다. 결제 정보를 저장하는 하나의 테이블에서 2개 이상의 상품 테이블을 참조해야 했으나 FK로 묶을 수 없어, reference_id(테이블 ID)와 reference_type(테이블명)을 컬럼으로 저장한 뒤 row 데이터를 기반으로 동적 JOIN을 수행해야 하는 구조적 한계가 있었습니다.

고려한 대안과 판단

대안	접근	기각 사유
현행 유지	문자열 참조 구조 그대로 사용	분기 로직 증가로 신규 상품 추가 시 수정 범위 통제 불가
완전 정규화	모든 관계를 FK로 연결, JOIN으로 조회	JOIN Depth 5단계 이상 → 조회 쿼리 복잡도·성능 저하
Core Product 다형성 + 전략적 비정규화	공통 부모 테이블을 두고 하위 테이블이 FK 참조, 재고는 객실을 직접 참조	—

이 경험을 바탕으로, Core Product 테이블을 공통 뿌리로 두고 type 컬럼으로 상품 종류를 식별하는 다형성 구조를 채택했습니다. 하위에 관광, 객실 등의 카테고리 테이블을 두어 관리하되, 결제·주문 등 타 테이블은 상위 Product ID만으로 관계를 맺도록 설계했습니다. 완전 정규화 대신 JOIN Depth를 최대 3단계로 제한하는 전략적 비정규화를 병행해 조회 성능을 방어했습니다.

해결 과정

• 모든 상품 테이블이 Core Product의 PK를 FK로 참조하도록 스키마를 재설계해 reference_id/reference_type 방식의 문자열 참조를 완전히 제거했습니다.
• 최하위 재고 테이블이 중간 단계를 건너뛰고 객실 테이블을 직접 참조하도록 설계해 빈번한 재고 조회의 JOIN Depth를 줄였습니다.
• 향후 호텔, 컴퓨터, 마우스 등 상품 카테고리가 파생되더라도 상위 Product ID를 기반으로 기존 주문·결제 로직의 변경 없이 하위 테이블만 추가하면 되는 확장 가능한 구조로 설계했습니다.

결과

• 결제·주문 로직이 상위 Product ID 하나만 참조하는 구조로, 신규 상품 카테고리 추가 시 하위 테이블 1개만 생성하면 기존 로직 변경 없이 확장 가능
• reference_id/reference_type 기반 동적 JOIN 제거 → FK 기반의 명시적 관계로 전환하여 쿼리 안정성 및 유지보수성 확보

---

챌린지 2: 예약·결제·재고의 동시성 충돌 방어 및 정합성 보장

문제 상황

실시간으로 감소해야 하는 재고와 외부 의존성이 높은 결제 API가 맞물리는 구조였습니다. 다수 사용자가 동시에 동일 객실을 예약 시도하거나, 결제 API 호출 이후 내부 트랜잭션이 실패하면 재고는 차감되었으나 예약은 미생성되는 데이터 불일치 상태가 발생할 수 있었습니다.

고려한 대안과 판단

대안	접근	기각 사유
비관적 락(Pessimistic Lock)	SELECT FOR UPDATE로 재고 행 잠금	트래픽 집중 시 DB 락 대기 누적 → 처리량 저하
애플리케이션 레벨 큐	예약 요청을 순차 처리	외부 결제 API 실패 시 롤백 복잡도 급증, 추가 인프라 필요
낙관적 락(Optimistic Lock) + 원자적 트랜잭션	version 컬럼으로 충돌 감지, 예약·결제·재고를 단일 트랜잭션으로 묶음	—

락 대기 없이 충돌을 감지하는 낙관적 락이 예약 시스템의 쓰기 빈도와 성능 요건에 더 적합하다고 판단했습니다. 예약·재고 차감·결제 검증을 단일 트랜잭션으로 묶어 원자성을 보장했습니다.

해결 과정

• 예약 생성, 재고 차감, 결제 검증 세 단계를 Prisma $transaction으로 묶어 어느 한 단계라도 실패하면 전체가 롤백되도록 구성했습니다.
• 재고 테이블에 version 컬럼을 도입하고, 차감 시점의 version과 조회 시점의 version이 다르면 충돌로 판정해 즉시 롤백했습니다.
• 동시성 충돌 발생 시 단순 품절 메시지 대신 "잠시 후 다시 시도해 주세요" 응답을 반환해 재시도 가능성을 열어두었습니다.

결과

• 동시 예약 충돌 시 데이터 불일치 발생률: 재현 가능 → 0% (트랜잭션 원자성 보장)
• 결제 API 실패 후 고아 재고 차감 건수: 발생 가능 → 0건 (롤백 일원화)

---

챌린지 3: Cloudflare 봇 차단 트러블슈팅과 인증 라우팅 중앙화

문제 상황

두 가지 이슈가 동시에 발생했습니다. 첫째, 도메인이 분리된 배포 환경에서 httpOnly secure 쿠키가 클라이언트에 전달되지 않아 로그인 세션이 유지되지 않는 현상이 있었습니다. 둘째, 관리자 API 경로가 늘어날수록 각 컨트롤러마다 인증 Guard를 선언해야 하는 구조로, 누락 가능성과 유지보수 비용이 높았습니다.

고려한 대안과 판단

대안	접근	기각 사유
쿠키 → Authorization 헤더 전환	JWT를 헤더로 전달	httpOnly 쿠키 포기 → XSS 취약점 노출 위험
Cloudflare 비활성화	리버스 프록시 우회	CDN·DDoS 방어 포기, 운영 환경에서 불가
Cloudflare 봇 감지 설정 조정 + MiddlewareConsumer 일괄 적용	서버 간 통신을 봇으로 오인한 룰 수정, 인증을 라우팅 레벨에서 일괄 처리	—

쿠키 보안 속성을 포기하지 않고 인프라 설정을 수정하는 방향을 선택했습니다. 인증 중앙화는 Guard 개별 선언 방식보다 MiddlewareConsumer를 통한 경로 기반 일괄 적용이 유지보수에 유리하다고 판단했습니다.

해결 과정

• 쿠키 유실 원인을 네트워크 레이어부터 역추적한 결과, Cloudflare가 서버 간 통신을 봇 트래픽으로 오인해 요청을 차단하고 있음을 확인했습니다.
• Cloudflare 보안 설정에서 내부 서버 IP 대역을 신뢰 범위로 등록해 차단 룰을 우회했습니다.
• NestJS의 MiddlewareConsumer를 활용해 /admin 하위 전체 경로에 JWT 검증 미들웨어를 일괄 적용하고, 로그인 등 인증 불필요 엔드포인트는 .exclude()로 명시적으로 제외했습니다.

Middleware와 Guard 중 어떤 방식을 선택할지에 대한 트레이드오프 분석은 인사이트 [NestJS] Guard가 정답일까? 에서 다루고 있습니다.

Next.js와 NestJS 간 도메인 분리 환경의 아키텍처 구성에 대해서는 인사이트 [Next.js x NestJS] 프론트엔드와 백엔드의 도메인 분리, 깨부순 아키텍처 오해들 에서 다루고 있습니다.

결과

• 쿠키 기반 인증 정상화: 세션 유지 불가 → 전 환경 정상 동작
• 인증 미들웨어 누락 가능 경로: 컨트롤러 개수만큼 → 0개 (라우팅 레벨 일괄 적용)
• 신규 관리자 API 추가 시 인증 처리 추가 작업: Guard 선언 필수 → 불필요

3. 프로젝트 회고

• 정규화와 성능은 정답이 없는 균형의 문제임을 체감했습니다. Core Product 모델링 과정에서 완전 정규화를 포기하고 전략적 비정규화를 선택한 판단이, 이후 조회 API 개발 속도와 쿼리 단순성을 실질적으로 높여주었습니다.
• 프레임워크가 제공하는 도구를 맹목적으로 따르기보다 현재 구조의 맥락에서 트레이드오프를 따져보는 습관이 생겼습니다. Guard 대신 MiddlewareConsumer를 선택한 것처럼, 더 "올바른" 방식보다 지금 상황에서 유지보수 비용이 낮은 방식을 고르는 판단력이 실무에서 더 중요하다는 것을 배웠습니다.