연구개발 추진 방안
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-tuner | diffusion-pipe (별도 스택) |
| 학습 VRAM | 12~16GB | LTX 약 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-06 | 2023 | 2024 |
| 규모 | 12.9B | 2.6B | 12B |
| 인물 사실성 | 상위. FLUX 1.1 Pro 와 대등하거나 앞섬 | 2026년 기준 경쟁력 하락 | 상위 |
| 텍스트 인코더 | Qwen3-VL. 사진 용어를 지시로 이해 | CLIP | — |
| 5090 에서 | Turbo FP8 12GB · 풀 품질 BF16 도 상주 가능 | 여유 | 여유 |
| 생성 속도 | 1024×1024 · 8스텝 · 5~6초 | 빠름 | 느림 |
| ControlNet | OpenPose · 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_info | VRAM · 가용 노드 확인 |
| 실시간 | WebSocket | 진행률 · 프리뷰 · 큐 상태 스트림 |
기본 주소는 127.0.0.1:8188 이며, 큐는 FIFO 로 동작합니다.
이 구조가 갖는 의미
ComfyUI 의 워크플로우가 JSON 이라는 점이 핵심입니다. 화면을 조작하는 것이 아니라 데이터를 만들어 보내는 방식이므로 에이전트가 다룰 수 있습니다.
배우 적용도 워크플로우 안의 값입니다. 학습이 끝난 배우 파일의 경로와 트리거 단어를 템플릿에 넣으면 그대로 반영되므로, 어떤 배우를 출연시킬지 바꾸는 일이 값 하나를 교체하는 것으로 끝납니다.
5. 영상 모델 — LTX 계열로 확정
2026년 8월 기준 오픈 모델 세 종을 5090(32GB) 기준으로 검토했습니다.
| 채택 — LTX | 기각 — Wan 2.2 14B | 기각 — HunyuanVideo 1.5 | |
|---|---|---|---|
| 규모 | 22B | 14B | 8.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.5 | 2026-08 | 최신. 멀티샷 씬 · 오토 듀레이션 · 4K HDR. ComfyUI 공식 템플릿 출시 당일 제공 |
| LTX-2.3 | 2026-03 | 5090 실측 벤치마크 공개. 검증 기간이 더 김 |
최신인 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. 검증이 필요한 기술 항목
착수 초기에 확인해야 하는 항목입니다. 결과에 따라 구성이 달라집니다.
| # | 항목 | 확인할 것 |
|---|---|---|
| 1 | Krea 2 얼굴 일관성 | 배우의 얼굴이 여러 생성·영상에 걸쳐 유지되는가. 몸은 안정적이나 얼굴은 편차 보고가 있음. 미달 시 SDXL 폴백 |
| 2 | LTX 결과물 품질 | 요구 수준을 충족하는가. 2.5 와 2.3 중 어느 쪽이 안정적인지 확인 |
| 3 | 장시간 작업 안정성 | 수 시간 학습 중 VRAM 누수·중단 여부 |
| 4 | 학습 도구 선정 | musubi-tuner 와 AI Toolkit 중 결과·안정성 비교. 캡션 검수 자동화 범위 확인 |
| 5 | ComfyUI 워크플로우 템플릿화 | 값만 바꿔 재사용 가능한 구조로 정리 가능한가 |
| 6 | 윈도우 환경 | 운영체제는 윈도우로 확정. 유니핸즈·헤르메스의 윈도우 동작이 미검증이므로 우선 확인 |
| 7 | 결과 재현성 | 같은 배우·설정으로 같은 결과가 나오는가 |
1번과 6번이 가장 불확실하므로 먼저 확인합니다. 1번은 이 연구의 성립 여부와 직결되고, 6번은 시스템 구성 전체에 영향을 줍니다. 불확실한 항목을 뒤로 미루면 후반에 전체 구성을 바꿔야 하는 상황이 생깁니다.
10. 전제
환경
| 항목 | 내용 |
|---|---|
| GPU | RTX 5090 (VRAM 32GB) |
| 운영체제 | 윈도우 (RTX 5090 사용에 따라 확정) |
| 가동 | 무인 실행을 위해 상시 전원 유지 |
| 저장공간 | 모델·데이터셋·산출물 누적. 용량 산정 필요 |
| 네트워크 | 알림 발송용 |
역할
| 항목 | 담당 |
|---|---|
| 학습 자료 준비 | 협의 필요 — 자동화 범위가 여기서 갈림 |
| 학습 자료의 권리 | 아래 참조. 상업 이용 전 확인 필요 |
| 모델 라이선스 | 아래 참조. 사업체 명의로 확인이 필요합니다 |
| 결과물 품질 판단 | 영상 담당 |
| 시스템 구축·운영 | 유니 스튜디오 |
11. 이 연구가 다루지 않는 것
| 모델 개발 | 공개된 모델을 활용하며, 새 모델을 만들지 않음 |
| 결과물의 완성도 보장 | 도구를 만드는 것이며, 산출물의 품질을 약속하지 않음 |
| 클라우드 전환 | 로컬 장비 기준. 클라우드 확장은 별도 판단 |
| 상용 서비스 구축 | 연구 단계이며, 제품화는 별도 판단 |
12. 다음 절차
| 순서 | 내용 |
|---|---|
| 1 | 9장 항목 중 1·6번 우선 검증 |
| 2 | 검증 결과로 2번 문서(범위와 산출물) 작성 |
| 3 | 3번 문서(단계별 계획) 작성 |
| 4 | 착수 |
본 문서는 기술 구성에 대한 것이며, 범위·일정·성과를 확약하지 않습니다.