# 현대 하드웨어 시대에 마이크로커널을 다시 검토해야 할지도 모름

> Clean Markdown view of GeekNews topic #31836. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=31836](https://news.hada.io/topic?id=31836)
- GeekNews Markdown: [https://news.hada.io/topic/31836.md](https://news.hada.io/topic/31836.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-07-27T04:01:41+09:00
- Updated: 2026-07-27T04:01:41+09:00
- Original source: [notes.hella.cheap](https://notes.hella.cheap/maybe-we-should-revisit-microkernels.html)
- Points: 1
- Comments: 1

## Topic Body

- 과거 높은 오버헤드로 실용성이 떨어졌던 **마이크로커널**은 오늘날 보편화된 IOMMU와 공유 메모리 덕분에 다시 현실적인 선택지가 될 수 있음
- 드라이버와 서브시스템을 사용자 공간에 격리하면 결함이나 공격의 영향 범위를 제한해 **보안·신뢰성·모듈성**을 높일 수 있음
- 1980~90년대에는 사용자 공간 프로세스가 장치에 직접 접근할 수 없어 디스크 읽기 같은 작업마다 **시스템 호출과 문맥 전환**, 잠금, 메모리 복사가 뒤따랐음
- **IOMMU와 공유 명령 큐**를 활용하면 정상 경로에서 문맥 전환과 주소 공간 간 복사, 잠금 없이 비동기 IPC와 장치 접근을 처리할 수 있음
- Xen, FreeBSD, Linux DRM 같은 기존 구성 요소를 활용할 수 있어 **하이퍼바이저와 시스템 서버**를 처음부터 새로 만드는 부담도 크지 않음

---

### 마이크로커널의 구조와 격리 효과
- [마이크로커널](https://en.wikipedia.org/wiki/Microkernel)은 스케줄링, I/O 장치 접근 관리, 프로세스 간 통신(IPC)을 제외한 기능을 **사용자 공간**에서 실행하는 커널 구조임
- 서브시스템 격리는 세 가지 이점을 제공함
  - **보안**: 드라이버 하나의 취약점이 공격자에게 전체 시스템이 아닌 해당 서브시스템이나 드라이버의 접근 권한만 줄 수 있음
  - **신뢰성**: 한 서브시스템의 충돌이 시스템 전체가 아니라 해당 부분에만 영향을 미침
  - **모듈성**: Linux 커널 팀이 모든 하드웨어 드라이버를 병합하고 각 칩의 내부 동작까지 검토해야 하는 부담을 덜 수 있음
- Windows가 마이크로커널 시스템이었다면 [CrowdStrike 버그](https://en.wikipedia.org/wiki/2024_CrowdStrike-related_IT_outages)는 일부 IT 보안 담당자의 원격 측정 데이터 수집만 중단시키는 데 그쳤을 수 있음

### 과거의 성능 한계와 IOMMU의 해법
- 과거 마이크로커널에서는 사용자 공간 프로세스가 특정 장치에 직접 접근할 수 없어 작업마다 **시스템 호출과 문맥 전환**이 필요했고, 비싼 잠금과 메모리 복사까지 뒤따랐음
  - [Mach](https://en.wikipedia.org/wiki/Mach_%28kernel%29#Performance_issues)는 성능 문제 때문에 사용자 공간 프로세스를 점차 커널 안으로 옮겼고, 결국 일반적인 모놀리식 커널에 가까워짐
- 오늘날 PC에는 약 10년간 [IOMMU](https://en.wikipedia.org/wiki/Input%E2%80%93output_memory_management_unit)가 표준적으로 탑재됐으며, 공유 메모리와 함께 사용하면 코어가 충분한 정상 경로에서 **문맥 전환을 완전히 제거**할 수 있음
  - 약간의 지연 시간을 받아들이면 전체적으로도 문맥 전환을 거의 없앨 수 있음
  - 가상화 기술 기반 스케줄러는 [Xen](https://xenproject.org/) 하이퍼바이저와 유사한 형태로 구성할 수 있음
  - I/O 장치 접근은 **IOMMU 하드웨어**가 관리함
- IPC는 프로세스 사이에 공유 버퍼를 할당하고 정수 원자적 compare-and-swap을 제공하는 방식으로 구현할 수 있음
  - 공유 버퍼를 링 버퍼 형태의 **명령 큐**로 사용하고 시작·끝 포인터를 원자적으로 갱신함
  - 정상 경로에서는 문맥 전환, 주소 공간 간 복사, 잠금 없이 비동기 메시지를 전달할 수 있으며, GPU 드라이버에서도 널리 쓰이는 방식임

### 라이브러리 구성과 기존 코드 활용
- 프로세스가 VM 게스트인 환경에서는 공유 라이브러리를 프로그램 시작 시 링크하고, 다른 프로세스에서 실행할 필요가 없는 기능은 [exokernel](https://pdos.csail.mit.edu/6.828/2008/readings/engler95exokernel.pdf) 방식으로 로컬에서 처리할 수 있음
  - Electron 형태로 애플리케이션마다 자체 운영체제 구성 요소를 함께 배포하는 오늘날에는 메모리의 **중복 라이브러리**가 30년 전만큼 큰 문제가 아님
- 구현에 필요한 주요 기반도 이미 존재함
  - **Xen**은 하이퍼바이저 계층에 필요한 기능 대부분을 갖추고 있음
  - Mach처럼 네트워크와 파일시스템 서버를 구성하되 FreeBSD 코드를 가져와 사용할 수 있음
  - [DRM](https://dri.freedesktop.org/docs/drm/gpu.html)은 이미 비동기 명령 버퍼를 기반으로 하므로 Linux 그래픽 서브시스템을 사용자 공간에서 실행할 수 있음
  - 편의상 디스플레이 서버와 그래픽 서브시스템을 같은 프로세스에서 실행하는 구성도 가능함

## Comments



### Comment 62423

- Author: neo
- Created: 2026-07-27T04:01:42+09:00
- Points: 1

###### [Lobste.rs 의견들](https://lobste.rs/s/krsvrp/maybe_we_should_revisit_microkernels) 
- Linux가 모든 드라이버를 포함하는 이유는 **트리 외부 커널 모듈용 안정적 API**가 없기 때문이며, 이런 API를 제공하는 데 마이크로커널이 필수인 것은 아님
  - 마이크로커널도 **내부 API의 불안정성**을 막아주지는 않으며, 단지 프로세스 간 경계를 넘게 될 뿐임  
    모든 Linux 드라이버를 사용자 공간으로 옮긴다는 가정에서도 내부 API 변경이 어려워진다는 LKML의 불만을 본 기억이 있음

- [L4](https://en.wikipedia.org/wiki/L4_microkernel_family) 계열 커널은 빠르다고 알려져 있지 않나 싶음. [Redox OS](https://doc.redox-os.org/book/microkernels.html)나 Fuchsia는 어떤지도 궁금함
  - **L4 커널**은 빠를 수 있지만, 실제로는 구성이 매우 고정적인 임베디드 시스템에서나 쓸 만함  
    [Genode](https://genode.org/)는 여러 커널을 지원하지만 seL4 등에서는 우스울 정도로 성능이 나쁨. 동료들이 Linux VM을 부팅해 봤을 때 32비트만 지원됐고, 절반쯤 부팅하는 데도 수분이 걸렸음  
    [NOVA microhypervisor](https://hypervisor.org/)의 [Genode 포크](https://genode.org/documentation/genode-foundations/26.05/under_the_hood/Execution_on_the_NOVA_microhypervisor_(base-nova).html#Genode-specific_modifications_of_the_NOVA_kernel)가 기본 플랫폼인 데는 실제로 동작하고 성능도 충분하다는 이유가 있음
  - [Redox 문서](https://doc.redox-os.org/book/communication.html)를 보면 요청 메시지를 조립할 때 여전히 **문맥 교환**을 수행하며, 아마 검증 단계로 보임  
    순환 버퍼를 사용하므로 수신자가 다른 코어에서 이미 실행 중이라면 두 번째 문맥 교환은 필요 없을 수도 있음. 문맥 교환 없이 메시지를 해석하면 수신자가 메시지를 검증해야 해서 공격 표면이 지나치게 커질 수 있지만, 커널 제공 동적 라이브러리로 완화할 여지는 있어 보임  
    전문가는 아니지만 원문이 몇 가지 중요한 고려 사항을 빠뜨린 느낌

- QNX는 빠른 마이크로커널로 알려졌는데, 무엇을 제대로 한 것인지 궁금함
  - 직접 써본 **QNX는 빠르지 않았음**  
    예전에 친구와 마이크로커널, 특히 QNX의 우아함에 매료돼 FireWire 기반 영상 처리 문제를 구현했음. 코드는 단순하고 멋졌지만 처참하게 느렸음. 당시 Linux용 1394 드라이버에 DMA 기반 등시성 전송 지원을 약 12시간 만에 추가하자 성능이 크게 개선됐고, 이 일을 계기로 회사의 광학 선별 장비에 Linux를 쓰는 데 대한 회의론도 사라졌음  
    QNX와 마이크로커널, 메시지 전달의 이상은 여전히 훌륭하지만 널리 자리 잡으려면 **프로세스 간 데이터 전달 비용**을 훨씬 낮춰야 함  
    지금은 Elixir로 웹 애플리케이션을 만들며 QNX가 내세운 것과 같은 프로세스 격리를 누리고 있음. 광학 처리처럼 성능이 중요한 작업이 아니어서 괜찮지만, Elixir/BEAM도 데이터 복사 문제는 동일함

- Mach가 원래 구상만큼 구성 요소를 완전히 독립시키지는 못했더라도 **평범한 모놀리식 커널**이 된 것은 아니며, 그 아키텍처가 여전히 주는 이점이 있다고 들었음  
  고전적인 POSIX 파일 목록 벤치마크처럼 모든 항목에 `readdir()`와 `stat()`을 호출하면 마이크로커널이 불리할 수밖에 없음. 하지만 `io_uring` 같은 **일괄 처리 API**를 사용해 시스템 호출 빈도를 낮추면 높은 지연 시간이 큰 약점이 아닐 수도 있음
  - Liedtke의 [“on μ-Kernel Construction”, 1995](https://dl.acm.org/doi/pdf/10.1145/224056.224075)는 Mach가 느린 원인을 **큰 캐시 사용량**, 즉 충분히 작지 않았던 설계에서 찾았음  
    Linux도 네트워크 패킷마다 시스템 호출을 한 번씩 하면 회선 속도를 따라갈 수 없음. 일괄 처리는 Linux와 마이크로커널 모두에서 중요함

- 이 분야의 흥미로운 최신 진입자로 [HongMeng](https://www.usenix.org/conference/osdi24/presentation/chen-haibo)이 있지만, 아쉽게도 **독점 소프트웨어**임

- **데이터 이동 비용**이 한 자릿수 이상 크게 줄지 않는 한 마이크로커널이 충분한 경쟁력을 갖추기는 어려워 보임  
  이론적으로는 우아하고 깔끔하지만 현실은 복잡하므로, 그 복잡성을 다루려면 커널도 어느 정도 복잡해야 할지 모름

- 올바른 아키텍처를 좋아하지만 Linux가 지배적인 위치에 오른 데는 순수한 기술 외의 **부차적 요인**도 컸다고 봄. 이를 여러 차원에서 분석한 글을 읽고 싶음