도커, 왕좌를 지키지 못하는 이유? 컨테이너 생태계의 지각변동

수년간 컨테이너 생태계의 중심에는 도커가 있었다. 사실 도커는 ‘대명사’가 되긴 했지만 원래 그 기술의 근간은 ‘컨테이너’라는 기술이다.

리눅스 기반 OS 에서 제공하는 기술로 컨테이너는 시스템의 나머지 부분으로부터 격리된 하나 이상의 프로세스 집합을 의미한다.

이러한 프로세스를 실행하는 데 필요한 모든 파일과 필수 라이브러리, 종속성이 개별 이미지 내에 함께 패키징된다. 한 마디로 정리하면, Host 에 해당하는 영역에서 공통적인 걸 가져오고, 실제 독립적인 시스템 구현을 위해 필요한 부분은 ‘레이어’ 라는 이름으로 별도로 이미지 내부에 장착시켜서 호스트와는 별개의 시스템이 마치 구동되는 듯 보이게 만들어준다.

컨테이너는 가상 머신과 달리 가상 머신보다 적은 리소스를 사용하면서도 애플리케이션 격리를 유지할 수 있다. 또한, 표준 인터페이스를 갖추고 있어 대규모 애플리케이션(여러 컨테이너)의 일부로 더 쉽게 관리될 수 있으며, 여러 클라우드에 걸쳐 오케스트레이션될 수 있다. 궁극적으로 컨테이너는 애플리케이션 개발, 배포, 관리 방식에서 이식성과 일관성을 유지시키며 발전시킨 기술이라고 볼 수 있다. 그리고 이러한 컨테이너를 활용하여 시스테메틱한 관리체계를 정립한 도커는 컨테이너의 대명사처럼 여겨졌다.

하지만 이제는 도커만의 독주 무대가 아니게 되어감을 종종 느끼게 된다. 도커는 여전히 인기가 있지만, 점점 더 많은 기업과 개발자들이 다른 대안으로 눈을 돌리고 있다는 점은 고려해볼만한 논지가 아닐까 한다. 이는 도커가 선택지에서 제외되었다는 것이 아닌 성능, 보안, 유연성, 비용 등 주요 측면에서 도커가 뒤처지거나, 대안이 있다 혹은 대안을 찾아야 한다는 인식이 확산되고 있는 것이다.

