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

Figma Weave의 Runway Aleph 2.0으로 모든 프레임을 직접 제어하세요 | Figma 블로그

Runway Aleph 2.0이 Figma Weave에 통합되어 영상의 개별 프레임과 장면을 더 정밀하게 지시하고 수정할 수 있게 됐다. 최대 30초 영상에 참조 이미지를 적용하고, 특정 요소만 바꾸면서 나머지는 유지할 수 있다. 사용자는 여러 편집을 단계적으로 조합해 재촬영 없이 새로운 영상 방향을 탐색할 수 있다. ## 프레임 단위의 정밀한 영상 제어 - Aleph 2.0은 영상 전체가 아니라 장면 속 요소와 프레임별 변화를 구체적으로 지시하는 데 초점을 둔다. - 최대 30초 길이의 영상 클립을 지원해 짧은 컷을 넘어 하나의 완결된 장면을 다룰 수 있다. - 참조 이미지를 입력하면 원하는 시각적 스타일이나 분위기를 영상 전반에 적용한다. - 사용자가 변경을 요청하지 않은 배경, 인물, 장면 요소는 최대한 보존한다. - 키프레임 편집은 해당 대상이 등장하는 모든 프레임에 이어져, 움직이는 피사체에도 일관되게 적용된다. ## 단계적으로 구성하는 Weave 워크플로 - Figma Weave의 Aleph 2.0 노드를 사용하면 영상 편집을 하나의 프롬프트가 아닌 여러 결정의 연속으로 구성할 수 있다. - 노드를 연결해 편집 단계를 순차적으로 쌓고, 각 단계의 결과를 미리 확인할 수 있다. - 결과를 확인한 뒤 프롬프트나 편집 방향을 수정하는 반복 작업이 가능하다. - 이는 영상 제작 과정을 Figma에서 디자인 프로젝트를 발전시키는 방식과 유사하게 만든다. - 한 번에 최종 결과를 생성하기보다, 여러 편집을 조합하며 점진적으로 결과물을 완성하는 접근이다. ## 재촬영 없이 장면 확장 - 기존에 촬영한 영상의 한계를 넘어 새로운 연출을 시험할 수 있다. - 카메라 앵글을 변경하거나 새로운 캐릭터를 추가할 수 있다. - 배경이나 환경 전체를 다른 모습으로 변환할 수도 있다. - 동일한 원본에서 여러 방향의 결과물을 나란히 비교하며 아이디어를 발전시킬 수 있다. - 촬영 조건을 다시 마련하지 않고도 모델이 원본 영상을 새로운 장면으로 확장한다. ## 이용 및 비용 관련 안내 - Aleph 2.0은 Figma Weave에서 사용할 수 있다. - 가격은 입력 영상 길이에 따라 조정될 예정이며, 짧은 입력을 사용하는 일부 작업에서는 비용이 낮아질 수 있다. - 시작 방법과 실제 워크플로는 Figma 도움말 센터, 커뮤니티 템플릿 라이브러리, Weavy 지식 센터에서 확인할 수 있다. 실무에서는 원본 영상을 보존한 뒤, 참조 이미지와 편집 목적을 단계별로 나누어 Weave 노드에 구성하는 방식이 효율적이다. 특히 인물·카메라·환경 변경을 각각 분리해 테스트하면 결과를 비교하기 쉽고, 재촬영 전 다양한 연출 가능성을 저비용으로 검증할 수 있다.

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

AIfigma-weavevideo-editingcreative-workflows+2

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

색의 언어로 말하기 | Figma 블로그

색은 단순한 시각 요소가 아니라 감정과 문화적 의미를 전달하는 언어이며, 브랜드의 메시지와 정체성을 형성하는 중요한 도구다. Pantone Color Institute(PCI)는 자연, 문화, 사회 분위기, 지역별 관습을 분석해 색이 사람들에게 어떻게 받아들여지는지 연구한다. 효과적인 색상 선택은 유행을 따르는 데 그치지 않고, 전달하려는 메시지와 사용 환경에 맞춰 색의 의미를 설계하는 데서 출발한다. ## 색이 감정과 인식에 미치는 영향 - 색에 대한 무의식적 반응은 자연환경과 밀접하게 연결되어 있다. - 노란색은 태양의 따뜻함과 즐거움을 연상시킨다. - 초록색은 재생과 성장을, 갈색은 안정감과 뿌리내림을 나타낸다. - 파란색은 변함없이 존재하는 하늘의 이미지 때문에 신뢰와 안정성을 전달한다. - 주황색은 과일의 새콤달콤한 맛과 연결되어 활기와 감각적인 즐거움을 불러일으킨다. - 자연을 반영하는 색은 문화와 시대가 바뀌어도 비교적 오래 지속되는 힘을 가진다. - 영화, 음악, 예술가, 여행, 스포츠, 신기술, 사회 분위기와 경제 상황도 색에 대한 감각을 변화시킨다. - 경제가 위축되면 사람들이 선호하는 색상 팔레트 역시 달라질 수 있다. ## 지역과 문화에 따른 색의 의미 - 색의 의미는 전 세계적으로 동일하지 않으며, 지역마다 고유한 “색의 방언”이 존재한다. - 서양에서는 장례식에 검은색을 입지만, 동양 일부 문화권에서는 흰색을 입는다. - 빨간색도 문화권에 따라 사랑·분노·긴급함을 뜻할 수 있고, 동양에서는 행운·번영·축하를 상징하기도 한다. - 따라서 브랜드와 마케팅 팀은 색상 트렌드나 보편적 의미만 믿어서는 안 된다. - 일본과 프랑스 소비자는 같은 제품을 보더라도 각자의 문화적 경험에 따라 색을 다르게 해석할 수 있다. ## 색으로 브랜드 스토리 만들기 - 효과적인 브랜드 색상은 회사가 무엇을 지향하는지 시각적으로 표현해야 한다. - 코카콜라의 빨간색은 흥분과 에너지를 전달하며, 시간이 지나면서 브랜드 자체를 상징하는 색이 되었다. - Airbnb는 2014년 기존의 베이비 블루를 연어색으로 변경했다. - 따뜻하고 인간적인 인상을 주며, 낯선 사람의 집에 머무는 데서 오는 불안감을 완화하려는 의도가 담겼다. - 이후 현지 문화를 연결하는 Experiences 서비스와도 자연스럽게 연결되었다. - Charli XCX의 ‘Brat Green’은 패션에서 먼저 관찰된 이질적인 색이 대중문화의 상징으로 발전한 사례다. - 병들거나 불쾌한 느낌을 줄 수 있는 색에 새싹과 생명력의 이미지를 결합했다. - 강렬한 색감과 노란 기운이 소셜미디어에서 눈에 띄는 대담함과 활력을 만들어냈다. - 브랜드 색은 고립된 색상값이 아니라 브랜드가 전달하려는 감정, 시대정신, 소비자 경험과 함께 설계해야 한다. ## 재료와 매체를 고려한 색상 설계 - 같은 색이라도 화면, 직물, 플라스틱, 종이 등 재료와 표면에 따라 다르게 보인다. - 디지털 화면에서 매력적인 색이 실제 제품에서는 지나치게 자극적으로 보일 수 있다. - 직물 염료로 구현 가능한 색이 의료용 밴드 같은 다른 소재에서는 구현되지 않을 수도 있다. - 따라서 색상은 디자인 후반에 추가하는 요소가 아니라 초기 기획 단계부터 고려해야 한다. - 색을 선택할 때는 색상 자체뿐 아니라 재료, 표면 마감, 조명, 실제 사용 환경까지 함께 검토해야 한다. ## 팬톤 컬러 연구와 시대정신 - Pantone Color Institute는 1986년 설립되었으며, 색채 심리학자와 트렌드 예측가로 구성된 글로벌 조직이다. - 연구 결과는 다음과 같은 분야에 활용된다. - PANTONEVIEW 트렌드북 - Pantone Connect 같은 디자인 도구 - 팬톤의 실물 컬러 가이드 - 매년 발표되는 Pantone Color of the Year - 매년 선정되는 올해의 색은 26년 이상 이어진 교육·문화 프로그램으로, 디자인 업계에서 큰 영향력을 행사한다. - PCI는 색을 단순히 예쁜 조합으로 고르는 것이 아니라, 사회 변화와 문화적 분위기, 소비자의 감정 변화를 반영하는 방식으로 해석한다. 제품이나 브랜드에 색을 적용할 때는 먼저 “어떤 메시지를 전달할 것인가”를 정한 뒤, 목표 시장의 문화적 맥락과 실제 소재·매체에서의 구현 가능성을 함께 검토하는 것이 좋다. 유행하는 색을 그대로 따라가기보다 브랜드의 가치와 사용자의 감정을 연결하는 색상 체계를 설계해야 한다.

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

