Intro

나는 학생창업으로 스타트업 대표 명함도 만들어봤고, 졸업 후에는 PM으로 정식 커리어를 시작했다. 그리고 우연한 기회에 개발자로 전향하여 지금까지 커리어를 이어오고 있다. 처음 개발자로 업무를 하면서 가장 낯설었던 부분은 개발팀 내부에 암묵적으로 강요되는 '기획/디자인 산출물에 대한-특히 사용성에 대한- 타협 없는 성역화'였다. 개발자가 요구받은 스펙에 개발 난이도가 높고, 개발에 소요되는 시간이 많다는 이유로 이의를 제기하는 것은 개발자의 능력이 부족하다는 방증이고,(물론 명확한 이유도 설명도 없이 '안됩니다'만 남발하는 개발자는 그 자체로 무능한 것이 맞다.) 유능한 개발자라면 개발팀 내부에서 어떻게든 스펙대로 구현하는 방법을 찾아내서 그대로 구현해내야한다는 것이다. 실제로 어떤 스펙에 대해서 5일 정도 리소스가 소요되는 방법을 유사한 사용성으로 10분 이내로 구현할 수 있는 다른 선택지를 제시했지만, 디자인팀에게 가급적 기술적인 이유를 꺼내지 말고 5일이 걸릴거 같으면 차라리 그냥 5일로 일정을 두고 업무를 진행하라는 피드백을 들었던 적도 있다. 하지만 정말로 그것이 옳은 의사결정일까?

PM으로 근무하던 시절 나는 기획에 있어서 예상되는 개발 리소스를 개발자에게 매번 물어봤고, 이를 기반으로 일정을 수립했었다. 어떤 의사결정을 내릴 때 최종 결과물의 완성도뿐만 아니라, 거기에 투입되는 인풋까지 고려하여 효율적인 의사결정을 하기 위해서였다. 내가 1,000원짜리 물건을 판매하는데 원가가 1,200원이라면 이 장사는 안하는 것만 못하다. 너무나 명백하지만 유독 '사용성'이라는 단어만 개입되면 마법처럼 이 사실을 잊게 되는 것만 같다. 우리는 실제로 지표에 긍정적인 영향을 주는 스펙과 단순히 사용성 개선 그 자체가 목표인 스펙을 구분해야할 필요가 있지 않을까?

사용성은 실제로 어느 정도의 영향력을 갖고 있을까

좋다. 사용성이 실제로 프로덕트 성장에 절대적으로 중요한 가치라면 이해할 수 있다. 그렇다면 응당 타협할 수 없는 성역화가 이루어지는게 모두에게 유익한 방향일 것이다.

상상해보자. 전세계에 배달앱이란 오직 '배민' 하나밖에 없다. 그런데 그 '배민' 사용성이 지금과 비교도 안 될 정도로 처참하다면 어떨까? 사용성이 거지같은 앱이라 사람들은 '배민'을 쳐다도보지 않았을까? 그럼에도 대안이 없기에 모두가 '배민'을 썼을까? 나는 그럼에도 불구하고 사람들은 배민을 썼을 거라고 생각한다. 배민은 배달 음식을 편하게 주문하고 싶다는 사람들의 니즈를 포착해 비즈니스 기회를 창출했고, 그것을 공략했다. '음식점과 메뉴를 검색하고, 우리집으로 주문을 한다'는 비즈니스 핵심 프로세스만 공고하다면 그 외 사용성은 그저 조금 더 편리함을 더해줄 뿐 의사결정에 큰 영향을 끼치지는 못한다.

사용성은 비즈니스에 우선할 수 없다. 이런 논리는 MVP에 그대로 녹아 있다. MVP를 만들 때 섬세한 사용성을 고려하고 각종 예외처리를 고민하며 만드는 사람은 많지 않다. 오히려 그렇게 출시가 늘어지게 되면 MVP라고 부를 수도 없다. 말 그대로 최소한의 기능을 구현하여 시장에서 가능성 있는 프로덕트인지 판단하는 것이 목적이기 때문이다. 반대로 말하자면 프로덕트가 시장의 니즈만 충족한다면 최소한의 사용성만으로 유저들을 끌어들일 수 있다는 것이다.

여기에 반박하는 사람은 많지 않을 것이다. 다만 UX를 타협할 수 있는 범위는 딱 MVP까지라고 생각할 수는 있다. 하지만 나는 그렇게 생각하지 않는다. UX는 그 자체로는 어떠한 의미도 가질 수 없다. 사용성 개선은 비즈니스 기회를 창출하고 프로덕트의 성장으로 이어져야만 그 의미를 가질 수 있다. 조금 격하게 말하자면 프로덕트의 성장으로 이어지지 않는 사용성 개선은 메이커 본인의 자기만족 이상의 가치를 지니기 어렵다.

