목록으로 돌아가기
20262026-01-2411분 읽기

쇼츠팩토리 제작기(2) - SKILL을 활용한 완전 자동화

쇼츠팩토리 제작기(2) - SKILL을 활용한 완전 자동화

"반자동화도 편하지만, 아예 손을 떼고 싶다"

쇼츠팩토리 v5를 만들고 나서 편집 속도는 확실히 빨라졌다. 원본 영상을 넣으면 하이라이트를 찾고, 자막을 만들고, 세로 영상으로 렌더링하는 흐름까지 이어졌다. 예전처럼 타임라인을 직접 붙잡고 컷을 잘라내는 일은 많이 줄었다.

그런데 며칠 써보니 이상하게도 피로가 완전히 사라지지는 않았다. 자동화된 기능은 많았지만, 운영자는 여전히 나였다. 오늘 찍은 파일이 어디 있는지 찾고, 어떤 버튼을 먼저 눌러야 하는지 기억하고, 결과물이 어색하면 다시 돌리고, 렌더링이 실패하면 로그를 확인해야 했다.

이 상태를 나는 반자동화라고 부르기로 했다. 프로그램은 일을 빨리 해주지만, 일의 시작과 판단은 사람이 계속 들고 있는 상태다.

그때 떠오른 질문은 단순했다.

"이 과정을 AI가 직접 실행하게 만들 수는 없을까?"

그러던 중 Claude Code의 SKILL 기능을 공부했다. 처음에는 "프롬프트를 저장해두는 기능인가?" 정도로 생각했는데, 공식 문서와 샘플을 읽어보니 관점이 조금 달랐다. Skill은 반복 작업을 위한 작은 실행 설명서에 가깝다. description으로 언제 사용할지 판단하고, SKILL.md에 실제 절차를 적고, 필요하면 scripts, references, assets 같은 보조 자원을 붙인다.

이 구조를 보자 쇼츠팩토리에 딱 맞는 지점이 보였다. 사람을 위한 화면을 더 만드는 대신, AI가 안전하게 호출할 수 있는 작업 계약을 만들면 되겠다는 생각이었다.

버튼 자동화와 스킬 자동화는 다르다

처음에는 단순히 UI를 자동 조작하게 만들 수도 있겠다고 생각했다. 파일 선택 버튼을 누르고, 렌더 버튼을 누르고, 완료 메시지를 기다리게 하는 식이다. 하지만 이 방식은 금방 한계가 보였다.

UI 자동화는 화면이 조금만 바뀌어도 깨진다. 버튼 이름이 바뀌거나, 모달이 하나 더 뜨거나, 파일 선택창의 기본 경로가 달라지면 에이전트는 쉽게 길을 잃는다. 무엇보다 실패했을 때 원인을 알기 어렵다. 클릭이 실패한 것인지, API가 실패한 것인지, 입력 영상이 문제인지가 한 덩어리로 뭉개진다.

그래서 방향을 바꿨다. AI에게 화면을 누르게 하는 게 아니라, 쇼츠팩토리의 핵심 파이프라인을 호출 가능한 명령 구조로 정리하기로 했다.

내가 정한 기준은 이렇다.

  • 사람에게 필요한 건 미리보기와 조작감이다.
  • AI에게 필요한 건 입력값, 실행 순서, 성공 조건, 실패 복구 방법이다.
  • UI는 사람이 볼 때 편해야 하고, Skill은 에이전트가 읽을 때 애매하지 않아야 한다.

이 차이를 인정하고 나서야 "완전 자동화"라는 말이 조금 구체적으로 바뀌었다. 완전 자동화는 버튼이 사라진 상태가 아니다. 사람이 매번 같은 판단을 반복하지 않아도 되는 상태다.

스킬은 마법 주문이 아니라 계약서다

쇼츠팩토리용 Skill을 설계하면서 가장 먼저 정리한 건 멋진 문장이 아니라 계약이었다. "쇼츠 만들어줘"라는 요청을 받았을 때, AI가 실제로 무엇을 확인하고 어떤 순서로 움직여야 하는지 적어야 했다.

예를 들면 스킬의 골격은 이런 식이어야 했다.

---
name: shorts-factory
description: Generate vertical YouTube Shorts from local source videos using the Shorts Factory backend. Use when the user asks to create, render, inspect, or prepare Shorts from raw video files.
---

# Shorts Factory

## Inputs
- source_dir: 원본 영상이 있는 폴더
- output_dir: 결과물을 저장할 폴더
- target_duration: 기본 45-60초, 필요 시 최대 3분
- style_preset: 자막 크기, 후킹 문구, 화면 크롭 기준

