Techlist.io - 한국 테크 블로그 큐레이터

figma3분 읽기큐레이션 요약

스마트 애니메이트와 같은 주요

Figma는 사용자 요청이 많았던 고급 프로토타이핑 기능으로 **Smart Animate**와 **Drag**를 출시했다. Smart Animate는 유사한 객체를 자동으로 애니메이션화하고, Drag는 사용자의 손가락 드래그에 따라 전환을 제어한다. 기능 설계 과정에서는 사용자 피드백을 수집하고 다양한 사례에서 공통 패턴을 도출한 뒤, 기존 Figma 기능과 자연스럽게 통합하는 데 초점을 맞췄다. ## 사용자 불편에서 출발한 기능 설계 - Figma는 인앱 NPS 설문과 고객 지원 피드백을 통해 프로토타이핑 관련 요구를 지속적으로 수집했다. - 사용자들이 원한 것은 복잡한 애니메이션보다는 다음과 같은 일상적인 인터랙션이었다. - 드롭다운 메뉴 - 버튼 호버 효과 - 팝업의 부드러운 등장과 전환 - 탭 전환 - 화면 간 자동 애니메이션 - 드래그·슬라이드 기반 전환 - NPS 점수 자체보다, 사용자가 실제로 겪는 불편과 원하는 작업 방식을 파악할 수 있는 개방형 피드백 채널이라는 점에 의미를 뒀다. - 초기 피드백을 제공한 사용자 중 일부는 Smart Animate의 첫 베타 사용자로 참여했다. ## 다양한 사례에서 공통 패턴 도출 - 특정 사례 하나만 기준으로 기능을 설계하면 활용 범위가 제한될 수 있으므로, 고객 사례와 일상적인 인터랙티브 인터페이스를 폭넓게 조사했다. - 그 결과 첫 출시에서 지원할 핵심 패턴을 두 가지로 정리했다. ### 화면은 유지되고 객체만 변하는 경우 - 사용자는 같은 화면에 머물지만 특정 객체가 나타나거나 사라지거나 형태를 바꾼다. - 예시는 다음과 같다. - 동영상에 마우스를 올렸을 때 재생 바가 나타나는 경우 - 내비게이션 항목에 마우스를 올렸을 때 드롭다운이 펼쳐지는 경우 - 객체를 스와이프해 제거하면 뒤의 콘텐츠가 나타나는 경우 ### 일부 UI는 고정되고 주요 콘텐츠가 바뀌는 경우 - 탭 내비게이션처럼 일부 요소는 고정된 채 화면 대부분의 콘텐츠가 전환된다. - 콘텐츠를 좌우로 드래그하면 콘텐츠가 이동하고, 탭 표시기는 반대 방향으로 움직이는 등 더 복잡한 애니메이션을 구현할 수 있다. ## Figma에 맞는 방식으로 통합 - Figma는 유사한 문제를 해결한 다른 도구들을 참고하되, 새로운 기능이 기존 프로토타이핑 기능과 자연스럽게 연결되어 “Figma답게” 느껴지도록 설계했다. - 이를 위해 기존 기능도 다시 검토했다. 특히 객체와 레이어를 자동으로 연결해 애니메이션하는 기본 동작을 개선했다. - Smart Animate는 별도의 복잡한 설정 없이도 가능한 한 자동으로 작동하도록 설계됐다. - 레이어의 자동 이름 지정 및 변경 방식을 수정해, 다음 조건이 맞는 객체들이 서로 대응되도록 했다. - 레이어 계층 구조 - 레이어 이름 - 객체의 순서 - 이러한 기준으로 대응되는 레이어는 화면 전환 시 자동으로 애니메이션된다. - 겉보기에는 단순한 레이어 이름 개선처럼 보이지만, 기존 동작과 새 기능을 안정적으로 연결하기 위해 많은 설계와 구현 작업이 필요했다. ## Smart Animate와 Drag의 역할 - **Smart Animate** - 서로 대응되는 유사 객체를 자동으로 찾아 전환 애니메이션을 적용한다. - 기존 전환 기능을 개선하고, 드롭다운·탭·호버·화면 전환 등 다양한 인터랙션을 표현할 수 있게 한다. - **Drag** - 사용자의 손가락이나 포인터 드래그를 전환의 입력으로 사용한다. - 단순히 클릭하면 전환되는 프로토타입보다 실제 앱의 제스처에 가까운 상호작용을 구현할 수 있다. Figma의 접근 방식은 기능을 많이 추가하는 데 그치지 않고, 실제 사용자 불편을 수집한 뒤 공통 패턴으로 추상화하고 기존 작업 흐름에 자연스럽게 녹여내는 것이었다. 유사한 전환을 만들 때는 레이어의 이름·계층·순서를 일관되게 관리하고, Smart Animate와 Drag를 활용하면 별도 도구 없이도 개발자에게 전달할 수 있는 인터랙션 프로토타입을 만들 수 있다.

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

플러그인 보안 업데이트

