요약

  • 리눅스 안정 버전 패치는 업스트림 존재와 검토 기준을 통과해야 하며, 장기 지원은 오래된 코드를 얼마나 오래 유지관리할 수 있는지라는 별개의 질문을 던집니다.
  • Kernel.org는 이 수명 시야를 다운스트림 수요와 유지관리자 가용성에 따른 것으로 설명하므로, 예상 종료일은 벤더의 지원 약속이 아닙니다.

오래된 커널은 처음 출시된 지 오랜 후에도 기기에 유용할 수 있습니다. 그러나 모든 제안된 수정이 그 안정 브랜치에 속하는 것은 아니며, 제품이 판매되는 기간 동안 브랜치가 유지관리된다는 보장도 없습니다. 리눅스에는 여기서 두 개의 관문이 있고, 이를 혼동하면 유용한 라벨이 허위 약속으로 바뀝니다.

첫 번째 관문은 개별 패치에 적용됩니다. 안정 커널 규칙은 수정(또는 동등한 수정)이 이미 메인라인에 존재해야 하고, 명백히 올바르고 테스트되었으며, 컨텍스트를 포함해 100줄 이내여야 하고, 패치 제출 규칙을 따르며, 실제 사용자 문제를 해결하거나 기기 ID를 추가해야 한다고 요구합니다. 예로는 크래시, 정지, 데이터 손상, 실질 보안 문제, 하드웨어 특성, 빌드 오류가 있습니다. 이 규칙은 악용 방법에 대한 설명 없이 추측성 문제를 제출한 경우와 사용자 이득이 없는 변경을 거부합니다. 이러한 한계는 백포트를 검사하기 쉽게 만들고, 이미 사용 중인 브랜치에 새 장애가 유입될 위험을 줄입니다.안정 커널 규칙은 이 기준과 제출 경로를 명시합니다.

이 필터를 통과하는 것이 검토를 건너뛴다는 뜻은 아닙니다. 문서화된 절차에서는 수락된 후보가 대기열로 보내지고, 개발자와 해당 서브시스템 유지관리자의 검토가 요청되며, 그 결과가 릴리스 후보에서 테스트됩니다. 검토자가 반대하면 패치가 제외될 수 있습니다. 따라서 메인라인 우선은 출처(provenance) 요건일 뿐, 모든 이후 커널이 해당 수정을 받을 것이라는 자동 약속이 아닙니다. 패치는 여전히 대상 계열에 실질적으로 적용되고 그곳에서 검토를 통과해야 합니다.

두 번째 관문은 브랜치 자체의 수명입니다. Kernel.org는 장기(long-term) 계열을 중요한 버그 수정을 받는 오래된 트리로, 보통 활성 안정 릴리스보다 덜 빈번하게 배포된다고 설명합니다. 릴리스 지침에 따르면 선택은 주요 기능, 상용 배포판의 필요, 기기 제조업체의 수요, 유지관리자의 작업량과 가용성을 반영합니다. 새 장기 계열은 산업 관심이 충분해 더 긴 유지관리를 뒷받침하면 연장될 수 있는 예상 종료일과 함께 시작됩니다. 이 예상은 명시적으로 고정되지 않았습니다. 이 기사를 위해 가져온 페이지는 2026년 2월 25일자로 표시되어 있으며, 정책 문구는 유용하지만 표시된 릴리스 목록은 2026년 10월 시점의 스냅샷이 아닙니다.Kernel.org의 릴리스 페이지가 선택 요소와 예상 정책의 출처입니다.

여기서 Greg Kroah-Hartman의 역할이, 그를 시스템 전부로 만들지 않으면서 중요해집니다. Linux Foundation은 그를 Fellow이자 리눅스 안정 브랜치 및 여러 서브시스템의 유지관리자로 식별합니다. 커널 개발 프로세스 문서는 Greg와 Sasha Levin을 안정 팀으로 명명하면서, 관련 유지관리자와 검토자도 패치 검토에 참여한다고 밝힙니다. 2018년 인터뷰에서 Greg는 2005년 안정 커널 릴리스가 시작될 때 자원했다고 회상했습니다. 그는 동시에 유지관리하던 트리 수가 늘어났다고 말하며, 그 일을 현장 기기의 보안 강화와 연결했습니다. 이는 그의 회고일 뿐, 현재의 브랜치 수를 세어준 것이 아니며 그가 단독으로 각 장기 계열을 선택한다는 증거도 아닙니다.Linux Foundation 프로필,커널 개발 프로세스,Greg의 인터뷰가 이 역할과 그 한계를 밝힙니다.

