Configuration Management

형상관리 또는 구성관리라고 칭하는 Configuration Management에 대한 설명입니다.

구성관리를 보험에 비유를 하곤 합니다. 문제가 없는 평시에는 Effort만 들어가는 것으로 생각되기 쉬운데, 장애발생시는 심각한문제를 야기하고, 결함 이전상태로 돌이킬 수 없어서 복구에 어려움을 겪는 경우를 종종 볼 것 입니다.

구성관리(Configuration Management)란 시스템 또는 프로그램을 구성하는항목들을 식별하고, 통제하고, 구성 상태를 보고하고, 구성 감사를 통하여 작업산출물의 무결성을 확보 및 유지하는 활동을 의미합니다.

1. 구성항목 식별

2. 구성항목 통제

3. 구성상태 보고

4. 구성감사

   위 4가지 요소만 기억하면 구성관리를 모두 이해한다고 보면 되며, 하나씩 설명하겠습니다.

1. 구성항목 식별이란?

• 우리들이 현재 하고 있는 소프트웨어 형상관리의 개념은 하드웨어 형상관리에서 시작되었다고 합니다. 그래서 새로운 자동차가 나오기까지의 예를 들어서 설명해 보겠습니다.

  

  
  그랜저 TG와 그냥 그랜저 인가요???
  
  자동차 한 대는 최소 구성단위로 완전히 분해할 때 2만개의 부품으로 구성되고 거기에 부품 번호를 부여한다고 합니다.
  하나의 단가를 구성해 관리하는 엔드 아이템(end item) 단위로 보면 수천여 개의 부품이 들어가는 것이죠.
  자동차 회사에서는 이렇게 많은 부품을 관리하기 위해 각 부품을 부분별로 구분하고 각 부품간의 관계를 정의합니다.
  이를 보통 BOM(Bill of Material)이라고 합니다.
  

  

  
  이렇게 많은 것들이 들어간다네요...
  
  자동차를 새로 개발할 때 자동차의 초기 컨셉이 정해지고 나면 그것에 디자인과 각 부분별 설계가 진행되고 모델 고정 시점이 되면 프로토타입 차, 시작 차와 같이 실제로 자동차를 만들어 테스트를 실시합니다.
  자동차 각 부분에 대한 부품설계 및 디자인을 진행하는 와중에도 지속적인 설계 변경이 일어나게 됩니다.
  자동차 회사 역시 설계 변경을 관리하기 위해 엄격한 변경 관리를 적용하고 있습니다.
  하나의 변경이 발생하기 위해서는 ECO(Engineering Change Order)라는 것을 발행하고,
  변경에 따른 영향도 분석은 관련 부서의 협력을 통해 얻어내어 최종 결정을 한다고 합니다.
  자동차 회사에서는 이와 같은 변경 프로세스를 아주 철저히 지키며
  그 누구도 귀찮다거나 쓸데없는 일 때문에 개발 기간이 늘어난다고 생각하지 않는다고 하더군요.
  상식적으로 생각해도 사람의 생명과 직결된 일이고 부서간의 협력을 통하지 않고 제대로 된 영향 분석을 하지 않는다면 자동차가 출고된 후에 문제가 발생할 것이 분명하기 때문이죠.
  
  이처럼 처음에 있던 설계에 대해 변경을 관리하는 것을 자동차 회사에선 "구성관리를 한다"라고 말을 할 수 있습니다.
  
  자동차 산업과 우리가 하고 있는 소프트웨어 산업은 무엇을 만든다는데 대해서는 공통점이 있는 것 같습니다.
  그리고 현재 운영되고 있는 소프트웨어에 대해 CSR, 분석/설계 요청으로 변경되는 것과 중간에 일어나는 절차도 비슷하다고 생각됩니다.
  
  하지만 자동차와는 달리 소프트웨어의 변경은 "눈에 보이지 않고", "변하기 쉬운" 특성 때문에 더 구성관리가 어려운 것 같습니다.
  간단히 말하면 구성관리는 소프트웨어와 그 구성물들에 대해서 변경을 관리하는 것 이라고 할 수 있습니다.

• 모든 소스와 산출물을 전부 엄격하게 시스템 또는 툴로 관리하라는 의미는 절대 아닙니다. 최종적인 버전의 식별과 이전버젼으로 복귀할 수 있는 방안, 변경이력등특성별 관리수준이 다를 수 있습니다.

