쇼츠 자막이 밋밋한 진짜 이유: 정지 배경의 함정과 '움직이는 글자'로 바꾸는 법

문제 제기: '텍스트 모션'인데 왜 멈춰 보일까

짧은 세로 영상(쇼츠)에 설명 자막을 넣었는데 완성본이 어쩐지 밋밋하다면, 원인은 대개 배경에 있습니다. 배경 그림 하나를 깔고 그 위에 자막을 얹는 방식은 만들기는 쉽지만, 재생 내내 배경이 멈춰 있으면 결과물이 '글자 붙은 사진'처럼 보입니다.
실제 작업 기록이 그랬습니다. 연출에 '텍스트모션(글자가 움직이는 연출)'이라는 이름을 붙여 놓고 완성본을 보니, 정작 움직임은 0이었습니다. 이름만 '움직임'이었고 실제로는 정지 이미지에 자막만 붙은 꼴이었죠. 이 글은 그 밋밋함의 두 가지 원인을 진단하고, 글자가 스르륵 등장하며 움직이는 방식으로 바꾼 과정을 독자가 따라 할 수 있게 정리한 것입니다.
결론을 먼저 말하면, 이 포맷의 핵심은 문구가 살아 움직여 시선을 끄는 것입니다. 그런데 처음 구현에서는 바로 그 핵심이 빠져 있었습니다. 왜 이런 일이 벌어지는지부터 짚어봅니다.

---

왜 위험한가: 두 가지 실패가 겹친다

처음 만든 방식은 '코드 화면(프로그래머가 보는 글자 나열 화면)을 배경으로 깔고 그 위에 자막을 얹는' 형태였습니다. 두 가지가 겹쳐 밋밋함을 만들었습니다.

• 배경이 시청자와 상관없는 화면이었다 — 코드 화면은 개발하는 사람에게나 익숙합니다. 일반 시청자에게는 낯설고 공감이 안 됩니다. 즉 만드는 사람 눈높이였지 보는 사람 눈높이가 아니었습니다.
• 움직임이 전혀 없었다 — 배경이 영상 내내 고정이라 사실상 정지 이미지에 자막만 붙었습니다.

여기서 위험한 지점은, 이런 결과물이 '완성된 것처럼 보인다'는 데 있습니다. 자막도 있고 배경도 있으니 겉보기엔 멀쩡합니다. 그래서 만드는 사람은 문제를 눈치채지 못하고 계속 같은 방식으로 여러 편을 찍어냅니다. 근본 원인은 포맷의 핵심을 축소해서 만든 것입니다. 글자로 시선을 끄는 연출의 핵심은 '문구가 살아 움직이는 것'인데, 이걸 '정지 배경 + 얹은 자막'으로 줄여 구현하면 이름만 남고 알맹이가 빠집니다.

---

확인 절차: 내 영상이 함정에 빠졌는지 점검하기

완성본을 보기 전에 아래 순서로 점검하면 밋밋함을 조기에 잡을 수 있습니다.

1. 재생 정지 테스트 — 영상을 3초 재생하고 멈춘 뒤, 아무 프레임이나 캡처합니다. 그 정지 화면과 실제 재생 화면의 인상이 거의 같다면 움직임이 없다는 신호입니다.
2. 배경 소거 테스트 — 배경을 단색으로 바꿔도 전달력이 그대로인지 봅니다. 그대로라면 배경은 장식일 뿐, 시선을 끄는 역할을 못 하고 있는 것입니다.
3. 시청자 대입 테스트 — 배경 요소(예: 코드 화면)를 목표 시청자가 이해하고 공감하는지 자문합니다. '나만 아는 화면'이면 관점이 어긋난 것입니다.
4. 글자 등장 확인 — 자막이 처음부터 끝까지 같은 자리에 고정돼 있는지, 아니면 구간마다 나타나고 사라지는지 봅니다. 고정이면 정지 자막입니다.

아래 표로 이전 방식과 이후 방식을 관점별로 비교했습니다.

배경	코드 화면(개발자에게만 익숙)	코드 요소 없는 어두운 그라데이션
움직임	없음(정지)	글자 등장 + 배경 느린 흐름
인상	자막 붙은 사진	글자가 살아 움직이는 영상

---

어떻게 고쳤나: 글자가 등장하는 방식으로 재설계

새 방식은 '움직이는 글자(키네틱 타이포그래피)'입니다. 배경에서 코드 요소를 완전히 빼고, 글자 연출을 화면의 주인공으로 세웠습니다. 실제로 바꾼 내용을 순서대로 옮깁니다.

