자막 파일이 필요한가, 쓸 장면을 찾을 것인가: AutoSubs와 StoryToolkitAI

필요한 것이 자막 파일이라면 AutoSubs의 출력 형식과 편집기 연결을 먼저 보면 됩니다. 반대로 긴 인터뷰에서 필요한 발언과 장면을 찾아 편집으로 넘기려면 StoryToolkitAI의 검색·스토리 구성 기능이 더 가까운 비교 대상입니다. 말을 글로 옮기는 일과, 그 글에서 쓸 장면을 찾아 편집 순서를 만드는 일은 다릅니다.

자막을 전달할지, 편집할 구간을 찾을지에 따라 비교 기준이 달라집니다. 실제 앱 화면은 아닙니다.

두 도구 모두 전사를 다루지만, 최종적으로 손에 남겨야 할 것이 SRT인지, 편집기로 가져갈 선택 구간인지부터 정해야 합니다. 여기서는 2026년 10월 18일의 main 문서·소스에서 확인한 범위를 비교합니다. 프로그램을 설치·실행한 후기가 아니며, 독립적인 품질·효능 검증 결과도 제시하지 않습니다.

“인터뷰에 자막을 달아 달라”는 요청부터 풀어보기

직접 촬영했고 편집 권한을 확보한 인터뷰가 있다고 가정해 보겠습니다. 담당자가 “자막을 달아 달라”고 말했는데, 실제 요구는 두 가지일 수 있습니다.

하나는 이미 편집이 끝난 영상의 말을 받아 적고 자막을 붙이는 일입니다. 영상 순서는 바꾸지 않습니다. 오탈자, 화자 구분, 줄바꿈과 자막 시점이 주된 확인 대상입니다. 이때 전달할 결과가 SRT인지, 편집기 안의 자막 트랙인지, 디자인을 적용한 텍스트인지에 따라 살펴볼 연결 방식이 달라집니다.

다른 하나는 “지원 동기를 설명한 부분을 찾아서 앞에 놓고, 실패 경험은 뒤에 붙이자”는 요청입니다. 이때는 자막만 만들어도 편집이 끝나지 않습니다. 해당 발언을 찾고, 앞뒤 문맥을 읽고, 사용할 구간과 순서를 정해야 합니다. 검색 결과를 원본과 연결해 편집기로 넘기는 과정도 필요합니다.

같은 인터뷰라도 앞의 요청은 자막 제작, 뒤의 요청은 자료 탐색과 편집 구성에 가깝습니다. 실제 파일을 처리한 사례가 아니라, 결과물에 따라 도구를 나눠 고르는 가정입니다.

AutoSubs에서 확인할 것은 ‘어디에 자막을 남길 것인가’

AutoSubs 공식 README는 오디오·비디오를 입력해 로컬 모델로 전사하고, 자막과 화자를 수정하는 독립 앱 사용 방식을 설명합니다. 자막 파일을 전달하는 작업이라면 우선 이 범위를 보면 됩니다.

형식은 사용 경로를 나눠 읽어야 합니다. 루트 README는 독립 앱의 SRT·텍스트 내보내기와 클립보드 복사를 설명합니다. 현재 CLI 문서는 text, SRT, WebVTT, JSON을 구분합니다. JSON은 단어별 시점이 포함된 구조화된 전사 결과이고, 사람이 읽는 텍스트와는 용도가 다릅니다. 현재 main에는 GUI의 raw JSON 내보내기 추가 기록도 있지만, 이를 모든 배포판의 동일한 화면으로 단정할 수는 없습니다. 당시 latest 배포 연결은 v3.11.0이었습니다. raw JSON의 main 추가 기록만으로 그 배포판에도 포함됐다고 확인한 것은 아닙니다.

자막 파일이 아니라 편집기 안으로 보내려면 연결의 실체를 확인해야 합니다. ‘Adobe 지원’이라는 말만으로 편집 프로젝트 전체를 주고받는다고 생각하기 쉽지만, Adobe 통합 문서가 설명하는 것은 더 구체적입니다.

Premiere Pro에서는 SRT를 프로젝트로 가져온 뒤 caption track을 만듭니다. After Effects에서는 SRT를 읽어 항목별 텍스트 레이어를 만듭니다. 같은 SRT라도 편집기 안에서 만들어지는 대상이 다릅니다. Resolve에는 스타일을 적용한 자막을 보내는 경로가 있습니다. 이 차이는 이후 누가 어떤 방식으로 자막을 수정할지 정할 때 중요합니다.

