[전공생이 설명하는 OS] 쉽게 읽는 OS의 발전 이야기

1. OS 의 목적

  OS는 자원관리자로서의 성경이 강하다. 주로 기기 사용자가 안전하고 효율적으로 하드웨어를 사용할 수 있도록 돕는다. OS 의 목적은 크게 3가지로 나타낼 수 있다. 

1. 편의성. 컴퓨터 사용자가 하드웨어를 조작하기 위한 instruction 이나 구현방법 등을 알지 못해도 안전하게 사용할 수 있게 한다.
2. 효율성. 사용자 경험을 최대화하기 위해 cpu utilization, cache memory, scheduling 등 자원을 관리 한다.
3. 유연함. OS 가 개선될 때, 기존 User Application 에 영향을 주지 않으면서 발전할 수 있도록 한다.

 

2. OS의 발전

William Stalling 교재에서는 OS 의 발전을 크게 4단계로 구분한다.

 

1) Serial Processing System

애니악. 출처 위키피디아

  이 때는 우리가 생각하는 os 가 없었다. 애니악과 같이 진공관과 발광체로 이루어진 거대한 기기에 펀치카드를 입력해서 조작하고, 그 결과를 테이프에 저장하는 방식이었다. 비용이 매우 비싼 국가적 자원이었다. 세계 각 연구소에서 사용하기 위해 예약을 해야했다. 할당된 시간이 되면 먼저 compiler 해당하는 프로그램(펀치카드)을 로딩한 후에, 수행하고자 하는 본래의 프로그램(펀치카드)을 로딩한다. 그 후에 결과물을 테이프에 저장해서 가져간다.

  이처럼 사람이 직접 개입하는 job-to-job transition에는 다음 두가지의 문제가 대두된다. (1) scheduling time, 한정된 자원을 여러 사용자들이 나누어서 사용해야하다보니 컴퓨터를 사용하는 시간을 분배해야했다. 사용자 사용 시간을 분배하는 일부터, 정해진 시간이 되면 해당 프로그램을 종료시키고 다음 사용자가 사용할 수 있도록 준비하는 일이 포함된다. (2) set-up time, 원하는 프로그램을 수행하기 위해서는 compiler 와 같은 프로그램을 로딩하고, 언로딩하는 일이 필요하다. 

  따라서 스케줄링을 자동화하고, setup time 을 줄이는 방향으로 os가 발전하게 된다. 

 

2) Simple Batch System

Memory Layout for a Resident Monitor (출처 William Stalling - OS 8th)

  set-up time 을 줄이기 위해, 동일한 컴파일러를 사용하는 job 을 묶어서 처리하려는 batch 시스템이 고안된다. 또 사람이 일일이 개입하는 job-to-job transition 을 자동화하기 위해, JCL(Job Control Language)이 등장하게 된다. 이 시기를 Simple Batch System 이라고 한다.

  이즈음 최초의 batch OS 격인 Monitor 가 등장한다. 사람이 아닌 OS 가 처음으로 등장하면서 요구되는 사항들이 하나 둘 생기기 시작한다.

• job sequencing 을 수행하기 위해서는 OS 가 항상 메모리에 상주해야하기 때문에, OS 와 사용자 프로그램의 메모리 공간을 분리해야한다(Memory Protection). 
• 한 프로그램이 CPU 를 독점하는 것을 방지하기 위한 System timer 가 필요하게 되었다(CPU Protection).
• 그 당시 컴퓨터는 국가적인 자원이기 때문에 CPU가 idle 한 것을 막고 utilization 을 높이기 위해, IO 장치 컨트롤러가 도입되었고 비동기적 io request 에 대한 interrupt 방식이 고안되었다.
• 이런 OS 만의 기능들을 사용자가 함부로 사용할 수 없도록 Privileged Instructions 이 생겨난다.

  하지만 여전히 CPU utilization 이 낮았다. synchronous 한 blocked IO job 에서는 cpu 가 사용되지 않음에도 io device 의 결과를 기다리면서 idle 한 경우가 많았기 때문이다. 컴퓨터는 매우 비싼 국가적 차원의 자원이기 때문에 cpu를 idle 하게 놀리는 것은 낭비였고, cpu utilization을 더 높일 수 있는 방법으로 발전한다.

 

3) Multi-programmed Batch System

  Synchronous blocked io 상황에서 cpu utilization 을 높이기 위해서는, block 되어있는 동안 다른 프로그램을 실행하면 된다. Single Batch System 에서는 메모리에 OS 와 사용자 프로그램 단 두개만 load 되어 있는 상태이다. 이를 uni-programming이라 하고, 따라서 메모리에 2개 이상의 프로그램을 load 하여 상황에 맞게 cpu 를 사용하게 하는 것이 multi-programming 이라 한다. (메모리 관점에서의 용어이다. 흔히 말하는 multi-process는 cpu 관점에서의 용어)

  이 시기에 중요한 기술적 문제는 (1) scheduling, 한 프로그램이 block 되었을 때 어떤 프로그램을 실행시킬 것인지에 대한 선택 문제. (2) memory protection, 우선순위가 낮은 프로그램은 disk 로 swap out 하거나 다른 프로그램을 swap in 시키면서 메모리 내에서 프로그램의 주소가 동적으로 변하게 된다. 따라서 os 뿐만 아니라 사용자 프로그램끼리의 메모리 보호 문제가 대두되면서 MMU(Memory Management Unit) 와 같은 하드웨어의 지원을 받게 된다.

 

4) Time Sharing System

  시간이 흘러, 하드웨어의 값이 점점 저렴해지고 인건비가 상대적으로 비싸졌다. 기존에는 프로그램이 끝나는 것을 마냥 기다리고 있었다. 지금 우리가 화면을 보면서 진행상황을 알 수 있는 것이 아니라, 언제 끝날지도 모른채 그저 할당받은 시간 내에 잘 끝나기만을 기다리는 것이다. CPU 는 열심히 일을 하지만 상대적으로 더 비싼 인간의 노동력이 idle 한 상태인 것이다.

  따라서 사람이 idle 한 것은 노동력 낭비이므로 사람의 utilization 을 더 높이려는 사회적인 요구가 발생하게 된다. 현대의 키보드, 모니터, 마우스처럼 interative하게 작업을 수행하는 것이 중요해졌고, 프로그램의 response time (처음 job 이 제출되고 대기하다가 처음 cpu에 의해 처리될 때의 시간, 반응시간)이 짧아지도록 하는것이 우선시 되었다. 이를 위해 프로그램이 cpu 를 점유하는 시간을 아주 짧게 정해서 순환하도록 했다. 즉 time sharing system 으로 발전했다.

  JCL(job control language)은 유닉스 터미널과 같은 형태로 변경되었고, 여러 사용자가 한번에 접속해서 작업을 요청할 수 있도록 환경이 바뀌었다. 자연스레 multi-user 환경으로 발전하면서 사용자 간의 information Protection 이 중요해지고, access control 등의 기술들이 점차 생겨나기 시작한다.