Linux 커널 역사와 주요 결정이 서버에 미치는 영향

Linux 커널 역사의 요약

Linux kernel의 역사는 1991년 9월 버전 0.01에서 시작해 오늘날 서버에서 부팅되는 7.x 시리즈까지 이어진다. 릴리스 목록은 이 역사에서 가장 흥미롭지 않은 부분이다. 소수의 결정이 Linux kernel의 형태를 정했고, 각 결정은 오늘 오후에 임대한 장비에도 여전히 영향을 미친다. 1991년에 새 kernel이 왜 필요했는지는 Unix의 더 긴 역사, AT&T 라이선스, 그리고 BSD의 발전을 중단시킨 소송에서 다룬다.

여기에 기재된 날짜와 버전 번호는 kernel.org와 해당 사이트가 게시하는 릴리스 이력을 따릅니다. 2026년 8월 기준 현재 상태는 다음과 같습니다. 2026년 4월 12일에 7.0이 출시되었고, 2026년 6월 14일에 7.1이 출시되었으며, 7.2는 현재 릴리스 후보(release candidate) 단계에 있습니다.

1992년 GPL 선택이 여전히 중요한 이유

버전 0.01은 1991년 9월 17일 Torvalds가 직접 작성한 라이선스로 배포되었습니다. 이 라이선스는 소스 코드 배포를 의무화했으며, 더 중요한 문구 하나를 추가했습니다. "수수료를 받고 배포할 수 없으며, '취급' 비용조차 청구할 수 없다." 1991년 당시 소프트웨어는 플로피 디스크로 배포되었으며, 플로피 디스크를 복사하고 우편으로 보내는 데는 비용이 발생했습니다. 해당 조항은 상업적인 Linux 배포를 불가능하게 만들었습니다.

그는 이를 변경했습니다. GNU General Public License (GPL)로의 전환은 1992년 1월 0.12 릴리스 노트에서 발표되었고 1992년 2월 1일부터 효력이 발생했습니다. 1992년 3월에 나온 버전 0.95는 해당 라이선스로 배포된 첫 번째 릴리스였습니다. 이후 Linux를 기반으로 구축된 모든 비즈니스는 이 변화에 기반을 두고 있습니다.

커널은 GPL 버전 2 전용이며, 버전 3로 이전한 적이 없습니다. Torvalds는 2007년에 이를 거부했는데, 주된 이유는 GPLv3의 anti-tivoisation 규칙 때문이었습니다. 이 규칙은 GPL 코드를 탑재한 장치가 해당 코드의 수정된 복사본도 수용해야 한다고 규정합니다. 그는 잠긴 하드웨어를 제조사의 고유한 권한으로 보았습니다. 2017년 커널 개발자들은 Kernel Enforcement Statement를 발표했는데, 이는 GPLv3의 한 가지 요소를 차용했습니다. 위반 사실을 통보받은 후 이를 수정한 사람은 라이선스를 영구적으로 박탈당하는 대신 라이선스를 유지할 수 있게 되었습니다.

서버 측면에서는 두 가지 결과가 따릅니다. 부팅하는 커널 바이너리는 일치하는 소스 코드에 대한 권리를 포함하므로, 누구도 검사하거나 재빌드할 수 없는 Linux 커널을 제공할 수 없습니다. 또한 커널의 저작권 고지에는 해당 라이선스가 일반적인 시스템 호출을 통해 커널 서비스를 사용하는 사용자 프로그램에는 적용되지 않는다고 명시되어 있습니다. 이것이 바로 독점 데이터베이스와 모니터링 에이전트가 아무런 문제 없이 Linux용으로 배포되는 이유입니다. 허용적인 라이선스는 이와 반대되는 압력을 생성하며, 플랫폼을 선택하기 전에 이러한 차이를 이해하는 것이 중요합니다. 서버 플랫폼으로서의 Linux와 FreeBSD를 참조하십시오.

모놀리식 커널이 실무에서 승리한 이유

