Notes

Cloud Adoption과 GitOps

Cloud adoption을 단순한 인프라 이전이 아니라 운영 모델 전환으로 보고, GitOps를 통해 desired state, drift detection, rollback, policy, secret 관리까지 함께 설계하는 방식을 정리한다.

Published: Jun 3, 2026
Updated: Jun 3, 2026
Area: Cloud Infrastructure
Type: concept
Series: DevOps Explained
Category: Notes

GitOpsCloud AdoptionCloud NativeDevOpsKubernetesIaCCI/CDDrift Detection

개요

Cloud adoption은 단순히 서버의 위치를 on-premise에서 cloud로 옮기는 일이 아니다. Cloud의 진짜 이점은 더 빠른 provisioning, 자동화된 배포, 재현 가능한 환경, self-healing, autoscaling, observability 기반 운영에서 나온다.

하지만 운영 방식이 그대로라면 cloud로 옮겨도 큰 변화가 생기지 않는다.

기존 서버:
  on-premise VM
  physical server
  manual deployment
  ticket-based operation

cloud migration:
  VM을 cloud VM으로 이동
  storage를 cloud storage로 이동
  database를 managed database로 이동

이 접근은 infrastructure 위치를 바꾸는 데는 도움이 된다. 하지만 단순히 서버가 cloud로 옮겨졌다고 해서 자동으로 cloud-native의 이점이 생기는 것은 아니다.

서버 위치만 cloud로 이동:
  provisioning은 빨라질 수 있음
  하지만 배포 방식은 여전히 수동
  configuration 변경은 ticket 기반
  rollback은 불명확
  drift는 계속 발생
  운영 표준은 환경마다 달라짐

따라서 cloud adoption은 cloud technology 선택과 modern operation practice 도입이 함께 가야 한다.

그중 GitOps는 cloud adoption의 운영 모델을 현대화하는 데 중요한 역할을 한다.

Cloud adoption:
  "어디에서 실행할 것인가?"의 문제만이 아니다.

GitOps:
  "어떻게 변경하고, 검증하고, 배포하고, 복구할 것인가?"의 문제를 다룬다.

핵심을 한 줄로 정리하면 다음과 같다.

Cloud는 실행 위치를 바꾼다.
GitOps는 운영 방식을 바꾼다.
둘이 함께 가야 cloud adoption의 효과가 난다.

Cloud Adoption을 기술 이전으로만 보면 생기는 문제

Cloud adoption을 단순히 기존 workload를 cloud로 옮기는 것으로만 보면 다음과 같은 구조가 된다.

Lift-and-shift:
  기존 VM을 cloud VM으로 이동
  기존 manual deployment 유지
  기존 운영 승인 절차 유지
  기존 configuration drift 유지

이 경우 cloud 비용과 복잡성은 늘어났는데, 운영 방식은 예전과 크게 달라지지 않을 수 있다.

예를 들어 다음 상황을 생각할 수 있다.

기존 환경:
  운영자가 VM에 SSH 접속
  config 파일 수정
  systemctl restart
  장애 시 수동 rollback

cloud 이전 후:
  cloud VM에 SSH 접속
  config 파일 수정
  systemctl restart
  장애 시 수동 rollback

위 구조는 서버 위치만 바뀌었을 뿐, 운영 모델은 거의 그대로다.

Cloud의 핵심 장점은 다음 능력에서 나온다.

- 빠른 provisioning
- 자동 scaling
- self-healing
- immutable artifact
- declarative infrastructure
- automated deployment
- observability 기반 운영
- policy as code
- repeatable environment

하지만 운영 방식이 수동이면 이 장점들이 제대로 발휘되지 않는다.

Cloud를 쓰지만 manual operation이면:
  환경 생성은 빨라져도 배포가 느림
  resource는 동적으로 만들 수 있지만 변경 추적이 약함
  managed service를 써도 configuration drift가 발생
  cloud-native scaling을 해도 release process가 병목

따라서 cloud adoption은 infrastructure migration과 operation modernization이 함께 가야 한다.

전통적 IT 선택과 Cloud-native 대안

전통적인 IT 환경과 cloud-native 환경의 차이는 단순히 제품 이름의 차이가 아니다. 운영 상태를 사람이 직접 기억하고 조작하는가, 아니면 code와 automation으로 관리하는가의 차이다.

