[아이티비즈] “조달청은 22일 미래창조과학부, 정부3.0 추진위원회 등과 공동으로 3개 공공정보화 사업에 대해 설계를 우선 실시하고 그 설계서에 따라 구현하는 ‘소프트웨어 사업 분할발주제도’를 시범 도입하기로 했다(출처:동아일보, 2015년 4월 23일)”는 뉴스를 접했다.
20년 이상 소프트웨어 개발 현장에서 발주자의 잦은 요구사항 변경으로 인해 힘들어하는 소프트웨어 개발자들의 현실이 안타까웠던 필자의 입장에서는 반가운 뉴스였다. 현재는 시범사업 수준으로 추진되는 소프트웨어 분할발주가 정착된다면 프로젝트팀은 보다 안정적인 환경에서 프로젝트를 관리할 수 있을 것으로 기대한다.
기존에는 회사가 아무리 좋은 개발 프로세스와 프로젝트 관리 절차를 수립하였어도 개발 현장에서 요구사항이 자주 변경되면 실질적인 프로세스의 적용이 어려웠다. 이러한 현실에서 정부의 소프트웨어 분할발주 시행은 선진화된 프로세스 적용의 장애요소를 제거하는 첫걸음이 될 것으로 기대한다. 하지만 제도의 뒷받침이 되어도 이를 운영하고 적용하는 조직이나 인력이 활용을 하지 못한다면 아무리 좋은 제도라도 효과를 보기 어렵다.
소프트웨어 개발 회사는 사업 환경 변화에 적응하고 사업적인 이득을 얻기 위해서는 새로운 공공사업 체계에 적응하기 위한 전략과 프로세스 개선의 숙제가 남겨졌다. 먼저 소프트웨어 분할발주가 CMMI(Capability Maturity Model Integration)에 기반을 둔 조직의 프로세스에 어떠한 영향을 줄 수 있는지 살펴보고자 한다.
새로운 발주 절차에 구체적인 요소를 살펴보면, 재작업이나 과업변경 시 계약 금액 조정을 위한 “계약 금액 조정 가이드”가 만들어졌다. 이 조항은 CMMI의 요구사항관리 영역과 관련이 많다. 현재 프로젝트 현장에서는 요구사항 변경이 많고, 고객이 변경요청서를 쓰지 않는 경우가 많아서 요구사항 변경 내역이 관리되지 않거나 형식적인 산출물을 만드는 경우가 많았다.
하지만 소프트웨어 분할발주 환경에서는 개발사업자가 재작업이나 변경에 대한 적정한 계약 금액의 조정을 위해서 공식화된 변경 절차와 기록이 필요하기 때문에 현재보다 더 공식적이고 합리적인 요구사항 변경 관리 프로세스가 필요하다. 프로젝트 계획 프로세스 또한 조직의 상황에 따라 개선이 필요할 수 있다. 기존의 프로젝트 계획은 한번 수립되고 일정이 변경되지 않으면 계획서가 크게 바뀌지 않는 경우가 많다.
요구사항이 변경이 되면 프로젝트 범위 변경이 필요한 경우가 많은데도 다양한 현실적인 이유로 범위 변경에 따른 계획 조정 없이 프로젝트가 수행되는 경우가 많았다. 하지만 요구사항 변경이 지금보다 공식화된다면 변경에 따른 프로젝트 범위 변경 시 추정 작업이 지금보다는 현실화될 수 있다.
따라서 프로젝트 계획 프로세스는 프로젝트 착수 시 프로젝트 수행계획서를 작성하는 것으로 완료되는 것이 아니라 요구사항 변경이 되어 범위가 변경된 경우 프로젝트 관리자는 추정 작업을 다시 수행하고 이를 기반으로 필요한 경우 프로젝트 계획을 수정하고 고객과 합의를 할 수 있는 프로세스가 이행되어야 한다.
형상관리 또한 지금보다 체계적인 관리가 필요한 프로세스 영역이 될 수 있다. 프로젝트 현장에서는 소스 코드에 대해서는 형상관리를 잘 하지만 관리 산출물이나 설계문서에 대해서는 버전 정도만 관리되는 경우가 많다. 하지만 변경에 따른 계약 금액 조정에 근거가 될 수 있는 증빙자료가 권한을 갖지 않은 사람에 의해 훼손되거나 적절한 베이스라인 관리가 되지 않으면 증빙자료로 활용이 될 수 없을 것이다. 따라서 형상관리 프로세스를 보다 엄격하게 적용할 필요가 있다.
발주자의 입장에서 관심을 가져야 할 영역은 CMMI에서 엔지니어링으로 분류되는 프로세스 영역들이다. 설계와 개발이 분할발주 되면 구축할 시스템 요구사항을 적절하게 도출되고 요구사항에 따른 설계가 되었는지 검증할 수 있는 프로세스가 고도화되어야 한다.
소프트웨어 개발의 특성상 설계까지는 가시화된 실체가 없는 경우가 많기 때문에 의도하지 않은 설계가 될 수 있다. 이와 같은 상황이 발생된다면 개발 단계에서 요구사항 변경을 하여야 하고 이는 계약 금액의 조정이 발생할 수 있는 위험이 있다. 따라서 발주자는 설계회사를 선정하는 경우 발주자의 요구사항을 명확히 이해하고 도출할 수 있는 업체를 선정하여야 한다. 개발된 설계문서를 검증하기 위해서는 동료검토 범위를 확장할 필요가 있다.
기존 동료검토는 프로젝트팀 자체적으로 수행되는 경우가 많았지만 발주자가 설계문서의 최종적인 책임을 지는 환경에서는 발주자는 요구사항이 설계문서에 정확하게 반영되었는지 설계 담당자와 상시적으로 점검해야 할 필요가 있다. 설계문서 개발이 완료된 이후에 점검을 하게 된다면 설계문서의 의도된 품질을 확보하지 못할 경우가 발생할 수도 있다. 간략하게 개선이 필요한 프로세스 영역을 점검해 보았지만 필자의 프로세스 개선 경험으로 볼 때 더 많은 프로세스 영역의 개선이 필요할 것으로 예상한다.
지금까지 프로젝트 현장은 범위 관리가 쉽지 않았지만 설계와 개발이 분할발주 되면 프로젝트팀은 범위를 가시적으로 관리할 수는 기반이 조성될 것이다. 또한 프로세스와 절차에 의한 프로젝트를 관리할 수 있는 환경이 구축되었다고 할 수 있다. 프로세스 활용이 필요한 이유는 무엇일까? W. Edwards Deming은 “고객의 기대 수준을 만족하지 못하는 이유의 85%가 조직의 구성원보다는 타당하지 않은 시스템과 프로세스에 기인한다. 경영층의 역할은 개인에게 일을 잘할 것을 요구하기보다는 프로세스를 변화시키는데 있다.”라고 했다.
올바른 프로세스는 고객의 기대수준을 충족할 수 있고, 프로세스에 존재하는 문제를 가시화 시킬 수 있다. 하지만 예측 불가능한 요구사항 변경은 조직이 가지고 있는 프로세스를 적용할 수 있는 기회를 제공하지 못했고 CMMI가 지향하는 프로세스 품질 향상을 통한 제품품질 향상 목표를 실현하기 어려웠다. 이러한 환경에서 소프트웨어 분할발주 정책은 조직의 프로세스 품질을 측정하고 실질적인 프로세스의 적용을 가능하게 하는 단비와도 같다.
향후 소프트웨어 분할발주가 정착되고 프로세스에 의한 프로젝트 관리가 고도화된다면 소프트웨어 품질은 개인의 역량이 아닌 프로세스에 의해 좌우될 것이고 발주자는 설계회사와 개발회사의 프로세스 체계를 점검을 통해 프로젝트의 안정적 관리를 할 수 있는지 역량을 확인할 수 있을 것이다. 따라서 발주자, 설계회사, 개발회사는 소프트웨어 공학과 연관된 프로세스 역량을 향상시켜 나가야 할 것이다.
봄이 어느덧 절정을 향하고 여름의 길목에 서있다. 정부의 희망적인 정책을 통해 소프트웨어 개발자의 열정이 한 여름의 열기같이 뜨겁게 달구어져서 창의적이고 도전적인 인재가 대한민국의 소프트웨어 개발 현장에 가득하길 기대해 본다.
