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

과거의 토스는 간편송금만 가능 했지만 현재는 어느덧 4개의 계열사, 100여 개 이상의 제품을 담고 있는 덩치 큰 앱이 되었습니다. 그러한 과정 속에서 사용자 가치 중심으로 서비스를 과감하게 갈아엎은 토스 프로덕트 디자이너님의 글을 공유드립니다. ⛹🏻'내 문서함' 서비스의 배경 갈아엎게된 서비스는 '내 문서함' 서비스로 사용자가 집으로 받아보는 세상의 모든 종이 서류를 토스에서 모아볼 수 있도록 하자는 목표를 가진 서비스였습니다. 최종적으로는 받은 고지서를 바로 기관에 제출하거나 납부하여 세상의 모든 종이 서류를 없애는 가슴 뛰는 비전을 가지고 있었습니다. 이 서비스는 내 정보, 내 신용점수와 함께 유저 정보를 상단에 묶어서 보여줬었고 전체탭 내 상단에 배치 되었기에 트래픽이 높았습니다. 💁‍♂️'내 문서함' 서비스의 문제점 '내 문서함' 서비스명만으로는 어떤 기능인지 직관적으로 이해하기 어려웠습니다. 사용자의 시야로는 문서가 부동산 문서나 내 계좌 서류 등 다양한 종류의 문서로 해석될 수 있기에 진입하기 전까지는 '서비스를 직관적으로 이해하기 어렵지 않을까' 라는 문제의식이 있었습니다. 또한 여러 서비스가 붙으면서 복잡도가 너무 높아졌습니다. 해당 서비스에 가장 중요한 기능은 내가 받은 문서를 확인하는 것인데 새로 신청 가능한 문서 서비스가 늘어날 때마다 서비스를 알리기 위한 구좌가 하나씩 추가되었기에 시간이 지날수록 서비스가 복잡해졌습니다. 그 결과로 토스앱은 사용자가 생각하지 않고 본능적으로 쓸 수 있는 상태인 Simplicity여야 하는데 서비스에 들어와서도 기능을 이해하지 못하는 상황이 발생했습니다. 또한 팀 내에서는 스펙 구조가 모두 다른 서비스를 한곳에 끼워 묶다 보니 끼워맞추기식의 정책과 로직이 쌓여갔습니다. 엣지 케이스는 작지만 매일 발생했고 방지를 위해 만든 기능과 로직이 또 다른 기능과 로직을 낳게 되어 디자이너와 개발자의 운영 리소스가 많이 쓰이게 되었습니다. 🤔 왜 이런 문제가 발생했을까요? 첫 번째는 조직 구조를 제품에 그대로 반영한게 문제였습니다. 팀 내에서는 '사용자가 우리의 조직 구성을 알게 하지마라'는 이야기가 있는데요. 팀 내에서 효율적으로 생각하는 사업 단위로 팀을 구성했고 각 애자일 조직이 목표를 향해 달려가다 보니 이를 편하게 하기 위해서 공급자 관점에서 제품을 구성해버렸습니다. 두 번째는 끝그림을 생각하고 제품을 구성한게 문제였습니다. 이해관계가 복잡한 사업 특성상 일정이 중구난방이다 보니 원하는 그림을 원하는 순간에 만들 수 없었고 처음부터 디자인, 개발 구조를 최종적으로 생각하는 방향에 맞춰서 설계할수밖에 없었습니다. 큰 제품을 뜯어고치기 위해서는 굉장한 용기가 필요합니다. 또한 1명의 사용자라도 잘 사용하고 있다면 갈아 엎었을 때 그 사용자는 불편함을 느낄수밖에 없고 다시 처음부터 학습하기 위해 큰 비용을 치루긴 합니다. 하지만 모든 운영 리소스를 한 번에 끊어내는 것이 장기적으로는 더 빠른 속도와 큰 효율을 가져올 것이라고 생각하고 시작했습니다. 🎆 갈아엎기 전에 고민했던 것들 가장 먼저 복잡한 화면을 정리하기 위해 정보 위계를 해결하고 싶었습니다. 어떤 정보가 중요하고 우선순위가 높은지, 어떤 서비스끼리 어떤 속성으로 묶어야 하는지 고민했고 또한 유저 행동과 가치에 집중해 유저의 행동에 맞게 제품을 잘게 쪼개보았습니다. 사용자가 생활에서 해당 서류를 접했을 때 어떤 행동을 먼저 떠올릴지 각 제품에서 유저가 행할 메인 액션은 무엇인지를 고민했습니다. 👩‍💻 갈아엎기 위해 진행했던 것들 1. 욕심 버리도록 설득하기 '내 문서함'은 탭에서도 상단에 위치했기에 좋은 트래픽을 받고있었습니다. 하지만 유저를 위해 제품을 모두 쪼개니 더 이상 하나의 진입점에 넣을 수 없었고 팀원들에게 쪼갠 제품을 맞는 카테고리 메뉴에 넣어야 한다고 설득했습니다. 결과적으로 황금땅을 벗어나 단기적인 지표 달성을 포기하고 사용자 가치를 중심으로 생각하면서 장기적인 제품 성장에 도움이 될 것이라는 믿음을 갖기 시작했습니다. 2. 운영 리소스 최소화하기 운영 리소스를 줄여야 우리가 정말 달성하고 싶은 목표에 집중할 수 있습니다. 매번 새로운 종류의 알림이 추가될 때마다 에러가 몇 백개씩 추가되었기에 과감하게 라이팅을 포기하고 서버에서 받는 그대로 보여주기로 결정했습니다. 3. 캐쥬얼하고 직관적인 컨셉으로 사용자가 바로 제목만 보고 이해할 수 있으면서도 어렵게 느끼지 않았으면 했습니다. 그렇다고 직관적으로 이름을 정하자니 너무 지엽적이고, 제너럴하게 쓰자니 '내 문서함'과 같은 네이밍이 될 수가 있었습니다. 결과적으로 고민한 멘탈 모델을 활용해 서비스를 사용자에게 각인시키고 사용자가 무리없이 받아들이고 있다는 점을 확인했습니다. 💁‍♂️ 결론 여러 가지 방법의 설득과 고민 과정을 통해 다른 형태와 모습으로 서비스를 정리할 수 있었습니다. 결국 전체 앱 관점을 바라보고 제시할 수 있는 사람은 디자이너 입니다. 사일로 구조와 애자일 조직에서는 본인 팀의 사업과 제품 목표 달성만을 위해 달려가기에, 전체 사용 흐름과 앱 구조를 보기가 어렵습니다. 하지만 유일하게 봐줄 사람은 사용자를 대표하는 디자이너입니다. 디자인이 잘 안풀린다면 과감하게 작업하던 화면을 닫고 사용자 가치 중심으로 다시 제품을 바라보세요.