Vrew 하드웨어 가속, 켜야 하나 꺼야 하나 — 지인 노트북에 SSH 로 들어가 확인한 13개 sub-feature 이야기

지인의 노트북에 SSH 로 들어가 본 적이 있습니다. 옆에서 잠깐 봐달라는 부탁이 아니라, "Vrew 의 하드웨어 가속, 켜야 하나 꺼야 하나" 라는 한 줄짜리 질문 때문이었습니다. 같은 자리에 있지 않아도 PowerShell 한 줄이면 환경 정도는 확인할 수 있겠다는 생각이 들었고, 마침 그 노트북은 Tailscale 사설 IP 와 한글 hostname 으로 winbox 라는 SSH alias 에 등록되어 있었습니다.

한 줄짜리 질문이라고 생각하고 들어갔는데, 결론부터 말씀드리면 그 토글은 단일 스위치가 아니었습니다. Chromium 의 13개 sub-feature 묶음 라벨이고, Vrew 에서는 그중에서도 "영상 인코딩" 한 단계만 켜고 끄는 토글이었습니다. 이 글은 그 사실에 도달하기까지의 과정과, 같은 위치에 있는 다른 누군가가 같은 결정을 내릴 때 참고할 수 있도록 정리해본 기록입니다.

먼저 정리하자면, 이 노트북에서는 "ON 유지" 가 정답입니다. 다만 그 결론보다 중요한 것은 결론에 도달한 근거이고, 다른 환경에서는 같은 토글이 다른 답을 낼 수 있다는 점입니다.

Vrew 하드웨어 가속 토글이 사는 위치

Vrew 의 "하드웨어 가속" 토글은 앱 전역 환경설정이 아니라, 영상 내보내기 다이얼로그 → 고급 설정 → 가장 아래 체크박스 에 위치해 있습니다. 정확한 라벨은 "하드웨어 (그래픽 카드) 가속" 입니다. 이 위치가 첫 번째 단서였습니다.

전역 설정이 아니라 내보내기 다이얼로그 안에만 있다는 사실은, 이 토글의 영향 범위가 "영상 인코딩 단계" 로 한정된다는 가장 직접적인 증거입니다. 토글이 사는 위치는 그 토글이 무엇을 끄는지에 대해 가장 정직한 단서를 제공한다는 생각이 들었습니다.

그래서 다음의 것들은 이 토글의 영향을 받지 않습니다.

• 편집 중의 미리보기 재생
• STT (음성 → 자막) 처리
• AI 음성 합성

미리보기가 끊긴다고 이 토글을 끄는 건, 다른 방을 청소하면서 이쪽 방의 먼지가 줄기를 기대하는 일과 비슷합니다.

"하드웨어 가속" 은 단일 스위치가 아닙니다

토글 한 줄로 보이지만, 그 뒤에 숨어 있는 것은 Chromium 의 13개 sub-feature 묶음입니다. Electron 의 app.getGPUFeatureStatus() 가 반환하는 GPUFeatureStatus 객체는 다음과 같은 키들을 각각 독립 상태로 추적합니다.

• 2d_canvas
• gpu_compositing
• rasterization
• video_decode
• video_encode
• webgl / webgl2
• 그 외 6개

각 키는 enabled_on, disabled_software, disabled_off 같은 10여 가지 상태 중 하나를 가집니다. 거기에 Chromium 의 software_rendering_list.json 이라는 GPU blocklist 가 디바이스별로 일부 sub-feature 만 끄는 일이 흔합니다. 같은 OS, 같은 드라이버 버전이라도 chrome://gpu 의 Feature Status 표가 머신마다 다르게 보이는 이유입니다.

그래서 "하드웨어 가속" 이라는 라벨을 만나면, 이 앱이 13개 중 정확히 어느 sub-feature 묶음을 가리키는지부터 묻는 습관이 필요하다는 결론에 닿게 됩니다. 거칠게나마 분류하면 다음의 4개 레이어가 됩니다.

