webassembly

19 개의 포스트

figma3분 읽기큐레이션 요약

팀을 Figma로 전환하도록 설득

Figma 도입은 단순히 디자인 도구를 바꾸는 일이 아니라, 디자인을 조직 내 협업과 의사결정의 중심으로 끌어오는 문화적 변화다. Buffer의 James Morris는 전사 탐색 기간을 마련하고, 실제 화이트보딩과 엔지니어 협업을 통해 구성원들이 Figma의 가치를 직접 경험하게 했다. 클라우드 기반의 공유성, 플랫폼 독립성, 실시간 협업, 개발자용 디자인 데이터 제공이 전환의 핵심 동력이었다. ## 디자인 도구가 협업을 가로막은 문제 - Buffer는 투명성을 중시하는 조직이었지만, 기존 디자인 도구는 디자인팀을 다른 부서와 분리했다. - 디자인 파일이 Dropbox의 깊은 하위 폴더에 묻혀 필요한 자료를 찾기 어려웠다. - 파일을 열려면 특정 데스크톱 소프트웨어나 최신 버전, 유료 라이선스가 필요했다. - 개발자와 PM은 실수로 원본을 덮어쓸까 봐 파일을 열기조차 꺼렸다. - Linux를 사용하는 엔지니어는 디자인 파일을 보기 위해 Mac을 구매해야 할 수도 있었다. ## Figma가 제공한 협업 방식 - 클라우드에서 실행되므로 파일을 URL 하나로 공유할 수 있다. - 무료 보기 전용 계정을 통해 누구나 디자인을 확인하고 댓글을 남길 수 있다. - 디자이너와 개발자, PM이 동일한 파일을 보며 소통할 수 있다. - 디자인 파일이 특정 운영체제나 데스크톱 애플리케이션에 종속되지 않는다. - 하나의 공유 URL이 디자인의 기준점이 되어, 이미지로 내보내거나 Dropbox 경로를 설명할 필요가 줄어든다. ## 1단계: 전사적인 탐색 기간 마련 - James는 처음부터 Figma 도입을 강요하지 않고, 회사 전체에 ‘탐색 기간’을 제안했다. - 각 팀이 여러 디자인·협업 도구를 직접 사용해 보고 자신들의 요구에 맞는 도구를 평가하도록 했다. - 이 과정에서 Buffer의 업무 흐름과 협업 문제에 대한 구성원들의 피드백을 수집했다. - Figma의 장점을 일방적으로 주장하기보다, 실제 사용을 통해 기능이 증명되도록 했다. ## 2단계: 설명보다 직접 경험하게 하기 ### PM과의 원격 화이트보딩 - 원격 근무 환경에 맞춰 PM과 Figma에서 실시간 가상 화이트보딩을 진행했다. - 문서에 글을 쓰는 대신 도형을 사용해 기능 아이디어와 협업 방식을 함께 구상했다. - 별도의 공식 기획서가 완성될 때까지 기다리지 않고, 디자이너와 PM이 즉시 아이디어를 시각화할 수 있었다. - Figma의 직관성과 실시간 협업 기능을 자연스럽게 체험하게 한 사례다. ### 엔지니어 설득 - 개발자들에게 장황하게 설명하는 대신 파일 URL을 전달하고 필요한 정보를 직접 찾아보게 했다. - 무료 보기 전용 기능으로 CSS, iOS용 Swift, Android용 XML 관련 디자인 데이터를 확인할 수 있었다. - 개발자는 별도의 애플리케이션을 설치하거나 라이선스를 구매하지 않고 디자인을 열 수 있었다. - URL이 동일하게 유지되는 ‘단일 진실의 원천(source of truth)’이 되어 디자인 전달과 위치 확인이 쉬워졌다. - Figma가 WebAssembly를 활용해 브라우저 성능을 개선했다는 점도 엔지니어들의 기술적 관심을 끌었다. ### 디자이너의 우려 다루기 - 디자이너는 공개적이고 투명한 디자인 작업 방식에 부담을 느낄 수 있다. - 웹 애플리케이션이 데스크톱 도구만큼 빠르게 작동할지 의심할 수도 있다. - 따라서 디자이너에게는 기능 설명보다 실제 성능과 작업 흐름을 직접 보여 주는 접근이 필요하다. - 글에서 제시된 전략의 핵심은 각 직군이 중요하게 여기는 가치에 맞춰 Figma를 소개하는 것이다. 조직의 도구 전환을 성공시키려면 “새 도구가 더 좋다”고 주장하기보다, 구성원들이 자신의 업무에서 문제 해결 효과를 직접 확인하게 해야 한다. 특히 원격·다직군 협업 환경에서는 공유 가능한 단일 작업 공간과 운영체제에 구애받지 않는 접근성이 도입의 강력한 근거가 된다.

