Day 1 - DevOps라는 운영 모델: CALMS의 다섯 축과 DORA가 측정해 보여준 진실

DevOps라는 단어를 처음 들었을 때 대부분은 "Jenkins랑 Ansible 같은 도구들"로 이해한다. 그렇게 시작해서 시험까지 그 수준으로 끝나면 Professional 시나리오 문제 앞에서 멈춰선다. DOP-C02가 묻는 것은 도구의 이름이 아니라 **"왜 이 조합인가, 왜 이 순서인가, 왜 이 메트릭으로 측정하는가"**다. 그 답을 만들어내는 사고 프레임이 바로 CALMS와 DORA 4 metrics다.

이 글에서는 DevOps가 왜 등장했고, 왜 단순한 도구 모음이 아니라 운영 모델이 되었는지, 그리고 그 운영 모델을 측정 가능하게 만든 DORA 연구가 AWS 도구 선택과 어떻게 맞물리는지를 정리한다. 새벽 3시에 알람이 울렸을 때 어떤 자동화가 켜졌어야 했는지를 떠올릴 수 있다면, 시험의 시나리오는 자연스럽게 풀린다.

DevOps의 탄생: 사일로가 깨질 수밖에 없던 순간

2009년 6월 23일 벨기에 헨트(Ghent)에서 열린 첫 DevOpsDays. 그 자리에서 Patrick Debois가 만든 "DevOps"라는 단어는 갑자기 튀어나온 게 아니다. 그 전 해인 2008년 토론토 Agile 컨퍼런스에서 Andrew Shafer가 "Agile Infrastructure"라는 주제로 BoF 세션을 열었지만 정작 발표장에 사람이 거의 오지 않았다. Debois 혼자 와서 그와 대화하며 "왜 Dev는 Agile을 하는데 Ops는 못 따라가는가"라는 질문이 생겼고, 그게 1년 뒤 DevOpsDays로 이어졌다.

그 시점의 산업 맥락이 중요하다. 2007-2008년 Flickr의 John Allspaw와 Paul Hammond는 "10+ Deploys Per Day"라는 발표(Velocity 2009)로 폭탄을 던졌다. 당시 엔터프라이즈는 분기에 한 번 배포가 정상이었는데, Flickr는 하루에 10번을 배포하면서도 안정적이었다. 어떻게 가능했나? 답이 "Dev와 Ops가 같은 팀처럼 일하면, 같은 도구를 쓰면, 같은 메트릭을 보면 가능하다"였다. 이게 DevOps 운동의 출발점이다.

💡 관련 이론: Conway의 법칙(1968) — "시스템 아키텍처는 그 조직의 커뮤니케이션 구조를 반영한다". 즉 Dev팀과 Ops팀이 분리되어 있으면 코드와 운영 인프라가 분리된 형태로 굳어지고, 둘 사이에 "throw it over the wall"이라는 안티패턴이 자연스럽게 생긴다. DevOps는 **역방향 Conway 법칙(Inverse Conway Maneuver)**을 적용해, "원하는 아키텍처에 맞춰 조직을 먼저 재설계"한다. Team Topologies(Skelton & Pais, 2019)는 이 아이디어를 4가지 팀 유형(Stream-aligned, Platform, Enabling, Complicated-subsystem)으로 정형화했다.

📚 사례: 2010년 Etsy의 John Allspaw가 CTO로 부임하며 "blameless postmortem"(비난 없는 사후 분석) 문화를 정착시켰다. 이는 단순한 친절함이 아니라 SRE의 핵심 원칙이다. 사람을 비난하는 문화에서는 엔지니어가 사고를 숨기고, 시스템 결함이 드러나지 않아 같은 사고가 반복된다. Etsy는 매주 "Postmortem of the Week"를 공유하며 학습 조직 문화를 만들었고, 이게 곧 산업 표준 SRE 프랙티스가 됐다. AWS의 Correction of Errors(COE) 프로세스가 정확히 이 패턴을 차용한다.

CALMS: 다섯 축으로 분해한 DevOps 성숙도

Jez Humble과 Damon Edwards가 2010년경 정리한 CALMS 프레임워크는 "DevOps가 되었다"는 게 무슨 뜻인지를 측정 가능한 5축으로 분해한다.

