생방송에서 재미있는 장면을 발견해도 방송이 끝날 때까지 기다리고, 긴 영상을 내려받아 구간을 찾아야 한다면 클립을 올리는 시점은 늦어집니다. PokeClip은 방송을 받는 도중에도 지난 장면을 찾아 편집하는 서비스로 시작했습니다. 여기에 배경음악을 제외한 소리를 고르는 요구가 더해지면서, 같은 방송을 받아도 시청용 파일과 편집 원본을 같게 만들 수 없었습니다.
저는 3인 팀에서 전체 구조와 미디어·인프라를 맡아 입력 형식, 상태 변경 시점, 실패 시 책임을 조율했습니다. 설계 초안·조사·구현·검증에는 AI를 활용했고, Spring 코어와 렌더 워커, 웹, OBS 플러그인은 팀원이 주로 구현했습니다. 이 글에서는 그중 원본 보존과 빠른 시청이 충돌한 지점에서 처리 경로를 나눈 과정을 설명합니다.
재생하기 쉬운 파일이 편집하기 좋은 원본은 아니었습니다
시청자는 지금 장면을 바로 보고 싶지만, 편집자는 나중에 고를 수 있도록 여러 오디오가 남아 있어야 합니다. 되감기는 이미 저장한 파일을 연속으로 재생하고 특정 시점으로 이동할 수 있어야 합니다. 방송 하나에서 출발하더라도 소비하는 방식은 세 가지였습니다.
| 사용 목적 | 필요한 데이터 | 지켜야 할 조건 |
|---|---|---|
| 라이브 시청 | 현재 방송의 HLS 목록·미디어 | 저장·편집 작업의 완료를 기다리지 않음 |
| 되감기 | 연속 재생에 맞춘 영상 1개·오디오 1개 | 여러 파일의 시간축과 탐색 가능성 |
| 클립 편집 | 분리된 오디오 6개를 보존한 원본 | 아직 선택하지 않은 재료도 남김 |
저장 단계부터 첫 오디오만 남기면 재생은 단순해지지만, 편집할 때 음악만 제외할 재료가 사라집니다. 반대로 6개 오디오를 모든 시청 경로에서 다루면 시청자가 쓰지 않는 트랙까지 목록과 플레이어가 처리해야 합니다. 그래서 편집 원본에는 6개를 보존하고, 되감기용 파일은 영상 1개·오디오 1개로 만들도록 산출물을 나눴습니다.
미디어 서버가 만든 파일에 방송 시간을 붙였습니다
OBS가 본방과 함께 멀티오디오를 SRT로 보내면 MediaMTX가 이를 수신하고 녹화합니다. 그 옆의 Go 계층은 완성된 파일의 방송 시간과 위치를 DB에 기록하고 S3 업로드 상태를 관리합니다. 수신 기반은 MediaMTX 공식 문서, 전체 연결은 당시 시스템 아키텍처에 정리돼 있습니다.
파일이 존재한다는 정보만으로는 클립을 만들 수 없었습니다. 어느 방송 회차의 어느 구간인지 알아야 편집 범위와 겹치는 원본을 찾을 수 있고, 업로드가 끝났는지 알아야 다음 작업에 넘길 수 있습니다. 따라서 파일 이름뿐 아니라 DB 행, 객체 키, 방송 식별자와 상태가 바뀌는 시점을 서비스 간 계약으로 맞췄습니다.
편집 요청은 원본을 덮어쓰는 대신 구간·크롭·오디오 트랙·자막을 레시피로 남기도록 설계했습니다. 되감기를 위한 재포장은 압축된 미디어를 재배치하는 작업이고, 크롭이나 자막을 적용하는 최종 렌더는 픽셀을 바꾸는 작업입니다. 둘을 나누어야 재포장이 끝난 상태와 편집 결과가 완성된 상태를 구별할 수 있습니다.
경로를 나눈 만큼 파일 사이의 정합성을 확인해야 했습니다
재생 요청은 정적 목록과 미디어 객체를 읽고, 목록 생성은 별도 발행 경로에서 맡는 방향을 택했습니다. 읽을 때마다 목록을 만들 필요는 줄어들지만, 원본과 재생용 객체가 함께 존재하며 DB 상태와 S3 객체 생성 시점이 어긋날 수 있습니다. 여러 파일의 시간축을 이어 붙이고 업로드 실패 뒤 복구하는 일도 Go 계층에 남았습니다.
초기 멀티오디오 실험에서는 녹화 파일 61개와 DB 61행을 대조했습니다. 오디오 6개가 녹화에 남았는지와 원하는 트랙을 선택해 추출할 수 있는지도 따로 확인했습니다. 이 검사는 해당 실행에서 원본과 색인이 대응한다는 근거입니다. 업로드 장애 후 복구, 재포장 연속성, 탐색은 각각 다른 실패 조건이므로 별도 항목으로 다뤘습니다.
2026년 10월 15일 판본에서는 개별 생산자와 렌더 부품의 병합·검증 기록이 있고, 되감기 발행 계층과 dev-media 연동은 진행 중입니다. 전체 사용자 흐름을 운영 완료한 상태는 아닙니다.
이 구조에서 중요한 것은 경로가 몇 개로 늘었는지가 아닙니다. 시청을 단순하게 만드는 변경이 편집 재료를 없애지 않고, 저장 성공 표시가 실제로 사용할 수 있는 객체와 맞아야 합니다. 방송 중 클립을 만드는 요구를 파일 종류와 상태 전이로 풀어낸 뒤부터, 각 서비스가 무엇을 확인하고 다음 단계에 넘겨야 하는지 구체적으로 검토할 수 있었습니다.