Figma는 플러그인 보안을 위해 사용하던 Realms shim에서 샌드박스 탈출 취약점이 발견되자 즉시 플러그인 게시와 업데이트를 중단하고 패치를 적용했다. 공개된 플러그인들을 감사한 결과 실제 악용 흔적은 발견되지 않았으며, 재발 방지를 위해 JavaScript 실행 환경을 Realms shim에서 WebAssembly로 컴파일한 QuickJS VM으로 교체했다. ## 플러그인 보안의 기본 원칙 Figma는 플러그인이 다음 작업을 수행할 수 있도록 설계했다. - 사용자가 명시적으로 실행한 경우에만 동작 - 플러그인 전용 대화상자 안에서 UI 표시 - 현재 열어 실행한 Figma 문서의 데이터 읽기 - 해당 문서의 데이터 수정 - 인터넷상의 서버와 통신 반대로 플러그인은 다음 작업을 할 수 없어야 한다. - 사용자 동의 없이 스스로 실행 - 파일을 소유한 프로젝트나 팀 정보 접근 - 실행 중이 아닐 때 데이터 접근 - 실행된 파일 이외의 다른 파일 데이터 접근 - 플러그인 UI 대화상자 외부의 Figma UI 변경 또한 Organization 요금제에서는 관리자가 허용된 플러그인 목록을 지정해 조직 내에서 신뢰할 수 없는 플러그인의 실행을 차단할 수 있다. ## Realms shim 취약점 발견 - Figma는 웹에서 서드파티 JavaScript를 안전하게 실행하기 위해 Realms shim을 사용했다. - 2019년 9월경 Realms shim에서 여러 독립적인 취약점이 발견됐다. - 취약점이 악용되면 샌드박스 내부 코드가 외부로 탈출해 Figma가 설정한 플러그인 보안 제한을 우회할 수 있었다. - 첫 번째 취약점은 공개 GitHub 이슈로 보고됐고, 나머지는 제한된 보안 권고를 통해 비공개로 공유됐다. - Figma는 공개 플러그인을 감사했지만 실제 플러그인이 취약점을 악용한 증거는 찾지 못했다. ## 취약점에 대한 대응 Figma는 위험 확산을 막기 위해 플러그인 배포 체계를 일시적으로 제한했다. - 신규 플러그인의 커뮤니티 허브 게시 중단 - 기존 플러그인의 업데이트 게시도 완전히 중단 - 공개 취약점에 대해서는 Realms shim 패치를 당일 적용 - 비공개 취약점은 관련 업체들과 공개 일정을 조율한 뒤 다음 주에 해결 - 모든 수정 사항이 배포된 후 취약점 세부 내용을 공개 - 게시된 플러그인 코드를 감사해 실제 공격 여부 확인 Figma의 수동 리뷰는 주로 사용자 경험과 품질을 검토하는 절차이며, 보안 경계를 사람이 직접 검증하는 방식은 아니다. 보안은 샌드박스가 강제하도록 설계했기 때문에, 리뷰만으로 악성 코드나 취약점을 완전히 차단할 수 있다고 보지 않았다. ## 실시간 업데이트가 만드는 위험 - Figma 플러그인 코드는 라이브 방식으로 배포된다. - 개발자가 기존 플러그인을 업데이트하면 변경 사항이 열려 있는 클라이언트에도 즉시 전파된다. - 따라서 취약점을 알고 있는 플러그인 개발자가 업데이트를 통해 악성 코드를 배포할 가능성을 차단하기 위해 기존 플러그인 업데이트까지 중단했다. - 이는 플러그인 생태계의 신속한 배포 기능이 보안 사고 시 위험 요소가 될 수 있음을 보여준다. ## QuickJS 기반 실행 환경으로 전환 Figma는 사고 대응 과정에서 Realms shim을 완전히 제거하고 QuickJS를 도입했다. - QuickJS는 C로 작성된 JavaScript 가상 머신이다. - Figma는 이를 WebAssembly로 크로스 컴파일해 플러그인 실행에 사용했다. - Realms shim의 객체 경계 혼동에서 비롯된 이번 취약점 유형은 새 구현에서는 발생하지 않는다. - 기존 구조가 교체 가능한 아키텍처로 설계되어 있었기 때문에 백업 계획이었던 QuickJS로 빠르게 전환할 수 있었다. ## 실용적인 결론 서드파티 코드를 실행할 때는 사람의 코드 리뷰보다 강제 가능한 샌드박스 경계가 핵심이다. 또한 배포 중단, 신속한 패치, 비공개 정보 공개 일정 조율, 실행 환경 교체 계획을 사전에 마련해 두면 취약점 발견 시 피해 확산을 효과적으로 줄일 수 있다.

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

DDSketch로 정확한 백분위수 계산하기 (새 탭에서 열림)

Datadog은 대규모 분산 환경에서 발생하는 모니터링 데이터를 효율적으로 처리하기 위해 새로운 확률적 자료구조인 **DDSketch**를 개발했습니다. 기존의 백분위수 계산 알고리즘은 분산된 데이터를 병합할 때 정확도가 떨어지거나 시각화 시 실제와 다른 노이즈를 생성하는 한계가 있었습니다. DDSketch는 빠른 연산 속도와 완전한 병합 가능성을 제공하며, 특히 '상대 오차 보장'을 통해 고성능 모니터링 시스템에서 정밀한 지표 산출을 가능하게 합니다. ### 분산 시스템에서의 데이터 집계와 백분위수 계산의 난제 * 웹 애플리케이션의 지연 시간(Latency) 모니터링 시, 평균값은 이상 수치를 가리기 때문에 P99와 같은 백분위수(Percentile)를 확인하는 것이 사용자 경험 파악에 필수적입니다. * 정확한 백분위수를 계산하려면 모든 데이터를 저장하고 정렬해야 하지만, 초당 수백만 개의 데이터가 발생하는 분산 환경에서는 메모리와 네트워크 비용 문제로 인해 사실상 불가능합니다. * 최대값이나 합계와 달리 백분위수는 각 노드에서 계산된 중간 결과값을 단순히 합치는 것만으로는 전체 데이터의 정확한 백분위수를 구할 수 없다는 기술적 어려움이 존재합니다. ### 스케치(Sketch) 알고리즘의 역할과 병합 가능성 * 스케치는 방대한 데이터를 요약하여 압축된 형태로 저장하는 '손실 압축' 알고리즘으로, 메모리 사용량을 대폭 줄이는 대신 약간의 정확도를 희생합니다. * 모니터링 시스템에서는 여러 소스에서 생성된 요약된 데이터(스케치)를 하나로 합쳐도 정확도가 유지되는 '병합 가능성(Mergeability)'이 매우 중요한 요소입니다. * 잘 설계된 분위수 스케치(Quantile Sketch)를 사용하면 전체 데이터를 전송하지 않고도 분산된 노드들의 지표를 효율적으로 통합할 수 있습니다. ### 기존 GK 스케치의 한계와 시각화 오류 * 기존에 사용되던 GK(Greenwald-Khanna) 알고리즘은 데이터 요약 과정에서 발생하는 오차로 인해 그래프상에 실제 데이터에는 없는 가공의 스파이크(Spike)나 노이즈를 생성하는 문제가 있었습니다. * 이러한 현상은 특히 P99와 같은 높은 백분위수에서 두드러지게 나타나며, 이는 시스템의 실제 상태를 오판하게 만드는 원인이 됩니다. * 기존 알고리즘의 대부분은 '순위 오차(Rank-error)'를 제어하는 데 집중하지만, 이는 값의 범위가 넓은 모니터링 데이터에서는 충분한 정확도를 보장하지 못합니다. ### DDSketch의 혁신: 상대 오차 보장 * DDSketch는 '상대 오차(Relative-error)'를 보장하도록 설계되어, 측정값이 크든 작든 설정된 오차 범위 내에서 일관된 정확도를 제공합니다. * 매우 빠른 입력 속도와 낮은 메모리 점유율을 기록하여 Datadog 에이전트와 같은 리소스 제한적인 환경에서도 원활하게 동작합니다. * 이 알고리즘은 학술적 검증(PVLDB 발표)을 마쳤으며, 실제 Datadog 서비스에서 대규모 분포 메트릭을 계산하는 핵심 기술로 활용되고 있습니다. **결론** 대규모 분산 시스템을 운영하는 엔지니어라면 데이터 집계 시 단순히 평균에 의존하기보다 DDSketch와 같은 상대 오차 보장형 스케치 알고리즘을 도입하는 것이 좋습니다. 이를 통해 리소스 비용을 최소화하면서도 사용자 경험을 결정짓는 핵심 지표인 상위 백분위수를 왜곡 없이 정확하게 모니터링할 수 있습니다.

