본문으로 이동
  • 현재 모든 문서는 작성 중입니다. 보시는 데 불편함이 있더라도 양해 부탁드립니다.

운영체제 기본/서문

~ldmsys
관리자 (토론 | 기여)님의 2026년 11월 1일 (일) 09:30 판 (자원 관리자와 제어 프로그램의 역할을 서문으로 보강; 추상화 623판의 운영체제 등장 배경과 출처 분리)
(차이) ← 이전 판 | 최신판 (차이) | 다음 판 → (차이)

컴퓨터에서 음악을 들으며 문서를 편집하고 파일을 내려받는다고 하자. 세 프로그램은 모두 CPU에서 명령을 실행하고, 메모리에 데이터를 두고, 장치를 사용한다. 프로그램마다 하드웨어를 자기 것처럼 차지한다면 다른 프로그램은 실행할 수 없다. 한 프로그램의 잘못된 메모리 접근이 다른 프로그램의 작업을 망가뜨릴 수도 있다. 운영체제(Operating System, OS)는 프로그램이 실행되는 환경을 마련하고, 여러 프로그램이 한정된 자원을 함께 사용하도록 관리한다.

이 역할은 자원 관리자(Resource Allocator)와 제어 프로그램(Control Program)이라는 두 관점으로 나누어 볼 수 있다. 자원 관리자는 누구에게 어떤 자원을 얼마나 줄지 결정하고, 제어 프로그램은 프로그램의 실행을 관리하여 오류나 잘못된 사용이 전체 실행 환경을 무너뜨리지 않도록 한다.[1]

자원 배분

CPU 시간, 메모리 공간, 장치의 처리 능력은 무한하지 않다. 동시에 실행하려는 프로그램이 많아지면 누구를 먼저 실행하고 얼마나 기다리게 할지 정해야 한다. 메모리가 부족하면 새 요청을 모두 받아 줄 수도 없다. 운영체제는 이러한 요구를 조정하고, 작업이 끝나면 사용하던 자원을 회수하여 다른 작업에 배정한다.

배분의 목표가 항상 같은 것은 아니다. 파일 변환 작업을 한꺼번에 오래 실행하면 처리량을 높일 수 있지만, 그동안 문서 편집기의 입력 반응이 늦어질 수 있다. 사용 가능한 자원을 낭비하지 않는 효율, 특정 작업만 계속 기다리지 않게 하는 공정성, 사용자의 요청에 빠르게 반응하는 응답성 사이에서 상황에 맞는 기준이 필요하다. 운영체제가 자원을 나눈다는 것은 모든 프로그램에 같은 양을 준다는 뜻이 아니다.[1]

프로그램 실행의 제어

자원을 나누어 주는 것만으로는 여러 프로그램을 안정적으로 실행할 수 없다. 프로그램 하나가 반복문에서 빠져나오지 못하더라도 다른 프로그램은 실행되어야 한다. 잘못된 포인터로 자기 영역 밖에 쓰려고 해도 다른 프로그램이나 운영체제의 메모리를 훼손해서는 안 된다. 운영체제는 실행을 시작하고 중단하며, 오류를 처리하고, 종료한 프로그램의 자원을 정리한다.

이때 운영체제가 계산 결과나 프로그램의 모든 논리를 검사하는 것은 아니다. 프로그램이 실행될 범위와 자원을 관리하고, 허용하지 않은 접근이 다른 작업까지 망가뜨리지 않도록 하는 것이다. 각 메모리 접근을 운영체제 코드가 일일이 검사할 수는 없으므로 CPU의 권한 모드와 메모리 접근 검사 같은 하드웨어의 도움을 받는다. 운영체제가 설정한 경계 안에서 프로그램이 실행되도록 강제하는 구체적인 방법은 보호에서 다룬다.[2]

격리는 모든 교류를 막는다는 뜻도 아니다. 서로 데이터를 주고받아야 하는 프로그램에는 운영체제가 정한 공유와 통신 방법을 제공한다. 각자 독립적으로 실행할 수 있게 하면서 필요한 협력도 가능하게 하는 것이 목적이다.[2]

운영 자동화와 자원 공유

