VPS 라이브 커널 패치 원리와 재부팅 대체 가능 여부

VPS에서 라이브 커널 패치가 수행하는 역할

라이브 커널 패치는 재부팅이나 연결 끊김 없이 실행 중인 머신에 커널 보안 수정 사항을 적용합니다. 수정된 함수 복사본이 커널 모듈로 로드되며, 서버가 트래픽을 처리하는 동안 기존 함수에 대한 모든 호출은 새로운 복사본으로 리다이렉트됩니다. 이 메커니즘 하나로 라이브 패치의 장점과 한계를 모두 설명할 수 있습니다.

라이브 패치는 시간을 벌어줄 뿐, 재부팅을 완전히 대체하지는 않습니다. 6개월 동안 라이브 패치를 적용한 서버라도 디스크에는 여전히 구버전 커널 이미지가 부팅되어 있으며, 모든 패치는 메모리에만 존재합니다.

라이브 패치는 흔히 관리형 플랜의 기능으로 판매됩니다. 관리되지 않는 서버에서는 두 개의 명령어로 직접 활성화할 수 있으므로, 관리형 VPS와 비관리형 VPS의 차이에 비용을 지불하기 전에 이 점을 알아두는 것이 좋습니다.

라이브 커널 패치는 어떻게 작동합니까?

커널에는 CONFIG_LIVEPATCH 옵션으로 컴파일되는 라이브 패치 코어가 내장되어 있습니다. 현재 실행 중인 커널에 이 기능이 있는지 확인하십시오.

grep CONFIG_LIVEPATCH /boot/config-$(uname -r)

CONFIG_LIVEPATCH=y 항목이 출력된다면 현재 실행 중인 커널이 해당 코어를 포함하여 빌드된 것입니다. 이 기능이 없다면 해당 머신에서는 어떠한 라이브 패치 서비스도 작동할 수 없습니다.

리다이렉션 자체는 커널의 함수 추적기인 ftrace를 사용합니다. 대부분의 커널 함수는 인자나 스택이 처리되기 전, 함수 최상단에 호출 명령어가 포함된 상태로 컴파일됩니다. Ftrace는 이 호출 지점을 훅(hook)으로 사용합니다. 패치가 적용되면 라이브 패치 코어는 대상 함수에 ftrace 핸들러를 등록하며, 핸들러는 실행 흐름을 대체 함수로 전달합니다. 커널 문서에서는 이를 명확히 설명합니다: "라이브 패치는 일반적으로 함수 매개변수나 스택이 수정되기 전, 함수 진입부 최상단에서 코드를 리다이렉트해야 합니다."

이 문장으로부터 두 가지 결과가 도출되며, 둘 다 이후 과정에서 중요합니다. ftrace가 훅을 걸 수 있는 함수만 패치가 가능하므로, 진입부 호출 없이 컴파일된 함수는 전혀 패치할 수 없습니다. 또한 패치의 단위는 함수 전체이며, 함수 내부의 단일 라인만 패치하는 것은 불가능합니다.

더 어려운 부분은 라이브 시스템을 안전하게 전환하는 것입니다. 함수를 교체하는 시점에 일부 CPU 스택에서 이전 코드가 여전히 실행 중이라면, 이전 동작과 새로운 동작이 혼재될 수 있습니다. 업스트림 Linux는 이를 태스크별 일관성 모델(per-task consistency model)로 처리하며, 커널 문서에서는 이를 하이브리드 방식이라고 설명합니다: "kGraft의 태스크별 일관성과 시스템 콜 장벽 전환을 kpatch의 스택 추적 전환과 결합한 방식입니다." 태스크는 커널이 해당 태스크가 현재 패치된 함수 내부에 있지 않음을 확인할 수 있을 때만 새로운 코드로 하나씩 이동합니다. 모든 태스크가 이동을 완료할 때까지 패치는 전환 상태에 머무릅니다.

결과는 직접 확인할 수 있습니다. 적용된 패치는 /sys/kernel/livepatch 아래에 나타나며, 패치당 하나의 디렉터리가 생성되고 그 안에 패치된 함수들이 나열됩니다.

