이 글은 UX, 너마저!라는 제목으로 UX 팩토리의 UX Design Talk 주간에 맞춰 작성한 글입니다.

"웹 서비스 벤쳐 회사는, 서로 독립되어 있지만 동등하고 중요한 두 부류로 대변할 수 있다: 서비스를 제작하는 개발팀, 그리고 그것을 사용할 수 있도록 만드는 디자인팀.

이것은 그들의 이야기다."

 저는 2007년 9월 이후부터 스토리베리(STORYBERRY)라는 서비스를 기획해 온 이즈데드라고 합니다.

 UX Design Talk로 썰을 풀 수 있는 자리를 마련 해 주신 UX팩토리의 황리건님께 감사를 드리며, 스토리베리를 만들어오며 겪었던 사용성 저하 사례들과, 문제 해결을 위한 삽질과 고난의 경험을 "UX, 너마저!" 라는 제목으로 풀어나가 보겠습니다.

사례 1: 바벨탑

 앨런 쿠퍼(Alan Cooper)옹의 명저, 「정신병원에서 뛰쳐나온 디자인」(The Inmates Are Running The Asylum)을 읽다보면, 개발자와 디자이너, 아니, 개발자와 일반인이 사용하는 언어의 차이가 얼마나 심각한 문제를 초래하는지, 400페이지 내내 설명합니다.

 개발자들은 현실에서 사용하는 언어(Language)보다 규약어(Protocol)에 익숙합니다. 따라서 대부분의 개발자들은 (그럭저럭) 쉽게 서로 이야기를 나눌 수 있습니다.

 문제는 디자이너와 개발자가... 아니, 사용자와 개발자가 직접 만났을 경우입니다. 재앙이라고도 할 수 있는 이 순간이 찾아오면, 둘 중 누군가는 포기하거나 쓰러지게 됩니다. (일반적으론 사용자들이 먼저 넉다운하죠.)

 같은 주제를 다루지만 다른 언어를 사용하고, 결국에는 같은 사회에 속해있지만 다른 문화를 소비하게 됩니다. 그리고 서로를 이해하지 않게, 못하게 되지요. 소위 현대의 바벨의 탑은 개발자와 일반인이 서로의 언어를 이해하지 못하게 만들었습니다.

 하지만 문제는 그게 아니었습니다. 일반인은 결국 개발자가 만든 도구가 필요하고, 개발자는 자신들이 만든 도구를 사용할 일반인이 필요했다는 사실…

 2007년 말, 저희가 직면한 문제가 바로 그것이었습니다.

 

 위 스크린샷은 XML 기반의 태그를 활용해, 웹 상에서 스토리베리 컨텐츠를 만드는 툴인 고급 에디터(현재는 스토리에디터)의 2007년 10월 경 초기 버전의 모습입니다.

 초기 버전에서 가장 큰 문제이자, 오랜 시간동안 고쳐지지 않았던 부분 중 하나는, 바로 미디라는 버튼이었습니다.

 저 버튼의 정체는? 미디어의 준말(?)이지요. 사진과 동영상, 음악 파일들을 올리고 관리하는 메뉴였습니다. 하지만 어째서 미디가 된 걸까요?

 저 버튼이 만들어지기까지의 과정을 간략히 적어보겠습니다.

1. 미디어 관련 파일들이 저장되는 공간이 필요하다.
2. 메뉴와 버튼을 만들었다.
3. 어? 버튼에 “미디어”라고 적으려 했는데 글자가 너무 길다.
4. 뭐 대충 툴을 써보면 미디가 미디어인 것쯤은 눈치 채겠지?
5. 최대 2글자로 정리해두니 디자인적으로 버튼들이 깔끔하니 좋구나.

 결국 개발 과정에서 느끼는 규약어와, 사용자들이 보고 듣고 느끼는 언어간의 차이를 인지하지 못한 저 UX적인 실패는, 약 3개월 후가 되어서 간신히 고쳐졌습니다. 하지만 그 3개월 동안 신규 가입자가 꾸준히 늘어왔다는 사실이 저희의 마음을 아프게 만들었습니다. 신규 유저들이 사진 넣는 법을 몰라서, 스토리를 안 만들 줄은 몰랐거든요.

