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 에이전트가 어려운 진짜 이유 도 함께 보면 좋다.
비슷한 글
기획자가 코드를 배포하면, 장애는 누가 책임질까
AI로 제품 담당자가 직접 코드를 만들고 여러 에이전트가 동시에 작업하는 조직에서, 운영에 나가는 변경을 누가 무엇으로 확인해야 하는지. NIST SSDF, SLSA provenance, Google SRE 포스트모템 문화를 근거로 작성자와 분리된 검증·승인·복구의 역할 설계를 정리했다.
백재민
에이전트 시대의 Eclipse 플러그인 — 작업 컨텍스트는 20년 전에도 문제였다
Mylyn 이 2000년대에 풀려던 문제와 지금 에이전트 컨텍스트 문제는 같습니다. 달라진 건 그 컨텍스트를 읽는 쪽에 사람만 있는 게 아니라는 점입니다.
김영상
에이전트 시대의 VS Code 확장 — 개발자는 에디터에서 무엇을 보는가
코드 작성 비용이 무너진 뒤 개발자의 시간은 판단과 승인으로 옮겨갔습니다. 그 일들이 왜 에디터 밖에 있으면 안 되는지, VS Code 확장을 만들며 내린 선택들.
이승백