figma2026년 7월 30일

속성 패널과 주석 기능, 이제 Figma Make에서 사용 가능 | Figma 블로그 (새 탭에서 열림)

Figma Make에 속성 패널과 주석 기능이 추가되어, 사용자는 코드를 직접 작성하지 않고도 시각적으로 인터페이스를 수정할 수 있게 되었다. 속성 패널은 간격·타이포그래피·레이아웃 같은 시각적 변경을 정밀하게 처리하고, 주석은 애니메이션이나 상호작용처럼 설명이 필요한 변경을 특정 요소에 연결해 전달한다. 두 기능은 디자인과 코드 사이의 간극을 줄이고, 프롬프트 기반 편집보다 정확하고 효율적인 작업 흐름을 제공한다. ## Figma Make의 속성 패널과 주석 기능 - Figma Make 편집기에서 요소를 선택한 뒤 시각적 컨트롤이나 자연어 주석으로 코드를 수정할 수 있다. - 디자인을 수정하는 과정과 코드가 업데이트되는 과정을 하나의 연속적인 작업 흐름으로 통합한다. - 새 기능은 처음부터 작업하는 경우뿐 아니라 기존 코드 기반 프로젝트를 편집할 때도 사용할 수 있다. ## 속성 패널을 활용한 시각적 편집 - 상단 툴바에서 **Edit**를 선택하면 요소의 속성을 조정할 수 있다. - 조정 가능한 항목에는 다음이 포함된다. - 패딩, 요소 간 간격, 코너 반경 - 글꼴 굵기, 줄 높이, 자간 - 투명도, `z-index`, 테두리 스타일 - 위치와 레이아웃 속성 - 코드의 전체 DOM 트리를 레이어 패널처럼 확인하면서 원하는 요소를 선택할 수 있다. - 동일한 요소의 모든 인스턴스를 한 번에 선택해 일괄 수정할 수 있다. - 현재는 코드베이스에 정의된 색상 및 타이포그래피 토큰을 사용해 디자인 일관성을 유지한다. - 향후 Code Connect가 적용되면 Figma Design 컴포넌트와 코드 컴포넌트 간 연결도 강화될 예정이다. ## 변경 사항 검토와 코드 반영 - 속성 패널에서 변경한 내용은 즉시 코드에 확정되지 않고 프롬프트 입력창에 먼저 단계적으로 쌓인다. - 사용자는 각 변경 사항을 검토한 뒤 적용하거나 마음에 들지 않는 변경을 폐기할 수 있다. - 적용을 완료하면 Figma Make가 실제 코드를 수정하고 새로운 파일 버전을 생성한다. - 따라서 캔버스에서 시각적으로 확인한 결과와 실제 배포되는 코드 사이의 불일치를 줄일 수 있다. ## 주석을 통한 정밀한 프롬프트 작성 - 속성 패널만으로 표현하기 어려운 상호작용, 애니메이션, 동작 변경에는 주석 기능을 사용할 수 있다. - **Annotate for agent**를 선택한 뒤 캔버스에서 변경 대상 영역을 직접 표시하고 자연어로 요구사항을 작성한다. - 예시는 다음과 같다. - 썸네일에 마우스를 올리면 약간 확대 - 버튼을 300ms 지연 후 페이드 인 - 버튼을 탭할 때 눌리는 효과 추가 - 메뉴 버튼 클릭 시 전체 화면 내비게이션 오버레이 표시 - 번호가 매겨진 주석으로 여러 요소를 동시에 지정할 수 있다. - 에이전트는 표시된 정확한 위치와 설명을 함께 활용해 관련 코드 전체에 변경 사항을 적용한다. ## 프롬프트 비용과 작업 효율 - 직접 요소를 선택하면 에이전트가 수정 대상을 탐색하거나 추측할 필요가 줄어든다. - 일반적인 텍스트 프롬프트로 같은 변경을 설명하는 것보다 토큰을 적게 사용하고 더 빠르게 완료할 수 있다. - 변경 사항은 적용 전까지 크레딧을 소비하지 않고 대기한다. - 최종적으로 변경 사항을 적용할 때 크레딧이 차감되고 파일이 새 버전으로 업데이트된다. ## 디자인과 코드의 통합 - 속성 패널은 시각적 조정에, 주석은 동작과 맥락이 필요한 변경에 적합하다. - 두 기능을 통해 사용자는 코드를 직접 다루면서도 Figma와 유사한 시각적 편집 경험을 유지할 수 있다. - 같은 편집 경험은 향후 Figma Design의 코드 레이어에도 제공될 예정이다. - 장기적으로는 Figma 캔버스에서 코드 기반 결과물을 여러 방향으로 탐색하고 팀과 함께 비교하는 작업이 가능해진다. 실무에서는 간격·타이포그래피·레이아웃처럼 명확한 시각 속성은 속성 패널로 수정하고, 인터랙션이나 애니메이션처럼 의도가 중요한 변경은 주석으로 요청하는 방식이 가장 효율적이다. 적용 전 검토 단계가 제공되므로 여러 변경을 시도한 뒤 실제 코드 반영 여부를 결정하는 것도 권장된다.

design-to-codefigmafigma-makecode-connect+2

figma2026년 7월 16일

워크플로우 랩: Figma Make로 디자인을 직접 배포하기 | Figma 블로그 (새 탭에서 열림)

