Introduction

프로젝트의 어떤 요소가 아무도 모르는 사이에 제멋대로 바뀐다면 참여자 전체에게 영향을 끼칠 수 있기 때문에, 특히 모두에게 열린 프로젝트라면 변경 사항을 통제 하에 두는 것은 매우 중요한 일입니다. 만약 시스템 테스트를 통과하거나 이미 릴리즈된 코드를 개발자가 멋대로 바꾼다면? 이미 구현이 완료된 데이터베이스 스키마를 데이터베이스 관리자가 멋대로 바꾼다면? OpenAPI 스펙을 임의로 바꾸고 공지하지 않는다면? 이 모든 문제를 해결하는 것이 바로 형상 관리Configuration Management입니다. 이 글에서는 CMMI의 형상 관리 목표(베이스라인 확립, 변경 추적·제어, 통합성 확립)를 중심으로 형상 관리 시스템의 구성 요소, 변경 제어 프로세스, 그리고 지속적 통합과의 관계를 살펴봅니다.

Configuration Management

소프트웨어 형상 관리Software Configuration Management, SCM는 소프트웨어 프로세스 전반에 걸쳐 적용되는 우산 활동umbrella activity이다.1 SCM의 목적은 형상을 인식하고 제어하며, 그 변화를 추적·감시하여 작업물work product의 통합성을 유지하는 것이다. Pressman에 따르면 SCM 활동은 네 가지로 요약된다. 변화를 식별하고identify, 제어하고control, 올바르게 구현되고 있는지 확인하고ensure, 관계자에게 보고report하는 것이다.

소프트웨어 유지보수software support와 형상 관리는 구분해야 한다. 유지보수는 소프트웨어가 고객에게 인도되고 운영에 들어간 이후에 수행되는 활동이지만, 형상 관리는 프로젝트가 시작되는 순간부터 소프트웨어가 퇴역할 때까지 지속되는 추적·제어 활동이다.

변화의 원천은 다양하다. 새로운 사업 조건이나 시장 환경이 요구사항을 바꾸기도 하고, 조직 개편이 프로젝트 우선순위를 뒤흔들기도 하며, 예산이나 일정 제약이 시스템 범위를 재정의하게 만들기도 한다. 이 모든 변화를 통제하기 위한 세 가지 목표가 있고 프랙티스들의 관계는 아래와 같다.

이제 각 목표와 하위 프랙티스들을 살펴보자.

Establish Baselines

첫 번째 목표는 베이스라인(baseline)을 확립하는 것이다. 그런데 베이스라인이란 도대체 무엇일까? 베이스라인의 정의는 아래와 같다.

Definition

A set of specifications or work products that has been formally reviewed and agreed on, which thereafter serves as the basis for further development, and which can be changed only through change control procedures.(CMMI, IEEE)

베이스라인은 정식으로 리뷰되고 합의된 작업물이나 명세 사항specification의 모음집을 의미한다. 이렇게 만들어진 베이스라인은 추후 개발의 초석이 되며, 변화 제어 과정change control procedure을 통해서만 바뀔 수 있다. 형상 아이템이 베이스라인이 되기 전에는 변경이 빠르고 비공식적으로 이루어질 수 있지만, 일단 베이스라인이 확립되면 모든 변경은 정해진 절차를 거쳐야 한다.

대표적인 소프트웨어 베이스라인으로는 시스템 명세System Specification, 소프트웨어 요구사항Software Requirements, 설계 명세Design Specification, 소스 코드Source Code, 테스트 계획·절차·데이터Test Plans/Procedures/Data, 운영 시스템Operational System 등이 있다. 베이스라인을 세우기 위한 프랙티스는 총 세 가지다.

Identify Configuration Items

우선 형상 관리의 대상이 되는 형상 아이템Configuration Item을 파악해야 한다. 그런데 형상 아이템은 대체 무엇일까?

Configuration Item

형상 아이템이란 사용자에게 전달되는 제품들, 지정된 내부 작업물들, 그리고 이러한 작업물들을 만들고 기술하는 과정에서 얻은 제품이나 도구 등을 모두 아우른다. Pressman은 SCI를 "소프트웨어 프로세스의 일부로 생산되는 모든 정보를 구성하는 이름 있는 정보 요소"로 정의하며, 하나의 UML 다이어그램만큼 작을 수도 있고 설계 문서 전체만큼 클 수도 있다고 설명한다.

형상 아이템에는 요구사항, 계획, 설계 명세 사항, 데이터베이스 스키마, 데이터 모델, 백로그backlog, 소스 코드, 라이브러리, 바이너리 파일, 테스트 명세 사항, 파일, 테스트용 도구와 스크립트 등이 포함된다. 여기에 더해 컴파일러 등 빌드, 패키징 등의 개발 활동에 사용된 도구와 환경, 그리고 빌드 스크립트 등 배포 파이프라인 상의 스크립트도 형상 아이템에 포함된다.

