ComfyUI 활용사례 조사 및 Son님 환경 맞춤 사용 가이드

조사·점검일: 2026-07-28
대상 환경: Windows 10 · NVIDIA GeForce RTX 5070 Ti 16GB · ComfyUI Desktop · FLUX.2 [klein] 4B FP8
결론: 지금은 모델을 더 모을 때가 아니라, 한 개의 빠른 모델로 반복 가능한 제작 파이프라인을 만드는 단계다.

0. 한눈에 보는 결론

ComfyUI는 단순한 “그림 생성 UI”가 아니다. 모델 로더, 텍스트·이미지 조건, 샘플러, 디코더, 저장 노드를 그래프로 연결해 생성·편집·후처리·검증·배치 실행을 재현 가능한 워크플로로 고정하는 도구다. 같은 그래프와 모델, 파라미터, seed를 보존하면 결과를 다시 만들거나 특정 변수만 바꾸어 비교할 수 있다. 이 점이 대화형 이미지 생성 서비스와 가장 크게 다르다.

Son님 PC는 RTX 5070 Ti 16GB이고, 실제 ComfyUI 로그에서 CUDA 장치·DynamicVRAM·비동기 weight offloading이 정상 활성화됐다. 설치된 FLUX.2 Klein 4B FP8은 공식 문서상 빠른 4-step distilled 계열이며, 로컬 로그에서도 1024급 작업이 첫 실행 약 13초, 워밍 이후 약 6초 전후로 완료됐다. 따라서 가장 높은 효율을 내는 순서는 다음과 같다.

같은 프롬프트의 seed·구도·비율 변형을 빠르게 생성한다.
선택한 시안을 FLUX.2 Klein 이미지 편집 워크플로로 수정한다.
배경 제거·크롭·보수적 업스케일을 붙여 실제 에셋 후보로 만든다.
프롬프트·seed·모델·워크플로 JSON을 함께 기록한다.
반복량이 생기면 API 형식으로 내보내 Hermes나 스크립트에서 배치 실행한다.

반대로 지금 당장 수십 개의 체크포인트와 커스텀 노드를 설치하는 것은 권장하지 않는다. 현재 설치에는 사실상 기본 노드만 있고, 이것은 약점이 아니라 안정적인 기준선이다. 하나의 산출물 유형에서 병목이 확인될 때만 필요한 노드와 모델을 추가하는 편이 업데이트·보안·재현성 측면에서 안전하다.

1. 실제 환경 점검 결과

하드웨어와 런타임

항목	확인값	해석
GPU	NVIDIA GeForce RTX 5070 Ti	로컬 이미지 생성에 충분
VRAM	16,303 MiB	FLUX.2 Klein 4B와 중간급 보조 워크플로에 적합
RAM	약 31.6GB	로그 기준 async offloading 운용 가능
ComfyUI	로그상 0.28.3	2026-07-27 실행 이력 기준
PyTorch/CUDA	2.10.0 + cu130	RTX 50 계열 환경에서 CUDA 인식 완료
VRAM 모드	NORMAL_VRAM + DynamicVRAM	필요 시 CPU offload와 동적 적재 사용
현재 서버	127.0.0.1:8188 미응답	조사 시점에는 ComfyUI가 종료된 상태

설치된 모델

ComfyUI-Shared/models/
├─ diffusion_models/flux-2-klein-4b-fp8.safetensors
├─ text_encoders/qwen_3_4b.safetensors
└─ vae/flux2-vae.safetensors

세 파일은 공식 FLUX.2 Klein 4B distilled 워크플로의 정확한 구성과 일치한다. Base 모델은 설치되어 있지 않다. 따라서 현재 강점은 빠른 4-step 생성과 편집이고, 본격 파인튜닝 유연성은 Base 모델을 나중에 별도 도입할 때 고려하면 된다.

실제 실행 기록

로컬 로그에는 다음이 확인됐다.

4-step 샘플링 정상 완료
첫 실행 약 13.18초
워밍 이후 반복 실행 약 6.05~6.39초
텍스트 인코더 약 7.7GB staged, diffusion model 약 3.9GB staged, VAE 약 160MB staged
일부 실패는 OOM이 아니라 SaveImage 또는 ImageScaleToTotalPixels의 필수 입력 미연결 때문

즉, 현재 문제의 중심은 성능 부족이 아니라 그래프 연결과 출력 노드 검증이다. 에러 메시지에 Required input is missing이 나오면 모델을 다시 설치할 것이 아니라 빨간색으로 표시된 입력 소켓과 Save 노드까지 이어지는 경로를 먼저 본다.

2. ComfyUI를 이해하는 가장 짧은 모델

기본 생성 그래프는 아래 여섯 단계로 이해하면 된다.

모델 로드 → 프롬프트 인코딩 → 초기 latent/입력 이미지 → 샘플링 → VAE 디코드 → 저장

모델 로더: 어떤 생성 능력을 사용할지 결정한다.
텍스트 인코더: 프롬프트를 모델이 읽는 조건으로 바꾼다.
latent 또는 입력 이미지: 생성의 출발점과 해상도를 정한다.
sampler/scheduler: 노이즈에서 결과로 가는 계산 경로를 정한다.
VAE: latent를 사람이 보는 이미지로 디코드한다.
SaveImage: 실행 가능한 출력 종착점이다.

중요한 운영 규칙은 하나다. 실행은 출력 노드에서 거꾸로 필요한 노드만 계산한다. 따라서 연결되지 않은 미리보기나 저장 노드는 실행되지 않고, 출력 노드 자체에 필수 입력이 없으면 전체 prompt가 검증 단계에서 거부된다.

3. 활용사례 지도

