블로그 on Physical AI 드림팀

블로그 글을 숏폼 영상으로 자동 변환해서 유튜브에 올리기까지

Thu, 02 Jul 2026 00:00:00 +0900

블로그에 정리해 둔 글을 그냥 두기 아까워서, 글 하나를 60초짜리 세로형 교육용 숏폼 영상으로 만들고 유튜브에 자동으로 올리는 파이프라인을 만들었다. 목표는 세 가지였다. (1) 글을 어떻게 영상 구성으로 바꿀 것인가, (2) 그걸 자동으로 할 수 있는가, (3) 실제 영상 파일로 인코딩해 저장·업로드까지 되는가. 결론부터 말하면 셋 다 된다. 비전공자도 따라올 수 있게, 개념과 내가 헤맨 지점 위주로 정리한다.

전체 그림 먼저

파이프라인은 이렇게 흐른다. 각 단계는 뒤에서 하나씩 풀어 쓴다.

1
2
3
4
5
6
7
8
9


블로그 글(.md)
 ↓ ① 글을 "장면 대본"으로 압축 (AI가 요약)
장면 JSON
 ↓ ② 나레이션 음성 만들기 (TTS, 무료 한국어)
 ↓ ③ 장면 화면(이미지) 만들기 (HTML 또는 Pillow)
 ↓ ④ 이미지 + 음성 → 영상으로 합치기 (ffmpeg)
숏폼 mp4
 ↓ ⑤ 유튜브 업로드 (YouTube API)
유튜브 Shorts

이 전체를 매일 일정 시간에 자동으로 도는 스케줄로 걸어두는 게 마지막 단계다.

준비물: 무료 도구 네 가지

돈 드는 건 없다. 전부 무료다.

Python — 파이프라인을 묶는 접착제 역할.
ffmpeg — 이미지와 음성을 합쳐 mp4로 인코딩(영상 파일로 만드는 것)하는 도구. 영상 자동화의 핵심.
edge-tts — 글자를 사람 목소리로 읽어주는 TTS(Text To Speech). Microsoft의 무료 한국어 음성을 API 키 없이 쓸 수 있다. ko-KR-SunHiNeural(여성) 같은 목소리가 꽤 자연스럽다.
화면 만드는 도구 — 두 가지를 다 만들어 비교했다. 뒤에서 설명한다.

Windows라면 ffmpeg는 winget install Gyan.FFmpeg, 나머지는 pip install로 끝난다.

① 글을 “장면 대본"으로 쪼개기

블로그 글은 길다. 60초 숏폼에는 한국어로 대략 320~380자밖에 못 담는다. 그래서 글을 통째로 넣을 수 없고 핵심만 압축해야 하는데, 이 요약·재구성이야말로 AI(LLM)가 제일 잘하는 일이다.

글을 다음처럼 5개 장면으로 나눈 대본(JSON 형식)으로 바꾼다.

후킹 (0~~3초): 강한 한 줄로 시선 잡기 (“최신 AI 모델, 외우지 마세요”) 2~~4. 핵심 카드: 한 장에 한 개념. 짧은 문장 3개 + 나레이션
마무리: 결론 한 줄 + “전체 글은 블로그에서”

각 장면에는 화면에 띄울 글자와, 성우가 읽을 나레이션이 따로 들어간다. 블로그 글의 제목·소제목·표가 자연스럽게 후킹·핵심 카드·계보 도표로 대응된다는 점이 좋았다.

한 가지 팁: 나레이션에서 영어 약어는 한글 발음으로 적어야 TTS가 제대로 읽는다. VLA는 “브이엘에이”, AI는 “에이아이"처럼. 숫자도 “96%“보다 “구십육 퍼센트"로 적으면 자연스럽다.

② 나레이션 음성 만들기

장면별 나레이션 문장을 edge-tts에 넣으면 mp3가 나온다. 명령 한 줄이면 된다. 이 음성의 길이를 재서, 나중에 그 장면 화면을 그 시간만큼 보여주면 화면과 목소리가 자동으로 맞는다.

③ 화면 만들기: 두 가지 방법

세로형(9:16, 유튜브 Shorts 규격)의 카드 이미지를 장면마다 만든다. 두 방식을 다 만들어 비교했다.

A안 — HTML/CSS로 만들고 캡처: 웹페이지처럼 예쁘게 꾸민 뒤 브라우저로 스크린샷을 찍는다. 한글 타이포와 표·도표가 훨씬 깔끔하다. 교육용에 유리해서 이걸 채택했다.
B안 — Pillow(파이썬 그림 라이브러리)로 직접 그리기: 브라우저가 필요 없고 가볍다. 담백한 스타일.

