Datacenter & Cloud - 08. Cloud Native 플랫폼

클라우드 네이티브란 무엇인가 — Cloud Native 플랫폼 개관

2013년, Netflix는 자체 데이터센터를 AWS로 완전히 이전했다. 당시에는 "미친 짓"으로 불렸다 — 자기 핵심 인프라를 남에게 맡긴다는 비판이었다. 하지만 Netflix는 — 이전 과정에서 마이크로서비스·Chaos Engineering·자동 배포 같은 기법을 개발했고, 이 기법들이 모여 "클라우드 네이티브(Cloud Native)"라는 패러다임이 됐다. 2026년 — 클라우드 네이티브는 더 이상 선구자의 선택이 아니라 업계의 기본이다. 이 글은 클라우드 네이티브가 무엇인지, CNCF가 왜 만들어졌는지, GitOps와 Service Mesh가 "운영"에 어떤 의미를 갖는지를 다룬다.

이 글은 foundations 06의 IaC 철학과 이전 글(Terraform)의 연장선에 있다. Terraform이 인프라를 코드로 정의한다면 — 클라우드 네이티브는 애플리케이션과 운영 방식 전체를 "클라우드에 맞게" 재설계하는 것이다. Kubernetes의 내부(API·CRD·컨트롤러)는 Kubernetes 서브프로젝트에서 다룬다 — 본 글은 "왜 클라우드 네이티브로 가나"라는 질문에 답한다.

클라우드 네이티브의 정의

클라우드 네이티브(Cloud Native) — CNCF의 정의는 다음과 같다: "클라우드 컴퓨팅 모델의 이점을 최대한 활용하는 애플리케이션을 구축하고 실행하는 접근 방식." 이 정의는 추상적이니 — 구체적으로 풀면 네 가지 핵심이 있다:

1. 마이크로서비스 — 애플리케이션을 작은 독립 서비스로 분해. 각 서비스가 독립적으로 배포·확장·장애 격리. software-architecture 서브프로젝트에서 다룬 개념.
2. 컨테이너 — 애플리케이션과 의존성을 컨테이너로 패키징. 환경 간 이식성. compute-platforms 영역에서 다룬 기술.
3. 동적 오케스트레이션 — Kubernetes 같은 오케스트레이터가 컨테이너를 스케줄링·확장·복구. 사람이 수동으로 "이 서버에 이 컨테이너를 띄워"라고 안 함.
4. 선언적 시스템 — "어떤 상태이어야 한다"를 선언하고, 시스템이 그 상태로 수렴. foundations 06의 IaC와 같은 철학.

flowchart TD
    CN["클라우드 네이티브"] --> MS["마이크로서비스<br/>(독립 배포·확장)"]
    CN --> CT["컨테이너<br/>(이식성·격리)"]
    CN --> ORC["오케스트레이션<br/>(Kubernetes)"]
    CN --> DEC["선언적<br/>(GitOps·IaC)"]

CNCF — 클라우드 네이티브 생태계의 중심

CNCF(Cloud Native Computing Foundation) 는 — 2015년 Linux Foundation 산하로 만들어진 재단. Kubernetes를 기증받아 시작했고, 현재 100개 이상의 프로젝트를 호스팅한다. CNCF는 클라우드 네이티브 생태계의 "표준화 기구"다.

CNCF 프로젝트의 성숙도 단계:

• Sandbox — 초기 단계. 실험적.
• Incubating — 성장 중. 사용자 증가.
• Graduated — 성숙. 프로덕션 준비 완료. Kubernetes·Prometheus·containerd·Envoy·etcd가 이 단계.

CNCF 생태의 주요 프로젝트:

카테고리	프로젝트	역할
오케스트레이션	Kubernetes	컨테이너 스케줄링·관리
컨테이너 런타임	containerd, CRI-O	컨테이너 실행
네트워킹	Cilium, Calico, Istio, Envoy	CNI, 서비스 메시, 프록시
관측성	Prometheus, Grafana, Jaeger, Fluentd	메트릭·대시보드·트레이스·로그
패키징	Helm, Artifact Hub	패키지 관리
CI/CD	ArgoCD, Flux, Tekton	GitOps·파이프라인
보안	Falco, Notary, OPA	런타임 보안·이미지 서명·정책
스토리지	Rook, Longhorn	분산 스토리지

