프로덕트, 더하지 말고 빼라

Hyunjung Kang
We Build Product
Published in
7 min readSep 30, 2016

--

무엇을 없앨 것인지는, 무엇을 더할 것인지 만큼이나 중요하다.

원문: <Measure twice, cut once> by Rick Klau, posted on Google Ventures(https://library.gv.com/measure-twice-cut-once-e86c2f08b4c)

더 많은 글을 만나보시려면 Build Magazine을 구독해보세요.

2009년, Blogger가 10년 째에 접어들었을 때, Blogger보다 트래픽을 많이 가진 웹사이트는 전세계에 7곳 밖에 없었다. 무료 호스팅, 안정적인 서비스, 간단한 인터페이스로인해 Blogger는 전세계 블로거들의 인기를 얻을 수 있었다.

수천만의 블로그가 Blogger를 이용해 운영되고 있을 때, 그 중 아주 작은 비율만이 Blogger의 초기 기능인 FTP 퍼블리싱 기능을 이용하고 있었다. 실제로 2001년에 블로그를 열었을 때, 나도 FTP 기능을 사용해서 내 도메인에 호스팅했다.

10주년이 될 때 까지, 0.5% 이하의 Blogger 블로그만이 FTP로 호스팅됐다. 그 와중에 프로덕트 매니저(PM)로 여러 팀 미팅에 참여할 때마다 FTP 기능 지원에 대한 부담이 커져간다는 것을 듣게 됐다. FTP 기능 지원을 중단한다면, 엔지니어들을 그 지원 업무로부터 구제할 수 있고, 그로인해 더욱 빠른 개발 업무가 가능해진다는 것이였다. 물론, 중단하게 된다면 Blogger의 가장 충성도 높은 고객 중 일부에게 상당한 불편함을 줄 것이라는 것을 알았고, 그걸 가볍게 볼 수는 없었다. 1999년의 Blogger에게 FTP는 적절한 기능이였지만, 극히 소수만을 위한 기능이 되었다. 결국 우리는 FTP 기능 지원을 중단했다. 그건 쉽지 않은 결정이였고, 예상했던 바와 같이 여러 사람을 화나게 했다.

운 좋게도, Google Ventures에서 일하면서 포트폴리오에 속한 여러 회사의 창업가들과 프로덕트 전략에 대해 논할 기회를 갖고있다. 필연적으로 PM들은 기능 개발의 우선순위를 어떻게 정해야 할지 알고 싶어한다. 프로덕트 로드맵은 어떻게 만드는지, 고객들의 추가 기능 요구에 대해서는 어떻게 응해야 하는지 묻곤 한다. 하지만 나는 창업자들, 프로덕트 책임자들과 그들의 프로덕트에 대해 얘기할 때, 어떤 기능을 추가할지 얘기하는 시간만큼이나 어떤 기능을 뺄지에 대해 얘기하는 시간을 가진다.

고객이나 잠재 고객이 기능 추가에 대해 요청했을 때, ‘yes’를 말하는 것은 쉽다. 어쨌거나 그건 하루짜리, 또는 이틀짜리 개발이슈니까, 굳이 안할 이유가 있나? 그러나 그럴 경우 당신은 만들고 있는 프로덕트에 대한 시야를 잃게된다. 당신의 프로덕트는 더이상 일관성도 없고, 새 기능을 계속 운영하는한 유지 비용도 계속 들어갈 것이다. 어렵지만 중요한 것은 어떤 기능이 당신이 만들고 있는 프로덕트의 필수 요소인지 그렇지 않은지를 판단하는 원칙을 세우는 것이다. 새로운 것인지, 오래되었는지, 만들기 쉬운지, 아니면 어려운지와는 무관하게, 어떤 기능이 전체 프로덕트의 목적과 맞지 않는다면, 그 기능을 버려야 한다. 고객과 팀 구성원들은 특히 그로 인해 더 나은 지원, 예측 가능한 개발, 프로덕트에 대한 분명한 이해가 가능해진다면, 그 원칙을 따를 것이다.

다시 FTP 얘기로 돌아가보자. Blogger의 개발 책임자들과 나는, 다음 두가지를 FTP 중단에 대한 근거로 들었다.

1. 분명한 결과지표(clear metrics). 1년 넘게 중요 지표를 정해서 상세히 관찰했다. 팀의 모든 멤버들(PM, 개발, 디자인, 지원 담당)이 그 지표들이 우리가 어떻게 하고있는지를 반영한다는 것에 동의했다. 그 지표들은 우리가 FTP를 계속 지원했을 때의 엔지니어링 비용에 대해 현실적으로 평가할 수 있도록 했고, FTP로 인해 개발 업무가 얼마나 지연되는지도 측정할 수 있게 했다. FTP에 들어가는 비용과, 사용하고 있는 유저 수를 함께 생각한 결과, 결정은 더 명백해졌다.

2. 정해진 목적(defined objectives). 2010년 Blogger에서는 여러가지 목표가 있었다. 그 중에서도 템플릿 에디터 전면 개선, 실시간 통계 서비스, 실시간 검색 이 주요한 것들이었다. 이 목표들은 Blogger의 원대한 야망 — 웹에서의 출판에 대해 새롭게 정의하는 것 — 의 일환이였다(이 포스트를 Medium에서 쓰고 있는건 아이러니라는걸 나도 안다!). 전체 팀이 몇년 안에 Blogger에 큰 가치를 부여할 기능들을 추가하는 것에 집중해야 했고, 두 가지 사실은 명백했다. FTP에 대한 지속적인 투자는 프로덕트를 전진시키는 것을 방해할 것이고, 새로 운 기능들은 레거시 FTP 블로그에서는 작동하지 않을 것이라는 것. 우리가 FTP 유저들을 더 오래 지원할 수록, 새로운 기능 출시는 적어질 것이고, 양분된 고객층을 더 오래 가지게 될 것이였다.

결정이 된 이상, 유저들에게 FTP를 더이상 지원하지 않는다고 알려야 했다. 우리가 어떻게 했고, 무엇을 배웠는지는 다음과 같다.

1. 소통, 소통, 소통하라(communication, communication, communication). 우리는 유저들로부터 신뢰를 쌓기위해 지난 수년간 노력해 왔다. 이런 과감한 결정을 알리기 위해서는 유저들에게 정확히 무슨일이, 일어나고 있고, 그들이 할 수 있는 선택은 무엇이 있는지를 설명할 수 있어야 했다. 우리는 전용 블로그를 만들었고, 코멘트에 대해 최대한 많은 답을 달았다.
교훈: 유저에게 무엇을 하고 있는지, 왜 하고있는지에 대해 알려라. 결정에 대해 동의하지는 않을지 몰라도 그들이 이해하기만 하면 대개는 그 결정을 존중해 준다.

2. 데이터에 대한 자유(Data liberation). 다행히도 Google의 Data Liberation Front 작업으로 인해 Blogger의 데이터를 자유롭게 다운로드 할 수 있는 상황이였고, Blogger의 데이터를 다른 블로그 서비스에서 불러올 수 있게 하는 오픈소스 툴을 제공했다. 유저들이 다른 플랫폼으로의 이전을 최대한 쉽게 할 수 있는 것을 목표로 했고, 몇몇 특수 케이스를 위해 백엔드 작업도 했다(어떤 블로그들은 10년도 넘는 것이였고, 방대한 기록을 가지고 있었다).
교훈: 대안이 존재하다면 유저들을 그 곳으로 안내해라. 설령 경쟁 서비스일지라도

3. 시간(time). FTP 지원 중단에 대한 최초 기한은, 지속적인 운영을 위해서는 FTP 서비스를 새로 만들어야 하는, Google 아키텍쳐 변경에 맞춰져 있었다. 결국은 FTP 서비스 중단에 변경 시점이 맞춰졌다. 더 시간이 필요하다는 유저들의 피드백을 받고, 몇 달을 연장할 수 있었다. 결과적으로 FTP 중단은 최초 공지한 것보다 약 5개월이 더 소요되었다.
교훈: 중단에 대한 공지는 할 수 있는한 최대한 빨리 하라.

4. 전환(transition). 유저들의 믿음을 다시 얻기 위해, 우리는 그들이 계속 Blogger를 사용하기를 원한다는 것을 보여줘야 했다. FTP에서 Blogger 호스팅으로 전환하기 위한 방법을 알려주는 대신, 전환 과정에 필요한 거의 모든 과정을 생략해줄 수 있도록 하는 마이그레이션 툴을 만드는 것에 시간을 투자했다. 마이그레이션이 얼마나 쉬운지를 알려주는 동영상도 제공했다.
교훈: 지원 중단으로 인해 발생할 불편함을 미리 예측하고, 할수 있는 한 줄여라.

5. 지원(support). 마이그레이션 툴로는 해결이 불가능한 특이 케이스들이 발생할 수 있다는 것을 알았다. 지원을 위해 전용 이슈트래커를 만들어, 지원, 개발, PM 팀이 이슈를 쉽게 분류할 수 있도록 하였다.
교훈: 유저들에게 그들의 이슈를 추적할 수 있게 하는 공간을 만들어라. 확장하여(그리고 가능하다면 공개적으로) 그 이슈를 해결하라.

PM으로서, 개발 인력 및 비용을 많이 잡아먹는 기능을 중단하는 것에 힘씀으로써 개발팀으로부터 신뢰와 존중을 받을 수 있었다. 팀에게 무엇을 하고 싶은지에 대해 더 크게 생각할 자유를 줄 수 있었고, 실제로 이룰 수 있는 능력을 줄 수 있었다.

Blogger 팀은 위에 언급된 기능과, 그 이외에도 여러 기능을 만들었다. 개발 속도는 훨씬 빨라졌고, 명확해진 팀 미션은 프로덕트가 어디로 가고 있는지 몰랐던 유저들을 매료시키는 데에 도움을 줬다.

역자 주

- Measure twice, cut once는 목수나 재단사 등 ‘재고 자르는’ 일에서 정확한 측정의 중요성을 강조할 때 쓰는 표현이라고 한다.
- product는 어감을 살리기 위해 프로덕트라고 했다. 상품/제품은 이 맥락에서 어울리지 않는다고 생각했기 때문이다.

--

--