2025/03/13

10. 오라클 리눅스의 두 가지 커널 “UEK”와 “RHCK” 이해하기

오라클 리눅스는 두 가지 커널을 제공합니다: RHEL과 호환되는 커널인 Red Hat Compatible Kernel(RHCK)과 오라클 리눅스 고유의 Unbreakable Enterprise Kernel(UEK)입니다.

오라클 리눅스를 처음 사용하는 경우 Unbreakable Enterprise Kernel에 대해 걱정할 수 있습니다. 이 기사에서는 Unbreakable Enterprise Kernel을 설명하고, 그 호환성 및 언제 사용해야 하는지에 대한 기준을 알아봅니다.

Red Hat Compatible Kernel과 Unbreakable Enterprise Kernel

기본 소개로, Red Hat Compatible Kernel과 Unbreakable Enterprise Kernel에 대한 개요를 제공합니다.

Red Hat Compatible Kernel이란?

이름에서 알 수 있듯이, Red Hat Compatible Kernel(RHCK)은 RHEL과 호환되는 커널로, RHEL 커널 소스 코드를 단순히 재빌드한 버전입니다. 단순히 재빌드된 버전이기 때문에 버그를 포함하여 RHEL과 동일한 버전 번호를 가질 경우 동일하게 동작합니다.

다음 표는 오라클 리눅스의 각 주요 버전에 대한 RHCK 및 glibc 버전을 보여줍니다. 동일한 리눅스 주요 버전 내에서의 호환성을 강조하기 위해 커널 및 glibc와 같은 중요한 구성 요소의 기본 버전은 변경되지 않습니다. 대신, 업데이트가 있을 때 아래에 설명된 대로 릴리스 번호가 변경됩니다.

리눅스 버전	RHCK 버전	glibc 버전
오라클 리눅스 9	5.14.0	2.34
오라클 리눅스 8	4.18.0	2.28
오라클 리눅스 7	3.10.0	2.17

다음 다이어그램은 커널과 glibc의 RPM 패키지 이름을 보여줍니다. 업데이트 패키지가 릴리스될 때 기본 버전은 동일하게 유지되며, 릴리스 번호가 업데이트됩니다.

그림 1 커널/glibc 버전 및 릴리스

Unbreakable Enterprise Kernel란?

Unbreakable Enterprise Kernel(UEK)은 오라클 리눅스에 고유한 커널로, RHCK보다 최신 커널을 기반으로 하며 RHCK와 호환됩니다. 다음 매뉴얼은 그 기능에 대한 참고 자료를 제공합니다.

공식 문서: Unbreakable Enterprise Kernel

Unbreakable Enterprise Kernel(UEK)은 오라클이 빌드하고 오라클 리눅스 지원을 통해 지원되는 리눅스 커널입니다. 성능, 안정성, 그리고 실용적으로 메인라인 소스 코드를 최대한 가깝게 추적함으로써 최소한의 백포트를 목표로 합니다. UEK는 오라클의 엔지니어드 시스템, 오라클 클라우드 인프라, 그리고 오라클 고객의 대규모 엔터프라이즈 배포를 실행하기 위해 철저히 테스트되었습니다.

리눅스용 데이터베이스 설치 가이드

Unbreakable Enterprise Kernel은 오라클 리눅스 커널에 기본으로 포함되고 활성화되어 있습니다. 이는 최근의 안정적인 메인라인 개발 리눅스 커널을 기반으로 하며, 오라클 데이터베이스, 오라클 미들웨어, 오라클 하드웨어 엔지니어링 팀과의 협력으로 개발된 최적화를 포함하여 가장 까다로운 엔터프라이즈 워크로드에 대한 안정성과 최적의 성능을 보장합니다.

주요 내용은 다음과 같습니다:

UEK는 오라클이 개발하고 지원하는 리눅스 커널입니다.
오라클 리눅스의 기본 커널
최신 안정적인 메인라인 리눅스 커널 버전을 기반으로 함
Exadata 및 오라클 데이터베이스 팀과 협력하여 성능과 안정성에 중점을 두고 개발됨
Exadata 및 오라클 클라우드 인프라를 포함한 대규모 엔터프라이즈 워크로드 환경에서 테스트됨

오라클 리눅스와 커널 버전의 관계

UEK 버전 번호는 기반이 되는 커널에 따라 변경되며, 예를 들어 UEK6, UEK7 등으로 이름이 붙습니다. 또한 RHCK와의 주요 차이점은 오라클 리눅스의 주요 버전과 UEK 버전이 고정되지 않는다는 점입니다. 다음 표는 UEK와 오라클 리눅스의 대응 관계를 보여줍니다. 이 표에서 알 수 있듯이, 오라클 리눅스 8은 UEK6와 UEK7을 사용할 수 있습니다.

UEK 버전	커널 버전	오라클 리눅스 7	오라클 리눅스 8	오라클 리눅스 9
UEK7	5.15.0	×	○	○
UEK6	5.4.17	○	○	×
UEK5	4.14.35	○	×	×
UEK4	4.1.12	○	×	×

다음 표는 오라클 리눅스에 대한 RHCK와 UEK의 커널 버전을 비교합니다. 오라클 리눅스 9는 2022년에 출시되었으므로 RHCK와 UEK 버전 간의 차이는 작습니다. 그러나 오라클 리눅스 7과 오라클 리눅스 8은 출시된 지 시간이 꽤 지났기 때문에 RHCK와 UEK 버전 간의 차이가 큽니다.

리눅스 버전	RHCK	UEK
오라클 리눅스 9	5.14.0	5.15.0
오라클 리눅스 8	4.18.0	5.4.17, 5.15.0
오라클 리눅스 7	3.10.0	4.1.12, 4.14.35, 5.4.17

리눅스 커널 버전 명명 규칙

이제 리눅스 커널 버전에 대해 다루었으니, 명명 규칙을 다시 살펴보겠습니다. 사실, 명명 규칙은 여러 번 변경되었기 때문에 절대적인 것은 없으며, 원래 kernel.org와 리눅스 배포판 간에 약간의 차이가 있습니다.

kernel.org의 명명 규칙

먼저, 공식 리눅스 커널 사이트인 kernel.org에서 사용하는 명명 규칙을 살펴보겠습니다. 리눅스 커널은 “abc“와 같이 이름이 붙으며, 다음과 같이 불립니다. 그러나 이 명명 규칙은 절대적이지 않습니다.

a : 주요 릴리스 번호
b : 부 릴리스 번호
c : 패치 번호 또는 리비전 번호

또한, 5.19 다음 버전은 6.0이 되지만, 이는 기능이 크게 변경되었기 때문이 아닙니다. 단순히 b 숫자가 너무 커지는 것이 바람직하지 않으며, b가 약 20에 도달하면 a를 증가시키는 관례입니다. 그리고 c는 버그 수정과 같은 패치 수준의 수정입니다. 이러한 이유로, 이제는 “ab” 또는 “abc” 조합을 릴리스 번호 또는 버전 번호라고 부르는 것이 일반적입니다.

다음 다이어그램에서 주요 릴리스(Major Release)는 더 이상 많이 사용되지 않기 때문에 취소선이 그어져 있지만, 첫 번째 숫자를 명시적으로 나타내고 싶을 때는 여전히 사용됩니다.

그림 2 리눅스 커널 버전 명명 규칙

다음 다이어그램을 보세요. 리눅스 커널의 개발 이력을 보여줍니다. 회색 부분은 개발 기간이며, 일정 기간 후에 개발이 다음 버전으로 넘어갑니다. 즉, 특정 리눅스 릴리스 “abc“는 몇 년마다 “개발 → 지원 → LTS(장기 지원)”의 라이프사이클을 반복합니다. LTS 커널은 매년 한 번씩 릴리스되며 약 5년 동안 지원됩니다.

