RHEL 10으로의 도약: 시스템 업그레이드 전 반드시 알아야 할 5가지 반전 요소

새로운 메이저 운영체제 버전이 출시될 때마다 시스템 관리자들이 가장 먼저 느끼는 감정은 아마도 ‘마이그레이션 공포’일 것입니다. 기존의 안정적인 서비스를 유지하면서 거대한 인프라를 최신 환경으로 옮기는 작업은 늘 위험을 수반하기 때문입니다. 하지만 시니어 아키텍트의 관점에서 볼 때, Red Hat Enterprise Linux(RHEL) 10으로의 전환은 이전과는 차원이 다른 정교함을 보여줍니다.

이제 마이그레이션은 더 이상 시스템을 밀고 새로 설치하는 고통스러운 과정이 아닙니다. ‘Leapp’ 유틸리티를 통한 **인플레이스 업그레이드(In-place Upgrade)**가 표준으로 자리 잡으며, 관리자들에게 새로운 전략적 선택지를 제공하고 있습니다. 하지만 성공적인 도약을 위해서는 우리가 알고 있던 상식을 뒤집는 몇 가지 결정적인 요소들을 반드시 이해해야 합니다.

——————————————————————————–

1. “새로 설치하는 시대는 끝났다?” — 인플레이스 업그레이드의 부상과 제약

과거의 정석은 시스템의 순수성을 유지하기 위해 데이터를 백업하고 OS를 새로 설치하는 ‘클린 설치(Clean Install)’였습니다. 그러나 현대의 복잡한 엔터프라이즈 환경에서 이는 막대한 시간과 비용 낭비를 의미합니다. RHEL 10은 기존 설정과 구독 상태를 그대로 유지하는 인플레이스 업그레이드를 공식적으로 권장합니다.

“인플레이스 업그레이드(In-place upgrade)는 RHEL을 새로 설치하는 것보다 시간과 비용이 적게 듭니다.”

하지만 아키텍트로서 주의를 드리고 싶은 점이 있습니다. 인플레이스 방식이 만능은 아니라는 사실입니다. 만약 기존 시스템의 부트 로더를 BIOS에서 UEFI로 전환해야 하는 상황이라면, 인플레이스 업그레이드는 불가능하며 반드시 새로 설치를 진행해야 합니다. 또한, Leapp 유틸리티가 원활하게 작동하기 위해서는 /var/lib/leapp 디렉토리에 최소 4GB 이상의 여유 공간이 확보되어야 한다는 전제 조건도 잊지 마십시오.

——————————————————————————–

2. “건너뛰기는 불가능하다” — 아키텍처와 버전에 따른 엄격한 경로

효율성이 강조되는 시대지만, 안정성만큼은 타협이 없습니다. RHEL 8에서 RHEL 10으로 곧장 점프하는 ‘버전 건너뛰기’는 원천적으로 차단됩니다. 마이그레이션은 반드시 RHEL 8 → RHEL 9 → RHEL 10의 순차적인 단계를 밟아야 합니다.

구체적인 지원 경로를 살펴보면, 현재 RHEL 9.6(EUS)에서 10.0(EUS)으로, 또는 RHEL 9.7에서 10.1로의 이동이 가능합니다. 특히 퍼블릭 클라우드의 Pay-As-You-Go(PAYG) 인스턴스 사용자라면 주의가 필요합니다. 이 환경에서는 오직 최신 가용 업그레이드 경로만 지원되기 때문입니다.

또한 하드웨어 아키텍처에 따른 제약도 명확합니다. 64비트 ARM 시스템의 경우, 오직 4k 페이지 사이즈 커널을 사용하는 시스템에서만 인플레이스 업그레이드가 지원됩니다. 만약 시스템이 64k 페이지 사이즈 커널로 부팅되어 있다면 Leapp은 작동하지 않습니다. 이는 Red Hat이 복잡한 워크로드의 일관성을 유지하기 위해 고수하는 보수적이면서도 합리적인 안전장치입니다.

——————————————————————————–

3. “SHA-1의 종말” — 업그레이드를 원천 차단하는 보안의 벽