ls /sys/kernel/livepatch/

목록이 비어 있다면 메모리에 로드된 라이브 패치가 없다는 뜻이며, 이는 새로 설치된 서버의 일반적인 초기 상태입니다.

라이브 커널 패치로 해결할 수 없는 문제

함수 본문은 패치할 수 있지만, 그 외의 영역은 불가능합니다.

• 데이터 구조 변경. 업스트림 수정 사항이 구조체에 필드를 추가하거나 기존 필드의 의미를 변경하는 경우, 이미 할당되어 사용 중인 객체를 안전하게 재작성할 방법이 없습니다. kpatch 프로젝트는 이 상황을 다음과 같이 명시합니다. "정적으로 할당된 데이터를 수정하는 패치는 직접 지원하지 않습니다." 섀도우 변수(shadow variables)와 콜백을 우회 수단으로 사용할 수 있으나, 이는 자동이 아니며 패치마다 수동으로 작성해야 합니다.
• 여러 함수에 걸친 수정. 여러 함수에 걸쳐 잠금 순서(lock ordering)를 변경하는 수정은 모든 함수가 동시에 변경되어야 합니다. 하지만 일관성 모델은 전체 시스템을 한순간에 멈추는 대신 작업을 전환하는 방식을 취합니다.
• 초기화 코드. __init으로 표시된 함수는 서버가 가동될 때 이미 실행을 마치고 메모리에서 해제되었으므로, 리다이렉트할 대상이 남아 있지 않습니다.
• 새로운 커널 버전 및 새로운 기능. 라이브 패치는 동일한 커널 시리즈 내에서 패치 레벨을 올리는 작업입니다. 시리즈를 넘나들거나 새로운 기능을 추가할 수는 없습니다. Linux 7.1에 포함된 변경 사항과 같이 더 높은 버전의 기능이 필요하다면, 해당 커널을 설치하고 재부팅해야 합니다.
• 사용자 공간(Userspace). Canonical은 패치의 범위를 다음과 같이 명시합니다. "Canonical Livepatch는 OpenSSL이나 glibc와 같은 사용자 공간 라이브러리를 패치하지 않습니다. 이는 unattended-upgrades나 시스템 관리 도구의 역할입니다." 라이브 패치된 커널을 사용하더라도 OpenSSL이 구버전이라면 서버가 완전히 보호되는 것이 아닙니다. 따라서 동일한 서버에서 unattended upgrades를 통한 사용자 공간 패키지 관리를 병행해야 합니다.

Ubuntu 서비스에는 심각도에 따른 제한도 존재합니다. Canonical은 "CVSS(Common Vulnerability Scoring System) 등급이 높거나 치명적인 커널 취약점, 그리고 Ubuntu 우선순위 등급에 해당하는 취약점만 패치한다"고 밝히고 있습니다. CVE(Common Vulnerabilities and Exposures) 식별자는 결함을 지칭하며, CVSS는 해당 결함에 부여된 점수입니다. 중간 등급의 커널 CVE는 디스크상의 패키지에서 수정되며 라이브 패치 대상이 아니므로, 다음 재부팅 시점에 실행 중인 커널에 적용됩니다.

라이브 커널 패치 옵션에는 무엇이 있습니까?

널리 사용되는 세 가지 계열이 있으며, 모두 동일한 커널 메커니즘을 구동합니다.

Canonical Livepatch는 Ubuntu Pro를 통해 제공됩니다. Ubuntu Pro는 개인용으로 무료이며, Canonical의 정책에 따르면 "최대 5대의 물리적 머신까지는 개인용으로 언제나 무료"이며, 공식 Ubuntu 커뮤니티 회원의 경우 50대까지 확장됩니다. 이는 2026년 8월 기준으로 명시된 제한 사항입니다. 상업적 용도로는 유료 구독이 필요합니다. 지원 범위는 커널 시리즈 및 배포판별로 제공되며, 지원되는 장기 지원(LTS) 릴리스의 일반 가용성(GA) 커널과 해당 하드웨어 활성화(HWE) 커널을 포함합니다. 지원 대상은 generic, aws, azure, gcp, oracle, ibm, lowlatency와 같은 배포판 전반에 걸쳐 있습니다. 의존하기 전에 Canonical이 게시한 커널 목록에서 본인의 커널을 확인하십시오.

