Rendi로 동영상 자막 넣기: SRT를 MP4에 영구 삽입하는 법

핵심부터: 동영상 자막 넣기는 언제 번인이 맞을까?

플레이어의 자막 트랙 설정과 관계없이 모든 시청자에게 같은 자막을 보여줘야 한다면 SRT를 영상에 입힙니다. 시청자가 자막을 끄거나 언어를 바꾸고, 플레이어의 접근성 기능을 이용해야 한다면 SRT를 별도 트랙으로 유지하는 편이 맞습니다.

Rendi를 사용할 때의 실무 순서는 다음과 같습니다.

1. 최종 동영상과 SRT를 함께 검수합니다.
2. 두 파일을 Rendi가 가져올 수 있는 URL에 두거나, 로컬 파일을 먼저 Rendi에 업로드합니다.
3. 문서에 명시된 FFmpeg 자막 명령을 제출합니다.
4. 명령 ID를 폴링하거나 웹훅으로 최종 결과를 받습니다.
5. MP4 메타데이터를 확인하고 전체 영상을 시청한 뒤 다음 작업을 보냅니다.

이 순서는 중요합니다. 인코딩 자체는 성공했더라도 자막이 일찍 나오거나 이름이 틀렸거나, 플랫폼 인터페이스에 문구가 가려지면 결과물은 실패한 것이나 다름없습니다.

Rendi가 실제로 맡는 역할

Rendi는 편집자가 아니라 기계실에 가깝습니다. 로컬에서 실행할 FFmpeg 명령을 HTTP API로 전달하면 됩니다. 요청을 작업 지시서라고 생각하면 이해하기 쉽습니다. 입력 별칭은 재료의 위치를, FFmpeg 문자열은 수행할 작업을, 출력 별칭은 완성품의 이름을 지정합니다.

현재 요청 스키마에는 ffmpeg_command와 output_files가 필요합니다. 입력 키는 in_으로, 출력 키는 out_으로 시작하며 이 이름들은 명령 안에서 이중 중괄호 사이에 다시 등장합니다. 요청이 정상적으로 접수되면 작업의 인수표에 해당하는 command_id가 반환됩니다.

가장 단순한 방식은 동영상과 SRT를 파일명이 URL 끝에 표시되는 공개 HTTP URL 또는 만료 시간이 있는 서명 URL에 두는 것입니다. 노트북의 로컬 경로는 입력 URL로 사용할 수 없습니다. 로컬 파일은 Rendi의 멀티파트 직접 업로드 방식을 이용할 수 있으며, 최대 5 TB 파일을 지원합니다. 다만 이는 별도의 준비 단계입니다.

영상에 고정한 자막과 선택형 자막 트랙은 다른 결과물입니다

영상에 입힌 자막은 디코딩되는 모든 프레임의 일부가 됩니다. 화면 모양을 일관되게 유지할 수 있지만, 그 결정은 되돌릴 수 없습니다. 철자를 하나 고치려 해도 영상을 다시 렌더링해야 하며 시청자가 자막을 숨길 수도 없습니다.

선택형 자막 트랙은 화면과 분리된 상태로 남습니다. Rendi의 자막 예제도 MP4의 소프트 자막 트랙에는 mov_text를 권장하며 비디오 필터를 사용하지 않습니다. 이 방식은 시청자의 선택권을 유지하고 자막을 이미지에 구워 넣지 않습니다.

기준은 간단합니다. 시각적 일관성이 우선인 검수용 마스터나 소셜 미디어용 파일에는 자막을 입힙니다. 원본 SRT는 반드시 보관하고, 접근성·검색·번역·시청자 선택이 중요할 때는 선택형 트랙이나 별도 자막 파일도 제공합니다.

렌더링 비용을 쓰기 전에 SRT부터 확인합니다

가장 저렴한 렌더링은 다시 하지 않아도 되는 렌더링입니다. 이전 편집본이 아니라 정확한 최종본에 맞춰 SRT를 검수해야 합니다. 자막 순서, 시작 및 종료 시각, 이름과 숫자의 철자, 의도한 줄바꿈, 대표적인 악센트 문자나 비라틴 문자를 확인합니다. 자막이 로어 서드와 겹치거나 화면 아래쪽 가장자리에 너무 붙지 않는지도 살펴봅니다.

이 단계에 AI 전사까지 한데 묶어 생각하면 안 됩니다. 음성 인식으로 앞단에서 SRT 초안을 만들 수는 있지만, 이 워크플로에 들어오는 시점에는 사람 또는 신뢰할 수 있는 검수 절차가 문구와 타이밍을 이미 승인한 상태여야 합니다. 여기서 Rendi가 맡는 일은 렌더링입니다.