또한 이 연결에는 Adobe CEP 확장이나 Resolve 브리지가 필요합니다. 파일만 내보내는 독립 사용과 호스트 앱 연결은 같은 조건이 아닙니다. README에는 Mac App Store판 DaVinci Resolve 미지원 경고도 있습니다. ‘Resolve 지원’이라는 짧은 소개보다 자신이 쓰는 배포판·버전·연결 방식에 관한 문서를 보는 편이 정확합니다.

설명용 개념도. Premiere의 SRT→caption track과 After Effects의 SRT→text layers는 다른 전달 방식이며 범용 NLE 프로젝트 내보내기가 아닙니다. 실제 가져오기 결과 화면은 아닙니다.

로컬 전사와 번역을 같은 말로 묶으면 생기는 오해

AutoSubs 루트 README에는 클라우드 없이 기기에서 처리한다는 표현이 있습니다. 전사 모델 설명과 선택적 번역까지 같은 범위로 읽으면 문제가 생깁니다. 앱 기술 README는 번역에 Google Translate를 적고 있으며, 현재 번역 코드에는 Google의 번역 엔드포인트로 네트워크 요청을 보내는 경로가 있습니다.

따라서 ‘모든 기능이 완전히 오프라인’이라는 설명보다는 전사는 로컬 모델, 선택한 번역 경로는 외부 서비스로 나누는 것이 맞습니다. 모델을 처음 내려받는 일도 오프라인 전사와는 별개입니다. 민감한 인터뷰라면 로컬 앱인지뿐 아니라 번역을 켰을 때 무엇을 외부로 보내는지도 확인해야 합니다.

이 구분은 오류를 읽을 때도 도움이 됩니다. 전사 결과가 만들어졌는데 외부 번역에 연결하지 못한 상황을 ‘로컬 음성 인식 모델이 전부 실패했다’고 해석하면 원인을 다른 곳에서 찾게 됩니다. 다만 특정 사용자의 장애 보고만으로 모든 환경의 안정성을 판단할 수는 없습니다.

한국어는 모델 이름까지 내려가서 봐야 합니다. 현재 README에는 Moonshine tiny-ko, SenseVoice, Cohere 항목에 한국어가 명시돼 있습니다. 반면 어떤 모델은 영어 전용이거나 다른 언어 묶음을 대상으로 합니다. ‘지원 언어가 많다’는 앱 소개는 선택한 모델이 한국어에 맞는지까지 대신 답하지 않습니다. 프로젝트 안의 정확도 별점 역시 자체 상대평가이지, 이 글에서 실시한 한국어 벤치마크가 아닙니다.

StoryToolkitAI는 전사 다음에 무엇을 찾을지 묻습니다

StoryToolkitAI 공식 README는 전사와 영상 인덱싱, 검색, 스토리 구성을 함께 설명합니다. 앞의 가정에서 “지원 동기를 말한 대목을 찾아 앞에 놓자”는 요청이라면, 자막 출력보다 이 부분이 먼저 필요합니다.

FEATURES 문서의 의미 검색은 정확히 같은 단어가 있는지만 찾는 방식과 다릅니다. 검색어와 뜻이 가까운 문장을 순위로 보여주고, 결과를 선택하면 전사 위치를 확인할 수 있도록 설명돼 있습니다. 여러 전사와 프로젝트 자료를 함께 찾는 기능도 있습니다.

하지만 의미가 가깝다는 것은 편집 의도에 맞는다는 뜻과 같지 않습니다. ‘실패를 통해 배운 경험’을 찾았는데 남의 사례를 인용한 부분이 나올 수도 있고, 질문자의 말이 후보에 섞일 수도 있습니다. 결과의 순위를 정답으로 받아들이기보다 누가 어떤 문맥에서 말했는지 원본과 함께 읽는 것이 편집자의 몫입니다. 이 예시는 검색 오류를 실제 관찰했다는 뜻이 아니라, 검색 결과를 채택할 때 적용할 판단 기준입니다.

한국어 전사와 한국어 의미 검색도 따로 봐야 합니다. StoryToolkitAI가 Whisper 기반 다국어 전사를 사용한다는 설명만으로 한국어 질문의 검색 적합성까지 확인됐다고 말할 수 없습니다. 이 비교에서는 한국어 음성 정확도와 한국어 검색 결과를 직접 시험하지 않았으므로, 어느 쪽이 더 정확하다는 순위는 제시하지 않습니다.

검색한 구간은 편집기로, 새 스토리는 검토 대상으로

StoryToolkitAI를 ‘찾기만 하는 도구’로 한정하는 것도 부족합니다. README에는 LLM Assistant로 story와 selection을 만들고, Story Editor에서 구성을 다루는 기능이 포함돼 있습니다. Story Editor 출력에는 EDL·XML·Fountain이, 전사 출력에는 SRT·TXT·AVID DS·Fusion Text node 등이 문서화돼 있습니다. 기존 SRT를 가져오는 경로도 있습니다.

