Talk about Software with hani

베이징 726번 시내버스 승객들은 이 소녀가 목졸려죽는걸 구경만 했다 (조선일보 기사 링크)

엊그제 각종 포탈 사이트의 Headline을 장식했던 중국에서 일어난 한 소녀의 죽음에 관한 기사입니다. 이 기사에 붙은 댓글은 중국에 대한 감정석인 비난과 중국은 아직까지 후진국이라는 식이 대부분입니다. 추측이지만 이 기사를 Headline으로 올린 조선일보의 의도 또한 중국의 후진성을 부각시키려 하지 않았나 싶네요. 얼마전에 일어난 기생충 김치부터 납 조기, 납 꽃개, 중국산 저가 제품, 저질 식료품 이 모든 것들이 우리나라 사람들이 가지고 있는 중국에 대한 인식의 한 모습이라 생각합니다. 이런 중국의 모습을 애써 부인하고 싶지는 않지만, 이런 부정적인 견해를 형성하게 된 대에는 우리의 책임 또한 있다고 생각합니다. 그 이야기는 다음 기회로 미루고 오늘은 어린 소녀의 죽음에 관해서 이야기 해 보도록 하겠습니다.

이 기사를 읽은 대부분의 사람들은 이런 황당한 일은 중국이니까 가능하다고 생각했을지 모릅니다. 하지만 중국 소녀의 죽음은 중국이라는 사회의 특수성에 기인한 것일까요? 본격적인 논의를 진행하기 전에 몇 십년 전의 또 다른 사건부터 살펴 보도록 하죠.

사건이 벌어진 것은 1964년 3월 13일 금요일, 그러니까 실제로 13일의 금요일이었다. 뉴욕 주 퀸스 지역의 이른 새벽 공기는 춥고 축축했다. … 그날 새벽에는 흔히 키티라고 불리던 캐서린 제노비스라는 한 여성이 지배인으로 일하던 술집에서 야간 당번을 마치고 귀가하던 중이었다. … 그녀가 주차장 안에 차를 주차시키고 밖으로 걸어나왔을 때가 새벽 3시였다. 그녀는 아파트 건물을 향하여 발걸음을 떼자마자 수장쩍어 보이는 덩치 큰 남자를 보았다. … 모즐리라고 신원이 밝혀진 남자가 그녀의 등에 칼을 깊숙이 찔렀던 것이다. … 그녀가 분명한 소리로 외쳤다. “어머 세상에, 이 남자가 칼로 날 찔렀어요! 도와주세요! 도와주세요!” 그러자 동네 사람들 집에 불이 켜졌다. … 그의 법정 진술에 따르면, 집집마다 불이 켜지기 시작했지만 사람들이 계단 아래로 내려올 것 같다는 느낌은 들지 않았다고 했다. 어떤 사람이 아래로 내려오는 대신 ” 그 여자를 내버려 두시오.”라고 소리를 질렀다. 그 때 범인은 그 자리에서 도망을 쳤고, 몸의 여러 군데가 칼에 찔린 제노비스는 몸을 이끌고 어느 서점 문 앞에 가 드러누웠다. 그러자 아파트의 불이 꺼지기 시작했고, 거리는 조용해 졌다. 자신의 자동차가 있는 곳으로 가던 범인은 거리가 조용해지고 창문이 어두워진 것을 보고서 범행을 마저 끝내기로 결심했다. … 그는 칼로 다시 그녀를 난도질 하기 시작했다. … 제노비스는 다시 소리를 지르고 또 질렀다. … 아파트에서 다시 불이 켜지기 시작했다. … 모즐리는 다시 도망갔고 … 제노비스는 간신히 몸을 이끌고 자신의 집이 있는 아파트 건물 복도 안으로 비틀거리며 걸어갔다. 하지만 몇 분 후에 또다시 모즐리가 찾아와 작업을 끝내기 시작했다. … 살인 사건은 새벽 3시 15분에서 50분까지 약 35분 동안 일어났다. 세 차례에 걸쳐 연속적으로 벌어진 이 사건은 도움을 청하는 비명에 중간 중간에 끊겼다. … 한 여성이 칼에 찔리고 쓰러지는 것을 창가에서 구경만 한 사람들은 모두 38명이었다. … < 뉴욕 타임즈> 지에서 이 방관자들의 기이한 행동을 시리즈 형태로 연속해서 보도하자 온 나라가 도덕성 문제로 들썩거렸다. … 교수의 부인이라고 밝힌 한 여성은 다음과 같이 썼다. “… 38명의 증인에 대해서는 그들이 마땅히 느껴야 할 도덕적 책임을 인식하지 못한 대가로 < 뉴욕 타임즈> 지 1면에 그 이름과 주소가 전원 공개되어야 한다.” source from 로렌 슬레이터의 “스키너의 심리상자 열기”

