Monolithic vs Microkernel Structures

1. Overview

모놀리식과 마이크로커널 구조(Monolithic vs Microkernel Structures)는 커널(Kernel)에 운영체제의 주요 기능(네트워크, 파일시스템, 디바이스 드라이버)을 함께 둘 것인지, 아니면 커널에는 최소한의 통신(IPC)과 스케줄링만 남기고 나머지를 사용자 공간(User Space)으로 분리할 것인지 결정하는 운영체제 아키텍처의 핵심 구조 선택입니다.

학습자는 함수 호출(Function Call)로 커널 내부 기능이 빠르게 협력하지만 드라이버 결함이 전체 시스템으로 번질 수 있는 리눅스(Linux) 모놀리식 커널의 딜레마를 살핍니다. 이어 디바이스 드라이버가 실패해도 해당 프로세스만 재시작할 수 있는 안정성을 제공하지만, 기능 호출마다 사용자 공간과 커널 공간을 오가며 메시지 패싱(Message Passing) 비용을 지불하는 **마이크로커널(QNX, seL4)**의 트레이드오프를 이해합니다.

2. Scope & Boundaries

In-Scope

• 모놀리식 커널 역학 (Monolithic Mechanics): 리눅스 커널 모듈(LKM), 함수 호출 기반의 극단적 성능(Throughput), 단일 주소 공간 붕괴 리스크.
• 마이크로커널 역학 (Microkernel Mechanics): QNX, seL4, L4 계열, 서버-클라이언트 아키텍처, 메시지 패싱(IPC) 병목과 컨텍스트 스위칭 오버헤드.
• 하이브리드 아키텍처 (Hybrid Structures): Windows NT, macOS(XNU), 마이크로커널의 탈을 쓴 모놀리식의 타협점.
• 엑소커널과 커널 바이패스 (Exokernel/Bypass): DPDK, SPDK 등 하드웨어 통제권을 사용자 애플리케이션에 직접 넘겨주는 제로 오버헤드 설계.

Out-of-Scope

• 멀티코어 스레딩 및 스케줄러 알고리즘: 커널 내부에서 프로세스를 어떻게 스케줄링(CFS)하는지에 대한 구체적 로직 $\rightarrow$ 03-02-03. CPU Scheduling Algorithms 영역.
• 사용자 공간 애플리케이션 아키텍처: MSA(마이크로서비스) 등 웹 백엔드의 분산 처리 구조 $\rightarrow$ 04-03-04. Microservices Architecture 영역.

Boundaries

• Kernel Arch vs. Distributed System (04-03-04): 마이크로서비스(MSA)가 웹 서버들을 네트워크(TCP/IP) 너머로 분리해 가용성을 높이는 구조라면, 마이크로커널은 하나의 시스템 안에서 권한 공간(Ring 0 vs Ring 3)을 분리해 드라이버 장애가 커널 전체 장애로 번지지 않도록 격리하는 구조입니다.

3. Counterexample

• 모놀리식 커널의 드라이버 장애 전파 (Third-Party Driver Crash): 리눅스 커널(모놀리식)에 검증되지 않은 그래픽카드 드라이버나 보안 모듈(.ko)을 적재하면, 해당 코드도 Ring 0 권한과 커널 메모리를 공유합니다. 드라이버가 배열 인덱스를 잘못 다루어 커널 메모리를 침범하면, 데이터베이스나 웹 서버가 함께 실행 중인 시스템 전체가 커널 패닉(Kernel Panic)으로 멈출 수 있습니다.
• 마이크로커널의 IPC 병목 (Message Passing Bottleneck): 보안을 이유로 모든 범용 데스크톱 기능을 마이크로커널 방식으로 분리하면 단순한 파일 열기 작업에도 [마우스 드라이버 $\rightarrow$ 커널 $\rightarrow$ GUI 서버 $\rightarrow$ 커널 $\rightarrow$ 파일 시스템 서버 $\rightarrow$ 커널 $\rightarrow$ 디스크 드라이버]처럼 여러 번의 메시지 전달(IPC)과 링(Ring) 전환이 발생합니다. 이 비용이 누적되면 실제 작업보다 통신과 전환에 더 많은 CPU 시간이 쓰일 수 있습니다.

