figma2026년 8월 13일

올바른 방향으로 빠르게 나아가는 방법 | Figma 블로그 (새 탭에서 열림)

AI는 소프트웨어 제작 속도를 크게 높였지만, 빠른 실행이 곧 올바른 제품을 의미하지는 않는다. AI가 만든 결과물을 그대로 받아들이면 기술 부채가 늘고, 평균적인 디자인과 기능에 머물 수 있다. 따라서 좋은 팀은 먼저 무엇을 만들지 충분히 고민하고, 명확한 맥락과 시스템을 제공한 뒤, 자신만의 관점으로 결과물을 다듬어야 한다. ## AI는 실행을 가속하지만 판단을 대신하지 못한다 - AI는 짧은 프롬프트만으로도 완성도 높아 보이는 프로토타입과 코드를 만들어낸다. - 그러나 겉보기의 완성도는 내부 구조, 제약 조건, 시스템 동작 방식까지 올바르다는 뜻이 아니다. - 과거에는 결과물의 세련됨 뒤에 전문가의 의사결정과 트레이드오프가 있었지만, 이제는 AI가 그 빈틈을 임의로 채울 수 있다. - **인지적 항복(cognitive surrender)**은 AI의 출력을 검토 없이 자신의 판단처럼 받아들이는 현상이다. - 첫 번째 결과물이 그럴듯하다는 이유로 바로 출시하지 말고, 문제의 본질과 실제로 만들 가치가 있는 것을 먼저 정의해야 한다. 글에서는 이를 **고려의 의무(consideration imperative)**로 표현한다. ## 맥락과 의도를 먼저 제공해야 한다 - 에이전틱 엔지니어링에서는 개발자의 역할이 코드를 직접 작성하는 것에서 **의도를 명확히 표현하고 검증하는 것**으로 이동한다. - Google의 관련 백서는 다음 요소를 중요한 기반으로 제시한다. - **결정론적 계층**: 테스트, 타입 검사, 검증처럼 매번 동일하게 실행되며 AI의 오류를 잡는 장치 - **고신호 맥락**: 명세, 문서화된 컴포넌트, 설계 원칙 등 에이전트가 의도를 정확히 이해하도록 돕는 정보 - **명확한 인터페이스**: 시스템 각 부분이 어떻게 연결되는지 에이전트가 추측하지 않도록 정의한 계약 - 디자인에서 코드로 전환할 때도 에이전트가 실제 프로덕션 컴포넌트의 구조를 모르면 픽셀을 보고 임의로 재구성할 가능성이 높다. - Figma MCP의 Code Connect처럼 실제 컴포넌트의 코드, props, variants를 제공하면 에이전트가 기존 시스템에 맞는 결과를 만들 수 있다. - 강력한 디자인 시스템은 결정 사항을 재사용 가능한 어휘와 가드레일로 codify해 결과물의 일관성을 높이고 코드와 기술 부채를 줄인다. - 초기에는 명세와 시스템을 준비하는 데 더 많은 시간이 들지만, 장기적으로 유지보수 비용을 낮춘다. ## “괜찮은 결과”는 쉽게 평균이 된다 - AI 모델은 방대한 기존 데이터를 학습했기 때문에 이미 널리 사용된 패턴과 스타일, 즉 **분포 안의 평균적인 결과**를 생성하는 경향이 있다. - 예를 들면 다음과 같은 결과가 반복될 수 있다. - 로고: 단순한 기하학적 형태와 그라디언트 - 발표 자료: 흔한 산세리프 글꼴과 익숙한 레이아웃 - React 컴포넌트: 둥근 모서리의 전형적인 카드 UI - 이런 결과는 틀리지는 않지만 차별성이 부족하다. - AI가 만든 “충분히 좋은” 결과를 반복해서 받아들이면 사용자의 판단 기준이 좁아지고, “무엇이어야 하는가?”보다 “덜 나쁜 선택은 무엇인가?”를 고르게 된다. - AI의 품질이 향상될수록 개인이 과거보다 나은 결과를 만들 수 있지만, 동시에 다른 AI 생성물과 비슷해질 위험도 커진다. ## 제품의 관점은 사람이 결정해야 한다 - AI는 실행과 변형을 빠르게 수행할 수 있지만, 제품의 목적과 차별화된 방향까지 자동으로 결정하게 두어서는 안 된다. - 명확한 의도와 평가 기준이 없으면 모델이 기본값과 평균적인 패턴을 대신 선택한다. - 팀은 AI가 제시한 결과를 출발점으로 활용하되, 왜 이 기능과 디자인이 필요한지, 누구를 위한 것인지, 무엇이 달라야 하는지를 직접 판단해야 한다. - 결국 속도의 핵심은 첫 결과물을 빨리 내는 것이 아니라, 명확한 맥락과 검증 장치를 통해 **올바른 방향으로 빠르게 반복하는 것**이다. AI를 활용할 때는 프롬프트 작성보다 먼저 목표, 제약 조건, 성공 기준을 문서화하는 것이 좋다. 테스트·타입 검사·디자인 시스템·명확한 인터페이스를 갖추고, AI 결과물을 반드시 사람의 관점과 제품 기준으로 검토해야 평균적인 결과와 기술 부채를 피할 수 있다.

reactaidesign-systemsllm+3

figma2026년 8월 5일

더 나은 코드, 더 적은 토큰: MCP에서 Code Connect의 이점 | Figma 블로그 (새 탭에서 열림)

