작업을 시작하기 전에 ‘하지 않을 일 목록’부터 쓰기: 첫 작품이 통제 불능에 빠지는 것을 막는 방법

첫 인터랙티브 영상 게임에서 가장 흔한 실패는 창의력이 부족한 것이 아니라 모든 좋은 아이디어를 첫 버전에 넣는 것입니다. 캐릭터, 장면, 분기, 게임플레이, 플랫폼이 계속 늘어나 결국 어느 부분도 완성하지 못합니다. 해결책은 전체 대본을 쓰기 전에 ‘하지 않을 일 목록’을 만들고 각 상한에 적용할 조건을 정하는 것입니다.

하지 않을 일 목록은 소극적으로 내용을 덜어내기 위한 것이 아닙니다. 프로젝트가 플레이어에게 한 가장 중요한 약속을 지키고, 한정된 예산을 실제로 검증해야 할 부분에 집중하게 합니다.

첫째는 완성 영상의 분량입니다. 여기에는 플레이어가 한 번의 플레이에서 보는 길이뿐 아니라 서로 중복되지 않는 영상의 총분량을 기록해야 합니다. 한 번의 플레이가 15분이어도 완전히 독립된 경로가 세 개라면 40분 이상의 영상이 필요할 수 있습니다.

둘째는 주요 캐릭터입니다. 캐릭터가 한 명 늘 때마다 배우 일정 조율, 의상과 분장, 대사 조합, 자막, 현지화, 테스트할 상태가 늘어날 수 있습니다.

셋째는 장면입니다. 장면은 장소뿐 아니라 같은 장소에서 시간, 세트 구성, 파손 상태가 달라질 때 생기는 제작상의 변화도 포함합니다.

넷째는 핵심 선택과 엔딩입니다. 선택의 수가 곧 품질은 아닙니다. 첫 버전에서는 소수의 선택에 정보, 대가, 피드백이 있도록 하는 것을 우선해야 합니다.

다섯째는 시스템입니다. 관계, 증거, 자원, QTE, 단서 수색, 자유 입력, AI 대화를 모두 동시에 핵심으로 삼을 수는 없습니다. 주 시스템 하나를 선택하고 보조 시스템은 최대 하나만 추가하세요.

여섯째는 플랫폼입니다. PC, Web, 모바일은 입력 방식, 영상 형식, 성능, 저장 공간, 배포에서 차이가 있습니다. 첫 버전에는 주 플랫폼 하나를 두는 것이 좋습니다.

어떤 기능을 미룬다고만 말하지 마세요. 곧 다른 이름으로 돌아올 수 있기 때문입니다. 첫 버전에 반드시 포함할 것, 검증에 성공한 뒤 할 것, 명확히 하지 않을 것이라는 세 가지 목록을 만드세요.

‘검증에 성공한 뒤 할 것’에는 실행 조건도 적어야 합니다. 예를 들어 3분짜리 프로토타입에서 테스터 최소 네 명이 증거 시스템을 이해할 수 있을 때만 두 번째 단서 유형을 추가하고, 저사양 기기에서 영상 전환이 안정적일 때만 더 높은 해상도를 추가하며, 메인 스토리 전체에 도달할 수 있을 때만 숨겨진 엔딩을 추가합니다.

실행 조건이 없는 할 일은 감정에 따라 요구사항을 늘리는 일이 됩니다.

《零点回拨》의 약속은 플레이어가 미래에서 걸려 온 전화와 캐릭터 증언의 신뢰성을 판단하고 자정 이후의 결과를 바꾸게 하는 것입니다. 따라서 첫 버전에는 검증 가능한 예언, 입장이 서로 다른 캐릭터 최소 두 명, 범위가 제한된 시간 변수 하나, 신뢰와 증거가 함께 결정하는 여러 결과가 반드시 있어야 합니다.

자유롭게 이동할 수 있는 3차원 고객 서비스 센터가 있을 필요도, 플레이어가 임의의 질문을 입력할 수 있을 필요도, 회사 업무 전체를 시뮬레이션할 필요도 없습니다. 이런 기능은 흥미로울 수 있지만 핵심 약속을 직접 입증하지는 않습니다.

팀이 어떤 기능을 두고 논쟁할 때는 세 가지를 물어볼 수 있습니다. 이것을 빼도 플레이어가 핵심 행동을 수행할 수 있는가? 이것을 빼도 엔딩이 플레이어의 행동을 반영할 수 있는가? 이것을 빼도 3분짜리 프로토타입으로 가장 큰 위험을 검증할 수 있는가? 세 답이 모두 ‘그렇다’라면 첫 버전에 넣지 않아야 합니다.

‘규모를 너무 키우지 말자’는 실행에 도움이 되지 않습니다. 범위 표를 사용하세요.

숫자는 프로젝트에 맞게 조정할 수 있지만, 상한을 넘으면 예산, 날짜 또는 다른 범위도 함께 조정해야 합니다. 팀이 야근으로 흡수할 것이라고 당연하게 여겨서는 안 됩니다.

첫째는 내용만 늘리고 새로운 이해는 제공하지 않는 분기입니다. 플레이어는 다른 대사를 보지만 새로운 정보, 관계, 능력을 얻지 못합니다.

둘째는 작품 전체에 걸쳐 유지할 수 없는 메커니즘을 홍보 목적으로 넣는 것입니다. 도입부에서 한 번 단서를 수색한다고 작품을 조사 게임으로 홍보할 수는 없습니다.

셋째는 이미 제작한 소재라서 삭제하기를 꺼리는 것입니다. 매몰비용은 콘텐츠의 가치를 입증하지 못합니다.

넷째는 기술적으로 가능한 것을 제품에 필요한 것으로 여기는 것입니다. 모델이 임의의 대사를 생성할 수 있다고 해서 이야기가 임의의 대사를 허용해야 하는 것은 아닙니다.

감사에서는 네 가지만 봅니다. 무엇이 추가됐는지, 왜 추가됐는지, 무엇을 대체하는지, 추가 테스트를 누가 맡는지입니다. 삭제할 항목이나 예산 또는 일정 변경이 없는 새 요구사항은 일단 제작에 넣지 않습니다.

범위 감사에서는 ‘숨은 증가’도 확인해야 합니다. 새 캐릭터가 추가되지 않았더라도 같은 캐릭터가 네 가지 상태에서 완전히 다른 연기와 영상을 필요로 한다면 제작량은 이미 늘어난 것입니다. 같은 사무실도 낮 상태에서 정전, 화재 경보, 파손이라는 세 가지 상태로 바뀐다면 장면 하나로만 계산할 수 없습니다. 중복되지 않는 소재의 양을 표에 적어 같은 이름으로 실제 비용을 가리는 일을 막으세요.

프로젝트가 정말 상한을 넘어야 한다면 명확하게 범위를 교환하세요. 예를 들어 엔딩 하나를 추가한다면 독립된 사이드 스토리 한 구간을 삭제하거나 특정 플랫폼 버전을 연기합니다. 누가 승인했는지, 왜 그럴 가치가 있는지, 새 인수 검수 날짜가 언제인지 기록하세요. 이렇게 해야 팀이 조용히 통제 불능을 받아들이는 대신 제품에 관한 선택을 하게 됩니다.

하지 않을 일 목록을 완성한 뒤에는 개인 노트가 아니라 프로젝트 홈페이지에 두세요. 다음 단계에서 가로 화면과 세로 화면, PC와 Web 중 하나를 선택할 때도 이 목록을 바탕으로 어떤 출시 형태가 첫 버전의 역량에 가장 잘 맞는지 판단해야 합니다.