운영자 입장에서는 이 구분이 지원 라벨이 말해줄 수 있는 것을 바꿉니다. kernel.org 장기 브랜치는 커뮤니티 유지관리 계열입니다. 배포판은 이를 기반으로 한 커널을 배포하거나 추가 변경을 포함하거나, 자체 일정으로 다른 커널을 유지관리할 수 있습니다. Kernel.org는 배포판 빌드 사용자에게 해당 배포판의 지원 채널로 안내하고, 커널 개발자는 그런 빌드를 지원하지 않을 수 있다고 말합니다. 따라서 운영자는 배포 이미지에 담긴 정확한 커널을 누가 유지관리하는지, 어떤 보안·회귀 경로가 적용되는지, 벤더의 약속이 제품의 운영 수명까지 닿는지를 확인해야 합니다. LTS 라벨만으로는 이 계약적 질문에 어느 하나도 답하지 못합니다.Kernel.org의 FAQ와 릴리스 페이지가 이 지원 표면들을 구분합니다.

경제적 메커니즘은 단순하지만 버전 번호 뒤에 숨기 쉽습니다. 지원되는 계열이 하나 늘 때마다 작업이 생깁니다. 누군가 제안된 수정을 평가하고, 백포트를 확인하고, 릴리스를 테스트하고, 회귀가 나타나면 대응해야 합니다. 공개 페이지는 이 작업의 시간이나 비용을 게시하지 않습니다. 다만 다운스트림 수요와 유지관리자 가용성이 어느 계열이 더 오래 주목받는지에 영향을 준다는 점은 보여줍니다. 산업 수요는 이 노력을 정당화하는 데 도움될 수 있지만, 그것을 수행할 사람의 필요를 없애지는 못합니다.

Lu Heng의 Note 64는 유용한 분석적 시험을 제공합니다. 조정 문서는 미래 상태를 서술할 수 있지만, 그것만으로 그 상태를 작동 가능하게 만들지는 않습니다. 여기서 리눅스는 그 노트 아래 설계된 시스템으로 제시되지 않습니다. 하나의 관점으로만 적용하면, 이 구분은 "장기"와 예상 종료일이 스스로 집행되는 보증이 아닌 이유를 설명하는 데 도움이 됩니다. 그것은 계속 채택되고 유지관리되어야 하는 지원 합의를 서술할 뿐입니다.Note 64는 분석적 참조일 뿐, 커널 정책에 대한 증거가 아닙니다.

분석

두 관문은 서로 다른 수준에서 위험을 배분합니다. 패치 규칙은 기존 브랜치에 무엇이 들어올 수 있는지를 제한하고, 장기 선택은 유지관리 커뮤니티가 얼마나 많은 오래된 브랜치를 계속 감당할 수 있는지를 제한합니다. 더 엄격한 패치 필터가 수년치 인력 역량을 만들어낼 수는 없고, 강한 산업 수요가 검토되지 않은 백포트를 안전하게 만들 수도 없습니다. 실질적 약속은 수정과 유지관리 계열이 모두 지속 가능한 곳에서만 존재합니다.

그 결과 지원 수명 시야는 변하는 연합에 민감해집니다. 기기 제조업체는 이미 현장에 배치된 하드웨어를 위해 오래된 커널이 필요할 수 있고, 배포판은 릴리스를 위한 안정 기반이 필요할 수 있으며, 유지관리자는 검토와 테스트에 쓸 시간이 있어야 합니다. 공개 자료는 이러한 기여가 어떻게 나뉘는지, 어느 참여자의 협상력을 정량화하지 않습니다. 다만 지원 기간이 버전 번호의 나이만이 아니라 수요와 가용 인력에 의해 형성된다는 점은 보여줍니다.

출처