주제: UI는 누가 붙여야 하나? - 아티스트에게 UI 돌려주기
강연자 : 박성철 - 넥슨코리아 / NEXON KOREA
발표분야 : 프로그래밍 - 비주얼아트&사운드
권장 대상 : 클라이언트 프로그래머, UI 디자이너
난이도 : 사전지식 불필요 : 튜토리얼이나 개요 수준에서의 설명
[강연 주제] 이 세션에서는 게임 UI를 제작하는데 있어서 MVC 모델을 지키면서 WPF 또는 XAML 과 흡사한 방식을 이용해 생산성을 향상시키는 방법을 소개합니다. UI 아티스트가 만든 이미지를 프로그래머가 게임에 적용하던 개발 방식이 초래하는 여러가지 문제점들을 지적하고, UI 디자인을 전적으로 UI 아티스트에게 돌려주기 위해 필요한 개별 시스템들을 정의합니다. 유니티와 언리얼을 중심으로 실제 구현에 대해서도 구체적으로 알아봅니다.
흔히 UI라고 줄여서 말하는 유저 인터페이스는 사람과 사물 또는 시스템, 특히 기계, 컴퓨터 프로그램 등 사이에서 의사소통을 할 수 있도록 하는 가상 매개체다. 게임에서도 이를 토대로 유저와 프로그램 간의 상호 작용이 일어나고, 게임플레이가 진행이 된다. UI는 전반적인 게임 그래픽이나 사운드처럼 감각적으로 확 느껴지지 않지만, 마치 공기처럼 없어서는 안 되는 존재인 셈이다.
게임 개발 과정 대다수가 그렇지만, UI를 개발하는 과정은 아티스트 혹은 프로그래머 혼자서만 진행하지 않는다. 각자 협업이 이루어지고, 그 과정에서 여러 가지 애로사항이 발생하기도 한다. 박성철 선임 디렉터 역시도 십여년 이상 게임 개발을 진행하면서 그 과정을 겪었고, 이를 해결하기 위해서 다방면으로 고심해왔다. NDC 2019에서 그는 자신이 기존의 UI 개발 과정에서 느낀 문제점과, 이를 해결하기 위해서 적용한 것들을 공유하는 시간을 가졌다.
■ UI, 누가 만들어야 할까 - 책임과 권한이 따로 노는 기존 UI 공정
박성철 선임 디렉터가 업계에 입사한 2000년대 초에는 그래픽스 엔진과 상용 엔진이 잘 활용되지 않던 시기였다. 그래서 UI를 하나하나 C++ 소스 코드에 하드코딩하는 식으로 만들어야 했다. 예를 들어서 버튼을 만드는 것도 newButton으로 만들거나, 이미지를 넣을 때는 setImage를 쓴다거나, 텍스트를 넣을 때는 setText를 치는 식으로 해야 했다. 즉 프로그래머의 공수가 굉장히 많이 들어갈 수밖에 없는 작업이었다.
그래서 프로그래머들은 손을 덜기 위해서 여러 툴을 만들었다. UI의 그래픽 프리뷰를 만들고, 여기에 일일이 명령어를 치는 게 아니라 크기나 특성을 입력하면 익스포트해서 화면에 뿌리는 식으로 한 것이다. 그나마 조금 나아졌지만, 프로그래머나 아티스트의 고통은 여전히 계속됐다.
이후에 유니티, 언리얼 등 상용 엔진이 발전하면서 이런 툴을 활용할 필요는 적어졌다. 그럼에도 불구하고 UI 개발 공정에서 프로그래머와 아티스트들은 서로 고생을 하는 일이 많았다. 이를 지켜보던 그는 어떻게 해야 이를 개선할 수 있을지 고민하기 시작했다.
우선 기존의 UI 제작 과정을 한 번 되짚어보는 것에서 시작했다. 기존에는 기획자가 UX를 기획하고, 아티스트가 리소스를 제작한 뒤에 프로그래머가 이를 토대로 기능을 구현하고 UI를 적용하게 된다. 이 결과물을 QA, 기획자가 검수하고 통과하면 비로소 완성이 된다.
이때 프로그래머가 하는 일인 기능 구현과 UI 적용은 밀접하게 연관이 있지만, 엄연히 다른 영역이라고 지적햇다. 채팅창을 예로 들면 채팅의 기능을 구현하는 것 자체는 프로그래머가 해야만 하는 일이다. 채팅의 기능 구현을 간단하게 보면 유저가 입력한 텍스트박스 속의 내용을 서버에 전송하고, 그 메시지를 같은 서버에 있는 유저에게 브로드캐스팅한 뒤에, 이 브로드캐스팅된 정보를 받아서 각 화면에 뿌리는 식으로 진행된다. 이런 기능을 프로그래머가 만든 뒤에, 그 위에 아티스트들이 제작한 리소스를 추가해서 UI가 만들어지는 것이다
기존의 UI 공정은 작업이 순탄하게 진행될 때는 크게 문제가 없었다. 하지만 QA나 기획자가 검수하고 수정을 해야 할 때 문제가 발생했다. 특히 UI 적용과 관련된 부분에서 문제가 생겼을 때, 이를 수정하기가 어렵다는 점이 가장 큰 난제였다. 기능 구현에서 오류가 나면 프로그래머가 수정할 수 있지만, UI 적용은 아티스트와 연관이 되어있기 때문이었다.
예를 들어서 이미지 크기를 수정하거나 테마를 바꾸고, 혹은 폰트를 어떤 식으로 고치라는 등의 문제가 발생하면 프로그래머들은 1차적으로 자신이 처리하려고 시도를 한다. 그렇게 해서 수정이 되면 다행이지만, 그게 안 되면 결국 아티스트에게 말해서 새로운 리소스나 가이드라인을 받은 뒤에 작업을 진행하게 된다. 그렇게 해서 수정한 것을 QA나 기획자가 재검수하는 것이 기존의 공정이었다.
문제는 그렇게 되면서 프로그래머가 할 일이 많아졌다는 것이다. 뿐만 아니라 아티스트들도 자기가 작업한 것과 다르게 나온 데다가, 자신이 직접 이를 수정할 수 없어서 불만이 생길 수밖에 없었다. 수정을 하려면 프로그래머와 같이 해야 하는데, 프로그래머는 원체 바쁘기 때문에 따로 시간을 내서 수정하기가 내심 어렵다. 기획자는 기획자대로 아티스트와 프로그래머가 바쁜 와중에도 수정을 해주기를 기다릴 수밖에 없는 등, 기다림의 연쇄작용이 반복되는 구조였다. 그러다보니 수정을 건의하기가 모호한 상황이 반복되고, 결국 좋은 UI를 구축할 기회를 잃어버렸던 것이 기존의 UI 공정의 가장 큰 문제였다.
더군다나 기존 UI 공정에서는 항상 이런 위험이 내포될 수밖에 없었다. 우선 아티스트들과 프로그래머가 쓰는 툴이 다르기 때문이다. 아티스트들은 처음에 흔히 '설계도'라고 부르는 양식으로 UI의 위치 및 크기, 폰트, 자간, 안티앨리어싱 등 정보를 프로그래머에게 넘겨주고는 한다. 그런데 포토샵과 엔진의 좌표계나 폰트 크기 기준, 9슬라이스 계산법이나 안티앨리어싱 강도가 서로 동일하지 않은 만큼 결과물이 틀어지는 경우가 왕왕 발생하곤 한다.
■ 새로운 UI 공정이 필요하다 - UI 적용은 아티스트에게, 기능 구현은 프로그래머가
이런 문제를 계속 겪게 되자, 그는 결국 새로운 UI 공정이 필요하다고 결론을 내리고 팀 회의를 진행했다. UX 기획은 기획자가 계속 맡되, 기능 구현과 UI 적용을 각각 프로그래머와 아티스트에게 배분을 하기로 한 것이다. 그렇게 되면 UI 적용을 아티스트가 할 수 있느냐는 문제가 생긴다. 이를 해결하는 것이 새로운 제작 공정의 첫 번째 핵심이라고 설명했다.
두 번째 핵심으로는 프로그래머가 기능을 구현할 때, 제대로 동작하나 확인하는 절차가 필요했다. 예를 들어서 채팅 기능을 구현했을 때 올바른 창에서 잘 보이는지 확인을 하는 것이다. 이렇게 하는 이유는 프로그래머와 아티스트가 각 작업을 병렬적으로 동시에 작업하면서 완성하고, 이를 수정할 때 각 파트에 따라서 따로 작업이 가능해야 했기 때문이다.
그러기 위해서 구축해야 할 것은 크게 두 가지였다. 하나는 프로그래머가 구축되어있는 UI를 확인할 수 있는 창이었고, 다른 하나는 아티스트가 UI를 배치할 수 있게 도와주는 툴이었다. 이를 만들기 위해서는 우선 UI가 무엇이고, 어떤 기능을 맡는가를 하나하나 재정립해서 만들어가는 과정이 필요했다.
박성철 선임 디렉터는 UI 기능을 세 가지로 정리했다. 하나는 게임 내 정보를 화면에 노출시키는 프레젠테이션 기능이다. 다른 두 개는 유저의 입력에 의한 처리를 하는 네비게이션과 오퍼레이션 기능이다. 이 중 클라이언트에 내재된 데이터에 변화가 없는 단순 처리는 네비게이션, 데이터에 변화가 생기는 것을 오퍼레이션이라고 구분했다. 예를 들면 메뉴창을 켜고 닫는 것은 네비게이션이고, 채팅을 쳐서 서버에 올리는 것을 오퍼레이션이라고 볼 수 있다.
이렇게 분석했을 때 오퍼레이션은 클라이언트 혹은 서버에 대한 프로그래밍 지식이 요구되지만, 프레젠테이션과 네비게이션은 프로그래머의 도움 없이도 구현이 가능했다.기존에 만들어둔 것을 어느 때에 띄우느냐, 혹은 언제 없애고 어떤 것을 어떤 식으로 사용하느냐 정도를 지정할 있으면 되기 때문이다. 따라서 이 두 가지에 관련된 기능과 권한을 UI 아티스트에게 넘기는 과정이 필요했다.
CUD(Create, Update, Delete)를 이에 맞게 구현하려면 프로그래머가 UI가 세팅이 안 된 상태에도 자신의 코드가 구현이 됐나 별도로 확인할 수 있어야 했다. 그리고 아티스트는 프로그래머에게 이를 전달할 수 있도록 UI를 적용하는 툴을 활용할 수 있어야 했다 박성철 선임 디렉터는 자신의 팀이 취한 방식이 이 원칙을 기반으로 기술을 적용했다고 설명했다. 그러면서 이 원칙을 구현할 수 있다면 적용하는 기술이 조금 달라져도 무방하다고 덧붙였다.
탱고파이브를 개발했을 때, 이 공정을 진행하면서 처음에 적용한 것은 양방향 데이터 바인딩이었다. 이는 메모리에 있는 변수와 UI 컨트롤에 있는 특성을 서로 연결하는 것이다. 예를 들어서 코드 텍스트에는 화면에 렌더링이 되어있는 것도 있고, 클라이언트 메모리에 있는 것도 있다. 이 두 가지를 묶어서 클라이언트에 있는 내용이 렌더링이 바로 되거나, 렌더링이 된 내용이 바뀌면서 클라이언트 메모리에 있는 것을 바꿀 수 있도록 한 것이다. 프로그래머 입장에서는 이렇게 구현하는 것만으로 작업은 완료된다. 왜냐하면 렌더링해서 뜨는 것에 따라 클라이언트 값도 바뀌는 것을 따로 확인할 필요도 없고, 그 과정을 아티스트가 수치를 입력하거나 몇몇 정보를 입력하는 것만으로 끝나기 때문이다.
다만 이런 작업을 위해서는 UI 컨트롤창에서는 프로그래머와 아티스트가 서로 프록시 데이터에 대해서 합의를 해둬야 한다. 예를 들어서 유저이름에 대한 UI와 데이터, 변수는 유저네임이는 프록시에 입력한다던가 하는 식이다. 또한 이를 한 컨테이너에 다 담으면 종류가 너무 많기 때문에 계층을 나누고, 그 계층 아래에 프록시 데이터와 함수를 구축했다. 그렇게 한 뒤에 아티스트가 R을 누르면 게임창에서 직접 확인을 할 수 있도록 구축하고, 핸들러에는 함수를 대입해서 아티스트가 단순 수치를 입력하는 정도로도 얼마든지 조절을 할 수 있도록 했다. 프로그래머의 입장에서 볼 때 UI 컨트롤창은 비주얼스튜디오의 와치창과 최대한 유사하게끔 구성했다.
양방향 데이터 바인딩을 하다보면, 데이터에 변화를 줄 때 종종 원본 데이터 자체가 변질되는 일도 발생한다. 예를 들어서 텍스트를 로컬라이제이션할 때 로컬라이제이션 스트링을 또 적는데, 이때 종종 원본 데이터를 건드려서 오류가 나는 일이 있다. 그렇기 때문에 클라이언트 데이터를 카피한 뷰 데이터 레이어를 끼워서 작업을 하는 식으로 진행하게 된다.
네비게이션 과정은 UI 스테이트 머신을 구축해서 활용하는 식으로 했지만. 이것은 꼭 필요하지는 않다. 다만 UI 아티스트가 좀 더 수치를 편하게 입력하고, 네비게이션을 조작할 수 있도록 지원한 것이다. 그리고 이벤트 후커를 도입해서 UI 아티스트가 작업이 끝난 이후에도 각 과정의 데이터 레이어를 관리하거나, 네비게이션 과정에서 불필요하게 메모리가 활용되지 않도록 수정할 수 있게끔 했다.
■ UI 적용을 아티스트에게 넘긴 이유 - 요는 책임과 권한의 일치
왜 굳이 이렇게 UI 개발 공정을 바꿔야 했을까? 박성철 선임 디렉터는 각자가 자신의 일에 더 몰입할 수 있게 하기 위해서라고 설명했다.
실제로 이 공정이 완성되고 도입된 결과, 프로그래머와 아티스트 모두가 만족도가 높아졌다. 프로그래머의 입장에서는 UI를 만드는 과정을 서버프로그래머가 되서 작업하는 것 같다고 느꼈다고 설명했다. 서버프로그래밍처럼 자신이 하지 않아도 무언가, 즉 UI가 바뀌어있고 때로는 상대가 요청하는 데이터를 받아서 작업하고 돌려준 뒤 이를 확인하는 식으로 진행하기 떄문이다.
한편, 아티스트 입장에서는 자신에게 책임만 있다가 권한까지 주어진 셈이라서 UI에 대해서 굉장히 적극적으로 임헀다고 설명했다. 그간 UI에 필요한 리소스는 자신의 책임이었지만, 그 적용 권한이 아티스트가 아닌 프로그래머에게만 있었기 때문에 아티스트들은 괴리감을 느끼고는 했었다. 그렇지만 자신이 이제 작업을 다 처리할 수 있게 되기 때문에, 자신이 의도한 대로 완성하기 위해 아티스트들이 여러 가지로 시도를 했다는 것이다.
기획자 입장에서도 각자가 할 일과 권한이 나뉘어져있기 때문에 문제가 발생할 때 좀 더 빠르게 처리할 수 있었다. 기능 구현에 문제가 생기면 프로그래머에게 지시하면 되고, UI 적용이나 리소스에 문제가 있으면 아티스트에게 바로 이야기하면 되기 때문이다. 그러면서 리드 타임이 줄어들었고, 만족스러운 결과물을 얻을 수 있었다고 밝혔다.
탱고파이브와는 달리 파이널판타지11 리부트는 엔진도 언리얼로 달라지고, 이미 어느 정도 진행이 된 프로젝트를 받아서 진행을 해야 했다. 그때도 그는 우선 아티스트가 UI 적용할 때 손을 못 대는 부분을 파악하고, 이 부분을 처리하는 작업을 진행했다. 로직 코드가 다 올라와있었기 때문에 아티스트들이 WBP를 아예 건드릴 엄두를 못 냈는데, 이를 C++로 내리면서 아티스트들이 WBP를 다룰 수 있게끔 했다. 이런 식으로 작업을 거친 결과 파이널판타지11 리부트의 UI 공정 역시도 기능 구현은 프로그래머가, UI 적용은 아티스트가 하게 됐다.
박성철 선임 디렉터는 개발사마다 다 상황이 다른 만큼 이런 방식을 일률적으로 적용하긴 어렵다고 설명했다. 다만 효율적인 개발 공정을 위해서는 책임과 권한, 그리고 각자의 분야와 업무를 일치시키는 것이 중요하다고 강조했다. 책임만 지고 수정할 수 있는 권한이 없거나, 권한은 있지만 자신의 분야가 아닌 일을 맡게 되면 일의 갈피를 못잡고 갈팡질팡할 수밖에 없기 떄문이다.
Ruudi@inven.co.kr