운영체제 3 || OS의 구조를 어떻게 디자인 할 수 있을까?

오늘은 OS의 발전과정에 대해 배워볼거야. 

 

먼저 결론부터 얘기하자면, OS를 설계하는데 있어서 절대적인 진리는 없어. 다만 성공적인 접근 방법이 존재할 뿐이야.

 

자, OS를 디자인하기 위해서는 제일 처음, 사용자의 입장과 시스템의 입장에서 목적과 특징을 정해야해.

 

당연히 사용자의 입장에서는 사용하기 편하고, 배우기 쉽고, 신뢰성있고, 안전하고 빠르게 작동하는게 좋을거야

시스템의 입장에서는, 설계하기 간편해야하고, 유지 보수하기도 편해야하고, 유연성이있어야하고, 에러에 있어서 좀 자유로워야 해. 

 

이런 각각의 목적들을 가지고 설계를 하는거지

 

그러니까, OS를 설계 할 때, 중요한 포인트는 뭐냐면, Policy와 Mechanism을 잘 나누는 거야 

 

Policy는 OS가 무엇을 할 건지에 관한거야

Mechanism은 Policy를 위해서 무엇을 할 건지에 관한거지. 

Policy를 Mechanism이 뒷받침한다고 생각하면 편해

 

OS가 어떤 정책을 채용하냐에 따라서 당연히 그에 따른 매커니즘도 달라지겠지?

여기서 조금 문제가 발생해. Policy는 막 환경에 따라 바뀔수도 있단말이지.

Policy가 A에서 B로 바뀌었으면 이를 뒷받침하는 Mechanism도 B로 바뀌어야 해. 유지보수가 상당히 힘들겠지?

그래서, 매커니즘을 얼마나 제너럴하게 만드냐에 따라 유지 보수의 수고를 덜어주는거야

 

 

이렇게 Policy와 Mechanism을 나누어서 설계하게 되면, OS를 모듈화 해서 만들 수 있는게 큰 장점이 될 수 있어, 모듈화의 장점은 확장성 있는 시스템을 만들기도 좋고, 유지보수하기도 좋은거지

 

자 이렇게 OS를 설계를 했으면 이제 개발자들이 구현을 해야하겠지?

 

 지금은 C/C++도 사용하고 있지만, 초기 OS는 Assembly언어로만 이루어져 있었어 최근에는 한 종류의 언어만을 사용하는게 아니고, 여러 언어를 섞어서 OS의 기능마다 적합한 언어를 채용하는 형태야.

 

 

1. Simple Structure

제일 처음 나온 구조는 그냥 단순한 구조야. MS-DOS가 이러한 형태인데

 

이 구조는, 영역들이 잘 구분되어 있지 않았어. 잘 보면 application의 화살표가 H/W로 바고 접근이 가능하게 화살표가 그려져 있지? 이는 보안에 되게 취약한 형태야, 또한 한번에 하나의 app만 실행이 가능해서 되게 불편한거지

그래서 이런점을 좀 보완하기 위한 형태가 나왔는데, 그게 바로 Layered Approach야

 

2. Layered Approach

 이름에서 힌트가 있는데, 레이어화 되어 있는 구조야

OS의 기능별로 여러개의 계층을 두고, 각 계층은 그 계층에서의 일만 할 수 있도록 한 뒤, 계층 사이의 접근은 시스템 콜의 형태로 접근하게 해 두었어. 제일 위 계층은 유저쪽 계층이고 제일 아래쪽 계층은 H/W쪽 계층인거지.

상당히 괜찮아 보이는 모델이야. 근데 문제가 있어, 계층이 많아지다보니까, 성능적으로 문제가있지. 계층 사이를 계속해서 전달해야하다 보니, 속도가 너무 느린거야 이런 문제를 또 해결하기 위해서 나온게 Monolithic 구조야.

 

3. Tranditional UNIX System Structure (Monolithic)

이 구조는, layered계층의 성능 문제를 해결하긴 했어. 이게 커널 부분을 크고 거대한 하나의 코드블럭으로 설계를 해 놓은거야  엄청나게 많은 OS의 기능이 한개의 레벨에 있는 형태인거지. 이거 좀 바로 문제가 보이지 않아?

여기에 한 부분에 오류가 생긴다고 가정하면, 그 부분과 연관되어 있는 모든 부분에서 오류가 생겨, 유지보수가 너무 힘든거야. 성능적으로는 매우 우수하지만, OS의 기능이 하나의 코드 덩어리로 되어 있기 때문에, 기능 사이에 상호 의존도가 높아서 유지보수가 힘들다는 단점이 있어.

 

이 단점을 또 해결하기 위해 나온게 바로

 

4. Microkernel 형태야.

위의 Monolithic 구조에서는 유지보수와 안전성에 좀 단점이 있었어. 

그래서 OS의 많은 기능들을 user 영역으로 올려버렸어. 대부분의 기능들은 프로세스로 동작하고, kernel영역에는 OS의 최소한의 기능만을 두는 형태야

그림을 보면 apps가 File System이나 Device Driver에 접근하기 위해서는 OS를 통해 접근을 해야했는데, 이를 Massage passing이라고 해. 이런식으로 새로운 프로세스를 올릴 수도 있는거지.  장점으로는 모듈화는 쉬워, 확장성도 당연히 좋을거고 새로운 프로세스를 올려버리면 되니까. 호환성도 좋을거야. 

하지만. OS의 기능을 이용하기 위해서는 Massge passing을 해야하기 때문에, 커뮤니케이션의 오버헤드가 발생하는거지

또 이런 문제를 해결하기 위해서 Modules 의 형태로 발전했어

 

5. Modules

간략하게 보면, OS의 기능을 프로세스가 아닌 코드블럭으로 가지고 있다가 필요할 때 마다 로드하는 구조야

객체지향의 관점과 상당히 유사하지?

이렇게 되면 Massage Passing이 필요가 없을테니, Monolithic과 비슷한 성능을 가지면서, 확장성도 좋고, 모듈화가 되어있으니 유지보수도 편해. 단순하게 시스템 콜을 통해서 OS의 기능을 사용하기만 하면 되니까.

 

 

자 이렇게 많은 과정을 발전시켜왔는데, 그럼 현대 OS는 어떤 구조를 채택했을까??

 

답은 여러개의 OS의 구조를 채택하고, 각각의 장점만을 취합한 형태야

 

Windows는 대부분 monolitic구조이지만, microkernel의 구조도 조금 붙어 있어

 

Mac Os는 마이크로 커널 구조이지만 일부는 또 레이어드 형태로 되어있지

 

최근의 OS들은 이렇게 여러개의 구조를 채택해서 hybrid형식으로 되어있어.