제품과 기능, 성공적으로 종료하는 방법 (中)

본문은 위시켓과 번역가 윌리(Willy)가 함께 만든 해외 콘텐츠 기반 번역문입니다. 코호트 기반 프로그램 회사인 ‘Reforge’의 블로그 글을 번역했습니다. 필진은 믹스패널(Mixpanel) 제품 및 디자인 담당 부사장인 닐 라힐리(Neil Rahilly), 최고 제품 책임자인 케이시 윈터스(Casey Winters), 제품 전략 프로그램 제작자인 파리드 모사바트(Fareed Mosavat), 프로덕트 매니저로 활동하는 키아 파텔(Keya Patel)이 참여했습니다. 본문은 제품과 기능을 종료할 때, 어떻게 종료해야 성공적으로 마무리할 수 있는지에 대한 내용으로 총 3편에 걸쳐 자세히 알아보겠습니다. (1편을 먼저 읽고 오시면 좋습니다.)

언제, 그리고 왜 제품을 종료해야 하는지 알면서도 이를 실천에 옮기는 것이 왜 그렇게 어려울까?

앞에서 '제품 종료가 필요한 8가지 경우'를 통해 살펴봤듯이 종료할 제품이나 기능을 찾아내는 것은 어렵지 않습니다. 하지만 이를 실제로 적용하는 것은 훨씬 복잡합니다. 제품이나 기능을 종료하는 것이 어려운 주된 이유는 다음과 같으며 본 챕터에서 각각에 대해 자세히 다룰 것입니다.

• 인간적인 감정
• 빠른 성장에만 초점을 맞추는 기술 회사
• 기능 종료에 따른 이점과 유지로 인한 비용은 눈에 잘 보이지 않는다
• 인간의 편견

인적요인: 기능에 대한 감정이입

제품이나 기능 개발에 참여했다면 감성이나 향수 등 일종의 인간적인 감정을 그 제품에 투영시키는 경향이 있습니다. 따라서 내가 만든 것을 없애는 것을 쉽게 받아들이지 못합니다. 예를 들어, 해당 기능을 기획하기 위해 1주일을 꼬박 투자한 엔지니어, 잠재 고객과의 통화에서 이 기능을 직접 소개한 영업 사원, 혹은 가족 중 누군가가 이 제품을 정기적으로 사용한다는 등 이 모든 것이 여러분이 느낄 수 있는 제품에 대한 개인적인 감정입니다. 더욱이 이러한 인적요인은 회사의 전략과 불일치하거나 직원들 간 상충하는 보상이 주어질 때 더욱 명확히 드러납니다. 특히, 개발팀은 자신이 만든 기능이 사라지면 조직의 목표 달성이 불가능할 것으로 생각하곤 합니다. 또는, 특정한 추가 기능 판매에 대한 보너스를 받기로 한 영업 사원이 있을 수도 있습니다. 인적요인으로 인해 잘못된 선택을 하고 있다면 잘못된 보상에 기인한 것은 아닌지 의심해 보아야 합니다.

마지막으로, 인적요인은 단지 무시할 수 있는 어리석은 감정으로 치부해서는 안 됩니다. 사람들은 자신이 개발한 기능이 없어지거나 제품을 종료하는 경우 자신의 자리가 위태해지거나 커리어에 오점이 될 것으로 생각할 수도 있습니다. 이러한 두려움을 가지고 되면 사람은 비이성적으로 행동하거나 인적요인에 의존할 가능성이 더욱 커집니다. 또한, 인적요인은 앞에서 언급했듯이 단지 기능을 만들고 판매하고 지원하는 회사 내부의 사람들에게만 적용되는 것이 아닙니다. 제품을 사용하며 다른 사람과 긍정적인 의견을 나눈 경험이 있는 사용자 역사 여기에 해당합니다. 기능의 구체적일수록 일반 사용자에 비해 높은 관심과 참여도를 가진 충성도 높은 사용자 집단일 가능성이 큽니다. 또한, 이러한 파워 유저는 입소문의 근원지가 되어 새로운 사용자를 끌어오거나 그 반대의 영향력을 행사할 수 있습니다.

여러분의 팀이 인적요인의 함정에 빠져있는지 확인하는 방법.

