꼬리를 무는 추가 기능 개발: 왜 일어나며 어떻게 대처해야 할까?

원문: Feature Creep: What Causes It & How To Avoid It

꼬리는 무는 추가 기능 개발(Feature creep). Featuritis. Feature bloat. Creeping featurism. Bloatware. 모두 같은 것을 뜻합니다. 

꼬리는 무는 추가 개발은 "소프트웨어 개발에서 끊임 없이 기능을 추가하다 결국 제품이 너무 복잡하고 사용하기 어려지는 경향"을 의미합니다. 

뉴역 타임즈의 데이빗 포그는 그의 유명한 2006년 TED강연을 통해 꼬리는 무는 추가 개발 현상에 사람들의 관심을 끌어모았습니다. 그는 마이크로소프트 워드의 모든 툴바를 활성화하였고, 그러자 정작 워드의 진짜 기능인 문서를 작성하기 위한 공간은 사라지게 되었습니다. 

물론 우리는 소비자를 악의적으로 괴롭히기 위해 이런저런 기능을 마구 추가하는 것은 아닙니다. 하지만 제품에 이런저런 기능을 밀어 넣다 보면 다양한 기능을 그럭저럭 수행하는 소프트웨어가 되면서 원래 목표했던 핵심 기능을 우수하게 수행하는 제품을 개발하는데에는 실패하게 됩니다. 

사람들은 당신이 내놓은 제품이 든든하게 사용할 수 있다면, 몇몇 기능이 없더라도 당신의 제품을 계속 사용합니다. 그러나 버그투성이거나 엉성하게 만든 기능들을 참고 제품을 사용하지는 않습니다. 양보다는 질에 집중하세요. 숙련도가 높아지면 신중하게 선정한 중요 기능을 소비자가 쉽게 사용할 수 있도록 추가해야 합니다. 그러나 한두명의 잠재적 소비자를 위해 성급하게 기능을 추가해선 안됩니다. 

꼭 필요한 기능들은 개발하면서도 꼬리는 무는 추가 개발의 함정을 피하기 위해서는 제품 관리자의(Product Manager) 역할이 매우 중요합니다. 끝없는 추가 개발의 함정을 피하기 위해서는 제품 개발에 관여하는 모든이가(개발부터 마케팅까지) 꼬리는 무는 추가 개발이 무엇인지, 그리고 그 치명적인 결말에 대해 이해하고 있어야 합니다.

이 블로그에서는 다음의 내용을 다룹니다.

• 꼬리는 무는 추가 개발이 왜 나쁜지
• 어떻게 시작되는지
• 추가 기능 요청을 언제 거절해야 하는지 

꼬리는 무는 추가 개발이 왜 나쁜가?

더 많은 문제, 더 큰 비용

기능 추가는 더 많은 회사의 자원을 사용하고, 잠재적인 버그를 내포합니다. 여기서 말하는 자원이란 단순히 해당 기능 개발에 투입되는 자원뿐 아니라, 추가된 기능을 홍보하고 제품 생명주기 동안의 지속적인 지원(개발팀과 고객 지원팀)비용도 포함합니다. "모든 변경점은 개발, 테스트와 꾸준한 개선 작업을 요구합니다." SaaS의 카피라이터 Pawel Grabowski의 말입니다. 추가 투입되는 자원과 지원 소요는 당연히 비용 상승을 의미하고, 해당 기능을 도입하는 최종 비용은 대개 처음 예상했던 비용을 크게 초과하게 됩니다.  

기능 피로 

"과유 불급: 정도를 지나침은 미치지 못함과 같다"라는 사자성어를 들어본 적 있을 겁니다. 기능 피로(Feature fatigue)는 2009년 마케팅 논문에서 나온 신조어로, 너무나 많은 기능이 소비자에게 과유불급으로 오히려 좋지 않은 효과를 내는 현상을 의미합니다. Grabowski는 "지나치게 많은 기능은 초기 구매를 촉진할 수 있지만, 제품 만족도를 낮추고 재구매 확률을 낮추고 결과적으로 고객의 총 LTV를 낮추는 부작용을 낼 수 있습니다."라고 이야기합니다.

사용자 친화성이 떨어짐

제품에 기능이 많으면 대개 복잡한 사용자 경험과 인터페이스가 따라오게 됩니다. 이로 인해 사용자 친화적이지 못하게 되고, 앞서 기능 피로 현상에서 보았듯이 대부분의 사용자는 수많은 기능이 혼재한 제품을 좋아하지 않습니다. 

그런데 모든이가 꼬리를 무는 추가 기능 개발이 나쁘다는 사실에 동의하는데에도 왜 자꾸만 이런 실수가 반복되는 걸까요? 

꼬리는 무는 추가 기능 개발에 돌입하는 원인

다음은 기능 추가 요청을 하는 이유와, 기능 추가 요청이 꼬리에 꼬리를 무는 추가 개발로 이어지는 일반적인 원인들입니다. 

