Ubuntu 22.04 지원 종료: 주요 일정, 위험 요소 및 향후 조치

주요 내용

• Ubuntu 22.04 LTS(Jammy Jellyfish)에 대한 Canonical의 표준 보안 유지보수는 2027년 5월에 종료됩니다.
• 22.04 버전을 계속 사용하는 시스템은 정상적으로 작동하지만, 무료 보안 패치는 더 이상 제공되지 않습니다.
• Ubuntu 24.04로 업그레이드한 다음 26.04 LTS로 업그레이드하는 것이 장기적으로 볼 때 가장 깔끔한 해결책입니다.
• 만약 그 공격이 제때 적중하지 못한다면, TuxCare의 끝없는 라이프사이클 지원 을 통해 지속적으로 패치를 제공해 드립니다.

22.04 서버들은 여전히 부팅됩니다. 여전히 트래픽을 처리하고, 모든 상태 점검도 통과합니다. 그런데 바로 그게 문제입니다. 우분투 22.04의 지원 종료는 서비스 중단으로 나타나지 않습니다. 표준 보안 유지보수는 2027년 5월에 종료되지만, 무료 패치 제공이 조용히 중단되는 동안 서버들은 여전히 쉼 없이 돌아갈 뿐입니다.

이 기사에서는 정확한 라이프사이클 일정, 지원이 종료되면 실제로 어떤 기능이 작동하지 않게 되는지(그리고 어떤 기능은 계속 작동하는지), 마이그레이션이 대개 계획보다 더 오래 걸리는 이유, 그리고 지원 종료일 이후에도 패치를 계속 적용받을 수 있는 구체적인 방안들을 다룹니다.

알아두어야 할 우분투 22.04 지원 주기 일정

Ubuntu 22.04 LTS(Jammy Jellyfish)는 2022년 4월 21일에 출시되었습니다. 다른 모든 LTS 릴리스와 마찬가지로, main 저장소의 패키지에 대해 5년간의 표준 보안 유지보수가 제공되며, 여기에 선택적으로 유료 연장 서비스를 추가할 수 있습니다. 전체 일정을 한눈에 확인해 보세요.

단계	날짜	그 의미는
일반 출시	4월 21, 2022	첫 번째 LTS 릴리스
표준 보안 유지보수 종료	5월 2027	메인 정거장을 위한 무료 CVE 패치
Ubuntu Pro ESM 지원 종료	5월 2032	유료 ESM은 메인 및 유니버스를 포괄합니다.
'레거시' 확장팩 관련 보도 종료	5월 2037	최종 유급 연장, 총 15년

가장 중요한 날짜는 2027년 5월입니다. 그 시점까지는, `apt upgrade` 명령어는 우분투 저장소에서 무료 보안 패치를 가져옵니다. 그 이후부터는 Ubuntu Pro와 같은 확장 지원으로 전환하지 않는 한, main 저장소의 패키지는 더 이상 이러한 수정 사항을 받지 못하게 됩니다. 시스템은 계속 작동합니다. 단지 무료로 수정되는 것만 중단될 뿐입니다.

Ubuntu 22.04의 지원 기간이 종료되면 어떻게 되나요?

수명 종료는 조용히 넘길 수 있는 유연한 기한이 아닙니다. 수명 종료 시점이 도래하는 순간, 여전히 가동 중인 모든 22.04 시스템의 위험 프로필이 변화합니다. 하드웨어와 워크로드는 동일하지만, 위협 표면은 달라집니다. 이러한 위험 요소들은 누적되며, 현 상태를 유지하는 한 매달 그 위험이 가중됩니다.

1. 패치되지 않은 CVE는 영구적으로 남게 됩니다

2027년 5월 이후에 공개된 취약점은 더 이상 22.04 버전의 표준 보안 유지보수를 통해 수정되지 않습니다. 어떤 형태의 확장 지원도 없다면, 이러한 취약점은 익스플로잇 코드가 공개된 후에도 포함해 무기한으로 패치되지 않은 채 방치됩니다. 관련 규모를 가늠해 보자면, LinuxCVETracker에 따르면 2026년 기준 4,800건 이상의 리눅스 커널 CVE가 기록되었으며 8월 말 기준으로 4,800건 이상의 리눅스 커널 CVE를 기록했으며, 이 중 359건은 ‘Critical(치명적)’, 1,896건은 ‘High(높음)’ 등급으로 분류되었습니다.

