커널 역사 (Kernel History)

리눅스 커널의 역사를 1991년 탄생부터 현재까지 버전별 릴리즈 시기, 주요 변경사항, 코드베이스 성장 통계, VCS 변천사, 커널 거버넌스 구조, stable/longterm 프로세스, 서브시스템 메인테이너 트리, 개발 프로세스의 모든 것을 심층적으로 정리합니다.

1991년 탄생부터 현재까지, 리눅스 커널의 진화 과정을 버전별 릴리즈와 주요 변경사항으로 정리합니다.

개요 -- 리눅스 커널의 시작

1991년 8월 25일, 핀란드 헬싱키 대학교의 21세 학생 Linus Torvalds는 Usenet 뉴스그룹 comp.os.minix에 다음과 같은 역사적인 메시지를 남겼다:

이 "취미 프로젝트"는 Andrew Tanenbaum의 교육용 OS인 MINIX에서 영감을 받았지만, 처음부터 실용적인 목적으로 개발되었다. Linus는 386 프로세서의 태스크 스위칭 기능을 탐구하다가 터미널 에뮬레이터를 작성했고, 이것이 점차 운영체제 커널로 발전했다.

초기 리눅스는 GNU 프로젝트의 도구(GCC, Bash, coreutils 등)와 결합하여 완전한 운영체제를 구성했다. Richard Stallman이 1983년부터 추진한 GNU 프로젝트는 커널(GNU Hurd)을 제외한 대부분의 사용자 공간 도구를 이미 갖추고 있었기에, 리눅스 커널은 이 생태계에 완벽하게 들어맞았다.

리눅스는 GPLv2 라이선스를 채택하여 소스 코드를 자유롭게 사용, 수정, 재배포할 수 있게 했다. 이 결정은 전 세계 개발자들의 참여를 이끌어내며 오픈소스 소프트웨어 역사상 가장 성공적인 협업 프로젝트로 성장하는 기반이 되었다.

커널 버전 연대표

아래 표는 리눅스 커널의 주요 릴리즈를 시간순으로 정리한 것이다. 각 버전의 상세 내용은 이후 섹션에서 다룬다.

초기 개발 (0.x ~ 1.x)

0.01 (1991년 9월)

최초로 공개된 리눅스 커널 소스 코드. 약 10,239줄의 C 코드로 구성되었다. i386 전용이었으며, Minix 파일시스템을 사용했다. 프로세스 관리, 메모리 관리, 기본적인 파일시스템 지원만 포함되어 있었다.

• 지원 하드웨어: i386 CPU, AT 하드디스크
• 파일시스템: Minix FS (읽기/쓰기)
• 셸: Bourne Shell (bash는 0.02부터)

/* Linux 0.01 - main.c의 시작 (1991년) */
/*
 * linux/init/main.c
 *
 * (C) 1991 Linus Torvalds
 */

#define __LIBRARY__
#include <unistd.h>
#include <time.h>

void main(void)
{
    mem_init(main_memory_start, memory_end);
    trap_init();
    blk_dev_init();
    chr_dev_init();
    tty_init();
    time_init();
    sched_init();
    buffer_init(buffer_memory_end);
    hd_init();
    floppy_init();
    sti();
    move_to_user_mode();
    if (!fork()) {
        init();
    }
    for(;;) pause();
}

0.02 (1991년 10월 5일)

Linus가 공식적으로 "발표"한 첫 번째 버전. bash와 gcc를 실행할 수 있었다. 아직 플로피 디스크 드라이버조차 없어서 Minix에서 하드 디스크로 복사한 후 부팅해야 했다.

0.12 (1992년 1월)

중요한 전환점: 라이선스를 자체 라이선스에서 GPLv2로 변경했다. 이전 라이선스는 상업적 배포를 금지했으나, GPL 전환으로 자유로운 배포가 가능해졌다. 가상 메모리(스왑) 지원이 추가되었다.

0.95 ~ 0.99 (1992 ~ 1993)

X Window System 지원, ext 파일시스템 도입, 네트워킹 스택 초기 구현 등 급속한 발전 기간. 전 세계 개발자들이 기여하기 시작하면서 코드 규모가 빠르게 성장했다.

• 0.95 (1992-03): X Window System 실행 가능
• 0.96 (1992-05): ext 파일시스템 도입
• 0.99 (1992-12): ext2 파일시스템 초기 지원, 네트워킹 개선

1.0 (1994년 3월 14일)

최초의 안정(stable) 릴리즈. 약 176,250줄의 코드로 성장했다. TCP/IP 네트워킹이 완전히 통합되어 인터넷 서버로 사용 가능해졌다.

• 네트워킹: TCP/IP 스택 완성 (BSD 소켓 인터페이스)
• 파일시스템: ext2, Minix, xiafs, MS-DOS FAT
• 아키텍처: i386 단일 아키텍처
• SCSI 지원, 가상 콘솔, 사운드 드라이버

1.2 (1995년 3월 7일)

최초로 다중 아키텍처를 지원한 릴리즈. Alpha, SPARC, MIPS 프로세서로 이식되었다.

• 네트워킹: IPX (Novell NetWare), AppleTalk 프로토콜
• 디바이스: 더 많은 SCSI 어댑터, 사운드 카드 지원
• 약 310,950줄의 코드

2.x 시대 -- 엔터프라이즈 진입

2.0 (1996년 6월 9일)

리눅스가 서버 시장에 진입하는 계기가 된 릴리즈. SMP(대칭형 다중 처리) 지원이 핵심이었다.

• SMP: 최대 16개 CPU 지원 (Big Kernel Lock 기반)
• 로더블 모듈: 런타임에 커널 기능을 동적 로드/언로드
• ELF 바이너리: a.out 포맷 대체
• 다중 아키텍처: x86, Alpha, SPARC, MIPS, m68k, PowerPC
• 약 780,000줄의 코드

2.2 (1999년 1월 25일)

