Virmii를 만든 이유: macOS의 제약에서 브라우저 기반 버튜빙으로

시작: macOS에서 mac-avatar-layer 만들기

처음 만든 mac-avatar-layer는 macOS에서 동작하는 가벼운 아바타 호스트였습니다. 큰 게임 엔진을 도입하지 않고, 투명한 아바타를 데스크톱 위에 표시하는 것이 목표였습니다. macOS의 네이티브 창과 그래픽 기능을 직접 다뤄 로컬 애플리케이션 위에 실시간 아바타를 띄우고자 했습니다.

이 프로젝트는 Rust를 중심으로 만든 Live2D 호스트이며, Cubism Core로 모델을 평가하고 자체 Rust/Metal 렌더러로 그립니다. Virmii의 3D VRM 워크스페이스와는 모델 형식과 구현이 다릅니다. 다만 아바타를 어떻게 표시하고 조작할 것인지 고민했던 경험은 Virmii를 설계하는 출발점이 되었습니다.

macOS 네이티브 환경에서 마주한 제약

네이티브 데스크톱 도구를 배포 가능한 제품으로 만들려면 렌더링 외에도 다룰 일이 많습니다. 창 시스템, 권한, 하드웨어별 그래픽 동작, 배포 방식이 사용자 경험에 영향을 줍니다. 개발자의 Mac에서 잘 동작하는 것과 여러 사용자의 환경에서 별다른 설정 없이 동작하는 것은 다른 문제였습니다.

테두리 없는 투명 창을 다른 앱 위에 띄울 때는 창의 높이, 포커스, 클릭 통과 동작을 조정해야 합니다. 화면 캡처와 카메라 입력에는 각각 관련 권한도 필요합니다. 투명 창을 표시하는 것 자체가 곧 화면 녹화 권한을 요구한다는 뜻은 아닙니다. 어떤 기능이 어떤 권한을 사용하는지 구분해 설명해야 했습니다.

Metal에 직접 연결한 렌더러는 macOS에 맞춰 세밀하게 제어할 수 있지만, 그 구현을 그대로 Windows나 Linux에 가져갈 수는 없습니다. 배포 대상과 방식에 따라 앱 서명, 공증, 권한 안내와 업데이트 절차도 검토해야 합니다. 로컬 개발용 실행과 일반 사용자에게 배포하는 절차를 같은 것으로 볼 수는 없습니다.

이런 작업은 네이티브 앱이 잘못된 선택이라는 뜻이 아닙니다. 다만 소규모 개발에서는 아바타 기능을 개선하는 시간과 플랫폼별 실행·배포 환경을 유지하는 시간 사이의 균형을 고민하게 됩니다.

크로스 플랫폼의 어려움: 운영체제마다 다른 창과 그래픽 처리

투명한 실시간 아바타를 여러 운영체제의 데스크톱 위에 표시하려면 각 환경의 차이를 다뤄야 합니다. 공통 라이브러리를 사용하더라도 창 합성, 입력 처리, 캡처 동작까지 모두 같아지지는 않습니다.

• macOS에서는 Cocoa의 NSWindow와 CALayer 같은 창·레이어 기능을 다룹니다.
• Windows에서는 Win32와 DWM을 통한 창·합성 처리, 창 스타일과 메시지 처리를 고려합니다.
• Linux에서는 X11과 Wayland의 창 관리 방식, 사용하는 컴포지터와 지원 프로토콜의 차이를 확인해야 합니다.

그래픽 백엔드도 Metal, Direct3D, Vulkan, OpenGL 등 선택지가 있으며 운영체제와 라이브러리에 따라 사용할 수 있는 구성이 달라집니다. 특정 운영체제가 반드시 하나의 그래픽 API만 사용해야 하는 것은 아니지만, 백엔드와 드라이버 조합별 검증은 여전히 필요합니다.

카메라 입력, 필요한 경우의 오디오 루프백, 창 입력 처리와 업데이트 배포까지 더해지면 유지할 범위가 넓어집니다. Virmii를 구상하면서는 이 차이를 어디까지 직접 책임지고, 어디부터 공통 실행 환경에 맡길지 다시 생각하게 되었습니다.

브라우저를 공통 아바타 실행 환경으로 보기

현대 브라우저는 문서를 읽는 도구를 넘어 실시간 3D 애플리케이션을 실행하는 환경이 되었습니다. WebGL과 WebAssembly 같은 기술을 이용하면 웹페이지 안에서 아바타를 렌더링하고 카메라 입력을 분석할 수 있습니다.

