무지가 낳은 괴물, 피쳐 크립
올바른 프로덕트 우선순위 선정하기
투명 인간, 프랑켄슈타인, 지킬 박사와 하이드 등 클래식 호러 무비에 나오는 많은 괴물들은 인간의 욕심으로 탄생했고, 희생되어 왔다. 대체로 스토리는 다음과 같다. 남들이 공감할 수 없는 자기만의 목적을 지닌 미친 과학자가 온갖 기술적인 방법을 동원해 가련한 피조물을 만들어 내고, 이렇게 만들어진 괴물들은 그 끔찍한 모습으로 사회에 받아들여지지 못한 채 슬픈 최후를 맞게 되는 것이다. 그들의 형상이 고전으로 분류되어 오랫동안 인기를 끌었을 만큼 매력적이긴 하지만, 중요한 건 그들이 괴물로 분류된다는 사실이다.
<출처: darkdiscussions.com>슬프게도, 초기 단계의 제품 개발에 몰두하는 스타트업에서도 이와 같은 모습을 관찰할 수 있다. 사용자에 공감하지 못하는 기능을 현실화하기 위해 오로지 제작의 광기에 매몰될 때, 사용자에게 받아들여지지 않는 괴물같은 프로덕트들이 만들어지곤 한다. 바로 피쳐 크립이다.
피쳐 크립(Feature Creep)은 왜 발생할까?
피처 크립은 프로덕트를 개발할 때, 처음에 계획한 범위보다 더 많은 기능을 추가하게 되어 프로덕트의 메인 기능이 모호해지고 거부감을 일으키는 제품이 되는 것을 말한다.
<출처: unsplash.com>이는 사용자의 기능 피로(Feature fatigue)를 유발하고 사용자가 서비스에서 이탈하는 원인이 된다. 실제 사용자들이 원하는 것은 단지 몇 가지 핵심 기능인 경우가 많다. 그럼에도 불구하고 이런저런 경우를 모두 대응할 수 있는 기능들을 욕심껏 붙이다 보면, 쓰지 않는 기능이 많은 거대한 피쳐 크립이 될 수 있다.
무엇이 피쳐 크립을 유발할까? 제작자가 사용자의 정확한 니즈를 파악하지 못하고 공급자 중심 사고에 빠졌을 때 피쳐 크립이 발생하기 쉽다. 그렇다고 무조건적인 사용자 인터뷰가 능사는 아니다. 여기에도 보이지 않는 위험은 숨어있다.
원인 1: 공급자 중심 사고
사용자 리서치나 인터뷰에 기반하지 않은 다양한 의견들이 팀 내에서 발의될 때, 이를 검증하는 프로세스가 없다면 피쳐 크립이 발생하기 쉽다. 가설 과정을 거치지 않은 "~하면 좋을 것 같은데?"식의 막연한 아이디어는 새로운 리서치의 씨앗이 되기에는 바람직할 수 있지만, 곧바로 기능 개발로 진입하는 데는 옳지 않다. 좋은 아이디어가 있다면 먼저 리서치를 통해 니즈를 검증하고, 기능에 대한 가설을 세운 뒤 조심스럽게 기능을 추가하는 것이 안전하다.
원인 2: 사용자 인터뷰에 대한 과도한 신뢰
사용자 인터뷰에서의 응답을 너무 곧이곧대로 믿는 경우에도 피쳐 크립이 발생하기 쉽다. 사용자 인터뷰에서 진행자가 "이런 기능이 있다면 어떨까요?"라는 질문을 한다면, 그 기능이 완전히 엉뚱한 기능이 아닌 이상 대부분의 사람들은 긍정형으로 대답할 것이다. 특히 사람들은 인터뷰의 매끄러운 진행을 위해, 또는 무관심으로 인해, 또는 우호적인 사람으로 보이고 싶은 욕망에서 긍정적으로 대답하는 경향이 있다.
<출처: unsplash.com>아마도 여러분은 이런 실제 니즈와 다른 가짜 연기나 애매한 대답은 인터뷰를 진행하면서 쉽게 분간할 수 있으리라 생각할지도 모르겠다. 하지만 낯선 사람을 대할 때 일어나는 판단 오류를 분석한 말콤 글래드웰의 <타인의 해석>에 따르면, 이러한 연기는 우리가 알아차리기 매우 어렵다. 사람들은 때론 그들의 실제 의사와 관계없이 매우 그럴듯하게 그러한 모습을 연기할 수 있기 때문이다.
이러한 과정이 반복되면, 본래 기획에 포함되지 않았으나 사용자가 원하고 있다고 관찰되기는 했으며, 하지만 실제로는 사람들이 쓰지 않을 가능성이 높은 부가 기능 몇 개가 추가되는 일은 물 흐르듯이 자연스럽게 일어날 수밖에 없다. 특히 우선순위를 정하는 단계에서 사용자의 니즈뿐만 아니라 비즈니스 방향, 기술적 제한을 모두 고려해야 한다.
피쳐 크립의 3가지 해악
개인적인 경험으로는 다음 세 가지가 피쳐 크립으로 인해 발생하는 대표적인 문제였다.
<출처: in.mashable.com>1) 사용성 저하: 피쳐 퍼티그(Feature fatigue)를 유발한다
피처 크립은 제품의 사용성과 사용자 경험의 질을 저하시킨다. 새로운 기능이나 특징이 계속해서 추가되면, 사용자들은 복잡도가 증가한 프로덕트를 더 어렵게 사용해야 한다. 이로 인한 사용자의 고통을 기능 피로, 즉 피쳐 퍼티그라고 부른다.
제품이 광범위한 기능을 제공하는 경우 사용자는 필요한 기능을 찾고 이해하는 데 어려움을 겪게 된다. 또 이로 인해 혼란을 느끼거나, 제품의 복잡성에 압도당하는 느낌이 들 수 있다. 서비스를 효과적으로 탐색하거나 활용하는 데 어려움을 겪는 것이다. 결과적으로 사용자는 좌절하거나 흥미를 잃고, 때론 프로덕트에서 완전히 이탈하기 쉽다.
2) 일정 파괴: 개발과 커뮤니케이션 비용 증가
피처 크립은 프로젝트의 일정과 예산을 초과시키는 문제를 초래한다. 초기에 계획했던 범위를 벗어나 새로운 기능이나 특징이 계속해서 추가되면, 이에 따라 개발에 필요한 시간과 비용이 늘어나게 되므로 일정을 재설정해야 하는 한편 시장에 이를 선보일 수 있는 시점을 더 늦추게 된다.
또한 자주 바뀌는 일정은 팀 내에 불만과 불안을 촉발하기 쉽다. 목표가 계속해서 바뀔 때 발생하는 불안감을 침착하고 논리적으로 안심시킬 수 있는 리더는 많지 않다. 만약 성공적으로 분위기를 만들 수 있다 하더라도, 여기에 들어가는 커뮤니케이션 비용을 계산하지 않을 수 없다. 예정에 없던 갑작스런 기능 추가는 팀을 운영하는 데 드는 각종 비용을 증가시킬 뿐더러 팀원들의 사기를 꺾을 뿐더러 그들의 신뢰를 잃게 될 수도 있다.
3) 개발 복잡성 증가: 버그 발생 가능성 상승, 유지보수 비용 증가
기능 하나를 추가했을 때, 코드의 복잡성은 복리로 붙는다. 한 기능을 작동시키기 위한 코드가 다른 기능을 위한 코드에 영향을 미치기 때문이다. 때문에 이를 구현하고 유지보수하는 작업이 기하급수적으로 늘어날 수 있다. 이는 물론 코드의 복잡성을 증가시키고, 코드 리뷰, 디버깅 등 개발자들의 작업을 어렵게 만든다. 늘어나는 업무량과 그로 인한 스트레스까지도 무형의 비용이 될 수 있다. 이 모든 것이 너무나 막연한 사용자 반응을 위해 희생되어야 한다. 꼭 필요한 기능은 당연히 제작되어야 하겠지만, '있으면 좋을 것 같은' 기능까지 이러한 부담을 감수하는 것은 비효율적이다.
<출처: unsplash.com>앞서 살펴본 세 가지 문제가 대표적이지만, 더 거시적으로 팀 외부의 비즈니스적인 관점에서 그리고 금전적인 문제에서 또한 피쳐 크립은 다양한 문제를 야기할 수 있다. 이것이 섣불리 기능 추가를 결정하기 전에 기능 우선순위를 설정하고 핵심 가치를 명확하게 설정해야 하는 이유다.
무엇이 더 중요한가?
서비스를 개선하고 새로운 기능을 추가할 때 여러 이해관계자들의 의견을 반영하게 된다. 이것은 자연스러운 일이며, 매우 필수적이다. 하지만 서비스의 본래 목적과 기능의 범주를 넘어선 의견은 정제되어야 한다. 이를 위해 사전에 서비스의 근본적인 목적이 무엇인지에 대한 탐구가 우선순위 선정 작업 이전에 이루어져야 하며 이에 대한 공동의 합의도 마무리가 되어 있어야 한다.
<출처: unsplash.com>팀이 서비스하고 있는 기능과 목표에 대한 이해가 불분명하고 두루뭉술할 때, 팀은 올바른 우선순위를 설정할 수 없다. 왜냐하면 모든 기능이 다 중요해 보이기 때문이다.
"어, 이것도 하면 좋겠는데요?"
"다른 앱에선 이런 기능이 있어서 좋던데요?"
"왜 이 기능을 추가하면 안 되죠?"
핑계 없는 무덤이 없다. 하나하나 듣고 보면 물론 이 기능들이 들어가야 하는 너무나도 중요한 이유들이 있다. 그러나 우선순위를 설정하는 작업은 각각을 떼 놓고 중요도를 판단하는 절대평가가 아니다. "무엇이 더 중요한가?"라는 질문은 상대적으로 평가되어야 한다. 이 작업에는 대상을 질적으로 판단하고 평가하는 종합적인 인지 과정이 수반된다.
그러면 대상을 종합적으로 판단하고 평가하는 이 종합적인 인지 활동을 어떻게 하면 실제 실무에 쉽게 적용할 수 있을까? 이를 위해 여러분이 기능 우선순위를 설정할 때 도움이 될지도 모르는 한 가지 질문을 소개해보려고 한다. 저명한 컴퓨터 프로그래머이자 애자일 소프트웨어 개발 운동의 창시자 중 한 명인 워드 커닝햄은 다음과 같은 말을 남겼다. 이는 본래 개발자를 위한 것이지만, 기획자에게도 충분히 작동하리라고 본다.
"작동하게 할 수 있는 가장 단순한 것은 무엇인가?"
<출처: azquotes.com>질문 1) 작동하게 할 수 있는 가장 단순한 것은 무엇인가?
What’s the simplest thing that could possibly work?
작동하게 할 수 있는 가장 단순한 것은 무엇인가?
이는 사실 개발자가 코드를 작성하다 막혔을 때를 위한 질문이지만, 기획에서도 마찬가지로 잘 작동할 것이다. 질문의 요점은 작동하는 것Could possibly work들 중 가장 단순한 것The simplest thing이 무엇인지 찾는 것이다.
이 질문은 단순성과 실용성의 중요성을 강조하고, 팀이 당면한 문제를 효과적으로 해결할 수 있는 가장 간단한 솔루션을 찾길 권장한다.
복잡하고 다양한 솔루션으로 문제를 복잡하게 만드는 대신, 기능 덩어리를 더 작고 컨트롤할 수 있는 조각으로 나누고 개발할 수 있는 가장 간단한 솔루션을 찾는 데 집중하는 것이 좋다. 단순성을 우선시함으로써 우리는 프로덕트의 불필요한 복잡성을 피하고 원하는 결과를 달성할 수 있는 가장 빠른 방법을 찾을 수 있다.
질문 2) 단순한 것들 중 가장 핵심에 가까운 것은 무엇인가?
이 문장을 서비스 기획의 관점으로 이해하는 과정에서, 선언문보다 의문문의 형태일 때 이 문장이 더 명확해짐을 깨달았다. 먼저, 선언문의 형태일 때 이 문장은 다음 두 가지를 강조한다.
1. 기능하는 것
2. 단순한 것
선언문의 형태일 때 WTSTTCPW는 우선순위에 대해 고려할 것을 그저 암시하고 있을 따름이지만, 의문문의 형태일 때는 그래서 그것이 무엇인지 직접적으로 중요도에 따른 순위를 요구한다. 그럼으로써 WTSTTCPW는 좀 더 피부에 와닿는 방식으로 우리에게 다가오는데, 왜냐하면 보통은 무언가를 기획할 때 우선순위를 고려하는 것의 중요성을 많은 기획 또는 디자인 서적에서는 설명하지 않기 때문이다. 왜냐하면 이를 만드는 데 드는 리소스를 기획서들은 고려하지 않기 때문이다. 그보다는 질적으로 좋은 것을 누가 왜 만들었는지에 중점을 두고 이야기한다.
이는 MVP에서만 적용되는 명제가 아니다. 작동하는 가장 단순한 것을 먼저 만들고, 사용자가 이를 외면하거나 환영하는지를 실제 시장에서 관찰한 뒤에 빠르게 고도화하는 것도 좋은 방법이다,
우선순위가 높은 데는 분명한 이유가 있어야 한다
<출처: unsplash.com>기획은 관념적인 영역, 질적인 작업이다. 이를 실체적이고 양적으로 구조화할 수 있게 한다는 점에서, WTSTTCPW는 기획에서 매우 잘 작동한다.
WTSTTCPW는 기능하는 가장 단순한 것들 중 무엇이 가장 효과적인지에 대한 판단을 명확하게 요구함으로써, 이를 실천하려고 하는 기획자에게 우선순위를 고민할 것을 강조한다. 양적으로 구조화한다는 것은 주관적인 선호에 따른 것이 아닌 명제화할 수 있는 조건들을 가지고 동료를 설득할 수 있게 된다. 다음 질문을 고려해서 우선순위를 설계하면 도움이 될 수 있다.
(1) 이 기능은 사용자에게 어떤 편익을 주는가?
(2) 왜 그 편익은 다른 기능이 주는 편익보다 강력한가?
여러분이 좋은 기획자라면 쉽고 정직하게 이 질문들에 대답할 수 있어야 한다. 만약 설득력 있게 답하지 못한다면 그것은 우선순위가 높은 기능이 아닐 것이다. 여러분의 프로덕트에 어떤 기능을 넣고 싶은데 동료들을 설득하는 데 어려움을 겪고 있다면, 시간을 따로 들여서라도 이 질문들에 답하는 시간을 가져 보면 어떨까. 덕지덕지 붙은 군더더기 피쳐들은 깔끔하게 덜어내고 최소 단위의 기능으로 정리할 수 있을 것이다.
사용자의 기능 피로를 만들지 않기 위해, 우리는 UX 디자인에서 단순함이 얼마나 중요한 가치인지를 이해해야 한다. 불필요하거나 거의 사용되지 않는 기능을 제거하여, 사용자 요구에 따라 기능을 신중하게 평가하고 우선 순위를 지정하는 것은 매우 중요하다. 인터페이스를 간소화하고 명확한 지침을 제공할 때, 우리는 사용자의 기능 피로를 완화하고 만족도를 높일 수 있다.
<출처: unsplash.com>마치며.
기능 우선순위를 올바르게 선정하는 능력은 기획자에게 있어 가장 중요한 스킬 중 하나다. 누군가 이를 잘 해낸다면, 그가 다음과 같은 기술을 갖추고 있음을 내포한다.
서비스의 핵심 이해
우리가 제공하는 서비스의 여러 기능 중 무엇이 가장 중요한지 핵심을 이해하고 있다.
근거에 기반한 가설 설정
정성 및 정량 데이터를 토대로 중요도에 따라 개연성 있는 가설을 설정할 수 있다.
다양한 관점 이해
이해관계자 및 팀원들과 소통하며 그들의 다양한 관점을 듣고 전략적으로 목표에 반영할 수 있다.
현실적인 계획 수립
목표를 달성할 수 있는 현실적인 타임라인을 설계하고 구성원을 설득할 수 있는 논리적인 사고가 가능하다.
유연한 사고
불확실성과 모호한 스타트업의 현실 속에서 새로운 정보를 받아들이고 반영할 수 있는 유연함이 있다.
우선순위를 설정하는 작업은 한 가지 행동이지만 이와 같은 많은 능력을 필요하기 때문에 간단하지 않다. 올바른 결정을 할 수 있는 기반이 되는 여러 능력들이 성숙했을 때, 비로소 팀을 올바른 방향으로 나아가게 할 수 있을 것이다.
<출처: unsplash.com>우리가 현실 세계에서 생각해야 할 것은 "1) 현재 조건에서 2) 가장 효율적으로 좋은 것"을 만드는 방법이다. 그리고 현실 세계에서 더 좋은 것을 추구하는 방법은 매우 단계적으로 실현된다. 이 각각의 작은 단계(노드)들을 얼마나 잘 구분하느냐에 따라 기능의 우선순위를 세밀하게 조정할 수 있다. 그렇기에 막연한 아이디어를 만들기보다, 근거에 기반한 가설을 만드려고 노력하는 것이 좋다.
현재 선택할 수 있는 최선의 선택을 기민하고 유연하게 취하자는 것이 애자일이라는 서비스 제작 방법론의 기본 취지다. 프랑켄슈타인 같은 피쳐 크립 대신, 논리적으로 단순하면서 매력적인 기능을 설계하는 것은 어떨까?
