운영체제 유형 완벽 가이드

운영체제의 다양한 유형을 초급 개발자도 쉽게 이해할 수 있도록 설명합니다. 단일 프로그래밍부터 분산 운영체제까지, 각 유형의 특징과 실무 활용 사례를 스토리텔링으로 풀어냅니다.

---

목차

1. 단일_프로그래밍_OS
2. 멀티프로그래밍_OS
3. 멀티태스킹_OS
4. 실시간_운영체제_RTOS
5. 분산_운영체제
6. 임베디드_운영체제

---

1. 단일 프로그래밍 OS

신입 개발자 김개발 씨가 컴퓨터 역사 박물관에서 오래된 컴퓨터를 보고 있습니다. "이 컴퓨터는 한 번에 프로그램 하나만 실행할 수 있었대요." 안내원의 설명에 김개발 씨는 고개를 갸웃거렸습니다.

지금은 당연하게 여러 프로그램을 동시에 돌리는데, 그땐 어떻게 일했을까요?

단일 프로그래밍 OS는 한 번에 오직 하나의 프로그램만 메모리에 적재하여 실행하는 가장 초기의 운영체제 형태입니다. 마치 좁은 주방에서 요리사 한 명이 요리 하나를 완성해야 다음 요리를 시작할 수 있는 것과 같습니다.

단순하지만 자원 활용 효율이 낮다는 한계가 있습니다.

다음 코드를 살펴봅시다.

// 단일 프로그래밍 OS의 작업 처리 시뮬레이션
public class SingleProgrammingOS {
    private boolean cpuBusy = false;

    // 한 번에 하나의 작업만 처리 가능
    public void executeJob(String jobName) {
        if (cpuBusy) {
            System.out.println("대기: " + jobName);
            return; // 현재 작업 완료까지 대기
        }
        cpuBusy = true;
        System.out.println("실행 중: " + jobName);
        // 작업 완료 후에야 다음 작업 가능
        cpuBusy = false;
    }
}

김개발 씨는 입사 첫날 사수인 박시니어 씨로부터 운영체제의 역사에 대해 듣게 되었습니다. "컴퓨터가 처음 나왔을 때는 지금과 완전히 달랐어요." 박시니어 씨의 이야기에 따르면, 1950년대의 컴퓨터는 방 하나를 가득 채울 정도로 거대했습니다.

그리고 그 거대한 기계는 놀랍게도 한 번에 프로그램 하나만 실행할 수 있었습니다. 단일 프로그래밍 OS란 정확히 무엇일까요?

쉽게 비유하자면, 이것은 마치 일차선 도로와 같습니다. 차가 아무리 많아도 한 번에 한 대씩만 지나갈 수 있습니다.

앞 차가 목적지에 도착해야 뒤 차가 출발할 수 있는 구조입니다. 당시 컴퓨터 운영자들은 천공 카드에 프로그램을 기록해서 컴퓨터에 입력했습니다.

컴퓨터는 그 프로그램을 처음부터 끝까지 실행한 후에야 다음 천공 카드 묶음을 받아들였습니다. 중간에 다른 프로그램을 끼워넣는 것은 불가능했습니다.

이런 방식의 가장 큰 문제는 자원 낭비였습니다. 프로그램이 입출력 작업을 하는 동안 CPU는 그저 기다리기만 했습니다.

마치 요리사가 오븐에 빵을 넣어놓고 다른 요리를 하지 않고 멍하니 서 있는 것과 같았습니다. 위의 코드를 살펴보면 이 구조가 명확해집니다.

cpuBusy가 true인 동안에는 어떤 새 작업도 시작할 수 없습니다. executeJob 메서드가 호출되어도 현재 작업이 끝날 때까지 무조건 대기해야 합니다.

실제로 이 시절에는 컴퓨터 사용 시간을 예약해야 했습니다. 과학자들이 자신의 계산을 위해 컴퓨터 앞에서 줄을 서서 기다렸습니다.

한 사람의 프로그램이 버그로 무한 루프에 빠지면, 뒤에 기다리는 모든 사람이 함께 피해를 봤습니다. 하지만 모든 것이 단점만 있는 것은 아닙니다.