사례 2: 자동 회전문

 유동인구가 많은 커다란 빌딩 중에는, 트래픽 컨트롤이나 냉/난방의 이점을 취하기 위해 회전문이 달려있는 경우가 많습니다. 하지만 가끔 ‘전자식 자동 회전문’이 달린 경우가 있지요. 손을 대면 자동으로 멈추고, 느릿느릿한 회전 속도에 맞춰서 걸어야 하고, 물건을 흘리면 대참사가 일어날 수도 있는 멋진 자동문이지요.

 스토리베리의 양대 에디터, 스토리에디터와 스토리포토에서 언급되었던 문제가, 바로 그런 문제였습니다.

 

 두 스크린샷에 공동적으로 보이는 여백이 눈에 띄시나요? 저런 배려는 주로 어도비 포토샵에서 볼 수 있는데요, Copy & Paste를 했을 경우, 사람들의 눈에 띄는 위치에 보여주기 위해, 눈에 보이는 화면의 (0, 0) 위치에서 상하로 약 20px 정도 떨어진 위치에 클립보드 이미지를 붙여 넣습니다.

 스토리베리 툴의 개발 과정에서도, 사용자들을 배려하여 사진이 삽입되는 위치에 여백을 주고 시작합니다. 다만 개발자들의 디자인에서 고려하지 못했던 사실은, 우리가 제공하는 화면은 사진이 항상 눈에 들어올 정도로 작았고, 게다가 우리는 사진을 (0, 0)으로 보내는 것이 결코 쉽지 않았다는 점이었습니다.

 게다가 사진을 클릭하고, 휠을 돌리면 사진의 사이즈가 조절되는 기능이 있었으나, 위에 살짝 떨어진 위치는 적잖은 드래그 & 드랍을 유도했습니다. 여백 덕분에 화면에 딱 맞게 사진 비율을 키우는게 어려웠으니까요.

 결국 사진을 보통 20장 넘게 삽입하게 되는 스토리포토의 작업 시간은 더뎌졌고, 스토리에디터에선 X, Y 좌표값을 0으로 바꾸기 위해 Tab키를 연발하거나 일일히 숫자를 바꾸는 눈물나는 상황이 연출되었지요.

 위 문제는 현재 버전에서도 여전히 존재합니다만, 곧 출시될 새로운 버전의 스토리포토와 스토리에디터에선 문제를 없애기 위해 몇가지 장치를 추가하였습니다. 하지만 역시나, 11개월 남짓한 시간 동안, 우리는 유저를 배려했던거죠.

사례 3: 브루투스

 공화정의 마지막을 불살랐던 카이사르(Caesar, 시저)의 죽음에 대한 이야기는 굳이 관심이 없더라도 많은 사람들에게 알려져 있는 일화입니다. 거의 아들이나 다름 없었던 브루투스(Brutus)의 단검에 마지막 단말마를 직면한 카이사르가, “브루투스, 너마저!”라고 외치고 숨을 멎었다는 유명한 이야기이죠.

 디자이너들에겐, 사람들이 항상 나의 우수하고 혁신적인 디자인을 애용할 것이며, 찬양하고 감탄할 것이다”라는 작고 소중한 꿈이 있습니다. 다음의 사례는, 그런 꿈을 무참히 짓밟히고, 고객들에게 배신을 당한(?) 디자인 요소에 대한 이야기입니다.

 

 초기 베리플레이어에 대해서는 사람들의 의견이 많이 갈리는 편입니다. 심플해서 좋다는 분들도 계시고, 너무 휑하고 필요한 기능들이 없다는 지적도 있었습니다.

 그리고 7개월에 걸친 고민과 노력 끝에, 새로운 플레이어가 등장했습니다! 다채롭고 흥미 진진한 새로운 기능들(저장, 불러오기 / 스토리 정보 보기)과 기존에 불편했던 기능들(자동 실행 / 추천하기)을 한껏 개선하고, 윈도우의 시작 버튼의 디자인을 참고한 새로운 레이아웃 또한 추가 되었습니다.

 하지만 과연 얼마나 많은 사람들이 버튼을 눌러봤을까요? 사람들이 스토리베리 컨텐츠를 보는 이유는, 저장하고 불러오기 위해서가 아니라, 일단 보기 위해서라는 점을 깨닫지 못하고, 화려한 기능들을 구석에 나열한 신세가 된 것 입니다.

 

