video-use는 Claude Code에 4,500만 프레임 토큰 대신 전사본을 넣는다

원본 영상 폴더를 디렉터리에 넣고, 문장 하나만 입력하면 완성된 final.mp4가 돌아옵니다. 타임라인도, 프리셋도, 메뉴도 없습니다. video-use의 반전은 모델이 실제로는 영상을 전혀 보지 않는다는 점입니다.

트랜스크립트를 DOM처럼 다루는 발상: 12KB와 노이즈 섞인 샘플 4,500만 개의 차이

video-use가 작동하는 이유는 픽셀을 모델에 먹이지 않기 때문입니다. browser-use 조직이 만든 오픈소스 에이전트 기반 편집 도구로, 편집을 새로운 비디오 모델 문제가 아니라 에이전트 제어 문제로 봅니다. 핵심 주장은 이렇습니다. 프레임별로 단순 처리하면 약 30,000프레임 × 1,500토큰 ≈ 4,500만 토큰에 달하는, 대부분 중복되고 모델이 편집 판단에 제대로 활용할 수 없는 시각 데이터가 소모됩니다. 반면 약 12KB짜리 Markdown 트랜스크립트와 필요할 때만 불러오는 타임라인 PNG만으로도 같은 편집 신호를 담을 수 있습니다 .

Quick Answer: video-use는 Claude Code 같은 코딩 에이전트가 약 30,000프레임, 즉 약 4,500만 토큰어치의 픽셀 데이터를 입력받는 대신 약 12KB짜리 Markdown 트랜스크립트를 읽고 영상을 편집하게 합니다. 컷, 군더더기 제거, 재촬영본 선택 같은 편집 판단은 텍스트 위에서 이루어지고, 픽셀 판단이 꼭 필요할 때만 에이전트가 PNG 프레임을 렌더링합니다 .

이 아이디어는 browser-use의 DOM 논지를 그대로 옮겨온 것입니다. 에이전트가 스크린샷에서 의미를 추론하게 하는 대신, browser-use는 구조화된 DOM과 접근성 트리를 제어 표면으로 건넵니다. video-use는 같은 방식을 영상에 적용합니다. 트랜스크립트가 DOM이고, timeline_view PNG는 필요할 때만 호출되는 스크린샷이며, ffmpeg는 실제 물리적 편집을 수행하는 구동 장치입니다 . 에이전트는 사람이 자막을 훑으며 편집점을 찾듯 텍스트를 훑고, 애매한 무음 구간이나 재촬영본 비교가 필요할 때만 렌더링된 프레임을 봅니다.

"LLM은 비디오를 보지 않습니다. 읽습니다."라고 제작자는 video-use 출시 워크스루에서 설명합니다 (source: YouTube).

프로젝트는 아직 어리지만 눈에 띕니다. 2026년 7월 9일 확인 기준, 저장소는 GitHub 스타 약 16.1k개, 포크 약 1.9k개, 커밋 18개, 공개 릴리스 없음, MIT 라이선스를 보였습니다 . 처음 확인 가능한 커밋은 2026년 4월 12일에 들어갔습니다 . 규모를 보자면, 모체인 browser-use 저장소는 약 104k개의 스타를 갖고 있습니다 . 따라서 video-use는 작고 빠르게 움직이는 파생 프로젝트이며, 성숙도는 스타 수보다 작동 방식으로 판단하는 편이 맞습니다.

이 작동 방식을 자세히 볼 만한 이유는 각 단계가 모두 구체적이고 파일 기반이기 때문입니다. 전사하고, 묶고, 추론하고, 편집 결정 목록을 내보내고, 렌더링하고, 스스로 평가합니다. 이 글의 나머지에서는 그 파이프라인을 따라갑니다. 먼저 영상이 애초에 어떻게 텍스트가 되는지부터 보겠습니다.

영상을 텍스트로 바꾸기: ElevenLabs STT, 화자 분리, 타임스탬프 정밀도