단일 프로그래밍 OS는 구조가 단순해서 이해하기 쉽고, 프로그램 간 충돌이 발생할 일이 없었습니다. 메모리 전체를 독점할 수 있어서 메모리 관리도 간단했습니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨는 웃으며 말했습니다.

"그래서 개발자들이 효율을 높이기 위해 여러 프로그램을 동시에 처리하는 방법을 고민하기 시작했어요. 그게 바로 다음에 배울 멀티프로그래밍이에요." 김개발 씨는 고개를 끄덕였습니다.

불편함이 혁신을 만든다는 말이 떠올랐습니다.

실전 팁

💡 - 단일 프로그래밍 OS의 개념을 이해하면 현대 OS의 발전 이유를 알 수 있습니다

• CPU 활용률이 낮은 시스템에서는 아직도 유사한 방식이 사용됩니다

---

2. 멀티프로그래밍 OS

김개발 씨가 회사 구내식당에서 점심을 먹고 있습니다. 주방을 보니 요리사가 국을 끓이면서 동시에 생선도 굽고 있었습니다.

"저렇게 하면 훨씬 빠르겠네요." 문득 단일 프로그래밍 OS의 비효율이 떠올랐습니다. 컴퓨터도 저렇게 할 수 있을까요?

멀티프로그래밍 OS는 여러 프로그램을 동시에 메모리에 적재하여 CPU 활용률을 높이는 운영체제입니다. 한 프로그램이 입출력을 기다리는 동안 다른 프로그램이 CPU를 사용합니다.

마치 빨래가 돌아가는 동안 설거지를 하는 것처럼 효율적입니다.

다음 코드를 살펴봅시다.

// 멀티프로그래밍 OS의 작업 전환 시뮬레이션
public class MultiprogrammingOS {
    private List<String> jobQueue = new ArrayList<>();
    private int currentJob = 0;

    public void loadJobs(String... jobs) {
        Collections.addAll(jobQueue, jobs);
    }

    // 입출력 대기 시 다른 작업으로 전환
    public void onIOWait() {
        System.out.println("작업 " + currentJob + " IO 대기");
        currentJob = (currentJob + 1) % jobQueue.size();
        System.out.println("작업 " + currentJob + " 로 전환");
    }
}

어느 날 박시니어 씨가 김개발 씨에게 질문을 던졌습니다. "만약 네가 1960년대 컴퓨터 과학자라면, 단일 프로그래밍의 비효율을 어떻게 해결했을 것 같아?" 김개발 씨는 잠시 생각하다가 답했습니다.

"음, 한 프로그램이 뭔가를 기다리는 동안 다른 프로그램을 실행하면 되지 않을까요?" 박시니어 씨가 환하게 웃었습니다. "정확해!

그게 바로 멀티프로그래밍이야." 멀티프로그래밍의 핵심 아이디어는 간단합니다. 컴퓨터 메모리에 여러 프로그램을 동시에 올려놓는 것입니다.

그리고 현재 실행 중인 프로그램이 입출력 작업 등으로 CPU를 사용하지 않을 때, 다른 프로그램이 CPU를 사용하도록 합니다. 비유하자면, 이것은 마치 세탁기와 식기세척기를 동시에 돌리는 것과 같습니다.

빨래가 돌아가는 40분 동안 가만히 기다리는 대신, 그 시간에 설거지를 하거나 청소를 합니다. 각각의 가전제품이 작동하는 동안 우리는 다른 일을 할 수 있습니다.

1960년대 초, IBM은 OS/360이라는 운영체제에서 멀티프로그래밍을 도입했습니다. 이를 통해 CPU 활용률이 극적으로 향상되었습니다.

이전에는 30% 정도였던 CPU 활용률이 70% 이상으로 올라갔습니다. 위의 코드를 살펴보면, jobQueue에 여러 작업이 미리 적재되어 있습니다.

onIOWait 메서드가 호출되면, 즉 현재 작업이 입출력을 기다리면, 시스템은 자동으로 다음 작업으로 전환합니다. 하지만 멀티프로그래밍을 구현하기 위해서는 새로운 기술이 필요했습니다.