도커가 가지는 현안들

  1. 라이선스 및 비용 구조 변경

    가장 중요한 전환점 중 하나는 도커 데스크톱의 라이선스와 비용 구조 변경이다. 도커는 일정 규모 이상의 조직에 유료 멤버십을 요구하기로 결정했으며, 이전까지 무료로 사용하던 도구에 대해 기업들이 갑자기 비용을 지불해야 하는 상황이 발생했다.

    이러한 부분은 비용에 민감한 팀들이 도커에 대한 의존도를 진지하게 재평가하도록 만들게 된다. 오픈 소스 도구로 전환하고자 하는 이들이 대안을 모색하는 계기가 되었다.

  2. 성능 문제

    도커는 리눅스에서는 뛰어난 성능을 가집니다. 물론, 이는 컨테이너라는 기술 자체의 본질적으로 리눅스 시스템 구조와 밀접한 연관성을 갖고 있다.

    하지만 문제는 이러한 편리함을 윈도우나 Mac 에서 사용하고자 하면서 여러 이슈가 발생하게 된다. 도커는 기본적으로 Host로 사용할 영역을 각각 WSL2, HyperKit 을 활용하는데, 이를 기반으로 하는 도커 데스크톱은 리눅스 컨테이너를 에뮬레이트하기 위해 가상 머신을 사용하기 때문에, 이로 인한 불가피한 성능 저하, 과도한 메모리와 CPU 사용 등의 문제가 발생할 수 있다.

    고질적인 윈도우 WSL Vmmem 이슈, 파일 시스템의 비정상적인 느림, IO 성능 저하, CPU 오버헤드 문제 등등… 알려진 문제들, 불편함은 이미 충분히 지적되고 있고, 이에 대한 개선은 수년째 언급 되고 있는 실정이다.

    특히나 무거운 빌드나 복잡한 멀티 컨테이너 구성에서는 문제가 더욱 심각해진다. 수겹의 레이어를 만들어야 하고, 그걸 위한 이미지들은 기존보다 훨씬 많은 양의 가상화를 위한 리소스를 필요로 한다.

    반면, 핀치(Finch)에서 사용하는 리마(Lima) 같은 신기술은 맥 개발자를 위해 최적화된 가상화 환경을 제공하여 도커 데스크톱의 복잡성 없이 성능을 개선합니다. 맥 성능을 극대화하는 것이 대체 런타임을 고려하는 또 하나의 이유다.

  3. 보안 문제

    도커의 아키텍처는 켜보면 바로 알 수 있는 특징이 있다. 내부의 구동에서 루트 권한으로 실행되는 데몬에 의존하고 있다는 점이다. 그러나 이러한 점이 바로 보안의 문제냐? 라고 하면 그렇지는 않다고 생각한다. 오히려 개발 친화적이고, Host 로의 입구 관문이 존재하는 데, 각 내부에 더 많고, 두꺼운 보안은 불필요한 요소일 수 있다.

    하지만 이로 인해 운영 환경에서 보안 위협 노출이 넓어질 수 있다. 이러한 점에서 도커는 보안 기능을 추가했지만, 보안을 중시하는 조직들은 애초부터 보안을 고려해 설계된 대안들을 선호하는 경우가 생길 수 밖에 없다.

  4. 모노리틱 접근 방식

    클러스터링을 위한 스웜(Swarm)과 이미지 레지스트리를 위한 도커 허브(Docker Hub)가 밀접하게 결합된 도커의 모노리틱 구조는 적응하고 난 사용자에게는 매우 편리하게 느껴질 수 있다. 모든 것이 물 흐르듯, 일사천리로 움직이게 되고 이러한 구조는 설정과 이식에서 우수한 성능을 보여준다.

    하지만 현대 클라우드 네이티브 환경에서는 오히려 제약으로 다가오게 될 수 있다. 오늘날의 트렌드는 특화되고 모듈화된 도구들로의 전환이다. 오케스트레이션은 쿠버네티스(Kubernetes)가 완전히 지배하고 있으며, 패키징은 헬름(Helm)이 담당하고, 컨테이너드(containerd)와 같은 전용 컨테이너 런타임은 컨테이너 관리에만 집중해준다. 즉, 각 역할에 맞는 수준의 관리를 하고 통제가 가능하다는 것은, 전체의 조율과 모듈화에 오히려 도움이 되지, 도커의 통합적 관리는, 오히려 복잡성을 증가시킬 수 있다.

  5. 밴더 종속성 우려

    개발자들은 도커의 특정 도구에 지나치게 의존하는 것에 신중해지고 있다. 도커 파일 문법은 널리 사용되지만, OCI 이미지 및 런타임 요구 사항처럼 공개 표준에 의해 관리되는 것이 아니다. 개발자들은 단일 툴체인에 묶이는 것을 피하고 싶어 하며, 특히 공개 표준이 더 큰 유연성과 장기적인 안정성을 보장해 줄 수 있다는 주장은 언제나 그렇지만 지속적으로 강조된다. 다양한 도구와 플랫폼 간의 호환성 보장, 이식성, 밴더 중립성 확보가 더욱 중요해졌고 그렇지 못한 대상에 대해선 기피하는 것이 어느 기업이나, 개발자들의 공통된 영역이리라.

도커의 대안들: 새로운 플레이어들의 등장