디자인과 개발의 핸드오프는 일방향일 필요가 없으며, 디자이너가 Figma Make에서 실제 코드베이스를 직접 수정하고 PR까지 이어지는 작업 흐름을 제안한다. 작은 접근성·사용성 개선을 티켓과 백로그에 맡기지 않고 디자이너가 직접 처리하면, 엔지니어는 대규모 아키텍처 작업에 집중하면서도 제품의 완성도를 높일 수 있다. Figma Design, Figma Make, Figma agent, GitHub 연동을 활용해 캔버스에서 검토하고 코드로 반영하는 것이 핵심이다. ## 작은 개선이 백로그에 묻히는 문제 - “간격을 조금 줄여 달라”거나 “스크린 리더가 잘못 읽는다”와 같은 수정은 중요하지만 규모가 작아 우선순위 경쟁에서 밀리기 쉽다. - 디자이너가 요구사항을 티켓으로 작성하면 엔지니어가 의도를 해석해야 하므로, 스크린샷과 설명을 주고받는 과정에서 디자인의 뉘앙스가 손실된다. - 그 결과 엔지니어는 실제 구현보다 디자이너의 결정을 번역하는 데 시간을 쓰게 된다. - 글에서는 이러한 문제를 해결하기 위해 디자이너가 저위험·고완성도 작업을 처음부터 끝까지 맡는 방식을 제안한다. ## MOSF 웹사이트의 접근성 개선 사례 - 가상의 박물관인 ‘Museum of Speculative Futures(MOSF)’가 사례로 등장한다. - 엔지니어는 대규모 정보 구조 재작성에 집중해야 하고, 디자이너는 웹사이트의 접근성 문제를 해결하려 한다. - PM은 엔지니어가 구조 개편 같은 고난도 작업을 계속 담당하고, 디자이너가 세부적인 접근성·사용성 개선을 직접 처리하도록 역할을 나눈다. - 목표는 기술적으로 동작하는 수준을 넘어, 다양한 사용자가 실제로 편리하게 사용할 수 있는 웹사이트를 만드는 것이다. ## 캔버스에서 사용자 피드백 수집 - 디자이너는 수정 전에 현재 경험을 점검하기 위해 Figma Design의 Figma agent를 사용한다. - 첫 방문자, 재방문 회원, 스크린 리더 사용자 등 여러 합성 페르소나를 생성하고 사이트를 탐색하게 한다. - 합성 페르소나는 실제 사용자 조사나 대면 테스트를 대체하지 않지만, 초기에 명백한 마찰을 발견해 후속 사용자 조사에 집중할 여지를 만든다. - 탐색 결과 다음과 같은 문제가 확인된다. - 전시 페이지의 내비게이션 라벨이 모호함 - 주요 행동 유도 버튼(CTA)이 눈에 잘 띄지 않음 - 날짜 선택기가 한눈에 이해하기 어려움 - 검색 결과가 없을 때 빈 화면만 표시됨 - 각각은 대규모 기능 변경은 아니지만, 여러 문제가 누적되면 사이트의 접근성과 사용성이 크게 떨어질 수 있다. ## 팀 검토를 거친 디자인 수정 - 디자이너는 에이전트가 발견한 문제를 바탕으로 디자인을 수정한다. - 이후 디자이너, 엔지니어, PM이 캔버스에서 변경 사항을 함께 검토한다. - 검토 대상에는 방문 페이지의 더 명확한 라벨, 눈에 잘 띄는 CTA, 사용하기 쉬운 날짜 선택기 등이 포함된다. - 디자인 단계에서 팀의 합의를 먼저 확보하므로, 코드 수정 이후에 요구사항을 다시 해석하거나 되돌리는 일을 줄일 수 있다. ## Figma Make로 실제 코드에서 작업 - 디자이너는 프로덕션 코드와 연결된 Figma Make를 사용해 캔버스의 수정 사항을 실제 코드에 반영한다. - 기존처럼 티켓을 생성해 백로그에 넣고 엔지니어가 나중에 구현하기를 기다리지 않는 것이 핵심이다. - Figma Make, GitHub 연동, 주석과 리뷰 기능을 통해 디자인 변경을 코드 변경으로 연결하고 팀 검토를 이어간다. - 최종적으로 작업은 풀 리퀘스트(PR) 단계까지 진행되며, 디자이너가 캔버스에서 시작한 개선을 병합 가능한 코드 변경으로 전달한다. - 이 방식은 엔지니어의 책임을 없애는 것이 아니라, 엔지니어가 코드 품질과 구조를 검토하는 동안 디자이너가 세부적인 사용자 경험 개선을 주도하도록 역할을 재배치한다. 작은 접근성·사용성 개선은 별도 티켓으로 쌓아두기보다, 디자이너가 실제 코드에서 직접 수정하고 엔지니어와 PR 리뷰를 진행하는 편이 효율적이다. 다만 합성 페르소나의 결과는 초기 탐색용으로 활용하고, 중요한 접근성 판단은 실제 사용자 조사와 기술 검증으로 보완하는 것이 바람직하다.

design-to-codefigmaaiaccessibility+2

figma2026년 7월 10일

Decagon이 AI를 활용해 디자인 시스템을 포화시키는 방법 | Figma 블로그 (새 탭에서 열림)

Decagon은 빠르게 성장하는 AI 고객지원 플랫폼의 품질과 개발 속도를 함께 확보하기 위해 Deco라는 디자인 시스템을 구축했다. Figma 라이브러리, Storybook, 코딩 에이전트, Figma MCP를 연결해 디자인과 코드가 지속적으로 일치하도록 만들었고, 그 결과 반복적인 해석과 수정 작업을 줄였다. 핵심은 디자인 시스템을 단순한 컴포넌트 모음이 아니라 사람과 AI 에이전트가 함께 사용하는 공통 언어로 만든 데 있다. ## 빠른 성장에 대응하는 디자인 시스템 구축 - Decagon은 초기에는 디자인 시스템 없이 빠르게 제품을 개발했지만, 플랫폼과 팀이 커지면서 화면 간 불일치와 완성도 저하가 나타났다. - 기업 고객을 대상으로 제품을 제공하기 위해서는 일관된 UI와 높은 품질이 필요했으며, 디자인과 개발 사이의 반복적인 수정 작업도 줄여야 했다. - 디자이너와 엔지니어가 처음부터 함께 Deco를 설계해 다음과 같은 세부 사항을 미리 정의했다. - 포커스 상태 - 비활성화, 읽기 전용, 오류, 경고 상태 - 플레이스홀더 사용 여부 - 기존 코드에 이미 존재하는 컴포넌트와의 관계 - 현재 Deco는 수백 개의 컴포넌트·스타일·변수를 포함하며, 여러 팀과 제품 영역의 대부분의 사용 사례를 다룬다. - Figma 라이브러리에서 30일 동안 수만 건의 컴포넌트 삽입이 발생해 조직 전반에서 실제로 활용되고 있음을 확인했다. ## 디자인 시스템이 만든 공통 언어 - 디자이너는 기존 컴포넌트로 화면을 조합할 수 있어 매번 UI를 처음부터 만들 필요가 없어졌다. - 개발자는 어떤 버튼이나 테이블을 사용해야 하는지 명확히 알 수 있어 구현상의 판단과 논쟁이 줄었다. - 디자인과 코드가 동일한 프리미티브를 기준으로 소통하면서 제품 흐름과 요구사항을 설명하기 쉬워졌다. - Deco는 조직 전체에 공개된 단일 진실 공급원(single source of truth)으로 작동해 빠른 출시와 일관된 디자인을 동시에 지원한다. ## 디자인과 코드 사이의 반복 작업 줄이기 - 기존 방식에서는 디자이너가 명세를 전달하면 개발자가 해석하고, 리뷰 단계에서 불일치를 발견한 뒤 다시 수정하는 과정이 반복됐다. - 코딩 에이전트는 개발자처럼 암묵적인 의도를 추론하지 않고 제공된 정보만 바탕으로 작업하므로, 디자인 파일과 명세가 불명확하거나 일관되지 않으면 결과물도 부정확해진다. - Decagon은 디자인 시스템 컴포넌트를 Storybook으로 옮겨 코드에서도 동일한 컴포넌트를 확인할 수 있게 했다. - 코딩 에이전트가 구현할 때 정확한 Deco 컴포넌트를 사용하도록 별도의 skill을 만들었다. - 디자이너가 새로운 컴포넌트를 추가할 때 사용하는 skill도 구축해 Figma와 코드의 동기화를 유지했다. ## Figma MCP를 통한 에이전트 활용 - Figma MCP를 사용하면 코딩 에이전트가 Figma의 디자인 문맥과 명세를 직접 읽을 수 있다. - 디자이너는 Figma 링크를 코딩 에이전트에 전달하는 것만으로 다음 작업을 수행할 수 있다. - 디자인의 구조와 세부 명세 파악 - Deco의 적합한 컴포넌트와 매핑 - 디자인에 가까운 고충실도 구현 생성 - 디자인 캔버스, 코드, 컴포넌트 명세가 하나의 작업 흐름으로 연결되어 파일을 내보내고 다시 해석하는 수동 왕복이 줄었다. - 에이전트가 기존 디자인 시스템을 활용하므로 빠른 프로토타이핑과 반복 수정이 가능하면서도 브랜드와 UI 일관성을 유지할 수 있다. ## 실용적인 결론 AI 코딩 도구를 도입할 때는 에이전트의 성능만 높이기보다, 먼저 재사용 가능한 디자인 시스템과 명확한 컴포넌트 문맥을 마련해야 한다. Figma와 Storybook을 연결하고, MCP와 에이전트 skill을 통해 동일한 컴포넌트를 사용하게 하면 디자인-개발 간 불일치를 줄이면서 빠른 개발 속도와 품질을 함께 확보할 수 있다.

