레슨 13: DevOps와 CI/CD¶

이전: 프로세스 개선 | 다음: 기술 문서화

DevOps는 지난 10년간 소프트웨어 팀이 소프트웨어를 구축하고 납품하는 방식을 변화시켰다. 그러나 DevOps는 도구도, 제품도, 직함도 아니다 — 소프트웨어 개발과 IT 운영 사이의 전통적인 장벽을 허무는 문화와 실천의 집합이다. 이 레슨에서는 DevOps의 진정한 의미, 지속적 통합(Continuous Integration)과 지속적 납품(Continuous Delivery) 뒤에 있는 원칙, 그리고 성숙한 엔지니어링 조직이 납품 프로세스의 속도와 신뢰성을 어떻게 측정하고 개선하는지 탐구한다.

난이도: ⭐⭐⭐

선수 학습: - 형상 관리 — 브랜칭 전략, 버전 관리 워크플로우 - 프로세스 개선 — 메트릭, 회고, 개선 사이클 - 빌드 시스템과 자동화 테스트 개념에 대한 기본 이해

학습 목표: - DevOps가 무엇인지 설명하고 전통적인 운영 및 SRE와 구별한다 - CALMS 프레임워크와 문화가 DevOps의 기반인 이유를 설명한다 - 의미 있는 단계와 품질 게이트가 있는 CI 파이프라인을 설계한다 - 지속적 납품(Continuous Delivery)과 지속적 배포(Continuous Deployment)를 구별한다 - 배포 전략을 비교한다: 롤링, 블루-그린, 카나리, 피처 플래그 - 관찰 가능성의 세 가지 기둥과 그 중요성을 설명한다 - DORA의 4가지 메트릭을 정의하고 팀 건강에 대해 무엇을 드러내는지 해석한다 - 무결점 사후 검토(blameless postmortems)와 심리적 안전이 학습을 가능하게 하는 이유를 설명한다

1. DevOps란 무엇인가?¶

DevOps는 2008–2009년경 개발 팀과 운영 팀 사이의 만성적인 기능 장애에 대한 좌절에서 탄생했다. 개발자들은 새로운 기능을 빠르게 출시하도록 유인을 받았고, 운영 팀은 운영 환경을 안정적으로 유지하도록 유인을 받았다. 이 상반된 유인이 장벽을 만들었다 — 기능들은 배포를 기다리며 쌓였고, 사고들은 "나쁜 코드" 또는 "운영 실수"로 탓해졌으며, 아무도 전체 납품 파이프라인을 소유하지 않았다.

DevOps는 개발 및 운영 엔지니어가 설계 및 개발부터 배포 및 운영 지원까지 전체 서비스 생명주기에 걸쳐 함께 작업하는 실천이다 — 린 제조와 시스템 사고의 원칙을 소프트웨어 납품에 적용하면서.

이 용어는 Patrick Debois와 Andrew Shafer에 의해 대중화되었으며, "State of DevOps" 연구(2013년 Puppet Labs에서 시작, 이후 DORA가 계속)는 DevOps 실천이 상당히 더 나은 조직 성과와 상관관계가 있다는 첫 번째 엄격한 증거를 제공했다.

DevOps vs. 전통적 운영¶

차원	전통적 방식	DevOps
팀 구조	개발과 운영이 별도의 사일로	공유 책임, 교차 기능 팀
배포	대량 배치, 드물고, 고위험	소규모, 자주, 점진적
변경 승인	변경 자문 위원회, 수 주의 리드 타임	자동화된 게이트, 수 분에서 수 시간
사고 대응	비난 찾기, 에스컬레이션	무결점 사후 검토, 공유 온콜
피드백 루프	릴리스 후 버그 발견, 느린 피드백	모니터링, 경보, 빠른 복구
지식	운영이 운영 환경을 "소유"; 개발은 접근 없음	개발자가 자신의 서비스를 이해하고 운영할 수 있음

DevOps vs. SRE¶

사이트 신뢰성 엔지니어링(SRE, Site Reliability Engineering)은 구글의 DevOps 원칙 구현이다. DevOps가 철학을 설명한다면, SRE는 직무 기능과 실천의 집합을 설명한다.

SRE는 구체적인 메커니즘을 도입한다: - 서비스 수준 목표(SLO, Service Level Objectives): 정량화된 신뢰성 목표 (예: 99.9% 가용성) - 오류 예산(Error budgets): 허용 가능한 다운타임 — 소진되면 신뢰성이 개선될 때까지 기능 작업 중단 - 수고 감소(Toil reduction): SRE는 반복적인 수동 작업을 자동화로 제거해야 함 - 사후 검토(Postmortems): 사고로부터의 구조화된 학습

