이제 나도 클라우드 네이티브 전문가: 쿠버네티스 구축부터 운영 완전 정복

앞서 컨테이너 런타임이 컨테이너를 실행하는 핵심 엔진이라고 말씀드렸죠? 그런데 만약 컨테이너 기술 회사마다 이미지를 만드는 방식, 컨테이너를 실행하는 방식이 제각각이라면 어떨까요? 마치 스마트폰 충전기가 제조사별로 달라 여행갈 때마다 여러 종류의 충전기를 챙겨야 했던 예전처럼, 컨테이너 기술을 사용하는 데 큰 불편함과 비효율이 발생할 겁니다. A라는 도구로 만든 컨테이너 이미지가 B라는 런타임에서는 돌아가지 않고, C라는 오케스트레이션 도구는 A의 이미지만 지원한다면, 기술 선택의 폭은 좁아지고 특정 기술에 종속될 수밖에 없겠죠.

이러한 혼란을 막고 컨테이너 생태계가 건강하게 발전할 수 있도록, 업계의 주요 기업들이 모여 만든 것이 바로 OCI(Open Container Initiative)입니다. OCI는 리눅스 재단(Linux Foundation) 산하의 프로젝트로, 컨테이너 기술의 핵심적인 두 가지 요소, 즉 컨테이너를 실행하는 방법(Runtime)과 컨테이너 이미지를 구성하는 형식(Image Format)에 대한 개방형 표준(Open Standard)을 정의하고 발전시키는 것을 목표로 합니다. 마치 전 세계적으로 통용되는 USB 규격이나 인터넷 프로토콜(TCP/IP)처럼, OCI 표준은 컨테이너 기술의 기본적인 약속이자 질서라고 할 수 있습니다.

이 표준 덕분에 우리는 다양한 도구와 기술들을 마치 레고 블록처럼 자유롭게 조합하여 사용할 수 있게 되었습니다. 이제 OCI가 정의하는 두 가지 핵심 표준 사양에 대해 좀 더 자세히 살펴보며, 이들이 어떻게 컨테이너 기술의 기반을 다지고 있는지 알아보겠습니다.

이제 OCI 표준의 첫 번째 기둥인 OCI 런타임 사양(Runtime Specification)에 대해 좀 더 깊이 파고들어 보겠습니다. 이 사양은 앞서 말씀드린 것처럼, 컨테이너라는 격리된 환경을 실제로 어떻게 만들고 실행할 것인가에 대한 매우 구체적이고 기술적인 약속입니다. 마치 아주 정교하게 작성된 기계 설계도나 상세한 요리 레시피와 같다고 생각하시면 이해가 쉬울 것 같습니다. 이 설계도나 레시피를 따르기만 하면, 누가 만들든 동일한 결과물(여기서는 실행 중인 컨테이너)을 얻을 수 있도록 하는 것이죠.

이 사양의 주된 사용자는 누구일까요? 바로 저수준 컨테이너 런타임(Low-level Container Runtime)입니다. 우리가 흔히 듣는 runc나 crun 같은 도구들이 이 사양을 충실히 구현하는 대표적인 예입니다. 쿠버네티스의 Kubelet이나 containerd, CRI-O와 같은 고수준 컨테이너 관리 도구들은 직접 컨테이너를 실행하는 복잡한 과정을 처리하는 대신, 이 OCI 런타임 사양을 준수하는 저수준 런타임에게 “여기 이 명세서(config.json)와 파일 시스템(rootfs)을 줄 테니, 이대로 컨테이너를 실행시켜 줘”라고 명령을 내립니다. 즉, OCI 런타임 사양은 고수준 관리 도구와 저수준 실행 엔진 사이의 명확한 계약서 역할을 수행하는 셈입니다.

그렇다면 이 중요한 계약서, OCI 런타임 사양은 구체적으로 어떤 내용을 담고 있을까요? 핵심 내용은 크게 두 가지 영역으로 나눌 수 있습니다. 바로 컨테이너의 구성(Configuration)과 생명주기 관리(Lifecycle Operations)입니다.

컨테이너를 실행하기 위해 필요한 모든 세부 설정은 config.json이라는 이름의 JSON(JavaScript Object Notation) 형식 파일에 담기도록 규정되어 있습니다. 이 파일은 컨테이너가 어떤 모습과 상태로 실행되어야 하는 지에 대한 완전한 명세, 즉 ‘청사진’입니다. 저수준 런타임은 이 config.json 파일을 읽어서 그대로 컨테이너 환경을 구성해야 합니다. 이 파일에는 다음과 같은 필수적이고 중요한 정보들이 아주 상세하게 기술됩니다.

OCI Runtime Specification: config.json 컨테이너 구성 항목 상세

이 표는 config.json이 컨테이너의 거의 모든 측면 – 무엇을 실행할지, 어떤 환경에서 실행할지, 어떤 자원을 얼마나 사용할 수 있는지, 어떻게 격리되고 보호될지 – 을 얼마나 상세하고 정교하게 정의하는지를 보여줍니다. 저수준 컨테이너 런타임은 이 ‘설계도’를 충실히 따라서 일관되고 예측 가능한 컨테이너 실행 환경을 구축하는 것입니다.