영역	전통적 IT 선택	Cloud-native 대안
Compute	physical server, VM	container, Kubernetes, serverless
Deployment	수동 배포, script, ticket 기반 승인	CI/CD, GitOps, automated rollout
Configuration	서버 내부 파일, wiki, 운영자 지식	declarative config, Git, IaC
Scaling	서버 증설 요청, 수동 capacity planning	autoscaling, HPA, serverless scaling
Recovery	backup restore, runbook, manual failover	self-healing, rollback, reconciliation
Release	일정 기반 배포, 대규모 release	small batch, frequent release, canary
Audit	change ticket, 문서, 수동 기록	Git history, pipeline logs, sync history
Environment	dev/test/prod 수동 구성	reproducible environment, template, overlay

핵심 차이는 운영 상태를 사람의 기억과 수동 절차가 아니라 code와 automation으로 관리하는가다.

Traditional IT:
  운영자가 시스템 상태를 알고 있음
  변경은 수동 명령과 ticket으로 처리

Cloud-native:
  Git과 declarative config가 시스템 상태를 표현
  controller와 pipeline이 상태를 자동으로 맞춤

Cloud-native 전환은 platform만 바꾸는 것이 아니라, 변경을 다루는 방식을 바꾸는 일이다.

GitOps가 Cloud Adoption에서 중요한 이유

GitOps는 Git을 desired configuration state의 single source of truth로 사용하는 운영 방식이다.

Cloud adoption에서 GitOps가 중요한 이유는 다음이다.

Cloud는 변경 속도를 높인다.
GitOps는 그 변경을 통제 가능하게 만든다.

Cloud에서는 resource를 빠르게 만들 수 있다.

새 namespace 생성
새 deployment 배포
새 database provision
새 route 생성
새 secret 연결
새 autoscaling policy 적용

하지만 빠르게 만들 수 있다는 것은 빠르게 잘못 만들 수도 있다는 뜻이다.

잘못된 cloud adoption:
  console에서 직접 resource 생성
  임시 설정이 permanent 설정이 됨
  누가 무엇을 바꿨는지 추적 어려움
  dev/staging/prod 차이가 커짐
  rollback 기준이 없음

GitOps는 이 문제를 Git 중심 workflow로 바꾼다.

GitOps:
  변경을 Git commit으로 남김
  PR/MR로 review
  CI/CD로 검증
  controller가 desired state를 반영
  drift가 생기면 감지
  rollback은 Git revert로 수행

즉, cloud adoption에서 GitOps는 다음 질문에 답한다.

어떤 상태가 정답인가?
누가 변경했는가?
변경은 review되었는가?
변경은 언제 적용되었는가?
현재 live state는 Git 상태와 같은가?
문제가 생기면 어디로 되돌릴 것인가?

Cloud Adoption과 GitOps의 관계

Cloud adoption은 “cloud platform을 선택하는 일”이고, GitOps는 “cloud platform을 운영하는 방식”이다.

둘을 분리해서 보면 다음과 같다.

구분	Cloud Adoption	GitOps
핵심 질문	어디에서 workload를 실행할 것인가?	어떤 desired state를 기준으로 운영할 것인가?
대상	compute, storage, network, managed service	configuration, deployment, infrastructure state
변화	infrastructure 위치와 서비스 모델 변화	운영 workflow와 변경 관리 방식 변화
위험	cloud sprawl, cost, misconfiguration	repo 구조, secret 관리, policy 설계
성공 조건	적절한 platform 선택	Git-based workflow와 reconciliation

Cloud adoption만 있고 GitOps가 없으면 다음 문제가 생길 수 있다.

Cloud만 도입:
  resource는 빨리 만들 수 있음
  하지만 변경 추적이 약함
  환경 drift 발생
  수동 배포 반복
  rollback 어려움

GitOps만 있고 cloud adoption이 없더라도 일부 이점은 있다. GitOps는 Kubernetes뿐 아니라 infrastructure와 application configuration에도 적용할 수 있기 때문이다.

하지만 cloud-native 환경에서는 GitOps의 효과가 특히 크다.

Kubernetes:
  declarative API
  controller reconciliation
  namespace/resource model
  manifest 기반 desired state