design-to-codefigmadesign-systemsai-agent+2

figma2026년 7월 9일

GPT-5.6이 이제 Figma Make에서 사용 가능합니다 | Figma 블로그 (새 탭에서 열림)

GPT-5.6이 Figma Make에 추가되어 프롬프트에서 프로토타입과 코드로 전환하는 속도와 첫 결과물의 품질을 높인다. 복잡한 앱도 한 번의 프롬프트로 만들고, 오류가 발생하면 모델이 원인을 찾아 스스로 수정할 수 있다. 또한 기존 Figma 디자인을 높은 충실도로 인터랙티브 프로토타입으로 변환하며, 반응형 레이아웃과 실제 동작하는 상호작용까지 구현한다. ## 빠른 프로토타이핑과 작업 흐름 유지 - GPT-5.6은 아이디어를 working build로 빠르게 전환해 한 번의 작업 세션에서 여러 방향을 탐색할 수 있도록 한다. - 복잡한 디자인에서도 첫 결과물을 빠르게 생성하며, 토큰 효율성도 높다고 소개된다. - 예시로 금융·고딕 스타일의 주식 추적 앱을 한 번의 프롬프트로 제작했다. - 어두운 배경과 앰버·네온 오렌지 텍스트 - 샘플 주가와 수익률 정보 - 스파크라인, 티커, 모듈형 그리드 - 키보드 단축키와 검색 기능 - 빌드 중 오류가 발생해도 작업을 중단하지 않고 원인을 조사해 자체적으로 수정한다. - 실제 테스트에서는 빈 화면이 나타난 원인을 GPT-5.6이 찾아 해결했다. ## 기존 디자인을 충실하게 구현 - Figma Design 파일이나 디자인 명세를 기반으로 기존 시각적 구조를 유지하면서 인터랙티브 프로토타입을 만들 수 있다. - 자연의 소리를 재생하는 오디오 플레이어 사례에서 다음 요소들이 원본 디자인과 유사하게 구현됐다. - 다중 트랙 타임라인 - 재생·일시정지·이전·다음 컨트롤 - 사운드 라이브러리와 아트워크 - 레이아웃, 시각적 계층, 간격, 비율, 스타일 - 정적인 디자인을 실제 동작하는 프로토타입으로 바꾸는 디자인-투-코드 작업을 보다 안정적으로 수행한다. - 오디오 파일 재생뿐 아니라 음악에 반응하는 셰이더 기반 이미지 왜곡 효과도 요청할 수 있다. ## 높은 완성도의 첫 결과물 - 최소한의 프롬프트만으로도 스타일이 정돈된 프로토타입을 생성하는 것이 목표다. - 책장 제품을 판매하는 콘텐츠 중심의 이커머스 페이지 사례에서는 다음 기능이 첫 결과물에 포함됐다. - 제품 설명, 치수, 관리 가이드 - 제품 정보가 채워진 드롭다운 - 책장 사진을 탐색하는 인터랙티브 이미지 갤러리 - 클릭 가능한 메뉴 - 별도의 추가 지시 없이도 화면 크기에 따라 레이아웃이 안정적으로 조정됐다. - 따라서 초기 결과물을 단순한 시안이 아니라 팀이 검토·수정·확장할 수 있는 출발점으로 활용할 수 있다. ## Figma Make에서의 사용 방법 - GPT-5.6은 Figma Make에서 제공된다. - Make의 모델 선택기에서 GPT-5.6을 선택해 사용할 수 있다. - 사용자는 거친 아이디어, 기존 Figma 디자인, 짧은 기능 설명 등을 입력해 프로토타입이나 생산 코드에 가까운 결과물을 생성할 수 있다. 실무에서는 먼저 기존 디자인이나 원하는 사용자 경험을 구체적으로 제공하고, 생성된 첫 결과물을 기반으로 세부 기능과 스타일을 반복 수정하는 방식이 효과적이다. 특히 반응형 동작, 실제 인터랙션, 오류 자동 수정 기능을 활용하면 초기 프로토타입 제작과 팀 리뷰까지의 시간을 줄일 수 있다.

design-to-codeprototypingfigma-makeresponsive-design+3

figma2026년 6월 29일

어디서든 시작하세요, Figma가 만든 매거진 | Figma 블로그 (새 탭에서 열림)

