유니커널, 이름은 들어봤지만 써본 적은 없는 기술
유니커널(unikernel)이라는 말을 들어보셨나요? 클라우드 네이티브 이야기가 나올 때마다 '언젠가 컨테이너를 대체할 기술'로 잠깐 등장했다가 조용히 사라지곤 했던 이름이에요. 이번에 소개할 글은 제목부터 도발적인데요. 우리말로 옮기면 '유니커널은 어려웠다. 핵심은 과거형이라는 것' 정도예요. 이제는 더 이상 어렵지 않다는 주장이죠.
글쓴이 Geoffrey Huntley는 AI 코딩 에이전트를 극한까지 밀어붙이는 실험으로 알려진 개발자예요. 이번 글에도 그 관점이 깔려 있어요. 예전에 유니커널을 가로막던 장벽은 상당 부분 '사람이 해야 할 일의 양' 문제였고, 그 일을 에이전트가 대신 하기 시작하면서 판이 바뀌었다는 이야기예요.
유니커널이 뭐냐면
애플리케이션 하나와, 그 앱이 꼭 필요로 하는 OS 기능만 묶어서 하나의 실행 이미지로 만든 것이에요. 보통 서버에 앱을 띄우면 하드웨어(또는 하이퍼바이저) 위에 리눅스 같은 범용 커널이 있고, 그 위에 셸, 패키지 매니저, 각종 데몬과 라이브러리가 깔린 다음 맨 위에 내 앱이 올라가요. 컨테이너도 결국 호스트의 리눅스 커널을 같이 쓰면서 그 위에 격리된 공간을 만드는 방식이고요.
유니커널은 이 층들을 확 접어버려요. 내 앱 코드에 네트워크 스택, 메모리 관리, 필요한 드라이버 정도만 라이브러리처럼 링크해서 하이퍼바이저 위에서 바로 부팅되는 바이너리 하나를 만드는 거예요. 그래서 '라이브러리 OS'라고 부르기도 해요.
비유하자면 범용 OS는 온갖 공구가 다 들어 있는 대형 공구함이고, 유니커널은 오늘 작업에 쓸 드라이버 두 개만 챙겨 나온 파우치 같은 거예요. 그래서 장점이 꽤 확실하거든요.
- 부팅이 빨라요. 밀리초 단위로 뜨는 경우가 많아서 서버리스나 요청 단위 실행과 잘 맞아요.
- 이미지가 작아요. 몇 MB 수준까지 줄일 수 있어요.
- 공격 표면이 작아요. 셸도 없고 쓸데없는 서비스도 없으니, 침입하더라도 할 수 있는 게 거의 없어요.
- 커널 모드와 유저 모드를 오가는 비용이 줄어서 일부 워크로드에선 성능 이점도 있어요.
그런데 왜 다들 안 썼을까
문제는 이 장점을 얻는 비용이 너무 컸다는 거예요.
첫째는 호환성이에요. 리눅스가 수십 년 동안 쌓아온 시스템 콜, 파일시스템, 스레드, 시그널 같은 POSIX 기능을 유니커널 쪽에서 다시 구현해야 하는데, 이게 끝이 없어요. 앱 하나 올리려다가 fork()가 없어서 막히고, epoll 동작이 미묘하게 달라서 또 막히는 식이죠.
둘째는 드라이버예요. 가상 NIC, 블록 디바이스처럼 클라우드마다 조금씩 다른 가상 하드웨어를 지원하려면 드라이버를 직접 짜야 해요. 리눅스는 이걸 수천 명의 기여자가 해결했지만, 유니커널 프로젝트는 소수 인원으로 버텨야 했어요.
셋째는 디버깅과 운영 도구예요. 셸이 없다는 건 보안상 장점이지만, 장애가 났을 때 ssh로 들어가서 top 한 번 쳐보는 것도 못 한다는 뜻이에요. 관측성(observability, 시스템 내부 상태를 밖에서 들여다보는 능력) 도구를 처음부터 다시 만들어야 했죠.
MirageOS(OCaml), IncludeOS(C++), Unikraft, NanoVMs의 Nanos 같은 프로젝트들이 꾸준히 도전했고 기술적으로도 의미 있는 성과를 냈어요. 그래도 들인 노력에 비해 얻는 게 적어서, 컨테이너와 Kubernetes 생태계를 넘어서진 못했어요.
무엇이 바뀌었나: 반복 작업을 에이전트가 맡는다
글쓴이의 핵심 논지가 여기서 나와요. 위의 장벽들을 다시 보면, 상당수가 '원리는 알지만 양이 너무 많아서 못 하는 일'이에요. 시스템 콜을 하나씩 구현하고, 스펙 문서를 보면서 드라이버를 짜고, 테스트가 실패하면 고치는 반복 작업이죠. 이런 일은 명세가 분명하고, 성공했는지 실패했는지를 기계가 판정할 수 있다는 특징이 있어요.
이게 요즘 AI 코딩 에이전트가 제일 잘하는 유형의 일이거든요. 테스트 스위트나 스펙처럼 정답을 판정해 주는 기준만 있으면, 에이전트를 루프로 돌려서 '실패, 수정, 재시도'를 사람 대신 수백 번 반복시킬 수 있어요. 예전 같으면 팀 단위로 몇 달 걸렸을 호환성 레이어 작업도, 한 사람이 에이전트를 잘 지휘하면 훨씬 짧은 시간에 굴러가는 거예요.
물론 이제 유니커널이 모든 걸 대체한다는 뜻은 아니에요. 설계 판단, 보안 검증, 성능 튜닝은 여전히 사람의 몫이에요. 다만 '엄두가 안 나서 시도조차 안 하던 영역'의 진입 장벽이 내려갔다는 게 이 글의 메시지예요.
업계 맥락
흥미로운 건, 유니커널과 같은 문제의식이 이미 다른 형태로 주류에 들어와 있다는 점이에요. AWS Lambda를 떠받치는 Firecracker 마이크로VM은 '최소한의 가상 하드웨어로 빨리 띄우기'라는 같은 목표를 리눅스 기반으로 풀었어요. gVisor는 시스템 콜을 가로채서 다시 구현하는 방식으로 격리를 강화했고요. WebAssembly와 WASI도 '필요한 기능만 열어주는 가벼운 실행 환경'이라는 점에서 같은 계보로 볼 수 있어요. 유니커널은 이 스펙트럼에서 가장 극단에 있는 선택지인데, 그 극단을 택하는 비용이 낮아지면 어떤 선택지가 현실적인지도 달라질 수 있어요.
한국 개발자에게 주는 시사점
당장 운영 환경에 유니커널을 도입하라는 이야기는 아니에요. 서버리스나 엣지 함수를 많이 쓰는 팀이라면 콜드 스타트와 격리 문제를 보는 시야를 넓혀둘 만해요. Unikraft나 Nanos는 지금도 직접 빌드해볼 수 있거든요.
그보다 중요한 건 사고방식이에요. 예전에 일이 너무 많아서 포기했던 작업 목록을 다시 꺼내볼 때라는 거죠. 레거시 마이그레이션, 프로토콜 재구현, 사내 도구 포팅처럼 명세와 테스트가 분명한 작업이 대표적이에요. 그리고 에이전트를 잘 쓰려면 좋은 테스트와 명확한 스펙이 먼저 있어야 한다는 것도 기억해두세요. 정답을 판정할 기준이 없으면 에이전트는 그럴듯한 오답을 끝없이 만들어내요.
마무리
한 줄 정리: 유니커널을 막고 있던 건 기술보다 일의 양이었고, 그 일을 AI 에이전트가 맡기 시작했어요.
여러분 팀에도 '좋은 건 아는데 손이 너무 많이 가서' 미뤄둔 기술이나 프로젝트가 있나요? 에이전트와 함께라면 다시 시도해볼 만하다고 보시나요?
🔗 출처: Hacker News