GitOps:
  Git desired state
  controller pull
  continuous reconciliation
  drift correction

Kubernetes와 GitOps는 모두 desired state와 reconciliation 중심 모델을 사용하기 때문에 서로 잘 맞는다.

GitOps의 기본 원칙

GitOps는 단순히 Git에 YAML을 저장하는 것이 아니다.

GitOps의 핵심 원칙은 다음 네 가지로 볼 수 있다.

1. Declarative
2. Versioned and Immutable
3. Pulled Automatically
4. Continuously Reconciled

1. Declarative

시스템이 어떤 상태여야 하는지를 선언적으로 표현해야 한다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 3
  template:
    spec:
      containers:
        - name: api
          image: registry.example.com/api:a1b2c3d

명령의 순서를 저장하는 것이 아니라, 최종 상태를 저장한다.

Imperative:
  kubectl create
  kubectl scale
  kubectl expose

Declarative:
  replicas: 3
  image: registry.example.com/api:a1b2c3d
  service port: 80

Declarative config는 cloud-native 운영의 기반이다. 시스템 상태가 code로 표현되어야 review, diff, rollback, automation이 가능해진다.

2. Versioned and Immutable

desired state는 version control되어야 하고, 과거 상태로 돌아갈 수 있어야 한다.

commit A:
  image: api:v1

commit B:
  image: api:v2

commit C:
  replicas: 5

이렇게 해야 다음을 알 수 있다.

누가 바꿨는가?
언제 바꿨는가?
무엇이 바뀌었는가?
문제가 생기면 어떤 commit으로 되돌릴 것인가?

또한 artifact도 immutable해야 한다. Git에는 같은 값이 남아 있는데 실제 image 내용이 바뀌면 GitOps의 재현성이 깨진다.

# 비추천
image: my-app:latest

더 나은 방식은 commit SHA나 digest다.

image: registry.example.com/my-app:a1b2c3d

또는 다음처럼 image digest를 사용할 수 있다.

image: registry.example.com/my-app@sha256:...

3. Pulled Automatically

GitOps에서는 cluster 내부 agent나 controller가 Git 상태를 pull한다.

Git repository
  <- GitOps controller가 pull
  -> cluster에 sync

이는 CI server가 cluster에 직접 push하는 방식과 다르다.

구분	Push-based CD	Pull-based GitOps
실행 주체	외부 CI/CD server	cluster 내부 controller
cluster credential	CI server가 보유	controller가 cluster 내부에서 보유
상태 기준	pipeline 실행 결과 또는 Git	Git desired state
drift 감지	별도 구현 필요	controller가 지속적으로 감지
multi-cluster	CI가 여러 cluster credential 관리	각 cluster가 필요한 state를 pull

Pull 방식은 production cluster credential을 외부 CI system에 넓게 배포하지 않아도 된다는 장점이 있다.

4. Continuously Reconciled

Git에 저장된 desired state와 실제 cluster state를 계속 비교한다.

Git desired state:
  replicas = 3

Cluster live state:
  replicas = 5

GitOps controller:
  drift 감지
  desired state로 복구

이 원칙 때문에 GitOps는 cloud adoption에서 drift와 수동 변경 문제를 줄이는 데 도움이 된다.

Kubernetes controller가 Deployment desired state와 실제 Pod 상태를 맞추듯이, GitOps controller는 Git desired state와 cluster live state를 맞춘다.

Kubernetes controller:
  Kubernetes resource desired state
  -> actual Pod/Service 상태 조정

GitOps controller:
  Git desired state
  -> cluster live state 조정

Cloud Adoption에서 자주 생기는 Drift 문제

Cloud 환경에서는 resource를 만드는 방법이 많다.

cloud console
CLI
Terraform
Kubernetes manifest
Helm
operator
CI/CD pipeline
수동 script

이 다양성은 편리하지만, 동시에 drift를 만들 수 있다.

예를 들어 다음 상황이다.

Git:
  replicas: 3

운영자가 급하게 수정:
  kubectl scale deployment api --replicas=10

결과:
  live state와 Git desired state가 달라짐

또는 cloud console에서 security group, route, database parameter를 직접 수정할 수도 있다.

