Figma/디자인 시스템

246 개의 포스트

figma3분 읽기큐레이션 요약

Figma Slides를 통해

Figma Slides는 프레젠테이션 제작에 Figma의 정교한 디자인 기능과 협업 방식을 결합한 도구다. 오픈 베타를 종료하고 정식 제공되면서 영상 편집, 컴포넌트, 객체 단위 애니메이션, PPTX 호환 기능을 추가했다. 이를 통해 디자이너뿐 아니라 개발자·영업·마케팅 등 다양한 팀이 브랜드에 맞는 고품질 발표 자료를 함께 만들 수 있다고 강조한다. ## Figma Slides의 정식 출시와 주요 기능 - Figma Slides가 오픈 베타를 종료하고 Full, Dev, Collab 좌석 사용자에게 정식 제공된다. - 지금까지 30개 이상의 기능과 업데이트가 출시됐다. - 새롭게 추가된 기능은 다음과 같다. - **영상 개선:** 편집기 안에서 영상 재생과 제어가 가능하며, 블러 효과·구간 탐색·재생 속도 조절을 지원한다. - **컴포넌트:** 브랜드 자산, 고객 로고 등 반복 요소를 컴포넌트로 관리해 디자인 일관성을 유지할 수 있다. - **객체 단위 애니메이션:** 슬라이드 전체가 아니라 개별 레이어에 슬라이드·페이드 애니메이션을 적용할 수 있다. - **PPTX 가져오기·내보내기:** 기존 PowerPoint 파일을 편집하거나 외부 협업자와 공유할 수 있다. - 오토 레이아웃, 사용자 지정 폰트, 연결된 브랜드 라이브러리, 임베드 가능한 프로토타입 등 기존 Figma 기능도 Slides에서 활용할 수 있다. ## 디자인 시스템과 템플릿으로 품질 유지 - Figma에 구축한 디자인 시스템의 자산과 컴포넌트를 슬라이드에 직접 가져올 수 있다. - Merkle은 글로벌 디자인 시스템의 컴포넌트를 기반으로 하되, 프레젠테이션에 적합하도록 선별한 템플릿을 운영한다. - UI/UX 디자인, 리서치, 데이터 시각화, 고객별 발표 등 목적에 맞춘 템플릿과 스타일을 별도로 구성할 수 있다. - 템플릿을 통해 팀원이 처음부터 많은 디자인 결정을 내리지 않아도 되므로, 전체 결과물의 품질 기준을 높일 수 있다. - 브랜드 라이브러리와 재사용 가능한 레이아웃을 활용하면 일관성을 유지하면서도 발표 목적에 맞게 자료를 수정할 수 있다. ## 브랜드에 맞춘 영업 자료 제작 - Decagon은 회사의 3D 브랜드 이미지에서 색상 영감을 얻은 템플릿을 제작해 영업 덱에 적용했다. - 브랜드의 디자인과 자산을 활용하면서도 세부적인 시각 요소까지 통제할 수 있도록 구성했다. - 고객의 우선순위에 따라 조합할 수 있는 다양한 부록 레이아웃도 포함했다. - 고객별 성공 기준에 맞춰 발표 자료를 구체화할 수 있어, 브랜드 인상과 영업 성과 모두에 영향을 줄 수 있다고 설명한다. - 단순히 정보를 나열하는 슬라이드가 아니라, 브랜드 정체성과 고객 맥락을 함께 전달하는 스토리텔링 도구로 활용된다. ## 대상에 맞춰 발표 흐름 조정 - 좋은 프레젠테이션은 청중에 따라 강조점과 순서를 바꿔야 한다. - 그리드 뷰로 전체 슬라이드를 한눈에 확인하면서 핵심 메시지와 적절한 도입부를 찾을 수 있다. - 슬라이드 순서를 쉽게 재배치해 투자자, 고객, 내부 구성원 등 대상별 내러티브를 구성할 수 있다. - 초기 스타트업 창업자를 위한 `Raise` 템플릿은 투자 단계, 창업자 구성, 제품 유형에 따라 덱의 구조가 달라져야 한다는 점을 반영한다. - 어떤 발표에서는 인사이트를 먼저 보여주고 팀 소개를 마지막에 배치할 수 있고, 다른 발표에서는 팀의 전문성을 강조하기 위해 팀 소개를 앞에 둘 수 있다. - 중요한 것은 ‘멋진 요소’를 많이 넣는 것이 아니라, 사업을 명확하고 설득력 있는 하나의 아이디어로 압축하는 것이다. ## 여러 직군이 함께 만드는 발표 자료 - Figma Slides는 내부 리뷰, 영업 덱, 고객 프레젠테이션 등 다양한 상황에서 사용할 수 있다. - 디자이너는 브랜드와 시각적 완성도를 관리하고, 개발자와 다른 직군은 같은 작업 공간에서 내용을 보완할 수 있다. - 프로토타입을 직접 삽입해 제품 경험을 발표 자료 안에서 보여줄 수 있다. - 공동 편집 환경을 통해 디자인 결과물과 발표 메시지를 별도 단계가 아니라 하나의 작업 과정으로 연결한다. - 결과적으로 프레젠테이션을 문서 제작 도구가 아니라 팀의 아이디어를 시각화하고 합의를 이끌어내는 협업 공간으로 확장한다. 팀의 브랜드 자산과 디자인 시스템을 이미 Figma에서 관리하고 있다면, Figma Slides의 연결된 라이브러리·컴포넌트·템플릿을 활용하는 것이 효과적이다. 특히 PPTX를 주고받아야 하거나 발표 대상별로 자료를 자주 재구성하는 조직이라면, 디자인 일관성과 협업 효율을 함께 높일 수 있다.

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

eBay가 Figma로 브랜드

eBay는 브랜드와 제품 팀이 따로 관리하던 디자인 시스템을 Figma 중심의 통합 문서 플랫폼인 ‘Evo Playbook’으로 재구축했다. 300쪽이 넘는 Playbook은 접근성, 디자인, 코드 정보를 한곳에 모으고, Figma 변경 사항을 자동 검증·게시해 문서를 살아 있는 업무 흐름으로 만들었다. 핵심은 중앙화된 문서, 라이브러리 메타데이터, Component Status API, Figma 플러그인 자동화다. ## 기존 문서화 방식의 한계 - 디자인 시스템 정보가 여러 Figma 파일에 흩어져 있었다. - 디자이너, 개발자, 접근성 담당자가 각각 별도의 문서를 관리했다. - 디자이너가 Figma의 정적 파일을 수정한 뒤, 별도 티켓을 통해 문서 사이트에 반영해야 했다. - 컴포넌트 상태를 수동 테이블로 관리해 정보가 빠르게 오래되었다. - 외부 에이전시가 만든 기존 Playbook은 실제 eBay의 디자인·개발 업무와 분리되어 유지보수가 어려웠다. ## Evo와 eBay Playbook의 통합 방향 - eBay는 기존 시스템을 부분 수정하지 않고 문서화 파이프라인을 처음부터 다시 설계했다. - 브랜드 가이드, 제품 디자인 시스템, 기술 문서를 별도 사이트가 아닌 하나의 공간에 통합했다. - 2024년 11월 공개된 Evo는 약 30년 된 eBay의 시각 언어를 현대화한 디자인 시스템이다. - 300쪽 이상의 Playbook을 통해 내부 팀과 외부 에이전시가 동일한 기준을 참고할 수 있도록 했다. - 문서를 단순한 참고 자료가 아니라 영감과 사용 경험을 제공하는 제품처럼 설계했다. ## Component Status API로 구현 상태 통합 - eBay는 모든 디자인 시스템 라이브러리의 컴포넌트 상태를 추적하는 내부 API를 만들었다. - Figma 컴포넌트 설명에 컴포넌트 이름과 버전 메타데이터를 기록한다. - API는 다음 라이브러리의 구현 여부와 버전을 통합적으로 확인한다. - Figma 컴포넌트 라이브러리 - 네이티브 라이브러리 - Skin, Marko, React 등 웹 컴포넌트 라이브러리 - Playbook의 컴포넌트 페이지에는 플랫폼별 리소스 링크, 최신 버전, 상태가 표시된다. - 개발자는 자신이 사용하는 프레임워크에 컴포넌트가 존재하는지, Figma 버전 및 문서와 일치하는지 바로 확인할 수 있다. ## Figma 기반 자동화와 게시 - 모든 컴포넌트, 가이드라인, 접근성 안내는 Figma에서 작성하고 수정한다. - eBay는 문서 내보내기 기능을 수행하는 자체 Figma 플러그인을 개발했다. - 플러그인은 변경 내용을 다음과 같이 처리한다. - 문서 구조와 콘텐츠를 추출 - 린팅을 통해 형식과 규칙을 검사 - 유효성을 검증 - CMS에 자동 게시 - 과거에는 문서 업데이트에 며칠이 걸렸지만, 자동화 이후 Figma 수정 사항이 2분 이내에 Playbook에 반영된다. - 개발자가 CMS를 직접 수정할 필요가 없어 문서 업데이트의 진입 장벽이 낮아졌다. ## 브랜드와 제품 조직 사이의 사일로 해소 - OneExperience 팀은 브랜드, 디자인 시스템, 디자인 기술, 콘텐츠를 아우르는 교차 기능 조직으로 구성됐다. - 디자인과 개발 문서가 서로 다른 원천에서 관리되지 않고 동일한 workflow에서 생성된다. - 디자인 시스템 문서가 실제 라이브러리와 자동으로 연결되므로 문서와 구현 사이의 불일치가 줄어든다. - 빠른 업데이트 덕분에 팀들이 문서화를 별도의 행정 업무가 아니라 일상적인 설계 과정의 일부로 받아들이게 되었다. ## 실용적인 적용 시사점 - 디자인 시스템 문서를 정적 웹 페이지로 관리하기보다 실제 설계 도구와 연결된 살아 있는 문서로 운영하는 것이 효과적이다. - 컴포넌트 이름과 버전을 메타데이터로 표준화하면 여러 플랫폼의 구현 상태를 자동으로 추적할 수 있다. - Figma 플러그인, 린터, API를 결합하면 문서 품질 검증과 게시를 자동화할 수 있다. - 브랜드 가이드와 제품 디자인 시스템을 분리하기보다 하나의 소스 오브 트루스로 통합하면 조직 간 협업과 일관성이 향상된다.

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

