프로젝트 기록

PokeClip의 Live와 DVR을 나누고, 다시 이어 붙이는 조건

Live·DVR URL 분리, DB 기준의 S3 매니페스트 발행, 자동 핸드오프의 조건을 연결합니다. 완료한 발행·되감기 연동과 진행 중인 시간축 검증을 구분합니다.

2026. 10. 28.7분 읽기

컨테이너는 살아 있고 설정 파일은 사라졌다: PokeClip Media 호스트의 재시작 경계

비정상 종료 시험에서 남은 컨테이너와 삭제된 비밀 파일이 충돌한 원인을 추적하고, 정리·마운트·재생성 조건을 함께 보완했습니다.

2026. 10. 28.6분 읽기

MediaMTX 앞 nginx가 확인해야 했던 것: 허용한 방송과 요청한 방송의 일치

경로의 방송 ID와 playback 쿼리를 대조하고, 정규화·중복 파라미터 우회 요청이 상류에 도달하지 않도록 검증한 기록입니다.

2026. 10. 28.6분 읽기

PokeClip의 DB 인증을 공통 모듈로 묶기: RDS IAM, TLS, 연결 풀의 경계

두 서비스의 세 연결 풀에 흩어진 DB 접속 정책을 pgconf로 모으고, IAM 토큰 재발급과 verify-full을 실험 RDS에서 검증한 기록.

2026. 10. 28.6분 읽기

오류 0건 뒤의 빈틈을 찾는 일: PokeClip · MediaMTX · Shakedown 개발 기록

공통 DB 인증, nginx 요청 검증, DVR 발행과 복구, MediaMTX 기여를 만든 판단과 검증을 연결한 기술 글 모음.

2026. 10. 16.18분 읽기

채팅이 많으면 하이라이트일까: 자동 탐지의 가설과 수동 대체 경로

채널별 기준선·고유 참여자·미디어 시간 보정을 검토한 연구 기록. 검증된 정확도 성과와 구분합니다.

클립을 파일로만 저장하지 않은 이유: 편집 레시피와 렌더의 경계

원본을 보존하고 편집 의도를 데이터로 남기면서, 되감기 재포장과 최종 렌더를 구분한 PokeClip 설계 기록.

테스트가 모두 통과해도 CI를 실패시켜야 할 때

테스트 제외 실험과 정수 교차곱으로 80% 커버리지 게이트의 실제 차단과 경계값을 검증한 기록.

CI 경로 필터를 바꾸려면 브랜치 보호부터 바꿔야 했다

미디어와 무관한 PR의 CI 표시를 없애며 필수 검사 포기, 적용 순서, 롤백을 함께 다룬 PR #163.

마이크를 고르는 문제에 상시 VAD가 필요할까

말소리 검출과 마이크 선택을 구분하고, 클립 구간의 RMS·미리듣기로 분석 범위를 줄인 설계 판단.

streamId의 의미를 바꾸기 전에 소비자의 조회부터 확인했다

방송 회차와 실제 미디어 경로를 분리하면서 기존 소비자의 조회와 배포 순서를 조율한 계약 변경.

백업이 있다는 말 대신 복원한 데이터로 확인했습니다

MySQL 수동 스냅샷과 MongoDB 데이터 볼륨을 새 대상에 복원하고, 이전 데이터·새 쓰기를 검증하며 자동 백업의 권한 한계를 구분했습니다.

TLS로 연결됐는데도 더 확인한 것: MySQL 호스트 검증과 MongoDB 장애 전환

MySQL의 정상 TLS와 잘못된 호스트 거부를 짝으로 확인하고, MongoDB의 암호화·단일 primary 장애 전환을 별도 검증했습니다.

잘못된 Java 구문이 ALLOW를 받았을 때: 보안 검사 앞에 구문 검사를 둔 이유

Semgrep 경로에서 잘못된 Java 구문이 ALLOW를 받은 반례를 유지하고, Tree-sitter 사전 검사로 SCAN_FAILED 경계를 보완했습니다.

재부팅 후에는 살아나고, 삭제 후에는 살아나지 않아야 했습니다

수동 시작이 필요했던 초기 결과를 보완하고, 제품 API 배포 뒤 재부팅 복구와 DELETE 뒤 미부활을 두 번의 실제 EC2 재부팅으로 확인했습니다.

MediaMTX 업그레이드에서 이미지만 바꾸면 놓치는 것들

MediaMTX 포크 전환 때 설정·훅·녹화 입력의 9개 전제를 재검증하고, 제품 이미지와 테스트·라이브러리의 버전 기준을 함께 맞췄습니다.