활용 영역	실제로 유용한 일	대표 그래프	Son님 환경 우선순위	주의점
Text-to-Image	콘셉트, 배경, 소품, 카드뉴스 시안	Prompt → FLUX.2 Klein → Save	S	한 번의 정답보다 4~8개 변형 비교
Image Edit	오브젝트 교체·삭제, 스타일 수정, 다중 레퍼런스 합성	Load Image + edit prompt → Klein Edit	S	원본 보존용 복사본과 편집 이력 유지
Img2Img	스케치·사진의 스타일 변환, 색감·재질 탐색	Image → VAE Encode → KSampler	A	`denoise`가 원본 보존/변형의 핵심
Inpaint/Outpaint	손·얼굴·소품 부분 수정, 화면 확장	Image + Mask → Inpaint → Composite	A	마스크 경계와 원본 구조 QA 필요
캐릭터 시트	정면/측면/표정·의상 후보 탐색	reference/edit + batch	A	“같아 보임”과 제작 일관성은 다름
ControlNet	포즈·윤곽·깊이·구도 고정	Preprocessor → ControlNet → Sampler	B	모델 호환성과 별도 전처리 노드 필요
LoRA	스타일·캐릭터·오브젝트 편향 추가	Model → Load LoRA → Sampler	B	기반 모델 계열이 맞아야 함
IPAdapter류	한 장의 스타일·주체 참조	Image encoder + adapter conditioning	C	대표 구현이 maintenance-only 상태임
배경 제거/세그먼트	투명 PNG, 합성용 마스크	Image → segmentation → alpha output	A	가장자리·반투명 머리카락 수동 QA
업스케일	납품 해상도, 크롭 여유, 픽셀 보정	Image → conservative upscale → Save	A	창의적 업스케일은 디테일을 발명함
영상	T2V/I2V, 루프·트레일러 시안	Prompt/Image → video model → Video Save	C	디스크·시간·VRAM 비용이 급증
오디오	BGM·효과 후보, audio-to-audio 변형	tags/lyrics/audio → ACE-Step → SaveAudio	C	별도 음악 제작·권리·루프 QA 필요
3D	이미지 기반 메시 초안·프록시	Multi-view image → 3D model → GLB	C	토폴로지·UV·재질·충돌체 후처리 필요
API 자동화	다량 변형, 파라미터 sweep, 에셋 팩 생성	API JSON → `/prompt` → history/view	S	API 형식과 UI 저장 형식은 다름

3.1 게임 아트에서 가장 현실적인 사용법

ComfyUI가 특히 잘하는 것은 “최종 에셋 자동 완성”보다 탐색 공간을 빠르게 넓히고, 선택된 방향을 일관된 파이프라인으로 정리하는 일이다.

캐릭터: 실루엣·복장·표정·색상 후보 → 사람이 기준 시트 선택 → 편집 모델로 변형 → 수동 드로오버
배경: 분위기·광원·시간대 후보 → 원근과 플레이 공간 검토 → 레이어 분리·인페인트 → 엔진 카메라에서 검증
소품: 동일 재질·팔레트의 여러 후보 → 배경 제거 → 규격 크롭 → 보수적 업스케일 → 실제 UI/맵에서 크기 검증
마케팅: 키비주얼 후보 → 안전한 문구 영역 확보 → 텍스트는 디자인 도구에서 최종 조판 → 플랫폼별 크롭 QA
애니메이션 시안: key frame·포즈·루프 분위기 탐색 → 정식 타이밍·hitbox·root motion은 엔진/애니메이터가 확정

생성 이미지가 아름답다는 이유만으로 게임 에셋이 되는 것은 아니다. 투명 배경, 동일한 카메라, 정확한 발 접지, 방향별 실루엣, 픽셀 밀도, 엔진 임포트, 모바일 가독성까지 통과해야 한다.

4. Son님이 지금 바로 쓰는 첫 워크플로

방법 A — 공식 템플릿에서 시작

Comfy Desktop을 실행한다.
사이드바 Templates 또는 Workflow → Browse Workflow Templates를 연다.
Flux.2 Klein을 검색한다.
Text to Image (Flux.2 Klein 4B) 템플릿을 연다.
distilled 경로에서 다음 파일을 선택한다. - flux-2-klein-4b-fp8.safetensors - qwen_3_4b.safetensors - flux2-vae.safetensors
해상도는 먼저 1024×1024, batch 1로 둔다.
프롬프트를 바꾸고 Ctrl + Enter로 실행한다.
seed를 고정한 버전과 랜덤화한 버전을 각각 저장한다.

공식 템플릿은 필요한 모델 파일명과 다운로드 위치를 내장할 수 있다. Desktop은 누락 모델을 감지해 다운로드 UI를 제공한다. 단, 현재 누락 감지는 해당 모델 폴더의 최상위 파일명을 기준으로 하므로 임의의 하위 폴더로 옮겼다면 팝업이 잘못 뜰 수 있다.

첫 실험용 프롬프트 구조

[주체], [행동/자세], [환경], [구도/카메라], [광원], [재질/색상], [스타일], [금지할 혼동을 줄이는 명확한 문장]

예:

small brass mechanical fox mascot, standing three-quarter view on a clean workshop table,
full body visible, warm rim light and soft overhead fill, readable silhouette,
aged brass with teal enamel accents, handcrafted game concept art,
plain uncluttered background, no text, no watermark

FLUX.2 Klein처럼 최신 문장 이해력이 좋은 모델에는 태그를 무작정 쌓기보다 누가·어디서·무엇을·어떤 카메라와 빛으로 보여야 하는지를 문장으로 명확히 적는 편이 관리하기 쉽다.

seed를 다루는 법

고정 seed: 프롬프트 한 부분만 바꿀 때 효과 비교
랜덤 seed: 넓은 시안 탐색
기록 seed: 채택 후보를 재현하고 후속 편집

좋은 결과가 나왔는데 seed와 workflow를 잃으면, 그 결과는 파이프라인 자산이 아니라 우연한 스크린샷이다.

5. 핵심 파라미터의 실전 의미

steps

노이즈 제거 반복 횟수다. 일반 diffusion 모델은 늘리면 계산량이 증가하지만, distilled 4-step 모델은 공식 워크플로의 적은 step을 유지하는 것이 먼저다. 무조건 20~30으로 올린다고 품질이 좋아지지 않는다. 모델 유형별 공식 템플릿을 기준선으로 삼는다.

CFG / guidance

텍스트 조건을 얼마나 강하게 따를지 정한다. 값이 높을수록 “말을 잘 듣는 것처럼” 보일 수 있지만 색 과포화·질감 경직·깨짐이 생길 수 있다. distilled Flux 계열은 전통적인 SD1.5 튜토리얼 수치를 복사하지 말고 해당 템플릿의 guidance 방식을 따른다.

sampler / scheduler

노이즈에서 이미지로 가는 수치적 경로다. 이것만 바꿔도 질감과 안정성이 달라진다. 하지만 초반에는 공식 설정을 고정하고 prompt·seed·해상도 중 하나만 바꾸는 비교가 더 유용하다.

denoise

img2img와 audio-to-audio에서 원본을 얼마나 보존할지 결정한다.

낮음: 원본 구조·색·구도를 더 많이 보존
높음: 더 큰 변형
1.0: 원본 특성이 거의 사라져 text-to-image에 가까워질 수 있음

실전에서는 0.25 / 0.45 / 0.65 같은 세 점을 비교하고, 채택 구간만 더 세밀하게 탐색한다.

해상도와 batch

