Toris Studio 회고: 로컬 TTS와 영상 검증을 하나의 작업 흐름으로

Toris Studio를 만들며 더 신경 쓰게 된 것은 영상 생성 다음의 일이었다. 대본을 고치고, 음성을 바꾸고, 결과물을 검수하고, 플랫폼에 올릴 준비를 하는 과정까지 이어져야 다음 영상도 만들 수 있었다. 생성 버튼보다 이 연결이 개발 과제에 가까웠다.

10월 1일에는 ClubLog 홍보 영상을 Threads, Instagram, YouTube Shorts에 올릴 수 있도록 키워드와 게시 문구를 정리해 달라고 요청했다. 당시 기록에는 문구·커버·메타데이터가 준비됐다고 남아 있지만, 게시에 필요한 연결은 갖춰지지 않았다. 확인된 산출물은 게시 준비였고, 실제 발행은 별개의 일이었다.

이 글은 2026년 9월 30일~10월 2일의 작업 대화를 바탕으로 정리했다. ClubLog 음성 교체와 약 58초 쇼츠 제작의 실행 결과는 당시 보고된 범위로 다루고, 작업 구조는 프로젝트 코드·문서와 대조했다.

실제 편집기 화면이 아니라 작업 관계를 설명한 개념도다. 생성·검증·게시의 완료 상태를 나타내지 않는다.

화면에 보여 줄 말, 읽을 말, 근거를 나눴다

장면에는 화면 제목과 설명, 내레이션, 출처, 미디어를 따로 두었다. 장면의 역할과 배치 방식도 구분했다. 같은 근거 장면이라도 제품 화면을 크게 보여 줄지, 설명과 나란히 놓을지는 별개의 선택이었다.

이 분리는 수정 범위를 다루는 데 의미가 있다. 화면 제목을 짧게 다듬는다고 음성까지 다시 만들 필요는 없다. 출처를 보강한다고 내레이션의 호흡까지 바꿀 필요도 없다. 모든 내용을 대본 한 덩어리에 넣으면 어느 수정이 어느 결과물에 영향을 주는지 추적하기 어렵다.

장면의 입력	맡기는 역할	별도로 확인할 것
화면 문구	읽고 이해할 핵심	작은 화면에서도 읽히는가
내레이션	귀로 듣는 설명	발음·호흡·문장 길이가 적절한가
출처	주장에 대한 근거	그 자료가 해당 문장을 뒷받침하는가
미디어	제품 화면과 시각적 설명	실제 파일이 있고 내용이 맞는가

발음 처리에서도 같은 구분이 필요했다. 쇼츠 제작 기록에는 영어 제품명을 그대로 합성했을 때 발음이 흔들린 구간이 있었다. 대응은 화면의 공식 표기를 유지하면서 음성 입력에 한국어 발음 표기를 쓰는 방식이었다. 화면의 정확성과 귀로 듣는 전달력을 서로 다른 입력으로 다룬 것이다.

재현을 위한 저장 범위도 중요했다. 프로젝트 JSON에 미디어 파일이 함께 들어가는 것은 아니므로, 장면 데이터와 참조하는 음성·이미지를 함께 보관해야 한다. 데이터는 남아 있는데 파일이 사라지면 다음 수정 작업을 이어 갈 수 없다.

화면비를 바꾸는 것과 이야기를 줄이는 것은 달랐다

가로형, 세로형, 쇼츠를 지원하면서 눈여겨본 것은 해상도보다 장면 구조였다. 짧은 홍보 영상은 관심을 끄는 도입, 효용, 실제 제품 화면, 행동 유도로 빠르게 이어진다. 긴 영상에는 배경과 문제, 설명, 근거, 한계를 다룰 여유가 있다.

세로 화면으로 바꿔도 긴 설명의 순서는 그대로 남는다. 현재 편집기의 포맷 버튼은 화면 포맷을 바꾸며, 기존 장면을 새 대본으로 자동 재작성하지 않는다. 포맷별 장면 구조는 템플릿에서 따로 선택한다. 포맷을 선택하는 일과 무엇을 남길지 편집하는 일은 따로 해야 했다.

쇼츠 제작 문서에도 원문 전체를 나열하지 않고 일부 주제로 압축한 방향이 기록돼 있다. 짧은 영상의 편집은 글자 크기보다 정보의 양을 줄이는 판단에서 시작했다.

Linux 제작 기록에는 긴 영상의 새 설명 장면에 내레이션이 부족해 검토용 초안으로 구분한 사례도 있다. 파일이 렌더되고 길이가 늘었다고 게시 가능한 영상이 된 것은 아니었다. 포맷 전환 결과를 볼 때는 이런 빈칸도 확인해야 한다.

로컬 TTS를 설치하니 운영할 서버가 생겼다

내가 설치 후 사용법을 확인한 Mac 기본 구성은 Qwen3-TTS 1.7B CustomVoice 8-bit, MLX, Sohee, Korean이다. 합성 API는 장면별 WAV를 저장하고 실제 음성 길이를 반환하며, 편집기는 그 길이에 여유 시간을 더해 장면 길이를 맞춘다. Qwen3-TTS 자체의 한국어 지원과 Sohee 음성은 공식 모델 문서에서도 확인할 수 있다. MLX와 8-bit 구성은 내 프로젝트의 로컬 실행 선택이며, 이 글에서 서버가 현재 실행 중이라고 확인한 것은 아니다.

설치 이후 내가 다시 물었던 것도 서버를 어떻게 시작하고 멈추는지였다. 이 질문이 운영 부담을 잘 보여 준다. 모델이 로컬에 있다는 것과 합성 서비스가 실행 중이라는 것은 다른 상태다. Studio 화면이 열려 있어도 음성 서버가 종료돼 있으면 합성 작업은 이어지지 않는다.