4. Prerequisites

• 권한 분리 (Basic): 커널 모드(Ring 0)와 유저 모드(Ring 3)가 물리적으로 램(RAM) 접근 권한이 다름을 이해해야 합니다. (03-01-02 System Call Interface)
• 메모리 보호 (Recommended): 프로세스들이 서로의 메모리를 볼 수 없는 가상 메모리의 장벽을 알아야 마이크로커널의 통신 딜레마를 깰 수 있습니다. (03-03-01 Virtual Memory)

5. Learning Map

6. Learning Topics

Basic

Core Topic 01: 단일 주소 공간과 빠른 협력, 모놀리식 커널 (Monolithic Kernel)

• Why to Learn: 리눅스(Linux)가 왜 높은 성능을 내는 동시에 드라이버 결함이 시스템 전체로 번질 수 있는지, 그 구조적 원인을 이해하기 위해서입니다.
• What to Learn:
  • Concepts: 모놀리식 아키텍처(Monolithic Architecture), 커널 모듈(LKM), 단일 주소 공간(Single Address Space).
  • Skills: 함수 호출(Function Call) 기반 통신, 포인터(Pointer) 직접 참조.
  • Tools: 리눅스 커널 소스 트리 분석, lsmod.
  • Trade-offs: 네트워크 스택과 파일 시스템이 같은 커널 주소 공간(Ring 0)에 있어 포인터 직접 참조로 빠르게 협력할 수 있지만, 메모리 보호 경계가 약해 한 드라이버의 결함이 다른 커널 기능에 영향을 줄 수 있습니다.
• How to Learn:
  • 1단계: 디스크에서 파일을 읽어(VFS) 네트워크 랜카드(TCP/IP)로 보낼 때, 커널 내부에서 "디스크 함수 $\rightarrow$ 메모리 버퍼 주소 전달 $\rightarrow$ 네트워크 함수" 형태의 함수 호출(Function Call)로 이어지는 흐름을 분석합니다.
  • 2단계: USB 드라이버를 커널에 동적 적재(insmod)하면 해당 코드가 커널 주소 공간에서 실행된다는 점을 확인하고, 이 권한이 성능과 안정성에 어떤 영향을 주는지 살핍니다.
• Implement: 파이썬의 단일 전역 변수(Global Dictionary)를 공유하는 FileSystem, Network, Driver 클래스를 만듭니다. Driver 함수 내에서 배열 인덱스 오류(Memory_Corruption_Bug)가 다른 모듈의 상태를 덮어쓰는 상황을 재현해, 격리 경계가 없을 때의 취약점을 관찰합니다.

Recommended

Core Topic 02: 격리와 복구를 중시하는 마이크로커널 아키텍처 (Microkernel Structure)

• Why to Learn: 자동차 제어기(QNX)나 탐사선 제어기처럼 일부 모듈 장애가 전체 시스템 중단으로 이어지면 안 되는 Mission-Critical 환경에서 격리와 복구 구조가 왜 중요한지 이해하기 위해서입니다.
• What to Learn:
  • Concepts: 마이크로커널(Microkernel), 서버-클라이언트 모델(Server-Client OS), 메모리 격리(Memory Isolation).
  • Skills: 컴포넌트 재시작(Component Restarting), 샌드박스(Sandbox).
  • Tools: QNX, seL4 검증 커널.
  • Trade-offs: 하드웨어 드라이버와 파일 시스템을 사용자 프로세스(Ring 3)로 분리하면, USB 드라이버가 실패해도 해당 프로세스만 종료(Kill)하고 재시작(Restart)할 수 있습니다. 대신 모든 모듈 간 통신에 IPC 비용이 붙습니다.
