12. 형상관리 계획

 

형상관리 계획(SCMP)은 네 가지 주요 objective를 가지고 있다. 베이스라인과 추적성, 변경관리, 각 개별 데이터 아이템의 구분 그리고 버전을 컨트롤하고 제품을 그대로 다시 만들어 낼 수 있는 능력이 그것들이다. 형상관리 계획서내에 이들 목표를 어떻게 달성할지에 대한 프로세스를 서로 다른 섹션에 상세하게 작성한다.

역주) 여기에 설명하고 있는 내용은 DO-178 가이드라인에 제시된 아래의 objective를 말하는 것이다. 실제 가이드라인 문서의 부록에는 아래와 같은 테이블이 존재한다. (참고 포스팅: 21. SCMP(Software Configuration Management Plan))

 

다른 DO-178B와 DO-254 계획문서들(인증계획, 품질보증 계획, 소프트웨어 개발 계획 그리고 소프트웨어 검증 계획)에 대해서는 이들 계획문서에 정의된 라이프사이클 활동들을 수행하기 위해 할당된 특정한 사람들이 있다. 그러나 형상관리 계획은 책임이라는 관점에서는 더 일반적이다. 말 그대로 소프트웨어와 하드웨어 엔지니어링팀의 모든 멤버가 형상관리에 직접적인 책임이 있다. 당신은 형상관리를 한 사람 혹은 한 팀에 전적으로 전담하도록 할 수 있는가? 물론 가능하다. 그런데 당신은 그럴 필요가 있는가? 혹은 대부분의 회사들이 그런 식으로 형상관리를 운영하는가? 그렇지 않다. 형상관리는 모두의 책임이고 그렇게 문서를 준비하고 리뷰를 수행하고 계획을 따른다. 모든 사람이 형상관리의 책임이 있다.

역주) DO-178에서 형상관리를 바라보는 철학을 보여주는 부분이다. 사실 현장에서 보면 형상관리에 대해서 확고한 개념을 가지고 운영되는 경우는 그렇게 많지 않다. 특히 소규모의 업체라면 그나마 형상관리를 한다고 하더라도 특정 1인이 과제를 진행하면서 각종 문서, 소스들을 서버에 저장하는 그런 정도를 하는게 보통이다. 그것도 형상관리의 일부분임에는 틀림없다. 하지만 DO-178을 진행하려면 이런 방식은 완전히 뜯어고쳐야 한다. 제대로 된 형상관리를 해야 한다는 말이다. 그러기 위해서 팀원 전체도 형상관리에 대한 마인드가 바뀌어야 한다. 팀원 각자가 DO-178에서 요구하는 형상관리에 대해서 제대로 알아야 하고 형상관리에 있어서 책임지고 각자의 역할을 할 수 있어야 한다. 그동안 해보지 않았고 하지 않던 일이어서 시작하는 것 부터가 어렵지만 막상 시작하고 나면 상대적으로 가장 쉬운 부분이기도 하다.

 

형상관리 계획 개요   형상관리 objective:   베이스라인 & 추적성 변경 관리, 문제점 레포트 & 리뷰 형상 구분 버전 컨트롤 & 복제

 

어떤 회사들은 두 개의 형상관리 시스템을 가지고 있다. 하나는 소프트웨어 소스 파일을 위한 것이고 다른 하나는 문서를 위한 것이다. 만약 그 두 개를 합칠 수 있다면 일반적으로 단지 하나의 형상관리툴을 의미하는 하나의 시스템만을 가진다는 점에서 더 쉬워진다. 하지만 양쪽 모두를 수행하는 특정 형상관리툴이 있긴 하다. 그것은 소프트웨어 관리뿐만 아니라 그것과 관계된 문서와 데이터 아이템 또한 관리할 필요가 있다는 것이다.

역주) 형상관리를 하나의 시스템으로 하든 두 개의 시스템으로 하든 DO-178이 요구하는 기준을 맞출 수 있다면 문제될 것이 없다. 하지만 굳이 두 개를 운영할 필요가 있을까? 오히려 관리의 부담과 활용의 혼선이 더해지는 것이 아닐까?

 

