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 프로젝트는 이 상황을 다음과 같이 명시합니다. "정적으로 할당된 데이터를 수정하는 패치는 직접 지원하지 않습니다." 섀도우 변수와 콜백을 우회 수단으로 사용할 수 있으나, 이는 자동이 아니며 패치마다 수동으로 작성해야 합니다.
• 여러 함수에 걸친 수정. 여러 함수에 걸쳐 잠금 순서를 변경하는 수정 사항은 모든 함수가 동시에 변경되어야 합니다. 하지만 일관성 모델은 전체 시스템을 한순간에 멈추는 대신 작업을 전환하는 방식을 사용합니다.
• 초기화 코드. __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는 현재 실행 중인 커널 버전을 출력합니다. 두 번째 명령은 디스크에 설치된 커널 패키지를 출력합니다. 해당 목록에 uname -r가 보고하는 버전보다 최신인 linux-image이 있다면, 라이브 패치 상태와 관계없이 시스템은 구버전 커널로 동작 중인 것입니다. 라이브 패치는 실행 중인 커널을 안전하게 유지하는 것이 목적이지 최신 상태로 만드는 것이 아니므로, 이 확인 과정이 중요합니다.

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

sudo needrestart -r l

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

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

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

커널 커버리지는 커널 시리즈별로 제공되며, 특정 시리즈는 지원이 종료됩니다. 실행 중인 시리즈가 지원 목록에서 제외되면 kernel state 라인은 더 이상 커버리지 정보를 보고하지 않으며, 유일한 해결책은 더 새로운 커널로 업데이트하는 것입니다. 이때는 재부팅이 필요합니다.

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

장기간 실행되는 커널은 패치로 해결되지 않는 상태 정보가 누적되기도 합니다. 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 복구 가이드를 참조하여 복구하십시오.

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

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

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

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

FAQ

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

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

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

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

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

네, 명시된 제한 범위 내에서는 무료입니다. Canonical은 2026년 8월 기준으로 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 함수는 패치할 수 없습니다.