기획자 입장에서 본 언리얼 개발환경의 변화
며칠 전 아침에 커피머신 앞에 서서 종이컵에 커피가 고이기를 기다리다가 팀에 UI 디자이너님과 UI팀이 커버할 업무범위가 생각보다 아주 넓은 점에 대해 이야기했습니다. 오래 전 시대부터 게임 개발에 참여해 오면서 시간이 흐를 수록 UI팀이 할 일이 점점 더 늘어났는데 이 이야기를 하다 보니 언리얼 엔진 기반에서 UI 담당자의 할일이 어떤 식으로 늘어났는지 UI 위젯 블루프린트를 직접 만들지는 않는 기획자 관점에서 이야기해 보면 재미있겠다는 생각이 들었습니다.
처음으로 언리얼 엔진을 사용한 프로젝트는 언리얼 2를 사용했습니다. 사실 이 때는 언리얼 엔진이 어떤 역할을 하는지도 잘 몰랐고 또 어떤 개발환경을 제공하는지도 잘 몰랐습니다. 지금에 와서 생각해보면 나 뿐만 아니라 팀 역시 이 값비싼 개발환경을 어떻게 활용해야 할 지 잘 몰라 이전에 개발해 오던 방식을 그대로 적용하다가 어려 어려움을 겪었던 것 같습니다. 먼저 언리얼 에디터 환경에서 레벨을 불러오고 액터를 배치하고 액터에 여러 프로퍼티를 설정할 수 있었지만 우리는 엑셀에 몬스터나 NPC를 정의하고 이걸 익스포트 해서 서버와 클라이언트가 각각 나눠 가진 다음 언리얼 에디터 환경에서 아까 액셀을 통해 정의한 액터를 배치했습니다.
그러다 보니 에디터는 사실상 액터를 배치하고 배치된 상태와 레벨을 프리뷰 하는 정도로 사용했습니다. 클라이언트 환경은 에디터에서 레벨을 직접 실행하는 식으로는 구동시킬 수 없었기 때문에 언리얼 에디터는 정말로 레벨 에디팅 역할로만 사용했고 기억이 흐릿하지만 나중에는 언리얼의 여러 기능을 감당하지 못해 최소한의 그래픽 처리 기능을 제외한 나머지 전체를 들어내기도 했습니다.
한번은 자체 엔진을 사용하는 개발에 참여했는데 이곳에서는 UI 담당자 입장에서 할 수 있는 일이 많지 않았습니다. 포토샵에서 UI 그래픽을 만들었고 UI 담당자가 모션 그래픽의 의도를 프로그래머에게 설명하면 프로그래머가 이를 설계한 다음 설계에 따른 에셋 구성을 UI 담당자에게 전달했습니다. 그러면 UI 담당자는 이 에셋 구성에 따라 포토샵 이미지를 가공해서 프로그래머에게 전달하고 프로그래머가 실제 UI 동작을 구현했습니다.
만약 화면 상에 평소엔 작게 나타나지만 최대화, 최소화, 원래 크기로 돌아올 수 있는 윈도우를 만들어야 한다면 포토샵에서 이 윈도우를 디자인한 다음 이 이미지를 아홉 조각으로 잘라 프로그래머에게 전달하면 프로그래머가 이 이미지 아홉 조각이 윈도우 모양으로 표시되며 늘어났다 줄어들었다 하도록 직접 만드는 식이었습니다. 이 시대의 UI 디자인은 주로 고정된 시안 여러 개를 만들어 칠판에 붙여 놓고 어떤 시안이 더 나을지 종이에 인쇄된 인터페이스를 노려보며 머릿속으로 시뮬레이션을 해 이 다음 시도할 시안을 결정하기를 반복하곤 했습니다. 아주 나중에 가서야 프로그래머가 주로 원하는 모양으로 에셋을 구성하고 저장하고 이를 코드에서 바로 읽을 수 있도록 가공하는 도구를 만들어 어지간한 인터페이스 디자인 변경에 대응할 수 있게 됐지만 여전히 모션 그래픽을 직접 다룰 수는 없었습니다.
한편 한번은 언리얼 3에 기반해 개발하는 프로젝트에 참여했는데 언리얼 에디터 인터페이스는 이전 시대만큼 후졌고 투박했지만 이번에야말로 언리얼 에디터 환경을 적극적으로 활용했습니다. 이전에 레벨을 프리뷰하고 액터를 배치하는 수준에서 에디터를 활용했다면 이번에는 키즈멧에 기반해 액터를 제어하고 이 제어가 서버 측에도 동기화 되도록 했습니다. 여느 MMO 팀에서는 잘 시도하지 않을 구성이지만 게임은 여러 액터가 복잡하게 움직이는 연출을 요구했고 이 요구사항을 반영할 가장 싼 방법이 바로 키즈멧에 기반해 액터를 제어하는 것이었습니다.
이와 함께 마티니 기반의 시네마틱 역시 서버를 통해 동기화 해 이들이 모두 조합된 대단한 연출이 멀티플레이 환경에서 동기화 되어 훌륭한 경험을 만들어 냈습니다. 다만 이 시대에도 여전히 UI 개발 파이프라인이 잘 정립되지는 않았습니다.
본격적으로 언리얼 엔진 기반의 UI 작업 파이프라인이 구축된 것은 언리얼 4 부터였는데 이제 위젯 블루프린트 제작과 코드 작성을 어느 정도 병렬로 진행할 수 있게 되었습니다. 요구사항이 확실해지고 요구사항에 인터페이스 목업이 포함되면 여기에 기반해 최소한의 화면 구성만을 포함한 위젯 블루프린트를 준비합니다. 프로그래머는 이 위젯 블루프린트에 기반해 기능을 개발하고 그 사이에 위젯 블루프린트의 핵심 기능을 유지한 채로 UI 구성요소를 배치하고 각각의 구성요소에 그래픽 요소를 추가해 인터페이스를 완성해 갑니다.
위젯 블루프린트는 기초적이나마 UI 모션 그래픽 기능을 포함하고 있어 어지간한 요구사항은 엔진을 직접 수정하지 않은 상태에서 커버할 수 있었습니다. 하지만 이전 시대에 비해 UI 디자이너는 UI 위젯 블루프린트와 코드가 얽혀 동작하는 구조와 원리에 대해 이전 시대에 비해 좀 더 깊이 이해하고 있어야만 했습니다.
언리얼 4에서 5로 넘어올 때는 기획자 입장에서 딱히 드라마틱한 개발 환경의 변화를 느끼지는 못했습니다. 테크 데모에서 이전에는 불가능했던 그래픽 표현이 가능해진 것도 같지만 기획자가 주로 접하는 UI 위젯 제작, 데이터 핸들링, 블루프린트 코드를 통한 최소한의 게임 제어, 시퀀스를 통한 연출 및 환경 제어 등은 이전과 별로 달라지지 않았고요.
하지만 시야를 넓혀 오래 전부터 언리얼 개발 환경의 변화를 살펴보면 이전에는 단순히 프로그래머가 거의 모든 작업을 수행했던데 비해 프로그래머 입장에서 비즈니스 로직과 거리가 있고 또 다른 직군이 더 높은 전문성을 발휘할 수 있는 분야들이 적당한 도구의 지원 하에 서서히 프로그래머의 영역에서 벗어나고 있습니다. 이제 종이컵에 커피가 가득 고여 커피머신에서 컵을 치우며 우리 프로젝트가 처한 상황에 UI 팀에 기대하는 업무량을 감안하면 파이프라인을 효율적으로 구동하는 것 만으로는 한계가 금새 찾아올 것이 확실하기 때문에 인원을 늘려야만 할 것 같다는 이야기를 하며 대화를 마치고 커피를 마시기 시작했습니다.
