형상관리, 품질과 속도를 동시에 잡는 운영 체계

형상관리는 회사 전체의 운영 체계 이다. 소스코드, 문서, 인프라, 배포 이력까지 한 줄로 묶어 재현 가능하고 감사 가능한 상태로 유지하는 것이 형상관리의 본질이다. 

 

---

🔎 형상관리란?

형상관리(Configuration Management, CM)는 시스템을 구성하는 모든 항목(CI: Configuration Item)을 식별·버전화 ·변경통제 ·감사 ·추적해 제품/서비스의 일관성과 재현성을 보장하는 경영 ·기술 활동이다. 

여기서 CI에는 소스코드만이 아니라 요구사항, 설계서, 테스트 케이스, 빌드 산출물, 인프라 코드, 운영 설정, 배포 승인 기록까지 포함된다. 결과적으로 '어떤 요구사항이 언제, 누구에 의해, 어떤 코드/설정 변경으로, 어떤 환경에 배포되었는가'를 끝까지 설명할 수 있어야 한다. 

 

---

🤔  왜 형상관리 시스템이 필요할까?

• 품질 보증(Traceability): 요구사항 -> 코드 -> 테스트 -> 배포의 연결고리를 남겨 결함 원인과 영향 범위를 신속하게 파악한다. 
• 속도와 안정성의 공존: 브랜치 전략 ·자동화 빌드 ·표준화된 배포 절차로 릴리즈 빈도는 높이고 실패율은 낮추는 운영을 가능하게 한다.
• 규정 ·감사 대응: 금융/공공/의료 등 규제 산업에서 변경 승인 ·이력 ·감사 로그가 필수이다.
• 보안 ·리스크 관리: 서드파티 라이브러리, 비밀정보(Secrets), 취약점(SBOM/스캔)까지 형상 경계 내로 끌어와 통제한다.
• 조직 스케일링: 다팀 ·다면 모듈 협업에서 충돌 ·중복 ·환경 드리프트를 줄이고 온보딩 시간을 단축한다.
• 비용 절감: 재현 가능한 빌드/테스트로 장애 MTTR 단축, 회귀 결함 ·야근 ·긴급 패치 등의 비용을 줄인다.

 

---

📌 기본 개념(핵심 용어와 운영 원칙)

• CI(구성항목) 식별: 관리 범위를 명문화한다. (예: app, infra, runbook, policies)
• 버전/릴리스/태그: 코드 ·문서 ·아티팩트를 불변 태그로 묶어 특정 시점을 재현한다. (예: v1.8.2)
• 베이스라인(Baseline): 승인된 기준 상태. 이후 변경은 Change Request(CR)로만 허용한다.
• 변경통제(Change Control): 요청 -> 영향분석 -> 승인 -> 반영 -> 검증의 워크플로, 승인 없이 직접 배포 금지.
• 브랜치 전략: 
  • Trunk-Based: 짧은 라이프의 피처 브랜치 + 강한 게이트(리뷰/테스트)
  • GitFlow: 다중 릴리스 ·규제 환경에 적합 (단, 복잡성↑)
• 빌드 재현성(Reproducible Build): 의존성 잠금(lockfile), 컨테이너화, 동일한 CI 이미지로 환경 불일치 제거.
• 환경 표준화: dev/stage/prod의 동형성(parity) 확보. laC(Terraform/Helm)로 환경 자체를 버전관리.
• 형상 감사/Audit: 누가 ·언제 ·왜 ·무엇을 바꿨는지, 승인자는 누구인지 로그로 증명
• 추적성 매트릭스: 요구사항 <> 코드 커밋 <> 테스트 케이스 <> 결과 <> 배포 태그를 일대일/일대다로 연결
• 릴리스 거버넌스: 릴리스 노트, 롤백 계획, 릴리스 캘린더(동결 기간), 정책 위반 차단(Git hook/PR 규칙)
• 운영 지표(DORA 4): 변경 리드타임, 배포 빈도, 변경 실패율, MTTR을 정례 측정하여 지속 개선
• 실무예시
  • JIRA 이슈 pay-451 승인 -> PR에 이슈 링크 의무화 -> 머지 시 CI가 보안/품질 게이트 통과 확인 -> 태그 v.2.3.0 발행 -> CD가 스테이지 배포 후 승인 워크플로 통해 운영 반영 -> 릴리스 노트 자동 생성

아티팩트(Artifact)
: 빌드 과정을 거쳐 나온 결과물
- 예시: .jar, .war, .exe, Docker 이미지, 모바일 앱 패키지(.apk, .ipa), 문서, 설정파일 등 
- 특징: 코드와 달리 실행 가능한 '완성품'으로 보통 아티팩트 저장소(Nexus, Arifacort, GitHub Packages)에 저장하며 재현성과 배포를 위해 반드시 버전 태그와 함께 관리한다.

거버넌스
: 조직 내 규칙·정책·프로세스를 수립·운영하는 체계로 속와 품질의 균형을 목적으로 한다.
- IT 거버넌스는 흔히 개발, 보안, 품질, 변경관리를 모두 아우른다. 
-예시: 
 > 브랜치 전략(GitFlos/ Trunk-based)
 > 리뷰어 2인 이상 승인 의무화
 > 보안 스캔 통과하지 않으면 머지 불가
 > 배포 동결 기간(Freeze Window)설정

 

 

---

🛠️ 시스템의 종류(도구 지형도)

형상관리는 '한 개의 툴'이 아니라 역할별 도구들의 느슨한 결합이다. 조직 규모 ·규제 수준에 따라 조합이 달라진다. 

• 소스코드 버전관리(SCM)
  • Git (GitCub, GitLab, Bitbucket), SVN
  • 브랜칭 ·코드리뷰 ·PR 규칙 ·보호 브랜치로 품질 게이트 구성
