Notes

Cloud Native DevOps

Cloud Native DevOps를 cloud-native architecture와 DevOps delivery lifecycle의 결합으로 이해하고, container, Kubernetes, managed service, CI/CD, GitOps, observability, scaling, state 분리까지 정리한다.

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

Cloud NativeDevOpsKubernetesCI/CDContainersMicroservicesObservabilityGitOps

개요

Cloud Native DevOps는 cloud-native architecture와 DevOps delivery lifecycle을 함께 다루는 접근이다.

Cloud Native는 애플리케이션을 cloud 환경에서 잘 실행되도록 설계하는 방식이고, DevOps는 그 애플리케이션을 빠르고 안정적으로 build, test, deploy, operate하기 위한 협업과 자동화 방식이다.

Cloud Native는 주로 다음 질문에 답한다.

애플리케이션을 어떤 구조로 만들 것인가?
어떤 runtime과 infrastructure 위에서 실행할 것인가?
어떻게 scale-out하고 장애를 견딜 것인가?
어떻게 cloud의 managed service를 활용할 것인가?

DevOps는 다음 질문에 답한다.

이 애플리케이션을 어떻게 build할 것인가?
어떻게 test할 것인가?
어떻게 배포할 것인가?
어떻게 rollback할 것인가?
어떻게 운영 feedback을 개발에 반영할 것인가?

따라서 Cloud Native DevOps는 다음처럼 정리할 수 있다.

Cloud Native DevOps:
  cloud-native architecture로 application을 만들고,
  DevOps practices로 build/test/deploy/operate lifecycle을 자동화하는 방식

핵심은 다음이다.

Cloud Native는 application이 cloud를 잘 활용하게 만들고,
DevOps는 그 application을 빠르고 안전하게 계속 바꾸게 만든다.

Cloud Native는 단순히 Cloud에서 실행하는 것이 아니다

가장 흔한 오해는 cloud-native를 “cloud 위에서 실행되는 애플리케이션” 정도로 이해하는 것이다.

하지만 VM을 cloud provider로 옮겼다고 해서 자동으로 cloud-native가 되는 것은 아니다.

Cloud-hosted:
  기존 애플리케이션을 cloud VM에 올림

Cloud-native:
  cloud의 특성을 활용하도록 애플리케이션 구조와 운영 방식을 바꿈

예를 들어 기존 애플리케이션이 다음과 같다고 하자.

단일 monolithic application
  + local filesystem에 파일 저장
  + VM 내부 config 파일 직접 수정
  + 수동 배포
  + 하나의 database에 강하게 결합
  + scale-up 중심 운영

이 애플리케이션을 cloud VM에 그대로 올리면 cloud-hosted는 될 수 있다. 하지만 여전히 다음 문제가 남는다.

- 배포가 수동이면 release 속도가 느림
- application instance를 여러 개 띄우기 어려움
- local filesystem 의존 때문에 stateless scaling이 어려움
- 장애가 나면 사람이 직접 복구해야 함
- configuration이 Git에 남지 않으면 drift가 발생
- test/build/deploy lifecycle이 자동화되어 있지 않음

Cloud-native 전환은 이런 구조를 다음 방향으로 바꾸는 일이다.

- container image를 배포 단위로 사용
- application을 stateless하게 만들거나 state를 외부 service로 분리
- Kubernetes 같은 orchestrator로 scaling과 self-healing 활용
- configuration을 declarative하게 관리
- CI/CD pipeline으로 build/test/deploy 자동화
- observability로 runtime feedback 확보
- managed database, object storage, queue, cache 같은 higher-level service 활용

Cloud-native는 실행 위치의 문제가 아니라 architecture와 operation model의 문제다.

DevOps는 Cloud Native의 운영 엔진이다

Cloud-native architecture를 만들었다고 해서 자동으로 운영이 좋아지는 것은 아니다.

예를 들어 container와 Kubernetes를 도입했지만, 배포가 여전히 수동이라면 다음 문제가 생긴다.