Figma디자인 시스템brandingcolor-theory+2

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

Figma에서 MCP 서버를 활용하는 4가지 방법 | Figma 블로그

Figma의 MCP 서버는 디자인 파일을 읽는 수준을 넘어 Slides·FigJam·Make·Figma 에이전트 전반에서 콘텐츠를 생성하고 수정하는 도구로 확장됐다. 에이전트는 사내 문서와 최신 제품 정보를 바탕으로 발표 자료나 협업 보드를 만들고, Figma 템플릿·디자인 시스템·사용자 정의 폰트까지 반영할 수 있다. 그 결과 반복적인 콘텐츠 제작의 상당 부분을 자동화하면서도 최종 검토와 창의적 판단은 사람이 담당하는 워크플로가 가능해졌다. ## Figma MCP 서버의 확장된 역할 - Figma Slides, FigJam, Figma Make, 새로운 Figma 디자인 에이전트에서 프롬프트 기반 생성·수정을 지원한다. - 디자인 파일의 이미지와 아이콘을 SVG, PDF, JPG, PNG로 내려받을 수 있는 `download_assets` 도구가 추가됐다. - 업로드한 사용자 정의 폰트를 지원해 웹 안전 폰트로 대체하지 않고 브랜드 서체를 그대로 렌더링한다. - `use_figma` 도구와 `/figma-use-slides` 같은 MCP 스킬을 조합해 팀의 템플릿과 디자인 의도를 결과물에 반영한다. - 스킬은 에이전트의 출력 품질과 일관성을 높이며, Figma 커뮤니티에서 공유하거나 직접 제작할 수 있다. ## 지속적으로 갱신되는 발표 자료 만들기 - Figma의 디자이너 옹호 담당자는 AI 제품 출시 내용을 정리한 상시 업데이트형 발표 자료를 운영한다. - 다음과 같은 프롬프트를 코드 에디터에서 실행해 자료를 갱신한다. - Slack, Google Drive, Shortcut 블로그, 릴리스 노트에서 최신 정보를 수집 - 기존 덱에서 갱신이 필요한 부분을 제안 - 새로 추가할 슬라이드 아이디어를 생성 - Figma Slides의 기존 템플릿에 내용을 반영 - 에이전트가 관련 대화, 브리프, 출시 메시지를 모아 초안의 약 80%를 완성한다. - 이후 사람은 이미지 교체, 문구 수정, 내용 검토 등 품질 관리에 집중한다. - 사용자 정의 폰트를 활용하기 때문에 발표 자료의 브랜드 정체성과 시각적 일관성을 유지할 수 있다. - 같은 방식은 다음과 같은 업무에도 적용된다. - PM의 제품 킥오프 자료 작성 - 디자이너의 디자인 탐색 발표 - 마케팅 팀의 GTM 계획 수립 - 영업 팀의 고객용 자료 최신화 - 핵심 이점은 단순히 제작 속도를 높이는 데 그치지 않고, 팀의 디자인 시스템과 브랜드 기준을 반영한 결과물을 만드는 것이다. ## 실시간 데이터를 반영한 FigJam 보드 생성 - 제품 관리자는 기능 킥오프 워크숍을 준비할 때 회사 곳곳의 정보를 수집하고, 세션에 맞게 FigJam 섹션을 구성해야 한다. - 이 과정은 관련 맥락을 모으고 보드 형식을 맞추는 데 많은 시간이 걸린다. - 이를 자동화하기 위해 `/figjam-builder`라는 커스텀 스킬을 구축했다. - 스킬과 MCP 서버를 이용하면 실시간 데이터와 조직 내 정보를 바탕으로 워크숍용 FigJam 보드를 생성할 수 있다. - 제공된 본문은 이 사례의 구체적인 구현 방식과 나머지 두 가지 활용 사례 설명으로 이어지기 전에 중단되어 있다. MCP를 도입할 때는 모든 결과를 자동 게시하기보다, 에이전트가 자료 조사와 초안 작성을 맡고 사람이 사실관계·문구·시각 요소를 검토하는 방식이 현실적이다. 특히 팀 템플릿, 디자인 시스템, 사용자 정의 폰트, 업무별 스킬을 함께 제공할수록 자동화 결과의 품질과 브랜드 일관성이 높아진다.

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

디자인 시스템AI 에이전트figjamfigma-make+2

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

레이어 패널의 성능 개선 | Figma 블로그