• How to Learn:
  • 1단계: 커널 안에는 프로세스 스케줄링과 기본 IPC만 남기고(Ring 0), 네트워크 기능은 Network Server 프로세스, 파일 기능은 File Server 프로세스로 분리해 사용자 공간(Ring 3)에서 실행하는 구조를 그립니다.
  • 2단계: File Server 코드가 무한 루프나 널 포인터 역참조(Null Pointer)로 실패해도 독립된 가상 메모리 구역 안에서만 장애가 발생하고, Network Server와 커널은 계속 동작할 수 있는 이유를 확인합니다.
• Implement: 독립된 서브프로세스 3개(Kernel, FileSystem_Proc, Network_Proc)를 띄웁니다. 클라이언트가 파일 읽기를 요청하는 중 FileSystem_Proc을 리눅스 kill -9로 종료해도, Kernel 프로세스가 이를 감지하고 FileSystem_Proc을 재시작해 전체 시스템 중단 없이 서비스를 복구하는 스크립트를 작성합니다.

Practical

Core Topic 03: IPC와 컨텍스트 스위치 오버헤드 (IPC & Context Switch Wall)

• Why to Learn: 마이크로커널이 범용 데스크톱/서버 OS에서 항상 선택되지 않는 이유를 메시지 패싱(IPC)과 컨텍스트 스위치 비용 관점에서 이해하기 위해서입니다.
• What to Learn:
  • Concepts: IPC(Inter-Process Communication), 컨텍스트 스위치(Context Switch), 메시지 카피(Message Copy), 모드 스위치(Mode Switch).
  • Skills: 제로 카피 IPC(Zero-copy IPC), 공유 메모리(Shared Memory) 트릭.
  • Tools: CPU 캐시 털림(Cache Eviction) 프로파일링.
  • Trade-offs: 모듈을 격리하면 보안과 안정성은 좋아지지만, 모듈 간 데이터를 넘길 때마다 [User $\rightarrow$ Kernel $\rightarrow$ User] 경로를 거쳐야 합니다. 이 과정에서 TLB/캐시 영향과 레지스터 저장·복원 비용이 누적되어 성능이 떨어질 수 있습니다.
• How to Learn:
  • 1단계: 사용자 앱이 파일을 요청할 때 마이크로커널에서는 [사용자 앱 $\rightarrow$ (시스템콜) $\rightarrow$ 커널 IPC $\rightarrow$ (컨텍스트 스위치) $\rightarrow$ 파일 시스템 서버 $\rightarrow$ (디스크 읽음) $\rightarrow$ 커널 IPC $\rightarrow$ (컨텍스트 스위치) $\rightarrow$ 사용자 앱] 경로를 거친다는 점을 추적합니다.
  • 2단계: 데이터 10KB를 보낼 때 커널 공간을 거치며 메모리가 여러 번 복사(Copy)되는 비용을 줄이기 위해, 두 프로세스가 같은 램 주소를 보도록 구성하는 공유 메모리(Shared Memory) IPC 방식을 살펴봅니다.
• Implement: 직접 참조(Direct Function Call) 모드와 IPC(Message Passing via Socket/Queue) 모드로 여러 번 통신하는 파이썬 벤치마크를 작성합니다. 직접 호출과 큐(Queue), 직렬화/역직렬화(Pickle)를 거치는 IPC 방식의 실행 시간을 비교합니다.

Advanced

Core Topic 04: 하이브리드와 엑소커널, 커널 바이패스 (Hybrid & Bypass)

