크고 복잡한 제품, 과감하게 갈아엎기

장기적으로 진행되는 큰 규모의 사업 제품을 맡은 디자이너라면 한 번쯤 이런 경험이 있을 것 같아요.

디자이너 : 지금 있는 기능을 모으면 이런 모습일 것 같아요. 팀원 1 : 그런데 이 사업도 지금 진행 중이고, 이 기능이랑 서비스도 곧 붙이게 될 것 같아요. 이것들이 들어갈 곳이 고려되어야 할 것 같은데… 디자이너 : 네. 그럼 결국 끝그림은 이런 컨셉과 방향이 맞을 것 같네요.

빠른 속도를 위해 작은 실험을 중심으로 제품을 출시하고 개선하는 애자일 조직은 어떨까요? 사업과 제품의 끝그림을 처음부터 고려하고 있을까요?

토스는 어느덧 4개의 계열사, 100여 개 이상의 제품을 담고 있는 덩치 큰 앱이 되었어요. 한 팀에서 맡는 제품의 규모가 커지고 이해관계자도 점점 복잡해지고 있어요. 수많은 제품 간의 연결성을 이어주며 토스 앱을 구성하는 것이 중요한 일이 된 거죠. 이로 인해 디자이너들도 어떻게 하면 빠른 속도를 내며 전체적인 경험을 맞출 수 있을지 매 순간 고민하고 있어요. 오늘 제가 들려드릴 이야기는 과거 1년 전쯤 맡았던 ‘내 문서함’이라는 완성된 제품을 다시 쪼개버린 이야기예요. 한창 진행 중인 사업들과 오픈 예정인 서비스들을 뒤로하고 서비스를 갈아엎은 내용이죠.

프로젝트의 배경

기존 내 문서함 서비스는 사용자가 집으로 받아보는 세상의 모든 종이 서류를 토스에서 모아볼 수 있도록 하자는 목표를 가진 서비스였어요.

수도요금/전기세/아파트 관리비와 같은 생활 고지서를 받아보거나, 경찰청의 교통 과태료와 같은 고지서는 물론 주민등록등본/코로나접종증명서와 같은 서류를 직접 발급할 수 있고요. 최종적으로는 받은 고지서를 바로 기관에 제출하거나 납부하여 세상의 모든 종이 서류를 없애는 가슴 뛰는 비전을 가지고 있었어요. 이런 배경으로 서비스명을 정하게 되었고 토스 전체 탭 내에 이와 같이 구성되어 있었어요. 내 정보, 내 신용점수와 함께 유저 정보를 상단에 묶어서 보여줬죠. 상단에 위치하고 전체탭의 트래픽이 높아서 꽤나 많은 유저들이 내 문서함으로 진입하고 있었어요.

하지만 다음과 같은 문제가 있었어요.

내 문서함 서비스명만으로는 어떤 기능인지 직관적으로 이해하기가 어려웠어요. 서비스를 기획하고 만드는 사람 입장에서 바라보면, 세상의 모든 문서를 없애고 모든 서비스가 문서라는 속성이기 때문에 내 문서함이라고 정한 것이죠. 하지만 사용자 입장에서는 사용자마다 문서가 부동산 문서나 내 계좌 서류 등 다양한 종류의 문서로 해석될 수 있기 때문에, 진입하기 전까지는 ‘서비스를 직관적으로 이해하기 어렵지 않을까’라는 문제의식이 있었어요.

두 번째는 내 문서함 화면에 여러 서비스가 붙으면서 복잡도가 너무 높아지는 문제가 있었어요. 내 문서함에서 가장 중요한 것은 내가 받은 문서를 확인하는 것인데 새로 신청 가능한 문서 서비스가 늘어날 때마다 서비스를 알리기 위한 구좌가 하나씩 추가되고 있었어요.

사용자는 받은 문서를 가장 먼저 확인하고 싶은데 국민비서 알림 신청도 유도하고 싶고 주민등록등본이 발급 가능하다는 것도 알리고 싶다 보니 화면 내에서 우선순위 정리가 되지 않았던 것이죠. 토스의 Product Principle 중 하나인 One thing per One page를 지키지 못하고 있었어요.

화면의 복잡도 문제는 다른 문제로도 이어졌어요. 유저들이 들어와서도 내 문서함을 이해하지 못했어요. 유저가 본능적으로 제품과 화면을 이해하지 못하니 팀에서는 기능에 대해 설명을 해주고 싶었어요. 토스앱은 사용자가 생각하지 않고 본능적으로 쓸 수 있는 상태인 Simplicity여야 하는데 별도의 화면을 추가해 기능을 소개하고 싶었던 것이죠.

