콘텐츠로 바로가기
HY_TECH_BASE

DevOps, CI & CD Automation Dynamics

개발과 운영의 경계를 허물고 자동화된 빌드, 테스트, 배포 파이프라인을 통해 소프트웨어 공급 속도와 신뢰성을 극대화하는 DevOps 문화와 엔지니어링 실무를 다루는 학습 노드입니다.

sys.entry
M

Me

hyunyoun's Blog

posts6 min read

1. Overview

DevOps, CI 및 CD 자동화 역학(DevOps, CI & CD Automation Dynamics, DCD)은 현대 소프트웨어 개발에서 '더 자주, 더 안전하게' 배포하기 위한 기술적/문화적 토대를 다룹니다.

과거의 개발과 운영은 단절된 칸막이(Silo) 속에 존재하여 배포 사고와 지연의 원인이 되었습니다. 학습자는 개발자가 코드를 커밋하는 순간부터 사용자에게 도달하기까지의 과정을 자동화하는 지속적 통합(CI)과 지속적 배포(CD) 파이프라인의 물리적 구조를 배웁니다. 또한, 서버 설정을 코드로 관리하는 IaC(Infrastructure as Code)를 통해 인프라의 가변성(Configuration Drift)을 제거하고, 개발 조직 전체의 생산성 선순환 구조를 구축하는 역량을 갖춥니다.

2. Scope & Boundaries

In-Scope

  • CI Principles: 빌드 자동화, 코드 정적 분석(Linting), 자동화 테스트 통합 물리
  • CD Strategies: 블루/그린 배포, 카나리(Canary) 릴리즈, 롤백(Rollback) 가용성 물리
  • Infrastructure as Code: 선언적 구성(Declarative), 불변 인프라(Immutable Infrastructure)
  • DevOps Culture: CALMS 모델(Culture, Automation, Lean, Measurement, Sharing)

Out-of-Scope

  • 상세한 쿠버네티스 리소스 최적화 (07-07 Cloud-Native 영역으로 위임)
  • 데이터베이스 백업 및 아카이빙 물리 (06-04 Governance 영역으로 위임)

Boundaries

  • DCD vs. SRE: DCD가 '생산 및 전달 파이프라인의 자동화'에 집중한다면, 09-04(SRE)는 '배포된 서비스의 안정적인 운영 상태 유지'에 더 큰 비중을 둡니다.

3. Counterexample

  • 단순히 Jenkins나 GitHub Actions의 문법을 익히는 것은 DCD 학습이 아닙니다. 왜 배포 단위를 잘게 나누어야(Micro-batch) 장애 발생 시 **평균 복구 시간(MTTR)**이 물리적으로 줄어드는지 설명하고, 왜 '환경 간 설정 차이'가 배포 무결성을 훼손하는지 IaC의 관점에서 논리적으로 입증할 수 있어야 합니다.

4. Prerequisites

  • 엔지니어링 라이프사이클 (Basic): 소프트웨어 개발 프로세스 전반에 대한 이해가 필요합니다. (09. ELM)
  • 테스트 및 QA 메커니즘 (Recommended): CI 파이프라인의 핵심인 자동화 테스트 기초가 권장됩니다. (09. TQA)

5. Learning Map

  1. Breaking Silos: 개발과 운영이 왜 협력해야 하는지 문화적/물리적 필연성을 이해합니다.
  2. The Pipeline: 코드 한 줄이 서버에 반영되는 자동화된 컨베이어 벨트(CI/CD)를 설계합니다.
  3. Hardware as Code: 마우스 클릭이 아닌 코드로 서버를 생성하고 관리하는 일관성을 배웁니다.
  4. Fast Feedback: 배포 결과를 즉각 확인하여 실패 비용을 최소화하는 피드백 루프를 탐구합니다.

6. Learning Topics

Basic

Core: DevOps 문화와 CI 기초 (DevOps & CI Basics)

  • Why to Learn: 개발 주기 전체의 병목을 제거하고 팀의 릴리스 속도를 높이기 위함입니다.
  • What to Learn:
    • DevOps의 정의와 3가지 길(흐름, 피드백, 지속적 학습)
    • 지속적 통합(CI)의 필수 요건: 버전 관리, 자동 빌드, 셀프 테스팅
    • 빌드 서버와 에이전트의 논리적 통신 흐름
  • How to Learn:
    • GitHub Actions와 같은 도구를 이용해 코드를 올리면 자동으로 'Hello World'가 빌드되는 환경 구축
    • 코드 커밋 메시지 규칙(Conventional Commits)이 자동화 도구와 연동되는 과정을 실습
  • Implement: 현재 팀/개인 프로젝트의 수동 배포 단계를 분석하고 자동화할 지점을 표시한 개선도

Core: 지속적 배포 및 전략 (CD Strategies)

  • Why to Learn: 배포 시 발생하는 서비스 중단(Downtime)을 없애고 위험을 분산하기 위해서입니다.
  • What to Learn:
    • 지속적 인도(Delivery) vs 지속적 배포(Deployment)의 차이
    • Blue/Green 배포: 구 버전과 신 버전의 물리적 병렬 교체 역학
    • Canary 배포: 트래픽의 일부만 신 버전으로 흘려보내 영향도 검증 논리
  • How to Learn:
    • 로드 밸런서 설정을 변경하며 두 버전의 서버로 트래픽이 분산되는 과정을 시뮬레이션
    • 배포가 실패했을 때 즉각적으로 이전 버전으로 돌아가는 롤백(Rollback) 절차 문서화 실습
  • Implement: 고가용성 보장을 위한 무중단 배포 시나리오 및 아키텍처 설계

