iframe

3 개의 포스트

figma

기능 비하인드 (새 탭에서 열림)

Figma는 Community 파일에서 사용자와 제작자가 더 깊이 소통할 수 있도록 일반 댓글과 캔버스 위치에 연결되는 컨텍스트 댓글을 도입했다. 기존 에디터 댓글 기능을 그대로 재사용하는 작업으로 시작했지만, 읽기 전용 파일 뷰어를 양방향 커뮤니케이션 공간으로 바꾸면서 UI·성능·공간 설계 문제가 발생했다. 최종적으로는 사용자가 캔버스를 클릭하면 전체 화면 댓글 보기로 전환하는 방향을 택했다. ## 커뮤니티에 댓글이 필요했던 이유 - Figma Community는 파일과 플러그인을 공유하고 발견하는 공간이었지만, 초기에는 제작자와 사용자 간 직접적인 소통 수단이 부족했다. - 글쓴이는 파일의 프로토타입 시작 프레임 오류를 발견했지만, 제작자에게 연락하기 위해 개인 웹사이트와 트위터를 거쳐 이메일을 찾아야 했다. - 이러한 경험을 개선하려면 단순한 리소스 공유를 넘어 질문, 의견, 피드백을 쉽게 주고받을 수 있어야 했다. - 이를 위해 두 가지 댓글 방식을 구상했다. - **일반 댓글**: 파일 아래 피드 형태로 표시 - **컨텍스트 댓글**: 에디터의 댓글처럼 파일 속 특정 위치에 연결 ## 기존 댓글 기능을 커뮤니티에 적용하며 생긴 문제 - 처음에는 기존 에디터 댓글 UI와 코드를 파일 미리보기에 그대로 덧붙이면 될 것으로 예상했다. - 하지만 다음과 같은 기술적 수정이 필요했다. - 뷰포트 정보를 주고받을 수 있도록 기존 iframe 기반 파일 미리보기 구조를 교체 - 댓글 수가 많아질 때 발생할 수 있는 성능 문제 검토 - 더 큰 어려움은 코드보다 상호작용 설계였다. - 에디터 내부 댓글과 비슷해 보이려면, 읽기 전용 커뮤니티 뷰어에서는 오히려 다른 상호작용을 설계해야 했다. - 기존 Community는 제작자가 콘텐츠를 공개하고 사용자가 이를 소비하는 일방향 구조였지만, 댓글은 사용자에서 제작자로 향하는 새로운 소통 경로를 만들었다. - 특히 컨텍스트 댓글은 일반적인 세로형 댓글 피드와 달리 다음 문제를 해결해야 했다. - 댓글을 디자인의 특정 지점에 고정하는 방법 - 댓글을 보면서 캔버스를 이동하고 탐색하는 방법 - 댓글 기능이 기존의 편안한 읽기 전용 경험을 방해하지 않도록 하는 방법 ## 초기 디자인 탐색과 협업 - 엔지니어링, 디자인, 제품 팀은 개발 과정 내내 긴밀한 피드백 루프를 유지했다. - 정적인 와이어프레임보다 댓글 생성과 캔버스 이동을 보여주는 GIF와 인터랙션 프로토타입을 적극 활용했다. - 여러 시안을 통해 다음과 같은 방향을 탐색했다. - 댓글 피드를 배치할 위치 - 캔버스 미리보기에서 댓글을 확인하는 방식 - 댓글 위치를 이해하기 위한 미니 뷰어와 전체 화면 뷰어 - 구체적인 프로토타입 덕분에 기술적 실현 가능성, UI 예외 상황, 출시 일정에 따라 기능 범위를 빠르게 좁힐 수 있었다. ## 초기 출시를 위한 세 가지 목표 - 사용자가 최대한 빠르고 쉽게 댓글 기능에 진입하도록 해 참여를 유도한다. - 컨텍스트 댓글이 달린 파일 위치를 충분히 크게 보여주어 사용자가 댓글의 의미와 디자인 맥락을 이해하도록 한다. - 출시 일정 안에서 구현 가능하고 지나치게 복잡하지 않은 해결책을 선택한다. ## 전체 화면 기반 컨텍스트 댓글 - 위 목표와 제약을 바탕으로 컨텍스트 댓글은 **전체 화면 보기에서만** 표시하도록 결정했다. - 전체 화면은 댓글이 연결된 디자인 영역을 충분히 확인할 수 있는 공간을 제공한다. - 사용자가 축소된 캔버스를 클릭하면 전체 화면 뷰어로 확장되도록 설계했다. - 반대로 축소된 캔버스에서는 클릭과 패닝을 비활성화해, 일반적인 파일 탐색 경험과 댓글 상호작용이 충돌하지 않도록 했다. - 결과적으로 댓글 기능을 기존 파일 뷰어에 무리하게 끼워 넣기보다, 댓글을 확인하고 위치를 탐색하는 별도의 집중된 경험으로 분리했다. ## 실용적인 시사점 기존 기능을 다른 제품 영역에 재사용할 때는 코드 복사보다 사용 맥락의 차이를 먼저 검토해야 한다. 특히 읽기 전용 화면에 편집기용 상호작용을 도입한다면, 기능 자체보다 진입 방식·공간 배치·탐색 흐름·성능과 같은 전체 사용자 경험을 함께 재설계하는 것이 중요하다.