관계: "SRE는 소프트웨어 엔지니어에게 운영 기능을 설계하도록 요청했을 때 얻는 것이다." DevOps는 더 넓은 문화적 운동이고, SRE는 이를 구현하는 하나의 엄격한 방법이다.

2. CALMS 프레임워크¶

CALMS는 DevOps를 이해하기 위해 가장 널리 사용되는 프레임워크다. 각 글자는 조직 역량의 한 차원을 나타낸다.

C — 문화(Culture)¶

문화는 기반이다. 이것 없이는 어떤 도구도 실패한다. DevOps 문화는: - 공유 소유권(Shared ownership): 개발자와 운영 모두 신뢰성과 배포 성공을 소유한다 - 비난 없는 환경(Blame-free environment): 실패는 사람을 처벌하는 것이 아니라 시스템을 개선할 기회다 - 투명성(Transparency): 메트릭, 사고, 결정이 팀 전체에 가시적이다 - 고객 집중(Customer focus): 궁극적인 척도는 사용자에게 전달된 가치다

문화적 전환이 가장 어렵다. 리더십의 지원, 신뢰 구축, 그리고 종종 조직 개편이 필요하다. 많은 "DevOps 전환"이 도구 선택이 아니라 기저의 문화가 바뀌지 않았기 때문에 실패한다.

A — 자동화(Automation)¶

자동화는 납품 파이프라인에서 수동적이고 오류가 발생하기 쉬운 단계를 제거한다: - 코드 빌드 및 컴파일 - 모든 수준에서의 테스트 실행 - 인프라 프로비저닝 - 모든 환경에 배포 - 형상 관리 - 보안 스캔

자동화의 목표는 단순히 속도가 아니라 일관성과 재현성이다. 90%의 시간에만 작동하는 수동 프로세스는 신뢰성 문제다.

L — 린(Lean)¶

제조업의 린 원칙이 소프트웨어 납품에 직접 적용된다: - 낭비 제거(Eliminate waste): 불필요한 승인 단계, 환경 대기, 수동 인계 - 피드백 증폭(Amplify feedback): 문제를 빠르게 가시화하여 수정할 수 있도록 - 소규모 배치(Small batch sizes): 위험을 줄이고 피드백을 가속화하기 위해 더 자주 더 작은 변경 배포 - 흐름(Flow): 개별 단계가 아닌 전체 시스템의 처리량 최적화

린에서의 핵심 통찰: 배포 후 발견된 결함은 코드 검토에서 잡힌 것보다 수정하는 데 10배, 좋은 설계로 예방한 것보다 100배 더 비용이 든다.

M — 측정(Measurement)¶

측정할 수 없는 것은 개선할 수 없다. DevOps 팀은 모든 것을 계측한다: - 배포 빈도와 리드 타임 - 시스템 건강: 오류율, 지연, 포화 - 파이프라인 건강: 빌드 성공률, 테스트 커버리지 추세 - 비즈니스 결과: 전환율, 사용자 참여

측정에는 도구(모니터링, APM, 로깅)가 필요하지만, 더 중요한 것은 데이터를 기반으로 결정을 내리고 실패 데이터를 숨기지 않고 배우는 문화다.

지식 사일로는 DevOps의 적이다. 공유란: - 전체 조직에 공개된 사후 검토 - 모든 사람이 접근 가능한 런북(runbook)과 플레이북(playbook) - 시스템이 특정 방식으로 구축된 이유를 설명하는 아키텍처 결정 기록(Architecture Decision Records) - 내부 기술 강연, 실천 공동체, 멘토링 - 가능하면 오픈 소스에 기여

3. 지속적 통합(Continuous Integration)¶

지속적 통합(CI, Continuous Integration)은 코드 변경을 자주 — 이상적으로는 하루에 여러 번 — 공유 저장소에 통합하고, 자동화된 빌드 및 테스트 스위트로 각 통합을 검증하는 실천이다.

CI가 해결하는 문제¶

CI 이전에는 팀이 수 주 또는 수 개월 동안 별도의 브랜치에서 작업한 다음 릴리스 전에 모든 것을 합치려는 시도가 일반적이었다. 결과는 통합 지옥(integration hell)이었다: 대규모 충돌, 깨진 테스트, 며칠간의 디버깅. Martin Fowler와 Kent Beck은 이 문제를 직접 해결하기 위해 익스트림 프로그래밍(Extreme Programming)의 일환으로 CI를 대중화했다.