Shakedown에서 AI가 만들 수 있는 배포 구성을 먼저 제한한 이유

기존 Dockerfile과 지원 스택 규칙을 먼저 사용하고, 실패할 때만 Claude를 호출하도록 이미지 생성과 인프라 판단의 범위를 제한했습니다.

선택한 배포 계획을 AWS에 적용하고, 장애 뒤 복구까지 확인하기

저장된 배포 계획을 실제 AWS 자원에 연결하고, 기동·중지 시간 예산과 태스크·RDS 장애 뒤 복구를 별도 조건으로 확인했습니다.

시간값만 바꿨더니 8.10초가 39.87초가 됐습니다

같은 녹화 파일 10개에서 init 분리와 tfdt 변경을 분리해 S3·CDN 직접 재생의 시간축 조건을 확인했습니다.

늦게 끝난 writer가 새 재생목록을 덮는다면

DB 장부·작성 권한·세대·S3 조건부 PUT을 나눈 설계와 실제 S3에서 재시작 전후 발행을 확인한 결과를 설명합니다.

2026. 10. 15.8분 읽기

재포장 23.43→3.05ms: 같은 I/O 범위로 다시 측정한 이유

FFmpeg 프로세스 호출을 상주 Go 재포장으로 바꾸고, 같은 입력·읽기·쓰기를 포함한 200회 대조와 동시성 비용을 확인했습니다.

276개 파일을 회수해도 p95만으로는 부족했습니다: 알림 유실을 견디는 인덱서

완료 훅·파일 감시·재스캔을 나눠 설계하고, 정상과 알림 유실 네 조건에서 누락·중복과 마지막 파일 지연을 확인했습니다.

6초 창 때문에 라이브러리를 포크할 필요가 있을까

재생목록 창·실제 시청 지연·녹화 길이를 분리해 7조각·약 14초 창과 녹화 4초를 독립적으로 선택했습니다.

12번이 준비돼도 11번을 건너뛰면 안 됩니다: HLS 목록 경계 검증

연속 확정 구간과 최근 1시간 창을 계산하고, 10만 행 원장의 초기 계산·tail 갱신·전체 렌더 비용을 구분했습니다.

재생 조각이 만들어졌다는 것과 저장됐다는 것을 나누기

원본·재생 조각·init의 독립 상태, MinIO 업로드 확인, 16MiB 입력 경계와 동시성 비용을 설명합니다.

재접속의 0.2초 빈틈: 타임스탬프와 불연속 태그를 함께 바꾸기

이른 트랙 끝과 DISCONTINUITY 조합을 대조하고, 동일 init 조건에서 150조각·두 재접속 경계를 확인했습니다.

USER만 바꾸면 녹화가 깨진다: scratch와 새 볼륨의 권한 설계

런타임 root 작업 없이 녹화와 사이드카 읽기를 유지하기 위해 이미지 단계에서 소유권을 확정했습니다.

3.9초부터 자르면 첫 조각이 빠진다: 조회 계약과 8,020개 경계 검증

시작점 BETWEEN을 실제 구간 겹침으로 정정하고, 계약 확정·팀원 구현·SQL 정확성 시험을 구분했습니다.

2026. 10. 15.7분 읽기

끝난 재생목록은 다시 열지 않기로 했습니다

송출 키·녹화기 표식·논리 회차를 분리하고 ENDLIST 불변과 조건부 이전 회차 계승을 설계했습니다.

S3 파일 8개, 246.2→130.5ms: 새 저장 계층을 보류한 이유

4초 객체라는 작업 단위를 기준으로 새 저장 계층 도입을 보류하고 PUT·GET·동시성의 실제 측정 범위를 나눴습니다.

가짜 실패 행 1,121개가 남았다: 테스트 DB의 소유권부터 확인하기

테스트 종료 정리로 해결되지 않는 개발 DB 오염을 전용 DB와 명시적 소유 표식으로 차단한 과정입니다.

S3에는 올라갔는데 DB는 pending: 업로드 복구의 기준을 정하다

큐 접수·객체 생성·DB 완료를 나누고, 스위퍼의 접수 회차와 실제 PostgreSQL 상태 복구를 별도로 검증했습니다.

오류는 0건인데 61.94초가 보이지 않았습니다

141.97초 목록이 80.03초로 인식되고 60초 탐색이 약 87초로 이동한 현상에서 재생 성공 조건을 다시 정했습니다.