출처: https://en.wikipedia.org/wiki/Linux_kernel_version_history

그림 3 리눅스 커널 버전 이력 6.x

그림 4 리눅스 커널 버전 이력 5.x

리눅스 배포판의 명명 규칙

리눅스 배포판과 kernel.org의 명명 규칙은 약간 다릅니다. 리눅스 배포판 커널은 “abc-z“와 같이 이름이 붙지만, 실제로는 대부분의 배포판에서 “ab0-z“로, c가 0입니다. 이는 RHEL뿐만 아니라 우분투, 그리고 UEK7 이후 버전에도 해당됩니다.

다음 다이어그램은 리눅스 배포판에서 커널 버전이 어떻게 불리는지를 보여줍니다. 현재 공통된 이해는 없으며, 사용 맥락과 사람에 따라 다르게 보입니다.

그림 5 리눅스 배포판 이름

기본 버전(Base Version)이라는 용어는 이 플랫폼에서 새로 도입된 것입니다. 이는 기반이 되는 kernel.org 버전을 나타냅니다. 그러나 c 숫자가 0으로 강제되므로, 기본 버전이 5.15.0이라 하더라도 기반이 되는 커널 버전이 반드시 5.15.0은 아닙니다. 예를 들어, UEK7은 버전 5.15.0이지만 5.15.6을 기반으로 합니다.

$ rpm -q --changelog kernel-uek-5.15.0-105.125.6.2.2.el9uek | tail -n 2 - Linux 5.15.6 (Greg Kroah-Hartman)

메인라인, 롱텀, 스테이블, rc 간의 관계

공식 리눅스 커널 페이지인 The Linux Kernel Archives를 살펴보겠습니다. 여러 리눅스 커널 버전이 나열되어 있으며, 메인라인(mainline), 롱텀(longterm), 스테이블(stable), rc와 같은 라벨이 붙어 있습니다. 아래에서 각각을 설명하겠습니다.

그림 6 The Linux Kernel Archives

다음 다이어그램은 kernel.org에서 발췌한 일부 커널 버전에 주석을 추가한 것입니다. 메인라인은 주요 개발입니다. rc(릴리스 후보)가 사용 가능해지면 공식 버전이 되므로 메인라인과 스테이블은 동일한 상태를 나타냅니다. 스테이블 버전 중 몇 개 버전마다 롱텀(long-term)이 되어 장기간 지원됩니다.

그림 7 kernel.org의 라이프사이클

백포팅이란?

여기서 기억해야 할 단어가 있습니다: 백포팅(backporting). 백포팅은 소프트웨어의 최신 버전에 포함된 기능이나 수정 사항을 이전 버전에 적용하는 것을 의미합니다.

예를 들어, 6.0 버전에서 도입된 새 패치를 5.0 버전에 적용하는 것을 백포팅이라고 합니다. 일반적으로 두 버전 간의 차이가 클수록 코드 베이스의 차이도 커져 적용이 더 어려워집니다. 또한, 해당 버그가 이전 버전에 존재하지 않는 경우 백포팅이 필요 없을 수도 있습니다.

백포팅의 반대가 무엇인지 궁금해하는 사람도 있을 수 있습니다. 예를 들어, 소프트웨어 5.0 버전의 버그 수정을 6.0 버전에 적용하는 경우입니다. 조사해 보았지만 일반적인 용어는 없으며, 백포트, 병합(merging), 포워드-포팅(forward-porting) 등이 사용되는 것으로 보입니다. 많은 사람들이 별생각 없이 백포트라고 부르는 것 같습니다.

다음은 앞에서 소개한 UEK 설명의 일부입니다.

그 초점은 성능, 안정성, 그리고 메인라인 소스 코드를 실용적으로 최대한 가깝게 추적함으로써 최소한의 백포트에 있습니다.

지금까지 논의한 내용을 고려할 때, 오라클은 다음과 같은 주장을 하고 있습니다:

최신 메인라인 소스 코드는 더 많은 새 기능과 버그 수정을 포함하므로 더 나은 성능과 안정성을 가질 가능성이 높습니다.
최신 메인라인 소스 코드로 시작하면 소스 코드의 차이가 적어 최소한의 백포팅만 필요합니다.

리눅스 내부 구조의 기본 지식

UEK에 대해 알아야 할 가장 중요한 것 중 하나는 RHEL 커널(RHCK)과의 호환성입니다. 호환성을 이해하려면 리눅스 OS에 대한 지식이 필수적입니다. 따라서 리눅스 내부 구조의 기본을 설명하겠습니다.

리눅스 OS의 주요 구성 요소

다음 다이어그램은 리눅스 OS의 주요 구성 요소와 그 관계를 보여줍니다. 리눅스 OS를 이해하려고 할 때 이 정보를 기억하는 것이 중요합니다.

리눅스 커널
커널은 리눅스 OS의 핵심 구성 요소입니다. 애플리케이션으로부터 요청을 받아 프로세스 관리와 메모리 관리를 수행하여 프로그램을 실행합니다. 또한 커널 모듈인 디바이스 드라이버를 사용하여 파일 시스템을 관리하고 I/O를 위해 디바이스를 제어합니다. 커널의 역할은 다음과 같이 요약할 수 있습니다. 하드웨어에 작용하는 기능으로 이해하는 것이 가장 좋습니다.
- CPU, 메모리, 디스크, 네트워크 카드 등의 하드웨어 리소스 관리
- 리눅스에서 실행되는 애플리케이션의 프로세스 관리 및 제어
커널 모듈
커널 모듈은 커널의 기능을 확장하는 바이너리 파일입니다. 주로 디바이스 드라이버이며, 필요할 때 로드할 수 있는 형식입니다. 이를 통해 드라이버를 추가하여 새 하드웨어를 지원할 수 있으며, 메모리 사용량도 줄일 수 있습니다.
시스템 라이브러리
시스템 라이브러리(또는 간단히 라이브러리)는 프로그램에서 일반적으로 사용되는 함수 모음으로, 운영 체제가 제공하는 대부분의 기능을 제공합니다. 가장 유명한 것은 리눅스에서 사용되는 표준 C 라이브러리인 glibc입니다. glibc는 원래 GNU가 GNU C 라이브러리로 개발했기 때문에 그렇게 불립니다.

그림 8. 리눅스의 내부 구조

기본 이해(라이브러리 함수와 시스템 호출)

그림 8의 애플리케이션은 OS에 표준으로 포함된 명령어와 유틸리티를 포함한 다양한 프로그램을 의미합니다. 이러한 프로그램은 라이브러리 함수와 시스템 호출을 호출하여 실행됩니다. 이 둘의 차이를 이해해 봅시다.

“라이브러리 /lib64” /usr/lib에 설치되어 있습니다. nm 명령으로 glibc의 심볼 정보를 표시하면 printf()가 포함되어 있는 것을 볼 수 있습니다. 심볼 정보란 라이브러리 또는 실행 프로그램에 포함된 함수와 변수를 의미합니다.

printf()는 주어진 인수에 따라 작동하며, 필요할 경우 커널에 명령을 내립니다.

$ rpm -qf /lib64/libc.so.6 glibc-2.34-60.0.3.el9.x86_64 $ nm /lib64/libc.so.6 | grep "T printf" 000000000006f430 T printf 000000000006e8f0 T printf_size 000000000006f350 T printf_size_info

“시스템 호출”은 파일 입출력, 새 프로세스 생성, 네트워크 통신 등 하드웨어를 조작하는 기능을 제공합니다. 그림 8에서 시스템 호출은 애플리케이션에서 직접 호출됩니다. 그러나 glibc에 포함된 시스템 호출 래퍼 함수를 통해 호출될 수도 있습니다.

