마이크로커널·모놀리식·하이브리드 커널 아키텍처 비교

하드웨어 접근 권한을 가진 커널과 사용자 공간

커널은 하드웨어와 응용 프로그램 사이에서 시스템 자원을 관리하는 운영체제의 중심 구성요소다. 프로세스와 메모리, 파일 시스템, 장치 드라이버, 네트워크 스택을 다루며 사용자 공간에는 시스템 호출 인터페이스를 제공한다.

커널이 맡는 역할은 다음과 같다.

프로세스 관리: 생성, 스케줄링, 종료
메모리 관리: 할당, 해제, 가상 메모리
장치 관리: 드라이버 인터페이스
파일 시스템: 저장소 추상화
시스템 호출: 사용자 공간 인터페이스
보안: 접근 제어, 권한 관리

커널 모드에서는 모든 하드웨어 자원과 명령어에 접근할 수 있으며, 커널 코드가 이 모드에서 실행된다. 반대로 사용자 모드의 응용 프로그램은 제한된 명령어 집합과 메모리 영역 안에서 실행된다.

⤢✕

모든 핵심 서비스를 커널 공간에 두는 모놀리식 구조

모놀리식 커널은 프로세스 관리, 메모리 관리, 파일 시스템, 장치 드라이버, 네트워크 스택 같은 핵심 서비스를 단일 주소 공간에서 커널 모드로 실행한다. 서비스들은 하나의 큰 바이너리에 통합되고, 공유 데이터 구조와 직접 함수 호출로 연결된다.

Linux, FreeBSD·NetBSD·OpenBSD, 전통적 Unix 시스템, MS-DOS가 대표적인 모놀리식 커널에 속한다.

⤢✕

직접 함수 호출은 모듈 간 통신 오버헤드를 줄이고, 공유 메모리는 데이터 복사를 피하게 한다. 커널 안에서의 컨텍스트 전환도 필요하지 않아 전체 코드 수준의 최적화가 가능하다. 단일 주소 공간에서 프로그래밍하므로 모듈 간 인터페이스를 단순하게 정의할 수 있고, 단일 컨텍스트라는 점은 디버깅에도 유리하다.

대신 커널 내부의 결함은 격리되지 않는다. 하나의 버그나 드라이버 오류가 커널 패닉으로 이어져 시스템 전체에 영향을 줄 수 있으며, 커널 내부에는 메모리 보호 경계가 없다. 코드베이스가 커질수록 모듈 의존성과 변경 영향 범위를 파악하기 어려워지고, 동적 기능 추가나 환경별 최적화에도 제약이 생긴다.

Linux가 모듈로 확보하는 유연성

Linux는 모놀리식 구조지만 로드 가능한 커널 모듈(LKM)을 사용한다. 모듈은 런타임에 동적으로 로드하거나 언로드할 수 있고, 커널 공간에서 실행되며 커널 심볼 테이블에 접근한다. 장치 드라이버와 파일 시스템 같은 기능이 주요 활용 대상이다.

# 모듈 로드
insmod mymodule.ko
modprobe mymodule

# 모듈 언로드
rmmod mymodule

# 로드된 모듈 확인
lsmod

서비스를 사용자 공간 서버로 분리하는 마이크로커널

마이크로커널은 커널 모드에서 실행하는 기능을 최소화하고 나머지 서비스를 사용자 공간의 별도 프로세스로 분리한다. 이 구조는 메커니즘과 정책을 분리하는 원칙을 따른다.

커널에는 IPC, 기본 스케줄링, 주소 공간 관리, 인터럽트 처리가 남는다. 파일 시스템, 네트워크, 장치 드라이버, 디스플레이 같은 기능은 사용자 공간 서버로 구성한다. Mach, L4 계열의 seL4와 Fiasco.OC, MINIX 3, QNX Neutrino, GNU Hurd가 이 접근을 대표한다.

⤢✕

서비스가 독립 주소 공간에서 동작하므로 서버 장애와 드라이버 오류를 시스템 전체에서 격리할 수 있다. 결함이 난 서버를 재시작할 수 있고, 최소 권한 원칙과 서버 간 권한 분리도 적용하기 쉽다. 서비스 단위 업데이트와 동적 기능 추가·제거, 분산 시스템 구현, 플랫폼 이식성 측면에서도 유연하다.

커널 코드베이스가 작아 형식 검증에 적합하다는 점도 특징이다. seL4는 최초의 형식 검증된 OS 커널로 제시된다.

