요약
FTL은 OS 기능 대부분을 컨테이너마다 따로 도는 사용자 공간 라이브러리로 옮긴 클라우드용 운영체제입니다.
개발자 누타 세이야가 Rust로 만든 실험적 운영체제입니다. 리눅스 같은 모놀리식 커널(OS 기능을 커널 하나에 모은 구조)은 확장하기 어렵다고 보고, 지금의 좋은 아이디어를 모아 커널을 처음부터 다시 설계했습니다.
왜 중요한가
- 가벼운 컨테이너를 VM만큼 안전하게 격리하면서 성능은 잃지 않는 것이 목표입니다.
- 컨테이너마다 자기 OS를 돌리므로 커널 버전이나 구현을 컨테이너별로 다르게 고를 수 있습니다.
- OS 기능을 고치거나 더하는 일이 커널 프로그래밍이 아니라 앱 개발처럼 쉬워집니다.
핵심 내용
- 커널은 vCPU(가상 CPU), 가상 주소 공간, 가상 네트워크처럼 하이퍼바이저와 비슷한 최소 기능만 제공합니다.
- 프로세스, VFS(가상 파일 시스템), TCP/IP 같은 OS 개념은 컨테이너별 라이브러리가 구현합니다.
- 격리에는 인텔 VT-x 같은 가상화 대신 CPU의 사용자 모드를 쓰므로 베어메탈 인스턴스가 필요 없습니다.
- 리눅스 바이너리와 호환되며, ftl-os.org도 FTL 위에서 도는 Rust HTTP 서버가 서비스합니다.
- 10월 v0.1.0에서 비동기 Rust 앱을 지원했고, 파일 시스템과 Node.js·Go, Arm 지원이 2027년 1월까지 예정돼 있습니다.
작성자 설명
글쓴이는 본문에 GitHub 저장소 주소만 남겼습니다.
HN 반응
- 드라이버까지 통째로 가상화하는 하이퍼바이저보다 OS 핵심만 라이브러리로 돌리는 편이 합리적이라는 평가가 나왔습니다.
- 반면 일반 리눅스와만 비교하지 말고 경량 VM인 Firecracker와 비교해 달라는 요청과, 최종 목표를 묻는 질문이 이어졌습니다.
FTL v0.1.0이 방금 릴리스됐습니다. 비동기 Rust 지원(멀티스레드 Tokio 런타임)이 추가됐고, 리눅스 호환 레이어에서 빠져 있던 부분이 많이 채워졌습니다.
(제 프로젝트는 아닙니다)
클라우드용 'OS'라는 게 무슨 뜻이죠?
장치 모델은 여전히 KVM이나 반가상화(paravirtualization) 같은 것에 맡기고, FTL 게스트 OS는 VM 안에서 보안이 확보된 여러 워크로드를 돌릴 수 있다는 뜻인가요?
아니면 네이티브 하드웨어에서 돌아가는 커스텀 OS를 밑바닥부터 설계하는 건가요? 리눅스가 가진 걸 전부 다시 구현하지 않고도 현실적으로 가능하게 하려고 하드웨어 지원에 어떤 제약을 두고 있나요? '클라우드'용이라고 내세우는 것도 배포될 머신을 미리 알 수 있어서 그런 거겠죠? 아니면 커널 개발자들 사이에서는 하드웨어 지원이 OS 분야에서 (프로세스, 스케줄링, 메모리 관리 같은) 사용자가 마주하는 기능에 비하면 (상대적으로) 사소한 문제로 알려져 있나요?
그것도 아니면 마이크로커널 = 승리 = 리눅스가 가진 걸 전부, 그리고 그 이상을 구현할 수 있다는 쪽에 거는 건가요?
지금 존재하는 것만이 아니라 이 프로젝트의 최종 목표가 뭔지 궁금해요. (그렇지 않다면 지금으로선 답이 첫 문장 같아서요.)
OS는 딱 하나뿐이죠… BIOS요!
아, 비즈니스 인텔리전스(Business Intelligence) OS 말이군요!
그냥 취미로 하는 거라서 gnu처럼 크고 전문적인 건 못 되는 거죠?
80386에서만 돌아가요. 제가 가진 게 그것뿐이라서요.
빨리요, 저자가 상의 벗고 맥주 마시는 사진 지워지기 전에 찾아보자고요.
맥락 좀 설명해 주세요.
https://www.reddit.com/r/linux/comments/15ifjt/young_linus_shirtless_drinking_a_beer_swoonworthy/
단순한 취미 개발자가 아니라,* 이전에도 열정적으로 해 온 사람이에요[1[2] 예전 글[3[4].
[1] https://x.com/seiyanuta [2] https://seiya.me/ [3] https://news.ycombinator.com/item?id=42631873 [4] https://news.ycombinator.com/item?id=28986229
요즘 애들은 그 인용 모를 것 같은데요.
아닐걸요. 꽤 유명한 인용이라서, 리누스가 그 유즈넷 글을 올리던 당시를 직접 겪을 나이가 아니었던 사람들도 다 알아요.
저는 나이는 충분한데도 몰랐어요. 그때 Unix를 만지고 있었지만, 리눅스는 2004년에야 처음 들여다봤거든요.
20년쯤 전에 리누스 전기(자서전이었나?)에서 읽었어요. 사우나 얘기, POSIX 사양을 리버스 엔지니어링해야 했던 얘기, 그리고 minix가 악당이었는지 아니면 학계 순수주의자였는지 하는 얘기도요.
Edit: 이제 기억나는데, 그때 난리도 아니었죠.
그런데 당신 댓글 덕분에 당신이 그 말을 알아들었다는 걸 우리 모두 알게 됐잖아요, 그게 요점이고요!
그리고 그 댓글 덕분에 모르던 사람들도 아마 눈치채게 될 텐데, 그게 더 미묘한 요점이고요!
저는 그냥 에이전트한테 제 앱과 제 하드웨어용 어셈블리를 만들게 하고, 거기로 바로 부팅해요.
농담으로 쓰신 거죠? 컴퓨팅의 미래가 정말 그쪽으로 가고 있을 가능성이 높긴 하지만요. 이 영상을 보세요 https://www.youtube.com/watch?v=kZRE7HIO3vk . 케이시한테 시비 건 사람이 많았죠. 다들 '자기 커널을 직접 짜던' 시절에는 소프트웨어가 더 효율적이었고 오늘날에는 그게 '불가능할 것'이라는 취지로 말했거든요. 게임마다 자체 부팅 USB가 딸려 오면 얼마나 멋질지도 얘기하고요. 그땐 정말 상상조차 못 할 일이었지만, 오늘날에는 그 현실에 점점 가까워지고 있어요.
예를 들어 저는 임베디드 장치용으로 Lisp 계열 언어로 짠, 실제로 동작하는 마이크로커널이 있어요. 네이티브 기계어 코드로 컴파일되고요. 100% LLM이 생성했고 약 7만 줄입니다. 벤치마크에서는 다른 임베디드 커널 프로젝트 대부분을 상당한 차이로 앞서요. 그런데 드는 비용은 토큰값으로 약 1,500달러(API 비용 전부 포함)뿐이었어요.
저도 같은 그림을 그리고 있습니다. 우리 직종에 어떤 결과를 가져오든 상관없이, 저는 미래가 예전에 4GL, CASE 도구, RUP 같은 것들이 시도했던 방향으로 가리라고 봅니다.
다만 한 가지는 잘못 짚으셨습니다.
그 시절에는 그게 정석이었습니다. 플로피 디스크나 테이프에 담긴, 컴퓨터 전체를 장악하는 완전한 부팅형 게임이 있었고, 그 방식은 한동안 콘솔 프로그래밍 모델이기도 했습니다.
이 접근법의 문제는, 처음에 계획했던 것 외의 장치(또는 서비스)를 지원해야 할 때 그 부담이 애플리케이션 개발자(또는 개발 시스템)에게 크게 얹힌다는 점입니다.
물론 필요할 때만 새 드라이버를 추가할 수도 있겠지만, 그러면 보안 문제가 생길 여지도 있습니다.
그러니 이론상으로는 될 수도 있겠지만, 실제로는 꽤 많은 고민이 필요할 겁니다.
includeos 같은 커널에는 여러분에게 제어권을 넘기기 전에 가능한 한 적게 하겠다고 내세운 접근이 있었고, 지금도 있습니다. 그러면 모두가 자기 드라이버 등을 만들 필요는 없고, 애플리케이션용 부팅 가능한 실행 파일을 얻게 됩니다.
특히 IncludeOS는 이후 완전한 '애플리케이션 서버'를 지향하는 쪽으로 갔다가, Docker가 성공하면서 사업으로 자리 잡지 못한 듯합니다.
https://includeos.org/
u images 같은 건 지금도 그렇게 하는데, 기존 소프트웨어를 묶어 넣을 수 있어서 전부 다시 짤 필요가 없어요. 멋진 점은 accept 같은 syscall/하이퍼바이저 호출 지점에서 멈춰 둘 수 있다는 거예요. 그러면 콜드 상태에서도 응답이 아주 빨라요.
8비트, 16비트 홈 컴퓨터 시절에 오신 것을 환영합니다. WinTel과 윈도 95가 거의 모든 걸 휩쓸기 전의 이야기죠.
컴퓨팅 하드웨어의 캄브리아기 대폭발이 끝난 지금도 드라이버가 그렇게 큰 문제일까요? 몇 가지 핵심 인터페이스로 통합될 가능성은 없나요?
하드웨어는 하나도 모르지만, 제가 아는 한 키보드와 마우스가 어디서나 동작하는 건 휴먼 인터페이스 장치가 어떻게 동작해야 하는지에 대한 공식 규격이 있기 때문이잖아요.
하드웨어에 여전히 전용 드라이버가 필요한 데는 (반경쟁적인 이유를 포함해) 그럴듯한 이유가 있겠지만, 밖에서 보기엔 해결할 수 있는 문제 같아요. 저는 장인이 한 땀 한 땀 만든 와이파이 드라이버 따위를 로드하고 싶은 마음이 전혀 없거든요.
게임 콘솔이 PS3 시대쯤까지는 꽤 이런 식으로 동작했습니다. 게임이 담긴 디스크나 카트리지가 하드웨어 지원을 포함해 모든 것의 바이너리를 싣고 있었죠.
그래서 과도기 콘솔이었던 Wii에서는 웃기는 구현상의 꼼수가 나왔습니다. Home 버튼을 누르면 뜨는 일시정지 화면은 사실 하부 콘솔 OS로의 태스크 전환이 아니라, 게임마다 따로 딸려 오는 SDK의 일부입니다.
참고. https://www.copetti.org/writings/consoles/wii/
AI가 하드웨어에 더 가까운 코드를 쓰는 비용을 낮추면, 겨냥할 새 하드웨어를 만드는 비용도 같이 낮아집니다. 맞춤형 솔루션을 설계하는 게 더 싸고 쉬워지니, 새로운 하드웨어가 폭발적으로 늘어나지 않을까 싶습니다.
VM용으로 쓰는 거고 GPU 같은 게 필요 없다면 가능해요.
실제 하드웨어에서는 어림도 없고요.
GPU, 와이파이, 전원/열 관리, 펌웨어요. 특히 휴대용 컴퓨팅에서는 여전히 상대해야 할 하드웨어 지원 범위가 어마어마해요.
라이브러리를 토대로 쓰면 되죠.
AI가 정리를 증명할 때는 사람과 똑같이 분할 정복 방식을 씁니다. 큰 정리를 보조정리(lemma)로 쪼개서 하나씩 해결합니다.
덩치만 큰 논리식 하나로 한 번에 끝내는 대안은 더 낫지 않습니다.
코드도 마찬가지라고 생각합니다. 호출 규약이나 보조 서브루틴 같은 중간 결과물이 필요합니다.
충분히 강력한 AI라면 컴파일을 '머릿속으로' 할 수 있습니다. 즉 특정 호출 규약에 맞는 기계어 코드를 만들어 낼 수 있습니다. 기계어를 디컴파일할 수도 있고요. 하지만 고수준 코드와 기계어가 일대일로 대응한다면, 이런 식으로 해서 얻는 건 분명히 아무것도 없습니다. 그냥 고수준 코드를 쓰면 되니까요.
소프트웨어가 더 효율적이 되길 진심으로 바랍니다. 다만 그게 기계어를 직접 생성해야만 가능하다고는 생각하지 않습니다.