Figma

736 개의 포스트

www.figma.com/blog/engineering

태그로 필터

figma5분 읽기큐레이션 요약

웹에서 플러그인 시스템

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처럼 더 강한 실행 격리를 고려하는 것이 바람직하다.

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

유용한 플러그인으로 디자인

접근성을 디자인 초기부터 반영하지 않으면 시각·운동 능력 등에 제약이 있는 많은 사용자가 제품에서 배제될 수 있다. 이 글은 Figma에서 색상 대비와 키보드 포커스 순서를 점검할 수 있는 네 가지 플러그인을 소개하며, WCAG 기준을 디자인·개발 과정에 적용할 것을 권한다. 접근성 검사를 별도 단계가 아니라 디자인 워크플로의 일부로 만드는 것이 핵심이다. ## 색상 대비와 WCAG 기준 - 텍스트와 배경 사이의 충분한 대비는 다양한 시각 능력을 가진 사용자가 콘텐츠를 읽는 데 필수적이다. - WCAG는 색상 대비를 AA 또는 AAA 등급으로 평가하는 기준을 제공한다. - 소개된 플러그인들은 선택한 두 객체의 색상을 분석해 대비 비율과 기준 충족 여부를 확인한다. - 단순히 색상을 고르는 데 그치지 않고, 실제 텍스트 크기와 배경 조합을 고려해 가독성을 검증할 수 있다. ## Able: 대비 검사와 색각 이상 시뮬레이션 - 선택한 두 객체의 색상 대비를 분석한다. - 선택 영역이 바뀌면 결과도 자동으로 업데이트된다. - 텍스트와 배경 조합을 미리 볼 수 있는 프리뷰를 제공한다. - 다양한 색각 이상 유형에서 색상이 어떻게 보이는지 시뮬레이션할 수 있다. - 텍스트 색상과 배경 색상을 서로 바꿔 비교할 수 있다. - 각 색각 이상 유형별 영향을 받는 인구 비율도 확인할 수 있다. ## Contrast Checker: 대비 비율과 등급 확인 - 선택한 두 객체의 정확한 색상 대비 비율을 표시한다. - 선택된 레이어 중 텍스트 레이어가 있는지에 따라 상황에 맞는 미리보기를 제공한다. - AA/AA+와 AAA/AAA+ 등 여러 접근성 등급별 충족 여부를 보여준다. - 글꼴 크기가 18pt를 초과하는 경우에 적용되는 대비 기준도 별도로 확인할 수 있다. - Sketch 사용자에게 익숙한 Stark의 Figma용 대비 검사 도구다. ## Color Blind: 캔버스에서 보는 색각 이상 결과 - 선택한 디자인 요소가 여러 색각 이상 유형에서 어떻게 보이는지 확인한다. - 단순한 미리보기 대신, 선택한 요소를 복제해 캔버스에 직접 결과물을 생성한다. - 각 복제본은 해당 시각 유형을 나타내는 이름의 그룹으로 정리된다. - 완성된 화면 전체의 색상 체계와 정보 전달 방식이 색각 이상 사용자에게도 충분히 구분되는지 검토하는 데 유용하다. ## Focus Orderer: 키보드 탐색 순서 설계 - 브라우저가 키보드 포커스를 이동시킬 요소와 순서를 디자인에 표시한다. - 요소를 선택해 포커스 지점을 만들고, 캔버스에 순번을 표시할 수 있다. - 플러그인 UI에서 항목을 드래그하면 포커스 순서가 변경되고 캔버스의 번호도 자동으로 갱신된다. - 실제로 모든 요소를 탭 키로 순회하며 포커스 흐름을 테스트할 수 있다. - 디자인 단계에서 키보드 내비게이션을 고려하게 해, 구현 과정에서 접근성 요구사항이 누락되는 것을 줄인다. ## 접근성을 워크플로에 포함하기 - 색상 대비 검사는 시각적 가독성을, 포커스 순서 검사는 키보드 사용성을 다룬다. - 두 영역 모두 개발 완료 후 수정하기보다 디자인 단계에서 문제를 발견하는 편이 효율적이다. - WCAG 문서를 기준으로 플러그인 결과를 해석하고, 실제 사용자 환경에서의 사용성도 함께 검증해야 한다. - Figma 플러그인 API와 개발자 커뮤니티를 활용하면 팀에 맞는 접근성 검사 도구를 직접 만들 수도 있다. 이 플러그인들을 디자인 시스템과 리뷰 과정에 포함하면 접근성을 일회성 점검이 아니라 지속적인 품질 기준으로 운영할 수 있다. 특히 텍스트·배경 대비, 색각 이상 시뮬레이션, 키보드 포커스 순서를 모든 주요 화면에서 반복적으로 확인하는 것이 실용적인 접근이다.

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

와이어프레임 제작 방법 |

와이어프레임은 웹사이트나 디지털 제품의 구조와 기능을 빠르게 표현하는 설계 청사진이다. 시각적 장식보다 레이아웃과 사용자 경험에 집중하게 하므로, 팀의 의견과 사용성 조사 결과를 반영하며 아이디어를 반복적으로 개선하는 데 유용하다. 초기에는 단순하게 시작하고, 필요에 따라 시각적 디테일을 단계적으로 추가하는 것이 핵심이다. ## 와이어프레임의 의미와 역할 - 웹사이트나 디지털 제품의 **골격과 구조**를 보여주는 간단한 시각 가이드다. - 최종 디자인의 청사진이지만, 색상·그래픽·세부 스타일을 확정하는 단계는 아니다. - 디자이너뿐 아니라 기획자, 개발자, 이해관계자, 사용자도 이해할 수 있을 만큼 단순해야 한다. - 시각 요소를 최소화하면 색상이나 미적 요소에 매몰되지 않고 다음에 집중할 수 있다. - 기능이 제대로 동작하는가 - 사용자가 서비스를 어떻게 이용하는가 - 아이디어를 어떻게 개선할 수 있는가 - 확정된 결과물이 아니라 사용성 테스트와 이해관계자 피드백을 수집하기 위한 반복 설계 도구다. ## 로우 피델리티 와이어프레임 - 가장 기본적인 형태로, 종이와 펜만으로도 제작할 수 있다. - 보통 흑백 또는 회색조로 구성하며 다음을 중심으로 표현한다. - 페이지 레이아웃 - 콘텐츠의 큰 구조 - 주요 상호작용 - UI 요소와 콘텐츠는 사각형, 삼각형, 원, 선 같은 기본 도형으로 표시한다. - Figma로 제작하면 팀원과 쉽게 공유하고, 변경된 아이디어를 최신 상태로 유지할 수 있다. - 전통적인 디자인 과정에서는 손으로 그린 스케치 다음, 고해상도 목업이나 프로토타입 이전 단계에 해당한다. ## 하이 피델리티 와이어프레임 - 로우 피델리티 단계의 구조를 바탕으로 더 구체적인 시각 요소를 추가한다. - 다음과 같은 요소가 포함될 수 있다. - 브랜드를 나타내는 색상 - 그래픽과 이미지 - 글꼴 스타일 - 실제와 유사한 UI 컴포넌트 - 질감과 그림자 - 실제 이미지와 문구 - 경우에 따라 하이 피델리티 와이어프레임을 별도 단계로 거치지 않고, 로우 피델리티 와이어프레임에서 바로 프로토타입으로 진행할 수도 있다. ## 시각 요소를 단순하게 유지하기 - 와이어프레임의 목적은 완성된 디자인을 꾸미는 것이 아니라 구조와 경험을 검증하는 것이다. - 색상은 흰색, 검은색, 회색 중심의 그레이스케일로 제한하는 것이 좋다. - 타이포그래피는 정보의 위계를 전달하는 용도로 사용한다. - 글꼴은 최대 두 종류로 제한하고, 다음 방식으로 중요도를 구분한다. - 글자 크기 조절 - 굵게 또는 기울임꼴 적용 - 제목과 본문의 시각적 대비 조정 ## 이미지와 그래픽을 도형으로 표현하기 - 실제 이미지나 그래픽을 넣기보다 배치될 위치를 보여주는 단순한 기호를 사용한다. - 이미지 영역은 사각형이나 직사각형 안에 X 표시를 넣어 표현할 수 있다. - 동영상 영역은 박스 안에 재생 버튼 모양의 삼각형을 표시한다. - 이렇게 하면 콘텐츠 자체보다 화면 구성과 배치에 집중할 수 있다. ## 화면 크기와 사용 환경 고려하기 와이어프레임은 창의적인 설계 도구인 동시에 기술적 제약을 검토하는 도구이기도 하다. - **지원 기기** - 데스크톱과 모바일에서 디자인이 어떻게 달라지는지 각각 설계한다. - 반응형 레이아웃에서 콘텐츠와 UI 요소가 어떻게 재배치되는지 확인한다. - **화면 방향** - 세로형과 가로형 화면에서 레이아웃이 적절히 작동하는지 검토한다. - 기기와 방향에 따라 별도의 와이어프레임이나 변형 버전이 필요할 수 있다. - 디자인이 실제로 사용될 장소, 단계, 방식까지 고려하면 초기 단계에서 기술적 문제를 발견할 수 있다. ## 실용적인 적용 순서 - 아이디어를 빠르게 손그림이나 로우 피델리티 형태로 표현한다. - 레이아웃, 기능, 사용자 흐름에 대한 팀 피드백을 수집한다. - 사용성 조사 결과를 반영해 구조를 반복 수정한다. - 구조가 충분히 검증된 뒤 필요한 경우 색상, 이미지, 글꼴, 그림자 등 하이 피델리티 요소를 추가한다. - 협업과 버전 관리를 위해 Figma에서 공유 가능한 형태로 제작하는 것이 효과적이다.

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

