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

워크플로우 랩: Figma MCP로 캔버스 확장하기 | 피그마 블로그

빠르게 코드를 작성하는 팀에서는 구현 과정에서 새로운 상태와 예외가 생기며 디자인과 실제 제품 사이의 간극이 커질 수 있다. 이 글은 Figma MCP를 사용해 코드에만 존재하던 제품 상태를 Figma 캔버스로 가져오고, 디자이너가 이를 직접 검토·수정하는 워크플로를 소개한다. 결과적으로 캔버스가 초기 화면을 넘어 실제 제품 전체의 상태와 구현 결과를 다루는 공간으로 확장된다. ## 빠른 개발이 만드는 디자인 사각지대 - Astra라는 가상의 AI 영상 제작 플랫폼은 에이전트 코딩 도구를 활용해 매주 기능을 출시한다. - 초기 영상 내보내기 플로우는 다음 네 단계로 시작한다. - 시퀀스 선택 - 포맷 선택 - 설정 확인 - 영상 내보내기 - 실제 코드와 데이터에 연결되면서 다음과 같은 상태가 추가된다. - 인코딩 오류 - 렌더링 진행 중 상태 - 선택 항목이 없는 상태 - 지원하지 않는 포맷 - 이러한 상태는 디자이너가 초기 설계에서 누락한 것이 아니라, 기능이 실제 구현되는 과정에서 새롭게 드러난 디자인 결정 사항이다. - 캔버스가 초기 플로우만 담고 있으면 디자이너 역시 제품의 일부만 보고 작업하게 된다. ## Figma MCP로 캔버스 확장 - Figma MCP를 통해 에이전트가 코드를 읽고 Figma 캔버스에 결과를 작성할 수 있다. - 에이전트는 구현된 내보내기 플로우를 분석해 개발자가 처리한 모든 상태를 식별한다. - 각 상태를 Figma의 편집 가능한 프레임으로 생성하고, Astra의 디자인 시스템 컴포넌트를 적용한다. - 초기에는 4개였던 프레임이 구현된 전체 상태를 반영하며 14개로 늘어난다. - 사용된 주요 도구는 다음과 같다. - Figma Design - Dev Mode - Figma MCP server - `use_figma` - `generate_figma_design` - `/sync-figma-token` 스킬 ## 코드에 드러난 상태를 디자인으로 발전시키기 - 인코딩 오류 화면에는 단순한 빨간색 오류 메시지만 있었지만, 디자이너가 다음 내용을 추가한다. - 오류 원인 - 사용자가 시도할 수 있는 해결 방법 - 이전 단계로 돌아가는 방법 - 렌더링 중 화면에는 스피너만 있었지만, 디자이너가 진행률과 예상 소요 시간을 추가한다. - 선택 항목이 없는 화면은 비어 있었지만, 기능 사용을 유도할 수 있는 안내 문구와 개성을 부여한다. - 이 방식은 작업 티켓이나 요구사항 문서 중심의 피드백보다, 코드와 디자인이 캔버스에서 직접 대화하는 형태에 가깝다. - 구현 후 발견된 예외 상태를 별도의 긴 탐색 세션을 거치지 않고 바로 디자인 대상으로 전환할 수 있다. ## 디자인과 구현 결과 비교 - Figma 캔버스에서 원본 디자인과 코드로 구현된 화면을 나란히 비교할 수 있다. - 시각적 차이를 찾아내는 비교 결과에는 심각도별 불일치가 표시된다. - 예시로 다음과 같은 차이가 발견된다. - 모달 제목 크기 차이 - 구현본에만 추가된 “Post share link” 버튼 - 설정 패널의 배경 또는 표면 스타일 제거 - 설정 헤더의 시각적 우선순위 하락 - 이를 통해 디자인 검토가 “의도한 화면이 구현되었는가”뿐 아니라, 실제 구현 과정에서 추가·변경된 요소까지 포함하도록 확장된다. ## 실용적인 결론 Figma MCP는 코드를 디자인으로 자동 변환하는 도구라기보다, 구현 중 발생한 모든 제품 상태를 디자인 의사결정의 영역으로 되돌리는 연결 장치다. 빠르게 개발하는 팀이라면 에이전트로 코드의 상태를 캔버스에 동기화한 뒤, 디자이너가 오류·로딩·빈 상태·시각적 불일치를 직접 검토하는 절차를 구축하는 것이 유용하다.

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

디자인 시스템AI 에이전트design-to-codeclaude-code+1

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

업무용 에이전트 도구 설계 방법 | 피그마 블로그

Gemini Enterprise는 사용자가 AI를 관리하는 대신 업무 목표에 집중하도록 설계된 에이전틱 업무 도구다. 복잡한 멀티 에이전트 작업을 단순하게 보이게 하면서도, 사용자가 언제든 개입하고 결과를 검토할 수 있도록 투명성과 책임성을 강화했다. 개인용 챗봇을 넘어 공유 프로젝트와 AI 대시보드를 통해 팀의 지식과 업무 흐름을 통합하는 것을 목표로 한다. ## 소비자용 Gemini와 기업용 경험의 연결 - 브랜드 일관성을 위해 반짝이 아이콘, 그라디언트, 둥근 형태, 의도적인 모션 등 공통된 시각 언어를 사용한다. - 프롬프트 입력창은 소비자용 Gemini와 유사하게 유지하되, 기업 환경에서는 외부 서비스 연결 기능을 더 강조한다. - Google Workspace, Jira, Notion 등 업무 도구와 연결해 AI가 업무에 필요한 맥락을 충분히 확보하도록 한다. - 기업용 AI는 단일 질문에 답하는 도구가 아니라 여러 도구와 데이터 소스를 조율하는 오케스트레이션 플랫폼으로 확장된다. ## 대화형 인터페이스를 넘어선 AI Inbox - 복잡한 업무에서는 단순한 채팅 기록만으로 여러 에이전트의 진행 상황을 파악하기 어렵다. - AI Inbox는 에이전트가 수행 중인 작업, 완료한 작업, 사용자의 개입이 필요한 작업을 한눈에 보여주는 실시간 대시보드다. - 예를 들어 다음 날 마감인 시장 분석이 완료되어 검토 대기 중인지 즉시 확인할 수 있다. - 시각적 워크플로는 질문과 답변이 반복되는 채팅보다 팀 체크인에 가까운 방식으로 장기 실행 작업을 관리하게 한다. ## 개인용 챗봇에서 공유 프로젝트로 - Gemini Enterprise는 개인별 채팅 스레드 대신 지속적으로 유지되는 공유 프로젝트 공간을 제공한다. - AI는 프로젝트의 또 다른 팀원처럼 다음과 같은 작업을 수행한다. - 업무 실행 - 논의 내용 요약 - 프로젝트 파일 검색 - 문서 작성 및 편집 - 모든 팀원이 같은 공간에서 AI의 요청과 결과를 확인할 수 있다. - 각 요청을 어느 팀원이 보냈는지 표시해 AI의 행동 맥락과 책임 소재를 명확히 한다. ## 팀 사일로를 줄이는 단일 정보 기반 - 한 팀원이 기술 명세서를 업로드하면 다른 팀원이 파일을 직접 찾지 않고도 AI를 통해 내용을 확인할 수 있다. - 프로젝트 안에 대화, 파일, AI 결과물이 함께 축적되어 팀 내 지식 격차를 줄인다. - AI가 부서별로 흩어진 정보를 연결해 조직의 단일 정보 원천 역할을 하도록 설계했다. - 이 때문에 AI는 개인 생산성 도구를 넘어 팀 전체의 지능을 증폭하는 도구로 발전한다. ## 협업 방식에 맞춘 다양한 작업 모드 - 팀원들은 공유 프로젝트에서 AI와 함께 그룹 채팅을 진행할 수 있다. - Canvas Mode에서는 AI가 작성한 문서를 생성하고 직접 수정할 수 있다. - AI의 결과물을 일회성 답변으로 소비하지 않고, 팀이 검토·편집·재사용하는 협업 산출물로 다룬다. - AI가 프로젝트 공간에 계속 존재하기 때문에 기존 대화의 맥락과 업무 진행 상황을 유지할 수 있다. ## 신뢰와 사용자 개입의 균형 - 사용자가 AI의 내부 동작을 계속 관리하지 않아도 목표 달성에 집중할 수 있도록 경험을 단순화한다. - 동시에 민감한 정보와 사업상 중요한 의사결정이 다뤄지는 만큼, 사용자가 결과를 검토하고 개입할 수 있어야 한다. - 진행 상태, 완료 여부, 검토 필요 여부를 명확히 보여주는 것이 신뢰 형성의 핵심이다. - 기업용 에이전트는 자동화 수준뿐 아니라 투명성, 추적 가능성, 책임성을 함께 제공해야 한다. 실무적으로는 에이전트를 단순한 챗봇으로 도입하기보다, 업무 도구 연결·장기 작업 상태·팀 공유 공간·사용자 승인 절차를 함께 설계하는 것이 중요하다. ખાસ히 중요한 업무일수록 AI의 자율성보다 진행 상황과 개입 지점을 명확히 보여주는 UX가 우선되어야 한다.

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

AIjiramulti-agent-systemsagentic-workflows+4

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

이제 FigJam은 코딩 에이전트의 화이트보드이기도 합니다 | Figma 블로그

