로컬 PC 실시간 얼굴 교체: GPU, FPS, 웹캠, 개인정보

결론: 실시간 얼굴 교체는 감지·교체·합성 전 과정을 웹캠의 모든 프레임에 대해 본인 기기에서 실행합니다. 프레임레이트는 가장 느린 단계가 정하고, 실용성을 좌우하는 것은 하드웨어 가속이며, FPS를 가장 많이 쓰는 설정은 대개 얼굴 보정입니다.

영상 내보내기는 필요한 만큼 시간을 써도 됩니다. 라이브 미리보기는 그렇지 않습니다. 30 FPS면 프레임당 약 33밀리초 안에 캡처, 얼굴 찾기, 교체, 필요 시 보정, 화면 표시까지 끝내야 합니다. 아래 내용은 모두 이 제약에서 나옵니다.

1. 웹캠의 각 프레임에 일어나는 일

라이브 경로는 루프이며 각 단계마다 비용이 있습니다.

• 캡처. 지정한 해상도와 프레임레이트로 카메라에서 한 프레임을 가져옵니다.
• 감지와 분석. 그 프레임의 얼굴을 찾아 기술하고, 누가 누구인지 판단할 임베딩도 함께 만듭니다.
• 배정. 감지된 각 얼굴을 소스 얼굴에 대응시킵니다. 모두 공통인 기본 소스이거나, 매핑된 인물 중 가장 가까운 후보입니다.
• 교체. 소스와 대상 쌍마다 교체 모델을 실행하고 결과를 프레임에 합성합니다.
• 선택적 보정. 얼굴 보정이 켜져 있고 실행 환경이 라이브 보정을 지원하면 얼굴마다 복원이 실행됩니다.
• 표시. 완성된 프레임을 인코딩해 로컬 루프백 연결로 앱 창에 보냅니다.

여기서 두 가지가 곧바로 따라옵니다. 첫째, 이 경로는 프레임 단위가 아니라 얼굴 단위입니다. 두 명이 화면에 있으면 교체와 보정 부담이 대략 두 배가 됩니다. 둘째, 보이는 프레임레이트는 가장 느린 단계가 정하므로, 병목이 보정이라면 더 빠른 카메라를 찾아도 소용없습니다.

2. 카메라 캡처: 요청한 값과 실제로 받는 값

Deep Face Cam은 960×540, 60 FPS, MJPG로 카메라를 열고 기기가 실제로 준 값을 다시 읽습니다. 의도된 설정입니다. 540p는 합리적인 라이브 작업 해상도이고, 열 때 MJPG를 요청하는 것은 특히 Windows에서 중요합니다. 압축되지 않은 형식으로 남으면 대역폭 제한 때문에 초당 몇 프레임까지 떨어질 수 있기 때문입니다.

Windows에서는 DirectShow, Media Foundation, 그다음 일반 폴백 순으로 시도합니다. 이들 백엔드가 카메라를 열거하는 순서가 다르고 모든 기기가 똑같이 동작하지도 않기 때문입니다. macOS에서는 AVFoundation과 일반 폴백을 씁니다.

실제 프레임레이트도 드라이버 보고값 대신 직접 측정합니다. DirectShow에서는 그 값이 믿을 만하지 않아 60 FPS를 내는 카메라가 30으로 보고하는 일이 흔하기 때문입니다. 값을 보려면 옵션 패널에서 Show FPS를 켜세요.

3. Execution provider: 나머지 전부를 좌우하는 설정

추론은 ONNX Runtime을 거치고, 선택된 execution provider가 라이브 성능의 가장 큰 단일 요인입니다. 백엔드는 시작할 때 사용 가능한 것을 감지해 다음 순서로 우선합니다.

Provider	플랫폼	비고
CUDA	Windows, NVIDIA GPU	NVIDIA에서 최고 성능이지만 드라이버·CUDA·cuDNN 버전 호환성에 민감합니다.
ROCm	AMD 컴퓨트 스택	사용 가능하면 CoreML과 DirectML보다 우선합니다.
CoreML	macOS, Apple 실리콘	PyTorch MPS 대신 사용하며 모델 분할에 따라 CPU·GPU·뉴럴 엔진에 걸쳐 실행될 수 있습니다.
DirectML	Windows	NVIDIA, AMD, Intel까지 폭넓은 GPU를 지원합니다.
CPU	전 플랫폼	호환성은 최대, 속도는 최저. 내보내기에는 쓸 만하지만 라이브에서는 가장 힘듭니다.

