오랫동안 글을 못 썼다. 못 쓴 이유는 조금 어이없는 이유인데, 서버 업데이트를 하고 났더니 MoinMoin이 업데이트가 되면서 한글 이름의 페이지명과 계정 인식에 문제가 생겨서 글쓰기 권한이 안 생겼기 때문-_- 내 블로그인데 내가 권한이 없어서 못 쓰는 어처구니 없는 사태가 생겼는데 며칠 전에 그냥 영문 아이디 등록하고 어드민 계정을 이걸로 바꿔버렸다. 이제 MoinMoin 갖다 버릴 때가 되어가나보다. dokuwiki 조금 써보니까 편한데 이걸로 바꿀까. 아님 깊이 묻어둔 개인 위키 프로젝트를 끄집어내서 완성시켜버릴까.

글 쓰고 싶을 때가 지나가버려서 그런지 이제 쓰고 싶은 내용은 워3 전략 밖에 안 떠오른다. 그래서 조금 정리해보기로...

나는 일을 대할 때 처음에는 아주 긍정적인 모드로 대하는 경향이 있다. 자세한 이야기를 듣기 전에는 일단 상대방이 신의를 지킬 것이라고 가정하고, 프로젝트도 재미있을 것이라고 본다. 딱히 의식적으로 그러는 건 아닌데 그냥 그렇게 되는 거 같다. 남들이 악평을 하는 프로젝트라도 내가 하면 잘할 수 있다고 생각하는 경우도 많고. 이런 태도가 새로운 프로젝트를 시작할 때 도움이 되긴 한데, 반대로 프로젝트 시작하자마자 후회하는 경우도 많다. 그럴 때마다 왜 처음부터 몰랐을까 한탄하곤 한다. 프로젝트 시작하기 전에는 고개들이 다들 "함께 좋은 제품을 만들어봐요" 모드로 이야기를 하지만 정작 프로젝트가 시작하면 "우리가 갑인데 시키는대로 해"식으로 돌변하는 고객들. 어떻게 하면 이런 고객들을 미리 분간해낼 수 있을까?

어느 정도 짚이는 현상은 있다. 대체로 나이가 많을수록, SI 프로젝트 경험이 많을수록 갑 놀이를 좋아한다. 아마도, "을한테는 이렇게 해야 먹힌다" 같은 신념이 있는 듯하다. 부하 직원들을 대하는 태도도 상관 관계가 있다. 들어야 할 자리에서 말을 하려고 하는 사람도 대체로 갑 놀이파다. 하지만, 사실 이런 경향성은 별 도움이 안된다. 오히려 함께 프로젝트를 하려는 마인드가 있는 사람을 가려내는 방법이 있어야 하는데, 이런 고객은 워낙 만나본 경험이 적어서 어렵다.

어쨋든, 내가 이런 갑 놀이를 견딜 수 없다면 소프트웨어 용역 전문 업체라는 전략도 나한테 잘 맞는 전략은 아닌 것 같다. 일단 이번 프로젝트가 그걸 시험해보는 계기로는 좋은 것 같다. 사실 이콜레모의 외주 프로젝트 경험에는 지금 정도의 갑 놀이파가 없었다. 굳이 따지자면 C&C는 지금보다 훨씬 더한 막가파식이었지만 다행히 우리와 C&C 사이에 중간 업체가 끼어 있었고, 지금처럼 우리가 갑 놀이에 직접 노출되지는 않았다. 8년 전에 SI할 때는 직접 갑 놀이에 노출되긴 했지만, 위에 팀장과 부장이 잘 막아줘서 나한테 압박이 직접 오진 않았고. 그렇다면 내가 갑 놀이를 봐줄 수 있는지 아닌지를 노골적으로 경험해보는 건 처음인 것 같다. 과연 내가 그런 걸 참아낼 수 있을까.

거참 뭐 하나 쉬운 일이 없나보다.

지난 글에 이어서, 이번에는 이콜레모의 고객에 대한 관점을 이야기해보고자 한다. 애자일에서 가장 중요하게 이야기하는 것이 바로 고객이기도 하다. XP에서는 OnSiteCustomer로 이야기하던 프랙티스다. 프로젝트할 때 Customer를 옆에 두라는 것. 그래서 Customer와 긴밀하게 소통해야 Customer를 만족시켜줄 수 있다는 것이다. 그런데, 이 단어가 고객으로 번역되면서 문제가 생겼다. SI에서 고객은 Client를 가리키는 말이기 때문이다. 그리고 한국에서의 소프트웨어 프로젝트는 대개 Customer보다 Client를 만족시키는 걸 목표로 진행되기 때문에 결국 별로 의미 없는 프랙티스가 될 위험성이 있다. 그나마, XP explained 2판에서 RealCustomerInvolvement로 좀더 명확하게 한 것이 다행이기는 하다. 어쨌든, 어차피 우리나라 SI에서 고객 = 클라이언트인 상황에서 내가 그 말의 의미를 바꿀 수는 없고, 대신 customer를 소비자로 번역하기로 했다. 고객은 우리에게 일을 의뢰하는 사람, 곧, 돈을 지불하는 사람이고, 소비자는 우리가 만든 소프트웨어를 실제로 사용하는 사람이다. 애자일 방법론에서 이야기하는 customer는 고객보다 소비자에 가깝고, 또 그래야 한다. 그리고 내가 애자일 방법론을 통해서 하려는 것 역시 소비자의 참여를 통해서 소비자를 만족시키는 것이다.