워크플로우 속도를 높여주는

플러그인은 Figma에서 반복 작업을 자동화하고 디자인 데이터를 효율적으로 다루도록 돕는다. 이 글은 플러그인 생태계 출시 직후 주목할 만한 유틸리티 플러그인 5개를 소개하며, 화면 크기 조정부터 컴포넌트 복제·텍스트 편집·유사 레이어 선택까지 다양한 작업을 간소화하는 방법을 설명한다. 또한 단축키를 활용하면 플러그인을 더 빠르게 실행할 수 있다고 강조한다. ## Viewports: 기기 화면 크기 빠르게 확인 - 프레임을 스마트폰 등 일반적인 기기 화면 크기로 변경할 수 있다. - 디자인 요소에 먼저 Figma의 **Constraints**를 설정해야 화면 크기 변경에 따른 레이아웃 변화를 제대로 확인할 수 있다. - 각 뷰포트별로 해당 기기를 사용하는 사용자의 예상 글로벌 시장 점유율을 보여준다. - 이를 통해 어떤 화면 크기를 우선 고려할지 판단할 수 있다. - 플러그인은 별도의 수동 업데이트 없이 새 기능이 배포되면 사용할 수 있다. ## Component Cloner: 컴포넌트와 인스턴스 복제 - 선택한 마스터 컴포넌트만 복제하거나, 해당 컴포넌트의 인스턴스까지 함께 복제한다. - 색상 오버라이드가 적용된 아이콘을 별도로 실험하거나 아이콘 스프라이트를 제작할 때 유용하다. - 컴포넌트와 연결된 여러 인스턴스를 일일이 다시 만들 필요가 없어 반복 작업을 줄여준다. ## Nisa Text Splitter: 텍스트를 개별 객체로 분리 - 한 텍스트 박스에 입력된 여러 줄을 줄바꿈 기준으로 각각의 텍스트 박스로 분리한다. - 분리된 텍스트 객체를 알파벳순 또는 역순으로 정렬할 수 있다. - Figma의 **Smart Selections**와 함께 사용하면 여러 객체의 순서를 편리하게 재배치할 수 있다. - 반대로 여러 텍스트 박스를 하나의 텍스트 객체로 합치는 기능도 제공한다. - 목록, 메뉴 항목, 데이터 샘플처럼 줄 단위 편집이 필요한 작업에 적합하다. ## Find and Replace: 텍스트와 레이어 이름 일괄 변경 - 문서 전체에서 텍스트를 검색하고 다른 문자열로 치환한다. - 캔버스 위의 텍스트뿐 아니라 레이어 이름도 검색·변경할 수 있다. - 대소문자 구분 여부를 설정할 수 있다. - 검색 범위를 문자열의 어느 위치에 적용할지 선택할 수 있다. - 문자열 어디에서나 일치 - 문자열의 시작 부분 - 문자열의 끝 부분 - 전체 문자열이 정확히 일치 - 대규모 문서의 문구 수정이나 카피 변경 시 특히 유용하다. ## Similayer: 조건이 같은 레이어 일괄 선택 - 기준이 될 요소를 선택한 뒤, 원하는 속성을 지정해 동일한 조건의 레이어를 찾아 선택한다. - Figma의 “같은 속성을 가진 항목 모두 선택” 기능을 확장한 방식이다. - 다음과 같은 속성을 조합할 수 있다. - 테두리 반경 - 채우기 - 선 - 그림자 - 여러 속성을 동시에 조건으로 지정할 수 있어, 복잡한 디자인 요소도 빠르게 선별할 수 있다. - 유사한 레이어를 한꺼번에 수정해야 할 때 반복 클릭을 크게 줄여준다. ## 플러그인 실행 단축키 - Mac에서는 `⌘ + /`, Windows에서는 `Ctrl + /`로 메뉴 검색을 연다. - 검색창에 플러그인 이름을 입력한 뒤 키보드만으로 실행할 수 있다. - 직전에 실행한 플러그인은 다음 단축키로 다시 실행할 수 있다. - Mac: `⌘ + ⌥ + P` - Windows: `Ctrl + Alt + P` 반복적인 화면 검증, 컴포넌트 복제, 텍스트 정리, 일괄 수정이 자주 발생한다면 이 플러그인들을 작업 흐름에 맞게 조합해 사용하는 것이 좋다. 특히 플러그인 이름을 메뉴 검색으로 실행하는 습관을 들이면 마우스 조작까지 줄일 수 있다.

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

Inter의 탄생 | Figma 블

