cloudflare·2026년 3월 3일원문

위험 탐지부터 해결까지: (새 탭에서 열림)

Cloudflare가 자사의 Cloud Access Security Broker(CASB)에 탐지된 보안 위험을 대시보드에서 즉시 수정할 수 있는 '리메디이에션(Remediation)' 기능을 도입했습니다. 그동안 CASB가 SaaS 앱 내의 설정 오류나 과도한 파일 공유를 시각화하는 데 집중했다면, 이제는 보안 팀이 별도의 관리 도구 없이 원클릭으로 문제를 해결할 수 있는 능동적인 제어 평면으로 진화했습니다. 이 기능은 먼저 Microsoft 365와 Google Workspace를 대상으로 출시되어 비즈니스 크리티컬한 데이터의 노출을 신속하게 차단합니다. **SaaS 보안 가시성에서 즉각적인 조치로의 확장** * Cloudflare CASB는 Microsoft 365, Google Workspace, Slack, GitHub 등 다양한 SaaS 환경과 API로 연결되어 통합된 보안 뷰를 제공합니다. * 기존 프로세스에서는 보안 팀이 발견된 위험을 해결하기 위해 각 앱의 개별 관리자 UI에 접속하거나 해당 툴의 담당자에게 티켓을 발송해야 하는 번거로움이 있었습니다. * 리메디이에션 기능은 이러한 루프를 폐쇄하여, 발견(Finding) 페이지에서 직접 공유 설정을 변경함으로써 조치 시간을 획기적으로 단축합니다. **고위험 파일 공유 리스크 해결** * 인터넷상의 누구나 접근 가능한 공공 링크, 전사적 공유 설정, 외부 도메인이나 개인 계정으로의 공유 등 가장 빈번하고 위험한 공유 패턴을 즉시 해제합니다. * 특히 고객 정보나 금융 데이터 등 민감 정보를 포함한 DLP(데이터 손실 방지) 프로필과 일치하는 파일에 대해 우선적인 조치가 가능합니다. * 이 기능은 파일 자체를 삭제하거나 소유권을 변경하지 않고 '위험한 공유 구성'만을 제거하여 업무의 연속성을 해치지 않으면서 보안을 강화합니다. **서버리스 아키텍처를 통한 기술적 안정성 확보** * Cloudflare Workers, Workflows, Queues, Hyperdrive 등 자사의 기술 스택을 활용해 대규모 환경에서도 빠르고 견고한 실행 환경을 구축했습니다. * 서드파티 API 호출 시 발생하는 속도 제한(429 에러) 문제를 Workflows의 기본 재시도(Retry) 기능을 통해 별도의 복잡한 상태 추적 시스템 없이도 효율적으로 관리합니다. * 성능 테스트 결과, 작업 완료 시간 중간값(p50)은 48초, 90분위수(p90)는 72초로 매우 빠른 응답성을 보이며 모든 조치 내역은 SIEM 연동을 위해 관리자 로그에 기록됩니다. **향후 계획 및 자동화 방향** * 향후 고위험 파일을 안전한 장소로 격리하는 'Quarantine' 조치와 티켓 생성 등 외부 워크플로우를 트리거하는 '커스텀 웹훅' 기능을 추가할 예정입니다. * 보안 정책에 따라 CASB가 자동으로 위험을 수정하는 '자동 리메디이에션(Autoremediation)' 정책을 도입하여 보안 운영의 효율성을 더욱 높일 계획입니다. SaaS 환경에서 발생하는 데이터 유출 사고의 상당수가 실수로 설정된 공유 권한에서 기인하는 만큼, Microsoft 365나 Google Workspace를 사용하는 조직은 CASB 리메디이에션 기능을 통해 '가시성 확보'와 '즉각적인 위험 제거'라는 두 마리 토끼를 잡을 것을 권장합니다. 특히 DLP 프로필과 연계하여 민감한 데이터가 포함된 파일의 외부 공유를 정기적으로 점검하고 즉시 조치하는 프로세스를 수립하는 것이 좋습니다.

API데이터베이스 설계cloudflaresaas+4

kakao·2026년 2월 11일·2분 읽기큐레이션 요약

Kanana-o 신규 모델 및 API 베타 서비스를 공개합니다.

카카오는 한국어와 한국적 맥락을 깊이 이해하고 텍스트·이미지·오디오를 통합 처리하는 옴니 모델 **Kanana-o**를 공개하고, 정식 상용화에 앞서 API 클로즈드 베타를 진행한다. 베타 모델은 **Kanana-1.5-o-9.8b-2602**이며, 자연스러운 한국어 발화와 감정 표현, 다중 화자·멀티턴 대화 등 다양한 활용을 목표로 한다. 카카오는 실제 서비스 아이디어를 가진 개발자와 연구자들의 사용 및 피드백을 통해 기술 가능성을 검증할 계획이다. ## 한국어와 멀티모달에 특화된 Kanana-o - 텍스트, 이미지, 오디오 등 두 가지 이상의 입력을 동시에 이해하고 처리하는 통합 멀티모달 언어 모델이다. - 한국어의 표현과 문화적 맥락, 복잡한 사용자 의도를 깊이 있게 해석하도록 설계됐다. - 억양·속도·감정 등 화자의 특성을 반영해 자연스러운 한국어 음성을 생성한다. - 텍스트 생성 속도와 오디오 처리 속도의 균형을 고려해 대화형 애플리케이션에 적합하다. - 팟캐스트 분석, 멀티턴 대화, 다중 화자 대화 TTS 등 다양한 시나리오에 활용할 수 있다. ## API 베타 서비스 운영 방식 - 제공 모델은 **Kanana-1.5-o-9.8b-2602** 버전이다. - 대규모 트래픽을 처리하는 공개 서비스가 아니라, 개발자와 파트너가 직접 사용하며 피드백을 제공하는 클로즈드 베타 테스트다. - 운영 기간은 **2026년 2월 27일부터 5월 27일까지**다. - 베타 기간에는 정해진 일일 사용 횟수만큼 API를 테스트할 수 있다. ## 신청 절차와 선정 기준 - `omni.kanana.ai`에서 카카오 계정으로 로그인한다. - 소속, 사용 목적, 예상 시나리오 등을 포함한 비즈니스 폼을 작성해 대기 등록한다. - 선정된 참가자는 2월 27일부터 순차적으로 카카오톡 알림톡을 통해 초대장과 API 이용 가이드를 받는다. - 대상은 개발자, 학생, 스타트업, 연구자 등 구체적인 활용 계획을 가진 사용자다. - 단순히 “AI를 사용해보고 싶다”는 동기보다, 시각장애인용 쇼핑 도우미처럼 모델의 기능과 구현 방법이 명확한 제안이 유리하다. ## 기대되는 활용 분야 - 이미지 이해 기능을 활용한 시각장애인 지원 서비스 - 음성과 이미지를 결합한 대화형 비서 - 감정과 화자 특성을 반영한 콘텐츠 제작 및 TTS - 팟캐스트·회의 등 다중 화자 오디오 분석 - 한국어 중심의 교육, 고객 지원, 엔터테인먼트 애플리케이션 실제 베타 신청을 고려한다면 단순 체험보다 구체적인 사용자 문제, 입력 데이터 형태, API 활용 방식, 프로토타입 구현 계획을 명확히 작성하는 것이 좋다.

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

APIAIkanana-otext-to-speech+1

figma·2025년 3월 12일·3분 읽기큐레이션 요약

eBay가 Figma로 브랜드

