호텔 예약 시스템 플랫폼화 및 구조 고도화

1. 프로젝트 개요 및 역할

단일 호텔에 종속되어 있던 기존 예약 페이지를 다수의 파트너사(호텔)에 유연하게 적용할 수 있는 플랫폼 아키텍처로 전환했습니다. 프론트엔드 2인 팀 내에서 설계 주도 역할을 맡아, 코드 수정 없이 신규 프로젝트를 온보딩할 수 있는 Config-driven 구조 도입, 복잡한 예약 상태 관리 캡슐화, 크로스 플랫폼 결제 정합성 보장까지 핵심 아키텍처 결정을 담당했습니다.

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

챌린지 1: 하드코딩된 복제 구조 탈피와 Config-driven 플랫폼 설계

문제 상황

결제 방식, 복합 예약(호텔+골프), 다국어, 회원 정책 등 파트너사마다 다른 요구사항을 공통 코드 내 if-else 분기로 처리했습니다. 신규 호텔 온보딩 시마다 공통 컴포넌트를 직접 수정해야 했고, A 호텔 수정이 B 호텔 UI에 사이드 이펙트를 유발하는 상황이 반복되었습니다. 공통 버그가 발생하면 복제된 N개 프로젝트를 모두 수정·배포해야 했습니다.

고려한 대안과 판단

대안	접근	기각 사유
복제 코드 유지 + 분기 정리	기존 방식의 if-else를 상수로 추출해 정리	분기 자체가 남아 있어 확장할수록 복잡도 재증가
모노레포 + 패키지 분리	공통 로직을 npm 패키지로 분리	빌드 파이프라인 오버헤드가 현 팀 규모에 과도함
Config-driven 아키텍처	관리자 페이지에서 Feature를 ON/OFF, 코드 수정 없이 동작	—

Config 데이터를 앱 최상단에서 한 번에 주입하면, 하위 컴포넌트는 설정값만 읽어 조건부 렌더링을 수행하므로 비즈니스 분기가 코드 밖으로 이동합니다.

해결 과정

• Initial Load 시점에 서버 API를 호출해 해당 프로젝트의 설정값을 일괄 수신하고 최상단 Config Context에 주입했습니다.
• 데이터 수신 전까지 메인 렌더링을 블로킹하되, 브랜드 로딩 스피너를 배치해 빈 화면 노출을 방지했습니다.
• 하위 컴포넌트는 useConfig() 훅으로 Feature Flag를 읽어 조건부 렌더링을 자체적으로 결정하도록 설계했습니다.
• 관리자 페이지에서 설정값 토글만으로 전체 동작이 달라지므로, 신규 파트너사 온보딩 시 프론트엔드 코드 배포가 불필요해졌습니다.

이 챌린지의 기술적 상세는 인사이트 Config-driven 아키텍처로 React 프로젝트 파편화 막기 에서 다루고 있습니다.

결과

• 신규 호텔 온보딩 시 프론트엔드 코드 수정 건수: N건 → 0건
• 파트너사 추가 시 배포 없이 관리자 설정만으로 환경 구성 가능
• 공통 버그 수정이 전체 파트너사에 단일 배포로 일괄 반영

---

챌린지 2: 전역 상태 비대화(Provider Hell) 해결 및 캡슐화

문제 상황

객실 선택 → 정보 입력 → 결제로 이어지는 복잡한 상태를 App.tsx 최상단에서 전역으로 관리했습니다. 예약 상태 하나가 바뀌어도 무관한 결제 컴포넌트가 리렌더링되었고, 결제 도메인 밖의 컴포넌트에서도 useContext로 예약 상태에 접근해 예기치 않은 부수 효과를 유발할 수 있었습니다.

고려한 대안과 판단

대안	접근	기각 사유
Redux Toolkit	전역 스토어 중앙화, 강타입 슬라이스	보일러플레이트 부담, 소규모 팀에 과도한 복잡도
Zustand	경량 전역 스토어, 간결한 API	도메인 경계 강제 불가, 어느 컴포넌트에서나 접근 가능
Context API + 라우터 레벨 격리	도메인별 Provider를 각 라우터에 배치, Custom Hook으로 접근 제한	—