Inter는 컴퓨터 화면과 텍스트 중심의 사용자 인터페이스에서 읽기 쉽도록 설계된 오픈소스 서체다. Figma에서 작은 글씨에 Roboto의 한계를 느낀 Rasmus Andersson이 직접 개발했으며, 2017년 첫 글리프를 공개한 뒤 지속적으로 개선하고 있다. 글자는 단순히 만드는 데 그치지 않고, 다양한 문자 체계와 장기간의 조정이 필요한 5~10년 규모의 프로젝트라는 점이 핵심이다. ## UI용 서체로 시작한 배경 - Figma는 오랫동안 Google의 Roboto를 기본 서체로 사용했다. - Roboto는 제목과 본문을 모두 처리하도록 설계됐지만, Figma처럼 작은 텍스트가 많은 UI에서는 읽기 어려운 한계가 있었다. - Figma 팀은 한 달간 대안을 조사했지만 Roboto가 여전히 가장 적합하다고 판단했다. - 이 경험을 계기로 Rasmus Andersson은 특정 목적 없이 범용적으로 쓰이는 서체가 아니라, 컴퓨터 UI에만 집중한 서체를 만들기로 했다. - Inter는 2017년 8월 첫 글리프가 공개됐고, 이후 계속 업데이트되고 있다. ## 예상보다 훨씬 큰 서체 제작 작업 - Rasmus는 이전에 취미로 서체를 만들거나 Spotify에서 디스플레이용 서체를 제작한 경험은 있었지만, 본문용 대규모 서체는 처음이었다. - 처음에는 완성까지 약 1년이 걸릴 것으로 예상했다. - 그러나 실제로는 완성도 있게 발전시키는 데 5~10년이 걸릴 수 있는 장기 프로젝트임을 깨달았다. - 서체 제작은 글자 모양뿐 아니라 글자 간 간격, 크기 비율, 다양한 굵기와 언어 지원까지 함께 설계해야 하는 작업이다. ## 문자 체계별 설계의 복잡성 - 전 세계에는 널리 인정되는 문자 체계만 150개 이상 존재한다. - 라틴 문자 외에도 그리스 문자, 키릴 문자, 아랍 문자, 한글 등은 글자 구조와 조판 방식이 크게 다르다. - 대문자와 소문자의 개념, 글자 간 간격, 획의 구조가 문자 체계마다 다르기 때문에 하나의 서체 가족으로 모두 지원하는 데는 평생이 걸릴 수도 있다. - Rasmus는 자신에게 익숙한 라틴 문자부터 시작했고, 첫해에 가장 많이 사용되는 라틴 문자 약 200자를 구현했다. ## Roboto를 활용한 초기 확장 - 초기 Inter는 라틴 문자 외의 글자를 빠르게 확보하기 위해 Roboto의 글리프를 가져와 사용했다. - 오랫동안 키릴 문자의 일부와 그리스 문자의 상당수가 Roboto에서 비롯됐다. - 이 때문에 Inter는 한동안 이중 라이선스 방식으로 배포됐다. - 이후 프로젝트가 발전하면서 해당 글리프를 하나씩 Inter의 시각적 스타일에 맞게 다시 제작했다. - 기존 서체를 임시 기반으로 활용한 덕분에 처음부터 모든 문자를 직접 만들지 않고도 빠르게 범위를 넓힐 수 있었다. ## 소문자와 대문자의 비율 - Rasmus는 Roboto의 소문자 x-height와 대문자 높이의 비율을 특히 긍정적으로 평가했다. - 소문자 x와 대문자 X의 높이를 비교하면, 서체마다 대문자와 소문자의 상대적 크기가 크게 다르다. - Roboto는 소문자와 대문자의 크기 차이가 균형 잡혀 있어 작은 화면에서도 안정적인 인상을 준다. - 이러한 비율은 San Francisco, Akkurat, Graphik, Aeonik, Helvetica 등 여러 현대적 그로테스크 계열 서체에서도 공통적으로 나타난다. - Inter 역시 화면에서 텍스트가 또렷하고 일관되게 보이도록 이런 비율과 크기 관계를 중요하게 다뤘다. ## 서체는 지속적으로 발전하는 시스템 - Inter는 한 번 완성해 배포하는 고정된 결과물이 아니라, 새로운 글리프와 언어 지원을 추가하며 계속 다듬는 프로젝트다. - 라틴 문자로 시작하더라도 국제적인 서체가 되려면 그리스어, 키릴 문자 등 다양한 문자를 동일한 디자인 언어 안에 통합해야 한다. - 따라서 오픈소스 공개는 완성의 끝이 아니라, 더 많은 사용과 피드백을 통해 서체를 발전시키는 출발점으로 기능한다. UI나 제품용 서체를 선택할 때는 단순히 글자 모양만 비교하기보다 작은 크기에서의 가독성, 대문자·소문자 비율, 지원 언어, 라이선스와 장기 유지 가능성까지 함께 검토하는 것이 좋다. Inter의 사례는 좋은 UI 서체가 명확한 사용 목적과 지속적인 개선 과정을 통해 만들어진다는 점을 보여준다.

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

디자인 스프린트 진행

디자인 스프린트는 복잡한 문제를 짧은 기간 안에 팀이 함께 해결하기 위한 방법론으로, 보통 5일 동안 진행된다. 이해, 정의, 스케치, 결정, 프로토타입, 검증의 여섯 단계를 거치며, 빠른 정렬과 사용자 테스트를 통해 아이디어의 실행 가능성을 확인한다. 성공적인 스프린트를 위해서는 진행 자체보다 사전 준비와 적절한 팀 구성이 중요하다. ## 디자인 스프린트의 목적과 구조 - 디자인, 프로토타이핑, 사용자 조사와 테스트를 결합해 큰 문제를 해결한다. - 제한된 기간과 명확한 목표·산출물을 설정해 팀이 공동의 방향에 빠르게 합의하도록 한다. - 일반적으로 다음 여섯 단계로 진행된다. - **Understand**: 문제와 사용자, 기존 데이터를 이해한다. - **Define**: 해결할 핵심 문제와 목표를 구체화한다. - **Sketch**: 다양한 해결 아이디어를 개별적으로 제안한다. - **Decide**: 가장 유망한 아이디어를 선택한다. - **Prototype**: 선택한 아이디어를 검증 가능한 형태로 만든다. - **Validate**: 실제 사용자에게 테스트해 가설을 확인한다. - 새 프로젝트의 시작, 일정이 촉박한 상황, 정체된 제품이나 팀을 다시 움직여야 할 때 활용할 수 있다. ## 구글에서 시작된 디자인 스프린트 - 구글은 조직 내 UX 문화와 디자인 리더십을 강화하기 위해 디자인 스프린트 방법론을 발전시켰다. - 전통적인 UX, IDEO, 스탠퍼드 d.school, 비즈니스 전략, 심리학의 사고방식과 프로세스를 바탕으로 한다. - 기본 프레임워크는 고정된 규칙이라기보다 조직의 문제와 일정에 맞게 수정할 수 있는 유연한 방법이다. ## 명확한 스프린트 브리프 작성 - 브리프에는 다음 내용을 포함해야 한다. - 해결할 문제와 목표 - 기대하는 산출물 - 일정과 진행 방식 - 프로젝트 배경 - 기존 사용자 조사와 관련 데이터 - 스프린트는 한 번에 하나의 큰 과제에 집중해야 한다. - “홈페이지를 더 구매하기 쉽게 만든다”보다 “전환율을 높이기 위해 특정 사용자 흐름을 재설계한다”처럼 답해야 할 질문을 하나로 명확히 표현하는 것이 좋다. - 이미 확보한 정보를 미리 제공하면 스프린트 중 자료를 찾느라 시간을 낭비하지 않을 수 있다. ## 적절한 팀 구성 - 참가자는 보통 5~7명으로 제한한다. - 인원이 많다면 같은 문제를 다루는 소규모 그룹으로 나누는 것이 좋다. - 스프린트 이후 실제 실행을 담당할 사람을 반드시 포함해야 한다. - 일반적으로 다음 역할이 참여한다. - UX 디자이너 - 사용자 연구자 - 제품 관리자 - 개발자 - 주요 의사결정권자 또는 리더십 구성원 - 다양한 직무의 참여는 더 많은 아이디어와 여러 형태의 프로토타입을 만드는 데 도움이 된다. ## 목적에 맞는 일정 설계 - 기본 일정은 여섯 단계의 순서를 따른다. - 팀이 이미 문제 영역을 충분히 알고 있다면 **Understand** 단계에 시간을 적게 배정하고 프로토타이핑에 더 투자할 수 있다. - 팀의 지식 수준, 목표, 전체 일정에 따라 단계별 시간을 조정해야 한다. - 스프린트 기간만큼의 준비 시간을 별도로 확보하는 것이 권장된다. 예를 들어 5일 스프린트라면 준비에도 충분한 시간을 투입해야 한다. ## 시각 자료와 사전 정보 준비 - 현재 웹사이트나 제품 화면의 스크린샷을 준비한다. - 참고할 만한 영감과 경쟁 제품 자료를 수집한다. - 데이터, 기존 사용자 조사, 제품 사용 현황과 관련된 요약 자료를 한곳에 정리한다. - 발표 자료나 보드 등 팀이 진행 중 빠르게 확인할 수 있는 시각 자료로 제공한다. - 사전에 충분한 사용자 조사를 수행하면 팀이 근거 없이 아이디어를 만드는 일을 줄일 수 있다. - 기존 데이터는 사용자가 현재 제품을 어떻게 이용하는지, 어떤 행동 변화를 유도해야 하는지 파악하는 데 활용된다. ## 전문가 발표와 라이트닝 토크 - 외부 전문가나 조직 내 관련 담당자를 초대해 새로운 관점을 제공할 수 있다. - 구글의 방식에서는 이를 **라이트닝 토크**라고 하며, 보통 10~15분의 짧은 발표로 진행한다. - 발표 주제의 예시는 다음과 같다. - 고객지원팀의 고객 조사 결과 - 분석 담당자의 경쟁사 분석 - 제품 관리자의 제품 성과 검토 - 발표자는 미리 섭외해야 하며, 직접 참석이 어렵다면 전화나 화상회의로 참여시킬 수 있다. ## 창의성을 지원하는 환경 조성 - 밝고 참가자가 공간을 자유롭게 바꿀 수 있는 장소를 선택한다. - 가구를 이동하거나 벽면 화이트보드를 활용할 수 있는 공간이 유리하다. - 일주일 내내 같은 장소에 머무르기보다 카페나 공원 등으로 장소를 바꾸는 것도 새로운 사고를 촉진할 수 있다. - 아이스브레이커를 활용하면 참가자들이 서로 편안해지고 창의적인 사고를 시작하는 데 도움이 된다. - 스프린트에 필요한 문구류와 기타 준비물을 미리 확보해야 한다. ## 실용적인 적용 방법 디자인 스프린트를 시작하기 전, 해결할 질문을 하나로 좁히고 필요한 데이터와 발표자를 먼저 준비하는 것이 좋다. 또한 아이디어를 내는 사람뿐 아니라 스프린트 결과를 실제로 구현할 담당자까지 참여시켜야 하며, 정해진 여섯 단계를 조직의 상황에 맞게 조정하는 것이 효과적이다.

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

