들어가며
이번 글에서는 OS가 어떤 서비스를 제공하는지, 프로그램이 OS에게 어떻게 서비스를 요청하는지, 그리고 OS 내부가 어떤 구조로 설계되어 있는지를 다루어 보겠습니다.
1. OS가 제공하는 서비스

OS는 크게 두 가지 관점의 서비스를 제공한다. 하나는 사용자와 프로그램을 위한 서비스이고, 다른 하나는 시스템 자체의 효율적인 운영을 위한 서비스다.
사용자를 위한 서비스
- User Interface는 사용자가 OS와 상호작용하는 방법이다. CLI(Command Line Interface)와 GUI(Graphic User Interface) 두 가지가 있다.
- Program Execution은 프로그램을 메모리에 적재하고 실행하며 종료하는 역할이다.
- I/O Operations는 키보드·마우스 입력과 모니터·프린터 출력 등 I/O 장치를 제어한다.
- File System Manipulation은 파일과 디렉토리의 생성·삭제·읽기·쓰기·검색을 수행한다.
- Communications는 프로세스 간 정보를 교환한다(Shared Memory 또는 Message Passing). Error Detection은 하드웨어(메모리 오류, 전원 이상), I/O 장치(네트워크 연결 실패), 사용자 프로그램(산술 오버플로우, 잘못된 메모리 접근) 등의 오류를 감지한다.
시스템 효율을 위한 서비스
사용자에게 직접 보이지는 않지만 시스템이 효율적으로 동작하기 위한 서비스도 있다.
- Resource Allocation은 멀티태스킹 환경에서 CPU 사이클, 메모리, 파일 저장소, I/O 장치를 여러 사용자와 프로세스에 적절히 배분한다.
- Accounting은 어떤 사용자가 얼마나 어떤 종류의 자원을 사용하는지 기록한다.
- Protection and Security는 시스템 자원에 대한 접근을 제어하고(Protection), 사용자 인증과 비정상적인 접근 방어를 수행한다(Security).
2. User Interface — CLI vs GUI
- CLI(Command Line Interface) 는 키보드 기반 인터페이스다. Shell이 사용자 명령을 받아 실행하는 Command Interpreter 역할을 한다. bash, csh 등이 대표적이며, 명령은 Shell 내부에 내장된 built-in command(cd, alias 등)와 별도 프로그램으로 구현된 명령(ls, vi 등) 두 가지 방식으로 구현된다.
- GUI(Graphic User Interface) 는 마우스 기반 인터페이스로 창과 메뉴 시스템으로 구성되며 아이콘이 파일, 프로그램, 동작을 나타낸다. 현대 OS(Windows, Mac OS X, Linux)는 CLI와 GUI를 모두 제공한다.
3. System Call

System Call이란?
System Call은 프로세스가 OS에게 서비스를 요청하는 인터페이스.
프로세스와 OS 사이의 필수적인 연결 창구로, 일반적으로 C/C++로 작성된다. 하드 디스크 접근, 새 프로세스 생성 등이 대표적인 예다.
왜 System Call이 필요한가?
프로세스는 User Mode에서 실행되므로 하드웨어에 직접 접근할 수 없다. 하드웨어 접근이 필요한 작업은 반드시 Kernel Mode로 전환해서 수행해야 하고, 그 전환 요청이 바로 System Call이다.
API vs System Call
프로그래머는 System Call을 직접 호출하기보다 API(Application Program Interface) 를 통해 간접적으로 사용한다. 대표적인 API로는 Win32 API(Windows), POSIX API(UNIX/Linux), Java API가 있다. API를 사용하는 이유는 두 가지다.
- 첫째로 Portability(이식성) 로, API는 OS 내부 구현과 분리되어 있어 같은 코드가 다른 OS에서도 동작한다.
- 둘째로 Easy to use(편의성) 로, 프로그래머는 System Call의 구현 방식을 알 필요 없이 API 사용법만 알면 된다.
System Call Handling
System Call이 실행되면 User Program이 fork() 같은 함수를 호출하고, libc의 래퍼 함수가 %eax 레지스터에 시스템 콜 번호를 저장한 뒤 int $0x80 명령으로 소프트웨어 인터럽트를 발생시킨다. 이 인터럽트는 Interrupt Vector Table의 0x80 항목인 system_call() 함수를 실행하고, System Call Table에서 번호에 해당하는 실제 커널 함수(예: sys_fork())를 찾아 실행한다. 작업이 완료되면 결과값을 User Program에 반환한다.
파라미터 전달 방법
System Call은 식별 번호 외에 추가 정보가 필요할 때가 많다. 매개변수 전달 방식은 세 가지다.
- 레지스터(Registers) 에 직접 넣는 방식은 가장 빠르지만 넣을 수 있는 양이 제한적이다.
- 블록/테이블(Block/Table) 방식은 매개변수를 메모리 블록에 저장하고 그 주소만 레지스터로 전달한다(Linux, Solaris 사용).
- 스택(Stack) 방식은 프로그램의 스택에 매개변수를 push하고 커널이 pop하여 사용한다.
System Call의 종류
| 분류 | 역할 | 예시 |
|---|---|---|
| Process control | 프로세스 생성/종료/실행 | fork(), execve(), getpid() |
| File management | 파일 생성/삭제/읽기/쓰기 | open(), read(), write(), close() |
| Memory management | 메모리 할당 | brk() |
| Information maintenance | 시간, 속성 조회/설정 | time() |
| Communications | 프로세스 간 통신 | socket(), bind(), connect() |
4. OS 설계 원칙
Policy와 Mechanism의 분리
OS 설계에서 가장 중요한 원칙 중 하나다.
- Mechanism(메커니즘) 은 "어떻게(how) 할 것인가"에 대한 것이다. 예를 들어 CPU 보호를 위한 Timer 구현이 해당한다.
- Policy(정책) 는 "무엇을(what) 할 것인가"에 대한 것이다. 예를 들어 Timer를 얼마로 설정할 것인가가 해당한다.
이 둘을 분리하면 Policy가 바뀌어도 Mechanism을 바꾸지 않아도 된다. CPU Scheduling에서 Mechanism은 "우선순위에 따라 프로세스를 선택하는 기능"이고, Policy는 "I/O bound 프로세스에게 더 높은 우선순위를 줄 것인가"다. Policy만 바꿔서 다양한 스케줄링 전략을 적용할 수 있다.
5. OS 구조

