char-art-system

Imported from macjoocan/game-dev-team_ver04 (plugins/game-dev-team/skills/char-art-system/SKILL.md). Install upstream with npx skills add macjoocan/game-dev-team_ver04 --skill char-art-system. Copyright stays with the author.

캐릭터는 UI(ui-art-system)·이펙트(fx-art-system)와 다르다. 저 둘은 결과물이 규격이라 코드로 그리는 게 정확하지만, 캐릭터는 인상이 결과물이라 생성 모델이 필요하다.

전제 — 백엔드

로컬 ComfyUI 가 http://127.0.0.1:8188 에 떠 있어야 한다. 세팅: references/comfyui-setup.md (RTX 50 시리즈는 CUDA 12.8+ PyTorch 가 아니면 커널 없이 죽는다 — 가이드의 경고 항목을 먼저 본다.)

안 떠 있으면 "생성 실패"가 아니라 측정 불가로 보고한다. 되돌아갈 곳이 프롬프트가 아니라 환경이다.

이 축의 본질은 정체성이다

"예쁜 캐릭터 한 장"은 쉽다. 어려운 건 같은 캐릭터가 포즈·앵글·표정이 바뀌어도 같아 보이는 것이다. 강도 순:

생성 경로 두 가지 — GPU가 없어도 시작할 수 있다

Codex 경로가 중요한 이유: 이 스킬은 "아트 3축 중 유일하게 절차적 생성이 안 되는 축"이라 백엔드 세팅이 선행됐다. Codex의 내장 image_gen은 투명 배경을 네이티브로 지원하고 API 키가 필요 없어서, 그 선행 조건 없이 시안을 시작할 수 있다. (실사용 확인: hex-danmaku 의 회화풍 캐스트가 이 경로 산출물이다 — 1254x1254 RGBA, 투명 54~60%.)

Codex 세션에서:  $imagegen 으로 시안 생성 (투명 배경 요청)
                 ↓ 생성물이 $CODEX_HOME/generated_images/ 에 떨어진다
                 ↓ **반드시 프로젝트 경로로 옮긴다** — 기본 경로에 두면 다른 세션이 못 찾는다
아래 결정론적 체인은 두 경로가 공유한다:
  cutout → sprite-normalize → rig-split/sheet-split → atlas-pack → style-score

Codex 안에 다시 두 갈래가 있다 — 알파냐 배치냐 (실측 2026-09-14)

CLI 는 --background transparent 를 주면 이렇게 거절한다: Transparent background is not supported for this model. (기본 모델 gpt-5.6-sol)

그래도 CLI 가 쓸모없지 않다. 흰 배경으로 뽑고 cutout 으로 자르면 된다 — 실측에서 유리병 하이라이트·흰 반사가 그대로 살아남았다(제거 64.8% · 구멍 0). 전역 색키를 쓰면 그게 뚫린다. cutout 은 테두리에서만 번져 들어가므로 안전하다.

고르는 기준:

• 한두 장, 알파가 바로 필요 → 내장 image_gen
• 여러 장을 같은 조건으로 → CLI 래퍼 + cutout. 프롬프트를 JSONL 로 적어 한 번에 돌린다

주의:

• 공식 scripts/image_gen.py (Codex 스킬의 CLI fallback)는 OPENAI_API_KEY 가 필요하다. 구독만 있으면 못 쓴다 — 서드파티 래퍼가 존재하는 이유가 그것이다

• 구독 할당량을 쓴다(5시간 롤링 + 주간 상한). 배치 전에 규모를 정한다

• CLI 는 --dry-run 으로 요청 JSON 을 먼저 볼 수 있다. 배치를 짜기 전에 한 번 찍어본다

• 배경은 흰색으로 뽑는다. 프롬프트 앞뒤에 plain white background, isolated on white, product photo style cutout 을 두고, 네거티브에 gradient background, vignette, colored background, scenery, floor, ground 를 넣는다. 그 뒤 cutout(기본 모서리 검출, tol 26)으로 자른다. 흰 옷은 테두리 flood fill 이라 안 먹힌다.

• 마젠타 크로마키(--chroma "#FF00FF")를 SD 프롬프트로 시키지 마라 — 실측에서 두 번 실패했다(2026-09-08, hex-danmaku): ① 배경 지시를 프롬프트 끝에 두면 24/24 장이 무시하고 색 그라디언트 배경이 나온다. ② 맨 앞으로 올려 반복하면 배경은 나오는데 피사체까지 그 색으로 물든다 — 청록 드래곤이 분홍이 됐다. 확산 모델에서 색 단어는 화면 전체에 걸리므로 크로마키의 전제(배경색 ∉ 피사체색)가 깨진다. --chroma 는 배경을 후처리로 깔거나 3D 렌더처럼 직접 지정할 때만 쓴다. 그때는 --feather 8 (실측: 기본 1.5에서 경계 번짐 112px, 8에서 16px).

