운영체제의 기초 - 1. Introduction to OS 1

1.1 Batch Monitor

목적

- Operating System이 제공하는 여러가지 기능들을 알아보고

- 그런 기능을 구현하는데 필요한 Computer Science 적인 이론이나 practice들을 공부할 예정

- 결과로 Operating System의 여러가지 기능과 내부구조를 공부하고 

   이를 통해서 Operating System이나 다른 복잡한 소프트웨어 시스템을 잘 개발할 수 있는 능력을 키우고자 함.

Operating System의 여러가지 측면을 하나씩 볼 예정

1. Operating System이 과거부터 현재까지 진화해온 과정을 보겠음

   - OS의 진화의 원인이 됐던 요인들을 파악하고

   - 그 결과로 OS의 변화가 생겨났는지를 공부해 보겠음.

   - OS 진화과정을 3단계로 나눠 살펴볼 예정

      1) 처음 컴퓨터 시스템이 개발된 시기부터 Main Frame이 보편화될 때까지의 시기

      2) 우리가 가장 많이 사용하는 OS의 근간이 되는 Time sharing system이 등장한 시기부터 

          인터넷이 보편화되기 시작한 시기까지

      3) 그 이후부터 오늘 날까지 

첫번째 시기

- 당시의 컴퓨터 시스템을 운영하는 사람들의 가장 큰 목적은 비싼 돈을 주고 개발한 컴퓨터 하드웨어를 가장 잘 활용하는 것임.

  다시 말해 CPU의 utilization을 최대화 하는 것이 목적이었음.

- 그에 비해 인건비는 상대적으로 저렴 했기때문에 인건비에 대한 투자는 고려대상이 아니었음.

- 50년대 초반까지 컴퓨터 시스템에서 OS라는 것은 실제로 존재하지 않았음. 그리고 human operator가 OS역할을 한 것임.

- 당시에 프로그램을 수행시키는 기본 단위를 job이라고 부름

- job이 컴퓨터에 입력되는 방법은 PPT 오른쪽 그림과 같이 펀치카드 형태로 입력이 됨 (ex: OMR 카드)

Operator의 역할

1. 사용자로부터 카드 덱을 수령

2. 카드 덱을 컴퓨터 시스템에 로딩하고 수행

3. 수행 결과를 프린터로 출력

4. 출력된 결과물을 사용자에게 전달

이러한 Operator의 역할을 사람인 human operator가 하는 형태가 됨.

따라서 human operator 한 job을 처리하고 다음 사용자의 job을 받아들이는 그런 과정을 job-to-job transition이라고 말하는데, 

job-to-job transition에 human operator가 개입을 하게 됨으로써 굉장히 느려지게 되는 문제가 발생하기 시작했음.

최초의 OS 등장 배경

Operator의 느린 job-to-job 전환 속도로 인한 컴퓨터 시스템의 비효율성의 해결이 필요

batch monitor (batch란 여러 동일한 속성을 같는 요소들의 묶음을 말함) 

IBM 1401을 I/O processing하는데 사용했음.

먼저 사용자들은 예전처럼 카드 덱의 형태로 job을 컴퓨터에 제출.

이것을 IBM1401이 받아서 Tape에 저장을 함. 

Tape에 저장을 할 때 하나의 job만 저장하는 것이 아니라 여러개의 job을 묶어서 저장.

당시에 batch monitor의 batch란 마그네틱테입에 읽혀진 여러개의 job들을 의미

Operator의 느린 Job-to-Job 전환 문제의 해결 방안

여러 개의 카드 덱(Batch of Jobs)을 하나의 Tape에 기록하고, 컴퓨터 시스템은 이 Tape에 있는 Job들을 순차적으로 수행함으로써 Operator의 느린 Job-to-Job 전환 속도 문제를 해결

이와 같이 1401이라는 I/O machine과 batch monitor을 사용함으로 인해서 

이제는 job-to-job transition에서 human operator의 간섭을 배제할 수 있게 됨.

그 결과로 CPU의 utilization을 좀더 높일 수 있게 됨.

그런데 Batch monitor가 개발이 되고 나니까

CPU의 utilization 좀더 높일 방안을 찾기 시작하였음.

그때 개발자들이 주목했던 가장 큰 특징은 I/O를 하고 있을 때는 CPU가 Idle 할 수 밖에 없다는 것이었죠.

CPU가 입출력도 하고 입출력이 종료될 때까지 계속 I/O device를 모니터링 해야만 했다.

