Booil Jung

산업 분야 및 응용별 운영체제

운영체제(Operating System, OS)는 컴퓨터 하드웨어 바로 위에 설치되어 사용자 및 다른 모든 소프트웨어와 하드웨어를 연결하는 필수적인 소프트웨어 계층이다.1 그 본질과 역할은 바라보는 관점에 따라 다르게 정의될 수 있다.

사용자 관점(User View)에서 운영체제는 복잡한 하드웨어의 작동 방식을 숨기고, 사용자가 컴퓨터를 쉽고 편리하게 사용할 수 있도록 돕는 도구다. 여러 사용자가 하나의 시스템 자원을 공유하는 메인프레임이나 미니컴퓨터 환경에서는 각 사용자에게 자원이 공평하게 할당되도록 보장하는 역할에 초점을 맞춘다.2 즉, 사용자에게는 일관되고 편리한 가상 환경을 제공하는 것이 주된 목표다.3

반면, 시스템 관점(System View)에서 운영체제는 한정된 시스템 자원을 관리하는 자원 할당자(Resource allocator)이자 제어 프로그램(Control program)이다.2 CPU 시간, 메모리 공간, 파일 저장 공간, 입출력 장치 등 다양한 자원을 어떤 프로세스에, 언제, 얼마만큼 할당할지를 결정하며 시스템 전체의 성능을 최적화한다.

이 두 관점은 운영체제의 이중적 정체성을 드러낸다. 운영체제는 사용자에게 복잡한 하드웨어를 추상화하여 편리한 인터페이스를 제공하는 ‘추상화 제공자’임과 동시에, 시스템 내부적으로는 한정된 자원을 ‘효율성’과 ‘형평성’이라는 원칙 아래 배분해야 하는 ‘자원 관리자’의 역할을 수행한다.1 때로는 상충될 수 있는 이 두 목표 사이에서 균형을 잡는 방식이 각 운영체제의 고유한 설계 철학을 결정짓는다.

운영체제의 핵심 기능은 크게 세 가지로 분류할 수 있다.

1. 자원 관리 (Resource Management): CPU 스케줄링을 통해 여러 프로세스가 CPU를 효율적으로 공유하도록 하고, 메모리 관리를 통해 각 프로세스에 메모리 공간을 할당 및 회수하며, 디스크 스케줄링과 파일 시스템을 통해 보조기억장치를 관리한다. 궁극적으로 시스템의 처리량(throughput)을 극대화하고 유휴 시간(idle time)을 최소화하는 것을 목표로 한다.1
2. 인터페이스 제공 (Interface): 사용자가 하드웨어의 복잡한 내부 구조나 동작 원리를 알지 못하더라도 명령줄 인터페이스(CLI)나 그래픽 사용자 인터페이스(GUI)를 통해 시스템과 상호작용하고 원하는 프로그램을 실행할 수 있도록 편리한 환경을 제공한다.1
3. 시스템 보호 및 보안 (Protection and Security): 악의적인 프로그램이 운영체제의 핵심 코드(커널)를 변경하거나, 허가받지 않은 사용자가 시스템 내부 데이터에 접근하는 것을 막는다. 이를 통해 사용자와 시스템 자체를 보호하는 중요한 기능을 수행한다.1

운영체제의 기능 중 항상 메모리에 상주하며 가장 핵심적인 역할을 수행하는 부분을 커널(Kernel)이라고 한다.1 커널을 어떻게 설계하는지에 따라 운영체제의 전체적인 특성이 결정되며, 대표적으로 모놀리식 커널과 마이크로커널 방식으로 나뉜다.

• 모놀리식 커널 (Monolithic Kernel): 파일 시스템, 프로세스 스케줄러, 메모리 관리자, 네트워크 스택, 디바이스 드라이버 등 운영체제의 거의 모든 핵심 기능이 커널이라는 단일 프로그램 내에서, 동일한 주소 공간에 통합되어 동작하는 구조다.5 커널 내부의 서비스들이 직접 함수를 호출하며 통신하므로 오버헤드가 적어 성능이 매우 우수하다는 장점이 있다.6 하지만 모든 기능이 강하게 결합되어 있어, 특정 기능에 발생한 작은 결함이 시스템 전체의 안정성을 해칠 수 있다. 또한 새로운 기능을 추가하거나 기존 기능을 수정하려면 커널 전체를 다시 컴파일하고 시스템을 재부팅해야 하므로 유연성과 유지보수성이 떨어진다.5
• 마이크로커널 (Microkernel): 스레드 관리, 메모리 관리, 프로세스 간 통신(IPC) 등 운영체제의 가장 본질적이고 필수적인 기능만을 커널에 남겨두고, 파일 시스템, 네트워크 스택, 디바이스 드라이버와 같은 나머지 서비스들은 사용자 공간(user space)에서 독립적인 서버(server) 프로세스 형태로 실행하는 구조다.5 각 서비스가 모듈화되어 독립적으로 동작하므로, 특정 서버에 문제가 발생하더라도 다른 서비스나 커널 자체에는 영향을 미치지 않아 시스템 전체의 안정성과 보안성이 높다. 또한 새로운 기능을 추가할 때 해당 서버 프로세스만 교체하거나 추가하면 되므로 유연성과 확장성이 뛰어나다.5 반면, 사용자 공간의 서버들과 커널 간에, 또는 서버들 간에 빈번하게 메시지를 주고받는 IPC 과정에서 문맥 교환(context switch)이 발생하여 모놀리식 커널에 비해 성능 저하가 발생할 수 있다.6

이 두 아키텍처의 선택은 단순한 기술적 차이를 넘어, 해당 운영체제가 ‘성능’과 ‘안정성 및 유연성’ 중 무엇을 최우선 가치로 삼을 것인지에 대한 근본적인 철학적 선택을 반영한다. 예를 들어, 극도의 연산 성능이 요구되는 고성능 컴퓨팅(HPC) 분야에서는 모놀리식 구조의 Linux가 표준으로 자리 잡았고, 반대로 단 하나의 오류도 허용되지 않는 자동차의 기능 안전 시스템에서는 마이크로커널 기반의 QNX가 선호된다. 이는 각 산업 분야의 핵심 요구사항이 운영체제의 근본적인 아키텍처 선택에 직접적으로 투영된 결과라 할 수 있다.

특성	모놀리식 커널 (Monolithic Kernel)	마이크로커널 (Microkernel)
구조	모든 OS 서비스가 커널 공간 내 단일 프로그램으로 통합	필수 기능만 커널에 남기고, 대부분의 서비스는 사용자 공간 서버로 분리
성능	서비스 간 통신 오버헤드가 적어 빠름 6	커널-서버 간 IPC 오버헤드로 인해 상대적으로 느림 6
안정성	단일 컴포넌트의 결함이 전체 시스템 장애로 이어질 수 있음 5	서비스가 분리되어 있어 결함이 격리되고 시스템 안정성이 높음 5
유연성/확장성	기능 추가/변경 시 커널 전체 재컴파일 필요 6	새로운 서비스(서버)를 동적으로 추가/교체하기 용이 5
보안	공격 표면이 넓고, 커널 권한 탈취 시 전체 시스템이 위험 5	최소한의 커널과 분리된 서버 구조로 공격 표면이 좁고 보안성이 높음 5
대표 예시	Linux, UNIX, MS-DOS, Windows (초기 버전)	QNX, Minix, Mach (macOS의 기반)

개인용 컴퓨터(PC) 환경은 대중이 가장 보편적으로 컴퓨팅을 경험하는 영역으로, 각기 다른 철학과 강점을 지닌 운영체제들이 경쟁하고 있다.

Microsoft Windows는 1981년 단일 사용자용 운영체제였던 DOS에서 출발하여, 다중 작업을 지원하는 그래픽 사용자 인터페이스(GUI) 기반 운영체제로 발전하며 PC 시장의 지배적인 위치를 확립했다.3 Windows의 가장 큰 강점은 압도적으로 넓은 하드웨어 호환성과 방대한 상용 애플리케이션 생태계에 있다.3 특히 Microsoft Office 제품군을 필두로 한 사무용 소프트웨어와의 강력한 연계는 비즈니스 환경에서 Windows를 필수적인 선택지로 만들었다.9 사용자 인터페이스는 화면 하단의 작업 표시줄(Taskbar)과 시작 메뉴(Start Menu)를 중심으로 구성되며, ‘스냅(Snap)’ 기능을 통해 최대 4개의 애플리케이션 창을 화면에 효율적으로 배열하는 등 다중 작업 편의성을 제공한다.9 파일 시스템으로는 주로 NTFS(New Technology File System)와 FAT32를 사용한다.10

Apple의 macOS는 UNIX 운영 체제를 기반으로 하며, Apple이 직접 설계하고 판매하는 Mac 하드웨어에서만 독점적으로 실행된다는 점이 가장 큰 특징이다.3 이러한 하드웨어와 소프트웨어의 수직적 통합은 높은 수준의 최적화와 안정성을 가능하게 한다. macOS는 전통적으로 그래픽 디자인, 영상 편집, 음악 작업 등 창의적인 멀티미디어 작업에 강점을 보여왔다.9 또한, UNIX 기반의 강력하고 편리한 터미널(Terminal) 환경을 기본적으로 제공하여 소프트웨어 개발자들에게도 높은 선호도를 보인다.11 사용자 인터페이스는 화면 하단의 ‘독(Dock)’을 통한 빠른 앱 접근과 미려한 디자인으로 직관적인 사용자 경험을 제공하며, 트랙패드를 활용한 다양한 제스처는 작업 효율성을 높여준다.9 파일 시스템은 주로 APFS(Apple File System) 또는 HFS+를 사용한다.10

