메모리 무결성(HVCI)을 끄면 빨라지는가 ── 의미와 절차와 판단

「메모리 무결성을 끄면 PC가 빨라진다」고 들어도, Windows 보안에 경고가 뜨면 바꿔도 되는지 망설이게 됩니다. 이 글에서는 「빨라질 수 있는가」와 「내 PC에서 꺼도 되는가」를 나누어 생각합니다.

대상은 Windows 보안의 「장치 보안」>「코어 격리」에 있는 「메모리 무결성」 토글입니다. 메모리 무결성은 드라이버를 통한 공격으로부터 Windows의 핵심을 지키는 기능이며, 단순히 성능을 낮추기 위한 설정이 아닙니다. 한편 Microsoft 자신도 게임용 장치의 일부 시나리오와 구성에서는 성능에 영향을 줄 수 있다고 안내합니다.¹

먼저 결론과 목적별 읽는 법을 제시하고, 그다음에 구조, 성능의 비교 방법, 판단 기준, 변경 전후의 확인, 끄는 절차와 되돌리는 방법을 설명합니다. 구조를 더 깊이 좇고 싶은 분은 연재 글 「Windows 가상화의 심층(제2회) ── 커널에서도 보이지 않는 메모리: VBS·HVCI·Credential Guard의 구조」를 참조하십시오. 이 글은 그 입구에 해당하는 입문편입니다.

이 글의 전제

1. 먼저 결론

끄면 빨라지는 구성은 있습니다. 다만 모든 PC가 빨라지는 것은 아니며, 성능 차이만으로 꺼도 된다고 정해지지도 않습니다.

메모리 무결성(HVCI)은 커널(OS의 핵심)에 로드되는 드라이버의 서명 검증을 하이퍼바이저가 만드는 격리 환경에서 수행합니다. 검증에 합격한 메모리 페이지만 실행 가능하게 하고, 실행 가능한 페이지에 쓰기를 허용하지 않음으로써 드라이버를 이용한 PC 탈취를 어렵게 만듭니다.²³

판단의 축은 「그 PC를 무엇에 쓰는가」입니다. 재어서 차이가 나고, 그 차이가 사용 방식에 영향을 주며, 오류에서 HVCI를 지목하는 안티치트 게임을 쓰지 않고, 사내 자산이나 중요한 정보를 다루지 않는 PC라면 끄는 것이 선택지에 들어갑니다. 그 밖에는 켠 채로 다른 원인을 찾는 편이 실무적입니다.

결론과, 필요한 곳으로의 안내

조작만 먼저 읽는 경우에도 5장의 판단 기준과 6장의 확인 방법을 먼저 파악하고 7장으로 나아가십시오. 끄는 조작은 짧아도 다시 시작과 확인까지가 한 세트입니다. 회색으로 조작할 수 없는 경우에는 관리자의 설정이나 UEFI 잠금을 직접 우회하지 마십시오.

그림의 실선은 항상 성립하는 관계, 점선은 조건이 붙는 관계입니다(성립 조건은 상세 페이지의 관계별 설명에 적혀 있습니다). 관계 전체 목록(총 28건, 근거와 확신도 포함)과 주요 개념의 정의는 지식 맵 상세 페이지에 정리되어 있습니다(일본어). 데이터: JSON-LD / Turtle

2. 먼저 섞이기 쉬운 4가지를 나눕니다

처음에 설정 화면의 이름과 뒤에서 동작하는 구조의 이름을 나누어 둡니다. 이번에 끄는 대상은 「메모리 무결성」이지, 아래 전부가 아닙니다.

2.1 메모리 무결성(HVCI)

Windows 보안의 「코어 격리」 화면에 있는 토글의 이름입니다. 정식으로는 「하이퍼바이저로 보호되는 코드 무결성(Hypervisor-protected Code Integrity, HVCI)」이라고 부르며, Microsoft의 문서에서는 「메모리 무결성」과 「HVCI」가 같은 것으로 다루어집니다.² 이 글에서 「끈다」고 말하는 것은 이것입니다.

2.2 코어 격리

Windows 보안 화면의 이름입니다. 「Windows의 코어 프로세스를 메모리 안에서 격리해 악의적인 소프트웨어로부터 보호하는」 보안 기능들을 한 화면에 모은 것으로, 메모리 무결성은 그중 1개의 토글입니다.³

화면에는 그 밖에도 커널 모드의 하드웨어 적용 스택 보호 등이 나열되는 경우가 있습니다. 「코어 격리를 끈다」는 표현을 자주 보지만, 화면 전체에 스위치는 없고 실제로 끄는 것은 메모리 무결성의 토글입니다.

2.3 가상화 기반 보안(VBS)

메모리 무결성의 토대가 되는 구조입니다. Windows의 하이퍼바이저를 써서 OS의 커널이 탈취되어도 보호되는 격리 환경을 만들고, 거기에 보안 기능을 담습니다.⁵

메모리 무결성은 VBS 위에 올라가는 기능의 하나이며, Credential Guard(도메인 자격 증명의 보호) 등도 여기에 올라갑니다. 메모리 무결성을 꺼도 VBS 자체가 멈춘다고는 할 수 없습니다(6장).

2.4 가상 머신 플랫폼(VMP)과 Hyper-V

「Windows 기능 켜기/끄기」에 있는 항목으로, WSL 2 같은 경량 가상 머신을 동작시키기 위한 토대입니다.⁶ Microsoft의 게임 성능에 관한 안내에서는 메모리 무결성과 나란히 이것도 성능 영향의 요인으로 꼽힙니다.¹ 메모리 무결성과는 별개의 토글이며 별개의 기능입니다.

참고로 Windows 샌드박스는 VMP가 아니라 「Windows 샌드박스」라는 전용 선택적 기능으로 켜는 것이며, VMP에 의존하지는 않지만 같은 Windows 하이퍼바이저 위에서 동작합니다.⁷

flowchart TB
    accTitle: 네 용어의 관계
    accDescr: Windows 하이퍼바이저 위에 가상화 기반 보안(VBS)과 가상 머신 플랫폼이 올라가고, VBS 위에 메모리 무결성과 Credential Guard가 올라가며, Windows 보안의 코어 격리 화면은 메모리 무결성의 토글을 표시한다는 포함 관계를 나타낸다
    hv["Windows 하이퍼바이저"]
    vbs["가상화 기반 보안(VBS)"]
    vmp["가상 머신 플랫폼"]
    hvci["메모리 무결성(HVCI)"]
    cg["Credential Guard 등"]
    ui["코어 격리 화면(토글을 표시)"]
    hv --> vbs
    hv --> vmp
    vbs --> hvci
    vbs --> cg
    ui -.->|"설정을 비춘다"| hvci

그림 1: 「코어 격리」는 화면의 이름, 「메모리 무결성」은 그 안의 토글, VBS는 그 토대, VMP는 같은 하이퍼바이저에 올라가는 별개의 기능이다.

즉, 「끄면 빨라진다」고 하는 것의 정체는 하이퍼바이저 위에 올라간 2개의 기능(메모리 무결성과 VMP)이고, 설정 화면의 토글은 그중 앞의 것만 끕니다.

3. 메모리 무결성은 무엇을 하고 있는가

이 장에서는 무엇을 지키는가 → 왜 성능에 영향을 주는가 → 내 PC에서는 처음부터 켜져 있는가의 순서로 정리합니다. 먼저 성능 차이의 전망을 알고 싶은 분은 4장의 표부터 읽을 수 있습니다.

