90DaysOfDevOps (Day 38)

고태규·2025년 11월 16일

devops

DevOps

목록 보기

37/50

해당 스터디는 90DaysOfDevOps
https://github.com/MichaelCade/90DaysOfDevOps
를 기반으로 진행한 내용입니다.

Day 38 - Open Standards: Empowering Cloud-Native Innovation

1. 오픈 스탠다드(Open Standard)

오픈 스탠다드 (Open Standard)란 여러 조직이 특정 도구나 서비스를 만들기 위해 서로 합의한 프로토콜과 형식의 집합이며, 동시에 해당 표준을 만드는 조직들이 직접 개발과 유지보수에 참여하는 개방형 기술 규약이다.

스탠다드 (Standard): 특정 서비스나 도구가 작동하는 방식을 정의하는 보편적으로 합의된 프로토콜과 형식의 집합이다.
오픈 (Open): '오픈 소스'를 의미한다. 즉, 공개된 커뮤니티라면 누구나 이 표준의 개발, 유지보수 및 향후 변경에 참여할 수 있음을 뜻한다.

즉, 오픈 스탠다드는 스탠다드 (표준) 과 오픈 (개방형)을 합친 용어인 것이다.

2. OCI (Open Container Initiative)

클라우드 네이티브 혁명의 시작은 2013년 도커 (Docker)의 등장이었다.

컨테이너 기술 자체는 이전에도 존재했지만, 도커는 이식성 (Portability)과 신속한 배포 및 확장 (Rapid Deployment & Scaling)이라는 강력한 이점을 제공하며 순식간에 사실상의 표준이 되었다.

하지만 곧 도커의 초창기 보안 문제 등의 한계를 지적하며 2014년 CoreOS가 Rocket이라는 새로운 컨테이너 기술을 출시하였으며, 다양한 컨테이너 기술 플랫폼이 등장하게 되었다.

모든 사람이 컨테이너에 대해 이야기하고 모든 사람이 조직에서 컨테이너를 사용하기를 원했고, 이때 생태계 파편화를 막고 더 많은 컨테이너 기술이 개발될 수 있도록 '표준'의 필요성이 제기되었다. 이것이 바로 OCI(Open Container Initiative)이다.

OCI는 2015년 6월, 도커, 코어OS 등 당시의 주요 컨테이너 기업들이 모여 설립한 개방형 거버넌스 구조이다.

OCI의 목적은 "컨테이너 형식 (Format)과 런타임 (Runtime)에 대한 개방형 산업 표준을 만드는 것"이었으며, '궁극적인 목표는 컨테이너 세계화(Container Globalization)'였다.

OCI는 다음과 같은 3가지 핵심 원칙을 기반으로 한다.

구성 가능성 (Composability): 모든 컨테이너는 서로 독립적이면서도 보안성과 이식성을 갖는다.
분산성 (Decentralization): 컨테이너가 실행되는 OS나 환경에 관계없이 동일하게 실행된다.
최소성 (Minimalism): docker run nginx 처럼 간단한 명령어로 컨테이너가 단순한 프로세스로 실행된다.

OCI는 기술적으로 다음 3가지 핵심 명세(Specifications)를 정의하였다.

이미지 명세 (Image Spec):
- 파일 시스템 번들을 OCI 이미지로 패키징하는 방법에 대한 표준
- 도커(Docker), 빌드킷(BuildKit), 파드맨(Podman) 등이 이 표준을 준수하여 이미지를 빌드
런타임 명세 (Runtime Spec):
- OCI 호환 런타임이 이미지를 실행하는 방법 (구성, 실행 환경, 수명 주기)을 정의
- ContainerD, CRI-O, gVisor
배포 명세 (Distribution Spec):
- 컨테이너 이미지를 배포하는 API를 표준화
- 도커 레지스트리 (Docker Hub)의 API V2 프로토콜을 기반으로 하며, 현재 GCR(Google), ECR(AWS) 등 주요 레지스트리가 표준을 따름.

3. Kubernetes Interface

OCI가 컨테이너 세계화를 이룬 후, 클라우드 네이티브 생태계는 컨테이너 오케스트레이션의 시대로 진입한다.

2015년, 쿠버네티스 (Kubernetes)가 1.0 버전을 출시했다. (초기 이름은 Borg)

도커가 개별 VM에서 개별 컨테이너를 실행하는 데 훌륭했다면, 쿠버네티스는 '여러 머신의 집합 (Fleet)'에 걸쳐 수천 개의 컨테이너를 배포하고 관리할 수 있는 오케스트레이터로 사용되었다.

쿠버네티스는 빠르게 CNCF 프로젝트로 합류하며 생태계의 중심이 되었다.

수많은 조직이 쿠버네티스의 기능을 확장하기 위한 다양한 도구를 개발하기 시작했고, 이것이 우리가 아는 압도적인 CNCF 랜드스케이프를 탄생시켰다.

하지만 쿠버네티스 역시 초기에 큰 도전에 직면했다.

문제점 : 초기 쿠버네티스는 도커와 Rocket 런타임만 지원했다.
해당 지원 로직이 쿠버네티스의 핵심 컴포넌트인 Kubelet 소스 코드에 깊이 내재되어 있었다.
결과 :
1. 느린 기능 개발 속도: 런타임의 새로운 기능을 쿠버네티스에 통합하려면, 쿠버네티스 전체 릴리스 주기를 기다려야 했다.
2. 높은 진입 장벽: 새로운 컨테이너 런타임을 만들고 싶은 개발자는 런타임 개발뿐만 아니라 쿠버네티스 소스 코드에 대한 심층적인 지식까지 갖춰야 했다.