코딩 에이전트가 디자인을 코드로 변환할 때 Code Connect를 사용하면 실제 프로덕션 컴포넌트와 디자인 시스템을 더 정확히 활용할 수 있다. Figma MCP와 Code Connect를 함께 사용한 실험에서 작업 시간은 19.6%, 토큰 사용량은 29.5% 감소했고, 코드 품질은 1~4점 척도에서 1점 향상됐다. 즉, 시각적으로 비슷한 코드를 새로 만드는 대신 기존 컴포넌트를 직접 연결하면 더 빠르고 일관된 결과를 얻을 수 있다. ## 코딩 에이전트가 디자인 시스템을 잘못 구현하는 이유 - Figma MCP의 `get_design_context`는 캔버스의 디자인을 React 코드 형태로 설명한다. - Code Connect가 없으면 에이전트는 다음과 같은 문제를 겪을 수 있다. - 기존 컴포넌트 대신 새로운 컴포넌트를 직접 생성한다. - 디자인 시스템에서 잘못된 컴포넌트를 선택한다. - 올바른 컴포넌트를 찾더라도 검색과 수정에 불필요한 토큰과 시간을 사용한다. - 결과물은 시각적으로는 맞아 보여도 프로젝트의 실제 코드 구조나 디자인 시스템 규칙과 어긋날 수 있다. ## Code Connect가 MCP 응답을 보강하는 방식 - Code Connect는 Figma 컴포넌트와 코드베이스의 실제 컴포넌트를 연결한다. - 설정이 완료되면 MCP 응답에 일반적인 React 표현 대신 프로덕션 코드에 가까운 코드 스니펫이 포함된다. - 에이전트는 다음 정보를 직접 전달받는다. - 사용해야 할 컴포넌트의 import 경로 - 컴포넌트에 전달할 정확한 속성값 - 디자인 요소와 코드 컴포넌트 간의 대응 관계 - 예를 들어 Code Connect가 없으면 탭 UI를 여러 `<button>` 요소와 CSS 클래스로 재구성할 수 있다. - Code Connect를 사용하면 다음처럼 기존 디자인 시스템 컴포넌트를 바로 사용한다. ```tsx <SegmentedControl value="design" options={["Design", "Code"]} /> ``` ## Coinbase 사례 - Coinbase Design Systems 팀은 일관된 UI를 위해 핵심 컴포넌트, 디자인 토큰, 인프라를 관리한다. - 에이전트 기반 개발을 도입하면서 Code Connect를 적용해 에이전트가 CDS 컴포넌트를 재사용하도록 했다. - Code Connect가 없을 때는 에이전트가 스테퍼를 프로그레스 바 조합으로 임의 구현하는 등 컴포넌트를 잘못 추측할 수 있었다. - Code Connect를 사용하면 정확한 코드 표현과 실제 CDS 컴포넌트의 import 문을 확인할 수 있어 코드 품질이 향상되고 토큰도 절약됐다. ## Code Connect의 효과를 측정한 실험 - 동일한 디자인, 프롬프트, 모델을 사용해 Code Connect 적용 여부만 달리한 디자인-투-코드 작업을 비교했다. - 총 27개 테스트 케이스에서 다음 항목을 측정했다. - 코드 품질 - 토큰 사용량 - 작업 소요 시간 - React 기반 디자인 시스템 두 가지를 대상으로 했다. - Figma의 예제 디자인 시스템인 Simple Design System(SDS) - 더 규모가 크고 복잡한 내부 시스템인 Figma Pattern Library(FPL) - Code Connect 적용 결과: - 작업 시간 중앙값 19.6% 감소 - 토큰 사용량 중앙값 29.5% 감소 - 코드 품질 1~4점 Likert 척도에서 1점 향상 ## 실용적인 적용 방향 - 디자인 시스템의 핵심 컴포넌트에 Code Connect 템플릿을 우선 설정하는 것이 효과적이다. - 에이전트가 직접 HTML과 스타일을 조합하게 하기보다 실제 컴포넌트와 import 정보를 제공해야 한다. - 디자인 시스템을 사용하는 팀이라면 Code Connect를 단순한 인간 개발자용 문서화 도구가 아니라 에이전트의 코드 생성 품질과 비용을 개선하는 컨텍스트 계층으로 활용할 수 있다.

reactdesign-systemstypescriptcode-connect+2

figma2026년 7월 1일

Canvas 기반 제품에 접근성 구축하기 | Figma 블로그 (새 탭에서 열림)

