25. 기준선 (Baseline) — 형상 관리의 공식 참조점

핵심 인사이트 (3줄 요약)

본질: 기준선(Baseline)은 SCM (Software Configuration Management, 소프트웨어 형상 관리)에서 공식적으로 검토·승인된 형상 항목(CI, Configuration Item)의 집합으로, 변경을 통제하는 기준점이자 향후 개발의 출발점이 되는 공식 스냅샷이다.

가치: 기준선이 없으면 "어느 버전이 공식 버전인가?"를 알 수 없어 개발팀이 서로 다른 버전을 기준으로 작업하는 혼란이 발생한다. 기준선은 팀 전체가 동일한 기준점에서 협업하고, 변경 통제 위원회(CCB)의 공식 승인 없이는 변경할 수 없는 안정화된 기반을 제공한다.

판단 포인트: 소프트웨어 개발 생명주기(SDLC)의 각 단계별 기준선(기능 기준선 → 할당 기준선 → 제품 기준선)을 이해하고 각 단계에서 무엇이 기준선에 포함되는지 정확히 파악하는 것이 기술사 시험과 실무 모두에서 핵심이다.

Ⅰ. 개요 및 필요성

기준선(Baseline)은 마치 사진을 찍는 것과 같다. 특정 시점의 소프트웨어 구성(요구사항, 설계, 코드, 테스트 명세)을 공식적으로 고정하여 이후 변경이 기준선에 비해 얼마나 바뀌었는지 추적할 수 있게 한다.

┌────────────────────────────────────────────────────────────┐
│           3대 기준선 (IEEE 828)                             │
├────────────────────────────────────────────────────────────┤
│                                                            │
│  개발 단계    기준선 유형        포함 항목                    │
│  ─────────── ─────────────── ──────────────────────────   │
│  요구사항     기능 기준선       승인된 시스템 요구사항          │
│  분석/설계    할당 기준선       소프트웨어 요구사항, 설계 문서  │
│  구현/테스트  제품 기준선       소스 코드, 빌드, 테스트 결과    │
│                                                            │
│  기준선 변경 → CCB 승인 필수                                 │
└────────────────────────────────────────────────────────────┘

📢 섹션 요약 비유: 기준선은 건물 설계도의 공식 확정본이다. 확정 전에는 자유롭게 수정하지만, 확정 후에는 건축 허가(CCB 승인) 없이 벽을 허물거나 옮길 수 없다.

Ⅱ. 아키텍처 및 핵심 원리

기준선과 변경 통제 흐름

[현재 기준선 v1.0]
       │
변경 요청(CR) 제출
       │
[CCB 검토·승인/거부]
       │ (승인)
       ▼
변경 구현 → 테스트 → 검증
       │
[새 기준선 v1.1] ← 업데이트

Git 관점에서의 기준선

# 릴리스 기준선 = Git 태그
git tag -a v1.0.0 -m "Release 1.0.0 Baseline - 2026-04-29"
git push origin v1.0.0

# 기준선 이후 변경 내역 추적
git log v1.0.0..HEAD --oneline

📢 섹션 요약 비유: Git 태그(Tag)가 현대의 기준선이다. 특정 커밋에 태그를 붙이면 "이 시점이 공식 v1.0 릴리스"라고 선언하는 것이며, 이후 변경은 이 태그를 기준으로 추적된다.

Ⅲ. 비교 및 연결

기준선 유형	설정 시점	주요 항목	변경 통제 주체
기능 기준선	SRR (시스템 요구사항 검토) 후	시스템 요구사항 명세서	시스템 엔지니어링 팀
할당 기준선	PDR (예비 설계 검토) 후	SW 요구사항, 인터페이스 명세	SW CCB
제품 기준선	TRR (테스트 준비 검토) 후	소스코드, 빌드, 테스트 명세	QA + CCB

📢 섹션 요약 비유: 기능 기준선은 건물의 용도 결정(무엇을 짓는가), 할당 기준선은 층별 평면도 확정(어떻게 나누는가), 제품 기준선은 준공 검사 후 완성된 건물(무엇이 만들어졌는가)이다.

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

실무 시나리오: 항공 SW 개발 기준선 관리 (DO-178C)

요구사항 기준선: JIRA Epic → 시스템 요구사항 명세서 v1.0 → CCB 승인.
설계 기준선: 아키텍처 설계서 v1.0 → 코드 리뷰 → CCB 승인.
제품 기준선: Git 태그 v1.0.0 → 빌드 결과물 + 테스트 리포트 패키지 → DO-178C DER 승인.
변경 통제: 비행 중 발견된 결함 → CR 제출 → CCB 긴급 검토 → 핫픽스 기준선 v1.0.1.

안티패턴

기준선을 설정했지만 CCB 프로세스 없이 개발자가 임의로 기준선 항목을 수정하는 "Shadow Baseline" 안티패턴. 공식 기준선과 실제 코드베이스가 불일치하면 감사 시 증적 불일치로 인증 실패가 발생한다.
📢 섹션 요약 비유: 기준선을 몰래 바꾸는 건, 건물 도면을 허가 없이 수정하는 것이다. 완공 검사(감사) 때 도면과 실제 건물이 다르면 불법 건축물로 판정된다.

Ⅴ. 기대효과 및 결론

기대효과	내용
변경 통제	무허가 변경 방지, CCB 승인 추적
협업 기준점	팀 전체가 동일 버전 기반 작업
감사·인증 증적	기준선 기반 변경 이력 제출

현대 DevOps에서 기준선은 GitOps의 Git 태그·릴리스 브랜치로 자동화되며, Infrastructure as Code(IaC)의 Terraform 상태 파일도 인프라 기준선의 역할을 한다.

📢 섹션 요약 비유: 기준선은 소프트웨어 개발의 구간 기록이다. 마라톤에서 5km, 10km 구간 기록처럼, 특정 시점의 완성 상태를 공식 기록하여 이후 진행 상황을 측정하는 기준이 된다.

📌 관련 개념 맵

개념	연결 포인트
SCM (형상 관리)	기준선이 핵심 구성 요소인 상위 관리 체계
CCB (변경 통제 위원회)	기준선 변경 승인 주체
Git 태그	현대 기준선의 기술적 구현체
CI/CD 파이프라인	기준선(릴리스 태그) 트리거 기반 자동 배포
IaC Terraform State	인프라 기준선의 현대적 형태

📈 관련 키워드 및 발전 흐름도

[형상 식별 — CI 정의 및 명명]
    │
    ▼
[기준선 설정 — CCB 승인, 공식 스냅샷 고정]
    │
    ▼
[형상 통제 — 기준선 이후 변경 통제·승인]
    │
    ▼
[형상 상태 기록(CSA) — 기준선 기반 이력 추적]
    │
    ▼
[GitOps 기준선 — Git 태그/릴리스 자동화]

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

기준선은 게임 저장 포인트처럼, 소프트웨어의 공식 체크포인트예요!
체크포인트를 저장한 후에는 어떤 변경이든 선생님(CCB)의 허락을 받아야 할 수 있어요.
덕분에 팀 전체가 같은 버전을 기준으로 일하고, 나중에 문제가 생겨도 체크포인트로 돌아갈 수 있답니다!