Kubernetes는 있음:
  Deployment, Service, Ingress 사용

하지만:
  image build는 수동
  test는 로컬에서만 실행
  manifest는 운영자가 직접 수정
  kubectl apply는 사람 손으로 실행
  rollback 기준은 불명확

이 경우 cloud-native 기술을 쓰고 있지만, 운영 방식은 cloud-native하지 않다.

DevOps는 여기서 build, test, release, deploy, operate의 흐름을 자동화하고 feedback loop를 짧게 만든다.

Cloud Native DevOps는 다음 구조를 지향한다.

Code
  -> Commit
  -> Automated test
  -> Build container image
  -> Push registry
  -> Deploy to Kubernetes
  -> Observe
  -> Feedback

즉, cloud-native system의 runtime 특징과 DevOps lifecycle automation이 결합되어야 한다.

기존 애플리케이션을 Cloud Native로 옮기는 기본 시나리오

전형적인 출발점은 다음과 같다.

기존 애플리케이션:
  monolithic app
  VM 또는 physical server에서 실행
  local runtime dependency
  manual deployment
  database와 강한 결합
  scaling은 서버 증설 중심

이것을 cloud-native로 바꾸면 다음 단계를 거칠 수 있다.

1. 애플리케이션을 container image로 패키징
2. container registry에 image 저장
3. Kubernetes Deployment로 실행
4. Service로 내부 접근 제공
5. Ingress 또는 Gateway로 외부 traffic 연결
6. ConfigMap/Secret으로 config 분리
7. database, cache, queue, object storage를 managed service로 분리
8. CI/CD pipeline으로 build/test/deploy 자동화
9. observability stack으로 metrics/logs/traces 수집
10. autoscaling과 rolling update, rollback 전략 적용

여기서 중요한 점은 migration이 한 번에 끝나는 작업이 아니라는 것이다.

Lift-and-shift:
  VM을 cloud로 이동

Containerization:
  application을 container image로 패키징

Orchestration:
  Kubernetes에서 실행

Modernization:
  state 분리, service decomposition, managed service 활용

DevOps automation:
  CI/CD, GitOps, observability, policy 적용

즉, cloud-native migration은 기술 이전이 아니라 점진적인 architecture와 operation의 전환이다.

Cloud Native의 핵심 구성 요소

Cloud Native DevOps를 이해하려면 몇 가지 핵심 구성 요소를 나눠봐야 한다.

Container

Container는 application code, runtime, library, dependency를 image로 묶어 실행하는 방식이다.

Container image:
  application binary/code
  runtime
  dependency
  config entrypoint
  filesystem layer

Container의 장점은 실행 환경을 명확히 만들 수 있다는 점이다.

개발 환경:
  node:20 image에서 실행

CI 환경:
  같은 Dockerfile로 build

운영 환경:
  같은 image를 Kubernetes에서 실행

전통적인 서버 배포에서는 “서버에 무엇이 설치되어 있는가”가 중요했다. Cloud-native에서는 “어떤 image가 실행되고 있는가”가 중요해진다.

Traditional:
  server state가 중요

Cloud Native:
  image artifact와 deployment state가 중요

Container image는 immutable artifact로 다뤄야 한다. 운영 중인 container 내부를 직접 수정하는 방식은 피해야 한다.

권장:
  Dockerfile 수정
  image rebuild
  tag/digest 고정
  rollout

비권장:
  running container에 접속
  파일 직접 수정
  임시 patch 후 기록 누락

Kubernetes

Kubernetes는 containerized workload를 실행하고 관리하는 orchestrator다. Kubernetes에서 중요한 개념은 desired state다.

예를 들어 Deployment에 다음처럼 선언한다.

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

이 YAML은 다음 뜻이다.

api application을
registry.example.com/api:a1b2c3d image로
3개 replica로 실행하고 싶다.

Kubernetes controller는 실제 cluster state가 이 desired state에 가까워지도록 계속 조정한다.

