현업에서 경력이 조금씩 올라가고, LLM을 통한 개발이 보편화되면서, CS 레벨의 지식이 더욱 중요해졌다는 생각이 들었습니다. 그러나 반대로 시간이 지나면서 CS지식들을 점점 까먹고 있는게 현실입니다. 그래서 다시 처음으로 돌아가 컴퓨터 시스템을 깊게 파보려고 합니다

오늘은 그 첫 번째로 Linux 가 무엇인지부터 정리해보겠습니다.

이번 편에서는 Kernel 내부까지 들어가지 않습니다. 대신 프로그램이 하드웨어를 쓰기까지 어떤 층을 거치는지, 그 큰 그림을 먼저 잡아두려 합니다.

1. 왜 Linux가 필요한가

아주 단순한 상황을 생각해보겠습니다. 우리가 만든 프로그램이 다음과 같은 작업을 해야 한다고 하겠습니다.

파일 읽기
네트워크 통신
메모리 사용
CPU에서 코드 실행
디스크에 데이터 저장

만약 프로그램이 하드웨어를 직접 제어해야 한다면 어떻게 될까요?

파일을 읽으려면 SSD의 동작 방식을 알아야 하고, 네트워크를 사용하려면 네트워크 카드의 동작 방식을 알아야 합니다. 메모리를 사용하려면 사용할 수 있는 영역을 직접 관리해야 하고, 여러 프로그램이 CPU를 함께 사용한다면 서로 충돌하지 않도록 조정해야 합니다. 이렇게 되면 애플리케이션을 만드는 것 자체가 지나치게 복잡해집니다.

그래서 프로그램과 하드웨어 사이에서 컴퓨터 자원을 관리하는 소프트웨어가 필요합니다.

Application 과 Hardware 사이에 컴퓨터 자원을 관리하는 소프트웨어가 있다.

이 역할을 하는 핵심 소프트웨어가 Kernel(커널) 입니다.

2. Kernel이란 무엇인가

컴퓨터에서 프로그램을 실행하면 CPU를 사용하고, 메모리에 데이터를 저장하고, 파일을 읽고, 네트워크를 통해 데이터를 주고받아야 합니다. 그런데 프로그램이 하드웨어를 직접 제어하도록 만들면 프로그램마다 CPU, 메모리, 디스크 등을 직접 관리해야 하기 때문에 매우 복잡해집니다.

이 문제를 해결하는 것이 Kernel(커널) 입니다.

Kernel은 운영체제의 핵심 부분으로, 프로그램과 하드웨어 사이에서 컴퓨터의 자원을 관리합니다. 프로그램이 CPU를 사용하거나 메모리를 할당받거나 파일을 읽고 쓰는 등의 작업을 할 때, Kernel이 그 요청을 받아 실제 하드웨어를 제어합니다.

쉽게 생각하면 다음과 같은 구조입니다.

Application 이 Linux Kernel 을 거쳐 CPU, Memory, Disk 가 있는 Hardware 를 쓴다.

예를 들어 프로그램이 파일을 읽으려고 하면 프로그램이 디스크를 직접 제어하는 것이 아니라 Kernel에 파일을 읽어달라고 요청합니다. Kernel은 파일 시스템과 저장장치를 관리하면서 필요한 데이터를 읽어 프로그램에 전달합니다.

여기서 Operating System(OS, 운영체제) 이라는 개념도 함께 알아둘 필요가 있습니다. 운영체제는 프로그램이 컴퓨터의 자원을 사용할 수 있도록 관리하고 필요한 환경을 제공하는 소프트웨어입니다. Kernel은 그중에서도 CPU, 메모리, 저장장치, 네트워크 같은 핵심 자원을 직접 관리하는 중심적인 부분입니다.

즉, OS 안에 Kernel 이 있는겁니다.

2.1. Linux와 Kernel의 관계

여기서 Linux를 이해할 때 가장 중요한 부분이 하나 있습니다.

엄밀하게 말하면 Linux는 운영체제 전체가 아니라 Kernel의 이름입니다.

