Riverasol

연구개발 추진 방안

AI 에이전트 기반 영상 제작 자동화

어떤 기술로 어떻게 구성할 것인지를 다룹니다. 범위와 일정은 기술 검증 이후 후속 문서에서 확정합니다.

작성
유니 스튜디오
작성일
2026-08-27
버전
v1.8 (초안)

요약

영상 제작 공정을 AI 에이전트가 조작할 수 있는 형태로 만드는 일입니다. 생성 도구는 이미 공개되어 있으므로, 이 연구는 도구가 아니라 사람의 지시를 기계가 끝까지 수행하도록 연결하는 방법을 다룹니다.

접근

등장인물을 매번 새로 만들지 않고 자산으로 축적합니다. 인물 한 명을 학습시켜 파일로 만들어 두면 이후 모든 영상에 같은 인물이 출연하며, 출연료도 일정 조율도 초상권 문제도 없습니다. 이 파일을 배우라고 부릅니다. 배우를 만드는 일은 배우당 한 번이고 배우로 영상을 만드는 일은 계속 반복되므로, 자동화의 대상은 뒤쪽입니다.

기술 구성

공정채택
배우 학습Krea 2 · musubi-tuner
이미지 생성ComfyUI · Krea 2
영상 생성LTX-2.5
조작 계층유니핸즈
무인 실행헤르메스

전부 로컬에서 동작하며 외부로 데이터를 보내지 않습니다.

확정된 것과 남은 것

기술 구성과 연결 방식은 확정했습니다. 각 도구는 개발사 문서와 공개된 실측 자료를 근거로 골랐습니다. 다만 이 조합 전체를 보유 장비에서 측정한 적은 없으므로, 착수 초기에 검증 항목을 먼저 통과시킵니다. 항목과 미달 시의 대안은 9절에 있습니다.

이 문서의 범위

어떤 기술로 어떻게 구성할 것인지만 다룹니다. 분량과 일정은 측정 없이 적으면 지킬 수 없는 약속이 되므로, 범위와 산출물은 2번 문서에서, 일정과 판정 기준은 3번 문서에서 확정합니다.


1. 시스템 구성

  사람          "이 사진들로 배우 만들어줘"      → 작업 A
                "그 배우로 영상 5개 뽑아줘"       → 작업 B
    │
    ▼
  AI 에이전트    Claude Code / Codex — 지시 해석
    │  MCP 호출
    ▼
  유니핸즈       조작 인터페이스 · 상태 관리 · 결과 보고
    │  HTTP / CLI
    ▼
  실행 계층      [작업 A] 배우 만들기
                   배우 학습     Krea 2 + LoRA 학습 도구 → 배우 파일(.safetensors)

                 [작업 B] 배우로 영상 만들기
                   이미지 생성   ComfyUI + Krea 2 + 배우 → 기준 프레임
                   영상 생성     ComfyUI + LTX (2.5 기본 / 2.3 폴백) → 영상 + 오디오
    │
    ▼
  하드웨어       RTX 5090 (VRAM 32GB)

2. 두 가지 작업 — 배우 만들기, 배우로 영상 만들기

이 시스템이 다루는 작업은 둘이며, 서로 독립적으로 실행됩니다.

작업 A — 배우 만들기작업 B — 영상 만들기
입력인물 기준 이미지 15~30장배우 파일 + 지시
출력배우 파일 (.safetensors)영상
빈도배우 한 명당 1회 (필요 시 재학습)계속
소요수 시간분 단위
사람 개입채택 여부를 사람이 판정최소. 무인 실행 가능
실패 시설정을 바꿔 재학습지시를 바꿔 재생성

두 작업을 하나로 묶지 않습니다. 배우를 만들 때마다 영상을 뽑는 것이 아니고, 영상을 만들 때마다 학습을 다시 하는 것도 아닙니다. 배우는 한 번 만들어 두고, 이후 영상 작업에서 계속 불러 씁니다.

유니핸즈는 두 작업을 각각 수행할 수 있어야 합니다.

배우 파일이란

한 인물의 여러 각도·표정 이미지 15~30장으로 LoRA 를 학습하면, 그 인물의 정체성이 파일 하나(수십~수백 MB)에 담깁니다. 이후 프롬프트에 정해둔 트리거 단어를 넣으면 포즈·의상·배경·조명이 바뀌어도 동일 인물로 재현됩니다.

