Container Runtime

이미지를 만들고 저장하는 것만으로는 서비스가 살아나지 않습니다. 실제 운영에서는 어떤 프로세스를 시작할지, 네트워크와 볼륨을 어떻게 붙일지, 실패했을 때 상태를 어떻게 기록할지를 실행 시점에 풀어야 합니다. 이 과정이 모호하면 장애가 날 때 어느 계층에서 문제가 생겼는지 좁히기 어렵습니다.

초기 Docker는 이미지 관리, API, 실행 로직을 큰 daemon 하나에 많이 묶어 두었습니다. 컨테이너가 오케스트레이터와 여러 도구의 공통 실행 단위가 되자, 어디까지가 표준 실행 규칙인지 분리할 필요가 커졌습니다. OCI(Open Container Initiative) 규격이 이미지와 런타임의 공통 계약을 정리했고, containerd와 runc는 그 계약을 실제 실행 경로로 구현하는 대표 구성 요소로 자리잡았습니다.

사용자가 CLI로 명령을 보내면 Docker daemon이 요청을 해석하고, containerd가 컨테이너 생명주기를 관리하며, runc가 최종적으로 namespace와 cgroup을 적용해 프로세스를 생성합니다. 이 체인을 이해하면 '이미지는 있는데 왜 실행이 안 되는가', '프로세스는 살았는데 왜 상태가 이상한가' 같은 문제를 훨씬 구조적으로 볼 수 있습니다.

Runtime과 Compose는 모두 컨테이너 실행에 관여하지만 층위가 다릅니다. Runtime은 개별 컨테이너를 프로세스로 만드는 실행 계층이고, Compose는 여러 컨테이너를 어떤 조합과 의존성으로 실행할지 선언하는 상위 조정 도구입니다. 여러 서비스를 한꺼번에 올리는 문제와, 한 컨테이너를 실제로 띄우는 문제를 구분해야 합니다.

운영에서 런타임 개념이 직접 드러나는 순간은 장애 대응입니다. 예를 들어 프로세스는 떠 있지만 헬스 체크가 실패하거나, 이미지 pull은 됐는데 컨테이너 생성이 안 되는 경우처럼 단계별 문제를 좁혀 가야 합니다. 이때 런타임 경로를 알면 로그를 어디서 봐야 하는지, 상태가 어느 계층에서 끊겼는지 판단이 빨라집니다.