스타일을 적용한 Rendi 작업 제출하기

아래 Node.js 예제는 Rendi가 공개한 샘플 동영상과 샘플 SRT를 사용하므로 실행에 필요한 것은 RENDI_API_KEY뿐입니다. 페이로드는 Rendi의 현재 OpenAPI 필드명과 별칭 규칙을 따릅니다. force_style 값은 흰색 글자에 검은색 외곽선과 아래쪽 여백을 만들고, libx264와 AAC는 Rendi의 자막 레시피에 설명된 MP4를 생성합니다.

const headers = {
  "X-API-KEY": process.env.RENDI_API_KEY,
  "Content-Type": "application/json",
};

const submit = await fetch("https://api.rendi.dev/v1/run-ffmpeg-command", {
  method: "POST",
  headers,
  body: JSON.stringify({
    input_files: {
      in_video: "https://storage.rendi.dev/sample/big_buck_bunny_720p_16sec.mp4",
      in_srt: "https://storage.rendi.dev/sample/subtitles.srt",
    },
    output_files: { out_1: "subtitled.mp4" },
    ffmpeg_command:
      "-i {{in_video}} -vf \"subtitles={{in_srt}}:force_style='FontSize=22,PrimaryColour=&H00FFFFFF,OutlineColour=&H00000000,BorderStyle=1,Outline=2,Shadow=0,MarginV=36'\" -c:v libx264 -crf 20 -c:a aac -b:a 192k {{out_1}}",
  }),
});

if (!submit.ok) throw new Error(await submit.text());
const { command_id } = await submit.json();

for (;;) {
  const poll = await fetch(
    `https://api.rendi.dev/v1/commands/${command_id}`,
    { headers: { "X-API-KEY": process.env.RENDI_API_KEY } },
  );
  const job = await poll.json();
  if (job.status === "SUCCESS") {
    console.log(job.output_files.out_1);
    break;
  }
  if (job.status === "FAILED") throw new Error(job.error_message);
  await new Promise((resolve) => setTimeout(resolve, 2000));
}

자막 필터는 프레임 자체를 바꾸므로 비디오 재인코딩이 필요합니다. 스타일, 코덱, 품질은 조정할 수 있지만, 설정을 바꿀 때마다 검수가 필요한 새로운 결과물로 취급해야 합니다. Rendi의 공식 FFmpeg 치트시트에는 fontsdir와 FontName을 이용한 사용자 지정 폰트도 설명되어 있습니다. 전체 영상 라이브러리에 적용하기 전에 정확한 폰트와 글리프 구성을 시험합니다.

실제로 검증한 범위

2026년 9월 11일, 위 엔드포인트와 요청 필드, 별칭 규칙, 상태값, 응답 필드를 Rendi의 현재 OpenAPI 파일과 대조했습니다. 동일한 자막 필터를 FFmpeg 8.0.1에서 Rendi의 공개 샘플 동영상 및 SRT와 함께 로컬로 실행했습니다. 그 결과 H.264 비디오와 AAC 오디오를 담은 16초 길이의 1280 × 720 MP4가 만들어졌고, 5초 지점의 프레임에서 예상한 자막도 눈으로 확인했습니다.

이 환경에는 Rendi API 키가 없어 Rendi 클라우드 작업은 제출하지 않았습니다. 코드는 스키마를 확인했고 FFmpeg 작업은 로컬로 검증했지만, 클라우드 실행까지 마쳤다고 주장하지는 않습니다.

짧은 작업은 폴링하고, 긴 작업은 웹훅을 사용합니다

Rendi의 상태 엔드포인트는 QUEUED, PROCESSING, PREPARED_FFMPEG_COMMAND, FAILED, SUCCESS를 반환할 수 있습니다. POST 요청이 접수됐다고 완성된 영상으로 간주해서는 안 됩니다. 최종 상태가 될 때까지 기다리고, 실패하면 error_message를 표시하며, 성공한 뒤에만 결과물을 읽어야 합니다.

Rendi는 완료까지 약 30초 이하로 예상되는 작업에는 폴링을, 더 긴 작업에는 웹훅을 권장합니다. 웹훅에는 폴링과 동일한 완료 명령 데이터가 담깁니다. 운영 환경에서는 완료 처리기를 멱등하게 만들고 즉시 응답하도록 하며, 웹훅 전달이 끝내 실패할 때를 대비해 폴링을 복구 경로로 남겨둡니다.

민감한 결과물은 유료 요금제에서 is_private: true로 설정한 뒤 폴링할 때 사전 서명 URL을 요청합니다. 기본값은 공개 저장소입니다. 비공개 파일에는 영구 공개 URL이 없으며, 요청한 다운로드 링크의 유효 기간은 최대 7일입니다.