글자	의미	핵심 질문	AWS 매핑
C Culture	협업, 책임 공유, blameless 문화	"사고 났을 때 누가 야단맞는가?"	Cross-account IAM, ChatOps(Chatbot+Slack), AWS Incident Manager
A Automation	수동 절차 제거, Pipeline-as-Code	"사람이 손으로 하는 일이 몇 단계나 되는가?"	CodePipeline, CodeBuild, CDK, SSM Automation Runbook
L Lean	작은 배치, WIP 제한, 낭비 제거	"한 PR이 며칠 동안 떠 있는가?"

📝 연습 문제

선택지를 클릭하면 정답·해설이 펼쳐집니다.

문제 1

한 회사가 다음 상태를 보고했다: 배포 주기 월 1회, commit-to-prod 평균 14일, 배포 시 사고 발생률 28%, 사고 평균 복구 시간 36시간. DORA 등급으로 분류하면?

문제 2

Werner Vogels의 "You Build It, You Run It" 원칙이 AWS 도구 설계에 반영된 결과로 가장 거리가 먼 것은?

문제 3

한 팀이 Deployment Frequency는 일 5회로 Elite 수준인데 Change Failure Rate가 45%로 매우 높다. 가장 우선해야 할 개선 조치는?

문제 4

어떤 회사가 EKS 환경에서 GitOps 모델을 도입하려 한다. push-based(CodePipeline이 클러스터에 배포)와 pull-based(ArgoCD가 Git을 polling) 중 멀티 계정·멀티 클러스터 환경에서 더 유리한 모델과 그 이유는?

문제 5

CALMS의 다섯 축 중 "Measurement"가 충족되지 않으면 직접적으로 영향을 받는 다른 축은?

문제 6

SRE의 Error Budget 개념을 AWS에서 구현할 때 적절한 패턴은?

문제 7

한 조직이 "분기 1회 배포 → 일 1회 배포"로 가속하는 과정에서 가장 먼저 깔아야 할 AWS 도구 조합은?

문제 8

Blameless Postmortem의 본질적 효과로 가장 정확한 것은?

지표	정의	Elite 기준	High	Medium	Low
Deployment Frequency	운영 배포 빈도	온디맨드(하루 여러 번)	일 1회 ~ 주 1회	주 1회 ~ 월 1회	월 1회 미만
Lead Time for Changes	commit → prod 시간	1시간 미만	1일 미만	1일 ~ 1주	1주 ~ 1개월
Change Failure Rate (CFR)	배포 중 사고 비율	0-15%	16-30%	16-30%	16-30%
MTTR (Time to Restore)	사고 복구 시간	1시간 미만	1일 미만	1일 ~ 1주	1주 이상

차원	DevOps	SRE
출신	산업 운동(2009 Ghent)	단일 회사(Google, 2003)
핵심 원칙	CALMS	Error Budget, SLO/SLI, Toil 제거
측정 지표	DORA 4 metrics	SLO 달성률, Error Budget 소진율
조직 모델	"Dev + Ops 통합"	"Dev팀과 별도 SRE팀 (50% 코딩, 50% 운영)"
책임 경계	You build it, you run it	SLO 기반 책임 분담
자동화 정의	Pipeline-as-Code	Toil < 50% 강제

Day 1 - DevOps라는 운영 모델: CALMS의 다섯 축과 DORA가 측정해 보여준 진실

DevOps의 탄생: 사일로가 깨질 수밖에 없던 순간

CALMS: 다섯 축으로 분해한 DevOps 성숙도

📝 연습 문제

DORA 4 metrics: 측정 가능한 DevOps의 결정타

DORA → AWS 도구로의 매핑 — 시험이 진짜 묻는 것

Werner Vogels의 "You Build It, You Run It" — 책임 경계의 재정의

SRE와 DevOps의 관계 — 같은 것의 다른 측면

Pipeline-as-Code와 GitOps — 자동화의 두 번째 진화

AWS DevOps 도구 지도의 4개 축

CLI로 보는 DORA 측정의 시작점

정리하며 — 시험과 실무의 같은 그림