## Procedure
1. 원본 영상 후보를 찾고 최신 파일과 용량을 확인한다.
2. 백엔드 상태를 확인한다.
3. 하이라이트 후보를 추출한다.
4. 후보 구간별 후킹 문구와 자막을 생성한다.
5. 세로 영상으로 렌더링한다.
6. 결과물을 검수하고 파일 경로, 길이, 화면비, 실패 로그를 보고한다.

## Stop conditions
- 원본 파일이 없으면 추정하지 말고 사용자에게 경로를 요청한다.
- 렌더링 결과가 0바이트이거나 재생 불가이면 성공으로 보고하지 않는다.
- 자막 타이밍이 영상 길이를 넘으면 재렌더링한다.

이런 구조를 만들고 나니 "AI가 알아서 했다"는 말이 더 이상 막연하지 않았다. AI가 알아서 한 게 아니라, AI가 알아서 해도 되는 범위를 내가 문서로 좁혀둔 것이다.

공식 문서에서 강조하는 description도 여기서 중요해졌다. 설명이 "쇼츠를 도와주는 스킬"처럼 모호하면 에이전트가 언제 이 스킬을 써야 할지 흔들린다. 반대로 "로컬 원본 영상에서 YouTube Shorts를 생성하고 렌더링 결과를 검수한다"처럼 입력과 결과가 분명하면 호출 가능성이 높아진다.

실제 실행 흐름

내가 기대한 최종 사용 장면은 단순하다.

"오늘 찍은 영상으로 쇼츠 하나 만들어줘."

하지만 이 한 문장 뒤에는 꽤 많은 단계가 숨어 있다.

  1. 작업 폴더에서 오늘 생성된 영상 파일을 찾는다.
  2. 파일 크기, 확장자, 수정 시간을 보고 후보를 좁힌다.
  3. 백엔드 서버가 살아 있는지 확인한다.
  4. 원본 영상의 길이와 해상도를 읽는다.
  5. 쇼츠 후보 구간을 추출한다.
  6. 후보가 여러 개면 후킹 강도, 말의 완결성, 장면 변화 기준으로 우선순위를 매긴다.
  7. 선택된 구간에 자막을 붙이고 세로 비율로 크롭한다.
  8. 렌더링 결과를 검수한다.
  9. 결과 파일 경로와 판단 근거를 보고한다.

중요한 건 마지막 8번과 9번이다. 자동화는 결과 파일을 만드는 순간 끝나는 게 아니다. 결과물이 실제로 쓸 수 있는 상태인지 확인해야 끝난다. 렌더링은 성공했지만 첫 화면이 검은색일 수 있고, 자막이 화면 밖으로 밀렸을 수 있고, 음성은 있는데 오디오 트랙이 빠졌을 수도 있다.

그래서 나는 성공 조건을 "파일 생성"이 아니라 "업로드 후보로 검토 가능한 파일 생성"으로 바꿨다. 이 기준 하나가 자동화의 품질을 크게 바꿨다.

Shorts 규격도 자동화 조건에 넣어야 한다

쇼츠 자동화에서 영상만 잘 만들면 끝이라고 생각하기 쉽지만, 플랫폼 규격도 실행 조건에 들어가야 한다. YouTube 공식 도움말 기준으로 2024년 10월 15일 이후 업로드된 정사각형 또는 세로 비율 영상은 최대 3분까지 Shorts로 분류된다. 데스크톱 업로드 기준도 최대 3분, 정사각형 또는 세로 비율을 요구한다.

이 정보는 단순한 상식이 아니라 자동화 검수 규칙이 된다.

  • 결과 영상은 정사각형 또는 세로 비율이어야 한다.
  • 기본 목표 길이는 45-60초로 두되, 긴 설명형 클립은 최대 3분 안에서만 허용한다.
  • 1분을 넘는 결과물은 음원과 Content ID 리스크를 별도로 표시한다.
  • 사용자가 긴 영상으로 올리고 싶은 파일은 16:9 같은 넓은 비율로 별도 출력해야 한다.

이런 규칙을 스킬에 넣어두면 AI가 단순히 "렌더링 성공"만 보고하지 않는다. "이 파일은 Shorts 후보로는 적합하지만 1분을 넘기 때문에 음원 클레임 리스크가 있다"처럼 운영 판단에 가까운 보고를 할 수 있다.

실패도 설계해야 자동화가 된다

이번 작업에서 가장 크게 배운 점은 실패 설계였다. 자동화가 위험해지는 순간은 실패했을 때가 아니라, 실패를 성공처럼 보고할 때다.