시간과 장소만 다를 뿐이지, 두 살인 사건은 닮은 꼴임을 알 수 있습니다. 그렇다면 중국에서 일어난 어처구니가 없는 소녀의 죽음은 단순한 중국 사회의 문제만은 아님을 알 수 있습니다. 여기서 우리가 주목해야 할 점은 살인 사건과 그 살인 사건이 일어난 사회적 환경이 아니라, 살인 사건을 목격한 군중들의 반응입니다. 사건을 글로써 접하는 사람들은 그 사건의 목격자들의 양심의 부재와 그 사회의 추락한 사회적 연대 의식을 비난합니다. 하지만 이 사건들은 단순한 윤리와 사회 문제로 국한시키기에는 석연치 않은 점이 있습니다.

제노비스 살인 사건을 접한 뉴욕 대학의 존 달리와 컬럼비아 대학의 빕 라타네는 정교한 심리 실험을 통해서 이 사건의 본질을 밝혔습니다. 그들은 이러한 사건들을 “책임감 분산(diffusion of responsibility)”이라고 불렀습니다. 사람들 속에서는 책임감이 공평하게 나누어지기 때문에, 어떤 사건을 목격한 사람들이 많을수록 개인이 느끼는 책임감이 분산된다고 합니다. 따라서 개인이 위험에 처해 있을 때에는, 대도시 같은 사람들이 많은 곳보다는 사막에서 동료와 함께 있을 때 도움을 받을 확률이 높다고 합니다. 또한 사건의 다른 측면은 그 비상 상태가 실제 상황인지 거짓인지를 구분하는 것도 문제가 된다고 합니다. 제노비스의 살인 사건을 목격한 사람들 중에는 둘을 연인 사이로 오해를 하거나, 실제 벌어지는 사태가 정확히 어떤 상황인지도 구분할 수 없었다고 합니다. 즉 사람들은 대중 앞에서 바보가 되는 것을 극도로 꺼려하기 때문에 자신의 눈으로 직접 본 것 조차도 의심한다고 합니다. 따라서 개인은 많은 사람들과 목격한 현상을 스스로 판단하기 보다는 군중의 반응에 편승할려고 한다는군요.

달리와 라타네의 방관자 효과에 기초해서, 구성애氏가 여성들에게 말했던 성폭력 대처 방법이 생각나는군요. 어두운 골목길에서 성폭력 위기에 처하게 되면 비명으로 구조요청을 하기 보다는 땅에 떨어진 돌을 집어서 불이 켜져 있는 집의 창문을 깨라고 하더군요. 즉 사람들은 군중 속에 위험에 처해 있는 타인보다는 자신의 재산이 망가지는데 더 즉각적인 조치를 취하기 때문이겠죠.

우리 나라 국민의 중국에 대한 부정적인 인식과 더불어 특정 목적에 맞추어져 쓰여진 중국 소녀 죽음에 관한 기사는 온라인을 달아 오르게 했습니다. 그러나 중국 소녀 죽음의 본질은 아쉽게도(?) 중국 사회의 특수성에 기인한 것이 아니라, 군중 속에서 보이는 개인의 어리석음에 있음을 알 수 있습니다. 인간은 군중 속에서 한없이 어리석어 지는 것일까요? 만일 그렇다면 대도시에 사는 이들은 자신에게 군중 속에서는 절대 위기의 순간이 생기지 않기만을 바래야 할까요?하지만 다행스럽게도 달리와 라타네는 사회적인 교육을 통해 이 문제를 해결할 수 있다고 합니다. 이런 교육의 단계는 다음의 5단계로 나눌 수 있다고 합니다.

1. 사건의 목격 단계. 도움을 줄 사람은 사건을 목격해야 한다.
2. 도움의 인식 단계. 도움을 줄 사람은 그 사건에 도움이 필요하다고 해석해야 한다.
3. 책임 인식 단계. 도움을 줄 사람은 개인적인 책임 의식을 느껴야 한다.
4. 행동 결정 단계. 도움을 줄 사람은 취해야 할 행동을 결정해야 한다.
5. 행동 단계. 도움을 줄 사람은 이제 행동을 취해야 한다.

