DevOps의 진화 — 2009년 벨기에 컨퍼런스부터 2026년 에이전틱 DevOps까지
DevOps는 17년 동안 다섯 단계를 거쳤다. 각 단계가 무엇을 풀었고, 무엇을 남겨 두었는지, 그리고 지금 우리가 어디에 와 있는지.
DevOps는 단일 사건이 아니다. 2009년 Patrick Debois가 벨기에 겐트에서 첫 DevOpsDays를 연 이후, 다섯 번의 의미 있는 단계 변화가 있었다. 각 단계는 직전 단계가 만든 새 한계 를 풀기 위해 등장했다.
이 글은 그 17년을 압축한다. 카테고리 정의 자체가 바뀌어 왔고, 지금의 AI 에이전틱 DevOps 는 또 다른 한계 위에서 등장한 답이지, 새로 만든 유행어가 아니다.
1단계 (2009–2013) — Dev와 Ops 사이의 벽 허물기
원래의 DevOps 운동은 문화 운동이었다. 개발과 운영이 다른 목표(개발은 "변화", 운영은 "안정") 를 가진 채로 갈라져 있던 것을 한 팀의 책임으로 합치는 것이 핵심이었다.
이 시기의 도구는 단순했다 — Chef, Puppet, Vagrant. Infrastructure as Code 라는 개념이 처음 자리 잡았다.
남긴 한계: 코드로 인프라를 정의해도, 배포 그 자체가 자동화되지 않으면 결국 수동이다.
2단계 (2014–2017) — CI/CD의 일반화
Jenkins, Travis CI, CircleCI 가 보편화됐다. 모든 커밋이 빌드를 트리거 하는 게 당연한 일이 됐다.
여기서 GitOps 의 씨앗이 뿌려졌다 — 깃 저장소가 진실의 단일 출처(single source of truth) 라는 명제. 또한 마이크로서비스 의 부상이 CI/CD 의무를 폭발적으로 늘렸다.
남긴 한계: 빌드는 자동이지만, 배포 결정 과 롤백 은 여전히 사람이 한다.
3단계 (2018–2020) — 컨테이너와 쿠버네티스
Docker 와 Kubernetes 가 운영 표준이 됐다. 클라우드 네이티브 라는 단어가 의미를 갖기 시작했다.
이 시기에 SRE (Site Reliability Engineering) 가 별개의 직무로 자리 잡았다. Google 의 SRE Book(2016) 이 표준 텍스트가 됐다. Observability 가 logs/metrics/traces 의 세 기둥으로 정착했다.
남긴 한계: 도구는 풍부해졌지만 조직별로 너무 다른 조합 을 쓰게 되어, 새 엔지니어 온보딩 비용이 폭증했다.
4단계 (2021–2024) — Platform Engineering
기업들이 깨달았다 — 모든 팀이 자기만의 DevOps 도구 묶음을 만드는 건 비용이 너무 크다. 그래서 내부 개발자 플랫폼(IDP, Internal Developer Platform) 을 만드는 흐름이 생겼다.
이 시기를 정의하는 단어는 Platform Engineering 이다. Backstage, Crossplane, Argo CD 가 핵심 도구로 부상했다. DevSecOps 도 이 시기에 별개 카테고리가 아니라 플랫폼의 기본 책임 으로 흡수됐다.
남긴 한계: 플랫폼이 풍부해질수록, 플랫폼 자체의 복잡도 가 새로운 병목이 됐다.
5단계 (2025–) — Agentic DevOps
지금이다. LLM 기반 에이전트가 사람과 같은 권한 모델 위에서 운영 행위를 수행 하는 시기다. 단순 코드 어시스트가 아니라, 배포·롤백·인시던트 대응 같은 행위 평면에 들어온다.
이 단계의 핵심 질문은 두 가지다.
- 에이전트의 권한 경계 를 어떻게 정의할 것인가
- 에이전트의 행위가 사람과 같은 감사 트레이스 안에 들어가게 할 것인가
이 둘을 풀지 못하면 에이전트는 IDE 안의 도구 로만 머문다. 운영 평면에는 못 들어간다.
정리 — 다섯 단계의 누적
| 단계 | 시기 | 핵심 단어 | 풀린 문제 | 남긴 한계 |
|---|---|---|---|---|
| 1 | 2009–2013 | 문화·IaC | Dev/Ops 분단 | 배포 자동화 X |
| 2 | 2014–2017 | CI/CD | 빌드 자동화 | 배포 결정은 수동 |
| 3 | 2018–2020 | 컨테이너·SRE | 운영 표준 | 도구 다양성 폭증 |
| 4 | 2021–2024 | Platform Engineering | 도구 통합 | 플랫폼 복잡도 |
| 5 | 2025– | Agentic DevOps | ? | 권한·감사 |
각 단계는 누적 이지 대체 가 아니다. 5단계는 1~4단계의 문제를 다시 푸는 게 아니라, 그 위에 새 평면을 올린다.
자주 묻는 질문
Q. DevOps는 죽었다는 말이 종종 나온다. 사실인가? A. 단어로서의 "DevOps" 가 마케팅 용어로 닳은 건 사실이지만, 운동 으로서의 DevOps 는 매 단계 의미를 갱신해 왔다. 죽은 게 아니라 진화 중 이다.
Q. SRE 와 DevOps 의 차이는? A. SRE 는 Google 이 DevOps 원칙을 구현하기 위한 한 방법론 으로 만들었다. DevOps 가 "무엇을" 이라면, SRE 는 "어떻게" 다. → 자세한 비교는 SRE vs Platform Engineering vs DevOps 참고.
Q. Agentic DevOps 는 곧 사람을 대체하나? A. 단기간엔 대체 가 아니라 권한 경계 이동 이다. 사람이 의사결정·승인을 유지하고, 에이전트가 실행 평면에서 시간을 줄인다. → 온프레미스 AI 에이전트가 어려운 진짜 이유 도 함께 보면 좋다.
비슷한 글
에이전틱 DevOps 12개월 후 — 첫 가설 중 무엇이 *맞았고* 무엇이 *틀렸나*
12개월 전 다음 10년의 DevOps는 에이전틱이다 의 가설들. 12개월의 데이터로 어느 가설이 맞고 어느 게 틀렸는지의 정직한 평가.
백재민
3 pillars 그 후 — 4 추가 신호의 *6개월 후* 운영 노트
3 pillars 가 더 이상 충분하지 않은 이유 발행 후 6개월. 4 추가 신호 (events / user journeys / deploy correlation / similarity) 가 운영에서 어떻게 작동했는지의 후속.
백재민
GitHub Actions vs 자체 호스팅 — *진짜 비용* 비교 (12개월 데이터)
GitHub Actions 가 *비싸 보임* 은 표면. 12개월 자체 호스팅 vs SaaS 비교 — 단순 *분당 비용* 이 아니라 *총 운영 비용* 으로.
백재민