OCI를 읽을 때 먼저 구분할 것은 “이미지의 형식”, “이미지를 주고받는 규약”, “컨테이너를 실행하는 규약”입니다. Open Container Initiative는 각각 Image, Distribution, Runtime Specification을 별도 문서로 관리합니다. OCI 개요는 큰 흐름을 요약하고, containerd의 content-flow 설명은 실제 이미지가 registry에서 실행 가능한 filesystem으로 준비되는 단계를 보여 줍니다.

세 규격은 같은 일을 반복하지 않는다

  • Image Specification은 이미지 manifest, config, layer 등 배포할 이미지 데이터의 구조를 다룹니다.
  • Distribution Specification은 registry가 이미지와 artifact를 조회하고 업로드·다운로드하는 상호운용 규약을 다룹니다. 저장소 구현 전체를 하나로 정하는 문서는 아닙니다.
  • Runtime Specification은 이미지에서 준비된 filesystem bundle과 설정으로 컨테이너 프로세스를 생성·실행하는 규약입니다.

따라서 registry에서 image를 pull할 때는 Distribution과 Image 관점이, 로컬에서 프로세스를 시작할 때는 Runtime 관점이 중요합니다. OCI 적합성만으로 특정 제품의 스케줄링, 네트워크, 권한 정책까지 결정되는 것은 아닙니다.

태그에서 실행 중인 파일시스템까지

example/app:stable 같은 태그는 편리한 이름입니다. containerd의 흐름 설명에 따르면 registry 응답은 manifest 하나일 수도 있고 여러 플랫폼별 manifest를 가리키는 index일 수도 있습니다. index라면 실행 대상 OS와 CPU 아키텍처에 맞는 manifest를 고르고, digest를 이용해 config와 layer를 가져옵니다. 그 다음 layer를 순서대로 풀어 snapshot을 만들고, 실행 중 쓰기에 사용할 filesystem을 준비합니다.

이 과정은 “이미지를 실행한다”는 말이 실제로는 여러 경계를 거친다는 점을 보여 줍니다. 태그가 같은 이름이어도 index가 어떤 플랫폼 manifest를 가리키는지, 레이어가 실제로 내려왔는지, 런타임이 어떤 설정으로 프로세스를 띄웠는지는 따로 확인해야 합니다. 장애를 조사할 때 registry pull 성공과 프로세스 실행 성공을 같은 단계로 묶지 마세요.

Runtime과 daemon도 같은 말은 아니다

OCI runtime spec은 low-level 실행을 위한 bundle과 설정을 설명합니다. containerd 같은 상위 런타임 프로젝트는 이미지 전달·저장·수명주기를 조정한 뒤 OCI 호환 실행기를 호출할 수 있습니다. 그러므로 “OCI runtime”이라는 표준 인터페이스와 containerd 같은 제품 daemon을 구별하면 로그의 어느 단계에서 문제가 났는지 좁히기 쉽습니다.

Windows 컨테이너는 항상 Linux VM이 아니다

OCI runtime에는 Windows 전용 설정도 있습니다. Windows 설정 문서는 Windows Host Compute Service API를 사용한다고 설명합니다. 선택 항목 hyperv가 있으면 Hyper-V isolation으로 실행하고, 생략하면 Windows Server container로 실행합니다. 즉 Windows 컨테이너를 모두 Linux VM으로 일반화할 수 없습니다. isolation 방식은 호스트 OS, 런타임, 배포 설정을 함께 확인해야 합니다.

문서를 볼 때의 실무 순서

문제가 이미지 수신 단계라면 Distribution API와 registry 응답을, 플랫폼 선택이나 layer 누락이면 Image manifest/index와 digest를, 프로세스가 시작되지 않는다면 Runtime bundle·호스트 설정·실행기를 확인하세요. 세 영역을 분리하면 “OCI가 깨졌다”는 막연한 진단 대신 실패 경계를 특정할 수 있습니다.

참고 자료