OCI 런타임 사양은 config.json과 파일 시스템 번들을 이용하여 컨테이너의 상태를 관리하기 위한 표준화된 명령어 집합(operations)도 정의합니다. 모든 OCI 호환 저수준 런타임은 이 명령어들을 동일한 방식으로 이해하고 처리해야 합니다. 이는 마치 VCR 플레이어의 ‘재생’, ‘정지’, ‘되감기’ 버튼처럼, 컨테이너를 제어하는 표준 인터페이스 역할을 합니다. 일반적으로 저수준 런타임은 이 명령어들을 처리하는 커맨드 라인 인터페이스(CLI)를 제공합니다. (예: runc create, runc start 등)

OCI Runtime Specification: 컨테이너 생명주기 명령어(Operations) 상세

표 요약 및 중요 포인트:

• 순서: 일반적인 컨테이너 생성 및 실행 순서는 create → start 입니다.
• 종료: 컨테이너를 종료할 때는 kill (프로세스 종료 요청) → (프로세스 종료 확인) → delete (리소스 정리) 순서로 진행됩니다.
• 상태 확인: state 명령은 전체 생명주기 동안 컨테이너의 현재 상태를 확인하는 데 사용됩니다.
• 표준 인터페이스: 이 명령어들은 저수준 런타임이 제공해야 하는 표준화된 인터페이스로, 어떤 OCI 호환 런타임을 사용하든 고수준 런타임은 동일한 방식으로 컨테이너를 관리할 수 있습니다.
• 저수준 vs 고수준: 사용자가 직접 runc create 같은 저수준 명령어를 사용하는 경우는 드물며, 보통 kubectl run, docker run, ctr run 등의 고수준 명령어를 사용하면 내부적으로 이러한 OCI 생명주기 명령어들이 호출됩니다.

이 표를 통해 컨테이너가 단순히 생성되고 사라지는 것이 아니라, OCI 런타임 사양에 정의된 명확한 상태들과 각 상태를 전환시키는 표준화된 명령어들을 통해 체계적으로 관리된다는 점을 이해하실 수 있기를 바랍니다. 이러한 표준화 덕분에 복잡한 컨테이너 오케스트레이션이 가능해지는 것입니다.

이처럼 OCI 런타임 사양이 컨테이너 구성과 생명주기 관리에 대한 명확하고 상세한 표준을 제시함으로써 얻게 되는 이점은 매우 큽니다.

• 런타임 구현의 다양성 촉진: runc는 OCI의 공식 참조 구현체로서 가장 널리 쓰이지만, 이 표준 덕분에 다른 목표를 가진 저수준 런타임들이 등장할 수 있었습니다. 예를 들어,
  • crun: C 언어로 작성되어 runc(Go 언어)보다 더 가볍고 빠르며 메모리 사용량이 적은 것을 목표로 합니다. 임베디드 환경이나 리소스가 제한적인 환경에 유리할 수 있습니다.
  • kata-containers: 컨테이너마다 경량 가상 머신(VM)을 사용하여 하드웨어 수준의 격리를 제공합니다. 보안이 매우 중요한 워크로드나 신뢰할 수 없는 코드를 실행해야 하는 경우 강력한 보안 경계를 제공합니다. 하지만 성능 오버헤드는 runc보다 클 수 있습니다.
  • gVisor: Google에서 개발한 것으로, 사용자 공간(User-space)에서 자체적인 커널을 구현하여 애플리케이션의 시스템 콜을 가로채 처리합니다. 이를 통해 호스트 커널과의 직접적인 상호작용을 최소화하여 보안을 강화합니다. kata-containers보다는 가볍지만 runc보다는 오버헤드가 있습니다.이처럼 다양한 특성을 가진 런타임들이 OCI 런타임 사양이라는 공통 인터페이스를 따르기 때문에, 사용자나 쿠버네티스는 필요에 따라 이들을 비교적 쉽게 교체하여 사용할 수 있습니다. 마치 표준 규격의 자동차 엔진 마운트 덕분에 가솔린 엔진, 디젤 엔진, 전기 모터 등 다양한 종류의 동력원을 동일한 차체에 탑재할 수 있는 것과 같습니다.
• 고수준 도구와의 명확한 역할 분담: containerd, CRI-O, Docker Engine 같은 고수준 도구들은 이미지 관리, 네트워크 설정, 스토리지 볼륨 연결, 여러 컨테이너 관리 등 복잡한 작업에 집중하고, 실제 컨테이너 실행이라는 저수준 작업은 OCI 호환 런타임에게 위임합니다. 이 명확한 역할 분담과 표준 인터페이스는 전체 시스템의 모듈성을 높이고 각 컴포넌트의 발전을 용이하게 합니다.

결론적으로, OCI 런타임 사양은 눈에 잘 띄지 않는 낮은 수준의 기술 명세처럼 보일 수 있지만, 실제로는 컨테이너 기술의 상호 운용성을 보장하고, 다양한 런타임 혁신을 가능하게 하며, 쿠버네티스와 같은 복잡한 오케스트레이션 시스템이 안정적으로 동작할 수 있도록 하는 매우 중요한 기반 기술입니다. 이 표준화된 약속 덕분에 우리는 오늘날 강력하고 유연한 클라우드 네이티브 환경을 구축하고 운영할 수 있는 것입니다.