3.1 드라이버의 검문소를 커널 밖으로 내보낸다

Windows에는 커널에 로드되는 드라이버가 올바르게 서명되어 있는지를 검사하는 구조(코드 무결성)가 원래 있습니다. 문제는 그 검사를 하는 코드도 커널 안에 있다는 점입니다. 커널을 탈취한 공격자는 검사 자체를 바꿔치기할 수 있습니다.

메모리 무결성은 이 검사를 VBS의 격리 환경 안에서 실행합니다.² 격리 환경은 하이퍼바이저가 지키고 있으므로 커널을 탈취해도 검사에는 손이 닿지 않습니다. 여기에 더해 다음 2가지 규칙을 커널의 메모리에 부과합니다.²

• 커널의 메모리 페이지는 검증에 합격하고 나서야 실행 가능해진다.
• 실행 가능한 페이지는 쓰기 가능이 되지 않는다.

flowchart TB
    accTitle: 메모리 무결성이 켜져 있을 때의 드라이버 로드
    accDescr: 드라이버의 로드 요청은 VBS의 격리 환경에서 서명 검증을 받고, 합격하면 실행 가능하며 쓰기 불가인 페이지로 허용되고, 불합격이면 로드가 차단되어 CodeIntegrity 운영 로그에 기록된다
    req["드라이버의 로드 요청"] --> chk{"격리 환경에서 서명을 검증"}
    chk -->|"합격"| ok["실행 가능·쓰기 불가로 허용"]
    chk -->|"불합격"| ng["로드를 차단"]
    ng --> log["CodeIntegrity 로그에 기록(3087)"]

그림 2: 검문소가 커널 밖에 있으므로 커널을 탈취해도 검문소는 바꿔치기할 수 없다.

이 규칙이 있으면 취약점을 찔러 커널의 메모리를 고쳐 써도 고쳐 쓴 내용을 실행으로 옮길 수 없습니다. 쓸 수 있는 페이지는 실행할 수 없고, 실행할 수 있는 페이지는 쓸 수 없기 때문입니다.² Windows 보안의 설명문에 있는 「악의적인 프로그램이 저수준 드라이버를 이용해 PC를 탈취하기 어렵게 한다」³는 이것을 가리킵니다.

3.2 왜 성능에 영향을 주는가

보호를 위한 처리에는 부하가 걸립니다. 여기에서는 하이퍼바이저를 쓰는 데 따른 부하와, 메모리 무결성이 실행 허가를 관리하는 부하를 나누어 생각합니다.

부하1: Windows 아래에서 하이퍼바이저가 동작한다

VBS는 하이퍼바이저를 전제로 하고, 하이퍼바이저는 SLAT(2단계 주소 변환)라는 CPU 기능을 필수로 합니다.⁵ 호스트의 Windows 자신이 하이퍼바이저 위의 파티션으로 동작하므로 메모리 주소의 변환이 2단계가 되고 그만큼의 부하가 걸립니다. 이 구조는 「지금 쓰는 Windows는 어디에서 실행되는가」에서 자세히 다룹니다.

부하2: 커널의 메모리를 실행해도 되는지 관리한다

메모리 무결성은 「검증에 합격한 페이지만 실행 가능」이라는 규칙을 커널 자신이 아니라 하이퍼바이저의 메모리 보호로 강제합니다. 이 처리에서 CPU의 세대 차이가 작용합니다.

Microsoft의 문서는 메모리 무결성이 Intel의 Kaby Lake(7세대) 이후의 Mode-Based Execution Control(MBEC) 이나 AMD의 Zen 2 이후의 Guest Mode Execute Trap(GMET) 을 가진 프로세서에서 더 잘 동작한다고 설명합니다. 그보다 오래된 프로세서에서는 Restricted User Mode라고 불리는 에뮬레이션에 의존하므로 성능에 대한 영향이 더 커집니다.⁸

MBEC는 메모리의 실행 허가를 「사용자 모드에서 실행해도 되는가」와 「커널 모드에서 실행해도 되는가」로 나누어 하드웨어로 구별할 수 있게 하는 기능입니다.⁹ 메모리 무결성은 커널 모드의 실행만 묶고 싶으므로, 이 구별이 있으면 CPU에 맡길 수 있습니다. 없으면 하이퍼바이저가 소프트웨어로 대신합니다.

flowchart TB
    accTitle: 성능 비용이 발생하는 두 곳
    accDescr: 메모리 무결성의 성능 비용은 하이퍼바이저가 아래에 들어오면서 생기는 2단계 주소 변환과, 커널 페이지의 실행 허가를 하이퍼바이저 쪽에서 강제하는 두 곳에서 발생하며, 후자는 MBEC/GMET의 유무에 따라 크기가 달라진다
    hvci["메모리 무결성이 켜짐"] --> c1["하이퍼바이저가 OS 아래에 들어온다"]
    hvci --> c2["실행 허가를 하이퍼바이저가 강제"]
    c1 --> t1["주소 변환이 2단계가 된다"]
    c2 --> q{"CPU에 MBEC / GMET는 있는가?"}
    q -->|"있다"| small["하드웨어가 처리(영향은 작은 편)"]
    q -->|"없다"| big["에뮬레이션(영향이 크다)"]

그림 3: 「끄면 빨라진다」의 크기는 주로 오른쪽 분기에서 정해진다.

자신의 CPU에 MBEC/GMET가 있는지는 6장에서 소개하는 Win32_DeviceGuard의 AvailableSecurityProperties에 7이 포함되는지로 알 수 있습니다.⁸

3.3 애초에 내 PC에서 동작하고 있는가

성능 비교로 나아가기 전에 하나 더 확인이 필요합니다. Windows 11이라고 해서 메모리 무결성이 반드시 동작하고 있는 것은 아닙니다.

메모리 무결성은 Windows 11을 지원 하드웨어에 클린 설치했을 때 기본으로 켜지는 기능이며, Windows 10에서의 업그레이드에서는 자동으로 켜지지 않습니다.⁴ 자동 활성화의 조건은 다음과 같습니다.⁴

즉, Windows 10에서 업그레이드해 그대로 쓰고 있는 PC, 조건을 충족하지 못하는 PC, 호환되지 않는 드라이버가 하나라도 있었던 PC에서는 원래 꺼져 있는 경우가 있습니다. 그 상태에서 「껐더니 빨라졌다」고 느꼈다면 그것은 다른 요인입니다. 먼저 6장의 방법으로 현재 상태를 확인하십시오.

flowchart TB
    accTitle: 메모리 무결성이 기본으로 켜지는 조건
    accDescr: Windows 11의 클린 설치에서 CPU 세대·8GB 이상의 메모리·64GB 이상의 SSD·지원 드라이버·펌웨어의 가상화 활성이라는 조건을 모두 충족하면 기본으로 켜지고, 업그레이드나 조건 미달에서는 켜지지 않는다
    start["Windows 11을 도입"] --> how{"클린 설치인가?"}
    how -->|"업그레이드"| off1["자동으로는 켜지지 않는다"]
    how -->|"예"| cond{"CPU·RAM·SSD·드라이버의 조건"}
    cond -->|"충족"| on["기본으로 켜짐"]
    cond -->|"미충족"| off2["켜지지 않는다(수동으로 가능)"]

