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월 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 생성 과정에 연결해 주는 기술로 활용해야 한다.

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

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

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년 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`와 스킬을 이용해 브랜드와 디자인 시스템에 맞게 다듬는 워크플로가 효과적이다.

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

디자인 시스템FigmaAI 에이전트모델 컨텍스트 프로토콜+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월 5일·3분 읽기큐레이션 요약

슬롯(Slots)으로

Figma의 ‘슬롯(slots)’은 컴포넌트의 구조와 연결 상태는 유지하면서 내부 콘텐츠를 자유롭게 바꾸는 기능이다. 이를 통해 디자이너는 컴포넌트를 분리(detach)하지 않고도 다양한 콘텐츠를 구성할 수 있으며, 디자인 시스템 관리자는 과도한 variants와 유지보수 부담을 줄일 수 있다. 글은 초기 사용자들의 사례를 바탕으로 슬롯을 효과적으로 도입하는 방법을 소개한다. ## 슬롯이 해결하는 디자인 시스템의 문제 - 디자인 시스템이 커질수록 일관성을 위한 제약이 표현의 자유를 제한할 수 있다. - 디자이너들은 이를 해결하기 위해 다음과 같은 우회 방법을 사용한다. - 컴포넌트 variants를 계속 추가 - 모든 가능한 상태를 고려해 숨겨진 레이어를 미리 포함 - 컴포넌트를 detach해 개별 수정 - 그 결과 라이브러리가 비대해지고, 디자인과 실제 코드 구현 사이의 연결도 약해진다. - 슬롯은 안정적인 컴포넌트 구조 안에 콘텐츠를 동적으로 삽입한다는 점에서 코드의 컴포넌트 구성 방식과 유사하다. ## 팀별 기대 효과 - **디자인 시스템 관리자** - variants 수와 유지보수 작업 감소 - 실제 제품 구조와 더 밀접하게 연결 - **디자이너** - 시스템 밖으로 나가지 않고도 콘텐츠와 표현을 자유롭게 조정 - 컴포넌트를 detach하지 않고 맞춤 구성 가능 - **개발자** - 코드로 구현되는 구조와 유사한 예측 가능한 디자인 전달 - 핸드오프와 구현 과정 단순화 - 슬롯은 자동화와 AI가 디자인 구조를 해석하는 데에도 유리한 형태를 제공한다. - Figma는 Schema 2025에서 슬롯을 공개했으며, 글 작성 시점에는 오픈 베타로 제공하고 있다. ## 1. 사용 빈도가 높은 컴포넌트부터 시작하기 - 슬롯 도입 효과가 가장 큰 대상은 이미 많은 사용자가 detach하고 있는 컴포넌트다. - 초기 사용자들이 우선 적용한 대표 컴포넌트는 다음과 같다. - 대화상자(dialog) - 메뉴와 드롭다운 - 모달 - 카드 - 패널 - 특히 다음 조건을 만족하는 컴포넌트를 우선순위로 삼는 것이 좋다. - 여러 화면에서 반복적으로 사용됨 - 시스템 안에서 중복되어 있음 - variants가 지나치게 많음 - 다양한 유형의 콘텐츠를 수용해야 함 ### 반복 요소가 있는 컴포넌트 - 메뉴와 리스트는 가능한 항목 수를 처리하기 위해 숨겨진 레이어를 다수 포함하는 경우가 많다. - 예를 들어 기본 리스트에 3개 항목을 표시하면서 7개 항목을 숨겨둘 수 있지만, 11번째 항목이 필요하면 결국 컴포넌트를 detach하게 된다. - 슬롯을 사용하면 필요한 항목만 추가할 수 있다. - 기본 컴포넌트가 불필요하게 커지지 않음 - 콘텐츠가 늘어나도 원래 컴포넌트와의 연결 유지 - 모든 가능한 항목 수를 variants로 미리 만들 필요 없음 ### variants가 급증하는 컴포넌트 - 모달과 카드는 제목, 설명, 미디어, 버튼 조합에 따라 수많은 variants가 생기기 쉽다. - 슬롯을 사용하면 구조는 그대로 유지하면서 필요한 콘텐츠만 교체하거나 삽입할 수 있다. - 따라서 구조는 일정하지만 콘텐츠가 자주 달라지는 컴포넌트에 특히 효과적이다. ## 2. 미리 채운 슬롯과 빈 슬롯을 목적에 맞게 사용하기 - 슬롯을 만들 때 기본 콘텐츠를 넣을지 비워둘지 결정해야 한다. - **미리 채운 슬롯** - 컴포넌트가 어떻게 사용되는지 보여주는 맥락을 제공한다. - 대부분의 사용자가 수정하지 않아도 되는 기본 상태를 표현할 수 있다. - 예를 들어 카드 오른쪽 위에 항상 아이콘이 있다면 매번 아이콘을 삽입하게 만들 필요가 없다. - **빈 슬롯** - 디자이너가 반드시 콘텐츠를 추가해야 한다는 점을 명확히 전달한다. - 사용자의 다음 행동을 유도하는 자리 표시자 역할을 한다. - 기존에 인스턴스 교체(instance swap)로 흉내 내던 패턴을 더 직접적으로 표현할 수 있다. - 기본 콘텐츠가 예측 가능한 경우에는 미리 채운 슬롯을, 콘텐츠 입력이 필수인 경우에는 빈 슬롯을 사용하는 것이 적절하다. ## 도입 시 고려할 기준 - 모든 컴포넌트에 한꺼번에 슬롯을 적용하기보다, 실제 우회 사용이 많이 발생하는 소수의 고빈도 컴포넌트부터 시작한다. - 구조는 유지되지만 콘텐츠가 자주 바뀌는 영역을 우선 찾는다. - 슬롯의 기본 콘텐츠가 사용자에게 충분한 맥락을 주는지, 혹은 빈 상태가 명확한 행동을 유도하는지 검토한다. - 이를 통해 디자인 시스템의 통제력은 유지하면서도 실제 제품에 필요한 유연성을 확보할 수 있다.

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

디자인 시스템Figma사용자 인터페이스design-to-development+1

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

Figma Make로 팀이

제품 관리자는 PRD나 정적인 목업만으로 아이디어를 설명하는 대신, Figma Make로 실제 동작을 보여주는 인터랙티브 프로토타입을 빠르게 만들 수 있다. 이를 통해 복잡한 요구사항을 구체화하고, 디자이너·엔지니어·사용자의 피드백을 일찍 받아 더 빠르게 합의와 확신을 형성한다. ServiceNow 사례는 추상적인 설명보다 직접 보고 조작할 수 있는 프로토타입이 제품 방향을 설득하는 데 효과적임을 보여준다. ## 프로토타입 중심의 제품 의사결정 - PM은 고객 인사이트, 디자인 의도, 엔지니어링 제약을 연결하는 역할을 한다. - Figma Make를 활용하면 정적인 목업보다 제품의 외관과 동작을 함께 표현할 수 있다. - 초기 단계에서 인터랙티브 프로토타입을 만들면 다음과 같은 효과가 있다. - 디자이너와 엔지니어의 조기 피드백 수집 - 사용자 테스트를 통한 가정 검증 - 개발이 깊이 진행되기 전 문제 수정 - 팀이 추상적인 아이디어 대신 구체적인 결과물을 보고 논의 - 따라서 프로토타입은 단순한 디자인 산출물을 넘어, PRD를 보완하거나 대체하는 커뮤니케이션 수단이 된다. ## 복잡한 제품 사고를 공동의 이해로 전환 ServiceNow의 제품 디렉터 Ram Devanathan은 여러 제품 조직을 지원하는 디자인팀과 협업하면서 복잡한 설정 화면을 개선해야 했다. - 해당 화면에는 약 15~20개의 설정이 포함되어 있었다. - 단순한 토글 - 기술적 이해가 필요한 고급 옵션 - 장애 발생 및 우선순위 처리 방식에 영향을 주는 설정 - 시스템 부하를 바꿀 수 있는 구성 항목 - 기존 목업은 기능적으로는 동작했지만, Ram이 의도한 다음 요소를 충분히 전달하지 못했다. - 설정의 우선순위와 계층 구조 - 각 옵션에 대한 맥락적 안내 - 사용자가 느껴야 할 전반적인 경험의 톤 - 공유 디자인 리소스를 사용하는 조직에서는 디자이너의 초기 참여가 제한될 수 있다. - Figma Make의 템플릿은 디자인 시스템과 UX 패턴을 미리 포함할 수 있어, PM이 일관된 기준으로 초기 시안을 직접 발전시키는 데 도움을 준다. ## Figma Make로 설정 화면의 의도 구체화 Ram은 디자이너의 초기 목업을 Figma Make로 가져온 뒤, 설정 구조에 대한 구체적인 지침을 추가했다. - Make가 생성한 개선안은 다음과 같은 변화를 포함했다. - 관련 설정을 논리적으로 그룹화 - 단순한 설정을 화면 상단에 배치 - 개별 옵션을 설명하는 툴팁 추가 - 변경 후 서비스를 재시작해야 한다는 안내문 표시 - 그 결과 사용자는 복잡한 기술 설정을 더 명확한 순서와 구조로 탐색할 수 있게 됐다. - 프로토타입은 Ram과 디자이너가 UX 방향을 빠르게 맞추는 공통 기준이 됐다. - Ram은 말로 추상적인 의도를 설명하는 대신, “무엇을 의미하는지 직접 보여줄 수 있었다”고 평가했다. - 즉 Figma Make는 다음의 시간을 줄이는 역할을 한다. - 아이디어 설명 - 디자인 방향 조율 - 관계자 설득 - 초기 의사결정 사이클 ## 개발 전 기능 검증 제공된 글은 Ticketmaster 사례의 도입부에서 끝나 있어, 구체적인 검증 방식과 결과는 확인할 수 없다. 다만 제목과 도입 내용상 Figma Make를 이용해 실제 개발에 들어가기 전에 새로운 기능을 프로토타이핑하고, 사용자 및 내부 팀의 반응을 확인하는 사례로 이어지는 구성이다. 실무적으로는 복잡하거나 합의가 어려운 요구사항일수록 설명만 반복하기보다 Figma Make로 빠르게 작동하는 형태를 만들어 공유하는 것이 효과적이다. 단, 제공된 본문이 중간에 생략되어 있어 나머지 두 가지 활용 방식에 대한 상세 요약은 포함하지 않았다.

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

디자인 시스템AI사용자 경험프로토타이핑+3

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

워크플로우 랩: Figma의

Trivet 팀은 추천 프로그램의 클릭과 가입을 늘리기 위해 기존 배너를 모달, 인피드 카드, 전체 화면 오버레이로 확장해 비교한다. 각 방향은 노출 강도뿐 아니라 이미지 처리와 시각적 톤을 다르게 설계하며, Figma의 AI 이미지 편집과 벡터화 기능을 활용해 빠르게 실험한다. 핵심 결론은 레이아웃을 만드는 데 그치지 않고, 사용자의 관심을 얼마나 끌면서도 경험을 방해하지 않을지 시각적 긴장감과 전환율을 함께 검증해야 한다는 것이다. ## 문제 정의: 더 많은 관심과 덜한 방해 사이 - Trivet의 추천 프로그램 배너는 기대만큼 클릭과 가입을 유도하지 못했다. - 팀은 배너가 너무 눈에 띄지 않는지, 반대로 팝업이 사용자 흐름을 지나치게 방해하는지 검토한다. - 세 가지 UX 방향을 비교한다. - **모달**: 사용자의 흐름을 잠시 중단시키는 방식 - **인피드 카드**: 피드 안에 자연스럽게 통합되는 방식 - **전체 화면 오버레이**: 가장 높은 가시성을 제공하는 방식 - 목표는 관심도를 높이되 사용자 경험을 훼손하지 않는 것이다. ## 방향 1: 유리 효과로 호기심 유발 - Trivet 디자인 시스템의 레시피 행 컴포넌트를 기반으로 몰입감 있는 모달을 구성한다. - “독점 레시피 잠금 해제”라는 문구에 맞춰, 레시피 이미지를 완전히 보여주지 않고 살짝 흐리게 처리한다. - Figma의 다음 효과를 사용한다. - **Glass 효과**: 반투명하고 서리 낀 표면 표현 - **Refraction**: 깊이감과 굴절감 추가 - **Progressive blur**: 가장자리를 부드럽게 흐림 처리 - 사용자가 보상을 바로 얻을 수는 없지만 눈앞에 있다는 느낌을 주어, 모달을 띄우는 불편함을 시각적 보상으로 상쇄한다. ## 방향 2: 인피드 카드에 개성 추가 - 사용자의 흐름을 끊지 않도록 추천 프로그램을 피드 내부 카드로 배치한다. - 제한된 공간에 맞춰 사진보다 가볍고 유연한 손그림 일러스트를 사용한다. - **Remove background**로 불필요한 배경을 제거한 뒤, **Vectorize**로 래스터 이미지를 편집 가능한 벡터로 변환한다. - 벡터화한 케이크 스케치를 다음과 같이 다듬는다. - Fill 패널의 변수 검색으로 브랜드 색상을 적용 - **Cut tool**로 경계를 정리하면서 기존 패스를 유지 - **Bounding box**를 활용해 앵커 포인트를 회전하고 세부 형태를 조정 - 결과적으로 손그림의 질감은 유지하면서도 색상과 크기를 자유롭게 조절할 수 있는 재사용 가능한 브랜드 자산을 만든다. ## 방향 3: 전체 화면 오버레이로 우선순위 강조 - 전체 화면 오버레이는 사용자 경험을 명확하게 중단시키며 추천 프로그램의 중요도를 강하게 전달한다. - 넓은 화면을 채우려면 사진 자체가 충분히 강한 시각적 존재감을 가져야 한다. - 선택한 사진은 품질은 좋았지만 레이아웃 비율이 맞지 않았고, 숟가락이 음식보다 눈에 띄는 문제가 있었다. - 대체 이미지를 찾거나 레이아웃을 억지로 조정하는 대신, Figma의 정밀 이미지 편집 기능으로 이미지를 디자인에 맞게 수정한다. - **Erase object**로 시선을 분산시키는 요소 제거 - **Expand image**로 필요한 비율과 구도에 맞게 이미지 확장 - 이 방식은 이미지 소스를 다시 찾는 시간을 줄이고, 디자인 의도에 맞춰 기존 자산을 즉시 변형할 수 있게 한다. ## 도구와 팀을 연결하는 워크플로 - 이 워크플로는 Figma Design, Figma Make, FigJam을 함께 사용한다. - 디자이너, 콘텐츠 디자이너, 제품 관리자, 성장 분석가, 엔지니어가 같은 문제를 중심으로 협업한다. - 이미지 편집, 벡터화, 변수 적용, 프로토타이핑을 별도 도구로 분리하지 않고 하나의 흐름에서 연결한다. - 아이디어를 시각화한 뒤 인터랙티브 프로토타입으로 검토하고, 팀 피드백과 실험 결과를 바탕으로 빠르게 완성하는 접근을 보여준다. 추천 프로그램처럼 전환율이 중요한 UI에서는 하나의 시안을 정답으로 가정하기보다, 노출 강도가 다른 여러 방향을 동시에 설계하는 것이 효과적이다. 특히 Figma의 이미지 편집·벡터화 기능을 활용하면 기존 자산을 재사용하면서도 모달, 카드, 오버레이에 맞는 시각적 변형을 빠르게 검증할 수 있다.

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

디자인 시스템Figma사용자 경험ai-image-editing+2

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

Codex와 Figma로 프론트

Codex와 Figma MCP 서버를 연결하면 디자인과 실행 중인 프론트엔드 UI를 양방향으로 오갈 수 있다. Figma의 디자인 정보를 Codex에 전달해 코드를 생성하고, 구현된 UI를 다시 편집 가능한 Figma 프레임으로 가져와 검토·협업·개선한 뒤 변경 사항을 코드에 반영하는 방식이다. 이를 통해 초기 디자인이나 코드에 고정되지 않고, 탐색과 구현을 반복하며 더 나은 제품을 만들 수 있다. ## Figma 디자인에서 앱 시작하기 - Figma MCP 서버는 **Figma Design, Figma Make, FigJam** 파일의 정보를 Codex에 전달한다. - 구현할 Figma 파일에서 원하는 프레임이나 노드를 우클릭한 뒤 **“Copy as → Copy link to selection”**을 선택한다. - 복사한 선택 URL은 단일 요소, 컴포넌트 묶음 등 특정 캔버스 영역을 가리키며, 에이전트가 코드 생성에 사용할 원본 데이터가 된다. - Codex에서 새 프로젝트나 기존 프로젝트를 선택하고 다음과 같은 방식으로 요청한다. - “이 Figma 디자인을 코드로 구현하고, 기존 디자인 시스템 컴포넌트를 최대한 활용해줘.” - Codex는 Figma MCP 서버의 `get_design_context` 도구를 호출해 다음 정보를 추출한다. - 레이아웃 구조 - 스타일 - 컴포넌트 정보 - 기타 디자인 관련 컨텍스트 - 이 정보를 바탕으로 Codex가 디자인에 맞는 UI 코드를 생성한다. ## 코드에서 Figma 캔버스로 가져오기 - 코드에서 UI를 구현하고 반복 수정한 뒤, 실행 중인 화면을 Figma로 가져와 시각적으로 비교하고 대안을 탐색할 수 있다. - 앱은 로컬 환경이나 공개 웹 서버에서 렌더링할 수 있다. - Codex에 새 Figma Design 파일을 생성하도록 요청하면 다음 과정을 안내한다. 1. 새 파일 또는 기존 파일 선택 2. 파일을 저장할 워크스페이스 선택 3. UI 캡처를 위한 애플리케이션 설정 4. 브라우저에서 앱 세션 열기 - Figma MCP 서버의 `generate_figma_design` 도구는 실행 중인 인터페이스를 편집 가능한 Figma 프레임으로 변환한다. ## UI 캡처 기능 앱이 다시 로드되면 화면 상단에 캡처 도구 모음이 표시된다. - **Entire screen**: 현재 표시된 전체 화면을 Figma 파일로 캡처 - **Select element**: 페이지에서 특정 컴포넌트나 요소만 선택해 캡처 - **Open file**: 생성된 디자인 레이어를 Figma에서 확인 캡처가 끝나면 Figma 파일을 바로 열거나 Codex로 돌아갈 수 있으며, Codex에는 해당 Figma 파일 URL이 전달된다. ## 캔버스에서 UI 개선하기 Figma로 가져온 실행 UI는 단순 이미지가 아니라 추가 편집과 협업이 가능한 디자인 자료로 활용된다. - 디자인 시스템 컴포넌트 추가 - 스타일, 글꼴, 색상을 변수로 전환 - 레이아웃 조정 및 주석 작성 - 인터랙션과 빈 상태 화면 설계 - 여러 UI 변형안과 탐색안 비교 - 팀원과 캔버스에서 공동 검토 수정이 끝나면 처음과 동일하게 프레임 또는 노드의 선택 URL을 복사해 Codex에 전달하고, Figma MCP 서버를 통해 변경된 디자인을 애플리케이션 코드에 반영할 수 있다. ## 디자인과 코드의 왕복 workflow - 디자인에서 시작해 Codex로 구현한다. - 실행 중인 UI를 Figma로 가져와 실제 결과를 검토한다. - Figma 캔버스에서 스타일, 컴포넌트, 레이아웃, 상태를 개선한다. - 변경된 디자인 컨텍스트를 다시 Codex로 보내 코드에 반영한다. - 이 과정을 반복하면서 속도를 유지한 채 프로토타입부터 실제 서비스 UI까지 발전시킬 수 있다. 실무에서는 먼저 Figma에 디자인 시스템과 핵심 화면을 정리한 뒤 Codex에 전달하고, 생성된 UI를 `generate_figma_design`으로 다시 캔버스에 가져와 시각적 차이를 검토하는 방식을 추천한다. 이를 통해 코드 구현과 디자인 의사결정을 분리하지 않고 하나의 반복 가능한 작업 흐름으로 통합할 수 있다.

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

디자인 시스템Figma모델 컨텍스트 프로토콜design-to-code+2

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

디자인 시스템을 위한 새로운

디자인 시스템은 더 이상 단순한 UI 컴포넌트 라이브러리가 아니라 매출 성장, 고객 충성도, 글로벌 확장, 제품 전략을 지원하는 비즈니스 자산이다. DXC 연구에 따르면 그 가치는 작업 효율뿐 아니라 고객 만족도·유지율·브랜드 경험·시장 확장성과 같은 경영 지표로도 측정할 수 있다. 따라서 디자인 시스템 팀은 재작업 감소보다 고객과 사업에 미친 구체적인 영향을 중심으로 투자 가치를 설명해야 한다. ## 생산성 중심에서 사업 성과 중심으로 - 기존에는 디자인 시스템의 ROI를 다음과 같은 운영 효율로 설명하는 경우가 많았다. - 재작업 감소 - 디자인·개발 핸드오프 단축 - 제품 제작 속도 향상 - 여러 팀 간 일관성 유지 - 그러나 현재 기업들은 디자인 시스템을 다음과 같은 전략적 목표에 활용한다. - 제품 포트폴리오 확장 - 고객 유지율과 충성도 개선 - 글로벌 시장 진출 - 제품 완성도와 브랜드 경험 향상 - 경우에 따라 매출 성장 측정 - 핵심은 디자인 시스템의 활동 자체가 아니라, 그 결과가 사업 지표에 어떤 변화를 만들었는지 연결하는 것이다. ## 고객 성과와 디자인 시스템의 연결 - 기업이 이미 관리하는 고객 지표를 디자인 시스템의 성과 측정 기준으로 활용할 수 있다. - 제품 도입률 - 유지율 - 참여도 - 고객 만족도 - 작업 완료율과 문제 해결 시간 - Freshworks는 새로운 디자인 시스템 도입 이후 고객 서비스 비용을 28% 줄이고 지원 티켓의 해결 시간을 개선했다고 설명한다. - SAP는 앱 내 설문을 통해 사용자 데이터 100만 건 이상을 수집하고, 이를 디자인 시스템 개선에 반영한다. - Freshworks는 온보딩 과정에서 사용자가 어디서 시작해야 할지 어려워한다는 피드백을 바탕으로 새로운 개선 작업을 추진했다. - 고객 경험 개선을 위해 다음 데이터를 활용한다. - CSAT 점수 - A/B 테스트 - 전환 퍼널 분석 - 온보딩 과정의 마찰 지점 - 이런 방식은 디자인 시스템이 단순히 컴포넌트를 제공하는 조직이 아니라, 고객의 불편을 발견하고 제품 경험을 개선하는 체계가 되도록 한다. ## 기업 가치와 제품 품질의 확장 - 디자인 시스템은 기업이 만든 브랜드와 제품 원칙을 여러 팀과 제품에 확산하는 수단이다. - Linear는 디자인 시스템을 통해 ‘완성도 높은 제품을 만든다’는 기업 가치를 규모가 커진 조직에서도 유지하고 있다. - Linear의 접근 방식은 엄격한 규칙과 수치만을 따르기보다 제품이 의도적으로 설계된 것처럼 느껴지는지를 중요하게 본다. - 이를 위해 디자인 시스템을 고정된 규격집이 아닌 살아 있는 시스템으로 운영한다. - 필요에 따라 컴포넌트를 업데이트 - 다양한 상황에 대응할 수 있도록 유연성 확보 - 품질 기준은 유지하되 제품 맥락에 따른 예외 허용 - 결과적으로 높은 제품 완성도는 사용자 경험을 차별화하고, 고객 충성도와 순매출 유지율에 영향을 줄 수 있다. ## 글로벌 확장을 지원하는 설계 기반 - 글로벌 확장에서 디자인 시스템의 역할은 제작 속도를 높이는 것에 그치지 않는다. - 여러 지역에서 일관된 브랜드 경험 제공 - 각 시장의 문화와 언어에 맞는 인터페이스 구현 - 다양한 하드웨어와 화면 크기 지원 - 브랜드별 고유성 유지 - 현대자동차그룹은 현대·기아·제네시스 3개 브랜드의 30개 이상 차량 모델을 하나의 일관된 기반으로 확장하면서도 각 브랜드의 정체성을 유지하려 한다. - Grammarly는 초기부터 현지화를 디자인 시스템 전략에 포함했다. - 사내 언어 전문가를 채용해 문화적 뉘앙스 반영 - 오른쪽에서 왼쪽으로 읽는 언어의 가독성 고려 - 언어별 레이아웃과 표현 차이를 시스템 입력값으로 관리 - 북미, 한국, 폴란드에 분산된 팀은 공통 디자인 시스템을 기반으로 지역별 차이를 조정한다. - 현대자동차그룹의 42dot은 다국어 UX를 검증하기 위해 맞춤형 Figma 플러그인도 활용한다. ## 디자인 시스템의 성과를 입증하는 방법 - 경영진이 중요하게 여기는 기존 비즈니스 지표와 디자인 시스템의 활동을 직접 연결해야 한다. - 예를 들어 다음과 같이 측정할 수 있다. - 디자인 변경 후 고객 만족도 변화 - 온보딩 퍼널의 이탈률 감소 - 지원 문의와 고객 서비스 비용 감소 - 기능 출시 기간 단축 - 글로벌 출시 시 지역별 일관성 및 현지화 품질 - 고객 유지율과 순매출 유지율 변화 - 정성적 사례와 정량적 데이터를 함께 제시하면 디자인 시스템의 기여도를 더 설득력 있게 설명할 수 있다. - 단순히 “컴포넌트를 몇 개 만들었는가”보다 “고객의 문제를 얼마나 줄였고 사업 결과를 어떻게 개선했는가”가 중요한 평가 기준이다. 디자인 시스템 팀은 운영 효율을 기본 성과로 제시하되, 고객 만족도·유지율·비용·매출·글로벌 확장성과 연결된 지표를 함께 관리하는 것이 좋다. 또한 시스템을 경직된 규칙 모음이 아니라 브랜드 가치와 사용자 피드백을 지속적으로 반영하는 살아 있는 제품으로 운영해야 한다.

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

디자인 시스템Figma사용자 경험디자인 토큰+2

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

제약 사항을 활용한

디자인과 요리 모두 결과를 좌우하는 것은 사전 준비이며, AI 프롬프트도 마찬가지다. LLM은 공감이나 예의보다 명확한 지시와 제약 조건을 필요로 하므로, 자연어로 막연하게 요청하기보다 구조화된 입력을 제공해야 한다. 글은 디자이너가 AI의 확률적 결과를 의도적이고 반복 가능한 디자인 결과로 바꾸기 위한 프레임워크로 TC-EBC(Task, Context, Elements, Behavior, Constraints)를 제안한다. ## 명확성이 예의보다 중요한 이유 - LLM은 감정을 느끼는 존재가 아니라 입력을 해석하는 시스템이므로 “부탁해”, “고마워” 같은 표현은 필요하지 않다. - 지나치게 공손한 표현은 요구사항을 더 명확하게 만들기보다 모호성을 늘릴 수 있다. - 모델은 깨끗한 지시문, 분명한 맥락, 구체적인 제약 조건을 바탕으로 더 안정적인 결과를 만든다. - LLM의 출력은 확률적이고 가변적이지만, 디자인은 정밀하고 반복 가능하며 의도적이어야 한다. - 따라서 디자인 분야의 프롬프트 작성에는 단순한 언어 능력보다 시스템적 사고가 필요하다. ## 미장플라스: 프롬프트도 사전 준비가 핵심 - 요리에서 미장플라스(mise en place)는 조리 전에 재료와 도구를 모두 준비해 혼란을 줄이는 과정이다. - 프롬프트 역시 실행 전에 다음 요소를 정리해야 한다. - 명확한 작업 - 충분한 맥락 - 필요한 UI 요소 - 예상되는 동작 - 구체적인 제약 조건 - 사전 준비를 잘하면 결과물을 만든 뒤 수정하고 보완하는 비용을 줄일 수 있다. - 프롬프트 엔지니어링에서도 의도 정의, 모듈화, 예측 가능성, 제약 조건이 중요한 원칙으로 강조된다. - 중요한 것은 고정된 문법을 외우는 것이 아니라, 사용자의 의도와 모델의 해석을 일치시키는 것이다. ## TC-EBC 프레임워크 - **Task**: AI가 수행해야 할 핵심 작업을 정의한다. - **Context**: 제품의 목적, 사용자, 사용 환경을 설명한다. - **Elements**: 필요한 화면, 기능, 컴포넌트, 콘텐츠를 나열한다. - **Behavior**: 사용자의 행동과 시스템의 반응을 구체적으로 기술한다. - **Constraints**: 플랫폼, 접근성, 레이아웃, 대상 기기 등 지켜야 할 조건을 지정한다. ## 모호한 프롬프트와 구조화된 프롬프트의 차이 - 막연한 요청의 예시는 다음과 같다. - “식료품 저장 공간이나 냉동고 사진으로 레시피를 추천하는 앱을 만들어 주세요. 알레르기와 선호도도 기억해 주세요.” - 이 방식은 핵심 기능이 한 문장 안에 섞여 있고, 화면 구성과 동작 방식이 명확하지 않다. - 그 결과 기본 기능은 갖추지만 와이어프레임에 가까운 평범하고 제한적인 결과가 나올 수 있다. - 같은 요구를 TC-EBC로 바꾸면 다음처럼 구체화할 수 있다. - **Task**: 식료품 저장 공간·냉장고 사진을 활용한 AI 식사 추천 앱 제작 - **Context**: 식이 제한이 있는 가정을 위한 요리 보조 앱 - **Elements**: 카메라 입력, 식재료 스캐너, 식이 설정 폼, 식사 추천 목록, 레시피 카드 - **Behavior**: 사진 업로드 → 재고 분석 → 식이 선호도 필터링 → 레시피 추천 - **Constraints**: 모바일 우선, iOS·Android 지원, 접근성 UI, 여러 가족 프로필 지원 - 이렇게 작성하면 모델이 요구사항을 빠르게 파악하고, 원하는 UI와 동작을 포함한 결과를 생성할 가능성이 높아진다. ## 디자이너에게 필요한 프롬프트 작성 방식 - 프롬프트를 한 번에 길게 작성하기보다 요구사항을 역할별로 분리하면 모델의 추측 영역을 줄일 수 있다. - 특히 “무엇을 만들 것인가”뿐 아니라 “누가 사용하는가”, “어떻게 동작하는가”, “무엇을 반드시 지켜야 하는가”를 함께 제공해야 한다. - 구조화된 프롬프트는 디자인 시스템처럼 AI에게 적절한 방향과 범위를 제공한다. - Figma Make 같은 프롬프트 기반 프로토타이핑 도구에서는 시각적 결과와 상호작용이 모두 중요하므로, 기능 목록만 제시하는 것보다 화면 요소와 사용자 흐름까지 명시해야 한다. AI에게 원하는 결과를 얻으려면 자연어로 희망사항을 늘어놓기보다 TC-EBC 형식으로 요구사항을 정리하는 것이 좋다. 특히 Task와 Behavior를 분명히 하고, Elements와 Constraints를 구체적으로 적으면 확률적인 모델 출력을 더 예측 가능하고 실용적인 프로토타입으로 유도할 수 있다.

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

디자인 시스템대규모 언어 모델프로토타이핑생성형 AI+2

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

프로토타입은

제품 관리자는 정적인 PRD를 작성해 검토받는 대신, 초기 아이디어를 인터랙티브한 프로토타입으로 구현하며 문제를 더 빠르게 이해하고 팀의 합의를 이끌어낼 수 있다. Figma는 Figma Make를 활용하면 불확실한 문제를 탐색하고 여러 해결책을 비교하며, 실제 디자인 시스템에 가까운 결과물로 가설을 검증할 수 있다고 설명한다. 따라서 프로토타입은 단순한 시각 자료를 넘어 의도와 동작을 보여주는 새로운 형태의 PRD로 자리 잡고 있다. ## 제품 관리자의 역할 변화 - 기존에는 PM이 요구사항 문서와 정적인 자료를 작성해 디자인·엔지니어링 팀의 검토를 받는 방식이 일반적이었다. - 이제는 팀과 함께 프롬프트를 작성하고 직접 프로토타입을 만들며, 아이디어를 구체적인 형태로 발전시키는 역할이 중요해지고 있다. - 문서만으로는 제품의 동작과 미묘한 사용 경험을 충분히 전달하기 어렵지만, 프로토타입은 “설명하는 것” 대신 “보여주는 것”을 가능하게 한다. - 작동하는 예시는 논의를 촉진하고, 팀이 같은 대상을 보며 빠르게 의견을 조율하도록 돕는다. ## 탐색: 불확실한 문제를 구체화하기 ### 문제 공간 정의 - 초기 단계에는 문제와 제약 조건이 명확하지 않아, 정답에 해당하는 해결책을 바로 정하기 어렵다. - Figma PM Tara Nadella는 문제 공간을 충분히 이해하지 못했을 때 Figma Make로 직접 여러 흐름과 상호작용을 실험했다. - 이를 통해 팀에 다시 가져갈 질문을 정리하고, 플러그인 사용 방식이나 전체 경험을 더 직관적으로 만드는 디자인 변경점에 대해 의견을 형성할 수 있었다. - 프로토타이핑은 해결책을 확정하기 전에 PM이 문제를 이해하고 자신의 관점을 세우는 수단으로 활용된다. ### 초기 아이디어를 여러 방향으로 발전시키기 - Figma Make는 빈 캔버스에서 시작하는 부담을 줄이고, 짧은 시간 안에 여러 접근 방식을 생성하게 해준다. - 손그림이나 텍스트 설명만으로 아이디어를 전달하는 대신, 실제로 반응하는 화면을 보고 어느 방향을 발전시킬지 판단할 수 있다. - Make kits를 사용하면 실제 제품의 디자인 라이브러리와 컴포넌트를 기반으로 프로토타입을 만들 수 있어, 일반적인 목업보다 출시 가능한 결과물에 가깝다. - Figma Design의 **Copy design** 기능으로 Figma Make 프리뷰를 편집 가능한 디자인 레이어로 변환할 수 있다. - 여러 시안을 빠르게 파생할 수 있다. - 디자이너가 시각적 완성도를 수동으로 보완할 수 있다. - 수정한 디자인을 다시 Figma Make에 연결해 프로토타입을 업데이트할 수 있다. - Figma Slides의 브랜드 색상 자동 적용 사례에서는 기존 템플릿을 복제하고, 프롬프트에 포함된 단서에 따라 색상 팔레트를 바꾸는 동작을 시뮬레이션했다. - 이처럼 프로토타입은 아이디어를 글로 설명하는 것보다 접근 방식에 대한 확신을 높이고, 실제 동작을 팀에 시연하는 데 유리하다. - Figma Make의 AI 이미지 기능을 이용하면 배경 제거, 객체 분리, 이미지 재구성 등 시각적 탐색도 캔버스에서 빠르게 수행할 수 있다. ## 디자인 시스템과 템플릿으로 탐색의 품질 유지하기 - 프로토타입을 실제 제품과 동떨어진 일반적인 목업으로 만들지 않으려면 디자인 시스템을 연결해야 한다. - Make kits에 팀의 디자인 라이브러리를 연결하면 생성 결과가 실제 제품의 UI와 컴포넌트에 기반하도록 만들 수 있다. - 프롬프트를 작성할 때는 기본 UI를 먼저 설정하고 관련 라이브러리를 첨부하는 것이 권장된다. - 완성도 높은 프로토타입은 Make 템플릿으로 게시할 수 있다. - 팀원이 수정할 수 있는 범위를 가이드로 제한할 수 있다. - 모든 사람이 동일한 기반에서 탐색할 수 있다. - 브랜드와 제품 경험의 일관성을 유지할 수 있다. - 장시간 프로토타이핑한 뒤 잠시 떠났다가 다시 검토하면, 처음에는 놓쳤던 세부적인 불일치나 사용성 문제를 발견하기 쉽다. ## 검증: 투자할 아이디어를 선별하기 - 아이디어를 자유롭게 생성하는 단계에서 실제로 자원을 투입할 대상을 검증하는 단계로 넘어가려면, 내부 이해관계자의 동의와 사용자 피드백이 필요하다. - 프로토타입은 정적인 설명 자료보다 실제 경험에 가까운 형태로 의견을 받을 수 있게 한다. - 사용자는 문서의 의도를 추측할 필요 없이 화면의 흐름과 동작을 직접 경험할 수 있으므로, 오해에 기반한 피드백을 줄이고 방향이 타당한지 확인하는 데 도움이 된다. 실무적으로는 문제를 충분히 이해하지 못한 상태에서 PRD부터 완성하려 하기보다, 실제 디자인 시스템을 연결한 낮은 비용의 프로토타입을 먼저 만들어 여러 방향을 비교하는 방식이 효과적이다. 이후 프로토타입을 내부 검토와 사용자 피드백의 기준점으로 활용하면, 문서만으로 합의하는 것보다 빠르게 실행 가능한 방향을 정할 수 있다.

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

디자인 시스템FigmaAI프로토타이핑+2

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

이제 정부용 피그마

Figma Make이 Figma for Government에 추가되어 연방 기관이 보안 환경에서 대화형 프로토타입을 더 빠르게 제작할 수 있게 됐다는 내용이다. Figma는 이를 통해 정책 담당자, 디자이너, 개발자, 연구자, IT 담당자가 협업하며 시민 대상 서비스를 더 일찍 검증하고 접근성과 일관성을 높일 수 있다고 설명한다. Figma for Government는 FedRAMP Moderate 인증 환경을 기반으로 하며, 일부 클라우드 인프라의 완전한 규정 준수는 2026년에 완료될 예정이지만 Make은 현재 승인된 환경에서 사용할 수 있다. ## 공공 서비스 디지털화의 복잡성 - 정부 서비스는 시민 생활과 직접 연결되므로 사용성, 접근성, 신뢰도가 중요하다. - 정책 담당자, 기술 담당자, 운영 책임자 등 다양한 이해관계자의 요구를 조율해야 한다. - 요구사항이 계속 변하고 디자인·개발 인력이 제한적이어서 정적인 목업만으로는 빠른 검증이 어렵다. - 2024년 온라인 여권 갱신 시스템 사례에서는 2025년까지 200만 명 이상이 온라인으로 갱신했으며, 이용자의 97%가 긍정적인 경험을 보고했다. - 미국 행정명령도 시민 대상 서비스에서 사용성, 접근성, 디자인 일관성의 중요성을 강조했다. ## Figma Make의 역할 - 텍스트 프롬프트를 활용해 아이디어를 대화형 프로토타입으로 구현한다. - 기존에는 정적 시안을 주고받으며 수주가 걸리던 작업을 수시간 내에 탐색할 수 있다. - 다양한 사용자 흐름과 화면 구성을 빠르게 만들어 초기 단계에서 비교·수정할 수 있다. - 시민과 실제 사용자를 개발 전에 참여시켜 업무 흐름과 가정을 검증할 수 있다. - Figma 내부의 공유 라이브러리, 디자인 패턴, 접근성 기준과 연계해 결과물의 일관성을 유지한다. ## 협업과 서비스 품질 향상 - 디자이너, 정책 담당자, 연구자, 엔지니어, IT 담당자가 하나의 실시간 협업 공간에서 작업할 수 있다. - 아이디어 구상부터 프로토타입, 사용자 테스트, 개발 전달까지의 단절을 줄인다. - 연방 혜택, 금융 커뮤니케이션, 교육 플랫폼, 우주 임무 지원 시스템, 연구 서비스 등 복잡한 공공 업무에 적용할 수 있다. - 공유 디자인 시스템을 활용해 여러 기관과 서비스에서 접근성과 시각적 일관성을 높일 수 있다. - 시민의 피드백을 더 이른 시점에 반영해 개발 후반의 수정 비용과 실패 위험을 줄일 수 있다. ## 보안 및 규정 준수 - Figma Make은 Figma for Government의 승인된 환경에서 제공된다. - Figma for Government는 FedRAMP Moderate 권한을 기반으로 정부 기관의 보안 요구사항을 충족하도록 설계됐다. - 다만 Figma의 일부 클라우드 인프라는 2026년에 완전한 FedRAMP Moderate 규정 준수를 달성할 예정이다. - 글에서는 이러한 진행 상황과 별개로 Make 자체는 현재 승인된 환경에서 사용할 수 있다고 설명한다. ## 향후 방향 - Figma는 Figma Make을 시민 중심의 공공 서비스와 기관 내부 도구를 현대화하는 핵심 기능으로 확대하려 한다. - 정부 기관이 더 많은 아이디어를 빠르게 실험하고, 사용자 검증을 거쳐 실제 서비스로 발전시키는 것이 목표다. - 국립공원관리청의 431개 국립공원 디지털 앱 사례처럼, 작은 팀도 Figma를 활용해 대규모 공공 정보 서비스를 구축할 수 있음을 강조한다. 실무적으로는 Figma Make을 최종 서비스 개발 도구라기보다, 보안 환경에서 정책·업무 흐름을 빠르게 검증하는 프로토타이핑 도구로 활용하는 것이 적절하다. 도입 전에는 조직의 데이터 분류 기준과 FedRAMP 적용 범위, 2026년 예정된 인프라 규정 준수 일정을 별도로 확인해야 한다.

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

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

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

AI 시대의 디자인 시스템을

AI 시대의 디자인 시스템은 단순한 컴포넌트 라이브러리에서 팀의 취향·품질 기준·의사결정 맥락을 담는 살아 있는 프레임워크로 발전하고 있다. AI가 빠르게 결과물을 생성하더라도 디자인 시스템이 방향성과 제약을 제공해야 브랜드의 개성과 품질을 유지할 수 있다. 따라서 앞으로는 시스템을 더 풍부하게 문서화하고, AI가 활용할 수 있도록 구조화하며, 제품 제작 전반을 관리하는 역할까지 확장해야 한다. ## 디자인 시스템에서 ‘크래프트’를 전달하는 시스템으로 - AI는 결과물을 빠르게 만들지만, 기준이 없으면 팀의 비전과 어긋난 결과를 만들고 재작업을 늘릴 수 있다. - 디자인 시스템은 단순한 일관성 검사 도구가 아니라 팀의 취향과 창의적 정체성을 반복 가능하게 만드는 장치가 된다. - 컴포넌트, 레이아웃, 인터랙션에 디자이너의 판단 기준을 반영하면 AI가 제품 전반에 동일한 감각을 적용할 수 있다. - 목표는 속도를 높이면서도 제품의 인간적인 개성과 완성도를 잃지 않는 것이다. ## AI 탐색을 현실적인 선택지로 제한하기 - 기존에는 여러 디자인 방향을 검토하려면 각 시안을 수작업으로 제작해야 해 탐색 범위가 제한적이었다. - Figma Make 같은 프롬프트 기반 도구와 디자인 시스템을 결합하면 다양한 레이아웃, 색상, 컴포넌트 조합을 빠르게 생성할 수 있다. - 공유 컴포넌트와 검증된 스타일을 기반으로 하기 때문에 AI가 만든 시안도 실제 제품에 적용 가능한 수준에 가까워진다. - 여러 방향을 실험한 뒤 선택한 안을 처음부터 다시 구현하는 대신, 기존 시스템을 바탕으로 세부 조정만 하면 된다. - 즉, 디자인 시스템은 AI의 자유로운 탐색을 막는 제약이 아니라 유효한 탐색을 가능하게 하는 기반이다. ## AI가 이해할 수 있도록 시스템을 작성하기 - 기존 디자인 시스템은 브랜드와 조직을 잘 아는 디자이너·개발자가 암묵적인 맥락을 보완한다는 전제 아래 작성됐다. - AI는 조직의 브랜드, 비즈니스 목표, 제품 관습을 자동으로 추론하지 못하므로 명시적인 설명이 필요하다. - 토큰과 컴포넌트뿐 아니라 다음 내용을 문서화해야 한다. - 각 결정이 내려진 이유 - 사용 조건과 제약 사항 - 좋은 결과물과 나쁜 결과물의 사례 - 품질을 판단하는 기준 - 브랜드와 제품 맥락 - 문서, 코드, 디자인 전반의 빈틈을 줄이고 암묵지를 명시지로 바꾸는 것이 중요하다. - 시스템은 사람을 위한 참고 자료인 동시에 AI가 브랜드에 맞는 결과를 생성하기 위한 지식 기반이 된다. ## 컴포넌트 관리에서 제품 제작 거버넌스로 - AI 도구가 제품 제작 과정에 들어오면서 디자인 시스템 팀의 역할은 컴포넌트 라이브러리 유지보수를 넘어선다. - 전통적인 제품 직군이 아닌 구성원도 제품에 기여할 수 있게 되므로, 이들이 사용하는 AI 및 제작 도구까지 관리 범위에 포함된다. - 디자인 시스템 팀은 어떤 도구와 방식으로 제품이 만들어지는지, 결과물이 품질·브랜드 기준을 충족하는지 관리하는 역할을 맡게 된다. - 제공된 글은 이 부분에서 본문이 중단되어, 거버넌스의 구체적인 실행 방식과 다섯 번째 변화의 내용은 확인할 수 없다. AI를 도입할수록 디자인 시스템을 단순한 UI 자산 저장소로 취급해서는 안 된다. 컴포넌트와 토큰에 의사결정 맥락, 품질 기준, 사용 제약을 함께 기록하고, AI 생성 결과가 시스템 안에서 검증·개선되도록 운영하는 것이 실용적인 방향이다.

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

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

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

Gemini 3를

Gemini 3 Pro가 Figma Make의 실험적 모델로 제공되며, 디자인을 작동하는 코드 기반 프로토타입으로 전환하는 능력을 보여준다. Figma의 초기 테스트에서 다양한 레이아웃·스타일·인터랙션을 빠르게 탐색하면서도 디자인 충실도를 유지하는 점이 강점으로 나타났다. Gemini 3 Flash는 빠른 아이디어 발상과 수정에 적합한 경량 모델로 함께 제공된다. ## Figma Make에서 Gemini 3 Pro 제공 - Figma는 AI 모델을 다음 기준으로 평가한다. - 원래 디자인을 얼마나 정확하게 구현하는가 - 반복적인 작업을 얼마나 줄여주는가 - 팀의 창의적 탐색 범위를 얼마나 넓혀주는가 - Gemini 3 Pro는 다양한 레이아웃, 시각적 스타일, 인터랙티브 패턴을 탐색하는 데 강점을 보였다. - Figma Make의 실험적 모델 설정에서 활성화할 수 있다. - Gemini 3 Flash는 성능과 속도에 초점을 둔 모델로, 빠른 아이디어 구상과 반복적인 디자인 수정에 적합하다. ## 디자인에서 코드로의 전환 - Figma Design에서 제작한 황금빛 나뭇잎과 짙은 적갈색 배경의 추수감사절 감사 보드를 Figma Make로 구현했다. - Gemini 3 Pro는 다음 작업을 수행했다. - 나뭇잎을 SVG로 생성 - 화면 위에서 자연스럽게 움직이는 물리 효과 구현 - 마우스를 올리면 감사 메시지가 표시되는 인터랙션 추가 - Supabase를 연결해 사용자가 감사 메시지를 제출하도록 구성 - 단순한 시각적 콘셉트가 데이터 저장과 사용자 입력을 포함한 인터랙티브 프로토타입으로 확장됐다. ## 하나의 기능, 여러 시각적 스타일 - 새해 전야 RSVP 페이지를 대상으로 스타일 변환 능력을 테스트했다. - 처음에는 다음과 같은 Y2K 스타일을 적용했다. - 복고풍 미래주의 - 어두운 크롬 질감 - 분위기 있는 시각 언어 - 실제로 작동하는 RSVP 폼 - 이후 같은 기능을 “콘크리트 포에트리” 스타일로 변경했다. - 강렬하고 제한적인 타이포그래피 - 브루털리즘적 긴장감 - 장식을 최소화한 구성 - 스타일이 크게 바뀌어도 RSVP 폼의 핵심 기능은 유지됐다. - 각 스타일에 맞춰 애니메이션과 인터랙션 세부 요소도 일관성 있게 조정됐다. ## 디자인 시스템과 컴포넌트 활용 - Gemini 3 Pro를 이미 구축된 디자인 시스템 안에서 테스트했다. - Figma Make의 Make kits와 npm import를 통해 공유 라이브러리와 컴포넌트를 활용할 수 있도록 구성했다. - UI3 라이브러리 기반의 FigJam 템플릿에 캔버스 배경 스타일 전환 기능을 추가하도록 요청했다. - 모델은 다음 결과를 만들었다. - 12가지 배경 스타일 구현 - UI3 컴포넌트 사용 - 배경 스타일 전환 인터랙션 추가 - 텍스처 간 애니메이션 적용 - 스티키 노트의 레이어링과 크기 변화 효과 구현 - 복잡한 설명 없이도 기존 시스템의 구성 요소를 활용하면서 새로운 기능을 프로토타이핑했다. ## 디자이너의 역할 확대 - AI는 디자이너를 대체하기보다 탐색 가능한 디자인 공간을 넓히는 도구로 제시된다. - 모델이 디자인 의도와 시스템을 더 잘 이해할수록 다음 작업이 빨라진다. - 다양한 스타일 시도 - 인터랙션 검증 - 디자인 시스템 기반 기능 실험 - 코드로 구현된 프로토타입 제작 - 속도와 창의성이 서로 충돌하기보다, AI가 반복 작업을 줄여 디자이너가 방향 설정과 가능성 판단에 더 집중하게 만든다는 관점이다. Gemini 3 Pro는 높은 시각적 충실도와 인터랙션 구현이 필요한 프로토타입 제작에 적합하고, Gemini 3 Flash는 빠른 시안 생성과 반복 수정에 활용하는 것이 좋다. 다만 실제 제품 개발 전에는 생성된 코드와 데이터 연결, 접근성, 디자인 시스템 준수 여부를 별도로 검토해야 한다.

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

디자인 시스템AIfigjamfigma-make+4