사용성이 좋아야 유저들 이탈을 막을 수 있다고 주장할 수 있다. 이는 사실이다. 하지만 내가 위 '배민' 예시에서 '전세계에 배달앱이란 오직 배민 하나다'라는 조건을 달았던 것을 기억할 필요가 있다. 결과적으로는 모두 상대적인 것이다. 사용자들의 눈높이가 상향평준화됨에 따라 소소한 불편함을 눈치채고 서비스에 대한 가치를 하향 평가할 수 있겠지만, 결국 우리 프로덕트를 대체하는 대체제가 등장하지 않는 한 그 평가절하가 실질적인 액션으로 들어나기 쉽지 않다. 우리 서비스가 소소한 사용성까지 최고로 갖추어야한다는 강박은 우리 서비스가 경쟁 서비스 대비 비즈니스 적으로 나을게 하나도 없는 특색없는 서비스라는 사실을 인정한 것밖에 되지 않는다. 실제로 경쟁 서비스들 간 차이점이 거의 없는 시장도 많다. 이럴때는 디자인과 소소한 사용성 등 디테일과 브랜딩으로 승부하는게 옳다. 하지만 정말로 우리가 추구하는 것이 그런 시장인지는 깊은 고찰이 필요할 수 있다.

내가 이전에 근속했던 '스톤아이'에서는 '다짐매니저'라는 헬스장 회원관리 프로그램을 판매하는데, 대표님께서 처음 이 시장을 발견하고 대다수의 헬스장들이 엄청나게 구린 서비스를 비싼돈을 주고 구독하고 있었다는 사실에 크게 놀랐다고 하셨다. 이유는 단순하다. 대체제가 없었다. 다른 대안이 없었기에 구린 사용성을 욕하면서도, 혹은 불편한지도 깨닫지 못하고 관성적으로 쓸 수 밖에 없었던 것이다. 이 현상이 다른 카테고리의 프로덕트라고 다를까. 나에게 사용성이란 딱 그정도의 가치로 다가온다. 선택권을 지닌 유저들 입장에서는 1차로 '나에게 이 서비스가 필요한가'를 판단하고, 그 다음에서야 '다른 서비스들보다 나은가'를 판단한다. 그렇다면 이런 결론을 도출할 수 있다. '사용성 개선은 우리 서비스를 선택할 이유를 만들어주던가 다른 서비스로의 이탈을 막을 정도의 효과를 내어야 가치가 있다.' 우리는 소소한 사용성 개선으로 경쟁 서비스와 끝없는 치킨게임을 시작할 것이 아니라, 경쟁서비스와는 차별화된 새로운 비즈니스 기회를 창출하고 고객들에게 새로운 가치를 제공해주는 것에 집중하는 것이 더 좋지 않을까?

나라면 이런 의사결정을 할 것이다

버그를 고칠 것인가 전환율을 개선할 것인가

프로덕트에 명백한 버그가 발생하여 전체 사용자의 8%가 불편함을 겪는 일이 발생했다고 해보자. 다만 비즈니스 핵심 플로우에 영향을 주는 부분은 아니었고, 로그를 살펴보니 6개월간 그 버그가 유지됐음에도 관련 cs는 한번도 유입된 적 없었다. 그런데 당장 코앞에 결제 전환율 3% 향상이 기대되는 스프린트가 예정되어 있다. 두 작업을 동시에 진행할 수는 없을 때 당신은 PO/PM으로서 어떤 작업을 우선할 것인가? 나라면 후자를 선택한다. 프로덕트에 버그가 발생하면 고쳐야하는 게 맞다. 하지만 어떤 것에라도 우선해서 타협없이 즉시 해결해야하는 것은 아니다. 비즈니스 전환율에 영향을 끼치지 않는 작은 버그라도 그런 것들이 모여 서비스 신뢰도를 떨어뜨릴 수 있다고 주장할 수 있다. 어느 정도 동의하지만 그럼에도 불구하고 경쟁 서비스 대비 비즈니스적으로 우위를 선점하는 것이 우선되어야한다고 생각한다. 이런 관점에서 프로덕트의 결함도 우선순위를 정해서 대응해야한다. 버그라고 예외를 둘 수 없다.

고점이 높은 작업과 효율이 좋은 작업