현재 실행 항목에는 설치와 시작 스크립트가 있지만, 중지·상태 확인·재시작을 위한 전용 패키지 명령은 없다. 설치 안내에 더해 실행 여부와 종료법도 사용 흐름에 포함해야 한다. 상태 확인 응답이 온다고 실제 문장 합성까지 검증된 것으로 볼 수도 없다.

상주 방식은 매번 모델을 불러오는 일을 줄이기 위한 선택이지만, 관리할 프로세스도 하나 늘린다. 모델 다운로드, 의존성, 서버 상태, 로그와 생성 파일을 다뤄야 한다. 외부 음성 API 호출을 줄이는 선택이 운영 부담까지 없애 주지는 않았다.

환경을 옮기는 문제도 남았다. Linux 문서에서는 편집·렌더와 새 음성 합성을 구분한다. 기존 음성을 가져오는 경로는 있어도 대체 합성 구성이 검증된 것은 아니다. Mac의 로컬 구성을 다른 환경에서도 그대로 동작한다고 일반화하지 않기로 했다.

발음, 오디오, 최종 파일을 따로 검수한다

ClubLog 음성 교체 기록에는 원래 대본을 기준으로 재합성하고 로컬 음성 인식으로 받아쓰기를 확인했다고 남아 있다. 원문이 있는데 음성 인식 결과를 새 원문처럼 취급할 이유는 없다. 받아쓰기는 의심 구간을 찾는 보조 수단이다.

내가 정리한 검수는 세 층으로 나뉜다.

1. 내용·발음: 원래 대본을 기준으로 브랜드명, 종목명, 숫자, 외래어를 확인한다. 인식 결과가 맞아도 직접 들었을 때 부자연스럽거나 단어가 빠지면 수정한다.
2. 오디오·편집: 문장 끝이 잘리는지, 긴 침묵이 생기는지, 음량이 튀는지 확인한다. 자막 시간도 실제 발화와 맞춰 본다.
3. 최종 파일: 게시할 MP4 전체가 정상 디코딩되는지, 검수한 파일과 같은 결과물인지 확인한다.

미리보기 재생과 최종 MP4 검증도 다르다. Remotion은 React 안의 Player 미리보기와 영상 파일 렌더 API를 제공한다. 내가 둘을 작업 흐름에 넣었다고 해서 한쪽의 성공이 다른 쪽의 품질까지 보장하는 것은 아니다.

음성 교체 때는 이미 만든 화면을 유지하고 오디오만 교체했다는 기록도 있다. 이때 비교할 것은 전체 파일의 해시가 아니라 영상 스트림이다. 오디오가 바뀌었으므로 전체 파일은 달라지는 것이 정상이다. 다만 이 방식이 모든 편집에서 화면을 다시 인코딩하지 않아도 된다는 뜻은 아니다.

세 검수는 서로를 대신하지 못한다. 현재 자동 품질 점수도 음성 연결 여부와 대본 밀도 등을 확인할 뿐 발음의 정확성을 판정하지는 않는다. 발음이 정확해도 오디오가 잘릴 수 있고, 디코딩되는 파일에도 대본 오류가 남을 수 있다. 하나의 성공 표시 대신 무엇을 어떤 기준으로 확인했는지를 남겨야 했다.

게시 준비의 끝을 명확히 남기기

ClubLog SNS 작업에서 가장 분명한 경계는 준비와 발행 사이였다. 제목·캡션·커버·키워드는 확인할 수 있는 산출물이다. 그렇지만 업로드 성공, 예약 등록, 실제 공개에는 각각 다른 증거가 필요하다. 메타데이터에 공개 설정을 적어 놓았다고 영상이 공개되는 것은 아니다.

Studio의 YouTube 업로드 기본값도 비공개다. 따라서 업로드를 했다면 공개 상태를 다시 확인해야 한다. 앞으로 게시 상태를 남길 때는 준비·업로드·예약·공개를 구분하고, 해당 상태를 확인한 근거를 붙이려 한다.

다음 제작에 적용할 기준은 이렇다.

• 장면의 화면 문구·내레이션·출처·미디어를 각각 확인한다.
• 출력 화면비와 별도로 대본의 목적·순서·길이를 검토한다.
• 음성 서버의 상태와 실제 짧은 문장 합성을 따로 확인한다.
• 고유명사와 숫자는 원문과 비교하며 직접 듣는다.
• 문장 끝·침묵·음량·자막과 장면 시간을 검수한다.
• 최종 파일의 디코딩과 동일성을 확인한다.
• 게시 준비와 실제 공개를 구분하고, 공개할 내용에서 개인 정보와 비밀값을 제거한다.

남은 일은 이 기준을 반복 가능한 운영 흐름으로 만드는 것이다. 서버 재시작 관리, 환경별 합성, 자막 정렬, 게시 상태 추적까지 해결됐다고 할 수는 없다. 합성과 렌더의 성능도 따로 측정해야 한다.

AppForge에서 빌드 성공과 제품 완성을 구분했던 경험과 마찬가지로, 영상에서도 출력 파일이 있다는 사실만으로 작업이 끝나지는 않았다. 다음 영상에서는 생성 결과에 더해 수정 근거, 검수 결과, 실제 게시 상태까지 남길 수 있는 스튜디오를 만들고 싶다.

편집 검토: 2026년 10월 2일 코드와 음성·영상 제작 문서를 읽기 전용으로 확인했다. 합성·렌더·디코딩·SNS 발행을 재실행하지 않았으며, 실행 결과는 당시 작업 보고를 기준으로 정리했다. 실행 시간·메모리·조회수 등의 성과는 추정하지 않았다.