메모리 보호 기능이 그 중 하나입니다. 여러 프로그램이 메모리에 있으니, 한 프로그램이 다른 프로그램의 영역을 침범하지 못하도록 해야 했습니다.

또한 작업 스케줄링도 중요해졌습니다. 어떤 작업이 CPU를 얼마나 오래 사용하게 할 것인지, 다음에 어떤 작업을 실행할 것인지 결정해야 했습니다.

이런 결정을 내리는 것이 바로 스케줄러의 역할입니다. 주의할 점도 있습니다.

멀티프로그래밍에서는 프로그램 간의 전환 시점을 사용자가 제어할 수 없습니다. 프로그램이 스스로 CPU를 양보하거나 입출력을 기다릴 때만 전환이 일어납니다.

이것이 나중에 배울 멀티태스킹과의 핵심 차이점입니다. 김개발 씨가 물었습니다.

"그러면 한 프로그램이 계속 CPU만 사용하면 다른 프로그램은 영원히 못 돌아가는 건가요?" 박시니어 씨가 고개를 끄덕였습니다. "맞아, 그래서 더 발전된 방식이 필요했지.

다음 시간에 알려줄게."

실전 팁

💡 - 멀티프로그래밍은 CPU 활용률을 높이기 위한 최초의 해결책입니다

• 현대 배치 처리 시스템에서도 이 개념이 활용됩니다

---

3. 멀티태스킹 OS

김개발 씨가 업무 중에 음악을 들으면서 코드를 작성하고, 동시에 슬랙 메시지도 확인하고 있습니다. 그런데 문득 궁금해졌습니다.

"컴퓨터가 진짜로 이걸 동시에 하는 걸까?" 박시니어 씨에게 물어보니 흥미로운 답이 돌아왔습니다.

멀티태스킹 OS는 여러 작업이 동시에 실행되는 것처럼 보이게 하는 운영체제입니다. CPU 시간을 아주 짧은 단위로 쪼개어 여러 프로그램에 번갈아 할당합니다.

마치 저글러가 여러 공을 동시에 다루는 것처럼, 실제로는 빠르게 번갈아 처리하지만 우리 눈에는 동시에 보입니다.

다음 코드를 살펴봅시다.

// 멀티태스킹 OS의 시간 분할 스케줄링
public class MultitaskingOS {
    private static final int TIME_SLICE = 100; // 밀리초
    private Queue<Runnable> readyQueue = new LinkedList<>();

    public void schedule() {
        while (!readyQueue.isEmpty()) {
            Runnable task = readyQueue.poll();
            // 각 태스크에 정해진 시간만 할당
            System.out.println("태스크 실행: " + TIME_SLICE + "ms");
            task.run(); // 실제로는 타이머 인터럽트로 중단
            readyQueue.offer(task); // 완료 전이면 다시 대기열로
        }
    }
}

박시니어 씨가 설명을 시작했습니다. "네 컴퓨터의 CPU는 사실 한 번에 하나의 일만 해.

그런데 왜 여러 프로그램이 동시에 돌아가는 것처럼 보일까?" 김개발 씨가 고개를 갸웃거렸습니다. "마술인가요?" "비슷해.

일종의 눈속임이지. 이걸 멀티태스킹이라고 해." 멀티태스킹의 비밀은 시간 분할에 있습니다.

CPU가 프로그램 A를 0.01초 실행하고, 프로그램 B를 0.01초 실행하고, 다시 프로그램 A로 돌아오는 식입니다. 이 전환이 1초에 수십 번에서 수백 번 일어나니, 사람의 눈에는 모든 프로그램이 동시에 돌아가는 것처럼 보입니다.

비유하자면, 이것은 마치 TV 채널 돌리기와 같습니다. 아주 빠르게 채널을 돌리면 마치 모든 채널을 동시에 보는 것 같은 착각이 들 수 있습니다.

물론 실제로는 한 번에 하나의 채널만 보고 있습니다. 멀티프로그래밍과의 차이가 무엇일까요?