여기서 초보가 꼭 만나는 문제 하나. 자막이 화면 폭을 넘어 줄이 깨진다. 글자 길이가 글마다 다르니 고정 폰트 크기로는 안 된다. 그래서 “한 줄에 들어갈 때까지 폰트 크기를 자동으로 줄이는” 로직을 넣었다. 이러면 어떤 글이 와도 자막이 깔끔하게 한 줄로 맞는다.

④ 영상으로 합치기 (ffmpeg)

장면마다 이미지 + 그 장면 음성을 붙여 짧은 클립을 만들고, 클립들을 순서대로 이어 붙이면 하나의 mp4가 된다. 페이드 인 같은 효과도 ffmpeg 옵션으로 넣을 수 있다. 60초 영상이 1~2MB로 가볍게 나온다.

⑤ 유튜브 자동 업로드: 여기가 진짜 삽질 구간

영상 만드는 것보다 유튜브에 자동으로 올리는 인증 과정이 훨씬 까다로웠다. 공식 방법은 YouTube Data API + OAuth 인증이다. 초보가 순서대로 만나는 함정을 그대로 적어둔다.

Google Cloud에서 API 사용 설정 + OAuth 클라이언트(데스크톱 앱) 만들기. 다운로드한 인증 파일(client_secret.json)이 "installed"로 시작하면 데스크톱 앱(정상), "web"이면 잘못 만든 것.
앱 이름에 “Google”·“YouTube” 같은 상표명을 넣으면 안 된다. 정책상 거부된다.
“프로덕션"으로 올리면 오히려 막힌다. 유튜브 업로드는 민감한 권한이라 프로덕션 상태에선 구글 정식 심사를 통과해야 한다. 개인용이면 “테스트” 상태로 두고 내 계정을 테스트 사용자로 추가하는 게 답이다.
“확인하지 않은 앱” 경고는 차단이 아니다. 테스트 모드에선 이 경고가 정상이다. 고급 → (앱이름)(으)로 이동을 눌러 통과하면 된다.
youtubeSignupRequired 오류 = 유튜브 채널이 없다는 뜻. 인증은 됐는데 그 구글 계정에 채널이 없으면 올릴 곳이 없다. youtube.com에서 채널을 먼저 만들면 해결된다.
테스트 모드는 토큰이 약 7일마다 만료된다. 자동화가 일주일에 한 번쯤 끊기므로, 주 1회 인증 명령을 한 번 다시 실행해 토큰을 갱신해 줘야 한다.

참고로 무료 사용량은 하루 10,000 유닛이고 업로드 1건이 1,600 유닛이라, 하루 약 6개까지 올릴 수 있다. 매일 몇 개면 충분하다.

매일 자동 실행: 규칙을 정하다

마지막으로 위 전체를 Windows 작업 스케줄러에 매일 오후 3시로 걸었다. 규칙은 이렇게 정했다.

게시된 글만 대상 (초안 제외).
“블로그 메이킹” 카테고리는 제외 (지금 이 글처럼 블로그 만들기 자체를 다룬 글은 영상으로 안 만든다).
오래된 글부터 순서대로 하루 2개씩 처리. 이미 처리한 글은 기록해 두고 다시 만들지 않는다.
밀린 글이 다 소진되면, 그다음부터는 새로 올라온 글을 자동으로 집어 처리한다.

한 줄 정리

블로그 글을 숏폼으로 바꾸는 핵심은 “긴 글을 5개 장면으로 압축하는 AI 단계” 와 “이미지+음성을 ffmpeg로 합치는 인코딩” 이고, 진짜 난관은 영상 제작이 아니라 유튜브 OAuth 인증(테스트 모드·채널 생성·토큰 만료) 이다. 이 셋만 넘으면 매일 자동으로 도는 숏폼 공장이 완성된다.

실제 결과물 — 이 글이 이렇게 숏폼이 됐다

아래 원본 글 하나가, 위에서 설명한 파이프라인을 거쳐 60초짜리 세로 영상으로 자동 변환됐다. 긴 글이 어떻게 5개 장면으로 압축됐는지 원본과 나란히 보면 감이 온다.

원본 글: 피지컬 AI, 최신 모델을 외우지 말고 ‘흐름’을 읽어라
결과 숏폼: 이 파이프라인으로 처음 업로드한 영상 (아래)

PaperMod에서 Stack 테마로 갈아타며 배운 것들

Tue, 30 Jun 2026 00:00:00 +0900

블로그 테마를 PaperMod에서 Stack(CaiJimmy/hugo-theme-stack)으로 교체했다. 색은 무채색(zinc) 톤으로, 폰트는 Pretendard로 커스텀했다. 단순히 “옷 갈아입기"로 끝나는 작업이 아니라 글 메타데이터와 자동화 prompt까지 한 사이클로 묶어야 일이 닫힌다는 걸 새삼 느꼈다. 헤맸던 지점 위주로 정리한다.