그 시간에 CPU가 다른 유용한 연산을 하게 하면 굉장히 바람직하게 되겠죠? 이러한 필요성을 느끼게 됨.

이런 필요성에 의해서 당시의 IBM 연구자들은 CPU와 I/O 연산을 overlap 시킬 수 있는 그런 하드웨어 mechanism을 개발했음

그것이 IBM 용어로는 I/O Channel 현대적인 의미로 해석해 보면 I/O Channel은 I/O device controller 임.

CPU를 대신해서 I/O device operation을 권장을 하고 대신 I/O operation의 시작과 끝만 CPU가 관심을 두게하는 그런 하드웨어 장치를 I/O Channel이라고 한다.

I/O Channel 사용되면 CPU는 I/O command만 I/O Channel에 전달해 주고 그리고 자기는 돌아와서 계속 다른 연산을 수행할 수 있게 됨.

그러면 I/O operation 이 끝났을 때 CPU가 관심을 가져야 된다고 했잖아요?

그런 controller 전이는 어떻게 일어날까? 지금 많이 사용되는 mechanism인 interrupt가 당시에 최초로 등장하게 됨.

I/O controller가 I/O operation이 끝나면 CPU가 입력된 데이터가 읽어갈 수 있도록 CPU에게 interrupt mechanism을 작동시킴

다시 말해 asynchronous, 비동기적으로 I/O 동작에 종료를 CPU에게 알려주는 mechanism 사용하게 되었음.

이와 같은 하드웨어의 도움으로 인해서 이제 CPU 연산과 I/O 동작이 어느정도 overlap을 할 수 있게 되었음.

최초의 OS에서 CPU Utilization을 낮추는 요인과 이를 극복하기 위한 하드웨어 및 OS의 진화

문제: I/O가 진행되는 동안 CPU가 I/O 작업을 관리하면서 기다려야 함

해결 방안: I/O 작업을 관리해주는 I/O Channel의 도입을 통해 CPU는 I/O 시작과 끝만 관리하고 그 사이에는 다른 작업을 수행할 수 있게 함

--> Interrupt 메커니즘을 지원하는 Batch Monitor의 등장

그런데 여기서 집고 넘어가야 할 점이 있음.

I/O operation의 모든 종류가 다 이와같이 CPU와 I/O operation을 분리시킬 수 있는가?

이 점을 생각해 봐야 한다는 거죠. read operation을 생각해 봅시다.

내 프로그램이 디스크에서 데이터를 읽어오고 싶어합니다. 그런데 디스크 read만 CPU에 신청을 해 놓고 다른 Operation을 수행할 수 있을까요?

그럴 수 없음. 왜냐하면 읽고자하는 데이터가 읽혀져야만 다음 Operation을 수행할 수 있기 때문.

이런 경우에는 아무리 I/O controller와 interrupt mechanism을 도입을 한다 하더라도 CPU 연산과 I/O 연산을 중복시킬 수가 없는 문제가 발생.

이 점을 좀더 우리가 보도록 하겠습니다. 좀더 쉽게 이해하기 위해서 I/O Operation을 2가지로 나눴음.

- Synchronous I/O Operation (동기적)

   CPU가 어떤 연산을 수행하다가 I/O를 만들었을 때, 그 I/O의 수행이 종료되어야만 다음 연산으로 수행이 될 수 있는 것 

- Asynchronous I/O Operation (비동기적)

   그거에 비해서 CPU가 I/O Operation을 시작했는데, 그 결과를 기다리지 않고 바로 다른 CPU 연산을 해도 되는 것.

Q. 동기적 I/O와 비동기적 I/O가 발생하는 경우는 어떤 것이 있는가?

A. 외부로부터 데이터를 입력 받아야 프로그램의 수행을 계속할 수 있는 경우

    동기적 I/O가 필요하고, 외부로 데이터를 출력하고 출력 결과에 상관없이 

    프로그램의 수행을 계속할 수 있는 경우는 비동기적 I/O가 필요하다.

대부분의 Input Operation은 Synchronous I/O

그거에 비해서 대부분의 Output Operation은 Asynchronous I/O

I/O controller가 I/O Operation을 잘 해줄 거 같으니까 명령만 내리면 되는 거죠. 

CPU연산의 다음 부분들은 I/O 연산의 결과에 종속적이지 않기 때문에 바로 수행을 할 수 있는 거죠

I/O Channel 과 Interrupt 메커니즘이라는 하드웨어 기법들을 동원해서 

