이 글은 개인 GCP 학습 트랙의 마지막 단계 — (7) ArgoCD 도입과 결정 회고 의 기록이다. 회사 시스템과 무관한 개인 학습. 결과부터 한 줄 spoiler: ArgoCD 가 GitOps 의 가치를 분명히 보여줬지만, 학습 종료 시점에 사용 중단으로 결정. 그 판단 과정과 비용 데이터를 본문에 명시한다. 시리즈 전체 맥락은 opener 글 참고.

이 글의 목적

이 글의 목적은 ArgoCD를 기존 Kubernetes + GKE + GitHub Actions 시스템에 통합하기 위한 구체적인 단계와 그 과정을 통해 얻은 교훈을 공유하는 것입니다.

한눈에 보기

ArgoCD의 설정 파일을 작성하고 ArgoCD에서 이를 인식할 수 있도록 설정하는 과정을 다룹니다. 최종적으로 설정이 올바르게 적용되었는지 확인합니다.

ArgoCD의 연결 절차

이 단계의 목적: ArgoCD 설정을 작성하고 인식하도록 함으로써 Kubernetes 환경과 효율적으로 연동합니다.

1. ArgoCD 관련 설정 파일들을 만든다.
2. 해당 설정을 ArgoCD에서 인식할 수 있도록 만든다.
3. 연결된 설정 정보가 ArgoCD에 잘 적용되었는지 확인한다.

결론

• 개인 PC를 구매해서 모니터링 및 Control 할 수 있도록 구성하기.

삽질

1. GKE의 Cluster 내에서 설치하니 새로운 ArgoCD namespace와 7개 정도의 노드가 발생
2. 그와 동시에 Kubernetes Engine의 사용량과 Monitoring의 사용량 증가
3. ArgoCD의 근본은 외부 Cluster에 kubectl 명령어를 GUI로 실행해주는 것과 외부 Cluster에 질의하여 로그 정보를 가져와 보여주는 것임을 알게됨
4. 그렇기에 결과적으로 Cloud가 아닌 로컬 PC나 저렴한 Instance에서 ArgoCD를 설치한 뒤 GKE의 클러스터와 연결하면 되겠다고 판단됨
5. 저렴한 Instance 보다는 개인용 PC를 한 대 구매해 사용하기로 결정

GKE 내부 설치 vs 외부 운영 — 실제 비용 비교

GKE Cluster 안에 ArgoCD 를 설치하니 새로운 argocd namespace 와 노드 7개 정도가 추가되었다. 며칠 돌려보니 GKE 의 일별 청구액이 명확히 증가했다.

비용 증가의 진짜 원인

예상과 다르게 Cluster 의 컴퓨트 비용 증가보다 monitoring/logging 비용 증가가 컸다. GKE 내 추가된 노드들이 GCP Monitoring 으로 메트릭을 보내고 Cloud Logging 으로 로그를 보내는 게 모두 과금 대상이라, ArgoCD 자체보다 그 주변 부수희 비용이 더 무거웠다.

실측 검증 — ArgoCD 일시 중지 후 비용 변화

이 가설을 검증하려고 ArgoCD 노드를 일시 중지(제거)해 보았다. 그 다음 1~2일의 Billing 화면을 보니 monitoring 비용이 수천 원 단위로 감소한 게 확인됐다. (4-3) 비용 최적화 편의 “어제 하루 690원” 같은 일별 청구액 단위에서, ArgoCD 가 차지하던 비중이 분명히 측정 가능한 크기였다는 뜻.

결론은 분명했다 — ArgoCD 는 GKE Cluster 내부가 아니라 외부 환경 (로컬 PC 또는 저렴한 Instance) 에서 띄우는 게 학습·운영 모두 합리적이다.

ArgoCD 의 본질 — kubectl 의 GUI 라는 깨달음