Linux는 소스 코드가 공개된 오픈 소스 프로젝트로서, 전 세계 수많은 개발자와 커뮤니티의 참여로 발전하고 있다.10 특정 기업에 종속되지 않고 누구나 자유롭게 소스 코드를 수정하여 자신만의 배포판(Distribution)을 만들 수 있다는 점이 가장 큰 특징이다. 이로 인해 Ubuntu, Fedora, Debian 등 다양한 목적과 철학을 가진 배포판이 존재한다. 사용자는 GNOME, KDE, XFCE 등 자신의 취향과 시스템 사양에 맞는 다양한 데스크톱 환경을 자유롭게 선택하고 변경할 수 있어, 사용자 맞춤화의 폭이 매우 넓다.10 파일 시스템 역시 EXT4, Btrfs, XFS 등 여러 종류를 지원하여 사용 목적에 따라 최적의 시스템을 구성할 수 있다.10 UNIX에 뿌리를 둔 강력한 권한 관리 모델 덕분에 보안성이 매우 높다는 장점도 있다.10

PC 운영체제를 선택하는 행위는 단순히 기술적 사양을 비교하는 것을 넘어, 특정 ‘생태계’에 편입되는 것을 의미한다. 각 운영체제는 자신만의 핵심 생태계를 중심으로 발전해왔으며, 이는 사용자의 작업 방식과 경험 전반에 깊은 영향을 미친다.

Windows는 가장 폭넓은 하드웨어 및 소프트웨어 호환성을 바탕으로 ‘업무 생산성 및 게임’ 생태계를 구축했다. 대부분의 사무용 소프트웨어와 최신 게임은 Windows 환경을 기준으로 개발되므로, 범용적인 작업을 수행하는 사용자에게는 가장 편리한 선택지다.8

macOS는 Apple의 하드웨어와 긴밀하게 통합된 ‘창작 및 Apple 기기 간 연동’ 생태계를 대표한다. iPhone, iPad 등 다른 Apple 기기와의 매끄러운 데이터 연동(Continuity) 기능과 전문적인 창작 도구들은 콘텐츠 제작자에게 강력한 작업 환경을 제공한다.11

Linux는 오픈소스 철학을 바탕으로 한 ‘개발 및 학술’ 생태계의 중심에 있다. 강력한 명령줄 도구, 방대한 오픈소스 라이브러리, 그리고 서버 환경과의 유사성은 소프트웨어 개발자와 시스템 관리자에게 최적의 환경을 제공한다.11

결국 어떤 운영체제가 ‘더 우수한가’라는 질문보다는, 사용자의 주된 목적과 가치관이 어떤 ‘생태계’와 가장 잘 부합하는지를 판단하는 것이 더 중요하다. 이 선택은 소프트웨어 호환성, 하드웨어 선택의 폭, 그리고 궁극적으로는 컴퓨팅 경험의 질을 결정하는 핵심적인 요인으로 작용한다.

구분	Microsoft Windows	Apple macOS	Linux (Desktop)
핵심 철학	범용성, 하드웨어 호환성, 비즈니스 생산성	사용자 경험, 창의적 작업, 하드웨어-소프트웨어 통합	개방성, 사용자 선택권, 개발자 친화성
주요 용도	사무, 게임, 일반 가정용 9	그래픽 디자인, 영상 편집, 소프트웨어 개발 9	서버 관리, 소프트웨어 개발, 학술 연구 11
UI/UX	작업 표시줄, 시작 메뉴 9	독(Dock), 메뉴 바, 직관적 제스처 9	고도로 사용자화 가능한 다양한 데스크톱 환경 (GNOME, KDE 등) 10
파일 시스템	NTFS, FAT32 10	APFS, HFS+ 10	EXT4, Btrfs, XFS 등 다수 지원 10
보안 모델	UAC 기반 권한 관리, 바이러스 노출 위험 상대적 높음 10	UNIX 기반 권한 관리, 샌드박싱, 바이러스 적음 10	UNIX 기반 세분화된 권한 관리, 매우 높은 보안성 10
소프트웨어 생태계	가장 방대한 상용 소프트웨어 및 게임 지원 8	전문적인 창작 도구, iOS 개발 필수 11	강력한 오픈소스 개발 도구 및 라이브러리 11

스마트폰과 태블릿으로 대표되는 모바일 컴퓨팅 환경은 Android와 iOS라는 두 거대 플랫폼이 시장을 양분하고 있다. 두 운영체제는 서로 다른 아키텍처와 개발 철학을 바탕으로 독자적인 생태계를 구축했다.

Android는 수정된 Linux 커널을 기반으로 하는 오픈 소스 운영체제로, Google이 주도하는 Open Handset Alliance에 의해 개발되었다.12 개방적인 라이선스 정책 덕분에 수많은 하드웨어 제조사들이 자사의 기기에 Android를 탑재할 수 있었고, 이는 전 세계 모바일 시장에서 압도적인 점유율을 확보하는 원동력이 되었다.12 Android 아키텍처는 다음과 같은 계층 구조로 이루어져 있다.15

1. Linux Kernel: 최하위 계층으로, 보안, 메모리 관리, 프로세스 관리, 네트워크 스택, 그리고 디스플레이, 카메라, 오디오 등 하드웨어 제어를 위한 디바이스 드라이버 모델과 같은 핵심 시스템 서비스를 제공한다.17
2. HAL (Hardware Abstraction Layer): 하드웨어 제조사가 각자의 하드웨어에 맞는 드라이버를 구현할 수 있도록 표준화된 인터페이스를 제공하는 계층이다. HAL 덕분에 상위의 Android 프레임워크는 특정 하드웨어 구현에 종속되지 않고 동작할 수 있다.15
3. Android Runtime (ART) & Native C/C++ Libraries: ART는 Android 앱의 바이트코드(DEX 파일)를 기계어로 변환하여 실행하는 런타임 환경이다. 초기 Dalvik 가상 머신(DVM)과 달리, 설치 시점에 코드를 미리 컴파일하는 AOT(Ahead-Of-Time) 방식을 도입하여 앱 실행 속도를 향상시켰다.16 이와 함께 그래픽 처리를 위한 OpenGL ES, 데이터베이스를 위한 SQLite 등 C/C++로 작성된 핵심 네이티브 라이브러리들이 이 계층에 포함된다.18
4. Application Framework: 개발자들이 앱을 만드는 데 사용하는 고수준의 API를 제공하는 계층이다. 앱의 생명주기를 관리하는 Activity Manager, 앱 간 데이터 공유를 담당하는 Content Provider, UI 구성을 위한 View System 등 다양한 시스템 서비스를 포함한다.15
5. Applications: 최상위 계층으로, 전화, 주소록과 같은 기본 앱과 사용자가 Google Play Store 등에서 다운로드하여 설치한 서드파티 앱들이 위치한다.16

iOS는 Apple이 자사의 iPhone, iPad 등 모바일 기기 전용으로 개발한 독점 운영체제다.12 하드웨어, 운영체제, 앱 배포 채널(App Store)까지 모든 요소를 Apple이 직접 통제하는 폐쇄형 플랫폼이라는 점이 가장 큰 특징이다.20 이 아키텍처는 Darwin 커널(BSD UNIX 기반)을 핵심으로 하며, 네 개의 주요 계층으로 구성된다.21

1. Core OS: 최하위 계층으로, 커널, 파일 시스템, 네트워크, 보안, 전력 관리 등 하드웨어와 직접 상호작용하는 저수준 서비스를 담당한다. Accelerate 프레임워크를 통해 하드웨어 가속 연산을 지원하고, Security 프레임워크를 통해 키체인, 암호화 등의 보안 기능을 제공한다.22
2. Core Services: 앱의 핵심 기능 구현에 필요한 기본적인 시스템 서비스를 제공하는 계층이다. 데이터 타입과 컬렉션을 다루는 Foundation 프레임워크, 객체 그래프와 데이터 영속성을 관리하는 Core Data, 사용자의 위치 정보를 다루는 Core Location 등이 여기에 속한다.22
3. Media: 오디오, 비디오, 그래픽, 애니메이션 등 멀티미디어 처리를 담당하는 계층이다. 2D 그래픽을 위한 Core Graphics(Quartz 2D), 부드러운 애니메이션을 위한 Core Animation, 오디오/비디오 재생 및 처리를 위한 AVFoundation 등이 포함되어 풍부한 사용자 경험을 가능하게 한다.25
4. Cocoa Touch: 최상위 계층으로, 앱의 사용자 인터페이스(UI)와 사용자 상호작용을 담당한다. 버튼, 슬라이더 등 UI 컴포넌트를 제공하는 UIKit 프레임워크와 선언적 UI 개발을 위한 SwiftUI 프레임워크가 핵심이다. 멀티터치 제스처 인식, 푸시 알림 등 모바일 환경에 특화된 기능들을 제공한다.22

Android와 iOS는 표면적으로 유사한 모바일 경험을 제공하지만, 그 기저에 깔린 아키텍처 철학은 근본적인 차이를 보인다. 두 플랫폼 모두 MVC(Model-View-Controller)나 MVVM(Model-View-ViewModel)과 같은 아키텍처 패턴을 사용하고, 비동기 처리, 네트워킹, 로컬 데이터베이스 활용, 앱 생명주기 관리 등 현대적인 애플리케이션 개발의 공통된 패러다임을 따른다.27

그러나 이들의 가장 큰 차이는 ‘통제’와 ‘자유’라는 철학적 지향점에서 비롯된다. Android의 HAL과 같은 계층적 추상화 설계는 다양한 하드웨어 제조사들에게 자사 제품에 맞게 OS를 수정하고 최적화할 수 있는 ‘자유’를 부여했다. 이는 Android 생태계가 폭발적으로 성장하는 원동력이었지만, 동시에 제조사별로 파편화(fragmentation)가 발생하고 보안 업데이트가 지연되는 문제의 원인이 되기도 했다.

