운영체제 공룡책 : Ch2. Operating System Structures | 운영체제 구조

📌 들어가며

운영체제를 살펴보기 위한 몇가지 관점이 있다.

1. 운영체제가 제공하는 서비스에 초점을 맞춘다.

2. 운영체제가 사용자와 프로그래머에게 제공하는 인터페이스에 초점을 맞춘다.

3. 시스템의 구성요소와 그들의 상호 연결에 초점을 맞춘다.

 

이 세가지 측면을 기준으로 사용자, 프로그래머, 운영체제 설계자의 관점에서 모두 살펴보자. 

 

---

📚 2.1 운영체제 서비스

운영체제는 프로그램 실행 환경을 제공한다. 즉, 프로그램과 그 프로그램의 사용자에게 특정 서비스를 제공한다.

이러한 서비스는 프로그래머가 프로그래밍 작업을 더 쉽게 수행할 수 있도록 한다.

 

 

[ 사용자에게 도움을 주는 것을 목적으로 하는 서비스 ]

 

✔️ 사용자 인터페이스(user interface) 

   * 거의 모든 OS가 제공하며, 여러 형태로 제공될 수 있지만 일반적으로 그래픽 사용자 인터페이스(GUI)가 사용된다.

   * 여기서 인터페이스는 윈도우 시스템으로, 마우스와 키보드를 가지고 있다.

   * 휴대전화 및 태블릿과 같은 모바일 시스템은 터치 스크린 인터페이스를 제공한다

   * 명령어 라인 인터페이스(CLI) (명령 사용, 명령 입력할 키보드 사용)도 제공한다.

 

✔️ 프로그램 수행(program execution)

   * 시스템은 프로그램을 메모리에 적재해 실행할 수 있어야 하며, 정상이든 비정상이든 실행을 끝낼 수 있어야 한다.

 

✔️ 입출력 연산(I/O operation)

   * 수행 중인 프로그램은 입출력을 요구할 수 있고, 이러한 입출력에는 파일이나 입출력 장치가 연관될 수 있다.

   * 효율과 보호를 위해, 사용자들은 통상 입출력 장치를 직접 제어할 수 없기에 운영체제가 입출력 수행의 수단을 제공해야 한다.

 

✔️ 파일 시스템 조작(file system manipulation)

   * 프로그램은 파일을 여러 방법으로 조작할 필요가 있다.

   * 많은 운영체제들은 개인의 선택에 따라 혹은 특정 특성과 성능 특성을 제공하기 위해 다양한 파일 시스템을 제공한다.

 

✔️ 통신(communication)

   * 한 프로세스가 다른 프로세스와 정보를 교환해야 할 필요가 있는 여러 상황에, 통신을 수행하는 두가지 방법이 있다.

   * 동일한 컴퓨터에서 수행되고 있는 프로세스들 사이에서 일어나는 통신은 공유 메모리를 통해 구현된다.

   * 네트워크에 의해 함께 묶여있는 서로 다른 컴퓨터 시스템상에서 수행되는 프로세스들 사이에서 일어나는 통신은 메시지 전달 기법을 사용하여 구현될 수 있는데, 이 경우 정보의 패킷들이 운영체제에 의해 프로세스들 사이를 이동한다.

 

✔️ 오류 탐지(error detection)

   * 운영체제는 모든 가능한 오류를 항상 의식하고 있어야 하며, 올바르고 일관성 있는 계산을 보장하기 위해 각 유형의 오류에 대해 적당한 조처를 해야 한다.

 

 

[ 시스템 자체의 효율적인 동작을 보장하기 위한 서비스 ]

 

✔️ 자원할당(resource allocation)

   * 다수의 프로세스나 다수의 작업이 동시에 진행될 때는 그들 각각에 자원을 할당해주어야 한다.

 

✔️ 기록 작성(logging)

   * 어떤 프로그램이 어떤 종류의 컴퓨터 자원을 얼마나 많이 사용하는지를 추적한다.

   * 이러한 기록 관리는 컴퓨팅 서비스를 개선하기 위해 시스템을 재구성하고자 하는 시스템 관리자에게 귀중한 자료이다.

 