만약에 고객도 소비자의 만족을 중시한다면 이상적이고, 프로젝트는 항상 좋은 결과물을 만들어낼 것이다. 하지만, 불행히도 이렇게 개발사, 고객, 소비자의 관심사가 일치하는 경우는 거의 존재하지 않는다. 얼마 전 애자일 프랙티스 세미나에서 내가 고객은 항상 우리편이라고 말하니까 SI 대기업에서 나온 두 분이 극렬하게 반대하면서 고객은 악이라고 했는데, 이런 관점에서는 그 말에도 동의한다. 고객이 애자일을 좋아한다는 점에서는 우리 편이지만, 소비자에게 유용한 소프트웨어를 만드는 관점에서는 적이나 마찬가지다. 가끔은 고객이 소비자를 만족시키려는 것을 기를 쓰고 막는 것처럼 보이기도 한다. 그러니 소비자의 만족을 위해 애자일을 하려는 사람들에게는 고객이 악으로 보이는 것도 당연하다.

그럼 왜 이런 일이 일어날까? 원론적으로 따지면 소비자가 만족하는 게 고객에게도 당연히 유리하고, 고객에게 직접 말로 물어보면 당연히 사용자를 만족시켜야 하는 거라고 대답한다. 그리고, 자기는 정말로 소비자를 위한다고 믿는 고객도 많다. 그렇지만 정말 소비자를 위하는 방향으로 프로젝트를 끌고 가는 고객은 거의 없다. 그 이유는 뭘까? 아쉽게도 이 문제를 꿰뚫을 만한 핵심적인 이유를 발견하지는 못했다. 대신, 몇 가지 원인은 발견했는데, 이런 것이다.

이유 1번, 고객과 소비자는 다른 사람이고 고객이 소비자를 이해한다는 것은 바꿔 말하면 다른 사람을 이해하는 것이다. 그런데, 다른 사람을 이해할 수 있는 사람은 흔치 않다. 자기 외의 다른 사람을 이해한다는 것 자체가 아주 어려운 일이라는 것이다.

이유 2번, 소비자의 이해 관계가 고객의 이해 관계로 나타나기까지의 거리가 먼 경우. 이를테면, 최근에 한 프로젝트 중에 안드로이드 VoIP폰을 만드는 프로젝트가 있었는데, 그 회사는 폰을 KT에 납품하는 것이 목표였다. KT는 기업용 인터넷 전화 상품을 팔면서 끼워주는 형태로 폰을 팔게 되는 것이고. 이런 경우, 사용자의 만족도는 KT의 서비스 품질과 폰의 만족도가 결합되어서 나타나기 때문에 일차적으로 폰의 만족도가 KT의 이해 관계에 미치는 영향이 절반이 된다. 그리고, 또 이 만족도가 너무 낮거나 하지만 않으면 KT는 지속적으로 이 제품을 구매할 것이기 때문에 납품 회사 입장에서는 소비자의 만족도보다 KT에 잘 보이는 것이 더 중요하다. 그렇다면 이 회사의 이해 관계는 소비자의 만족도보다 KT에서 제품을 평가하는 담당자에 더 많이 좌우된다. 그러면 자연스럽게 소비자의 만족도에는 신경 쓸 여유가 없다.

비슷한 경우로, 관공서 프로젝트는 주로 발주하는 부서와 사용하는 부서가 분리되어 있다. 그리고 프로젝트의 평가는 주로 고위 관리가 한다. 그러니 실제로 제품을 사용할 실무자를 만족시키는 것보다 고위 관리를 만족시키는 것이 더 중요해진다. 그래서 관공서 프로젝트의 소프트웨어를 보면 보고 화면이 상당히 비중이 크고, 또 안 쓰는 소프트웨어가 상당히 많다. 내가 9년 전에 프로젝트할 때 들은 이야기로, 서울시청에 들어가 있는 시스템이 1만 개가 넘는다고 했다. 당시에는 상당히 충격적인 이야기로 받아들였지만, 좀 지나고 보니 사실 그 때 내가 하던 프로젝트도 불과 3~4명이 쓰는 소프트웨어인데 이미 같은 목적의 소프트웨어가 3개가 개발되어서 설치되어 있었는데 실무자들이 안 써서 다시 발주한 프로젝트였다. 그리고, 내가 만든 프로젝트도 성공 사례로 평가되서 장관한테 보고도 되고 대규모 교육까지 해가면서 전국의 동종 부서로 확산시켰는데, 결국 실무자들은 아무도 쓰지 않았다. 사실 이 사건이 내가 애자일에 관심을 갖게 된 계기이기도 하다.

