◆요구사항 관리 시장 규모
IDC조사기관에 의하면 2007년도의 요구사항 관리시장의 규모는 약 2,300억원 이었으며 이는 2006년 대비 12.5%의 성장된 수치이다. 또한 시장규모가 내년 2011년에는 4,600억원 규모의 시장으로 성장할 것으로 내다 보았다. 이는 2006년 부터 2011년 동안 평균 17.4%의 성장을 의미하는 것이다.
필자가 처음으로 요구사항 관리 분야에서 일을 시작한 2000대 초반, 그 때의 국내 요구사항 관리시장 상황은 상대적으로 유럽이나 미국에 비해 상대적으로 뒤떨어져 있었던게 사실이다. 요구사항 관리 컨설팅 업무를 수행하는 해외 지사의 컨설턴트들이 국내에 들어와서 세미나를 하고 국내 고객과 함께 일을 하면서 그들이 했던 말이 생각난다. “한국은 미국이나 유럽에 비해 약 7년 정도 뒤떨어져 있는 것 같다”라고 말했다. 사실 그때 상황으로서는 그렇다고 인정할 수 밖에 없는 상황이었다. 국내 개발자들 중 명함에 요구사항 담당자, 요구사항 관리자, 요구사항 분석가, 비지니스 분석가, 시스템 엔지니어(IT 시스템 엔지니어와는 다름) 등과 같은 직함을 가진 사람이 드물었으며, 국내 대기업의 구인 광고에서 이러한 사람을 뽑는다는 광고를 본 적이 없었다. 또한 요구사항 관리도구가 미국, 유럽시장에서는 굉장히 팔기 쉬운 도구 중 하나라는 말도 덧붙힌 것으로 기억한다.
가장 눈에 띄는 변화의 물결은 국방관련 사업에서 확인할 수 있다. 2009년 현재 방위사업청에서 무기체계 연구개발 사업추진시 체계공학(Systems Engineering) 적용을 의무적으로 하려는 움직임이 있다. 체계공학은 포괄적인 시스템 관점으로 전체 수명주기를 고려한 체계적인 접근법으로 성공적으로 시스템을 개발하기 위한 방법론으로 요구사항 분석, 기능 할당, 추적/변경관리가 핵심적인 프로세스 중 하나이다. 시스템 개발프로젝트에 체계공학을 적용한다는 의미는 프로젝트 산출물(예를 들면 체계규격서, 설계서 등)을 방위사업청이 규정하는 산출물형식(단위 요구사항 식별 및 추적관리표 등이 기본포함)으로 만들어야 함을 의미하기도 한다. 이젠 요구사항의 추적/이력/변경관리는 개발 프로세스 중 반드시 수행해야하는 요소로 자리잡아가려 하고 있다.
체계공학 또는 시스템 공학의 용어는 1950년대 후반 미국에서 우주,국방분야에서 시작된 것이나 현재 민간 업체인 삼성전자, 현대 자동차에서도 이 용어를 일부 사용하고 있으며, 방위사업청, 국방과학 연구소를 포함한 관련 방산업체들이 이 분야에 대한 관심과 적용을 위해 노력하고 있다. 중요한 것은 민수 또는 국방분야에서 공통적으로 요구사항 관리를 통한 시스템 개발을 진행하고 있다는 점이다. 약 10여년 전에는 요구사항 관리의 중요성과 필요성을 단지 알고 있는 수준이었다고 할 수 있다면 현재는 알고 있는 지식을 실제 개발에 적용/시도하려는 단계로 접어들고 있다고 말할 수 있다. 필자가 그동안 요구사항 분야에서 일을 해 오며 직접 수행한 경험을 바탕으로 국내 사례 일부를 간단히 소개하고자 한다.
◆국내외 성공적인 적용 사례
▷자동차 분야
완성차 업체는 수 많은 공급업체를 거느린 보잉과 에어버스와 마찬가지로 시스템 통합 업체(System Integrator)이다. 이들이 가진 이슈 중 하나가 수 많은 공급업체들과의 효과적인 의사소통 방법과 협업, 품질관리방안이다. 개발하고자 하는 시스템에 관한 사양이 정해지면 이를 기준으로 각 서브시스템 사양이 만들어 지고, 해당 업체에게 원하는 사양을 배포하고 이를 납품 받고 검수한 뒤 생산을 하는 방식으로 완성시스템이 만들어 진다. 업체간 공식적인 의사소통의 수단은 기술 문서, 즉 사양서로 이루어 진다. 사양서를 확정하기 위해서는 완성차업체와 공급업체간의 수 많은 기술 협의를 통해 서로 합의과정을 거친 후 사양서를 확정하게 된다. 이 단계 이후로는 개발과정 동안 불가피하게 발생되는 사양서의 변경 관리를 하게된다. 이런 작업을 워드프로세스를 통해 관리를 하다보니 문서의 버전 관리 이슈(잘못된 버전을 가지고 작업을 할 위험)와 기존 사양서와 최신 사양서 사이의 변경부분을 쉽게 찾을 수도 없으며, 무엇 보다도 모든 요구사항을 실제 시스템에 반영되었는지 확인하는 작업을 수행하기 힘들었다.
이에 대한 솔루션으로 IBM Rational(구 Telelogic Professional팀, 이후 2008년 IBM으로 합병)의 서비스 팀이 DOORS를 기반으로 이러한 이슈를 해결할 수 있는 솔루션인 DOORS eXchange를 독일 자동차 업계를 대상으로 개발하였다. DOORS eXchange는 업체간 사양서를 DOORS 모듈로 작성해서 서로 주고 받으며 변경 사항을 자동으로 비교해 변경사항만 자동 업데이트 시켜주며, 서로 버전을 일치 시켜주는 기능을 가지고 있다. 또한 요구사항 간의 추적성 정보까지 자동 업데이트 시켜줌으로써 궁극적으로 지리적으로 떨어진 업체들간의 DOORS DB를 동기화 할 수 있는 기능을 제공한다.
이 솔루션은 현재 독일의 자동차 업계에서 사실상 표준으로 사용하고 있으며, 독일 완성차 업체는 사양서를 DOORS 모듈로 작성해서 eXchange를 사용하여 각 업체들에게 전달하고 있다. 국내에는 H사 및 D사의 일부 팀이 독일 완성차 업체와 함께 DOORS eXchange를 활용하여 특정 시스템의 개발에 참여하고 있다. 최초에 해당 국내 업체의 담당자는 일을 하기 매우 힘들어 했던 것으로 기억한다. 해외 업체들로 부터 요구사항이 분명하게 식별된 상세한 요구사양서를 받고 그들이 요구하는대로 사양서를 작성하다 보니 처음에는 너무 힘들었지만 시간이 지남에 따라 사양서에 어떤 부분을 반영해야 하는지, 누락된 요구사항이 무엇인지를 분명히 알게되어 사양서 품질이 점점 높아짐을 느꼈으며 나중에는 본인들도 업체관리는 이런 방식으로 하는 것이 효과적일 것 같다는 말을 필자에게 한 적이 있다.
국내에는 H사가 2007년 중순에 요구사항 관리도구로 IBM Rational의 DOORS를 표준화도구로 지정한 바있으며, 여러 자동차 1차 협력업체들이 DOORS를 일부 활용하여 사용하고 있다.
▷ 국방분야
먼저 해외사례로 ATWCS(Advanced Tomahawk Weapon Control System)프로그램을 소개한다. 여기서 시사하는 바는 국내에도 그대로 사용할 수 있을 것으로 생각한다. 이 사례는 ATWCS 프로그램에 2년간 DOORS를 적용해 본 후 얻는 투자대비 효과(ROI)를 정리한 것이다.
1) 요구사항 변경율 감소
DOORS를 적용한 이후 요구사항의 변경이 급속히 감소되었다. 예비 SRR(System Requirements Review) 단계 이후의 변경 비율이 DOORS를 적용하기 전에는 72%였으나, DOORS를 적용한 후에는 48%로 줄어들었다. 또한 최종 SRR(System Requirements Review) 단계 이후의 변경율은 33%에서 17%로 줄어들었다고 한다.
2) 변경요청에 따른 변경 구현율
일단 문서에 버전이 올라간 뒤(베이스라인)에 발생하는 요구사항 변경은 형상통제위원회(Configuration Control Board)의 승인을 거쳐야 가능하다. 변경 요청이 왔을때 가장 먼저 해야 하는 작업이 영향 분석(Impact Analysis)을 수행하게 된다. 변경요청을 수락/거부하기 이전에 최초 요구사항을 기반으로 작업했던 모든 부분에 대해 어떤 영향을 미치는 지를 분석하는 과정을 일컫는다. 수작업으로 수행했을 때 평균 8~16시간 걸리던 작업이 DOORS의 추적성 분석기능을 사용했을 땐 1~2분이면 완료할 수 있다. 효과적인 영향분석으로 인해 DOORS 적용 전 변경에 대한 수락율이 98%였던 것이 DOORS를 사용했을 경우는 16%로 줄어들었다. 변경 거부율은 영향분석이 어려운 경우에는 2%에 불과하던 것이 84%로 증가하였다.
3) 테스팅 기간
DOORS를 활용하여 각 요구사항 별로 최소 하나 이상의 테스트케이스를 작성하는 방식으로 추적관리하면서 수 많은 중복된 테스트 케이스와 불필요한 테스트케이스를 발견/제거 할 수 있었으며 누락된 테스트케이스를 추가하는 작업이 수행되었다. 이를 통해 13주 걸리던 시스템 테스기간이 6주로 줄어들었다고 한다.(사용자 수락시험은 22주 걸리던 작업이 10주로 줄었다고 함)
국내에서 DOORS를 도입해서 사용하고 있는 A연구소, L사, S사, K사 등 여러 국방관련 기업, 정부기관 등이 있으며 현재 국가의 방위력 증강 사업의 상당수에 DOORS를 활용하여 체계개발을 수행하고 있으며 필자 역시 현재 4개의 DOORS를 이용한 체계공학 컨설팅서비스를 수행하고 있다.
국방부문에서 DOORS를 활용하는 부분을 아래와 같이 정리할 수 있다.
＊군의 요구사항을 반영하는 시스템 사양서를 만들고 추적성을 확보한다.
＊시스템 사양서를 바탕으로 부체계 사양서를 만들고 시스템 사양서와 추적성을 확보한다.
＊시험 계획서 및 소프트웨어 사양서, 설계서 등의 문서들을 상위 요구사항을 바탕으로 작성하고 추적성을 확보한다.
＊추적성 확보를 통한 각 요구사양서간의 검증 및 테스트 커버리지 분석
＊변경 발생시 영향 분석 수행(End-To-End Traceability)
＊각 검토단계에서 필수 산출물 자동생성
앞에서 언급한 방위사업청에서 제시하는 기준에 맞는 체계공학 산출물들은 각 산출물들간의 단위 요구사항간의 추적성 확보를 강제화하고 있으며, 반드시 문서 산출물에 추적표를 첨부하도록 되어 있다. 이는 누락된 요구사항 및 불필요한 요구사항 식별, 테스트 커버리지 확인을 위한 필수적인 요소이며, 영향분석을 위해 반드시 확보해야 하는 것이다. 국방관련 고객이 Rational DOORS를 도입한 후 ROI측면에서 이런 말을 하였다. “요구사항 검토 회의(SRR) 준비시 검토 문서를 생성하기 위해 모든 체계 팀원들과 협력업체들이 함께 다른 일을 중단하고 1~2주 이상 시간을 소요되던 일이 도구를 사용하면서 1명의 담당자가 1~2일 정도면 충분하게 되었다.”
이 밖에도 금융과 제조업등의 국내외 사례 역시 가지고 있다. 위에서 언급한 ATWCS사례와 유사하게 FDA의 시험기준과 제품사양서간의 엄격한 추적/변경관리를 위해 해외 일부 의료장비업체가 Rational DOORS를 활용하고 있는 사례도 있다.
시간이 정말 돈이라고 생각하는가? 많은 회사들은 우수한 인재를 뽑기 위해 시간을 투자하고 있다. 뛰어난 인재에게 단순 반복적인 작업에 소중한 시간을 투자하게하는 부분이 없는지 생각해 보자. 개발자들의 생산성에 대해 논리적으로 생각을 해 보아야 한다.
요구사항 관리 도구를 통해 고객의 요구사항의 누락을 방지하고, 효과적인 변경 관리와 의사소통을 통한 프로젝트 후반부에서 발생되는 재작업을 줄이고, 테스트 커버리지를 향상시켜 품질을 높히고, 잘못된 버전의 요구사항을 가지고 개발자가 개발하는 오류를 줄여서 프로젝트의 성공확률을 높혀야 한다. 2003년 Standish 자료에서 조사한 바와 같이 대형 IT프로젝트의 실패로 인한 비용 규모가 450조원이나 된다고 한다. 호미로 막을 것을 가래로 막는 우를 범하지 않아야 한다.
-IBM 래쇼날 컨설턴트 김대승 부장