Figma는 대규모 파일에서 레이어 패널의 느린 상호작용을 해결하기 위해 아키텍처를 전면 재설계했다. 행 목록 계산과 노드 상세 정보 계산을 분리하고, 파생 속성(derived properties)을 활용해 변경된 부분만 다시 계산한 결과, 가장 복잡한 파일에서 일부 상호작용이 30~50% 빨라졌다. 핵심은 보이지 않는 레이어까지 계산하지 않고, 필요한 데이터만 지연 계산·캐싱하는 것이다. ## 레이어 패널 성능 저하의 원인 - 레이어 패널은 Figma 파일의 노드 트리를 중첩된 목록으로 표현한다. - 초기 아키텍처는 파일의 각 노드에 대해 이름, 아이콘, 표시 여부, 잠금 상태 등 UI에 필요한 데이터를 하나의 큰 JavaScript 객체로 구성했다. - 레이어가 변경될 때마다 확장된 모든 노드에 대해 데이터를 처음부터 다시 계산했다. - 파일이 수만 개의 레이어를 포함하게 되면서 두 가지 문제가 발생했다. - **계산량 과다:** 화면에 실제로 보이는 행은 보통 20~30개뿐인데, 확장된 모든 노드의 데이터를 계산했다. - **재계산 빈도 과다:** 레이어 하나를 확장하거나 변경해도 전체 데이터를 다시 생성했다. ## 1단계: 두 번에 나누어 계산하기 - 데이터 수집 과정을 두 단계로 분리했다. - 첫 번째 단계에서는 패널에 표시될 **행 ID의 순서**만 계산한다. - 이 과정도 단순하지 않으며 다음과 같은 제품 규칙을 반영해야 한다. - 오토 레이아웃 프레임의 자식은 역순으로 표시될 수 있다. - 위젯이나 FigJam 스티키처럼 자식 노드를 패널에 표시하지 않는 노드가 있다. - 프로토타이핑 프레임의 고정 헤더와 스크롤 헤더는 자식을 두 영역으로 나눈다. - 최상위 프레임과 컴포넌트는 고정된 위치에 표시된다. - 두 번째 단계에서는 첫 단계에서 얻은 행 ID 중 현재 화면에 보이는 노드만 대상으로 상세 데이터를 계산한다. - 기존에도 화면 밖 항목을 렌더링하지 않는 윈도잉(windowing)을 사용했지만, 데이터 계산 자체는 모든 확장 노드에 대해 수행되고 있었다. - 새 구조에서는 이름, 아이콘, 잠금·표시 상태, 선택 상태 등을 실제로 필요한 수십 개 행에 대해서만 계산한다. - 그 결과 수십만 개 노드의 데이터를 계산하던 작업을 화면 주변의 작은 범위로 줄였다. ## 2단계: 파생 데이터 캐싱 - 변경되지 않은 레이어를 다시 그리거나 재계산하지 않고, 바뀐 부분만 갱신하도록 개선했다. - 이를 위해 Figma가 플랫폼 차원에서 개발한 **파생 속성(derived properties)** 기능을 사용했다. - Figma 노드는 직접 저장·조회할 수 있는 필드(fields)를 가진다. - 하지만 일부 속성은 직접 저장하지 않고 다른 필드와 속성으로부터 계산된다. - 예를 들어 노드는 부모 기준의 상대 위치만 저장하고, 절대 위치는 다음과 같이 계산할 수 있다. ```text Self.AbsolutePosition = Parent.AbsolutePosition + Self.RelativePosition ``` - 파생 속성 시스템은 이런 계산 관계를 명시적으로 선언하고, 의존하는 값이 바뀌면 최신 상태를 유지하도록 한다. - 시스템의 장점은 다음과 같다. - 각 파생 속성이 어떤 필드와 다른 파생 속성에 의존하는지 추적한다. - 의존 관계가 최적화된 그래프 형태로 컴파일된다. - 속도와 메모리 사용량 사이의 선택을 고려한 여러 캐싱 정책을 제공한다. - 기본적으로 지연 계산(lazy evaluation) 방식이어서 실제로 읽을 때만 계산한다. - 레이어 패널은 부모-자식 트리 구조를 갖기 때문에 파생 속성과 자연스럽게 결합된다. - 이전에는 트리 어디에서든 변경이 발생하면 노드 데이터를 전체적으로 다시 계산했지만, 새 구조에서는 의존 관계를 바탕으로 영향을 받은 데이터만 갱신할 수 있다. ## 성능 개선의 의미 - 대규모 Figma 파일에서 레이어 패널의 스크롤, 확장·축소, 선택 등의 상호작용이 더 빨라졌다. - 레이어 패널의 계산 비용이 줄어들면서 드래그나 텍스트 입력 같은 에디터의 다른 작업에도 영향을 주던 지연이 완화됐다. - 윈도잉만 적용하는 것보다, **계산 대상 자체를 가시 영역으로 제한하는 것**이 중요하다는 점을 보여준다. - UI 성능을 높이려면 다음 두 문제를 별도로 해결해야 한다. - 불필요한 항목까지 계산하는 문제 - 같은 항목을 반복해서 계산하는 문제 ## 실용적인 결론 대규모 트리형 UI에서는 렌더링만 가상화하는 것으로 충분하지 않다. 먼저 화면에 필요한 항목의 ID나 구조만 계산한 뒤, 실제 표시되는 항목의 상세 데이터만 지연 계산하고, 의존성이 변한 부분만 캐시를 무효화하는 방식이 효과적이다.

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

JavaScriptcachingvirtualizationdependency-graph+2

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

이 템플릿을 가져가세요: Figma Weave로 사용자 페르소나에 생동감을 불어넣기 | Figma 블로그