확장성과 성능이 크게 개선된 버전. 엔터프라이즈 환경에서의 안정성이 입증되기 시작했다.

• 개선된 SMP: 세분화된 잠금(fine-grained locking) 도입
• IPv6 초기 지원 (실험적)
• 대용량 메모리 지원 개선 (2GB 이상)
• 향상된 네트워킹 성능
• 약 1,800,000줄의 코드

2.4 (2001년 1월 4일)

데스크탑과 서버 양쪽에서 리눅스의 실용성을 크게 높인 릴리즈.

• USB 서브시스템: 대중적인 USB 장치 지원
• ext3: 저널링 파일시스템 (ext2 호환)
• iptables / Netfilter: ipchains 대체, stateful 방화벽
• LVM (Logical Volume Manager): 논리 볼륨 관리
• Bluetooth 지원
• ISA Plug and Play
• 약 3,800,000줄의 코드

2.6 (2003년 12월 17일)

가장 오래 유지된 메이저 버전 시리즈(2003~2011). 현대 리눅스 커널의 기반이 되는 핵심 기능 대부분이 이 시기에 도입되었다.

2.6.0 핵심 기능:

• O(1) 스케줄러: 프로세스 수에 무관한 상수 시간 스케줄링
• Preemptive kernel: 커널 코드 실행 중 선점 가능
• NPTL (Native POSIX Thread Library): 1:1 스레딩 모델
• sysfs: 디바이스 모델을 파일시스템으로 노출
• udev: 사용자 공간 디바이스 관리
• ALSA 사운드 서브시스템 (OSS 대체)

2.6.x 주요 포인트 릴리즈:

3.x ~ 4.x -- 현대화

3.0 (2011년 7월 21일)

버전 번호 체계를 변경한 릴리즈. 2.6.39에서 곧바로 3.0으로 넘어갔으며, 기술적으로 혁명적인 변화보다는 리눅스 탄생 20주년을 기념하여 번호를 정리한 것이다. 이후 3.x, 4.x, 5.x, 6.x로 순차 증가하는 체계가 확립되었다.

3.x 주요 릴리즈 (2011 ~ 2015)

4.0 (2015년 4월 12일)

Live kernel patching이 도입된 릴리즈. 재부팅 없이 커널 코드를 패치할 수 있는 인프라로, Red Hat의 kpatch와 SUSE의 kGraft를 통합한 결과물이다.

4.x 주요 릴리즈 (2015 ~ 2018)

5.x -- 성숙기

5.0 (2019년 3월 3일)

4.20에서 이어진 릴리즈로, 번호 변경 자체에 기술적 의미는 없다. Linus는 "번호가 너무 커지면 변경한다"고 언급했다.

• Energy-Aware Scheduling (EAS): ARM big.LITTLE 등 비대칭 CPU 아키텍처에서 에너지 효율적 스케줄링
• Adiantum 암호화: 저성능 디바이스를 위한 빠른 스토리지 암호화
• AMD FreeSync 지원

5.x 주요 릴리즈 (2019 ~ 2022)

6.x -- 현재

6.0 (2022년 10월 2일)

Rust 인프라가 커널에 초기 도입된 릴리즈. CONFIG_RUST 빌드 옵션이 추가되었으며, Rust로 커널 모듈을 작성할 수 있는 기반이 마련되었다.

• Rust 지원 인프라 초기 코드
• io_uring zero-copy 네트워킹 개선
• XFS Online Repair 확장

6.1 (2022년 12월 11일)

Rust 공식 지원이 안정화된 첫 번째 릴리즈. MGLRU(Multi-Gen LRU)도 포함되어 메모리 관리 성능이 크게 개선되었다.

• Rust: 커널 모듈 작성 지원 (실험적이지만 공식 통합)
• MGLRU: 새로운 페이지 교체 알고리즘, 기존 LRU 대비 성능 향상
• Maple Tree: VMA 관리용 새로운 자료구조
• User-space 스택 언와인딩 지원
• LTS 릴리즈

6.x 주요 릴리즈 (2023 ~ 현재)

스케줄러 변천사

리눅스 커널의 프로세스 스케줄러는 워크로드 변화에 맞춰 꾸준히 진화해왔다. 스케줄러 변천사는 커널 설계 철학의 변화를 가장 잘 보여주는 지표이다.

VCS(버전 관리 시스템) 변천사

리눅스 커널의 소스 코드 관리 방식은 프로젝트 규모의 성장과 함께 극적으로 변화해왔다. VCS 변천사는 오픈소스 개발 방법론의 진화를 직접적으로 반영한다.

# 커널 Git 저장소 통계 확인

# 전체 커밋 수
git rev-list --count HEAD

# 기여자 수
git shortlog -sn | wc -l

# 최근 릴리즈 태그
git tag --sort=-v:refname | head -10

# 특정 릴리즈 간 변경 통계
git diff --stat v6.1..v6.6 | tail -1

# 릴리즈별 커밋 수
git rev-list --count v6.5..v6.6

커널 개발 프로세스

릴리즈 사이클

리눅스 커널은 약 9~10주 주기로 새 버전을 릴리즈한다. 각 사이클은 다음 단계로 구성된다:

Stable/LTS 프로세스

LTS (Long Term Support) 정책

매년 1~2개의 릴리즈가 LTS로 지정되어 장기 지원을 받는다. 일반 릴리즈가 다음 버전 출시까지(약 2~3개월)만 지원되는 것과 달리, LTS는 최소 2년에서 최대 6년까지 보안 및 중요 버그 수정 패치를 받는다.

Stable 패치 선정 기준

stable 트리에 백포트되는 패치는 엄격한 기준을 따른다:

# stable 패치 선정 기준 (Documentation/process/stable-kernel-rules.rst)

1. 메인라인에 이미 머지된 패치여야 한다
2. 실제 버그를 수정하거나 보안 문제를 해결해야 한다
3. 100줄 이하의 작은 패치여야 한다 (예외 가능)
4. 명확한 테스트를 거쳐야 한다
5. Cc: stable@vger.kernel.org 태그가 있어야 한다

