형상관리와 빌드·배포

🗂️ 형상관리의 개념과 중요성

이 섹션에서는 소프트웨어 형상관리(SCM)의 개념과 형상 항목 분류를 살펴보겠습니다.

형상관리(Software Configuration Management, SCM)는 소프트웨어 개발 과정에서 생성되는 모든 산출물의 변경을 체계적으로 관리하는 활동입니다. 단순히 소스코드만이 아니라 설계 문서, 테스트 케이스, 실행 파일, 데이터 등 모든 산출물이 관리 대상입니다.

형상관리의 4가지 핵심 활동은 다음과 같습니다. 형상 식별(Configuration Identification) — 관리 대상 항목을 식별하고 이름과 번호를 부여합니다. 형상 통제(Configuration Control) — 변경 요청을 검토하고 승인하는 절차를 관리합니다. 형상 상태 보고(Status Accounting) — 형상 항목의 현재 상태를 기록하고 보고합니다. 형상 감사(Configuration Audit) — 형상 항목이 올바르게 관리되고 있는지 검토합니다.

베이스라인(Baseline)은 공식적으로 검토·승인된 형상으로, 이후 변경은 공식 절차를 거쳐야 합니다. 기능 기준선(Functional Baseline), 할당 기준선(Allocated Baseline), 제품 기준선(Product Baseline) 세 종류가 있습니다.

기출 함정: "형상관리는 소스코드만 관리한다" → 틀림. 설계 문서, 테스트 케이스 등 모든 산출물을 관리합니다. "베이스라인은 자유롭게 변경할 수 있다" → 틀림. 공식 절차(CCB 승인)를 거쳐야 합니다.

🔀 버전 관리 시스템 비교 — Git vs SVN vs CVS

이 섹션에서는 대표적인 버전 관리 시스템 세 가지를 비교하고 각각의 특성을 살펴보겠습니다.

구분	CVS	SVN	Git
저장 방식	중앙 집중식	중앙 집중식	분산형
저장소	중앙 서버 1개	중앙 서버 1개	로컬+원격
브랜치	어렵고 느림	디렉터리 기반	가볍고 빠름
변경 단위	파일 단위	커밋 단위	커밋 단위
오프라인 작업	불가	제한적	가능
병합 충돌	자주 발생	줄어듦	최소화

Git의 핵심 명령어 흐름은 작업 디렉터리 → (git add) → 스테이징 영역 → (git commit) → 로컬 저장소 → (git push) → 원격 저장소입니다. 암기법: "작스로원 — 작업·스테이징·로컬·원격" 4단계를 순서대로 기억합니다.

🌿 Git Flow — 5개 브랜치 전략

이 섹션에서는 Vincent Driessen이 제안한 Git Flow 브랜치 전략과 각 브랜치의 역할을 살펴보겠습니다.

Git Flow는 소프트웨어 릴리즈 주기가 명확한 프로젝트에 적합한 브랜치 전략입니다. 5개의 브랜치로 구성됩니다.

브랜치	역할	분기 원점	병합 대상
main(master)	프로덕션 배포 코드	—	—
develop	다음 릴리즈 통합 브랜치	main	—
feature	새 기능 개발	develop	develop
release	릴리즈 준비(버그 수정)	develop	main + develop
hotfix	프로덕션 긴급 버그 수정	main	main + develop

기출 함정: "hotfix 브랜치는 develop에서 분기한다" → 틀림. hotfix는 main에서 분기하여 긴급 수정 후 main과 develop 모두에 병합합니다. "feature 브랜치는 main에 직접 병합한다" → 틀림. feature는 develop에 병합합니다.

암기법: "메인·디벨·피처·릴리즈·핫픽스(M·D·F·R·H)" — 핫픽스만 메인에서 직접 분기하는 특별한 브랜치입니다.

🔨 빌드 도구 비교 — Maven·Gradle·Ant