FigJam이 코딩 에이전트의 작업을 시각화하고 팀과 함께 검토하는 협업 공간으로 확장된다. Figma는 `figma-use-figjam`, 확장된 `generate_diagram`, `get_figjam` 등의 MCP 도구와 스킬을 통해 에이전트가 코드베이스와 문서를 분석하고, FigJam에 아키텍처를 작성하며, 팀 피드백을 다시 구현 단계로 전달하도록 한다. 이를 통해 빠른 에이전트 개발로 발생하는 숨은 복잡성을 줄이고, 코딩 전에 설계를 검토할 수 있다는 것이 글의 결론이다. ## 에이전트 개발 속도와 코드 복잡성의 간극 - 에이전트 덕분에 과거 몇 분기 걸리던 기능을 몇 주 만에 구현할 수 있다. - 그러나 사람이 충분히 검토하지 않은 에이전트 생성 PR이 쌓이면 코드베이스에 다음 문제가 생긴다. - 숨은 복잡성 증가 - 기존 구조와 새로운 구현 간의 불일치 - 팀원이 전체 시스템 변화를 파악하기 어려움 - 글의 저자는 이러한 문제를 한눈에 파악하고 논의하기 위해 텍스트 문서보다 시각적인 시스템 표현이 필요하다고 설명한다. ## FigJam과 MCP 도구의 결합 - 기존 `use_figma` MCP 도구는 AI 에이전트가 실제 Figma 컴포넌트를 사용해 디자인을 생성하거나 수정하도록 한다. - `create_new_file`은 에이전트가 새 Figma 파일 안에 디자인을 생성할 수 있게 한다. - 새롭게 확장된 `generate_diagram`은 단순한 다이어그램을 넘어 다음과 같은 복잡한 시각 자료를 생성한다. - 시스템 아키텍처 다이어그램 - ERD(Entity Relationship Diagram) - 서비스 및 데이터 관계 구조 - `figma-use-figjam` MCP 스킬은 에이전트가 FigJam 보드를 직접 읽고 쓸 수 있도록 한다. - `generate-project-plan` 같은 워크플로 스킬은 문서, 코드베이스, 대화 내용을 시각적인 프로젝트 계획으로 변환한다. ## 1단계: 조사와 계획을 시각화 - 먼저 코딩 에이전트가 새 기능에 필요한 맥락을 수집한다. - 관련 MCP 서버 문서 - 코드베이스 구조 - 기존 구현 패턴 - 영향을 받는 서비스와 파일 - 에이전트는 가능한 구현 방안과 트레이드오프를 조사한다. - 이후 작업을 여러 개의 stacked PR로 나누고 테스트 전략을 세운다. - 기존에는 이 결과가 긴 Markdown 문서로 남았지만, 이제 FigJam 보드로 변환할 수 있다. - 보드에는 다음 자료를 함께 배치할 수 있다. - `generate_diagram`으로 생성한 아키텍처 및 ER 다이어그램 - `figma-use-figjam`으로 작성한 노트 - 코드 블록 - 주석과 설계 근거 - 텍스트 중심의 계획보다 팀원이 구조와 대안을 빠르게 비교하고, 적절한 아키텍처를 논의하기 쉬워진다. ## 2단계: 코드 작성 전 협업 - 생성된 FigJam 보드를 팀에 공유해 구현 전에 기술적 피드백을 받는다. - 팀원은 다이어그램 위에서 질문과 결정을 직접 남길 수 있다. - 특정 도구가 디자인 파일 외에 여러 파일 형식을 지원해야 하는가? - `folderId`를 입력받을 것인가? - 새 파일은 사용자의 Drafts 폴더에 생성할 것인가? - 원격 팀도 회의실에서 화이트보드를 사용하는 것처럼 기술 맥락을 공유하고 논의할 수 있다. - 에이전트가 만든 다이어그램도 사람이 검토하는 협업 산출물로 활용된다. ## 3단계: FigJam의 결정을 구현으로 전달 - 리뷰가 끝나면 에이전트가 보드의 결과를 다시 읽어 구현 계획을 갱신한다. - `get_figjam` 도구를 사용하면 다음 정보를 코딩 환경으로 가져올 수 있다. - 아키텍처 다이어그램 - 팀의 결정 사항 - 보드의 주석과 논의 내용 - 과거처럼 다이어그램을 캡처하고 댓글을 수동으로 요약해 에이전트에게 설명할 필요가 줄어든다. - 최종 PR에는 FigJam 보드 링크를 함께 연결해 설계 맥락을 보존할 수 있다. - 아키텍처가 코드 작성 전에 이미 검토되므로 PR 리뷰와 병합이 더 수월해진다. 에이전트에게 구현을 맡기더라도 계획·아키텍처·팀 의사결정은 사람이 먼저 검토하는 흐름을 만드는 것이 중요하다. FigJam과 MCP 도구를 함께 사용하면 에이전트의 빠른 실행력과 팀의 설계 검토를 연결해, 코드 품질과 협업 가시성을 높일 수 있다.

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

FigmaAI 에이전트figjam모델 컨텍스트 프로토콜+3

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

AI 리더들이 디자인 플레이북을 활용하는 방법 | Figma 블로그

AI 전환을 성공시키는 리더는 단순히 새로운 도구를 도입하는 기술자가 아니라, 디자인 원칙에 따라 일하는 방식을 재설계하는 사람이다. 이들은 AI를 직접 사용해 특성을 익히고, 조직 구성원의 실제 업무 흐름을 관찰하며, 아이디어를 프로토타입으로 구체화한다. 중요한 것은 도구 도입 자체가 아니라 팀의 행동과 시스템을 실질적으로 변화시키는 것이다. ## AI 리더의 역할과 ‘보여주기식 진전’의 함정 - AI 혁신·가속화 역할은 다음과 같은 일을 담당한다. - 업무 흐름을 빠르게 개선 - AI 기반 기능 출시 촉진 - 조직 전반의 도구 도입 지원 - 제품, 고객 지원, 내부 업무에 AI를 적용하는 방향 조율 - AI 도입이 확산되면서 워크플로와 시스템뿐 아니라 이를 사용하는 팀 자체도 변화시켜야 한다. - 새로운 도구를 도입했다는 사실만으로 성과를 증명하려는 **‘보여주기식 진전(performative progress)’**에 빠질 수 있다. - 효과적인 리더는 도구를 추가하는 데 그치지 않고, AI 시대에 맞는 새로운 업무 방식을 설계한다. ## 직접 사용하며 AI라는 재료 익히기 - 디자인의 기본 원칙은 다루는 재료를 직접 사용해 깊이 이해하는 것이다. - AI 리더도 전략적 관점에만 머물지 말고 직접 프롬프트를 작성하고 에이전트를 만들어야 한다. - 여러 AI 도구를 실제로 사용하면 다음을 파악할 수 있다. - 도구의 장점과 한계 - 확률적 결과가 만들어내는 불확실성 - 실제 업무에서 발생하는 트레이드오프 - 도입 과정에서 사용자가 겪는 마찰 - 업무 외 영역에서 AI를 실험하는 것도 유용하다. - 여행 계획 - 집 꾸미기 - 생일 파티 준비 - 봉사활동 관리 - 이런 경험은 단순한 호기심 충족이 아니라, AI의 동작 방식을 체득하는 **AI 활용 역량**의 일부다. ## 관찰을 통해 실제 업무 흐름 이해하기 - 리더가 AI를 직접 사용하는 것만으로는 부족하며, 조직의 여러 팀이 AI를 어떻게 활용하는지도 관찰해야 한다. - 도구의 기능이나 최종 산출물보다 중요한 것은 업무 과정에서 다음이 어디서 발생하는지 파악하는 것이다. - 병목 - 반복 작업 - 사용자의 불편 - 문제 해결을 촉진하는 지점 - 관찰 대상이 될 수 있는 신호는 다양하다. - Slack 대화 - 설문 응답 - 도구 사용 패턴 - 구성원의 기대와 불만 - 팀이 업무를 우회하거나 자체 해결책을 만드는 방식 - 문서상으로 완벽한 AI 자동화도 복잡한 기존 업무 흐름에 마찰을 추가하면 사용률이 정체될 수 있다. - 따라서 낮은 도입률을 단순히 사용자의 저항으로 해석하지 말고, 기존 프로세스와의 연결 방식에 문제가 없는지 확인해야 한다. ## 아이디어를 프로토타입으로 구체화하기 - 디자인은 관찰과 실행을 함께 요구한다. - AI 관련 아이디어는 나빠서 실패하는 것이 아니라, 팀이 아이디어를 구체적으로 상상하거나 검토하지 못해서 실패할 수 있다. - 초기 개념을 실제로 볼 수 있는 프로토타입으로 만들면 다음이 가능해진다. - 추상적인 아이디어를 시각화 - 팀 간 이해 차이 축소 - 빠른 피드백 수집 - 실행 가능성과 문제점 조기 검증 - 글에서는 Figma Make를 활용해 AI 아이디어를 유형화하고 실제 형태로 발전시키는 방법을 소개하려 한다. 제공된 본문은 이 섹션의 도입부에서 끝나므로 구체적인 사례와 후속 원칙은 포함되어 있지 않다. AI 전환을 추진할 때는 도구 도입 건수보다 실제 사용 경험과 업무 변화에 집중하는 것이 좋다. 리더가 직접 AI를 실험하고, 구성원의 업무를 관찰하며, 작은 프로토타입으로 아이디어를 검증하는 순환을 구축해야 한다.

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

