디자인 시스템

252 개의 포스트

figma3분 읽기큐레이션 요약

디자인-코드 루프가 열어 주는 가능성 | Figma 블로그

AI는 디자인과 코드 사이의 장벽을 낮춰 두 영역을 하나의 연속적인 작업 흐름으로 만들고 있다. 이제 디자이너는 정적인 시안을 반복 제작하는 대신 기능하는 프로토타입을 코드로 만들고, 이를 다시 Figma 캔버스에서 편집하며 방향을 재탐색할 수 있다. 중요한 변화는 단순한 코드 생성 속도가 아니라, 디자인과 코드 간 변환이 기계적 번역에서 의미 중심의 협업으로 바뀐다는 점이다. ## 디자인과 코드의 경계가 사라지는 흐름 - 과거에는 코드가 복잡하고 수정 비용이 높아 디자인 단계에서 여러 정적 시안을 먼저 탐색하는 방식이 일반적이었다. - AI를 활용하면 기능하는 와이어프레임을 빠르게 만들고, 레이아웃뿐 아니라 상호작용과 동작까지 직접 실험할 수 있다. - 코드에서 Figma 캔버스로 이동하면 이미 구현한 방향에 고정되지 않고 새로운 구조와 시각적 대안을 다시 탐색할 수 있다. - Figma의 Alex Kern은 핵심 변화가 “코드를 더 빠르게 생성하는 것”이 아니라 디자인과 코드 사이의 변환을 더 의미론적이고 덜 기계적으로 만드는 것이라고 설명한다. ## 양방향 디자인-코드 루프 - 기존 개발 환경은 코드베이스에 이미 존재하는 구조와 패턴을 중심으로 한 방향으로 작업하기 쉽다. - AI 모델 역시 기존 코드의 관성에 영향을 받아 완전히 다른 제품 방향을 제안하는 데 한계가 있을 수 있다. - Figma 캔버스에서는 코드에서 구현한 결과를 다시 시각적으로 검토하고, 전혀 다른 방향으로 되돌아가 탐색할 수 있다. - 이처럼 `코드 → 캔버스 → 코드`를 반복하는 루프가 디자인과 엔지니어링의 협업 범위를 넓힌다. ## 협업 참여자의 확대 - 과거에는 “디자이너가 코딩을 배워야 하는가”가 주요 논점이었다면, 이제는 “디자이너가 AI에게 코드를 요청할 수 있는가”가 더 현실적인 질문이 되었다. - AI는 디자인 시스템이나 내부 개발 환경에 직접 접근하지 못하는 사람도 실제 제품을 Figma의 편집 가능한 프레임으로 가져와 작업할 수 있게 한다. - 결과적으로 특정 도구, 전문 지식, 조직 내 접근 권한이 협업의 진입장벽이 되는 문제가 줄어든다. - 디자인과 개발이 일부 전문가만의 영역이 아니라 더 많은 팀원이 참여할 수 있는 공동 작업 공간으로 변화한다. ## 학습 곡선에서 학습 램프로 - AI는 초보자의 출발점을 높여 복잡한 프레임워크와 개발 환경을 처음부터 모두 익히지 않아도 작업을 시작하게 한다. - 작업 중인 실제 맥락에서 “이 코드가 무엇을 하는지”, “React 라우팅이 어떻게 동작하는지”를 질문할 수 있어 추상적인 교육보다 이해가 쉽다. - 디자이너는 자신의 제품과 문제를 기반으로 학습하면서 점진적으로 전문성을 쌓을 수 있다. - Gui Seiz는 AI를 통해 셰이더, 3D, 자체 제작 도구처럼 과거에는 기술적 지식 부족으로 시도하지 않았던 영역까지 탐색하게 되었다고 말한다. ## 도구보다 중요한 호기심과 취향 - AI 도구 자체는 점점 많은 사람에게 동일하게 제공되므로 도구 접근성만으로는 차별화하기 어려워진다. - 앞으로는 무엇을 만들지 판단하는 취향과, 새로운 가능성을 계속 시험하는 호기심이 중요한 경쟁력이 된다. - AI는 문법, 프레임워크, 개발 환경을 설명해 주는 인내심 있는 튜터 역할을 할 수 있다. - 따라서 AI 시대에는 기존 전문성을 유지하는 것뿐 아니라 새로운 방식으로 배우고 실험하는 태도가 중요하다. ## 실용적인 결론 디자이너와 개발자는 디자인과 코드를 분리된 인수인계 단계로 보기보다, 서로 오가며 반복 개선하는 하나의 루프로 운영하는 것이 유리하다. AI를 최종 결과물을 자동 생성하는 도구로만 사용하기보다, 기능 프로토타이핑·코드 이해·대안 탐색·협업 진입장벽 완화에 활용할 때 가장 큰 효과를 얻을 수 있다.

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