Cloud Native DevOps에서 Kubernetes가 제공하는 운영 이점은 다음과 같다.

기능	설명
Scheduling	Pod를 적절한 node에 배치
Self-healing	실패한 Pod 재시작, 대체 Pod 생성
Service discovery	Service를 통한 안정적인 endpoint 제공
Rolling update	새 version을 점진적으로 배포
Rollback	이전 ReplicaSet으로 되돌릴 수 있음
Autoscaling	HPA 등을 통한 replica 조정
Declarative API	YAML로 desired state 선언
Extensibility	CRD, Operator, Controller 확장 가능

하지만 Kubernetes가 application bug, 잘못된 DB migration, 잘못된 business logic까지 해결해주지는 않는다. Kubernetes는 platform-level self-healing을 제공하고, application-level correctness는 test와 observability로 확인해야 한다.

Managed Service

Cloud-native approach에서는 모든 것을 직접 운영하지 않고, cloud provider나 platform이 제공하는 higher-level service를 활용한다.

예시는 다음과 같다.

기능	직접 운영	Higher-level service
Database	VM에 DB 설치	Managed DB
Object storage	file server	Object storage
Queue	broker 직접 운영	Managed message queue
Cache	Redis 직접 운영	Managed cache
Identity	자체 auth 구현	Managed IAM/OIDC
Monitoring	직접 구축	Managed monitoring 또는 observability stack

Managed service의 목적은 운영 부담을 줄이고 application logic에 집중하는 것이다.

하지만 managed service를 쓰면 다음도 고려해야 한다.

- vendor lock-in
- network latency
- service quota
- backup/restore 정책
- IAM 권한
- cost
- local/test 환경 재현성

Cloud Native DevOps는 “무조건 managed service를 쓰자”가 아니라, 운영 부담과 control 사이의 trade-off를 판단하는 것이다.

CI/CD Pipeline

Cloud Native DevOps에서 CI/CD pipeline은 핵심이다.

CI:
  code checkout
  unit test
  integration test
  image build
  image scan
  registry push

CD:
  deployment manifest update
  Kubernetes rollout
  smoke test
  canary or blue-green
  observability check

CI/CD가 없으면 cloud-native runtime을 쓰더라도 배포는 느리고 불안정해진다.

CI/CD가 담당해야 하는 것은 단순 build만이 아니다.

검증 대상:
  application code
  dependency
  container image
  Kubernetes manifest
  Helm values
  Kustomize overlay
  security policy
  runtime configuration

Cloud Native DevOps에서는 code와 infrastructure, deployment configuration이 함께 검증되어야 한다.

Monolith에서 Cloud Native로 가는 여러 경로

기존 애플리케이션을 cloud-native로 바꾸는 방식은 하나가 아니다.

Rehost

가장 단순한 방식은 기존 애플리케이션을 거의 그대로 cloud VM에 올리는 것이다.

Rehost:
  on-prem VM -> cloud VM

장점은 빠르다.

장점:
  migration 속도가 빠름
  application code 변경이 적음
  초기 위험이 낮음

단점은 cloud-native 이점이 제한적이다.

단점:
  scaling과 deployment 방식이 그대로일 수 있음
  운영 자동화 이점이 적음
  cloud 비용만 증가할 수 있음

Rehost는 출발점이 될 수 있지만, 최종 목표로 삼으면 cloud-native 효과가 제한된다.

Replatform

일부 구성 요소를 cloud-native service로 바꾸는 방식이다.

Replatform:
  app은 거의 유지
  database는 managed DB로 이동
  file storage는 object storage로 변경
  deployment는 container로 전환

이 방식은 현실적인 중간 단계다.

예를 들어 local file upload를 object storage로 분리하거나, 직접 운영하던 database를 managed DB로 옮길 수 있다.

Before:
  application VM 내부 /uploads에 파일 저장

After:
  object storage bucket에 파일 저장

이렇게 하면 application instance를 여러 개로 늘리기 쉬워진다.

Refactor