이유 3번, 고객이 소비자를 이미 알고 있다고 생각하는 경우. 이것은 용역 프로젝트 뿐 아니라 기업 내의 프로젝트에도 발생하는 현상이다. 이 분야에서 많은 경험을 가진 고객은 대개 자신이 소비자를 잘 이해한다고 생각하고, 자신의 직관이 곧 소비자의 니즈라고 생각한다. 이런 경우는 그 직관을 반증하는 증거가 눈 앞에 있어도 소용이 없다. 이 오류는 고객 뿐 아니라 개발사도 많이 저지른다.

나는 이유 1번은 어쩔 수 없다 해도 이유 2번과 이유 3번은 피할 수는 있다고 생각했다. 그런 고객이랑은 일 안 하면 된다. 소비자에 대해서 겸손한 자세를 갖추고 있고, 소비자를 만족시키려는 의지가 높은 고객이랑만 일하면 된다. 이런 경우라면 난 소비자를 만족시킬 자신이 있다. 창업 이전까지 포함한 내 경력 전체를 고려하면 크고 작은 프로젝트를 40여 개 했는데 이 중에서 내가 소비자가 높은 수준으로 만족한다는 피드백을 받은 것은 대략 6건 정도다. 이 6건은 모두 실제 사용자와 긴밀하게 소통할 수 있었다. 사용자와 긴밀하게 소통하면서도 실패한 경우도 한 건 있긴 하지만, 6:1의 확률이면 괜찮은 확률 아닌가. 그래서, 난 지금도 소비자와의 소통을 열어주고 나에게 결정권을 준다면 난 소비자를 만족시킬 수 있다고 호언하고 다닌다.

하지만, 여기에는 치명적인 문제가 있다. 저 6건 중에서 소프트웨어 용역은 1건 뿐이다. 5건은 모두 사내 시스템이었고, 소비자는 사내의 다른 부서 직원들이었다. 그리고, 우리가 지난 2년 간 수행한 용역과 내가 사회 초년병 때 했던 프로젝트를 합치면 15건 가량 되는데 그 중에 소비자와의 긴밀한 소통이 가능한 프로젝트도 단 한 건이었다. 이래서는 우리의 전략 변화, 곧, 소프트웨어 용역 전문 업체로의 전환을 감당할 만큼의 프로젝트를 수주할 수 없다. A급 고객만 찾기에는 시장이 너무 작은 것이다. 결국 B급 고객을 소화하지 못한다면 소프트웨어 용역 업체로서의 존재 의미는 없다.

그래서, 난 이유 2번과 3번도, 기피할 대상보다는 극복할 대상으로 보고 싶다. 이런 걸 해내야 혁신이라고 부를 수 있지 않겠는가. 물론, 2번과 3번을 극복하지 않고 그냥 수용할 수도 있다. 대신 소비자의 만족을 포기하면 된다. 그래도 고객은 만족시킬 수 있고, 프로젝트를 제 때 완료하고 돈 받는 데는 지장이 없을 것이다. 후속 프로젝트도 얼마든지 따낼 만큼의 관계를 만들 수 있을 것이다. 하지만, 그러면 다른 회사랑 다를 게 무엇인가. 그렇게 한다면 사업하는 의미가 없다. 나는 소비자를 만족시킬 때 가장 보람을 느낀다.

하지만 사실 이유 2번에 대한 답은 아직 모른다. 그래서, 여전히 2번의 경우는 프로젝트를 거절한다. 관심 자체가 다른 데 가 있다면 어떻게 하기 어렵다. 대신, 3번은 방법이 있다고 생각한다. 그 방법은 지난 글에서 이야기한 바 있는 애자일이다. 자주 릴리스하고 피드백을 받아서 소비자의 반응을 고객이 실제로 느끼도록 유도하는 것이다. 굳이 고객과 논쟁을 벌일 필요는 없다. 일단 고객이 해달라는 것을 기준으로 기획하고 개발해주고 소비자의 반응을 잘 느낄 수 있게 환경을 조성하면 된다. 그러면 고객도 결국 소비자를 이해하게 될 가능성이 높아질 것이다. 그리고, 이 과정을 통해서 우리 역시 같은 오류를 피할 수 있다.