Virmii를 브라우저 중심으로 설계한 이유는 여러 운영체제에서 접근할 수 있는 공통 워크스페이스가 필요했기 때문입니다. 사용자는 Virmii 전용 데스크톱 설치 파일을 받는 대신 URL을 열어 모델을 확인할 수 있습니다. 개발 측면에서도 운영체제별 창 시스템을 모두 직접 구현하는 대신 브라우저가 제공하는 API를 활용할 수 있습니다.

그렇다고 운영체제와 하드웨어의 차이가 사라지는 것은 아닙니다. GPU, 드라이버, 브라우저 버전과 권한 설정에 따라 동작과 성능이 달라집니다. 카메라 사용에는 명시적인 허용이 필요하고, OBS로 방송하려면 OBS도 별도로 준비해야 합니다.

설계의 목표는 모든 환경에서 무조건 같은 성능을 보장하는 것이 아니라, 사용자가 거쳐야 하는 설치와 연결 단계를 줄이고 문제가 생겼을 때 원인을 이해할 수 있게 만드는 것입니다.

실시간 3D를 위한 WebGL, WebGPU, WebAssembly

WebGL은 브라우저에서 GPU를 이용해 3D를 그리는 수단입니다. Virmii의 현재 아바타 뷰어는 three.js, React Three Fiber와 three-vrm을 이용해 VRM 모델을 읽고 표시합니다. 메쉬, 재질, 본과 모델에 준비된 표정 정보를 함께 다룹니다.

WebAssembly는 추적이나 수치 계산처럼 별도의 실행 모듈이 필요한 처리를 웹 환경에 가져오는 데 사용할 수 있습니다. Virmii의 얼굴 추적은 MediaPipe Tasks Vision과 해당 WASM 리소스를 사용합니다. 이것을 아바타의 모든 물리·본·블렌드셰이프 계산이 자체 WebAssembly 엔진에서 실행된다는 의미로 받아들여서는 안 됩니다.

WebGPU는 컴퓨트 셰이더 등 더 새로운 GPU 기능을 제공하는 API입니다. 다만 브라우저와 장치의 지원 여부를 확인해야 하며, 현재 Virmii의 렌더러가 WebGPU 기반이라고 설명할 수는 없습니다. 향후 검토할 기술과 이미 사용하는 구현을 구분하는 것이 중요합니다.

같은 이유로 공유 버퍼를 통한 정점 전달이나 WASM으로 옮긴 계산을 모든 상황의 성능 해법으로 볼 수는 없습니다. 데이터 복사, 메모리 관리, GPU 부하와 페이지의 다른 작업도 함께 측정해야 합니다. 브라우저에서 동작한다는 사실만으로 안정적인 60 FPS나 프레임 저하가 없는 실행이 보장되지는 않습니다.

실제 사용자에게는 기술 이름보다 모델 로딩 실패, 카메라 권한 거부, 추적 중단과 연결 상태를 알아볼 수 있는 안내가 더 중요할 때가 많습니다. 어떤 환경에서 어떤 기능을 사용할 수 있는지 드러내는 것도 런타임 설계의 일부입니다.

Virmii의 설계: 데스크톱 프로토타입에서 웹 워크스페이스로

mac-avatar-layer가 완성된 아바타를 데스크톱에 표시하는 도구에서 출발했다면, Virmii는 캐릭터 준비부터 모델 확인과 방송 출력까지 연결하는 워크스페이스를 목표로 합니다. 네이티브 뷰어를 웹페이지로 옮기는 것만으로는 충분하지 않았습니다.

현재 사용 흐름은 다음과 같습니다.

1. 사용할 권한이 있는 캐릭터 참고 이미지로 3D 아바타 생성을 시작합니다.
2. 생성된 모델을 브라우저에서 확인합니다.
3. 필요한 경우 AI 표정 이미지를 별도로 생성하고 눈·입 표현을 시험합니다.
4. Live Studio에서 카메라 트래킹과 모델 반응을 조정합니다.
5. 비공개 라이브 스테이지 URL을 OBS 브라우저 소스에 연결합니다.
6. 제공되는 VRM 파일을 다운로드하고, 다른 앱에서 사용할 때는 호환성을 확인합니다.

브라우저에서는 GLTFLoader와 VRMLoaderPlugin으로 모델을 불러옵니다. 아바타 표시와 애니메이션은 사용자의 장치에서 실행되지만, 생성·저장·인증 같은 서비스 기능까지 모두 로컬에서 처리되는 것은 아닙니다. 모델 생성 단계와 완성 모델의 실시간 표시 단계를 구분해야 합니다.

