풀스택 개발자를 위한 CI/CD 13강 — 측정과 개선: DORA 지표, 그리고 마무리

풀스택 개발자를 위한 CI/CD 시리즈 · 심화 13/13

지금까지 파이프라인을 만들고, 빠르게 하고, 안전하게 했습니다. 마지막 질문은 "그래서 우리 팀의 전달 능력이 실제로 좋아졌는가"입니다. 측정하지 않으면 개선했는지 알 수 없습니다. 마지막 강의에서는 측정 방법을 다루고, 시리즈 전체를 하나의 로드맵으로 정리합니다.

1. DORA 지표

DORA(DevOps Research and Assessment)는 수년간 수많은 조직을 조사해, 소프트웨어 전달 성과를 설명하는 핵심 지표를 정리했습니다. 이 연구는 책 『Accelerate』로 널리 알려졌고, 매년 보고서로 갱신되고 있습니다.

지표	질문	측정 방법
배포 빈도 (Deployment Frequency)	얼마나 자주 운영에 배포하는가?	기간 내 운영 배포 횟수
변경 리드타임 (Lead Time for Changes)	커밋이 운영에 도달하기까지 얼마나 걸리는가?	커밋 시각 → 운영 배포 완료 시각
변경 실패율 (Change Failure Rate)	배포 중 몇 %가 장애·롤백·긴급 수정을 일으키는가?	실패 배포 수 / 전체 배포 수
실패 배포 복구 시간 (Failed Deployment Recovery Time)	배포로 인한 장애를 얼마나 빨리 복구하는가?	장애 발생 → 복구 완료 시각

앞의 두 개는 속도(throughput), 뒤의 두 개는 안정성(stability)을 나타냅니다.

DORA 연구의 가장 중요한 발견은 속도와 안정성이 서로 반대가 아니라는 것입니다. 성과가 높은 팀은 더 자주 배포하면서도 실패율이 낮고 복구도 빠릅니다. 1강에서 말한 "배포가 드물수록 배포는 위험해진다"를 데이터로 보여 준 셈입니다.

2. 지표를 어떻게 모으나

배포 이벤트 기록

GitHub Environments를 쓰면 배포가 Deployments 기록으로 남습니다(7강). API로 조회할 수 있습니다.

bash

# 운영 환경 배포 목록
gh api "repos/my-org/my-app/deployments?environment=production&per_page=100" \
  --jq '.[] | {sha: .sha, created_at: .created_at}'

Environments를 쓰지 않는 환경(폐쇄망 스크립트 배포 등)이라면, 6강의 releases.log처럼 배포 시각과 커밋을 기록하는 습관만으로도 시작할 수 있습니다.

리드타임 계산

bash

#!/usr/bin/env bash
# 배포된 커밋의 작성 시각과 배포 시각의 차이 (단순화한 예)
while read -r deployed_at sha; do
  committed_at=$(git show -s --format=%cI "$sha")
  echo "$sha $(( $(date -d "$deployed_at" +%s) - $(date -d "$committed_at" +%s) ))초"
done < releases.log

엄밀하게는 배포에 포함된 모든 커밋의 대기 시간을 봐야 합니다. 이전 배포 이후의 커밋 목록(git log prev..current)을 기준으로 계산하고, 중앙값을 사용하면 극단값에 덜 흔들립니다.

실패와 복구 기록

변경 실패율과 복구 시간은 자동으로 알기 어렵습니다. 장애 기록 규칙을 정합니다.

롤백하거나 긴급 수정(hotfix)이 필요했던 배포를 "실패 배포"로 표시합니다.
이슈 트래커에 incident 라벨로 장애를 기록하고 발생·복구 시각을 남깁니다.
8강의 자동 롤백 step이 실행되면 그 자체를 실패 이벤트로 기록합니다.

도구로는 DORA 공식 사이트의 간단한 자가 진단, Four Keys 같은 오픈소스 대시보드, 상용 엔지니어링 분석 서비스 등이 있습니다. 처음에는 스프레드시트로도 충분합니다. 완벽한 자동 측정보다 꾸준한 기록이 중요합니다.

3. 지표 사용 시 주의

개인 평가에 쓰지 않습니다. 지표가 평가 기준이 되면 사람들은 지표를 개선하는 대신 지표를 조작합니다(굿하트의 법칙). 의미 없는 배포를 쪼개 빈도를 늘리는 식입니다.
팀의 과거와 비교합니다. 다른 팀, 다른 도메인과 단순 비교하지 않습니다. 사내 시스템과 소비자 서비스의 적정 배포 빈도는 다릅니다.
네 지표를 함께 봅니다. 빈도만 올리고 실패율이 치솟는다면 개선이 아닙니다.
추세를 봅니다. 한 달의 숫자보다 분기별 방향이 중요합니다.