한 번 만든 배우는 이후 모든 영상에 다시 쓸 수 있습니다. 따라서 이 프로젝트에서 축적되는 것은 완성된 영상이 아니라 배우 파일과 그 제작 절차입니다.

배우 파일은 학습에 사용한 생성 모델 위에서만 동작합니다. 이 프로젝트는 Krea 2 를 사용하며, 선택 근거는 아래에 정리했습니다.

배우 파일 형식 — safetensors

배우 파일은 .safetensors 형식으로 저장합니다.

과거에는 .ckpt 형식을 썼으나, 이 형식은 데이터와 함께 실행 가능한 코드를 담을 수 있어 파일을 여는 것만으로 임의 코드가 실행될 위험이 있었습니다. .safetensors 는 순수 데이터만 담으므로 그 위험이 없고, 로딩도 빠릅니다.

.ckpt.safetensors
담기는 것데이터 + 실행 가능한 코드데이터만
위험파일을 여는 것만으로 코드 실행 가능없음

운영 원칙 — 외부에서 받은 모델·배우 파일은 .safetensors 만 취급합니다. 학습 데이터나 참고용으로 외부 모델을 들여올 일이 생기므로 이 기준을 미리 정해 둡니다.

배우 제작 절차

배우 한 명은 한 번의 학습으로 완성되지 않습니다. 설정을 바꿔가며 반복하고, 결과를 비교해 채택합니다.

순서내용
1기준 이미지 확보 — 각도·조명·표정을 달리한 15~30장, 1024×1024
2캡션 생성 — 트리거 단어를 일관되게 부여
3학습 — 설정을 바꿔 여러 회차 수행
4체크포인트 비교 — 회차별 결과를 대조해 채택본 선정
5검증 — 학습셋에 없는 포즈·조명에서 동일 인물이 유지되는지 확인
6등록 — 설정값·시드와 함께 배우 파일 기록

여기까지가 작업 A 입니다. 영상 생성은 별도 작업(B)이며, 등록된 배우를 불러 쓰는 것으로 시작합니다.

1번이 결과를 가장 크게 좌우합니다. 데이터셋 품질이 낮으면 학습 설정으로 만회할 수 없습니다. 같은 각도·같은 조명만 모으면 그 조건에서만 작동하는 배우가 나옵니다.

4번과 5번을 생략하면 배우가 완성된 것처럼 보이지만 실제 사용에서 무너집니다. 학습을 오래 할수록 좋아지는 것이 아니라, 어느 지점을 지나면 유연성을 잃습니다.

6번은 재현을 위한 것입니다. 설정을 남기지 않으면 잘 나온 배우를 다시 만들 수 없고, 개선하거나 같은 조건으로 다른 배우를 만드는 것도 불가능합니다. 배우가 자산이라면 그 제작 조건도 함께 자산입니다.

배우를 만드는 방식 — 이미지 학습으로 확정

배우를 만드는 방식은 두 가지가 가능합니다. 이미지로 학습하는 방식과, 영상 모델에 직접 학습하는 방식입니다. 이 프로젝트는 이미지 학습 방식을 사용합니다.

채택 — 이미지 학습기각 — 영상 모델 직접 학습
학습 대상Krea 2 (이미지 모델)Wan · Hunyuan · LTX 등 영상 모델
학습 데이터사진 15~30장영상 클립 12~20개 (각 4~8초)
학습 도구musubi-tunerdiffusion-pipe (별도 스택)
학습 VRAM12~16GBLTX 약 24GB · Wan/Hunyuan 32~48GB
영상 생성배우로 기준 프레임을 만든 뒤 영상 모델로 움직임 부여영상 모델이 직접 생성

영상 모델 직접 학습을 기각한 이유는 셋입니다.

첫째, 이 방식만 장비 요구가 다릅니다. 보유 장비(32GB)로 이미지 학습과 영상 생성은 여유 있게 수행할 수 있습니다. 그러나 Wan·Hunyuan 계열의 LoRA 학습은 32~48GB 를 요구해, 하한선에 걸치거나 미달합니다. 같은 장비로 영상 생성까지 해야 하므로 실제로는 더 빠듯합니다.