해상도와 batch는 VRAM과 시간을 크게 늘린다. 16GB라도 “큰 해상도 × batch 여러 장 × 여러 조건 모델”을 한 번에 겹치면 OOM 가능성이 있다. 먼저 batch 1로 워크플로를 검증하고, 다량 변형은 ComfyUI queue 또는 API에서 순차 실행한다.

6. 편집·제어 워크플로를 늘리는 순서

1단계: FLUX.2 Klein Image Edit

현재 모델군의 장점을 가장 빨리 확장한다. 공식 템플릿의 distilled image-edit 워크플로를 열고 입력 이미지를 넣은 뒤, “무엇을 유지하고 무엇만 바꿀지”를 명시한다.

Keep the character silhouette, camera angle, and brass material unchanged.
Replace only the teal scarf with a short crimson pilot scarf.
Preserve the plain background and lighting direction.

전체 재생성보다 부분 변경 요청을 명시적으로 분리하는 것이 좋다. 편집 결과는 구조·로고·손·텍스트·얼굴을 확대 검토한다.

2단계: Inpaint와 마스크

부분 수정은 마스크를 함께 사용하면 편집 범위를 좁힐 수 있다. 마스크가 너무 딱 맞으면 경계가 보이고, 너무 넓으면 주변 구조가 흔들린다. 경계 여유를 주고 feather 또는 후속 합성을 쓴다.

3단계: 배경 제거와 보수적 업스케일

생성 → 수정 → 배경 제거 → 크롭 → 업스케일 → 규격 저장 순으로 둔다. 공식 업스케일 가이드도 생성 결과의 해부학적 오류나 아티팩트를 업스케일러가 알아서 고칠 것이라 기대하지 말라고 경고한다. 먼저 편집 단계에서 오류를 해결한 후 키운다.

보수적 업스케일: 형태와 라벨을 보존해야 하는 UI·소품·제품형 이미지
창의적 업스케일: 환경·일러스트에 세부를 더할 때 후보용

4단계: ControlNet

포즈·윤곽·깊이·스크리블을 고정해야 할 때 추가한다. ControlNet은 reference image를 pose/depth/canny/scribble 같은 조건 맵으로 전처리한 뒤 sampling condition에 연결한다. strength, start_percent, end_percent로 영향 범위를 조절할 수 있다.

다만 현재 설치에는 ControlNet 보조 전처리 커스텀 노드가 없다. “포즈 고정이 실제 병목”이라는 증거가 생긴 뒤 comfyui_controlnet_aux 같은 검증된 노드를 Manager로 설치하고 snapshot을 남기는 편이 안전하다.

5단계: LoRA·IPAdapter류

LoRA는 스타일이나 특정 주체 편향을 base model에 덧붙인다. 모델 계열 호환성이 핵심이며, strength_model과 strength_clip을 조절한다. IPAdapter류는 한 장의 이미지에서 주체·스타일 조건을 가져오는 데 유용하지만, 널리 쓰인 ComfyUI_IPAdapter_plus 저장소는 2025-04부터 maintenance-only라고 명시한다. 새 워크플로의 핵심 의존성으로 고정하기 전 업데이트 상태와 모델 호환성을 검증해야 한다.

7. 영상·오디오·3D는 어디까지 가능한가

영상

공식 문서와 템플릿은 Wan·LTX 등 text-to-video, image-to-video, first/last-frame, pose/depth/canny 조건, frame interpolation, video upscale·inpaint를 제공한다. Wan2.1 1.3B는 공식 문서상 8GB VRAM부터 실행 가능한 경량 경로가 있지만, 고해상도 14B I2V는 저장공간·대기시간·VRAM 요구가 훨씬 크다.

Son님 환경에서 영상은 가능하지만 정지 이미지 파이프라인이 안정된 뒤 480p·짧은 클립·batch 1로 검증하는 것이 맞다. 첫 목표는 완성 트레일러가 아니라 “한 장의 채택 시안을 2~4초 움직여 연출 가능성을 확인”하는 것이다.

오디오

ComfyUI는 ACE-Step 등으로 text-to-music, audio-to-audio, 가사·태그 기반 생성과 SaveAudio 출력을 구성할 수 있다. 그러나 생성된 곡은 자동으로 게임 루프, stem, BPM 전환, 저작권·유사성 검토를 통과하지 않는다. 후보 생성 후 DAW에서 편집하고 엔진 전환 지점과 loudness를 별도로 검증해야 한다.

3D

Hunyuan3D 계열에는 이미지→geometry와 GLB 출력 워크플로가 있지만, 현재 Tencent Hunyuan 3D 2.0/2.1 Community License는 South Korea를 허가 Territory에서 제외한다. 라이선스는 Territory 밖에서 Works뿐 아니라 Output·결과의 사용도 unlicensed/unauthorized로 명시하므로, 한국에서는 Tencent의 별도 서면 허가 또는 한국 적용이 명확한 별도 서비스 약관을 확보하기 전까지 로컬·Cloud 제작 경로 모두 보류한다.

기술 수치도 출처가 일치하지 않는다. Hunyuan3D-2 공식 저장소는 shape 6GB, shape+texture 전체 16GB라고 하고 ComfyUI 문서는 mini 5GB, standard shape 6GB, 전체 12GB라고 적는다. Hunyuan3D-2.1 공식 저장소는 shape 10GB, texture 21GB, 전체 29GB를 요구한다. 따라서 16GB에서 전체 texture 경로가 안전하다고 단정하지 않는다. ComfyUI 코어는 현재 Hunyuan shape/GLB까지만 지원하고 texture/material은 지원하지 않는다.

8. 큐와 API 자동화

UI Queue

ComfyUI는 실행 요청을 queue에 넣는다. 클라이언트는 queue 시점의 전체 workflow와 widget 값을 서버로 전송하며, 제출 뒤 UI에서 바꾼 값은 이미 들어간 요청에 반영되지 않는다. 따라서 실험 이름과 seed를 출력 filename prefix에 넣으면 비교가 쉬워진다.

권장 출력 이름:

project_asset_stage_seed
fox_mascot_colorpass_184203
room_bg_lightingB_92210

API 형식

일반 Save JSON과 Export Workflow (API) JSON은 용도가 다르다.

Save format: 노드 위치·색·그룹 등 UI 편집 정보 포함
API format: 숫자 node id와 class_type, 입력값 중심
메뉴: File → Export Workflow (API)

로컬 서버는 기본 http://127.0.0.1:8188에서 REST와 WebSocket을 제공한다. API 자동화의 기본 순서는 다음과 같다.

1. UI에서 검증된 workflow를 API 형식으로 export
2. prompt·seed·해상도·입력 파일 node id를 식별
3. POST /prompt 로 제출
4. WebSocket 또는 /history 로 완료 추적
5. /view 로 결과 회수
6. manifest에 workflow hash, model, params, source image 기록