AIAI 에이전트프로토타이핑자동화+2

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

MCP 핵심 요약: 컨텍스트의 중요성과 활용 방법 | Figma 블로그

MCP(Model Context Protocol)는 AI가 Figma의 디자인 파일과 컴포넌트, 토큰, 레이아웃 결정 같은 맥락을 코드 작성 도구에서 활용하도록 연결한다. 이를 통해 AI가 단순히 화면을 모방하는 대신 디자인 시스템에 맞는 코드를 생성하고, 코드와 캔버스를 오가며 제품을 반복적으로 개선할 수 있다. 글의 결론은 MCP의 효과가 기술 자체뿐 아니라 팀이 얼마나 구조적이고 일관된 디자인 맥락을 구축했는지에 달려 있다는 것이다. ## MCP가 제품 개발에 필요한 이유 - MCP는 AI 도구가 팀이 사용하는 도구와 데이터에서 맥락을 가져올 수 있도록 하는 표준화된 연결 방식이다. - 기존 제품 개발의 선형적인 흐름은 디자인 → 개발 순서로만 진행되지 않는다. - 팀은 필요에 따라 어느 단계에서든 시작한다. - 개발 중 디자인으로 돌아가거나, 완성된 UI를 다시 캔버스에서 검토할 수 있다. - Figma MCP 서버는 디자인 정보를 개발자의 코드 작성 환경으로 전달한다. - 반대로 코드로 구현된 실제 UI를 Figma 캔버스로 가져와 탐색·수정하고, 다시 개발 환경으로 돌려보낼 수도 있다. ## 스크린샷만 보는 AI의 한계 - AI 코딩 도구가 Figma 화면만 참고하면 최종 결과의 시각적 형태만 파악하고, 그 결과를 만든 설계 의도는 알기 어렵다. - 예를 들어 AI는 다음과 같은 문제를 일으킬 수 있다. - 브랜드 색상과 비슷하지만 실제 토큰에 연결되지 않은 색상을 선택한다. - 팀이 반복적으로 사용한 기존 카드 컴포넌트 대신 새 카드를 처음부터 만든다. - 여러 중첩 컴포넌트로 구성된 폼을 하나의 단순한 요소로 평탄화한다. - 결과물은 겉보기에는 비슷해도 디자인 시스템에서 벗어난 코드가 되고, 화면과 컴포넌트가 늘어날수록 불일치가 누적된다. - MCP는 컴포넌트, 디자인 토큰, 레이아웃 구조 등 Figma 파일의 구조화된 정보를 AI에 제공해 이러한 번역 오류를 줄인다. ## 디자이너에게 달라지는 점 - 디자인 시스템은 제품의 시각적 일관성을 유지하는 수단을 넘어, AI가 생성하는 코드의 품질과 방향을 결정하는 입력값이 된다. - 파일의 구조와 명명, 컴포넌트 재사용성, 토큰의 일관성이 AI 생성 결과에 직접 영향을 준다. - AI가 대규모로 코드를 생성하기 때문에 작은 파일 정리 문제도 여러 화면에 반복될 수 있다. - 과거에는 개발자가 구현 과정에서 한 번 수정하면 끝날 문제가 될 수 있었다. - 이제는 하나의 불일치가 AI를 통해 여러 곳에 복제될 수 있다. - MCP를 사용하면 개발자가 코드로 구현한 결과를 디자이너가 다시 캔버스에서 확인할 수 있다. - 디자이너는 누락된 상태를 추가하고 세부 사항을 다듬어, 기존 구현을 다시 만드는 대신 제품을 완성도 있게 개선할 수 있다. ## 개발자에게 달라지는 점 - AI 코딩 도구는 개발 속도를 높이지만, 디자인 맥락이 없으면 개발자가 디자인 의도를 코드로 번역하는 작업을 여전히 직접 해야 한다. - MCP는 개발 도구 안에서 다음 정보를 활용할 수 있게 한다. - 재사용해야 할 컴포넌트 - 색상·간격·타이포그래피 등의 디자인 토큰 - 레이아웃과 계층 구조 - 디자인 시스템에 포함된 구성 방식 - 따라서 개발자는 화면을 추측하거나 비슷하게 재현하는 데 쓰는 시간을 줄이고, 실제 기능 구현과 제품 완성도 향상에 집중할 수 있다. - 디자인과 코드가 연결된 상태로 유지되므로 구현 과정에서 발생한 차이를 더 빠르게 발견하고 수정할 수 있다. ## 디자인 시스템이 AI 품질을 좌우한다 - MCP의 성능은 연결 방식만으로 결정되지 않고, AI가 읽는 디자인 파일의 품질에 크게 의존한다. - 명확하게 정리된 컴포넌트와 토큰은 AI가 일관된 결과를 생성하도록 돕는다. - 반대로 중복 컴포넌트, 불명확한 이름, 임의의 스타일 값이 많으면 AI가 잘못된 패턴을 학습하고 이를 여러 곳에 확산시킬 수 있다. - 디자인 시스템은 AI 기반 워크플로에서 생산성을 높이는 기준점이자, 생성 결과가 브랜드와 제품 규칙에 맞도록 제한하는 장치가 된다. 실무적으로는 Figma 파일을 AI가 읽기 쉬운 구조로 정리하고, 컴포넌트·토큰·상태를 명확히 관리하는 것이 우선이다. MCP는 디자인 시스템을 대체하는 기술이 아니라, 잘 구축된 디자인 시스템을 개발과 AI 생성 과정에 연결해 주는 기술로 활용해야 한다.

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

FigmaAI디자인 시스템AI 에이전트+3

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

Figma Weave로 프롬프트를 다섯 가지 확장 가능한 워크플로우로 전환하기 | Figma 블로그

Figma Weave는 단일 프롬프트로 이미지를 생성하는 도구가 아니라, 여러 AI 모델과 편집 단계를 연결해 반복·확장 가능한 창작 워크플로를 만드는 캔버스다. 사용자는 이미지·영상·오디오·3D 제작 과정에서 각 단계를 분기하고 수정하며 결과를 통제할 수 있다. 글은 특히 기존 이미지에서 스타일을 추출하고 조합해 재사용 가능한 스타일 가이드를 만드는 과정을 대표 사례로 소개한다. ## 프롬프트를 넘어선 AI 창작 워크플로 - 좋은 이미지를 빠르게 만드는 것과 브랜드에 맞고 다양한 채널에서 일관되게 사용할 이미지를 만드는 것은 다르다. - Figma Weave는 여러 AI 노드를 연결해 다음 작업을 지원한다. - 이미지, 영상, 오디오, 3D 생성 및 편집 - 프롬프트와 결과의 단계별 수정 - 여러 방향으로 결과를 분기해 탐색 - 서로 다른 AI 모델을 비교하고 검증 - 각 단계가 독립적으로 구성되므로 특정 결과를 다시 적용하거나 일부 요소만 바꿀 수 있다. - Figma는 Weavy를 인수해 Figma Weave로 발전시키고 있으며, 향후 Figma 제품과의 통합을 추진하고 있다. ## 템플릿으로 확장하는 제작 방식 - Figma Weave 팀은 Figma Community에 20개 이상의 워크플로 템플릿을 제공한다. - 템플릿은 다음과 같은 작업에 활용할 수 있다. - 이미지를 영상으로 변환 - 3D 모델 생성 - 여러 참고 이미지의 스타일 결합 - 이미지 생성 모델 간 결과 비교 - 글에서는 가상의 사운드·비디오 브랜드인 Epoch의 자산을 사용해 워크플로를 설명한다. - Epoch는 왜곡된 텍스처와 3D 자연물 형태를 브랜드 시각 언어로 사용하며, 모바일·데스크톱 화면에 일관된 이미지를 적용하는 상황을 가정한다. ## 두 이미지를 결합해 스타일 가이드 만들기 - 기존 미학과 어울리는 새 이미지를 만들 때, 처음부터 프롬프트를 작성하기보다 이미 검증된 참고 이미지에서 스타일을 추출한다. - 예시에서는 다음 두 이미지를 사용한다. - 분홍색 히비스커스 꽃 - 따뜻한 색감의 사암 표면 - 각 이미지를 **Image Describer 노드**에 입력하면 이미지의 주요 시각적 특성이 텍스트로 변환된다. - 질감 - 색상 - 조명 - 구성 - 형태와 분위기 - 추출된 두 설명을 하나의 스타일 정의로 결합한 뒤, 각 참고 이미지가 결과에 미치는 영향력을 개별적으로 조절한다. - 단순히 “두 스타일을 섞어 달라”고 요청하는 것과 달리, 워크플로에서는 각 스타일의 비중을 세밀하게 수정할 수 있다. - 완성된 스타일을 여러 이미지 생성 모델에 적용해 결과를 비교하고, 다양한 상황에서도 일관되게 작동하는지 검증한다. ## 일회성 프롬프트가 아닌 재사용 가능한 스타일 정의 - 최종 산출물은 특정 이미지 하나를 위한 프롬프트가 아니라 이후 작업에 반복 사용할 수 있는 스타일 정의다. - 이 정의를 다른 워크플로에 연결하면 다음 작업에서도 동일한 브랜드 감각을 유지할 수 있다. - 스타일을 별도의 구성 요소로 관리하면 이미지 생성, 편집, 영상 제작 등 후속 작업에서 수정과 재사용이 쉬워진다. - 핵심은 AI가 한 번에 정답을 생성하도록 기대하는 것이 아니라, 참고 자료·설명·생성 모델을 연결해 결과를 점진적으로 조정하는 데 있다. ## 실용적인 결론 브랜드용 AI 이미지를 만들 때는 단일 프롬프트보다 참고 이미지 분석, 스타일 결합, 영향력 조절, 모델 비교를 단계별 워크플로로 구성하는 편이 효과적이다. 먼저 기존 브랜드 자산에서 재사용 가능한 스타일 정의를 만들고, 이를 다양한 생성·편집 작업에 연결하면 결과의 일관성과 확장성을 함께 확보할 수 있다.

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

