사용자 반발 없이 기능을 삭제하는 용기
PM의 '언쉽(Unship)' 전략과 데이터 분석
PM이라면 누구나 '내 새끼 같은 기능'을 개발하며 많은 시간과 열정을 쏟습니다. 하지만 제품의 건강을 위해, 자신이 기획했던 기능을 삭제하거나 제거해야 하는 '언쉽(Unship)'의 순간이 반드시 찾아옵니다. 이 순간은 감정적으로 어렵지만, 기능 삭제는 실패가 아닌, 제품의 생존과 성장을 위한 가장 용기 있는 의사결정입니다.
기능 삭제의 역설: '추가'보다 '제거'가 더 중요한 이유
제품에 기능을 추가하는 것은 쉽지만, 제거하는 것은 매우 어렵습니다. 하지만 사용되지 않는 기능은 제품의 군살을 늘리는 '피처 블롯(Feature Bloat)' 현상을 유발합니다. 이 군살들은 제품의 명확성을 해치고, 사용자에게 인지적 부담(Cognitive Load)을 주며, 신규 사용자들의 온보딩을 어렵게 만듭니다.
또한, 사용되지 않는 기능이라도 서버 자원을 소모하고, 개발팀의 유지보수 비용을 발생시키며, 매번 QA(품질 보증)를 거쳐야 하는 기술 부채로 작용합니다. 따라서 PM은 더 나은 기능을 만들기 위해 '무엇을 그만둘 것인가'를 결정하는 냉철함을 가져야 합니다.
냉정한 결정: 삭제의 3가지 데이터 근거
감정적인 애착을 버리고 기능을 삭제하기 위해서는 객관적이고 명확한 데이터가 필요합니다. 이 결정은 다음 세 가지 핵심 데이터에 근거해야 합니다.
첫째, 사용성 지표입니다. 전체 활성 사용자 중 해당 기능을 '단 한 번이라도 사용해 본' 비율과 '주기적으로 재사용하는' 비율을 확인해야 합니다. 만약 이 지표가 특정 기준치(예: 5% 미만)보다 낮다면, 이는 그 기능이 대다수 사용자에게 가치를 제공하지 못한다는 명확한 증거입니다.
둘째, 유지보수 비용 및 기회 비용입니다. 해당 기능을 유지하는 데 드는 개발팀의 시간, 서버 비용, 그리고 버그 수정에 투입되는 QA 공수를 정량적으로 파악해야 합니다. 이 비용을 제거했을 때, 그 리소스를 사용자들이 정말로 필요로 하는 핵심 기능 개발에 투입할 수 있는 '기회 비용'이 삭제의 가장 강력한 근거가 됩니다.
셋째, 간접 지표입니다. 기능 자체가 다른 핵심 지표에 부정적인 영향을 미치는지 확인해야 합니다. 예를 들어, 해당 기능이 앱의 로딩 시간을 늘리거나, 사용자 혼란으로 인해 CS(고객 지원) 문의를 증가시키고 있다면, 이는 삭제의 시급성을 높이는 결정적인 증거가 됩니다.
사용자 반발을 최소화하는 '솔직한 소통' 전략
기능 삭제가 결정되었다면, 사용자 반발을 최소화하는 것이 PM의 마지막 임무입니다. 사용자는 기능이 사라지는 것 자체보다, '내 의견이 무시당했다'고 느낄 때 더 큰 분노를 느낍니다. 따라서 PM은 솔직함과 투명성을 기반으로 소통해야 합니다. 삭제 계획을 최소 2~3주 전에 미리 공지하고, '왜(Why)' 기능을 제거하는지에 대한 명확한 데이터 근거를 제시해야 합니다.
"이 기능은 99%의 사용자에게 외면받고 있었고, 우리는 이 리소스로 여러분이 가장 사랑하는 [핵심 기능]을 2배 더 빠르게 개선하겠습니다"와 같이, 제거의 이유를 '더 나은 미래'와 연결하여 제시해야 합니다. 이러한 투명한 소통은 일시적인 불만을 수반할지라도, 장기적으로는 사용자와의 신뢰를 유지하고, 제품에 대한 PM의 책임감을 증명하는 가장 현명한 전략이 될 것입니다.
