패치 관리, 업데이트를 미루지 않는 구조

미뤄지는 이유를 먼저 제거합니다

보안 업데이트가 미뤄지는 이유는 세 가지입니다. 첫째, 적용 중 서비스가 멈출까 두렵습니다. 둘째, 어느 서버가 어떤 상태인지 모릅니다. 셋째, 적용 작업이 손으로 하는 일이라 시간이 많이 듭니다. 자동화는 세 번째만 해결합니다. 그래서 먼저 첫째와 둘째를 처리해야 합니다. 첫째는 점검 창을 정하고 서버를 나눠 순차 적용하는 방식으로 해결합니다. 둘째는 현재 패치 상태를 한 화면에서 볼 수 있게 만드는 것으로 해결합니다. 이 두 가지가 갖춰진 뒤에 자동 적용을 켜면, 자동화가 신뢰를 얻고 유지됩니다.

서버를 묶음으로 나누고 순차로 적용합니다

모든 서버에 동시에 적용하면 문제가 생길 때 전체가 영향을 받습니다. 그래서 묶음을 나눕니다. 1묶음은 시험 환경입니다. 2묶음은 운영 중 영향이 작은 서버입니다. 3묶음은 핵심 서버입니다. 적용 간격을 두어 1묶음에서 문제가 없으면 다음으로 넘어갑니다. 또 적용 승인 지연을 설정합니다. 공개된 지 며칠 지난 업데이트만 적용하도록 두면, 문제가 알려진 업데이트를 먼저 걸러낼 수 있습니다. 지연을 너무 길게 두면 노출 기간이 늘어나므로, 보안 등급이 높은 업데이트는 지연을 짧게 두는 예외를 만듭니다.

자동화의 회수 기간을 계산합니다

학습용 가정으로 계산합니다. 가정값은 서버 20대이고 서버당 수동 패치와 확인에 월 20분이 든다고 두겠습니다. 월 작업 시간은 400분이고 내부 시간 비용을 시간당 30,000원으로 가정하면 200,000원입니다. 자동화 구성에 8시간이 들면 일회성 240,000원입니다. 중간 계산값인 회수 기간은 240,000원을 200,000원으로 나눈 1.2개월입니다. 최종 효과에는 누락이 사라지는 몫이 더해집니다. 손으로 할 때는 20대 중 몇 대가 빠지기 쉬운데, 자동화하면 적용 결과가 목록으로 남아 빠진 서버를 바로 알 수 있습니다.

재시작이 필요한 업데이트가 남습니다

결론을 뒤집는 조건은 재시작입니다. 커널이나 핵심 라이브러리 업데이트는 적용 후 재시작해야 효력이 생깁니다. 자동 적용만 켜 두면 패치는 설치됐지만 재시작하지 않아 취약점이 그대로 남는 상태가 됩니다. 그래서 패치 상태 화면에서 '재시작 대기' 항목을 따로 봐야 하고, 재시작 일정을 별도로 잡아야 합니다. 두 번째 조건은 고정 버전 요구입니다. 특정 버전에 묶인 애플리케이션이 있으면 그 패키지는 자동 적용 대상에서 제외하고, 제외 목록과 이유를 문서에 적습니다. 제외 목록이 길어지면 애플리케이션 쪽을 손봐야 합니다.

서버 운영 실행 전 점검표

• 점검 창과 서버 묶음을 정해 순차 적용한다
• 현재 패치 상태를 한 화면에서 확인할 수 있다
• 승인 지연을 설정하고 보안 등급별 예외를 두었다
• 재시작 대기 항목과 제외 목록을 따로 관리한다