TTS를 붙이면 자연스럽게 MP3를 어디에 올릴지 생각하게 된다. R2 같은 public storage에 올리고, CDN으로 배포하고, 글마다 audio asset을 연결하는 구조도 가능하다. 하지만 지금 필요한 것은 공개 음원 배포가 아니었다.
먼저 검증해야 할 것은 개인 작업 루프였다. Mac mini에서 생성하고, 캐시하고, 브라우저가 안정적으로 재생하고, 실패하면 readback할 수 있는 구조가 필요했다.
현재 판단은 local cache + audio API다. metadata는 local SQLite에 둔다. audio file은 Mac mini cache에 둔다. API는 job 생성, 상태 readback, audio endpoint를 제공한다. 브라우저 재생에 필요한 Range streaming은 API contract로 푼다.
이 방식은 생성 비용과 반복 재생을 통제하기 좋다. 실패했을 때 원인을 확인하기도 쉽다. public distribution을 먼저 만들면 저장소, 캐시 무효화, 비용, 공개 범위가 한꺼번에 따라온다.
R2를 쓰지 않겠다는 뜻은 아니다. public sharing이나 scale 요구가 생기면 다시 보면 된다. 다만 지금은 public asset이 아니라 local voice loop가 검증 단위다.
이 순서가 OkayJing답다. 먼저 로컬에서 생성, 저장, 재생, readback을 닫는다. 그 다음에 공개 배포가 필요해졌을 때 외부 storage를 붙인다.
음성 기능을 붙일 때 처음부터 public asset pipeline을 만들 필요는 없다. 먼저 로컬에서 한 문장을 생성하고, 캐시에 저장하고, 브라우저가 Range 요청으로 재생할 수 있는지 확인하면 된다. 이 단계가 닫히기 전에는 CDN이나 object storage를 붙여도 문제가 어디서 생겼는지 알기 어렵다.
좋은 MVP는 단순하다. generate API는 텍스트와 voice 옵션을 받아 파일을 만들고, status API는 생성 상태와 cache key를 알려주고, audio API는 Range streaming을 지원한다. 사용자가 실제로 다시 듣는지, 생성 시간이 허용 가능한지, 캐시가 얼마나 쌓이는지를 본 뒤에 R2 같은 외부 storage를 붙이면 된다.
Post Q&A
TTS를 R2에 올리기 전에 — Mac mini local audio API로 먼저 검증하기 전체를 기준으로 질문과 피드백을 받아요.답을 본 뒤에는 이 내용을 댓글로 달아서 서징에게도 물어볼 수 있어요. 작성자가 직접 볼 수 있어요!