OCI 이미지 사양은 “무엇을 실행할지”를 운반하는 표준 패키징 규격이며, 이미지가 어떻게 저장되고 전송되며 검증되는지까지 포함하는 합의입니다. 핵심은 콘텐츠 주소 가능성(Content-Addressable Storage), 표준 JSON 매니페스트, 레이어 기반 파일 시스템, 설정 메타데이터, 그리고 멀티 플랫폼 지원입니다. 아래를 읽으면 빌드 도구, 레지스트리, 런타임 간의 연결 고리가 한눈에 그려질 것입니다.

• Image Manifest: 단일 플랫폼(예: linux/amd64)용 이미지의 “목차”입니다. 어떤 설정(Config)을 쓰고 어떤 레이어(Layers)로 구성되는지를 기술합니다.
• Image Configuration(JSON): 기본 실행 사용자, 환경 변수, Entrypoint, Cmd, ExposedPorts, Volumes, WorkingDir 등 런타임 기본값과 이미지 메타데이터를 담습니다. 또한 rootfs.diff_ids로 “압축 해제된” 레이어 해시를 기록합니다.
• Layers: 변경 사항(changeset)을 담은 tar 아카이브들의 순서 배열입니다. OverlayFS 같은 유니온 파일시스템으로 겹쳐 최종 rootfs를 만듭니다.
• Image Index(선택): 여러 플랫폼용 매니페스트를 하나로 묶는 상위 카탈로그입니다. 동일 태그로 arm64, amd64 등을 동시에 제공하는 멀티플랫폼 이미지를 가능하게 합니다.

간단 예시(요지는 구조 이해):

• Digest가 진리의 원천: 매니페스트, 설정, 각 레이어는 내용 기반 해시(SHA-256 등)로 식별됩니다. “sha256:…” 다이제스트가 곧 ID입니다.
• 신뢰 경로: 레지스트리는 클라이언트 요청 시 다이제스트를 키로 블롭(blob)을 반환합니다. 런타임은 내려받은 바이트를 다시 해시해 매니페스트/레이어의 무결성을 검증합니다.
• 중복 제거와 캐싱: 동일 내용의 레이어는 어떤 이미지든 하나만 저장·전송하면 됩니다. 노드 로컬 캐시에도 다이제스트 키로 보관되어 풀 속도가 빨라집니다.

• Media Types(대표):
  • Manifest: application/vnd.oci.image.manifest.v1+json
  • Config: application/vnd.oci.image.config.v1+json
  • Layer: application/vnd.oci.image.layer.v1.tar(+gzip|+zstd)
• 변경 표현: 레이어 tarball은 파일 추가/변경/삭제를 담습니다. 삭제는 whiteout(.wh.<file>)과 디렉터리용 .wh..wh..opq로 표현합니다.
• 압축: gzip이 일반적이나 zstd도 지원됩니다. zstd는 속도/압축률 모두 우수한 편이라 대형 이미지에 유리합니다.
• Lazy pulling(고급): stargz/estargz, Nydus 등 포맷은 “필요한 파일만 먼저” 스트리밍 받아 콜드 스타트 시간을 크게 줄입니다. OCI는 이러한 최적화 포맷을 별도 mediaType으로 공존시킵니다.

• 런타임 기본값: Entrypoint/Cmd, Env, User, WorkingDir, ExposedPorts, Volumes, StopSignal 등은 “기본 실행 의도”를 담습니다. 최종 실행값은 런타임 옵션으로 덮어쓸 수 있습니다.
• rootfs.diff_ids: 레이어 tar를 “압축 해제한” 콘텐츠 해시 목록입니다. Manifest의 layers.digest(압축본 해시)와 1:1 매핑은 아니므로 혼동 주의.
• history: 어떤 명령으로 레이어가 생겼는지(예: RUN, COPY)가 남습니다. 디버깅과 SBOM 생성에 유용합니다.

• 구조: application/vnd.oci.image.index.v1+json 내 manifests 배열에 각 플랫폼(os, architecture, variant)을 명시한 디스크립터를 나열합니다.
• 선택: 클라이언트(containerd, CRI-O)는 자신의 플랫폼과 일치하는 매니페스트를 자동 선택합니다. 사용자는 동일한 레퍼런스(예: myapp:1.2)를 쓰면 됩니다.

1. 빌드: Dockerfile/BuildKit, Buildah, Kaniko 등으로 레이어 생성 → Config/Manifest 작성 → 로컬 CAS에 저장.
2. 푸시: 레지스트리 API v2로 Blob 업로드(레이어/설정) → Manifest 업로드 → (옵션) Index 업로드.
3. 풀: 클라이언트가 레퍼런스(이름:태그 또는 @다이제스트)로 Manifest/Index 요청 → 일치 플랫폼 Manifest 수신 → Config/Layer 다이제스트로 블롭 요청 → 검증 후 로컬 캐시 저장 → 컨테이너 시작.