그 중 하나는 이미 이론에서 실제 적용 단계로 넘어갔습니다. “Copy Fail”이라는 별명이 붙은 CVE-2026-31431는 2026년 5월 1일 CISA의 ‘알려진 악용 취약점(KEV)’ 목록에 추가되었습니다. 이는 2017년 커널 변경으로 인해 발생한 로컬 권한 상승 결함으로, 권한이 없는 로컬 사용자가 루트 권한을 바로 획득할 수 있게 하며, CVSS 점수는 7.8(HIGH)을 기록하고 있습니다.

그건 1년 치이며, 커널만 포함된 것입니다. TuxCare의 ‘2026년 오픈소스 현황 보고서’ 에 따르면, 사이버 보안 사고를 보고한 조직 중 61.4%가 해당 사고가 패치가 이미 제공되었음에도 불구하고 단순히 적용되지 않았을 때 발생했다고 답했습니다. 지원 기간이 연장되지 않는다면, 패치가 늦게 나온 것이 아닙니다. 표준 경로를 통해 패치가 전혀 제공되지 않을 수도 있습니다.

2. 규정 준수 감사를 통과하기가 점점 더 어려워지고 있다

PCI DSS, HIPAA, SOC 2, 그리고 GDPR 모두 사용자가 알려진 취약점을 관리하고 적절한 보안 통제 조치를 유지하도록 요구하며, 지원 종료된 운영 체제 을 사용하면 이러한 요건을 충족한다는 주장을 펼치기가 훨씬 더 어려워집니다. PCI DSS는 이 점에 대해 가장 명확하게 규정하고 있습니다. 지원이 중단된 소프트웨어는 패치 적용 요건을 충족하기 어렵게 만들 수 있으며, 적절하게 설계된 대체 통제 수단이 때로는 허용되기도 하지만, 해당 제약 사항을 문서화하고 해당 통제 수단이 실제로 위험을 해소한다는 것을 입증해야 합니다. 이는 시스템을 패치 가능한 상태로 유지하는 것보다 훨씬 더 큰 규정 준수 부담을 의미합니다.

하류 비용 역시 이론적인 것이 아닙니다. 2026년 IBM 데이터 유출 비용 보고서 에 따르면, 전 세계 평균 데이터 유출 사고 비용은 전년 대비 12% 증가한 사상 최고치인 499만 달러로 집계되었습니다.

3. 소프트웨어 생태계가 당신을 뒤처지게 만든다

이 문제는 서서히 스며들기 때문에 사람들이 이를 과소평가하기 쉽습니다. 모니터링 에이전트는 구버전에 대한 지원을 중단합니다. 최신 언어 런타임은 노후화된 시스템 라이브러리를 기반으로 빌드되지 않습니다. 결국, 공급업체 지원팀조차도 지원 종료(EOL)된 시스템에 대한 문제 해결 요청을 처리하지 않게 되며, 그때쯤이면 이미 눈 감고 시스템을 운영하게 됩니다.

이주가 항상 쉬운 일만은 아닌 이유

문서상으로는 업그레이드가 단 한 번의 명령어로 끝날 것처럼 보입니다. 하지만 실제로는 하나의 프로젝트이며, 그 범위를 파악하다 보면 항상 단순한 버전 업데이트 이상의 작업이 드러나게 마련입니다. 이 과정에서 스택이 기반이 되는 OS에 대해 은연중에 가정해 온 모든 사항들이 표면화됩니다. 다음은 ‘빠른 업그레이드’를 계획 기간의 4분의 1이나 소요되는 작업으로 바꾸어 버리는 세 가지 걸림돌입니다.

LTS 업그레이드는 순차적으로 이루어집니다.

22.04에서 최신 LTS 버전으로 바로 업그레이드할 수는 없습니다. 우분투의 업그레이드 경로는 한 번에 한 릴리스씩 진행되므로, 22.04에서 우분투 26.04로 가려면 먼저 24.04를 거쳐야 합니다. 캐노니컬이 공개한 26.04 릴리스 노트에도 이 점이 명확히 명시되어 있습니다.

