커널 역사 (Kernel History)

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

1991년 탄생부터 현재까지, 리눅스 커널의 진화 과정을 버전별 릴리즈와 주요 변경사항으로 정리합니다. 스케줄러(Scheduler) 교체, 실시간(Real-time) PREEMPT_RT 통합, Rust 도입 같은 핵심 변천을 함께 다룹니다.

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

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

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

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

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

커널 버전 연대표

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

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

0.01 (1991년 9월)

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

• 지원 하드웨어: 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 전환으로 자유로운 배포가 가능해졌습니다. 가상 메모리(Virtual Memory)(스왑(Swap)) 지원이 추가되었습니다.

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 소켓(Socket) 인터페이스)
• 파일시스템: 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: 세분화된 잠금(Lock)(fine-grained locking) 도입
• IPv6 초기 지원 (실험적)
• 대용량 메모리 지원 개선 (2GB 이상)
• 향상된 네트워킹 성능
• 약 1,800,000줄의 코드

2.4 (2001년 1월 4일)

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

• USB 서브시스템: 대중적인 USB 장치 지원
• ext3: 저널링(Journaling) 파일시스템 (ext2 호환)
• iptables / Netfilter: ipchains 대체, stateful 방화벽(Firewall)
• 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: 커널 코드 실행 중 선점(Preemption) 가능
• 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이 도입된 릴리즈. 재부팅 없이 커널 코드를 패치(Patch)할 수 있는 인프라로, 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: 새로운 페이지(Page) 교체 알고리즘, 기존 LRU 대비 성능 향상
• Maple Tree: VMA 관리용 새로운 자료구조
• User-space 스택 언와인딩 지원
• LTS 릴리즈

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

7.x -- 새로운 시대

7.0 (2026년 4월 12일)

6.19 이후 버전 번호가 7.0으로 점프한 릴리즈입니다. Linus Torvalds의 관례대로 마이너 번호가 19에 도달하면 메이저 번호를 올리는 방식이며, 기술적 단절(breaking change)은 없습니다. 7.0은 Rust의 실험 딱지 제거, sched_ext 정식 통합, XFS 자가 복구 등 여러 장기 프로젝트의 완성을 포함합니다.

핵심 변경사항

• Rust stable: 2022년 6.0에서 시작된 Rust 실험이 공식 종료되었습니다. Rust는 이제 C와 동등한 1급 언어로 인정되며, 서브시스템 메인테이너 재량으로 Rust 드라이버/모듈을 수용할 수 있습니다. 2025년 Linux Kernel Maintainers Summit에서 합의된 결정입니다.
• sched_ext 정식 통합: eBPF 프로그램으로 스케줄러 정책을 교체할 수 있는 확장형 스케줄링 프레임워크가 정식 포함되었습니다. 하이브리드 아키텍처(Intel Nova Lake 등)를 대상으로 재설계된 태스크(Task) 스케줄러와 결합됩니다.
• XFS 자가 복구(Autonomous Self-Healing): XFS 파일시스템이 메타데이터(Metadata) 손상을 자동으로 감지하고 복구하는 기능이 추가되었습니다.
• AI 코딩 문서화: 커널 개발에 AI 도구를 사용할 때의 정책이 공식 문서화되었습니다. AI 기여는 Assisted-by 태그로 표기하며, 제출자가 전체 책임을 집니다.

성능 개선

• 스레드(Thread) 생성/해제 10~16% 가속: PID 할당 알고리즘 개선
• 파일 열기/닫기 4~16% 개선: 멀티코어 환경에서 잠금 경합(Lock Contention) 최소화
• Swap Phase II: 6.18에서 시작된 스왑 서브시스템 재구조화의 2단계, 메모리 압박 상황에서 처리량 추가 향상
• ZRAM 압축 writeback: 압축된 페이지를 직접 물리 디스크에 기록하여 불필요한 압축 해제 사이클(CPU/배터리 낭비) 제거
• AMD EPYC 스케줄러 확장성 최적화, 메모리 관리 성능 개선