✔️ 보호(protection)와 보안(security)

   * 서로 다른 여러 프로세스가 병행하게 수행될 때, 한 프로세스가 다른 프로세스나 운영체제 자체를 방해해서는 안된다.

   * 보호는 시스템 자원에 대한 모든 접근이 통제되도록 보장하는 것을 필요로 하며, 각 사용자가 자원에 대한 접근을 원할 때 통상 패스워드를 사용해서 시스템에게 자기 자신을 인증하는 것으로부터 시작된다.

   * 보안은 네트워크 어댑터 등과 같은 외부 입출력 장치들을 부적합한 접근 시도로부터 지키고, 침입의 탐지를 위해 모든 접속을 기록하는 것으로 범위를 넓힌다.

 

---

📚 2.2 사용자와 운영체제 인터페이스

사용자가 OS와 인터페이스하기 위해 사용하는 세 가지 방법에 대해 조금 더 자세하게 알아보자.

2.2.1 명령 인터프리터 Command-Interpreter

먼저, 명령 인터프리터이다. shell으로 유명하다.

말그대로 ls와 같은 명령어를 이용하여 인터페이스 한다. (인터페이스: 두개의 시스템이 서로 상호작용)

 

명령 인터프리터의 주요한 역할은 사용자가 특정한 다음 명령어를 받아서 실행시키는 것이다.

 

이를 위해 명령 인터프리터는 그자체로 명령어를 실행시킬 코드를 가지고 있다. 예를 들어, 파일을 지우라는 명령어는 명령 인터프리터가 그에 맞는 적절한 시스템 콜을 호출하는 코드의 부분으로 점프하도록 한다.

 

혹은 명령 인터프리터가 명령어를 이해하지 못할 경우, 해당 명령어의 파일을 식별하여 메모리에 로드받고 실행하도록 한다. 예를 들어, "rm file.txt"라는 명령어를 입력했을 경우, rm이라는 파일을 찾아서, 메모리에 로드하고, file.txt.라는 파라미터와 함께 실행시킨다. 이 방식은 프로그래머가 새로운 명렁어를 시스템에 쉽게 추가할수 있다는 장점이 있다.

 

2.2.2 그래픽 사용자 인터페이스 Graphical User Interface

GUI라고도 알려진 그래픽 사용자 인터페이스이다.

사용자에게 친숙한 방식으로, 마우스를 움직여 데스크탑 화면 속의 이미지나 아이콘을 가리킬 수 있으며 마우스를 클릭함으로써 프로그램을 실행시키거나 파일 혹은 디렉토리를 선택할 수 있다.

 

2.2.3 터치 스크린 인터페이스 Touch-Screen Interface

스마트폰인 태블릿 같은 모바일 시스템에서는 명령 인터페이스나 마우스와 키보드를 이용하는 그래픽 사용자 인터페이스 방식이 실용적이지 않기에, 터치 시크린 인터페이스를 주로 사용한다.

우리가 평소에 하듯, 손가락을 움직여 터치 스크린을 누르거나 밀어서 사용할 수 있다.

 

---

📚 2.3 System Calls

시스템콜은 컴퓨터 응용프로그램과 운영체제를 연결시키는 역할을 한다.

아까 언급했던 운영체제가 제공하는 서비스들은 시스템콜을 통해 호출할 수 있다.

 

2.3.2 응용 프로그래밍 인터페이스 Application Programming Interface

위의 그림에서 볼 수 있듯이, 간단한 프로그램이라도 많은 시스템콜이 사용된다. 즉, 운영체제를 많이많이 사용해야 한다.

보통 대부분의 프로그래머는 이 정도의 세부사항을 볼 일이 없지만, 응용 프로그램 개발자들은 API(application programming interface)에 따라 프로그램을 개발한다. 여기서 API란 무엇일까?

 

API는 각 함수에 전달되는 파라미터들과 리턴값을 포함하여 응용 프로그램 개발자가 사용할 수 있는 함수 집합을 담고 있다. 운영체제의 API가 시스템콜들이라고 이해하면 좋다.

 

그럼 API는 어떻게 생겼을까?

