본문 바로가기
Reviews/읽자

[DevOps] GitOps CookBook

by Jany 2026. 5. 17.
반응형

https://www.yes24.com/product/goods/138929285

 

GitOps Cookbook | 나탈리 빈토 | 인사이트(insight) - 예스24

쿠버네티스와 GitHub를 활용한 CI/CD 파이프라인 구축왜 수많은 회사들이 DevOps와 클라우드 네이티브 전략을 위해 GitOps를 채택하고 있을까? 이 안정적인 프레임워크는 쿠버네티스에 애플리케이션

www.yes24.com

운영자가 “현재 서버 상태”를 못 믿게 되는 순간

처음 GitOps라는 단어를 들었을 때는 솔직히 좀 애매했다.

그냥 Kubernetes 배포 방식 중 하나 아닌가 싶었다.

Git에 yaml 넣고,
ArgoCD 같은 걸로 동기화하고,
자동 배포하는 흐름 정도.

근데 『GitOps Cookbook』를 읽다 보니까 생각보다 훨씬 운영 이야기라는 느낌이 강했다.

단순히:
“Git으로 배포합시다”
수준이 아니었다.

오히려 읽다 보면:
“사람이 직접 상태를 관리하는 운영 방식 자체를 줄여나가는 이야기”
처럼 느껴진다.

특히 인상 깊었던 건 이 책이 “현재 상태”보다 “원하는 상태(desired state)”를 훨씬 중요하게 본다는 점이었다.

예전 운영 방식에서는 실제 서버 상태가 기준이 되는 경우가 많았다.

운영자가 직접 들어가서 설정 바꾸고,
긴급 수정하고,
콘솔에서 값 바꾸고,
문제 생기면 SSH 들어가서 대응하고.

근데 그렇게 운영하다 보면 시간이 지날수록 상태가 이상해진다.

문서랑 실제 설정이 다르고,
dev/prod 값 달라지고,
왜 특정 서버만 다르게 동작하는지도 모르게 된다.

운영 오래 하다 보면 진짜 자주 보는 순간이다.

“분명 같은 환경인데 왜 얘만 다르지?”

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

특히 콘솔 수정은 진짜 무섭다.

처음에는:
“급한데 이것만 잠깐 바꾸자”
로 시작한다.

근데 몇 달 지나면 아무도 실제 상태를 확신하지 못하게 된다.

누가 뭘 수정했는지 모르고,
왜 prod만 다르게 동작하는지 모르고,
문서와 실제 상태는 점점 멀어진다.

결국 시스템이 아니라 사람 기억력으로 운영하게 되는 순간이 온다.

이 책은 그걸 굉장히 강하게 경계한다.

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

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

GitOps는 배포 자동화 이야기라기보다:
“운영 드리프트를 어떻게 줄일 것인가”
에 훨씬 가까운 느낌이라는 것.

이 부분이 꽤 공감됐다.

특히 Kubernetes 환경에서는 규모 커질수록 상태 드리프트가 진짜 무섭다.

처음에는 다 비슷하게 시작했는데,
시간 지나면:

  • ingress 옵션 달라지고,
  • namespace 설정 달라지고,
  • 환경변수 달라지고,
  • 리소스 제한 다르고,
  • 운영 중 임시 수정 누적된다.

그러다 보면 어느 순간부터:
“이 클러스터 지금 누가 정확히 이해하고 있지?”
상태가 된다.

실제로 운영하다 보면 가장 무서운 순간이 그거다.

아무도 현재 상태를 확신하지 못하는 순간.

이 책은 계속 Git 기준으로 상태를 되돌리려 한다.

그래서 GitOps에서 Git은 단순 버전관리 도구 느낌이 아니다.

읽다 보면 거의:
“운영 상태의 기준점”
처럼 다뤄진다.

왜냐하면 Git에는 최소한:

  • 변경 이력이 남고,
  • 누가 수정했는지 보이고,
  • 리뷰 가능하고,
  • 롤백 가능하기 때문이다.

즉 운영 상태를:
운영자 기억,
위키 문서,
구두 전달

같은 불안정한 방식 대신,
계속 추적 가능한 형태로 관리하려는 흐름에 가깝다.

이 부분이 꽤 인상 깊었다.

특히 재미있었던 건 GitOps가 생각보다 굉장히 “보수적인 운영 방식”이라는 점이었다.

처음에는 최신 DevOps 트렌드처럼 느껴졌는데,
실제로는:

  • 변경 이력 남기고,
  • 승인 거치고,
  • 상태 일관성 유지하고,
  • 예상 가능한 방식으로 운영하려는 흐름이라

오히려 엔터프라이즈 운영 철학과 닿아있는 부분이 많았다.

다만 차이가 있다면:
사람이 직접 상태를 맞추는 대신,
시스템이 계속 원하는 상태로 되돌리게 만든다는 점 정도.

읽다 보면 운영자의 역할도 조금 달라진다.

예전에는 운영자가:
직접 접속해서 수정하고,
긴급 대응하고,
서버 상태 맞추는 역할에 가까웠다면,

GitOps에서는 점점:
운영 흐름 자체를 설계하고,
선언형 상태를 관리하고,
자동 복구 구조를 만드는 방향으로 이동한다.

약간:
“서버를 관리한다”
보다
“상태 흐름을 관리한다”
에 가까워지는 느낌.

이 변화가 꽤 크게 느껴졌다.

특히 좋았던 건 이 책이 GitOps를 무슨 마법 같은 운영 방식처럼 포장하지 않는다는 점이었다.

오히려 읽다 보면:
운영 규모가 커질수록 결국 사람이 직접 상태를 맞추는 방식은 오래 못 간다는 현실에서 출발하는 느낌이 강하다.

누가 콘솔에서 수정했는지 모르고,
왜 prod만 설정 다른지 모르고,
왜 특정 클러스터만 이상한지 모르는 순간부터 운영 난이도는 급격하게 올라간다.

GitOps는 결국 그 문제를:
“상태를 계속 선언형으로 되돌리는 방식”
으로 해결하려는 흐름처럼 느껴졌다.

그리고 그래서 Kubernetes랑 굉장히 잘 어울린다는 생각도 들었다.

Kubernetes 자체가 이미:
“원하는 상태를 선언하면 시스템이 계속 그 상태를 맞추는 구조”
에 가까우니까.

읽고 나서 가장 크게 남았던 건 이거였다.

GitOps는 단순히 새로운 배포 방식이라기보다,
사람이 기억과 수동 작업으로 유지하던 운영 방식에서 벗어나려는 흐름에 훨씬 가까웠다는 점.

그리고 운영 규모가 커질수록 결국 그 방향으로 갈 수밖에 없겠다는 생각이 꽤 강하게 들었다.

반응형

댓글