고가용성을 위한 리눅스 커널 재부팅 없이 적용되는 패치

이 블로그 글의 AI 요약으로 바로 가기

주요 내용

리눅스 커널 재부팅 없이 패치 적용 기능은 실행 중인 커널에 보안 수정 사항을 적용하므로, 문제 해결 과정에서 재부팅을 기다릴 필요가 없습니다.
이 블로그 게시물에서는, 필수 패치 적용을 위한 재부팅을 단 한 번도 하지 않고 약 10,000개의 핵심 거래 시스템을 관리하는 5인 규모의 팀을 살펴봅니다.
재부팅 주기가 약 6개월에서 약 1년으로 두 배로 늘어났으며, 선택적 유지보수 작업으로 전환되었습니다.
재부팅 의존성을 제거함으로써 팀 간 협업을 줄일 수 있었으며, PCI DSS 시정 조치가 유지보수 일정에 포함되지 않게 되었습니다.

거래 플랫폼은 수많은 어려운 상황을 견뎌낼 수 있습니다. 하지만 주문 실행 도중에 커널이 재부팅되는 상황은 예외입니다.

커널 수정 사항이 존재하는 것과 실제 운영 시스템이 보호되는 것 사이에는 간극이 존재합니다. 업데이트가 적용된 후, 누군가는 적절한 시기를 파악하고, 변경 승인을 받고, 애플리케이션 담당자들을 소집한 다음, 시스템을 재시작해야 합니다. 리눅스 커널의 재부팅 없이 적용되는 패치 기능은 실행 중인 커널에 해당 보안 수정 사항을 적용함으로써 이러한 간극을 해소하므로, 보호 기능이 더 이상 재부팅에 의존하지 않게 됩니다.

이제 문제의 규모를 생각해 봅시다. 엔지니어 5명. 여러 데이터 센터에 걸쳐 있는 약 10,000개의 핵심 시스템으로, 주로 RHEL 기반이며 대부분 AlmaLinux를 사용합니다. 여기에 PCI DSS는 물론, 알려진 취약점을 지질학적 시간 척도보다 훨씬 빠른 시일 내에 해결해야 한다는 추가적인 보안 및 감사 기준까지 더해집니다.

이는 한 글로벌 금융 서비스 제공업체의 상황이었는데, 이곳에서는 가동 시간이 매출과 직결되며, 주문 실행에 사소한 차질이라도 생기면 바로 실적에 타격을 입게 됩니다.

커널 패치 작업이 운영 프로젝트가 될 때

재부팅을 통한 패치 작업은 대략 6개월마다 한 번씩 진행되었습니다. 이는 반년 동안의 취약점 노출이 용인될 수 있다고 생각했기 때문이 아니라, 조정 작업이 실제로 감당할 수 있는 주기가 바로 그 정도였기 때문입니다. 단일 주기를 계획하는 데만도 팀 리더의 며칠이 소요될 수 있었는데, 이는 전체 조직이 참여하기 전 단계에서 이미 발생한 일이었습니다. 게다가 각 애플리케이션 소유자와 변경 승인 담당자마다 시스템 가동 중단이 가능한 시기에 대해 서로 다른 의견을 가지고 있었습니다.

6개월이 지났지만 여전히 목표에 미치지 못했습니다. 보안 및 규정 준수 팀은 더 신속한 문제 해결을 원했습니다. 반면 엔지니어링 팀은 이미 그 빈도로 인해 과중한 업무 부담을 겪고 있었습니다. 이 두 가지 상황이 동시에 발생했다는 사실은 대개 프로세스 자체에 문제가 있다는 신호이지, 프로세스를 운영하는 사람들에게 문제가 있다는 뜻은 아닙니다.

그 비용의 대부분은 티켓 대기열에 나타나지 않습니다. 그 비용은 일정 조율, 롤백 계획 수립, 종속성 확인 등에 쓰입니다. 그 어떤 것도 단 하나의 추가 CVE도 패치하지 않습니다.

유지보수 시간대 계산은 애초에 통하지 않았다

팀 리더는 스케줄링 문제를 다음과 같이 설명했습니다:

“이 시스템들은 매우 중요해서 절대 멈출 수 없습니다. 멈출 수 있다고 해도 특정 유지보수 시간대에만 가능합니다. 하지만 그 시간대는 너무 짧아서 사실상 맞추기가 불가능했고, 모든 시스템을 재부팅하려면 100명 정도가 필요했죠.”

