Claude Code에 mp3나 영상 파일을 직접 넣으면 내용을 들을 수 있나?
아니다. Claude Code의 Read 도구는 이미지·PDF는 읽지만 오디오는 읽지 못하며, 오류가 나도 모델이 분석을 지어낼 수 있다는 버그 리포트가 있다. ffmpeg로 오디오를 뽑고 whisper.cpp로 전사한 텍스트를 읽히는 방식이 표준이다.
AI 코딩 도구는 오디오를 직접 읽지 못한다. ffmpeg·whisper.cpp로 전사해 넘기는 순서와 환각·화자 분리·발음 판정의 한계를 짚는다
영상 하나를 던져 놓고 "이 강의 내용 정리해 줘"라고 하면 AI 코딩 도구가 소리까지 알아서 들어줄 것 같지만, 실제로는 그렇지 않다. 클코단에서는 Claude Code 같은 도구에 영상 소리를 듣게 하는 방법이 화제였고, 이야기는 곧 Whisper 전사 품질을 어떻게 믿을 수 있느냐는 질문으로 옮겨갔다. 이 기사는 그 두 질문에 답한다. 소리를 도구에 넣는 실제 순서는 무엇이고, 전사 결과의 품질은 어디까지 검증할 수 있는가.
Claude Code의 Read 도구는 이미지와 PDF는 읽지만 mp3·wav·m4a 같은 오디오 파일은 읽지 못한다. Claude Code 공식 저장소에 올라온 버그 리포트에 따르면, 오디오 파일을 읽으라고 하면 오류나 깨진 텍스트가 돌아오는데도 모델이 "어조가 차분하다" 같은 분석을 지어내는 문제가 보고됐다. 오디오를 정식 입력 형식으로 추가해 달라는 기능 요청도 별도 이슈로 열려 있다.
그래서 지금 통용되는 방식은 한 가지다. 먼저 소리를 글자로 바꾼 뒤, 그 텍스트 파일을 Claude Code에 읽힌다.
순서는 이렇다. ffmpeg로 영상에서 오디오 트랙만 뽑아 16kHz 모노 WAV로 만든다. whisper.cpp의 whisper-cli에 그 WAV를 넣어 txt·srt·vtt 전사본을 받는다. Claude Code에는 전사본을 읽히고 요약·정리·자막 교정을 맡긴다. 800MB짜리 영상 전체를 넘길 필요가 없고, Whisper가 필요한 것은 오디오 트랙뿐이다.
이 순서를 자동화한 Claude Code 스킬과 플러그인이 여럿 공개돼 있다. Binjee의 저장소는 Video Input 스킬과 whisper.cpp를 묶어 프레임 추출·전사·요약을 한 번에 돌리는 설치 가이드를 제공한다. jftuga의 transcript-critic은 로컬 파일이나 유튜브 주소를 받아 yt-dlp와 whisper-cli로 전사한 뒤 타임스탬프 요약과 논리 오류 분석까지 뽑는다. alicicek의 claude-transcribe는 플러그인 마켓플레이스로 설치하면 첫 세션에서 yt-dlp·ffmpeg·openai-whisper를 알아서 깔아 준다. danielrosehill의 Claude-Transcription-Plugin은 무음 제거·포맷 정규화·전사·필러 제거·구조화 단계를 명령어로 나눠 두었고, 전사 엔진으로 Whisper 로컬 외에 Gemini와 AssemblyAI도 고를 수 있다.
방에서 공유된 whisper.cpp는 OpenAI Whisper를 C/C++로 옮긴 프로젝트다. 파이썬 없이 돌아가고 Apple Metal·CUDA·Vulkan·CPU를 지원해서 맥북에서 쓰기 편하다. 모델 파일은 저장소의 download-ggml-model.sh 스크립트로 받는다.
선택지는 크게 둘이다. large-v3는 가장 정확하지만 느리다. large-v3-turbo는 인코더는 그대로 두고 디코더를 32층에서 4층으로 줄인 뒤 미세조정한 모델로, 파일 크기는 약 1.5GiB이며 전사 속도가 더 빠르다. 억양이 세거나 겹쳐 말하거나 녹음이 나쁜 경우엔 full large-v3가 조금 더 낫다는 것이 배포 문서와 사용자 가이드의 공통된 설명이다.
한국어는 어떤가. OpenAI의 large-v3 릴리스 노트는 한국어에 대해 단어 오류율 대신 문자 오류율을 썼는데, 한국어 띄어쓰기가 데이터셋마다 일관되지 않기 때문이라고 밝혔다. 한국어 회의록 파이프라인을 공개한 TreeSoop 블로그는 전문 용어 인식에서 Whisper 로컬 파이프라인이 비교 대상 유료 서비스보다 나았다고 적었다. 반면 ENERZAi는 자체 테스트에서 한국어 정확도가 영어보다 눈에 띄게 떨어졌다고 썼다. 두 관찰은 충돌하지 않는다. 두 관찰은 large-v3의 한국어 전사 성능에 장점과 한계가 함께 있다는 뜻이다.
써본 사람들 사이에서 반복해서 나오는 팁이 하나 있다. 언어 자동 감지에 맡기면 한국어 음성이 영어로 나오는 경우가 있으니 언어를 명시하라는 것이다. 또 ffmpeg로 16kHz 리샘플링과 간단한 노이즈 필터를 먼저 거치면 인식률이 눈에 띄게 오른다는 경험담이 여럿이다.