• 또한 소스만 중요한 구성항목이라고 인식하는 분들이 많은데,개발을 위한 Work Product 즉, 설계서, 분석 문서, 테스트케이스들도 중요한 구성항목입니다

• 따라서 조직별로 충분한 협의 후에 관리할 구성항목을 정의한 후 구성관리를 하도록 해야 합니다. 파워콤에는 구성관리 계획서 별첨으로 구성항목 목록 문서가 관리되고 있습니다.

2. 구성항목 통제

• 고객과 합의된 상태로 베이스라인 화 된 산출물은 무결성을 보장하기 위해서는 엄격한 통제에의해서 산출물 접근이 이루어져야 하며, 개발자가 임의로 산출물을 변경,삭제, 등록을 해서는 안됩니다. 통제라는 의미가수정을 하지 말라는 의미가 아니라, 충분한 검토와 협의등의 변경관리위원회(CCB)를 통해서만 변경될 구성항목을 식별하고, 변경요청을 승인할것인지를 전문가들이 모여서 결정을 지으라는 의미입니다.

• 파워콤에서는 CCB 수행기준이 3가지로써 CCB1은 한달이상의 대규모 변경이 요구될 때 소집되는것으로 IT 기획팀의 주관하에 CCB가 이루어진다. CCB2는 IT운영팀 주관하에 타시스템에 영향을 주는 변경영향분석회의이며, CCB3는 LG CNS 자체적으로 실시하는 CCB로써 분할, 이관, 통합테스트수행여부, 접수여부등을 판단하기 위해 실시한다.

• 구성항목통제를 위하여 구성관리 책임자, 구성관리담당자, 라이브러리 담당자등을 지정하여 구성항목에 대한 적절한 통제를 수행하도록 한다.

• 그리고, 통제를 제대로 하기 위해서는 구성 및변경 관리 도구 및 시스템을 구축해야 합니다. 물론 파일 서버만으로도 구성관리 통제가 가능은 하나 효율적인관리가 어려울 것입니다. 현재 파워콤 OS팀은 전사 표준구성관리툴인 실루엣을 G-AMS, 개발툴과 연동해서 효과적으로 구성관리를 수행하고 있으며, CS팀의 경우도 곧 적용할 예정입니다.

3. 구성 상태 보고

• 산출물에 대한 베이스라인 설정을 한 후 특정기간 동안에 신규로 등록되고, 변경, 삭제된 산출물 현황을 파악하는 것이 중요합니다.

• 여기서 변경관리의 기초가 되는 베이스라인이라는 의미를 이해하기 위해 위성사진으로 예를 들어보겠습니다. 1950년대 서울 상공에서 항공기로 특정 지역의 사진을 찍어놓았습니다. 이것이 1950년의 서울 모습을 베이스라인화 했다고 볼수 있습니다. 베이스라인 설정된 그 자체는 사진으로 찍혀 변경되지 않습니다. 이후 2007년 똑 같은 지역의 상공에서 사진을 찍어 비교 해보면 변경된 지역도 있겠지만, 변화없이 그대로 인 집들도 있을 겁니다. 말그대로 기준선을 베이스라인이라고보면 쉽게 이해할 수 있으며, 기준선 대비 무엇이, 얼마나변경되었는지를 알 수 있어야 합니다. 보통 SM에서는 베이스라인변경율 지표 관리를 통해 시스템별로 베이스라인 변경이 얼마나 자주 일어나는지, 왜 변경율이 높은지를원인분석하며 시스템의 무결성 상태를 확인합니다.

• 파워콤의 경우 매주, 데이터 수집 및 측정 보고서를통해 베이스라인 현황 및 구성항목의 변경상태를 취합 보고 하고 있습니다.

4. 구성 감사

• QA 가 품질 감사를 하듯이 구성관리가 제대로 이루어지는지, 베이스라인무결성이 보장되는지 감사라는 형태로 부적합사항을 식별하고 해당담당자에게 시정조치활동을 지시하고 시정조치 여부를 확인합니다.

• 구성감사를 통해체크리스트에 따라 변경요청된 구성항목이 제대로 구성관리 라이브러리에 등록이되고, 운영환경과 일치하는지 확인이 이루어집니다.

• 파워콤의 경우 매월 1회씩 팀별로 별도의 구성감사자에의해 구성감사가 실시된 후 팀장에게 보고되고 시정조치를 지시하고 있습니다.