목록으로 돌아가기
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 실험은 그 기준을 처음으로 확인한 작업이었습니다. 다음 버전의 목표는 더 화려한 버튼이 아니라, 매일 돌려도 믿을 수 있는 제작 파이프라인입니다.

참고한 자료