이제 Asynchronous I/O에 대해서는 CPU와 I/O Operation을 overlapping 시킬 수가 있게 됩니다.

그래서 overlapping 시킨 것 만큼 CPU의 Utilization이 더 증가되는 그런 효과를 얻을 수 있게 되겠죠.

Synchronous I/O 인 경우에는 그런 메커니즘의 효과를 전혀 볼 수가 없음.

여러분이 생각해볼 때, Synchronous I/O와 Asynchronous I/O의 비율이 어떨 것 같은가?

프로그램마다 다르지만 적지않은 Synchronous I/O가 존재하게 됩니다.

Synchronous I/O가 존재하는 상황에서는 어쩔 수 없이 CPU가 I/O Operation 수행되는 동안에 Idle 할 수 밖에 없게 되고 그만큼 CPU Utilization 낮아지는 문제가 발생하게 됨.

Batch Monitor의 한계

비동기적 I/O의 경우에는 CPU Utilization을 높일 수 있지만, 동기적 I/O의 경우에는 여전히 CPU가 I/O 동안 다른 작업을 수행할 수 없기 때문에 Utilization이 낮아짐

현재까지는 현재까지의 Batch monitor를 이용하면 한번에 하나의 job만 컴퓨터를 장악해서 수행할 수 있었음.

그런 경우에는 Synchronous I/O가 발생했을 때는 어쩔 수 없이 CPU가 Idle 할 수 밖에 없다.

그러면 Synchronous I/O가 발생했을 때 CPU가 다른 유용한 연산을 하게 하려면 동시에 다른 job을 함께 수행시켜야 합니다. 

이런 생각들을 하게 되었고, 이러한 생각들을 반영해서 Operating System에 넣었는데 그것이 Multiprogrammed Batch Monitor입니다.

1.2 Multiprogrammed Batch Monitor

Active Job: 수행을 시작했지만 아직 종료되지 않은 상태의 프로그램

Multiprogramming: 컴퓨터 시스템의 메인 메모리에 동시에 여러 개의 Active Job이 존재하는 것

Degree of Multiprogramming: 현재 메인 메모리에 존재하고 있는 Active Job의 개수

사람들이 I/O Channel과 interrupt 메커니즘을 이용을 해서 CPU와 Asynchronous I/O를 overlap시켰고

이제는 multiprogramming을 이용해서 Synchronous I/O 일 때, 다른 job에게 CPU를 넘김으로 해서 CPU Utilization을 더욱 크게 만들 수 있었음.

당시 사람들의 관점에서 볼 때는 Operating System에서 할 수 있는 모든 일들을 하게 됨

1960년 대 초반. IBM 시스템 360 메인 프레임 컴퓨터 개발. 

OS 360이라는 Multiprogrammed Batch Monitor를 장착하려고 했음.

불행히도 Multiprogrammed Batch Monitor의 개발이 3년이나 지연됨

왜냐? 미쳐 생각하지 못했던 기술적인 문제가 발생했기 때문.

Multiprogrammed Batch Monitor의 등장 배경과 새롭게 대두된 문제들

등장 배경: 동기적 I/O로 인한 CPU Utilization 저하 문제를 해결하기 위해

                Multiprogramming을 지원할 필요가 생김

문제점: Memory Protection, Memory Relocation, Concurrent Programming

먼저 Memory Protection의 문제

- Multiprogramming을 하기때문에 등장하기 시작

- C 프로그램에서 가장 어려운 버그가 포인터 에러

- 당시에도 기계어 프로그래밍을 했기 때문에 포인터 에러가 굉장히 중요한 문제였음.

- 지금 현재에 Job2가 수행을 하고 있음. Job2에 포인터 에러가 발생하여 다른 메모리 location을 건들였음.

- Job1이 수행되고 있고, Job2의 메모리 영역을 over ride하는 문제가 생긴 것임.

- 만약 내가 Job2 프로그램을 작성하는 프로그래머라고 생각해 봅시다.

   이런 상황에서 내 프로그램은 제대로된 프로그램을 만들어 내지 못할 것이다.

   이럴 때 프로그래머들의 반응은? 내가 뭔가 잘못했구나... 자기 질책

- 사실은 자기의 잘못이 아니라 다른 job의 잘못

   그러면 어떻게 하느냐? 열심히 자기가 짠 코드를 보며 확인하고 문제가 없어서 

   job을 또 다시 submit을 하게 됨. 그럴 때는 job1과 같이 수행하지 않을 가능성이 높기 때문에 잘 돌아감.

   원인을 모르지만 버그가 고쳐짐. 