Windows는 CPU·DirectML·CUDA가 서로 다른 의존성 세트에서 별도 빌드로 패키징됩니다. 즉 맞는 설치 파일을 고르는 것 자체가 이 결정의 일부이며 나중에 전환하는 설정이 아닙니다. Apple 실리콘에서는 생성된 CoreML 캐시 파일이 사용자 모델 디렉터리에 기록되므로 어떤 모델의 첫 실행이 이후보다 느릴 수 있습니다.

함께 기억할 점으로, 라이브 얼굴 복원은 실행 환경이 CUDA 또는 DirectML일 때만 활성화됩니다. 다른 provider에서는 라이브 경로가 교체만 실행하고, 이미지와 영상 내보내기는 어떤 보정 모델이든 계속 쓸 수 있습니다. 자세한 내용은 GFPGAN과 GPEN 비교에 있습니다.

4. FPS는 어디로 가는가

라이브 미리보기가 느리면 이 순서대로 점검하세요. 시간 소모가 큰 정도와 바꾸기 쉬운 정도를 함께 고려한 순서입니다.

요인	영향	먼저 시도할 것
얼굴 보정	가장 큼. 얼굴마다, 프레임마다 복원 한 번.	끄거나 256 모델로 낮춥니다.
얼굴 수	큼. 교체와 복원 모두 얼굴 단위.	필요한 얼굴만 들어오도록 화면을 잡습니다.
Execution provider	큼. CPU만으로 하는 라이브가 가장 힘듭니다.	GPU에 맞는 빌드를 설치합니다.
캡처 해상도	보통. 감지와 합성 비용에 영향.	라이브 해상도는 적당히 유지합니다. 내보내기와 다릅니다.
카메라 형식	보통이며 잘 드러나지 않음. 비압축이면 기기 자체가 막힙니다.	Show FPS로 실측 캡처 속도를 확인합니다.
다른 GPU 부하	가변. 게임, 인코더, 브라우저가 같은 장치를 두고 경쟁합니다.	라이브 중에는 GPU를 쓰는 다른 앱을 닫습니다.
발열 제한	점진적. 노트북은 몇 분 뒤 클럭을 낮춥니다.	처음 30초가 아니라 지속 FPS로 판단합니다.

프레임레이트와 지연은 구분하세요. 편안한 프레임레이트에서도 각 프레임이 여러 단계와 버퍼를 거치기 때문에 늦게 느껴질 수 있습니다. 거슬리는 것이 지연이라면 해상도만이 아니라 프레임당 작업량을 줄이세요.

프레임 예산, 캡처 해상도, 기록할 항목

라이브는 튜닝보다 먼저 산수입니다. 프레임당 예산은 목표 프레임레이트로 고정되고, 캡처·감지·배정·교체·선택적 보정·표시가 모두 그 안에 들어가야 합니다.

목표 프레임레이트	프레임당 시간	감지·교체·보정에 남는 시간
15 FPS	66.7 ms	≈ 61 ms
24 FPS	41.7 ms	≈ 37 ms
30 FPS	33.3 ms	≈ 28 ms
60 FPS	16.7 ms	≈ 12 ms

세 번째 열은 캡처와 표시에 약 5ms를 가정한 값입니다. 이는 사용자의 장비에서 측정한 값이 아니라 가정이므로, 사양이 아니라 문제의 구조로 이해해 주세요.

캡처 해상도	프레임당 픽셀	기본값 960 × 540 대비
640 × 360	230,400	0.44×
960 × 540	518,400	1.00×
1280 × 720	921,600	1.78×
1920 × 1080	2,073,600	4.00×

감지와 합성은 프레임의 픽셀 수에, 교체와 보정은 얼굴 수에 비례합니다. 그래서 캡처 해상도를 올리는 것과 사람이 한 명 늘어나는 것은 성격이 다른 비용입니다.

측정할 때 기록할 항목