하드웨어 지원

• ARM: 64-byte atomic 로드/스토어(FEAT_LS64, ARMv8.7+), Rockchip RK3576/RK3588 H.264/H.265 디코더, Qualcomm Snapdragon 7s Gen 3/Kaanapali, MediaTek Dimensity 6300/9200, Raspberry Pi BCM2712 RNG/Watchdog
• RISC-V: Zicfiss/Zicfilp 제어 흐름 무결성, SpacemiT K3 8/16코어, Alibaba T-Head TH1520 CPUFreq
• x86: Intel Nova Lake 지원 확대, Intel TSX auto 모드 기본화, AMD EPYC 5 KVM 지원

네트워킹 및 보안

• AccECN(Accurate ECN): TCP 혼잡 알림 프로토콜 개선
• Wi-Fi 8/UHR(802.11bn): 초기 지원 시작
• VSOCK 네트워크 네임스페이스 지원
• ML-DSA 포스트 양자 서명 검증(Signature Verification) 지원
• SELinux BPF 토큰(Token) 접근 제어 업데이트
• fserror 인프라: 파일시스템의 메타데이터 손상/I/O 오류를 사용자 공간에 표준화하여 보고하는 범용 프레임워크

파일시스템

• Btrfs: 페이지 크기보다 큰 블록 크기의 Direct I/O 지원, remap-tree 기능 초기 지원
• EXT4: 병렬 Direct I/O 쓰기 성능 향상
• XFS: 자가 복구(self-healing) 지원

스케줄러 변천사

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

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, 네트워크 대역폭(Bandwidth) 등의 자원 한도를 설정할 수 있습니다.

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

eBPF (3.18~현재)

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

io_uring (5.1~현재)

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