• 기능에 가장 직접적으로 연관된 사람들의 의견을 가장 크게 고려하는 있다 (예: 기능 개발을 주도한 프로덕트 매니저, 고객에게 해당 기능을 가치 제안(Value Proposition)[1]으로 사용하고 있는 마케터)
• 파워 유저의 함정
• 초기 개발 과정과 팀원에 대한 추억을 끄집어내 개인적인 감정을 반영하고 있다
• "만약 우리가 이 기능을 종료한다는 소식을 OO가 듣는다면 어떻게 생각할까요?"라는 걱정을 하고 있다
• 기능 추가와 유지에 대해 인센티브가 부여되는 경우 (예: 영업 팀의 연봉 구조가 특정 기능의 추가와 직접적인 관련이 있음)
• 직원들로부터 개인적인 자리나 공개 석상에서 해고나 고용 안정에 대한 질문을 반복해서 듣고 있다

"분할 납부는 이벤트브라이트(Eventbrite)가 특히 지원하기 어려운 기능이었습니다. 기술 및 운영적인 문제가 혼합되어 있었고, 주로 비싼 페스티벌이나 컨퍼런스 티켓을 구매하는 소비자가 사용했습니다. 우리 회사의 전략은 더 저렴한 티켓 가격의 소규모 모임에 초점을 두는 것이었습니다. 전통적으로 이벤트 제작자에게 높은 가격의 티켓을 판매해왔던 영업팀은 이러한 변화를 달가워하지 않았습니다." - Casey Winters 이벤트브라이트 CPO

인적요인의 함정에서 빠져나오는 방법.

• 분산하기: 한쪽에 치우치지 말고 기능에 대한 모든 정성적, 그리고 정량적 정보를 나열하십시오. 인적요인은 고려해야 할 수많은 부분 중 하나일 뿐입니다. 가장 중요한 순으로 정보에 우선순위를 지정합니다. (예: 제품 전략과의 일치는 인적요인에 우선시되어야 함)
• 북돋워 주기: 기능 종료에 대해 염려하는 사람들을 북돋워 주십시오. 일단 그들이 지금까지 그 기능에 쏟아부은 시간과 노력에 대해 감사와 존중을 표현합니다. 인간에게 가장 귀중한 자산은 시간이며 그들의 시간과 능력을 매우 귀중하게 여기고 있다고 설명합니다. 그리고 기존 제품에 쏟아붓고 있는 시간을 새로운 곳에 투자함으로써 더욱 큰 기회를 잡을 수 있다고 설득하는 것입니다.
• 안심시키기: 제품이나 기능 종료로 인해 직장을 잃거나 해오던 업무의 가치가 절하되는 것이 아니라고 안심시켜줍니다. 이러한 결정이 얼마나 중요하고 회사가 이를 존중하는지 설명합니다. 또한, 커리어의 방향과 안정성에 대해 다시 생각해 볼 수 있는 새로운 기회를 제시해 줍니다.

기술 회사는 즉각적인 매출 증가에 중점을 두지만, 기능을 없애는 것은 장기적인 성장과 도움을 준다

기술 회사, 특히 스타트업은 이익의 증가보다 매출 성장에 중점을 둡니다. 이는 장기적인 관점의 성장은 상대적으로 주목을 받지 못한다는 것을 의미합니다. 때때로 성장이 중요하고 빠른 경쟁 우위를 확보하는 것이 필요하지만, 이는 반대로 기능을 없애는 것이 더 어렵다는 것을 의미합니다. 왜냐하면, 기능의 종료는 단기 성장이나 즉각적인 수익 증가가 아니라 장기적인 성장과 관련이 있기 때문입니다.

여러분의 회사가 단기 성장이라는 함정에 빠져 있는지 확인하는 방법.

• 주간/월간 비즈니스 및 제품 리뷰에서 수익 또는 고객 유치를 위한 단기 전략에 대해서만 이야기하고 있다. 수익성과 장기 계획은 투자자 또는 이사회 수준의 자료에만 포함되고 있다.
• 로드맵은 즉각적이고 계속되는 성장을 장려하는 '빠른 성공'에 대한 지표를 중심으로 만들어진다. 몇 주가 소요되는 기능은 일반적으로 제품 개발에서 우선순위가 밀린다.
• 프로덕트 매니저와 비즈니스 리더는 모든 아이디어에 대해 얼마만큼의 매출을 벌어다 줄 것인지 설명하도록 요구받는다.