• 접지 그림자·잔광이 구워져 있으면 색 기반 컷아웃으로는 못 지운다 — rembg(의미 분할)를 쓴다. 실측(2026-09-08, hex-danmaku): 프롬프트로 그림자를 빼려고 네거티브 강화·"공중에 뜬"·product photo 문구 제거· 2D 스프라이트·평평한 조명까지 다섯 가지를 시도했는데 전부 그림자가 나왔다(같은 시드 대조 실험). "공중에 뜬" 프롬프트는 그림자 대신 받침대를 만들었다(6장 중 5장). cutout --deshadow 로 절반은 지워지지만 진한 접지 타원은 허용치를 올려도 다리가 먼저 사라진다.

  pip install rembg        # onnxruntime 필요. u2net 176MB 를 처음 한 번 받는다
  python -c "from rembg import remove,new_session; from PIL import Image;     im=remove(Image.open('in.png').convert('RGBA'),session=new_session('u2net')); im.crop(im.getbbox()).save('out.png')"

  장당 0.5초(CPU)에 그림자·잔광이 완전히 사라진다. 색이 아니라 피사체를 의미로 분할하기 때문이다. 색 기반 cutout 은 배경을 통제할 수 있을 때(크로마키·단색 렌더) 여전히 더 정확하다 — 둘을 상황에 따라 쓴다.

• 그라디언트 배경을 --tol 로 이기려 하지 마라. tol 을 60·90 으로 올리면 제거율은 9399% 로 오르지만 피사체가 통째로 반투명해진다(실측: 불투명 4864% → 0.1~3.3%). cutout 이 이제 이걸 미달(exit 1) 로 끊는다.

• 정체성 고정이 필요해지면 로컬 경로로 옮긴다. LoRA 학습은 CUDA 전제다 — Codex 경로로는 캐릭터 1종을 수백 장 양산할 때의 정체성 드리프트를 못 잡는다.

• 두 경로 중 무엇으로 뽑았는지 manifest 에 기록한다(출처·라이선스 칸). 나중에 재현·교체 근거다.

선행 사례: 이 "생성은 모델이, 정리는 결정론적 스크립트가" 구조는 우리만의 것이 아니다. agent-sprite-forge 도 독립적으로 같은 결론에 도달했다 — "스크립트는 창작 두뇌가 아니다. 에이전트가 비주얼·파이프라인 결정을 하고, 도구는 반복 가능한 픽셀·익스포트 작업만 한다." 마젠타 크로마키도 거기서 널리 쓰이는 수법이다.

실행 (로컬 ComfyUI 백엔드가 떠 있을 때)

node <플러그인>/skills/char-art-system/scripts/comfy-run.mjs \
  <플러그인>/skills/char-art-system/references/workflows/sdxl-character.api.json \
  --out art/char --batch 8 --seed 1000 \
  --set 6.text="<프롬프트>"

• --batch N 으로 시안을 한 번에 N장. 시드는 자동으로 기록된다(run-log.json)
• --set <노드id>.<입력>=<값> 으로 프롬프트·해상도·스텝을 바깥에서 바꾼다. 워크플로 파일은 안 건드린다
• 서버가 없으면 스크립트가 측정 불가 로 끝난다 — 실패로 처리하지 않는다
• 배치가 끝나면 모델을 자동으로 내린다. SDXL 하나가 커밋 10GB 를 잡는다(실측 14.6GB → 4.4GB). 연속으로 돌릴 때만 --keep-loaded 를 준다 — 그 경우 다음 배치가 모델 재로딩 90초를 아낀다.
• 작업이 다 끝났으면 서버도 내린다. 모델은 디스크에 남으므로 재다운로드는 없다.

워크플로는 references/workflows/ 에 API Format 으로 둔다. 웹UI 에서 새로 만들었으면 "Save (API Format)" 으로 저장해야 한다(일반 Save 는 /prompt 가 400 으로 거부).

얼굴이 깨질 때 — 순서대로 본다

실측(2026-08-21, SDXL Base · RTX 5060)에서 얻은 순서다. 위에서부터 한다.

1번이 압도적이다. 얼굴이 깨지는 주된 이유는 모델이 나빠서가 아니라 캐릭터가 작게 그려져서다. 1024 정사각에 9마리가 격자로 들어가면 얼굴에 쓸 픽셀이 20~30px 뿐이라 눈을 그릴 수가 없다. 즉 다중 피사체 문제와 얼굴 깨짐은 같은 문제이고, 구도를 고치면 둘 다 낫는다. sprite 라는 단어 자체가 스프라이트 시트를 부르므로 full body portrait of one character, large in frame 쪽으로 쓴다.

주의 — 체크포인트를 바꾸면 프롬프트도 바꿔야 한다

Animagine XL 4.0 을 같은 프롬프트로 넣었더니 캐릭터가 아니라 추상 무늬가 나왔다. 확인한 것:

• 파일 정상(6.9GB · 텐서 2,514 · SDXL 구조) — 손상 아님
• v-prediction 가설도 틀림(강제했더니 회색 단색으로 더 나빠짐)
• 남은 유력 원인: 태그 학습 모델에 자연어 프롬프트를 넣은 것. flat cel shading · clean readable silhouette 같은 문구를 미니멀 벡터 스타일 지시로 해석한 것으로 보인다

교훈: 체크포인트는 프롬프트 문법과 한 세트다. 태그 기반 모델(Danbooru 계열)로 바꾸려면 프롬프트도 태그식(1girl, chibi, full body, simple background)으로 다시 써야 하고, 그건 별도 튜닝 작업이다. 모델만 갈아끼우면 결과가 무너진다.

워크플로 JSON 주의

API Format JSON 에 주석 키를 넣지 마라. _comment 를 넣었더니 ComfyUI 가 노드로 해석해 /prompt 가 500 을 냈다. 설명은 옆에 .notes.md 로 둔다.

스프라이트 파이프라인 — 생성부터 아틀라스까지

전부 커스텀 노드 없이, 의존성 0으로 돈다. 순서대로 이으면 유니티에 넣을 규격 에셋이 나온다.

# 1) 시트 생성 — 여러 포즈를 한 장에 (아래 "왜 시트인가" 참고)
node comfy-run.mjs <워크플로>.api.json --style <profile.json> --out out --batch 2

# 2) 셀 분리 + 알파
node sheet-split.mjs out/<시트>.png --out cells --min 0.012

# 3) 규격 통일 — 캔버스·크기·발바닥 정렬
node sprite-normalize.mjs cells --out norm --canvas 512x768 --fit 0.86 --anchor bottom

# 4) 아틀라스
node atlas-pack.mjs norm --out atlas.png --trim --pad 2 --pot

낱장 캐릭터라면 2번 대신 cutout.mjs 로 배경만 지우면 된다. 리깅용으로 부위를 나누려면 rig-split.mjs, ControlNet 용 포즈 스켈레톤이 필요하면 pose-skeleton.mjs.

왜 "한 장에 여러 포즈"인가 — 정체성 때문이다

한 장 안에서는 캐릭터가 유지된다. 같은 디노이징 과정이라 모델이 스스로 일관성을 잡는다. 별도로 4번 생성하면 후드 모양이 바뀌고 없던 토끼귀가 생긴다(실측). LoRA 없이 정체성 문제를 상당 부분 우회하는 방법이라, 지금 구성에서 가장 실용적인 경로다.

주의:

• 정사각 캔버스(1216² 등)를 써라. 가로로 긴 캔버스를 주면 12~16개 초소형 셀이 나와 못 쓴다
• 셀 수를 지정해도 안 지킨다. 2x2 를 요청해도 7개가 나온다. 그래서 sheet-split 은 격자 좌표를 가정하지 않고 연결 성분으로 찾는다
• 포즈는 지정할 수 없다. 모델이 고른다. 걷기 8프레임 같은 특정 시퀀스는 이 방법으로 안 된다

각 단계에서 실제로 밟은 함정

프레임 애니메이션 — 영상 모델(WAN 2.2 5B)이 답이다 (실측 2026-09-08)

확산 이미지 모델로 프레임을 따로 뽑으면 프레임마다 캐릭터가 달라진다. 영상 모델은 시간축을 같이 보므로 그 문제가 구조적으로 없다. references/workflows/wan22-5b-sprite-motion.api.json · 세팅은 그 옆 .notes.md.

8GB 에서 돈다 — 모델 17GB, VRAM 7.6GB, 시스템 RAM 27GB, 33프레임에 약 25분. 커스텀 노드 불필요 (ComfyUI 0.33+ 가 Wan22ImageToVideoLatent 내장). 5B 를 써라 — 14B 는 24GB 가 필요하다.

핵심은 ModelSamplingSD3.shift — 움직임과 정체성을 맞바꾸는 손잡이다.

작은 동작(걷기·대기·흔들림)은 되고, 큰 동작(공격·점프)은 shift 를 어떻게 줘도 안 된다. 공격은 shift 를 올려도 드리프트가 안 줄었다 — 손잡이의 한계 밖이다. 큰 동작은 키프레임을 따로 생성해 (LoRA + ControlNet) 잇거나 코드 트랜스폼으로 준다.

프롬프트에서 제일 중요한 건 배경이 아니라 카메라다. 영상 모델은 기본적으로 카메라를 움직인다. in place, camera locked, no zoom, no pan 을 긍정에, camera motion, zoom, pan, static, frozen 을 부정에 넣는다. in place 를 빼면 캐릭터가 화면 밖으로 걸어 나간다. 실측에서 이 조합으로 면적비 1.00~1.03 을 유지했다.