여기서 자막 SRT와 편집 구성을 넘기는 EDL/XML은 서로 다른 결과물입니다. 앞의 인터뷰에서 발언 순서를 바꾸려면 구간을 골라 스토리를 구성한 뒤 편집기로 넘길 작업이 남습니다. EDL/XML을 내보낸다는 사실이 자막·화면·음악까지 완성된 영상을 받는다는 뜻은 아닙니다. 원본 연결, 시간코드와 프레임레이트, 잘린 문맥은 후속 편집에서 확인할 부분입니다.

Resolve 통합 역시 조건이 있습니다. README는 DaVinci Resolve Studio 18 이상을 명시합니다. AutoSubs의 Resolve 연결과 이름이 비슷하다고 동일한 호스트 조건이나 자막 구조를 가정하면 안 됩니다. StoryToolkitAI는 다른 편집기와 독립적으로 사용할 수 있지만, 그 사실을 모든 NLE에 대한 직접 통합으로 확대할 수도 없습니다.

전사·인덱싱·검색은 로컬 기능으로 설명돼 있고, Assistant는 OpenAI 같은 외부 제공자 또는 로컬 LLM을 선택할 수 있습니다. 외부 Assistant를 사용하면 선택해 보낸 문맥과 메시지가 전송됩니다. 앱이 로컬에서 실행된다는 설명과 외부 Assistant의 데이터 흐름을 나눠 읽어야 하는 이유입니다.

배포판 차이도 남습니다. 확인 당시 최신 standalone release 연결은 v0.25.1이었지만 main의 version.py는 1.0.0이었습니다. 공식 README도 standalone이 소스보다 늦을 수 있다고 경고합니다. 소스 문서에 적힌 모든 기능을 현재 내려받는 패키지의 기능으로 그대로 옮겨 적지는 않았습니다.

설명용 일러스트. 검색 후보의 원본 문맥 검토와 편집기에서의 후속 편집은 남습니다. 실제 실행 결과가 아닙니다.

넘길 파일을 적으면 선택이 간단해집니다

“최종 영상 순서는 그대로 두고 자막만 전달한다”면 AutoSubs의 SRT 등 출력 형식과 대상 편집기 연결을 검토하면 됩니다. 이때 중요한 질문은 한국어에 맞는 모델인지, 번역을 쓰는지, 자막을 받은 사람이 파일·caption track·텍스트 레이어 중 무엇을 수정할지입니다.

“여러 인터뷰에서 필요한 대목을 찾아 순서를 짠다”면 StoryToolkitAI의 의미 검색과 Story Editor, EDL/XML 전달 범위를 살펴볼 이유가 있습니다. 이때 확인할 것은 검색 후보의 문맥, 편집 구성, 원본과 시간 정보의 연결입니다.

라이선스는 마지막에 따로 확인해야 합니다. AutoSubs 코드는 MIT지만 선택적 MMS 강제 정렬 가중치는 CC BY-NC 4.0, README상 Orukeet 가중치는 CC BY-SA 4.0입니다. StoryToolkitAI 코드는 GPL-3.0이며 사용하는 모델의 조건은 별도입니다. 앱의 코드 라이선스 하나로 모든 모델을 상업적으로 사용할 수 있다고 판단하면 안 됩니다.

두 도구 중 하나가 다른 하나를 전부 대신하는지는 이 비교의 질문이 아닙니다. 자막을 전달할 것인지, 쓸 장면을 골라 편집으로 넘길 것인지부터 정하면 살펴볼 문서와 남은 검수가 달라집니다.

코드의 MIT 허가를 선택한 전사 모델의 조건에 그대로 옮기지 않는 이유는 오픈소스 AI의 코드·가중치 구분에서도 설명했습니다.

출처와 확인 범위

확인일: 2026년 10월 18일 KST. 아래 현재 문서는 개별 게시일이 미표기되어 있습니다. 기능 범위를 확인했으며 프로그램 실행·한국어 품질·시간 절감은 측정하지 않았습니다.

• tmoroney, AutoSubs README.md, 모델·한국어 명시·라이선스·사용 경로.
• tmoroney, CLI.md 및 Adobe Extension README, 출력 형식과 호스트별 SRT 처리.
• tmoroney, AutoSubs App README 및 translation_client.rs, 선택적 외부 번역 경로.
• octimot, StoryToolkitAI README.md 및 FEATURES.md, 검색·편집 전달·로컬 및 외부 기능 구분.