결론

 UX는 순수하게 필요에 의해 태어난 장르입니다. 존재하지 않았던 것도 아니고, 모든 상황에 적용되는 통합 이론(Universal Principle)도 없습니다.

 하지만, 이것이 없으면 사용자들은 불편하고, 개발자와 디자이너들은 고객을 잃으며, 소프트웨어 비즈니스는 실패합니다. 특히 작은 시작으로 큰 꿈을 꾸는 벤쳐들은, 이런 점을 묵과하다가 쉽게 쓰러집니다.

 근 1년간의 삽질과 실패는 저와 저희 팀원들에게 큰 깨달음을 주었습니다. 얄팍한 배려와 무관심이 어떤 결과를 가져오는지, 춤추는 곰을 만들고 만족하는 행위가 얼마나 큰 피해를 주는지 말이죠.

 현재 스토리베리 팀에선, 인터렉션 디자인의 비중이 높아져, 꾸준한 토론과 비교 분석으로, 지금까지 많은 실망을 겪은 유저들에게 다시 한번 새로운 경험을 전달할 수 있도록, 새로운 리뉴얼 프로젝트에 박차를 가하고 있습니다. 물론 슬픈 경험들이 모티베이션이 되었다고 할 수도 있겠지만, 그 동안 저희가 잃은 것들은 매우 큰 것이었습니다.

 저희와 같은 실수를, 함께하는 웹 서비스 벤처들과 앞으로 탄생할 스타트업들이 번복하지 않았으면 하는 바람입니다. 어설픈 글 읽어주셔서 감사합니다.

# 스토리베리를 기준으로 작성함.
# 기본적으로는 (반복되지 않는) 매 턴마다 동일한 엔진을 삽입.
# 스토리베리에서는 기본적으로 엔진 기능이 없으므로 위와 같은 방법으로 구현한다.

씬

씬은 총 15개 (혹은 17개)로 나누어진다.

오프닝 1개 (상황에 따라 2개)
하루 기준 턴 12개
엔딩 1개 (상황에 따라 2개)
크레딧 1개
=합계 15개

* 오프닝 씬
오프닝 화면을 거쳐 "시작", "이어하기", "크레딧", "추가 정보"로 갈 수 있는 선택지 제공
게임을 다 깬 후에는 새로운 메뉴 화면으로 변경하고, 숨겨진 기능을 추가함. (상황에 따라 분할처리 할 가능성 있음)

* 게임 엔진(턴) 씬
하루를 12턴으로 쪼개고, 매 턴을 3번 반복하는 식.
턴이 돌아올 때 마다 씬 넘버에 +1을 해주고, 12번째가 종료 된 후에는 1로 돌려주고 날짜를 +1 해준다.
진행 될 때는 spot을 3개로 나눠, Day one/two/three로 이동하게 한다.
특정 조건이 달성되었을 때는 엔딩 씬으로 이동한다.

* 엔딩 씬
조만간 프로젝트 문서에 게재할 예정이지만, 엔딩의 개수가 상당히 많으므로 분할하여 처리 할 수도 있음.
종료 후에는 자동적으로 크레딧 씬으로 넘겨준다.

* 크레딧 씬
제작 맴버에 대한 소개와 추가 정보를 적어주고 컨텐츠를 종료한다.
게임 클리어 일 경우에는, 스위치를 올려주고 오프닝 씬의 선택 화면으로 보낸다.



변수

변수는 크게 스트레스/허기/체력/집중력/돈/업무 달성률으로 나눈다.

* 스트레스
스트레스의 크기에 따라, 체력 저하량과 집중력 저하량에 변동이 생긴다.
스트레스 증가의 원인은 아래와 같다.

허기가 0일 때
주변의 이벤트에 의해 스트레스에 영향을 받을 때
업무를 할 때
잠을 20시간 넘게 못 잤을 때

스트레스 해소의 원인은 아래와 같다.

허기가 줄어들 때
담배를 필 때
게임을 할 때
쉴 때
잠을 잘 때
운동을 할 때

* 허기
밥을 먹지 않으면 허기가 강해진다. 크게 6개의 상태로 나누어진다.

배부름 > 든든함 > 그냥저냥 > 허기짐 > 배고픔 > 아사

배고픔 이하에 도달하면, 체력에 직접적으로 영향을 끼친다.

* 체력
게임 오버에 직접적으로 영향을 끼치는 요소. 0이 되면 사망한다.
체력을 보충하기 위해서는 아래와 같은 행동을 취한다.

6시간 이상의 수면을 취한다.
스트레스를 연속 2턴 이상 0으로 유지한다.
체력 회복계열의 약품을 사용한다.

* 집중력
업무 달성률에 영향을 끼치는 요소.
높은 집중력을 위해선 스트레스를 낮게, 배부르지 않게 컨디션을 유지해야한다.

