인터랙티브 영상 게임을 0에서 1까지 만들기: 전체 프로세스, 역할, 산출물 지도

인터랙티브 영상 게임을 만드는 데 진짜 어려운 점은 “영상을 하나 찍고 버튼 두 개를 붙이는 것”이 아니라, 이야기, 선택, 소재, 프로그램, 테스트가 처음부터 끝까지 같은 프로젝트를 설명하도록 만드는 일이다. 가장 안정적인 방법은 제작을 명확한 산출물이 있는 10개 단계로 나누는 것이다. 기획, 핵심 경험, 이야기, 분기 시스템, 프로토타입, 프로덕션, 촬영, 후반 연동, 테스트, 출시 회고가 그것이다. 앞 단계의 결과물은 다음 단계에서 바로 사용할 수 있어야 한다.

이 글은 처음으로 인터랙티브 영상 게임을 맡는 작가, 감독, 인디 개발자, 소규모 팀 리더에게 적합하다. 읽고 나면 자신만의 제작 경로를 그릴 수 있고, 각 단계에서 누가 무엇을 책임지는지, 무엇을 납품해야 하는지, 언제 더 진행하면 안 되는지 알 수 있을 것이다.

DramaFork는 인터랙티브 콘텐츠 제작 및 출시 플랫폼이다. 이 글에서는 플랫폼 안의 기획안 「자정의 리콜」을 예시로 사용하지만, 프로세스 자체는 특정 도구에 의존하지 않는다.

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

「자정의 리콜」을 예로 들면, 이야기의 훅은 “야간 고객센터 상담원이 24시간 뒤에서 걸려온 전화를 받는다”이다. 하지만 플레이 가능한 약속은 이 문장이 아니다. 플레이어가 제한된 시간 안에 전화 내용을 믿을 수 있는지 판단하고, 동맹을 선택하며, 자정 이후의 결과를 바꾼다는 것이 진짜 약속이다. 뒤의 문장만이 선택 설계와 프로토타입 검증을 이끌 수 있다.

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

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

두 번째는 갈등을 선택으로 번역하는 것이다. 모든 선택에는 진입 정보, 이해 가능한 선택지, 상태 변화, 보이는 피드백이 필요하다. 상태 변화가 없는 선택지는 캐릭터 표현용으로 남겨둘 수 있지만, 그것이 메인 줄거리를 바꾸는 척해서는 안 된다.

세 번째는 선택을 데이터로 번역하는 것이다. 팀은 노드 번호, 이동 대상, 등장 조건, 변수 기록, 필요한 영상, 가능한 결말을 통일해야 한다. 작가가 쓰는 “두 번째 말다툼”, 개발자가 쓰는 scene_02, 후반 작업자가 쓰는 파일명이 서로 대응되어야 한다.

네 번째는 데이터를 제작 업무로 번역하는 것이다. 노드 표는 장면 매트릭스, 배우 투입일, 소품, 분장과 의상, 촬영 컷, 사운드, 자막, 테스트 케이스로 펼쳐져야 한다. 이 지점에 와서야 아이디어는 처음으로 견적을 낼 수 있는 프로젝트가 된다.

단계 필수 산출물 계속 진행할 조건 기획 포지셔닝 카드, 범위 가드레일 플레이어, 플랫폼, 플레이 시간, 핵심 행동이 명확함 핵심 경험 핵심 루프, 인터랙션 밀도표 3분 안에 완전한 피드백이 한 번 발생함 이야기와 캐릭터 비트표, 캐릭터별 정보 격차 매트릭스 주요 갈등이 플레이어 행동으로 바뀔 수 있음 분기 시스템 노드 표, 변수 사전, 결말 매트릭스 모든 이동을 추적할 수 있고 주인 없는 노드가 없음 프로토타입 플레이 가능한 3분 버전 최소 한 경로가 시작부터 결말까지 도달함 프로덕션 장면 매트릭스, 예산, 일정 독립 소재량이 예산 안에 있음 촬영 번호가 붙은 영상 및 음성 소재 소재를 노드 표에 따라 항목별로 대조할 수 있음 후반 연동 출시용 영상, 자막, 인터페이스, 저장 기능 선택 전환이 안정적이고 상태 저장이 정확함 테스트 경로 커버리지와 기기 보고서 차단 이슈가 0개이고 핵심 결말에 도달 가능함 출시 회고 스토어 페이지, Build, 데이터 대시보드 홍보 약속과 실제 버전이 일치함

Steam의 출시 프로세스도 스토어 페이지와 제품 Build가 각각 검사와 심사를 완료할 것을 요구하므로, “게임을 다 만든 뒤 출시를 생각하자”는 방식은 보통 재작업을 만든다. 공식 Steamworks 시작 가이드는 Build를 제작하는 동시에 스토어 노출 준비를 진행하라고 권장한다.

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

예를 들어 작가 겸 개발자라도 여전히 노드 표가 필요하다. 3주 뒤에는 본인도 어떤 변수가 어디에서 기록되는지 기억만으로 판단할 수 없기 때문이다. 감독 겸 편집자라도 여전히 스크립트 기록과 에셋 번호가 필요하다. 그렇지 않으면 재촬영한 소재를 기존 분기와 정확히 교체할 수 없다. 역할은 합칠 수 있지만, 인터페이스는 사라질 수 없다.

많은 프로젝트가 먼저 10만 자짜리 대본을 다 쓰거나 심지어 모든 소재를 촬영한 뒤에야 처음으로 플레이어에게 조작하게 한다. 이때 “선택에 정보가 없다”, “선택지를 이해할 수 없다”, “영상 전환이 리듬을 망친다”는 사실을 발견하면 수정 비용은 이미 다시 쓰기, 재촬영, 재편집이 되어 버린다.

더 나은 순서는 먼저 3분짜리 프로토타입을 만드는 것이다. 노드 5개, 선택 2번, 결말 3개면 충분하며, 임시 텍스트나 저비용 영상으로도 가능하다. 프로토타입이 검증해야 하는 것은 화면 품질이 아니라, 플레이어가 자신이 무엇을 결정하는지 아는가, 선택 후 변화를 느낄 수 있는가, 팀이 상태를 추적할 수 있는가이다.

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

다음 글에서는 먼저 인터랙티브 영화, FMV 게임, 인터랙티브 숏폼 드라마, 비주얼 노벨을 구분할 것이다. 제품 형태를 잘못 선택하면 이후의 대본, 촬영, 기술 방안이 근본부터 서로 충돌하게 된다.