AI에게 스프라이트를 시킬 때 프레임 수를 계약으로 고정하기

여덟 번 다시 시켰다

캐릭터의 걷는 동작을 이미지 생성 모델로 만들려 했다. 4프레임 보행 사이클이면 충분했다.

일곱 번 반려하고 여덟 번째에 받았다. 반려 사유를 전부 기록해 뒀는데, 다시 읽어 보니 같은 실수가 반복되지 않았다. 매번 다른 이유로 틀렸다.

그 기록이 프롬프트를 고치는 재료가 됐다.

처음엔 방향부터 틀렸다

원래 아틀라스의 걷기 행이 이상해서 다시 만드는 작업이었다. 문제는 이랬다.

f1과 f3이 거의 동일한 차렷 자세 → 좌우 발 교대가 없어 보행으로 읽히지 않음
네 프레임 모두 팔이 몸 옆에 고정 → 팔 스윙 부재

첫 시도 결과다.

정면으로 생성됨 → 요구는 측면(오른쪽 향함) 보행
팔-다리 교차가 반대: 같은 쪽 팔과 다리가 함께 앞으로 나가는 동측 보행

사람은 걸을 때 오른팔과 왼다리가 같이 나간다. 반대로 그리면 어색한데 말로 설명하기는 애매하다. “contralateral arm-leg pairing”이라고 못 박아 넣었다.

텍스트로 안 되는 게 있다

두 번째, 세 번째 시도는 같은 문제로 반려됐다.

F1과 F3이 동일한 보폭 위상 (둘 다 같은 다리가 앞)
→ 다리 교대 없는 실질 2프레임 루프

“1번과 3번은 반대 다리가 앞으로 나와야 한다”를 여러 방식으로 적어 봤다. 안 통했다.

세 번째 시도 후에 이렇게 결론 냈다.

여전히 F1=F3. 텍스트 지시만으로는 보폭 교대가 전달되지 않음이 확인됨

대응이 두 가지였다.

포즈 가이드 이미지를 만들어 첨부했다. 참조 캐릭터 시트 한 장에 더해 포즈만 그린 가이드 한 장, 총 두 장 체제로 바꿨다.

판별 앵커를 지정했다. 캐릭터 허벅지에 스트랩이 있는데, 그걸 좌우 구분 기준으로 쓰게 했다.

F1: 스트랩 다리가 앞
F3: 스트랩 다리가 뒤

“반대 다리”는 모호하지만 “스트랩이 있는 다리”는 그림에서 확인된다. 모델이 볼 수 있는 표식을 기준으로 삼으면 지시가 검증 가능해진다.

명시 안 한 프레임은 모델이 채운다

다섯 번째 시도에서 8프레임으로 늘렸다. 결과가 역대 최선이었는데도 반려됐다.

측면·발 교대·F1/F5 위상 교대·품질 전부 ✓
F2·F6(리코일)에서 양손이 몸 앞에 모여 팔 스윙이 죽음. F4·F8도 팔 스윙 약함

원인을 찾아보니 프롬프트 문제였다.

원인: 프롬프트가 F1/F5/F4/F8에만 팔을 지시하고
      F2·F3·F6·F7은 팔 지시를 생략

지시가 없는 프레임에서 모델이 알아서 채웠고, 그 결과가 “손을 앞에 모으는” 자연스러운 정지 자세였다.

빠뜨린 곳은 비어 있지 않다. 모델이 그럴듯한 것으로 메운다. 그래서 8프레임 전부에 팔 위치를 명시하고, 금지 문구를 추가했다.

hands never meet or clasp in front

개념어가 다르게 해석된다

여섯 번째가 가장 배울 게 많았다.

F2·F6이 무릎을 깊게 접고 쭈그린 점프 준비 자세로 생성됨

프롬프트에는 이렇게 적혀 있었다.

recoil: weight sinks onto the front leg, body at its lowest point

애니메이션에서 recoil은 보행 중 몸이 살짝 내려앉는 순간을 뜻한다. 그런데 “가장 낮은 지점”을 문자 그대로 받으면 스쿼트가 된다.

개념을 아예 버렸다.

recoil 개념 폐기 → F2/F6을 "weight shift, 몸통 직립,
프레임 1과 같은 높이"로 재서술

전문 용어를 쓰면 그 분야 안에서만 통한다. 생성 모델은 그 단어를 다른 맥락에서도 학습했다. 결과로 판정할 수 있는 서술(“프레임 1과 같은 높이”)로 바꾸는 게 안전하다.

팔도 같은 이유로 바꿨다. “swing back(뒤로 흔들리기 시작)” 같은 전이형 서술 대신 앞/뒤 이분 위치로 고정했다. 전이형은 어느 정도인지가 모호하다.

검수를 수치로 한다

일곱 번째는 눈으로는 통과할 뻔했다.

쭈그림·양손 모임은 해결 ✓, 8프레임 전부 직립 ✓
아랫줄 F5–F8이 윗줄 F1–F4의 복제

두 줄로 배치된 8프레임에서 아랫줄이 윗줄을 복사한 것이었다. 미묘하게 달라 보여서 넘어갈 뻔했는데, 실루엣을 겹쳐 재 보니 명확했다.

미러 쌍 실루엣 IoU 0.96~0.98

IoU는 두 영역의 겹치는 정도다. 1에 가까우면 사실상 같은 그림이다. 0.96이면 복제로 봐야 한다.

“달라 보이는가”를 사람 눈으로 판정하면 놓친다. 알파 채널로 실루엣을 뽑아 겹쳐 보는 건 몇 줄이면 되고, 답이 숫자로 나온다.

기록이 프롬프트가 된다

이 작업에서 실제로 값이 있었던 건 프롬프트 자체가 아니라 반려 기록이었다.

문서 구조를 이렇게 뒀다.

## 0. 실패 기록 (이번 프롬프트가 고쳐야 하는 것)
   기존 아틀라스의 문제
   시도 1 — 리젝 사유 / 원인 / 대응
   시도 2 — 리젝 사유 / 원인 / 대응
   ...
## 1. 프롬프트 본문

프롬프트를 고칠 때마다 “왜 이 문장이 여기 있는지”가 위에 남는다. 없으면 나중에 길어진 프롬프트를 보고 정리하고 싶어지고, 정리하면 그 실수가 돌아온다.

hands never meet or clasp in front 같은 문장은 그냥 보면 이상하다. 시도 5의 기록이 있어야 지울 수 없다.

정리

• 반려 사유가 매번 달랐다. 한 번에 되는 프롬프트를 찾는 게 아니라 실패를 하나씩 막는 작업이다
• 위상 교대처럼 텍스트로 안 되는 게 있다. 포즈 가이드 이미지를 별도로 첨부한다
• 모델이 볼 수 있는 표식(스트랩 다리)을 판별 기준으로 삼으면 지시가 검증 가능해진다
• 지시를 빠뜨린 프레임은 비지 않는다. 모델이 그럴듯한 것으로 채운다
• 전문 용어(recoil)는 다른 맥락으로 해석된다. 결과로 판정 가능한 서술로 바꾼다
• 전이형 서술(“흔들리기 시작”) 대신 이분 위치로 고정한다
• 검수를 눈으로 하면 복제를 놓친다. 실루엣 IoU 같은 수치를 쓴다
• 프롬프트 위에 반려 기록을 남긴다. 없으면 정리하다가 실수가 돌아온다

프롬프트가 길고 이상해 보인다면, 그 문장 하나하나가 한 번씩 당한 흔적일 수 있다.