* 돈
기호 식품이나 음식을 사 먹을 때 사용해야 하는 요소.
3만원 (혹은 5만원)에서 시작한다. 0원이 되어도 게임 진행에 문제는 없다.
다만 몇몇 상황에 필요한 물품을 구매하지 못하면 사망할 수도 있다. (밥이라던지)

* 업무 달성률
게임의 클리어 요소 중 가장 중요한 변수.
집중력이 높은 상태에서 업무를 진행할 경우, 시간 대비 달성률이 빠르게 올라간다.
반대로 집중력이 낮은 상태에서는 시간 대비 달성률이 0에 가깝다.



행동

턴에서 선택할 수 있는 행동군은 크게 3가지.

먹기/싸기/자기 등의 생존을 위한 대비
쉬기/운동하기/게임하기 등의 정신적 스트레스 해소
일하기/정리하기/배분하기 등의 업무 관련

 사업을 성공시키는 핵심적인 팀의 구성에 대해 여러가지 조언을 듣고 선배들의 이야기를 듣다보면, 결론은 하나. 아래의 요소들을 '고루' 갖추는 것.

• 관리 (Management)
• 영업 (Business)
• 마케팅 (Marketing)
• 기획 (Design)
• 개발 (Development)

 그림을 그려보면 피라미드와 같은 형태가 나온다. 서로 상호 관계를 가진 분야로서, 5가지 업무가 전부 원활히 돌아갈 경우 큰 시너지가 발생한다.

 대부분 '이제 시작하는 팀'은 기획과 개발만 가지고 출발하는 경우가 대부분이다. 마케팅과 영업은 무시되고, 관리는 핵심 개발자나 기획자가 맡는다.
 그럼 결과는? 매우 힘들다. 성공...할 가능성이야 언제나 있지만, 0.001%와 50%의 성공률차이는 너무 크다. 가뜩이나 리소스가 모자란 벤처에서, 이런 사실은 리소스의 분산을 가져오고, 결국 팀의 해체와 비즈니스의 실패로 다가온다.

 하지만 알다시피, 위의 요소를 전부 가지고 시작하는 것은 어렵다. 특히 능력있는 마케터은 아무나 가질 수 없는 꿈의 영역임에도 불구하고, 경시하거나 무시하는 경우가 많다. 우리도 사업 초기에 경험했으니.


 결론은? 좋은 마케터를 잡아라! (...)

 올해 Portal은 FPS계에 새로운 충격을 남겨주었습니다. 혁신적인 FPV(First-Person View)의 활용에 대한 부분이었죠. 무작정 총을 쏘고 적을 쓰러뜨리는 과거의 방식이 아닌, 1인칭 시점의 기묘한 퍼즐을 만들어낸 대단함에 많은 사람들이 빠져들었습니다.

 그 핵심에는 Narbacular Drop이라는 게임을 만든 Nuclear Monkey Software가 있었습니다. DigiPen의 학생들이 모여서 만든 일종의 (졸업작품) 게임 제작 팀이었죠. 그들은 Portal 이전, 2005년도에 이미 Portal과 비슷한 형태의 Narbacular Drop을 성공적으로 제작하였고, 그 결과로 밸브에 팀 전체가 팔려가게(?) 됩니다.

 위 강연은 바로 그 팀의 이야기입니다. 어떻게 시작했는지, 어떻게 게임을 만들었는지, 어떻게 Valve로 갔는지, Valve로 넘어가서 어떻게 지금과 같은 성공적인 게임을 만들 수 있었는지에 대한 내용이지요.


 저 강연 중, 가장 인상깊은 부분은 RET(Resource, Experience, Time)의 부족에 대한 이야기였습니다. RET의 부족은, 분명 커다란 리스크이자 팀의 존속을 흔드는 요소입니다. 하지만 그와 상대적으로 RET의 부족이 주는 장점인 제약 없음(no limit), 창작활동의 자유(freedom), 그리고 허기가 주는 새로운 영감(innovation) 등을 잘 살리면, Nuclear Monkey팀과 같은 성공의 길로 다가갈 수 있겠지요.

 최근 제가 느끼는 프레셔 중, 가장 큰 부분이 RET입니다. 아마 아시는분은 잘 알고 계시겠지만, 저 또한 RET의 부족이 절실하게 느껴지고 있습니다. 하지만 그런 만큼, 살아남기 위해 머리를 굴려야하는 빈도가 점점 높아집니다. 이것이야 말로 벤처의 특징이고, 장점이 아닐까 싶습니다.



다른 인디 게임 제작 팀들의 강연 내용은 http://www.indiegamesummit.com/ 에서 더 보실 수 있습니다.