figma

웹에서 플러그인 시스템 (새 탭에서 열림)

Figma는 서드파티 플러그인을 브라우저 기반 디자인 편집기 안에서 실행하면서도 보안·안정성·성능을 모두 확보해야 했다. 단순히 `eval(PLUGIN_CODE)`를 사용하는 것은 위험하고, 기존 플러그인처럼 플랫폼 성능을 저하시키거나 업데이트 때마다 깨지는 문제도 피해야 했다. 여러 접근을 검토한 결과, 당시에는 JavaScript `Realm` 기반 샌드박스를 선택했지만, 이후 보안 취약점 공개를 계기로 C로 작성된 JavaScript VM을 WebAssembly로 컴파일하는 방식으로 변경했다. ## 플러그인 시스템이 해결해야 할 제약 - 플러그인은 접근성 검사, 번역, 색상 도구, 이미지 가져오기 등 사용자가 작성한 임의의 코드를 실행한다. - 플러그인이 Figma 편집기의 내부 데이터와 기능을 사용해야 하므로, 단순한 외부 웹페이지처럼 완전히 격리할 수는 없다. - 동시에 플러그인이 다음 영역에 영향을 주면 안 된다. - Figma 문서나 다른 사용자의 데이터에 대한 무단 접근 - 편집기 UI와 실행 환경의 안정성 - CPU·메모리 등 시스템 자원의 과도한 사용 - Figma 업데이트에 따른 플러그인 호환성 저하 - Figma는 WebGL, WebAssembly, TypeScript, React, 실시간 협업 기능을 함께 사용하는 구조라 일반적인 웹 애플리케이션보다 실행 환경이 복잡했다. ## 시도 1: `<iframe>` 샌드박스 - 가장 표준적이고 검증된 웹 보안 기능인 `<iframe>`을 플러그인 실행 환경으로 검토했다. - iframe은 별도의 문서와 JavaScript 실행 컨텍스트를 제공해 플러그인 코드가 Figma의 전역 객체나 DOM에 직접 접근하지 못하게 할 수 있다. - `sandbox` 속성과 출처(origin) 분리를 사용하면 플러그인과 호스트 애플리케이션 사이의 경계를 강화할 수 있다. - 플러그인과 Figma 사이의 통신은 `postMessage` 같은 명시적인 메시지 전달 방식으로 제한할 수 있다. - 그러나 iframe 방식에는 중요한 한계가 있었다. - Figma 내부 데이터 구조에 대한 빠르고 자연스러운 접근이 어렵다. - 플러그인 API 호출을 위해 많은 객체와 요청을 직렬화·전달해야 한다. - 별도 브라우저 컨텍스트를 만들기 때문에 성능과 메모리 비용이 발생한다. - iframe 자체가 안전하더라도 플러그인이 CPU나 메모리를 과도하게 사용해 편집기를 느리게 만들 가능성은 남는다. - 따라서 일반적인 웹 위젯에는 적합하지만, Figma처럼 고성능 편집기와 긴밀하게 상호작용해야 하는 플러그인 환경에는 충분하지 않았다. ## 시도 2: JavaScript 인터프리터를 WebAssembly로 컴파일 - 두 번째 접근은 플러그인 코드를 브라우저의 JavaScript 엔진에서 직접 실행하지 않고, 별도의 JavaScript 인터프리터 안에서 실행하는 방식이었다. - 인터프리터를 WebAssembly로 컴파일하면 플러그인 코드는 Figma의 실제 JavaScript 환경과 분리된 가상 실행 환경에서 동작한다. - 이 방식의 장점은 다음과 같다. - 플러그인이 브라우저의 전역 객체, DOM, Figma 내부 구현에 직접 접근할 수 없다. - 노출할 API를 명시적으로 선택할 수 있다. - 실행 환경을 통제하고 향후 브라우저 변경의 영향을 줄일 수 있다. - 반면 별도의 JavaScript 인터프리터를 실행해야 하므로 일반 JavaScript보다 느릴 수 있다. - 표준 JavaScript 기능과 내장 객체를 정확하게 구현해야 하며, 언어 호환성 문제도 발생한다. - 인터프리터 자체의 구현 오류나 보안 취약점이 샌드박스를 무너뜨릴 가능성도 고려해야 했다. - 당시에는 성능과 구현 복잡성이 주요 장애물이었다. ## 시도 3: JavaScript Realm - 세 번째 접근은 별도의 전역 환경과 객체 영역을 만드는 `Realm` 개념이었다. - Realm은 플러그인이 Figma의 전역 객체와 분리된 JavaScript 환경에서 실행되도록 하면서도, 필요한 API만 선택적으로 제공할 수 있게 한다. - iframe보다 가볍고, 별도 JavaScript 인터프리터를 내장하는 방식보다 브라우저의 기본 실행 성능을 더 많이 활용할 수 있다. - Figma는 다음과 같은 형태의 경계를 구성할 수 있었다. - 플러그인에 필요한 API만 노출 - 호스트 객체와 플러그인 객체 사이의 직접 참조 제한 - 허용된 요청만 Figma 내부 기능으로 전달 - 플러그인 전역 환경과 Figma 전역 환경의 분리 - 이 접근은 보안, 성능, API 사용성 사이의 균형이 가장 좋다고 판단되어 원래 구현에 채택됐다. - 다만 Realm은 당시 표준 기능으로 완전히 지원된 것이 아니라 shim에 의존해야 했다. - JavaScript 객체 모델과 프로토타입 체인을 완벽하게 격리하는 것은 매우 어려워, shim의 작은 결함도 보안 취약점으로 이어질 수 있었다. ## 운영 과정에서 드러난 보안 문제와 변경 - 글 게시 후 Realm shim에서 보안 취약점이 비공개로 제보됐다. - 취약점은 공개되기 전에 shim 팀에 의해 수정됐고, Figma는 실제 악용 증거를 발견하지 못했다고 밝혔다. - 그러나 샌드박스의 핵심이 외부 라이브러리의 복잡한 JavaScript 격리에 의존한다는 점은 중요한 위험 요소였다. - Figma는 이후 C로 작성된 JavaScript VM을 WebAssembly로 컴파일하는 대안으로 구현을 변경했다. - 이 방식은 브라우저의 JavaScript 객체와 실행 컨텍스트를 더 강하게 분리해, Realm shim에 의존하는 공격 표면을 줄이는 방향이다. ## 설계에서 얻은 교훈 - 서드파티 코드를 안전하게 실행하는 문제는 단순히 `eval`을 다른 API로 바꾸는 문제가 아니다. - 격리 수준, API 호출 비용, 실행 성능, 자원 제한, 유지보수성을 함께 평가해야 한다. - “브라우저 기능을 사용하므로 자동으로 안전하다”거나 “샌드박스이므로 모든 문제가 해결된다”고 볼 수 없다. - 특히 샌드박스 구현 자체가 복잡한 경우, 해당 구현의 취약점과 업데이트 정책까지 시스템의 보안 경계로 봐야 한다. - 가장 현실적인 설계는 플러그인에 필요한 최소 API만 노출하고, 실행 환경과 호스트 애플리케이션 사이의 통신을 명확한 경계로 제한하는 것이다. 플러그인 시스템을 설계할 때는 iframe, 별도 인터프리터, Realm 같은 선택지를 보안·성능·호환성 관점에서 비교해야 한다. 또한 외부 샌드박스 라이브러리에 의존한다면 정기적인 보안 검토와 교체 가능한 구조를 마련하고, 높은 보안 수준이 필요할 경우 WebAssembly 기반 독립 VM처럼 더 강한 실행 격리를 고려하는 것이 바람직하다.

