구현 계획

MVP는 도메인, 게이트웨이, QR 결제, 다운로드 순서로 만듭니다

기술적으로 멋진 기능보다 결제 성공 후 영상이 안정적으로 도착하는 구조를 먼저 고정합니다. 중앙 서버는 새로 만들지 않고 기존 dilling-backend를 확장하며, 운영 화면은 dilling-admin에 붙입니다.

작업 레인

병렬로 나누되 상태 모델은 하나로 묶습니다

각 레인은 독립적으로 개발할 수 있지만, RecordingSession 상태가 전체 흐름의 기준점입니다.

dilling-backend

중앙 백엔드 도메인

새 서버를 만들지 않고 기존 Spring 서버에 시설, 코트, 주문, 촬영 세션, 영상 자산, 다운로드 토큰을 추가합니다.

PlayVenue
PlayCourt
PlayOrder
SessionEvent
Settlement

dilling-camera-gateway

현장 게이트웨이

백엔드에서 받은 세션 작업을 polling으로 가져가고, 녹화와 업로드 콜백을 보냅니다.

job polling
session recording
upload callback
heartbeat

dilling-play

고객 웹앱

QR 랜딩, 결제, 동의, 상태 조회, 다운로드 페이지를 앱 설치 없이 모바일 웹으로 제공합니다.

QR landing
payment
consent
watch link

dilling-admin

운영 콘솔

고객 화면은 넣지 않고 시설주와 운영자가 실패 건, 영상 상태, 정산 예정 금액을 확인하는 화면만 붙입니다.

session list
retry
refund flag
settlement
구현 순서

2주 안에 끝나는 것이 아니라, 2주 안에 현장 검증 가능한 뼈대를 만듭니다

01

기존 백엔드 도메인 스켈레톤

dilling-backend 안에서 상태 모델과 API 계약을 먼저 잠급니다.

2-3일

엔티티, 마이그레이션, 관리자 조회 API

02

게이트웨이 작업 큐

현장 장비가 백엔드 세션을 받아 녹화할 수 있게 만듭니다.

3-4일

polling, heartbeat, recording events

03

dilling-play QR 결제

이용자가 dilling-play QR에서 결제하면 촬영 세션이 자동 생성됩니다.

3-5일

주문 생성, 결제 웹훅, 동의 기록

04

업로드와 다운로드

원본 업로드 후 다운로드 토큰으로 영상 링크를 제공합니다.

3-5일

asset registration, signed download, expiry

05

dilling-admin 운영판

실패, 환불, 정산, 장비 상태를 한 화면에서 봅니다.

2-3일

운영 대시보드, 재시도, 환불 대상 표시

레포별 책임

새 서비스처럼 보이지만 내부는 네 개의 기존 자산을 조립합니다

고객이 보는 화면과 운영자가 보는 화면을 섞지 않고, 카메라 제어는 현장 서버에 남기는 것이 운영 기준입니다.

dilling-backend

Play 도메인, 결제 웹훅, 세션 상태 머신, 다운로드 권한, 정산 데이터를 담당합니다.

dilling-camera-gateway

카메라 제어, 예약 녹화, 로컬 파일 보관, 업로드, 이벤트 콜백을 담당합니다.

dilling-play

고객 QR 랜딩, 결제, 동의, 영상 준비 상태, 다운로드 화면을 담당합니다.

dilling-admin

시설/코트/장비/세션/환불/정산을 보는 운영 콘솔을 담당합니다.

도메인과 API

첫 구현은 화면보다 상태 추적이 먼저입니다

결제, 녹화, 업로드, 압축, 다운로드는 서로 다른 시스템에서 일어나므로 엔티티와 이벤트를 분리해야 합니다.

실무 기준

사용자는 `READY`만 보면 되지만, 운영자는 `RECORDING`, `UPLOADING`, `PROCESSING`, `FAILED`를 모두 봐야 합니다.

PlayVenue

시설 단위, 시설주, 정산율, 기본 보관 기간

PlayCourt

코트 단위, 종목, QR 토큰, 기본 가격, 기본 촬영 시간

PlayCameraDevice

게이트웨이와 카메라 상태, heartbeat, 설치 위치

PlayOrder

결제 주문, 휴대폰 암호화, 동의 버전, 결제 상태

PlayRecordingSession

촬영 시작/종료, 실제 녹화 시간, 실패 코드

PlaySessionEvent

녹화, 업로드, 처리, 실패, 재시도 이벤트 로그

PlayVideoAsset

원본, 압축본, 썸네일, 파일 크기, 처리 상태

PlayDownloadToken

만료 토큰, 사용 횟수, 강제 폐기

PlaySettlement

시설주 정산 금액, 정산율, 지급 예정일, 지급 상태

공개 API

GET /api/play/courts/by-qr/{qrToken}POST /api/play/ordersGET /api/play/orders/{orderId}/statusGET /api/play/watch/{downloadToken}

게이트웨이 API

GET /api/play/gateways/{gatewayId}/jobsPOST /api/play/gateways/{gatewayId}/heartbeatPOST /api/play/sessions/{sessionId}/eventsPOST /api/play/sessions/{sessionId}/assets

관리자 API

GET /api/admin/play/sessionsPOST /api/admin/play/sessions/{sessionId}/retryPOST /api/admin/play/sessions/{sessionId}/mark-refund-requiredGET /api/admin/play/settlements

이번 주 1순위

  • 데이터 모델 확정
  • 세션 상태 전이 확정
  • 테스트 결제 없이 수동 PAID 생성

파일럿 전에 반드시

  • 동의 문구 버전 저장
  • 다운로드 토큰 만료
  • 녹화 실패 환불 대상 표시

뒤로 미룰 것

  • 네이티브 앱
  • 자동 하이라이트
  • 다중 카메라 자동 편집

Next decision

다음 설계는 결제사와 게이트웨이 업로드 방식을 확정하는 것입니다

기술 페이지로