그림 4: 「우리 PC는 처음부터 꺼져 있었다」는 드물지 않다. 시험하기 전에 현재 상태를 본다.

4. 정말 빨라지는가 ── 판단의 재료

이 장의 요점은 성능에 영향을 줄 가능성은 있지만 몇 % 빨라지는지를 일률적으로 말할 수 없다는 것입니다. 공식 설명, 구성별 전망, 자신의 PC에서의 측정을 나누어 읽습니다.

4.1 Microsoft가 말하는 것

Microsoft의 지원 문서 「Options to optimize gaming performance in Windows 11」은 Windows 11이 메모리 무결성(HVCI)과 가상 머신 플랫폼(VMP)을 위해 가상화를 쓰고 있다는 점, 그리고 게임용 장치의 일부 시나리오와 일부 구성에서는 메모리 무결성과 VMP가 켜져 있음으로 인한 성능 영향이 있을 수 있다는 점을 서술하고, 각각을 끄는 절차를 안내합니다.¹

즉 「빨라질 수 있다」는 Microsoft 공식의 견해입니다. 다만 「일부 시나리오와 일부 구성에서는」이라는 한정이 붙어 있고, 얼마나 빨라지는지의 숫자는 제시되어 있지 않습니다.

4.2 차이가 나기 쉬운 조건, 나기 어려운 조건

3.2의 구조에서 말할 수 있는 것을 상황별로 정리합니다. 여기에 쓰는 「전망」은 구조에서 온 경향이며 Microsoft가 공표한 측정값이 아닙니다. 자신의 PC에서 어떤지는 4.3의 방법으로 재십시오.

flowchart TB
    accTitle: 끄면 빨라지는지의 판단 흐름
    accDescr: 먼저 메모리 무결성이 현재 동작하고 있는지 확인하고, 동작하지 않으면 다른 원인을 찾으며, 동작한다면 CPU에 MBEC/GMET가 있는지와 병목이 CPU인지로 전망을 나누고, 마지막은 같은 조건으로 재어 판단한다
    s["체감으로 느리다"] --> run{"메모리 무결성은 동작 중인가?"}
    run -->|"아니오"| other["다른 원인을 찾는다"]
    run -->|"예"| cpu{"CPU에 MBEC / GMET가 있는가?"}
    cpu -->|"없다"| likely["차이가 나기 쉽다"]
    cpu -->|"있다"| bn{"병목은 CPU인가?"}
    bn -->|"예"| maybe["차이가 날 때가 있다"]
    bn -->|"아니오(GPU 등)"| small["차이는 작을 전망"]
    likely --> measure["같은 조건으로 재어 판단"]
    maybe --> measure
    small --> measure

그림 5: 「빨라지는가」는 PC의 구성으로 정해진다. 마지막에 작용하는 것은 구조의 지식이 아니라 자신의 PC에서의 측정이다.

4.3 체감이 아니라 잰다

「껐더니 빨라진 것 같다」만으로는 설정의 효과를 판단할 수 없습니다. 설정을 바꾸기 위해 다시 시작했으므로 그것만으로도 일시적으로 가벼워지기 때문입니다.

실제로 설정을 바꾸기 전에 5장에서 꺼도 되는 PC인지 확인하십시오. 그런 뒤에 비교하는 경우에는 다음 주의점을 파악하십시오. 측정의 순서는 그림 6과 같이 「켜짐을 확인하고 잰다 → 끄고 다시 시작한다 → 꺼짐을 확인하고 같은 조건으로 잰다」입니다. 확인 방법은 6장, 설정의 변경 방법은 7장입니다.

측정 시 파악할 상태와 조건

• 상태가 정말로 바뀌었음을 확인한다. 끄고 다시 시작한 뒤, 6장의 방법으로 「실행 중인 서비스」에서 메모리 무결성이 사라졌음을 확인합니다. 이것을 하지 않고 재면 켜짐끼리 비교하고 있을 수 있습니다.
• 조건을 맞춘다. AC 연결인지 배터리인지, 전원 모드, 백그라운드에서 도는 것, 게임이라면 같은 장면·같은 화질 설정. 비교 조건을 맞추는 법은 「Windows에서 프로그램 버전별 속도를 올바르게 비교하는 방법」에 정리해 두었습니다.

여러 번 재고, 사용 방식에 영향을 주는 차이인지를 본다

게임 내장 벤치마크나 정해진 처리에 걸리는 시간 등 숫자로 나오는 것을 씁니다. 켬과 끔에서 각 3회 정도 재고 중앙값을 비교하십시오.

볼 것은 숫자가 늘었는지만이 아닙니다. 평균 fps가 2% 올라도 화면에서는 구별할 수 없습니다. 최저 fps(끊김)가 개선되었는지가 체감에는 더 크게 작용합니다. 차이가 「사용 방식에 영향을 주는」 크기인지를 확인합니다.

flowchart TB
    accTitle: 켬·끔의 비교 절차
    accDescr: 현재 상태를 확인해 조건을 고정하고, 같은 계측을 여러 번 수행하며, 설정을 바꿔 다시 시작하고, 상태가 바뀌었음을 확인한 뒤 같은 계측을 반복해, 차이의 크기가 사용 방식에 영향을 주는지로 판단한다
    a["현재 상태를 확인(6장)"] --> b["조건을 고정해 3회 잰다"]
    b --> c["설정을 바꿔 다시 시작"]
    c --> d["상태가 바뀌었음을 확인"]
    d --> e["같은 조건으로 3회 잰다"]
    e --> f{"차이는 사용 방식에 영향을 주는 크기인가?"}
    f -->|"예"| g["5장의 판단으로"]
    f -->|"아니오"| h["다시 켜고 다른 원인을 찾는다"]

그림 6: 다시 시작 직후의 가벼움과 설정의 효과를 혼동하지 않는다. 상태의 확인이 측정의 전제이다.

차이가 나지 않았다면 다른 원인을 찾는다

차이가 나지 않았다면 느림의 원인은 다른 데 있습니다. PC 전체가 무거운 경우의 조사법은 「WPR/WPA 실무 ── 「PC 전체가 느리다」를 시스템 전체에서 조사하는 성능 조사 입문」을, 작업 관리자의 효율 모드가 원인일지 모르는 경우에는 「Windows 효율 모드란 - 녹색 잎 아이콘과 끄는 방법」을 참조하십시오.

5. 꺼도 되는가 ── 무엇을 잃는가

「빨라진다」와 「꺼도 된다」는 별개의 판단입니다. 재어서 차이가 났더라도 그것만으로 끌 이유가 되지는 않습니다. 잃는 보호와 그 PC의 용도를 견주어 봅니다.

5.1 잃는 것

주의할 것은 보호가 약해지는 것, 경고가 뜨는 것, 쓸 수 없게 되는 소프트웨어가 있는 것의 3가지입니다.

커널로의 코드 주입에 대한 방벽이 벗겨진다

취약점이 있는 드라이버나 서명이 없는 드라이버를 통해 커널을 탈취하는 공격을 메모리 무결성은 어렵게 만듭니다.² 끄면 그 공격에 대해서는 종전대로의 Windows가 됩니다.

Windows 보안에 경고가 뜬다

Windows 11 22H2 이후, 메모리 무결성이 꺼져 있으면 Windows 보안에 경고가 표시되고, 작업 표시줄의 아이콘과 알림 센터에도 경고 표시가 붙습니다. 경고는 Windows 보안의 화면에서 닫을 수 있습니다.⁸