좋은 동료들과 함께

뉴스 미디어 기업들은 디지털 전환과 구독 경쟁에 대응하기 위해 앱, 서체, 브랜드를 재설계하고 있으며, 이 과정에서 Figma를 협업과 프로토타이핑의 중심 도구로 활용한다. The New York Times 사례는 여러 콘텐츠 제품을 하나의 생태계로 연결하면서도 각 섹션의 정체성을 유지한 앱을 구축한 경우다. Figma는 편집자·디자이너·엔지니어·경영진이 비동기적으로 같은 화면과 프로토타입을 검토하게 해, 저널리즘의 형식 자체를 함께 설계하도록 돕는다. ## 디지털 시대의 뉴스 디자인 과제 - 신문사들은 웹과 모바일 중심으로 사업을 전환하고 새로운 콘텐츠 형식을 실험하고 있다. - 광고 시장의 불확실성으로 구독 모델이 중요해졌지만, 온라인 뉴스 이용자는 비용을 지불하는 데 상대적으로 소극적이다. - 따라서 기존 독자뿐 아니라 새로운 독자와 관계를 형성하고, 디지털 환경에서 뉴스의 정확성·명확성·접근성을 유지해야 한다. - 앱 개편, 서체 개발, 웹사이트 출시처럼 큰 변화에는 다양한 직군의 긴밀한 협업이 필요하다. ## The New York Times의 제품 생태계 중심 앱 개편 - 2024년 10월 개편된 앱은 뉴스뿐 아니라 Games, Cooking, Audio, Wirecutter, The Athletic 등 여러 제품을 하나의 구독 생태계로 연결한다. - 사용자는 앱을 열면 최신 뉴스가 모이는 **Today** 섹션을 먼저 보게 된다. - 상단 내비게이션을 통해 다른 제품과 콘텐츠 영역으로 이동할 수 있으며, 각 영역은 독립적인 홈 화면을 제공한다. - 핵심 전략은 모든 콘텐츠를 하나의 피드에 섞는 ‘슈퍼 앱’이 아니라, 저널리즘을 중심에 두고 각 제품이 고유한 방식으로 확장되는 구조다. ## 섹션별 시각적 정체성 - 각 콘텐츠 영역은 서로 다른 편집 목적과 독자 경험에 맞춰 시각 언어를 갖는다. - Lifestyle은 이미지와 제목을 겹쳐 배치한 그리드형 구성을 사용한다. - The Times가 “poster”라고 부르는 시각 중심 컴포넌트를 활용해 콘텐츠의 주목도를 높인다. - Opinion은 일반 뉴스와 다른 스타일의 제목 표현을 사용해 의견·관점 중심 콘텐츠라는 특성을 드러낸다. - 결과적으로 앱 전체의 일관성을 유지하면서도 각 제품과 섹션의 개성을 구분했다. ## Figma를 활용한 비동기 협업 - 편집자, 엔지니어, 디자이너, 고위 경영진, 스토리텔링 그룹이 하나의 Figma 파일에서 작업했다. - 스토리텔링 그룹은 뉴스룸과 협업해 이미지·텍스트·비디오·오디오를 조합한 다양한 기사 형식을 설계한다. - 팀원들은 화상회의나 화면 공유 없이 Figma에 들어가 작업물을 확인하고 의견을 교환할 수 있었다. - 디자이너는 기존처럼 발표용 덱을 반복해서 만드는 대신, Figma 안에서 직접 프로토타입을 공유했다. - 이를 통해 제품의 화면뿐 아니라 “저널리즘을 어떤 형태로 전달할 것인가”까지 함께 탐색할 수 있었다. ## 다른 미디어 기업의 사례 - 글은 The New York Times 외에도 The Economist의 디지털 친화적 서체 개발 사례를 다룬다. - The Minnesota Star Tribune은 Figma를 활용해 브랜드를 변화시킨 사례로 소개된다. - 세 사례 모두 변화하는 미디어 환경에서 디자인 시스템, 협업, 새로운 콘텐츠 형식이 경쟁력의 핵심이라는 점을 보여준다. ## 실용적인 시사점 - 대규모 디지털 제품을 개편할 때는 콘텐츠·디자인·개발·경영진이 같은 프로토타입을 기준으로 논의하는 것이 효과적이다. - 전체 브랜드의 일관성을 유지하되, 콘텐츠 유형별로 차별화된 시각적 정체성을 설계해야 한다. - Figma 같은 협업 도구를 단순한 화면 제작 도구가 아니라 편집 구조와 콘텐츠 전달 방식을 실험하는 공동 작업 공간으로 활용할 수 있다.

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

의미 있는 지표 만들기 | 디자인

디자인 시스템은 컴포넌트와 문서를 만드는 데서 끝나지 않고, 사용 데이터로 실제 비즈니스 가치를 입증해야 한다. 적절한 지표를 추적하면 디자인 시스템이 작업 속도, 일관성, 확장성에 미친 영향을 정량화하고 투자와 개선의 근거로 활용할 수 있다. Figma의 실험에서는 디자인 시스템을 사용한 디자이너가 그렇지 않은 디자이너보다 작업을 34% 빠르게 완료했다. ### 디자인 시스템의 효과를 수치로 증명하기 - 디자인 시스템 사용으로 얻는 효과는 단순한 시간 절약을 넘어, 제품 전체와 일관된 디자인을 만든다는 자신감 향상으로도 나타난다. - 디자이너 7명이 주당 20시간씩 집중적으로 일하는 팀에서 34%의 효율 향상은 매주 약 3.5명의 디자이너를 추가한 것과 같은 효과다. - Vanguard는 디자인 시스템을 통해 디자인 업데이트 속도를 50% 높였다. - Headspace는 토큰과 변수를 활용해 단순한 작업에서 20~30%, 복잡한 프로젝트에서 최대 50%의 시간을 절약했다. - Swiggy는 체계적인 추적을 도입한 뒤 기능 출시 시간을 절반으로 줄였다. ### 어떤 신호를 측정할 것인가 - **라이브러리 및 컴포넌트 사용량** - 어떤 컴포넌트, 변수, 스타일이 가장 많이 사용되는지 확인한다. - 자주 사용되는 요소는 디자인 시스템의 핵심 자산으로 볼 수 있다. - 사용량이 낮은 요소는 개선하거나 폐기할 후보가 된다. - **도입률** - 팀과 프로젝트가 디자인 시스템을 실제로 얼마나 채택했는지 측정한다. - 시스템이 존재하는 것보다 실제 업무에 활용되는지가 중요하다. - **일관성 점수** - 제품 전반에서 컴포넌트와 스타일이 얼마나 일관되게 사용되는지 확인한다. - 일관성 지표는 디자인 품질과 유지보수성의 변화를 보여준다. - **절약된 시간** - 컴포넌트 재사용으로 줄어든 디자인 시간을 추적한다. - 시간 절약은 이해관계자에게 디자인 시스템의 투자 가치를 설명하기 좋은 지표다. ### 사용량 데이터가 알려주는 것 - 초기에는 컴포넌트 제작과 문서화 자체에 집중하기 쉽지만, 실제 영향력을 파악하려면 adoption과 usage를 함께 측정해야 한다. - 단순히 컴포넌트 수가 많다는 사실보다 어떤 요소가 실제 업무에서 반복적으로 사용되는지가 중요하다. - 데이터는 다음과 같은 개선 방향을 제시한다. - 자주 사용되는 요소의 품질과 문서 개선 - 사용되지 않는 요소의 원인 분석 - 중복 컴포넌트 통합 - 사용성이 낮은 요소의 재설계 또는 폐기 - 이러한 분석을 통해 디자인 시스템을 정적인 리소스가 아니라 지속적으로 개선되는 운영 체계로 만들 수 있다. ### 도구와 자동화의 활용 - 지표를 지속적으로 수집하려면 사용량과 도입률을 수작업으로 조사하기보다 도구와 자동화를 활용해야 한다. - 컴포넌트, 변수, 스타일의 사용 현황을 정기적으로 수집하면 변화 추이를 파악할 수 있다. - 자동화된 측정은 팀 규모가 커져도 동일한 기준으로 성과를 비교하고, 문제를 조기에 발견하는 데 도움이 된다. ### 데이터를 실행으로 연결하기 - 측정 자체가 목적이 아니라, 데이터를 바탕으로 디자인 시스템의 우선순위를 정하는 것이 중요하다. - 사용량이 높은 요소에는 안정성, 접근성, 문서화 개선을 우선 적용할 수 있다. - 도입률이나 일관성이 낮은 영역은 교육, 문서, 지원 프로세스를 보완해야 한다. - 시간 절약과 출시 속도 같은 지표는 디자인 시스템 팀의 활동을 제품 및 비즈니스 성과와 연결해준다. ### 확장을 고려한 측정 - 조직과 제품이 성장할수록 개인의 체감 효과보다 팀 전체의 반복 가능한 지표가 필요하다. - 사용량, 도입률, 일관성, 절약 시간 등을 지속적으로 기록하면 디자인 시스템이 확장 과정에서 효율성을 유지하는지 확인할 수 있다. - 지표는 단순한 보고용 숫자가 아니라, 디자인 시스템의 투자 방향과 운영 방식을 결정하는 기준으로 활용해야 한다. 실무에서는 모든 지표를 한꺼번에 도입하기보다 컴포넌트 사용량, 디자인 시스템 도입률, 작업 시간 절감처럼 측정하기 쉽고 의사결정에 직접 연결되는 지표부터 시작하는 것이 좋다.

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