워크플로우 랩: 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는 코드를 디자인으로 자동 변환하는 도구라기보다, 구현 중 발생한 모든 제품 상태를 디자인 의사결정의 영역으로 되돌리는 연결 장치다. 빠르게 개발하는 팀이라면 에이전트로 코드의 상태를 캔버스에 동기화한 뒤, 디자이너가 오류·로딩·빈 상태·시각적 불일치를 직접 검토하는 절차를 구축하는 것이 유용하다.

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

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

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

토스가 디자인 직무를 2개로 줄인 이유 (새 탭에서 열림)

토스 디자인 챕터는 기술의 발전으로 도구 활용에 대한 장벽이 낮아짐에 따라, 기존의 세분화된 6개 직무를 'Product Designer'와 'Visual Designer' 2개로 전격 통합했습니다. 이번 개편은 "어떤 도구를 사용하는가" 혹은 "어떤 화면을 만드는가"라는 수단 중심의 경계를 허물고, "무엇이 좋은 경험인가"를 판단하는 디자이너 본연의 감각과 판단력에 집중하기 위한 결정입니다. 이를 통해 디자이너가 고민할 수 있는 영역을 넓히고, 매체나 기법에 갇히지 않는 본질적인 문제 해결을 지향합니다. **수단과 매체가 만든 직무 경계의 한계** * 기존의 직무 세분화(Platform, Interaction, Graphic, Brand 등)는 조직의 성장에 따라 전문성을 쌓는 데 기여했으나, 실무에서는 점차 경계가 모호해지는 문제가 발생했습니다. * 인터랙션 적용이나 디자인 시스템 구축 시 특정 직무의 영역인지 모호한 상황이 반복되었으며, 이는 협업의 효율을 저해하는 요소가 되었습니다. * 과거의 직무 구분은 "무엇을 판단하느냐"가 아니라 Lottie, 코드, PC/모바일 등 다루는 도구와 화면의 크기라는 '수단'에 매몰되어 있었다는 점이 한계로 지적되었습니다. **기술 발전과 하드스킬 장벽의 붕괴** * AI와 디자인 도구(Figma 등)의 비약적인 발전으로 영상 제작, 프로토타이핑, 코드 구현 등 과거 전문 영역이었던 기술적 난이도가 낮아졌습니다. * 이미 실무에서는 직무에 구애받지 않고 브랜드 디자이너가 제품을 디자인하거나, 그래픽 디자이너가 시스템을 구축하는 등 '경계를 넘는 디자이너'들이 등장하고 있었습니다. * 하드스킬 습득 시간이 단축됨에 따라 디자이너에게 가장 중요한 역량은 도구 숙련도가 아닌, 결과물의 질을 결정하는 '판단력'과 '감각'으로 이동했습니다. **통합된 두 가지 핵심 직무** * **Product Designer**: 기존의 제품 디자이너와 툴즈 제품 디자이너를 통합하여, 모바일과 PC라는 화면 구분을 없앴습니다. 사용자의 맥락과 문제를 발견하고 해결책을 설계하는 본질에 집중합니다. * **Visual Designer**: 플랫폼, 인터랙션, 그래픽, 브랜드 디자이너를 통합했습니다. 특정 매체에 국한되지 않고 "무엇이 아름답고 올바른 시각적 판단인가"를 고민하며, 필요에 따라 아이콘 제작부터 인터랙티브 웹까지 직접 수행하는 조형 전문가를 지향합니다. **산업 전반에서 나타나는 역할 수렴 현상** * 디즈니 애니메이션이 복잡한 물리적 공정을 소프트웨어로 대체하고 기획 중심의 구조로 바뀐 것처럼, 디자인 역시 도구 중심에서 판단 중심으로 진화하고 있습니다. * 음악 산업에서 DAW(디지털 오디오 워크스테이션)의 등장으로 작곡과 엔지니어링의 경계가 사라진 사례처럼, 도구가 하나로 모이면 역할도 자연스럽게 하나로 흐려집니다. * 영화와 TV 연출의 경계가 디지털 시네마 등장 이후 사라진 것과 마찬가지로, 디자인 매체의 통합은 거스를 수 없는 흐름입니다. **디자이너를 위한 실용적인 제언** 이제 디자이너는 특정 툴의 숙련도에 안주하기보다, 자신이 만드는 결과물이 사용자에게 어떤 가치를 전달하는지 '판단하는 힘'을 길러야 합니다. 직무의 이름에 스스로를 가두지 않고 문제 해결을 위해 필요한 모든 수단을 자유롭게 활용할 수 있는 역량을 갖추는 것이 중요합니다. 토스의 사례처럼 조직 차원에서도 디자이너가 더 넓은 범위에서 사고할 수 있도록 제도적 제약을 제거해 나가는 변화가 필요할 것입니다.

