Files
live-app-translator/docs/WINDOWS-TESTING.md
EJClaw d0028abdac
Some checks failed
Windows / verify (push) Has been cancelled
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>
2026-09-23 04:05:31 +09:00

19 KiB

Windows에서 자동 검증 붙이기

개발은 리눅스에서 하고 있어서 Windows 전용 경로는 테스트가 불가능합니다. 오디오 캡처, 전역 단축키, 모니터 열거, exe 빌드가 전부 여기에 해당합니다. 그래서 "리눅스에서 다 통과했는데 윈도우에서 안 되더라"가 나올 수 있습니다.

Windows 러너를 하나 붙이면 main 에 push할 때(또는 Actions 탭에서 수동 실행할 때) 이 경로들이 자동으로 검증됩니다.

어디에 올릴까 — 서버 Windows VM 권장

개인 PC를 안 쓰고 서버에 올려 완전 자동화하는 게 가장 깔끔합니다. GPU가 없어도 됩니다. 실제로 확인해봤습니다.

검증 항목 GPU 필요? GPU 없는 서버 VM
단위 테스트 189개 ❌ ✅
WASAPI 장치·프로그램 열거 ❌ ✅
전역 단축키 ❌ ✅
모니터 열거·자막 배치 ❌ ✅
포터블 exe 빌드·기동 ❌ ✅
오디오 → 한국어 자막 (전 과정) ❌ CPU로 됨 ✅
CUDA 인식·VRAM 상한 ✅ ⚠️ 경고만 (빌드 통과)

GPU 검증은 .9(리눅스)에서 — 이미 돌아갑니다

GPU는 .9에 고정입니다. 그래서 GPU 검증은 Windows가 아니라 여기서 합니다. 한 줄이면 됩니다.

scripts/gpu-check.sh

RTX 5050 실측 결과입니다.

[OK] CUDA 사용 가능            RTX 5050 · 7.5GB
[OK] VRAM 상한이 실제로 걸리는지  35% 상한 적용됨
[OK] GPU 로 실제 번역           '적 왼쪽에서 오는'
[OK] 티어 게이트가 뭐라고 하는지  정밀=autoawq 없음 / 극한=VRAM 부족(16GB 필요, 7.5GB)
6/6 통과

이 GPU로는 4·5티어를 쓸 수 없습니다. 정밀은 autoawq가 필요하고 (pip install autoawq), 극한은 16GB가 필요한데 카드가 7.5GB입니다. 극한은 카드를 바꾸지 않는 한 영영 불가능합니다. 1~3티어는 정상 동작합니다.

GPU가 필요한 테스트는 어떻게 하나

GPU는 한 VM만 독점합니다. 컨슈머 NVIDIA는 vGPU/SR-IOV를 지원하지 않아서 쪼개 쓸 방법이 없습니다. 지금 RTX 5050은 .9(리눅스)에 물려 있습니다.

그래서 러너를 라벨로 둘로 나눠뒀습니다. 지금은 앞의 것만 있으면 되고, 나중에 GPU 머신이 생기면 뒤의 것을 붙이기만 하면 됩니다. 워크플로는 이미 그렇게 짜여 있습니다.

러너 라벨 어디에 언제 도나 무엇을
windows:host GPU 없는 서버 VM main push마다 자동 테스트·Windows 경로·오디오→자막·exe 빌드
windows-gpu:host GPU 달린 머신 수동 실행만 CUDA 인식·VRAM 상한·4·5티어·GPU 번역

GPU 러너를 상시로 띄울 필요는 없습니다. 필요할 때만 daemon을 켜고 Actions 탭에서 Windows GPU → Run workflow 하면 됩니다. 러너가 없으면 큐에 쌓이기만 하고 아무 일도 일어나지 않습니다.

GPU 워크플로는 GPU가 없으면 분명히 실패합니다. GPU를 확인하겠다고 부른 작업이 조용히 통과하면 안 되니까요. nvidia-smi가 없으면 그 자리에서 멈춥니다.

여러 프로젝트가 GPU 러너를 같이 쓸 때 — 동시에 돌리면 안 됩니다

이게 가장 중요합니다. GPU는 나눠 쓸 수 없어서, 두 작업이 동시에 VRAM을 잡으면 둘 다 OOM으로 죽거나 하나가 조용히 느려져 원인을 못 찾습니다. CPU 러너와 달리 GPU 러너는 반드시 한 번에 한 작업만 돌아야 합니다.