새로운 도구와 재료의 등장으로 디자인은 더 이상 정해진 출발점에서 시작할 필요가 없으며, 누구나 아이디어에 맞는 방식으로 작업을 시작할 수 있다. Figma의 2026년 Config 매거진은 모션, 코드, AI를 디자인 캔버스 안으로 통합하면서 디자인의 표현력과 협업 방식을 확장하는 흐름을 조명한다. 핵심은 도구가 쉬워질수록 기본 원리와 호기심, 지속적인 탐구가 더욱 중요해진다는 것이다. ## 디자인은 어디에서든 시작할 수 있다 - Figma는 Config 2026을 맞아 디자인의 현재를 보여주는 인쇄 매거진을 제작했다. - 매년 주제와 기고자, 디자인은 달라지지만, “지금 디자인이 어떤 모습인가”를 아름다운 인쇄물로 표현한다는 목표는 유지된다. - 빠르게 변하는 제품과 기술 환경에서는 글이 출간될 때 이미 새로운 버전이 나올 수 있다. - 이런 변화 속에서도 오래 남는 것은 다음과 같은 태도다. - 무엇을 하는지 설명하기 전에 그것이 무엇인지 이해하려는 자세 - 새로운 도구의 가능성을 성급히 단정하지 않는 인내심 - 서로 다른 도구와 재료가 어떻게 연결될지 탐구하는 호기심 - 매거진은 초보자, 숙련된 실무자, 단순히 좋은 결과물을 빠르게 만들고 싶은 사람 모두를 독자로 삼는다. - 세 가지 표지는 각각 다른 질문과 출발점을 제시하지만, 결국 같은 주제를 향해 계속 탐구하도록 유도한다. ## 모션이 캔버스에 들어오다 - Figma Motion은 타임라인을 Figma 캔버스 안에 제공한다. - 모션 작업이 기존 컴포넌트, 변수, 팀 협업 환경과 같은 파일 안에서 이루어질 수 있다. - 디자이너는 제품이 완성된 뒤 애니메이션을 추가하는 것이 아니라, 초기 단계부터 시간과 움직임을 설계할 수 있다. - 모션 디자인에서는 도구 사용이 쉬워져도 기본 원리가 중요하다. - 움직임의 속도와 타이밍 - 시각적 전환이 전달하는 의미 - 움직임을 통해 사용자 경험을 조직하는 방식 - Figma는 Brand Studio의 모션 디자이너들과 함께, “시간을 디자인한다”는 것이 무엇인지 설명한다. ## 코드와 디자인의 경계가 좁아지다 - 코드는 오래전부터 디자인 과정의 재료였지만, 기존에는 디자인 도구와 분리된 환경에 놓여 있었다. - Figma는 코드 레이어를 디자인 캔버스에 도입해 코드와 시각적 디자인을 같은 멀티플레이어 공간에서 다룰 수 있도록 한다. - 팀은 여러 코드 기반 방향을 나란히 탐색하고 비교할 수 있다. - 디자인에서 코드로 일방향 전달하는 방식보다, 코드와 캔버스 사이를 반복적으로 오가는 작업 흐름이 가능해진다. - 이러한 변화는 디자인과 개발의 역할을 단순히 합치는 것이 아니라, 아이디어를 시험하고 발전시키는 경로를 늘린다. ## 디자인-코드 순환이 만드는 새로운 가능성 - 코드와 캔버스 사이의 이동이 자연스러워지면서 디자인과 개발 워크플로가 서로 수렴한다. - Figma 소프트웨어 엔지니어 Alex Kern과 AI 디자인 디렉터 Gui Seiz는 연결된 작업 방식이 무엇을 가능하게 하는지 논의한다. - 디자인 결과물을 코드로 넘기는 마지막 단계만 자동화하는 것이 아니라, 아이디어 구상과 구현 과정 전체가 연결된다. - 이를 통해 팀은 다음을 더 빠르게 반복할 수 있다. - 여러 제품 방향의 실험 - 디자인과 실제 구현의 비교 - 팀원 간 피드백과 수정 - 아이디어를 프로덕션에 가까운 형태로 검증 ## AI가 아이디어에서 제품까지의 과정을 바꾸다 - AI 도구는 팀이 제품을 시작하는 지점뿐 아니라, 아이디어가 실제 제품으로 이어지는 방식까지 바꾸고 있다. - 변화는 특정 도구 하나의 도입보다 전체 프로세스의 재구성에 가깝다. - 매거진은 네 조직의 사례를 통해 AI를 활용해 아이디어를 제품으로 발전시키는 새로운 접근법을 소개한다. - AI는 초기 아이디어 생성, 방향 탐색, 프로토타이핑, 제작 단계 간의 연결을 강화할 수 있다. - 다만 AI가 디자인 판단을 대신한다기보다, 사람이 더 많은 가능성을 빠르게 탐색하고 선택하도록 돕는 역할에 초점이 맞춰져 있다. ## 인간과 AI의 미래적 상호작용 - 매거진의 “Future states” 섹션은 기계 지능과 인간 지능의 간극이 좁아졌을 때의 가능성을 상상한다. - 커뮤니티 구성원들은 AI가 소프트웨어를 더 인간적인 방식으로 만들 수 있다고 제안한다. - 예시로 다음과 같은 방향이 제시된다. - 사용자의 감정이나 상태를 이해하는 인터페이스 - 사용자의 선택이 어떤 결과로 이어질지 예측하는 시스템 - 인간의 맥락과 의도를 더 깊이 파악하는 소프트웨어 - 이는 AI를 단순한 자동화 도구가 아니라, 인간의 의사결정과 상호작용을 보조하는 새로운 인터페이스 재료로 바라보는 관점이다. 새로운 도구를 익히는 가장 좋은 방법은 완벽한 출발점을 기다리기보다 작은 아이디어에서 바로 시작해 보는 것이다. 모션, 코드, AI를 기존 디자인 과정에 단계적으로 결합하되, 도구보다 디자인 원리와 사용자 경험에 대한 판단을 중심에 두는 것이 바람직하다.

design-to-codefigmaaireact+1

figma2026년 6월 24일

Config 2026: 새로운 소재, 새로운 도구, 더욱 표현력 있는 캔버스 | Figma 블로그 (새 탭에서 열림)