eBay는 브랜드와 제품 팀이 따로 관리하던 디자인 시스템을 Figma 중심의 통합 문서 플랫폼인 ‘Evo Playbook’으로 재구축했다. 300쪽이 넘는 Playbook은 접근성, 디자인, 코드 정보를 한곳에 모으고, Figma 변경 사항을 자동 검증·게시해 문서를 살아 있는 업무 흐름으로 만들었다. 핵심은 중앙화된 문서, 라이브러리 메타데이터, Component Status API, Figma 플러그인 자동화다. ## 기존 문서화 방식의 한계 - 디자인 시스템 정보가 여러 Figma 파일에 흩어져 있었다. - 디자이너, 개발자, 접근성 담당자가 각각 별도의 문서를 관리했다. - 디자이너가 Figma의 정적 파일을 수정한 뒤, 별도 티켓을 통해 문서 사이트에 반영해야 했다. - 컴포넌트 상태를 수동 테이블로 관리해 정보가 빠르게 오래되었다. - 외부 에이전시가 만든 기존 Playbook은 실제 eBay의 디자인·개발 업무와 분리되어 유지보수가 어려웠다. ## Evo와 eBay Playbook의 통합 방향 - eBay는 기존 시스템을 부분 수정하지 않고 문서화 파이프라인을 처음부터 다시 설계했다. - 브랜드 가이드, 제품 디자인 시스템, 기술 문서를 별도 사이트가 아닌 하나의 공간에 통합했다. - 2024년 11월 공개된 Evo는 약 30년 된 eBay의 시각 언어를 현대화한 디자인 시스템이다. - 300쪽 이상의 Playbook을 통해 내부 팀과 외부 에이전시가 동일한 기준을 참고할 수 있도록 했다. - 문서를 단순한 참고 자료가 아니라 영감과 사용 경험을 제공하는 제품처럼 설계했다. ## Component Status API로 구현 상태 통합 - eBay는 모든 디자인 시스템 라이브러리의 컴포넌트 상태를 추적하는 내부 API를 만들었다. - Figma 컴포넌트 설명에 컴포넌트 이름과 버전 메타데이터를 기록한다. - API는 다음 라이브러리의 구현 여부와 버전을 통합적으로 확인한다. - Figma 컴포넌트 라이브러리 - 네이티브 라이브러리 - Skin, Marko, React 등 웹 컴포넌트 라이브러리 - Playbook의 컴포넌트 페이지에는 플랫폼별 리소스 링크, 최신 버전, 상태가 표시된다. - 개발자는 자신이 사용하는 프레임워크에 컴포넌트가 존재하는지, Figma 버전 및 문서와 일치하는지 바로 확인할 수 있다. ## Figma 기반 자동화와 게시 - 모든 컴포넌트, 가이드라인, 접근성 안내는 Figma에서 작성하고 수정한다. - eBay는 문서 내보내기 기능을 수행하는 자체 Figma 플러그인을 개발했다. - 플러그인은 변경 내용을 다음과 같이 처리한다. - 문서 구조와 콘텐츠를 추출 - 린팅을 통해 형식과 규칙을 검사 - 유효성을 검증 - CMS에 자동 게시 - 과거에는 문서 업데이트에 며칠이 걸렸지만, 자동화 이후 Figma 수정 사항이 2분 이내에 Playbook에 반영된다. - 개발자가 CMS를 직접 수정할 필요가 없어 문서 업데이트의 진입 장벽이 낮아졌다. ## 브랜드와 제품 조직 사이의 사일로 해소 - OneExperience 팀은 브랜드, 디자인 시스템, 디자인 기술, 콘텐츠를 아우르는 교차 기능 조직으로 구성됐다. - 디자인과 개발 문서가 서로 다른 원천에서 관리되지 않고 동일한 workflow에서 생성된다. - 디자인 시스템 문서가 실제 라이브러리와 자동으로 연결되므로 문서와 구현 사이의 불일치가 줄어든다. - 빠른 업데이트 덕분에 팀들이 문서화를 별도의 행정 업무가 아니라 일상적인 설계 과정의 일부로 받아들이게 되었다. ## 실용적인 적용 시사점 - 디자인 시스템 문서를 정적 웹 페이지로 관리하기보다 실제 설계 도구와 연결된 살아 있는 문서로 운영하는 것이 효과적이다. - 컴포넌트 이름과 버전을 메타데이터로 표준화하면 여러 플랫폼의 구현 상태를 자동으로 추적할 수 있다. - Figma 플러그인, 린터, API를 결합하면 문서 품질 검증과 게시를 자동화할 수 있다. - 브랜드 가이드와 제품 디자인 시스템을 분리하기보다 하나의 소스 오브 트루스로 통합하면 조직 간 협업과 일관성이 향상된다.

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

APIFigma디자인 시스템접근성+3

discord·2025년 2월 26일·3분 읽기큐레이션 요약

디스코드 업데이트:

2024년 Discord는 음성·채팅 이용 경험을 개선하기 위해 모바일 앱 안정성, 렌더링 속도, 서버 전환, GIF 검색, API 지연 시간 등을 집중적으로 최적화했다. iOS 충돌률은 84% 감소했고, 모바일 서버 전환 속도는 30% 이상 빨라졌으며, API 지연 시간은 약 25% 줄었다. 이 글은 이러한 연간 개선 사항을 연말 시 형식으로 정리한 회고다. ## iOS 안정성과 저장 공간 개선 - 장기간 발생하던 iOS 충돌 문제를 식별하고 계측·수정해 전체 충돌률을 **84% 감소**시켰다. - iOS 데이터 저장 방식을 개선해 기기 내 디스크 사용량을 줄였다. - 영향을 많이 받은 사용자 중 일부는 최대 **4GB의 저장 공간을 회복**했다. ## Android 채팅 및 콘텐츠 렌더링 최적화 - Android 채팅 렌더러를 개선해 기기별로 느린 프레임을 최대 **60% 감소**시켰다. - 채팅 목록의 메모리 사용량도 약 **12% 줄이는 효과**를 측정했다. - 이모지, GIF, 스티커가 포함된 Expression Picker를 최적화해 Android에서 렌더링 프레임 드롭 빈도를 최대 **50% 감소**시켰다. - 관련 테스트에서 메모리 사용량은 약 **7.5% 감소**했다. ## 폴더블 기기와 모바일 화면 대응 - 다양한 화면 비율과 형태를 가진 모바일 기기에 맞춰 앱 레이아웃 적응성을 강화했다. - 폴더블 기기에서 멀티태스킹과 화면 전환 경험을 크게 개선했다. - 작은 화면부터 접히는 대형 화면까지 Discord UI가 더 자연스럽게 동작하도록 지원 범위를 넓혔다. ## 서버 탐색과 전환 속도 향상 - 모바일 서버 목록에 **가상화(virtualization)** 를 적용했다. - 현재 화면에 보이는 서버만 로드해 대규모 서버 목록을 스크롤할 때 성능과 메모리 효율을 개선했다. - 모바일에서 서버 전환 속도를 기기와 네트워크 환경에 따라 **30% 이상 향상**시켰다. ## GIF와 미디어 공유 성능 개선 - 모바일 GIF Picker의 로딩 시간을 최대 **80% 단축**했다. - GIF 검색과 게시 과정이 더 빠르고 부드럽게 동작하도록 최적화했다. - 이미지 변환 과정에서 **ICC 색상 프로필 데이터**를 보존하도록 미디어 프록시를 개선했다. - WebP로 변환된 이미지에서도 원본에 가까운 색상과 품질을 유지할 수 있게 됐다. ## API 및 백엔드 인프라 개선 - Google Cloud의 **GCE C3 인스턴스**로 이전하고 nginx 계층을 제거하는 등 인프라를 변경했다. - 그 결과 p90 이상 구간의 API 지연 시간이 약 **25% 감소**했다. - API를 사용하는 Discord 앱과 Activities의 응답성이 전반적으로 향상됐다. ## 연말 프로모션 - 글의 마지막에는 Nitro 선물 기능을 홍보하며, 선물을 보낸 사용자에게 Avatar Decoration을 제공한다고 안내한다. - 연말 개선 사항은 새로운 대규모 기능보다는 충돌, 지연, 메모리, 저장 공간처럼 일상적인 사용성을 좌우하는 문제를 줄이는 데 초점이 맞춰져 있다. Discord의 2024년 업데이트는 눈에 띄는 기능 추가보다 성능과 안정성 개선에 집중한 사례다. 특히 모바일 사용자는 앱 업데이트를 유지하고, 저장 공간이 부족하거나 채팅·GIF 로딩이 느렸던 경우 개선 효과를 확인해볼 만하다.

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

APIAndroidiOS성능 최적화+4

