개요
지난 글에서는 13스테이지 기획과 8일 96 person-hour가 맞지 않는다는 사실을 확인하고, 구현 범위를 줄인 과정을 적었다.
계획을 줄였다고 바로 제작이 정리된 것은 아니었다.. 역할을 나눈 문서를 보고도 각자 생각한 범위가 달랐고, 실제 제출물을 만들기 위해 스테이지를 한 번 더 압축하게 되었다.
나는 Role A를 맡아 spec을 기준으로 코어 기능을 구현하고, 캐릭터 애니메이션 에셋을 만들어 Unity에 적용했다. 이번 글에서는 마지막 날 디버깅 직전까지 했던 두 작업을 정리하려한다!
이번 글이 답할 질문은 하나다. 역할과 범위를 미리 나눴는데도 실제 제작은 왜 계획대로 흘러가지 않았고, AI로 만든 이미지 한 장은 왜 바로 애니메이션이 되지 못했을까?
1. 같은 역할표에서도 나온 소통의 부재
협업 문서에서 Role A는 시스템과 플레이어를 맡았다. 상태, 입력, 이동, 잡기, 전투, 상호작용, 저장과 Scene 흐름이 내 범위였다.
내 작업 방식은 단순했다.
spec 확인
→ AI에게 코어 기능 구현 요청
→ Unity 프로젝트에 적용
→ 동작 확인
Role B는 추격과 레벨을 맡았다. 나는 이 역할을 Stage 1을 실제로 플레이할 수 있을 만큼 상세하게 설계하고 구현하는 범위로 이해하고 있었다.
그런데 작업이 진행된 뒤 Role B 담당자와 이야기를 나눠보니, 서로 역할 범위를 다르게 이해했던 것으로 보였다. 실제 Role B 작업은 Stage 1 하나보다 전체 Stage 1~13의 설계 방향을 다루는 쪽으로 진행되고 있었다.
누가 맞고 틀렸다는 문제는 아니었다. 같은 문서에 역할 이름과 담당 기능은 적혀 있었지만, 한 스테이지를 얼마나 깊게 만들지와 전체 스테이지를 어디까지 다룰지는 서로 다르게 읽고 있었다…
| 내가 이해한 Role B 범위 | 실제로 진행된 방향 |
|---|---|
| Stage 1 상세 설계와 구현 | Stage 1~13 전체 설계 방향 |
| 하나의 세로 조각을 깊게 완성 | 전체 게임 흐름을 넓게 연결 |
역할 이름을 나누는 것만으로는 부족했다. 깊이와 범위까지 같은 문장으로 확인했어야 했다.
2. 숫자가 아니라 시작·중간·엔딩만 남겼다
남은 시간에 13개 Stage를 모두 구현하기는 어려웠다. 결국 실제 제출물의 경험을 세 덩어리로 다시 압축했다.
| 최종 Scene | 게임에서 맡은 역할 |
|---|---|
| Stage 1 | 시작 |
| Stage 10 Scene | 중간 |
| Stage 13 | 엔딩 |
여기서 Stage 10은 기획상의 열 번째 Stage가 중요해서 선택한 것이 아니다.
실제 중간 Scene은 Stage 06 blockout을 베이스로 제작했다. 저장소의 Git 기록에도 Stage06의 Encounter, 출구 잠금, marker, 추격 연결을 복제해 Stage10_Base를 만들고, 아트를 다시 입힌 과정이 남아 있다. Scene 이름만 Stage 10으로 남은 셈이다.
중요한 것은 숫자가 아니었다.
시작
→ 중간
→ 엔딩
13개의 번호를 모두 채우는 대신, 플레이어가 게임의 출발과 변화, 끝을 경험할 수 있는 구조만 남겼다.
Stage 10을 고른 것이 아니라, 시작과 엔딩 사이를 이어줄 중간 경험을 남긴 것이다.
3. Role A의 코어 기능 — spec을 코드로 옮기기
내가 맡은 첫 번째 작업은 코어 기능 구현이었다.
상태, 입력, 이동, 잡기, 전투, 상호작용, 저장과 Scene 흐름처럼 게임의 뼈대가 되는 기능을 spec에서 확인하고 AI에게 구현을 요청했다.
AI에게 막연히 “게임을 만들어줘”라고 한 것은 아니다. spec에 적힌 책임과 동작을 기준으로 코드를 작성하게 하고, 그 결과를 Unity 프로젝트에 적용했다.
| 단계 | 내가 한 일 | AI가 한 일 |
|---|---|---|
| 요구사항 확인 | 구현할 spec과 범위를 선택 | spec 문맥을 읽음 |
| 구현 | 필요한 동작과 연결 지점을 요청 | C# 코드 작성 |
| 적용 | Scene, Prefab, Inspector와 연결 | 코드 수정 보조 |
| 확인 | Unity에서 실제 동작 점검 | 발견된 문제의 수정안 제안 |
이 방식은 코드를 빠르게 만드는 데에는 확실히 도움이 됐다. 다만 마지막 열의 “실제 동작 점검”은 코드만 읽어서는 끝나지 않았다.
Unity에서는 같은 코드라도 어떤 GameObject에 붙였는지, Collider와 Parameter가 어떻게 설정됐는지에 따라 결과가 달라진다. 이 문제는 마지막 날 디버깅에서 더 크게 드러났고, 다음 글에서 따로 다룬다.
spec은 AI가 코드를 시작할 기준이 됐지만, Unity에서 끝까지 동작한다는 보증까지 대신해주지는 않았다.
4. PixelLab.ai — 공격이 새 날갯짓이 됐다
두 번째 작업은 횡스크롤 사이드뷰 캐릭터의 애니메이션 에셋 제작이었다.
먼저 PixelLab.ai의 애니메이션 기능을 사용했다. 당시 이 기능은 Beta였고, 원본 이미지를 잘 넣어도 결과가 안정적이지 않았다.
특히 공격 모션이 문제였다. 공격 동작을 요청했는데 캐릭터가 상대를 때리거나 무기를 휘두르는 대신, 양팔을 새 날개처럼 위아래로 퍼덕였다.
단순히 화질이 낮은 문제가 아니었다. 프레임을 이어봐도 “공격한다”는 행동의 의미가 읽히지 않았다. 픽셀이 조금 흐린 이미지는 보정할 수 있지만, 동작 자체가 다르면 애니메이션으로 사용할 수 없다.
정지 이미지에서는 캐릭터의 모양이 맞는지가 중요하다. 애니메이션에서는 여기에 한 가지가 더 붙는다. 앞 프레임에서 다음 프레임으로 넘어갈 때 무슨 행동인지 읽혀야 한다.
보기 좋은 프레임을 만드는 것과 행동이 읽히는 프레임을 만드는 것은 다른 작업이었다.
5. GPT를 섞자 pose는 나왔지만 캐릭터가 바뀌었다
이전에 봤던 Codex로 Unity 게임 개발하기 자료에서는 GPT로 게임 에셋을 만들었는데 품질이 괜찮았다. 그 경험을 떠올려 PixelLab.ai만 사용하지 않고 GPT를 함께 사용해보기로 했다.
GPT에는 세 가지를 요청했다.
- 캐릭터의 기본 상태 만들기
- 공격이나 점프처럼 원하는 pose 만들기
- 동작 사이가 어색한 중간 frame 보정하기
원하는 pose 자체는 잘 나왔다.
문제는 여러 장을 이어놓았을 때였다. 프레임마다 색감과 몸의 비율이 크게 달라졌다. 같은 옷과 머리 모양을 요청해도 어떤 프레임은 아예 다른 캐릭터처럼 보였다.
애니메이션은 한 장씩 따로 보면 괜찮아도, 빠르게 이어서 재생하면 작은 차이가 크게 보인다. 얼굴 크기가 달라지면 캐릭터가 흔들리는 것처럼 보이고, 옷 색이 바뀌면 장면마다 조명이 번쩍이는 것처럼 보인다.
그래서 원하는 pose를 다시 만들고, 색을 맞추고, 몸 비율을 보정하는 작업을 여러 번 반복했다.
최종 결과는 IDLE / RUN / JUMP / ATTACK / GRAB 다섯 동작으로 정리했다. Unity 프로젝트에는 idle 5장, move 8장, jump 6장, attack 8장, grab 4장으로 총 31개 frame이 연결됐다.
Unity 적용 과정에서는 큰 문제를 발견하지 못했다. 31개 frame을 Sprite로 import하고 기존 Animator 상태에 연결한 뒤, 순서와 재생 시간을 확인했다. 프로젝트의 QA 기록에서도 frame mapping, PlayMode 동작, 최종 build가 통과했다.
좋은 이미지 한 장을 만드는 것과 같은 캐릭터의 애니메이션 여러 장을 만드는 것은 다른 문제였다.
정리
- 역할 분배: 나는 Role A를 맡았고, spec을 기준으로 코어 기능 구현을 AI에게 요청했다.
- 범위 차이: Role B 담당자와 대화한 뒤 Stage 범위를 서로 다르게 이해했던 것으로 보였다.
- Stage 압축: 13개 번호를 채우는 대신 Stage 1, Stage 10 Scene, Stage 13으로 시작·중간·엔딩을 남겼다.
- Stage 10의 실제 기반: 기획상의 열 번째 Stage를 고른 것이 아니라 Stage 06 blockout을 바탕으로 중간 Scene을 만들었다.
- PixelLab.ai: 공격 요청이 양팔을 새처럼 퍼덕이는 동작으로 나와 행동의 의미를 읽기 어려웠다.
- GPT 혼용: 원하는 pose는 얻었지만 frame마다 색감과 몸 비율이 달라 반복 보정이 필요했다.
- Unity 적용: 최종 31개 frame을 Animator에 연결했고, 적용 과정에서는 큰 문제를 발견하지 못했다.
참고 자료
한줄 평
- 계획을 역할 이름과 Stage 번호로 나누는 것보다 같은 방향성과 같은 캐릭터를 끝까지 유지하는 일이 더 어려웠다..!