게임 스프라이트를 로컬 Wan 2.2로 뽑아봤다. (핑크팬더 5모션)

게임 스프라이트를 로컬 Wan 2.2로 뽑아봤다. (핑크팬더 5모션)

게임 스프라이트를 AI 영상으로 만든다는 얘기를 들었습니다. 모탈컴뱃 제작진이 실제로 쓴 방식이라고 하더라고요. 영상 생성 모델을 배우로 쓰는 것입니다. 배우에게 동작을 찍게 하고, 크로마키로 배경을 지우고, 키프레임을 뽑아 아틀라스로 묶습니다. 옛날 제작진이 실제 배우를 찍어 스프라이트를 그렸다는 이야기가 화제가 됐었죠. 그 자리를 영상 모델이 대체하는 셈입니다.

 

트렌드시프트에서 그 워크플로우를 에이전트 스킬로 만든 걸 봤습니다. gary149/h3-game-sprites였어요. H3(Hailuo/MiniMax)로 모션 클립을 만들고 크로마키, 키프레임 추출, 아틀라스까지 전부 대신 해줍니다. Hermes 스킬로 설치하니 금방 돌았습니다.

 

흐름 자체는 깔끔해서, H3 클립만 뺄 수 있으면 그대로 쓸 수 있는 구조였어요. 문제는 영상 생성이었습니다. H3는 그 사이 허깅페이스에도 오픈웨이트로 공개됐는데(2026년 8월 초), 미국·EU·영국·한국 사용자는 라이선스 신청을 따로 해야 했습니다. 거기다 모델이 33B+32B 규모라 실험실 GPU로는 로컬 구동이 어려웠고, API는 유료라 당장 쓸 키도 없었습니다.

 

로컬에 서빙 중인 딥시크나 qwen3.8 같은 LLM은 텍스트만 뱉습니다. 대체가 안 돼요. 오픈소스 영상 모델을 직접 돌리는 수밖에 없었고, 알리바바의 Wan 2.2 TI2V-5B가 후보가 됐습니다.

H3가 없어서 Wan으로

검토한 대안은 이랬습니다.

 

옵션	판정
H3(미니맥스)	오픈웨이트 공개(8월 초)지만 미국·EU·영국·한국은 라이선스 신청 필요, 33B+32B 규모라 로컬 구동 난해, API는 클립당 $0.6
로컬 LLM 대체(딥시크/qwen3.8)	텍스트만 뱉어 영상 생성 불가
GB10 듀얼	딥시크 서빙으로 두 노드 다 약 92% 점유
로컬 2080 Ti(11GB)	Turing이라 fp8/bf16 텐서코어 없음, GGUF Q4 + 480p로 수 분~십수 분
워크스테이션(일회성)	720p 5.1분/46GB로 검증 완료, 상시 구동은 안 되는 워크스테이션
리모트 서버의 L40 세 번째 GPU	Ada라 fp8 지원, 여유 17.6GB, GGUF 480p 실운영 후보(검토만)

 

Apache-2.0이면서 5B 수준에서 도는 이미지투비디오가 마침 Wan이었습니다. TI2V는 텍스트와 이미지를 같이 받는 모델이에요. 첫 프레임에 캐릭터 스틸을 고정하는 idle 핀 트릭이 그대로 성립합니다. 모션이 끝나면 캐릭터가 자기 자리로 돌아오고, 화면 밖으로 이탈하지도 않아요. 격투게임 스프라이트에 이만한 성질이 없습니다.

 

결국 워크스테이션을 일회성으로 빌려 쓰는 게 답이었습니다. 검증은 그 길로 끝났고, 상시로 얹을 자리는 남은 숙제로 남겨뒀습니다.

 

VRAM은 5B bf16 로드가 24.2GB, 720p 생성 피크가 46GB입니다. 실험실의 워크스테이션(96GB)에 딱 맞는 크기였어요.

돌리는 데까지가 절반

환경 꾸리기가 모델보다 힘들었습니다. 실행은 Slurm sbatch로만 제출했어요. GPU1에 떠 있는 vLLM(qwen3.8-27b 서빙)은 건드리지 않고, 빈 GPU0을 골라 씁니다. 잡이 끝나면 GPU를 반납하고요.

 

venv 함정이 하나 있었습니다. 기존 서빙 venv에는 python-venv가 없어서 venv --without-pip로 만들고 get-pip로 부트스트랩했어요. torch cu130은 vLLM venv를 복제한 뒤 python -m pip으로 diffusers만 얹었습니다. pip 스크립트는 shebang이 원본 인터프리터를 가리켜서, 그냥 쓰면 기존 venv를 오염시킵니다. python -m pip으로만 깔아야 깨끗하죠. 이 방식이면 로드가 7초(warm cache) 만에 끝납니다.

 