애플리케이션 구조 자체를 바꾸는 방식이다.

Refactor:
  monolith 일부를 service로 분리
  stateless API server로 변경
  async queue 도입
  managed cache/object storage 사용
  Kubernetes-native deployment 적용

장점은 cloud-native 이점을 크게 활용할 수 있다는 것이다.

단점은 시간과 비용이 많이 든다.

주의:
  한 번에 전부 microservices로 쪼개면 위험
  domain boundary가 불명확하면 복잡도 증가
  distributed transaction, observability, network failure 문제가 생김

현실적으로는 rehost, replatform, refactor가 섞여 진행되는 경우가 많다.

Build/Test/Deploy Lifecycle

Cloud Native DevOps에서는 build, test, deploy lifecycle을 자동화해야 한다.

Build

Build 단계에서는 source code를 artifact로 바꾼다.

source code
  -> dependency install
  -> compile/build
  -> test
  -> container image build
  -> image tag
  -> registry push

Cloud-native에서는 보통 container image가 핵심 artifact다.

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

주의할 점은 image tag가 재현 가능해야 한다는 것이다.

비추천:
  my-app:latest

권장:
  my-app:a1b2c3d
  my-app@sha256:...

latest tag는 GitOps와 rollback, audit 관점에서 불리하다. 같은 manifest가 시간이 지나며 다른 image를 가리킬 수 있기 때문이다.

Test

Cloud Native DevOps에서 test는 여러 계층으로 나뉜다.

테스트	목적
Unit test	작은 function/module 검증
Integration test	DB, API, queue 등 연동 검증
Contract test	service 간 API 계약 검증
Container test	image 실행 가능성, entrypoint 확인
Security scan	dependency/image 취약점 확인
Manifest validation	Kubernetes YAML, Helm, Kustomize 검증
Smoke test	배포 후 기본 동작 확인
E2E test	주요 user journey 검증
Performance test	latency, throughput, resource 사용 확인

Cloud-native에서는 code만 테스트하면 부족하다.

검증 대상:
  application code
  container image
  Kubernetes manifest
  runtime config
  network route
  scaling policy
  security policy

배포 대상이 Kubernetes라면 manifest validation과 runtime smoke test도 중요한 test 범위가 된다.

Deploy

Deploy 단계에서는 image와 manifest를 runtime에 반영한다.

registry image
  + Kubernetes manifest
  + config
  + secret reference
  -> Kubernetes rollout

Kubernetes Deployment를 쓰면 rolling update가 가능하다.

old ReplicaSet:
  my-app:v1

new ReplicaSet:
  my-app:v2

rollout:
  v2 pod를 점진적으로 늘림
  v1 pod를 점진적으로 줄임

하지만 rollout이 성공했다고 해서 application이 정상이라는 뜻은 아니다.

rollout success:
  Pod가 새 image로 교체됨

application success:
  실제 요청이 정상 처리됨
  latency와 error rate가 정상
  business transaction이 성공

따라서 deploy 이후에도 observability와 smoke test가 필요하다.

Scaling의 의미

Cloud-native migration의 큰 목적 중 하나는 scalability다.

전통적인 scaling은 보통 scale-up 중심이다.

Scale-up:
  더 큰 서버 사용
  CPU/RAM 증설
  vertical scaling

Cloud-native에서는 scale-out이 중요하다.

Scale-out:
  작은 instance를 여러 개 실행
  replica 수 증가
  load balancing
  autoscaling

Kubernetes에서는 다음처럼 replica 수를 조정할 수 있다.

spec:
  replicas: 5

또는 HPA를 사용할 수 있다.

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

하지만 scale-out이 잘 되려면 애플리케이션이 다음 조건을 만족해야 한다.

- 가능한 stateless하게 설계
- session state를 외부 store로 분리
- local filesystem에 중요한 state 저장 금지
- idempotent한 API 설계
- database connection pool 관리
- cache와 queue를 적절히 사용
- graceful shutdown 지원
- readiness/liveness/startupProbe 설정