대량 처리 전에 결과물을 직접 확인합니다

SUCCESS는 FFmpeg가 작업을 끝냈다는 뜻일 뿐, 자막 품질이 좋다는 증명은 아닙니다. 기계가 읽는 응답과 실제 화면을 모두 확인해야 합니다.

먼저 output_files.out_1이 존재하고 storage_url이 열리는지 확인합니다. 반환된 재생 시간, 해상도, 코덱, 파일 형식을 목표한 납품 사양과 비교합니다. 그런 다음 첫 자막, 마지막 자막, 가장 빠른 대화, 줄바꿈, 이름, 숫자, 컷 또는 그래픽 오버레이 근처의 자막에 특히 주의하면서 전체 영상을 시청합니다.

이 검수를 통과한 뒤에야 같은 스타일 프리셋을 대기열에 넣어야 합니다. 원본 동영상 버전, SRT 버전, FFmpeg 명령, Rendi 명령 ID, 출력 파일 ID, 검수자의 결정을 함께 보관합니다. 이런 기록이 있어야 단순히 렌더링 파일이 쌓이는 수준을 넘어 운영 가능한 제작 시스템이 됩니다.

비용은 영상 길이가 아니라 바이트로 계산합니다

Rendi는 입력 미디어와 출력 미디어의 합산 크기를 집계합니다. Rendi의 가격 예시에서는 1 GB 입력과 0.5 GB 출력을 합쳐 처리량 1.5 GB로 계산합니다. 이 예시를 그대로 적용하면 Free 요금제의 50 GB 제공량으로 33개 작업을 완성하고 0.5 GB가 남으며, 기본 Pro 요금제의 250 GB로는 166개 작업을 완성하고 1 GB가 남습니다.

이 작업 수는 Rendi의 예시를 바탕으로 한 산술 결과이지 자막 처리 벤치마크가 아닙니다. 실제 고정 자막 MP4의 크기는 원본과 코덱 설정, 출력에 따라 더 커지거나 작아질 수 있습니다. 처리량을 예측하기 전에 실제 입력과 출력의 합산 크기를 측정합니다.

Free는 월 $0이며 처리량 50 GB를 제공하고 명령 실행 시간을 1분으로 제한합니다. 기본 Pro는 월 $25에 250 GB를 제공하며 명령 상한을 10분으로 늘립니다. 더 큰 CPU 구성과 실행 시간 무제한 구성은 Rendi 전체 가격 분석에 정리되어 있으므로 여기서 같은 표를 반복할 필요는 없습니다.

실제로 중요한 비교 기준은 운영 방식입니다. Kapwing Pro는 연간 결제 시 멤버당 월 $16, 월간 결제 시 $24로 안내되어 있습니다. 가끔 한 번씩 처리한다면 시각적 편집기가 더 편합니다. 승인된 에셋을 받아 반복 가능한 시스템 단계로 자막 마무리 작업을 수행하고, 누군가 편집기를 다시 열지 않아도 과정을 추적해야 한다면 Rendi가 더 잘 맞습니다.

효과가 가장 큰 7가지 워크플로

자막을 추가하는 모든 사람이 최적의 사용자는 아닙니다. 이미 승인된 SRT가 있고 최종 렌더링을 계속 반복하는 팀에 가장 잘 맞습니다.

제품으로 만들 만한 3가지 아이디어

1. 브랜드 규칙을 지키는 일괄 자막 마무리 도구

가장 유망한 기회입니다. 콘텐츠 팀과 에이전시를 위해 기능 범위를 좁힌 포털을 만듭니다. 동영상 URL, 승인된 SRT, 이름을 붙인 스타일 프리셋, 검수 페이지, 다운로드 가능한 MP4만 받으면 됩니다. 이 제품이 파는 것은 만능 편집기가 아니라 반복 가능성과 승인 절차입니다.

미국에서는 add subtitles to a video가 월 약 1,900회 검색되며 Kapwing Pro는 연간 결제 기준 멤버당 월 $16부터 시작합니다. 사용자 유입을 만들 만큼 수요 범위가 넓으면서도, 반복되는 팀 워크플로는 초점이 분명한 제품을 뒷받침할 만큼 구체적입니다.

판매 가능한 최소 버전에는 서명 URL 입력, SRT 검증, 변경할 수 없는 소수의 브랜드 프리셋, Rendi 제출, 웹훅 처리, 출력 메타데이터, 사람의 승인 또는 거절이 필요합니다. 문제는 방어력입니다. FFmpeg 호출 하나를 입력 폼으로 감싼 정도는 쉽게 복제됩니다. 지속적인 가치는 승인 이력, 재사용할 수 있는 브랜드 규칙, 버전 연결, 안정적인 장애 복구에서 나와야 합니다.