업무 자동화, 데이터 활용,

Figma는 2019년 8월, 누구나 플러그인을 사용하고 직접 만들 수 있는 공개 플러그인 플랫폼을 출시했다. 플러그인은 반복 작업 자동화, 실제 데이터·이미지 활용, 접근성 검사 등 Figma의 기능을 확장하며 디자이너가 필요한 도구를 직접 만들 수 있게 한다. Figma는 웹 개발과 유사한 프로그래밍 경험을 제공하면서도 플러그인의 보안성·안정성·성능을 확보하는 것을 목표로 했다. ## 플러그인 플랫폼을 만든 배경 - 기존 디자인 플러그인에는 두 가지 문제가 있었다. - 공식적으로 충분히 지원되지 않는 API를 사용하는 경우가 많아 안정성과 보안이 떨어졌다. - 디자이너가 직접 코딩하지 못하면 필요한 플러그인을 다른 사람이 만들어주길 기다려야 했다. - Figma는 플러그인을 단순한 부가 기능이 아니라 디자이너의 작업 흐름을 강화하는 “파워업”으로 정의했다. - 내부 목표는 “기본적인 HTML과 JavaScript로 웹 페이지를 만들 수 있다면 Figma 플러그인도 만들 수 있어야 한다”는 것이었다. - 웹 기반 디자인 도구를 위한 플러그인 아키텍처를 새롭게 설계했으며, 이를 통해 더 많은 개발자가 창의적인 플러그인을 만들 수 있도록 했다. ## 누구나 사용하고 만들 수 있는 생태계 - 베타 공개 6주 만에 40개 이상의 공개 플러그인이 제공됐다. - Figma 제품 안에서 플러그인을 검색하고 한 번의 클릭으로 설치할 수 있다. - 디자인 파일에서 마우스 오른쪽 버튼을 클릭해 사용 가능한 플러그인을 실행할 수 있다. - Figma Organization 요금제에서는 다음 기능도 제공된다. - 회사 내부용 비공개 플러그인 제작 및 배포 - 관리자가 승인된 플러그인 목록을 큐레이션 - 관리자가 조직 구성원을 대신해 플러그인 설치 ## 반복 작업을 자동화하는 유틸리티 플러그인 - **Similayer** - 비슷한 속성을 가진 레이어를 한꺼번에 선택한다. - 여러 레이어를 일괄 수정해야 하는 반복 작업을 줄여준다. - **Super Tidy** - 프레임 이름을 정리하고 레이어 목록의 순서를 재배치한다. - 디자인 파일의 구조와 탐색성을 개선한다. - 이런 플러그인은 픽셀 단위의 수작업을 줄이고, 디자이너가 더 중요한 설계 작업에 집중하도록 돕는다. ## 실제 콘텐츠와 시각 자료를 가져오는 플러그인 - **Unsplash** - Unsplash의 이미지를 Figma 파일에 직접 삽입할 수 있다. - 이미지 검색과 배치 과정을 간소화해 디자인 작업에 실제 시각 자료를 빠르게 반영한다. - **Content Reel** - 텍스트, 아바타, 아이콘 등 디자인에 필요한 콘텐츠를 검색하고 배치한다. - 더미 데이터 대신 맥락에 맞는 콘텐츠를 사용해 현실적인 시안을 만들 수 있다. - 이러한 플러그인은 디자인 시스템이나 화면 설계 단계에서 콘텐츠를 수동으로 준비하는 부담을 줄인다. ## 접근성 문제를 발견하는 플러그인 - **Contrast Checker** - 색상, 시각 요소, 타이포그래피의 대비 수준을 검사한다. - 읽기 어렵거나 가독성이 낮은 디자인을 식별하는 데 도움을 준다. - **Color Blind** - 8가지 색각 이상 유형을 기준으로 디자인이 어떻게 보이는지 확인한다. - 디자이너가 다양한 사용자의 시각적 경험을 이해하고 접근성을 개선하도록 돕는다. - 플러그인은 디자이너가 육안으로 놓치기 쉬운 접근성 문제를 작업 과정에서 조기에 발견하게 한다. ## 플러그인이 확장하는 디자인 작업 방식 - 플러그인은 Figma에 없는 기능을 외부 도구로 보완하는 수준을 넘어, 팀과 개인의 고유한 작업 방식에 맞는 도구를 만들게 한다. - 디자이너는 엔지니어링 리소스를 기다리거나 다른 사람이 만든 도구에 의존하지 않고, 필요한 기능을 직접 구현할 수 있다. - Figma는 공개 플러그인과 조직 전용 플러그인을 함께 지원해 개인 창작자와 기업 팀 모두를 플랫폼에 참여시켰다. 플러그인은 반복 업무 자동화, 실제 콘텐츠 활용, 접근성 검증처럼 디자인 프로세스의 구체적인 문제를 해결하는 수단이다. Figma를 사용하는 팀이라면 자주 반복되는 작업과 품질 검사를 먼저 찾아보고, 적합한 공개 플러그인을 도입하거나 조직 전용 플러그인으로 직접 자동화하는 것이 효과적이다.

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

플러그인 비하인드

