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

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** 모드에서 테스트하는 것이 좋다.

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

DesignSystems.com의 새로운

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 변수나 디자인 토큰을 활용하면 일관성과 유연성을 동시에 확보할 수 있다.

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

Figma의 새로운 기능 요

Figma는 2019년 봄, 디자인 시스템 확장에 초점을 맞춰 Components를 개선하고 플러그인 API 공개 베타를 시작했다. 여러 컴포넌트를 한 번에 생성하거나 인스턴스와 마스터 간 이동·동기화를 쉽게 만드는 기능으로 반복 작업을 줄였으며, 플러그인을 통해 커뮤니티가 Figma 기능을 확장할 수 있는 기반을 마련했다. 또한 Smart Selection 등 일상적인 기능 개선과 버그 수정도 함께 진행했다. ## 디자인 시스템 확장을 위한 컴포넌트 개선 - 여러 객체를 선택한 뒤 한 번의 클릭으로 각각의 Component로 변환할 수 있다. - 인스턴스를 우클릭하면 Context Menu에서 관련 Component를 바로 확인할 수 있다. - 다른 인스턴스로 빠르게 교체할 때 유용하다. - **Return to Instance** 기능을 사용하면 현재 인스턴스의 Master Component로 이동해 참고하거나 수정한 뒤, 작업 중이던 인스턴스로 돌아올 수 있다. - 로컬 컴포넌트에서는 인스턴스에 적용한 변경 사항과 오버라이드를 Master Component에 반영할 수 있다. - 기존 컴포넌트를 실제 사용 사례에 맞게 조정하고 업데이트할 때 효율적이다. - 이러한 기능들은 재사용 가능한 UI 요소를 관리하고, 팀 단위 디자인 시스템을 확장하는 작업을 단순화한다. ## Figma 플러그인 API 공개 베타 - Figma는 오랫동안 준비한 플러그인 API의 공개 베타를 출시했다. - 플러그인을 통해 사용자가 Figma 내부 기능을 직접 확장하고 반복적인 디자인 작업을 자동화할 수 있게 됐다. - 초기 제작 사례로 다음과 같은 플러그인이 소개됐다. - 텍스트 요소를 방사형으로 반복 배치하는 생성형 디자인 플러그인 - 선택한 이미지에서 주요 색상 팔레트를 추출하는 플러그인 - 공개 직후부터 커뮤니티와 고객들이 다양한 실험적 도구를 만들며 생태계의 가능성을 보여줬다. ## 지속적인 사용성 개선과 품질 향상 - Components와 Smart Selection처럼 매일 사용하는 기능을 빠르게 개선했다. - 사용자가 요청해 온 기능을 추가하는 동시에, 반복 작업에 드는 시간을 줄이는 데 초점을 맞췄다. - 별도의 품질 개선 기간을 운영해 다수의 버그를 수정했다. - 이번 업데이트는 대규모 신기능뿐 아니라 기존 기능의 안정성과 작업 흐름 개선도 중요하게 다뤘다. ## 실용적인 활용 방향 - 반복되는 UI 요소는 Component로 만들고, 여러 객체를 한 번에 변환해 초기 구축 시간을 줄이는 것이 좋다. - 인스턴스에서 발견한 개선 사항은 로컬 컴포넌트의 Master에 반영해 디자인 시스템을 최신 상태로 유지할 수 있다. - 이미지 색상 추출이나 생성형 배치처럼 반복적이거나 계산이 필요한 작업은 플러그인으로 자동화할 수 있다.

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

Figma에 플러그인이 도입