즉, Kubernetes가 replica를 늘릴 수 있다고 해서 애플리케이션이 자동으로 잘 scale하는 것은 아니다. 애플리케이션 구조가 scale-out 가능해야 한다.

Stateless와 Stateful 분리

Cloud Native DevOps에서 중요한 설계 기준은 stateless와 stateful 분리다.

Stateless Application

Stateless application은 instance 내부에 중요한 상태를 저장하지 않는다.

stateless API server:
  요청 처리
  business logic 실행
  state는 DB/cache/object storage에 저장

장점은 다음과 같다.

- replica 수를 쉽게 늘릴 수 있음
- pod가 죽어도 새 pod로 대체 가능
- rolling update가 쉬움
- load balancing이 단순함

Stateless하게 만들수록 cloud-native runtime이 제공하는 scaling과 self-healing을 더 잘 활용할 수 있다.

Stateful Component

Stateful component는 데이터와 상태를 가진다.

database
message broker
cache
object storage
persistent volume

이들은 migration과 운영이 더 어렵다.

주의:
  backup/restore 필요
  data migration 필요
  replication 필요
  consistency 고려
  storage failure 대응 필요
  version upgrade 전략 필요

Cloud-native approach에서는 가능하면 stateful component를 managed service로 분리하거나, Kubernetes에서 운영할 경우 operator, backup, replication, monitoring까지 함께 설계해야 한다.

Cloud Native DevOps Architecture 예시

기존 애플리케이션을 cloud-native로 전환한 예시 architecture는 다음처럼 볼 수 있다.

User
  -> Ingress / Gateway
  -> Frontend Service
  -> Backend API Service
  -> Managed Database
  -> Object Storage
  -> Message Queue
  -> Cache

Kubernetes 쪽 resource는 다음과 같다.

Namespace
Deployment
Service
Ingress
ConfigMap
Secret
HorizontalPodAutoscaler
ServiceAccount
NetworkPolicy

CI/CD는 다음을 담당한다.

Git repository
  -> CI pipeline
  -> unit/integration test
  -> container image build
  -> image registry push
  -> manifest update
  -> CD/GitOps sync
  -> Kubernetes rollout

Observability는 다음을 담당한다.

Metrics:
  request rate
  error rate
  latency
  CPU/memory
  pod restart

Logs:
  application logs
  access logs
  error logs

Traces:
  service-to-service latency
  database call
  external API call

이 전체가 결합되어야 Cloud Native DevOps라고 할 수 있다.

Cloud Native와 Microservices는 같은 말이 아니다

Cloud-native를 microservices와 동일하게 보는 경우가 많다. 하지만 둘은 같은 말이 아니다.

Cloud Native:
  cloud 환경의 특성을 활용하는 architecture와 운영 방식

Microservices:
  application을 여러 작은 service로 분리하는 architecture style

Microservices는 cloud-native를 구현하는 한 방식일 수 있다. 그러나 cloud-native라고 해서 반드시 처음부터 모든 것을 microservices로 쪼개야 하는 것은 아니다.

오히려 잘못 쪼개면 복잡도가 폭발한다.

잘못된 microservices 전환:
  service boundary가 불명확
  database를 공유
  network call 증가
  distributed transaction 문제
  observability 부족
  배포 dependency 증가

현실적인 cloud-native 전환은 다음처럼 시작할 수 있다.

1. monolith를 containerize
2. CI/CD 자동화
3. config와 secret 분리
4. stateless API 구조로 개선
5. DB/file/session state 외부화
6. 병목이 되는 기능부터 service로 분리
7. observability와 tracing 강화

Microservices는 목표가 아니라 수단이다. 핵심은 loosely coupled, resilient, manageable, observable한 system을 만드는 것이다.

Higher-level Services 활용

Higher-level service는 직접 서버를 설치하고 운영하는 대신, cloud나 platform이 제공하는 관리형 서비스를 사용하는 것을 의미한다.