• 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의 주도로, 모든 스핀락(Spinlock)을 RT-mutex로 대체하고 인터럽트(Interrupt)를 스레드화하여 결정적(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

주제별 변경 이력 모음

개별 문서마다 장문의 버전별 변경 이력을 반복해서 두면, 동일한 릴리즈 정보를 여러 곳에서 중복 관리해야 합니다. 이 섹션은 그런 중복을 줄이기 위해 주요 주제의 연대기성 변경 이력을 한곳에 모아 정리한 것입니다. 각 문서에서는 현재 동작을 이해하는 데 필요한 버전 차이만 간단히 남기고, 상세한 연혁은 여기에서 이어서 확인하면 됩니다.

Context Switching 관련 변경 이력

Context Switching 문서에서 자주 참고하는 최근 변경 이력을 간단히 모으면 다음과 같습니다.

Wireless 관련 변경 이력

Wireless 문서의 긴 버전표는 무선 세대 전환과 커널 지원 진화를 이해하는 데 유용하지만, 실제로는 연대기 정보의 비중이 큽니다. 핵심 흐름은 아래 표로 한곳에 정리합니다.

Bluetooth 관련 변경 이력

Bluetooth 문서의 버전별 이력도 연대기 중심 정보이므로 이 페이지에 함께 배치합니다. Bluetooth는 LE Audio와 ISO 전송, 그리고 hci_sync.c 전환이 큰 분기점입니다.

Wait/Wound Mutex 관련 변경 이력

Wait/Wound Mutex 문서는 DRM과 GPU 예약 객체 경로에 밀접하게 연결되어 있어 버전별 변화가 많지만, 긴 타임라인 자체는 이곳에 모으는 편이 문서 구조상 더 안정적입니다.

디버깅 도구 관련 변경 이력

디버깅 & 트러블슈팅 문서는 최신 커널의 sanitizer, drgn, RV, BPF 디버깅 흐름을 폭넓게 다루기 때문에 연대기 표가 길어지기 쉽습니다. 주요 변화는 다음과 같이 중앙에서 관리합니다.

perf 관련 변경 이력

perf 문서는 툴 사용법 자체보다 최신 PMU와 언와인딩 인프라 변화 때문에 버전표가 커집니다. 릴리즈별 흐름은 아래 표로 모읍니다.

GPU / DRM 관련 변경 이력

GPU (DRM/KMS) 문서는 2025~2026년 드라이버 머지와 가속기 확장 때문에 릴리즈 매트릭스가 커졌습니다. 주요 줄기는 다음과 같습니다.

VirtIO 관련 변경 이력

virtio / vhost 문서는 최근 릴리즈의 기능 추가를 한눈에 보는 용도로 버전표가 컸습니다. 그 정보는 중앙 문서로 옮겨 관리합니다.

Serial / TTY 관련 변경 이력

Serial/TTY 문서의 최신 동향 표 역시 연대기 정보 비중이 높습니다. 핵심 변화는 다음과 같습니다.

Ethernet PHY / phylink 관련 변경 이력

이더넷 PHY 문서는 포팅과 드라이버 작성 관점에서 버전별 API 차이를 자주 참고하므로, 순수 연대기 표는 이곳에 모아 관리합니다.

타이머 관련 최근 변경 이력

타이머 문서는 버전 차이가 현재 동작 설명과 직접 붙어 있는 경우가 많아서 대부분의 설명을 현지 문서에 유지합니다. 다만 순수 릴리즈 흐름만 보면 다음과 같습니다.

ACPI 관련 변경 이력

ACPI 문서는 규격 자체의 역사와 최신 커널 수용 흐름이 모두 길기 때문에, 순수 연대기 정보는 이곳에 모아 관리합니다.

VFIO / mdev 관련 변경 이력

VFIO & mdev 문서는 최근 몇 년간 IOMMUFD로의 전환이 워낙 커서 연혁 자체가 별도 축이 되었습니다. 핵심 흐름은 다음과 같습니다.

Linux Bridge 관련 최근 변경 이력

Linux Bridge 문서는 운영 시나리오와 버그 수정이 강하게 결합되어 있어 대부분을 현지 문서에 유지합니다. 다만 최근 릴리즈 기준 분기점은 아래와 같습니다.

네임스페이스 관련 최근 변경 이력

네임스페이스 문서에는 예제와 운영 영향 설명을 남기고, 여기에는 최근 버전별 분기점만 정리합니다.

Livepatch 관련 최근 변경 이력

Livepatch 문서에는 consistency model과 작성 패턴을 남기고, 긴 버전 흐름은 여기로 모읍니다.

KASAN / Sanitizer 관련 최근 변경 이력

KASAN 문서에는 탐지 모델과 운영 선택 기준을 남기고, Sanitizer 계열의 최신 버전표는 여기로 모읍니다.

Time Namespace 관련 최근 변경 이력

Time Namespace 문서에는 CRIU, 기밀 VM, OCI 활용 설명을 남기고 주변 인프라 버전표는 여기로 모읍니다.

가상화 / KVM 관련 최근 변경 이력

가상화 문서에는 기밀 VM 운용, 성능 확장성, 사용자 공간 조합 설명을 남기고, 최근 릴리즈 흐름은 여기로 모읍니다.

Futex 관련 최근 변경 이력

Futex 문서에는 futex2 API, NT 동기화, 프록시 실행 설명을 남기고, 최근 버전표는 여기로 모읍니다.

RT Mutex 관련 최근 변경 이력

RT Mutex 문서에는 PI 체인과 Proxy Execution 관계 설명을 남기고, 최근 릴리즈 흐름은 여기로 모읍니다.

Red-Black Tree 관련 최근 변경 이력

Red-Black Tree 문서에는 자료구조 선택 기준을 남기고, 최근 버전 흐름은 여기로 모읍니다.

IDR / IDA 관련 최근 변경 이력

IDR / IDA 문서에는 XArray 전환 배경과 사용 지침을 남기고, 최근 릴리즈 흐름은 여기로 모읍니다.

Ring Buffer 관련 최근 변경 이력

Ring Buffer 문서에는 persistent buffer, zero-copy, BPF 연계 설명을 남기고, 버전표는 여기로 모읍니다.

CAN / SocketCAN 관련 최근 변경 이력

CAN Bus 문서에는 CAN-XL, ISO-TP, J1939 운용 설명을 남기고, 최근 릴리즈 표는 여기로 모읍니다.

IIO 관련 최근 변경 이력

IIO 문서에는 backend, cyclic DMA, DMABUF 활용 설명을 남기고, 최근 버전표는 여기로 모읍니다.

Intel PCM 관련 최근 변경 이력

Intel PCM 문서에는 TPMI, CXL 모니터링, perf와의 역할 분담 설명을 남기고, 플랫폼 지원 연혁은 여기로 모읍니다.

Watchdog 관련 최근 변경 이력

Watchdog 문서에는 pretimeout, secure watchdog, SCMI 운용 설명을 남기고, 최근 릴리즈 표는 여기로 모읍니다.

RAPL / Powercap 관련 최근 변경 이력

RAPL & powercap 문서에는 TPMI, PLR, DTPM, AMD RAPL 활용 설명을 남기고, 최근 릴리즈 흐름은 여기로 모읍니다.

IRQ Domain / MSI 도메인 관련 최근 변경 이력

IRQ Domain 문서에는 계층형 도메인과 드라이버 전환 설명을 남기고, 최근 구조 변화의 버전표는 여기로 모읍니다.

개발 통계 상세

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

디렉토리별 코드 비중 변화

릴리즈 주기 통계

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

# 릴리즈 간 커밋 수
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로 발전했습니다.

커널 빌드 시스템(Build System) 변천

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

# 커널 빌드 기본 명령어

# 설정
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]'