TuxCare에서 제공하는 KernelCare는 자체 서비스가 없는 배포판을 포함하여 많은 배포판을 지원하는 상업용 에이전트입니다. 문서화된 설치 방법은 공급업체 스크립트인 curl -s -L https://kernelcare.com/installer | bash를 실행한 후, 키 기반 라이선스를 위해 /usr/bin/kcarectl --register KEY를 사용하는 것입니다. 에이전트는 자체 일정에 따라 새 패치를 확인하며, /usr/bin/kcarectl --update 명령으로 강제 확인을 수행할 수 있습니다. 중요한 서버의 셸에 파이프로 연결하기 전에 설치 스크립트 내용을 먼저 읽어보십시오.

kpatch와 kGraft는 초기 기술입니다. kGraft는 SUSE에서, kpatch는 Red Hat에서 시작되었으며, 오늘날 업스트림 Linux의 라이브 패치 핵심은 두 아이디어를 통합한 것입니다. kpatch 자체는 축소되는 추세입니다. README에 따르면 Linux 6.19부터 "kpatch 프로젝트는 더 이상 사용되지 않으며 유지보수 모드"로 전환되었고, kpatch-build은 업스트림 커널에서 klp-build로 대체되었습니다. RHEL 및 그 파생 배포판에서는 직접 패치를 빌드하는 대신 배포판에서 제공하는 자체 서비스를 사용하는 것이 좋습니다.

사용 중인 배포판의 지원 여부와 라이선스 허용 범위를 고려하여 선택하십시오. 어떤 경우든 커널 수준의 결과는 동일합니다.

Ubuntu에서 Canonical Livepatch 활성화하는 방법

먼저 Ubuntu Pro 계정 페이지에서 토큰을 발급받아야 합니다. 아래 두 명령어 모두 외부 네트워크 연결이 필요합니다. 클라이언트가 Canonical 서버와 통신하여 계정을 연결하고 패치를 가져오기 때문입니다.

sudo pro attach TOKEN
sudo pro status

토큰 없이 sudo pro attach를 실행하면 브라우저 기반 인증 절차가 시작되며, Canonical 사이트에 입력할 코드가 출력됩니다. 연결이 완료되면 권장 서비스가 자동으로 활성화되는데, 현재 LTS 릴리스에서는 Livepatch가 포함됩니다. 서비스를 직접 선택하려면 sudo pro attach --no-auto-enable을 사용하십시오.

Livepatch가 활성화되어 있지 않다면 다음을 실행합니다:

sudo pro enable livepatch
sudo canonical-livepatch status

이 서비스는 canonical-livepatch 스냅으로 실행되므로, 활성화 단계를 완료하려면 snapd가 정상적으로 작동해야 합니다. pro status는 서비스의 권한과 상태를 표 형태로 출력합니다. canonical-livepatch status은 커널별 상세 정보를 출력하며, Canonical 문서에 따르면 출력 결과는 다음과 같습니다:

last check: 52 seconds ago
kernel: 5.4.0-216.236-generic
server check-in: succeeded
kernel state: ✓ kernel series 5.4 is covered by Livepatch
patch state: ✓ all applicable livepatch kernel modules applied
patch version: 113.1

두 줄의 정보가 핵심입니다. kernel state는 현재 실행 중인 커널 시리즈가 서비스 지원 대상인지 나타내며, Livepatch가 지원하지 않는 커널로 부팅할 경우 이 항목의 상태가 나빠집니다. patch state는 해당 커널에 적용 가능한 패치가 실제로 로드되었는지 나타냅니다. 지원 대상 커널임에도 패치가 적용되지 않았다면 클라이언트 측의 문제입니다. 지원되지 않는 커널이라면 커널 자체의 문제이며, 클라이언트 설정으로는 해결할 수 없습니다.