GitOps — Git을 단일 진실의 원천으로

GitOps 는 — Git 저장소가 시스템 상태의 단일 진실의 원천(single source of truth) 이고, 자동화된 프로세스가 Git의 상태를 프로덕션에 동기화하는 운영 모델이다. foundations 06에서 맛보기로 소개했고, 여기서 실천 관점에서 본다.

GitOps의 핵심 원칙:

1. 선언적(Declarative) — 시스템 상태를 코드(YAML)로 선언. 명령적(imperative) 스크립트가 아님.
2. 버전 관리(Versioned) — 모든 변경이 Git 커밋으로. 누가 언제 무엇을 바꿨는지 전부 추적 가능.
3. 자동 동기화(Automated) — Git에 push하면 자동으로 프로덕션에 적용. 수동 kubectl apply 불필요.
4. 지속적 조정(Continuously reconciled) — 소프트웨어 에이전트(ArgoCD·Flux)가 Git과 프로덕션을 지속적으로 비교. drift가 생기면 Git 상태로 복원.

flowchart LR
    DEV["개발자"] -->|git push| REPO["Git 저장소<br/>(선언적 YAML)"]
    REPO --> CI["CI 파이프라인<br/>(테스트·이미지 빌드)"]
    CI --> REPO
    REPO --> CD["ArgoCD / Flux<br/>(자동 동기화)"]
    CD --> K8S["Kubernetes 클러스터<br/>(프로덕션)"]
    K8S -. drift 감지 .-> CD
    CD -. Git으로 복원 .-> K8S

GitOps vs 전통적 배포

특성	전통적 배포 (Jenkins + kubectl)	GitOps (ArgoCD/Flux)
배포 트리거	수동 (또는 CI에서 kubectl)	Git push (자동)
변경 추적	CI 로그 (흩어짐)	Git 히스토리 (한 곳)
권한	CI가 클러스터 권한 필요	ArgoCD/Flux만 권한
롤백	kubectl rollout undo (수동)	git revert (Git에서)
감사	CI 로그 검색	Git blame으로 즉시
drift 감지	없음	자동 (지속적 비교)

Service Mesh — 왜 쓰는가 (운용 관점)

서비스 메시(Service Mesh) 는 — 마이크로서비스 간 통신을 관리하는 인프라 계층이다. Istio·Linkerd·Consul Connect가 대표적. "왜 쓰는가"가 핵심 질문 — 복잡성·오버헤드를 감수하면서까지.

서비스 메시가 해결하는 문제:

1. 트래픽 관리 — "A 서비스 호출의 10%만 새 버전으로" (카나리 배포). 로드 밸런서 없이 메시 규칙으로 분배.
2. 보안 (mTLS) — 서비스 간 통신을 자동 암호화. 각 서비스에 인증서를 발급·회전. foundations 03에서 본 zero trust의 실천.
3. 관측성 — 각 서비스 간 호출의 메트릭·트레이스를 자동 수집. 앱 코드 변경 없이.
4. 회복탄력성 — 서킷 브레이커·재시도·타임아웃을 메시가 자동으로 적용. 앱 코드에 회복탄력성 로직을 넣지 않아도 됨.

서비스 메시는 — 사이드카(sidecar) 패턴으로 구현된다. 각 Pod에 프록시 컨테이너(Envoy)를 붙이고 — 모든 트래픽이 이 프록시를 거친다. 앱은 프록시의 존재를 모른다 — 투명하게 트래픽이 가로채져서(f intercept) 메시 기능이 적용된다.

서비스 메시의 비용

서비스 메시는 무료가 아니다:

• 지연 — 모든 트래픽이 사이드카를 거치니 — 1 ~ 5ms의 추가 지연
• 자원 — 각 Pod에 프록시 컨테이너가 추가되니 — CPU·메모리 오버헤드 (Pod당 100 ~ 500MB)
• 복잡성 — 메시 자체의 설정·관리·업그레이드가 별도의 운영 부담
• 디버깅 — 트래픽이 프록시를 거치니 — "왜 느린가?"를 디버깅할 때 프록시까지 봐야 함