전체 파이프라인 — 정지 스프라이트 1장 → 게임 시트:

# 1) 흰 배경에 합성해 입력 (영상 모델은 알파를 모른다)
# 2) 33프레임 생성 — shift 3.0, 640x640
node comfy-run.mjs wan22-5b-sprite-motion.api.json --out wan/walk   --set 4.image=sprite.png --set 8.shift=3.0 --set 9.cfg=6.5 --set "5.text=<동작>, in place, camera locked"
# 3) 앞쪽에서 6장 선별 → rembg 로 알파 → 규격 통일 → 가로 스트립
#    뒤로 갈수록 드리프트가 커진다. 33장을 다 쓰지 않는다
node sprite-qa.mjs walknorm      # 정체성 드리프트가 기준 안인지 여기서 판정한다

실측 결과: 6프레임 시트가 sprite-qa 충족(드리프트 미달 0건), 게임 41px 에서 동작이 읽힌다.

img2img·ControlNet 단독은 안 된다 (앞선 실측)

실측으로 확인한 것:

레퍼런스 게임들(Royal Match·Royal Kingdom·Zen Match)은 프레임 스프라이트가 아니라 Spine 스켈레탈 애니메이션을 쓴다 — assets zip 에서 .skel/.atlas 가 73~134건 나왔다. 생성으로 프레임을 뽑는 대신 한 장을 잘 만들어 뼈대에 물리는 쪽이 현실적이다(rig-split.mjs 가 그 앞단).

도트(픽셀아트)는 격자를 모델 바깥에서 강제한다 (실측 2026-09-09)

확산 모델은 도트를 못 만든다. 품질이 모자란 게 아니라 종류가 다르다 — VAE 가 연속 RGB 를 뱉으므로 생성물은 색이 10만 개 넘고 경계가 전부 부드럽다. 그걸 48px 로 줄이면 도트가 되는 게 아니라 흐릿한 썸네일이 된다. 걷기 애니메이션과 같은 모양의 문제다: 손잡이를 더 돌려서 되는 게 아니라 격자·팔레트·알파를 모델 바깥에서 강제해야 한다.

도트 계약 — 상용 픽셀아트 300장 실측 기준선

"외톨이 픽셀"이 축소한 일러스트와 손으로 찍은 도트를 가르는 지문이다. 이웃 4칸에 자기 색이 하나도 없는 픽셀의 비율이다. 큰 일러스트를 그냥 줄이면 36% 가 나오고, 눈으로 보면 노이즈 덩어리다.

단, 0 이 목표가 아니다. 1픽셀 하이라이트는 정당한 도트 기법이라 레퍼런스도 9.1% 다. 너무 낮으면(2%대) 과하게 뭉갠 것이다 — 그래서 대역으로 판정한다.

node skills/char-art-system/scripts/pixel-quantize.mjs <일러스트.png> --out dot.png      [--size 48] [--colors 24] [--clean 2]
node skills/char-art-system/scripts/pixel-contract.mjs <dot.png|폴더> [--cell 48]

pixel-quantize 의 처리 순서가 중요하다. 바꾸면 결과가 탁해진다.

1. 알파를 먼저 이진화한 뒤 축소한다(순서를 바꾸면 반투명 테두리 색이 본체에 섞인다)
2. 면적 평균 축소는 알파 가중으로(투명부의 검정이 섞이면 테두리가 어두워진다)
3. 색 양자화는 Lab 에서 k-means(RGB 로 하면 눈에 다른 색을 한 덩어리로 합친다)
4. 외톨이 픽셀 정리 — --clean 2 가 레퍼런스 대역이다(36.5% → 6.6%). 4 는 과하게 밀린다(2.6%)

pixel-contract 는 종료 코드 0/1/3 을 낸다. 색 수만 세면 안 된다 — 축소한 일러스트도 색 수는 맞출 수 있다. 실측에서 색·알파는 통과하는데 외톨이 36.5% 인 결과가 나왔다.

그렇다고 외톨이를 품질 게이트로 쓰지 마라 — 한 번 틀렸다. 상한을 15% 로 박았더니 도트 전용 모델의 멀쩡한 출력(외톨이 21~26%)을 15/16 프레임 반려했다. 게임 크기로 줄여 보니 문제가 없었다. 축소 노이즈(35.8%)와 정상 출력(26%)이 종이 한 장 차이라 이 지표 하나로는 못 가른다. 그래서 하드 게이트는 팔레트 색 수와 반투명 비율만 잡고, 외톨이·평평은 수치를 보여주고 사람이 본다.

팔레트는 프레임이 아니라 시트 속성이다. 프레임마다 하한을 걸면 후면처럼 단순한 컷(망토+머리뿐, 14색)을 반려한다. 파일 전체 합집합으로 본다.

시트가 격자면 행도 세야 한다. 가로 스트립만 가정했다가 192x192 4x4 시트의 위 4칸만 재고 나머지 12칸을 통과시킨 적이 있다.

