brunch

매거진 왜 우리 소프트웨어는 안나와요

라이킷 2 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by Jinho Yoo Oct 06. 2017

그럼에도 불구하고 만들지 않은 것을 팔아야 할 때

위험을 얼마나 감수할지 고민해야 합니다.

앞서 글을 쓴 다음에 제일 많이 받은 피드백은 이런 것이었습니다.

“그런데 없는 물건을 팔아야 하는 경우는 어쩌지요?”

제 답은 “팔지 마세요, 왜 팔아요?” 였습니다. 위험하니까요. 그런데 사업이 뭐 우리 맘대로 되는 경우가 있어야 말이죠.

타협할 순간

최근에 Bitcoin을 가지고 콘텐츠를 소액 결제로 판매하는 서비를 제공하는 Satosipay의 CEO인 Meinhard Benn을 만나볼 일이 있었습니다. 함께 엔지니어답게 기술스택을 이용한 것에 대해 이야기하다가 이런 말을 들었습니다. “물론 고객에게 없는 기능인데도 된다고 하고와서 열심히 구현한 적도 있어”. 아…. 비교적 잘나가는(?) 글로벌 핀테크 스타트업의 현실도 이러했다니 눈물이 앞을 가리더군요. (잠시 껴안고 울고 싶었어요.) 그런데 사실 여러 회사들의 CTO들이나 매니저들 이야기 들어보면 현실상 이럴 수 밖에 없었다는 사람들이 많았습니다. 몇가지 요약하면 이런 상황이었습니다.

1. 고객이 무언지 모르겠다면서 ‘잘 모르겠으니 다 만들고 가져와보세요’라고 말을 한다. 그러나 시간은 없고 낼모레 회사는 망하게 생겼고… 그래서 고객한테 마치 정말 돌아가는 것인양 제품을 애니메이션을 만들어서 보여줬는데 “당장 계약합시다, 얼마면 됩니까”라고 한다. 다행히 CTO한테 이야기 했더니 고객이 필요한 시간안에 될 것 같다 한다, 휴….

2. 고객이 "다 좋은데 이 기능 하나만 새로 하면 딱 우리랑 일할 수 있을 거 같아요. 혹시 가능할까요?"라는 피드백이 왔다. 딱 이번달 돈나가는 거 보니 매출을 안만들면 안되는 상황이다. 내 추정으로 3일 밤낮새서 만들면 될거 같다. “네, 지금 그 기능이 딱 있습니다. 다음 미팅때, 데모를 보여드리겠습니다”라고 말을 던지고 옴. 난 이제 죽었다.

3. 고객들이 서비스를 써보고 ‘이거 ~~~하게 고쳐주면 더 많이 쓸거 같아요’라고 요구사항이 빗발친다. 그런데 내부에서 보니 정말 우리 매출 올릴 아이디어라는 결론이 낫다. 문제는…. 진짜 고객들에게 주면 쓸지 안쓸지 모르겠다. 어쩌지?

그렇죠, 대부분은 목구멍이 포도청인 경우지요. 당장 다음달 직원들 월급주고, 퇴직금 챙겨주고, 사무실 월세내고 뭐 하려면 무조건 돈이 있어야 하는데 아무리 해도 돈나올 구멍은 없고.. 안타깝지만 그게 현실입니다. 혹은 고객들이 정말 원하는 기능이 맞는지 어떤지 누구도 보장할 수 없으니 실증을 해봐야 하는 경우입니다. 그런데 이것도 막무가내로 하면 안됩니다.

만들지 않았는데 있다고 하고 만들지 말지 결정할 수 있는 방법

우선 “된다”라고 말을 하기 전에 우리는 시간을 가져야 합니다. 행동과 결정 사이에 우리는 ‘선택’할 수 있는 자유를 가진 존재거든요. 위험을 감수해야 한다면 이 위험이 얼마나 될지 예산은 해봐야 합니다. 간단한 규칙을 만들어 보면 아래와 같습니다.

def 위험감수_ 여부_결정:
       if 고객에게 줄 남은 시간 > 실제 만드는데 걸릴 시간 + 검증하는데 걸릴 시간 + 여유 시간 then
                “됩니다”라고 말한다.
       else:
                   최대한 실제 가능한 시간에 대한 추정 후 “~~까지 될 수 있습니다”라고 말한다.