S/W 개발 이이야기로 넘어 가도록 하겠습니다. 군중 속의 방관자 효과는 S/W 개발 프로젝트에서도 찾아볼 수 있습니다. 즉 프로젝트 규모가 커지면서, 나타내는 현상으로 품질에 대한 책임감 분산 효과라 할 수 있습니다. 특히 개발 품질을 관리하는 프로세스와 전문적인 테스트 팀과 품질 관리 팀이 없는 경우에는 책임감 분산 효과는 극적으로 나타납니다. 개발이 진행되면서 PL은 고객 관리, 일정 관리와 개발 관리로 품질은 개발자가 알아서 챙길 것이라 생각합니다. 반대로 개발자들은 자신이 맡은 모듈에만 정신이 팔려서 품질은 PL이나 다른 누군가가 챙겨줄 것으로 생각합니다. 고객 또한 품질은 프로젝트 팀이 알아서 처리할 문제라 생각하기 때문에 품질은 관심영역이 아닙니다. 이 때부터 품질에 관한 책임감 분산 효과가 발생합니다. S/W 품질은 빈사 상태에 몰려, 구조의 외침을 외쳐 보지만 PL, 개발자, 고객 모두 자신의 책임은 아니라 생각합니다. 결국 S/W 품질이 사망 선고 받은 순간 PL, 개발자, 고객 모두는 서로를 쳐다 보며 서로의 책임이었다고 비난하기 시작합니다.

S/W 품질은 생명이 아니기 때문에 사망 선고를 받은 순간부터 노력하면 어느 정도 회복이 가능합니다. 그러나 이때 소요되는 품질 비용은 프로젝트 전체 비용을 초과할 수도 있습니다. 이런 추가적인 품질 비용을 막을 수 있는 방법은 없을까요? 달리와 라타네가 제시한 교육의 5단계를 통해서 어느 정도 해결할 수 있습니다. 다소 도식적이지만 5단계로 구분하면 다음과 같습니다.

1. 사건의 목격 단계. 품질 상태를 판별할 수 있는 도구를 도입한다. 도구의 간단한 예로 버그 리포트를 작성하거나, 위험관리 항목으로 품질 요소를 추가해 품질 문제를 예견할 수 있는 전이 지표를 만든다.
2. 도움의 인식 단계. 버그 리포트와 위험관리 항목의 품질 관련 전이 지표를 지속적으로 모니터링한다.
3. 책임 인식 단계. 2단계에서 품질 문제가 발생하게 되면, 해당 품질 문제에 대한 책임 관계를 명확히 한다. 예를 들어 개발자의 실수에 의해 발생한 문제인지, 개발 Spec. 변경에 따른 품질 문제인지를 명확히 판단해야 한다.
4. 행동 결정 단계. 해당 품질 문제를 구체적으로 해결하거나, 단순 의사 결정으로 품질 문제를 종결할 수 있는지 관련 담당자들이 협의를 해서 결정한다.
5. 행동 단계. 4 단계에서 구체적인 조치를 취해야 한다고 결론이 난 경우, 해당 품질 문제의 개발자에게는 품질 문제를 해결하도록 하며, PL은 필요한 리소스나 일정 상의 문제를 해결해 주고 고객은 해당 품질 문제 해결 시 필요한 의사 결정 및 이로 인해 발생하는 프로젝트 상의 문제점을 명확히 인식해야 한다.

이런 프로세를 도입하면, 당연히 비용문제가 수반됩니다. 하지만 달리와 라타네가 밝힌 인간 본연의 속성인 군중 속의 방관자 효과로 발생하게 될 문제점보다 다소의 비용을 지불해서라도 더 큰 손해를 막을 수 있다면, 우리는 반드시 이런 노력을 기울여야 하지 않을까요?

마소

자본주의에 공짜 점심은 없답니다. 그런데 오늘 영등포 역을 지나다 토마스의 집이라는 곳을 봤습니다. 큰 간판에 “토마스의 집”이라는 이름과 함께 “무료 점심 제공”이라는 글이 적혀 있더군요. 아니 토마스의 집에서는 공짜로 노숙자들에게 점심을 제공해 준다는데, 자본주의에 공짜 점심이 없다는게 말이 되나요? 이 이야기를 한 사람을(아버지 말고요.) 데려다가 토마스의 집에서 무료 점심을 나눠 주는걸 보여 줘야 하는게 아닐까요?

자 흥분을 가라 앉히고, 저만 흥분하거 같습니다만… “자본주의에 공짜 점심은 없다” 라는 말을 왜 했는지 잠깐 고민해 보죠.

이 말의 참뜻은 공짜로 점심을 먹는 사람 입장이 아니라, 사회 전체로 볼 때 뜻을 알 수 있습니다. 누군가가 기적을 일으켜 공짜 점심이 無에서 나타나지 않는 이상, 공짜 점심을 제공해 주는 재원은 누군가의 주머니에서 나와야 합니다. 여러분이 낸 세금일 수도 있고, 김밥집 할머니의 기부금일 수도 있고요. 아무튼 누군가는 공짜 점심을 만드는 비용을 제공해 주어야 한다는게 이 말의 요점입니다. 따라서 우리 사회 전체로(System 관점) 보았을 때 이 세상엔 공짜 점심이란 있을 수 없답니다.(아버지가 틀리시는 경우는 거의 없더군요.)