영상은 하나의 결정론적 단계를 거쳐 텍스트가 됩니다. helpers/transcribe.py가 ffmpeg로 모노 16kHz WAV 트랙을 추출한 뒤, ElevenLabs의 speech-to-text 엔드포인트로 POST 요청을 보내고 구조화된 결과를 JSON으로 캐시합니다 . 모든 이후 단계가 추론하는 대상은 픽셀이 아니라 이 JSON이므로, 이 호출의 정확도가 전체 편집 품질의 상한을 정합니다.

요청에는 뚜렷한 선택이 들어 있습니다. https://api.elevenlabs.io/v1/speech-to-text에 diarize=true, tag_audio_events=true, timestamps_granularity=word를 붙여 호출합니다 . 그 결과 ElevenLabs의 Scribe 모델은 video-use가 실제로 필요로 하는 세 가지를 돌려줍니다 :

• 단어 단위 타임스탬프 — 모든 단어의 시작과 끝 시간으로, 에이전트가 나중에 컷을 맞추는 좌표가 됩니다.
• 화자 분리 — S0, S1 같은 라벨로, 수동 태깅 없이 인터뷰어와 게스트를 구분합니다.
• 태그가 붙은 오디오 이벤트 — (laughter)나 (applause) 같은 비음성 표시가 인라인으로 적혀, 에이전트가 반응의 박자를 살리거나 들을 수 없는 빈 공기를 잘라낼 수 있게 합니다.

결과는 edit/transcripts/<source>.json 아래에 JSON으로 캐시되므로, 같은 영상으로 편집을 다시 실행해도 전사 비용을 두 번 내지 않습니다 . 이 캐시는 중요합니다. Scribe는 유료 종량제 서비스이기 때문입니다. video-use는 .env에 ELEVENLABS_API_KEY가 필요하며, STT가 분당 비용이 붙는 강한 외부 의존성이 됩니다 . 개발자 입장에서는 이 의존성을 두고 세 가지 현실적 제약을 미리 따져봐야 합니다. 예산, 즉 긴 영상은 전사 요금이 커진다는 점, 프라이버시, 즉 오디오가 로컬을 떠나 서드파티 API로 간다는 점, 그리고 언어 지원, 즉 화자 분리와 단어 타이밍 품질이 언어마다 달라진다는 점입니다.

로컬 준비물은 더 가볍습니다. 오디오 추출을 위한 ffmpeg, uv 또는 pip로 구성한 Python 환경, 그리고 선택 사항으로 전사 전에 온라인 소스에서 영상을 가져오기 위한 yt-dlp가 있으면 됩니다 . 이 지점 이후의 모든 것은 캐시된 텍스트 위에서 이루어지는 추론입니다.

takes_packed.md: 에이전트가 읽는 압축 표현

트랜스크립트가 캐시되면 pack_transcripts.py는 원시 단어 단위 JSON을 takes_packed.md라는 작고 사람이 읽기 쉬운 스크립트로 접습니다. 이 파일이 편집 서브 에이전트가 실제로 읽는 핵심 산출물입니다. 패커는 개별 단어 항목을 구문 단위 줄로 묶고, 최소 0.5초의 침묵 구간을 만나거나 화자가 바뀔 때마다 새 줄을 시작합니다 . 결과물은 데이터 덤프라기보다 편집용 단서가 이미 박혀 있는 자막 파일처럼 읽힙니다.

각 줄은 고정된 형태를 따릅니다. 대괄호 안의 타임스탬프 범위, 화자 라벨, 그리고 구문 텍스트가 이어집니다. 예시는 다음과 같습니다.

[002.52-005.36] S0 Ninety percent of what a web agent does is completely wasted.

여기서 002.52-005.36은 초 단위 시작 및 종료 시간이고, S0는 화자 분리로 식별된 화자이며, 나머지는 전사된 구문입니다 . 이 한 줄만으로도 에이전트는 원본 영상을 열지 않고 클립의 위치를 찾는 데 필요한 정보를 모두 얻습니다.