미래 전망

리눅스 커널은 35년 이상의 역사를 통해 지속적으로 발전해왔으며, 7.0 출시(2026-04)를 기점으로 새로운 시대가 열렸습니다. Rust의 공식화와 sched_ext의 정식 통합은 향후 커널 개발의 방향을 근본적으로 바꿀 이정표입니다.

기술적 방향성

거버넌스 과제

• 후계 구도: Linus Torvalds의 은퇴 후 커널 관리 체계에 대한 논의가 지속되고 있습니다
• 다양성: 기여자 다양성 확대(지역, 성별, 배경)를 위한 노력
• 개발 도구: 메일링 리스트 중심 워크플로우의 현대화 논의 (GitLab/Forge 등)
• AI 코드 기여: 7.0에서 AI 코딩 정책이 공식 문서화되었으나, AI 생성 코드의 품질 검증 자동화와 저작권 문제는 여전히 활발한 논의 중입니다. Linus는 AI 도구가 커널의 코너 케이스를 더 많이 발견하게 될 것이라고 전망했습니다
• 보안 공개: 취약점 공개 프로세스 개선, CVE 할당 체계 정비
• LTS 지원 연장: Greg KH가 2026-02에 6.6/6.12/6.18의 LTS 지원 기간을 연장했으며, 기업 요구에 맞춘 유연한 지원 정책 논의가 계속됩니다

메모리 관리 진화