둘째, 학습 데이터의 성격이 다릅니다. 사진이 아니라 그 인물이 나오는 영상 클립이 필요합니다. 배우 한 명당 4~8초짜리 클립을 12~20개 확보해야 하므로, 준비 부담이 사진과 비교되지 않습니다.

셋째, 배우가 영상 모델에 묶입니다. 이미지 학습 방식에서는 영상 모델을 바꿔도 배우를 그대로 쓸 수 있지만, 직접 학습 방식에서는 영상 모델을 바꾸는 순간 배우를 다시 만들어야 합니다.

베이스 모델 — Krea 2 로 확정 (SDXL 폴백)

배우를 학습시킬 바탕 모델입니다. 인물의 사실성이 결과를 좌우하므로 이 선택이 중요합니다.

채택 — Krea 2폴백 — SDXL기각 — FLUX.1 [dev]
공개2026-0620232024
규모12.9B2.6B12B
인물 사실성상위. FLUX 1.1 Pro 와 대등하거나 앞섬2026년 기준 경쟁력 하락상위
텍스트 인코더Qwen3-VL. 사진 용어를 지시로 이해CLIP
5090 에서Turbo FP8 12GB · 풀 품질 BF16 도 상주 가능여유여유
생성 속도1024×1024 · 8스텝 · 5~6초빠름느림
ControlNetOpenPose · Depth 있음 (수동 설치)안정적불안정
LoRA 생태계두 달. 빠르게 축적 중가장 큼성장 중
상업 이용연 매출 100만 달러 미만 무료제약 없음불가

Krea 2 를 채택하는 근거

첫째, 인물 사실성이 가장 높습니다. 커뮤니티 비교에서 얼굴 디테일·눈 선명도·근접 피부 질감이 FLUX 1.1 Pro 와 대등하거나 앞선다는 평가입니다. 반면 SDXL 은 2023년 모델로, 2026년 기준 인물 사실성에서 경쟁력이 떨어집니다. 우리가 만드는 것이 사실적인 인물이므로 이 항목이 다른 요소보다 우선합니다.

둘째, 사진 용어를 이해합니다. 텍스트 인코더로 Qwen3-VL 을 사용해 조리개 같은 촬영 파라미터를 지시로 처리합니다. 원하는 화면을 말로 지정하기 쉬워집니다.

셋째, 5090 에 적합합니다. Turbo 를 FP8 로 올리면 12GB 를 쓰고 20GB 가 남으며, 풀 품질 BF16 도 32GB 안에 상주합니다. 16GB 카드에서는 양자화나 CPU 오프로드가 필요하지만 5090 에서는 그럴 필요가 없습니다. FP8 과 BF16 은 육안으로 구분되지 않는 수준입니다.

넷째, 포즈 제어가 가능합니다. OpenPose 와 Depth ControlNet 이 공개되어 있어 배우를 원하는 자세로 세울 수 있습니다.

SDXL 을 폴백으로 두는 이유

Krea 2 는 공개된 지 두 달로, 축적된 설정값과 노하우가 SDXL 에 미치지 못합니다. 또한 캐릭터 일관성에서 몸은 안정적이나 얼굴은 일부 생성에서 목표에서 벗어난다는 보고가 있습니다. 배우의 얼굴 일관성은 이 프로젝트의 핵심 지표이므로 초기 검증에서 우선 확인하며, 요구 수준에 못 미치면 SDXL 로 전환합니다.

ControlNet 이 아직 ComfyUI 관리 도구에 등록되지 않아 수동 설치가 필요한 점도 초기 부담입니다.

FLUX.1 을 기각한 이유

FLUX.1 [dev] 는 비상업 라이선스여서 수익이 발생하는 용도로 사용할 수 없습니다. 상업 이용이 자유로운 [schnell] 은 [dev] 를 경량화한 버전이라 품질이 낮아, Krea 2 대비 이점이 없습니다.

라이선스

모델상업 이용
Krea 2연 매출 100만 달러 미만 무료. 이상은 별도 계약
SDXL제약 없음
FLUX.1 [dev]불가

두 모델 모두 기준은 연 매출이며 인원수가 아닙니다.

라이선스 의무는 모델을 상업적으로 사용하는 주체, 즉 이 시스템으로 영상을 제작해 수익을 내는 사업체에 있습니다. 유니핸즈는 그 사업체가 사용하는 도구이며, 도구 제작자가 라이선스 주체가 되지 않습니다.