이 방식이 전체 타임라인 UI를 대체합니다. 파형을 훑거나 클립을 드래그하는 대신, LLM은 편집상 중요한 표시가 이미 명시된 텍스트를 두고 추론합니다. 군더더기 말은 짧은 구문으로 인라인에 남고, 무음 구간은 줄 사이의 끊김으로 드러나며, 같은 문장이 반복되는 지점에는 재촬영 경계가 드러납니다. 여기서는 두 가지 줄바꿈 조건이 핵심 역할을 합니다. 0.5초 이상의 침묵 구간과 모든 화자 전환이 에이전트가 읽어서 찾아낼 수 있는 자연스러운 컷 지점 후보가 됩니다. 픽셀 하나를 들여다볼 필요가 없습니다 .

효과는 밀도입니다. 단순한 대안이라면 약 30,000프레임에 프레임당 약 1,500토큰, 거의 4,500만 토큰에 달하는 중복 노이즈를 처리해야 합니다. 이 표현은 그 부담을 피하고, 전체 토킹헤드 테이크를 에이전트가 컨텍스트에 담아 편집 기준으로 삼을 수 있는 몇 KB짜리 Markdown으로 압축합니다 . 컷 선택부터 오버레이 타이밍까지, 이후의 모든 작업은 이 압축 스크립트를 소스 오브 트루스로 삼아 진행됩니다.

에이전트가 클립을 지정하는 방식: grade, beat, overlays, subtitles

에이전트는 takes_packed.md를 읽고 그 판단을 Edit Decision List(EDL)로 바꿉니다. EDL은 렌더러가 이어 붙일 클립 하나하나를 항목으로 담은 JSON 배열입니다. 각 항목은 source, start, end, beat, quote, reason, grade, overlays, subtitles, total_duration_s라는 고정 필드 묶음을 가집니다 . 이것이 추론과 렌더링 사이의 실제 계약입니다. 에이전트는 픽셀을 직접 조작하지 않고, 의도를 데이터로 선언한 뒤 helpers/render.py가 실행하게 합니다.

grade 필드는 전역 LUT 하나가 아니라 세그먼트별 색을 인코딩하므로, 어두운 재촬영분과 조명이 좋은 펀치라인을 독립적으로 정규화할 수 있습니다. overlays 필드는 어떤 모션 엔진이 애니메이션을 합성할지 지정합니다. HyperFrames, Remotion, Manim, PIL 중 하나이며, 이들은 지연 설치되고 병렬 서브 에이전트에서 애니메이션 하나당 한 슬롯씩 생성되기 때문에 오버레이 작업이 메인 편집을 막지 않습니다 . 이는 browser-use가 동시 웹 작업에 사용하는 것과 같은 위임 패턴을 렌더 그래프로 옮긴 것입니다.

픽셀은 필요할 때만 루프에 들어옵니다. 트랜스크립트만으로 판단을 내릴 수 없을 때, 예를 들어 애매한 멈춤, 거의 같은 두 재촬영분, 의심스러운 컷 경계가 있을 때 에이전트는 timeline_view 도구를 실행합니다. 이 도구는 해당 구간의 필름스트립 프레임, 오디오 파형, 단어 라벨, 침묵 구간 후보를 하나의 PNG 합성 이미지로 렌더링합니다 . 프레임을 스트리밍하는 대신 판단 지점에서 이미지 한 장만 확인하므로, 실제로 시각적 확인이 필요한 순간으로 토큰 비용을 제한할 수 있습니다.

렌더링 후에는 셀프 평가 패스가 결과물을 EDL과 대조해 검증하고, 검사에서 스플라이스 경계의 들리는 컷 지점 클릭, 목표 대비 라우드니스 위반, 세그먼트에서 벗어난 오버레이 타이밍을 발견하면 최대 세 번의 수정 및 재렌더 사이클을 트리거할 수 있습니다 . −14 LUFS 라우드니스 정규화와 30ms 경계 페이드는 helpers/render.py가 적용하므로 , 셀프 평가 루프는 결정론적 렌더를 검사하는 셈입니다. 매번 다시 실행할 때 불투명한 타임라인을 조금씩 만지는 것이 아니라 수정된 EDL을 다시 내보내기 때문에, 전체 편집은 재현 가능하고 점검 가능한 상태로 유지됩니다.