- 뿐만아니라 job1의 포인터 에러가 Operation System 영역을 건들인다면 전체 시스템이 crash하는 좀더 심각한 문제가 발생하게 됨.

- 이런 문제를 회피하기 위해서는 메모리를 잘 보호해야 함.

- 이것이 바로 Protection의 문제가 되는 것임

- 어떻게 하면 우리가 Memory Protection을 제공해 줄 수 있는가?

어떤 job이 포인터를 통해서 메모리를 access할 때, 그 타겟 메모리가 그 job에게 부여받은 고정공간에 있는가를 확인을 하면 됨.

그런 기법들을 뒤에서 설명할 예정임.

Multiprogramming으로 등장한 문제 #1: Memory Protection

어떤 Job의 주소 사용 버그로 인해 다른 Job이나 OS의 영역을 침범함으로써 문제를 일으키는 현상을 방지해야 할 필요성이 대두됨

두번째 Memory Relocation의 문제 

- 과거 simple batch monitor 시절에는 user job이 메인메모리의 특정 영역에 load되어 수행이 됐었음.

- 그래서 프로그램을 짤 때, 아니면 컴파일러가 코드를 생성을 할 때, 프로그램은 예를들어 1000번지에서 시작을 한다고 가정을 하고 프로그램을 짤 수가 있었음.

- Multiprogrammed batch 가 되고 나서부터는 그런 특권을 누릴 수 있는 job은 오로지 한개밖에는 없는거죠

   다른 job들은 임의의 메모리 위치에서 수행을 하게 됨.

- 이럴 경우 프로그램을 작성을 할 때 특히 기계어 프로그램을 짤 때, 내 프로그램이 어디에서 시작되는지 어떻게 알고 작성을 할 수 있겠어요?

   컴파일러는 또 어떻게 여러분의 프로그램에 시작주소를 알고 code generation을 시작할 수 있겠어요?

- 이러한 문제가 발생하게 됨

- 그래서 이제는 multiprogramming을 지원하는 batch monitor에서 프로그램을 개발할 때는 job이 메인메모리에 임의의 위치에서 잘 수행될 수 있도록 프로그램을 작성해 주어야 함.

- 이것을 바로 Memory Relocation의 문제라고 함

Multiprogramming으로 등장한 문제 #1: Memory Relocation

Job이 메인 메모리의 어느 위치에 로드될 지를 알 수 없기 때문에 임의의 주소에서도 문제없이 수행될 수 있어야 함

- 즉, Relocation의 문제와 Protection의 문제는 Multiprogramming으로 인해서 시작이 된 것임

- 그렇다면 어떻게 Relocation의 문제를 해결할 수 있을까?

- 하드웨어 메커니즘을 개발하기 시작함. 그것이 Base Register (프로그램이 로드된 시작주소를 담고 있는 주소가 됨)

- 그리고 프로그램은 이제 새로운 가정을 통해서 개발이 됨

   모든 프로그램이 0번지부터 수행이 된다라고 가정하게 됨.

   그리고 실제 주소가 만들어질 때는 Base Register에 있는 자기의 시작주소와 합쳐져서 주소가 생성이 됨.

   이 기법이 바로 Base Register임

- Memory Relocation의 문제를 해결하기 위해서 이제 Base Register를 도입했다고 했죠?

- 이 Base Register는 예를들면 job2가 현재 수행이 되고 있다면 job2의 시작주소인 2500번지를 가리키고 있게 될 것임.

  그리고 job2의 내부 프로그램을 들여다 보면 나는 0번지 부터 수행을 한다는 가정을 하고 코드가 생성이 되어 있음.

  그래서 job2의 0번지는 실제적으로는 Base Register 값 2500이 더해져서 2500번지가 되는거죠

- 이런 작업들은 run time에 자동적으로 이루어져야 될 겁니다.

- 그리고 또 다른 측면인 Memory Protection을 위해서는 job2의 사이즈를 또 다른 Register에 저장을 합니다.

  그 Register를 Bound Register라고 한다.

  그래서 job2의 address가 0부터 1500의 range 안에 있는지를 run time에 체크를 함.

  그것을 벗어나게 되면 Protection 에러를 만들면 됨.

하드웨어 지원을 통한 Memory Protection과 Memory Relocation 방안

Memory Protection

Job이 사용하는 메인 메모리의 시작 주소(Base Register에 저장)와 Job이

사용하는 메모리의 크기(Bound Register에 저장)를 사용해 현재 접근하려는