사용자 문제뿐만 아니라 팀 내 운영에서도 문제가 있었는데요. 스펙 구조가 모두 다른 서비스를 한 곳에 끼워 묶다 보니 끼워 맞추기 식의 정책과 로직이 쌓여갔어요. 내 문서함에 보여주는 문서들은 사업 상, 모두 다른 회사나 정부로 받아오는 API를 이용해 제품 개발을 해야 했는데요. 이 제품에는 맞지 않는 스펙이지만 다른 제품과 맞추기 위해 억지로 가능하도록 스펙을 추가했던 것이죠.

예를 들어, 내 문서함에는 오래된 → 최신 시간 순으로 받은 문서를 쌓는 방식으로 구성이 되어있었는데요. KT 통신비 납부 기능은 사실 청구서를 받는 것이 아닌 실시간으로 최신 요금을 조회하는 방식의 스펙이었어요. 억지로 과거의 청구서를 생성해서 쌓아두고 있었죠.

엣지 케이스는 작지만 매일 발생했고 방지를 위해 만든 기능과 로직이 또 다른 기능과 로직을 낳게 되어 결국 디자이너와 개발자의 운영 리소스가 많이 쓰이게 되었어요. 사용성은 점점 더 복잡해질 수밖에 없는 상황이었죠.

왜 이런 문제들이 있었던 걸까요? 제가 속해 있던 페이퍼제로 팀(세상의 모든 종이 서류를 없애는 목표를 가진 팀)은 회고를 통해 이 문제들의 원인이 다음 2가지라고 생각했어요.

첫 번째는 조직 구조를 제품에 그대로 반영한 것이었어요. 팀이 맡은 모든 사업과 서비스를 한 곳에 모아 넣고 그대로 하나의 제품, 내 문서함으로 묶어버렸죠. 토스팀 내에서는 ‘사용자가 우리의 조직 구성(사업)을 알게 하지 마라’는 이야기가 있는데요. 토스팀 내에서 효율적으로 생각하는 사업 단위로 팀을 구성했고, 각 애자일 조직이 목표를 향해 달려가다 보니 이를 편하게 하기 위해서 공급자 관점에서 제품을 구성해 버렸어요.

두 번째 문제는 끝그림을 생각하고 제품을 구성한 것인데요. 초기 내 문서함에는 단 2개의 제품만 존재했어요. 하지만 이해관계가 복잡한 사업 특성상 일정이 중구난방이다 보니 우리가 원하는 그림을 원하는 순간에 만들 수가 없었어요. 처음부터 디자인과 개발 구조를 최종적으로 생각하는 방향에 맞추어서 설계할 수밖에 없었어요. 모종의 이유로 제품의 오픈 일정이 밀리게 되거나 스펙이 변경되게 되면, 기존 설계에 맞춰 새 제품의 스펙을 다시 끼워 맞추곤 했죠. 결국 제품과 스펙이 복잡해지고 리소스는 많이 드는 비효율을 야기할 수밖에 없었어요.

하지만 애자일 조직인 토스에서는 한 번에 규모가 큰 제품을 뜯어고쳤던 경험은 거의 없었어요. 이미 완성되어 가고 많은 리소스를 투여한 제품을 완전히 부수는 것에는 굉장한 용기가 필요했죠. 또한 1명의 사용자라도 이미 서비스를 잘 쓰고 있다면, 사용자가 불편함을 느낄뿐더러 다시 처음부터 학습시키는 것은 굉장히 큰 비용을 치러야 하는 일이에요. 이로 인해 개편하는 결정을 내리기까지도 많은 논의와 고민이 있었어요.

하지만 모든 운영 리소스를 한 번에 끊어내는 것이 장기적으로는 더 빠른 속도와 큰 효율을 가져올 것이라고 생각했어요. 우리는 정말 중요하고 임팩트가 큰 일들을 해야 하고 지금 작은 것들을 끊어내야 중요한 것에 집중할 수 있는 환경을 만들 수 있는 것이라고 말이죠.

진행 과정

