IT 업계는 새로운 추상화를 통해 경계를 다시 설정한 뒤, 이전 방식을 구식이라 선언하길 좋아한다. 이는 애플리케이션 아키텍처(모놀리식 vs. 마이크로서비스), 프로그래밍 언어(JVM 기반 언어 vs. 스위프트, 러스트, 고), 클라우드 인프라(퍼블릭 클라우드 vs. 온프레미스) 등 거의 모든 주요 영역에서 반복된다.

이런 가짜 이분법은 사람들의 관심을 끌고 흥미를 자극하며 레딧에서 논쟁거리로 이용되기는 좋다. 하지만 거의 예외 없이, 오래된 방식과 새 방식은 장기간 공존한다. 때로는 오래된 방식이 새로운 모습으로 다시 등장하기도 한다. 모놀리식 아키텍처는 마이크로서비스 이론이 지배적인 상황에서도 여전히 존재감을 유지하고 있다. 온프레미스 데이터센터는 퍼블릭 클라우드에 의해 사라지지 않았으며, 서버리스도 데브옵스를 대체하지 못했다. 사례는 셀 수 없이 많다.

지금 가장 흥미로운 가짜 이분법은 가상머신(VM)과 컨테이너 사이의 경계일 것이다. 가상머신은 비싸고, 무겁고, 특정 솔루션 업체에 종속됐다는 이유로(때로는 정당하게, 때로는 그렇지 않게) 비판받는 반면, 컨테이너는 클라우드 네이티브 환경의 표준 애플리케이션 형식으로 여겨진다.

하지만 실제로는 두 기술이 점점 더 융합되고 있다. 컨테이너가 부상한 지 10년이 넘은 현재, 가상머신과 컨테이너의 관계는 대체보다는 융합으로 설명하는 것이 적절하다. 이는 인프라, 애플리케이션, 무엇보다 보안을 아우르는 기업 아키텍처의 복잡한 진화 주제 중 하나다.

컨테이너의 부상

컨테이너와 가상머신의 계보는 복잡하다. 컨테이너의 기반이 되는 리눅스 네임스페이스는 2006년에 등장했다. 리눅스 컨테이너 프로젝트(LXC)는 2008년부터, 컨테이너와 유사한 운영체제 가상화 프로젝트인 Linux-vserver는 1999년에 시작됐다. 맞춤형 리눅스 커널을 사용하는 또 다른 컨테이너 기술인 버추어조(Virtuozzo)는 2000년에 상용 제품으로 출시됐고, 2005년 오픈소스로 전환돼 OpenVZ로 공개됐다. 즉, 컨테이너는 2000년대 가상화 기술이 본격화되기 전부터 존재해왔다.

하지만 시장 대부분은 2013년 도커(Docker)의 등장으로 처음 컨테이너를 인식했고, 2015년 도커 1.0 출시를 기점으로 본격적으로 주류에 진입했다. 2010년대 도커의 확산은 개발자에게 혁신이었으며, 지금 우리가 말하는 클라우드 네이티브 개발의 기반을 만들었다. 도커의 격리된 애플리케이션 환경은 “내 컴퓨터에서는 잘 되는데”라는 업계의 오랜 문제를 해결했고, 베이그런트(Vagrant) 같은 무겁고 가변적인 개발 도구를 도커파일과 컨테이너 이미지 기반의 불변 구조로 대체했다. 이 변화는 애플리케이션 개발과 배포, 지속적 통합(CI) 시스템의 새로운 르네상스를 이끌었고, 클라우드 네이티브 애플리케이션 아키텍처 시대를 열었다.

당시 컨테이너는 적시에 등장한 최적의 기술이었다. 개발자에게 높은 민첩성을 제공했고, 이에 비해 가상머신은 비싸고 무겁고 다루기 어렵우며, 무엇보다 “IT 부서가 마련해줘야 하는 것”이라는 이미지가 있었다. 퍼블릭 클라우드를 통해 개발자가 스스로 인프라를 조달할 수 있게 된 시점에서 이는 치명적인 단점이었다.

가상머신의 미덕

컨테이너가 처음 대중에게 소개됐을 때, 가상머신은 대부분 어플라이언스 형태로 제공됐다. 이 소비 모델은 일반적으로 무거운 VM웨어 스택과 전용 VM 호스트를 필요로 했다. 라이선스는 당시에도, 지금도 매우 비싸다. 오늘날 대부분은 ‘가상화’라는 말을 들으면, 시작 시간이 느리고 이식성이 떨어지며 자원을 비효율적으로 사용하는 무거운 스택을 떠올린다. 컨테이너가 가벼운 노트북이라면, 가상머신은 무게 1,000파운드짜리 서버 같다.

하지만 가상머신은 매우 유용한 특성을 지니고 있다. 시간이 흐르면서 마이크로VM에 대한 관심이 커졌고, 가상머신이 더 작고 효율적으로 진화하는 추세가 이어지고 있다. 리눅스 커널 기술도 발전해, 이제는 별도의 커널에서 사용자 애플리케이션을 실행하는 것이 충분히 가능해졌다. 이런 진화는 가상머신을 더 친숙한 플랫폼으로 만들었고, 현재는 우리 주변 어디에서나 사용되고 있다.