예를 들어 database를 직접 운영하는 방식과 managed database를 비교할 수 있다.

직접 운영:
  VM에 PostgreSQL 설치
  backup script 작성
  failover 직접 구성
  patch 직접 적용

Higher-level service:
  Managed PostgreSQL 사용
  automated backup
  managed patch
  replication/failover 기능 활용

또는 file upload를 local disk에 저장하던 구조를 object storage로 바꿀 수 있다.

Before:
  /uploads directory에 파일 저장

After:
  object storage bucket에 파일 저장

이렇게 하면 application pod가 여러 개로 늘어나도 파일 상태를 공유할 수 있다.

하지만 managed service는 항상 장점만 있는 것은 아니다.

고려할 점:
  cloud provider 종속성
  network latency
  pricing model
  quota
  region/zone availability
  backup retention
  security/IAM
  local development 대체 환경

Cloud Native DevOps는 “무조건 managed service를 쓰자”가 아니라, 운영 부담과 control 사이의 trade-off를 판단하는 것이다.

Immutable Infrastructure와 Declarative API

Cloud-native의 중요한 특징 중 하나는 immutable infrastructure다.

전통적 방식에서는 running server에 직접 접속해 수정하는 일이 많았다.

SSH 접속
config 수정
package 설치
service restart

이 방식은 빠를 수 있지만 drift를 만든다.

Cloud-native 방식에서는 running instance를 직접 고치기보다, image와 manifest를 바꿔 새 version을 배포한다.

변경:
  Dockerfile 수정
  image rebuild
  manifest update
  rollout

금지에 가까운 방식:
  running container 안에 들어가 직접 수정

Declarative API도 중요하다.

명령:
  지금 이 작업을 해라.

선언:
  시스템이 이 상태가 되도록 유지해라.

Kubernetes는 declarative API와 controller model을 사용한다. 이 구조 덕분에 Cloud Native DevOps에서는 다음이 가능해진다.

- Git에 desired state 저장
- PR로 변경 검토
- controller가 실제 상태를 반영
- drift를 감지하고 복구
- rollback을 Git revert 또는 이전 manifest로 수행

Observability의 역할

Cloud-native 환경에서는 instance가 자주 교체되고, service가 여러 개로 나뉘며, network call이 많아진다.

따라서 단순히 “서버에 접속해서 로그 보기” 방식으로는 부족하다.

Observability는 다음 세 축으로 생각할 수 있다.

축	설명
Metrics	수치 기반 상태: latency, error rate, CPU, memory
Logs	application과 system event 기록
Traces	요청이 여러 service를 거치는 경로와 지연 분석

Cloud Native DevOps에서 중요한 metric은 다음이다.

Golden signals:
  latency
  traffic
  errors
  saturation

Kubernetes 환경에서는 다음도 봐야 한다.

Pod restart count
CrashLoopBackOff
readinessProbe failure
livenessProbe failure
HPA scaling event
node pressure
network error
ingress 5xx

CI/CD와 observability는 연결되어야 한다.

Deploy v2
  -> error rate 증가
  -> p99 latency 증가
  -> rollback 또는 canary abort

즉, DevOps lifecycle은 배포에서 끝나지 않고 runtime feedback으로 이어져야 한다.

GitOps, Tekton, Argo CD와의 연결

Cloud Native DevOps는 Tekton, GitOps, Argo CD 같은 도구들을 포괄하는 더 큰 그림이다.

Tekton:
  build/test/image push

GitOps repo:
  desired deployment state

Argo CD:
  cluster sync/reconcile

Kubernetes:
  workload runtime

Observability:
  runtime feedback

Cloud Native DevOps에서는 다음 flow가 자연스럽다.

Developer push
  -> CI pipeline
  -> test
  -> image build
  -> image scan
  -> registry push
  -> GitOps repo update
  -> Argo CD sync
  -> Kubernetes rollout
  -> observability check

이 구조는 cloud-native의 declarative operation과 DevOps의 automation을 결합한다.