연말인데다가 지금 Project Leader를 맡고 있는 프로젝트 마무리 때문에 정신이 없습니다. 사실 프로젝트 완료 시점은 아닌데, 고객 요구로 한 개의 프로젝트에 두번의 Release 계획이 잡혀 있습니다. 두 번의 Release라는 이야기만 들으면, Iterative 방식의 Process라는 생각이 들지도 모릅니다. 총 3개의 모듈 가운데 1개의 모듈을 먼저 개발 완료하고, 2개의 모듈은 내년 4월에 완료할 예정입니다.

그렇다면 2번의 Release라는 표현보다는 2번의 프로젝트 완료라고 말하는게 더 맞겠네요. 올해 12월까지 완료해야 하는 모듈은 제가 고객 요구 분석, 개발 명세서 작성까지 하고, 개발은 Outsourcing 하고 있습니다. 물론 도움말이라던지, 인수 테스트는 제가 담당하고 있습니다.

이번 프로젝트를 통해서 “자본주의에 공짜 점심은 없다”라는 말의 뜻을 새삼 느끼고 있습니다. 보통 우리나라에서는 제안서 작성 업무에 투입된 공수를 청구하지 않는게 일반화된 관행입니다. 따라서 프로젝트 수주 제안 작업을 할 때 많은 공수를 투입하지 않습니다.

대형 SI 프로젝트가 아닌 이상, 많이 잡아 대여섯 번의(이건 진짜 많은 경우입니다. 보통 두 세번, 제 경험 상에는요.) 고객 상담을 한 후 최종적인 제안서가 완성이 됩니다. 물론 많은 경험이 있는 고참 개발자와 영업팀이 협의해서 제안서를 만들지만, 시간적 자원적 한계로 이렇게 만들어진 제안서에는 프로젝트의 최종 이미지와 간단한 시스템 구성도, 대략적인 공수, 프로젝트 완료 기간(대부분 고객이 D-day를 정해 줍니다.) 정도를 담습니다.

이 제안서는 하얀 종이 위에 연필로 아주 기초적인 스케치만 해 놓은 상태입니다. 그릴려는 그림이 어떤 것인지 대략적인 윤곽만 짐작할 뿐 정확한 형상은 알 수 없습니다. 물감을 칠 한다면 얼마나 많은 물감이 필요한 건지, 시간은 얼마나 걸리게 될 건지 알 수가 없습니다. 따라서 소요되는 물감의 양과 시간을 알기 위해서는 밑 그림을 좀 더 자세히 그릴 필요가 있습니다.

하지만 여기에 딜레마가 있습니다. 왜 그런지 정확히 모르겠지만 관행이라고 말하는 것이 정답이 아닐까 합니다. 보통 제안작업이 끝나고 산출된 공수와 기간으로 프로젝트 계약이 완료 됩니다. 그 이후 기간이 조정되거나 금액이 늘어 나는 것은 고객도 용납하지 않을 뿐더러, 설계가 끝난 후 프로젝트를 수행하는 회사 내에서도 금액이 늘어나거나 기간이 늘어 난다고 이야기 하는 것은 절대 금기시 되는거 같습니다. 그런 이야기를 하는 PL이나 개발자들은 무능하거나, 방어적이고 소극적인 사람으로 낙인이 찍히게 되죠.

이 때부터 프로젝트 팀의 토요일과 일요일은 모두 Working day로 설정이 됩니다. 제 경험 상 프로젝트 계획 수립 시 토요일과 일요일을 Working day로 설정하면, 그 프로젝트는 100% delay되더군요. “월화수목금금금”의 계획표를 가진 프로젝트는 꼭 해야할 업무도 뛰어 넘거나 간략히 하고 Coding부터 시작합니다. 밑그림을 제대로 그리지 못한 상태에서 도화지는 크고, 그릴 시간도 없어 무슨 그림을 그릴지 생각하지도 않고, 색부터 칠하는 것처럼요.

결국엔 프로젝트 팀원들은 납기를 맞추기 위해 품질을 떨어뜨리는 전략으로 침묵의 공모를 합니다. 물론 PL도 명시적으로 품질을 떨어뜨리라는 지시는 하지 않지만 암묵적으로 개발자와 공범이 되는 길을 택합니다. 이렇게 해도 결국에 Delay가 되고 품질이 떨어진 제품이 고객에게 전달됩니다.

나비의 날개 짓이 태풍을 일으키는 카오스 이론처럼, 프로젝트 초반의 공짜 제안 작업이 프로젝트의 품질을 저하 시킵니다. 따라서 여기서도 자본주의의 공짜 점심은 없다라는 이야기가 얼추 들어 맞는거 같습니다. 이 문제점에서는 고객, SI 업체, 프로젝트 팀원 어느 누구도 자유로울 수 없습니다. 다만 관행이라고 여겨졌던 일에 목표 달성을 위해, 이제는 의문을 가져야 하는게 아닐까요?