1992년 1월 29일, Andrew Tanenbaum은 comp.os.minix 뉴스그룹에 "LINUX is obsolete"라는 제목의 메시지를 게시했습니다. 그는 두 가지 주장을 펼쳤습니다. 드라이버와 파일 시스템이 하나의 특권 주소 공간에서 실행되는 모놀리식 커널은 1970년대의 설계 방식이며, 이러한 구성 요소들이 일반 프로세스로 실행되는 마이크로커널이 미래라는 것이었습니다. 또한 Linux는 Intel 386에 고정되어 있어 결코 이식될 수 없을 것이라고 주장했습니다.

이식성에 대한 주장은 이식 작업을 통해 반박되었습니다. 1995년 3월의 버전 1.2에서는 Alpha, SPARC, MIPS가 추가되었습니다. 1996년 6월의 버전 2.0에서는 64비트 Alpha 포트가 추가되었습니다.

설계에 대한 주장은 타협을 통해 해결되었습니다. Linux는 마이크로커널이 되지 않았습니다. 대신 로드 가능한 커널 모듈(loadable kernel modules)을 도입했습니다. 이는 실행 중인 커널에 삽입하거나 제거할 수 있는 오브젝트 파일로, 드라이버가 커널 바이너리와 별도로 배포될 수 있게 했습니다.

lsmod | head
modinfo virtio_net | head -5

lsmod는 현재 로드된 모듈 목록을 보여줍니다. modinfo는 해당 모듈이 유래한 파일과 모듈이 허용하는 매개변수를 출력합니다. 가상 서버에서 디스크 및 네트워크 경로의 대부분은 모듈로 구성되어 있으며, 이것이 바로 하나의 커널 이미지가 이전에 만난 적 없는 하드웨어에서도 부팅될 수 있는 이유입니다. 커널은 새로운 하드웨어를 알리기만 하고, 사용자 공간 데몬이 어떤 모듈을 로드하고 장치 이름을 무엇으로 할지 결정합니다. 이것이 장치 관리가 init 시스템 내부로 들어오게 된 경위이며, systemd를 피하기 어려워진 이유 중 하나입니다.

모듈은 마이크로커널 설계가 수반하는 비용 없이 이러한 유연성을 확보했습니다. 드라이버를 별도의 프로세스로 격리하면 모든 호출마다 컨텍스트 스위칭과 메시지 전달 비용을 지불해야 하는데, 1992년 당시 그 비용은 매우 컸습니다.

Linux가 여전히 안고 있는 비용은 계획을 세울 때 고려해야 할 부분입니다. 모듈은 커널의 모든 권한을 가지고 실행되므로, 잘못된 모듈은 하나의 프로세스가 아닌 시스템 전체를 중단시킵니다. 메인라인에 포함되지 않은 외부 모듈(out-of-tree modules)에서 이러한 문제가 발생합니다. 메인라인에 포함되지 않은 벤더 드라이버는 새로운 커널이 나올 때마다 다시 빌드해야 하며, 이는 업그레이드 과정에서 DKMS가 수행하는 작업입니다. 빌드가 실패하면 재부팅 후 해당 장치를 사용할 수 없게 됩니다.

SMP 구현에 15년이 걸린 이유

1996년 6월에 발표된 Linux 2.0은 대칭형 다중 처리(SMP)를 지원한 최초의 커널입니다. 이는 하나의 커널을 여러 CPU가 동시에 실행할 수 있음을 의미합니다. 초기 구현 방식은 BKL(big kernel lock)이라는 단일 잠금을 사용하는 것이었기에, 한 번에 하나의 프로세서만 커널 코드 내부로 진입할 수 있었습니다. 따라서 두 번째 CPU는 사용자 공간에서 계산을 수행하는 작업 부하에는 도움이 되었지만, 시스템 호출이 많은 작업 부하에는 거의 도움이 되지 않았습니다. 모든 시스템 호출이 동일한 잠금 뒤에서 대기해야 했기 때문입니다.

이 잠금을 제거하는 데 15년이 걸렸습니다. Arnd Bergmann의 주도로 남은 사용자들을 세밀한 잠금(fine-grained locking) 방식으로 전환했고, 2011년 5월 18일에 발표된 2.6.39 버전에서 BKL이 완전히 삭제되었습니다. 스케줄러 역시 이와 비슷한 긴 호흡으로 발전했습니다. 2.6.0의 O(1) 스케줄러, 2007년 2.6.23부터 도입된 CFS(Completely Fair Scheduler), 그리고 2023년 10월 6.6 버전에서 CFS를 대체한 EEVDF가 그 결과물입니다.

