Figma는 2021년 8월 업데이트에서 FigJam의 확장성과 Figma 플러그인 개발 역량을 강화하고, 디자인 시스템 관리와 반복 작업을 간소화했다. 특히 FigJam 플러그인·위젯, 프로토타이핑 자동화를 위한 API, 라이브러리 관리 기능이 추가되어 협업과 디자인 운영의 효율성이 높아졌다. 또한 투명 객체의 그림자 처리와 직선 그리기처럼 일상적인 사용성도 개선했다.
## FigJam 플러그인과 위젯 도입
- FigJam에 Figma의 오픈 플랫폼을 확장해 팀별 협업 방식에 맞는 기능을 직접 만들 수 있게 했다.
- **플러그인**
- 개인 작업을 자동화하고 효율화하는 도구다.
- 스타일 사용자 지정, 스티키 정리, 데이터 가져오기 등에 활용할 수 있다.
- **위젯**
- 여러 사용자가 캔버스에서 함께 조작하는 인터랙티브 객체다.
- 투표, 설문, 메모장, 게임 등을 제공해 워크숍과 브레인스토밍 진행을 돕는다.
- 기본 HTML·JavaScript 지식이 있으면 플러그인을, React 경험이 있으면 위젯을 개발할 수 있도록 진입 장벽을 낮췄다.
- 플러그인은 모든 요금제 사용자가 개발할 수 있었고, 위젯은 당시 비공개 베타로 제공됐다.
## Figma 플러그인 API 확장
- **프로토타이핑 쓰기 기능**
- 플러그인이 프로토타입을 자동 생성하거나 기존 인터랙션을 대량으로 수정할 수 있게 됐다.
- 반복적인 프로토타입 제작과 상호작용 설정을 자동화할 수 있다.
- **플러그인 파라미터**
- 별도의 사용자 인터페이스를 만들지 않고도 Quick Actions를 통해 사용자 입력을 받을 수 있다.
- 플러그인 개발 시간이 줄고, 간단한 입력 기반 도구를 더 빠르게 만들 수 있다.
- 당시 오픈 베타로 제공됐다.
## 디자인 시스템 관리 개선
- **컴포넌트 이동**
- 게시된 컴포넌트와 컴포넌트 세트를 파일 간에 이동할 수 있다.
- 이동 후에도 기존 인스턴스와의 연결이 유지된다.
- 대형 라이브러리를 여러 파일로 분리하거나 새 파일로 이전하기 쉬워졌다.
- **라이브러리 교체**
- 스타일과 컴포넌트를 하나씩 변경하지 않고, 전체 라이브러리 세트를 다른 라이브러리로 교체할 수 있다.
- **컴포넌트 검색**
- `Shift + I` 단축키로 필요한 컴포넌트를 빠르게 검색할 수 있다.
- 규모가 큰 디자인 시스템에서 탐색 시간을 줄여준다.
## 일상적인 사용성 개선
- 투명 객체가 뒤에 있는 그림자를 기본적으로 가리도록 변경되어, 별도로 설정을 조정할 필요가 줄었다.
- Figma와 FigJam에서 연필 도구 사용 시 `Shift`를 누르면 직선을 그릴 수 있다.
- 그 밖의 버그 수정과 개선 사항은 Figma 릴리스 노트에서 확인할 수 있도록 안내했다.
실무에서는 컴포넌트 라이브러리를 기능별 파일로 분리하고, 라이브러리 교체 기능과 플러그인 자동화를 함께 활용하면 디자인 시스템 유지보수 비용을 줄일 수 있다. FigJam에서는 투표나 설문 위젯을 활용해 회의 진행과 의사결정을 구조화할 수 있다.
FigJam은 Figma의 개방형 플랫폼을 확장해 플러그인과 위젯을 누구나 만들 수 있도록 지원한다. 플러그인은 반복 작업과 데이터 처리를 자동화하고, 위젯은 투표·설문·게임처럼 여러 사용자가 동시에 상호작용하는 협업 경험을 제공한다. 두 API 모두 JavaScript·HTML 또는 React 지식을 바탕으로 쉽게 시작할 수 있도록 설계되었다.
## Figma 플러그인에서 FigJam으로 확장
- Figma는 약 2년 전부터 플러그인을 통해 외부 데이터 연동, 워크플로 자동화, 디자인 프로세스 개선을 지원했다.
- 핵심 원칙은 “웹사이트를 만들 수 있다면 플러그인도 만들 수 있어야 한다”는 것이다.
- 따라서 기본적인 JavaScript와 HTML 지식만으로도 플러그인 개발을 시작할 수 있도록 API의 진입장벽을 낮췄다.
- FigJam에도 같은 개방형 플랫폼 원칙을 적용하되, 협업 중심의 사용 사례를 추가로 고려했다.
## 플러그인과 위젯의 역할 차이
- **플러그인**
- 개인 또는 팀의 작업 흐름을 자동화한다.
- CSV 데이터를 스티키 노트 격자로 변환하거나, 스티키 노트에 태그를 붙이는 작업 등을 처리할 수 있다.
- 보드의 객체를 정리·분석하거나 외부 콘텐츠를 가져오는 데 적합하다.
- **위젯**
- FigJam 보드에 직접 배치해 여러 사용자가 함께 조작하는 인터랙티브 객체다.
- 투표, 설문, 게임 등 협업형 기능을 구현할 수 있다.
- 사용자가 보드에 드래그 앤 드롭해 사용할 수 있다.
## React 기반의 선언형 위젯 API
- 위젯 API는 플러그인 API와 달리 선언적·함수형 방식으로 설계되었다.
- `<Frame />`, `<Rectangle />`, `<Text />`, `<SVG />` 같은 컴포넌트로 위젯의 화면 구조를 정의한다.
- 클릭 이벤트와 같은 사용자 상호작용에 임의의 코드를 연결할 수 있다.
- FigJam의 기본 객체처럼 인라인 속성 메뉴도 제공할 수 있다.
- React 컴포넌트와 유사한 구조를 사용하며, 컴포넌트 속성은 CSS의 레이아웃·스타일 속성과 비슷하다.
- 예시 카운터 위젯은 다음 방식으로 동작한다.
- `useSyncedState('count', 0)`으로 여러 사용자에게 동기화되는 상태를 만든다.
- 사용자가 숫자를 클릭하면 `setCount(count + 1)`을 호출해 값을 증가시킨다.
- `Frame`으로 자동 레이아웃과 패딩을 지정하고, `Text`로 현재 값을 표시한다.
- `widget.register(SimpleCounter)`로 위젯을 등록한다.
## FigJam 플러그인의 주요 활용 분야
### 보드 정리와 인사이트 도출
- 보드의 객체를 체계적으로 정리하고 분석할 수 있다.
- 스티키 노트를 색상별로 정렬하거나 카테고리용 태그를 추가할 수 있다.
- 스티키 노트의 내용을 분석해 워드 클라우드처럼 주제를 시각화할 수 있다.
- 투표 수를 자동으로 집계하는 스탬프 카운터 플러그인도 활용 사례로 제시된다.
- 텍스트를 입력하면 여러 개의 스티키 노트를 자동 생성하는 플러그인도 소개된다.
### 반복 작업 자동화
- 맞춤법 검사, 찾기 및 바꾸기 같은 수작업을 줄일 수 있다.
- 동일한 스타일의 스티키 노트 100개를 한 번에 만드는 등 반복적인 작업을 자동화할 수 있다.
- 사용자는 여러 단계를 직접 수행하는 대신 몇 번의 클릭만으로 작업을 완료할 수 있다.
- Figma에서 사용되던 맞춤법 검사 플러그인을 FigJam으로 확장하는 사례가 언급된다.
### 콘텐츠 라이브러리 연동
- 외부 서비스나 라이브러리의 콘텐츠를 FigJam 보드로 가져올 수 있다.
- 아이콘, 이모지, 회사 로고 등을 빠르게 삽입하는 플러그인을 만들 수 있다.
- Icons8, Material Design, Iconify, Brandfetch 등 기존 Figma 콘텐츠 플러그인의 FigJam 확장이 사례로 제시된다.
- 이를 통해 FigJam 사용자는 별도의 검색·복사 과정 없이 보드 안에서 필요한 시각 자료를 활용할 수 있다.
### 사용자 맞춤 설정
- 사용자가 원하는 색상, 폰트, 텍스트 스타일 등을 선택할 수 있는 기능도 플러그인 활용 분야로 제시된다.
- FigJam은 기본적으로 폰트와 색상 체계를 단순하게 유지하지만, 사용자 요구에 따른 커스터마이징 수요가 존재한다.
## 실용적인 시사점
FigJam에서 자동화가 필요하면 플러그인을, 여러 사람이 동시에 조작하는 기능이 필요하면 위젯을 선택하는 것이 적합하다. 특히 React에 익숙한 개발자는 FigJam 레이어와 CSS와 유사한 컴포넌트 구조를 활용해 비교적 빠르게 인터랙티브 협업 도구를 만들 수 있다.
Figma는 캔버스에서 댓글 핀이 이동할 때 발생하던 불필요한 React 렌더링을 줄여 스크롤 성능을 약 3배 개선했다. 댓글 수와 무관하게 편집기를 60fps에 가깝게 동작시키는 것이 목표였으며, Chrome Performance 도구와 React Profiler로 병목이 JavaScript 실행과 컴포넌트 재렌더링에 있음을 확인했다. 핵심 해결책은 뷰포트 변화에 실제로 영향을 받는 댓글 컴포넌트만 업데이트하고, 댓글 위치 계산과 변환 처리를 최적화하는 것이었다.
## 60fps를 목표로 한 댓글 스크롤
- Figma의 댓글은 캔버스 위 특정 위치에 고정된 “댓글 핀”으로 표시된다.
- 사용자가 캔버스를 이동하거나 확대·축소하면 댓글 핀도 뷰포트에 맞춰 계속 위치를 다시 계산해야 한다.
- 15fps나 30fps보다 60fps가 훨씬 부드러운 사용자 경험을 제공하므로, 댓글과 스레드가 많아져도 일정한 성능을 유지하는 것이 목표였다.
- 댓글 사용량이 증가하면서 대규모 팀과 파일에서 캔버스 반응성이 저하되기 시작했다.
## WebGL 캔버스와 React 댓글 UI의 구조
- Figma 편집기는 WebGL과 WebAssembly를 사용하는 “브라우저 안의 브라우저”에 가까운 구조다.
- 일부 사용자 인터페이스는 TypeScript와 React로 구현되어 있지만, 일반적인 정적 React 화면과 달리 댓글은 캔버스의 이동과 확대·축소에 따라 동적으로 움직인다.
- 편집기의 뷰포트 정보는 Redux에 저장된다.
- 댓글 핀 컴포넌트는 Redux에서 뷰포트 정보를 가져와 캔버스 좌표를 화면에 표시할 위치로 변환한다.
- 뷰포트가 변경될 때마다 React 컴포넌트 트리 일부가 업데이트되므로, 업데이트 범위가 성능에 직접적인 영향을 준다.
## 성능 분석에서 발견한 병목
- Chrome Performance 도구에서 대부분의 프레임 시간이 렌더링이나 페인팅이 아니라 JavaScript 실행에 사용되는 것으로 나타났다.
- 댓글 30개인 화면에서 프레임당 약 68ms가 JavaScript에 소비되었고, 실제 화면은 약 19fps로 렌더링됐다.
- React Profiler에서는 댓글 화면 자체의 렌더링에는 약 1.8ms만 사용되고 있었다.
- 대신 뷰포트 변화와 직접 관련 없는 다음 컴포넌트들이 함께 재렌더링됐다.
- 왼쪽 패널
- 툴바
- 속성 패널
- 기타 고정 위치 UI
- 즉, 댓글 내용 렌더링보다 “변화가 없는 컴포넌트까지 다시 렌더링하는 것”이 더 큰 비효율이었다.
## 불필요한 재렌더링 줄이기
- 뷰포트 업데이트는 댓글 핀의 위치에는 필요하지만, 화면에 고정된 패널이나 툴바에는 필요하지 않다.
- 따라서 뷰포트 상태를 사용하는 컴포넌트의 범위를 댓글 영역으로 제한해야 한다.
- React 애플리케이션이 커질수록 상위 컴포넌트의 상태 변화가 하위 전체로 전파되면서 불필요한 렌더링이 발생하기 쉽다.
- React Profiler로 실제로 다시 렌더링되는 컴포넌트를 확인하면, 직관만으로 찾기 어려운 병목을 구체적으로 식별할 수 있다.
- 성능 개선은 댓글 컴포넌트 자체를 빠르게 만드는 것뿐 아니라, 댓글과 무관한 컴포넌트가 업데이트되지 않도록 컴포넌트 구조와 상태 구독 방식을 조정하는 데서 시작됐다.
## 댓글 핀 위치 변환 최적화
- 댓글 핀은 뷰포트가 바뀔 때마다 캔버스 좌표를 화면 좌표로 변환해야 한다.
- 이 변환 과정이 매 업데이트마다 React 렌더링과 결합되면 JavaScript 실행 비용이 커질 수 있다.
- Figma는 불필요한 컴포넌트 업데이트를 제거한 뒤 댓글 핀의 변환 처리도 최적화해, 캔버스 이동 중 위치 계산과 화면 반영 비용을 줄였다.
- 결과적으로 댓글 스크롤 FPS가 기존보다 약 3배 향상됐다.
## 실용적인 결론
- React 성능 문제에서는 먼저 “컴포넌트 하나의 렌더링 속도”보다 “불필요하게 다시 렌더링되는 컴포넌트가 무엇인지”를 확인하는 것이 효과적이다.
- Chrome Performance 도구로 프레임별 JavaScript 비용을 확인하고, React Profiler로 재렌더링 범위를 분석하는 조합이 유용하다.
- 자주 변하는 상태는 실제로 그 상태가 필요한 컴포넌트 가까이에 두고, 고정 UI가 동적 상태 변화에 구독되지 않도록 설계하는 것이 좋다.
Figma의 첫 Plugin Show & Tell은 커뮤니티 개발자들이 제작 중인 플러그인을 직접 시연하고, 새로운 기능과 개발 방향을 공유하는 라이브 행사였다. 디자인 시스템 검사, 맞춤법 검사, 아이콘 관리, 문서 연결, 음성 제어 등 플러그인이 Figma의 작업 자동화와 확장성을 크게 넓힐 수 있음을 보여준다. 글은 행사를 소개하는 데 그치지 않고, 더 많은 개발자가 Figma Plugin API에 참여하도록 관련 자료와 커뮤니티를 안내한다.
## Plugin Show & Tell의 목적
- Figma 플러그인 커뮤니티의 창의적인 작업을 소개하기 위해 처음 개최된 라이브 스트리밍 행사다.
- 개발자들이 플러그인을 홍보하고, 사용자가 새로운 API와 활용 방법을 탐색하도록 돕는 것이 목적이다.
- 완성된 플러그인뿐 아니라 개발 중인 기능과 향후 로드맵도 공유했다.
- 녹화 영상에서는 5명의 개발자가 디자인 시스템 검사부터 Figma 음성 제어까지 다양한 사례를 시연했다.
## 디자인 시스템과 품질 관리 자동화
- Toybox의 Jono Kolnik은 개발 중인 **Roller**를 소개했다.
- Roller는 디자인을 디자인 시스템과 비교해 오류와 불일치를 찾고 수정하도록 돕는다.
- 반복적인 수동 검수 대신 플러그인이 디자인 규칙을 검사함으로써 일관성을 유지할 수 있다.
- 디자인 시스템이 커질수록 색상, 간격, 컴포넌트 사용 규칙을 자동으로 점검하는 도구의 가치가 커진다.
## 맞춤법 검사와 외부 서비스 연동
- Tekeste Kidanu는 Figma 안에서 사용하는 **Spell Check** 플러그인을 시연했다.
- 프로젝트의 텍스트를 검사해 디자인 문서의 오탈자를 줄이는 데 활용할 수 있다.
- 자신의 서비스인 **Cleanmock**을 Figma 내부에서 사용할 수 있도록 연동한 사례도 소개했다.
- 플러그인은 Figma 캔버스뿐 아니라 브라우저 API와 외부 서비스까지 연결하는 확장 지점이 될 수 있다.
## 대규모 아이콘 세트 관리
- Vjacheslav Trushkin은 **Iconify** 플러그인과 향후 계획을 공유했다.
- Iconify를 사용하면 수백 개의 아이콘 세트를 Figma와 실제 제품 개발 과정에서 함께 활용할 수 있다.
- 디자인 단계에서 선택한 아이콘을 production 환경까지 일관되게 연결하는 워크플로를 지향한다.
- 방대한 아이콘 라이브러리를 검색하고 관리하는 문제를 플러그인으로 단순화한다.
## 검색·문서화·레이아웃 작업 개선
- Jackie Chui는 여러 생산성 플러그인의 개선 사항을 소개했다.
- **Find & Replace**는 Figma 문서 안의 내용을 빠르게 검색하고 바꾸는 기능을 제공한다.
- **Link to Documentation**은 컴포넌트에 관련 문서 링크를 추가해 디자인과 가이드 문서를 연결한다.
- **Paste to Fill**은 붙여넣은 이미지를 이미지 채우기로 적용한다.
- 프레임 안 오브젝트의 여백과 크기를 관리하는 플러그인은 사용자 지정 프리셋을 지원할 예정이었다.
- 이러한 도구들은 반복적인 레이아웃 조정과 문서 탐색 작업을 줄이는 데 초점을 둔다.
## 타이포그래피 규칙과 음성 인터페이스
- Andrew Goodwin은 타이포그래피 규칙을 선택하고 적용하는 플러그인을 선보였다.
- 사용자가 정해진 글꼴, 크기, 행간 등의 규칙을 적용해 텍스트 스타일을 일관되게 관리할 수 있다.
- Figma를 음성 명령으로 조작하는 음성 UI도 시연했다.
- Figma Plugin API의 기능 대부분을 음성 명령으로 매핑하는 작업이 거의 완료 단계라고 설명했다.
- 이는 플러그인이 시각적 UI를 넘어 새로운 입력 방식과 접근성 기능까지 제공할 수 있음을 보여준다.
## 플러그인 개발을 위한 생태계
- Figma는 플러그인 개발을 시작할 수 있도록 다음 자료를 제공했다.
- 플러그인의 기본 구조와 개발 환경 설정을 설명하는 Getting Started 문서
- 캔버스와 상호작용하는 공식 Plugin API 문서
- Figma UI와 유사한 HTML·JavaScript·CSS 기반의 Figma Plugin DS
- 오픈소스 플러그인 코드 목록
- TypeScript, React/JSX, 번들링, 매니페스트 생성을 지원하는 FigPlug
- 개발자들이 질문과 작업물을 공유하는 Figma Plugins Slack 커뮤니티
- 조직 내부에서만 사용하는 비공개 플러그인도 팀별 워크플로 자동화에 활용할 수 있다고 안내한다.
## 실용적인 결론
Figma 플러그인은 단순한 편의 기능을 넘어 디자인 시스템 검증, 콘텐츠 품질 관리, 외부 데이터 연동, 접근성 개선, 개발 프로세스 연결까지 확장할 수 있다. 반복 작업이나 팀 고유의 규칙이 있다면 Plugin API와 오픈소스 사례를 참고해 사내 전용 플러그인부터 작게 만들어보는 것이 현실적인 접근이다.
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처럼 더 강한 실행 격리를 고려하는 것이 바람직하다.
DesignSystems.com은 디자인 시스템을 만들고 운영하는 디자이너·개발자·관리자를 위한 지식 공유 플랫폼으로 자리 잡고 있다. 이 글은 2019년 6월에 공개된 주요 콘텐츠 네 가지를 소개하며, 아이콘 설계부터 접근성 높은 React 컴포넌트, 에이전시 협업, 화이트라벨링까지 디자인 시스템의 실무 범위를 보여준다. 핵심은 재사용성과 일관성을 유지하면서도 다양한 사용자와 제품 요구에 유연하게 대응하는 것이다.
## 아이콘 시스템 설계와 구현
- 아이콘 제작의 기본 원칙부터 개발자 전달까지 다루는 종합 가이드를 소개한다.
- 주요 내용은 다음과 같다.
- 아이콘의 스트로크와 필(fill) 설계
- Boolean 연산을 활용한 아이콘 제작
- 아이콘을 체계적으로 구성하고 관리하는 방법
- 개발자 핸드오프를 위한 파일 및 자산 준비
- 아이콘은 단순한 그래픽 요소가 아니라 디자인 시스템의 일관성과 사용성을 좌우하는 핵심 자산으로 설명된다.
## 에이전시 관점의 디자인 시스템 구축
- Instrument는 Nike, Google, Airbnb 등과 협업하며 일회성 결과물이 아닌 확장 가능한 디자인 시스템을 구축한다.
- 재사용 가능한 기능성 컴포넌트를 여러 애플리케이션과 규모에 걸쳐 활용하는 것을 중시한다.
- 디자인 시스템의 성공을 위해서는 다음 과정이 중요하다.
- 클라이언트와 시스템의 목표 및 범위에 대한 공통 이해 형성
- 높은 수준의 협업을 통한 요구사항 조율
- 특정 프로젝트를 넘어 장기적으로 활용 가능한 구성요소 설계
- 디자인 시스템은 산출물 하나가 아니라 브랜드, 제품, 기술을 연결하는 협업 프로세스로 제시된다.
## 접근성을 공유하는 React 컨테이너
- Zendesk의 오픈소스 디자인 시스템 Garden은 접근성 및 키보드 조작을 공통 패턴으로 관리하기 위해 “컨테이너” 패턴을 사용한다.
- 컨테이너는 화면 UI를 직접 렌더링하지 않고 다음 기능을 담당한다.
- 키보드 및 마우스 상호작용 처리
- React 컴포넌트 간 접근성 로직 공유
- RTL(오른쪽에서 왼쪽으로 읽는 언어) 레이아웃 지원
- 새 라이브러리인 `react-containers`는 스타일이 포함된 전체 패키지를 설치하지 않아도 비시각적 로직만 사용할 수 있도록 별도 저장소로 분리됐다.
- 기존 패턴보다 더 작고 효율적으로 다시 작성됐으며, WAI-ARIA Authoring Practices 1.1에 더욱 가깝게 구현됐다.
## 사용자에게 권한을 제공하는 화이트라벨링
- Dawn Labs는 제3자가 디자인 시스템을 직접 커스터마이즈할 수 있으면서도 제품 전체의 일관성을 유지해야 하는 문제를 다뤘다.
- 사용한 기술은 다음과 같다.
- `styled-components`
- `styled-system`
- GraphQL 백엔드
- CSS 변수와 전역 CSS 주입
- 기본 디자인 토큰과 구조는 통제하면서도, 최종 사용자가 클라이언트의 개입 없이 원하는 스타일을 수정할 수 있도록 “스타일링 탈출구”를 제공했다.
- 화이트라벨 시스템은 일관된 기본 경험과 사용자별 커스터마이징 사이의 균형이 중요하다.
## 커뮤니티 중심의 지식 공유
- DesignSystems.com은 디자인 시스템 제작자, 디자이너, 개발자, 관리자가 경험과 실무 지식을 공유하는 것을 목표로 한다.
- 다양한 분야의 기고를 통해 디자인 시스템을 시각 디자인에만 한정하지 않고 다음 영역까지 확장한다.
- 접근성
- 컴포넌트 아키텍처
- 협업과 운영
- 사용자 커스터마이징
- 플랫폼의 성장은 운영팀뿐 아니라 커뮤니티 구성원의 사례와 기여에 기반한다.
디자인 시스템을 구축할 때는 재사용 가능한 컴포넌트와 명확한 시각 규칙뿐 아니라 접근성, 협업 프로세스, 확장 가능한 커스터마이징 구조까지 함께 설계하는 것이 좋다. 특히 공통 로직은 별도 모듈로 분리하고, CSS 변수나 디자인 토큰을 활용하면 일관성과 유연성을 동시에 확보할 수 있다.
LittleBits 팀은 여러 플랫폼과 화면 크기에 대응하기 위해 Figma의 제약 조건과 8px 기반의 ‘매직 넘버’ 시스템을 결합했다. 주요 크기와 여백을 일정한 배수로 통일하고, 화면 비율별 스케일링 규칙을 React 코드에도 적용해 하나의 템플릿으로 모바일·태블릿 레이아웃을 관리했다. 그 결과 작은 팀으로도 다양한 기기에서 일관된 디자인을 유지하면서 추가적인 화면별 조정을 줄일 수 있었다.
## 8px 기반의 매직 넘버 시스템
- 텍스트, 버튼, 그래픽, 여백, 패딩 등의 크기가 공통 숫자 배수를 따르도록 설계했다.
- 기존 시안을 분석한 결과 대부분의 값이 8의 배수에 가까웠기 때문에 8px을 기준 단위로 채택했다.
- 버튼과 입력 요소의 높이는 32, 48, 56, 64, 96px로 구성했다.
- 주요 텍스트 크기는 16, 24, 32, 48px을 사용했다.
- 패딩과 거터는 16, 24, 32px을 중심으로 정의했으며, 큰 카드 높이는 240px로 설정했다.
- 공통 단위를 사용하면 컴포넌트 간 간격과 크기를 조정하기 쉽고 전체 디자인의 조화도 높아진다.
## Figma 제약 조건과 화면 크기 대응
- Figma의 constraints를 활용해 요소를 화면이나 그리드의 가장자리에 고정하고, 프레임 크기 변화에 따라 레이아웃이 반응하도록 만들었다.
- 하나의 레이아웃이 일반적인 스마트폰, 작은 화면의 iPhone SE, 태블릿에서 모두 자연스럽게 보이도록 화면 간 비율을 분석했다.
- 화면 크기 사이의 비율을 계산한 뒤 소수 값을 반올림해 실용적인 정수 기반 스케일링 규칙으로 정리했다.
- 이 규칙을 React 코드의 크기 계산 로직에 적용해 디자인과 실제 구현이 같은 방식으로 동작하도록 했다.
- Figma에서는 scale 도구와 프레임 크기 조절을 함께 사용해 하나의 템플릿으로 다양한 기기 화면을 미리 확인했다.
- 템플릿이 처음부터 스케일링 규칙을 고려해 설계되었기 때문에 태블릿과 작은 스마트폰에서도 별도의 대규모 수정 없이 안정적으로 표시됐다.
## 다양한 화면 비율을 위한 콘텐츠 설계
- 앱에는 많은 영상과 애니메이션이 포함되어 있어 화면별로 콘텐츠 파일을 여러 버전 제작하는 방식은 피하고자 했다.
- 모든 영상과 애니메이션을 4:3 비율을 기준으로 제작했다.
- 16:9 화면에서 일부가 잘리더라도 핵심 내용이 유지되도록 안전 영역(safe area)을 설정했다.
- 이 방식으로 콘텐츠 파일은 하나만 유지하면서 다양한 화면 비율에 대응할 수 있었다.
## 텍스트 크기와 다국어 지원
- 8px 규칙이 모든 텍스트에 적합한 것은 아니므로 작은 글자에는 4px 단위의 예외를 허용했다.
- 예를 들어 12px과 20px 같은 크기를 사용해 가독성과 시각적 균형을 맞췄다.
- 앱을 6개 언어로 번역하면서 독일어처럼 단어가 긴 언어가 정해진 영역을 넘는 문제가 발생했다.
- 이를 해결하기 위해 텍스트가 영역에 맞지 않으면 코드가 다음으로 작은 제목 크기를 자동 선택하도록 구현했다.
- 그 결과 실제 사용 가능한 제목 크기는 기본 디자인보다 많아졌지만, H1부터 H6까지 단계적으로 자연스럽게 작아지는 체계를 유지했다.
## 단순한 레이아웃에 맞춘 체계적인 접근
- 대부분의 화면은 중앙 정렬 요소나 2~3열 콘텐츠처럼 비교적 단순한 구조였다.
- 복잡한 반응형 패턴을 많이 사용하지 않고, 기본 제약 조건과 스케일링 시스템만으로 요구사항을 충족했다.
- 디자인 시스템을 Figma와 React 양쪽에 동일하게 적용한 것이 다양한 화면 크기를 효율적으로 관리한 핵심이었다.
실무에서는 먼저 기존 디자인에서 반복되는 크기와 간격을 찾아 기준 단위를 정하고, Figma constraints와 코드의 반응형 규칙을 함께 설계하는 것이 좋다. 다만 텍스트와 다국어처럼 예외가 잦은 영역에는 고정 규칙을 강제하기보다 단계적 축소나 안전 영역 같은 유연한 예외 처리를 마련해야 한다.
Figma의 2018년은 단순한 디자인 도구를 넘어 플랫폼과 커뮤니티로 확장한 해였다. 웹 기반 API를 공개해 외부 서비스와 자동화 도구가 Figma에 연결될 수 있도록 했고, 실제 사업과 통합 사례도 등장했다. 동시에 전 세계 사용자 커뮤니티를 조직하고 디자인 시스템 관련 지식 공유를 확대했으며, Series B 투자로 제품·사업 확장을 뒷받침했다.
## 플랫폼과 웹 API의 공개
- Figma는 초기부터 데스크톱 소프트웨어가 아닌 웹 기반 디자인 도구를 지향했다.
- 2018년에는 디자인 도구 최초의 웹 API를 공개하며 Figma Platform을 출시했다.
- API를 통해 다음과 같은 확장이 가능해졌다.
- 다른 디자인·개발 도구와의 연동
- 반복 작업 자동화
- 스크립트와 웹 애플리케이션을 활용한 맞춤형 워크플로 구축
- Uber와 GitHub는 공개 전부터 API를 활용해 자체 업무 프로세스를 맞춤화했다.
- 클라우드 기반 구조 덕분에 기존의 폐쇄적인 데스크톱 소프트웨어로는 구현하기 어려웠던 온라인 통합이 가능해졌다.
## API를 기반으로 한 생태계와 사업
- 플랫폼 출시 7개월 만에 Figma 위에서 유료 사업을 운영하는 기업이 등장했다.
- 커뮤니티와 기업이 만든 주요 통합 사례는 다음과 같다.
- PDF 내보내기
- 스타일 가이드 자동 생성
- 텍스트와 레이어 이름 검색·일괄 변경
- JavaScript용 Figma API 라이브러리
- 외부 서비스와의 연동도 확대됐다.
- Avocode와 Zeplin: 개발자 핸드오프 지원
- Principle: Figma 디자인에 고급 애니메이션 추가
- Relay for Figma: 디자인을 코드베이스로 직접 전달
- Pagedraw: Figma 디자인을 React 코드로 변환
- Overflow: 사용자 플로우 다이어그램 제작
- Haiku: 디자인을 프로덕션용 컴포넌트로 전환
- Figma는 파트너십과 통합 생태계를 향후 성장의 핵심 축으로 보고, 2019년에도 플랫폼 확장을 이어가겠다고 밝혔다.
## 글로벌 커뮤니티 구축
- 2018년 Figma의 관심사는 제품 자체뿐 아니라 사용자 커뮤니티로 확대됐다.
- 디자인 시스템을 주제로 한 밋업을 세계 여러 도시에서 개최했다.
- 초기에는 8개 도시에서 시작
- 이후 17개 국가로 활동 범위를 확장
- Bengaluru, Toronto 등지에서 디자이너들이 실제 디자인 시스템 운영 경험을 공유
- 커뮤니티의 관심이 커지자 DesignSystems.com을 개설했다.
- Airbnb, GitHub, Braintree, Segment 등의 구성원이 디자인 시스템 운영 사례와 실무 조언을 공유했다.
- Figma는 온라인 제품뿐 아니라 오프라인 만남과 지식 공유를 통해 사용자 간 연결을 강화하려 했다.
## 기업 확장과 투자
- Microsoft Dynamics 365 for Talent 디자인팀은 Figma API를 활용해 개발자 핸드오프를 자동화했다.
- 대규모 조직이 여러 부서와 팀에서 Figma를 채택하기 시작했다.
- 2018년 초 2,500만 달러 규모의 Series B 투자를 유치했다.
- 투자금은 제품 개발과 사업 확장, 플랫폼 및 커뮤니티 성장에 활용됐다.
## 실용적인 시사점
Figma의 사례는 협업 도구가 자체 기능만으로 성장하는 것이 아니라 API, 외부 통합, 사용자 커뮤니티를 통해 플랫폼으로 발전할 수 있음을 보여준다. 특히 반복적인 디자인·개발 업무를 자동화하려는 팀이라면 API 기반 연동과 기존 도구와의 연결 가능성을 우선 검토할 만하다.
Figma는 디자인 생태계의 개방성을 강화하기 위해 Figma 파일을 Sketch로 변환하는 API 챌린지를 발표했다. 총 1만 5천 달러의 상금과 오픈소스 제출을 통해 개발자와 디자이너의 참여를 유도하려는 목적이었다. 다만 커뮤니티의 우려가 제기되면서 챌린지는 일시 중단되었고, 2018년 11월에는 당분간 진행하지 않기로 결정되었다.
## 개방형 디자인 플랫폼을 위한 API 챌린지
- Figma는 경쟁 제품인 Sketch로 파일을 내보내는 도구를 만들도록 참가자들을 초대했다.
- 이는 특정 도구에 사용자를 묶어두기보다, 다양한 디자인 도구와 작업 방식을 연결하려는 Figma의 개방형 플랫폼 전략을 보여준다.
- Figma는 이미 Sketch 파일 가져오기를 지원하고 있었으며, Sketch 내보내기는 그 생태계를 확장하는 자연스러운 다음 단계로 소개됐다.
- 기존 API를 활용해 커뮤니티가 만든 스타일 가이드 생성기, Alexa 연동 등 다양한 프로젝트에서 영감을 받아 챌린지를 기획했다.
## 구현 대상: Figma에서 Sketch로의 변환
- 참가자는 Figma 객체로 구성된 두 개의 파일을 Sketch로 변환하는 exporter를 개발해야 했다.
- 첫 번째 파일에는 기본 수준의 객체가 포함되어 비교적 명확한 변환 결과를 기대할 수 있었다.
- 두 번째 파일에는 다음과 같은 복잡한 요소가 포함됐다.
- 텍스트 및 타입
- 컴포넌트
- 스타일
- 프로토타입
- Figma와 Sketch의 기능이 항상 1:1로 대응하지 않기 때문에, 복잡한 파일은 단순한 변환 정확도뿐 아니라 창의적인 매핑 방식도 평가 대상이었다.
## 평가 기준과 제출 조건
- 심사는 객관적 기준과 주관적 기준을 함께 적용했다.
- 평가 요소에는 다음이 포함됐다.
- 두 파일의 디자인 요소를 얼마나 정확하게 전달하는지
- exporter의 사용 편의성
- Figma와 Sketch 간 차이를 해결하는 접근 방식의 창의성
- 코드 품질과 GitHub 문서화 수준
- 전체 점수의 5%는 코드 품질과 GitHub README 문서에 배정됐다.
- 제출물은 GitHub 저장소 링크와 함께 제출해야 했으며, README와 MIT 라이선스를 포함해야 했다.
## 상금과 참가 방식
- 1등 상금은 1만 달러, 2등 상금은 5천 달러로 총상금은 1만 5천 달러였다.
- 최대 3명까지 팀을 구성할 수 있었다.
- 대부분의 국가에서 만 21세 이상이면 참가할 수 있었지만, 일부 국가에는 예외가 적용됐다.
- 챌린지 기간은 2018년 10월 2일부터 11월 16일 오후 11시 59분(PST)까지로 예정됐다.
## 심사위원 구성
- 심사위원은 디자인 경험과 커뮤니티용 플러그인·도구 제작 경험을 함께 갖춘 인물들로 구성됐다.
- GitHub의 디자인 시스템 엔지니어 Emily Plumme는 디자인과 개발을 연결하는 API 및 컴포넌트 시스템 경험을 보유했다.
- Google의 인터랙션 디자이너 Raph D’Amico는 행동과학과 시스템 설계 관점에서 사용자 경험을 평가할 수 있는 배경을 갖췄다.
- 접근성 도구 Stark와 Lyra를 만든 Cat Noone은 디자인 접근성과 윤리적 제품 설계에 전문성이 있었다.
- Sketch Runner를 만든 디자이너 Roy van Rooijen은 디자인 도구와 플러그인 생태계에 대한 경험을 제공했다.
## 커뮤니티 반응과 챌린지 중단
- 발표 이후 커뮤니티에서 챌린지의 운영 방식과 관련한 우려가 제기됐다.
- Figma는 이러한 의견을 반영해 챌린지를 일시 중단하고, 몇 주 뒤 재개하는 방안을 검토한다고 밝혔다.
- 이후 2018년 11월 19일 업데이트에서 어떤 형태의 챌린지도 당분간 진행하지 않기로 결정했다.
- 따라서 글에서 제시된 상금, 일정, 제출 조건은 최초 계획이며 실제로는 예정대로 진행되지 않았다.
Figma의 시도는 경쟁 제품과의 호환성을 지원하는 것이 장기적으로 플랫폼의 신뢰와 확장성을 높일 수 있음을 보여준다. 다만 외부 커뮤니티를 대상으로 한 API 경연은 상품 범위, 평가 기준, 참가자 권리와 운영 방식에 대한 충분한 사전 검토와 소통이 중요하다는 교훈도 남겼다.
Microsoft 디자이너 Jackie Chui는 사내 아이콘 4,000개를 한곳에서 검색·분류·복사할 수 있는 브라우저 기반 라이브러리를 3주 만에 만들었다. 디자이너용 태그와 엔지니어용 클래스명, 아이콘을 붙여 넣어 메타데이터를 찾는 역검색 기능을 제공해 도구 간 단절을 해결했다. 이 사례는 기존 제품을 그대로 사용하는 대신 실제 사용자의 요구를 조사하고, 익숙한 기술과 단계적인 학습으로 맞춤형 도구를 만들 수 있음을 보여준다.
## 문제 발견과 기존 도구의 한계
- Jackie는 Microsoft 디자이너들의 작업 과정을 관찰하고 아이콘 관리에서 겪는 불편을 조사했다.
- 기존 제품 중에서는 IconJar가 아이콘 정리와 복사·붙여넣기를 지원했지만 Microsoft의 요구에는 부족했다.
- 여러 사용자가 아이콘 태그를 추가하고 공유할 수 없었다.
- 브라우저 기반이 아니어서 아이콘을 클라우드에서 공동으로 사용할 수 없었다.
- Mac 전용이라 Windows 중심 조직에 적합하지 않았다.
- 이에 따라 특정 운영체제나 디자인 도구에 종속되지 않는 자체 도구를 만들기로 했다.
## 브라우저 기반 아이콘 라이브러리 설계
- 초기 UI는 Sketch로 설계하고 IconJar에서 아이디어를 얻되, Microsoft Fabric 디자인 언어에 맞게 스타일을 조정했다.
- 브라우저에서 작동하도록 만들어 사용자가 선호하는 디자인 도구와 관계없이 접근할 수 있게 했다.
- 아이콘마다 다음 정보를 연결했다.
- 디자이너가 찾기 쉬운 태그와 분류명
- 엔지니어가 코드에서 사용하는 클래스명
- 실제 복사·붙여넣기에 필요한 유니코드 아이콘 문자
- 아이콘을 검색해 바로 복사할 수 있게 해, 디자이너가 자주 쓰는 아이콘 문자를 별도 파일에 보관하던 방식을 없앴다.
- 아이콘을 라이브러리에 붙여 넣으면 관련 메타데이터를 역으로 찾을 수 있는 기능도 제공했다.
## 익숙한 기술로 빠르게 개발
- Jackie는 포트폴리오 제작을 통해 익힌 HTML, CSS, JavaScript 경험을 기반으로 개발을 시작했다.
- 프런트엔드와 백엔드 데이터베이스를 함께 구축하기 쉬운 JavaScript 프레임워크 Meteor.js를 선택했다.
- Meteor 튜토리얼의 할 일 목록 데이터베이스 예제를 아이콘 데이터베이스로 확장했다.
- 새로운 기술을 완전히 습득한 뒤 시작하기보다, 해결해야 할 실제 문제를 중심으로 필요한 내용을 학습하며 개발했다.
- 기획과 디자인 경험에 엔지니어링 지식을 결합해 짧은 기간 안에 작동하는 제품을 완성했다.
## 아이콘 데이터 수집과 변환
- 아이콘은 일반적으로 폰트 파일에 저장되며, 키보드로 직접 입력할 수 없는 전용 유니코드 문자를 복사해 사용한다.
- Jackie는 회사의 아이콘 폰트 파일을 다운로드하고 각 아이콘의 실제 유니코드 문자를 추출했다.
- Microsoft 문서에서 엔지니어가 사용하는 아이콘 이름과 클래스명 목록을 확보했다.
- 아이콘 이름 목록을 Excel로 정리한 뒤 JSON으로 변환해 애플리케이션 데이터로 사용했다.
- 이렇게 아이콘 문자, 표시 이름, 클래스명, 태그를 하나의 검색 가능한 시스템으로 통합했다.
## 배포와 사용자 피드백
- 약 3주간의 개인 작업 끝에 첫 버전을 완성하고 Microsoft Azure에 호스팅했다.
- 처음에는 팀에 간단한 이메일과 링크만 공유했지만, 사용자들의 입소문을 통해 디자인 스튜디오 전체로 확산됐다.
- 동료들은 버그를 제보하고 새 기능을 제안하며 제품 개선에 참여했다.
- 도구는 빠르게 여러 디자이너의 일상적인 작업 흐름에 포함됐다.
- 이후 V2에서는 버그 수정과 기능 보강을 진행하고 다른 Microsoft 팀으로 확장할 계획이었다.
## Figma 컴포넌트로의 확장
- 향후 4,000개 이상의 아이콘을 한 번에 Figma 컴포넌트로 변환하는 기능을 계획했다.
- 사용자는 별도 라이브러리를 거치지 않고 Figma 안에서 아이콘을 검색하고 정리할 수 있게 된다.
- 장기적으로는 아이콘 폰트 파일을 업로드하면 누구나 Figma 컴포넌트로 변환할 수 있는 도구로 발전시키려 했다.
- 기존 도구를 대체하는 다음 버전을 만드는 것이 목표라는 점에서, 제품은 사용자의 작업 흐름에 맞춰 계속 진화한다.
실용적으로는 먼저 사용자의 반복적인 불편을 관찰하고, 기존 도구의 부족한 점을 명확히 정의하는 것이 중요하다. 이후 모든 기능을 완성하려 하기보다 검색·분류·복사처럼 핵심 작업만 지원하는 최소 버전을 빠르게 배포하고, 실제 사용자 피드백을 바탕으로 확장하는 접근이 효과적이다.
Figma는 API를 활용해 Figma 디자인을 React 컴포넌트와 코드로 변환하는 도구를 만들었다. 핵심 목표는 디자인을 Figma에서 계속 관리하면서도, 개발자가 작성한 기능 코드를 보존하고 여러 디자인에 재사용할 수 있도록 분리하는 것이다. 이를 통해 디자인 변경 사항을 웹사이트에 동기화하고, 기존 기능을 새로운 디자인에 쉽게 연결하려 했다.
## Figma 디자인을 React 코드로 변환
- Figma API 출시 이후 Figma 문서를 React 컴포넌트로 자동 변환하려는 시도가 꾸준히 있었다.
- Pagedraw는 Figma 연동을 지원하는 제품을 만들었고, Figma 역시 자체적인 변환기를 개발해 공개했다.
- 구현 코드는 GitHub에 오픈 소스로 공개되어 누구나 동작 방식을 확인하고 실험할 수 있다.
- API를 직접 사용해 보고 싶은 개발자를 위해 Figma Developers 페이지도 제공한다.
## 디자인 코드와 기능 코드의 분리
- 생성되는 컴포넌트의 시각적 디자인은 가능한 한 Figma에서 관리하도록 설계했다.
- Figma에서 디자인을 수정한 뒤 버튼 한 번으로 웹사이트의 디자인 변경 사항을 동기화하는 것이 목표다.
- 동기화 과정에서 개발자가 작성한 이벤트 처리, 데이터 로직 등 기능 코드를 덮어쓰지 않아야 한다.
- 따라서 Figma가 생성하는 디자인 코드와 애플리케이션의 기능 코드를 서로 독립적인 영역에 두는 구조가 필요하다.
## 기능 코드의 재사용
- 새로운 디자인을 만들 때마다 기능을 처음부터 다시 구현하지 않도록 하는 것도 주요 목표다.
- 예를 들어 기존에 구현한 정렬 가능한 리스트의 기능을 새로운 리스트 디자인에 연결할 수 있어야 한다.
- 기능 코드를 디자인과 분리하면 React 컴포넌트를 재사용하듯, 동일한 기능을 여러 시각적 디자인에 적용할 수 있다.
- 이는 디자인 변경과 기능 개발이 서로의 작업을 방해하지 않도록 만드는 기반이 된다.
## Figma에서 CSS로 변환하기
- React 변환의 첫 번째 기술적 과제는 Figma 디자인과 동일하게 보이는 React 컴포넌트를 생성하는 것이다.
- 단순히 HTML 구조만 생성하는 것이 아니라, 레이아웃과 스타일을 CSS로 재현해야 변환의 실질적인 가치가 생긴다.
- 글에서는 정렬 가능한 리스트 예시를 사용해 디자인을 코드로 옮기는 과정을 설명하려 한다.
- 동일한 시각적 결과를 구현하는 방법은 여러 가지가 있으므로, 어떤 CSS 구조와 속성을 선택할지가 중요한 설계 문제가 된다.
실무에서는 Figma를 디자인의 원천으로 활용하되, 변환된 코드를 그대로 최종 코드로 취급하기보다 시각적 구조와 기능 로직을 분리하는 초기 코드 생성 도구로 사용하는 것이 적절하다.
Figma는 2018년 Web API 출시 직후 커뮤니티가 만든 다양한 활용 사례를 소개한다. PDF·스타일 가이드 생성부터 음성 인터페이스, GraphQL, React 연동까지 API가 디자인 산출물 자동화와 개발자 협업에 활용될 수 있음을 보여준다. 글은 Figma API가 디자이너와 개발자의 작업 흐름을 확장하는 플랫폼이 될 가능성을 강조한다.
## Figma API 출시와 커뮤니티의 반응
- Figma는 전문 디자인 도구를 위한 첫 Web API인 Figma Platform을 공개했다.
- 출시 후 며칠 만에 커뮤니티에서 다양한 프로젝트가 등장했다.
- 일부 프로젝트는 오픈 소스로 공개되어 다른 개발자가 확장하거나 재사용할 수 있었다.
- 소개된 통합 기능은 모두 제3자 프로젝트이므로 권한 설정과 유지보수는 Figma가 책임지지 않는다.
## 디자이너가 바로 사용할 수 있는 통합
### PDF 내보내기
- Figma 파일에서 프레임을 선택한 뒤 파일 URL을 웹사이트에 입력하면 PDF로 변환할 수 있다.
- 개발 지식이 없어도 사용할 수 있는 간단한 API 활용 사례다.
- Gweltaz Calori가 만든 `Figma-To-Pdf` 프로젝트는 GitHub에 오픈 소스로 공개됐다.
### 스타일 가이드 자동 생성
- Figma 문서 URL을 입력하면 문서에 사용된 폰트, 색상, 기타 스타일 정보를 분석한다.
- 분석 결과를 바탕으로 스타일 가이드 페이지를 자동으로 생성한다.
- 디자인 파일을 별도로 정리하지 않아도 현재 사용 중인 디자인 시스템을 문서화할 수 있다.
### Alexa 음성 통합
- Figma 디자인에 남겨진 댓글을 Alexa가 읽어 주는 음성 기반 통합 사례다.
- 실용성보다는 Figma API가 음성 인터페이스와도 연결될 수 있음을 보여주는 실험적 프로젝트다.
- Airbnb의 디자인 테크놀로지스트 Jon Gold가 제작했다.
## 개발자를 위한 API 활용 기반
### JavaScript 라이브러리와 GraphQL
- Jon Gold는 Figma API를 JavaScript에서 쉽게 사용할 수 있도록 비공식 `figma-js` 라이브러리를 만들었다.
- API 호출을 직접 다루는 복잡성을 줄여 JavaScript 통합 개발을 빠르게 시작할 수 있다.
- Bernardo Raposo와 Sara Vieira는 이 라이브러리를 활용해 Figma API를 GraphQL 쿼리로 사용할 수 있는 오픈 소스 커넥터를 만들었다.
- GraphQL을 이용하면 필요한 디자인 데이터만 질의하는 방식으로 API를 활용할 수 있다.
### Figma 디자인과 React 컴포넌트 동기화
- Figma 디자인을 React 등 다른 프레임워크의 코드로 자동 변환하려는 시도가 등장했다.
- PageDraw는 Figma와 React를 연결하는 통합 기능을 제공했다.
- Sara Vieira는 GraphQL 커넥터를 사용해 Figma 파일의 요소를 React 컴포넌트로 직접 렌더링하는 방식을 구현했다.
- Candis의 Florian Nagel도 Figma 디자인을 React 코드로 변환하는 자체 도구를 개발하고 오픈 소스화를 추진했다.
- 이러한 도구는 디자인과 실제 구현 사이의 변환 작업을 자동화해 디자이너와 개발자의 핸드오프 비용을 줄이는 것을 목표로 한다.
## 실용적인 시사점
Figma API는 단순한 파일 조회 기능을 넘어 문서화, 포맷 변환, 음성 인터페이스, GraphQL 질의, 프론트엔드 코드 생성까지 확장될 수 있다. 특히 디자인 시스템 자동 생성과 Figma-to-React 변환은 반복적인 협업 작업을 줄이는 데 직접적인 가치가 있으므로, API 래퍼나 오픈 소스 커넥터를 기반으로 팀의 디자인·개발 프로세스에 맞는 자동화 도구를 구축할 수 있다.
2018년 UI/UX의 중심 과제는 시각적 유행보다 사용자의 경험과 사회적 책임을 개선하는 데 있다는 전망이다. 18명의 디자이너는 접근성, 윤리, 협업, 디자인 시스템, 개발 도구의 통합을 주요 변화로 꼽았다. 동시에 표준 시스템을 무비판적으로 따르거나 효율성만 추구하는 흐름에 대한 경계도 제시한다.
## 접근성이 디자인의 우선순위가 된다
- 디자이너의 개성이나 시각적 과시보다 모든 사용자가 콘텐츠를 이해하고 사용할 수 있는지가 중요해진다.
- 필수 요소에 지나치게 옅은 회색을 사용하거나, 장식적인 애니메이션을 과도하게 적용하는 관행을 줄여야 한다.
- 접근성은 부가 기능이 아니라 제품 설계 초기부터 고려해야 할 기본 조건으로 제시된다.
- 다만 접근성·포용적 디자인은 필요한 작업임에도 업계의 관심과 참여가 부족할 것이라는 비관적인 전망도 함께 나온다.
## 디자인 협업이 엔지니어링 방식에 가까워진다
- 디자인 팀도 개발 팀처럼 체계적인 협업과 검토 절차를 도입할 것으로 예상된다.
- 코드 리뷰와 유사한 디자인 리뷰가 일반화될 수 있다.
- 디자인 도구가 코드 린터처럼 일관성이나 오류를 자동으로 점검하는 방향으로 발전할 수 있다.
- 오픈소스 엔지니어링 프로젝트처럼, 사용자 경험과 정보 설계를 위한 오픈소스 디자인 패턴이 늘어날 가능성이 있다.
## 디자이너의 윤리적 책임이 커진다
- UX/UI 디자인은 사용자의 행동과 선택에 직접 영향을 주므로, 디자이너는 자신의 영향력을 더 자각해야 한다.
- 제품의 편의성과 전환율만이 아니라 디자인 결정이 사용자와 사회에 미치는 윤리적 결과를 고려해야 한다.
- 어떤 사용자를 배제하거나 조작하는지, 정보와 선택지를 공정하게 제공하는지 검토하는 태도가 중요해진다.
## 표준 디자인 시스템의 무비판적 사용
- Material Design이나 Microsoft Fluent 같은 업계 표준 디자인 시스템에 대한 의존도가 높아질 수 있다.
- 검증된 컴포넌트와 규칙은 일관성과 개발 효율을 높이지만, 모든 제품과 사용자에게 적합한 것은 아니다.
- 표준을 그대로 적용하기보다 제품의 목적, 브랜드, 사용 맥락에 맞는지 비판적으로 판단해야 한다.
- 디자인 시스템이 창의적 문제 해결을 대체하는 처방전처럼 사용될 위험이 있다.
## 디자인과 개발 도구의 통합
- 디자인 도구와 개발 도구가 계속 수렴하면서, 하나의 중앙화된 환경에서 디자인 시스템을 만들고 다양한 기술·플랫폼에 구현하는 흐름이 강화될 것으로 보인다.
- CSS Grid와 사용자 정의 변수는 레이아웃과 스타일을 더 유연하고 효율적으로 구현하게 한다.
- Vue와 React 같은 프레임워크는 디자인 결과물을 실제 제품으로 연결하는 과정을 단순화한다.
- 구현 효율이 높아진 만큼 절약된 시간을 더 책임감 있고 포용적인 경험을 설계하는 데 사용해야 한다.
## 접근성과 효율성 사이의 긴장
- 업계는 생산성과 구현 속도를 높이는 기술에는 빠르게 반응하지만, 접근성과 포용적 디자인처럼 많은 조사와 세심한 작업이 필요한 분야에는 상대적으로 소극적이다.
- 따라서 접근성이 중요한 트렌드로 인정받더라도 실제 프로젝트 우선순위에서 밀릴 수 있다.
- 진정한 발전은 새로운 도구를 도입하는 데 그치지 않고, 효율성을 사용자 모두의 경험 개선으로 연결하는 데 달려 있다.
## 실용적인 적용 방향
디자인 팀은 접근성 검토를 초기 요구사항에 포함하고, 정기적인 디자인 리뷰와 공통 컴포넌트 검증 절차를 마련하는 것이 좋다. 또한 Material이나 Fluent 같은 표준을 그대로 복사하기보다 사용자와 제품 맥락에 맞게 조정하고, 개발 효율로 확보한 시간을 포용성·윤리성·사용성 개선에 투자해야 한다.
에어비앤비의 디자인 테크놀로지스트 젬 골드는 디자인을 결과물이 아니라 시스템과 프로세스의 산물로 바라본다. 그가 고른 다섯 권의 책은 디자인 시스템, 인간과 컴퓨터의 협업, 집중력, 명상, 함수형 프로그래밍에 대한 관점을 형성했다. 공통적으로 작은 구성 요소를 조합하고, 인간의 창의성을 확장하는 도구와 환경을 중시한다.
## 디자인을 생성하는 시스템으로 보기 — 《Designing Programmes》
- 칼 게르스트너의 책은 레이아웃·로고·타이포그래피를 개별 결과물이 아니라 일정한 규칙과 과정이 만들어내는 산출물로 설명한다.
- 디자이너가 매번 최종 결과를 직접 만드는 대신, 사람이 조정할 수 있는 디자인 파이프라인과 시스템을 설계한다는 관점을 제시한다.
- UI 디자인 시스템이 등장하기 전의 책이지만, 오늘날의 디자인 시스템과 자동화된 제작 도구에도 그대로 연결된다.
- 젬 골드는 이 관점을 에어비앤비의 디자인 시스템과 디자인 자동화 작업에 적용하고 있다.
## 반응을 늦추는 습관 — 《10% Happier》
- 명상은 즉각적인 감정이나 직관에 따라 반응하기보다, 문제를 관찰하고 더 나은 대응을 선택하게 해준다.
- 이 책은 명상 기법 안내서라기보다, 방송 중 신경 쇠약을 겪은 저널리스트 댄 해리스의 회고록에 가깝다.
- 저자는 명상에 관한 여러 주장에 회의적인 태도를 유지하며, 종교적·초월적 설명보다 실제 경험과 검증 가능성을 중시한다.
- 젬 골드는 이런 현실적이고 비판적인 태도가 디자인 의사결정에도 도움이 된다고 본다.
## 인간의 지능을 확장하는 컴퓨터 — 《The Dream Machine》
- J. C. R. 리클라이더가 주창한 ‘인간-컴퓨터 공생’과 컴퓨터의 상호작용적 활용을 다룬다.
- 컴퓨터를 펀치카드를 입력하고 결과를 오래 기다리는 기계가 아니라, 인간의 사고력을 증폭하고 함께 탐구하는 도구로 바라본다.
- IBM 중심의 정적이고 관료적인 컴퓨팅 비전에 맞서, 사람들이 즐겁게 사용할 수 있는 인터랙티브 컴퓨팅을 추구한 연구자들의 역사를 소개한다.
- 젬 골드는 기존 관습에 도전하고 인간의 능력을 확장하는 기술을 만들려는 태도를 자신의 작업에도 이어가고 있다.
## 창의성을 위한 집중력 — 《Deep Work》
- 소셜 미디어는 작업 중 주의를 끊고, 사고와 상상력을 계속 초기화해 깊은 아이디어를 형성하기 어렵게 만든다.
- 젬 골드는 한 달 동안 소셜 미디어를 끊고, 창작 작업을 위한 시간을 미리 일정에 배치했다.
- 초기에는 확인 충동을 참기 어렵지만, 달리기나 독서처럼 창의성을 회복시키는 활동으로 주의를 전환할 수 있다.
- 집중력은 단순히 방해 요소를 제거하는 것이 아니라, 창의적인 활동으로 삶의 빈자리를 채우는 습관과 관련된다.
## 작은 단위의 조합과 확장 — 《Professor Frisby’s Mostly Adequate Guide to Functional Programming》
- 함수형 프로그래밍은 문제를 가능한 한 작은 단위로 나눈 뒤, 이 요소들을 조합하고 재배열하는 방식이다.
- 짧고 무료로 읽을 수 있어 프로그래밍 입문자에게도 비교적 접근하기 쉽다.
- 젬 골드는 이 사고방식이 디자인에도 직접 적용된다고 본다.
- 큰 레이아웃이나 마케팅 페이지부터 시작해 쪼개는 대신, 가장 작은 디자인 프리미티브에서 출발해 점진적으로 구성 요소를 쌓아 올린다.
- 이는 디자인 시스템에서 재사용성과 일관성을 확보하는 데 특히 유용하다.
## 실무에 적용할 점
- 디자인을 개별 시안이 아니라 규칙·구성 요소·자동화 과정이 결합된 시스템으로 설계한다.
- 작은 프리미티브부터 시작해 복잡한 화면과 제품으로 확장한다.
- 소셜 미디어와 즉각적인 반응을 줄여 깊이 있는 작업 시간을 확보한다.
- 기술을 단순한 자동화 수단이 아니라 인간의 사고와 창의성을 강화하는 협업 도구로 활용한다.
Figma의 Team Libraries는 여러 파일과 팀원이 동일한 컴포넌트를 공유하고 동기화하도록 해 디자인 시스템 구축을 돕는 기능이다. 기존처럼 파일마다 심볼을 복사해 수동으로 교체하는 방식의 불일치 문제를 해결하고, 컴포넌트를 게시·삽입·업데이트하는 흐름으로 단일 진실 공급원을 유지한다. 이를 통해 디자인 시스템을 더 빠르고 일관되게 확장할 수 있다.
## 기존 디자인 도구의 한계
- 전통적인 디자인 도구는 사진 편집, 일러스트 제작, 정적인 화면 구성에 초점을 맞췄다.
- 실제 애플리케이션의 반응형 동작이나 플랫폼의 제약 조건을 충분히 표현하지 못했다.
- 디자인 시스템을 하나의 마스터 파일에서 관리하더라도 컴포넌트를 다른 파일로 복사하면 서로 다른 버전이 된다.
- 작은 변경도 여러 문서를 찾아 각 심볼과 오버라이드를 수동으로 수정해야 했다.
- Facebook, Google, Airbnb 같은 기업은 이러한 한계를 보완하기 위해 자체 디자인 시스템 도구와 전담 인력을 구축했다.
## Figma가 제시한 기반
- Figma는 시각 디자인과 동적인 사용자 인터페이스 설계를 연결하는 것을 목표로 했다.
- 벡터 편집, 시스템 동작에 대응하는 제약 조건, 재사용 가능한 동적 컴포넌트를 제공해 디자인 시스템의 기반을 마련했다.
- Team Libraries를 통해 이 컴포넌트를 여러 파일과 팀원 사이에서 공유할 수 있게 했다.
- 웹 기반 구조 덕분에 파일 간 동기화 지연이 거의 없고, 여러 기기와 플랫폼을 위한 레이아웃을 일관된 규칙으로 설계할 수 있다.
## 엔지니어링 원칙을 반영한 디자인 시스템
- React 같은 프레임워크처럼 애플리케이션을 명확히 정의된 작은 단위로 구성하는 방식을 디자인에도 적용했다.
- 재사용 가능하고 유지보수하기 쉬운 구조는 제품 개발 주기 전체의 효율을 높인다.
- 다만 프로그래밍 개념을 그대로 가져오기보다 디자이너가 쉽게 사용할 수 있도록 인터페이스와 작업 흐름을 단순화했다.
## 게시(Publish): 단일 진실 공급원 만들기
- 파일에서 컴포넌트를 선택하고 Inspector의 **Add to Library**를 눌러 라이브러리에 추가한다.
- 여러 컴포넌트를 선택한 뒤 변경 사항을 검토하고 팀 라이브러리에 게시한다.
- 라이브러리와 원본 파일을 분리해 디자인 시스템의 변경 권한을 통제할 수 있다.
- 원본 파일에 편집 권한이 있는 사람만 소스 컴포넌트를 수정할 수 있다.
- 원본 파일을 볼 수 있는 사람은 게시된 컴포넌트를 사용할 수 있지만 규칙 자체를 변경할 수는 없다.
- 예를 들어 프로덕션 디자이너는 아이콘을, 브랜드 디자이너는 색상 문서를 관리하고 다른 팀원은 이를 재사용할 수 있다.
## 삽입(Insert): 여러 파일에서 컴포넌트 재사용
- 라이브러리에 게시된 컴포넌트는 원본 파일을 볼 권한이 있는 팀원에게 제공된다.
- 각 파일의 툴바에서 컴포넌트 도구를 선택해 공유 컴포넌트를 삽입한다.
- 컴포넌트 안에 다른 컴포넌트를 중첩할 수 있다.
- 개별 요소로 모듈을 구성한 뒤, 이를 더 복잡한 화면과 사용자 흐름에서 재사용할 수 있다.
- 깊게 중첩된 컴포넌트도 원본과 연결되므로 단일 진실 공급원을 예측 가능하게 유지할 수 있다.
## 업데이트(Update): 변경 사항의 동기화
- 브랜드 가이드나 UI 자산을 변경할 때 기존 컴포넌트를 수정하고 다시 게시한다.
- 재게시 전 확인 단계를 거치며, 이전 버전과 무엇이 달라졌는지 시각적 diff로 확인할 수 있다.
- 원본 파일에서 컴포넌트를 삭제한 뒤 게시하면 팀 라이브러리에서도 해당 컴포넌트가 사라진다.
- 따라서 팀에는 현재 유효한 디자인 시스템 요소만 공유된다.
- 공유 컴포넌트의 변경이 여러 탐색 작업에 영향을 줄 수 있으므로, 작업 손실을 막기 위한 추가 확인 절차를 둔다.
## 실용적인 결론
Team Libraries는 디자인 시스템을 복사본이 아니라 연결된 컴포넌트 구조로 관리하게 해준다. 팀에서는 원본 파일의 편집 권한을 제한하고, 색상·아이콘·버튼·복합 모듈을 라이브러리로 게시한 뒤 변경 사항을 검토하며 재게시하는 운영 방식을 마련하는 것이 좋다.