Figma는 캔버스 렌더링으로 무한 줌과 실시간 협업 같은 성능을 얻었지만, 브라우저의 기본 접근성 기능을 사용할 수 없게 되었다. 이를 해결하기 위해 디자인의 scenegraph를 기반으로 접근성 정보를 담은 내부 트리와 이를 반영하는 Mirror DOM을 구축했다. 그 결과 스크린 리더 사용자는 Figma 파일을 탐색·편집하고, 캔버스 선택 상태와 키보드 탐색을 연동하며, 비시각적 변경 사항도 안내받을 수 있다. ## 캔버스 기반 제품의 접근성 문제 - Figma 캔버스는 일반 HTML/DOM 대신 자체 렌더링 시스템을 사용한다. - 이 방식은 전통적인 웹 앱보다 높은 성능을 제공한다. - 무한 줌 - 실시간 멀티플레이어 협업 - 게임과 유사한 고성능 그래픽 처리 - 반면 브라우저가 자동으로 생성하는 접근성 트리를 활용할 수 없다. - 실제 캔버스에는 여러 디자인 레이어가 있어도 포커스를 유지하는 `<input>` 요소 하나만 존재하므로, 스크린 리더가 인식할 구조가 거의 없었다. ## 접근성 트리 합성 - 브라우저의 접근성 트리는 DOM, 시맨틱 HTML, ARIA 속성, 계산된 상태를 바탕으로 생성된다. - Figma는 이 기능을 되살리기 위해 실제 캔버스와 별도로 접근성용 DOM 요소를 합성했다. - 이 구조를 통해 스크린 리더가 Figma 파일의 레이어를 탐색하고 편집할 수 있게 했다. - 시각적 렌더링과 접근성 정보를 분리해, 캔버스의 성능을 유지하면서 브라우저의 보조 기술과 연동한다. ## 네 가지 핵심 시스템 Figma의 접근성 구현은 다음 시스템들이 협력하는 구조다. - **내부 접근성 트리** - 각 디자인 레이어의 접근성 정보를 캐시한다. - 변경이 발생할 때 전체를 다시 만들지 않고 필요한 부분만 갱신한다. - **Mirror DOM React 컴포넌트** - 내부 접근성 트리를 참조해 실제 DOM 요소를 생성한다. - 각 레이어에 대응하는 접근성 요소를 재귀적으로 렌더링한다. - **양방향 선택 동기화** - 캔버스에서 노드를 선택하면 대응하는 DOM 요소에 포커스를 이동한다. - 스크린 리더나 키보드로 DOM 요소를 탐색하면 캔버스 선택 상태도 갱신한다. - **공지 시스템** - 탐색 외의 변경 사항을 사용자에게 알린다. - 예를 들어 객체 이동, 도구 전환 등 시각 사용자에게는 명확하지만 스크린 리더 사용자는 놓칠 수 있는 변화를 안내한다. ## 문맥에 따른 접근성 요약 - 각 디자인 레이어마다 스크린 리더가 읽을 수 있는 **접근성 요약(accessible summary)** 을 생성한다. - 같은 디자인이라도 사용 중인 애플리케이션 문맥에 따라 요약 방식이 달라진다. - 프로토타입을 보는 상황에서는: - 편집 관련 기능을 대부분 제외한다. - 텍스트 필드의 내용이나 클릭 동작이 있는 요소의 버튼 역할처럼 최종 사용자에게 필요한 정보만 제공한다. - 문서를 편집하는 상황에서는: - 오토레이아웃 프레임처럼 편집에 필요한 구조도 접근성 트리에 포함한다. - 레이어별 요약을 만든 뒤 트리를 위에서 아래로 순회하며, 접근성에서 제외된 노드는 제거하고 하위 노드를 상위 구조에 병합한다. - 문서 최초 로딩 시에는 전체 접근성 트리를 구성하지만, 이후에는 편집된 부분만 수술적으로 갱신해 비용을 줄인다. ## Mirror DOM의 재귀적 렌더링 - React 기반 `Mirror DOM` 컴포넌트가 접근성 트리의 각 레이어를 DOM으로 변환한다. - 각 컴포넌트는 특정 레이어의 접근성 요약을 구독한다. - 요약에서 다음 정보를 가져와 DOM 요소를 생성한다. - `label`: 스크린 리더가 읽을 이름 - `role`: 버튼, 입력 필드 등 요소의 의미 - `children`: 하위 레이어 - 하위 레이어는 같은 컴포넌트를 재귀적으로 호출해 DOM 트리를 구성한다. - 내부 접근성 트리를 최소 단위로 갱신하면 React가 실제 DOM 변경도 최소화할 수 있다. ## 시각적 콘텐츠와 접근성 콘텐츠의 분리 - Mirror DOM은 화면에 보이지 않지만 보조 기술이 해석할 수 있는 구조를 제공한다. - 일반적인 visually hidden 스타일을 사용하지 않는 점이 특징이다. - 캔버스 기반 제품에서는 접근성용 DOM이 페이지 레이아웃이나 캔버스 렌더링에 영향을 주지 않도록 별도의 방식으로 관리해야 한다. - 핵심은 시각적 UI를 억지로 HTML로 대체하는 것이 아니라, 보조 기술이 필요로 하는 의미 구조를 별도로 합성하는 것이다. 캔버스 기반 제품에 접근성을 추가할 때는 브라우저가 자동으로 제공하던 기능을 직접 재구축해야 한다. 특히 내부 접근성 트리, 점진적 갱신, 시각 UI와 DOM의 양방향 상태 동기화를 함께 설계하는 것이 중요하다.

reactaccessibilityscreen-readersdom+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를 기존 디자인 과정에 단계적으로 결합하되, 도구보다 디자인 원리와 사용자 경험에 대한 판단을 중심에 두는 것이 바람직하다.

reactfigmaaidesign-to-code+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은 디자이너가 구현 가능성을 즉시 실험하고, 개발자는 디자인 의도와 애니메이션 세부 정보를 정확히 확인하도록 돕는 기능으로 볼 수 있다.

reactfigmagen-aimcp+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에서 확인할 수 있다. 실무에서는 코드 레이어를 최종 구현을 자동화하는 도구라기보다, 디자인·개발팀이 여러 구현안을 빠르게 실험하고 합의하는 공동 프로토타이핑 환경으로 활용하는 것이 적합하다. 특히 기존 코드베이스를 불러와 실제 동작을 검토한 뒤 디자인과 코드를 반복적으로 조정하는 워크플로에 유용하다.

reactfigmaai-agentgithub+2

figma2026년 5월 22일

Figma Make 크레딧을 더 효율적으로 사용하는 7가지 팁 | Figma 블로그 (새 탭에서 열림)

