DevOps 패턴과 안티패턴 1강 — DevOps는 왜 패턴이 필요해졌나

시리즈 전체 구성

1강. DevOps는 왜 패턴이 필요해졌나 2강. 인프라: 손으로 만든 서버의 최후 3강. 코드 흐름: 병합 지옥에서 벗어나기 4강. 파이프라인과 아티팩트 5강. 배포 전략: 빅뱅 릴리스를 쪼개는 법 6강. 운영: 장애를 대하는 방식 7강. 조직: 도구로는 해결되지 않는 것 특별편. 폐쇄망에서의 DevOps

들어가며

"DevOps를 도입했다"는 말은 흔히 "Jenkins를 설치했다"나 "Kubernetes로 옮겼다"는 뜻으로 쓰입니다. 그런데 도구를 다 갖췄는데도 배포는 여전히 두렵고, 금요일 배포는 금지이고, 장애가 나면 누군가의 이름이 회의에 오르는 조직이 많습니다. 도구가 문제를 풀지 못했다면, 애초에 문제가 도구 쪽에 있지 않았다는 뜻입니다.

이번 강의에서는 DevOps가 풀려고 했던 원래 문제가 무엇이었는지 추적합니다. 그리고 이후 강의에서 만날 모든 패턴을 판별할 기준을 세웁니다.

벽의 탄생: 개발과 운영은 왜 싸웠나

전통적인 IT 조직에서 개발팀과 운영팀은 서로 다른 것으로 평가받았습니다. 개발팀은 새 기능을 얼마나 빨리 내놓는지로, 운영팀은 시스템이 얼마나 안정적인지로 평가받았습니다.

문제는 장애의 가장 큰 원인이 변경이라는 점입니다. 아무것도 바꾸지 않은 시스템은 대체로 어제처럼 돌아갑니다. 그러니 운영팀 입장에서 가장 합리적인 전략은 변경을 막는 것입니다. 변경 승인 절차를 늘리고, 배포 가능 시간을 줄이고, 릴리스를 분기에 한 번으로 묶습니다. 개발팀은 완성된 코드를 벽 너머로 던지고, 운영팀은 그것을 받아 어떻게든 띄웁니다. 이 구조를 흔히 "혼돈의 벽(Wall of Confusion)"이라고 부릅니다.

여기서 역설이 생깁니다.

변경이 무섭다 → 배포 횟수를 줄인다
      ↑                    ↓
장애가 크다   ← 한 번에 배포되는 변경량이 커진다

배포를 드물게 하면 한 번의 배포에 몇 달치 변경이 실립니다. 변경이 많을수록 무엇이 장애를 일으켰는지 찾기 어렵고, 되돌리기도 어렵습니다. 그 결과 배포는 더 위험해지고, 운영팀은 배포를 더 줄입니다. 변경을 막으려는 시도가 오히려 변경을 더 위험하게 만드는 순환이 생기는 것이죠.

양쪽 모두 자기 평가 기준 안에서는 합리적으로 행동했습니다. 그런데 시스템 전체로 보면 최악의 결과가 나왔습니다. 이것이 DevOps 안티패턴의 원형이고, 앞으로 보게 될 거의 모든 안티패턴이 이 구조를 조금씩 변형한 형태입니다.

2009년, 전환점

이 순환을 끊을 수 있다는 증거는 의외의 곳에서 나왔습니다.

2008년 토론토의 Agile 컨퍼런스에서 Andrew Clay Shafer와 Patrick Debois가 "Agile Infrastructure"라는 주제로 만났습니다. 애자일이 개발 쪽의 속도는 올렸지만 운영과의 간극은 그대로라는 문제의식이었습니다.

2009년 Velocity 컨퍼런스에서는 Flickr의 John Allspaw와 Paul Hammond가 "하루 10회 이상 배포"라는 발표를 했습니다. 당시 상식으로는 무모해 보였지만, 핵심 주장은 반대였습니다. 작게 자주 배포하기 때문에 오히려 안정적이라는 것이었죠. 이 발표에 자극받은 Debois가 같은 해 벨기에 겐트에서 첫 DevOpsDays를 열었고, 여기서 "DevOps"라는 이름이 굳어졌습니다.

중요한 점은 DevOps가 특정 도구가 아니라 앞에서 본 순환을 뒤집자는 제안으로 출발했다는 것입니다. 변경을 막는 대신 변경을 작고 안전하게 만들자는 제안이었습니다.

"패턴"이라는 말의 족보

패턴이라는 개념은 소프트웨어가 아니라 건축에서 왔습니다. 건축가 Christopher Alexander는 1977년 『A Pattern Language』에서 "특정 맥락에서 반복적으로 나타나는 문제와, 그 문제에 대한 해법의 핵심"을 패턴이라 불렀습니다. 1994년 GoF가 이 개념을 객체지향 설계에 가져온 것이 우리가 아는 디자인 패턴입니다.

안티패턴이라는 말은 1995년 Andrew Koenig가 처음 썼고, 이후 정의가 다듬어졌습니다. 어떤 관행이 안티패턴이 되려면 두 조건을 만족해야 합니다.

1. 처음에는 합리적으로 보인다. 누구도 망하려고 SSH로 서버 설정을 고치지 않습니다. 그 순간에는 그게 가장 빠르기 때문입니다.
2. 더 나은 해법이 알려져 있다. 대안이 없는 고통은 안티패턴이 아니라 그냥 어려운 문제입니다.