필러 제거, 재촬영본 선택, 그리고 확인 후 렌더링

에이전트의 편집 판단은 SKILL.md에 있는 엄격한 규칙을 따르며, 그중 가장 강한 규칙은 컷 제약입니다. 말소리의 음절 안에서는 절대 자르지 않는다는 것입니다. 모든 컷 지점은 가장 가까운 단어 경계에 맞춘 뒤 바깥쪽으로 30–200 ms 여유를 둬야 합니다. ElevenLabs Scribe 타임스탬프가 50–100 ms 정도 밀릴 수 있기 때문입니다. 이 패딩은 의도적으로 둔 여유분입니다. STT의 흔들림을 흡수해, 트림이 다음 단어의 첫 음소를 잘라내는 대신 침묵 구간에 떨어지게 합니다.

제거 후보는 화면 픽셀이 아니라 압축된 transcript에서 드러납니다. 0.5초 이상의 무음 구간은 모두 컷 후보로 표시되고, "umm," "uh," 같은 필러 단어나 말실수로 시작했다가 멈춘 부분은 자동으로 표시됩니다. 같은 대목을 여러 번 촬영한 영상이라면 에이전트는 가장 좋은 테이크를 고르고 나머지를 버리도록 안내받습니다. 이는 사람 편집자가 자막 트랙을 다루는 방식과 같은 재촬영본 선택입니다. 프레임 렌더링에 시간을 쓰기 전에 텍스트에서 표현과 전달력을 먼저 비교하는 방식입니다.

긴 영상에서 이런 작업은 물리적이고 되돌리기 어렵기 때문에, SKILL.md는 질문 → 확인 → 실행 순서를 강제합니다. 에이전트가 편집 전략을 제안하고, 사용자의 승인을 기다린 뒤에야 ffmpeg를 실행합니다. 한 번 잘못 판단한 EDL이 몇 시간짜리 원본을 잘라낼 수 있다는 점에서 이 관문은 중요합니다. 싸게 되돌릴 수 없는 유일한 단계에서 사람이 판단 흐름 안에 남아 있게 해줍니다.

모션 작업은 순차 처리하지 않고 여러 갈래로 나뉩니다. 애니메이션 슬롯은 애니메이션 하나당 하나씩 병렬 서브 에이전트에 넘겨지며, HyperFrames, Remotion, Manim, PIL 같은 선택형 엔진을 필요할 때 설치해 동시에 생성합니다 (video: Nate Herk | AI Automation). 실행을 거듭해도 세션 상태는 footage 폴더의 edit/ 디렉터리 안 project.md에 유지됩니다. 그래서 나중에 다시 실행하면 처음부터 다시 추론하지 않고, 이전 계획과 캐시된 transcript, 결정 사항을 그대로 이어받습니다.

EDL에서 final.mp4까지: 세그먼트 이어붙이기, 색 보정, 라우드니스 정규화

렌더링 단계에서는 에이전트의 Edit Decision List가 재생 가능한 파일이 됩니다. helpers/render.py는 각 EDL 항목을 순서대로 따라가며, 원본 클립에서 해당 세그먼트를 추출하고, 지정된 색 보정을 적용한 뒤, 양쪽 경계에 짧은 오디오 페이드를 깔고 모두 이어 붙입니다. transcript 추론이 설명만 했던 물리적 편집이 여기서 실제로 일어납니다. 이 단계에서는 콘텐츠를 다시 판단하지 않습니다. render.py는 전달받은 JSON을 실행하는 결정론적 액추에이터이기 때문에, 창작 판단은 감사 가능하게 남고 출력은 재현 가능해집니다.

두 가지 세부 처리 덕분에 이음새가 드러나지 않습니다. 각 세그먼트의 양쪽 경계에는 30 ms 오디오 페이드가 들어가 단어 사이의 하드 컷에서 들리는 클릭음을 막고, 세그먼트는 전체 재인코딩이 아니라 ffmpeg의 -c copy concat으로 무손실 결합되어 원본 코덱과 품질을 보존합니다. concat 단계가 스트림을 트랜스코딩하지 않고 복사하므로, 렌더 시간은 전체 해상도나 비트레이트보다 컷 수에 비례합니다.

