일기장/2010-05-16

지난 글에 이어서, 이번에는 이콜레모의 고객에 대한 관점을 이야기해보고자 한다. 애자일에서 가장 중요하게 이야기하는 것이 바로 고객이기도 하다. 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순위인 경우가 많다. 아직 그런 차이를 구분할 안목이 없는 것이다. 그래도 이 문제는 해결책이 조금씩 보이고 있다.

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

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