자동차 전장 부품 개발에서 Automotive SPICE® assessment에 대한 요구가 많아지고 있습니다. 우리나라에서 assessment는 “심사” 또는 “평가”로 번역되는데, 사실 “평가”라고 하면 영어로 “evaluation”을 떠올리게 됩니다. 개발 프로세스 심사에서 “assessment”와 “evaluation” 간에는 차이가 있습니다. 본 기사에서는 개발 프로세스 심사 방법론의 간단한 역사를 살펴보고 심사와 평가의 차이점은 무엇이며 앞으로 어떤 방식으로 심사를 이해하고 활용하는 것이 바람직할지 생각해봅니다.
개발 프로세스 심사 방법론의 시작
전통적으로 제조 업계에서는 문서화된 표준 프로세스를 지키는지 확인하기 위한 감사(audit)가 수행되어 왔습니다. 1970년대 후반, 품질 분야의 대표 석학 중 한 명인, 필립 크로스비(Philip B. Crosby)는 품질 감사를 통과한 조직들이 품질 관리 역량에서 서로 큰 차이를 보이는 요인에 대해 지적하면서 품질 관리 성숙도(Quality Management Maturity Grid)를 제안했습니다. 그의 제안은 많은 품질 전문가들에게 영감을 주었고 공정 능력 성숙도라는 개념으로 발전했습니다.
한편, 제조보다는 개발 프로세스에 의존하는 소프트웨어의 경우 품질 관리 시스템에 대한 감사만으로는 프로젝트의 성공과 품질 확보가 어렵다는 인식이 높아졌습니다. 초기 소프트웨어 개발은 예술적이거나 공예적인 활동으로 여겨져 왔는데, 와츠 험프리(Watts Humphery)는 IBM에서의 오랜 경험을 통해 소프트웨어 개발이 재현 가능하고 예측 가능한 프로세스가 될 수 있음을 깨달았습니다. 그는 프로세스의 향상이 제품 품질의 향상으로 이어진다는 점을 강조하였고 소프트웨어 품질 개선이 개별 개발자의 노력에 의존하는 것이 아니라, 표준화되고 세련된 프로세스의 도입과 개선을 통해 이루어져야 한다고 주장했습니다. 소프트웨어 조직이 그들의 프로세스를 개선하기 위한 체계적인 접근 방식을 필요로 한다는 인식을 바탕으로, 그는 미국 국방성이 후원하여 카네기멜론 대학에 설립된 Software Engineering Institute(SEI)에서 Capability Maturity Model(CMM)을 개발하는데 중요한 역할을 하게 되고 소프트웨어 개발을 수행하는 조직에 대한 프로세스 성숙도 개념을 도입하여 현재의 상태를 결정하고 어디로 나아가야 하는지 방향성을 제시하는 체계적인 모델인 CMM을 개발하게 됩니다.
1990년대 중반, 다수의 국가 및 조직에서는 국제적으로 인정받을 수 있는 표준화된 소프트웨어 프로세스 심사 및 개선 모델과 심사 방법의 필요성이 대두되었고, CMM은 유럽을 중심으로 ISO/IEC 15504, 현재의 ISO/IEC 330xx 시리즈가 되는 SPICE(Software Process Improvement and Capability dEtermination) 프로젝트의 시작을 촉진시켰습니다.
한편, SEI는 CMM를 이용하여 조직과 프로세스를 심사하는 방법들도 함께 개발하였는데 조직의 소프트웨어 개발 능력을 평가하려는 목적으로 설계된 SCE (Software Capability Evaluation)는 CMM의 다섯 개의 성숙도 수준을 기반으로 하며 외부의 독립적인 심사팀에 의해 이루어지며, 조직의 실제 프로세스가 CMM의 각 성숙도 수준에 정의된 프로세스 영역과 얼마나 일치하는지를 평가했습니다. CBA-IPI (CMM-Based Assessment for Internal Process Improvement)는 조직 내부의 프로세스 개선을 목표로 하며 자기 평가에 중점을 둔 방법론으로 조직의 현 상태를 파악하고 개선 영역을 도출하는 데 사용되었습니다. 이후, CMMI에 특화된 심사 방법론으로 SCAMPI (Standard CMMI Appraisal Method for Process Improvement)로 진화하게 됩니다. CMM과 SPICE는 프로세스 모델과 심사 방법에서 서로 영향을 주며 발전하게 됩니다.
심사(assessment)와 평가(evaluation)
미국 국방성과 SEI는 소프트웨어 개발 프로세스에 대한 품질 평가를 대체로 두 가지 유형으로 수행하였습니다. 첫 번째는 소프트웨어 프로세스 심사(Software Process Assessment, SPA) 방식으로, 조직이 자체 소프트웨어 개발 능력을 파악하고 프로세스 개선을 위한 조치의 우선순위를 정하기 위해 사용하는 방식입니다. 두 번째는 소프트웨어 능력도 평가(Software Capability Evaluation, SCE) 방식인데 미국 국방성이나 그 밖의 정부 기관에서 소프트웨어 획득 프로세스의 일환으로 수행되었으며 외부 인원들이 특정 계약자의 프로세스 성숙도 수준을 평가(evaluation)하는 데 사용됩니다.
소프트웨어 프로세스 심사(SPA)와 소프트웨어 능력도 평가(SCE)는 방법, 목적, 결과의 소유권 및 결과에 대한 동기 등 여러 측면에서 차이를 보이지만, 기본적인 차이는 소프트웨어 프로세스 심사(SPA)에서 적용하는 협력적 접근방식이 수행 중인 프로세스의 개선을 촉진하는 분위기를 조성한다는 것입니다.
개발 조직이 스스로를 분석하는 집단적 노력이 심사(assessment)이고 이것을 통해 실질적인 개선을 시작할 수 있습니다. 참여자 중심의 활동으로서 심사가 진행되면 조직은 그 결과에서 비롯되는 개선 계획을 잘 받아들이고 주인이 되어 주도적으로 수행할 수 있게 됩니다. 변화를 위한 제안이 조직 외부나 고위층에서 강요되는 것이 아니라 집단적인 노력으로 인해 생겨난 아이디어에서 시작될 때, 사람들은 그것에 저항하는 경향이 훨씬 덜합니다. 반면에 평가(evaluation)나 감사(audit)는 조직이 하지 않거나 갖고 있지 않은 것으로부터 시작되는데, 이는 물론 유익한 부분도 있지만 많은 경우 피평가 조직은 상처받고 좌절하게 되며 능동적인 개선보다는 발견된 문제에 대응하기 위한 수동적인 시정조치만 남게 됩니다. 오늘날 Automotive SPICE® 심사 후에 대상 프로젝트와 조직에서 일어나고 있는 상황과 다르지 않습니다.
SEI는 SPICE 프로젝트가 진행되는 시기에 CMM을 CMMI로 확장하면서 appraisal이라는 용어를 도입하고 이것을 적용하는 방식으로서 내부 프로세스 개선, 공급업체 선정 등의 심사 모드(mode)를 정의했습니다. 결국 심사(appraisal)라는 용어로 심사(assessment)와 평가(evaluation)를 모두 수행할 수 있도록 했습니다.
SPICE도 그 이름에서 알 수 있듯 두 가지 주요 목적을 가지고 있습니다. 하나는 Software Process Improvement 입니다. 조직에서 소프트웨어 개발 프로세스의 현재 상태를 파악하고 개선 기회를 식별하기 위한 것입니다. 이는 조직 내부에서 주로 수행되며, 그 결과를 바탕으로 프로세스 개선 활동을 계획하고 실행할 수 있습니다. 또 하나는 Capability dEtermination 입니다. 외부의 관점에서, 특정 조직이나 프로세스가 주어진 기준 또는 모델(예: ISO/IEC 15504 표준, 현재는 ISO/IEC 330xx)의 충족 정도를 결정하는 것입니다. 그러므로 SPICE도 조직의 프로세스 개선을 위한 목적과 외부적인 프로세스 능력 평가를 위한 목적 모두를 위해 사용됩니다. 그래서 Automotive SPICE® Guideline에도 심사의 사용법이 두 가지로 제시되어 있습니다.
결론
많은 노력에도 불구하고 심사가 도움이 되지도 않고 심지어 손해를 끼치기도 하는데 여기에는 그럴만한 이유가 있습니다.
첫째는 심사 동기에 따른 그릇된 대응에 있습니다. 심사의 동인은 조직 외부(예를 들면 고객)나 조직의 고위층의 요구로부터 발생하는 경우가 많습니다. 특정한 성숙도나 능력도 수준 이상을 달성해야 한다는 필요성은 수주를 위한 기준이 된 것처럼 작용합니다. 결과적으로, 조직은 그들의 의사에 반하는 심사에 끌려가고, 실제보다 더 높은 성숙도나 능력도 수준으로 보이기 위해 심사 결과를 왜곡하려는 시도가 자연스럽게 나타납니다. 심사는 오직 정직한 노력으로 성취될 수 있는 개선을 스스로 할 수 있도록 동기를 부여하는 과정입니다. 단기적으로 조직은 심사 주체를 속일 수도 있지만, 장기적으로는 그들 스스로를 속이게 될 뿐인데, 그 과정에서 개선에 진심인 직원들을 실망시키고 그런 속임수가 인정된 후에는 실질적인 개선 노력을 훨씬 더 어렵게 만듭니다. 심사를 통해 수준을 정확하게 알고자 요구하는 고객이나 경영진이라면 이러한 부작용에 주의해야 합니다.
둘째는 심사 결과에 대한 잘못된 인식입니다. 심사에서 발견된 약점이나 개선기회들을 전통적인 감사나 평가에서의 그것들처럼 특정 기준에 충족되지 않는 사항이라고 판단하여 하나하나 고치려는 시도를 합니다. 심지어 일부 고객이나 심사원들은 그렇게 할 것을 요구하기도 합니다. 조직이 그들이 수행해 왔던 관행을 개선하여 더 높은 능력도나 성숙도 수준으로 올라가는 것은 생각보다 쉽지 않습니다. 그것이 어렵지 않았다면 CMM, SPICE 등이 출현한 지 30년이 넘은 지금까지도 수준 1이나 2에 머물러 있을 조직은 없을 겁니다. 이것은 상당히 고통스럽고 힘든 일입니다. 산출물에서 발견한 결함들을 기계적으로 하나하나 고치는 방식으로는 달성이 어렵습니다. 당장은 성공적인 시정 조치를 한 것처럼 보이지만 사실 그들 결함은 또 나오게 됩니다. 왜 그런 결함들이 생겼는지 프로세스 상의 근본 원인을 살피고 우선순위를 정하여 가능한 일부터 지속적으로 바꾸어 나가는 길이 입증된 방법입니다.
현재 우리는 혼란 속에 있습니다. assessment를 “평가”라고 하고 assessor를 “심사원”으로 호칭하는 가운데 심사를 “평가”로만 인식하는 경향이 있습니다. 개선을 목적으로 하는 심사도 평가처럼 진행하고 또, 그렇게 대응합니다.
많은 조직들이 심사를 받기 위해 적지 않은 비용과 노력 그리고 시간을 투입하고 있는 이 시기에, 우리나라 산업 경쟁력 제고라는 관점에서 개발 프로세스 심사의 의도와 이익을 다시 생각해 보고 활용하면 좋겠습니다.