CI 원칙¶

단일 소스 저장소 유지: 모든 코드가 하나의 메인 브랜치에 있거나 자주 병합됨
빌드 자동화: 누구든 코드를 체크아웃하고 단일 명령으로 빌드할 수 있어야 함
빌드를 자체 테스트로: 빌드가 테스트를 실행하고, 빌드 통과는 코드가 올바름을 의미함
모든 커밋이 빌드를 트리거: 파이프라인이 모든 푸시에서 자동으로 실행됨
깨진 빌드 즉시 수정: 깨진 메인 브랜치는 최우선 순위 — "나중에 고칠게"가 아님
빌드를 빠르게 유지: 45분이 걸리는 CI 파이프라인은 나쁜 피드백을 제공 — 핵심 파이프라인은 10분 미만 목표
운영과 유사한 환경에서 테스트: 테스트와 운영 환경 간의 차이가 위험을 도입함
결과를 가시적으로: 빌드 상태를 보여주는 대시보드는 팀 건강 지표임

CI 파이프라인 단계¶

일반적인 CI 파이프라인은 증가하는 깊이와 비용의 단계를 거친다:

[커밋(Commit)]
   │
   ▼
[체크아웃 & 컴파일]          ~30초
   │  구문 오류, 누락된 의존성
   ▼
[단위 테스트(Unit Tests)]    ~2–5분
   │  빠르고, 격리되고, 높은 커버리지
   ▼
[정적 분석 & 린팅]           ~1–2분
   │  코드 스타일, 복잡도, 보안 패턴 (SAST)
   ▼
[통합 테스트(Integration Tests)] ~5–10분
   │  컴포넌트 경계 간 테스트, 데이터베이스 상호작용
   ▼
[아티팩트 빌드(Build Artifact)] ~1–3분
   │  Docker 이미지, JAR, 바이너리, 패키지
   ▼
[보안 스캔(Security Scanning)] ~2–5분
   │  의존성 취약점 (SCA), 컨테이너 이미지 스캔
   ▼
[통과(PASS)] → 아티팩트를 레지스트리에 저장
[실패(FAIL)] → 빌드 차단, 개발자에게 알림

품질 게이트(Quality gates): 각 단계가 게이트 역할을 한다. 단계 실패는 파이프라인을 중단시키고 깨진 아티팩트가 진행되는 것을 막는다. 이 "빠른 실패(fail fast)" 원칙이 필수적이다 — 문제가 일찍 잡힐수록 수정하는 데 비용이 덜 든다.

CI의 테스트 피라미드¶

테스트 피라미드(Mike Cohn)는 어떤 유형의 테스트를 언제 실행할지 안내한다:

        /\
       /  \
      / E2E \         적고, 느리고, 불안정 — 덜 자주 실행
     /--------\
    / Integration\    적당량 — 모든 커밋에서 실행
   /--------------\
  /   Unit Tests   \  많고, 빠르고, 신뢰할 수 있음 — 모든 커밋에서 실행
 /------------------\

단위 테스트가 피라미드를 지배해야 한다. 밀리초 단위로 실행되고, 외부 의존성이 없으며, 정확한 피드백을 제공한다. 느린 통합 테스트가 너무 많은 파이프라인은 피드백에 너무 오래 걸리기 때문에 무시된다.

4. 지속적 납품(Continuous Delivery) vs. 지속적 배포(Continuous Deployment)¶

이 용어들은 관련이 있지만 구별되며, 그 구별이 중요하다.

지속적 납품(Continuous Delivery)¶

정의: 모든 성공적인 빌드는 언제든지 운영 환경에 배포될 수 있는 아티팩트를 생성한다. 운영 환경으로의 배포는 수동 결정이다.

지속적 납품은 다음을 보장한다: - 소프트웨어는 항상 배포 가능한 상태 - 배포는 저위험의 일상적인 작업 - 비즈니스가 릴리스를 언제 할지 선택할 수 있음 (릴리스가 기술적으로 가능한지만이 아닌)

"기술적으로 릴리스 가능"과 "릴리스하기 위한 비즈니스 결정"의 이 분리는 강력하다. 팀은 사용자에게 준비가 되지 않은 기능을 완성하고, 코드를 메인에 병합된 상태로 유지하다가, 마케팅 팀이 준비되면 릴리스할 수 있다.

지속적 배포(Continuous Deployment)¶