리뷰를 위한 소프트웨어 베이스라인의 정의. 데이터 아이템은 리뷰 바로 직전에 반드시 형상관리되어야 한다. 모든 리뷰는 리뷰될 버전을 지정해야 하고 대부분의 형상관리툴은 버전 번호를 자동으로 추적하고 관리한다. 산출물은 형상관리에 체크인된 이후에만 리뷰될 수 있다. 산출물이 리뷰 바로 직전이 아니라 더 일찍 형상관리에 저장될 수 있을까? 당연하다. 기억하자. DO-178B는 융통성이 있다. 사실 하나의 아이템이 매우 일찍 형상관리로 체크인되는 것이 바람직하며 일반적으로는 생성자가 작업을 시작한 바로 첫날의 마지막 시점이다. 왜 그럴까? 데이터 손실을 방지하는 것이다. 하드드라이버나 파일을 잃어본 적이 있는가? 누구나 있을 것이다. 형상관리는 중앙집중의 저장소를 제공하고 파일, 데이터 그리고 산출물의 잠재적인 손실을 최소화한다.

 

소프트웨어 모듈 A를 개발하면서 형상관리에 올리지도 않은 채 복도에서 동료에게 “내가 방금 모듈 A를 다 만들었는데 어서 리뷰하고 검증결과를 나에게 주세요.”라고 말하는 것은 허용되지 않는다. 그가 리뷰도 하고 심지어는 체크리스트를 채울 수도 있지만 형상관리에 있을 때까지는 어떤 버전으로 해야 하는지를 알지 못한다. 만약 그가 그것이 버전 1이라는 것을 안다면 그는 그것을 수정한 후에 다음 버전, 예를 들면 버전 2를 생성하게 된다. 이제 모든 사람이 추적할 수 있고 리뷰하기 전에 베이스라인을 가질 수 있다. 리뷰될 산출물과 관련된 버전 번호가 없이는 그 리뷰는 비공식적인 것이고 DO-178B의 리뷰 기준을 만족하지 않는다.

역주) 실제 자신의 회사에서, 팀에서 이렇게 진행하고 있는지 생각해보자. 역자가 경험한 대부분의 회사는 이렇게 진행하는 경우가 없었다. 있어도 지속적인 것이 아니었고 특정 프로젝트의 특정 상황에서만 그렇게 해서 실적을 남기는 정도였다. 그런 상태로는 DO-178 인증을 받을 수 없다. 만약 그런 상황이라면 형상관리 시스템 구축과 프로세스 정의에 대한 부분부터 먼저 진행되어야 한다. 현실적으로는 DO-178 인증을 진행하면서 곧바로 적용해 보는 것이 가장 빠르고 확실한 방법이 될 것이다. 다만 팀원들의 준비가 아직 안되어 있을 가능성이 높기 때문에 많은 시행착오를 각오(?)해야 할 것이다.

 

형상관리 계획: 세부사항   소프트웨어와 하드웨어 형상을 관리하는 것에 대한 프로세스를 상세화 리뷰와 릴리즈에 대한 베이스라인을 정의 바이너리가 지속적이고 반복적으로 생성될 수 있다는 것에 대한 보장 문제점 리포트, 추적, 승인, 병합, 리뷰 그리고 보장되지 않는 변경의 금지 모든 전자 데이터(그리고 전자장비와 관련없다면 물리적 데이터)에 대한 안전, 백업, 복구를 제공 다음을 포함한 산출물이 관리된다는 것을 보장 어플리케이션 소프트웨어와 문서 계획문서와 표준문서 리뷰와 감사 결과 써드파티툴 소프트웨어 개발 및 시험 환경 기타 산출물들

 