Linux Kernel은 CPU, 메모리, 프로세스, 파일 시스템, 네트워크 등의 컴퓨터 자원을 관리합니다. 하지만 Kernel만 있다고 해서 우리가 평소 사용하는 Ubuntu나 Debian 같은 환경이 완성되는 것은 아닙니다.

예를 들어 우리가 터미널을 열어 명령어를 실행하고, 파일을 복사하고, 프로그램을 설치하는 등의 작업을 하려면 Kernel 외에도 여러 프로그램과 도구가 필요합니다.

그래서 실제로 사용하는 Linux 환경에는 다음과 같은 구성 요소들이 함께 들어 있습니다.

Linux Kernel : CPU, 메모리, 디스크, 네트워크 등 하드웨어 자원 관리
System Library : 프로그램이 Kernel의 기능을 사용할 수 있도록 도와주는 라이브러리
Shell : 사용자가 명령어를 입력하고 프로그램을 실행할 수 있도록 해주는 인터페이스
System Utilities : ls, cp, mv, ps 같은 기본 명령어
System Services : 부팅, 네트워크, 로그 등 시스템에서 필요한 백그라운드 서비스
그 외 다양한 프로그램과 설정

이렇게 Linux Kernel을 중심으로 여러 프로그램과 도구를 묶어서 사용하기 편한 형태로 만든 것이 Linux 배포판(Distribution) 입니다.

대표적인 Linux 배포판으로는 Ubuntu, Debian, Fedora, Rocky Linux 등이 있습니다.

따라서 관계를 단순하게 정리하면 다음과 같습니다.

Linux Kernel → 컴퓨터 자원을 관리하는 핵심

Linux Distribution → Linux Kernel + 라이브러리 + 명령어 + 시스템 서비스 + 각종 프로그램

Ubuntu / Debian / Fedora → 대표적인 Linux Distribution

Ubuntu 는 Linux Kernel, Shell, GNU utilities, System Libraries, System Services, 기타 프로그램으로 이루어진다.

Linux 는 Kernel 이고, Ubuntu / Debian / Fedora 는 Linux Kernel 에 여러 프로그램과 도구를 더한 배포판이다.

즉, 우리가 흔히 "Linux를 사용한다"고 말할 때는 실제로는 Linux Kernel을 포함한 Linux 배포판을 사용하고 있는 경우가 대부분입니다.

3. Kernel은 왜 필요한가

Kernel이 필요한 가장 중요한 이유는 여러 프로그램이 컴퓨터 자원을 함께 사용해야 하기 때문입니다. 예를 들어 하나의 서버에서 다음 프로그램이 동시에 실행될 수 있습니다.

Kafka
PostgreSQL
Java Application
Python Application

모두 CPU와 메모리를 사용하고, 일부는 디스크와 네트워크도 사용합니다. 만약 프로그램들이 하드웨어를 마음대로 사용한다면 문제가 발생합니다.

예를 들어 프로그램 A가 프로그램 B의 메모리를 마음대로 수정할 수 있다면 시스템이 망가질 수 있습니다. 또 하나의 프로그램이 CPU를 계속 사용한다면 다른 프로그램이 실행되지 못할 수도 있습니다. 그래서 중앙에서 자원을 관리하는 역할이 필요합니다.

Application A, B, C 가 모두 Linux Kernel 을 거친다. Kernel 은 CPU, Memory, File, Network, Device 를 관리하고 Hardware 를 쓴다.

즉 Kernel의 핵심 역할은 크게 두 가지로 볼 수 있습니다.

3.1. 자원 관리

컴퓨터의 자원을 여러 프로그램이 안전하게 사용할 수 있도록 관리합니다.

CPU
Memory
Storage
Network
Devices

3.2. 추상화

Abstraction(추상화) 는 복잡한 내부 구현을 숨기고 사용하기 쉬운 형태로 제공하는 것입니다.

예를 들어 프로그램이 파일을 읽을 때 SSD의 물리적인 동작까지 직접 알 필요는 없습니다. 프로그램 입장에서는 단순히 "파일을 연다", "파일을 읽는다" 라고 생각하면 되고, 그 뒤의 복잡한 작업은 Kernel이 처리합니다.