• 서명(Signing):
  • Cosign(Sigstore): 키리스 키(키 관리 간소화)와 투명성 로그(Rekor)로 매니페스트 다이제스트를 서명합니다. 정책 엔진(Kyverno, Gatekeeper)과 연계해 “서명·검증 필수”를 강제 가능합니다.
  • Notary v2/OCI Artifacts: 서명을 이미지와 나란히 OCI 아티팩트로 저장·배포하는 표준화가 진행되어, 레지스트리 간 복제·보존이 쉬워집니다.
• SBOM(Software Bill of Materials): SPDX, CycloneDX 형태의 SBOM을 빌드 시 생성해 OCI 아티팩트로 함께 저장하면, 취약점 스캐닝과 라이선스 컴플라이언스가 수월해집니다.
• 취약점 스캔: Trivy, Clair 등과 연계해 레지스트리/CI에서 자동 스캔. “기준 이상 심각도 발견 시 배포 차단” 정책을 둡니다.
• 공급망 보증: SLSA, in-toto 어태스테이션으로 “누가, 언제, 어떤 소스로, 어떤 빌더로 만들었나” 출처를 남깁니다. 매니페스트 다이제스트 기준으로 불변 참조가 핵심입니다.

• 최소 베이스 이미지: distroless, alpine, wolfi 등을 사용해 공격면과 크기를 동시에 감소.
• 레이어 정리: 한 RUN에 패키지 설치·캐시 삭제를 함께 묶고, 자주 바뀌는 파일(COPY 소스)은 아래 레이어에 두지 않습니다(캐시 보존 극대화).
• 사용자/권한: config.User를 루트가 아닌 계정으로 설정하고, 캡빌리티 최소화, readOnlyRootFilesystem를 활용합니다.
• 고정 참조: 배포 시 태그 대신 다이제스트(@sha256:…)를 써서 동일 아티팩트를 재현 가능하게 참조합니다.
• 멀티플랫폼 태그: 동일 태그에 arm64/amd64를 함께 게시해 하이브리드 클러스터 운영을 단순화합니다.
• 레지스트리 정책: 보존·삭제(GC), 서명·검증, 복제(geo-replication) 정책으로 가용성과 신뢰성을 확보합니다.

OCI는 단지 컨테이너만이 아닙니다. Helm 차트, WASM 모듈, 모델 파일, SBOM, 서명 등 “이미지 아닌 것들”도 OCI Artifacts로 저장·배포할 수 있도록 확장되고 있습니다. 동일한 CAS, 동일한 보안·정책·복제 메커니즘을 재사용한다는 점이 강점입니다.

• Manifest는 “목차”, Config는 “기본 실행 메타데이터”, Layers는 “파일 시스템 변화”, Index는 “멀티플랫폼 선택자”.
• 모든 구성 요소는 다이제스트로 식별되고 검증됩니다.
• 표준화 덕분에 빌드·배포·실행 전 과정이 도구 중립적으로 이어지고, 보안·최적화 기법이 공통 기반 위에서 발전합니다.

이로써 OCI 이미지 사양의 구조와 동작, 보안·운영 관점의 실무 포인트를 모두 연결해 보았습니다. 이제 어떤 빌드/레지스트리/런타임 조합이어도 “다이제스트를 기준으로 동일한 아티팩트”를 재현·검증·배포할 수 있다는 감각이 잡히실 것입니다.

앞서 OCI 런타임 사양이 컨테이너를 ‘어떻게 실행할 것인가’에 대한 약속이었다면, 이번에 살펴볼 OCI 이미지 사양(Image Format Specification)은 컨테이너의 내용물, 즉 ‘컨테이너 이미지를 어떻게 만들고 포장(패키징)할 것인가’에 대한 표준 약속입니다. 우리가 애플리케이션과 그 실행에 필요한 모든 라이브러리, 의존성, 설정 파일 등을 하나로 묶어 배포하는 단위가 바로 컨테이너 이미지인데요, 이것이 단순히 파일들을 압축한 덩어리가 아니라, 모든 관련 도구들이 이해하고 사용할 수 있는 일관된 구조와 형식을 가져야만 합니다.

만약 이미지 형식이 표준화되어 있지 않다면 어떤 일이 벌어질까요? A라는 도구로 만든 이미지를 B라는 저장소(레지스트리)에 올릴 수 없거나, C라는 실행 환경(런타임)에서 내려받아 실행할 수 없는, 그야말로 기술적인 장벽과 파편화가 만연했을 것입니다. 마치 각기 다른 포맷의 비디오 파일을 재생하기 위해 여러 종류의 플레이어를 설치해야 했던 불편함과 비슷하죠.

OCI 이미지 사양은 이러한 혼란을 막고, 컨테이너 기술 생태계의 모든 참여자들 – 이미지를 만드는 빌드 도구(예: Docker Build, Buildah, Kaniko), 이미지를 저장하고 공유하는 레지스트리(예: Docker Hub, Harbor, Quay.io, Amazon ECR, Google Container Registry), 그리고 이미지를 가져와 컨테이너로 실행하는 런타임(예: containerd, CRI-O) – 이 마치 하나의 언어를 사용하듯 원활하게 소통하고 협력할 수 있도록 하는 기반을 제공합니다. 이는 마치 전 세계적으로 통용되는 표준 화물 컨테이너 규격(ISO 668) 덕분에 선박, 기차, 트럭 등 다양한 운송 수단 간의 환적이 용이해지고 물류 시스템 전체의 효율성이 극대화된 것과 같은 원리입니다.