실제로 SCI들은 구성 객체configuration object로 조직된다. 예를 들어 DesignSpecification 객체는 DataModel과 ComponentN을 포함하고, SourceCode와 TestSpecification은 이들과 상호관계interrelationship로 연결된다. 이러한 의존 관계를 추적하면 한 객체의 변경이 다른 객체에 미치는 영향을 파악할 수 있다.2

Establish a Configuration Management System

그 다음 형상 관리 시스템을 확립해야 한다. 그런데 형상 관리 시스템은 구체적으로 무엇일까?

형상 관리 시스템

형상을 관리한다는 것은 일종의 검문과 같다. 모든 변경사항을 수용할 필요가 없고, 수용하면 새로운 문제가 생기기도 하기 때문에 절차를 거쳐 필요한 변화만 수용하는 것이다. 그래서 형상 관리 시스템은 의사결정의 과정이기도 하다.

Dart는 형상 관리 시스템을 구성하는 네 가지 요소를 제시한다.3 컴포넌트 요소component elements는 파일 관리 시스템(데이터베이스)과 결합된 도구 집합으로 SCI에 대한 접근과 관리를 가능하게 한다. 프로세스 요소process elements는 변경 관리에 대한 효과적인 접근 방식을 정의하는 절차와 태스크의 모음이다. 구축 요소construction elements는 올바른 버전의 검증된 컴포넌트가 조립되었는지를 보장하며 소프트웨어 구축을 자동화하는 도구 집합이다. 인적 요소human elements는 소프트웨어 팀이 효과적으로 SCM을 수행하도록 돕는 도구와 프로세스 기능이다.

위 그래프는 변경 통제 과정을 다이어그램으로 나타낸 것인데, 당연히 이 과정에서 버전 관리 시스템*Version Control System*은 확립되어 있어야 한다.

SCM 저장소

SCM 저장소repository는 소프트웨어 팀이 변경을 효과적으로 관리할 수 있게 하는 메커니즘과 데이터 구조의 집합이다. 저장소는 데이터 무결성, 공유, 통합을 보장하는 데이터베이스 기능뿐만 아니라, 버전 관리versioning, 의존성 추적과 변경 관리dependency tracking and change management, 요구사항 추적requirements tracing, 형상 관리configuration management, 감사 추적audit trail 등의 SCM 고유 기능을 제공한다.

Create or Release Baselines

형상 관리 시스템이 확립되면 베이스라인을 만들거나 릴리즈한다.

Track and Control Changes

다음 목표는 프로젝트에서 발생하는 변화들을 추적하고 제어하는 것이다. 이를 위한 프랙티스는 총 두 가지다.

Track Change Requests for Configuration Items

첫 번째는 형상 아이템에 대한 변경 요청을 추적하는 것이다. 변경 요청은 새로 만들어지거나 바뀐 요구사항에서 비롯되기도 하지만, 작업물에서 발견된 오류를 수정하기 위해 발생하기도 한다. 어떤 경우든 해당 변경이 가져올 영향을 분석하고 이해관계자들과 리뷰하여 합의를 이끌어내야 한다. 그 다음 변경이 문제없이 잘 이루어지는지 끝까지 추적해야 한다.

Control Changes to Configuration Items

다음 프랙티스는 형상 아이템의 변화를 제어하는 것이다. Pressman에 따르면 변경 제어의 구체적인 과정은 다음과 같다. 변경 요청change request이 접수되면 개발자가 기술적 타당성, 잠재적 부작용, 전체 영향, 예상 비용을 평가한다. 평가 결과는 변경 보고서change report로 작성되어 변경 제어 기관Change Control Authority, CCA에 전달되며, CCA가 변경의 상태와 우선순위를 최종 결정한다. 승인된 변경에 대해서는 엔지니어링 변경 명령Engineering Change Order, ECO이 발행되고, 해당 객체를 체크아웃check out하여 수정한 뒤 SQA 활동을 거쳐 다시 체크인check in한다.4

변경 제어에서 핵심이 되는 두 가지 메커니즘은 접근 제어access control와 동기화 제어synchronization control다. 접근 제어는 어떤 엔지니어가 특정 형상 객체를 수정할 권한을 가지는지를 관장하고, 동기화 제어는 두 사람이 동시에 수행한 변경이 서로를 덮어쓰지 않도록 보장한다.

Establish Integrity

세 번째 목표는 통합성integrity을 확립하는 것이다. 이를 위한 프랙티스는 총 두 가지다.

Establish and Maintain Records Describing Configuration Items

첫 번째 프랙티스는 형상 아이템을 기술하는 기록을 만들고 유지하는 것이다. 형상 아이템이 바뀌어온 과정revision history, 변경 기록change log, 변경 요청 기록change request records, 그리고 형상 아이템의 상태5가 기록에 포함된다.

