figma-api

11 개의 포스트

figma3분 읽기큐레이션 요약

AI: 디자인의 새로운

AI는 디자인 도구의 한 기능이 아니라 제품 개발 전반을 바꾸는 플랫폼이라는 것이 글의 핵심 주장이다. Figma는 Diagram을 인수하고 AI 역량을 강화해 아이디어 발굴부터 디자인, 개발 코드 생성까지 팀의 작업을 가속하려 한다. AI가 디자이너를 대체하기보다는 반복 작업을 줄이고 문제 해결과 창의적 판단에 더 집중하게 만들 것이라는 전망을 제시한다. ## Figma의 Diagram 인수와 AI 전략 - Figma는 GPT-3 기반 디자인 생성 플러그인 **Designer**를 만든 Jordan Singer의 팀 Diagram을 인수했다. - Diagram의 Jordan Singer, Siddarth, Andrew, Marco, Vincent가 Figma에 합류했다. - Figma는 이미 머신러닝 전담 팀을 운영하고 AI 플랫폼 개발에 투자해 왔다. - Figma의 오픈 API를 활용해 커뮤니티가 만든 AI 플러그인도 약 100개에 이른다. - AI를 단일 기능이 아니라 제품 개발 프로세스 전체를 지원하는 핵심 플랫폼으로 보고 있다. ## 제품 개발 전 과정의 AI 활용 - **발견 단계** - 간단한 프롬프트로 초기 아이디어를 생성한다. - 여러 아이디어를 요약하고 종합한다. - **디자인 단계** - 기존 디자인과 디자인 시스템을 분석한다. - 적절한 컴포넌트나 디자인 방향을 추천한다. - 더 빠르게 첫 시안을 만들 수 있도록 지원한다. - **개발 단계** - 디자인의 맥락을 개발자에게 더 빠르게 전달한다. - 제품 요구사항과 디자인을 바탕으로 더 나은 프로덕션 코드를 생성한다. - 결과적으로 AI는 반복 작업을 줄이고 팀이 더 빠르게 문제 해결과 제품 완성도 향상에 집중하도록 돕는다. ## 기술 발전과 디자인의 변화 - 인쇄기, 스마트폰, 협업 도구, 하이브리드 근무처럼 디자인은 기술 변화에 따라 계속 진화해 왔다. - 새로운 기술이 등장해도 사려 깊은 디자인의 필요성이 사라진 것은 아니었다. - AI 역시 디자인을 없애기보다 디자이너의 작업 방식과 역할을 변화시킬 것으로 본다. ## 픽셀에서 패턴으로: 더 높은 수준의 설계 - 디자인 시스템은 모서리 반경이나 버튼 같은 반복적인 세부 작업을 줄이고, 디자이너가 콘셉트와 방향성에 집중하게 했다. - 원자적 요소인 픽셀이 컴포넌트와 같은 더 큰 구조로 결합되면서 작업 속도와 일관성이 향상됐다. - AI는 디자인 시스템보다 더 높은 수준의 구조와 패턴을 제안할 수 있다. - 예를 들어 로그인 화면의 이메일 입력창과 비밀번호 입력창을 만드는 데 그치지 않고, 이메일·전화번호·Touch ID를 대체할 새로운 로그인 방식을 제안할 수 있다. - 프로젝트의 감정적 분위기나 주제에 맞는 색상 팔레트를 자동으로 추천하는 것도 가능하다. - 디자인은 개별 픽셀을 조정하는 작업에서 벗어나 더 직관적이고 인간적인 경험을 설계하는 방향으로 이동한다. ## 새로운 디지털 경험의 등장 - ChatGPT와 같은 AI는 웹사이트와 앱을 탐색하는 기존 방식에서 벗어나 질문하고 답을 받는 인터페이스를 강화한다. - AI는 사용자의 의도와 실제 행동 사이의 간극을 줄일 수 있다. - 예를 들어 사용자가 차량 호출 앱에서 위치와 옵션을 여러 단계로 입력하는 대신, “JFK 공항으로 데려다줘”라고 말하면 AI가 필요한 절차를 처리할 수 있다. - 제품 설계자는 기능과 화면 수를 늘리는 대신, 사용자의 목적을 더 적은 클릭과 판단으로 달성하게 할 방법을 고민해야 한다. ## 디자이너와 제품 역할의 변화 - 글은 AI 시대에 제품 역할과 협업 방식도 변화할 것이라고 예고한다. - 반복적인 제작 업무가 자동화되면 디자이너는 결과물을 직접 만드는 일뿐 아니라 AI가 제안한 결과를 선택하고 다듬는 큐레이터 역할을 더 많이 맡게 될 가능성이 있다. - 디자인의 핵심 가치는 여전히 문제를 정의하고, 적절한 방향을 판단하며, 사람에게 의미 있는 경험을 만드는 데 있다. AI를 도입할 때는 단순히 디자인 산출물을 자동 생성하는 데 그치지 말고, 아이디어 정리·패턴 탐색·프로토타이핑·개발 전달 등 전체 흐름에서 반복 작업을 줄이는 방향을 고려하는 것이 실용적이다. 최종 품질과 사용자 경험을 결정하는 문제 정의와 판단은 여전히 사람의 중요한 역할로 남는다.