생성형 AI프롬프트 엔지니어링figma-weaveimage-generation+2

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

Figmates가 Figma AI를 활용해 즐거움의 차원을 한 단계 높인 방법 | Figma 블로그

Figma 팀은 연례 April Fun Day를 위해 Figma Make, Weave, MCP를 활용해 며칠 만에 여섯 개의 미니게임을 제작하고 캔버스에 일주일간 공개했다. 이 과정에서 AI는 아이디어를 빠르게 프로토타이핑하고 시각 요소를 확장하며, 디자인과 코드 사이의 협업을 가속하는 역할을 했다. 글의 결론은 적절한 AI 도구를 사용하면 디자이너와 개발자 모두가 제작 과정에 참여하면서 더 빠르게 실험하고 완성도 높은 결과물을 만들 수 있다는 것이다. ## 놀이를 실험의 장으로 활용한 April Fun Day - Figma의 April Fun Day는 매년 커뮤니티를 위한 이스터 에그와 새로운 경험을 선보이는 행사다. - 올해는 기존의 추억을 불러일으키는 콘텐츠를 넘어, 캔버스 안에서 직접 즐길 수 있는 미니게임 플랫폼 **FigCade**를 제작했다. - 팀은 평소 업무 영역을 벗어나 새로운 도구와 제작 방식을 시험하는 기회로 행사를 활용했다. - FigCade는 단 며칠 만에 완성됐으며, 일주일 동안 사용자에게 제공됐다. ## 빠른 프로토타이핑과 반복 - **Figma Make**를 사용해 아이디어를 즉시 작동하는 프로토타입으로 만들었다. - 예를 들어 `2Fast2Figma` 퀴즈의 초기 아이디어는 일요일 아침에 시작해 그날 오후 작동하는 프로토타입이 됐다. - 아이디어 수만큼 다양한 프로토타입을 만든 뒤, 빠르게 공유하고 반응을 확인하며 방향을 조정했다. - 제작 과정의 기본 원칙은 “먼저 보여주고, 반응하고, 정렬한 뒤, 반복한다”는 방식이었다. - `2Fast2Figma`에서는 사용자가 30초 동안 Figma 관련 질문에 최대한 많이 답하도록 구성했다. ## Figma Weave를 활용한 시각적 탐색 - **Figma Weave**는 게임의 시각적 스타일과 질감 요소를 빠르게 탐색하는 데 사용됐다. - 디자이너 Lesley Moon은 펠트 느낌의 커서 등 FigCade의 질감 있는 그래픽 요소를 몇 시간 만에 제작했다. - AI로 펠트 소재 에셋을 대량 생성하면서 시도할 수 있는 시각적 테마와 질감의 범위가 넓어졌다. - 생성 결과물을 그대로 사용하는 데 그치지 않고, 이를 기반으로 추가 제작과 수정 작업을 이어갔다. ## 하루 만에 제작한 홍보 영상 - Weave는 FigCade의 April Fun Day 트레일러 제작에도 활용됐다. - 제품 관리자 Tara Nadella가 Weave에서 영상 콘셉트를 구상하고 필요한 요소를 생성했다. - 모션 디자이너 Fifi Law는 이를 Lesley의 시각 자료와 결합해 최종 영상을 제작했다. - 스토리보드에 필요한 요소를 빠르게 생성할 수 있었고, 트레일러 전체를 하루 만에 만들었다. ## Figma MCP로 디자인과 코드를 연결 - **Figma MCP 서버**는 디자인 탐색 결과를 실제 코드로 구현하는 데 사용됐다. - 개발자는 Claude와 GitHub Copilot을 Figma MCP에 인증한 뒤, 특정 디자인 컴포넌트 링크를 에이전트에 전달했다. - 에이전트는 해당 디자인 사양을 참고해 UI 변경에 필요한 코드를 생성했다. - 이를 통해 개발자는 디자인 맥락을 직접 확인하면서 시각적 요구사항에 맞는 코드를 작성할 수 있었다. - 프로젝트 전반에서 팀은 디자인과 코드 사이를 반복적으로 오가며 구현 결과를 조정했다. ## 실용적인 결론 - 아이디어 단계에서는 Figma Make로 빠르게 여러 프로토타입을 만들고, 사용자 반응을 기준으로 선별하는 방식이 효과적이다. - 시각적 에셋과 영상은 Figma Weave로 다양한 방향을 먼저 탐색한 뒤 사람이 다듬는 것이 적합하다. - Figma MCP는 디자인 컴포넌트와 코드의 연결을 강화하므로, UI 중심 개발에서 특히 유용하다. - AI를 완성품 자동 생성 도구보다 **빠른 탐색과 협업을 돕는 도구**로 활용할 때 가장 큰 효과를 얻을 수 있다.

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

프로토타이핑생성형 AIgithub-copilotfigma-make+2

figma·2026년 4월 2일·4분 읽기큐레이션 요약

Figma Make에서 더 많은 맥락과 제어력으로 빌드하기 | Figma Blog

Figma Make가 **Make kits**와 **Make attachments**를 통해 디자인 시스템과 실제 프로젝트 자료를 반영한 프로토타입을 생성하도록 개선됐다. Make kits는 코드 패키지나 Figma 라이브러리의 컴포넌트·스타일·토큰과 사용 지침을 제공하고, attachments는 데이터·법률 문구·스크린샷 등 프로젝트별 맥락을 전달한다. 이를 통해 범용적인 초안에서 출발해 반복적으로 수정하는 대신, 실제 제품 구조와 제약에 가까운 결과물을 더 빠르게 만들 수 있다. ## AI 초안이 실제 제품과 어긋나는 문제 - 기존 AI 생성 UI는 레이아웃과 인터랙션은 그럴듯하지만 다음과 같은 문제가 있었다. - 팀의 실제 디자인 시스템 컴포넌트를 사용하지 않음 - 카피가 placeholder로 남음 - 예외 상황과 중요한 edge case가 반영되지 않음 - 프로덕션 코드의 구조와 다른 방식으로 구현됨 - 그 결과 초기 생성 속도는 빨라도, 리뷰 전에 디자인 시스템에 맞게 다시 작성하고 조정하는 데 많은 시간이 필요했다. - Figma는 이 문제의 원인을 생성 품질 자체가 아니라 **팀이 실제 개발에 사용하는 맥락의 부족**으로 설명한다. ## Make kits: 디자인 시스템을 학습시키는 패키지 - Make kit은 디자인 시스템의 컴포넌트나 스타일과, 이를 어떻게 사용해야 하는지 설명하는 세부 가이드라인을 하나의 재사용 가능한 패키지로 결합한다. - 다음과 같은 소스를 사용할 수 있다. - 공개 npm 레지스트리의 JavaScript 패키지 - Figma의 보안 비공개 레지스트리에 저장된 코드 패키지 - Figma 라이브러리의 스타일과 디자인 토큰 - 가이드라인은 단순히 “어떤 컴포넌트가 존재하는가”뿐 아니라 다음까지 전달한다. - 컴포넌트를 어떤 상황에 사용해야 하는지 - 컴포넌트가 어떤 구조와 패턴을 따라야 하는지 - 디자인 시스템의 규칙을 프로토타입에 어떻게 적용해야 하는지 - 따라서 Make는 일반적인 UI 요소를 조합하는 대신, 팀의 코드베이스와 가까운 구조로 프로토타입을 시작할 수 있다. ## Make kits가 팀 협업에 주는 효과 - 폼, 대시보드, 설정 화면, 온보딩 플로우 등 여러 팀이 공유하는 화면에서 일관성이 높아진다. - 여러 팀이 동시에 프로토타입을 제작해도 디자인 시스템에서 벗어날 가능성이 줄어든다. - 리뷰 전에 spacing, 컴포넌트 선택, UI 패턴을 다시 맞추는 작업이 감소한다. - 엔지니어 입장에서는 익숙한 컴포넌트와 코드 패턴을 바로 확인할 수 있다. - “이 부분은 커스텀 구현인가?”와 같은 확인 질문이 줄어들어, 디자인을 코드로 번역하는 시간보다 제안 자체를 검토하고 개선하는 데 집중할 수 있다. - Figma는 향후 Figma 라이브러리의 컴포넌트 구조를 더욱 정확히 재현하는 방향으로 Make kits를 발전시킬 계획이다. ## Make attachments: 프로젝트의 실제 맥락 반영 - 디자인 시스템만으로는 각 프로젝트의 고유한 요구사항을 모두 설명할 수 없다. - 실제 프로젝트에는 다음과 같은 정보가 추가로 필요하다. - 실제 사용자 데이터 - 마이그레이션 제약 - 예외 처리와 edge case - 규정 및 컴플라이언스 요구사항 - 브랜드 콘텐츠와 법률 문구 - Make attachments는 이런 자료를 긴 프롬프트로 요약하지 않고 원본 파일 형태로 Make에 전달한다. - 지원되는 자료에는 다음이 포함된다. - PDF와 Markdown 문서 - CSV·JSON 데이터셋 - 스크린샷과 이미지 - 브랜드 가이드라인 - 법률 문구 - 미디어 파일과 SVG - 코드 및 관련 프로젝트 파일 ## 실제 데이터와 제약을 반영하는 프로토타이핑 - 예를 들어 디지털 제품의 전체 온보딩 플로우를 만들 때는 다음 정보가 동시에 필요할 수 있다. - 실제 사용자 데이터 - 법률상 반드시 표시해야 하는 문구 - 여러 입력 검증 상태 - 정상 흐름 외의 예외 상황 - 첨부 파일 없이 프롬프트만 사용하면 Make가 법률 문구를 임의로 줄이거나, 검증 상태를 단순화하거나, 이상적인 정상 흐름만 생성할 수 있다. - 원본 PDF, 데이터셋, 스크린샷 등을 첨부하면 Make가 프로젝트 자료를 직접 참조하므로, 보다 현실적인 콘텐츠와 제약을 포함한 프로토타입을 만들 수 있다. ## 디자인 시스템과 프로젝트 자료의 결합 - Make kits는 **제품 전반에 공통으로 적용되는 규칙**을 제공한다. - Make attachments는 **특정 프로젝트에만 존재하는 데이터와 제약**을 제공한다. - 두 기능을 함께 사용하면 다음과 같은 흐름이 가능하다. - Make kits로 실제 코드 또는 Figma 라이브러리 기반의 컴포넌트 사용 - attachments로 실제 데이터, 콘텐츠, 법률 요구사항, 시각 자료 반영 - 생성 결과를 프로덕션 구조에 가깝게 유지하면서 프로젝트의 세부 조건까지 검증 - 결과적으로 프로토타입 제작은 “일반적인 UI 초안 생성”에서 “실제 제품 조건을 반영한 탐색과 검증”으로 이동한다. 실무에서는 공통 컴포넌트와 토큰을 Make kit으로 정리하고, 기능별 요구사항·데이터·법률 문구·예외 상태는 attachments로 함께 제공하는 방식이 효과적이다. 이렇게 하면 생성 후 대규모 수정에 쓰는 시간을 줄이고, 초기 단계부터 개발·디자인 리뷰에 적합한 프로토타입을 만들 수 있다.

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

