리눅스 25주년 : 컨테이너와 유니커널로 입증된 '적을수록 좋다'

출처 : http://www.itworld.co.kr/news/100871 (2016.08.25 Serdar Yegulalp | InfoWorld)

리눅스의 25년 역사를 통틀어 변치 않은 한 가지가 있다면 바로 변화다. 커널 자체도 수십 번의 개정을 거쳤고 거의 모든 사용 사례를 위한 리눅스 배포판이 만들어졌다. 가벼운 취미 프로젝트로 시작된 리눅스 문화는 이후 전세계 IT 인프라의 토대로 발전했다.

지금은 리눅스에 불어 닥칠 다음 변화의 물결이 시작되어 그 첫 번째 결과물들이 나오고 있다. 컨테이너화, 유니커널을 비롯한 여러 실험이 리눅스를 근본적으로 변화시키면서 오픈소스 운영체제로서 그 역량을 입증한 리눅스를 위한 새로운 길을 열고 있다.

리눅스의 컨테이너 혁명(또는 발전)

컨테이너는 리눅스의 재창조에서 큰 부분을 차지한다. 컨테이너는 애플리케이션, 나아가 전체 가상 시스템 간에 높은 수준의 격리를 가능하게 해주면서, 일반적으로 하이퍼바이저 스타일의 VM에 수반되는 오버헤드도 없다.

컨테이너의 놀라운 점은 소프트웨어 개발과 운영에 관한 논의를 격상시켰다는 데만 있지 않다. 컨테이너의 모든 기술은 이미 오래 전부터 리눅스에 기본적으로 존재했는데, 누군가가 상품화한 이후부터 리눅스 재창조의 동력이 되었다는 점 역시 놀라운 부분이다.

리눅스의 컨테이너 기술 중 가장 눈에 띄고 중심이 되는 기술은 도커(Docker)다. 도커는 애플리케이션을 격리 상태로 실행시키고 패키징하고 전달하고 관리하고 스케줄링하는 데 사용되는 소프트웨어 제품이다. 도커는 리눅스 커널에 이미 존재하는 기술을 가져다(주로 cgroup과 namespace) 이를 포장하기 위한 편리한 메타포, 프론트 엔드, 워크플로를 제공했다.

도커가 부상하고 얼마 지나지 않아 사람들은 급진적인 개념들을 실험하기 시작했다. 리눅스의 껍질을 다 벗겨내고 단순한 부팅 메커니즘, 시동 시스템, 그리고 컨테이너를 실행하고 관리하기 위한 수단으로 만들면 어떨까? 네트워킹과 스토리지 관리를 위한 임베디드 리눅스와 같이 컨테이너를 위한 리눅스를 만들면 좋지 않을까? 그렇게 해서 코어OS(CoreOS)가 태어났다.

코어OS는 단순히 색다른 무언가를 위해 만들어진 것이 아니다. 많은 이유가 있지만 그 중 하나는 축소판 리눅스가 관리하고 유지하기 더 쉽고, 공격으로부터 보호하기 쉽고, 하트블리드(Heartbleed) 또는 셸쇼크(Shellshock)에 직면한 경우 되살리기도 더 쉬울 것이라는 데 있다.

도커의 성공과 코어OS의 실험에 자극을 받은 다른 리눅스 배포판들도 비슷한 개념을 시도하기 시작했다. 레드햇은 제품군 전반에 대규모 컨테이너 실행 지원을 내장했고, 컨테이너 중심의 자체 리눅스인 레드햇 아토믹 호스트(Atomic Host)도 출시했다.

어떤 면에서 아토믹 호스트는 코어OS와 비슷하다. 즉, 컨테이너를 실행하는 것 외의 다른 기능은 거의 없는 간소화된 리눅스 버전이다. 그러나 레드햇의 의도는 단순히 미니멀한 시스템을 만들고 끝내는 것이 아니었다. 대신 레드햇은 아토믹 호스트를 전체 리눅스 배포판을 구축하기 위한 기반으로 삼고 컨테이너를 사용해 플랫폼에서의 소프트웨어 설치를 관리하는 방법을 택했다. 아직 전통적인 리눅스 패키지 관리의 필요성을 완전히 대체하지는 못했지만 보완적인 기능을 제공한다.

캐노니컬(Canonical)도 마찬가지로 컨테이너 기반인 스내피(Snappy) 애플리케이션 패키징 시스템을 통해 이와 유사한 방식을 도입했다. 원래 우분투 폰 OS에 업데이트를 배포하기 위한 목적으로 개발된 스내피는 컨테이너를 사용해서 데이터베이스 트랜잭션과 같은 방식으로 소프트웨어 설치를 처리한다.

유니커널 : 딱 필요한 만큼만

커널과 일부 컨테이너만 남길 정도로 간소화한 리눅스마저 무겁다고 생각한 사람들은 커널과 애플리케이션 하나만 남기고 그 외의 불필요한 것은 아무것도 포함하지 않는 리눅스 프로젝트를 시작했다. 이른바 "유니커널" 접근 방법이다.