figma4분 읽기큐레이션 요약

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로 함께 제공하는 방식이 효과적이다. 이렇게 하면 생성 후 대규모 수정에 쓰는 시간을 줄이고, 초기 단계부터 개발·디자인 리뷰에 적합한 프로토타입을 만들 수 있다.

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

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

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

컴포넌트 인스턴스의 토대를 재구축한 방법 | 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의 원본 콘텐츠와 동기화해야 하는 리치 텍스트 노드에도 같은 개념을 적용할 수 있다. - 따라서 인스턴스 기능 개선을 넘어, 외부 데이터나 다른 상태에 따라 문서 트리를 동적으로 구성하는 기능의 기반이 된다. ## 실용적인 결론 복잡한 트리 기반 시스템에서는 모든 변경 때 전체 트리를 다시 계산하기보다, 원천 데이터와 파생 결과를 분리하고 변경된 부분만 무효화하는 구조가 효과적이다. 또한 기능별 책임을 명확히 나누고 반응형 업데이트·의존성 추적을 범용 인프라로 추출하면, 성능 개선과 새로운 기능 확장을 동시에 달성할 수 있다.

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

슬롯(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)로 흉내 내던 패턴을 더 직접적으로 표현할 수 있다. - 기본 콘텐츠가 예측 가능한 경우에는 미리 채운 슬롯을, 콘텐츠 입력이 필수인 경우에는 빈 슬롯을 사용하는 것이 적절하다. ## 도입 시 고려할 기준 - 모든 컴포넌트에 한꺼번에 슬롯을 적용하기보다, 실제 우회 사용이 많이 발생하는 소수의 고빈도 컴포넌트부터 시작한다. - 구조는 유지되지만 콘텐츠가 자주 바뀌는 영역을 우선 찾는다. - 슬롯의 기본 콘텐츠가 사용자에게 충분한 맥락을 주는지, 혹은 빈 상태가 명확한 행동을 유도하는지 검토한다. - 이를 통해 디자인 시스템의 통제력은 유지하면서도 실제 제품에 필요한 유연성을 확보할 수 있다.

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

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로 빠르게 작동하는 형태를 만들어 공유하는 것이 효과적이다. 단, 제공된 본문이 중간에 생략되어 있어 나머지 두 가지 활용 방식에 대한 상세 요약은 포함하지 않았다.

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