현재 규모에서는 무료 사용 범위 안이므로 별도 비용이 발생하지 않습니다. 매출이 기준을 넘어서는 시점에는 사업체 명의로 상업 라이선스를 확보하면 되며, 그 규모에 이르렀다면 라이선스 비용은 부담이 되지 않는 수준입니다.

이름 혼동 주의

Krea 2 는 2025년의 FLUX.1 Krea 협업 모델과 다릅니다. Krea 가 자체 개발해 2026년 6월 공개한 별도 모델입니다.

베이스 모델은 한 번 정하면 바꾸기 어렵다

LoRA 는 학습에 사용한 베이스 모델에서만 동작합니다. Krea 2 로 만든 배우는 SDXL 에서 동작하지 않으며, 그 반대도 마찬가지입니다.

배우 10명을 만든 뒤 베이스를 바꾸면
배우 10명을 전부 다시 학습해야 함
재학습해도 완전히 동일한 얼굴은 나오지 않음 (모델이 다르므로)
기존 영상과 새 영상의 인물이 미묘하게 달라짐

전환 비용이 그때까지 쌓인 배우 수에 비례합니다. 늦게 바꿀수록 비싸집니다. 이 프로젝트에서 축적되는 자산이 배우이므로, 베이스 모델 선택은 초기에 확정하는 것이 유리합니다.

영상 모델은 별개 층이다

베이스 모델과 영상 모델은 서로 다른 선택입니다.

배우 (이미지 베이스)    Krea 2                    자산이 여기 묶임
        │
        ▼ 기준 프레임
영상 모델               LTX                       교체 가능

경로 A 에서는 영상 모델이 배우를 알 필요가 없습니다. 완성된 기준 프레임만 받으면 되기 때문입니다. 따라서 영상 모델은 나중에 바꿔도 배우 자산이 유지됩니다.

경로 B(영상 모델에 직접 학습)를 택하면 배우가 영상 모델에도 묶이므로 교체가 훨씬 어려워집니다. 이 점도 경로 A 를 기본으로 두는 근거입니다.


3. 학습 — musubi-tuner

배우를 만드는 단계입니다. Krea 2 LoRA 학습은 여러 도구가 지원하며, 로컬 무인 실행에 적합한 것을 씁니다.

도구특징
musubi-tuner (kohya)기본. CLI · VRAM 최적화가 낫다는 보고 · 12GB 학습 가이드 존재
AI Toolkit (Ostris)대안. 2026-07-04 Krea 2 지원 추가 · 참조 이미지 학습 강점
Krea 내장 Train · Fal API클라우드. 로컬 실행 원칙에 맞지 않아 사용하지 않음

musubi-tuner 를 기본으로 둡니다. CLI 로 동작해 무인 실행에 적합하고, kohya 계열이므로 SDXL 로 폴백하더라도 같은 생태계 안에서 이동할 수 있습니다.

두 도구 모두 활성 지원 상태이므로, 초기 검증에서 실제 결과를 비교해 확정합니다.

데이터 준비

학습에는 이미지와 캡션(설명 텍스트) 쌍이 필요합니다. 캡션 생성은 WD14 Tagger v3 로 자동화하되, 학습 대상을 지칭하는 트리거 토큰은 일관되게 유지해야 합니다.

단계자동화 가능성
이미지 수집협의 필요 — 담당 주체에 따라 범위가 달라짐
태깅(캡션 생성)자동화 가능 (WD14 Tagger v3)
캡션 검수·보정부분 자동화. 품질 판단은 사람 개입 필요
학습 실행자동화 가능 (CLI)
결과 검증자동 생성 + 사람 확인

4. 생성 — ComfyUI

ComfyUI 는 로컬 이미지·영상 생성의 사실상 표준이며, HTTP·WebSocket API 를 제공합니다. 웹 화면 없이 외부 프로그램이 직접 작업을 넣고 결과를 가져올 수 있습니다.

사용하는 인터페이스

구분엔드포인트용도
실행POST /prompt워크플로우(JSON)를 큐에 등록
GET /queue · POST /interrupt대기열 확인 · 중단
이력GET /history완료된 작업과 결과 경로
파일POST /upload/image · GET /view입력 업로드 · 산출물 조회
상태GET /system_stats · GET /object_infoVRAM · 가용 노드 확인
실시간WebSocket진행률 · 프리뷰 · 큐 상태 스트림