datadog3분 읽기큐레이션 요약

DDSketch로 정확한 백

Datadog의 글은 대규모 분산 시스템에서 정확한 백분위수(percentile)를 효율적으로 계산하기 위해 DDSketch를 사용하는 방법을 설명합니다. 평균이나 단순한 히스토그램은 지연 시간처럼 분포가 치우친 데이터의 꼬리 구간을 제대로 표현하지 못하지만, DDSketch는 상대 오차를 일정하게 제한하면서 적은 메모리로 값을 집계합니다. 또한 분산 환경에서 여러 스케치를 병합할 수 있어 p95, p99 같은 지표를 안정적으로 계산할 수 있습니다. ## 백분위수 계산이 어려운 이유 - 평균은 데이터 분포의 꼬리 부분을 숨길 수 있습니다. - 예를 들어 대부분의 요청이 빠르더라도 일부 요청이 매우 느리면 평균만으로는 사용자 경험을 설명하기 어렵습니다. - p95나 p99는 전체 값을 정렬해야 정확히 계산할 수 있습니다. - 대규모 트래픽에서는 모든 원본 값을 저장하고 정렬하는 비용이 매우 큽니다. - 단순한 고정 폭 히스토그램은 구간 경계에 따라 정확도가 달라집니다. - 작은 값에서는 정밀하지만 큰 값에서는 오차가 커지거나, 반대로 큰 값에 맞추면 작은 값의 차이를 구분하지 못합니다. - 여러 서버에서 수집한 데이터를 중앙에서 합치려면 집계 구조가 병합 가능해야 합니다. ## 절대 오차보다 상대 오차가 적합한 이유 - DDSketch는 “실제 값과 추정값의 차이가 일정한 절대값 이하”가 아니라 “실제 값 대비 일정 비율 이하”가 되도록 설계됩니다. - 예를 들어 상대 오차를 1%로 설정하면: - 실제 값이 100인 경우 추정값은 대략 99~101 범위입니다. - 실제 값이 10,000인 경우에도 약 9,900~10,100 범위입니다. - 지연 시간이나 처리량처럼 값의 규모가 크게 달라지는 데이터에서는 상대 오차 보장이 더 일관된 품질을 제공합니다. ## 로그 스케일 기반의 DDSketch - DDSketch는 값을 로그 스케일의 버킷에 매핑합니다. - 인접한 버킷의 대표값이 일정한 비율을 갖도록 만들어, 값이 커져도 상대 오차가 일정하게 유지됩니다. - 양수 값과 음수 값은 별도의 저장소에 기록하고, 0에 가까운 값은 별도의 zero bucket으로 처리합니다. - 각 원본 값을 저장하는 대신 다음 정보만 유지합니다. - 값이 속한 버킷의 인덱스 - 해당 버킷에 포함된 값의 개수 - 조회 시에는 버킷의 대표값과 누적 개수를 이용해 원하는 순위의 값을 추정합니다. ## 메모리 사용량과 정확도의 균형 - 상대 오차 설정값을 작게 할수록 더 많은 버킷이 필요하고 메모리 사용량이 증가합니다. - 반대로 허용 오차를 키우면 더 적은 메모리로 처리할 수 있지만 백분위수의 정밀도가 낮아집니다. - DDSketch는 원본 데이터 전체가 아니라 분포를 근사하므로, 높은 트래픽에서도 메모리 사용량을 예측하기 쉽습니다. - 매우 큰 값 범위가 입력되더라도 로그 매핑을 사용하기 때문에 선형 히스토그램보다 효율적으로 다룰 수 있습니다. ## 분산 환경에서의 병합 - 각 호스트나 애플리케이션 인스턴스가 독립적으로 DDSketch를 생성할 수 있습니다. - 중앙 집계 단계에서는 각 스케치의 동일한 버킷 개수를 더해 하나의 스케치로 병합합니다. - 이 방식은 원본 요청 데이터를 네트워크로 전송할 필요가 없어 수집 및 전송 비용을 줄입니다. - 병합 후에도 설정한 상대 오차 보장이 유지되므로, 분산 시스템 전체의 p95·p99 지연 시간을 계산하는 데 적합합니다. ## 저장소 구조와 큰 데이터 범위 처리 - DDSketch의 내부 저장소는 버킷 인덱스와 카운트를 관리하는 구조로 구현됩니다. - 일반적인 범위에서는 밀집 배열을 사용해 빠르게 접근할 수 있습니다. - 값의 범위가 지나치게 커져 메모리 사용량이 증가할 경우에는 저장소 크기를 제한하고 오래된 범위나 덜 중요한 범위를 압축하는 collapsing store를 사용할 수 있습니다. - 이로 인해 정확도와 메모리 상한 사이의 트레이드오프를 제어할 수 있습니다. 실무에서는 지연 시간처럼 분포의 꼬리가 중요한 지표에 DDSketch 같은 상대 오차 기반 스케치를 적용하는 것이 유용합니다. 다만 허용 오차와 메모리 제한을 서비스 특성에 맞게 설정하고, p99 등 핵심 백분위수의 정확도를 실제 원본 데이터와 비교해 검증하는 것이 좋습니다.

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

