webassembly

모든 디스코드 (새 탭에서 열림)

Discord가 음성 및 영상 통화의 종단간 암호화(E2EE)를 구현하는 'DAVE' 프로토콜을 브라우저, 콘솔, Social SDK를 포함한 모든 플랫폼으로 확대 적용합니다. 2026년 3월 1일부터는 DAVE를 지원하지 않는 클라이언트나 앱의 통화 참여가 전면 제한되며, 이를 통해 Discord의 모든 통화 환경에서 E2EE가 필수 표준으로 자리 잡게 됩니다. 이번 업데이트는 실험적 도입 단계를 넘어 전 플랫폼에 걸친 보안 표준화를 완성하려는 Discord의 핵심 전략을 담고 있습니다. **웹 브라우저 통합을 위한 기술적 도전** * WebAssembly(Wasm) 성능 최적화: 브라우저 환경에서 암호화 연산을 효율적으로 처리하기 위해 고성능 Wasm을 활용했습니다. * Web Worker 기반 아키텍처: 메인 스레드의 성능 저하를 방지하고 안정적인 통화 품질을 유지하기 위해 암호화 로직을 별도의 워커에서 실행하도록 설계했습니다. * 성능과 보안의 균형: 웹 플랫폼의 제약 조건 내에서 보안 수준을 유지하면서도 사용자 경험을 해치지 않는 최적의 트레이드오프(Trade-off)를 도출했습니다. **지원 중단 일정 및 호환성 확보** * 2026년 3월 1일 데드라인: 해당 날짜를 기점으로 DAVE 프로토콜을 지원하지 않는 구형 클라이언트 및 앱의 접속이 차단됩니다. * 표준화 가속화: 기존의 비-E2EE 통화 방식을 완전히 폐기함으로써 보안 사각지대를 없애고 단일화된 보안 프로토콜 체계를 구축합니다. * 개발자 대응 요구: Social SDK를 사용하여 통화 기능을 구현한 개발자들은 서비스 중단을 막기 위해 정해진 기한 내에 호환성을 검토해야 합니다. Discord 생태계에서 음성 및 영상 기능을 활용하는 사용자와 개발자는 2026년 3월 이전까지 반드시 최신 버전의 SDK와 클라이언트로 업데이트해야 합니다. 특히 커스텀 앱이나 서드파티 도구를 운영 중인 개발자라면 Discord가 제공하는 기술 문서를 참고하여 DAVE 프로토콜로의 마이그레이션을 서둘러 준비할 것을 권장합니다.

Rust의 메모리 최적화 (새 탭에서 열림)

Figma는 파일 로드 속도를 혁신적으로 개선하기 위해 전체 파일을 한 번에 불러오는 방식에서 사용자가 현재 보고 있는 페이지만 불러오는 '페이지 단위 온디맨드 로딩' 방식으로 전환했습니다. 이 과정에서 메모리 사용량을 최적화하고 복잡한 동기화 메커니즘을 재설계하여, 특히 대규모 프로젝트에서의 초기 로딩 시간을 최대 50%까지 단축했습니다. 이는 협업 기능을 온전히 유지하면서도 효율적인 자원 관리를 통해 사용자 경험을 극대화한 기술적 성과입니다. **기존 모놀리식 로딩 방식의 한계** * 이전의 Figma는 파일 내 모든 페이지의 데이터를 초기 로딩 시점에 메모리에 전부 적재하는 방식을 사용했습니다. * 파일 규모가 커질수록 로딩 시간이 기하급수적으로 늘어났으며, 브라우저의 메모리 제한으로 인해 대형 파일 실행 시 충돌(Crash)이 발생하는 주요 원인이 되었습니다. * 사용자가 특정 페이지만 작업하더라도 당장 보지 않는 수십 개의 페이지 데이터를 모두 다운로드하고 해석해야 하는 비효율이 존재했습니다. **페이지 단위 온디맨드 로딩 도입** * 파일 저장 구조를 수정하여 각 페이지 데이터를 독립적인 단위로 분리하고, 사용자가 해당 페이지를 클릭할 때만 서버에서 데이터를 가져오도록 변경했습니다. * 초기 로딩 시에는 파일의 전체 구조(페이지 목록, 레이어 트리 등)와 사용자가 마지막으로 머물렀던 페이지만 로드하여 '유효 로딩 시간(Time to Interactive)'을 대폭 줄였습니다. * 페이지 전환 시 지연을 최소화하기 위해 백그라운드에서 데이터를 미리 가져오거나 스트리밍하는 최적화 기법을 적용했습니다. **기술적 난제와 동기화 엔진의 재설계** * Figma의 핵심인 실시간 협업(Multiplayer) 기능을 유지하기 위해, 현재 로드되지 않은 페이지에서 다른 사용자가 수행하는 변경 사항을 추적하고 병합하는 복잡한 로직을 구현했습니다. * C++로 작성된 엔진(Wasm)이 메모리에 없는 데이터에 접근하려 할 때 발생하는 오류를 방지하기 위해 데이터 접근 방식을 프록시화했습니다. * 전체 데이터를 다루던 기존 인덱싱 구조를 부분 로딩 모델에 맞게 재설계하여 데이터 일관성을 보장했습니다. **성능 개선 및 안정성 확보** * 로딩 전략 수정 후 대규모 파일의 초기 로드 속도가 이전 대비 약 30~50% 향상되는 결과를 얻었습니다. * 메모리 사용량을 획기적으로 낮춤으로써 저사양 기기에서의 안정성을 확보하고, 브라우저의 메모리 부족으로 인한 앱 종료 현상을 크게 줄였습니다. * 점진적인 롤아웃과 모니터링을 통해 대규모 데이터 마이그레이션 과정에서 발생할 수 있는 데이터 손실 위험을 성공적으로 관리했습니다. 대규모 데이터를 다루는 웹 애플리케이션에서 초기 로딩 속도와 메모리 관리는 서비스의 생존과 직결됩니다. Figma의 사례처럼 데이터 구조를 세밀하게 파편화하고 '필요한 순간에만 로드'하는 지연 로딩(Lazy Loading) 전략을 시스템 심층부(엔진 레벨)부터 설계하면, 확장성과 사용자 만족도를 동시에 잡을 수 있습니다.