1. 배경 교체 — 코드 화면을 빼고 코드 요소가 없는 어두운 그라데이션 배경으로 바꿉니다.
2. 글자 등장 연출 — 나레이션(음성 설명) 구간마다 문구가 서서히 나타나며(페이드) 옆으로 미끄러지듯(슬라이드) 등장하게 합니다. 이게 진짜 움직임입니다.
3. 배경에 느린 움직임 추가 — 배경이 아주 천천히 세로로 흐르게 해 '정지 이미지' 느낌을 없앱니다.
4. 구간 타이밍 자동 배분 — 각 문구가 화면에 머무는 시간을 글자 수에 비례해 나눕니다. 긴 문장은 오래, 짧은 문장은 잠깐 보이도록 맞춥니다.

작업 구조도 나눴습니다. 글자 카드와 배경 그림은 이미지 처리 도구(Pillow)로 그려서, 영상 합성 도구가 없는 개발용 컴퓨터에서도 한글 글씨체 품질을 미리 눈으로 확인할 수 있게 했습니다. 실제 영상 합성과 움직임 처리(합치기·서서히 나타나기·잘라내기)는 영상 편집 엔진(ffmpeg)에 맡겼고, 그 명령을 만드는 부분은 결과가 항상 같은 '순수한 계산 함수'로 두어 테스트하기 쉽게 했습니다.
이 분리가 핵심입니다. '글씨가 예쁘게 그려졌는가'는 이미지로 미리 보고, '움직임 명령이 맞는가'는 입력이 같으면 출력이 같은 함수라 값만 비교하면 됩니다. 새 방식으로 통째로 바꾸면서 기존 코드 화면 배경을 만들던 부분과 전용 설정값은 폐기했고, 렌더링 담당 부분은 기존과 똑같은 형태로 갈아 끼울 수 있게 만들어 실제 작업 흐름에서는 이 부분만 교체하면 됐습니다. 타이밍·합성 명령·글씨 이미지 생성에 대한 새 테스트를 포함해 388개 검사를 모두 통과시켰습니다.

---

잘못하면 어떻게 되나 + 적용 체크리스트

이 함정의 가장 큰 위험은 앞서 말했듯 '완성돼 보인다'는 착각입니다. 밋밋함을 방치한 채 같은 방식으로 여러 편을 만들면, 나중에 포맷을 통째로 다시 설계해야 합니다. 실제로 이번 작업도 코드 화면 배경을 걷어내고 글자가 살아 움직이는 렌더 경로를 새로 세우는, 부분 수정이 아닌 재설계였습니다. 초반에 정지 배경 함정을 알았다면 처음부터 핵심을 중심에 두고 만들 수 있었을 것입니다.
발행·제작 전 아래를 점검하세요.

• 포맷의 핵심(글자가 움직여 시선을 끄는 것)이 화면에 실제로 구현되어 있는가? 이름만 붙이지 않았는가?
• 배경이 시청자가 아니라 제작자 취향으로 골라지지 않았는가?
• 정지 프레임과 재생 화면의 인상이 확실히 다른가?
• 글자 등장·머무는 시간이 문장 길이에 맞게 배분되는가?
• 글씨 품질을 실제 렌더 전에 미리 확인할 수 있는 경로가 있는가?
• 연출 명령 생성 부분이 테스트 가능한 형태(같은 입력→같은 출력)로 분리돼 있는가?

기본 원칙: AI나 자동 생성 도구가 '완성됐다'고 알려도, 정지 프레임 캡처처럼 사람이 직접 눈으로 확인하는 작은 테스트를 반드시 거치세요. 실패 시 되돌릴 수 있게 이전 방식의 렌더 부분을 갈아 끼울 수 있는 구조로 남겨두는 것도 안전장치가 됩니다.

---

한계와 주의사항

이 글에서 다룬 것은 '만드는 방식'의 전환 기록입니다. 몇 가지 선을 분명히 해둡니다.

• 움직이는 글자 방식으로 바꾼 뒤 시청자 반응이나 조회수가 실제로 좋아졌다는 지표는 확인되지 않았습니다. 여기서 말한 '전후 비교'는 수치 성과가 아니라 화면 동작 자체의 차이입니다.
• 388개 검사 통과는 작업 시점 기록입니다. 실제 적용 시에는 본인 환경의 최신 테스트 상태를 다시 확인하세요.
• Pillow·ffmpeg는 이 작업에서 쓴 도구일 뿐이며, 비개발자라면 같은 원리(글자 등장·배경 움직임·타이밍 배분)를 지원하는 편집 도구로 대체할 수 있습니다. 핵심은 도구가 아니라 '핵심을 축소하지 말 것'과 '보는 사람 기준으로 고를 것' 두 원칙입니다.

어떤 연출도 모든 채널·주제에 '무조건' 맞지는 않습니다. 정지 배경이 더 어울리는 포맷(예: 정보 나열형 카드)도 있으니, 위 확인 절차로 내 영상에 움직임이 필요한지 먼저 판단한 뒤 적용하시길 권합니다.
이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.