Figma Make에서 크레딧을 효율적으로 사용하려면 긴 프롬프트를 반복하기보다 초기 설계와 변경 범위를 명확히 해야 한다. 첫 프롬프트에 프로젝트의 목표·맥락·제약·완료 기준을 충분히 담고, 이후에는 필요한 부분만 구체적으로 수정하는 방식이 효과적이다. 단순한 시각 변경이나 데이터 수정은 AI에 다시 요청하기보다 Edit 도구나 소스 코드 직접 편집을 활용하는 것이 좋다. ## 초기 프롬프트에 프로젝트의 기준점 담기 - 첫 프롬프트는 단순한 요청이 아니라 프로젝트의 전체 브리프처럼 작성한다. - 다음 내용을 구체적으로 포함한다. - 프로젝트의 목표 - 사용 맥락 - 필요한 UI 요소와 동작 - 기술적·기능적 제약 - 최종적으로 “완료”라고 판단할 기준 - 초기 구조가 탄탄할수록 이후에 잘못된 구현을 되돌리는 비용과 크레딧 사용량이 줄어든다. - 대규모 프로젝트는 다음 순서로 나누는 것이 효과적이다. 1. 화면과 컴포넌트의 전체 구조 설계 2. 기능과 상호작용 구현 3. 콘텐츠 입력 및 시각적 세부 조정 - 구조는 프로젝트가 진행될수록 변경하기 어려우므로 가장 먼저 확정하는 것이 좋다. ## 후속 프롬프트는 변경 범위를 좁혀 작성하기 - 첫 프롬프트 이후의 요청은 전체 프로젝트를 다시 설명하는 것이 아니라 변경 사항(delta)을 전달하는 방식으로 작성한다. - 좋은 후속 프롬프트는 다음 세 가지를 포함한다. - 무엇을 바꿀지 - 어떻게 바꿀지 - 무엇은 그대로 유지할지 - “다시 해줘”, “뭔가 이상해”처럼 모호한 요청보다 다음처럼 대상과 위치를 명시한다. - “캘린더 컴포넌트를 수정해줘” - “이 화면에 새로운 상태를 추가해줘” - “`tokens.ts` 파일을 수정해줘” - 서로 관련된 수정이 같은 컴포넌트나 로직에 집중되어 있다면 한 번에 묶는 편이 효율적이다. - 반대로 관련 없는 변경을 하나의 프롬프트에 섞으면 Make가 의도를 해석하는 비용이 커지고 결과도 불안정해질 수 있다. - 특정 파일, 컴포넌트, 상태를 지정하면 Make가 탐색해야 할 범위가 줄어들어 크레딧을 절약할 수 있다. ## 작은 시각 변경은 Edit 도구로 처리하기 - 간격 조정, 요소 삭제, 텍스트 변경처럼 결과가 거의 완성된 상태에서의 작은 수정은 AI 프롬프트보다 Edit 도구가 빠르다. - 이런 작업을 매번 프롬프트로 요청하면 새로운 설계 문제를 해결하는 것이 아니라 기존 결과를 조금씩 조정하는 데 크레딧을 소비하게 된다. - 직접 편집이 적합한 예시는 다음과 같다. - 여백이나 간격 변경 - 특정 UI 요소 제거 - 문구 수정 - 이미 구현된 컴포넌트의 단순한 스타일 조정 ## 소스 코드에서 동적 콘텐츠 수정하기 - 미리보기 화면에서 직접 수정하기 어려운 동적 콘텐츠는 소스 코드에서 값을 변경하는 편이 효율적이다. - `Go to source`를 사용해 관련 코드로 이동한 뒤 실제 데이터가 정의된 부분을 수정한다. - 반복 컴포넌트 안의 텍스트나 같은 폴더의 목록에서 가져오는 데이터 변경에 특히 유용하다. - **⌘F** 단축키로 코드를 검색해 특정 태그나 콘텐츠를 빠르게 찾을 수 있다. - 우선 `App.tsx`를 확인하고, 해당 코드가 없다면 컴포넌트 폴더의 다른 `.tsx` 파일을 살펴보면 된다. ## 실용적인 작업 원칙 처음에는 프로젝트 구조와 제약을 충분히 설명하고, 이후 요청은 한 번에 하나의 명확한 변경에 집중하는 것이 좋다. 단순한 수정은 Edit 도구나 소스 코드에서 직접 처리하고, AI는 새로운 구조·기능·상호작용처럼 직접 구현하기 복잡한 작업에 사용하는 방식이 크레딧과 시간을 모두 절약한다.

reacttypescriptfigma-makeui-ux+3

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를 최종 결과물을 자동 생성하는 도구로만 사용하기보다, 기능 프로토타이핑·코드 이해·대안 탐색·협업 진입장벽 완화에 활용할 때 가장 큰 효과를 얻을 수 있다.

reactfigmadesign-systemsgen-ai+2

figma2026년 4월 2일

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

reactdesign-systemsjavascriptfigma-make+3

figma2025년 10월 5일

ChatGPT 브레인스토밍을 (새 탭에서 열림)

ChatGPT의 새로운 Figma 앱은 대화 중 나온 아이디어와 첨부 파일을 분석해 FigJam 다이어그램으로 변환해준다. 손그림, PDF, PRD, 기술 문서 등을 바탕으로 플로차트·시퀀스 다이어그램·상태 다이어그램·간트 차트 등을 만들고 수정할 수 있어, 개인 브레인스토밍을 팀 협업용 산출물로 빠르게 발전시키는 것이 핵심이다. 이 기능은 Figma MCP 서버를 기반으로 하며, 글 작성 시점에는 EU 외 지역의 로그인한 ChatGPT 사용자에게 제공된다. ## ChatGPT 브레인스토밍을 FigJam으로 변환 - ChatGPT 대화 내용을 바탕으로 적절한 FigJam 다이어그램을 추천하고 자동 생성한다. - 사용자는 프롬프트에 Figma 앱을 직접 언급할 수 있다. - 예: “Figma, 이 스케치로 다이어그램을 만들어줘.” - 사진, 손그림, PDF 등의 파일을 업로드해 다이어그램 생성에 참고시킬 수 있다. - 현재 지원되는 다이어그램 유형은 다음과 같다. - 텍스트 기반 플로차트 - 시퀀스 다이어그램 - 상태 다이어그램 - 간트 차트 - 생성된 결과는 FigJam에서 팀원들과 공유하고 반복적으로 수정할 수 있다. ## 디자인 아이디어를 빠르게 발전시키기 - 냅킨이나 화이트보드에 그린 임시 스케치를 공유 가능한 FigJam 파일로 변환한다. - ChatGPT에 다이어그램 수정, 주제 확장, 다른 시각화 방식 제안을 요청할 수 있다. - 복잡한 문서와 맥락을 업로드하면 ChatGPT가 첫 번째 다이어그램 초안을 작성한다. - 디자이너는 아이디어를 손쉽게 디지털 산출물로 바꾼 뒤 팀 리뷰와 협업을 진행할 수 있다. ## 기술 아키텍처와 시스템 설계 시각화 - 기술 문서와 화면 캡처를 업로드해 소프트웨어 아키텍처 다이어그램을 생성하거나 갱신할 수 있다. - 기술 블로그와 사례 연구를 바탕으로 여러 기술 접근법을 비교하는 구조도를 만들 수 있다. - 웹페이지 스크린샷을 분석해 관련 React 컴포넌트 구조를 다이어그램으로 표현할 수도 있다. - 분산된 코드와 문서, 팀별로 나뉜 지식을 하나의 시각적 모델로 통합해 시스템 설계 논의와 기술 의사결정을 돕는다. - 생성된 다이어그램을 바탕으로 엔지니어들이 실시간으로 협업할 수 있다. ## 제품 기획과 사용자 흐름 정리 - 권한 관리처럼 여러 선택지가 있는 문제를 옵션별 다이어그램으로 만들어 장단점을 비교한다. - PRD를 업로드해 사용자 여정이나 기능 플로차트를 생성한다. - 제품·디자인·엔지니어링 요구사항을 입력해 출시 일정을 간트 차트로 구성한다. - ChatGPT에서 개인적으로 여러 아이디어를 탐색한 뒤 FigJam에서 팀과 함께 우선순위와 실행 계획을 조율할 수 있다. ## Figma MCP 서버 기반 통합 - 이 기능은 Figma MCP 서버를 기반으로 동작한다. - MCP 서버는 원격 접근을 지원하며, 사용자가 작업 중인 맥락을 Figma 작업 환경으로 연결한다. - 따라서 ChatGPT의 분석 능력과 FigJam의 멀티플레이어 협업 기능을 결합할 수 있다. - 글 작성 시점에는 로그인한 ChatGPT 사용자 중 EU 외 지역 사용자에게 제공되며, 향후 더 많은 기능과 다이어그램 유형이 추가될 예정이다. 실무에서는 먼저 ChatGPT에 원문 자료나 스케치를 제공해 초안을 만들고, FigJam에서 사실관계·구조·표현을 검토한 뒤 팀 협업 자료로 다듬는 방식이 가장 효과적이다. AI가 만든 다이어그램은 초안이므로 기술적 정확성과 일정의 현실성은 담당자가 반드시 확인해야 한다.

