CS학습2026년 9월 5일

User Mode / Kernel Mode: CPU 권한 분리와 시스템 콜의 경계

User Mode와 Kernel Mode는 CPU가 실행 중인 코드에 부여하는 권한 수준으로, 하드웨어 자원 접근을 통제해 시스템 안정성과 보안을 확보하는 메커니즘이다. 애플리케이션은 User Mode에서 실행되다가 파일 입출력이나 네트워크 요청처럼 커널의 도움이 필요한 순간 시스템 콜(system call)을 통해 Kernel Mode로 전환된다. 이 전

송민성7분 읽기

1. 개념

User Mode와 Kernel Mode는 CPU가 제공하는 두 가지(혹은 그 이상) 특권 수준(privilege level)이다. x86 아키텍처 기준으로는 링(ring) 0부터 3까지 존재하는데, 실제 대부분의 운영체제는 링 0(Kernel Mode)과 링 3(User Mode) 두 단계만 사용한다.

User Mode: 일반 애플리케이션 코드가 실행되는 모드. CPU 레지스터, 메모리 관리 유닛(MMU), I/O 포트 같은 하드웨어 자원에 직접 접근할 수 없다.
Kernel Mode: 운영체제 커널 코드가 실행되는 모드. 모든 CPU 명령어와 하드웨어 자원에 제한 없이 접근 가능하다.

이 구분은 소프트웨어적 약속이 아니라 CPU 하드웨어가 강제하는 규칙이다. CPU는 현재 실행 모드를 플래그 레지스터(예: x86의 CS 레지스터 하위 2비트)에 저장하고, 특정 명령어(예: HLT, IN, OUT, MMU 설정 명령)는 Kernel Mode에서만 실행 가능하도록 하드웨어 수준에서 차단한다.

2. 왜 사용하는가

모든 프로그램이 Kernel Mode로 실행된다면 버그가 있는 애플리케이션 하나가 디스크를 직접 조작하거나 다른 프로세스의 메모리를 덮어써서 시스템 전체를 망가뜨릴 수 있다. 권한 분리의 목적은 다음과 같다.

안정성: 애플리케이션의 오류가 커널이나 다른 프로세스에 영향을 주지 않도록 격리한다.
보안: 악의적인 코드가 하드웨어를 직접 제어하거나 커널 메모리를 읽는 것을 차단한다.
자원 중재: 여러 프로세스가 동시에 CPU, 메모리, 디스크를 요청할 때 커널이 유일한 중재자 역할을 한다.

웹 개발자 입장에서는 Node.js의 fs.readFile, Python의 open(), DB 드라이버의 소켓 통신 모두 결국 내부적으로 시스템 콜을 호출하고, 이 과정에서 User Mode ↔ Kernel Mode 전환이 발생한다는 점을 이해하는 것이 중요하다.

3. 동작 원리

애플리케이션이 커널 기능이 필요할 때 일어나는 흐름은 다음과 같다.

User Mode에서 실행 중인 프로세스가 시스템 콜(예: read(), write(), socket())을 호출한다.
CPU는 소프트웨어 인터럽트(x86의 INT 0x80 또는 더 빠른 SYSCALL/SYSENTER 명령어)를 발생시킨다.
CPU는 현재 실행 모드를 Kernel Mode로 전환하고, 미리 등록된 시스템 콜 핸들러 테이블(system call table)을 참조해 해당 커널 함수로 점프한다.
커널이 요청된 작업(디스크 읽기, 메모리 할당 등)을 수행한다.
작업이 끝나면 SYSRET/IRET 같은 명령어로 User Mode로 복귀하고, 결과값을 반환한다.

이 전환에는 다음과 같은 비용이 발생한다.

CPU 레지스터 저장/복원
페이지 테이블 컨텍스트 전환 (필요시 TLB flush)
CPU 캐시 지역성(locality) 손실

인터럽트(interrupt)도 유사한 원리로 동작한다. 하드웨어 인터럽트(키보드 입력, 타이머, 네트워크 카드 이벤트)가 발생하면 CPU는 현재 실행 중인 User Mode 코드를 중단하고 Kernel Mode로 전환해 인터럽트 핸들러를 실행한 뒤 원래 작업으로 복귀한다.

4. 코드 예제

시스템 콜이 실제로 몇 번 발생하는지 strace로 직접 관찰할 수 있다.

shell

# Python 스크립트가 발생시키는 시스템 콜을 추적
strace -c python3 -c "
with open('/tmp/test.txt', 'w') as f:
    f.write('hello kernel mode')
"

shell

# 출력 예시 (환경에 따라 수치는 달라짐)
% time     seconds  usecs/call     calls    syscall
------ ----------- ----------- --------- ----------------
 45.23    0.000412          20        20 mmap
 20.11    0.000183          18        10 openat
 15.02    0.000137          13        10 read
 10.05    0.000091           9        10 write
  9.59    0.000087           8        10 close

Python에서 시스템 콜 오버헤드를 간접적으로 측정하는 예제:

python

import time
import os

# User Mode에서만 수행되는 순수 연산 (시스템 콜 없음)
start = time.perf_counter()
total = 0
for i in range(1_000_000):
    total += i
elapsed_user = time.perf_counter() - start

# 시스템 콜을 반복 호출하는 연산 (Kernel Mode 전환 발생)
start = time.perf_counter()
fd = os.open("/tmp/test.txt", os.O_WRONLY | os.O_CREAT)
for _ in range(1_000):
    os.write(fd, b"x")  # 매 호출마다 User -> Kernel 전환
