데비안 11 “Bullseye”는 2026년 8월 31일에 지원 종료됩니다. 관리자를 위한 실용 가이드

끝없는 라이프사이클 지원 | ~10분 소요

주요 요점

• 데비안 11에 대한 무료 보안 지원은 2026년 8월 31일에 종료되며, 이때 자원봉사자 LTS 팀이 Bullseye에 대한 지원을 중단합니다. 데비안 자체 보안 팀은 이미 2024년 8월에 지원을 중단했습니다.
• 지원되지 않는 OS는 취약점 스캐너가 반환할 수 있는 가장 심각한 결과이며, 이는 PCI DSS, HIPAA, SOC 2 및 FedRAMP 준수 의무를 위태롭게 합니다.
• 데비안 12로 먼저 업그레이드한 다음 데비안 13으로 업그레이드하는 2단계 과정이 진정한 해결책입니다. 마감일 전에 이를 완료할 수 없는 경우, 데비안 11용 TuxCare 엔드리스 라이프사이클 지원 는 Bullseye에 패치를 지속적으로 적용하여, 사용자가 원하는 시기에 업그레이드를 진행할 수 있도록 지원합니다.

세 명의 데비안 관리자에게 Bullseye의 지원 종료 시기가 정확히 언제인지 물어보면, 세 가지 서로 다른 날짜를 듣게 될 수도 있습니다. 이는 부주의 때문이 아닙니다. 이는 데비안이 릴리스를 지원하는 방식에서 비롯된 부작용입니다. 릴리스의 수명 주기 동안 지원 업무가 여러 사람의 손을 거치며, ‘지원’이라는 단어의 의미가 매번 인계될 때마다 은연중에 바뀌기 때문입니다. 데비안 11의 경우, 중요한 날짜는 2026년 8월 31일입니다. 바로 그날, 자원봉사자들로 구성된 장기 지원(LTS) 팀이 패치 제공을 중단하며, Bullseye를 위한 무료 보안 업데이트의 마지막 공급원이 마르게 됩니다.

자정이 되어도 별다른 일은 일어나지 않습니다. apt는 여전히 작동하고, 서비스들도 여전히 응답합니다. 달라지는 점은, 지난 5년 동안 여러분이 의지해 온 CVE 수정 패치의 꾸준한 공급이 갑자기 중단되고, 새로 공개되는 모든 취약점에 대한 책임이 여러분에게 돌아온다는 것입니다.

이 가이드에서는 마감일이 실제로 어떤 변화를 가져오는지, 패치가 적용되지 않은 데비안 호스트가 겉보기에 비해 훨씬 더 큰 위험 요소인 이유, 그리고 Bullseye에서 벗어나는 네 가지 방법(급하게 업그레이드하는 것이 잘못된 선택인 경우를 포함하여)에 대해 단계별로 설명합니다.

데비안 지원이 실제로 어떻게 이루어지는지

데비안 릴리스에는 단일 지원 기간이 주어지는 것이 아닙니다. 대신 단계적인 지원 체계가 적용됩니다. 대략 처음 3년 동안은 데비안 보안 팀이 직접 수정 사항을 처리하며, 이것이 바로 대부분의 사람들이 상상하는 “전체” 지원입니다. 다음 안정판이 출시되면, 이전 버전은 장기 지원(LTS) 팀으로 이관됩니다. 이 팀은 자원봉사자와 후원 기업으로 구성된 별도의 조직으로, 출시 후 약 5년 동안 지원을 연장해 주지만, 엄선된 일부 패키지와 아키텍처에 한해서만 지원합니다. 그 이후에는 Freexian의 상용 확장 LTS 프로그램을 통해 업데이트를 10년까지 연장할 수 있지만, 이는 데비안 본체와는 별개의 서비스입니다.

