시장에서 성공하는 소프트웨어 변화 방법 - 조직 프로세스 리더쉽 관점


2014년 한 장의 다이어그램을 포함한 글이 IT에 종사자들 사이에서 트위터를 크게 달궜습니다.
San Francisco를 거점으로 일하는 컨설턴트가 올린 트윗인데, 현재까지 2000회이상 리트윗이 되었고, 이에 대한 기사 및 블로그가 다양한 곳에 실렸습니다.

이 트윗의 내용을 살펴보면 S/W가 일반적으로 죽어가는 패턴을 그린 것입니다. 이를 있는 그대로 설명하면 다음과 같습니다.

1) 아무도 제품을 쓰지 않는다
2) 고객에게 부족한 기능이 무엇인지 묻는다
3) 부족한 기능을 만든다
4) 다시 1)로 돌아간다.

이 내용이 어떤 내용을 담기에 많은 사람들이 공감한 것일까요?

필자가 생각하는 가장 큰 이유는 소프트웨어(SW) 회사라면, 위와 같은 패턴이 어디에서나 관찰됩니다.
솔루션으로 승부하는 경우는 더욱 그렇습니다.

과거 흥행에 성공했던 제품이던, 아니면 새로 만들었지만 시장 반응이 싸늘한 제품의 경우 위와 같은 악순환 사이클에 많은 제품이 들어옵니다.

시장의 반응에 민감한 모바일 앱 같은 경우 Retention 비율(다시 사용자가 앱을 찾는 %)이 앱 런칭 후 90일 정도까지 20%가 되기가 어렵다는 것은 일반적인 상식이라고 볼 수 있습니다.

사용자가 제품을 외면하게 되는 패턴이 관찰되는 순간, 제품이 시장에서 사라지게 되는 경우가 대부분인 현실 속에서, 이 Retention이 감소되는 폭을 좁히기 위해, 사용하지 않는 사람들에게 이유를 묻고 그들이 원하는 기능을 추가하는 것은 사실, 지극히 상식적인 접근입니다.

하지만, 기능을 억지로 더 붙이는 일은 대부분 그다지 효과가 없습니다.
사용자가 제품을 사용하게 되는 근본적인 원인은 사용자의 Pain Point를 해결해 주거나 그들의 새로운 니즈를 해결해주기 때문인데, 위와 같은 접근은 기존에 사용했던 사용자에게는 도움을 일부 줄 수 있으나, 새로운 사용자를 끌어들일 전략으로 역부족입니다.
특히나, 특정 사용자 군이 아닌 다양한 사용자들에게 제공하는 일반적인 서비스는 더 어렵습니다.

위와 같은 문제에 대해 기업들은 다양한 전략을 구사하는데 새로운 사용자가 방문할 이유, 또한 사용자가 계속해서 방문할 이유(아래 예제)를 만듭니다.
(ex) Omni-channel experience, App onboarding, In-app messaging, individualization, remarketing 등이 그것입니다.

시작하는 제품에 많은 투자를 한 경우에는 더욱 심각합니다. 특히, 출시 후 사용자의 반응이 싸늘한 경우, 회사는 어려운 결정을 해야 하는 순간이 발생하게 됩니다.
방향을 바꾸든지, 제품을 접든지, 하는 Pivoting을 해야 하는데, 초기 투자가 많아, 제품을 접는 의사결정을 하기 매우 어렵습니다. 이러한 경우 특히 많이 악순환 고리에 진입하게 됩니다.

원하는 수의 사용자를 확보하지 못하니, 유효한 사용자 반응을 얻기 어렵고, 이를 보완하기 위해 일반적으로 세 가지 접근을 하는데,

1) 타 경쟁사 제품을 사용하는 사용자의 경험에 대해 묻고 기능을 추가/보완한다.

2) 경쟁사 기능을 분석하여 추가한다.

3) 신기술 또는 차별화된 기능을 제공한다.