이 비용 비교를 거치면서 알게 된 점이 있다 — ArgoCD 의 본질은 외부 Cluster 에 kubectl 명령을 GUI 로 실행하고, 외부 Cluster 에 질의해 로그·상태를 가져와 시각화하는 레이어다. 즉 ArgoCD 자체는 Cluster 안에 살 필요가 없다.

이 본질을 받아들이고 보니 두 가지가 정리됐다:

• Cluster 가 ArgoCD 의 라이프사이클을 알 필요가 없다 — Cluster 가 죽거나 다시 만들어져도 ArgoCD 는 따로 살아 있어야 한다 (외부에서 새 Cluster 를 다시 연결).
• ArgoCD 가 Cluster 의 라이프사이클을 결정할 필요도 없다 — ArgoCD 는 명령을 보내고 결과를 시각화할 뿐, Cluster 의 운명을 좌우하지 않는다.

이 깨달음이 “GKE 내부 설치는 잘못된 선택” 이라는 판단의 결정적 근거. 한 줄 정리하면 “ArgoCD 는 Cluster 의 도구지, Cluster 의 일부가 아니다”.

ArgoCD 가 진짜 가치를 준 순간

비용·구조 회고 외에 ArgoCD 가 분명히 의미 있었던 순간이 한 번 있다 — 코드를 git push 했을 때 GitHub Actions 가 build/test 통과 → ArgoCD 가 자동으로 sync 감지 → GKE 에 자동 배포되는 첫 end-to-end 성공 순간이었다.

그 시점까지 매번 kubectl apply -f 를 직접 치고, 이미지를 push 하고, deployment 를 rollout 하는 절차를 손으로 했다. 그게 한 번에 git push 만으로 자동화된 순간 — “이게 GitOps 라는 거구나” 가 머릿속에 명확히 박혔다. 이 한 번의 성공이 ArgoCD 의 핵심 가치를 한 페이지로 설명한 셈.

흔한 함정

• GKE 클러스터 내에서 직접 ArgoCD를 설치하면 리소스 소비가 크게 증가할 수 있습니다.
• 로컬 환경에 설치하여 사용하는 것이 비용 효율적일 수 있습니다.

그럼에도 학습 종료 시점에 사용 중단을 결정한 이유

핵심 가치를 분명히 봤음에도 학습 종료 시점에 ArgoCD 사용 중단을 결정했다. 이유는 두 가지:

1. 개인 학습 환경에서는 자동 배포의 빈도가 낮다 — 회사 환경처럼 하루에 N 번 배포가 일어나는 게 아니라 학습 환경은 며칠에 한 번. ArgoCD 의 가시성 가치가 운영 비용을 정당화하지 못함.
2. 외부 운영 셋업의 추가 투자 시점 — Cloud 가 아닌 외부에서 운영하려면 개인 PC 구매 (Mac mini, NUC 등) 또는 저렴한 Instance 임대가 필요한데, 학습 종료 시점에는 그 추가 투자의 회수 가치가 명확하지 않았다.

그래서 결정 — ArgoCD 는 “필요해지는 시점”까지 보류. GitOps 의 흐름과 가치는 이미 알았으니, 다음 단계 (실제 운영 환경 / 회사 인프라 / 본격적인 사이드 프로젝트) 에서 다시 세팅할 준비는 됐다. 학습의 자산은 “도구” 가 아니라 “흐름의 이해” 였다는 회고.

다음 단계

ArgoCD를 사용하여 실제 배포 자동화를 설정하고 최적화하는 과정을 진행합니다.

---

GKE 인프라 학습 시리즈 (요약본)

1. GKE 인프라 학습 시리즈 시작 (개요·계획)
2. (4-1) K8S를 GKE와 연결
3. GKE에 직접 띄우고 비용 줄이기 (API 서버·K8s 실행·비용 최적화)
4. (6) GitHub Actions
5. (7) ArgoCD (현재 글)
6. 도메인 발급 및 GKE와의 연결

📚 이 시리즈는 네이버 블로그 원본 10편을 요약·정리한 것입니다. 세부 절차를 순서대로 따라 하려면 → 네이버 블로그 원본 시리즈