쿠버네티스 배포를 편하게 해준다는 배포 관리 도구를 도입했다가, 몇 달 뒤 전면 걷어내고 ArgoCD로 전환했습니다.
도구 자체의 완성도가 떨어져서가 아닙니다. 도구를 선택할 당시 미처 따져보지 않았던 한 가지 질문이 실제 운영 단계에서 가장 치명적인 문제로 드러났기 때문입니다.
도구를 고를 때 흔히 따지는 기준들
배포 도구를 비교할 때 주로 확인하는 기준은 대개 정해져 있습니다. 지원하는 배포 전략(카나리, 블루그린), 대시보드 UI의 직관성, 권한 관리, 알림 연동, 초기 학습 곡선 등입니다.
이 기준들만 놓고 보면 기존 도구가 훨씬 매력적이었습니다. 대시보드가 깔끔하고, 몇 번의 클릭만으로 배포가 이루어져 처음 접하는 엔지니어도 금방 적응했습니다.
하지만 우리가 간과했던 가장 결정적인 질문은 바로 "설정의 단일 원본(Single Source of Truth)이 어디에 있는가?"였습니다.
왜 '설정의 원본 위치'가 결정적인가
해당 도구는 인프라 설정을 내부 데이터베이스에 보관했습니다. 배포할 때마다 DB에서 매니페스트를 렌더링해 별도의 산출물 Git 저장소로 푸시하고, 클러스터가 그 저장소를 바라보는 구조였습니다.
저장소에 YAML 파일이 커밋되니 겉보기에는 완벽한 GitOps처럼 보였습니다. 커밋 히스토리도 쌓이고 변경 diff도 깔끔하게 보였습니다.
하지만 치명적인 문제는 그 Git 저장소가 인프라 설정의 '입력(원천)'이 아니라, 시스템이 렌더링한 '출력(산출물)'에 불과했다는 점입니다. 사람이 저장소의 YAML을 직접 수정하더라도, 다음 배포 시 DB 데이터가 다시 렌더링되면서 기존 수정을 덮어써 버렸습니다. 심지어 동일 경로를 덮어쓰는 대신 새 버전 디렉터리를 만들고 참조 경로를 변경하는 방식이라, 사람이 고친 내용은 되돌려졌다는 흔적조차 남기지 않고 유실되었습니다.
Git의 형태를 띠고 있었지만, 실제로는 '버전 관리되는 빌드 산출물'에 불과했던 것입니다.
전환을 결심하게 된 두 가지 이유
이러한 구조적 한계를 인지하면서도 당장 배포는 돌아가니 한동안 유지했습니다. 하지만 다음 두 가지 이유로 전환을 더 이상 미룰 수 없었습니다.
- 상태 재현 및 추적 불가: 클러스터가 현재 왜 이 상태인지 Git 저장소만 봐서는 알 수 없었습니다. 진짜 원인은 DB 내부에 갇혀 있었고, 이는 코드 리뷰나 감사 추적의 대상이 되지 못했습니다. 장애 발생 시 "정확히 언제부터 왜 이 설정이었는가"를 규명할 방법이 없었습니다.
- 자동화 도구와의 연동 한계: 인프라 운영에 AI 에이전트나 자동화 스크립트를 연결하려면 클러스터 상태를 코드로 명확히 읽고 수정할 수 있어야 합니다. 설정이 DB에 갇혀 있으면 자동화 도구가 읽을 수 있는 것은 산출물뿐이고, 산출물을 아무리 수정해도 다음 배포 때 무효화됩니다.
특히 두 번째 이유는 앞으로의 인프라 운영 방식 전체를 좌우하는 구조적 한계였기에 전면적인 도구 교체를 결단했습니다.
무중단으로 마이그레이션한 방법
운영 중인 수십 개의 서비스를 멈추거나 새 클러스터를 구축할 수는 없었습니다. 따라서 클러스터는 그대로 유지한 채 배포 파이프라인 엔진만 교체하는 방식을 택했습니다.
전환 전 가장 먼저 검증한 것은 신·구 배포 도구 간의 매니페스트 필드 호환성이었습니다. 양쪽에서 렌더링된 매니페스트를 diff하여 단 하나의 설정 필드도 유실되지 않음을 사전에 증명했습니다. 설정이 누락되면 마이그레이션 한참 뒤에야 원인 모를 런타임 장애로 터지기 때문입니다.
이후 전체 서비스를 한 번에 옮기지 않고, 서비스 단위로 하나씩 순차 편입하며 검증했습니다.
의도적으로 비활성화한 두 가지 편의 기능
ArgoCD를 도입하면서 일반적으로 자주 쓰이는 편의 기능 두 가지를 의도적으로 비활성화했습니다.
- Git에서 삭제된 리소스를 클러스터에서도 자동 삭제하는 기능(Prune): 활성화 시 Git 매니페스트에서 실수로 누락된 오브젝트가 운영 환경에서 즉시 삭제될 위험이 있습니다. 안전을 위해 전 서비스에서 자동 삭제를 비활성화하고 명시적으로 제어하도록 했습니다.
- 업스트림 Helm 차트의 태그(Tag) 기반 참조: 태그는 가변적이므로 외부 저장소의 변경사항이 의도치 않게 운영계로 즉시 흘러들어올 위험이 있습니다. 모든 외부 차트는 불변 식별자인 커밋 해시 단위로 고정했습니다.
추가로, 개발 환경 설정을 복사해 수정하다가 실수로 운영 환경을 덮어쓰는 사고를 방지하기 위해 Helm 렌더링 단계에서 타깃 환경 검증 가드를 두었습니다.
이러한 결정들은 모두 편의성을 일부 양보하더라도 장애 발생 가능성을 원천 차단하기 위한 선택이었습니다.
과거 산출물 저장소는 왜 남겨두었는가
기존 도구가 생성해 둔 산출물 저장소들은 삭제하지 않고 그대로 보존했습니다. 삭제할 경우 과거 배포 이력에 대한 근거가 사라지기 때문입니다.
대신 문서에 "본 저장소는 과거 빌드 산출물이므로 직접 수정하지 말 것"을 명시했습니다. 무조건 지우는 것보다 왜 남아있는지를 명확히 기록해 두는 것이 장기적인 유지보수에 훨씬 안전합니다.
도구 선택의 새로운 기준
이번 경험을 통해 도구 도입 시 가장 먼저 던져야 할 질문이 확립되었습니다.
"이 도구가 다루는 상태의 단일 원본(Single Source of Truth)은 어디에 있는가? 그리고 그 원본을 온전히 Git으로 통제하고 재현할 수 있는가?"
대시보드의 화려함보다 중요한 것은 시스템의 상태를 투명하고 예측 가능하게 제어할 수 있는 구조인가입니다.
이 판단이 달라질 수 있는 경우
- 팀 내에 쿠버네티스 숙련자가 부족한 경우: 직관적인 GUI 도구가 부재 시의 운영 위험을 낮추는 안전장치가 될 수 있습니다.
- 운영하는 서비스가 소규모인 경우: 설정이 몇 개 안 되는 환경에서는 DB 기반 도구라도 복잡도가 낮아 큰 무리 없이 운영할 수 있습니다.
저희는 수십 개의 마이크로서비스를 운영 중이었고 인프라 운영 자동화가 핵심 목표였기에, GitOps 원칙에 철저히 부합하는 ArgoCD 체계로 전환하는 것이 옳았습니다.