스타트업을 창업 하려는 분에게 하고 싶은 말(Feat. 전 스타트업 CTO)
최종 수정일 2020-01-26
이 글은 연쇄 창업자들을 위한 글이 아니고 특정 상황에 놓여있는 사람에게만 제한되는 글입니다.
극히 개인적인 생각과 의견이며 정답이 아님을 먼저 말씀드립니다.
필자는 경험이 많지 않고 부족하지만, 스타트업의 CTO로 4년을 지냈으며, 새로운 도전을 앞두고 있는 사람입니다.
스타트업의 CTO로 있었으면서 여러 사람을 만나다 보니 아쉬웠던 점이 많았었습니다.
그리고 새로이 창업을 하려고 하는, 경험이 부족한 젊은 친구들이 고려했으면 좋겠다는 부분이며
겪지 않으면 좋겠다는 마음으로 글을 작성했습니다.
이미 스타트업 창업에 대한 조언하는 좋은 글들은 많으니 CTO의 관점에서 다른 포인트로 접근하여 얘기해보고 싶었습니다.
글을 읽기에 그나마 적합한 사람을 작성해봤습니다.
- 연쇄 창업자가 아닌 자
- 처음으로 창업을 하려고 하는 자
- 소프트웨어로 서비스를 제공하려고 하는 자
- 학생 창업자
그 외의 분들에게는 괴리감이 있을 수도 있고 해당도 안될 수 있습니다.
무턱대고 사람을 뽑지 않는다
경험이 조금 부족한 창업자가 쉽게 생각하는 부분입니다. 사람과 관련하여 세 가지를 얘기하고 싶습니다.
첫 번째는 창업자는 일단 가급적 '혼자서' 비즈니스 모델을 만들고 운영할 수 있도록 도전하고 노력해야 한다.
두 번째는 스타트업은 사람이 재산이다.
세 번째는 동료를 데려온다는 것은 그 동료뿐 만 아니라 부양하는 가정에 대해 생각해봐야 한다.라는 이야기입니다.
창업자는 일단 가급적 '혼자서' 비즈니스 모델을 만들고 운영할 수 있도록 도전하고 노력해야 한다
사업부터 시작할 때 팀부터 세팅하고 시작하는 분들이 있습니다. 비즈니스에 대한 계획과 인력에 대한 운용 계획이 스스로 완벽하고 확실하다고 생각하더라도 좀 더 생각하고 주의해야 할 부분입니다.
물론 비즈니스를 운용하기 위한 각 파트별로 인원(예시로 마케팅, 기획, 영업, 디자인 등)을 모아놓고 사업을 시작하면 좋은 점도 분명 있을 수 있습니다만 문제가 생기는 부분이 있습니다.
최초에 사업을 시작하고 각자 땅! 하고 움직이기 쉽지 않습니다. 각자 해야 하는 롤에 대해 충분히 숙지가 되어있지 않을 수 있습니다.
학생 때 단순히 동아리처럼 생각하고 창업하면서 생기는 문제인데, '내가 영업할 테니 넌 기획해라, 넌 디자인해라, 넌 마케팅해라' 이런 식으로 롤을 간단히 정해버리고 시작하기 쉽습니다. 그렇게 되면 서비스의 프로토타입이 만들어지기 전까지 황당한 경우가 많습니다.
아직 잘될지 안될지도 모를뿐더러 실제로 모든 파트의 인력 구성이 그 시기에 필요 없을 수도 있습니다.
예시로 소프트웨어 서비스라면 소프트웨어 프로토타입이 만들어지기까지 각자 할 수 있는 일이 그렇게 많지 않습니다. 실제로 서비스를 운영하면서 성장하면서 바빠지고 그에 따른 필요 인력 구성이 정해지지, 처음부터 필요하지 않습니다. 잉여인력이 발생합니다. 또한 롤에 대해 애매함을 느끼는 팀원은 뭘 해야 할지도 모르며, 혼자서 생각하다가 나가거나 창업자의 자본만 까먹게 됩니다. 그리고 프로토타입이 잘 안됬을 경우는 더 큰 문제입니다. 즉 시장이 없다고 판단할 경우 초반에 믿고 모인 여러 사람에게도 민폐입니다.
좋은 방법은 일단 대표 '혼자서' 비즈니스 모델을 신중히 고민해보며, 문제를 겪고 있는 고객을 더 많이 만나는 것이 좋습니다. 그리고 핵심문제를 해결 함으로써 비즈니스 모델이 운용 가능하다는 가능성이 판단되면 그때 움직여도 됩니다.
프로토타입을 외주로 맞기는 건 개인적으로 꺼림칙 하지만, 핵심 기능만 구체적으로 기획해서 들어가면 큰 문제는 없습니다. 정 불안하다면 프로토 타입을 만들어줄 수 있는 엔지니어를 데려오는 것은 나쁘지 않습니다. 저는 개인적으로 프로토타입을 만드는 단계에서도 굳이 디자이너나, 마케팅, 기획, 인사, 재무 다 필요 없다고 생각합니다. 영업하고 고객 만나고 기획하고 디자인 신경 쓰고, 재무 신경 쓰고, 마케팅하는 대표와 엔지니어 하나면 족한 것 같습니다. 그렇게 프로토 타입을 먼저 만드는 것이 낫습니다. 고객과 만나며 생각하고 깨달은 것들을 엔지니어와 함께 프로토타입을 구현합니다. 디자인? 처음에 투박해도 됩니다. 완벽하지 않아도 됩니다. 그게 프로토 타입이니까요. 핵심 문제만 해결할 수 있으면 됩니다.
스타트업은 사람이 재산이다
창업이나 사업을 취미로 할 정도로 부유한 사람이 아니고서는 어느 사람이든 기업이든 리소스는 항상 부족합니다. 한정된 리소스 안에서 기업을 운영해야 하는 것은 숙명입니다. 스타트업에서 초반에 가장 비용이 많이 드는 부분은 제조업이 아니라면 인건비입니다.
운 좋게 정부지원을 받아서 창업을 하더라도, 대부분의 정부 지원금의 자금운용계획에 인건비는 들어갈 수 없습니다. 대부분 마케팅 비용이나 연구개발비로 쓸 수 있습니다.(증빙 가능한) 그러므로 인건비로 운용할 수 있는 돈은, 창업자의 자본 + 영업수익이 최대입니다. 물론 운이 좋다면 투자도 받을 수 있겠지만 확률은 낮다고 볼 수 있습니다. (카이스트 박사 3명 모인 거 아니고서야.. 초반부터 투자는 일반적으로 힘듦..)
그러므로 창업자 입장에선 인건비를 정말 효율적으로 사용해야 합니다. 그러다 보니 적은 돈으로 일당백 하는 사람(가성비 좋은)을 찾게 되긴 합니다.. 비용보다 더 중요한 건, 창업자가 가려고 하는 비전에 동의해야 하며, '핏'이 맞는 사람이어야 합니다. 사실 비용보다 이 문제가 가장 중요합니다. 소위 말하는 '핏'은 굉장히 추상적이고 설명하기 어렵습니다.
'핏'을 단순하게 얘기해보면, 창업자가 부족한 부분을 채워주며, 창업자와 같은 비전을 공유하고 힘차게 나아갈 힘이 있으며 능력도 출중하고 겸손하고 창업자의 수족이므로 손과 발 같은 사람이면 됩니다. 이런 사람을 어떻게 모셔 오냐는 것은 글을 작성하는 필자도 힘들고 어렵고 모르기에 넘어가겠습니다. 찾는 것부터가 인복과 운이 많이 작용합니다.
그리고 리소스 부족으로 인해 여러 사람을 뽑기 힘들기 때문에, 한 사람의 능력치가 굉장히 중요합니다. 한 사람의 능력치로 회사가 좌지우지될 수 있습니다. 회사의 성장에 크게 기여하는 것도 사람입니다. 그러므로 사람이 재산입니다.
동료를 데려온다는 것은 그 동료뿐 만 아니라 부양하는 가정에 대해 생각해봐야 한다
동료를 모집하고 데려오는 것은 단순히 법적인 문제를 떠나 도의적인 문제도 발생합니다. 누군가를 부양해야 할 책임이 없는 사람이거나, 젊은 친구들은 크게 문제가 안될 수 있으나. 동료가 집안의 가장이던가, 동료가 부양해야할 가족들이 있는 경우는 동료에게 돈을 지급하는 것은 그 가정에도 영향을 미치기 때문입니다.
스타트업의 현금흐름이 원활하고 재무계획이 정상적으로 작동한다면 문제는 없습니다만 만약에 월급을 못주던가 밀리던가 하는 상황이 오면 동료뿐만 아니라 동료가 부양하는 가정에도 영향을 미치게 됩니다. 혹시나 그 부분까지 신경 쓸 필요 없다 라고 생각한다면 경기도 오산입니다.(그런 분이시라면 밑에 글을 읽을 필요가 없습니다.)
만약에 핵심 멤버이며, 놓치고 싶지 않은 동료이나 현실적인 문제로 계속해서 불안하게 만든다면 떠날 수밖에 없기 때문입니다. 현실적인 문제는 현실적입니다. 한 번 생각해보시길 바랍니다. 애 딸린 가장이 월급을 못 가져가는 상황이 오면 어떻게 행동할까요. 어떤 생각을 할까요.
시니어급들은 부양하는 가정이 있을 가능성이 높습니다. 대표라면 좀 더 신중할 필요가 있습니다.
핵심문제에 집중하지 않으면 개발 비용이 기하급수적으로 증가한다
소프트웨어를 이용하여 서비스를 하려는 스타트업에서 개발 비용이란? 크게 2가지로 나뉠 수 있습니다. 신규 기능 개발 + 유지 보수 = 개발 비용입니다. 신규 기능 개발은 아시다시피 새로운 기능을 개발하는 시간적 비용부터 테스트 후 릴리즈까지 들어가는 비용을 뜻합니다.
개발자 출신의 창업자이면 개발비용에 대해서 말할 필요도 없지만, 비 개발자 출신의 창업자이면 대략적으로만 알고 있지 모를 가능성이 높습니다.
이것, 저것 넣으면 더 잘될 것 같다.
흔히들 하는 착각은 이것, 저것 넣으면 더 잘될 것 같다 라고 생각하는 부분입니다. 정말 진심 착각입니다.
머릿속에서 결과물이 완벽히 구체화되지 않은 채, 타 서비스를 벤치마킹하며 이것도 넣고 저것도 넣다가는 본질에서 벗어나 산으로 갑니다.
산으로 가는 만큼 핵심 문제에서 벗어난 개발을 계속하게 됩니다. 이건 프로토 타입 개발뿐만 아니라 이후에 개발할 때도 마찬가지입니다.
예시로 핵심 문제에만 쏟아부어서 개발한다고 했을 때 약 2주 걸린다고 가정해봅니다. 핵심문제 외 것을 지적하고 추가하여 개발하다 보면 2주가 아니라 3~4주가 걸립니다. 단순히 비용으로 생각해보면, 인건비의 반으로 해결할 문제를 그 이상으로 더 주면서 해결해야 하는 문제가 발생합니다. 어떻게 보면 오버 엔지니어링 일 수 있습니다.
기능이 많아질수록 프로그램 복잡도와 개발 시간은 더 증가한다
비개발자 출신의 대표들이 정말로 잘 모르는 부분이 있습니다. 여타 다른 직무, 마케팅, 디자인, 기획, 영업과 다르게
개발 업무 자체가 일이 기하급수적으로 누적된다는 부분입니다.
여타 다른 직무는 어떤 한 프로젝트 또는 한 단락이 끝나면 '와 끝났다, 고생 많았습니다.'라고 하고 다른 새로운 업무를 할 수 있지만, 개발이라는 직무는 어제 만들었던 코드 또는 프로젝트를 기반으로 그 위에 새로운 기능을 쌓아 나아가야 합니다. 레거시 코드는 '어제 코딩했던 코드'다.라는 말이 있습니다. 그리고 프로젝트의 복잡도는 한 층 더 올라갑니다. 그 위에 또 새로운 기능을 만들고 계속해서 만들고 또 만듭니다.
감이 안 오시는 분들을 위해서 예시를 들겠습니다.
인간이라는 것도 시스템적으로 돌아가는 유기물이라고 볼 수 있습니다. 인간은 계속해서 살아있는 상태입니다.
살아 있는 상태에서 개복하는 것도 쉽지 않습니다. 고려해야 할 것이 많아집니다.
인간에게 새로운 기능을 접목시키기 위해 수술대에 올려놓고 개복합니다.
새로운 기능은 '위장 근처에 센서를 달아 위에 남아있는 물질이 있는지 없는지 확인할 수 있는 기능'을 만드는 겁니다.
개복하는 순간부터 정신 바짝 차려야 합니다. 잘못 수술했다가는 과출혈 또는 비정상 동작으로 죽을 수 있습니다.
인간이란 시스템은 유기적으로 작동하기 때문에 한 혈관을 건들면 다른 혈관에 영향을 미칠 수 있습니다. 또한 새로운 기능을 넣을 경우 다른 장기에 예상치 못한 영향을 줄 수 있으므로 미리 시뮬레이션하고 확인합니다.
새로운 기능을 넣습니다. 무사히 봉합합니다.
그리고 이 인간은 새로운 기능을 가진 인간으로 다른 사람이 수술할 때 참고하도록 문서로 남겨놓습니다.
또 다른 새로운 기능은 위장에 적절한 위산을 무작위적으로 생성하는 기능을 만들 예정입니다.
일단 해당 인간에 대해 파악하기 위해 Chart를 보고 확인합니다.
Chart에는 저번에 만든 '위장 근처에 센서를 달아 위에 남아있는 물질이 있는지 없는지 확인할 수 있는 기능' 이 포함되어 있습니다.
이번엔 고려해야 할 것이 있습니다. 위산을 무작위적으로 생성할 경우, 저번에 만든 기능이 의도하지 않게 오작동할 가능성이 높기 때문입니다.
남아있는 물질이 있는지 없는지 확인하는 것을 의도는 했으나 위산을 체크하는 것을 원하지 않았기 때문입니다.
아침 점심 저녁으로 위산이 나오는 것은 고려하여 저번에 개발되었으나, 무작위적으로 위산을 생성하면 위산을 음식으로 오해하여 남아있는 물질이 존재한다고 시그널을 보낼 수 있기 때문입니다.
골치 아파졌습니다. 새로운 기능을 넣기 위해 이전의 기능을 고려하고 건드려야 하는 상황이 발생할 수도 있기 때문입니다.
그래도 어떻게든 새로운 기능을 욱여넣고 봉합했습니다.
인간이란 시스템의 복잡도는 더 심해졌습니다. 다음에 개복하여 새로운 기능을 넣을 때는 더 많은 것들을 고려해야 하는 상황입니다.
기능이 많아질수록 신경 쓸 것이 많아지고 정리해야 한다. 그러므로 정리하는 시간이 더 들어간다.
소프트웨어 엔지니어를 고용해본 적 있는 사람은 무조건 한번 이상은 듣게 되는 말이 있습니다. 그 이름하여.
한 번도 들어보지 않은 사람 있어도, 한 번밖에 안 들어 본 사람은 없다는 단어입니다.
리팩터링이란 단어는 서칭 하면 다 나오므로 여기에서는 '왜? 필요하지'라는 부분에 대해서 공감시키기 위해 예시로 설명하려고 합니다.
리팩터링은 현실세계의 이사와 비슷하다고 볼 수 있습니다. 다만 전제조건이 있는 이사입니다.
30평짜리 집에서 17평짜리 집으로 이사 가야 하는 상황입니다.
이유는 월세(유지비용)이며 30평짜리 집보다 17평짜리 집이 상대적으로 더 저렴하기 때문입니다.
30평짜리 집에서 17평짜리로 이사 가려면 버려야 하는 짐이 많습니다. 짐들을 넣을 수 있는 규모가 축소되기 때문에 필요 없는 건 무조건 버리고 가야 합니다.아니면 집이 쓰레기장이 되겠지요. 또한 다 가지고 갈 수 있다고 가정해봅시다.
일단 좁은 집에 짐들을 욱여넣습니다. 그렇게 이사를 완료했습니다.
어느 날 필요한 짐(기존에 있던 기능)이 생겼습니다.
이전에 이사할 때 창고에다가 아무렇게 욱여넣었습니다.
찾으려면 앞에 있던 짐들을 다 뺀 후 꺼낼 수 있습니다.
결국 창고에 있는 짐을 다 빼고 나서야 원하는 짐을 찾을 수 있었습니다.
새로운 짐(새로운 기능)을 넣어야 하는 상황이 생겼습니다.
일단 창고는 무작위로 짐을 욱여넣었기 때문에, 더 이상 넣을 공간이 없어 보입니다.
그러나 좀 정리하면 짐을 넣을 수 있을 것 같습니다.
일단 창고의 짐을 다 뺍니다. 그리고 차곡차곡 종류별로 묶어서 정리합니다.
1년 이내 사용하지 않은 짐(Legacy)들은 버립니다. 그리고 새로운 짐을 넣습니다.
다음에는 짐을 찾을 때나 새로운 짐을 넣을 때 큰 무리가 없을 것 같습니다.
안드로이드, iOS 애플리케이션을 운영 도중 기능이 추가되면 파편화와 호환성 문제가 발생한다.
소프트웨어를 가지고 서비스하는 기업은 필연적으로 새로운 기능이 계속해서 추가될 수밖에 없습니다.
이 문제는 앞으로도 창업자 분도 이해하고 겪어 나아가야 할 부분입니다. 여기서 말하는 파편화라는 것은 운영체제 버전별 파편화, 웹을 운영한다면 브라우저 별 파편화, 디바이스 별 파편화를 얘기하는 것이 아니라, 애플리케이션 레벨 단의 버전별 파편화를 뜻합니다.
단순한 예시로 안드로이드 애플리케이션을 들겠습니다.
식당을 예약하는 소프트웨어를 개발하여 플레이 스토어에 출시를 했습니다.
최초의 기능은 예약기능만 존재합니다.
이때 버전은 '1'입니다.
'1' 버전을 다운로드 한 고객이 1,000명이 되었습니다.
예약할 시 푸시 메시지를 받을 수 있는 새로운 기능을 넣었습니다.
이때 버전은 '2'입니다.
'2' 버전을 다운로드 한 고객이 500명이 되었습니다.
실제로 사용자는 '1'버전 1,000명과 '2'버전 500명이 되었습니다.
1,000명은 예약 시 푸시 메시지를 받을 수 없습니다.
500명은 예약 시 푸쉬 메세지를 받을 수 있습니다.
푸쉬 메세지를 받으면 답변을 보낼 수 있는 새로운 기능을 넣었습니다.
이때 버전은 '3'입니다.
'3' 버전을 다운로드 한 고객이 2,000명이 되었습니다.
실제로 사용자는 '1'버전 1,000명과, '2'버전 500명 '3'버전 2,000명입니다.
이런 부분을 애플리케이션 레벨 단의 버전별 파편화라고 합니다.
이 부분이 무엇이 문제냐고 할 수 있지만, CS 부분에서도 대응해야 하는 문제가 생길 수 있고(뭐가 안된다.), 엔지니어링 관점에서도 세 가지의 버전을 대응해야 하는 복잡도 문제도 발생합니다. 새로운 버전이 아닌 이전 버전의 소프트웨어가 잘 운영되기 위해 호환성도 신경 써야 합니다.
그만큼 유지해야 하는 코드의 양도 많아질뿐더러, 엔지니어링 비용도 증가합니다.
기능이 많아지면 유지해야 할 엔지니어의 숫자도 증가한다.
여태까지 신규 개발에 집중해서 얘기했으나 유지 비용도 비용이라는 부분을 얘기하고 싶었습니다.
기능이 많아지고 유통 채널이 많아질수록 그에 대응하는 엔지니어의 수도 많아져야 합니다. 이건 물리적인 부분입니다.
만약에
프런트(웹), 백엔드(Server, Infra, DB)만 운영할 때와
프런트(안드로이드, iOS, Window, 웹), 백엔드(Server, Infra, DB)만 운영할 때와
인력 구성과 숫자도 다릅니다. 각각에 맞는 엔지니어가 필요합니다.
도메인(특정 산업군 또는 특정 단위를 뜻함, Domain Name을 얘기하는 것이 아님.) 별로 엔지니어들을 배치하고 운영해야 할 수도 있으며
그에 따라 엔지니어의 수도 증가하게 됩니다.
트래픽이나 서비스 규모 그리고 서비스 아키텍처에 따라 필요한 엔지니어의 수도 달라집니다.
이로 인해 엔지니어의 수도 증가하게 됩니다.
단순한 수치로 예시를 들어보겠습니다.
엔지니어 수를 코드 10만 줄 당 한 명씩 담당하게 하는 소프트웨어 회사가 있다고 가정해봅시다. (실제로 그렇진 않습니다.)
해당 회사의 A 소프트웨어의 코드가 40만 줄이 넘어갑니다. 한 사람당 10만 줄을 물리적으로 담당할 수 있다고 하면
40만 줄 / 10만 줄 = 4명이 필요합니다.
새로운 기능을 추가하면 20만 줄이 추가될 예정입니다.
총 60만 줄이 되어 6명의 엔지니어가 필요하게 됩니다.
다만 안타까운 건 엔지니어를 늘린다고 개발 속도나 퍼포먼스가 비례적으로 나오는 것은 아닙니다.
개발부터 생각하지 말고, 가능하다면 기존의 솔루션을 이용하라.
경험 부족하신 창업자분들은 자신만의 자산, 소프트웨어를 가지길 원하는 성향이 있습니다. 그러나 그 욕심과 성향은 잠시 접어둡니다.
정말 필수적으로 엔지니어가 필요한 상황이 아니고서는 다른 대체 방법이 있는지 찾아봐야 합니다.
예를 들어 일반적인 커머스를 하고 싶으면, 홈페이지를 제공해주는 여러 플랫폼 또는 솔루션, 툴이 많습니다. 유명한 카페24나, 네이버 스토어, 워드프레스, 윅스, XE 등 많습니다. 또는 예약시스템을 이용하고 싶으면 네이버 예약 뿐만 아니라 구글링에 예약 솔루션 치면 나오는 것들이 많습니다.
물론 여러 비즈니스를 대응하기 위한 템플릿형 솔루션들은 보편적인 문제를 해결하기 위해 만들어졌기 때문에 창업자분의 비즈니스에 최적화되어있지는 않을 수 있습니다.
최적화 되어있지 않고 조금 부족하더라도 고객의 문제를 파악하고 해결할 수 있다면 솔루션을 이용하는 것을 추천합니다. 굳이 고도의 엔지니어링이 필요하지 않습니다.
고객의 니즈를 먼저 확인하기 위해 솔루션을 통해 랜딩페이지를 만들어서 확인하는 방법도 있습니다.
확실히 세상 많이 편해지고 좋아졌습니다.
진짜 비즈니스를 하고 싶은 것이라면, '꼭 필요한 것일까?'라는 의문을 항상 가지고 생각하시길 바랍니다.
남에게 보이기 식으로 비즈니스를 하지 않길 바라겠습니다.
자기 혼자만의 생각일 뿐이다 가정하고 측정하고 평가하라
'측정하지 않는 것은 계속해서 찜찜하고 발목을 잡을 것이다'라고 말씀드리고 싶습니다.
여러 스타트업 창업책에 무엇을 측정하고, 어떻게 측정할지는 충분히 나와있으므로, 여기서 얘기를 꺼내진 않습니다.
(CPA, CTR, LTV, CVR, DAU, WAU, MAU, 거래액, 재구매율 등..)
다만 CTO로써 있었던 사람으로서 엔지니어링과 관련된 얘기를 해보고 싶습니다.
위에 앞서 얘기했듯이 기능이 많이 추가되면 그에 따른 개발비용이 기하급수적으로 늘어납니다.
필요한 기능이라면 넣는 것이 맞지만 그렇지 않은 경우에 대해서도 생각을 해봐야 합니다.
'이 기능을 넣으면 좋을 것 같다.'라는 얘기를 할 수 있습니다. 아, 물론 다 넣으면 좋습니다. 좋겠지요.
하지만 실제로 고객이 잘 사용하지 않을 수도 있고, 필요가 없었던 기능일 수도 있습니다.
창업자는 개발비용을 줄이기 위해 몇 가지 원칙이 있어야 합니다.
물론 능력 있는 CTO 또는 엔지니어가 존재한다면 조언을 잘해줄 가능성이 높습니다만 창업자도 원칙을 가지고 있어야 합니다.
예시로
'월간 이용자 중 1%도 사용하지 않는 기능이라면 제거한다.'
'새로운 기능을 넣으면 고객이 좋아할 것 같다. 그러나 고객은 다를 수 있다. 생각이 아니라 A/B 테스트를 통해 실제로 확인한다.'
'내비게이션 도구를 넣는 것에 있어서 왼쪽 상단에 햄버거 메뉴가 편할지, 하단 탭 바 형식으로 넣는 것이 편할지'
'측정 후 신뢰구간이 95%를 넘어가면 새로운 기능 적용, 넘어가지 않는다면 롤백'
창업자나 팀원들은 직관을 가지고 여러 아이디어를 던질 수 있습니다.
이 아이디어가 개발이 필요한 아이디어라면 더 많이 가정하고 측정하고 엄밀하게 평가해야 합니다.
평가하기 위한 로그분석 또는 A/B 테스트 관련 도구가 많습니다. 그건 구글링 검색해도 잘 나오니 얘기를 꺼내진 않겠습니다.
왜? 가정하고 측정하고 평가해야 하나?
아이디어는 누구나 던질 수 있으나 만드는 건 디자이너나 개발자이기 때문입니다.
'새로운 기능을 적용 후, 잘 안되면 말고' 할 단순한 문제가 아닙니다.
위에도 얘기했듯이 엔지니어링 관점에서 기능이 추가되면 개발비용이 기하급수적으로 늘어나기 때문입니다.
그건 개발자가 부담해야 할 것이 아니라 창업자 또는 임원들이 부담해야 합니다. 사람을 뽑고 교육하는 시간, 그리고 이후의 개발 시간을 더 많이 투자해야 하니까요.
그래서 결론적으로 하고 싶은 말이 있습니다.
'무엇을 추가하려고 하지 말고 무엇을 덜어낼지 생각하라'
'정말로 필요한 기능인지 다시 한번 또 한번 우선순위를 정하고 고민해봐라'
계속...