재부팅이 필요한지 어떻게 확인합니까?

라이브 패치(Live patching)를 적용하면 긴급한 상황이 해소되므로 재부팅이 필요한지 즉각적으로 알기 어렵습니다. 따라서 직접 확인해야 합니다.

ls -l /var/run/reboot-required
cat /var/run/reboot-required.pkgs

패키지 관리자는 설치된 패키지에 재시작이 필요할 때 /var/run/reboot-required을 생성하며, 새로운 linux-image 패키지는 항상 이 파일을 생성합니다. .pkgs 파일에는 재부팅을 요청한 패키지 목록이 기록됩니다. 첫 번째 명령의 결과가 No such file or directory라면, 마지막 부팅 이후 재부팅을 요청한 패키지가 없다는 뜻입니다. 현재 Ubuntu에서 /var/run은 /run에 대한 심볼릭 링크이므로, 어느 경로를 사용하든 동일한 파일에 접근합니다.

해당 플래그는 tmpfs에 위치하여 부팅 시마다 초기화되므로, 커널 자체를 기준으로 다시 확인해야 합니다.

uname -r
dpkg -l 'linux-image-*' | grep ^ii

uname -r는 현재 실행 중인 커널 버전을 출력합니다. 두 번째 명령은 디스크에 설치된 커널 패키지 목록을 출력합니다. 목록에 있는 linux-image 버전이 uname -r가 보고하는 버전보다 최신이라면, Livepatch 상태와 관계없이 시스템은 구형 커널로 동작 중입니다. 라이브 패치는 실행 중인 커널을 안전하게 유지할 뿐 최신 버전으로 만들어주는 것은 아니므로, 이 확인 과정이 중요합니다.

사용자 공간(userspace) 측면에서 동일한 문제를 확인하려면, Ubuntu Server에 기본 설치된 needrestart를 사용하여 삭제된 라이브러리 파일을 여전히 참조하고 있는 실행 중인 서비스 목록을 확인하십시오.

sudo needrestart -r l

-r l 플래그 조합은 "목록만 표시(list only)"를 의미하므로, 아무것도 변경하지 않고 상태만 보고합니다.

재부팅이 사라지지 않는 이유

디스크에 저장된 커널은 변경되지 않습니다. 라이브 패치는 실행 중인 커널에 로드될 뿐 부팅 이미지에 기록되지 않으므로, 재부팅을 수행하면 부팅 로더가 선택한 linux-image로 시스템이 올라오며, 이후 Livepatch 클라이언트가 적용 가능한 패치를 다시 적용합니다. 이 두 시점 사이에는 패치되지 않은 코드가 실행되므로, 구형 커널보다는 최신 커널로 부팅해야 하는 또 다른 이유가 됩니다.

커널 커버리지는 커널 시리즈별로 제공되며, 특정 시리즈는 지원이 종료됩니다. 실행 중인 시리즈가 지원 목록에서 제외되면 kernel state 라인은 더 이상 커버리지 정보를 보고하지 않으며, 유일한 해결책은 더 최신 커널로 교체하는 것입니다. 이때 재부팅이 필요합니다. LTS 릴리스의 경우, 더 최신 시리즈는 보통 26.04.1과 같은 포인트 릴리스에 포함된 하드웨어 지원 커널(HWE) 형태로 제공되므로, 교체용 커널은 이미 아카이브에 준비되어 있으며 사용자가 일정을 잡아 재부팅만 하면 됩니다.

중간 및 낮은 심각도의 커널 수정 사항은 라이브 패치로 제공되지 않습니다. 이러한 수정 사항은 디스크의 패키지 내에 머물러 있다가 재부팅을 수행해야만 적용됩니다.