Hermes 자동화는 UI 그래프를 대신 설계하는 것이 아니라, 사람이 검증한 API workflow에 파라미터를 주입해 반복 실행하는 층으로 두는 것이 안전하다.

9. 오류 진단 순서

`Prompt has no outputs`

SaveImage, PreviewImage, SaveAudio, SaveVideo 같은 출력 노드가 있는지 본다.
출력 노드가 bypass/mute인지 확인한다.
최종 결과가 출력 노드까지 연결됐는지 확인한다.

`Required input is missing`

에러에 나온 node id와 input 이름을 찾는다.
images, image, model, vae, samples 소켓을 확인한다.
우회 연결을 삭제한 뒤 Save 노드까지 거꾸로 추적한다.

`class_type not found` / missing nodes

신뢰할 수 있는 workflow인지 먼저 확인한다.
Manager의 missing-node detection을 사용한다.
설치 전 저장소·최근 업데이트·라이선스·외부 네트워크 동작을 확인한다.
설치 후 snapshot을 남기고 ComfyUI를 재시작한다.

모델이 목록에 안 보임

파일명과 확장자를 확인한다.
올바른 폴더(diffusion_models, text_encoders, vae, loras, controlnet)인지 확인한다.
템플릿 자동 감지는 최상위 폴더 이름 검사를 사용할 수 있다.
서버 재시작 또는 모델 목록 refresh를 수행한다.

OOM

batch를 1로 줄인다.
해상도를 낮춘다.
동시에 쓰는 ControlNet·LoRA·upscale 단계를 분리한다.
이미지 생성과 업스케일을 별도 queue job으로 나눈다.
불필요한 모델을 unload한다.

현재 Son님 로그는 OOM보다 연결 오류가 더 직접적인 실패 원인이었다. 에러가 나면 GPU 탓부터 하지 말고 그래프 검증부터 한다.

10. 안전·라이선스·재현성

커스텀 노드는 코드 실행이다

커스텀 노드는 Python 패키지이며, 출처 불명의 workflow가 요구하는 노드를 무작정 설치하는 것은 임의 코드 실행과 비슷한 위험을 가진다. 공식 템플릿은 제3자 노드를 쓰지 않는 것을 원칙으로 한다. 커뮤니티 workflow는 다음을 확인한다.

저장소 소유자와 최근 커밋
Registry/Manager 정보
설치 스크립트와 의존성
외부 API·업로드·telemetry 여부
라이선스
제거·rollback 경로

모델과 출력 권리는 별개다

“오픈소스”라는 말만으로 상업 이용을 단정하지 않는다. 모델 라이선스, LoRA 라이선스, reference image 권리, 생성물의 제3자 유사성, 배포 플랫폼의 AI 표시 정책을 각각 확인한다. 특히 실존 인물 얼굴·브랜드·캐릭터·작가 스타일을 참조할 때는 별도 검토가 필요하다.

현재 후보군에서 특히 구분해야 할 사항은 다음과 같다.

구성요소	확인된 라이선스 경계	실전 판단
FLUX.2 Klein 4B Base / Distilled	BFL 공식 저장소 기준 Apache-2.0	현재 설치된 4B FP8은 상업 파일럿 후보로 검토 가능. 다만 입력 권리·출력 비침해까지 보장하는 것은 아님
FLUX.2 Klein 9B / FLUX.2 Dev	BFL 비상업 라이선스 계열	4B의 조건을 가족 전체로 확대하지 말 것. 상업 게임 자산 라인에 자동 승격 금지
IPAdapter Plus	구현 저장소가 2025-04부터 maintenance-only	최신 모델 호환성과 보안 유지 상태를 직접 검증
FaceID용 InsightFace pretrained model	코드 라이선스와 별개로 제공 사전학습 모델은 비상업 연구용 정책	상업 캐릭터·실존 인물 파이프라인에는 기본 채택하지 말 것

따라서 provenance에는 “ComfyUI를 사용했다”가 아니라 정확한 모델·VAE·text encoder·LoRA·ControlNet/IP-Adapter·upscaler·커스텀 노드 버전과 각 라이선스 URL을 기록해야 한다.

최소 provenance manifest

채택 후보마다 다음을 남긴다.

{
  "workflow": "flux2-klein-t2i-v1.json",
  "model": "flux-2-klein-4b-fp8.safetensors",
  "text_encoder": "qwen_3_4b.safetensors",
  "vae": "flux2-vae.safetensors",
  "prompt": "...",
  "seed": 184203,
  "width": 1024,
  "height": 1024,
  "source_images": [],
  "postprocess": ["background-remove", "conservative-upscale"],
  "human_approval": "pending"
}

11. 첫 30분 · 첫 주 · 자동화 단계

첫 30분

[ ] Comfy Desktop 실행
[ ] Templates에서 Flux.2 Klein 4B Text to Image 열기
[ ] distilled 모델 3종 선택 확인
[ ] 1024×1024, batch 1로 1장 생성
[ ] seed 고정 후 프롬프트의 색상만 변경
[ ] seed 랜덤으로 4개 변형 생성
[ ] 채택 후보 PNG와 workflow JSON 저장

첫 주

Day 1 — 기준선
동일 프롬프트 8 seeds. 속도·성공률·원하는 방향 도달률 기록.

Day 2 — 편집
채택 이미지 한 장으로 의상·소품·배경 각각 하나만 바꾸는 edit 3종.

Day 3 — 에셋화
배경 제거, 규격 크롭, 보수적 업스케일. 실제 엔진/UI에 넣어 가독성 확인.

Day 4 — 일관성
같은 주체를 정면·3/4·측면 또는 표정 4종으로 생성. 실패 패턴 기록.

Day 5 — 배치
workflow를 API 형식으로 내보내 seed 또는 prompt fragment만 바꾸는 8-job sweep.

Day 6 — QA
손·얼굴·텍스트·실루엣·투명 경계·해상도·라이선스·provenance 체크리스트 적용.

Day 7 — 승격 판단
편집만으로 부족하면 Inpaint, 포즈 제어가 병목이면 ControlNet, 스타일 반복이 병목이면 호환 LoRA를 하나만 추가.

자동화 승격 조건

아래가 모두 충족될 때 Hermes/API 자동화로 올린다.

UI에서 같은 workflow가 10회 이상 안정 실행
입력·출력 경로와 node id가 고정
seed·prompt·resolution 변경점이 명확
결과 파일명과 manifest 규칙이 존재
실패 시 재시도할 오류와 중단할 오류가 구분
사람이 승인할 접점이 정의됨