리눅스 커널의 메모리 관리 서브시스템은 초기 단순한 페이지 할당에서 현대의 정교한 다층 메모리 관리 체계로 발전했습니다. 이 변천사는 하드웨어 발전(대용량 메모리, 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에서 도입된 페이지 캐시(Page Cache) 관리 단위로, 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

가상화 지원 변천

리눅스는 세계에서 가장 널리 사용되는 하이퍼바이저(Hypervisor) 호스트 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에서 시작하여 현재의 정교한 트레이싱/프로파일링(Profiling) 프레임워크로 발전했습니다. 이 변천사는 커널 개발 문화와 소프트웨어 공학의 진보를 반영합니다.

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

# === 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 인프라의 근간입니다. 서버, 클라우드, 모바일, 임베디드, 슈퍼컴퓨터까지 거의 모든 컴퓨팅 영역에서 지배적 위치를 차지합니다.

시장 점유율 (2025~2026)

주요 배포판 커널 정책

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에서 실행

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

참고자료

커널 공식 문서 및 아카이브

• The Linux Kernel Archives — 커널 공식 배포 사이트, 모든 릴리즈 타르볼과 변경 이력
• HOWTO do Linux kernel development — 커널 개발 참여 방법 공식 가이드
• A guide to the Kernel Development Process — 머지 윈도우, RC, 릴리즈 사이클 상세 설명
• Everything you ever wanted to know about Linux -stable releases — Stable/LTS 패치 선정 기준과 백포트 규칙
• Submitting patches: the essential guide — 패치 형식, 커밋 메시지, Signed-off-by 규칙
• Kernel Maintainer Handbooks — 서브시스템별 메인테이너 역할과 운영 가이드
• Linux Kernel Code of Conduct — 2018년 채택된 커뮤니티 행동 강령
• git.kernel.org — 커널 공식 Git 저장소 브라우저 (Linus 트리, 서브시스템 트리)

LWN.net 역사 관련 기사

• A 20-year timeline of Linux (2011) — 리눅스 20주년 주요 이정표 정리
• How the development process works (2014) — 커널 개발 프로세스 심층 분석
• Rust in the Linux Kernel (2020) — Rust for Linux 프로젝트 초기 논의
• The kernel's command line (2015) — 커널 부트 파라미터의 진화
• How the kernel is tested (2015) — 커널 테스트 인프라 발전사
• LWN.net Kernel Page — 매주 업데이트되는 커널 개발 뉴스와 분석

역사 및 문화 자료

• A Brief History of Linux — 카네기 멜론 대학의 리눅스 역사 요약
• Linux Foundation — Kernel Development Reports — Linux Foundation의 연례 커널 개발 통계 보고서
• Linux Kernel History Report — 커널 개발 참여자, 기업 기여도 통계
• lore.kernel.org (LKML) — 리눅스 커널 메일링 리스트 아카이브, 모든 기술 토론 원문
• KernelNewbies — Linux Versions — 버전별 주요 기능 변경사항 정리 (인간 친화적 요약)
• KernelNewbies — Linux Changes — 최신 커널 릴리즈 변경사항 상세

버전 관리와 Git 역사

• A Short History of Git — Linus Torvalds가 Git을 만든 배경과 BitKeeper 사건
• Linus Torvalds: Git (Google Tech Talk, 2007) — Git 설계 철학을 설명하는 유명 발표
• Linus Torvalds announces Linux 0.01 — 1991년 최초 리눅스 공개 메일 원문

컨퍼런스 및 발표

• Linux Plumbers Conference (YouTube) — 커널 플러머 컨퍼런스 발표 영상
• Kernel Recipes — 유럽 커널 개발자 컨퍼런스, 역사적 회고 발표 다수
• Linux Foundation (YouTube) — Linux Foundation 주최 컨퍼런스 발표 영상
• Open Source Summit — Linux Foundation 주최 오픈소스 서밋

서적

• Just for Fun: The Story of an Accidental Revolutionary (Linus Torvalds, David Diamond, 2001) — 리눅스 탄생 자서전
• Rebel Code: Linux and the Open Source Revolution (Glyn Moody, 2001) — 리눅스와 오픈소스 운동의 역사
• Free as in Freedom (Sam Williams, 2002) — Richard Stallman과 GNU 프로젝트 이야기
• The Cathedral and the Bazaar (Eric S. Raymond, 1999) — 오픈소스 개발 모델 분석의 고전
• Linux Kernel Development, 3rd ed. (Robert Love, 2010) — 커널 개발 입문서의 표준
• Understanding the Linux Kernel, 3rd ed. (Bovet & Cesati, 2005) — 2.6 커널 내부 구조 바이블

관련 문서

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

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