멀티프로그래밍에서는 프로그램이 스스로 CPU를 양보할 때만 전환이 일어났습니다. 하지만 멀티태스킹에서는 운영체제가 강제로 전환을 시킵니다.

정해진 시간이 지나면 타이머 인터럽트가 발생하고, 운영체제가 현재 작업을 멈추고 다른 작업에 CPU를 넘깁니다. 위의 코드에서 TIME_SLICE가 바로 이 정해진 시간입니다.

각 태스크는 100밀리초 동안만 실행될 수 있고, 시간이 지나면 대기열 맨 뒤로 돌아갑니다. 이것을 라운드 로빈 스케줄링이라고 합니다.

1960년대 말, 시분할 시스템이 등장하면서 멀티태스킹이 본격적으로 사용되기 시작했습니다. 여러 사용자가 하나의 컴퓨터를 동시에 사용할 수 있게 되었습니다.

각자 터미널 앞에 앉아 마치 컴퓨터를 독점하고 있는 것처럼 작업할 수 있었습니다. 현대의 Windows, macOS, Linux 모두 멀티태스킹 운영체제입니다.

우리가 당연하게 여기는 "음악 들으면서 문서 작성하기"가 가능한 이유입니다. 하지만 멀티태스킹에는 오버헤드가 있습니다.

작업을 전환할 때마다 현재 상태를 저장하고 다음 작업의 상태를 복원해야 합니다. 이것을 컨텍스트 스위칭이라고 하는데, 이 과정에서 시간이 소요됩니다.

전환이 너무 잦으면 실제 작업보다 전환에 시간을 더 쓰게 될 수도 있습니다. 김개발 씨가 이해했다는 듯 말했습니다.

"그래서 프로그램이 너무 많으면 컴퓨터가 느려지는 거군요!" 박시니어 씨가 웃으며 답했습니다. "정확해.

그래서 백그라운드 프로그램 정리가 중요한 거야."

실전 팁

💡 - 시간 분할의 단위(타임 슬라이스)는 보통 10~100밀리초입니다

• 컨텍스트 스위칭 비용을 고려하여 동시 실행 프로세스 수를 관리하세요

---

4. 실시간 운영체제 RTOS

김개발 씨가 친구의 자동차 공장을 견학하게 되었습니다. 거대한 로봇 팔이 0.001초의 오차도 없이 정확하게 부품을 조립하고 있었습니다.

"저 로봇도 일반 컴퓨터처럼 윈도우로 돌아가나요?" 친구가 웃으며 고개를 저었습니다. "아니, 완전히 다른 종류의 OS를 써."

**실시간 운영체제(RTOS)**는 정해진 시간 안에 반드시 작업을 완료해야 하는 시스템을 위한 운영체제입니다. 일반 OS가 "빠르면 좋다" 라면, RTOS는 "반드시 이 시간 안에" 입니다.

항공기 제어, 의료 장비, 산업용 로봇 등 지연이 곧 사고로 이어지는 곳에서 사용됩니다.

다음 코드를 살펴봅시다.

// RTOS의 우선순위 기반 스케줄링 개념
public class RTOSScheduler {
    // 마감시한(deadline)이 있는 태스크
    class RealTimeTask {
        String name;
        int priority;
        long deadline; // 밀리초 단위 마감시한
    }

    // 항상 가장 높은 우선순위 태스크가 먼저 실행
    public RealTimeTask getNextTask(List<RealTimeTask> tasks) {
        return tasks.stream()
            .min(Comparator.comparingInt(t -> t.priority))
            .orElse(null); // 낮은 숫자 = 높은 우선순위
    }
}

박시니어 씨가 김개발 씨에게 물었습니다. "만약 네가 비행기 조종 시스템을 만든다면, 조종사가 버튼을 눌렀을 때 응답이 2초 후에 와도 괜찮을까?" 김개발 씨가 움찔했습니다.

"그건... 큰일 나겠죠." "맞아.

그래서 그런 시스템에는 일반 OS를 쓸 수 없어. RTOS가 필요하지." **실시간 운영체제(Real-Time Operating System)**는 이름 그대로 실시간성을 보장하는 운영체제입니다.