일반적으로 경쟁사를 따라가고픈 열정에, 설익은 기능을 내어 놓게 되고, 이럴 경우 제품 경쟁력으로 연결되지 않는 경우가 많은데, 그 이유는 다음과 같습니다.

1), 2) 의 경우, 사용자들이 현재 사용하는 제품이 어떤 기능을 가졌고 그에 비해 이 제품이 어떻게 못하다라는 피드백을 듣게 되고 이는 부족한 기능을 경쟁사 제품에 맞춰 보완하는 형태가 됩니다.
상대적으로 짧은 시간 안에 구현해야 하기에 자연스럽게 경쟁사의 기능을 그대로 본 떠 만드는 경우가 많기에 보다 나은 기능이 되기 어렵습니다.

또한 경쟁사의 경우 제품을 사용하는 다양한 고객들이 이미 그 기능에 피드백을 주었고, 이를 통해 개선된 형태로 자리 잡고 있기 때문에 당연히 새로 나온 제품 보다 비교우위가 될 수 밖에 없습니다.
그렇다면 결국 3) “신기술 또는 차별화된 기능을 제공한다.” 로 승부를 걸어야 하는데, 이 또한 짧은 기간 안에 결과를 내기 매우 어렵습니다.

이 때문에, 다시 한번 사용자의 싸늘한 반응을 얻게 되고 위의 사이클이 계속해서 반복되는 패턴이 나타납니다.
특히 B2C보다 B2B 제품의 경우 위와 같은 경우가 더 자주 발생하는데, 이유는 고객의 반응을 받기까지 상대적으로 오랜 시간이 걸리기 때문입니다.

이 악순환의 고리에서 나오려면, 일하는 방법의 커다란 변화가 필요한데, 이 변화 중 가장 중요한 것은 많은 기능을 처음부터 만들지 않는 것입니다.
많은 기능에 대해 약속하고 프로젝트를 하는 경우, 방향을 바꾸는 것은 정말 어렵습니다. 최근 시장에서는 시장에 증명되지 않은 기능들이라는 의미로 “Feature Bloat”이라는 용어를 탄생 시켰을 만큼 최초 많은 기능에 투자하는 것을 위 같은 이유로 지양하고 있습니다.

Feature Bloat이 추가된 Product Death Cycle 그림입니다. 1단계 : Feature Bloat, 2단계 : Build it for long time (6-12m), 3단계 : No one uses our product, 4단계 : Ask customers What Features are missing, 5단계 : Build the missing features 입니다. 1단계에서 5단계로 프로세스가 끝나는 것이 아니라, 5단계에서 다시 3단계로 이동하여, 3~5단계가 계속 반복되게 됩니다.  |Feature Bloat이 추가된 Product Death Cycle

반대로 투자를 적게 하면 그 만큼 시장의 반응에 따라 방향을 바꾸기가 쉽습니다. 때문에, 특정 기능이 사용자에게 가치가 있을 것 이라는 가정을 최대한 배제하고, 철저하게 시장의 사용자들에게 기능의 유효성을 검증하는 형태로 디자인 및 개발을 수행해야 합니다.

이를 풀어서 설명하면 다음과 같습니다.

1) 프로젝트가 시작되자마자, 가장 중요한 이해관계자에게 찾아가 그들의 Pain Point와 그들에게 가장 중요한 사용자가 누구인지 묻습니다.

2) 그 사용자를 식별하자마자 직접 사용자들을 만나 그들의 워크플로에 대해 질문하고, 그들이 일할 때 가장 중요하다고 생각하는 워크플로를 듣고 이를 분석하여 해당 시나리오에 대한 것만 아주 간단하게 디자인을 합니다.

3) 가장 짧은 시간 내에 디자인 된 내용을 들고 그를 다시 찾아가 사용해보라고 주면서 피드백을 듣습니다. 이 때 적어도 4~5명의 사용자에게 검증을 받는 것이 중요합니다. (UX Lean Start up의 저자 Laura Klein에 따르면 4~5명의 주요 사용자에게 한 개의 시나리오를 검증 받으면 통계학적으로 95% 수준의 기능을 검증 받을 수 있다고 합니다.

4) 이 피드백을 통해 디자인을 몇 차례 업데이트 합니다.