도트 작업 순서 (정본)

시작점이 뭐냐로 갈린다.

이미 일러스트가 있으면 — 변환이 먼저다. 정체성이 그대로 남는다.

node skills/char-art-system/scripts/pixel-quantize.mjs <일러스트.png> --out dot.png      --size 48 --colors 24 --clean 2
node skills/char-art-system/scripts/pixel-contract.mjs dot.png

애니메이션이 필요하면 — 위 결과를 시작 프레임으로 도트 전용 모델에 넣는다. 두 경로는 경쟁이 아니라 직렬이다. 프롬프트만으로 돌리면 무기가 프레임마다 사라진다.

# 1) RGB 로 변환 (투명이 있으면 API 가 거부한다)
python <RD스킬>/scripts/prepare_reference_image.py --input dot.png --output ref.png        --matte-color "#FFFFFF" --target-size 48 --fit contain --trim-alpha
# 2) 단가 먼저 (--check-cost 는 무료다)
python <RD스킬>/scripts/retro_inference_run.py --preset <프리셋> --check-cost ...
# 3) 생성 -> 흰 배경이 불투명하게 온다 -> 테두리 flood fill + 알파 이진화
node skills/char-art-system/scripts/cutout.mjs <출력.png> --out cut --feather 0 --binary-alpha
node skills/char-art-system/scripts/pixel-contract.mjs cut --cell 48

--binary-alpha 를 빼지 마라. --feather 0 만으로는 톨러런스 경계에 반투명이 1.1% 남아 도트 계약(0.5%)을 어긴다.

마지막은 사람이다. 얼굴(48px 에서 6x6), 소품 정리, 면 단순화는 Aseprite 로 손본다. 판정 도구는 "도트인가"만 본다 — "좋은가"는 안 본다.

생성으로 도트를 뽑을 거면 도트 전용 모델을 쓴다

SDXL LoRA 로 도트를 배우게 하는 건 원본이 18~48px 이라 30배 확대 학습이 되고, 모델이 "도트 화풍"이 아니라 "큰 네모"를 배울 위험이 크다. 도트 전용 서비스(Retro Diffusion 등)가 격자 스냅·양자화를 파이프라인에 포함하므로 그쪽이 맞다.

단 무기·소품은 프레임마다 사라진다. 실측: 4방향 걷기 프리셋(animation__walking_and_idle)에 무기를 프롬프트로 강하게 박아도 16프레임 중 3개에만 검이 나왔다(나머지 13개는 0px). 프레임마다 독립 생성이라 걷기 애니메이션에서 겪은 것과 같은 한계다.

시작 프레임을 받는 프리셋을 써라. rd_advanced_animation__walking 에 정리된 도트 한 장을 input_image 로 넣으니 8/8 프레임에 검이 남았고 8프레임이 23색을 공유했다.

단, 4방향 프리셋도 버리지 마라. 무기만 지우면(색이 뚜렷하면 픽셀 단위로 지워진다) 4방향 x 4프레임 세트가 남는다 — 시작 프레임 프리셋에는 없는 것이다. 실측에서 검 141px 를 지우고 부유 픽셀 10개를 정리하니 16프레임이 24색을 공유했다. 방패처럼 색이 애매한 소품은 임계값으로 못 도려낸다 — 밝은 코어만 지워지고 테두리가 남아 구멍이 뚫렸다. 그건 Aseprite 로 손봐야 한다. input_image 는 RGB(투명 없음)여야 하고, 배경이 불투명 흰색으로 돌아오므로 테두리 flood fill 로 잘라낸다 — 전역 색키를 쓰면 캐릭터의 흰 하이라이트에 구멍이 뚫린다 (실측 52px).

걷기 프레임은 코드로 만든다 — walk-composite.mjs (실측 2026-09-08, 결론)

생성 모델로 걷기 프레임을 뽑는 길은 세 갈래 모두 막혔다. hex-danmaku 의 창 든 고블린으로 같은 캐릭터에 네 방법을 다 돌려 게임 렌더 크기(41x44)에서 인접 프레임 픽셀차를 쟀다. 의상 차이는 깜빡임이고 다리 차이가 걷기다 — 이 둘을 나눠 재야 판정이 된다.

원인은 손잡이가 아니라 구조다. 확산 모델은 프레임마다 독립 표본이라 "의상은 그대로, 다리만" 을 지킬 수단이 없다. denoise 를 낮추면 다리까지 굳고, 올리면 의상까지 흔들린다. 0.40/0.55/0.70/0.75/0.85/0.95 를 다 재도 뒤집히는 지점이 없었다.

# 의상이 고정된 한 장을 만들고(img2img 가 여기에 딱 맞는다), 다리는 코드로 움직인다
node skills/char-art-system/scripts/walk-composite.mjs <캐릭터.png> --out frames      --frames 8 [--lift 0.30] [--box lx,rx] [--mid x] --strip walk.png