첫 번째 조건이 특히 중요합니다. 안티패턴은 무지나 게으름의 산물이 아닙니다. 국소적으로 합리적인 선택이 쌓여서 전체적으로 나쁜 결과를 만드는 구조입니다. 그래서 개인을 탓해서는 고쳐지지 않고, 구조를 바꿔야 고쳐집니다. 이 관점은 6강(Blameless Postmortem)과 7강(조직)에서 다시 등장합니다.

DevOps에 GoF 같은 단일 카탈로그가 없는 이유도 여기서 짐작할 수 있습니다. DevOps 패턴은 코드 구조가 아니라 사람, 프로세스, 인프라에 걸친 문제를 다루기 때문에 맥락 의존성이 훨씬 큽니다. 대신 『Continuous Delivery』(2010), 『Accelerate』(2018), 『Team Topologies』(2019) 같은 책과 Martin Fowler의 글들이 사실상의 카탈로그 역할을 해 왔습니다.

패턴을 판별하는 세 가지 질문

앞으로 새로운 도구나 관행을 만나면 다음 세 질문을 던져 보세요. 거의 모든 DevOps 패턴은 이 중 하나 이상을 강화하고, 거의 모든 안티패턴은 하나 이상을 약화시킵니다.

첫째, 재현 가능한가? 같은 입력으로 같은 결과를 다시 만들 수 있는지를 묻습니다. 서버를 다시 만들 수 있는가, 빌드를 다시 돌리면 같은 결과물이 나오는가, 장애 상황을 다시 재현할 수 있는가. 재현이 안 되는 시스템은 이해할 수 없고, 이해할 수 없는 시스템은 두려움의 대상이 됩니다. 두려움은 변경 회피로 이어지고, 결국 앞의 악순환으로 돌아갑니다. IaC, 컨테이너 이미지, 버전 고정은 모두 이 질문에 대한 답입니다.

둘째, 변경 단위가 작은가? 한 번에 흘려보내는 변경의 크기(batch size)를 묻습니다. 변경이 작으면 원인 추적이 쉽고, 되돌리기 쉽고, 리뷰도 제대로 됩니다. 이 개념은 원래 제조업의 린(Lean) 생산 방식에서 왔습니다. 재고를 쌓아두지 말고 작은 단위로 흘려보내라는 원칙이죠. 소프트웨어에서 배포되지 않은 코드는 일종의 재고이고, 재고가 쌓일수록 위험도 쌓입니다. Trunk-Based Development, Canary Release, Feature Flag는 모두 이 질문에 대한 답입니다.

셋째, 피드백이 빠른가? 무언가 잘못됐을 때 얼마나 빨리 알 수 있는지를 묻습니다. 커밋 후 몇 분 안에 테스트 실패를 아는 것과, 3개월 후 운영에서 고객 항의로 아는 것은 수정 비용이 수십 배 차이 납니다. CI, Shift-Left, Observability가 이 질문에 대한 답입니다.

세 질문은 서로 맞물려 있습니다. 재현 가능해야 작은 변경을 안심하고 반복할 수 있고, 변경이 작아야 피드백이 무엇에 대한 것인지 분명해집니다.

측정: DORA 4대 지표

원칙만으로는 "우리 조직이 나아지고 있는가"를 판단하기 어렵습니다. 이 공백을 메운 것이 Nicole Forsgren, Jez Humble, Gene Kim의 『Accelerate』입니다. 수년간의 설문 연구(DORA, DevOps Research and Assessment)를 바탕으로, 소프트웨어 전달 성과를 예측하는 네 가지 지표를 제시했습니다.

이 연구에서 가장 중요한 발견은 속도와 안정성이 트레이드오프가 아니라는 것입니다. 성과가 높은 조직은 네 지표 모두에서 동시에 앞섰습니다. 자주 배포하는 조직이 오히려 실패율이 낮고 복구가 빨랐습니다.

앞의 악순환을 떠올리면 이 결과가 자연스럽게 이해됩니다. 자주 배포한다는 것은 변경 단위가 작다는 뜻이고, 변경이 작으면 실패가 적고 원인도 빨리 찾습니다. 2009년 Flickr 발표의 직관이 10년 가까이 지나 통계로 확인된 셈입니다.

한 가지 주의할 점이 있습니다. 이 지표를 개인이나 팀 평가에 직접 쓰기 시작하면 사람들은 지표 자체를 최적화합니다. 의미 없는 배포를 늘리거나, 장애를 장애로 기록하지 않는 식이죠(Goodhart의 법칙). 지표는 구조를 진단하는 도구로 써야지, 사람을 평가하는 도구로 쓰면 그 자체가 안티패턴이 됩니다.

정리

DevOps가 풀려던 원래 문제는 "변경을 막을수록 변경이 위험해지는" 구조적 순환이었습니다. 안티패턴은 이 순환 안에서 국소적으로 합리적인 선택이 쌓인 결과이고, 패턴은 이 순환을 뒤집는 반복 검증된 해법입니다. 어떤 관행이 어느 쪽인지 판단할 때는 재현성, 작은 변경 단위, 빠른 피드백이라는 세 질문을 던지고, 개선 여부는 DORA 4대 지표로 확인합니다.

다음 2강에서는 이 세 질문 중 첫 번째인 재현성이 무너진 가장 대표적인 사례, Snowflake Server에서 출발합니다. 서버가 어떻게 "아무도 다시 만들 수 없는 존재"가 되는지, 그리고 IaC와 Immutable Infrastructure가 그 문제를 어떻게 다르게 푸는지 다룹니다.