피그마의 TypeScript (새 탭에서 열림)

피그마(Figma)는 자사의 모바일 렌더링 엔진의 핵심 언어였던 자체 개발 언어 'Skew'를 산업 표준인 TypeScript로 완전히 전환하는 데 성공했습니다. 과거 성능 최적화를 위해 도입했던 Skew가 팀 규모 확장에 따라 생산성 저해와 생태계 부재라는 한계에 부딪히자, 피그마는 일상적인 개발 흐름을 방해하지 않으면서도 자동화된 마이그레이션을 완수했습니다. 결과적으로 피그마는 성능 손실 없이 더 나은 개발 환경과 최신 JavaScript 생태계의 이점을 누릴 수 있게 되었습니다. ### 자체 개발 언어 Skew의 도입과 한계 * **성능 중심의 탄생:** 초기 피그마는 웹과 모바일 모두에서 프로토타입 뷰어를 구현하기 위해 Skew를 개발했습니다. 당시 Skew는 정적 타이핑과 더불어 상수 폴딩(constant folding), 가상 함수 호출 최적화(devirtualization) 등 고급 컴파일러 최적화를 통해 JavaScript보다 뛰어난 성능을 제공했습니다. * **확장의 걸림돌:** 하지만 팀이 커지면서 Skew는 신규 입사자의 적응을 어렵게 만들고, 린터(linter)나 정적 분석기 같은 현대적인 개발 도구 생태계를 활용할 수 없다는 단점이 부각되었습니다. * **기능의 부재:** async/await와 같은 현대적인 JavaScript 기능이 부족했고, 피그마 내부의 다른 코드베이스와 통합하는 데에도 높은 비용이 발생했습니다. ### TypeScript 전환이 가능해진 기술적 배경 * **WebAssembly(Wasm)의 보편화:** 2018년 이후 모바일 브라우저에서 WebAssembly 지원이 확대되었고, 2020년경에는 모바일에서도 안정적인 성능을 발휘하게 되었습니다. * **C++ 엔진으로의 교체:** Skew로 작성되었던 파일 로딩 등 핵심 성능 경로를 WebAssembly로 컴파일되는 C++ 엔진으로 대체함으로써, 나머지 로직을 TypeScript로 전환하더라도 전체 성능에 미치는 영향이 미미해졌습니다. * **팀 규모의 성장:** 개발 경험(DX) 개선에 전념할 수 있는 리소스를 확보할 만큼 팀이 성장하면서 자동화된 마이그레이션 도구 개발이 가능해졌습니다. ### 안전한 전환을 위한 3단계 자동화 프로세스 * **1단계 (Skew 작성, Skew 빌드):** 기존 빌드 프로세스를 유지하면서 Skew 코드를 TypeScript로 변환하는 트랜스파일러를 개발했습니다. 변환된 TypeScript 코드를 깃허브에 체크인하여 개발자들이 미래의 코드 모습을 확인할 수 있게 했습니다. * **2단계 (Skew 작성, TypeScript 빌드):** 개발자는 여전히 Skew로 코드를 짜지만, 실제 프로덕션 빌드는 트랜스파일러를 거친 TypeScript 코드로 진행했습니다. 이 과정에서 유닛 테스트를 통과시키고 타입 오류를 점진적으로 수정하며 안정성을 확보했습니다. * **3단계 (TypeScript 작성, TypeScript 빌드):** 특정 시점에 Skew 코드 생성을 중단하고 모든 Skew 소스 파일을 삭제했습니다. 이후 모든 개발자는 TypeScript를 직접 작성하게 되었으며, CI/CD 파이프라인도 TypeScript 기반으로 완전히 전환되었습니다. ### 실용적인 결론 및 시사점 피그마의 사례는 서비스 초기 성능을 위해 도입한 커스텀 기술이 성숙기에는 오히려 부채가 될 수 있음을 보여줍니다. 특히 대규모 코드베이스를 전환할 때는 **'점진적인 롤아웃'**과 **'자동화된 트랜스파일링'**이 핵심입니다. Skew와 TypeScript 간의 시맨틱 차이(예: 네임스페이스 초기화 순서 등)로 발생할 수 있는 런타임 오류를 방지하기 위해, 자체 컴파일러를 수정하여 제어권을 확보한 점은 기술적 난관을 극복한 훌륭한 전략으로 평가됩니다.

