올해 초, 3개월이란 시간을 벌면서 이콜레모는 자체 서비스에 올인했다. 3개월 간 자체 서비스에만 집중해보자는 전략. 목표도 세웠다. 아이폰앱 6개, 안드로이드앱 1개 런칭. 하지만 아이폰앱 1개, 안드로이드앱 1개 런칭 후 괜찮은 아이템을 발견하면서 프로젝트를 좀 키웠다. 3개월에 6개가 나오려면 1개월에 2개를 만들어야 하는데 두번째 아이폰앱을 하면서 좀 비전이 있다고 보고 프로젝트를 키웠다. 그래서 2개월 간 진행을 했는데 결과적으로 런칭 실패. 앱과 웹이 연동이 되어야 하는데 프로토타입까지는 금방 되었지만 실제 서비스 수준으로 올리기까지는 난관이 많았다. 결국 이 프로젝트는 보류하고 전략을 전환했다.
물론, 3개월이라는 시간을 다 썼기 때문이기도 하지만, 전략을 바꾸고 프로젝트를 보류한 것이 꼭 그 때문만은 아니었다. 그보다, 이콜레모의 파워가 아직 이 정도의 서비스를 하기에는 부족하다는 생각이 들었기 때문이다. 이건 그냥 느낌이지만, 서비스가 성공하려면 좋은 서비스를 만들어내는 것만으로는 부족하다. 사용자의 니즈 변화와 경쟁자의 추격에 대응할 수 있는 스피드가 필요하다. 지금 이콜레모의 힘으로 이 프로젝트를 완성은 할 수 있겠지만 시장이 요구하는 속도에 맞출 수 있을 것이라는 자신감이 들지 않았다. 뭐 딱히 합리적지도 않고 명확한 이유도 아니지만 그냥 그런 느낌에 프로젝트를 더 이상 하는 것이 좋은 전략이 아니라는 생각이 들었다. 지금까지는 이콜레모에게 가장 필요한 것이 시장에 이콜레모를 세우는 일이라고 생각했는데, 그게 아니었다. 이콜레모에게 지금 필요한 것은 시장에 설 수 있는 힘을 기르는 것이다. 스타트업이 시장에 나가려면 한 500 정도의 파워가 필요하다면, 이콜레모는 현재 150 정도? 이 500 정도는 넘어야 뭐가 되었든 실현할 수 있는 힘이 되는 것 같다.
그래서, 전략을 변경했다. 이제 소프트웨어 용역 업체로 변신하기로 했다. 뭐, 이전까지도 딱히 용역 업체가 아니었다고 할 수는 없지만, 전문 용역 업체라기보다, 여러 가지 아이템 중 하나로 소프트웨어 용역 개발을 대해왔다. 다양한 것을 시도해보고 잘 되는 것을 밀어주는 전략의 일환이랄까. 이제 여기서 더 나아가서, 아예 자체 서비스는 제외하기로 했다. 우린 아직 훌륭한 자체 서비스를 띄울 수 있는 역량이 안된다고 보았기 때문에. 하지만, 고객에게 필요한 소프트웨어를 개발해주는 일이라면 누구보다 잘할 자신 있다. 그렇다면 이걸 우리의 경쟁력으로 삼아야 하지 않겠는가.
물론 여기는 레드오션이다. 하지만, 난 모든 사람이 레드오션이라고 말하는 시장에서도 블루오션을 만들어낼 수 있다고 본다. 특히나 소프트웨어 용역 시장은 불신이 팽배해 있고, 이것은 우리 같은 업체에겐 블루오션의 기회가 있다는 것이다. 블루오션 전략은 기존 제품에서 당연하다고 생각하는 것들을 빼서 비용을 줄이고 그 비용을 새로운 장점을 추가하는데 쓰는 것. 그렇다면 기존의 소프트웨어 용역 업체들은 어떻게 하고 있으며, 우리는 어떻게 차별화할 것인가.
우선, 일반적인 중소 소프트웨어 용역 업체는 영업에 많은 비용을 쓴다. 사장의 가장 큰 업무는 계약을 따오는 것이다. 그리고 주로 대기업의 하청으로 들어가기 위해 노력한다. 하지만 우린 이럴 사치를 부릴 여유도 없고, 그럴 생각도 없고, 그렇게 한다고 해서 대기업 하청으로 들어갈 수 있는 것도 아니다. 그래서 이런 일에는 시간을 쓰지 않는다. 작더라도 들어오는 일 위주로 하고, 중소 비즈니스를 노린다.
또, 기존 업체는 프로젝트 범위를 줄이기 위해 많은 노력을 기울인다. 그래서, 뭔가가 구현이 어렵다는 것을 증명하기 위해 시간을 쓰기도 하고, 협상에 많은 시간을 낭비한다. 우리는 그 대신, AgileScope를 제시한다. 완료 2주 전까지 고객의 변경 요구를 수용하겠다고 약속하되, 그 대신 완료 시점에 출시하는 제품의 범위는 변동 가능함을 주지시킨다. 이게 잘되면 고객과 줄다리기를 해야 하는 일이 사라지고, 매주 제품을 보여주고 사용자의 니즈를 어떻게 반영할지만 고민하면 된다. 사실, 이런 차원에서 보면 투입 인력 MM 단위로 프로젝트 금액을 산정하는 것이 합리적이라는 생각도 든다. 이 이야기는 또 다음 기회에...
용역 업체의 가장 큰 문제 중 하나는 인력 유동성이다. utilization이라고 표현하기도 하는데, 프로젝트의 크기와 회사의 맨파워가 늘 일치하는 것이 아니기 때문에 회사의 맨파워로 할 수 없는 일을 거절하면 굶게 되고, 따게 되면 추가로 인력을 뽑아야 한다. 그런데 인력을 뽑았다가 일거리가 줄면 또 굶게 된다. 이것이 용역 업체의 딜레마고, 그래서 용역 업체는 다수의 프리랜서를 쓰게 된다. 하지만, 프리랜서를 쓰게 되면 늘 발생하는 문제는, 프로젝트를 수행하기에 충분한 실력이 안되는 사람을 뽑을 위험이 높다는 것이다. 또, 용역 업체의 상당수가 사장이 개발자가 아니고 개발자 출신이라 개발자들의 실력을 제대로 평가하지 못한다. 하지만 우리는 모두 개발자들인 만큼, 테스트를 통해서 개발자의 실력을 가늠할 수 있다. 그래서, 테스트를 통해서 검증된 개발자만 프리랜서로 고용해서 불확실성의 비용을 줄인다. 그래도 여전히 유동성의 문제는 해결하지 못하지만, 최소한 비용은 비용대로 쓰면서 프로젝트는 완료하지 못하는 사태는 막을 수 있다.
이렇게 줄인 비용을 투자하는 곳은 사용자를 만족시키는 일이다. 사실 용역 프로젝트에서 고객이 사용자면 참 좋은데, 그런 경우는 거의 없다. 대개는 고객과 사용자의 거리가 멀다. 또 하나 심각한 것은, 고객이 사용자와 거리가 먼대도 자기는 사용자를 잘 안다고 생각하는 것이다. 이럴 때 그 간극을 좁히는 역할을 우리가 하는 것이다. 뭐, 방법은 간단하다. 자주 릴리스하고 실사용자가 테스트해볼 수 있도록 유도하는 것.
한 마디로 요약하면 애자일이라고 할 수도 있겠다. 말하자면, 애자일 소프트웨어 개발 전문 용역 업체가 새로운 이콜레모의 전략이다.
첫 삽은 그런대로 잘 떴다. 단계를 따지자면 우리가 병으로 들어가는 프로젝트인데, 개발은 전적으로 우리가 맡기로 했고, 제안서를 내는 단계부터 참여했는데, 을이 작성한 표준적인(?) 제안서를 내면서 옵션 제안서로 애자일 방법론을 첨부했다. 제안서를 놓고 회의하면서 표준 제안서를 택하면 을의 대표가 PM을 맡고, 애자일 제안서를 택하면 내가 PM을 맡는다고 알려줬는데, 의외로 고객이 애자일 방법론을 선택했다. 사실 이 프로젝트는 을 대표의 역량 덕분에 이루어진 프로젝트이고 그 분에 대한 고객들의 신뢰도 아주 높은 상황이었다. 심지어 초기에 고객의 요구 중에 을의 대표가 PM을 한다는 조건도 있었는데, 그런대도 잘 모르는 나를 PM으로 선택하는 위험을 지면서 애자일 방법론을 택한 것이다. 역시 고객은 애자일을 원한다.
하지만, 사실 이 프로젝트가 성공적으로 끝날 가능성이 그렇게 높진 않다. 골치 아픈 일도 많고, 프로젝트 관련자들이 나랑 일하는 스타일이 좀 맞지 않는 부분이 많다. 그래서, 좀 두렵기도 하다. 하지만, 우리가 이 정도 프로젝트도 제대로 못해낸다면 아마 사업할 자격이 없는 것일 터. 이번에 이콜레모의 능력이 진짜로 시험대에 오르는 것이다.
3개월 후, xper에 애자일 성공 사례로 자랑할 수 있었으면 좋겠다.