각 도구의 책임은 다음처럼 나눌 수 있다.

영역	담당
Code validation	CI pipeline
Image build	Tekton, GitHub Actions, GitLab CI, Jenkins 등
Image registry	Nexus, Harbor, cloud registry
Desired state	GitOps repository
Deployment reconciliation	Argo CD, Flux
Runtime	Kubernetes
Runtime feedback	Prometheus, Grafana, Loki, tracing stack

Cloud Native 전환에서 자주 실수하는 부분

VM을 Cloud로 옮기고 끝났다고 생각하는 경우

Cloud VM으로 옮겼지만 배포, scaling, monitoring, rollback이 그대로라면 cloud-native 이점은 제한적이다.

Cloud migration:
  위치 변경

Cloud-native modernization:
  architecture와 operation 변경

Container만 만들면 끝이라고 생각하는 경우

Dockerfile을 만들었다고 cloud-native가 되는 것은 아니다.

Containerization:
  packaging 방식 개선

Cloud Native:
  scaling, resilience, observability, automation, declarative operation까지 포함

Kubernetes를 쓰면 자동으로 안정적이라고 생각하는 경우

Kubernetes는 failed container restart, pod replacement, service endpoint update 등 self-healing capabilities를 제공할 수 있다. 하지만 application bug나 잘못된 configuration까지 자동으로 해결하지는 않는다.

모든 것을 Microservices로 쪼개는 경우

Microservices는 복잡성을 줄이기도 하지만, 잘못 도입하면 더 큰 복잡도를 만든다.

주의:
  distributed tracing 필요
  service discovery 필요
  network failure 고려
  version compatibility 필요
  contract testing 필요
  shared database 피해야 함

Observability 없이 배포 자동화만 하는 경우

자동 배포는 빠른 장애 전파로 이어질 수 있다.

자동화만 있고 observability 없음:
  빠르게 배포
  빠르게 장애
  늦게 인지

Cloud Native DevOps는 deployment automation과 runtime feedback을 함께 설계해야 한다.

Stateful Workload를 가볍게 보는 경우

Stateful workload는 stateless service보다 훨씬 신중해야 한다.

주의:
  PVC 삭제
  database schema migration
  backup/restore
  replication lag
  data consistency
  rollback compatibility

Application image rollback만으로 database 변경이 되돌아가지 않는 경우가 많다.

k3s / Homelab 관점에서 적용하기

k3s, Longhorn, MetalLB, Traefik, Nexus, Argo CD, Tekton 같은 구성을 다루는 환경에서도 이 구조는 그대로 적용된다.

Homelab에서도 Cloud Native DevOps는 다음 의미를 가진다.

- application을 container image로 build
- Nexus 같은 registry에 push
- Kubernetes manifest 또는 Helm values를 Git에 저장
- Argo CD로 GitOps sync
- Traefik으로 ingress 노출
- Longhorn으로 storage 관리
- Prometheus/Grafana/Loki로 observability 구성

예시 workflow는 다음과 같다.

1. app repo에 code push
2. Tekton 또는 GitHub Actions로 test/build
3. image를 Nexus registry에 push
4. GitOps repo의 image tag update
5. Argo CD가 k3s cluster에 sync
6. Traefik IngressRoute로 접근
7. Grafana/Loki로 상태 확인

주의할 점은 다음이다.

- Longhorn PVC를 쓰는 stateful workload는 prune에 주의
- Nexus registry credential을 안전하게 관리
- internal IP, token, password는 Git에 넣지 않음
- MetalLB IPAddressPool과 Traefik route도 GitOps로 관리 가능
- 단일 node/소규모 cluster에서는 resource request를 과하게 잡지 않기
- build workload와 runtime workload가 같은 cluster resource를 공유하면 CI가 서비스 성능에 영향 줄 수 있음

즉, homelab에서도 cloud-native는 단순히 Kubernetes를 설치하는 것이 아니라, build/test/deploy/observe까지 이어지는 lifecycle을 만드는 것이다.