다음 디자인 프로젝트를 위한

매일 새로운 패턴을 만드는 도전은 창의력을 훈련하고, 클라이언트나 브랜드 제약에서 벗어나 새로운 시각적 가능성을 탐색하게 한다. Namika Hamasaki는 일상에서 영감을 수집한 뒤 색상 팔레트와 그리드를 설정하고, 기본 도형을 조합·변형해 패턴을 만든다. 완성한 패턴은 Figma 컴포넌트로 변환하고 클립 콘텐츠를 끈 상태에서 반복 배치해 매끄러운 패턴으로 완성한다. ## 일상에서 영감 찾기 - 영감은 음식, 건축물, 가구, 자연, 출퇴근길 등 주변 어디에서나 얻을 수 있다. - 눈에 띄는 형태, 색상, 구도 같은 세부 요소를 관찰하고 이를 디자인 요소로 번역한다. - 마음에 드는 장면이나 사물을 사진으로 기록해 나중에 참고한다. - 사진을 모아두면 빈 화면 앞에서 시작해야 하는 부담을 줄이고, 디자인의 출발점으로 활용할 수 있다. - 매일 하나씩 패턴을 만드는 습관은 반복적인 연습이면서도 매번 다른 결과를 실험하는 창작 활동이 된다. ## 색상 팔레트 만들기 - 업무에서는 브랜드 색상에 맞춰야 하는 경우가 많지만, 개인적인 패턴 작업에서는 평소 사용하지 않던 색 조합을 자유롭게 시도한다. - 영감을 준 사진에서 색상을 추출해 팔레트의 출발점으로 삼는다. - Figma의 **Image Palette 플러그인**을 사용하면 이미지에서 색상을 자동으로 추출하고 팔레트를 생성할 수 있다. - 제한된 브랜드 팔레트에서 벗어나는 과정이 새로운 분위기와 시각적 결과를 발견하는 데 도움이 된다. ## 그리드 설정하기 - 색상 팔레트를 정한 뒤 패턴을 배치할 그리드를 만든다. - 반복되는 패턴은 요소의 위치와 간격이 중요하므로 그리드가 구조를 잡아주는 역할을 한다. - Figma의 **Layout grid**를 활용하면 원하는 기준선을 빠르게 설정할 수 있다. - 그리드는 패턴 요소를 정렬하고 반복 단위를 일관되게 유지하는 데 유용하다. ## 기본 도형으로 형태 실험하기 - 복잡해 보이는 패턴도 처음에는 원, 사각형, 삼각형 같은 단순한 도형에서 시작한다. - 도형을 그리드 위에 배치한 뒤 회전, 이동, 조합을 반복하며 다양한 결과를 탐색한다. - 예를 들어 원을 45도 회전하거나, 반원을 각각 다른 각도로 회전해 시각적 변화를 확인한다. - 같은 도형이라도 위치와 회전 각도에 따라 전혀 다른 인상을 만들 수 있다. - 도형의 구조뿐 아니라 색상 조합도 계속 바꿔보며 예상하지 못한 결과를 발견한다. - 손으로 그리던 방식에서 기본 기하 도형을 활용한 디지털 작업으로 전환하면서 구성과 반복을 더욱 쉽게 실험할 수 있었다. ## 패턴을 매끄럽게 반복하기 - 만족스러운 패턴을 찾으면 이를 Figma 컴포넌트로 변환한다. - 이때 **Clip content 옵션을 꺼야** 컴포넌트 경계를 넘어 패턴 요소를 확인하고 반복 배치하기 쉽다. - 컴포넌트를 복제한 뒤 프레임 전체를 채우도록 배열한다. - 마스터 컴포넌트 내부의 요소를 이동하면 여러 반복 구조와 레이아웃을 빠르게 비교할 수 있다. - 하나의 패턴 단위를 반복 배치하면서 가장 자연스럽고 끊김 없는 연결 방식을 찾는다. ## 실용적인 적용 방법 - 매일 짧은 시간이라도 하나의 패턴을 만들어 창작 루틴을 구축한다. - 주변에서 발견한 형태와 색상을 사진으로 모아 개인적인 영감 라이브러리를 만든다. - 사진에서 색상을 추출하고, 그리드와 기본 도형을 사용해 부담 없이 실험을 시작한다. - 완성도보다 다양한 회전·이동·색상 조합을 시도하는 과정에 집중하면 창의적인 결과를 얻기 쉽다.

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

5명의 플러그인 개발자가

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와 오픈소스 사례를 참고해 사내 전용 플러그인부터 작게 만들어보는 것이 현실적인 접근이다.

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

OpenType을 향한

