2026년 10월 22일, 한 개발자가 재미로 자신의 컨테이너 런타임을 만들기 시작하면서 도커의 내부 동작 방식이 다시 주목받았습니다. 이 과정에서 도커가 리눅스 커널의 단일 기능이 아니라 네임스페이스, cgroups, 네트워크 격리 등 다섯 가지 다른 커널 기능들이 겹쳐진 형태라는 점이 명확히 드러났습니다.
이미지는 디스크에 있는 폴더일 뿐이며, 도커는 chroot나 pivot_root를 호출해 그 폴더를 프로세스의 새로운 루트 디렉터리로 지정합니다. 이는 가상 머신과 달리 호스트 커널이 여전히 해당 프로세스를 실행하고 있다는 뜻이기도 합니다.
기술적 난점은 고(Go) 언어 런타임에서 발생했습니다. 고는 기본적으로 멀티스레드 환경인데, 포크(fork) 시스템 콜은 호출한 스레드만 복제하므로 다중 스레드 환경에서는 위험할 수 있습니다. 이로 인해 고는 포크 기능을 노출하지 않습니다.
도커의 컨테이너 런타임인 runc는 이 문제를 해결하기 위해 /proc/self/exe를 특수한 명령줄 인자와 함께 실행하여 포크를 모방합니다. 또한 일부 리눅스 시스템 콜은 단일 스레드 환경에서 수행되어야 하므로, runc는 고 런타임 초기화 전에 실행되는 C 모듈을 포함하고 있습니다.
도커 데몬은 보통 루트 권한으로 실행됩니다. macOS에서는 VM 내에서 도커가 돌아가 이러한 특성이 가려지지만, 리눅스에서는 많은 커널 API가 루트 권한을 요구하기 때문입니다. 루트리스 컨테이너 런타임도 존재하지만, 동일한 기능을 제공하려면 사용자 공간에서 전체 네트워크 스택을 재구현해야 하는 부담이 따릅니다.
이러한 발견은 Hacker News와 daily.dev 커뮤니티에서 활발한 논의를 불러일으켰습니다. 특히 도커의 창시자로 알려진 인물이 직접 댓글을 남겨 과거의 설계 의도를 설명하기도 했습니다.
창시자는 도커의 독창성이 컨테이너 기술 자체보다는 Dockerfile 개념, 이미지 레이어 캐싱, 그리고 전 세계적으로 이미지를 공유하는 레지스트리 모델에 있다고 강조했습니다. 복잡한 배포 과정을 간소화하고 호스트 시스템에 대한 불안감을 해소한 것이 핵심이었다는 설명입니다.
다만 현재 시점에서 많은 개발자들은 Podman 같은 대안을 선호하는 경향도 보입니다. 도커가 ‘트렌치코트를 입은 다섯 가지 리눅스 커널 기능’이라는 표현처럼, 기존 OS 기능 위에 뛰어난 개발자 경험을 얹어낸 결과물이라는 평가가 지배적입니다.
이번 사례는 저수준 툴링을 구축하려는 개발자들에게 고 언어의 런타임 제약과 컨테이너 기술의 실제 작동 원리를 이해하는 계기가 되었습니다. 도커의 내부 구조가 낯설게 느껴지는 이유 중 하나는 이러한 복잡한 우회 로직과 권한 모델에 기인합니다.