AI로 캐릭터 팩 만들기: 파일 1001개 에셋 파이프라인

첫 커밋이 파일 1001개였다

데스크톱 펫 캐릭터 팩을 만들면서 첫 커밋에 파일 1001개가 들어갔다. 22,210줄이 함께 올라갔다. 캐릭터 하나 분량이다.

AI로 이미지를 만들면 그림 그리는 시간이 줄어드는 건 맞다. 대신 다른 일이 늘어난다. 나온 이미지를 프레임으로 쓸 수 있게 다듬고, 크기와 위치를 맞추고, 그게 맞는지 확인하는 일이다. 이 글은 그 늘어난 일을 다룬다.

왜 파일이 그렇게 많아지나

스프라이트 시트 방식을 골랐기 때문에 동작 하나마다 프레임이 필요하다. 서 있기, 걷기, 손 흔들기, 말하기, 창틀 오르기 같은 상태가 각각 여러 장으로 이뤄진다.

거기에 프레임만 들어가는 게 아니다. 팩 하나를 뜯어보면 이런 것들이 함께 있다.

폴더	내용	크기	파일
sprites	실제로 런타임이 읽는 스프라이트	20M	4
provenance	이 프레임이 어떤 요청으로 어떻게 나왔는지 기록	115M	124
download	생성 원본	68M	46
qa	확인용 이미지와 대조 시트	14M	36
gifs	동작별 미리보기	4M	14
persona, rules	캐릭터 설정과 행동 규칙	—	—
CHECKSUMS.*.json	파일 무결성 검증값	—	—

숫자로 보면 분명하다. 앱이 실제로 읽는 건 sprites 20M, 파일 4개다. 나머지 199M과 220개는 그 4개를 만드는 과정에서 남았다. 프레임보다 부수 자산이 훨씬 많다.

생성 이력을 왜 남기나

AI로 이미지를 만들면 같은 프롬프트로 다시 돌려도 같은 그림이 나오지 않는다. 그래서 “이 프레임을 어떻게 얻었는지”를 적어두지 않으면, 나중에 한 장만 다시 만들어야 할 때 처음부터 다시 헤매게 된다.

그래서 프레임 묶음마다 요청 내용과 조건을 파일로 남겼다. 걷기 동작을 다시 만들 때 쓴 프롬프트, 빠진 4프레임을 채우려고 쓴 요청, 특정 동작을 비활성화한 이유 같은 것들이다.

이건 코드의 커밋 메시지와 같은 역할이다. 결과물만 남기면 나중에 왜 그렇게 됐는지 알 수 없다.

진짜 일은 생성 다음에 있었다

이미지가 나온 뒤에 하는 일이 훨씬 길었다. 팩 검증 파일에 정규화 버전이 남아 있는데, 57번까지 올라가 있다.

무엇을 반복했는지 몇 개만 옮기면 이렇다.

• 낙하산 동작 12프레임을 전부 실측해서 상태별 배율을 다시 잡았다. 그전에는 특정 행의 평균값을 썼는데, 착지할 때 크기가 튀었다
• 손 흔들기와 말하기 프레임 중 1번과 3번이 가로로 어긋나 있어서 발과 몸 기준점을 고정하려고 -5px, +6px씩 옮겼다
• 옆으로 총 쏘는 동작은 몸통 기준으로 맞췄더니 발이 미끄러져서, 양발 기준으로 다시 잡고 프레임마다 픽셀을 조정했다
• 창틀과 기둥에 남은 굵은 선을 1픽셀로 정리했다. 캐릭터의 색 있는 픽셀은 건드리지 않도록 보호하면서 지웠다

전부 픽셀 단위 이야기다. AI가 만든 그림은 프레임끼리 크기와 위치가 미묘하게 다르다. 그대로 이어 붙이면 캐릭터가 제자리에서 떨리거나, 착지할 때 갑자기 커지거나, 걷는데 발이 미끄러진다.

눈으로 확인할 수 있게 만들어 뒀다

픽셀 단위 조정은 숫자만 봐서는 맞는지 알 수 없다. 그래서 동작마다 GIF와 대조 시트를 만들어 두고, 조정한 결과가 실제 런타임 프레임과 같은지 확인하는 과정을 넣었다.

바꾼 뒤에 확인용 이미지를 다시 만들지 않으면, 고쳤다고 생각한 것이 실제로는 안 고쳐졌는지 알 수 없다. 57번을 반복하는 동안 이 확인 단계가 매번 붙었다.

파일이 많다는 건 관리 대상이 많다는 뜻이다

파일 1001개는 그 자체로 문제가 되지는 않는다. 문제는 그중 하나가 잘못됐을 때 알아채기 어렵다는 데 있다.

그래서 팩에 체크섬 파일을 넣었다. 런타임이 팩을 읽을 때 파일이 바뀌었는지 확인할 수 있게 했고, 스프라이트 매니페스트가 애니메이션 규격에 맞는지도 로딩 단계에서 검사한다.

수작업으로 몇 장 그리던 규모라면 필요 없었을 장치다. 자동 생성으로 규모가 커지면 검증도 자동으로 붙어야 한다.