OBS로 튜토리얼이나 소프트웨어 사용법을 녹화하다 보면 촬영할 때는 충분히 선명해 보였는데 실제 시청자는 어디를 클릭했는지 잘 보지 못하는 문제가 자주 생깁니다.

특히 2K나 4K 화면에서 toolbar, sidebar, floating panel을 한 화면에 많이 띄우는 경우 영상이 압축되면 작은 버튼과 mouse 위치를 따라가기 어려워집니다.

제가 좋아하는 해결 방법은 편집 단계에서 매 구간마다 keyframe을 추가하는 것이 아니라 OBS 안에서 부분 확대 + 마우스 추적을 처리하는 것입니다. 녹화할 때부터 화면이 현재 작업 위치로 자연스럽게 시선을 유도하므로 software tutorial, 지식 공유, 화면 녹화 콘텐츠에서 효과가 큽니다.

버전 선택: Python vs Lua

처음 이 방식을 접한 것은 angeldeejay/obs-zoom-to-mouse 프로젝트였습니다. OBS source를 확대하고 mouse가 이동하면 확대 영역이 천천히 따라가는 구조입니다. scene을 자주 바꾸거나 촬영 후 많은 구간을 다시 편집할 필요가 줄어듭니다.

다만 지금 처음 설치한다면 예전 Python 버전을 굳이 고집하지 않는 편이 좋습니다. 기존 repository에서도 script가 적극적으로 유지보수되지 않는다고 안내하고 있으며 BlankSourceCode/obs-zoom-to-mouse Lua 버전을 우선 고려하도록 권합니다.

신규 사용자는 Lua 버전이 보통 더 단순합니다. 별도의 Python runtime을 맞추는 과정이 줄고 cross-platform 환경에서도 접근하기 쉽습니다. 반면 오래된 tutorial이나 기존 설정을 이미 갖고 있다면 Python 버전의 설치와 실패 지점을 이해해 두는 것도 여전히 도움이 됩니다.

먼저 이해하기: 줌의 움직임이 관건

이 기능의 가장 큰 가치는 화면을 화려하게 만드는 것이 아니라 시청자가 덜 노력하게 하는 것입니다. 전체 화면 녹화에서 문제는 해상도보다 정보가 너무 많다는 데 있을 때가 많습니다. 작은 글씨와 버튼이 묻히고, 설명하면서 메뉴를 빠르게 이동하면 시청자의 시선이 mouse를 따라가지 못합니다.

부분 확대가 자연스럽게 들어가면 복잡한 편집 없이도 현재 조작 영역이 훨씬 명확해집니다.

중요한 것은 “줌이 있느냐”보다 줌이 어떻게 움직이느냐입니다. 너무 빠르게 확대되거나 mouse가 조금만 움직여도 카메라가 계속 따라다니면 화면이 흔들리는 것처럼 느껴져 오히려 피로해집니다.

저는 이런 script를 “효과”보다 가벼운 camera control이라고 생각하는 편이 좋다고 봅니다. 목적은 화려함이 아니라 시청자가 현재 작업 지점을 안정적으로 보게 하는 것입니다.

Python 버전 설치 단계

Python 버전을 사용한다면 일반적인 OBS script loading 순서를 따릅니다. 먼저 올바른 Python environment에 dependency를 설치합니다.

python -m pip install -r requirements.txt

또는:

python3 -m pip install -r requirements.txt

그다음 OBS의 도구 -> 스크립트에서 Python path를 dependency를 설치한 environment로 맞추고 zoom_and_follow_mouse.py를 추가한 뒤 확대할 source를 선택합니다.

여기서 가장 자주 실패하는 이유는 설치 명령이 아니라 OBS가 사용하는 Python interpreter와 pip를 실행한 Python이 서로 다른 것입니다. dependency를 설치했는데 OBS가 module을 찾지 못한다면 먼저 이 경로를 확인하는 편이 좋습니다.

대략적인 설정 화면에서는 줌 배율, 추적 속도, 경계 범위를 조정할 수 있습니다.

튜닝: 단축키, 파라미터와 흔한 함정