이 문제점의 해결책은 프로젝트 기간을 크게 두 구간으로 나누는 것으로 얻을 수 있습니다. 첫번째 기간에는 제안 작업에 소요되는 비용을 별도로 받고, 실제 고참 설계자가 투입이 되어 고객 요구 분석과 간단한 사용자 인터페이스 설계, 대략적인 아키텍쳐를 구성하는 겁니다. 이 작업이 끝나게 되면 대략적으로 소요되는 기간과 공수가 산정이 됩니다. 물론 이 때 나온 결과도 100%의 정확성을 가지고 있다고 보장할 수 없지만, 공짜 제안서와 비교할 수 없는 정확도를 가집니다. 고객이 이 때 나온 결과가 꼭 필요한 시스템이라는 판단이 들 때는 산정된 공수의 80% 수준에서 계약을 한 후 프로젝트를 진행합니다. 80% 수준의 공수로 계약하는 이유는 이 기간에 산출된 공수도 100%의 정확도를 보장할 수 없기 때문입니다. 최종 프로젝트 금액은 프로젝트가 완료된 후 소요된 공수를 정산해서 모자른 공수는 청구하거나, 반대로 남는 공수는 다시 고객에게 되돌려 줍니다.

어떠세요? 좀 복잡하고 고객 입장에서 기존의 계약 방식 보다 돈이 더 들어 보인다구요? 물론 표면 상으로는 그럴 수 있습니다. 하지만 알 수 없는 프로젝트 범위를 기반으로 산정된 공수에 질 낮은 결과물을 없는 것보다, 다소 비용이 비싸도 훌륭한 S/W를 얻는게 좋지 않을까요? 다시 한 번 이야기 하지만, 아니… 아버지 아까 모라고 하셨죠?

“아들아! 다시 한번 말하지만, 자본주의에는 공짜 점심이 없단다!”

※ 제가 마무리 하고 있는 지금 프로젝트에 문제가 많다는 뜻이 아닙니다.(오해하지 마세요!) 다만 그동안 생각했던 것들이 이번 프로젝트를 통해서 정리된다는 뜻입니다. 여러모로 수고해 주시는 김팀장님과 이선임님, 조주임님께 감사 합니다.(이 글을 안 보실지 모르지만요.) 아무쪼록 프로젝트 잘 마무리하고 맛난 거 먹으러 가자구요!

오늘 Post는 지금으로 부터 몇 백년 전 이야기로 시작하겠다. 내수 경기를 활성화 시키기 위해서 대규모 공공 사업을 실시하던 조선 중기 아니면 말기. 지금의 건설교통부의 역할을 하던 공조에 공사 규모와 건수가 늘어나면서 몇 가지 문제점이 생겼다. 그 중 한가지는 망치에 관한 것이었다. 공사 증가로 납품받는 망치의 개수가 많아지자, 불량 망치의 비율도 높아졌다. 공사 도중 불량 망치가 망가지면서 파편에 맞아 부상당하는 인부가 속출하였다. 따라서 인부의 부상으로 납기를 제때에 맞추지 못 한 공조판서는 임금으로부터 호된 꾸지람을 듣는 일이 종종 생겼다.

며칠 전 청계천 공사에서 불량 망치 문제로 납기가 지연되자, 공조 판서는 또 한번 임금에게 불려가 호된 꾸지람을 들었다. 이에 분개한 공조 판서는 공조 신하들에게 망치의 품질을 획기적으로 개선시키라는 명령을 내렸다. 공조 판서의 명을 받은 공조 신하들은 망치 품질을 개선시킬 수 있는 아이디어를 공모하였다. 수 많은 아이디어들이 쏟아졌지만, 그 중 공조 신하들의 마음에 들은 것은 망치 제조 연구소의 “망치 제조 성숙도 모형”이었다.

“망치 제조 성숙도 모형”은 망치를 만드는 대장간의 프로세스를 1에서 5까지의 5단계로 분류하여, 점수를 부여하는 것이다. 즉 1레벨은 망치 제조 시 아무런 프로세스를 따르지 않아 망치의 품질을 보증할 수 없고, 최고 등급인 5단계는 망치 제조 프로세스가 가장 최적화 되고 성숙되어서 높은 품질의 망치를 만들 수 있다는 것이다. 즉 납품 받는 망치의 품질을 전수 조사하기 보다는 망치를 납품하는 대장간의 프로세스를 측정해서 간접적으로 망치의 품질을 보증 받겠다는 계산이었다.