그렇다면 OCI 이미지 사양이 정의하는 컨테이너 이미지의 핵심 구성 요소들은 구체적으로 무엇일까요? 크게 네 가지 중요한 요소로 나누어 살펴볼 수 있습니다.

• 이미지 매니페스트(Image Manifest)는 특정 플랫폼(OS/아키텍처 조합)을 위한 컨테이너 이미지의 전체 구조를 설명하는 핵심적인 JSON 파일입니다. 마치 책의 목차나 제품의 상세 명세서처럼, 이 매니페스트 파일은 해당 이미지가 어떤 설정 정보(Image Configuration)를 가지고 있으며, 어떤 파일 시스템 레이어(Layers)들로 구성되어 있는지에 대한 정보를 담고 있습니다.

매니페스트 안에는 크게 두 가지 중요한 정보가 포함됩니다.

• 설정 객체(Config Descriptor): 이미지의 메타데이터와 기본 실행 설정을 담고 있는 ‘이미지 설정(Image Configuration)’ 파일(이 역시 JSON 형식)을 가리키는 정보입니다. 이 정보에는 해당 설정 파일의 미디어 타입(media type, 예: application/vnd.oci.image.config.v1+json), 파일 크기(size), 그리고 가장 중요한 고유 식별자(Digest)가 포함됩니다. 다이제스트는 해당 파일 내용물의 암호화 해시값(보통 SHA256)으로, 파일의 무결성을 보장하고 고유하게 주소를 지정하는 데 사용됩니다.
• 레이어 목록(Layers Array): 이미지를 구성하는 파일 시스템 레이어들을 순서대로 나열한 목록입니다. 각 레이어 항목 역시 해당 레이어 파일(보통 압축된 tar 아카이브)의 미디어 타입(media type, 예: application/vnd.oci.image.layer.v1.tar+gzip), 압축된 파일 크기(size), 그리고 고유 식별자(Digest) 정보를 포함합니다. 레이어는 반드시 순서대로 적용되어야 최종적인 컨테이너 루트 파일 시스템을 구성할 수 있습니다.

이 매니페스트 자체도 고유한 미디어 타입(예: application/vnd.oci.image.manifest.v1+json)을 가지며, 레지스트리와 런타임은 이 매니페스트를 통해 이미지의 전체 구조를 파악하고 필요한 구성 요소(설정 파일, 레이어 파일)들을 다이제스트를 이용해 정확하게 요청하고 내려받을 수 있습니다. 즉, 매니페스트는 이미지의 모든 구성 요소를 연결하는 중심 허브 역할을 하는 셈입니다.

때로는 동일한 이미지 이름과 태그(예: nginx:latest)를 사용하지만, 서로 다른 운영체제나 CPU 아키텍처(예: linux/amd64, linux/arm64, windows/amd64)를 지원해야 할 필요가 있습니다. 이런 경우를 위해 OCI 이미지 사양은 이미지 인덱스(Image Index)라는 개념을 제공합니다. (이는 “Fat Manifest”라고 불리기도 합니다.)

이미지 인덱스는 그 자체로 또 다른 JSON 파일이며, 여러 개의 이미지 매니페스트를 하나로 묶어 참조할 수 있게 해주는 상위 레벨의 매니페스트 역할을 합니다. 인덱스 파일 내부에는 manifests라는 배열이 있고, 이 배열의 각 항목은 특정 플랫폼용 이미지 매니페스트를 가리키는 설명자(Descriptor)입니다. 이 설명자에는 해당 이미지 매니페스트의 미디어 타입, 크기, 다이제스트 정보와 더불어, 어떤 플랫폼(os, architecture, 선택적으로 variant)을 위한 매니페스트인지를 명시하는 platform 객체가 포함되어 있습니다.

컨테이너 런타임이 레지스트리에 특정 이미지 태그(예: nginx:latest)를 요청했을 때, 레지스트리가 이미지 인덱스를 반환하면, 런타임은 자신의 실행 환경(OS, 아키텍처)과 일치하는 platform 정보를 가진 매니페스트 설명자를 인덱스 내에서 찾습니다. 그리고 해당 설명자에 포함된 다이제스트를 사용하여 실제 필요한 이미지 매니페스트를 다시 요청하는 방식으로 작동합니다.

이 이미지 인덱스 덕분에 사용자들은 자신의 환경을 신경 쓸 필요 없이 동일한 이미지 이름과 태그를 사용하여 이미지를 가져올 수 있고, 시스템은 자동으로 현재 환경에 맞는 최적의 이미지를 선택하여 제공할 수 있게 됩니다. 이는 멀티 아키텍처 지원을 매우 편리하게 만들어주는 중요한 기능입니다.