오버레이와 자막은 조립된 타임라인 위에 얹힙니다. 애니메이션은 setpts=PTS-STARTPTS+T/TB 표현식으로 합성됩니다. 이 표현식은 각 오버레이의 프레젠테이션 타임스탬프를 초기화하고 T만큼 오프셋을 주어, 모션 그래픽이 자체 소스 타이밍이 아니라 최종 컷의 정확한 순간에 고정되게 합니다. 자막은 마지막 패스로 실행되며, 기본값은 2단어 UPPERCASE 청크이고, 스타일은 프로젝트별로 설정할 수 있습니다 [1][13].

마지막 선택 패스는 -14 LUFS integrated, -1 dBTP true peak, and LRA 11을 목표로 하는 라우드니스 정규화입니다. 이 세 값은 YouTube와 대부분의 팟캐스트 플랫폼에 맞는 실무 전달 사양이므로, 출력물은 업로드 시 클리핑되거나 자동으로 낮춰지는 대신 배포자가 기대하는 라우드니스에 맞춰 도착합니다. 색 보정, 페이드, 무손실 concat, 타임스탬프에 고정된 오버레이, 캡션, 방송 표준 라우드니스까지 합쳐져 렌더 단계는 12 KB transcript에서 시작된 흐름을 마무리하고, 타임라인 UI가 footage를 직접 건드리지 않아도 edit/final.mp4를 만들어냅니다.

video-use, ELLMPEG, Remotion: 에이전트 기반 편집에서 각각 맡는 역할

video-use, ELLMPEG, Remotion은 에이전트 기반 편집 스택에서 서로 다른 세 계층을 차지하므로 경쟁하기보다 보완 관계에 가깝다. video-use는 트랜스크립트에서 파생한 Edit Decision List를 바탕으로 어떤 테이크를 살릴지, 어디서 군더더기를 잘라낼지, 오버레이 타이밍을 어떻게 맞출지 판단하는 편집적 종합을 맡는다 . ELLMPEG는 명령 합성을 맡는다. Remotion은 프로그래매틱 컴포지션을 맡는다. 각 도구가 실제로 해결하는 문제가 무엇인지 이해해야 알맞은 도구를 고를 수 있고, 한 도구에 다른 도구의 일을 기대하는 실수를 피할 수 있다.

2026년 1월 17일 arXiv에 제출된 대표적 ffmpeg-agent인 ELLMPEG는 도구 인식 검색 증강 생성과 자기 성찰을 사용해 실행 가능한 FFmpeg 및 VVenC 명령을 자동 생성하고 로컬에서 검증하며, Qwen2.5 기반 480개 프롬프트에서 평균 78%의 명령 생성 정확도를 보고했다 . 이는 video-use가 하는 일과 다른 과제다. ELLMPEG는 "이 영상을 크롭하고 트랜스코딩해줘"를 올바른 ffmpeg 호출로 바꾸는 반면, FFmpeg 자체는 여전히 녹화, 변환, 스트리밍을 위한 성숙한 기반이다 . video-use는 명령 합성보다 한 계층 위에 있으며, ffmpeg를 지능이 아니라 실행 장치로 다룬다.

Remotion은 React 코드가 소스 오브 트루스가 되는 컴포지션 프레임워크이며, npx create-video@latest로 스캐폴딩한다. 2026년 7월 8일 업데이트된 문서에는 이제 코딩 에이전트용 저작 지침도 포함되어 있다 . 설계된 설명 영상, 데이터 영상, 확장 가능한 개인화 템플릿에서는 Remotion이 video-use보다 더 깊이 들어간다. 하지만 video-use도 Manim 또는 PIL과 함께 Remotion을 선택적 애니메이션 엔진으로 호출할 수 있다. 그래서 둘은 보완적이다. 그래픽이 핵심이면 Remotion을 쓰고, 기존 촬영본을 선별하고 다듬어야 한다면 video-use를 쓰면 된다.