Figma는 로컬 폰트, Google Fonts, 조직 내 공유 폰트에 포함된 OpenType 기능을 지원하기 시작했다. 이를 통해 단순한 굵기·기울기 조절을 넘어 합자, 숫자 스타일, 대체 글리프, 장식 문자 등을 활용해 글자의 인상과 가독성을 세밀하게 조정할 수 있다. 글쓴이는 OpenType이 폰트마다 숨겨진 가능성을 제공하며, 기능을 무작정 적용하기보다 용도와 맥락에 맞게 사용해야 한다고 설명한다. ## 폰트에 숨겨진 또 다른 세계 - Warnock Pro를 계기로 글쓴이는 하나의 서체가 기본적인 글자 모양 외에도 다양한 변형을 포함한다는 사실을 발견했다. - OpenType 기능으로 다음과 같은 요소를 바꿀 수 있다. - **Old-style figures**: 본문 속 소문자와 어울리도록 높낮이와 형태를 조정한 숫자 - **Tabular figures**: 표나 데이터에서 숫자 폭을 일정하게 맞추는 숫자 - **Small caps**: 소문자와 대문자 사이의 형태로, 도입부나 강조에 사용 - **Swash와 대체 글리프**: 글자 끝의 장식적인 획이나 다른 문자 형태 - **Stylistic alternates**: 특정 글자의 대체 디자인 - **Ornaments**: 장식 기호와 문양 - **Ordinals와 fractions**: 서수와 분수에 적합한 글리프 - **Numero sign**: `№`와 같은 특수 기호 - 이러한 기능은 디자인 도구 안에 존재했지만, 당시에는 복잡한 메뉴와 낯선 기술 용어 뒤에 숨겨져 있어 발견하기 어려웠다. - 글쓴이는 기능의 목적을 완전히 이해하기 전부터 스와시, 장식 문자, 여러 숫자 스타일을 논문에 적용하며 OpenType의 매력에 빠졌다. ## OpenType 기능을 이해해 가는 과정 - 시간이 지나면서 폰트 제작사들은 PDF 설명서 대신 온라인 타입 견본 페이지를 통해 OpenType 기능을 소개하기 시작했다. - 폰트마다 제공하는 기능의 규모는 크게 달랐다. - 한 글자만 바꾸는 단일 기능을 제공하는 폰트 - 문자 전체를 변형해 서체가 전혀 다른 인상을 주는 수십 개의 기능을 제공하는 폰트 - 글쓴이는 점차 기능을 단순히 “켜 보는” 수준에서 벗어나, 각 기능이 어떤 문제를 해결하는지 이해하게 되었다. - 예를 들어 **discretionary ligatures**는 항상 적용하는 합자가 아니라, 필요할 때 선택적으로 사용하는 합자다. - **Tabular numbers**는 표처럼 숫자를 정렬해야 하는 상황에 적합하며, 본문용 숫자와 목적이 다르다. ## 맥락에 따른 숫자와 기호 선택 - Medium에서 글쓴이는 기사 본문과 인용문에 서로 다른 숫자 스타일을 적용하는 방식을 고민했다. - 본문에서는 숫자가 문장 속에 자연스럽게 섞이도록 눈에 띄지 않는 형태를 선택했다. - 반대로 큰 인용문이나 강조 영역에서는 제목처럼 강한 인상을 주는 숫자와 장식적인 앰퍼샌드를 사용했다. - 같은 폰트라도 OpenType 기능을 활용하면 콘텐츠의 역할에 맞춰 차분하거나 화려한 분위기를 만들 수 있다. - 따라서 특정 기능이 “더 좋은” 것이 아니라, 본문·표·제목·인용문 등 사용 위치에 따라 적절한 기능이 달라진다. ## 대문자 전용 조정과 디자인 완성도 - 많은 폰트에는 대문자로만 문장을 쓸 때를 위한 별도의 기호와 문장부호 세트가 포함되어 있다. - 대문자 환경에서는 일반적인 기호의 크기와 정렬이 어색해질 수 있으므로, 이를 보정한 글리프를 사용하면 전체적인 인상이 더 균형 잡힌다. - 이런 세부 조정은 글자 자체보다 기호와 문장부호의 간격, 높이, 정렬을 개선해 대문자 제목이나 포스터의 완성도를 높인다. ## Figma에서의 OpenType 지원 - Figma는 사용자가 사용하는 다양한 폰트의 OpenType 기능을 지원한다. - 로컬 폰트 - Google Fonts - 조직 내에서 공유된 폰트 - 사용자는 Figma의 인터페이스를 통해 다음 기능을 쉽게 탐색하고 적용할 수 있다. - 추가 합자 - 숫자 스타일 변경 - 대체 글자 형태 - 폰트에 포함된 각종 조정 기능 - 기존에는 전문적인 메뉴나 폰트 설명서를 찾아야 했던 기능을 디자인 작업 중에 직접 확인할 수 있게 된 것이 핵심 변화다. ## 실용적인 활용 방향 OpenType 기능은 장식 요소를 많이 넣는 도구라기보다, 글의 목적과 배치에 맞게 타이포그래피를 조정하는 수단이다. 본문에는 가독성이 좋은 숫자와 합자를 사용하고, 표에는 탭 숫자를 적용하며, 제목이나 포스터에는 대체 글리프와 장식 기능을 제한적으로 활용하는 것이 좋다. Figma에서는 폰트별 기능을 직접 비교해 보되, 효과가 눈에 띈다는 이유만으로 무작정 적용하지 않는 것이 중요하다.

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

Figma에서 디자인 크

