DevOps의 진화 — 2009년 벨기에 컨퍼런스부터 2026년 에이전틱 DevOps까지

DevOps는 17년 동안 다섯 단계를 거쳤다. 각 단계가 무엇을 풀었고, 무엇을 남겨 두었는지, 그리고 지금 우리가 어디에 와 있는지.

백재민
백재민
CollabOps 창업자
DevOps의 진화 — 2009년 벨기에 컨퍼런스부터 2026년 에이전틱 DevOps까지

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 기반 에이전트가 사람과 같은 권한 모델 위에서 운영 행위를 수행 하는 시기다. 단순 코드 어시스트가 아니라, 배포·롤백·인시던트 대응 같은 행위 평면에 들어온다.

이 단계의 핵심 질문은 두 가지다.

  1. 에이전트의 권한 경계 를 어떻게 정의할 것인가
  2. 에이전트의 행위가 사람과 같은 감사 트레이스 안에 들어가게 할 것인가

이 둘을 풀지 못하면 에이전트는 IDE 안의 도구 로만 머문다. 운영 평면에는 못 들어간다.

정리 — 다섯 단계의 누적

단계시기핵심 단어풀린 문제남긴 한계
12009–2013문화·IaCDev/Ops 분단배포 자동화 X
22014–2017CI/CD빌드 자동화배포 결정은 수동
32018–2020컨테이너·SRE운영 표준도구 다양성 폭증
42021–2024Platform Engineering도구 통합플랫폼 복잡도
52025–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#history#agentic-devops#platform-engineering#sre