[NDC2016] '별거 아닌게 아니다', 프로그래머와 디자이너를 이롭게 하는 UI 개발

모바일 게임에서 UI 개발은 난도는 낮은데 비해 많은 작업량과 잦은 변경으로 시간을 많이 소모하는 작업이다. 속된 말로 '노가다'라고 불리며 디자이너에게도 프로그래머에게도 환영받지 못하는 작업이다.

하지만 UI는 게임에서 커다란 영향력을 가지는 부분이다. 스마트폰이라는 한정된 화면 속에서 게임의 재미를 구현하고 장르의 특성을 녹여내야 하므로 UI의 구성에 따라 게임의 집중도 자체가 변화하기 때문이다.

게임 시장의 경쟁이 치열해지며 게임 콘텐츠뿐만 아니라 게임의 UI 자체도 게임의 질을 판단하는 주요 기준으로 떠오르고 있다. '9이닝 매니저'를 개발한 에이스 프로젝트의 안현석 개발팀장은 개발과정에서 시도한 UI 작업 환경 개선과 시행착오의 경험을 공유했다.

▲ 에이스프로젝트 안현석 개발팀장

디자이너와 프로그래머 모두 기피하는 UI 작업

모바일 게임에서 UI 작업이라는 게 그렇다. 분명 모두가 중요하다고 생각한다. 하지만 귀찮게 여기는 작업이다. 작업량도 많고, 수정도 엄청나게 잦은데 프로세스 개선이 잘되지 않는 작업이기도 하다.

프로그래머 입장에서 UI 작업은 잦은 변경과 반복되는 수정 작업의 연속이다. 한 번에 끝나는 경우가 거의 없다. 코딩양은 많은데 남는 것도 없다. 무엇보다 지루하고 재미가 없다. 그래서 '하기 싫은' 매우 귀찮은 작업으로 정평이 나 있고 대부분 주니어 프로그래머에게 떠넘기기 일쑤다. 심지어 이런 귀찮은 UI 작업 때문에 신입 프로그래머를 뽑기도 한다.

이는 디자이너에게도 마찬가지다. 귀찮은 단순 반복 작업의 연속이다. 좌표를 따고, 이미지 리소스를 자르고, 아틀라스를 만들고의 무한 반복이다. 사실상 UI 컨셉을 잡는 거 빼고는 '노가다'를 하는 거다.

작업의 특성상 UI 작업은 프로그래머의 도움이 필요하다. 그런데 그들은 UI 개발에 많은 시간을 투자하지 않는다. 항상 우선순위가 밀리고 때문에 항상 막판에 급하게 구현된다. UI를 하드 코딩할 수밖에 없는 환경인 거다. 디자이너 입장에서는 심하면 정말 고치고 싶은 부분이 있는데도 프로그래머가 바쁘면 눈치 보느라 넘어가는 경우도 생긴다.

요약하자면 UI 작업은 프로그래머나 디자이너 모두에게 불만족스럽고 귀찮은 작업이다.

낡은 프로세스와 도구를 개선해 효율적인 UI 작업 만들기

이런 문제는 예전부터 계속 있었던 문제다. 뭐가 문제인지 파악하지도 않고 '원래 그렇다'라는 식으로 인식되고 있었으며 대부분 개선 의지가 별로 없었다. 디자이너든 프로그래머든. 에이스프로젝트는 이러한 문제점을 해결하고자 했다. 그들이 제일 먼저 시작한 것은 '9이닝 매니저'의 UI를 작업하는 데 있어 예상되는 어려움을 파악하는 것이었다.

'9이닝 매니저'는 MLB 야구 매니지먼트게임이다. 각종 데이터와 수치를 기반으로 한 시뮬레이션 야구 게임으로 UI 대부분은 방대한 데이터와 수치를 어떻게 보여주느냐에 치중되어 있다. 그러므로 복잡하고 다양한 UI 레이아웃이 나올 것이며, 복잡한 가운데서 사용자가 수치를 쉽게 인지하게 하여야 했다. 매니지먼트게임은 대부분 UI로 이뤄진 게임이기에 UI를 귀찮은 작업으로만 치부하기엔 그 비중이 컸다.

에이스프로젝트는 UI 레이아웃이 100개가 넘을 것으로 예상했다. 100개가 넘는 레이아웃을 만들면서 프로그래머 손을 타면 한도 끝도 없을 것으로 판단하고 최대한 프로그래머의 손을 타지 않고 디자이너가 마음대로 할 수 있게 개발 목표를 잡았다. 더불어 재사용성도 고려했다. UI는 일회용으로 사용되고 버려지는 레거시 코드들로 짜이는 게 대부분이었기 때문에 이러한 낭비를 버리고자 했다.