팀 내에서 개편 결정 후에도 사실 현재에 오기까지 많은 논의 과정과 고민이 있었어요. 처음에는 복잡한 화면을 정리하기 위해 정보 위계를 가장 먼저 해결하고 싶었어요. 내 문서함 홈의 다양한 안을 그려보면서 어떤 정보가 가장 중요하고 우선순위가 높은지, 어떤 서비스끼리 어떤 속성으로 묶어야 할지 고민했어요.

주민등록등본이나 코로나접종증명서와 같은 문서 발급할 수 있는 ‘증명서 발급’ 탭과 그 외에 조회하거나 납부할 수 있는 ‘조회∙납부’ 탭으로 말이죠.

하지만 조회∙납부 탭에 속한 국민비서 서비스는 교통과태료나 건강검진 안내를 사용자의 별도 액션 없이 일방적으로 알림으로 받는 것이고, 아파트 관리비나 통신비 서비스는 본인이 조회를 해야 했기 때문에 같이 묶는 게 어색하지 않냐는 의견이 있었어요.

또한 탭 이름만 보고 어떤 서비스가 있을지 예상하기 어려웠기 때문에 기존 안의 직관성의 문제가 해결되지 않았어요. 게다가 탭 구조의 한계로 인해 첫 번째 탭인 증명서 발급 탭이 더 강조될 수밖에 없었고, 팀원들은 두 번째 탭의 주목도가 떨어져서 두 번째 탭에 속한 서비스들의 액티베이션 비율이 떨어질 것 같다는 우려가 있었죠.

이런 우려를 보완하기 위해 두 번째는 스크롤로 구성해 보았어요.

언제든 등본을 발급받을 수 있도록 최상단에 위치하고 그 아래 내가 신청한 문서들이 도착하면 확인할 수 있게, 하단에는 아직 신청하지 않은 문서 서비스들을 보여주고 신청할 수 있게끔요. 하지만 스크롤을 너무 내리지 않도록 하기 위해 받은 문서를 모두 보여줄 수가 없었고, 더보기를 넣어 불필요한 뎁스와 몇 개의 문서를 어떤 우선순위로 보여줄지 등의 정책이 생길 수밖에 없었어요. 기존에 우릴 괴롭히던 정책과 로직의 지옥, Less Policy를 지킬 수 없게 된 거죠.

화면 안에서 정보 배치, 컴포넌트 수정, 워딩 바꾸기를 한 50번쯤 했을까요. 굉장한 현타와 함께 ‘내가 길을 잃었구나’라는 생각이 들었어요. 해결하고자 했던 문제와 점점 멀어지고 있었어요. 저는 여전히 기존의 내 문서함과 문서에 갇혀있었던 거예요. 근본적인 문제는 화면 안에, 문구 안에 있는 것이 아니었는데 말이죠.

유저 행동에 맞게 제품 쪼개기

잠시 프레이머에서 벗어나보기로 했어요. 유저 행동과 가치에 집중해 유저의 행동에 맞게 제품을 잘게 쪼개보았어요.

사용자가 생활에서 해당 서류를 접했을 때 어떤 행동을 먼저 떠올릴지, 각 제품에서 유저가 행할 메인 액션 (Clear CTA)는 무엇인지를 고민했어요.

기존에는 문서 속성 안에서 ‘받은 문서’와 ‘새로 문서 받기’로 나뉘어있던 것을 모든 제품을 펼쳐두고 유저의 행동별로 다시 그루핑을 하고 제품으로 구성한 것이죠.

또한 서비스 중에는 한번 신청만 해두면 사용자가 굳이 별다른 액션 없이 안내만 받아도 되는 서비스가 있었어요. 보험 통지서의 경우 삼성화재에 가입된 고객만 이 서비스를 신청할 수 있고, 신청만 하면 받아만 보면 되는 것이었죠. 사용자가 굳이 기능을 다시 찾아 들어올 이유가 없었어요. 과감하게 전체탭 메뉴에서 고정 진입점을 제거하고 토스의 알림탭으로만 받을 수 있도록 하였어요.

욕심 버리도록 설득하기

가장 어려웠던 일은 나 자신과 팀원들을 설득하는 일이었어요. 내 문서함은 전체탭에서도 상단에 위치했기 때문에 좋은 트래픽을 받고 있었어요. 하지만 위처럼 제품을 모두 쪼개니 더 이상 하나의 진입점에 다 넣을 수 없었어요. 그렇다면 다시 이들을 묶을 새로운 개념과 뎁스가 생겨야 했고 직관적이지 않은 기존 네이밍 문제를 해결할 수 없었기 때문이죠.