Perform Configuration Audits to Maintain the Integrity of Configuration Baseline

다음 프랙티스는 형상에 대한 감사를 진행해 형상 베이스라인의 통합성을 유지하는 것이다. 이를 위해 총 세 가지 감사가 이루어진다.

Functional Configuration Audit

기능적 형상 감사Functional Configuration Audit는 형상의 완전성completeness를 감사하여 모든 요구사항이 충족되었는지를 중점적으로 본다. 넣기로 한 기능이 다 들어가 있는지, 테스트를 통과했는지, 원하는 내용이 다 포함되어 있는지를 보게 된다.

Physical Configuration Audit

물리적 형상 감사Physical Configuration Audit에서는 맞는 제품이 제대로 모여 있는지를 평가한다. 인터페이스를 바꿔야 한다면 인터페이스가 물리적으로 제대로 바뀌었는지를 이 감사에서 보게 된다.

Configuration Managements Audit

형상 관리 감사Configuration Managements Audit에서는 형상 관리 기록과 형상 아이템 그 자체가 완전하고, 지속적이고, 정확한지를 중점적으로 본다.

지속적 통합과 형상 관리

애자일 개발 환경에서 형상 관리는 지속적 통합Continuous Integration, CI과 밀접하게 연결된다. CI의 모범 사례로는 코드 변형variant의 수를 최소화하고, 일찍 그리고 자주 테스트하며, 일찍 그리고 자주 통합하고, 테스트·빌드·코드 통합을 자동화하는 도구를 활용하는 것이 있다.

CI는 각 변경이 프로젝트 소스 코드에 즉시 통합되어 컴파일되고 자동으로 테스트됨을 보장한다. 이를 통해 피드백을 가속화하고accelerated feedback, 품질을 높이며increased quality, 통합 실패의 위험을 줄이고reduced risk, 형상 상태 보고의 정확성을 향상시킨다improved reporting.6

Google은 이 원칙을 극단까지 밀고 나가 트렁크 기반 개발trunk-based development을 채택했다. 하나의 저장소에 개발 브랜치를 두지 않는 이 정책은 "모든 의존에 대해 선택할 수 있는 버전은 단 하나여야 한다"는 원버전 규칙One-Version Rule과 결합되어, 대규모 코드베이스에서도 형상의 일관성을 유지할 수 있게 해 준다.

마무리

형상 관리는 소프트웨어 프로세스의 시작부터 끝까지 변화를 통제하는 활동이다. 베이스라인을 확립하고, 변경 요청을 추적·제어하며, 감사를 통해 통합성을 유지한다. 형상 관리의 토대 위에 버전 관리 시스템이 놓이고, 테스트와 지속적 통합이 어우러질 때 비로소 변화에 대한 신뢰할 수 있는 대응이 가능해진다.

출처

  • Pressman, R.S. and Maxim, B.R. (2020) Software engineering: a practitioner’s approach. Ninth edition. New York, NY: McGraw-Hill Education. — Ch.22 Software Configuration Management.
  • Dart, S. (2001) "Spectrum of Functionality in Configuration Management Systems." Software Engineering Institute, Carnegie Mellon University.
  • Winters, T., Manshreck, T. and Wright, H. (2020) Software engineering at Google: lessons learned from programming over time. Sebastopol, CA: O’Reilly Media. — Ch.16 Version Control and Branch Management.
  • IEEE Std 828 (2012) IEEE Standard for Configuration Management in Systems and Software Engineering. IEEE Computer Society.

Footnotes

  1. 우산 활동이란 소프트웨어 프로세스의 특정 단계에 국한되지 않고 프로세스 전반에 걸쳐 적용되는 활동을 말한다. Pressman은 SCM, SQA, 기술 리뷰 등을 우산 활동으로 분류한다. ↩

  2. Pressman, Ch.22. 구성 객체 간의 의존 관계를 추적하면 하나의 SCI를 변경했을 때 영향을 받는 다른 SCI를 자동으로 식별할 수 있다. 이를 영향 관리impact management라 한다. ↩

  3. Dart, S. (2001) "Spectrum of Functionality in Configuration Management Systems." Software Engineering Institute, Carnegie Mellon University. ↩

  4. 변경 제어에는 세 가지 단계가 있다. 베이스라인 확립 전에는 비공식적informal 제어만 적용되고, 베이스라인이 확립되면 프로젝트 수준의 제어가 적용되며, 소프트웨어가 고객에게 릴리즈된 이후에는 공식적formal 변경 제어가 시행된다. ↩

  5. 준비 안됨not ready, 테스트, 빌드, 프로덕션, 더 이상 사용하지 않음deprecated, 더 이상 존재하지 않음decommissioned 등의 상태가 존재한다. ↩

  6. Pressman, Ch.22. Molinari, L. (2012) Agile Testing with JIRA에서 인용된 CI의 네 가지 장점이다. ↩