문제:
  Git에는 변경 기록 없음
  누가 바꿨는지 불명확
  다른 환경에는 반영되지 않음
  다음 배포에서 덮어써질 수 있음

GitOps는 이런 drift를 줄이는 운영 모델이다.

변경 원칙:
  console에서 직접 바꾸지 않는다.
  Git에 desired state를 수정한다.
  PR/MR로 review한다.
  automation이 반영한다.
  live state와 desired state 차이를 계속 감지한다.

이 방식은 cloud adoption에서 빠른 변경과 통제 가능한 변경을 동시에 추구한다.

GitOps와 Cloud-native Productivity

Cloud adoption의 목적은 단순히 cloud bill을 내는 것이 아니다. 목적은 더 빠르고 안전하게 software를 제공하는 것이다.

GitOps가 cloud-native productivity에 기여하는 방식은 다음과 같다.

GitOps 요소	생산성 효과
Git source of truth	현재 운영 상태를 Git에서 확인 가능
PR/MR workflow	변경 review와 승인 흐름 표준화
Declarative config	환경 재현성이 좋아짐
Automated sync	수동 배포 작업 감소
Drift detection	수동 변경과 환경 차이 조기 발견
Git revert rollback	rollback 경로 단순화
Audit trail	compliance와 변경 추적이 쉬워짐
Environment overlay	dev/staging/prod 차이 관리

Cloud에서는 resource 생성 자체는 쉬워진다. 하지만 운영 상태가 흩어지면 오히려 복잡성이 커진다.

GitOps 없는 cloud:
  빠르게 만들 수 있지만,
  무엇이 정답인지 모를 수 있음

GitOps 있는 cloud:
  빠르게 만들고,
  Git에 선언된 정답을 기준으로 운영할 수 있음

Traditional IT에서 Cloud-native로 넘어갈 때의 변화

Cloud-native 전환은 여러 계층에서 동시에 일어난다.

Server에서 Container로

전통적 환경에서는 application이 VM이나 physical server 위에 직접 설치되는 경우가 많다.

VM:
  OS patch
  runtime 설치
  application binary 복사
  systemd service 등록

Cloud-native 환경에서는 container image가 배포 단위가 된다.

Container:
  runtime과 dependency를 image에 포함
  immutable artifact로 registry에 저장
  Kubernetes가 pod로 실행

이 변화의 핵심은 artifact가 명확해진다는 점이다.

전통적 서버:
  서버 안에 무엇이 설치되어 있는지 확인 필요

Container:
  image tag/digest가 실행 단위

Manual Deployment에서 GitOps Deployment로

전통적 배포는 사람이 명령을 실행하거나 script를 돌리는 방식일 수 있다.

scp artifact
ssh server
restart service
check log

GitOps에서는 Git repository의 desired state가 바뀌고, controller가 이를 반영한다.

Git commit
  -> PR review
  -> merge
  -> GitOps controller sync
  -> rollout

Static Capacity에서 Elastic Capacity로

전통적 환경에서는 capacity planning이 긴 주기를 가질 수 있다.

서버 구매
rack 설치
network 연결
VM 생성
application 배포

Cloud-native 환경에서는 resource를 더 빠르게 늘리고 줄일 수 있다.

replicas 증가
HPA 설정
node autoscaling
serverless scaling

하지만 scaling policy도 Git으로 관리해야 한다.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api
spec:
  minReplicas: 3
  maxReplicas: 20

Ticket 중심 Change에서 PR 중심 Change로

전통적 운영에서는 변경 요청이 ticket으로 관리되는 경우가 많다.

Change ticket:
  운영자 승인
  수동 배포
  결과 문서화

GitOps에서는 Git workflow가 변경 절차의 중심이 된다.

Pull Request:
  변경 diff 확인
  reviewer 승인
  CI 검증
  merge
  controller sync

이 방식은 개발자에게 익숙한 workflow를 운영에도 적용한다.

Cloud Adoption에서 GitOps가 줄이는 Risk

Cloud adoption에는 여러 risk가 있다.

- 잘못된 resource 생성
- 보안 설정 누락
- 비용 증가
- 환경 drift
- 수동 변경 누락
- rollback 실패
- team별 운영 방식 차이

GitOps는 이 중 특히 변경 관리와 운영 일관성 risk를 줄인다.