장기간 실행되는 커널은 패치로 해결되지 않는 상태 정보도 축적합니다. Canonical의 공식 입장은 솔직하므로 인용할 가치가 있습니다. Livepatch는 "재부팅을 대체하는 도구가 아닙니다. 이는 계획되지 않은 재부팅을 방지하여 더 많은 제어권을 제공하는 도구입니다." 여기서 핵심적인 의미를 담고 있는 단어는 계획되지 않은입니다. 사용자는 여전히 재부팅을 해야 합니다. 다만 그 시점을 직접 선택할 뿐입니다.

재부팅 후 정상적으로 복구되도록 예약하는 방법

콘솔에 접근할 수 없는 상태에서 VPS를 재부팅하면 일방통행이 될 수 있습니다. reboot를 입력하기 전에, 시스템이 돌아오지 않을 경우를 대비해 다시 접속할 수 있는지 확인하십시오.

• 서비스 제공업체가 제어판에서 시리얼 콘솔이나 VNC(virtual network computing) 화면을 제공하는지 확인하고, 장애 발생 시가 아니라 지금 미리 열어두십시오.
• df -h /boot을 사용하여 여유 공간을 확인하십시오. /boot이 가득 차면 initramfs(initial RAM filesystem)를 기록하는 동안 커널 패키지 설치가 실패하며, 이로 인해 완료되지 않은 이미지로 부팅을 시도하는 부트로더 항목이 남을 수 있습니다.
• 정상 작동이 확인된 이전 커널을 최소 하나 이상 유지하십시오. GRUB은 이를 "Advanced options for Ubuntu" 항목 아래에 나열하며, 새 커널이 실패했을 때 가장 빠르게 복구하는 방법은 이전 커널로 부팅하는 것입니다.
• 필요하기 전에 서비스 제공업체의 구조 모드(rescue mode) 진입 방법을 찾아두십시오. 재부팅 후 콘솔에 initramfs 프롬프트가 나타난다면, 그곳에서 복구 작업을 수행해야 합니다.

그런 다음 깨어 있는 시간에 재부팅을 예약하십시오:

sudo shutdown -r +5 "Kernel update, back in a moment"

이 명령은 5분 뒤에 재부팅을 예약하고 로그인한 사용자들에게 메시지를 보냅니다. sudo shutdown -c를 입력하면 예약을 취소할 수 있습니다. 시스템이 돌아오면 다음 두 가지를 확인하십시오:

uname -r
sudo canonical-livepatch status

uname -r은 이제 더 최신 커널을 보고해야 하며, 상태 출력은 새로운 시리즈가 적용되었음을 나타내야 합니다. 만약 시스템이 전혀 돌아오지 않는다면, 문제는 네트워크가 아니라 부팅 경로에 있을 가능성이 거의 확실합니다. 이 경우 복구 방법은 커널 업데이트 후 부팅되지 않는 VPS 복구 가이드를 참조하십시오.

오래된 커널을 정리해야 하는 이유

라이브 패칭은 재부팅의 필요성을 줄여주지만, 오히려 이 문제를 악화시킵니다. 재부팅을 하지 않아도 linux-image 패키지는 계속 설치되기 때문입니다. 각 커널은 부트 이미지, initramfs, 모듈 트리, 그리고 일반적으로 헤더 패키지를 설치합니다. 수백 메가바이트 크기의 별도 /boot 파티션을 사용하는 소규모 VPS에서는 커널 3~4개만 설치되어도 파티션이 가득 찹니다.

/boot이 가득 차면 다음 커널 설치가 실패하며, 결과적으로 시스템은 필요한 업데이트를 적용할 수 없는 상태가 됩니다. apt autoremove 경로는 정리 대상이 된 오래된 커널을 삭제하지만, 재부팅을 하지 않는 서버에서는 커널이 항상 정리 대상이 되지는 않습니다. 패키지 관리자는 현재 실행 중일 가능성이 있는 커널을 삭제하지 않기 때문입니다.