디자인 크리틱은 팀의 집단적 역량을 활용해 작업의 품질을 높이고, 디자이너가 문제를 해결하도록 돕는 협업 의식이다. 하지만 운영이 미숙하면 피드백이 피상적이거나 실행 불가능해지고, 참여자는 위축되거나 혼란을 느낄 수 있다. Figma는 크리틱을 “위협적이지 않고 동기를 부여하는 자리”로 만들기 위해 목적을 명확히 하고, 문제에 맞는 다양한 형식과 지속적인 개선 방식을 도입했다. ## 크리틱 자체를 크리틱하기 Figma 팀은 약 1년간 크리틱을 운영한 뒤, 무엇이 잘되고 무엇이 문제인지 팀 전체가 검토했다. - 발견한 주요 문제: - 참석자가 많아 공간이 지나치게 붐빔 - 피드백이 피상적임 - 짧은 시간에 다루기에는 문제가 지나치게 복잡함 - 피드백이 구체적이거나 실행 가능하지 않음 - “동의한다”는 식의 집단사고와 단순한 찬성이 많음 - 솔직한 의견보다 지나치게 조심스러운 의견이 많음 - 디자이너의 문제를 실제로 해결하거나 다음 단계로 나아가게 하지 못함 - 팀은 Figma 파일에 의견을 모으고 주제별로 정리했다. - 문제를 분석하는 회의 자체가 가볍고 생산적이며 창의적으로 진행되었고, Figma는 이 분위기를 실제 크리틱에서도 재현하려 했다. - 한 번의 회의로 모든 문제를 해결하려 하지 않고, Slack의 `#design-crit-crit` 채널에서 운영 방식을 계속 개선했다. - 팀 규모와 업무 유형이 변하면 크리틱 방식도 함께 진화해야 한다고 보았다. ## 크리틱의 목표 정렬 효과적인 크리틱을 만들려면 먼저 회의가 무엇을 달성해야 하는지 합의해야 한다. - **문제 해결과 아이디어 생성** - 혼자 오래 고민해 막힌 디자이너가 팀의 관점을 활용해 앞으로 나아가도록 돕는다. - 초기 단계에서 팀이 이미 갖고 있는 아이디어와 가능성을 폭넓게 수집한다. - **디자인 품질 향상** - 시각 디자인뿐 아니라 인터랙션 세부 사항, 제품의 전반적인 방향까지 검토한다. - **일관성 강화** - 기존 디자인 패턴을 재사용할 수 있는지 확인한다. - 기존 패턴으로 해결되지 않는 경우 새로운 패턴이 필요한지 논의한다. - **맥락 공유** - 디자인팀이 알고 있는 회사와 제품의 상황을 서로 공유해, 개별 작업이 전체 방향과 연결되도록 한다. ## 문제에 맞춰 크리틱 형식을 선택하기 Figma는 모든 작업에 같은 회의 형식을 적용하지 않고, 목적과 상황에 따라 여러 방식을 사용한다. - **표준 크리틱** - 작업을 발표하고 참석자들이 의견을 주고받는 일반적인 형식이다. - 정기적인 검토와 폭넓은 피드백에 적합하다. - **잼과 워크숍** - 특정 문제를 함께 탐색하고 아이디어를 빠르게 생성하는 협업형 방식이다. - 방향이 정해지지 않았거나 여러 대안을 만들어야 할 때 유용하다. - **페어 디자인** - 두 명의 디자이너가 함께 작업하며 즉각적으로 판단과 피드백을 주고받는다. - 짧은 시간 안에 구체적인 문제를 해결하거나 작업을 진전시키는 데 적합하다. - **사일런트 크리틱** - 먼저 말없이 작업을 검토하고 각자 의견을 정리한 뒤 공유한다. - 목소리가 큰 사람의 의견에 쏠리는 현상과 집단사고를 줄이는 데 도움이 된다. - **종이·출력물 크리틱** - 화면 대신 출력물을 실제 공간에 배치해 검토한다. - 작업을 새로운 관점에서 보고, 세부 화면에 매몰되지 않은 피드백을 얻을 수 있다. - **FYI 크리틱** - 즉각적인 논의나 해결책보다 작업의 진행 상황과 맥락을 공유하는 데 초점을 둔다. - 참석자에게 정보를 전달하되, 발표자에게 불필요한 압박을 주지 않는 방식이다. ## 안전하고 생산적인 분위기 만들기 크리틱은 개인을 평가하는 자리가 아니라 작업을 발전시키는 자리여야 한다. - 참여자가 영감을 받고 도전받으며, 다음 행동을 결정할 수 있어야 한다. - 솔직한 피드백이 가능하려면 심리적으로 안전한 환경이 필요하다. - 단순한 “+1”이나 막연한 칭찬보다 문제의 원인과 개선 방향을 구체적으로 말해야 한다. - 피드백은 발표자의 현재 단계와 요청에 맞아야 하며, 짧은 시간에 지나치게 많은 문제를 다루지 않아야 한다. - 크리틱의 품질은 디자인팀 문화와 정체성에 영향을 주며, 인재를 채용하고 유지하는 데에도 중요한 요소다. ## 지속적으로 운영 방식을 개선하기 Figma의 크리틱은 고정된 규칙이 아니라 팀이 함께 발전시키는 프로세스다. - 정기적으로 크리틱의 효과와 문제점을 되돌아본다. - 회의에서 느낀 불편이나 개선 아이디어를 별도 채널에 계속 축적한다. - 팀이 성장하거나 다루는 문제의 유형이 달라지면 참석자 수, 시간, 형식, 피드백 방식도 조정한다. - 좋은 크리틱에서 실제로 나타나는 에너지와 협업 방식을 관찰하고, 이를 의도적으로 재현한다. 실무에서는 먼저 크리틱의 목적을 정한 뒤, 작업 단계와 문제의 성격에 맞는 형식을 선택하는 것이 좋다. 또한 회의가 끝난 뒤 “어떤 피드백이 실제로 작업을 전진시켰는가”를 점검하면, 크리틱을 부담스러운 평가 시간이 아니라 팀의 역량을 높이는 협업 도구로 발전시킬 수 있다.

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

마이크로소프트가 워