4. 파이프라인 자체의 건강 지표

DORA가 팀의 결과라면, 다음은 파이프라인이라는 도구의 상태입니다.

지표	의미	개선 방법
CI 소요 시간 (p50, p90)	피드백 속도	4강의 캐시, 병렬화, 샤딩
대기 시간	Runner 부족 여부	Runner 증설, 불필요한 실행 취소
main 성공률	main의 건강도	깨진 빌드 즉시 복구 문화
Flaky 테스트 비율	신뢰도	3강의 격리와 수정
재실행 비율	불안정성의 간접 지표	원인 분석
월별 실행 시간/비용	비용	경로 필터, 동시성 취소
의존성 업데이트 PR 평균 머지 시간	보안 패치 반영 속도	테스트 신뢰도 향상, 자동 머지 규칙

5. 성숙도 로드맵

지금까지의 강의를 단계별로 정리하면 다음과 같습니다. 팀이 어디에 있는지 확인하고 한 단계씩 올라가면 됩니다.

레벨	상태	해당 강의
0. 수동	서버에 접속해 손으로 빌드·배포	—
1. 자동 검증	PR마다 lint·test·build, 브랜치 보호	1~3강
2. 빠른 피드백	캐시·병렬화로 10분 이내, 동시성 제어	4강
3. 불변 산출물	이미지 빌드, SHA 태그, 레지스트리	5강
4. 자동 배포	스크립트 배포, 헬스체크, 롤백 절차	6강
5. 안전한 전달	환경 분리, 승인, OIDC, 최소 권한	7강
6. 무중단과 데이터 안정성	Blue-Green/카나리, Expand-Contract	8강
7. 신뢰할 수 있는 공급망	스캔 게이트, SBOM, 서명 검증	9강
8. 조직 규모 확장	모노레포 최적화, 공용 워크플로	10강
9. 선언형 운영	GitOps, 정책 강제, 점진적 배포	12강
∞. 지속적 개선	DORA 지표로 측정하고 병목 제거	13강

폐쇄망 환경(11강)은 별도 레벨이 아니라, 각 레벨을 폐쇄망 제약 안에서 구현하는 방법입니다.

6. 흔한 안티패턴

안티패턴	증상	처방
빨간 main 방치	"원래 실패하는 테스트예요"	깨진 빌드 최우선 복구, flaky 격리
장수 브랜치	머지할 때마다 대형 충돌	작은 PR, 기능 플래그
환경별 재빌드	스테이징에선 됐는데 운영에선 안 됨	Build Once, 런타임 설정 주입
`latest` 배포	무엇이 떠 있는지 모름	SHA 태그, digest
서버에서 직접 수정	설정 drift, 재현 불가	모든 변경을 코드와 파이프라인으로
수동 마이그레이션	배포마다 DB 순서 사고	마이그레이션을 파이프라인 단계로
시크릿 평문 커밋	유출	시크릿 저장소, 스캔, 교체
복붙 워크플로	저장소마다 조금씩 다른 파이프라인	reusable workflow, composite action
문서 없는 운영	담당자 부재 시 복구 불가	RUNBOOK, Pipeline as Code
느린 CI 방치	결과를 안 보고 머지	측정 후 병목 제거

7. 종합 실습 과제

시리즈를 마무리하는 실습으로, 개인 Next.js 프로젝트 하나에 다음을 순서대로 적용해 보세요.

CI 구성: lint, typecheck, test, build 워크플로와 브랜치 보호 (2~3강)
통합 테스트: PostgreSQL 서비스 컨테이너와 마이그레이션 적용 (3강)
최적화: npm·Next.js 캐시, 동시성 취소, 소요 시간 전후 비교 (4강)
이미지: standalone 멀티스테이지 Dockerfile, GHCR push, SHA 태그 (5강)
배포: 개인 서버에 Compose + deploy.sh로 배포하고 롤백 연습 (6강)
환경 분리: staging 자동, production 승인 (7강)
무중단: Nginx Blue-Green 전환, 컬럼 이름 변경을 Expand-Contract로 실습 (8강)
보안: 액션 SHA 고정, Dependabot, Trivy 게이트, cosign 서명과 배포 전 검증 (9강)
측정: 한 달간 배포 기록을 모아 DORA 네 지표 계산 (13강)
(선택) 로컬 k3s/kind 클러스터에 Argo CD를 설치해 같은 앱을 GitOps로 배포 (12강)