방송 연결도 가상 카메라 영상 전송과는 다릅니다. Live Studio에서 계산한 움직임 데이터를 WebRTC 데이터 채널로 스테이지에 전달하고, OBS 브라우저 소스가 모델을 렌더링합니다. 연결 환경에 따라 중계를 거칠 수 있지만, 이 경로가 카메라 원본 영상을 OBS에 보내는 것은 아닙니다.

이렇게 추적을 제어하는 페이지와 아바타를 출력하는 페이지를 나누면, 별도의 Virmii 가상 카메라 드라이버 없이도 OBS 장면에 캐릭터를 넣을 수 있습니다. 방송 중에는 트래킹 페이지를 열어 두어야 하며 비공개 스테이지 URL도 안전하게 관리해야 합니다.

크리에이터의 시작 부담 줄이기

아바타를 준비할 때는 모델링, 텍스처, 리깅, 표정, 파일 형식, 추적과 OBS 설정 등 여러 작업을 만납니다. Virmii는 이 가운데 처음 모델을 만들고 움직임을 확인해 방송 화면으로 보내는 흐름을 한곳에서 이어가려는 시도입니다. 전문적인 제작과 세밀한 수작업을 모두 대신한다는 뜻은 아닙니다.

Virmii에서 생성한 모델에는 별도로 13개의 AI 표정 이미지를 만들 수 있습니다. 이 이미지는 Virmii 미리보기, Live Studio와 OBS 스테이지에서 사용하며 다운로드한 VRM에는 포함되지 않습니다. 직접 업로드한 VRM은 모델의 기존 표정 바인딩을 사용합니다. 자세한 범위는 AI 표정 생성 안내에서 확인할 수 있습니다.

생성과 표정 기능에는 크레딧이나 요금제별 이용 조건이 적용됩니다. 시작 전에 현재 요금제를 확인해야 합니다. 한 번의 생성으로 모든 수정과 방송 준비가 끝난다고 가정해서도 안 됩니다.

브라우저 방식은 설치 단계를 줄여 주지만 장치의 계산 부담을 없애지는 않습니다. 저가형 노트북에서도 사용할 수 있는지는 모델 복잡도, 해상도, 브라우저와 함께 실행하는 게임 등에 따라 달라집니다. 실제 방송 구성으로 녹화해 보고 필요한 경우 설정을 낮추는 과정이 필요합니다.

처음 방송 환경을 준비한다면 버튜버 시작 가이드에서 모델 선택부터 테스트 순서까지 살펴볼 수 있습니다.

브라우저에서 트래킹과 오디오 처리 구분하기

카메라 영상은 민감한 정보입니다. Virmii의 현재 트래킹은 브라우저에서 카메라 프레임을 분석하고, 아바타를 움직이는 데 필요한 머리 방향과 눈·입 등의 값을 계산합니다. 원본 영상 대신 이 움직임 값이 비공개 스테이지에 전달됩니다.

MediaDevices의 getUserMedia()는 사용자가 허용한 카메라나 마이크의 스트림을 얻는 API입니다. Virmii는 여기서 audio: false로 카메라 입력만 요청합니다. 얼굴 추적 결과로 모델의 대응 표현을 움직이며, 마이크 주파수 분석으로 한국어 발음이나 입 모양을 인식하는 기능은 제공하지 않습니다.

Web Audio API의 AudioContext, AnalyserNode, AudioWorklet을 이용해 음성 반응형 아바타를 구현하는 것은 별개의 기술적 선택입니다. 주파수 분석 노드를 연결하는 것만으로 정확한 음소별 립싱크가 완성되는 것도 아닙니다. 이를 현재 Virmii에 구현된 기능으로 소개해서는 안 됩니다. 방송할 목소리는 OBS에서 별도로 설정합니다.

다음은 Virmii의 카메라 요청 조건에 맞춘 최소 예시입니다. 이 코드 자체가 얼굴 추적이나 OBS 연결까지 구현하는 것은 아닙니다.

async function openTrackingCamera() {
  const stream = await navigator.mediaDevices.getUserMedia({
    audio: false,
    video: {
      facingMode: "user",
      width: { ideal: 1280 },
      height: { ideal: 720 },
      frameRate: { ideal: 30, max: 30 }
    }
  });

  return {
    stream,
    stop() {
      stream.getTracks().forEach((track) => track.stop());
    }
  };
}