이러한 노력 덕분에 오늘날 4 vCPU 구성은 평범한 사양이 되었습니다. 하지만 알아두어야 할 한계점도 있습니다. 공유 가상 서버 환경에서는 커널이 스레드를 스케줄링하고, 하이퍼바이저가 커널을 스케줄링합니다. top를 실행하여 %st 필드를 확인해 보십시오. Steal time은 커널이 사용할 준비가 되었음에도 호스트가 이를 다른 게스트에게 할당하여 발생한 CPU 시간입니다. 따라서 커널 내부의 어떤 튜닝으로도 이를 복구할 수 없습니다.

2.6 시리즈에서 커널 빌드 방식이 변경된 이유

2.6 이전에는 버전 번호가 쌍으로 구성되었습니다. 두 번째 숫자가 짝수이면 안정화 시리즈(2.4)를, 홀수이면 개발 시리즈(2.5)를 의미했습니다. 2.4는 2001년 1월 4일에, 2.6은 2003년 12월 17일에 출시되었으므로 사용자는 다음 안정화 시리즈를 위해 거의 3년을 기다려야 했습니다. 배포판들은 이를 기다릴 수 없어 백포트를 수행했습니다. "2.4"를 제공하는 두 벤더가 수천 개의 패치 차이가 나는 커널을 배포하는 상황이 발생했습니다.

이러한 구분은 2.6 이후 폐기되었습니다. 메인라인은 이제 약 2주간의 머지 윈도우를 열어 새로운 작업을 수용한 뒤, 릴리스 후보(release candidate) 과정을 거쳐 조용해질 때까지 진행하며, kernel.org에서 여전히 문서화하고 있는 9~10주 간격으로 릴리스를 진행합니다. 이 모델의 나머지 절반은 2005년 3월 4일, Greg Kroah-Hartman과 Chris Wright가 유지 관리하는 2.6.11에 대한 수정 전용 업데이트인 안정화 트리(stable tree)의 첫 번째 릴리스와 함께 도입되었습니다. 안정화 트리는 수정 사항만 수용하고 새로운 기능은 거부합니다.

한 가지 부작용으로, 버전 번호가 더 이상 약속의 의미를 갖지 않게 되었습니다. 3.0, 4.0, 5.0, 7.0은 재작성된 버전이 아닙니다. Torvalds는 두 번째 숫자가 커져서 거슬릴 때 첫 번째 숫자를 올리며, 이것이 2026년 4월 6.19 이후에 7.0이 나온 이유입니다. 서버 운영에서 중요한 것은 사용하는 배포판이 어떤 브랜치를 추적하는지, 그리고 해당 브랜치가 여전히 수정 사항을 제공받는지 여부입니다.

2005년 4월 BitKeeper 결별과 git의 탄생

2002년 2월부터 리눅스 커널은 2.5 시리즈를 시작으로 Larry McVoy가 설립한 BitMover사의 독점 분산 버전 관리 시스템인 BitKeeper를 사용하여 개발되었습니다. BitMover는 커널 개발자들에게 무료 라이선스를 제공했으나, 경쟁 버전 관리 도구를 개발해서는 안 되며 BitKeeper를 리버스 엔지니어링해서도 안 된다는 조건을 붙였습니다. 많은 개발자는 소스 코드를 열람할 수 없는 도구를 사용하여 자유 소프트웨어인 커널을 개발하는 상황을 달갑지 않게 여겼습니다.

2005년 4월, Andrew Tridgell이 BitKeeper 저장소와 통신하는 프로그램을 시연하면서 문제가 발생했습니다. BitMover는 이를 리버스 엔지니어링으로 간주하고 무료 라이선스를 철회했습니다. 이로 인해 커널은 개발 주기 도중에 버전 관리 시스템을 잃게 되었습니다.

