마이크로커널(Microkernel), 현대 하드웨어로 부활할까?

글에서는 IOMMU와 공유 메모리를 활용하여 컨텍스트 스위칭(Context Switching) 없는 IPC를 구현할 수 있다고 주장하지만, 커뮤니티에서는 데이터 복사(Data Copying) 및 메시지 검증(Message Validation) 과정에서 발생하는 오버헤드를 지적합니다. 특히 고속 네트워크 환경에서는 패킷당 처리 시간이 극히 제한적이므로, 커널 모드 전환 비용만으로도 성능 저하가 발생할 수 있다는 의견이 지배적입니다. 동기식 처리(Synchronous Processing)의 비효율성을 지적하며, 배칭(Batching) 및 비동기 공유 메모리 큐(Asynchronous Shared-Memory Queue) 디자인의 중요성을 강조합니다.

QNX, Redox OS, seL4 등 다양한 마이크로커널(Microkernel) 기반 시스템의 성능에 대한 논의가 활발합니다. 일부는 정적 임베디드 시스템(Static Embedded Systems)에서는 L4 계열 커널이 빠르다고 언급하지만, Genode나 Kry10 OS와 같이 고가용성(High Assurance)을 목표로 하는 시스템에서는 동적 시스템(Dynamic Systems) 구축 및 성능 확보에 어려움이 있다는 지적이 있습니다. 특히 Windows VM 구동 시 수 분이 소요되는 사례가 언급되며, 실질적인 성능 확보가 관건임을 시사합니다.

Linux 커널 팀이 모든 하드웨어 드라이버를 직접 관리하는 이유로 안정적인 외부 커널 모듈 API 부재가 지적되었습니다. 마이크로커널(Microkernel) 환경에서도 프로세스 간 API(Inter-Process API)의 불안정성은 여전히 문제될 수 있으며, 사용자 공간 드라이버의 내부 API 변경에 대한 불만이 제기된 바 있습니다. 이는 마이크로커널(Microkernel)이라 할지라도 모듈 간의 안정적인 인터페이스 설계가 필수적임을 보여줍니다.

Mach 커널이 XNU 커널의 조상임에도 불구하고, 성능상의 이유로 많은 사용자 공간 프로세스가 다시 커널 내부로 통합되어 결국 모놀리식 커널(Monolithic Kernel)에 가까워졌다는 사례가 언급됩니다. 이는 성능 최적화(Performance Optimization) 과정에서 마이크로커널(Microkernel)의 이상적인 구조가 희생될 수 있음을 시사합니다. 다만, 일부에서는 여전히 Mach 아키텍처가 독립적인 컴포넌트 이점을 일부 제공한다는 반론도 존재합니다.

고전적인 POSIX 파일 시스템 벤치마크(예: `readdir`, `stat`)에서 마이크로커널(Microkernel)이 불리할 수 있다는 점이 지적됩니다. 이는 각 항목마다 시스템 콜(System Call)을 호출해야 하는 특성 때문입니다. 그러나 `io_uring`과 같은 배치 지향 API(Batch-Oriented APIs)는 이러한 지연 시간을 완화할 수 있으며, 마이크로커널(Microkernel)에서도 네트워크 패킷 처리와 같이 높은 처리량이 요구되는 작업에서는 커널 바이패스(Kernel Bypass) 기술을 통해 성능을 확보할 수 있다는 논의가 이어집니다.

근본적으로 데이터 이동 비용(Cost of Moving Data)이 획기적으로 줄어들지 않는 한, 마이크로커널(Microkernel)이 현대적인 시스템에서 경쟁력을 갖기 어렵다는 비관적인 전망이 있습니다. 이론적으로는 우아하고 깔끔한(Elegant and Cleaner) 구조를 가지지만, 현실 세계의 복잡성을 다루기 위해서는 오히려 '지저분한(Messy)' 커널이 필요할 수 있다는 의견입니다. 이는 마이크로커널(Microkernel)의 이론적 장점과 실질적 구현의 어려움 사이의 간극을 보여줍니다.