2019. 5. 7. 07:50ㆍUX 가벼운 이야기
들어가며
지난 3월에 진행되었던 토스 디자인 시스템 컨퍼런스에 다녀왔습니다. 토스는 어떻게 신규 아이템을 발굴하고 제품을 런칭하는지, 그리고 제품을 어떻게 개선해 나가는지 살펴볼 수 있었습니다. 몇 가지 세션을 통해 토스라는 애자일 조직이 어떻게 좋은 사용자 경험을 만들어 나가고 있는지 공유합니다.
애자일 조직의 전체 개편 - 윤성권
해당 세션에서는 토스가 Focus on impact라는 공동의 목표를 가진 애자일 조직임에도 왜 전체 개편을 진행해야 했는지, 그리고 어떻게 진행하였는지를 다루었습니다.
연사님은 '토스는 만들고 배포해서 측정하고, 그리고 이에 대한 러닝을 바탕으로 다시 만드는 것을 반복하는 이터레이션*'을 하며 성장해나가는 조직이라고 소개했습니다. 원하는 타겟에게 제품을 출시해보기도 하고, 탭의 유무나 버튼 내의 문구를 가지고 A/B 테스트를 하는 등 실험을 진행하며, 그 과정에서 배운 것을 바탕으로 성장해왔다고 덧붙였습니다.
* 이터레이션: 인터페이스를 개량하고 사용성을 확인하기 위한 테스트를 반복하는 것을 의미합니다.
개편 이전의 고민
토스는 다양한 직군의 사람들이 하나의 서비스를 만들기 위해 구성된 '사일로'와 토스 전체의 일관된 경험을 위해 같은 직군끼리 모인 '챕터'로 조직되어 있는데요. 모든 팀이 '쉽고 간편한 사용자 경험을 만들자’라는 공동의 목표를 가지고 있지만, 각자의 방식으로 Focus on impact를 하다 보니 전체 디자인에 통일성이 결여된 상황이 발생했습니다. 컴포넌트의 컬러에서부터, 폰트 크기, 문구까지 제품마다 다르게 사용되고 있었는데요. 이 때문에 디자인할 때마다 매번 어떤 컴포넌트를 사용할지 고민하는 문제가 생겼습니다. 빨리 달리며 했던 일들이 이제는 발목을 잡는 상황이 된 것이죠. 누군가가 좋은 디자인을 해도 프로덕트 전체로 확장되지 못하고 정체되어 있다는 느낌을 받았습니다. 모두에게 자율과 권한, 책임이 주어져 있지만 서로가 다른 방향으로 달려나가고 있다는 점이 고민이었습니다.
조직 개편
다른 애자일 조직도 분명 유사한 어려움이 있었을 것이라 생각해 찾던 중, 스포티파이가 유사한 문제를 경험하고 해결했음을 알게 되었습니다.
Spotify - Design doesn't scale.
스포티파이 디자이너 Stanley Wood는 아티클을 통해, 디자인이 확장되지 않던 문제와 해결 방법을 공유했습니다. 그는 이런 상황이 된 것은 서로 다른 시간대에서 서로 다른 프로젝트를 진행하고 있는 파편화된 디자인 팀 구조가 디자인의 파편화를 가져왔고, 이를 살필 기회가 없었기 때문이라고 설명했습니다. 이 때문에 스포티파이 디자인 팀은 분산된 디자이너들이 어떻게 일관된 경험을 만들 수 있을지 고민하였고, 5가지 방법을 찾아냈습니다.
‧ Principle: 디자인 팀의 공통된 관점을 가지기 위해 디자인 원칙을 수립했습니다. 이 원칙들을 바탕으로 디자인 재정립 프로젝트를 진행하였습니다. 이 원칙들은 비즈니스 목표와 연결되어 있어 디자이너 이외의 조직 구성원들에게도 공감을 얻을 수 있었습니다.
‧ Guideline: 재정립된 디자인 일관성을 유지하기 위해, 스포티파이의 컴포넌트와 패턴, 스타일 문서를 담은 가이드라인을 오픈했습니다. 일관성뿐만 아니라, 디자이너와 개발자 간 용어를 제작함으로써 효율성도 높였습니다.
‧ GLUE: 가이드라인과 툴킷을 담당하는 팀을 만들어 조직의 중심에서 팀 간의 협업을 돕고 다양한 디자인 요구를 지원합니다.
‧ Guild: Silo의 디자이너와 GLUE의 팀원이 함께 길드를 결성하여 가이드라인과 디자인 사항을 합의하고 조율합니다.
‧ 디자인 QA: 디자인 버그를 수정하기 위해 디자인 QA를 마련하였습니다. 체크리스트를 통해 스포티파이의 가이드라인과 디자인 원칙을 준수하도록 하였습니다.
스포티파이가 문제를 해결한 방법을 참고하여, 토스가 이미 갖고 있던 부분은 더욱 발전시키고, 필요한 부분은 반영하며 해결해나가기 시작했습니다. 첫 번째, 토스에는 그동안의 러닝을 바탕으로 만들어진 Product principle이 있었습니다. 제품을 출시하고 결과를 분석했던 경험을 바탕으로 만들어진 원칙이었기에 핵심 원칙이 될 수 있었습니다.
- Casual Concept: 어려운 금융의 개념을 친숙하고 이해하기 쉽게 만들었는가
- 1 thing per 1 page: 하나의 화면에 하나의 명확한 목표가 드러나는가
- Minimum Features: 꼭 필요한 기능인가? 이걸 넣어야만 성장할 수 있나
- Clear CTA: 다음 단계로 진행하거나 과업을 완료하기 위한 CTA가 잘 보이고, 바로 누를 수 있는가
- Minimum Policy: 고객이 사용을 위해 '알아야 할 것'을 없앨 수 있는가
- Mimimum Input: 꼭 필요한 정보만 요구하고 있는가? 최소한의 터치만으로 완료할 수 있는가
두 번째, 플랫폼 디자인팀을 꾸리고, 디자인 Guideline인 TDS(Toss Design System)를 만들어 효율적으로 디자인 자산을 사용할 수 있도록 했습니다. 일관된 사용자 경험을 제공함과 동시에 프로덕트 디자이너들이 제품에 더욱 집중할 수 있게 하였습니다. 세 번째, 플랫폼 디자인팀과 브랜드 디자인팀을 중심으로 각 사일로의 프로덕트 디자이너가 유기적으로 협업할 수 있는 조직을 구성하였습니다. 마지막으로 디자인 QA를 통해 수치 확인에서 그치는 것이 아닌, 디자인 principle을 기반으로 한 피드백을 진행할 수 있도록 했습니다. 고객에게 얼마나 만족감을 주고 있는지, 그리고 그것을 통해 우리가 어떻게 성장할 수 있을지에 대한 의견을 주고받습니다.
디자인 개편
토스 팀은 앞서 언급했던 것처럼, Focus on impact를 고민하며 큰 효과를 낼 수 있는 제품에 집중해왔습니다. 그렇다 보니 자동이체와 같이 성과가 나지 않는 페이지들은 계속해서 백로그에 남아있게 되었습니다. 탭 구조 또한 맥락을 갖고 있거나 서로 연결되어 도움을 주는 구조가 아니었습니다. 간편 송금에서 시작하여 추가된 기능들이 출시된 순서대로 탭에 추가되어있는 상태였는데요. 맥락이 튼튼한 구조를 갖추고자 전체 개편을 진행하게 되었습니다. 이는 속도를 내기 위해 쌓아 두었던 디자인 부채를 해결하기 위한 선택이었습니다. 전체 개편을 통해 사용자에게 가치를 줄 수 있는 부분에 투자하여 더 큰 가치를 창출할 수 있는 기반을 마련한 것이라 할 수 있습니다.
5주 만에 제품 런칭하기 - 소윤의
해당 세션에서는 '공동 계좌'라는 신규 제품을 만들어 나가는 과정을 다루었습니다. 현재 토스에는 송금에서부터 시작한 40개 이상의 제품이 있으며, MVP 방식을 사용하여 서비스를 발전시켜 왔다고 합니다. 연사님은 이 방식에 대해 '짧은 시간 내에 이 비즈니스가 사용자에게 통하는지, 맞는 방향인지 검증하고 발전시키는 과정을 거치는 것'이라고 설명했습니다.
MVP란?
Minimum Viable Product의 약자로, 린 스타트업 용어입니다. 근본적인 사업 가설을 테스트하기 위해, 최소 노력과 개발 기간으로 '만들기-측정-학습 순환'을 완전히 돌 수 있는 제품을 만듭니다. 최소한의 기능을 갖지만, 그 자체만으로 사용자에게 가치는 주어야 합니다. (린 스타트업)
예로써, 드롭박스가 '뛰어난 고객 경험을 제공할 수 있다면 사람들이 사용할까?'라는 가설을 검증한 사례가 있습니다. 3분짜리 비디오를 통해 드롭박스가 어떻게 작동하는지를 보여주자, 하룻밤에 베타 대기 명단이 5000에서 7만 5000명이 되었습니다. (https://techcrunch.com/2011/10/19/dropbox-minimal-viable-product/)
이와 유사하게 토스에서도 제품 개발 전 마케팅을 진행한다고 합니다. 아직 개발된 제품이 없지만, 있는 것처럼 미리 광고하는 방식인데요. 만약 클릭이나 전환율이 높아서 시장에 니즈가 있다고 느껴지면, 그때 제품 가설을 시작한다고 합니다.
kickoff. 불편함은 기회다: 문제 정의
킥오프 단계에서는 어떤 제품을 만들지, 어떤 불편함을 해결할 것인지를 고민합니다. 공동 계좌는 '회비 걷는 과정의 불편함에 집중'하며 시작했습니다. '불편한 경험이 맞다'는 사일로 구성원 모두의 공감이 있었고, 데이터에서도 같이 공금을 모으는 사람들의 패턴을 볼 수 있었습니다. 구성원들은 이 과정에서의 불편함은 정보의 불균형에서 오는 불편함이라고 보았습니다.
Week 1. Creative ideation: 아무 말 대잔치로 해결안 찾기
사일로의 모든 구성원이 기술의 바운더리 없이 해결책에 관한 아이데이션을 진행하였습니다.
총무가 회비를 쉽게 걷을 수 있는, 공금의 사용내역을 모두가 볼 수 있는, 목적에 따라 금액 목표를 함께 채우는, 채팅방을 대체할 수 있는 그런 제품….
Week 2. 기능은 비용이다: 스펙 쳐내기
많은 아이디어를 발산한 후, '과연 이 기능들이 정말 다 필요할까?'라는 의문을 던졌습니다. 토스의 제품 원칙 중 Minimum feature에 따라 최소한의 기능으로 검증하기 위해 아이데이션에서 나온 기능들 가운데 핵심 기능만을 추려내었습니다.
'기능은 가치가 아니라 비용'이기 때문에 '있어서 좋은 기능'은 만들지 않습니다. 기능이 많아지면 사용이 어려워지고, 버그와 에러의 가능성도 커지기 때문에 리스크가 있는 시도를 하지 않는 것입니다. 또한 비즈니스가 워킹하지 않으면 제품 자체를 버리게 되므로, (총무가 회비를 모으는 경험에서) '없으면 안 되는 기능'을 만드는 데 집중합니다. 그 결과 꽤 필요한, 말이 되는 기능이라고 생각했던 40여 개의 기능을 쳐내고, 약 20% 정도의 기능만을 가지고 검증을 진행하게 되었습니다.
Week 3. Focus on Impact: 디자인&개발
TDS(Toss Design System)을 사용하여 디자인을 완료하였습니다. 빠르게 스프린트를 돌기 때문에 따로 프로토타이핑을 진행하지는 않았는데요. 기능적으로 단순한 디자인을 구현하는 것이기에 개발자분들과 커뮤니케이션하는 편이 훨씬 빠르기 때문입니다.
하지만 기획을 깊이 있게 설계하여 출시하는 것이 아니라 생각지 못한 고민이 생겼습니다. '10회 송금 무료 정책을 갖고 있는데, 총무가 회비를 결제할 때마다 개인의 무료 송금 횟수가 차감된다면, 정말 문제를 해결하는 것일까? 경험의 완결성이 떨어지지는 않을까?' 오히려 반대로 '공동 계좌에 항상 무료로 송금할 수 있다면, 체리피커로 인해 매출에 영향을 주지 않을까?' 프로덕트 오너와 상의한 끝에 정책과 매출에 관련된 중요한 고민이지만, 일어나지 않은 일이기 때문에 걱정하지 말고 일단 진행하자는 결론을 내렸습니다.
Week 4. Going extra mile: 마지막 테스트
어느 정도 제품 개발이 진행되면, apk 파일로 버그를 잡고 디테일을 챙기기 위한 QA 과정을 거칩니다. 문제를 해결하는데 꼭 필요한 기능이 있다면 마지막에 추가하기도 합니다. 사일로 구성원들이 제품에 대한 오너십을 가지고 '공동 계좌'의 경험이 어떠한지 QA를 진행하였고, 경험의 완결성이 부족한 부분을 수정하였습니다.
Week 5. 저렴한 실패, 새로운 시작
제품을 출시한 후, 쏟았던 시간과 비용보다 좋은 바이럴과 반응이 받았습니다. 그러나 퍼널을 실험하며 제품을 개선하던 중, 카카오 모임 통장이 나왔고, 좌절을 맛보았습니다. 토스 팀이 잘하는 것, 더 잘 아는 것은 금융정보라고 판단하였고, 계좌에서 시작하는 공동계좌로의 피봇을 준비하고 있습니다. 실패를 배움으로 받아들이는 문화가 있기에 빠르게 시도해볼 수 있었다고 생각합니다.
큰돈 버는 디자인하기 - 송승원
마지막으로 '신용카드 추천 서비스'를 어떤 과정으로 개선하였는지, 어떤 비즈니스 임팩트를 냈는지에 대한 이야기입니다. 세션은 플랫폼의 선순환 구조에 대한 설명으로 시작되었습니다. 연사님은 사용자가 지속해서 유입되고, 사용자 트래픽을 공급자로 보내야 플랫폼의 선순환적인 성장이 가능하다고 이야기했습니다. 트래픽이 곧 돈이 되는 구조인데, 그렇다고 단기적인 트래픽과 매출만을 위한다면 제품이 신뢰를 잃을 것이고, 사용자는 떠나 결과적으로 매출도 떨어질 것이라고 설명했습니다. 그 때문에 어떻게 하면 사용자 경험을 지키면서도 돈을 벌 수 있는 선순환 구조를 만들 수 있을지 고민하였고, 세션을 통해 그 고민의 결과를 공유해주었습니다.
step 1. 이해하기
신용카드 추천 서비스는 카드사의 카드들을 한곳에 모아 비교해주고, 발급까지 연결해주는 서비스입니다. 이 서비스의 개선은 사용자와 제휴사의 니즈가 무엇인지, 제품을 사용하고 있는 사용자는 누구인지 이해하는 데서 시작하였습니다.
(1) 니즈
사용자: 혜택 많은 카드를 발급받고 싶어 한다. ↔ 제휴사: 발급량 자체의 증가를 원한다.
신용카드 시장의 경우 양쪽의 니즈가 명확한 편이기 때문에, 두 지점의 공통점을 찾아서 핵심 성과 지표(KPI)를 카드 발급량과 매출로 잡았습니다. 채널의 특성상 발급량을 바로 트래킹할 수 없기에 발급 가능성을 예측하는 지표로 클릭률과 인당 클릭 개수를 보았습니다.
(2) 이 제품은 누가 사용할까?
제품을 사용하는 사용자는 크게 두 그룹으로 나눌 수 있었습니다.
‧ 정보에 빠르고 신용카드를 잘 아는: 자신의 소비패턴을 인지하고 있고, 그에 따라 필요한 혜택이 무엇인지 매우 잘 아는 사용자
‧ 신용카드 니즈가 있지만, 아직 잘 모르는: 신용카드가 필요하지만, 아직 자신에게 맞는 혜택이 무엇인지 모르는 사용자
데이터를 확인해보니, 후자의 그룹이 대다수를 차지하고 있었습니다.
step 2. 제품이 가진 문제점 찾기
기존의 제품은 원하는 혜택을 명확하게 알고 있어야 다음 퍼널로 진입할 수 있는 구조였습니다. 이 때문에 카드를 고른 후에 각 카드가 가진 혜택을 꼼꼼하게 읽고 비교해야 했습니다. 즉, 카드에 대해 잘 알고 있는 유저 세그먼트에 더 적합한 제품이었던 것입니다.
step 3. 가설 세우기
찾은 문제를 어떻게 해결할 수 있을까 고민하며 가설을 세웠습니다. '카드에 대해 잘 모르는 사용자들은 카드를 발급하는 것에 앞서, 혜택을 비교하는 것에 어려움을 겪는 것은 아닐까?'라는 생각을 했습니다. 이를 토대로 '혜택을 최대한 쉽고 명확하게 보여주면, 클릭과 발급이 증가할 것'이라는 가설을 세웠습니다.
step 4. 개선안 만들기
혜택을 쉽고 명확하게 보여주기 위해 카드 섹션을 바꾼 개선안을 도출했습니다. 같은 통신비 할인 카드라고 해도, 카드마다 할인율이 다르기 때문에 특화된 혜택 3가지만을 노출하였습니다. 또한 우선순위가 낮은 전월 실적과 이외의 혜택들은 추가 뎁스 페이지에 넣어 구성함으로써, 더 알고 싶은 니즈가 있는 경우에만 접근할 수 있도록 하였습니다. 이는 사용자의 반응을 유도하기 위해 제품의 가치를 먼저 전달하라는 원칙을 반영한 것이었습니다.
step 5. 제휴사 설득하기
대부분의 제휴사 관계자들은 기존에 보이던 구성과 달라지는 것에 대한 우려가 있었습니다. 카드 정보를 최대한 많이 노출해야 사용자가 더 많이 반응할 것이라고 추측했기 때문인데요. 토스팀은 오히려 요약된 혜택 정보가 콘텐츠를 돋보이게 할 것이고, 효율을 높일 것이라 설득했습니다.
step 6. A/B 테스트하기
테스트 결과 클릭률은 38%가 증가했고, 인당 클릭 카드 개수는 40%가 증가했습니다. 요약된 혜택 정보가 사용자의 클릭을 확실히 유도한다는 점을 증명할 수 있었습니다. 하지만 클릭률만큼 발급률이 나오지 않았기 때문에, 절반은 개선했지만 나머지 절반은 개선하지 못했다고 판단하였고, 다시 step 2로 돌아가게 되었습니다.
again step 2-3. 제품이 가진 문제점 찾기 & 가설 세우기
사용자는 여전히 카드를 탐색만 할 뿐 발급을 결정하지 못하고 있었고, 제휴사는 카드 종류에 상관없이 발급량만 늘리면 된다는 니즈가 있었습니다. 이 두 지점을 고려하여 '카드를 선별하여 추천해주면 발급으로 이어지지 않을까?'라는 가설을 떠올렸습니다.
again step 4. 개선안 만들기
카드를 선별하는 과정에서 수백 개의 카드를 모두 잘 보여주는 것은 욕심이라 생각하기 때문에 카드 맞춤 추천 서비스 전면에 10개의 카드만을 노출하였습니다. 카드사별 혜택 좋은 카드들로 채워졌고, 결과적으로 발급량이 13% 증가하였습니다.
하지만 여전히 발급량을 확 키울 수 있는 장치가 필요했습니다. 그렇다면 '개인 금융 정보 기반으로 개인화된 추천을 해주면 어떨까?'라는 가설을 세웠고, 추천 배너를 만들게 되었습니다. '만약 김00이 대중교통을 타고 다니는 회사원이라면, 토스가 그의 소비 내역을 트래킹해서 교통비 할인을 가장 많이 받을 수 있는 카드 단 한 개만을 추천해준다.' 이러한 추천 배너는 앱상에서 얼마를 어디에 썼는지, 소비 내역을 확인한 후에 볼 수 있도록 배치하였습니다. 경험을 연결함으로써 인지 구조를 자연스럽게 만들었고, 맥락이 형성된 추천을 통해 CTR 45%를 이루어냈습니다. 가설과 검증의 반복으로 발급량 60% 그리고 매출 26% 증가를 만들어낼 수 있었습니다.
마치며
최근에는 스프린트 + 린 스타트업 + 애자일 조직 문화를 결합하여 적용하는 것이 보편적이며, 많은 조직에서 이를 시도하고 있습니다. 그러나, 작은 규모의 자율적인 팀이 오히려 단편적이고 불합리한 경험을 만들어낸 사례가 있는 만큼, 고객 경험을 희생하면서 속도와 자율성을 추구하는 것을 주의해야 합니다. 토스의 사례를 들어보니, 이러한 조직문화가 필요한 상황에 필요한 요소를 잘 적용했다는 인상을 받았습니다. 조직 구조와 일하는 방식에 많은 투자를 한 회사인 만큼, 이러한 문화를 도입하려는 조직에 좋은 사례가 될 것이라 생각합니다.
긴 글 읽어주셔서 감사합니다.