Application 은 파일을 읽고 싶다고만 하고, Kernel 이 어떤 파일인지 확인해 Storage 에서 데이터를 가져온다.

따라서 Kernel은 하드웨어의 복잡성을 애플리케이션에서 숨기고, 여러 프로그램이 하드웨어를 안전하게 사용할 수 있도록 관리합니다.

4. Application은 Kernel을 어떻게 사용하는가

여기서 System Call(시스템 호출) 이라는 개념이 등장합니다. System Call은 쉽게 말하면 프로그램이 Kernel에게 작업을 요청하는 공식적인 통로입니다.

예를 들어 파일을 읽고 싶다면 개념적으로 다음과 같은 흐름이 만들어집니다.

Application 이 파일을 읽어달라고 System Call 로 요청하면 Linux Kernel 이 Storage 에 접근한다.

대표적인 System Call에는 다음과 같은 것들이 있습니다.

text

open()
read()
write()
close()

중요한 것은 Application이 SSD나 디스크에 직접 명령을 보내는 것이 아니라 Kernel에게 요청한다는 점입니다.

5. Library는 어디에 있는가

실제 프로그램에서는 Application이 System Call을 직접 호출하기보다는 Library(라이브러리) 를 거치는 경우가 많습니다. Library는 프로그램에서 자주 사용하는 기능을 미리 만들어 놓은 코드 묶음입니다. 예를 들어 C 프로그램에서는 printf() 와 같은 함수를 사용할 수 있습니다.

개념적으로 보면 다음과 같습니다.

Application, Library, System Call, Linux Kernel, Hardware 순서의 흐름.

따라서 Linux에서 프로그램이 하드웨어를 사용하는 기본적인 흐름을 다음처럼 기억하면 좋습니다.

Application → Library → System Call → Kernel → Hardware.

단, 모든 작업이 반드시 이 정확한 경로를 거친다는 의미는 아닙니다. 여기서는 전체적인 구조를 이해하기 위한 모델입니다.

6. 파일 하나를 읽는 과정

예를 들어 애플리케이션이 /data/test.txt 파일을 읽는다고 해보겠습니다. 개념적으로는 다음과 같은 흐름이 됩니다.

파일을 읽을 때 Kernel 은 파일 관리, 메모리 관리, 저장장치 접근을 하고 Driver 를 통해 SSD 에 닿는다.

여기서 Driver(드라이버) 가 등장합니다. Driver는 특정 하드웨어를 운영체제가 사용할 수 있도록 연결해주는 소프트웨어입니다. SSD, 네트워크 카드, USB 장치 등은 각각 동작 방식이 다르고, Kernel은 이러한 장치들을 Driver를 통해 제어합니다.

그래서 전체 구조를 조금 더 구체적으로 보면 다음과 같습니다.

Application, Runtime / Library, System Call, Linux Kernel, Driver, Hardware 순서의 전체 구조.

이번 글에서는 이 구조를 이해하는 것이 가장 중요합니다.

7. 이 구조의 장점과 Trade-off

이 구조를 사용하면 애플리케이션이 하드웨어의 세부적인 동작을 직접 처리하지 않아도 됩니다.

Kafka, PostgreSQL, Java App, Spark 가 모두 하나의 Linux Kernel 을 거쳐 Hardware 를 쓴다.

Kernel이 CPU, 메모리, I/O 등을 관리하기 때문에 여러 프로그램이 하나의 컴퓨터에서 함께 실행될 수 있습니다. 하지만 모든 것을 공짜로 얻는 것은 아닙니다. 하드웨어와 애플리케이션 사이에 Kernel이라는 복잡한 계층이 생깁니다.

Application 과 Hardware 사이에 Kernel 이라는 계층이 생긴다.

즉 하드웨어의 복잡성을 Application에서 Kernel로 이동시킨 것이라고 볼 수도 있습니다. 이것이 중요한 Trade-off입니다. 애플리케이션은 단순해지는 대신 Kernel은 복잡해집니다.

그리고 Kernel이 자원을 관리하기 때문에 애플리케이션이 하드웨어를 마음대로 사용할 수는 없습니다. 대신 이러한 구조를 통해 프로그램 간 격리와 시스템의 안정성을 확보할 수 있습니다.

