새 중앙 서버는 만들지 않습니다
결제, 유저, 딜링박스, 딜링마켓, 스토리지 연동이 이미 dilling-backend에 있으므로 Play 도메인을 같은 서버에 추가합니다.
기술 설계
카메라 원본은 현장에 두고, 클라우드는 세션과 파일 상태를 관리합니다
딜링플레이의 핵심 기술 판단은 중앙 서버를 새로 만들지 않고, 기존 딜링 자산을 역할별로 확장하는 것입니다. 현장 게이트웨이가 녹화와 업로드를 맡고, 기존 백엔드는 상태와 권한을 관리합니다.
Architecture decision
고객 화면은 dilling-play, 중앙 도메인은 dilling-backend, 현장 제어는 dilling-camera-gateway, 운영 화면은 dilling-admin으로 나눕니다.
서버 판단
새 서버보다 기존 서버 확장이 더 빠르고 운영 리스크가 낮습니다
현장 서버는 별도로 둡니다
카메라 계정, RTSP, ffmpeg, 로컬 파일은 시설 안에서만 다루고 dilling-camera-gateway가 중앙 서버 작업을 polling합니다.
dilling-admin은 운영 콘솔입니다
고객 QR 화면은 분리하고, dilling-admin에는 시설/장비/세션/환불/정산을 보는 관리자 화면만 붙입니다.
시스템 구조
MVP는 6개 책임만 안정적으로 이어지면 됩니다
dilling-play
QR 랜딩, 결제, 동의, 영상 상태, 다운로드
dilling-backend
기존 Spring 서버에 Play 도메인 추가
dilling-camera-gateway
job polling, RTSP 녹화, 업로드 콜백
IP 카메라
RTSP 원본, 외부 비노출
R2/S3 스토리지
원본, 압축본, 썸네일, 만료 삭제
dilling-admin
운영 콘솔, 실패 처리, 환불, 정산
핵심 기술 판단
파일럿에서 중요한 것은 실시간성보다 실패 복구입니다
게이트웨이는 outbound polling
시설 공유기에 포트포워딩을 요구하지 않고, 카메라 원본 RTSP를 외부에 노출하지 않습니다.
즉시성은 약간 떨어지지만 예약 녹화에는 충분합니다.
녹화는 현장 로컬 파일 우선
네트워크가 흔들려도 경기 영상 자체는 남겨야 합니다.
디스크 용량 감시와 만료 삭제가 필수입니다.
다운로드는 만료 토큰
영상 URL을 영구 공개하지 않고 주문자 접근을 제한합니다.
공유 편의성과 개인정보 보호 사이의 균형을 잡아야 합니다.
콜백은 이벤트 단위
녹화, 업로드, 압축은 실패 지점이 다르므로 하나의 완료 플래그로 묶으면 운영이 어렵습니다.
상태 전이 로직은 더 엄격하게 관리해야 합니다.
상태 머신
세션 상태가 전체 시스템의 기준입니다
PAIDSCHEDULEDRECORDINGRECORDEDUPLOADINGPROCESSINGREADY녹화 실패
RecordingSession FAILED, PlayOrder REFUND_REQUIRED
업로드 실패
로컬 파일 유지, UPLOAD_FAILED 이벤트, 재시도 작업 생성
압축 실패
원본 대체 가능 여부 확인, PROCESSING_FAILED 저장
다운로드 만료
토큰 비활성화, 파일 만료 삭제, 삭제 로그 보관
스택 구성
이미 있는 딜링 자산을 재사용하고, 새 코드는 경계만 추가합니다
Frontend
- dilling-play
- Next.js App Router
- QR 결제와 다운로드
- 모바일 공개 페이지
Backend
- 기존 dilling-backend
- Spring Boot
- JPA 엔티티
- 결제 웹훅과 상태 머신
Gateway
- 기존 dilling-camera-gateway
- Node.js
- ffmpeg
- heartbeat와 job polling
Operations
- dilling-admin
- 세션 목록
- 재시도와 환불 표시
- 시설별 정산
RTSP 비노출
카메라 계정과 RTSP URL은 현장 장비 안에서만 사용합니다.
서명된 이벤트
게이트웨이 콜백은 장비 키 또는 HMAC 서명으로 검증합니다.
동의 버전 저장
결제 시점의 촬영 안내와 개인정보 동의 버전을 주문에 남깁니다.
만료와 삭제
영상 보관 7일을 기본으로 두고 토큰, 스토리지, 로컬 파일을 함께 만료 처리합니다.
Next decision