도입을 이끄는 문서화

디자인 시스템 문서는 컴포넌트 목록을 나열하는 자료가 아니라, 디자인 의도와 구현 방법을 연결해 팀의 실제 사용을 이끄는 제품이어야 한다. 좋은 문서는 디자이너와 개발자 사이의 언어 차이를 줄이고, 일관된 의사결정·효율적인 온보딩·플랫폼 간 품질 유지를 가능하게 한다. 이를 위해 조직에 맞는 단일 진실 공급원(source of truth)을 정하고, 시스템과 함께 계속 진화하는 문서로 운영해야 한다. ## 문서화가 필요한 이유 - Razorpay는 디자인 시스템 Blade를 도입하기 전 팀마다 버튼 상태나 텍스트 필드 오류 처리 방식을 놓치는 일이 있었다. - 문제의 본질은 단순한 품질 부족이 아니라 디자인 의도와 구현 방식이 제대로 전달되지 않는 커뮤니케이션 문제였다. - 개발자와 디자이너 사이의 언어 차이로 다음과 같은 불일치가 발생할 수 있다. - 컴포넌트와 속성의 명칭이 서로 다름 - 디자인의 상태와 실제 코드 구현이 다름 - 제품의 시각적·상호작용적 기대치가 어긋남 - 문서는 단순히 “무엇이 있는가”를 보여주는 데 그치지 않고, 각 결정의 **방법(how)** 과 **이유(why)** 를 설명해야 한다. - 효과적인 문서는 다음을 돕는다. - 디자인 원칙과 구현 세부 사항 이해 - 여러 제품과 플랫폼에서 일관된 결정 - 신규 팀원의 빠른 온보딩 - 디자이너와 개발자 간 협업 개선 ## 단일 진실 공급원 정하기 문서화를 시작할 때 가장 먼저 결정할 것은 무엇을 쓸지가 아니라 **어디에 둘지**다. - 디자인 시스템이 성장하고 조직이 커질수록 정보가 여러 도구에 분산되기 쉽다. - 공유 드라이브의 정적 PDF처럼 한 번 만들어 놓고 갱신하지 않는 방식은 빠르게 낡는다. - 전용 문서 사이트, 협업 워크스페이스 등 조직의 규모와 업무 흐름에 맞는 저장소를 선택해야 한다. - 중요한 것은 도구 자체보다 팀이 “최신 정보는 어디에 있는가”를 명확히 알 수 있게 하는 것이다. - 문서는 디자인 파일, 코드 저장소, 개발자 도구와 연결되어야 하며, 디자이너와 개발자가 같은 기준을 참조할 수 있어야 한다. ## 맞춤형 문서 사이트의 역할 본문은 대규모 조직의 경우 자체 문서 사이트가 디자인 시스템을 도구와 프로세스에 깊이 통합하는 데 유리하다고 설명한다. - 여러 제품과 플랫폼을 운영하는 조직은 전용 사이트를 통해 문서 구조와 탐색 경험을 직접 설계할 수 있다. - 컴포넌트의 시각적 예시뿐 아니라 사용법, 코드 구현, 상태, 접근성 지침까지 한곳에서 제공할 수 있다. - 디자인 시스템이 사용하는 도구와 개발 워크플로에 맞춰 문서를 확장할 수 있다. - 다만 자체 사이트를 구축하는 것만으로는 충분하지 않으며, 최신 상태를 유지하는 운영 체계가 함께 필요하다. ## 도입을 이끄는 살아 있는 문서 - 문서는 디자인 시스템과 별개로 관리되는 부가 자료가 아니라 시스템의 일부여야 한다. - 컴포넌트가 변경되면 관련 사용법과 코드 예시도 함께 갱신되어야 한다. - 문서에는 컴포넌트의 외형뿐 아니라 다음 정보가 포함되어야 한다. - 언제 사용하고 언제 사용하지 않는지 - 지원하는 상태와 속성 - 상호작용 및 오류 처리 방식 - 디자인 결정의 배경과 목적 - 개발자가 실제로 적용할 수 있는 구현 정보 - 사용자가 문서를 읽은 뒤 바로 디자인하거나 코드를 작성할 수 있어야 adoption으로 이어진다. ## 실용적인 결론 디자인 시스템 문서는 “보관용 설명서”가 아니라 팀의 공통 언어이자 제품 사용 경험의 일부로 운영해야 한다. 하나의 공식 출처를 정하고, 디자인·코드·문서의 변경을 연결하며, 각 컴포넌트의 사용법과 설계 이유까지 기록하는 방식이 가장 실용적이다.

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

Config 2025 미리보기

Figma는 2025년 연례 컨퍼런스 Config을 미국 샌프란시스코와 영국 런던, 두 도시에서 개최하며 글로벌 커뮤니티 확장을 추진한다. 샌프란시스코에서는 3일간 대규모 오프라인·온라인 행사를, 런던에서는 유럽 제품 제작자를 위한 하루짜리 행사를 연다. 두 행사 모두 강연뿐 아니라 참가자 간 교류와 직접 제작하는 경험을 강화하는 데 초점을 둔다. ## 두 도시로 확장하는 Config 2025 - Config은 제품을 만드는 사람들을 위한 Figma의 연례 컨퍼런스다. - 2025년에는 다음 두 행사로 운영된다. - **샌프란시스코:** 5월 6~8일, 3일간 진행 - **런던:** 5월 14일, 하루 동안 진행 - 미국 중심이었던 Config의 협업 경험을 유럽과 전 세계 커뮤니티로 확대하려는 시도다. - 지난해 싱가포르 커뮤니티와의 교류 경험을 바탕으로 새로운 지역 개최를 결정했다. ## 샌프란시스코 행사: 대규모 다중 트랙 컨퍼런스 - 5월 6일에는 Moscone Center 인근 Howard Street 전체를 활용한 **Config Commons**에서 행사를 시작한다. - 참가자 등록과 배지 수령 - 다른 참석자 및 Config 커뮤니티 구성원과의 네트워킹 - 5월 7~8일에는 Moscone Center에서 진행된다. - 75명 이상의 연사 - 50개 이상의 세션 - 여러 트랙으로 구성된 프로그램 - 참석자는 관심사에 따라 직접 일정을 구성할 수 있다. - 강연 참석 - 전시장과 설치 작품 탐방 - 새로 만난 사람들과 프로젝트 작업 - 현장 참석뿐 아니라 온라인 등록도 제공된다. - 도시 곳곳의 파트너 호텔에도 체크인 장소를 마련해 배지 수령과 행사 참여를 편리하게 했다. ## 참가자 간 교류를 강화한 공간 설계 - Figma는 과거 참가자 의견을 반영해 Moscone Center의 공간과 동선을 재설계했다. - 강연을 듣는 것에 그치지 않고, 참가자들이 자연스럽게 대화하고 아이디어를 교환하도록 구성했다. - **Maker Space**를 확장하고 별도의 무대를 추가한다. - Figma 커뮤니티 리더들이 최신 작업을 소개 - 참가자들이 실제 제작 사례와 결과물을 공유 - 강연장, 점심 공간, 전시 및 체험 공간 사이의 이동 흐름도 개선해 참가자들이 행사 경험을 끊김 없이 이어가도록 했다. ## 런던에서 유럽 커뮤니티와 연결 - 5월 14일 런던 ExCeL 전시장에서 첫 런던 Config을 개최한다. - 유럽의 디자인 전통과 활발한 기술 산업, 제품 제작자 커뮤니티를 고려해 런던을 개최지로 선정했다. - 프로그램 구성: - 15명 이상의 연사 - 10개 세션 - 유럽 커뮤니티에 맞춘 큐레이션 프로그램 - 현장 티켓은 매진됐지만 온라인 등록은 가능하다. - 런던 행사는 샌프란시스코보다 규모는 작지만, Config의 협업 중심 분위기를 유럽으로 확장하는 데 의미가 있다. ## 실용적인 참고 사항 - 샌프란시스코 행사는 5월 6~8일, 런던 행사는 5월 14일 일정이다. - 현장 참석이 어렵다면 두 행사 모두 온라인 참여 가능 여부를 확인할 수 있다. - 여러 세션이 동시에 진행되므로 참석 전 관심 주제와 시간표를 미리 계획하는 것이 좋다.

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

