"예전엔 개발하기 빡셌지만…" AI 시대에 다시 뜨고 있는 유니커널 근황

요약 과거 개발자들 사이에서 '유니커널(Unikernel)'은 매력적인 개념이지만 지나치게 구현이 어렵다는 평가를 받았습니다. 일반적인 운영체제(OS)처럼 유저랜드나 셸이 따로 존재하는 것이 아니라 애플리케이션 자체가 곧 하나의 운영체제로 동작하는 방식이라, 웹 서버나 DNS는 물론 외부 API 호출에 필요한 라이브러리까지 모두 직접 밑바닥부터 구현해야 했기 때문입니다. 저장장치 드라이버조차 부족해 다른 OS의 코드를 긁어와야 할 정도로 진입장벽이 높았습니다. 하지만 생성형 AI 코딩 도구의 등장으로 상황이 완전히 뒤집혔다는 주장이 제기되었습니다. 유니커널과 Nix, Bazel처럼 복잡하고 방대한 도메인 지식들이 이미 대규모 언어 모델에 학습되어 있어, 프롬프트 입력과 자동화된 루프만으로도 필요한 라이브러리를 손쉽게 포팅할 수 있게 되었기 때문입니다. 예를 들어 OCaml 기반 유니커널에 스트라이프(Stripe) 결제 라이브러리가 없다면, 기존 Go 언어 라이브러리를 AI 에이전트 루프에 넣어 순식간에 OCaml로 변환해 버리면 그만이라는 설명입니다. 실제로 복잡한 파일 시스템 도구를 러스트(Rust)로 몇 시간 만에 바이트 단위까지 완벽하게 재구현해 낸 사례도 소개되었습니다. 또한 저자는 지난 수십 년간 이어져 온 'OS 위에 애플리케이션을 얹는 구조' 자체가 사람 작업자가 직접 터미널을 다루던 시절에 만들어진 거대한 '설계 부채'라고 지적합니다. 일반적인 서버 환경에서는 공격자가 애플리케이션 취약점을 뚫으면 셸을 얻어 내부 침투를 이어가지만, 셸이나 인터프리터가 전혀 없는 유니커널 환경에서는 해커나 자동화된 공격 모델이 다음 단계로 넘어갈 수 없어 보안상으로도 훨씬 안전해집니다. 여기에 S3를 무한 확장 가능한 기본 저장소로 삼고 로컬 NVMe 캐시를 붙이는 클라우드 아키텍처까지 더해지면서, AI 시대에 유니커널이 다시금 현실적인 대안으로 떠오르고 있습니다.