보장 장치가 두 겹입니다.

  1. 러너 capacity: 1 — 진짜 보장입니다. 저장소가 달라도 막힙니다. act_runner 설정 파일(config.yaml)에서 확인하세요. 기본값이 1이지만 GPU 러너에서는 반드시 확인하고 넘어가세요.

    runner:
      capacity: 1   # GPU 러너는 절대 올리지 말 것
    

    설정 파일이 없으면 만들고 --config config.yaml 로 띄웁니다.

    .\act_runner.exe generate-config > config.yaml
    .\act_runner.exe daemon --config config.yaml
    
  2. 워크플로 concurrency — 같은 저장소 안에서 겹치는 것만 막습니다. windows-gpu.yml 에 이미 들어 있습니다. 다른 저장소에는 효력이 없으니 1번을 대신하지 못합니다.

한 대에 러너 프로세스를 여러 개 띄우지도 마세요. capacity 1짜리 러너가 둘이면 결국 동시에 두 작업이 돕니다.

GPU 머신을 어디서 구하나

다른 프로젝트도 이 러너에서 GPU 테스트를 돌리실 거라면 셋 중 하나입니다.

  1. 서버에 GPU 한 장 더 — 가장 깔끔합니다. PCIe 슬롯과 파워 여유만 있으면 그 GPU를 Windows VM에 패스스루하고 windows-gpu 라벨로 등록하면 끝입니다. 이후로는 두 러너가 각자 계속 돕니다.
  2. RTX 5050을 Windows VM으로 옮기기 — .9가 GPU를 포기해야 합니다. .9에서 하던 GPU 작업(이미지 생성 등)을 못 하게 되니 득실을 따져보세요.
  3. 필요할 때만 실물 PC에 GPU 러너 — 평소엔 꺼두고 GPU 검증이 필요할 때만 켭니다. 수동 실행이라 게임 중에 갑자기 도는 일은 없습니다.

1번이 가능한지는 서버에서 이걸로 확인할 수 있습니다.

lspci | grep -i vga          # GPU가 몇 장 꽂혀 있나
dmidecode -t slot | grep -i "in use"   # 빈 PCIe 슬롯이 있나

선택지 A — .9 안에 Windows VM (중첩 가상화)

Proxmox를 건드리지 않고 .9(우분투) 안에서 바로 Windows VM을 돌릴 수 있습니다. 실제로 확인했습니다.

/dev/kvm                존재
kvm_intel nested        Y
qemu -enable-kvm        kvm support: enabled   ← 실측
여유 RAM / 디스크        25GB / 294GB

가장 큰 장점은 사람 손이 안 간다는 것입니다. .9 안이라 에이전트가 VM 생성부터 러너 등록까지 직접 합니다. Proxmox 자격증명도 필요 없습니다.

단, GPU는 여전히 안 됩니다. 중첩 패스스루가 불가능합니다.

IOMMU 그룹 수           0개
커널 cmdline            iommu 옵션 없음

되게 하려면 Proxmox가 .9에 vIOMMU를 열어주고 .9 커널에 intel_iommu=on을 넣은 뒤 GPU를 vfio-pci에 묶어야 하는데, 그러면 .9가 GPU를 잃습니다. 결국 "GPU를 누가 가질 것인가" 문제로 되돌아오므로 중첩으로는 해결되지 않습니다.

VM 에 얼마를 줄까 — 실측 근거

vCPU 4개 / RAM 8GB / 디스크 80GB. 추측이 아니라 재보고 정한 값입니다.

CPU 는 4개에서 포화합니다. 더 줘도 빨라지지 않습니다.

파이프라인(음성→자막)   2코어 13초 · 4코어 10초 · 8코어 11초
테스트 190개            4코어 5.9초 · 8코어 5.8초

CI 작업 대부분이 단일 스레드라 코어를 늘려도 효과가 없습니다. 음성인식만 병렬인데 그것도 4개에서 멈춥니다.

RAM 8GB 는 Windows 11 이 쾌적하게 도는 최소선이고, 그 안에서 도는 음성인식+번역이 2~3GB 를 씁니다. 디스크 80GB 는 Windows 30GB + 모델 캐시

  • 빌드 산출물 기준입니다.

VM 의 Windows 는 진짜 Windows 인가

맞습니다. 같은 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개뿐입니다.

-device virtio-vga,max_outputs=2      # KVM 기동 확인 완료

Windows 쪽에 virtio-gpu 드라이버(virtio-win ISO)가 깔려 있어야 2개로 잡힙니다.

100% 부하에서도 괜찮은가 — 재봤습니다

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 상한과 함께 띄웁니다.

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

에이전트 턴에서 그냥 qemu를 띄우면 VM이 봇의 cgroup 안에서 돕니다. ejclaw.service는 MemoryHigh=16G이고 평상시 5G를 쓰므로, 8G짜리 VM이 그 안에 들어가면 상한에 부딪혀 봇이 OOM으로 죽습니다(전례 있음).