# 패치에 stable 태그 추가 방법:
Cc: stable@vger.kernel.org
# 또는 특정 버전 지정:
Cc: <stable@vger.kernel.org> # v5.10+

커널 거버넌스

서브시스템 메인테이너 구조

리눅스 커널은 계층적 메인테이너 구조로 관리된다. 이 구조는 "신뢰의 사슬(web of trust)"이라고도 불린다:

# MAINTAINERS 파일 활용법

# 특정 파일의 메인테이너 확인
scripts/get_maintainer.pl -f drivers/net/dsa/mv88e6xxx/chip.c

# MAINTAINERS 엔트리 검색
grep -A 10 "DSA" MAINTAINERS

# 패치 제출 시 수신자 자동 확인
scripts/get_maintainer.pl 0001-fix-bug.patch

패치 제출 절차

# 패치 작성 및 제출 절차

# 1. 기능 브랜치 생성
git checkout -b fix/my-bug-fix origin/master

# 2. 코드 수정 및 커밋
git add drivers/net/dsa/my_fix.c
git commit -s  # Signed-off-by: 자동 추가

# 3. 커밋 메시지 형식
# net: dsa: fix source port decode for multichip
#
# When using multichip cascade topology, the source
# device ID was not properly extracted from the DSA
# tag, causing packets to be delivered to wrong ports.
#
# Fixes: abc1234 ("net: dsa: add multichip support")
# Cc: stable@vger.kernel.org
# Signed-off-by: Developer Name <dev@example.com>

# 4. 패치 형식 검사
scripts/checkpatch.pl --strict 0001-*.patch

# 5. 메인테이너 확인
scripts/get_maintainer.pl 0001-*.patch

# 6. 패치 발송
git send-email --to=maintainer@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    0001-*.patch

커널 규모 변화

리눅스 커널의 소스 코드 규모는 약 30년간 꾸준히 성장해왔다. 아래는 주요 버전별 대략적인 코드 라인 수(LOC, drivers 포함)이다:

코드 증가의 대부분은 디바이스 드라이버(drivers/ 디렉토리)가 차지한다. 전체 코드의 약 60~70%가 드라이버 코드이며, 커널 핵심(코어 서브시스템)은 상대적으로 적은 비율을 차지한다.

# 전체 코드 라인 수
find . -name '*.[chS]' -not -path './tools/*' | xargs wc -l

# drivers/ 디렉토리 비율
find drivers/ -name '*.[chS]' | xargs wc -l

# 디렉토리별 코드 비중
for dir in drivers kernel mm net fs arch; do
    echo "$dir: $(find $dir -name '*.[chS]' | xargs cat | wc -l) lines"
done

# 릴리즈 간 변경 통계
git diff --stat v6.1..v6.6 | tail -1

개발 통계

리눅스 커널은 세계에서 가장 활발하게 개발되는 오픈소스 프로젝트 중 하나이다. 매 릴리즈마다 수천 명의 개발자가 수만 건의 패치를 기여한다.

주요 기여 조직

아키텍처 지원 역사

리눅스 커널은 i386 단일 아키텍처에서 시작하여 현재 30개 이상의 하드웨어 아키텍처를 지원한다.

보안 관련 주요 사건

리눅스 커널의 보안은 하드웨어 취약점 발견, LSM 프레임워크 발전, 커널 자체 방어 기능 강화를 통해 지속적으로 발전해왔다.

# 현재 커널의 보안 기능 확인

# LSM 모듈 확인
cat /sys/kernel/security/lsm

# KPTI 상태
dmesg | grep -i "page table isolation"

# Spectre/Meltdown 완화 상태
cat /sys/devices/system/cpu/vulnerabilities/*

# seccomp 상태
grep Seccomp /proc/self/status

# Lockdown 상태
cat /sys/kernel/security/lockdown

배포판과 커널 버전 관계

주요 Linux 배포판은 메인라인 커널을 기반으로 자체 패치를 적용하여 배포한다. 배포판 선택 시 커널 버전을 확인하는 것은 하드웨어 호환성과 기능 지원에 직접적인 영향을 미친다.

# 현재 커널 버전 확인
uname -r

# 상세 빌드 정보
cat /proc/version

# 배포판 커널 설정 확인
ls /boot/config-$(uname -r)
zcat /proc/config.gz 2>/dev/null || cat /boot/config-$(uname -r)

# 배포판별 커널 패키지 확인
# Debian/Ubuntu:
dpkg -l | grep linux-image
# RHEL/CentOS:
rpm -qa | grep kernel
# Arch:
pacman -Q | grep linux

커널 라이선스와 법적 쟁점

리눅스 커널의 라이선스 역사는 오픈소스 소프트웨어 법률의 발전과 밀접하게 연관되어 있다.

/* SPDX 라이선스 태그 예시 (모든 커널 소스 파일 첫 줄) */
// SPDX-License-Identifier: GPL-2.0-only
/* 또는 */
// SPDX-License-Identifier: GPL-2.0-or-later
/* Rust 바인딩의 경우 */
// SPDX-License-Identifier: GPL-2.0 OR Apache-2.0

Rust in Kernel 역사

C 언어로만 작성되던 리눅스 커널에 Rust가 도입된 것은 30년 역사상 가장 큰 언어 변화이다.

# Rust 커널 빌드 설정

# Rust 도구 체인 설치 확인
rustup show
rustc --version
bindgen --version

# 커널 Rust 지원 확인
make rustavailable

# Rust 모듈 빌드
make menuconfig  # General setup -> Rust support 활성화
make -j$(nproc)

/* 최소 Rust 커널 모듈 예시 */
// SPDX-License-Identifier: GPL-2.0

//! Rust 최소 커널 모듈

use kernel::prelude::*;

module! {
    type: RustMinimal,
    name: "rust_minimal",
    author: "Developer",
    description: "Rust minimal module",
    license: "GPL",
}

struct RustMinimal;