주소값이 Base Register와 Base Register+Bound Register 사이에 있는지를 확인

Memory Relocation

프로그램을 작성할 때는 항상 0번지에 로드된다고 가정하고 주소값들을 계산하고,

수행 시에 주소값을 계산하기 위해서는 Base Register의 값을 더해서 실제 물리적

메모리의 주소를 계산

이제 컴퓨터 시스템에서 생성되는 주소를 크게 2가지로 나누어 보기 시작함.

1. CPU에서 프로그램에 의해서 바로 생성된 주소 (Logical Address)

   이 논리적인 주소는 run time에 여러가지 변환과정을 거치게 됨

   논리적인 주소는 base register의 값과 더해지게 됨

   그리고 나서 그 base register와 더해진 값이 base+bound value 보다 작은지를 체크하게 됨.

   왜 체크해야 하는가? 이것을 넘어서게 되면 다른 메모리 영역을 건들인 다는 것

   이것을 통과했을 때만 물리메모리에 접근할 수 있음.

2. 이렇게 일련의 동적변환을 거친 최종의 주소를 우리가 Physical Address라고 함

논리 주소(Logical Address): 프로그램에 의해 CPU가 바로 생성하는 주소

물리 주소(Physical Address): 일련의 변환을 거친 최종 메인 메모리 주소

이와 같이 논리주소를 물리주소로 변화시켜주고 Protection을 체크해주는 이 부분을

MMU (Memory Management Unit) 이라고 부름

이것은 과거 60년대 시절의 굉장히 초보적인 형태의 MMU이지만 지금도 조금 복잡하지만 유사한 형태의 MMU이 컴퓨터 시스템에서 많이 사용이 되고 있습니다.

앞으로 종종 어떤 메커니즘을 설명하고 이 메커니즘이 하드웨어 메커니즘인지 아니면 소프트웨어 메커니즘인지 질문을 할 것임

여러분이 생각하기에 이 논리주소를 물리주소로 변환시키는 MMU 메커니즘은 하드웨어로 구현하는 것이 타당하겠는가? 소프트웨어로 구현하는 것이 타당하겠는가?

Q. MMU는 하드웨어와 소프트웨어중 어떤 것으로 구현하는 것이 타당한가?

A. 하드웨어로 구현되는 것이 타당하다. 소프트웨어로 구현될 경우 성능

    저하 문제와 주소 변환을 위해 다시 주소 변환이 필요해지는 문제가 발생한다.

이 MMU를 소프트웨어적으로 구현하면 2가지 문제가 발생함

1. 성능의 문제: instruction이 한번 수행이 되려면 최소한 1번 많게는 2~3번의 메모리 주소가 발생하게 됨

   instruction 한개를 수행시키기 위해서 10개 이상의 다른 instruction. 

   소프트웨어로 구현이 됐다는 말은 instruction들의 sequence로 구현이 되는 거잖아요.

   10개 이상의 다른 instruction을 수행시킨다면 시스템의 성능이 엄청나게 나빠짐

2. MMU 역시 instruction으로 구성이 됨. 

    MMU 주소 역시 또, 이런 매핑과정을 transration 과정을 거쳐야 겠죠?

    그러면 자기코드를 또 생성, 또 활용을 해야 됩니다.

    재귀적인 계속 반복적으로 호출되는 문제가 생김

Q. MMU가 과거에 없던 하드웨어로써 등장을 했음. 그렇다면 Operation System의 관점에서 볼 때는 이 MMU에 대해서 주목을 해야 될 것 같은가? 주목을 하지 않아도 될 것 같은가? (영어로 표현하면 Transparent 한가?) Operating 관점에서 MMU라는 하드웨어가 도입이 됐다면 어떤일을 해줘야 할 것 같은가?

A. MMU의 등장은 Operation System에게 Transparent 하지 않음. 

    왜냐하면 한 job이 수행되다가 다른 job으로 넘어가게 되면 그 새로운 job에 base register값을 operate system에 셋팅해줘야 된다. 

    또 protection을 위해서 bound register의 값도 세트를 해야되는 그런 문제가 생기게 됨.

    그래서 MMU는 Operating System에 의해서 programmable한 entity가 된다.

Q. 이 base register와 bound register를 programming을 하는 기능을 operating system에게만 줘야 될 것 같은가? 일반 job들에게 줘도 상관 없을 것 같은가?