이 섹션에서는 Java 생태계의 대표적인 빌드 도구 세 가지를 비교하고 기출 포인트를 살펴보겠습니다.

구분	Ant	Maven	Gradle
등장 시기	2000년	2004년	2012년
설정 파일	build.xml	pom.xml	build.gradle
설정 언어	XML	XML	Groovy/Kotlin DSL
의존성 관리	직접 관리	중앙 저장소	중앙 저장소
빌드 속도	보통	보통	빠름(증분 빌드)
표준 디렉터리	없음	있음(Convention)	있음(Convention)

Maven의 POM(Project Object Model)은 프로젝트 구조를 XML로 정의하며 Convention over Configuration 원칙을 따릅니다. 표준 디렉터리 구조를 강제하여 프로젝트 구조를 통일합니다. Gradle은 Maven보다 빠른 증분 빌드(Incremental Build)와 빌드 캐시를 지원합니다.

🚀 CI/CD 파이프라인과 Docker

이 섹션에서는 현대 소프트웨어 개발의 핵심인 CI/CD 파이프라인과 컨테이너 기술을 살펴보겠습니다.

CI(Continuous Integration, 지속적 통합)는 개발자가 코드를 공유 저장소에 자주 통합하고, 통합 시마다 자동으로 빌드와 테스트를 실행하는 방식입니다. 통합 지점을 자주 만들어 "통합 지옥(Integration Hell)"을 방지합니다.

CD(Continuous Delivery/Deployment, 지속적 제공/배포)에서 지속적 제공은 릴리즈 가능한 상태를 항상 유지하되 수동 승인 후 배포하는 것이고, 지속적 배포는 승인 없이 자동으로 프로덕션에 배포하는 것입니다.

CI/CD 파이프라인 단계: 코드 커밋 → 빌드(Build) → 단위 테스트 → 패키지(Package) → 통합 테스트 → 스테이징 배포 → 인수 테스트 → 프로덕션 배포

구분	Docker 컨테이너	가상 머신(VM)
가상화 단위	프로세스	OS 전체
기동 시간	초 단위	분 단위
크기	MB 단위	GB 단위
격리 수준	프로세스 수준	완전 격리
OS 공유	호스트 OS 커널 공유	각자 독립 OS

시맨틱 버전(Semantic Versioning)은 MAJOR.MINOR.PATCH 형식입니다. MAJOR는 하위 호환 불가 변경, MINOR는 하위 호환 기능 추가, PATCH는 하위 호환 버그 수정입니다. 예: 2.1.3에서 MAJOR=2, MINOR=1, PATCH=3.

기출 함정: "CI는 배포까지 자동화한다" → 틀림. CI는 빌드와 테스트까지입니다. "컨테이너는 VM보다 격리 수준이 높다" → 틀림. VM이 더 강한 격리를 제공합니다. "시맨틱 버전에서 MINOR 업그레이드는 하위 호환을 깨뜨린다" → 틀림. MAJOR만 하위 호환을 깨뜨립니다.

📌 9강 핵심 요약과 10강 예고

이 섹션에서는 9강 핵심 내용을 압축 정리합니다.

형상관리 4활동: 식별·통제·보고·감사. Git vs SVN: Git은 분산형, 오프라인 작업 가능. Git Flow 5브랜치: main·develop·feature·release·hotfix, hotfix만 main에서 직접 분기.

빌드 도구: Ant(build.xml)·Maven(pom.xml)·Gradle(build.gradle), Gradle이 가장 빠름. CI/CD: CI=빌드+테스트 자동화, CD=배포 자동화(제공 vs 배포 구분). Docker=컨테이너(경량), VM=완전격리(무거움). 시맨틱 버전: MAJOR.MINOR.PATCH.

다음 10강에서는 성능 최적화와 시큐어 코딩 — 성능 4지표, OWASP Top 10, SQL 인젝션·XSS·CSRF 방어 원리를 완벽히 정리합니다.