Figma는 디자인 작업을 확장할 수 있는 플러그인 베타를 출시하며, 개발자들의 참여를 요청했다. 플러그인은 반복 작업 자동화, 외부 데이터 활용 등으로 디자인 워크플로를 개선할 수 있으며, 장기적으로는 커뮤니티가 만든 플러그인을 누구나 사용할 수 있도록 하는 것이 목표다. Figma는 안정성·보안·성능을 보장하기 위해 내부 API가 아닌 서드파티 전용 API를 설계했다고 강조한다. ## Figma 플랫폼에서 플러그인으로 확장 - Figma는 1년 전 HTTP 기반 Figma API를 공개해 외부 도구와의 연동을 지원했다. - 고객들은 API를 활용해 다음과 같은 워크플로를 구축했다. - Slack 명령으로 Figma 아이콘을 문서에 내보내기 - 디자인 파일 변경 사항을 개발 환경에 자동 반영하기 - SVG 아이콘 라이브러리를 효율적으로 업데이트·배포하기 - 플러그인은 기존 API 연동을 넘어 Figma 내부의 디자인 작업 과정을 직접 확장하는 다음 단계로 소개됐다. ## 플러그인으로 가능한 작업 - 반복적인 디자인 작업을 자동화할 수 있다. - 실제 데이터를 Figma 파일에 가져와 디자인에 활용할 수 있다. - 팀 구성원과 직접 만든 플러그인을 공유할 수 있다. - 웹사이트 제작 경험이 있는 개발자라면 비교적 쉽게 플러그인을 만들고 유지할 수 있도록 설계됐다. ## 안정성과 보안을 고려한 API 설계 - 플러그인이 Figma 업데이트 때마다 작동을 멈추는 문제를 방지하려 했다. - 내부 API를 그대로 공개하면 플랫폼 변경에 따라 API가 자주 바뀌고, 서드파티 개발자는 매번 코드를 수정해야 한다. - Figma는 플러그인 개발자를 위해 별도의 공식 API를 설계하고, 플러그인이 의존하는 API를 지속적으로 지원·관리하겠다고 밝혔다. - 플러그인이 Figma의 성능이나 사용자 경험을 저해하지 않도록 하는 것도 중요한 원칙으로 제시됐다. ## 플러그인 생태계의 설계 원칙 - 모든 디자이너가 쉽고 직관적으로 사용할 수 있어야 한다. - 웹사이트를 만들 수 있는 사람이라면 플러그인을 개발할 수 있어야 한다. - 인기 있는 프로그래밍 언어로 플러그인을 작성할 수 있어야 한다. - 플러그인이 Figma의 성능과 사용성을 해치지 않아야 한다. - 플러그인이 사용하는 모든 API를 Figma가 공식적으로 지원해야 한다. ## 베타 참여 대상과 운영 방식 - 기본적인 HTML과 JavaScript 지식이 있고 플러그인 아이디어가 있는 사람을 대상으로 했다. - 초기에는 참여 인원이 제한되며, 어떤 플러그인을 만들려는지에 따라 우선순위를 정했다. - 다양한 아이디어를 가진 베타 사용자가 API를 실제로 시험하고 개선 방향을 제시하도록 하는 것이 목적이었다. - 당시에는 개발자 중심의 베타였지만, 이후 코딩하지 않는 사용자도 커뮤니티 플러그인을 사용하게 될 것이라고 예고했다. 플러그인은 Figma를 단순한 디자인 도구가 아니라 개발자와 커뮤니티가 기능을 확장하는 플랫폼으로 전환하는 핵심 수단이다. 플러그인을 도입하려는 팀은 반복 업무 자동화나 실제 데이터 연동처럼 효과가 분명한 작업부터 시작하고, 공식 API의 안정성과 성능 영향을 함께 고려하는 것이 좋다.

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

TUF와 in-toto를 활용한 Datadog Agent 통합 기능의 안전한 배포 (새 탭에서 열림)

