kubectl apply -f를 매번 직접 입력하고 있나요? Git을 단일 진실 공급원(SSOT)으로 삼아 인프라와 애플리케이션 배포를 자동화하는 GitOps의 개념을 설명합니다. Push vs Pull 방식의 차이, ArgoCD를 이용한 자동화, 비밀 관리(Secrets) 전략, 그리고 누군가 몰래 설정을 바꿨을 때 이를 감지하는 Drift Detection까지 실제적인 관점에서 다뤄봤습니다.
서버를 끄지 않고 배포하는 법. 롤링, 카나리, 블루-그린의 차이점과 실제 구축 전략. DB 마이그레이션의 난제(팽창-수축 패턴)와 AWS CodeDeploy 활용법까지 심층 분석합니다.
새벽엔 낭비하고 점심엔 터지는 서버 문제 해결기. '택시 배차'와 '피자 배달' 비유로 알아보는 오토 스케일링과 서버리스의 차이, 그리고 Spot Instance를 활용한 비용 절감 꿀팁.
내 서버가 해킹당하지 않는 이유. 포트와 IP를 검사하는 '패킷 필터링'부터 AWS Security Group까지, 방화벽의 진화 과정.
왜 넷플릭스는 멀쩡한 서버를 랜덤하게 꺼버릴까요? 시스템의 약점을 찾기 위해 고의로 장애를 주입하는 카오스 엔지니어링의 철학과 실천 방법(GameDay)을 소개합니다.
개발팀에서 이런 대화는 너무나 흔합니다.
A: "어제까지만 해도 잘 돌아가던 서비스가 갑자기 500 에러를 뱉어요!" B: "아, 제가 아까 급해서 운영 서버 들어가서 메모리 설정 좀 바꿨는데..." A: "그거 어디 기록해뒀나요?" B: "아뇨, 그냥
kubectl edit으로 바로 고쳤는데요..."
이게 바로 "구성 표류(Configuration Drift)"의 시작입니다. 서버의 실제 상태(Actual State)가 우리 모르게 조금씩 바뀌어서, 아무도 현재 서버가 정확히 어떤 설정인지 모르는 상태가 되는 것이죠.
이 문제를 해결하기 위해 등장한 개념이 바로 GitOps입니다. 핵심은 간단합니다. "Git에 있는 코드가 곧 서버의 상태다."
GitOps는 단순히 툴 이름이 아니라 방법론입니다. OpenGitOps에서 정의한 4가지 원칙이 있습니다.
기존의 CI/CD 방식(CIOps)과 GitOps의 가장 큰 차이는 누가 배포를 주도하냐입니다.
Jenkins나 GitHub Actions 같은 CI 툴이 "내가 가서 서버에 배포할게!" 하는 방식입니다.
서버 안에 살고 있는 에이전트(ArgoCD, Flux)가 "Git 저장소에 뭐 바뀐 거 있나?" 하고 주기적으로 확인해서 가져오는 방식입니다.
가장 대중적인 GitOps 도구는 ArgoCD입니다. Kubernetes 네이티브라서 설치도 쉽고 UI가 매우 훌륭합니다. ArgoCD를 설정하면 다음과 같은 흐름이 만들어집니다.
deployment.yaml의 이미지 태그를 v1.0에서 v1.1로 수정해서 Git에 푸시합니다.v1.1인데, 지금 클러스터는 v1.0이네? OutOfSync 상태다!"라고 감지합니다.v1.1로 동기화(Sync) 합니다.이 모든 과정이 시각화되어 보이고, 만약 배포가 잘못되면 Git에서 Revert 버튼 한 번만 누르면 ArgoCD가 즉시 이전 버전으로 롤백합니다. 배포와 롤백이 획기적으로 빨라지고 안전해집니다.
graph LR
Dev[개발자] -->|1. PR Merge| Git[Git Repository]
Argo[ArgoCD Agent] -->|2. 감시 (Polling)| Git
Argo -->|3. 동기화 (Sync)| K8s[Kubernetes Cluster]
style Git fill:#f9f,stroke:#333
style Argo fill:#9ff,stroke:#333
style K8s fill:#9f9,stroke:#333
ArgoCD는 3분마다 Git 저장소를 훔쳐봅니다.
"어? Git에는 replicas: 3인데, 지금 클러스터는 replicas: 1이네? 이상하다(Drift 감지)."
그리고 즉시 Git의 상태와 똑같이 맞춰줍니다(Sync).
GitOps를 도입하고 겪은 가장 짜릿한 경험은 자동 치유(Self-Healing)였습니다.
어느 날 신입 개발자가 실수로 운영 서버의 중요한 데플로이먼트를 삭제했습니다.
# 앗... 실수로 삭제!
kubectl delete deployment my-payment-service
나는 비명을 지르며 복구 명령어를 찾고 있었는데, 1분 뒤 슬랙 알림이 왔습니다. "Service is Healthy."
ArgoCD가 "어? Git 명세서에는 이 서비스가 있어야 하는데 실제로 가보니 없네? 내가 다시 만들어야겠다!"라고 판단하고, Git에 있는 설정대로 다시 생성해 버린 겁니다.
우리는 아무것도 안 했습니다. 그냥 ArgoCD가 열일한 거죠. 이제 우리 서버는 불사신이 되었습니다. 누가 와서 서버를 난장판으로 만들어도, ArgoCD가 Git을 보고 다시 원상 복구해 놓으니까요. 이것이 진정한 선언적(Declarative) 인프라입니다.
이전에는 누군가의 PC에서 비밀스럽게 배포가 일어났지만, 이제는 Pull Request(PR)가 곧 배포입니다. "메모리 늘릴게요"라고 PR을 올리면, 리뷰어가 검토하고 승인(Merge)합니다. Merge 버튼을 누르면 그게 곧 배포 시작입니다. 배포 권한 같은 복잡한 관리 없이, Git 권한 관리로 통일되었습니다.
저희는 Kustomize를 사용해서 환경을 관리합니다.
base/에는 공통 설정을 두고, overlays/dev, overlays/prod에서 차이점(CPU, Memory, Replicas 등)만 관리합니다.
ArgoCD는 각 환경에 맞는 폴더를 바라보게 설정해 두면 끝입니다.
GitOps를 도입할 때 가장 큰 고민은 "어떤 도구를 쓸까?"였습니다.
처음에는 Helm을 고려했습니다. Helm은 템플릿 방식이라 변수({{ .Values.image }})만 갈아 끼우면 되니 편해 보였습니다.
하지만 YAML 파일이 복잡해질수록 템플릿 문법이 난해해졌고, "렌더링 하기 전에는 결과를 알 수 없다"는 점이 불안했습니다.
반면 Kustomize는 순수한 YAML을 겹쳐서(Overlay) 패치하는 방식입니다.
저희 팀은 "직관성"을 위해 Kustomize를 선택했습니다. Git에 올라간 파일이 곧 최종 결과물이라는 철학에 더 잘 맞았기 때문입니다.
Flux CD도 훌륭하지만, 저희는 ArgoCD를 선택했습니다. 가장 큰 이유는 "예쁜 UI" 때문이었습니다.
ArgoCD는 현재 클러스터 상태를 시각적인 그래프로 보여줍니다. 개발자들이 터미널에서 kubectl을 치지 않아도, 웹 대시보드만 보면 "아, 지금 내 앱이 배포 중이구나", "Pod가 하나 죽었구나"를 직관적으로 알 수 있습니다. 이 시각화가 주는 심리적 안정감은 엄청났습니다.
물론 GitOps가 만능은 아닙니다.