정적 이미지와 반복되는 프로필 사진만으로는 이상적 고객 프로필(ICP)을 실제 고객처럼 생생하게 전달하기 어렵다. Dropbox의 Sara Clayton은 Figma Weave를 활용해 사용자의 얼굴 사진과 간단한 프롬프트를 현실적인 작업 환경 이미지로 바꾸고, 참고 이미지를 추가해 의상과 스타일을 조정했다. 이를 통해 ICP의 스토리텔링을 강화하고, 고객에 대한 공감과 전략적 활용도를 높일 수 있었다. ### 정적인 ICP의 한계 - ICP는 제품을 만들 대상 고객을 구체적으로 묘사하는 문서다. - Dropbox Replay 팀은 영상 편집자, 오디오 엔지니어, 제작 관리자 등을 주요 사용자로 정의했다. - 기존에는 다이어그램, 사용자 스토리, 슬라이드 덱, 동일한 인물 사진을 반복 사용했다. - 이런 방식은 사용자가 실제로 어떤 환경에서 일하고 어떤 도구를 사용하는지 충분히 보여주지 못했다. - Sara Clayton은 사용자의 직업적 맥락과 현실감을 시각적으로 표현할 필요성을 느꼈다. ### 스토리 중심의 사용자 페르소나 - ICP 관점에서 상황을 시간 순서대로 보여주는 슬라이드 덱이 기존 방식보다 효과적이었다. - 예를 들어 미디어 제작자가 타임라인이나 믹싱 보드 앞에서 일하는 모습을 보여주면 사용자의 업무 맥락을 더 쉽게 이해할 수 있다. - 반복되는 증명사진 대신 실제 작업 공간, 복장, 주변 도구를 포함한 장면이 필요했다. - 이러한 시각적 디테일은 페르소나를 단순한 데이터 묶음이 아니라 현실적인 인물로 느끼게 한다. ### Figma Weave를 활용한 이미지 생성과 수정 - 사용자의 얼굴 사진과 한 줄 프롬프트만으로 재택근무 공간에서 작업하는 미디어 제작자 이미지를 생성했다. - 생성된 인물은 Premiere Pro 화면 앞에 앉아 있는 등 직업적 환경이 반영됐다. - 동료의 피드백을 받은 뒤 참고 이미지를 업로드해 의상과 전체적인 스타일을 수정했다. - 일반적인 챗봇형 이미지 생성 도구보다 변수별 결과를 확인하고 반복 수정하기 쉬웠다. - 여러 생성 결과를 시각적으로 비교하면서 원하는 인물, 복장, 환경을 구체화할 수 있었다. ### 페르소나 템플릿과 활용 방식 - 글에서 소개한 템플릿은 현실적인 장면을 포함한 ICP 이미지를 약 2분 안에 만드는 데 초점을 둔다. - 바로 사용할 수 있는 Figma Weave 템플릿에는 다음과 같은 유형이 포함된다. - 자동차 내부의 캐릭터 이미지 생성 - 전문적인 캐릭터 레퍼런스 시트 제작 - 변수 기능을 활용한 다양한 의상과 캐릭터 생성 - 템플릿을 활용하면 반복적인 페르소나 프로필을 여러 상황과 스타일로 확장할 수 있다. ### Figma Weave의 의미 - Figma가 인수한 Weavy를 기반으로 한 Figma Weave는 생성형 AI와 전문 편집 기능을 오픈 캔버스에 결합한다. - 이미지뿐 아니라 동영상, 애니메이션, 모션 디자인, VFX 생성 및 편집까지 지원하는 방향을 지향한다. - 단순히 이미지를 생성하는 것보다 결과를 보고 다양한 요소를 조정하는 반복 작업에 강점이 있다. - Dropbox 사례에서는 더 인간적이고 높은 해상도의 스토리텔링을 가능하게 해 ICP가 제품 전략에 실제로 영향을 주도록 했다. 팀의 ICP나 사용자 페르소나가 텍스트와 반복적인 스톡 이미지에 머물러 있다면, 실제 업무 환경과 행동을 보여주는 장면으로 확장하는 것이 효과적이다. Figma Weave 같은 도구를 사용할 때는 얼굴, 직업 환경, 복장, 참고 이미지 등의 변수를 단계적으로 조정하면 더 일관되고 설득력 있는 페르소나를 만들 수 있다.

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

Figma생성형 AImotion-designfigma-weave+2

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

취향을 가꾸는 일은 결코 멈추지 않는다 | Figma 블로그

도구와 AI만으로는 장인의 경지에 도달할 수 없으며, 중요한 것은 자신만의 관점인 ‘감각(taste)’을 기르는 일이다. 감각은 반복적인 연습과 피드백, 세부 사항에 대한 관심, 사용자와 결과물에 대한 배려를 통해 끊임없이 발전한다. AI는 더 많은 가능성을 탐색하게 해주지만, 무엇을 선택하고 다듬을지는 여전히 사람의 감각에 달려 있다. ## 숙련은 기술 습득을 넘어 관점을 만드는 일 - 어떤 분야든 재료와 도구의 작동 방식을 이해하고 반복해서 연습해야 한다. - AI가 작업 방식을 바꾸더라도 전문가가 되는 과정 자체가 사라지지는 않는다. - 진정한 전문성은 새로운 기술을 많이 익히는 데 그치지 않고, 세상을 바라보고 해석하는 고유한 방식을 갖는 데서 나온다. - 피아노 연주나 작곡에서 리듬과 강약을 조절해 감정을 전달하듯, 디자인에서도 각 선택의 이유와 효과를 이해해야 한다. - 멘토의 조언, 비평, 협업, 꾸준한 실천이 창의적 직관을 형성한다. ## 감각은 배려와 의도성에서 나온다 - 감각이 뛰어난 결과물은 제작자의 의도와 그것을 끝까지 구현하려는 노력을 보여준다. - 디터 람스의 브라운 제품처럼 기능만 설계하는 것이 아니라, 제품이 놓일 공간과 사용자가 만지는 경험까지 고려해야 한다. - 감각은 모든 사람이 좋아하는 보편적 취향이 아니다. 서로 다른 미적 관점을 가진 디자이너도 충분히 감각적일 수 있다. - 제품 디자인에서는 형태와 기능, 표현력과 가독성, 추가할 것과 حذف할 것 사이의 트레이드오프를 어떻게 다루는지가 감각을 드러낸다. - 세부 사항에 얼마나 투자하고 어떤 타협을 거부하는지가 결과물의 개성을 만든다. ## 좋은 결과물을 만드는 세 가지 요소 저자는 감각을 가진 사람을 판단할 때 다음 세 가지를 본다고 설명한다. - **분별력(Discernment)** - 무엇이 잘못되었는지뿐 아니라 왜 잘못되었는지 설명할 수 있어야 한다. - 다른 사람은 막연히 느끼는 문제를 구체적인 언어와 근거로 표현할 수 있어야 한다. - **공감(Empathy)** - 화면이나 제품 자체가 아니라 그 반대편에 있는 사용자를 생각해야 한다. - 다양한 화면 크기, 색상 프로필, 인터페이스 언어, 사용 빈도가 낮은 상태까지 고려하는 태도가 중요하다. - **창의적 에너지(Creative energy)** - 개인 프로젝트나 실험을 계속하며, 해결하고 싶은 문제를 스스로 만들어 나가야 한다. - 결과물을 만들지 않고는 견디기 어려울 정도로 자신의 분야에 몰입하는 태도가 드러난다. ## 감각은 연습과 협업 속에서 자란다 - 음악에서는 손가락이 건반을 익히고 귀가 음 사이의 공간을 감지하듯, 디자인에서도 반복 작업을 통해 품질 판단이 몸에 배게 된다. - 디자인 비평은 자신의 판단을 검증하고 다른 관점을 받아들이는 중요한 과정이다. - 완성도는 혼자만의 취향에서 나오는 것이 아니라, 협업과 피드백을 통해 의도를 더 명확하게 다듬을 때 높아진다. - 사용자가 거의 경험하지 않는 빈 상태나 아주 미세한 전환 속도처럼 눈에 잘 띄지 않는 부분도 세심하게 관리해야 한다. ## AI는 감각을 대체하지 않고 창작의 범위를 넓힌다 - AI가 첫 번째 결과물을 빠르게 만들어 주더라도, 그것을 최종 결과로 받아들이는 태도는 감각의 부족을 의미할 수 있다. - 제임스 다이슨이 대표적인 진공청소기 디자인을 완성하기까지 5,127개의 시제품을 만든 사례처럼, 뛰어난 결과물에는 반복적인 선택과 개선이 필요하다. - 좋은 도구는 머릿속의 의도와 실제 결과물 사이의 간극을 줄여준다. - AI는 더 넓은 방향을 탐색하고 더 많은 시안을 만드는 데 도움을 주지만, 어떤 결과가 적절한지 판단하는 기준은 제공하지 못한다. - 결과물에 반복적으로 쌓인 의도적 선택이 결국 “이 사람만 만들 수 있는 것”이라는 고유성을 만든다. 결국 감각을 기른다는 것은 자신의 분야를 사랑하고, 사용자와 결과물을 세심하게 배려하며, 반복해서 선택하고 수정하는 일이다. AI를 활용하더라도 첫 결과물을 그대로 받아들이기보다 다양한 가능성을 탐색한 뒤 자신의 기준으로 엄격하게 선별하고 다듬는 것이 바람직하다.

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