# 봇 cgroup 밖(app.slice 형제)에 VM 을 띄운다 — 실측으로 확인됨
systemd-run --user --scope -p MemoryMax=10G --unit win-ci   qemu-system-x86_64 -enable-kvm -m 8192 ...

A vs B 비교

A: .9 안 중첩 VM B: Proxmox VM
만드는 사람 에이전트가 직접 사용자
GPU ❌ ❌ (별도 GPU 추가 시 ⭕)
속도 중첩이라 다소 느림 네이티브
.9 재부팅 시 같이 죽음 영향 없음
RAM .9의 30GB를 나눠 씀 독립

CI는 타임아웃이 30분인데 파이프라인이 27초라 속도 여유가 충분합니다. 먼저 A로 띄워보고, 부족하면 B로 옮기는 편을 권합니다.

선택지 B — Proxmox에 Windows VM 만들기

# Proxmox 호스트에서 (VMID 는 비어 있는 번호로)
qm create 920 --name win-ci --memory 8192 --cores 4   --net0 virtio,bridge=vmbr0 --scsihw virtio-scsi-single   --scsi0 local-lvm:80 --ostype win11 --machine q35 --bios ovmf   --efidisk0 local-lvm:1,efitype=4m,pre-enrolled-keys=1 --tpmstate0 local-lvm:1,version=v2.0   --ide2 local:iso/Win11.iso,media=cdrom --ide0 local:iso/virtio-win.iso,media=cdrom   --audio0 device=ich9-intel-hda,driver=none   --vga std

RAM 8GB / 디스크 80GB면 충분합니다(모델 캐시 포함). 아래 둘을 꼭 넣으세요.

  • --audio0 ... — 없으면 오디오 장치가 하나도 안 잡혀 WASAPI 점검이 실패합니다
  • --vga std — 화면이 있어야 자막 오버레이를 그리고 스크린샷을 찍습니다

VM 안에서 꼭 해야 하는 두 가지

1. 자동 로그온 — 러너가 서비스로 돌면 데스크톱 세션이 없어 GUI 테스트와 스크린샷이 전부 실패합니다. 자동 로그온 + 로그온 시 실행이어야 합니다.

# 관리자 PowerShell (VM 안이므로 부담 적음)
$k = "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon"
Set-ItemProperty $k AutoAdminLogon 1
Set-ItemProperty $k DefaultUserName "ci"
Set-ItemProperty $k DefaultPassword "<비밀번호>"

2. 화면 꺼짐·잠금 끄기 — 잠기면 GUI 테스트가 실패합니다.

powercfg /change monitor-timeout-ac 0
powercfg /change standby-timeout-ac 0

그 다음은 아래 일반 설치 절차와 같습니다. 러너는 서비스가 아니라 로그온 예약 작업으로 등록하세요(아래 "항상 켜두고 싶다면" 참고).


무엇이 자동으로 확인되나

항목 리눅스에서 Windows 러너에서
단위 테스트 189개 ✅ ✅
WASAPI 루프백 장치 열거 ❌ ✅
소리 내는 프로그램 열거 ❌ ✅
전역 단축키 등록/해제 ❌ ✅
모니터 열거·자막 배치 가상 화면만 ✅ 실제 모니터
포터블 exe 빌드 ❌ ✅
exe가 실제로 뜨는지 ❌ ✅
GPU 인식 (CUDA) 이 서버 GPU ✅ 실제 게임 PC GPU
실제 화면 스크린샷 offscreen ✅ 진짜 화면

결과물(exe, 스크린샷, 로그)은 Gitea Actions의 artifact로 올라오므로 원격에서도 눈으로 확인할 수 있습니다.


설치 (약 10분, 한 번만)

1. 필요한 것 설치

winget install Git.Git                                  # 소스 받기 (checkout) 에 필요
winget install Microsoft.PowerShell                     # 워크플로가 pwsh 7 을 씁니다
winget install Python.Python.3.12
winget install Kitware.CMake
winget install Microsoft.VisualStudio.2022.BuildTools   # C++ 데스크톱 워크로드 선택

Git.Git 과 Microsoft.PowerShell 은 빠뜨리기 쉬운데 둘 다 필수입니다. Git 이 없으면 소스를 못 받고, Windows 에 기본으로 깔린 PowerShell 은 5.1 이라 워크플로가 쓰는 pwsh(7.x) 가 없으면 단계마다 실패합니다. 설치 후 새 PowerShell 창을 열어 git --version, pwsh --version 이 나오는지 확인하세요.

2. Gitea 러너 내려받기

https://gitea.com/gitea/act_runner/releases 에서 act_runner-<버전>-windows-amd64.exe 를 받아 C:\gitea-runner\act_runner.exe 로 둡니다.

3. 등록 토큰 받기