그래서 실패를 단계별로 나눴다.

단계실패 상황AI가 해야 할 일
입력 탐색원본 영상이 없음경로를 추정하지 말고 후보 폴더와 필요한 파일 형식을 요청한다.
후보 선택영상이 여러 개임최신 파일, 용량, 길이를 표로 보여주고 선택 기준을 밝힌다.
하이라이트 추출후보 구간이 비어 있음장면 전환, 음성 에너지, 길이 기준을 낮춘 재분석을 시도한다.
자막 생성자막이 너무 길거나 겹침문장을 쪼개고, 한 줄 글자 수와 표시 시간을 조정한다.
렌더링파일 생성 실패명령, 로그 위치, 실패한 입력값을 함께 남긴다.
검수화면비/길이/오디오 문제성공으로 보고하지 말고 재렌더링 또는 사용자 승인을 요청한다.

이 표를 만들고 나서 스킬의 성격이 달라졌다. 예전에는 "작업을 실행하는 지시문"이었다면, 이제는 "작업을 멈춰야 할 때를 아는 지시문"이 됐다.

특히 자막은 자동화에서 자주 놓치는 부분이다. 영상은 멀쩡해 보여도 자막이 1초에 너무 많이 지나가면 실제로는 볼 수 없다. 그래서 자막 검수에는 최소한 다음 조건이 필요했다.

  • 한 화면에 너무 많은 글자가 나오지 않는가
  • 자막 시작/종료 시간이 영상 길이를 넘지 않는가
  • 후킹 문구가 첫 1-2초 안에 들어오는가
  • 얼굴이나 중요한 피사체를 자막이 가리지 않는가
  • 세로 크롭 후에도 핵심 피사체가 중앙에 남는가

이 정도까지 적어야 AI가 "자막 붙였다"에서 멈추지 않고, 실제 숏폼 결과물로 볼 수 있는지 판단할 수 있다.

God Skill로 만들면 오래 못 간다

처음에는 쇼츠팩토리 전체를 하나의 거대한 Skill로 만들고 싶었다. 원본 찾기, 분석, 자막, 렌더링, 업로드, 설명문 작성, 썸네일 생성까지 한 번에 묶으면 멋있어 보인다.

하지만 샘플 문서와 스킬 제작 가이드를 보면서 이 방식이 위험하다는 걸 알게 됐다. 하나의 Skill에 너무 많은 책임이 들어가면, 실패했을 때 어디를 고쳐야 하는지 알기 어렵다. 설명도 길어지고, 트리거도 넓어지고, 결과적으로 의도하지 않은 순간에 불려 나올 가능성이 커진다.

그래서 다음 버전에서는 역할을 나누는 쪽이 맞다고 본다.

  • shorts-intake: 원본 파일 탐색, 후보 선택, 메타데이터 확인
  • shorts-highlight: 하이라이트 후보 추출과 우선순위 판단
  • shorts-caption: 후킹 문구와 자막 스타일 적용
  • shorts-render: 세로 크롭, 인코딩, 렌더링 로그 관리
  • shorts-qc: 길이, 화면비, 오디오, 자막, 검은 화면 검수
  • shorts-publish-brief: 업로드 전 제목, 설명, 해시태그 초안 작성

이렇게 나누면 "쇼츠 만들어줘"라는 요청은 여전히 한 문장으로 시작할 수 있다. 다만 내부에서는 작은 책임들이 순서대로 이어진다. 사람이 보기에는 간단하고, 시스템 입장에서는 고칠 수 있는 구조가 된다.

메모리에는 취향을, 스킬에는 절차를 둔다

또 하나 정리한 기준은 메모리와 스킬의 역할 분리다.

내가 좋아하는 자막 톤, 기본 출력 폴더, 자주 쓰는 후킹 방식, 영상 길이 취향은 프로젝트 메모리나 설정에 두는 편이 낫다. 반면 어떤 API를 어떤 순서로 호출하고, 실패하면 무엇을 확인하며, 결과물을 어떤 기준으로 검수할지는 Skill에 있어야 한다.

둘을 섞으면 관리가 어려워진다. 취향은 자주 바뀌지만, 절차는 안정적이어야 한다. 오늘은 자막을 크게 쓰고 싶을 수 있지만, 렌더링 실패를 성공으로 보고하면 안 된다는 규칙은 바뀌면 안 된다.

