D-Order
1차 2025.03~05 · 2차 05~07 · 3차 07~09 · 4차 2026.02~ (고도화)Frontend LeadFE 3 / BE 4 / PM 1 / Designer 1
- Team
- React
- TypeScript
- WebSocket
- Redis
D-Order는 축제 부스 현장에서 발생하는 주문·결제·서빙·정산의 불편함을 디지털로 해결하는 운영지원 서비스입니다. Customer(고객)·Admin(운영진)·Server(서빙) 웹을 분리해 역할별 흐름만 제공하고, WebSocket + Redis Pub/Sub로 주문/상태/직원 호출을 실시간 동기화했습니다.
기술적 의사결정
- React + TypeScript로 역할(고객/운영진/서빙)별 UI를 타입 안정적으로 분리
- WebSocket을 주문·테이블·직원 호출의 실시간 채널로 사용
- Redis Pub/Sub로 Front↔Back 이벤트 브로커 구성
- 장바구니·주문 스냅샷의 단일 출처를 서버로 두고 클라이언트는 조회/구독
- Heartbeat(PING/PONG 30s)·Reconnect(3s, 최대 5회)로 현장 네트워크 변동 대응
- JWT/쿠키 인증 + 권한 분리로 역할별 구독 범위 설계
담당 역할
- Frontend Lead로 Customer/Admin/Server 전반의 흐름 설계 및 개발 기준 수립
- 장바구니·주문·결제 흐름과 화면 간 상태 관리 아키텍처 설계
- 축제 현장 네트워크를 고려한 인증/연결 전략·장애 대응 UX 정리
- 고객·직원 WebSocket 채널 설계(구독 범위 분리)
- WebSocket + Redis Pub/Sub 기반 실시간 상태 동기화 구현
- 2주 MVP 협업을 위한 와이어프레임·API 명세·GitHub→Discord 알림 자동화 주도
Challenge & Solution
문제
모바일 CPU slowdown 조건에서 radial-gradient + blur 배경이 GPU 과부하를 유발하며 프레임 저하·렌더 아티팩트가 발생했습니다.
해결
Chrome DevTools + Lighthouse로 현장 조건을 재현한 뒤 Performance/Paint/Layers로 blur 비용을 확정하고, 배경을 이미지화·transform 중심 구성으로 전환해 composite에서 처리되게 했습니다.
배운 점
모바일 성능 이슈는 ‘느리다’가 아니라 ‘어떤 조건에서 깨지는가’를 재현하는 것부터가 시작이며, 감각적 UI도 DevTools 근거로 안전한 렌더링을 선택해야 합니다.
문제
장바구니를 클라이언트 전역 상태 중심으로 관리하니 새로고침·로그인 변경·다중 탭에서 상태 유실이 났고 현장 신뢰성이 떨어졌습니다.
해결
localStorage·BroadcastChannel·React Query cache를 비교 실험한 뒤, 서버를 단일 출처로 두고 클라이언트는 스냅샷 조회/WebSocket 구독으로 수렴하도록 전환했습니다.
배운 점
현장 운영에서는 편의성보다 신뢰성이 우선이며, 서버 기준 정합성 설계가 필요합니다.
문제
직원 호출에서 여러 직원이 동시에 수락하면 동일 요청이 중복 처리되거나 화면 상태가 꼬일 수 있었습니다.
해결
호출 상태(PENDING/ACCEPTED/DELETED)를 WebSocket으로 구독하고, 서버에서 트랜잭션/비관적 락으로 PENDING→ACCEPTED 전이를 한 번만 보장한 뒤 Redis Pub/Sub로 브로드캐스트했습니다.
배운 점
실시간 도메인의 핵심은 동시성/정합성이며, 프론트는 UX와 함께 ‘상태가 수렴하는 구조’를 설계해야 합니다.