RHEL 10으로 가는 길목에서 가장 강력한 ‘수문장’은 바로 강화된 보안 표준입니다. RHEL 9에서 이미 예고되었던 SHA-1 알고리즘의 퇴출이 RHEL 10 업그레이드 과정에서는 실질적인 차단(Inhibit) 요소로 작용합니다.

단순한 경고가 아닙니다. 시스템 내에 RSA/SHA-1 서명이 포함된 패키지가 하나라도 남아 있다면, Leapp 유틸리티는 업그레이드 프로세스를 시작조차 하지 못하도록 막아버립니다. 이는 호환성 문제를 넘어 현대적 보안 아키텍처로의 강제적 전환을 의미합니다. 관리자는 업그레이드 전 반드시 해당 패키지를 제거하거나 RSA/SHA-256 서명이 적용된 최신 버전으로 교체하는 선결 과제를 해결해야만 합니다.

——————————————————————————–

4. “기계가 당신에게 질문을 던질 때” — Answerfile과 CLI의 상호작용

업그레이드 프로세스는 고도로 자동화되어 있지만, 시스템이 관리자의 명확한 의사 결정을 요구하며 멈춰 서는 흥미로운 변수가 있습니다. 바로 Answerfile의 존재입니다. Leapp 유틸리티는 VDO(Virtual Data Optimizer) 장치의 LVM 관리 방식 전환 여부와 같이 데이터 안전과 직결된 사안에 대해 관리자의 확답을 기다립니다.

“Label 필드에는 답변이 필요한 질문이 명시되어 있습니다.”

전통적인 방식으로는 /var/log/leapp/answerfile을 직접 편집하여 # confirm = 부분을 True 또는 False로 수정해야 합니다. 하지만 자동화에 익숙한 시니어 관리자라면 leapp answer –section <섹션명>.<필드명>=<답변> 명령어를 활용하는 ‘프로 팁’을 기억하십시오. 직접 파일을 열지 않고도 CLI에서 즉시 시스템의 질문에 답하고 프로세스를 재개할 수 있습니다.

——————————————————————————–

5. “업그레이드 후의 함정” — SELinux 모드 복구라는 필수 과제

많은 관리자가 업그레이드 완료 메시지를 보는 순간 긴장을 풉니다. 하지만 보안 아키텍트의 관점에서 작업은 아직 끝나지 않았습니다. 업그레이드 과정 중 Leapp 유틸리티는 권한 충돌을 막기 위해 SELinux 모드를 일시적으로 **’Permissive’**로 변경합니다.

문제는 업그레이드가 완료된 후에도 시스템이 자동으로 다시 보호 상태로 돌아가지 않는다는 점입니다. 시스템은 여전히 보안 경고만 출력할 뿐 실제 차단은 하지 않는 취약한 상태에 머물게 됩니다. 성공적인 마이그레이션의 진정한 마지막 단계는 반드시 /etc/selinux/config를 수정하여 SELinux를 ‘Enforcing’ 모드로 복구하는 것입니다. 이 보안 감사 단계를 누락한다면, 최신 OS로의 업그레이드가 무색하게 인프라 전체가 보안 위험에 노출될 수 있습니다.

——————————————————————————–

결론

RHEL 10으로의 업그레이드는 ‘Leapp’ 유틸리티와 새롭게 도입된 LiveMode(테크 프리뷰) 덕분에 이전보다 훨씬 정교한 제어가 가능해졌습니다. 참고로 LiveMode는 현재 테크 프리뷰(Technology Preview) 단계이므로, 생산 환경의 SLA를 보장받아야 하는 시스템에 적용하기 전에는 반드시 Red Hat의 지원 범위를 확인해야 합니다.

성공적인 마이그레이션은 단순히 도구에 의존하는 것이 아니라, 보안 아키텍처의 변화와 아키텍처별 제약 조건을 면밀히 분석하는 것에서 시작됩니다.

“당신의 인프라는 최신 엔터프라이즈 환경으로 도약할 준비가 되었습니까, 아니면 여전히 SHA-1과 같은 과거의 유산에 발목이 잡혀 있습니까?”