피그마가 게임 세계에서 (새 탭에서 열림)

피그마는 단순한 웹 애플리케이션을 넘어 고성능 게임 엔진과 유사한 기술적 아키텍처를 기반으로 구축된 창의적 협업 도구입니다. 이 글은 피그마가 실시간 멀티플레이어 시스템, 물리 기반 애니메이션, 그리고 C++와 WebAssembly, Rust와 같은 고성능 스택을 통해 어떻게 디지털 세계를 구축하는지 설명합니다. 결과적으로 피그마는 게임 개발의 복잡한 시스템 상호작용 원리를 차용하여 사용자들에게 몰입감 있고 매끄러운 디자인 경험을 제공하고 있습니다. ## 디지털 세계를 구축하는 엔진으로서의 피그마 * 피그마의 핵심은 웹 기반의 2D 그래픽 및 렌더링 시스템으로, 이는 마인크래프트와 같은 게임 엔진의 근간과 동일한 구조를 가집니다. * 사용자가 생성하는 모든 텍스트, 도형, 선을 브라우저에서 실시간으로 구현하며, 방대한 캔버스에서의 팬(pan)과 줌(zoom) 조작 시에도 정확한 위치에 객체를 렌더링합니다. * 실시간 동시 편집 기능을 게임의 개념에서 착안한 '멀티플레이어(multiplayer)' 엔진이라고 명명하여 협업의 핵심 시스템으로 발전시켰습니다. * 브라우저 및 모바일 앱의 메모리와 성능 제약을 극복하기 위해 일반적인 웹 스택 대신 C++로 캔버스를 구축한 후 WebAssembly로 컴파일하여 로딩 속도를 3배 개선했으며, 서버 측 성능 향상을 위해 Rust 언어를 도입했습니다. ## 시스템 기반의 창의적 협업과 상호작용 * 게임 스튜디오에서 엔지니어와 아티스트가 협업하듯, 피그마 엔지니어들은 시스템의 한계를 밀어붙이기 위해 디자이너, PM, 데이터 과학자들과 긴밀하게 소통합니다. * '젤다의 전설: 브레스 오브 더 와일드'의 불(fire) 시스템이 빛, 온기, 공격 수단 등 다양한 방식으로 상호작용하는 것처럼, 피그마의 오토세이브, 멀티플레이어, 렌더링 시스템도 서로 유기적으로 연결되어 작동합니다. * 단순한 도구 기능을 넘어 스프링 물리 법칙을 적용한 애니메이션 시스템, 커서 채팅, 하이파이브 기능 등을 통해 사용자가 도구 내에서 살아있는 피드백을 느낄 수 있도록 설계했습니다. * 베리언트(Variants) 기능과 플러그인/위젯 시스템을 통해 디자인 컴포넌트와 코드를 긴밀하게 연결하고, 사용자가 직접 생태계를 확장할 수 있는 개방형 플랫폼을 지향합니다. 웹 환경에서 복잡하고 성능 집약적인 도구를 개발해야 한다면, 전통적인 웹 프레임워크의 틀을 벗어나 게임 엔진의 설계 방식과 고성능 언어(WASM, Rust) 도입을 검토해야 합니다. 기술적 한계를 극복하는 열쇠는 도구를 하나의 살아있는 '시스템'들의 집합으로 바라보고, 각 요소 간의 상호작용이 사용자 경험에 미치는 영향을 정교하게 설계하는 데 있습니다.