여기서 "실시간"이란 "빠른"이 아니라 **"예측 가능한 시간 내에"**를 의미합니다. 비유하자면, 일반 OS는 마치 맛집과 같습니다.

음식이 맛있지만, 오늘은 30분 걸리고 내일은 1시간 걸릴 수도 있습니다. 반면 RTOS는 응급실과 같습니다.

환자가 도착하면 반드시 정해진 시간 내에 처치가 시작되어야 합니다. 늦으면 생명이 위험해집니다.

RTOS는 크게 두 종류로 나뉩니다. 경성 실시간 시스템은 마감시한을 절대로 어기면 안 됩니다.

항공기 제어, 심장 박동기, 자동차 에어백 시스템이 이에 해당합니다. 연성 실시간 시스템은 마감시한을 어기면 성능이 저하되지만 시스템이 완전히 실패하지는 않습니다.

동영상 스트리밍이 대표적입니다. 위의 코드에서 RealTimeTask 클래스에는 deadline이라는 필드가 있습니다.

이것이 RTOS의 핵심입니다. 스케줄러는 단순히 순서대로 작업을 처리하는 것이 아니라, 마감시한과 우선순위를 고려하여 작업을 선택합니다.

VxWorks, FreeRTOS, QNX 같은 RTOS들이 실제로 사용됩니다. 특히 FreeRTOS는 오픈소스로, 아두이노나 ESP32 같은 소형 장치에서도 많이 사용됩니다.

일반 OS와의 가장 큰 차이는 인터럽트 응답 시간입니다. 일반 OS에서는 어떤 이벤트가 발생해도 다른 작업 때문에 응답이 지연될 수 있습니다.

하지만 RTOS에서는 최악의 경우에도 얼마나 빨리 응답할 수 있는지가 보장됩니다. 이것을 결정론적(deterministic) 동작이라고 합니다.

주의할 점이 있습니다. RTOS라고 해서 무조건 빠른 것은 아닙니다.

평균 속도는 일반 OS가 더 빠를 수 있습니다. RTOS의 강점은 최악의 경우에도 일정한 응답 시간을 보장한다는 것입니다.

김개발 씨가 고개를 끄덕였습니다. "그러니까 RTOS는 빠른 게 아니라 믿을 수 있는 거군요." 박시니어 씨가 엄지를 들어 보였습니다.

"완벽하게 이해했어!"

실전 팁

💡 - 임베디드 시스템 개발자라면 FreeRTOS 학습을 추천합니다

• RTOS 선택 시 최악의 경우 인터럽트 지연시간을 반드시 확인하세요

---

5. 분산 운영체제

김개발 씨가 대규모 이벤트 세일 기간에 쇼핑몰 서버가 터지지 않고 잘 버티는 것을 보고 감탄했습니다. "서버 한 대로는 절대 불가능할 텐데..." 선배에게 물어보니 흥미로운 답이 돌아왔습니다.

"여러 컴퓨터가 하나처럼 일하거든."

분산 운영체제는 네트워크로 연결된 여러 컴퓨터가 마치 하나의 시스템처럼 동작하게 하는 운영체제입니다. 사용자는 자원이 어느 컴퓨터에 있는지 알 필요 없이 투명하게 사용할 수 있습니다.

마치 여러 사람이 한 팀으로 움직이는 것처럼, 각 컴퓨터가 협력하여 더 큰 일을 처리합니다.

다음 코드를 살펴봅시다.

// 분산 시스템의 작업 분배 개념
public class DistributedOS {
    private List<Node> nodes = new ArrayList<>();

    // 작업을 여러 노드에 분산
    public void distributeTask(Task task) {
        List<SubTask> subTasks = task.split();
        for (int i = 0; i < subTasks.size(); i++) {
            Node targetNode = nodes.get(i % nodes.size());
            targetNode.execute(subTasks.get(i));
        }
        // 결과를 모아서 합침
        collectAndMergeResults();
    }
}