반면, iOS의 수직적 통합 아키텍처는 하드웨어부터 소프트웨어, 앱 스토어까지 모든 요소를 Apple이 강력하게 ‘통제’함으로써 일관된 사용자 경험, 높은 수준의 보안, 그리고 최적화된 성능을 보장한다.12 엄격한 App Store 심사 과정은 악성 코드로부터 사용자를 보호하는 강력한 방어선 역할을 하지만, 개발자에게는 더 많은 제약으로 작용하기도 한다.27

결국, Android의 아키텍처는 ‘수평적 확장’을 통한 생태계 확장을, iOS의 아키텍처는 ‘수직적 통합’을 통한 경험의 질적 향상을 지향하도록 설계되었다. 이 근본적인 차이는 개발자에게는 유연성과 제약 사이의 트레이드오프를, 사용자에게는 다양성과 안정성 사이의 선택지를 제공하며 오늘날의 모바일 시장을 형성하고 있다.

엔터프라이즈 환경의 심장부인 서버는 24시간 365일 안정적인 운영을 보장해야 하며, 이를 뒷받침하는 서버 운영체제는 안정성, 보안, 성능이 무엇보다 중요하다. 이 시장은 주로 Linux와 Windows Server가 양분하고 있다.

Linux는 서버 운영체제 시장에서 사실상의 표준으로 자리 잡았다. 그 이유는 여러 측면에서 찾을 수 있다.

• 비용 효율성: 대부분의 Linux 배포판은 라이선스 비용 없이 무료로 사용할 수 있으며, Red Hat이나 SUSE와 같은 기업에서 제공하는 상용 기술 지원 구독 서비스도 일반적으로 Windows Server 라이선스에 비해 비용 효율적이다.28
• 안정성 및 신뢰성: Linux는 중단 없는 서버 운영을 보장하는 높은 안정성으로 정평이 나 있다. 수많은 개발자와 기업에 의해 지속적으로 업데이트되며 견고함을 유지한다.8
• 보안성: 다중 사용자 시스템을 기반으로 설계된 강력한 파일 권한 및 프로세스 관리 모델은 근본적으로 높은 보안 수준을 제공한다. 또한 소스 코드가 공개되어 있어 전 세계 개발자들이 보안 취약점을 신속하게 발견하고 패치를 공유하므로, 상용 OS에 비해 오히려 더 안전하다는 평가를 받는다.8
• 성능 및 유연성: 커널 수준까지 사용자가 직접 수정하고 최적화할 수 있어, 특정 워크로드에 맞춰 고도로 맞춤화된 시스템을 구축할 수 있다. 비교적 낮은 사양의 하드웨어에서도 높은 성능을 발휘할 수 있다는 장점도 있다.8

다만, 대부분의 관리가 명령줄 인터페이스(CLI)를 통해 이루어지기 때문에, GUI 환경에 익숙한 관리자에게는 학습 곡선이 다소 가파를 수 있다는 점이 단점으로 지적되기도 한다.28

Windows Server는 Microsoft가 개발한 서버용 운영체제로, 특히 기존에 Microsoft 제품군을 중심으로 IT 인프라를 구축한 기업 환경에서 강력한 입지를 가지고 있다.

• 사용자 친화성: PC용 Windows와 유사한 GUI를 제공하여, Linux의 CLI에 익숙하지 않은 관리자도 비교적 쉽게 서버를 설정하고 운영할 수 있다.28
• 생태계 통합: Active Directory를 통한 사용자 및 정책 중앙 관리, Exchange Server, SQL Server 등 다른 Microsoft 제품과의 원활하고 강력한 통합은 Windows Server의 가장 큰 장점이다. 이는 기업 내 IT 인프라 관리의 일관성과 효율성을 크게 높여준다.28
• 포괄적 지원: Microsoft로부터 직접적이고 포괄적인 기술 지원 서비스를 받을 수 있어, 문제 발생 시 신속한 해결을 기대할 수 있다.28
• 상용 애플리케이션 호환성: ASP.NET으로 개발된 웹 애플리케이션이나 특정 Windows 전용 상용 소프트웨어를 운영해야 하는 경우, Windows Server는 필수적인 선택지다.8

그러나 서버 및 사용자 수에 따라 부과되는 라이선스 비용이 고가이며, 보안 취약점이 발견되었을 때 공식 패치가 배포되기까지 상대적으로 시간이 걸릴 수 있다는 단점이 있다.8

서버 운영체제의 선택은 단순한 기술적 우위 비교를 넘어, 조직의 비즈니스 전략과 직결되는 중요한 의사결정이다. 어떤 OS가 더 적합한지는 조직의 규모, 예산, 보유 인력의 기술 역량, 그리고 기존 IT 인프라 환경에 따라 달라진다.

예를 들어, IT 전문 인력이 부족하거나 소규모인 기업, 혹은 이미 사내 업무 시스템이 Microsoft 제품군을 중심으로 구성된 경우에는 관리의 용이성과 생태계 통합성을 고려하여 Windows Server를 선택하는 것이 더 합리적일 수 있다.28

반면, 대규모 IT 인프라를 직접 운영하며 TCO(총소유비용) 절감을 추구하고, 특정 워크로드에 대한 고도의 최적화와 강력한 보안이 필요한 기업이라면 Linux가 더 나은 선택이 될 것이다.28 웹 서비스, 클라우드 인프라, 빅데이터 처리 등 현대적인 IT 워크로드 대부분이 Linux 환경을 기반으로 발전해왔다는 점도 중요한 고려사항이다.

결국 서버 OS의 선택은 기술 스펙 자체보다 조직의 비즈니스 목표와 운영 역량이라는 더 큰 틀 안에서 이루어지는 전략적 결정이라 할 수 있다.

실시간 운영체제(Real-Time Operating System, RTOS)는 일반적인 운영체제와 달리 ‘시간’이라는 제약을 가장 중요한 가치로 삼는 특수 목적 운영체제다.

RTOS의 핵심은 단순히 ‘빠른’ 시스템이 아니라 ‘예측 가능한’ 시스템을 만드는 데 있다. 즉, 특정 작업이 요청되었을 때, 정해진 시간 제약(deadline, 마감 시간) 내에 반드시 결과를 보장해야 한다.4 시스템의 평균 응답 속도보다 중요한 것은, 어떠한 상황에서도 최악의 경우(worst-case) 응답 시간이 마감 시간을 넘지 않을 것이라는 보장, 즉 시간 결정성(determinism)과 예측 가능성(predictability)이다.31

이러한 시간 제약의 엄격성에 따라 RTOS는 다음과 같이 분류된다.

• 경성 실시간 시스템 (Hard Real-Time System): 마감 시간을 단 한 번이라도 어기는 것이 시스템 전체의 치명적인 실패로 이어지는 시스템이다. 마감 시간을 넘긴 결과는 아무런 가치가 없다. 무기 제어 시스템, 발전소 제어, 항공기 자동 항법 장치, 미사일 자동 조준 등이 이에 해당한다.4
• 연성 실시간 시스템 (Soft Real-Time System): 마감 시간을 지키는 것이 중요하지만, 가끔 어기더라도 시스템 전체에 치명적인 영향을 주지는 않는 시스템이다. 마감 시간을 넘긴 결과는 가치가 떨어질 뿐, 완전히 무의미하지는 않다. 동영상 스트리밍이나 온라인 게임에서 발생하는 일시적인 끊김 현상이 대표적인 예다.4
• 준경성 실시간 시스템 (Firm Real-Time System): 경성과 연성의 중간 형태로, 마감 시간을 넘긴 결과는 무의미해져 버려지지만, 그 실패가 시스템 전체에 치명적인 재앙을 초래하지는 않는 경우를 말한다.34

RTOS가 시간 결정성을 보장하기 위해 사용하는 핵심 기술이 바로 실시간 스케줄링 알고리즘이다. 여러 태스크(task) 중 어떤 것을 먼저 실행할지 결정하여 모든 태스크가 각자의 마감 시간을 지키도록 만드는 것이 목표다.

• Rate-Monotonic Scheduling (RMS): 정적 우선순위(static priority) 스케줄링의 대표적인 알고리즘이다. 시스템이 시작될 때 각 태스크의 주기를 분석하여, 주기가 짧은 태스크(즉, 더 자주 실행되어야 하는 태스크)에 영구적으로 높은 우선순위를 할당한다.35 이 방식의 스케줄링 가능성(schedulability)을 판단하는 충분 조건은 N개의 태스크에 대한 총 CPU 이용률($U$)이 특정 경계값을 넘지 않는 것이다. \(\sum_{i=1}^{N} \frac{C_i}{T_i} \le N(2^{1/N} - 1)\) 여기서 $C_i$는 태스크 i의 최악 실행 시간(WCET), $T_i$는 주기이다. 태스크의 수가 무한히 많아질 때 이 경계값은 $\ln(2) \approx 0.693$에 수렴한다. 즉, 총 CPU 사용률이 약 69% 이하라면 RMS는 모든 태스크의 마감 시간을 보장할 수 있다.36

• Earliest-Deadline-First (EDF): 동적 우선순위(dynamic priority) 스케줄링의 대표적인 알고리즘이다. 실행 가능한 태스크들 중에서 마감 시간이 가장 임박한 태스크에 실시간으로 가장 높은 우선순위를 부여한다.38 EDF는 선점형 단일 프로세서 환경에서 이론적으로 최적(optimal)인 스케줄링 알고리즘으로 알려져 있다. EDF의 스케줄링 가능 조건은 매우 간단하다. \(\sum_{i=1}^{N} \frac{C_i}{T_i} \le 1\) 이는 총 CPU 이용률이 100%를 넘지 않는 한, EDF는 모든 태스크의 마감 시간을 보장할 수 있다는 것을 의미한다. RMS보다 더 높은 CPU 활용률을 달성할 수 있다는 큰 장점이 있다.40

