- [SW 형상 관리 Α to Ω] ① SW 변경·품질 좌우한다
- QC/품질관리
- 2005. 12. 13. 14:52
Maincolumn --> //Bottom Menu -->날로 경쟁이 심화되는 IT 분야에서 우리는 소프트웨어의 경쟁력이 바로 IT 비즈니스의 경쟁력으로 인식되는 시대에 살고 있다.
소프트웨어 형상 관리(Software Configuration Management, SCM)는 최근 몇 년 사이에 소프트웨어 품질의 관점에서 아주 중요하게 다뤄지고 있는 분야이다. 특히 프로젝트의 규모가 커짐에 따라, 혹은 프로젝트에서 품질의 요소가 아주 중요한 위치를 차지하고 있는가에 따라 소프트웨어 형상 관리는 그 중요성이 더욱 부각되고 있다.
미국 카네기 멜론 대학의 SEI 연구소에서 개발한 CMM(Capability Maturity Model)과 같은 품질 프레임워크에서는 특정 성숙도 레벨로 진입하기 위해서 반드시 수행해야 할 활동으로 보고 있다.
하지만 현실은 몇몇 대규모 프로젝트나 공공 프로젝트와 같은 엄격한 품질 기준을 적용하는 곳 이외에는 본격적으로 형상 관리 활동을 하는 프로젝트는 사실 별로 많지 않다. 심지어는 소스코드에 대한 버전 관리를 소프트웨어 형상 관리와 같은 의미로 알고 있는 개발자들도 상당수 있다. 버전 관리는 형상 관리의 일부분으로 같은 수준이 아니다.
소프트웨어의 가장 큰 특징은 변경이고, 이 변경으로 인해 소프트웨어라는 이름에 걸맞지 않게 개발과 유지보수를 아주 어렵게 만들어 버린다. 물론 변경이라는 소프트웨어의 큰 특성을 무시할 순 없다. 무시할 수 없기에 수많은 사람들이 이 '변경'이라는 난코스를 슬기롭게 헤쳐나갈 수 있도록 수많은 연구를 해 왔다. 그 중에 하나의 해결책이 바로 소프트웨어 형상 관리이다. 지금부터 소프트웨어 형상 관리에 대해 알아보자.
어느 개발팀의 이야기
약 3개월 기한으로 시작한 프로젝트는 2개월 하고도 반이나 지났지만 도통 끝이 보이지 않는다. 프로젝트 관리자이자 아키텍트를 맡고 있는 고 과장은 하루하루가 마음 졸임의 연속이다. 처음 시작할 때만 해도 비교적 작은 규모의 시스템이었기 때문에 3개월 정도면 무난하리라 생각했다. 그래서 별다른 관리 체계도 만들지 않고 인원도 4명이라 그저 얼굴보고 이야기하면서 개발하면 되리라 생각했다.
하지만 프로젝트가 점점 수렁에 빠져드는 듯한 느낌을 받기 시작한 것은 약 1개월 정도가 지나서였다. 갑자기 어느 팀원이 건강상의 이유로 회사를 퇴사해 버리고 그가 맡은 업무는 전부 중지되어 버렸다. 부랴부랴 사람을 수소문해서 채워놨지만 제대로 된 문서 하나 만들어 놓지 않았기 때문에 몇 명 되지도 않는 팀에서 한 명을 뽑아 신입 팀원의 교육을 3일간 맡아야 했다.
이런 일이 있은 후에 부랴부랴 고 과장은 당장 필요한 요구사항에 관한 산출물과 설계 산출물을 작성하기 시작했다. 물론 이런 산출물의 작성 기간은 프로젝트 기간에 들어있지 않았기 때문에 프로젝트 지연을 막고자 거의 1주일간을 밤샘 작업을 해야만 했다.
문서작업 후 어느 정도 프로젝트가 잘 굴러가나 싶었는데 더 심각한 문제는 약 2개월 정도가 지난 다음에 나타났다. 주요 기능과 프레임워크를 개발하고 난 뒤 고객에게 시연해야 하는 시기가 되어 바쁘게 준비를 하고 있었다. 그런데 팀에 마가 끼었는지 한 팀원의 컴퓨터가 바이러스에 감염되어 그 안에 있던 모든 소스코드와 각종 스크립트가 한 순간에 날아가 버렸다.
산출물을 한군데 관리하지 않고 문서 종류만 중앙 파일 서버에 관리한 채 각자의 소스코드는 개별 PC에 저장해 놓고 개발하는 형태로 진행했던 것이 화근이었다. 그때까지만 해도 각자의 소스코드를 파일 서버에 올리는 것은 각 개발자의 부지런함에 맡겨놓고 있던 실정이었다. 바이러스에 감염되어 소스코드를 전부 잃어버린 개발자는 그 중에서 가장 부지런하지 않던 사람이었다.
그나마 파일 서버에 올려놨던 가장 최근의 소스코드를 받아 새로 만드느라 또다시 철야 근무를 하며 며칠을 보냈고 고객의 신뢰는 점점 없어지고 있었다. 충격을 심하게 받은 개발팀은 CVS(Concurrent Versions System)라는 오픈소스 버전 관리 도구를 파일 서버에 설치하고 모든 문서와 소스코드, 스크립트를 CVS에 등록했다. 프로젝트가 거의 끝나가는 시점에 개발 도구와 CVS를 연동하여 본격적인 개발 환경을 그제서야 만들었다.
이제는 갖출 것은 다 갖췄다고 생각한 개발자들은 남은 한달 바짝 해서 구겨진 프로젝트를 그나마 본궤도에 올리려고 그야말로 화장실 가는 시간도 없이 열심히 일을 했다. 하지만 운명은 그들을 그냥 놔두지 않았다. 프로젝트가 거의 종료되어 갈 시점에 팀을 절망하게 만드는 상황이 발생하기 시작했다.
규모는 작지만 영어와 중국어를 지원해야 하고 국내에서도 여러 곳에서 운영되어야 하는 요구사항이 있었다. 개발이 거의 완료되었다는 소식을 들은 고객은 본격적으로 영업을 하기 시작했고, 미국과 중국을 비롯해 국내 여러 곳에 시스템을 배포해야 한다는 요청을 했다. 시스템이 고객사로 인도되기 시작하면서부터 다양한 요구사항들이 쇄도하고 개발팀은 그 요구사항에 맞춰 그때그때 소스코드를 수정해 나가기 시작했다.
그런데 문제는 시간이 지남에 따라 각 고객사별로 소프트웨어의 버전이 차이가 나면서 어떤 고객사의 요구사항이 어떤 버전인지 도저히 알 수 없는 지경에 이르게 되었다. 소스코드가 점점 누더기로 변해 갔고 이전에는 없었던 버그가 하나 둘씩 나타나기 시작했다. 그저 매일같이 소스코드 한 줄 한 줄 따라가며 끔찍한 디버깅 작업을 끝도 없이 해야 했다.
만약 형상 관리의 분기와 병합, 베이스라인, 베이스라인 프로모션(baseline promotion), 변경 추적과 형상 감사와 같은 개념을 알고 활용했다면 변경에 대한 요청에 체계적으로 대응하여 매일같이 새롭게 등장하는 버그와 씨름하지 않았어도 됐을지 모른다.
지금까지 형상 관리를 하지 않고 별다른 문제없이 개발을 끝냈다면 분명 운이 좋은 경우라 할 수 있지만 아마 이런 경우를 한두 번씩 겪었으리라 생각된다. 만약 고과장의 팀이 프로젝트를 시작하면서 간단하게나마 소프트웨어 개발 프로세스를 정립하고 프로젝트 상황에 맞게 형상 관리 계획을 세웠으면 어떠했을까? 아마 이런 어이없는 일이 일어날 확률은 많이 줄어들었을 것이다.
결론적으로 형상 관리는 소프트웨어 개발을 확실하게 도와준다. 부가적으로 수행해야 할 활동이 늘어나긴 하지만 분명 그 이상의 효과를 볼 수 있다.
뭔가 만드는 곳은 변경을 관리한다
소프트웨어를 개발하는 일과 자동차를 만드는 일은 다르지만 수많은 부분으로 구성되고 많은 사람들이 참여하여 만든다는 본질은 유사하리라 생각된다.
자동차 한 대는 최소 구성단위로 완전히 분해할 때 2만개의 부품으로 구성되고 거기에 부품 번호를 부여한다. 하나의 단가를 구성해 관리하는 엔드 아이템(end item) 단위로 보면 수천여 개의 부품이 들어간다고 한다. 자동차 회사에서는 이렇게 많은 부품을 관리하기 위해 각 부품을 부분별로 구분하고 각 부품간의 관계를 정의한다. 이를 보통 BOM(Bill of Material)이라고 하여 산업공학에서는 커다란 연구 분야로 꼽는다.
자동차 회사에서 이렇게 수많은 부품으로 구성되는 자동차를 개발하기 위해서는 아주 철저한 개발 프로세스를 적용한다. 자동차의 초기 컨셉이 정해지고 나면 그것에 디자인과 각 부분별 설계가 진행되고 모델고정 시점이 되면 프로토타입 차, 시작 차와 같이 실제로 자동차를 만들어 테스트를 실시한다.
자동차 각 부분에 대한 부품설계 및 디자인을 진행하는 와중에도 지속적인 설계 변경이 일어나게 된다. 자동차 회사 역시 설계 변경을 관리하기 위해 엄격한 형상 관리(물론 자동차 회사에서는 형상 관리라는 말은 쓰지 않는다)를 적용하고 있다.
하나의 변경이 발생하기 위해서는 ECO(Engineering Change Order)를 발행하고, 변경에 따른 영향도 분석은 관련 부서의 협력을 통해 얻어내어 최종 결정을 한다. 자동차 회사에서는 이와 같은 변경 프로세스를 아주 철저히 지키며 그 누구도 귀찮다거나 쓸데없는 일 때문에 개발 기간이 늘어난다고 생각하지 않는다.
오히려 프로세스가 없다면 제대로 된 자동차 설계가 되지 않을 것으로 생각한다. 비단 자동차 회사뿐만 아니라 무엇인가 만드는 곳에서는 변경을 아주 중요하게 생각하고 철저히 관리한다.
이제 소프트웨어 개발 현장으로 넘어와 보자. 이상하게도 소프트웨어를 개발하는 곳은 변경이라는 것을 그리 중요한 요소로 생각하지 않는다. 소프트웨어 개발 과정도 초기 컨셉이 결정되면 요구사항 파악부터 분석/설계과정을 거처 구현/테스트를 통해 소프트웨어를 릴리즈하고 유지보수 단계로 접어든다.
요구사항에서부터 최종 릴리즈까지 진행하면서 소프트웨어는 수많은 변경을 겪는다. 수시로 바뀌는 요구사항 때문에 설계를 변경해야 하고 소스코드를 뜯어 고쳐야 한다. 또한 요구사항을 잘못 이해하는 바람에 변경이 발생하고, 소프트웨어의 결함 때문에 변경을 해야 한다.
하나의 변경은 그에 수반된 여러 부분의 변경을 파생시킨다. 또한 하나의 변경으로 인해 다른 부분의 안정성도 보장받지 못할 수 있다. 따라서 변경에 대한 영향을 파악해야 하고 변경을 받아들이기 위해서는 얼마 만큼의 노력이 필요한지 알아야 한다.
그럼에도 불구하고 왜 변경에 대해 관리하지 않는 것일까? 소프트웨어 개발 시에 변경 관리가 용이하지 않은 가장 큰 이유는 '변경이 쉽다'라는 것이다. 적어도 자동차를 만드는 것보다는 쉬울 수 있다. 변경이 쉽기 때문에 너무 빈번하게 일어나고 자연스럽게 생각한다. 사소한 변경이든 중대한 변경이든 변경은 통제 대상에 놓여야 한다. 특히 형상 관리 대상으로 결정된 산출물은 엄격히 관리되어야 한다.
바꾸려는 사람과 안 바꾸려는 사람
프로젝트 현장에서 변경에 대한 시각은 이해관계에 따라 서로 다르다. 개발한 소프트웨어를 사용해야 하는 사람들은 개발 완료 시점이 다 되어 갈수록 아이디어가 샘솟기 때문에 자신의 아이디어를 어떻게든 반영하려고 노력한다. 반면 소프트웨어를 개발하는 사람들은 초기에 결정했던 고객의 요구사항을 어떻게든 바꾸지 않고 끝까지 끌고 가려고 노력한다.
변경의 정당성을 주장하는 고객의 논리는 지금 이 변경을 적용하지 않으면 결국 쓸모없는 소프트웨어가 된다는 것이다. 바꿔 말하면 변경하지 않을 경우 안 쓰겠다는 거의 반 협박성의 주장이다. 대가를 받고 소프트웨어를 개발하는 입장에서 들을 때는 검수해 주지 않겠다는 생존의 위협을 느끼게 하는 대목이다.
검수받지 못하면 잔금을 받을 수 없다. 반면 개발하는 사람들은 지금 변경하면 다른 부분에 영향이 많기 때문에 혹은 아키텍처가 흔들리기 때문에 시스템의 안정성을 보장할 수 없다고 한다. 여력만 있다면 바꿔주겠지만 현재 남은 기간으로는 도저히 반영할 수 없는 상황이라고 반론을 편다.
이때 변경 통제가 어느 정도 효과를 발휘할 수 있다. 변경 통제라는 것은 앞에서도 잠깐 언급했지만 소프트웨어 개발 기간 동안 발생하는 주요 변경사항을 평가 및 승인하여 변경사항이 소프트웨어의 각 부분에 어떤 영향을 주는지 알아내어 해당 이해관계자에게 어떤 영향을 주는지 알리는 것을 의미한다.
만약 고객의 변경이 불필요한 것이라면 관련 당사자를 의사결정에 참여시켜 조목조목 따져봄으로써 변경에 대한 영향을 가시화해 볼 수 있게 되므로 고객의 주장대로 정말 못 쓸 정도의 소프트웨어가 개발되는 것인지 반대로 개발팀의 주장대로 아키텍처가 흔들릴 정도로 엄청난 변경을 가하게 되어 안정성을 해치게 되는지, 남은 기간에 도저히 적용할 수 없는 수준의 변경인지 판단할 여력이 생긴다. 만약 소위 막가파 식으로 밀어붙이는 것만 아니라면 서로 얼굴 붉히지 않고 합리적인 수준에서 협의할 수 있는 근거가 만들어 질 수 있다.
형상 관리는 무엇인가?
지금까지 여러 가지 형상 관리와 관련된 사항들, 왜 형상 관리가 필요한지, 다른 분야에서는 형상 관리 같은 것을 하는지, 사람들의 관점은 어떤지 이야기했다. 이제 본격적으로 형상 관리에 대해 알아보자.
형상 관리는 1960년대에 등장하여 1970년대에 미 국방부의 밀리터리 스탠더드(Military Standard)의 일부로 만들어졌다. 이후 지속적으로 발전하다가 1990년대 들어 컴퓨팅 환경이 복잡해지고 품질기준이 엄격해지면서 본격적으로 적용되기 시작했다. 형상관리에 관하여 많은 정의가 존재하지만 가장 많이 보는 2가지를 살펴보자.
◆ 형상 항목을 식별하여 그 기능적 물리적 특성을 문서화하고, 그러한 특성에 대한 변경을 제어하고, 변경 처리 상태를 기록 및 보고하고, 명시된 요구사항에 부합하는지 확인하는 일련의 사항에 대해 기술적 행정적인 지침과 사후 관리를 적용하는 원칙 - IEEE Standard Glossary of Software Engineering Terminology(1991)
◆ 전체 소프트웨어 공학 과정에 적용되는 '보호(Umbrella)' 활동이다. 변경은 언제나 일어날 수 있기 때문에, SCM(Software Configuration Management) 활동은 (1)변경을 알아내기 위해서 (2)변경을 제어하기 위해서 (3)변경의 적절히 수행되고 있는 것을 확인하기 위해 (4)변경에 관심을 가지고 있는 사람들에게 이것을 통보하는 것이다. - Roger's S Pressman, "Software Engineering : A Practitioner's Approach , 3rd Edition"(1995)
이와 같은 정의에서와 같이 대부분의 정의에서 형상 관리라 함은 크게 4가지로 나눈다.
◆ 우선 형상관리의 대상이 무엇인지 식별하여 형상항목(configuration item)이라고 한다.
◆ 식별한 형상 항목의 버전(version control)과 변경을 통제(change control)라고 한다.
◆ 형상항목의 변경이 제대로 이뤄졌는지 살펴보는데, 형상 감사(configuration audit)라 한다.
◆ 변경된 형상 항목을 관계된 사람들에게 알리는데 이를 상태 보고(status reporting)라 한다.
형상 관리의 대상인 형상 항목을 생각해보면 형상 관리는 특성상 소프트웨어의 모든 부분에 영향을 주고 영향을 받는다. 단순히 바이너리 형태의 파일이나 소스코드에만 범위에 해당하는 것이 아니라 문서형식의 산출물, 각종 스크립트, 소프트웨어를 개발 이력 등이 해당한다. 또한 소프트웨어를 개발하는 사람들과 조직, 소프트웨어 개발 프로세스, 소프트웨어가 탑재된 하드웨어 및 네트워크 등도 해당된다.
형상 관리에서 말하는 형상(configuration)은 그 의미를 광의적으로 해석했을 때 사실 소프트웨어 그 자체이다. 소프트웨어는 PC에서 실행되는 작은 규모도 있고 네트워크와 연결되어 복수 개의 서버에서 운영되는 크고 복잡한 규모의 것도 있다. 따라서 엄밀히 따지면 소프트웨어를 구성하는 모든 것으로 볼 수 있으며 소프트웨어를 만드는 사람과 회사, 소프트웨어를 탑재하는 하드웨어 및 각종 컨피규레이션(configuration), 소프트웨어 그 자체, 소프트웨어 개발 프로세스, 형상 관리를 하기 위한 형상 관리 도구와 개발 도구 등이 해당한다.
형상 항목의 상태 변경에 따른 형상 관리
사실 형상 관리의 가장 큰 목적은 변경에 의해 점차적으로 변해가는 소프트웨어의 형상을 관리함에 있다. 형상 항목의 변경은 특정 상태를 거쳐 이뤄지는데 그 흐름을 그림으로 표시하면 <그림 1>과 같다.
형상 항목의 라이프 사이클은 크게 6단계의 상태로 볼 수 있는데 개발 초기에 개발 중이라는 상태에 위치하게 된다. 일단 개발이 어느 정도 완료되면 단위 테스트(unit test)를 준비하고 테스트를 통과하면 시스템 테스트 준비상태로 변하게 된다.
시스템 테스트(system test)도 아무런 이상 없이 통과하면 수락 테스트(acceptance test) 준비상태로 되고 이후 모든 결함(defect)을 제거하면 베이스라인(baseline)을 확정하고 제품을 릴리즈하게 된다. 이때 각 테스트 상태에서 결함이 발견되면 그 전 상태로 돌아가고 발견한 모든 결함을 제거할 때까지 과정을 반복하게 된다.
앞에서 언급한 형상 관리의 정의에 따라 <그림 1>의 형상 관리 품목의 라이프 사이클을 살펴보면 우선 식별한 형상 항목을 최초로 작성하고 각 테스트를 거치면서 형상 항목을 변경하거나 수정한다. 단위 테스트의 경우 단위 프로그램의 결함 여부를 찾아내는 것이므로 주로 수정의 경우에 해당된다고 할 수 있다.
이 때 개발자가 작성한 프로그램의 경우 결함에 의해 수정되어 버전 통제를 받게 된다. 만약 단위 테스트 결과로 형상 항목의 구성에 포함되어 있다면 프로그램과 해당 단위 테스트의 결과는 서로 관계를 맺고 변경 요청에 의한 변경 통제 프로세스를 따라 진행될 것이다.
단위 테스트를 통과한 단위 프로그램들은 의미 있는 집합으로 묶여 시스템 테스트의 대상이 된다. 이때도 역시 결함이 발견되면 변경 통제 프로세스에 따라 진행한다. 수락 테스트는 주로 소프트웨어의 요구사항과 직접적으로 연관되어 있으므로 변경 통제 절차가 강화되고 요구사항과 변경과의 추적(trace)을 관리해야 한다. 베이스라인 확정 상태는 수락 테스트까지 마친 상태에서 프로젝트 진행 상태의 기준이 되는 아주 중요한 지표가 된다. 한번 확정한 베이스라인은 뒤로 바꿀 수 없다.
프로세스 관점에서 형상 관리 활동
지금까지 형상 항목의 상태에 따른 라이프 사이클을 중심으로 봤다면 이제 프로세스 관점에서 형상 관리 활동을 중심으로 살펴보자. ‘오류! 참조 원본을 찾을 수 없습니다’는 형상 관리 활동을 전반적으로 나타낸 것으로 Anne Mette Jonassen Hass의 『Configuration management principles and practice(2002)』에서 나오는 원래의 그림은 원문자와 곡선 화살표가 없는데 이는 더 용이한 설명을 위해 필자가 첨부한 것이다.
<그림 2>에서 굵은 선으로 둘러싸인 부분이 형상 관리의 범위이다. 여기에는 형상식별(Identification)과 통제 상에 놓여 있는 저장소(controlled storage), 변경 관리(change control), 상태 보고(status reporting)가 형상 관리의 활동이다. 여기서 형상 감사(audit) 부분은 각종 테스트와 검사에 관계된 활동으로 순수 형상 관리의 활동으로 보기 보다는 품질보증(quality assurance)의 일환으로 보는 관점이 있어 형상 관리의 정의에는 포함되나 그림 상으로는 굵은 선 박스의 외부에 위치시켰다.
그림 상으로 드럼통 모양은 데이터베이스 표식으로 저장소 데이터베이스, 변경 관리 데이터베이스, 메타 데이터베이스가 있다. 이들은 형상 관리를 위한 프로젝트 데이터베이스로 형상 항목의 그 자체를 저장하고(controlled storage), 변경에 관한 이력과 각종 정보를 저장하며(change control), 형상 항목에 대한 이름, 작성자, 생성 날짜와 다른 형상 항목과의 관계를 저장(metadatabase)한다.
그림에서 각 번호는 형상관리 활동을 나타낸 것이다. ①은 형상 관리 계획(configuration management plan)에 따른 형상 식별 활동이다. 우선 프로젝트에서는 프로젝트 계획의 일환으로 작성한 형상 관리 계획을 근거로 형상항목을 식별하여 메타 데이터 베이스에 입력한다. 이때 형상 항목을 유일하게 식별할 수 있도록 형상 항목의 이름, 작성자(author), 생성일, 문서인 경우 문서번호, 다른 형상 항목과의 관계 등을 저장하고 이때부터는 변경 관리의 대상이 된다.
②는 아직 형상 관리 범위 안으로 들어오지 못한 형상 항목의 생성 과정을 나타낸다. 프로덕션(production)은 현재 변경 중인 상태의 항목을 의미한다. 이때까지는 변경 통제의 대상에 포함되지 않는다. ③은 감사를 거쳐 변경할 수 없는 상태의 형상 항목을 구분된 장소에 두는 활동을 의미한다. 이때 보통 테스트를 거치는데 변경 중인 형상 항목과 더 이상의 변경이 없는 항목의 구분을 위해 존재한다. 이 분에서도 역시 변경 통제의 대상에 두지 않는다.
④에서는 ③을 거쳐 나온 항목을 비로소 변경 통제의 대상에 등록하는 활동이다. 이때 누가 왜 무엇을 언제 바꾸었는지 변경관리 데이터베이스에 기록된다. ⑤는 변경 통제 하에 있는 항목의 상태를 리포팅(status reporting)하는 활동이다.
지금까지 형상 관리의 정의와 형상 관리의 대상이 되는 항목의 상태 변화와 형상 관리 활동을 중심으로 살펴보았다. 주로 형상 관리 자체만을 갖고 설명했으므로 피상적이고 따분하겠지만 우선 이런 것이구나 하는 수준으로 접근했으면 한다.
CMM과 형상 관리
여기서 CMM은 정확히 말하자면 SW-CMM으로 소프트웨어 개발 역량을 평가하기 위한 성숙도 모델이다. 여기에는 실제 실행 지침과 소프트웨어 프로세스 개선, 소프트웨어 프로세스 평가를 수행하는 개별 작업자의 요구를 반영한다. 또한 문서화되고 공개적으로 사용 가능하다. CMM의 태동을 주도한 미 국방부의 연구에 따르면 소프트웨어 개발 프로젝트의 성공과 실패를 결정짓는 주요 원인은 기술이라기보다는 관리의 문제라는 결론을 내렸다.
따라서 소프트웨어 개발 조직의 성숙도에 따라 소프트웨어의 품질은 많은 차이를 보인다. 그 이유로는 미성숙한 개발 조직의 경우 소프트웨어의 품질의 좋고 나쁨을 판단하는 객관적인 기준이 없고, 소프트웨어 프로세스가 품질에 어떻게 영향을 미치는지에 대한 이해가 없으며, 정형화된 테스트나 검토와 같은 품질 보증 활동은 이런 저런 이유로 축소되거나 생략된다. 개발팀은 사소한 문제로도 우왕좌왕하고 개인의 역량에 의지하여 해결하려고 한다. 따라서 고객은 최종 인도 이전에는 그들이 사용할 소프트웨어가 어떻게 작동하는지 알 수 없게 된다.
하지만 개발 역량이 성숙한 조직은 프로세스를 적극 활용하여 개발팀이 그들이 맡은 임무에 따라 일사 분란하게 움직이도록 훈련이 되어 있다. CMM은 개발 역량이 성숙한지 아닌지를 평가하기 위해 5단계의 레벨을 두고 있다. 각 레벨의 특징은 <표 1>과 같다.
이 5레벨에서 우리가 지금 이야기하고 있는 소프트웨어 형상 관리는 어느 레벨의 인증을 위한 핵심 프로세스에 해당할까? 높은 레벨일 듯 싶지만 겨우 레벨 2이다. 이 정도면 이제 겨우 조직적으로 개발 좀 한다는 소리를 듣는 단계의 시작이다.
CMM에서는 레벨 2에서 소프트웨어 요구사항관리와 함께 형상 관리가 핵심 프로세스 영역(KPA : Key Process Area)으로 되어 있다. 성숙도 레벨에 따른 핵심 프로세스 영역은 <그림 3>과 같다.
반복 레벨의 인증을 받기 위해서라도 이것저것 관리해야 할 것이 태산이다. 그 중 CMM이 인정할만한 소프트웨어 형상관리는 어떤 수준인지 살펴보자.
CMM의 형상 관리 가이드
CMU/SEI에서 작성한 『The Capability Maturity Model: Guide for Improving the Software Process, 1st Edition(1994)』을 토대로 CMM이 레벨 2 수준의 형상 관리를 위해서는 목표에 따른 어떠한 수행능력(Ability to Perform)이 있어야 하는지 살펴보자.
[1] 프로젝트 소프트웨어 기준선을 관리할 수 있는 권한을 가진 위원회(즉, 형상통제위원회, SCCB : Software Configuration Control Board)가 존재하거나 없다면 설립한다.
[2] 프로젝트를 위한 SCM의 조정과 구현에 책임을 가진 그룹(즉, SCM 그룹)이 존재한다.
[3] SCM 활동 수행을 위해 적절한 자원과 자금이 지원된다.
[4] SCM 그룹의 구성원들은 SCM 활동을 수행하기 위한 목표, 절차, 방법 등에 대해 교육을 받는다.
[5] 소프트웨어 엔지니어링 그룹과 다른 소프트웨어 관련 그룹의 구성원들은 SCM 활동을 수행하는 데 필요한 교육을 받는다.
이와 같이 총 5가지의 수행능력을 바탕으로 형상 관리 활동을 실시해야 한다. 어떻게 보면 그야말로 딱딱한 법전 같은 가이드지만 결국 요약하면 프로세스 상에서 권한과 책임을 줘 결정하고 승인할 역할을 만든다. 또한 결정에 따라 형상 관리를 수행할 조직을 만들고, 수행할 사람들에게 교육을 제공해야 한다는 것이다.
너무나 상식적이고 당연한 형상관리
『소프트웨어 공학의 사실과 오해』를 저술한 로버트 L. 글래스는 개발자의 능력에 따라 생산성이 28배까지 차이 난다는 사실을 이야기한바 있다. 어마어마한 수치임에 틀림없다. 실제로 누구나 아는 사실이겠지만 어려운 난관에 부딪히면 초보개발자 100명이 달라붙어도 해결하지 못할 문제를 고급 개발자는 점심시간에 자장면 먹어가며 한 손으로 타이핑 몇 번 만에 해결할 수 있다. 이것은 사실을 넘어서 부인할 수 없는 진실이다.
하지만 조직적으로 소프트웨어를 개발할 때는 어려운 문제만 있는 것이 아니라 해결 가능한 평이한 문제들이 절대 다수를 차지하고 이것들은 서로 관계를 갖고 복잡도를 증가시킨다. 또 끊임없이 변한다.
이렇게 복잡하면서 지속적으로 변하는 소프트웨어라는 괴물을 어떻게 다루는가가 형상 관리의 주된 목적이다. 형상 관리는 반드시 되어야 한다. 그 과정도 너무나 상식적이고 당연하다.@
출처 : 이 기사는 ZDNet Korea의 제휴매체인 마이크로소프트웨어에 게재된 내용입니다.
소프트웨어 형상 관리(Software Configuration Management, SCM)는 최근 몇 년 사이에 소프트웨어 품질의 관점에서 아주 중요하게 다뤄지고 있는 분야이다. 특히 프로젝트의 규모가 커짐에 따라, 혹은 프로젝트에서 품질의 요소가 아주 중요한 위치를 차지하고 있는가에 따라 소프트웨어 형상 관리는 그 중요성이 더욱 부각되고 있다.
미국 카네기 멜론 대학의 SEI 연구소에서 개발한 CMM(Capability Maturity Model)과 같은 품질 프레임워크에서는 특정 성숙도 레벨로 진입하기 위해서 반드시 수행해야 할 활동으로 보고 있다.
하지만 현실은 몇몇 대규모 프로젝트나 공공 프로젝트와 같은 엄격한 품질 기준을 적용하는 곳 이외에는 본격적으로 형상 관리 활동을 하는 프로젝트는 사실 별로 많지 않다. 심지어는 소스코드에 대한 버전 관리를 소프트웨어 형상 관리와 같은 의미로 알고 있는 개발자들도 상당수 있다. 버전 관리는 형상 관리의 일부분으로 같은 수준이 아니다.
소프트웨어의 가장 큰 특징은 변경이고, 이 변경으로 인해 소프트웨어라는 이름에 걸맞지 않게 개발과 유지보수를 아주 어렵게 만들어 버린다. 물론 변경이라는 소프트웨어의 큰 특성을 무시할 순 없다. 무시할 수 없기에 수많은 사람들이 이 '변경'이라는 난코스를 슬기롭게 헤쳐나갈 수 있도록 수많은 연구를 해 왔다. 그 중에 하나의 해결책이 바로 소프트웨어 형상 관리이다. 지금부터 소프트웨어 형상 관리에 대해 알아보자.
어느 개발팀의 이야기
약 3개월 기한으로 시작한 프로젝트는 2개월 하고도 반이나 지났지만 도통 끝이 보이지 않는다. 프로젝트 관리자이자 아키텍트를 맡고 있는 고 과장은 하루하루가 마음 졸임의 연속이다. 처음 시작할 때만 해도 비교적 작은 규모의 시스템이었기 때문에 3개월 정도면 무난하리라 생각했다. 그래서 별다른 관리 체계도 만들지 않고 인원도 4명이라 그저 얼굴보고 이야기하면서 개발하면 되리라 생각했다.
하지만 프로젝트가 점점 수렁에 빠져드는 듯한 느낌을 받기 시작한 것은 약 1개월 정도가 지나서였다. 갑자기 어느 팀원이 건강상의 이유로 회사를 퇴사해 버리고 그가 맡은 업무는 전부 중지되어 버렸다. 부랴부랴 사람을 수소문해서 채워놨지만 제대로 된 문서 하나 만들어 놓지 않았기 때문에 몇 명 되지도 않는 팀에서 한 명을 뽑아 신입 팀원의 교육을 3일간 맡아야 했다.
이런 일이 있은 후에 부랴부랴 고 과장은 당장 필요한 요구사항에 관한 산출물과 설계 산출물을 작성하기 시작했다. 물론 이런 산출물의 작성 기간은 프로젝트 기간에 들어있지 않았기 때문에 프로젝트 지연을 막고자 거의 1주일간을 밤샘 작업을 해야만 했다.
문서작업 후 어느 정도 프로젝트가 잘 굴러가나 싶었는데 더 심각한 문제는 약 2개월 정도가 지난 다음에 나타났다. 주요 기능과 프레임워크를 개발하고 난 뒤 고객에게 시연해야 하는 시기가 되어 바쁘게 준비를 하고 있었다. 그런데 팀에 마가 끼었는지 한 팀원의 컴퓨터가 바이러스에 감염되어 그 안에 있던 모든 소스코드와 각종 스크립트가 한 순간에 날아가 버렸다.
산출물을 한군데 관리하지 않고 문서 종류만 중앙 파일 서버에 관리한 채 각자의 소스코드는 개별 PC에 저장해 놓고 개발하는 형태로 진행했던 것이 화근이었다. 그때까지만 해도 각자의 소스코드를 파일 서버에 올리는 것은 각 개발자의 부지런함에 맡겨놓고 있던 실정이었다. 바이러스에 감염되어 소스코드를 전부 잃어버린 개발자는 그 중에서 가장 부지런하지 않던 사람이었다.
그나마 파일 서버에 올려놨던 가장 최근의 소스코드를 받아 새로 만드느라 또다시 철야 근무를 하며 며칠을 보냈고 고객의 신뢰는 점점 없어지고 있었다. 충격을 심하게 받은 개발팀은 CVS(Concurrent Versions System)라는 오픈소스 버전 관리 도구를 파일 서버에 설치하고 모든 문서와 소스코드, 스크립트를 CVS에 등록했다. 프로젝트가 거의 끝나가는 시점에 개발 도구와 CVS를 연동하여 본격적인 개발 환경을 그제서야 만들었다.
이제는 갖출 것은 다 갖췄다고 생각한 개발자들은 남은 한달 바짝 해서 구겨진 프로젝트를 그나마 본궤도에 올리려고 그야말로 화장실 가는 시간도 없이 열심히 일을 했다. 하지만 운명은 그들을 그냥 놔두지 않았다. 프로젝트가 거의 종료되어 갈 시점에 팀을 절망하게 만드는 상황이 발생하기 시작했다.
규모는 작지만 영어와 중국어를 지원해야 하고 국내에서도 여러 곳에서 운영되어야 하는 요구사항이 있었다. 개발이 거의 완료되었다는 소식을 들은 고객은 본격적으로 영업을 하기 시작했고, 미국과 중국을 비롯해 국내 여러 곳에 시스템을 배포해야 한다는 요청을 했다. 시스템이 고객사로 인도되기 시작하면서부터 다양한 요구사항들이 쇄도하고 개발팀은 그 요구사항에 맞춰 그때그때 소스코드를 수정해 나가기 시작했다.
그런데 문제는 시간이 지남에 따라 각 고객사별로 소프트웨어의 버전이 차이가 나면서 어떤 고객사의 요구사항이 어떤 버전인지 도저히 알 수 없는 지경에 이르게 되었다. 소스코드가 점점 누더기로 변해 갔고 이전에는 없었던 버그가 하나 둘씩 나타나기 시작했다. 그저 매일같이 소스코드 한 줄 한 줄 따라가며 끔찍한 디버깅 작업을 끝도 없이 해야 했다.
만약 형상 관리의 분기와 병합, 베이스라인, 베이스라인 프로모션(baseline promotion), 변경 추적과 형상 감사와 같은 개념을 알고 활용했다면 변경에 대한 요청에 체계적으로 대응하여 매일같이 새롭게 등장하는 버그와 씨름하지 않았어도 됐을지 모른다.
지금까지 형상 관리를 하지 않고 별다른 문제없이 개발을 끝냈다면 분명 운이 좋은 경우라 할 수 있지만 아마 이런 경우를 한두 번씩 겪었으리라 생각된다. 만약 고과장의 팀이 프로젝트를 시작하면서 간단하게나마 소프트웨어 개발 프로세스를 정립하고 프로젝트 상황에 맞게 형상 관리 계획을 세웠으면 어떠했을까? 아마 이런 어이없는 일이 일어날 확률은 많이 줄어들었을 것이다.
결론적으로 형상 관리는 소프트웨어 개발을 확실하게 도와준다. 부가적으로 수행해야 할 활동이 늘어나긴 하지만 분명 그 이상의 효과를 볼 수 있다.
뭔가 만드는 곳은 변경을 관리한다
소프트웨어를 개발하는 일과 자동차를 만드는 일은 다르지만 수많은 부분으로 구성되고 많은 사람들이 참여하여 만든다는 본질은 유사하리라 생각된다.
자동차 한 대는 최소 구성단위로 완전히 분해할 때 2만개의 부품으로 구성되고 거기에 부품 번호를 부여한다. 하나의 단가를 구성해 관리하는 엔드 아이템(end item) 단위로 보면 수천여 개의 부품이 들어간다고 한다. 자동차 회사에서는 이렇게 많은 부품을 관리하기 위해 각 부품을 부분별로 구분하고 각 부품간의 관계를 정의한다. 이를 보통 BOM(Bill of Material)이라고 하여 산업공학에서는 커다란 연구 분야로 꼽는다.
자동차 회사에서 이렇게 수많은 부품으로 구성되는 자동차를 개발하기 위해서는 아주 철저한 개발 프로세스를 적용한다. 자동차의 초기 컨셉이 정해지고 나면 그것에 디자인과 각 부분별 설계가 진행되고 모델고정 시점이 되면 프로토타입 차, 시작 차와 같이 실제로 자동차를 만들어 테스트를 실시한다.
자동차 각 부분에 대한 부품설계 및 디자인을 진행하는 와중에도 지속적인 설계 변경이 일어나게 된다. 자동차 회사 역시 설계 변경을 관리하기 위해 엄격한 형상 관리(물론 자동차 회사에서는 형상 관리라는 말은 쓰지 않는다)를 적용하고 있다.
하나의 변경이 발생하기 위해서는 ECO(Engineering Change Order)를 발행하고, 변경에 따른 영향도 분석은 관련 부서의 협력을 통해 얻어내어 최종 결정을 한다. 자동차 회사에서는 이와 같은 변경 프로세스를 아주 철저히 지키며 그 누구도 귀찮다거나 쓸데없는 일 때문에 개발 기간이 늘어난다고 생각하지 않는다.
오히려 프로세스가 없다면 제대로 된 자동차 설계가 되지 않을 것으로 생각한다. 비단 자동차 회사뿐만 아니라 무엇인가 만드는 곳에서는 변경을 아주 중요하게 생각하고 철저히 관리한다.
이제 소프트웨어 개발 현장으로 넘어와 보자. 이상하게도 소프트웨어를 개발하는 곳은 변경이라는 것을 그리 중요한 요소로 생각하지 않는다. 소프트웨어 개발 과정도 초기 컨셉이 결정되면 요구사항 파악부터 분석/설계과정을 거처 구현/테스트를 통해 소프트웨어를 릴리즈하고 유지보수 단계로 접어든다.
요구사항에서부터 최종 릴리즈까지 진행하면서 소프트웨어는 수많은 변경을 겪는다. 수시로 바뀌는 요구사항 때문에 설계를 변경해야 하고 소스코드를 뜯어 고쳐야 한다. 또한 요구사항을 잘못 이해하는 바람에 변경이 발생하고, 소프트웨어의 결함 때문에 변경을 해야 한다.
하나의 변경은 그에 수반된 여러 부분의 변경을 파생시킨다. 또한 하나의 변경으로 인해 다른 부분의 안정성도 보장받지 못할 수 있다. 따라서 변경에 대한 영향을 파악해야 하고 변경을 받아들이기 위해서는 얼마 만큼의 노력이 필요한지 알아야 한다.
그럼에도 불구하고 왜 변경에 대해 관리하지 않는 것일까? 소프트웨어 개발 시에 변경 관리가 용이하지 않은 가장 큰 이유는 '변경이 쉽다'라는 것이다. 적어도 자동차를 만드는 것보다는 쉬울 수 있다. 변경이 쉽기 때문에 너무 빈번하게 일어나고 자연스럽게 생각한다. 사소한 변경이든 중대한 변경이든 변경은 통제 대상에 놓여야 한다. 특히 형상 관리 대상으로 결정된 산출물은 엄격히 관리되어야 한다.
바꾸려는 사람과 안 바꾸려는 사람
프로젝트 현장에서 변경에 대한 시각은 이해관계에 따라 서로 다르다. 개발한 소프트웨어를 사용해야 하는 사람들은 개발 완료 시점이 다 되어 갈수록 아이디어가 샘솟기 때문에 자신의 아이디어를 어떻게든 반영하려고 노력한다. 반면 소프트웨어를 개발하는 사람들은 초기에 결정했던 고객의 요구사항을 어떻게든 바꾸지 않고 끝까지 끌고 가려고 노력한다.
변경의 정당성을 주장하는 고객의 논리는 지금 이 변경을 적용하지 않으면 결국 쓸모없는 소프트웨어가 된다는 것이다. 바꿔 말하면 변경하지 않을 경우 안 쓰겠다는 거의 반 협박성의 주장이다. 대가를 받고 소프트웨어를 개발하는 입장에서 들을 때는 검수해 주지 않겠다는 생존의 위협을 느끼게 하는 대목이다.
검수받지 못하면 잔금을 받을 수 없다. 반면 개발하는 사람들은 지금 변경하면 다른 부분에 영향이 많기 때문에 혹은 아키텍처가 흔들리기 때문에 시스템의 안정성을 보장할 수 없다고 한다. 여력만 있다면 바꿔주겠지만 현재 남은 기간으로는 도저히 반영할 수 없는 상황이라고 반론을 편다.
이때 변경 통제가 어느 정도 효과를 발휘할 수 있다. 변경 통제라는 것은 앞에서도 잠깐 언급했지만 소프트웨어 개발 기간 동안 발생하는 주요 변경사항을 평가 및 승인하여 변경사항이 소프트웨어의 각 부분에 어떤 영향을 주는지 알아내어 해당 이해관계자에게 어떤 영향을 주는지 알리는 것을 의미한다.
만약 고객의 변경이 불필요한 것이라면 관련 당사자를 의사결정에 참여시켜 조목조목 따져봄으로써 변경에 대한 영향을 가시화해 볼 수 있게 되므로 고객의 주장대로 정말 못 쓸 정도의 소프트웨어가 개발되는 것인지 반대로 개발팀의 주장대로 아키텍처가 흔들릴 정도로 엄청난 변경을 가하게 되어 안정성을 해치게 되는지, 남은 기간에 도저히 적용할 수 없는 수준의 변경인지 판단할 여력이 생긴다. 만약 소위 막가파 식으로 밀어붙이는 것만 아니라면 서로 얼굴 붉히지 않고 합리적인 수준에서 협의할 수 있는 근거가 만들어 질 수 있다.
형상 관리는 무엇인가?
지금까지 여러 가지 형상 관리와 관련된 사항들, 왜 형상 관리가 필요한지, 다른 분야에서는 형상 관리 같은 것을 하는지, 사람들의 관점은 어떤지 이야기했다. 이제 본격적으로 형상 관리에 대해 알아보자.
형상 관리는 1960년대에 등장하여 1970년대에 미 국방부의 밀리터리 스탠더드(Military Standard)의 일부로 만들어졌다. 이후 지속적으로 발전하다가 1990년대 들어 컴퓨팅 환경이 복잡해지고 품질기준이 엄격해지면서 본격적으로 적용되기 시작했다. 형상관리에 관하여 많은 정의가 존재하지만 가장 많이 보는 2가지를 살펴보자.
◆ 형상 항목을 식별하여 그 기능적 물리적 특성을 문서화하고, 그러한 특성에 대한 변경을 제어하고, 변경 처리 상태를 기록 및 보고하고, 명시된 요구사항에 부합하는지 확인하는 일련의 사항에 대해 기술적 행정적인 지침과 사후 관리를 적용하는 원칙 - IEEE Standard Glossary of Software Engineering Terminology(1991)
◆ 전체 소프트웨어 공학 과정에 적용되는 '보호(Umbrella)' 활동이다. 변경은 언제나 일어날 수 있기 때문에, SCM(Software Configuration Management) 활동은 (1)변경을 알아내기 위해서 (2)변경을 제어하기 위해서 (3)변경의 적절히 수행되고 있는 것을 확인하기 위해 (4)변경에 관심을 가지고 있는 사람들에게 이것을 통보하는 것이다. - Roger's S Pressman, "Software Engineering : A Practitioner's Approach , 3rd Edition"(1995)
이와 같은 정의에서와 같이 대부분의 정의에서 형상 관리라 함은 크게 4가지로 나눈다.
◆ 우선 형상관리의 대상이 무엇인지 식별하여 형상항목(configuration item)이라고 한다.
◆ 식별한 형상 항목의 버전(version control)과 변경을 통제(change control)라고 한다.
◆ 형상항목의 변경이 제대로 이뤄졌는지 살펴보는데, 형상 감사(configuration audit)라 한다.
◆ 변경된 형상 항목을 관계된 사람들에게 알리는데 이를 상태 보고(status reporting)라 한다.
형상 관리의 대상인 형상 항목을 생각해보면 형상 관리는 특성상 소프트웨어의 모든 부분에 영향을 주고 영향을 받는다. 단순히 바이너리 형태의 파일이나 소스코드에만 범위에 해당하는 것이 아니라 문서형식의 산출물, 각종 스크립트, 소프트웨어를 개발 이력 등이 해당한다. 또한 소프트웨어를 개발하는 사람들과 조직, 소프트웨어 개발 프로세스, 소프트웨어가 탑재된 하드웨어 및 네트워크 등도 해당된다.
형상 관리에서 말하는 형상(configuration)은 그 의미를 광의적으로 해석했을 때 사실 소프트웨어 그 자체이다. 소프트웨어는 PC에서 실행되는 작은 규모도 있고 네트워크와 연결되어 복수 개의 서버에서 운영되는 크고 복잡한 규모의 것도 있다. 따라서 엄밀히 따지면 소프트웨어를 구성하는 모든 것으로 볼 수 있으며 소프트웨어를 만드는 사람과 회사, 소프트웨어를 탑재하는 하드웨어 및 각종 컨피규레이션(configuration), 소프트웨어 그 자체, 소프트웨어 개발 프로세스, 형상 관리를 하기 위한 형상 관리 도구와 개발 도구 등이 해당한다.
형상 항목의 상태 변경에 따른 형상 관리
사실 형상 관리의 가장 큰 목적은 변경에 의해 점차적으로 변해가는 소프트웨어의 형상을 관리함에 있다. 형상 항목의 변경은 특정 상태를 거쳐 이뤄지는데 그 흐름을 그림으로 표시하면 <그림 1>과 같다.
형상 항목의 라이프 사이클은 크게 6단계의 상태로 볼 수 있는데 개발 초기에 개발 중이라는 상태에 위치하게 된다. 일단 개발이 어느 정도 완료되면 단위 테스트(unit test)를 준비하고 테스트를 통과하면 시스템 테스트 준비상태로 변하게 된다.
시스템 테스트(system test)도 아무런 이상 없이 통과하면 수락 테스트(acceptance test) 준비상태로 되고 이후 모든 결함(defect)을 제거하면 베이스라인(baseline)을 확정하고 제품을 릴리즈하게 된다. 이때 각 테스트 상태에서 결함이 발견되면 그 전 상태로 돌아가고 발견한 모든 결함을 제거할 때까지 과정을 반복하게 된다.
 |
