핵심 요약

도메인 검색·구매·옥션·보유 관리로 이어지는 사용자 서비스와, 주문·정산·쿠폰·CS·권한·로그를 다루는 운영자 백오피스를 하나의 도메인으로 보고 함께 구축했습니다. 같은 거래 데이터를 사용자·운영자가 서로 다른 관점으로 다루는 구조라, 서버/클라이언트 상태 책임 분리메뉴 노출이 아닌 실제 권한 기준의 인가를 축으로 프론트엔드를 설계했습니다.

프로젝트 배경

Cluvit은 도메인 검색부터 등록·구매·옥션·보유 도메인 관리까지 이어지는 사용자 서비스와, 도메인·옥션·주문·정산·쿠폰·CS·공지·FAQ·배너·팝업·설정·권한·로그를 다루는 운영자 백오피스를 함께 제공하는 거래 플랫폼입니다. 사용자 웹·백오피스·문서·공통 코어를 pnpm 모노레포로 묶어 운영합니다.

거래 서비스는 사용자 화면만 잘 만든다고 끝나지 않습니다. 사용자가 만든 주문·옥션이 운영자의 정산·CS·권한 관리로 이어지므로, 사용자 흐름과 운영 흐름을 같은 도메인 모델 위에서 설계해야 데이터가 어긋나지 않습니다.

담당 범위

  • 사용자 웹·대시보드 UI/UX 및 프론트엔드 개발
  • 도메인 검색·구매·옥션·보유 관리 화면 구현
  • 운영자 백오피스 프론트엔드(주문·정산·쿠폰·CS·공지·FAQ·배너·권한·로그)
  • 인증·상태·서버 데이터 관리 구조 설계
  • 다국어 화면·콘텐츠 확장을 고려한 UI 구조 적용

문제 정의

  • 도메인 이중성 — 같은 도메인·옥션·주문 데이터를 사용자는 '거래 대상'으로, 운영자는 '관리·정산 대상'으로 다뤄야 했습니다. 두 관점을 각기 다른 화면으로 만들면 데이터 정의가 갈라져 발행 결과가 어긋날 위험이 있었습니다.
  • 빠르게 변하는 서버 상태 — 옥션·거래는 서버 상태가 수시로 바뀝니다. 클라이언트 Store가 서버 데이터를 복사·보관하면 화면마다 최신 상태가 달라지는 불일치가 생깁니다.
  • 권한의 표리부동 — 운영자 기능은 메뉴를 숨기는 것만으로 접근을 막았다고 볼 수 없었습니다. 페이지 접근·액션 노출·서버 Permission이 어긋나면 UI로는 막혔지만 실제로는 뚫리는 취약점이 됩니다.
  • 다국어 확장 — 언어 리소스를 화면에 직접 박으면, 언어가 늘 때마다 화면을 다시 만들어야 합니다.

기술적 의사결정

1. 사용자 서비스와 운영 시스템을 하나의 도메인으로 이해

  • 배경 — 거래 이후 운영자가 주문·정산·CS·옥션 상태를 어떻게 다루는지 모른 채 사용자 화면만 만들면, 같은 데이터가 두 곳에서 다르게 정의됩니다.
  • 선택 — 동일 도메인 데이터가 사용자와 운영자에게 서로 다른 관점으로 표현된다는 전제로 화면 구조를 잡아, 거래 흐름과 운영 흐름을 같은 모델 위에 얹었습니다.
  • 트레이드오프 — 사용자 앱과 운영자 앱을 완전히 분리하면 초기 개발은 단순하지만 도메인 정의가 갈라집니다. 공통 코어를 모노레포로 공유하는 비용을 감수하고 정의의 단일화를 택했습니다.

2. Server State와 Client State 책임 분리

  • 배경 — 옥션·거래처럼 서버가 소유하고 빠르게 변하는 데이터를, 화면 인터랙션 상태와 같은 도구로 관리하면 캐시·동기화가 뒤섞입니다.
  • 선택 — 원격 데이터의 조회·갱신·캐시는 TanStack Query가, 화면 인터랙션 상태는 Zustand가 맡도록 갈랐습니다. 클라이언트 Store가 서버 데이터의 원본 역할을 하지 않게 해, 갱신 빈도가 높은 영역에서도 최신성을 유지했습니다.
  • 트레이드오프 — 모든 상태를 전역 Store 하나로 다루면 코드는 단순해 보이지만, 서버 상태의 무효화·재검증을 직접 구현해야 합니다. 상태를 소유 주체별로 나누는 쪽이 장기적으로 결합을 줄인다고 판단했습니다.

3. 메뉴 노출이 아닌 '실제 권한' 기준의 인가

  • 배경 — 운영 기능은 노출을 숨긴다고 접근이 막히지 않습니다. 정산·쿠폰·CS처럼 운영 영향도가 큰 기능일수록 UI 게이팅과 서버 권한이 반드시 일치해야 합니다.
  • 선택 — 페이지 접근·액션 노출·서버 Permission의 의미가 일치하도록 인가 기준을 맞추고, 운영 영향도가 높은 기능은 변경·실행 이력을 추적할 수 있는 구조와 함께 다뤘습니다.

4. 언어 리소스와 UI 구조 분리

  • 배경 — 다국어 확장 시 화면을 다시 만들지 않으려면, 텍스트가 화면 로직과 분리돼 있어야 합니다.
  • 선택 — 언어별 텍스트를 화면 내부에 결합하지 않고 언어 리소스로 분리해, 언어가 늘어도 UI 구조를 재작성하지 않도록 유지했습니다.

결과

  • 사용자 거래 흐름과 운영 백오피스를 하나의 제품 흐름으로 연결
  • Server/Client State 책임 분리로 갱신 빈도 높은 옥션·거래 데이터의 화면 간 불일치 억제
  • 페이지 접근·액션 노출·서버 권한을 일치시켜 UI 게이팅과 실제 인가의 괴리 제거
  • 언어 리소스 분리로 다국어 확장 시 화면 재작성 비용 축소

핵심 작업

  • 사용자 웹·대시보드와 운영자 백오피스를 동일 도메인 모델 위에서 구현
  • TanStack Query(서버 상태)·Zustand(클라이언트 상태) 책임 분리
  • 페이지 접근·액션 노출·서버 Permission 정합을 맞춘 역할 기반 인가
  • 정산·쿠폰·CS 등 운영 영향도 높은 기능의 변경·실행 이력 추적 구조
  • 언어 리소스와 UI 구조 분리로 다국어 확장 대응