Datadog은 에이전트 통합 기능의 배포 주기를 에이전트 본체와 분리하여 자동화하는 동시에, 전체 공급망의 보안을 보장하기 위해 TUF(The Update Framework)와 in-toto를 도입했습니다. 기존의 TLS나 GPG 방식이 해결하지 못하는 인프라 침해 공격에 대응하기 위해, 개발자의 코드 커밋부터 최종 사용자의 설치 단계까지 모든 과정을 검증 가능한 구조로 설계했습니다. 이를 통해 Datadog은 자동화된 배포의 효율성과 '침해 저항성(Compromise-resilience)'을 갖춘 강력한 보안을 동시에 달성했습니다. ## 자동 배포의 필요성과 보안 과제 * **배포 주기 분리:** 수백 개의 통합 패키지를 에이전트 릴리스와 분리하여 독립적으로 업데이트함으로써 사용자에게 최신 기능을 신속하게 제공하고자 했습니다. * **기존 보안의 한계:** TLS 암호화나 단순 GPG 서명은 중간자 공격(MitM)은 방어할 수 있지만, 개발자와 사용자 사이의 인프라가 침해되어 코드가 변조되는 상황에는 취약합니다. * **침해 저항 시스템 구축:** 인프라의 일부가 장악되더라도 소프트웨어의 진본성과 무결성을 보호할 수 있는 CI/CD 시스템이 필요했습니다. ## in-toto를 통한 소프트웨어 공급망 검증 * **단계별 무결성 보장:** 소프트웨어 공급망을 코드 작성, 패키징(Wheel 파일 생성), 서명 등 일련의 고정된 단계로 정의하고 각 단계마다 입력과 출력에 대한 서명된 메타데이터를 생성합니다. * **최종 검증 과정:** Datadog 에이전트는 설치 시 서명된 메타데이터를 검사하여, 해당 패키지가 지정된 담당자에 의해 정의된 절차대로 생성되었는지 확인합니다. * **4단계 워크플로우:** 1. 개발자가 Python 소스 코드와 YAML 설정 파일을 작성합니다. 2. CI/CD 시스템이 소스 코드를 수신하여 Python Wheel(ZIP 파일)로 패키징합니다. 3. CI/CD 시스템이 동일한 Wheel 파일들에 대해 TUF 서명을 수행합니다. 4. 에이전트가 파일을 다운로드하여 개발자가 서명한 코드와 정확히 일치하는지 최종 확인합니다. ## TUF를 활용한 안전한 키 관리 및 전송 * **신뢰의 뿌리(Root of Trust):** in-toto가 공급망 단계를 검증한다면, TUF는 검증에 사용되는 공개키를 안전하게 배포, 취소, 교체하는 역할을 담당합니다. * **공격 방어:** 메타데이터의 일관성과 진본성을 보장하며, 공격자가 이전 버전으로 되돌리는 롤백(Rollback) 공격이나 무한 재생(Replay) 공격을 방지합니다. * **오프라인 부트스트래핑:** TUF를 통해 신뢰를 오프라인에서 구축하고 하드웨어 키로 개발자 서명 키를 보호함으로써 in-toto의 보안 보장을 더욱 공고히 합니다. ## Yubikey 기반의 하드웨어 보안 서명 * **키 유출 방지:** 개발자는 GPG 서명 키를 생성하고 저장할 수 있는 하드웨어 키(Yubikey)를 사용하며, 키는 장치 외부로 내보낼 수 없습니다. * **다중 보호 계층:** 서명 작업을 승인하기 위해서는 비밀번호(PIN) 입력과 장치에 대한 물리적인 터치가 반드시 필요합니다. * **사용 편의성:** CLI 도구를 통해 in-toto와 GPG 호출 과정을 투명하게 처리하여, 개발자의 업무 흐름을 방해하지 않으면서도 키 침해 위험을 최소화했습니다. ## 사용자 경험과 실용적 결론 * **투명한 보안:** 사용자는 평소와 다름없이 에이전트를 통해 통합 기능을 설치하지만, TUF나 in-toto가 공격을 감지하면 즉시 설치를 차단하고 상세한 오류 메시지를 표시합니다. * **업계 표준 지향:** Datadog은 이처럼 두 기술을 밀접하게 통합함으로써 보안 소프트웨어 배포가 단순히 '선택 사항'이 아닌 업계의 '표준'이 되도록 기여하고 있습니다. * **추천 사항:** 자동화된 CI/CD 환경에서 보안을 강화하려는 조직은 소프트웨어 공급망의 각 단계를 투명하게 기록하는 in-toto와 키 관리 체계를 담당하는 TUF의 조합을 검토할 필요가 있습니다.