컨테이너와 가상머신(VM) 사이의 오래된 긴장 관계를 정면으로 겨냥한 프로젝트가 등장했다. FTL은 스스로를 '클라우드를 위한 새로운 운영체제'라고 소개하는데, 그 핵심 발상은 단순하면서도 낯설다. 각 컨테이너가 공유하는 호스트 커널에만 의존하는 대신, 컨테이너마다 사용자 공간(userspace)에서 동작하는 자체 OS를 하나씩 들고 돌아간다는 것이다. 이 사용자 공간 OS는 별도의 무거운 런타임이 아니라 하나의 공유 라이브러리 형태로 제공되며, 리눅스 프로세스나 VFS(가상 파일시스템), TCP/IP 같은 전통적인 운영체제 개념의 상당 부분을 그 안에서 직접 구현한다.
하이퍼바이저를 닮은 최소 커널
FTL의 구조를 이해하는 열쇠는 '커널이 무엇을 하지 않는가'에 있다. FTL 커널은 리눅스 시스템 콜을 사용자 공간에서 구현할 수 있도록 하는 최소한의 인터페이스만 제공한다. 프로젝트 측은 이 역할을 하이퍼바이저에 비유한다. 하이퍼바이저가 게스트 OS에 하드웨어에 가까운 얇은 경계만 제공하고 나머지는 게스트가 알아서 처리하듯, FTL 커널도 시스템 콜 구현의 실체를 위쪽 라이브러리로 밀어 올린다. 즉 파일시스템이나 네트워크 스택 같은 실제 로직은 커널 안이 아니라 각 컨테이너가 품고 있는 사용자 공간 OS 안에서 돌아간다.
이 설계는 마이크로커널과 모놀리식 커널 사이의 해묵은 선택을 절충하려는 시도다. FTL은 마이크로커널의 장점으로 유연성과 보안을, 모놀리식 커널의 장점으로 성능과 단순함을 꼽으며 둘을 함께 취하는 것을 목표로 내세운다. 전통적으로 마이크로커널은 기능을 잘게 쪼개 격리하는 대신 메시지 전달 비용 탓에 성능 손해를 감수해야 했고, 모놀리식 커널은 빠르지만 거대한 공유 영역이 공격면과 복잡도를 키웠다. FTL은 OS 기능 대부분을 각 컨테이너의 라이브러리 안으로 옮김으로써, 격리는 프로세스 경계에서 확보하되 실행은 한 덩어리로 이어 붙이는 쪽을 택한 셈이다.
노리는 지점: 컨테이너의 격리, VM 없이
FTL이 풀려는 실무적 과제는 분명하다. 컨테이너는 가볍고 빠르지만 호스트 커널을 공유하기 때문에 격리 수준이 VM에 미치지 못한다는 지적을 오래 받아 왔다. 커널에서 발견되는 취약점 하나가 그 커널을 공유하는 모든 컨테이너에 영향을 줄 수 있기 때문이다. 그래서 더 강한 격리가 필요한 환경에서는 결국 VM이나 경량 VM 계열 기술로 되돌아가곤 했다. FTL은 '가벼운 컨테이너를 VM만큼 안전하게' 만드는 것을 목표로 제시하며, 성능을 희생하지 않으면서 그 격차를 좁히겠다고 말한다. OS 로직이 컨테이너별 사용자 공간으로 내려오면, 한 컨테이너의 OS 상태가 다른 컨테이너와 뒤섞이는 면이 줄어든다는 논리다.
개발자 관점에서 더 흥미로운 대목은 확장성이다. FTL은 사용자 공간 OS 설계 덕분에 리눅스 커널 기능 대부분을 커널 프로그래밍이나 eBPF 없이도 확장할 수 있다고 설명한다. 운영체제가 '그냥 라이브러리'이기 때문에, 디버깅용 printf를 끼워 넣거나 보안 업데이트를 적용하거나 새로운 기능을 추가하는 일을 빠르고 안전하게 할 수 있다는 것이다. 커널 모듈을 다뤄 본 사람이라면 이 차이의 무게를 안다. 커널 공간에서의 실수는 시스템 전체를 멈추게 하지만, 사용자 공간 라이브러리 수준의 실험은 실패하더라도 영향 범위가 그 컨테이너 안에 머문다.
실무자가 따져봐야 할 한계
다만 공개된 정보만으로는 신중하게 볼 지점이 적지 않다. FTL은 리눅스 시스템 콜을 사용자 공간에서 재구현하는 구조인데, 리눅스 ABI는 방대하고 가장자리 동작이 많아 호환성의 완성도가 실사용 가치를 좌우한다. 어떤 시스템 콜을, 어느 수준까지 지원하는지, 기존 컨테이너 이미지를 수정 없이 그대로 돌릴 수 있는지는 아직 이 소개만으로 확인하기 어렵다. 성능 역시 '희생하지 않는다'는 선언은 있으나 구체적인 벤치마크나 비교 수치는 제시돼 있지 않아, 사용자 공간으로 로직을 옮길 때 통상 따라오는 오버헤드를 실제로 어떻게 상쇄하는지는 검증이 필요하다.
그럼에도 FTL이 던지는 문제의식은 한국의 클라우드·플랫폼 엔지니어에게도 낯설지 않다. gVisor처럼 사용자 공간에서 시스템 콜을 가로채 격리를 강화하려는 접근이나, 라이브러리 OS·유니커널 계열의 실험은 이전에도 있었다. FTL은 그 계보 위에서 'OS를 컨테이너마다 들려 보내는 라이브러리'라는 각도로 격리와 확장성, 성능을 동시에 잡겠다고 주장하는 쪽이다. 지금 단계에서 도입을 저울질하기보다는, 호환성 범위와 성능 특성, 실제 운영 사례가 공개되는 시점에 다시 들여다보는 편이 합리적이다. 컨테이너의 격리 한계를 VM으로 되돌아가지 않고 해결하려는 시도가 어디까지 현실성을 확보하는지, 지켜볼 만한 가치가 있는 프로젝트다.