맵에 마커를 찍는 작업을 상상해보자. 처음 지도를 불러오면 100개의 마커가 화면에 찍히고, 그 다음에 클러스터링을 통해 마커를 보기 좋게 정리해준다. 이 과정에서 유저는 처음 진입했을 때 화면을 가득 채우는 100개의 마커를 보게 되고 0.5초 뒤에야 정리된 마커를 보게 된다. 혹자는 이것이 '좋지 않은 사용성이다'라고 판단할 수 있다. 동의한다. 하지만 이 것을 해결하기 위해서 프론트/백 개발자가 워킹 데이로 2일이 소모된다면 이것을 개선하는게 좋을까? 당장 일이 없어서 한가하다면 개선하는게 좋다. 사용성은 개선할 수 있는 환경이라면 무조건 개선하는게 좋다. 이부분은 동의한다. 하지만 서비스에 새로운 수익모델을 추가하는 신규 스프린트가 예정되어 있다면 어떨까. 나는 마커를 개선하지 않는 선택을 지향한다.

들어가는 리소스 대비 얻게되는 편익이 크지 않다는 판단이다. 오히려 기회비용을 생각해봐야한다. 개발자 두명의 워킹데이 2일에 해당하는 일금을 계산해보면 결코 적지 않은 금액이다. 왜 큰 기업들이 센드버드같은 비싼 솔루션을 사용하는지 생각해봐야한다. 유능한 지휘관이라면 인력이 노는 환경을 최소화하고, 전투에서 패배하더라도 전쟁에서는 승리해야한다. 사용자 입장에서 생각해보자. 지도에 진입했는데, 100개의 마커가 0.5초간 노출되었다가 클러스터링으로 이쁘게 보인다고 서비스를 이탈할 이유가 될 수 있는가? 심지어 클러스터링 없이 100개의 마커가 지도에 빼곡히 박혀있더라도 핵심 플로우에 지장이 없고, 사용자의 니즈를 정확하게 긁어주는 서비스라면 그것이 이탈의 이유가 될 수는 없다. 수익성 개선과 관련된 업무가 예정되어 있는데 이런 사용성 개선에 그 리소스를 할애하는 것은 전투에서 승리하고 전쟁에서 불리한 지점을 자처하겠다는 의사결정이라고 생각한다. 10의 리소스를 투자해 5의 편익을 얻는 것은 리소스가 남아도는 조직에서나 할 수 있는 판단이다. 일반적인 스타트업이라면 효율 중심으로 10의 리소스를 투자했다면 적어도 12의 편익은 얻어야 한다고 생각한다.

Outro 주저리주저리

• 기능 개발에는 1일이 걸리지만, 더 좋은 사용성을 위해 3일이 필요하다고 했을 때 타협없이 더 좋은 사용성을 선택하는 의사결정. 프로덕트에 버그가 발생했다면 그 경중을 따지기보다 타협없이 최우선순위로 처리해야한다는 의사결정은 모두 '뛰어난 메이커'로서의 마음가짐이 될 수는 있겠지만, 이는 어찌보면 '예술가'에 더욱 가까운 마음가짐이다. 하지만 나는 '사업가'로서의 마인드를 얘기하고 싶다. 결국 메이커가 의미를 가질려면 서비스가 성장해야한다. 때로는 더 안좋을 수 있는 사용성을 선택하고, 명백한 버그를 묵인할 수 있는 선택이 결과적으로 프로덕트의 성장으로 이어질 수 있다는 사실을 알아야한다고 생각한다. 이것이 조금 더 주인의식에 가까운 마인드이며 조금 더 성숙한 의사결정이 아닐까 생각한다.

• 나도 글을 쓰면서 반례를 열심히 생각해봤다. 사용성이 생각보다 중요한 가치가 아니라면 사용성 변태로 유명한 토스는 어떻게 설명할 것인가? 여기에 대해서 나는 '토스의 사용성은 그 자체로 브랜딩이 된다'고 답변할 것이다. 토스의 경쟁자들은 전통 은행권 서비스였고, 그들에게는 없는 차원이 다른 사용성을 제공해줄 필요가 있었다. 토스의 시작을 떠올려보자. 애초에 토스 탄생 자체가 기존 은행앱에서 제공해주지 않는 편리한 송금 서비스 아니었는가. 토스는 전통 은행권 기업들과는 다른 it기업으로서의 아이덴티티를 강조할 필요성이 있었다고 생각한다. 기술과 사용성을 깎아냄으로써 그 자체로 '토스'라는 브랜드를 만들어갔고, 그로인해 비즈니스 기회를 창출할 수 있었다. (그리고 사실 생각해보면 토스의 기능이라고 특별한게 없다. 은행권 어플에서 모두 똑같이 제공해주는데 기능들인데 위 사례처럼 사용성이라도 변태처럼 깎아서 치킨게임에 돌입한거고 빠르게 선점해서 승리한 것이라고 생각한다.)