impl kernel::Module for RustMinimal {
    fn init(_module: &ThisModule) -> Result<Self> {
        pr_info!("Rust minimal module loaded\n");
        Ok(RustMinimal)
    }
}

impl Drop for RustMinimal {
    fn drop(&mut self) {
        pr_info!("Rust minimal module unloaded\n");
    }
}

서브시스템 메인테이너 트리

리눅스 커널의 개발은 수십 개의 서브시스템 트리로 분산되어 진행된다. 각 서브시스템 메인테이너는 자신의 Git 트리에서 패치를 관리하고, merge window 기간에 Linus에게 pull request를 보낸다.

# 서브시스템 트리 활용

# 특정 서브시스템 트리 추가
git remote add net-next https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git
git fetch net-next

# 서브시스템 트리의 최신 패치 확인
git log --oneline net-next/main -20

# 서브시스템별 merge window 기여 확인
git log --oneline --merges v6.18..v6.19 | head -30

# 특정 서브시스템의 패치 수 통계
git log --oneline v6.18..v6.19 -- net/ drivers/net/ | wc -l
git log --oneline v6.18..v6.19 -- mm/ | wc -l
git log --oneline v6.18..v6.19 -- drivers/gpu/ | wc -l

릴리즈별 주요 기능 상세

이 섹션에서는 커널 역사에서 특히 영향력이 컸던 기능들의 도입 배경, 설계 결정, 이후 발전 과정을 상세히 다룬다.

cgroups (2.6.24, 2008)

Control Groups는 Google 엔지니어들(Paul Menage, Rohit Seth)이 개발한 프로세스 자원 제어 메커니즘이다. 프로세스 그룹에 CPU, 메모리, I/O, 네트워크 대역폭 등의 자원 한도를 설정할 수 있다.

• cgroups v1 (2.6.24, 2008): 계층적 자원 제어, 각 컨트롤러 독립 계층
• cgroups v2 (4.5, 2016): 단일 계층 구조, 모든 컨트롤러 통합
• 컨테이너 기술(Docker, LXC, Kubernetes)의 핵심 기반
• systemd의 서비스 자원 관리 기반

eBPF (3.18~현재)

extended Berkeley Packet Filter는 커널 내에서 안전하게 실행되는 사용자 정의 프로그램 프레임워크이다. 원래 패킷 필터링용이었으나, 현재는 트레이싱, 보안, 네트워킹, 스케줄링 등 거의 모든 커널 서브시스템에서 사용된다.

io_uring (5.1~현재)

Jens Axboe가 개발한 io_uring은 비동기 I/O의 혁명적 개선이다. 기존 aio(Linux AIO)와 epoll의 한계를 극복하기 위해, 사용자-커널 간 공유 링 버퍼로 시스템 콜 오버헤드를 최소화했다.

• Submission Queue (SQ): 사용자가 I/O 요청을 넣는 링
• Completion Queue (CQ): 커널이 완료 결과를 넣는 링
• Polling 모드: 시스템 콜 없이 I/O 처리 (최대 성능)
• 지원 연산: read/write, send/recv, accept, connect, splice, 파일 관리 등

PREEMPT_RT (6.12, 2024)

약 20년간 out-of-tree로 유지된 실시간 스케줄링 패치가 드디어 메인라인에 통합되었다. Thomas Gleixner와 Peter Zijlstra의 주도로, 모든 스핀락을 RT-mutex로 대체하고 인터럽트를 스레드화하여 결정적(deterministic) 지연시간을 보장한다.

# PREEMPT_RT 확인
uname -a | grep -i rt
cat /sys/kernel/realtime

# preemption 모델 확인
cat /sys/kernel/debug/sched/preempt

# cyclictest로 실시간 지연시간 측정
cyclictest -t1 -p 80 -n -i 1000 -l 10000

개발 통계 상세

리눅스 커널의 개발 활동을 정량적으로 분석하면, 이 프로젝트의 규모와 활력을 구체적으로 이해할 수 있다.

디렉토리별 코드 비중 변화

릴리즈 주기 통계

# 릴리즈별 상세 통계 명령어

# 릴리즈 간 커밋 수
git rev-list --count v6.11..v6.12

# 릴리즈 간 기여자 수
git shortlog -sn v6.11..v6.12 | wc -l

# 릴리즈 간 변경 파일 수
git diff --stat v6.11..v6.12 | tail -1

# 릴리즈 간 추가/삭제 라인 수
git diff --shortstat v6.11..v6.12

# 상위 10 기여자
git shortlog -sn v6.11..v6.12 | head -10

# merge window 기간 커밋 (rc1까지)
git rev-list --count v6.11..v6.12-rc1

# rc 기간 커밋 (rc1~final)
git rev-list --count v6.12-rc1..v6.12

# 디렉토리별 변경 비중
git diff --stat v6.11..v6.12 -- drivers/ | tail -1
git diff --stat v6.11..v6.12 -- net/ | tail -1
git diff --stat v6.11..v6.12 -- mm/ | tail -1

Stable/Longterm 프로세스 상세

stable 트리의 패치 선정과 릴리즈 과정은 엄격한 규칙을 따른다. 이 프로세스를 이해하면 배포판 커널 업데이트의 배경을 알 수 있다.

LTS 정책 상세

커널 거버넌스 구조 상세

리눅스 커널의 거버넌스는 공식적인 조직 구조 없이, 기술적 역량과 신뢰에 기반한 유기적 체계로 운영된다. 2018년 Code of Conduct 채택 이후 커뮤니티 운영 방식에도 변화가 있었다.

Technical Advisory Board (TAB)

Linux Foundation의 Technical Advisory Board는 커널 커뮤니티의 기술적 방향성을 논의하는 자문 기구이다. 구성원은 커뮤니티 선거로 선출되며, Code of Conduct 위반 사항 조정 역할도 수행한다.

MAINTAINERS 파일 구조