오디오 자동 배정이 방송자의 원래 설정을 망가뜨리지 않게 하기

본방 트랙 2의 440Hz 보존과 컬렉션별 복원을 대조했습니다. 자동 배정을 켜는 것만큼 끈 뒤의 상태도 확인한 기록입니다.

200인데 검은 화면이었다: 세 원인이 겹친 HLS 재생 문제 추적

서버 오류를 없애도 검은 화면은 남았습니다. GAP 7개와 hls.js 초기화를 차례로 조사하고 실제 재생·되감기까지 확인했습니다.

원본 요청 1,254건을 28건으로: 캐시 키와 인증 전달을 분리한 실험

401이 난 첫 시도에서 캐시 키와 원본 전달 정책을 분리했습니다. 원본 요청 1,254→28건과 97.95%의 분모, 403 검증을 함께 설명합니다.

2026. 10. 15.9분 읽기

편집을 맡긴다고 채널 게시까지 맡기는 것은 아니다

편집 결과를 보존하면서 게시 결정은 방송자에게 남기기 위해 제작·직접 업로드·자동 업로드와 승인 대기를 나눈 설계입니다.

채팅 수집을 Spring으로 바꾼 이유: 언어보다 먼저 정할 책임

채팅 담당자가 바뀌면서 Node 자산 재사용과 이후 변경 검토 비용을 다시 비교해 Spring 전환을 선택했습니다.

방송이 끝나기 전에 클립을 만들려면: 라이브·되감기·편집 경로 나누기

편집 원본에는 오디오 6개를 보존하고 되감기는 1개로 단순화했습니다. 같은 방송의 소비 목적이 달라 처리 경로를 나눈 이유입니다.

미디어 서버를 전부 만들려던 계획을 바꾼 이유

OBS→SRT→녹화·재생을 확인한 뒤 직접 구현할 범위를 파일 색인·복구·시간축으로 좁혔습니다.

오디오 6개가 보인다고 검증이 끝난 것은 아니었다

6트랙의 존재, 선택 추출, 실제 소리 보존을 나누어 검사했습니다. 무음 입력과 테스트 톤은 다른 것을 증명합니다.

본방 인코더 하나로 SRT도 보내기: 시작과 종료가 더 어려웠다

로컬에서 x264 인코더 1개로 RTMP·SRT를 함께 보냈습니다. 시작 전 GOP 설정과 실행 중 거절, 종료 수명을 함께 다뤘습니다.

OBS 안에 OAuth를 다시 만들지 않고 계정을 연결하는 방법

8자·10분·일회용 코드로 OBS를 연결하면서 시도 제한과 재사용 응답, 사용 기록의 보존 기간까지 정했습니다.

부분 목록으로 방송을 지우지 않기: 폐기한 경로 조정 설계에서 남은 판단

연결별 인증으로 전환하며 폐기한 path-reconciler 설계입니다. 부분 목록으로 삭제하지 않는 규칙과 인증 지연의 영향을 남겼습니다.

해시로 충분한 값과 다시 읽어야 하는 비밀: SRT 키 저장을 바꿀 계획

현재 PG의 passphrase를 Secrets Manager로 옮기는 전환을 준비 중입니다. 원문 사용과 키 대조를 나눈 이유 및 변경 조건을 설명합니다.

소스 약 10개를 직접 추적하는 대신 OBS 6트랙을 선택한 이유

약 10개 소스를 직접 추적하는 대신 필요한 편집 조합을 OBS 6트랙으로 표현하고 전달·복원을 확인했습니다.

API처럼 교체할 수 없는 서버: 방송 상태를 가진 미디어의 배포 경계

UDP 세션·진행 중 녹화·업로드 전 파일이 남는 미디어를 코어 API와 다르게 배치한 이유입니다.

치지직·SOOP 실시간 채팅 수집기를 만들며 겪은 문제들

방송 채팅 데이터로 하이라이트를 찾아내는 도구를 만들면서 부딪힌 문제들과 해결 과정, 그리고 한 번의 틀린 가설에 대한 기록이다.

2026. 07. 05.8분 읽기

채팅은 알고 있었다 - PokeClip 파이프라인을 갈아엎은 기록 (v3→v4)

지난 글에서 PokéClip의 v3 아키텍처를 소개했다. 영상(YOLO)·음성(Whisper)·채팅 세 신호를 병렬로 분석하고, 둘 이상이 임계치를 넘으면 하이라이트로 판정하는 "E 하이브리드" 구조였다.

2026. 07. 03.26분 읽기