figma·2025년 2월 5일원문

더블 클릭: 에이 (새 탭에서 열림)

에이전트 AI(Agentic AI)는 단순한 상호작용의 대상이 아닌 자율적으로 과업을 수행하는 도구로서, 사용자의 인지적 부하를 줄이고 웹의 상호운용성을 극대화하는 방향으로 진화하고 있습니다. 앞으로의 웹은 시각적 화려함보다는 기계가 읽기 쉬운 API 중심의 구조로 재편될 것이며, 이 과정에서 인간의 창의성을 보존하기 위한 새로운 설계 방식이 요구됩니다. 결국 미래 UX 디자인의 핵심은 무조건적인 편리함이 아니라, 사용자가 제어권을 유지할 수 있도록 적절한 '의도적 마찰'을 배치하는 기술에 달려 있습니다. **인터페이스에서 실행으로의 가치 전환** - AI는 더 이상 사용자가 말을 걸어야 하는 챗봇이 아니라, 보이지 않는 곳에서 작업을 완료하는 '구동 방식' 그 자체가 되어야 합니다. - 사용자는 자동차 보닛을 열어 엔진을 들여다보는 대신 목적지로 바로 이동하기를 원하듯, 에이전트 AI는 인터페이스의 복잡성을 숨기고 결과에 집중하게 합니다. - 이는 사용자가 메뉴를 클릭하고 정보를 찾는 데 소모하던 인지적 에너지를 창의적인 활동과 연결에 재투자할 수 있게 돕습니다. **웹 상호운용성과 협업하는 에이전트들** - 에이전트 AI는 사람처럼 여러 플랫폼과 웹사이트를 넘나들며 작업할 수 있어, 플랫폼 간의 장벽을 허무는 새로운 웹 상호운용성 시대를 엽니다. - 수많은 탭을 오가며 작업해야 했던 '토글 세금(Toggle Tax)'이 사라지고, 여러 전문 에이전트가 하나의 팀처럼 협력하여 복잡한 문제를 해결하는 구조로 변화합니다. - 이러한 변화는 사용자가 개별 사이트의 사용법을 익힐 필요 없이 하나의 요청으로 여러 서비스를 통합 이용할 수 있게 합니다. **기계 판독 가능성 중심의 웹 설계** - 웹사이트 최적화의 기준이 인간 사용자의 시각적 만족에서 AI 에이전트의 데이터 처리 효율성으로 이동할 것입니다. - 화려한 애니메이션이나 복잡한 레이아웃보다는 클린 API, 구조화된 기계 판독 가능(Machine-readable) 콘텐츠, 단순화된 내비게이션이 더 중요해집니다. - 이에 따라 웹사이트를 AI 에이전트에 최적화하고 유지관리하는 새로운 형태의 산업이 등장할 것으로 예측됩니다. **통제권 유지를 위한 '의도적인 마찰'의 재도입** - 모든 과정이 자동화되고 효율화될 경우, 인간의 창의성과 경험의 깊이가 훼손될 위험이 있습니다. - 전통적인 UX 디자인은 마찰을 없애는 데 집중했지만, AI 시대의 좋은 디자인은 사용자가 중요한 지점에서 검토하고 승인할 수 있도록 '의도적인 마찰'을 설계하는 것입니다. - 이를 통해 사용자는 AI가 작업을 대신 수행하더라도 자신이 여전히 최종 결정권을 쥐고 있다는 통제감을 유지하게 됩니다. 미래의 디자이너와 개발자는 단순히 '사용하기 쉬운' 사이트를 만드는 것을 넘어, AI 에이전트가 데이터를 원활하게 수집할 수 있는 기술적 토대를 마련하는 동시에 인간이 주도권을 잃지 않도록 돕는 정교한 개입 지점을 설계하는 데 역량을 집중해야 합니다.

APIAI 에이전트사용자 경험creative-coding+3

figma·2024년 4월 17일·3분 읽기큐레이션 요약

The Long and Short of

Figma의 뉴스레터 「Find your framework」는 디자인 시스템 구축과 확산에 도움이 되는 Framework 행사 발표와 관련 콘텐츠를 소개한다. 핵심 메시지는 디자인 시스템이 단순한 UI 산출물이 아니라, 조직 전체가 사용해야 가치를 발휘하는 제품이라는 점이다. 이를 위해 기능 개발뿐 아니라 내부 마케팅, 교육, 데이터 기반 adoption 전략이 필요하다. ## Framework 행사에서 발표한 기능 - Figma의 가상 디자인 시스템 행사인 **Framework**에서 제품 개발자와 디자인 시스템 담당자를 위한 기능을 공개했다. - 주요 발표 내용: - **Code Connect**: 디자인 시스템의 컴포넌트와 실제 코드 구현을 연결해 디자이너와 개발자 간 협업을 지원한다. - **Typography variables**: 글꼴, 크기, 행간 등 타이포그래피 속성을 변수로 관리할 수 있다. - **Gradient variables**: 그라디언트 관련 값을 변수화해 일관된 스타일 관리와 변경을 돕는다. - **Library Analytics API**: 조직 내 라이브러리 사용 현황을 분석해 디자인 시스템 adoption을 높이는 데 활용할 수 있다. - 행사에서 진행된 라운드테이블과 전문가 Q&A를 통해 디자인 시스템 운영 사례와 실무 관점도 공유했다. ## 디자인 시스템을 제품처럼 운영하기 - 디자인 시스템을 조직의 필수 도구로 만들려면 단순히 좋은 컴포넌트를 만드는 것만으로는 부족하다. - 제품처럼 다음 요소를 관리해야 한다. - 사용자의 요구와 문제 파악 - 명확한 가치 제안 - 지속적인 개선과 업데이트 - 사용 현황과 피드백 수집 - 사용자에게 변화와 이점을 알리는 커뮤니케이션 - 디자인 시스템의 성공은 완성도보다 **얼마나 많은 팀이 실제 업무에서 사용하는가**에 달려 있다. ## 내부 마케팅과 사용 확산 - 디자인 시스템은 일관성, 효율성, 확장성을 약속하지만, 실제 효과는 조직 전체의 사용이 전제되어야 나타난다. - 담당자는 “사용하라”고 지시하기보다 각 팀이 얻는 구체적인 이점을 설득해야 한다. - 디자인·개발 작업 시간 단축 - 중복 작업 감소 - 제품 간 시각적 일관성 향상 - 변경 사항을 여러 화면과 플랫폼에 빠르게 반영 - 내부 구성원을 대상으로 명확한 adoption 전략을 세우고, 교육·문서화·사례 공유를 통해 지속적인 참여를 유도해야 한다. ## 디자인 시스템 입문 - 아직 디자인 시스템을 시작하지 않은 팀을 위해 기본 개념과 구축 방법을 소개하는 입문 시리즈를 제공한다. - 디자인 시스템은 재사용 가능한 컴포넌트, 스타일, 규칙, 가이드라인을 모아 제품 제작 방식을 표준화하는 체계다. - 이를 활용하면: - 반복적인 디자인 결정을 줄일 수 있다. - 팀 간 협업 방식이 통일된다. - 제품이 성장해도 일관된 경험을 유지하기 쉽다. - 디자인과 개발 사이의 구현 차이를 줄일 수 있다. ## 성장과 확장을 지원한 Carvana 사례 - 온라인 중고차 거래 기업 **Carvana**는 급격한 고객 수요 증가와 사업 확장에 대응하기 위해 디자인 시스템을 활용했다. - 디자인 시스템과 변수를 사용해 제품 전반의 디자인 세부 사항을 일관되게 유지했다. - 특히 변수는 색상이나 기타 디자인 속성을 중앙에서 관리하고 변경할 수 있게 해, 여러 화면과 제품 영역에 일관된 수정 사항을 적용하는 데 도움을 줬다. - 이는 디자인 시스템이 시각적 통일성뿐 아니라 빠른 성장과 운영 효율성을 뒷받침하는 기반이 될 수 있음을 보여준다. 디자인 시스템을 도입할 때는 컴포넌트 제작에만 집중하기보다, 실제 사용자를 위한 제품으로 정의하는 것이 좋다. 명확한 사용 가치와 교육·홍보 전략을 마련하고, 사용 데이터를 분석하며 지속적으로 개선해야 조직 전체에서 정착시킬 수 있다.

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

