유니커널은 어려웠다. 중요한 건 ‘과거형’이라는 점이다

유니커널은 애플리케이션 자체가 운영체제인 구조로, 필요한 기능을 라이브러리로 구현해야 했던 부담이 컸지만 AI를 통한 이식과 개발로 그 장벽을 낮출 수 있음 셸과 인터프리터가 없는 구조는 침해 이후 공격자가 활용할 기능을 줄일 수 있지만, 메모리 안전성과 공격에 재사용할 코드 조각 문제까지 사라지는 것은 아님 기존 구현을 정답 기준으로 삼고 결과 비교와 테스트를 반복하면, 부족한 라이브러리나 시스템 도구를 에이전트로 이식할 수 있음 Spaceleans는 Microsoft Orleans를 OCaml로 이식해 유니커널에서 실행한 실험으로, 분산 액터와 파일시스템을 결합한 시스템을 일주일 만에 구축했으나 공개하지 않을 가능성이 있음 AI 개발에서는 타입 시스템과 빠른 컴파일이 오류를 제어하는 피드백 수단이 되며, Cursed 실험에서는 학습 데이터에 없는 언어도 문법을 컨텍스트에 제공하면 사용할 수 있었음 유니커널의 구조와 과거의 장벽 MirageOS와 Unikernel Systems에서 일했던 Justin Cormack과 Geoffrey Huntley가 유니커널의 재발견과 AI 개발을 논의함 대화 영상과 편집된 대화록을 확인할 수 있음 Huntley는 2015년경 Haskell 개발팀과 함수형 프로그래밍을 깊이 다루다가 OCaml을 거쳐 MirageOS 를 접함 유니커널은 애플리케이션 자체가 운영체제이며 별도의 사용자 공간이 없음 웹 서버, DNS, 이메일 전송이 필요해도 외부 프로그램을 fork하거나 spawn할 수 없으므로 애플리케이션 내부 라이브러리로 구현해야 함 초기 Mirage에는 TCP와 HTTPS 스택이 있었지만 스토리지 기능은 거의 없었고, 사용자 공간에서 실행할 수 있는 NetBSD 드라이버를 가져와야 했음 Huntley는 Nix, Bazel, 유니커널이 어렵다는 고정관념을 버려야 한다고 봄 과거에 어려웠던 개념이 이제 모델 가중치에 들어 있으므로, 프롬프트를 통해 활용할 수 있다고 판단함 운영체제의 설계 부채와 공격 표면 Huntley는 인간 운영자와 다중 사용자 환경을 전제로 만들어진 운영체제 계층을 설계 부채로 봄 IBM 5250, AIX, Solaris, 메인프레임을 다뤘던 경험을 바탕으로, 애플리케이션 아래에 항상 범용 운영체제가 필요한지 의문을 던짐 사용자 공간 애플리케이션이 침해돼 셸 접근 권한을 내주면, 공격자는 데이터 유출에 필요한 편리한 도구를 확보함 유니커널에서는 애플리케이션에 ...