• 진짜로 이번에 만드려는 바로 이 기능이  회사를 유니콘으로 만들어 줄 핵심 기능이라는 믿음 
• 잠재적인 (대형) 고객이 요청해서
• 경쟁사 제품이 가진 기능이라서 
• 이번에 이 기능을 넣지 않으면, 어디선가 이 기능도 가진 경쟁자가 나타나서 불리해질 것이라는 믿음 (위와 유사)
• 상사나 동료가 이 기능을 원해서
• 나중에 이 기능이 도움이 될 것 같아서
• 최신 유행을 반영하고 싶어서, 예를 들어 근래의 소셜 미디어 광란에 탑승하기 위해 추가하는 소셜 기능
• 개발 시간이 짧아서
• 고객이 선택권을 가지면 좋을 것 같아서
• 근래에 신규 기능을 업데이트를 못 했는데, 이번 업데이트에 넣으면 좋을 것 같아서 
• "많은" 고객이 요청해서. 근데 "많은"의 기준이 뭘까?

꼬리는 무는 추가 기능 개발에 돌입하는 이유들을 살펴보았으니, 이제 이를 피하기 위해 가장 중요한 사항을 이야기해 봅시다. 그것은 거부하기 입니다

신규 기능 요청에 응할 때와 거부할 때

기능 요청이 들어왔을 때, 다음의 원칙으로 어떤 기능 개발은 거부할지 판단해 보세요.

  

제품이 사용자에게 주는 진짜 부가가치에 집중하세요 

제품 개발을 시작할 때 보았던 비전과 목적을 기억하세요, "제품의 비전은 개발에 참여하는 모든 사람이 성공적인 제품을 만들도록 이끌어줍니다. 그 이상이 당신이 향하는 목적지이고, 제품 개발을 시작한 이유이기도 합니다. 새로운 아이디어가 나타날 때마다 제품의 이상에 부합하는지 따져보세요." Grabowski의 말입니다. 

"기능과 사용성간 균형을 맞추는 동시에 제품의 진짜 비전을 향한 집중력을 잃어서는 안됩니다." UserVoice의 유저 유입 & 콘텐츠 마케팅 매니저인 Heather McCloskey의 조언입니다.  

 

프로젝트의 우선순위에 집중하세요

앞의 원칙과 유사하지만, 좀 더 거시적인 관점입니다. "달성하기 어려운 큰 목표를 설정하고... 각각의 기능이 그 목표를 이루는 데 도움이 되는지 검토하세요." Lola Travel의 부사장 Ellen Chisa의 조언입니다. 

시간과 자원을 꼼꼼히 따져보세요

출처

"기능을 추가하는 데에 이상적인 테스트 환경에서는 고작 한두 시간 밖에 안 걸릴 수도 있습니다. 하지만 그 기능을 제품에 얹으려면 UI & UX 제작에 디자이너도 필요하고, 테스트 코드도 다 작성해야 제품에 반영할 수 있습니다. 그러다 보면 하루 정도는 쉽게 지나가 버립니다.  그 기능이 정말 그렇게 비용을 들일 가치가 있었을까요? 그럴지도 모르지만, 특정 기능을 추가할 때에는 얼마나 걸릴지 좀 더 현실적으로 생각해야 합니다." Intercom의 공동 창업자인 Des Traynor의 말입니다. 

추가 기능 개발과 가용 자원에 대해서 저희가 좋아하는 격언이 있죠:

"제품 관리의 공통 법칙: 추가 기능 개발 요청은 가용한 개발 자원보다 언제나 더 많다."

데이터를 살펴 보세요

사용 데이터를 뽑아보면 어떤 기능이 가장 많이 사용되고, 어떤 기능이 사용되지 않는지 판단할 수 있습니다. 

출처

유저의 이용률을 높이는 기능은 무엇 일까요?

한편으로 신규 기능의 유용성을 따지기 위해 데이터를 분석할 때에는 조심해야 합니다. Tranor가 그 이유를 설명합니다. 

"데이터를 통해 확실한 이용률 개선이 보이더라도, 이렇게 증가한 이용률이 제품의 진짜 경쟁력을 높이는지에 대해서는 신중히 생각해보아야 합니다. 제품에 테트리스를 추가한다면 이용률이 높아질 겁니다. 하지만, 그게 본 제품의 경쟁력 제고를 의미할까요?"

사용자 의견에 귀를 기울이세요

출처

앞에서 논의했듯이, 고객들이 왜 그러한 기능을 요청하는지 제대로 살펴보는 것이 중요합니다. 내면에 숨어 있는 진짜 문제를 파헤쳐 보세요. "고객들은 때때로 제품의 사용성 문제를 추가 기능 요청으로 제기하기도 합니다." InVision의 Jennifer Aldrich가 말했습니다. 

또한 고객의 필요와 욕구를 구분하는 것도 매우 중요합니다. 

우선 고객의 필요에 집중하고 그다음에 욕구를 살펴보세요. 고객의 필요를 해결하면 대 다수의 욕구는 저절로 사라지게 됩니다." McCloskey의 말입니다.

