사용자 모드 vs 커널 모드
CPU의 실행 권한을 두 단계로 나누어 OS를 보호하는 메커니즘
왜 필요한가?
[모드 분리 없이]
사용자 프로그램이 직접:
- 디스크에 쓰기
- 메모리 맘대로 접근
- 다른 프로세스 메모리 읽기
→ 시스템 불안정! 보안 위험!
[모드 분리]
사용자 프로그램 → 시스템 콜 → OS가 대신 처리
→ OS가 검증 후 안전하게 실행
두 모드 비교
| 구분 | 사용자 모드 | 커널 모드 |
|---|
| 권한 | 제한적 | 모든 권한 |
| 접근 | 자기 메모리만 | 전체 메모리 |
| H/W 접근 | 불가 | 가능 |
| Mode bit | 1 | 0 |
| 실행 코드 | 애플리케이션 | OS 커널 |
모드 전환
[사용자 모드]
프로그램 실행 중
read() 호출 → 시스템 콜
↓ (트랩)
[커널 모드]
OS: 파일 읽기 수행
결과 준비
↓ (복귀)
[사용자 모드]
결과 받아서 계속 실행
시스템 콜
애플리케이션이 OS 에 서비스를 요청하는 인터페이스입니다.
| 분류 | 시스템 콜 |
|---|
| 프로세스 | fork(), exec(), exit() |
| 파일 | open(), read(), write() |
| 네트워크 | socket(), connect(), send() |
| 메모리 | mmap(), brk() |
모드 전환 비용
시스템 콜 1회 ≈ 수백 나노초
비용:
1. 레지스터 저장/복원
2. 모드 비트 전환
3. 커널 스택으로 전환
4. 보안 검증
| 방식 | 비용 | 설명 |
|---|
| 함수 호출 | ~1ns | 모드 전환 없음 |
| 시스템 콜 | ~100-1000ns | 모드 전환 필요 |
| 컨텍스트 스위칭 | ~1-10us | 프로세스 전환 |
실무 연결
| 상황 | 영향 |
|---|
| I/O 많은 서버 | 시스콜 빈번 → 오버헤드 |
| io_uring (Linux) | 시스콜 최소화로 성능 향상 |
| Docker 컨테이너 | 커널 공유 (VM보다 가벼움) |
| eBPF | 커널 모드에서 안전하게 코드 실행 |
Q.사용자 모드와 커널 모드의 차이를 설명해주세요.
실행할 수 있는 명령과 접근할 수 있는 자원이 다릅니다.
| 항목 | 사용자 모드 | 커널 모드 |
|---|
| 권한 | 제한적 | 모든 명령과 메모리 |
| 하드웨어 접근 | 직접 불가 | 가능 |
| 다른 프로세스 메모리 | 볼 수 없다 | 볼 수 있다 |
| 오류의 영향 | 그 프로세스만 죽는다 | 시스템 전체가 멈출 수 있다 |
나누는 이유는 응용 프로그램의 실수나 악의가 시스템 전체를 망가뜨리지 못하게 하기 위해서입니다. 디스크에 직접 쓰거나 다른 프로세스의 메모리를 읽는 것을 하드웨어 수준에서 막습니다.
응용 프로그램이 그런 일을 하려면 시스템 콜로 커널에 요청해야 하고, 커널이 권한과 정당성을 검사한 뒤 대신 수행합니다.
흔한 실수: 모드를 소프트웨어 설정으로 설명하는 것. CPU 에 특권 수준 비트가 있고 하드웨어가 강제합니다. 그래서 우회할 수 없습니다.
Q.시스템 콜이란 무엇이고 왜 필요한가요?
사용자 모드 프로그램이 커널의 기능을 요청하는 유일한 통로입니다.
| 분류 | 예 |
|---|
| 프로세스 | fork, exec, exit, wait |
| 파일 | open, read, write, close |
| 네트워크 | socket, connect, send, recv |
| 메모리 | mmap, brk |
필요한 이유는 권한 분리 때문입니다. 파일을 읽으려면 디스크에 접근해야 하는데 그것은 커널만 할 수 있습니다. 그래서 요청하고, 커널이 권한을 검사한 뒤 대신 수행하고 결과를 돌려줍니다.
호출하면 모드가 전환됩니다. 사용자 모드에서 커널 모드로 갔다가 결과와 함께 돌아옵니다. 이 전환에 비용이 있어, 시스템 콜을 반복문 안에서 부르면 그 비용이 누적됩니다.
흔한 실수: 라이브러리 함수와 시스템 콜을 같은 것으로 보는 것. printf 는 라이브러리 함수이고 내부에서 write 시스템 콜을 부릅니다. 라이브러리가 버퍼에 모아 두었다가 한 번에 호출해 전환 횟수를 줄입니다.
Q.모드 전환의 비용은 어느 정도인가요?
문맥 교환보다 훨씬 싸지만 공짜는 아닙니다.
| 작업 | 대략적인 비용 |
|---|
| 함수 호출 | 수 나노초 |
| 시스템 콜 (모드 전환) | 수십에서 수백 나노초 |
| 문맥 교환 | 수 마이크로초 |
| 페이지 폴트 (디스크) | 수십에서 수백 마이크로초 |
모드 전환 자체는 레지스터 일부를 저장하고 특권 수준을 바꾸는 정도입니다. 주소 공간은 그대로라 TLB 와 캐시가 유지됩니다.
그래도 반복문 안에서 부르면 누적됩니다. 1바이트씩 100만 번 쓰면 시스템 콜이 100만 번이고, 버퍼에 모아 한 번에 쓰면 한 번입니다. 표준 입출력 라이브러리가 버퍼를 두는 이유입니다.
흔한 실수: 모드 전환과 문맥 교환을 같은 비용으로 보는 것. 자릿수가 다르고, 최적화 우선순위도 달라집니다.
Q.컨테이너가 VM보다 가벼운 이유를 모드 관점에서?
컨테이너는 호스트 커널을 그대로 쓰기 때문입니다. 게스트 커널이 없습니다.
| 항목 | 가상 머신 | 컨테이너 |
|---|
| 커널 | 게스트마다 따로 | 호스트 커널을 공유 |
| 시스템 콜 경로 | 게스트 커널을 거쳐 하이퍼바이저로 | 호스트 커널로 바로 |
| 부팅 | 커널 부팅이 필요. 수십 초 | 프로세스 시작. 수백 밀리초 |
| 메모리 | 게스트 OS 몫이 따로 든다 | 프로세스 몫만 |
| 격리 수준 | 하드웨어 수준. 강하다 | 네임스페이스와 cgroup. 상대적으로 약하다 |
컨테이너 안의 프로세스는 호스트에서 보면 그냥 프로세스입니다. 네임스페이스로 보이는 범위를 제한하고 cgroup 으로 쓸 수 있는 자원을 제한할 뿐입니다.
그래서 격리가 약한 대가가 있습니다. 커널 취약점이 나오면 컨테이너를 벗어날 수 있고, VM 은 하이퍼바이저를 한 번 더 뚫어야 합니다.
흔한 실수: 컨테이너를 가벼운 VM 으로 설명하는 것. 가상화 대상이 다릅니다. VM 은 하드웨어를, 컨테이너는 운영체제 수준의 뷰를 가상화합니다.
먼저 스스로 답해보고 아래 답변과 견줘보세요. 막히는 부분은 문제로 확인할 수 있어요.
읽었으면 문제로 확인해보세요
운영체제 문제를 풀면 틀린 문제가 자동으로 노트에 쌓입니다. 가입 없이 5문제를 먼저 풀어볼 수도 있어요.