SRE 오류 예산으로 보안 패치 일정을 설득하는 방법

핵심 요약

오류 예산은 보안 패치를 미루는 면허가 아니라, 변경 위험과 미패치 위험을 같은 운영 언어로 비교하는 장치다. 악용 중인 취약점과 외부 노출 자산에는 별도 보안 기한을 두고, 카나리·자동 롤백·복구 리허설로 패치 자체의 장애 가능성을 낮춰야 한다.

보안팀이 “오늘 패치해야 한다”고 말하고 SRE가 “이번 주는 안정성 동결 기간”이라고 답하는 순간, 논의는 쉽게 위험 대 속도의 대립으로 흐른다. 그러나 두 팀이 실제로 지키려는 것은 같다. 고객이 서비스를 안전하고 지속적으로 사용할 수 있어야 한다는 목표다. 오류 예산은 이 목표를 숫자와 조건으로 번역해 주는 공통 언어가 될 수 있다.

다만 오류 예산을 단순히 “이번 달에 허용된 장애 시간”으로만 보면 잘못된 결론에 도달한다. 패치를 적용해 발생할 수 있는 변경 장애와, 패치를 미뤄 침해가 발생할 위험은 서로 다른 종류의 위험이다. 따라서 운영 정책은 서비스 신뢰성 예산과 보안 위험 기한을 나란히 두고 판단해야 한다.

오류 예산이 답하는 질문과 답하지 못하는 질문

오류 예산은 SLO를 기준으로 서비스가 허용 가능한 신뢰성 범위 안에 있는지 보여 준다. 예를 들어 최근 30일 가용성 목표를 이미 크게 소진했다면, 기능 출시를 줄이고 안정화 작업에 집중해야 한다는 근거가 된다. 보안 패치에도 같은 원리를 적용할 수 있다. 패치 변경으로 장애가 날 가능성이 높다면 배포 폭을 줄이고 검증을 강화해야 한다.

그러나 오류 예산만으로 다음 질문에는 답할 수 없다.

해당 취약점이 실제 공격에 사용되고 있는가
인터넷에 노출된 자산이 영향을 받는가
권한 상승, 원격 코드 실행, 인증 우회처럼 피해 상한이 큰가
완화책이 실제 공격 경로를 차단하는가
침해가 발생했을 때 탐지와 복구가 가능한가

이 정보는 자산 노출도, 공급업체 권고, CISA Known Exploited Vulnerabilities Catalog, 위협 인텔리전스, 내부 공격 경로 분석에서 가져와야 한다. KEV 포함 여부와 공급업체 공지는 시간이 지나며 바뀌므로 실제 배포 결정 시점에 다시 확인해야 한다.

두 개의 예산으로 판단한다

판단 축	묻는 질문	대표 신호	운영 결정
신뢰성 예산	변경으로 고객 오류가 얼마나 늘 수 있는가	SLO 소진율, 최근 장애, 롤백 시간	카나리 폭, 배포 시간, 승인 수준
보안 위험 기한	미패치 상태를 언제까지 허용할 수 있는가	악용 여부, 노출도, 권한, 데이터 영향	패치 마감, 임시 완화, 격리 여부
복구 능력	실패하면 얼마나 빨리 되돌릴 수 있는가	백업, 이미지, 설정 스냅샷, 연습 결과	자동 롤백·수동 복구 선택
관측 가능성	패치와 공격 징후를 구분할 수 있는가	오류율, 인증 실패, 프로세스·네트워크 로그	중단 조건과 경보 기준

핵심은 한 예산이 다른 예산을 무효화하지 않는다는 점이다. 오류 예산이 거의 남지 않았더라도 악용 중인 인터넷 노출 취약점을 무기한 미룰 수 없다. 반대로 심각도 점수만 높고 공격 경로가 차단된 내부 시스템이라면, 검증 없이 전 노드에 긴급 배포하는 것보다 단계적 적용이 더 안전할 수 있다.