만약 사용자가 "man read"라는 명령어를 입력하여 read() 함수의 API를 얻어보자. 아래와 같이 나타나 있을 것이다.

 

대부분의 프로그래머는 API를 통해 시스템콜을 호출하며,

API 사용자는 각 함수가 어떻게 생겼는지, 어떤 방식으로 돌아가는지 몰라도 된다. 그저 API를 준수하고 호출 결과로서 운영체제가 무엇을 할 지만 판단하면 된다.

 

+ 왜 직접 호출하지 않고 API를 사용할까?

1. 편의성을 위해 - 직접 호출하는 것은 매우 힘들다. 하지만 불확실성을 제거하기 위해 직접적으로 사용하기도 한다.

2. 휴대성을 위해 - 어디서든 적용할 수 있다.

 

그럼 사용자 응용 프로그램에서 시스템콜을 호출하면 어떻게 처리될까?

시스템콜 인터페이스는 시스템콜에 대한 링크 역할을 한다. 위의 그림에서는 open() 함수를 통해 운영체제가 필요한 시스템콜을 호출한다. 일반적으로 번호는 각 시스템콜과 연결되어 있으며, 시스템콜 인터페이스가 번호들에 따라 인덱싱된 테이블(시스템콜 테이블)을 유지한다.

 

2.3.3 시스템콜의 유형 Types of System Calls

시스템콜은 대략 6개의 카테고리로 나눌 수 있다.

 

• 프로세스 제어 process control
  • 끝내기 end, 중지 abort
    • 실행 중인 프로그램은 수행을 정상적으로나 비정상적으로 종료(에러를 반환)할 수 있어야 한다.
  • 적재 load, 수행 execute
    • 한 프로그램을 실행하고 있는 프로세스나 작업이 다른 프로그램을 로드하고 실행하기를 원할 수 있다.
    • 로드된 프로그램이 종료되었을 때, 어디로 control을 반환해야 하는가에 대한 질문이 생길 수 있다.
    • 만약 control이 기존 프로그램으로 돌아간다면, 기존 프로그램의 memory image를 저장해두어야 한다.
    • 만약 두 프로그램이 병행하게 수행된다면, multi-programming 될 새로운 작업이나 프로세스를 생성한다.
  • 프로세스 생성, 프로세스 종료
    • 새로운 작업이나 프로세스을 생성한다면, 이들의 실행을 제어할 수 있어야 한다.
  • 프로세스 속성 획득, 속성 결정
    • 작업의 우선순위, 최대 할당가능한 실행시간 등을 포함하여 속성을 결정할 수 있어야 한다.
  • 시간 기다리기 wait for time
    • 새로운 작업이나 프로세스를 생성한 후에는 이들의 실행이 끝나기를 기다릴 필요가 있을 수 있다.
  • 이벤트
    • wait event : 특정 사건이 일어날 때까지 기다릴 수 있어야 한다.
    • signal event : 그 사건이 일어나면 신호를 보낼 수 있어야 한다.
  • 할당과 free 메모리 allocate and free memory
    • 둘 이상의 프로세스들이 공유하는 데이터들에 대해 일관성을 보장해야 할 필요성이 있을 수 있다.
    • 이에 운영체제는 종종 프로세스가 공유 데이터를 lock 할 수 있는 시스템콜을 제공한다.
• 파일 조작 file management
  • 생성 create, 삭제 delete
  • 열기 open, 닫기 close
  • 읽기 read, 쓰기 write, 위치 변경 reposition
    • 위치 변경의 예) 파일 끝으로 건너뛰기
  • 속성 획득 및 결정 get file attributes, set file attributes
    • 파일 속성에 대한 정보를 얻을 수 있고, 변경할 수 있다.