정의: 모든 성공적인 빌드가 인간의 승인 없이 자동으로 운영 환경에 배포된다.

지속적 배포는 다음을 필요로 한다: - 매우 높은 테스트 커버리지와 파이프라인 신뢰 - 배포 후 문제를 잡기 위한 강력한 모니터링 및 경보 - 빠른 롤백 능력 (자동화 또는 원클릭) - 코드 배포에서 기능 가시성을 분리하는 피처 플래그

	지속적 납품(Continuous Delivery)	지속적 배포(Continuous Deployment)
운영 환경으로의 배포	수동 트리거	자동
인간 승인 단계	예 (마지막에)	아니오
위험 허용	중간	높은 신뢰 필요
일반적 사용 사례	엔터프라이즈, 규제 산업	고속 웹 서비스
예시	Netflix (주로), 은행	Flickr (2009년 하루 10+ 배포), 많은 SaaS 기업

대부분의 조직은 지속적 납품을 실천한다; 지속적 배포는 성숙한 CI와 강력한 모니터링 문화를 가진 팀에 적합하다.

5. 배포 전략¶

변경을 어떻게 릴리스하느냐는 릴리스하느냐 만큼이나 중요하다. 다른 전략들은 위험을 다르게 관리한다.

롤링 배포(Rolling Deployment)¶

인스턴스를 하나씩 (또는 소규모 배치로) 업데이트한다. 어느 시점에서나 일부 인스턴스는 이전 버전을, 일부는 새 버전을 실행한다.

이전:    [v1] [v1] [v1] [v1] [v1]
1단계:   [v2] [v1] [v1] [v1] [v1]
2단계:   [v2] [v2] [v1] [v1] [v1]
3단계:   [v2] [v2] [v2] [v1] [v1]
...
이후:    [v2] [v2] [v2] [v2] [v2]

장점: 점진적 출시, 추가 인프라 불필요, 일시 중지 용이. 단점: 동시에 운영 환경에 혼합 버전 존재 (하위 호환성 필요), 다른 전략보다 느림.

블루-그린 배포(Blue-Green Deployment)¶

두 개의 동일한 운영 환경을 유지한다. 모든 트래픽을 "블루"(현재)로 라우팅한다. "그린"(유휴)에 배포한다. 트래픽을 한 번에 전환한다.

         [로드 밸런서]
              │
     ┌────────┴────────┐
     ▼                 ▼
  [블루: v1]       [그린: v2]
  ← 트래픽            유휴

  (전환 후)

  [블루: v1]       [그린: v2]
    유휴            ← 트래픽

장점: 즉각적인 롤백 (블루로 다시 전환), 혼합 버전 없음. 단점: 두 배의 인프라 필요, 데이터베이스 스키마 변경이 까다로움.

카나리 배포(Canary Deployment)¶

트래픽의 소규모 비율을 새 버전으로 라우팅하고, 관찰하다가 점진적으로 증가시킨다.

[로드 밸런서]
      │
  ┌───┴──────────────┐
  ▼ (5%)             ▼ (95%)
[v2: 카나리]      [v1: 안정]

장점: 실제 운영 트래픽이 제한된 노출로 새 버전을 검증; 전체 출시 전에 통계적 신뢰성. 단점: 트래픽 라우팅 능력 필요, 낮은 트래픽 볼륨에서 문제를 감지할 만큼 모니터링이 정밀해야 함.

피처 플래그(Feature Flags)¶

피처 플래그(피처 토글, 피처 게이트라고도 함)는 코드 배포와 기능 가시성을 분리한다. 코드가 비활성화 상태로 운영 환경에 출시되고, 기능은 설정을 통해 특정 사용자, 비율, 또는 지역에 대해 활성화된다.

# 예시: 서버 측 피처 플래그 확인 (의사 코드)
if feature_flags.is_enabled("new_checkout_flow", user=current_user):
    return render_new_checkout()
else:
    return render_old_checkout()

피처 플래그를 통해: - A/B 테스트: 비즈니스 메트릭을 위한 두 버전 비교 - 점진적 출시: 1% → 10% → 50% → 100%로 활성화 - 킬 스위치: 배포 없이 문제 있는 기능을 즉시 비활성화 - 베타 프로그램: 동의한 사용자에게만 활성화

피처 플래그는 신중하게 관리해야 한다: 전체 출시 후 정리되지 않으면 오래된 플래그들이 기술 부채로 쌓인다.

6. 코드로서의 인프라(Infrastructure as Code)¶