이 비용을 감수할 만큼 서비스 수가 많고(수십 개 이상의 마이크로서비스), mTLS·카나리 배포·분산 트레이스가 필요할 때 — 서비스 메시가 정답이다. 서비스가 3 ~ 5개인 소규모에서는 — 메시 없이 Kubernetes 기본 기능(Service·NetworkPolicy)으로 충분하다.

특성	서비스 메시 없음	서비스 메시 (Istio 등)
mTLS	직접 구현	자동 (모든 통신)
카나리 배포	kubectl로 수동	메시 규칙으로 정밀
분산 트레이스	각 앱에 계측	자동 (사이드카)
서킷 브레이커	앱 코드에 구현	메시 규칙
지연	기본	+1 ~ 5ms
메모리 오버헤드	없음	Pod당 +100 ~ 500MB
적합 규모	소규모 (~5 서비스)	대규모 (10+ 서비스)

Cloud Native는 "설계 철학"이다

클라우드 네이티브는 — 특정 도구(Kubernetes·Istio·Prometheus)가 아니다. 그것들은 도구일 뿐이다. 클라우드 네이티브는 — 설계 철학이다: 애플리케이션을 클라우드의 특성(탄력성·자동화·마이크로서비스)에 맞게 설계하는 것. 이 철학 없이 Kubernetes를 쓰면 — "클러스터 위에서 돌아가는 모놀리스"가 될 뿐이다.

다음 글에서는 — 클라우드 네이티브 환경이 온프레미스와 만나는 지점을 다룬다 — 하이브리드/멀티클라우드. 한 회사가 AWS와 GCP를 같이 쓰거나, 클라우드와 자체 데이터센터를 연결할 때 생기는 문제와 해결책.

Kubernetes가 클라우드 네이티브의 중심인 이유

Kubernetes는 — 클라우드 네이티브 생태계의 "운영체제"로 불린다. 그 이유는 — 컨테이너 오케스트레이션의 표준이기 때문이다. 사용자가 "nginx 컨테이너 3개를 띄우고, CPU가 80%면 자동으로 5개로 늘려라"라고 선언하면 — Kubernetes가 그 상태를 유지한다(self-healing). 컨테이너가 죽으면 자동 재시작. 노드가 장애 나면 다른 노드로 이동. 이 "선언 → 수렴" 모델이 — foundations 06의 IaC와 같은 철학이다.

Kubernetes의 핵심 추상화:

• Pod — 컨테이너의 그룹 (한 노드에서 함께 실행)
• Deployment — Pod의 복제본 수를 관리 (3개 유지)
• Service — Pod 그룹에 대한 안정적인 네트워크 엔드포인트 (IP가 바껴도 이름으로 접근)
• Ingress — 외부 트래픽을 클러스터로 라우팅 (HTTP 경로별)

이 추상화들 위에 — Helm(패키지 관리)·ArgoCD(GitOps 배포)·Prometheus(관측성)가 얹혀서 — 완전한 클라우드 네이티브 플랫폼을 만든다.

GitOps 실천 — ArgoCD의 동작

ArgoCD는 — Kubernetes 클러스터에 설치되는 컨트롤러다. Git 저장소의 YAML 매니페스트와 클러스터의 실제 상태를 지속적으로 비교한다:

1. 개발자가 Git에 새 버전의 Deployment YAML을 push
2. ArgoCD가 Git 변경을 감지 (또는 webhook으로 알림)
3. ArgoCD가 클러스터에 kubectl apply를 자동 실행
4. ArgoCD가 클러스터 상태가 Git과 일치하는지 지속적으로 확인
5. 누군가 수동으로 kubectl로 변경해도 — ArgoCD가 Git 상태로 되돌림 (drift 자동 수정)

이 과정에서 — 클러스터 접근 권한이 ArgoCD에만 있고 — 개발자는 Git만 다룬다. 보안이 강화된다 (Git 권한 = 배포 권한).

Service Mesh의 사이드카 패턴

서비스 메시의 핵심 기술이 — 사이드카(sidecar) 패턴이다. 각 Pod에 프록시 컨테이너(Envoy)를 추가로 붙인다. 앱 컨테이너와 프록시 컨테이너가 같은 Pod에서 실행되면서 — 네트워크 네임스페이스를 공유한다. 모든 트래픽이 프록시를 거치게 — iptables 규칙으로 트래픽을 가로챈다(intercept).