APIFigma디자인 시스템디자인 토큰+2

figma·2022년 6월 27일·2분 읽기큐레이션 요약

Figma의 새로운 소식

Figma의 2022년 6월 업데이트는 디자인 협업과 확장성을 강화하는 데 초점을 맞췄다. 여러 사용자가 캔버스에서 함께 조작할 수 있는 위젯을 도입하고, 플러그인·위젯 탐색과 설치 과정을 간소화했다. 또한 개발자용 API 문서를 개선하고 Google과 협력해 학생들이 Chromebook에서 Figma와 FigJam을 사용할 수 있도록 접근성을 넓혔다. ## 여러 사람이 함께 사용하는 Figma 위젯 - 위젯은 Figma 캔버스에 배치되는 대화형 객체다. - 한 사용자가 단독으로 자동화하는 플러그인과 달리, 팀원 모두가 캔버스에서 동시에 상호작용할 수 있다. - 투표, 작업 관리, 타이머, 주석, 상태 표시 등 협업 중심의 기능을 구현할 수 있다. - 대표적인 위젯 사례: - **Asana**: Figma를 떠나지 않고 팀 작업을 논의하고 후속 작업을 Asana에 등록 - **Jira**: 디자인 화면에서 바로 개발 작업 생성 - **RAG Status**: 디자인 상태를 빨강·노랑·초록으로 표시 - **Navigate**: 내비게이션 버튼으로 이해관계자를 디자인 화면의 주요 영역으로 안내 ## 확장 기능을 더 쉽게 찾고 설치하기 - 기존에는 신규 사용자가 Figma의 플러그인과 Community 리소스를 찾기 어려웠다. - 업데이트 이후 Figma 툴바에서 플러그인과 위젯을 직접 검색하고 설치할 수 있게 됐다. - Figma Community에서 확장 기능을 시험해보는 방식도 개선됐다. - 결과적으로 사용자와 확장 기능 개발자 사이의 접근성이 높아지고, Figma 생태계 활용이 쉬워졌다. ## 새롭게 개편된 API 문서 - Figma 플랫폼 위에서 플러그인과 연동 도구를 개발하기 쉽도록 개발자 문서를 전면 개선했다. - 주요 변경 사항: - 새로운 탐색 구조 - 리소스 분류 및 구성 개선 - 복사할 수 있는 코드 블록 - 새로운 코드 예제와 단계별 가이드 - 문서 탐색 시간을 줄이고, 개발자가 실제 API 사용법을 빠르게 이해하도록 돕는 데 목적이 있다. ## Chromebook을 통한 교육 접근성 확대 - Figma는 Google for Education과 협력해 Chromebook에서 Figma와 FigJam을 사용할 수 있도록 했다. - Chromebook은 학생들이 널리 사용하는 기기이므로, 별도 고성능 장비 없이도 디자인과 협업 학습이 가능해진다. - 학교 구역은 Google Admin Console에서 Figma Organization 라이선스를 배포하고 관리할 수 있다. - 미국의 수천만 명 학생이 산업 표준 디자인 도구를 접할 수 있도록 무료 제공을 추진했으며, 학교는 베타 프로그램에 신청할 수 있게 됐다. Figma는 이번 업데이트를 통해 단순한 디자인 편집기를 넘어, 협업 위젯·개발자 생태계·교육 인프라가 결합된 확장 가능한 플랫폼으로 발전하려는 방향을 보여준다. 팀 작업에서는 위젯을 활용하고, 자동화나 연동이 필요하다면 개선된 API 문서와 Community 확장 기능을 함께 검토하는 것이 실용적이다.

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

APIFigmafigjamplugins+4

figma·2021년 11월 10일·3분 읽기큐레이션 요약

제작 비하인드: 개발

개빈 맥팔랜드는 사용자들이 겪는 불편에서 아이디어를 얻어 Figma 플러그인과 FigJam 위젯을 개발해 왔다. 대표작인 Table Creator와 테이블 위젯은 FigJam을 떠나지 않고 표 데이터를 생성·관리하도록 돕는다. 그는 단순한 API 실험에서 출발했지만, 실시간 협업과 대규모 데이터 처리 같은 문제로 관심을 확장하며 도구가 팀의 생산성과 협업을 높여야 한다고 강조한다. ## 사용자 문제에서 출발한 개발 - 개빈은 사용자 중심 디자인을 바탕으로 기업의 디지털 전환을 돕는 프리랜서 디자인 컨설턴트다. - 친구와 가족의 웹사이트를 제작하던 경험에서 시작해, 새로운 기술과 작업 방식을 꾸준히 시도해 왔다. - 트위터에서 “Figma에서 표를 더 쉽게 만들고 싶다”는 요청을 본 것이 플러그인 개발의 계기가 됐다. - Figma의 `Rectangle Creator` 예제를 수정해 표 생성 기능을 만들었고, 이를 **Table Creator**라는 첫 플러그인으로 출시했다. - 해당 플러그인은 수만 명이 사용할 정도로 확산됐다. ## FigJam용 테이블 위젯 - 첫 플러그인 개발 경험을 바탕으로 FigJam용 테이블 위젯을 제작했다. - 위젯의 주요 기능은 다음과 같다. - 행과 열 추가 - 데이터 가져오기 - 열 기준 정렬 - 표의 디자인과 구조 조정 - 별도의 도구로 이동하지 않고 FigJam 작업 공간에서 표 데이터를 바로 확인하고 활용할 수 있도록 설계됐다. - 디자인 작업, 협업 회의, 데이터 정리 등 표 형식의 정보를 사용하는 다양한 팀을 대상으로 한다. ## 예제 코드로 시작한 개발 방식 - 처음에는 FigJam 위젯의 `notepad` 예제를 수정하며 API 동작을 단계적으로 익혔다. - 간단한 변경을 반복하면서 위젯의 구조와 동작 방식을 파악했다. - 기존에 익숙하지 않았던 JSX 코드도 개발 과정에서 학습했다. - 기본적인 사용법을 이해한 뒤 행과 열을 표시하고, 여러 레이아웃과 디자인을 실험했다. - 완성된 설계에서 시작하기보다 작은 프로토타입을 빠르게 수정하는 방식으로 기능을 발전시켰다. ## 단순한 기능에서 협업 문제로 확장 - 처음에는 위젯 API를 익히기 위한 연습 프로젝트였지만, 팀 협업을 개선할 수 있는 도구로 발전했다. - 여러 사용자가 같은 표를 동시에 편집할 때 발생하는 문제에 관심을 갖게 됐다. - 특히 다음과 같은 과제가 중요하다고 보았다. - 다른 사용자가 같은 표를 편집 중임을 어떻게 표시할 것인가 - 실시간 멀티플레이어 상호작용을 어떻게 설계할 것인가 - 대량의 데이터를 다루면서도 인터페이스가 느려지지 않게 하려면 어떻게 해야 하는가 - 시각적 디자인과 기술적 구현을 함께 고민해야 한다는 점이 개발의 매력으로 작용했다. ## 영감과 개발자 커뮤니티 - 영감은 사람들이 디자인 과정에서 어떤 부분을 어렵게 느끼는지 관찰하는 데서 얻는다. - Friends of Figma Slack 그룹에서 사용자들의 요구와 작업상의 불편을 파악한다. - 플러그인 개발자 커뮤니티에도 적극적으로 참여하며 다른 제작자들과 아이디어와 개선 방법을 공유한다. - 사용자 피드백과 개발자 간 협업을 통해 실제 업무 문제를 해결하는 기능을 찾으려 한다. ## 생산성과 협업을 위한 도구 - 위젯을 사용하는 사람들이 더 생산적으로 일하고, 중요한 문제에 집중하기를 기대한다. - 개인의 작업 속도 향상뿐 아니라 팀원 간 협업을 더욱 긴밀하게 만드는 것이 목표다. - 개빈에게 좋은 도구란 기능을 추가하는 데 그치지 않고, 사람들이 일상적으로 겪는 문제를 함께 해결하도록 돕는 도구다. - 이후에도 Figma 플러그인인 **Node Decoder**를 만드는 등 새로운 개발 작업을 이어가고 있다. 사용자들이 반복적으로 겪는 불편을 관찰하고, 작은 예제에서 출발해 실제 협업 환경에 필요한 기능으로 확장한 점이 이 사례의 핵심이다. Figma·FigJam 플러그인을 개발할 때도 기능 자체보다 사용자의 작업 흐름, 실시간 협업, 데이터 규모와 성능을 함께 고려하는 것이 중요하다.

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