이는 고가용성을 추구하는 모든 기업이 결국 마주하게 되는 현실입니다. 사업이 글로벌화되고, 운영 중인 시스템 수가 계속 늘어나는 반면, 인력은 늘어나지 않으면서 업무 기간은 점점 짧아지게 됩니다.

호스트가 수백 대 정도라면, 주말에 재부팅을 무작정 반복하는 방식으로 문제를 해결할 수 있고 이를 ‘계획’이라고 부를 수도 있습니다. 하지만 5명의 인력으로 1만 대의 핵심 시스템을 관리해야 한다면, 더 이상 무작정 반복하는 방식은 통하지 않게 되며, 패치 미처리 목록은 환경의 고질적인 문제가 되어버립니다. 커널 CVE 하나마다 100명을 채용하는 것은 전략이 아닙니다.

시스템 재부팅 용량이 시스템 수에 따라 증가한다면, 예정된 재부팅 시간대를 계속 활용하는 것도 가능합니다. 그렇지 않다면, 유일한 실질적인 해결책은 취약점 수정 작업을 재부팅과 아예 연계하지 않는 것입니다.

5인 팀에 재부팅 없이 적용되는 패치 방식이 가져온 변화

여러 대안을 검토한 끝에, 해당 조직은 TuxCare의 KernelCare를 선택하여 가장 중요한 시스템 약 10,000대에 이를 배포했습니다. 테스트 결과, 안정적이고 일관된 패치 배포가 확인되었으며, ePortal을 통해 중앙 집중식으로 배포를 관리함으로써 단 5명의 인력으로 전체 과정을 파악할 수 있었습니다.

필수 패치 적용을 위한 재부팅 횟수가 0으로 줄었습니다. 재부팅은 여전히 발생하지만, 그 간격이 약 6개월에서 약 1년으로 늘어났고, 그 목적도 시간이 지남에 따라 바뀌었습니다. 재부팅은 커널 취약점을 수정하기 위한 필수 절차가 아니라 선택적 유지보수 작업으로 변모했습니다. 커널 패치 적용을 위한 팀 간 협업은 거의 사라졌으며, 이를 위해 미리 계획하던 시절도 함께 끝났습니다.

패치 배포 방식도 바뀌었습니다. 누적된 수정 사항이 한 번에 집중적으로 적용되던 방식 대신, 패치가 지속적으로 적용되므로 장기간 운영되는 시스템에서 위험이 쌓이는 것을 방지할 수 있습니다.

이것이 PCI DSS 및 감사 증거에 있어 왜 중요한가

규정 준수 프레임워크는 소요 시간을 측정합니다. 투입된 노력은 고려 대상이 아닙니다. PCI DSS는 중대 및 고위험 취약점에 대한 보안 패치가 출시 후 정해진 기간 내에 설치될 것을 요구하며, 감사관은 유지보수 기간이 지연된 이유에 대한 설명보다는 기한을 준수했다는 증거를 요청합니다.

6개월 주기를 적용하면 패치가 출시된 시점과 해당 패치가 적용되는 시점 사이에 일정 기간의 간격이 보장됩니다. 10,000대의 시스템 전반에 걸쳐, 이 간격은 분기마다 작성되는 모든 스캔 보고서에 기록됩니다. 재부팅 과정을 제거함으로써, 일정에 별도의 작업 시간을 추가하지 않고도 이 간격을 해소할 수 있습니다.

이 글을 읽어야 할 대상

감사 압박을 받고 있으며, 팀 규모가 그야말로 ‘함대’에 비할 바도 안 될 정도로 작은 환경에서 고가용성 리눅스를 운영하는 사람이라면 누구나 그럴 자격이 있다고 할 수 있습니다. 거래 플랫폼이 대표적인 사례이지만, 데이터베이스, 클러스터형 워크로드, 통신, 결제 처리, 그리고 “그냥 재부팅하면 된다”는 식의 접근이 보안 전략이 될 수 없는 모든 고객 대상 서비스에도 동일한 논리가 적용됩니다.

이 사례 연구는 6개월 주기가 왜 지속 불가능하게 되었는지, 팀이 재부팅 없이 적용 가능한 패치 방식을 평가할 때 어떤 점을 중점적으로 살펴봤는지, 그리고 그 이후 규정 준수 및 일상적인 업무량 측면에서 어떤 변화가 있었는지를 주로 해당 조직의 직접적인 설명을 바탕으로 다루고 있습니다. 분량이 짧으며, 형용사보다는 구체적인 수치에 중점을 두고 있습니다.

전체 사례 연구를 읽어보세요:

가동 시간을 유지하면서 글로벌 거래 시스템의 보안을 확보하는 방법 →

요약