12. 게임 에셋 제작으로 확장한 전체 지도

ComfyUI의 역할은 후보 생성·참조 편집·조건 제어·일괄 후처리 오케스트레이션이다. 실제 게임 에셋은 여기에 결정적 가공과 엔진 검증이 붙어야 한다.

에셋 유형	ComfyUI가 잘하는 일	추가 제작 공정	release gate	16GB 권고
캐릭터 콘셉트/시트	외형·의상·표정·색상 후보, multi-reference 편집	기준 정면 확정, turnaround 재구성, 손·장비·비율 수정	정체성·실루엣·색상표·권리 승인	A
4/8방향 스프라이트	각 방향 후보와 포즈 reference 생성	동일 canvas, pivot, 발 위치, 크기, 팔레트, 프레임 재작성	방향 전환 시 체형·장비·접지 일치	B
2D 애니메이션	key pose·motion mood·inbetween 후보	Aseprite/rig 도구에서 key pose·timing·contact 확정	loop·hit timing·root motion·hitbox 합의	B
픽셀 아트	고해상도 형태·팔레트 후보	indexed palette, nearest-neighbor, 픽셀 수작업 정리	의도된 cluster·outline·target-size 가독성	B
타일셋/지형	재질·표면·edge/corner 후보	고정 grid, seam 보정, terrain peering bits, collision	3×3 wrap·모든 이웃 조합·충돌 통과	B
배경/패럴랙스	분위기·레이아웃·시간대·레이어 후보	foreground/mid/background 분리, camera-safe crop	실제 카메라 이동에서 seam·빈 공간 없음	A
UI 아이콘/버튼	아이콘·프레임·재질·상태 후보	공통 bounds, optical alignment, SVG/PNG 정리	normal/hover/pressed/disabled 일관성·가독성	A
VFX flipbook	폭발·연기·마법 key frame 후보	alpha/additive 정리, atlas, timing·loop 재구성	배경별 halo·frame pop·overdraw 확인	B
2D→3D 소품	single/multi-view shape 또는 splat 후보	Blender retopo·UV·material·LOD·collision·pivot	GLB import·scale·normals·budget·collision 통과	B
2D→3D 캐릭터	silhouette/shape blocking	topology·rig·skin·face·animation 전면 재작업	deformation·contact·LOD·runtime 성능 통과	C

등급은 A=즉시 파일럿, B=제한 파일럿, C=전문 후처리 또는 Cloud/별도 도구가 전제라는 뜻이다. 생성 가능 여부가 아니라 승인 자산까지의 총 수정량을 기준으로 매겼다.

13. 2D 캐릭터와 스프라이트 제작 파이프라인

13.1 캐릭터 기준 시트

첫 단계는 애니메이션이 아니라 불변 계약을 만드는 일이다.

rights-cleared concept/reference
→ FLUX.2 Klein 후보 생성·편집
→ 정면 기준안 인간 승인
→ 정면/3⁄4/측면/후면 후보
→ 키·머리비율·의상 경계·장비 위치 정규화
→ expression/hand/equipment sheet
→ immutable character bible

현재 Desktop에 보이는 공식·제공 템플릿도 실행 경로가 다르다.

템플릿	실제 기반	로컬 여부	판단
`Character Sheet`	`GeminiImage2Node` + `ImageStitch`	Partner API	편리한 레이아웃 후보. 로컬 FLUX 워크플로로 오해하지 말 것
`1 Click Multiple Character Angles`	Qwen Image Edit FP8 + 7B text encoder + angle LoRA + Lightning LoRA + VAE	별도 모델 설치 후 로컬	방향 후보 생성에 유용. 동일 캐릭터 topology 보장은 아님
FLUX.2 Klein Image Edit	현재 설치된 4B FP8 세트	로컬	한 요소씩 바꾸는 기준선. 명시적 다중 방향 템플릿은 아님
`Qwen Image Layered`	Qwen Layered BF16 + 7B encoder + 전용 VAE	로컬이지만 무거움	전경/배경 분리 후보. 공식 노트상 50 steps·CFG 4, 느린 경로

가장 안전한 시작은 현재 Klein으로 정면 기준안 하나를 승인하고, 동일 prompt/seed만 믿지 말고 편집 reference를 사용해 방향 후보를 만드는 것이다. 방향별 후보는 다음 수치를 정규화해야 한다.

canvas 크기와 캐릭터의 pixel height
발바닥 baseline과 중심 pivot
머리·몸통·팔다리 비율
무기·가방·망토 등 비대칭 장비의 좌우 규칙
광원 방향과 그림자 유무
팔레트와 outline 두께

13.2 4/8방향 스프라이트

생성 모델이 그린 여러 방향을 그대로 잘라 atlas로 만들면 방향마다 키·발 위치·장비가 흔들린다. 권장 흐름은 다음과 같다.

승인 정면 + 측면/후면 reference 후보
→ 방향별 key pose 1장씩 인간 수정
→ 공통 canvas와 foot pivot에 배치
→ 좌우 대칭 가능 방향과 고유 방향 분리
→ idle/walk key pose 작성
→ 제한된 inbetween 후보
→ Aseprite tags/slices
→ PNG sheet + JSON export
→ Godot AnimatedSprite2D import

Godot는 개별 PNG 프레임과 단일 sprite sheet 모두 AnimatedSprite2D에서 사용할 수 있다. sprite sheet는 H/V frame 수를 맞춰 잘라 쓸 수 있고, AnimationPlayer를 사용하면 frame 외에 위치·scale 같은 속성도 함께 제어할 수 있다.

프레임 보간의 경계: RIFE/FILM류 raster interpolation은 픽셀을 추정할 뿐 뼈, 발 접지, 무기 contact, hitbox, root displacement를 이해하지 못한다. preview와 비권위 secondary effect에는 쓸 수 있지만 attack/hit/invulnerability frame과 최종 loop timing에는 자동 승격하지 않는다.

13.3 애니메이션별 최소 계약

animation	생성/보조가 가능한 부분	사람이 확정할 것	자동 QA
idle	호흡·옷자락 후보	silhouette 안정성, 과도한 흔들림 제거	첫/끝 pose gap, bbox/pivot jump
walk/run	key pose·중간 pose 후보	contact/passing/up/down, 발 미끄럼, 속도	foot baseline, root 이동, loop velocity
attack	anticipation·strike·recovery 후보	타격 frame, 무기 궤적, hitbox·cancel window	frame tag 존재, 무기 tip jump
hit/death	line of action 후보	방향성, readability, gameplay duration	마지막 pose 유지, alpha/bounds
cast/VFX	손·마법 위치 후보	손-효과 contact, telegraph timing	effect anchor와 frame count