AI디자인 시스템프로덕트 디자인user-experience-design+1

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

AI 도구로 아이디어를 제품으로 발전시키는 4가지 새로운 방법 | Figma 블로그

AI 도구는 제품 개발의 시작점을 아이디어나 정적 목업에서 실행 가능한 프로토타입으로 확장하고 있다. 팀은 코드를 통해 복잡한 제약과 실제 데이터를 먼저 검증한 뒤 Figma에서 함께 탐색·개선하고, 필요하면 디자인 맥락을 유지한 채 다시 코드로 돌아갈 수 있다. 글은 FloQast, Merkle, Affirm, Accor의 사례를 통해 속도와 의도적인 협업을 결합하는 네 가지 AI 기반 워크플로를 소개한다. ## AI 시대의 제품 개발 방식 변화 - 제품팀은 초기부터 프로토타입을 만들며 아이디어를 검증하는 방향으로 이동하고 있다. - AI 코딩 도구를 활용하면 디자이너나 기획자도 개발자의 큰 투입 없이 복잡한 상호작용을 시험할 수 있다. - 제품 탐색은 코드, Figma 캔버스, 다시 코드로 이어지는 순환형 과정이 된다. - AI는 탐색 범위를 넓힐 뿐 아니라, 기존에 핸드오프 과정에서 사라지던 디자인 시스템과 맥락을 개발 단계까지 전달하는 데 활용된다. ## 코드로 복잡한 제약 검증 - 정적 목업만으로 평가하기 어려운 다음과 같은 상황을 코드 기반 프로토타입으로 테스트할 수 있다. - 한 작업이 완료되어야 다음 작업이 활성화되는 다단계 흐름 - 실제 데이터에 따라 화면과 동작이 달라지는 인터페이스 - 사용자 권한, 조건부 상태, 외부 시스템 간 데이터 일치 여부 - 제품 담당자는 AI 코딩 도구로 실제 동작하는 프로토타입을 만들고, 이후 **Codex to Figma**를 통해 Figma 캔버스로 가져와 팀과 함께 검토할 수 있다. - 디자인에서 추가 조정이 필요하면 Figma에서 작업한 뒤 MCP를 통해 코드로 되돌릴 수 있으며, 디자인 맥락도 함께 유지된다. ## FloQast의 복잡한 회계 워크플로 테스트 ### 문제 상황 - FloQast의 회계 소프트웨어에서는 작업 간 의존성, 결제 처리업체와 은행 간 기록 대조, 검토 및 승인 절차 등이 중요하다. - 기존 워크플로에서는 사용자가 불일치를 확인하기 위해 여러 페이지를 오가야 했다. - 팀은 작업 목록, 차단된 작업, 문제 해결 기능을 하나의 화면에 통합하려 했다. - 초기 프로토타입은 가능성을 보였지만, 실제 데이터와 연결된 여러 단계의 상호작용을 정적 디자인만으로는 검증하기 어려웠다. ### AI 코딩 프로토타입의 활용 - UX 매니저 Benjamin Ellis는 AI 코딩 도구로 시뮬레이션 백엔드와 실제 고객 워크플로를 기반으로 한 현실적인 데이터를 구성했다. - 팀은 한 단계의 완료가 다음 단계의 상태를 바꾸는 실제 시나리오를 직접 실행했다. - 겉보기에는 자연스러워 보였지만 실제 데이터와 로직을 적용하면 무너지는 흐름을 조기에 발견했다. ### 결과와 적용 시점 - 디자인 방향을 확정하기 전에 실제 시나리오를 충분히 검증해 후속 개발 단계의 예상치 못한 문제를 줄였다. - 다음과 같은 경우에 이 방식을 적용할 수 있다. - 권한이나 조건에 따라 UI 동작이 달라지는 경우 - 한 동작이 다른 동작과 상태에 연쇄적으로 영향을 주는 경우 - 작은 수정은 디자인 툴을 거치는 것보다 코드에서 직접 처리하는 편이 빠른 경우 - 디자이너와 개발자가 복잡한 경험을 함께 정의해야 하는 경우 정적인 화면을 먼저 완성하려 하기보다, AI 도구로 실제 데이터와 로직을 포함한 작동 가능한 프로토타입을 빠르게 만든 뒤 디자인과 개발을 오가는 방식이 효과적이다. 특히 복잡한 제품일수록 초기 코드 검증을 통해 잘못된 상호작용을 일찍 발견하고, Figma를 협업과 refinement의 공간으로 활용하는 것이 유리하다.

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

Figma디자인 시스템프로토타이핑모델 컨텍스트 프로토콜+4

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

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 캔버스 협업이 안정화된다면 디자이너와 개발자가 실제 제품 코드를 함께 발전시키는 실용적인 워크플로가 될 수 있다.

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

AI 에이전트collaborationfigma-makedesign-to-code+3

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

이슈 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 같은 도구를 활용하되, 최종 방향과 품질 기준은 사람이 명확히 관리해야 한다.

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

FigmaAI모델 컨텍스트 프로토콜design-to-code+2

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

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-make+3

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

누구나 만들 수 있을 때 중요한 것 | Figma 블로그