바이너리가 재생산될 수 있고 문제점 리포트가 추적될 수 있다는 것을 확실하게 해야 한다. 또한 시스템을 백업하고 안전을 관리하는 방법을 가지고 있어야 한다. 1991년에 거대한 지진이 로스앤젤레스 지역을 강타해서 보잉 777의 일부 협력사들의 공장 일부와 데이터가 유실되었다. 다행히 그 협력업체들은 매일 그리고 매주 백업을 했을 뿐만 아니라 업체 외부에도 백업을 하고 있었다. 그래서 그 잃어버린 데이터를 빠르게 복구할 수 있었다. 따라서 회사 운영 절차에서 중요한 단계는 주기적인 백업과 데이터 아이템을 다시 복구할 수 있는 능력이다. 문서, 소프트웨어, 시험케이스, 계획문서, 표준문서 그리고 리뷰에 대한 산출물들을 백업하라.

역주) 형상관리가 잘 이루어지지 않는 업체라고 해도 보통 백업은 나름대로 진행하는 곳이 많다. 이는 회사 전체로 봐서도 중요하지만 개인에게도 마찬가지로 중요한 부분이다. 그런데 이런 백업이 버전에 대한 관리와 함께 이루어지지 않고 있다면 사실 그것은 제대로 수행하는 것이 아니다. 저자가 말한 보잉 777의 사례만 보더라도 만약 버전관리가 없이 백업만 이루어진 상태라면 막상 항공기에 탑재할 소프트웨어 혹은 하드웨어를 다시 만들어야 되는데 도대체 어떤 소스, 어떤 장비로 해야 되는지 정확하게 알 수 있을까? 버전관리가 되어 있다면 최종적으로 항공기에 탑재된 버전을 확인해서 그 버전의 백업본을 가지고 작업을 하면 되지만 그렇지 않다면 백업된 것 중에서 가장 나중에 백업한 것을 사용해본다거나 하는 식의 운에 맡길 수 밖에 없어진다.

 

형상관리 계획: 범위   어떤 산출물들이 형상관리를 통해서 컨트롤되어야 하는가?   DO-178B & DO-254를 지켜서 따르거나 보여주는데 사용되는 모든 산출물: 모든 계획, 표준, 문서, 요구사항, 설계, 코드, 시험절차 및 결과, 리뷰, 빌드파일, 체크리스트, 감사, 리뷰 등

 

써드파티툴. 당신이 사용하는 어떤 툴이든 버전 번호를 유지하라. 그렇게 함으로써 필요한 경우 항상 또 다른 복사본을 얻을 수 있고 개발과 시험을 준비하고 실행하는 환경을 알 수 있게 된다. 형상관리는 또한 산출물의 관리를 요구한다. 우리는 비싸지 않은 보장과 DO-178B/DO-254 준수와 같은 것을 요구하는 당신의 계획을 따라왔다는 증거로써 감사결과와 체크리스트가 형상관리 시스템내에 보관되어야 한다고 믿는다.

역주) DO-178에서는 도구를 아주 중요하게 생각한다. 일반적으로 사용하는 상용툴이라고 하더라도 형상관리를 요구한다. 혹시라도 자체 개발한 툴을 사용한다면 두말 할 필요도 없다. 기본적인 개념은 개발환경이 (사고 등으로) 완전히 리셋되더라도 과거에 사용했던 동일한 툴을 동일한 셋팅으로 사용할 수 있어야 한다.

 

형상관리 컨트롤 분류: 세부내용   DO-178B는 두 가지 타입의 형상관리 컨트롤 카테고리를 요구함    CC1은 엄격함: 모든 형상관리 컨트롤이 적용 CC2는 느슨함: CC1의 서브셋

 

DO-178B는 형상관리에 대해서 두 가지 컨트롤 카테고리로 구분한다. 하지만 레벨과 데이터 아이템을 구분하려고 노력해서 그것이 레벨 CC1인지 CC2인지를 알아내는 것에 시간을 낭비하지는 말아라. 모든 것을 엄격한 형상 컨트롤하에 유지하는 것이 더 쉽다. 그렇게 함으로써 프로세스를 반복하지 않고 단지 모든 것을 CC1으로 수행함으로써 어떤 레벨로 적용할 지 결정하는 데 더 많은 시간을 소모하지 않게 된다.

