운영 중인 시스템을 재부팅 없이 갱신하고 싶다는 욕구는 서버 운영자라면 누구나 가져봤을 것이다. 마이크로소프트의 핫패치(hot-patching)는 바로 이 지점을 겨냥한다. 메모리에 적재된 함수를 실행 중에 교체해 보안 패치를 적용하고 재부팅을 미룰 수 있게 해준다. 레이먼드 첸의 'The Old New Thing' 블로그는 최근 이 메커니즘을 짧게 훑으면서, 많은 개발자가 오해하기 쉬운 전제를 분명히 못 박았다. 핫패치는 윈도우를 위한 기능이지 당신(애플리케이션 개발자)을 위한 기능이 아니라는 것이다.
설계 전제: 패처는 단 하나다
핫패치 설계의 핵심은 하나의 패처만을 가정한다는 데 있다. 의도된 사용자는 핫패치를 지원하는 시스템에서 동작하는 윈도우 업데이트다. 글에 따르면 현재 핫패치를 지원하는 환경은 윈도우 서버, 그리고 비교적 최근부터는 윈도우 11 엔터프라이즈 정도다. 관리자가 핫패치를 활성화했고, 업데이트에 포함된 파일이 '핫패치 안전(safe for hot-patching)'으로 표시되어 있을 때, 윈도우 업데이트는 미리 예약된 공간을 이용해 영향받는 함수를 즉석에서 교체한다.
이 공간을 사용할 권한이 윈도우 업데이트에만 있다는 점이 설계를 단순하게 만든다. 다른 누군가가 이미 함수를 핫패치해 두었을 가능성을 고려할 필요가 없기 때문이다. 애초에 그 '다른 누군가'가 될 자격을 가진 코드가 존재하지 않는다. 그래서 '이미 핫패치된 함수를 또 핫패치하려 하면 어떻게 되는가'라는 질문의 답은 간단하다. 그런 상황이 벌어졌다면 이미 무언가 잘못된 것이다.
무단 패치가 끼어들면 벌어지는 일
문제는 디투어(detour)나 그 밖의 방식으로 권한 없이 함수를 건드리는 코드가 실재한다는 데 있다. 첸이 핫패치 코드를 읽어본 바로는, 패치 과정에서 이런 비정상 패치가 감지되면 해당 파일을 핫패치 불가로 선언하고 시스템은 재부팅으로 넘어가게 된다. 재부팅은 고객을 불편하게 만드는 결과지만, 적어도 예측 가능한 실패다.
더 고약한 것은 경합 조건(race condition)이다. 사전 스캔에서는 모든 함수가 패치해도 안전하다고 나왔는데, 스캔이 끝난 직후 누군가가 그 함수를 패치해 버리는 경우다. 이때 패처는 작업을 절반쯤 진행한 뒤에야 무단 패치된 함수를 발견한다. 앞으로 나아갈 수도 없고, 안정적으로 되돌릴 수도 없다. 롤백 역시 이미 덧씌워진 패치 때문에 실패할 공산이 크기 때문이다. 결국 절반만 패치된 바이너리가 메모리에 남고, 그다음 무슨 일이 벌어질지는 아무도 장담할 수 없다. 첸은 이를 소방차 진입로에 주차한 차에 비유한다. 평소엔 아무 문제 없어 보이지만, 정작 불이 나 소방차가 도착했을 때 길이 막혀 집이 전소되는 상황이다.
핫패치가 만능이 아닌 이유
모든 변경이 핫패치 대상이 될 수 있는 것도 아니다. 예컨대 자료구조의 레이아웃이나 불변식(invariant)을 바꾸는 변경은 핫패치할 수 없다. 패치 이전에 생성된 기존 인스턴스들이 패치 이후에는 올바르지 않은 상태가 되어 버리기 때문이다. 이 제약은 무중단 갱신이 물리적으로 교체 가능한 코드 조각에만 적용되는, 본질적으로 제한된 기법임을 보여준다.
그렇다면 과거에 윈도우 업데이트가 이미 핫패치한 파일은 두 번 패치하지 못하는가 하는 의문이 남는다. 첸은 윈도우 업데이트가 자기 자신은 무리 없이 처리한다고 본다. 두 가지 방식을 떠올릴 수 있는데, 하나는 패치 이력을 확인해 스스로가 패처임을 알고 점프 대상(jump target)을 갱신하는 것이고, 다른 하나는 자신이 쓰는 형식인지(그리고 선택적으로 점프 대상이 예약 영역을 가리키는 그럴듯한 포인터인지) 확인한 뒤 점프 대상을 갱신하는 것이다. 참고로 글에는 '다른 모든 업데이트 설치가 재부팅을 요구한다'는 하드 요구사항이 존재한다는 언급도 있는데, 이 맥락에서 보면 그 제약이 자연스럽게 이해된다.
실무자가 가져갈 교훈
한국의 인프라·보안 엔지니어 입장에서 이 글이 주는 메시지는 분명하다. 핫패치용 예약 공간은 운영체제의 자산이지 애플리케이션이 성능 후킹이나 기능 주입을 위해 빌려 쓸 수 있는 땅이 아니다. 보안 제품, APM 에이전트, 각종 후킹 기반 솔루션이 흔히 쓰는 함수 디투어 기법은 평소엔 멀쩡히 돌아가다가도, 핫패치가 활성화된 서버에서 윈도우 업데이트가 내려오는 순간 핫패치 불가 판정에 따른 강제 재부팅이나 반쯤 패치된 바이너리라는 최악의 상태를 유발할 수 있다. 특히 윈도우 서버 환경에서 무중단 패치를 기대하면서 동시에 커널·사용자 모드 후킹 제품을 올려둔 조합이라면, 둘의 전제가 충돌한다는 점을 설계 단계에서 짚어야 한다.
첸은 머지않아 '밸류를 더한다'는 명목으로 다른 앱에 자신을 주입하려 핫패치 공간을 악용한 애플리케이션 탓에 발생한 크래시를 디버깅하는 글을 쓰게 될 것이라고 반쯤 농담조로 예고한다. 운영체제가 명시적으로 자기 전용이라고 선을 그은 자원에 올라타는 설계는, 지금 당장은 아무 문제가 없어 보여도 결국 추적하기 어려운 장애의 씨앗이 된다는 오래된 교훈을 다시 확인시켜 준다.