Figma Config 2026의 핵심 방향은 캔버스를 단순한 디자인 작업 공간이 아니라 코드·모션·셰이더·생성형 플러그인 등을 함께 다루는 창작 환경으로 확장하는 것이다. Figma는 AI가 작업의 진입장벽은 낮췄지만 창작의 한계를 넓히는 것은 결국 디자이너와 크리에이터의 몫이라고 강조한다. 이를 위해 디자인과 코드의 경계를 없애고, 더 풍부한 표현과 협업을 캔버스 안에서 가능하게 하려 한다. ## 디자인 캔버스의 확장 - Figma는 이미지, 벡터, 디자인 레이어뿐 아니라 코드와 모션도 디자인 재료로 취급하려 한다. - 코드·모션·셰이더·생성형 플러그인·Weave 도구를 하나의 캔버스에서 조합하는 것이 이번 Config의 주요 방향이다. - 캔버스는 결과물이 저장되는 장소를 넘어, 아이디어를 연결하고 동료와 함께 반복적으로 발전시키는 협업 공간으로 정의된다. - AI가 창작의 진입장벽을 낮췄다면, 더 높은 수준의 창의성과 과감한 시도는 사용자가 만들어야 한다는 관점을 제시한다. ## 코드 레이어로 디자인과 개발 통합 - 기존의 “디자인 대 코드”라는 구분은 인위적인 논쟁이며, 코드는 이미지나 벡터와 같은 디자인 재료라는 것이 Figma의 주장이다. - Figma Design의 모든 디자인 레이어를 클릭 한 번 또는 프롬프트로 인터랙티브한 코드 레이어로 변환할 수 있다. - 코드 레이어를 복제해 여러 구현 방향을 나란히 비교하고 탐색할 수 있다. - 일반적인 Figma 캔버스처럼 팀원이 같은 파일에서 코드를 수정하고, 의견을 남기고, 반복 작업을 진행할 수 있다. - 코드로 만든 결과물을 다시 편집 가능한 디자인 레이어로 추출할 수 있다. - 디자인 레이어를 수정한 뒤에는 한 번의 클릭으로 변경 사항을 코드 레이어에 반영할 수 있어 디자인과 구현 사이를 양방향으로 오갈 수 있다. - 코드 레이어의 얼리 액세스는 7월부터 시작될 예정이며, 베타 대기자 등록을 통해 참여할 수 있다. ## Figma Motion으로 디자인에 움직임 추가 - Figma Design 안에 타임라인 기반의 모션 제작 기능이 추가된다. - 키프레임과 프리셋을 사용해 처음부터 애니메이션을 만들거나, 기존 디자인에 모션을 덧입힐 수 있다. - Figma agent를 이용해 애니메이션의 초기 시안을 생성할 수도 있다. - 모션 디자이너에게는 반복적인 작업을 줄이고, 창의적인 표현에 더 집중할 수 있는 환경을 제공한다. - 애니메이션을 컴포넌트에 한 번 정의하면 여러 화면과 협업자의 파일에서 디자인 시스템의 일부처럼 재사용할 수 있다. ## 모션과 개발 도구의 연결 - Dev Mode에서는 전체 타임라인을 확인하고 검사할 수 있다. - 각 키프레임, 타이밍 값, 이징 곡선을 별도의 해석 없이 읽을 수 있다. - 애니메이션 코드를 CSS, JSON 또는 React 프레임워크용 코드로 직접 복사할 수 있다. - MCP와 호환되므로 애니메이션이 적용된 프레임을 코딩 에이전트로 전달해 구현할 수 있다. - 결과물은 MP4, WebM, Animated SVG, GIF 등으로 내보낼 수 있으며, 향후 더 많은 포맷이 추가될 예정이다. Figma Config 2026은 디자인·개발·모션을 별도 도구로 분리하기보다 하나의 협업 캔버스에서 연결하려는 흐름을 보여준다. 특히 코드 레이어와 Figma Motion은 디자이너가 구현 가능성을 즉시 실험하고, 개발자는 디자인 의도와 애니메이션 세부 정보를 정확히 확인하도록 돕는 기능으로 볼 수 있다.

design-to-codefigmagen-aireact+3

figma2026년 6월 24일

피그마 캔버스에서 코딩하기 | 피그마 블로그 (새 탭에서 열림)

Figma는 코드 레이어를 통해 실행 가능한 코드를 디자인 캔버스 안에서 생성·비교·수정할 수 있도록 한다. 디자이너와 개발자는 코드와 디자인을 오가는 대신 같은 Figma 파일에서 아이디어를 함께 탐색하고, 팀의 피드백을 반영하며, 최종 코드를 저장소에 반영할 수 있다. 코드 레이어는 디자인과 개발의 경계를 좁혀 협업 중심의 프로토타이핑을 가능하게 하는 기능이다. ## 캔버스에서 코드 시작하기 - Figma Design의 툴바에서 코드 레이어를 추가하거나, 기존 프레임을 코드로 변환할 수 있다. - Figma Agent에게 원하는 결과를 설명해 코드를 생성할 수도 있다. - 템플릿에서 시작하거나 직접 만들고 싶은 내용을 프롬프트로 입력할 수 있다. - GitHub 저장소를 가져오거나 로컬 폴더를 업로드해 기존 코드베이스를 불러올 수 있다. - Figma Make에서 생성·수정한 코드도 캔버스의 코드 레이어로 가져와 팀과 공유할 수 있다. ## 여러 대안을 나란히 비교하기 - 기존 프레임을 복제해 여러 디자인 방향을 시험하듯 코드 레이어도 복제해 대안을 만들 수 있다. - 실제로 작동하는 화면을 캔버스에서 비교하므로 정적인 시안만 볼 때보다 사용 경험을 구체적으로 평가할 수 있다. - 요소를 이동·조정·리사이즈하면 코드에 즉시 반영된다. - 프롬프트로 새 버전을 생성하면서도 기존 버전은 보존할 수 있다. - 팀원은 공유 파일 안에서 댓글을 남기거나 동일한 코드 레이어를 대상으로 Agent에 추가 작업을 요청할 수 있다. ## 코드와 디자인 레이어 오가기 - `Extract designs` 기능을 사용하면 코드의 현재 상태를 편집 가능한 Figma 레이어로 변환할 수 있다. - 전체 화면뿐 아니라 특정 화면, 상태, 사용자 플로우만 선택해 캔버스로 가져올 수 있다. - 코드로 구현된 인터랙션과 상태를 시각적으로 분석하고, 일반적인 Figma 디자인 요소처럼 편집할 수 있다. - 캔버스에서 수정한 내용은 한 번의 클릭으로 코드 레이어에 업데이트할 수 있어 디자인과 구현 사이의 반복 작업이 짧아진다. ## 코드 편집과 저장소 반영 - 코드 에디터에서 원하는 변경 사항을 주석이나 설명으로 작성하고 Agent에게 수정을 요청할 수 있다. - 필요하면 개발자가 직접 코드를 편집할 수도 있다. - 수정 결과를 다시 코드 레이어로 변환해 팀에 공유할 수 있다. - 최종적으로 확정한 변경 사항은 저장소에 push해 실제 소스 코드에 반영할 수 있다. - 따라서 Figma 캔버스는 단순한 시각화 공간이 아니라, 아이디어 탐색부터 코드 변경 및 공유까지 이어지는 협업 환경이 된다. ## 출시 계획 - 코드 레이어는 2026년 6월 기준 향후 몇 주 동안 비공개 베타로 제공될 예정이다. - 초기 접근 권한은 Figma의 베타 신청 페이지를 통해 요청할 수 있다. - 기능 세부 사항과 Config에서 발표된 다른 업데이트는 Figma Help Center와 Figma Learn에서 확인할 수 있다. 실무에서는 코드 레이어를 최종 구현을 자동화하는 도구라기보다, 디자인·개발팀이 여러 구현안을 빠르게 실험하고 합의하는 공동 프로토타이핑 환경으로 활용하는 것이 적합하다. 특히 기존 코드베이스를 불러와 실제 동작을 검토한 뒤 디자인과 코드를 반복적으로 조정하는 워크플로에 유용하다.

