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는 단순히 새로운 배포 방식이라기보다,
사람이 기억과 수동 작업으로 유지하던 운영 방식에서 벗어나려는 흐름에 훨씬 가까웠다는 점.
그리고 운영 규모가 커질수록 결국 그 방향으로 갈 수밖에 없겠다는 생각이 꽤 강하게 들었다.
'Reviews > 읽자' 카테고리의 다른 글
| [DevOps] 데브옵스 핸드북 2/e (The DevOps Handbook) (0) | 2026.05.17 |
|---|---|
| [DevOps] 데브옵스 도입 전략 (The DevOps Adoption Playbook) (0) | 2026.05.17 |
| [DevOps] 엔터프라이즈 데브옵스 (DevOps for the Modern Enterprise) (0) | 2026.05.17 |
| RARE 리더쉽 (0) | 2026.02.08 |
| [book] 팀장의 본질 (0) | 2026.02.04 |
댓글