제너럴리스트

AI가 전문 영역의 작업을 빠르게 수행할수록, 인간에게는 여러 분야의 지식을 연결하고 무엇을 만들어야 하는지 판단하는 능력이 더 중요해진다. 글은 전문성을 버리자는 주장이 아니라, 한 분야의 깊이와 인접 분야의 역량을 결합한 ‘멀티 스페셜리스트’가 미래의 핵심 인재가 될 것이라고 말한다. 특히 디자인·엔지니어링처럼 경계가 흐려지는 영역에서 호기심을 따라 역량을 확장한 사람들이 새로운 직무를 만들어내고 있다. ## 스타트업을 넘어 확산되는 제너럴리스트 - 초기 스타트업에서는 한 사람이 성장 실험, UX 문구 작성, 사용자 온보딩, 마케팅 아이디어 구상 등을 동시에 맡는 일이 흔했다. - 최근에는 대기업과 기술 기업에서도 단일 직무에 갇히지 않고 여러 영역을 연결하는 인재를 찾고 있다. - 대표적인 사례는 다음과 같다. - 브랜드와 퍼포먼스 마케팅을 모두 이해하는 ‘풀스택 마케터’ - 디자인 시스템을 이해하는 프로덕트 매니저 - 다양한 규모의 기업에 판매할 수 있는 세일즈 담당자 - 운영, 인사, 소프트웨어, 3D, 브랜드 스토리텔링을 아우르는 제너럴리스트 직무 ## 전문성은 버리는 것이 아니라 조합하는 것 - 제너럴리스트의 부상은 특정 분야의 깊은 전문성이 더 이상 필요 없다는 뜻이 아니다. - 오히려 전문 지식에 보완적인 역량을 결합해 더 희소한 능력을 만드는 것이 중요하다. - 한 분야를 깊이 파고든 전문가는 해당 영역에서 무엇이 중요한지 직관적으로 판단할 수 있다. - 제너럴리스트는 서로 다른 전문가들의 지식과 관점을 번역하고 연결해 협업을 촉진한다. - 따라서 이상적인 인재는 모든 것을 얕게 아는 사람이 아니라, 하나 이상의 깊은 전문성을 갖고 인접 분야에도 능숙한 ‘멀티 스페셜리스트’에 가깝다. ## 디자인 엔지니어가 보여주는 하이브리드 직무 - 디자인 엔지니어는 디자인과 소프트웨어 엔지니어링 역량을 함께 활용하는 대표적인 하이브리드 직무다. - 아이디어를 실제 작동하는 프로토타입으로 빠르게 구현할 수 있어, 디자인과 개발 사이의 정보 손실을 줄인다. - 동시에 디자인 단계에서 기술적 제약과 구현 가능성을 고려하고, 개발 과정에서 새로운 제품 기회를 발견할 수 있다. - 비판하는 쪽에서는 디자인과 엔지니어링 모두를 희석한다고 보지만, 지지하는 쪽에서는 더 나은 제품을 만들기 위해 필수적인 역할이라고 평가한다. - 많은 디자인 엔지니어는 처음부터 해당 직무를 목표로 한 것이 아니라, 자신의 아이디어를 완성하고 싶다는 호기심을 따라 부족한 기술을 하나씩 익히며 성장했다. - 개인이 발견한 역량의 공백이 산업의 수요와 맞아떨어지면서, 이전에는 존재하지 않던 새로운 경력 경로가 만들어졌다. ## 협업이 직무의 경계를 허문다 - 제품 개발이 점점 더 협업 중심으로 바뀌면서 디자인, 엔지니어링, 콘텐츠, 기획 사이의 경계가 흐려지고 있다. - 제품 디자이너가 엔지니어링 제약을 이해하면 실제로 구현 가능한 해결책을 제안할 수 있다. - 작가나 콘텐츠 담당자가 구현 방식을 이해하면 더 일관성 있고 실행 가능한 문서와 메시지를 만들 수 있다. - 이런 사람들은 여러 분야를 얕게 건드리는 ‘잡다한 사람’이 아니라, 서로 연결되는 분야에서 깊이를 쌓아가는 인재다. - 한 분야의 언어와 사고방식을 다른 분야로 전달하는 능력이 이들의 핵심 경쟁력이다. ## AI 시대에 커지는 연결과 판단의 가치 - AI는 명확한 범위와 규칙이 있는 전문 작업을 점점 더 정교하게 처리하고 있다. - 따라서 단순히 특정 기술이나 지식을 보유하는 것만으로는 차별화하기 어려워질 수 있다. - 글이 말하는 ‘allocation economy’에서는 자원과 관심이 제한되어 있기 때문에, 중요한 문제를 선택하고 집중하는 능력이 경쟁력이 된다. - 인간에게 더 중요한 능력은 다음과 같다. - 서로 다른 분야를 연결하는 질문을 제시하는 능력 - 무엇이 가능한지뿐 아니라 무엇을 만들어야 하는지 판단하는 감각 - 여러 전문가의 관점을 통합하는 능력 - AI가 생성한 결과물 중 가치 있는 방향을 선택하는 능력 - 좋은 프롬프트가 AI의 능력을 끌어내듯, 분야를 넘나드는 좋은 질문은 예상하지 못한 해결책을 이끌어낼 수 있다. ## 경력 개발에 대한 시사점 - 제너럴리스트 역량은 정해진 직무명을 선택해 얻기보다, 호기심과 실제 문제 해결을 따라가며 형성될 수 있다. - 현재 업무에서 반복적으로 만나는 다른 팀의 문제를 이해하고, 그 분야의 기본 언어와 도구를 익히는 방식이 효과적이다. - 모든 분야를 동시에 배우기보다는 자신의 핵심 전문성을 기준으로 시너지가 큰 인접 분야를 선택해야 한다. - 이렇게 쌓은 조합은 기존 채용 공고에 없던 새로운 역할을 만들어낼 가능성도 있다. 한 분야의 깊이를 유지하면서 협업이 잦은 인접 영역을 확장하고, 여러 전문성을 연결하는 질문과 판단력을 길러야 한다. 앞으로는 ‘무엇이든 조금씩 하는 사람’보다 ‘깊이 있는 전문성을 바탕으로 분야 사이를 연결하는 사람’이 더 큰 가치를 만들 가능성이 높다.

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

제품 로드맵을 벗