sudo do-release-upgrade

각 단계는 그 자체로 테스트 및 검증 주기를 이루며, 각 단계마다 고유한 오류가 발생할 수 있습니다. 26.04 버전까지 온사이트 업그레이드 방식을 적용할 경우, 업그레이드 과정을 한 번이 아닌 두 번으로 예상하고 예산을 책정해야 합니다. 대규모 환경의 경우, 새로운 인프라에 대상 LTS 버전을 새로 설치한 후 구성 관리를 통해 재배포하는 방식이 더 깔끔한 접근법이며, 이 방법은 온사이트 업그레이드 과정을 완전히 생략합니다.

전문가 팁: 다음 사항을 확인하세요. Prompt=lts 가 /etc/update-manager/release-upgrades 파일에Prompt=lts가 설정되어 있는지 확인하세요. LTS 설치 환경에서는 이것이 기본값입니다. LTS에서 LTS로의 경로는 대상 릴리스가 첫 번째 소수점 릴리스에 도달해야만 열리므로 이 점을 유의하십시오. 다음 명령을 실행하세요. do-release-upgrade -c 를 실행하여 업그레이드를 시작하지 않고도 다음 릴리스가 실제로 사용 가능한지 확인할 수 있습니다.

새로운 기반에서 애플리케이션이 작동하지 않습니다

OS 업그레이드 자체는 거의 문제가 되지 않습니다. 문제는 그 위에 설치된 앱들입니다. 22.04에서 24.04로 업그레이드하면 Python, OpenSSL, 그리고 수십 개의 시스템 라이브러리가 한 번에 여러 버전씩 업데이트되는데, 이전 버전의 동작 방식에 의존하던 코드는 실행 시점이 되어서야 드러나는 방식으로 오류가 발생할 수 있습니다.

PPA와 같은 타사 저장소는 일반적으로 릴리스 업그레이드 중에 비활성화됩니다. 더 이상 사용되지 않는 구성 옵션은 아무런 경고 없이 무시됩니다. 바로 3년 동안 아무도 손대지 않은 그 구식 내부 서비스에서 문제가 발생하기 마련입니다. 이에 대한 대응 조치는 절대 타협할 수 없습니다. 프로덕션 환경을 그대로 반영한 스테이징 환경에서 재구축하고, 전체 테스트 스위트를 실행한 뒤, 그곳에서 오류를 수정해야 합니다. 전환 작업이 한창인 새벽 2시에 해결해서는 안 됩니다.

전체 차량에 걸친 가동 중단 시간 조정

서버 한 대는 단순한 유지보수 작업에 불과하지만, 300대의 서버는 물류상의 문제입니다. 변경 작업 중단, 규정 준수 승인, 서비스 간 종속성 순서 조정, 그리고 모든 서버를 한꺼번에 재부팅할 수 없다는 사실 등이 복합적으로 작용하여 일정이 길어지게 됩니다.

다음 단계를 통과한 팀들 Ubuntu 16.04 지원 종료 혼란을 겪은 팀들은 이를 몸소 체험했습니다. 이를 완화하기 위한 방법은 단계적 배포입니다. 먼저 비생산 환경을 시작으로, 다음으로 저위험 생산 환경, 그다음 중요 시스템을 순차적으로 진행하며, 골든 이미지와 인프라-어-코드(Infrastructure-as-Code)를 활용해 각 단계가 재현 가능하도록 해야 합니다. 만약 2027년 5월 이전에 일정을 맞출 수 없다면, 바로 그때가 패치 지원 기간 연장의 진가를 발휘할 때입니다.

2분 만에 우분투 지원 상태를 확인하는 방법

각 박스가 어떤 상태인지 추측할 필요가 없습니다. 두 가지 명령어를 실행하면 버전 정보와 실시간 지원 상태를 확인할 수 있으며, 라이프사이클 날짜를 통해 남은 기간을 파악할 수 있습니다. 확실하지 않은 호스트가 있다면 이 명령어들을 순서대로 실행해 보세요.

먼저, 정확한 버전을 확인하십시오.

