리눅스 기초 시리즈의 71번째 시간입니다! 지난 시간에는 서버 인프라가 스스로 몸집을 불리는 클러스터 오토스케일러(CA)를 통해 물리적 한계를 극복하는 법을 배웠습니다. 이제 우리 서버는 트래픽이라는 파도가 몰아쳐도 굳건히 버틸 수 있는 거대한 성이 되었습니다.
하지만 성이 커질수록 관리해야 할 방도 많아지는 법이죠. 수십 대의 서버에 일일이 접속해 코드를 업데이트하고 계신가요? 혹은 '누가, 언제, 무엇을' 변경했는지 몰라 장애가 났을 때 범인을 찾느라 혈안이 되어 있진 않나요? 오늘은 모든 인프라의 상태를 Git에 기록하고, 자동으로 동기화하는 데브옵스의 꽃, GitOps와 그 핵심 도구인 ArgoCD를 저의 경험담과 함께 정리해 보겠습니다.
1. 나의 경험담: "명령어 한 줄의 실수가 불러온 나비효과"
IT 개발자로 일하며 제가 가장 등골이 서늘했던 순간은, 운영 중인 유튜브 자동화 서버의 환경 변수를 수동으로 수정하다가 오타를 냈을 때였습니다. kubectl edit으로 실시간 수정을 하던 중, 쉼표 하나를 잘못 찍는 바람에 전체 서비스가 30분간 중단되었죠. 문제는 제가 무엇을 고쳤는지 기록이 남지 않아 복구하는 데 한참이 걸렸다는 것입니다.
그 사건 이후 저는 '수동 조작'을 완전히 끊기로 결심했습니다. 그리고 도입한 것이 바로 ArgoCD였습니다. 이제 저는 서버에 직접 명령을 내리지 않습니다. 오직 Git 저장소에 "이런 상태가 되어야 해"라고 적어두기만 하죠. ArgoCD는 마치 24시간 감시 카메라처럼 Git과 서버를 대조하며, 1초의 오차도 없이 상태를 일치시킵니다. 이제 저는 주말에 영화 '하빈'을 보러 가서도 서버 걱정 없이 팝콘을 먹을 수 있게 되었습니다. 진정한 자동화는 기술이 아니라 '신뢰'에서 나옵니다.
2. Before: "히스토리 없는 배포와 '클릭옵스'의 굴레"
GitOps 이전의 배포는 '기억'과 '기록'의 싸움이었습니다. 누군가 서버 설정을 바꿨는데 공유를 안 했다면? 다음 배포 때 그 설정은 덮어씌워져 사라지고 맙니다. 이를 'Configuration Drift(구성 드리프트)'라고 부르는데, 관리자가 인프라의 현재 상태를 확신할 수 없는 최악의 상황이죠.
수동 배포의 위험성 (Before):
# 수동으로 리소스 수정
kubectl apply -f deployment.yaml
"앗, 아까 서버에서 직접 고친 설정이 뭐였지?"
기록이 남지 않아 장애 발생 시 롤백이 불가능함
팀원들끼리 "누가 건드렸어?"라며 서로 묻는 상황 발생
(▲ Before: 서버의 실제 상태와 코드상의 상태가 따로 노는 현상이 발생합니다. 배포할 때마다 기도해야 하는 '기우제식 운영'이 반복되죠.)
3. Action: ArgoCD로 '선언적' 배포 환경 구축하기
이제 ArgoCD를 설치하고, 우리 서비스를 Git 저장소와 연결해 보겠습니다. 핵심은 'Application'이라는 커스텀 리소스를 통해 "Git의 특정 폴더를 이 네임스페이스에 동기화해줘"라고 명령하는 것입니다.
ArgoCD 애플리케이션 정의 (app.yaml):
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: youtube-auto-bot
namespace: argocd
spec:
project: default
source:
repoURL: 'https://github.com/myuser/my-infra.git'
targetRevision: HEAD
path: 'manifests/prod' # 배포 파일이 있는 경로
destination:
server: 'https://kubernetes.default.svc'
namespace: production # 실제 서비스가 돌아갈 곳
syncPolicy:
automated: # 자동 동기화 활성화!
prune: true
selfHeal: true # 서버에서 수동으로 바꾸면 자동으로 원복시킴
(▲ Action: kubectl apply -f app.yaml을 실행하는 순간, ArgoCD는 Git 저장소를 읽어와 서버에 리소스를 생성합니다. 누군가 서버에서 몰래 설정을 바꿔도 selfHeal 기능이 즉시 Git 상태로 되돌려 놓습니다.)
4. After: "Git이 곧 법이다 (Source of Truth)"
GitOps를 도입한 뒤, 제 개발 팀의 문화는 '투명함'과 '안정성'을 얻었습니다.
혁신적인 변화들:
- 완벽한 히스토리: 모든 변경 사항이 Git Commit 로그에 남습니다. "누가 포트를 바꿨지?"라고 물을 필요 없이
git log만 보면 됩니다. - 광속 롤백: 장애가 발생하면
git revert한 번으로 단 5초 만에 이전의 안정적인 상태로 복구합니다. - 보안 강화: 이제 개발자들에게 서버(Kubernetes) 접근 권한을 줄 필요가 없습니다. 오직 Git PR(Pull Request) 권한만 있으면 배포가 가능하니까요.
5. 전통적 배포 vs GitOps 비교
| 구분 | kubectl / Click-ops | GitOps (ArgoCD) |
| Source of Truth | 관리자의 로컬 파일 / 기억 | Git 저장소 |
| 배포 방식 | Push (명령어 전송) | Pull (서버가 Git을 당겨옴) |
| 수동 변경 대응 | 방치됨 (드리프트 발생) | 자동 원복 (Self-Healing) |
| 롤백 속도 | 느림 (이전 파일 찾기) | 매우 빠름 (Git Revert) |
6. 마치며: 당신의 코드를 믿으세요.
리눅스 기초 71단계를 거치며 우리는 이제 한 대의 서버를 넘어, 수천 대의 서버도 Git 하나로 통제하는 경지에 올랐습니다. GitOps는 단순히 편리함을 넘어, 인프라를 소프트웨어처럼 다루는 'Immutable Infrastructure(불변 인프라)' 철학의 정점입니다. 여러분의 손맛보다는 여러분이 짠 코드를 믿고, 인프라의 주권을 Git에게 넘겨주세요.
오늘의 인사이트: "가장 훌륭한 배포는 관리자가 배포 버튼을 누르지 않아도 일어나는 배포다."
71번째 이야기를 마칩니다. 이제 우리 인프라는 Git과 하나가 되었습니다. 다음 시간에는 이렇게 수많은 마이크로서비스가 연결될 때, 네트워크의 흐름을 제어하고 보안을 강화하는 '서비스 메시의 끝판왕: Istio로 구현하는 트래픽 제어와 관측성'에 대해 다뤄보겠습니다.
이 글이 여러분의 배포 공포증을 해소하는 데 도움이 되었나요? 혹시 ArgoCD 설치 후 대시보드 비밀번호를 몰라 로그인을 못 하고 계신가요?
ArgoCD 초기 비밀번호 확인법과 CLI 로그인 팁을 다음 포스팅 부록으로 준비해 드릴까요?