하드서브 vs 소프트서브: 실제로 뭘 내보내야 할까요?
하드서브는 영상의 픽셀 안에 구워져 끌 수 없고 재인코딩이 필요하지만, 소프트서브는 언제든 끄거나 바꿀 수 있는 별도의 자막 트랙이에요. 어떤 플랫폼이 실제로 자막 파일을 받아주는지 직접 확인해서 정리했어요.
하드서브는 영상의 픽셀에 그려져서 끌 수 없어요. 소프트서브는 플레이어가 그 위에 따로 그려주는 트랙이라 시청자가 끄거나 스타일을 바꾸거나 다른 언어로 바꿀 수 있어요. 전달할 곳이 자막 파일을 아예 읽지 못할 때는 하드서브를, 그 외에는 언제나 소프트서브를 내보내세요.
이건 품질 문제가 아니라 전달 방식의 문제예요. 자막 파일을 거부하는 곳의 목록은 소셜 플랫폼들이 우리에게 학습시킨 것보다 훨씬 짧고, 잘못 짐작하면 영상 전체를 다시 인코딩해야 하는 대가를 치르게 돼요.
하드서브와 소프트서브, 나란히 비교하기
| 속성 | 하드서브 | 소프트서브 |
|---|---|---|
| 텍스트가 있는 곳 | 모든 프레임의 픽셀 안 | 별도의 트랙이나 파일 안 |
| 시청자가 끌 수 있음 | 아니요 | 네 |
| 시청자가 언어를 바꿀 수 있음 | 아니요, 언어마다 영상이 따로 필요 | 네, 트랙이 있다면 |
| 스타일이 유지됨 | 항상, 렌더링한 그대로 | 플레이어가 지원할 때만 |
| 재인코딩이 필요함 | 네 | 아니요 |
| 내보낸 뒤에도 수정 가능 | 아니요, 마스터에서 다시 렌더링해야 함 | 네, 텍스트 파일만 편집하면 됨 |
| 모든 플레이어에서 재생됨 | 네 | 플레이어에 따라 다름 |
| 기계가 읽고 색인할 수 있음 | 아니요 | 네 |
| 실제로 내보내는 것 | 언어마다 영상 하나씩 | 영상 하나에 작은 텍스트 파일들 |
대부분의 논쟁을 정리해 주는 건 일곱 번째 행이에요. 하드서브는 실패할 일이 없어요: 영상이 재생되기만 하면 텍스트는 고른 크기와 색깔 그대로 거기 있어요. 10년 된 스마트 TV에서도, 음소거로 자동재생되는 피드에서도, 미리보기 썸네일에서도요. 표의 다른 모든 행은 소프트서브 쪽 손을 들어주지만, 이 한 행 때문에 하드서브는 아직 사라지지 않았어요.
왜 한쪽은 재인코딩이 필요하고 다른 쪽은 아닐까
프레임에 텍스트를 그려 넣는다는 건 프레임을 디코딩하고, 그 위에 그림을 그리고, 다시 인코딩한다는 뜻이에요. 마지막 단계는 피할 수 없어요 — 바뀐 픽셀은 다시 파일로 써내야 하고, 영상 인코더는 손실이 있을 수밖에 없어요.
소프트 자막은 인코더에 아무것도 요구하지 않아요. 먹싱은 기존 영상과 오디오 스트림을 손대지 않고 그대로 복사한 다음, 그 옆에 세 번째 스트림을 추가해요.
ffmpeg -i input.mp4 -i subs.srt -c copy output.mkv
구워 넣기는 모든 프레임을 건드려야 하고, 영상 스트림에는 -c copy 지름길을 쓸 수 없어요.
ffmpeg -i input.mp4 -vf "subtitles=subs.srt" -c:a copy output.mp4
첫 번째 명령어는 디스크에서 파일을 읽어 들이는 정도의 시간이면 끝나요. 두 번째 명령어는 영상 전체를 인코더에 통과시키는데, 두 시간짜리 녹화라면 꽤 오래 기다려야 하고 품질 손실도 눈에 잴 수 있는 수준이 돼요. 이 손실은 알 수 없는 게 아니라 통제할 수 있는 값이에요 — CRF로 정하는 값이고, 영상에 자막 구워 넣기에서 손실을 눈에 안 보이게 유지하는 설정을 다뤄요.
언어가 하나 이상 얽히면 이 비대칭은 더 커져요. 여덟 개 언어를 소프트 자막으로 만들면 작은 텍스트 파일 여덟 개, 또는 .mkv 하나 안의 트랙 여덟 개면 끝나요. 여덟 개 언어를 구워 넣으면 완전한 인코딩 여덟 번, 저장할 파일 여덟 개, 업로드 여덟 번이 필요해요 — 그래서 다국어 전달은 보통 대부분의 언어는 소프트 트랙으로, 가장 중요한 한두 개 언어만 구워 넣는 방식을 뜻해요.
소프트서브는 정말로 시청자에게 도달할까요?
깔끔했던 답이 여기서 무너져요. 솔직하게 짚고 넘어갈 가치가 있는데, 올바른 자막 파일과 그걸 실제로 읽는 시청자 사이에서 다섯 가지가 잘못될 수 있기 때문이에요.
- 파일이 영상과 따로 떨어진다. 영상 옆에 딸린
.srt파일은 두 번째 첨부파일로 함께 이동하는데, 두 번째 첨부파일은 채팅 앱, 공유 드라이브, 재업로드 과정에서 잘 사라져요. 컨테이너 안에 먹싱된 트랙에는 이 문제가 없어요. - MP4는 자막을 제대로 지원하지 못한다. 이 컨테이너는 자막을
mov_text라는, 폰트도 색상도 위치 지정도 없는 순수 타임드 텍스트 형식으로 담아요. Apple의 플레이어는 이걸 읽지만, 다른 여러 플레이어는 이 트랙을 조용히 무시해요. 소프트 자막을 넣은.mp4가 아무것도 보여주지 않는 가장 흔한 이유가 바로 이거예요. - 스타일은 렌더러 마음이다.
.ass트랙은 외곽선, 위치, 폰트, 카라오케 타이밍까지 담고 있어요. mpv, VLC, Plex는 이걸 전부 그려주는 반면, 저가형 TV 앱은 이걸 몽땅 버리고 흰색 텍스트만 보여줘요. 형식 비교 글에서 어떤 변환에서 어떤 기능이 살아남는지 다뤄요. - 플랫폼은 업로드한 걸 다시 인코딩한다. 소셜 플랫폼은 올린 파일을 분해한 다음 자기만의 규격으로 다시 조립해요. 자막 스트림을 포함해서, 플랫폼이 애초에 찾지 않던 건 그 재조립 과정에서 살아남지 못해요.
- 음소거 자동재생. 피드는 영상을 소리 없이, 캡션도 기본으로 꺼진 채 재생을 시작해요. 그래서 시청자가 직접 켜야 하는 자막은 대부분의 시청자가 끝내 보지 못하는 자막이 돼요.
그렇다고 소프트 자막이 나쁜 기본값이라는 뜻은 아니에요. 다만 “내 VLC에서는 잘 돼요”와 “시청자에게도 잘 통해요”가 왜 서로 다른 주장인지를 설명해 줄 뿐이에요.
어떤 플랫폼이 자막 파일을 받아줄까요?
2026년 9월 기준, 각 플랫폼의 공식 문서를 직접 확인했어요.
| 대상 | 자막 파일을 받아줌 | 내보낼 것 |
|---|---|---|
| YouTube | 네, .srt, .vtt, .ttml 등 | 소프트서브 |
| Vimeo | 네, .srt와 .vtt | 소프트서브 |
네, 파일명에 로케일이 들어간 .srt | 소프트서브 | |
네, .srt | 소프트서브 | |
| TikTok | 아니요 | 하드서브 |
| Instagram Reels | 아니요 | 하드서브 |
| X | 아니요 | 하드서브 |
| 자체 사이트 | 네, <track> 요소 안의 .vtt | 소프트서브 |
| VLC, mpv, Plex, Jellyfin | 네, .srt나 .ass, 별도 파일이든 .mkv 안이든 | 소프트서브 |
세 행은 특히 날카로운 함정이 있어요. YouTube가 지원하는 형식은 스무 개 가까이 되지만 그 목록에 .ass는 없어서, .ass 파일의 스타일은 업로드하는 순간 사라져요. Facebook은 video.en_US.srt처럼 정확한 형식으로 로케일이 들어가지 않은 캡션 파일을 거부해요. 그리고 YouTube는 업로드 가능한 컨테이너 목록에 .mkv를 아예 올려두지 않았는데, 이건 다중 트랙 .mkv가 플랫폼이 아니라 플레이어를 위한 전달 형식이라는 뜻이에요.
“아니요”가 적힌 세 행에는 설명이 필요해요. TikTok, Instagram, X는 모두 앱 안에서 자체적으로 캡션을 생성하는데, 이건 우리가 만든 자막을 받아주는 것과는 전혀 다른 이야기예요. 우리가 얻는 건 그들의 전사, 그들의 스타일, 그들의 줄바꿈, 그리고 한 줄을 얼마나 빨리 읽을 수 있는지에 대한 그들의 기준이에요 — 그중 어느 것도 우리가 통제할 수 없어요.
하드서브, 소프트서브, 아니면 둘 다를 내보내야 할 때
“YouTube나 Vimeo에 올릴 거예요.” 소프트서브예요. 언어마다 .srt나 .vtt 하나씩이면 돼요. 텍스트는 검색에 색인되고, 시청자가 직접 언어를 바꾸고, 오타 하나는 영상을 건드리지 않고 10초면 고쳐져요.
“TikTok, Reels, X에 올릴 거예요.” 하드서브예요, 그것 말고는 아무것도 살아남지 못하니까요. 거실용이 아니라 소리 없이 엄지손가락으로 넘기는 세로형 피드에 맞춰 스타일을 입히세요.
“검토용으로 클라이언트에게 컷을 보낼 거예요.” 하드서브예요. 마스터 파일을 보내는 게 아니라, 리뷰어가 무엇을 더블클릭하든 처음 열리는 순간부터 제대로 보여야 하는 걸 보내는 거니까요.
“영화, 강의 라이브러리, 아카이브를 전달할 거예요.” .mkv 안의 소프트서브예요. 언어마다 트랙 하나씩, 필요한 폰트까지 첨부해서요. 모든 언어를 파일 하나에 담으면서도 시청자가 직접 고를 수 있게 하는 유일한 전달 방식이에요.
“같은 영상을 다섯 개 언어로 낼 거예요.” 둘 다예요. 다섯 개 언어 전부에는 소프트 트랙을, 시청자가 가장 많은 한두 개 언어에는 구워 넣은 사본을 추가하세요.
“어디에 쓰일지 아직 모르겠어요.” 깨끗한 마스터 파일과 자막 파일을 나란히 보관해 두고, 필요할 때마다 사본을 구워 내세요. 순서를 거꾸로 하면 오후 반나절을 날리는 실수가 돼요 — 소프트서브는 언제든 나중에 구워 넣을 수 있지만, 하드서브는 절대 다시 빼낼 수 없으니까요.
하나의 전사에서 둘 다 뽑아내기
실무에서 진짜 중요한 질문은 어느 쪽이 더 나은가가 아니에요. 같은 작업에서 둘 다 뽑아내는 방법이 진짜 질문이에요 — 전사도 타이밍도 스타일도 둘 중 어느 쪽이든 똑같고, 달라지는 건 마지막 내보내기 단계뿐이니까요.
Sablate가 짜인 방식이 바로 이거예요. 작업 하나에 전사 하나와 언어별 번역 레이어가 들어가고, 각 레이어는 자기만의 스타일과 문자 체계에 맞는 폰트를 가져요. 갈림길은 내보내기 단계에서 생겨요: 자막 파일을 읽는 플랫폼에는 자막 파일을, 읽지 못하는 플랫폼에는 구워 넣은 .mp4를, 로컬 재생용으로는 언어별 트랙이 담긴 .mkv 하나를 내보내면 돼요. 이 세 가지 사이에서 전사를 두 번 할 필요는 없고, 영상이 컴퓨터 밖으로 나가는 일도 없어요. 무료 요금제는 최대 10분 영상, 월 3개 작업, 작은 워터마크가 있는 구워 넣은 .mp4까지 지원해요. .ass 내보내기와 다중 트랙 .mkv는 $29 한 번의 결제로 끝나는 Pro에 포함되고, 자세한 내용은 가격 페이지에서 확인할 수 있어요.
다만 파일 하나, 언어 하나뿐이라면 솔직한 답은 애플리케이션 자체가 필요 없을 수도 있다는 거예요.
| 작업 | FFmpeg와 mkvmerge | Subtitle Edit | Sablate |
|---|---|---|---|
| 자막 파일을 화면에 구워 넣기 | 가능 | 가능 | 가능 |
자막 트랙을 .mkv에 먹싱하기 | 가능 | 불가능 | 가능, Pro |
| 음성을 자막 파일로 전사하기 | 불가능 | 가능 | 가능 |
| 전사 하나에 여러 언어 레이어 | 불가능 | 부분적으로 가능 | 가능 |
| 언어별 스타일과 문자 체계 폰트 | 불가능 | 불가능 | 가능 |
| 가격 | 무료 | 무료 | $29 일회성 |
FFmpeg와 mkvmerge는 먹싱과 굽기를 공짜로 해내고, Subtitle Edit은 Sablate가 앞으로도 따라가지 못할 만큼 많은 자막 형식을 읽어요. 지금 앞에 놓인 일이 언어 하나짜리 형식 손질이라면, 이 도구들이 더 나은 선택이고 비용도 전혀 들지 않아요.
한 줄 요약
기본은 소프트서브, 전달할 곳이 선택지를 안 주면 하드서브, 그리고 어느 쪽이든 깨끗한 마스터는 따로 보관하세요. 자막 작업에서 되돌릴 수 없는 단계는 구워 넣기 하나뿐이니, 이 단계는 맨 마지막에 두고 프로젝트 단위가 아니라 전달할 곳 단위로 결정하세요. 언어가 둘 이상이라면 소프트 트랙부터 먼저 만들고, 구워 넣은 사본은 하나하나를 세로형 크롭이나 소셜용 컷다운과 똑같이 하나의 렌더 결과물로 다루세요.