이러한 배경 속에서 여러 컨테이너 런타임들이 인기를 얻고 있으며, 이들은 현대적인 컨테이너 네이티브 환경의 핵심 가치인 모듈화, 성능, 개방성을 반영하고 있다. 주목할 만한 대안들은 다음과 같다.

  • Podman: 레드햇(Red Hat)에서 개발한 포드만은 안전하고 데몬이 없는 대체재로 평가받는다. 도커와 달리 중앙 데몬에 의존하지 않으며, 루트 권한 없이 컨테이너를 실행할 수 있는 루트리스 환경을 적극 지원 한다. 명령어 인터페이스도 도커와 매우 유사하여 보안을 중시하는 팀이 쉽게 전환할 수 있다.
  • containerd: 원래는 도커의 일부였지만 분리되어 현재는 CNCF가 관리하는 독립 프로젝트다. 특히 쿠버네티스 1.24에서 도커에 대한 직접 지원이 중단된 이후로, 컨테이너드는 대부분의 쿠버네티스 배포판에서 기본 컨테이너 런타임으로 사용되고 있다. AWS, 구글 클라우드, 애저와 같은 주요 클라우드 제공 업체들도 자체 관리형 쿠버네티스 서비스에서 컨테이너드를 기반으로 사용한다. 컨테이너 관리에 단일 목적을 가지고 있어 경량화되고 확장 가능하다는 특징이 가장 크다.
  • CRI-O: CRI-O 역시 CNCF에서 관리하며, 쿠버네티스를 위해 특별히 설계되었다. 컨테이너 런타임 인터페이스(CRI)를 엄격히 준수하며, 불필요한 요소를 제거한 간결하고 목적에 맞는 환경을 유지해준다. 오직 쿠버네티스 워크로드만을 지원하기 때문에 보안 측면에서도 이점을 제공한다. 레드햇 오픈 시프트의 기본 런타임이며, 최소주의와 규정 준수를 중시하는 팀들에게 선호된다.
  • Lima 및 Finch: 맥OS 성능 문제를 해결하기 위한 도구들이다. Lima는 맥OS에서 컨테이너 빌드를 위한 리눅스 가상 머신을 구성해 주는 도구로 성능에 최적화된 환경을 제공한다. Finch는 AWS가 후원하는 프로젝트로 리마와 컨테이너드/너드컨트롤(nerdctl)을 기반으로 하여 도커 데스크톱을 대체할 수 있는 고성능 도구를 제공한다. 라이선스 제약 없이 사용할 수 있다는 점이 큰 장점이며, 맥OS 개발자들 사이에서 네이티브에 가까운 성능을 제공하는 대안으로 빠르게 선호되고 있다.

컨테이너 생태계의 미래

컨테이너 생태계 전반의 분위기는 현재 지속적으로 모듈화와 전문화로의 전환을 반영하고 있다. 그러한 상황에서 도커의 아쉬운 부분을 이야기 해봤으나, 사실 지속적인 개선이 이루어지고 있다. 2025년 1월에 쓰여진 글로, Docker on MacOS is still slow?라는 이 글만 보더라도 2년 전 분석에 비하면 Docker 의 File Synchronization 기능으로 성능 저하는 최소화 가능하며, 아직 베타지만 Docker VMM 등 대안, 대첵 등도 거론된다는 점에서 MacOS 가상화 환경과 native linux 성능 간 격차 개선을 통해 컨테이너 생태계와 Docker가 여전히 개발자들의 선택을 받게 될 것이라는 점은 확실해 보인다.

도커는 사라지는 것이 아니라 변화하고 있는 것이다. 그러나 컨테이너라는 기술을 기반으로 하는 영역은 현재 개방형 표준, 경량화된 런타임, 클라우드 네이티브 원칙을 중심으로 빠르게 진화하고 있다. 도커가 이제는 컨테이너의 절대적인 중심은 아닐 수 있지만, 여전히 중요한 역할을 수행할 것이다. 우리가 목격하고 있는 것은 도커가 만들어낸 생태계의 성숙이며, 이를 통해 개발자들은 더 다양한 선택지를 갖게 되었다는 점이다.

미래는 모듈형 구조를 갖고 설계 단계부터 개방성을 지향하며, 기본적으로 안전하고 다양한 워크플로우에 유연하게 대응할 수 있는 도구들을 선호하는 것은 자연스러운 흐름일 것이고, 이 흐름을 읽고 대비하는 필요는 있어 보인다고 생각이 든다.