• Why to Learn: Windows, macOS 같은 상업용 OS가 모놀리식/마이크로커널 이분법을 어떻게 절충하는지, 그리고 고성능 네트워크 환경에서 커널 바이패스(Exokernel/DPDK)가 왜 쓰이는지 이해하기 위해서입니다.
• What to Learn:
  • Concepts: 하이브리드 커널(Windows NT, XNU/macOS), 커널 바이패스(Kernel Bypass, DPDK, SPDK), 엑소커널(Exokernel).
  • Skills: 사용자 공간 디바이스 드라이버(User-space Driver), 하드웨어 직결 맵핑.
  • Tools: DPDK(Data Plane Development Kit).
  • Trade-offs: 커널 바이패스를 사용해 사용자 앱(게임 서버)이 랜카드(NIC) 하드웨어 메모리를 직접 다루면(Zero-copy) 매우 높은 패킷 처리량을 얻을 수 있습니다. 대신 TCP/IP 라우팅, 방화벽, 포트 공유 등 커널이 제공하던 기능을 애플리케이션에서 직접 처리해야 하는 복잡성이 생깁니다.
• How to Learn:
  • 1단계: Windows NT: 설계 철학은 마이크로커널처럼 모듈을 나누지만, 성능을 위해 많은 모듈을 커널 공간(Ring 0)에서 실행하는 하이브리드 타협을 살핍니다. macOS의 XNU도 같은 관점에서 비교합니다.
  • 2단계: DPDK(Kernel Bypass): 리눅스 커널 네트워크 스택을 거치지 않고 랜카드 컨트롤러 메모리를 사용자 앱(Ring 3) 주소 공간에 매핑(mmap)해 패킷을 직접 처리하는 구조를 확인합니다.
• Implement: 파이썬 mmap 라이브러리로 가상의 큰 파일(하드웨어 버퍼 역할)을 생성합니다. OS의 read() 시스템콜을 거쳐 1바이트씩 읽는 방식과, mmap으로 메모리를 사용자 공간 배열에 연결한 뒤 슬라이싱(Bypass)하는 방식의 처리량(Throughput)을 비교합니다.

7. Terminology

8. References

Primary

• [P1] CS2023 - OS/Operating System Principles (Structures) — Core definitions.
• [P2] SWEBOK v4.0 - Computing Foundations / Operating Systems — System design and integration.

Secondary

• [Modern Operating Systems] Andrew S. Tanenbaum — The Tanenbaum-Torvalds debate.
• [Operating System Concepts] Silberschatz et al. — Structure and implementation basics.

Industry

• [Linux Kernel Organization: Kernel Architecture] — Real-world monolithic example.
• [QNX: Microkernel Architecture for Safety-Critical Systems] — Real-world microkernel example.

9. Final Checklist

Primary

• '모놀리식 커널'이 '마이크로커널'보다 왜 일반적으로 시스템 콜 처리 속도가 빠른지 하드웨어 모드 전환 관점에서 설명 가능한가? (P1)
• '마이크로커널' 구조에서 특정 드라이버에 크래시가 발생했을 때 왜 시스템 전체가 'Reboot' 없이도 복구 가능한지 격리 근거를 제시할 수 있는가? (P1)

Secondary

• '하이브리드 커널'이 현대 OS에서 왜 주류가 되었는지, 성능과 신뢰성의 절충 지점을 예시를 들어 설명할 수 있는가?
• 커널 크기가 커질수록 CPU의 L1 Instruction Cache 미스 확률이 왜 높아지는지, MMS 설계가 캐시 효율에 미치는 영향을 도출할 수 있는가?

Industry

• 자율주행차의 제어 컴퓨터 설계 시, 왜 'QNX'와 같은 마이크로커널 기반 OS가 'Linux'보다 안전 인증 획득에 유리한지 구조 차이를 제안할 수 있는가? (SFIA)
• 안드로이드와 같이 리눅스 커널을 쓰면서도 하드웨어 추상화 계층(HAL)을 사용자 공간으로 빼는 설계가 '모놀리식'의 한계를 어떻게 보완하는지 기술할 수 있는가?