A. 이것은 operating system에게만 고유한 권한으로 수행할 수 있게 해야한다.

    왜냐하면 다른 job들이 이 MMU에 있는 register를 마음대로 바꿔 쓸 수 있다면 Relocation이나 Protection을 자기가 임의로 침범할 수 있는 문제가 생김

    이와같이 operating system만 access할 수 있는 그런 기능들을 Privileged Instrucrtion이라고 한다.

    다음 시간에 좀더 자세히 배울 예정

Multiprogramming으로 등장한 문제 #3: Concurrent Programming

여러 Job들이 동시에 수행되면 공유 자원이나 공유 데이터에 동시에 접근함으로써 생기는 문제를 해결할 필요성이 대두됨

이 부분은 나중에 synchronization 부분에서 굉장히 자세하게 공부할 예정. 그때 설명하겠음.

Phase2

1960년대 후반

하드웨어가 점차 발전하기 시작. 이 시기에 어떤 하드웨어가 innovation 영향을 줬냐하면?

트랜지스터가 발명됨. 직접회로 기술이 발전하게 됨. 

(컴퓨터 시스템이 점점 작아지고 값 싸지고 무어의법칙에 따라 성능은 좋아지고 값은 싸짐)

그거에 비해 사람들의 인건비는 점점 올라가기 시작

Operating System의 역할이 조금 변화하기 시작했음

과거에는 비싼 진공관 CPU가 Idle하지 않게 하는 것이 목표였었는데

이제는 어떻게 하면 사람들의 생산성을 향상시킬 수 있을까? 이것이 목표가 됨

multiprogrammed batch monitor 시절의 컴퓨터 센터를 생각해 봅시다.

사용자는 여전히 펀치카드로 펀칭을 해서 카드덱을 만들어 그 카드덱을 Operator한테 제공해 주면

Operator가 그것을 batch로 만들어서 수행시킴.

그러면 Operator가 결과를 보내줄 때까지 사용자는 Idle 해짐

해결방법으로 컴퓨터(Terminal)를 개인별로 나눠주게 됨.

Terminal: 중앙의 컴퓨터와 연결되어 데이터를 입력하거나 출력할 수 있는 하드웨어 장치

가장보편적인 터미널 DEC VT-100

수 많은 터미널은 묶여서 TCU(Terminal Control Unit) 중계장치를 통해 전산센터에 있는 Server 컴퓨터에 연결됨.

실제로 프로그래머들에게 컴퓨터 한대씩 주지는 못했지만 Terminal은 한 대씩 주게 됨.

그래서 이제 사용자는 interactive하게 컴퓨터를 사용하게 됨

컴퓨터 센터(Operating System)의 관점에서 볼 때 문제가 있음.

CPU는 한 대가 있는데 Terminal에 여러명의 User들이 존재하고 있음.

그렇다면 어떻게 여러명의 User들에게 하나의 CPU를 제공해 주면서 그것을 또 interactive하게 보이게 할 수 있을까? 고민이 생기게 됨.

하나밖에 없는 CPU를 그리고 그 CPU의 시간을 여러 유저들에게 쪼개서 나눠주는 것

이것이 Phase2 Operation System 시기에 가장 큰 특징임.

그리고 이러한 시스템을 Time-sharing OS 이라고 함

Time-sharing을 통해 interactive하게 되었음

컴퓨터와 프로그래머가 서로 대화를 하기 시작함

interactive Time-sharing OS를 사용하는 사람들이 착각을 하기 시작했음.

컴퓨터 센터에 있는 서버를 자기 혼자 소유하고 있다는 생각을 들게 함 (Private하게 느낌)

그래서 private한 개인정보들을 컴퓨터 시스템에 저장을 하기 시작함.

사용자의 요구를 만족시키기 위해서 파일시스템을 다시 설계하기 시작함

사용자 별로 어떤 파일의 소속을 규정할 수 있고 특정파일에 접근 가능한 사용자들을 제한 할 수 있는 시스템이 추가되기 시작

컴퓨터 시스템이나 OS을 평가하는 Metric들이 변화하기 시작함

사람들의 사용감 (Response Time = 내가 커맨드를 쳤을 때 얼마나 빨리 빨리 답장이 오는가)

아니면 private한 파일이 얼마나 잘 보호되고 있는가? 이러한 특징들이 나타남

---

출처 - http://snui.snu.ac.kr/ocw/index.php?mode=view&id=623

출처 - http://snui.snu.ac.kr/ocw/index.php?mode=view&id=625

출처 - http://snui.snu.ac.kr/ocw/index.php?mode=view&id=626#class_room-tab