재키 추이는 Microsoft의 UX 디자이너이자 Figma API와 플러그인 베타 초기 사용자로, 디자이너의 작업을 더 빠르고 효율적으로 만드는 도구를 개발해왔다. 그는 접근성 기능을 만들기 위한 해커톤에서 Figma API를 접한 뒤 플러그인 개발에 매료되었고, 개인 프로젝트를 커뮤니티용 플랫폼으로 확장했다. 이 인터뷰는 디자이너와 개발자의 경계가 가까워지는 흐름과 Figma 플러그인 생태계의 가능성을 보여준다. ## 디자이너이자 도구 제작자가 된 배경 - 어린 시절 LEGO로 무언가를 만들고 발명하는 것을 좋아했던 경험이 UX 디자인과 개발에 대한 관심으로 이어졌다. - UX 디자이너로 일하면서 코딩을 익혀 자신이 설계한 제품을 직접 구현할 수 있게 되었다. - 다른 사람들이 만든 작업을 관찰하고, 서로 다른 아이디어를 연결해 자신의 프로젝트에 적용하는 방식으로 영감을 얻는다. - 디자인과 개발을 함께 수행하며 아이디어가 실제 결과물로 완성되는 과정을 중요하게 여긴다. ## Figma API를 접한 계기 - 2018년 Microsoft OneWeek Hackathon에서 팀원들과 디자인 도구에 접근성 기능을 추가하는 프로젝트를 진행했다. - Figma가 웹 기반으로 만들어졌다는 점에 흥미를 느껴 Figma 플랫폼과 API를 탐색하기 시작했다. - API를 이용해 사용자 동작을 프로그래밍 방식으로 시뮬레이션할 수 있다는 사실을 발견하면서 본격적으로 플러그인 개발에 빠져들었다. - 기능을 하나씩 발견할 때마다 새로운 가능성이 열린다고 느꼈으며, 공식 API의 사용 편의성과 안정성을 높이 평가했다. ## 개발한 Figma 플러그인 - **Find and Replace** - Figma 커뮤니티를 위해 만든 대표적인 플러그인이다. - 디자인 파일 안의 텍스트나 요소를 찾아 일괄적으로 변경하는 작업을 지원한다. - **Paste to Fill** - 복사한 콘텐츠를 디자인 요소의 채우기 영역에 적용하는 도구다. - **Button Resizer** - 버튼의 크기를 보다 쉽게 조정할 수 있도록 돕는다. - 이외에도 Microsoft의 업무와 일반 Figma 사용자 모두에게 유용한 다양한 플러그인을 제작했다. ## Figma Plus로 확장된 개인 프로젝트 - 초기에는 브라우저에서만 동작하는 Chrome 확장 프로그램 형태로 플러그인을 만들었다. - 커뮤니티의 긍정적인 반응을 통해 Figma 데스크톱 앱에서도 사용할 수 있는 도구에 대한 수요를 확인했다. - Mirko Santangelo, Ahmad Al Haddad와 협업해 자신들이 알고 있던 Figma API 지식을 통합하는 플랫폼을 개발했다. - 작은 프로젝트로 시작했지만 다음 요소를 포함한 완전한 시스템으로 발전했다. - 자체 API - 플러그인 스토어 - 플러그인 게시 및 배포 프로세스 - Figma가 공식적으로 플러그인 베타를 시작하자 팀도 베타 프로그램에 참여했다. - 추이는 여러 플러그인 중에서도 역설적으로 이 대규모 시스템 프로젝트인 **Figma Plus**를 가장 자랑스럽게 여긴다. ## 디자인과 개발의 미래 - 앞으로 5년 동안 디자이너와 개발자는 업무 과정에서 더욱 긴밀하게 협업하게 될 것으로 전망한다. - 미래의 디자인 도구는 현재 존재하는 디자인과 개발 사이의 간극을 줄일 것이다. - 디자이너가 기본적인 코딩 역량을 갖추고 직접 도구를 제작하는 흐름이 이런 변화를 촉진할 수 있다. ## Figma 커뮤니티를 위한 개발 - Microsoft에서 Figma가 주요 디자인 도구로 자리 잡았기 때문에, 팀의 업무 흐름을 개선하는 플랫폼 위에서 개발하는 것이 자연스러운 선택이었다. - 내부 업무용 도구를 만드는 데서 멈추지 않고, 더 넓은 Figma 커뮤니티에 공개해 다른 사용자에게도 혜택을 주려 했다. - 2019년 8월 1일부터 추이의 플러그인들이 Figma 커뮤니티에 공개될 예정이었다. 디자이너가 자신의 반복 작업과 불편을 직접 관찰하고 Figma API로 해결책을 구현하면, 업무 효율을 높이는 동시에 커뮤니티 전체에 기여할 수 있다. 이 사례는 디자인 도구를 단순히 사용하는 것을 넘어, 필요한 기능을 직접 만들고 공유하는 방식이 Figma 생태계를 확장한다는 점을 보여준다.

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

igma Blog": "피

Matt DesLauriers는 코드와 예술을 결합해 규칙과 매개변수로 독창적인 이미지를 생성하는 제너레이티브 아티스트이자 크리에이티브 코더다. 그는 코드를 붓이나 펜처럼 활용하며, 컴퓨터의 반복 연산과 예측하지 못한 결과를 창작 과정에 포함한다. Figma 플러그인을 통해 디자이너와 개발자가 서로의 영역을 탐험하고, 제너레이티브 아트를 더 쉽게 접할 수 있도록 하는 것이 그의 목표다. ## 제너레이티브 아트를 시작한 계기 - 어릴 때부터 게임을 플레이하기보다 게임을 개조하고 해킹하며 다시 디자인하는 데 관심이 많았다. - 2014년 JavaScript로 브라우저 기반의 작은 데모를 만들면서 제너레이티브 아트를 접했다. - 단순한 규칙과 매개변수만으로 시간이 지나며 변화하고 매번 새로운 이미지를 생성하는 방식에 매료됐다. - 복잡한 예술 작품이 간단한 시스템에서 출현하는 ‘창발성(emergence)’을 핵심적인 탐구 대상으로 삼았다. ## 대표 프로젝트: LUMOS - 친구 Jean-Michel Gariepy, Steven Mengin과 함께 인터랙티브 조명 조형물 **LUMOS**를 제작했다. - 작품은 캐나다 토론토에서 열린 2018년 Ontario Place Park Winter Light Exhibition에 전시됐다. - 관람객과 빛, 소프트웨어가 상호작용하는 형태로 예술과 기술의 결합을 구현한 프로젝트다. ## 코드와 예술의 결합 - Matt에게 코드는 기계와 창작자를 연결하는 도구이며, 붓이나 펜과 같은 창작 매체다. - 창작자는 코드에 지시, 규칙, 매개변수를 정의하고 컴퓨터는 이를 초당 수백만 번 실행할 수 있다. - 컴퓨터의 빠른 반복 처리 덕분에 인간의 상상력과 작업 속도의 한계를 확장할 수 있다. - 코드의 오류나 예상 밖의 실행 결과도 새로운 작품의 아이디어로 발전할 수 있다. - 따라서 제너레이티브 아트는 창작자가 모든 결과를 통제하는 방식이 아니라, 시스템과 함께 결과를 발견하는 협업에 가깝다. ## Figma 플러그인을 만드는 이유 - 디자이너가 코드를 탐구하고 개발자가 디자인을 경험하도록 돕는 것이 목표다. - 코더와 비코더 모두 제너레이티브 아트와 크리에이티브 코딩을 쉽게 접할 수 있는 도구를 만들고자 한다. - 소개된 플러그인에는 다음과 같은 유형이 포함된다. - 애니메이션 제작 플러그인 - 이미지에서 색상 팔레트를 추출하고 조합을 제안하는 플러그인 - 매개변수를 조정해 디자인을 생성하는 파라메트릭 디자인 도구 ## 인상 깊게 본 Figma 기능 - 숫자 입력 필드에 `25 / 2`처럼 수학식을 입력하면 자동으로 계산되는 세부 기능을 좋아한다고 설명했다. - 복잡한 기능뿐 아니라 작업 흐름을 빠르게 만드는 작은 상호작용과 편의성이 도구의 완성도를 높인다고 본다. ## 디자인 산업에 대한 제안 - 더 개방적이고, 해킹 가능하며, 실험적인 도구가 필요하다고 주장한다. - 디자이너, 개발자, 예술가 등 창작 분야 사이의 경계가 더 흐려져야 한다고 본다. - 서로 다른 전문성을 연결하는 도구가 새로운 창작 방식과 협업을 촉진할 수 있다고 강조한다. ## 실용적인 결론 제너레이티브 아트를 시작하려면 JavaScript 같은 언어로 간단한 규칙과 매개변수를 정하고, 반복 실행을 통해 결과가 어떻게 변화하는지 관찰하는 방식이 유용하다. 완벽하게 결과를 통제하기보다 오류와 우연까지 창작 과정에 포함하면 새로운 시각적 아이디어를 발견할 수 있다.

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

플러그인 비하인드