#	레이어	영상 편집기에 미치는 영향	터미널·텍스트 앱에 미치는 영향
1	GPU 컴포지터 (viz)	큼 — 미리보기 캔버스 합성	작음
2	Skia GPU raster	중간	매우 작음
3	비디오 디코드 가속 (VideoToolbox / D3D11 / VAAPI)	매우 큼	거의 없음
4	WebGL / WebGPU / Canvas2D	큼	거의 없음

영상 편집기의 부담이 결정되는 레이어는 대체로 #3 비디오 디코드 가속입니다. 압축된 비디오 비트스트림을 매 프레임 디코드하는 작업은 1080p30 H.264 만 해도 CPU 한 코어를 100% 까지 끌어쓸 수 있고, 4K60 HEVC 나 AV1 은 CPU 단독으로 사실상 실시간 처리가 어렵습니다. Chrome 팀은 macOS 풀스크린 비디오 재생 시 비디오 오버레이를 켜면 전력 소모가 절반으로 떨어진다고 측정한 적이 있는데, 같은 사상이 모든 OS 의 디코드 가속 경로에 적용됩니다.

다만 Vrew 토글이 "내보내기 다이얼로그" 에 사는 이유는, Vrew 의 토글이 가리키는 핵심은 #3 의 디코드 쪽이 아니라 video_encode — 즉 인코딩 가속 쪽이라는 정황과 맞닿아 있습니다. 이 부분은 뒤에서 따로 풀어보겠습니다.

winbox 에서 직접 본 환경

SSH 로 들어가서 PowerShell 로 환경을 한 번 훑었습니다. 명령은 거창하지 않습니다.

Get-CimInstance Win32_VideoController | Select-Object Name, DriverVersion, DriverDate
Get-CimInstance Win32_Processor | Select-Object Name, NumberOfCores, NumberOfLogicalProcessors

결과를 정리하면 다음과 같습니다.

항목	값
OS	Windows 11 Home Build 26200 (24H2)
CPU	Intel Core i5-13500H (12C / 16T)
GPU #1	NVIDIA RTX 4050 Laptop (4GB VRAM, NVENC 8세대)
GPU #2	Intel Iris Xe Graphics (QuickSync)
NVIDIA 드라이버	32.0.15.6626 (2024-11-24)
Intel 드라이버	32.0.101.6129 (2024-11-21)
Vrew	4.1.1 (registry 확인)

NVENC 와 QuickSync 가 모두 깔려 있는, 가속을 켜기에 거의 이상적인 조합입니다. 다만 두 드라이버가 모두 약 6개월 가량 묵어 있다는 점이 눈에 띄었습니다. Vrew 의 D31 (그래픽 드라이버 구버전) 에러가 이 정도 묵음에서 곧잘 등장한다는 보이저엑스 공식 안내를 기억하고 있어서, 이 환경에서 가장 먼저 권하고 싶은 조치는 토글을 끄는 일이 아니라 드라이버 업데이트 쪽이라는 생각이 들었습니다.

다음으로 %APPDATA%\vrew\ 폴더를 훑어 봤습니다. 가속이 실제로 살아 움직이고 있는지 확인하기에 좋은 자리입니다.

Get-ChildItem ~\AppData\Roaming\vrew | Select-Object Name, LastWriteTime

그 안에서 다음 폴더들이 살아 있었습니다.

• GPUCache/ — Chromium 의 GPU 캐시. 가속 활성 상태일 때 만들어집니다.
• DawnWebGPUCache/ — WebGPU 셰이더 캐시
• DawnGraphiteCache/ — Skia 의 새 GPU 백엔드인 Graphite 캐시
• VideoDecodeStats/ — 비디오 디코드 가속 통계
• ffmpeg_gpl_vgx_v3/ — Vrew 가 사용하는 ffmpeg GPU 인코더 바이너리
• autosave/ 의 최신 기록은 2026-05-27, localProjectHistory.json 은 2026-05-28

활발히 사용 중이고, GPU 가속 캐시가 모두 살아 있고, 별도의 "가속 비활성" 흔적도 없습니다. 정황상 이 노트북에서는 가속이 잘 동작하고 있다고 봐도 무방합니다.