코드로서의 인프라(IaC, Infrastructure as Code)는 수동 프로세스나 대화형 도구가 아닌 기계가 읽을 수 있는 설정 파일을 통해 인프라를 관리하고 프로비저닝하는 실천이다.

핵심 원칙¶

멱등성(Idempotency): 같은 설정을 여러 번 적용해도 같은 결과가 나온다. 프로비저닝 스크립트를 두 번 실행해도 중복 리소스가 생성되어서는 안 된다.

버전 관리: 인프라 설정은 애플리케이션 코드와 같은 저장소에 존재한다. 변경은 검토되고, 테스트되고, 감사된다.

선언적 vs. 명령적: - 선언적(Declarative): 원하는 최종 상태를 기술; 도구가 거기에 도달하는 방법을 파악 (Terraform, CloudFormation, Kubernetes 매니페스트) - 명령적(Imperative): 수행할 단계를 기술 (Ansible 플레이북, 셸 스크립트)

현대 IaC는 상태와 멱등성에 대해 추론하기 더 쉽기 때문에 선언적 방향으로 경향이 있다.

인프라 테스트: IaC 설정은 애플리케이션 코드와 마찬가지로 테스트해야 한다 — 모듈 단위 테스트, 테스트 환경에서 실제 인프라를 프로비저닝하는 통합 테스트, 그리고 코드형 정책(policy-as-code) 확인 (예: "S3 버킷은 공개 읽기 불가").

IaC 범주¶

범주	목적	예시
프로비저닝(Provisioning)	인프라 리소스 생성	Terraform, Pulumi, CloudFormation
형상 관리(Configuration management)	기존 서버에서 소프트웨어 구성	Ansible, Chef, Puppet
컨테이너 오케스트레이션(Container orchestration)	컨테이너 워크로드 관리	Kubernetes, Nomad
이미지 빌드(Image building)	재사용 가능한 머신 이미지 생성	Packer, Docker
코드형 정책(Policy as code)	컴플라이언스 규칙 시행	OPA, Sentinel, Checkov

7. 모니터링과 관찰 가능성(Observability)¶

소프트웨어가 배포되면, 올바르게 작동하고 있는지 알아야 한다. 관찰 가능성(Observability)은 외부 출력에서 시스템의 내부 상태를 추론할 수 있는 정도다.

세 가지 기둥¶

메트릭(Metrics)¶

메트릭은 시간에 따라 샘플링된 숫자 측정값이다. 저장 비용이 저렴하고, 집계하기 쉽고, 경보에 적합하다.

범주 (리소스용 USE 방법, 서비스용 RED 방법): - 활용률(Utilization): 리소스가 얼마나 바쁜가? (CPU %, 메모리 %) - 포화(Saturation): 얼마나 많은 작업이 대기 중인가? (요청 큐 깊이) - 오류(Errors): 오류율은 얼마인가? (HTTP 5xx 비율) - 속도(Rate): 초당 요청 수는? - 지속 시간(Duration): 요청에 얼마나 걸리는가? (p50, p95, p99 지연)

로그(Logs)¶

로그는 개별 이벤트의 타임스탬프 기록이다. 메트릭이 제공할 수 없는 세부 사항을 제공한다 — 정확한 오류 메시지, 요청 ID, 영향받은 사용자.

좋은 로깅 실천: - 구조화된 로깅(Structured logging): 로그를 기계가 파싱할 수 있도록 자유 텍스트가 아닌 JSON으로 출력 - 상관 ID(Correlation IDs): 모든 요청에 고유 ID; 해당 요청의 모든 로그 줄에 이를 포함 - 로그 레벨(Log levels): DEBUG, INFO, WARN, ERROR — 레벨을 일관성 있게 사용; 모든 것을 ERROR로 로깅하지 않음 - 민감한 데이터 로깅 금지: 비밀번호, 토큰, 개인정보(PII)는 절대 로그에 나타나면 안 됨

트레이스(Traces)¶

분산 트레이싱(Distributed tracing)은 요청이 여러 서비스를 통해 흐르는 것을 추적한다. 각 서비스는 스팬(span) (시작 시간, 종료 시간, 서비스 이름, 작업 이름)을 기록하고, 스팬들은 같은 트레이스 ID로 연결된다.

트레이스는 답한다: "이 요청이 왜 느렸는가? 어느 서비스가 병목이었는가?"

경보 원칙¶