| <그림 1> 형상 관리의 라이프 사이클 (Pankaj Jalote, CMM in Practice, 2000) |
앞에서 언급한 형상 관리의 정의에 따라 <그림 1>의 형상 관리 품목의 라이프 사이클을 살펴보면 우선 식별한 형상 항목을 최초로 작성하고 각 테스트를 거치면서 형상 항목을 변경하거나 수정한다. 단위 테스트의 경우 단위 프로그램의 결함 여부를 찾아내는 것이므로 주로 수정의 경우에 해당된다고 할 수 있다.
이 때 개발자가 작성한 프로그램의 경우 결함에 의해 수정되어 버전 통제를 받게 된다. 만약 단위 테스트 결과로 형상 항목의 구성에 포함되어 있다면 프로그램과 해당 단위 테스트의 결과는 서로 관계를 맺고 변경 요청에 의한 변경 통제 프로세스를 따라 진행될 것이다.
단위 테스트를 통과한 단위 프로그램들은 의미 있는 집합으로 묶여 시스템 테스트의 대상이 된다. 이때도 역시 결함이 발견되면 변경 통제 프로세스에 따라 진행한다. 수락 테스트는 주로 소프트웨어의 요구사항과 직접적으로 연관되어 있으므로 변경 통제 절차가 강화되고 요구사항과 변경과의 추적(trace)을 관리해야 한다. 베이스라인 확정 상태는 수락 테스트까지 마친 상태에서 프로젝트 진행 상태의 기준이 되는 아주 중요한 지표가 된다. 한번 확정한 베이스라인은 뒤로 바꿀 수 없다.
프로세스 관점에서 형상 관리 활동
지금까지 형상 항목의 상태에 따른 라이프 사이클을 중심으로 봤다면 이제 프로세스 관점에서 형상 관리 활동을 중심으로 살펴보자. ‘오류! 참조 원본을 찾을 수 없습니다’는 형상 관리 활동을 전반적으로 나타낸 것으로 Anne Mette Jonassen Hass의 『Configuration management principles and practice(2002)』에서 나오는 원래의 그림은 원문자와 곡선 화살표가 없는데 이는 더 용이한 설명을 위해 필자가 첨부한 것이다.
 |