Gitea 웹에서 저장소 → 설정 → Actions → 러너 → 등록 토큰 생성 (주소: https://git.tkrmagid.kr/tkrmagid/live-app-translator/settings/actions/runners)

4. 등록하고 실행

cd C:\gitea-runner
.\act_runner.exe register --no-interactive `
  --instance https://git.tkrmagid.kr `
  --token <위에서 받은 토큰> `
  --name windows-test `
  --labels windows:host

.\act_runner.exe daemon

--labels windows:host 가 중요합니다. 워크플로의 runs-on: windows 와 이름이 맞아야 하고, :host 는 컨테이너가 아니라 그 PC에서 직접 돌리라는 뜻입니다 (생략해도 기본값이 host 지만 명시하는 편이 낫습니다).

이름이 안 맞으면 Gitea 는 작업을 실패시키지 않고 기본 우분투 컨테이너에서 돌립니다. Windows 검증이 조용히 리눅스에서 돌아가는 셈이라, 워크플로 첫 단계에서 그걸 막아 뒀습니다.

5. 확인

워크플로는 main 에 push될 때 또는 Actions 탭에서 수동 실행할 때 돕니다. (.gitea/workflows/windows.yml 의 on: 항목)

저장소 Actions 탭 → Windows → Run workflow 로 바로 한 번 돌려보세요.


항상 켜두고 싶다면 (선택)

서비스(sc.exe create)로 등록하지 마세요. 그렇게 하면 SYSTEM 권한으로 돌아가 러너가 PC 전체를 건드릴 수 있게 됩니다. 로그인할 때 그 계정 권한으로 뜨게 하는 편이 안전합니다.

# 관리자 아님 — 그냥 평소 PowerShell
$action  = New-ScheduledTaskAction -Execute "C:\gitea-runner\act_runner.exe" `
                                   -Argument "daemon" -WorkingDirectory "C:\gitea-runner"
$trigger = New-ScheduledTaskTrigger -AtLogOn
Register-ScheduledTask -TaskName "gitea-runner" -Action $action -Trigger $trigger

게임할 때 방해되면 그냥 꺼두고, 확인이 필요할 때만 daemon 을 켜도 됩니다. 러너가 꺼져 있으면 워크플로는 대기만 하고 아무 일도 하지 않습니다.


안전에 대해 — 정확히 어떤 권한인가

솔직하게 말하면, 이건 "그 PC에서 명령을 실행할 수 있는 권한"입니다.

러너는 저장소의 워크플로 파일을 실행합니다. 그런데 저(Claude)는 이 저장소의 main에 push할 수 있으므로, 워크플로 파일을 고쳐서 커밋하면 결과적으로 그 PC에서 원하는 명령을 돌릴 수 있습니다. "커밋된 파일만 실행하니 안전하다"는 말은 정확하지 않습니다.

실제로 보장되는 것은 이것뿐입니다.

  • 숨길 수 없습니다. 실행되는 모든 것은 .gitea/workflows/ 안에 있고 git 기록에 남습니다. 몰래 뭘 했는지 나중에 전부 확인할 수 있습니다.
  • 러너를 끄면 즉시 멈춥니다. daemon 을 종료하면 그만입니다.
  • 러너는 자기 계정 권한으로 돕니다. 관리자로 띄우지 마세요.

그래서 권하는 방식은 이렇습니다.

방법 위험 얻는 것
Windows VM (Proxmox 등) 거의 없음 빌드·단축키·모니터·UI·exe 실행
전용 Windows 계정 낮음 — 그 계정 파일만 노출 위 전부 + 실제 GPU
평소 쓰는 계정 개인 파일·브라우저 세션 노출 위 전부 + 실제 게임 소리

VM이나 전용 계정을 권합니다. GPU와 실제 게임 소리 확인은 못 하지만, 지금 미검증인 항목의 대부분(빌드·단축키·모니터·UI·exe 기동)은 거기서도 그대로 검증됩니다. GPU/오디오는 필요할 때만 평소 계정에서 한 번씩 확인하는 편이 낫습니다.

부담스러우면 러너를 붙이지 않고 아래 "러너 없이 직접 돌려보기"만 하셔도 충분합니다.


러너 없이 직접 돌려보기

러너를 안 붙이고 그때그때 확인만 하고 싶다면 이것만 실행하고 결과를 보내주셔도 됩니다.

git clone https://git.tkrmagid.kr/tkrmagid/live-app-translator
cd live-app-translator
py -3.12 -m venv .venv
.\.venv\Scripts\python -m pip install -r packaging\requirements-portable.txt pytest
$env:PYTHONPATH="src"
.\.venv\Scripts\python -m pytest tests -q
.\.venv\Scripts\python packaging\windows_smoke.py

artifacts\windows-smoke.txt 와 artifacts\*.png 를 보내주시면 됩니다.