HVCI를 요구하는 게임이 실행되지 않게 되는 경우가 있다

일부 안티치트(Riot Games의 Vanguard 등)는 Windows 11에서 HVCI(메모리 무결성)를 시스템 무결성의 검증에 쓰고 있습니다.

Riot의 지원 문서에서는 VAN: RESTRICTION 오류에 열거된 보안 기능(TPM 2.0, 보안 부팅, 메모리 무결성, IOMMU 중 하나)을 각각 활성화하도록 안내합니다. 오류에서 HVCI가 지목된 PC에서는 켜지 않으면 게임이 실행되지 않습니다.¹⁰

모든 PC에 일률적으로 부과되는 조건은 아니지만, 「빠르게 하고 싶은 게임」을 위해 껐더니 다른 게임이 실행되지 않게 되는 경우가 있습니다.

flowchart TB
    accTitle: 메모리 무결성을 끄면 잃는 것
    accDescr: 메모리 무결성을 끄면 커널로의 코드 주입에 대한 방벽이 벗겨지고, Windows 11 22H2 이후에는 Windows 보안이 계속 경고를 내며, 오류에서 HVCI를 지목하는 안티치트 게임은 실행되지 않게 된다
    off["메모리 무결성을 끔"] --> l1["커널로의 코드 주입의 방벽이 벗겨진다"]
    off --> l2["Windows 보안이 경고를 낸다"]
    off --> l3["HVCI를 지목하는 게임이 멈춘다"]

그림 7: 잃는 것은 3가지. 속도의 차이와 균형이 맞는지는 이 3가지를 보고 나서 정한다.

5.2 판단의 기준

flowchart TB
    accTitle: 꺼도 되는지의 판단
    accDescr: 업무 데이터나 사내 네트워크에 관계된 PC는 켠 채로, 오류에서 HVCI를 지목하는 안티치트 게임을 쓴다면 켠 채로, 재어서 차이가 난 전용기만이 끄는 후보가 되며, 그 밖에는 켠 채로 다른 원인을 찾는다
    q1{"업무 데이터·사내망에 관계되는가?"} -->|"예"| keep1["켠 채로(다른 원인을 찾는다)"]
    q1 -->|"아니오"| q2{"HVCI를 지목하는 게임을 쓰는가?"}
    q2 -->|"예"| keep2["켠 채로"]
    q2 -->|"아니오"| q3{"재어서 차이가 났는가?"}
    q3 -->|"예"| off["끄는 것이 선택지(용도가 바뀌면 되돌린다)"]
    q3 -->|"아니오"| keep3["켠 채로"]

그림 8: 끄기의 후보가 되는 것은 마지막 분기까지 나아간 PC뿐이다.

6. 꺼져 있는지를 확인한다

여기부터는 조작의 준비입니다. 확인 방법을 먼저 파악하고, 변경 전과 변경 후에 같은 방법을 씁니다. 토글을 본 것만으로 「켜져 있었다」「꺼졌다」고 판단하지 않는 것이 중요합니다.

6.1 토글의 표시는 「설정」이지 「동작 상태」가 아니다

Windows 보안의 「코어 격리」 화면의 토글은 설정의 값을 표시합니다. 활성화한 직후 다시 시작을 기다리는 동안이나, 부팅 시 호환성 문제로 메모리 무결성이 시작되지 못한 동안에도 토글은 켜진 것처럼 보일 수 있습니다. 동작 상태는 다음 둘 중 하나로 확인합니다.⁴

화면으로 확인한다: msinfo32(시스템 정보)

1. Win + R에서 msinfo32를 실행합니다.
2. 「시스템 요약」 아래쪽에 있는 「가상화 기반 보안」 항목을 봅니다.
3. 「실행 중인 서비스」에 「하이퍼바이저로 적용되는 코드 무결성」이 포함되어 있으면 메모리 무결성은 동작 중입니다.⁸

수치로 확인한다: PowerShell

관리자로 연 PowerShell에서 다음을 실행합니다.⁸