• 글만 읽어서는 내용이 그닥 와닿지 않을 수 있다. 누군가는 '당연한 얘기를 왜이렇게 길게하지'라고 생각할 수 있고, 누군가는 '헛소리를 엄청 길게 써놨네'라고 할 수도 있다. 그래서 실제로 경험해봤던 사례를 하나 공유해보려고한다. 프로덕트의 구조적인 모순을 제거해서 큰 성과개선이 기대되는 작업이 있었다. 기술적으로 약간의 검토가 필요하지만 충분히 구현이 가능하다는 판단까지 내렸었다. 하지만 결국 실제 실행까지는 무기한 연기됐는데, 그 이유는 '단순히 난이도가 조금 높다'는 것과 당장 '기존에 계획해놓은 스프린트'가 있다는 것이다. 심지어 그 당면한 스프린트 라는게 리스트의 디자인 개편해서 '더 이쁘고 깔끔하고 정보를 노출해준다' 정도의 내용이었다. 단순히 디자인 개선으로 보기에 좋아지면 클릭률이 올라가고 결제전환율이 올라간다는 막연한 기대에 기대서 진짜 프로덕트에 필요한 의사결정을 외면한 결정이었다고 회상한다.

• 글은 이렇게 썼지만, 실제로 회사에서는 사용성 개선을 위해 최선을 다하고 있다. 요구 스펙에 있어서 기술적인 이유로, 투입 리소스를 이유로 다른 대안을 제시하지 않으려 노력한다. 공과 사는 구분해야하지 않겠나. 나의 가치관이 어떻다 하는 것과 실제로 그렇게 살아가는 것은 전혀 다른 문제다. 조금 더 구체적으로 따지고 들어가보자면 '그렇게 불만이라면 스스로 C레벨 달거나, 창업해서 하고싶은대로 하는게 맞다'라는 가치관 또한 갖고 있기 때문이다. 일개 직원이 이런 가치관을 조금씩 어필해볼 수는 있으나 조직을 어떻게 바꾸고싶은 마음 까지는 없다. 다만 내 가치관이 그렇게 이상한 생각인가, 그렇게 수용될 수 없는 것이고 지적받을만한 가치관인지에 대한 의문이 들었을 뿐이다. 내가 잘못 생각한게 맞다면 그것을 빠르게 깨닫고 고치는게 좋지 않겠나.

• 중요한건 균형점을 찾는 것이다. 내가 이런 가치관을 가지고 있다고 사용성은 모두 개나 줘버리고 개떡같이 생겨먹은 프로덕트를 추구하는 것은 아니다. 사용성은 개선할 수 있으면 무조건 개선하는 것이 좋다. 다만 선택의 기로에서 문제의 우선순위를 결정하는데 있어서 그 경중을 어떻게 판단하느냐의 문제라고 이해해주면 감사하겠다. 나도 UI/UX에 관심 많고 이쁘고 보기좋은 프로덕트를 좋아한다.

• 이런 주장에 입각한 의사결정이 기업 입장에서는 옳을 수 있으나, 구성원들에게도 옳은가는 여전히 고민중이다. 사실 이런 사용성을 깎는 행위, 그로 인해 일반적이지 않은 방법을 구상하고 실제로 구현해내는 과정은 디자이너/개발자들에게 좋은 성장의 기회 내지는 포트폴리오 소재가 될 수 있기 때문이다. 실제로 나 또한 이 과정에서 색다른 경험을 하면서 배운 점도 적지 않다. 그럼에도 고민이라고 한 것은 '구성원의 성장을 위해 기업에 적절하지 않은 선택을 하는 것이 옳은가'하는 점이다. 사실 그런 이유라면 다른 방법으로 달성할 수 있는 것 아닌가라는 생각이 떠나지 않는다. 마치 체력을 증진시키고 근육량을 늘리기 위해 군대에 입대한다는 얘기처럼 들리기도 한다.

• 위 주장은 모두 리소스가 절대적으로 부족한 스타트업 기준의 얘기다. 이미 시장에서 독보적인 지위를 획득한 서비스와 대기업은 사정이 다를 수 있다.