형상관리(Configuration Management)와 기준선(Baseline)
1. 개요
가. 정의
소프트웨어 개발·운영 과정에서 생성되는 산출물(형상항목, Configuration Item)의 변경을 식별·통제·기록·감사하여 무결성(Integrity)과 일관성(Consistency)을 유지하는 관리 활동으로, 공식 합의된 기준선(Baseline) 을 기준으로 변경을 통제한다.
형상관리는 흔히 "버전관리 도구를 쓰는 것"으로 오해되지만, 본질은 변경을 조직적으로 통제하는 관리 체계(management discipline) 다. 도구는 이를 자동화하는 수단일 뿐이며, 형상관리의 실체는 "무엇을 관리 대상으로 삼고, 그것을 누구의 승인으로 어떻게 바꾸며, 그 변경 이력을 어떻게 남기는가"라는 절차와 책임 구조에 있다. CMMI·ISO/IEC 12207·PMBOK 등 주요 프로세스 모델이 형상관리를 지원 프로세스(supporting process)의 핵심으로 다루는 것도, 형상관리가 개발·품질·유지보수의 모든 단계를 관통하는 기반 활동이기 때문이다.
나. 등장 배경 및 필요성
소프트웨어는 코드·설계서·요구명세·매뉴얼·테스트 케이스 등 수많은 산출물이 여러 사람 손을 거쳐 끊임없이 바뀐다. 통제 없이 각자 수정하면 "어떤 버전이 진짜인지" 알 수 없는 버전 혼란이 생기고, 한 사람의 변경이 다른 사람의 작업을 덮어써(overwrite) 품질이 무너진다. 이런 현상은 규모가 커질수록 기하급수적으로 악화되어, 릴리스 직전 "빌드가 되던 코드가 갑자기 깨지는" 통합 지옥(integration hell)으로 이어진다.
형상관리는 이 문제를 "변경을 금지하는 것이 아니라, 통제된 절차로만 허용"함으로써 푼다. 변경 자체는 소프트웨어의 본질적 속성이므로 막을 수 없고 막아서도 안 된다. 대신 변경이 누구의 판단으로, 어떤 영향 분석을 거쳐, 어떤 이력과 함께 이뤄지도록 규율한다. 이를 통해 ① 변경 이력을 추적(감사·추적성)하고, ② 다수 개발자의 동시 작업 충돌을 방지하며, ③ 특정 시점의 상태(예: 지난달 출시 버전)로 언제든 복원할 수 있게 하고, ④ 어떤 소스·문서·라이브러리 조합이 실제 운영에 배포되어 있는지 정확히 재현(reproducibility)할 수 있게 한다.
다. 특징
형상관리의 핵심 특징은 기준선 중심의 통제, 추적성(traceability) 확보, 책임성(accountability) 부여의 세 가지다. 기준선이라는 고정점을 두어 그 이후 변경만 통제하므로 관리 부담이 무한정 늘지 않고, 요구→설계→코드→테스트의 연결고리를 남겨 "이 코드가 어떤 요구 때문에 존재하는가"를 역추적할 수 있으며, 변경마다 승인자와 사유를 남겨 문제 발생 시 책임 소재를 명확히 한다.
2. 형상관리 프로세스 (전체 구조)
형상관리는 "무엇을 관리할지 정하고(식별)→변경을 통제하고(통제)→상태를 기록하고(상태기록)→기준과 일치하는지 검증(감사)"하는 순환으로 이뤄진다. 이 네 활동은 일회성 단계가 아니라 프로젝트 전 생명주기 동안 반복되는 순환 고리이며, 감사 결과는 다시 식별에 반영되어 관리 대상과 기준을 갱신한다.
flowchart LR
A[형상 식별] --> B[형상 통제]
B --> C[형상 상태 기록]
C --> D[형상 감사]
D -. 피드백 .-> A
subgraph 기준선
BL["Baseline 확정/갱신"]
end
B --> BL
BL --> C
위 그림에서 보듯, 형상 통제 활동을 통과한 변경만이 새로운 기준선으로 승격되고, 그 상태가 기록되며, 주기적 감사를 통해 기준선이 실제 요구와 일치하는지 검증된다. 감사에서 불일치가 발견되면 다시 식별 단계로 환류되어 관리 대상 목록이나 명명 규칙 자체가 보완된다. 이 순환성 때문에 형상관리는 "한 번 세팅하고 끝나는 작업"이 아니라 프로젝트가 살아있는 동안 계속 돌아가는 엔진에 가깝다.
3. 형상관리 4대 활동
각 활동은 형상관리의 서로 다른 질문에 답한다. 식별은 "무엇을", 통제는 "어떻게 바꿀지", 상태기록은 "지금 어떤 상태인지", 감사는 "제대로 됐는지"를 다룬다.
| 활동 | 핵심 질문 | 설명 |
|---|---|---|
| 형상 식별 | 무엇을 관리하나 | 형상항목(코드·문서·라이브러리)을 식별·명명·버전 부여 |
| 형상 통제 | 어떻게 바꾸나 | CR → 영향분석 → CCB 승인 → 반영 |
| 형상 상태 기록 | 지금 어떤 상태인가 | 변경 이력·현재 상태를 기록·보고 |
| 형상 감사 | 제대로 됐는가 | 기준선이 요구와 일치하는지 기능(FCA)·물리(PCA) 감사 |
가. 형상 식별(Configuration Identification)
형상 식별은 "관리할 대상을 정하고 이름표를 붙이는" 활동이다. 모든 산출물을 형상항목으로 삼으면 관리 비용이 폭증하므로, 변경 가능성이 높고 다른 산출물에 영향을 크게 미치는 것(요구명세, 아키텍처 설계, 핵심 소스, 인터페이스 규격 등)을 선별해 형상항목으로 지정한다.
식별의 실무 핵심은 명명 규칙과 버전 체계다. 예를 들어 시맨틱 버저닝(Semantic Versioning, MAJOR.MINOR.PATCH)을 쓰면 2.3.1이라는 번호만으로 "하위 호환이 깨지는 큰 변경인지(MAJOR), 기능 추가인지(MINOR), 버그 수정인지(PATCH)"를 즉시 알 수 있다. 이처럼 식별은 단순 번호 붙이기가 아니라, 이후 통제·추적의 전 과정이 딛고 설 좌표계를 세우는 일이다.
식별이 부실하면 이후 활동 전체가 흔들린다. 관리 대상에서 누락된 항목은 아무도 통제하지 않은 채 몰래 바뀌고(shadow change), 명명이 일관되지 않으면 같은 파일을 여러 이름으로 부르며 이력이 갈라진다. 따라서 프로젝트 초기에 형상항목 목록과 명명 규칙을 확정하는 것이 형상관리 성패의 첫 관문이다.
나. 형상 통제(Configuration Control)
형상 통제는 형상관리의 실질적 핵심이다. 변경요청(CR, Change Request)이 오면 즉시 반영하는 것이 아니라, 영향분석(Impact Analysis) 후 CCB(형상통제위원회, Configuration Control Board)의 승인을 거쳐야만 반영한다. 이 관문이 있기에 무분별한 변경이 걸러지고 변경의 책임 소재가 남는다.
영향분석이 특히 중요하다. 하나의 변경은 겉보기엔 작아 보여도, 그 항목을 참조하는 다른 모듈·문서·테스트에 연쇄적으로 파급된다. 예컨대 공통 라이브러리의 함수 시그니처 하나를 바꾸면, 이를 호출하는 수십 개 모듈이 영향을 받는다. 영향분석은 "이 변경을 반영할 때 함께 손봐야 하는 것이 무엇인가"를 미리 파악해, 부분 변경으로 인한 정합성 붕괴를 예방한다.
CCB는 변경의 비용·위험·편익을 종합 판단하는 의사결정 기구다. 긴급 보안 패치처럼 신속성이 필요한 경우를 위해 간이 승인 경로(emergency CR)를 두기도 하지만, 원칙은 "책임 있는 주체의 승인 없이는 기준선을 바꾸지 않는다"는 것이다. 이 원칙이 지켜져야 "왜 이 코드가 이렇게 바뀌었는가"라는 질문에 항상 답할 수 있다.
다. 형상 상태 기록(Configuration Status Accounting)
상태 기록은 "지금 각 형상항목이 어떤 버전이고, 어떤 변경이 진행 중이며, 무엇이 승인·반려되었는가"를 기록하고 보고하는 활동이다. 변경요청의 접수-검토-승인-반영-검증에 이르는 전 과정의 상태를 추적해, 관리자와 개발자가 언제든 형상의 현재 스냅샷을 볼 수 있게 한다.
이 활동의 산출물은 형상 상태 보고서, 변경 이력 대장, 버전별 릴리스 노트 등이다. 실무에서는 이슈추적 시스템(Jira 등)과 버전관리(Git)를 연동해, 커밋이 어떤 변경요청과 연결되는지 자동으로 기록되게 한다. 상태 기록이 정확해야 감사가 가능하고, 문제 발생 시 "언제, 어떤 변경 이후 문제가 생겼는가"를 역추적할 수 있다.
라. 형상 감사(Configuration Audit)
감사는 "만들어진 것이 약속한 것과 일치하는가"를 검증하는 활동으로, 두 종류가 있다. 기능 감사(FCA, Functional Configuration Audit) 는 산출물이 요구사항·명세대로 기능하는지를 확인하고, 물리 감사(PCA, Physical Configuration Audit) 는 산출물의 구성(문서·코드·매체)이 목록대로 빠짐없이 갖춰졌는지를 확인한다.
감사는 기준선 확정 직전이나 최종 인도 시점에 수행되어, 그때까지 통제된 변경들이 실제로 무결성을 유지했는지 최종 점검한다. 감사에서 불일치가 발견되면 시정 조치가 이뤄지고 그 결과가 식별·통제 활동으로 환류된다. 즉 감사는 형상관리 순환의 품질 게이트 역할을 한다.
예컨대 운영 중 버그 수정 요청이 오면, 개발자가 임의로 패치하는 것이 아니라 CR을 등록하고, 이 변경이 다른 모듈에 미칠 영향을 분석한 뒤 CCB 승인을 받아 반영하고, 그 이력을 기록하며, 릴리스 전 감사로 정합성을 최종 확인한다.
4. 기준선(Baseline) 유형
기준선: 특정 시점에 공식 검토·합의되어 확정된 형상으로, 이후 변경 시 반드시 통제 절차(CCB)를 거쳐야 하는 기준 버전.
기준선을 개발 생명주기의 주요 시점마다 설정하는 이유는, 그때까지의 산출물을 "얼려서(freeze)" 안정된 기준으로 삼아 이후 작업이 흔들리지 않게 하기 위함이다. 기준선이 없으면 모든 산출물이 항상 유동적이어서, 어느 시점의 무엇을 기준으로 검증·통제해야 할지 알 수 없다. 기준선은 "여기까지는 확정, 이후 변경은 통제 대상"이라는 경계선을 그어, 관리 범위를 유한하게 만든다.
개발이 진행될수록 요구→설계→제품 순으로 구체화되므로, 기준선도 그 단계에 맞춰 세 가지로 설정된다.
| 기준선 | 설정 시점 | 확정 내용 |
|---|---|---|
| 기능 기준선(Functional) | 요구분석 완료 | 시스템 요구사항 명세(SRS) |
| 할당 기준선(Allocated) | 설계 완료 | 요구를 구성요소에 할당한 설계 명세 |
| 제품 기준선(Product) | 개발·시험 완료 | 최종 인도 제품 형상(코드·매뉴얼) |
기능 기준선이 "무엇을 만들지"를, 할당 기준선이 "어떻게 나눠 설계할지"를, 제품 기준선이 "실제 만들어진 결과물"을 고정한다. 뒤 기준선은 앞 기준선을 기준으로 검증(추적)되므로, 요구부터 제품까지 일관성이 유지된다. 예를 들어 제품 기준선의 코드가 할당 기준선의 설계를 벗어나면 감사에서 걸러지고, 할당 기준선이 기능 기준선의 요구를 누락하면 요구 추적 매트릭스에서 드러난다. 이렇게 기준선들이 사슬처럼 연결되어 "요구 없는 코드, 코드 없는 요구"를 방지한다.
5. 형상관리 조직·도구 및 변경 통제 흐름
형상관리는 개념이지만 실제 운영은 조직(CCB)과 도구로 구현된다. 아래는 변경요청 하나가 CCB 통제를 거쳐 기준선에 반영되고 배포까지 이어지는 세부 흐름이다.
sequenceDiagram
participant Dev as 개발자
participant CM as 형상관리자
participant CCB as CCB
participant Repo as 저장소/기준선
Dev->>CM: 변경요청(CR) 제출
CM->>CM: 영향분석 수행
CM->>CCB: 심의 요청
CCB-->>CM: 승인 또는 반려
CM->>Repo: 승인 시 변경 반영·기준선 갱신
Repo->>Repo: CI/CD 빌드·배포
Repo-->>CM: 상태 기록·릴리스 노트
이 흐름을 도구가 자동화한다. 버전관리·이슈추적·CI/CD를 연계하면, 코드 변경이 이슈(변경요청)와 연결되고 자동 빌드·배포까지 추적되어 형상의 가시성이 극대화된다. 예컨대 개발자가 커밋 메시지에 이슈 번호를 넣으면 Jira의 해당 CR과 자동 연결되고, 병합 시 Jenkins/GitHub Actions가 빌드·테스트를 돌려 통과한 경우에만 배포되며, 그 결과가 릴리스 노트로 자동 정리된다.
| 구분 | 예 |
|---|---|
| 버전관리 | Git, SVN |
| 이슈·변경관리 | Jira, Redmine |
| CI/CD·릴리스 | Jenkins, GitHub Actions |
| 인프라 형상 | Terraform, Ansible(IaC) |
6. 심화: 형상관리의 확장 — DevOps·IaC·SBOM·공급망 무결성
전통적 형상관리가 "소스와 문서"를 대상으로 했다면, 클라우드·컨테이너 시대의 형상관리는 훨씬 넓은 대상으로 확장되고 있다. 이는 최근 기술사 출제에서도 SCM을 단독으로 묻기보다 DevOps·SBOM·공급망 보안과 엮어 묻는 경향으로 나타난다.
첫째, IaC(Infrastructure as Code) 로 인프라 자체가 형상관리 대상이 되었다. 과거 수작업으로 구성하던 서버·네트워크를 Terraform·Ansible 코드로 선언하면, 인프라 변경도 코드 변경처럼 버전관리·리뷰·롤백이 가능해진다. "서버가 지금 어떤 상태인지"를 코드로 재현할 수 있게 된 것이 큰 진전이다.
둘째, GitOps 는 형상관리 원칙을 배포 운영에 적용한 방식이다. Git 저장소를 "단일 진실 공급원(Single Source of Truth)"으로 삼아, 운영 환경의 원하는 상태(desired state)를 Git에 선언하고, Argo CD 같은 도구가 실제 상태를 Git 선언과 자동으로 일치시킨다. 모든 배포가 Git 커밋으로 남으므로 형상관리의 추적성·롤백성이 배포에까지 확장된다.
셋째, SBOM(Software Bill of Materials) 과 공급망 무결성이 부상했다. 현대 소프트웨어는 방대한 오픈소스 의존성 위에 세워지므로, "우리 제품 안에 어떤 컴포넌트가 어떤 버전으로 들어있는가"를 관리하지 않으면 Log4Shell(2021) 같은 취약점 발생 시 영향 범위조차 파악하기 어렵다. SBOM은 이 구성요소 목록을 SPDX·CycloneDX 등 표준 형식으로 관리하는 것으로, 미국 행정명령(EO 14028)을 계기로 사실상 필수 요건이 되었다. 즉 형상관리가 "내가 만든 것"을 넘어 "내가 가져다 쓴 것"의 무결성까지 책임지는 방향으로 확장되고 있다.
7. 고려사항 및 시사점
- 자동화 연계(DevOps 통합): 형상관리 도구를 버전관리·이슈추적·CI/CD와 통합해, 변경-빌드-배포 전 과정을 추적 가능하게 만드는 것이 현대적 방향이다. 다만 자동화가 CCB의 판단을 대체하는 것이 아니라, 저위험 변경은 자동 승인하고 고위험 변경만 사람의 심의로 보내는 위험 기반 통제로 설계해야 속도와 통제가 조화된다.
- 가시성·책임성 확보: CCB를 통한 변경 통제의 본질은 "누가·왜·무엇을 바꿨는가"를 남겨 변경의 가시성과 책임성을 확보하는 데 있다. 도구만 도입하고 이 절차 규율이 없으면 형상관리는 형식화된다.
- 공급망으로 확장(SBOM): 오픈소스 의존성까지 관리해야 하므로, 구성요소 목록인 SBOM(SPDX·CycloneDX)과 릴리스 관리로 형상관리가 공급망 무결성까지 확장되고 있다. 취약점 대응·라이선스 준수의 기반이 된다.
- 인프라·환경까지 형상화(IaC/GitOps): 코드뿐 아니라 인프라·배포 상태까지 코드로 선언·통제하여, "특정 시점의 시스템 전체를 재현 가능하게" 만드는 것이 신뢰성·복원력의 핵심이다.
- 프로세스 성숙도와의 연계: 형상관리는 CMMI 등 성숙도 모델에서 필수 지원 프로세스로 평가되므로, 조직 차원의 표준 프로세스·역할 정의와 함께 정착시켜야 지속 가능하다.
참고자료
- IEEE Std 828, Standard for Configuration Management in Systems and Software Engineering
- ISO/IEC/IEEE 12207, Software life cycle processes
- CISA, Software Bill of Materials (SBOM): https://www.cisa.gov/sbom
- The White House, Executive Order 14028 on Improving the Nation's Cybersecurity: https://www.federalregister.gov/documents/2021/05/17/2021-10460/improving-the-nations-cybersecurity
한 줄 요약: 형상관리는 식별→통제(CCB)→상태기록→감사 활동으로 산출물 변경을 통제된 절차로만 허용하며, 기능·할당·제품 기준선을 시점별로 고정해 무결성·추적성을 보장하고, 최근 IaC·GitOps·SBOM·공급망 무결성으로 그 대상이 크게 확장되고 있다.