먼저 출시 일정과 코드명을 확인하세요.

lsb_release -a

다음 내용을 확인하세요 출시: 22.04 그리고 코드명: jammy를 확인하세요. 원본 소스 파일을 원하신다면, cat /etc/os-release 명령어를 실행하면 동일한 데이터와 전체 버전 문자열을 확인할 수 있습니다. 'jammy'로 표시되는 모든 버전은 22.04 버전을 기반으로 하며, 22.04.5와 같은 소수점 릴리스는 이 날짜를 변경하지 않습니다.

다음으로, 실시간 지원 상태를 확인하세요.

대부분의 사람들이 이 단계를 건너뛰곤 합니다. Ubuntu Pro 클라이언트는 시스템에 설치된 패키지에 현재 어떤 보안 지원이 적용되고 있는지 보여줍니다.

pro 보안 상태

출력 결과에는 지원 대상 패키지 수, 표준 또는 ESM 보안 업데이트 이용 가능 여부, 그리고 해당 보안 업데이트 채널에서 제외된 패키지가 무엇인지가 표시됩니다. 만약 “더 이상 보안 업데이트를 받지 않는” 패키지가 나열되어 있다면, 해당 패키지는 해당 업데이트 채널에서 제외된 것이며, 해당 패키지에 영향을 미치는 새로운 취약점이 공개될수록 잠재적인 보안 위험이 커집니다. TuxCare의 Ubuntu 지원 종료 개요 에서는 이러한 상태가 실제로 무엇을 의미하는지 단계별로 설명합니다.

마지막으로, 발견한 내용을 라이프사이클에 대입해 보세요.

위의 날짜 표와 대조하거나 endoflife.date와 대조한 후, 남은 기간을 계산해 보십시오. Pro 버전이 없는 22.04 버전의 경우, 표준 보안 유지보수는 2027년 5월에 종료됩니다. Pro 또는 ESM이 활성화된 경우, 지원 기간은 2032년 5월까지 연장되므로 시간을 벌 수는 있지만, 마이그레이션 작업을 로드맵에서 제외할 수는 없습니다.

날짜를 명확히 적어 두세요. “2027년 언젠가”는 마이그레이션 계획이 아닙니다. “2027년 1분기에 전환을 완료하고, 일정이 지연될 경우 ELS를 대체 방안으로 삼겠다”는 것이야말로 마이그레이션 계획입니다.

Ubuntu 버전이 EOL인 경우 어떻게 해야 할까요?

22.04 버전의 지원 종료(EOL)가 막다른 길은 아닙니다. 실제로 선택할 수 있는 세 가지 경로가 있으며, 어떤 경로가 적합한지는 이전할 수 있는지, 그리고 언제 이전할 수 있는지에 따라 달라집니다. 문서에 가장 깔끔하게 적혀 있는 옵션이 아니라, 실제 제약 조건을 고려하여 선택하십시오.

확장 지원 이용하기

만약 2027년 5월 이전에 마이그레이션이 정말로 불가능하다면, 그 이유가 규제 동결이든, 하드웨어 수명 종료든, 아니면 원활하게 이전할 수 없는 애플리케이션 스택 때문이든 간에, TuxCare의 ‘Endless Lifecycle Support’ 는 강제 업그레이드 없이도 시스템에 패치를 지속적으로 적용해 줍니다. 사용 중인 패키지에 대한 CVE 패치를 계속 받아보면서, 합리적인 속도로 마이그레이션을 계획할 수 있습니다.

중요한 점은 “절대 업그레이드하지 말아야 한다”는 것이 아닙니다. 서둘러서가 아니라 제대로 마이그레이션을 완료할 수 있도록 패치 적용 기간을 충분히 확보하는 것입니다. TuxCare ELS는 다음을 지원합니다. Ubuntu 16.04, Ubuntu 18.04, 그리고 Ubuntu 20.04 에 대해 다루며, 표준 지원이 종료되면 22.04에 대해서도 다룰 예정입니다.

