--- title: "야프스냅, GPU 없이 유튜브·틱톡 영상을 로컬에서 텍스트로 뽑아주는 도구" published: 2026-05-20T21:28:28.000Z canonical: https://jeff.news/article/2969 --- # 야프스냅, GPU 없이 유튜브·틱톡 영상을 로컬에서 텍스트로 뽑아주는 도구 야프스냅은 유튜브, 틱톡, 엑스, 인스타그램 영상이나 로컬 오디오 파일을 CPU만으로 텍스트 변환해주는 오픈소스 도구다. 첫 실행 때 약 80MB 모델을 내려받고 나면 이후에는 클라우드나 API 키 없이 로컬에서 동작한다. - 야프스냅(yapsnap)은 영상 URL이나 오디오 파일을 그냥 텍스트 파일로 뽑아주는 명령줄 도구임 - GPU 필요 없음 - 클라우드 API 필요 없음 - 실행하면 현재 작업 디렉터리 아래 `./transcripts/`에 UTF-8 텍스트 파일을 만들어줌 - 지원 범위가 꽤 실용적으로 잡혀 있음 - 유튜브, 유튜브 쇼츠, 엑스, 틱톡, 인스타그램 릴스, 직접 미디어 링크를 처리함 - 로컬 파일도 가능하고, ffmpeg가 디코딩할 수 있는 mp3, mp4, m4a, wav, webm, mov, mkv, aac, opus, ogg, flac 계열을 받음 - URL 다운로드는 yt-dlp가 맡고, 오디오 디코딩은 ffmpeg가 맡음 - 첫 실행 때 약 80MB 모델을 한 번만 내려받고, 이후에는 오프라인으로 돈다 - macOS는 `~/Library/Caches/yapsnap/`에 캐시됨 - 리눅스는 `$XDG_CACHE_HOME/yapsnap/` 또는 `~/.cache/yapsnap/`을 씀 - 윈도우는 `%LOCALAPPDATA%\yapsnap\`에 저장됨 - 오디오는 외부로 전송되지 않고, 실행 사이에 남는 상태도 캐시된 모델뿐이라고 설명함 > [!IMPORTANT] > 이 도구의 포인트는 ‘최고 정확도’보다 ‘내 노트북 CPU에서, API 키 없이, 영상 길이보다 빠르게 텍스트를 얻기’에 가까움. - 기본 모델은 Kroko English이고, CPU에서 빠르게 돌도록 잡혀 있음 - 스트리밍 Zipformer2 트랜스듀서 기반의 INT8 오닉스 모델이고 크기는 약 80MB임 - 기본값으로 `--speed 1.5`를 써서 전사 전에 오디오를 빠르게 만들며, 작성자는 이 설정이 정확도 손실을 크게 만들지 않으면서 시간을 약 3분의 1 줄인다고 설명함 - 더 빠르게 원하면 `--speed 2.0`, 잡음이 많거나 말이 빠르면 `--speed 1.0`을 권장함 - 타임스탬프도 선택적으로 붙일 수 있음 - 기본 출력은 인식된 텍스트를 한 문단으로 내보냄 - `--timestamps`를 켜면 `[MM:SS]` 형식으로 문장 단위 타임스탬프를 붙임 - 빠른 속도로 전사해도 타임스탬프는 원본 오디오 시간 기준으로 다시 맞춰짐 - 다만 자막 제작용 초정밀 정렬이 아니라, 탐색용으로 충분한 수준이라고 못 박음 - 설치와 의존성은 꽤 작게 유지하려는 쪽임 - 파이썬 모듈 하나와 의존성 세 개가 전부라고 설명함 - 주요 의존성은 sherpa-onnx, numpy, yt-dlp임 - 설치하면 `yapsnap`과 별칭인 `transcribe` 명령이 같이 생김 - ffmpeg는 운영체제별 패키지 매니저로 따로 설치해야 함 - 영어 외 언어는 모델을 갈아끼우는 방식임 - 프랑스어, 독일어, 스페인어, 이탈리아어, 포르투갈어, 네덜란드어, 스웨덴어, 스위스 독일어, 히브리어, 튀르키예어 모델을 언급함 - 각 모델은 단일 언어용이라 여러 언어를 오가려면 폴더를 나눠 두고 `--model`이나 `KROKO_MODEL`로 바꿔야 함 - 표준 encoder, decoder, joiner, tokens.txt 구조를 가진 sherpa-onnx 스트리밍 트랜스듀서면 Kroko 말고도 쓸 수 있음 > [!TIP] > 사내 영상, 인터뷰, 강연 녹취처럼 외부 API에 올리기 애매한 오디오를 빠르게 훑고 싶을 때 잘 맞는 타입임. --- ## 기술 맥락 - 야프스냅의 선택이 흥미로운 건 거대한 음성 인식 서비스를 새로 만든 게 아니라, 이미 검증된 작은 도구들을 이어 붙였다는 점이에요. URL 처리는 yt-dlp, 디코딩은 ffmpeg, 추론은 sherpa-onnx가 맡기 때문에 각 레이어가 해야 할 일이 분명해요. - CPU 전용을 고집한 이유는 배포와 반복 사용성이 좋아지기 때문이에요. CUDA나 특정 칩 전용 최적화에 기대면 성능은 더 나올 수 있어도, 평범한 노트북이나 서버에서 바로 쓰기 어려워지거든요. - INT8 오닉스 모델을 쓰는 것도 같은 맥락이에요. 약 80MB 모델이면 첫 실행 부담이 작고, 캐시에 넣어둔 뒤 오프라인으로 계속 돌릴 수 있어요. 전사 API 비용이나 쿼터를 신경 쓰지 않아도 되는 게 장점이에요. - `--speed`로 오디오를 먼저 빠르게 만드는 방식은 꽤 현실적인 타협이에요. 완벽한 정확도가 필요한 녹취록이 아니라 내용을 훑기 위한 텍스트라면, 약간의 정확도 손실보다 처리 시간이 더 중요할 때가 많거든요. ## 핵심 포인트 - CPU만으로 실시간보다 빠른 전사를 목표로 한다 - 유튜브, 틱톡, 엑스, 인스타그램 릴스, 직접 미디어 링크, 로컬 파일을 처리한다 - yt-dlp, ffmpeg, sherpa-onnx 조합으로 다운로드·디코딩·인식을 처리한다 - 기본은 영어 모델이고, 프랑스어·독일어·스페인어 등은 모델 교체로 지원한다 ## 인사이트 회의 녹취나 영상 리서치를 자주 하는 개발자라면 ‘클라우드 전사 API 없이 로컬에서 대충 빠르게 텍스트를 얻는’ 선택지가 꽤 실용적임. 정확도보다 프라이버시, 비용, 반복 사용성이 중요한 워크플로에 잘 맞는다.