목차
0. 운영체제란?
우리는 살아가면서 컴퓨터와 스마트폰,네비게이션,전자레인지와 같은 전자제품을 사용합니다.
요즘 나오는 전자제품에는 거의 대부분 운영체제라는 것을 사용합니다.
그럼 운영체제라는게 대체 뭘까요?
그전에 운영체제가 왜 만들어 졌는지 한번 역사를 통해서 보겠습니다.
0-1. 운영체제의 필요성
과거 1950년대, 에니악이 나왔던 그 당시로 돌아가보면 에니악은 지금과 같은 키보드, 모니터, 마우스등이 일절 없는 4층짜리 커다란 계산기에 불과했습니다.
위 사진이 애니악의 일부분입니다.
애니악은 진공관을 이용하여 회로를 구성한 무식하게 컸습니다.
진공관은 지금의 트랜지스터와 같으며 쉽게 이야기하면 직류를 교류로 바꿔준다던가 신호를 제어하는 역할을 합니다.
자세한 원리나 설명은 아래 링크에서 확인해주세요.
당연하지만, 당시에는 운영체제라는 개념이 존재하지 않아서, 애니악은 그저 전선의 연결을 변경시켜서 프로그래밍을 하는 개념이 컸습니다.
그래서 구현한 기능 1가지 이외에는 다른 기능을 사용하기에 매우 껄끄러웠습니다.
<저 그림위에 기능을 바꾸기 위해서 선을 하나하나 바꾼다 생각해보세요. 얼마나 귀찮고 헷갈립니까?>
이렇게, 운영체제는 컴퓨터 사용자와 컴퓨터 HW간의 인터페이스를 담당하는 프로그램입니다.
※ 여기서 간략하게 용어를 정리해보는 시간을 가져보겠습니다.
| 이름 | 설명 |
| 컴퓨터 사용자<=User> | 컴퓨터를 직접적으로 사용하는 사람, 즉 우리들입니다. |
| 하드웨어<=HW> | 연산을 직접적으로 처리하며, 이러한 연산을 위한 자원을 제공하는 기기들 |
| 유틸리티 | 컴퓨터의 여러 처리과정을 보조하는 프로그램 대표적으로 컴파일러, 편집기, 디스크 조각모음 등이 있습니다. |
| 응용 프로그램 | 우리가 흔히 이야기하는 프로그램의 개념이 응용 프로그램입니다. 게임이라던가 메모장 은행 프로그램 등등 많죠. |
그리하여 IBM에서 IBM360이라는 최초의 상용화 OS를 개발하게 되었습니다.
그리고 운영체제를 통해서 새로운 기능을 쉽게 추가, 자원관리 및 성능 향상을 도모할 수 있게 되었습니다.
그러면 간략하게 운영체제의 목표를 그림을 통해 정리 해보는 시간을 갖겠습니다.
운영체제의 목표는 크게 4가지로 분류가 됩니다.
1. 효율성 : 적은 자원을 활용하여 빠른 결과를 보여줍니다.
2. 안정성 : 운영체제가 안정하다면 사용자가 프로그램을 짜더라도 운영체제상에서 오롯이 프로그램을 보존 할 수 있으며 작업성 또한 안정합니다.
3. 확장성 : 다양한 자원을 바로 실행할 수 있는<이를 플러그 앤 플레이라 함> 역할을 맡습니다.
4. 편리성 : 현재의 윈도우와 같이 GUI<Graphical User Interface>를 제공하여 컴퓨터를 모르는 사람도 직관적으로 사용할 수 있게 만드는 역할을 합니다
1. 운영체제의 역사
1-1. 초창기 컴퓨터<1940년대 - 1950년대> - 애니악,천공 컴퓨터
에니악 : 진공관을 사용하여 2진법이라는 개념을 정립한 시기입니다.
즉 True가 1이면 진공관이 켜지고 False라면 0 진공관이 꺼지는 방식으로 작동이 됩니다.
이때에는 프로그래밍을 전선의 연결을 통해서 논리회로를 구성하는 방식으로 했습니다. (= 하드와이어링)
위에서 이야기 했다시피 에니악은 하나의 기능밖에 수행을 하지 못합니다.
천공 컴퓨터란 쉽게 생각하면 OMR 카드를 떠올리면 이해가 빠를겁니다.
OMR 카드를 기억해보면 특정 부분에 마크를 하잖아요. 그 부분이 일종의 1과0을 따지는 데이터와 같습니다.
그러니까 마크가 되어있는 부분이 2진법을 따지면 1<즉 True> 마크가 안되어있는 부분이 0<=False>와 같다고 이해하면 됩니다.
1-1-1. 운영체제가 없다??
여기서 문제점이 무엇이냐면, 이 당시에는 운영체제라는 개념이 존재하지 않던 시기였습니다.
그래서 프로그래머들이 하나부터 열까지 모든것을 다 해야 했고, 하나의 작업을 하는데 있어서 하나의 밑작업이 필요했습니다.
또한, 사용자 한명이 어떠한 명령 하나를 실행중인데, 1시간을 기준으로 잡을 경우에 1시간을 덜 채우고 끝내는 경우가 있고 1시간이 넘도록 작업이 안 끝나는 경우도 왕왕 있었습니다.
쉽게 생각해서, 화장실을 사용한다 칩시다.
화장실을 사용하는데 있어서 조건이 2가지가 있습니다.
1. 화장실은 한번에 한사람만 딱 10분을 사용할 수 있다.
2. 화장실을 사용하기 전에 각자 화장실을 사용할 준비로써 휴지와 물티슈 비누를 준비해야 한다.
먼저, 1번 조건의 문제점을 살펴보자면 아래와 같습니다.
A는 1분만 쓰고 나가면 되는데 뒤에 기다리는 사람들은 쓸데없이 4분을 기다려야 하는겁니다!
반대로, B는 10분을 써야하는데 중간에 끊고 나가서 다시 줄을 서야 하는 불상사가 벌어지는것이죠!
그리고 2번 조건의 문제점을 살펴 봅시다.
A는 휴지가 준비가 되어있지 않아서, 걸어서 5분거리인 슈퍼마켓에 가서 휴지를 사와야 합니다.
기다리는 만큼 또 지연이 되는게 문제가 됩니다.
B는 너무 깔끔한 성격이라서 비누가 없어서 뒤의 사람에게 비누를 빌려달라고는 못하고 또 비누를 사러 갔다와야합니다.
이제, 프로그래머들은 이렇게는 더 이상 못해먹겠네! 해서 나온게 바로 일괄 작업 시스템입니다.
1-2. 일괄 작업 시스템<1950년대 - 1960년대>
이제는 프로그래머들이 머리를 콩알만큼 굴려서 나온게 바로 일괄 작업 시스템<Batch Job System>입니다.
일련의 공통된 작업을 한다면 그 작업들을 일괄적으로 묶어서 처리하는것이 바로 일괄작업 시스템입니다.
＊config.sys,autoexec.bat 파일이 있는데<운영체제가 사용하는 파일>.bat가 위의 일괄 작업의 흔적입니다.
위의 화장실의 예시를 들어 설명해봅시다.
만약, 소변을 보고 싶은 분들이라면 비누만 준비하면 됩니다.
반면 대변을 보고 싶은 분들이라면 휴지와 비누, 필요에 따라서는 물티슈를 준비해야하겠죠.
이런식으로 소변을 보고 싶은 사람들끼리 그룹을 지어서 한번에 화장실에 왔다 갔다 하면 훨씬 일이 빠르게 처리가 될겁니다.
1-2-1. 일괄 작업 시스템의 문제점
하지만 일괄 작업 시스템도 문제점이 있습니다.
1. 하나의 작업이 어떠한 문제점이 발견 되어서 중단을 하게 된다면 이 문제점을 찾기 까지 시간이 너무 오래 걸린다.
2. 작업을 한번 실행 시키기 위해서 밑작업을 할 데이터를 준비시키는 시간이 많이 든다.
3. 작업이 한번 끝나고 다른 작업을 할 때 까지<천이상태>의 빈 시간이 생긴다.
위의 화장실의 예를 다시 들어 설명해보겠습니다.
소변을 보고 싶은 그룹들이 있습니다. 그래서 화장실에 들여보내 줬는데 A그룹내에서 사소한 문제가 생겼습니다. 그래서 화장실 무슨 칸이 문제인지를 판단해야하는데 이게 1번 문제입니다.
그리고, 비누를 모두 챙기는데 시간이 각각 달라서 누구는 갖고 있는데 누구는 사러 멀리까지 갔다와야합니다. 이게 2번째 문제입니다.
마지막으로, A그룹이 화장실을 다 보고 B그룹이 준비가 되기까지 공백기가 생깁니다. 이때 화장실은 텅텅 비죠. 이게 3번째 문제점입니다.
이때, 3번 문제점을 해결하기 위해 생겨난 개념이 바로 상주 모니터<Resident Monitor>라는 것으로써 작업이 끝나면 바로 다음 작업을 시킬 수 있도록 도와주는 기능이 도입되었습니다.
그리고 상주 모니터가 어떠한 일을 하는지 정보에 대한 기록을 위해 제어카드<control card>가 도입되었습니다.
또한, 상주모니터는 버퍼와 스풀링이라는 개념을 도입하게 되었습니다.
1-2-2. 버퍼, 스풀링
버퍼와 스풀링은 쉽게 생각하면 작업 전에 놓는 임시 저장소라 생각하면 됩니다.
아마, 이것을 기억하시는 분들이라면 2024년 기준으로 최소 20대 중후반일겁니다.
버퍼링이란 메모리의 일부를 버퍼로 설정하여 Input/Output과 프로세서<=CPU>의 연산간의 딜레이를 없애는 기술입니다.
위의 그림에서 보다시피, 버퍼는 입출력 장치<=Input/Output>과 CPU간의 연산처리 시간의 딜레이를 없애고자 만든 일종의 임시공간입니다.
1-3. 다중 프로그래밍 시스템<Multi Programming>과 시분할 시스템<Time Sharing System>
하지만, 이런 일괄배치 시스템도 결국은 프로세서가 한번에 하나만 일을 처리할 수 밖에 없습니다.
위에서 언급한 문제점이 바로 그것이죠.
다중 프로그래밍은 CPU 사용시간을 잘게 쪼개어서 여러 작업을 하게 만드는 겁니다.
말보다 이건 그림으로 보는편이 빠릅니다.
위의 그림이 다중 프로그래밍을 표현한 그림입니다.
단위시간이 1초라 치고 표를 그려보면 다음과 같습니다.
| 0~1초 | 프로그램1 에 CPU 작업을 할당 |
| 1~2초 | 프로그램2 에 CPU 작업을 할당 |
| 2~3초 | 프로그램1 |
| 3~4초 | 프로그램2 |
| 4~5초 | 프로그램1 |
보통 이렇게 작업을 조금씩 처리하여 작업이 동시에 이루어지는것과 같은 것을 다중 프로그래밍이라 합니다.
그리고 단위시간을 타임 슬라이스라고 합니다.
이해가 조금 어렵다면 아까 언급한 화장실 이야기로 돌아가봅시다.
A그룹이 화장실을 사용하는 동안 B그룹이 밑준비를 한다면 어떨까요?
이렇게 스케줄을 진행한다면 아마 프로세서 즉 화장실이 쉴 틈 없이 사용될겁니다.
시분할 시스템은 이를 약간 확장한 느낌인데요.
프로그램이 여러개가 있는겁니다. 두개가 아니라 여러개가 있는거에요!
그러니까 단위시간이 정말 짧아서 마치 여러 프로그램이 동시에 작동하는것과 같은 착각이라고 이해하시면 됩니다.
정말 쉽게 예를 들자면 아래의 짤방을 보시면 이해가 되실 겁니다.
시분할 시스템의 문제점은 어떤 시간제한내에 작업이 끝나는것을 보장하지 못합니다.
이를 보완하기 위해서 나온것이 실시간 시스템<real-time system>입니다.
1-4. 분산형 시스템 <1970년대>
1977년 애플의 스티브 잡스는 애플2라는 컴퓨터를 통해서 컴퓨터의 대중화를 실현하게 되었습니다.
이에 따라 운영체제 시장의 성장이 커지게 되었으며 컴퓨터와 컴퓨터간의 통신이 중요한 시대가 오게 되었습니다.
그리고 1960년대 미국의 ARPA(Advanced Research Project Agency)라는 단체에서는 컴퓨터간에 통신을 하기 위해서 LAN(Local Area Network)을 하나로 묶기 위한 통신 규약을 통일하고자 하는 시도를 합니다.
이 규약을 TCP/IP라 하며 지금도 통신에서 가장 많이 사용되는 규약입니다.
더 자세한 이야기는 네트워크 이론에서 다루도록 하겠습니다.
당시에 슈퍼컴퓨터를 애플2와 같은 가정용 컴퓨터 여러대를 하나로 묶어서 슈퍼컴퓨터화 하자는 개념이 바로 분산 시스템입니다.
1-5. 클라이언트 서버 <1990년대와 현재>
분산 시스템의 문제점은 모든 컴퓨터가 동일한 지위라는 점이 문제였습니다.
즉 작업의 결과물들의 파편들이 각각의 컴퓨터에 있어서 만약 컴퓨터가 하나가 고장나면 작업을 못한다는 문제점이 있습니다.
쉽게 말하면 각각의 컴퓨터가 엑조디아 파츠라 생각하면 이해가 빠를겁니다.
수중의 패에 엑조디아 패가 하나라도 없으면 게임에서 승리를 못한다는 룰이 있듯이 분산 시스템의 문제는 이와 같습니다.
이를 해결하기 위해서 클라이언트/서버 시스템이라는 개념이 도입이 되게 됩니다.
서버용 컴퓨터 하나를 둬서 컴퓨터끼리 통신을 하자는 개념이 바로 클라이언트/서버 시스템의 개념입니다.
그리고 여기서 데몬이라는 개념이 나오게 되는데 쉽게 말하면 클라이언트의 요청이 있던 없던간에 서버 컴퓨터에서 계속해서 작동시켜야 하는 프로그램을 데몬이라고 합니다.
<아마 백엔드 개발을 배워본 분이라면 아파치 톰캣,Nginx,IIS와 같은 프로그램을 써본 경험이 있을겁니다. 이것이 데몬입니다.>
1-6. P2P와 그리드 컴퓨팅<2000년대 초반 ~ 현재>
아마 가장 대표적으로 알고 계실듯한 프로그램들은 소리바다,프루나,당나귀와 XX디스크,토렌트와 같은것입니다.
위에서 언급한 분산 시스템이라던가 클라이언트/서버 시스템은 대장격처럼 어떠한 컴퓨터에 하나로 자료를 뭉치는 개념같은 겁니다.
반면 그리드와 P2P는 따로 호스트 컴퓨터가 존재하지 않고 사용자들끼리 뿜빠이 한다는 개념이 큽니다.
요약 정리.
1. 운영체제의 목표는 사용자의 편의성을 제공해주는 인터페이스, 자원관리와 같은 역할을 맡습니다.
2. 과거에는 일괄작업을 하였으나 일괄작업의 문제점인 중간 수정이 되지 않는다는 점때문에 인터렉티브 시스템이 만들어 졌습니다.
3. 인터렉티브 시스템에서 다중 작업을 처리하기 위해 시분할 시스템이라는 개념이 생겨나게 되었습니다.
4. 시분할 시스템이 생겨나며 PC가 개인이 가지게 됨에 따라서 분산형 컴퓨팅이 생겨나게 되었습니다.
'CS 이론 > 운영체제' 카테고리의 다른 글
| 운영체제 3부<프로세스와 상태> (0) | 2024.10.09 |
|---|---|
| 운영체제 2부<구조> (0) | 2024.01.11 |