실제 앱에서는 HTTPS 같은 안전한 컨텍스트, 권한 거부, 카메라 사용 불가, 세션 종료와 스트림 해제도 처리해야 합니다. 요청한 해상도가 실제 장치에서 그대로 선택되는지도 별도로 확인해야 합니다.

아키텍처 비교: 네이티브 앱과 브라우저 실행 환경

두 방식의 차이는 단순한 성능 우열보다 배포, 권한, 장치 접근과 유지보수 범위에 있습니다.

특수한 장치 연결이나 세밀한 로컬 제어가 중요하다면 네이티브 앱이 적합할 수 있습니다. Virmii에서는 접근 방식과 설정 흐름을 통일하는 쪽에 무게를 두었습니다. 브라우저는 그 선택을 뒷받침하는 실행 환경이지, 모든 제약을 없애는 수단은 아닙니다.

Virmii와 열린 웹 아바타의 다음 단계

Virmii를 만든 이유는 특정 운영체제에서만 실행되는 아바타 경험을 웹에서 접근할 수 있는 작업 흐름으로 넓히고 싶었기 때문입니다. 작은 macOS 도구를 만들며 시작한 고민은, 여러 환경에서 같은 URL로 모델을 확인하고 방송에 연결할 수 있는지에 대한 질문으로 이어졌습니다.

VRM과 glTF 같은 공개 형식은 모델을 다른 도구로 옮기는 데 도움이 됩니다. 다만 파일을 다운로드할 수 있다는 것과 서비스 안의 모든 기능이 그대로 이동한다는 것은 다릅니다. AI 표정 이미지처럼 Virmii 안에서 사용하는 요소는 내보낸 VRM의 기능과 구분해 설명해야 합니다.

앞으로도 모델 검증, 표정 설정, 추적 조정과 다른 도구에서의 사용성을 개선하는 방향이 중요합니다. WebGPU 같은 새 기술은 검토할 수 있는 선택지지만, 채택 여부와 성능 효과는 실제 환경에서 확인해야 합니다. 새로운 API를 쓰는 것만큼 지원하지 않는 환경에서 무엇이 가능한지 알려 주는 일도 중요합니다.

실시간 애니메이션, 상태 동기화, 모듈별 구현과 기술 문서를 발전시키려는 방향은 유지하되, 계획을 이미 출시한 기능처럼 소개하지 않으려 합니다. 크리에이터가 설치와 연결 문제에 쓰는 시간을 줄이고, 현재 도구의 가능성과 한계를 이해할 수 있는 워크스페이스를 만드는 것이 목표입니다.

자주 묻는 질문

mac-avatar-layer는 왜 macOS 네이티브 소프트웨어만으로 충분하지 않았나요?

macOS 전용 도구로서의 가치가 없었던 것은 아닙니다. 다만 Metal 렌더러와 네이티브 창 처리에 맞춘 구현을 다른 운영체제로 넓히려면 추가 작업이 필요했습니다. Virmii는 더 넓은 접근성과 모델 준비부터 방송까지의 흐름을 위해 브라우저 중심의 별도 워크스페이스를 선택했습니다.

웹브라우저에서 3D 버튜버 아바타를 부드럽게 움직일 수 있나요?

가능합니다. Virmii는 브라우저에서 3D 모델을 표시하고 카메라 기반 얼굴 추적을 실행합니다. 다만 모델의 복잡도, PC 성능, 브라우저와 함께 실행하는 프로그램에 따라 결과가 달라지므로 고정된 60 FPS나 지연 없는 동작을 보장하지는 않습니다.

Virmii는 기존 네이티브 버튜버 소프트웨어와 무엇이 다른가요?

Virmii 전용 데스크톱 앱 대신 웹 워크스페이스에서 생성 모델 확인, VRM 관리, 트래킹과 OBS용 스테이지를 이용합니다. OBS 연결은 비공개 URL을 브라우저 소스에 넣는 방식입니다. 카메라 권한, 지원 브라우저, PC 자원과 별도의 OBS 설정은 여전히 필요합니다.

저렴한 장비를 쓰는 개인 크리에이터에게도 적합한가요?

사용하려는 모델과 방송 구성으로 먼저 시험해 보는 것이 좋습니다. 전용 Virmii 앱을 설치하지 않아도 된다는 장점은 있지만, 웹에서 실행된다고 GPU와 CPU 부하가 없어지지는 않습니다. 게임·아바타·OBS를 함께 실행해 보고 출력 해상도와 프레임레이트 등을 조정하세요.