figma

Figma의 라이브 (새 탭에서 열림)

Figma는 웹 기반 디자인 파일과 프로토타입을 최신 상태로 유지한 채 다른 웹사이트와 협업 도구에 삽입할 수 있는 **Live Embed Kit**을 공개했다. 사용자는 iframe 코드만으로 Figma 콘텐츠를 임베드할 수 있으며, 원본 파일이 변경되면 별도 재업로드 없이 임베드된 화면도 자동으로 동기화된다. 이를 통해 팀이 이메일, 메신저, 파일 공유 서비스에 흩어진 디자인을 찾는 번거로움을 줄이고 더 빠르게 협업할 수 있다는 것이 글의 핵심 주장이다. ## iframe 기반의 간단한 임베드 - Figma 파일 우측 상단의 **Share** 메뉴에서 **Public embed**를 선택하면 iframe 코드를 얻을 수 있다. - 개발자는 이 iframe을 자신의 웹사이트나 서비스에 삽입해 Figma 디자인 또는 프로토타입을 표시할 수 있다. - 별도의 복잡한 렌더링 시스템을 구축하지 않아도 웹페이지에 Figma 콘텐츠를 통합할 수 있다. ## 항상 최신 상태로 유지되는 디자인 - 임베드된 콘텐츠는 Figma 원본 파일과 연결되어 실시간으로 동기화된다. - 디자이너가 여백, 아이콘, 레이아웃 등을 수정하면 임베드 화면에도 변경 사항이 반영된다. - 디자인을 이미지로 다시 내보내거나, 수정된 파일을 다시 업로드할 필요가 없다. - Figma가 웹에서 실행되는 디자인 도구라는 점이 이러한 지속적인 동기화의 기반이다. ## 외부 서비스와의 통합 - Live Embed Kit은 개인 웹사이트뿐 아니라 제3자 서비스가 Figma 임베드 기능을 제공하도록 설계됐다. - 글에서는 Trello, JIRA, Dropbox Paper와 같은 도구에서의 활용 사례를 언급한다. - 서비스 개발자는 자체 제품 안에서 사용자가 최신 Figma 파일을 공유하고 확인할 수 있도록 통합할 수 있다. ## 팀 협업에서의 활용 사례 - **사내 위키**: 프로젝트나 기능 문서에 최신 디자인을 삽입해 문서와 시안을 함께 관리할 수 있다. - **팀 메시징 앱**: 그룹 채팅에서 디자인 파일의 최신 버전을 공유할 수 있다. - **블로그**: 프로젝트 소개 글에 live Figma 파일을 넣어 독자가 항상 최신 디자인을 보도록 할 수 있다. - 이러한 방식은 이메일 기록, Slack 대화, 파일 공유 폴더를 뒤져 최신 디자인을 찾는 문제를 줄인다. ## Figma 플랫폼 확장의 출발점 - Figma는 Live Embed Kit을 웹 기반 플랫폼 전략의 시작으로 소개한다. - 향후 Figma 파일에서 디자인 외의 다양한 정보를 가져와 새로운 업무 흐름에 활용할 수 있는 **Figma API**를 제공할 계획도 밝혔다. - 개발자와 파트너사가 Figma 데이터를 다른 협업 도구와 연결하는 생태계를 구축하는 방향이다. 실무적으로는 사내 문서, 제품 블로그, 협업 툴에 정적인 이미지 대신 Live Embed를 사용하면 최신성 유지와 커뮤니케이션 비용을 줄일 수 있다. 다만 공개 임베드 방식인 만큼, 삽입할 파일의 접근 권한과 공개 범위를 설정할 때 보안 및 기밀성도 함께 검토해야 한다.