"When browser users automated the web, they passed screen layout diagrams instead of screenshots. I translated that exact idea into a video," — 브라우저-use의 제어 표면 논리를 영상으로 옮겼다고 설명한 video-use 제작자 (source: primary demo video).

이 영역 전반에는 한 가지 주의점이 있다. 정량 근거 상당수가 퍼스트파티 자료라는 점이다. 2026년 7월 3일 개정된 VideoAgent v2는 87~95%의 오케스트레이션 성공률, 60%의 API 비용 절감, 사람이 만든 영상보다 4% 낮은 품질을 주장하지만, 모두 자체 평가 결과다 . video-use의 12KB 대 4,500만 토큰 수치도 독립 벤치마크가 아니라 README의 예시성 주장이다 . 서드파티 수치가 나오기 전까지 도구 간 비교는 방향성 정도로 보는 편이 낫다.

ElevenLabs 연동, 트랜스크립트 지터, 도입 전에 확인할 점

실제 촬영본을 video-use에 맡기기 전에는 기대감보다 성숙도를 먼저 따져봐야 한다. 2026년 7월 9일 기준 이 저장소에는 공개 릴리스가 없고 커밋도 18개뿐이며, 빠르게 늘어난 스타 수는 약 16,100개 수준이다 . 스타는 관심을 보여줄 뿐 프로덕션 안정성을 증명하지 않는다. 이렇게 젊은 MIT 라이선스 프로젝트에는 변경 로그 규율도, 버전 핀도, 클라이언트 편집을 맡길 만한 파이프라인 이력도 없다. 여기서 인기는 신뢰성의 대체 지표가 아니다.

대표 효율성 수치에도 같은 주의가 필요하다. 12KB 대 4,500만 토큰이라는 표현은 독립적으로 재현된 벤치마크가 아니라 README의 예시성 주장이고, 이 도구의 품질 및 재렌더 성공률 역시 퍼스트파티 자료에서만 인용된다 . 트랜스크립트 기반 편집이 다양한 촬영본에서 사람의 컷 편집과 맞먹는다는 점을 확인한 서드파티 평가는 아직 없다.

운영 제약은 구체적이다. ElevenLabs Scribe는 유료이고 클라우드 전용이며 레이트 리밋이 있으므로, 영상 분당 비용, 데이터 프라이버시 노출, 언어 정확도, 화자 분리 품질이 모두 그대로 의존성이 된다. 또한 단어 단위 타임스탬프가 50~100ms 정도 밀릴 수 있는데, 이 때문에 해당 스킬은 경계를 그대로 믿지 않고 컷 가장자리에 패딩을 둔다 . 완전 자율 에이전트 후반 작업도 대규모 외부 검증은 부족하다. 이전 LAVE 연구에서도 LLM 보조 편집은 수동 UI 보정의 도움을 받았고, 그 이후로도 사람 검토자를 없앨 만한 근거는 나오지 않았다.

현실적인 결론은 이렇다. video-use는 토킹헤드, 튜토리얼, 론칭 영상에 대해 재현 가능하고 점검 가능한 1차 편집본을 만드는 도구로 보되, 사람이 손대지 않는 렌더 팜으로 보면 안 된다. STT 비용을 예산에 넣고, 최종 검토에는 사람을 남겨두며, 프로젝트가 버전이 붙은 릴리스를 내놓기 전까지는 자체 포크를 고정해 쓰는 편이 낫다.

자주 묻는 질문

video-use를 쓰려면 GPU나 전용 비디오 모델이 필요한가요?