reactfigmafigjamchatgpt+4

figma2025년 6월 24일

캔버스, 코드를 만나다 (새 탭에서 열림)

Figma의 코드 레이어는 디자인 캔버스와 실제 코드를 하나의 작업 공간에서 결합하려는 시도다. React 기반 코드를 일반 Figma 레이어처럼 이동·복제·리사이즈하고, AI 또는 내장 IDE로 편집할 수 있게 해 디자인의 자유로운 탐색성과 코드의 강력한 기능을 함께 제공한다. 이를 위해 Figma는 캔버스 모델, 웹 기반 코드 편집기, 디자이너와 개발자의 협업 방식을 통합하는 하이브리드 접근법을 택했다. ## 디자인 캔버스와 코드의 충돌 - Figma 캔버스는 객체를 자유롭게 배치하고 수정하는 2D 공간이다. - 반면 코드는 디렉터리와 파일로 구성된 계층적 파일 시스템을 전제로 한다. - 이 차이 때문에 다음과 같은 문제가 발생한다. - 캔버스에서 코드 레이어를 복제하면 새 인스턴스를 만들 것인지, 코드의 분기본을 만들 것인지 결정해야 한다. - 코드의 원본이 캔버스인지 파일 시스템인지 명확히 해야 한다. - 시각적 레이어와 실제 코드 파일의 위치를 어떻게 연결할지 정해야 한다. - Figma는 코드의 구조를 캔버스에 그대로 강요하기보다, 코드가 Figma의 공간적 작업 방식에 맞도록 설계했다. ## 코드를 새로운 캔버스 기본 요소로 구현 - 코드 레이어는 일반 레이어처럼 다음 작업을 지원한다. - 자유로운 이동과 크기 조절 - 부모 레이어 변경 - 오토 레이아웃 스택에 배치 - 다른 레이어와 동일한 방식의 중첩 - 코드 레이어를 복제하면 별도의 코드 포크가 생성된다. - 따라서 Git 브랜치를 따로 만들지 않고도 `Option` 키를 누른 채 드래그해 여러 코드 버전을 나란히 비교할 수 있다. - 이러한 방식은 디자인에서 흔한 빠른 복제와 실험, 버전 비교를 코드에도 적용한다. ## React와 Figma 컴포넌트의 결합 - Figma는 컴포넌트 모델과 React의 컴포넌트 모델이 유사하다는 점에서 React를 선택했다. - 두 시스템 모두 재사용 가능한 구성 요소를 조합해 화면과 애플리케이션을 만든다. - React의 props는 Figma의 컴포넌트 속성과 연결된다. - 개발자가 코드에서 속성을 정의하면 디자이너는 Figma 화면에서 다음과 같은 컨트롤로 값을 조정할 수 있다. - 토글 - 슬라이더 - 드롭다운 - 결과적으로 코드 컴포넌트도 일반 Figma 컴포넌트처럼 시각적으로 재사용하고 변형할 수 있다. ## AI와 직접 편집을 함께 지원하는 IDE - 코드 레이어는 AI만으로 생성하고 수정할 수 있지만, 사용자가 직접 코드를 편집할 수 있는 환경도 필요했다. - Figma는 웹 기반의 내장 IDE를 만들기 위해 CodeMirror를 핵심 편집 엔진으로 채택했다. - CodeMirror의 확장 구조를 활용해 다음 기능을 제공할 수 있다. - 색상 테마 - 찾기 및 바꾸기 - 줄 번호 - Figma 환경에 맞춘 편집 동작 - 기본 편집기의 실행 취소·다시 실행 동작은 Figma의 자체 멀티플레이어 undo 스택과 통합하기 위해 교체했다. - 이를 통해 코드 편집도 Figma의 다른 작업과 일관된 협업 및 실행 취소 경험을 제공하도록 했다. ## 코드 레이어 설계에서 해결해야 할 세 가지 과제 - Figma는 코드 레이어를 구축하며 다음 문제를 핵심 과제로 삼았다. - 코드 레이어와 컴포넌트를 기존 Figma 생태계에 자연스럽게 통합하기 - 강력하면서도 쉽게 사용할 수 있는 웹 IDE 제공하기 - 디자이너와 개발자가 동시에 작업할 수 있는 멀티플레이어 협업 지원하기 - 전체 방향은 코드의 엄격한 구조를 그대로 가져오는 것이 아니라, Figma의 시각적이고 실험적인 작업 방식을 유지하면서 코드의 표현력을 추가하는 데 있다. 코드 레이어는 디자인 파일 안에 단순히 코드를 삽입한 기능이 아니라, 코드를 Figma의 레이어와 컴포넌트 모델에 맞춰 재구성한 기능이다. 디자인을 한 번의 클릭으로 코드 레이어로 바꾸고, AI나 직접 코딩으로 상호작용을 추가할 수 있으므로 디자이너와 개발자가 같은 캔버스에서 더 빠르게 실험할 수 있다는 점이 핵심이다.

reactmultiplayer-collaborationcode-editorcodemirror+2

figma2025년 6월 16일

코드 레이어로 사이트를 인터랙티브 (새 탭에서 열림)

