“Unikernels were hard. Key word: were. Now we have AI.”
2026년 10월, Geoffrey Huntley는 한 기술 대담에서 이렇게 단언했습니다. 맞은편에 앉은 이는 MirageOS의 초기 핵심 개발자인 Justin Cormack이었습니다. 10년 전 가상머신 위에서 애플리케이션을 직접 구동하기 위해, 개발팀은 NetBSD에서 장치 드라이버를 추출해 C 언어 코드를 사용자 공간으로 일일이 포팅해야 했습니다.
유니커널(Unikernel)은 단일 주소 공간 아키텍처를 채택합니다. 애플리케이션 자체가 곧 운영체제이며, 이미지 안에는 독립된 프로세스 구분도, 상호작용 가능한 셸도 존재하지 않습니다. 개발자가 네트워크 패킷을 주고받거나 도메인을 해석하려면 외부 호스트 환경에 의존할 수 없습니다. 모든 저수준 드라이버와 프로토콜 스택을 바이너리 이미지 안에 직접 컴파일해 넣어야 합니다.
지난 10년 동안 가파른 툴체인 학습 곡선과 부족한 생태계 때문에 이 기술은 오랫동안 외면받았습니다. 오늘날 대형 언어 모델의 등장은 전용 라이브러리를 작성하는 진입 장벽을 완전히 허물었습니다. 하지만 개발 장벽이 낮아졌다고 해서, 이 아키텍처가 본질적으로 지닌 보안 논쟁까지 해결된 것은 아닙니다.
그림: 유니커널을 군더더기 없는 디지털 코어로 표현한 개념 일러스트. 출처: ghuntley.com
모델 가중치가 짊어진 저수준 드라이버 작성 부담
Huntley가 보기에 소프트웨어 업계는 오랫동안 낡은 기술적 교조에 갇혀 있었습니다. Nix도 어렵고, Bazel도 어렵고, 유니커널도 어렵다는 편견입니다. 이러한 난관은 본질적으로 구현 디테일이 쌓아 올린 지식의 장벽에 불과했습니다.
모델 가중치는 타입 이론과 수십 년간 축적된 컴퓨터 과학 논문을 흡수했습니다. 과거 수개월이 걸리던 저수준 스캐폴딩 작업이 이제는 프롬프트 몇 줄로 해결됩니다. 숙련된 엔지니어가 C 언어 드라이버 코드를 한 줄씩 옮겨 적을 필요가 없어진 것입니다.
Huntley는 불과 일주일 만에 Spaceleans 프로토타입을 완성했습니다. 그는 마이크로소프트의 Orleans 분산 가상 액터 시스템을 OCaml 환경으로 포팅하여 유니커널 이미지로 제작했습니다. 이 시스템은 여러 대의 물리 머신을 하나의 주소 지정 가능한 힙으로 통합하고, 스토리지에서 필요할 때마다 액터 인스턴스를 즉시 복원해 냅니다.
프로토타입을 가동하려면 런타임 기반 전체를 갖추어야 했습니다. 그는 코드 생성을 활용하여 네트워크 스택, DNS 리졸버, HTTP 클라이언트를 단 7일 만에 완성했습니다. 이어 NTP 시간 동기화, 대형 언어 모델 클라이언트, 분산 트레이싱 기능까지 덧붙였습니다. 본래 전문 시스템 팀이 매달려야 했던 저수준 인프라 작업을 개인 개발자가 며칠 만에 조립해 낸 것입니다.
생태계가 부족하다는 고질적인 반론 역시 코드 생성 앞에서 설득력을 잃었습니다. 과거 유니커널 도입을 반대하던 논거 중 하나는 OCaml 환경에 성숙한 결제 모듈 같은 서드파티 SDK가 없다는 점이었습니다. 하지만 자동화된 에이전트 루프를 작동시키면, 모델이 기존 Go 라이브러리를 몇 시간 만에 OCaml 모듈로 다시 작성해 냅니다.
Rust로 몇 시간 만에 전용 툴체인 복제하기
Cormack의 엔지니어링 실무에서도 비슷한 패러다임 전환이 일어났습니다. 그는 단일 애플리케이션용 리눅스 이미지를 구축하면서 극단적인 경량화를 추구했습니다. 기존 방식대로 디스크를 포맷하려면, 단 한 줄의 명령을 실행하기 위해 거대한 xfsprogs 패키지 전체를 빌드 이미지에 집어넣어야 했습니다.
그는 대신 모델을 활용해 Rust로 전용 mkfs.xfs 도구를 다시 작성하는 방식을 택했습니다. 기존 네이티브 도구를 ‘골든 오라클(golden oracle)’ 삼아, 모델이 생성한 코드의 출력을 원본과 바이트 단위로 대조 검증하고 다양한 블록 크기에서 테스트를 통과시켰습니다. 파라미터 파싱부터 디스크 구조 기록까지, 전용 도구를 만드는 데 걸린 시간은 불과 몇 시간에 불과했습니다.
이러한 워크플로는 전용 시스템 도구를 제작하는 방식을 근본적으로 바꿉니다. 과거 저수준 도구를 가지치기하는 일은 막대한 유지보수 부담을 초래했기에, 개발팀은 비대해진 사용자 공간을 어쩔 수 없이 수용해야 했습니다. 코드 생성과 차분 오라클 검증의 결합은 커스텀 도구 제작 비용을 사실상 무시할 수 있는 수준으로 떨어뜨렸습니다.
클라우드 네이티브 스토리지 인프라의 발전은 로컬 파일시스템에 요구되는 기준을 더욱 낮췄습니다. turbopuffer 같은 최신 아키텍처는 클라우드 객체 스토리지를 주 영속성 계층으로 직접 활용하며, 로컬 NVMe 드라이브는 임시 블록 캐시와 제거 로직만 담당합니다. 영속성을 클라우드에 위임함에 따라 로컬에 복잡한 저널링 파일시스템을 둘 필요가 없어졌으며, 시스템은 객체 스토리지에 기대어 대규모 상태를 안정적으로 다룹니다.
그림: ‘Unikernels in 2026’ 대담 영상 표지. 출처: YouTube / Geoffrey Huntley 채널
운영체제 껍질을 벗긴다고 공격 표면이 사라지지는 않는다
진입 장벽이 낮아지자 보안성을 둘러싼 논쟁은 오히려 한층 첨예해졌습니다. Huntley는 다중 사용자 운영체제를 터미널 시대의 낡은 유물로 규정합니다. 전용 마이크로서비스에는 불필요한 조작 인터페이스가 필요 없으며, 셸과 시스템 인터프리터가 없다면 침입자가 횡적 이동의 발판을 얻지 못해 무차별 스캔 공격도 무력화된다고 주장합니다.
하지만 Cormack은 그 자리에서 신중한 입장을 드러냈습니다. 그는 커뮤니티가 말하는 ‘공격 표면 축소’라는 개념이 오랫동안 공허한 구호에 머물러 있었다고 지적합니다. 컨테이너에서 /bin/sh를 제거하는 것은 간단하지만, 비즈니스 런타임 환경 자체는 여전히 튜링 완전한 해석 능력을 지니고 있습니다. 디스크 쓰기 권한을 차단하더라도 메모리 오염과 ROP 체인을 활용하면 프로그램의 제어 흐름을 얼마든지 가로챌 수 있습니다.
Huntley 역시 초기 설계가 애플리케이션과 커널을 동일한 특권 링에 배치했다는 점을 인정했습니다. 그러나 2026년 시점에서는 링 격리를 추가하는 것 역시 ‘프롬프트 한 번의 거리’에 불과하며, 어떻게 따져보더라도 systemd의 cgroup 설정이 완벽하기만을 기도하는 운영 방식보다는 안전하다고 반박했습니다. Cormack은 그 지점에서 논쟁을 더 밀어붙이지는 않았으나, ‘공격 표면’이라는 개념이 무분별하게 구호로 소비되는 현실에 대한 경계를 늦추지 않았습니다.
가상화 하이퍼바이저 수준의 샌드박스조차 뚫릴 수 있는 현실적 위험이 존재합니다. 대담이 녹화되던 바로 그 주에도, 보안 연구원들이 KVM 탈출 취약점을 발견하여 클라우드 벤더로부터 5만 달러의 포상금을 수령했습니다. 이러한 취약점은 멀티테넌트 호스팅의 격리 기반을 송두리째 뒤흔듭니다. 극도의 보안을 추구하려면 seL4처럼 정형 검증된 시스템으로 전환해야 하며, 단일 바이너리 이미지에 맹목적인 기대를 품는 것은 보안 위험의 위치를 옮겨놓는 것에 불과합니다.
로컬 컴파일 지연이 모델 추론 속도를 갉아먹다
프로그래밍 언어의 선택은 자동화된 개발 효율에 직결됩니다. Huntley는 OCaml을 선호합니다. 명확한 인터페이스가 간결한 컨텍스트를 제공하며, 컴파일러는 몇 초 만에 타입 검증을 완료합니다.
반면 Rust 생태계를 다룬 Cormack은 심각한 마찰에 부딪혔습니다. Rust의 엄격한 타입 시스템은 추론 모델과의 궁합이 뛰어나지만, 무거운 빌드 오버헤드가 반복 작업의 템포를 크게 떨어뜨립니다. 모델이 저수준 구현을 탐색하는 과정에서 환각은 불가피하게 발생하며, 매 빌드마다 발생하는 기나긴 대기 시간은 시행착오 비용을 가파르게 끌어올립니다.
수백만 줄 규모의 코드베이스에서는 컴파일 작업이 머신 리소스를 완전히 고갈시키기도 했습니다. 네 개의 코딩 에이전트가 Rust 코드를 병렬로 컴파일하자마자 디스크 I/O와 CPU 큐가 순식간에 포화 상태에 이르렀습니다. 고성능 서버 환경에서도 컴파일을 기다리는 시간이 모델의 토큰 생성 속도를 일상적으로 앞질렀습니다.
이러한 엔지니어링 현실은 기존의 개발 논리를 뒤흔들고 있습니다. 인간 개발자는 런타임 안정성을 확보하기 위해 느린 컴파일을 기꺼이 감수해 왔습니다. 하지만 에이전트 주도의 시행착오 워크플로에서는 컴파일 지연이야말로 시스템 진화를 가로막는 핵심 병목으로 떠올랐습니다.
엔지니어링 마찰이 걷힌 자리에 드러난 순수한 아키텍처 선택
단일 주소 공간이라는 구상은 결코 시대에 뒤처진 아이디어가 아닙니다. 타입 이론과 학술 논문을 소화한 인공지능 모델은 과거의 엔지니어링 공백을 빠르게 메워가고 있습니다. 드라이버와 네트워크 스택의 자동 생성은 전용 시스템을 구축하는 일정을 수개월에서 며칠 단위로 단축했습니다.
하지만 구현 마찰이 사라졌다고 해서 컴퓨터 아키텍처의 기본 원칙까지 바뀐 것은 아닙니다. 스캐폴딩을 걷어내고 나면 개발자가 마주하는 것은 유니커널의 날것 그대로의 본질입니다. 그것은 여전히 하드웨어 수준의 특권 링 격리가 결여되어 있으며, 메모리 안전성에 극도로 민감한 단일 프로세스 샌드박스입니다.
AI가 허문 것은 어디까지나 입장권의 가격일 뿐입니다. 개발자는 더 이상 장치 드라이버를 직접 작성하는 고통에 시달리지 않아도 되지만, 단일 특권 도메인이 초래하는 시스템 리스크에는 정면으로 맞닥뜨려야 합니다. 기존 운영체제가 제공하던 풍부한 디버깅과 관측 생태계를 내려놓을 것인가는 여전히 신중한 저울질이 필요한 엔지니어링 선택입니다.
참고 링크:
- Ignore Previous Directions: Unikernels in 2026 (Justin Cormack)
- Geoffrey Huntley: Unikernels were hard. Key word: were.
- Spaceleans 프로젝트 설계 메모 및 MirageOS 회고
