Talk about Software with hani

CMM을 처음으로 접하는 것은, 02월드컵의 열기가 잦아들고 02대선의 열기가 후끈달아오른 시점이었습니다. 그 당시에는, CMM을 회사에 적용하는 게 일종의 유행이었죠. 제가 몸담고 있던 회사에서도, CMM을 이런 저런 사업부에서 적용하기 시작했죠. 제가 근무했던 연구소에서는 ISO9001을 적용하고 있었지만, IS9001기반으로 정리된 SW개발 프로세스가 그다지 상세하지 않았기에, 개발하는 데 큰 도움을 주지 못했습니다.

인원은 모자르고, 일은 많고, 납기가 늦어지는 경우가 왕왕 있었기에, 제가 있던 연구소에서도 CMM을 적용하자는 분위기가 있었습니다(물론 CMM을 적용하다고 이런 문제가 해결된다는 것은 물음표입니다). 그리하여, CMM을 배워 오기 위해, 비행기를 타고 동료들과 CMM5레벨을 취득한 인도연구소로 향했습니다. 그곳에서 2주 동안, 친숙하지 않은 주제인데, 익숙하지 않은 인도 영어로 배움을 얻으려고 하니 참 고단했습니다. 짧은 기간이었기에, “CMM이라는 게 그런 거구나”하는 느낌 정도를 받아 왔습니다.

그러고 나서, 인도연구소에서 온 엔지니어들과 CMM을 적용한 파일롯 프로젝트를 약 2달간 진행했습니다. 저는 당시에 여러 가지 일이 있었는데, 가욋일 비슷하게 저도 파일롯 프로젝트에 참석했죠. 대충 그 프로젝트를 통해서, 윗분들이 CMM을 연구소에 적용하는 게 의미있는지 살펴보려는 의도였습니다. 인도에서 공부도 쉽지 않았는데, 그 짧은 기간에 파일롯 프로젝트를 수행한다는 게 만만하지 않았죠. 우여곡절 끝에, 파일롯 프로젝트는 끝나고 다행스럽게 CMM을 조직에 적용하는 것은 시기상조다, 그리고 별 이득이 없다는 결론이 내려졌습니다. 하하…

어찌 어찌하여 이직하고 몇 년이 흘렀습니다. 그리고 지금 있는 곳에서도 CMMI 인증을 얻으려고 준비했고, 3레벨을 취득했습니다. CMMI나 기타 인증시스템을 취득해 보거나, 취득한 회사에서 근무하신 분들은 아시겠지만, 이런 인증모델을 조직차원에서 적용한다는 것은, 자신이 맡은 혹은 참여한 프로젝트에서도 인증을 유지하기 위한 프로세스를 따라야 한다는 의미입니다.

조직 차원에서, 프로젝트가 CMMI 영역을 준수하는지 파악하기 위해, 보통은 QA팀에서 품질보증활동을 합니다. 즉, 품질보증을 위한 체크리스트를 활용해서 QA담당자들이, 프로젝트 산출물을 검토하고, 의심이? 생기는 부분은 프로젝트 관리자나 팀원들과 인터뷰로 확인합니다. 이런 이유로, CMMI를 준수하는 회사에서 운영되는 프로젝트는 문서 작성을 소홀히 할 수 없습니다. 물론, CMMI에서 문서 작성을 반드시 하라고 말하지는 않지만, 심사관이나 QA담당자가 프로세스를 준수하는지 파악할 수 있는 유일한 방법 그리고 객관적인? 방법은, 산출물이기 때문입니다.

SI회사에서, 대개 CMMI 레벨을 취득하기 때문에, PM에게 산출물을 잘 작성하고 관리하는 게 중요한 능력으로 평가받기도 합니다.

CMMI는 프로세스 개선, 평가 모델이기 때문에, 어떤 개발방법론을 따르라고 명시하지 않습니다. 그렇기 때문에, 프로젝트에서 폭포수 방법을 써도, 반복적인 방법(iterative methodology), 점진적인 방법(incremental methodology), 애자일 방법론(agile methodology)를 사용할 수 있고, 사용해도 괜찮습니다. 그런데, 애자일 방법론을 CMMI인증을 받은 조직에서 사용하다 보면, 일종의 형용모순을 겪습니다. 왜냐하면… 애자일 선언과 CMMI의 접근방식이 모순을 일으키기 때문이죠.

애자일 소프트웨어 개발 선언문

‘프로세스와 도구’보다는 ‘개인과 상호작용’을

‘포괄적인 문서화’보다는 ‘동작하는 소프트웨어’를

‘계약 협상’보다는 ‘고객과의 협력’을

‘계획 준수’보다는 ‘변화에 대응’을

‘애자일 프랙티스’에서(밑줄은 개인적으로 침)

애자일 선언문에서 알 수 있듯이, 애자일 방법론은 ‘프로세스와 도구’보다는 ‘개인과 상호작용’을 중시하기 때문입니다. 애자일 방법론은 경량 프로세스(light weight process)라고도 불립니다. 즉, 전통적인 프로세스(heavy weight process)에 반발해서, 애자일은 경량 프로세스를 외치면서 만들어졌기 때문입니다.

자! 그렇다면, CMMI, 즉 전통적인 프로세스를 적용하는 SI회사에서, 애자일 방법론을 적용한다는 것은 일종의 형용 모순처럼 느껴지지 않으신가요? 맞습니다. SI회사에서 애자일은 확실히 가능하지만, 한편으로 CMMI 프로세스를 준수해야 하기 때문에 이러 저러한 어려움이 있었습니다.

즉, 우선순위라는 것은 결국 순서를 세워야 한다는 의미인데, 모든 것이 우선순위 1번이라는 것은 이미 모순적인 말입니다. 다시 애자일 방법론으로 돌아와서, ‘프로세스’보다는 ‘개인과 상호작용’에 비중을 두는 것이기에, 프로세스가 이러 저러 하기 때문에, “고객님의 요구사항”을 받아들일 수 없다는 논리를 편다는 게… 썩 개운치 않습니다.

그렇다면, CMMI속에서 애자일을 적용한다는 것은 모순투성이 일일까요? 지금까지 제가 내린 결론은, 절반의 긍정과 절반의 부정입니다. 즉, CMMI를 적용한다면 변경요청서를 작성하는 작업이 고객의 요구사항을 애자일하게 반영하는 것보다 더 중요할 수 있습니다. 반대로 애자일을 적용한다는 것은 그깟 ‘문서 작업’은 이슈 추적 시스템에 기록한 티켓 정도로 충분할 수도 있습니다. 아무튼 이런 모순이 존재하기에, CMMI도 준수해야 하고 애자일 방법을 프로젝트에 적용해야 하는 PM은 무척이나 분주해질 수 있습니다.

프로젝트에서 중요하지 않은 팀원은 없습니다. 팀원이 모두 자신이 맡은 일을 제대로 할 때 좋은 결과가 생기기 때문이죠. 하지만, 행정적인 업무를 처리하고, 조직차원의 규칙도 준수하면서, 팀원들이 신나게 일하는 환경을 만들기 위해서, 즉 CMMI도 지키고 애자일 실천방법도 프로젝트에 적용하려면, 전체적인 관점에서 CMMI와 애자일을 잘 엮을 수 있는 PM의 역할이 중요한 셈이죠.

그래서 한줄 요약은, “CMMI와 애자일을 동시에 따른다는 게 쉽지  않다”정도 입니다.

This entry was posted on Sunday, August 31st, 2008 at 9:11 pm and is filed under software. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.