예를 들어 윈도우 환경에서 가상머신을 일반 하드웨어에 설치할 경우, 보안 목적으로 가삼머신 상에서 실행할 수 있다. 하이퍼바이저가 강력한 보안 수단이라는 인식은 이제 보편화됐다. 가상머신에서 실행되는 컨테이너는 어떤 클라우드 환경에서도 구동할 수 있으며, 더 이상 하이퍼바이저 업체의 프라이빗 환경에 국한되지 않는다.

힘을 합치는 컨테이너와 가상머신

멀티테넌시 환경의 필요성과 컨테이너를 위한 쓸만한 보안 격리가 부족하다는 것이 현재 컨테이너와 가상머신이 결합하게 된 주된 이유다.

컨테이너는 실제로 ‘컨테이너’ 역할을 하지 못한다. 쿠버네티스 클러스터 내에서 여러 워크로드와 애플리케이션을 실행하면, 모두 같은 OS 커널을 공유한다. 이 중 하나의 컨테이너가 침해당하면, 나머지 모든 컨테이너와 컨테이너를 실행하는 인프라 전체가 위험에 처할 수 있다.

컨테이너는 기본적으로 OS 수준의 가상화를 제공해 파일 시스템과 프로세스를 분리된 형태로 보여주지만, 리눅스 커널에 취약점이 있을 경우 시스템 전체로 침투해 상위 권한을 얻을 수 있고, 컨테이너를 빠져나오거나 사용자가 절대로 허용하지 않을 프로세스나 맥락에서 프로세스를 실행할 수 있다.

컨테이너와 가상머신 세상이 충돌하게 된 핵심 이유 중 하나는 가상머신 기반 컨테이너를 사용하면 각 컨테이너가 독립적인 커널과 주소 공간 위에서 실행되기 때문이다. 이는 호스트 시스템과 같은 리눅스 커널을 공유하지 않아 보안적으로 큰 이점을 제공한다.

멀티테넌시 환경에서의 보안 격리 문제는 가상머신 기반 컨테이너가 부상하게 된 급박한 이유지만, 그 외에도 가상머신과 컨테이너 경계를 허무는 경제적 이유도 있다. 가상머신은 메모리 요구사항이나 CPU 사용량을 세밀하게 제어할 수 있고, 전체 시스템 수준에서 자원 사용 정책을 적용할 수도 있다.

크라타(Krata)의 출현

컨테이너 형식은 클라우드 분산 인프라에서 현대 애플리케이션을 생성하고 운영하는 방식이 등장한 지 거의 20년간 진화해온 결과물이다. 세상은 컨테이너를 채택하며 가상머신이 사라질 것으로 기대했지만, 현실은 달랐다. 가상머신은 여전히 널리 쓰이고 있으며, 개발자는 여전히 해결되지 않은 컨테이너의 문제를 보완하기 위해 가상머신의 설계 철학을 차용하고 있다.

에데라가 시작한 오픈소스 프로젝트 크라타는 타입 1 하이퍼바이저인 젠(Xen) 마이크로커널에 러스트(Rust)로 재설계된 컨트롤 플레인을 결합해 컨테이너 친화적인 구조를 제공한다. 크라타는 가상머신의 강력한 격리성과 세밀한 자원 제어 기능을 제공하면서도, 도커와 유사한 개발자 경험을 지원한다. 또한 OCI 호환 컨테이너 런타임을 쿠버네티스 상에 구축하며, 가상화를 위해 쿠브버트(KubeVirt)를 사용할 필요도 없다. 시스템 펌웨어가 부팅되면 젠 마이크로커널로 넘겨지고, 여기서 가상머신 실행에 필요한 인터럽트와 메모리 관리를 설정한 뒤 쿠버네티스에서 컨테이너 팟을 실행한다.

크라타는 마이크로커널을 기반으로 하기 때문에 기존 쿠버네티스 운영체제를 변경하지 않아도 된다. AL2023, 우분투, 탈로스 리눅스 등 어떤 운영체제든 사용할 수 있으며, 가상화를 위해 쿠브버트를 쓸 필요도 없다. 컨테이너는 쿠버네티스 상에서 나란히 실행되며, 커널 상태를 공유하지 않기 때문에 커널 취약점이 발생해도 워크로드 간 데이터 접근이 불가능하다.

컨테이너는 개발자에게 유연성과 속도, 간편한 배포 환경을 제공한다. 가상머신은 더 뛰어난 워크로드 격리성과 보안을 제공한다. 그동안 개발자는 둘 중 하나를 선택해야 했지만, 그런 시대는 끝나가고 있다.

Alex Zenla는 에데라의 공동 설립자이자 CTO이다.
dl-itworldkorea@foundryco.com