Aseprite는 .aseprite 원본에 layer·frame·palette·tag·slice를 보존하고, CLI에서 --batch, --tag, --frame-range, --sheet, --data, padding·packing 옵션으로 PNG와 JSON을 결정적으로 export할 수 있다. AI는 key pose를 독단적으로 승인하는 대신 이름·tag·palette·pivot·loop 검사를 자동화하는 쪽이 안전하다.

13.4 픽셀 아트

“픽셀풍 이미지”와 실제 픽셀 아트 에셋은 다르다. 생성 결과를 줄이기만 하면 반투명 edge, 색 과다, 불규칙한 1px noise, 프레임마다 달라지는 outline이 남는다.

권장 승격 단계:

고해상도에서 silhouette와 색 덩어리 후보 생성
target size(예: 32/48/64px)로 nearest-neighbor 축소 후보 생성
indexed palette로 색 수 제한
Aseprite에서 cluster·outline·negative space 수정
hot pink/black/white 배경에 합성해 alpha halo 검사
실제 게임 배율과 모바일 화면에서 nearest 필터로 확인

픽셀 아트에서는 창의적 업스케일보다 정수 배율, nearest-neighbor, 고정 팔레트와 수동 cluster 정리가 권위 있는 공정이다.

14. 타일·배경·UI·VFX 제작

14.1 타일셋과 seamless texture

AI가 “seamless”라고 생성한 텍스처도 실제 경계가 맞는지 별도 검사해야 한다.

재질 후보 생성
→ 정확한 tile 크기로 crop
→ offset/wrap으로 네 경계 이동
→ seam inpaint 또는 수동 수정
→ 3×3 반복 합성
→ edge/corner/inner-corner/transition variant 제작
→ Godot TileSet atlas
→ terrain set·peering bits·collision·custom data 설정

Godot 4의 terrain은 과거 autotile을 대체하며 Match Corners and Sides, Match Corners, Match Sides 모드와 terrain peering bits로 이웃 조건을 표현한다. 즉, 중앙 타일 한 장이 자연스럽다고 타일셋이 완성되는 것이 아니다. 빈 공간, 모서리, 외곽, 두 terrain 간 transition을 포함한 atlas가 필요하다.

자동 QA:

좌/우·상/하 edge pixel 또는 perceptual seam 차이
3×3/5×5 반복 contact sheet
tile grid 밖 alpha·bleed
corner/edge 조합 누락
collision polygon·terrain ID·custom metadata 누락
camera zoom에서 filtering/mipmap 영향

14.2 배경과 패럴랙스

Qwen Layered 같은 워크플로는 전경·중경·배경 분리 후보에 유용하지만, 개별 layer의 의미를 prompt로 정확히 통제하는 도구는 아니라는 공식 노트가 있다. 따라서 결과를 자동으로 패럴랙스 레이어로 승격하지 않는다.

foreground: 화면을 가리더라도 gameplay visibility를 침범하지 않는지
midground: 플레이어와 depth ordering이 맞는지
background: 카메라 이동 범위를 덮고 빈 영역이 없는지
모든 레이어: 서로 다른 이동 속도에서 seam·occlusion hole이 없는지
모바일: 데스크톱 crop의 축소판이 아니라 별도 safe composition인지

14.3 UI 아이콘과 버튼 상태

아이콘은 예쁜 단일 PNG보다 세트 일관성이 중요하다.

6~12개 icon 후보를 같은 prompt·reference로 배치 생성
→ 공통 canvas/bounds/padding
→ 배경 제거·alpha 정리
→ palette·stroke·light direction 정규화
→ 16/24/32/48px 실제 표시 크기 QA
→ normal/hover/pressed/disabled 상태 생성
→ Godot Control 노드에서 theme/9-patch 테스트

텍스트는 생성 이미지에 맡기지 말고 폰트와 UI 레이아웃에서 조판한다. 버튼 상태는 형태가 바뀌는 새 그림보다 동일 geometry에 명도·offset·border 변화가 적용되는 방식이 상호작용 인지가 좋다.

14.4 VFX flipbook

ComfyUI는 explosion/smoke/magic 후보나 짧은 video를 만들 수 있지만, game VFX는 투명한 flipbook과 timing 계약이 필요하다.

동일 canvas와 effect origin
additive/alpha/premultiplied alpha 구분
첫 frame의 anticipation과 마지막 frame의 소멸
loop형은 첫/끝 luminance·shape gap
atlas padding과 texture bleeding
overdraw·해상도·동시 particle 수 예산
실제 배경 밝기와 모바일 GPU에서 확인

투명 VFX는 RGBA 존재만으로 통과하지 않는다. black/white/hot-pink 및 실제 장면 합성에서 checker 오염, rectangular matte, 밝거나 어두운 halo를 검사한다.

15. 2D에서 3D 게임 에셋으로 가는 경로

15.1 로컬 ComfyUI가 현재 제공하는 것

로컬 설치의 공식 템플릿을 확인하면 Hunyuan3D는 다음 그래프를 제공한다.

single 또는 multi-view LoadImage
→ CLIPVisionEncode
→ Hunyuan3Dv2Conditioning(/MultiView)
→ KSampler
→ VAEDecodeHunyuan3D
→ VoxelToMesh
→ SaveGLB

single-view, multi-view, multi-view turbo 템플릿이 존재
Hunyuan3D-2 요구량은 공식 저장소의 전체 16GB와 ComfyUI 문서의 전체 12GB가 충돌
Hunyuan3D-2.1은 공식적으로 shape 10GB, texture 21GB, 전체 29GB
ComfyUI 코어 Hunyuan3D 템플릿은 texture/material 생성을 아직 지원하지 않음
결과 GLB는 geometry 후보이지 UV·PBR·retopo·rig·collision이 끝난 game-ready 모델이 아님
무엇보다 Hunyuan3D-2.0/2.1 Community License는 South Korea를 Territory에서 제외하므로, 별도 Tencent 서면 허가 전 한국에서 Works·Output 사용을 보류

기술적으로 보이는 템플릿과 실제 채택 가능한 모델을 분리한다.

후보	ComfyUI/출력	16GB 판단	권리 판단
Hunyuan3D-2/2mv	코어 shape→GLB	shape 수치는 범위 안이나 전체 수치 충돌	한국 사용 보류
Hunyuan3D-2.1 PBR	별도 2.1 경로	texture 21GB·전체 29GB로 기본 로컬 경로 아님	한국 사용 보류
TripoSplat	코어 splat·SPZ·mesh/GLB 후보	공식 최소 VRAM 미확인, bounded local pilot	code/weights MIT; 보조 weight 별도 기록
TripoSG	standalone/custom integration, mesh/GLB	공식 8GB 이상, bounded local pilot	code/weights MIT지만 기본 RMBG-1.4는 비상업용