APIFigmafigjamreal-time-collaboration+3

figma·2021년 10월 27일·3분 읽기큐레이션 요약

빌드 비하인드:

Figma는 FigJam의 플러그인·위젯 생태계를 외부 개발자에게 개방하며 새로운 협업과 창작 가능성을 넓히고 있다. 개발자 Tru Narla는 위젯 제작 경험을 바탕으로 사운드보드 위젯을 만들었고, 작은 아이디어를 실제로 출시하는 과정에서 커뮤니티와 스트리밍의 도움을 얻었다. 그녀는 앞으로 인터랙티브 피아노와 멀티플레이어 게임 등으로 FigJam의 상호작용성을 확장하고자 한다. ## Soundboard 위젯의 목적 - Tru Narla는 Square의 소프트웨어 엔지니어로 일하며, 개인 프로젝트와 프로토타이핑에도 Figma를 자주 사용한다. - 그녀가 만든 **Soundboard**는 FigJam 보드에 재미있는 소리를 추가하는 위젯이다. - 향후 사용자가 직접 오디오를 녹음하거나 미리 준비된 소리를 선택하는 기능을 추가하고 싶어 한다. - 기존에 오디오 중심의 FigJam 위젯이 거의 없다는 점에서 아이디어를 얻었다. ## 문서와 커뮤니티를 통한 개발 - 공식 문서를 읽고 데모 프로젝트를 따라 하면서 개발을 시작했다. - 초기에는 시행착오를 반복하며 기능을 구현했다. - 위젯 API의 제약으로 오디오 녹음 기능을 넣을 수 없어 프로젝트 범위를 축소했다. - 비공개 Slack 채널에서 다른 위젯 개발자들과 코드를 공유하고 버그를 함께 해결한 것이 큰 도움이 됐다. - 위젯 개발은 예상보다 쉽고 재미있었으며, 제한적인 부분이 있어도 현재 제공되는 기능만으로 다양한 프로젝트를 만들 수 있다고 평가했다. ## 아이디어를 실행하고 출시한 계기 - Tru는 이전에도 사이드 프로젝트를 자주 시작했지만 완성하거나 출시하지 못한 경우가 많았다. - 비공개 위젯 개발자 커뮤니티에서 다른 사람들의 작업을 보며 동기를 얻었다. - 자신이 직접 사용할 만한 것을 만들고 싶다는 생각으로 사운드 관련 프로젝트를 시작했다. - 개발 과정을 Twitch에서 스트리밍한 것이 프로젝트를 끝까지 완성하는 데 도움이 됐다. - 아이디어가 떠오르면 바로 메모하고, Twitter와 일상생활에서 영감을 얻는다고 설명했다. ## FigJam에서 확장되는 상호작용 - 다음 프로젝트로 사용자가 건반을 클릭해 소리를 내거나, 키보드 단축키로 특정 음을 연주할 수 있는 **인터랙티브 피아노**를 개발 중이다. - 장기적으로는 구현 난도가 높은 멀티플레이어 게임도 만들고 싶어 한다. - FigJam의 플러그인과 위젯이 협업 보드에 재미와 상호작용을 더하는 방식에 주목한다. - 개발·시스템 설계를 위한 코드 임베드 기능에도 관심이 있으며, 코드 설명이나 튜토리얼을 FigJam에 작성하는 활용을 기대한다. - 실행 가능한 코드를 샌드박스에서 직접 보여주는 기능도 있으면 유용할 것이라고 제안한다. ## 개방형 플랫폼의 가능성 - FigJam이 외부 개발자에게 API를 공개하면서 개인 개발자도 새로운 도구를 제작하고 배포할 수 있게 됐다. - 다른 개발자들의 플러그인과 위젯이 다시 새로운 아이디어를 자극하는 선순환이 형성되고 있다. - Tru는 Figma와 FigJam에 아직 개발되지 않은 가능성이 많다는 점을 가장 기대되는 부분으로 꼽는다. - Figma Community를 통해 다양한 위젯과 플러그인을 공유하고 탐색할 수 있다. 작은 기능의 프로토타입이라도 직접 사용해 보고 싶은 문제에서 출발해 빠르게 만들고 공개하는 것이 좋은 출발점이다. 공식 문서뿐 아니라 개발자 커뮤니티와 공개 과정을 활용하면 기술적 제약을 줄이고 프로젝트를 완성할 가능성을 높일 수 있다.

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

APIFigmafigjamslack+4

figma·2021년 8월 23일·3분 읽기큐레이션 요약

FigJam에 도입된 오픈 플랫폼의

FigJam은 Figma의 개방형 플랫폼을 확장해 플러그인과 위젯을 누구나 만들 수 있도록 지원한다. 플러그인은 반복 작업과 데이터 처리를 자동화하고, 위젯은 투표·설문·게임처럼 여러 사용자가 동시에 상호작용하는 협업 경험을 제공한다. 두 API 모두 JavaScript·HTML 또는 React 지식을 바탕으로 쉽게 시작할 수 있도록 설계되었다. ## Figma 플러그인에서 FigJam으로 확장 - Figma는 약 2년 전부터 플러그인을 통해 외부 데이터 연동, 워크플로 자동화, 디자인 프로세스 개선을 지원했다. - 핵심 원칙은 “웹사이트를 만들 수 있다면 플러그인도 만들 수 있어야 한다”는 것이다. - 따라서 기본적인 JavaScript와 HTML 지식만으로도 플러그인 개발을 시작할 수 있도록 API의 진입장벽을 낮췄다. - FigJam에도 같은 개방형 플랫폼 원칙을 적용하되, 협업 중심의 사용 사례를 추가로 고려했다. ## 플러그인과 위젯의 역할 차이 - **플러그인** - 개인 또는 팀의 작업 흐름을 자동화한다. - CSV 데이터를 스티키 노트 격자로 변환하거나, 스티키 노트에 태그를 붙이는 작업 등을 처리할 수 있다. - 보드의 객체를 정리·분석하거나 외부 콘텐츠를 가져오는 데 적합하다. - **위젯** - FigJam 보드에 직접 배치해 여러 사용자가 함께 조작하는 인터랙티브 객체다. - 투표, 설문, 게임 등 협업형 기능을 구현할 수 있다. - 사용자가 보드에 드래그 앤 드롭해 사용할 수 있다. ## React 기반의 선언형 위젯 API - 위젯 API는 플러그인 API와 달리 선언적·함수형 방식으로 설계되었다. - `<Frame />`, `<Rectangle />`, `<Text />`, `<SVG />` 같은 컴포넌트로 위젯의 화면 구조를 정의한다. - 클릭 이벤트와 같은 사용자 상호작용에 임의의 코드를 연결할 수 있다. - FigJam의 기본 객체처럼 인라인 속성 메뉴도 제공할 수 있다. - React 컴포넌트와 유사한 구조를 사용하며, 컴포넌트 속성은 CSS의 레이아웃·스타일 속성과 비슷하다. - 예시 카운터 위젯은 다음 방식으로 동작한다. - `useSyncedState('count', 0)`으로 여러 사용자에게 동기화되는 상태를 만든다. - 사용자가 숫자를 클릭하면 `setCount(count + 1)`을 호출해 값을 증가시킨다. - `Frame`으로 자동 레이아웃과 패딩을 지정하고, `Text`로 현재 값을 표시한다. - `widget.register(SimpleCounter)`로 위젯을 등록한다. ## FigJam 플러그인의 주요 활용 분야 ### 보드 정리와 인사이트 도출 - 보드의 객체를 체계적으로 정리하고 분석할 수 있다. - 스티키 노트를 색상별로 정렬하거나 카테고리용 태그를 추가할 수 있다. - 스티키 노트의 내용을 분석해 워드 클라우드처럼 주제를 시각화할 수 있다. - 투표 수를 자동으로 집계하는 스탬프 카운터 플러그인도 활용 사례로 제시된다. - 텍스트를 입력하면 여러 개의 스티키 노트를 자동 생성하는 플러그인도 소개된다. ### 반복 작업 자동화 - 맞춤법 검사, 찾기 및 바꾸기 같은 수작업을 줄일 수 있다. - 동일한 스타일의 스티키 노트 100개를 한 번에 만드는 등 반복적인 작업을 자동화할 수 있다. - 사용자는 여러 단계를 직접 수행하는 대신 몇 번의 클릭만으로 작업을 완료할 수 있다. - Figma에서 사용되던 맞춤법 검사 플러그인을 FigJam으로 확장하는 사례가 언급된다. ### 콘텐츠 라이브러리 연동 - 외부 서비스나 라이브러리의 콘텐츠를 FigJam 보드로 가져올 수 있다. - 아이콘, 이모지, 회사 로고 등을 빠르게 삽입하는 플러그인을 만들 수 있다. - Icons8, Material Design, Iconify, Brandfetch 등 기존 Figma 콘텐츠 플러그인의 FigJam 확장이 사례로 제시된다. - 이를 통해 FigJam 사용자는 별도의 검색·복사 과정 없이 보드 안에서 필요한 시각 자료를 활용할 수 있다. ### 사용자 맞춤 설정 - 사용자가 원하는 색상, 폰트, 텍스트 스타일 등을 선택할 수 있는 기능도 플러그인 활용 분야로 제시된다. - FigJam은 기본적으로 폰트와 색상 체계를 단순하게 유지하지만, 사용자 요구에 따른 커스터마이징 수요가 존재한다. ## 실용적인 시사점 FigJam에서 자동화가 필요하면 플러그인을, 여러 사람이 동시에 조작하는 기능이 필요하면 위젯을 선택하는 것이 적합하다. 특히 React에 익숙한 개발자는 FigJam 레이어와 CSS와 유사한 컴포넌트 구조를 활용해 비교적 빠르게 인터랙티브 협업 도구를 만들 수 있다.

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