여기까지 읽으셨나요? glibc와 같은 라이브러리가 매우 중요하다는 것을 알 수 있습니다. 이러한 이유로 RHEL 기반 배포판은 주요 버전이 변경될 때까지 glibc 버전을 변경하지 않습니다.

커널 모드와 사용자 모드

커널 모드와 사용자 모드를 설명합니다.

커널 및 디바이스 드라이버와 같이 하드웨어 리소스에 접근하는 프로그램은 “커널 모드”라는 특별한 권한 모드에서 실행됩니다. 이는 CPU의 보호 기능을 활용하는 단일 격리된 메모리 공간에서 실행되며, 컨텍스트 전환이 필요 없기 때문에 매우 빠르게 실행됩니다. 커널은 각 프로세스를 실행할 뿐만 아니라 하드웨어에 대한 보호된 접근도 제공합니다.

반면, 일반 프로그램은 “사용자 모드”라는 메모리 공간에서 실행됩니다. 사용자 모드에서 실행되는 프로그램은 하드웨어에 직접 접근할 수 없습니다. 대신 시스템 호출을 통해 커널 함수에 접근하며, 궁극적으로 커널이 하드웨어에 접근합니다.

기본 지식 요약

지금까지 다룬 리눅스 내부 구조의 기본을 간단히 요약해 보겠습니다.

커널과 glibc는 모두 리눅스의 중요한 구성 요소이지만 역할이 다릅니다.
커널은 하드웨어 제어를 담당합니다.
라이브러리는 일반 프로그램에서 사용되는 함수를 제공합니다. 가장 중요한 라이브러리는 glibc입니다.
하드웨어에 접근하려면 시스템 호출을 해야 합니다.
프로그램은 시스템 호출 또는 라이브러리 함수를 통해 하드웨어에 접근합니다.

컨테이너의 작동 방식

다음으로 컨테이너에 대해 설명하겠습니다. 커널에 대해 설명한 후에 “왜 컨테이너인가?”라고 궁금해할 수도 있습니다. 그 이유는 컨테이너의 작동 방식을 이해하는 것이 커널 호환성을 이해하는 데 좋은 주제이기 때문입니다.

컨테이너 구조

다음 다이어그램은 하이퍼바이저 기반 가상화와 컨테이너 기반 가상화를 비교합니다: 가상 머신에는 게스트 OS와 커널이 있지만, 컨테이너에는 애플리케이션과 라이브러리만 포함되며 커널은 없습니다.

그림 9 하이퍼바이저 타입과 컨테이너 타입의 차이

컨테이너에 커널이 필요 없는 이유는 호스트 OS의 커널을 사용하기 때문입니다. 컨테이너는 cgroups 및 Namespace와 같은 리눅스 기능을 사용하여 컨테이너 간 격리를 하지만, 호스트 OS에서 실행되는 프로세스일 뿐입니다. 다음 다이어그램을 보세요. 컨테이너는 애플리케이션 실행에 필요한 라이브러리와 프로그램만 포함하면 실행됩니다.

그림 10 컨테이너의 작동 방식

리눅스 커널 호환성

여기서 중요한 점이 있습니다.

컨테이너 이미지가 생성된 OS가 호스트 OS와 다른 리눅스 버전이라도 작동합니다.

예를 들어, 컨테이너 엔진이 실행되는 호스트 OS가 Ubuntu Server 22.04 LTS라고 가정해 봅시다. 이 경우 컨테이너 이미지가 오라클 리눅스 9로 생성되었더라도 필요한 라이브러리와 바이너리가 포함되어 있으면 작동합니다. 둘 다 리눅스여야 하지만, 리눅스 커널 버전이 약간 달라도 작동할 수 있습니다.

그러나 이는 기술적으로 작동하는지의 문제일 뿐, 벤더가 기술 지원을 제공하는지와는 무관합니다.

그림 11 리눅스 커널 호환성