TripoSplat은 단일 RGB를 DINO vision encoder로 읽어 Gaussian primitives를 만들고 RenderSplat, SplatToFile3D(.spz), SplatToMesh, SaveGLB 경로를 제공한다. splat은 viewpoint preview와 scene capture에 유용하지만, mesh 변환에는 density·smoothing·simplification 손실이 생긴다. 공식 최소 VRAM 수치를 확인하지 못했으므로 16GB 적합성을 추정하지 말고 소품 1개로 OOM·peak VRAM·wall time·mesh 결함을 계측한다.

TripoSG는 single image→mesh/GLB 경로이며 공식 요구량은 CUDA GPU 8GB 이상이다. 다만 기본 파이프라인이 자동으로 받는 BRIA RMBG-1.4는 source-available 비상업용이고 상업 이용은 별도 계약 대상이다. 상업 파일럿에서는 권리 확인된 투명 배경 입력이나 별도 허가된 background remover로 교체하고 exact weight license를 manifest에 기록한다.

15.2 권장 2D→3D 생산선

G0 권리 정리된 정면 reference
→ G1 FLUX/Qwen으로 측면·후면·3⁄4 후보 생성
→ G2 사람이 multi-view silhouette·장비 위치 정렬
→ G3 권리 확인된 TripoSG 또는 TripoSplat bounded pilot
→ G4 Blender에서 mesh 진단·retopo·normals·UV·material
→ G5 scale·pivot·collision·LOD·rig/skin 정리
→ G6 GLB export
→ Godot import·실제 조명·collision·성능 테스트

단일 이미지에서 보이지 않는 후면은 모델이 추론해서 만든다. 그래서 2D 단계에서 multi-view를 먼저 만들고 사람이 서로 맞춘 뒤 3D에 넣는 편이 검증 가능하다. 하지만 AI가 만든 multi-view 역시 동일 topology를 보장하지 않으므로 장비 위치와 silhouette를 수동으로 정렬한다.

15.3 Blender에서 반드시 닫아야 할 항목

영역	검사/수정
geometry	non-manifold, self-intersection, 내부면, 얇은 구조, 삼각형 수
topology	deformation이 필요한 곳의 edge flow, retopo, separate parts
normals	뒤집힌 면, hard/soft edge, tangent 일관성
UV/material	overlap 정책, texel density, PBR map, alpha/cull mode
transform	unit scale, forward/up axis, applied transforms, origin/pivot
gameplay	collision proxy, socket/attachment, nav blocker, LOD
animation	skeleton names, rest pose, weights, root bone, clips

Godot는 glTF 2.0의 .gltf와 .glb를 권장한다. OBJ는 pivot·skeleton·animation·UV2·PBR material이 없어 복잡한 에셋 경로에는 부적합하다. GLB는 mesh와 texture를 한 파일에 넣기 편하지만, 팀에서 texture diff를 별도 관리하려면 .gltf + .bin + textures가 더 투명할 수 있다.

15.4 3D 에셋별 현실적 판단

소형 정적 소품: 가장 좋은 첫 파일럿. shape·pivot·collision·간단 material만 닫으면 됨.
배경 장식물: 화면상 작고 접촉이 적으면 허용 오차가 큼. texture budget과 LOD가 중요.
건물/모듈 키트: 단일 멋진 mesh보다 grid·snap·모듈 edge·collision·texel density가 중요.
캐릭터: topology·rig·skin·표정·의상 deformation 때문에 생성 mesh의 직접 승격 위험이 가장 큼.
Gaussian splat: 프리비즈·배경 capture·view synthesis에는 유용하지만 일반 Godot gameplay mesh의 대체물로 자동 간주하지 않음.

16. ComfyUI 밖의 결정적 제작 도구

도구	권장 역할	자동화 표면	ComfyUI가 대신하지 못하는 것
Aseprite	pixel/frame 원본, tags, slices, palette, atlas	CLI + Lua, PNG/JSON sheet export	권위 있는 pixel cluster·timing·pivot 승인
Blender	3D normalize, retopo, UV, rig, collision, GLB	background mode + Python	clean topology·deformation·game budget
ImageMagick/Pillow	crop, trim, extent, contact sheet, alpha·seam 검사	CLI/Python	예술적 silhouette·identity 판단
Godot	실제 runtime import와 play test	headless import/test 가능	gameplay readability·collision agreement
ComfyUI	생성·편집·조건·배치·후처리 오케스트레이션	REST/WebSocket/API workflow	에셋 규격·엔진 의미·최종 승인

권장 구조는 vendor-neutral하다.

rights-cleared art bible
→ versioned ComfyUI workflow/model
→ immutable candidate outputs
→ deterministic asset builder
→ quantitative QA
→ human art/IP approval
→ Godot import smoke test
→ release asset store

17. 에이전트와 인간의 승인 경계

G0 Rights/Input Approval       사람: 참조·학습·모델 라이선스 승인
G1 Generation Preflight       에이전트: 모델/노드/hash/해상도/경로 검증
G2 Candidate Generation       에이전트: bounded batch와 실패 기록
G3 Deterministic Asset Build  에이전트: crop/alpha/palette/atlas/GLB normalize
G4 Quantitative QA            에이전트: seam/pivot/bbox/loop/import 검사
G5 Art & Gameplay Approval    사람: 정체성·감정·timing·contact·readability 승인
G6 Release Approval           사람: 권리·스토어·최종 merge 승인

에이전트에게 맡겨도 되는 일:

파일 inventory, hash, manifest, 이름·규격·frame tag 검사
alpha 합성, bbox·pivot jump, palette violation, seam·loop gap 측정
atlas packing, GLB import smoke test, 정해진 횟수의 bounded retry

사람이 반드시 결정할 일:

캐릭터 정체성·line of action·표정·실루엣
발·손·무기·소품 contact와 공격 판정 frame
타일의 플레이 가독성, UI 계층, VFX telegraph
3D deformation·collision과 gameplay 의도 일치
최종 권리와 release 승인

확장 provenance manifest

asset_id: hero_walk_e_v003
asset_type: 2d_sprite_animation
source_hashes: []
source_rights_ticket: null
workflow_edit_json: workflows/hero-angle-v2.edit.json
workflow_api_json: workflows/hero-angle-v2.api.json
workflow_hash: null
models:
  - name: flux-2-klein-4b-fp8.safetensors
    hash: null
    license_url: https://github.com/black-forest-labs/flux2