APIfigjamReactJavaScript+4

figma·2020년 6월 17일·4분 읽기큐레이션 요약

개발자와 더 가까워지는 방법 |

엔지니어를 제품 디자인 과정에 일찍 참여시키면 기술적 제약과 예외 상황을 빠르게 파악해 더 나은 해결책을 만들 수 있다. 디자이너는 완성된 시안을 전달하기보다 초기 아이디어 단계부터 엔지니어와 함께 가설을 검토하고 대안을 탐색해야 한다. 이를 위해 빠른 목업, 공동 브레인스토밍, 핵심 질문 정의가 효과적인 협업 방식으로 제시된다. ## 기술 지식이 아이디어를 구체화한다 - 디자인 초기의 아이디어 구상 단계에서 엔지니어와 긴밀히 협업하면 구현상의 제약을 빠르게 이해할 수 있다. - 엔지니어는 기술적 지식을 바탕으로 다음을 파악하는 데 도움을 준다. - 예상하지 못한 예외 상황 - API나 시스템 구조에서 발생할 수 있는 제약 - 구현 난이도와 선택지별 트레이드오프 - 초기부터 제약 조건을 알면 나중에 구현이 불가능한 시안을 수정하는 대신, 현실적이면서도 더 사려 깊은 해결책을 설계할 수 있다. - 완성된 결과물을 평가받는 방식이 아니라, 문제를 함께 정의하고 아이디어를 발전시키는 파트너로 엔지니어를 참여시켜야 한다. ## 지속적으로 협업할 엔지니어를 정한다 - Coda의 Packs Tables 기능을 개발할 때 전체 엔지니어링 팀과 별개로, 디자이너와 전 과정에서 협력할 엔지니어 파트너를 두었다. - Packs Tables는 Spotify, Google Calendar, Gmail 등 외부 앱의 데이터를 Coda 문서로 가져오는 기능이다. - 여러 앱의 API를 지원해야 하므로 특정 앱에만 맞는 해결책이 아니라 다양한 서비스에서 작동하는 구조를 고민해야 했다. - 한 명의 엔지니어와 지속적으로 협업하면 아이디어를 즉시 검토하고, 기술적 질문과 디자인 방향을 함께 조정할 수 있다. ## 빠르고 불완전한 ‘스트로맨 목업’을 만든다 - 스트로맨 목업은 완성된 디자인이 아니라 토론과 질문을 유도하기 위한 시각적 초안이다. - 다음 원칙을 따른다. - 빠르게 만든다. 초기 아이디어에는 오해나 잘못된 가정이 포함될 수 있으므로 많은 시간을 투자하지 않는다. - 해결책보다 질문을 더 많이 담는다. - 하나의 방향으로 좁히기보다 다양한 가능성을 보여준다. - 먼저 “모든 것이 쉽게 작동한다면 어떻게 보이고 동작할까?”를 가정해 초안을 만든다. - 엔지니어와 검토할 때 다음 질문을 적극적으로 던진다. - 가장 큰 오해나 잘못된 가정은 무엇인가? - 아직 고려하지 못한 요소는 무엇인가? - 흥미로운 방향은 무엇인가? - 구현하기 어려운 방향은 무엇이며, 그 어려움의 대가는 무엇인가? - 어려운 방향을 무조건 배제하는 것이 아니라, 난이도와 트레이드오프를 이해하는 것이 목적이다. ## 함께 아이디어를 시각화한다 - 초기 단계에는 자신의 목업만 검토하지 말고 엔지니어와 함께 새로운 아이디어를 브레인스토밍해야 한다. - 디자이너의 시각화 능력은 자신의 아이디어뿐 아니라 팀원의 질문과 가설을 구체화하는 데도 활용할 수 있다. - Coda에서는 컴포넌트가 준비된 와이어프레임 키트를 사용했으며, 새로운 요소가 아니라면 하이파이 형태로도 빠르게 탐색했다. - 원격 환경에서는 다음과 같은 방식으로도 협업할 수 있다. - 펜과 종이를 카메라로 공유하기 - iPad 화면 공유하기 - 온라인 화이트보드 사용하기 - Packs Tables 개발 과정에서는 화이트보드에 UI를 그리며 질문과 잠재적 문제를 구체화했다. - 이 단계의 목표는 최종 UI를 확정하는 것이 아니라, 아이디어와 문제에 대해 서로 같은 이해를 갖는 것이다. ## 핵심 질문을 먼저 정의한다 - 핵심 질문은 이후 발생하는 세부적인 의사결정의 기준이 되는 원칙이다. - 질문을 먼저 정리하면 다음과 같은 효과가 있다. - 문제를 올바른 순서로 해결할 수 있다. - 초기부터 특정 해결책을 두고 논쟁하는 일을 줄일 수 있다. - 설계 결정을 더 빠르게 내릴 수 있다. - 예를 들어 행사에 맞춤 냅킨을 사용할지 결정하려면 먼저 예산, 시간, 인력, 행사 분위기 같은 상위 조건을 정해야 한다. - Packs Tables에서는 브레인스토밍 중 핵심 질문을 만들고 이를 Coda 문서에 기록했다. - 이후 해당 기능에 참여하는 모든 엔지니어와 질문 및 가능한 선택지를 함께 검토해 공통된 판단 기준을 마련했다. 엔지니어를 마지막 검수 단계에만 참여시키지 말고, 초기 가설과 아이디어를 함께 탐색하는 파트너로 초대하는 것이 좋다. 빠른 목업을 만들고, 화이트보드로 대안을 시각화하며, 핵심 질문을 문서화하면 기술적 제약을 창의성을 제한하는 요소가 아니라 더 나은 디자인을 만드는 정보로 활용할 수 있다.

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