공조 신하들의 만장일치로 채택된 “망치 제조 성숙도 모형”은 공조 판서의 재가로 실행 되었다. 공조에 망치를 납품하려는 대장간은 최소 “망치 제조 성숙도 모형”의 3단계 이상을 획득해야 했다. 이런 사실이 알려지자. 기존에 망치를 납품하던 대장간에는 일대 “망치 제조 성숙도 모형” 인증 붐이 일었다. “망치 제조 성숙도 모형”의 인증을 받기 위해서는 망치 제조 연구소의 심사가 있어야 했다. 때아닌 “망치 제조 성숙도 모형” 인증 붐으로 망치 제조 연구소는 망치 제조 업계의 큰 영향력을 행사하였다.

“망치 제조 성숙도 모형”의 인증을 받기 위해서 가장 중요한 것은 문서 작업이었다. 기존에는 주문 받은 망치 종류에 맞는 거푸집을 찾아서, 쇳물을 부어 만들어진 망치 머리에 나무로 된 손잡이를 다는 것으로, 망치 만드는 것이 끝났다. 하지만 제대로 된 프로세스를 따라 망치를 만든다는 것을 보여 주기 위해서는 각 공정마다 산출물로 문서를 만들어야 했다. 예를 들어 주문을 받은 후 주문 받은 망치를 제 때에 만들어 낼 수 있는지 분석한 주문 대응 분석서를 만들어야 했다. 예전에는 단순히 그날 만들어야할 망치 개수에 따라서 몇 개를 추가적으로 만들지 대장장이 사이에 간단한 대화로 끝낼 수 있었던 업무였지만, “망치 제조 성숙도 모형” 3단계를 획득하기 위해선 반드시 문서를 만들어야 했다. 왜냐면 인증 심사관은 증거로만 심사를 할 수 있었고, 프로세스를 잘 따른다는 증거로 문서만큼 좋은 것은 없었다.

시간이 흐르고, “망치 제조 성숙도 모형” 3단계를 획득하는 대장간이 하나 둘 씩 나왔다. 공조는 “망치 제조 성숙도 모형”을 빠른 시간 안에 보급하기 위해서 3단계 획득한 대장간의 망치만을 공급 받았다. 또한 “망치 제조 성숙도 모형” 3단계는 마켓팅에도 많은 도움이 되었다. 공조 독점 공급이라는 소문이 퍼지자 일반 장터에서도 “망치 제조 성숙도 모형” 3단계 인증 대장간 제품이 불티나게 팔렸다. 따라서 일반 장터에만 물건을 납품하던 대장간들도 할 수 없이 “망치 제조 성숙도 모형” 3단계를 취득해야 했다. 갑작스런 인증 심사 요청으로 모든 인증 업무를 수행할 수 없게된 망치 제조 연구소는 한 가지 꾀를 내었다. 자신들이 직접 인증 업무를 하는 것이 아니라 인증 업무를 수행할 수 있는 인증 업체를 인증해 주는 사업 모델을 만들었다. 망치 제조 연구소는 일일이 대장간을 상대하지 않게 되었고 돈은 전보다 더 많이 벌게 되었다. 따라서 “망치 제조 성숙도 모형” 인증을 하는 업체는 우후죽순 격으로 생겨났다.

“망치 제조 성숙도 모형” 인증은 대장간이라면 당연한 것이 되었고, 잘 나간다는 대장간들은 서로 더 높은 레벨을 얻기 위해서 경쟁 아닌 경쟁을 하였다. A대장간과 B대장간은 망치 제조 분야에서 1,2위를 다투는 사이였다. 두 대장간 중에서 A대장간이 업계 최초로 “망치 제조 성숙도 모형” 5레벨을 획득하였다. 문서 작업이 많긴 했지만, A대장간의 대장장이들은 대장간 세계에서 유일하게 “망치 제조 성숙도 모형” 5레벨의 대장간에 다닌다는 Pride도 생겼다. 하지만 얼마 전까지 A대장간과 어깨를 나란히 하던 B대장간은 단지 3레벨에 머물러 있었다. 자신의 대장간에 만족하던 B대장간의 대장장이들도 으시대고 다니는 A대장간의 대장장이들을 보자, 왠지 자신의 직장이 초라해 보였다.

그러던 중 B대장간에는 이상한 소문이 돌았다. B대장간의 사장이 망치를 만들지 않고 장도리라는 제품을 만들겠다는 계획을 세운다는 것이었다. 이 소문은 B대장간의 대장장이들에게는 마른 하늘의 날벼락같은 소식이었다. “망치 제조 성숙도 모형”의 인증 레벨은 한 가지 제품에만 부여되는 특징이 있다. 즉 쇠망치를 만드는 대장간이 3단계를 획득하였다 하더라도, 나무망치를 만든다고 해서 나무망치 제조 분야에도 3단계를 주는 것은 아니다. 나무망치에 대해서는 별도로 인증 심사를 받아야 했다. 물론 쇠망치 3단계를 획득한 대장간이 나무망치에서 인증을 받는 것이 쉽긴 했지만, 별도의 인증 심사를 받아야 하는 고통이 따라야 했다.