# MAINTAINERS 파일 엔트리 형식
NETWORKING [DSA]
M:  Andrew Lunn <andrew@lunn.ch>
M:  Florian Fainelli <f.fainelli@gmail.com>
M:  Vladimir Oltean <olteanv@gmail.com>
L:  netdev@vger.kernel.org
S:  Maintained
F:  net/dsa/
F:  drivers/net/dsa/
F:  include/net/dsa.h
F:  include/linux/dsa/

# 필드 설명:
# M: = 메인테이너 (패치 리뷰 및 병합 권한)
# R: = 리뷰어 (Acked-by/Reviewed-by 제공)
# L: = 메일링 리스트
# S: = 상태 (Maintained, Supported, Orphan 등)
# F: = 파일/디렉토리 패턴
# T: = Git 트리 URL

# MAINTAINERS 활용 실전 명령어

# 특정 파일의 메인테이너 확인
scripts/get_maintainer.pl -f net/dsa/slave.c

# 특정 패치의 수신자 자동 확인
scripts/get_maintainer.pl 0001-net-dsa-fix-bug.patch

# 메인테이너 수 통계
grep "^M:" MAINTAINERS | sort -u | wc -l

# Orphan 상태 서브시스템 확인
grep -B1 "^S:.*Orphan" MAINTAINERS

# 전체 메일링 리스트 목록
grep "^L:" MAINTAINERS | sort -u

파일시스템 진화

리눅스 커널의 파일시스템 지원은 초기 Minix FS에서 현재의 ext4, Btrfs, XFS, F2FS, Bcachefs까지 지속적으로 발전해왔다. 파일시스템 변천사는 스토리지 기술 발전을 직접 반영한다.

네트워킹 스택 진화

리눅스 네트워킹 스택은 단순한 TCP/IP 구현에서 세계에서 가장 기능이 풍부한 네트워크 OS로 발전했다.

커널 빌드 시스템 변천

커널 빌드 시스템도 코드베이스 성장에 맞춰 진화해왔다.

# 커널 빌드 기본 명령어

# 설정
make defconfig               # 기본 설정
make menuconfig              # 대화형 설정
make olddefconfig            # 기존 .config 유지 + 새 옵션 기본값

# 빌드
make -j$(nproc)              # 병렬 빌드
make CC=clang -j$(nproc)     # Clang으로 빌드
make LLVM=1 -j$(nproc)       # 전체 LLVM 도구 체인

# Rust 지원 확인 및 빌드
make rustavailable           # Rust 도구 체인 확인
make LLVM=1 -j$(nproc)       # Rust는 LLVM 필수

# 크로스 컴파일
make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- defconfig
make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j$(nproc)

# 빌드 시간 프로파일링
make -j$(nproc) 2>&1 | ts '[%Y-%m-%d %H:%M:%S]'

미래 전망

리눅스 커널은 30년 이상의 역사를 통해 지속적으로 발전해왔으며, 앞으로도 여러 방향에서 진화가 예상된다.

기술적 방향성

거버넌스 과제

• 후계 구도: Linus Torvalds의 은퇴 후 커널 관리 체계에 대한 논의가 시작되고 있다
• 다양성: 기여자 다양성 확대(지역, 성별, 배경)를 위한 노력
• 개발 도구: 메일링 리스트 중심 워크플로우의 현대화 논의 (GitLab/Forge 등)
• AI 코드 기여: AI 생성 코드의 저작권, 라이선스, 품질 관리 정책 수립
• 보안 공개: 취약점 공개 프로세스 개선, CVE 할당 체계 정비

메모리 관리 진화

리눅스 커널의 메모리 관리 서브시스템은 초기 단순한 페이지 할당에서 현대의 정교한 다층 메모리 관리 체계로 발전했다. 이 변천사는 하드웨어 발전(대용량 메모리, NUMA, 영구 메모리)과 워크로드 변화(가상화, 컨테이너)를 반영한다.

MGLRU (Multi-gen LRU): 5.18의 혁신

전통적인 LRU(Least Recently Used) 알고리즘은 active/inactive 두 리스트만으로 페이지 노화를 추적했다. MGLRU는 세대(generation) 개념을 도입하여 페이지 접근 패턴을 더 정밀하게 추적하고, 불필요한 페이지 스캔을 줄여 메모리 압력 상황에서 성능을 크게 개선했다.

# MGLRU 활성화 확인/제어
cat /sys/kernel/mm/lru_gen/enabled
# 값: 0x0007 (기본) - 모든 기능 활성
# bit 0: MGLRU 코어
# bit 1: 런타임 페이지 테이블 young 비트 스캔
# bit 2: 비활성 세대 자동 노화

# MGLRU 통계 확인 (memcg별)
cat /sys/kernel/debug/lru_gen
# memcg     0 (type=anon)
#   node    0
#     gen    3    age  10s    nr_pages  12345
#     gen    2    age  30s    nr_pages  8765
#     gen    1    age  60s    nr_pages  4321
#     gen    0    age 120s    nr_pages  2345

# DAMON 기반 선제적 회수 설정
echo "2000000 3000000 5 1000 10000" > /sys/kernel/debug/damon/target_ids
# min_sz max_sz min_nr_reg sample_intv aggr_intv (마이크로초)

대형 폴리오 (Large Folio): 6.x의 진화

folio는 5.16에서 도입된 페이지 캐시 관리 단위로, compound page를 대체한다. 6.x 시리즈에서 large folio가 일반화되면서 파일 I/O와 THP 모두에서 성능이 크게 향상되었다.

/* folio 도입 전후 비교 */

/* 5.15 이전: struct page 기반 */
struct page *page = find_get_page(mapping, index);
if (PageCompound(page))
    page = compound_head(page);  /* head page 필요 */

/* 5.16 이후: struct folio 기반 */
struct folio *folio = filemap_get_folio(mapping, index);
/* folio는 항상 head page → compound_head() 불필요 */
size_t size = folio_size(folio);  /* 4KB, 16KB, 64KB, ... */