API프로덕트 디자인collaborationwireframing+2

figma·2019년 4월 30일·3분 읽기큐레이션 요약

Figma 워크플로우

Figma는 디자인 작업의 맥락과 팀별 상황에 따라 해답이 달라지는 문제를 사용자 간 대화로 해결할 수 있다고 보고, 온라인 포럼을 새롭게 개편했다. 개편의 핵심은 주제별 채널 구조, 명확한 커뮤니티 가이드라인, AMA와 라이브스트림 같은 참여형 콘텐츠다. 버그 신고와 기능 요청은 포럼 대신 지원 플랫폼으로 일원화해 더 신속하고 체계적으로 처리하도록 했다. ## 사용자 간 지식 공유를 강화하는 포럼 - 디자인 시스템, 개발자 핸드오프, 툴체인 구성처럼 정답이 하나로 정해지지 않은 문제는 일반적인 지원 문서만으로 해결하기 어렵다. - 사용자는 다른 디자이너의 실제 경험과 상황을 참고해 자신의 워크플로를 개선할 수 있다. - 포럼에서는 한 질문에 다양한 관점이 모이고, 그 논의가 질문자뿐 아니라 커뮤니티 전체에 유용한 지식으로 축적된다. - Figma는 오프라인 모임이나 트위터에서 자연스럽게 이뤄지던 교류를 온라인 포럼에서 더 쉽게 이어가려 했다. ## 실무 주제 중심의 새 채널 구조 - 기존 채널 일부를 보관하거나 이름을 변경하고, 실무 영역별로 대화를 집중할 수 있도록 새 채널을 추가했다. - **Design Systems** - 디자인 시스템의 모범 사례를 논의한다. - 팀별 Figma 라이브러리 구성 방식과 운영 경험을 공유한다. - 관련 자료와 리소스를 교환한다. - **Prototyping** - 프로토타이핑 기법과 활용 사례를 다룬다. - **API and Extensions** - Figma API와 확장 기능에 관한 질문과 정보를 공유한다. - **Workflow and Process** - 디자인 업무 프로세스와 협업 방식에 대해 논의한다. - **Open Design** - 진행 중인 작업물을 공개하고 피드백을 받을 수 있다. - 프로젝트에 참여할 다른 디자이너를 찾는 용도로도 활용할 수 있다. - 브라우저 기반 협업 도구라는 Figma의 특성을 커뮤니티 활동에 연결한 채널이다. - **Start Here** - 새 채널 구조, 커뮤니티 이용 가이드라인, 행동 강령 등 포럼 이용에 필요한 정보를 제공한다. ## 버그 신고와 기능 요청의 지원 플랫폼 이관 - 버그 신고와 기능 요청은 포럼에서 제거하고 Figma의 공식 지원 플랫폼으로 접수 경로를 통합했다. - 지원 채널을 이용하면 담당 팀이 사용자와 1:1로 문제를 진단할 수 있다. - 공개 포럼에서 공유하기 어려운 파일이나 계정 정보도 지원 과정에서 전달할 수 있다. - 지원팀은 접수된 버그와 요청을 적절한 담당자에게 전달하고 우선순위를 관리한다. - 지원팀은 제품팀 및 엔지니어링팀과 매주 논의하며, 사용자 피드백이 제품 개선 과정에 반영되도록 했다. ## 커뮤니티 참여형 콘텐츠 - 포럼을 단순한 질문·답변 공간이 아니라 지속적인 커뮤니티 활동의 장으로 확장하려 했다. - AMA(Ask Me Anything)를 통해 Figma 관계자나 전문가에게 직접 질문할 수 있다. - 라이브스트림 등 실시간 콘텐츠를 통해 사용자와의 소통을 강화한다. - 공식 안내와 사용자 간 자율적인 경험 공유를 함께 제공하는 구조를 지향한다. 실제로 이용할 때는 워크플로·디자인 시스템·프로토타이핑 관련 질문은 주제별 포럼에서 다른 사용자의 경험을 참고하고, 계정 정보나 파일이 필요한 버그 신고 및 기능 요청은 공식 지원 플랫폼을 이용하는 것이 가장 효율적이다.

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

APIFigma디자인 시스템프로토타이핑+1

figma·2018년 10월 2일·2분 읽기큐레이션 요약

API 챌린지 과정에서의

Figma는 Sketch 내보내기 API 챌린지가 디자이너에게 무보수 작업을 요구하는 ‘스펙 워크’로 받아들여질 수 있음을 인정하고 사과했다. 개방적인 디자인 생태계를 만들고자 했던 취지는 타당했지만, 창작 노동의 가치를 충분히 고려하지 못한 것이 문제였다. Figma는 챌린지를 중단하고 대안을 검토했으며, 2018년 11월에는 해당 챌린지를 어떤 형태로도 진행하지 않기로 결정했다. ## API 챌린지의 목적 - Figma는 **Figma 파일을 Sketch 형식으로 내보내는 기능**을 만들기 위한 API 챌린지를 시작했다. - 목표는 다음과 같았다. - Figma를 중심으로 한 개방적인 디자인 도구 생태계 조성 - Figma 데이터를 외부로 가져갈 수 있는 다양한 방법 지원 - 관련 기능이나 도구 개발에 필요한 자금 지원 - 회사는 기술 생태계를 확장하려는 의도에서 이 프로그램을 기획했다. ## ‘스펙 워크’로 비친 문제 - 디자이너 커뮤니티는 챌린지가 실제 결과물을 요구하면서도 참가자가 보상을 받지 못할 수 있다는 점을 지적했다. - 이러한 구조는 기업이 업무에 활용할 수 있는 창작물을 여러 참가자에게 무상으로 제작하게 하는 **스펙 워크(spec work)**로 해석될 수 있었다. - Figma는 창작자가 정당한 대가를 받아야 한다고 믿어왔지만, 개방형 생태계에 대한 열정 때문에 이 원칙을 이번 기획에 충분히 적용하지 못했다고 인정했다. - 특히 숙련된 창작 노동자가 착취되어 온 업계의 역사와 커뮤니티의 우려를 간과한 점이 핵심적인 실수였다. ## Figma의 대응과 사과 - Figma는 커뮤니티의 비판을 접한 뒤 해당 챌린지를 즉시 중단했다. - 기존 방식으로는 진행하지 않고, 참가자에게 무보수 작업을 요구하지 않는 새로운 구조를 검토하겠다고 밝혔다. - 당시에는 1~2주 안에 챌린지를 재설계해 다시 시작할 가능성을 언급했다. - 커뮤니티의 건설적인 피드백에 감사를 표하고, 디자인 생태계를 더 개방적이고 공정하게 만들겠다고 약속했다. ## 최종 결정 - 2018년 11월 19일 업데이트에서 Figma는 커뮤니티의 우려를 고려해 **이 챌린지를 어떤 형태로도 당분간 진행하지 않기로 결정**했다. - 따라서 단순히 운영 방식을 수정하는 수준을 넘어, 해당 프로젝트 자체를 보류하는 결론에 도달했다. ## 실용적인 시사점 - 오픈 생태계나 커뮤니티 프로그램을 설계할 때도 참여자의 노동이 기업 가치로 전환되는지 먼저 검토해야 한다. - 결과물을 요구하는 공모전이나 API 챌린지는 보상, 사용권, 선정 기준을 명확히 제시해야 한다. - 좋은 기술적 목표라도 창작자의 권리와 보상 구조를 고려하지 않으면 커뮤니티의 신뢰를 잃을 수 있다.

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

APIFigmadesign-toolssketch+2

figma·2018년 6월 20일·3분 읽기큐레이션 요약

피그마 3.0 (!)