Bullseye는 현재 해당 릴레이의 마지막 무료 지원 단계에 접어들었습니다. 이 버전은 2021년 8월 14일에 출시되었으며, 2024년 8월에 보안 팀의 완전한 지원을 종료했고, 2026년 8월 31일까지 자원봉사자 주도 LTS로 운영됩니다. 데비안 LTS는 패키지와 아키텍처 모두에서 지원 범위를 좁히기 때문에(Bullseye LTS는 i386, amd64, armhf, arm64로 제한됨), 특정 호스트의 일부 구성 요소는 이미 지원 대상에서 제외되었을 수 있습니다. debian-security-support 패키지를 설치하면 설치된 패키지 중 더 이상 지원되지 않는 패키지가 표시되므로, 추측하기보다는 직접 확인하시기 바랍니다. 

2026년 6월 현재, 최근 출시된 제품들의 현황은 다음과 같습니다:

이 표는 또한 명백한 업그레이드 대상이 왜 바뀌었는지도 보여줍니다. Buster(10)는 이미 종료되었으며, Bookworm(12)은 2026년 7월 11일에 정규 지원이 종료된 후 자체 LTS 단계로 진입합니다. 이로 인해 Trixie(13)가 가장 긴 안정적 운영 기간을 가진 릴리스로 남게 됩니다. 현재 Bullseye에서 마이그레이션 중인 팀에게 Bookworm은 필수적인 중간 단계일 수 있지만, 장기적인 관점에서 보면 Trixie가 더 나은 최종 목적지입니다.

그림 1. Bullseye에서 출발하는 각 경로는 서로 다른 범위의 패치 커버리지를 제공합니다. 무료 옵션이 먼저 종료됩니다.

데비안 11의 지원 종료가 의미하는 바 

서버가 계속 가동되고 있기 때문에, 마감일을 별일 아닌 것처럼 여기는 경우가 많습니다. 하지만 결코 그렇지 않습니다. 이에 따른 비용은 보안, 규정 준수, 그리고 Bullseye를 둘러싼 생태계라는 세 가지 영역에 걸쳐 발생합니다.

새로운 CVE가 발생할 때마다 이는 여러분의 문제가 됩니다

보안을 최우선으로 생각하십시오. 데비안(Debian)의 보안 수정 사항은 공개적으로 개발되므로, 지원되는 릴리스에 패치가 적용되는 순간 누구나 커밋 내용을 확인하고, 정확히 어떤 줄이 변경되었는지 파악하며, 이를 통해 수정된 버그가 무엇인지 추론할 수 있습니다. 유지보수가 이루어지는 시스템에서는 수정 사항이 이미 배포된 상태이므로 이는 무해합니다. 하지만 Bullseye에서는, 그와 동일한 공개 커밋이 무료 팁 시트와 다름없습니다. 취약한 코드가 여전히 서버에 남아 있는 상태에서, 이제 그 내용이 상세히 문서화되어 있기 때문입니다. 이러한 정보를 실제 작동하는 익스플로잇으로 전환하는 데는 예전에는 상당한 리버스 엔지니어링 시간이 소요되었습니다. AI가 번거로운 작업을 대신해 주면서 그 시간은 계속 단축되고 있으며, “패치가 공개된 시점”과 “익스플로잇이 유포되기 시작하는 시점” 사이의 안전 간격은 점점 좁아지고 있습니다.

운영 체제는 다른 모든 구성 요소의 기반이 되기 때문에, 보안 사고의 파급 범위가 광범위합니다. 커널, OpenSSL 또는 다른 패키지에 있는 수정되지 않은 취약점은 특정 서비스에만 국한되지 않고, 호스트와 그 위에서 실행되는 모든 것을 위험에 노출시킵니다.

그림 2. 지원되는 릴리스에 대한 공개 수정 프로그램은, 공격자들이 패치가 적용되지 않은 버전을 공격할 때 이용하는 표적이 됩니다.

감사관들이 근거가 없는 OS를 지적하다