Risk	GitOps로 줄이는 방식
환경 drift	desired state와 live state 비교
수동 변경	Git 변경 원칙과 self-heal
rollback 불명확	Git revert 기반 rollback
audit 부족	Git history와 PR review
설정 누락	policy as code, CI validation
환경별 차이	base/overlay 구조
production 변경 위험	PR approval, branch protection
cluster credential 노출	pull-based controller model

특히 GitOps는 cloud migration 중에 “새 환경을 어떻게 재현할 것인가?”라는 문제에 강하다.

GitOps repo가 있으면:
  새 cluster 생성
  GitOps controller bootstrap
  Git repository 연결
  desired state sync

물론 database data, object storage, secret, external dependency까지 자동으로 해결되는 것은 아니다. 하지만 application과 platform configuration의 재현성은 크게 좋아진다.

GitOps와 IaC의 관계

Cloud adoption에서는 IaC가 중요하다. Terraform, Pulumi, CloudFormation, Kubernetes YAML, Helm chart 등이 대표적이다.

하지만 IaC와 GitOps는 같은 말이 아니다.

구분	IaC	GitOps
핵심	infrastructure를 code로 정의	Git desired state와 live state를 자동으로 reconcile
저장 위치	보통 Git	Git이 source of truth
실행 방식	plan/apply, pipeline, script 등 다양	controller/agent 기반 pull과 continuous reconciliation
Drift 대응	별도 drift detection 필요	모델 자체에 drift detection 포함
예시	Terraform으로 VPC 생성	Argo CD로 Kubernetes app sync

Git에 Terraform code를 저장했다고 해서 자동으로 GitOps가 되는 것은 아니다.

Git + IaC:
  version control은 됨

GitOps:
  desired state를 Git에 저장하고
  agent가 pull하며
  actual state를 계속 reconcile

IaC는 GitOps의 재료가 될 수 있지만, GitOps는 그보다 운영 workflow와 reconciliation model에 가깝다.

GitOps와 CI/CD의 관계

GitOps는 CI/CD를 대체하지 않는다.

Cloud adoption에서 CI/CD와 GitOps는 역할이 다르다.

CI:
  code를 검증하고 artifact를 만든다.

CD/GitOps:
  검증된 artifact version을 desired state로 선언하고 cluster에 반영한다.

예를 들어 다음과 같은 구조가 가능하다.

Developer push
  -> CI pipeline
  -> unit test
  -> image build
  -> image scan
  -> registry push
  -> GitOps repo image tag update
  -> GitOps controller sync

여기서 중요한 점은 GitOps controller가 아무 image나 배포하지 않도록 하는 것이다.

좋은 구조:
  CI에서 test와 scan 통과
  immutable image tag 생성
  GitOps repo update
  review 또는 policy check
  Argo CD/Flux sync

즉, GitOps는 delivery의 끝단만 담당하는 것이 아니라, CI에서 만들어진 artifact와 운영 desired state를 연결하는 방식이다.

GitOps와 Environment Promotion

Cloud adoption에서 dev, staging, production 환경을 어떻게 승격할지 중요하다.

GitOps에서는 환경별 branch나 directory를 사용할 수 있다.

gitops-repo/
  apps/
    my-app/
      overlays/
        dev/
        staging/
        prod/

또는 branch를 사용할 수도 있다.

branches:
  dev
  staging
  prod

Directory 방식은 환경 차이를 한 repository에서 비교하기 쉽다.

dev overlay:
  replicas: 1
  debug logging

prod overlay:
  replicas: 3
  resource limits
  HPA enabled

Promotion은 다음처럼 진행할 수 있다.

1. dev image tag update
2. dev 검증
3. staging overlay에 같은 image tag 반영
4. staging 검증
5. prod overlay에 같은 image tag 반영
6. production sync

이 방식의 장점은 동일한 artifact를 환경별로 승격할 수 있다는 점이다.

build once:
  my-app:a1b2c3d

promote:
  dev -> staging -> prod

Cloud adoption에서 환경마다 새로 build하면 재현성이 떨어질 수 있다. 동일한 artifact를 promotion하는 구조가 더 안전하다.

GitOps와 Policy as Code

Cloud adoption에서 보안과 governance는 중요하다. GitOps는 Policy as Code와 잘 맞는다.