이러한 문제들을 해결하기 위해 또다시 표준 인터페이스가 등장했다.

3-1. CRI (Container Runtime Interface)

쿠버네티스 1.5 릴리스와 함께 CRI (Container Runtime Interface)가 도입되었다.

CRI는 kubelet이 클러스터 구성 요소를 재컴파일할 필요 없이 다양한 컨테이너 런타임을 사용할 수 있게 하는 플러그인 인터페이스이다.

CRI는 gRPC API를 통해 kubelet과 Container Runtime 사이의 통신 규약을 정의했다.

[Kubelet] <-> [CRI Plugin] <-> [Container Runtime] 구조가 확립되면서, 이제 누구든 CRI 표준만 준수하면 자신만의 런타임을 쿠버네티스에 쉽게 통합시킬 수 있게 되었다.

3-2. CNI, CSI, SMI, CPI

CRI의 성공은 "왜 여기서 멈춰야 하는가?"라는 질문으로 이어졌다. 쿠버네티스에는 런타임 외에도 네트워크, 스토리지 등 다양한 기능이 필요했기 때문이다.

따라서, 해당 인터페이스 표준 모델은 쿠버네티스의 다른 핵심 기능으로 빠르게 확장되었다.

CNI (Container Network Interface):
- 컨테이너 간 통신을 위한 네트워킹 솔루션을 연동하는 표준
- Cilium, Flannel, WeaveNet
CSI (Container Storage Interface):
- 다양한 스토리지 솔루션을 연동하는 표준
- OpenEBS, Longhorn, Kasten
SMI (Service Mesh Interface):
- 클러스터 트래픽을 관리하는 '서비스 메시' 기술을 연동하는 표준
- Istio, Linkerd, HashiCorp Consul
CPI (Cloud Provider Interface):
- AWS, GCP, Azure 등 각 클라우드 플랫폼에서 쿠버네티스를 실행하기 위한 표준
- EKS, GKE, AKS

4. 오픈 스탠다드가 생태계에 가져온 가치

오픈 스탠다드가 클라우드 네이티브 생태계에 가져온 영향은 3가지 핵심 가치로 요약된다.

벤더(기업)를 위한 혁신 (Innovation for Vendors)
- OCI, CRI, CNI 등의 표준이 통합을 위한 규칙을 모두 정의해 주었다.
- 덕분에 벤더들은 더 이상 어떻게 쿠버네티스와 통합할까를 고민하며 시간을 낭비할 필요가 없어졌다.
- 벤더들은 자신들의 자원을 오롯이 최종 사용자의 문제를 해결하는 핵심 기능 혁신에만 집중할 수 있게 되었다.
최종 사용자를 위한 확장성 (Extensibility for End Users)
- 벤더들이 혁신에 집중한 결과, 기능이 뛰어난 수많은 CNI, CSI 도구들이 탄생했다.
- 최종 사용자는 이 도구들을 기능을 기준으로 쉽게 벤치마킹할 수 있게 되었다.
- 결과적으로 사용자는 자신의 사용 사례에 가장 적합한 최고의 도구를 자유롭게 선택할 수 있는 확장성을 얻었다.
커뮤니티를 위한 상호운용성 (Interoperability for the Community)
- 네트워킹, 스토리지 등 동일한 문제를 해결하는 여러 솔루션이 등장했다.
- 이는 사용자가 단 하나의 도구나 기술에 종속되는 '벤더 락인 (Vendor Lock-in)'을 걱정할 필요가 없어졌음을 의미한다.
- 오픈 스탠다드는 이 모든 도구들이 서로 원활하게 작동하도록 보장하는 접착제 역할을 하며, 커뮤니티 전체의 상호운용성을 극대화했다.

5. 최근 각광받는 표준화 분야

OCI와 쿠버네티스 인터페이스 표준의 성공 이후, 클라우드 네이티브의 표준화 여정은 새로운 영역으로 계속 확장되고 있다.

옵저버빌리티 (Observability) 분야
- 목표: 복잡한 분산 시스템의 상태를 파악하기 위해 계측을 단순화하고, 데이터 집계 비용을 낮추며, 메트릭 (Metrics), 로그 (Logs), 트레이스 (Traces) 등 데이터 형식을 표준화
- 핵심 표준: OpenTelemetry 가 CNCF 프로젝트로서 이 분야의 표준화를 주도하고 있음.

애플리케이션 배포 (Application Deployment) 분야
- 목표: 어떤 플랫폼에서든 애플리케이션 배포 과정을 단순화하고 개발자 경험을 향상
- 핵심 표준: OAM (Open Application Model)이 새로운 애플리케이션 배포 방식으로 주목받고 있는중이다.
- 관련 도구: CNCF 프로젝트인 KubeVela 는 OAM 표준을 따르는 대표적인 구현체이며, Crossplane 역시 코드 작성 없이 클라우드 네이티브 컨트롤 플레인을 구축하는 프레임워크로 각광받고 있다.

고태규

이전 포스트

90DaysOfDevOps (Day 37)

다음 포스트