design-to-codefigmaai-agentreact+2

toss2026년 6월 16일

디자이너가 시안 대신 앱을 만든 이유 (새 탭에서 열림)

AI를 활용하면 디자이너가 정적인 시안을 넘어 실제로 동작하는 프로토타입을 직접 만들 수 있고, 디자인과 개발 사이의 번역 과정도 줄어든다. 토스의 underlay 프로젝트는 화면 위에 겹치는 대신 화면 아래에 있던 정보가 드러나는 방식을 통해, 사용자의 흐름을 방해하지 않고 다음 경험으로 연결하려 했다. 이 과정에서 동작하는 코드 자체가 디자인 명세이자 개발 가능한 구조가 될 수 있음을 보여준다. ## 데드엔드를 다음 경험의 시작으로 바꾸기 - 송금 완료나 결제 완료처럼 사용자의 할 일이 끝나는 화면을 ‘데드엔드’로 정의했다. - 목표는 특정 화면을 개선하는 것이 아니라, 앱 어디서든 현재 경험을 자연스럽게 다음 경험으로 연결하는 공통 장치를 만드는 것이었다. - 이를 위해 여러 화면에서 재사용할 수 있는 컴포넌트 개발부터 시작했다. ## 기존 알림 UI의 한계와 underlay의 발상 - 바텀시트, 토스트, 푸시 등 기존 UI는 화면 위에 나타나 사용자의 시선을 끌지만, 보고 있던 화면이나 진행 중인 행동을 방해할 수 있다. - 전화처럼 등장하거나 화면 한쪽·채팅창처럼 나타나는 방식도 같은 문제를 가졌다. - 택배 송장을 떼자 아래에 있던 책의 문구가 드러난 경험에서 아이디어를 얻었다. - 새로운 정보를 화면 위에 올리는 대신, 화면 아래에 존재하던 정보가 드러나게 하는 컴포넌트를 **underlay**라고 정의했다. ## AI와 코드로 인터랙션을 디자인하기 - underlay는 외형보다 움직임과 반응 방식이 중요한 컴포넌트였다. 인터랙션 자체가 디자인의 핵심이었다. - 프로토파이나 프레이머 대신 SwiftUI와 Xcode로 iOS 앱 형태의 프로토타입을 직접 만들었다. - SwiftUI를 처음 사용했지만 AI에게 구현을 요청하며 디자인을 구체화했다. - 디자이너의 역할은 다음 세 가지로 정리됐다. - 만들고 싶은 경험을 설명하기 - AI가 제안한 여러 방향 중 적절한 것을 선택하기 - 실제 기기에서 결과를 보고 판단하기 - AI와의 디자인 과정은 설계, 선택, 검증을 반복하는 과정이었다. ## 실제 기기에서 반복하며 완성도 높이기 - 먼저 자유롭게 실험하고 지울 수 있는 플레이그라운드 환경을 만들고, 피그마 시안을 AI에게 참고 자료로 제공했다. - 버튼, 텍스트, 레이아웃을 정지 화면이 아니라 실제 기기에서 움직여 보며 수정했다. - 상상한 움직임과 실제 구현된 움직임의 차이가 컸기 때문에 수백 번 반복해서 조정했다. - 화면의 맥락을 읽고 적절한 정보를 찾는 느낌을 표현하기 위해 빛이 화면을 훑는 스캔 인터랙션을 도입했다. - 빛의 번짐, 틴트, 폭, 속도, 배경 어두워짐 등은 Metal 셰이더로 구현했다. - AI가 작성한 셰이더 코드를 출발점으로 삼되, 최종 질감은 직접 수치를 조정하며 완성했다. - 등장하거나 스캔이 지나갈 때의 미세한 출렁임 같은 디테일도 코드로 다듬었다. ## 디자인 가이드 대신 동작하는 레포 전달하기 - 기존 방식이라면 등장 타이밍, 이징 커브, 딜레이 등을 문서로 정리했을 것이다. - 이번에는 간단한 플로우만 설명하고, 직접 만든 코드 레포를 개발자에게 전달했다. - 동작하는 레퍼런스가 있었기 때문에 개발자는 시안의 구조와 인터랙션을 빠르게 이해할 수 있었다. - 개발 과정의 파인튜닝에서도 opacity나 모션 값을 말로 주고받기보다, 디자이너가 직접 실행 결과를 보며 수정했다. - AI에게 원하는 모션을 자연어로 설명하고 결과를 확인하는 과정을 개발자의 환경에서도 반복하면서 인터랙션 완성도를 높였다. - “느낌이 이상하다”는 추상적 표현 대신 실제 코드와 동작을 기준으로 소통할 수 있었다. ## 시각적 결과뿐 아니라 코드 구조까지 디자인하기 - 프로토타입 레포의 구조가 실제 iOS 개발 코드와 거의 동일하게 활용됐다. - 처음부터 개발을 위한 구조를 의도한 것은 아니었지만, UT와 빠른 버전 변경을 위해 만든 구조가 자연스럽게 개발 가능한 형태가 됐다. - 잘 만든 시안은 보기 좋은 화면에 그치지 않고, 재사용·수정·확장이 가능한 방식으로 만들어져야 한다. - 일회용 코드라면 개발자가 다시 구현해야 하지만, 개발 가능한 구조의 시안은 그대로 구현 명세가 될 수 있다. - AI가 “어떻게 만들지”를 지원하는 시대에는 디자이너가 “무엇을 만들지” 상상하고 결정하는 역량이 더 중요해진다. ## 적용 방법 - 도구의 제약에 맞춰 디자인하기보다, 가장 좋은 사용자 경험을 먼저 상상한다. - 정적인 그림으로 끝내지 말고 AI와 코드를 활용해 실제 기기에서 작동하는 프로토타입을 만든다. - 인터랙션을 문서로만 설명하기보다, 직접 만든 동작하는 레포를 개발자에게 전달한다. - 최종 결과뿐 아니라 코드 구조와 수정 가능성까지 디자인의 일부로 고려한다. 실용적으로는 작은 인터랙션부터 SwiftUI나 웹 기술로 직접 구현해 보고, 실제 기기에서 반복 검증하는 방식이 효과적이다. 완성된 코드는 단순한 시안이 아니라 개발자와 AI 모두가 이해할 수 있는 실행 가능한 디자인 스펙이 될 수 있다.

design-to-codefigmaiosinteraction-design+3

figma2026년 5월 28일

Figma Make, 이제 로컬 코드에서 | Figma 블로그 (새 탭에서 열림)