역주) CC1, CC2와 같은 어려운 용어를 따지기 이전에 여기에서 중요한 점은 형상관리 항목을 하나하나 구분해서 엄격하게 할 필요가 없다는 것이다. 무엇이 더 엄격해야 하고 덜 엄격해도 되는지 구분하고 신경쓰다보면 오히려 그 부분에 더 부하가 걸릴 가능성이 높다. 그럴 바에는 차라리 전체를 엄격한 레벨로 통일해서 형상관리하는 것이 전체적으로 보면 오히려 부하를 감소시킬 수 있다는 말이다. 이어서 나오는 내용들을 좀 더 살펴보자..

 

기본적으로 두 가지 레벨의 컨트롤이 있다. 컨트롤 카테고리(Control Category) 1은 매우 타이트하고 컨트롤 카테고리(Control Category) 2는 좀 더 느슨하다. 그들 간에는 얼마간의 차이점이 있다. 어쨌든 당신이 수행하는 형상관리의 대부분은 상용 형상관리툴을 통해서 자동으로 수행된다.

 

어떤 아이템은 체크리스트일 것이다. 두 개의 컨트롤 카테고리 사이에 구분을 하려고 하면 모두 다 컨트롤 카테고리 1으로 유지하는 것보다 시간이 더 소요된다. 어떤 데이터 아이템이 CC2 대비 CC1이 되어야 하는지 구분하는 방법은 DO-178B에 있는 테이블을 보는 것이다. 예들 들면, PSAC은 CC1으로 유지할 필요가 있으며 다음의 태스크들은 CC1과 관계가 있다. 즉, 단지 흔적만 요구하는 CC2에 비해서 식별, 베이스라인, 추적성, 문제점 리포트, 릴리즈 방법 그리고 데이터 저장과 같은 태스크가 필요하다는 의미이다.

 

CC1과 CC2 데이터와 관련된 소프트웨어 형상관리 objective

소프트웨어 형상관리 프로세스 Objective	참조	CC1	CC2
형상 식별	7.2.1	●	●
베이스라인	7.2.2.a, b, c, d, e	●
추적성	7.2.2.f, g	●	●
문제점 리포트	7.2.3	●
변경 통제 – 통합 및 식별	7.2.4.a, b	●	●
변경 통제 – 추적성	7.2.4.c, d, e	●
변경 리뷰	7.2.5	●
형상 상태 정리(Configuration Status Accounting)	7.2.6	●
복구	7.2.7.a	●	●
허가받지 않은 변경 금지	7.2.5.b.1	●	●
미디어 선정, 갱신, 복제	7.2.7.b.2, 3, 4, c	●
릴리즈	7.2.7.d	●
데이터 저장	7.2.7.e	●	●

 

역주) 위의 표는 DO-178 가이드라인에 나와 있다. 결국은 이 테이블을 어떻게 해석하는지를 알아야 한다. 그러자면 가장 왼쪽의 objective라고 된 부분이 정확하게 어떤 것을 말하는지를 이해해야 한다. 아마도 몇 가지 항목을 제외하면 대부분 직관적으로 이해가 될 것이다. 그런데 오른쪽의 점으로 된 표시가 없는 부분이 있다. 해당사항이 없다는 뜻이다. 이걸 보면 CC2가 CC1보다 몇 가지 항목이 빠지는 만큼 관리가 용이하다는 것을 이해할 수 있다. 한 예로 ‘문제점 리포트’를 보면 CC1으로 지정된 데이터는 반드시 문제점 리포트가 있어야 한다. 예를 들면 이슈로 등록하지 않으면 그 데이터를 변경할 수 있다는 의미이다. CC2로 지정된 경우라면 굳이 이슈 등록을 하지 않고서도 변경할 수 있다는 것을 알 수 있다. 물론 CC1처럼 이슈로 등록하고 나서 변경해도 전혀 문제가 되지 않는다. 이런 것이 바로 앞서 저자가 이야기한 동일 카테고리로 통일해서 관리하는 게 더 편할 수 있다는 부분이다. (참고 포스팅: 13. DO-178과 소프트웨어 형상관리 프로세스 (Section 7.0))

 