원문 읽기(새 탭에서 열림)
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분 읽기큐레이션 요약

플러그인 비하인드

재키 추이는 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분 읽기큐레이션 요약

플러그인 비하인드

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에 플러그인이 도입

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의 안정성과 성능 영향을 함께 고려하는 것이 좋다.

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

깃허브, 협업 문화를

GitHub는 원격 협업 환경에서 디자인 시스템을 효율적으로 운영하기 위해 Figma를 도입했다. Figma와 API를 활용해 아이콘·UI 컴포넌트 제작 과정을 자동화하고, 디자이너와 개발자가 같은 파일에서 실시간으로 협업할 수 있게 했다. 그 결과 디자인 시스템은 GitHub의 일하는 방식에 핵심 요소로 자리 잡았고, 반복 작업과 협업 장벽을 줄이는 기반이 되었다. ## 디자인 시스템 전담 조직의 성장 - 2015년 당시 GitHub에는 디자인 시스템을 전담하는 직원이 없었다. - 디자이너들이 동일한 요소를 반복해서 만들고, 문서가 부족하며, 패턴이 오래된 문제가 있었다. - 이를 해결하기 위해 디자인 시스템과 문서화된 워크플로를 구축하는 풀뿌리 활동을 시작했다. - 활동 시작 6개월 만에 전담 팀이 만들어졌으며, 이후 7명 규모로 성장했다. - 전체 제품 디자인 팀 25명 중 7명이 재사용 가능하고 교체 가능한 컴포넌트를 관리하게 되었다. - 디자인 시스템은 GitHub의 디자인·개발 프로세스를 효율적이고 반복 가능하며 확장 가능하게 만드는 핵심 기반이 되었다. ## 기존 디자인 워크플로의 문제점 - 전담 팀을 구성해도 디자인 시스템을 만들고 유지하는 과정 자체가 비효율적이었다. - SVG 아이콘 라이브러리인 **Octicons**를 수정하려면 특정 소프트웨어 설치와 관련 도구에 대한 지식이 필요했다. - 이런 복잡한 설정은 기여자가 아이콘을 수정하거나 업데이트하는 일을 어렵고 혼란스럽게 만들었다. - 결과적으로 디자인 시스템에 참여하려는 사람들의 진입 장벽이 높아졌다. ## Figma와 API를 통한 기여 과정 자동화 - GitHub는 Octicons를 Figma로 이전하는 실험을 시작했다. - Figma는 별도의 소프트웨어를 다운로드하거나 설치하지 않아도 브라우저에서 작업할 수 있었다. - Figma API를 함께 사용해 아이콘 업데이트 과정을 자동화할 수 있었다. - 디자이너와 개발자는 운영체제나 도구에 관계없이 복잡한 설정 없이 디자인 시스템에 기여할 수 있게 되었다. - Octicons에서 얻은 효과를 바탕으로 UI 컴포넌트도 Figma로 이전했다. - 이후 GitHub의 디자인과 개발에 필요한 대부분의 요소를 Figma에서 이용할 수 있게 되었다. ## 원격 팀을 위한 ‘DesignHub’ - GitHub는 원래 도구에 구애받지 않는 팀이었지만, Figma 사용은 빠르게 확산되었다. - 웹 기반 협업 기능 덕분에 서로 다른 장소에서 일하는 팀원들이 같은 파일에 동시에 참여할 수 있었다. - Figma는 물리적으로 함께 모여 화이트보드 앞에서 작업하는 경험을 대체했다. - 디자이너들은 실제로 한 공간에 있는 팀처럼 아이디어를 공유하고 발전시킬 수 있었다. - 여러 디자이너가 Figma 파일에서 즉석으로 아이디어를 결합하는 ‘디자인 잼’을 진행하며 창의적인 탐색을 활성화했다. ## 프로토타이핑과 스토리텔링의 통합 - GitHub의 디자이너들은 Figma를 디자인 과정뿐 아니라 스토리텔링 전반에 활용했다. - 디자인은 사용자 경험의 이야기를 전달하는 과정이며, 프로토타입은 그 이야기를 실제 흐름으로 보여주는 수단으로 여겨졌다. - Figma에서는 다른 도구로 전환하지 않고 요소를 빠르게 배치하고 이동해 화면 흐름을 제안할 수 있었다. - 프로토타이핑의 진입 장벽이 낮아지면서 아이디어를 빠르게 표현하고 검증할 수 있었다. ## 협업 중심 문화와 도구의 결합 - GitHub는 기능과 도구가 모두 협업을 촉진해야 한다는 문화를 갖고 있다. - Figma는 디자이너와 엔지니어가 함께 작업하도록 설계된 도구라는 점에서 GitHub의 문화와 잘 맞았다. - 디자인 시스템을 단순한 결과물이나 라이브러리가 아니라 여러 직군이 함께 개선하는 협업 공간으로 발전시켰다. - 웹 기반 편집, 실시간 공동 작업, API 자동화를 조합해 원격 협업의 물리적 한계를 줄였다. GitHub 사례는 디자인 시스템의 효과를 높이려면 컴포넌트를 만드는 것뿐 아니라 누구나 쉽게 기여할 수 있는 워크플로를 함께 설계해야 한다는 점을 보여준다. 특히 웹 기반 협업 도구와 API 자동화를 결합하면 원격 팀에서도 디자인·개발 간 피드백과 반복 작업을 크게 줄일 수 있다.

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