유니커널은 컨테이너와 마찬가지로 새로운 개념이 아니다. 수십 년 전부터 형태를 달리하며 계속 존재해왔다. 유니커널은 작은 크기와 빠른 부팅, 최소화된 공격 표면을 대표적인 장점으로 내세우지만, 만들기는 더 복잡하다. 전통적으로 이러한 프로젝트는 리눅스를 채택하지 않고 전용으로 만든 맞춤형 커널을 사용하거나 젠 프로젝트(Xen Project)의 미니OS(MiniOS)와 같이 최소화된 커널을 기반으로 사용했다.

리눅스를 유니커널의 기반으로 사용할 수 있는 한 가지 방법은 "라이브러리 OS" 형태다. 여기서 사실상 리눅스 커널은 애플리케이션에 연결되는 거대한 코드 라이브러리가 된다. 그라핀 라이브러리 OS(Graphene Library OS)가 이 방식을 사용하는 프로젝트로, 부팅 가능한 커널 안에 "네이티브 비수정 리눅스 애플리케이션"을 내장하는 형태로 컴파일이 가능하다.

유니커널과 리눅스의 또 다른 눈에 띄는 예는 도커에서 찾아볼 수 있다. 도커는 다양한 시나리오에서 유니커널을 유니커널 시스템즈(Unikernel Systems)를 인수했고, 그 기술 일부를 맥 및 윈도우용 도커 제품에 적용했다. 원래 데스크톱에서 도커를 실행하려면 버추얼박스(VirtualBox) 기반의 온전한 리눅스 배포판을 부팅해야 했지만 이제 각 플랫폼의 네이티브 가상화 기술을 사용해 도커 엔진이 내장된 맞춤형 리눅스 커널을 부팅하면 된다.

유니커널을 향한 길에 모두가 동참하는 것은 아니다. 특히 유니커널에 대한 도커의 관심은 많은 비판을 촉발하기도 했다. 조이엔트(Joyent)의 브라이언 캔트릴은 유니커널이 "프로덕션용으로는 맞지 않다"고 주장했다. 단점이 장점보다 많다는 것이 이유인데, 캔트릴이 꼽은 단점은 모든 것이 하나의 프로세스에서 실행되는 점, 유니커널은 디버그하기가 어렵다는 점, 유니커널을 만드는 데 사용된 언어와 개발 스택에 대한 종속성을 유발한다는 점이다. 코어OS의 알렉스 폴비 역시 거의 비슷한 이유로 유니커널에 대해 회의적이다. 그러나 지금까지 도커의 계획은 특정 사용 사례, 즉 데스크톱에 맞춰져 있으며 컨테이너를 일방적으로 대체하려는 움직임은 없다.

항상 다음 단계가 있다

이러한 모든 프로젝트에서 진정한 혁신은 리눅스를 "미니멀"하게 만드는 데 있지 않다. 소용량 리눅스 배포판은 예전부터 리눅스 세계의 대표적인 산물이다. 새로운 점은 소프트웨어 제공, 관리, 유지보수, 그리고 시스템 관리와 유지보수 분야의 오랜 문제점들을 리눅스의 중심에 있는 요소를 새롭고 창의적으로 응용하여, 또는 리눅스 커널 자체의 새롭고 창의적인 사용을 통해 해결하는 그 방법에 있다.

이제부터 어디로 가게 될까? 우선 도커 스타일의 컨테이너(컨테이너를 움직이는 기반 커널 기술이 아니라)를 리눅스의 일부로서 더 깊숙이 집어넣을 것인지에 대한 논란과 그에 따른 갈등이 일어나게 될 것이다. 이러한 마찰을 볼 수 있는 한 가지 예는 '컨테이너 런타임을 어떻게 리눅스 시스템 서비스로 처리할 것인가'라는 질문이다. 애초에 리눅스에서 시스템 서비스를 어떻게 처리할 것인지에 관한 이전의 논란도 아직 진행 중이니, 상황은 더 악화되는 셈이다. 컨테이너가 OS의 일부인지, 사용자 공간의 추가 요소인지, 이 두 가지의 혼합인지도 불명확하다. 최선의 결론을 도출하기 위한 유일한 방법은 끊임없이 실험하고 어떤 모델이 가장 보편적인 이점을 제공하는지 확인하는 것이다.

유니커널과 리눅스의 미래는 이 두 가지가 가장 잘 조화되는 분야와 그 이유를 찾는 데 있다. 유니커널 운영 모드는 컨테이너 대체를 목적으로 하지 않는다. 이전에는 존재하지 않았거나 부족한 구현으로 인해 진지하게 고려되지 않았던 가능성을 열어준다.

리눅스에 대한 근본적인 우려 중 하나는 파편화다. 리눅스 구현의 다양성으로 인해 일관성을 보장하기가 어렵다. 안드로이드, 또는 데스크톱 환경으로서의 리눅스와 같은 소비자 제품 측면에 관한 논의에서도 중요한 문제지만, 다른 요소를 위한 기반으로서의 리눅스(리눅스 사용 형태의 상당 부분을 차지하는)에서는 또 다른 문제다.

이러한 종류의 발명과 실험은 "단편화"가 아니라 자르고 붙이고 봉해서 필요에 맞게 새로운 모양으로 만들 수 있는 원자재라는, 리눅스가 항상 지향해온 본질이다.