Microsoft는 Figma 플러그인을 활용해 Fluent 디자인 시스템의 도입을 여러 제품·조직·팀으로 확장하고, 디자인 과정의 일관성과 효율성을 높였다. 특히 승인된 콘텐츠를 불러오고, 제품별 라이브러리를 전환하며, 반복 작업을 자동화하는 사내 도구를 개발했다. 이 글은 조직의 고유한 업무 방식에 맞춘 비공개 플러그인이 디자이너의 창의적 작업에 더 많은 시간을 돌려줄 수 있다고 설명한다. ## Fluent 디자인 시스템과 플러그인의 역할 - Microsoft는 모든 제품에서 사용성, 일관성, 접근성을 높이기 위해 Fluent 디자인 시스템을 운영했다. - 여러 제품군과 조직, 팀에 디자인 시스템을 적용하려면 단순한 가이드라인만으로는 부족하고 효율적인 도구가 필요했다. - Figma 플러그인은 반복 작업을 줄이고, 조직별 데이터와 규칙을 디자인 프로세스에 직접 통합하는 수단으로 활용됐다. - 공개 플러그인뿐 아니라 특정 팀의 승인 절차와 콘텐츠 정책에 맞춘 사내 전용 플러그인도 개발했다. ## 승인된 디자인 콘텐츠를 불러오는 Content Reel - 일반적인 더미 텍스트나 Lorem Ipsum은 실제 디자인 의도와 콘텐츠 특성을 충분히 반영하지 못한다. - Microsoft는 사내용 Content Reel을 만들어 승인된 다음 요소를 Figma 디자인에 바로 삽입했다. - 승인된 텍스트 문자열 - 아바타 - 아이콘 - 디자이너가 콘텐츠를 직접 찾거나 사용 승인을 다시 받을 필요가 없어 작업 속도가 향상됐다. - 조직마다 자체 콘텐츠 저장소와 승인 기준을 연결한 Content Reel을 만들 수 있다는 점을 보여준다. ## 제품별 라이브러리를 빠르게 전환하는 Themer - Microsoft는 제품마다 고유한 라이브러리와 스타일을 사용하며, Figma 안에 수백 개의 라이브러리가 존재했다. - 제품 스타일에 맞게 디자인을 수동으로 변경하는 작업은 규모가 커질수록 비효율적이었다. - Jackie Chui가 개발한 Themer는 Work, Outlook 등 여러 제품 테마 사이를 빠르게 전환하도록 지원했다. - 공개 버전 Themer는 라이브러리에서 게시된 스타일을 쉽게 교체하는 기능을 제공한다. - 이를 통해 하나의 디자인을 여러 제품의 시각적 체계에 맞게 적용하는 비용을 줄였다. ## 반복 작업을 줄이는 워크플로 도구 Microsoft 디자이너들은 창의적인 문제 해결에 집중하기 위해 반복적인 작업을 자동화하는 여러 플러그인을 제작했다. - **Find and Replace** - 페이지 내 텍스트를 검색하고 일괄 교체한다. - 일반적인 텍스트 편집기의 찾기·바꾸기와 유사하다. - **Paste to Fill** - 복사한 이미지를 선택한 레이어의 Fill로 붙여 넣는다. - 이미지 URL을 입력해 레이어의 이미지 Fill로 불러올 수도 있다. - **Button Resizer** - 버튼의 라벨 너비에 맞춰 버튼 크기를 쉽게 조정한다. - Jackie는 Figma API가 공개된 이후부터 플랫폼을 활용해 팀의 디자인 작업을 개선하는 도구를 꾸준히 개발했다. - Figma가 Microsoft의 주요 디자인 도구가 된 만큼, 그 위에 자체 업무 도구를 구축하는 것이 자연스러운 선택이었다. ## 접근성을 프로세스에 포함하려는 시도 - Microsoft 디자이너 Tiffany Chen은 Modern Input and Accessibility 팀에서 제품 경험의 포용성을 높이는 업무를 담당했다. - 접근성이 제품 개발 마지막 단계에 덧붙이는 작업으로 취급되는 문제를 지적했다. - 그녀는 디자이너들이 초기 단계부터 접근성을 고려하도록 돕는 플러그인을 개발했다. - 제공된 글은 해당 플러그인의 구체적인 기능 설명이 중간에 끊겨 있어 상세 내용까지는 확인할 수 없다. 조직에 맞는 승인 콘텐츠, 디자인 토큰과 라이브러리, 반복 작업을 플러그인으로 연결하면 디자인 시스템의 실제 활용도를 크게 높일 수 있다. 특히 팀 내 반복 작업을 먼저 찾아 작은 자동화 도구로 해결한 뒤, 효과가 검증된 도구를 조직 전체로 확장하는 접근이 실용적이다.

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

Figma 데이터의 안전한 보호 및

Figma는 고객의 디자인 데이터와 지식재산을 보호하기 위해 보안을 제품 개발과 인프라 운영 전반의 핵심 원칙으로 삼고 있다. SOC 2 인증, 유럽 데이터 보호 체계, 플러그인 권한 제한, SAML 기반 SSO 등을 통해 규정 준수와 실제 서비스 보안을 함께 강화했다. 이후 업데이트에서는 SOC 2 Type 2와 SOC 3 보고서까지 취득해 내부 통제가 일정 기간 안정적으로 작동했음을 입증했다. ## SOC 2 인증으로 검증한 보안 통제 - SOC 2는 클라우드에 저장된 고객 데이터를 보호하기 위한 미국 소프트웨어 기업의 대표적인 보안 준수 기준이다. - 인증 과정에서 인프라, 소프트웨어, 인사 절차, 고객 데이터 처리 정책과 통제를 종합적으로 감사한다. - SOC 2 Type 1은 특정 시점에 통제가 마련되어 있는지를 확인하는 일종의 스냅샷이다. - SOC 2 Type 2는 통제가 일정 기간 실제로 작동했는지까지 검증하므로 더 높은 수준의 보증을 제공한다. - Figma는 글 작성 당시 Type 1 인증을 완료하고 Type 2를 추진 중이었으며, 2020년 업데이트에서 SOC 2 Type 2와 SOC 3 보고서 취득을 발표했다. ## 유럽 고객을 위한 데이터 보호와 준수 - 유럽 고객 증가에 맞춰 EU와 국제적인 데이터 보호 및 보안 요구사항을 충족하는 것을 목표로 했다. - EU-US Privacy Shield와 Swiss-US Privacy Shield 프레임워크 인증을 취득했다. - 이를 통해 유럽 및 스위스 고객이 Figma에 디자인 데이터를 저장할 때 필요한 개인정보 보호 체계를 마련했다고 설명한다. ## 기능 개발 단계부터 적용한 보안 원칙 - 보안은 별도의 사후 검토가 아니라 새로운 기능을 설계하고 개발하는 단계부터 고려하는 원칙으로 제시된다. - 특히 Figma Plugins처럼 외부 개발자가 플랫폼을 확장하는 기능은 보안·안정성·성능 사이의 균형이 중요했다. - 플러그인은 한 번에 하나의 디자인 파일에만 접근할 수 있다. - 플러그인이 사용자의 전체 계정이나 다른 플러그인의 데이터에 접근할 수 없도록 격리했다. - 플러그인이 Figma UI를 변경하지 못하게 해 사용자를 속이거나 피싱으로 유도할 가능성을 줄였다. - 일부 기능과 확장성을 제한하더라도 고객 데이터 보호를 우선한 설계 결정이었다. ## SAML SSO를 통한 기업 계정 관리 - 기업 고객을 위해 SAML 기반 싱글 사인온(SSO)을 지원했다. - SSO는 로그인 절차를 단순화하는 동시에 조직 전체에 Figma를 배포하고 사용자 접근 권한을 중앙에서 관리할 수 있게 한다. - 기존 Okta와 Microsoft Azure Active Directory에 더해 OneLogin도 통합 대상으로 추가했다. - 기업은 기존 인증·접근 관리 체계와 Figma를 연결해 퇴사자 계정 차단이나 사용자 권한 관리 등을 일관되게 운영할 수 있다. ## 실용적인 시사점 Figma의 사례는 SaaS 보안에서 인증서 취득만으로 끝나는 것이 아니라, 장기간 작동하는 내부 통제와 기능별 권한 격리, 기업용 접근 관리까지 함께 구축해야 한다는 점을 보여준다. 특히 플러그인이나 확장 기능을 도입할 때는 가능한 기능을 늘리는 것보다 데이터 접근 범위를 최소화하고 사용자 신뢰를 보호하는 설계가 우선되어야 한다.

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