Yitong Zhang은 Coinbase에서 디자이너가 단순히 PRD를 실행하는 역할을 넘어 제품 전략과 문제 정의에 참여해야 한다고 강조한다. 그는 Figma API를 활용해 두 객체를 선으로 연결하는 자동 플로우 플러그인을 개발하며, 디자인 도구와 커뮤니티의 확장 가능성을 보여준다. 앞으로 디자이너는 픽셀 단위 작업보다 시스템 구축, 전략 수립, 브랜드 경쟁력 강화에 더 집중하게 될 것이라고 전망한다. ### 창업 경험에서 출발한 디자인 - Yitong은 처음부터 디자이너였던 것이 아니라, 스타트업 창업자로서 여러 역할을 수행하며 기술 업계에 들어왔다. - 창업이 실패한 뒤 생계를 위해 디자이너가 되었고, 디자인이 유용한 것을 상상하고 실제로 만들어내는 창업의 즐거운 부분과 닮았다고 설명한다. - 과거 좋아하는 애니메이션의 팬아트를 만들며 디자인 도구를 익힌 경험도 디자이너로 전환하는 데 도움이 되었다. ### Figma API로 만드는 자동 플로우 플러그인 - 개발 중인 플러그인은 **Auto Flow**로, Figma 안의 두 객체를 선으로 연결해 플로우 다이어그램을 빠르게 만들 수 있도록 한다. - 사용자가 객체를 직접 배치하고 연결선을 조정하는 반복 작업을 줄이는 것이 목적이다. - Yitong은 Figma API가 강력하고 사용하기 좋으며, Figma가 디자인의 미래라고 생각하기 때문에 Figma 커뮤니티를 위한 도구를 만든다고 말한다. ### Coinbase에서 디자인의 역할 확장 - Yitong이 가장 자랑스럽게 생각하는 성과는 Coinbase에서 디자인 프로세스를 발전시킨 일이다. - 디자인팀이 제품 요구사항(PRD)을 전달받아 실행하는 조직에서 벗어나, 제품 전략을 함께 만드는 동등한 파트너가 되었다. - 이는 디자인을 시각적 결과물 제작이 아니라 문제와 방향을 정의하는 활동으로 확장한 변화다. ### 문제 정의 단계에 참여하는 디자이너 - 좋은 제품은 잘못된 문제 정의에서 나올 수 없으므로, 디자이너가 해결책을 만드는 단계보다 먼저 문제를 정의하는 과정에 참여해야 한다. - 초기 단계부터 참여하면 제품의 영향력과 윤리적 결과까지 고려할 수 있다. - 디자이너가 제품 개발 후반의 실행자에 머물지 않고, 어떤 문제를 해결할지 결정하는 역할을 맡아야 한다는 주장이다. ### 디자인 직무의 미래 - 제품 디자이너의 업무는 세밀한 픽셀 조정에서 시스템 구축과 전략 정의 중심으로 이동할 것으로 전망한다. - 기술 기업이 브랜드를 강력한 경쟁 우위로 인식하면서 브랜드 디자인은 더욱 중요해지고, 제품 디자인과는 별도의 전문 영역으로 발전할 수 있다. - 디자이너에게는 화면 제작 능력뿐 아니라 시스템적 사고와 비즈니스 전략 이해가 요구될 가능성이 커진다. ### 다른 분야에서 얻는 영감 - Yitong은 자신의 분야와 최대한 거리가 먼 영역에서 영감을 얻으려 한다. - 시스템 수준의 디자인 작업을 하면서 건축을 탐구하는 것이 특히 유익했다고 말한다. - 익숙한 디자인 사례만 참고하기보다 건축처럼 구조, 관계, 시스템을 다루는 분야에서 새로운 관점을 얻는 방식이다. 디자이너는 화면을 예쁘게 만드는 역할에만 머무르지 말고, 제품의 문제 정의와 전략 수립 단계부터 참여하는 것이 좋다. 또한 Figma 플러그인처럼 반복 작업을 자동화하는 도구를 직접 만들고, 건축 등 다른 분야의 시스템적 사고를 배우면 디자인의 영향력을 넓힐 수 있다.

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

플러그인 비하인드

티파니 첸은 Microsoft의 접근성과 포용성 팀에서 일하며, Figma 플러그인으로 접근성 주석 작성 과정을 자동화하고 있다. 그녀는 플러그인이 디자이너가 필요한 기능을 직접 만들 수 있게 해 주며, 접근성 향상과 디자인 진입 장벽 완화에 기여한다고 본다. 또한 다양한 전공과 배경을 가진 사람들이 디자인에 참여할수록 더 풍부하고 포용적인 결과를 만들 수 있다고 강조한다. ## 접근성 주석 작업을 자동화하는 플러그인 - 티파니가 개발 중인 플러그인은 **접근성 중심의 주석(annotation) 도구**다. - 디자인에 접근성 관련 정보를 표시하는 수작업을 자동화해 반복적인 작업을 줄이는 것을 목표로 한다. - Microsoft의 내부·외부 접근성 강화 노력과 맞닿아 있으며, 포용적인 제품 경험에 대한 인식을 높이려는 목적이 있다. - 이 프로젝트는 티파니가 처음 만든 Figma 디자인 플러그인이기도 하다. ## Figma 플러그인을 선택한 이유 - 새로운 플러그인 시스템과 Figma API가 사용하기 쉬워 설정이나 디버깅보다 실제 제작에 더 많은 시간을 쓸 수 있었다. - 기존 디자인 도구가 모든 디자이너의 요구를 충족할 수는 없지만, 플러그인을 통해 필요한 기능을 직접 만들 수 있다. - 다른 개발자가 기능을 추가해 주기를 기다리는 대신, 자신과 커뮤니티에 필요한 도구를 직접 제안하고 구현할 수 있다. - Figma 커뮤니티가 친절하고 협력적이라는 점도 개발 동기가 됐다. ## 다양한 배경이 디자인에 주는 가치 - 티파니는 심리학, 인류학, 국제관계, 컴퓨터과학 등 비전통적인 배경을 가진 사람들이 디자인에 진입하는 것을 돕고 싶어 한다. - 다양한 경험과 지식은 디자인 커뮤니티에 새로운 관점과 문제 해결 방식을 제공한다. - 컴퓨터과학 배경 덕분에 디자인을 평가하고 구현할 때 **기술적 실현 가능성**과 **새로운 시도** 사이에서 균형을 잡는 편이라고 설명한다. - 디자인이 특정 전공자만의 영역이 되지 않도록 진입 장벽을 낮추는 것이 중요하다고 본다. ## 기술과 창작을 결합한 작업 - 가장 자랑스러운 프로젝트로 사람들에게 “어릴 때 어떤 거짓말을 들었나요?” 같은 질문을 던지고, 그 답변을 이야기와 일러스트로 발전시킨 작업을 꼽았다. - 참여자들의 경험을 시각화해 아트 디렉션 웹사이트로 제작했다. - 레이어링과 패럴랙스 효과를 활용해 이야기를 입체적으로 표현했다. - 이 프로젝트를 통해 기술적 역량과 창의적 작업을 결합하는 데 흥미를 느끼게 됐다. ## 사회적 영향을 고려하는 기업관 - 티파니는 B Corporation의 원칙에 관심을 보였다. - B Corp 인증 기업은 의사결정 시 노동자, 고객, 공급업체, 환경에 미치는 영향을 함께 고려한다. - Ben & Jerry’s, Kickstarter, Patagonia 등이 대표적인 B Corp 사례로 언급된다. - 이는 제품과 기업 활동이 수익뿐 아니라 사회와 환경에 미치는 영향까지 책임져야 한다는 관점과 연결된다. ## 더 포용적인 디자인 생태계 - 디자인 업계에는 모든 사람을 포괄하는 제품과 경험에 대한 인식이 더 필요하다. - 동시에 디자이너가 되려는 사람들의 진입 장벽도 낮아져야 한다. - 온라인에 공개된 학습 자료가 늘면서 이러한 장벽은 점차 낮아지고 있다. - 단순하면서도 강력한 도구인 Figma와 플러그인 생태계가 이 변화를 더욱 빠르게 만들 수 있다고 기대한다. 접근성을 별도의 사후 작업으로 다루기보다 디자인 과정에 자연스럽게 통합하려면, 반복적인 접근성 검토를 자동화하는 도구를 적극 활용하는 것이 좋다. 또한 디자인 팀은 다양한 전공과 배경의 구성원이 참여할 수 있도록 학습 자료와 제작 도구를 개방하는 방향을 고려할 필요가 있다.

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

플러그인 뒷이야기:

Figma 플러그인은 디자이너가 반복적이고 번거로운 작업을 자동화해 더 의미 있는 디자인 작업에 집중하도록 돕는다. Cloudflare의 UX Engineer Sam Mason de Caires는 번역, 데이터 교체, 테마 생성, 그래프, 색각 이상 대응 등 다양한 플러그인을 만들며 디자인과 개발의 결합 가능성을 보여준다. 그는 앞으로 디자인 도구가 데이터를 바탕으로 여러 디자인 변형을 생성하고, 디자이너가 그중 최선의 결과를 선택하는 방향으로 발전할 것이라고 전망한다. ## 플러그인 생태계의 출발 - Figma는 2019년 플러그인 베타를 시작했고, 첫 고객들이 다양한 도구를 제작했다. - 플러그인의 활용 사례로 데이터 시각화, 콘텐츠 가져오기, 접근성 도구 등이 소개된다. - Figma는 플러그인 제작자들의 동기와 작업물을 소개하는 5부작 인터뷰 시리즈를 진행했다. - Sam Mason de Caires는 Figma 커뮤니티를 위한 초기 플러그인 제작자 중 한 명이다. ## 디자인과 개발의 결합 - Sam은 무언가를 처음부터 만들어 사람들이 실제로 사용하는 모습을 보는 데 매력을 느껴 개발자가 되었다. - 동시에 디자인에도 관심이 있었으며, 디자인과 개발 사이에 큰 교차점이 있다고 보았다. - Cloudflare에서는 개발 역량을 활용해 디자인 프로젝트에 실질적으로 기여하고 있다. - 플러그인 API는 디자인 도구 내부의 코드와 데이터에 접근할 수 있게 해, 개발자가 디자이너를 위한 생산성 도구를 만들 수 있도록 한다. ## 제작 중인 Figma 플러그인 - 번역 플러그인: 디자인 콘텐츠를 여러 언어로 변환하는 작업을 지원한다. - 데이터 교체 플러그인: 화면에 들어간 데이터를 빠르게 다른 값으로 바꿀 수 있다. - 테마 UI 생성기: 테마에 맞는 사용자 인터페이스 요소를 자동으로 생성한다. - 그래프 플러그인: 데이터를 시각적인 그래프로 표현한다. - 색상 참고 플러그인: 색각 이상 사용자가 색상을 어떻게 인식하는지 확인해 접근성을 개선한다. - 이 도구들은 디자이너가 수작업으로 반복하던 작업을 줄이고, 더 빠르고 자신 있게 디자인하도록 돕는 것을 목표로 한다. ## 자동화가 디자이너에게 주는 가치 - 반복 작업을 자동화하면 디자이너가 실제 문제 해결과 시각적 의사결정에 더 많은 시간을 사용할 수 있다. - 플러그인은 단순한 편의 기능을 넘어 디자인 프로세스 자체를 확장하는 수단이 된다. - 개발자는 디자인 도구의 내부 구조와 API를 활용해 디자이너가 직접 만들기 어려운 기능을 제공할 수 있다. - Sam은 개발자의 기술이 커뮤니티에 직접 도움이 되지 않을 것이라고 생각했지만, 플러그인을 만들면서 디자인 생산성과 신뢰도를 높일 수 있음을 깨달았다. ## 생성형 디자인의 미래 - Sam은 향후 5년 동안 생성형 디자인이 크게 발전할 것으로 예상한다. - 디자이너가 가능한 모든 상태를 하나씩 만드는 대신, 원하는 결과를 설명하는 데이터와 조건을 입력하면 도구가 여러 변형을 자동으로 생성한다. - 디자이너의 역할은 모든 결과를 직접 제작하는 것에서 벗어나, 생성된 결과 중 적절한 요소를 선택하고 다듬는 방향으로 이동할 수 있다. - 이는 디자인 도구가 정적인 편집기를 넘어 데이터 기반의 결과 생성 시스템으로 발전할 가능성을 의미한다. ## 커뮤니티에 대한 장기적 기여 - Sam은 디자이너가 더 빠르고 정확하게 작업할 수 있도록 돕는 도구와 프로세스를 계속 만들고 싶다고 밝혔다. - 그는 디자인 커뮤니티의 발전에 개발자도 중요한 방식으로 기여할 수 있다고 본다. - 특히 자동화, 접근성, 콘텐츠 관리처럼 여러 프로젝트에서 반복되는 문제를 플러그인으로 해결할 수 있다. - Sam의 플러그인은 2019년 8월 1일부터 Figma 커뮤니티에 공개될 예정이었다. 플러그인을 활용하면 반복 작업을 줄이고 디자인 품질과 접근성을 함께 높일 수 있다. 디자이너와 개발자는 Figma API를 활용해 팀의 업무 방식에 맞는 자동화 도구를 직접 만들고, 생성된 여러 결과를 사람이 검토·선택하는 협업 방식을 실험해볼 만하다.

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

회고를 위한 Figma

애자일·스크럼 팀의 회고를 Figma에서 진행하면 화이트보드와 포스트잇의 한계를 줄이고, 모든 구성원이 동시에 의견을 작성하고 확인할 수 있다. Figma의 실시간 협업, 댓글, 컴포넌트 기능은 원격 참여를 돕고 팀이 새로운 도구에 자연스럽게 익숙해지도록 한다. 글은 회고용 템플릿을 만들고 공유하는 방법부터 프레임·스티키 노트·브랜드 요소를 활용해 맞춤화하는 방법까지 단계별로 설명한다. ## Figma를 회고에 사용하는 이유 - 기존 화이트보드 회고에는 다음과 같은 문제가 있다. - 사람들 앞에 나가 직접 글을 쓰는 것이 부담스러울 수 있다. - 손글씨를 읽기 어렵다. - 여러 사람이 동시에 보드 앞에 서기 어렵다. - Figma는 멀티플레이어 방식으로 여러 명이 같은 파일에 동시에 접속할 수 있다. - 참가자별 커서가 표시되어 서로의 작업을 실시간으로 확인할 수 있다. - 댓글과 협업 기능을 활용하면 회의실에 직접 참석하지 못한 원격 구성원도 참여하기 쉽다. - 회고를 통해 팀에 Figma를 소개하고 도입 가능성을 시험해볼 수 있다. ## 파일 공유와 권한 설정 - 회고용 Figma 파일을 새로 만들거나 제공된 템플릿을 복제한다. - 우측 상단의 파란색 **Share** 버튼으로 파일을 공유한다. - 구성원을 이메일로 초대하거나 공유 링크를 생성할 수 있다. - 링크로 참여하는 사람도 의견을 작성할 수 있도록 편집 권한을 설정해야 한다. ## 회고 카테고리를 프레임으로 구성 - 화이트보드의 구역처럼 Figma 캔버스를 프레임으로 나눈다. - 기본 회고 템플릿은 세 가지 프레임으로 구성된다. - 계속할 일: 잘 작동했으므로 유지할 것 - 중단할 일: 비효율적이거나 개선이 필요한 것 - 시작할 일: 새롭게 시도할 것 - 프레임 내부의 제목과 배경 등에 **Constraints**를 설정한다. - 프레임 크기를 늘리거나 줄여도 내부 요소가 자동으로 조정되므로 참가자들이 작성할 공간을 쉽게 확장할 수 있다. ## 스티키 노트 컴포넌트로 의견 작성 - 참가자들이 각 카테고리에 빠르게 의견을 추가할 수 있도록 스티키 노트 컴포넌트를 제공한다. - 컴포넌트를 선택한 뒤 `Command + D`를 누르거나, `Option/Alt`를 누른 채 드래그해 복제한다. - 컴포넌트 인스턴스에는 오버라이드가 가능하다. - 텍스트 변경 - 색상 변경 - 효과 조정 - 원본 컴포넌트를 훼손하지 않고 각자의 메모를 개성 있게 꾸밀 수 있다. - 원격 참가자도 동일한 화면을 보며 다른 사람의 작업을 따라갈 수 있다. - 다른 사람의 아바타를 클릭해 해당 사용자의 화면을 관찰하는 기능도 활용할 수 있다. ## 팀에 맞게 템플릿 맞춤화 ### 회사 로고와 브랜드 색상 추가 - 회고 파일에 회사 로고 컴포넌트를 추가한다. - 회고 결과를 이미지나 PDF로 내보낼 때 조직의 정체성을 반영할 수 있다. - Figma의 **Styles** 패널에서 회사 브랜드 색상을 지정한다. ### 동의 표시용 컴포넌트 만들기 - 팀원들이 특정 의견에 동의하거나 추가 논의를 원할 때 `+1` 표시를 사용할 수 있다. - `+1` 아이콘이나 배지를 별도 컴포넌트로 만들어 재사용한다. - 각 인스턴스의 크기와 색상을 조정할 수 있도록 구성하면 다양한 의견 표시 방식에 대응할 수 있다. ### 회고별 커버 페이지 구성 - Figma 파일의 첫 페이지를 회고용 커버 페이지로 활용한다. - 회고마다 새 파일을 만든다면 프로젝트, 스프린트, 계절 등 다양한 테마를 적용할 수 있다. - 회고 결과물을 보관하거나 공유할 때 파일을 쉽게 식별하는 데 도움이 된다. 실제로 적용할 때는 회고 전에 편집 권한과 프레임 구조를 미리 설정하고, 참가자들이 사용할 스티키 노트와 동의 표시 컴포넌트를 준비하는 것이 좋다. 이후 회고가 끝나면 프레임을 내보내 결과와 실행 항목을 기록해두면 협업 기록으로도 활용할 수 있다.

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