제품 로드맵은 방향을 제시하는 도구이지, 반드시 지켜야 하는 계약서가 아니다. AI와 사용자 기대가 빠르게 변하는 환경에서는 사용자 피드백과 실험 결과에 따라 계획을 과감히 수정해야 하며, 이러한 우회와 전환이 오히려 좋은 제품을 만든다. Figma의 Dev Mode 사례는 초기 비전을 고집하기보다 실제 개발자의 문제를 해결하는 방향으로 피벗한 과정을 보여준다. ## 변화한 제품 개발 환경 - AI, 에이전트, 어시스턴트의 발전으로 제품 개발과 사용 방식이 빠르게 변하고 있다. - Claude, Cursor 같은 도구는 프롬프트만으로도 애플리케이션을 만들 수 있다는 기대를 높였다. - 기존의 6~12개월 단위 로드맵과 전통적인 개발 방식만으로는 변화 속도와 사용자 기대를 따라가기 어렵다. - 명확한 계획은 필요하지만, 로드맵을 지나치게 규범적으로 따르면 더 이상 유효하지 않은 방향을 계속 추진할 위험이 있다. ## 비전보다 중요한 유연성과 학습 - 신제품 개발은 계획대로 직선적으로 진행되지 않고, 실험과 실패, 재설계를 반복하는 비선형 과정이다. - 하나의 비전을 끝까지 고수해야 성공한다는 것은 기술 업계의 신화에 가깝다. - 사용자 조사, 내부 직원의 실제 사용(dogfooding), 베타 테스트를 통해 새로운 정보를 얻으면 기존 가정을 수정해야 한다. - 계획을 바꾸는 것은 실패가 아니라 더 나은 사용자 결과에 도달하기 위한 학습 과정이다. ## Dev Mode의 피벗 사례 - Figma는 처음에 Dev Mode를 디자인을 코드로 자동 변환하는 도구로 구상했다. - 초기 코드 생성 기능은 가능성을 보였지만, 개발자들은 생성된 코드가 실제 업무에 항상 유용하지 않다고 피드백했다. - 디자인 시스템을 사용하는 개발자들은 새 코드를 생성하기보다 이미 작성된 컴포넌트를 조합하는 데 더 많은 시간을 썼다. - Figma는 코드 생성에 계속 투자하는 대신 **Code Connect**를 개발했다. - 개발자가 디자인 시스템의 실제 코드 스니펫을 직접 연결할 수 있다. - Dev Mode에서 자동 생성 CSS가 아니라 팀이 사용하는 컴포넌트 코드를 보여준다. - 이 전환으로 출시가 늦어지고 기존 방향을 추진하던 팀원들이 좌절하는 비용이 발생했지만, 사용자에게 더 적합한 제품에 가까워질 수 있었다. ## 로드맵을 수정하는 데 따르는 비용 - 방향 전환은 이미 투입한 시간과 자원을 포기해야 하므로 조직적으로 쉽지 않다. - 기존 작업을 중단하면 출시 일정이 지연되고, 팀의 사기가 떨어질 수 있다. - 그러나 매몰비용 때문에 효과가 낮은 기능을 계속 개발하면 더 큰 손실로 이어진다. - Figma는 Dev Mode 베타 이후 로드맵보다 사용자 피드백을 우선했고, 한 달 동안 200개가 넘는 수정 사항과 신규 기능을 출시했다. ## 성공적인 제품은 전환을 통해 성장한다 - Loom은 기업에 제품 피드백을 제공하는 전문가 네트워크에서 출발했지만 여러 번 피벗한 끝에 현재의 비디오 녹화 플랫폼이 되었다. - Slack 역시 온라인 멀티플레이어 게임인 Glitch에서 시작해 협업 도구로 전환했다. - 이 사례들은 초기 아이디어를 끝까지 지키는 것보다, 새로운 학습을 바탕으로 사업과 제품의 방향을 바꾸는 것이 중요하다는 점을 보여준다. - 좋은 제품은 우여곡절 때문에 망가지는 것이 아니라, 그 우여곡절을 통해 정의된다. ## 실무에서의 적용 - 상세한 사양과 디자인을 확정하기 전에 빠른 프로토타입으로 가설을 검증한다. - 베타 사용자와 내부 사용자에게서 반복적으로 나타나는 문제를 로드맵보다 우선한다. - 제품이 시장이나 사용자에게 제대로 도달하지 못한다면 처음부터 다시 시작하는 결정을 고려한다. - 매몰비용이나 기존 방법론에 얽매이지 말고, 현재 환경에서도 유효한지 오래된 가정을 재검토한다. - 로드맵은 고정된 약속이 아니라, 언제 계획을 따르고 언제 방향을 바꿀지 판단하기 위한 기준으로 활용하는 것이 바람직하다.

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

이제 디자인의 정의를 확장할 때

디자인은 디자이너라는 직함을 가진 사람만의 업무가 아니라, 마케팅·제품·영업 등 다양한 직군이 시각적으로 문제를 해결하고 소통하는 과정이라는 것이 글의 핵심 주장이다. Figma는 전문 디자이너를 위한 도구라는 정체성을 유지하면서도, 모든 협업자가 자신 있게 디자인에 참여할 수 있도록 도구와 조직 문화를 확장해야 한다. 이를 위해 템플릿, 단순화된 기능, 브랜드 자산 관리와 승인 지원 같은 장치가 필요하다. ## 디자인의 경계를 넓혀야 하는 이유 - 오늘날 더 많은 사람이 일상 업무에서 디자인을 활용하고 있다. - 마케터, 제품 관리자, 개발자, 운영 담당자 등은 썸네일, 전단, 초대장, 소개 카드, 원페이저 등을 직접 제작한다. - 이들은 공식적인 디자이너는 아니지만, 정보를 시각적으로 전달하고 사용자의 관심을 끌며 협업의 품질을 높이는 역할을 한다. - 따라서 디자인은 직함이나 소속보다 실제로 문제를 시각적으로 해결하는 활동을 기준으로 정의해야 한다. ## 비디자이너가 느끼는 진입 장벽 - 비디자이너에게 Figma 파일은 전문 예술가의 갤러리처럼 느껴질 수 있다. - 무엇을 어떻게 만져야 할지 모르고 - 실수로 작업물을 망칠까 걱정하며 - 자신의 결과물을 전문 디자이너가 평가할까 부담을 느낀다. - 실제로 많은 비디자이너가 디자인 요청이 밀리는 상황을 해결하기 위해 직접 결과물을 만들지만, 자신이 도구를 “제대로” 사용하고 있는지 확신하지 못한다. - 도구 사용법의 문제뿐 아니라 “디자인은 전문가의 영역”이라는 조직 내 인식도 참여를 어렵게 만든다. ## 협업 도구가 만드는 소속감 - 회의나 팀 활동뿐 아니라 도구 자체도 조직 내 소속감을 형성할 수 있다. - Figma는 원래 디자이너를 위해 만들어졌지만, 협업자가 참여할 때 더 큰 가치가 발생한다. - FigJam, Dev Mode, Figma Slides 등은 마케팅 담당자, 개발자, 기타 협업자가 디자인 과정에 더 자신 있게 참여하도록 돕는다. - 다만 기능을 제공하는 것만으로는 충분하지 않으며, 누구나 디자인에 기여할 수 있다는 개인적·조직적 관점의 변화가 필요하다. ## 일상적 디자이너를 지원하는 방법 - 디자이너는 팀원이 쉽게 시작할 수 있도록 목적별 템플릿을 제공할 수 있다. - 더 많은 사용자가 접근할 수 있도록 복잡한 기능과 작업 흐름을 단순화해야 한다. - 비디자이너가 자주 겪는 문제를 제품 차원에서 해결할 필요가 있다. - 브랜드 가이드에 맞는 결과물 만들기 - 적절한 이미지와 디자인 자산 찾기 - 카피 문구를 수정하거나 발전시키기 - 검토와 승인 요청하기 - 새로운 사용자의 실력을 교육하고, 시도 자체를 인정하며, 성장한 결과를 적극적으로 격려해야 한다. ## 2025년의 디자인과 협업 - 업무 속도가 빨라지고 여러 업무 흐름이 동시에 진행되면서 협업 접점은 더욱 중요해지고 있다. - 마케팅과 제품 분야의 구성원도 자신의 업무가 디자인의 일부라는 점을 인식해야 한다. - 디자인 품질은 전문 디자이너의 결과물뿐 아니라, 조직 구성원 모두가 만드는 다양한 커뮤니케이션 자료에 의해 결정된다. - Figma는 전문성을 유지하면서도 더 넓은 사람들이 디자인에 참여할 수 있는 환경을 만들고자 한다. 실무적으로는 비디자이너에게 작업을 맡길 때 빈 파일보다 템플릿과 명확한 브랜드 규칙을 제공하고, 검토·승인 절차를 간소화하는 것이 효과적이다. 디자인을 특정 직군의 전유물이 아닌 조직 전체의 협업 역량으로 바라볼 때 더 빠르고 포용적인 결과를 만들 수 있다.

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

2025년 직장에