| <그림 2> 형상 관리 활동의 개요(Anne Mette Jonassen Hass, Configuration management principles and practice, 2002) |
<그림 2>에서 굵은 선으로 둘러싸인 부분이 형상 관리의 범위이다. 여기에는 형상식별(Identification)과 통제 상에 놓여 있는 저장소(controlled storage), 변경 관리(change control), 상태 보고(status reporting)가 형상 관리의 활동이다. 여기서 형상 감사(audit) 부분은 각종 테스트와 검사에 관계된 활동으로 순수 형상 관리의 활동으로 보기 보다는 품질보증(quality assurance)의 일환으로 보는 관점이 있어 형상 관리의 정의에는 포함되나 그림 상으로는 굵은 선 박스의 외부에 위치시켰다.
그림 상으로 드럼통 모양은 데이터베이스 표식으로 저장소 데이터베이스, 변경 관리 데이터베이스, 메타 데이터베이스가 있다. 이들은 형상 관리를 위한 프로젝트 데이터베이스로 형상 항목의 그 자체를 저장하고(controlled storage), 변경에 관한 이력과 각종 정보를 저장하며(change control), 형상 항목에 대한 이름, 작성자, 생성 날짜와 다른 형상 항목과의 관계를 저장(metadatabase)한다.
그림에서 각 번호는 형상관리 활동을 나타낸 것이다. ①은 형상 관리 계획(configuration management plan)에 따른 형상 식별 활동이다. 우선 프로젝트에서는 프로젝트 계획의 일환으로 작성한 형상 관리 계획을 근거로 형상항목을 식별하여 메타 데이터 베이스에 입력한다. 이때 형상 항목을 유일하게 식별할 수 있도록 형상 항목의 이름, 작성자(author), 생성일, 문서인 경우 문서번호, 다른 형상 항목과의 관계 등을 저장하고 이때부터는 변경 관리의 대상이 된다.
②는 아직 형상 관리 범위 안으로 들어오지 못한 형상 항목의 생성 과정을 나타낸다. 프로덕션(production)은 현재 변경 중인 상태의 항목을 의미한다. 이때까지는 변경 통제의 대상에 포함되지 않는다. ③은 감사를 거쳐 변경할 수 없는 상태의 형상 항목을 구분된 장소에 두는 활동을 의미한다. 이때 보통 테스트를 거치는데 변경 중인 형상 항목과 더 이상의 변경이 없는 항목의 구분을 위해 존재한다. 이 분에서도 역시 변경 통제의 대상에 두지 않는다.
④에서는 ③을 거쳐 나온 항목을 비로소 변경 통제의 대상에 등록하는 활동이다. 이때 누가 왜 무엇을 언제 바꾸었는지 변경관리 데이터베이스에 기록된다. ⑤는 변경 통제 하에 있는 항목의 상태를 리포팅(status reporting)하는 활동이다.
지금까지 형상 관리의 정의와 형상 관리의 대상이 되는 항목의 상태 변화와 형상 관리 활동을 중심으로 살펴보았다. 주로 형상 관리 자체만을 갖고 설명했으므로 피상적이고 따분하겠지만 우선 이런 것이구나 하는 수준으로 접근했으면 한다.
CMM과 형상 관리
여기서 CMM은 정확히 말하자면 SW-CMM으로 소프트웨어 개발 역량을 평가하기 위한 성숙도 모델이다. 여기에는 실제 실행 지침과 소프트웨어 프로세스 개선, 소프트웨어 프로세스 평가를 수행하는 개별 작업자의 요구를 반영한다. 또한 문서화되고 공개적으로 사용 가능하다. CMM의 태동을 주도한 미 국방부의 연구에 따르면 소프트웨어 개발 프로젝트의 성공과 실패를 결정짓는 주요 원인은 기술이라기보다는 관리의 문제라는 결론을 내렸다.
따라서 소프트웨어 개발 조직의 성숙도에 따라 소프트웨어의 품질은 많은 차이를 보인다. 그 이유로는 미성숙한 개발 조직의 경우 소프트웨어의 품질의 좋고 나쁨을 판단하는 객관적인 기준이 없고, 소프트웨어 프로세스가 품질에 어떻게 영향을 미치는지에 대한 이해가 없으며, 정형화된 테스트나 검토와 같은 품질 보증 활동은 이런 저런 이유로 축소되거나 생략된다. 개발팀은 사소한 문제로도 우왕좌왕하고 개인의 역량에 의지하여 해결하려고 한다. 따라서 고객은 최종 인도 이전에는 그들이 사용할 소프트웨어가 어떻게 작동하는지 알 수 없게 된다.
하지만 개발 역량이 성숙한 조직은 프로세스를 적극 활용하여 개발팀이 그들이 맡은 임무에 따라 일사 분란하게 움직이도록 훈련이 되어 있다. CMM은 개발 역량이 성숙한지 아닌지를 평가하기 위해 5단계의 레벨을 두고 있다. 각 레벨의 특징은 <표 1>과 같다.
 |