다리 영역을 좌/우로 나눠 위를 고정하고 세로로 압축한다. 평행이동하면 부츠 위에 틈이 생기지만 압축은 틈이 없다. 여기에 몸통 상하(사이클당 2회)를 얹는다 — 작은 화면에서 걷기를 파는 건 다리보다 몸통 상하다.

• 사이클이 루프가 맞는다. 생성 시퀀스와 달리 왕복(pingPong)이 필요 없다
• 다리 상자 자동 검출은 초안이다. 창·망토가 아래까지 오면 딸려온다 — 실측에서 창 든 캐릭터는 자동으로 맞았고, 발이 벌어진 캐릭터는 맨 아랫줄에 한 발만 닿아 나머지 발을 놓쳤다. --box 로 직접 준다. 눈으로 한 번 봐라
• 옆모습 스트라이드는 못 만든다(없는 픽셀이 필요하다). 정면·정면3/4 제자리 걷기용이다
• 무릎이 안 접힌다. 관절이 필요하면 rig-split.mjs + 스켈레탈로 간다

움직임의 대부분은 다리가 아니라 몸통 상하다 (실측 2026-09-08)

같은 스크립트를 보스 4종(렌더 5356px)에 돌려 --bob 0 으로 다리만 움직여 봤다. 프레임차가 **0.20.7** 이었다 — 사실상 안 보인다. 상하를 넣으면 2127 로 뛴다. 다리 영역이 스프라이트의 714% 밖에 안 되기 때문이다. 걷는 적(lunger)의 11 도 대부분 다리가 아니라 상하가 만든 값이었다.

그래서 --lift 보다 --bob 을 먼저 맞춘다. 진폭은 렌더 크기 기준으로 환산해서 잡아라 — --bob 은 피사체 높이 비율이라 캔버스가 같아도 렌더 크기가 다르면 체감이 달라진다. 실측 기준점: 렌더 0.62~0.64px 이면 프레임차 11 이고 그게 "걷는다"로 읽히는 지점이었다. 그보다 키우면(렌더 2.9px → 프레임차 27) 걷기가 아니라 떨림으로 보인다.

이미 CSS 등으로 흔들고 있는 대상이면 --bob 0 으로 끄지 말고, 진폭비를 벌려서 얹어라. 보스는 CSS 부유(2.6초 3px) 위에 0.62px 를 얹었다 — 5:1 이라 두 진동이 안 싸운다. 같은 진폭으로 주기만 다르면 그때 싸운다.

서 있는 캐릭터는 걷기가 아니라 무게중심 이동이다

제자리에 있는 보스에 걷는 적과 같은 박자(150ms)를 주면 무게가 안 실린다. 프레임 간격을 캐릭터마다 줄 수 있어야 한다(hex-danmaku 에서는 시트 설정에 ms 를 더했다. 보스 260ms).

다리 상자는 캐릭터마다 손으로 잡는다

--hip 을 낮추면 치마·망토까지 압축돼 천에 세로 이음매가 생긴다. 각 캐릭터마다 행을 찍어 다리 덩어리 둘로만 갈리는 줄을 찾아야 한다. 자동 검출은 거기까지 못 한다. 네발 짐승은 좌/우가 아니라 앞/뒤로 갈라 반대 위상을 주면 속보가 된다(실제로 통했다).

ControlNet 스켈레톤은 체형이 맞아야 한다

OpenPose 에는 "머리 크기" 입력이 없다. 코·눈·귀 키포인트가 목에서 얼마나 멀리, 얼마나 넓게 떨어져 있는지가 곧 머리 크기다. 그래서 비율이 틀리면 ControlNet 이 캐릭터를 그 비율로 늘린다 — 2.5등신 고블린에 7등신 스켈레톤을 물렸더니 팔다리가 막대처럼 늘어나고 갑옷·창이 통째로 사라졌다. pose-skeleton.mjs --proportion chibi|hero 로 고른다.

정면 걷기 스켈레톤에서 앞뒤 스윙을 x 로 옮기면 다리가 좌우로 교차한다 — 걷기가 아니라 가위질로 보인다. 정면에서는 스윙을 y(들림)로 옮기고 발목이 중심선을 넘지 않게 묶는다. --view side 는 x 스윙이 맞다.

항상 같은 특징은 프롬프트에 쓴다 — 토큰 하나에 기대지 마라

같은 LoRA·같은 스켈레톤으로 프롬프트만 바꿔 실측했다. 토큰만 준 쪽은 갑옷도 투구도 창도 없는 맨몸 고블린이 나왔고, 내용 태그(helmet with red plume, red scarf, gold armor, holding a spear)를 같이 준 쪽은 원본과 같은 캐릭터가 나왔다. 15장짜리 소규모 데이터셋에서 토큰은 그만큼 약하다. 캡션 규칙의 뒷면이다.

