인터랙티브 영상 게임을 0에서 1로: 전체 제작 과정·역할·산출물 지도

인터랙티브 영상 게임을 만들 때 정말 어려운 것은 “영상을 찍고 버튼 두 개를 붙이는 것”이 아니라, 이야기와 선택지, 에셋, 코드, 테스트가 끝까지 같은 프로젝트를 가리키도록 하는 일이다. 가장 안정적인 방법은 제작을 명확한 산출물이 있는 열 단계로 나누는 것이다. 프로젝트 착수, 핵심 경험, 이야기, 분기 시스템, 프로토타입, 제작 준비, 촬영, 후반 작업 및 통합, 테스트, 출시 및 회고다. 앞 단계의 결과물은 다음 단계에서 바로 사용할 수 있어야 한다.

이 글은 처음으로 인터랙티브 영상 게임을 맡은 작가, 감독, 독립 개발자, 소규모 팀 책임자를 위한 글이다. 읽고 나면 자신의 제작 과정을 그려 보고, 각 단계를 누가 책임지며 무엇을 전달해야 하는지, 그리고 언제 다음 단계로 넘어가면 안 되는지 알 수 있어야 한다.

DramaFork는 인터랙티브 콘텐츠 제작 및 배포 플랫폼이다. 이 글에서는 플랫폼에 있는 기획안 《零点回拨》을 예로 들지만, 제작 과정 자체는 특정 도구에 의존하지 않는다.

프로젝트 착수 단계에서는 네 가지 질문에 답해야 한다. 누가 플레이할 것인가, 왜 지금 플레이하고 싶어 하는가, 플레이어는 이야기 안에서 무엇을 하는가, 팀이 이 규모를 감당할 수 있는가. 산출물은 한 페이지짜리 프로젝트 포지셔닝 카드다. 최소한 목표 플레이어, 출시 플랫폼, 예상 플레이 시간, 핵심 플레이어 행동 동사, 인물과 장소의 최대 수를 담아야 한다.

《零点回拨》을 예로 들면, 이야기의 훅은 “야간 근무 중인 고객 상담원이 24시간 뒤에서 걸려 온 전화를 받는다”이다. 하지만 플레이 경험에 대한 약속은 이 문장이 아니다. 플레이어가 제한된 시간 안에 발신자를 믿을 수 있는지 판단하고, 동료를 선택하며, 자정 이후의 결과를 바꾼다는 것이다. 선택지 설계와 프로토타입 검증을 이끌 수 있는 것은 뒤의 문장뿐이다.

착수 단계의 통과 기준도 간단하다. 팀이 플레이어가 반복해서 수행하는 행동을 한 문장으로 설명하고, 첫 버전에서 하지 않을 일을 명확히 정할 수 있는가. 답이 여전히 “몰입감 있는 이야기를 경험한다”라면 범위가 아직 구체화되지 않은 것이다.

첫 번째는 주제를 갈등으로 번역하는 것이다. 예를 들어 “신뢰”는 인물의 대사에만 등장해서는 안 된다. 플레이어가 그 결과를 감당해야 하는 결정이 되어야 한다.

두 번째는 갈등을 선택으로 번역하는 것이다. 모든 선택에는 선택 전에 주어지는 정보, 이해할 수 있는 선택지, 상태 변화, 눈에 보이는 피드백이 필요하다. 상태 변화가 없는 선택지는 인물을 표현하는 수단으로 남겨 둘 수 있지만, 주요 줄거리를 바꾸는 것처럼 보여서는 안 된다.

세 번째는 선택을 데이터로 번역하는 것이다. 팀은 노드 번호, 이동 대상, 등장 조건, 변수 기록, 필요한 영상, 가능한 엔딩을 통일해야 한다. 작가가 쓰는 “두 번째 다툼 장면”, 프로그래머가 쓰는 scene_02, 후반 작업에서 쓰는 파일명이 서로 대응해야 한다.

네 번째는 데이터를 제작 작업으로 번역하는 것이다. 노드 표를 장소 매트릭스, 배우별 촬영 일수, 소품, 분장·헤어·의상, 샷, 사운드, 자막, 테스트 케이스로 펼쳐야 한다. 이때 비로소 아이디어는 처음으로 비용을 산정할 수 있는 프로젝트가 된다.

Steam의 출시 절차에서도 상점 페이지와 제품 Build는 각각 점검과 심사를 마쳐야 한다. 따라서 “게임을 완성한 뒤 출시를 생각하자”는 방식은 대개 재작업으로 이어진다. 공식 Steamworks 시작 안내는 Build를 제작하면서 상점에 보여 줄 내용도 함께 준비하도록 권한다.

세 명으로 구성된 팀에서는 작가가 내러티브 디자인을 함께 맡고, 감독이 제작을 겸하며, 프로그래머가 테스트 도구까지 담당할 수 있다. 이것은 문제가 아니다. 정말 위험한 것은 같은 사람이 두 가지 일을 한다는 이유로 두 업무 사이에 필요한 산출물을 생략하는 것이다.

예를 들어 작가와 프로그래머를 겸하더라도 노드 표는 여전히 필요하다. 3주 뒤에는 그 사람도 기억만으로 특정 변수가 어디에서 기록되는지 판단할 수 없기 때문이다. 감독과 편집자를 겸하더라도 촬영 기록과 에셋 번호는 필요하다. 그렇지 않으면 재촬영한 에셋으로 기존 분기의 에셋을 올바르게 교체할 수 없다. 역할은 합칠 수 있지만, 역할 사이의 인터페이스는 사라져서는 안 된다.

많은 프로젝트가 10만 자 분량의 대본을 모두 쓰고, 심지어 모든 촬영을 마친 뒤에야 처음으로 플레이어에게 조작을 맡긴다. 이때 “선택에 필요한 정보가 없다”, “선택지를 이해할 수 없다”, “영상 전환이 흐름을 깨뜨린다”는 문제를 발견하면, 수정 비용은 이미 대본 재작성, 재촬영, 재편집 비용이 되어 있다.

더 나은 순서는 먼저 3분짜리 프로토타입을 만드는 것이다. 노드 다섯 개, 선택 두 번, 엔딩 세 개면 된다. 임시 텍스트나 저비용 영상 어느 쪽을 사용해도 좋다. 프로토타입에서 검증할 것은 영상 품질이 아니라, 플레이어가 자신이 무엇을 결정하는지 아는가, 선택 뒤 변화를 느낄 수 있는가, 팀이 상태를 추적할 수 있는가다.

한 페이지짜리 프로젝트 포지셔닝 카드를 새로 만들고 목표 플레이어, 이용 상황, 핵심 플레이어 행동 동사, 플랫폼, 플레이 시간, 인물 수 상한, 장소 수 상한, 첫 버전에서 하지 않을 일 목록만 작성하자. 아직 전체 줄거리는 쓰지 말자.

다음 글에서는 먼저 인터랙티브 영화, FMV 게임, 인터랙티브 숏드라마, 비주얼 노벨을 구분한다. 제품 형식을 잘못 선택하면 이후의 대본, 촬영, 기술 계획이 근본적으로 서로 충돌하게 된다.