"2019년 초, 헤드스페이스의 Conversion 팀은 결제 및 인앱 구매 경험에 대한 빠른 성공에 중점을 두었습니다. 이러한 빠른 A/B 테스트를 통해 조직의 규모를 불릴 수 있었고 고객의 전환율을 지속적으로 높일 수 있었습니다. 하지만 돌이켜 보면, 이러한 빠른 성과 창출에만 집착했기 때문에 그해 말 전체적인 포트폴리오 접근 방식을 도입하기 전까지 제품 결제 기능 중 빼야 하는 부분을 실제로 제거하기 힘들었습니다." - Keya Patel 리포지 OIR (전 헤드스페이스 제품 성장 디렉터)

단기 성장의 함정에서 빠져나오는 방법.

• 장기적인 성장 계획 도출: 회사의 장기적인 성장(2년 이상의 전략)에 대해 논의할 수 있는 자리를 마련합니다. 이는 회사 전체에 공유하거나 로드맵에 대한 검토를 통해 이루어질 수 있습니다. 이를 시작으로, 운영팀은 의식적으로 장기 목표에 따라 성장을 점검할 수 있는 이정표를 세워야 합니다. 매일매일 보기에는 변화가 없는 것처럼 보일 수도 있습니다.
• 매출과 무관한 성과 축하하기: 지속성과 내구성이 주는 가치를 상기시켜주세요. 매출 달성과 무관하며 쉽게 수치화시킬 수 없는 성과에 대해 축하하고 메시지를 공유하십시오. 여기에는 수백 또는 수천 줄의 코드를 줄이는 풀 리퀘스트(Pull request)[2], 다운타임을 줄이기 위한 새로운 공급 업체로의 전환, 월말 이후 1주일이 걸리던 회계 장부 마감 업무를 2 영업일로 줄인 회계팀의 개선 업무 등이 있습니다.
• 포트폴리오 접근 방식: 로드맵 계획 수립 시 '빠른 성공'을 위한 요소와 중장기적인 목표가 같이 어우러져 단계별로 성과 지표를 변경할 수 있을지 확인합니다. 이러한 중장기 목표는 로드맵의 20% 이상을 차지해야 합니다. 포트폴리오 접근 방식을 사용하면 팀이 단순히 빠른 성공에만 몰두하는 것을 방지할 수 있으며, 결과적으로 향후 제거해야 하는 기능을 사전에 방지할 수 있습니다. 마지막으로, 이러한 방식의 지속 가능한 성장을 포함하는 다양한 접근 방식을 경영진이 수용할 것인지 확인해야 합니다.

비용은 오랜 기간에 걸쳐 발생하기 때문에 기능 종료에 따른 이점과 유지로 인한 비용은 눈에 잘 보이지 않는다

기능 종료의 이점은 눈에 잘 보이지 않는다: 어느 정도 규모가 있는 회사는 일반적으로 회사의 목표가 매출과 고객 유치 및 유지라는 성과 지표를 관련이 있습니다. 기능을 종료함으로써 얻는 이점(유지 관리할 코드 감소, 지원 티켓 감소, 이슈 감소, UX 개선, 전략적으로 중요한 부분에 집중, 업무의 분산 방지)은 보통 서서히 그 효과가 나타납니다. 이러한 혜택은 회사가 목표로 하는 성과에 직접적으로 연관시키기 힘듭니다.

기능 유지 비용은 눈에 잘 보이지 않는다: 제품 팀은 개발에 걸릴 시간과 인력 투입을 기준으로 비용을 산정하지만, 이것이 기능에 소요되는 전체 비용은 아닙니다. 여기에는 유지 비용까지 포함되어야 합니다. 기능의 출시하고 유지하기 위해 엔지니어링 팀은 단순히 유지보수뿐만 아니라 기술 및 영업 지원, 마케팅, 문서화, 패키징 및 향후 모든 의사 결정에 관여해야 합니다. 간단히 말해 이러한 복잡성은 걸림돌입니다. 회사에서 각 개인이 하나의 기능에 쏟아붓는 유지 비용을 측정하는 것은 어렵습니다. 이러한 노력과 시간은 잘 기록되지 않으며 하나 이상의 팀에 분산되어 있기 때문입니다.

동전의 양면: 유지 비용은 기능 종료로 인한 이점은 일반적으로 동전의 양면과 같습니다. 기능 종료를 통해 유지 비용을 절감하면 종종 기존에는 몰랐던 이점이 보이기 시작합니다.

유지 비용과 기능 종료의 이점을 보지 못하는 함정에 빠져있는지 확인하는 방법.