Figma Make은 디자인, 프로토타이핑, 실제 코드 배포 사이의 경계를 허물고, Figma 안에서 로컬 코드베이스를 직접 수정·검토·공유할 수 있도록 확장된다. 사용자는 화면 요소를 시각적으로 편집하거나 자연어 주석으로 동작을 변경하고, Git 브랜치·커밋·PR 흐름을 통해 안전하게 배포할 수 있다. 궁극적으로 Figma는 디자인 캔버스와 코드베이스를 하나의 협업 환경으로 통합하려 한다. ## 로컬 코드베이스의 시각적 편집 - Figma Make를 회사의 코드베이스에 연결하면 Figma 안에서 실제 UI를 직접 수정할 수 있다. - 화면 요소를 선택해 다음 속성을 변경할 수 있다. - 레이아웃 - 색상 - 글꼴 - 크기 - 기타 시각적 속성 - Make의 에이전트가 사용자의 시각적 변경에 대응하는 코드를 찾아 수정한다. - 이미 원하는 결과가 명확한 속성 변경에는 직접 편집 기능을 사용한다. - 현재는 코드베이스 접근 권한이 있는 디자이너에게 적합하며, 비기술 사용자를 위한 설정 과정은 계속 개선 중이다. ## 주석과 프롬프트를 활용한 동작 변경 - 단순한 속성 변경을 넘어 상호작용이나 애니메이션을 수정할 때는 화면 요소에 주석을 달 수 있다. - 주석에는 원하는 동작을 자연어로 설명할 수 있다. - 여러 요소를 한 번에 참조할 수 있어 에이전트에 구체적인 맥락을 전달한다. - 직접 편집과 일반적인 채팅 프롬프트 사이의 유연한 작업 방식으로 활용된다. - 예를 들어 버튼의 클릭 동작, 화면 전환, 애니메이션 로직 등을 설명해 코드에 반영할 수 있다. ## 브랜치·커밋·PR 기반 배포 - 프로덕션 코드는 팀의 개발 프로세스를 거쳐 의도적으로 배포하도록 설계됐다. - PR을 열기 전 변경 사항은 로컬 커밋으로 저장된다. - Make 안에서 Git 작업을 수행할 수 있다. - 브랜치 생성 - 커밋 확인 - 커밋 되돌리기 - 변경 이력 검토 - PR 생성 - 엔지니어링 팀은 일반적인 코드 변경과 동일하게 Make의 변경 사항을 리뷰할 수 있다. ## 디자인과 코드의 협업 및 왕복 작업 - 로컬 코드베이스의 변경 사항을 파일과 브랜치 단위로 팀원에게 공유할 수 있다. - 팀원은 공유받은 브랜치를 체크아웃해 변경 내용을 확인하고 추가 작업을 진행한다. - 커밋 이력을 통해 변경 전후를 비교할 수 있다. - Make에서 만든 화면·페이지·컴포넌트를 Figma 캔버스의 레이어로 복사할 수 있다. - Figma 캔버스에서 팀원과 의견을 나누고, Figma 에이전트와 함께 디자인을 수정할 수 있다. - 디자인 변경 사항은 다시 Make로 가져와 코드에 적용할 수 있다. - 이를 통해 다음과 같은 왕복 흐름을 지향한다. - Make에서 코드 기반 화면 제작 - Figma Design에서 검토·편집·협업 - 결정된 디자인을 다시 코드에 반영 ## 베타 출시 범위 - 직접 편집, 주석, 채팅, PR 생성 기능은 2026년 5월 28일부터 제한적 베타로 제공된다. - 베타 기간에는 AI 크레딧을 차감하지 않는다. - 정식 AI 크레딧 요금은 추후 공개될 예정이다. - 초기 베타는 Mac용 Figma Beta 데스크톱 앱에서만 제공된다. - 대기자 등록이 베타 접근을 보장하지는 않으며, 선정된 사용자에게 별도 이메일이 발송된다. - 향후 다른 플랫폼으로 확대할 계획이다. Figma Make는 디자인 도구와 IDE를 대체로 구분하기보다, 작업 단계에 따라 두 환경을 연결하는 방향을 택했다. 현재는 Mac 베타와 코드 접근 권한 등 제약이 있지만, Git 기반 리뷰 프로세스와 Figma 캔버스 협업이 안정화된다면 디자이너와 개발자가 실제 제품 코드를 함께 발전시키는 실용적인 워크플로가 될 수 있다.

design-to-codeai-agentcollaborationfigma-make+3

figma2026년 5월 26일

이슈 16호: 프로세스를 믿으세요 | Figma 블로그 (새 탭에서 열림)