Pod 내부 구조 (서비스 메시):
┌─────────────────────────────────┐
│  Pod                            │
│  ┌───────────┐  ┌───────────┐  │
│  │ 앱 컨테이너│  │ Envoy     │  │
│  │ (앱 로직)  │←→│ (프록시)  │  │
│  │            │  │ mTLS      │  │
│  │            │  │ retry     │  │
│  │            │  │ metrics   │  │
│  └───────────┘  └───────────┘  │
└─────────────────────────────────┘

앱은 프록시의 존재를 모른다 — "나는 그냥 HTTP 요청을 보냈을 뿐인데" — 프록시가 mTLS 암호화·재시도·메트릭 수집·트래픽 분할을 알아서 한다. 이 "투명성"이 사이드카의 핵심이다.

클라우드 네이티브 도입 시 고려할 점

클라우드 네이티브로 가는 것은 — 도구를 바꾸는 게 아니라 조직과 문화를 바꾸는 일이다:

• 팀 구조 — Conway's 법칙: 시스템 구조는 조직 구조를 따른다. 마이크로서비스는 — 작은 자율 팀이 필요하다.
• 운영 능력 — Kubernetes 운영은 복잡하다. 전담 팀(Platform Engineering) 또는 관리형 서비스(EKS/GKE)가 필요.
• 관측성 투자 — 분산 시스템에서는 — 무엇이 어떻게 동작하는지 보려면 분산 트레이싱(Jaeger)·메트릭(Prometheus)·로그(Loki)가 필수. foundations 05의 observability 글에서 다룬다.
• 점진적 도입 — "전부 마이크로서비스로"가 아니라 — 한 서비스부터 시작해 점진적으로. Strangler Fig 패턴: 모놀리스에서 하나씩 떼어내어 마이크로서비스로 이동.

클라우드 네이티브는 — 도구가 아니라 철학이다. Kubernetes·Istio·Prometheus는 그 철학을 실천하는 도구일 뿐. 핵심은 — 클라우드의 특성(탄력성·자동화·분산)을 활용해 애플리케이션을 설계하는 것. 철학 없이 도구만 쓰면 — "Kubernetes 위의 모놀리스"가 될 뿐이다.

선언적 인프라의 힘 — "원하는 상태"를 코드로

선언적(declarative) 시스템의 핵심은 — "어떻게(how)"가 아니라 "무엇(what)"을 정의하는 것이다. Kubernetes 매니페스트:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-server
spec:
  replicas: 3              # "3개가 있어야 해"
  selector:
    matchLabels:
      app: web
  template:
    spec:
      containers:
      - name: nginx
        image: nginx:1.27
        resources:
          requests:
            cpu: 100m
            memory: 128Mi

이 YAML은 — "nginx 컨테이너 3개를, CPU 100m/메모리 128Mi로"라고 선언한다. Kubernetes가 — 이 상태를 유지한다. 컨테이너가 죽으면 재시작. 노드가 장애 나면 다른 노드로 옮김. 사람이 "컨테이너 2번이 죽었으니 재시작해라"라고 명령할 필요가 없다.

이게 명령적(imperative) 스크립트와 다른 점이다. 명령적은 — "컨테이너를 띄워라, 죽었는지 확인해라, 재시작해라"를 단계별로 코딩해야 한다. 선언적은 — "이 상태가 되어야 한다"고 한 줄로 정의하고 — 시스템이 알아서 수렴한다. foundations 06의 Terraform이 — 인프라 수준에서 선언적이라면 — Kubernetes는 — 애플리케이션 수준에서 선언적이다.

GitOps가 DevOps를 넘어서는 이유

GitOps는 — DevOps의 다음 단계로 불린다. 차이점:

DevOps: CI 파이프라인이 빌드 → 테스트 → 배포를 자동화. 하지만 — 배포 권한이 CI에 있고, 클러스터 접근이 필요하다.
GitOps: Git이 유일한 진실의 원천. 배포 권한이 Git 커밋 권한으로 환원된다. ArgoCD/Flux가 Git을 클러스터에 동기화. CI는 빌드/테스트만 하고, 배포는 GitOps가 한다.

