AI 숏폼 비디오 생성기 구축하기: 워크플로우에는 프롬프트뿐만 아니라 기술(Skills)이 필요한 이유

대부분의 AI 숏폼 비디오 데모는 지루한 부분을 건너뜁니다.

그들은 완성된 TikTok, Reel, 또는 YouTube Short를 보여줍니다. 어쩌면 프롬프트(Prompt)를 보여줄 수도 있고, 생성된 스크립트(Script)나 최종 렌더링(Render) 결과물을 보여줄 수도 있습니다.

하지만 어려운 점은 비디오 하나를 만드는 것이 아닙니다.

진짜 어려운 점은 전체 시스템이 일회성 스크립트 더미, 기억이 가물가물한 FFmpeg 명령어, 깨진 자막, 일관성 없는 훅(Hook), 그리고 수동 업로드 단계로 변질되지 않으면서 15번째 비디오를 만들어내는 것입니다.

그 지점이 바로 AI 비디오 자동화에 관한 논의가 더 흥미로워지는 부분이라고 생각합니다.

다음과 같은 질문이 아니라 말이죠:

AI가 Short를 생성할 수 있을까?

대신 다음과 같은 질문이어야 합니다:

AI 에이전트(Agent)가 Shorts를 반복적으로 생성하기 위해 어떤 워크플로우(Workflow)가 필요한가?

저는 AI 숏폼 비디오 생성기를 구축하기 위한 터미널 기술(Terminal Skills) 활용 사례를 살펴보고 있었는데, 유용한 부분은 "버튼 하나만 누르면 무한한 콘텐츠가 출력된다"는 환상이 아니었습니다.

유용한 부분은 바로 스택(Stack)입니다.

진짜 작업은 파이프라인(Pipeline)이다

숏폼 비디오 생성기는 하나의 도구처럼 들립니다.

실제로 그것은 파이프라인(Pipeline)입니다:

주제 조사(Topic research)
  -> 스크립트(Script)
  -> 보이스오버(Voiceover)
...

각 단계는 서로 다른 실패 모드(Failure modes)를 가집니다.

주제 조사는 진부한 아이디어를 만들어낼 수 있습니다.
스크립트는 너무 길어질 수 있습니다.
목소리는 브랜드 이미지에서 벗어날 수 있습니다.
푸티지(Footage)는 내레이션과 일치하지 않을 수 있습니다.
자막은 플랫폼 UI 아래에 위치할 수 있습니다.
FFmpeg는 기술적으로는 유효하지만 플랫폼이 여전히 싫어하는 파일을 내보낼 수 있습니다.
업로드는 API에서는 성공하지만 실제 게시 워크플로우에서는 실패할 수 있습니다.

이 모든 것을 하나의 거대한 프롬프트(Prompt)로 해결하려고 하면, 에이전트는 너무 많은 운영 지식을 머릿속에 담고 있어야 합니다.

그것은 취약합니다.

더 나은 패턴은 워크플로우를 기술(Skills)로 나누는 것입니다.

기술(Skill)이 에이전트에게 주는 것

기술(Skill)은 단순한 코드 스니펫(Code snippet)이 아닙니다.

이러한 종류의 워크플로우에서 유용한 기술은 에이전트에게 다음과 같은 내용을 알려줍니다:

이 기능을 언제 사용할 것인가
어떤 입력값(Inputs)이 기대되는가
이후에 어떤 출력값(Output)이 존재해야 하는가
어떤 검증(Validation)이 필요한가
성공한 척하는 대신 언제 멈춰야 하는가

마지막 포인트가 중요합니다.

미디어 자동화에서 "명령어가 실행되었다"는 것만으로는 충분하지 않습니다.

에이전트(Agent)는 다음과 같은 사항들을 검증해야 합니다:

비디오가 실제로 9:16 비율인가?
재생 시간(Duration)이 목표 범위 내에 있는가?
파일에 오디오 스트림(Audio stream)이 포함되어 있는가?
자막(Captions)이 세이프 에어리어(Safe area) 안에 있는가?
코덱(Codec)이 플랫폼 친화적인가?
업로드 확인이 단순히 제작 도구(Composer)가 아닌, 최종 게시된 페이지에서 이루어졌는가?