물론 이런 인증 방식에 문제가 없는 것은 아니었다. 하지만 망치 제조 연구소의 주장에도 설득력이 있었던 것은 쇠망치를 만드는 것과 나무 망치를 만드는 것이 엄연히 다르기 때문에 인증도 별도로 해야 한다는 것이다. 즉 “망치 제조 성숙도 모형”의 본질은 제조 프로세스가 어느 정도 성숙했는가를 나타내는 것이기 때문에 쇠망치를 만들던 대장간이 3레벨의 수준이라 해도, 나무 망치를 만들 때는 그 성숙도가 떨어진다는 것이다.

따라서 B대장간이 기존의 망치를 만들지 않고, 장도리를 만든다면 힘들게 취득한 “망치 제조 성숙도 모형” 3단계는 없어질 판이었다. 듣자 하니 장도리라는 제품은 망치에 못을 뽑는 도구가 붙어 있는 형태이기 때문에, 망치와는 완전히 달라 1레벨도 취득하기 어려울거 같았다. 대장장이들은 사장에게 가서 따졌다.

대장장이A : 사장님. 망치를 안 만들고 앞으로 장도리라는 제품을 만든다구요?
사장 : 내. 앞으로는 장도리로 제품 생산을 전환할려 합니다.
대장장이B : 아니 지금 제 정신이에요. 옆의 A대장간은 5레벨을 따고 난리인데 장도리를 만들면 어떻게 하자는 거에요?
대장장이C : 맞아요. 장도리를 만들면 지금껏 애써서 얻은 3레벨도 인증 취소 될 수 있단 말이에요.
사장 : 내. 저도 그 점은 알고 있어요.
대장장이A : 그걸 아시는 양반이 장도리를 만들자고 합니까? 더 노력해서 4레벨도 따고 5레벨도 따야지.
사장 : 자~ 다들 그렇게 흥분하지 말고. 제 얘길 들어 보세요. 지금 망치를 만드는 잘 나간다는 대장간 중에 3레벨이 아니 곳이 있나요?
대장장이들 : 없죠.
사장 : 바로 그거에요. 여러분들도 아시겠지만, 3레벨을 취득하고 말고는 선택이 아니라 필수예요. 무엇보다도 망치 시장은 포화 상태입니다. 즉 제조 원가 싸움인거 아시죠. 중국산 저가 망치가 시장을 잠식하고 있기 때문에 앞으로 망치 시장은 더 불투명합니다. 우리는 이런 환경에서 벗어나야 해요. 아무리 망치를 잘 만들면 무엇합니까? 팔 시장도 없고 이윤도 나지 않는 시장인데요. 따라서 제가 장도리를 만들려고 하는 이유는 새로운 시장을 만들기 위함이에요. 앞으로는 망치 시장은 장도리가 대체할 겁니다. 장도리를 만드는 것은 쉬운 일이 아니라 생각합니다. 하지만 우리는 이미 망치 만드는데는 도가 튼 상태이기 때문에 조금만 힘을 합치면 장도리를 만들 수 있을겁니다.
대장장이A : 그래도 우리 대장간이 A대장간보다 망치를 잘 만드는데, 그냥 망치를 만드는게 낫지 않나요?
대장장이B : 저도 같은 생각입니다만..

대장장이들의 저항에 부딪혀 장도리 출시는 다소 지연되었지만, 사장의 설득으로 장터에 출시할 수 있었다. 못을 뽑을 수 있는 기능이 추가된 B대장간의 장도리는 초 히트 상품이 되었다. 이에 반해 “망치 제조 성숙도 모형” 레벨 취득에 혈안이 되어 있던 대장간들은 한동안 중국 망치의 저가 공세로 고전을 면치 못했다.

이 우화를 읽고 어떤 생각이 드는가? SI업계에 한동안 몰아 쳤던 CMM인증 붐이 떠오르지는 않는가? 다시 말하지만 난 Process 무용론자도 아니며, CMM의 가치를 폄하하려는 의도도 없다. 이 Post의 본질은 Business 관점에서 CMM 인증을 바라 보려는데 있다. 일단 이 우화의 영감을 얻은 피플웨어(톰 디마르코, 티모시 리스터 著)에서는 CMM에 대해서 다음과 같이 평가한다.