피그마(Figma)는 디자인 환경 내에서 커스텀 리액트(React) 코드를 활용해 역동적인 상호작용을 구현할 수 있는 ‘코드 레이어(Code Layers)’ 기능을 출시했습니다. 이 기능을 통해 디자이너는 복잡한 개발 지식 없이도 AI 채팅이나 직접적인 코드 수정을 통해 정적인 디자인을 실제 작동하는 웹 요소로 변환하고 실험할 수 있습니다. 결과적으로 디자인과 실제 제품 구현 사이의 장벽을 허물어, 별도의 개발 전달 과정 없이도 고도화된 애니메이션이나 기능적 컴포넌트를 피그마 사이츠(Figma Sites)에서 즉시 빌드할 수 있게 되었습니다. **코드 레이어를 활용한 인터랙션 구현** * 코드 레이어는 리액트 코드를 기반으로 구동되는 상호작용 요소로, 피그마 사이츠 내에서 기존 컴포넌트를 코드로 변환하거나 새롭게 생성할 수 있습니다. * 피그마 메이크(Figma Make)의 AI 기술을 활용하여 "꽃 이미지를 무한히 복제해서 드래그할 수 있게 해줘"와 같은 자연어 프롬프트만으로 복잡한 로직을 생성합니다. * 캔버스 위에서 바로 코드 레이어를 복제(Cmd + D)하여 여러 버전의 상호작용을 나란히 비교하고 실험하는 유연한 워크플로우를 제공합니다. **기존 디자인의 동적 변환 및 제작 방식** * 작업 중인 요소에 애니메이션(회전, 바운스 등)을 추가하거나, 마우스 호버 시 색상이 변하는 리플 효과 등 정적 이미지에 생명력을 불어넣을 수 있습니다. * 대출 계산기, 가격 추정기, 실시간 통계 카운터와 같이 단순한 프로토타입을 넘어 실제 로직이 작동하는 유틸리티 컴포넌트를 제작할 수 있습니다. * 단축키(E)를 사용하여 캔버스에 즉석에서 코드 레이어를 그려 넣고, AI에게 이모지 파티클 생성이나 이미지 갤러리 구축 등을 요청하여 빠르게 아이디어를 시각화합니다. **개발자 수준의 확장성과 재사용성** * **커스텀 속성 편집:** AI가 코드 기반의 속성(문자열, 숫자 등)을 자동으로 생성하며, 사용자는 코드 수정 없이도 패널에서 직접 값을 조정해 레이어의 동작을 변경할 수 있습니다. * **컴포넌트화:** 일반적인 피그마 프레임처럼 코드 레이어도 재사용 가능한 컴포넌트로 전환하여 여러 페이지나 팀 프로젝트에 공유할 수 있습니다. * **npm 패키지 지원:** `motion`이나 `@react-three/fiber`와 같은 외부 노드 패키지 매니저(npm) 라이브러리를 임포트하여 고난도의 3D 렌더링이나 정교한 모션 그래픽을 구현할 수 있습니다. 웹 디자인의 한계를 넓히고자 하는 디자이너라면 피그마 사이츠에서 제공되는 코드 레이어를 적극적으로 활용해 보시기 바랍니다. 특히 AI 프롬프트를 통해 기초 코드를 생성한 뒤, npm 패키지를 결합해 시중의 템플릿으로는 불가능했던 독창적인 사용자 경험을 직접 구축해 보는 것을 추천합니다.

reactaiprototypinginteraction-design+4

figma2025년 4월 15일

버전 관리: 피그마 (새 탭에서 열림)

Figma의 Layers 패널에 가로 스크롤을 추가하는 일은 단순한 UI 개선이 아니었다. 계층 구조, 접기·펼치기와 잠금·숨김 상태, 가상화 렌더링, 다양한 텍스트 길이와 다중 스크롤 방향이 서로 얽혀 있었기 때문이다. Figma 팀은 세 가지 프로토타입을 시험하며 사용자의 계층 구조 인식과 작업 맥락을 해치지 않는 방향을 탐색했다. ## 가로 스크롤이 어려웠던 이유 - Layers 패널은 자주 사용되고 신뢰성이 중요해 작은 동작 변화도 신중해야 했다. - 레이어는 정적인 목록이 아니라 다음과 같은 상태를 가진다. - 숨김·잠금 - 계층 접기·펼치기 - 부모·자식 관계 - 성능을 위해 현재 화면에 보이는 레이어만 렌더링하는 **가상화**가 적용되어 있었다. - 세로로 스크롤하면 새 레이어가 렌더링되고, 레이어 이름 길이가 달라져 가로 스크롤 영역과 정렬이 복잡해졌다. - 핵심 목표는 단순히 콘텐츠를 옮기는 것이 아니라 사용자가 현재 계층상의 위치와 “더 볼 내용이 있음”을 계속 이해하도록 하는 것이었다. - 디자이너 Giorgio Caviglia는 JavaScript, HTML, CSS, React로 직접 프로토타입을 만들어 수천 개 레이어와 다양한 상호작용을 실제로 검증했다. ## 첫 번째 시도: 화면 왼쪽의 보이지 않는 레이어 표시 - 레이어가 패널의 왼쪽 위나 오른쪽 아래 경계를 벗어나면 해당 위치에 아이콘을 표시하는 대칭형 UI를 실험했다. - 아이콘을 패널 가장자리에 고정하는 것은 쉬웠지만, 레이어 이름이 스크롤될 때 배경이 일부 요소 아래로 지나가고 다른 텍스트는 가려야 했다. - 컴포넌트가 위에 놓인 요소의 정확한 위치를 알지 못해 다음 문제가 발생했다. - 배경이 텍스트를 제대로 덮지 못함 - 레이어 행 구조와 불투명 배경 처리가 충돌함 - 스크롤 상태에 따라 시각적 가림 처리가 달라짐 - 디자인 측면에서도 왼쪽 상단에 레이어 이름의 끝부분이 들쭉날쭉하게 남아 시각적으로 어색했다. - 결과적으로 대칭성을 유지하려던 해결책이 새로운 문제를 만들었고, 패널 상단의 빈 공간을 어떻게 다룰지 재검토하게 됐다. ## 두 번째 시도: 선택한 레이어로 자동 스크롤 - 캔버스에서 선택한 레이어가 Layers 패널에 보이지 않으면 해당 레이어가 패널 중앙에 오도록 자동으로 가로 스크롤하는 방식을 실험했다. - 이론적으로는 편리했지만, 실제 사용에서는 가로와 세로 스크롤이 동시에 발생해 사용자가 현재 위치를 잃었다. - 특히 깊게 중첩된 레이어를 선택하면 부모 레이어가 화면에서 사라져 계층 구조를 파악하기 어려웠다. - 사용자는 작업 대상의 이름뿐 아니라 다음 정보도 함께 확인해야 한다. - 어떤 부모 아래에 있는지 - 계층상 어디에 위치하는지 - 특정 컴포넌트의 일부인지 - 화면을 갑자기 다른 위치로 이동시키는 동작은 Google Maps가 주행 중 지도를 갑자기 다른 장소로 옮기는 것과 비슷한 혼란을 유발했다. - 도구가 사용자를 돕기보다 현재 작업에 대한 정신적 모델을 깨뜨리는 결과가 되어 채택되지 않았다. ## 세 번째 시도: 레이어 이름 변경 중 스크롤 - 가로 스크롤 도입으로 레이어 이름을 편집하는 동안 다른 레이어로 스크롤할 때의 동작도 새롭게 정의해야 했다. - 사용자가 이름 입력 중 다른 레이어를 보기 위해 스크롤하면, 입력 중인 텍스트를 자동으로 새 이름으로 확정하는 방안을 검토했다. - 그러나 스크롤은 이름 변경을 확정했다는 충분히 강한 신호가 아니었다. - 이 동작을 채택하면 사용자가 의도하지 않게 레이어 이름을 변경할 위험이 있었다. - 따라서 스크롤과 편집 확정의 관계를 별도로 설계해야 한다는 점이 드러났다. ## 실용적인 시사점 - 복잡한 UI에서는 정적인 화면 설계만으로 모든 상태를 예측하기 어렵기 때문에 실제 코드 기반 프로토타이핑이 유용하다. - 자동 이동은 편리함보다 사용자의 공간적·계층적 맥락 보존을 우선해야 한다. - 스크롤, 선택, 편집처럼 서로 다른 의도를 가진 동작을 하나의 암묵적 신호로 처리하면 오작동과 혼란이 발생한다. - 특히 가상화된 계층형 UI에서는 렌더링 구조, 텍스트 가림, 상태 변화까지 함께 고려해야 한다.