git에 대한 작업은 2005년 4월 3일에 시작되었습니다. Torvalds는 4월 6일에 이를 발표했습니다. 4월 7일에는 git이 스스로를 관리하는 self-hosting 단계에 도달했으며, 이는 git의 자체 기록이 이미 git 내부에 저장되었음을 의미합니다. 4월 18일에는 여러 브랜치를 병합하는 작업이 처음으로 수행되었습니다. 2005년 6월, git은 2.6.12 릴리스를 관리했습니다. Torvalds는 얼마 지나지 않아 유지보수 권한을 Junio Hamano에게 넘기고 커널 개발로 복귀했습니다.

git의 설계는 당시의 문제 상황에서 직접적으로 도출되었습니다. 수천 명의 기여자가 존재하고, 신뢰할 수 없는 네트워크를 통해 서로의 코드를 가져와야 하는 유지보수자들의 환경이 고려되었습니다. 모든 객체는 콘텐츠의 해시값으로 이름이 지정되므로, 과거 기록의 1바이트만 변경되어도 그 이후의 모든 커밋 이름이 바뀝니다. 이것이 바로 클론(clone)이 단순한 주장이 아닌 증거가 되는 이유입니다. 오늘날의 모든 배포 파이프라인, 모든 구성 저장소, 대부분의 팀이 코드를 푸시하는 호스팅 서비스, 그리고 직접 운영할 수 있는 git 서버는 모두 커널 개발 당시의 라이선스 논쟁에서 비롯되었습니다.

LTS 모델이 보장하는 것과 그렇지 않은 것

Mainline은 운영 환경에 적합하지 않습니다. Mainline 릴리스는 9주에서 10주가 지나면 다음 버전으로 대체됩니다. Stable 트리는 각 릴리스 이후 몇 주 동안만 수정 사항을 반영합니다. 보통 LTS라고 부르는 Longterm 브랜치는 수년간 수정 사항을 반영하며, 배포판들은 이를 기반으로 빌드됩니다.

2009년 12월에 릴리스된 2.6.32 버전은 이 모델의 유효성을 입증한 사례입니다. RHEL 6, Debian 6, SUSE Linux Enterprise 11 SP1, Ubuntu 10.04 LTS 모두 이 버전을 탑재했으며, 해당 브랜치는 출시 후 6년이 넘은 2016년 2월까지 유지되었습니다. Red Hat은 한발 더 나아가 RHEL 6가 수명을 다한 2020년까지 자체 백포트를 통해 2.6.32 기반 커널을 유지했습니다. 이러한 10년간의 지원을 무료로 재현하려는 목적이 바로 CentOS가 존재했던 이유이자 Rocky Linux와 AlmaLinux가 그 자리를 대신하게 된 이유입니다.

지원 기간에 대한 약속은 여러 번 변경되었습니다. 처음에는 2년이었으나, 일부 브랜치는 6년으로 늘어났습니다. 2023년, Stable 유지보수 담당자들은 기본 지원 기간을 2년으로 단축했습니다. 오래된 트리에 백포트를 적용하는 데 드는 유지보수 비용이 크고, 오래된 브랜치는 실제 테스트가 거의 이루어지지 않기 때문입니다. 2026년 2월 25일, Greg Kroah-Hartman은 해당 브랜치에 의존하는 기업들과의 논의를 거쳐 더 긴 지원 계획을 다시 발표했으며, 현재 프레임워크는 3년에서 6년의 지원 기간을 제공합니다.

[
  {
    "kernel": "5.10",
    "released": "2020-12-13",
    "eol_projected": "Dec 2026",
    "maintained_for": 6.0
  },
  {
    "kernel": "5.15",
    "released": "2021-10-31",
    "eol_projected": "Dec 2026",
    "maintained_for": 5.1
  },
  {
    "kernel": "6.1",
    "released": "2022-12-11",
    "eol_projected": "Dec 2027",
    "maintained_for": 5.0
  },
  {
    "kernel": "6.6",
    "released": "2023-10-29",
    "eol_projected": "Dec 2027",
    "maintained_for": 4.2
  },
  {
    "kernel": "6.12",
    "released": "2024-11-17",
    "eol_projected": "Dec 2028",
    "maintained_for": 4.1
  },
  {
    "kernel": "6.18",
    "released": "2025-11-30",
    "eol_projected": "Dec 2028",
    "maintained_for": 3.1
  }
]