“루크여, 잘 생각해 보라. 너의 기업이 레벨 4로 뛰어 오르면 엄청난 재정적 이익이 돌아올 거라는 사실은 알고 있겠지(레벨 5는 최고만 될 수 있다는 것을 알아야 한다.) 그렇다면 레벨 4로 가는 길을 방해하는 것을 모두 없애 버려라. … 우리의 계획은 이렇다. 과거 우리가 해보았던 프로젝트와 똑같은 종류의 프로젝트만 맡는 것이다. 우리가 잘하는 일만 하고, 이런 흔한 프로젝트에 딱 맞는 프로세스를 택하는 것이다. 우리는 모든 과정을 잘 문서해 놓았다가 은하계 프로세스 평가원이 오면, 우리가 해놓은 한 치의 오점도 없는 완벽한 소프트웨어 프로세스를 실행해 보인 뒤 감탄하게 만드는 것이다. 그렇게 되면 우리는 당초 기대하고 있었던 소프트웨어 프로세스 레벨을 올리는 엄청난 성과를 거두게 될 것이다. 그러나 그러고 나서 재빨리 움직여야 한다. 회사가 망하기 전에 하루 빨리 올라간 프로세스 레벨을 이용하여 돈을 벌어야 한다.”

정반대로의 프로세스 개선책

… 당신의 회사가 현재 CMM 레벨 2 혹은 그 이상의 회사라면 다음 문장을 꼭 기억하라. “가장 해 볼 만한 가치가 있는 프로젝트는 당신 회사의 프로세스 레벨을 완전히 한 등급 낮춰 줄 그런 프로젝트이다” 그런 프로젝트들이야말로 당신이 해야 할 유일한 프로젝트일 수도 있다.

당신이 S/W 회사의 owner라 가정해 보자. 회사를 운영하는 이유는 무엇인가? 일이 좋아서, 사람들이 좋아서 물론 이런 것도 답이 되겠지만 가장 큰 이유는 이윤 창출일 것이다. 돈을 벌고 싶다면 당신의 회사는 시장에 새로운 가치를 제공해 주어야 한다. 다르게 표현하면 당신 회사의 S/W 혹은 서비스가 시장에 새로운 가치를 줄 때 돈을 벌 기회가 있다.

반대로 CMM은 무엇인가? 업무의 성숙도를 나타내는 지표다. 예를 들어 당신 회사는 ERP 구축을 주력 사업으로 하고, CMM레벨을 올리려 한다면, ERP 관련 프로젝트를 수주해야 한다.(동일 분야의 프로젝트 경험이 축적되어야 레벨이 올라갈 수 있기 때문이다.) 모든 SI프로젝트의 시장이 그렇듯이 시간이 흐르면 기술이 보편화 되어 프로젝트 수익성이 떨어질 수 밖에 없다. 그렇다면 수익성 저하에도 불구하고 CMM 레벨을 올리려는 진짜 이유는 무엇일까? S/W의 품질을 높이려는 목적도 있지만, 좀 더 큰 이유는 마케팅적 요소가 있기 때문이다. 같은 S/W 분야, 같은 수주 조건일 때 고객은 CMM 레벨이 높은 곳에 프로젝트를 의뢰할 가능성이 많다. 실제로 CMM 레벨이 프로젝트 수주에 많은 영향을 미치는 것이 사실이다. 따라서 쉽게 돈을 벌고 싶다면 하루 빨리 회사의 CMM레벨을 높여서 프로젝트를 수주해야 한다. 하지만 그러는 사이 돈은 벌지 모르지만 회사의 성장 동력은 점점 떨어지게 된다. 얼마 지나지 않아 당신은 회사가 Red Ocean 안에 놓여 있는 것을 알게 될 것이다.

위의 이야기는 CMM레벨을 올려서 돈을 벌 수 있는 방법이다. 그럼 CMM레벨을 떨어 트려서 돈을 벌 수 있는 방법을 알아 보자. CMM 레벨을 떨어 트리는 방법은 해 보지 않은 프로젝트를 하는 것이다. 즉 경험 없는 프로젝트를 수행하는 것이다. 경험이 없는 프로젝트란 무엇인가? 바로 새로운 가치 혹은 새로운 분야의 프로젝트다. 새로운 가치 혹은 새로운 분야의 프로젝트라는 걱정은 할 필요가 없다. 당신의 회사는 이미 어느정도 수준의 S/W 개발 경험을 가지고 있기 때문에 처음에는 효율이 높지 않지만 곧 재기량을 발휘할 수 있을 것이다.(이건 CMM이 말해 준다.) 따라서 Risk를 감수할 준비만 되어 있다면 새로운 Business의 가능성은 CMM 레벨 저하 프로젝트에서 찾을 수 있을 것이다.

※ 망치 이야기는 가상임을 알려 둡니다. ^^