사용성을 우선적으로 고려하세요  

이 항목은 앞의 내용과 이어집니다. 새 기능이 얼마나 유저 친화적이 될지 정직하게 따져보세요. 고객이 이 기능을 쓰기 위해 얼마나 많은 수고를 들여야 할까요? 고객이 얻는 잠재적 보상보다 수고가 더 크다면 새 기능이 유용하더라도 버려질 가능성이 높습니다.  

현재의 업무 절차에 끼칠 영향을 따져 보세요 

"제품 개발팀에 새로운 업무 절차를 도입하는 건 아주 가끔 있는 일이어야만 합니다. 당신의 시간은 제품을 개선하고, 완성 시키거나 기존의 것을 혁신하는 데에 사용해야 합니다. 프로젝트를 진행하려면 당신은 지금 하고 있는 것이 개선, 완성, 혁신 중 어디에 속하는지 알아야 합니다." 

전체 사업에 끼칠 영향을 생각해 보세요

새 기능은 특히나 수익성을 개선할 것으로 예상될 경우 매력적으로 보입니다. 하지만 조심하세요. 수익성은 물론 중요한 항목이지만, 유일한 고려 대상은 아닙니다. 어떤 기능은 단기 수익을 증대시키는데 그치고, 제품 근원의 경쟁력을 해칠 수 있습니다. 

현재 고객에 끼칠 영향을 파악하세요

때때로 잠재 고객이 새 기능을 요청할 때가 있습니다. 우선 생각할 점은, 특정 고객의 요구가 제품의 전체적 가치에 손상을 끼쳐서는 안된다는 점입니다. 둘째로 잠재적인 새 고객에게 추가 가치를 창출하는 기능이, 기존 고객이 제품을 통해 얻던 가치를 빼앗게 되는 경우도 많습니다. 현재 고객 덕분에 당신이 기업을 유지하고 있다는 사실을 잊으면 안 됩니다.  

단기 수익 vs 장기 가치 

앞서 제가 꼬리는 무는 추가 개발이 발생하는 원인 중 하나로 제시했던 "최신 유행을 쫒고 싶어서"(소셜 미디어 등)이 있었습니다. 이러한 기능 추가의 득실을 저울질할 때 스스로에게 물어보세요. "5년 후에도 우리 제품에 이 기능이 쓸모가 있을까?" 

기능 개발의 범위

"기능을 구체적으로 정의할 수 없다면, 새 기능 개발의 범위가 잘 관리되지 못할 것이라는 신호입니다. 예를 들어 '큰 기업들이 사용할 수 있도록 만들자' 혹은 기능이 '수행할 일'이 아니라 '어떤 보고서'를 만들 목적으로 기능을 개발하는 경우가 있습니다; '판매 관리자가 팀원들의 업무 성과를 볼 수 있도록'하는 기능 따위가그런 경우지요. Traynor의 말에 의하면, 신규 기능의 타당성을 검토할 때에는 솔직하게 그 기능 개발의 범위를 가늠해야 미래의 문제를 예방할 수 있습니다. 

구체적으로 "아니오"라고 거절해야 하는 방법에 대해서는 Intercom에서 쓴 글 "꼬리는 무는 기능 개발을 끊어내기"에 좋은 사례가 있습니다.

기능 삭제를 피하지 마세요

출처

이 주제를 제대로 다루기 위해서는 별개의 글이 필요하지만, 이 글에서는 더 이상 쓸모나 가치가 없는 기능을 제거하는 중요성에 대해서 간략하게 언급하겠습니다.

"꼬리는 무는 추가 기능 개발을 막기 위해 해야 하는 일 들 중 가장 어려운 것은, 이미 만들었지만 실패한 기능을 잘라내는 것입니다." 기업가 Jake Peters의 경험담입니다. 

Groove는 실시간 채팅 기능을 제거하면서 겪었던 어려움을 상세히 블로그로 작성했습니다. "왜 사업을 키우기 위해 우리 제품의 가장 큰 기능을 제거했는가" 이 주제에 대해 더 알고 싶다면 꼭 일독하기를 권장합니다. 

 

정기적으로 제품을 검사하면서 가치 없는 기능을 제거하는 것은, 꼬리는 무는 기능 개발을 막는 방파제가 됩니다. 이미 만든 기능을 제거하는 건 어려운 과정이 될 수 있습니다, 그러한 결정을 내린 이유를 스스로가 이해할 때까지 깊이 생각해 보세요.

결론

제품 관리자의(Product Manager) 가장 어려운 일은 어떤 기능 요청에 응하고, 어떤 기능 요청은 거절할지를 결정하는 일입니다.  "그거 참 좋은 아이디어인데, 안 할께요."라고 말하는 건 쉬운일이 아닙니다. 특히나 상대가 상사나 투자자라면 더더욱 그렇습니다. 하지만 제품의 성공을 위해 제품 관리자가 꼭 해내야만 하는 일입니다.