10년 간의 삽질

바쁜 가운데에도 실패에 관한 기록을 남겨야 할 시기라고 생각해서 글을 시작합니다.

 

저는 10년이 넘도록 온라인 실시간 강의 솔루션을 틈틈이 만들어 왔습니다.  전문적으로 온라인 강의 솔루션에 몰입 할 수 있었던 기간은 4년 정도 되는 것 같습니다.  그 동안 두 번의 투자를 받아서 사업을 시도해본 적도 있습니다.  첫 번 째는 여러 이유로 제대로 시작도 못해보고 문을 닫고, 두 번 째는 2년 정도 개발만하다가 접어야 했습니다.  

 

그러다가 스스로 창업을 한 지, 1년이 되었습니다.  서비스는 성공적으로 오픈 했지만, 이렇게 오래 시행착오를 거치게 된 이야기를 되 짚어 보고자 합니다.

 

 

초라한 결과물 그러나 "됐다"라는 착각

 

불완전한 결과에 쉽게 만족하는 실수

 

대부분의 기술적 문제는 목표가 명확해 보입니다.  수도를 설치하면, 물이 나오면 됩니다.  그리고, 그런 일상에 젖어 살다 보면, 불완전한 기초에 쉽게 만족하는 습관을 가지게 됩니다.  수도를 설치하고 녹물이 나오고 있는데도, 말입니다.

 

설마?  그렇게 생각하실 수도 있습니다.  비유를 들어 보이고, 객관적으로 이 글을 읽을 때는 그렇게 생각할 수 있지만, 사실 많은 개발자들이 쉽게 범하는 실수 입니다.

 

보다 이런 습성이 위험해지는 순간이 있습니다.  그것은 유사한 곳에 같은 기술을 적용하여 해결하면서 발생합니다.  우리가 자주 쓰는 표현으로 "가래로 막을 것을 호미로 막는다" 와 같은 순간입니다.

 

서비스, 고객, 비즈니스 또는 마케팅의 영역에 들어서면 이러한 갈등이 더욱 심화됩니다.  기술 세계에서 추구하는 명확함 대신 추상적인 가치들이 중요해지기 시작하기 때문입니다.

 

불안정한 기초 위에 가치를 쌓아 올릴 수록 늘어나는 부목들, 그리고 기초보다 거대해진 부목들

 

불안정한 기초 위에 탑을 지어 올립니다.  그런데, 기초가 부실한 탓에 탑이 자꾸 흔들리고 위태해집니다.  시간은 촉박합니다.  결국 탑 자체를 개선하지 못하고, 옆에 부목을 덧붙여서 해결합니다.

 

이런 모습은 엔지니어링 현장에서 자주 볼 수 있는 상황입니다.  결국에는 부목 자체가 버거워서 부목을 위한 부목까지 필요해지게 되고, 나중에 가서는 핵심인 탑은 보이지도 않게 됩니다.  그리고, 보이지 않는 핵심보다 눈에 당장 거슬리는 부목에 대한 해결책만이 급급해지기 시작합니다.

 

아무리 뛰어난 기술자도 처음부터 예측하는 것은 한계가 있다.

 

처음부터 모든 것을 예측할 수 있는 것은 아니기 때문에, 정기 점검의 타이밍을 놓쳐서는 안됩니다.  하지만, 일정에 쫓기는 개발 현장에서 정기 점검이란 쉽지 않습니다.

 

그러나, 점검과 핵심 문제 해결이 선행되지 않으면 최종 비용과 일정은 예상을 휠씬 뛰어넘는 수준이 될 것은 분명합니다.

 

자신이 고용된 입장에서는 이러한 주장을 하는 것이 쉽지 않습니다.  하지만, 자신이 창업한 이후에도 저는 이러한 실수를 저질렀고, 그렇게 문제가 커지는 동안 자각하지 못하고 있었습니다.

 

정기 점검을 연기하게 되는 이유

 

정기 점검을 방해하는 요소들이 너무나 많습니다.  여기서는 저의 경우만 한 번 되 돌아 보겠습니다.

 

첫 번 째 요소는 바로 투자자였습니다.  실패를 투자자에게 떠 넘기려는 파렴치한 생각은 아닙니다.  저는 항상 저에게 투자해주신 분들에게 감사하며 죄송한 마음으로 살아갑니다.  하지만, 투자자가 생기면 더욱더 쫓기게 됩니다.  투자자가 부추기는 경우도 많지만, 결국 스스로가 거기에 호응하거나 오버하게 됩니다.

 