os.close(fd)
elapsed_syscall = time.perf_counter() - start

print(f"순수 연산(100만 회): {elapsed_user:.6f}초")
print(f"시스템 콜(1000회): {elapsed_syscall:.6f}초")

같은 작업량이라도 시스템 콜 횟수가 늘어나면 전환 오버헤드가 누적되어 성능이 급격히 나빠진다. 이것이 버퍼링(buffering)이 필요한 이유다.

python

import os
import time

# 매번 write() 시스템 콜을 호출하는 비효율적인 방식
def write_unbuffered(path, count):
    fd = os.open(path, os.O_WRONLY | os.O_CREAT | os.O_TRUNC)
    for _ in range(count):
        os.write(fd, b"x")
    os.close(fd)

# 사용자 공간 버퍼에 모았다가 한 번에 write()하는 방식
def write_buffered(path, count):
    with open(path, "wb", buffering=8192) as f:
        for _ in range(count):
            f.write(b"x")

start = time.perf_counter()
write_unbuffered("/tmp/a.txt", 100_000)
print(f"unbuffered: {time.perf_counter() - start:.4f}초")

start = time.perf_counter()
write_buffered("/tmp/b.txt", 100_000)
print(f"buffered: {time.perf_counter() - start:.4f}초")

5. 시간 복잡도 또는 성능 특성

시스템 콜과 컨텍스트 스위칭은 정확한 절대 수치가 CPU 아키텍처, 커널 버전, SYSCALL vs INT 0x80 여부에 따라 달라지므로 일반적인 경향만 정리한다.

단순한 시스템 콜(getpid() 등)의 오버헤드는 사용자 공간 함수 호출보다 수십~수백 배 느리다. 이는 모드 전환 자체의 비용 때문이다.
프로세스 간 컨텍스트 스위칭은 시스템 콜보다 비용이 훨씬 크다. 페이지 테이블 전환과 TLB(Translation Lookaside Buffer) flush, 캐시 미스가 추가되기 때문이다.
vDSO(virtual Dynamic Shared Object) 같은 메커니즘은 gettimeofday()처럼 자주 호출되는 일부 시스템 콜을 실제 모드 전환 없이 User Mode에서 처리해 오버헤드를 없앤다.

정확한 나노초/마이크로초 단위 수치는 벤치마크 환경마다 크게 달라지므로 이 문서에서는 단정적인 절대값을 제시하지 않는다. 실제 프로젝트에서는 perf stat이나 strace -T 옵션으로 직접 측정하는 것이 정확하다.

6. 실무 사용 사례

Node.js의 libuv 스레드 풀: 파일 I/O처럼 블로킹되는 시스템 콜을 별도 스레드에서 실행해 이벤트 루프가 Kernel Mode 전환 대기로 멈추지 않게 한다.
DB 커넥션 풀: 소켓 연결(connect(), accept())은 시스템 콜이므로, 매 요청마다 새 연결을 맺으면 시스템 콜 오버헤드가 누적된다. 커넥션 풀은 이를 재사용해 오버헤드를 줄인다.
io_uring: 리눅스에서 시스템 콜 횟수 자체를 줄이기 위해 등장한 비동기 I/O 인터페이스로, 사용자 공간과 커널이 공유 메모리 링 버퍼를 통해 통신해 매 요청마다 모드 전환이 발생하지 않도록 설계되었다.
컨테이너 기술: Docker 같은 컨테이너는 별도의 커널을 두지 않고 호스트 커널을 공유하면서 namespace, cgroup이라는 커널 기능으로 격리를 구현한다. 즉 컨테이너의 User Mode 프로세스도 결국 호스트의 Kernel Mode를 통해 자원에 접근한다.

7. 주의할 점

시스템 콜이 많다고 무조건 느린 것은 아니다. 문제는 작은 단위 작업을 반복적으로 시스템 콜로 처리할 때 전환 비용이 누적되는 것이다. 버퍼링, 배치 처리로 완화할 수 있다.
Kernel Mode에서 실행되는 코드(디바이스 드라이버, 커널 모듈)는 버그가 발생하면 프로세스 하나가 아니라 시스템 전체가 크래시(kernel panic)될 수 있다. User Mode 프로세스의 버그는 보통 해당 프로세스만 종료된다.
가상화 환경(VM)에서는 게스트 OS의 Kernel Mode 명령어 일부를 하이퍼바이저가 가로채 처리(트랩 앤 에뮬레이트 또는 하드웨어 가상화 확장 사용)하므로 실제 물리 환경보다 시스템 콜 오버헤드가 더 클 수 있다.
Meltdown, Spectre 같은 CPU 취약점은 User Mode에서 Kernel Mode 메모리를 부적절하게 추측 실행(speculative execution)을 통해 읽어낼 수 있다는 점을 악용한 것으로, 패치 이후 시스템 콜 성능이 저하되는 부작용이 있었다.

8. 핵심 정리

User Mode와 Kernel Mode는 CPU 하드웨어가 강제하는 권한 분리 체계로, 애플리케이션 코드와 커널 코드를 격리해 시스템 안정성과 보안을 지킨다. 애플리케이션이 하드웨어 자원에 접근하려면 시스템 콜을 통해 반드시 Kernel Mode로 전환해야 하며, 이 전환에는 무시할 수 없는 성능 비용이 따른다. 웹 개발자는 이 비용을 직접 다룰 일은 적지만, 버퍼링·커넥션 풀링·비동기 I/O 같은 최적화 기법이 왜 필요한지 이해하려면 이 경계의 존재를 알고 있어야 한다.