2025년 업무에서 중요한 것은 정답이나 규칙을 따르는 것이 아니라, 경험을 바탕으로 자신만의 원칙을 세우고 상황에 맞게 적용하는 것이다. 글은 디자인 영감, AI 자동화, 사용자 온보딩, 회의 운영, 꾸준한 실행에 관한 업계 리더들의 조언을 소개한다. 공통적으로 반복되는 메시지는 핵심 가치에 집중하고, 불필요한 마찰을 줄이며, 실제 성과와 사용자 가치로 이어지는 활동에 힘을 쏟으라는 것이다. ## 디자인 밖에서 영감 찾기 Ableton의 수석 디자이너 Pablo Sánchez는 창작의 출발점을 디자인 영역에만 한정하지 말라고 조언한다. - 감정, 기억, 과학적 발견, 자연 등 다양한 분야에서 영감을 얻는다. - 다른 영역을 참고하면 창작 과정이 더 확장적이고 예측하기 어려우며 개인적인 방향으로 발전한다. - 디자이너 자신이 먼저 매력을 느끼는 방식으로 설계해야 최종 결과물에도 열정이 전달된다. - Ableton의 Note 앱은 기존 MIDI 편집기나 음악 제작 앱의 관습 대신 브루탈리즘 건축의 미니멀한 표현을 참고했다. - 그 결과 음악을 즉각적으로 만들 수 있는 단순하고 직관적인 UX를 구현했다. ## 업무를 방해하는 일을 자동화하기 Meta, Reddit, Twitch, X 등에서 제품 업무를 담당했던 Peter Yang은 제품 관리자의 핵심 역할이 문서 자체를 만드는 데 있지 않다고 말한다. - OKR, 내부 문서, 제품 리뷰는 필요하지만 제품 관리자의 본질적인 책임은 고객을 공감하고 고객 가치를 전달하는 것이다. - 중간 산출물 작성에 실제 제품 개발만큼의 시간이 든다면 업무 방식을 재검토해야 한다. - 반복적인 작업은 다른 사람에게 위임하거나 AI로 자동화할 수 있다. - Peter Yang은 AI를 활용해 다음 업무를 처리한다. - 브레인스토밍 결과 종합 - 고객 피드백 요약 - 제품 요구사항 문서 정리 - 자동화의 목적은 업무를 줄이는 것 자체가 아니라, 고객 문제를 이해하고 중요한 의사결정을 내리는 데 더 많은 시간을 쓰는 것이다. ## 사용자가 빠르게 ‘마법의 순간’에 도달하게 하기 Snapchat Lens Studio의 Charmaine Lee는 처음부터 많은 튜토리얼과 도움말을 제공하기보다 사용자가 직접 만들기 시작하는 순간을 앞당겨야 한다고 강조한다. - 신규 사용자가 교육 과정을 모두 이수하는 것보다 도구를 실제로 사용하고 창작하는 것이 중요하다. - 사용자가 “아하”라고 느끼는 순간은 단순한 사용자를 창작자로 전환시키는 계기가 된다. - 좋은 온보딩은 사용자가 스스로 배울 수 있을 때까지 필요한 최소한의 발판만 제공한다. - Lens Studio 팀은 FigJam에서 사용자 여정을 시각화했다. - 앱 다운로드부터 첫 프로젝트 제출까지 19단계였던 과정을 4개의 핵심 마일스톤으로 줄였다. - 온보딩을 개선할 때는 기능과 설명을 추가하기보다 첫 번째 성공 경험까지의 단계를 줄이는 것이 효과적이다. ## 목적에 맞는 회의 유형 조합하기 Coda의 공동 창업자이자 CEO인 Shishir Mehrotra는 모든 회의를 같은 방식으로 운영해서는 안 된다고 설명한다. 회의는 목적에 따라 세 유형으로 나눌 수 있다. - **Cadence 회의** - 스탠드업, 정기 팀 회의, 프로젝트 동기화 회의 등이 해당한다. - 목표를 설정하고 실행한 뒤 결과를 돌아보는 일정한 리듬을 만든다. - 핵심 질문은 “설정한 목표대로 진행되고 있는가?”이다. - **Catalyst 회의** - 의사결정 회의, 제품 리뷰, 디자인 크리틱 등이 해당한다. - 방향을 바꾸고 진전을 만들어내는 데 목적이 있다. - 핵심 질문은 “논의한 질문에 대한 답을 얻었는가?”이다. - 지나치게 많으면 구성원의 피로와 소진을 유발할 수 있다. - **Context 회의** - 전사회의, 오프사이트, 오리엔테이션 등이 해당한다. - 정보와 통찰을 공유하고 팀 간 연결을 강화한다. - 핵심 질문은 “업무를 더 잘할 수 있는 맥락과 준비를 얻었는가?”이다. - 효과적인 조직은 세 가지 회의를 균형 있게 운영하며, 각 회의의 목적을 명확히 해야 한다. ## 어려워도 계속 전진하기 Design System University의 창립자 Dan Mall은 목표가 가치 있더라도 목표에 도달하는 과정은 지루하고 고통스러울 수 있다고 말한다. - 결과만 짧게 보여주는 영화 속 훈련 장면과 달리, 실제 성장은 반복적이고 긴 시간을 요구한다. - 지루한 과정을 견디려면 스스로 추진력을 만들어야 한다. - 큰 목표를 한 번에 해결하려 하기보다 작업의 각 부분을 시작해 진행감을 쌓는 방식이 도움이 된다. - 완벽한 동기나 이상적인 조건을 기다리기보다 작은 진전을 반복해 momentum을 유지해야 한다. 결국 2025년의 업무 방식은 더 많은 일을 하는 것이 아니라, 중요한 일에 집중하는 방향이어야 한다. 불필요한 문서와 절차는 자동화하고, 사용자의 첫 성공 경험을 앞당기며, 회의 목적을 구분하고, 디자인과 업무의 경계를 넘어 새로운 영감을 찾는 것이 실용적인 출발점이다.

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

요점 정리: 제

피그마의 2024년 업데이트는 사용자 커뮤니티와의 상호작용을 바탕으로 제품과 브랜드를 함께 확장한 과정이었다. 180개의 신규 릴리스, 1만 명이 참석한 Config, 전 세계 220개 이상의 Friends of Figma 그룹을 통해 피그마는 디자인뿐 아니라 개발·마케팅·제품팀 전체를 위한 도구로 영역을 넓혔다. 글은 주요 제품 출시와 브랜드 개편, 커뮤니티 콘텐츠를 되돌아보며 “피그마가 만들고 사용자가 완성한다”는 메시지를 강조한다. ## 제품 기능과 워크플로 확장 - UI3를 개선해 사용자가 인터페이스를 더 세밀하게 제어할 수 있도록 했다. - AI 도구를 재정비해 기능을 무작정 늘리기보다 의도와 활용성을 중심으로 발전시켰다. - Dev Mode를 강화해 디자인과 코드 사이의 연결을 원활하게 만들었다. - 프레젠테이션 제작 도구인 Figma Slides를 출시해 디자인 결과물을 발표하고 공유하는 단계까지 지원했다. - 2024년에는 대규모 기능 출시뿐 아니라 사용성을 높이는 작은 업데이트까지 총 180개의 릴리스를 진행했다. ## Config를 통한 커뮤니티 확장 - 2024년 Config에는 1만 명 이상이 샌프란시스코에 모여 제품 개발의 미래를 논의했다. - 피그마는 Config 2025의 얼리버드 티켓을 소개하며 행사를 지속적으로 확대하고 있다. - 발표자들의 강연에서 영감을 얻는 방법과 기억에 남는 세션을 만드는 방식을 공유했다. - 전 세계 220개 이상의 Friends of Figma 그룹이 커뮤니티 기반 학습과 교류를 뒷받침했다. ## 새로운 도구에 맞춘 브랜드 개편 - 개발자, 마케터, 제품팀 등 더 넓은 사용자를 지원하게 되면서 브랜드 정체성도 함께 개편했다. - 새로운 시각적 아이덴티티와 서체를 도입했다. - 피그마 자체 도구를 사용해 웹 시스템을 재설계했다. - 컴포넌트를 점검하고 정리해 일관성을 높였으며, 변수·색상·타이포그래피 스타일을 활용해 향후 확장 가능한 디자인 시스템을 구축했다. - 웹 제작 워크플로를 간소화하고 팀 간 협업 효율을 높이는 데 초점을 맞췄다. ## 커뮤니티가 만든 활용 방식 - Figma Slides에서는 커뮤니티 템플릿을 활용해 발표의 완성도와 표현력을 높이는 사례를 소개했다. - Ableton Note 앱 디자이너 Pablo Sánchez는 예상 밖의 경험을 만드는 7가지 디자인 원칙을 공유했다. - 핵심은 사용자를 놀라게 하는 요소를 설계하기 전에 디자이너 스스로 작업 과정에서 즐거움과 호기심을 느끼는 것이다. - One North의 Nick Villapiano는 개발자도 디자인 과정에 적극 참여해야 한다고 주장했다. - Dev Mode를 단순한 개발 전달 도구가 아니라 개발자가 디자인 의사결정에 기여하는 협업 공간으로 바라본다. ## 사용자 피드백을 통한 제품 발전 - 피그마의 업데이트는 커뮤니티의 작업 방식과 제작 결과물에 대한 관찰에서 출발한다. - 새로운 기능은 출시 자체보다 사용자가 실제 프로젝트에서 어떻게 활용하고 변형하는지가 중요하다고 설명한다. - 제품, 행사, 브랜드 시스템, 교육 콘텐츠를 함께 발전시키며 피그마 생태계를 확장하는 전략을 보여준다. 피그마를 사용하는 팀이라면 2024년 기능을 단순히 추가된 도구로 보기보다, UI3·AI·Dev Mode·Slides를 현재 협업 프로세스에 어떻게 연결할지 점검하는 것이 유용하다. 특히 개발자를 초기 디자인 논의에 참여시키고, 디자인 시스템을 실제 제품과 웹 경험에 일관되게 적용하는 방식이 실질적인 개선으로 이어질 수 있다.

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

피그마 2024 (새 탭에서 열림)