모든 문제가 즉각적인 인간 대응을 필요로 하지는 않는다. 좋은 경보: - 증상에 경보, 원인이 아닌: "오류율 > 1%"보다 "CPU > 80%" (높은 CPU가 사용자에게 영향을 주지 않을 수도 있음) - SLO 소모율에 임계값 설정: 지속 가능한 속도보다 빠르게 오류 예산을 소모할 때 경보 - 노이즈 최소화: 경보 피로는 엔지니어가 경보를 무시하게 만든다 — 새벽 3시에 누군가를 깨우는 모든 경보는 실행 가능해야 함 - 런북 링크 포함: 모든 경보는 진단 및 해결 방법을 설명하는 런북에 링크해야 함

8. 사고 관리(Incident Management)¶

잘 설계된 시스템도 실패한다. 조직이 사고에 어떻게 대응하고 배우느냐가 신뢰성 문화를 정의한다.

온콜 실천¶

순환(Rotation): 팀원들 사이에서 온콜 부담을 공평하게 분배
에스컬레이션 경로(Escalation paths): 사고를 해결할 수 없을 때 누구에게 연락할지 알 수 있도록 명확한 에스컬레이션 체인 정의
런북(Runbooks): 알려진 장애 모드에 대한 미리 작성된 절차 — 온콜 엔지니어가 기본 진단을 즉흥적으로 해야 하지 않음
사고 심각도 수준(Incident severity levels): 심각도 기준 정의 (예: SEV1 = 완전 중단, SEV2 = 서비스 저하) 그래야 대응이 비례적임

무결점 사후 검토(Blameless Postmortems)¶

사후 검토(postmortem)는 무슨 일이 있었는지, 왜, 재발 방지를 위해 무엇을 할 것인지를 기록하는 문서다. "무결점(blameless)" 수식어가 중요하다: 목표는 개인 처벌이 아닌 체계적 개선이다.

왜 무결점인가? 사람들이 처벌을 두려워할 때, 정보를 숨긴다. 무결점 문화는 조직이 사고를 사람 문제가 아닌 시스템 문제로 다루기 때문에 엔지니어들이 — 자신의 실수를 포함하여 — 무슨 일이 있었는지 솔직하게 보고한다는 것을 의미한다. 이 투명성만이 실제로 개선하는 유일한 방법이다.

표준 사후 검토 구조:

사고 요약
  - 날짜, 기간, 심각도, 영향받은 시스템

타임라인
  - 이벤트의 시간순 순서 (UTC 타임스탬프)
  - 탐지, 에스컬레이션, 완화, 해결 포함

근본 원인 분석
  - 트리거 원인은 무엇이었는가?
  - 기여 요인은 무엇이었는가?
  - "5 Why" 또는 결함 트리 분석 사용

영향
  - 영향받은 사용자, 수익 영향, SLO 소모

행동 항목
  - 각 항목: 설명, 담당자, 기한, 우선순위
  - 즉각적 완화 vs. 장기적 수정 구별

얻은 교훈
  - 잘된 것은? (탐지, 대응)
  - 개선할 수 있는 것은?
  - 우리를 놀라게 한 것은?

사후 검토의 행동 항목은 추적되고 완료되어야 한다. 개선 목록을 만들었지만 아무것도 변하지 않는 사후 검토는 아예 없는 것보다 나쁘다 — 조직이 실제로 개선에 관심이 없다는 신호를 보낸다.

9. DORA 메트릭¶

Dr. Nicole Forsgren, Jez Humble, Gene Kim이 이끄는 DevOps Research and Assessment(DORA) 프로그램은 소프트웨어 납품 성과에 대한 가장 큰 지속적인 과학적 연구다. 이 연구는 고성과 엔지니어링 조직과 저성과 조직을 구별하는 4가지 핵심 메트릭을 파악한다.

4가지 DORA 메트릭¶

메트릭	정의	엘리트 수행자	저성과 수행자
배포 빈도(Deployment Frequency)	운영 환경에 코드가 배포되는 빈도	하루 여러 번	월 1회 미만
변경 리드 타임(Lead Time for Changes)	코드 커밋에서 운영 환경에서 실행까지의 시간	1시간 미만	1–6개월
변경 실패율(Change Failure Rate)	운영 사고를 일으키는 배포의 비율	0–15%	46–60%
서비스 복구 시간(Time to Restore, MTTR)	운영 장애에서 복구하는 시간	1시간 미만	1주 – 1개월

메트릭이 드러내는 것¶

배포 빈도와 리드 타임은 처리량(throughput)을 측정한다 — 아이디어에서 운영까지 가치가 얼마나 빠르게 흐르는가.