kernel.org에 따르면 2026년 8월 기준으로 6개의 Longterm 브랜치가 존재합니다. 가장 오래된 5.10 버전은 Dec 2026에 종료될 때까지 6.0년간 수정 사항을 반영하게 됩니다. 가장 최신인 6.18 버전은 Dec 2028까지 지원될 예정이며, 이는 3.1년간의 수정 사항을 포함합니다.

이 날짜들은 확정된 계약이라기보다 최소한의 보장 기간으로 이해해야 합니다. 6.6 및 6.12 버전의 지원 종료일은 2026년 2월에 모두 연장되었으며, 반대로 아무도 사용하지 않는 브랜치는 조기에 종료될 수도 있습니다. 일반적으로 배포판이 이 선택을 대신해 줍니다. Debian 13은 6.12 버전을, Ubuntu 26.04 LTS는 7.0 버전을 탑재합니다. 이 간극이 바로 서버 운영 시 LTS와 중간 릴리스 사이의 실질적인 차이이며, Ubuntu 24.04를 26.04로 업그레이드할 때 시스템 내부에서 실제로 변화하는 핵심 요소입니다.

이와 관련하여 주의할 점이 하나 있습니다. Ubuntu 24.04에서 uname -r 명령을 실행하면 6.8.0-51-generic과 같은 결과가 출력됩니다. 이는 업스트림 베이스에 배포판 자체의 백포트가 추가된 버전이므로, 해당 숫자는 브랜치의 시작점일 뿐 실제 포함된 수정 사항을 모두 나타내지는 않습니다. 커널 버전을 문자열로만 판단하는 스캐너들이 배포판 커널에 대해 잘못된 경고를 생성하는 이유가 바로 이것입니다.

현재 커널에서 논의 중인 쟁점

두 가지 논쟁이 진행 중이며, 모두 누가 작업을 수행할 것인가에 관한 문제입니다.

Rust는 2022년 12월 6.1 버전에서 인프라로 도입되었습니다. 7.0 버전에서 실험적이라는 꼬리표가 제거됨에 따라, 이제 커널의 핵심 언어는 C, 어셈블리, Rust가 되었으며 빌드 시 더 이상 nightly 컴파일러가 필요하지 않습니다. 논쟁의 핵심은 유지보수입니다. 인터페이스를 변경하는 C 메인테이너는 자신이 읽지 않는 Rust 바인딩을 손상시킬 수 있으며, 이를 복구하는 작업이 누구의 책임인지에 대해 의견이 갈리고 있습니다.

두 번째 논쟁은 AI 기여에 관한 것입니다. Sasha Levin은 기계가 보조한 패치가 메일링 리스트에 급증하자 2025년 7월 정책을 제안했습니다. 해당 문서는 2025년 12월 23일에 커밋되었으며, 현재 커널의 자체 프로세스 문서인 docs.kernel.org/process/coding-assistants.html에 명시되어 있습니다. AI 에이전트는 Signed-off-by 태그를 추가해서는 안 됩니다. 해당 행은 DCO(Developer Certificate of Origin)를 인증하는 것이며, 오직 사람만이 이를 인증할 수 있기 때문입니다. 도구는 저자가 아니라는 점을 고려하여 리뷰 과정에서 Co-developed-by:에서 변경된 Assisted-by: 태그를 사용하여 지원 사실을 명시해야 합니다. 생성된 코드는 반드시 GPL-2.0-only와 호환되어야 합니다. 패치를 제출하는 사람은 해당 코드를 검토하고 그에 대한 책임을 집니다.

이 정책의 배경에는 리뷰 시간에 대한 부담이 있습니다. 패치를 생성하는 데는 몇 초가 걸리지만, 메인테이너가 이를 검토하는 데는 오후 내내 시간이 소요됩니다. 태그 하나가 이러한 불균형을 해결해주지는 않습니다. 이 정책이 보존하고자 하는 것은 출처입니다. 즉, 각 변경 사항에 대해 누가 서명했는지 기록을 유지하는 것이며, 이는 2004년 DCO가 도입된 목적이기도 합니다.

이 역사가 귀하가 임대하는 서버에 갖는 의미

