LXC, 도커가 딛고 선 리눅스 컨테이너의 기반 기술
cgroups·namespaces로 구현되는 LXC의 동작 원리와 Docker·VM 대비 언제 선택하는지를 정리한다
2026-08-12 · 최초 발행 2026-01-12
컨테이너라고 하면 대개 Docker를 먼저 떠올리지만, Docker가 격리를 구현하는 데 쓰는 커널 기능—cgroups와 namespaces—은 LXC(Linux Containers)가 먼저 정리해 놓은 것이다. LXC는 하이퍼바이저 없이 호스트 커널을 공유하면서도 격리된 사용자 공간을 제공하는 OS 수준 가상화 기술로, 오버헤드를 최소화하는 대신 완전한 하드웨어 격리는 포기한다.
하이퍼바이저를 빼면 뭐가 달라지는가
전통적인 하이퍼바이저 기반 가상화는 Guest OS 전체를 실행하고 하드웨어를 에뮬레이션한다. 높은 리소스 오버헤드를 감수하는 대신 완전한 격리를 얻는다. LXC 같은 컨테이너 기반 가상화는 호스트 커널을 그대로 공유해 네이티브에 가까운 성능과 낮은 오버헤드를 얻지만, 격리 수준은 프로세스 단위로 낮아진다. 이 트레이드오프—성능이냐 격리냐—가 가상화 기술을 고를 때 항상 따라오는 질문이다.
cgroups와 namespaces가 전부다
cgroups(Control Groups)는 2006년 Google이 개발한 커널 기능으로, 프로세스 그룹의 리소스 사용량을 제한하고 격리한다. CPU 시간 할당량, 메모리 사용량 상한, 디스크 I/O 대역폭, 네트워크 대역폭, 최대 프로세스 수를 각각 통제할 수 있다. cgroups v2는 이를 단일 통합 계층 구조로 정리해 인터페이스를 단순화했다.
namespaces는 커널 리소스를 파티셔닝해 프로세스마다 독립적인 시스템 뷰를 만든다. PID(프로세스 ID), Network(네트워크 스택), Mount(파일시스템 마운트 포인트), UTS(호스트명·도메인명), IPC(프로세스 간 통신), User(사용자·그룹 ID), Cgroup(cgroup 루트 디렉토리), 그리고 리눅스 5.6부터 추가된 Time(시스템 시간)까지 여덟 종류가 각기 다른 리소스를 격리한다. 컨테이너 안에서 PID 1번이 실제로는 호스트에서 전혀 다른 PID로 보이는 것, 컨테이너마다 별도의 네트워크 인터페이스를 갖는 것 모두 이 namespaces 덕분이다.
이 두 기능을 감싸는 게 liblxc라는 C로 작성된 핵심 라이브러리이고, 그 위에 lxc-create(생성)·lxc-start(시작)·lxc-stop(정지)·lxc-attach(접속)·lxc-info(정보 조회) 같은 명령행 도구와 Ubuntu·Debian·CentOS 등 배포판별 템플릿이 얹힌다. lxc-create가 템플릿 스크립트를 실행해 루트 파일시스템과 설정 파일을 만들고, lxc-start가 PID·Network·Mount namespace를 생성한 뒤 cgroups를 설정하고 init 프로세스를 띄우는 순서로 컨테이너가 Running 상태에 이른다.
LXC와 Docker는 같은 기반, 다른 지향점
두 기술 모두 OS 수준 가상화이고 커널을 공유하며 초 단위로 시작한다는 점은 같다. 갈리는 지점은 컨테이너가 뭘 담도록 설계됐는가다. LXC는 시스템 컨테이너를 지향한다—완전한 OS 환경을 제공해 다중 프로세스를 돌리고, 전통적인 서버 운영과 비슷한 방식으로 다룬다. Docker는 애플리케이션 컨테이너를 지향한다—단일 프로세스를 권장하고 이미지 레이어 시스템으로 마이크로서비스에 최적화된다. VM을 대체해 서버를 통합하려는 목적이면 LXC 쪽 사고방식이, 마이크로서비스와 CI/CD 파이프라인을 돌리려는 목적이면 Docker 쪽 사고방식이 자연스럽다. KVM이나 VMware 같은 하드웨어 수준 가상화와 비교하면 LXC와 Docker 둘 다 시작 시간(초 단위 vs 분 단위)과 오버헤드(매우 낮음/낮음 vs 높음) 면에서 압도적으로 가볍지만, 격리 수준은 중간에 머문다는 것도 공통점이다.
커널을 공유한다는 것의 보안적 의미
LXC는 AppArmor·SELinux로 필수 접근 제어(MAC)를 걸고 컨테이너별 보안 프로파일을 적용하며, seccomp로 시스템 콜을 화이트리스트·블랙리스트 방식으로 필터링해 공격 표면을 줄이고, capabilities로 루트 권한을 세분화해 필요한 권한만 부여한다. 이 세 겹의 방어가 다층 보안 메커니즘과 커널 수준 격리, 리소스 제한을 통한 DoS 방지를 만들어낸다.
하지만 근본적인 제약은 남는다—커널을 공유한다는 것 자체가 위험 요소다. 호스트 커널에 취약점이 있으면 그 영향 범위가 모든 컨테이너로 확대되고, 이론적으로는 컨테이너에서 호스트로 탈출(escape)하는 경로가 생길 수 있다. VM처럼 하드웨어 수준에서 격리된 환경과 달리, LXC의 격리는 결국 같은 커널 안에서의 논리적 격리라는 한계를 안고 간다.
실제로 쓰이는 자리
격리된 개발 환경을 빠르게 만들고 지우거나 다양한 배포판을 테스트할 때, 물리 서버를 통합해 리소스 효율을 높이고 운영 비용을 줄일 때, CI/CD 파이프라인에서 빌드 환경을 격리하고 일관된 테스트 환경을 확보할 때, 그리고 멀티테넌트 클라우드 환경에서 컨테이너 오케스트레이션과 마이크로서비스를 배포할 때—이 네 가지가 LXC가 실제로 선택되는 맥락이다. 다만 마이크로서비스·CI/CD 쪽은 이제 Docker가 사실상 표준 자리를 차지했고, LXC는 완전한 OS 환경이 필요한 시스템 컨테이너·서버 통합 용도로 더 자주 남아 있다.