변경 실패율과 MTTR은 안정성(stability)을 측정한다 — 시스템이 얼마나 신뢰할 수 있고 얼마나 빠르게 복구되는가.

DORA 연구의 반직관적 발견: 높은 처리량과 높은 안정성은 상관관계가 있으며 트레이드오프가 아니다. 엘리트 팀은 더 자주 배포하며 동시에 실패가 적다. 이는 잦은 소규모 변경이 본질적으로 드문 대규모 변경보다 위험이 적고, 빠른 피드백 루프가 문제를 더 일찍 잡기 때문이다.

DORA 메트릭 사용¶

성과 평가가 아닌 진단 신호로 사용한다. 배포 빈도를 개별 엔지니어를 순위 매기는 데 사용하지 않는다.
절대값보다 시간에 따른 추세가 더 유용하다. 팀이 개선되고 있는가?
DORA 메트릭은 지연 지표 — 결과를 반영한다. 이를 개선하려면 선행 실천에 집중한다 (CI, 테스트 커버리지, 배포 자동화, 관찰 가능성).

10. DevOps 성숙도 모델¶

조직은 DevOps를 점진적으로 채택한다. 성숙도 모델은 팀이 현재 어디에 있고 다음에 무엇을 해야 하는지 이해하는 데 도움을 준다.

레벨	명칭	특징
1	초기(Initial)	수동 배포, 제한된 자동화, 사일로 팀, 사고는 위기
2	개발 중(Developing)	기본 CI 파이프라인, 자동화 테스트, 일부 공유 소유권, 사후 검토 발생
3	정의됨(Defined)	지속적 납품, IaC, SLO 있는 모니터링, 무결점 사후 검토, 주간+ 배포 빈도
4	관리됨(Managed)	지속적 배포, 완전한 관찰 가능성, DORA 메트릭 추적, 오류 예산 사용
5	최적화(Optimizing)	실험 문화, 카오스 엔지니어링, 엘리트 DORA 메트릭, 실천을 산업에 환원

대부분의 조직은 레벨 2–3에 있다. 레벨 3에서 4로 이동하는 것은 일반적으로 추가 도구보다 문화적 변화가 더 필요하다.

11. DevOps의 문화적 측면¶

DevOps에서 기술은 쉬운 부분이다. 문화가 어려운 부분이다.

사일로 허물기¶

전통적인 조직은 개발자, QA, 보안, 운영을 서로 다른 관리자, 서로 다른 유인, 서로 다른 어휘를 가진 별도 부서로 분리한다. DevOps는 이 그룹들이 공유된 결과를 향해 통합된 팀으로 작업하도록 요구한다.

사일로를 허물기 위해서는: - 공유 목표(Shared goals): 통합된 팀은 충돌하는 별도 부서 목표가 아닌 하나의 OKR 세트를 가짐 - 내재된 전문성(Embedded expertise): 보안과 운영 전문성이 별도 승인 대기열이 아닌 제품 팀 내에 존재 - 직무 교환 및 섀도잉(Job rotation and shadowing): 개발자가 온콜 시간을 보내고; 운영 엔지니어가 CI 파이프라인 개발에 기여 - 공유 도구(Shared tools): 공통 관찰 가능성 플랫폼, 공통 배포 플랫폼

공유 책임¶

"당신이 만들면, 당신이 실행한다(You build it, you run it)" — Amazon CTO Werner Vogels, 2006. 서비스를 구축하는 팀이 운영 환경에서 서비스를 운영할 책임이 있다. 이는 개발자가 운영 가능성에 관심을 갖도록 강제한다: 계측, 우아한 저하(graceful degradation), 런북, 경보.

공유 책임은 모든 개발자가 24/7 온콜이라는 의미가 아니다. 이것이 의미하는 바: - 개발자가 자신의 서비스에 대한 온콜 순환에 참여 - 엔지니어가 운영 가능한 시스템을 설계 (기능적일 뿐만 아니라) - 신뢰성은 사후 생각이 아닌 기능

실패에서 배우기¶

고성과 DevOps 조직은 모든 실패를 배움의 기회로 다룬다. 이는 심리적 안전 — 처벌 두려움 없이 발언하고, 실수를 인정하고, 질문할 수 있다는 믿음 — 을 필요로 한다.

리더는 다음을 통해 심리적 안전을 가능하게 한다: - 직접 무결점 사후 검토를 수행하고 행동을 모델링 - 엔지니어가 문제를 조기에 탐지하고 보고할 때 축하 - 사고 데이터를 개인 성과 평가에 절대 사용하지 않음 - 공개적으로 자신의 실수를 인정