디자인 시스템ReactJavaScriptfigma-make+3

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

소프트웨어와 상호작용하는 방식을 재구상하는 6가지 디자인 | Figma 블로그

이번 Figma Make-a-thon 수상작들은 소프트웨어가 단순히 효율을 높이는 도구를 넘어, 사람들의 연결·놀이·창작 방식을 새롭게 설계할 수 있음을 보여준다. 공통적으로 기존의 익숙한 상호작용을 비틀고, 제약과 감각적 경험을 활용해 더 인간적인 디지털 경험을 만든다. 특히 Figma Make는 전문 개발 지식이 부족한 사람도 아이디어를 빠르게 프로토타입으로 구현하도록 돕는 도구로 소개된다. ## 소프트웨어 상호작용을 다시 상상한 Make-a-thon - Figma Make-a-thon은 핀치 줌, 좋아요 탭, 오른쪽 스와이프처럼 일상화된 상호작용의 다음 가능성을 탐구했다. - 수상작에는 총 10만 달러의 상금이 수여됐다. - 작품들은 새로운 기능보다 사람 사이의 연결, 놀이, 창의성, 장인정신에 초점을 맞춘다. - 얼굴 움직임으로 인터페이스를 조작하거나, 16비트 세계를 구현하는 등 익숙한 소프트웨어 사용 방식을 확장한다. ## 낯선 사람과 함께 만드는 자수 캔버스 **수상 부문: Best Overall — Common Thread** - 전통적인 자수 견본천(sampler)에서 영감을 얻은 멀티플레이어 디지털 캔버스다. - 사용자는 실의 색상과 스티치 유형을 선택해 공동 캔버스에 자신의 흔적을 남긴다. - 한 사람의 작업물이 아니라 여러 방문자가 이어서 완성하는 구조이며, 캔버스의 제한된 공간 자체가 중요한 경험이 된다. - 10만 개가 넘는 스티치가 쌓였으며, 작품은 완성되지 않은 채 계속 확장된다. - 제작자는 기능 목록보다 먼저 “어떤 느낌의 경험을 만들 것인가”를 설명하고, Figma Make로 구조를 만든 뒤 시각 디자인을 덧입히는 방식을 추천한다. - 실시간 협업과 인터랙티브 캔버스 기능을 개발 지식 없이 하루 만에 구현했다는 점도 강조된다. - 핵심 메시지는 속도와 규모를 중시하는 디지털 환경에서, 제한과 느린 공동 작업이 오히려 의미 있는 상호작용을 만든다는 것이다. ## 클릭 대신 입술 움직임으로 조작하기 **수상 부문: New Interaction — Pucker** - 손을 사용할 수 없거나 음성 명령을 원하지 않는 상황을 위해 얼굴 움직임을 입력 방식으로 활용한다. - 고개를 기울여 커서를 움직이고, 일정 시간 멈춰 항목을 선택하며, 입술을 오므리는 동작으로 선택을 확정한다. - 뜨개질, 요리, 베이킹, 디자인처럼 손이 바쁜 상황에서도 화면을 조작할 수 있다. - 전면 카메라로 실시간 추적하지만, 데이터는 저장하거나 전송하지 않는 방식으로 설계됐다. - 제작자는 기본적인 코드 구조를 이해하면 프로토타입을 수정하고 문제를 해결하는 데 큰 도움이 된다고 조언한다. - Pucker는 특정 제품이라기보다 여러 앱과 플랫폼에 적용할 수 있는 “유연한 인터랙션 레이어”로 제시된다. - 새로운 상호작용이 충분히 자연스러워지면 사용자가 의식하지 않고도 사용할 수 있으며, 이것이 접근성 높은 디자인으로 이어질 수 있다는 관점을 담고 있다. ## 시간과 공간의 제약을 없앤 사진 부스 **수상 부문: Reimagining Iconic Interactions — Duet Booth** - 1920년대부터 크게 변하지 않은 사진 부스의 개념을 원격 환경으로 확장한다. - 서로 다른 장소에 있는 두 사람이 비동기적으로 사진을 촬영할 수 있다. - 각자의 사진을 하나의 사진 스트립으로 결합해, 마치 두 사람이 같은 장소에 함께 있었던 것처럼 보여준다. - 사진 부스가 사진을 더 쉽고 즉각적이며 공유 가능한 경험으로 만들었다는 점을 디지털 공간에서 재해석한다. - 제작자는 시각적 세부 사항보다 핵심 상호작용을 먼저 완성하라고 조언한다. 기본 경험이 제대로 작동하면 이후의 디자인 요소가 이를 중심으로 정리되기 때문이다. 이 사례들이 보여주는 실용적인 방향은 기능을 많이 추가하는 것보다 사용자가 어떤 감정과 행동을 경험할지 먼저 정의하는 것이다. 그 후 핵심 상호작용을 빠르게 프로토타이핑하고, 시각 디자인과 세부 기능을 단계적으로 보완하면 제한된 시간과 개발 지식으로도 독창적인 소프트웨어 경험을 만들 수 있다.

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

Figmareal-time-collaborationfigma-makecomputer-vision+2

figma·2026년 3월 25일·3분 읽기큐레이션 요약

피그마의 차세대 데이터 캐싱 플랫폼 | 피그마 블로그