다만 한 가지는 정직하게 인정하고 넘어가야 했습니다. D31 흔적을 찾기 위해 Preferences, localProjectHistory.json 같은 텍스트 파일을 대상으로 D31|E07|E10|E25|E26|E27|E28|hardware|gpu 패턴을 검색해 봤지만 0 매칭이었습니다. 0 매칭이라는 결과만 보고 "이 노트북에는 가속 관련 에러가 한 번도 없었다" 고 단정하기는 어렵습니다.

검색의 한계 — Vrew 는 별도 application log 를 남기지 않는 디자인입니다. logs/ 폴더가 아예 없습니다. 검색 가능한 범위가 Chromium 표준 텍스트 형식 파일에 한정되고, IndexedDB / LevelDB 같은 바이너리 안에 들어가 있는 기록은 직접 grep 으로 잡히지 않습니다. "없다" 가 "안전하다" 의 증명이 되지는 않습니다.

그래도 캐시 폴더가 모두 살아 있고 최근까지 활발히 사용 중이라는 정황은, "최근에 가속을 끄게 만든 큰 사고는 없었다" 정도의 약한 결론을 지지하기엔 충분하다고 봤습니다.

ON / OFF 는 GPU 와 CPU 의 무게중심을 옮기는 일

토글의 결과를 단순히 "ON 이면 GPU 만 일하고, OFF 면 CPU 만 일한다" 고 이해하기 쉽지만, 좀 더 정확한 표현은 "부하의 무게중심이 GPU 와 CPU 사이를 옮겨 다닌다" 쪽입니다. 양쪽 토글 모두에서 GPU 와 CPU 는 어느 정도 동시에 일합니다.

작업 단계별로 분담을 풀어 보면 다음과 같습니다.

작업 단계	가속 ON	가속 OFF
영상 디코드 (입력)	GPU (D3D11)	GPU 그대로 또는 CPU 폴백
컬러스페이스 변환	GPU 셰이더	CPU
영상 인코딩 (핵심)	GPU 의 NVENC 칩	CPU 의 x264 / x265
오디오 인코딩 (AAC)	CPU	CPU
mp4 muxing	CPU	CPU

토글의 실제 효과가 가장 크게 갈라지는 자리는 영상 인코딩 한 단계입니다. NVENC 같은 전용 인코딩 칩을 쓰느냐, x264 / x265 같은 CPU 소프트웨어 인코더를 쓰느냐의 차이이고, 체감 결과는 다음 표 정도로 갈립니다.

지표	가속 ON	가속 OFF
CPU 부담	10 ~ 25%	80 ~ 100%
GPU 부담	NVENC 칩 + VRAM 100 ~ 800MB	디코드 정도만
인코딩 시간	실시간의 0.5 ~ 1배	실시간의 2 ~ 5배

다시 말해 NVENC 가 잘 동작하는 환경이라면 가속 ON 은 영상 내보내기 시간을 수 배 단축합니다. 반대로 가속을 꺼야 할 때는 GPU 부담을 0 으로 만들기 위해서가 아니라, GPU 인코딩 경로에서 발생하는 특정 에러를 우회하기 위해서입니다.

하드웨어 가속 끄기로 풀리지 않는 흔한 오해

안티패턴 — 다음 증상들은 가속 토글과 무관합니다. 끄더라도 해결되지 않습니다.

• srt 자막이 출력 영상에서 끊겨 보이는 현상 — 자막 시간 코드 이슈입니다.
• 배속 편집 후 음성이 끊기는 현상 — 1.0배로 되돌리면 대부분 해결됩니다.
• VFR (가변 프레임률) 화면녹화 영상에서 검정 화면이 나오는 현상 — 입력 코덱 이슈입니다.

"끊김 = 가속 끄기" 라는 단순 가설을 너무 빨리 적용하면, 정작 해결되지 않는 동시에 인코딩 시간만 두 배로 길어집니다.