AI로 누구나 제품을 빠르게 만들 수 있는 시대에는 구현 속도보다 무엇을 만들지 정하는 방향성이 더 중요하다. 좋은 팀은 여러 가능성을 동시에 탐색하고, 실제에 가까운 프로토타입으로 비교한 뒤, 선택한 방향을 반복적으로 다듬어 자신만의 결과물로 만든다. 결국 경쟁력은 속도·방향·완성도를 함께 갖추는 데서 나온다. ## 속도보다 방향이 중요해진 이유 - 과거에는 아이디어를 실제 제품으로 구현하는 능력과 코딩 역량이 큰 차별점이었다. - AI와 새로운 제작 도구로 상상과 구현 사이의 간격이 거의 사라지면서, 빠르게 만드는 능력은 기본 조건이 되었다. - 빠른 실행은 잘못된 방향으로 달리는 문제를 가릴 수 있다. - 모두가 빠르게 만들 수 있다면 차별점은 “얼마나 빨리 만들었는가”가 아니라 “무엇을 만들 가치가 있다고 판단했는가”가 된다. ## 첫 아이디어에 매몰되는 문제 - 초보 빌더는 첫 아이디어를 선택한 뒤 개선과 반복에 집중하기 쉽다. - 이 과정은 출발점을 재검토하지 않는 **국소 최적화(hill-climbing)**와 비슷하다. - 초기 선택에 따라 이후 의사결정이 결정되는 경로 의존성이 생길 수 있다. - AI 에이전트는 사용자의 첫 요청을 빠르고 친절하게 발전시키지만, 더 나은 대안을 스스로 제시하거나 터널 비전을 깨뜨리지는 못할 수 있다. - 결과적으로 아이디어를 깊게 발전시키기는 하지만, 애초에 가장 좋은 아이디어였는지는 검증하지 못한다. ## 넓게 탐색하되 실제 경험까지 검증하기 - 숙련된 팀은 먼저 선택지를 넓게 펼친다. - 서로 겹치지 않으면서 전체 가능성을 포괄하는 **MECE(Mutually Exclusive, Collectively Exhaustive)** 방식으로 방향을 정리하고 장단점을 비교한다. - 반대로 2x2 매트릭스나 와이어프레임처럼 추상적인 자료만으로는 실제 사용자 경험에 대한 확신을 얻기 어렵다. - 효과적인 방법은 여러 방향을 동시에 탐색하면서 각각을 충분히 구체화하는 것이다. - AI를 활용하면 하나의 문제에 대해 여러 인터랙티브 프로토타입을 병렬로 제작하고, 각 방향을 실제 제품처럼 비교할 수 있다. - 팀원과 AI가 함께 프로토타입을 사용하고 피드백을 나누면 추상적인 아이디어가 아니라 구체적인 경험을 기준으로 판단할 수 있다. - 이는 순차적이고 분리된 작업 방식에서 벗어나, 여러 사람이 여러 방향을 동시에 실험하는 협업 방식이다. ## 평균적인 결과를 넘어 자신만의 제품 만들기 - 누구나 빠르게 만들 수 있게 되면 제품은 검증된 패턴과 일반적인 디자인으로 수렴하기 쉽다. - AI는 통계적으로 성공 가능성이 높은 UI와 기능을 제안하지만, 그것이 반드시 깊이 고민된 제품 경험을 의미하지는 않는다. - 사용자가 AI의 첫 결과물을 그대로 받아들이면 제품은 서로 비슷하고 무난해진다. - 진짜 위험은 능력 부족이 아니라 첫 제안에 수동적으로 동의하고, “그럴듯해 보인다”는 이유로 멈추는 태도다. - 기억에 남는 제품은 기능적으로 작동하는 것에서 끝나지 않고, 제작자의 명확한 관점과 의도를 드러낸다. - 이를 위해 각 결정을 다시 질문하고, 불필요한 요소를 제거하며, 여러 번 수정하고 다듬어야 한다. - 완성도 높은 결과를 만드는 일은 타고난 감각만의 문제가 아니라, 반복적으로 보고 판단하고 개선하는 훈련의 결과다. ## 지금 중요한 세 가지 역량 - **속도**: 아이디어를 빠르게 실험하고 프로토타입으로 구현한다. - **방향**: 여러 가능성을 비교해 만들 가치가 있는 문제와 해법을 선택한다. - **완성도와 장인정신**: AI가 만든 기본 결과를 넘어 제품의 의도와 개성을 구체화한다. - 최고의 팀은 이 세 가지를 서로 맞바꾸지 않고, 빠르게 움직이면서도 신중하게 선택하고 집요하게 개선한다. 실무에서는 하나의 아이디어를 곧바로 개발하기보다 여러 방향의 프로토타입을 병렬 제작하고, 실제 사용자 경험을 비교한 뒤 선택하는 방식이 효과적이다. AI의 결과물은 출발점으로 활용하되 그대로 받아들이지 말고, 제품의 목적과 차별성이 분명해질 때까지 반복적으로 수정하는 것이 좋다.

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

AI사용자 경험프로덕트 디자인product-development+2

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

피그마 디자인 에이전트가 출시되었습니다 | 피그마 블로그

