사실 UI는 매우 중요하다. 게임이 아무리 잘 만들어졌어도, 잘못 만들어진 UI로 인해 불편함이 생기면 많은 유저들이 게임에서 이탈한다. 이런 중요성에 비해 UI에 신경 쓰는 개발사는 그리 많지 않다. 대부분의 개발사는 UI의 개발 우선도를 낮게 둔다.
그뿐만 아니다. 프로그래머와 디자이너들 역시 UI 개발 작업을 피한다. 대체 어떤 문제가 이런 상황을 만드는 걸까? 에이스프로젝트의 안현석 강영자. 그는 개선되지 않는 개발 환경이 이런 상황의 원인이라 이야기했다. 그가 경험한 UI 개발 과정의 문제점과 해결법에 대해 들어보도록 하자. / 디스이즈게임 우정혁 기자
■ 프로그래머와 디자이너. 그들에게 UI 작업이란?
모두가 중요하다고 생각하면서도 한편으론 하찮게 여기는 작업이 있다. 업무량도 많고, 개발 과정에서 수정이 굉장히 잦다. 그럼에도 불구하고 프로세스의 개선은 잘 이뤄지지 않는 분야다. 바로 UI 개발 작업이다.
프로그래머에게 UI 작업이란 무엇일까? 많은 프로그래머가 UI 작업을 단순 반복 작업이라 여긴다. 코딩해야 하는 작업량은 많은데, 기술적으로 배우는 것은 딱히 없고 코딩 과정이 노가다란 느낌을 받기 때문이다.
하드코딩을 해야 하는 상황도 많이 발생한다. UI는 개발에 많은 시간을 투자하지 않기 때문에 항상 우선순위가 밀린다. 때문에 개발 일정 막판에 급하게 구현되는 경우가 대부분이다. 이런 개발 과정에 비해 사용성 개선을 위한 수정 작업은 빈번히 일어난다.
많은 프로그래머들이 UI 작업을 싫어한다. 그래서 주니어 프로그래머에게 떠넘겨 해결하는 경우가 대부분이다. UI 작업 때문에 신입을 뽑는 경우도 있다.
그렇다면 디자이너들은 어떨까? 디자이너 역시 마찬가지다. UI 좌표를 따야 하고, 이미지 리소스를 잘라야 하고, 이걸 다시 아틀라스로 만들어야 하고, 툴 세팅을 해야 한다. 디자이너 입장에서도 UI의 컨셉을 잡고 구성을 만드는 작업 외에는 단순 반복 작업이 대부분이다.
디자이너 자신의 자율성이 낮고, 프로그래머 의존도가 높은 것도 문제다. UI 작업은 일의 특성상 수정이 많을 수밖에 없는데, 이를 해결하기 위해선 프로그래머의 도움을 받아야 한다.
수정 작업이 많아질수록 디자이너는 점점 프로그래머의 눈치를 보게 된다. 정말 고치고 싶은 문제가 생겨도 프로그래머가 바빠서 포기해야 하는 경우까지 발생한다.
이런 이유로 UI 작업은 프로그래머도, 디자이너도 모두 비효율적이고 불만족스럽게 받아들이는 작업이다. 하지만 대부분 사람은 이 부분에 대한 개선 의지를 별로 가지고 있지 않았다. 기존의 구식 프로세스와 도구를 개선해서 UI 작업을 좀 더 효율적이고 만족스러운 작업으로 바꾸는 방법이 필요했다.
■ 일단 좋은 툴이 필요하다!
<9이닝스 매니저>는 각종 데이터와 수치를 기반으로 한 야구 시뮬레이션 게임이다. 그러다 보니 데이터와 수치가 UI의 대부분을 차지한다. 덕분에 개발 초기에 예상되는 상황이 여러 가지 있었다.
다양한 스타일의 레이아웃이 쏟아져 나올 것으로 예상했다. 유저들이 인지하기 쉽고, 분석하기 쉬워야 하기 때문이다. 또한, 데이터를 기반으로 진행되는, 정적인 게임인 만큼 세련되고 동적인 UI 연출이 필요할 것으로 생각했다.
UI 개발 초기에 잡은 목표는 모두 세 가지였다. 첫째, UI 디자인을 최대한 디자이너 마음대로 할 수 있어야 한다. 둘째, 결과물의 생산성이 좋아야 한다. 셋째, 만들어진 UI는 재사용성이 고려되어야 한다. 기존의 방식으론 이를 충족시키기 힘들었다. 새로운 툴을 사용하기로 했다.
기준으로 삼은 좋은 툴의 조건이 몇 가지 있었다. 일단 디자이너가 사용할 수 있도록 사용법이 편하고 쉬워야 했다. 디자이너가 원하는 대로 뜯어 고쳐줄 수 있는 오픈소스 형식이어야 하며, 자체 UI 컴포넌트를 만들어 추가할 수 있어야 했다.
유니티와 코코스 빌더가 이 조건에 부합했다. 유니티는 UI 컴포넌트를 손쉽게 만들 수 있었다. 또한 툴 자체를 어느 정도 커스터마이징할 수 있었다. 하지만 유니티는 3D 엔진이기에, 2D 게임인 <9이닝스 매니저>에 적합한지엔 의문점이 있었다.
코코스 빌더는 풀 오픈소스였기에 입맛대로 고칠 수 있단 사실이 매력이었다. 2D 기반 엔진이기에 2D 게임을 개발하는 데 유용한 기능이 굉장히 많았다. UI 컴포넌트도 일단 추가는 가능했다.
결국 코코스 빌더가 선택되었다. 디자이너 입장에선 유니티보다 다루기 쉽고, 포토샵과 병행해 사용하기에 부담 없을 정도로 프로그램이 가벼웠기 때문이다. 프로그래밍 팀이 코코스 2d-x를 다룬 경험이 있고, 프로그램이 무료란 점도 강하게 작용했다.
■ UI 작업환경을 개선해보자!
이렇게 툴을 선택하고, UI 작업 환경을 개선하기 위한 첫 개선을 시도했다. 먼저 생산성을 높이기 위해 툴 커스터마이징을 진행했다. 디자이너의 부탁을 모두 수용했다. 속성 창을 프로젝트 창 옆에 붙이고, 포토샵처럼 가이드라인을 만들고, 타임라인을 오른쪽에 붙였다.
모바일 게임은 그 특성상 단말기 확인이 잦게 일어난다. 단말기마다 해상도가 다르기 때문이다. 하지만 디자이너가 디자인하더라도, 프로그래머의 도움 없인 확인이 불가능했다. 디자이너가 이를 자유롭게 확인할 수 있도록 개선했다.
디자이너가 툴에서 작업을 완료하면 서버에 업로드할 수 있는 기능을 만들었다. 디자인 테스트 빌드를 만들어 디자이너가 프로그래머의 도움 없이 디바이스를 확인할 수 있도록 해주었다.
사실 별것 아닌 일이었다. 그런데 이런 변화 하나로 프로그래머가 굉장히 편해졌다. 디자이너들은 낭비되는 시간을 아낄 수 있게 되었고, 잦은 테스트와 다양한 시도를 해볼 수 있다며 만족스러워했다. 사소한 기능개선도 디자이너, 프로그래머 모두에 큰 도움이 되었다.
■ UI 컴포넌트 개발이 필요하다
이렇게 작업환경을 개선하고, UI 컴포넌트 개발을 시작했다. 코코스 빌더에서 기본으로 제공하는 UI 컴포넌트가 있긴 했지만, 정말 기본적인 기능만 제공했기에 이것들만으론 부족했다. 디자이너들이 하고 싶은 일은 너무 많았다.
이 부분에 대한 고민이 있었다. 이걸 꼭 컴포넌트로 만들어줘야 할까? 그냥 코딩으로 해결해주면 안 될까?
요구사항을 코드로 구현하는 것은 어렵지 않았다. 하지만 진짜 문제는 구현이 아니었다. 적용된 결과물이 괜찮다면 이를 많은 곳에 적용해달란 요청이 들어왔다. 최종적으론 디테일하고 번거로운 부분까지 지정해 작업 요청이 들어왔다.
당장 하드 코딩으로 기능을 구현해주는 건 빠르고 쉬운 해결 방법이지만, UI가 늘어나고 수정이 잦아지면 프로그래머의 발목을 잡을 수 있단 결론을 내렸다. 배보다 배꼽이 커지는 현상이 발생하는 것은 막아야 했다. 이를 위해 시간이 걸려도 UI 컴포넌트를 개발하자 결정했다.
컴포넌트를 개발해둔다면 당장은 귀찮아도 이후엔 시간을 절약하고 레거시 코드를 줄일 수 있을 것으로 생각했다. 만들어진 결과물과 그 방식은 언제 어디서나 다시 사용할 수 있었다.
물론 저항도 많았다. 일정을 관리하는 PM은 무슨 컴포넌트냐, UI가 왜 이리 늦게 나오냐 이야기했다. 디자이너들은 자신들이 당장 작업해야 하는데, 컴포넌트가 완성될 때까지 얼마나 기다려야 하는지 질문했다.
결국 미래를 보자고 설득하는 수밖엔 없었다. 다행히 설득이 잘 되었고, 그 결과물로 30여 개의 자체 컴포넌트를 제작 완료할 수 있었다.
■ 디자이너는 항상 프로그래머가 상상하지 못하는 걸 만들어낸다
유저가 새로 얻은 선수 카드가 있다. 여기에 "New"라는 마크가 보여야 한다 가정하자. 보통은 이를 위한 코딩을 따로 진행한다. 하지만 선수 카드에 다양한 상태가 생기게 되고, 코딩을 해야 하는 일이 한 번으로 끝나지 않는다면 어떻게 될까.
이를 해결하기 위해 간단한 분기는 디자이너가 처리할 수 있도록 컴포넌트를 만들었다. 디자이너는 자신의 필요에 따라 직접 케이스를 생성하고, 케이스별로 UI 작업을 다르게 할 수 있게 됐다. 프로그래머는 스위치값만 설정해도 이에 맞는 UI를 활성화하는 것이 가능해졌다.
선수 카드의 등급, 상태 표시 작업을 수월하게 할 수 있었다. 컴포넌트를 만들지 않았다면 선수 카드 하나하나에 코딩을 해야 하는 일이었다.
스텐실 효과도 만들었다. 아마 다들 미술 시간에 많이 해보셨을 것이다. 그림 모양 외에는 물감을 넣어 찍어내는 기법이다. 이미지 모양 그대로 클리핑할 때 자주 사용하는 방법이다. 디자이너들은 세련된 연출을 하기 위해 이 기능이 필요하다 이야기했다. 이 부분을 수용해 컴포넌트로 만들었다.
프로그래밍 팀은 이 기능을 별로 중요하지 않게 생각했고, 삼각형 모양으로 이미지를 자른다던지, 이미지 클리핑에 쓰이는 정도를 상상하고 있었다. 하지만 디자이너들은 프로그래머가 상상하지 못하는 방식으로 이를 사용했다.
디자이너들은 스텐실 기능을 중심으로 기존에 만들어진 다른 컴포넌트를 활용했다. 화면 전환 시의 왜곡 연출, 선수 카드 획득 시의 프리즘 효과와 같은 온갖 세련된 결과물을 뽑아냈다. 프로그래머는 스텐실 기능을 단순히 "이미지에 구멍을 내는 것"으로 인식하고 있었는데, 디자이너들은 더 멋진 결과물을 바라보고 상상하고 있던 것이다.
프로그래머가 할 일이 점점 줄어들고, 정말 중요한 작업에 집중할 수 있는 시간이 늘어났다. 디자이너들은 다양한 컴포넌트를 조합해 새로운 기능을 발견하고 UI에 적용했다. 컴포넌트 개발을 통해 UI 개발이 점점 자산화되고, 의미가 생기기 시작했다.
이런 변화를 통해, 디자이너는 자신의 마음대로 UI를 만들고, UX를 테스트할 수 있는 환경을 얻게 되었다. 이를 통해 테스트마다 UI의 개선 역시 크게 이뤄졌다. 프로그래머의 도움 없이 새로운 시도를 많이 해볼 수 있게 되었다.
생산성도 좋아졌다. 컴포넌트 제작으로 빠른 작업과 수정이 가능해지자, 프로그래머와 디자이너 모두의 시간이 절약되었다. 개선된 작업환경으로 디자이너는 UI 퀄리티업에 집중할 수 있게 되었다.
■ 마무리
내부 동료들이 어떻게 생각하는지 간단하게 인터뷰를 해보았다.
디자이너들은 "프로그래머의 도움 없이 다양한 UI를 시도할 수 있어서 좋았다", "욕심을 마음껏 부릴 수 있어서 좋다", "죽어있던 크리에이티브가 살아났다"라는 대답을 했다. 그동안은 프로그래머가 구현 가능한 수준에서 디자인을 해야 했는데, 이젠 마음껏 여러 시도를 할 수 있으니 크리에이티브가 살아났다고 말했다.
이런 변화는 분명 쉽지 않은 일이다. 하지만 계속해서, 조금씩 개선해 간다면 분명 더 나은 UI 개발환경을 만들 수 있을 것이다. 우리도 이 부분이 완전하진 않다. 계속 노력해나갈 것이다.