항목	중요한 이유
운영체제와 빌드 종류	Windows에서 CPU·DirectML·CUDA는 별도 빌드이며 macOS는 아키텍처별로 다릅니다.
Execution provider	가장 큰 단일 요인이며 라이브 보정 가능 여부도 여기서 결정됩니다.
GPU와 드라이버 버전	CUDA 성능은 드라이버·CUDA·cuDNN 호환성에 민감합니다.
캡처 해상도	프레임당 감지와 합성 비용을 결정합니다.
보고된 FPS와 실측 FPS	DirectShow에서는 60 FPS를 내는 카메라가 30으로 보고하는 일이 흔합니다.
프레임 내 얼굴 수	교체와 보정은 얼굴 단위라 작업량이 그대로 배가됩니다.
보정 설정	Off / GPEN-256 / GPEN-512 / GFPGAN은 설계상 얼굴당 비용이 다릅니다.
5분 후 지속 FPS	노트북은 발열로 성능이 떨어집니다. 처음 30초는 실제 수치가 아닙니다.

5. 실제로 쓸 만한 라이브 결과 만들기

라이브는 파일 렌더링보다 관대하지 않습니다. 나쁜 프레임을 나중에 고칠 수 없기 때문입니다. 품질의 대부분은 시작 전에 정해집니다.

• 소스 사진. 선명하고 조명이 고르고 정면에 가깝게. 영상과 같은 기준이지만 라이브에서 더 중요합니다.
• 조명. 뒤의 밝은 창보다 정면의 고른 빛이 낫습니다. 역광은 라이브 교체가 계속 깨지는 가장 흔한 원인입니다.
• 거리와 화면 구성. 얼굴이 너무 작으면 감지가 쓸 정보가 줄어듭니다.
• 움직임. 빠른 고개 돌림과 얼굴을 가로지르는 손이 실패하는 프레임입니다. 의지하기 전에 일부러 시험하세요.
• 좌우 반전. 미리보기를 수평으로 뒤집을 수 있습니다. 본인 동작의 자연스러움에는 영향을 주지만 결과의 기하에는 영향이 없습니다.

카메라에 두 명 이상이 있으면 라이브 배정은 미리 분석한 매핑이 아니라 계속 이어지는 유사도 판단이라 매핑된 영상보다 본질적으로 불안정합니다. 차이는 다중 얼굴 가이드에서 설명합니다.

6. 로컬 미리보기가 할 수 있는 일과 없는 일

분명히 적어 둡니다. 라이브 얼굴 교체 도구에 대해 가장 흔한 오해이기 때문입니다. Deep Face Cam은 라이브 결과를 자체 미리보기 창에 표시합니다. 시스템 수준의 가상 웹캠 장치로 등록되지 않으므로 Zoom, Discord, OBS, 브라우저의 카메라 목록에는 나타나지 않습니다.

다른 애플리케이션 안에서 출력을 쓰려면 별도의 화면 또는 창 캡처 소프트웨어를 거쳐야 하고, 화질·지연·플랫폼 제약이 그대로 따라옵니다. 그 경로를 직접 검증하기 전에는 된다고 전제하지 마세요. 그리고 변형된 카메라 화면을 회의나 본인 확인에서 실제 본인 모습으로 제시하는 것은 책임 있는 사용 정책이 명확히 금지하는 용도입니다.

7. 개인정보: 무엇이 기기에 남고 무엇이 아닌가

“로컬”과 “오프라인”은 같은 주장이 아니며, 그 차이는 라이브 카메라에서 가장 중요합니다.

• 핵심 처리는 기기 안에서. 카메라 프레임, 교체, 미리보기는 본인 기기에서 도는 백엔드가 처리합니다.
• 미리보기는 루프백을 지납니다. 내장 백엔드가 처리된 프레임을 127.0.0.1의 로컬 연결로 앱 창에 전달합니다. 컴퓨터 내부 경로이지 업로드가 아닙니다.
• 모델은 확인 후 한 번만 내려받습니다. 큰 모델 파일은 저장소에 없고, 확인 후 사용자 디렉터리로 내려받아 공개된 체크섬으로 검증합니다.
• 네트워크 사용은 남아 있습니다. 설치 파일, 모델 다운로드, 문서 링크, 업데이트 확인은 네트워크를 씁니다.
• 생성물은 디스크에 남습니다. 모델, 출력, 임시 파일, 설정은 사용자별 앱 데이터 디렉터리에 놓입니다.