가속 토글이 정직하게 효과를 보이는 자리는 보이저엑스가 공식으로 묶어둔 에러 코드들 — E07, E10, E25, E26, E27, E28 — 이 떴을 때입니다. 그 외의 "어딘가 이상하다" 류 증상에 토글을 만지기 시작하면 원인을 잘못 잡을 가능성이 큽니다.

같은 라벨, 다른 의미 — 곁가지 한 단락

같은 이름의 토글이 다른 앱에 있을 때도 같은 것을 가리키지 않을 수 있다는 점은 짚어둘 만합니다. 예를 들어 Termius 같은 SSH 클라이언트에 "하드웨어 가속" 이라는 라벨이 등장한다면, 그건 Chromium 의 UI 합성기 — 텍스트 페인트나 스크롤 같은 레이어 — 를 가리킵니다. Vrew 와는 완전히 다른 레이어이고, SSH 프로토콜 자체와는 더더욱 관련이 없습니다. Vrew 와 Termius 모두 Electron 기반 앱이라는 공통점이 있어도, 그 토글이 가리키는 sub-feature 묶음은 서로 다른 자리에 있습니다. 같은 라벨을 만나면 그 앱이 13개 sub-feature 중 어느 것을 가리키는지부터 다시 묻는 편이 안전합니다.

이 노트북의 결론, 그리고 미확정으로 남겨두는 것들

winbox 환경 — Windows 11 24H2, i5-13500H, RTX 4050 + Iris Xe, 약 6개월 된 드라이버, Vrew 4.1.1 — 에서의 결론은 다음과 같습니다.

• 하드웨어 가속은 ON 유지가 정답입니다. NVENC 가 살아 있는 환경에서 끄면 내보내기 시간만 두 배 이상 늘어납니다.
• 먼저 손대야 할 것은 드라이버 업데이트입니다. NVIDIA / Intel 모두 약 6개월 묵어 있어서, D31 같은 에러를 예방하는 차원에서 우선순위가 가장 높습니다.
• 토글을 끄는 시점은 E07 / E10 / E25 / E26 / E27 / E28 에러가 실제로 떴을 때입니다. 그전에는 굳이 만질 이유가 없습니다.

이 결론은 winbox 환경에 한정된 결론입니다. 다른 노트북, 다른 GPU 조합, 다른 드라이버 상태에서는 다른 답이 나올 수 있고, 그게 이 토글의 본질에 더 가까운 모습이라는 생각이 들었습니다.

마지막으로 정직하게 미확정으로 남겨두는 부분들이 있습니다.

미확정 사항

• Vrew 가 NVENC / QuickSync / AMF 중 정확히 어느 GPU 인코더를 어떤 우선순위로 선택하는지에 대한 공식 명시가 없습니다. 정황상 NVIDIA 우선, Intel 폴백 정도로 추정만 가능합니다.
• D31 흔적 검색의 0 매칭은 "에러가 없었다" 의 증명이 아니라, "검색 가능한 텍스트 파일 범위 안에서 찾히지 않았다" 정도의 결과입니다.
• 다른 앱의 "하드웨어 가속" 토글이 정확히 어느 레이어를 가리키는지는, 그 앱의 코드나 사후 측정 없이 라벨만으로는 단정할 수 없습니다.

그리고 의심되는 부분은 직접 확인하는 편이 가장 빠르다는 점도 적어두고 싶습니다. 작업 관리자의 GPU 그래프를 띄워두고 내보내기를 한 번 돌려보면 NVENC 엔진의 사용률이 그대로 보이고, 내보낸 mp4 를 ffprobe -show_streams 로 열어보면 어느 코덱·어느 인코더가 사용됐는지 메타에 남아 있습니다. %APPDATA%\vrew\ 폴더의 캐시 타임스탬프를 보면 가속 경로가 최근까지 살아 있었는지 정도는 충분히 추론할 수 있습니다.

토글 한 줄짜리 질문에서 시작했는데, 결국 답에 도달하는 가장 정직한 길은 라벨을 한 번 더 의심하고, 들어가서 직접 보는 일이라는 생각이 들었습니다. 같은 라벨이라도 앱마다 끄는 것이 다르고, 같은 토글이라도 환경마다 답이 달라지기 때문입니다.