클라우드용 OS란 정확히 무엇을 뜻하는 건가? 장치 모델은 KVM이나 반가상화에 맡기고, FTL 게스트 OS가 VM 안에서 여러 작업을 안전하게 격리해 실행한다는 뜻인가?
아니면 실제 하드웨어에서 직접 실행할 OS를 처음부터 만드는 건가? Linux의 모든 기능을 다시 구현하지 않으려면 하드웨어 지원 범위를 어떻게 제한할 계획인가? 배포할 장비를 미리 알 수 있어서 클라우드용이라고 부르는 건지, 아니면 커널 개발 관점에서는 하드웨어 지원이 프로세스·스케줄링·메모리 관리보다 상대적으로 쉬운 건지 궁금함.
혹은 마이크로커널 구조라면 Linux의 모든 기능과 그 이상까지 구현할 수 있다는 데 거는 건가? 현재 구현만 보면 첫 번째 해석에 가까워 보이지만, 궁금한 것은 프로젝트의 최종 목표임.
나는 에이전트에게 내 앱과 하드웨어에 맞는 어셈블리를 생성하게 하고, 곧바로 그 코드로 부팅함.
농담으로 쓴 건가? 실제로 컴퓨팅의 미래가 그쪽으로 갈 가능성이 상당히 높다고 봄. https://www.youtube.com/watch?v=kZRE7HIO3vk에서 Casey는 각자 커널을 만들던 시절에 소프트웨어가 더 효율적이었다는 취지로 이야기했다가, 지금은 불가능하다는 비판을 많이 받았음. 게임마다 부팅 가능한 USB가 딸려 오면 멋지겠다는 이야기도 하는데, 당시에는 상상하기 어려웠지만 이제는 점점 현실에 가까워지고 있음.
예를 들어 내게는 Lisp 방언으로 작성하고 네이티브 기계어로 컴파일하는 임베디드용 마이크로커널이 있음. 약 7만 줄을 전부 LLM으로 생성했고, 벤치마크에서 다른 임베디드 커널 프로젝트 대부분보다 상당히 빠르게 동작함. API 비용을 모두 포함한 토큰 비용은 약 1,500달러였음.
그건 오히려 https://github.com/H4vC/oh-my-uefPi에 해당함. BOOTX64.EFI 파일 하나로 Hyper-V VM을 채팅 프롬프트로 바로 부팅하고, OpenAI 호환 /v1/chat/completions 엔드포인트에서 응답을 스트리밍함. 기본 모델은 DeepSeek이며, 모델에 요청하면 Omarchy, netboot.xyz 또는 HTTP(S) URL의 UEFI 이미지로 부팅할 수 있음. OS도 대화 기록도 없고, 재미 삼아 omp처럼 꾸며 놓았음.
Unikraft보다는 gVisor에 더 가까워 보이는데, 호출을 가로채는 경로가 좀 더 빠른 구조인가?
나도 처음에 그렇게 생각함. 선행·관련 작업을 비교하는 FAQ를 명확하게 제공하면 도입이 늘어날 것 같음. 독자가 사람이든 AI든 직접 차이를 추론하게 두지 않는 편이 좋겠음.
둘 다 닮은 것 같음. 자체 게스트로 실행되지만 Linux와 일대일로 대응하는 시스템 호출을 구현하는 대신, Linux를 라이브러리로 실행하고 더 간소한 호출 집합을 통해 게스트로 진입하는 구조로 보임.
그래서 비용이 더 낮지는 않을 것 같음. 일반적인 경로가 gVisor의 syscall → vmexit 대신 프로세스 → 게스트로 시스템 호출 → 하이퍼바이저로 vmexit일 수도 있다는 추측임.
FTL v0.1.0이 막 출시됐고, 비동기 Rust 지원과 Linux 호환 계층에서 빠져 있던 여러 기능이 추가됨. 비동기 실행에는 다중 스레드 Tokio 런타임을 사용함.
내가 만드는 프로젝트는 아님.
마이크로커널 비슷한 구조인가? Linux 프로그램을 실행하고 자체 웹사이트를 서비스할 만큼 기능도 갖췄다니 훌륭함. 잘 성장하길 바람.
전형적인 엑소커널(exokernel) 임. 운영체제 교과서들이 이 개념을 너무 형편없이 설명해서, 누가 일부러 그렇게 쓰라고 돈이라도 주는 것처럼 느껴질 정도임.
핵심은 커널에 무조건 최소한만 남기는 게 아니라, 최소한의 추상화로 하드웨어를 나눠 쓰는 데 필요한 기능을 남기는 데 있음. 네트워크 드라이버는 커널에 넣더라도 TCP 스택까지 넣어야 할까? 디스크 드라이버는 넣더라도 VFS까지 넣어야 할까?
여기에 보안 장치를 더해 빠른 실행 경로가 사용자 공간의 추상화 서비스를 거치지 않도록 함. BPF 같은 장치로 프로세스가 자신이 연 포트의 패킷만 커널 장치 드라이버에서 직접 받게 할 수 있음. 파일 시스템 서비스는 프로세스가 정상적으로 연 파일에 해당하는 디스크 블록에 대해 철회 가능한 접근 권한을 발급하는 식임.
최소 권한 원칙을 따르면서 Unix답고 Linux와도 호환되는 운영체제가 있으면 좋겠음.
Linux의 네임스페이스, cgroups, seccomp는 복잡하게 뒤엉켜 있지만, 실제 기능은 OS X나 Windows가 제공하는 것보다 나을 가능성이 높음.
더 나은 구조를 만들 수 있지 않을까? 다만 이 프로젝트가 그걸 추구하는지는 모르겠음.