Practical

Core: 코드형 인프라 (Infrastructure as Code)

  • Why to Learn: 인프라 설정을 동일하게 복제하여 환경 불일치로 인한 오류를 물리적으로 방지하기 위함입니다.
  • What to Learn:
    • IaC의 핵심 가치: 선언적(Declarative) vs 명령적(Imperative) 접근
    • 인프라 가변(Configuration Drift) 방지와 불변성(Immutability) 확보
    • 대표 도구(Terraform, CloudFormation 등)의 상태 관리(State) 물리
  • How to Learn:
    • Terraform 코드를 작성하여 클라우드 리소스를 생성하고, 코드를 수정하여 실제 반영되는 변경분(Plan) 분석
    • 생성된 자원을 수동으로 변경했을 때 코드가 이를 감지(Drift)하는 현상 확인
  • Implement: 공통 개발 환경을 1분 만에 프로비저닝할 수 있는 IaC 템플릿 코드

Advanced

Core: 데브섹옵스 및 플랫폼 엔지니어링 (Advanced DevOps)

  • Why to Learn: 대규모 조직에서 보안 가드레일을 유지하며 개발 자율성을 극대화하기 위해서입니다.
  • What to Learn:
    • DevSecOps: CI 파이프라인 내에서의 취약점 스캐닝(SAST/DAST) 통합
    • 플랫폼 엔지니어링: 개발자에게 'Self-service' 인프라를 제공하는 내부 포털 물리
    • GitOps: Git 저장소를 인프라 상태의 SSOT로 삼는 동기화 논리
  • How to Learn:
    • 빌드 파이프라인에 보안 체크 단계를 추가하여 취약한 버전의 배포를 물리적으로 차단하는 실습
    • ArgoCD와 같은 도구를 활용하여 Git의 코드 상태와 서버의 실제 상태가 일치하도록 강제하는 환경 구축
  • Implement: 조직 내 플랫폼 엔지니어링 도입을 위한 개발자 셀프서비스 요건 정의서

7. Terminology

Term (EN / ko, abbr) 1문장 정의 단계(기본/권장/실무/심화) 역할/맥락 관련 개념 유사/대비/함께 사용 오해 포인트 Evidence(Primary/Secondary/Industry) Flags(core)
CI (지속적 통합) 개발자의 코드 변경 사항을 중앙 저장소에 수시로 통합하고 자동 빌드 및 테스트를 수행하는 물리입니다. 기본 개발 가속 Version Control CD 단순히 '빌드 툴'로 오해 P2:SWEBOK core
Pipeline 코드가 릴리스되기 위해 거쳐야 하는 일련의 자동화된 단계(Build, Test, Deploy)의 물리적 연결입니다. 기본 자동화 흐름 Workflow Step 단순히 '선형 구조'로 오해 Industry Patterns core
Configuration Drift 서버의 실제 상태가 IaC 코드로 관리되는 정의서에서 벗어나 개별적으로 변하는 물리적 현상입니다. 추천 위험 관리 IaC Immutability 단순히 '설정 오류'와 혼동 Industry Docs core
Canary Deployment 전체 트래픽 중 극소수에게만 신규 버전을 노출하여 위험을 초기에 감지하는 점진적 배포 물리입니다. 실무 위험 완화 Blue/Green Blast Radius 단순히 '베타 테스트'로 오해 Industry core

8. References

Primary References

Secondary References

  • [The Phoenix Project] Gene Kim — The definitive DevOps culture book.
  • [Continuous Delivery] Jez Humble & David Farley — Technical foundation for DCD.

Industry References

  • [Google - State of DevOps Report (DORA)] — Industry performance metrics.
  • [Infrastructure as Code] Kief Morris — Comprehensive IaC guide.

9. Final Checklist

Primary Checklist

  • DevOps의 릴리스 주기 개선이 소프트웨어의 전체적인 품질(버그 발생률 저하)에 기여하는 물리적 이유를 기술할 수 있는가? (P2)
  • 형상 관리(SCM) 시스템이 CI/CD 파이프라인의 시작점으로서 담당하는 데이터 무결성 보장 역할을 설명 가능한가? (P2)

Secondary Checklist

  • 빌드 파이프라인의 특정 단계에서 실패했을 때, 원인을 분석하여 10분 내에 복구하거나 배포를 중단시키는 판단을 내릴 수 있는가?
  • IaC 코드를 통해 동일한 아키텍처를 테스트 환경과 운영 환경에 '오차 없이' 배포할 수 있는 재현성을 갖추었는가?

Industry Checklist

  • DORA 메트릭(Deployment Frequency, Lead Time 등)을 통해 본인 조직의 배포 성숙도를 정량적으로 진단할 수 있는가? (SFIA)
  • 프로덕션 배포 시 트래픽 전환율과 모니터링 지표를 연동하여 이상 징후 발생 시 자동 롤백을 수행하는 파이프라인을 설계 가능한가?

Concepts & Tags

#devops-culture#ci-cd-pipeline#infrastructure-as-code#continuous-delivery