오오니시 마사토 사운드 프로그래머
유저 인터페이스, 줄여서 UI는 사용자와 기기를 연결해주는 매개체다. 유저는 UI를 통해서 기계에게 명령을 입력하고, 기계는 이를 받아들인 뒤 수행 여부를 화면상의 UI를 통해서 출력하는 식으로 소통이 이루어진다. 이러한 과정이 너무도 당연한 것이기 때문에 유저들은 때론 UI에 대해서 잘 인지하지 못하기도 한다. 그러나 종종 UI를 이해하지 못해서 기기 사용에 불편을 겪는 사람도 존재하며, 개발사들은 이러한 경우를 상정해서 UI를 설계해나가게 된다. 특히나 기존과 다른 것을 만들 때, 이를 유저들이 보다 편하게 받아들일 수 있도록 인터페이스 설계에 더욱 더 신경 쓰게 된다.
닌텐도 스위치는 출시 당시 기존 시장에 없던 새로운 컨셉의 콘솔로 주목을 받았다. 거치형, 혹은 휴대형으로 구분이 되어있던 기존의 콘솔과 달리 두 가지가 가능한 하이브리드 형태였기 때문이었다. 이는 기존의 닌텐도 기기와도 달랐던 만큼, UI도 처음부터 다시 설계할 필요가 있었다.
닌텐도 개발부의 오노 스미카즈 소프트웨어 엔지니어, 타키구치 타카히로 아티스트, 오오니시 마사토 사운드 프로그래머는 UI는 여기에 닌텐도 스위치의 컨셉이 이전 세대 콘솔인 Wii나 Wii U 등과 지향점부터도 달랐기 때문에 이 과정은 필연적이었다고 밝혔다. 종합 엔터테인먼트 기기로서 콘솔을 조명한 것이 Wii 시리즈였다면, 닌텐도 스위치는 다시 게임을 즐긴다는 콘솔 본연의 목표를 다시 지향했기 때문이다. 여기에 게임기를 켜고, 게임을 하기까지의 과정도 명쾌하고 경쾌해야 한다는 슬로건 아래에 UI를 각 부서가 협심해서 지금의 모습이 나오게 됐다는 것이다. 세 개발자들은 이 과정의 세부 내용을 CEDEC 2018 무대에서 하나하나 재조명해나갔다.
세 개발자는 닌텐도에서 본체 인터페이스 개발이 게임 개발자들과 같은 부서에서 이루어진다고 밝혔다. 본체 인터페이스에 대한 닌텐도의 관점은 기기에 처음부터 내장되어있는 소프트웨어인데, 소프트웨어라는 점과 인터페이스에 들어가는 요소들이 게임과 유사하기 때문이다.
닌텐도에서 처음 출시한 본체 UI가 내장된 콘솔은 게임큐브였으며, 그 이후로 지속적으로 발전하면서 다양한 기능들이 추가됐다. Wii에서부터는 게임 콘솔을 넘어서 인터넷이나 커뮤니케이션 등 종합 엔터테인먼트 기기로서 기능도 갖추게 됐다. 이렇듯 시간이 지나면서 점차 다양한 기능이 추가되었고, 인터페이스 역시도 변화를 겪을 수밖에 없었다. 이는 닌텐도 스위치도 마찬가지였다.
그러나 닌텐도 스위치의 경우는 전 세대의 콘솔들과 다른 위치에 있었다. Wii 때는 게임을 즐기는 것 외에도 다양한 기능을 할 수 있는 콘솔이라는 것이 Wii만의 독창적이고 독자적인 포인트였다. 그렇기 때문에 게임 외 다른 기능을 부각시키는 인터페이스가 유저들에게 어필할 수 있는 포인트였다. 닌텐도 스위치를 처음 개발할 당시에 닌텐도에서는 스위치도 이런 점은 스위치만의 독창적인 요소가 될 것이라고 여겼었다. 그러나 시간이 지나고 기술이 발전하자 이러한 예상은 엇나가게 된다. 스마트폰과 태블릿 등 게임도 즐길 수 있고, 각종 다양한 기능을 내재한 기기들이 놀라울 정도로 발전했기 때문이다. 그에 따라 닌텐도에서는 개발 방향을 수정하게 됐다.
닌텐도에서 수정한 닌텐도 스위치의 지향점은, 게임 콘솔은 게임으로 논다는 기능에 특화되어야 한다는 것이었다. 본래 콘솔이 게임을 즐기기 위해 만들어진 만큼, 이것에 충실할 때 비로소 다른 기기와 다른 독자적인 요소가 드러난다고 여겼기 때문이다.
닌텐도 스위치의 UI를 구성할 때 개발부에서는 압도적으로 명쾌하게, 압도적으로 경쾌하게라는 두 가지 슬로건을 내세웠다. 명쾌하게 한다는 의미는 간단하게 말해 유저가 헤매지 않도록 단순명료하게 구성한다는 것이다. 이러한 점은 UI 개발자들이라면 다들 공감하지만, 정작 이를 UI로 어떻게 표현하냐는 문제가 남는다.
타키구치 아티스트는 우선 예전 디자인을 하나하나 훑어서 복기하는 과정을 거쳤다고 밝혔다. 예전 디자인에서 쓸만한 것을 골라서 다양하게 응용해보자는 생각이 있었기 때문이다. 그러다 보니 Wii 시리즈와 닌텐도 스위치의 차이점이 드러났고, 달라져야 한다는 것을 새삼 느꼈다고 첨언했다.
Wii 시리즈는 다양한 기능을 써보자는 것과, 유저가 모은 콜렉션이 이렇게 있다는 것을 강조하는 걸 중요시했다. 그래서 게임에 관계없는 뉴트럴한 기능도 게임과 뒤섞여있는 UI를 갖고 있었다. 그렇지만 닌텐도 스위치는 앞서 말한 것처럼 게임에 좀 더 집중하는 디자인을 요구했다. 그렇기 때문에 UI 디자인이 게임이 좀 더 부각되는 형태가 될 필요가 있었다.
또 한 가지 유의할 사항은, 닌텐도 스위치가 게임 기능을 중시하는 것은 맞지만, 그 외에 다른 기능을 완전히 배제하는 기기가 아니라는 점이었다. 앨범 및 스크린샷 기능, e숍 등 게임 외 다른 기능도 유저들에게 인지시킬 필요가 있었다.
디자인팀에서 가장 우선적으로 한 작업은, 기존에 뒤섞여있던 기능들을 뒤섞지 말고 구분하는 것이었다. 게임은 게임대로, 게임과 직접적으로 연관이 되지 않은 기능은 각각 분류해서 따로 나눈 것이다. 그런 뒤에 게임이 우선이라는 룰을 적용해 게임 부분의 아이콘을 키웠으며, 시스템 및 기타 기능 아이콘은 줄이는 등 차이를 주게 됐다.
사이즈와 밀도 차이를 통해서 각 기능과 해당 아이콘을 구분하는 것은 UI 개발에서 기초적인 작업이다. 이와 같은 작업을 한 뒤에는 어떻게 나열하느냐 하는 문제도 존재했다. 여기에서 디자인팀은 다양한 시도를 했다. 중요한 것은 상단, 덜 중요한 것은 하단에 놓는다는 상하의 법칙과, 범주의 넓이에 따라서 구분하는 매크로-미크로의 법칙을 적용했다.
이 법칙에 따라 유저 계정, 배터리 상태 등 중요한 부분이 제일 위에 올라왔으며, 게임은 중단에 가장 큰 아이콘을 할당해서 배치하고 하단에 시스템 아이콘을 놓는 형태로 초기안이 만들어졌다. 이 초기안은 단순했지만, 직관성은 떨어졌다. 화면상에서 레이어 구분을 하긴 했지만, 한 화면에 여러 개가 동시에 있는 형태로 보였기 때문이다.
이 부분은 전화번호를 나누는 법칙을 적용해서 해결해나갔다. 전화번호는 일반적으로 3-3-4 등 셋에서 넷 단위로 숫자를 끊어서 표기하는데, UI도 각 레이어당 세 개에서 네 개씩 끊어서 유저들에게 보이도록 설계를 한 것이다. 게임 타이틀은 한 화면에 최대 4개만 노출되도록 설정했으며, 시스템 아이콘은 컬러 아이콘 3개에 흑백 아이콘 3개로 구성했다. 최하단은 버튼 UI와 조이콘 상태창 아이콘 3개로 구성해 3에서 4개로 끊어서 배치한다는 법칙을 지켜서 디자인해나갔다.
UI를 실제로 적용하는 룰은 레이어와 아이콘을 디자인할 때뿐만 아니라 스타일이나 스크롤 속도, 로고 등을 만들 때도 필요하다. 프로그래밍팀과 사운드팀에서는 특히 화면의 전환 등의 상황에 주목했다. 닌텐도 스위치에서 본체에서 화면이 전환되는 경우의 수를 체크했을 때, 약 400개 이상이나 됐기 때문이었다.
이 부분에서 가장 중요시한 것은, 개발자가 헤매면 유저도 헤맨다는 점이었다. 따라서 최대한 단순하게 갖춰나갈 필요가 있었다. 여기에 위화감이 없어야 한다는 점도 추가됐다. 특히나 프로그래밍팀은 커서에 관련된 룰을 정할 때는 위화감이 없어야 한다는 것을 핵심으로 삼고 알고리즘을 구성했다.
커서 알고리즘은 최초에는 아이콘과 커서의 폭을 탐색하고, 뒤이어 커서와 아이콘 간의 거리를 체크하는 형태로 구성했다. 여기에 처음에는 중심부에 있는 것을 우선한다는 룰을 가정하고 설계에 들어갔다. 이러한 알고리즘을 구성하면서 문제가 발생했다. 중심부터 거리 순으로 체크를 할 때 아이콘의 어느 지점을 거리를 재는 척도로 삼아야 하는지도 고민해야 했기 때문이다. 아울러 그것보다 좀 더 중요한 아이콘에 커서가 먼저 가야 한다는 의견도 있었다.
이러한 부분들을 종합했을 때 알고리즘만으로는 커서에 대한 법칙을 정의하기 어려웠다. 이는 디자인팀과의 협의를 통해서 해결이 되었다. 디자인팀이 버튼에 대한 룰을 좀 더 명확히 했기 때문이다. 그 개선안은 배열에 예외가 없도록 일렬로 진열한다는 것과, 아이콘을 그리드에 맞춰서 정렬한다는 것, 아이콘은 종류별로 완전히 디자인을 다르게 나눈다는 것이었다. 이러한 버튼 배치룰에 프로그래밍팀은 기존 알고리즘을 더했으며, 여기에 좌상단부터 우하단으로 내려간다는 룰을 알고리즘 논리의 세 번째 항목으로 덧붙였다.
그 다음에는 사운드팀이 버튼을 눌렀을 때 나는 효과음에 대해서 고민해야 했다. 오오니시 사운드 프로그래머는 개발부에서는 닌텐도 스위치가 유저들에게 소리로 상황을 알기 쉽게 전달하도록 만들자는 원칙을 세웠다고 밝혔다. 이에 의거해서 각 상황을 상정하자 300가지의 상황이 도출됐고, 이를 분석하면서 사운드를 설계해나가는 과정을 거쳤다.
최초에 효과음을 분류하는 룰은 '어떤 상황이라는 것을 전달할까?'에 의거해서 소리를 분류하자는 것이었다. 예를 들면 안내하고 싶은 상황에서는 안내음이, 주의해달라고 요청하고 싶은 상황이면 주의음이 난다고 설정한 뒤, 카테고리 안에 있는 상황별로 조금씩 차이를 두는 방식이었다. 그렇지만 이러한 방법에는 문제가 있었다. 어떤 음으로 주의해달라고 하는 상황을 전달해야 할까? 이 부분이 모호했기 때문이다. 실제로 이런 메시지는 효과음만으로는 전달되는 것이 아니었다. 효과음에, 문자와 아이콘 등 다양한 요소가 결합되어야만 전달되는 것이다.
또한 어떤 상황이 주의, 안내, 확인인지 확실하게 구분하는 것도 어려웠다. 예를 들어 소프트를 종료한다는 메시지는 그 셋 중 어디에 집어넣어야 할지 모호하다. 상황에 따라서 다르기 때문이다. 유저가 실수로 소프트를 종료하면 주의나 확인일 수도 있고, 유저가 의도적으로 종료하려고 하면 안내가 되기 때문이다.
오오니시 사운드 프로그래머는 이 고민을 디자인팀에서 해결해줬다고 밝혔다. 디자인팀에서 동일 종류 아이콘을 동일한 양식으로 만든 것처럼, 사운드도 동일한 상황에 동일한 음이 나오도록 하는 것이 어떻냐고 제시했기 때문이었다. 이를 토대로 사운드팀은 정상, 에러, 경고라는 세 가지 카테고리로 다시 상황을 분류하고 그 상황에 나오는 사운드를 통일했다. 이 부분에서 오오니시 사운드 프로그래머는 부서 간의 의논이 중요한 포인트라고 강조했다. 게임 개발도 그렇지만, 하드웨어의 UI를 구현하는 것도 다양한 부서 간의 협력을 전제되는 작업이다. 그런 만큼 서로가 일관성이 있고, 스무스하게 일을 하기 위해서는 의논이 필수적이다. 뿐만 아니라 팀 내에서는 풀리지 않았던 일이, 다른 팀의 시각에서는 쉽게 해결할 수 있는 문제이기도 하다. 그런 점들을 개발 중에 생각해볼 필요가 있다고 오오니시 사운드 프로그래머는 조언했다.
효과음에 대한 설명 이후 오노 엔지니어는 프로그래밍팀에서 주로 작업한 부분에 대해서 소개했다. 프로그래밍팀에서는 어떤 명령을 입력한 뒤에, 이를 처리하는 과정과 애니메이션이 나오는 과정을 구현해나가야했다. 앞서 디자인팀과 사운드팀에서 작업한 UI 버튼이나 아이콘 디자인, 레이어 구성, 효과음이 명확한 룰을 통해서 명쾌하게 만들어나가는 과정이었다면, 프로그래밍팀에서는 경쾌하게, 즉 빠른 속도로 이 모든 과정이 이루어지도록 해야 했다.
오노 엔지니어는 유저가 UI를 접하는 과정을 자동차를 멈추는 과정에 비유했다. 운전자가 브레이크를 밟고 자동차가 감속을 시작하고, 일정 거리 이상을 주행한 뒤에 자동차가 완전히 멈추게 된다. 유저와 콘솔로 생각하면 유저가 버튼을 누르고, 로딩 이후에 다른 화면이 뜨는 과정이 이와 유사하다는 것이다.
빠른 처리를 위해서는 이 세 과정에서의 리드타임을 최대한 줄이는 것이 필요했다. 그래서 프로그래밍팀은 우선 이 세 과정을 좀 더 세부적으로 나눠서 파악하고, 리드타임을 없애거나 통합할 수 있는 과ㅌ정을 찾아나갔다. 처음 파악한 결과 버튼을 누르고 의사결정을 할 때의 애니메이션-특정 씬 종료 처리-특정 씬에서 퇴장하는 애니메이션-새로운 씬을 구축 처리하는 과정-씬에 입장할 때의 애니메이션 총 5개의 과정으로 분류가 됐다.
이를 최초에는 순차적으로 진행했지만, 리드타임을 줄이기 위해서 다양한 시도가 이어졌다. 처음에는 결정 애니메이션과 종료처리 작업을 동시에 진행하면서 리드타임을 줄였고, 그 뒤에는 애니메이션 타임을 0초로 만들면서 극한의 빠르기를 구현했다. 이 빠르기를 구현하기 위해서 오노 엔지니어는 애니메이션용 리소스를 단 세 종류만 구분했으며, 여기에 각 상황별로 세부적으로 나눈 결과 쉐이더에는 총 5개의 폴리곤만 사용됐다.
이렇게 극한으로 속도를 끌어올리는 방법에는 한 가지 맹점이 있었다. 각 팀이 전부 체험해본 결과, 너무 순식간에 일이 처리가 됐기 때문에 오히려 자신이 어떤 결정을 하고, 어떤 일이 벌어졌는지 인지하는 것이 늦어졌던 것이다.
프로그래밍팀에서는 유저가 자신이 어떤 결정을 하고, 그것이 어떤 식으로 진행이 되는지 인지한 이후에 변화가 이어져야 비로소 유저는 변화에 대해 인식을 한다는 것을 테스트를 통해 파악했다. 그래서 애니메이션 타임은 최대한 짧게, 그러나 0이 되지 않도록 설정했다. 그리고 처리 과정을 재해석하면서 통합하는 작업에 들어갔다. 버튼을 누를 때 처리작업이 동시에 진행되는데, 이 처리 과정을 유저가 인지할 수 있도록 특정 씬에서 퇴장하는 애니메이션, 즉 페이드아웃을 처리작업과 같이 진행하도록 한 것이다.
버튼을 눌렀을 때 결정하는 애니메이션은 0.2초간 진행되고, 그 사이에 처리작업은 절반 가량의 시간인 0.1초 사이에 끝난다, 이후 바로 새로운 씬을 구축하는 작업이 진행되고 페이드인, 즉 새로운 씬으로 들어가는 애니메이션이 버튼을 누른 뒤 0.2초가 될 때 바로 시작되도록 했다. 그럼으로써 버튼을 눌렀을 때 자신이 어떤 결정을 했나 애니메이션을 통해서 확인하고, 그 사이에 점차 변화가 일어나는 것을 유저가 인지하고 난 뒤에 변화가 찾아오도록 설계한 것이다. 앞서 리드타임을 완벽히 없앴을 때보다 속도는 조금 느리지만, 유저가 변화와 변화의 속도에 대해서 인지를 하기 때문에 좀 더 자연스럽고 빠르게 느껴졌다고 오노 엔지니어는 덧붙였다.
오노 엔지니어는 화면의 전환에 있어서 가장 신경을 많이 쓴 부분은, 게임을 종료하고 본 메뉴로 돌아가는 부분이라고 밝혔다. 여기에서 프로그래밍팀이 신경 쓴 부분은 크게 두 가지였다. 하나는 어떻게 유저가 버튼을 최소한으로 누르도록 하는 것과, 다른 하나는 유저가 문장의 의미를 빠르게 파악하도록 하는 것이었다.
조작을 최소화하기 위해서 프로그래밍팀이 취한 것은, 유저가 하는 행동을 신뢰하는 것이었다. 즉 종료 버튼을 눌렀을 때 '진짜?'라고 되묻지 않고 바로 종료하겠습니다, 라고 유저의 명령을 믿고 바로 실행할 수 있도록 준비하는 것이었다. 그래서 종료 버튼을 누른 뒤에 바로 우측 하단에 있는 확인 버튼으로 커서가 이동하도록 프로그래밍을 했다고 오노 엔지니어는 밝혔다.
일반적으로 글을 읽을 때, 유저들은 좌측에서 우측으로 읽는다. 이를 토대로 소프트웨어 종료 취소를 오른쪽에 두어야 하고, 확인을 왼쪽이 좋다는 의견도 있었다. 혹은 이를 변경하지 않아도 커서가 왼쪽부터 떠야 한다고 보기도 했다. 그렇지만 사람이 문자를 빠르게 해독하고자 할 때 일반적으로 좌측 상단에서 우측 하단으로 대각선 방향으로 본다는 점 때문에 유저의 의도와 반대된다고 여기는 메시지는 좌측에, 부합한다고 여기는 메시지는 우측에 놓게 됐다.
좌상단에서 우하단으로 가는 독법은 본문 메시지에도 큰 영향을 미쳤다고 오노 엔지니어는 덧붙였다. 실제로 닌텐도 스위치 게임 종료 화면을 보면 소프트웨어를 종료하겠습니다. 라는 문구가 좌측 상단에 위치한다. 그렇게 함으로써 유저에게 상황을 좀 더 빨리 전달하는 것이다. 최초에는 이 문구과 본문 맨 끝에 있었는데, 잘 읽히지가 않았다고 타키구치 아티스트는 회고했다. 따라서 좌측 상단에 본문 핵심 내용을 배치해서 유저에게 빠르게 의미를 전달하고, 그 의미와 짝을 이루는 부분을 우측 하단에 배치하게 됐다고 밝혔다.
여기까지의 명쾌함과 경쾌함은 어렵거나, 혹은 느릴 때 발생하는 불쾌감을 줄이는 과정이었다고 오오니시 사운드 프로그래머는 설명했다. 그렇지만 진정 명쾌하고 경쾌한 UI는, 단순히 불쾌감을 줄이는 것만으로는 부족했다. 앞서 말한 슬로건처럼 압도적으로 명쾌하고, 경쾌하기 위해서는 그만큼 유저에게 즐겁고, 쾌적한 경험을 제공해야했다.
이러한 기조는 전 세대 콘솔인 Wii 개발 때부터 존재했다. Wii는 BGM과 효과음을 통해서 특유의 편안하고 매력적인 분위기를 조성했기 때문이다. 그렇지만 닌텐도 스위치는 게임에 집중한다는 의미로 홈 메뉴의 BGM은 없앴다. 대신 그만큼 효과음을 통해서 유저에게 매력을 전달하도록 계획을 세웠다.
오오니시 사운드 프로그래머는 매력적인 효과음을 만들기 위해 세 가지 법칙을 적용했다. 각 효과음의 종류에 따라, 혹은 해당 효과음이 들어가는 아이콘의 종류에 따라서 음의 높낮이 등에 변화를 준 것이다. 이를 오오니시 사운드 프로그래머는 '음의 움직임'이라고 정의했다. 유저가 커서를 이동할 때마다 음색, 높낮이가 변화하는 것이 마치 음이 커서에 맞춰서 이동하는 것 같기 때문이었다.
최초에는 이 음들이 각각 다른 길이로 재생이 됐지만, 통일감을 부여하기 위해서 음의 길이를 동일하게 맞췄다. 이로 인해서 음에 리듬감이 생겼다고 오오니시 사운드 프로그래머는 덧붙였다. 또한 메뉴에서 다른 메뉴로 전이할 때, 그 관계를 연결짓도록 음을 만든다는 이른바 음의 연계성 원칙도 세웠다.
이러한 과정을 통해서 닌텐도 개발부에서는 유저가 즐거움을 더 배가할 수 있도록 했다. 그러나 스트레스는 어떠한 경우에도 완벽히 없애는 것이 불가능하며, 실제로 개발자들이 전혀 생각지도 못한 부분에서 문제가 발생하기도 한다. 실제로 UI 구현 후 초창기에 아이들을 대상으로 테스트하다가 갑자기 러시아어로 기본 언어 설정이 바뀌어버리는 일도 생겼기 때문이다.
세 개발자들은 본체 개발 과정에 대해서 되짚어가면서, 마지막으로 두 가지를 강조했다. 하나는 당연하다고 생각했던 것을 다듬어서 특징으로 만들어가는 것이었다. 앞서 닌텐도에서는 닌텐도 스위치를 '게임을 즐긴다는 것에 집중한 기기'라고 방향을 잡았다고 소개했는데, 이는 사실 콘솔로서는 당연한 부분이다. 그렇지만 이 부분을 철저하게 파고, 집중한 결과 닌텐도 스위치만의 특징 있는 UI를 만들어갈 수 있었다는 것이다.
그리고 UI를 만들 때는 각 팀이 따로따로 작업하는 것이 아니라 다 같이 공유해야 한다는 점을 강조했다. UI는 단순히 기능을 드러내기 위한 틀이 아니라, 마치 게임처럼 사운드, 프로그래밍, 디자인 등 모든 분야가 총집합된 분야이기 때문이다.
※8월 22일 개최된 일본 개발자 컨퍼런스 CEDEC 2018의 강연 정보와 뉴스를 현지에 나가 있는 박광석, 윤서호 기자가 생생하게 전달해드립니다 ▶ 인벤 뉴스센터: https://goo.gl/ha5vNc
Ruudi@inven.co.kr