2. 자동화를 우선한 자막 렌더링 API

고객에게 FFmpeg 문법을 노출하고 싶지 않은 에이전시를 위해 안정적인 엔드포인트 하나를 제공합니다. 고객은 동영상 URL, SRT URL, 프리셋 이름, 콜백 URL을 보내고, 서비스는 프리셋을 검수된 명령으로 변환한 뒤 형식을 통일한 작업 결과를 반환합니다.

Burn subtitles into video는 미국에서 월 40회 검색되며 CPC는 $8.16입니다. 검색량은 작지만 의도는 유난히 구체적입니다. PAA 질문인 “SRT 자막을 동영상에 영구적으로 입히려면 어떻게 해야 하나요?”는 사실상 제품 요구사항과 같습니다.

MVP에는 인증, 요청 검증, Rendi 작업 연결, 멱등성 키, 웹훅 검증, 재시도에 안전한 상태 관리, 사용량 기록이 필요합니다. 문제는 유통입니다. 검색만으로는 사업을 지탱할 수 없고, Rendi가 이미 기반 API를 제공합니다. 이 중개 서비스가 선택받으려면 에이전시 연동, 프리셋, 운영 가시성, 지원에서 우위를 만들어야 합니다.

3. 자막 사전 검수와 두 가지 결과물 인계 시스템

하나의 최종 동영상에 SRT 하나가 맞는지 확인한 다음, 승인된 조합으로 고정 자막 검수용 MP4와 선택형 트랙을 포함한 납품용 MP4를 함께 만드는 검수 관문을 구축합니다. 어떤 자막 버전이 어떤 편집본에 대응하는지 자꾸 놓치는 현지화·교육·미디어 운영 팀이 대상입니다.

실제 PAA 질문인 “SRT 자막을 동영상에 어떻게 추가하나요?” 옆에는 현재 검색 결과에서 고정 자막과 선택형 자막을 혼동하는 사례가 반복해서 나타납니다. 이 제품은 운영자가 컨테이너 내부 구조를 직접 결정하지 않아도 두 작업을 모두 해결합니다.

MVP에는 자막 구간 분석, 재생 시간 비교, 안전 영역 미리보기, 버전 ID, 통제된 FFmpeg 처리 방식 두 가지, 승인 기록이 필요합니다. 문제는 기본적인 SRT 검증만으로는 하나의 기능일 뿐 회사가 되기 어렵다는 점입니다. 팀이 출시 절차에 제품을 계속 둘 만큼 검수 이력과 인계 통제가 가치 있어야 합니다.

한계와 솔직한 결론

Rendi는 이 워크플로에서 FFmpeg 인프라를 없애줍니다. 하지만 편집 책임까지 없애주지는 않습니다. 전사본을 수정하거나 잘못된 타이밍을 고치고, 읽기 좋은 줄바꿈을 선택하거나, 고정 자막이 올바른 접근성 형식인지 판단하지 않습니다.

또한 자막 번인을 무손실로 만들 수 없습니다. 자막 필터가 비디오 프레임을 바꾸므로 영상은 재인코딩됩니다. 품질, 실행 시간, 출력 크기는 명령과 원본에 따라 달라집니다. 기본 API 안전 제한은 300초이며, 요청할 수 있는 최대 시간은 요금제가 정합니다. 오래 걸리거나 연산량이 많은 작업에는 실제 인코딩 시간을 수용할 명령 실행 한도의 요금제가 필요합니다.

무료 브라우저 도구로 충분한 일회성 클립이라면 이 방식을 쓰지 않아도 됩니다. 시청자가 자막을 켜고 꺼야 한다면 자막을 영상에 입히지 않습니다. 검수하지 않은 스타일을 일괄 작업에 적용해서도 안 됩니다. 승인된 동일한 마무리 규칙을 많은 에셋에 안정적으로 반복해야 할 때 Rendi의 장점이 분명해집니다.

월요일에 바로 할 일

짧고 승인된 동영상 하나와 최종 SRT를 준비합니다. 둘 다 Rendi가 가져올 수 있는 URL에 둔 다음 원하는 스타일로 예제 페이로드를 실행하고, 반환된 메타데이터를 확인하며, 지원하는 가장 작은 화면에서 전체 MP4를 시청합니다. 검수를 통과한 뒤에만 승인된 명령을 프리셋으로 저장합니다. 마지막으로 워크플로가 동영상과 자막을 승인 완료로 표시하는 지점에 이 프리셋을 연결합니다.

이처럼 검수된 미디어 파이프라인을 비즈니스에 구축하려면 AI 프로덕션 시스템을 확인해 보세요.