기본 주소는 127.0.0.1:8188 이며, 큐는 FIFO 로 동작합니다.

이 구조가 갖는 의미

ComfyUI 의 워크플로우가 JSON 이라는 점이 핵심입니다. 화면을 조작하는 것이 아니라 데이터를 만들어 보내는 방식이므로 에이전트가 다룰 수 있습니다.

배우 적용도 워크플로우 안의 값입니다. 학습이 끝난 배우 파일의 경로와 트리거 단어를 템플릿에 넣으면 그대로 반영되므로, 어떤 배우를 출연시킬지 바꾸는 일이 값 하나를 교체하는 것으로 끝납니다.


5. 영상 모델 — LTX 계열로 확정

2026년 8월 기준 오픈 모델 세 종을 5090(32GB) 기준으로 검토했습니다.

채택 — LTX기각 — Wan 2.2 14B기각 — HunyuanVideo 1.5
규모22B14B8.3B
32GB 에서양자화 없이 동작 (24.2GB)풀 품질 80GB+ · GGUF 양자화 필수오프로딩 시 14GB
ComfyUI퍼스트파티 통합 · 공식 템플릿레퍼런스 워크플로우 제공별도 구성
오디오영상과 동시 생성없음없음
상업 이용연 매출 1,000만 달러 미만 무료
품질세 모델 중 상위시간적 일관성 우수 (풀 품질 기준)LTX 대비 한 단계 아래

LTX 를 채택하는 근거

첫째, 오디오를 영상과 함께 생성합니다. 비대칭 듀얼 스트림 구조로 영상(14B)과 오디오(5B)를 한 번의 처리에서 만들어 내며, 대사가 있으면 입 모양이 맞고 장면에 맞는 배경음·효과음이 함께 나옵니다. 오디오를 따로 제작해 붙이는 공정이 사라집니다. 오픈 모델 중 이 기능을 갖춘 것은 LTX 계열뿐입니다.

둘째, ComfyUI 에 퍼스트파티로 통합되어 공식 워크플로우 템플릿을 제공합니다. 자동화가 워크플로우 JSON 을 다루는 방식이므로, 이 통합 수준이 작업량을 크게 좌우합니다.

셋째, 5090 에서 양자화 없이 동작합니다. 4초 클립 기준 VRAM 24.2GB 로 여유가 남고, 양자화를 거치지 않으므로 설정이 단순하고 품질 손실이 없습니다.

넷째, 상업 이용 조건이 명확합니다. 연 반복매출 1,000만 달러 미만 기업은 상업적으로 무료 사용할 수 있어, 별도 라이선스 비용이 발생하지 않습니다.

버전 정책 — LTX-2.5 기본, LTX-2.3 폴백

버전시점비고
LTX-2.52026-08최신. 멀티샷 씬 · 오토 듀레이션 · 4K HDR. ComfyUI 공식 템플릿 출시 당일 제공
LTX-2.32026-035090 실측 벤치마크 공개. 검증 기간이 더 김

최신인 2.5 를 기본으로 사용하되, 문제가 발생하면 2.3 으로 내려갑니다. 2.5 는 공개된 지 한 달이 되지 않아 실사용 검증이 부족할 수 있고, 2.3 은 다섯 달간 사용되며 5090 기준 실측 자료가 축적되어 있습니다.

같은 계열이므로 전환 비용이 거의 없습니다. 워크플로우 구조가 동일하고 모델 파일만 교체하면 됩니다.

기각 근거

Wan 2.2 는 풀 품질에 80GB 이상을 요구해 5090 에서는 GGUF 양자화가 필수입니다. 그런데 Wan 의 장점이 풀 품질에서의 시간적 일관성이므로, 양자화를 거치면 채택 이유가 사라집니다.

HunyuanVideo 는 요구 사양이 가장 낮아 오프로딩 시 14GB 로 동작합니다. 그러나 우리는 VRAM 이 부족한 상황이 아니므로 이 장점이 의미가 없고, 품질은 LTX 보다 낮습니다. 장점은 필요 없고 단점만 남는 조합입니다.