그래서 나는 쇼츠팩토리 자동화의 기억을 이렇게 나누는 게 맞다고 봤다.

  • 메모리: "내 기본 스타일은 빠른 후킹, 큰 자막, 45-60초 결과물이다."
  • Skill: "원본 탐색, 후보 추출, 렌더링, 검수, 보고를 이 순서로 수행한다."
  • 프로젝트 설정: "백엔드 주소, 출력 폴더, 임시 파일 경로, 로그 경로는 여기에 둔다."

이 분리를 해두면 나중에 다른 콘텐츠에도 응용하기 쉽다. 예를 들어 강의 클립은 90초까지 허용하고, 제품 소개 영상은 첫 3초에 제품명이 반드시 나오게 하는 식으로 스타일만 바꾸면 된다. 절차는 그대로 재사용할 수 있다.

결과: "된다"보다 중요한 것은 "믿고 맡길 수 있다"

스킬을 붙인 뒤 가장 먼저 확인한 건 정말로 결과물이 만들어지는지였다. AI는 백엔드 서버와 통신했고, 원본 영상을 분석했고, 후보 구간을 골랐고, 자막이 들어간 세로 영상을 만들었다.

처음에는 그 자체만으로도 꽤 신기했다. 하지만 며칠 지나고 나니 더 중요한 기준이 생겼다.

이 자동화를 믿고 매일 돌릴 수 있는가?

한 번 성공하는 자동화는 데모다. 매일 돌릴 수 있는 자동화는 운영이다. 운영이 되려면 결과만큼 로그가 중요하고, 성공 메시지만큼 실패 메시지가 중요하고, 생성 속도만큼 검수 기준이 중요하다.

그래서 이번 버전의 의미는 "AI가 쇼츠를 만들었다"가 아니다. 더 정확히 말하면, 쇼츠팩토리를 사람이 직접 조작하는 앱에서 에이전트가 호출할 수 있는 작업 시스템으로 바꿔본 실험이었다.

다음 버전에서 바로 고칠 것들

다음 단계는 기능을 더 많이 붙이는 게 아니라, 자동화의 신뢰도를 높이는 쪽이다.

첫째, 결과물 QC를 별도 단계로 분리해야 한다. ffprobe나 렌더링 로그를 기준으로 영상 길이, 해상도, 화면비, 오디오 트랙, 파일 크기, 첫 프레임 상태를 확인해야 한다. 파일이 생겼다는 이유만으로 성공 처리하면 안 된다.

둘째, 자막 품질 기준을 수치화해야 한다. 한 줄 최대 글자 수, 화면당 최대 줄 수, 최소 표시 시간, 자막 겹침 여부를 검사해야 한다. 숏폼에서는 자막이 곧 편집 리듬이라서, 자막이 무너지면 영상 전체가 무너진다.

셋째, 하이라이트 후보를 하나만 뽑지 말고 후보 3개를 남겨야 한다. 자동화가 항상 최고의 장면을 고른다고 믿기보다는, AI가 1순위와 2순위의 차이를 설명하게 하는 편이 낫다. 그래야 내가 검수할 때 "왜 이 장면을 골랐는지" 빠르게 판단할 수 있다.

넷째, 업로드 전 승인 지점을 명확히 둬야 한다. 완전 자동화라고 해서 바로 게시까지 맡기는 건 아직 이르다. 생성과 검수는 자동화하되, 공개 게시 전에는 사람이 제목, 저작권, 맥락을 확인하는 단계가 필요하다.

다섯째, 실패 로그를 콘텐츠 개선 데이터로 써야 한다. 어떤 파일에서 하이라이트 추출이 자주 실패하는지, 어떤 길이에서 자막이 자주 밀리는지, 어떤 촬영 환경에서 세로 크롭이 어색한지 쌓이면 다음 촬영 방식까지 바꿀 수 있다.

마치며

이번 작업을 통해 쇼츠팩토리를 바라보는 관점이 바뀌었다. 예전에는 좋은 편집 기능을 많이 넣는 게 목표였다. 이제는 AI가 그 기능을 안전하게 다룰 수 있도록 절차를 작게 나누고, 실패를 설명하게 만들고, 결과물을 검수 가능한 상태로 내보내는 게 더 중요해졌다.

자동화는 "내가 안 해도 된다"에서 끝나지 않는다. 진짜 자동화는 "맡겨도 어디까지 했고 어디서 멈췄는지 알 수 있다"에 가깝다.

쇼츠팩토리 v2 Skill 실험은 그 기준을 처음으로 확인한 작업이었다. 다음 버전의 목표는 더 화려한 버튼이 아니라, 매일 돌려도 믿을 수 있는 제작 파이프라인이다.

참고한 자료