Linux Kernel은 GitHub Pull Request가 아닌 메일링 리스트(Mailing List) 를 중심으로 개발되는 대표적인 오픈소스 프로젝트입니다.
처음 Linux Kernel 개발을 접하는 사람들은 “왜 GitHub가 아니라 이메일을 사용할까?”라는 의문을 가지곤 합니다. 하지만 Linux Kernel은 수십 년 동안 메일링 리스트 기반의 개발 문화를 유지해 왔으며, 지금도 대부분의 패치 제출과 코드 리뷰가 이메일을 통해 이루어지고 있습니다.
이 중심에 있는 것이 바로 LKML(Linux Kernel Mailing List) 입니다.
이번 글에서는 LKML의 개념부터 커널 개발 프로세스, 패치 제출 과정, 코드 리뷰 문화, Maintainer의 역할까지 실무 중심으로 자세히 알아보겠습니다.
LKML이란?
LKML은 Linux Kernel 개발자들이 패치와 기술적인 논의를 공유하는 공식 메일링 리스트입니다.
전체 구조는 다음과 같습니다.
Developer
↓
Patch
↓
LKML
↓
Review
↓
Maintainer
↓
MergeLinux Kernel과 관련된 거의 모든 개발 활동이 이곳에서 이루어집니다.
왜 GitHub 대신 이메일을 사용할까?
Linux Kernel 프로젝트는 GitHub보다 훨씬 이전부터 개발되었습니다.
이메일 기반 개발의 장점은 다음과 같습니다.
- 전 세계 어디서나 접근 가능
- 특정 플랫폼에 종속되지 않음
- Patch 기반 리뷰에 최적화
- 메일 스레드(Thread)로 토론 가능
- 수십 년간 유지된 개발 문화
현재도 GitHub는 미러 저장소 역할만 하며 공식 개발 채널은 아닙니다.
LKML 개발 구조
전체 개발 흐름은 다음과 같습니다.
Developer
↓
Git Commit
↓
git format-patch
↓
Send Email
↓
LKML
↓
Review
↓
v2 Patch
↓
Maintainer
↓
Linus Torvalds
↓
Mainline Kernel패치는 여러 차례 리뷰를 거쳐 메인라인 커널에 반영됩니다.
Kernel Maintainer란?
Maintainer는 특정 기능이나 서브시스템을 관리하는 개발자입니다.
예를 들면
- Scheduler Maintainer
- Memory Maintainer
- Networking Maintainer
- Filesystem Maintainer
- BPF Maintainer
- USB Maintainer
각 Maintainer는 자신이 담당하는 코드의 품질을 관리합니다.
Linus Torvalds의 역할
많은 사람들이 Linus Torvalds가 모든 코드를 직접 리뷰한다고 생각하지만 실제로는 그렇지 않습니다.
구조는 다음과 같습니다.
Developer
↓
Maintainer
↓
Subsystem Tree
↓
Linus Tree
↓
ReleaseLinus는 각 Maintainer가 검토한 변경 사항을 최종적으로 병합하는 역할을 수행합니다.
Patch 제출 과정
일반적인 Patch 제출 절차는 다음과 같습니다.
- 코드 수정
- Commit 생성
git format-patch- 메일 작성
- LKML 전송
- 코드 리뷰
- 수정(v2, v3…)
- Maintainer 승인
- Mainline Merge
한 번에 병합되는 경우는 매우 드물며, 여러 차례 수정이 이루어지는 것이 일반적입니다.
git send-email
Patch는 일반적으로 다음 명령으로 전송합니다.
git send-email *.patch이 명령은 Patch 파일을 이메일 형태로 전송합니다.
Patch 버전 관리
리뷰 후 수정되면 새로운 버전을 제출합니다.
예를 들어
v1
↓
Review
↓
v2
↓
Review
↓
v3
↓
MergedPatch 제목에도 버전이 표시됩니다.
[PATCH v2] net: Fix memory leakCommit Message의 중요성
Linux Kernel에서는 코드만큼 Commit Message도 중요합니다.
좋은 Commit Message는 다음 내용을 포함합니다.
- 문제 설명
- 원인 분석
- 해결 방법
- 변경 이유
- 영향 범위
코드보다 설명이 부족하면 리뷰에서 반려되는 경우도 많습니다.
Signed-off-by
Kernel Patch에는 일반적으로 다음과 같은 문구가 포함됩니다.
Signed-off-by: Hong Gil Dong <hong@example.com>이는 개발자가 해당 코드를 제출할 권한이 있으며, Developer Certificate of Origin(DCO)에 동의한다는 의미입니다.
자동 추가
git commit -sReviewed-by
코드 리뷰가 완료되면 다음과 같은 태그가 추가될 수 있습니다.
Reviewed-by:
Tested-by:
Acked-by:
Reported-by:각 태그는 리뷰와 테스트 과정을 기록하는 역할을 합니다.
Patch Review 문화
Linux Kernel에서는 매우 엄격한 리뷰 문화가 존재합니다.
대표적인 검토 항목은 다음과 같습니다.
- Coding Style
- 성능 영향
- 메모리 사용
- Lock 처리
- 동시성 문제
- ABI 호환성
- 기존 코드와의 일관성
기능이 정상적으로 동작하더라도 코드 품질이 부족하면 병합되지 않을 수 있습니다.
Linux Coding Style
커널에는 공식 코딩 스타일이 존재합니다.
대표적인 예는 다음과 같습니다.
- Tab 사용
- 80열 권장
- 명확한 변수명
- 간결한 함수
- 불필요한 매크로 지양
Maintainer는 이러한 규칙도 함께 검토합니다.
Patch가 반려되는 이유
대표적인 반려 사유는 다음과 같습니다.
- Commit Message 부족
- Coding Style 위반
- 성능 저하
- 테스트 부족
- 기존 기능 손상
- 보안 문제
- 설계 문제
반려는 흔한 과정이며, 대부분 수정 후 다시 제출합니다.
Merge Window
Linux Kernel은 일정한 릴리스 주기를 따릅니다.
일반적인 흐름은 다음과 같습니다.
Release
↓
Merge Window
↓
RC1
↓
RC2
↓
RC3
↓
...
↓
Stable Release새로운 기능은 Merge Window 기간에만 병합됩니다.
실무에서 자주 사용하는 명령어
Commit 생성
git commit -sPatch 생성
git format-patch HEAD~1Patch 전송
git send-email *.patch최근 Commit 확인
git log --onelinePatch 적용
git am 0001.patchCommit 내용 확인
git show실무 사례
예를 들어 메모리 관리 코드에서 작은 버그를 수정했다고 가정해 보겠습니다.
실제 개발 과정은 다음과 같습니다.
- 버그 수정 후
git commit -s실행 git format-patch로 패치 생성git send-email을 통해 LKML과 관련 Maintainer에게 전송- 리뷰어가 성능 개선 의견과 코드 스타일 수정 요청
- 수정 후
[PATCH v2]로 다시 제출 Reviewed-by태그 획득- Maintainer가 자신의 트리에 병합
- Merge Window 기간에 Linus Torvalds가 메인라인 커널에 병합
이처럼 Linux Kernel 개발은 단순히 코드를 작성하는 것이 아니라 리뷰와 토론을 거치는 협업 중심의 개발 문화로 이루어져 있습니다.
자주 묻는 질문
Linux Kernel은 왜 GitHub Pull Request를 사용하지 않나요?
Linux Kernel은 GitHub가 등장하기 훨씬 이전부터 메일링 리스트 기반으로 개발되어 왔습니다. 이메일은 특정 플랫폼에 종속되지 않고 Patch 기반 협업에 적합하기 때문에 현재도 공식 개발 방식으로 유지되고 있습니다.
Maintainer와 Linus Torvalds의 역할은 무엇인가요?
Maintainer는 자신이 담당하는 서브시스템의 코드를 검토하고 관리합니다. Linus Torvalds는 각 Maintainer가 검토한 변경 사항을 최종적으로 메인라인 커널에 병합하는 역할을 수행합니다.
Patch가 한 번에 승인되는 경우도 있나요?
가능하지만 드뭅니다. 대부분의 Patch는 리뷰 과정에서 여러 차례 수정 요청을 받으며, v2, v3와 같은 새로운 버전으로 다시 제출한 뒤 최종 승인됩니다.
마무리
LKML은 Linux Kernel 개발의 중심이 되는 공식 협업 채널입니다. 개발자는 git format-patch와 git send-email을 이용해 패치를 제출하고, Maintainer와 커뮤니티의 엄격한 리뷰를 거쳐 메인라인 커널에 반영됩니다. 이러한 메일링 리스트 기반 개발 문화는 Linux Kernel이 오랜 기간 높은 품질과 안정성을 유지할 수 있었던 핵심 요소 중 하나입니다.