좀 더 자세히 설명하겠습니다. 아래 그림 12를 보세요. 리눅스에서 애플리케이션과 커널 간의 인터페이스는 시스템 호출로, 이를 Application Binary Interface(ABI)라고 합니다. 리눅스 커널은 이전 버전에서 존재하는 시스템 호출을 동일한 사양으로 호출할 수 있도록 호환성을 고려하여 개발됩니다. 따라서 리눅스 커널 버전이 약간 달라도 애플리케이션은 동일하게 작동합니다.

그림 12 Application Binary Interface를 통한 호환성 유지

Application Binary Interface(ABI)

ABI는 인터페이스 정의로, 구체적으로 시스템 호출 이름, 인수 데이터 타입, 인수 개수, 반환 값 데이터 타입 및 값 등을 의미합니다. 리눅스 커널은 이러한 것들이 변경되지 않도록 개발됩니다. ABI가 변경되지 않으면 시스템 호출을 호출할 때 오류가 발생하지 않습니다.

그러나 커널 버전이 다르면 시스템 호출의 내부 구현이 다를 수 있습니다. 하지만 시스템 호출은 “디스크에 데이터 쓰기” 또는 “메모리 할당”과 같은 하드웨어에 대한 기본 명령이므로 외부 동작도 동일하게 만들어집니다. 이것이 호환성이 유지되는 방식입니다.

그림 13 ABI로 유지되는 호환성

주의해야 할 비호환성

반면, 어떤 비호환성에 주의해야 할까요? 아래 그림 14를 보세요. 디바이스 드라이버와 같은 커널 모듈입니다. 커널 버전 번호가 일치하더라도 마지막 릴리스 번호가 다르면 작동하지 않을 수 있습니다. 일부 커널 모듈은 릴리스 번호의 약간의 차이를 흡수할 수 있지만, 재컴파일이 권장됩니다.

커널과는 무관하지만, 애플리케이션 호환성과 관련해 주의해야 할 것은 언어, 프레임워크 등에서 사용되는 라이브러리입니다. 라이브러리는 자주 업데이트되며, XXX 라이브러리 2.0 이상과 같은 제한이 있는 경우가 일반적입니다.

그림 14. 커널 모듈 비호환성

UEK와 RHCK 비교

이제 기본 사항을 다루었으니, 마침내 주요 주제인 호환성과 기능 비교에 도달했습니다.

RHCK와의 호환성

이것은 UEK와 RHCK 간의 호환성에 관한 것입니다. 여기까지 읽었다면 이미 아실 겁니다. UEK는 RHCK와 ABI 호환성을 유지하도록 개발되었습니다. 따라서 사용자 모드에서 실행되는 일반 애플리케이션이라면 호환됩니다.

그러나 몇 가지 주의할 점이 있습니다.

상용 소프트웨어 제품 지원
첫 번째로, 상용 소프트웨어 제품이 지원되는지 여부입니다. 상용 소프트웨어 제품이 오라클 리눅스를 지원하더라도 RHCK는 지원하지만 UEK는 지원하지 않을 수 있습니다. 실제로 사용자 모드에서 실행되는 애플리케이션은 보통 문제없이 실행되지만, 벤더의 지원 정책을 우선시하려면 RHCK를 사용하세요.

호환성에 주의가 필요한 상용 소프트웨어의 예로는 안티바이러스 제품이 있습니다. 일부 안티바이러스 제품은 커널 모듈로 실행되므로, 이 경우 호환성을 확인해야 합니다.

일본 소프트웨어는 선택 폭이 넓지 않지만, 오라클 리눅스 ISV 카탈로그에서 오라클 리눅스 호환성을 확인할 수 있습니다.

잘 알려진 제조업체의 서버 사용 시
가장 주의해야 할 점은 오라클 리눅스가 지원 하드웨어 목록에 포함되어 있는지입니다. 제조업체에서 지원하지 않으면 문제가 발생했을 때 도움을 받을 가능성이 낮습니다.