실무 검증 포인트

Cloud Native DevOps를 적용할 때는 다음 질문을 확인해야 한다.

검증 포인트	확인 질문
Application packaging	container image가 재현 가능하게 build되는가?
Immutable artifact	`latest` 대신 tag/digest를 사용하는가?
Runtime platform	Kubernetes, serverless, managed runtime 중 무엇을 쓰는가?
Stateless 설계	scale-out 가능한 구조인가?
Stateful 분리	DB, file, session state가 외부화되어 있는가?
Managed service	직접 운영할 것과 managed service를 쓸 것을 구분했는가?
CI pipeline	build/test/image scan/registry push가 자동화되어 있는가?
CD/GitOps	배포 desired state가 Git으로 관리되는가?
Deployment strategy	rolling, blue-green, canary 중 어떤 전략인가?
Config 관리	ConfigMap, Secret, environment별 values가 관리되는가?
Secret 관리	secret이 Git에 평문으로 들어가지 않는가?
Observability	metrics/logs/traces와 alert가 있는가?
Rollback	image rollback과 DB migration rollback이 가능한가?
Autoscaling	HPA, resource requests/limits가 적절한가?
Security	image scan, RBAC, NetworkPolicy, admission policy를 고려했는가?
Homelab resource	build workload가 runtime workload에 영향을 주지 않는가?

Mental Model

Cloud Native DevOps는 다음 mental model로 이해할 수 있다.

Cloud Native:
  architecture와 runtime의 변화

DevOps:
  delivery와 operation workflow의 변화

Cloud Native DevOps:
  두 변화를 결합해
  scalable하고 observable하며 자동화된 software delivery system을 만드는 것

구체적으로는 다음 흐름이다.

Code:
  application source

CI:
  test, build, scan

Container Registry:
  immutable image artifact

GitOps Repository:
  deployment desired state

CD/GitOps Controller:
  desired state와 live state sync

Kubernetes:
  workload scheduling, scaling, self-healing

Managed Services:
  database, object storage, queue, cache

Observability:
  metrics, logs, traces, alert

Feedback:
  runtime signal을 다음 개발과 배포에 반영

정리

Cloud Native DevOps는 기존 애플리케이션을 container, Kubernetes, managed service, declarative configuration, CI/CD, observability를 활용하는 구조로 전환하고, DevOps 원칙으로 build·test·deploy·operate lifecycle을 자동화하여 cloud의 scalability와 agility를 실제 운영 가치로 바꾸는 접근이다.

핵심은 다음과 같다.

Cloud Native는 단순히 cloud에서 실행하는 것이 아니다.
Cloud-hosted와 cloud-native는 다르다.
Cloud Native는 architecture와 runtime의 변화다.
DevOps는 delivery와 operation workflow의 변화다.
Container image는 cloud-native 배포의 핵심 artifact다.
Kubernetes는 desired state 기반으로 workload를 실행하고 조정한다.
Managed service는 운영 부담을 줄이지만 vendor lock-in, IAM, cost, backup을 고려해야 한다.
CI/CD pipeline은 build, test, image build, image scan, registry push, deploy를 자동화한다.
Scaling은 platform 기능만으로 해결되지 않고 application의 stateless 설계가 필요하다.
Stateful component는 backup, restore, migration, replication 전략이 필요하다.
Microservices는 cloud-native의 필수 조건이 아니라 선택 가능한 architecture style이다.
Observability 없이 자동화만 하면 장애도 빠르게 전파될 수 있다.
GitOps, Tekton, Argo CD는 Cloud Native DevOps lifecycle을 구성하는 대표적인 도구 조합이 될 수 있다.
Homelab에서도 container registry, GitOps, ingress, storage, observability를 연결하면 cloud-native DevOps 흐름을 실험할 수 있다.

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

Cloud Native는 application이 cloud를 잘 활용하게 만들고,
DevOps는 그 application을 빠르고 안전하게 계속 바꾸게 만든다.