스타트업, 그렇게 실패한다.
스타트업은 대부분 실패한다. 성공신화보다는 실패사례를 수집하라.
스타트업을 모든 기업의 시작점이라고 정의해보자.
원대한 꿈과 멋진 비전을 가지고 시작한 스타트업이지만, 스타트업의 수명은 정말 짧고, 분명 그 끝은 빠르게 다가온다. 슬프고 미안하지만, 그 꿈의 대부분은 비극이다.
한여름밤의 악몽처럼 스타트업은 그렇게 실패로 마무리 된다.100개의 스타트업이 시작되면 99개의 스타트업은 대부분 비극으로 끝이나고. 한두개의 기업만이 살아남을 뿐이다. 아이디어, 멤버, 자본이 충분했지만, 주변 여건과 사회적인 운으로도 망할 수 있다. 기업이란 원래 그렇다.
다 갖추고 있어도 실패할 수 있다. 반대로, 한가지 이유때문에도 성공한다.
하지만, 그 성공의 이유는 그냥 운일뿐, 실패를 줄여가는 것이 최선일 뿐이다.
창업자는 다만 꿈을 키워 기업의 형태로 만드는 것에 집중해야 한다. 그래야, 악몽에서 빠져나올 수 있다. 실패에 좌절하지 않고, 다시 도전할 수 있다.
정말 성공했다고 평가받으려면, 시장에서 서비스와 제품이 소비될 때에 스타트업은 '성공'했다고 이야기할 수 있을 것이다. '성공'에 대한 이야기를 듣고 싶으면 다른 곳에서 듣도록 하자, 여기서는 제대로 꽃을 피우지도 못하고 씨앗 상태에서 발아하지 못하는 것을 '실패'라고 정의하고, 그런 스타트업의 '실패'에 대해서 이야기할 것이다.
스타트업을 시작하는 사람들은 대부분 '성공신화'의 정보를 수집하느라 바쁘다. 하지만, 실제 성공한 사람들의 이유들을 100가지 나열해봐야, 따라 할 수 없는 것들이 대부분이다.
재벌 2,3세가 아니라서 어렵고, 서울대, MIT, 스탠포드를 다니지 못했기 때문에 따라 하기 어렵다. 심지어, 미국에서 시작한 것도 아니며, 시대 적인 배경도 다르다. 그래서, '성공'만 수집하는 것은 대부분 '실패'로 달려가는 지름길을 찾고 있는 것이라고 이야기하겠다. 타인의 성공 스토리는 들어봐야 쓸모없다.
성공에 왕도나 공식은 없다. 성공의 요인에서 99가지를 완벽하게 갖추었지만, 단 한 개의 요소가 빠져서도 실패할 수 있다.
스타트업을 시작한 사람들은 타인의 ‘성공’에 대한 ‘신화’를 듣기보다는, ‘실패사례’를 꾸준하게 수집해야 한다. 그나마 수집된 ‘실패’를 내가 다시 경험하지 않도록 하는 것이 그나마 최선이다. '실패'에 대한 경험을 바탕으로 '성공'하기 위해서 조금이라도 변수를 줄여 나갈 수 있다.
창업은 쉽다!
창업을 하기는 쉽다. 하지만, 성공하기란 정말 어렵다. 그냥 대부분 실패한다. 많은 사람들이 성공하는 방법들에 대해서 이야기를 한다고 하지만, 대부분 가짜들이다. 정말 성공에 대한 중요한 요소는 그들 자신도 설명하지 못하는 경우가 대부분이다. 그러니, 그들의 성공 스토리는 그들만의 이야기라고 인식하기 바란다.
성공사례는 그 사람이기 때문에, 그 사람의 아이디어이기 때문에 성공한 경우도 많다. 그래서, 대부분의 잘못된 사례들은 그대로 뭉개고 가는 경향이 많을 뿐이다.
참신한 아이디어에서 출발한다?
스타트업의 핵심을 ‘참신한 아이디어’라고 착각하는 사람들이 많다. 단언컨데 아니다.
다만, 정말 중요한 것은 그렇게 생각한 아이디어가 최소한 ‘나에게 만이라도’ 필요한 것이냐고 반문하는 것이다. 그리고, 나라면 그 ‘아이디어’를 ‘돈’을 주고 살 가치가 있냐고 확인하는 것이다.
정말 필요한 가치가 있거나, 최소한 아름답고, 매력적인 요소가 있다면, 그것을 위해서 고객들은 ‘구매의사’를 보일 것이고, 그것은 곳 비즈니스 모델이 성립한다는 것을 의미한다. ‘기업’은 아이디어를 ‘실현’하는 곳이라고 생각하기보다는, ‘팔릴만한 제품’이나 ‘서비스’를 만들어 파는 곳이라고 생각을 해야 한다. 정말로, 비즈니스 모델이라는 의미를 아는 것을 떠나서, ‘팔릴 만한 제품’이나 ‘구매 의미가 있는 소프트웨어’를 만들고 있는가? 그것을 가장 먼저 생각해야 한다.
아이러니하지만, 그렇다고, ‘제품’에 있는 그런 가치에만 집중한다고 모든 비즈니스 모델이 성립하는 것은 또 아니다. 실제 제품이나 서비스는 실제 구현되고 제조되어진 상태로 시장에서 고객들에게 평가를 받을 수 있어야만, 제대로 된 가치를 인정받는다.
아무리 참신한 아이디어라도 ‘팔릴만한 제품’과는 꼭, 필요충분 요건은 아니라는 것이다. 재미있는 아이디어를 가지고 놀거나 대화를 하는 행위가 완전하게 비효율적인 것은 아니지만, 너무 그 ‘참신함’에만 매달려서는 문제를 제대로 인식하는 것이 아니다.
그리고, 그러한 아이디어가 시장과 가치가 모두 있어도 그냥 성공하는 것이 아니다. 그 아이디어를 실현하도록 모인 팀원들이 그 아이디어와 가치를 어떻게 생각하느냐가 또 하나의 중요한 요소가 된다.
고집을 피우지 않으면 망한다
창업자가 새로운 비즈니스 모델에 대한 아이디어를 가진 사람의 생각을 팀원에게 전파하는 것은 정말 어렵다.
한편으로는 그러한 시도를 한다는 것 자체가 무모한 짓이다. 그래서, 대부분의 리더들은 자신의 동료에게는 의견 통일을 구하지만, 직원에게는 전달하는 것에 집중하는지도 모른다. ( 모든 리더들은 자기가 스티브 잡스가 된것 처럼 착각하는 경우가 많다. 웃긴다. )
뭐, 정말로 그러한 아이디어나 모델을 자신의 팀원에게 설명하는 것이 가능할 수도 있을지 모른다. 그렇지만, 필자는 여기서 조언을 하고 싶다. 창업자의 생각과 열정을 팀원들이 그대로 받아들여서 일을 해주었으면 하는 바람은 저 멀리 던져버리라고.
필자가 과거에 벤처기업을 창업하고 운영할 때에 많은 개발자들과 동료들을 모아서 진행해 보았지만 대부분 실패했다. 스타트업의 리더는 초기에 아이디어를 구상하고 기획하고, 투자자를 끌어모으고, 업무를 진두지휘하는 것만으로 충분하지 않았나 한다.
오히려, 기업 내부의 교육이나 철학적인 부분까지 너무도 많은 것을 내재화하려 애를 쓴 것이 오히려 독이 되었다는 점이다. 자칫 잘못하면 골목대장 놀이가 될 뿐이고, 이 시간과 비용들이 이런 시간으로 무참하게 낭비되는 경우를 빈번하게 경험했으며, 지금 이시간에도 수많은 스타트업 리더들의 '삽질'에서 느낄 수 있다.
물론, 스타트업의 '창업자'는 외롭고 힘들다. 그리고, 가장 큰 문제는 ‘창업자’가 너무 힘들다는 것이다.
초기의 불안전한 아이디어나 모델들을 다른 사람들의 아이디어를 사용해서 보완한다는 것 자체가 무모한 도전을 하고 있다는 것을 잊지 말자. 원래, 그런 자리다. 외롭고 힘들고, 두려운 것이 정답이다. 끝없는 마인드 컨트롤이 아니면 버티기 어려운 자리다. 매우 당연하다. 그렇지만, 그러한 고민과 어려움을 직원들과 나누려 하지 마라.
돈 몇푼 받고 일하는 직원들은 그런 리더를 우습게 여길 뿐이다. ( 돈을 많이 받아도 똑같다. 직원은 직원일 뿐이다. )
아이디어를 실현하는 고민은 창업자와 리더의 머릿속에서 완성되어야 한다. 그것을 팀원이 도움을 주어서 완성된 형태로 만들것이라고 착각을 기반으로 한 계획을 세우지 않기를 권한다.
당신의 불완전한 아이디어를 듣는 직원들은 자신의 생각과 자신의 시선으로 아이디어를 다시 해석할 뿐이다. 같은 단어를 서로 이야기한다고 하지만, 서로 따른 이야기를 하고 있다는 것이다. 정말, 혁신적인 아이디어라면 직원은 그 단어를 잘 이해못하는 것이 매우 당연하다.
어떤 아이디어나, 기획이 혁신적이지 않다면, 창업해야 할 의미가 없는 것이고, 그 아이디어들은 생각보다 단순한 바탕에서 보통 출발하는 것이 대부분이다. 보통, 그 아이디어와 기획에 대해서 듣는 대부분의 반응은 ‘그 아이디어가 팔리겠어?’라는 반응일 것이다. 이때에 직원들은 그냥, 이해가 가지 않아도 그냥 넘어간다. 슬프지만, 사실이다.
그래서, 불완전한 아이디어를 직원들과 만들다 보면, 대부분 이상한 '물건'이 나의 의사와 상관없이 나왔다고 푸념하고, 직원들을 원망하고 있는 자신을 발견하고 있을 것이다. 슬퍼하지 말라. 당신의 아이디어가 원래 불완전했기 때문에 그런것 뿐이다.
중간 정리를 하자면, 남의 이야기와 아이디어를 나의 아이디어와 합한다는 것은 정말로 어려운 일이다. 컨설팅을 수년이상을 해도 그런 행위는 정말 어려운 것이다. 설명하기 어려운 것만큼 고집을 피우지 않는다면 일은 성립하기 어렵다는 것을 잊어버리면 안 된다. 정말 만들고 싶은 것은 '고집'을 피우고, 원하는 것을 만들기 위해서 자신이 처음과 끝을 마무리 해야 한다.
엔지니어가 아니라면 최소한 서비스의 형태는 자신이 원하는 형태로 동작하는지 테스트는 해야 한다.
기업 내부를 치열하게 만들면 망한다
성공한 기업의 특징은 비즈니스 모델에서 얻어지는 이익이 야박하지 않다는 점이다. 특히, IT업체의 특징 중의 하나는 ‘이익’이 큰 것이다. 냉정하게 이익이 많지 않은 일을 창업했다면, 그 비즈니스는 잘해도 그 모양일 것이다.
‘이익’이 크기 때문에, 잘되는 IT기업의 특징은 일정상 느슨한 구조를 가지게 된다. 그리고, 잉여를 존중하거나 기회를 많이 제공하게 된다. 한편으로는 이런 기업의 특징은 머리가 좋거나 아이디어가 충만한 사람들에게는 부드러운 직장생활이 되는 반면에, 능력이 부족하면 매우 괴로운 기업문화가 된다. 기업 내부를 창의적인 집단으로 만들려면 ‘부드럽게’ 만들고 ‘재미있게’ 만들어야 한다.
하지만, 대부분의 기업은 정해진 시장과 정해진 제품과 기능만을 만족하면 팔리는 적절한 투자에 적합한 기능들로 충분한 경우가 많다. 정말, 큰 시장을 노리고 있다면, 기업 내부를 치열하게 만들면 안 된다. 그러면, 망하는 조건을 하나 더 추가한 것이다.
기회는 또다시 온다고 믿는 것
어떤 기회나 도전, 열정, 사람과의 인연 등을 보면, ‘아깝다’라는 기분이나 기회가 많이 만나게 된다. 비슷한 기회는 다시는 돌아오지 않는다. 그 순간이 끝인 경우가 대부분이다.
이런 기회를 잡는다는 것 자체가 대단한 실력이고 대단한 운에 해당한다.
정말, 기회는 다시 오지 않는다. 대부분 실패한 사람들은 그러한 '기회'를 제대로 잡지 못한 경우가 태반이다. 아니, 그런 '기회'가 온지도 모르고 지나가는 경우도 많다. 보통, 그러한 기회를 제대로 파악하기 위해서 '시각화'하고 '도표'화한다.
물론, 모든 것을 정량적으로 수치화한다고 모든 것이 보이는 것은 아니다. 하지만, 최소한의 것이라도 정량적으로 평가하지 않는다면, 최소한의 기회의 시점도 찾기 어려워진다.
이는, 기업의 회계나, 소프트웨어 개발의 시각화 모두에 해당한다. 모든 것이 수치화시킨다고 하더라고, 정성적인 평가나 경험적인 평가가 결합하지 않으면, 그런 '수치'도 무의미하다고 하겠다.
최소한의 수치화도 안된다면, 최소한의 기회도 찾기 어렵다.
양보는 방향성을 상실하게 한다.
소프트웨어 개발에 있어서 ‘법’과 같은 절대적인 방법론이 존재한다면, 아마도. 누가 해야 할 것인가에 대해서는 고민하지 않을 것이다. 하지만, 소프트웨어 개발에 있어서 그러한 ‘법칙’은 없다.
냉정하게 이야기하자면, 누군가가 편해지만, 누군가는 불편해지고 일이 많아진다. 그렇다면, 일이 많아지는 곳의 논리가 명확해지고, 그 인사평가도 명확해진다면 그러한 일은 줄어들까?
업무를 결정하는 사소한 다툼과 방향성은 그 기업과 팀, 조직의 탄성과 관성을 만들어내는 원동력이 되기도 한다.
문제는, 이러한 협의의 과정에서 만들어진 결과물들은 퇴적층처럼 쌓여서, 그 기업의 문화로 발전되게 된다. 업무의 협의의 과정은 ‘이번에 내가 양보했으니, 다음번에는 당신이 양보하면 되겠네’라는 발상이 통용되지 않는다.
대부분의 업무협의과정은 한번 양보한 사람이 계속 양보하게 되어있고, 한번 이기면 계속 이기는 것이 보편적인 현상이다. 이러한 것은 ‘실력’의 문제 이전에, 작업의 우선순위 결정에 있어서의 탄성력이 발생한 것이다.
어떤 방식으로 결정되고, 사소한 업무라도 개시해서, 작업 결과물이 축적되는 것과 같은 작업과 업무의 선택 방법이 회사의 ‘체계’로 굳어지게 되는 것이다.
그래서, 보통 초반부터 기선제압을 하고 주도권을 잡으려 애쓰는 것이 보편타당할 것이다. 하지만, 이러한 결정이 올바른 방향으로 간다면 다행이겠지만. 대부분은 그 퇴적층처럼 쌓이는 결정권의 방향성 때문에 기업의 수명이 제한되는 것이 보통이다.
누군가는 분명 양보를 했다.
그래서, 그 업무는 누군가에게 집중된다.
보통은 그 업무나 요구사항의 ‘해결책’을 제시하는 팀이나 사람에게 그 업무는 전이되게 된다. 내 업무 중에 ‘자동화’되거나, ‘시스템’이 자동적으로 해결되는 일과, 고객과 개발되는 서비스와의 연관성에 있어서, ‘고품질’로 운용이 되고 있다면, 그 업무를 분명 대신해주고 있는 협상은 ‘대가’를 받아야 한다.
‘툰드라의 늑대’ 이야기가 그 좋은 예가 될 수 있다.
영국 에든버러대 교수이자 협상 전문가인 게빈 케네디가 이야기한 ‘튼 드라의 늑대’ 이야기는 양보의 역효과에 대해서 설명한다.
오래전 유럽 세일즈맨들이 툰드라 지역의 원주민 마을을 찾아갔다.
그들은 원주민에게 냉장고와 맥주 같은 문명의 이기를 팔고, 사냥 방법을 배우면서 가까워졌다. 그런데 바로 그 "사냥"이 문제의 시작이었다. 한 세일즈맨이 사슴 사냥에 성공한 뒤 썰매를 타고 돌아오던 중 멀리서 늑대 한 마리가 쫓아오는 것을 느꼈다.
위험을 직감하고 미친 듯이 도망치던 그는 더는 안 되겠다 싶어 사냥한 고기를 조금 떼어 던져줬다. 다행히 늑대가 쫓아오지 않아 한숨 돌리려던 순간, 이제는 서너 마리의 늑대가 쫓아오는 것이 보였다. 생각할 겨를도 없이 또 고기를 던져줬다. 이때부터 불행의 반복이었다. 어느덧 수십 마리가 그를 뒤쫓았고, 남아 있는 고기는 없었다.
그 순간 마을에 도착해 다행히 늑대로부터 목숨은 건질 수 있고, 이 일을 전해 들은 다른 세일즈맨들은 그 지역을 돌 때마다 여분의 고기를 갖고 다니다가 늑대가 위협해오면 던져줬다. 하지만 거기까지였다.
어느 날 원주민들이 그들을 내쫓은 것이다.
“배고픈 늑대에게 썰매를 따라가라고 가르친 멍청한 놈들! 당장 꺼져!”
이들이 쫓겨난 이유는 늑대에게 베푼 "선의의 양보" 때문이다. 양보가 결코 미덕이 아니라는 뜻이다. 하지만 양측 모두 무작정 버티면서 시간만 끌 수는 없는 법. 양보할 수밖에 없는 상황이라면 다음 같은 사항을 명심해야 한다.
"만약"이라는 말을 반드시 붙여라. “만약 내가 그 조건을 양보한다면 당신은 나에게 뭘 양보해줄 수 있나요?”
이 말은 "내가 먼저 양보할 테니 당신도 양보해달라"는 것과 다르다.
"당신이 내 마음에 드는 양보를 한다면 나도 똑같이 양보할 뜻이 있음"을 밝히는 것이다.
이렇게 자신의 양보가 절대 "공짜"가 아님을 알려라. 나의 양보를 가치 있게 만드는 것이 가장 중요하다.
아직도 꽉 막힌 협상을 푸는 방법은 양보라고 생각하는가. 자신의 상대는 툰드라의 늑대와 다르다고 믿는가.
그렇다면 이렇게 물어보자. 당신의 상대가 당신에게 "대가 없는" 양보를 한다면 당신도 그에게 그만큼의 양보를 해줄 것 같은가.
-- 주간동아 ‘803호’에 실린 칼럼 중에서... 세계경영연구원의 IGM 비즈니스 리뷰 중에서.
양보는 하되, 그에 걸맞은 ‘대가’에 대해서 상대방에게 인지하게 하는 것이 기술이며, 처세술의 기본이다. 어떤 요구사항이나 업무에 대해서 협의가 발생하게 되면, 그 ‘대가’를 상대방에게 지불하게 하는 방법을 같이 구사하여야 한다.
소프트웨어 개발에 있어서의 ‘정치’라는 것은, 단순화한 파워게임이나 자존심 대결이 아니라, 실용적인 개발방향을 정하는 것이라는 점이다. 문제는 ‘내가 이해하지 못한다고, 상대방의 이야기를 듣지 않는 경우가 발생하는 것이 가장 큰 문제이다’. 이런 방법으로 ‘양보’를 얻어낸다는 것은 결국, 소프트웨어의 미래를 포기하게 하는 것인지도 모른다.
어떤 협의 이후에, ‘편하고 좋은 환경’에서 개발일을 하게 된다는 것은, 그에 상응하는 ‘비효율적이고, 불편하고, 어려운 개발’ 일을 누군가가 대신하고 있다는 것을 잊으면 안 된다.
편하고 효율적인 개발환경은 분명하게도 이러한 ‘정치’적인 선택과 혜택을 제공받았기 때문인지도 모른다. 하지만, 이러한 상황은 비 개발자와 개발자 사이에서도 빈번하게 발생되는 문제들이다.
하루에 끝날 일을 3개월 넘게 말싸움을 할 수도 있다. 그것은, ‘자리’를 만들기 때문이다.
전문가의 권위는 추락했지만, 그 능력은 인정하자
인쇄 성경판이 구텐베르크에 의해 실현되고, 성직자의 권위가 떨어진 현상과 대응되는 것. 전문가의 권위, 전문가의 지식을 꼭 따라야 하는가?
어떤 식당에서 밥을 먹을지 선택하는 것을 유명한 음식 평론가의 평판이나 의견에 따라서 움직이는 것보다, 사용자들의 평점에 따라서 추천순위가 매겨진 스마트폰 애플리케이션을 따르는 것이 틀리다고 말할 수 있는가?
가장 전문가의 권위와 지식에 의존하는 범주를 설명한다면, 그것은 ‘의학지식’과 같다. 하지만, 대부분 우리들은 이러한 전문가의 지식에만 의존하지는 않는다. 그것은, ‘경험 지식’에 의한 것일 수 있기 때문이다.
이미, 우리는 ‘지식’과 ‘경험’을 중첩으로 경험하는 시대를 접하고 있다.
이제는 ‘전문가’들이 ‘사용자들의 경험’을 더욱더 높은 가치로 인정하는 시대가 되고 있다.
‘PatientLikeMe'서비스의 경우에는 전문의들이 오히려, 사용자들의 경험을 참고하고, 인용하기 시작한다.
다만, 양이 늘어나면 질이 떨어지는 것을 어떻게 하는 것인가가 관건이지만, 그만큼. 다양성이라는 가능성을 얻게 되고, 콘텐츠는 보다 저렴하고 신속하게 소통되면서 획기적인 발견이나 창조성이 발견되러 질 가능성도 높아진다.
이제는 특정한 조건에 의해서 영향을 받는 것이 아니다.
노하우가 아닌 노후
knowhow가 아닌 knowwho
소프트웨어 개발 방법론은 다양한 방법과 전략들을 만들 수 있으며, 이를 통해서 수많은 요구사항과 문제점들을 배치하고 나열할 수 있다. 그 이외에도 소프트웨어 개발에 있어 필요한 스킬은 정말 많은 것을 필요로 한다.
대표적으로 부수적으로 필요한 스킬을 보면 보고서나 기획서를 쓰는 방법, 소프트웨어 설계를 잘하는 방법, 디자인 패턴을 고르고, 배치하는 방법, 인공지능과 같은 첨단적인 기법을 활용하는 방법까지도 매우 다양하다.
하지만, 이제 소프트웨어 개발에 있어서 최고로 필요로 한 것은 무엇일까? 과거에는 소프트웨어 개발을 가장 잘하는 방법은 how(어떻게) 그것을 만들어내는가에 집중되어 있었고, 그것은 Know-how라고 불렸다.
경험에 의해서 축적되어진 이 지식을 통해서, 결정되어졌으며, 이 노하우를 가장 많이 가진 사람을 ‘실력자’라고 인정하였다. 하지만, 시대가 바뀌고, 소통과 협업, 농담 삼아 이야기하는 구글 신이 지배하는 세상으로 변화하였다.
이제 ‘노하우는 필요 없다’는 것이다. 냉정하게 이야기하자면, 소프트웨어 개발자가 뭔지 모르면 배우면 되고, 그 자료나 정보들은 인터넷을 찾아보면 된다. 그리고, 그것 마저도 없으면 삽질하면서 얻어낼 수 있다.
현대의 소프트웨어 개발자에서 가장 문제가 있는 사람은 이것저것 다 빼고, 이러한 방법들을 시도조차 하지 않는 ‘안 하려는 사람’ 일뿐이다.
이제는 ‘삽질’을 하면서 얻을 수 있는 무궁무진한 방법들이 인터넷에 널려있는 세상이다.
소프트웨어 개발에 있어 대부분은 일상적이고 평범한 일이 대부분이다.
대부분 폼도 안 나고, 개발자로서 얻는 것도 없고, 평가도 부족한 업무와 소프트웨어 개발이 대부분이다. 과연 이러한 소프트웨어 개발을 하는 업무에 대해서 어떻게 평가를 해야 할까? 대부분의 소프트웨어 개발사들은 이러한 업무에 대해서 ‘평가’가 매우 적고, 박하게 평가하는 편이다.
그런 회사일수록, 해당 업무를 ‘누가 할 것인가’에 대한 ‘폭탄게임’이 심각하게 발생한다.
‘어떤 모듈이나 서비스를 어떻게 만들어야 하는지에 대해서는 모르는 사람이 없다’
‘신입만 되어도 해당 모듈이나 서비스는 만들 줄 안다’
이러한 업무들의 특징은 작업은 어렵지 않지만, 누가 크게 알아주지도 않는다. 하지만, 대부분 이런 업무의 특성이 대량의 파일을 다루고, 테스트 시간도 오래 걸리고, 잘해봐야 본전이고, 못하면 대박 깨지는 그런 업무들이다.
너무도 뻔하기 때문에, 너무도 뻔하게 업무를 해야 하는 업무들이고, 팀이나 조직원들 간에도 이러한 업무들은 가능한 전담하려 하지 않는 것이 대부분이다.
정말, 귀찮고, 매력 없는 업무들이기 때문이다.
물론, 몇 가지 방법이 있다. 그러한 일상적이고 뻔한 업무들은 외부에 용역을 주거나, 외부의 서비스들을 구매해서 사용하거나 연계해서 사용하는 방법이 최선의 경영진의 판단일 것이다. 기업은 ‘가치’를 인정받을 수 있는 최고의 일을 하는 것이기 때문이다.
‘폭탄 돌리기’가 가장 극심한 기업과 조직일수록, 가장 말이 많이 나오는 이야기는
‘원래 그 업무는 XXX가 해야 한다’라는 ‘원래’라는 식의 단어들이다.
‘이렇게 해도 되고’
‘저렇게 해도 되고’
‘요렇게 해도 된다’는 업무야말로...
냉정하게 ‘방법’을 몰라서 삽질하는 것이 아니라, ‘정치’적인 싸움을 하는 것이 가장 큰 문제이다.
‘양보’하면 계속 밀릴 수밖에 없다.
한번 기득권을 가져가거나, 협상에서 밀리면, 그 권한을 다시 회복하기는 정말 어렵다. 그래서, 기업 내부에서 팀 간의 ‘기득권’ 쟁탈전은 언제나 발생한다. 또한, 업무는 손쉽게 하면서 최고의 가치만을 얻어가려 애쓰는 것은 틀린 이야기가 아니다.
하지만, 이러한 ‘폭탄게임’은 회사의 수명을 짧게 만들고, 회사를 망하게도 할 수 있는 치명적인 문제로 발생하게 된다.
보통, 이렇게 정착되어진 ‘회사의 규칙’에 의해서, ‘중요한 고객의 요구사항’이 잘못 판단되게 되어지고, 그 영향은 제품과 서비스에 반영되어진다. 그리고, 그 기업의 품질에도 큰 영향을 주게 되는 것이 보통이다.
요구사항의 판단과 ‘품질’의 판단은 ‘양보’로 얻어지면 안 된다.
협의와 협상의 규칙이 만들어지는 것이 최선이지만, 그것이 안된다면, 중복적이고 가치는 적지만, 효용가치가 높은 것부터 업무가 가치 있고, 평가가 후한 업무라면 부서와 사람이 업무를 거부하겠는가?
요구사항과 업무는 그 가치와 평가가 효과적 이도록 결합되어야 한다. 부정적이고 의미 없는 업무를 제거한 상태라면, 요구사항들의 가치가 형성되도록 요구사항들이 결합되어야 한다.
소프트웨어 개발에는 ‘원래’라는 단어는 없다.
오래된 경력자들이 모이면 오히려 개발 진행이 어려운 경우가 많다. 그것은, 각자의 경험상에 축적되어진 지식들의 왜곡현상 때문에 발생하는 일상적인 일인 경우다.
자신의 경험과 지식과 타인의 경험과 지식이 왜곡되고, 서로에게 강요하는 일이 발생하게 되는 것은 매우 당연한 것이다.
냉정하고 ‘사공’이나 ‘선장’은 적은 사람이 해야 한다.
소프트웨어 개발에 있어서 가장 빠르게 변화하는 것과 자신의 가능성을 최대한 확장하는 방법을 잘 알고 있음에도 불구하고, 자신의 경력과 지식, 경험에 자꾸 제한을 가하게 되는 경우는 ‘경력이 풍부한 사람’ 일 수록 흔히들 빠지게 되는 함정과도 같다.
자신의 경력을 내려놓고, 신입과 동일한 ‘눈’으로 맞출 수 있는 사람이 더 새로운 경험을 많이 하게 된다.
사공이 많게 되면 배가 산으로 가거나, 서로 샅바 싸움을 하거나, 배가 꿈쩍도 하지 않는 상황을 만들지 않게 하는 것이 아키텍트가 해야 할 일이다.
소프트웨어 개발에 있어서 가장 경험자가 많은 경우에 선택하기 쉬운 구조는 ‘독재’를 하는 방법이 최선이다. 대부분의 회사들은 그러한 ‘정치구조’를 선택한다. 그리고, 그러한 구조를 통해서 ‘컨트롤’을 하는 것이 일반적이다. 그래서, ‘일반적인 구조’가 어울리는 소프트웨어 개발 조직도 많다.
다만, 이 조직은 철저하게 ‘리더의 자질’에 의해서 모든 것이 결정되어진다는 점이다. 한 사람이 가진 지식과 경험이라는 것은 ‘인터넷의 바다’에 비한다면...
토론과 의견수렴을 하는 방법을 만들자
기업의 입장에서는 ‘디아블로’와 같은 절대군주와 같은 리더가 최선일 수 있다. 그리고, 그 군주가 실패하면 갈아치우면 되니까 가능한 구조이다. 다만, 이러한 ‘업무 스타일’은 유지하게 하는 것이 최선이다.
보통 ‘토론’의 경우에는 ‘5명’이 넘어서는 안된다. 대부분 그 이상의 토론은 통제 자체가 불가능하다.
대부분의 정치구조는 ‘혼란’스러우면 ‘독재’를 선택한다. 그리고, ‘현명한 군주나 리더’가 너그러운 정치를 통해서, 좋은 결과를 유도하기를 바란다.
의사결정 과정은 ‘민주적’이지 않지만, ‘좋은 결과물’을 만들어내는 대부분의 구조는 이러한 방법이 대부분이다.
하지만, 대부분 이러한 구조는 ‘정치’적인 상황을 만들고, 그 리더와 그 의견에 동조하는 세력들이 모여지고, 발언권을 동조하는 세력들을 만들게 되는 상황으로 흔하게 흘러간다.
이러한 모습이 대부분 기업들이 중견기업으로 성장하면서 겪게 되는 대부분의 문제들이다. 하지만, 이러한 모습들은 불편한 상황들을 만든다.
냉정하게 대부분의 정치는 ‘목소리’를 내고, ‘목소리’가 큰 사람이 주도하는 형상으로 끌려간다. ‘적극적으로 의사표현’을 하는 사람들의 위주로 흘러가게 되는데, 문제는 이러한 행위들이 사익을 위한 것인가? 회사 전체를 위한 것인가? 에 대한 모호함 때문이다.
더더군다나, 동양적인 소극적이고 양보하고 겸손하게 살게 하는 ‘문화’ 속에 살고 있는 우리의 입장에서는 정말로, 기업적인 색깔과 모습을 표현하는 것은 정말 어려운 일이고, 목소리를 내는 사람의 이야기를 ‘사익’에 가까운 모습으로 연상하게 되는 것은 어쩔 수 없는 일인지도 모른다.
가장 좋은 방법은 ‘의사표현’을 할 수 있는 방법을 제공해주는 것이다. 어떻게든, 소극적이고 겸손한 사람들의 ‘의견’과 ‘아이디어’가 소통되게 만드는 것이 최선의 방법이다.
‘독재’는 빠르고 효과적이지만, 조직을 ‘지옥’으로 만들 가능성이 농후하다, 하지만. 내부가 불통되고, 세력다툼이 벌어지는 구조는 더더욱 문제가 심각하다. 최선의 선택은 언제나 ‘독재’ 인지도 모른다. 하지만, ‘똑똑한 독재자’는 ‘왕조’, ‘편안한 왕조’와 ‘똑똑한 왕’이 된다.
그래서, 기업들 대부분이 경력 2~4년 차를 원한다. 대부분 ‘독재화’되어진 구조에서는 ‘아이디어’가 필요한 것이 아니기 때문이다.
우리 기업에 있어서 ‘혁신’이나 ‘창의성’이 정말 중요한가?
아이디어와 요구사항이 가장 잘못되어지는 것
추상화가 가장 잘못되어지는 사례는 기획을 한 사람과 구현한 사람이 중요한 핵심기능을 잊어버린 체, 변화되는 ‘어떤 것’에만 집중하는 경우이다. 사용자에게 ‘제공되는 가치’에 대해서 제대로 인식하지 못하면, 끊임없는 반복 작업만이 기다리고 있으며, 유지보수성이나 플랫폼과 같은 결과물은 기대할 수 없게 된다.
‘어떤 기능’에 대해서 무비판적으로 기능을 추가하는 것이 가장 큰 문제이다.
소프트웨어 개발에 있어 절체절명의 원칙은 ‘반복 작업’을 최소화하는 것이다. 그 방법이 유틸리티를 만들든, 서비스를 만들든, 스크립트 언어를 사용하던, 어떻게든 최소화하는 것이다. 다만, 그 리소스의 활용이나 기간 상의 문제만 다를 뿐이지, 추상화는 ‘반복 작업’을 최소화한다.
특히, 소프트웨어 개발기업에 있어 가장 중요한 소프트웨어 개발자의 리소스를 가장 효율적으로 사용할 수 있도록 디자인하는 것이 최선이다. 기획자와 요구사항 수집자는 가능한 소프트웨어 개발자가 ‘한 번만 개발 작업’을 할 수 있도록 최선을 다해서 추상화를 하는 것이 최선이다.
소프트웨어 개발에 있어서 ‘메시지’를 기획자가 자유롭게 다루도록 하되, 소프트웨어 개발자는 ‘메시지’를 표현하는 기능은 한 번에 집중하게 하는 것이, 추상화의 기본 원칙을 쉽게 설명한 것이다.
그렇다면, 이러한 요구사항을 추상화하는 과정은 누가 해야 하는가? 냉정하게 이야기한다면, 기획자가 최선을 다해서 추상화하여, 소프트웨어 개발자의 리소스를 최대한 활용할 수 있도록 해야 한다.
그 원칙은 어떻게 하면 프로그래머의 작업을 최대한 단순화하느냐에 달려있다.
이 원칙은 프로그래밍 팀과 기능 관련 회의와 일정을 최소화하고, 버그를 줄여주며, 기획이 최대한 반영되는 방법으로 변화한다.
냉정하게 그 기업에서 ‘월급이 밀리냐? 안 밀리냐?’의 중요한 차이는 이러한 아이디어나 요구사항을 어떻게 최대한 추상화하느냐에 달려있다.
더 쉬운 설명은 ‘데이터’가 변화하는데 ‘소프트웨어 코드’가 바뀐다면, 그 소프트웨어의 추상화는 실패한 것이다.
기획과 요구사항을 어떻게 추상화해야 하는가?
요구사항을 유스 케이스로 표현하면서 최대한 가능하게 된다.
어떤 것들이 유지보수에 집중적인 영향을 주는가를 생각하게 한다.
아키텍트가 존재하는가?
그렇다면, 독재와 집중 통제 방법을 사용하고, 없다면, 담당자끼리 직접 의사소통을 하는 것이 최선이다. 하지만, 이것도 역시 최선의 해답은 아니다. 가장 확실한 것은 계속 소통하면서 자신의 환경에 맞도록 프로세스와 협의 과정을 변화시키는 것이다. 아키텍트는 있으면 충분하게 도움이 될 뿐이다. 있다고 모든 것이 성공하는 것도 아니라는 것을 명심하자.
그리고, 그것이 애자일의 철학의 기본 개념이다.
잘 모르면, 베끼는 것도 최선일 수 있다.
창작자가 만들어낸 것은 대부분 많은 시행착오의 결과물이다. 하지만, 이것을 복제해내게 되면 비슷하게 만들면서 엄청나게 누적되어진 시행착오를 만나지 않는다.
하지만, 대부분 이렇게 복제하게 되면, 무언가 부족한 느낌이 들거나, 무언가 허전하게 된다는 것은 약점이다. 또한, 그 시행착오의 결과물들이 또 다른 지식과 경험으로 파생되어지는 경우가 발생할 수 있다.
예술과 창작이라고 하더라도, 습작의 시기에는 베끼는 것을 통해서 수련의 과정을 겪는다.
일단, 기업이 시작되었다면 치열한 것이고, 비용과 사람의 수고가 투입되게 된다. 최악의 상황에서는 첫 번째 달려가고 있는 기업이나 서비스를 베끼는 것도 또 하나의 방법이기도 하다.
더군다나, 국내에 해당 서비스가 없다면, 해외의 서비스를 그대로 베껴서 국내 시장에 내놓는 방식은 선배들이 대부분 따라 한다. 일단, '돈'과 '인원'을 모았다면, 그대로 베끼는 작업을 아무런 고민도 없이 진행하는 사람들이 더 빠르게 시장에서 안착하고 성공하는 경우를 너무도 많이 봤다.
망하면 쪽박을 차는 사업을 하고 있다면, 체면은 뒤로하고, 망하지 않기 위해서 최악의 상황에서는 '베끼는 것이 최선'이다. 슬프지만, 기업이란 것이 원래 그렇다. 특허와 법, 표절과의 경계선에서 움직이는 사람들이 돈을 벌고 성공하는 것이 기업과 사업의 운명이란 것을 엄청 말아먹고 난 다음에 깨달았다.
그리고 생각해야 하는 것이 소프트웨어 품질에 대한 이슈이다.
소프트웨어 개발의 품질이 올라가려면?
소수정예의 소프트웨어 개발자와 그 이외의 업무를 담당하는 프로그래머가 다수 포진해야만 가능하다. 인력 구성도 그렇게 만들어야 한다. 고품질을 지향하는 개발자와 유지보수를 지향하는 개발자의 구성이 적절해야 한다. 보통 3:7 정도로 인력을 배치한다.
그리고, 애매한 요구사항을 명확하게 정제해야 한다. 이때에 '애매한 다수결의 원리'를 따르지 말아야 한다.
팀원이 많은 팀의 의견이 대부분 받아들여지고, 그들의 리소스를 효과적으로 이용하는 방법으로 소수의 팀의 업무가 더 집중화되는 경향이 높다. 그래서, 대부분 이 여파로, 자신의 팀원을 늘리려는 경향을 보이기도 하다.
냉정하게 적은 수의 팀원의 업무가 늘어나고, 다수의 인원이 존재하는 팀에서 보다 창조적인 작업만 하게 되는 현상은 방지해야 한다.
소프트웨어 개발회사의 가장 큰 문제는 ‘다수결의 함정’에 빠지는 것이다.
QC와 품질이 높아지는 방향을 선택해야지, 다수가 동의하는 방향으로 선택되어지면 안 된다. 냉정하게 다수의 의견이 집단이기주의 + 다수결의 결과물이라면 독재가 오히려 현명하다.
슬프지만, 개발 경험이 부족한 경영자나 스킬이 부족한 팀 리더가 '회의'시간을 늘릴수록, 서비스는 산으로 가고, 개발 품질이 떨어지는 것을 무수하게 경험했다. '회의'를 좋아하지 말고, '개발자'들 간의 소통이나 코드리뷰가 가능하도록 구성해야 한다.
이러한 환경상의 문제를 효과적으로 반영하여 주어야 한다. 대부분 ‘인원수’에 의한 ‘판단’을 하게 되면 이런 현상이 발생하고, 조직의 인원이 기하급수적으로 증가하게 된다.
물론, 리소스가 풍부할 경우는 상관이 없겠지만, 대부분의 기업은 리소스의 투입은 한계를 가지고 있다. 분명, 개발자가 더 집중적으로 해야 하는 일이지만, 이 인원을 더 늘리지 못하거나 한계치에 다다른다면, 그 업무를 외부로 분산시키는 것이 더 효과적일 수 있다.
현대의 소프트웨어 개발은 대부분 소규모 팀으로 가능하다. 대규모 팀으로 가능하게 세팅하는 경영진이거나 팀 리더라면 그 사람부터 정리하는 것이 최선일 것이다.
또한, 가능하면 ‘기획’을 하지 않도록 프로그래머의 시야를 줄여주어야 한다.
소프트웨어 개발자의 특징은 깔끔한 코드와 탄탄한 자료구조이다. 이해되지 않는 기획을 가지고, ‘왜? 그런 식으로 해야 하지?’라고 생각하게 하는 것은 심각한 문제를 야기한다.
프로그래머는 ‘버그’를 줄이고, 효율적인 코드를 만드는 것에 집중한다. 당연하게도 ‘기능을 줄이고,’ ‘콘텐츠’를 최소화하는 방향으로 진행한다.
이러한 것은 ‘당연한 혁신이나 아이디어’를 파괴하는 행동이 될 수 있다.
참신한 아이디어나 혁신은 ‘기존의 틀과 관습으로는 해석 못하는 것이 많은 것이 현실이다’.
의사소통은 곧! 비용이다. 그리고, 품질이다.
기획서에는 ‘형용사’를 남발하는 것이 아니다.
‘형용사’를 줄이고, 구체적인 수치와 설명으로 요구사항을 바꾸어라.
구체적인 숫자, 스케치, 참고자료로 구현되어야 한다.
물론, '완벽한 기획서'를 만들 수 있다. 그런 기획이 가능하다면 정말 환상적인 서비스와 소프트웨어 품질이 가능할 것이다. 하지만, 필자도 20년의 경력과 경험상 단 한 번도 그런 일이 발생된 기적적인 일은 존재하지 않는다.
완전하지 않은 기획과 불완전한 기획으로 삽질을 반복해야 하는 비싼 리소스를 사용하는 개발자들을 적절하게 방향을 잡아주면서 방향을 잡아가야 한다. 다만, 이 경우 '팀 리더'가 방향성이라도 제대로 잡고 있으면 그나마 혼란스럽지 않지만, 방향성마저도 갈지자를 그린다면 팀의 붕괴나 서비스의 품질은 그 누구도 보장할 수 없게 된다.
기획자는 기획의 불완전함을 인지하고, 개발자와 소통해야 하고, 개발자도 기획의 불완전함을 이해하고, 어떻게 하면 개발자가 싫어하는 삽질이나 반복적인 일정을 줄일 수 있는지에 대해서 기획자에게 끊임없이 이야기해야 한다.
서로 간의 신뢰관계가 없다면, 이러한 애자일스러운 개발은 그냥 '꿈'일 뿐이다.
그리고, 기획과 개발의 업무는 롤로 구분되어져야 한다. 이 두 업무가 동시에 가능한 개발자는 '천재'라고 인정하고, 절대적으로 팀에서 '인력관리'에 총력을 기울이기를 바란다. 하지만, 대부분은 이 두 롤은 분리되어야 하고, 팀 구성과 의사소통에 상당한 비용을 지불해야 할 것이다.
물론, 의사소통이 엉망이고 적절치 못한 서비스가 만들어지는 경우에도 기업은 매출을 올리는 경우도 많다. 작은 규모의 시장의 경우 '버그'가 있거나, '불완전한 서비스'로 구성되어진 소프트웨어로도 충분하게 시장에서 의미가 있는 경우도 많다.
태생적으로 '업무가 불명확한' 환경의 업무도 상당히 많다는 것을 이해하자. 단지, 영업능력을 확고하게 보유한 대표이사님의 엄청난 인맥으로 '매출'이 발생하고, 소프트웨어는 서비스인 경우도 실제 시장에 상당히 존재한다.
스타트업이 실패할 수 있는 방법은 위에서 나열한 여러 가지 에피소드를 통해서 불완전하게 흘러갈 수 있지만, 기업은 '돈'을 버는 황당한 경우도 많다. 실제, 많이 봤다. ~.~ 그런 회사는 '스타트업'이라기보다는 전혀 다른 단어로 언급되어야 할 것 같다.
마치, 대기업 재벌 3세의 빵집이 아버지의 호텔에서 오픈한 형태라고나 할까? 아니면, 아버지 회사의 1층 로비에 커피숍을 차린 것과 같은 회사인 경우도 실제 사업을 하면서 많이 보게 된다.
역설적이지만, 스타트업이 성공하는 것은 '그 한 가지'를 채울 수 있기 때문에 가능한 것인지도 모르겠다. 스타트업이 성공하기 위한 조건을 나열하는 것은 너무도 어렵지만, 실패하는 조건들을 나열하는 것은 너무도 많기 때문이다.
언제나 이야기하지만, 내 칼럼은 그러하다. 성공의 조건은 나열하기 어렵고, 이런 식으로 하면 망한다는 언제나 이야기해줄 수 있을 뿐이다.
