개요
지난 글에서 두 가지를 적었다. 3D 트랙이 모델링 최적화 검토와 기획자 판단으로 무산돼 2D 단일 트랙이 됐다는 것, 그리고 남은 2D 기획 패키지를 적대적으로 검토해 계약의 구멍을 찾았다는 것이다. 추격 실패 판정이 없었고, 추격자의 움직임을 아무도 소유하지 않았고, 통과시킬 수 없는 합격 기준이 셋 있었다.
검토는 문제를 목록으로 만들 뿐이다. 목록은 결정이 되지 않으면 아무것도 바꾸지 않는다.
이번 글은 그 목록을 결정으로 바꾸고, 결정을 문서가 아니라 명세에 직접 박고, 3인이 8일 동안 실제로 손댈 수 있는 상태까지 만든 기록이다. 그 과정에서 계획 하나가 통째로 뒤집혔다.
1. 결정을 AI가 대신하지 않게 한다
검토 목록에는 두 종류가 섞여 있었다.
- 답이 정해진 것 — 예: 데이터 스키마에 필드가 빠졌다. 그냥 넣으면 된다.
- 판단이 필요한 것 — 예: 추격자에게 닿으면 즉사인가, 체력이 깎이는가?
두 번째를 AI가 알아서 고르면 안 된다. 즉사와 피해는 이후 모든 밸런싱이 달라지는 갈림길이다. 그런데 문서만 보면 어느 쪽도 말이 되기 때문에, AI는 그럴듯한 쪽을 골라놓고 확정된 것처럼 적어버린다.
그래서 판단이 필요한 항목만 뽑아 선택지와 각 선택의 대가를 붙여 팀에 물었다. 총 14건이 확정됐다.
| 물어본 것 | 정해진 것 |
|---|---|
| 추격자에게 닿으면? | 피해 0, 붙잡히는 연출 후 체크포인트 복귀 |
| 추격의 길이는 누가 정하나? | 별도의 연출 관리자가 소유. 추격자는 실행만 |
| 이동 동작을 하나 더 넣을까? | 붙잡기·매달리기 추가 |
| 아트 방식은? | 픽셀 아트 |
| 접근성 옵션 범위는? | 최소 세트 (색 비의존 신호, 리매핑, 흔들림 끄기, 자막 크기, 추격 속도 저하) |
| 인물 이름은? | 이름을 주지 않는다. 호칭으로만 |
마지막 항목이 재밌었다. 원래 “주인공과 친구의 이름”은 미정 항목에 있었고, 그것 때문에 대사를 한 줄도 못 쓰는 상태였다. 한국어는 이름 없이도 대화가 자연스럽고, 이름을 부를 상대가 없다는 상태 자체가 주제와 맞는다. 미정 항목 하나가 결정이 아니라 삭제로 풀린 경우다.
2. 그리고 산수가 계획을 죽였다
제작 규모를 물었을 때 답이 이랬다.
개발자 3인 + AI 파이프라인, 최대 8일. 실질 개발 시간은 평일 2시간, 주말 10시간.
계산해봤다.
평일 6일 × 2시간 = 12시간
주말 2일 × 10시간 = 20시간
------------------------------
1인 32시간 × 3인 = 96 person-hour
원래 목표는 13스테이지, 4~5시간 플레이, 공간 상태 26개, 고유 추격 기믹 12개였다.
96을 13으로 나누면 스테이지당 7.4시간이다. 레벨 저작, 전투, 회상, 오염 공간, 추격, 오디오, 저장을 전부 포함해서다. 그리고 이건 공통 시스템 작업을 빼기 전 숫자다.
이 기한으로 13스테이지는 불가능하다.
여기서 중요한 것은 이 판단을 내가 조용히 내리지 않았다는 점이다. 범위를 줄이는 것은 팀의 결정이지 도구의 결정이 아니다. 산수를 그대로 보여주고 선택지를 물었다.
답은 Stage 1 세로 조각만 만든다였다.
3. 설계는 줄이지 않는다. 구현만 줄인다
여기서 흔한 실수가 하나 있다. 일정이 안 맞으면 기획서를 뜯어고쳐 13스테이지를 5스테이지로 줄이는 것이다.
그렇게 하면 진실이 공개되는 순서, 복선의 배치, 반복 학습의 횟수가 전부 무너진다. 설계 품질을 일정에 맞춰 깎는 셈이다.
그래서 반대로 갔다.
- 13스테이지 설계 계약은 그대로 보존한다. 한 줄도 지우지 않는다.
- 이번 8일에 구현할 범위만 Stage 1로 줄인다.
그리고 이 구분을 사람의 기억에 맡기지 않기 위해, 명세 15개 각각에 Build scope 절을 새로 넣었다. 그 명세가 이번 빌드에 들어가는지, 부분만 들어가는지, 통째로 미뤄지는지를 문서 스스로 선언한다.
## Build scope
- 8일 슬라이스: 부분 포함
- 슬라이스에서 구현한다: 기본 공격, 피격, 체력, 추격자 접촉 붙잡기
- 슬라이스에서 제외한다: 마지막 장면의 무장 해제
개발자든 AI 에이전트든 그 명세를 열면 이번에 뭘 만들고 뭘 안 만드는지가 첫 화면에 있다. 별도의 일정표를 찾아갈 필요가 없다.
4. 결정은 회의록이 아니라 명세에 박는다
확정된 14건을 결정 기록 문서에만 남기면 그 문서는 곧 아무도 안 읽는다. 그래서 명세 15개를 직접 고쳤다.
- 추격자 접촉 규칙을 전투 명세에 신설했다. 피해 0, 붙잡히는 연출, 화면 안에서만 시작, 재시도할 때마다 같은 길이.
- 추격 명세에 연출 관리자를 편입했다. 스테이지별 목표 추격 시간, 이동 속도, 유지 거리 상·하한, 플레이어가 멈춰도 안전하지 않다는 규칙, 막다른 길에서는 실패시키는 대신 물러난다는 규칙.
- 데이터 스키마에 빠져 있던 필드 3개를 넣었다. 이걸로 지난 글의 “통과시킬 수 없는 합격 기준 3개”가 전부 성립하게 됐다.
- 화면 프롬프트를 물리 키가 아니라 입력 액션 이름 + 문자열 키 참조로 바꿨다. 게임패드를 붙여도, 나중에 번역을 붙여도 안 깨진다.
명세 하나에서 특히 마음에 든 변화가 있다. 원래는 이랬다.
적 명세: “추격자 AI는 이 문서 범위 밖”
이제는 이렇게 적혀 있다.
적 명세: “추격자의 이동과 연출 관리자는 추격 명세가 소유한다”
같은 “내 일이 아니다”인데, 뒤엣것은 누구 일인지를 말한다. 책임을 밀어내는 문장과 넘겨주는 문장의 차이다.
5. 같은 사실이 세 곳에 있으면 반드시 어긋난다
문서를 고치고 나서 전체를 다시 훑었다. 그러다 웃긴 걸 발견했다.
“이번에 뭘 만드는가”가 세 군데에 적혀 있었다. 최상위 계약 문서, 결정 기록 문서, 그리고 각 명세의 Build scope 절.
착수 순서도 세 군데에 있었다. 그것도 서로 조금씩 달랐다.
그리고 이미 사고가 한 번 났다. 복원 규칙이 안내 문서와 저장 명세 양쪽에 있었는데, 추격 실패 판정을 새로 넣을 때 두 곳을 따로 고쳐야 했다. 하나를 놓쳤으면 그대로 어긋난 채 남았을 것이다.
그래서 사실마다 집을 하나씩만 정했다.
| 사실 | 단일 원본 |
|---|---|
| 시스템별 구현 범위 | 각 명세의 Build scope 절 |
| 착수·삭감 순서 | 안내 문서 |
| 왜 그렇게 정했나 | 결정 기록 문서 |
| 기계가 읽는 계약 | 최상위 계약 문서 |
| 스테이지 저작 내용 | 서사 설계 문서 |
나머지는 포인터로 바꿨다. 서사 설계 문서에서는 죽은 절 여섯 개를 지웠다. 사라진 이전 판본과 비교하던 절, 명세 목록을 베껴둔 표(이미 낡아 있었다), 바로 아랫 절과 완전히 겹치는 표, 그리고 새 범위 결정과 정면으로 충돌하던 제작 범위 절.
문서 4개에서 137줄이 사라졌다. 내용은 하나도 안 없어졌다.
문서는 길어서 위험한 게 아니라, 같은 사실이 여러 곳에 있어서 위험하다. 셋 중 하나만 고쳐지는 날이 반드시 온다.
6. 3인이 동시에 손대려면 먼저 정해야 하는 것들
여기까지는 “무엇을 만드는가”였다. 마지막은 “셋이 어떻게 동시에 만드는가”다.
이것도 판단이 필요한 것부터 물었다. 픽셀 규격, 저장소 방식, 분업 축, 브랜치 전략, 팔레트 방향.
픽셀 규격 — 나중에 못 바꾸는 값
내부 해상도 480×270, 캐릭터 32픽셀, PPU 32로 정했다. 480×270은 1920×1080의 정확히 4분의 1이라 정수배로 확대해도 픽셀이 뭉개지지 않는다.
캐릭터 크기가 논쟁거리였다. 24픽셀이 물량은 가장 적지만, 이 게임은 붙잡기와 무기를 내려놓는 동작이 핵심이다. 둘 다 손동작이다. 24픽셀에서는 손으로 뭘 하는지가 안 읽힌다. 32픽셀을 골랐다.
팔레트 — 오염을 다시 그리지 않는 방법
가장 마음에 드는 결정이다. 평상시 8색과 오염 상태 8색을 같은 인덱스로 대응시켰다.
평상시 지형 #b06b45 ↔ 오염 지형 #4a7183
평상시 소품 #e0954a ↔ 오염 소품 #7fa8b5
오염된 공간은 스프라이트를 새로 그리는 게 아니라 색 인덱스를 갈아끼운 것이다. 26개 공간 상태를 이 인력으로 감당할 방법이 이것뿐이다.
여기에 규칙을 하나 더 걸었다. 캐릭터 색은 두 상태에서 바뀌지 않는다. 주인공만 오염되지 않는다는 설정이 시각으로 그냥 드러난다.
씬 소유권 — Unity 협업 최대의 지뢰
Unity 씬과 프리팹은 실질적으로 병합이 불가능하다. 두 사람이 같은 씬을 만지면 한 명의 작업이 통째로 날아간다.
그래서 Stage 1 하나를 기본 공간 / 오염 오버레이 2개로 쪼개고 1인 1씬으로 소유권을 나눴다. 이건 새로 짜낸 규칙이 아니라, 앞서 오버레이 구조를 채택한 결정에서 그냥 따라 나온 것이다.
그리고 Git 설정에 이렇게 박았다.
*.unity -merge
*.prefab -merge
자동 병합을 아예 금지한다. 조용히 깨진 씬을 나중에 발견하는 것보다, 충돌로 그 자리에서 멈추는 편이 낫다.
첫날 2시간에 할 일
96시간에서 가장 큰 낭비는 서로를 기다리는 시간이다. 그래서 첫날 두 시간에 담당 A가 껍데기만 커밋한다. 이벤트 버스, 인터페이스, 상태 열거형, 문자열 조회 함수, 저장 데이터 필드. 알맹이는 비어 있어도 된다.
B와 C가 1일차부터 자기 코드를 컴파일할 수 있게 만드는 것이 목적이다.
7. 팔레트를 못 바꾸는 도구를 설득한 방법
마지막으로 도구 이야기 하나.
에셋 생성 파이프라인에는 게임별 팔레트를 고정하는 기능이 있다. 호출했더니 라임그린과 라벤더 조합이 나왔다. 상실과 병원을 다루는 게임에 쓸 색이 아니다.
다시 호출했다. 같은 색이 나왔다. 설명을 길게 붙여도 똑같았다.
코드를 열어보니 이유가 분명했다.
- 팔레트는 게임 ID + 스타일 문자열에서 결정적으로 유도된다
- 색을 직접 넣는 인자가 없다
- 한 번 정해지면 파일에 저장되고, 이후 호출은 저장된 값을 돌려준다
여기서 저장 파일을 손으로 고칠 수도 있었다. 안 했다. 그 파일은 초기화될 수 있는 런타임 출력이고, 손으로 쓴 값은 날아가면 시드 팔레트가 되살아난다.
대신 의도한 색이 나오는 문자열을 찾았다. 후보를 만들어 각각의 유도 결과를 비교했다.
artStyle = "pixel art hospital corridor"
→ 지형 #d37245 (노을 호박)
→ 강조 #73c6ed (병원 시안)
→ 그리드 32 (PPU 32와 일치)
호박과 시안이 정확히 보색이라, 의도한 대비가 유도 팔레트에서 그대로 나왔다. 문자열 자체가 의도를 기록하는 것도 좋았다.
걸린 제약도 있었다. 채도가 낮은 프로파일을 노렸더니 픽셀 그리드가 48로 떨어졌다. PPU 32와 충돌한다. 키워드 매칭 순서 때문에 둘을 동시에 만족시킬 수 없었다. 그리드를 지키고 채도를 포기했다.
도구가 원하는 값을 안 받아줄 때, 저장 파일을 손으로 고치는 것은 한 번은 통하고 다음 번에 사라지는 해결이다. 도구의 입력에서 답을 찾으면 재현된다.
8. 지금 상태
- 트랙은 2D 하나. 3D는 무산됐고 그 기획 산출물은 보관만 해둔다.
- 판단이 필요한 항목 14건 확정. 착수를 막던 미정 항목은 전부 사라졌다.
- 명세 15개에 결정 반영 완료. 통과시킬 수 없던 합격 기준 3개도 성립한다.
- 8일 구현 범위는 Stage 1 세로 조각. 13스테이지 설계는 그대로 보존.
- 픽셀 규격, 팔레트, Unity 폴더·씬 구조, 저장소 규칙, 3인 분업, 8일 일정 확정.
일정에서 가장 위험한 지점도 미리 표시했다. 토요일에 잡힌 오염 오버레이와 추격 연출 관리자다. 그날 막히면 그 주말이 통째로 날아간다. 그래서 그 하나에만 백업 인력 규칙을 걸어뒀다.
다음 글에서는 실제로 Stage 1이 브라우저에서 돌아가는지, 그리고 여기서 세운 규칙 중 무엇이 8일을 버티지 못했는지를 적을 생각이다. 계획과 결과가 다르면 다른 대로 남긴다.
한줄 평
- AI로 기획을 빠르게 만들 수는 있지만, 만들 수 있는 양은 여전히 사람 시간에 묶여 있다. 이번에 제일 값어치 있었던 작업이 화려한 자동화가 아니라 곱하기 나누기 한 번이었다는 게 좀 웃기면서도 오래 남을 것 같다ㅋㅋㅋㅋ