개요
지난 글에서는 하나의 스토리를 2D와 3D로 나눠 각각 MVP를 만든 뒤, 플레이해보고 더 나은 쪽을 고르겠다고 적었다.
그 비교는 실행되지 않았다. 3D 트랙은 MVP를 만들기 전에 무산됐다.
계획과 결과가 다르면 다른 대로 남기겠다고 했으니 그 이야기부터 적는다. 그리고 남은 2D 쪽 기획이 1차 완료됐다.
최상위 게임 계약 문서 하나, 스테이지별 서사 설계 문서 하나, 기능 명세 15개. 분량으로 보면 꽤 그럴듯한 패키지가 나왔다.
그런데 여기서 한 가지를 확인해야 했다.
“기획이 완성됐다”와 “이 기획으로 만들 수 있다”는 전혀 다른 말이다.
그래서 다음 작업을 구현이 아니라 적대적 검토로 잡았다. 잘 쓴 부분을 확인하는 검토가 아니라, 이 문서로 개발을 시작하면 어디서 멈추게 되는지를 찾는 검토다.
이 글은 그 검토 과정과, 판정 근거를 어디서 가져왔는지에 대한 기록이다. 스토리 내용은 여전히 큰 흐름만 적는다.
1. 두 갈래 중 하나가 비교 전에 접혔다
지난 글의 계획은 분명했다. 2D와 3D MVP를 같은 하이라이트 장면과 같은 질문으로 만들고, 플레이해본 결과를 선택의 근거로 삼는다.
그 계획은 지켜지지 않았다. 3D는 MVP 단계에 들어가기 전에 정리됐다.
① 모델링 최적화 검토가 먼저 걸렸다
3D 방향은 1인칭 좁은 공간이라 넓이 부담은 작았다. 문제는 넓이가 아니라 에셋의 종류였다.
2D에서 스프라이트 한 장이면 끝나는 자리에, 3D는 모델·텍스처·머티리얼·리깅·라이팅·최적화가 한 묶음으로 따라온다. 그리고 이 묶음은 AI 파이프라인이 2D 스프라이트만큼 안정적으로 뽑아주지 못한다. 생성된 결과를 게임에 넣을 수 있는 상태로 만드는 구간에서 사람 손이 계속 필요했다.
즉 AI로 줄어드는 구간이 2D 쪽이 훨씬 넓었다. 같은 시간을 넣어도 3D는 검증 가능한 플레이가 나오기까지 더 멀었다.
② 그리고 기획자가 판단했다
최적화 검토는 “비싸다”까지만 말해준다. 접을지 말지는 기획자의 판단이었고, 결론은 2D 단일 트랙이었다.
이 게임이 요구하는 핵심 경험이 “방금 지나온 길을 반대로 되짚어 달리는 것”인데, 그 길이 한눈에 보이는 형식이 횡스크롤이라는 판단이었다. 1인칭은 시선을 좁히는 데 강하지만, 왔던 길과 지금 도망치는 길이 같은 길임을 즉시 알려주기에는 불리하다.
③ 계획이 틀렸다고 보진 않는다
“플레이해보고 고른다”는 원칙은 이번에 적용되지 않았다. 그건 그대로 적어둔다.
다만 두 갈래를 놓고 검토한 것이 낭비였냐면 그렇지 않다. 3D를 아예 보지 않았다면 2D 선택은 “그것밖에 없어서”가 됐을 것이다. 지금은 무엇을 포기하고 고른 것인지가 남았다. 3D 쪽 기획 산출물도 지우지 않고 보관해뒀다.
여기서 배운 것은 따로 있다. 비교 실험은 양쪽이 같은 출발선에 설 수 있을 때만 성립한다. 제작 비용 구조가 다르면 플레이해보기 전에 예산이 답을 정해버린다. 두 형식을 비교하려면 “무엇을 만들 것인가”보다 “각각 첫 플레이까지 얼마나 걸리는가”를 먼저 재봤어야 했다.
이 글의 나머지는 살아남은 2D 기획을 검토한 기록이다.
2. 왜 칭찬이 아니라 공격부터 하는가
AI에게 기획서를 검토시키면 대체로 잘 읽힌다는 평가가 돌아온다. 문서가 문법적으로 매끄럽고 구성이 갖춰져 있으면 더 그렇다.
문제는 기획서의 품질과 개발 가능성이 다른 축이라는 점이다. 문장이 아름다워도 “적에게 잡히면 어떻게 되는가”가 안 적혀 있으면 개발자는 그 자리에서 멈춘다.
그래서 검토 기준을 세 가지로 못 박았다.
| 기준 | 확인하는 것 |
|---|---|
| 계약 검증 가능성 | 이 합격 기준을 기계가 통과시킬 수 있는가 |
| 시스템 책임 공백 | 이 기능을 누가 소유하는지 명세에 적혀 있는가 |
| 페이싱·상업 리스크 | 중반에 플레이어가 떠날 이유가 있는가 |
“재미있는가”는 일부러 넣지 않았다. 재미는 플레이해봐야 알고, 지금 단계에서 물어봐야 답이 감상밖에 안 나온다.
3. 서사가 아니라 계약이 깨져 있었다
검토 결과가 예상과 반대였다.
이 게임의 큰 흐름은 이렇다. 주인공이 기억을 되찾을수록 억눌린 현실이 같은 공간으로 역류하고, 방금 지나온 길을 반대로 달아나게 된다. 그 도주를 여러 번 반복해 몸에 익힌 뒤, 마지막에 처음으로 돌아서서 두려운 쪽으로 걸어간다.
이 서사 축은 구멍이 없었다. 진실이 공개되는 순서, 복선을 회수하는 위치, 마지막 장면의 절차까지 촘촘했다.
깨진 곳은 액션 계약이었다.
① 추격에서 잡히면 무슨 일이 일어나는지 아무도 안 적었다
이 게임은 도주가 핵심 반복이다. 그런데 명세 15개 어디에도 추격자에게 닿았을 때 무슨 일이 일어나는지가 없었다.
명세에는 “플레이어가 추격자를 공격해도 소용없다”만 있었다. 반대 방향, 즉 추격자가 플레이어에게 무엇을 하는지는 비어 있었다.
즉사인가? 체력이 깎이는가? 붙잡히는 연출이 있는가? 이걸 정하지 않으면 추격 난이도라는 개념 자체가 성립하지 않는다. 도주 게임에서 이건 작은 누락이 아니라 바닥이 없는 상태다.
② 추격자의 움직임을 아무도 소유하지 않았다
더 이상한 것이 있었다.
- 적 명세: “추격자 AI는 이 문서 범위 밖” — 명시적으로 배제
- 추격 명세: 출현 위치와 도주 방향만 다루고 이동 규칙은 없음
- 연출 명세: “추격자와의 거리에 따라 카메라 압박을 조절한다”
세 번째가 문제다. 정의된 적 없는 값을 소비하고 있었다. 각 문서는 자기 범위를 성실히 지켰는데, 그 사이에 아무도 줍지 않은 책임이 떨어져 있었다.
이건 사람이 나눠 쓴 문서에서도 흔하지만, AI가 문서를 여러 개로 나눠 쓸 때 더 잘 생긴다. 각 문서가 국소적으로는 완결돼 보이기 때문이다.
③ 통과시킬 수 없는 합격 기준 3개
명세에는 자동 테스트 이름이 붙은 합격 기준이 있었다. 그중 셋은 원리적으로 통과시킬 수 없었다.
예를 들어 “병원 이미지의 직접성이 스테이지 순서대로 강해지는지 검사한다”는 기준이 있었다. 그런데 그 ‘직접성’ 값은 산문 문서에만 있고, 데이터 스키마의 필수 필드 목록에는 없었다.
기계가 존재하지 않는 값을 검사하게 되어 있었던 것이다.
자동 검증을 붙였다는 사실이 검증이 된다는 뜻은 아니다. 테스트 이름은 계약처럼 보이지만, 읽을 데이터가 없으면 문장일 뿐이다.
4. 감이 아니라 근거로 — RAG를 반대로 쓰기
여기서 검토를 “제 생각에는 중반이 지루할 것 같습니다”로 끝내면 기획자가 받아들일 이유가 없다. 취향 싸움이 된다.
그래서 게임 디자인 리서치 저장소의 카드 DB를 평소와 반대 방향으로 썼다.
보통 RAG는 “이렇게 만들면 성공한다”는 근거를 찾는 데 쓴다. 이번에는 “이렇게 만들면 실패한다”를 먼저 찾았다. 리서치 저장소가 성공 사례뿐 아니라 실패·혼재 사례와 각 카드의 리스크 절을 함께 모으는 이유가 여기에 있다.
검색 결과 세 장이 이 기획을 정확히 겨눴다.
반복은 콘텐츠가 아니다
마지막 장면에서 플레이어는 도주를 반복하다가 스스로 돌아서야 한다. 그런데 그 반복 구간은 설계상 새로 주는 정보가 하나도 없었다.
DB의 루프 메커니즘 카드에는 이런 리스크가 적혀 있다. 반복 자체는 콘텐츠가 아니며, 매 반복마다 새 정보·새 대사·새 성장 중 최소 하나가 갱신되어야 한다는 것이다. 그리고 시간 루프를 다룬 어느 실패 사례 게임의 불만 키워드 1위가 “막히면 루프 전체를 처음부터 다시” 였다.
우리 설계는 그 실패 형태와 모양이 같았다. 힌트는 카메라 연출 한 번이 전부였고, 저장 필드도 “힌트를 봤는가” 참·거짓 하나였다.
분위기는 진입 조건이지 유지 조건이 아니다
적은 세 종류인데 그게 전부 초반에 등장하고, 이후 여덟 스테이지 동안 새로운 전투 요소가 하나도 없었다. 플레이어 능력도 처음부터 끝까지 그대로다.
DB에는 어느 횡스크롤 호러 속편의 사례가 있다. 분위기와 비주얼은 호평받았지만 추격자와 환경의 창의성 부족, 반복되는 공식이 지적되며 시리즈 최저 평가를 받았다. 그 카드의 결론 한 줄이 이랬다.
분위기는 진입 조건이지 유지 조건이 아니다.
이야기를 이해하기 전에 이동이 만족스러워야 한다
가장 가까운 성공 레퍼런스는 이미 DB에 들어 있었다. 서사로 호평받은 2D 액션 게임인데, 그 카드의 결론은 “반전을 넣어라”가 아니었다.
핵심 이동이 플레이어가 이야기를 다 이해하기 전에 이미 만족스러워야 한다는 쪽이었다. 그 게임은 상징적인 이동 동작 하나가 이동·전투·주인공의 정체성을 동시에 감당한다.
우리 기획의 도주 동작은 “달리기” 하나였다. 그리고 웃긴 것은, 어느 스테이지의 기믹 설명에 이미 “미끄러질 때 난간을 붙잡아 균형을 회복한다”가 적혀 있었다는 점이다. 존재하지 않는 동작을 기획서가 스스로 요구하고 있었다.
5. 한글로 물었더니 검색이 통째로 헛돌았다
이번에 실무적으로 가장 뼈아팠던 것은 따로 있다.
처음에 검색을 한국어로 던졌다. 결과가 이상했다. “처치 불가능한 추격자”를 물었는데 픽셀아트 오픈월드 샌드박스 카드가 최상위로 나왔다.
원인은 단순했다. 리서치 카드 본문은 이전 작업에서 영어로 통일했는데, 이번 환경에서는 의미 기반 벡터 검색이 꺼져 있어 글자 단위 유사도 검색만 돌고 있었다. 한국어 질의와 영어 본문은 글자가 겹칠 일이 없다.
즉 검색이 실패한 게 아니라, 실패했다는 사실조차 알려주지 않고 무관한 결과를 성실하게 돌려준 것이다.
질의를 영어로 바꾸자 같은 DB에서 필요한 카드가 정확히 상위로 올라왔다.
검색이 빈 결과를 주면 사람은 이상하다고 느낀다. 그런데 그럴듯한 오답을 주면 그대로 믿는다. 검색 방식과 자료의 언어가 어긋났을 때가 정확히 그 상황이다.
이건 RAG를 쓰는 팀이라면 한 번은 밟는 지뢰라고 생각한다. 자료를 영어로 통일하는 결정 자체는 옳았지만, 그 결정이 질의 언어까지 구속한다는 사실은 따로 적어두지 않았다.
6. 없는 카드는 만들지 말고, 정말 없을 때만 만든다
검토를 마치고 나니 DB에 근거가 아예 없는 주제가 셋 남았다.
- 처치할 수 없는 추격자를 반복해서 등장시키는 설계
- 난이도·접근성 옵션
- 같은 공간을 두 가지 상태로 유지하는 레벨 구조
세 번째가 이 게임의 최대 제작 리스크였다. 스테이지마다 평상시 공간과 오염된 공간이 필요하니 최소 26개의 공간 상태가 나오는데, 그걸 어떻게 만들지가 명세에 0줄이었다.
여기서 팀에서 나온 지적이 중요했다.
“카드 만들지 말고 있던 DB에서 끌어와라.”
맞는 지적이다. 새 지식을 만드는 것은 마지막 수단이어야 한다. 그래서 먼저 기존 카드로 채울 수 있는 만큼 채우고, 그러고도 남은 것만 새로 만들었다.
그 결과 실제로 새로 쓴 카드는 위 세 장뿐이다. 나머지 결함은 이미 있던 카드로 전부 근거를 댈 수 있었다.
카드를 쓸 때는 저장소의 기존 절차를 그대로 따랐다. 사실에는 출처와 확인 날짜를 붙이고 추론에는 해석 표시를 붙인다. 그리고 형식 검사, 절 검사, 링크 감사, DB 동기화, 임베딩, 최종 검증까지 통과시켰다.
- 카드 형식 검사 3장 통과
- 전체 카드 180장 · 절 914개 검사 통과
- 링크 감사에서 한쪽만 걸린 링크 0건
- DB 미해결 참조
unresolved_refs: 0
링크 감사에서 하나가 걸렸다. 새로 쓴 아키텍처 카드를 아무도 참조하지 않아 검색으로 도달할 수 없다는 지적이었다. 카드를 잘 써도 다른 카드가 가리키지 않으면 없는 것과 같다. 관련 카드에서 역방향 링크를 걸어 해소했다.
7. 이번 검토에서 배운 것
① AI가 나눠 쓴 문서는 사이가 빈다
각 문서가 자기 범위를 성실히 지킬수록, 아무도 자기 범위라고 주장하지 않는 영역이 생긴다. 사람이 쓸 때도 생기지만 AI는 “이건 내 문서 밖”이라고 적는 데 거리낌이 없어서 더 잘 생긴다.
그래서 검토할 때 각 문서를 따로 읽으면 못 찾는다. 한 문서가 소비하는 값을 다른 문서가 정의하는지 교차로 봐야 나온다.
② 테스트 이름은 계약처럼 보이지만 계약이 아니다
자동 검증 항목이 붙어 있으면 검증되고 있다고 착각하기 쉽다. 검사할 데이터가 스키마에 없으면 그건 그냥 잘 쓴 문장이다.
③ 근거는 판정을 취향 싸움에서 꺼낸다
“중반이 지루할 것 같다”는 반박 가능한 감상이다. “분위기는 유지 조건이 아니라는 사례가 있고, 우리 설계는 여덟 스테이지 동안 새 요소가 0이다”는 확인 가능한 지적이다.
RAG를 성공 사례 검색기로만 쓰면 이 힘이 안 나온다. 실패 사례를 같이 모아둔 DB라야 검토에 쓸 수 있다.
한줄 평
- 두 갈래를 다 만들어보고 고르겠다는 계획은 한쪽의 제작 비용 앞에서 먼저 접혔다. 아쉽지만 접는 판단이 늦었으면 8일이 아니라 두 배로 늦었을 것이라 지금은 잘 접었다고 본다.
- 기획을 AI로 빠르게 뽑는 것보다, 뽑힌 기획을 어디까지 믿을지 정하는 절차가 더 중요해지는 것 같다. 다음 글에서는 이 검토 결과를 실제 결정으로 바꾸는 과정과, 그 과정에서 계획 하나가 산수 때문에 통째로 뒤집힌 이야기를 적는다.