구분	Rate-Monotonic Scheduling (RMS)	Earliest-Deadline-First (EDF)
우선순위 유형	정적 우선순위 (Static Priority) - 주기가 짧을수록 높음	동적 우선순위 (Dynamic Priority) - 마감일이 가까울수록 높음
최적성	정적 우선순위 알고리즘 중 최적 35	동적 우선순위 알고리즘 중 최적 41
CPU 이용률 한계	$U \le N(2^{1/N} - 1)$ 35	$U \le 1$ 37
스케줄링 가능성	이용률이 약 69% 이하일 때 보장 37	이용률이 100% 이하일 때 보장 40
과부하 시 동작	우선순위가 낮은 태스크부터 실패하여 예측 가능 41	어떤 태스크가 실패할지 예측하기 어려움 41
구현 복잡성	상대적으로 간단	우선순위가 동적으로 변해 상대적으로 복잡

VxWorks는 Wind River Systems가 개발한 대표적인 상용 RTOS로, 항공우주, 국방, 산업 자동화, 의료 기기 등 극도의 신뢰성이 요구되는 미션 크리티컬(mission-critical) 시스템 분야에서 수십 년간 표준으로 사용되어 왔다.42 선점형 실시간 커널을 기반으로 네트워킹과 파일 시스템 등 풍부한 기능을 내장하고 있으며, 모듈화된 아키텍처를 통해 유지보수와 확장이 용이하다.34

이러한 시스템에서 운영체제의 작은 오류는 수조 원 규모의 프로젝트 실패나 인명 손실과 같은 재앙적인 결과로 이어질 수 있다. VxWorks가 NASA의 화성 탐사 로버(Curiosity, Mars 2020), 제임스 웹 우주 망원경, F-35 전투기, 보잉 787 드림라이너 등 실패가 용납되지 않는 수많은 프로젝트에 채택될 수 있었던 이유는 단순한 기술적 성능 때문만이 아니다.43 그보다는 수많은 미션 크리티컬 프로젝트를 통해 수십 년간 축적된 ‘신뢰성’과, 항공 분야의 DO-178C와 같은 엄격한 ‘안전 표준 인증’을 획득했다는 사실이 더 중요하다.46 미션 크리티컬 시스템에서 RTOS는 단순히 기능을 구현하는 도구를 넘어, 시스템 전체의 신뢰도를 보증하는 핵심 자산 그 자체인 것이다.

QNX는 BlackBerry가 소유한 UNIX 호환 RTOS로, 마이크로커널 아키텍처를 채택한 것으로 유명하다.34 이 아키텍처는 운영체제의 핵심 기능만을 커널에 남기고, 디바이스 드라이버, 파일 시스템, 네트워크 스택 등을 사용자 공간의 독립된 서버 프로세스로 격리한다. 만약 드라이버 하나에 오류가 발생하더라도 커널이나 다른 서비스에 영향을 주지 않고 해당 프로세스만 재시작하면 되므로 시스템 전체의 안정성과 가용성이 극적으로 향상된다. 이는 ‘간섭으로부터의 자유(Freedom from Interference)’라는 개념으로, QNX의 안정성을 설명하는 핵심 원리다.49

이러한 구조적 안정성 덕분에 QNX는 자동차 산업에서 요구하는 기능 안전 표준인 ISO 26262의 가장 높은 등급인 ASIL D(Automotive Safety Integrity Level D) 사전 인증을 획득했다.50 자동차 제조사들은 QNX를 기반으로 첨단 운전자 지원 시스템(ADAS), 디지털 콕핏, 자율주행 제어기 등 안전이 필수적인 시스템을 개발함으로써, 복잡하고 비용이 많이 드는 안전 인증 과정을 크게 단축할 수 있다.49 또한 QNX의 강력한 격리 기능은 인포테인먼트와 같은 비안전(non-safety-critical) 기능과 ADAS와 같은 안전 필수(safety-critical) 기능을 동일한 고성능 칩(SoC) 위에서 안정적으로 동시에 실행하는 ‘혼합 중요도 시스템(Mixed-criticality systems)’을 가능하게 하는 핵심 기술로 작용한다.49

임베디드 시스템은 특정 기능을 수행하기 위해 기기에 내장되는 컴퓨터 시스템으로, 제한된 CPU 성능, 작은 메모리, 저전력이라는 자원 제약 환경에서 동작하는 경우가 많다.52 이러한 환경을 위해 특화된 운영체제가 바로 임베디드 운영체제다.

임베디드 운영체제는 크게 임베디드 Linux와 경량 RTOS로 나눌 수 있다.

• 임베디드 Linux: 데스크톱 및 서버용 Linux 커널을 기반으로 불필요한 기능을 제거하고 특정 하드웨어에 맞게 최적화한 운영체제다. 풍부한 기능과 드라이버, 강력한 네트워킹 스택, 방대한 오픈소스 생태계를 그대로 활용할 수 있다는 장점이 있지만, RTOS에 비해서는 상대적으로 메모리 사용량이 크고 실시간성을 완벽하게 보장하기 어렵다는 한계가 있다.
• RTOS (FreeRTOS, Zephyr 등): 매우 작은 메모리 공간(small-footprint)을 차지하도록 설계된 실시간 운영체제다. 멀티스레딩, 스케줄링, 인터럽트 처리 등 실시간 동작에 필수적인 핵심 기능만을 제공한다.52
  • Zephyr: Linux 재단이 주관하는 오픈 소스 RTOS 프로젝트로, 특히 사물 인터넷(IoT) 환경을 겨냥하고 있다. Bluetooth 5.0, 저전력 기능 등을 지원하며, Linux의 디바이스 트리(device tree) 개념을 차용하는 등 고급 기능을 제공한다. 하지만 추상화 수준이 높고 구성이 복잡하여 학습 곡선이 가파르다는 평가를 받는다.53
  • FreeRTOS: 매우 가볍고 기본적인 RTOS 기능을 제공하며, 구조가 간단하여 다양한 마이크로컨트롤러에 이식하기 쉽다. 이 덕분에 전 세계적으로 가장 널리 사용되는 RTOS 중 하나가 되었다.53

Yocto Project는 특정 임베디드 Linux 배포판이 아니다. 이는 개발자가 특정 하드웨어와 요구사항에 완벽하게 부합하는 자신만의 맞춤형 임베디드 Linux를 ‘만들기 위한’ 강력한 프레임워크이자 도구의 집합이다.55

과거의 임베디드 Linux 개발이 수많은 수작업과 복잡한 스크립트에 의존하여 빌드 환경을 재현하기 어렵고 유지보수가 힘들었다면, Yocto는 이 과정을 표준화하고 자동화함으로써 ‘소프트웨어 공학’의 영역으로 끌어올렸다. Yocto는 ‘재현성’, ‘모듈성’, ‘재사용성’이라는 소프트웨어 공학의 핵심 원칙을 OS 개발에 적용한다. 이는 OS를 만드는 ‘제품’이 아니라, OS를 만드는 체계적인 ‘프로세스’를 제공하는 패러다임의 전환이라 할 수 있다. Yocto의 핵심 구성요소는 다음과 같다.55

• BitBake: Yocto의 빌드 엔진. Python으로 작성되었으며, 레시피 파일들을 해석하여 소스 코드 다운로드, 패치 적용, 컴파일, 패키징, 최종 이미지 생성에 이르는 복잡한 빌드 과정을 순서에 맞게 자동으로 실행한다.55
• Recipes (레시피): 특정 소프트웨어 패키지(예: BusyBox, GStreamer)를 빌드하는 방법에 대한 상세한 지침이 담긴 메타데이터 파일이다. 소스 코드의 위치, 적용할 패치, 의존성, 컴파일 옵션 등이 정의되어 있다.55
• Layers (레이어): 관련된 레시피들의 집합을 담는 저장소다. Yocto는 레이어 개념을 통해 빌드 구성을 모듈화한다. 예를 들어, 하드웨어 종속적인 코드는 ‘BSP(Board Support Package) 레이어’에, GUI 관련 패키지들은 ‘GUI 레이어’에, 특정 애플리케이션은 ‘애플리케이션 레이어’에 분리하여 관리할 수 있다. 이를 통해 특정 하드웨어나 기능에 대한 지원을 쉽게 추가하거나 제거할 수 있어 재사용성과 유지보수성이 극대화된다.55

이러한 구조 덕분에 Yocto는 재현 가능한 빌드(reproducible builds), 소프트웨어 라이선스 준수 관리, 포괄적인 생태계 활용 등 다양한 장점을 제공하며, 복잡한 임베디드 시스템 개발의 생산성을 획기적으로 향상시켰다.58

메인프레임 컴퓨터는 수십 년간 금융, 보험, 정부, 유통 등 사회 핵심 인프라의 중추적인 역할을 담당해왔다. 이러한 시스템의 심장에는 궁극의 안정성과 보안, 그리고 대규모 트랜잭션 처리 능력을 제공하는 메인프레임 운영체제가 있다.

z/OS는 IBM의 메인프레임 컴퓨터(IBM Z)에서 실행되는 대표적인 운영체제다. 24시간 365일 무중단 운영을 목표로 설계되었으며, 대규모 온라인 트랜잭션 처리(OLTP)와 배치(batch) 작업을 동시에 안정적으로 수행할 수 있다. z/OS가 금융권과 같이 신뢰성이 최우선인 분야에서 여전히 핵심적인 역할을 하는 가장 큰 이유는 바로 ‘보안’에 있다.59 z/OS의 보안은 특정 소프트웨어나 기능에 국한되지 않고, 하드웨어 프로세서 레벨부터 운영체제, 미들웨어, 애플리케이션에 이르기까지 모든 계층에 걸쳐 다층적으로 구현되어 있다. RACF(Resource Access Control Facility)와 같은 정교한 접근 제어 시스템은 사용자가 허가된 자원에만 접근할 수 있도록 엄격하게 통제하며, 강력한 암호화 하드웨어와 연동하여 데이터를 보호한다.59