이 분리가 — 보안을 강화한다: 개발자는 Git에 push하기만 하면 되고 — 클러스터 접근 권한이 필요 없다. Git 커밋 히스토리가 곧 배포 히스토리고 — git revert가 곧 롤백이다.

Service Mesh vs Kubernetes 네이티브 기능

"서비스 메시가 필요한가?"는 — 조직 규모와 요구사항에 달려 있다. Kubernetes가 이미 제공하는 기능과 비교하면:

• Service → Pod 간 로드 밸런싱: Kubernetes 기본
• mTLS (서비스 간 암호화): 서비스 메시 필요 (또는 직접 구현)
• 카나리 배포 (트래픽 비율 제어): 서비스 메시가 더 정밀 (Kubernetes는 Deployment 비율로만 가능)
• 분산 트레이싱: 서비스 메시가 자동 (Kubernetes는 앱에 계측 필요)
• 서킷 브레이커: 서비스 메시가 제공 (Kubernetes는 없음)

5개 이하의 서비스, 기본 로드 밸런싱만 필요 → Kubernetes 네이티브로 충분.
10개 이상, mTLS·분산 트레이싱·정밀 트래픽 제어 필요 → 서비스 메시 검토.

클라우드 네이티브는 — 도구(Kubernetes·Istio·Prometheus)가 아니라 철학이다. 핵심은 — 클라우드의 특성(탄력성·자동화·분산)을 활용해 애플리케이션을 설계하는 것. 철학 없이 도구만 쓰면 — "Kubernetes 위의 모놀리스"가 될 뿐이다.

서비스 메시의 미래 — Ambient Mesh

사이드카 패턴의 비용(지연·메모리)을 줄이기 위해 — Istio는 Ambient Mesh(사이드카 없는 메시)를 발표했다(2022). 각 Pod에 사이드카를 붙이는 대신 — 노드당 하나의 ztunnel(L4 프록시)을 두고 — L7 처리가 필요한 서비스만 waypoint(선택적 L7 프록시)를 둔다. 사이드카 100개가 ztunnel 1개로 줄어드니 — 자원 오버헤드가 크게 감소. 2026년 기준 — Ambient Mesh가 Istio의 기본 모델로 자리잡고 있다.

---

참고

• CNCF, "Cloud Native Definition v1.0", 2018 — 클라우드 네이티브 정의. 접근 2026-07-21. URL: https://github.com/cncf/toc/blob/main/DEFINITION.md
• CNCF, "CNCF Landscape" — 클라우드 네이티브 프로젝트 지도. 접근 2026-07-21
• OpenGitOps, "GitOps Principles", CNCF, 2022 — GitOps 원칙. 접근 2026-07-21. URL: https://opengitops.dev/
• Burns, B. et al. "Kubernetes: Up and Running" 3rd ed, O'Reilly, 2022 — Kubernetes 실천. 접근 2026-07-21
• Ihnativ, C. "Cloud Native Patterns", O'Reilly, 2021 — 클라우드 네이티브 설계 패턴. 접근 2026-07-21
• Istio, "Istio Documentation" — 서비스 메시. 접근 2026-07-21. URL: https://istio.io/latest/docs/
• ArgoCD, "ArgoCD Documentation" — GitOps 도구. 접근 2026-07-21. URL: https://argo-cd.readthedocs.io/
• Newman, S. "Building Microservices" 2nd ed, O'Reilly, 2021 — 마이크로서비스 설계. 접근 2026-07-21
• Cloud Native Computing Foundation, "CNCF Annual Survey 2025" — 클라우드 네이티브 도입 현황. 접근 2026-07-21
• Istio, "Ambient Mesh Documentation" — 사이드카 없는 메시. 접근 2026-07-21
• Linkerd, "Linkerd Documentation" — 경량 서비스 메시. 접근 2026-07-21

이 글에서 다룬 클라우드 네이티브의 핵심 — 선언적 인프라(GitOps)와 투명한 트래픽 관리(Service Mesh)는 —
"인프라 관리를 소프트웨어 문제로" 바꾸는 기술이다. 다음 글에서는 하이브리드/멀티클라우드를 다룬다.

• Skelton, M., Pais, M. , IT Revolution, 2019 — 팀 구조와 시스템 구조. 접근 2026-07-21