• 이미지 레이어(Image Layers)는 컨테이너의 루트 파일 시스템(rootfs)을 구성하는 변경 사항(changeset)들을 순차적으로 쌓아 올린 것입니다. 각 레이어는 이전 레이어 상태에서 파일이나 디렉토리가 추가, 수정, 또는 삭제된 내용을 담고 있습니다.
• 형식: 일반적으로 각 레이어는 파일 시스템의 변경 내용을 담은 압축된 tar 아카이브(tarball) 형태로 표현됩니다. (예: application/vnd.oci.image.layer.v1.tar+gzip 또는 application/vnd.oci.image.layer.v1.tar+zstd 등). OCI 사양은 특정 압축 알고리즘을 강제하지는 않지만 gzip이 가장 흔하게 사용됩니다. 파일 삭제를 표현하기 위해서는 ‘whiteout’ 파일이라는 특수한 표식(.wh.<filename> 또는 .wh..wh..opq)을 사용합니다.
• 효율성: 이 레이어 방식은 컨테이너 이미지의 저장 및 전송 효율성을 극대화하는 핵심적인 이유입니다.
  • 재사용 및 공유: 여러 이미지가 동일한 기반 이미지(Base Image)를 공유하는 경우가 많습니다. 예를 들어, Ubuntu 기반 위에 각기 다른 애플리케이션을 설치한 이미지들은 Ubuntu 기본 레이어들을 모두 공유할 수 있습니다. 레이어는 내용 기반의 다이제스트로 식별되기 때문에, 동일한 내용의 레이어는 시스템 내에 단 한 번만 저장되고, 여러 이미지에서 참조하여 사용할 수 있습니다. (Content-Addressable Storage)
  • 네트워크 효율성: 이미지를 내려받거나(pull) 올릴(push) 때, 이미 로컬 시스템이나 대상 레지스트리에 존재하는 레이어는 다시 전송할 필요 없이 건너뛸 수 있습니다. 변경된 레이어만 전송하면 되므로 네트워크 대역폭 사용량과 전송 시간을 크게 절약할 수 있습니다.
• 루트 파일 시스템 구성: 컨테이너 런타임은 이미지 매니페스트에 명시된 순서대로 이 레이어들을 내려받아, OverlayFS와 같은 유니온 파일 시스템(Union Filesystem) 기술을 사용하여 마치 하나의 통합된 파일 시스템처럼 보이도록 겹쳐 쌓습니다(stacking). 아래쪽 레이어들은 일반적으로 읽기 전용(read-only)으로 마운트되고, 컨테이너가 실행될 때 가장 위에는 변경 사항을 기록하기 위한 쓰기 가능한(writable) 레이어가 추가됩니다.

OCI 이미지 사양은 이러한 레이어들이 어떻게 패키징되고, 어떤 미디어 타입을 가져야 하며, 어떻게 식별(다이제스트)되어야 하는지를 명확히 규정함으로써, 이러한 효율적인 메커니즘이 모든 호환 도구에서 일관되게 작동하도록 보장합니다.

이미지 설정(Image Configuration)은 해당 이미지로부터 컨테이너를 실행할 때 필요한 기본 설정값들과 이미지 자체에 대한 메타데이터를 담고 있는 JSON 파일입니다. 이 파일은 이미지 매니페스트에 의해 참조되며, 이미지 레이어들과 함께 이미지의 중요한 구성 요소입니다.

OCI Image Specification: 이미지 설정(Image Configuration) JSON 상세

핵심 요약:

• 기본값 제공: 이미지 설정 파일은 컨테이너 실행 시 사용될 환경 변수, 명령어, 사용자 등의 기본값을 정의합니다. 이는 사용자가 별도 옵션을 주지 않았을 때 적용됩니다.
• 메타데이터 저장소: 이미지 자체에 대한 중요한 정보(생성자, 플랫폼, 빌드 이력, 레이블 등)를 담고 있어 이미지 관리와 활용에 필수적입니다.
• 런타임 설정과의 관계: 여기에 정의된 값들은 컨테이너 실행 시 사용자가 제공하는 옵션(예: docker run -e VAR=new_value –user 1002 myimage new_command)에 의해 덮어쓰여지거나(Override) 보강될 수 있습니다. 최종 실행 설정은 OCI 런타임 사양의 config.json으로 조합됩니다.
• 이미지 불변성: 한번 빌드된 이미지의 설정 파일 내용은 변경되지 않습니다. 변경이 필요하면 새로운 이미지를 빌드해야 합니다.

이 표를 통해 이미지 설정 파일이 단순한 설정 모음이 아니라, 이미지의 정체성, 기본 행동 방식, 빌드 과정 등을 담고 있는 중요한 ‘명세서’ 역할을 한다는 것을 이해하실 수 있기를 바랍니다.