• 아티팩트/패키지 저장소
  • Nexus, JFrog Artifactory, GitHub Packages
  • 빌드 산출물(WAR/JAR/컨테이너 이미지), 내부 패키지(NPM/PyPI) 보관·서명·보존 정책
• CI/CD 오케스트레이션
  • Jenkins, GitLab CI/CD, GitHub Actions, Azure DevOps Pipelines
  • 빌드 재현성, 단계적 배포(블루/그린, 카나리), 보안 스캔, SBOM 생성

CI/CD
* CI(Continuous Integration, 지속적 통합)
 > 개발자가 코드를 push 하면 -> 자동으로 빌드/테스트 실행
 > 코드 품질과 안정성을 보장하고 조기 결함 발견

* CD(Continuous Delivery/Deployment, 지속적 제공/배포)
 > Delivery: 빌드, 테스트 통과 시 운영 배포 준비 자동화(최종 승인 필요)
 > Deployment: 승인 절차 없이 운영에 자동 배포 

*툴: Jenkins, GitLab CI/CD, GitHub Actions, Azure DevOps 등
👉 CI는 코드 품질, CD는 빠른 배포에 초점.

• 요구사항 ·이슈 ·문서 관리(ALM)
  • Jira/Confluence, Azure Boards, Redmine, Polarion
  • 요구사항–테스트–코드–배포 추적 체인의 중심 축
• 인프라 형상/구성 관리
  • Terraform, Pulumi (IaC) / Ansible, Chef, Puppet, Salt (구성 자동화)
  • Helm, Kustomize (쿠버네티스 앱 형상) → 환경 자체를 버전관리
• ITSM/변경관리(변경 승인 거버넌스)
  • ServiceNow Change, Jira Service Management
  • 변경 승인·위험평가·감사 대응(특히 규제 산업)
• 엔터프라이즈 통합형(감리 ·보안 중심)
  • Azure DevOps Server/Cloud, IBM ELM, Siemens Polarion, eCAMS 등
  • 소스·문서·빌드·배포·결재를 한 체계에서 관리

---

📋체크리스트

• SSOT: “진실의 단일 소스”를 정하고 나머지는 링크만 둔다.
• PR 게이트: 필수 리뷰어, 테스트·스캔·커버리지·정적분석을 자동 차단 규칙으로.
• 명명 규칙: 브랜치/태그/커밋 메시지 표준(이슈 키 포함) 문서화.
• 릴리스 규율: 동결 기간·롤백 플레이북·릴리스 노트 자동화.
• 보안 내재화: 시크릿 관리(Vault), SBOM, 취약점 SLA.
• 지표 경영: DORA 4 주간 리뷰, 병목 지점(리뷰 대기·승인 지연) 해소.

SSOT (Single Source of Truth)
-진실의 단일 소스
-데이터/정보가 여러 시스템에 흩어져 있지 않고 단일 기준점을 통해 관리되는 상태
-예시
 > 요구사항 관리: JIRA
 > 소스코드: Git
 > 문서: Confluence
 > 운영 지표: Datadog
-중요한 건 '각 영영마다 한 곳만 진짜'를 정해 두는 것 
👉 SSOT는 정보 혼선을 막고, 감사/감리 대응에도 핵심

PR 게이트(Pull Request Gate)
-PR(Pull Request) 병합 전에 자동으로 통과해야 하는 품질 게이트
-체크 항목 예시
 > 빌드 성공 여부 
 > 테스트 통과율 ≥ 90%
 > 보안 스캘 결과 (CVE 없음)
 > 코드 리뷰 2인 이상 승인
- GitHub, GitLab, Azure DevOps 등에서 Branch Protection Rule로 설정 가능
👉  개발자가 “실수로” 품질 기준을 깨뜨리지 못하도록 자동 방어선 구축.

SBOM (Software Bill of Materials)
-소프트웨어 자재명세서
-애플리케이션을 구성하는 라이브러리, 프레임워크, 의존성 목록을 기록한 문서
-필요성
 > 오픈소스 보안 취약점(CVE) 추적
 > 라이선스 컴플라이언스 (GPL, Apache, MIT 등)
 > 공급망 보안 대응 
-표준: SPDX, CycloneDX
👉 최근 보안 이슈(예: Log4j)로 인해 기업·정부에서 의무화 되는 추세.

SLA (Service Level Agreement)
-서비스 수준 협약: 서비스 제공자와 고객 간에 합의한 품질·가용성 기준
-주요 지표
 > 가용성(Availability): 99.9% (월 43분 다운타임 허용)
 > 응답시간(Response Time): 평균 200ms 이하
 > 지원 대응시간: P1 이슈는 30분 내 대응
-SLA 위반 시 보상(크레딧 제공 등)도 명시
👉 SLA는 “고객과 회사 간 서비스 품질 계약서”.

DORA 지표
-DevOps Research and Assessment에서 제시한 4대 핵심 지표
-팀 생산성과 소프트웨어 전달 성숙도를 측정하는 국제 표준
 > 배포 빈도(Deployment Frequency): 얼마나 자주 배포하는가
 > 변경 리드타임(Lead Time for Change) 코드 커밋 → 운영 반영까지 걸린 시간
 > 변경 실패율(Change Failure Rate) 배포 후 장애/롤백 발생 비율
 > 평균 복구 시간(MTTR: Mean Time To Restore) 장애 발생 → 정상 복구까지 걸린 시간
👉 DORA 지표는 속도+안정성을 동시에 평가하는 균형 척도. 세계적 하이퍼스케일러(구글, 넷플릭스 등)는 이 지표로 DevOps 성숙도를 관리한다.