Figma는 캔버스 안에서 직접 작동하며 디자인 시스템과 팀의 작업 맥락을 이해하는 전용 디자인 에이전트를 공개했다. 이 에이전트는 AI 생성과 직접 조작 중 하나를 선택하게 하지 않고, 아이디어 탐색부터 반복 수정·대량 편집까지 디자이너의 작업을 보조한다. Figma는 이를 통해 속도와 정밀성, 자동화와 디자이너의 통제력을 함께 확보하려 한다. ## 캔버스에 통합된 Figma 디자인 에이전트 - 에이전트는 Figma 캔버스와 왼쪽 레일에서 바로 사용할 수 있다. - 특정 디자인 레이어에서 프롬프트를 시작할 수 있다. - 여러 프롬프트를 병렬로 실행해 다양한 아이디어를 동시에 비교할 수 있다. - 사용자가 직접 편집하는 동안 에이전트도 계속 반복 작업을 수행할 수 있다. - 별도의 도구 설정이나 컨텍스트 전환 없이 팀과 같은 파일 안에서 협업자처럼 작동한다. - 컴포넌트, 디자인 토큰, 변수, 표준, 모범 사례 등 Figma 내부의 디자인 시스템 맥락을 이해하도록 설계됐다. ## Figma 에이전트와 MCP 서버의 역할 분담 - **Figma 에이전트** - 캔버스 안에서 디자인을 생성하고 수정하는 데 적합하다. - 현재 파일과 디자인 시스템에 대한 추가 맥락을 활용한다. - Figma 파일을 직접 편집하며 결과물을 바로 조작할 수 있다. - **MCP 서버와 `use_figma`** - 코드를 캔버스로 가져오거나 디자인을 다시 코드로 보내는 작업에 사용한다. - 코드와 Figma 사이를 오가며 디자인 충실도를 유지할 수 있다. - 두 방식은 경쟁 관계가 아니라, 캔버스 작업과 코드-디자인 간 연결을 각각 담당한다. ## 다양한 디자인 방향 탐색 - 첫 번째 아이디어나 프롬프트에 머무르지 않고 여러 방향을 빠르게 실험할 수 있다. - 같은 문제에 대해 서로 다른 스타일의 시안을 여러 개 생성할 수 있다. - 예: 유기적 스타일, 현대적 스타일, 복고풍 스타일 - 서로 다른 비즈니스 목표에 맞춘 결제 흐름이나 정보 구조를 비교할 수 있다. - Figma Design에서 흐름, 상태, 문구, 구조를 구체화한 뒤 Figma Make로 보내 동작을 위한 코드 레이어를 생성할 수 있다. - 반대로 Figma Make에서 만든 프레임을 Figma Design으로 가져와 에이전트로 다듬은 뒤 다시 Make로 보낼 수도 있다. ## 디자인 시스템을 활용한 생성과 반복 - 에이전트는 자주 사용되거나 최근 사용된 컴포넌트를 우선 활용한다. - 특정 라이브러리를 선택하거나 토큰·변수·컴포넌트를 `@` 멘션해 결과를 세밀하게 통제할 수 있다. - 디자인 시스템에 맞는 화면을 생성하고 기존 디자인을 새로운 스타일로 리믹스할 수 있다. - 예시 작업: - 모바일 앱용 가로 스크롤 이미지 캐러셀 생성 - 이미지 위·아래에 제목을 배치한 여러 버전 비교 - 특정 디자인을 여러 시각적 스타일로 변환 - AI가 평균적인 결과물을 빠르게 만드는 데 그치지 않도록, 여러 대안을 비교한 뒤 최종 방향은 디자이너가 직접 선택하고 조작하도록 한다. ## 반복적인 대량 작업 자동화 - 에이전트는 맥락과 정밀성이 필요한 단순 반복 작업을 자동화한다. - 대표적인 활용 사례: - 파일 전체의 타이포그래피 업데이트 - 여러 화면의 동일 컴포넌트 일괄 교체 - 전체 플로우의 패딩 값 변경 - 변수 이름 일괄 변경 - 그리드 전체의 Lorem ipsum과 이미지를 실제에 가까운 콘텐츠로 교체 - 칩 컴포넌트를 모두 활성 상태로 변경 - 화면을 다크 모드로 변환 - 디자인 시스템 관리자는 라이브러리의 설명, 태그, 사용 사례, 컴포넌트 문서와 명명 규칙을 대량으로 정리할 수 있다. ## 코드와 디자인 사이의 연속적인 흐름 - 코드에서 시작한 결과물을 Figma의 코드-투-캔버스 기능으로 가져와 디자인 시스템을 적용하고 시각적으로 반복 수정할 수 있다. - 수정된 디자인은 MCP 서버를 통해 다시 코드로 전달할 수 있다. - 이 과정에서 Figma 에이전트가 캔버스 작업을 지원해 코드와 디자인 간 이동 중에도 작업 흐름과 맥락을 유지한다. - AI 지원과 직접 조작을 필요에 따라 오갈 수 있어, 모든 작업을 프롬프트로 해결하지 않아도 된다. 디자인 방향을 넓게 탐색할 때는 에이전트를 활용하고, 최종 선택과 세밀한 조정은 캔버스에서 직접 수행하는 방식이 가장 실용적이다. 특히 디자인 시스템을 사용하는 팀은 컴포넌트·토큰 기반의 대량 수정과 코드-디자인 동기화에 에이전트를 효과적으로 활용할 수 있다.

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

AI디자인 시스템생성형 AI모델 컨텍스트 프로토콜+2

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

Friends of Figma의 브랜드 리뉴얼이 글로벌 커뮤니티의 이야기를 전하다 | Figma 블로그

Friends of Figma는 전 세계 지역 커뮤니티의 다양성과 연결성을 표현하기 위해 브랜드를 새롭게 개편했다. 새 디자인은 Figma와의 연관성은 유지하면서도 각 지역 챕터가 도시와 문화를 반영해 자유롭게 활용할 수 있도록 설계됐다. 핵심은 통일된 결과물을 강요하기보다, 공통된 정신과 최소한의 규칙 안에서 챕터들이 직접 브랜드를 소유하고 발전시키도록 하는 것이다. ## 전 세계로 확장된 Friends of Figma - Friends of Figma는 Figma 사용자를 연결하고 서로 배우며 영감을 나누는 공식 사용자 그룹 프로그램이다. - 2026년 기준 전 세계 **82개국, 250개 이상의 챕터**가 운영되고 있다. - 지난해에는 워크숍, 웨비나, 디자인 토크, 시청 파티, 친목 모임 등 **900개 이상의 행사**가 열렸다. - 2018년부터 커뮤니티 주도의 모임이 형성됐고, Figma는 2020년 Friends of Figma 프로그램을 출범해 챕터 리더 선정, 행사 지원, 신기능 사전 공개 등을 제공했다. - AI로 산업이 빠르게 변화하는 상황에서, 지역 기반의 실제 만남과 사람 간 연결이 더욱 중요해졌다는 점이 브랜드 개편의 배경이다. ## Figma와 연결되면서도 지역적인 브랜드 - 새 디자인 시스템은 두 가지 목표를 동시에 추구한다. - Figma와 구별되지만 Figma의 정체성은 유지할 것 - 각 챕터가 도시와 지역의 특성을 반영해 자신만의 방식으로 표현할 수 있을 것 - Figma 브랜드와 연결된 시각적 정체성은 지역 커뮤니티가 신규 참가자와 후원자를 유치하는 데 도움을 준다. - 특히 디자인 커뮤니티가 충분히 형성되지 않은 지역에서는 Figma와의 공식적인 연계가 신뢰와 참여를 높이는 역할을 한다. - 이 시스템은 모든 챕터가 똑같은 결과물을 만드는 방식이 아니라, 공통된 정신을 공유하는 **민주적 디자인 시스템**을 지향한다. ## Figma 로고의 기본 형태를 활용한 심벌 - 새 Friends of Figma 로고는 기존 Figma 로고를 구성하는 기본 도형을 분리해 새로운 조합의 building block으로 활용한다. - 각각의 도형은 서로 다른 지역 챕터를 상징하고, 이들이 모여 하나의 글로벌 커뮤니티를 구성한다는 의미를 담는다. - 따라서 로고는 단순한 브랜드 변형이 아니라, 독립적인 챕터들이 공동체로 연결되는 과정을 시각화한다. ## 제약을 줄이고 창의성을 여는 디자인 규칙 - 브랜드 가이드라인은 색상, 챕터 배지, 스티커 등 기본적인 공통 요소를 제공한다. - 모든 챕터는 핵심 색상 체계를 공유하지만, 제공된 팔레트에서 **추가 색상 6개를 직접 선택**할 수 있다. - 스티커 템플릿은 최소한의 형태만 제공하며, 그 안에 어떤 그래픽과 메시지를 담을지는 각 챕터가 결정한다. - 즉, 브랜드가 모든 표현을 통제하기보다 “창의성을 발휘할 수 있을 만큼만 제한”하는 접근이다. - 최종 결과물보다 각 지역의 사람, 장소, 행사처럼 실제 커뮤니티를 구성하는 요소가 중심이 된다. ## 지역의 현실을 담는 사진과 콘텐츠 - 새 사진 가이드는 전문적인 연출보다 지역의 일상과 거리에서 포착되는 모습을 중시한다. - 해당 지역 주민이 알아볼 수 있는 장소와 분위기, 실제 행사 참여자의 모습을 통해 챕터의 정체성을 표현한다. - 이를 통해 Friends of Figma가 전 세계적으로 통일된 브랜드이면서도, 서울·상파울루·바쿠·나이로비 등 각 지역에서 서로 다른 모습으로 존재하도록 한다. ## 실용적인 시사점 - 글로벌 커뮤니티 브랜드는 모든 지역에 동일한 디자인을 적용하기보다, **공통 요소와 지역 자율성의 균형**을 설계하는 것이 효과적이다. - 브랜드 가이드라인을 세밀하게 통제하기보다 핵심 원칙, 기본 자산, 선택 가능한 범위를 제공하면 참여자들의 소유감과 창의성을 높일 수 있다. - 특히 사용자 그룹이나 지역 지부를 운영하는 조직이라면 로고보다 실제 사람과 장소, 활동이 드러나는 콘텐츠를 브랜드의 중심에 두는 것이 바람직하다.

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