요약¶

DevOps는 소프트웨어 개발과 운영 사이의 간격을 메워 빠르고 신뢰할 수 있는 소프트웨어 납품을 가능하게 하는 문화와 실천의 집합이다 — 도구가 아니다.

핵심 개념: - CALMS (문화, 자동화, 린, 측정, 공유)는 DevOps 성숙도의 차원을 설명함 - CI는 모든 코드 변경이 자동화된 빌드 및 테스트 파이프라인으로 검증됨을 보장; 깨진 빌드는 즉시 수정 - 지속적 납품은 소프트웨어가 항상 배포 가능함을 의미; 지속적 배포는 자동으로 배포됨을 의미 - 배포 전략 (롤링, 블루-그린, 카나리, 피처 플래그)은 릴리스 중 위험을 관리 - IaC는 인프라 설정을 애플리케이션 코드와 같은 규율로 다룸 - 관찰 가능성 (메트릭, 로그, 트레이스)은 운영 시스템을 이해하는 데 필요한 가시성을 제공 - 무결점 사후 검토는 개인을 처벌하지 않고 실패를 배움의 기회로 전환 - DORA 메트릭은 엔지니어링 성과에 대한 증거 기반 척도를 제공; 높은 처리량과 높은 안정성은 상관관계가 있으며 트레이드오프가 아님

연습 문제¶

파이프라인 설계: 데이터베이스 백엔드가 있는 웹 애플리케이션을 위한 CI/CD 파이프라인을 스케치하라. 모든 단계, 각 단계에서 확인하는 것, 대략 소요 시간, 해당 단계에서의 실패 기준을 나열하라. 단계 순서를 정당화하라.
배포 전략 선택: 팀이 99.99% 가동 시간 SLO를 가진 결제 처리 서비스를 운영하고 있다. 데이터베이스 스키마를 변경하는 새 버전을 배포해야 한다. 어떤 배포 전략을 권장하겠는가, 그 이유는? 스키마 변경이 어떤 복잡성을 도입하는가?
DORA 평가: 팀이 월 1회 운영 환경에 배포하고, 커밋에서 운영까지 3주가 걸리고, 30% 변경 실패율을 가지며, 사고에서 복구하는 데 평균 2일이 걸린다. DORA 성숙도 범주를 사용하여 이 팀을 분류하라. 개선을 위해 어느 메트릭을 먼저 목표로 삼겠는가, 그리고 어떤 구체적인 실천을 권장하겠는가?
사후 검토 작성: 트래픽 급증 후 데이터베이스 연결 풀이 소진되어 전자상거래 사이트가 블랙 프라이데이에 45분 중단을 경험했다. 사후 검토 개요를 작성하라: 타임라인(그럴듯한 세부 사항 작성), "5 Why"를 사용한 근본 원인 분석, 영향 추정, 그리고 담당자와 우선순위가 있는 최소 4개의 행동 항목.
무결점 문화 분석: 팀 리드가 말한다: "우리의 사후 검토는 항상 실수를 한 사람을 파악한다. 우리는 책임이 필요하다." 책임과 비난의 차이를 설명하고, 무결점 사후 검토가 왜 실제로 더 나은 결과를 이끄는지 설명하는 답변을 작성하라. 심리적 안전과 사람들이 처벌을 두려워할 때 정보 흐름에 무슨 일이 일어나는지를 참조하라.

더 읽을거리¶

도서:
The Phoenix Project — Gene Kim, Kevin Behr, George Spafford (DevOps 원칙에 대한 소설 스타일 소개)
Accelerate: The Science of Lean Software and DevOps — Nicole Forsgren, Jez Humble, Gene Kim (DORA 메트릭 뒤의 연구)
The DevOps Handbook — Gene Kim, Jez Humble, Patrick Debois, John Willis (포괄적인 실천 가이드)
Site Reliability Engineering — Google (sre.google에서 무료 온라인) — SRE 실천 상세
연구 및 보고서:
DORA State of DevOps Report (연간, dora.dev) — 엔지니어링 성과 벤치마크 데이터
"Psychological Safety and Learning Behavior in Work Teams" — Amy Edmondson, ASQ 1999
아티클:
"Continuous Delivery" — Martin Fowler (martinfowler.com/bliki/ContinuousDelivery.html)
"Feature Toggles" — Pete Hodgson (martinfowler.com)
"CALMS: A DevOps Framework" — Atlassian 문서
"Blameless PostMortems and a Just Culture" — John Allspaw, Etsy Engineering Blog