reactfigmaui-designjavascript+4

figma2024년 6월 25일

왜 우리는 코드가 범 (새 탭에서 열림)

AI가 디자인을 코드로 변환하고 반복적인 구현 작업을 자동화하더라도, 엔지니어의 역할 자체가 사라지는 것은 아니다. 코드 작성은 엔지니어링의 일부일 뿐이며, 사용자의 문제를 정의하고 제약 조건 속에서 적절한 추상화와 시스템을 설계하는 능력은 여전히 사람의 핵심 역량이다. 따라서 코드를 상품화의 대상으로 두려워하기보다, 자동화를 통해 창의성·문제 해결·제품 의사결정에 더 집중해야 한다는 것이 글의 결론이다. ## 디자인과 코드의 경계가 흐려지는 이유 - AI는 프로그래밍 언어 간 변환뿐 아니라 디자인 시안을 실제 코드로 변환하는 작업도 자동화할 수 있다. - Figma 같은 현대적인 디자인 도구는 내부적으로 디자인을 일종의 구조화된 코드 형태로 저장한다. - 따라서 디자인을 TypeScript·React 또는 Kotlin·Jetpack 코드로 바꾸는 일은 본질적으로 한 표현 방식에서 다른 표현 방식으로 번역하는 작업에 가깝다. - 그러나 목업을 코드로 바꾸는 능력이 곧 좋은 제품이나 시스템을 만드는 능력을 의미하지는 않는다. ## 코드 작성보다 중요한 엔지니어링의 본질 - 엔지니어링은 단순히 코드를 출력하는 일이 아니라 다음을 포함한다. - 어떤 문제를 해결해야 하는지 판단하기 - 문제를 해결할 적절한 방법 선택하기 - 복잡한 시스템을 이해하기 쉬운 추상화로 구성하기 - 정확하고 단순하며 유지보수 가능한 해법 만들기 - 뛰어난 엔지니어는 특정 언어·프레임워크·플랫폼의 세부 문법에만 의존하지 않고, 여러 기술에 공통된 원리를 바탕으로 사고한다. - React나 Jetpack 같은 특정 기술의 전문성은 시간이 지나면 가치가 감소할 수 있지만, 사용자의 요구와 시스템 제약을 해석하는 능력은 오래 지속된다. - AI가 부족한 영역은 사용자의 실제 필요, 제품 맥락, 기술적 제약을 종합해 우아하고 직관적인 시스템으로 설계하는 일이다. ## 반복 작업 자동화와 엔지니어의 창의성 - AI는 반복적이고 정형화된 작업을 줄여 엔지니어가 더 창의적인 문제에 집중하도록 도울 수 있다. - 하나의 기능을 구현하는 방법은 여러 가지일 수 있으며, AI는 기존에 고려하지 않았던 대안을 빠르게 제시할 수 있다. - 최종적으로 어떤 방식을 선택할지는 성능, 복잡도, 유지보수성, 사용자 경험 등의 트레이드오프를 평가하는 사람의 판단에 달려 있다. - 엔지니어의 창의성은 제약을 제거하는 데만 있지 않고, 제약을 활용해 더 나은 기술적·제품적 선택을 만들어내는 데 있다. - 기술 시스템의 구현은 단순한 코딩 작업이 아니라 팀의 제품 결정을 개선하는 창의적 활동이다. ## 구현자에서 문제 정의자·조정자로의 역할 변화 - Figma의 엔지니어들은 출근 후 곧바로 코드를 작성하기보다 팀원들과 사용자 문제를 논의하고 해결 우선순위를 정한다. - 무엇을 만들지, 왜 만들어야 하는지, 어떤 방식이 적절한지를 합의한 뒤에야 구현에 들어간다. - AI가 하위 수준의 기술 작업을 자동화할수록 엔지니어가 직접 신경 써야 할 구현 세부사항은 줄어든다. - 그 결과 엔지니어의 업무는 다음 영역으로 더 이동한다. - 사용자 문제의 발견과 해석 - 문제의 우선순위 설정 - 팀 간 정렬과 의사결정 - 시스템 구조와 품질 기준 설계 - 즉, 엔지니어의 추상화 수준이 높아지고 구현 자체가 전체 업무에서 차지하는 비중은 작아진다. ## 생산성보다 중요한 개발 속도와 가치 전달 - AI 도입의 효과를 단순히 “더 많은 코드를 더 빨리 작성하는 것”으로 측정해서는 안 된다. - 중요한 것은 코드 출력량이 아니라, 올바른 문제를 선택하고 사용자에게 가치 있는 결과를 얼마나 빠르게 전달하는가이다. - 잘못 정의된 문제를 AI로 빠르게 구현하면 오히려 불필요한 기능과 기술 부채가 빠르게 늘어날 수 있다. - 따라서 AI는 구현 자동화 도구이면서 동시에 여러 해결책을 탐색하고 제품 실험을 가속하는 도구로 활용해야 한다. AI 시대에 엔지니어는 특정 프레임워크의 코드 작성 능력보다 문제 정의, 시스템 사고, 트레이드오프 판단, 사용자 맥락 이해를 강화하는 것이 좋다. 반복 구현은 AI에 맡기되, 무엇을 만들지와 어떤 구조가 장기적으로 좋은지는 사람이 책임지는 방식이 바람직하다.