실무용 패치 우선순위 레인

조직마다 이름은 달라도 최소 세 개의 레인을 두는 편이 좋다.

P0: 즉시 위험 축소

다음 조건 중 하나 이상이면 일반 변경 동결보다 우선한다.

실제 악용 사실이 확인됐거나 신뢰할 만한 기관의 악용 목록에 포함됨
인증 없이 도달 가능한 외부 노출 서비스에 영향
원격 코드 실행, 인증 우회, 광범위한 권한 탈취 가능성
이미 침해 지표가 관측되거나 자산 상태를 신뢰할 수 없음

이 레인에서는 “완벽한 패치 배포”보다 먼저 공격 경로를 줄인다. 취약 기능 비활성화, 외부 접근 차단, WAF 또는 네트워크 제한, 인스턴스 격리 같은 보완 통제를 즉시 적용하고, 병행해서 패치를 검증한다. 단, 임시 완화에는 소유자와 만료 시각을 붙여야 한다.

P1: 짧은 기한 내 계획 배포

노출은 제한돼 있지만 자산 가치가 높거나, 공격 난도가 낮고 영향 범위가 큰 경우다. 정해진 패치 SLO 안에서 staging, 카나리, 점진 확대를 수행한다. 오류 예산이 부족하다면 배포를 취소하는 대신 한 번에 바꾸는 노드 수를 줄이고 관찰 시간을 늘린다.

P2: 정기 유지보수

공격 경로가 없거나 보완 통제가 검증됐고, 영향이 제한적인 항목은 정기 창구에 넣는다. 이 레인의 가장 큰 위험은 영구 미적용이다. 자산 소유자, 목표 버전, 완료일, 예외 만료일을 자동 추적해야 한다.

오류 예산을 패치 설계에 연결하는 방법

1. 배포 단위를 줄인다

오류 예산이 빠르게 소진되는 서비스라면 “패치하지 않는다”가 아니라 “폭발 반경을 줄여 패치한다”가 맞다. 한 리전의 소수 인스턴스, 비핵심 워커, 읽기 전용 복제본부터 시작한다. 상태 저장 시스템은 복제와 장애 조치 조건을 먼저 검증한다.

2. 정상·보안·비용 신호를 함께 본다

패치 성공 기준에 HTTP 오류율만 넣으면 부족하다. 인증 실패, 권한 거부, 비정상 프로세스, 외부 연결, 큐 적체, 재시도 폭증, CPU와 메모리, 클라우드 비용도 함께 관찰해야 한다. 보안 패치가 동작을 바꾸면서 정상 요청을 차단하거나, 반대로 보호 기능이 비활성화될 수 있기 때문이다.

3. 중단 조건을 배포 전에 적는다

예를 들어 다음처럼 수치와 행동을 연결한다.

카나리 5% 배포
  → 15분 동안 5xx·지연·인증 실패·큐 지연 관찰
  → 기준선 대비 임계치 초과 시 자동 중단
  → 데이터 형식 변경이 없으면 자동 롤백
  → 롤백 불가 변경이면 트래픽 차단 후 복구 절차 실행

구체적인 임계치는 서비스의 SLO와 평소 변동폭을 사용해야 한다. 모든 서비스에 같은 1% 기준을 복사하면 잡음이 많거나 실제 이상을 놓칠 수 있다.

4. 패치 SLO를 별도로 운영한다

“Critical은 7일”처럼 심각도 하나만으로 기한을 정하지 말고 악용, 노출, 자산 중요도, 완화 가능성을 반영한다. 예시는 다음과 같다.

조건	목표 행동
악용 중 + 외부 노출	즉시 격리 또는 완화, 최우선 검증·배포
악용 중 + 내부 한정	접근 경로 확인, 세분화, 짧은 기한 내 배포
고위험 + 보완 통제 없음	다음 승인 창구보다 앞당겨 적용
보완 통제 검증됨	예외 만료일까지 패치, 통제 상태 지속 감시
영향 불명	자산 식별과 버전 확인부터 긴급 수행

