Title:
이콜레모 2015년 회고
|
edited by
Youngrok Pak
at
8 years, 11 months ago.
<p>2015년은 지금까지 이콜레모의 역사에서 한 가지 목표만을 끝까지 유지한 첫번째 해였다. 그만큼 이전까지의 이콜레모는 전략적으로 형편 없었다는 뜻이 되겠다. 이전에도 이콜레모가 외주를 많이 했고, 중간중간에 재미 있었던 순간도 많았지만, 총체적으로 유쾌한 경험이었다고는 할 수 없었다. 다음은 그런 고민들이 담겨 있는 글들이다.</p>
<h3>이콜레모 외주 실패의 역사</h3>
<ul>
<li><a href="일기장/2009-02-27">일기장/2009-02-27</a> 우리는 프로젝트의 성공을 원하지만, 고객은 프로젝트의 완료를 원한다.</li>
<li><a href="일기장/2009-05-03">일기장/2009-05-03</a> 대기업의 횡포</li>
<li><a href="일기장/2009-05-11">일기장/2009-05-11</a> 적당히 외주해서 돈 모은 다음에 우리 아이템 하자는 전략의 허구성</li>
<li><a href="일기장/2009-11-04">일기장/2009-11-04</a> 창업 이념을 잃고 돈에 휘둘린 시간</li>
<li><a href="일기장/2009-12-14">일기장/2009-12-14</a> 이젠 돈에 휘둘리지 말아야지</li>
<li><a href="일기장/2010-05-24">일기장/2010-05-24</a> 갑질 고객을 미리 판별할 수 있을까?</li>
<li><a href="일기장/2010-05-16">일기장/2010-05-16</a> 좋은 외주 고객에 대한 나름대로 생각해본 조건</li>
</ul>
<p>뭐 구질구질 많지만, 요약하면 제대로 외주하는 것도 아니면서 돈에 휘둘리기는 했고, 좋은 고객을 필터링하기 위해 열심히 회고하고 분석했으나 다 소용 없었다는 이야기다. 그래서 재작년에 다시 외주를 시작할까 아니면 아예 새로운 길을 찾을까 고민을 많이 했었다. 그러다가 새로운 시스템으로 외주를 해보기로 마음을 먹었다. 그 시스템은 바로 시간제 보수 시스템이다.</p>
<h3>시간제 보수 시스템의 배경</h3>
<p>이 시스템을 선택하는데 영향을 주었던 것들은 이런 것들이다.</p>
<ul>
<li>변호사, 세무사 등은 시간당 상담료를 받는다.</li>
<li>XP에서 이야기하는 외주 프로젝트에서의 pay per use 개념</li>
<li>자신이 원하는 수준에 따라 개발 비용이 차이가 난다는 것을 알게 되면 고객도 더 합리적으로 행동하려고 하지 않을까?</li>
<li>소프트웨어 견적의 불합리성</li>
<li>프로그래머도 노동자인데 노동 가치로 돈을 받는 것이 합리적이지 않을까?</li>
<li>몇 번의 짧은 취업 경험에서 내 시장 가치가 꽤 괜찮다는 것을 알게 됨.</li>
<li>어차피 내 마음에 드는 소프트웨어를 외주에서 만들 수 없다면 그에 상응하는 돈이라도 받자.</li>
<li>지섭이에게서 배운 연봉 협상 전략 - 원하는 금액을 스스로 정하고 그 금액을 주는 회사를 만나기 전까지 타협하지 말라.</li>
<li>공인 단가대로 제대로 받을 수만 있다면 먹고 사는데는 문제 없다.</li>
</ul>
<h4>프로그래머의 수급 불균형</h4>
<p>연봉 협상 전략은 지섭이가 자기가 원하는 연봉을 정해놓고 취업하는 과정을 보고 배운 것이다. 옆에서 지켜보니 연봉은 자기가 원하는 금액에 다소 못 미치지만 그 외의 조건들을 생각해보면 괜찮아보이는 건들이 여럿 있었는데 지섭이는 계속 거절했다. 솔직히 지섭이가 저러는 걸 보기 전까지의 나라면 저러다 영영 취직 못할까봐 겁나서 못했을 거다. 근데 이 녀석은 꿋꿋이 밀고 나가더니 결국 원하는 조건의 일자리를 찾았다. 뭐 그 뒤로 오래 일한 것 같진 않지만;;</p>
<p>그래서, 나도 이콜레모를 잠정 중단하고 취업을 해볼까 하던 시기에 이 전략을 채용했다. 근데 조금 더 나아갔다. 협상이 한 번 실패할 때마다 희망 연봉을 1천만원 올리기. 이렇게까지 할 수 있었던 것은 지섭이를 지켜보면서 용기를 얻게 된 것도 있고, 또 그 사이 프로그래머 수요가 더 늘어나서 공급을 크게 초과하고 있다는 사실도 눈치 챘기 때문이다. 항상 시장 원리에 당하기만 해왔던 노동자 입장이지만 시장 상황이 변하면 역으로 이용할 수 있는 것도 당연하다.</p>
<p>그래서 네 번 협상을 실패하고 다섯 번째에 내가 원하는 조건으로 취직을 성공했다. 나 역시 지섭이처럼 거기에 오래 머무르진 못했지만, 여튼 이 경험은 고급 프로그래머의 수급 상황에 대한 확신을 가질 수 있었다. 그래서 내가 지금도 다른 프로그래머들에게 이런 조언을 한다. </p>
<blockquote>
<p>찾는 곳이 없으면 나에게 오라. 내가 일거리를 주겠다.</p>
</blockquote>
<h4>소프트웨어 견적의 불합리성</h4>
<p>이게 내가 용기를 낼 수 있었던 이유라고 한다면, pay per use의 개념은 이 시스템이 더 합리적이라고 생각하는 이유다. 아니, 반대로 소프트웨어 견적의 불합리성이라고 해도 좋겠다. 소프트웨어 프로젝트를 미리 견적을 낸다는 것 자체가 말이 안되는 개념이다. 아직 소프트웨어 개발이 얼마나 걸릴지 예측할 수 있는 프로그래머는 태어난 적이 없다.</p>
<p>소프트웨어 개발을 시작하기도 전에 미리 견적을 내서 비용을 고정하고 프로젝트를 하면 갑과 을은 어떻게 행동하게 될까? 갑은 최대한 작은 견적을 받아서 계약하려고 할 것이고, 을은 최대한 부풀리려고 할 것이다. 여기까지는 좋다. 시장이니까. 근데 문제는 계약한 후에 일어난다. 계약한 후에 갑의 행동은 어떻게 될까? 갑은 이미 비용이 고정되어 있으니 최대한 많은 기능을 집어넣으려고 한다. 그게 이익이라고 생각하니까. 그러면서도 이미 약속했던 기능이 안되는 사실은 참을 수 없다. 손해니까.</p>
<p>을은 당연히 정반대로 행동한다. 이미 받을 비용은 정해져 있으니까 최대한 적은 노동을 해주는 게 이익이므로 고객과의 협상은 늘 일의 양을 줄이는데 초점이 맞춰진다. 물론 가끔은 을의 담당자가 자기 회사의 프로그래머보다 갑을 만족시키는 것을 중요하게 생각하는 경우가 있는데, 이 경우는 을의 담당자가 갑 역할이 되고 프로그래머들이 을 역할이 되기 때문에 문제가 쉬프트되긴 해도 그대로 존재한다. 어쩌면 이게 많은 프로그래머들의 현실일 것이다. 팀장은 갑님 앞에서 예스맨이 되어 굽실거리다 회의 끝내고 와서는 프로그래머들을 몰아세우는 상황. </p>
<p>이런 것 뿐만이 아니다. <span style="line-height: 1.42857;">예를 들어 내가 고객의 요구를 아주 멋지게 만족시켜줄 수 있는 방안이 생각났는데 이미 계약한 금액이 턱없이 모자란다. 그럼 내가 그 아이디어를 말할까? </span><span style="line-height: 1.42857;">반대로 고객이 자기도 처음에 원했던 기능 중에 하나가 이제 필요 없다는 것을 알았는데, 이거 안해도 된다고 할까? 하든 안하든 비용 지불하는 건 똑같은데? 다행히 지혜로운 고객들도 종종 있고, 그들은 그게 결과적으로 자신들에게도 이득이라는 것을 알기 때문에 필요 없는 것은 처음에 하기로 했더라도 빼자고 하는 경우가 있다. 하지만, 대부분은 이게 손해보는 느낌이 드는지, "그래도 하기로 했잖아요"하면서 끝까지 요구하는 경우가 많다. 아니면 그 대가로 다른 걸 넣어달라고 하거나.</span></p>
<p>이처럼 고정 비용 하에서는 갑과 을의 이해 관계가 상충되기 때문에 이 소프트웨어를 어떻게 하면 잘 만들어야 할까 둘이 머리를 맞대고 고민을 해야 할 중요한 회의 시간에 이 일을 뺄까 더할까로 싸우게 된다. 프로젝트가 잘 되려면 둘이 협력을 잘 해야 할 텐데 말이다. 근데, <a href="http://agilemanifesto.org/">애자일 선언</a>의 세번째 가치가 뭐더라?</p>
<blockquote>
<p><strong>Customer collaboration</strong> over contract negotiation</p>
</blockquote>
<p>나는 이걸 하고 싶은 거다. 그렇다고 해서 손해를 보면서 일할 생각은 눈꼽만큼도 없다. 그럼 답은 간단하다. 일한 만큼 돈을 받으면 된다.</p>
<p>일한 만큼 돈을 받으면 고객이 아무리 무리한 요구를 하더라도 그만큼 돈을 받으니까 나는 손해를 보지 않는다. 그러면 나도 열린 마음으로 고객의 문제 해결에 집중할 수 있게 된다. 근데 여기까지 해주면 내가 손해고, 저기까지 해주면 내가 이익이고 이런 생각을 해야 하는 상황이 오면 집중이 될 리 만무하다. 예전의 이콜레모는 다소 손해를 보더라도 고객에게 좋은 기능을 탑재해주는 것을 우선하기도 했는데, 그 결과는 적자는 도저히 유쾌하게 받아들일 수가 없었다.</p>
<h4>노동가치가 부가가치보다 중요하다</h4>
<p>프로그래머의 성과는 유독 노동가치보다 부가가치로 평가하려는 경향이 있다. 소프트웨어는 들어간 노력보다 훨씬 큰 부가가치를 창출하는 경우가 많으니 그 부가가치를 나누어 받아야 하는 것 아니냐는 논리다. 주로 노임 단가제도를 비판하는 논거로 많이 등장한다. 하지만, 이건 자본가의 논리다. 그럼 만일 개발한 소프트웨어가 아무 가치를 창출하지 못하면 프로그래머는 돈을 받지 않아도 되는가?</p>
<p>내가 투자 받는 스타트업을 안하려는 이유도 비슷한 맥락이다. 투자 받아서 스타트업이 성공하면 세상의 권력은 더 자본가 쪽으로 이동한다. 물론 실질적인 부는 투자자보다 창업가들이 더 많이 가져갈 수도 있다. 하지만, 그들은 그저 새로운 자본가 대열에 합류하는 것 뿐이다. 그런 스타트업이 많아지면 스타트업의 나쁜 근무조건을 견디라는 압박이 노동자에게 더 많이 가해진다. 일반적인 스타트업의 성공은 그 자체로 나중에 대박 날 테니 지금은 참고 미친듯이 일하라는 메세지를 이 세상에 던지는 셈이다. 그러니까 임금을 노동가치보다는 부가가치로 평가하게 만드는 세계관을 퍼트리는 셈이다.</p>
<p> </p>
<h3>이콜레모의 외주 원칙</h3>
<p>이전과 달라진 것은 시간제 보수만이 아니다. 여러 가지로 외주를 하는 원칙이 달라졌는데, 모두 정리하면 이렇다.</p>
<ul>
<li>비용은 투입한 시간에 비례해서 받되, 단위는 하루와 반나절 두 가지만 사용한다.</li>
<li>비용을 받는 시간당 단가는 투입한 엔지니어의 역량에 따라 다르게 정하되, 내가 정한다.</li>
<li>계약하기 전에는 고객을 만나러 가지 않고, 오는 고객만 만난다. (친구, 예전 동료, 동문 등은 찾아가기도 한다.)</li>
<li>비용은 매달 정산 받는다.</li>
<li>조건만 맞으면 고객을 선별하지 않는다.</li>
<li>컨설팅 등의 단기 프로젝트가 아닌, 내가 주도적으로 코딩해야 하는 프로젝트는 동시에 2개 이상 진행하지 않는다.</li>
<li>동시에 일을 의뢰하는 고객이 많을 때는 계약까지 먼저 진행하는 고객과 일한다.</li>
</ul>
<h4>찾아오는 사람만 만난다</h4>
<p>리스트는 길지만, 간단히 요약하면 시간제 보수에 합의하고 날 찾아와서 일을 의뢰하는 사람하고만 일한다는 것이다. 찾아가지 않기로 한 것은 딱히 내가 거만해서가 아니라 시간제와 연관이 있다. 일하는 시간만큼 돈을 받는 시스템이다보니 공치는 날을 줄여야 한다. 서울에 미팅하러 가면 보통 반나절을 날리게 되는데, 그러면 월 수입의 40분의 1이 줄어드는 것이다. 우리 회사가 크다면 영업 비용으로 그 정도는 감수할 수 있지만, 현재 이콜레모는 내가 전력의 대부분이니 내가 하루 놀면 회사 매출이 하루 분 줄어드는 거라 타격이 크다.</p>
<p>미팅 비용을 따로 받을까 하는 생각도 안해본 건 아닌데, 그건 오라고 하는 것보다 더 받아들일 가능성이 적을 것 같다. 그래서 날 찾아 오는 고객만 만나고, 내가 가야하는 경우는 그냥 거절한다. 찾아오는 것도 되도록 찾아오기 전에 내 조건을 먼저 이야기하고 그걸 받아들일 생각이 있을 때만 찾아오라고 한다. 처음에는 무작정 만나자고 하는 사람들을 다 만났는데, 그러다보니 미팅에서 이야기하다가 내가 조건 이야기하면 바로 거기서 미팅 종료가 되는 경우를 몇 번 겪었다. 그래서 그 뒤로는 서로 시간 낭비를 줄이고자 조건을 먼저 이야기한다.</p>
<h4>고객을 선별하지 않는다</h4>
<p>앞서 이콜레모 외주 실패의 역사에서 보듯, 이전에는 이콜레모가 좋은 고객을 선별해 내기 위해 많은 노력을 기울였었다. 근데 지금에 와서 </p>
<p> </p>
<p>