|
Go back OS Review Device Driver NS Tools Home Papers Daily Link To Main |
1. 오에스란? (What is an Operating System?)
오에스야, 넌 도데체 모니,,, 컴퓨터 시스템을 나눌때는 크게 네부분으로 나눈답니다. 먼저 하드웨어, 오에스, 어플리케이션 프로그램, 그리고 여러분인 유저이죠. 이중 오에스를 몇마디 단어로 정의한것은 책의 어디를 봐도 찾을수 없을겁니다. 단지, 몇가지 키워드들을 나열해보자면, "오에스는 정부(-_-+)와도 같다". "오에스는 리소스 분배자이다". "오에스는 컨트롤 프로그램이다". 등등,,,뭐 이런 그럴듯한 비유들만이 있을뿐이죠. 모두 다 맞는 말입니다. 그러나 오에스의 목적은 단 한가지로 압축될수 있습니다. 바로 "유저들이 쓰기 쉽고 컴퓨터 시스템을 효율적으로 이용하도록 만든다" 가 되겄습니다. 그렇기에 유저인터페이스는 오에스의 아주 중요한 요소가 될수 밖엔 없겠죠? 그런데 여기서 우리는 재미있는 사실 한가지를 주지할 필요가 있을듯한데, 유저인터페이스가 너무 사용자 위주가 되어버리면 시스템의 효율은 저하될테고 (많은 그래픽적인 리소스의 난무 및 이벤트(인터럽트)의 발생은 씨피유를 정신 못차리게 할겁니다) 그렇다고 유닉스 쉘과 같이 시스템의 효율만을 고려한다면 유저들이 쓰기가 너무 어려워져버리는 마치 양날의 칼과같은 경우라 할수 있을듯합니다. 오에스의 발전은 보면 전형적인 heurestic approch를 따른다고 개인적으로 생각이 되는데요, 그 말이 뭔말이냐,,,먼저 어떤 쌈빡한 이론을 제시해놓고 거기에 논리적으로 맞추어서 시스템을 완성하기 보다는, 먼저 대충 돌아가는것을 지켜보며 점진적으로 아, 여기를 요렇게, 저기를 저렇게 해야겄군,,,과도 같은 방법론을 따른다는 뜻이죠. 나중에 시간이 된다면 인터페이스를 디자인할때 휴레스틱 어프로치는 어떻게 이루어지는지를 다루어보도록 하죠. 태초에 컴이 생기면서 오에스 다운 오에스로써는 바로 심플 또는 멀티프로그래밍이 가능한 배치(batch)시스템이 있었습니다. 배치시스템의 가장 큰 특징은 유저와의 상호작용(interaction)이 개입될 여지가 전혀 없는 시스템이라는 사실입니다. 순차적으로 a->b->c->d식의 a에서 d를 얻는데 사용되는 시스템이죠. 이중 멀티프로그래밍 배치시스템은 그 유명한 스풀링(Simulaneous Peripheral Operation On-Line)의 힘을 빌린것인데, 스풀링이란 좀더 명확하게 설명하자면, 프린터와 같은 아웃풋 디바이스들의 속도는 씨피유에 비해서 정말 느리잖애요. 요즘에서 조차 도큐먼트 백장 램에 띄우는건 순간이지만, 그걸 프린트아웃하려면,,,우우 악몽이죠. 그렇기에 일종의 동기화를 시켜주는 완충장치(buffer)로써 스풀링이란 개념이 사용됩니다. 단, 보통의 버퍼와 다른점은 바로 주변기기들과의 I/O전용으로 사용된다는 점이죠. 먼저 처리되어버린 아웃풋이나 처리해야하는데 병목현상으로 대기하고 있는 인풋들을 거대한 디스크와 같은 공간에 싸그리 담아버림으로써 데이터가 증발하지 않도록 하는것이죠. 배치시스템의 처리단위는 통상 잡(job)이었죠. 잡이란 프로그램, 데이타, 그리고 몇가지 제어정보를 지닌 일련의 카드들이라고 여기서는 생각하면 되요. 나중에 또 다른의미로 사용될때 다시 언급하기로 하고,,,하여간, 이러한 잡들의 수행을 좀더 빠르게 하기 위하여 비슷한 잡들끼리 통채로 묶어서 그룹으로 컴퓨터에서 수행시켜주되 잡풀이라는 스풀에 담아서 한정된 메모리안에 올렸다 내렸다 거리면서 수행해주는 형태의 시스템이 바로 멀티프로그래밍 배치 시스템입니다. 배치프로그램의 특성상 언제나 순차적으로 코드가 수행되어야 하는 한계가 있었음에도 불구하고, 여기서 정말 중요한 몇가지 오에스론의 주제가 등장합니다. 먼저, 어떤잡을 먼저 올리고 언제 내릴것인가를 결정한는 잡스케줄링(롱텀스케줄링)은 나중에 씨피유스케줄링(숏텀스케줄링)으로 연구가 진행되고, 수행을 위해 한정된 주메모리에 올렸다 내렸다 한다는 사실에서 그 유명한 메모리 스케줄링이 등장하죠. 또한 스풀은 통상 하드디스크로 발전하며, 그 속도와 효율성을 또한 디스크 스케쥴링이라는 주제로 승화(?)되버리는 사태에 이르게 됩니다. 잡은 나중에 프로세스(process)라는 근사한 단위로 다시 나뉘게 되고 프로세스는 또 쓰레드(thread)라는 현대적 단위로 다시 바라보게 됩니다. 위에 나온 이론들은 본 글이 진행됨과 동시에 하나씩 베일을 벗겨보기로 하죠. 위에 도배된 스케줄링이라는 말의 중요성을 한번 곰곰히 생각해 봅시다. 도데체 왜 스케줄링이 필요하지??? 그것은 바로 멀티프로세싱을 위해서 이죠. 먼저 우리가 통상적으로 쓰는 멀티프로세싱이라는 말은 적어도 씨피유가 한개 달린 시스템에서는 수도(pseudo:짜가)멀티입니다.수도란 아닌걸 긴척~ 하는 뻔뻔함을 말하죠. 시간을 쪼개서 왔다리 갔다리 거리며 동시에 뭔가를 하고있다는 착각을 교묘하게 주는 기법을 좀더 그럴싸하게 만들기 위해서는 스케쥴링 필연적이겠죠? 바이어스(bias:치우친)되지 않은 스케줄링이라고 무조건 좋은건 또 아니여요. 공평무사하기만 한 스케줄링 시스템은 결국 공산주의와 같이 모두다 가난해져버리는 결과를 낳고 말지요. 고로 또한 여기서 똘아이 역할이 하나 등장하는데 바로 그것이 여러분 이 지겹도록 들어온 선점형(pre-emptive)입니다. 일종의 막나가는 폭주족 깡패죠. 퍼스널 컴퓨터의 역사야, 맥을 다루는 사람들이라면 빠삭~!!! 할테고, 잠시 마지막으로 멀티프로세서 시스템을 간략하게 다루어볼까 합니다. 씨피유가 여럿달린 시스템은 크게 두가지 부류로 나눕니다. 하나는 패러랠 시스템으로 tightly coupled system이라고도 하죠. 요 시스템은 씨피유는 여러개이지만 램, 클럭같은 시스템 자원을 여러개의 씨피유가 공유합니다. 재미있는 사실은 n개의 씨피유가 달렸다고 해서 n배만큼의 일이 처리되는 것은 결코 아니지만, n에 가깝도록! 만드는 것이 본 시스템을 연구하는 사람들의 목적이라 할수있죠. 본 시스템의 강점은 10개의 씨피유중 하나가 맛탱이 가버리면 전 시스템이 따운!되버리는 대신 10%의 성능 감소가 일어나는 안정성에 있기도 합니다. 이러한 강점을 누리기 위하여, 오에스 설계자들이 격어야하는 고충이란,,, 패러랠시스템은 2종류로 다시 나뉠수 있는데, 한가지는 대칭형(symmetric) 멀티프로세싱 시스템이고 또하나는 비대칭형(asymmetric) 멀티프로세싱 시스템입니다. 자, 여기서 또 멋진 오에스 한개 등장 해야겄죠? 그렇습니다. BeOS입니다. BeOS는 대표적인 대칭형 멀티프로세싱 오에스로써, 씨피유바로미터를 켜보면 정말로 그 부하가 두개에 공평무사하게 대칭적으로 부과됨을 알수있게 되죠. 많은 이들이 몇년전 비오에스를 시험평가 한답시고 각자의 맥에 인스톨을 해서 좋네, 안좋네를 논하던 적이 있죠. 하지만 곰곰이 생각해보면 맥에서는 아무리 해봐야 반쪽 평가밖에는 내리지 못한다는 결론이나옵니다. 멀티플 씨피유를 지원하는 멋진오에스였어,,, 나머지하나는 마스터(master)프로세서와 떨거지(slave:노예) 프로세서들로 이루어지며, 각 씨피유는 목적이 특화되어있어서 한 시스템을 최적화 하기에는 그만이겄죠. 두번째 부류의 멀티플씨피유 시스템은 분산형(distributed) 시스템입니다. Loosely coupled system이라고도 불리며, 이는 최신 오에스의 경향이라고 까지 하더군요. 본 시스템의 특징은, 여러개의 씨피유는 각각의 메모리와 클럭등을 가지고 있게 됨으로써 일종의 네트웍을 기반으로 거대한 한개의 시스템을 구성하는 형태가 되겄죠.그래서인지 이 시스템의 단위는 씨피유라고 불리우기 보다는 사이트(site)라고 불리게 됩니다. 통신이 갈수록 빨라진는 시점에서 이런 시스템의 등장은 필연같기도 해요. 여러개의 매킨토시(LC, IIci, 8500)등을 전부 네트웍으로 연결해서 마치 하나의 거대한 컴퓨터 처럼 사용한다면 그 파워는 정말 똥파워 나오겠죠? 잠깐 여기서 짚고 넘어가야하는 것이 하나 있는데 바로 네트웍컴퓨터라는 카테고리입니다. 분산형 시스템과 네트웍컴퓨터는 엄밀히 구분되어야 하는데, 책의 후반부에 보면 잠깐 언급하기를 바로 네트웍상의 투명성이라고 추상적인 말을 합니다. 그말은 곧 네트웍 컴퓨터들은 각각을 각각으로 인식하는 고급유닛 스카웃이지만, 분산시스템은 각각이 모여 똥파워 전체가 되어버리는 일종의 저글링 개때같은 존재죠. 그밖에 실시간 시스템 등이 있지만, 그런게 있구나 라고 여기시거나 책을 한번 읽어보시길. 자, 앞으로 다룰 내용들은 위에서 언급된 내용을 더욱 구체적으로 다루는것 뿐입니다. 단지, 가끔씩 유닉스 프로그래밍을 곁들어서 실전에 임할수 있도록 나름대로 노력해볼겁니다. -duffer 경준 (http://vorlon.cwru.edu/~kxm73)
|