수많은 사용자가 동시에 시스템에 접속하여 계좌 조회, 이체, 결제 등 수많은 거래를 요청하는 금융 시스템 환경에서는 이러한 트랜잭션을 빠르고 안정적으로 처리하는 것이 무엇보다 중요하다. z/OS 환경에서는 CICS와 IMS라는 강력한 트랜잭션 처리 미들웨어가 이 역할을 담당한다.

• CICS (Customer Information Control System): z/OS 상에서 동작하는 온라인 트랜잭션 관리자다. 수천, 수만 명의 사용자가 동시에 요청하는 트랜잭션들이 서로 충돌 없이, 데이터의 무결성을 유지하며, 빠른 응답 시간 내에 처리될 수 있도록 자원 공유와 실행 순서를 관리한다.60 CICS의 핵심 개념은 ‘트랜잭션의 원자성(Atomicity)’이다. 트랜잭션은 ‘모두 실행되거나, 아니면 모두 실행되지 않아야 하는(all or nothing)’ 논리적인 단일 작업 단위(Unit of Work)로 취급된다. 예를 들어 계좌 이체라는 트랜잭션은 ‘A 계좌에서 출금’과 ‘B 계좌로 입금’이라는 두 개의 작업으로 구성되는데, 만약 출금 후 시스템에 장애가 발생하여 입금이 실패하면, CICS는 이미 완료된 출금 작업까지 자동으로 취소(rollback)하여 데이터의 일관성을 완벽하게 보장한다.60
• IMS (Information Management System): CICS와 마찬가지로 대규모 트랜잭션을 처리하는 미들웨어로, 트랜잭션 관리자(TM) 기능과 함께 계층형 데이터베이스 관리자(DB) 기능을 통합하여 제공하는 것이 특징이다.61 IMS는 수십 년간 축적된 안정성과 성능을 바탕으로 핵심 업무를 처리하며, 최근에는 RESTful API 지원 등을 통해 현대적인 하이브리드 클라우드 환경과 유연하게 통합될 수 있도록 발전하고 있다.62

고성능 컴퓨팅(High-Performance Computing, HPC)은 기상 예측, 유전자 분석, 신약 개발, 물리 시뮬레이션 등 방대한 양의 계산을 요구하는 과학 및 공학 분야의 문제를 해결하기 위한 컴퓨팅 기술이다. 수백에서 수천 개의 컴퓨팅 서버(노드)를 고속 네트워크로 연결한 클러스터 환경에서 병렬 계산을 수행하는 것이 일반적이다.64

현대 HPC 환경에서 운영체제는 사실상 Linux의 독무대다. 전 세계에서 가장 빠른 슈퍼컴퓨터 순위를 매기는 TOP500 리스트에 등재된 모든 시스템이 Linux를 운영체제로 사용하고 있다.64 Linux가 HPC 분야를 지배하게 된 이유는 명확하다.

• 개방성과 유연성: 오픈 소스인 Linux는 특정 하드웨어나 워크로드에 맞춰 커널 수준까지 자유롭게 수정하고 최적화할 수 있다. 이는 최첨단 하드웨어를 사용하는 HPC 환경에서 성능을 극한까지 끌어올리는 데 필수적이다.65
• 비용 효율성: 라이선스 비용이 없어 대규모 클러스터를 구축하는 데 드는 초기 비용을 크게 절감할 수 있다.29
• 생태계: 수많은 과학 계산용 소프트웨어, 병렬 프로그래밍 라이브러리, 개발 도구들이 Linux 환경을 중심으로 개발되고 공유되어 강력한 생태계를 형성하고 있다.

HPC 환경에서는 안정적인 장기 지원과 기술 서비스를 제공하는 상용 Linux 배포판이 주로 사용된다. 그중 Red Hat Enterprise Linux(RHEL)와 SUSE Linux Enterprise Server(SLES)가 대표적이다. 두 배포판 모두 RPM 패키지 관리 시스템을 기반으로 하며, 엔터프라이즈급 보안과 지원을 제공한다는 공통점이 있다.66

• Red Hat Enterprise Linux (RHEL): 상용 Linux 시장의 선두주자로, 오랜 기간 축적된 안정성과 폭넓은 하드웨어 및 소프트웨어 인증을 자랑한다. Red Hat은 OpenShift(컨테이너 플랫폼), Ansible(자동화 도구) 등 자사의 광범위한 클라우드 및 자동화 포트폴리오와의 긴밀한 통합을 통해 ‘클라우드-HPC 융합’ 생태계를 지향한다.68
• SUSE Linux Enterprise (SLES) for HPC: YaST와 같은 강력한 통합 시스템 관리 도구를 제공하여 복잡한 클러스터 환경의 설정과 관리가 용이하다는 장점이 있다.69 특히 인메모리 데이터베이스인 SAP HANA 환경에서 최적의 성능을 제공하는 것으로 알려져 있으며, 시스템 업데이트 후 문제가 발생했을 때 이전 상태로 쉽게 되돌릴 수 있는 스냅샷 및 롤백 기능(snapper)이 뛰어나다.66 또한 워크로드 매니저, 성능 모니터링 툴 등을 포함한 HPC 전용 모듈을 제공하여 HPC 환경 구축을 용이하게 한다.71

이 두 배포판의 선택은 단순히 기술적 우위를 넘어, 각 기업이 추구하는 ‘기술 생태계’와 ‘관리 철학’의 차이를 반영한다. RHEL은 Red Hat의 광범위한 하이브리드 클라우드 생태계와의 연동성을 중시하는 반면, SUSE는 단일 시스템 및 클러스터 자체의 관리 용이성과 안정성에 더 집중하는 경향을 보인다.

HPC 클러스터의 성능은 운영체제뿐만 아니라, 노드들을 연결하는 네트워크와 데이터를 저장하는 파일 시스템의 성능에 크게 좌우된다.

• 고속 인터커넥트 (InfiniBand): 수천 개의 노드가 서로 데이터를 주고받을 때 발생하는 통신 병목 현상을 해결하기 위한 초고속, 초저지연 네트워크 기술이다. 특히 RDMA(Remote Direct Memory Access) 기술을 통해 운영체제 커널을 거치지 않고 한 노드의 애플리케이션이 다른 노드의 메모리에 직접 데이터를 읽고 쓸 수 있게 하여, 통신 지연 시간을 획기적으로 줄이고 CPU 부하를 최소화한다.72 RHEL, SLES와 같은 엔터프라이즈 Linux는 InfiniBand 하드웨어를 위한 드라이버 스택(예: MLNX_OFED)과 관리 도구를 완벽하게 지원한다.73
• 병렬 파일 시스템 (Lustre): 수천 개의 노드가 동시에 하나의 거대한 파일에 접근하여 읽고 쓰는 병렬 I/O 작업을 효율적으로 처리하기 위해 설계된 분산 파일 시스템이다. 파일의 메타데이터(이름, 위치, 권한 등)를 관리하는 메타데이터 서버(MDS)와 실제 데이터 블록을 저장하는 다수의 객체 스토리지 서버(OSS)로 구조를 분리하여, 메타데이터 연산과 데이터 I/O가 서로 간섭 없이 병렬로 처리되도록 함으로써 엄청난 I/O 대역폭을 제공한다.74
• 워크로드 매니저 (Slurm): 대규모 클러스터의 한정된 컴퓨팅 자원을 여러 사용자 및 작업 그룹에게 공정하고 효율적으로 할당하고 스케줄링하는 핵심 소프트웨어다. 사용자가 작업을 제출하면, Slurm은 현재 클러스터의 자원 상황을 파악하여 작업을 대기 큐에 넣거나, 가용한 노드에 할당하여 실행시킨다.76 Slurm은 cgroups와 같은 Linux 커널의 자원 제어 기능을 활용하여 각 작업이 할당된 CPU 코어와 메모리 양을 초과하지 않도록 격리하고 제어한다.78

컴퓨팅 환경이 물리 서버에서 가상머신을 거쳐 컨테이너와 서버리스로 진화하고, 워크로드가 범용 작업에서 대규모 AI 학습과 같은 전문화된 작업으로 변화함에 따라 운영체제의 역할과 구조 또한 근본적인 변화를 맞이하고 있다.

클라우드 네이티브는 애플리케이션을 처음부터 클라우드 환경의 유연성, 확장성, 복원력을 최대한 활용할 수 있도록 설계하고 운영하는 접근 방식이다.79 이 패러다임의 핵심에는 컨테이너 기술이 있다.

컨테이너는 가상머신(VM)처럼 독립적인 운영체제를 통째로 실행하는 대신, 호스트 운영체제(Host OS)의 커널을 다른 컨테이너들과 공유한다. 그러면서도 각 컨테이너는 마치 독립된 서버처럼 자신만의 격리된 환경을 갖는다. 이는 Host OS인 Linux 커널이 제공하는 두 가지 핵심 기능, 즉 ‘프리미티브(primitive)’ 덕분에 가능하다.80

1. Namespaces: 하나의 시스템을 여러 개의 가상 시스템으로 보이게 하는 논리적인 격벽을 제공한다. 예를 들어, PID 네임스페이스는 컨테이너 내부의 프로세스가 자신만의 독립적인 프로세스 ID(PID 1부터 시작)를 갖게 하고, 네트워크 네임스페이스는 컨테이너가 자신만의 독립적인 네트워크 인터페이스와 IP 주소를 갖도록 격리한다.81
2. cgroups (Control Groups): 특정 프로세스 그룹이 사용할 수 있는 시스템 자원의 양을 제한하고 격리하는 기능이다. 예를 들어, 특정 컨테이너가 CPU 시간의 50%와 1GB의 메모리만 사용하도록 제한을 걸 수 있다. 이를 통해 하나의 컨테이너가 시스템의 모든 자원을 독점하여 다른 컨테이너의 성능에 영향을 미치는 것을 방지한다.80