소개합니다: 피그

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 경연은 상품 범위, 평가 기준, 참가자 권리와 운영 방식에 대한 충분한 사전 검토와 소통이 중요하다는 교훈도 남겼다.

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

마이크로소프트, 피

Microsoft Dynamics 365 for Talent 디자인팀은 Figma API와 웹훅을 활용해 디자인-개발 핸드오프를 자동화했다. 디자이너가 파일의 새 버전을 저장하면 자동으로 Pull Request가 생성되고, 디자인·개발팀의 검토와 승인 후 변경 사항이 제품에 반영된다. 그 결과 기존 업무 흐름을 약 70% 줄이고, 디자이너와 엔지니어가 각자의 핵심 업무에 더 집중할 수 있게 됐다. ## 대규모 조직에서 발생한 디자인 핸드오프 문제 - Microsoft는 사내 해커톤인 **OneWeek**를 매년 개최하며, 직원들이 기존 업무에서 벗어나 업무 개선 아이디어를 실험하도록 지원한다. - Dynamics 365 for Talent 팀은 Fluent Design System을 확장하면서 새로운 기능보다 시각적 디자인 요소를 확장하고 정교화하는 데 집중했다. - 디자이너와 엔지니어 비율을 약 **1:10**으로 유지하려 했지만, 디자인 변경 사항을 개발에 전달하는 과정이 병목이 됐다. - 디자이너는 작은 변경 사항을 반영하기 위해 요청을 설명하고 우선순위를 확보해야 했고, 엔지니어는 대규모 기업 업무 속에서 각 요청의 처리 순서를 조정해야 했다. - 이 때문에 단일 디자인 요소를 실제 제품에 배포하는 데 **최대 일주일 이상**이 걸리기도 했다. ## Figma API를 활용한 OneWeek 프로젝트 - 팀은 Figma를 적극적으로 사용하고 있었기 때문에, Figma의 웹 기반 API가 핸드오프 문제를 해결할 수 있다고 판단했다. - OneWeek 기간 동안 디자인 파일의 변경을 개발 워크플로와 연결하는 자동화 시스템을 구축했다. - 핵심은 Figma 파일의 변경을 감지하는 **Figma 웹훅(webhook)** 이었다. - 디자이너가 파일의 새 버전을 저장하면 웹훅이 이를 감지하고 후속 개발 프로세스를 자동으로 시작한다. ## 변경 사항을 Pull Request로 자동 전환 - 새 디자인 버전이 저장되면 자동으로 디자인·개발팀의 검토를 위한 **Pull Request**가 생성된다. - 양 팀은 Pull Request를 통해 변경 내용을 확인하고 승인할 수 있다. - 승인된 변경 사항은 엔지니어가 커밋하고 제품에 반영한다. - 기존처럼 디자이너가 개별 요청을 전달하고 엔지니어가 수동으로 우선순위를 정하는 대신, 디자인 변경이 코드 협업 흐름에 직접 연결된다. - 디자인 파일의 버전 관리와 코드 리뷰 프로세스를 결합해 책임과 승인 절차도 명확해졌다. ## 자동화가 가져온 효과 - 팀에 따르면 새로운 프로세스는 전체 업무 흐름을 **약 70% 단축**할 수 있었다. - 디자이너는 반복적인 설명과 요청 조율보다 디자인 작업에 더 많은 시간을 쓸 수 있게 됐다. - 엔지니어는 단순한 핸드오프 처리에서 벗어나 개발과 기술적 문제 해결에 집중할 수 있었다. - 디자인 변경 사항의 배포 속도가 빨라져, 조직 규모가 큰 환경에서도 디자인 시스템을 효율적으로 확장할 수 있는 기반이 마련됐다. 디자인과 개발 사이의 반복적인 전달 업무가 병목이라면, 디자인 도구의 API·웹훅을 코드 저장소 및 Pull Request 흐름과 연동하는 방식을 고려할 만하다. 특히 자동화만 도입하기보다 버전 저장, 검토, 승인, 커밋까지의 책임과 절차를 함께 정의해야 효과를 안정적으로 유지할 수 있다.

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

소개: Figma to React | 피

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를 디자인의 원천으로 활용하되, 변환된 코드를 그대로 최종 코드로 취급하기보다 시각적 구조와 기능 로직을 분리하는 초기 코드 생성 도구로 사용하는 것이 적절하다.

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

Figma API 영감이 필요하신가

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 래퍼나 오픈 소스 커넥터를 기반으로 팀의 디자인·개발 프로세스에 맞는 자동화 도구를 구축할 수 있다.

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