Figma 3.0은 데스크톱 중심의 파편화된 디자인 작업을 웹 기반 협업 환경으로 통합하려는 업데이트다. 프로토타이핑, 디자인 시스템 관리, 대규모 조직 운영 기능을 강화해 InVision 같은 별도 도구와 반복적인 파일 동기화·내보내기 작업을 줄이는 것이 핵심이다. 디자인과 프로토타입, 댓글, 개발자 전달을 하나의 최신 상태로 연결해 팀 전체의 작업 효율을 높이려 한다. ## 웹 기반 디자인 워크플로 통합 - 데스크톱 기반 작업에서는 다음과 같은 문제가 발생한다. - 어떤 프로토타입에 이해관계자의 댓글이 있는지 확인하기 어렵다. - 스타일 가이드가 최신 상태인지 보장하기 어렵다. - 팀원들이 같은 디자인 버전을 보고 있는지 관리해야 한다. - Figma는 디자인 파일과 프로토타입, 댓글, 공유 기능을 웹에서 연결해 별도 앱 간 전환을 줄이려 한다. - 결과적으로 중복 도구와 구독 비용을 줄이고, 팀의 작업 흐름을 Figma 중심으로 통합하는 것이 목표다. ## 프로토타이핑 기능 강화 Figma 3.0은 디자인 파일에서 바로 동작하는 프로토타입 기능을 강화했다. - **디바이스 프레임** - iPhone, Android, Apple Watch 등 다양한 기기 프레임을 적용할 수 있다. - 디자인이 실제 기기에서 어느 정도 크기로 보이는지 팀원들이 쉽게 이해할 수 있다. - **고정 오브젝트** - 상태 표시줄, 헤더, 푸터, 버튼 등을 화면의 위·아래·측면에 고정할 수 있다. - 제약 조건과 함께 사용해 스크롤 중에도 특정 요소가 유지되도록 만들 수 있다. - 배경 블러와 블렌딩 모드를 적용하면 고정 요소의 시각적 완성도를 높일 수 있다. - **스크롤 가능한 영역** - 프레임 내부의 개별 도형이나 영역에 스크롤 동작을 설정할 수 있다. - 부모 프레임 자체가 스크롤되는 중첩 구조도 지원한다. - 이미지 캐러셀, 세로 목록, 가로·세로 어느 방향으로든 스크롤하는 화면을 구현할 수 있다. - **화면 전환** - dissolve, slide, push 등의 전환 효과를 제공한다. - 네이티브 모바일 앱과 유사한 움직임을 구현해 프로토타입의 완성도를 높인다. ## 디자인과 프로토타입의 실시간 연결 - 디자인의 색상이나 글꼴 크기를 수정하면 프로토타입에도 실시간으로 반영된다. - 디자인 파일과 댓글이 분리되지 않아, 피드백을 확인하기 위해 다른 앱이나 탭으로 이동할 필요가 줄어든다. - 모바일 브라우저에서 프로토타입을 열고 휴대폰을 리모컨처럼 사용해 발표할 수 있다. - 프로토타입이 디자인과 직접 연결되어 있어 화면을 별도로 내보내거나 버전을 동기화하는 관리 작업이 필요 없다. - 다만 Figma는 모든 프로토타이핑 요구를 대체한다고 단정하지 않고, 다른 도구와의 연동을 위해 API 개발도 함께 추진한다. ## Figma Styles와 디자인 시스템 - Figma Styles를 모든 사용자에게 공개했다. - 텍스트와 레이어 속성을 스타일로 정의해 회사 전체에서 일관된 디자인 요소를 관리할 수 있다. - 새로운 Team Library 기능과 결합하면 색상, 글꼴, 효과 등 디자인 시스템의 구성 요소를 팀 단위로 공유하고 유지할 수 있다. - 스타일 기능은 비공개 베타와 사용자 조사를 거쳐 개발되었으며, 여러 팀이 동일한 디자인 기준을 적용하는 것을 목표로 한다. ## Organization 요금제 - 대규모 조직을 위한 새로운 Organization 등급을 미리 공개했다. - 조직 규모가 커질수록 필요한 디자인 관리와 운영 체계를 확장하는 데 초점을 둔다. - Figma는 이를 Styles, Team Library, 개발자 전달, 댓글, 공유 컴포넌트와 함께 기업용 디자인 운영 기반으로 제시한다. ## 실용적인 결론 Figma 3.0은 디자인 파일을 단순히 편집하는 도구에서 프로토타이핑과 디자인 시스템, 협업을 함께 처리하는 플랫폼으로 확장한 업데이트다. 팀이 여러 버전의 파일과 별도 프로토타이핑 도구를 관리하고 있다면, Figma의 실시간 연결·공유·스타일 라이브러리를 활용해 작업 단계를 줄이는 것을 검토할 만하다.

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

APIFigma디자인 시스템프로토타이핑+3

figma·2017년 9월 27일·2분 읽기큐레이션 요약

Figma의 라이브

Figma는 웹 기반 디자인 파일과 프로토타입을 최신 상태로 유지한 채 다른 웹사이트와 협업 도구에 삽입할 수 있는 **Live Embed Kit**을 공개했다. 사용자는 iframe 코드만으로 Figma 콘텐츠를 임베드할 수 있으며, 원본 파일이 변경되면 별도 재업로드 없이 임베드된 화면도 자동으로 동기화된다. 이를 통해 팀이 이메일, 메신저, 파일 공유 서비스에 흩어진 디자인을 찾는 번거로움을 줄이고 더 빠르게 협업할 수 있다는 것이 글의 핵심 주장이다. ## iframe 기반의 간단한 임베드 - Figma 파일 우측 상단의 **Share** 메뉴에서 **Public embed**를 선택하면 iframe 코드를 얻을 수 있다. - 개발자는 이 iframe을 자신의 웹사이트나 서비스에 삽입해 Figma 디자인 또는 프로토타입을 표시할 수 있다. - 별도의 복잡한 렌더링 시스템을 구축하지 않아도 웹페이지에 Figma 콘텐츠를 통합할 수 있다. ## 항상 최신 상태로 유지되는 디자인 - 임베드된 콘텐츠는 Figma 원본 파일과 연결되어 실시간으로 동기화된다. - 디자이너가 여백, 아이콘, 레이아웃 등을 수정하면 임베드 화면에도 변경 사항이 반영된다. - 디자인을 이미지로 다시 내보내거나, 수정된 파일을 다시 업로드할 필요가 없다. - Figma가 웹에서 실행되는 디자인 도구라는 점이 이러한 지속적인 동기화의 기반이다. ## 외부 서비스와의 통합 - Live Embed Kit은 개인 웹사이트뿐 아니라 제3자 서비스가 Figma 임베드 기능을 제공하도록 설계됐다. - 글에서는 Trello, JIRA, Dropbox Paper와 같은 도구에서의 활용 사례를 언급한다. - 서비스 개발자는 자체 제품 안에서 사용자가 최신 Figma 파일을 공유하고 확인할 수 있도록 통합할 수 있다. ## 팀 협업에서의 활용 사례 - **사내 위키**: 프로젝트나 기능 문서에 최신 디자인을 삽입해 문서와 시안을 함께 관리할 수 있다. - **팀 메시징 앱**: 그룹 채팅에서 디자인 파일의 최신 버전을 공유할 수 있다. - **블로그**: 프로젝트 소개 글에 live Figma 파일을 넣어 독자가 항상 최신 디자인을 보도록 할 수 있다. - 이러한 방식은 이메일 기록, Slack 대화, 파일 공유 폴더를 뒤져 최신 디자인을 찾는 문제를 줄인다. ## Figma 플랫폼 확장의 출발점 - Figma는 Live Embed Kit을 웹 기반 플랫폼 전략의 시작으로 소개한다. - 향후 Figma 파일에서 디자인 외의 다양한 정보를 가져와 새로운 업무 흐름에 활용할 수 있는 **Figma API**를 제공할 계획도 밝혔다. - 개발자와 파트너사가 Figma 데이터를 다른 협업 도구와 연결하는 생태계를 구축하는 방향이다. 실무적으로는 사내 문서, 제품 블로그, 협업 툴에 정적인 이미지 대신 Live Embed를 사용하면 최신성 유지와 커뮤니케이션 비용을 줄일 수 있다. 다만 공개 임베드 방식인 만큼, 삽입할 파일의 접근 권한과 공개 범위를 설정할 때 보안 및 기밀성도 함께 검토해야 한다.

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

APIFigmareal-time-collaboration웹 개발+3