이러한 변화는 운영체제의 역할을 재정의하고 있다. 과거 OS가 애플리케이션의 실행과 자원 관리를 총괄하는 ‘최종 관리자’였다면, 클라우드 네이티브 시대의 OS는 Kubernetes와 같은 상위 오케스트레이션 플랫폼이 애플리케이션을 효율적으로 관리할 수 있도록 cgroups, namespaces와 같은 저수준의 핵심 기능(프리미티브)을 API 형태로 제공하는 ‘기반 기술 플랫폼’으로 변화하고 있다. 즉, OS의 기능은 더 잘게 분해되고, 상위 플랫폼에 의해 필요에 따라 재조합되어 사용되는 것이다.

수천, 수만 개의 컨테이너를 수동으로 배포하고 관리하는 것은 불가능하다. Kubernetes는 이렇게 컨테이너화된 애플리케이션의 배포, 확장, 장애 복구, 네트워킹 등을 자동화하는 사실상의 표준 컨테이너 오케스트레이션 시스템이다.79 Kubernetes는 OS가 제공하는 컨테이너 프리미티브를 기반으로, 여러 노드에 걸쳐 컨테이너를 지능적으로 배치(스케줄링)하고, 서비스의 상태를 지속적으로 모니터링하며, 문제가 발생하면 자동으로 복구하는 등 고차원적인 관리 기능을 수행한다.

대규모 언어 모델(LLM)과 같은 현대 AI 모델의 등장은 컴퓨팅 패러다임을 CPU 중심에서 GPU와 같은 가속기 중심으로 바꾸고 있으며, 이는 운영체제에 새로운 도전과제를 제기하고 있다.

대규모 AI 모델 학습은 수백, 수천 개의 GPU를 사용하는 거대한 분산 클러스터에서 수 주에서 수 개월에 걸쳐 진행된다. 이 과정에서 예측 불가능한 하드웨어 고장, GPU 메모리 부족(Out-of-Memory, OOM), 비효율적인 GPU 자원 활용, 노드 간 통신 병목 등 다양한 문제가 발생하며, 이는 막대한 시간과 비용 낭비로 이어진다.82

전통적인 운영체제는 CPU와 시스템 메모리 관리에 최적화되어 있어, 수많은 코어를 가진 GPU의 내부 아키텍처나 대규모 병렬 워크로드의 특성을 제대로 이해하지 못한다. 이로 인해 GPU 자원을 효율적으로 스케줄링하고, CPU-GPU 간 데이터 전송을 최적화하며, 여러 AI 작업을 격리하여 실행하는 데 한계를 보인다.85

이러한 한계를 극복하기 위해 운영체제 커널 수준에서부터 AI 워크로드를 지원하려는 연구가 활발히 진행되고 있다.

• OS 커널 연구 동향: 현재의 연구는 단순히 드라이버를 개선하는 수준을 넘어, 운영체제 커널의 근본적인 구조를 재설계하는 방향으로 나아가고 있다. GPU를 더 이상 주변 장치가 아닌, CPU와 동등한 ‘일급 시민(first-class citizen)’으로 취급하여 OS 커널이 직접 GPU의 메모리 관리(스와핑, 공유), 태스크 스케줄링, 컨텍스트 간 통신(IPC)을 담당하도록 하는 연구(예: Gdev)가 대표적이다.87 더 나아가, 부동소수점 연산 가속, AI 워크로드의 특성을 이해하는 ML-Aware 스케줄러, CPU-GPU 간 제로카피(zero-copy) 메모리 관리와 같은 기능들을 커널에 내장하는 ‘AI-네이티브 OS’라는 새로운 아키텍처 개념도 제안되고 있다.88 이는 컴퓨팅 패러다임의 근본적인 변화가 운영체제의 구조적 진화를 이끌어내는 역사적 흐름을 보여준다.
• NVIDIA MIG (Multi-Instance GPU): 하드웨어 수준에서 이 문제를 해결하려는 접근 방식도 있다. NVIDIA의 MIG 기술은 Ampere 아키텍처 이상의 고성능 GPU를 물리적으로 최대 7개의 독립적인 GPU 인스턴스로 분할하는 기능이다. 각 인스턴스는 완전히 격리된 메모리, 캐시, 컴퓨팅 코어를 가지므로, 여러 개의 작은 AI 추론 작업이나 개발 작업을 하나의 GPU에서 서로 간섭 없이 동시에 실행할 수 있다.89 OS와 CUDA 애플리케이션 입장에서는 각 MIG 인스턴스가 별개의 물리적 GPU처럼 보이므로, 기존 소프트웨어 변경 없이도 GPU 자원의 활용률과 격리 수준을 높일 수 있다.90

클라우드 네이티브 환경에서 AI 워크로드를 실행하기 위해, Kubernetes는 GPU와 같은 특수 하드웨어를 인식하고 스케줄링할 수 있도록 다양한 확장 메커니즘을 제공한다.

• Device Plugin: NVIDIA, AMD 등 하드웨어 벤더가 제공하는 핵심 플러그인이다. 각 노드에 설치되어 해당 노드의 GPU 자원을 감지하고, 이를 Kubernetes API 서버에 보고한다. 사용자가 Pod 명세에 GPU를 요청하면, Kubelet은 Device Plugin을 통해 컨테이너에 GPU 장치를 할당하고 필요한 드라이버 라이브러리를 마운트해준다.92
• NFD (Node Feature Discovery): 클러스터 내의 각 노드가 어떤 종류의 GPU(예: NVIDIA A100, H100)를 가지고 있는지, 어떤 CPU 아키텍처인지 등 구체적인 하드웨어 사양을 자동으로 감지하여 노드에 레이블(label)로 붙여주는 역할을 한다. 사용자는 이 레이블을 활용하여 nodeSelector나 nodeAffinity와 같은 Kubernetes 스케줄링 기능을 통해 “A100 GPU가 장착된 노드에만 이 작업을 배치하라”와 같이 정교한 스케줄링 정책을 구현할 수 있다.92
• GPU Operator: GPU를 사용하기 위해 필요한 모든 구성요소(NVIDIA 드라이버 설치, Device Plugin 배포, 컨테이너 런타임 설정, 모니터링 도구 등)의 설치와 생명주기 관리를 자동화하는 도구다. 관리자는 복잡한 수동 설정 과정 없이 Operator를 통해 클러스터 전체의 GPU 환경을 일관되게 관리할 수 있다.93

지난 수십 년간 운영체제는 변화하는 하드웨어 기술과 애플리케이션 요구사항에 맞춰 끊임없이 진화해왔다. 본 고찰을 통해 분석한 다양한 산업 분야별 운영체제들은 각자의 환경에 최적화된 고유한 아키텍처와 철학을 발전시켜왔음을 확인할 수 있다. 그리고 지금, 우리는 또 한 번의 거대한 패러다임 전환의 중심에 서 있다.

미래 운영체제의 진화 방향을 이끄는 핵심 동인은 다음 세 가지로 요약할 수 있다.

1. 하드웨어의 다양화 (Heterogeneity): 컴퓨팅의 중심이 범용 CPU에서 GPU, NPU, FPGA 등 특정 작업에 특화된 다양한 가속기로 확장되고 있다. 이에 따라 운영체제는 이러한 이기종 하드웨어를 단일 시스템처럼 통합적으로 관리하고 추상화하는 능력이 그 어느 때보다 중요해졌다.
2. 워크로드의 전문화 (Specialization): 범용 컴퓨팅을 넘어 실시간 제어, 대규모 병렬 계산(HPC), AI 모델 학습 및 추론 등 특정 목적에 고도로 최적화된 시스템에 대한 요구가 폭발적으로 증가하고 있다. 이는 각 워크로드의 고유한 특성을 이해하고 지원하는 전문화된 운영체제 기능의 필요성을 증대시킨다.
3. 추상화 수준의 변화 (Abstraction Shift): 컴퓨팅 자원을 사용하는 단위가 물리적 서버에서 가상머신, 컨테이너, 그리고 서버리스 함수로 점차 상위 수준으로 추상화되고 있다. 이에 따라 운영체제의 역할 역시 애플리케이션을 직접 관리하는 주체에서, 상위 플랫폼이 필요로 하는 저수준의 핵심 프리미티브를 제공하는 기반 기술 제공자로 변화하고 있다.

이러한 변화의 흐름 속에서 미래 운영체제가 해결해야 할 핵심 과제는 다음과 같다.

• 이기종 자원 통합 관리: 다양한 종류의 프로세서와 메모리, 네트워크 자원을 효율적으로 통합하고, 애플리케이션이 하드웨어의 복잡성을 인지하지 않고도 최적의 성능을 낼 수 있도록 지능적으로 자원을 할당하고 스케줄링하는 능력이 요구된다.
• AI 네이티브 지원: AI 워크로드, 특히 대규모 딥러닝 모델의 특성을 커널 수준에서부터 이해하고, 데이터 이동, 모델 실행, 자원 할당의 전 과정을 최적화하는 기능이 운영체제에 내장될 것이다. 이는 단순히 드라이버를 제공하는 수준을 넘어, 스케줄러와 메모리 관리자와 같은 커널의 핵심 구성요소가 AI 워크로드에 맞춰 재설계됨을 의미한다.
• 양자 컴퓨팅을 향한 준비: 아직 초기 단계이지만, 미래의 컴퓨팅 패러다임이 될 양자 컴퓨터를 제어하고 관리하기 위한 새로운 운영체제(Quantum Computing Operating System, QCOS)에 대한 연구도 시작되고 있다. 양자 계산의 신뢰성 있는 실행을 보장해야 하는 QCOS의 특성상, 초기 연구에서는 안정성과 모듈성이 뛰어난 마이크로커널 아키텍처가 유력한 후보로 거론되고 있다.94

