diff --git a/docs/WINDOWS-TESTING.md b/docs/WINDOWS-TESTING.md
index ecd5756..566fa29 100644
--- a/docs/WINDOWS-TESTING.md
+++ b/docs/WINDOWS-TESTING.md
@@ -160,26 +160,81 @@ RAM 8GB 는 Windows 11 이 쾌적하게 도는 최소선이고, 그 안에서 
 음성인식+번역이 2~3GB 를 씁니다. 디스크 80GB 는 Windows 30GB + 모델 캐시
 + 빌드 산출물 기준입니다.
 
-#### 호스트를 증설해야 하나 — 거의 필요 없습니다
+#### VM 의 Windows 는 진짜 Windows 인가
 
-물리 호스트는 **i7-11700(8코어/16스레드), RAM 62.6GB** 입니다.
-`.9` 는 그중 8 vCPU / 30GB 를 쓰고 있습니다.
+**맞습니다. 같은 Windows 이고 같은 바이너리입니다.** 우리가 검증하려는 것들은
+코드 경로가 동일합니다.
+
+| | VM 에서 | 비고 |
+|---|---|---|
+| WASAPI 오디오 캡처 API | 동일 | 에뮬레이트된 사운드 장치를 잡을 뿐 API 는 같음 |
+| 전역 단축키(`RegisterHotKey`) | 동일 | |
+| 모니터 열거 API | 동일 | `max_outputs=2` 로 화면 2개를 줄 수 있음 |
+| PyInstaller exe 빌드·실행 | 동일 | |
+| CPU 명령어 집합 | 동일 | 중첩 KVM 이 호스트 CPU 기능을 그대로 노출 |
+
+다른 점은 셋입니다.
+
+- **GPU 없음** — CUDA·VRAM 검증은 `.9`(리눅스)에서 합니다. 위 참고.
+- **실제 게임 소리 없음** — 게임을 띄워 진짜 캡처하는 건 못 합니다.
+  대신 음성 파일을 넣어 자막까지 나오는지 자동 검증합니다.
+- **속도/지연이 다름** — 체감 지연 측정값은 실제 PC 기준이 아닙니다.
+
+모니터 선택을 검증하려면 화면을 2개 줘야 합니다. `--vga std` 는 1개뿐입니다.
 
 ```
-.9 실측    ejclaw 최대 7.2GB (상한은 16GB) + VM 8GB = 15.2GB / 30GB
-           코어는 4개에서 포화 -> 8개면 VM 4 + 봇 4 로 충분
+-device virtio-vga,max_outputs=2      # KVM 기동 확인 완료
 ```
 
-**그대로 두셔도 됩니다.** 굳이 여유를 두고 싶다면 아래 정도가 상한입니다.
+Windows 쪽에 virtio-gpu 드라이버(virtio-win ISO)가 깔려 있어야 2개로 잡힙니다.
 
-| | 현재 | 여유용 | 그 이상은 |
-|---|---|---|---|
-| vCPU | 8 | 12 | 호스트가 16스레드, `.5` 가 4개를 쓰므로 남는 건 4개뿐 |
-| RAM | 30GB | 38GB | 호스트 여유가 페이지 캐시 포함 약 24GB |
-| 디스크 | 293GB 여유 | 그대로 | VM 80GB 쓰고도 충분 |
+#### 100% 부하에서도 괜찮은가 — 재봤습니다
 
-`.5` 에서 운영 컨테이너 19개가 돌고 있으니 `.9` 가 호스트 자원을 다
-가져가지 않도록 두세요.
+**VM 4 vCPU 까지는 안전하고, `.9` 의 CPU 를 늘리면 오히려 해롭습니다.**
+
+`.9` 안에서 VM 이 4코어를 100% 써도 영향은 작습니다.
+
+```
+            부하 없음      VM 4코어 100%
+테스트         5.9초    ->    6.1초   (+3%)
+파이프라인      9.8초    ->   11.0초   (+12%)
+```
+
+문제는 호스트입니다. 물리 호스트는 i7-11700(8코어/**16스레드**)뿐인데
+`.5` 에서 운영 컨테이너 19개가 돌고 있습니다. `.5` 의 응답 속도를 재봤습니다.
+
+```
+.9 가 한가할 때          616~628ms   기준
+.9 가 4코어 사용         657~678ms   +7%   ← VM 이 100% 인 실제 상황
+.9 가 8코어 전부 사용   1487~1491ms  +140% ← 봇까지 동시에 바쁠 때
+```
+
+**그래서 `.9` 의 vCPU 는 늘리면 안 됩니다.** 늘릴수록 호스트 지분이 커져
+`.5` 의 운영 서비스가 느려집니다. 지금 8개가 적정 상한입니다.
+최악(8코어 전부)을 아예 막으려면 VM 을 CPU 상한과 함께 띄웁니다.
+
+```bash
+systemd-run --user --scope -p CPUQuota=400% -p CPUWeight=50 --unit win-ci   qemu-system-x86_64 -enable-kvm ...
+```
+
+`CPUWeight=50` 은 봇과 경합할 때 VM 이 양보한다는 뜻입니다.
+`CPUQuota=200%` 로 재봤을 때 `.5` 응답이 649~653ms 로 기준선과 같았습니다.
+
+RAM 은 최악을 다 더해도 여유가 있습니다.
+
+```
+ejclaw 봇 (실측 최대)          7.2 GB
+Windows VM 게스트              8.0 GB
+QEMU 오버헤드                  0.4 GB
+GPU 작업 동시 실행             3.0 GB
+tmpfs 워치독 경보선            3.0 GB
+─────────────────────────────────────
+최악 합계                     21.6 GB / 30 GB   (여유 8.4 GB)
+```
+
+**결론: CPU·RAM 모두 증설 없이 진행하면 됩니다.** RAM 만 여유를 두고 싶다면
+30 → 38GB 까지는 호스트가 감당합니다(호스트 62.6GB, 여유 약 24GB).
+CPU 는 늘리지 마세요.
 
 #### ⚠️ 메모리 cgroup 함정 — 반드시 `systemd-run --scope`