정체성 고정 — 캐릭터 LoRA 학습

시트 생성은 우회다. 캐릭터 1종을 스킨·표정·포즈로 계속 양산해야 하면 LoRA 를 학습한다. 상세(설치·데이터셋 규칙·8GB 프리셋 근거·고르는 법): references/lora-training.md

# 1) 데이터셋 — 채택본(알파 PNG) 10~20장 → 배경 합성·축소·중복 제거·캡션 → dataset.toml
node lora-dataset.mjs art/char/approved --out art/char/lora-ds --token gdt_hero --captions captions.json

# 2) 학습 — 8GB 프리셋(batch 1 · grad ckpt · TE 캐시 · fp8 · bf16). 에폭마다 저장
node lora-train.mjs art/char/lora-ds --name hero_v1 --base sdxl        # --dry-run 으로 설정만 먼저

# 3) 고르기 — 에폭 × 강도(0/0.6/0.8/1) × 포즈 프롬프트 4종 격자 한 장. 사람은 이것만 본다
node lora-eval.mjs --lora art/char/lora-ds/train --token gdt_hero --out art/char/lora-eval

# 4) 생성 — LoraLoader 워크플로. 프롬프트는 토큰으로 시작
node comfy-run.mjs references/workflows/sdxl-character-lora.api.json --set 10.lora_name=hero_v1-000007.safetensors \
  --set 10.strength_model=0.7 --set 10.strength_clip=0.7 --set 6.text="gdt_hero, winter coat, front view, ..."

지켜야 하는 것 세 가지:

• 캡션에는 그 장에서 변하는 것만(포즈·앵글·표정). 머리색·옷을 쓰면 그 단어에 학습돼 토큰만으론 안 나온다
• 트리거 토큰은 사전에 없는 단어(gdt_hero). hero 는 모델이 아는 개념과 섞인다
• 결과는 파일이 아니라 (에폭, 강도)다. 마지막 에폭이 최선인 경우는 드물다. 격자에서 정체성이 붙는 가장 이른 에폭·낮은 강도를 고르고, 그걸 manifest 에 적는다

학습기(sd-scripts venv)가 없으면 lora-train.mjs 는 측정 불가로 끝난다. ComfyUI 와 별도 설치다. 학습 중엔 ComfyUI 모델을 내려야 한다(SDXL 하나가 커밋 10GB — 둘이 같이 못 산다).

실측(2026-09-03, RTX 5060 8GB): 같은 캐릭터 13장 × 12반복 × 10에폭 = 1,560스텝, SDXL Base 1024px, 8GB 프리셋 그대로 → 31분 완주, 1.0초/스텝, OOM 없음. 격자에서 LoRA 없는 행은 매번 다른 캐릭터, LoRA 행 10개는 전부 같은 캐릭터(머리·눈·의상·비율)에 포즈 프롬프트 4종이 다 먹었다. 채택: 에폭 8 @ 0.9 + 프롬프트에 후드 명시. 빠진 요소(후드)는 강도를 올려 억지로 붙이지 말고 프롬프트로 말한다 — 강도 1.0 은 배경이 새기 시작한다.

모션 스프라이트 — LoRA + ControlNet 실측

같은 날 채택 LoRA 에 OpenPose(sdxl-character-lora-openpose.api.json) 를 얹어 스켈레톤 4종을 뽑았다.

결론: 키프레임 포즈(idle·walk·attack 같은 정지 포즈) 는 이 조합으로 된다. 걷기 8프레임 같은 연속 동작은 여전히 생성으로는 안 되고, 한 장을 잘 만들어 Spine 뼈대에 물리는 rig-split 경로가 답이다.

스타일 LoRA — 레퍼런스 화풍만 빌리기 (실측 2026-09-03)

레퍼런스 게임 초상화 70장(캐릭터 70종 × 1장씩, WD14 자동 캡션)으로 스타일 LoRA 를 학습해 우리 캐릭터 LoRA 와 체인(sdxl-character-lora-style.api.json)으로 썼다. 상세 규칙은 lora-training.md 의 스타일 LoRA 절.

누출의 원인은 캡션이었다. 태거 결과에서 cookie 계열 태그를 전부 지웠더니, "쿠키다"라는 내용이 캡션 대신 스타일 토큰에 붙었다. 내용 태그(food·cookie·gingerbread)는 남기고 IP 이름(작품명)만 지운다. 그래야 비스킷 피부는 cookie 단어에, 그리는 법만 토큰에 남는다. 선택 기준: 이른 에폭(57) · 강도 0.50.7 · 캐릭터 LoRA 와 합 1.5 이하.