두 모델 모두 오디오 생성 기능이 없어, 채택 시 오디오 공정이 별도로 필요합니다.

재검토 조건

LTX 의 결과물이 요구 품질에 못 미칠 때입니다. 실제 결과물 품질은 아직 실측하지 않았으므로 초기 검증 항목에 포함되어 있습니다. 영상 모델은 배우 자산과 분리되어 있어, 교체하더라도 이미 만든 배우는 그대로 사용할 수 있습니다.

하드웨어 실측치 — RTX 5090 (32GB)

배우 학습 · 이미지 생성 (Krea 2)

항목수치
LoRA 학습 VRAM최적화 시 약 10.5GB (12GB GPU 에서 검증)
Turbo 생성 (FP8)12.01GB 점유 · 5090 에 약 20GB 여유
풀 품질 Raw (BF16)32GB 에 상주 가능
생성 속도1024×1024 · 8스텝 · 5~6초
FP8 vs BF16육안으로 구분되지 않는 수준

16GB 카드에서는 양자화나 CPU 오프로드가 필요하지만, 5090 에서는 두 체크포인트를 모두 여유 있게 운용할 수 있습니다.

영상 생성 (LTX-2.3 실측 기준)

조건생성 시간VRAM
768×512 · 4초약 40초24.2GB
1280×704 · 4초약 50초24.2GB
720p · 4초약 25초32GB 이내
720p · 8초약 3분32GB 초과

4초 클립까지는 양자화 없이 32GB 안에서 처리되며 여유가 남습니다.

이 수치가 뜻하는 것

장비의 한계는 용량 자체가 아니라 클립 길이에 있습니다.

720p 기준으로 4초는 약 25초 만에 나오지만, 8초는 약 3분이 걸립니다. 길이가 두 배인데 시간이 일곱 배가 되는 이유는, 작업이 32GB 안에 들어가지 못해 가중치를 시스템 메모리와 주고받기 때문입니다.

따라서 짧은 클립을 여러 개 만들어 이어 붙이는 방식은 무리가 없고, 긴 영상을 한 번에 생성하려 하면 급격히 느려집니다. 필요한 영상 길이가 정해지면 그에 맞춰 모델과 설정을 정합니다.


6. 조작 계층 — 유니핸즈 MCP

MCP(Model Context Protocol)는 AI 에이전트가 외부 도구를 호출하는 표준 규약입니다. 유니핸즈를 MCP 서버로 노출하면, Claude Code·Codex 가 아래 기능을 직접 호출할 수 있습니다.

작업도구 (예정)하는 일
A학습 실행학습 도구 호출, 로그·진척 수집
A학습 상태 조회진행률 · 회차별 체크포인트
A배우 등록채택본을 설정값·시드와 함께 기록
A배우 목록 조회사용 가능한 배우와 트리거 단어
B워크플로우 실행ComfyUI /prompt 호출, 작업 ID 반환
B생성 상태 조회큐 · 진행률 · 완료 여부
B산출물 조회생성된 파일 목록과 경로
공통예약 등록지정 시각·조건에 작업 등록
공통이력 조회어떤 배우·설정으로 무엇을 만들었는지

에이전트가 셸 명령을 직접 만들어 실행하는 방식은 쓰지 않습니다. 정의된 도구만 호출하게 하면 결과가 일정하고, 위험한 명령이 생성될 경로가 차단됩니다.


7. 무인 실행 계층 — 헤르메스

예약된 시각에 사람 없이 작업을 수행하는 부분은 헤르메스가 담당합니다. 스케줄러·상주 프로세스·알림 채널을 직접 구현하지 않고 기존 인프라를 사용합니다.

담당내용
예약 실행지정 시각에 지시문과 함께 에이전트 기동
상주사람이 없는 시간대의 작업 처리
알림완료·실패를 지정 채널로 전달

의존 표면은 파일 규격·엔드포인트·CLI 플래그 목록으로 문서화하며, 헤르메스가 갱신될 때 이 목록만 검증합니다.


8. 실행 흐름

두 작업은 따로 실행됩니다. 배우를 만드는 흐름과, 만들어진 배우로 영상을 만드는 흐름입니다.

작업 A — 배우 만들기

"이 사진들로 배우 만들어줘"

