16분 강의에서 쇼츠 한 편까지 15분: TwelveLabs Jockey MCP 실측기

YouTube URL 하나를 넣고 “쇼츠 후보를 발굴해서 하나 만들어보자”라고 말했다. 16분 4초짜리 Git·GitHub 입문 강의가 세로형 MP4가 되기까지 약 15분이 걸렸다. 인덱싱은 약 4분, 사람이 실제로 개입한 시간은 후보 선택과 마지막 프레임 검증을 합쳐 약 2분이었다.

비용은 TwelveLabs 공개 API 단가로 환산하면 약 1.64달러였다. 이 숫자는 Jockey 청구서가 아니다. Jockey에는 별도 상품 요금제가 있고 에이전트 내부 호출 횟수도 달라질 수 있으므로 실제 차감량은 계정 대시보드가 기준이다.

이번 실험의 질문은 단순했다.

영상을 처음부터 끝까지 보지 않고도 쇼츠 한 편을 완성할 수 있을까?

결론부터 말하면 가능했다. 다만 좋은 구간을 찾는 일과 자막 시각을 맞추는 일은 서로 다른 정확도를 요구했다.

검수에서 발굴로 방향을 돌리다

이전에는 Jockey를 강의 검수에 사용했다. 이번에는 방향을 뒤집었다. 검수가 “만든 것을 다시 보는 일”이라면 쇼츠 제작은 “만든 것에서 다시 꺼내는 일”이다.

두 작업의 병목은 같다. 영상을 정주행해야 한다는 점이다. 16분 강의에서 쇼츠 한 편을 뽑으려면 구간을 찾고, 다시 들으며 자막을 맞추고, 마지막으로 결과를 확인해야 한다. Jockey가 검수에서 “어디가 이상한지”를 찾았다면 발굴에서는 “어디가 좋은지”를 찾을 수 있어야 했다.

전체 파이프라인

이번 구성은 Claude Cowork 세션에 Jockey MCP를 연결하고 같은 환경에서 ffmpeg로 편집하는 방식이다.

flowchart LR
    A[YouTube URL] --> B[Jockey 인덱싱]
    B --> C[JSON 스키마 질의]
    C --> D[쇼츠 후보 5개]
    D --> E[사람이 후보 선택]
    E --> F[전사와 시각 보정]
    F --> G[ffmpeg 세로 편집]
    G --> H[프레임 검증]
    H --> I[완성 MP4]

핵심은 도구 수가 아니라 단계 사이의 계약이었다. Jockey가 start_sec와 end_sec를 숫자로 넘겨주자 그 결과를 ffmpeg 입력으로 바로 사용할 수 있었다.

1단계: YouTube URL 하나로 인덱싱

jockey_add_media에 YouTube 링크를 넣었다. 별도 다운로드나 업로드 없이 964초, 약 35MB의 강의가 약 4분 만에 준비됐다.

인덱싱 뒤에는 질의 가능한 지식 저장소와 HLS 스트림 URL이 생겼다. HLS URL 덕분에 원본 파일 전체를 내려받지 않고도 필요한 구간만 가져올 수 있었다.

2단계: 산문 대신 JSON 스키마로 후보 받기

가장 유용했던 기능은 jockey_query의 json_schema였다. 산문은 사람이 다시 읽고 옮겨야 하지만 스키마 응답은 다음 단계가 바로 소비할 수 있다.

{
  "candidates": [{
    "rank": "rank",
    "start_sec": "start time in seconds",
    "end_sec": "end time in seconds",
    "hook_strength": "high | medium | low",
    "shorts_title_ko": "title",
    "concept": "concept",
    "reason": "selection reason",
    "key_quote_ko": "key quote"
  }]
}

조건은 30~60초, 하나의 완결된 개념, 강한 훅이었다.

순위	구간	제목 후보	훅 유형
1	3:24–4:01	Git은 대체 왜 쓰는 걸까?	입문 개념
2	6:39–7:19	Git의 3단계, 택배로 이해하기	비유
3	8:00–8:40	git add .을 함부로 치면 안 되는 이유	실수 경고
4	11:41–12:12	Git과 GitHub, 뭐가 다른가요?	혼동 정리
5	14:43–15:20	clone·fetch·pull, 30초 만에 구분하기	비교