손자병법에 보면, "장수는 때로 군왕의 명령을 어길 수 있다"라고 되어 있습니다.  실전의 상황을 모르는 정치적인 결정이 전술에 있어서 얼마나 위험한 일인지 알고 있기 때문입니다.  투자자와 개발자의 관계는 군왕과 장수의 관계처럼 작용되는 경우가 많습니다.

 

두 번 째 요소는 고객입니다.  고객이 생기고 많아질 수록 요구사항은 늘어나고 다양해 집니다.  그리고, 개발자도 현실을 되돌아 보지 못하고 과욕을 부리기 쉽습니다.  결국 버릴 것은 버리고, 핵심에 집중해도 살아나기 힘든 비즈니스 세계에서 도태됩니다.

 

특히나 사업 초기에는 자신이 소화할 수 있는 먹이에 집중하는 것이 좋습니다.

 

세 번 째 그리고 가장 중요한 요소는 개발자의 섣부른 판단입니다.  저를 비롯한 많은 개발자들이 정형화된 데이터가 아닌 직감을 토대로 많은 결정을 합니다.

 

"이런 기능 추가 가능할까요?" 라고 고객이 물으면, 자신이 그 기능을 개발 할 수 있다고 생각하는 순간 바로 "네!"라고 대답합니다.  그 기능을 추가하고 난 뒤, 어떠한 부작용이 생길지는 추호도 생각하지 않습니다.

 

마치, "이 증상에 치료제가 있나요?"하고 환자가 물어보니 "아 여기 있네요?"하고 바로 약을 건네주는 의사와 같습니다.  그 환자가 해당 약에 부작용을 겪은 적이 있는 지, 다른 질병으로 인해서 생긴 증상인지는 생각하지도 않고 말입니다.

 

 

 

개발자 자신의 기술적 불안정

 

자신이 알고 있는 지식(기술)을 제대로 평가하지 못하는 위험

 

제 스스로가 우물 안에 개구리였다는 사실은 그 우물 안에 있을 때 전혀 알 수 없습니다.  그런데, 우물 밖으로 나온 순간에도 아직 더 큰 우물 안 속이라는 것을 모르고 기고만장한 탓에 결국 비싼 대가를 치르고 말았습니다.

 

더 좋은 방법이 있어도 그 것을 외면하는 것은 상당히 멍청한 짓이라고 생각합니다.  하지만, 우리는 자주 더 멍청한 방법에 얽매여 살아갑니다.

 

시야가 문제

 

아는 만큼 보입니다.  그리고, 지식은 다른 지식을 통해서 완성됩니다.  다양한 지식과 정보가 부족하면, 문제와 직접 연관되지 않은 곳에서 발견할 수 있는 해법을 찾아내기 어렵습니다.  문 앞에 있는 열쇠만을 사용하게 될 뿐 입니다.

 

어느 우스개 소리에 "전구 하나를 갈려면 몇 명이 필요한가?"라는 것이 있습니다.  일단 전구를 갈기 위해서 한 사람이 전구를 들고 있습니다.  그런데 키가 안 닿네요.  결국 책상을 가져와서 올라섭니다.  이제 전구를 돌려야 하는데, 책상이 돌아가지 않습니다.  그래서, 네 명이 책상 모서리를 들고 돌립니다.

 

인과 정보의 일부분만 조명하다 보면 언제나 멍청한 해법이 우선하게 됩니다.

 

스스로 해결 할 수 없다고 해도, 심도 깊은 이해가 필요합니다.

 

다른 분야의 지식을 완전히 체득할 수 없다고 해도, 해당 분야에 대한 깊은 이해가 바탕이 되지 않는다면, 접목하여 새로운 발명을 이끌어내는 것은 어렵습니다.

 

하지만, 이조차 저는 너무 쉽게 덤비고 나서 후회를 일 삼고는 했습니다.

 

"협력"이라는 장미빛 환상을 가지고, 다른 전문가의 힘을 빌려서 "문제"를 해결하려는 순간 "문제"는 온데 간데 없고, "협력" 자체가 버거운 임무가 되어 버렸던 것 입니다.  

 

"적임자를 찾아서 인원을 늘려가면 된다"라는 막연한 착각은 비효율적인 프로세스를 유도하여 사업을 더욱 어렵게 합니다.

 

 

 

비효율적인 프로세스

 