초기 대형 컴퓨터에서는 프로그램을 준비하고 실행하는 일 자체가 큰 부담이었다. 사용자가 정해진 시간 동안 제어 콘솔을 조작하고, 프로그램과 데이터를 넣고, 실행 결과를 회수했다. 다음 작업을 준비하는 동안에는 계산할 일이 있어도 기계가 멈춰 있었다. 비싼 컴퓨터를 더 오래 가동하고 사람의 반복 작업을 줄이기 위해, 작업의 시작과 종료를 관리하는 모니터(Monitor)와 여러 작업을 차례로 실행하는 일괄 처리(Batch Processing)가 발전했다. GM-NAA I/O 같은 초기 시스템은 한 작업이 끝나거나 실패한 뒤에도 다음 작업으로 넘어가도록 실행을 자동화했다.[3]

작업 사이의 공백을 줄여도 실행 중인 프로그램이 입출력을 기다리면 CPU가 쉴 수 있었다. 다중 프로그래밍(Multiprogramming)은 여러 프로그램을 준비해 두고, 하나가 기다리는 동안 다른 프로그램에 CPU를 배정하여 자원 이용률을 높였다. 그 대신 운영체제가 각 프로그램의 실행 상태와 메모리 배치를 관리해야 했고, 준비된 프로그램을 보관할 메모리도 더 필요했다.[4]

시분할(Time Sharing)은 여기에 대화형 사용의 요구를 더했다. 작업을 제출하고 결과가 돌아올 때까지 기다리는 대신, 여러 사용자가 단말에서 명령을 내리고 응답을 받을 수 있어야 했다. 이를 위해 운영체제는 CPU 시간을 나누고 각 사용자의 작업을 이어서 실행했다. 초기 시분할 시스템인 CTSS(Compatible Time-Sharing System)의 목표도 기계의 처리량만 늘리는 데 있지 않았다. 프로그램을 수정하고 결과를 확인하는 사람의 대기 시간을 줄이는 것이 중요한 목적이었다.[5]

공통 서비스와 추상화

운영체제는 자원을 관리하면서 프로그램이 사용할 공통 서비스도 제공한다. 파일을 읽거나 장치에 데이터를 보내는 일을 각 프로그램이 하드웨어마다 다시 구현하지 않아도 된다. 프로그램은 운영체제가 제공하는 인터페이스로 작업을 요청하고, 운영체제는 실제 자원과 요청을 연결한다.

이렇게 실제 자원의 복잡한 동작을 프로그램이 사용할 대상과 연산으로 나타내는 것이 추상화다. 추상화는 운영체제의 목적 전부가 아니라, 자원 배분과 실행 제어를 수행하면서 사용하기 쉬운 환경을 제공하는 설계 방법이다. 다음 장에서는 DOS의 장치 설정 사례에서 출발하여, 실행 환경과 입출력 인터페이스가 어떻게 만들어지는지 살펴본다.

운영체제를 읽을 때는 무엇을 할지 정하는 정책과 그 결정을 실행하는 메커니즘도 구별할 필요가 있다. 다음에 실행할 프로그램을 고르는 기준은 정책이고, 현재 실행 상태를 보관하고 다른 프로그램의 실행을 이어 주는 수단은 메커니즘이다. 총론은 이런 문제와 설계상의 선택을 설명하고, Linux 각론은 실제 구현을 추적한다.

관련 문서

참고 문헌

  1. ↑ 1.0 1.1 Abraham Silberschatz·Peter B. Galvin·Greg Gagne, Operating System Concepts, 9th Edition, Chapter 1: Introduction, 슬라이드 1.4–1.8. 운영체제의 목적, 자원 관리자와 제어 프로그램의 역할.
  2. ↑ 2.0 2.1 MIT PDOS, xv6: Operating system organization, §2.1. 자원 공유, 격리, 상호작용과 물리 자원의 추상화.
  3. ↑ Robert L. Patrick, Operating Systems at Conception (2008). GM-NAA I/O 설계 참여자의 초기 작업 운영과 일괄 처리에 대한 회고.
  4. ↑ Jerome H. Saltzer·John W. Gintell, The Instrumentation of Multics (1970), “Special Instrumentation for Multiprogrammed Demand Paging”. 입출력 대기와 CPU 이용률, 여러 프로그램을 유지하는 메모리 비용.
  5. ↑ MIT Computation Center, The Compatible Time-Sharing System: A Programmer's Guide (1963), 1장. 시분할의 동기와 감독 프로그램에 의한 실행 관리.