라우터 레벨 격리는 해당 도메인 진입 시에만 Context가 마운트되므로, 별도 라이브러리 없이 스코프와 리렌더링 범위를 동시에 통제할 수 있다고 판단했습니다.

해결 과정

• App.tsx에는 앱 구동에 필수적인 User·Config Provider만 남기고, 예약·결제 Provider는 해당 기능이 동작하는 개별 라우터 레벨로 이동했습니다.
• 라우터를 벗어나면 Context가 자동으로 언마운트되어 메모리가 정리되고, 관련 없는 컴포넌트의 리렌더링을 원천 차단했습니다.
• Context를 직접 노출하지 않고 useReservation 같은 Custom Hook을 통해서만 상태에 접근하도록 강제하여, 도메인 외부에서의 상태 변조를 불가능하게 만들었습니다.

이 챌린지의 기술적 상세는 인사이트 Context API 지옥에서 벗어나 라우터 레벨 캡슐화 달성하기 에서 다루고 있습니다.

결과

• 예약 상태 변경 시 결제 컴포넌트 불필요 리렌더링 제거
• 도메인 외부에서의 상태 변조 경로를 구조적으로 차단
• 컴포넌트 단위 테스트 작성이 용이해져 코드 예측 가능성 향상

---

챌린지 3: 크로스 플랫폼 결제 환경의 UX 보호 및 데이터 정합성 보장

문제 상황

모바일 환경에서는 PC와 달리 PG 결제가 페이지 이동(Redirect) 방식으로 진행됩니다. 결제창으로 이동하는 사이 사용자의 입력 데이터가 유실되는 문제와, 복귀 시점에 재고·가격이 이미 변동되어 결제 금액과 실제 데이터가 불일치하는 두 가지 리스크가 동시에 존재했습니다.

고려한 대안과 판단

대안	접근	기각 사유
sessionStorage만 사용	탭 단위 임시 저장	브라우저 종료·새 탭 복귀 시 데이터 유실
서버 임시 저장	결제 전 상태를 서버 세션에 저장	별도 API·세션 관리 비용, 불필요한 서버 의존도 증가
localStorage TTL + 서버 중심 재조회	입력값은 클라이언트 캐시, 가격·재고는 복귀 시 서버 재조회	—

클라이언트 상태(사용자 입력)와 서버 상태(재고·가격)를 명확히 분리하면, 각자의 신뢰 소스를 올바르게 사용할 수 있다고 판단했습니다.

해결 과정

• 사용자의 순수 입력값은 localStorage에 TTL을 부여해 캐싱하고, 결제 완료나 페이지 완전 이탈 시 즉시 파기하여 잘못된 데이터 복원을 방지했습니다.
• 결제창에서 복귀 시 가격·재고 등 크리티컬한 데이터는 반드시 서버 API를 재조회해 정합성을 강제했습니다.
• 복귀 시점에 재고·가격 변동이 감지되거나 파트너사 API 오류가 발생하면, 즉각 PG 승인을 취소하는 보상 트랜잭션을 실행했습니다.
• 단순 오류 메시지가 아닌 상황별 안내 문구와 함께 안전한 화면으로 리다이렉트해 UX와 데이터 무결성을 동시에 방어했습니다.

결과

• 모바일 결제 복귀 후 입력 데이터 유실 건수 0건 달성
• 결제 금액·재고 불일치로 인한 이상 결제 차단
• 보상 트랜잭션을 통해 PG 이중 청구 없이 안전한 롤백 보장

3. 프로젝트 회고

• 플랫폼은 코드의 공유가 아니라 책임의 분리다: 복제 기반 시스템이 진정한 플랫폼이 되려면 비즈니스 분기를 개별 컴포넌트가 아닌 Config 레벨에서 통제해야 한다는 것을 체감했습니다. 향후 SSR 환경을 도입한다면 Config 데이터를 서버 렌더링 단계에서 미리 주입하는 구조로 재설계가 필요합니다.
• 도구보다 설계 원칙이 먼저다: Redux 없이도 Context API와 라우터 격리만으로 도메인 경계를 충분히 강제할 수 있었습니다. 상태 관리 라이브러리를 선택하기 전에 스코프와 접근 제어 정책을 먼저 설계하는 습관을 갖게 되었습니다.