순서주체동작
1에이전트지시를 작업 단위로 분해
2유니핸즈데이터셋 경로 확인 · 태깅 실행(WD14)
3유니핸즈학습 실행. 설정을 바꿔 여러 회차
4유니핸즈회차별 체크포인트로 시험 생성, 결과 정리
5사람결과를 보고 채택본 판정
6유니핸즈채택본을 설정값·시드와 함께 배우로 등록

5번에 사람이 들어갑니다. 배우의 완성도는 사람이 보고 판단해야 하므로 이 단계는 무인화하지 않습니다. 자동화의 역할은 사람이 판단할 재료를 정리해 주는 데까지입니다.

작업 B — 배우로 영상 만들기

"그 배우로 영상 5개 뽑아서 알려줘"

순서주체동작
1에이전트지시 해석 · 사용할 배우 확인
2유니핸즈배우 파일 경로와 트리거 단어를 워크플로우에 반영
3유니핸즈ComfyUI POST /prompt — 기준 프레임 생성
4유니핸즈기준 프레임으로 영상 생성
5유니핸즈WebSocket 으로 진행률 추적
6유니핸즈산출물 경로 수집 · 사용한 배우·설정과 함께 기록
7헤르메스완료 알림 발송

B 는 사람 개입 없이 실행됩니다. 예약을 걸어 두면 지정 시각에 그대로 수행됩니다.

중간에 실패하면 해당 단계에서 중단하고 원인과 함께 알립니다. 실패가 조용히 넘어가지 않도록 각 단계에 결과 확인을 둡니다.


9. 검증이 필요한 기술 항목

착수 초기에 확인해야 하는 항목입니다. 결과에 따라 구성이 달라집니다.

#항목확인할 것
1Krea 2 얼굴 일관성배우의 얼굴이 여러 생성·영상에 걸쳐 유지되는가. 몸은 안정적이나 얼굴은 편차 보고가 있음. 미달 시 SDXL 폴백
2LTX 결과물 품질요구 수준을 충족하는가. 2.5 와 2.3 중 어느 쪽이 안정적인지 확인
3장시간 작업 안정성수 시간 학습 중 VRAM 누수·중단 여부
4학습 도구 선정musubi-tuner 와 AI Toolkit 중 결과·안정성 비교. 캡션 검수 자동화 범위 확인
5ComfyUI 워크플로우 템플릿화값만 바꿔 재사용 가능한 구조로 정리 가능한가
6윈도우 환경운영체제는 윈도우로 확정. 유니핸즈·헤르메스의 윈도우 동작이 미검증이므로 우선 확인
7결과 재현성같은 배우·설정으로 같은 결과가 나오는가

1번과 6번이 가장 불확실하므로 먼저 확인합니다. 1번은 이 연구의 성립 여부와 직결되고, 6번은 시스템 구성 전체에 영향을 줍니다. 불확실한 항목을 뒤로 미루면 후반에 전체 구성을 바꿔야 하는 상황이 생깁니다.


10. 전제

환경

항목내용
GPURTX 5090 (VRAM 32GB)
운영체제윈도우 (RTX 5090 사용에 따라 확정)
가동무인 실행을 위해 상시 전원 유지
저장공간모델·데이터셋·산출물 누적. 용량 산정 필요
네트워크알림 발송용

역할

항목담당
학습 자료 준비협의 필요 — 자동화 범위가 여기서 갈림
학습 자료의 권리아래 참조. 상업 이용 전 확인 필요
모델 라이선스아래 참조. 사업체 명의로 확인이 필요합니다
결과물 품질 판단영상 담당
시스템 구축·운영유니 스튜디오

11. 이 연구가 다루지 않는 것

모델 개발공개된 모델을 활용하며, 새 모델을 만들지 않음
결과물의 완성도 보장도구를 만드는 것이며, 산출물의 품질을 약속하지 않음
클라우드 전환로컬 장비 기준. 클라우드 확장은 별도 판단
상용 서비스 구축연구 단계이며, 제품화는 별도 판단

12. 다음 절차

순서내용
19장 항목 중 1·6번 우선 검증
2검증 결과로 2번 문서(범위와 산출물) 작성
33번 문서(단계별 계획) 작성
4착수

본 문서는 기술 구성에 대한 것이며, 범위·일정·성과를 확약하지 않습니다.