8. 실습

Linux에서는 strace 라는 도구를 이용해 프로그램이 어떤 System Call을 사용하는지 확인할 수 있습니다. 직접 확인해보기 위해 Ubuntu 26.04(WSL2, Kernel 6.18)에 strace 6.19를 설치하고, 파일 하나(test.txt)와 폴더 하나(data)가 있는 디렉터리에서 ls 를 실행해봤습니다.

8.1. strace ls

평소처럼 ls 를 실행하면 목록 두 줄이 나올 뿐입니다. 같은 명령을 strace 로 감싸 실행하면 그 뒤에서 일어나는 System Call이 한 줄씩 찍힙니다.

ls 와 strace ls 를 실행한 터미널. execve 로 ls 가 시작되고, openat 으로 라이브러리 파일을 열어 read 로 읽고 close 로 닫는 호출이 이어진다.

첫 줄의 execve 는 ls 프로그램을 실행해달라는 요청입니다. 그 뒤로 openat 으로 파일을 열고, read 로 읽고, close 로 닫는 호출이 반복됩니다. 여기서 열고 있는 파일을 보면 libselinux.so.1, libc.so.6 같은 Library 입니다. 5장에서 본 것처럼 ls 도 Library를 거쳐 동작하기 때문에, 본격적인 일을 하기 전에 필요한 Library부터 불러오는 것입니다.

출력의 마지막 부분은 다음과 같습니다.

$strace ls 출력의 마지막 부분. getdents64 로 디렉터리 내용을 읽고, write 로 "data\ntest.txt\n" 을 화면에 쓴 뒤 exit_group 으로 끝난다.$

openat(AT_FDCWD, ".", ...) 으로 현재 디렉터리를 열고, getdents64 로 그 안의 항목을 읽습니다. 그리고 write(1, "data\ntest.txt\n", 14) 로 화면(표준 출력, 1번)에 결과를 씁니다. 우리가 화면에서 보는 ls 결과도 결국 Kernel에게 "이 14바이트를 써달라" 고 요청한 결과입니다.

8.2. 파일 관련 System Call만 보기

파일과 관련된 System Call만 보고 싶다면 다음처럼 실행할 수 있습니다.

bash

strace -e trace=file ls

strace -e trace=file ls 를 실행한 터미널. execve, access, openat, statfs, statx, newfstatat 처럼 파일 경로를 다루는 호출만 남는다.

read, write, mmap 같은 호출은 사라지고 파일 경로를 다루는 호출만 남습니다. 참고로 제 환경의 ls 는 Rust로 다시 작성된 coreutils(uutils)라서, /usr/share/coreutils/locales/uucore 처럼 메시지 번역 파일을 찾는 경로도 함께 보입니다.

8.3. 몇 번이나 요청했을까

-c 옵션을 주면 호출을 하나하나 찍는 대신 종류별로 몇 번 호출했는지 집계해줍니다.

strace -c ls 의 집계 결과. read 18회, mmap 27회, openat 12회 등 System Call 을 모두 145회 호출했다.

ls 한 번에 System Call을 145번 호출했습니다. 평소에는 단순히 ls 라고 실행하지만, 실제로는 파일과 디렉터리 정보를 확인하고 프로그램을 실행하는 과정에서 Kernel에 여러 작업을 요청하고 있습니다.

여기서 145번의 호출이 모두 ls의 파일 목록 조회에만 사용되는 것은 아닙니다. mmap, mprotect, brk처럼 프로그램을 실행하고 메모리를 준비하는 과정에서 필요한 System Call도 포함되어 있습니다. 반면 openat, getdents64, statx, write 등은 디렉터리를 열고 파일 정보를 확인하고 결과를 출력하는 ls의 동작과 직접적으로 연결됩니다.

또한 calls는 System Call 함수가 호출된 횟수를 의미합니다. 예를 들어 read가 18회라고 해서 파일을 18개 읽었다는 의미는 아닙니다. 한 번의 read 호출로 여러 데이터를 읽을 수도 있습니다.

ls 명령도 System Call 을 통해 Linux Kernel 에 요청한다.