따라서 설치된 커널을 확인하고, 현재 실행 중인 커널과 정상 작동이 확인된 예비 커널 하나를 제외한 나머지는 Ubuntu에서 오래된 커널을 안전하게 제거하는 절차를 따라 삭제하십시오. uname -r이 현재 보고하는 커널은 절대 삭제해서는 안 됩니다.

FAQ

라이브 커널 패치를 사용하면 VPS를 재부팅할 필요가 없습니까?

아닙니다. 라이브 패치는 실행 중인 커널에 로드될 뿐 부팅 이미지에 기록되지 않으므로, 디스크의 linux-image은 부팅 시점의 버전으로 유지됩니다. Canonical은 이를 명확히 밝히고 있습니다. Livepatch는 "재부팅을 대체하는 것이 아니라, 계획되지 않은 재부팅을 방지하여 제어권을 높여주는 도구"입니다. 또한 커널 시리즈의 지원이 종료되면 패치 적용도 중단되며, 중간 수준의 커널 보안 취약점은 라이브 패치 대상에서 제외됩니다. 강제 재부팅을 기다리기보다 정기적인 유지보수 계획을 세워 재부팅을 수행하십시오.

라이브 커널 패치가 실제로 적용되고 있는지 어떻게 확인합니까?

sudo canonical-livepatch status를 실행하여 두 줄의 결과를 확인하십시오. kernel state은 현재 실행 중인 커널 시리즈가 서비스 지원 대상인지 보고하며, patch state은 해당 커널에 대한 패치가 로드되었는지 보고합니다. 또한 ls /sys/kernel/livepatch/를 통해 커널 측면에서 직접 확인할 수도 있습니다. 이 명령은 로드된 패치당 하나의 디렉터리를 나열합니다. 목록이 비어 있다면 클라이언트의 상태 메시지와 관계없이 현재 메모리에 적용된 패치가 없다는 의미입니다.

개인용 VPS에서 Ubuntu Pro는 무료입니까?

네, 명시된 제한 범위 내에서 무료입니다. 2026년 8월 기준으로 Canonical은 Ubuntu Pro가 "최대 5대의 물리적 머신까지 개인용으로 항상 무료이며, 공식 Ubuntu 커뮤니티 멤버는 50대까지 무료"라고 명시하고 있습니다. 상업적 용도로는 유료 구독이 필요합니다. Ubuntu Pro 계정 페이지에서 토큰을 발급받아 sudo pro attach TOKEN으로 머신을 연결한 뒤, sudo pro enable livepatch를 사용하여 서비스를 활성화하십시오.

Livepatch를 실행했는데도 커널 CVE가 여전히 미해결 상태로 표시되는 이유는 무엇입니까?

보통 두 가지 이유 중 하나입니다. 첫째, 해당 수정 사항이 중요도 기준 미달일 수 있습니다. Canonical은 "CVSS(Common Vulnerability Scoring System) 점수가 높거나 Ubuntu 우선순위가 높은 커널 취약점"만 라이브 패치하며, 나머지는 디스크의 패키지 업데이트에 맡깁니다. 둘째, 업스트림에서 데이터 구조를 변경한 경우처럼 함수 본문 수정만으로는 해결할 수 없는 경우입니다. 이미 할당된 객체에 대해 라이브 패치를 안전하게 수행할 수 없기 때문입니다. 두 경우 모두 해결 방법은 동일합니다. 업데이트된 커널 패키지를 설치하고 해당 커널로 부팅하십시오.

라이브 커널 패치가 전혀 다루지 않는 영역은 무엇입니까?

사용자 공간(Userspace)입니다. Canonical은 Livepatch가 "OpenSSL이나 glibc와 같은 사용자 공간 라이브러리는 패치하지 않으며, 이는 unattended-upgrades나 시스템 관리 도구의 책임"이라고 명시하고 있습니다. 또한 이미 실행 중인 커널 시리즈 내의 함수 본문만 교체하므로 새로운 커널 버전이나 새로운 기능을 제공할 수 없습니다. 서버가 가동된 시점에 이미 실행을 마치고 메모리에서 해제된 __init 함수도 패치할 수 없습니다.