CMMI는 회사를 망칠 수도 있다

필자는 최근 소프트웨어와 시스템 공학 역량의 성숙도를 평가하는 CMMI(Capability Maturity Model Integration)를 적용하여 오히려 어려워진 H사 직원 S씨를 만났다. 

그동안 SI회사 등 여러 곳에서 CMMI를 적용하였던 회사의 직원들을 많이 만나봤지만 SI회사도 아닌 이 회사의 사례는 독특해 칼럼에서 소개할까 한다. 

CMMI를 폄훼하려는 의도가 있는 것은 전혀 아니니 오해는 하지 말아주기 바란다. CMMI에 대한 오해와 서투른 기대를 경계하자는 것이다. 이는 CMMI 뿐만 아니라 수많은 방법론에도 똑같이 해당한다. 

H사는 최근 촉망받는 분야의 서비스를 하는 회사다. 직원이 100명 가까이 되는 작지 않는 회사지만 개발에 관련된 변변한 문서가 하나도 없다. 스펙, 설계서 뿐만 아니라 문서는 전무하다 시피하다. 개발 프로세스라고 할 만한 것도 없다보니, 주먹구구식으로 개발을 하고 있었다. 

고참 개발자라고 하는 사람들도 코딩만 꽤 할 줄 알았지 개발 프로세스가 뭔지도 모르고 협업에는 별로 관심도 없는 상태였다고 한다. 

이에 H사 대표는 이대로는 안되겠으니 컨설팅을 받아봐야겠다고 생각 했다. 그래서 선택한 컨설팅 회사가 CMMI를 전문적으로 컨설팅하는 국내 회사인 P사였다. 

P사는 CMMI 레벨3를 적용하자고 제안했고 직원들은 회사 내부에서 관련 교육을 받았다. 외부에 나가서도 수차례 교육을 받았다. P사는 회사의 기존 프로세스와 그나마 있었던 문서를 분석해서 CMMI 레벨3 기준으로 개발 프로세스를 만들고 수십가지의 문서 탬플릿을 만들어서 제안했다. 

실제 프로젝트에 이 프로세스와 문서 탬플릿을 적용하기 시작했는데 교육을 받기는 했지만 요구하는 수많은 문서를 만들어내기는 보통 어려운 일이 아니었다. 또 촉박한 프로젝트 일정에 문서까지 추가로 만드는 것은 죽을 맛이었다고 한다. 이에 개발자 및 사업부에서는 반발이 매우 심했고, CMMI를 적용하느라 몇개 프로젝트는 포기를 해야 하는 상황까지 발생했다고 한다. 

이런 상황에서 개발자들이 선택한 방법은 어처구니는 없는 것이었다. 문서에 적어야 하는 기능의 개수를 줄이기 시작한 것이다. 

기능하나에 서로 연결해서 작성해야 하는 문서가 많아서 전체 문서 양이 매우 많았다. 예를 들어 실제로는 500개 기능인 프로젝트에서 문서에는 100개만 적으면 문서 개수가 많아도 전체 작성해야 하는 문서의 양은 줄어들게 된다. 그렇게 해서 요구하는 문서와 프로세스를 따랐다고 한다. 정해진 일정에 요구하는 문서를 만들어 내려면 어쩔 수 없다고 한다. 

CMMI를 적용한 프로젝트에 참여했던 S씨는 해당 프로젝트에서 20여가지 문서를 만들었지만 실제 프로젝트에 쓰인것은 SRS와 WBS 문서 2개 밖에 없다고 했다. 나머지 20여가지 문서는 컨설팅 회사에서 요구하기 때문에 만들었을 뿐이라고 한다. 프로젝트 중간이나 프로젝트가 끝난 후에도 나머지 문서들은 볼일이 없을 것이라고 한다. 

H사는 그 뒤로 개발역량 향상은 커녕 CMMI의 직접적인 영향을 아니겠지만 매우 어려운 상태에 놓이게 되었다. 

이론적으로 CMMI를 통해 SW공학의 성숙도를 측정하고 역량을 향상할 수 있다. 하지만 오해와 잘못된 적용 방식이 국내에서는 큰 문제가 되고 있다. 역량 수준이 한참 못미치는데 억지로 요구하는 수준에 맞추기 위해서 문서를 만들어내고 프로세스를 따르는 것이다. 그렇게 해서는 역량이 향상될리 없다. 이런 일이 빈번하여 한국이 블랙리스트에 올랐다는 소문도 파다하다. 

CMMI가 필요한 분야도 있다. 대표적인 분야가 국방일 것이다. 국방 프로젝트는 1달러짜리 나사를 사기 위해서 프로세스와 문서를 적용하여 50달러를 투입해야 할 때도 있는 프로젝트다. 민간 프로젝트와는 성격이 다른 중요도가 있는 프로젝트이다. 

그 외에도 CMMI 인증이 필요한 프로젝트가 있다. 역량이 안되더라도 비즈니스 목적으로 CMMI를 적용하는 것은 그럴 수도 있다고 생각한다. 개발에는 별로 도움이 안되고 영업에는 도움이 될 것이다. 

하지만 순수하게 소프트웨어 개발 역량을 높이기 위해서 단기간에 CMMI를 적용하는 것은 별로 좋은 방법이 아니다. 실전적인 방법으로 내실을 다지는 것이 더 낫다. 

적당할 예 일지는 모르겠지만 타이거 우즈가 CMMI 레벨5 수준으로 골프를 친다고 가정하자. 타이거 우즈는 CMMI 레벨5로 골프를 치기 위해서 골프 스윙시 25가지의 절차와 고려사항을 눈깜짝할 사이에 적용해서 공을 친다. CMMI 레벨5에서는 그 25가지의 절차를 잘 분석해 놨다. 

나는 주말골퍼인데 코치가 그 25가지 절차를 따르면 타이거우즈처럼 골프를 칠수 있다고 한다. 1년을 그렇게 연습한다고 타이거 우즈처럼 골프를 칠 수 있을까? 타이거 우즈는 이미 성숙도가 높고 몸에 완전히 베어 있어서 25가지의 절차를 아무렇지도 않게 수행할 수 있지만 나는 그렇게 할 수가 없다. 

그것을 따라하다가는 오히려 골프를 더 못치게 된다. 현재 상황에서 필요한 것을 하나씩 배우는 것이 훨씬 낫다. 또한 대부분의 실용적인 소프트웨어 개발 현장에서는 그 수준까지는 필요하지도 않다. 

사대주의도 아니고 바다건너의 멋진 모델에 현혹되는 사례가 유난히 우리나라에는 많은 것 같다. 실리콘밸리에서 오래 개발한 개발자들에게 물어봐도 CMMI는 관심도 없고 주변에 적용한 회사는 본적도 없다고 한다. 그만큼 실전적이고 실용주의적인 개발을 지향하는 곳이라면 성숙된 개발 문화와 개발 본연의 역량 향상에 힘을 쓴다. 뛰어난 아키텍트 발굴도 그 일환이다. 

이는 비단 CMMI만의 이야기가 아니다. 수많은 방법론도 마찬가지다. 그자체로는 훌륭할지는 몰라도 적절한 곳에 적용을 해야 하며 우리 회사에서 필요한 것인지는 잘 생각해봐야 한다. 

필자는 좀더 효율적으로 개발을 하기 위해서는 성숙된 개발문화를 정착하기 위해 노력해야 한다고 생각한다. 실용적이고 실전적이지 않은 모든 절차와 프로세스는 짐이 될 뿐이다.

이글은  ZDNet Korea에 기고한 칼럼입니다.