하지만, 사실 이것도 허점은 있다. 사람은 대개 자신이 뭔가 깨달음을 얻어서 뭔가 이론을 세웠다고 생각하면 그 이론을 완전히 뒤집는 증거가 눈앞에 있어도 어떻게든 자기 이론을 합리화시키기 때문이다. 물론 이것도 고객과 개발사 모두 해당된다. 소비자는 계속 No라고 말하고 있는데 고객은 Yes로 이해하는 것이다. 특히, 소비자의 반응에 대한 해석이 고객과 개발사가 다를 때 문제가 된다. 그 때는 소비자를 이해한 경험이 많은 쪽의 해석이 옳을 가능성이 높고, 보통은 개발사가 그런 경험이 많지만, 주도권은 고객이 쥐기 때문에 결론은 고객이 해석한 방향으로 나게 된다. 이것이 애자일 소프트웨어 용역 업체라는 전략의 가장 큰 허점인데, 현실에선 이 허점의 크기가 상당히 크다. 아직은 해법의 초안조차 없는 상태다. 우리 전략의 가장 큰 도전 과제가 될 것이다.

뭐 어쨌든, 이것은 피할 대상까지는 아니고, 도전해야 할 부분이다. 그래서 이콜레모가 수주하는 프로젝트의 기준은 이렇게 정리할 수 있다.

• 1순위. 소비자를 만족시키려는 의지가 높고, 스스로의 의견보다 소비자의 반응을 중요하게 여기는 고객
• 2순위. 소비자를 만족시키려는 의지는 높지만 소비자를 잘 알고 있다고 생각하는 고객
• 3순위. 소비자에게 별 관심이 없고, 우리가 하려는 대로 내버려두는 고객
• 4순위. 소비자에게 관심이 없는데 자신은 만족시켜주기를 바라는 고객
• 5순위. 을은 갑이 명령한 대로 따라야 한다고 생각하는 고객

1순위는 비용과 상관 없이 우선적으로 수주한다. 2순위는 비용이 맞으면 수주하지만 비용이 안 맞으면 다른 프로젝트와 저울질한다. 3순위는 상황에 따라 판단한다. 4순위 이하는 우리의 실력이 소화할 수 있게 되기 전까지는 수주하지 않는다.

혹자는, 사업을 하면서 고객을 가려서는 안 되는 거 아니냐고 한다. 물론, 그렇게 생각할 수도 있지만, 그건 성공과는 상관 없는 철학의 문제다. 고객을 가리지 말자는 철학이 있을 수 있고, 그런 기업 이념도 좋은 이념이라고 생각하지만, 그렇지 않은 기업 이념도 좋은 이념일 수 있다. HP에서는 고객이 3순위이고, 애플도 고객을 가리는 회사다. 은행 대출은 고객을 안 가리는가? SI 대기업들도 일을 가린다. 가리는 기준이 비용일 뿐. 비용으로 가리는 것보야 우리가 높은 성과를 낼 수 있느냐 아니냐로 가리는 것이 훨씬 합리적이지 않겠는가. 그래서 우리는 고객을 보고 프로젝트를 결정한다.

애자일 프랙티스 세미나에서는 상황상 설명을 길게 할 상황이 아니라서, "그럼 을로만 프로젝트를 하겠다는 것이냐"라는 질문에 그렇다고 대답했는데, 그걸 길게 풀어서 설명하면 이런 의미인 것이다. 결국 중요한 것은 소비자 지향적인 프로젝트가 되어야 우리가 성과를 낼 수 있기 때문에 그런 프로젝트를 중심으로 하겠다는 것이다.

다만, 여기에 또 하나의 문제가 있다. 프로젝트를 실제 진행해보기 전까지는 1순위와 2순위를 구분하기가 참 어렵다는 것이다. 나는 사람을 처음 대할 때는 긍정적인 편이라 대부분 1순위로 느끼고 시작하는데, 시작하고 나서 보면 2순위인 경우가 많다. 아직 그런 차이를 구분할 안목이 없는 것이다. 그래도 이 문제는 해결책이 조금씩 보이고 있다.

아직 풀지 못한 숙제는 많지만, 충분히 도전해볼 만한 상황인 것 같다. 다행히, 아이폰이라는 변수가 이런 전략 변화를 어느 정도 지지해주고 있기도 하고.

다음 번에는 소비자의 피드백을 어떻게 얻어내고 활용할 것인가에 대한 생각을 정리해볼 것이다.

올해 초, 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에 애자일 성공 사례로 자랑할 수 있었으면 좋겠다.