규정 준수 위험은 취약점이 악용될 때까지 기다려주지 않습니다. 대부분의 취약점 스캐너는 호스트에서 OS 버전을 직접 읽어들이기 때문에, 8월 31일 이후에는 Bullseye가 설치된 시스템들이 스캔 결과에서 “지원되지 않는 운영 체제”로 표시되기 시작할 것입니다.

PCI DSS는 알려진 취약점에 대해 정해진 주기에 따라 패치를 적용할 것을 요구합니다. SOC 2 심사관들은 지원 종료(EOL)된 구성 요소를 통제 격차로 간주합니다. HIPAA와 FedRAMP 모두 문서화된 패치 적용 및 취약점 관리를 중시하는데, 기반이 되는 운영 체제가 더 이상 수정 프로그램을 제공받지 않게 되면 이를 입증하기가 훨씬 더 어려워집니다. 지원이 중단된 배포판 하나만으로도 본래는 체계적이었던 인프라 전반에 걸쳐 문제점이 산재할 수 있으며, 사이버 보험사들은 이미 지원 종료된 소프트웨어를 보험 적용 제외 항목에 직접 명시하기 시작했습니다.

생태계는 당신 없이도 계속 돌아갑니다

Bullseye를 둘러싼 생태계도 변화하고 있습니다. 패키지 관리자와 타사 apt 저장소들은 Bullseye용 빌드를 중단하고 있습니다. 공식 컨테이너 이미지는 Bookworm과 Trixie 기반으로 재구축됩니다. 구성 관리 모듈, 모니터링 에이전트, 언어 런타임은 11 버전에 대한 테스트를 중단합니다. 이 모든 것이 사소한 불편을 초래합니다. 이러한 문제들이 몇 분기 동안 쌓이면서 Bullseye는 점차 굳어집니다. 새로운 종속성마다 고정(pin)이나 우회 조치가 필요해지며, 미루고 있던 업그레이드는 시간이 지날수록 더 큰 비용이 들 수 있습니다.

불스아이에서 벗어나는 네 가지 방법

정답은 하나만 있는 것이 아닙니다. 어떤 방식을 선택할지는 시스템의 중요도, 감당할 수 있는 운영 부하량, 그리고 클린 업그레이드를 현실적으로 기한 내에 완료할 수 있는지 여부에 따라 달라집니다. 아래의 흐름도는 선택지를 빠르게 좁혀주며, 각 옵션에 대한 자세한 내용은 그 뒤에 설명되어 있습니다.

그림 3. 결정을 좁히는 빠른 방법. 자체 유지 관리는 이를 담당할 인력을 확보할 수 있는 팀이 거의 없기 때문에 제외되었다.

Debian 12로 업그레이드한 다음, Debian 13으로 업그레이드하세요

이것이 모든 Bullseye 호스트가 목표로 삼아야 할 방향이며, 많은 시스템의 경우 지금 시작하는 것이 올바른 선택입니다. 데비안(Debian)에만 해당되는 까다로운 점은 한 번에 여러 버전을 건너뛸 수 없다는 것입니다. 지원되는 인플레이스 업그레이드는 한 번에 한 릴리스씩 진행되므로, 11 버전에서 벗어나려면 두 번의 dist-upgrade를 연속으로 수행해야 하며, 각 단계마다 변경된 기본 설정, 제거된 패키지, 재설정해야 할 타사 저장소가 존재합니다. Bookworm 자체가 곧 LTS 단계에 진입할 예정이므로, 가장 긴 준비 기간을 확보하고 싶다면 Trixie를 목표로 삼으십시오. 이를 본격적인 프로젝트로 간주하십시오: 클론 환경에서 미리 테스트하고, 각 단계 전환 전에 스냅샷을 생성하며, 서비스가 예상대로 복구되지 않을 경우를 대비해 롤백을 준비해 두십시오.

Freexian에서 Debian Extended LTS 구매하기

