지원 종료(EOL)된 PHP용 php2shell 패치(CVE-2026-109618 및 CVE-2026-109619)가 출시되었습니다. 수요가 많아 평소보다 영업팀의 답변이 늦어지고 있으므로, 패치된 패키지를 가장 빠르게 확보하려면 온라인에서 Runtimes용 ELS를 구매하시기 바랍니다 (새 탭에서 열림). | 패치 FAQ 읽어보기
라이브 패치 기능은 재부팅을 없애고 보안 취약점을 보완해 줄 것으로 기대됩니다.
하지만 kpatch는 CVE의 10%만 다루며, 어차피 재부팅하기 약
1년 전에 유효기간이 만료됩니다.
현재 대부분의 엔터프라이즈 리눅스 공급업체들은 라이브 패치 도구를 제공하고 있으며, 레드햇의 경우 2014년에 RHEL에 내장된 ‘kpatch’를 사용하고 있습니다. 하지만 이 도구의 업스트림 오픈소스 프로젝트는 현재 더 이상 지원되지 않습니다. kpatch는 실행 중인 서버에 커널 수정 사항을 적용하므로, 보안 업데이트를 위해 더 이상 유지보수 시간을 기다릴 필요가 없습니다.
문제는 적용 범위가 너무 좁다는 점입니다. kpatch는 시스템에 영향을 미치는 CVE 중 약 10% 정도만 패치하며, 사용자 공간은 완전히 제외합니다. 또한 커널당 약 1년 후에 적용 기간이 만료되어, 라이브 패칭이 본래 없애고자 했던 재부팅을 어쩔 수 없이 강요하게 됩니다. 게다가 이처럼 제한적인 보호 기능조차 여전히 비용이 많이 드는 RHEL 구독에 의존하고 있습니다.
TuxCare의 KernelCare는 이러한 사각지대를 해소하기 위해 개발되었습니다. 이 솔루션은 심각도에 관계없이 모든 커널 CVE에 대한 패치를 제공하며, LibCare를 통해 OpenSSL 및 glibc까지 지원 범위를 확장하고, 강제 재부팅 없이 지속적인 보안을 보장합니다. 이 모든 서비스를 시스템당 연간 단 50달러에 이용할 수 있습니다. 아래 비교표에서는 두 솔루션의 차이점을 상세히 정리했습니다.
Red Hat k패치 |
KernelCare |
|
|---|---|---|
| 지원되는 배포판 | Red Hat Enterprise Linux 전용 | Red Hat Enterprise Linux 6, 7, 8, 9, 그리고 Ubuntu, Oracle, AlmaLinux 등 다양한 운영 체제 |
| 패치된 취약점 | ❌ CVE 중 약 10%만 (선별된 ‘중요’ 및 ‘심각’ 등급의 커널 CVE) | ✅ 최대 100% 보장 |
| 리눅스 커널 및 핵심 사용자 공간(OpenSSL, glibc)에 대한 지원 | ❌ 커널 전용 | ✅ 네 |
| ARM64 아키텍처 지원 | ❌ x86-64 전용 | ✅ 네 |
| 실행 중인 모든 커널에 대한 라이브 패치 | ❌ 해당되는 커널만 선택하세요 | ✅ 네 |
| 사실상 무제한의 커널 패치 수명 | ❌ 커널당 약 1년 | ✅ 네 |
에 내장된 자동 패치 기능 |
❌ 전용 에이전트가 없으며, 패치는 RPM 형태로 제공되며 yum/dnf 또는 Satellite를 통해 적용됩니다. | ✅ 에이전트가 새로운 패치를 자동으로 확인하고 적용합니다 |
에 대한 라이브 패치 지원 종료된 OS |
❌ 유료 ‘확장 수명 주기 지원(Extended Life-cycle Support)’ 애드온에는 포함되지 않습니다. |
✅ Red Hat Enterprise Linux 6, 7, 그리고 Ubuntu, Oracle, AlmaLinux 등 다양한 운영체제 |
| 재부팅 없는 롤백 기능 | ❌ 재부팅 후 | ✅ 재부팅 불필요 |
| 맞춤형 패치 배송 | ❌ kpatch-build를 이용한 직접 구축; 서비스 형태로 제공되거나 지원되지 않음 | ✅ 완전 관리형 |
| 중앙 집중식 및 에어갭 방식의 관리 | ❌ Red Hat Satellite 필요 (별도 라이선스) | ✅ 포함 (ePortal) |
| API 사용 가능 | ❌ 중앙 집중식 API를 사용하려면 Red Hat Satellite(별도 라이선스)가 필요합니다. | ✅ 포함 (ePortal) |
| 모든 패치를 위한 단일 패치세트 배포 | ✅ 네 | ✅ 네 |
| 상류 부문에서 적극적으로 개발 중 | ❌ 사용 중단됨, 유지보수 모드 중 | ✅ 네 |
| 연중무휴 24시간 지원 | ❌ 심각도 1 및 2에 한함, 프리미엄 구독자 | ✅ 온라인, 연중무휴 24시간 |
| 애드온 | - | LibCare, 맞춤형 패치 |
| 패치 유형 | 영구 | 영구 |
| 비용 | 유효한 RHEL 구독이 필요합니다: 시스템당 연간 $878.90(스탠다드) 또는 $1,428.90(프리미엄); EUS 추가 옵션 +$273.90 | 시스템당 연간 50달러부터, 대량 구매 시 할인 혜택 제공 |
이 차트는 두 가지가 어떻게 다른지를 보여줍니다. 이 비교의 나머지 부분에서는 이러한 차이점들이 여러분이 실제로 운영하는 시스템에 어떤 의미를 지니는지 자세히 살펴보겠습니다.
라이브 패칭은 실제로 실행 중인 시스템을 모두 포함해야 하며, 배포판의 조합이 어떻게 되든 상관없습니다. kpatch는 Red Hat 개발자들이 개발하고 유지 관리하므로, 실질적으로 RHEL용 도구이며, RHEL 내에서도 RHEL 6과 일부 RHEL 7 버전은 지원 대상에서 제외됩니다. 특정 Ubuntu, Debian, Gentoo 버전과 같은 소수의 비-RHEL 배포판은 기술적으로 지원되지만, 이는 사용자가 직접 라이브 패치를 작성하는 경우에만 해당되며, 이를 위해서는 깊은 커널 전문 지식이 필요하고, 실수할 경우 실질적인 위험을 수반합니다.
KernelCare는 이와 정반대의 입장을 취합니다. 이 제품은 RHEL, Ubuntu, Debian, Oracle Linux, AlmaLinux, Rocky Linux, Amazon Linux 등을 설치 즉시 라이브 패치할 수 있습니다. 단일 배포판만 사용하는 환경에서는 현재로서는 결정적인 요소로 보이지 않을 수 있지만, 향후 환경이 RHEL을 넘어 확장될 경우 단일 도구와 단일 워크플로우로 관리할 수 있게 된다는 의미입니다.
라이브 패치링의 핵심 목적은 취약점을 신속하게 수정하는 것이므로, 가장 먼저 제기되는 질문은 해당 도구가 실제로 어떤 취약점을 수정하느냐는 것입니다. 저희 자체 연구에 따르면, kpatch는 시스템에 영향을 미치는 CVE 중 약 10% 정도만 라이브 패치하며, 이러한 차이의 일부는 설계상 의도된 것입니다.
kpatch는 레드햇이 직접 ‘중요(Important)’ 또는 ‘치명적(Critical)’으로 평가한 커널 CVE에 대해서만 실시간 패치를 적용하며, 그 기준은 겉보이는 것보다 훨씬 엄격합니다. 레드햇은 자체적인 심각도 등급을 부여하는데, 이는 국가 취약점 데이터베이스(National Vulnerability Database)에서 CVE에 부여된 점수와 다를 수 있으므로, 다른 곳에서 ‘치명적’으로 평가된 결함이라도 등급이 하향 조정되어 패치 대상에서 제외될 수 있습니다. 또한 이러한 등급은 일반적인 구성을 전제로 하기 때문에, 레드햇이 낮은 등급을 부여한 CVE라도 사용자의 특정 환경에서는 여전히 심각한 보안 위협이 될 수 있음에도 불구하고, 라이브 패치를 받지 못하고 다음 커널 릴리스와 재부팅을 기다려야 합니다. 게다가 레드햇이 ‘중요(Important)’ 또는 ‘치명적(Critical)’ 등급으로 분류한 CVE 중에서도, 레드햇의 공식 문서에 따르면 모든 CVE에 대해 라이브 패치가 보장되는 것은 아닙니다.
KernelCare는 심각도 등급에 관계없이 모든 커널 CVE에 대해 라이브 패치를 적용함으로써 불확실성을 해소하므로, 적용 범위는 특정 CVE의 평가 점수에 좌우되지 않습니다.
라이브 패치(Live patching)는 재시작 없이 전체 시스템의 보안을 유지해야 하지만, kpatch는 오직 커널에만 적용됩니다. Heartbleed, GHOST, Looney Tunables와 같은 사고의 원인이 된 OpenSSL 및 glibc 결함을 비롯한 모든 사용자 공간 라이브러리 취약점은 여전히 패키지 업데이트와 서비스 또는 애플리케이션 재시작을 기다려야 합니다. 이러한 라이브러리는 사용자가 실행하는 거의 모든 것의 기반이 되기 때문에, glibc나 OpenSSL의 단 한 가지 수정만으로도 스택의 상당 부분을 재시작해야 할 수 있습니다.
KernelCare는 LibCare를 통해 이러한 격차를 해소하며, OpenSSL 및 glibc와 같은 공유 라이브러리에 대한 패치를 해당 라이브러리에 의존하는 애플리케이션을 재시작하지 않고 메모리 내에서 직접 적용합니다. 가동 중단 없이 중요한 사용자 공간에 패치를 적용할 수 있기 때문에, 팀은 시스템을 오프라인으로 전환할 수 없는 환경에서도 PCI DSS, SOC 2 및 FedRAMP의 시정 조치 기한을 준수할 수 있습니다.
라이브 패치 기능은 특정 프로세서에 탑재된 서버뿐만 아니라 인프라 내의 모든 서버를 보호해야 합니다. kpatch는 x86-64 및 ppc64le 아키텍처에 대해 라이브 패치를 지원하지만, Arm64 시스템에 대해서는 라이브 패치 기능을 전혀 제공하지 않습니다. Arm이 데이터 센터와 클라우드 분야에서 점차 입지를 넓혀감에 따라, 이는 점점 더 심각한 사각지대가 되고 있습니다.
KernelCare는 x86-64와 Arm64를 모두 지원하므로, 워크로드가 기존 x86 하드웨어에서 실행되든 Arm에서 실행되든 동일한 재부팅 없이도 보호 기능을 제공합니다.
라이브 패칭은 사용자가 실제로 실행 중인 커널을 대상으로 해야 하지만, kpatch는 그중 일부에만 패치를 적용합니다. kpatch는 레드햇이 분기마다 한 번씩 지정하는, kpatch 적용 대상인 기본 에라타 커널에 대해서만 라이브 패치를 수행하므로, 시스템이 해당 지정 커널 중 하나를 실행하고 있지 않은 한, 해당 커널로 전환하기 전까지는 라이브 패치를 받을 수 없습니다.
KernelCare는 자격 요건에 대한 제한을 전혀 두지 않습니다. 어떤 커널이 로드되든 이를 패치하므로, 사용자가 미리 정해진 목록을 따르도록 요구하지 않고 시스템 자체에 맞춰 지원이 이루어집니다.
적격 커널을 사용 중이라 하더라도 지원 기간에는 제한이 있습니다. 각 적격 커널은 약 1년 동안 실시간 패치를 제공받으며, 그 이후에는 수정 사항을 계속 받아보려면 커널을 업그레이드하고 시스템을 재부팅해야 합니다. 바로 이 한계가 본래의 취지를 은연중에 무력화시키는 요인입니다. kpatch는 재부팅을 없애는 대신 이를 미루기만 할 뿐이며, 결국 사용자는 어쩔 수 없이 공급업체의 일정에 맞춰 유지보수 시간을 계획해야만 합니다.
KernelCare는 이러한 시간 제한을 두지 않으며, 각 커널에 대해 사실상 무제한의 수명 동안 패치를 적용하므로, 사용자는 매년 강제 재부팅 없이도 기존 커널에서 계속 보호를 받을 수 있습니다.
라이브 패치 작업은 백그라운드에서 조용히 실행되어야 하며, 관리해야 할 또 다른 업무가 되어서는 안 됩니다. kpatch에는 전용 패치 자동화 에이전트가 없습니다. 패치는 RPM 형태로 제공되며, 사용자는 yum이나 dnf를 통해 적용하거나 Satellite를 통해 배포할 수 있습니다. 즉, 최신 상태를 유지하는 작업은 수동으로 수행해야 하는 관리 업무이거나, 범용 업데이트 도구를 조합하여 해결해야 하는 문제입니다.
KernelCare는 새로운 패치를 자동으로 확인하고 적용하는 경량 에이전트를 설치하며, 귀사가 이미 사용 중인 IT 자동화 시스템과 연동됩니다. 일단 배포가 완료되면, 시스템 패치 관리는 더 이상 반복되는 번거로운 작업이 아닙니다.
레드햇은 확장 지원 기간 동안 kpatch 라이브 패치를 제공하지 않으며, 유료 확장 지원 애드온을 이용하더라도 마찬가지입니다. 릴리스의 지원 기간이 종료되면, 보안 에라타 비용을 계속 지불하더라도 라이브 패치 기능은 더 이상 이용할 수 없습니다.
KernelCare는 이와 정반대의 방식을 취합니다. CentOS 7, Ubuntu 18.04, Debian 10, RHEL 7 등 지원이 종료된 배포판 버전에 대해서도 지속적으로 라이브 패치를 제공하므로, 예정대로 폐기할 수 없는 시스템도 사용자가 자신의 일정에 맞춰 이전 계획을 세우는 동안 계속해서 보호받을 수 있습니다.
라이브 패치 적용은 되돌릴 수 있어야 합니다. 때로는 수정 사항이 다시 제거되어야 할 필요가 있기 때문인데, 예를 들어 (일부 스펙터 및 멜트다운 수정 사항에서 그랬던 것처럼) 특정 완화 조치가 성능 저하를 초래하고, 대안적인 완화 조치가 마련된 경우 등이 해당됩니다.
kpatch로는 이 작업을 수행할 수 없습니다. 라이브 패치를 되돌리려면 재부팅이 필요하기 때문에, 문제가 있는 패치로 인해 계획된 서비스 중단이 발생하게 되고, 라이브 패치 적용의 가장 큰 장점이 사라지게 됩니다. 반면 KernelCare를 사용하면 재부팅 없이 단 한 번의 명령어로 적용된 패치를 롤백할 수 있으므로, 패치를 되돌리는 데 미치는 영향은 패치를 적용할 때와 마찬가지로 미미합니다.
일부 환경에서는 공급업체가 아직 배포하지 않은 수정 사항이나 자체 코드에 맞춰 제작된 패치가 필요한 경우가 있습니다. kpatch를 사용하면 이를 직접 해결해야 합니다. 즉, kpatch-build를 사용하여 패치를 직접 빌드해야 하며, 관리형 배포나 기술 지원은 제공되지 않습니다. 대부분의 팀에게 있어 필요한 커널 전문 지식 자체가 이미 큰 장벽이 됩니다.
KernelCare는 TuxCare가 고객을 대신해 빌드, 테스트 및 유지보수를 담당하는 완전 관리형 맞춤형 패치를 제공합니다. 이를 통해 고객은 사내에서 라이브 패치를 직접 제작하는 데 따르는 업무 부담과 위험을 감수하지 않고도 필요한 수정 사항을 적용할 수 있습니다.
실제 규모에서는 라이브 패치 적용을 중앙에서 관리해야 하며, 인터넷에 접속할 수 없는 환경에서 이를 수행해야 하는 경우도 점점 늘어나고 있습니다. kpatch를 사용할 경우, 중앙 집중식 배포를 위해서는 별도의 라이선스가 필요한 Red Hat Satellite를 구축해야 하는데, 이는 추가 비용이 발생할 뿐만 아니라 운영해야 할 시스템이 하나 더 늘어나는 것을 의미합니다.
KernelCare에는 단계적 배포, 통제된 배포 및 완전한 에어갭 네트워크를 위한 온프레미스 전용 패치 서버인 ePortal이 추가 라이선스 비용 없이 포함되어 있습니다. Red Hat 측에서는 추가 비용이 발생하는 이 기능이 TuxCare 측에서는 패키지의 일부로 제공됩니다.
현대적인 패치 적용은 스크립트로 자동화할 수 있어야 하며, 시스템의 다른 자동화 기능과 연동되어야 합니다. kpatch는 기본 API를 제공하지 않으므로, API를 통해 수행되는 모든 작업은 다시 Red Hat Satellite를 경유하게 됩니다.
KernelCare에는 등록, 관리 및 Ansible 자동화를 위한 ePortal API가 포함되어 있으므로, 별도의 관리 제품 없이도 라이브 패치 기능을 기존 파이프라인에 원활하게 통합할 수 있습니다.
패치 도구를 선택하는 것은 장기적인 결정이므로, 프로젝트의 건전성이 중요합니다. 업스트림 오픈소스 프로젝트인 kpatch는 현재 유지보수 단계에 있으며, 패치 빌드 작업은 메인라인 커널의 klp-build로 이전되었습니다. 반면 KernelCare는 다양한 배포판과 아키텍처에 걸쳐 활발히 개발되고 상용 지원이 제공되고 있는데, 이는 수년 동안 운영될 것으로 예상되는 인프라의 기반으로서 바람직한 발전 방향입니다.
패치 관련 문의가 시급해질 경우, 대응 속도가 매우 중요합니다. kpatch의 연중무휴 지원 서비스는 심각도 1 및 2의 사례로만 제한되며, 프리미엄 구독자만 이용할 수 있으므로, 심각도가 낮은 문제는 업무 시간까지 기다려야 합니다. KernelCare는 모든 구독 등급에 대해 연중무휴 24시간 온라인 지원 서비스를 제공합니다.
KernelCare Enterprise는 커널 라이브 패치 기능을 제공하며, 시스템당 연간 50달러부터 시작하고, Red Hat 구독 없이도 기존 RHEL 시스템에서 실행됩니다. OpenSSL 및 glibc에 대한 사용자 공간 라이브 패칭은 LibCare 애드온을 통해 이용할 수 있습니다. 반면, kpatch는 별도의 요금이 부과되지 않지만 유효한 RHEL 구독이 필요하며, 구독 요금은 시스템당 연간 Standard의 경우 $878.90, Premium의 경우 $1,428.90이며, 라이브 패치 창을 열어두기 위한 EUS 애드온 비용은 $273.90이 추가됩니다.
이 격차는 대규모 시스템 환경에서 가장 두드러집니다. KernelCare를 통해 100대의 시스템에 대한 커널 라이브 패치 서비스를 이용하면 연간 5,000달러가 듭니다. 반면 레드햇을 통해 동일한 서비스를 이용하려면 RHEL Standard 구독과 EUS를 합쳐 연간 약 115,280달러가 소요되며, 이는 약 23배나 더 비싼 금액입니다. 또한 기존 RHEL 환경 내에서 kpatch 비용을 이미 지불한 것으로 간주하더라도, 이를 계속 사용할 수 있게 해주는 EUS 이용 권한 비용만으로도 연간 약 27,390달러가 추가로 발생합니다.
RHEL만 운영한다면, kpatch는 Red Hat 라이선스 계약에 포함되어 있으므로 당연한 선택처럼 보일 수 있습니다. 이 비교의 요점은, 순수한 RHEL 환경이라 할지라도 기본 설정만으로는 겉보이는 것보다 더 많은 부분이 패치 범위에 포함되지 않는다는 점입니다. 많은 커널 CVE와 모든 사용자 공간 취약점이 패치되지 않은 채 남아 있으며, 제공되는 패치 범위는 레드햇이 선정한 기본 커널로만 제한됩니다. 또한 각 패치 기간은 약 1년 후에 만료되며, 패치를 롤백하는 것조차 재부팅을 필요로 합니다.
KernelCare는 이러한 타협점을 해소하기 위해 개발되었습니다. 이 솔루션은 심각도에 관계없이, 사용자가 어떤 커널을 실행 중이든, 심지어 지원 종료 시점을 훨씬 지난 커널에 대해서도 커널과 사용자 공간을 지속적으로 패치합니다. 롤백은 재부팅 없이 이루어지며, 맞춤형 패치는 완벽하게 관리되고, 모든 과정이 기존 시스템에서 Red Hat이 청구하는 비용의 극히 일부만으로 실행됩니다. 따라서 여러 배포판을 혼합하여 사용 중이거나, 시스템을 중단하지 않고 모든 취약점을 패치하고자 하는 경우, KernelCare가 더 나은 선택입니다.
kpatch에서 KernelCare로 전환하는 과정은 매우 간단합니다. 단 하나의 퀵스타트 스크립트로 KernelCare를 설치하면, 모든 시스템에 걸쳐 지속적인 라이브 패치 적용이 이루어지며, 기존 워크로드는 필요한 기간 동안 계속 실행됩니다.
이 서비스를 가장 먼저 체험해 보고 싶은 팀을 위해 KernelCare는 모든 기능을 이용할 수 있는 30일 무료 체험판을 제공하므로, 정식 가입 전에 중단 없는 서비스 이용이 가능한지 확인해 보실 수 있습니다.