모델은 Wan-AI/Wan2.2-TI2V-5B-Diffusers 공식 포트를 받았습니다. 20GB 안팎이었어요. diffusers 0.40의 WanImageToVideoPipeline으로 I2V를 로드했는데, CLIP이 필요 없고 VAE first-frame 방식이라 간단했습니다. 출력이 (1, F, H, W, C) float32 numpy라는 데서 두 번 헛짚었습니다. uint8 변환과 인덱싱이 따로 필요했죠. 환경을 세우는 시간이 생성 시간보다 길었습니다. 이 글은 그 삽질의 기록입니다.

첫 검증, 720p 5.1분

 

레퍼런스 영상이 하나 떴습니다. 121프레임(5초), 50스텝이었어요. 생성에 5.1분, peak VRAM 46GB. 키잉은 bg_purity 1.0에 magenta 누수 0px이었습니다. idle 핀도 통과했습니다. 이 스트립을 sprite_cut.py로 잘라 12키프레임 스프라이트가 나왔습니다.

 

 

 

첫 결과치고는 반듯했습니다. 스트립 배경이 마젠타로 남아 있는 게 보일 텐데, 크로마키 원판이라는 뜻입니다. 키잉 품질이 곧 스프라이트 품질이에요.

핑크팬더 5모션

캐릭터는 핑크팬더로 정했습니다. 나노바나나(Nano Banana)로 스틸을 3장 만들어, 픽셀 단위 QA로 최고 1장을 골랐어요. 장당 7센트였습니다. 3장을 한참 들여다보다가 고른 건데, 픽셀 단위로 보면 차이가 제법 났습니다.

 

 

이 스틸을 첫 프레임으로 박고 모션 5종을 생성했습니다. 달리기, 춤추기, 앞으로 뛰어가기, 쪼그려앉기, 총쏘기예요. 121프레임짜리는 5분 전후, 81프레임짜리는 3.1분이었습니다. 다 합치면 약 21분입니다.

 

달리기부터 스트립과 애니메이션을 붙였습니다.

 

 

 

춤추기.

 

 

 

앞으로 뛰어가기.

 

 

 

쪼그려앉기.

 

 

 

총쏘기.

 

 

 

핑크 캐릭터라 처음에는 마젠타 키로 잘랐습니다. 그러자 캐릭터 몸통까지 함께 지워졌어요. 핑크 팬더의 몸은 마젠타 배경과 같은 색 계열이라 배경 판정 기준에 걸린 것입니다. 흰 배경 위에 올리면 몸통이 우수수 구멍 나는 게 그대로 보였죠. 그래서 만화 캐릭터의 상식대로 그린 스크린으로 다시 찍었습니다. 그린 키는 핑크를 건드리지 않고 배경만 지워요. 전 모션 그린 누수 0px에 bg_purity 1.0이었습니다.

 

달리기·춤·앞뛰기는 --loop로 루프 시임까지 탐지했습니다. GIF를 보면 각 모션이 끝날 때 캐릭터가 제자리로 돌아오는데, idle 핀이 딱 그 역할을 합니다. 프레임을 넘겨가며 일일이 확인했어요. 프레임 사이 캐릭터 일관성도 좋았고, 잘림이나 변형, 잔상이 없었습니다. 게임 애니메이션 자산으로 바로 쓸 수 있는 수준입니다.

남은 숙제

결과물 전반은 만족스러웠습니다. 다만 손가락이나 모션이 조금 더 역동적이었으면 좋겠다는 평이 나왔어요. 프롬프트로 어느 정도는 잡힐 걸로 봅니다. 추후 프롬프트 실험을 조금 더 해볼 생각이고, 성패와 상관없이 GPU 시간 몇 분이면 되는 실험이라 부담은 없습니다. 아직 확정은 아니니, 후속 테스트로 남겨뒀습니다.

 

파이프라인은 성립했습니다. 나노바나나가 스틸을 만들고, Wan 2.2 TI2V-5B가 모션을 만들고, sprite_cut이 키잉·키프레임을 맡습니다. 클립당 60센트였을 작업이 GPU 시간 몇 분으로 줄었어요. 외부 API 비용에 붙들리지 않아도 된다는 게 큽니다. 스킬은 MIT, Wan 2.2는 Apache-2.0이라 쓰는 데 거리낄 것도 없습니다.

 

L40 세 번째 GPU는 여유가 나면 실운영 자리로 다시 볼 만하고, 다음엔 2080 Ti에 GGUF 480p로 얹어볼지도 모르겠습니다. 느리겠지만, 상시 돌릴 수 있다는 게 값이에요. 모션을 더 뽑고 싶은 분은 직접 돌려보세요.