방에서 나온 문제의식은 정확했다. Whisper는 세그먼트마다 몇 가지 숫자를 함께 돌려주는데, 그 숫자는 전사 실패를 잡는 데는 쓸모 있어도 발음 품질을 판정하지는 못한다.
openai/whisper 소스 코드 기준으로 지표는 셋이다. avg_logprob는 평균 로그 확률로, 기본 임계값 -1.0보다 낮으면 디코딩 실패로 본다. compression_ratio는 zlib 압축비로, 2.4를 넘으면 반복적인 출력으로 보고 디코딩 실패로 처리한다. no_speech_prob는 무음 확률로, 0.6을 넘고 avg_logprob도 낮으면 그 구간을 무음으로 처리한다. Whisper 저자는 이 기본값이 몇 개 데이터셋에서 그럭저럭 맞았을 뿐이며, 특히 no_speech_prob는 음성 활동 예측치로 믿을 만하지 않다고 GitHub 토론에서 인정했다.
이 지표가 잡아내는 것은 Whisper의 악명 높은 환각이다. 무음이나 음악 구간에서 "시청해 주셔서 감사합니다" 같은 학습 데이터 문구를 지어내거나 직전 문장을 수십 번 반복하는 현상이다. 2026년 arXiv에 올라온 벤치마크 논문은 Fair-Speech 오디오의 30%를 마스킹한 실험에서 Whisper-small의 삽입 오류 중 86%가 반복 루프였다고 보고했다. 써본 사람들 사이에서도 4시간 녹음에서 소음 구간을 지나면 "네." "죄송합니다." 같은 짧은 말이 무한 반복됐다는 이야기, 걸린 지점에서 시작 오프셋을 옮겨 다시 돌린다는 임시방편이 흔하다.
효과가 확인된 대책은 외부 VAD(음성 활동 감지)다. WhisperX 논문은 Whisper 자체 타임스탬프 대신 외부 VAD 경계로 오디오를 잘라 넣으면 반복 루프와 무음 환각이 줄어든다고 보였다. 실무에서는 Silero VAD로 무음을 찾아 긴 공백을 줄이는 방식이 쓰인다. 무음을 통째로 없애면 Whisper가 문장 경계와 구두점을 잡는 단서까지 사라지기 때문이다. condition_on_previous_text를 끄는 것도 반복 강화를 막는 데 도움이 된다.
그런데 이 모든 것은 "전사 과정에서 누락이나 삽입·반복이 생겼는가"의 문제다. 발음이 또렷했는지, 청취자가 알아듣기 좋았는지는 다른 층의 질문이다. 그 질문에 답하는 도구는 Microsoft Azure AI Speech의 발음 평가 API다. 참조 텍스트를 주면 음소·단어 단위 정확도와 영어(en-US)의 음절 단위 정확도, 쉼 간격의 자연스러움을 재는 유창성, 강세·억양·속도를 재는 운율 점수를 돌려준다. 다만 Microsoft 문서에 따르면 운율 점수는 en-US 로케일에서만 제공되고, 대본 없는 모드는 Azure STT와 다른 인식 모델을 쓰므로 정확한 판정이 필요하면 STT로 참조 텍스트를 먼저 뽑으라고 안내한다. Microsoft Azure AI Speech의 발음 평가는 한국어(ko-KR)도 지원한다.
방에서는 Whisper Large v3·Deepgram Nova-2·AssemblyAI Universal-2 비교가 요청됐다. 비교 논문 하나가 세 모델을 나란히 다뤘다. 비원어민 영어 전사를 다룬 arXiv 논문(2503.06924)은 Universal-2·Nova-2·Whisper large-v3 등 다섯 시스템을 비교하면서, Whisper만 오픈소스라 로컬 설치가 가능하고 나머지는 구조가 비공개이며 성능 자료도 동료 심사가 아닌 마케팅 자료라고 지적했다.
숫자는 테스트셋마다 크게 흔들린다. AssemblyAI는 자사 블로그에서 Universal-3.5 Pro가 Whisper보다 환각을 약 30% 줄였다고 주장한다. 벤더 수치는 참고만 하고 자기 오디오로 직접 재라는 것이 비교 글마다 붙는 조언이다.
한국어 지원은 셋 다 확인된다. Deepgram은 Nova-3에 한국어를 추가하면서 음절 블록과 빠른 활용, 띄어쓰기 모호성을 핵심 난제로 꼽았고, Nova-2는 여전히 서비스 중이다. AssemblyAI는 한국어 화자 분리도 지원한다. 다만 AssemblyAI 문서에 따르면 언어 자동 감지를 켠 채 지원되지 않는 기능을 요청하면 오류 없이 그 기능만 조용히 빠지므로, 응답에 화자 라벨이 실제로 있는지 확인해야 한다.
가격은 분당 0.5센트 안팎에서 모인다. 2026년 8월 말 나온 Google의 Gemini 3.5 Transcribe는 파일 전사 기준 분당 약 0.005달러로 추산되고, OpenAI의 gpt-4o-transcribe와 whisper-1은 분당 0.006달러, AssemblyAI Universal-2는 시간당 0.15달러다. Gemini 쪽은 토큰 과금이라 오디오 길이와 출력 텍스트 토큰 수에 따라 실제 청구가 달라진다.
방에서 나온 "화자 분리는 다른 모델을 조합한다"는 언급은 현재 관행과 일치한다. whisper.cpp에도 tinydiarize라는 실험 기능이 있어 -tdrz 옵션으로 화자 교체 지점 토큰을 찍어 주지만, 제약이 크다. small.en 모델 하나뿐이라 영어 전용이고, 누가 말했는지 식별하지 않고 "바뀌었다"만 표시하며, 프로젝트가 공개한 수치로 교체 지점 정밀도는 97.7%인데 재현율은 70.8%다. 열 번 중 세 번은 교체를 놓친다.
자체 호스팅에서 사실상 표준은 Whisper와 pyannote.audio의 조합이다. WhisperX가 이를 네 단계로 묶는다. faster-whisper로 배치 전사, wav2vec2 강제 정렬로 단어 단위 타임스탬프 복원, pyannote로 화자 구간 추출, 타임스탬프로 단어와 화자 매칭. Whisper 자체 타임스탬프는 발화 단위라 몇 초씩 어긋날 수 있어 정렬 단계가 필요하다. 약점도 문서화돼 있다. pyannote 모델 가중치는 무료지만 약관 동의가 필요한 게이트 모델이다.
2026년 3월 arXiv 논문(WhisperAlign)은 한 가지 실전 함정을 짚었다. ASR 파이프라인과 pyannote가 서로 다른 VAD를 쓰기 때문에 경계 타임스탬프가 본질적으로 어긋나며, pyannote 출력을 Silero VAD의 음성 구간 안으로 잘라 넣으면 경계 환각이 사라졌다고 보고했다.
마지막 질문은 Gemini의 음성 기능이었다. 답은 두 층으로 나뉜다. 소비자용 Gemini 앱의 Gemini Live는 음성 대화 기능으로, 텍스트를 거치지 않고 음성을 직접 생성한다. 개발자가 파일 전사에 쓰는 것은 Gemini API 쪽이다.
Gemini API는 Claude와 달리 오디오를 입력으로 받는다. 일반 Gemini 모델에 오디오 파일을 올리고 "화자를 구분하고 MM:SS 타임스탬프를 붙여 전사하라"고 프롬프트하면 구조화된 출력으로 받을 수 있다. 여기에 더해 전용 모델 Gemini 3.5 Transcribe가 나왔다. Google 문서에 따르면 85개 이상 언어 자동 감지, 화자 분리, 단어 단위 타임스탬프, 사용자 어휘 바이어싱을 지원하고 단일 요청으로 1시간까지 처리하되, 화자 분리나 단어 단위 타임스탬프를 켜면 30분까지 처리한다. 제약도 명시돼 있다. 사용자 어휘는 화자 분리·단어 타임스탬프와 함께 쓸 수 없고, 실시간 스트리밍 모델은 화자 분리를 지원하지 않는다.
일반 모델로 긴 오디오를 전사할 때는 알려진 문제가 있다. Google AI 개발자 포럼에 2026년 3월 올라온 버그 리포트는 12분짜리 아랍어 강의에서 Gemini 3 Flash와 3.1 Pro 모두 타임스탬프가 점진적으로 앞서 나갔다고 보고했다. 써본 사람들 사이에서 1~3시간짜리 화자 분리 전사를 Gemini로 한 번에 처리해 본 사람이 있느냐는 질문이 반복되는 것도 같은 맥락이다.
그래서 개인 개발자가 지금 고를 수 있는 길은 세 갈래다. 비용 없이 로컬에서 끝내려면 ffmpeg·whisper.cpp large-v3-turbo에 Silero VAD를 앞에 붙이고 전사본을 Claude Code에 읽힌다. 화자 라벨이 필요하면 WhisperX나 AssemblyAI·Deepgram의 화자 분리 옵션을 켠다. 소리를 직접 듣는 모델이 필요하면 Gemini API로 넘어가되 짧게 잘라 넣는다. 어느 길이든 전사 실패의 징후는 지표로 잡을 수 있어도, 그 목소리가 듣기 좋았는지는 아직 사람이 들어야 안다.
아니다. Claude Code의 Read 도구는 이미지·PDF는 읽지만 오디오는 읽지 못하며, 오류가 나도 모델이 분석을 지어낼 수 있다는 버그 리포트가 있다. ffmpeg로 오디오를 뽑고 whisper.cpp로 전사한 텍스트를 읽히는 방식이 표준이다.
Silero VAD 같은 외부 음성 활동 감지로 긴 무음을 0.3~0.5초로 줄여 넣고, condition_on_previous_text를 끈다. 출력에서 compression_ratio가 2.4를 넘거나 avg_logprob가 -1.0 아래인 세그먼트를 걸러내면 대부분 잡힌다.
일반적인 강의·회의 녹음은 여섯 배 빠른 large-v3-turbo로 충분하다. 억양이 강하거나 여러 사람이 겹쳐 말하거나 녹음 상태가 나쁘면 디코더가 32층인 full large-v3가 조금 더 정확하다.
whisper.cpp의 tinydiarize는 영어 전용에 화자 교체 지점만 찍어 주고 재현율이 70% 수준이다. 실무에서는 WhisperX처럼 pyannote.audio를 붙이거나 AssemblyAI·Deepgram·Gemini 3.5 Transcribe의 화자 분리 옵션을 쓴다.
된다. Gemini API는 오디오 입력을 받으며, 전용 모델 Gemini 3.5 Transcribe는 화자 분리와 단어 타임스탬프를 지원한다. 다만 일반 모델로 긴 파일을 넣으면 12~18분 부근부터 타임스탬프가 앞서 나가는 문제가 보고돼 10~15분 단위로 자르는 것이 권장된다.