Figma는 Redis 기반 캐싱 인프라가 성장하면서 연결 수 한계, 급격한 확장 시 연결 폭주, 관측성 부족 등으로 가용성 위협이 커지자 이를 근본적으로 재설계했다. 그 결과 stateless RESP 프록시인 FigCache를 구축해 Redis 연결과 클라이언트 서비스 규모를 분리하고, 라우팅·보안·관측성을 중앙화했다. 2025년 하반기 핵심 API에 도입한 이후 캐싱 계층은 99.9999% 가동률을 달성했다. ## Redis 캐싱 인프라의 성장통 - Figma의 Redis는 단순한 보조 구성 요소에서 사이트 가용성에 직접 영향을 주는 핵심 의존성으로 발전했다. - Redis 클러스터의 연결 수가 한계에 가까워졌고, 클라이언트 서비스가 빠르게 확장될 때 대규모 연결 생성이 동시에 발생하는 ‘thundering herd’ 문제가 나타났다. - 중앙화된 트래픽 관리와 일관된 접근 방식이 없어 애플리케이션이 서로 다른 클러스터의 데이터를 오염시키거나 손상시킬 위험이 있었다. - 클라이언트 라이브러리마다 관측 기능이 달라 장애 원인 분석과 대응이 어려웠다. - 장애 조치나 토폴로지 변경 시 클라이언트 상태가 올바르게 유지되는지 전체 서비스에 일관된 보장을 제공하기도 어려웠다. - Figma는 일부 API 시스템에서 Redis 의존성을 제거하고, 서비스별 연결 풀링을 도입해 단기적으로 장애 영향을 줄였지만 장기적인 공통 플랫폼이 필요하다고 판단했다. ## 장기적인 설계 목표 - **클라이언트 연결 변동성으로부터 Redis 격리** - Redis가 처리하는 연결 수를 클라이언트 애플리케이션의 규모와 탄력적 확장성에서 분리한다. - 서비스가 급격히 확장될 때 Redis로 연결 요청이 몰리는 현상을 막는다. - **기본 제공 observability** - 서비스 소유자와 플랫폼 운영자가 멀티테넌트 환경에서 개별 워크로드의 가용성과 성능을 확인할 수 있도록 한다. - 여러 계층에서 일관되고 세밀한 모니터링 기능을 제공한다. - **투명한 수평 확장** - 클라이언트가 인프라 확장이나 축소를 직접 알 필요 없도록 한다. - 클러스터 확장·축소, 노드 장애 조치, 샤드 전체 손실 같은 복잡한 Redis Cluster 동작을 클라이언트 라이브러리 아래 계층에서 처리한다. - **단일 범용 엔드포인트** - 여러 Redis 클러스터를 애플리케이션별 개별 설정 없이 중앙 라우팅한다. - 클러스터 격리 수준, 내구성, 중요도, 트래픽 규모가 서로 다른 환경의 분할 결정을 중앙에서 관리한다. - **대체 저장소의 플러그인 가능성** - 같은 프로토콜과 API를 유지하면서 필요에 따라 진정한 내구성을 제공하는 다른 저장 기술을 연결할 수 있도록 한다. - **기본 확장성** - 인라인 데이터 암호화, 보호 장치(guardrail), 트래픽 백프레셔 등 Figma 고유의 데이터 플레인 기능을 애플리케이션마다 반복 구현하지 않도록 한다. ## FigCache의 구조와 역할 - FigCache는 **stateless RESP-wire-protocol 프록시 서비스**다. - Redis 데이터 플레인과 진입 계층 역할을 하며, 애플리케이션에는 언어와 무관한 일관된 Redis 인터페이스를 제공한다. - 여러 Redis 클러스터와 백엔드 사이의 트래픽 라우팅 및 클러스터 관리 복잡성을 애플리케이션에서 숨긴다. - 연결 멀티플렉서로 동작해 클라이언트 서비스의 연결 변동이 Redis에 직접 전달되지 않도록 한다. - FigCache 자체와 함께 Figma가 관리하는 전용 클라이언트 라이브러리를 제공해 캐싱 스택 전반의 동작을 표준화한다. ## 플랫폼 전환의 효과 - Redis 연결 확장성과 클라이언트 서비스의 용량 변동을 분리할 수 있게 됐다. - 중앙화된 라우팅으로 애플리케이션이 여러 클러스터의 엔드포인트를 직접 관리할 필요가 줄었다. - 보안 정책과 트래픽 제어를 공통 계층에서 적용할 기반이 마련됐다. - 전체 캐싱 스택에 걸친 종합적인 관측성을 확보했다. - 2025년 하반기 Figma의 메인 API 서비스에 적용한 뒤 캐싱 계층은 **99.9999% 가동률**이라는 안정성 목표를 달성했다. ## 실용적인 시사점 Redis를 서비스의 핵심 경로에서 사용할 때는 개별 애플리케이션의 연결 풀링만으로 문제를 해결하기보다, 연결 중계·라우팅·클러스터 토폴로지 관리·관측성을 공통 플랫폼으로 분리하는 것이 효과적이다. 특히 클라이언트 수가 탄력적으로 변하는 환경에서는 프록시 계층을 통해 Redis가 직접 연결 폭주를 겪지 않도록 설계하는 것이 중요하다.

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

옵저버빌리티분산 시스템rediscaching+2

figma·2026년 3월 24일·3분 읽기큐레이션 요약

에이전트, Figma 캔버스를 만나다 | Figma 블로그

Figma는 이제 AI 에이전트가 디자인 캔버스에서 직접 파일과 컴포넌트를 생성·수정할 수 있도록 지원한다. MCP 서버의 `use_figma` 도구와 Markdown 기반 스킬을 통해 에이전트가 팀의 디자인 시스템, 컴포넌트, 변수, 작업 규칙을 활용하게 되며, 결과적으로 코드와 디자인 사이의 단절을 줄이는 것이 목표다. 이 기능은 현재 베타 기간 동안 무료로 제공되지만 향후 사용량 기반 유료 기능으로 전환될 예정이다. ## AI 에이전트가 Figma 캔버스에서 작업 - Claude Code, Codex 등 MCP 클라이언트가 `use_figma` 도구를 통해 Figma 파일과 컴포넌트를 직접 생성하고 수정할 수 있다. - 에이전트는 색상, 버튼 패딩, 타이포그래피, 인터랙션 같은 팀의 디자인 결정을 Figma 안에서 참조한다. - 기존처럼 AI가 일반적이고 브랜드와 동떨어진 디자인을 만드는 대신, 조직의 디자인 시스템에 연결된 결과물을 생성할 수 있다. - 코드에서 시작한 작업도 Figma에서 검토·수정할 수 있고, Figma에서 결정한 내용을 다시 개발 과정에 반영할 수 있다. ## `generate_figma_design`과 `use_figma`의 역할 분담 - `generate_figma_design` - 실제 웹사이트나 애플리케이션의 HTML을 Figma 레이어로 변환한다. - 코드와 디자인이 달라졌을 때 최신 UI를 Figma로 가져오는 데 사용된다. - `use_figma` - Figma 캔버스에서 기존 디자인을 수정하거나 새로운 디자인 자산을 생성한다. - 팀의 컴포넌트, 변수, 자동 레이아웃 등 실제 디자인 시스템을 활용한다. - 두 도구를 함께 사용하면 코드의 최신 상태를 Figma로 가져온 뒤, 에이전트가 디자인 시스템에 맞춰 재구성하고 개선할 수 있다. ## Markdown으로 정의하는 Figma 스킬 - 스킬은 에이전트가 Figma에서 작업하는 방법을 설명하는 Markdown 파일 기반 지침이다. - 특정 작업의 순서, 적용해야 할 규칙, 팀의 디자인 관례와 품질 기준을 명시할 수 있다. - 플러그인을 개발하거나 별도의 코드를 작성하지 않아도 누구나 스킬을 만들 수 있다. - 기본 스킬인 `/figma-use`는 Figma의 구조와 핵심 원칙을 에이전트에게 알려주며, 팀은 이를 확장해 자체 업무 방식에 맞출 수 있다. - 스킬은 단순한 문서가 아니라 에이전트가 실제 작업 중 따라야 하는 실행 규칙으로 작동한다. ## 제공되는 스킬 사례 - `/figma-generate-library`: 코드베이스에서 Figma 컴포넌트 라이브러리 생성 - `/figma-generate-design`: 기존 컴포넌트와 변수를 사용해 새로운 디자인 생성 - `/create-voice`: UI 명세에서 VoiceOver, TalkBack, ARIA용 스크린 리더 사양 생성 - `/apply-design-system`: 기존 디자인을 디자인 시스템 컴포넌트와 연결 - `/rad-spacing`: 변수와 폴백을 사용해 계층적인 간격 적용 - `/sync-figma-token`: 코드와 Figma 변수 사이의 디자인 토큰 동기화 및 변경 감지 - `/multi-agent`: 여러 에이전트가 디자인 구현 작업을 병렬로 수행 - 커뮤니티 실무자가 만든 JSON 기반 컴포넌트 생성, 디자인 워크플로 오케스트레이션 등의 스킬도 제공된다. ## 구조 기반의 자기 수정 - 에이전트는 화면을 생성한 뒤 스크린샷을 찍고, 결과가 목표와 다른 부분을 확인해 반복적으로 수정할 수 있다. - 수정 대상이 단순한 픽셀이 아니라 실제 컴포넌트, 변수, 자동 레이아웃, 레이어 구조이므로 디자인 시스템과 상호작용하며 개선된다. - AI 모델의 비결정성 때문에 같은 프롬프트라도 결과가 달라질 수 있지만, 스킬이 작업 순서와 기준을 고정해 결과를 더 예측 가능하게 만든다. - 기존의 디자인 규칙과 팀 관례가 정적인 문서에 머무르지 않고, 에이전트가 작업 중 실제로 적용하는 규칙이 된다. ## 실용적인 의미 팀은 `use_figma`와 `/figma-use`를 기반으로 자체 디자인 스킬을 만들고, 컴포넌트·변수·토큰 사용 규칙을 명시하는 것이 좋다. 특히 코드와 Figma가 자주 어긋나는 조직이라면 `generate_figma_design`으로 최신 UI를 동기화한 뒤, `use_figma`와 스킬을 이용해 브랜드와 디자인 시스템에 맞게 다듬는 워크플로가 효과적이다.

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