아니요. video-use에는 GPU도, 비디오 생성 모델도 필요하지 않습니다. 전사는 ElevenLabs의 클라우드 음성-텍스트 API에서 실행되고 , 편집 판단은 셸을 다룰 수 있는 어떤 코딩 에이전트든 맡을 수 있습니다. Claude Code, Codex, Hermes, Openclaw 모두 가능합니다. 실제 물리적 편집은 로컬 ffmpeg가 렌더러로 수행합니다 . 이 저장소는 대략 76%가 Python이며, 인코딩 작업은 ffmpeg가 처리합니다 . 여기서의 지능은 생성이 아니라 편집 판단입니다. 에이전트는 새 픽셀을 상상해 만들어내는 것이 아니라, 무엇을 남길지 결정합니다.

takes_packed.md의 한 줄은 실제로 어떻게 생겼나요?

각 줄은 타임스탬프 범위, 화자 ID, 발화 문구를 한 쌍으로 묶습니다. 예를 들면 다음과 같습니다. [002.52-005.36] S0 Ninety percent of what a web agent does is completely wasted. . 대괄호 안 숫자는 초 단위의 시작 및 종료 시각이고, S0는 화자 분리로 식별된 화자이며, 나머지는 발화 텍스트입니다. pack_transcripts.py는 단어 단위 항목을 묶고, 0.5초 이상의 침묵이 있거나 화자가 바뀌는 지점에서 끊어 이런 줄을 만듭니다 . 그래서 각 공백이 에이전트가 자연스럽게 참조할 수 있는 컷 지점 마커로 바뀝니다.

video-use가 여러 명이 말하는 인터뷰나 팟캐스트도 처리할 수 있나요?

네. 전사 단계에서 ElevenLabs를 diarize=true 및 tag_audio_events=true로 호출하므로, API는 (laughter)나 (applause) 같은 이벤트와 함께 화자별 레이블(S0, S1, …)을 반환합니다 . 이후 pack_transcripts.py는 화자가 바뀔 때마다 문구 줄을 끊습니다 . 덕분에 압축된 transcript 안에서도 각 참가자의 발언이 명확히 귀속되고 개별적으로 선택할 수 있습니다. 인터뷰, 패널, 팟캐스트 영상은 모두 이 모델에 잘 맞습니다. 다만 화자 분리 품질과 타임스탬프 밀림은 기반 STT에 좌우되므로, 샘플 확인은 해보는 편이 좋습니다.

AI 어시스턴트에게 ffmpeg 명령을 써 달라고 하는 것과 무엇이 다른가요?

ffmpeg-agent 시스템은 설명을 바탕으로 올바른 명령을 합성합니다. video-use는 그보다 한 층 위에 있습니다. 대표적인 2026년 학술 ffmpeg-agent인 ELLMPEG는 실행 가능한 FFmpeg 명령을 자동 생성하고 로컬에서 검증하며, 480개 프롬프트에서 평균 78%의 명령 생성 정확도를 보고했습니다 . 이는 명령 합성입니다. 즉 자르기, 트랜스코딩, 압축 같은 작업입니다. video-use는 편집 합성을 합니다. transcript를 읽고 어느 테이크가 더 강한지, 군더더기가 어디서 끝나는지, 어떤 침묵이 의도된 것인지를 판단한 뒤, ffmpeg가 실행할 Edit Decision List를 도출합니다 . 하나는 명령을 쓰고, 다른 하나는 컷을 결정합니다.

자체 평가 루프는 렌더링 후 실제로 무엇을 확인하나요?

render.py가 출력물을 만들면, 에이전트는 컷 지점의 클릭 아티팩트, -14 LUFS / -1 dBTP 목표 대비 라우드니스 위반, 오버레이 타이밍 밀림을 검사합니다 . 문제가 발견되면 수정된 EDL 항목을 발행하고 다시 렌더링합니다. 이 수정 및 재렌더링은 최대 세 번까지 수행한 뒤 edit/final.mp4를 반환합니다 . 세그먼트 경계에 30ms 오디오 페이드를 넣는 이유는 바로 이 루프가 방지하려는 클릭 아티팩트를 막기 위해서입니다 . 이는 범위가 정해진 검사이지, 무제한 품질 보증은 아닙니다. 최종 인간 리뷰는 여전히 필요합니다.

이 글이 도움이 되셨다면, 새 글이 올라올 때마다 이메일로 받아보세요.

구독하기