[DevOps] 왜 DevOps는 결국 GitOps로 향하게 되었을까

이 내용은 책 4권을 읽고 나서 나름의 개념을 정리한 내용입니다.

[Reviews/읽자] - [DevOps] 엔터프라이즈 데브옵스 (DevOps for the Modern Enterprise)

[Reviews/읽자] - [DevOps] 데브옵스 도입 전략 (The DevOps Adoption Playbook)

[Reviews/읽자] - [DevOps] 데브옵스 핸드북 2/e (The DevOps Handbook)

[Reviews/읽자] - [DevOps] GitOps CookBook

---

운영 패러다임은 어떻게 계속 바뀌어왔는가

한동안 DevOps 관련 책들을 몰아서 읽었다.

책 자체도 재미있었지만, 더 흥미로웠던 건 책들 사이에 흐르는 “시대의 변화”였다.

읽다 보면 느껴지는 게 있다.

운영 패러다임은 어느 날 갑자기 등장한 게 아니라 항상 이전 방식의 한계를 해결하기 위해 조금씩 진화해왔다는 점이다.

그리고 그 흐름은 생각보다 굉장히 자연스럽다.

처음에는:
“배포를 좀 더 빠르게 하고 싶다”
에서 시작했는데,

시간이 지나면서:

• 조직 구조가 병목이 되고,
• 운영 복잡도가 증가하고,
• 클라우드와 Kubernetes가 등장하고,
• 시스템 규모 자체가 폭발적으로 커지면서,

결국:
“사람이 직접 상태를 관리하는 운영 방식 자체가 한계에 도달했다”
는 방향으로 계속 흘러간다.

재미있는 건 기술은 계속 바뀌었는데,
근본적으로 해결하려는 문제는 계속 비슷했다는 점이다.

운영 복잡도를 줄이고,
사람 의존도를 낮추고,
변경을 더 안전하게 만들고,
시스템을 더 일관되게 유지하려는 방향.

결국 지난 10년 정도의 DevOps 흐름은:
“사람 중심 운영”에서 “시스템 중심 운영”으로 이동해온 과정처럼 느껴졌다.

1. 처음 DevOps가 해결하려 했던 문제

초기 운영 조직의 가장 큰 문제는 속도보다 “병목”에 가까웠다.

당시 엔터프라이즈 환경에서는:

• 긴 승인 절차,
• 조직 간 분리,
• 수동 배포,
• 사람 의존 운영

같은 문제들이 굉장히 강했다.

자동화 기술 자체는 이미 존재했는데도 조직은 쉽게 빨라지지 못했다.

왜냐하면 실제 병목은 기술보다 조직 구조에 있었기 때문이다.

배포 한번 하려 해도:
운영팀 확인 받고,
승인 등록하고,
점검 시간 잡고,
롤백 계획 작성하고,
새벽 대기 들어간다.

그러다 보면 자동화가 있어도 결국 사람이 중심이 된다.

이 시기의 핵심 키워드는:
“운영 복잡도를 어떻게 줄일 것인가”
에 가까웠다.

특히 운영 규모가 커질수록:
특정 사람 기억력으로 유지되는 시스템은 오래 못 간다는 걸 다들 느끼기 시작했던 것 같다.

그리고 여기서 중요한 변화가 나온다.

운영자를 단순 반복 작업 수행자가 아니라:
“Knowledge Worker”, 즉 지식 노동자로 보기 시작한 것.

반복 작업은 자동화하고,
사람은:

• 시스템 개선,
• 운영 구조 설계,
• 자동화,
• 플랫폼화

같은 더 복잡한 문제를 다루기 시작한다.

지금 보면 너무 자연스러운 흐름인데,
당시에는 꽤 큰 변화였던 것 같다.

# 초기 운영 구조

개발팀 → 운영팀 → 승인조직 → DBA → 배포

(긴 승인 흐름)
(수동 전달)
(사람 의존)

2. 근데 기술만으로 조직은 안 바뀌었다

DevOps가 어느 정도 자리 잡기 시작하면서 새로운 문제가 등장한다.

“좋은 기술을 도입해도 조직은 쉽게 안 바뀐다.”

이게 생각보다 굉장히 큰 문제였다.

현실 조직에서는:

• 익숙하지 않거나,
• 책임이 애매하거나,
• 운영 리스크가 커 보이면

아무리 좋은 구조라도 쉽게 받아들이지 않는다.

특히 운영 조직은 더 그렇다.

장애는 결국 실제 사람을 지치게 만들기 때문이다.

새벽에 깨고,
로그 뒤지고,
원인 분석하고,
회의 들어가고,
재발방지 쓰는 경험이 반복되면 조직은 자연스럽게 보수적으로 변한다.

그래서 이 시기부터 중요한 건:
“좋은 기술”
보다
“신뢰”가 된다.

결국 사람은 기술로 설득되는 게 아니라:
“내 일이 실제로 편해졌다”
라는 경험으로 움직인다.

배포 시간이 줄어들고,
반복 작업이 줄어들고,
새벽 대응이 줄어들고,
운영 스트레스가 줄어드는 경험.

이런 게 쌓여야 조직도 움직이기 시작한다.

그래서 DevOps는 점점:
단순 기술 도입이 아니라 조직 변화 전략처럼 움직이기 시작한다.

내부 챔피언,
조직 Alignment,
측정 가능한 성과,
운영 프로세스 변화 같은 흐름이 중요해진 것도 이 시기였다.

근데 여기서 또 다른 문제가 등장한다.

조직은 조금씩 적응하고 있었는데,
시스템 규모 자체가 완전히 달라지기 시작한 것.

