형상관리로 소프트웨어 변경과 기준선을 통제하는 방법
형상관리의 식별·통제·감사·기록 활동과 SDLC 기준선, CVCS·DVCS, 변경 통제 운영 원칙을 정리한다.
2026-08-14 · 최초 발행 2026-04-17
변경이 누적될수록 형상관리가 필요한 이유
소프트웨어의 변경 대상은 소스 코드에만 머물지 않는다. 요구사항, 설계 문서, 라이브러리, 데이터베이스 스키마까지 함께 바뀌며, 이 변화가 통제되지 않으면 버전 혼용과 산출물 불일치가 곧바로 프로젝트 위험이 된다.
형상관리(SCM, Software Configuration Management)는 이런 기술 자산의 상태와 변경 이력을 관리하는 체계다. 파일을 보관하거나 버전 번호를 부여하는 일을 넘어, 개발 과정의 가시성(Visibility), 추적성(Traceability), 무결성(Integrity)을 확보하는 데 목적이 있다.
이 체계가 제공해야 하는 결과는 분명하다. 현재 프로젝트가 어떤 상태인지 확인할 수 있어야 하고, 특정 산출물이 어떤 요구사항과 변경을 거쳐 만들어졌는지 되짚을 수 있어야 한다. 또한 승인되지 않은 수정으로 제품의 정합성이 흔들리지 않도록 해야 한다.
개발 완료 뒤에도 유지보수와 요구 변경은 계속된다. 관리 항목이 늘어난 환경에서는 개발자 간 소스 충돌, 신·구 버전의 혼재, 요구사항과 구현 결과 사이의 괴리가 발생하기 쉽다. 형상관리는 이러한 문제를 예방하고 품질을 보증하는 운영 기반이 된다.
식별에서 기록까지 이어지는 변경 통제
형상관리는 식별, 통제, 감사, 기록의 활동으로 구성된다. 각 활동은 독립된 문서 작업이 아니라 변경을 관리하는 하나의 흐름으로 연결된다.
형상 식별(Configuration Identification)에서는 관리할 대상을 형상 항목(CI, Configuration Item)으로 정한다. 문서, 소스 코드, 데이터베이스 스키마 등에 고유한 이름과 번호 체계를 부여하고, 특정 시점의 산출물 상태를 기준선(Baseline)으로 고정한다. 무엇을 관리하며 어느 상태를 기준으로 삼을지 정하는 단계다.
형상 통제(Configuration Control)는 기준선 이후의 변경을 다룬다. 사용자 요구나 버그 수정을 위한 변경 요청(CR)을 접수하고, 형상 통제 위원회(CCB)가 변경의 타당성과 프로젝트 영향도를 검토해 승인 여부를 결정한다. 승인된 변경만 반영하고 새 버전으로 관리한다.
형상 감사(Configuration Audit)는 변경 결과가 승인 내용과 기준선에 맞는지 확인한다. 기능적 감사에서는 요구된 기능 충족 여부를 검증하고, 물리적 감사에서는 실제 산출물이 문서화된 내용과 일치하는지와 구성 요소의 누락 여부를 확인한다. 형상관리 계획에 따라 활동이 수행됐는지도 점검 대상이다.
형상 기록(Configuration Status Accounting)은 항목의 버전, 승인 상태, 변경 진행 상황을 남기고 보고하는 활동이다. 관계자는 이 기록을 통해 형상관리 결과와 지표를 확인하고 의사결정에 활용할 수 있다.
SDLC를 넘길 때 기준선이 맡는 역할
기준선은 SDLC의 특정 시점에 공식 승인된 산출물 세트다. 다음 단계로 진행하기 위한 기준이 되며, 이후 발생하는 변경을 통제할 출발점이 된다.
| 단계 | 기준선 명칭 | 주요 산출물 및 관리 항목 |
|---|---|---|
| 계획 | 기능적 기준선 (Functional) | 프로젝트 수행계획서, 요구사항 정의서, 요구사항 관리대장 |
| 요구분석 | 분배적 기준선 (Allocated) | ERD(개체관계도), DFD(데이터흐름도), 용어 사전, 기능 명세서 |
| 설계 | 설계 기준선 (Design) | 시스템 아키텍처 정의서, UI 정의서, 데이터베이스 설계서, 프로그램 명세서 |
| 구현 | 시험 기준선 (Test) | 소스 코드, 단위 테스트 시나리오, 빌드 스크립트 |
| 통합/시험 | 제품 기준선 (Product) | 통합 테스트 계획서 및 결과서, 사용자 매뉴얼, 설치 가이드 |
| 설치/운영 | 운용 기준선 (Operational) | 운영자 매뉴얼, 시스템 구성도, 최종 릴리스 노트 |
설계 기준선이 확정되면 구현 단계에서 코딩을 시작할 근거가 마련된다. 진행 중 요구사항이 바뀌면 해당 기준선을 다시 열어(Check-out) 변경 내용을 반영하고, 다시 닫는(Check-in) 절차를 거친다. 이 과정이 없다면 어떤 산출물이 승인된 상태인지 구분하기 어려워진다.
저장소 관리 도구와 자동화의 변화
중앙 집중식 형상관리 도구인 CVS와 SVN은 서버에 소스 코드를 두고 클라이언트가 필요한 부분을 받아 작업하는 방식이다. 충돌 관리가 명확하지만 서버 장애 시 협업이 불가능하다는 제약이 있다.
Git을 비롯한 분산형 형상관리 도구(DVCS)는 작업자마다 전체 저장소의 복사본을 로컬에 보유한다. 오프라인 작업이 가능하며 브랜치(Branch) 전략을 통해 병렬 개발을 지원한다. Mercurial도 이 방식의 대표 도구다.
현재의 형상관리는 CI/CD(지속적 통합/지속적 배포) 파이프라인과도 이어진다. 소스 코드가 푸시된 뒤 빌드, 테스트, 배포가 자동으로 수행되는 환경에서는 저장소의 변경 이력과 자동화 결과가 함께 관리 대상이 된다.
팀의 변경 관리를 운영 규칙으로 만드는 법
도구를 도입했다고 형상관리가 정착되지는 않는다. 변경 이유가 남고, 기준선이 점검되며, 팀이 같은 협업 규칙을 따르는 운영 방식이 필요하다.
커밋 메시지는 "Fix bug"처럼 모호하게 남기기보다 변경 사유와 티켓 번호를 포함하는 규약을 정하는 편이 좋다. 변경 이력과 업무 맥락을 연결할 수 있기 때문이다.
마일스톤마다 형상 감사를 수행하면 산출물 누락과 버전 불일치를 조기에 확인할 수 있다. CCB도 모든 변경을 같은 강도로 다루기보다, 경미한 변경은 실무자 수준에서 처리하고 중요한 설계 변경에 집중하는 유연성이 필요하다. 지나치게 엄격한 통제는 개발 속도를 떨어뜨릴 수 있다.
브랜치 전략 역시 팀의 형상관리 규칙에 포함된다. Git Flow나 GitHub Flow처럼 작업 방식에 맞는 전략을 명확히 정의하면 협업 중 발생하는 혼선을 줄일 수 있다.
형상관리는 과거 기록을 보관하는 작업이 아니라 현재의 제품 상태를 파악하고 이후 변경에 대응하기 위한 자산 관리 활동이다. 식별, 통제, 감사, 기록과 단계별 기준선이 함께 작동할 때 산출물의 가시성과 무결성을 유지할 수 있다.
Sources
- IEEE Standard for Software Configuration Management Plans (IEEE Std 828-2012)
- Roger S. Pressman, Software Engineering: A Practitioner's Approach
- S.A. Whitgift, Methods and Tools for Software Configuration Management
- National Institute of Standards and Technology (NIST) Configuration Management Guidance
- Software Engineering Institute (SEI) CMMI for Development Version 1.3