저는 팀원들에게 위 기준으로 쪼갠 제품을 맞는 카테고리 메뉴에 넣어야 하고, 상단에서 내려올 수밖에 없다고 했어요. 하지만 우리 제품을 알리는 PO 입장에서는 이 ‘황금 땅’을 벗어나기가 싫었던 거죠. 게다가 PO는 ‘이 서비스를 쓰기 위해 들어왔다가 → 우연찮게 이 서비스를 보게 될 것이고 전이된다, 즉 cross activation 효과’를 포기할 수 없었죠.

저는 계속 질문을 던졌어요.

황금땅을 유지하는 것은 일시적인 유입을 늘릴 수는 있겠지만, 사용자가 강한 동인 없이 그 제품을 마주했다면 제품의 진짜 가치를 알기 어렵고 다시 찾기도 힘들 거예요. 기존 내 문서함 화면은 들어온다 하더라도 너무 다양한 맥락의 제품이 뒤섞여있어서 사용자가 이해를 할 수도 없었고요. 디자이너라면 모두 공감할 거예요. 비즈니스 목표를 달성하면서도 사용자의 경험을 최상으로 유지하는 것은 매우 어렵고 큰 용기를 필요로 한다는 것을요. 단기적인 지표 달성보다는 사용자 가치를 중심으로 생각하면 장기적인 제품 성장에 도움이 될 것이라는 믿음을 가지는 게 중요했죠.

우리를 괴롭히는 운영 리소스 최소화하기

제품 별 운영 리소스를 최소화하는 일도 해결할 중요한 문제 중 하나였어요. 운영 리소스를 최소화해야 우리가 정말 달성하고 싶은 목표에 집중을 할 수 있으니까요.

기존 내 문서함에서는 행정안전부 API에서 내려오는 에러 문구가 있었어요. 하지만 API에서 내려주는 문구는 토스의 라이팅과는 맞지 않았기 때문에 에러가 추가되거나 발견될 때마다 서버 개발자가 디자이너에게 알려주면 디자이너가 일일이 수정하고 있었어요.

매번 새로운 종류의 알림이 추가될 때마다 에러가 몇 백개씩 추가되었기 때문에 리소스를 해결하기 위해 과감하게 라이팅을 맞추는 것을 포기하고 서버에서 받는 그대로 보여주기로 결정했어요. 대신 이상한 기호들이 포함되어 있으면 공통적으로 들어가 있는 이상한 문구들을 정리하여 제거해 달라고 요청드렸어요.

캐쥬얼하지만 직관적인 컨셉

내 문서함 중 주요 기능 중 하나는 주민등록등본, 코로나접종증명서 등의 개인 민원문서를 발급받을 수 있는 것이었는데요. 주민센터나 정부 24 홈페이지가 아닌 타 앱에서 등본을 뗀다는 것은 너무 혁신적인 경험이었기 때문에 사람들이 이 기능을 예상하거나 이해하기가 어려웠어요.

저는 사용자가 바로 제목만 보고 이해할 수 있으면서도 너무 어렵게 느끼지 않았으면 했어요. 사람들이 가장 많이 받는 증명서인 주민등록등본인 것을 고려해 ‘등본 떼기’로 서비스 명을 바꾸었죠. 하지만 성적증명서나 자격증명서 등도 뗄 수 있었기 때문에 등본 외의 증명서를 찾는 사람들은 오히려 서비스를 찾지 못하는 문제가 있었어요.

직관적으로 이름을 정하자니 너무 지엽적이고, 제너럴하게 쓰자니 ‘내 문서함’과 같은 네이밍이 될 수가 있었어요. 마치 화려하지만 심플한 것처럼 어려운 문제였죠.

저희는 상위 카테고리 명을 활용하였어요. 등본 → 증명서로 제너럴하게 바꾸되, 보통 등본은 주민센터에서 떼니 여기서 착안해 주민센터-증명서 떼기로 민원 증명서를 의미함을 내포했죠. 등본 발급 하면 바로 주민센터를 떠올리기 때문에, 이 멘탈 모델을 활용해 이 서비스를 사용자에게 각인시키기도 수월할 것으로 생각했어요. 덕분에 외부로부터도 칭찬받고 사용자도 무리 없이 받아들이고 있다는 점도 확인할 수 있었어요.

정리