2024년 피그마(Figma)는 전 세계 커뮤니티의 피드백을 바탕으로 180회 이상의 업데이트를 진행하며 디자인 도구를 넘어 협업 플랫폼으로서의 완성도를 높였습니다. UI3로 불리는 대대적인 인터페이스 개편부터 AI를 활용한 워크플로우 효율화, 그리고 새로운 프레젠테이션 도구인 '피그마 슬라이즈(Figma Slides)' 도입까지, 사용자의 제작 과정을 더 빠르고 정교하게 만드는 데 집중했습니다. 결과적으로 피그마는 단순히 화면을 그리는 도구에서 아이디어 구상부터 개발 전달까지 전 과정을 아우르는 에코시스템으로 진화했습니다. **사용자 피드백으로 완성된 UI3와 인터페이스 혁신** * 2019년 이후 가장 큰 규모의 디자인 개편인 UI3를 출시했으며, 베타 기간 중 접수된 피드백을 반영해 플로팅 패널 대신 고정 및 크기 조절이 가능한 패널 시스템으로 최종 조정했습니다. * 디자인 캔버스의 공간 확보를 위해 레이어 패널을 숨길 수 있게 개선하고, 타이포그래피 및 아이콘 시스템을 현대적으로 일신했습니다. * 스포이드 도구를 개선하여 스타일과 변수(Variables)를 쉽게 재사용하고 여러 컬러 포맷을 탭으로 전환하며 빠르게 관리할 수 있도록 했습니다. **핵심 기능 고도화 및 성능 최적화** * **멀티 에디트(Multi-edit):** 여러 프레임에 걸친 디자인 요소를 한 번에 편집할 수 있는 기능을 도입하여 반복 작업 시간을 획기적으로 단축했습니다. * **고급 타이포그래피:** 텍스트 스타일 내에서 기울임꼴, 굵게, 밑줄 등을 개별적으로 재정의(Override)할 수 있으며, 단일 텍스트 노드 내에서 혼합 단락 간격을 설정할 수 있습니다. * **성능 향상:** 대규모 파일을 효율적으로 관리하기 위해 동적 페이지 로딩(Dynamic page loading)과 메모리 최적화 시스템을 도입했으며, 유럽 지역 로컬 파일 호스팅을 통해 인프라 안정성을 강화했습니다. * **오토 레이아웃 제안:** 복잡한 디자인을 반응형으로 더 쉽게 변환할 수 있도록 오토 레이아웃 추천 기능을 강화했습니다. **워크플로우의 마찰을 줄이는 AI 기능** * **비주얼 및 에셋 검색:** 이미지 업로드나 영역 선택을 통해 필요한 컴포넌트를 찾고, 이름이 일치하지 않아도 맥락에 맞는 에셋을 찾아주는 AI 검색 기능을 도입했습니다. * **콘텐츠 생성 및 편집:** 더미 데이터를 채워주는 텍스트 생성, 다국어 번역, 이미지 배경 제거 기능을 캔버스 내에서 즉시 실행할 수 있습니다. * **First Draft:** 기존의 'Make Designs'를 개선한 기능으로, 아이디어를 시각화하는 첫 단계에서 디자인 초안을 빠르게 생성하여 디자이너의 초기 탐색 과정을 돕습니다. * **레이어 정리:** AI가 레이어 이름을 자동으로 정리해주는 기능을 통해 파일 관리의 번거로움을 줄였습니다. **협업의 확장: 개발 생산성과 프레젠테이션** * **데브 모드(Dev Mode):** 코드 커넥트(Code Connect)를 통해 디자인 시스템의 컴포넌트를 실제 코드와 연결하여 개발자가 문맥 전환 없이 디자인을 구현할 수 있도록 지원합니다. * **피그마 슬라이즈(Figma Slides):** 디자인과 프레젠테이션의 경계를 허물어, 피그마의 정교한 디자인 툴을 그대로 활용하면서 고품질의 발표 자료를 제작하고 공유할 수 있게 했습니다. 실무 디자이너와 팀은 새롭게 도입된 AI 기반 검색과 레이어 정리 기능을 활용해 관리 리소스를 줄이고, 코드 커넥트를 도입해 개발자와의 협업 효율을 극대화하는 것을 권장합니다. 특히 UI3의 변경된 패널 시스템에 익숙해진다면 더 넓은 작업 영역에서 창의적인 업무에 몰입할 수 있을 것입니다.

figma4분 읽기큐레이션 요약

피그마 패턴 라이브

UI3 개편은 Figma 내부 디자인 시스템이 오랜 성장 과정에서 파편화되었다는 문제를 드러냈고, 이를 해결하기 위해 Figma Pattern Library(FPL)를 처음부터 다시 구축하게 만들었습니다. 디자이너와 엔지니어가 페어 프로그래밍에 가까운 방식으로 협업해 디자인 의도와 코드 구현을 연결하고, 변수·REST API·테마 모드를 기반으로 일관되고 접근성 높은 제품 개발의 기반을 마련했습니다. FPL은 단순한 컴포넌트 모음이 아니라 조직 전체의 공통 언어이자 UI3를 확장하기 위한 단일 진실 공급원으로 설계되었습니다. ## UI3가 드러낸 내부 디자인 시스템의 문제 - Figma는 다른 팀의 디자인 시스템 구축을 돕는 제품을 만들고 있었지만, 내부 시스템은 오랜 기간의 급속한 성장과 제품 확장으로 분리되어 있었습니다. - 동일해야 할 컴포넌트가 서로 조금씩 달랐고, 연결이 끊긴 컴포넌트 인스턴스가 누적되었습니다. - UI3를 모든 Figma 제품에 적용하려면 새로운 화면 디자인만으로는 부족했습니다. - 여러 팀이 일관되고 효율적으로 작업할 수 있는 견고한 기반 시스템이 필요했습니다. ## 디자이너와 엔지니어의 페어 협업 - Wayne Sun과 Tom Williams는 디자이너와 엔지니어로 구성된 5명의 소규모 팀을 만들었습니다. - 개발에서 한 사람이 코드를 작성하고 다른 사람이 실시간 검토하는 페어 프로그래밍처럼, 디자이너와 엔지니어가 긴밀하게 짝을 이루어 작업했습니다. - 디자이너는 시각적·사용자 경험 의도를 전달하고, 엔지니어는 이를 실제 컴포넌트와 토큰 시스템으로 구현했습니다. - 이 방식은 디자인 파일과 제품 코드 사이의 간극을 줄이고, 양쪽이 공유할 수 있는 시스템 언어를 만드는 데 목적이 있었습니다. - 그 결과 새로운 내부 디자인 시스템인 Figma Pattern Library(FPL)가 탄생했습니다. ## 스타일과 스프레드시트에서 변수 중심 구조로 전환 - 기존 시스템은 Figma의 변수 기능이 등장하기 전에 만들어졌습니다. - 디자이너는 Figma 스타일을 사용했지만, 엔지니어는 별도의 Google Sheets에서 색상 토큰을 관리했습니다. - 스프레드시트가 제품 변경 사항을 즉시 반영하지 못하면서 디자인 파일과 실제 코드의 색상이 달라지는 문제가 발생했습니다. - 팀은 Figma 변수와 REST API를 활용해 디자인과 코드가 자동으로 동기화될 수 있는 구조를 만들었습니다. - 타이포그래피 변수를 새로 만들고, 기존 타이포그래피 스타일이 이 변수들을 별칭으로 참조하도록 구성했습니다. - 색상 스타일은 중앙 관리가 가능한 색상 변수로 마이그레이션했습니다. - 색상 변수에 CSS 정의도 추가해 Dev Mode의 검사 패널에서 개발자가 올바른 변수명과 코드 표현을 확인할 수 있게 했습니다. ## Primitive와 Semantic 변수로 색상 체계 정리 - 색상은 밝기와 어두움이 체계적으로 이어지는 **color ramp**를 기반으로 구성했습니다. - 기본 색상 단위인 **Primitive 변수**는 색상 계열별로 정리하고, 100부터 1000까지 단계적으로 구분했습니다. - 실제 UI 용도를 나타내는 **Semantic 변수**는 Primitive 변수를 별칭으로 참조합니다. - 예를 들어 특정 색상값을 직접 사용하는 대신 배경, 텍스트, 테두리 같은 의미 기반 변수로 연결할 수 있습니다. - Semantic 변수는 다음과 같은 테마와 제품별 모드를 지원하도록 설계되었습니다. - 라이트 모드와 다크 모드 - Figma Design - FigJam - Slides - Dev Mode - 이 구조 덕분에 하나의 공통 컴포넌트가 제품이나 테마에 따라 색상만 자연스럽게 바꿀 수 있습니다. - Primitive 변수의 값을 수정하면 이를 참조하는 Semantic 변수와 컴포넌트에 변경 사항을 일괄 적용할 수 있습니다. ## FPL의 역할 - FPL은 UI3의 시각적 스타일을 정의하는 동시에, 이를 실제 제품에 일관되게 구현하기 위한 기술적 기반입니다. - 디자인과 엔지니어링을 분리된 단계로 처리하지 않고, 초기 설계부터 함께 검증하는 협업 모델을 채택했습니다. - 변수와 모드 기반의 구조는 여러 제품과 테마를 지원하면서도 공통된 사용자 경험을 유지하도록 돕습니다. - 중앙화된 토큰과 컴포넌트는 중복 구현과 미세한 시각적 차이를 줄이고, 향후 변경 사항을 더 빠르게 확산시킬 수 있습니다. FPL 사례는 디자인 시스템을 단순한 UI 컴포넌트 저장소가 아니라 디자인 토큰, 테마, 코드 연동, 협업 방식까지 포함하는 조직의 공통 인프라로 다뤄야 한다는 점을 보여줍니다. 특히 디자인 파일과 코드가 서로 다른 토큰을 관리하지 않도록 변수와 자동 동기화를 도입하는 것이 규모가 큰 제품 조직에 실용적인 출발점입니다.

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

개발자가 디자인에 적극적으로 참여