이 한 번의 실험에서는 다섯 후보 모두 완결된 개념 경계에서 잘렸다. 모든 영상에서 같은 결과를 보장한다는 뜻은 아니다. 다만 내용과 구조를 기준으로 후보를 좁히는 일에는 충분히 쓸 만했다.

3단계: 자막은 두 번 보정해야 했다

1번 후보의 문장 단위 전사를 요청하자 여러 문장이 약 8초짜리 같은 시간 구간을 공유했다. 그대로 쓰면 네 줄이 한꺼번에 나타났다 사라진다.

각 구간 안에서 문장 길이에 비례해 시간을 다시 나눴다. 8.13초 구간에 20자, 22자, 24자, 36자 문장이 있다면 약 1.6초, 1.8초, 1.9초, 2.9초를 배정하는 식이다. 정밀한 음소 정렬은 아니지만 이 짧은 클립에서는 자연스럽게 보였다.

두 번째 한계는 한국어 고유명사였다. .gitignore가 “깃이근호”, GitHub가 “기터부”로 전사됐다. 원문 ASR을 그대로 자막으로 쓰기는 어려웠다. 문맥을 유지한 채 기술 용어와 문법만 정리하도록 LLM 후처리를 거치자 게시 가능한 수준까지 개선됐다.

• Jockey는 개념 경계와 후보 구간을 찾는다.
• 후처리 로직은 문장별 자막 시각을 다시 배분한다.
• LLM 정제는 고유명사와 문법 오류를 문맥 안에서 고친다.
• 사람은 마지막 프레임과 자막을 확인한다.

4단계: HLS와 ffmpeg로 세로 영상 만들기

# Extract a 36.54-second segment starting at 204.93 seconds.
ffmpeg -ss 204.93 -i "https://.../playlist.m3u8" -t 36.54 \
  -c:v libx264 -crf 18 -c:a aac clip_raw.mp4

# Build a 9:16 video with a blurred background and ASS subtitles.
ffmpeg -i clip_raw.mp4 -filter_complex \
  "[0:v]split[s0][s1];
   [s0]scale=1080:1920:force_original_aspect_ratio=increase,
       crop=1080:1920,gblur=sigma=30,eq=brightness=-0.08[bg];
   [s1]scale=1040:-2[fg];
   [bg][fg]overlay=(W-w)/2:(H-h)/2,ass=subs.ass[v]" \
  -map "[v]" -map 0:a -c:v libx264 -crf 19 git_why_shorts.mp4

ASS 자막은 외곽선, 반투명 박스, 제목과 본문 위치를 제어하기 쉬웠다. 같은 비디오 입력을 배경과 전경에 재사용할 때는 [0:v]를 반복 참조하지 않고 split으로 나눠야 했다.

5단계: 마지막 검증은 프레임 네 장

완성본의 2초, 10초, 20초, 30초 지점에서 프레임을 뽑았다. 30초 프레임에서는 자막이 git --version을 설명할 때 실제 화면에도 같은 터미널 출력이 보였다.

정주행을 완전히 없앤 것은 아니다. 정주행 대신 대표 프레임과 경계 구간을 확인하는 짧은 검증으로 바꿨다.

무엇을 믿고 무엇을 확인해야 하나

신뢰 수준	항목	이번 실험에서의 판단
신뢰 가능	개념 경계 기반 후보 발굴	다섯 후보가 완결된 구간으로 나옴
신뢰 가능	자연어 검색과 구간 전사	원하는 개념을 찾는 데 유용
조건부	후보 시작·종료 시각	컷 앞뒤를 결과물에서 확인
조건부	문장별 자막 시각	시간 구간 재분배 필요
보정 필요	한국어 ASR 원문	고유명사와 기술 용어 교정 필요

발굴에는 몇 초의 오차가 허용되지만 자막은 0.5초만 어긋나도 어색하다. 같은 타임스탬프라도 용도에 따라 검증 기준이 달라져야 한다.

비용: 가정한 API 호출량으로 환산하면 약 1.64달러