PSAC은 CC1이 되어야 하지만 다른 것을 선정해 보자. 레벨 A와 B를 위한 소프트웨어 형상관리 계획서는 레벨 C에 대해서는 CC1이 되어야 하고 레벨 D에 대해서는 CC2가 되어야 한다. 엄격한 형상관리를 유지하는 것이 더 쉽다. 형상관리 계획서를 수정하기 위해서 당신은 하나의 문제점 리포트를 작성할 것이다. 레벨과 관계없이 당신은 수행한다. 사실, 사람들은 CC2를 무시하고 대부분의 산출물에 대해서 CC1을 적용한다. CC1은 CC2가 요구하는 모든 활동을 포함하며 몇 가지가 추가된다. 따라서 당신은 커버하게 되는 것이다.

 

컨설팅을 하는 동안 어떤 회사는 그것에 동의하지 않고 이렇게 말하는 것을 본 적이 있다. “우리는 레벨을 구분하기를 원하고 레벨 C와 D 작업에 대해서는 좀 더 쉽게 하고 싶습니다.” 그들은 이미 아무도 따르지 않는 이런 복잡한 정책을 만들었는데 그런 방식은 실수를 하는 것이다. 형상관리에 대해서 우리는 툴을 직접 만드는 것 보다는 엔지니어들이 쉽게 이해하고 따라할 수 있는 상용툴을 추천한다.

 

DO-178B의 의도를 만족하고 프로세스로 쉽게 채택될 수 있는 문제점 레포팅툴들이 있다. 당신이 만약 하나를 가지고 있다면, 변경사항 추적에 대해서 DO-178B의 의도를 만족하는지 확인하라. 보증되지 않는 변경이 없다는 것을 확실히 하기 위한 매뉴얼 단계가 있어야 한다. 그것은 산출물이 변경될 때마다 리뷰된다는 것이고 당신이 변경된 버전과 이전 버전(변경에 앞선)을 비교하고 그 산출물의 유일한 변경은 다른 “보장되지 않은” 변경이 없이 문제점 리포트에 의해서 보증된 것들만 해당한다는 것을 확인한다는 의미이다.

역주) DO-178에서는 이슈와 형상관리가 아주 밀접하게 연관되어 있다. 쉽게 말해서 어떤 문서가 변경되려면 반드시 이슈가 먼저 등록되고 그 이슈에 기반해서 담당자도 지정되고 그 담당자에 의해서 실제로 문서가 변경되는 것이다. 형상변경의 공식적인 시작이 이슈등록에서 출발한다고 볼 수 있다. DO-178 인증을 진행할 때 이것이 가장 기본적인 프로세스라고 생각하고 형상관리 및 이슈관리에 대해서 준비할 필요가 있다.   참고로 역자는 이슈관리도구로 ‘Redmine’을 형상관리도구로 ‘Subversion’을 주로 사용하며 두 개의 툴을 연동해서 사용하고 있다.

 

한 젊은 엔지니어가 고객사의 사람들과 함께 비행시험을 위한 컨트롤 소프트웨어를 작성했다. 그런데 데이터 스트링을 작성하는 동안 실수로 콤마를 타이핑해서 두 개의 데이터 항목으로 분리해 버렸다. 한 번의 비행동안 흔들리기 시작했다. (조종석 뒤편의 사람들이 구토를 하게 만드는) 요댐퍼가 왜 잘못 동작했는지는 미스터리였다. 경험이 별로 없었던 그 엔지니어는 이전에 비행시험에 사용되었던 소프트웨어 버전과 현재 버전을 비교하기 전까지는 자신이 무엇을 잘못한 건지 상상조차 할 수 없었다. 일주일의 시간과 몇 십만 달러를 소모하고 난 후에야 그 “개선사항”이 발견되었다. 그것은 단순한 콤마였지만 잘못된 위치에 있었다! 그런 에러들을 피하기 위한 단계를 거치는 것은 많은 돈을 절약할 수 있고 아마도 생명을 구할 수 있을 것이다.

 