문제는 여기서 실제 만드는데 걸리게 될 시간, 검증하는데 걸릴 시간, 여유 시간의 추정을 누가 하느냐일겁니다. 만약 본인이 이미 회사 제품을 설계하고 구현까지 다 하는 사람이라면 이에 대해 직접해도 좋습니다. 하지만 대부분 그렇지 못할 것입니다. 문제는 여기서 생깁니다. “아 내가 대표야, 책임질께!”하는 순간 망하는 겁니다. 이러한 일을 처리하는 기본 원칙들을 알려드리면 다음과 같습니다.

1. 실제 만드는데 걸리게 될 시간, 검증하는데 걸릴 시간, 여유 시간의 추정은 CTO혹은 기술담당 총괄이 해야 하는 것입니다. 경영자나 영업담당자가 해서는 안됩니다.

2. 충분히 전 구성원 (최소한 C level들은 포함해야 합니다) 합의해야 합니다. 누구 하나 반대하면 안됩니다.

3. 실제 이 작업을 하는 구성원들이 집중해서 일하도록 전폭적으로 지원해줘야 합니다. 지적 노동은 긴 덩어리 시간이 필요하다고 이미 피터드러커가 이야기 했었습니다. 긴 시간을 지원해줘야 합니다. 갑자기 미팅에 불려가거나 행사에 끌려가면 안됩니다.

4. 어려운 작업한 사람들을 보상하고 위로해줘야 합니다. 조직 전체를 위해서 희생해서 어려운 일을 한 구성원들에게 박수를 쳐주고 보상(휴가/금전/뭐든간에)해줘야 합니다.

5. 다시는 이런 일을 만들지 않게 경영해야 합니다. 어찌보면 이러한 일들이 회사의 경영상의 실수를 누군가 개고생해서 막은 것입니다. 이런 일이 없도록 제대로 예상가능하게 경영을 해야 합니다.

이도 저도 할 수 없는 경우에는 어떻게 해야 할까요? 사실상 소프트웨어 개발의 추정 자체가 그리 정확하기 매우 힘들다는 이야기를 여러번 했습니다. 그럴 때는 ‘최선을 다한다'라고 밖에는 드릴 말씀이 없네요. 최대한 얼마나 시간이 걸릴지에 대해서 계속 단계별로 노력해서 추정해야 합니다. 적어도 고객에게 ‘~~까지는 될 수 있을 것 같습니다'라는 이야기는 해줘야 합니다. 이 이야기를 해야 당신은 경영자입니다.

그럼 어느 수준으로 제품을 만들어야 하나?

이 때, 문제는 앞서 뱉어 버린 제품을 어느 수준으로 만들것이냐를 결정해야 합니다. 보통 이런 결정을 해야 하는 경우는 보통 실제 완벽한 무언가가 아니라 프로토타입정도만 원하는 경우도 있기 때문입니다. 고객에게 어느정도를 원하는 지를 정확하게 이야기 해야 합니다.

1. 전단지 수준 : '이러이러한 제품이 있다’라고 전단지 수준으로 정리만 되면 됩니다. 보통 이런것이 필요한 경우는 두가지입니다. 첫째, 이러한 제품이 실제 납득이 되는 제품인지 아닌지 보는 겁니다. 앞서 기술했던 Working backward전략입니다. 두번째, 경쟁 회사들을 교란하고자 하는 겁니다. 이른바 수증기 제품 (Vapor ware)전략입니다. 이렇게 하는 목적 자체가 그런 제품을 당장 만들 목적이 아니라 고객의 반응만 살피는 목적이기 때문입니다.

2. 간단한 프로토타입: 화면만 만들어 보여주는 정도만 보여주는 겁니다. 예를 들어 프론트엔드만 가지고 있는 웹페이지를 만드는 거죠.

3. 진짜 제품이 있어야 합니다: 포기하시죠. -.-;; 이건 정공법으로 접근해야 합니다.

경영담당과 영업담당이 긴급성 중독 환자라면?

그런데 이런일이 계속반복된다면? 이것은 긴급성 중독에 경영진이 걸린 것은 아닌지 되돌아봐야 할 것입니다.

긴급성 중독이란, 어떠한 상황을 긴급하고 몰리게 만들고 그 상황에서 나오는 아드레날린을 즐기는 심리적 중독을 말합니다. 이게 무서운 것이 어렵거나 몰리지 않게 할 수 있는 일 조차 급박한 상황으로 부지불식간에 몰아가기 때문입니다. 만약에 이런일이 계속 된다면 경영담당과 영업담당을 해고해야 할 수도 있습니다. 이 습관이 없는 사람들을 경영담당, 영업담당으로 두지 않으면 회사는 매일매일 롤러코스터가 됩니다.