원문 읽기(새 탭에서 열림)
figma3분 읽기큐레이션 요약

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라는 안정성 문제를 함께 평가해야 한다.

원문 읽기(새 탭에서 열림)
figma3분 읽기큐레이션 요약

피그마는 웹어

WebAssembly 도입으로 Figma는 애플리케이션 초기화, 디자인 파일 다운로드, 첫 렌더링을 포함한 전체 로드 시간을 약 3배 단축했다. 특히 C++ 기반 코드를 브라우저에서 실행할 때 asm.js보다 전송·파싱·네이티브 코드 변환·캐싱 측면에서 유리했다. 다만 압축 후 다운로드 크기 감소 효과는 작았고, 당시에는 브라우저별 구현 및 캐싱 지원 차이로 적용 범위가 제한됐다. ## WebAssembly의 특징과 asm.js와의 차이 - WebAssembly는 브라우저 실행을 위해 설계된 바이너리 형식의 머신 코드다. - 기존에는 C++ 코드를 asm.js라는 JavaScript 부분집합으로 변환해 실행했다. - 숫자와 포인터만 사용할 수 있으며, 포인터는 숫자 배열의 인덱스로 표현된다. - DOM 조작이나 네트워크 연결 등 브라우저 기능은 JavaScript를 호출해야 한다. - WebAssembly도 asm.js와 동일한 제약과 브라우저 샌드박스를 공유하지만, 실행 형식이 더 효율적이다. - C++처럼 이미 LLVM으로 최적화된 코드는 브라우저가 별도 최적화를 많이 수행하지 않고 네이티브 코드로 변환할 수 있다. ## WebAssembly가 빠른 이유 - **작은 바이너리 형식** - 동일한 코드의 JavaScript보다 네트워크 전송에 유리하다. - 다만 압축하면 asm.js와 WebAssembly의 크기 차이는 크게 줄어든다. - **빠른 파싱** - 사람이 작성하는 JavaScript에는 문법과 중복 정보가 많다. - WebAssembly는 브라우저가 빠르게 해석하도록 설계되어 asm.js보다 약 20배 빠르게 파싱된다. - **효율적인 네이티브 코드 변환** - LLVM이 사전에 C++ 코드를 최적화하므로 브라우저의 런타임 최적화 부담이 작다. - **변환 결과 캐싱** - 브라우저가 WebAssembly 모듈의 네이티브 코드 변환 결과를 쉽게 캐시할 수 있다. - 같은 애플리케이션을 다시 열 때 변환 시간이 거의 사라질 수 있다. - **64비트 정수 지원** - WebAssembly는 64비트 정수를 직접 지원한다. - JavaScript는 정수 정밀도가 53비트로 제한되어 64비트 정수를 에뮬레이션해야 한다. ## Figma에서의 적용과 성능 개선 - Figma는 C++로 작성된 대규모 2D WebGL 렌더링 엔진을 사용한다. - 측정한 로드 시간에는 다음 과정이 모두 포함됐다. - 애플리케이션 초기화 - 디자인 파일 다운로드 - 디자인의 최초 전체 렌더링 - WebAssembly로 전환한 뒤 문서 크기와 관계없이 로드 시간이 3배 이상 개선됐다. - 큰 디자인 문서를 자주 만들고 전환하는 Figma 사용자에게 특히 큰 효과가 있었다. - 앱을 한 번 실행한 뒤에는 WebAssembly의 네이티브 변환 결과가 캐시되므로, 이후 로드 시간은 애플리케이션 코드 크기에 덜 영향을 받는다. ## 다운로드 크기와 실제 개선의 차이 - WebAssembly로 전환하면 전송 크기도 크게 줄어들 것으로 예상했지만 실제 감소 폭은 작았다. - asm.js 코드도 압축하면 WebAssembly와 비슷한 크기까지 줄어들기 때문이다. - 따라서 Figma에서 가장 큰 이점은 파일 크기 감소가 아니라 파싱, 코드 변환, 캐싱에 따른 실행 및 로드 시간 단축이었다. ## 브라우저 지원의 한계 - 당시 WebAssembly는 Firefox와 Chrome에서 기본 활성화되어 있었다. - Edge와 Safari는 아직 구현 중이어서 브라우저별 지원 상황을 확인해야 했다. - Figma는 Chrome에서도 WebAssembly를 사용할 수 있었지만, 구현상의 문제 때문에 실제로는 Firefox에서만 활성화했다. - 특히 Chrome의 네이티브 변환 코드 캐싱 방식이 Firefox와 달라 페이지를 열 때마다 애플리케이션 전체를 다시 변환해야 하는 문제가 있었다. WebAssembly는 대규모 C/C++ 코드베이스를 웹으로 옮길 때 특히 효과적이다. 단순히 다운로드 용량을 줄이는 기술이라기보다, 빠른 파싱과 네이티브 코드 변환, 실행 결과 캐싱을 통해 초기 로드 시간을 줄이는 기술로 보는 것이 적절하다.

