Electron용 BrowserView 소개 | Figma 블 (새 탭에서 열림)
Figma는 Electron에서 원격 웹 앱을 임베드할 때 사용하던 `<webview>`의 성능·안정성 문제를 해결하기 위해 `BrowserView`를 개발했다. `BrowserView`는 DOM 계층이 아닌 운영체제 창 계층에서 웹 콘텐츠를 관리해 Chrome 탭에 가까운 성능과 안정성을 제공한다. 다만 HTML/CSS 기반의 자동 배치와 레이어링을 사용할 수 없어 위치와 겹침을 직접 관리해야 하며, Figma는 이를 데스크톱 앱 2.0에 적용했다. ## Electron과 Figma의 웹 기반 데스크톱 전략 - Figma는 접근성이 뛰어난 웹을 주요 플랫폼으로 선택했다. - 파일 공유가 링크 하나로 가능하다는 점이 큰 장점이다. - 웹 앱의 성능을 네이티브 애플리케이션 수준으로 끌어올리기 위해 다음 기술을 활용했다. - WebGL 기반 캔버스 렌더링 - WebAssembly를 통한 앱 로딩 시간 개선 - 데스크톱 앱에는 웹 기술로 크로스플랫폼 애플리케이션을 만들 수 있는 Electron을 사용했다. - Figma는 Electron의 성능과 버그를 개선하기 위해 Chromium 및 Electron 프로젝트에도 지속적으로 기여했다. ## `<webview>` 기반 임베딩의 한계 - Electron 창에서 원격 웹 앱을 삽입하는 기존 표준 방식은 `<webview>`였다. - `<webview>`는 `<iframe>`과 유사하지만, 콘텐츠를 별도 프로세스에서 렌더링한다. - 일반 iframe보다 성능, 보안, 안정성 측면에서 유리하다. - 그러나 Figma가 실제 사용 과정에서 다음 문제를 겪었다. - 드래그 앤 드롭 같은 기본 기능의 버그 - Chrome에 미치지 못하는 전반적인 성능 - 시간이 지날수록 증가하는 호환성과 안정성 문제 - `<webview>`는 Chromium 내부에서 구현되므로 Electron 측에서 직접 근본 문제를 해결하기 어려웠다. - Chromium을 크게 수정하는 것은 현실적으로 부담이 크기 때문에, Electron 팀과 Figma는 `<webview>`를 우회하는 대안을 선택했다. ## `BrowserView`의 구조와 장점 - `BrowserView`는 웹 콘텐츠를 DOM 계층에 포함하지 않고 운영체제의 창 계층에 배치한다. - 구조적으로 Chrome이 브라우저 탭을 관리하는 방식과 유사하다. - 이 방식의 장점은 다음과 같다. - `<webview>`에 특화된 버그를 상당 부분 피할 수 있다. - Chrome 탭과 동일한 렌더링 경로를 활용해 웹 앱이 Chrome 수준의 속도로 동작한다. - Chrome에서 중요하게 취급되는 창·탭 관련 문제를 더 빠르게 수정할 수 있다. - 결과적으로 Electron 앱 안에서 원격 웹 앱을 더 빠르고 안정적으로 실행할 수 있다. ## 레이아웃과 레이어링의 trade-off - `BrowserView`는 DOM 요소가 아니므로 일반적인 HTML/CSS 레이아웃 기능을 사용할 수 없다. - CSS의 위치 지정 - DOM 기반의 자동 크기 조정 - 요소 간 z-index 및 레이어링 - 애플리케이션이 직접 다음 작업을 처리해야 한다. - 각 `BrowserView`의 위치와 크기 계산 - 여러 뷰의 겹침 순서 관리 - 창 크기 변경에 따른 수동 레이아웃 갱신 - 복잡한 위치 배치나 레이어 구성이 핵심인 애플리케이션에서는 이 제약이 큰 단점이 될 수 있다. - 반면 Figma처럼 구조가 비교적 명확한 앱에서는 전환 작업이 충분히 실용적이었다. ## 출시와 향후 계획 - `BrowserView`는 당시 최신 Electron 베타 버전에 실험적 API로 포함됐다. - Figma는 이를 적용한 Figma Desktop 2.0을 출시했다. - Figma는 Electron과 BrowserView가 아직 완벽하지 않지만 빠르게 발전하고 있다고 평가했다. - 다른 기업과 개발자들도 Electron 개선에 참여하고 있으며, Figma는 더 많은 앱이 BrowserView로 이전하기를 기대했다. 실용적으로는 원격 웹 앱을 Electron에 임베드하면서 `<webview>`의 성능이나 버그가 문제가 된다면 `BrowserView`를 검토할 수 있다. 다만 도입 전 수동 레이아웃과 레이어링 구현 부담, 당시 실험적 API라는 안정성 문제를 함께 평가해야 한다.