Livepack V4 이슈 — 공유 완료 / 결정 대기
작성 요령
livepack-v4-issues.md에서 공유 완료 / 결정 대기 항목을 이동받는 문서- 번호는 이 문서의 마지막 번호 +1로 순서대로 부여
- 결정 완료 시 →
livepack-v4-issues-done.md로 이동, 이 문서에서 삭제 후 번호 리셋
1. billingKey account DB 이관
현황
billingKey(결제 정보)가 상품별 DB(videopack, livepack 등)에 각각 저장되어 있음. 계정별 결제 정보이므로 상품별로 분리되어 있으면 안 됨.
문제
- 동일 계정의 billingKey가 상품 DB마다 중복 관리
- 결제 수단 변경 시 모든 상품 DB에서 개별 업데이트 필요
- 계정 단위 결제 정보 조회가 어려움
해결 방안
- billingKey를 account DB로 이관 (계정 단위 단일 관리)
- 각 상품 DB에서는 account DB를 참조하여 결제 처리
- 기존 상품 DB의 billingKey 컬럼/테이블은 이관 후 제거
영향 범위
- account DB 스키마 변경 → videopack-api에도 영향
- Phase 1 (상품 사양 확정) 시점에 같이 결정
결정 필요 사항
- 계정 분리 방식 (컬럼 추가 vs 매핑 테이블)
- 소유자는 양쪽 공유인지, 관리자만 분리인지
- 기존 데이터 마이그레이션 방법
2. CloudFront + MediaPackage Origin 등록 이슈
현황
라이브팩 상품 생성 시 CloudFront Distribution을 기본으로 1개 생성하여 모든 라이브 채널에 대응하려 했으나, MediaLive 채널 생성 시 MediaPackage Channel Group을 선택해야 하므로 origin이 채널 생성 시점에 결정됨.
문제
- 하나의 CF Distribution으로 모든 채널을 커버하려면, 채널 생성 시마다 해당 MediaPackage origin을 CF에 등록해야 함
- CF origin 추가는 API로 가능하지만, origin path/behavior 설정이 채널마다 달라짐
- 채널 삭제 시 origin 제거도 필요
검토 필요
- 채널 생성 시 자동으로 CF origin 등록하는 프로세스 구현 여부
- 채널별 CF Distribution을 별도 생성하는 방식 vs 하나의 CF에 origin 동적 추가 방식
- MediaPackage Channel Group과 CF origin 매핑 관리 방법
3. IVS Chat 방송 종료 시 채팅 종료 처리
현황
IVS Chat에는 ChatRoom 전체 연결 해제 API가 없음. DisconnectUser는 userId를 지정해야 하고 한 명씩만 가능.
방안
| 방안 |
설명 |
장단점 |
| A: 클라이언트 처리 |
플레이어가 방송 종료 감지 → WebSocket 직접 닫음 |
추가 API 불필요, 클라이언트 의존 |
| B: SendEvent 신호 |
방송 종료 webhook에서 SendEvent("app:live:ended") 전송 → 클라이언트 수신 후 닫음 |
서버에서 신호, 더 확실 |
- 어느 방안이든 토큰 재발급 시
status !== LIVE이면 거부되므로 재접속은 불가
- 기존 연결은 토큰 만료까지 유지됨 (최대 session_duration_minutes)
결정 필요
- A vs B 선택 (또는 A+B 병행)
- 토큰 만료 전 기존 연결 유지 허용 여부