이번 글에서는 전통적인 CI/CD 방식의 한계를 극복하기 위해 등장한 GitOps(깃옵스) 패턴과, 최근 GitOps의 단일 진실 공급원(Source of Truth)으로 새롭게 주목받고 있는 OCI(Open Container Initiative) 레지스트리의 개념을 정리해 봅니다.
1. Push형 가고 Pull형 온다: 전통적 CD와 GitOps의 차이
기존의 전통적인 배포 방식(Jenkins, GitLab CI 등)은 가상 머신(VM)이나 서버에 원격으로 접속해 배포 스크립트를 실행하는 Push 방식이었습니다.
- 전통적인 Push 방식: CI/CD 툴이 K8s 클러스터의 API 권한(kubeconfig 등)을 직접 가지고, 밖에서 클러스터 안으로
kubectl apply -f deployment.yaml명령을 밀어 넣는(Push) 형태입니다. - 문제점: 외부의 CI/CD 툴이 클러스터의 막강한 관리자 권한을 상시 보유해야 하므로 보안상 취약점이 생깁니다. 또한 누군가 실무에서
kubectl로 직접 설정을 바꾸면, Git 레포지토리의 코드와 실제 인프라의 상태가 불일치하는 현상이 발생합니다.
이 문제를 해결하기 위해 등장한 개념이 바로 GitOps이며, 이를 구현한 대표적인 오픈소스가 Argo CD와 Flux입니다. GitOps는 Pull 방식을 사용합니다.
- 작동 원리: K8s 클러스터 내부에 배포된 GitOps 에이전트(예: Argo CD)가 지정된 Git 레포지토리를 계속 감시(Polling)합니다. Git에 저장된 YAML 파일과 현재 클러스터의 상태가 다르면, 에이전트가 클러스터 내부에서 스스로 변경 사항을 당겨와(Pull) 싱크를 맞춥니다.
- 장점: 클러스터 외부로 배포 권한을 노출할 필요가 없어 보안이 극대화됩니다. 인프라의 모든 변경 이력이 Git 커밋 로그로 남기 때문에 추적과 롤백이 매우 정교해집니다.
2. "OCI is not Git": 왜 GitOps의 저장소로 OCI를 고민할까?
GitOps 환경이 성숙해지면서, 대규모 인프라를 관리하는 엔지니어들 사이에서 새로운 화두가 던져졌습니다. 바로 "쿠버네티스 명세서(YAML)를 반드시 Git 레포지토리에만 저장해야 하는가?"에 대한 의문입니다.
여기서 등장한 개념이 OCI(Open Container Initiative) 아티팩트 활용입니다.
원래 OCI 레지스트리(예: Docker Hub, AWS ECR, GitLab Container Registry 등)는 'Docker 이미지'를 저장하는 공간이었습니다. 하지만 OCI 스펙이 발전하면서, 이제는 이미지뿐만 아니라 K8s YAML 파일, Helm 차트 등 클라우드 네이티브 환경의 모든 정적 아티팩트를 묶어서 버저닝하고 저장할 수 있게 되었습니다.
💡 Git 저장소 대신 OCI 레지스트리를 활용할 때의 이점
- 대규모 커밋으로 인한 Git 오버헤드: 수백 개의 마이크로서비스가 배포될 때마다 GitOps 배포용 Git 레포지토리에 수많은 자동 커밋이 발생합니다. 이는 Git 서버의 성능 저하와 API 레이트 리밋(Rate Limit) 문제로 이어집니다.
- 보안 및 접근 제어의 한계: 배포 명세서에 접근해야 하는 에이전트가 늘어날수록 Git 레포지토리 자체의 접근 권한 관리가 복잡해집니다.
- 불필요한 변경 이력의 비대화: 소스 코드가 아닌 컴파일된 배포본(YAML 결과물)의 단순 텍스트 변경 이력이 Git 히스토리에 무겁게 쌓이게 됩니다.
이러한 한계를 극복하기 위해, CI 파이프라인에서 렌더링이 완료된 최종 K8s 배포 명세서(YAML)를 OCI 아티팩트 패키지 형태로 빌드하여 이미지 레지스트리에 푸시하고, K8s 클러스터 안의 GitOps 에이전트(Flux 등)는 이 OCI 레지스트리를 '단일 진실 공급원(Source of Truth)'으로 바라보고 동기화하는 아키텍처가 대안으로 부상하고 있습니다.
3. 요약: 현대적인 배포 파이프라인의 모습
결국 배포 자동화의 미래는 "모든 산출물을 OCI라는 표준 규격으로 패키징하고, 클러스터 내부의 에이전트가 이를 안전하게 당겨와 스스로 동기화(GitOps)하는 구조"로 수렴하고 있습니다.