• 장치 조작 device management
  • 프로세스는 작업을 계속 수행하기 위해 메인 메모리나 디스크 드라이브 등의 추가 자원을 필요로 할 수 있다.
  • 장치를 요구 request devices, 장치 방출 release devices
    • 다수의 사용자가 동시에 사용하는 시스템은 독점적인 디바이스 사용을 보장받기 위해 request 해야 한다.
    • 디바이스 사용이 끝나면 반드시 release 해야 한다.
  • 읽기 read, 쓰기 write, 위치 변경 reposition
    • 일단 디바이스를 request하여 할당되면, 해당 디바이스를 읽고, 쓰고, 위치 변경 할 수 있다.
    • I/O 장치와 파일들 간에는 유사성이 많기 때문에, UNIX를 포함한 많은 운영체제가 이들 둘을 통합한 파일-장치 구조 file-device structure로 결합했다.
    • 장치 속성 획득 및 결정 get device attributes, set device attributes
    • 장치의 논리적 부착 또는 분리 logically attach or detach devices
• 정보 유지보수 information maintenance
  • 시간과 날짜의 설정과 획득 get/set time or date
  • 시스템 데이터의 설정과 획득 get/set system data
  • 프로세스, 파일, 장치 속성의 획득 get process, file, or device attributes
  • 프로세스, 파일, 장치 속성의 설정 set process, file, or device attributes
• 통신 communications
  • Messaging Passing Model
    • 통신하는 두 프로세스가 정보를 교환하기 위해 서로 메시지를 주고받는다.
    • 메시지는 두 프로세스 사이에서 직접 교환되거나, 메일박스를 통해 간접적으로 교환될 수 있다.
    • 충돌이 없기 때문에 소량의 데이터를 교환하는데 좋다.
  • Shared Memory Model
    • 프로세스는 다른 프로세스가 소유한 메모리 영역에 대해 접근하기 위해 시스템콜을 사용한다.
    • 정상적으로, 운영체제는 한 프로세스가 다른 프로세스의 메모리를 접근하는 것을 막으려고 한다.
    • 이에, Shared Memory Model에서는 이런 제한을 제거해야 할 필요성이 있다.
    • 최대 속도와 편리한 통신을 할 수 있지만, 동기화에 대한 문제가 있다.
• 보호 protection
  • 과거에는 다수의 사용자를 가지는 다중 프로그램 시스템에서만 고려되는 문제였으나, 네트워킹과 인터넷의 출현으로, 서버에서 휴대용 컴퓨터까지 모든 컴퓨터 시스템에서 고려해야 한다.

 

---

📚 2.4  시스템 서비스 System Services

시스템 유틸리티 system utilities로도 알려져 있으며, 프로그램 개발과 실행을 위한 편리한 환경을 제공한다.

다음과 같은 카테고리로 분류할 수 있다.

• 파일 관리 file management
• 상태 정보 status information
• 파일 변경 file modificatio
• 프로그래밍 언어 지원 programming-language support
• 프로그램 적재와 수행 program loading and execution
• 통신 communications
• 백그라운드 서비 background services

대부분의 운영체제는 시스템 서비스와 함께 일반적인 문제점을 해결하거나, 일반적인 연산을 수행하는데 유용한 프로그램을 제공한다.

 

---

📚 2.5 링커와 로더 Linkers and Loaders

 

보통 프로그램은 바이너리 실행 파일로 디스크에 존재하는데, CPU에서 실행하기 위해서는 메모리로 가져와서 프로세스의 문맥에 놓아야 한다. 이 과정을 위의 그림으로 나타내었다. 

 

우선, source program은 컴파일러 compiler를 통해 object file로 변환된다.

그럼 링커 linker가 object file과 다른 object file들을 결합하여 하나의 실행 가능한 이진 파일로 만든다.

로더 loader는 이진 실행 파일 binary executable file을 메모리로 불러와 프로그램을 실행시킬 수 있다.

 

dynamically linked libraries(DLLs)를 통해 같은 라이브러리를 사용하는 파일들이 불러온 라이브러리를 공유하여 사용할 수 있다. 예를 들어, 윈도우는 DLLs를 지원하여 실행 파일로 사용되지 않을 수 있는 라이브러리들을 링크하거나 로드하는 것을 막는다. (뒷단원에서 자세히 다룰 예정)

 

---

📚 2.7 운영체제 설계과 구현 Operating-System Design and Implementation

운영체제를 설계하고 구현하는 것에는 정답이 없지만 성공적으로 입증된 접근법에 대해 살펴보자.

 