몇 초 만에 디자인에 실제 콘텐츠

실제 콘텐츠를 활용하면 목업이 실제 제품에서 어떻게 보일지 더 정확히 검증하고, 긴 텍스트나 다양한 데이터로 UI를 스트레스 테스트할 수 있다. 글은 Figma에서 이름·주소·이미지·지도 등을 자동으로 채워 주는 플러그인들을 소개하며, 반복적인 수동 입력을 줄이는 방법을 설명한다. 민감한 사내 데이터가 필요하다면 조직 전용 비공개 플러그인을 활용할 수도 있다. ## 실제 데이터로 디자인해야 하는 이유 - Lorem Ipsum 같은 placeholder는 실제 콘텐츠의 길이와 형식을 충분히 반영하지 못한다. - 이름, 전화번호, 주소, 이미지, 지도 등 현실적인 데이터를 넣으면 다음을 검증할 수 있다. - 긴 텍스트가 레이아웃을 깨뜨리는지 - 다양한 데이터 형식이 UI에 적합한지 - 실제 서비스 화면과 목업의 차이가 큰지 - 복잡한 문서의 여러 텍스트 레이어를 수동으로 채우는 작업을 자동화할 수 있다. ## Google Sheets Sync - Google Sheets의 데이터를 Figma 레이어와 연결해 일괄 입력한다. - 사용 방법: - 공유 가능한 Google Sheets를 만든다. - 데이터 종류별로 열을 만들고, 각 열에 고유한 헤더를 지정한다. - Figma 레이어 이름을 `#Name`, `#Address`처럼 `#`과 열 헤더 조합으로 지정한다. - 플러그인에 시트 URL을 입력하고 **Fetch & sync**를 실행한다. - 스프레드시트의 수식과 편집 기능을 그대로 활용할 수 있어 데이터 수정과 재동기화가 편리하다. - 이미지 URL이 들어 있는 열도 지원하며, 해당 레이어에 이미지 채우기로 적용할 수 있다. ## Unsplash - Unsplash의 고해상도 사진을 Figma 캔버스에 삽입한다. - 카테고리 선택, 무작위 이미지 선택, 직접 검색을 지원한다. - 이미지를 새 요소로 삽입하거나, 미리 선택한 요소에 이미지 채우기로 적용할 수 있다. - 개인 및 상업적 용도로 사용할 수 있는 대규모 무료 사진 라이브러리를 활용할 수 있다. ## Data Lab - 변수 조합 방식으로 텍스트 콘텐츠를 생성한다. - 이름, 숫자, 날짜, 전화번호, 이메일, 목록 등의 데이터 형식을 제공한다. - 예를 들어 `{NAME} · {EMAIL}`처럼 변수를 조합해 이름과 이메일을 한 문자열로 만들 수 있다. - 단순한 형식으로 다양한 텍스트 샘플을 빠르게 생성할 수 있다. ## Content Reel - 이름, 전화번호, 미국 주소, 숫자, 이메일, URL, 회사명, 사용자명, 국가 등의 텍스트 데이터를 제공한다. - 주소 같은 데이터 형식은 드래그 앤 드롭으로 구성 요소와 순서를 바꿀 수 있다. - 쉼표 배치까지 조정할 수 있어 원하는 데이터 포맷을 만들기 쉽다. - Segoe MDL2 아이콘 라이브러리도 제공하지만, 사용하려면 Segoe 아이콘 폰트를 설치해야 한다. - 작업 중 패널을 작게 접어 둘 수 있는 compact mode를 지원한다. - 당시에는 사용자 프로필 이미지 같은 이미지 기반 콘텐츠 지원도 예정되어 있었다. ## Mapsicle - Mapbox 지도를 Figma 요소의 이미지 채우기로 삽입한다. - 지도 스타일, 확대 수준, 카메라 기울기와 회전을 설정할 수 있다. - 기본적으로 Light, Dark, Satellite, Streets 등의 테마를 제공한다. - Mapbox 액세스 토큰을 사용하면 직접 만든 사용자 정의 지도 테마도 적용할 수 있다. - 기존 지도의 크기를 바꿀 때 **Refresh selected map**을 사용하면 기존 확대 수준을 유지하면서 새 크기에 맞게 갱신할 수 있다. - 지도를 작은 프레임 안에 넣고 프로토타입의 오버플로를 가로·세로 스크롤로 설정하면 양방향 지도 탐색을 구현할 수 있다. ## 사내 데이터와 비공개 플러그인 - 실제 서비스의 민감한 데이터나 내부 API를 활용해야 하는 경우 공개 플러그인보다 자체 플러그인이 적합하다. - Figma Organization 요금제 사용자는 회사 전용 비공개 플러그인을 만들고 배포할 수 있다. - 이를 통해 외부에 데이터를 노출하지 않고 실제 애플리케이션 데이터를 디자인 검증에 활용할 수 있다. 실무에서는 Google Sheets Sync로 구조화된 데이터를 반복 주입하고, Unsplash·Mapsicle로 이미지와 지도를 보완하면 빠르게 현실적인 목업을 만들 수 있다. 데이터가 민감하거나 서비스 API와 직접 연동해야 한다면 조직 전용 비공개 플러그인을 고려하는 것이 좋다.

원문 읽기(새 탭에서 열림)
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` 반복적인 화면 검증, 컴포넌트 복제, 텍스트 정리, 일괄 수정이 자주 발생한다면 이 플러그인들을 작업 흐름에 맞게 조합해 사용하는 것이 좋다. 특히 플러그인 이름을 메뉴 검색으로 실행하는 습관을 들이면 마우스 조작까지 줄일 수 있다.

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