docs: 100% 부하 실측 — .9 CPU 증설은 오히려 해롭다 (이전 권고 정정)

"VM 이 실제 윈도우와 다른가, 100% 부하에서도 자원이 괜찮은가" 에 대한 답.
앞선 측정은 한가할 때 값이라 부하를 걸어 다시 쟀고, 결론이 하나 바뀌었다.

이전에 "여유용으로 vCPU 12까지 가능" 이라고 적었는데 틀렸다. 늘리면 .5 의
운영 컨테이너 19개가 느려진다. 물리 호스트가 i7-11700 16스레드뿐이라
.9 의 지분이 커지는 만큼 .5 가 밀린다. .5 응답 속도 실측:

  .9 한가할 때        616~628ms   기준
  .9 가 4코어 사용    657~678ms   +7%    <- VM 100% 인 실제 상황, 무시 가능
  .9 가 8코어 전부   1487~1491ms  +140%  <- 봇까지 동시에 바쁠 때

VM 4 vCPU 는 안전하다. .9 내부 영향도 작다 (파이프라인 9.8 -> 11.0초).
최악(8코어 전부)을 막으려면 CPUQuota=400% + CPUWeight=50 으로 띄운다.
CPUQuota=200% 로 재봤을 때 .5 응답이 649~653ms 로 기준선과 같았다.

RAM 은 최악을 다 더해도 21.6GB / 30GB 로 8.4GB 여유가 있다.
QEMU 오버헤드는 -m 8192 기준 VmSize 8.22GB 로 약 0.2GB.

VM 의 Windows 가 실제와 다른지도 정리했다. 같은 바이너리이고 WASAPI,
RegisterHotKey, 모니터 열거, PyInstaller 모두 코드 경로가 동일하다.
다른 건 GPU 없음, 실제 게임 소리 없음, 속도/지연 세 가지뿐이다.

부수 수확: virtio-vga,max_outputs=2 가 KVM 으로 기동되는 것을 확인했다.
--vga std 는 화면이 1개라 모니터 선택 기능을 검증할 수 없는데, 이걸 쓰면
화면 2개를 줄 수 있어 사용자가 요청한 모니터 선택 기능도 자동 검증 가능하다
(게스트에 virtio-gpu 드라이버 필요).

결론: CPU·RAM 모두 증설 없이 진행. RAM 만 원하면 38GB 까지 가능. CPU 는 금지.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

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** 입니다.
+**맞습니다. 같은 Windows 이고 같은 바이너리입니다.** 우리가 검증하려는 것들은
-`.9` 는 그중 8 vCPU / 30GB 를 쓰고 있습니다.
+코드 경로가 동일합니다.
+
+| | 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
+-device virtio-vga,max_outputs=2      # KVM 기동 확인 완료
-           코어는 4개에서 포화 -> 8개면 VM 4 + 봇 4 로 충분
 ```
 
-**그대로 두셔도 됩니다.** 굳이 여유를 두고 싶다면 아래 정도가 상한입니다.
+Windows 쪽에 virtio-gpu 드라이버(virtio-win ISO)가 깔려 있어야 2개로 잡힙니다.
 
-| | 현재 | 여유용 | 그 이상은 |
+#### 100% 부하에서도 괜찮은가 — 재봤습니다
-|---|---|---|---|
-| vCPU | 8 | 12 | 호스트가 16스레드, `.5` 가 4개를 쓰므로 남는 건 4개뿐 |
-| RAM | 30GB | 38GB | 호스트 여유가 페이지 캐시 포함 약 24GB |
-| 디스크 | 293GB 여유 | 그대로 | VM 80GB 쓰고도 충분 |
 
-`.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`