# 조직 변화 확산 구조

좋은 기술
   ↓
반복 성공 경험
   ↓
조직 신뢰 형성
   ↓
문화 변화
   ↓
조직 전체 확산

3. Kubernetes 이후 운영 난이도가 완전히 달라졌다

클라우드,
MSA,
컨테이너,
Kubernetes.

이 흐름 이후 운영 자체가 완전히 다른 문제가 되기 시작한다.

예전에는:
서버 몇 대 관리하는 수준이었다면,

이제는:

• 수백 개 서비스,
• 동적으로 변하는 리소스,
• 수많은 배포 단위,
• 계속 변하는 상태,
• 멀티 클러스터

같은 환경이 된다.

이쯤 되면 단순히 “배포 자동화”만으로는 부족해진다.

왜냐하면 운영 상태 자체가 너무 복잡해졌기 때문이다.

특히 여기서 중요해진 게:
“피드백 속도”와 “관측 가능성”이었다.

운영 규모가 커질수록:
“장애를 막는다”
보다
“장애를 얼마나 빨리 이해하는가”
가 훨씬 중요해진다.

완벽하게 장애 없는 시스템은 현실적으로 어렵기 때문이다.

그래서:

• Monitoring,
• Telemetry,
• Alerting,
• Observability

같은 흐름이 핵심으로 올라온다.

그리고 운영 철학 자체도 바뀌기 시작한다.

예전에는:
변경은 위험한 것이고,
배포는 최대한 줄여야 한다는 분위기가 강했다.

근데 실제 운영하다 보면 오히려 반대였다.

몇 달 치 변경사항을 한 번에 배포하는 게 훨씬 무섭다.

문제 생겨도 어디서 깨졌는지 찾기 어렵고,
롤백 범위는 커지고,
영향도도 커진다.

그래서:
작고 자주 변경할수록 더 안정적이라는 흐름이 강해진다.

이 시점부터 운영은 단순 경험과 감으로 버티는 영역이 아니라:
하나의 “시스템 공학”처럼 움직이기 시작한다.

근데 여기서 또 다른 한계가 등장한다.

사람이 직접 상태를 맞추는 방식 자체가 확장되지 않는다는 점.

# 운영 복잡도 증가

시스템 규모 ↑
      ↓
운영 상태 변화량 ↑
      ↓
사람 중심 운영 한계
      ↓
선언형/자동화 운영 필요

4.결국 GitOps는 “배포 방식”보다 “상태 관리 방식”의 변화였다

처음 GitOps를 보면 단순 Kubernetes 배포 전략처럼 보인다.

Git에 yaml 넣고,
ArgoCD 같은 걸로 동기화하는 방식 정도.

근데 실제로는 훨씬 운영 철학에 가까운 느낌이다.

GitOps가 해결하려 했던 핵심 문제는:
“운영 상태 드리프트”였다.

운영자가 직접 들어가서 설정 바꾸고,
긴급 수정하고,
콘솔에서 값 바꾸고,
SSH 들어가서 대응하기 시작하면 시간이 갈수록 상태가 이상해진다.

문서와 실제 설정이 달라지고,
환경마다 설정이 달라지고,
왜 특정 서버만 다르게 동작하는지도 모르게 된다.

운영 오래 해보면:
“분명 같은 환경인데 왜 얘만 다르지?”
라는 순간을 계속 만나게 된다.

그리고 대부분 원인을 따라가다 보면:
예전에 누군가 급하게 수정했던 설정 하나가 남아있다.

GitOps는 그걸 굉장히 강하게 경계한다.

현재 상태를 사람이 직접 맞추지 말고,
원하는 상태를 선언하고,
시스템이 계속 그 상태를 따라가게 만들자는 흐름.

특히 Kubernetes와 굉장히 잘 맞아떨어진다.

Kubernetes 자체가 이미:
“원하는 상태를 선언하면 시스템이 계속 그 상태를 맞추는 구조”
에 가깝기 때문이다.

읽다 보면 느껴진다.

운영 규모가 커질수록 결국 사람이 기억력과 수동 작업으로 유지하는 시스템은 오래 못 간다는 것.

그리고 GitOps는 그 문제를:
“시스템이 계속 상태를 원래 의도대로 되돌리게 만드는 방식”
으로 해결하려는 흐름에 가까웠다.

# GitOps 상태 흐름

Git (Desired State)
        ↓
CD Controller
        ↓
Cluster State
        ↓
Drift Detection
        ↓
자동 복구 / 상태 동기화

5. 결국 흐름은 계속 같은 방향이었다

 

돌이켜보면 지난 10년 정도의 운영 패러다임 변화는 결국 같은 방향으로 움직여왔다.

계속:

• 반복 작업 줄이고,
• 사람 의존 줄이고,
• 상태 일관성 높이고,
• 변경을 더 안전하게 만들고,
• 운영 복잡도를 낮추는 방향.

기술은 계속 바뀌었지만,
핵심 목표는 크게 달라지지 않았다.

그리고 지금도 흐름은 계속 이어지고 있는 것 같다.

아마 앞으로는:

• AI Ops,
• Autonomous Remediation,
• Intent-based Infrastructure,
• Policy-driven Operations

같은 방향으로 더 확장될 가능성이 높다.

근데 결국 그 밑바닥 철학은 비슷하다.

사람이 직접 상태를 맞추는 운영은 규모가 커질수록 한계가 온다.

그리고 현대 운영은 계속:
“사람이 반복 작업을 하는 구조”
에서 벗어나는 방향으로 움직이고 있다는 점.

아마 이게 지난 DevOps 흐름 전체를 관통하는 가장 큰 변화였던 것 같다.