이 표준 덕분에, 어떤 도구를 사용하여 이미지를 빌드하든(예: Dockerfile + docker build, buildah bud), 그 결과물은 OCI 호환 레지스트리(예: Harbor, Docker Hub)에 안정적으로 저장 및 배포될 수 있으며, OCI 호환 런타임(예: containerd + runc, CRI-O + crun)은 이 이미지를 문제없이 해석하고 내려받아 컨테이너로 실행할 수 있습니다. 이는 마치 전 세계 어디서나 통용되는 표준 화물 컨테이너 덕분에 복잡한 국제 물류 시스템이 원활하게 작동하는 것과 같은 이치입니다. OCI 이미지 사양은 컨테이너 기술 생태계 전반에 걸쳐 ‘빌드(Build) – 배포(Ship) – 실행(Run)’ 워크플로우를 매끄럽게 만들고 자동화하는 데 필수적인 기반을 제공하는 것입니다.

지금까지 우리는 OCI가 정의하는 컨테이너 이미지 형식과 실행 방법에 대한 두 가지 핵심 기술 사양(Specification)을 자세히 살펴보았습니다. 기술적인 내용들이 조금 복잡하게 느껴지셨을 수도 있지만, 이제 잠시 한 걸음 물러나서 “왜 이렇게까지 표준을 만드는 것이 중요했을까?”라는 근본적인 질문에 답해볼 시간입니다. 단순히 기술 명세를 정하는 것을 넘어, OCI 표준화는 오늘날 우리가 누리는 강력하고 유연한 클라우드 네이티브 환경을 가능하게 만든 결정적인 전환점이었습니다. 그 중요성을 몇 가지 핵심적인 측면에서 자세히 살펴보겠습니다.

OCI 표준이 가져온 가장 중요하고 직접적인 이점은 바로 상호 운용성(Interoperability)의 확보입니다. OCI 이전, 컨테이너 기술 초기에는 특정 회사의 도구가 사실상의 표준처럼 여겨지면서도, 다른 여러 기술들이 각자의 방식으로 컨테이너를 다루려는 시도들이 있었습니다. 만약 이런 상황이 지속되었다면, 특정 도구 A로 만든 컨테이너 이미지는 오직 도구 A의 런타임에서만 실행 가능하고, 도구 B의 레지스트리와는 호환되지 않는 ‘기술의 사일로(Silo)’ 현상이 심화되었을 것입니다. 이는 마치 제조사마다 다른 충전 규격을 사용하던 초기의 휴대폰 시장처럼, 사용자에게 큰 불편과 비효율을 초래했을 겁니다.

하지만 2015년, Docker, CoreOS(이후 Red Hat에 인수), Google, Red Hat, Microsoft 등 컨테이너 기술 분야의 주요 기업들이 리눅스 재단(Linux Foundation) 산하에 모여 OCI를 출범시키면서 상황은 극적으로 변했습니다. 이들은 경쟁 관계를 넘어 컨테이너 이미지 형식과 런타임 실행 방식이라는 핵심 기술에 대한 공통의 약속, 즉 OCI 표준을 만들기로 합의했습니다.

이 OCI 표준 덕분에, 이제 서로 다른 회사나 오픈소스 커뮤니티에서 개발된 다양한 컨테이너 관련 도구들 – 이미지를 만드는 빌드 도구(예: Docker Build, Buildah, Kaniko), 이미지를 저장하고 공유하는 레지스트리(예: Docker Hub, Harbor, Quay.io, Google Container Registry, Amazon ECR), 이미지를 실행하는 컨테이너 런타임(예: containerd, CRI-O, 그리고 이들이 사용하는 runc, crun 등), 그리고 이 모든 것을 지휘하는 오케스트레이션 도구(예: 쿠버네티스) – 가 마치 원래부터 하나였던 것처럼 매끄럽게 함께 작동할 수 있게 되었습니다.

이는 사용자에게 엄청난 선택의 자유를 선사합니다. 개발자와 운영자는 더 이상 특정 회사의 기술 스택에 갇힐 필요 없이, 자신들의 요구사항과 환경에 가장 적합한 도구들을 마치 레고 블록처럼 자유롭게 선택하고 조합하여 시스템을 구성할 수 있습니다. 예를 들어, 이미지 빌드는 Buildah를 사용하고, 레지스트리는 Harbor를 구축하며, 쿠버네티스 클러스터의 런타임으로는 containerd와 runc 조합을 선택하는 것이 가능해진 것입니다. 이러한 유연성은 벤더 종속성(Vendor Lock-in)이라는 위험을 효과적으로 피하게 해주는 핵심적인 요소입니다. 특정 기술에 묶여 원치 않는 업그레이드를 강요받거나, 다른 더 나은 대안으로 전환하기 어려워지는 상황을 막을 수 있게 된 것이죠.

두 번째 중요한 이점은 OCI 표준이 기술 혁신을 가속화하는 강력한 촉매 역할을 한다는 점입니다. 기본적인 규칙(이미지 형식, 런타임 실행 방식)이 명확하게 정립되면서, 개발자들과 기업들은 더 이상 ‘바퀴를 재발명’하는 데, 즉 이미 해결된 기본적인 문제를 다시 구현하는 데 귀중한 시간과 노력을 낭비할 필요가 없어졌습니다. 대신, 이 안정적인 OCI 표준이라는 기반 위에서 더욱 새롭고 차별화된 가치를 창출하는 데 역량을 집중할 수 있게 되었습니다.

이는 다양한 영역에서의 혁신으로 이어졌습니다.