Figma디자인 시스템AI 에이전트모델 컨텍스트 프로토콜+4

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

컴포넌트 인스턴스의 토대를 재구축한 방법 | Figma 블로그

10년간 컴포넌트 인스턴스를 담당해 온 Figma의 `Instance Updater`는 오토 레이아웃, 변수, variants, 컴포넌트 속성 등 기능 확장으로 한계에 도달했다. Figma는 이를 대체하기 위해 반응형 기반의 범용 시스템인 `Materializer`를 구축하고, 인스턴스의 구조·속성 계산과 레이아웃·변수 평가를 분리했다. 그 결과 대규모 디자인 시스템에서 자주 수행하는 작업이 최대 50% 빨라졌고, 향후 동적 기능을 확장할 수 있는 기반도 마련했다. ## 컴포넌트 인스턴스의 기본 구조 - 메인 컴포넌트는 크기, 색상, 구조 같은 속성을 정의한다. - 인스턴스는 메인 컴포넌트의 변경 사항을 자동으로 반영하는 스마트 복사본이다. - 기존에는 `Instance Updater`라는 독립 런타임이 다음 작업을 모두 담당했다. - 인스턴스 속성 해석 - 인스턴스 내부 구조 관리 - 메인 컴포넌트와의 동기화 - 레이아웃 엔진 등 다른 시스템은 인스턴스를 만나면 `Instance Updater`에 처리를 위임했다. ## 기존 아키텍처가 한계에 도달한 이유 - Figma에는 오토 레이아웃(2019), variants(2020), 컴포넌트 속성(2022), 변수(2023) 등이 추가되며 인스턴스가 훨씬 복잡해졌다. - 현대적인 인스턴스는 다음 요소를 동시에 포함할 수 있다. - variants와 변수 바인딩 - 오토 레이아웃 규칙 - 고유한 오버라이드를 가진 중첩 인스턴스 - 변수 모드 - 복잡한 반응형 동작 - 기능이 추가될 때마다 `Instance Updater`에 개별적이고 특수한 로직을 덧붙였다. - 그 결과 인스턴스 처리, 레이아웃 계산, 변수 평가가 서로 강하게 얽혔다. - 작은 변경도 인스턴스 트리 전체에 전파될 수 있었다. - 변수 모드 하나를 바꾸면 수천 개 노드의 인스턴스 업데이트와 레이아웃 재계산이 발생할 수 있다. - 서로 다른 시스템이 같은 서브트리를 반복적으로 무효화하는 문제도 생겼다. - 인스턴스 교체나 속성 변경 시 편집기가 수 초 동안 멈추기도 했다. ## 아키텍처를 근본적으로 재설계한 목표 - 점진적인 최적화만으로는 문제를 해결하기 어렵다고 판단하고 구조 자체를 다시 설계했다. - 첫 번째 목표는 관심사의 분리였다. - 인스턴스 시스템은 메인 컴포넌트를 기반으로 어떤 속성과 자식 구조를 제공할지만 결정한다. - 레이아웃은 레이아웃 시스템이 전담한다. - 변수 평가는 변수 시스템이 전담한다. - 두 번째 목표는 세밀한 무효화(granular invalidation)다. - 기존 시스템은 변경이 발생하면 인스턴스 전체를 갱신했다. - 새 구조에서는 실제로 변경된 트리의 일부만 업데이트한다. - 깊게 중첩된 컴포넌트에서 불필요한 재귀적 작업을 줄일 수 있다. - 또한 인스턴스 전용 해결책이 아니라, 다른 기능에도 사용할 수 있는 범용 반응형 프레임워크를 목표로 삼았다. ## Materializer와 파생 서브트리 - Figma는 새 아키텍처를 지원하기 위해 `Materializer`를 만들었다. - `Instance Updater`가 컴포넌트 인스턴스에 특화된 시스템이었다면, `Materializer`는 Figma 문서 트리 전반에서 동작하는 범용 시스템이다. - Materializer의 핵심 역할은 **파생 서브트리(derived subtree)**를 생성하고 유지하는 것이다. - 파생 서브트리는 다른 원천 데이터로부터 구조와 속성이 계산되는 서브트리다. - 컴포넌트 인스턴스뿐 아니라 외부 CMS의 원본 콘텐츠와 동기화해야 하는 리치 텍스트 노드에도 같은 개념을 적용할 수 있다. - 따라서 인스턴스 기능 개선을 넘어, 외부 데이터나 다른 상태에 따라 문서 트리를 동적으로 구성하는 기능의 기반이 된다. ## 실용적인 결론 복잡한 트리 기반 시스템에서는 모든 변경 때 전체 트리를 다시 계산하기보다, 원천 데이터와 파생 결과를 분리하고 변경된 부분만 무효화하는 구조가 효과적이다. 또한 기능별 책임을 명확히 나누고 반응형 업데이트·의존성 추적을 범용 인프라로 추출하면, 성능 개선과 새로운 기능 확장을 동시에 달성할 수 있다.

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

디자인 시스템auto-layoutcomponent-instancesreactive-programming+3

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

디자인의 영향력은 커지고 있습니다. 그런데 왜 이것이 어렵게 느껴질까요? | Figma 블로그

AI는 디자인의 영향력과 적용 범위를 크게 넓혔지만, 디자이너의 일이 줄어든 것은 아니다. 오히려 새로운 제품 유형과 복잡한 사용자 경험이 등장하고, 더 빠른 제작 속도에 맞춰 기대 수준과 업무량도 증가하고 있다. 따라서 디자인 업계는 성장하고 있지만, 디자이너들이 체감하는 환경은 개선과 악화가 팽팽하게 엇갈린다. ## 디자인의 영향력 확대와 업계의 엇갈린 평가 - 그래픽 사용자 인터페이스, 웹, 모바일처럼 기술이 발전할 때마다 디자인이 다뤄야 할 영역과 책임이 넓어졌다. - AI 역시 새로운 소프트웨어와 상호작용 방식을 만들어 디자인의 범위를 확장하고 있다. - Figma의 2026년 디자이너 조사에서: - 36%는 디자인이 좋아졌다고 응답했다. - 35%는 나빠졌다고 응답했다. - 29%는 큰 변화가 없다고 답했다. - 디자인 채용 관리자 조사에서는 82%가 회사의 디자이너 수요가 증가했거나 유지됐다고 답했지만, 업계가 개선되고 있다고 본 응답자는 20%에 그쳤다. - 즉, 디자인의 중요성과 고용 수요는 커지고 있지만, 현업의 만족도나 전망이 반드시 함께 좋아지는 것은 아니다. ## 디자인 대상과 사용자 경험의 복잡성 증가 - AI는 에이전트 오케스트레이션 시스템, 답변 엔진 등 과거에는 없던 제품 유형을 만들어냈다. - 기존 제품에도 생성형·대화형·예측형 기능이 추가되면서 하나의 인터페이스 안에서 여러 상호작용이 동시에 일어난다. - 사용자는 단순히 화면을 클릭하는 데 그치지 않고 다음과 같은 방식으로 제품과 상호작용한다. - 자연어로 질문하거나 명령하기 - 이미지 업로드하기 - 프롬프트 입력하기 - 자동화된 결과를 검토하고 수정하기 - 디자인팀은 불완전하고 모호한 입력을 명확한 사용자 의도로 변환해야 한다. - 자동화된 경험에 신뢰성, 이해 가능성, 인간적인 느낌을 부여하는 것도 새로운 디자인 과제가 됐다. - 결과적으로 디자인자는 화면을 구성하는 역할을 넘어, 복잡한 시스템의 작동 방식과 사용자와 AI의 관계까지 설계해야 한다. ## AI는 업무를 줄이는 대신 증폭하는 계수 - AI는 새로운 디자인 문제를 더 빠르게 해결하도록 돕지만, 전체 업무량을 자동으로 줄여주지는 않는다. - 제품 개발자들은 이전보다 더 많은 도구를 사용하고 더 다양한 업무를 수행하고 있다. - Figma의 역할 변화 연구에서는 제품 제작자가 수행하는 업무가 전년 대비 17.5% 증가한 것으로 나타났다. - UC 버클리 연구에서도 AI 사용자는 더 빠르게 일했지만: - 더 많은 업무를 맡게 됐고 - 근무 시간이 늘어났으며 - 생산성은 높아졌지만 바쁘다는 느낌은 줄지 않았다. - AI는 인력을 대체하는 단순한 자동화 도구라기보다, 기존 능력과 산출량을 확대하는 ‘계수’에 가깝다. ## 젭슨의 역설과 늘어나는 산출량 - 어떤 생산 방식이 더 저렴하고 쉬워지면 총수요가 감소하는 것이 아니라 오히려 증가할 수 있다. - 이를 경제학의 ‘젭슨의 역설’이라고 한다. - 클라우드 인프라가 소프트웨어 배포를 쉽게 만들었을 때 출시 횟수와 재설계가 함께 늘어난 것처럼, AI도 디자인 제작을 빠르고 저렴하게 만들면서 작업량을 확대하고 있다. - 팀은 더 많은 아이디어를 탐색하고, 더 깊이 반복하며, 더 많은 결과물을 생산한다. - 따라서 AI로 인한 가속은 업무의 소멸보다는 업무 리듬과 규모의 변화를 의미한다. ## 실용적인 결론 AI 시대의 디자이너에게 중요한 역량은 단순히 더 빠르게 화면을 만드는 능력이 아니다. 복잡한 입력과 자동화 결과를 이해 가능한 경험으로 바꾸고, 늘어난 업무 범위 속에서 우선순위를 정하며, AI가 만들어낸 결과의 품질과 사용자 신뢰를 판단하는 능력이 더욱 중요해지고 있다.

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