| <표 1> 소프트웨어 프로세스 성숙도의 5레벨 |
이 5레벨에서 우리가 지금 이야기하고 있는 소프트웨어 형상 관리는 어느 레벨의 인증을 위한 핵심 프로세스에 해당할까? 높은 레벨일 듯 싶지만 겨우 레벨 2이다. 이 정도면 이제 겨우 조직적으로 개발 좀 한다는 소리를 듣는 단계의 시작이다.
CMM에서는 레벨 2에서 소프트웨어 요구사항관리와 함께 형상 관리가 핵심 프로세스 영역(KPA : Key Process Area)으로 되어 있다. 성숙도 레벨에 따른 핵심 프로세스 영역은 <그림 3>과 같다.
 |
| <그림 3> 성숙도 레벨에 따른 핵심 프로세스 영역 |
반복 레벨의 인증을 받기 위해서라도 이것저것 관리해야 할 것이 태산이다. 그 중 CMM이 인정할만한 소프트웨어 형상관리는 어떤 수준인지 살펴보자.
CMM의 형상 관리 가이드
CMU/SEI에서 작성한 『The Capability Maturity Model: Guide for Improving the Software Process, 1st Edition(1994)』을 토대로 CMM이 레벨 2 수준의 형상 관리를 위해서는 목표에 따른 어떠한 수행능력(Ability to Perform)이 있어야 하는지 살펴보자.
[1] 프로젝트 소프트웨어 기준선을 관리할 수 있는 권한을 가진 위원회(즉, 형상통제위원회, SCCB : Software Configuration Control Board)가 존재하거나 없다면 설립한다.
A. 소프트웨어 기준선 결정과 형상 항목 식별 권한을 갖는 의사결정권을 갖는 조직이 결성돼야 한다. 실제 프로젝트 현장에서는 형상 항목의 결정과 변경 통제의 권한을 어떻게 가져가느냐에 많은 신경을 쓰고 있다. 하지만 중요한 것은 의사 결정권을 갖는 역할로 구성돼야 한다는 것이다. 대표적으로 프로젝트 관리자와 고객의 대표로 구성된다.
B. 또한 이 조직은 베이스라인의 승인을 결정하는 중요한 조직으로 형상 관리를 위해서는 반드시 존재해야 한다.
B. 또한 이 조직은 베이스라인의 승인을 결정하는 중요한 조직으로 형상 관리를 위해서는 반드시 존재해야 한다.
[2] 프로젝트를 위한 SCM의 조정과 구현에 책임을 가진 그룹(즉, SCM 그룹)이 존재한다.
A. 이 그룹은 형상 관리를 위한 모든 활동에 대하여 책임을 갖는다. 이들이 맡고 있는 부분은 앞에서도 언급한 형상 관리의 정의에 해당하는 모든 활동을 책임진다.
i. 프로젝트 소프트웨어 베이스라인 라이브러리 생성과 관리
ii. SCM 계획, 표준, 절차의 개발, 유지 및 분배
iii. SCM 하에 놓인 일련의 작업 산출물 식별
iv. 소프트웨어 베이스라인 라이브러리에 대한 접근 관리
v. 소프트웨어 기준선 갱신
vi. 소프트웨어 기준선 라이브러리로부터 산출물 생성
vii. SCM 작업 기록
viii. SCM 보고서 작성 및 분배
i. 프로젝트 소프트웨어 베이스라인 라이브러리 생성과 관리
ii. SCM 계획, 표준, 절차의 개발, 유지 및 분배
iii. SCM 하에 놓인 일련의 작업 산출물 식별
iv. 소프트웨어 베이스라인 라이브러리에 대한 접근 관리
v. 소프트웨어 기준선 갱신
vi. 소프트웨어 기준선 라이브러리로부터 산출물 생성
vii. SCM 작업 기록
viii. SCM 보고서 작성 및 분배
[3] SCM 활동 수행을 위해 적절한 자원과 자금이 지원된다.
A. 여기서 적절한 자원은 형상 관리자의 고유 권한과 책임이 부여돼야 하며
B. 자동화된 형상 관리 도구가 지원돼야 한다.
B. 자동화된 형상 관리 도구가 지원돼야 한다.
[4] SCM 그룹의 구성원들은 SCM 활동을 수행하기 위한 목표, 절차, 방법 등에 대해 교육을 받는다.
A. 교육의 범위는 SCM의 표준, 절차, 방법 등이며 형상관리 도구의 사용법과 관리 방법도 숙지해야 한다.
[5] 소프트웨어 엔지니어링 그룹과 다른 소프트웨어 관련 그룹의 구성원들은 SCM 활동을 수행하는 데 필요한 교육을 받는다.
A. 소프트웨어 형상 관리는 비단 SCM 그룹에 국한되는 것이 아니라 프로젝트의 모든 구성원이 어떤 형태로든 참여하게 된다. 따라서 SCM 활동을 위해 준수해야 하는 표준과 절차, 방법을 알아야 하고 형상 관리 도구의 사용법을 숙지해야 한다.
이와 같이 총 5가지의 수행능력을 바탕으로 형상 관리 활동을 실시해야 한다. 어떻게 보면 그야말로 딱딱한 법전 같은 가이드지만 결국 요약하면 프로세스 상에서 권한과 책임을 줘 결정하고 승인할 역할을 만든다. 또한 결정에 따라 형상 관리를 수행할 조직을 만들고, 수행할 사람들에게 교육을 제공해야 한다는 것이다.
너무나 상식적이고 당연한 형상관리
『소프트웨어 공학의 사실과 오해』를 저술한 로버트 L. 글래스는 개발자의 능력에 따라 생산성이 28배까지 차이 난다는 사실을 이야기한바 있다. 어마어마한 수치임에 틀림없다. 실제로 누구나 아는 사실이겠지만 어려운 난관에 부딪히면 초보개발자 100명이 달라붙어도 해결하지 못할 문제를 고급 개발자는 점심시간에 자장면 먹어가며 한 손으로 타이핑 몇 번 만에 해결할 수 있다. 이것은 사실을 넘어서 부인할 수 없는 진실이다.
하지만 조직적으로 소프트웨어를 개발할 때는 어려운 문제만 있는 것이 아니라 해결 가능한 평이한 문제들이 절대 다수를 차지하고 이것들은 서로 관계를 갖고 복잡도를 증가시킨다. 또 끊임없이 변한다.
이렇게 복잡하면서 지속적으로 변하는 소프트웨어라는 괴물을 어떻게 다루는가가 형상 관리의 주된 목적이다. 형상 관리는 반드시 되어야 한다. 그 과정도 너무나 상식적이고 당연하다.@
출처 : 이 기사는 ZDNet Korea의 제휴매체인 마이크로소프트웨어에 게재된 내용입니다.
'QC > 품질관리' 카테고리의 다른 글
| 테스트설계의 관점과 테스트기법 (0) | 2005.12.13 |
|---|---|
| 소프트웨어 형상 관리 (0) | 2005.12.13 |
| 원전 소프트웨어 확인 및 검증 (0) | 2005.12.13 |
| MBASE(Model-Based Architecting and Software Engineering) (0) | 2005.11.18 |
| 제9차 SW 테스트 전문가 양성 교육 [응용] 자료 (0) | 2005.11.18 |
| 제9차 SW 테스트 전문가 양성 교육 [기초] 자료 (0) | 2005.11.18 |
| 테스트 용어 해설 (0) | 2005.11.18 |
| 테스트 계획과 문서화 (0) | 2005.11.18 |
| 개발 단계에 따른 각 팀별 업무 (0) | 2005.11.18 |
| 소프트웨어 개발 시 타협점 (0) | 2005.11.18 |
Recent comment