런타임 다양화: OCI 런타임 사양을 준수하면서도 각기 다른 장점을 가진 저수준 런타임들이 등장했습니다. runc가 표준 참조 구현체라면, C언어로 작성되어 더 가볍고 빠른 crun이 개발되었고, 보안 강화를 위해 가상 머신 기술을 활용하는 kata-containers나 사용자 공간 커널을 구현한 gVisor 같은 혁신적인 런타임들이 OCI 호환성을 유지하며 생태계에 합류했습니다. 사용자들은 워크로드의 특성(성능 중시, 보안 중시 등)에 따라 최적의 런타임을 선택할 수 있게 되었습니다.
빌드 도구 발전: OCI 이미지 사양 덕분에 Docker 데몬에 의존하지 않는 새로운 이미지 빌드 도구들(예: Buildah, Kaniko, img)이 등장하여, 더 빠르고 안전하며 유연한 빌드 파이프라인 구축을 가능하게 했습니다.
이미지 관리 혁신: 이미지 레이어 형식, 매니페스트 등의 표준화는 레지스트리 기술의 발전을 촉진했고, 이미지 서명(예: Notary, Sigstore)이나 취약점 스캔 같은 보안 기능과의 통합을 용이하게 만들었습니다.
특수 목적 컨테이너 기술: OCI 표준을 기반으로 WebAssembly 컨테이너(wasm), GPU 가속 컨테이너 등 특정 워크로드에 최적화된 컨테이너 기술들도 개발되고 있습니다.
이처럼 OCI 표준은 기술의 ‘최소 공통 분모’를 정의함으로써, 그 위에 다양한 아이디어와 기술들이 자유롭게 꽃피울 수 있는 비옥한 토양을 제공했습니다.

세 번째로, OCI 표준은 개방적이고 건강한 컨테이너 기술 생태계를 만드는 데 결정적인 기여를 했습니다. 명확하고 공개된 표준은 기술의 진입 장벽을 낮추는 효과를 가져옵니다. 새로운 기업이나 개발자들이 컨테이너 관련 기술을 개발하거나 기존 기술에 기여하고자 할 때, 따라야 할 명확한 가이드라인이 있으므로 훨씬 수월하게 생태계에 참여할 수 있습니다.

이는 자연스럽게 더 많은 플레이어들의 참여를 유도했고, 결과적으로 경쟁과 협력이 공존하는 활발한 생태계가 형성되었습니다. 다양한 기업과 커뮤니티가 OCI 표준을 중심으로 각자의 솔루션을 개발하고 개선하면서 경쟁하는 동시에, OCI 표준 자체의 발전이나 관련 오픈소스 프로젝트에는 함께 기여하며 협력합니다. 이러한 역동적인 환경은 결국 최종 사용자인 우리에게 더 많은 선택권, 더 높은 품질의 도구, 그리고 더 합리적인 비용이라는 혜택으로 돌아옵니다. 마치 다양한 자동차 제조사들이 공통의 도로 규범과 안전 기준을 따르면서도 각자의 기술력과 디자인으로 경쟁하여 소비자에게 더 좋은 자동차를 제공하는 것과 유사합니다. OCI는 컨테이너 기술 분야에서 이러한 선순환 구조를 만드는 데 핵심적인 역할을 했습니다.

마지막으로, OCI 표준은 오늘날 컨테이너 오케스트레이션의 사실상 표준(de facto standard)으로 자리 잡은 쿠버네티스와의 강력한 시너지를 만들어냅니다. 쿠버네티스는 설계 초기부터 특정 컨테이너 런타임 기술에 종속되지 않도록 하는 것을 중요한 목표로 삼았습니다. 이를 위해 쿠버네티스는 CRI(Container Runtime Interface)라는 자체적인 추상화된 인터페이스를 정의했습니다. 쿠버네티스의 핵심 컴포넌트인 Kubelet은 이 CRI를 통해 컨테이너 런타임에게 컨테이너 및 이미지 관리를 요청합니다.

여기서 중요한 점은, containerd나 CRI-O와 같은 널리 사용되는 고수준 컨테이너 런타임들은 바로 이 CRI를 구현하는 동시에, 내부적으로는 OCI 표준을 철저히 준수한다는 사실입니다. 즉, 이들은 쿠버네티스(Kubelet)로부터 CRI를 통해 명령을 받으면, 이를 해석하여 OCI 이미지 사양에 맞는 이미지를 가져오고, OCI 런타임 사양에 따라 저수준 런타임(runc, crun 등)을 호출하여 컨테이너를 생성하고 관리합니다.

결국, OCI 표준은 쿠버네티스가 다양한 컨테이너 런타임 구현체들을 일관된 방식으로 지원하고, 사용자에게 런타임 선택의 유연성을 제공할 수 있도록 하는 근본적인 토대(Foundation) 역할을 수행하는 것입니다. 쿠버네티스가 직접 OCI 표준을 사용하는 것은 아니지만, 쿠버네티스 생태계의 핵심 구성 요소들이 OCI 표준 위에 구축되어 있기 때문에, OCI 없이는 오늘날과 같은 쿠버네티스의 유연성과 확장성을 상상하기 어렵습니다.