Skip to content

GitOps 개념

개요

배포를 하다 보면 "지금 클러스터에 실제로 뭐가 떠 있는지"가 점점 헷갈려요. 누가 언제 어떤 명령으로 바꿨는지 기록이 안 남잖아요. 이를 뒤집어서, Git 레포지토리가 배포 상태의 단일 진실(Source of Truth)이 되게 하는 운영 방식이 GitOps예요. ArgoCD가 대표적인 GitOps 도구죠.

상위 문서: ArgoCD · 애플리케이션 · 헬스 상태

핵심 개념

선언적(Declarative) 배포. GitOps에서는 운영자가 매번 "이걸 실행해줘"라고 명령하지 않아요. 대신 "최종적으로 이 상태가 되어야 한다"고 매니페스트(원하는 상태)를 레포에 적어 두죠. 프로세스가 그 상태를 계속 따라가요. 이 원하는 상태를 표현하기 위해 Kubernetes 매니페스트를 그대로 두거나, 필요하면 Helm 차트(또는 Kustomize)로 패키징해요.

레포가 단일 진실. 클러스터 상태를 바꾸는 유일한 통로가 레포가 되도록 설계해요. 즉 kubectl apply로 직접 손대지 않아요. 모든 변경은 PR로 리뷰되어 레포에 머지되고, 그게 곧 배포가 돼요. 그래서 감사(audit)와 롤백이 자연스러워져요. "누가 언제 무엇을 바꿨는지"가 Git 히스토리에 남아요.

끌어오기(Pull) 방식. 기존 CI가 변경을 클러스터로 "밀어 넣는(push)" 느낌이라면, GitOps 에이전트(ArgoCD)는 레포를 지속적으로 "당겨서(pull)" 비교하고 맞춰요. CI(빌드)와 CD(배포)의 책임이 분리되고, 배포 주체가 클러스터 안에 있어서 외부 접근 권한이 줄어드는 장점도 있어요.

원하는 상태(Desired) vs 현재 상태(Actual). GitOps의 핵심 루프는 두 상태를 비교하는 일이에요. 레포에 적힌 원하는 상태와 클러스터의 실제 상태가 다르면, 도구가 실제를 원하는 쪽으로 되돌려요. 누가 kubectl로 실수로 지워도, 다음 동기화에서 레포 상태로 복구돼요.

버전 관리·재현성. 레포 브랜치(예: main, staging)에 따라 환경이 나뉘고, 각 배포는 정확한 이미지 버전을 가리키므로 완전히 재현 가능해요. 잘못 배포됐다면 Git에서 해당 커밋을 되돌리는 것만으로 롤백돼요.

실제 적용(데이터스케쳐스)

우리 클러스터의 원하는 상태를 전부 Git 레포에서 관리해요. GitHub Actions는 이미지 빌드·push까지만 하고 끝나요. 그다음 ArgoCD가 레포를 보고, 원하는 상태와 클러스터 상태를 맞춰요. 배포는 kubectl로 하지 않고 모두 이 GitOps 흐름을 타요. 그래서 "최근에 뭐가 배포됐나"가 Git 히스토리로 확인 가능하고, 되돌리기도 Git revert로 끝나요.

GitOps가 우리에게 가져다 주는 실질적인 변화를 짚어 볼게요. 첫째, 배포 기록이 코드가 된다는 점이에요. 누가 언제 무엇을 바꿨는지가 커밋으로 남아, "이게 왜 바뀌었지?"라는 질문에 레포 히스토리가 답해요. 둘째, 논의와 배포가 한 흐름이 돼요. 상태 변경은 PR을 통해 리뷰를 거친 뒤 머지되므로, 코드 리뷰가 곧 배포 리뷰예요. 셋째, 복구가 결정적이에요. 잘못 배포됐다면 해당 커밋을 되돌리는 것만으로 이전 상태로 되돌아가요. 넷째, 환경 간 일관성이 생겨요. 같은 레포의 다른 브랜치·경로를 개발과 운영이 각각 가리키므로, 두 환경이 같은 방식으로 배포되고 차이를 Git에서 바로 비교할 수 있어요.

단, GitOps는 만능 도구가 아니에요. 상태 변화가 잦고 즉각 반영이 필요한 실시간성 작업에는 잘 맞지 않을 수 있어요. 그래서 우리는 배포라는 "상태 선언"에는 GitOps를, 빌드 같은 "일회성 작업"에는 CI 도구를 나눠 쓰는 책임 분리를 유지해요. 이 구분을 기억해 두면, GitOps가 문제를 풀어야 할 지점과 아닌 지점이 명확해져요.

정리하면, GitOps는 "배포를 누가 기억하는가"에 대한 대답이에요. 사람이나 명령 로그 대신 Git 레포가 기억하고, 도구가 그 상태를 지켜요. 이 철학이 뒷페이지에서 다루는 ArgoCD 동작의 뿌리가 돼요.

더 알아보기