Figma디자인 시스템brandingvisual-identity+1

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

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

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

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

Figma디자인 시스템생성형 AIReact+2

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

PGKeeper: Postgres에 꼭 필요했던 보안관 만들기 | Figma 블로그

Figma는 데이터베이스 트래픽과 제품 규모가 커지면서 기존 PgBouncer의 확장성·부하 제어·연결 관리 한계에 부딪혔고, 이를 대체할 자체 서비스 PGKeeper를 구축했다. PGKeeper는 DBProxy와 PostgreSQL 사이에서 연결 풀링과 트래픽 관리를 담당하며, 과부하로부터 데이터베이스와 연결을 보호하는 것을 목표로 한다. 글은 Figma의 데이터베이스 구조와 PgBouncer를 교체하게 된 이유, 그리고 PGKeeper를 직접 개발한 배경을 설명한다. ## Figma의 PostgreSQL 데이터베이스 구조 - PostgreSQL은 Figma의 OLTP 시스템 기반이다. - 데이터 증가에 대응하기 위해 데이터베이스를 수평·수직으로 확장하고 여러 PostgreSQL 인스턴스를 운영했다. - 애플리케이션이 샤딩 구조를 직접 알 필요 없도록 **DBProxy**라는 요청 라우팅 계층을 구축했다. - DBProxy는 쿼리를 분석해 적절한 PostgreSQL 인스턴스를 선택하고, 필요하면 여러 인스턴스를 대상으로 쿼리를 재작성한다. - DBProxy와 PostgreSQL 사이에는 연결 풀러가 위치한다. - 각 PostgreSQL 머신에는 전용 연결 풀러 복제본 그룹이 배치되어, 여러 풀러가 하나의 데이터베이스에 연결되는 n-to-1 구조를 이룬다. ## PgBouncer가 한계에 도달한 이유 - **확장성 부족** - PgBouncer는 단일 스레드 아키텍처라 수직 확장에 한계가 있었다. - 복제본을 늘려 수평 확장했지만 트래픽 분배가 치우치면서 성능 저하가 발생했다. - **정교한 부하 관리 부재** - 중요한 트래픽을 낮은 우선순위의 문제성 트래픽보다 먼저 처리할 수 없었다. - 백프레셔가 없어 급격한 트래픽 증가를 우아하게 제어하기 어려웠다. - 대기 시간에 기반해 작업을 버리는 CoDel(Controlled Delay) 같은 부하 완화 알고리즘도 지원하지 않았다. - **연결 폭증과 연결 churn 위험** - PostgreSQL 연결은 많은 자원을 사용한다. - 연결이 빠르게 생성되거나 과도하게 재생성되면 데이터베이스 안정성이 크게 떨어진다. - 장애 이후 무제한으로 연결을 다시 만들면 복구 과정 자체가 PostgreSQL을 압박할 수 있다. - 이로 인해 연결 churn과 연쇄적인 과부하가 장시간 지속될 수 있다. - **확장성과 운영 제어의 한계** - 트래픽 유형별 admission control, 공정한 자원 분배 등 세밀한 정책이 필요했다. - 심층적인 관측성, 기능 플래그 기반의 안전한 롤아웃도 요구됐다. - PgBouncer에 작은 수정 사항을 유지하는 것만으로도 부담이 컸기 때문에, 대규모 확장은 장기적인 유지보수 비용을 초래할 가능성이 컸다. ## DBProxy에 연결 풀링을 통합하지 않은 이유 - PostgreSQL 인스턴스 하나의 연결 풀은 대략 100개 규모로 운영됐다. - 반면 DBProxy는 수백 개의 상태 비저장 복제본으로 구성됐다. - 각 DBProxy가 독립적으로 연결 풀을 관리하면: - 전체 PostgreSQL 연결 제한을 초과할 수 있고, - 복제본 간 복잡한 조정이 필요하며, - 고정된 소규모 연결 풀을 수백 개 인스턴스에 분산하기 어렵다. - 따라서 연결 풀링은 DBProxy 내부가 아니라 별도의 중앙화된 계층에서 담당해야 했다. ## PGCat 대신 자체 서비스를 만든 배경 - Figma는 PgBouncer의 단일 스레드 한계를 해결하기 위해 멀티스레드 PostgreSQL 프록시인 PGCat도 검토했다. - 그러나 필요한 기능을 추가하려면 PGCat의 핵심 실행 경로를 크게 수정해야 했다. - 관측성, 기능 플래그, admission control을 upstream에 반영하기도 쉽지 않았다. - 결국 PGCat을 포크해 장기적으로 유지해야 할 가능성이 높았으므로, Figma는 요구사항에 맞는 Go 기반 자체 서비스 **PGKeeper**를 개발했다. ## PGKeeper의 역할 - PGKeeper는 DBProxy와 PostgreSQL 사이에 위치하는 Go 서비스다. - 주요 목적은 다음과 같다. - 데이터베이스를 과도하거나 잘못된 트래픽으로부터 보호 - PostgreSQL 연결의 급격한 생성과 churn 방지 - 트래픽 우선순위와 자원 사용을 세밀하게 제어 - 대규모 환경에 맞는 확장성과 운영 도구 제공 - 이름은 골키퍼처럼 위험한 트래픽이 시스템을 압도하지 못하도록 막고, 연결 자체도 보호한다는 의미에서 붙여졌다. Figma의 사례는 단순히 연결 풀러를 교체한 것이 아니라, 데이터베이스 앞단에서 트래픽을 선별하고 과부하를 제어하는 별도 인프라 계층이 필요해졌음을 보여준다. PostgreSQL 연결 수가 제한적이고 프록시 복제본이 많은 환경에서는 풀링을 애플리케이션 프록시에 분산하기보다, 독립적인 계층으로 관리하는 편이 적합하다.

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

PostgreSQLGodatabase-shardingload-balancing+3