결론적으로, 운영체제는 하드웨어와 애플리케이션 사이의 정적인 중재자 역할을 넘어, 동적으로 변화하는 컴퓨팅 환경과 워크로드에 지능적으로 적응하고 최적의 기반을 제공하는 능동적인 플랫폼으로 진화하고 있다. 이러한 진화의 방향을 이해하는 것은 미래 기술의 흐름을 예측하고 대비하는 데 있어 필수적인 과제가 될 것이다.

1. [운영체제] 101.운영체제개념 - 개요 및 기능 - 코딩 바다에서의 항해일지, 8월 16, 2025에 액세스, https://makecodework.tistory.com/entry/%EC%9A%B4%EC%98%81%EC%B2%B4%EC%A0%9C-101%EC%9A%B4%EC%98%81%EC%B2%B4%EC%A0%9C%EA%B0%9C%EB%85%90-%EA%B0%9C%EC%9A%94-%EB%B0%8F-%EA%B8%B0%EB%8A%A5
2. 운영체제의 개념과 역할, 구조 - ben_DS - 티스토리, 8월 16, 2025에 액세스, https://bentist.tistory.com/65
3. [운영체제 OS] 운영체제의 개념 Operating System - MYVELOP 마이벨롭 - 티스토리, 8월 16, 2025에 액세스, https://myvelop.tistory.com/167
4. 운영체제(Operating System) 핵심 개념 정리 (1) – Jang, 8월 16, 2025에 액세스, https://wkdtjsgur100.github.io/os-summary/

5. 운영체제의 역사와 커널에 관하여 / 마이크로 커널 세부탐구(완)

   by Seo Minsang

   Medium, 8월 16, 2025에 액세스, https://medium.com/@seominsang/%EC%9A%B4%EC%98%81%EC%B2%B4%EC%A0%9C%EC%9D%98-%EC%97%AD%EC%82%AC%EC%99%80-%EC%BB%A4%EB%84%90%EC%97%90-%EA%B4%80%ED%95%98%EC%97%AC-%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C-%EC%BB%A4%EB%84%90-%EC%84%B8%EB%B6%80%ED%83%90%EA%B5%AC-%EC%99%84-532838074e41

6. 모놀리식 커널과 마이크로 커널 - Smart Tiger’s blog - 티스토리, 8월 16, 2025에 액세스, https://seamless.tistory.com/14
7. 1. 운영체제 구조(2) - SONGANG IT - 티스토리, 8월 16, 2025에 액세스, https://ku320121.tistory.com/177
8. 리눅스(LINUX) vs 윈도우(Windows) - 데이터 엔지니어를 꿈꾸는 Spidy web블로그 - 티스토리, 8월 16, 2025에 액세스, https://spidyweb.tistory.com/69
9. 운영 체제의 차이점 - 원더쉐어 리커버릿, 8월 16, 2025에 액세스, https://recoverit.wondershare.kr/mac-tips/apple-mac-windows-pc-which-is-better.html
10. [Linux] 리눅스와 다른 운영체제 비교(vs Windows, Mac os) - Hi_AI - 티스토리, 8월 16, 2025에 액세스, https://hi-ai0913.tistory.com/3
11. macOS 특징, 8월 16, 2025에 액세스, https://subicura.com/mac/guide/macos-vs-windows.html
12. 모바일 운영체제(예: Android, iOS) - AppMaster, 8월 16, 2025에 액세스, https://appmaster.io/ko/glossary/mobail-unyeongceje-ye-android-ios
13. Android (operating system) - Wikipedia, 8월 16, 2025에 액세스, https://en.wikipedia.org/wiki/Android_(operating_system)
14. 모바일 운영체제 - 나무위키, 8월 16, 2025에 액세스, https://namu.wiki/w/%EB%AA%A8%EB%B0%94%EC%9D%BC%20%EC%9A%B4%EC%98%81%EC%B2%B4%EC%A0%9C

15. Architecture overview

    Android Open Source Project, 8월 16, 2025에 액세스, https://source.android.com/docs/core/architecture

16. Android Architecture - GeeksforGeeks, 8월 16, 2025에 액세스, https://www.geeksforgeeks.org/android/android-architecture/
17. Android Operating System: Mobile Development Explained - Netguru, 8월 16, 2025에 액세스, https://www.netguru.com/glossary/android-operating-system

18. The main components of android architecture are following:-

    by Menkashah - Medium, 8월 16, 2025에 액세스, https://medium.com/@menkashah060/the-main-components-of-android-architecture-are-following-53f84b45a45b

19. Demystifying the Android Architecture: A Comprehensive Guide to Its Components, 8월 16, 2025에 액세스, https://30dayscoding.com/blog/understanding-android-architecture-components
20. 아이폰(iOS) 앱개발 고유의 특징 7가지 (안드로이드 차이, 비교) - 위시켓블로그, 8월 16, 2025에 액세스, https://blog.wishket.com/blog/41466
21. architecture - What iOS layers Foundation and Core Foundation …, 8월 16, 2025에 액세스, https://stackoverflow.com/questions/14990975/what-ios-layers-foundation-and-core-foundation-frameworks-belong-to
22. iOS SDK Architecture - DEV Community, 8월 16, 2025에 액세스, https://dev.to/binoy123/ios-sdk-architecture-3h11
23. Architecture of IOS Operating System - GeeksforGeeks, 8월 16, 2025에 액세스, https://www.geeksforgeeks.org/operating-systems/architecture-of-ios-operating-system/
24. Core Services Layer - Apple Developer, 8월 16, 2025에 액세스, https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/OSX_Technology_Overview/CoreServicesLayer/CoreServicesLayer.html

25. Architecture of IOS Operating System

    PDF

    Ios

    Mobile App - Scribd, 8월 16, 2025에 액세스, https://www.scribd.com/document/735943047/Architecture-of-IOS-Operating-System

26. iOS Architecture - A Comprehensive Guide - Intellipaat, 8월 16, 2025에 액세스, https://intellipaat.com/blog/tutorial/ios-tutorial/ios-architecture/
27. Android와 iOS 개발의 공통점 - 개발린생 - 티스토리, 8월 16, 2025에 액세스, https://blueland99.tistory.com/11
28. 최고의 서버 운영 체제: 2024년에 적합한 서버 OS 선택 - AscentOptics 블로그, 8월 16, 2025에 액세스, https://ascentoptics.com/blog/ko/best-server-operating-systems-choosing-the-right-server-os-in-2024/
29. 윈도우(Window) 대신 리눅스(Linux) 에 서버를 설치하는 이유 - 8ugust의 개발일기, 8월 16, 2025에 액세스, https://8ugust-dev.tistory.com/2
30. [OS] Windows Server vs Linux Server - Haengsin - 티스토리, 8월 16, 2025에 액세스, https://haengsin.tistory.com/59
31. 안드로이드 운영체제에서 실시간 시스템 - 대체로 무해함, 8월 16, 2025에 액세스, https://lethean.github.io/2010/11/19/real-time-on-android-os/
32. 실시간 컴퓨팅 - 위키백과, 우리 모두의 백과사전, 8월 16, 2025에 액세스, https://ko.wikipedia.org/wiki/%EC%8B%A4%EC%8B%9C%EA%B0%84_%EC%BB%B4%ED%93%A8%ED%8C%85
33. [Chapter 5. CPU 스케줄링] 실시간 시스템과 실시간 스케줄링 (RM, EDF), 8월 16, 2025에 액세스, https://eunajung01.tistory.com/67
34. 실시간 운영체제, 8월 16, 2025에 액세스, https://koreascience.kr/article/JAKO199963369850595.pdf
35. 운영체제 6주차, 8월 16, 2025에 액세스, https://diy-multitab.tistory.com/28
36. [Operating System - Chapter 5] CPU 스케줄링, 8월 16, 2025에 액세스, https://imbf.github.io/computer-science(cs)/2020/10/18/CPU-Scheduling.html
37. EL2450 Hybrid and Embedded Control Lecture 7: Real-time scheduling - KTH, 8월 16, 2025에 액세스, https://www.kth.se/social/upload/51136561f2765413ec9a1d6c/lec07_VT13.pdf
38. 실시간 CPU 스케줄링 - Ayaan의 개발블로그, 8월 16, 2025에 액세스, https://ayaan-dev.tistory.com/8

39. Scheduling: Earliest Deadline First

    Baeldung on Computer Science, 8월 16, 2025에 액세스, https://www.baeldung.com/cs/scheduling-earliest-deadline-first

40. Earliest Deadline First (EDF) CPU scheduling algorithm - GeeksforGeeks, 8월 16, 2025에 액세스, https://www.geeksforgeeks.org/operating-systems/earliest-deadline-first-edf-cpu-scheduling-algorithm/
41. Earliest deadline first scheduling - Wikipedia, 8월 16, 2025에 액세스, https://en.wikipedia.org/wiki/Earliest_deadline_first_scheduling
42. 실시간 운영체제 종류 - 김용환 블로그(2004-2020), 8월 16, 2025에 액세스, https://knight76.tistory.com/entry/30001197100
43. VxWorks - Wikipedia, 8월 16, 2025에 액세스, https://en.wikipedia.org/wiki/VxWorks
44. Mastering VxWorks for Embedded Systems - Number Analytics, 8월 16, 2025에 액세스, https://www.numberanalytics.com/blog/mastering-vxworks-for-embedded-systems