워크플로우 랩: 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의 이미지 편집·벡터화 기능을 활용하면 기존 자산을 재사용하면서도 모달, 카드, 오버레이에 맞는 시각적 변형을 빠르게 검증할 수 있다.

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

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`으로 다시 캔버스에 가져와 시각적 차이를 검토하는 방식을 추천한다. 이를 통해 코드 구현과 디자인 의사결정을 분리하지 않고 하나의 반복 가능한 작업 흐름으로 통합할 수 있다.

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

토스의 새로운 얼굴 만들기 (새 탭에서 열림)

토스는 서비스의 인상과 신뢰감을 효과적으로 전달하기 위해 기존의 인물 그래픽을 고도화했습니다. 기존의 귀엽고 어린 이미지를 탈피하여 똑똑하고 믿음직한 '토스다운' 인상을 구축하고, 글로벌 확장에 발맞춰 다인종·다문화 환경을 포용할 수 있는 보편적인 디자인 체계를 마련하는 데 집중했습니다. 이를 통해 어떤 화면에서도 완성도를 유지하며 사용자에게 친근하면서도 전문적인 가치를 전달하는 새로운 페르소나를 완성했습니다. **토스다운 신뢰감을 주는 인물 비율 조정** - 기존 그래픽은 얼굴의 세로 비율이 짧아 다소 어려 보이고 신뢰감이 부족하다는 피드백이 있었습니다. - 얼굴 형태를 크게 바꾸어 이질감을 주는 대신, 눈·코·입의 배치와 표현을 미세하게 조정하여 지적이고 성숙한 인상의 균형점을 찾았습니다. - 도형을 단순히 이어 붙인 구조에서 탈피하여 목과 어깨의 곡선을 다듬고 입체감을 더해 조형적 완성도를 높였습니다. - 단정하고 전문적인 분위기를 자아낼 수 있도록 과한 디테일이 배제된 짧은 목폴라 형태의 의상을 기본 착장으로 설정했습니다. **성별과 인종의 경계를 허무는 중립적 디자인** - 특정 성별로 치우치지 않는 중성적인 헤어 스타일을 개발하여 성별 중립적인 인상을 구현했습니다. - 헤어의 부피감을 보완하고 라인을 정돈하여 화면 크기가 커지더라도 그래픽의 밀도가 떨어져 보이지 않도록 개선했습니다. - 단일한 스킨톤에서 벗어나 이모지의 표준을 참고한 다섯 가지 스킨톤 체계를 정의함으로써 다양성을 수용했습니다. - 여러 인물이 등장하는 화면에서는 다양한 스킨톤을 섞어 배치할 수 있도록 가이드를 마련하여 유니버설 디자인의 가치를 투영했습니다. **글로벌 확장을 고려한 포용적 그래픽 시스템** - 한국 중심의 서비스에서 글로벌 시장으로 확장함에 따라 특정 문화권에 국한되지 않는 보편적인 얼굴이 필요해졌습니다. - 노란색과 같은 추상적인 중립 컬러 대신 실제 인종의 다양성을 반영한 컬러 시스템을 선택하여 사용자들의 공감을 유도했습니다. - 디자인 개선 후 실제 앱 적용 시 주변 인터페이스 요소들과 자연스럽게 어우러지며 브랜드의 지향점을 명확히 드러내고 있습니다. 이러한 개편은 단순한 시각적 변화를 넘어 토스가 지향하는 포용성과 신뢰라는 브랜드 가치를 사용자에게 더 가깝게 전달하는 역할을 합니다. 향후에도 인종, 성별, 연령에 관계없이 누구나 자신을 투영할 수 있는 중립적이고 포용적인 그래픽 시스템을 지속적으로 확장해 나갈 것으로 기대됩니다.

figma4분 읽기큐레이션 요약

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

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

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

디자인 시스템 다시 생각해보기 (새 탭에서 열림)

디자인 시스템은 성장에 따라 경직되기 마련이며, 시스템이 제품 팀의 변화하는 요구사항을 제때 수용하지 못할 경우 팀은 시스템을 우회하거나 파편화된 코드를 생성하게 됩니다. 토스의 디자인 시스템(TDS)은 디자인 시스템을 통제 수단이 아닌 '하나의 제품'으로 정의하고, 수요자의 니즈에 따라 유연하게 대응할 수 있는 설계 구조를 지향합니다. 이를 위해 단순함과 유연함을 동시에 잡을 수 있는 하이브리드 API 전략을 도입하여 일관성과 생산성을 모두 확보하는 해결책을 제시합니다. ### 시스템의 경직성과 파편화 문제 * 조직이 커지고 제품이 다양해지면 기존 시스템의 제약 내에서 해결할 수 없는 UI 요구사항이 빈번하게 발생합니다. * 제품 팀은 빠른 해결을 위해 피그마 컴포넌트를 해제(detach)하거나 라이브러리 코드를 복제(fork)하여 로컬에서 수정해 사용하게 됩니다. * 이러한 우회 방식은 시스템 업데이트와의 연결을 끊어버려 UI 불일치를 초래하고, 장기적으로 디자인 시스템의 핵심 가치를 무너뜨립니다. * 결국 디자인 시스템이 팀의 속도를 늦추는 장애물이 되지 않으려면, 강력한 규칙보다 '우회할 이유를 줄이는 유연한 설계'가 필요합니다. ### 확장성을 고려한 컴포넌트 API 패턴 비교 * **Flat 패턴**: 내부 구조를 숨기고 모든 변형을 props로 처리하는 방식입니다. 사용이 직관적이고 간결하지만, 예외적인 요구사항이 늘어날수록 props가 기하급수적으로 증가하여 유지보수가 어려워집니다. * **Compound 패턴**: 하위 컴포넌트(Header, Body, Footer 등)를 제공하여 사용자가 직접 조합하는 방식입니다. 시스템이 예측하지 못한 레이아웃도 유연하게 구현할 수 있으나, 코드량이 늘어나고 구조에 대한 학습 비용이 발생한다는 단점이 있습니다. * 두 패턴은 상충하는 장단점을 가지고 있으므로, 단순히 하나의 패턴을 강요하는 것은 사용자의 이탈을 막기에 부족합니다. ### TDS의 하이브리드 전략과 Primitive 레이어 * TDS는 단순하고 빈번한 케이스를 위한 **Flat API**와 복잡한 커스텀을 위한 **Compound API**를 동시에 제공합니다. * 사용자는 별도의 커스텀이 필요 없을 때는 간결한 Flat 형식을 선택하고, 세밀한 제어가 필요할 때는 Compound 형식을 선택하여 시스템 내부에서 문제를 해결할 수 있습니다. * 디자인 시스템 팀은 관리 효율을 위해 **Primitive(기초 단위)** 레이어를 먼저 구축합니다. * 내부적으로는 동일한 Primitive 컴포넌트를 공유하면서 외부로 드러나는 API만 두 가지 형태로 노출함으로써, 유지보수 부담을 최소화하면서도 사용자 경험을 극대화합니다. 디자인 시스템은 팀을 가두는 울타리가 아니라 안전하게 안내하는 가드레일이 되어야 합니다. 중앙에서 모든 것을 통제하려 하기보다, 규칙에서 벗어난 예외 상황까지 시스템 안에서 지원할 수 있는 유연한 설계를 갖출 때 진정한 일관성을 유지할 수 있습니다.

figma3분 읽기큐레이션 요약

제약 사항을 활용한

디자인과 요리 모두 결과를 좌우하는 것은 사전 준비이며, 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를 구체적으로 적으면 확률적인 모델 출력을 더 예측 가능하고 실용적인 프로토타입으로 유도할 수 있다.

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