먼저, UI 작업에 필요한 좋은 툴이 필요하다고 판단했다. 과거 UI 작업이라고 하면 디자이너가 스크린샷을 만들어서 좌표를 찍고 이를 프로그래머에게 넘기면 UI를 배치해주는 형태였다. 이렇게 손을 많이 거치는 형태는 수정이 힘들어 답이 없다고 판단했다.

좋은 툴의 조건은 간단명료했다. 디자이너가 사용할 것이기에 사용하기 편하고 쉬워야 하며 오픈 소스로 제작되어 원하는 대로 뜯어고칠 수 있어야 했다. 그리고 자체 UI 컴포넌트를 추가할 수 있어야 하는 것이 조건이었다.

그들은 '유니티'와 '코코스빌더'를 두고 고민했다. 유니티는 컴포넌트 기반의 엔진이기 때문에 컴포넌트를 매우 손쉽게 추가할 수 있다는 장점이 있고, 툴을 어느 정도 커스터마이징 할 수도 있었다. 그러나 3D 기반의 엔진이기 때문에 2D UI를 개발하는 데 있어 적당한가 하는 의문은 있었다.

코코스빌더는 유니티 만큼은 아니지만, 컴포넌트 추가가 쉽고 풀 오픈 소스로 개발된 엔진이라 뜯어고치기가 쉬웠다. 또한, 2D 기반 엔진이라 2D 작업에도 편리했다. 그러나 오픈 소스이기 때문에 상용 엔진에 비해 유지 보수가 안되어 신뢰성의 문제가 있었다.

개발팀은 고민 끝에 '코코스빌더'로 결정했다. 유니티보다 쉽고 가벼우며 2D 관련 기능이 많았기 때문이다. 그러나 '코코스빌더' 자체가 완전히 만족스러운 도구는 아니었다. 수많은 버그와 사소한 불편함이 있었고 무엇보다 3.0 이후 업데이트가 중지됐다는 단점이 있었다. 그래서 팀 차원에서 코코스빌더를 업데이트하고 유지 보수하는 과정을 거치기로 했다. 그리고 '코코스빌더'는 맥 OS 환경만 지원했기에 팀 전체가 윈도우에서 맥으로 환경을 바꿨다.

틀을 고른 다음에는 작업 환경을 개선하는 작업을 시작했다. 디자이너의 생산성이 가장 중요하기에 디자이너들이 요구하는 대로 전부 툴을 커스터마이징했다. 디자이너들은 작업하기 훨씬 편해졌다고 좋아했다.

그다음에 착수한 환경 개선은 디바이스 확인 부분이었다. 모바일기기가 워낙 다양하다 보니 해상도가 매우 다양했고 이 때문에 디바이스 테스트는 매우 빈번하게 일어나는 일이었으나, 기존에는 프로그래머의 도움을 받아야만 이를 테스트할 수 있었다. 그러므로 매번 많은 시간이 소모됐다.

그래서 디자이너가 프로그래머의 도움 없이 직접 확인할 수 있게 환경을 재편했다. 디자이너가 자유롭게 확인할 수 있게 하는 것이 목표였다. 일단 코코스빌더로 만든 작업 파일을 서버에 업로드할 수 있게 했다. 그리고 디자인 테스트 빌드를 이용해 작업 파일 서버에서 파일을 다운로드하면 프로그래머의 도움 없이 디바이스 확인 및 테스트를 할 수 있었다.

디자이너들은 매우 만족했다. 정말 별거 아닌 게 별거 아닌 게 아니라는 사실을 경험할 수 있었다. 정말 아무것도 아닌 기능인데 불편한 도구로 낭비되는 시간을 아낄 수 있었고 잦은 테스트와 다양한 시도를 해볼 수 있게 됐다. 사소한 기능개선도 디자이너에게 큰 도움이 된다는 사실을 얻을 수 있었다. 프로그래머 입장에서는 '속성창 몇 픽셀 옮겨주세요'라는 요청은 어렵지는 않지만, 매우 귀찮은 작업이다. 디자이너 입장에서도 번거롭고. 그런데 이런 과정을 개선하니 생산성과 완성도가 상승했다.

