당신의 제품은 빚을 늘리고 있다
제품 부채(product debt)에 관하여
원문: “What Can You Remove From Your Product?” by Tomasz Tunguz
Redpoint라는 VC에서 SaaS 컴퍼니의 시리즈 A, B 투자를 담당하는 파트너인 Tomasz Tunguz가 쓴 글입니다. 실제로 운영되고 있는 서비스를 중단할 때 어떻게 결정하고 실행하는지에 대해 궁금하면 “프로덕트, 더하지 말고 빼라” 를 함께 읽어보셔도 좋을 것 같습니다.
보탤 것이 없을 때가 아니라, 뺄 것이 없을 때 비로소 완벽해 진다.
— 앙투안 드 생텍쥐페리
내가 구글에서 일 할 때의 얘기다. AdSense에 필터링 기능을 새로 추가했다. 그 당시에는 이미 수십만의 퍼블리셔*들이 AdSense를 이용하여 광고 성과 레포트를 내려받거나, 웹사이트의 스타일에 맞도록 광고를 설정하거나, 게재되는 광고의 우선순위를 설정하는 등의 업무를 수행하고 있었다.
*퍼블리셔: 광고를 게재하여 수익을 얻는 매체(뉴스 사이트, 블로그 등)
안타깝게도 전체 유저의 2% 미만의 유저만이 필터 기능에 관심을 가졌다. 출시 몇 주 만에, 나는 기능을 빼야
할지 고민하게 됐다. 한편, 수백 명 정도의 유저는 우리가 고생해서 만든 기능을 기쁘게 사용하고 있었다.
반면에, 우리는 기능을 사용하지도 않는 다른 수십만의 유저에게 복잡한 것을 하나 더 늘린 것이었다. 게다가 프로덕트와 엔지니어링 쪽도 더 복잡해졌다. 어떤 면에서, 우리는 제품 부채를 늘리고 있었다.
제품 부채(product debt)는 개발자들을 몸서리치게 하는 기술 부채(technical debt)와는 차이가 있다. 기술 부채는, 처음에 스케일을 고려하지 않았거나 코드를 난해하게 작성하여, 상당한 양의 예전 코드를 고쳐야 하는 것을 말한다. 새로운 것을 만드는 게 리팩토링이나 다시 만드는 것보다 훨씬 재밌다.
제품 부채는 기능이 정상적으로 돌아가고는 있지만, 너무 적은 유저만이 사용하고 있는 경우를 말한다. 그런 제품 부채가 더 복잡한 경우를 만들기도 한다. 예를 들면 퍼블리셔가 언어, 지역, 키워드, 인구 통계학적 정보, 플랫폼 등 더욱 다양한 필터를 원하게 될 수도 있다.
여러 필터를 동시에 사용하는 경우를 고려하면, 기하급수적인 조합이 된다. 극소수의 유저에게만 도움이 될 뿐인 필터 항목을 하나 추가할 때마다, 모든 필터의 조합을 고려해야 하는 것이다.
디자이너들은 이런 복잡성을 잘 풀어낼 인터페이스에 대해 고민해야 하고, QA팀은 모든 것이 잘 돌아가고 있는지 확인하기 위한 테스트 코드를 추가해야 한다. 또 PM들은 다른 기능을 추가할 때 더 복잡도를 갖게 된다. 마지막으로 가장 중요한 것은, 유저들이 더 복잡해진 제품을 사용해야 한다는 사실이다.
유통업에서는, 재고를 유지하는 데에 들어가는 모든 비용을 일컫는 말인 ‘재고 유지 비용(inventory carrying cost)'이라는 개념을 사용한다. 창고를 빌리고, 관리할 직원을 고용하고, 운송하는 비용과 재고 가치 하락분(감가상각) 등이 모두 이에 해당한다. 재고 유지 비용의 개념은, 더 많은 제품이 항상 더 나은 것은 아니라는 부분을 이해하기 쉽게 해준다. 더 많은 것을 유지하기 위해서는 더 큰 비용이 발생하므로.
스타트업의 프로덕트에도 재고 유지 비용의 개념을 적용해 볼 수 있다. 프로덕트와 엔지니어링 조직은 유지 비용의 상한선을 확실히 정해두어야 한다. 최소 몇 퍼센트의 유저가 사용해야 기능을 유지할 것인가? 몇 퍼센트의 과금 유저가, 또는 얼마의 매출이 발생해야 기능을 유지할 것인가?
기준 미달인 기능을 제거함으로써 제품 개발 조직은 더 빠르게 움직일 수 있고, 제품 부채를 줄일 수 있고, 또 유저에게 더 나은 경험을 선사할 수 있다. 알다시피, 그게 가장 중요한 거니까.
역자 주.
고객이나 내부 구성원이 원하는 대로 기능을 추가만 하다보면, 어느새 엄청난 제품 부채를 떠안고 있는 것을 발견할 수 있습니다. 제품이 무거워지면, 다른 기능을 추가할 때도 고려해야 하는 요소가 많아서 어려워지고, 문제상황이 발생했을 때 원인 규명에 더 많은 시간이 들어갑니다.
물론 유저가 ‘원하는' 제품을 만들기 위해서 외부의 input에 귀기울여야 합니다. 때로는 당장의 B2B 계약 성사를 위해 기능 추가가 필요할 때도 있습니다. 중요한 것은, 제품 부채를 덜 늘리는 방향에 대해 고민하고, 때로는 정리하는 시간을 가지며, 그 때 불만을 가질 수 있는 유저에게 납득할 수 있는 설명을 제공하는 것입니다.
특정 회사의 요청에 의해 제공한 기능이 있다면, 주기적으로 사용량을 체크한다. 사용 되는 정도가 내부의 관리 비용보다 적다고 판단되면, 해당 회사에 이 사실을 말하고 기능을 정리한다. 이 때, 데이터 기반으로 커뮤니케이션한다.
소수의 다양한 니즈가 있을 것으로 보이는 부분은 더 유연한 사용이 가능하도록 만든다. 예를 들면, 모든 자료의 export 기능을 각각 지원할 것이 아니라, 원하는 자료를 선택해서 결과값을 받아갈 수 있는 API를 지원한다.
제품 부채를 없애기는 어렵겠지만, 최소한으로 가져가기 위한 고민은 필요합니다. 관련해서 생각나는 에피소드가 있거나 제품 부채를 관리하는 노하우가 있다면 댓글로 공유해주세요.
더 많은 글을 만나보시려면 Build Magazine을 구독해보세요.
We Build Product 페이스북 페이지를 통해서도 구독할 수 있습니다.
