167. SCM (Software Configuration Management, 소프트웨어 형상 관리)

핵심 인사이트

본질: SCM (Software Configuration Management, 소프트웨어 형상 관리)은 SW 산출물의 변경을 체계적으로 식별·통제·기록·감사하는 관리 체계로—베이스라인(Baseline) 기반의 변경 통제가 핵심이다.

가치: SCM이 없으면 "어떤 버전이 운영 중인가", "누가 언제 무엇을 바꿨는가"를 알 수 없어—장애 발생 시 원인 추적과 롤백이 불가능해진다.

판단 포인트: SCM의 4대 기능—식별(Identification)→통제(Control)→상태 기록(Status Accounting)→감사(Audit)의 순서와 각 기능의 역할을 명확히 구분하라.

Ⅰ. 개요 및 필요성

SCM (Software Configuration Management, 소프트웨어 형상 관리)은 소프트웨어 시스템의 구성 요소(형상 항목, Configuration Item)에 대한 변경을 체계적으로 관리하는 프로세스다. IEEE 828 표준이 SCM 계획의 요구사항을 정의하며, CMMI 레벨 2의 핵심 프로세스 영역이다.

SCM이 필요한 이유는 SW 개발 특성에 있다. 소프트웨어는 물리적 제약 없이 쉽게 변경되고, 변경이 다른 부분에 예상치 못한 영향을 미친다. "작동하던 코드가 갑자기 안 된다"는 문제는 대부분 추적되지 않은 변경 때문이다. SCM은 이 변경의 역사를 기록하고 통제한다.

실무에서 SCM은 버전 관리(Version Control)만을 의미하지 않는다. 버전 관리는 SCM의 일부일 뿐이다. SCM에는 변경 요청(Change Request) 프로세스, CCB (Configuration Control Board, 형상 통제 위원회) 승인, 베이스라인 설정, 릴리스 관리, 형상 감사까지 포함된다.

📢 섹션 요약 비유: SCM은 병원의 의무 기록 관리와 같다. 모든 처방(변경)이 기록되고, 특정 처방(변경)을 누가 언제 내렸는지 추적 가능하며, 부작용(버그) 발생 시 원인을 찾아 이전 상태로 돌아갈 수 있다.

Ⅱ. 아키텍처 및 핵심 원리

SCM 4대 기능

┌──────────────────────────────────────────────────────────────┐
│              SCM 4대 기능                                     │
├──────────────────────────────────────────────────────────────┤
│                                                              │
│  1. 형상 식별 (Configuration Identification)                 │
│     → CI(Configuration Item) 식별 및 이름/번호 부여         │
│     → 형상 항목: 소스코드, 문서, DB 스키마, 테스트 케이스   │
│     → 기준: 무엇을 관리할 것인가 결정                       │
│                                                              │
│  2. 형상 통제 (Configuration Control)                        │
│     → 변경 요청(CR) → CCB 검토·승인 → 구현 → 검증          │
│     → CCB: 형상 통제 위원회                                 │
│     → 무허가 변경 방지                                       │
│                                                              │
│  3. 형상 상태 기록 (Configuration Status Accounting)         │
│     → 형상 항목의 현재 상태, 변경 이력 기록                 │
│     → "지금 어느 버전이 어디에 배포됐는가" 추적             │
│     → 감사 추적 (Audit Trail)                               │
│                                                              │
│  4. 형상 감사 (Configuration Audit)                          │
│     → 물리적 감사: 산출물이 명세대로 구현됐는가             │
│     → 기능적 감사: 성능/기능 요구사항 충족 여부             │
│     → 독립적 검증                                           │
└──────────────────────────────────────────────────────────────┘

베이스라인 (Baseline) 종류

┌────────────────────────────────────────────────────────────────┐
│  베이스라인 유형                                               │
├──────────────────┬─────────────────────────────────────────────┤
│  기능 기준선     │ 요구사항 검토 완료 후 (SRR 통과)            │
│  (Functional)    │ = 요구사항 명세서 (SRS) 확정               │
├──────────────────┼─────────────────────────────────────────────┤
│  할당 기준선     │ 시스템 설계 검토 완료 후 (PDR/CDR)          │
│  (Allocated)     │ = 설계 명세서 확정                          │
├──────────────────┼─────────────────────────────────────────────┤
│  제품 기준선     │ 테스트 완료 후 (TRR 통과)                   │
│  (Product)       │ = 최종 SW 제품 확정 (릴리스)                │
└──────────────────┴─────────────────────────────────────────────┘

베이스라인의 의미:
  공식 검토·승인 후 잠긴(Locked) 스냅샷
  변경 시 반드시 CCB 승인 필요
  SCM 상태 기록의 기준점

변경 관리 프로세스

변경 요청(CR) → 영향 분석 → CCB 검토 → 승인/거부
    → 구현 → 검증 → 기준선 업데이트 → 릴리스

버전 관리 시스템

시스템	유형	특징
Git	분산형 (DVCS)	현재 업계 표준, 오프라인 작업 가능
SVN (Subversion)	중앙 집중형	단순 이진 파일 관리에 적합
Mercurial	분산형	Git과 유사, 단순성 강조
ClearCase	기업용	대기업, 복잡한 브랜치 관리

📢 섹션 요약 비유: SCM 베이스라인은 건물 인허가 서류와 같다. 인허가(CCB 승인) 없이 설계를 바꾸면 법적 문제가 생기듯, 베이스라인 없이 SW를 변경하면 무엇이 최신인지 아무도 모르게 된다.