빠르게 쓰기 시작하려는 목적이라면 저는 Lua 버전을 먼저 권합니다. “runtime부터 맞춘 뒤 녹화한다”보다 “script를 설치하고 바로 움직임을 조정한다”에 가까운 흐름이기 때문입니다.

Python이든 Lua든 실제로 시간을 써야 하는 것은 설치보다 hotkey와 움직임 파라미터입니다.

hotkey는 보통 설정 -> 단축키에서 지정합니다. 최소한 줌 on/off와 follow on/off 정도는 접근하기 쉬운 조합으로 두는 편이 좋습니다. 튜토리얼을 녹화하면서 설명하고 화면을 조작하고 진행 속도까지 관리해야 하므로 복잡한 hotkey는 오히려 흐름을 끊습니다.

체감에 가장 영향을 주는 값은 대략 다음과 같습니다.

Zoom Factor      확대 배율
Zoom Speed       확대/축소 애니메이션 속도
Follow Speed     추적 속도
Follow Border    추적을 시작하는 경계 범위
Lock Sensitivity 잠금 민감도

처음부터 “효과가 크게 보이게” 만드는 것보다 시청자가 피곤하지 않게 만드는 것을 먼저 목표로 잡는 편이 좋습니다.

줌 배율이 너무 크면 세부는 잘 보이지만 화면 전체에서 현재 위치를 잃기 쉽습니다. follow speed가 너무 빠르면 카메라가 mouse에 끌려다니는 느낌이 납니다. border가 너무 넓으면 작은 mouse 움직임에도 화면이 계속 흔들립니다.

편안한 상태는 대부분의 시간에는 화면이 안정적이고, 실제로 가장자리 작업 영역으로 이동하거나 시선을 다른 곳으로 옮겨야 할 때만 부드럽게 따라오는 정도입니다.

실제 부분 확대가 어떤 느낌인지 보는 preview도 도움이 됩니다.

또 자주 놓치는 문제는 어떤 source를 확대하고 있는가입니다.

Display Capture는 script가 canvas에서 source의 실제 위치와 크기를 이해하기 쉬워 상대적으로 단순합니다. 하지만 crop된 window, 복제한 source, 이미 scale과 transform이 적용된 source를 확대하면 mouse coordinate와 zoom 영역이 어긋날 수 있습니다.

이때 script 자체가 고장났다고 생각하기 쉽지만 실제로는 안정적인 source coordinate relationship을 얻지 못한 경우가 많습니다.

그래서 이 방식은 특히 desktop tutorial recording에 잘 맞습니다. software UI, 관리자 화면, website 사용법, 코드 설명처럼 하나의 화면을 따라가는 콘텐츠에서는 매우 자연스럽습니다. 반대로 scene 안에 변형된 source, nested source, crop source가 많이 쌓여 있다면 source 위치와 크기를 맞추는 작업이 더 필요합니다.

예전 Python 방식에서 여러 source에 서로 다른 줌 control이 필요하다면 한 script에 모든 logic을 억지로 넣기보다 script file을 복사해 source와 hotkey를 따로 연결하는 단순한 방법이 더 안정적일 수도 있습니다. 콘텐츠 제작에서는 구조의 우아함보다 녹화 중 안정성이 더 중요할 때가 많습니다.

이 기능은 화려한 transition을 원하는 채널보다 업데이트 빈도가 높고 후반 편집 부담을 줄이고 싶은 tutorial creator에게 특히 잘 맞습니다. 촬영 단계에서 시청자의 시선을 이미 안내하면 나중에 매 장면마다 줌 keyframe을 다시 만들 필요가 줄어듭니다.

제 기준은 단순합니다.

• 새로 시작한다면 Lua 버전부터 확인
• 기존 Python 설정이 있다면 interpreter, source, hotkey부터 점검
• 줌 배율보다 안정적인 움직임을 우선
• “잘 보인다 / 덜 흔들린다 / 현재 작업 위치가 명확하다”를 먼저 만족

이 세 가지가 맞으면 복잡한 후반 작업 없이도 튜토리얼 영상의 시청 경험이 꽤 좋아집니다.