parameters:
  seed: 184203
  width: 1024
  height: 1024
derivative_toolchain:
  - aseprite-version
engine_contract:
  canvas: [64, 64]
  pivot: [32, 56]
  animation: walk_e
  fps: 10
qa_report: qa/hero_walk_e_v003.json
human_approver: null
status: NEEDS_ART_REVIEW

18. 30일 확장 파일럿

교차 파일럿에는 모든 에셋군을 넣되, 생산 자동화 승격 순서는 다르게 둔다.

우선순위	자산군	이유	승격 경계
P0	아이콘·고립 2D 소품	규격·alpha·축소 가독성을 객관화하기 쉬움	최종 silhouette·색은 사람 승인
P0	타일·단순 재질	seam과 연결 조합을 자동·반복 검증 가능	terrain 규칙·랜드마크는 사람 승인
P1	비인터랙티브 배경	카메라와 layer 계약을 고정하면 검증 가능	충돌·길찾기 공간을 이미지에서 추론 금지
P1	비권위 VFX	loop·alpha·frame 경계를 측정 가능	hit/damage timing은 디자인 데이터가 원본
P2	캐릭터·2D 애니메이션	정체성·접촉·타이밍의 인간 수정비 변동이 큼	key pose·pivot·타격감 사람 승인
P3	3D 정적 소품	retopo·UV·PBR·collision·LOD 추가 공정	제한 파일럿, GLB 생성만으로 승격 금지

P0/P1의 QA·manifest가 안정된 뒤 P2/P3를 확대한다. 다만 같은 30일 비교 안에서는 모든 자산군을 측정해 어디에서 실제 승인 비용이 줄어드는지 본다.

Week 1 — 2D 정적 에셋

동일 캐릭터 정면 1장, 표정 4종, 소품 아이콘 6종
투명 PNG와 공통 canvas 규격
black/white/hot-pink alpha QA
채택률과 승인 자산당 수정시간 측정

Week 2 — 방향·애니메이션·타일

캐릭터 4방향 key pose
idle 4 frames, walk 6~8 frames 한 방향
seamless texture 2종과 edge/corner tile
Aseprite PNG+JSON export, Godot AnimatedSprite2D/TileSet import

Week 3 — 2D→3D 정적 소품

권리 정리된 소품 1개를 정면/측면/후면으로 정렬
TripoSplat 코어 템플릿과 TripoSG standalone을 각각 bounded pilot
TripoSG는 RMBG-1.4를 우회하거나 상업 라이선스를 확보
Hunyuan3D-2.x는 한국 적용 별도 Tencent 허가 전 실행·출력 사용 보류
Blender에서 triangle·non-manifold·UV·pivot·collision 수정량 기록
GLB를 Godot에 import하고 실제 조명/scale/성능 확인

Week 4 — 자동화 승격

UI에서 검증된 workflow를 API JSON으로 export
asset builder로 crop/alpha/atlas/manifest 자동화
100-job이 아니라 먼저 20-job bounded batch
실패율, 채택률, 사람 수정분, engine import 성공률 비교
병목이 증명된 경우에만 Qwen angle stack, ControlNet, LoRA, 3D 추가 모델 도입

파일럿 판정 지표

지표	의미
accepted-frame rate	생성 수가 아니라 실제 채택 가능한 frame 비율
correction minutes/asset	승인 자산 한 개당 사람 수정 시간
identity retention	방향·표정·frame 사이 핵심 특징 유지
alpha/seam defects	halo·checker·tile seam·atlas bleeding 건수
pivot/bbox stability	animation 중 접지와 중심 흔들림
loop/contact pass	첫/끝 gap, 발/무기 contact, authoritative timing
engine import pass	Godot에서 broken texture·scale·collision 없이 로드
provenance completeness	모델·workflow·참조 권리·수정·승인 기록 완전성

이 수치는 도입 평가를 위한 내부 지표다. “생성 속도 몇 초”보다 승인 자산당 총시간과 실제 엔진 통과율이 채택 여부를 결정한다.

19. Sonia의 최종 권고

확장된 운영 모델

Generate / Edit
FLUX.2 Klein · 제한적으로 Qwen angle/layer · TripoSG/TripoSplat bounded pilot
(Hunyuan3D-2.x는 한국 적용 별도 허가 전 보류)
        ↓
Normalize
canvas · pivot · palette · alpha · grid · scale · axes
        ↓
Authoritative Tool
Aseprite(frame/pixel) · Blender(mesh/UV/rig) · Godot(runtime contract)
        ↓
Automated QA
alpha · seam · bbox/pivot · loop · mesh · import
        ↓
Human Approval
identity · timing · contact · readability · rights
        ↓
Archive & Release
source + derivatives + workflow + model/license + QA + approval

당장 하지 말 것

모델을 목적 없이 대량 다운로드
Character Sheet 같은 Partner Node 템플릿을 로컬 모델 기능으로 오해
여러 방향 후보를 잘라 바로 sprite sheet로 승격
frame interpolation으로 공격 판정·발 접지·hitbox timing 결정
“seamless” prompt만 믿고 타일 반복 검사를 생략
GLB가 열렸다는 이유로 retopo·UV·collision·LOD 없이 game-ready 판정
한국에서 별도 Tencent 허가 없이 Hunyuan3D-2.x Works·Output을 제작에 사용
TripoSG 기본 RMBG-1.4의 비상업 조건을 무시하고 상업 파이프라인에 포함
Gaussian splat을 일반 gameplay mesh와 동일 취급
커뮤니티 workflow의 missing node를 전부 자동 설치

다음 한 단계

가장 정보량이 높은 다음 행동은 한 캐릭터·한 타일 재질·한 정적 3D 소품으로 구성된 교차 에셋 팩을 만드는 것이다.

캐릭터 정면 + 4방향 key pose + idle/walk 한 방향
seamless 바닥 1종 + edge/corner variants
동일 세계관의 정적 소품 1개를 2D와 GLB로 제작
Aseprite/Godot/Blender 승격 공정과 수정시간을 함께 기록

이 파일럿이 끝나면 “ComfyUI로 무엇을 만들 수 있는가”가 아니라 어떤 에셋 유형에서 Son님의 승인 비용을 실제로 줄이는가를 판단할 수 있다.

주요 출처

출처 경계: 공식 문서의 기능 설명은 “지원되는 capability”의 근거다. 특정 workflow가 Son님의 제작물 품질·일관성·상업 성과를 보장한다는 근거는 아니다. 로컬 성능 수치는 2026-07-27~28 Son님 PC의 실제 로그에서 확인한 관측값이며, 해상도·동시 작업·백그라운드 GPU 부하에 따라 달라질 수 있다.