확장 지원은 안전망일 뿐, 22.04 버전을 2030년대까지 계속 사용하려는 계획이 아닙니다. 이를 통해 원활한 마이그레이션 시기를 확보한 다음, 그 기회를 실제로 활용하십시오. TuxCare의 2026년 오픈소스 현황 보고서 에 따르면, 운영 환경에서 EOL(지원 종료) 구성 요소를 다루는 조직의 50.2%가 연장된 라이프사이클 지원이나 벤더 패치 적용을 선택하는 것으로 나타났으며, 이는 마이그레이션(43.9%)과 업그레이드(41.0%)보다 높은 수치입니다. 그렇다고 해서 그들이 마이그레이션을 포기한 것은 아닙니다. 연장 지원은 그들이 마이그레이션을 제대로 수행할 수 있도록 통제된 시간을 확보해 주는 것입니다.

지원되는 LTS 버전으로 업그레이드하세요

장기적으로 가장 좋은 방법은 최신 LTS 버전으로 업그레이드하는 것입니다. 2026년 기준으로, 그 버전은 Ubuntu 24.04 LTS이며, 표준 보안 유지보수는 2029년 5월까지 제공됩니다. 또는 2031년 5월까지 지원되는 26.04 LTS(Resolute Raccoon, 2026년 4월 23일 출시)도 선택할 수 있습니다.

22.04에서 업그레이드할 때는 먼저 24.04로, 그다음 26.04로 진행해야 한다는 점을 기억하십시오. 작업 범위를 파악하기 전에, 26.04에서는 GNOME Shell이 더 이상 X.org 세션으로 실행될 수 없게 되어 우분투 데스크톱 세션이 Wayland 전용으로 전환되며, 커널 버전도 6.8에서 7.0으로 변경된다는 점을 유의하십시오. X.org 애플리케이션은 여전히 XWayland를 통해 실행되며, 다른 데스크톱 세션에서는 X.org를 계속 사용할 수 있지만, 데스크톱 또는 커널 드라이버에 의존하는 모든 항목은 면밀히 검토해야 합니다. 이 경로를 선택하면 향후 수년간 표준 지원을 받을 수 있는 새로운 기반을 마련할 수 있습니다. 또한 초기 작업량이 가장 많으므로, 앞서 언급한 테스트 및 오류 시나리오에 대한 예산을 확보해야 합니다.

ESM을 사용하여 Canonical Ubuntu Pro 활성화하기

공급업체로부터 직접 확장된 지원 범위를 원하신다면, Ubuntu Pro는 22.04 버전부터 2032년 5월까지 ESM을 활성화하여 main 및 universe 저장소의 패키지에 대한 보안 지원을 제공합니다. 개인용으로는 최대 5대의 컴퓨터까지 무료로 이용할 수 있으며, 조직 차원의 배포를 위한 유료 요금제도 마련되어 있습니다.

이미 캐노니컬(Canonical)의 툴을 전면적으로 도입하고 있다면, Pro 버전이 가장 번거로움이 적은 선택지입니다. 하지만 대규모 시스템의 경우, 기기당 요금이 금세 불어나기 때문에, 최종 결정을 내리기 전에 TuxCare ELS와 같은 타사 옵션을 비교해 볼 가치가 있습니다.

TuxCare와 함께 우분투 22.04의 지원 종료(EOL) 이후에도 보안을 유지하세요

2027년 5월은 생각보다 금방 다가올 것이며, 그 시기가 오더라도 시스템은 아무런 경고도 하지 않을 것입니다. 그저 패치 제공이 중단될 뿐입니다. 24.04로 마이그레이션하든, 26.04로 재배포하든, 아니면 계획보다 더 오랫동안 22.04를 유지해야 하든 간에, 지금부터 전환일까지의 보안 공백에 대한 결정만큼은 미룰 수 없습니다.

만약 해당 전환이 예정된 일정에 맞춰 완료되지 못할 경우, TuxCare의 의 ‘Endless Lifecycle Support’를 통해 22.04 시스템을 새로운 CVE에 대비해 패치된 상태로 유지할 수 있으며, 서두르는 마이그레이션이나 계획되지 않은 가동 중단 없이도 가능합니다. EOL은 더 이상 긴급 대응 상황이 아닌, 로드맵상의 한 단계로 자리 잡게 됩니다.

자주 묻는 질문