박시니어 씨가 김개발 씨에게 질문했습니다. "만약 하루에 10억 건의 검색 요청을 처리해야 한다면 어떻게 할 것 같아?" 김개발 씨가 잠시 계산해 보았습니다.

"초당 만 건 이상이네요... 아무리 좋은 서버라도 한 대로는 불가능하지 않나요?" "맞아.

그래서 분산 시스템이 필요해." 분산 운영체제는 여러 컴퓨터를 네트워크로 연결하여 하나의 거대한 시스템처럼 동작하게 합니다. 구글, 넷플릭스, 아마존 같은 대규모 서비스가 가능한 이유입니다.

비유하자면, 이것은 마치 대형 레스토랑 주방과 같습니다. 요리사 한 명이 모든 요리를 하면 손님들이 오래 기다려야 합니다.

하지만 여러 요리사가 각자 담당 요리를 맡으면 많은 손님을 동시에 처리할 수 있습니다. 분산 운영체제의 핵심 개념 중 하나는 투명성입니다.

사용자는 파일이 어느 컴퓨터에 저장되어 있는지, 프로그램이 어느 컴퓨터에서 실행되는지 알 필요가 없습니다. 마치 클라우드 저장소를 쓸 때 데이터가 어느 데이터센터에 있는지 신경 쓰지 않는 것처럼요.

위의 코드를 보면 분산 처리의 기본 패턴이 나타납니다. 큰 작업을 작은 하위 작업으로 나누고, 각 하위 작업을 다른 노드에 할당합니다.

모든 노드가 작업을 완료하면 결과를 모아서 합칩니다. 이것이 바로 맵리듀스 패턴의 기본 원리입니다.

분산 시스템에서 가장 어려운 문제 중 하나는 일관성 유지입니다. 예를 들어 은행 계좌 잔액이 서버 A에서는 100만 원이고 서버 B에서는 90만 원으로 보인다면 큰 문제가 됩니다.

이를 해결하기 위해 분산 합의 알고리즘 같은 복잡한 기술이 사용됩니다. 또 다른 중요한 개념은 장애 허용입니다.

수천 대의 컴퓨터 중 일부가 고장 나더라도 전체 시스템은 계속 동작해야 합니다. 넷플릭스는 의도적으로 서버를 랜덤하게 종료하는 "카오스 몽키"를 운영해서 시스템의 복원력을 테스트한다고 합니다.

실제 분산 운영체제의 예로는 구글의 Borg, Apache Mesos, Kubernetes 등이 있습니다. 특히 Kubernetes는 컨테이너 오케스트레이션 도구로, 현대 클라우드 환경에서 사실상의 표준이 되었습니다.

하지만 분산 시스템은 복잡합니다. 네트워크 지연, 부분 장애, 데이터 일관성 문제 등 새로운 종류의 문제들이 생깁니다.

"분산 시스템에서는 두 가지 어려운 문제가 있다: 순서 보장, 정확히 한 번 전달, 그리고 오프 바이 원 에러"라는 유명한 농담이 있을 정도입니다. 김개발 씨가 웃으며 말했습니다.

"농담인데 세 가지잖아요?" 박시니어 씨가 의미심장하게 말했습니다. "그게 바로 분산 시스템의 어려움을 보여주는 거야."

실전 팁

💡 - 분산 시스템 설계 시 CAP 정리를 반드시 이해하세요

• 단일 서버로 충분하다면 분산 시스템을 피하는 것도 좋은 선택입니다

---

6. 임베디드 운영체제

김개발 씨가 스마트 냉장고를 구경하고 있습니다. 화면에서 요리 레시피를 보여주고, 식재료 재고까지 관리해줍니다.

"이 냉장고도 컴퓨터인 건가?" 문득 이 작은 기기 안에 어떤 운영체제가 돌아가는지 궁금해졌습니다.

임베디드 운영체제는 특정 기능을 수행하는 전용 장치에 내장되어 동작하는 운영체제입니다. 스마트폰, 스마트워치, 자동차 네비게이션, IoT 기기 등에서 사용됩니다.

제한된 하드웨어 자원에서 효율적으로 동작해야 하므로, 가볍고 최적화되어 있습니다.