/* large folio 할당 (6.8+) */
struct folio *folio = filemap_alloc_folio(GFP_KERNEL, order);
/* order=0: 4KB, order=2: 16KB, order=4: 64KB */

디바이스 모델 진화

리눅스 커널의 디바이스 모델은 하드웨어 추상화와 드라이버 관리의 근간이다. 초기의 디바이스 번호(major/minor) 기반 모델에서 sysfs/udev 기반의 현대적 모델로 발전했다.

# 디바이스 모델 탐색 명령어

# sysfs 디바이스 트리 탐색
ls /sys/bus/                        # 등록된 버스 타입
ls /sys/class/                      # 디바이스 클래스
ls /sys/devices/platform/           # 플랫폼 디바이스

# PCI 디바이스 계층
lspci -tv                           # PCI 토폴로지 트리
ls /sys/bus/pci/devices/            # sysfs에서 확인

# USB 디바이스 계층
lsusb -tv                           # USB 토폴로지 트리
ls /sys/bus/usb/devices/            # sysfs에서 확인

# Device Tree 확인 (ARM/ARM64)
ls /proc/device-tree/               # DT 노드 탐색
dtc -I fs /proc/device-tree/        # 런타임 DT 덤프

# udev 규칙 디버깅
udevadm info --query=all --name=/dev/sda
udevadm monitor --property         # 실시간 uevent 모니터링
udevadm test /sys/class/net/eth0    # 규칙 시뮬레이션

# 드라이버 바인딩 수동 제어
echo "0000:00:1f.0" > /sys/bus/pci/drivers/lpc_ich/unbind
echo "0000:00:1f.0" > /sys/bus/pci/drivers/lpc_ich/bind

가상화 지원 변천

리눅스는 세계에서 가장 널리 사용되는 하이퍼바이저 호스트 OS이다. KVM의 메인라인 통합부터 컨테이너 격리, 마이크로VM까지 가상화 기술의 전 영역을 포괄한다.

전원 관리와 에너지 효율 역사

리눅스 커널의 전원 관리는 노트북 배터리 절약에서 시작하여 데이터센터 에너지 효율과 모바일 디바이스 최적화까지 광범위한 영역으로 확장되었다.

# 전원 관리 상태 확인 명령어

# cpufreq 현재 상태
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors

# 모든 CPU 주파수 한번에 확인
grep MHz /proc/cpuinfo

# cpuidle C-state 통계
cat /sys/devices/system/cpu/cpu0/cpuidle/state*/name
cat /sys/devices/system/cpu/cpu0/cpuidle/state*/time
cat /sys/devices/system/cpu/cpu0/cpuidle/state*/usage

# 거버너 변경
echo schedutil > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

# Intel P-State 드라이버 상태
cat /sys/devices/system/cpu/intel_pstate/status   # active/passive/off
cat /sys/devices/system/cpu/intel_pstate/min_perf_pct
cat /sys/devices/system/cpu/intel_pstate/max_perf_pct

# runtime PM 상태 확인 (디바이스별)
cat /sys/bus/pci/devices/0000:00:00.0/power/runtime_status
# active / suspended / suspending

# 시스템 전체 에너지 소비 (RAPL)
cat /sys/class/powercap/intel-rapl/intel-rapl:0/energy_uj
# turbostat으로 상세 분석
turbostat --Summary --show Busy%,Bzy_MHz,PkgWatt sleep 5

# 서스펜드/하이버네이트
cat /sys/power/state                # freeze mem disk
echo mem > /sys/power/state         # S3 서스펜드
echo freeze > /sys/power/state      # s2idle (S0ix)

커널 디버깅 도구 변천

리눅스 커널 디버깅 도구는 printk에서 시작하여 현재의 정교한 트레이싱/프로파일링 프레임워크로 발전했다. 이 변천사는 커널 개발 문화와 소프트웨어 공학의 진보를 반영한다.

# 주요 커널 디버깅 도구 사용 예시

# === ftrace: 함수 트레이싱 ===
cd /sys/kernel/tracing
echo function_graph > current_tracer
echo 'tcp_sendmsg' > set_graph_function
echo 1 > tracing_on
sleep 2
echo 0 > tracing_on
cat trace | head -50

# === perf: 성능 프로파일링 ===
# CPU 프로파일링 (플레임 그래프용)
perf record -g -a sleep 10
perf report --stdio

# 하드웨어 이벤트 카운팅
perf stat -e cycles,instructions,cache-misses,branches,branch-misses ./workload

# 스케줄러 지연시간 분석
perf sched record sleep 5
perf sched latency

# === bpftrace: 고수준 트레이싱 ===
# 프로세스별 시스콜 빈도
bpftrace -e 'tracepoint:raw_syscalls:sys_enter { @[comm] = count(); }'

# 블록 I/O 지연시간 히스토그램
bpftrace -e 'tracepoint:block:block_rq_issue { @start[args->dev, args->sector] = nsecs; }
tracepoint:block:block_rq_complete /@start[args->dev, args->sector]/ {
  @usecs = hist((nsecs - @start[args->dev, args->sector]) / 1000);
  delete(@start[args->dev, args->sector]);
}'

# TCP 재전송 추적
bpftrace -e 'kprobe:tcp_retransmit_skb { printf("retransmit: %s:%d\n", comm, pid); }'

# === KASAN: 메모리 오류 탐지 (빌드 시 설정) ===
# .config에서 CONFIG_KASAN=y 설정 후 빌드
# 버그 발생 시 dmesg에 상세 리포트 출력
dmesg | grep -A 20 "BUG: KASAN"

# === crash: 커널 덤프 분석 ===
crash /usr/lib/debug/lib/modules/$(uname -r)/vmlinux /var/crash/vmcore
# crash> bt     (backtrace)
# crash> ps     (프로세스 목록)
# crash> vm     (가상 메모리)
# crash> log    (커널 로그)

커널 테스트 인프라 발전