2.7.1 설계 목표 design goals

설계 시 고려해야 할 요구사항은 사용자 목적과 시스템 목적으로 구분지을 수 있다.

사용자 입장에서 시스템은 사용하기 편리해야 하고, 배우기 쉬워야 하며, 신뢰성 있고, 안전하고, 빨라야한다.

(convenient to use, easy to learn and use, reliable, safe, fast)

시스템 입장에서 운영체제는 설계, 구현, 유지 보수가 쉬워야 하며, 적응성, 신뢰성, 효율성 등을 가져야 한다.

(easy to design, implement, and maintain, flexible, reliable, error free, efficient)

 

2.7.2 기법과 정책 mechanisms and policies

기법 mechanism은 어떻게 할 것인가(how to do something)을 결정하는 것이다.

정책 policies는 무엇을 할 것인가(what will be done)를 결정하는 것이다.

예를 들어, timer mechanism과 scheduing policy는 정책이고 30일마다 비밀번호를 만료시키는 것은 기법이다.

 

기법과 정책의 분리는 flexibility을 위해 중요하다.

정책은 언제 어디서나 변경될 수 있기에, 기법과 정책을 분리하지 않을 경우에는 기법을 바꿔야 할 수도 있고 이것은 바람직하지 않다.

 

2.7.3 구현 implementation

초창기 운영체제는 어셈블리어로 구현되었으며, 현재 대부분의 운영체제는 C나 C++과 같은 고급언어로 구현되어 있다.

 

고급언어로 구현할 경우의 장점은 다음과 같다.

• 더 빨라진 실행 시간 faster implementation time
• 줄어든 코드 라인 수 compact and easier to understand/debug
• 컴파일러의 발전으로 커널 코드 자체는 더 개선된 형태 improved compiler will improve the generated code
• 다른 환경으로 코드를 변경하기 쉬워짐 easier to port

 

고급언어로 구현할 경우의 단점은 다음과 같다.

• (세부적으로 컨트롤하기 어려워져서) 속도가 느려지고 저장 장치가 많이 소요된다.
• 하지만 좋은 자료구조와 알고리즘을 사용함으로써 위의 문제를 해결할 수 있다.

 

---

📚 2.8 운영체제 구조 Operating-System Structure

2.8.1 모놀리틱 구조 Monolithic Structure

Monolithic 구조에서는 system call interface와 kernel interface 사이의 모든 것이 kernel이다.

수많은 기능들이 한 덩어리에 들어가 있기에 시스템 한 부분의 변화가 다른 부분들에 영향을 줄 수 있어서 구현하거나 유지 보수하기 어렵다는 단점이 있다.

하지만 성능 측면에서 시스템콜 인터페이스에서 통신하는 경우 오버헤드가 거의 없고 커널 내의 통신 속도가 빠르다는 장점이 있다. 이러한 장점 때문에 Linux, Windows는 여전히 이 구조를 사용하고 있다.'

 

2.8.2 계층적 구조 Layered Approach

계층적 구조는 운영체제를 세분화해 계층을 분리한 방식이다.

layer가 0인 가장 아래에 있는 계층은 하드웨어이며, layer가 N인 가장 위에 있는 계층은 사용자 인터페이스이다.

임의의 m층은 자신보다 아래에 있는 하위층들의 서비스들만 사용할 수 있다.

 

문제가 생겼을 경우 계층별로 수정할 수 있기에 유지 보수가 편리하다는 장점이 있다.

하지만 계층을 정의하기가 어렵고, 함수 호출  시 단계를 많이 거쳐야 하는 경우 비효율적일 수 있다는 단점이 있다.

 

2.8.3 마이크로커널 Microkernels

마이크로커널은 커널에서 핵심적인 요소만 남겨둔, 이른바 가벼운 커널이다.

커널이 커질수록 문제가 생길 가능성이 높아지고, 유지 보수가 힘들어지기 때문에 정말 필요한 최소 기능만을 남겨두어 커널을 더 가볍게 만들 필요가 있었다.

 

마이크로커널의 주요 기능은 다음과 같다.