Simple Structure (단순 구조)
MS-DOS, 초기 UNIX가 대표적이다. 인터페이스와 기능 계층이 잘 분리되어 있지 않아 애플리케이션이 I/O 루틴에 직접 접근할 수 있었다. 하나의 애플리케이션이 실패하면 시스템 전체가 충돌할 수 있다는 심각한 문제가 있다. 단순하지만 안전하지 않고, 유지보수도 어렵다.
Layered Structure (계층 구조)
OS를 여러 개의 계층(Layer)으로 나누는 구조다. 최하위 계층(Layer 0)은 하드웨어, 최상위 계층(Layer N-1)은 사용자 인터페이스다. 각 계층은 그 아래 계층의 기능만 사용한다.
장점은 디버그가 쉽다는 점이다. 단점은 계층을 명확히 정의하기 어렵고, 계층을 거칠 때마다 오버헤드가 발생하여 비효율적이라는 점이다.
Microkernel Structure (마이크로커널 구조)
커널에서 핵심 기능(IPC, Virtual Memory, Scheduling)만 남기고 나머지(파일 시스템, 디바이스 드라이버 등)를 사용자 공간으로 이동시킨 구조다. 사용자 모듈 간 통신은 Message Passing을 통해 이루어진다. Mach, QNX, Windows NT가 대표적인 예다.
- 장점은 확장이 쉽고(easy to extend), 이식성이 좋으며(easy to port), 커널에서 실행되는 코드가 적어 안전하다(reliable and secure)는 것이다.
- 단점은 사용자 모듈과 커널 간의 빈번한 통신으로 인한 성능 저하(Performance Degradation) 다.
Module Structure (모듈 구조)
현대 OS 대부분이 채택하는 방식이다. 객체지향 방식으로 커널을 구현하며, 각 핵심 컴포넌트를 분리된 모듈로 만든다. 각 모듈은 알려진 인터페이스로 서로 통신하며, 필요할 때만 커널에 동적으로 로드된다. Solaris, Linux, Mac OS X가 대표적이다. Microkernel과 달리 모듈들이 커널 공간에서 실행되므로 성능 저하 문제가 없고, Layered보다 훨씬 유연하다.
| 구조 | 특징 | 장점 | 단점 | 예시 |
|---|---|---|---|---|
| Simple | 계층 없음 | 단순함 | 불안정, 비보안 | MS-DOS |
| Layered | 계층별 분리 | 디버그 용이 | 비효율적 | - |
| Microkernel | 최소 커널 + 사용자 공간 | 안정적, 이식성 | 성능 저하 | Mach, QNX |
| Module | 동적 모듈 로드 | 유연성, 성능 | 인터페이스 설계 복잡 | Linux, Solaris |
6. System Boot

Bootloader는 컴퓨터 전원이 켜질 때 OS를 디스크에서 메모리로 적재(load)하는 프로그램이다. 시스템 진단(diagnostics) 실행, 커널 위치 탐색, 커널을 메모리에 적재하고 시작하는 역할을 한다. 소형 시스템은 Bootloader와 OS를 ROM에 저장하고, PC 같은 대형 시스템은 Bootloader는 ROM에, OS는 디스크에 저장한다.
Linux 기반 PC의 부팅 과정은 ① BIOS 실행(ROM에서 하드웨어 진단 및 부팅 장치 탐색) → ② Bootloader 실행(디스크의 boot block에서 커널을 메모리에 적재) → ③ 커널 실행(하드웨어 초기화, 루트 파일시스템 마운트) → ④ init 프로세스 실행(PID 1, daemon·shell 등 시작) 순서로 진행된다.
전체 정리
OS는 사용자를 위한 서비스(UI, 프로그램 실행, I/O, 파일 관리, 통신, 오류 감지)와 시스템 효율을 위한 서비스(자원 할당, 회계, 보호/보안)를 제공한다.
System Call은 프로세스가 OS에 서비스를 요청하는 인터페이스로, 프로그래머는 직접 System Call을 쓰지 않고 API(Win32, POSIX, Java)를 통해 간접적으로 사용한다. API는 이식성과 편의성을 제공한다.
OS 구조는 Simple → Layered → Microkernel → Module 순으로 발전했다. 현대 OS는 대부분 Module 구조를 채택하며, 마이크로커널의 안정성과 모듈의 성능을 함께 추구한다. 부팅 과정은 BIOS → Bootloader → Kernel → init 순서로 진행된다.
'Computer Science > OS(운영 체제)' 카테고리의 다른 글
| [OS] 4. Thread(쓰레드)란? (0) | 2026.05.03 |
|---|---|
| [OS] 3. 프로세스(Process)란? (0) | 2026.04.29 |
| [OS] 1. Introduction to Operating Systems (0) | 2026.04.29 |
경이로운 BE 개발자가 되기 위한 프로그래밍 공부 기록장
도움이 되었다면 "❤️" 또는 "👍🏻" 해주세요! 문의는 아래 이메일로 보내주세요.