약 2달간 여러 가지 방법의 설득과 고민 과정을 통해 다른 형태와 모습으로 서비스를 정리할 수 있었어요. 간편 송금만 가능했던 토스가 커져가는 것처럼, 저도 작은 제품을 개선하다가 크고 복잡한 제품을 개선하는 과정에서 배운 것이 많았어요.

결국 전체 앱 관점을 바라보고, 제시할 수 있는 사람은 디자이너뿐이라는 것이죠. 사일로 구조와 애자일 조직에서는 본인 팀의 사업과 제품 목표 달성만을 위해 달려가기 때문에, 전체 사용 흐름과 앱 구조를 보기가 어려워요. 하지만 유일하게 봐줄 사람은 사용자를 대표하는 디자이너라는 거예요.

여러분 혹시 디자인이 잘 안 풀릴 때가 있나요? 그렇다면 분명 그 답은 화면에 있지 않을 거예요. 과감하게 작업하던 화면을 닫고 사용자 가치를 중심으로 다시 제품을 바라보세요. 그럼 지금 눈앞의 컴포넌트나 라이팅이 해결책이 아닌 다른 해결책이 보일 거예요.

Q. 토스의 Product Principle은 어떤 것이 있는지 궁금해요.

Product Principle은 토스 제품의 winning strategy 를 담고 있는, 기준이 되는 제품 디자인의 원칙이에요.

Simplicity 단순함은 토스 제품의 core principle 입니다. 단순함이란, 사용자가 토스 제품을 사용하기 위해 특별히 ‘알아야 할 것’, ‘배워야 할 것’이 없으며, 본능적으로 이해할 수 있음을 의미합니다.

Simplicity를 만드는 방법 이 본능적인 사용을 가능하게 하려면 우리가 고려해야할 세가지 비용이 있습니다. 바로 인지 비용, 심리 비용, 노동 비용이 바로 그것입니다.

1. 1초만에 이해되게 만들기 (인지적 비용 줄이기)
   • Casual Concept 어려운 금융의 개념을 친숙하고 이해하기 쉽게 만들었는가?
   • One thing per One page 하나의 화면에 하나의 명확한 목표가 들어가는가?
   • Clear Call to Action 과업을 완료하기 위한 CTA가 명확하게 드러나는가?
   • Less Policy 고객이 사용을 위해 ‘알아야 할’ 것을 없앨 수 있는가?
   • Easy to Answer 과업 완료까지의 모든 질문은 3초 안에 대답할 수 있는 것들인가?
   • Minimum Features 이 기능 없이는 절대 목표를 달성할 수 없나?
2. 하고 싶게 만들기
   • Explain Why 왜 이 과업을 완료해야하는지 고객에게 충분히 설명했는가?
   • No Ads Patterns 습관적으로 광고 문법으로 소구하고 있지는 않은가?
   • Value First 뭐가 좋은지도 모르는데 정보 입력을 요구하거나 비용을 이야기하진 않는가?
   • Personalize 고객에게 맞춤 경험을 제공했는가?
   • Context Based 앞 뒤 상황의 맥락이 이어지는가?
3. 하기 쉽게 만들기
   • Sleek Experience 전체 Flow가 물 흐르듯이 진행되는가?
   • Low-cost action 노동 비용이 더 적게 드는 경험을 만들었는가?
   • No more loading 핵심 Flow 에서 기다림을 완전히 없앴는가?

Q. 지표를 달성해야 하는 환경에서 의사결정권자를 설득하는 것은 어려운 것 같아요. 지윤님께서 말씀하신 것과 같은 논리가 통할 수 있는 것은 조직문화에서 비롯된 것인가요?

토스에서도 지표 달성을 위해 모든 팀원이 노력해요. 저 역시도 누구보다도 그 목표를 달성하고 싶은 팀원이고요. 하지만 이러한 사용자 중심의 해결책, 지속 가능한 해결책을 끊임없이 내고, 이를 시도해 보는 것이 토스의 문화인 것 같아요. 이 근본적인 해결이 결국 우리 모두에게 성공과 성과로 돌아올 것이라는 믿음을 갖고 사례를 많이 쌓는 것이 중요한 것 같아요. 이 사례들이 모여 모두가 이 방법이 가능하다는 것을 알게 되고 더 전파되게 되고요.

작은 것이라도 포기하지 말고 근본적인 문제를 해결하기 위한 방법을 끊임없이 시도해 보는 것이 중요하다고 말씀드리고 싶어요!