예를 들어 GitOps repository에 들어오는 변경을 다음 기준으로 검사할 수 있다.

- image tag가 latest인지
- container가 root로 실행되는지
- privileged container인지
- resource requests/limits가 있는지
- LoadBalancer service가 public으로 열리는지
- hostPath를 사용하는지
- secret이 평문으로 들어갔는지
- 승인된 registry의 image인지

PR 단계에서 policy check를 수행할 수 있다.

Pull Request:
  manifest lint
  schema validation
  policy check
  security scan

Merge:
  GitOps controller sync

Admission:
  Kubernetes admission controller가 최종 정책 검증

이 구조는 cloud adoption에서 흔한 misconfiguration을 줄이는 데 도움이 된다.

GitOps와 Secret 관리

GitOps에서 가장 조심해야 하는 부분이 secret이다.

Git이 source of truth라고 해서 password, token, private key를 그대로 Git에 넣으면 안 된다.

Git에 평문으로 넣으면 안 되는 것:
  database password
  API token
  kubeconfig
  cloud access key
  private key
  webhook secret

Kubernetes Secret은 base64 encoding일 뿐 암호화가 아니다.

apiVersion: v1
kind: Secret
data:
  password: cGFzc3dvcmQ=

Cloud adoption에서는 secret 관리 전략이 필요하다.

방식	설명
External Secrets	cloud secret manager나 Vault에서 Kubernetes Secret 생성
Sealed Secrets	encrypted Secret을 Git에 저장하고 cluster에서 복호화
SOPS	YAML 안의 secret 값을 암호화
Vault 연동	runtime 또는 controller가 secret 조회
CI/CD secret store	pipeline 단계에서 필요한 credential만 주입

GitOps의 목적은 모든 것을 무조건 Git에 평문으로 넣는 것이 아니다. Git에는 desired state와 reference를 두고, 민감 정보는 안전한 secret backend와 연결하는 것이 좋다.

Cloud Adoption에서 GitOps가 특히 유용한 상황

GitOps는 다음 상황에서 특히 유용하다.

- Kubernetes cluster를 운영한다.
- dev/staging/prod 환경을 나눠야 한다.
- 여러 팀이 같은 platform 위에 application을 배포한다.
- cloud resource와 application config 변경 이력을 추적해야 한다.
- 수동 변경으로 인한 drift가 자주 발생한다.
- production 변경에 review와 approval이 필요하다.
- cluster를 재구축하거나 다른 region으로 복제해야 한다.
- cloud adoption 중 표준 운영 workflow를 만들고 싶다.

반대로 다음 상황에서는 GitOps 도입 효과가 제한적일 수 있다.

- 단일 VM에 단일 app만 수동으로 가끔 배포한다.
- Git workflow가 정착되어 있지 않다.
- declarative config가 전혀 정리되어 있지 않다.
- 모든 변경이 console에서만 이루어진다.
- platform 운영자가 GitOps controller를 관리할 여력이 없다.

GitOps는 도구 하나 설치로 끝나는 것이 아니라 운영 방식의 변화다.

Kubernetes/k3s Homelab에서 적용하기

개인 k3s나 homelab 환경에서도 이 구조는 그대로 적용된다.

Cloud provider를 쓰지 않더라도, Kubernetes를 운영한다면 이미 cloud-native operation의 많은 문제를 경험하게 된다.

homelab에서도 생기는 문제:
  어떤 Helm values로 설치했는지 기억이 안 남
  수동으로 바꾼 IngressRoute가 Git에 없음
  Longhorn 설정이 문서화되어 있지 않음
  Nexus PVC와 backup 정책이 따로 관리됨
  MetalLB IPAddressPool이 수동 적용됨
  cluster 재설치 시 복구 절차가 불명확

GitOps를 적용하면 다음을 Git에 정리할 수 있다.

영역	GitOps 관리 대상
Networking	MetalLB, Traefik, IngressRoute
Storage	Longhorn, StorageClass, backup target
Registry	Nexus, Harbor, Docker Registry
Observability	Prometheus, Grafana, Loki
Apps	Deployment, Service, ConfigMap, HPA
Security	RBAC, ServiceAccount, NetworkPolicy
CI/CD	Tekton Pipeline, Argo CD Application