각 단계를 블로그 글로 남기면, 그 자체가 "배포 파이프라인을 처음부터 설계할 수 있는 풀스택 개발자"라는 포트폴리오가 됩니다.

8. 최종 체크리스트

모든 PR에서 lint, 타입 체크, 테스트, 빌드가 실행된다
main은 보호되어 있고 필수 체크가 통과해야 머지된다
CI는 10분 안팎으로 끝난다
lockfile 기반으로 재현 가능하게 설치한다

산출물은 한 번 빌드한 불변 이미지이며 SHA/digest로 배포한다
스테이징과 운영이 분리되고 운영에는 승인이 있다
배포 후 헬스체크로 새 버전을 확인한다
롤백 절차가 있고 실제로 연습해 봤다
DB 마이그레이션은 이전 코드와 호환된다

보안

워크플로 권한이 최소이고, 외부 입력은 env로 전달한다
장기 자격 증명 대신 OIDC를 사용하거나, 교체 절차가 있다
서드파티 액션이 SHA로 고정되고 자동 업데이트된다
이미지 스캔 게이트와 서명 검증이 있다

운영

배포 이력이 기록된다
장애와 복구 시간이 기록된다
구성과 절차가 문서화되어 있다
DORA 지표를 주기적으로 돌아본다

9. 더 공부할 자료

GitHub Actions 공식 문서: 워크플로 문법, 보안 강화 가이드(Security hardening)
『Continuous Delivery』 (Jez Humble, David Farley): CD의 원전
『Accelerate』 (Nicole Forsgren 외): DORA 연구의 배경과 근거
dora.dev: DORA 지표 정의, 연례 보고서, 자가 진단
Martin Fowler, "Continuous Integration": CI 원칙의 고전적 정리
SLSA (slsa.dev), Sigstore (sigstore.dev): 공급망 보안
OpenGitOps (opengitops.dev), Argo CD 문서: GitOps 원칙과 구현
Docker 공식 문서의 빌드 모범 사례: 멀티스테이지, 캐시, 보안

10. 시리즈를 마치며

CI/CD는 도구의 이름이 아니라 "변경을 작게, 자주, 안전하게 사용자에게 전달하는 능력"입니다. GitHub Actions, GitLab CI, Jenkins, Argo CD는 그 능력을 구현하는 수단일 뿐이고, 도구는 계속 바뀝니다. 하지만 이 시리즈에서 반복한 원칙은 쉽게 바뀌지 않습니다.

파이프라인은 코드로 관리한다.
빠르게 실패하게 만든다.
한 번 빌드하고, 같은 것을 배포한다.
산출물은 불변이고, 정확히 식별된다.
모든 변경은 되돌릴 수 있게 설계한다. 특히 데이터베이스는.
권한은 최소로, 신뢰는 검증으로.
측정하고, 병목을 없앤다.

풀스택 개발자에게 이 원칙은 특히 중요합니다. 화면과 API와 데이터가 한 번에 바뀌는 순간을 책임지는 사람이기 때문입니다. 오늘 작은 워크플로 하나를 붙이는 것에서 시작해 보세요.

확인 문제와 해설

Q1. 팀장이 "배포 빈도를 두 배로 올리라"는 목표를 세웠더니, 팀이 하나의 변경을 여러 번에 나눠 배포하기 시작했습니다. 무엇이 문제일까요?

지표 자체가 목표가 되어 실제 개선 없이 숫자만 바뀌었습니다. DORA 지표는 병목을 찾는 진단 도구로 쓰고, 네 지표를 함께 보며 리드타임과 실패율이 실제로 개선되는지 확인해야 합니다.

Q2. 배포 빈도가 월 1회인 팀이 변경 실패율 30%를 기록하고 있습니다. 어떤 방향으로 개선하면 좋을까요?

배포 단위가 커서 위험이 큰 상태일 가능성이 높습니다. 자동 테스트와 배포 자동화를 먼저 갖춘 뒤 배포 크기를 줄이고 빈도를 높이는 방향으로 개선합니다. 작은 배포는 실패 원인을 찾기 쉽고 복구도 빠릅니다.

Q3. 리드타임을 측정했더니 코드 작성 후 PR 리뷰 대기가 전체 시간의 70%였습니다. 파이프라인 최적화가 우선일까요?

아닙니다. 병목은 CI가 아니라 리뷰 대기입니다. PR 크기 줄이기, 리뷰 담당 순환, 리뷰 응답 시간 합의처럼 프로세스 병목을 먼저 개선해야 합니다. 측정의 목적은 가장 큰 병목을 찾는 것입니다.