45. Customer Success

    Wind River Case Studies, 8월 16, 2025에 액세스, https://www.windriver.com/success-stories

46. VxWorks in Real-Time Systems Development - Number Analytics, 8월 16, 2025에 액세스, https://www.numberanalytics.com/blog/vxworks-in-real-time-systems-development
47. A Comparative Analysis of VxWorks OS and Windows CE in Embedded Real-Time Applications - ResearchGate, 8월 16, 2025에 액세스, https://www.researchgate.net/publication/391651473_A_Comparative_Analysis_of_VxWorks_OS_and_Windows_CE_in_Embedded_Real-Time_Applications
48. RTOS 주요 플레이어, 나에게 필요한 운영체제는? - 테크월드뉴스, 8월 16, 2025에 액세스, https://www.epnc.co.kr/news/articleView.html?idxno=100241

49. Automotive Software

    QNX, 8월 16, 2025에 액세스, https://blackberry.qnx.com/en/industries/connected-autonomous-vehicles

50. QNX OS for Automotive Safety - Gopalam Embedded Systems, 8월 16, 2025에 액세스, https://www.embeddedsingapore.com/products/rtos-and-middleware/qnx/qnx-os-automotive-safety/
51. QNX OS for Safety, 8월 16, 2025에 액세스, https://blackberry.qnx.com/en/products/safety-certified/qnx-os-for-safety
52. NCS (7) - Zephyr OS 주요 특징 - RTOS 와 커널 (Kernel) - 임베디드 개발장이, 8월 16, 2025에 액세스, https://enidanny.github.io/nrf%20connect%20sdk/nRF-Connect-SDK-Zephyr-OS/
53. FreeRTOS vs Zephyr RTOS : r/embedded - Reddit, 8월 16, 2025에 액세스, https://www.reddit.com/r/embedded/comments/ynn5yw/freertos_vs_zephyr_rtos/?tl=ko
54. Zephyr RTOS Project - Linux Kernel Hacks, 8월 16, 2025에 액세스, https://slowbootkernelhacks.blogspot.com/2020/11/zephyr-rtos-project.html
55. Technical Overview - The Yocto Project, 8월 16, 2025에 액세스, https://www.yoctoproject.org/development/technical-overview/
56. The Yocto Project, 8월 16, 2025에 액세스, https://www.yoctoproject.org/
57. What is the Yocto Project? - The Embedded Kit, 8월 16, 2025에 액세스, https://theembeddedkit.io/blog/what-is-the-yocto-project/
58. The Benefits of Leveraging Yocto for Embedded Linux Distribution, 8월 16, 2025에 액세스, https://blog.peridio.com/the-benefits-of-leveraging-yocto-for-embedded-linux-distribution
59. 메인프레임 철통 보안, 더 강화된다 - 보안뉴스, 8월 16, 2025에 액세스, https://www.boannews.com/media/view.asp?idx=7254&page=4207&mkind=1&kind=3
60. CICS - Wikipedia, 8월 16, 2025에 액세스, https://en.wikipedia.org/wiki/CICS
61. Chapter 11: Transaction managers on z/OS CICS and IMS - SlideServe, 8월 16, 2025에 액세스, https://www.slideserve.com/pmckinnon/chapter-11-transaction-managers-on-z-os-cics-and-ims-powerpoint-ppt-presentation
62. Transaction software - IBM Z, 8월 16, 2025에 액세스, https://www.ibm.com/products/z/transactions
63. Chapter 1: Introduction, 8월 16, 2025에 액세스, https://www.microfocus.com/documentation/MainframeExpress/mx31/igarch.htm
64. 고성능 컴퓨팅(HPC)이란? - Red Hat, 8월 16, 2025에 액세스, https://www.redhat.com/ko/topics/high-performance-computing/what-is-high-performance-computing
65. Red Hat Enterprise Linux가 지원하는 고성능 컴퓨팅, 8월 16, 2025에 액세스, https://www.redhat.com/ko/technologies/linux-platforms/enterprise-linux/high-performance-computing
66. RHEL (RedHat) vs SUSE - Which one to choose? Key differences - TheServerHost, 8월 16, 2025에 액세스, https://theserverhost.com/blog/post/rhel-vs-suse-which-one-to-choose-key-differences
67. List of Linux distributions - Wikipedia, 8월 16, 2025에 액세스, https://en.wikipedia.org/wiki/List_of_Linux_distributions
68. What’s the best Linux distro for you? - Red Hat, 8월 16, 2025에 액세스, https://www.redhat.com/en/topics/linux/whats-the-best-linux-distro-for-you
69. difference between suse and red hat - Hewlett Packard Enterprise Community, 8월 16, 2025에 액세스, https://community.hpe.com/t5/operating-system-linux/difference-between-suse-and-red-hat/td-p/4058821
70. Considering Changing from RHEL/Fedora to SUSE/openSUSE - Reddit, 8월 16, 2025에 액세스, https://www.reddit.com/r/openSUSE/comments/19cfm6f/considering_changing_from_rhelfedora_to/

71. Release Notes

    SUSE Linux Enterprise for High-Performance …, 8월 16, 2025에 액세스, https://www.suse.com/releasenotes/x86_64/SLE-HPC/15-SP6/index.html

72. Red Hat Enterprise Linux 9 Configuring InfiniBand and RDMA …, 8월 16, 2025에 액세스, https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/pdf/configuring_infiniband_and_rdma_networks/Red_Hat_Enterprise_Linux-9-Configuring_InfiniBand_and_RDMA_networks-en-US.pdf
73. Linux InfiniBand Drivers, 8월 16, 2025에 액세스, https://network.nvidia.com/products/infiniband-drivers/linux/mlnx_ofed/
74. Performance Evaluation of A Infiniband-based Lustre Parallel File System - ResearchGate, 8월 16, 2025에 액세스, https://www.researchgate.net/publication/257728102_Performance_Evaluation_of_A_Infiniband-based_Lustre_Parallel_File_System
75. High Performance, Open Source, Dell Lustre Storage System Dell /Cambridge HPC Solution Centre, 8월 16, 2025에 액세스, https://i.dell.com/sites/csdocuments/Shared-Content_solutions_Documents/es/ar/lustre-storage-brick-white-paper_la.pdf
76. Install Slurm on Red Hat Enterprise Linux using the Snap Store - Snapcraft, 8월 16, 2025에 액세스, https://snapcraft.io/install/slurm/rhel
77. Frequently Asked Questions - Slurm Workload Manager - SchedMD, 8월 16, 2025에 액세스, https://slurm.schedmd.com/faq.html
78. WEKA and Slurm integration, 8월 16, 2025에 액세스, https://docs.weka.io/best-practice-guides/weka-and-slurm-integration
79. 클라우드네이티브 환경 구현 기술, 8월 16, 2025에 액세스, https://etevers-marketing.com/data/board/202306282039585.pdf
80. Linux Container Primitives: An Introduction to Control Groups - Schutzwerk, 8월 16, 2025에 액세스, https://www.schutzwerk.com/en/blog/linux-container-cgroups-01-intro/
81. Linux Container primitives - Xin Cheng - Medium, 8월 16, 2025에 액세스, https://billtcheng2013.medium.com/linux-container-primitives-91078f490398
82. neptune.ai, 8월 16, 2025에 액세스, https://neptune.ai/blog/learnings-from-teams-training-large-scale-models#:~:text=When%20you’re%20dealing%20with,need%20for%20efficient%20resource%20management.
83. Learnings From Teams Training Large-Scale Models: Challenges and Solutions For Monitoring at Hyperscale - neptune.ai, 8월 16, 2025에 액세스, https://neptune.ai/blog/learnings-from-teams-training-large-scale-models
84. Optimizing Large-Scale AI Model Training - AiThority, 8월 16, 2025에 액세스, https://aithority.com/natural-language/large-scale-ai-model-training-key-challenges-and-innovations/
85. Algorithmic Techniques for GPU Scheduling: A Comprehensive Survey - MDPI, 8월 16, 2025에 액세스, https://www.mdpi.com/1999-4893/18/7/385
86. Deep Learning Workload Scheduling in GPU Datacenters: A Survey - Tianwei Zhang, 8월 16, 2025에 액세스, https://tianweiz07.github.io/Papers/24-csur.pdf
87. Gdev: First-Class GPU Resource Management in the … - USENIX, 8월 16, 2025에 액세스, https://www.usenix.org/system/files/conference/atc12/atc12-final319.pdf
88. Composable OS Kernel Architectures for Autonomous Intelligence - arXiv, 8월 16, 2025에 액세스, https://arxiv.org/html/2508.00604v1
89. NVIDIA Multi-Instance GPU (MIG), 8월 16, 2025에 액세스, https://www.nvidia.com/en-us/technologies/multi-instance-gpu/
90. NVIDIA Multi-Instance GPU User Guide - NVIDIA Docs Hub, 8월 16, 2025에 액세스, https://docs.nvidia.com/datacenter/tesla/pdf/NVIDIA_MIG_User_Guide.pdf
91. MIG Support in OpenShift Container Platform - NVIDIA Docs Hub, 8월 16, 2025에 액세스, https://docs.nvidia.com/datacenter/cloud-native/openshift/latest/mig-ocp.html

92. Schedule GPUs

    Kubernetes, 8월 16, 2025에 액세스, https://kubernetes.io/docs/tasks/manage-gpus/scheduling-gpus/

93. Overview of Kubernetes GPU Scheduling, Device Plugin, CDI, NFD …, 8월 16, 2025에 액세스, https://medium.com/@rifewang/overview-of-kubernetes-gpu-scheduling-device-plugin-cdi-nfd-and-gpu-operator-48a7c4213b28
94. Architecting a reliable quantum operating system: microkernel, message passing and supercomputing - arXiv, 8월 16, 2025에 액세스, https://arxiv.org/html/2410.13482v1