데비안 LTS 운영에 깊이 관여하고 있는 기업인 Freexian은 2031년 6월 30일까지 Bullseye의 보안 업데이트를 지원하는 상용 확장 LTS 프로그램을 판매하고 있습니다. 이 프로그램의 매력은 간단합니다. 바로 11 버전을 계속 사용하며 업그레이드를 완전히 건너뛸 수 있다는 점입니다. 이 프로그램이 적합한지는 세 가지 세부 사항에 따라 결정됩니다. 지원 범위는 패키지 목록으로 한정되며, 고정된 기본 세트는 항상 지원되지만 그 외의 항목은 패키지별로 별도 견적이 산정됩니다. 또한 일부 패키지는 제한적인 지원만 받거나 아예 지원되지 않을 수도 있습니다. Freexian이 공개한 비용 모델에 따르면, 가격은 6개월마다 상승하는데, 기간 전반부에는 완만하게 오르다가 다른 고객들이 이탈함에 따라 후반부에는 급격히 치솟습니다. 또한 커널은 현재 사용 중인 버전을 그대로 유지하는 대신, 이후 데비안(Debian) 릴리스에서 백포트된 최신 커널 버전으로 전환함으로써 최신 상태를 유지합니다. 지원 대상 패키지를 사용 중이며, 비용 상승과 가끔 발생하는 커널 버전 변경을 감수할 수 있는 호스트 소유자에게는 시간을 벌 수 있는 타당한 방법입니다.

패치는 직접 관리하세요

이론적으로는 CVE를 추적하고 수정 사항을 자체 재빌드에 역포트할 수 있습니다. 운영 체제의 경우, 이는 커널, C 라이브러리, 그리고 수십 개의 서비스에 걸친 보안 유지 관리를, 자신이 정한 일정이 아닌 공격자가 정한 일정에 맞춰 수행해야 함을 의미합니다. 이를 제대로 수행할 수 있는 인력과 C 및 C++에 대한 심도 있는 전문 지식을 갖춘 조직은 극소수에 불과합니다. 대다수의 조직은 그렇지 못하며, 인력이 부족한 상태에서 이를 시도하는 것은 ‘할 수 없다’고 인정하는 것보다 더 위험합니다. 왜냐하면 실질적인 대비책 없이 단지 대비가 되어 있는 듯한 착각만 불러일으키기 때문입니다.

TuxCare ELS로 Bullseye의 기능을 확장하세요

마감 기한 전에 업그레이드를 무사히 완료할 수 없는 경우, 이것이 대개 가장 실용적인 선택지입니다. TuxCare의 Debian 11용 ‘Endless Lifecycle Support’ 는 LTS 지원 종료 후에도 기존 Bullseye 설치 환경에 패치를 계속 제공합니다.

TuxCare는 CVE를 추적하고, 수정 사항을 백포트하여 apt를 통해 서명된 패키지로 배포합니다. 이 서비스는 광범위한 서버 패키지 목록을 다루며, 사용자를 최신 버전으로 전환시키는 대신 이미 실행 중인 커널에 패치를 적용합니다. 이는 앞서 언급한 Freexian의 접근 방식과는 정반대입니다. 목록에 아직 포함되지 않은 패키지를 요청할 수도 있습니다. 호스트는 간단한 스크립트를 통해 TuxCare 저장소에 연결되며, 재부팅이나 dist-upgrade 없이도 기존 패키지 워크플로우를 통해 패치가 적용됩니다.

TuxCare는 에라타 및 OVAL 데이터도 공개하므로, OpenSCAP 및 기타 OVAL 호환 도구를 통해 해당 호스트의 패치 상태를 계속 확인할 수 있습니다. 가격은 계약 기간 내내 고정되어 있으므로, 릴리스가 오래되어도 비용이 상승하지 않습니다.

사실 여러분이 구매하는 것은 ‘시기’입니다. ELS는 “보안 유지”와 “업그레이드 완료”를 분리하므로, 더 이상 고정된 일정에 따라 엔지니어링 작업을 계획할 필요가 없습니다. 이 방식은 업그레이드를 8월 31일 이전에 완료할 수 없는 경우, 감사관이 지속적으로 문서화된 패치 적용 내역을 확인해야 하는 경우, 또는 시스템이 충분히 안정적이어서 서둘러 두 단계에 걸쳐 업그레이드를 진행할 경우 오히려 더 큰 위험이 따르는 경우에 그 진가를 발휘합니다.