Get-CimInstance -Namespace root/Microsoft/Windows/DeviceGuard `
    -ClassName Win32_DeviceGuard |
    Select-Object VirtualizationBasedSecurityStatus,
                  SecurityServicesConfigured,
                  SecurityServicesRunning,
                  AvailableSecurityProperties

읽는 법은 다음과 같습니다.⁸

끄고 다시 시작한 뒤에는 SecurityServicesRunning에서 2가 사라졌으면 성공입니다. SecurityServicesConfigured에도 2가 없으면 설정으로도 꺼진 것입니다. VBS 전체의 상태와 메모리 무결성의 동작 상태는 나누어 읽습니다.

flowchart TB
    accTitle: 메모리 무결성 동작 확인의 흐름
    accDescr: Win32_DeviceGuard를 조회해 SecurityServicesRunning에 2가 포함되면 메모리 무결성은 동작 중이고, 포함되지 않으면 동작하지 않는다. 설정 쪽의 SecurityServicesConfigured에 2가 있는데 동작하지 않으면 다시 시작 대기나 부팅 시의 호환성 문제를 의심한다
    q0["Win32_DeviceGuard를 조회"] --> r{"SecurityServicesRunning에 2가 있는가?"}
    r -->|"포함"| on["메모리 무결성은 동작 중"]
    r -->|"미포함"| c{"Configured에는 2가 있는가?"}
    c -->|"있다"| wait["다시 시작 대기나 부팅 시의 호환성 문제"]
    c -->|"없다"| off["설정·동작 모두 꺼짐"]

그림 9: 볼 것은 Configured가 아니라 Running. 설정과 동작은 따로 읽는다.

6.2 꺼도 하이퍼바이저가 남는 구성

메모리 무결성만 멈춰도 토대가 멈춘다고는 할 수 없다

메모리 무결성은 VBS 위에 올라가는 기능의 하나입니다. 끈 것은 메모리 무결성뿐이며, VBS의 사용 여부는 별개의 설정(EnableVirtualizationBasedSecurity)으로 관리됩니다. Microsoft의 문서도 「VBS만 사용(메모리 무결성 없이)」이라는 구성을 명시합니다.⁸

게다가 Hyper-V, WSL 2, Windows 샌드박스, 가상 머신 플랫폼을 쓰고 있다면 하이퍼바이저는 그것들을 위해 계속 시작됩니다.⁶

3.2에서 본 2가지 비용 중 「하이퍼바이저가 OS 아래에 들어온다」 쪽은 이 경우 꺼도 남습니다. 메모리 무결성을 끄고도 msinfo32의 「가상화 기반 보안」이 「실행 중」인 채라면 토대는 남아 있습니다.

flowchart TB
    accTitle: 메모리 무결성을 꺼도 남는 것
    accDescr: 메모리 무결성의 토글을 꺼도, VBS의 활성화 설정, Hyper-V, WSL 2, Windows 샌드박스, 가상 머신 플랫폼 중 어느 하나가 켜져 있으면 하이퍼바이저는 계속 동작하고 2단계 주소 변환의 비용은 남는다
    off["메모리 무결성을 끔"] --> q{"달리 하이퍼바이저를 쓰는 것이 있는가?"}
    q -->|"VBS 설정·Credential Guard"| stay1["하이퍼바이저는 남는다"]
    q -->|"Hyper-V·WSL 2·샌드박스·VMP"| stay2["하이퍼바이저는 남는다"]
    q -->|"아무것도 없다"| gone["토대째 멈추는 경우가 있다"]
    stay1 --> cost["2단계 주소 변환의 비용은 남는다"]
    stay2 --> cost

그림 10: 토글이 끄는 것은 메모리 무결성뿐. 하이퍼바이저를 필요로 하는 다른 기능이 있으면 토대는 그대로 남는다.

토대째 멈추는 변경은 이 글의 대상이 아니다

VBS 자체를 사용하지 않게 하는 설정이나 하이퍼바이저를 시작하지 않는 구성도 존재하지만, Credential Guard를 포함한 VBS 위의 모든 기능과 Hyper-V·WSL 2·Windows 샌드박스를 쓸 수 없게 됩니다. 「메모리 무결성을 끈다」와는 다른, 훨씬 큰 변경입니다. 이 글에서는 그 절차를 다루지 않습니다. 구조를 이해한 뒤에 판단하고 싶다면 연재 제1회와 제2회를 읽고 나서 하십시오.

7. 끄는 절차

보통은 7.1의 Windows 보안 화면에서 조작합니다. 7.2는 조작할 수 없는 경우의 확인, 7.3은 화면을 쓸 수 없는 환경을 위한 대체 수단입니다. 7.4의 VMP는 별개의 기능이므로, 메모리 무결성을 끄기 위해 이어서 실시하는 절차가 아닙니다.

7.1 Windows 보안에서(표준 절차)

끈다: 설정 변경·다시 시작·확인까지 한다

1. 시작에서 「Windows 보안」을 엽니다.
2. 왼쪽 메뉴에서 「장치 보안」을 고릅니다.
3. 「코어 격리」 아래에 있는 「코어 격리 세부 정보」를 엽니다.
4. 「메모리 무결성」의 토글을 끔으로 합니다. 관리자 권한 확인(UAC)이 나오면 허용합니다.
5. PC를 다시 시작합니다. 다시 시작하기 전에는 변경이 반영되지 않습니다.¹
6. 다시 시작한 뒤 6.1의 방법으로 꺼졌음을 확인합니다.

다시 켠다: 같은 화면에서 조작한다

되돌릴 때는 같은 화면에서 토글을 켬으로 하고 다시 시작합니다. 켤 때는 호환되지 않는 드라이버의 검사가 들어가는 경우가 있습니다. 목록이 나오면 강제하지 말고 8장의 순서로 대처하십시오.

비교하는 경우에는 변경 전후의 동작 상태를 확인한 뒤 4.3의 방법으로 잽니다. 차이가 사용 방식에 영향을 주지 않으면 다시 켜고 다른 원인을 찾습니다.

flowchart TB
    accTitle: Windows 보안에서 메모리 무결성을 끄는 절차
    accDescr: Windows 보안의 장치 보안에서 코어 격리 세부 정보를 열고, 메모리 무결성의 토글을 끈 뒤 다시 시작하고, msinfo32나 Win32_DeviceGuard로 꺼졌음을 확인한다
    s1["Windows 보안을 연다"] --> s2["장치 보안"]
    s2 --> s3["코어 격리 세부 정보"]
    s3 --> s4["메모리 무결성을 끔"]
    s4 --> s5["다시 시작"]
    s5 --> s6["6장의 방법으로 확인"]

그림 11: 절차 자체는 짧다. 빠뜨리기 쉬운 것은 마지막 2가지(다시 시작과 확인)이다.

7.2 토글이 회색이라 만질 수 없을 때

회사나 학교의 PC라면 직접 우회하지 말고 관리자에게 문의하십시오. 회색이라 조작할 수 없는 경우에는 다음과 같은 이유가 있습니다.

정책이나 레지스트리로 고정되어 있다

토글이 회색이고 「이 설정은 관리자가 관리합니다」라고 표시되는 경우, 그 PC는 그룹 정책이나 Intune 등으로 설정이 고정되어 있거나 레지스트리로 화면이 비활성화되어 있습니다.⁸ 회사나 학교의 PC라면 이것은 관리자의 의도입니다.

UEFI 잠금과 함께 활성화되어 있다

그룹 정책의 「가상화 기반 보안 켜기」에서 「UEFI 잠금으로 사용」을 골라 배포된 PC는 설정이 UEFI(펌웨어)의 변수에 저장되므로, 원격이나 정책의 업데이트로는 메모리 무결성을 끌 수 없습니다.⁸

해제하려면 정책이나 레지스트리의 설정을 뗀 뒤, 그 PC 앞에 있는 사람이 UEFI에 저장된 구성을 지우는 절차가 필요합니다. 같은 UEFI 잠금을 쓰는 Credential Guard의 문서에서는 관리자 권한으로 bcdedit를 써서 EFI 변수를 삭제하고, 다시 시작할 때 표시되는 확인 프롬프트를 물리적으로 승인하는 절차가 제시되어 있습니다.¹¹

UEFI 메뉴에서 보안 부팅을 비활성화하는 것만으로는 저장된 구성이 지워지지 않습니다. BitLocker의 복구 키 입력을 부르는 경우도 있습니다. 이것은 「멋대로 꺼지지 않게 하기 위한」 설정이므로, 역시 관리자의 영역입니다.

flowchart TB
    accTitle: 토글이 회색일 때의 분리
    accDescr: 토글이 회색이면 관리자에 의한 관리(정책이나 레지스트리)이거나 UEFI 잠금(PC 앞에서 UEFI에 저장된 구성을 지우는 절차가 필요)이며, 어느 쪽이든 직접 우회하지 말고 관리자에게 문의한다
    gray["토글이 회색"] --> why{"표시된 이유는 무엇인가?"}
    why -->|"관리자가 관리"| pol["정책·레지스트리로 고정"]
    why -->|"UEFI 잠금"| lock["PC 앞에서 UEFI의 구성을 지우는 절차가 필요"]
    pol --> ask["관리자에게 문의한다"]
    lock --> ask

그림 12: 회색은 고장이 아니라 누군가가 의도해 고정한 표시이다.

7.3 레지스트리로 설정한다(화면을 쓸 수 없을 때)

이 방법은 Windows 보안의 화면을 쓸 수 없는 환경이나, 스크립트로 설정하고 싶은 경우의 대체 수단입니다. 관리자의 설정을 우회하는 방법이 아닙니다. 또한 다시 켤 때는 7.1의 화면을 씁니다.

끄기 위한 값과 명령

Microsoft가 문서화한 메모리 무결성의 사용·사용 안 함의 설정값은 다음과 같습니다.⁸

관리자로 연 터미널에서 다음을 실행하고 다시 시작합니다.

reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v Enabled /t REG_DWORD /d 0 /f

이는 Microsoft가 메모리 무결성을 켠 뒤 부팅되지 않게 된 PC를 복구 환경(Windows RE)에서 복구하는 절차로 안내하는 것과 같은 조작입니다.⁸

되돌릴 때 레지스트리에 1을 쓰지 않는 이유

되돌릴 때는 레지스트리에 1을 써넣지 말고, 7.1의 Windows 보안 화면에서 켜십시오. 화면에서 켤 때는 호환되지 않는 드라이버의 검사가 먼저 돌고, 해당이 있으면 목록이 표시됩니다(8장).³

레지스트리로 1을 쓰면 그 검사를 거치지 않고 다음 부팅에서 메모리 무결성이 요구됩니다. 호환되지 않는 드라이버가 남아 있으면 8장에서 경고하는 부팅 실패를 그대로 부릅니다. 정책이나 레지스트리로 켜도 되는 것은 호환되지 않는 드라이버의 목록과 CodeIntegrity 로그로 문제가 없음을 확인한 뒤에 한합니다.

고쳐 써도 듣지 않거나 되돌아가는 경우

같은 키의 Locked가 1(UEFI 잠금)로 되어 있는 PC에서는 이 값을 고쳐 써도 듣지 않습니다.⁸ 또한 조직의 정책으로 관리되는 PC에서는 다음 정책 적용 시에 설정이 되돌아갑니다. 레지스트리는 「화면의 대체」이지 「관리자의 설정을 덮어쓰는 수단」이 아닙니다.

flowchart TB
    accTitle: 레지스트리로 설정할 때 듣지 않는 조건
    accDescr: HypervisorEnforcedCodeIntegrity의 Enabled를 0으로 해도 같은 키의 Locked가 1(UEFI 잠금)이면 듣지 않고, 조직의 정책으로 관리되는 PC에서는 다음 정책 적용 시에 설정이 되돌아간다. 다시 켤 때는 레지스트리가 아니라 Windows 보안의 화면에서 한다
    reg["Enabled를 0으로 하고 다시 시작"] --> lk{"Locked는 1(UEFI 잠금)인가?"}
    lk -->|"예"| no1["듣지 않는다(UEFI 쪽의 해제가 필요)"]
    lk -->|"아니오"| pol{"정책으로 관리되는가?"}
    pol -->|"예"| no2["다음 적용 시에 되돌아간다"]
    pol -->|"아니오"| ok["꺼진다(6장에서 확인)"]
    ok -.-> back["되돌릴 때는 화면에서(검사가 들어간다)"]

그림 13: 레지스트리 값은 화면과 같은 설정을 쓰고 있을 뿐이며, 잠금과 정책 위에는 설 수 없다.

7.4 가상 머신 플랫폼(VMP)은 별개의 절차

Microsoft의 게임 성능 안내에서는 VMP도 꼽히지만, 이것은 메모리 무결성과는 별개의 기능입니다. 메모리 무결성을 끄기 위해 VMP도 떼어 낼 필요가 있는 것은 아닙니다.

떼기 전에 쓰고 있는 기능을 확인한다

VMP는 WSL 2의 전제 기능입니다.⁶ WSL 2나 WSL 2를 토대로 하는 Docker Desktop을 쓰는 PC에서 이것을 떼면 그것들이 동작하지 않게 됩니다.

Windows 샌드박스는 VMP가 아니라 전용 선택적 기능으로 활성화되므로 VMP를 떼어도 쓸 수 있습니다.⁷ 다만 샌드박스도 같은 하이퍼바이저 위에서 동작하므로, 계속 쓰는 한 6.2에서 본 「토대가 남는」 쪽의 요인이 됩니다.

판단 기준은 「쓰지 않는다면 뗀다」이지 「빨라지니까 뗀다」가 아닙니다.

VMP를 쓰지 않는 경우의 조작

VMP는 Windows 보안이 아니라 「Windows 기능」에서 끕니다.¹

1. 시작에서 「Windows 기능」을 검색해 「Windows 기능 켜기/끄기」를 엽니다.
2. 「가상 머신 플랫폼」의 체크를 해제하고 「확인」을 누릅니다.
3. 다시 시작합니다.

flowchart TB
    accTitle: 가상 머신 플랫폼을 떼어도 되는가
    accDescr: WSL 2나 Docker Desktop(WSL 2 백엔드) 등 가상 머신 플랫폼에 의존하는 기능을 쓰고 있다면 떼지 말고, 쓰지 않는 경우에만 떼기의 후보가 된다. Windows 샌드박스는 전용 기능이므로 VMP를 떼어도 동작하지만, 같은 하이퍼바이저를 쓰므로 토대는 남는다
    vmp["VMP를 떼고 싶다"] --> use{"WSL 2나 Docker Desktop을 쓰는가?"}
    use -->|"쓴다"| keep["떼지 않는다(동작하지 않게 된다)"]
    use -->|"쓰지 않는다"| ok["떼기의 후보(Windows 기능에서)"]
    ok --> reboot["다시 시작해 확인"]
    ok -.-> sb["샌드박스는 별개 기능(토대는 남는다)"]

그림 14: VMP를 떼는지는 속도가 아니라 「그 기능을 쓰는가」로 정한다.

8. 다시 켤 때 ── 「호환되지 않는 드라이버」에 대한 대처

이 장에서는 직접 다시 켤 수 없는 경우와, 자동으로 켜진 PC에서 어느새 꺼진 경우를 나눕니다. 둘 다 드라이버의 목록이나 로그로 확인하고 나서 대처합니다.

8.1 다시 켤 수 없을 때는 드라이버를 확인한다

꺼 두었던 PC에서 메모리 무결성을 다시 켜려고 하면 「호환되지 않는 드라이버」가 있다고 하며 켤 수 없는 경우가 있습니다. Windows 보안은 토글을 켤 때 드라이버를 검사하고, 메모리 무결성의 규칙(3.1)에 맞지 않는 드라이버가 있으면 목록을 표시합니다.³

대처의 순서는 다음과 같습니다.

1. 목록에서 대상을 확인한다. 「코어 격리」 화면의 「호환되지 않는 드라이버 확인」에서 드라이버의 파일 이름과 제공처를 봅니다.
2. 업데이트된 드라이버로 교체한다. Microsoft의 안내대로 장치의 제조사에 업데이트된 드라이버가 제공되고 있는지 확인합니다.³ Windows 업데이트의 「선택적 업데이트」에 와 있는 경우도 있습니다.
3. 쓰지 않는 기기의 드라이버라면 삭제한다. 예전에 연결했던 주변 기기, 제거하다 만 유틸리티의 드라이버가 남아 있는 경우가 흔합니다.
4. 어떤 드라이버가 차단되었는지를 로그로 확인한다. 이벤트 뷰어의 Applications and Services Logs\Microsoft\Windows\CodeIntegrity\Operational에 메모리 무결성에 의한 차단이 이벤트 ID 3087을 대표로 기록됩니다.⁴

호환되지 않는 드라이버가 남은 채로 강제로 켜는 일은 하지 마십시오. Microsoft는 메모리 무결성과 호환되지 않는 드라이버로 인해 장치나 소프트웨어가 오동작하고, 드물게는 부팅 실패(블루 스크린)에 이르는 경우가 있다고 경고합니다.⁸ 실제로 부팅되지 않게 된 경우에는 복구 환경에서 7.3의 레지스트리 값을 0으로 해 부팅을 복구하는 절차가 마련되어 있습니다.⁸

flowchart TB
    accTitle: 다시 켤 수 없을 때의 대처
    accDescr: 호환되지 않는 드라이버의 목록에서 대상을 특정하고, 제조사의 업데이트판이 있으면 교체하고, 쓰지 않는 기기라면 삭제하며, 어느 쪽도 안 되면 강제하지 말고 끈 채로 두고 제조사에 대응판을 요청한다
    fail["켤 수 없다"] --> list["호환되지 않는 드라이버 목록을 본다"]
    list --> upd{"제조사에 업데이트판이 있는가?"}
    upd -->|"있다"| fix["교체해 켠다"]
    upd -->|"없다"| used{"그 기기를 쓰고 있는가?"}
    used -->|"쓰지 않는다"| rm["드라이버를 삭제해 켠다"]
    used -->|"쓰고 있다"| wait["강제하지 말고 제조사에 요청"]

그림 15: 본길은 드라이버의 업데이트. 강제로 켜는 것은 부팅되지 않게 되는 대가에 걸맞지 않는다.

8.2 자동으로 꺼지는 안전장치에는 조건이 있다

자동으로 켜진 PC에 한한 구조

Windows가 메모리 무결성을 자동으로 켠 PC(3.3의 기본 활성화나, 제조사가 출하 이미지에서 켠 PC)에는, 활성화 직후에 부팅 시의 크래시가 일어나면 메모리 무결성을 자동으로 끄는 안전장치가 들어 있는 경우가 있습니다.

Microsoft의 문서에서는 이 안전장치가 레지스트리의 WasEnabledBy와 EnabledBootId가 설정된 경우에 작동하며, 활성화로부터 3회의 부팅 동안만 유효하고, 제조사가 출하 이미지에 설정하는 구성으로 설명되어 있습니다.⁴

코어 격리 화면에서 직접 켠 경우에 대해서는 이 동작이 문서화되어 있지 않습니다. 수동으로 다시 켤 때는 이 안전장치에 의존하지 말고, 8.1의 절차로 호환되지 않는 드라이버를 먼저 정리하십시오.

자동으로 꺼졌다고 해서 원인이 확정된 것은 아니다

「클린 설치 직후에 어느새 꺼져 있었다」는 현상은 이 안전장치가 작동한 결과인 경우가 있습니다. 다만 기록하고 있는 것은 「활성화 직후에 부팅에 실패했다」는 사실뿐입니다. 원인이 호환되지 않는 드라이버라고 확정된 것은 아닙니다. 그 기간에 무관한 원인으로 부팅에 실패해도 같은 결과가 됩니다.

Microsoft의 문서도 메모리 무결성을 꺼도 부팅 실패가 계속되는 경우에는 메모리 무결성이 원인이 아니었다고 보고 설정을 원래대로 되돌리는 동작이 있다고 설명합니다.⁴

호환되지 않는 드라이버가 원인일 가능성은 높으므로, 먼저 「호환되지 않는 드라이버」의 목록과 CodeIntegrity 로그로 뒷받침을 얻습니다. 해당이 있으면 8.1의 절차로 대처하고, 해당이 없으면 부팅 실패의 원인을 따로 조사하십시오.

flowchart TB
    accTitle: 자동으로 켜진 PC에서 자동으로 꺼지는 안전장치
    accDescr: Windows가 자동으로 켠(WasEnabledBy와 EnabledBootId가 설정된) PC에서는 활성화로부터 3회의 부팅 안에 부팅 시 크래시가 일어나면 메모리 무결성이 자동으로 꺼지는 경우가 있다. 수동으로 켠 경우에는 이 동작이 문서화되어 있지 않으므로 안전장치에 의존하지 않는다. 자동으로 꺼진 경우도 부팅 실패의 기록이지 원인의 확정이 아니므로, 호환되지 않는 드라이버의 목록과 CodeIntegrity 로그로 뒷받침을 얻고, 해당이 있으면 업데이트나 삭제로 대처하고 없으면 다른 원인을 조사한다
    en["메모리 무결성이 켜진다"] --> how{"자동 활성화(WasEnabledBy)인가?"}
    how -->|"수동으로 켬"| manual["안전장치는 문서화되어 있지 않다"]
    how -->|"자동"| boot{"3회 이내의 부팅에서 크래시했는가?"}
    boot -->|"하지 않았다"| fine["켜진 채로 동작"]
    boot -->|"했다"| auto["자동으로 꺼진다"]
    auto --> chk{"목록이나 로그에 해당은?"}
    chk -->|"있다"| fix["업데이트나 삭제로 대처"]
    chk -->|"없다"| other["다른 원인을 조사"]

그림 16: 안전장치가 작동하는 것은 자동으로 켜진 PC뿐이며, 수동으로 켠 경우에는 기댈 수 없다. 작동한 경우에도 그것은 신호이지 진단이 아니므로, 목록과 로그로 뒷받침을 얻고 나서 고친다.

9. 흔한 오해

마지막으로 설정을 바꾸기 전후에 혼동하기 쉬운 점을 확인합니다.

9.1 「코어 격리를 껐다」

코어 격리는 화면의 이름이고, 실제로 끈 것은 메모리 무결성의 토글입니다(2장). 같은 화면에 있는 다른 항목이나 VBS 자체는 꺼지지 않았습니다.

9.2 「끄면 반드시 빨라진다」

빨라질 수 있는 것은 메모리 무결성이 실제로 동작하고 있고, CPU 쪽이 병목이며, 특히 CPU가 MBEC/GMET를 갖지 않은 경우입니다(4장). GPU 율속인 게임이나 원인이 다른 데 있는 느림은 달라지지 않습니다.

9.3 「토글을 끈 시점에서 끝」

다시 시작하기 전에는 반영되지 않고, 다시 시작한 뒤에도 동작 상태를 따로 확인해야 합니다(6장). 반대로 정책이나 UEFI 잠금으로 고정된 PC에서는 토글을 만져도 되돌아갑니다.

9.4 「꺼도 다른 영향은 없다」

커널로의 코드 주입에 대한 방벽이 벗겨지고, Windows 보안이 계속 경고를 내며, 오류에서 HVCI를 지목하는 안티치트 게임은 실행되지 않게 됩니다(5장).

9.5 「끄면 하이퍼바이저도 멈춘다」

메모리 무결성은 VBS 위의 한 기능이며, VBS의 설정, Credential Guard, Hyper-V, WSL 2, Windows 샌드박스, VMP 중 어느 하나가 켜져 있으면 하이퍼바이저는 계속 동작합니다(6.2).

flowchart TB
    accTitle: 오해와 실제의 대응표
    accDescr: 코어 격리를 껐다는 오해는 실제로는 메모리 무결성의 토글이라는 것, 반드시 빨라진다는 오해는 구성에 달렸다는 것, 토글로 끝이라는 오해는 다시 시작과 확인이 필요하다는 것, 하이퍼바이저도 멈춘다는 오해는 다른 기능이 있으면 남는다는 것에 대응한다
    m1["코어 격리를 껐다"] --> r1["끈 것은 메모리 무결성의 토글"]
    m2["반드시 빨라진다"] --> r2["구성에 달렸다. 재어서 판단"]
    m3["토글로 끝"] --> r3["다시 시작과 동작 확인이 필요"]
    m4["하이퍼바이저도 멈춘다"] --> r4["다른 기능이 있으면 남는다"]

그림 17: 오해의 대부분은 「화면의 이름」과 「구조의 이름」을 섞은 데서 생긴다.

10. 정리

메모리 무결성(HVCI)은 커널에 들어오는 드라이버의 검문소를 커널 밖의 격리 환경으로 이사시킨 구조입니다. 그 이사에는 하이퍼바이저를 아래에 까는 것, 실행 허가를 하이퍼바이저가 강제하는 것이라는 대가가 있고, 구성에 따라서는 성능에 영향을 줍니다.

판단은 다음 3단계로 생각하면 정리됩니다.

1. 용도와 잃는 것을 확인한다. 끄기의 후보는 업무 데이터나 사내 네트워크에 관계되지 않고 HVCI를 지목하는 안티치트 게임을 쓰지 않는 전용기입니다. 속도만으로 정하지 않습니다.
2. 동작 상태를 확인하고 나서 같은 조건으로 잰다. msinfo32나 Win32_DeviceGuard를 쓰고, 변경 전후에 상태가 바뀌었음을 확인합니다. 차이가 나기 쉬운 것은 MBEC/GMET가 없는 오래된 CPU와 CPU 율속인 게임이고, GPU 율속인 게임이나 일상 용도에서는 나기 어렵습니다. 여러 번 재고 그 차이가 사용 방식에 영향을 주는지를 봅니다.
3. 차이와 용도에 따라 유지할지 되돌릴지 정한다. 끄기는 재어서 차이가 난 경우의 선택지입니다. Hyper-V·WSL 2·샌드박스·VMP를 쓰는 PC에서는 토대가 남아 기대한 차이는 나기 어렵습니다. 차이가 사용 방식에 영향을 주지 않으면 다시 켜고, 용도가 바뀌었을 때에도 재검토합니다. 다시 켤 수 없을 때의 본길은 드라이버의 업데이트이며 강제로 켜지 않습니다.

「끄면 빨라진다」는 거짓말이 아닙니다. 다만 「내 PC에서」「재어 보고」「잃는 것을 알고 나서」라는 3가지 조건을 붙여야 비로소 판단의 재료가 됩니다.

관련 글

• Windows 가상화의 심층(제2회) ── 커널에서도 보이지 않는 메모리: VBS·HVCI·Credential Guard의 구조
• Windows 가상화의 심층(제1회) ── 지금 쓰는 Windows는 어디에서 실행되는가: 하이퍼바이저와 파티션
• Windows 가상화의 심층(제3회) ── 수초 만에 시작되는 가상 머신: WSL2·Windows Sandbox·컨테이너
• Windows 효율 모드란 - 녹색 잎 아이콘과 끄는 방법
• Windows에서 프로그램 버전별 속도를 올바르게 비교하는 방법. 전원 모드 등 환경을 맞추는 법부터 한계까지
• WPR/WPA 실무 ── 「PC 전체가 느리다」를 시스템 전체에서 조사하는 성능 조사 입문
• Windows의 프로세서 스케줄 설정 - 백그라운드 서비스와 P/E 코어

관련된 상담 영역

합동회사 코무라소프트에서는 Windows 애플리케이션과 보안 기능(메모리 무결성·VBS·App Control)의 호환성 조사, 드라이버에서 비롯된 결함 분석, 「PC나 앱이 느리다」의 원인을 측정으로 분리하는 성능 조사를 다룹니다. 「꺼도 빨라지지 않았다」의 다음부터 상담해 주십시오.

• 결함 조사·원인 분석
• 기술 상담·설계 리뷰
• Windows 앱 개발
• 문의하기

참고 링크

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

자주 묻는 질문

이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.

메모리 무결성(HVCI)이란 무엇입니까?

Windows 보안의 「장치 보안」>「코어 격리」에 있는 기능으로, 정식으로는 「하이퍼바이저로 보호되는 코드 무결성(HVCI)」이라고 부릅니다. 커널(OS의 핵심)에 로드되는 드라이버의 서명 검증을 하이퍼바이저가 만드는 격리 환경 안에서 수행하고, 검증에 합격한 페이지만 실행 가능하게 하며, 실행 가능한 페이지에는 쓰기를 허용하지 않습니다. 악의적인 프로그램이 저수준 드라이버를 이용해 PC를 탈취하기 어렵게 만들기 위한 기능입니다.

메모리 무결성을 끄면 정말 빨라집니까?

빨라지는 구성도 있고 거의 달라지지 않는 구성도 있습니다. Microsoft는 게임용 장치의 일부 시나리오와 구성에서 메모리 무결성과 가상 머신 플랫폼에 의한 성능 영향이 있을 수 있다고 안내합니다. 영향이 나타나기 쉬운 것은 Mode-Based Execution Control(Intel에서는 7세대 이후에 탑재)이나 Guest Mode Execute Trap(AMD에서는 Zen 2 이후에 탑재)을 갖지 않은 오래된 CPU이며, 이 경우에는 에뮬레이션으로 대체되므로 성능 영향이 커집니다. 한편 GPU가 병목인 게임이나, 느림의 원인이 메모리 부족·디스크·발열·전원 모드에 있는 경우에는 꺼도 달라지지 않습니다. 자신의 PC에서 같은 조건으로 재어 보고 판단하는 것이 확실합니다.

메모리 무결성을 끄는 절차를 알려 주십시오.

Windows 보안을 열고 「장치 보안」>「코어 격리 세부 정보」에서 「메모리 무결성」의 토글을 끈 뒤 PC를 다시 시작합니다. 다시 시작하기 전에는 설정이 반영되지 않습니다. 토글이 회색이고 「이 설정은 관리자가 관리합니다」라고 나오는 경우에는 조직의 정책으로 고정된 것이므로, 직접 바꾸지 말고 관리자에게 문의하십시오.

껐는데도 빨라지지 않는 이유는 무엇입니까?

먼저 정말로 꺼졌는지를 msinfo32(시스템 정보)의 「가상화 기반 보안」 항목이나 PowerShell의 Win32_DeviceGuard 클래스에서 확인하십시오. 다시 시작하지 않았다, 정책으로 되돌려졌다 같은 이유로 켜진 채인 경우가 있습니다. 다음으로 Hyper-V·WSL 2·Windows 샌드박스·가상 머신 플랫폼을 쓰고 있다면, 메모리 무결성을 꺼도 하이퍼바이저 자체는 계속 동작합니다. 그리고 애초에 느림의 원인이 메모리 무결성이 아니라면 꺼도 빨라지지 않습니다.

메모리 무결성을 다시 켤 수 없을 때(호환되지 않는 드라이버가 있다고 나올 때)는 어떻게 해야 합니까?

Windows 보안의 「코어 격리」 화면에 표시되는 호환되지 않는 드라이버 목록에서 대상을 확인하고, 장치 제조사가 제공하는 업데이트된 드라이버로 교체하는 것이 본길입니다. 쓰지 않는 기기의 드라이버라면 삭제해도 괜찮습니다. 어떤 드라이버가 차단되었는지는 이벤트 뷰어의 CodeIntegrity 운영 로그(이벤트 ID 3087이 대표)에서도 확인할 수 있습니다. 호환되지 않는 드라이버가 남은 채로 강제로 켜는 것은 Microsoft도 지원하지 않으며, 부팅되지 않게 되는 경우가 있습니다.

게임 때문에 껐더니 다른 게임이 실행되지 않게 되었습니다.

일부 안티치트(Riot Games의 Vanguard 등)는 Windows 11에서 메모리 무결성(HVCI)을 시스템 무결성의 검증에 사용하고 있으며, VAN: RESTRICTION 오류에서 HVCI가 지목된 PC에서는 켜지 않으면 게임이 실행되지 않습니다. 모든 Windows 11 PC에 일률적으로 요구되는 것은 아니고, 오류에 무엇이 열거되어 있는지에 따라 정해집니다. 해당한다면 메모리 무결성을 다시 켜고 다시 시작해야 합니다. 끌지 말지는 「빠르게 하고 싶은 게임」과 「HVCI를 요구하는 게임」 양쪽을 보고 정하십시오.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.