• 프로세스간 통신 interprocess communication
• 메모리 관리 memory management
• CPU 스케줄링 CPU scheduling

마이크로커널의 장점은 다음과 같다.

• 모든 새로운 서비스는 사용자 공간에 추가되기 때문에 결과적으로 커널의 수정이 발생하지 않아서 운영체제를 확장하기 더 쉽다. highly extensible OS kernel
• 하나의 하드웨어 설계에서 다른 것으로 이식하기 쉽다. easy to port kernels
• 보안성, 안정성이 높다 more secure and reliable

마이크로커널의 단점은 다음과 같다.

• 늘어난 오버헤드 때문에 성능에 영향이 있을 수 있다. impact on performance

 

2.8.4 모듈 modules

이 방법에서 커널은 핵심적인 구성요소의 집합을 가지고 있고, 부팅 시에 또는 실행 중에 부가적인 서비스들을 모듈을 통해 연결한다. 설계 시 중요한 점은 핵심 서비스를 제공하고 다른 서비스들은 커널이 실행되는 동안 동적으로 구현하는 것이다.

 

전체적인 결과는 각 부분이 정의되고 보호된 인터페이스를 가진다는 점에서 계층적 구조와 비슷하지만 모듈에서 임의의 다른 모듈을 호출할 수 있다는 점에서 계층적 구조보다 유연하다고 할 수 있다.

 

2.8.5 하이브리드 시스템 hybrid systems

하나의 구조만 사용하는 운영체제는 거의 없다. 서로 다른 구조를 결합하여 사용한다.

예를 들어, Linux, Windows는 monolithic 구조를 사용하면서 module을 지원한다.

 

---

📚 2.9 운영체제 빌딩과 부팅 building and booting an operation system

2.9.1 운영체제 생성 operating-system generation

운영체제는 다양한 주변 구성을 가진, 여러 부류의 기계에서 수행되도록 설계되는 것이 일반적이다.

이 경우, 시스템은 각 specific computer site를 위해 구성되거나 또는 생성되어야 한다.

이 절차를 시스템 생성 SYSGEN이라고 한다.

 

2.9.2 시스템 부트 system boot

컴퓨터가 전원을 켜거나 재부팅 등의 사건을 받으면 명령 레지스터는 미리 지정된 메모리 위치를 가리키고, 그곳에서부터 실행을 시작한다. 해당 위치에는 최초의 bootstrap program이 존재한다. RAM은 시스템 시작 시에는 알 수 없는 상태가 되기 때문에 bootstrap program은 ROM 안에 저장된다.

 

bootstrap program은 먼저 기계의 상태를 진단하여 이상이 없는지 확인한다. 이후에 CPU Register, device controller, main memory 등 시스템 전반에 걸쳐 초기화한다. 이 작업이 끝나면, bootstrap program은 운영체제를 시작한다.

 

---

📚 2.10 운영체제 디버깅 operation-system debugging

디버깅은 하드웨어와 소프트웨어에서의 시스템 오류를 발견하고 수정하는 것을 말한다.

 

2.10.1 장애 분석 failure analysis

➡️ 프로세스가 실패했을 때, 운영체제는 프로세스가 사용하던 메모리를 캡처한 뒤 'core dump'를 취하고 이후의 분석을 파일로 저장한다.

➡️ 커널 장애는 crash라고 불린다. 해당 오류 정보는 로그 파일로 저장되고, 메모리의 상태가 'crash dump'에 저장된다.

 

2.10.2 성능 모니터링과 조정 performance monitoring and tuning

병목 지점 bottlenecks을 제거함으로써 성능을 향상시키려고 하는 것도 디버깅이라고 할 수 있다.

이에 병목 지점을 발견하기 위해 시스템 성능을 감시할 수 있어야 하며, 시스템 동작을 측정하고 표시할 수 있는 방법을 가지고 있어야 한다. (ex. 윈도우 작업 관리자)

 

2.10.3 추적 tracing

추적 도구는 시스템콜 호출 과정과 같은 구체적인 이벤트에 대한 정보를 모은다. 이러한 정보는 운영체제를 더 나은 방향으로 개선할 수 있도록 한다.