AI와 에이전트 도구의 발전으로 디자인과 개발 workflow가 빠르게 결합되고 있다. 하지만 제작 속도보다 중요한 것은 올바른 방향을 선택하고, 실제로 가치 있는 결과물을 출시하는 판단력이다. 이 글은 Figma의 MCP, Weave, 디자인-코드 왕복 작업 등을 통해 속도·맥락·완성도를 함께 높이는 방법을 소개한다. ## 빠른 제작보다 중요한 출시 판단 - AI는 제품 아이디어와 결과물을 빠르게 만들어 주지만, 잘못된 방향으로 빠르게 나아갈 위험도 키운다. - “충분히 괜찮은 결과물”에 머무르지 않고, 경쟁 제품과 차별화되는 결과를 만들려면 무엇을 출시할지 판단하는 능력이 필요하다. - Figma의 Chief Product Officer Yuhki Yamashita는 AI 시대의 제품팀이 터널 비전을 피하고, 사용자와 제품에 실질적인 가치를 주는 방향을 검증해야 한다고 설명한다. ## MCP로 디자인 맥락을 코드에 연결 - Model Context Protocol(MCP)은 에이전트형 코딩 도구가 Figma 파일과 디자인 시스템의 정보를 활용하도록 해준다. - 코드 작성 도구가 컴포넌트, 스타일, 레이아웃 등 디자인 의도를 직접 참고할 수 있어 디자인과 구현 사이의 불일치를 줄인다. - Figma MCP 서버는 디자인 결정이 코드가 작성되는 환경으로 전달되도록 하며, 결과적으로 실제 구현물이 원래 디자인에 더 가까워진다. - 디자이너와 개발자는 MCP가 제공하는 맥락을 더 구조화하고 명확하게 관리할수록 에이전트의 결과 품질을 높일 수 있다. ## Figma Weave를 활용한 시각 자산 제작 - Figma Weave는 영상, 사진, 일러스트레이션, 3D 효과 등 다양한 시각 작업에서 AI 이미지 생성과 정밀한 편집을 지원한다. - 단순히 프롬프트 하나로 이미지를 생성하는 것이 아니라, 시각적 언어와 제작 규칙을 반복적으로 적용하는 workflow가 중요하다. - 두 개의 참고 이미지만으로도 전체 자산 라이브러리를 확장할 수 있으며, 20개 이상의 workflow 템플릿이 이를 지원한다. - 주요 작업 방식은 다음과 같다. - 이미지 생성 - 기존 이미지 편집 - 프롬프트의 구조와 의도 조정 - 여러 자산에 일관된 스타일 적용 - 반복 가능한 시각 제작 프로세스 구축 ## 디자인과 코드의 왕복 작업 - 오늘날 팀은 캔버스에서 코드를 만들고, 코드에서 다시 캔버스로 돌아오는 방식으로 작업한다. - 디자인과 개발이 분리된 순차 과정이 아니라 서로 영향을 주고받는 반복 루프로 변하고 있다. - 실제 제품 상태를 디자인 캔버스로 가져오면 디자이너가 정적인 목업이 아니라 실제로 출시될 화면과 상호작용을 다듬을 수 있다. - 이러한 왕복 작업은 다음 효과를 준다. - 디자인과 코드 사이의 간극 축소 - 구현 결과에 대한 빠른 피드백 - 제품 상태와 예외 상황을 디자인에 반영 - 개발 속도를 유지하면서도 완성도 향상 ## 실무 workflow와 생산성 팁 - Figma MCP를 활용해 비디오 export flow의 문제를 점검하고, 실제 제품 상태를 캔버스에 반영하는 사례가 소개된다. - 팀이 빠르게 제작할수록 디자인과 코드가 서로 다른 방향으로 움직일 가능성도 커지므로, 두 환경을 연결하는 장치가 중요하다. - Figma Make를 자주 사용하는 사용자를 위해 크레딧을 효율적으로 사용하고 작업 속도를 높이는 7가지 팁도 제공된다. - AI 도구의 활용도는 단순 사용 횟수보다 프롬프트 품질, 맥락 제공, 반복 가능한 프로세스 설계에 좌우된다. AI 도구를 도입할 때는 생성 속도만 평가하지 말고, 디자인 맥락이 코드까지 전달되는지, 결과를 반복적으로 개선할 수 있는지, 실제 출시 가치가 있는지를 함께 검토하는 것이 좋다. Figma MCP와 Weave 같은 도구를 활용하되, 최종 방향과 품질 기준은 사람이 명확히 관리해야 한다.

design-to-codefigmaaimodel-context-protocol+2

figma2026년 5월 12일

디자인-코드 루프가 열어 주는 가능성 | Figma 블로그 (새 탭에서 열림)

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

design-to-codefigmadesign-systemsgen-ai+2

figma2026년 4월 30일

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

design-to-codedesign-systemsai-agentclaude-code+1

figma2026년 4월 15일

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

design-to-codefigmaaidesign-systems+3

figma2026년 2월 26일

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

design-to-codefigmadesign-systemsmodel-context-protocol+2

figma2026년 2월 16일

디자인의 미래는 코드와 (새 탭에서 열림)

AI 시대의 디자인은 코드와 캔버스 중 하나를 선택하는 것이 아니라, 두 방식을 오가며 가능성을 탐색하는 방향으로 발전한다. Figma는 Claude Code와의 MCP 연동을 통해 코드로 만든 결과물을 편집 가능한 Figma 레이어로 변환하고, 디자인 수정 사항을 다시 코드에 반영하는 워크플로를 제시한다. 이를 통해 개발 과정에서 첫 번째 결과물에 매몰되지 않고 여러 대안을 시각적으로 비교·검토할 수 있다는 것이 글의 결론이다. ## 코드와 캔버스의 결합 - 제품을 만드는 방식은 코드, 프롬프트, 시각적 UI, 손그림 등 어디에서든 시작할 수 있다. - 중요한 것은 특정 도구를 고집하는 것이 아니라, 아이디어를 발전시키는 데 적합한 도구를 선택하는 것이다. - 코드는 빠르게 실행 가능한 결과물을 만들고, 캔버스는 다양한 가능성을 시각적으로 탐색하고 비교하는 데 강점이 있다. - 따라서 디자인과 개발은 경쟁 관계가 아니라 서로의 장점을 보완하는 관계가 된다. ## Claude Code와 Figma MCP 연동 - Figma MCP를 설치하면 Claude Code에서 “Send this to Figma”와 같은 명령으로 작업물을 Figma로 보낼 수 있다. - 브라우저에 렌더링된 현재 상태를 분석해 Figma의 편집 가능한 레이어로 자동 변환한다. - 코드로 구현된 화면을 단순 이미지로 가져오는 것이 아니라, Figma 안에서 요소를 개별적으로 수정할 수 있다. - Figma에서 다듬은 디자인 변경 사항은 다시 MCP를 통해 코드베이스에 반영할 수 있다. - Claude Code는 Figma MCP와 연결되는 여러 에이전트 도구 중 하나로 소개된다. ## 캔버스가 제공하는 탐색 능력 - IDE나 프롬프트 환경에서는 하나의 구현 방향을 빠르게 밀어붙이기 쉽다. - Figma 캔버스에서는 여러 디자인 시안을 나란히 배치해 차이점을 비교할 수 있다. - 전체 화면의 구조와 사용자 경험을 한눈에 파악하면서 세부 요소는 직접 조작해 수정할 수 있다. - AI가 표현 가능한 수많은 결과물을 만들어낼수록, 최종적으로 좋은 방향을 선택하는 디자인 감각과 관점이 더 중요해진다. ## 선형적 개발 프로세스의 변화 - 과거에는 일반적으로 아이디어 구상 → 디자인 → 코딩 순서로 작업이 진행됐다. - 이제는 터미널에서 구현을 시작한 뒤 디자인 도구로 이동하거나, Figma에서 시작해 코드로 넘어가는 등 순서가 고정되지 않는다. - 작업은 “어디서 시작하느냐”보다 “지금 올바른 방향으로 만들고 있는가”를 지속적으로 점검하는 것이 중요하다. - 첫 번째 구현물이 관성 때문에 최종 버전으로 굳어지는 ‘터널 비전’을 피해야 한다. ## 실용적인 적용 방향 - AI로 빠르게 만든 초기 구현물을 Figma로 가져와 여러 변형안을 비교한다. - 캔버스에서 레이아웃, 시각적 계층, 인터랙션 방향을 검토한 뒤 세부 디자인을 다듬는다. - 확정된 디자인 변경 사항을 MCP를 통해 코드에 다시 반영한다. - 코드와 디자인을 순차적으로 분리하기보다, 탐색 단계에서는 반복적으로 양쪽을 오가며 검증하는 것이 효과적이다.

design-to-codefigmaaiprototyping+2