이것이 자동화 데모(Automation demo)와 실제 운영 워크플로우(Operating workflow)의 차이입니다.

숏폼 비디오를 위한 실질적인 기술 스택 (Skills stack)

터미널 스킬(Terminal Skills) 유스케이스는 AI 숏폼 비디오 생성기를 하나의 거대한 단일체(Monolith)가 아닌, 하나의 스택(Stack)으로 정의합니다.

저는 이를 다음과 같이 분류하겠습니다.

1. 리서치 기술 (Research skill)

이 기술은 단순히 "트렌딩 토픽을 찾는 것"에 그쳐서는 안 됩니다.

사용 가능한 후보군을 생성해야 합니다:

주제 (topic)
시의성 (why it is timely)
타겟 오디언스 (target audience)
...

YouTube Shorts 파이프라인의 경우, 리서치 기술은 60초 이내에 시각적으로 설명할 수 있는 아이디어에 편향(Bias)되어야 합니다.

모든 좋은 기사가 좋은 쇼츠(Short)가 되는 것은 아닙니다.

2. 스크립트 기술 (Script skill)

숏폼 스크립트에는 제약 조건(Constraints)이 필요합니다.

유용한 스크립트 기술은 다음 사항들을 강제해야 합니다:

영상당 하나의 아이디어
첫 1~2초 내의 훅(Hook)
짧은 문장
각 섹션별 명확한 비주얼 비트(Visual beat)
긴 인트로 지양
채널에서 실제로 CTA를 사용하지 않는 한 모호한 CTA(Call to Action) 지양

출력물은 단순한 산문이 아니라 구조화되어야 합니다:

{
  "hook": "이 전화 한 통을 놓치면 지역 비즈니스는 수백 달러의 손해를 볼 수 있습니다.",
  "beats": [
...

그래야 렌더러(Renderer)가 작업할 수 있는 데이터가 생깁니다.

3. 보이스 기술 (Voice skill)

텍스트 음성 변환(Text-to-speech)을 호출하는 것은 쉽습니다.

브랜드와 일관된 목소리를 구현하는 것은 더 어렵습니다.

보이스 기술은 다음을 알고 있어야 합니다:

선호하는 제공업체 (Preferred provider)
보이스 ID 또는 스타일
페이싱 (Pacing)
목표 라우드니스 (Loudness target)
일시 정지(Pause) 사용 여부
파일 명명 규칙 (File naming conventions)
재시도 규칙 (Retry rules)

또한 비디오 조립(Assembly)이 시작되기 전에 오디오 재생 시간이 스크립트 타이밍과 대략적으로 일치하는지 검증해야 합니다.

4. 자막 기술 (Caption skill)

쇼츠에서 자막은 단순한 장식이 아닙니다.

자막은 포맷의 일부입니다.

자막 기술은 다음을 담당해야 합니다:

줄 길이 (line length)
단어 그룹화 (word grouping)
글꼴 크기 (font size)
대비 (contrast)
하단 안전 영역 (bottom safe zone)
단어 단위 강조 (word-level highlighting) 사용 여부
SRT 또는 자막 삽입 (burned-in) 출력 방식

이 지점에서 많은 AI 비디오 파이프라인 (pipelines)이 눈에 띄게 저렴해 보이기 시작합니다.

콘텐츠는 괜찮을지 몰라도, 자막이 너무 낮거나, 너무 넓거나, 너무 빠르거나, 혹은 TikTok/Shorts 인터페이스 아래에 가려져 있을 수 있습니다.

5. FFmpeg 또는 조립 기술 (assembly skill)

이것은 기계적인 계층 (mechanical layer)입니다.

완성된 에셋 (asset)을 예측 가능한 플랫폼용 출력물로 조립해야 합니다:

1080x1920
H.264
AAC
...

중요한 점은 FFmpeg 플래그 (flags)를 암기하는 것이 아닙니다.

중요한 점은 에이전트 (agent)가 출력 규약 (output contract)을 알고 있다는 사실입니다.

예를 들어:

ffprobe -v error -show_streams -show_format -of json output/short.mp4

이 확인 작업은 렌더링 (render) 후에 이루어져야 하며, 사람이 업로드 실패를 불평한 뒤에 이루어져서는 안 됩니다.

6. 업로드 기술 (Upload skill)

업로드 자동화는 제가 가장 보수적으로 접근할 부분입니다.

로컬 MP4 파일을 렌더링하는 것과 외부로 게시하는 것은 별개의 문제입니다.

업로드 기술은 다음을 분리해야 합니다:

업로드 준비 (prepare upload)
메타데이터 검증 (verify metadata)
초안 작성/예약 (draft/schedule)
...

이 모든 과정이 하나의 보이지 않는 단계로 처리되어서는 안 됩니다.

만약 사람의 승인 단계 (approval gate)가 필요하다면, 기술은 이를 명확하게 명시해야 합니다.

유용한 멘탈 모델 (mental model)

흔히 하는 실수는 이것을 다음과 같이 생각하는 것입니다:

프롬프트 (prompt) -> 비디오 (video)

더 나은 모델은 다음과 같습니다:

브리프 (brief) -> 구조화된 에셋 (structured assets) -> 렌더링 (render) -> 검증 (verify) -> 게시 결정 (publish decision)

이 모델은 설명하기에는 더 느리지만, 프로덕션 (production) 환경에서는 훨씬 더 신뢰할 수 있습니다.

또한 에이전트에게 더 작은 작업들을 부여합니다.

리서치 기술 (research skill)이 FFmpeg를 이해할 필요는 없습니다.
자막 기술 (caption skill)이 YouTube Data API를 알 필요는 없습니다.
업로드 기술 (upload skill)이 스크립트 (script)를 발명할 필요는 없습니다.

각 기술은 고유한 경계 (boundary)를 가집니다.

그 경계가 바로 워크플로우 (workflow)를 디버깅 (debuggable) 가능하게 만드는 요소입니다.

내가 가장 먼저 자동화할 것

만약 제가 이것을 처음부터 구축한다면, 완전 자동 게시부터 시작하지는 않을 것입니다.

대신 검토용 폴더를 생성하는 로컬 생성기 (local generator)부터 시작할 것입니다:

shorts/
  001/
    script.json
...

그 다음 에이전트(agent)는 다음과 같이 보고합니다:

Generated 12 Shorts.
10 passed validation.
2 need review:
...

이것만으로도 이미 충분히 가치가 있습니다.

이는 최종 게시 결정권은 인간이 유지하면서도, 반복적인 제작 작업은 제거해 줍니다.

이 과정이 신뢰할 수 있게 된 이후에야 스케줄링(scheduling)이나 업로드 자동화(upload automation)를 추가할 것입니다.

더 중요한 점

AI 비디오 자동화는 단순히 모델(model)의 문제가 아닙니다.

그것은 워크플로우(workflow)의 문제입니다.

이 분야에서 승리하는 팀은 가장 긴 프롬프트(prompt)를 가진 팀이 아닐 것입니다.

그들은 프로세스의 각 취약한 부분을 작고, 문서화되었으며, 재사용 가능한 기술(skill)로 전환하는 팀이 될 것입니다:

리서치 (research)
스크립트 작성 (scripting)
음성 (voice)
자막 (captions)
렌더링 (rendering)
검증 (validation)
업로드 (upload)
분석 (analytics)

이것이 바로 "멋진 영상 하나를 만들었다"에서 "모든 내보내기(export) 과정을 일일이 감시하지 않고도 반복 가능한 콘텐츠 파이프라인(content pipeline)을 구축할 수 있다"로 나아가는 방법입니다.

그리고 이것이 제가 가장 중요하게 생각하는 부분입니다.

데모(demo)는 비디오입니다.

제품(product)은 워크플로우입니다.

Source use case: Build an AI Short Video Generator