아래 표는 2026년 9월 1일 TwelveLabs API 가격표를 기준으로, Marengo 인덱싱 1회와 전체 영상 Pegasus Analyze 2회, 출력 약 3,000토큰을 사용했다고 가정한 조건부 계산이다. Jockey 요청과 내부 API 호출이 일대일로 대응한다는 뜻은 아니다.

항목	사용량	공개 단가	추정 비용
Marengo 인덱싱	16.1분 × 1회	$0.042/분	$0.68
Pegasus 분석	16.1분 × 2회	$0.0292/분	$0.94
출력 텍스트	약 3,000토큰	$0.0075/1,000토큰	$0.02
ffmpeg 편집	로컬 처리	-	$0
합계			약 $1.64

이 계산에는 세 가지 경계가 있다.

1. 실제 Jockey 청구액이 아니다. Jockey 공개 페이지에는 별도 저장 용량 기반 요금제가 안내돼 있다.
2. 에이전트 내부 호출은 달라질 수 있다. 하나의 질의가 여러 분석 호출을 만들 수 있으므로 대시보드 사용량이 최종 기준이다.
3. 인덱스 유지 비용은 별도다. Developer 가격표의 월간 인프라 비용은 즉시 제작비 표에서 제외했다.

API Free 플랜의 600분은 인덱싱·분석·세그먼트 사용량을 합산한 한도다. 이는 Jockey 지식 저장소의 무료 5GB 요금제와 같은 개념이 아니다.

한 번 인덱싱한 영상에서 추가 쇼츠를 만들면 인덱싱 비용을 다시 내지 않는다. 강의 하나에서 여러 후보를 뽑을수록 첫 인덱스 비용이 분산된다.

이번 실험에서 남은 네 가지 교훈

JSON 스키마가 파이프라인의 등뼈였다

산문은 사람이 읽고 끝나지만 숫자로 된 시작·종료 시각은 다음 도구가 바로 사용할 수 있다. 구조화 출력이 생기는 순간 대화는 자동화 가능한 인터페이스가 된다.

신뢰는 도구별이 아니라 단계별로 정해야 한다

“Jockey를 믿을 것인가”라는 질문은 너무 크다. 후보 발굴은 믿고, 자막 시각은 보정하고, 고유명사는 검토하는 식으로 단계마다 신뢰 수준을 다르게 잡는 편이 실용적이다.

한 영상 자산은 여러 후속 작업의 출발점이 된다

한 강의 자산은 품질 검수, 쇼츠 후보, 챕터 생성, 질의응답으로 이어질 수 있다. 다만 사용하는 엔진과 기능에 따라 재인덱싱이 필요할 수 있으므로 모든 기능이 같은 인덱스를 그대로 공유한다고 단정해서는 안 된다.

사람의 역할은 정주행에서 승인으로 이동한다

사람이 영상 전체를 다시 보는 대신 후보를 고르고 대표 프레임을 확인했다. 판단을 없앤 것이 아니라 판단이 필요한 지점을 좁힌 것이다.

다음 자동화

다음 단계는 후보 선택이다. 훅 강도, 구간 길이, 개념 완결성을 점수화하고 나머지 네 후보까지 일괄 렌더링하면 영상 하나에서 쇼츠 다섯 편을 만드는 배치 흐름이 된다.

AI는 “여기가 좋다”까지 가져온다. “업로드해도 된다”는 마지막 판단은 사람이 한다.

차이는 그 판단을 위해 16분을 다시 보는 대신 프레임 네 장을 확인했다는 데 있다.

환경과 출처

• 환경: Claude Cowork, TwelveLabs Jockey MCP, ffmpeg 6.1
• 대상: Git·GitHub 입문 강의 16분 4초
• 가격 기준: TwelveLabs API Pricing, 2026-09-01
• Jockey 제품 요금제: Jockey
• 제품 구조: Video Intelligence Is Going Agentic
• 분석 과금 범위: TwelveLabs FAQ
• 이전 실측기: TwelveLabs Jockey로 강의 검수 파이프라인 만들기

Jockey는 공식 소개 당시 research preview로 안내된 제품이다. 이 글의 시간과 결과는 한 번의 실행에서 관찰한 값이며 서비스 성능 보장이 아니다.