이 구조의 비용은 서비스 간 메시지 전달에 있다. 요청마다 IPC가 발생하고 서버 사이의 컨텍스트 스위치와 주소 공간 간 데이터 이동이 늘어난다. IPC 프로토콜, 서버 의존성, 동기화, 데드락과 라이브락까지 설계해야 하므로 구조 자체의 복잡성도 높다.

작업	모놀리식	마이크로커널
시스템 호출	직접 호출	IPC + 서버 호출
파일 읽기	1회 전환	다중 IPC
네트워크 패킷	커널 내 처리	여러 서버 경유

IPC 방식이 만드는 차이

동기식 IPC에서는 송신자가 수신자의 응답을 받을 때까지 기다린다. 이는 랑데부 방식이며 L4 계열에서 주로 사용된다. 비동기식 IPC는 메시지 큐에 메시지를 버퍼링하고 송신 뒤 즉시 반환하며, Mach에서 주로 사용된다.

⤢✕

성능과 분리를 함께 다루는 하이브리드 커널

하이브리드 커널은 모놀리식 커널의 성능과 마이크로커널의 모듈성을 함께 취하는 절충 구조다. 성능이 중요한 서비스는 커널 공간에 두고, 안정성이나 유연성이 더 중요한 일부 서비스는 사용자 공간으로 분리한다.

Windows NT/10/11, macOS/iOS의 XNU, BeOS/Haiku, DragonFly BSD가 대표 사례다.

⤢✕

Windows NT는 HAL로 하드웨어 독립성을 제공하고 Executive에 커널 서비스를 모은다. 마이크로커널 기반의 설계 철학을 따르지만 실제로는 대부분이 커널 모드에서 실행된다.

계층	구성요소	역할
Executive	객체 관리자	커널 객체 관리
Executive	프로세스 관리자	프로세스/스레드
Executive	메모리 관리자	가상 메모리
Executive	I/O 관리자	장치 드라이버
Executive	보안 참조 모니터	접근 제어
커널	ntoskrnl.exe	스케줄링, 인터럽트
HAL	hal.dll	하드웨어 추상화

XNU는 Mach 마이크로커널, POSIX API와 파일 시스템을 담당하는 BSD 계층, 객체지향 드라이버 프레임워크인 I/O Kit을 결합한다. Mach는 포트 기반 IPC를 제공하고 BSD는 모놀리식 방식의 시스템 호출을 수행하며, 두 계층은 혼합되어 실행된다.

⤢✕

하이브리드 구조는 성능과 안정성 사이에서 균형을 맞추고, 점진적 마이그레이션과 기존 코드 재사용을 가능하게 한다. 그 대가로 설계 복잡성이 늘고 구조 간 경계가 명확하지 않을 수 있으며, 두 접근의 단점을 일부 함께 가진다.

요구사항으로 보는 커널 구조 선택

특성	모놀리식	마이크로커널	하이브리드
성능	높음	낮음	중간
안정성	낮음	높음	중간
보안	낮음	높음	중간
복잡성	중간	높음	높음
유연성	낮음	높음	중간
코드 크기	큼	작음	큼
검증 가능성	어려움	가능	어려움

최고 성능이 필요하거나 범용 목적 운영체제를 빠르게 개발해야 한다면 모놀리식 구조가 맞는다. 높은 신뢰성과 보안, 인증이 필요한 항공·의료 시스템, 분산 시스템, 실시간 시스템에서는 마이크로커널이 선택 대상이 된다. 성능과 안정성의 균형, 상용 운영체제 요구, 레거시 호환성이 핵심이면 하이브리드 구조가 현실적인 선택지다.

⤢✕

유니커널과 형식 검증의 방향

유니커널은 응용 프로그램과 필요한 OS 기능만을 단일 주소 공간으로 컴파일하는 경량화 접근법이다. 단일 목적 VM, 최소 공격 표면, 빠른 부팅, 클라우드 최적화가 특징이다.

seL4는 수학적으로 정확성이 증명된 최초의 범용 OS 커널이다. 구현이 명세와 일치하는지 검증하며, 무결성(Integrity), 기밀성(Confidentiality), 가용성(Availability) 보장을 다룬다.

커널 구조는 성능만으로 정할 문제가 아니다. 서비스 장애를 어디까지 격리할지, IPC 비용을 감수할지, 형식 검증이 필요한지, 기존 생태계와의 호환성을 어떻게 가져갈지를 함께 결정하는 운영체제의 설계 선택이다.