쿠팡 모바일 디자인 스토리 : 시작
쿠팡 모바일 디자이너로 보낸 3년간의 이야기 #1
*이 글은 2012년부터 2015년까지의 이야기며 현재 쿠팡과는 많은 차이가 있습니다.
2012.3 : 입사
이커머스는 제쳐두고 웹 기반 서비스는 7–8년 만이었다. Postvisual이라는 플래시 위주의 웹사이트를 만들던 회사에서 일을 잠깐 해본 것과 프리랜서로 웹을 디자인해 본 것이 전부인 상태에서 입사를 했다.
"과장님은 이제 모바일팀이에요."
"네? 왜 저에요?"
"그건 나도 모르겠어요."
쿠팡 입사 후 BI 개편 제안을 위한 문서작업만 몇 주를 진행하다 한 달만에 GUI팀으로 옮긴지 2주 만에 팀장과 했던 대화였다. 그동안 모바일앱은 PLUSX를 통해 진행 중이었고 가끔 기획자를 통해 시안을 구경하던 게 전부였는데, 갑자기 디자이너와 개발자가 모여있는 팀이 생겼고 내가 배정받았다.
앱이 거의 완성된 상황에서 수정된 사항을 반영하려니 플러스 엑스와의 계약을 연장할 수 없었던 것 같았다. 자세한 상황은 모르지만 수도 없는 수정에 많이 지쳤다는 얘기도 들렸다. - 나중에 플러스 엑스 블로그 글에서 느껴진 분노가 공감되는 상황이었다. 다른 얘기지만 햄버거 메뉴와 플리킹 메뉴를 사용한 시안을 대표가 굉장히 싫어했는데 담당 기획자, 개발자가 많이 설득하다 실패했다고 한다. 햄버거 메뉴에 대한 얘기는 나중에 다시 할 계획이다.
이후 수정은 내가 맡아서 진행했다. 메인 칼라를 레드에서 블루로 바꾸는 단순하지만 귀찮은 작업이었다. 앱 오픈을 일주일 남겨둔 상황에서......
난 앱 디자인 제작방식에 있어서 아무것도 모르는 상태였다. 디자인이야 바꾸면 되지만 가이드를 어떻게 전달해야 하는 지도 몰라서 경험자들에게 물어보며 우여곡절 끝에 오픈은 할 수 있게 됐다.
그렇게 시작됐다.
부끄럽지만 개인적인 부족함을 강조하는 이유는 쿠팡에서 어떤 방식으로 모바일 서비스에 대해 배울 수 있었는지를 부각하고 싶어서다. 개인적으로는 모바일이나 웹 디자인을 해본 경험이 중요하진 않다고 생각하지만 보통의 조직장들은 그렇게 생각하지 않는 것 같아 조금 아쉽다. 물론 해당 매체에 대한 특성은 알고 있어야 한다. 그러나 디자인은 기본적으로 문제의 본질에 다가가고 해결하는 분야라 크게 중요하진 않다. 포스터 디자인을 잘하는 사람은 다른 디자인도 잘 할 가능성이 높다.
고객중심 & USABILITY TEST
모든 회사들이 고객중심을 외친다. 그런데 정작 일이 진행되는 상황을 보면 단기적인 이익이나 여러가지 현실 때문에 고객의 입장에서 생각하는 관점을 놓치는 경우가 대부분이다. 비즈니스 선순환의 고리에서 순환 동력을 어디에 두느냐의 차이일 수도 있는데 쿠팡은 철저히 고객을 중심에 뒀다. 고객이 모이면 판매자가 모이고 그렇게 상품이 많아지면 고객이 더 모인다는 흐름이다. 고객의 불편함을 해소하고 놀라운 경험을 제공하면 다른 것은 자연스럽게 따라온다는 얘기다. 언뜻 보기엔 단순하지만 당장 눈앞의 매출에 휘둘리고 판매자 눈치를 보느라 갈팡질팡하는 게 대다수의 업체들이다.
그렇게 고객을 중심에 두고 생각하면 당장 고객들이 서비스를 어떻게 이용하는지, 이용하며 어떤 불편함은 없는지에 대해 알아야 된다는 생각으로 연결된다. '사용성 테스트'가 첫 단추였다.
어떤 서비스(제품)가 가지고 있는 최소한의 사용성의 기준을 50점이라고 봤을 때 50점 미만인 경우와 그 이상인 경우는 접근해야 하는 방법이 다르다. 50점 미만이라면 장애물이 많은 놀이공원이라고 생각하면 된다. 이 상태에서 고객을 많이 모아봤자 장애물에 걸려 넘어지는 사람만 많아질 뿐이다. 극단적인 예를 들면 지뢰밭이라는 표현을 쓸 수도 있다. 고객을 모으려면 일단 지뢰부터 제거해야 한다. 어떤 서비스던지 일단 문제가 있을 거라고 가정하고 접근하는 것이 좋다. 넓은 시각으로 보면 문제가 없는 서비스는 없다. 아직 발견을 못했을 뿐이다.
대표의 지휘 아래에 UX Lab이 생기고 Usability Test(UT)가 가장 먼저 진행되었다. PC 웹을 먼저 진행했는데 많은 이슈들이 쏟아져 나왔다. 여기에서 재밌는 상황은 사용성에 대해 아무런 생각이 없던 사람들이 고객들이 사용하며 실패하고 당황하는 모습을 눈으로 직접보니 문제의 심각성을 인식했다는 점이다.
이때부터 쿠팡은 기획/디자인뿐 아니라 전직원에게 UT관람을 의무적으로 진행했다. 말이나 문서로 전달되는 문제점보다 직접 눈으로 보는 문제점은 다가오는 무게가 다르기 때문이다. 쿠팡은 UT진행만으로 커뮤니케이션 비용 낭비를 줄이는 데 성공했다고 생각한다. 그렇게 1-2년 정도가 지나니 배너 강조에 열을 올리던 영업부서에서도 사용성에 관한 견해를 가지고 의견을 제시하는 긍정적인 현상이 생기기도 했다.
이런 최소한의 검증 장치가 없는 대부분의 회사에서는 사용성 문제를 말해봤자 외면당하기 쉽다. 관찰을 해 본 적이 없기 때문이다. 사용자를 연구해 본 적이 없기 때문이다. 그래서 공감대가 형성되지 않는다. 자기가 설계한대로 사용자가 이용할거라 생각한다. 이럴 땐 보통 목소리 큰 사람이 이긴다. 부서장의 컨펌이 답이다. 겉으로 보기에 매끄러워 보이지만 전제가 검증되지 않은 논리가 이기는 씁쓸한 경험을 자주 하게 된다.
SPLIT TEST
지금은 꽤 많은 온라인 서비스 업체들이 진행하고 있지만 3년전에는 극비에 가까울 정도로 소수의 업체들만이 시행하고 있었던 것 같다. 보통 A/B Test로 불리는데 검색해보면 많은 자료들이 있다.
A/B Test가 필요한 이유는 런칭/개선한 서비스 결과가 좋은 영향을 미치면 다행이지만 예상치 못한 허들로 구매전환율이 10%씩 떨어질 수도 있고, 이탈률이 증가하고 재방문율이 반토막 날 수도 있기 때문이다. 아무도 이 결과를 장담할 수 없다. 더 큰 문제는 개선한 부분의 어떤 점 때문에 데이터 지표가 낮아졌는지 알 길이 없으니 '롤백'을 할 수밖에 없다는 점이다. 몇 개월간의 고생이 물거품이 되는 순간이다. 그나마 지표에 이상이 있다는 사실을 발견하면 다행이다. 데이터를 확인하는 시스템이 갖춰지지 않았다면 끓는 물 속 개구리처럼 서비스는 서서히 죽어갈 수도 있다. 겁주는 것이 아니라 현실이다.
A/B Test는 이런 리스크를 효과적으로 줄일 수 있는데, 방문 고객의 5% 정도를 기존 안(A)에 할당하고 신규 적용 안(B)에도 5% 정도 할당하여 같은 조건 아래에서 라이브 된 데이터를 비교하는 방식이다. 이 정도 수치면 실패를 하더라도 20분의 1로 손해를 줄일 수 있으며, 정확한 비교 데이터를 얻을 수도 있다. 또 100% 반영한 뒤 데이터를 뽑아 기존 안과 비교하면 지표에 영향을 미치는 변수가 너무 많기 때문에 신뢰성이 없어진다. 주중/주말, 월초/월말, 시즌 등에 따라 소비가 달라질 수 있기 때문이다. 동시에 테스트하는 이유는 이러한 변수를 통제하기 위해서다.
쿠팡은 이런 시스템으로 항상 이기는 디자인을 반영해 왔다. - 잘못된 데이터 해석으로 가슴 아픈 사건이 하나 있었다는 암시만 해두고 싶다;
AGILE
모바일팀으로 옮긴지 한 달만에 애자일 조직이 세팅되었다. 조금 과장해서 애자일은 쿠팡의 엔진과도 같은 역할을 했다는 기분도 든다. 물론 내가 애자일 조직에 속해 있었기 때문에 우물 안 개구리의 시각일 수도 있다.
애자일은 PO 1, SM 1, 디자이너 1, 개발자 6 정도로 구성된 팀이다. PO는 Product Owner의 약자고 말 그대로 서비스 프러덕트를 관리한다. 비즈니스를 보며 팀과 외부 부서의 커뮤니케이션을 담당하고 지표를 관리한다. SM은 Scrum Master의 약자인데 업무 일정을 관리하고 업무에 방해되는 요소를 찾아 제거하는 등의 역할이다. 참고로 내가 함께 했던 SM들은 그 이상의 일도 마다하지 않고 디자이너와 개발자들을 보호하고 돌봐주는(?) 수고스러운 일까지 감당한 고마운 존재였다. - 애자일은 칸반 방식과 스크럼 방식이 있는데 쿠팡은 스크럼 방식을 채택했기에 스크럼 마스터가 존재한다.
팀 구성을 보면 특이한 점이 하나 발견했을 텐데, 쿠팡엔 기획자가 없다. 서비스에 대한 구상이나 정책은 PO가 유관부서들이나 경영진과의 협의를 통해 만들고, 기타 자세한 화면 설계부터 와이어프레임까지 디자이너의 몫이다. 이건 디자이너로서 가장 큰 장점이다. 직접 레이아웃과 인터렉션을 고려하며 설계하고 디자인을 해본다면 다들 그렇게 느낄 거라 생각한다. 설계 후 와이어프레임을 프로토타이핑 한 뒤 캐주얼하게 UT를 진행해 발견된 문제점을 수정해서 다시 UT를 진행하는 방식으로 일을 했다. 여기에서 말한 캐주얼한 UT는 외부 사용자를 UT룸에 불러서 테스트하는 것이 아니라 직접 핸드폰을 들고 다니며 디자이너나 개발자를 제외한 다른 직원들에게 사용을 부탁하고 관찰하는 방법이다. 의외로 예상치 못한 문제점을 발견할 때가 많아 디자이너들에게 필수적으로 권하고 싶다.
개발자가 바로 옆에 있어서 커뮤니케이션하기 수월한 것은 이루 말할 수 없다. 많이 배우기도 하고 많은 아이디어를 얻기도 한다. 애자일의 장점은 바로 누구나 아이디어를 내고 업무를 진행할 수 있다는 점이다. 조직장 컨펌은 필요 없다. 앞에서 말한 A/B Test가 있기 때문이다. - 이 부분 때문에 많은 조직장들이 싫어할 수도 있겠다. 쿠팡의 많은 개선안들이 개발자들의 기획으로 반영되기도 했다.
이렇게 열정적으로 아이디어를 내고 서비스에 반영하는 이유는 오너십이 있기 때문이다. 애자일의 또 다른 장점이다. 누가 시켜서 하는 프로세스가 아니라서 스스로 만든다는 분위기가 자연스럽게 형성된다. 너 나 할 것 없이 문제점을 제기하고 개선한다. 오너십은 강요한다고 생기는 게 아니라 이렇게 스스로 결정하고 진행할 수 있는 권한을 줄 때 강해진다고 생각한다. 더구나 실패에 대한 리스크도 적으니 과감하게 모든 아이디어를 테스트해볼 수 있다. 일하는 게 즐거울 수밖에 없다. - 지금은 상황이 조금 다르지만 이런 시절이 있었다.
글쓰기 초짜에게 처음부터 긴 글 쓰기는 무리인 것 같다. 하고 싶은 얘기는 많은데 어떻게 엮어야 효과적인지 잘 모르겠다. 주제가 반복되더라도 분리해서 써야할 것 같다. 작은 단위로 나눠서 진행하는 것 또한 쿠팡의 철학이다.
_
#1 끝
_
UI/GUI Designer
Personal Site : http://frozensound.com