5) 어느 정도 사용성이 보장되었다는 생각이 들면 개발자에게 부탁하여 가장 빠른 시간 안에 개발하게 하고, 이것이 해당 시나리오만 돌리는데 결함 없이 사용할 만큼이 되는 순간 다시 한번 사용자에게 들고가 사용하게 하고 피드백을 받습니다.

최근 Lean startup, Agile, Design thinking을 함께 쓴다는 회사들은 대부분 위와 같은 형태로 일합니다. 이를 그림으로 표현하면 다음과 같습니다.

Lean startup과 Agile 그리고 Design thinking을 함께 사용하는 개발 방식에 대한 설명입니다. 2일간의 사용자리서치를 통해 사용자의 핵심 사용자 시나리오를 1개 선택합니다. 그리고 8일간의 디자인단계에 들어갑니다. 디자인 단계는 디자인, 사용자에게 확인하는 실제 측정, 학습의 과정을 반복합니다. 디자인 단계가 완료되면 10일간의 개발단계에 들어갑니다. 개발 단계는 개발, 사용자에게 확인하는 측정, 학습의 과정을 반복합니다. 이 단계가 완료 후 검증에 의해 기능이 부족한 경우 디자인단계로 다시 돌아가서 다시 디자인 단계를 반복합니다. 디자인단계도 마찬가지로 검증에 의해 부족한 부분들이 발견될 경우 사용자리서치 단계로 돌아가서 다시 리서치를 진행합니다. | Lean startup + Agile + Design thinking의 개발 방식

독자 여러분 중 여기까지 이야기를 듣고, ‘작은 회사에서는 그렇게 할 수 있지’ 라고 생각하는 분들이 계실 수도 있습니다.
사실, 2011년 정도까지만 해도 위와 같이 일하는 방식이, 스타트업 기업들의 전유물처럼 여겨졌습니다. 엔터프라이즈급 기업들은 위와 같은 일을 할 수 없는 것처럼 여겼었습니다.
하지만 2013년 정도부터 이 스피드의 장점을 대기업에서 취하는 형태들이 나타나기 시작했습니다. 최근 많은 대형 기업들도 위와 같은 형태로 일을 하고 있다. 스타트업 기업과의 차이는 개발 외 많은 조직들이 개발팀을 돕고 있고, 아래와 같은 메커니즘으로 일하고 있습니다.

G사의 실제 사례를 보면, 위의 그림처럼 CEO로 부터 권한을 위임 받은 전사 TF(가칭: Enablement Team)가 회사 내 낭비를 식별하여 제거해주는 역할로 자리 잡고, 개발팀은 이들의 보호 하에 최대한 사용자 피드백을 빨리 반영하는 형태로 일합니다.

전사 조직은 개발팀을 위한 도우미 이지, 간섭하거나 방해하지 않습니다. 더구나 개발팀에서 식별된 이슈, 즉 개발팀이 원활하게 일할 수 없게 만드는 병목(조직 구조, 프로세스, 리더십 측면)들은 전사 TF에게 전달되고, 이들은 회사의 변화 전략을 고려하여 개발 팀에 최우선이 될 의사결정을 합니다. 의사결정 후에는 이를 Enterprise change board를 통해 전체 직원들에게 투명하게 공개합니다.

외의실에서 남자직원 3명과 여자직원 1명이 회의를 하고있는 장면

이러한 변화는 G사 뿐만이 아니라, 디자인 툴의 최강자 A사등 여러 회사에서도 동일하게 관찰되는 혁신의 방식입니다. 이 변화를 통해 두 회사는 계속해서 시장의 강자로 거듭나고 있습니다.