환경을 개선하고 난 다음에 한 작업은 UI 컴포넌트를 제작하는 것이었다. 기본적으로 코코스빌더에서 제공하는 UI가 있었으나 질적으로나 기능적으로나 팀에 어울리지 않았다. 일반적으로 컴포넌트는 하나하나 하드 코딩하곤 한다. 처음에는 간단하니까 프로그래머들의 부담이 없지만, UI가 늘어나고 수정이 잦아지면 프로그래머의 발목을 잡게 된다.

그래서 시간이 걸려도 새로운 컴포넌트를 개발하기로 했다. 당장은 귀찮아도 분명 시간과 레거시코드를 줄일 수 있다고 판단했다. 물론 일정을 관리하는 PM은 화를 냈고 디자이너들도 '빨리 작업해야 된다'며 기다리는데 난색을 보이기도 했다. 겨우겨우 설득해서 새 컴포넌트를 만들었다. 결과는 좋았다. 처음에는 만들어야 할 게 많아서 작업량이 많았는데 점점 줄어들었다. UI 작업을 디자이너가 오롯이 하게 되었기 때문이다.

디자이너들은 컴퍼넌트를 다양하게 조합해 상상하지도 못한 방식의 연출을 만들거나 새로운 기능을 구현했다. 디자이너들의 창의성이 기존 UI 작업에서는 불가능했던 디자이너들의 창의성이 솟아나기 시작했다. 또한, 일반적으로 UI는 자산으로 인식하지 않은 경우가 많은데 컴포넌트 개발로 자산화할 수 있었다.

[에이스프로젝트에서 작성한 몇 개의 컴포넌트]
- 가변적 컴포넌트 정렬. 서버에서 데이터를 받으면 글자가 바뀌면서 라벨이 겹치는 현상이 있어 이를 해결할 수 있는 컴포넌트를 제작했다. 유동적인 변화에도 디자이너가 UI 툴 작업을 할 수 있게 했다.

- 간단한 분기처리를 디자이너가 할 수 있게 했다. 디자이너는 케이스를 생성하고 값을 설정한 뒤 케이스별로 UI 작업을 다르게 할 수 있게 했다. 프로그래머는 스위치에 값을 설정하기만 하면 됐다.

- 각종 수치를 영역형 그래프로 보여주는 컴포넌트도 제작했다. 처음에는 코딩으로 구현하려고 하다가 자주 쓸 거 같아 만들었다. 사소한 기능도 속성을 줘 제작했다.

- 지정한 스트라이프의 모양대로 클리핑할 수 있는 컴포넌트도 제작했다. 이 컴포넌트는 놀랍게도 디자이너들이 창의적으로 사용해 흐림 효과, 프리즘 효과 같은 것도 만들 수 있었다. 기껏 해봐야 스텐실이나 만드는 정도겠거니 생각했는데 연출을 만드는 데 활용해 정말 놀라웠다.

결론

프로그래머들은 일련의 과정을 통해 디자이너들의 창의력에 놀랐다. UI 작업에 잔손이 가지 않게 된 관계로 중요한 개발에 더 집중할 수 있었고 레거시 코드를 많이 줄일 수 있어 만족스러워했다.

디자이너들은 작업환경 개선과 컴포넌트 제작으로 자유도를 높일 수 있었다. 다양한 형태의 UI 레이아웃을 만들 수 있었다. 무엇보다 프로그래머의 도움 없이 새로운 시도를 많이 해 볼 수 있어 다양한 기능을 도전해 볼 수 있었다. 만약 이런 자유도를 주지 않았다면 UI는 프로그래머 성향에 따라 시도가 결정됐을 것이다.

UI 작업은 욕심을 부릴 수 없었던 작업이란 인식이 변화하며 디자이너들의 죽어있던 창의성도 되살아났다. 그 동안 프로그래머의 구현 가능성에 초점을 맞추고 UI 작업을 전달하는 것에서 벗어났기 때문에 가능한 일이었다.

물론 상기에 언급한 방법들과 과정은 아직 완벽하지는 않다. 아직도 연결 연출 부분 등 프로그래머 손을 타는 부분이 꽤 있으며 UI 구조가 많이 바뀌면 변수, 함수 연결을 새로 해야 할 때가 있기도 하다. 그리고 아직 많은 버그들이 산재해있다. 그러나 쉽지는 않겠지만, 조금씩 개선해 나간다면 분명 더 나은 UI 개발 환경을 만들 수 있을 것이다.