가로형인가 세로형인가, PC인가 Web인가: 출시 형태를 정한 뒤 시나리오를 쓰자

출시 형태는 시나리오를 다 쓴 뒤 고르는 포장 옵션이 아니다. 가로형과 세로형은 배우의 위치와 자막 공간을 결정하고, PC와 Web은 입력 방식, 영상 저장, 로딩 전략, 배포 경로를 결정한다. 늦어도 3분 프로토타입을 만들기 전에는 팀이 주 화면 비율과 주 플랫폼을 하나씩 정해야 한다.

이 글은 프로젝트 착수 시 의사결정을 위한 틀을 제공하며, 모든 프로젝트가 반드시 하나의 플랫폼으로만 출시해야 한다는 뜻은 아니다. 주 플랫폼을 먼저 고르는 이유는 첫 버전의 기술 조건과 시청 조건을 검증할 수 있게 하기 위해서다. 이식은 핵심 경험이 안정된 뒤에 진행해야 한다.

가로형은 여러 인물이 한 화면에 등장하는 장면, 환경 단서, 감시 카메라 화면, 전통적인 PC/콘솔 시청에 더 적합하다. 플레이어의 시선이 더 넓은 범위로 이동할 수 있고, 자막과 선택지도 화면 아래나 옆에 배치하기가 비교적 쉽다.

세로형은 휴대폰을 한 손으로 들고 보는 방식에 더 잘 맞는다. 인물의 얼굴과 관계 갈등이 화면 중심을 차지하기 쉽지만, 환경 정보를 담을 공간은 더 적다. 자막, 선택지, 카운트다운, 시스템 안내가 같은 영역을 두고 경쟁한다. 촬영할 때 안전 영역을 확보하지 않으면 후반 작업에서는 연기를 가리거나 글자를 줄일 수밖에 없다.

가로형과 세로형을 각각 한 세트씩 촬영한다고 당연하게 생각하지 말자. 가로형 영상을 세로형으로 자르면 인물 관계와 단서가 사라지고, 세로형 영상을 가로형 화면에 넣으면 빈 공간이 많이 생긴다. 두 화면 비율을 지원하려면 구도를 다시 잡고, 자막을 확인하고, 영상 자료를 내보내고, 인터페이스를 테스트해야 하므로 별도의 비용으로 계산해야 한다.

PC 클라이언트는 용량이 큰 영상 패키지, 키보드·마우스나 컨트롤러 입력, 오프라인 저장, Steam 배포에 적합하다. 대신 설치, 빌드, 플랫폼 심사, 더 다양한 기기 차이에 대응해야 한다.

Web 버전은 진입 장벽이 낮고 프로토타입을 공유하기 쉽지만, 브라우저 자동 재생 규칙, 네트워크 변동, 캐시, 디코딩 성능, 탭 전환이 모두 영상 경험에 영향을 준다. 개발용 컴퓨터의 고속 네트워크가 실제 환경을 대표한다고 가정해서는 안 된다.

모바일은 세로형과 짧은 플레이에 적합하지만, 터치 영역, 시스템 중단, 백그라운드에서의 복귀, 저장 공간, 다양한 화면 비율, 스토어 규정을 처리해야 한다. 사용자가 소리를 끄고 볼 가능성도 더 높으므로 자막과 소리에 의존하지 않는 피드백은 첫 버전부터 설계해야 한다.

핵심 과제가 여러 감시 카메라 화면을 비교하며 세부 정보를 찾는 것이라면 보통 가로형 PC가 더 자연스럽다. 핵심 과제가 짧은 드라마의 갈등 속에서 빠르게 입장을 표현하는 것이라면 세로형 모바일이 실제 사용 상황에 더 가깝다. 핵심 목표가 잠재 사용자에게 설치 없이 3분 프로토타입을 체험하게 하는 것이라면 Web을 검증 플랫폼으로 사용할 수 있다.

《零点回拨》의 전체 버전에는 고객센터 인터페이스, 통화 기록, 감시 영상과 증거 비교가 포함되어 가로형 PC에 적합하다. 하지만 사용자 확보용 3분 버전은 Web으로 만들어, 걸려 온 전화에 대한 판단 한 번과 명확한 결과 하나를 남길 수 있다. 둘은 단순히 내보내기만 달리한 관계가 아니라 완성 제품과 검증용 일부 구간의 관계다.

영상을 “재생”할 수 있는 것은 최소 요건일 뿐이다. 인터랙티브 영상 게임은 다음 영상을 미리 준비하고, 선택 뒤 빠르게 전환하며, 일시 정지와 재개를 처리하고, 저사양 기기에서도 영상과 음성을 안정적으로 유지해야 한다.

Unity의 VideoPlayer.Prepare는 재생 전에 리소스를 준비하는 데 쓰인다. Unreal Engine의 Media Framework는 로컬 파일, 스트리밍 미디어, 오디오·비디오 트랙, Blueprint와 UMG 연동을 지원한다. Godot의 VideoStreamPlayer에도 자체적인 형식 및 Web 성능 제약이 있다. 촬영이 끝난 뒤에야 모든 영상을 변환해야 한다는 사실을 발견하지 않도록, 엔진을 선택하기 전에 목표 플랫폼과 인코딩을 확인해야 한다.

각 후보안을 1점부터 5점까지 평가하자.

점수가 답을 자동으로 정해 주지는 않는다. “플레이어 적합성”이나 “기술적 위험”이 3점 미만인 안은 총점의 평균으로 약점을 덮지 말고, 먼저 해당 문제를 겨냥한 프로토타입을 만들어야 한다.

첫째, 첫 버전의 주 화면 비율과 주 플랫폼은 무엇인가. 둘째, 그것이 목표 플레이어와 핵심 과제에 가장 적합한 이유는 무엇인가. 셋째, 당분간 지원하지 않을 플랫폼과 재검토 조건은 무엇인가.

출시 형태를 정해야 시나리오에서 한 구간이 얼마나 오래 지속될 수 있는지, 플레이어가 동시에 얼마나 많은 정보를 볼 수 있는지, 선택지가 어떻게 나타나야 하는지를 알 수 있다. 다음 단계에서는 이러한 제약을 핵심 루프로 바꿔야 한다.

실제 실행 단계에서는 목표 기기, 화면 비율, 한 번의 체험 시간, 입력 방식, 네트워크 조건을 같은 사양 카드에 적자. 그런 다음 대사, 선택, 자막, 영상 전환을 포함한 최소 구간으로 가로형과 세로형을 함께 테스트하자. 팀이 구도, 상호작용 영역, 자료 제작 비용이 모두 성립한다고 확인한 뒤에야 전체 시나리오 단계로 넘어가자.