테마 붙이고 config에서 처음에 헤매는 것들

Stack은 submodule로 붙인다.

1

git submodule add https://github.com/CaiJimmy/hugo-theme-stack themes/hugo-theme-stack

GitHub Actions로 빌드한다면 checkout 단계에 submodules: recursive 옵션이 있어야 테마가 같이 받아진다. 이게 없으면 로컬에선 멀쩡한데 배포 빌드만 깨진다.

hugo.toml은 길지만, 처음에 발목 잡히는 건 세 가지뿐이다.

mainSections = ["posts"] — Stack 기본값은 단수형 "post"다. 우리 폴더가 posts/라면 이걸 명시하지 않으면 홈에 글이 한 개도 안 뜬다.
sidebar.avatar는 문자열 한 줄로. {enabled=..., src=...} 같은 중첩 테이블을 쓰면 빌드 에러가 난다.
메뉴 아이콘은 실재하는 파일명으로. themes/.../assets/icons/에 실제로 있는 이름이어야 한다. list, category처럼 없는 이름을 쓰면 빌드가 fail한다. archives, categories, tag, hash, home 정도가 안전하다.

커스텀의 90%는 custom.scss 한 파일에서 끝난다

Stack은 자기 style.scss 마지막에 @import "custom.scss";를 박아둔다. 그래서 우리 사이트의 assets/scss/custom.scss만 만들면 별도 설정 없이 자동으로 끼워져 컴파일된다. 이게 Stack 커스텀의 핵심이다.

이 파일에서 한 일은 다음과 같다.

색 변수(--body-background, --accent-color, --card-background 등)를 라이트/다크 모두 zinc 톤으로 override. 다크 모드는 :root[data-scheme="dark"] 블록에서 따로 잡는다.
Pretendard를 @import url(...) CDN으로 불러오고 --base-font-family를 교체. Stack 기본 폰트인 Lato는 한글 글리프가 없어서 시스템 fallback으로 떨어지면 글자가 둔탁해진다.
카드 타이틀을 2.2rem → 1.9rem으로 줄이고 letter-spacing: -0.01em. 한글은 영문보다 자간을 살짝 좁히는 쪽이 균형이 맞는다.
본문에 word-break: keep-all; overflow-wrap: anywhere; — 한국어가 어절 단위로 줄바꿈되어 훨씬 깔끔해진다.

가장 큰 함정: 카테고리 배지의 inline style

제일 오래 잡아먹은 건 카테고리/태그 배지였다. Stack은 카테고리·태그마다 hash로 색을 자동 생성해서 <a> 태그에 inline style로 직접 박는다. inline style은 외부 CSS를 이기기 때문에, SCSS로 그냥 덮어쓰면 먹지 않는다.

해결은 !important로 강제하는 것이다.

1
2
3
4


.article-category a, .article-tags a {
 background-color: var(--card-background-selected) !important;
 color: var(--card-text-color-secondary) !important;
}

이걸 안 하면 사이트 전체는 무채색인데 카테고리 배지만 알록달록하게 튄다.

글 메타데이터와 자동화 prompt까지 함께 손보기

Stack 사이드바의 카테고리 위젯이 살아나려면 각 글의 frontmatter에 categories:가 있어야 한다. 기존 글들은 PaperMod 시절이라 tags:만 있어서 위젯이 비어 있었다. 그래서 모든 글에 카테고리를 VLA / 피지컬 AI / 메타 3개 분류로 채워 넣었다.

여기서 멈추면 다음 날 새로 생기는 글에서 같은 문제가 반복된다. 그래서 매일 밤 자동 초안을 만드는 prompt-instructions.txt에도 categories 지시를 추가했다. 이제 다음 날부터 새 글은 자동으로 올바른 분류에 들어간다. 테마 교체를 글 메타데이터·자동화 prompt까지 한 사이클로 묶어야 일이 닫힌다는 게 이 작업의 교훈이다.

작업 흐름에서 챙긴 팁도 적어둔다.

별도 브랜치에서 작업. main은 머지 시점까지 건드리지 않는다.
로컬에서 hugo server를 띄워두고 SCSS를 고치면 hot reload된다. 확인할 때마다 GitHub Pages에 push하지 말 것.
배포 후 옛 모양으로 보이면 십중팔구 브라우저 캐시다. Ctrl+Shift+R이나 시크릿 창으로 먼저 확인하자. 빌드 자체를 의심하기 전에 curl로 라이브 CSS에 새 규칙이 들어갔는지 보는 게 더 빠르다.

한 줄 정리

Stack 테마 교체의 핵심은 custom.scss 한 파일과 inline style을 이기는 !important이며, 테마 변경은 글 메타데이터와 자동화 prompt까지 한 사이클로 묶어야 비로소 끝난다.