reactgen-aitypescriptdesign-to-code+2

figma2024년 4월 15일

Framework 2024 (새 탭에서 열림)

Figma는 디자인 시스템 구축보다 더 어려운 과제인 조직 전체의 도입과 활용을 지원하기 위해 Framework 2024에서 세 가지 기능을 공개했다. Code Connect는 디자인과 실제 코드 사이의 간극을 줄이고, 타이포그래피·그라디언트 변수는 디자인 토큰의 범위를 확장하며, Library Analytics API는 디자인 시스템 사용 현황을 측정하도록 돕는다. 결론적으로 Figma는 디자인 시스템을 만드는 도구를 넘어, 개발자 adoption과 조직 내 확산까지 지원하는 방향으로 발전하고 있다. ### 디자인 시스템의 핵심 과제: 조직 전체의 도입 - 디자인 시스템은 일관성, 효율성, 확장성을 제공하지만 실제 효과는 팀 전체가 이를 사용할 때 발생한다. - 시스템이 강력하고 정교해질수록 복잡성도 커지며, 디자이너와 개발자의 적극적인 참여를 이끌어내는 일이 어려워진다. - Figma는 변수, 테마와 상태 관리, 고급 프로토타이핑, Dev Mode 등을 통해 디자인과 코드의 연결을 강화해 왔다. - 이번 발표의 중심 목표는 디자인 시스템을 “구축”하는 데서 나아가 조직 전반에서 “채택”되도록 만드는 것이다. ### Code Connect: 디자인과 코드의 연결 - Code Connect는 Dev Mode에서 디자인 시스템 컴포넌트에 대응하는 실제 코드 스니펫을 제공한다. - 개발자는 별도의 문서나 저장소를 검색하지 않고 Figma에서 필요한 코드를 확인하고 복사할 수 있다. - 이를 통해: - 구현 시간을 줄일 수 있다. - 디자인과 코드의 불일치를 완화할 수 있다. - 개발자가 디자인 시스템 컴포넌트를 사용하는 진입 장벽을 낮출 수 있다. - 임의로 유사한 컴포넌트를 새로 만드는 일을 줄일 수 있다. - Organization 및 Enterprise 요금제에서 베타로 제공되며, React·iOS·Storybook을 지원한다. - 향후 더 많은 프레임워크와 플랫폼으로 지원 범위가 확대될 예정이다. - Bumble, GitHub, HP 등의 팀은 디자인 시스템과 실제 프로덕션 코드 사이를 연결하는 문제와 Code Connect의 활용 가능성을 논의했다. ### 타이포그래피 변수: 디자인 토큰의 확장 - 기존 변수 기능만으로는 디자인 시스템의 중요한 영역인 타이포그래피를 충분히 표현하기 어려웠다. - 타이포그래피 변수를 사용하면 글꼴 크기, 행간, 글꼴 스타일 등 타이포그래피 속성을 변수와 토큰 체계 안에서 관리할 수 있다. - 주요 활용 방식: - 폰트 스케일을 한 번 정의하고 전체 시스템에 일관되게 적용 - 플랫폼별 타이포그래피 설정 조정 - 반응형 또는 테마별 텍스트 스타일 관리 - WCAG 기준을 고려한 접근성 높은 스케일 구성 - 디자인 시스템의 색상과 간격뿐 아니라 텍스트 표현까지 체계적으로 관리할 수 있게 된다. ### 그라디언트 변수: 더 풍부한 시각 스타일 관리 - 그라디언트도 변수로 정의하고 재사용할 수 있도록 지원한다. - 여러 화면과 컴포넌트에서 동일한 그라디언트 스타일을 일관되게 적용할 수 있다. - 브랜드 테마나 모드별로 그라디언트를 교체하기 쉬워진다. - 변수 기반 관리로 디자인 시스템이 단순한 색상 팔레트를 넘어 더 표현력 있는 시각 언어를 다룰 수 있다. ### Library Analytics API: 디자인 시스템 사용 현황 측정 - Library Analytics API는 조직 내 디자인 시스템 라이브러리와 컴포넌트의 사용 데이터를 분석할 수 있도록 제공된다. - 디자인 시스템 관리자는 다음과 같은 질문에 답할 수 있다. - 어떤 라이브러리와 컴포넌트가 실제로 사용되는가? - 어느 팀이나 프로젝트가 디자인 시스템을 적극적으로 채택하는가? - 사용되지 않거나 개선이 필요한 컴포넌트는 무엇인가? - 정량적인 사용 데이터를 바탕으로 문서화, 교육, 컴포넌트 개선, 도입 전략을 세울 수 있다. - 디자인 시스템의 성공을 단순히 “만들었는가”가 아니라 “얼마나 사용되는가”로 평가할 수 있게 한다. ### 실용적인 결론 디자인 시스템 팀은 컴포넌트와 토큰을 만드는 데 그치지 말고, 개발자가 실제 코드로 쉽게 사용할 수 있는 경로와 사용 현황을 측정할 방법까지 함께 마련해야 한다. Code Connect로 개발자 경험을 개선하고, 타이포그래피·그라디언트 변수로 토큰 범위를 확장하며, Analytics API로 채택률을 추적하는 접근이 효과적이다.

reactfigmadesign-systemsdesign-tokens+3