같은 주장을 하는 어떤 도구에도 통하는 정직한 권고는 같습니다. 실제로 쓸 빌드를 그대로 시험하고, 첫 모델 다운로드까지 마친 뒤 동작을 확인하고 나서 민감한 소재에 쓰세요. 개인정보 관련 설명을 참고하세요.

라이브 문제 해결

증상	가능한 원인	확인할 것
카메라가 열리지 않음	다른 앱이 장치를 점유했거나 백엔드가 맞지 않음.	다른 카메라 앱을 닫습니다. Windows에서는 DirectShow → Media Foundation → 일반 순으로 폴백합니다.
캡처 속도가 매우 낮음	카메라가 비압축 형식으로 연결됨.	Show FPS를 켜고 카메라 공칭 프레임레이트와 비교합니다.
라이브에서 보정을 고를 수 없음	실행 환경이 CUDA도 DirectML도 아님.	provider를 확인합니다. 이미지와 영상 내보내기에서는 보정이 동작합니다.
고개를 돌리면 얼굴이 빠짐	정면에서 크게 벗어난 얼굴을 감지하지 못함.	조명과 구도를 개선하고 사용 전에 동작 범위를 시험합니다.
엉뚱한 사람에게 얼굴이 붙음	라이브 배정은 프레임 단위 유사도 판단.	화면에 나오는 인원을 줄이거나 파일 작업을 씁니다.
몇 분 뒤 FPS가 떨어짐	발열로 인한 클럭 저하.	처음 몇 초가 아니라 지속 프레임레이트로 측정합니다.
첫 실행만 훨씬 느림	모델 로딩과 Apple 실리콘의 CoreML 캐시 생성.	한 번 예열한 뒤 측정합니다.

자주 묻는 질문

실시간 얼굴 교체에 GPU가 필요한가요?

CPU로도 파이프라인은 돌지만, 프레임당 시간 예산이 고정된 라이브에서 가속이 가장 크게 작용합니다. Windows에 CPU·DirectML·CUDA 빌드가 따로 있는 이유이며, Apple 실리콘에서는 CoreML provider를 씁니다.

Zoom, Discord, OBS의 카메라로 쓸 수 있나요?

직접은 안 됩니다. 결과는 앱 자체 미리보기 창에 표시되고 시스템 가상 카메라 장치로 등록되지 않으므로 다른 앱의 카메라 입력 목록에 나타나지 않습니다.

라이브 FPS가 카메라 공칭값보다 낮은 이유는?

캡처는 첫 단계일 뿐이기 때문입니다. 감지, 배정, 교체, 선택적 보정, 표시가 같은 프레임 예산에 들어가야 하고 가장 느린 단계가 속도를 정합니다.

라이브에서는 어떤 해상도가 좋나요?

내보내기보다 낮게. 기본값은 960×540 캡처를 목표로 하며 미리보기 작업점으로 합리적입니다. 실시간 경로에 4K를 넣을 이점은 없습니다.

라이브 얼굴 교체가 카메라 화면을 전송하나요?

핵심 처리는 본인 기기에서 실행되고 미리보기는 로컬 루프백 연결을 지납니다. 확인된 모델 다운로드와 링크에는 네트워크를 쓰므로 실제 설치한 빌드의 동작을 확인하세요.

두 사람이 동시에 쓸 수 있나요?

가능하지만 배정이 미리 분석한 매핑이 아니라 매 프레임 유사도로 정해지므로 매핑된 영상 렌더링보다 불안정합니다. 미리보기로 다루세요.

관련 가이드

• GFPGAN과 GPEN, 어떤 얼굴 보정을 쓸까
• 영상에서 여러 명의 얼굴을 바꾸는 방법
• PC와 Mac에서 영상 얼굴을 로컬로 바꾸는 방법
• PC와 Mac용 로컬 얼굴 교체 프로그램
• 업로드 없이 GIF 얼굴을 로컬에서 바꾸는 방법
• Deep Face Cam 소스 저장소
• 개인정보 관련 설명