Figma 채용 담당자가 전하는

제품 디자인 포트폴리오는 자신의 경력을 모두 보여주는 자료가 아니라, 지원하는 역할에 맞는 역량을 짧은 시간 안에 전달하는 도구다. 채용 담당자나 디자인 리더는 포트폴리오를 몇 분 또는 몇 초 만에 훑을 수 있으므로, 대상 독자의 관점에서 정보를 선별하고 구조화해야 한다. 랜딩 페이지에서는 프로젝트를 일관되게 배치하고 실제 작업까지 한 번의 클릭으로 도달하게 하며, 프로젝트는 목표 직무와 산업에 맞춰 선택하는 것이 핵심이다. ## 채용 담당자의 관점에서 목표 설정 - 포트폴리오를 주로 검토하는 사람은 디자인 매니저, 크리에이티브 디렉터, 디자인 총괄, 디자인 부문 VP 등이다. - 이들은 회의와 인터뷰 사이에 제한된 시간으로 포트폴리오를 검토한다. - 짧은 시간 안에 다음 정보를 파악하려 한다. - 어떤 유형의 디자인을 하는지 - 어떤 역량과 관심사를 가졌는지 - 지원 직무에 적합한 경험이 있는지 - 디자인 문제를 어떻게 해결하는지 - 전반적인 디자인 능력이 어떤지 - 따라서 모든 경력을 빠짐없이 보여주기보다, 지원하는 역할과 가장 관련 있는 정보를 우선적으로 노출해야 한다. ## 랜딩 페이지: 프로젝트를 쉽게 파악하게 만들기 - 프로젝트 썸네일은 일관된 시스템으로 구성해야 한다. - 회사 로고를 보여준다면 로고 크기를 동일하게 맞춘다. - 작업 화면을 보여준다면 배경색, 그림자, 이미지 스타일 등을 통일한다. - 각 프로젝트에는 회사명, 담당 역할, 작업 매체 등 핵심 정보를 일정한 형식으로 표시한다. - 동일한 크기와 정돈된 디자인의 썸네일은 채용 담당자가 포트폴리오 전체를 더 쉽게 훑도록 돕는다. - 썸네일마다 차이를 주고 싶다면 우연히 어긋난 결과가 아니라, 특정 프로젝트의 중요도 등을 반영한 의도적인 레이아웃이어야 한다. ## 작업까지의 클릭 수 줄이기 - 방문자가 ‘소개 페이지 → 작업 메뉴 → 프로젝트 선택’처럼 여러 단계를 거치지 않도록 한다. - 랜딩 페이지에서 프로젝트 개요를 바로 볼 수 있게 구성하고, 실제 작업까지 한 번의 클릭으로 접근하게 만드는 것이 좋다. - 채용 담당자가 정보를 찾아 헤매도록 만들지 말고, 첫 화면에서 작업의 범위와 성격을 즉시 이해할 수 있어야 한다. ## 지원 목표에 맞는 프로젝트 선택 - 프로젝트는 자신의 전체 경력보다 희망하는 직무와 커리어 방향을 기준으로 선별한다. - 모바일, 웹, VR 중 원하는 분야의 경험을 강조한다. - 이커머스에서 핀테크나 헬스케어로 전환하고 싶다면 관련성이 높은 작업을 앞세운다. - 모든 프로젝트를 한 포트폴리오에 담아 경력의 폭을 보여주려는 방식은 오히려 핵심 메시지를 흐릴 수 있다. - 오래된 유명 브랜드 작업은 브랜드 이름만으로 포함하지 않는다. - 현재의 자신을 잘 보여주지 못하는 작업은 이력서에서 경력의 폭을 설명하는 데 활용한다. - 다만 널리 알려진 대표 작업처럼 현재도 의미가 큰 결과물은 예외적으로 강조할 수 있다. - 희망 분야의 실무 경험이 부족하다면 사이드 프로젝트로 해당 분야의 결과물을 만든다. - 예를 들어 모바일 중심 경력으로 웹 디자인 직무를 원한다면 웹을 우선한 프로젝트를 추가한다. - 인쇄 디자인에서 UX/UI로, 비주얼 디자인에서 UX 리서치로 이동하는 경우에도 같은 전략을 적용할 수 있다. - 가장 뛰어난 작업이 지원 분야의 산업이나 매체와 다르더라도, 단순히 그 이유만으로 포트폴리오 전체를 구성해서는 안 된다. 지원 목표를 보여줄 수 있는 관련 작업을 새로 만들거나 기존 작업을 적절히 재구성하는 것이 바람직하다. ## 실용적인 적용 방법 지원 직무를 먼저 한 문장으로 정한 뒤, 랜딩 페이지에는 그 직무와 가장 관련 있는 프로젝트를 일관된 썸네일 형식으로 배치하는 것이 좋다. 각 프로젝트에는 자신의 역할과 작업 매체를 명확히 적고, 방문자가 한 번의 클릭으로 핵심 결과물에 도달하도록 구성하면 채용 담당자의 제한된 검토 시간을 효과적으로 활용할 수 있다.

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

GIF로 피그마 프로토타

Figma는 2019년부터 프로토타입에서 애니메이션 GIF를 재생할 수 있도록 지원했다. 파일에 GIF를 추가한 뒤 **Present**를 누르면 움직임이 재생되며, 모션 디자인·영상·미세한 인터랙션을 실제 제품처럼 표현할 수 있다. 편집 화면에서는 GIF가 정지 이미지로 보이지만, 원하는 프레임을 커버 이미지로 지정해 여러 GIF를 쉽게 구분할 수 있다. ## 프로토타입에서 GIF 사용하기 - Figma 파일에 GIF를 이미지처럼 추가한다. - **Present** 모드에서 GIF가 자동으로 애니메이션을 재생한다. - GIF는 편집 화면에서는 정지 이미지로 표시되고, 프로토타입에서만 움직인다. - GIF 제작 도구로 ScreenFlow, LICEcap, Principle, After Effects 등이 소개됐다. ## 커버 프레임 지정 - GIF 속성 패널의 GIF 모달을 열어 원하는 프레임으로 이동할 수 있다. - 선택한 프레임은 편집 화면에 표시되는 대표 이미지가 된다. - 첫 프레임이 비어 있거나, 비슷한 시작 화면을 가진 GIF가 여러 개일 때 유용하다. ## 모바일 프로토타입 개선 - 모바일 프로토타입에는 OS에 맞춘 관성 스크롤이 적용됐다. - 새로운 터치 커서가 추가되어 실제 모바일 기기와 비슷한 조작감을 제공한다. - GIF 기능과 함께 모바일 인터랙션의 사실성을 높이는 업데이트다. ## GIF를 활용할 수 있는 디자인 사례 - **Uber**: 애니메이션 스플래시 화면을 로딩 상태와 브랜드 인사말로 활용한다. - **Slack**: 로딩 중 제품 팁이나 재미있는 문구를 보여준다. - **Material Design**: 선형·원형 진행 표시기로 작업 상태를 단순하게 전달한다. - **Headspace**: 온보딩 과정에서 일러스트 애니메이션으로 기능과 사용 맥락을 설명한다. - **Hyperlapse**: 동영상 촬영 앱의 사용 시나리오를 온보딩 영상으로 소개한다. - **Mapbox**: 웹사이트 히어로 영역에서 위치 기술을 설명하는 반복 영상을 사용한다. - **Mailchimp**: 일러스트에 미세한 움직임을 더해 화면에 생동감과 질감을 부여한다. ## 실용적인 활용 방향 GIF는 복잡한 동영상 구현 없이도 로딩 상태, 온보딩, 진행 표시, 제품 소개, 일러스트 애니메이션을 프로토타입에 포함하는 간단한 방법이다. 다만 편집 화면에서는 정지 이미지로 보이므로 의미 있는 커버 프레임을 설정하고, 실제 사용 환경을 확인하려면 반드시 **Present** 모드에서 테스트하는 것이 좋다.

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