이들의 성공 요소를 돌아보면 가장 중요한 것은 Champion의 결단이었습니다. 위와 같은 의사결정을 하기에는 많은 투자가 필요하기 마련이고, 이 제약조건은 리더들의 결단을 어렵게 합니다.
당연히 성공이 보장되어 있는 것은 아니기 때문입니다. 때문에 많은 회사들이 현재 있는 구조에서 조직을 조금씩 개선하는 형태로 일을 하고 싶어하는데 이들의 접근은 다음과 같습니다.

“우리는 100~300명의 개발자가 한 시스템을 만든다. 엔터프라이즈 급 S/W를 만드는 경우에도 위와 같은 일을 할 수 있는가? “
이 의미를 달리 해석해 보면, 다음과 같습니다.
“현재의 조직구조, 현재의 프로세스, 현재의 리더십 방식을 유지하면서, 위의 변화를 할 수 있는가?”

답은 간단합니다. “No” 다. 현재의 체계에 대해 달리 생각하지 않고서는 위의 변화를 가져오기 어렵습니다. 그렇다면, 조직구조, 프로세스, 리더십을 어떻게 변화해야 할까요?

1) 조직구조

큰 프로젝트라고 한 덩어리의 시스템에 처음부터 수백 명을 투입시기기 보다, 작은 팀으로 시작해서 성장할 수 있는 구조가 되어야 합니다. 물론 비즈니스 영역에 따라 다른 접근이 반드시 필요한 경우도 있습니다.
이렇게 성장하여, 독립적인 의사결정권을 가진 작은 모듈들이 유기적으로 분리되고 공통화 되어 있고, 작은 단위의 팀이 모여 전체 프로젝트 팀을 이룹니다.
적절한 툴 체인과 엮어 직접적으로 사용자의 피드백을 독립적으로 반영할 수 있는 형태로 팀을 이루어야 합니다.

2) 프로세스

일단 프로세스는 Zero base에서 시작해야 합니다.
시간을 두고 필요한 것을 만들어가는 형태로 구성해야 합니다. 이를 위해 우선 일하는 방법을 체득할 수 있는 작은 팀을 만들어야 합니다.

그리고 100~300명 인력이 한번에 프로젝트에 들어가 짧은 시간에 프로젝트를 종료하려고 하기 보다, 작은 팀에 조금씩 조금씩 인력을 추가하며 일하는 방법을 유지/개선하면서 성장시키는 것이 필요합니다. 최근 선진 S/W 업체라는 곳들은 대부분 위와 같은 패턴으로 일하고 있으며, 이 같은 기반 하에 유연한 시스템을 구축하여] 커다란 성과를 얻고 있습니다.
(ex) P사의 C제품을 개발하는 팀 같은 경우 Agile을 중심으로 한 위와 같은 형태로 2.5년만에 30명에서 250명의 대형 팀으로 성장하였습니다.

3) 리더십

가장 필요한 리더십은 적절하게 변화를 위한 권한을 주고, 기다려 주는 것이다. 혁신은 고통이 따르고, 그 고통을 극복 하는 데는 시간이 들기 마련입니다.

작은 조직, 큰 조직 관계 없이 시장의 반응을 제품 성공의 가능성을 높이고, 이를 유지하기 위해 사용과 동시에 가장 빠르게 제품 기능으로 반영할 수 있는 형태로 일하는 방법을 전환하는 것이 반드시 필요합니다.

우리는 조직구조, 프로세스, 리더십 이 세가지에 대해 항상 기억해야합니다.



▶   해당 콘텐츠는 저작권법에 의하여 보호받는 저작물로 기고자에게 저작권이 있습니다.
▶   해당 콘텐츠는 사전 동의없이 2차 가공 및 영리적인 이용을 금하고 있습니다.

공유하기
신황규 그룹장
신황규 그룹장 IT테크놀로지 전문가
삼성SDS 개발실

애자일의 다양한 프랙티스를 통해, 삼성이 보다 좋은 S/W를 개발할 수 있도록 개발문화를 개선하는 일을 하고 있습니다.