리눅스 커널은 세계 최대 규모의 오픈소스 프로젝트답게 정교한 테스트 인프라를 구축해왔다. 초기에는 테스트가 거의 없었으나, 현재는 수십 개의 자동화된 CI 시스템이 매 패치를 검증한다.

# 커널 테스트 실행 예시

# === KUnit: 커널 단위 테스트 ===
# 모든 KUnit 테스트 실행 (UML 기반, 하드웨어 불필요)
./tools/testing/kunit/kunit.py run

# 특정 테스트 스위트만 실행
./tools/testing/kunit/kunit.py run --filter=kunit_example

# QEMU에서 실행 (ARM64)
./tools/testing/kunit/kunit.py run --arch=arm64 --cross_compile=aarch64-linux-gnu-

# === kselftest: 서브시스템 테스트 ===
# 전체 selftest 빌드 및 실행
make -C tools/testing/selftests run_tests

# 특정 서브시스템 테스트만
make -C tools/testing/selftests TARGETS=net run_tests
make -C tools/testing/selftests TARGETS=bpf run_tests
make -C tools/testing/selftests TARGETS=mm run_tests

# === syzkaller: 커널 퍼징 (로컬) ===
# syz-manager 설정 후 실행
./bin/syz-manager -config my.cfg

# === LTP: 회귀 테스트 ===
# 기본 시스콜 테스트
./runltp -f syscalls -z -o /tmp/ltp-results.log

# === virtme-ng: 빠른 커널 부팅 ===
# 현재 커널 소스로 빌드 후 즉시 부팅
vng --build --run
# 특정 명령 실행 후 종료
vng --run -- uname -r

커널 문서화 시스템 변천

커널 문서화 체계의 발전은 프로젝트 규모 성장과 개발자 온보딩의 필요성을 반영한다.

# 커널 문서 빌드

# HTML 문서 생성
make htmldocs

# 특정 서브시스템 문서만
make SPHINXDIRS=networking htmldocs
make SPHINXDIRS=driver-api htmldocs

# PDF 생성
make pdfdocs

# kernel-doc 추출 (특정 파일의 API 문서)
scripts/kernel-doc -man include/linux/skbuff.h
scripts/kernel-doc -rst include/linux/list.h

# 문서 검증 (스타일 체크)
make htmldocs 2>&1 | grep WARNING

# 번역 문서 빌드 (한국어)
make SPHINXDIRS=translations/ko_KR htmldocs

리눅스 커널의 문화와 커뮤니케이션

리눅스 커널 개발 커뮤니티는 독특한 문화와 커뮤니케이션 방식을 발전시켜왔다. 30년 이상 지속된 메일링 리스트 기반 워크플로우는 현재까지 커널 개발의 근간이다.

커뮤니케이션 채널

패치 워크플로우

# 커널 패치 제출 전체 과정

# 1. 코딩 스타일 검증
scripts/checkpatch.pl --strict -f drivers/net/dsa/my_driver.c

# 2. 패치 생성
git format-patch -v2 --cover-letter -o /tmp/patches HEAD~3
# -v2: 두 번째 버전
# --cover-letter: 시리즈 설명