NIST SP 800-40 Rev. 4는 패치 관리를 단순 설치 작업이 아니라 예방적 유지보수와 위험 대응 과정으로 다룬다. 정책에는 발견, 우선순위화, 테스트, 배포, 검증, 예외 종료가 모두 들어가야 한다.

흔한 실패 모드

오류 예산이 없으니 긴급 패치를 미룬다

신뢰성 상태가 나쁠수록 침해 발생 시 복구도 어려울 가능성이 크다. 이 경우 패치 범위를 줄이고, 트래픽을 우회하고, 추가 인력을 붙이는 식으로 위험을 낮춰야 한다. 미루는 결정에는 반드시 보완 통제와 종료일이 필요하다.

CVSS 점수만으로 모든 시스템에 같은 기한을 준다

인터넷에서 인증 없이 도달 가능한 취약점과, 격리된 테스트 장비의 동일 취약점은 우선순위가 다르다. 반대로 낮은 점수라도 핵심 인증 체인의 취약점이면 사업 영향이 클 수 있다.

패치 설치 성공을 완료로 처리한다

버전 문자열이 바뀌었어도 프로세스가 재시작되지 않았거나, 일부 노드가 이전 이미지로 남거나, 로드밸런서 뒤에 미적용 인스턴스가 있을 수 있다. 실제 요청 경로의 버전과 동작을 검증해야 한다.

롤백만 믿고 데이터 변경을 놓친다

스키마 마이그레이션, 저장 형식, 키 회전은 바이너리 롤백만으로 되돌아가지 않는다. forward-compatible 변경과 복구 절차를 별도로 설계한다.

예외 목록이 자산 목록보다 오래 산다

예외는 시스템 폐기, 소유자 변경, 네트워크 노출 변경과 함께 재평가돼야 한다. 티켓이 닫혔다는 사실보다 실제 버전과 공격 경로가 사라졌는지 확인한다.

탐지 신호와 대시보드

자산별 취약 버전 잔존 기간과 패치 SLO 초과 수
KEV 또는 공급업체 긴급 공지와 내부 자산의 교집합
외부 노출 자산 중 소유자·버전이 불명확한 비율
카나리 단계별 오류율, 지연, 인증 실패, 롤백 횟수
패치 후 재부팅 또는 프로세스 재시작이 누락된 노드
예외 만료 초과, 보완 통제 비활성화, 방화벽 규칙 변경
동일 취약점의 반복 재등장과 이미지·템플릿 원인
평균 패치 시간뿐 아니라 90·95백분위 완료 시간

평균만 보면 오래 남은 소수의 고위험 자산이 가려진다. 가장 오래 미적용된 자산과 가장 중요한 자산을 별도 목록으로 보여 주는 편이 낫다.

운영 체크리스트

패치 우선순위는 CISA KEV 기반 패치 분류와 연결하고, 서버리스처럼 배포 단위가 다른 환경은 서버리스 함수 보안의 트리거·IAM·버전 관리 기준을 함께 적용해야 한다. 침해가 패치보다 먼저 발생할 가능성에 대비해 랜섬웨어 백업 불변성과 복구 훈련도 같은 운영 지표로 관리하는 것이 좋다.

최종 판단

오류 예산은 보안팀을 설득하기 위한 숫자도, 패치를 거부하기 위한 방패도 아니다. “얼마나 위험한 변경을 어느 폭으로 수행할 수 있는가”를 정하는 도구다. 악용과 노출이 큰 취약점에는 별도 보안 기한을 적용하고, 오류 예산이 부족할수록 카나리·관찰·자동 중단·복구 준비를 강화해야 한다. 이렇게 해야 보안 패치는 안정성과 경쟁하는 일이 아니라 장기 신뢰성을 지키는 운영 작업이 된다.