다음 코드를 살펴봅시다.

// 임베디드 시스템의 자원 제약 고려 예시
public class EmbeddedOS {
    private static final int MAX_MEMORY_KB = 256;
    private int usedMemory = 0;

    // 메모리 할당 시 제한 확인
    public boolean allocateMemory(int sizeKB) {
        if (usedMemory + sizeKB > MAX_MEMORY_KB) {
            System.out.println("메모리 부족!");
            return false; // 제한된 자원 내에서 동작
        }
        usedMemory += sizeKB;
        return true;
    }
}

박시니어 씨가 손목의 스마트워치를 보여주며 말했습니다. "이 작은 시계 안에도 운영체제가 돌아가고 있어.

그런데 Windows나 macOS는 아니야. 왜일까?" 김개발 씨가 답했습니다.

"너무 크고 무거워서요?" "정확해. 그래서 임베디드 운영체제가 필요한 거야." 임베디드 운영체제는 특정 목적을 위해 설계된 전용 장치에서 동작하는 운영체제입니다.

우리 주변의 수많은 기기들, 세탁기, 전자레인지, 자동차, 엘리베이터, 신호등 안에 임베디드 시스템이 있습니다. 비유하자면, 일반 OS가 만능 스위스 아미 나이프라면, 임베디드 OS는 전용 수술 도구와 같습니다.

모든 것을 할 수 있지만 크고 무거운 것보다, 한 가지 일을 완벽하게 하는 가볍고 정교한 도구가 더 적합한 상황이 있습니다. 임베디드 OS의 가장 큰 특징은 자원 제약 속에서 동작해야 한다는 것입니다.

위의 코드를 보면 MAX_MEMORY_KB가 256으로 설정되어 있습니다. 256KB, 일반 컴퓨터 기준으로는 상상할 수 없이 작은 양입니다.

하지만 많은 임베디드 시스템이 이보다 적은 메모리로도 동작합니다. 전력 소비도 중요한 고려사항입니다.

스마트워치나 IoT 센서는 배터리로 몇 주에서 몇 년을 동작해야 합니다. 따라서 임베디드 OS는 불필요한 동작을 최소화하고, 가능하면 절전 모드로 전환하도록 설계됩니다.

대표적인 임베디드 OS로는 임베디드 리눅스, Android(스마트폰용), Tizen(삼성 가전), watchOS(애플워치) 등이 있습니다. 더 작은 장치에서는 FreeRTOS, Zephyr, mbedOS 같은 경량 RTOS가 사용됩니다.

임베디드 개발의 어려움 중 하나는 디버깅입니다. 일반 컴퓨터에서는 버그가 생기면 로그를 보거나 디버거를 붙일 수 있습니다.

하지만 세탁기 안의 마이크로컨트롤러에서 문제가 생기면 어떻게 해야 할까요? 특수한 장비와 기술이 필요합니다.

또한 임베디드 시스템은 한 번 배포되면 업데이트하기 어려운 경우가 많습니다. 자동차에 탑재된 소프트웨어를 리콜 없이 업데이트하는 것은 최근에야 일반화되고 있습니다.

따라서 처음부터 버그 없이 완벽하게 만들어야 한다는 부담이 있습니다. 요즘은 IoT의 발전으로 임베디드 시스템도 네트워크에 연결되는 경우가 많습니다.

이에 따라 보안도 중요한 이슈가 되었습니다. 해킹당한 스마트 도어락이나 웹캠 이야기가 뉴스에 종종 등장하는 이유입니다.

김개발 씨가 주변을 둘러보며 말했습니다. "이렇게 보니 우리 주변에 임베디드 시스템이 정말 많네요." 박시니어 씨가 고개를 끄덕였습니다.

"맞아. 눈에 보이지 않지만, 현대 사회를 조용히 움직이고 있는 거야."

실전 팁

💡 - 임베디드 개발 입문은 아두이노나 라즈베리파이로 시작하세요

• 메모리와 전력 사용량을 항상 의식하면서 코드를 작성하는 습관을 들이세요

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!