• 라이선스는 귀하가 제공업체가 부팅하는 커널을 읽고 재빌드할 수 있는 이유이며, 독점 소프트웨어가 여전히 그 위에서 실행되는 이유입니다.
• 모놀리식 설계는 드라이버 버그 하나가 전체 머신을 재부팅하게 만드는 이유이며, out-of-tree 모듈을 커널 업그레이드마다 다시 빌드해야 하는 이유입니다.
• 릴리스 모델은 버전 번호가 의미하는 바가 적은 반면, 브랜치와 해당 브랜치의 지원 종료(end-of-life) 날짜가 거의 모든 것을 말해주는 이유입니다.
• 가상화 유형은 귀하가 수행할 수 있는 작업을 결정합니다. KVM에서는 자체 커널을 부팅하고 모듈을 로드할 수 있지만, 호스트 커널을 공유하는 컨테이너 가상화 환경에서는 uname -r이 호스트 버전을 표시하고, modprobe는 실패하며, 일부 sysctl은 읽기 전용으로 설정됩니다.

FAQ

Linux 커널은 왜 GPLv3가 아닌 GPLv2를 유지합니까?

Torvalds는 2007년에 GPLv3 도입을 거부했습니다. 주된 이유는 GPL 코드가 포함된 장치가 수정된 코드도 실행할 수 있어야 한다는 'anti-tivoisation' 조항 때문입니다. 그는 하드웨어 잠금 여부를 제조사의 고유 권한으로 봅니다. 또한 커널 저작권은 수천 명의 기여자가 나누어 가지고 있으며 저작권 양도 계약도 존재하지 않으므로, 사실상 라이선스 변경은 불가능합니다. 커널은 GPL-2.0-only 라이선스를 따르므로 GPLv3로만 제공되는 코드는 병합할 수 없습니다.

Linux 커널은 모놀리식 커널입니까, 마이크로커널입니까?

모듈을 로드할 수 있는 모놀리식 커널입니다. 드라이버와 파일 시스템은 커널 주소 공간에서 실행되며, lsmod 명령으로 현재 로드된 모듈을 확인할 수 있습니다. 이 구조는 성능 면에서 유리하지만, 모듈에 결함이 생기면 시스템 전체가 패닉에 빠질 수 있다는 단점이 있습니다. 마이크로커널이라면 해당 프로세스만 종료되었을 상황입니다. 1992년 이후 사용자 공간에서 동작하는 FUSE 파일 시스템과 커널이 실행 전 검증하는 eBPF 프로그램 도입으로 이러한 경계는 다소 완화되었습니다.

메인라인, 스테이블, 롱텀 커널의 차이는 무엇입니까?

메인라인은 Torvalds가 관리하는 트리로 9~10주마다 릴리스되며 새로운 기능이 가장 먼저 추가됩니다. 스테이블은 가장 최근의 메인라인 릴리스를 기반으로 몇 주간 버그 수정을 진행합니다. 롱텀 브랜치는 수년간 수정 사항을 제공하며, 배포판 커널의 기반이 됩니다. kernel.org에서 현재 롱텀 브랜치 목록과 각 브랜치의 예상 지원 종료일을 확인할 수 있습니다.

Linux 커널은 AI가 작성한 코드를 허용합니까?

네, 2025년 12월에 확정된 정책에 따라 허용합니다. 사용된 도구는 Assisted-by: 태그에 명시해야 하며, AI 에이전트가 Signed-off-by 라인을 추가해서는 안 됩니다. 생성된 코드는 GPL-2.0-only와 호환되어야 합니다. 제출하는 인간 기여자가 직접 서명(sign-off)해야 하며, 이는 해당 패치를 검토했고 Developer Certificate of Origin에 따라 책임을 진다는 의미입니다.

서버에는 어떤 커널 버전을 사용해야 합니까?

대부분의 경우 배포판에서 유지 관리하는 커널을 사용해야 합니다. 배포판 커널은 롱텀 브랜치에 백포트된 수정 사항과 공급업체의 테스트가 더해진 버전이며, 제공업체의 이미지와 기술 지원 계약이 이를 기준으로 합니다. 특정 드라이버나 기능이 필요할 때만 최신 메인라인 커널을 빌드하십시오. 전환하려는 브랜치의 지원 종료일을 반드시 확인한 뒤 결정하십시오.