기술을 가진 자가 주도하는 비즈니스에서 주도자는 관리와 개발 그리고 잡무를 모두 하게 됩니다.  그리고 이를 해결하기 위해서 사람을 늘려가면, 그로 인해서 늘어나는 잡무의 비중이 더욱 커질 수도 있습니다.

 

혼자서 개발하다가 투자를 받게 되니, 자본의 여유가 생겼습니다.  그리고, 바로 직원을 늘려 갑니다.  직원을 늘리는 그 자체가 문제가 아니지만, 저의 경우에는 이것이 독이 되었습니다.

 

직원을 늘린 이유가 내가 힘들고 바빠서였습니다.  그리고, 그 짐을 덜기 위해서였습니다.  여기에 함정이 있었습니다.  물리적이고 구체적인 그리고 독립적인 단위의 짐을 덜기 위해서라면 사람을 늘릴 수록 유리합니다.  쉽게 벽돌을 나르는 일이라면, 사람이 많을 수록 당연히 도움이 됩니다.

 

하지만, 추상적이고 독립적인 단위로 처리할 수 없는 일들은 사람을 늘리면, 마치 2인 삼각 달리기를 하는 꼴이 됩니다.

 

그리고, 개발이 비즈니스와 연관되면 추상적인 요소들을 상당 수 해결해줘야 합니다.  결국 이런 추상적인 요구사항들을 효율적으로 협력 할 수 있는 방안도 없이, 무작정 인원 수를 늘리는 것은 그 자체가 독이 됩니다.

 

심지어 어떤 짐을 내려 놓아야 할 지가 막연해 지는 순간을 자주 경험하였습니다.  구체적으로 기술 할 수 없는 일정과 목표를 가지고 있었기 때문입니다.

 

 

 

결국 뻔한 이야기

 

그리고 그 뻔한 이야기 때문에 무너져 버린 제 자신을 되돌아보면서, 이번 창업에서는 반드시 지켜야 할 것이 무엇인가 항상 곰곰이 생각해왔습니다.

 

너무 많은 것을 한꺼번에 지킬 수는 없는 노릇이기에, 몇 가지만을 추려서 되새기곤 했습니다.  그것은 바로..

• 작고 단순한 핵심을 유지한다.
• 자주 되돌아본다.
• 핵심 기술에 대하여, 오픈 소스나 3rd party의 무조건적인 의존을 피한다.
• 당장 필요하지 않더라도 몰랐던 기술에 대한 공부를 꾸준히 한다.
• 시간에 쫓기어 대책없이 사람을 늘리지 않는다.

 

작고 단순한 핵심 덕분에 충분히 괜찮은 결과물을 얻을 수가 있었습니다.

 

자주 되돌아보고, 이미 만들어진 것에 대한 점검을 통해서 최초의 생각대로 움직이지 않는 부분에 대한 근본적인 개선을 통해서 제품이 점점 복잡해지더라도 단순한 핵심이 잘 드러나도록 최선을 다했습니다.

 

핵심 기술에 관련된 것들은 오픈 소스나 다른 사람이 만들어 놓은 것을 사용하기 이전에 직접 만들어보거나 검토하여 해결했습니다.  유사하다고 무작정 가져다 쓰지 않고, 최대한 직접 해결하는 것을 원칙으로 하였습니다.

 

시간을 아끼기 위해서 최대한 전문 분야에만 국한했던 독서 습관을 바꾸고, 아무리 바빠도 독서와 글쓰기 그리고 메모 정리를 거르지 않았습니다.

 

사업 규모가 커지면 이 상태를 유지할 수는 없겠지만, 사업 초기인 만큼 모든 개발 프로세스를 혼자서 처리하였습니다.  스스로 정리가 된 것들을 사람을 뽑아서 위임 시키려 합니다.  하지만, 생각처럼 잘 되지는 않습니다.  우선, 웹 개발 부분은 수 개월 전부터 위임하여 처리하고 있습니다.  

 

앞으로도 핵심 기술은 소수 정예가 전체를 가늠 할 수 있도록 할 예정입니다.  개발 업무를 분야별로 분장하는 것이 아니고, 횡적으로 분업하는 것이 목표입니다.  즉, 기초 공사는 소수 정예가, 마무리 공정은 그에 따른 전문 인원이 처리하도록 말입니다.

 

다음 되돌아보는 글을 쓸 때에는 실패가 아닌 성공 스토리가 되기를 바라며 ^^*