예시 repository 구조는 다음과 같다.

homelab-gitops/
  clusters/
    k3s-main/
      infrastructure/
        metallb/
        traefik/
        longhorn/
      platform/
        prometheus/
        grafana/
        loki/
      apps/
        nexus/
        internal-api/
        blog/

처음부터 모든 것을 GitOps로 옮기기보다 다음 순서가 현실적이다.

1. namespace와 간단한 stateless app부터 Git에 정리
2. Traefik IngressRoute와 Service를 GitOps화
3. MetalLB 설정을 Git에 정리
4. observability stack values를 Git에 정리
5. Longhorn/Nexus 같은 stateful workload는 backup/restore 전략을 먼저 확정
6. secret은 SOPS, Sealed Secrets, External Secrets 중 하나로 관리

Homelab에서도 GitOps의 장점은 cloud adoption과 동일하다.

- 현재 상태가 Git에 남음
- 재설치와 복구가 쉬워짐
- 수동 변경 drift를 줄임
- 실험과 rollback이 쉬워짐
- 운영 문서가 code와 함께 관리됨

자칫 실수하기 쉬운 부분

Cloud로 옮기면 자동으로 현대화된다고 생각하는 경우

Cloud VM으로 옮겼지만 배포와 운영이 여전히 수동이라면 cloud-native의 이점은 제한적이다.

Cloud migration:
  위치 변경

Cloud-native modernization:
  운영 모델 변경

Git에 YAML만 넣으면 GitOps라고 생각하는 경우

Git에 manifest를 저장하는 것은 시작일 뿐이다. GitOps는 desired state를 pull하고 continuously reconcile하는 automation이 필요하다.

Git에 YAML 저장:
  version control

GitOps:
  version control
  + pull-based automation
  + continuous reconciliation
  + drift detection

Cloud console 수동 변경을 계속 허용하는 경우

Console에서 직접 변경하면 빠르지만, Git에 기록되지 않으면 drift가 된다. 긴급 변경 후에는 반드시 Git에 반영해야 한다.

`latest` tag를 사용하는 경우

GitOps에서 latest는 재현성을 해친다.

image: my-app:latest

더 나은 방식은 commit SHA나 digest다.

image: registry.example.com/my-app:a1b2c3d
image: registry.example.com/my-app@sha256:...

Secret을 Git에 평문으로 넣는 경우

GitOps의 source of truth는 secret 평문 저장소라는 뜻이 아니다. secret은 별도 암호화 또는 external secret manager를 사용해야 한다.

GitOps가 모든 cloud risk를 해결한다고 생각하는 경우

GitOps는 변경 관리와 reconciliation에 강하다. 하지만 cost control, network architecture, IAM 설계, data migration, backup/restore, observability는 별도로 설계해야 한다.

실무 검증 포인트

Cloud adoption과 GitOps를 함께 설계할 때는 다음을 확인해야 한다.

검증 포인트	확인 질문
Cloud adoption 목적	단순 migration인지, 운영 현대화까지 포함하는지 명확한가?
Source of truth	운영 desired state가 Git에 있는가?
Declarative config	infrastructure와 application state가 선언형으로 표현되는가?
Pull/reconcile	controller나 agent가 actual state를 계속 맞추는가?
Drift detection	수동 변경과 live state 차이를 감지하는가?
Environment strategy	dev/staging/prod 구성이 Git으로 구분되는가?
Promotion	동일 artifact를 환경 간 승격하는가?
CI/CD 연결	CI가 test/build/scan 후 GitOps repo를 업데이트하는가?
Immutable artifact	image tag나 digest가 재현 가능한가?
Secret 관리	secret이 Git에 평문으로 저장되지 않는가?
Policy as Code	위험한 cloud/Kubernetes 설정을 PR 단계에서 막는가?
Rollback	Git revert로 안전하게 되돌릴 수 있는가?
Stateful data	database migration과 backup/restore 전략이 있는가?
Observability	deployment 이후 metrics/logs/SLO를 확인하는가?
Governance	branch protection, review, approval, audit trail이 있는가?

Mental Model

Cloud adoption과 GitOps의 관계는 다음 mental model로 이해할 수 있다.