• 사내에서 기능 종료가 가져다주는 이점에 대해 논의하거나 표면적으로 언급되는 부분이 없다. 대신, '만약'이라는 질문과 함께 이에 대한 우려의 목소리만 커져간다. (X 고객을 잃는 경우, 언론이 이러한 지원 중단에 대해 부정적인 뉴스를 내보낸다면? 등등)
• 이를 추적하기 위한 성능 및 운영 지표가 경영진 보고서에 전혀 포함되어있지 않다. 예를 들어, 지원 티켓의 수나 이슈 대응 시간에 대한 목표 자체가 존재하지 않는 경우.
• 기술 부채(Technical Debt)[3]와 유지보수에 대한 논의가 개발 및 운영팀 내에서만 이루어지고 있다. 프로덕트 매니저, 디자이너를 포함한 이해 관계자들은 새로운 기능에 대한 리서치를 수행할 때 코드베이스와 개발 라이프라이클에 존재하는 취약점을 인지하지 못하고 있다.
• 만약 기존 레거시 기능을 전혀 고려하지 않아도 된다면 프로덕트 매니저와 개발자는 완전히 다른 방식으로 결정을 내리고 개발할 것이다.
• 개발자 모두가 자잘한 버그를 수정할 걸린 소요시간을 입력하지 않고 있습니다. 엔지니어들이 지원 팀이 받은 기능에 대한 질문을 대신 답해주거나, 매뉴얼 등 문서에 들어가는 기술적인 문구를 검토해 주고 있다.

"이벤트브라이트 엔지니어와 디자이너는 이벤트 생성자가 HTML을 통해 자신만의 디자인을 만들 수 있는 이전 버전을 계속해서 지원해야 했기 때문에 이벤트 목록 페이지에 영향을 미치는 프로젝트를 의도적으로 회피하기 시작했습니다. 이는 우리가 제품의 가장 중요한 영역 중 하나에 대해 개선하지 않고 있다는 것을 의미할 뿐만 아니라, 이 부분이 어떻게 동작하는지에 대한 기술적인 지식을 잃게 된다는 것을 의미합니다." - Casey Winters 이벤트브라이트 CPO

유지 비용과 기능 종료의 이점을 보지 못하는 함정에서 빠져나오는 방법.

• 성능 및 운영 지표 - 이러한 지표는 이미 잘 정립되어 있으며, 매출과 직접적인 관계가 없더라도 이러한 지표의 중요성을 옹호하는 리더가 필요합니다. 또한, 기존 방식으로는 개선되지 않는 유지보수 지표가 있습니다. 예: 마지막 주요 결제 수단 처리 실패 이후 X일, 또는 매일 밤 자동으로 수행되는 테스트에서 오류 발생 후 테스트되지 않은 경로 X.
• 기술 부채에 대한 명확한 이해 - 제품 관리자는 기술 부채 또는 근본적인 성능 향상 개선과 관련된 영역을 이해하기 위해 개발자 회의에 참석해야 합니다. 꼭 이런 자리가 아니더라도 제품 관리와 개발 파트는 새로운 개발 항목에 대해서만 논의하는 것이 아니라 정기적이고 의도적으로 기술 부채 및 유지관리 비용을 표면화시키고 해결하려 노력해야 합니다.
• 유지 비용 문서화하기 - 기능 유지보수와 관련된 사람을 식별하는 빠르게 나열해 보세요. 그리고 한 주, 혹은 한 달간 개인별로 해당 기능에 얼마나 많은 시간을 투자하는지 물어봅니다. 특정 기능에 대해 팀 구성원 전체가 투자한 시간을 측정하면 얼마나 많은 컨텍스트 스위칭(Context Switching)[4]이 발생하고 있는지 파악할 수 있고 관련된 활동 간 우선순위를 지정하는 것이 수월해집니다.

인간의 편견은 합리적인 사고를 방해한다

우리는 편견으로 인해 현상을 유지하고, 매몰비용(Sunk Cost)[5]과 손실을 회피하는 방향으로 움직이는 경향이 있습니다. 따라서 기능을 종료해야 하는 타당한 이유가 있음에도 불구하고 우리가 가진 편견에 의해 이러한 근거에 반하는 논리를 만들어냅니다.