형상관리 추천사항들   가능한 모든 형상관리 프로세스를 자동화하기 위해 상용툴을 구매하고 배우고 사용하라.   상용 문제점 리포트툴을 구매하고 사용하라.   보증되지 않은 변경이 발생하지 않도록 보장하기 위해 매뉴얼 단계를 추가하라.   형상관리에 관계된 모든 사람을 교육시켜라. 그것은 모든 사람의 책임이다.   모든 산출물들이 형상관리하에 위치하는 것을 보장하라. (공통된 실수들: 써드파티 문서들, 라이브러리, 빌드관련 파일들, 리뷰, 감사결과를 누락)   형상관리 계획을 회사의 정책과 맞추어라. 약간의 변경으로 다른 프로젝트에 재사용.

 

형상관리에 관련된 사람들을 교육하라. 모든 사람이 어떻게 사용하는지를 이해할 뿐만 아니라 그것이 한 사람만의 작업이 아니라는 것을 알고 있는지 확인하라. 프로그램의 라이프사이클을 위해서 필요로 하는, 써드파티 데이터 아이템들을 포함해서 모든 것을 형상관리하에 두어라. 그리고 형상관리 계획을 회사의 모든 프로그램에 사용될 수 있도록 회사의 정책과 일치하게 만들어라. 다시 한 번 말하지만 모든 데이터를 왜 형상관리하에 유지하지 않는가? 비용이 더 드는 것도 아니고, 어렵지도 않고, 레코드를 재생산하려고 할 때, 그것들을 다시 시험하려고 할 때, 혹은 산출물의 어떤 부분을 다시 감사하려고 할 때 앞으로 마주치게 될 많은 질문들을 줄여줄 수 있다. 기억하라. 당산의 형상관리 시스템은 DER과 FAA 감사에 중요한 포인트이다. 당신의 형상관리 레코드에 대한 실질적인 확신은 그들 감사의 예봉을 막아낼 수 있을 것이다.

 

형상관리 보존   모든 산출물들은 컨트롤되어야 한다. 하지만 어떤 것이 보관되어야 하나?   전부? 아니다!   DO-178B/DO-254를 준수하는지를 보여주는 모든 레코드를 보관하라.   이전 버전에 대한 리뷰, 리빌드 혹은 회귀시험할 수 있도록 할 수 있을 만큼의 충분한 레코드를 보관하라.

 

역주) 실제로 형상관리는 DER이 감사를 할 때 가장 먼저 볼 가능성이 높다. 그 만큼 중요하다는 말이다. 각 단계별로 산출물들을 보여주게 되는데 그 산출물들이 정확하다는 근거가 있어야 하며 어떤 과정으로 변경되어 왔는지를 보여주는 히스토리를 보여줄 수 있어야 한다. 따라서 정확한 정보가 제대로 저장되어 있어야 하는데 그 역할을 형상관리가 담당하는 것이다. 참고로 여기에 이슈관리도 포함된다. 어쨌든 이 부분이 제대로 되어 있지 않으면 감사를 받겠다고 제출한 자료에 대한 신뢰성이 흔들리게 된다.   위의 박스에서 “DO-178B/DO-254를 준수하는지를 보여주는 모든 레코드를 보관하라”라고 제시하고 있는 부분도 결국 이런 전제에 기반하는 것이다. 참고로 굳이 보여주지 않는 자료들까지 하나하나 모두 챙겨서 형상관리로 보관할 필요는 없다.   아마도 많은 개발자들은 형상관리에 대해 신경 써 본적이 많이 없을 것이다. 이제부터라도 직접 형상관리를 해보자. 그것이 DO-178의 시작이 될 수 있다.