Cloud adoption:
  workload가 실행되는 platform을 현대화한다.

GitOps:
  workload와 infrastructure를 변경하고 운영하는 방식을 현대화한다.

CI/CD:
  code를 검증하고 artifact를 만든다.

GitOps repository:
  deployment와 configuration의 desired state를 저장한다.

GitOps controller:
  desired state와 live state를 비교하고 reconcile한다.

Observability:
  배포 이후 실제 service health를 검증한다.

더 짧게 말하면 다음과 같다.

Cloud:
  빠르게 만들 수 있게 해준다.

GitOps:
  빠른 변경을 추적 가능하고 복구 가능하게 만든다.

정리

Cloud adoption은 cloud 기술을 선택하는 것만으로 완성되지 않는다. GitOps처럼 Git을 source of truth로 삼아 변경·배포·복구·감사를 자동화하는 운영 모델을 함께 도입해야 cloud-native의 생산성과 민첩성 이점을 제대로 얻을 수 있다.

핵심은 다음과 같다.

Cloud adoption은 infrastructure 위치 변경만이 아니라 운영 모델 전환까지 포함해야 한다.
Cloud는 resource를 빠르게 만들 수 있게 하지만, GitOps는 그 변경을 통제 가능하게 만든다.
GitOps는 Git에 desired state를 선언하고, controller가 live state와 지속적으로 reconcile하는 방식이다.
GitOps의 핵심 원칙은 declarative, versioned and immutable, pulled automatically, continuously reconciled다.
GitOps는 cloud adoption에서 drift detection, rollback, audit, environment promotion, governance를 강화한다.
IaC는 GitOps의 재료가 될 수 있지만, Git에 IaC를 저장했다고 자동으로 GitOps가 되는 것은 아니다.
CI/CD와 GitOps는 역할이 다르다. CI는 artifact를 만들고, GitOps는 desired state를 cluster에 반영한다.
latest tag 대신 commit SHA나 image digest를 사용해야 재현성이 좋아진다.
Secret은 Git에 평문으로 저장하지 말고 SOPS, Sealed Secrets, External Secrets, Vault 같은 방식을 사용해야 한다.
GitOps는 cloud risk 전체를 해결하지 않는다. cost control, IAM, network architecture, data migration, backup/restore, observability는 별도로 설계해야 한다.
k3s/homelab에서도 GitOps는 현재 상태 기록, 복구, drift 감소, 운영 문서화에 유용하다.

결국 다음 문장으로 정리할 수 있다.

Cloud는 실행 위치를 바꾼다.
GitOps는 운영 방식을 바꾼다.
둘이 함께 가야 cloud adoption의 효과가 난다.

개요

Cloud Adoption을 기술 이전으로만 보면 생기는 문제

전통적 IT 선택과 Cloud-native 대안

GitOps가 Cloud Adoption에서 중요한 이유

Cloud Adoption과 GitOps의 관계

GitOps의 기본 원칙

1. Declarative

2. Versioned and Immutable

3. Pulled Automatically

4. Continuously Reconciled

Cloud Adoption에서 자주 생기는 Drift 문제

GitOps와 Cloud-native Productivity

Traditional IT에서 Cloud-native로 넘어갈 때의 변화

Server에서 Container로

Manual Deployment에서 GitOps Deployment로

Static Capacity에서 Elastic Capacity로

Ticket 중심 Change에서 PR 중심 Change로

Cloud Adoption에서 GitOps가 줄이는 Risk

GitOps와 IaC의 관계

GitOps와 CI/CD의 관계

GitOps와 Environment Promotion

GitOps와 Policy as Code

GitOps와 Secret 관리

Cloud Adoption에서 GitOps가 특히 유용한 상황

Kubernetes/k3s Homelab에서 적용하기

자칫 실수하기 쉬운 부분

Cloud로 옮기면 자동으로 현대화된다고 생각하는 경우

Git에 YAML만 넣으면 GitOps라고 생각하는 경우

Cloud console 수동 변경을 계속 허용하는 경우

latest tag를 사용하는 경우

Secret을 Git에 평문으로 넣는 경우

GitOps가 모든 cloud risk를 해결한다고 생각하는 경우

실무 검증 포인트

Mental Model

정리

`latest` tag를 사용하는 경우