또한, 서버 머신에는 RAID 컨트롤러나 NIC와 같은 특수 하드웨어가 장착되어 있어 제조업체가 자체 디바이스 드라이버를 제공할 수 있습니다. 드라이버가 지원되지 않으면 사용할 수 없을 수도 있습니다.

제조업체의 웹 페이지 또는 오라클 리눅스 하드웨어 인증 목록에서 지원 정보를 확인하세요. 여기에는 RHCK와 UEK 지원 정보도 포함되어 있습니다.

기능 차이

기능 차이를 일반화하기는 어렵습니다. 커널 버전에 따라 다르기 때문입니다. 하지만 일반적으로 UEK는 최신 메인라인 커널을 기반으로 하므로 더 나은 성능과 기능을 제공합니다.

예를 들어, 오라클 리눅스 9에서 UEK7의 기본 버전은 5.15.0이고, RHCK의 기본 버전은 5.14.0입니다. 현재로서는 큰 차이가 없습니다. 그러나 다음 표에서 볼 수 있듯이, UEK는 동일한 주요 버전 내에서도 변경됩니다. 몇 년 후에는 오라클 리눅스 9용 UEK8이 출시될 것이며, 커널 버전의 차이가 더 커질 것입니다.

리눅스 버전	UEK4	UEK5	UEK6	UEK7
오라클 리눅스 9	×	×	×	○
오라클 리눅스 8	×	×	○	○
오라클 리눅스 7	○	○	○	×

UEK에만 있는 잘 알려진 기능으로는 ocfs2와 btfs가 있습니다. 다른 기능도 있지만, 자세한 내용은 “Unbreakable Enterprise Kernel 릴리스 노트“의 “신규 기능 및 변경 사항”을 참조하세요.

그림 15. Unbreakable Enterprise Kernel 릴리스 7 릴리스 노트

요약: 언제 UEK를 사용하고 언제 RHCK를 사용해야 할까?

UEK는 대규모 오라클 데이터베이스 및 오라클 리눅스 KVM 워크로드를 위해 설계되었으며, 최신 커널을 기반으로 하여 더 나은 성능과 기능을 제공하는 경우가 많습니다.

그러나 UEK가 절대적으로 필요한 것은 아닙니다. 상황과 목적에 따라 사용해야 한다고 생각합니다. 다음의 경우 1과 2에서는 RHCK 사용을 고려해야 합니다. 중요한 것은 UEK와 RHCK의 차이를 이해하고 적절히 사용하는 것입니다. 지금까지 설명한 내용을 요약한 표도 소개하겠습니다.

물리적 서버를 사용 중이고 제조업체가 RHCK만 지원한다면
RHCK를 사용하세요.
상용 소프트웨어를 사용 중이고 벤더가 RHCK만 지원한다면
RHCK를 사용하는 것이 좋습니다. 그러나 자체 시스템에서 사용 중이며 위험을 감수할 수 있다면 UEK도 선택지입니다.

UEK와 RHCK의 장단점

항목	장점	단점
기능 및 성능	비교하는 UEK와 RHCK 버전에 따라 다르지만, UEK는 최신 메인라인 커널을 사용하므로 더 나은 기능과 성능을 가질 가능성이 높으며, 오라클 데이터베이스에 대한 최적화도 포함될 수 있습니다.
사용자 모드에서 실행되는 애플리케이션의 호환성	호환됨	상용 패키지 제품의 경우, 벤더의 지원 정책에 따라 지원되지 않을 수 있음
커널 모드에서 실행되는 커널 모듈	소스 코드로 제공되는 디바이스 드라이버 등은 호환될 가능성이 높음	커널 모드에서 실행되는 안티바이러스 소프트웨어 및 디바이스 드라이버는 일반적으로 호환되지 않음
기타		잘 알려진 제조업체의 서버는 오라클 리눅스(RHCK)를 지원하지만 UEK는 지원하지 않을 수 있음