v2(모든 캡션에 "gingerbread cookie character, biscuit-colored skin, food" 명시, 1,400스텝, 30분)로 재학습한 결과: 강도 0.7 에서는 에폭 5·10 모두 사람 피부 유지, 스티커 테두리·광택만 옮겨옴. 1.0 에서는 여전히 얼굴이 노랗게 기운다. 캡션이 대부분을 고치고, 나머지는 "0.7 이하" 규칙이 막는다.

그림이 구린 진짜 이유는 베이스 모델이었다 (실측 2026-09-03)

같은 시드·같은 LoRA·같은 4포즈로 세 조합을 비교했다(sdxl-character-lora-style-hires.api.json).

• SDXL Base 로 학습한 LoRA 는 Animagine 에 재학습 없이 얹힌다. 구조가 같아서다. 강도는 0.1 낮췄다(0.9 → 0.8)
• 체크포인트를 바꾸면 프롬프트 문법도 바꾼다. Animagine 은 태그식(masterpiece, best quality, 1girl, solo, chibi, white hair, red eyes, ...). 자연어를 넣으면 추상 무늬가 나온다(8/21 실측). 정체성 태그(white hair, red eyes)를 프롬프트에 같이 써도 된다 — LoRA 와 싸우지 않는다
• 학습 데이터(13장)가 SDXL Base 산출물이라는 한계는 남아 있다. 다음 캐릭터 LoRA 는 Animagine 으로 뽑은 시안으로 학습한다

캐릭터 LoRA v2 — 좋은 모델로 뽑은 데이터로 다시 학습 (실측 2026-09-03)

위 기준 조합으로 포즈·앵글·표정·소품을 바꿔 24장을 뽑고, 배경이 들어간 4장과 비율이 깨진 1장을 빼서 19장으로 Animagine XL 4 를 베이스로 학습했다(× 8반복 × 10에폭 = 1,520스텝, 32분, 1.1초/스텝).

토큰만으로 약해진 이유는 캡션이다. 19장 전부에 hood up 을 넣었는데, 전 장에 공통인 단어는 정체성인데도 캡션에 쓰면 토큰이 아니라 그 단어에 붙는다. 실제 생성 프롬프트에는 hood up 이 들어가므로 실사용엔 문제가 없지만, v3 는 캡션에서 공통 특징을 뺀다(lora-training.md "전 장에 공통인 특징" 절).

현재 기준 조합: animagine-xl-4.0 · 태그 프롬프트(정체성 태그 + hood up 포함) · hires 1.5× denoise 0.42 · 캐릭터 LoRA redhood_v2 에폭 8 @ 0.8 · 스타일 LoRA(ckstyle_v2 에폭 5) 0.5.

절차

1. 기준 확인 — VISUAL_DESIGN.md 의 팔레트·프로포션·금지 스타일을 프롬프트에 넣는다. 없으면 art-direction 부터.
2. 시안 배치 생성 — 한 캐릭터당 8~16장. 시드를 전부 기록한다.
3. 자동 스코어링 — 규격(캔버스·배경 순도·알파 여백) + 팔레트 정합 + 실루엣 판독성. 하위는 자동 탈락.
4. 사람 채택 — 상위 3장에서 1장. 이 한 단계는 남긴다 (취향·IP·톤은 사람 판단).
5. 정체성 고정 — 채택본으로 LoRA 학습(lora-dataset → lora-train → lora-eval)하거나 IP-Adapter 레퍼런스로 등록.
6. 변형 양산 — 표정·포즈·의상 변형. 프레임 시트가 필요하면 sprite-pipeline 으로 넘긴다.
7. 등록 — asset-pipeline manifest 에 모델·시드·프롬프트·LoRA 버전까지 적는다.

재현성 (이 축에서 제일 자주 깨지는 것)

생성물은 모델 + 시드 + 프롬프트 + LoRA 버전 이 없으면 다시 만들 수 없다. 6개월 뒤 스킨 하나 추가하려는데 원본 캐릭터를 재현 못 하면 처음부터 다시 그리게 된다.

manifest 에 반드시 남긴다:

checkpoint / lora(+가중치) / seed / sampler·steps·cfg / 프롬프트 원문 / 레퍼런스 이미지 경로

보고 (검증 리포트 5섹션)

• 증거: 실행한 워크플로와 prompt_id, 시드·생성 장수·채택 기준, 결과 경로
• 기준: VISUAL_DESIGN.md 의 어느 항목과 대조했는지
• 공백: 안 만든 변형(표정·앵글), 스코어링 못 한 항목
• 잔여 위험: 정체성이 흔들릴 수 있는 변형 범위

하지 않는 것

• 톤·팔레트 결정 (art-direction 소관)
• 프레임 시트 정규화·아틀라스 (sprite-pipeline 소관)
• 실존 IP·타 게임 캐릭터를 모방한 생성 — 레퍼런스는 스타일 기준이지 복제 대상이 아니다
• 백엔드가 없는데 "대충 비슷한 결과"로 넘어가기 — 그건 측정 불가다