# 3. 수신자 자동 확인
scripts/get_maintainer.pl /tmp/patches/*.patch

# 4. 패치 전송
git send-email --to=maintainer@example.com \
    --cc=linux-kernel@vger.kernel.org \
    /tmp/patches/*.patch

# 5. 패치 상태 확인
# lore.kernel.org에서 Message-ID로 검색
# patchwork에서 상태 확인 (New/Under Review/Accepted 등)

# 6. 피드백 반영 후 재전송
git format-patch -v3 --cover-letter -o /tmp/patches_v3 HEAD~3
# v3 커버레터에 변경 이력(changelog) 포함

코드 리뷰 태그

커널 주요 인물과 기여

리눅스 커널의 역사는 핵심 개발자들의 기여와 분리할 수 없다. 프로젝트 초기부터 현재까지 커널의 방향을 결정지은 주요 인물들을 정리한다.

기업별 기여 비중 (2024년 기준)

현대 리눅스 커널 개발은 기업 후원에 크게 의존한다. Linux Foundation의 분석에 따르면 전체 커밋의 약 85%가 기업 소속 개발자에 의해 이루어진다.

주요 기술 논쟁과 분기점

리눅스 커널 30년 역사에서 커뮤니티를 뒤흔든 주요 기술 논쟁들은 프로젝트의 방향을 결정지었다. 각 논쟁의 배경, 결과, 교훈을 정리한다.

마이크로커널 vs 모놀리식 (1992)

Andrew Tanenbaum과 Linus Torvalds의 유명한 논쟁. Tanenbaum은 "Linux는 시대에 뒤떨어진 모놀리식 설계"라고 비판했으나, Linus는 실용적 성능을 이유로 모놀리식을 고수했다. 결과적으로 loadable module, 네임스페이스 등 모듈화 기법으로 모놀리식의 단점을 보완하며 현재에 이르렀다.

BitKeeper 논쟁과 Git 탄생 (2002~2005)

2002년 Linus가 상용 VCS인 BitKeeper를 채택하면서 오픈소스 커뮤니티 내 논란이 시작되었다. 2005년 BitKeeper의 무료 라이선스가 철회되자 Linus가 2주 만에 Git을 개발했다. 이 사건은 분산 VCS의 혁명을 일으켰고, Git은 현재 세계에서 가장 널리 쓰이는 VCS가 되었다.

스케줄러 전쟁: O(1) vs CFS (2007)

Con Kolivas의 RSDL/BFS 스케줄러와 Ingo Molnar의 CFS(Completely Fair Scheduler) 사이의 경쟁. 결과적으로 CFS가 2.6.23에 병합되어 2024년까지 17년간 기본 스케줄러로 사용되었다. 2024년 6.6에서 Peter Zijlstra의 EEVDF가 CFS를 대체하며 새로운 시대를 열었다.

GPL 전용 심볼 논쟁 (지속)

NVIDIA 등의 바이너리 전용 드라이버가 GPL 전용 심볼(EXPORT_SYMBOL_GPL)을 사용할 수 없는 문제는 커널 라이선스 정책의 핵심 논쟁이다. Linus의 유명한 "NVIDIA, f*** you" 발언(2012)은 이 갈등을 상징한다. 2022년 NVIDIA가 커널 모듈을 오픈소스화하면서 일부 해소되었다.

Rust 도입 논쟁 (2020~현재)

C 언어 30년 전통의 커널에 Rust를 도입하는 것은 커뮤니티 내 가장 뜨거운 논쟁 중 하나이다. 메모리 안전성(Rust 지지) vs 복잡성 증가/학습 곡선(반대)의 대립이 지속되고 있다. 2022년 6.1에서 Rust 인프라가 병합되었고, 2024년부터 실제 드라이버(nova-gpu)가 작성되고 있지만, 일부 메인테이너들의 반발도 여전하다.

코드 오브 컨덕트 도입 (2018)

Linus Torvalds가 일시적으로 커널 관리를 중단하고 Linux Foundation의 Contributor Covenant를 채택한 사건. 이전의 "Code of Conflict"를 대체하여 보다 포용적인 커뮤니티 문화로의 전환을 시도했다. Linus는 자신의 공격적인 커뮤니케이션 스타일을 반성하며 복귀했다.

커널과 산업 생태계

리눅스 커널은 세계 IT 인프라의 근간이다. 서버, 클라우드, 모바일, 임베디드, 슈퍼컴퓨터까지 거의 모든 컴퓨팅 영역에서 지배적 위치를 차지한다.

시장 점유율 (2024~2025)

주요 배포판 커널 정책

Android GKI (Generic Kernel Image)

Google의 GKI는 Android 커널 파편화 문제를 해결하기 위한 핵심 프로젝트이다. 기존에는 각 제조사(삼성, 퀄컴, 미디어텍 등)가 독자적으로 포크한 커널을 사용했으나, GKI 2.0(Android 12+)부터 Google이 단일 커널 바이너리를 제공하고 벤더 모듈만 별도로 로드하는 구조로 전환했다.

# Android GKI 커널 구조

# GKI 커널 (Google 제공, 공통)
boot.img
├── kernel (vmlinuz - GKI)     # 모든 기기 공통
├── ramdisk.img                # 초기 램디스크
└── dtb                        # Device Tree Blob

# 벤더 모듈 (제조사 제공, 기기별)
vendor_boot.img
├── vendor_ramdisk.img
└── dtb (추가 오버레이)

vendor_dlkm.img
└── lib/modules/               # 벤더 커널 모듈 (.ko)
    ├── qcom_xxx.ko            # 퀄컴 SoC 드라이버
    ├── samsung_xxx.ko         # 삼성 하드웨어 드라이버
    └── camera_xxx.ko          # 카메라 HAL 드라이버

# GKI 버전 확인 (Android 기기에서)
uname -r
# 예: 6.6.30-android15-6-gxxxxxxxx

# GKI 모듈 심볼 리스트 (ABI 안정성 보장)
# android/abi_gki_aarch64.stg 파일로 관리

클라우드 커널 커스터마이징

주요 클라우드 공급자들은 자체 커널을 운영하여 가상화 성능과 보안을 최적화한다.

실시간 리눅스와 자동차/산업 분야

PREEMPT_RT의 메인라인 통합(6.12)은 자동차, 로봇, 산업 자동화 분야에서 리눅스 채택을 가속화하고 있다. 이전에는 별도의 RT 패치를 유지해야 했으나, 이제 표준 커널에서 하드 실시간을 달성할 수 있다.

# PREEMPT_RT 커널 설정 및 검증

# RT 커널 빌드 설정
make menuconfig
# General setup → Preemption Model → Fully Preemptible Kernel (RT)
# CONFIG_PREEMPT_RT=y

# RT 커널 확인
uname -a
# ...SMP PREEMPT_RT...

# 최악 지연시간 측정 (cyclictest)
cyclictest -m -p 99 -t 4 -D 60 -q
# T: 0 Min:   2 Act:   5 Avg:   4 Max:  18
# T: 1 Min:   2 Act:   4 Avg:   4 Max:  22
# Max < 50us가 일반적인 RT 성능 기준

# IRQ 스레드 확인 (RT에서는 대부분의 IRQ가 스레드화)
ps -eo pid,cls,rtprio,comm | grep irq

# RT 태스크 우선순위 설정
chrt -f 80 ./my_realtime_app      # SCHED_FIFO, 우선순위 80
chrt -r 50 ./my_realtime_app      # SCHED_RR, 우선순위 50

# CPU isolation (RT 전용 코어 확보)
# 커널 부팅 파라미터: isolcpus=2,3 nohz_full=2,3 rcu_nocbs=2,3
taskset -c 2 ./my_realtime_app    # 격리된 CPU 2에서 실행

커널 참고 도서 (역사 이해에 도움)

관련 문서

커널 역사와 함께 이해하면 유용한 문서들입니다.

• 참고자료 -- 공식 문서, 추천 도서, 컨퍼런스
• 빌드 시스템 -- Kbuild, Kconfig, 커널 설정
• 커널 아키텍처 -- 커널 전체 구조와 서브시스템
• 프로세스 스케줄러 -- O(1), CFS, EEVDF 스케줄러 변천사
• 메모리 관리 -- 메모리 서브시스템 발전사
• 개발 도구 -- Git, 빌드 도구, 디버깅
• Git -- Linus가 만든 분산 버전 관리 시스템
• Rust in Kernel -- 커널 Rust 지원 상세
• 커널 보안 -- 보안 서브시스템과 방어 기능
• Livepatch -- 재부팅 없는 커널 패칭
• 패치 제출 -- 커널 패치 작성과 제출 절차
• 코딩 스타일 -- 커널 코딩 컨벤션
• BPF/eBPF/XDP -- eBPF 서브시스템 상세
• io_uring -- 비동기 I/O 프레임워크