신속한 업그레이드가 잘못된 선택일 때

슬라이드 상에서는 “그냥 업그레이드하면 된다”는 말이 항상 통합니다. 하지만 실제 인프라 환경에서는 몇 가지 요인으로 인해, 사람들이 예상하는 것보다 훨씬 더 자주 이것이 잘못된 첫 번째 조치가 되곤 합니다.

이 두 단계가 가장 까다로운 부분입니다. Bullseye에서 Trixie로 넘어가려면 먼저 Bookworm을 거쳐야 하는데, dist-upgrade를 할 때마다 기본값이 변경되고 패키지가 제거되며, 타사 저장소의 경로를 다시 지정하거나 교체해야 할 수도 있습니다. 심지어 일부 저장소는 Bullseye에서 Bookworm으로 이어지는 경로가 아예 없을 수도 있습니다. 이는 마치 고고학 작업을 하는 것과 같으며, 마감 기한에 맞추기 위해 서둘러 처리할 수 있는 일이 아닙니다.

마감 기한에 쫓겨 진행하는 마이그레이션은 겉보이는 것보다 더 많은 비용이 듭니다. 시간에 쫓겨 진행되는 업그레이드는 잘못된 구성 설정을 배포하고, 예외적인 경우를 간과하며, 테스트 과정을 생략하게 됩니다. 그 결과는 다음 분기에 사고 발생과 당직 근무 시간 증가라는 형태로 나타나게 되며, 1년간의 연장 지원 비용을 포함하더라도 차분하게 계획된 업그레이드에 드는 비용보다 훨씬 더 큰 부담을 안겨주는 경우가 많습니다.

이번 분기에 모든 호스트가 업그레이드 대상이 되는 것은 아닙니다. 가전 제품이나 고정된 워크로드를 실행하는 장비, 혹은 이미 교체 예정인 장비군은 당장 두 단계에 걸친 OS 마이그레이션을 진행할 만한 타당한 이유가 없을 수 있습니다. 계획된 변경이 이루어질 때까지 해당 장비들을 Bullseye 패치로 최신 상태를 유지하는 것은 회피가 아니라 건전한 엔지니어링 방식입니다.

데비안 11의 개발 중단

2026년 8월 31일은 확정된 날짜입니다. 이 날짜가 지나면 Bullseye에 대한 무료 패치 제공이 종료되며, 이후 발생하는 모든 새로운 CVE는 여전히 해당 버전을 사용 중인 사용자에게 귀속됩니다. Debian 12로, 그리고 이어서 Debian 13으로 전환하는 것이 올바른 방향이며, 지금부터 준비하는 것이 좋습니다. 제때 전환하지 못하거나, 아직 시스템 중단이 정당화되지 않는 서버의 경우, TuxCare의 Debian 11용 Endless Lifecycle Support 를 이용하면 재부팅이나 버전 변경 없이 apt를 통해 패치를 계속 적용받을 수 있습니다.

이 내용을 귀하의 부동산 상황에 적용하고 싶으시다면, TuxCare 전문가와 상담하여 마감일 이후에도 계속 운영해야 할 호스트에 대해 상의해 보세요. 목표는 달력이 대신 정해 주는 것이 아니라, 직접 마이그레이션 날짜를 정하는 것입니다.

요약

기사 이름

데비안 11 “Bullseye” 지원 종료

설명

마감일이 실제로 어떤 변화를 가져오는지, 패치가 적용되지 않은 데비안 호스트가 겉보이는 것보다 더 큰 위험 요소인 이유, 그리고 Bullseye에서 벗어나는 네 가지 방법을 살펴보겠습니다.

작성자

아르템 카라세프

게시자 이름

TuxCare

게시자 로고