Ⅲ. 비교 및 연결

SCM vs 형상 관리 도구 범위 비교

범위	도구	SCM의 역할
버전 관리	Git, SVN	CI 기반—코드·문서 이력 관리
빌드 관리	Maven, Gradle, CMake	재현 가능한 빌드
릴리스 관리	Jira, ServiceNow, JIRA	릴리스 계획·추적
형상 통제	CCB 프로세스	변경 승인 절차
배포 관리	Ansible, Kubernetes	운영 환경 일관성

SCM vs DevOps 형상 관리

전통적 SCM:
  엄격한 CCB 승인, 베이스라인 중심
  → 대규모 미션 크리티컬 시스템에 적합

DevOps 형상 관리:
  IaC (Infrastructure as Code): 인프라도 코드로 관리
  GitOps: Git이 단일 진실의 원천 (Single Source of Truth)
  → 클라우드 네이티브, 고속 배포 환경에 적합

공통:
  변경 이력 추적, 롤백 능력, 감사 가능성은 양쪽 모두 필수

📢 섹션 요약 비유: 전통적 SCM과 GitOps의 관계는 종이 서류 결재(CCB)와 전자 결재 시스템(PR)의 차이다. 원칙(변경 추적, 승인)은 같지만, 속도와 자동화 수준이 다르다.

Ⅳ. 실무 적용 및 기술사 판단

CCB (Configuration Control Board)

CCB (형상 통제 위원회) 구성:
  - PM (Project Manager)
  - 시스템/소프트웨어 아키텍트
  - 품질 보증 담당자
  - 테스트 담당자
  - 해당 변경 영향을 받는 이해관계자

CCB 역할:
  - 변경 요청(CR) 평가
  - 영향 분석 검토
  - 승인/거부/보류 결정
  - 우선순위 결정

CCB 회의 주기:
  - 소규모: 주간
  - 대규모: 필요 시 소집

기술사 시험 판단 포인트

SCM 4대 기능 순서: 식별→통제→상태 기록→감사 (암기)
베이스라인 3종류: 기능 기준선(요구사항 확정), 할당 기준선(설계 확정), 제품 기준선(최종 제품 확정)
CCB: 모든 베이스라인 변경의 관문—CCB 없이는 베이스라인을 바꿀 수 없다
IEEE 828: SCM 계획 표준—SCM 계획서(SCMP)에 포함되어야 할 내용 정의
CMMI 레벨 2: CM (Configuration Management)이 레벨 2 프로세스 영역

📢 섹션 요약 비유: CCB는 회사의 결재 라인과 같다. 아무리 좋은 아이디어(변경)도 결재자(CCB)의 도장이 없으면 실행할 수 없다—이 제약이 불편해 보여도 통제 없는 변경의 리스크보다는 낫다.

Ⅴ. 기대효과 및 결론

SCM을 체계적으로 적용하면:

변경 추적성: 언제, 누가, 무엇을, 왜 바꿨는지 모든 이력을 추적한다.
롤백 능력: 문제 발생 시 이전 베이스라인으로 신속히 복구한다.
감사 가능성: ISO 9001, CMMI 등 품질 인증의 증거 자료가 된다.
릴리스 일관성: 모든 환경(개발/스테이징/운영)에 동일한 버전이 배포됨을 보장한다.

SCM의 핵심 교훈은 "변경은 피할 수 없지만, 통제되지 않은 변경은 재앙이다"이다. SW 개발에서 변경은 생명이다—하지만 추적·통제되지 않은 변경은 시스템을 카오스로 만든다. SCM은 이 변경을 질서 있게 관리하는 엔지니어링 기반이다.

📢 섹션 요약 비유: SCM 없는 대형 SW 프로젝트는 도서관 사서 없는 도서관과 같다. 책(코드)이 아무 곳에나 꽂혀 있고, 누가 대출했는지도 모르며, 필요한 책을 찾을 수 없게 된다.

📌 관련 개념 맵

개념	설명	연관 키워드
SCM (Software Configuration Management)	SW 형상 식별·통제·기록·감사 체계	IEEE 828
CI (Configuration Item, 형상 항목)	SCM 관리 대상 단위 (코드, 문서 등)	형상 식별
Baseline (베이스라인)	공식 승인된 형상 스냅샷	변경 통제 기준
CCB (Configuration Control Board)	변경 요청 검토·승인 위원회	형상 통제
SCMP (SCM Plan)	IEEE 828 기반 SCM 계획서	IEEE 828
버전 관리 (Version Control)	SCM의 일부, Git/SVN	Git
GitOps	Git을 Single Source of Truth로 활용	DevOps SCM
릴리스 관리 (Release Management)	베이스라인→운영 배포 관리	CD

👶 어린이를 위한 3줄 비유 설명

SCM은 레고 설명서 관리와 같아요 — 어떤 조각(형상 항목)이 있고, 누가 어떻게 바꿨는지 기록해요.
베이스라인은 "오늘 이 모습이 공식이야"라고 사진을 찍어두는 것이에요 — 나중에 무언가 망가지면 사진을 보고 원래대로 돌아갈 수 있어요.
CCB는 변경 허가증이에요 — 아무나 레고를 마음대로 바꾸면 다른 친구들이 헷갈리니까, CCB의 허락을 받아야만 바꿀 수 있어요.