AI생성형 AIuser-experience-designcloud-infrastructure+3

figma·2026년 3월 16일·3분 읽기큐레이션 요약

제15호: 디자인의 현주소 | 피그마 블로그

AI 도구와 워크플로가 디자인 방식을 근본적으로 바꾸면서, 디자인은 더 이상 특정 매체나 툴에 한정되지 않고 코드와 캔버스를 오가는 활동이 되고 있다. Figma의 조사에 따르면 디자이너의 91%가 AI가 업무 수준을 높인다고 답했으며, 채용 담당자의 82%는 디자이너 수요가 유지되거나 증가했다고 응답했다. 따라서 AI 시대의 디자이너에게는 전통적인 디자인 역량과 함께 문제 해결, 협업, AI 활용 능력이 중요해지고 있다. ## AI가 바꾸는 디자이너의 역할 - AI 도구는 디자이너의 작업 방식을 변화시키고 있으며, 단순한 제작 자동화를 넘어 아이디어 발상과 문제 해결에도 활용된다. - 디자이너가 무엇을 통해 가치를 만드는지는 사람마다 다르다. - 시각적 완성도 향상 - 복잡한 문제에 대한 사고 - 직관적인 사용자 경험 설계 - 이러한 가치 기준은 디자이너의 직무 만족도와 업무 경험에도 직접적인 영향을 준다. - 디자인 업무는 특정 매체에 고정되지 않고, 코드와 시각적 캔버스 사이를 자유롭게 오가는 방향으로 확장되고 있다. ## 디자인 채용 수요는 여전히 증가 - AI의 확산이 디자인 채용을 줄일 것이라는 전망과 달리, 조사 결과 기업의 디자이너 수요는 안정적이거나 증가하고 있다. - 전 세계 채용 담당자의 82%가 디자이너 채용 수요가 유지되거나 늘었다고 답했다. - 수요 증가는 기술 기업에만 국한되지 않고 다양한 산업으로 확산되고 있다. - AI가 제품 개발 속도를 높일수록 다음과 같은 역할이 더 중요해진다. - 사용자 문제를 정의하는 능력 - 제품 방향성을 시각화하는 능력 - 기술과 비즈니스 요구를 사용자 경험으로 연결하는 능력 - AI가 결과물을 생성하더라도, 어떤 문제를 풀고 무엇을 만들어야 하는지 판단하는 일은 여전히 사람의 역할이다. ## AI 시대에 요구되는 역량 - 프롬프트 작성 능력과 MCP 같은 AI 연동 기술을 이해하는 역량이 새로운 경쟁력으로 부상하고 있다. - AI 워크플로를 실제 디자인·개발 과정에 연결하고 자동화하는 능력이 중요하다. - 서로 다른 직군 사이에서 정보를 번역하고 협업을 이끄는 능력도 높은 가치를 갖는다. - 디자이너와 개발자 간 커뮤니케이션 - 제품 관리자와 디자인팀 간 요구사항 조율 - 기술적 제약과 사용자 요구의 연결 - 새로운 도구를 익히는 것만으로는 충분하지 않으며, 디자인의 기본기 역시 계속 중요하다. - 사용자 중심 사고 - 시각적 계층 구조 - 인터랙션 설계 - 문제 정의와 검증 - 결국 AI 활용 능력은 기존 디자인 역량을 대체하기보다 이를 확장하는 방향으로 작동한다. ## 프로토타이핑과 제품 의사결정의 변화 - Figma Make를 활용하면 제품 관리자도 아이디어를 빠르게 프로토타입으로 구현할 수 있다. - 프로토타입은 단순한 시각 자료를 넘어 제품의 복잡한 동작과 가능성을 검증하는 수단이 된다. - ServiceNow, Ticketmaster, Affirm 등의 제품팀은 프로토타이핑을 통해 다음을 수행하고 있다. - 복잡한 동작을 구체적으로 전달 - 아이디어의 한계를 빠르게 실험 - 제품 로드맵의 다음 방향에 대한 확신 확보 - 아이디어가 디자인팀에서만 시작되는 것이 아니라 제품, 개발, 기획 등 어느 직군에서든 시작될 수 있는 환경이 만들어지고 있다. ## 코드와 캔버스가 결합하는 미래 - 디자인의 미래는 코드와 시각적 캔버스가 서로 분리된 영역으로 남는 것이 아니라, 두 환경이 유기적으로 연결되는 방향으로 제시된다. - 아이디어는 코드로 구현되거나 캔버스에서 시각화된 뒤, 다시 서로 다른 형태로 발전할 수 있다. - 이 변화는 디자이너가 코드를 반드시 전문적으로 작성해야 한다는 의미라기보다, 구현 가능성과 기술적 구조를 이해해야 한다는 뜻에 가깝다. - 디자인 도구는 특정 직군만 사용하는 제작 프로그램에서, 여러 직군이 함께 사고하고 검증하는 협업 환경으로 확장되고 있다. AI 시대에는 새로운 도구를 많이 아는 것보다, AI를 활용해 더 나은 문제를 정의하고 빠르게 검증하며 다양한 직군을 연결하는 능력이 중요하다. 디자이너는 프롬프트와 자동화 기술을 익히되 사용자 중심 사고와 디자인 기본기를 함께 강화하는 것이 바람직하다.

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

FigmaAI프로토타이핑모델 컨텍스트 프로토콜+3

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

AI 시대에 갈고닦아야 할 5가지 디자인 기술 | 피그마 블로그

AI는 제품 제작을 가속하고 디자인 참여자의 범위를 넓히고 있으며, 이에 따라 디자이너에게 요구되는 역량도 변화하고 있다. Figma의 「State of the Designer 2026」 조사에 따르면 AI 활용 능력은 선택 사항이 아니라 디자이너와 비디자이너 모두에게 중요한 기본 역량이 되고 있다. 특히 명확한 프롬프트를 작성하고 AI를 반복 가능한 디자인 워크플로에 통합하는 능력이 핵심이다. ## AI 도구 활용 능력과 프롬프트 역량 - AI 활용 능력은 이제 디자이너 채용에서 필수에 가까운 기술로 자리 잡고 있다. - 디자이너의 91%는 AI가 더 나은 디자인을 만드는 데 도움이 된다고 답했고, 89%는 업무 속도가 빨라졌다고 답했다. - 채용 담당자의 54%는 AI를 활용한 디자인을 디자이너에게 가장 중요한 수요 기술 중 하나로 꼽았다. - AI 디자인 역량은 디자이너에게만 요구되지 않는다. - 채용 담당자의 57%는 PM, 개발자, 마케터 등 비디자인 직군에도 AI 활용 능력이 중요하다고 답했다. - 활용 사례는 다음과 같이 다양하다. - 기존 이미지의 세부 요소를 AI로 수정하기 - 코드를 직접 작성하기보다 AI로 앱 프로토타입 만들기 - 제품 요구사항 문서(PRD)보다 먼저 작동하는 프로토타입을 제작해 아이디어 검증하기 ## 프로토타입 중심의 협업 - AI 도구가 보편화되면서 역할 간 경계가 흐려지고, 다양한 직군이 직접 디자인과 프로토타이핑에 참여하고 있다. - 특히 제품 관리자는 문서로 요구사항을 설명하기보다 프로토타입을 만들어 가정을 빠르게 검증할 수 있다. - 구체적인 결과물을 조기에 공유하면 팀의 이해를 높이고, 의사결정을 빠르게 하며, 프로젝트 추진력을 확보할 수 있다. ## 구조화된 프롬프트 작성 - AI 결과물의 품질은 프롬프트의 명확성과 구조에 크게 좌우된다. - 효과적인 프롬프트는 다음 요소를 포함할 수 있다. - **작업(Task):** AI가 수행해야 할 구체적인 작업 - **맥락(Context):** 제품, 사용자, 사용 목적 등 배경 정보 - **요소(Elements):** 포함해야 할 화면·콘텐츠·기능 - **동작(Behavior):** 인터랙션과 상태 변화 - **제약 조건(Constraints):** 플랫폼, 스타일, 기술적 제한, 브랜드 규칙 - 좋은 프롬프트는 일회성 지시가 아니라 반복 가능한 작업 구조로 설계해야 한다. - 이를 통해 AI를 단순한 아이디어 생성기가 아니라 지속적인 디자인 협업 도구로 활용할 수 있다. ## 실용적인 적용 방향 AI 도구를 익힐 때는 단순히 다양한 기능을 시험하기보다, 작업 목적과 맥락·제약 조건을 포함한 프롬프트 템플릿을 먼저 만드는 것이 좋다. 또한 문서 작성 전에 프로토타입을 제작해 가정을 검증하고, AI가 만든 결과물을 디자이너의 판단과 검토를 거쳐 개선하는 방식이 효과적이다.

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

FigmaAI프로토타이핑figma-make+2