Figma의 Dev Mode는 개발자를 디자인의 수동적 구현자가 아니라 제품 설계에 참여하는 협업자로 바라보게 한다. 개발자가 디자인 도구를 적극적으로 사용하고 필요한 개선을 직접 제안하면, 디자인 파일 탐색의 불안과 반복적인 탭 전환을 줄이고 디자이너와의 공통 언어를 만들 수 있다. 글은 Dev Mode 도입을 조직에 요구하는 일이 개발자 경험과 생산성, 협업 품질을 개선하는 실질적인 방법이라고 결론짓는다. ## 개발자는 디자인 과정의 참여자다 - 기존에는 디자인 도구를 디자이너만 사용하는 것으로 여겨 개발자가 파일을 조심스럽게 열어보거나 여러 브라우저 탭을 오가며 사양을 확인했다. - 이런 역할 분리는 디자인과 구현 사이의 소통 비용을 키우고, 개발자가 제품 결정에 기여할 기회를 줄인다. - Dev Mode는 개발자에게 별도의 작업 공간과 기능을 제공해 기획부터 출시까지 디자인 과정에 참여할 수 있게 한다. - 개발자가 Dev Mode의 필요성을 조직에 설명하고 도입을 주도해야 더 나은 협업 환경을 만들 수 있다. ## 공유 도구가 만드는 공통 언어 - Dev Mode는 개발자가 디자인을 단순히 구현하는 사람이 아니라 적극적인 협업자라는 전제를 바탕으로 한다. - Figma의 오토 레이아웃은 개발자에게 CSS Flexbox와 유사하게 느껴져 디자인의 레이아웃 동작을 웹 구현 방식과 연결해 주었다. - 이러한 공통 개념은 디자이너와 개발자가 서로의 작업 방식을 이해하는 접점이 된다. - Dev Mode는 특정 기능 하나를 넘어, 양쪽 직군이 같은 파일과 개념을 바탕으로 소통하는 협업 프레임워크를 제공한다. ## 개발자가 직접 도입을 제안해야 하는 이유 - 관리자는 실제 작업에서 한 단계 떨어져 있어 개발자가 겪는 불편과 생산성 저하를 놓칠 수 있다. - 개발자는 GitHub 이슈, 풀 리퀘스트 의견, Stack Overflow 답변처럼 필요한 개선을 직접 제안하는 데 익숙하다. - 같은 방식으로 1:1 미팅, 스프린트 회고, 팀 회의에서 디자인 도구와 개발자 경험의 문제를 구체적으로 제기할 수 있다. - 단순히 “새 도구가 필요하다”고 말하기보다, 현재의 반복 작업과 협업 비용을 어떤 기능이 어떻게 줄이는지 설명해야 설득력이 높아진다. ## 두려움 없이 디자인 파일 탐색하기 - Dev Mode는 기본적으로 읽기 전용이므로 개발자가 실수로 디자인 파일을 수정하거나 다른 사람의 작업을 덮어쓸 위험을 줄인다. - 개발자는 여백, 컴포넌트, 레이아웃 등을 자유롭게 클릭하며 파일 구조를 탐색할 수 있다. - 이는 Git의 `main` 브랜치 보호와 비슷한 안전장치로, 파일을 망칠까 봐 지나치게 조심하는 상황을 없앤다. - 결과적으로 디자인 파일을 이해하는 데 필요한 탐색 시간이 줄고, 개발자의 사용 자신감이 높아진다. ## 변경 사항을 명확하게 비교하기 - Dev Mode의 버전 기록과 변경 사항 비교 기능은 GitHub의 커밋 기록이나 풀 리퀘스트와 유사한 방식으로 동작한다. - 디자인의 여러 버전을 시각적으로 비교해 무엇이 언제, 누구에 의해 변경되었는지 확인할 수 있다. - 문구 변경, 여백 수정, 컴포넌트 변형 추가처럼 변경 항목을 구체적인 작업 목록으로 파악할 수 있다. - 이를 통해 개발자는 최신 디자인을 빠르게 이해하고, 구현 과정에서 누락된 변경 사항을 줄일 수 있다. ## 디자인 사양과 코드 사이의 탭 전환 줄이기 - 기존 개발자는 디자인 사양, 문서, 코드 저장소를 오가며 정보를 확인해야 했고, 이 과정에서 많은 시간이 소모됐다. - Dev Mode와 Code Connect 같은 기능은 디자인 정보와 실제 코드 구현 사이의 거리를 줄이는 방향으로 설계됐다. - 디자인 확인과 개발에 필요한 정보를 한 작업 흐름 안에서 연결하면 반복적인 검색과 컨텍스트 전환을 줄일 수 있다. - 이는 단순한 편의 기능을 넘어 개발자의 집중력과 전체 개발 속도에도 영향을 준다. ## 실용적인 적용 방향 - 현재 디자인 파일을 확인할 때 발생하는 실수, 정보 탐색, 탭 전환 시간을 구체적으로 기록한다. - Dev Mode의 읽기 전용 탐색, 버전 비교, 코드 연결 기능이 각각 어떤 문제를 해결하는지 사례로 제시한다. - 디자인 시스템 개편이나 원격·하이브리드 협업처럼 여러 직군의 긴밀한 조율이 필요한 프로젝트에서 먼저 적용한다. - 도구 도입 자체보다 디자이너와 개발자가 공유할 수 있는 언어와 작업 방식을 만드는 데 초점을 둔다.

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

새로운 시대를 위한 웹

Figma는 2024년 브랜드 리프레시를 계기로 figma.com의 웹 디자인 시스템을 전면 점검했다. 기존 시스템은 유사한 컴포넌트가 지나치게 많고, 색상과 타이포그래피가 확장된 브랜드와 다양한 콘텐츠를 충분히 지원하지 못했다. 사용 현황을 데이터로 분석해 컴포넌트를 단순화하고, 일관된 디자인 원칙과 재사용 가능한 템플릿을 마련함으로써 더 유연하고 미래 지향적인 웹 시스템을 구축했다. ## 브랜드와 웹 시스템을 함께 재정비한 배경 - 2020년의 figma.com은 새로운 디자인 도구를 소개하는 데 초점이 맞춰져 있었다. - 2024년의 Figma는 여러 제품 팀을 위한 플랫폼으로 확장되었고, 웹사이트 역시 제품 생태계와 다양한 사용자 요구를 보여줘야 했다. - 기존 시스템에는 다음과 같은 문제가 있었다. - 서로 조금씩만 다른 컴포넌트가 많아 적절한 컴포넌트를 선택하기 어려움 - 변화하는 브랜드 색상 팔레트를 수용할 만큼 색상 체계가 유연하지 않음 - 다양한 콘텐츠 유형을 지원하기에 타이포그래피 체계가 충분히 최적화되지 않음 - Figma Sans와 새로운 색상·일러스트레이션 스타일을 도입한 브랜드 리프레시는 웹 디자인 시스템을 재설계하는 계기가 되었다. ## 컴포넌트 사용 현황을 데이터로 감사 - Web Experience 팀은 스크립트를 작성해 컴포넌트가 다음과 같이 어떻게 사용되는지 분석했다. - 어떤 컴포넌트가 사용되는가 - 각 컴포넌트가 얼마나 자주 사용되는가 - 어떤 페이지에서 사용되는가 - 이 분석을 통해 실제 사용량과 필요성을 기준으로 컴포넌트 구조를 단순화할 수 있었다. - 디자인 시스템을 직관이나 선호만으로 관리하지 않고, 실제 페이지와 팀의 사용 패턴을 근거로 개선한 점이 핵심이다. ## Flex 컴포넌트의 48개 변형을 24개로 축소 - 가장 널리 사용되던 기본 구성 요소인 ‘Flex’ 컴포넌트는 옵션이 추가되면서 48개 변형까지 늘어나 있었다. - 사용 사례를 조사한 결과, 기능을 유지하면서도 변형 수를 24개로 줄일 수 있었다. - 중복되거나 활용도가 낮은 선택지를 제거해 속성 패널을 더 집중된 형태로 만들었다. - 예를 들어 가운데 정렬 텍스트 옵션을 없애고, 웹 시스템 전체에서 왼쪽 정렬을 기본값으로 정했다. - 그 결과: - 디자이너와 콘텐츠 제작자가 선택해야 할 옵션이 줄어듦 - 컴포넌트 사용법이 쉬워짐 - 웹페이지 전반의 시각적 일관성이 높아짐 - 새로운 브랜드 언어와도 더 잘 맞게 됨 ## 템플릿과 조합 가능한 빌딩 블록 - 단순히 기존 컴포넌트를 줄이는 데 그치지 않고, 자주 쓰는 페이지 레이아웃을 템플릿으로 만들었다. - 여러 방식으로 조합할 수 있는 “building block” 컴포넌트 세트도 구축했다. - 이를 통해 팀은: - 일반적인 페이지 구조를 더 빠르게 만들고 - 필요한 구성 요소를 조합해 다양한 페이지를 제작하며 - 별도의 커스텀 작업 없이도 Figma 브랜드에 맞는 결과물을 만들 수 있게 되었다. - 컴포넌트 선택지를 무작정 늘리는 대신, 검증된 핵심 요소와 조합 방식을 제공하는 접근이다. ## 실용적인 시사점 - 디자인 시스템을 정기적으로 감사하고 실제 사용 데이터를 확인해야 한다. - 유사한 변형이 계속 늘어난다면 기능을 유지하면서 옵션을 통합할 수 있는지 검토할 필요가 있다. - 명확한 기본값과 일관된 원칙을 정하면 사용자의 선택 부담을 줄일 수 있다. - 공통 레이아웃 템플릿과 조합형 컴포넌트를 함께 제공하면 확장성과 제작 속도를 모두 높일 수 있다.

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