원문 읽기(새 탭에서 열림)
figma4분 읽기큐레이션 요약

웹에서 전문적인 디자인 도구

Figma는 전문 디자이너가 받아들일 수 있는 고품질 편집 경험을 웹 브라우저에서 제공하기 위해, 사실상 “브라우저 안의 브라우저”를 구축했다. 웹 플랫폼의 제한적인 추상화 대신 WebGL·asm.js 같은 저수준 기술을 활용하고, C++ 기반 편집기와 자체 메모리·렌더링 시스템으로 성능과 플랫폼 간 일관성을 확보했다. 특히 Emscripten을 통해 네이티브에 가까운 성능과 예측 가능한 프레임률을 달성하는 것이 핵심 전략이다. ## 웹에서 전문 디자인 도구를 만들기 어려운 이유 - 웹은 원래 문서 표시를 위해 설계되었고, 애플리케이션 개발 기능은 이후 개별 API 형태로 덧붙여졌다. - 따라서 특정 기능은 제공하지만, 개발자가 이를 조합해 새로운 동작을 구현할 수 있는 범용적인 저수준 primitive가 부족하다. - CSS는 복잡한 텍스트 배치 알고리즘을 제공하지만: - 알고리즘을 직접 커스터마이즈하기 어렵고 - 브라우저가 계산한 결과를 읽어 다른 알고리즘에 재사용하기도 어렵다. - 브라우저의 GPU 컴포지터는 고성능이지만: - 렌더링 과정에 직접 개입하기 어렵고 - 사용자 정의 블렌드 모드나 애플리케이션 특화 최적화를 추가할 수 없다. - 이미지 디코더는 하드웨어 가속과 비동기 처리를 지원하지만: - EXIF 방향 정보를 어떻게 처리할지 지정하기 어렵고 - 디스플레이 색 공간을 이미지 데이터에 미리 반영하지 않도록 제어하기 어렵다. - WebGL과 asm.js의 등장으로 개발자가 브라우저에 기능 추가를 기다리지 않고 하드웨어에 가까운 수준에서 필요한 기능을 직접 구현할 수 있게 되었다. ## Emscripten으로 C++ 편집기 실행 - Figma 편집기는 C++로 작성하고 Emscripten으로 JavaScript로 크로스 컴파일했다. - Emscripten은 asm.js를 대상으로 하며, asm.js는 JIT가 예측 가능하고 compact한 기계어를 생성하기 쉬운 JavaScript 부분집합이다. - 이 방식의 장점: - 메모리 배치를 직접 제어할 수 있어 64비트 부동소수점 중심인 JavaScript보다 32비트 float나 byte를 효율적으로 사용할 수 있다. - 객체를 미리 할당한 typed array 영역에 배치해 JavaScript 가비지 컬렉터의 개입을 피한다. - GC 중단으로 인한 프레임 저하를 줄여 60fps 달성에 유리하다. - LLVM 최적화와 C++ 템플릿 특수화를 활용해 네이티브 성능의 약 2배 이내 수준까지 접근할 수 있다. - asm.js에는 일반 JavaScript의 JIT 추론에 따른 deoptimization 지점이 없어 실행 성능이 더 예측 가능하다. ## 대용량 메모리와 브라우저 제약 대응 - Emscripten은 전체 메모리 공간을 하나의 큰 typed array에 담기 때문에 연속된 주소 공간을 충분히 확보해야 한다. - 특히 32비트 Chrome on Windows에서는 ASLR이 주소 공간을 파편화해 256MB typed array조차 할당하지 못하는 문제가 있었다. - Figma는 대형 이미지·기하 버퍼를 주 힙 외부의 별도 typed array에 저장하고, 이를 C++에서 참조하는 `IndirectBuffer` API를 만들었다. - 이 방식은: - 장시간 실행 시 메모리 파편화를 줄이고 - 32비트 브라우저의 제한된 주소 공간을 더 효율적으로 사용하며 - 64비트 브라우저의 31비트 typed array 크기 제한을 우회한다. - 해당 `IndirectBuffer` 구현은 오픈소스로 공개되었다. ## asm.js 이후의 발전 방향 - WebAssembly는 asm.js 코드를 바이너리 형식으로 표현해 JavaScript 파싱 시간을 크게 줄이는 것을 목표로 한다. - 당시 웹의 멀티스레딩은 Web Worker와 메시지 전달 방식에 의존했다. - Shared Typed Array가 도입되면 여러 실행 흐름이 메모리를 공유하는 진정한 공유 메모리 기반 멀티스레딩이 가능해질 것으로 전망했다. ## 자체 렌더링 엔진 - 브라우저의 그래픽 기능을 그대로 사용하는 대신, 콘텐츠를 빠르고 플랫폼 간 일관되게 표시하기 위해 자체 렌더링 엔진을 구현했다. - 이는 브라우저마다 다른 그래픽 구현과 동작 차이를 통제하고, 전문 디자인 도구에 필요한 고성능 렌더링을 직접 최적화하기 위한 선택이다. - 제공된 글 내용은 자체 렌더링 엔진의 필요성을 설명하는 부분에서 끝나므로, 구체적인 렌더링 구조와 최적화 기법은 확인할 수 없다. 브라우저 기반 고성능 그래픽 애플리케이션을 만들 때는 DOM과 일반 JavaScript API만으로 해결하려 하기보다, C++/WebAssembly 계열의 실행 모델과 명시적인 메모리 관리, 자체 렌더링 계층을 고려하는 것이 효과적이다. 특히 60fps가 중요한 편집 도구라면 가비지 컬렉션과 브라우저별 렌더링 차이를 구조적으로 줄이는 설계가 중요하다.

원문 읽기(새 탭에서 열림)