• 현상 유지는 기능 제거로 인한 워크플로우의 변경이나 예측 불가능한 상황을 방지하기 위해 기능을 현재 상태로 그대로 유지하는 것입니다.
• 매몰 비용을 회피한다는 것은 이미 기능에 들어간 시간, 고민, 에너지로 인해 기능을 계속 유지하는 것을 의미합니다. 기능을 종료해야 한다는 점을 인정하는 순간 기존에 투자가 실패했다는 것과 비용이 그대로 매몰된 다는 것을 의미한다고 믿기 때문입니다.
• 손실 회피는 동일한 양의 이익과 손실이 있을 때 손실을 회피하는 선택을 한다는 것입니다. 간단히 말해서, 이것은 길거리에 떨어진 5만원짜리 지폐를 찾는 것보다 지금 손에 쥔 5만 원을 잃지 않는 것을 선호한다는 것입니다. 제품팀은 있던 기능이 사라지는 것을 원하지 않습니다. 기능 종료에 대한 부정적인 인식이 새로운 기능을 탐색할 수 있는 기회보다 앞서는 것이 보통입니다.

여러분의 팀이 편견의 함정에 빠져 있는지 확인하는 방법.

• 팀은 변화를 성장과 학습의 기회로 받아들이지 않고, 비생산적이며 귀찮은 것으로 치부하고 있다.
• 기능과 관련하여 팀은 새로운 시각으로 바라보는 대신 "이건 항상 그래 왔으니까" 또는 "이게 우리가 항상 해오던 방식"과 같은 문구를 자주 사용한다.
• 현시점의 기회비용을 고려하는 대신 팀이 지금까지 기능에 투입한 노력이 무엇이었는지에 집착하고 있다.
• 팀 구성원들이 처음부터 깊게 관여되어 있었기 때문에 기능에 대해 무엇을 개선할 수 있는지, 초기 배포에서 어떤 실수가 있었는지 말로 표현하기가 힘들어하고 있다.
• 긍정적인 결과를 얻지 못한 기능 실험은 성공한 실험에서 얻은 것과 동일한 학습의 기회로 여겨지지 않고 실패로써 묻어버리고 지나간다.

편견이라는 함정에서 빠져나오는 방법.

• 초심자의 마인드: 현실에 안주하지 편견 없는 목소리를 듣기 위해 신입 사원에게 기능을 소개하고 피드백을 받아보세요. 또는, 해당 기능에 관여하고 있는 누군가에게 만약 자신이 제품의 책임자라면 지금에서 무엇을 바꿀지 물어보세요. 각 기능이 고객과 비즈니스에 미치는 중요도를 새로운 관점에서 바라볼 수 있습니다.
• 기회비용: 특정 기능을 종료할 경우 새롭게 확보되는 리소스와 기회가 무엇인지 전부 나열해 봅니다. 또한, 손실에 대비하여 팀이 얻을 수 있는 선택지에 대해 고려해 봅니다.
• 승진 기회 부여: 직원이 편견에 맞서 기능 종료를 수행할 수 있는 환경을 조성하십시오. 이러한 분위기를 조성할 수 있는 한 가지 방법은 경력 발전의 기회를 제공하는 것입니다. 일반적으로 회사가 추구하는 신념에 부합하고, 안주하지 않으며, 기능 종료를 수행하기 위해 업무를 객관적으로 바라볼 수 있는 직원을 골라 승진시킵니다.

"저희는 최근에 기능 중단을 담당한 프로덕트 매니저를 승진시켰습니다. 그가 한 일이 가치가 있다는 것을 회사 전체에 보여주는 것이 중요했습니다. 회사 내부의 모두가 반대를 외쳐 추진하기 어려웠음에도 불구하고 해냈을 뿐만 아니라, 이러한 기능 종료 자체가 큰 이득을 가져다주었기 때문입니다. 그가 해낸 기능 종료는 새로운 기능의 추가만큼이나 인정받을만한 가치가 있었습니다." - Neil Rahilly 믹스패널 제품 및 디자인 부사장

[1] 소비자들의 욕구를 만족시키기 위해 고객들에게 회사가 전달하기로 약속한 가치 또는 이익과 혜택들의 집합.

[2] 분산 버전 컨트롤 시스템의 기능 중 하나로 자신이 변경한 부분을 소스 코드베이스에 반영(병합)하기 위해 보내는 요청.

[3] 현시점에서 더 오래 소요될 수 있는 더 나은 접근방식을 사용하는 대신 쉬운(제한된) 솔루션을 채택함으로써 발생하는 추가적인 재작업의 비용을 반영하는 소프트웨어 개발의 한 관점.

[4] 한 가지 업무를 하는 도중 다른 요청사항이 발생하여 다른 업무로 주의를 옮겨가는 행동.

[5] 이미 지출해서 회수할 수 없는 비용을 말한다.