PokeClip 초기 계획에는 미디어 서버를 직접 구현할 부분이 많았습니다. 그러나 3인 팀이 확인하려던 제품 가치는 전송 프로토콜 자체가 아니라, 방송 중 지난 장면을 찾아 원하는 소리로 클립을 만드는 경험이었습니다. 수신·코덱·녹화 기반을 먼저 모두 만들면 그 경험을 검증하는 시점이 늦어질 수 있었습니다.
계획을 바꾼 계기는 OBS → SRT → 녹화·재생 스파이크가 MediaMTX로 성립한 것입니다. 저는 이 결과를 근거로 수신·녹화·라이브 재생은 MediaMTX에 맡기고, 파일 색인·복구·되감기 시간축·방송 회차는 자체 Go 계층에 남겼습니다. 조사와 구현에는 AI를 활용했고, 직접 소유할 범위를 고르고 확정하는 역할을 맡았습니다.
프로토콜 지원 목록 대신 우리 입력을 통과시켰습니다
MediaMTX가 SRT를 지원한다는 사실만으로 도입할 수는 없었습니다. OBS가 보내는 입력이 실제 녹화 산출물과 재생까지 이어져야 했습니다. 공식 송출 문서를 출발점으로 이 연결을 확인한 뒤, 직접 구현하던 범위 중 어떤 부분을 걷어낼 수 있는지 비교했습니다.
| 검토한 방법 | 얻는 것 | 남는 부담 |
|---|---|---|
| C/C++로 기반부터 구현 | 내부 동작을 폭넓게 제어 | 메모리·스레딩·코덱·전송 처리의 검토 |
| 범용 FFmpeg 프로세스 조합 | 기존 변환 기능 활용 | 서비스별 목록·프로세스 수명·실패 복구 연결 |
| MediaMTX + Go 자체 계층 | 확인한 수신·녹화 기반을 활용 | 외부 버전과 동작을 이해하고 유지 |
FFmpeg는 포장이나 변환의 대안으로 남겼습니다. 다만 FFmpeg의 입력·출력 기능을 조합해도 어느 방송의 원본을 언제 공개하고, 업로드 실패를 어떻게 복구할지는 따로 정해야 합니다. 변환 도구가 제품의 상태 관리를 대신하지는 않았습니다.
녹화 뒤에 남는 일을 기준으로 자체 계층을 정했습니다
파일이 만들어지면 다음 질문이 생깁니다. 어느 방송 회차의 파일인지, 방송 시간은 어디서 시작하는지, S3 업로드가 실패하면 무엇을 다시 시도해야 하는지 알아야 합니다. 편집 구간이 파일 경계에 걸친다면 겹치는 원본도 찾아야 합니다.
이 질문을 처리하는 Go 계층을 MediaMTX 옆에 두었습니다. 수신과 라이브 먹싱은 MediaMTX가 담당하고, 완성 파일의 색인·업로드 상태·재포장·정적 목록·회차 관리는 자체 코드가 담당하도록 나눴습니다. 두 계층은 녹화 파일, DB 행, 객체 키와 서비스 계약으로 연결됩니다. 저장·편집 규칙을 바꿀 때 전송 프로토콜 전체까지 수정하지 않도록 한 선택입니다.
후속 되감기 생산 경로의 팀 PR #192와 PR #196은 이 구분에 따라 제품 계층을 추가한 작업입니다. 각 부품은 병합됐지만, 전체 되감기 발행과 통합 완료 여부는 별도로 확인하고 있습니다.
직접 만들지 않은 코드는 검토하지 않아도 되는 코드가 아니었습니다
도입 뒤에는 녹화 파일의 시간 모델, 훅이 호출되고 실패하는 방식, 버전 변경 시 유지해야 할 전제를 알아야 했습니다. 직접 작성할 기반 코드를 줄인 대신 외부 프로젝트를 읽고 검증하는 책임이 생긴 셈입니다.
요구와 외부 동작이 어긋났을 때는 먼저 요구 자체를 조정할 수 있는지 살폈습니다. 제품 고유 규칙이라면 자체 계층에서 처리하고, 여러 사용자가 겪을 공통 결함이라면 재현과 회귀 테스트를 갖춘 상류 수정으로 다뤘습니다. 우회 코드가 쌓인다는 이유만으로 바로 포크하거나, 반대로 도입한 프로젝트를 고치지 않으려고 제품 요구를 무조건 바꾸지는 않았습니다.
개발 시간을 몇 퍼센트 줄였다는 비교 측정은 없습니다. 대신 확인 가능한 변화는 직접 구현할 책임의 범위입니다. 초기의 전체 직접 구현 계획에서, 2026년 10월에는 검증한 MediaMTX 기반 위에 PokeClip의 시간·저장·복구 규칙을 붙이는 구조로 바뀌었습니다.
이 선택은 도입 한 번으로 끝나지 않습니다. 버전을 교체한 뒤에도 같은 입력이 같은 산출 경로를 통과해야 MediaMTX를 채택한 근거가 유지됩니다. 처음의 계획을 지키는 일보다, 우리 입력을 통과시킨 근거와 직접 보장해야 할 규칙을 계속 확인하는 일이 더 중요했습니다.