Figma/디자인 시스템

246 개의 포스트

figma3분 읽기큐레이션 요약

개발 모드 어노테

Figma의 Dev Mode 주석 기능은 디자이너와 개발자 사이에 흩어진 요구사항과 설계 의도를 하나의 공간에 모으기 위해 만들어졌다. 기존 주석은 작성에 시간이 많이 들고 디자인 변경에 따라 쉽게 낡으며 캔버스를 복잡하게 만든다는 문제가 있었다. Figma는 주석을 실제 디자인 속성·측정값·변수·컴포넌트와 연결하고, 캔버스 바깥에서 자동으로 배치해 최신 상태와 가독성을 함께 확보하려 했다. ## 디자이너와 개발자의 서로 다른 요구 - 디자이너는 시각적 결과만으로 표현하기 어려운 정보를 전달해야 한다. - 접근성 속성 - 인터랙션의 세부 동작 - 특정 디자인 결정을 내린 의도 - 개발자에게 디자인 파일은 정보가 지나치게 많아 실제 구현해야 할 부분을 찾기 어려울 수 있다. - 디자인 공유는 전체 파일을 전달하는 것과 다르며, 개발자가 집중해야 할 영역과 요구사항을 선별해 주는 과정이 필요하다. - Figma는 이러한 문제를 해결하기 위해 Dev Mode 안에 개발자용 사양을 큐레이션하는 전용 공간을 마련했다. - 디자이너도 Dev Mode에서 주석을 작성함으로써 개발자가 실제로 보게 될 화면과 맥락을 확인할 수 있고, 작업이 끝난 뒤 Dev Mode 링크를 공유할 수 있다. ## 기존 수동 주석의 한계 - 디자이너는 텍스트, 화살표, 치수선, 콜아웃 등을 직접 배치해야 하므로 주석 작성에 많은 시간이 든다. - 디자인이 변경되면 기존 주석이 수정되지 않아 실제 디자인과 설명 사이에 불일치가 생긴다. - 디자인 파일에 주석을 추가하려면 프레임을 옮기거나 주변 공간을 확보해야 한다. - 주석이 많아질수록 캔버스가 복잡해지고, 개발자가 필요한 정보를 찾기 어려워진다. - 작업이 완전히 확정된 뒤 “개발 준비 완료” 상태를 표시하는 방식에는 적합하지만, 지속적으로 변경되는 제품 개발 과정에는 한계가 있다. ## 디자인 속성과 연결되는 동적 주석 - Figma는 주석을 단순한 텍스트가 아니라 디자인의 실제 속성에 연결하는 방식을 고민했다. - 디자인 변경 시 연결된 주석과 치수선도 함께 갱신되도록 하면 디자이너가 정보를 반복해서 입력할 필요가 줄어든다. - 개발자는 디자이너가 계속 수정 중인 상황에서도 최신 디자인에 기반한 사양을 확인할 수 있다. - 디자인 시스템의 변수와 컴포넌트를 주석에서 직접 참조하면, 일반 텍스트보다 오류 가능성이 낮아진다. - 주석의 정보가 실제 디자인 요소 및 코드베이스와 가까워질수록 설계 사양과 구현 결과의 정합성이 높아진다. ## 캔버스를 어지럽히지 않는 위치 지정 - 기존 방식에서는 주석을 표시할 공간을 만들기 위해 프레임을 계속 재배치해야 했다. - Figma는 주석을 캔버스에 직접 차지시키지 않으면서도 개발자에게 충분히 잘 보이게 하는 방식을 탐색했다. - 최종 방향 중 하나는 주석을 자동으로 배치하고 표시하는 것이었다. - 자동 배치는 디자이너의 수동 정리 작업을 줄이고 개발자에게 더 깔끔한 화면을 제공할 수 있다. - 다만 확대·축소, 이동, 크기 조절, 최소화, 선택, 마우스 오버 등 다양한 상호작용을 고려해야 하므로 여러 프로토타입과 반복적인 조정이 필요했다. - 엔지니어링 팀은 주석 표시 로직을 조정해 다양한 화면 상태에서도 주석이 적절히 보이도록 하는 데 집중했다. ## 실용적인 시사점 Dev Mode의 주석은 디자인이 끝난 뒤 설명을 덧붙이는 문서화 도구라기보다, 변경 중인 디자인과 구현 요구사항을 지속적으로 연결하는 협업 기능에 가깝다. 주석을 작성할 때는 단순한 설명보다 접근성, 상태 변화, 인터랙션, 디자인 토큰처럼 실제 구현에 필요한 정보를 디자인 요소와 연결해 기록하는 것이 효과적이다.

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

디자인 시스템 도입을 가로

디자인 시스템은 대기업만을 위한 복잡한 도구가 아니라, 팀 규모와 관계없이 효율성·일관성·협업을 높이는 실용적인 체계다. 최신 유행이나 Material Design을 그대로 따르기보다 조직의 목표, 브랜드, 사용자에 맞춰 설계해야 한다. 또한 처음부터 모든 것을 직접 만들 필요 없이 공개된 리소스를 활용해 현실적인 범위에서 시작할 수 있다. ## 디자인 시스템은 대기업만을 위한 것이 아니다 - 규모가 작은 팀도 디자인 시스템을 통해 반복 작업을 줄이고 결과물의 일관성을 높일 수 있다. - 디자인 시스템의 형태는 조직마다 다를 수 있지만, 핵심 목적은 공통적이다. - 업무 효율 향상 - 제품 경험의 일관성 확보 - 디자이너와 개발자 간 협업 촉진 - 사례로 소개된 Mixpanel은 디자인 시스템을 개편해 비용을 절감하고, 일관성을 개선하며, 전사적으로 데이터 분석 접근성을 높였다. ## 최신 디자인 기법을 모두 적용해야 한다는 오해 - 디자인 트렌드는 계속 변하며, 모든 조직에 통하는 유일한 정답은 없다. - 다른 팀의 사례와 업계 동향은 참고할 수 있지만 그대로 복제할 필요는 없다. - “완벽하고 최신인 시스템”을 만드는 데 집중하면 실제 해결하려던 문제와 목표를 놓칠 수 있다. - 디자인 시스템은 유행을 보여주는 전시물이 아니라 다음을 지원해야 한다. - 조직의 구체적인 목표 - 실제 사용자 요구 - 팀의 업무 방식 - 지속 가능한 운영 ## Material Design이 모든 조직에 맞는 것은 아니다 - Google의 Material Design은 널리 알려진 표준이지만, 모든 제품에 그대로 적용할 수 있는 만능 해법은 아니다. - 조직의 디자인 시스템은 다음 요소를 반영해야 한다. - 브랜드의 고유한 정체성 - 제품 사용자의 needs - 조직의 비즈니스 목표 - 현재 조직이 처한 상황과 우선순위 - 업계 표준을 참고하되, 조직에 가장 적합한 방식과 균형을 찾아야 한다. - 글에서는 Uber Base, Google Material 3, Spotify Backstage, Pipedrive, Microsoft Teams, Salesforce Lightning 등의 디자인 시스템과 UI 키트를 비교 사례로 제시한다. ## 디자인 시스템을 처음부터 직접 만들어야 한다는 오해 - 글은 디자인 시스템을 반드시 처음부터 자체 제작해야 한다는 생각에 의문을 제기한다. - 공개된 오픈소스 디자인 시스템과 UI 리소스를 활용하면 초기 구축 비용과 시간을 줄일 수 있다. - 이미 검증된 리소스를 기반으로 시작한 뒤, 조직의 브랜드와 제품 요구에 맞게 수정하는 방식이 현실적이다. - 제공된 본문은 이 신화에 대한 설명 중간에서 끝나므로, 이후 네 번째부터 여섯 번째 신화의 전체 내용은 확인할 수 없다. 작게 시작하되 팀의 반복 문제와 실제 사용자 요구를 우선 해결하는 것이 좋다. 기존 오픈소스와 업계 사례는 출발점으로 활용하고, 최종 디자인 시스템은 조직의 브랜드·제품·업무 방식에 맞게 점진적으로 발전시키는 것이 바람직하다.

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

개발 모드의 향후 계획

Figma는 Dev Mode 무료 베타 종료를 앞두고 주석, 변경 사항 비교 개선, 플러그인, Jira·VS Code 연동 기능을 공개했다. 이를 통해 디자이너와 개발자 간 핸드오프에 필요한 맥락을 강화하고, 조직별 기술 스택과 디자인 시스템에 맞춘 개발 워크플로를 지원한다. Dev Mode는 2024년 1월 31일부터 무료 베타를 종료하고 유료 좌석이 필요해진다. ## 디자인과 연결되는 주석 기능 - 디자이너가 디자인 레이어에 설명, 속성, 사양, 측정값을 직접 추가할 수 있다. - 클릭과 드래그만으로 치수와 간격을 표시해 개발자에게 구체적인 구현 정보를 전달한다. - 주석이 특정 레이어에 연결되므로 디자인이 변경되면 속성이나 측정값도 함께 업데이트된다. - 확대·축소 수준에 따라 주석이 자동으로 표시되거나 숨겨져 캔버스를 복잡하게 만들지 않는다. - 플러그인 API를 이용하면 여러 레이어에 주석을 일괄 생성하고 관리할 수 있다. ## 시각적·코드 기반 변경 사항 비교 - Compare Changes 기능이 개편되어 디자인 변경 사항을 시각적 차이와 코드 차이로 모두 확인할 수 있다. - 주석 기능과 결합해 어떤 디자인 요소가 바뀌었고 구현에 어떤 영향을 주는지 파악하기 쉬워졌다. - Figma for Jira 앱을 사용하면 Jira 이슈에 디자인 맥락을 삽입할 수 있다. - 디자인이 변경될 때 Jira에서 알림을 받아 핸드오프 과정에서 업데이트를 놓치지 않도록 지원한다. ## 조직별 코드 생성과 플러그인 - 조직마다 다른 개발 환경에 맞춰 HTML, React, Tailwind, Bootstrap 등 다양한 형식의 코드를 생성할 수 있다. - 디자인 시스템 컴포넌트와 실제 코드베이스의 컴포넌트 연결 여부를 확인하는 플러그인을 만들 수 있다. - 플러그인에 내부 API 안내, 디자인 시스템 문서 링크, 사용 가능한 컴포넌트 정보 등을 포함할 수 있다. - Enterprise 관리자는 특정 플러그인을 조직 전체에 고정하고 Dev Mode에서 기본 실행되도록 설정할 수 있다. - Razorpay는 자체 Dev Mode 플러그인인 RazorSharp를 구축해 디자인에 대응하는 코드를 자동 생성했다. ## Figma for VS Code 개선 - VS Code 안에서 Figma 디자인을 탐색하고 검사할 수 있도록 확장 기능의 탐색성과 검색성이 개선됐다. - 여러 페이지와 무한 캔버스를 직접 이동하는 대신 프레임을 그리드 형태로 선택할 수 있다. - Focus View를 통해 개별 프레임을 집중해서 확인할 수 있다. - VS Code를 떠나지 않고 Figma 플러그인을 실행할 수 있어, 사내 도구나 코드 생성 플러그인을 개발 환경에서 바로 사용할 수 있다. ## Dev Mode 유료 전환 - Dev Mode는 2024년 1월 31일 무료 베타에서 정식 서비스로 전환된다. - 이후 사용하려면 플랜과 좌석 유형에 따라 유료 Dev Mode 좌석이 필요하다. - 무료 베타 기간 동안 사용자 피드백을 반영해 200개 이상의 기능과 수정 사항이 추가됐다. 조직은 디자인 시스템과 실제 코드베이스의 연결이 중요하다면 주석과 플러그인을 우선 도입하고, 개발자가 VS Code 중심으로 작업한다면 Figma for VS Code와 사내 플러그인 연동을 검토하는 것이 효과적이다. 유료 전환 전 팀별 좌석과 플러그인 운영 정책도 함께 정하는 것이 좋다.

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

Razorpay가 개발자 워크플 (새 탭에서 열림)

인도 최대의 금융 서비스 기업인 Razorpay는 1,000만 개 이상의 비즈니스를 지원하기 위해 디자인 시스템 'Blade'를 구축하여 일관된 사용자 경험과 개발 효율성을 동시에 확보했습니다. 웹과 모바일을 아우르는 단일 API 구조를 통해 플랫폼 간 전환 비용을 최소화하고, 전용 플러그인과 Figma Dev Mode를 적극 활용해 디자이너와 개발자 간의 협업 마찰을 획기적으로 줄였습니다. 결과적으로 Blade는 단순한 가이드를 넘어 제품의 신뢰성을 높이고 시장 출시 속도를 앞당기는 핵심 동력으로 자리 잡았습니다. **크로스 플랫폼을 위한 단일 라이브러리 체계** * 웹, iOS, Android 등 다양한 플랫폼에서 동일한 API와 속성을 공유하는 단일 디자인 시스템을 운영하여 개발자가 플랫폼을 옮겨가더라도 기존 지식을 그대로 활용할 수 있게 했습니다. * 하드코딩으로 인해 발생할 수 있는 텍스트 필드의 에러 처리나 버튼 상태값 누락 등의 세부적인 오류를 방지하고, 모든 컴포넌트에 접근성(Accessibility)을 기본적으로 내장했습니다. * 디자이너와 개발자가 동일한 언어를 사용함으로써 커뮤니케이션 비용을 줄이고, 디자인에서 보는 결과물이 코드와 일치하도록 보장합니다. **지표 기반의 도입 전략과 조직 내 확산** * 새로운 기능을 개발할 때는 디자인의 70%, 기존 화면을 수정할 때는 50% 이상 Blade 컴포넌트를 사용하도록 KPI를 설정하여 디자인과 개발 팀이 공동의 목표를 추구하게 합니다. * 'Blade Coverage' 플러그인을 통해 디자이너가 시스템에서 얼마나 벗어나고 있는지 실시간으로 확인하게 함으로써, 핸드오프 단계 이전에 피드백을 주고받을 수 있는 환경을 조성했습니다. * 리더십의 지지를 바탕으로 전담 슬랙 채널 운영, 오피스 아워, 시연 영상 공유 등을 통해 내부 고객(직원)들의 채택률을 높이고 연간 NPS(순추천지수) 설문을 통해 만족도를 관리합니다. **RazorSharp와 Dev Mode를 통한 코드 자동화** * 개발자가 일일이 속성을 검사하던 비효율을 제거하기 위해 디자인을 코드로 자동 변환해주는 자체 플러그인 'RazorSharp'를 개발했습니다. * Figma의 Dev Mode를 도입하면서 기존 편집 권한이 필요했던 플러그인 제약을 극복했고, 개발자가 편집 권한 없이도 코드를 복사하고 Storybook 링크를 통해 바로 컴포넌트 환경으로 이동할 수 있게 했습니다. * VS Code 플러그인을 연동하여 개발 환경 내부에서 직접 디자인 사양을 확인하며 코드를 작성하는 워크플로우를 구축했습니다. **Variables를 활용한 토큰 관리 및 성능 최적화** * 기존의 복잡한 토큰 명명 규칙(surface/text/subtle)을 개발자 친화적인 구조(surface.text.subtle)로 변환하고, 간격(spacing) 토큰을 변수화하여 개발 편의성을 높였습니다. * 여러 테마와 라이트/다크 모드를 개별적으로 만들던 방식에서 변수(Variables) 기반 시스템으로 전환하여 메모리 소모를 대폭 줄이고 디자인 작업 속도를 개선했습니다. * 이를 통해 하나의 테마 안에서 다양한 모드를 유연하게 구현할 수 있게 되어 시스템의 복잡성을 낮추고 관리 효율을 극대화했습니다. **디자인 시스템 운영을 위한 실용적 제언** 디자인 시스템의 성공은 단순히 컴포넌트를 만드는 것에 그치지 않고, 개발자가 실제 작업 환경에서 얼마나 편리하게 코드를 추출하고 적용할 수 있느냐에 달려 있습니다. Razorpay처럼 자체 플러그인을 개발하거나 Dev Mode를 적극 활용하여 '디자인 검사'에 들어가는 시간을 줄이고, 정량적인 사용량 지표(Coverage)를 통해 팀의 성과를 객관화하는 접근 방식이 권장됩니다. 또한, 시스템의 복잡도가 커질수록 Variables 기능을 활용해 성능 저하를 방지하고 개발 생산성을 높이는 전략이 필수적입니다.

figma3분 읽기큐레이션 요약

프로토타이핑 문화를 조성

프로토타이핑은 더 이상 개발 직전의 선택적 작업이 아니라, 제품 개발 전반에 통합해야 할 핵심 활동이다. 인터랙티브한 프로토타입은 정적 디자인에서 놓치기 쉬운 내비게이션과 사용자 경험 문제를 조기에 발견하고, 개발 전에 아이디어의 가치를 검증하게 한다. 조직 전체가 프로토타이핑을 일상적인 업무 방식으로 받아들이면 실험과 의사결정이 빨라지고 더 나은 제품을 만들 수 있다. ## 프로토타이핑의 역할과 가치 - 프로토타입은 제품의 형태와 동작을 미리 보여주는 모형 또는 데모다. - 인터랙션과 경험을 충분히 높은 완성도로 재현해, 실제 개발에 들어가기 전에 아이디어를 평가할 수 있다. - 정적 화면만으로는 발견하기 어려운 내비게이션 문제, 사용성 장애, 사용자 테스트상의 문제를 조기에 드러낸다. - 개발 전에 문제를 수정하므로 엔지니어링 시간과 불필요한 개발 사이클을 줄인다. - 디자인을 단순한 시각 결과물이 아니라 실제 제품 경험으로 전환한다. ## 빠른 실험과 아이디어 검증 - 여러 아이디어를 개발 리소스를 추가로 투입하지 않고 빠르게 만들고 검증할 수 있다. - 초기에는 다양한 방향으로 폭넓게 탐색한 뒤, 가능성이 높은 해법으로 좁혀 갈 수 있다. - 이러한 과정은 더 창의적이고 기존 방식에서 벗어난 사용자 경험을 만드는 데 도움이 된다. - 프로토타입은 아이디어를 상위 의사결정자에게 구체적으로 보여주는 증거가 되어, 프로젝트 승인과 설득을 앞당긴다. - 디자이너는 인터랙티브한 결과물로 자신의 의도를 효과적으로 전달하고 제품 및 비즈니스 의사결정에 영향력을 행사할 수 있다. ## 프로토타이핑 문화의 확산 - 프로토타이핑 문화는 과거 디자인 시스템이 발전한 과정과 비슷하게 확산되고 있다. - 도구 접근성이 높아지고 교육 프로그램이 생기면서 더 많은 팀이 프로토타이핑을 업무에 활용할 수 있게 됐다. - Lyft는 정적 디자인을 넘어 동영상, GIF, 인터랙티브 프로토타입을 활용하고, 사용자 피드백을 제품 리뷰에 빠르게 반영하는 사례로 소개된다. - 프로토타이핑을 중시하는 조직은 혁신과 디자인을 중요하게 여긴다는 신호를 제공하며, 우수한 디자인 인재를 끌어들이는 데도 도움이 된다. ## 조직 차원의 정착 조건 - 프로토타이핑을 익히고 실천할 수 있도록 시간과 리소스를 공식적으로 배정해야 한다. - 이를 최종 단계의 선택 사항이 아니라 디자인 프로세스에 자연스럽게 포함된 필수 단계로 바꿔야 한다. - 실무자는 프로토타이핑 역량을 발전시키고, 리더십은 효율성과 의사결정 개선에 미치는 가치를 인정해야 한다. - 리더는 팀이 프로토타이핑을 프로세스에 포함하도록 명시적으로 요구하고, 실제로 작업할 시간과 환경을 제공해야 한다. - 관심 있는 직원들을 위한 전문 프로그램을 운영하고, 습득한 지식을 교육·개발 체계와 주요 리뷰 과정에 확장할 수 있다. - 실무자와 리더 중 한쪽만 동의하면 문화로 정착하기 어렵기 때문에 조직 전반의 공감대가 필요하다. ## 제품 개발 프로세스의 변화 - 프로토타이핑을 앞단에 배치하면 제품 개발은 기존의 선형적인 순서에서 더 반복적이고 탐색적인 과정으로 바뀐다. - 잠재적 장애물을 빠르게 발견하고 여러 대안을 평가할 수 있어, 이미 알려진 문제를 피하면서 해결책에 집중할 수 있다. - 프로토타이핑 문화는 디자이너의 역할뿐 아니라 제품·엔지니어링·리더십 간 협업 방식과 의사결정 구조 전체를 변화시킨다. - 결과적으로 개발 착수 후 수정하는 비용보다, 개발 전 실험하고 학습하는 비용을 우선하게 된다. 실무적으로는 모든 기능에 높은 완성도의 프로토타입을 만들기보다, 위험이 큰 인터랙션과 사용자 경험부터 짧게 실험하는 것이 효과적이다. 이를 정기 리뷰와 교육 과정에 포함하고 리더가 시간을 보장해야 프로토타이핑이 일회성 산출물이 아니라 조직의 기본 업무 방식으로 자리 잡을 수 있다.

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

슬랙래시부터 토글

2023년의 디지털·하이브리드 업무 환경은 새로운 행동과 감정을 만들어냈고, 이를 표현할 새로운 업무 용어도 낳았다. 이 글은 Slack, Zoom, 협업 도구, 멀티태스킹과 관련된 현상을 유머러스한 신조어로 정리하며, 변화한 업무 문화를 이해하고 적응하는 언어를 제시한다. 결국 바쁜 업무 환경을 완전히 없애기보다, 그 안의 불합리함과 재미를 인식하고 더 현명하게 일하자는 메시지다. ### 업무 완성도와 반복 개선 - **Fidelity Fluency** - 프로젝트에 필요한 완성도 수준을 판단하는 능력이다. - 초기 아이디어 스케치에 과도한 시간을 쓰지 않고, 실제 영향력에 맞춰 디테일을 조절한다. - 불필요한 픽셀 단위 수정과 낭비를 줄이는 실무적 감각을 의미한다. - **WIP Waltz** - 진행 중인 작업을 끊임없이 수정하고 반복하는 과정을 춤에 비유한 표현이다. - 매 단계마다 새로운 관점과 개선 사항이 생기지만, 동시에 또 다른 수정 라운드가 시작된다. ### 원격 협업에서 발생하는 순간들 - **Icebroken** - 온라인 회의의 아이스브레이킹에서 지나치게 개인적인 이야기를 꺼내 어색해지는 상황이다. - 친밀감을 만들려던 시도가 오히려 ‘TMI’로 이어지는 순간을 풍자한다. - **Screenshare Scramble** - 화면 공유 직전이나 도중에 민감하거나 부끄러운 브라우저 탭을 급히 숨기는 행동이다. - Zoom 화면에 무엇이 나타날지 모르는 긴장감과 허둥거림을 표현한다. - **Zoombie** - Zoom 회의에 접속해 있지만 실제로는 거의 참여하지 않는 사람을 뜻한다. - 카메라 앞에는 존재하지만 정신적으로는 여러 회의와 화면 공유에 지친 상태다. - **Zoom Zen** - 명확한 안건, 원활한 음소거·해제, 시간 내 종료가 모두 이루어진 이상적인 화상회의 상태다. - 드물지만 회의가 효율적이고 만족스럽게 끝났을 때의 평온함을 의미한다. ### 메시지와 알림의 과부하 - **Keyboard Cardio** - 이메일과 Slack 메시지를 빠르게 입력하고 처리하는 일을 격렬한 유산소 운동처럼 표현한 말이다. - 실제 운동 효과보다는 메시지 작성이 유발하는 긴장과 스트레스를 농담처럼 강조한다. - **Slack-lash** - Slack 알림과 메시지가 한꺼번에 쏟아져 놀라고 압도되는 순간이다. - 디지털 메시지의 폭발적인 유입을 갑작스러운 반동이나 ‘채찍질’에 비유한다. - **Workplace Whack-a-Mole** - 업무, 알림, 이메일이 끊임없이 나타나 이를 계속 처리해야 하는 상황이다. - 하나를 끝내면 곧바로 다른 일이 튀어나오는 업무 환경의 피로와 혼란을 묘사한다. ### 멀티태스킹과 디지털 산만함 - **Toggle Tax** - 여러 업무 사이를 전환할 때 발생하는 인지적 비용이다. - 작업을 바꿀 때마다 집중력을 다시 끌어올려야 하므로, 멀티태스킹이 생산성을 떨어뜨릴 수 있음을 암시한다. - **Tab Tsunami** - 브라우저 탭이 지나치게 많이 열려 화면과 집중력을 모두 압도하는 상태다. - 수많은 정보와 작업을 동시에 붙잡으려는 디지털 업무 습관을 거대한 파도에 비유한다. ### 디자인 시스템과 협업 문화 - **Style Guide Safari** - 스타일 가이드 안에서 색상, 서체, 컴포넌트 등을 탐색하는 과정을 정글 탐험처럼 표현한 말이다. - 디자인 시스템이 풍부하고 복잡할수록 원하는 규칙을 찾아다니는 경험이 모험처럼 느껴질 수 있다. - **Sudden Heavy Stamping** - 협업 중 자신의 아이디어에 갑자기 여러 개의 +1, 하트, 스탬프가 몰리는 순간이다. - 실시간 협업 도구에서 사회적 인정과 즉각적인 피드백을 받는 기쁨을 뜻한다. - **UI Lock Ness Monster** - 다음 업데이트에 포함될 것이라는 소문만 무성하고 실제로는 계속 등장하지 않는 UI 기능이다. - 오랫동안 기대되지만 실현되지 않는 기능을 전설 속 괴물에 빗댄 표현이다. ### 글이 제시하는 업무 문화의 풍경 - 이 용어들은 새로운 기술 자체보다, 기술을 사용하는 과정에서 생긴 감정과 습관을 포착한다. - Zoom 피로, Slack 알림, 화면 공유 불안, 멀티태스킹 비용처럼 디지털 업무의 문제를 유머로 표현한다. - 동시에 비동기 업무, 팬데믹 이후의 업무 전환, 몰입 중심의 업무 방식 등 변화한 일하는 방식을 반영한다. - 이러한 표현은 업무의 혼란을 개인의 실패로만 보지 않고, 많은 사람이 공유하는 문화적 경험으로 바라보게 한다. 업무 효율을 높이려면 `Toggle Tax`를 줄이도록 작업 전환을 최소화하고, `Zoom Zen`을 위해 회의 안건과 종료 시간을 명확히 정하는 것이 좋다. 또한 `Fidelity Fluency`처럼 업무 목적에 맞는 완성도만 추구하면 불필요한 수정과 디지털 과부하를 줄일 수 있다.

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

올해 출시된 주요 기능 Top

2023년 Figma는 디자인에서 개발까지 팀이 함께 작업하기 쉽게 만드는 기능을 대거 출시했다. 이 글은 Dev Mode, 변수, 고급 프로토타이핑 같은 대형 기능뿐 아니라 폰트 미리보기와 컴포넌트 탐색처럼 작업 흐름을 개선한 세부 업데이트까지, 올해의 대표적인 10개 기능을 소개한다. 기능의 순위를 매기기보다 제품 개발 단계별로 각 업데이트가 제공하는 정밀함과 생산성 향상에 초점을 둔다. ## 2023년 Figma 업데이트의 방향 - Config 2023에서 다음과 같은 주요 기능을 공개했다. - 개발자를 위한 새로운 작업 공간인 **Dev Mode** - 디자인 시스템과 값을 관리하는 **Variables** - **고급 프로토타이핑** 기능 - 디자인에서 구현으로 넘어가는 과정의 편의성을 높이는 다양한 품질 개선 - 연말까지 약 200개 이상의 기능과 업데이트가 출시되었으며, 최신 **Little Big Updates**에서도 42개의 개선 사항을 추가로 선보였다. - Figma는 눈에 띄는 대형 기능뿐 아니라 버그 수정과 사용성 개선도 제품 개발 과정에서 중요한 업데이트로 평가한다. ## 캔버스에서 바로 확인하는 폰트 미리보기 - 폰트 선택기에서 실제로 폰트를 적용하지 않아도 캔버스 위에 글꼴 모양을 미리 볼 수 있다. - 사용자는 폰트 목록 위에 마우스를 올리는 것만으로 텍스트가 각 서체에서 어떻게 보이는지 확인할 수 있다. - 기존처럼 폰트를 하나씩 선택하고 되돌리는 과정을 반복하지 않아도 되므로 적절한 서체를 빠르게 비교할 수 있다. - Inter 외에도 다양한 글꼴을 자연스럽게 탐색하도록 돕는, 작지만 실질적인 작업 흐름 개선이다. ## 컴포넌트 탐색을 돕는 모달과 플레이그라운드 - Assets 패널에서 컴포넌트를 클릭하면 상세 정보를 보여주는 모달을 열 수 있다. - 모달에서는 다음 정보를 확인할 수 있다. - 컴포넌트의 상세 내용 - 원본 컴포넌트가 포함된 메인 라이브러리로 이동하는 링크 - Professional 플랜 이상에서는 **Component Playground**를 사용할 수 있다. - 플레이그라운드에서 다음 항목을 미리 확인하고 실험할 수 있다. - 컴포넌트 변형(variants) - 컴포넌트 속성(properties) - 변수 모드(variable modes) - 실제 디자인에 적용하기 전에 여러 상태를 자유롭게 시험할 수 있어 반복 작업이 줄고, 디자인 시스템을 활용하는 흐름이 더 빨라진다. ## 개발자와 디자이너의 협업 강화 - Dev Mode는 개발자가 구현에 필요한 정보를 더 직접적으로 얻도록 설계된 별도 작업 공간이다. - Figma의 2023년 업데이트 전반은 디자인 결과물을 만드는 데서 끝나지 않고, 팀이 함께 빌드하는 과정까지 연결하는 데 초점을 맞췄다. - 대형 기능 출시와 세부적인 사용성 개선을 함께 추진함으로써 제품 개발의 여러 단계에서 작업 효율을 높이려 했다. Figma를 사용하는 팀이라면 Dev Mode와 Variables 같은 구조적 기능뿐 아니라 폰트 미리보기, 컴포넌트 플레이그라운드처럼 반복적인 탐색 시간을 줄이는 기능도 함께 활용하는 것이 좋다. 작은 편의 기능과 큰 협업 기능이 결합될 때 디자인-개발 전환 과정의 효율이 가장 크게 향상된다.

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

Headspace와 함께 살아

Headspace는 제품·파트너십·브랜드 확장에 대응하려면 수작업과 플러그인 중심의 디자인 시스템을 확장 가능한 구조로 전환해야 했다. 이를 위해 Figma의 변수와 디자인 토큰을 도입하고, 단일 브랜드용 시스템을 여러 브랜드와 플랫폼을 지원하는 시스템으로 재구축했다. 그 결과 디자인·엔지니어링 팀이 공유할 수 있는 소스 오브 트루스를 마련하고, 반복적인 색상·타이포그래피 변경 작업을 크게 줄일 수 있었다. ## 확장에 한계가 있던 기존 디자인 시스템 - Headspace는 앱, 웨어러블, VR, 다양한 브랜드 협업 등 100개국 이상에서 여러 접점을 운영하고 있었다. - 기존 시스템은 수작업과 플러그인에 크게 의존해 규모가 커질수록 유지보수가 어려웠다. - 색상이 고정된 hex 코드로 관리되어 동일한 색상에 여러 값이 생겼고, 화면과 제품 간 사용자 경험이 일관되지 않았다. - 색상 팔레트처럼 단순한 변경에도 디자인 시스템 담당자가 몇 시간에서 며칠을 소비해야 했다. - 플러그인은 임시 해결책이었지만 다음과 같은 문제가 있었다. - 디자이너가 자주 사용하지 않으면 학습 비용이 높았다. - Figma의 스타일을 수정할 때마다 플러그인을 다시 설정해야 했다. - 디자인·엔지니어링 팀이 신뢰할 수 있는 단일 기준점을 제공하지 못했다. ## 여러 브랜드를 위한 시스템으로 전환 - 2021년 Ginger와의 합병이 발표되면서 Headspace는 단일 브랜드용 시스템의 한계를 해결해야 했다. - 새 시스템은 Headspace뿐 아니라 Headspace Care와 향후 파트너 브랜드까지 수용할 수 있어야 했다. - 기존 시스템을 감사한 뒤 컴포넌트와 패턴을 다시 구축해 디자이너와 엔지니어가 쉽게 찾고 참조할 수 있도록 했다. - 이 과정에서 Headspace 최초의 디자인 토큰 시스템을 만들었다. - 색상, 타이포그래피 등 반복적으로 사용되는 디자인 속성을 추상화해 브랜드별로 재사용하고 변경할 수 있는 기반을 마련했다. ## Figma 변수와 디자인 토큰 도입 - Headspace는 기존 플러그인 중심 워크플로를 Figma의 네이티브 변수 기능으로 대체했다. - 색상 값을 직접 입력하는 대신 의미 기반 토큰으로 관리했다. - 예: 특정 hex 코드가 아니라 배경색, 텍스트색, 강조색과 같은 역할 중심 이름을 사용 - 변수에 값을 연결하면 하나의 값을 변경해 이를 사용하는 여러 컴포넌트와 화면에 일괄 반영할 수 있다. - 테마와 브랜드가 달라져도 같은 컴포넌트 구조를 유지하면서 변수 값만 교체할 수 있다. - Steven은 약 2년 동안 플러그인 기반 시스템을 구축했지만, 변수 도입 후 색상 토큰과 타이포그래피를 하루 만에 변수로 구현했다고 설명한다. - 변경 사항은 한 달 이내에 디자이너와 엔지니어에게 배포되었다. ## 디자인·엔지니어링 협업 개선 - 토큰과 컴포넌트를 명확하게 구조화해 디자인과 코드 사이의 대응 관계를 쉽게 만들었다. - 디자이너는 반복적인 스타일 수정 대신 제품 경험과 시스템 개선에 집중할 수 있게 되었다. - 엔지니어는 임의의 색상값이나 스타일을 해석하는 대신 공유된 토큰을 기준으로 구현할 수 있다. - 디자인 시스템이 브랜드 가이드 문서에 머무르지 않고 실제 제품 제작 과정에서 작동하는 소스 오브 트루스가 되었다. - 여러 제품과 플랫폼이 늘어나도 동일한 원칙과 컴포넌트를 재사용할 수 있는 확장성을 확보했다. Headspace 사례는 디자인 시스템을 단순히 컴포넌트 모음으로 관리하기보다, 변수와 토큰을 활용해 브랜드·테마·플랫폼 변화를 흡수하는 구조로 설계해야 한다는 점을 보여준다. 특히 제품과 조직이 빠르게 성장한다면 하드코딩된 스타일과 플러그인 의존성을 줄이고, 의미 기반 토큰과 네이티브 변수부터 정비하는 것이 실용적인 출발점이다.

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

변수에 관한 모든 궁금증 해결

Figma의 변수(Variables)는 단순한 디자인 토큰을 넘어 여러 상태와 플랫폼에 따라 디자인 값을 동적으로 바꾸고, 디자인과 코드를 더 밀접하게 연결하는 기능이다. 이번 업데이트로 효과, 선 두께, 투명도, 레이아웃 그리드, 모서리 반경, 중첩된 컴포넌트 인스턴스까지 변수로 제어할 수 있게 되어 반응형·다중 플랫폼 디자인의 유연성이 크게 향상됐다. Figma는 앞으로 타이포그래피 영역까지 변수 활용을 확장할 계획이다. ## 변수의 확장된 활용 - 변수는 색상이나 간격 같은 고정된 토큰을 대체하는 데 그치지 않고, 모드에 따라 값이 달라지는 유연한 설계 단위로 사용된다. - 데스크톱·모바일, 라이트·다크 모드, 브랜드별 테마 등 서로 다른 조건에 맞춰 디자인을 한 번에 조정할 수 있다. - Headspace처럼 디자인 시스템의 일관성을 유지하면서도 다양한 제품 상황과 협업 요구에 대응하는 데 활용할 수 있다. - 변수의 개방적인 구조 덕분에 일반적인 디자인 시스템뿐 아니라 Figma 안에서 게임과 인터랙티브 작품을 만드는 등 창의적인 용도로도 사용된다. ## 효과와 시각적 속성의 반응형 제어 - 블러 크기, 드롭 섀도의 색상, 오프셋 거리 등 효과의 다양한 속성에 변수를 바인딩할 수 있다. - 모드가 바뀌면 효과 값도 함께 변경되므로, 플랫폼이나 테마에 맞는 시각적 표현을 자동으로 적용할 수 있다. - 레이어의 불투명도 역시 변수로 제어할 수 있으며, 불투명도 필드를 마우스 오른쪽 버튼으로 클릭해 변수를 연결한다. - 개별 모서리 반경을 변수에 연결해 네 모서리를 동일하게 처리하지 않고 각각 세밀하게 조정할 수 있다. ## 플랫폼별 반응형 디자인 - 선 두께를 변수로 관리해 데스크톱과 모바일 등 플랫폼별로 다른 스트로크 값을 적용할 수 있다. - 레이아웃 그리드도 변수와 모드에 따라 변경할 수 있어 화면 크기나 기기별 레이아웃을 더욱 정밀하게 설계할 수 있다. - 동일한 컴포넌트 구조를 유지하면서 모드만 전환해 픽셀 단위로 최적화된 디자인을 만들 수 있다. ## 중첩된 컴포넌트 인스턴스 제어 - 컴포넌트 내부에 포함된 다른 컴포넌트 인스턴스의 변형(variant)에도 변수를 연결할 수 있다. - 이를 통해 복잡한 컴포넌트 구조에서도 내부 요소의 상태와 속성을 상위 시스템에서 유연하게 제어할 수 있다. - 여러 단계로 중첩된 디자인 시스템을 구성할 때 반복적인 수동 수정이 줄어든다. ## 변수와 스타일의 관계 - 스타일은 특정 색상, 텍스트, 효과 등을 재사용하는 데 적합한 반면, 변수는 조건이나 모드에 따라 값이 바뀌는 동적 상황에 더 적합하다. - 변수는 기존 스타일을 대체하기보다는 스타일과 함께 사용해 디자인 시스템을 확장하는 방식으로 이해할 수 있다. - 변수의 활용 범위가 넓어지면서 디자인 파일의 값과 실제 코드에서 사용하는 토큰 사이의 연결도 더 자연스러워진다. ## 디자인과 코드의 연결 강화 - 변수 기반으로 디자인 값을 관리하면 개발자가 사용하는 플랫폼별 토큰 및 테마 값과 디자인 시스템을 맞추기 쉬워진다. - 모드와 변수 구조를 코드의 상태값이나 디자인 토큰 구조에 대응시킬 수 있어 핸드오프 과정의 불일치를 줄일 수 있다. - Figma는 이러한 연계를 앞으로 타이포그래피까지 확장하려 하며, 글꼴 크기·행간·문자 간격 등도 더 유연하게 관리할 가능성을 제시한다. 실무에서는 먼저 색상과 간격처럼 반복 사용이 많은 값을 변수화한 뒤, 라이트·다크 모드나 모바일·데스크톱 모드를 구성하는 것이 좋다. 이후 효과, 투명도, 그리드, 컴포넌트 상태로 범위를 넓히면 디자인 시스템의 일관성과 반응형 설계 효율을 함께 높일 수 있다.

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

Config 202

Figma는 커뮤니티 중심의 컨퍼런스인 Config 2024를 더 많은 참여와 원활한 경험을 제공하는 행사로 발전시키겠다고 밝혔다. 2024년 6월 26~27일 샌프란시스코에서 열리며, 디자인·AI·개발·디자인 시스템 등을 주제로 75명 이상의 연사가 참여한다. 참가자 피드백을 반영해 세션 예약제, 개발자 콘텐츠 확대, 교류 시간 확보, 다국어 지원 등을 도입한다. ## 커뮤니티 중심의 컨퍼런스 - Config는 단순한 제품 발표회가 아니라 다음을 위한 행사로 소개된다. - 커뮤니티 구성원 간의 교류 - 실무 중심의 학습과 아이디어 공유 - 제품을 만드는 사람들의 작업과 전문성에 대한 축하 - 2020년 첫 오프라인 행사에서 약 1,000명의 Figma 사용자를 모은 이후, Figma와 커뮤니티의 성장에 맞춰 행사의 규모와 범위를 확장해 왔다. - 팬데믹 이후 첫 대규모 오프라인 Config에서 얻은 경험을 2024년 행사 운영에 반영한다. ## 세션 예약제로 좌석 보장 - 참가자는 원하는 브레이크아웃 세션을 사전에 예약할 수 있다. - 예약한 세션에 제시간에 도착하면 좌석을 보장받는다. - 매우 얼리버드 티켓 구매자는 다른 참가자보다 24시간 먼저 세션을 예약할 수 있다. - 인기 세션의 긴 대기 줄과 좌석 부족 문제를 줄이려는 개선이다. ## 개발자를 위한 프로그램 확대 - 제품 제작에 참여하는 모든 직군을 지원하기 위해 개발자 대상 콘텐츠를 늘린다. - 구체적인 세부 프로그램은 추후 공개될 예정이지만, 기존 디자인 중심 구성에서 개발 관련 트랙을 강화하는 방향이다. - 디자인 시스템, 개발, AI 등 여러 분야를 아우르는 발표가 예정되어 있다. ## 교류와 현장 경험 개선 - 참가자들이 네트워킹하거나 휴식할 수 있도록 일정에 더 많은 여유 시간을 배치한다. - 행사 공간을 확장해 다음과 같은 현장 문제를 개선한다. - 대기 줄 단축 - 이동 및 좌석 공간 확대 - 참가자 동선 개선 - 전반적인 행사 운영의 원활함 향상 - 강연을 연속해서 듣는 데 그치지 않고 커뮤니티와 직접 교류할 수 있는 경험을 강화한다. ## 글로벌 참가자를 위한 다국어 지원 - 온라인 참가자에게 영어, 프랑스어, 독일어, 일본어, 한국어, 스페인어 자막을 제공한다. - 오프라인 참가자를 위해 동시통역과 번역을 지원한다. - 향후 더 많은 언어를 행사에 추가해 글로벌 커뮤니티의 접근성을 높일 계획이다. ## 리더십 트랙 확대 - 전년도 긍정적인 반응을 바탕으로 임원 및 리더 대상 프로그램인 Leadership Collective를 확대한다. - 새로운 임원 브리핑 센터를 마련한다. - 리더를 위한 콘텐츠와 네트워킹 기회를 늘린다. - 등록 과정에서 초대 전용 트랙에 지원할 수 있다. ## 참가 및 발표자 모집 - 얼리버드 티켓은 수량이 제한되어 있으며, 자격 요건을 충족하는 참가자를 위한 장학금도 제공한다. - 참가자 의견과 발표자 제안을 이메일이나 소셜미디어로 받고 있다. - 발표 또는 세션 진행을 원하는 사람은 2023년 12월 31일까지 발표자 모집에 지원할 수 있었다. - 행사는 2024년 6월 26~27일 샌프란시스코에서 개최될 예정이었다. Config 2024는 규모만 키우는 대신 좌석 예약, 개발자 콘텐츠, 다국어 지원, 네트워킹 시간처럼 참가자의 실제 불편을 해결하는 방향으로 설계된 행사다. 비슷한 컨퍼런스를 기획한다면 참가자 피드백을 운영 방식에 직접 반영하고, 학습·교류·접근성을 균형 있게 강화하는 것이 핵심이다.

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

디자인과 창의성의 미래 (새 탭에서 열림)

피그마와 어도비는 15개월에 걸친 규제 검토 끝에, 당국의 승인을 얻을 수 있는 현실적인 경로가 없다는 판단하에 인수 합병 계약을 공식적으로 종료하기로 합의했습니다. 이번 결정은 양사의 기술적 결합이 가져올 혁신적인 디자인 생태계에 대한 비전을 뒤로한 채 각자의 길을 걷게 됨을 의미합니다. 비록 합병은 무산되었으나, 피그마는 실시간 협업과 생성형 AI, 그리고 도구 간의 심리스한 연결성이 주도할 미래 디자인 워크플로우의 청사진을 제시하며 창의성의 미래를 향한 의지를 밝혔습니다. **합병 중단 배경과 규제 환경** * 2023년 12월 18일, 피그마와 어도비는 시장 독점 및 경쟁 저해를 우려하는 규제 당국의 높은 벽을 넘지 못하고 인수 포기를 선언함. * 양사는 장기간의 검토 과정 끝에 더 이상 승인 가능성이 없다는 점에 상호 동의하며 15개월간의 인수 절차를 마무리함. **멀티플레이어 협업 기술의 확장** * 피그마의 강점인 실시간 멀티플레이어 환경을 어도비의 전문 저작 도구(예: 3D 디자인)에 이식하여 협업 효율 극대화 추진. * 한 디자이너가 3D 모델을 구축하는 동안 다른 디자이너가 실시간으로 조명이나 텍스처를 조정하는 동시 작업 환경 구상. * 전문 툴 학습 시 숙련자가 초보자와 같은 파일 내에서 실시간 가이드를 제공하는 교육적 효과 기대. **심리스한 에셋 연동과 디자인 시스템 통합** * Adobe Substance 3D에서 제작한 에셋을 피그마 목업에 배치하고, 원본 수정 시 피그마 내 에셋도 자동으로 최신화되는 실시간 동기화 기술. * 피그마의 제품 디자인과 어도비 에셋 간의 디자인 시스템(컬러 팔레트, 폰트 등) 공유 및 Adobe Fonts의 피그마 내 직접 활용. * 완성된 피그마 프로토타입을 마케팅 영상에 직접 삽입하여, 제품 디자인 변경이 영상 소스에 즉각 반영되는 워크플로우 구축. **생성형 AI '파이어플라이'와의 기술적 융합** * 어도비의 생성형 AI 모델인 '파이어플라이(Firefly)'를 피그마 워크플로우에 통합하여 UI 컨셉에 맞는 배경을 즉석에서 생성. * 반응형 디자인 대응을 위해 이미지를 자연스럽게 확장하는 '제너레이티브 필(Generative Fill)' 기능의 피그마 내 구현. * 브레인스토밍 단계의 스티키 노트를 지능적으로 분석하여 순식간에 시각화된 스토리보드로 전환하는 자동화 기능 구상. 기업 간의 물리적 합병은 멈추었으나, 피그마가 제시한 '도구 간의 경계 없는 연결'과 '실시간 협업의 확장'이라는 방향성은 향후 디자인 도구 시장의 중요한 표준이 될 것입니다. 디자이너들은 개별 툴의 숙련도를 넘어, AI와 실시간 협업 기능을 활용해 아이디어에서 프로토타입까지의 도달 시간을 단축하는 효율적인 워크플로우 구축에 주목해야 합니다.

figma3분 읽기큐레이션 요약

가치 있는 디자인 커리어를 위한

Dan Mall은 25년간 디자이너, 창업가, 교육자, 작가로 활동하며 얻은 경험을 바탕으로 지속 가능한 디자인 커리어의 원칙을 제시한다. 글의 중심 메시지는 모든 선택을 하나의 ‘베팅’으로 보고, 가치 있는 목표를 설정한 뒤 자신의 강점을 활용해 실행하라는 것이다. 또한 시작하기 전에 원하는 최종 결과를 분명히 해야 복잡한 커리어 결정을 효과적으로 이끌 수 있다고 강조한다. ## 다양한 역할을 통한 지속적인 성장 - Mall은 1998년 교회 웹사이트를 만들며 디자인을 시작한 뒤 에이전시, 스타트업, 교육, 저술 등 여러 영역을 경험했다. - 직접 에이전시를 운영하고 두 개의 스타트업을 공동 창업했으며, 견습 프로그램을 운영하고 수천 명의 학생을 가르쳤다. - 이러한 경험을 통해 디자인 역량은 최신 도구나 트렌드를 따라가는 것만이 아니라, 문제를 새롭게 해결하고 지속적으로 성장하는 과정에서 확장된다고 설명한다. - 디자인 시스템 교육 기관인 Design System University를 통해 대규모 조직이 디자인을 체계적으로 운영하도록 돕고 있다. ## 가치 있는 목표를 선택하기 - 새로운 일을 시작하기 전, 다음과 같은 질문을 던진다. - 이 일의 최종 목적은 무엇인가? - 결과적으로 지금보다 더 나은 상태에 도달할 수 있는가? - 목표는 흥미롭고, 중요하며, 동시에 도전적이어야 한다는 Michael Bungay Stanier의 기준을 소개한다. - Mall은 특히 ‘흥미로운가’를 중요하게 여긴다. 자신을 움직일 만큼 설레지 않는 일은 대체로 추진하지 않는다. - 가족과 더 많은 시간을 보내기 위해 기존의 꿈의 직장을 떠나 자신의 에이전시를 만든 사례를 들며, 개인의 가치와 목표가 커리어 선택의 출발점이 될 수 있다고 설명한다. ## 자신의 불공정한 강점에 베팅하기 - 모든 의사결정은 다른 선택지를 포기한다는 점에서 일종의 베팅이다. - 직업 선택, 이직과 이주, 계약과 영업, 주택 구매 같은 결정뿐 아니라 일상적인 선택도 기회비용을 수반한다. - 성공 가능성을 높이려면 누구나 가진 일반적인 조건이 아니라 자신만의 ‘불공정한 강점’을 활용해야 한다. - 전문 지식과 경험 - 업계 평판과 네트워크 - 자금과 자원 - 특정 분야에 대한 독특한 통찰 - 유리한 위치나 교육 배경 - Mall은 이러한 요소를 MILES 프레임워크로 정리한다. - **Money**: 자금 - **Intelligence & Insight**: 지능과 통찰 - **Location & Luck**: 위치와 운 - **Education & Expertise**: 교육과 전문성 - **Status**: 평판과 지위 - 자신의 에이전시를 시작할 때 이미 보유한 에이전시 경험, 좋은 평판, 안정적인 고객 흐름이 성공 확률을 높이는 강점으로 작용했다. - Design System University 역시 10년간 디자인 시스템과 대규모 디자인을 다뤄온 경험, 해당 분야의 문제와 패턴에 대한 깊은 이해가 기반이 되었다. - 강점은 성공을 보장하지 않지만, 같은 목표를 향한 베팅의 확률을 높여준다. ## 최종 결과를 먼저 정하고 시작하기 - Stephen Covey의 원칙인 “끝을 염두에 두고 시작하라”를 커리어와 프로젝트에 적용한다. - 시작 전에 명확하고 달성 가능한 최종 목표를 정하면 어떤 활동에 집중할지 판단하기 쉬워진다. - Mall은 컨퍼런스 발표를 시작할 때, 자신이 존경하던 웹 디자인 행사인 An Event Apart의 연사가 되는 것을 장기 목표로 삼았다. - 목표를 구체적으로 설정하면 막연한 희망이 아니라 필요한 역량, 평판, 작업물을 역산해 준비할 수 있다. - 따라서 프로젝트나 커리어 결정을 내릴 때 “무엇을 하고 싶은가”뿐 아니라 “어떤 결과에 도달하고 싶은가”를 먼저 정의하는 것이 중요하다. ## 실용적인 적용 새로운 커리어 기회를 검토할 때는 먼저 그 목표가 자신에게 흥미롭고 중요한지 확인하고, 현재 가진 전문성·네트워크·평판이 어떻게 성공 가능성을 높이는지 점검하는 것이 좋다. 이후 원하는 최종 상태를 구체적으로 정한 뒤, 그 결과에서 거꾸로 필요한 경험과 실행 단계를 설계하면 더 현실적이고 지속 가능한 선택을 할 수 있다.

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

코드 생성이 (진짜)

코드 생성(codegen)은 디자인-개발 과정을 완전히 자동화하기보다, 개발자가 더 빠르고 정확하게 작업하도록 돕는 확장 도구로 활용할 때 가장 효과적이다. 특히 AI 코드 생성 결과는 정확성과 유용성에 한계가 있으므로, 개발자를 대체하기보다 적절한 컴포넌트·속성·코드 패턴을 제안해 초기 작업을 앞당기는 방향이 현실적이다. Figma는 이를 “0에서 1”이 아닌 “0에서 0.5”로 빠르게 이동시키는 도구로 설명한다. ### 코드 생성의 범위와 현실 - 코드 생성은 정해진 규칙이나 명세를 바탕으로 코드를 자동 생성하는 과정이다. - 범위가 넓으며 다음과 같은 형태를 포함한다. - IDE의 자동 완성 기능 - 반복적인 코드 패턴을 위한 스니펫과 템플릿 - Bubble 같은 비주얼 프로그래밍·노코드 도구 - GitHub Copilot, Replit Ghostwriter 같은 AI 기반 코드 생성 도구 - Stack Overflow 2023 조사에서 개발자의 82%가 AI 도구를 사용해 코드를 작성한다고 답했다. - 반면 AI 도구의 정확성을 매우 신뢰한다고 답한 비율은 3%에 불과했다. - 따라서 코드가 생성된다는 사실보다, 실제 프로젝트의 프레임워크와 코드베이스에 맞고 개발자가 유용하게 사용할 수 있는지가 더 중요하다. ### 디자인을 코드로 그대로 변환하기 어려운 이유 - Figma는 Dev Mode를 처음 개발할 때 디자인을 코드로 자동 변환하는 것을 목표로 했다. - 초기 결과는 가능성을 보였지만, 다양한 개발자의 요구와 프레임워크를 모두 만족하는 코드를 만들기는 어려웠다. - 자동 생성된 코드가 문법적으로 맞더라도 팀의 컴포넌트 구조, 네이밍 규칙, 상태 관리 방식과 맞지 않으면 실무에서는 유용하지 않을 수 있다. - 이에 따라 Figma는 디자인을 코드로 직역하는 방식보다, 디자인과 개발 사이의 해석과 협업을 보조하는 방식으로 방향을 전환했다. ### 개발자를 대체하는 도구가 아닌 지능 증폭 도구 - 코드 생성은 개발자를 대신하는 자동화 시스템보다 개발자의 능력을 확장하는 도구로 보는 편이 적절하다. - 글은 이를 **지능 증폭(Intelligence Amplification, IA)**으로 설명한다. - 복잡한 문제를 이해하고 - 필요한 정보를 빠르게 찾으며 - 해결책을 도출하는 인간의 능력을 강화하는 접근이다. - AI가 기술이 주도하는 미래를 상징한다면, IA는 사람이 주도권을 유지한 채 기술의 도움을 받는 방식이다. - 개발자는 최종 구조와 구현 방식을 결정하고, codegen은 탐색·반복·초기 작성에 드는 시간을 줄인다. ### “0에서 0.5”까지 빠르게 이동하기 - 디자인 시스템과 컴포넌트 라이브러리를 사용하는 제품에서는 codegen이 핸드오프 과정의 추측을 줄일 수 있다. - 디자인 요소에 대응하는 컴포넌트 이름이나 속성 값을 제안해 개발자가 어떤 도구를 사용할지 빠르게 판단하도록 돕는다. - 디자인 시스템을 공구 상자에 비유하면, codegen은 상황에 맞는 공구와 사용법을 추천하는 역할을 한다. - 완성된 코드를 제공하기보다는 빈 화면에서 작업을 시작할 수 있는 출발점을 만들어 준다. - 즉, “0에서 1”까지 완성하는 자동화보다 “0에서 0.5”까지 빠르게 진입하게 하는 보조 기능에 더 큰 가치가 있다. ### 팀과 코드베이스에 맞춘 구체적인 활용 - codegen의 효과는 일반적인 자동화 도구보다 특정 팀·회사·워크플로에 맞게 적용할 때 커진다. - 디자인 시스템과 컴포넌트 라이브러리가 이미 Figma에 있다면 별도의 완전 자동화 디자인-코드 변환 앱이 반드시 필요하지 않다. - 대신 다음 기능을 활용하는 편이 실용적이다. - 디자인 토큰과 변수 참조 - 컴포넌트 및 속성 문서 확인 - 팀 전용 codegen 플러그인 구축 - 프로젝트 규칙에 맞춘 사용자 정의 코드 스니펫 생성 - 이러한 정보와 힌트는 개발자가 디자인을 빠르게 해석하고 직접 코드를 작성하도록 돕는다. ### 실용적인 결론 codegen은 생성된 코드를 그대로 채택하는 자동화 수단이 아니라, 팀의 디자인 시스템과 개발 규칙을 이해한 상태에서 적절한 컴포넌트와 구현 방향을 제안하는 보조 수단으로 사용하는 것이 좋다. 특히 토큰, 문서, 컴포넌트 메타데이터, 사용자 정의 스니펫을 코드베이스와 연결하면 개발자의 판단을 유지하면서 반복 작업과 초기 탐색 시간을 크게 줄일 수 있다.

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

스포티파이의 디자인

Spotify는 45개 플랫폼과 2,000종 이상의 기기에서 일관된 브랜드 경험을 제공하기 위해 디자인 시스템 Encore를 플랫폼별 체계에서 크로스플랫폼 체계로 확장했다. 초기에는 모바일과 웹 시스템이 분리되어 유연성을 얻었지만, 시간이 지나며 컴포넌트의 불일치와 중복이 커졌다. 이에 공통 기반과 재사용 가능한 중간 계층을 마련하고, 컴포넌트를 처음부터 여러 플랫폼이 함께 설계하는 방식으로 전환했다. ## 일관된 경험이 필요해진 배경 - Spotify는 TV, 자동차, 모바일, 컴퓨터 등 다양한 환경에서 오디오 콘텐츠를 제공하게 됐다. - 2019년 기준 45개 플랫폼, 2000종 이상의 기기, 200개 브랜드에 걸쳐 서비스를 제공해야 했다. - 목표는 모든 플랫폼을 단순히 지원하는 것이 아니라, 어떤 기기에서도 사용자가 “Spotify답다”고 느끼는 일관된 경험을 만드는 것이었다. - 디자인 시스템의 컴포넌트가 플랫폼 간 경험을 통합하는 핵심 수단으로 강조됐다. ## Encore의 초기 구조와 한계 - Encore는 2019년 두 개의 하위 시스템으로 출발했다. - **Encore Consumer Mobile**: 모바일 중심 경험을 위한 유연한 UI 컴포넌트 카탈로그 - **Encore Web**: 다양한 웹 제품을 위한 시스템 - 색상과 타이포그래피 같은 기본 디자인 결정에는 디자인 토큰을 사용했다. - 그러나 각 하위 시스템이 독립적으로 발전하면서 버튼의 크기, 타이포그래피, 상태 표현 등에서 차이가 생겼다. - 제품팀의 요구가 커지면서 컴포넌트가 지나치게 유연해졌고, 플랫폼 간 공통성이 약해졌다. ## 공통 기반과 재사용 계층의 도입 - 2022년 Spotify는 유연성에 치우친 구조를 재조정할 필요가 있다고 판단했다. - Encore Mobile을 위한 재사용 가능한 컴포넌트 제작 전담 팀을 구성했다. - 이 새로운 계층은 공통 기반과 Consumer Mobile 사이에 위치했다. - 이를 통해: - Consumer Mobile이 모든 컴포넌트를 직접 제공해야 하는 부담을 줄이고 - Web과 Mobile 사이의 플랫폼 대응성을 높이며 - 제품별로 중복 구현되는 컴포넌트를 줄일 수 있었다. - Web 팀과 협력해 크로스플랫폼 컴포넌트를 나중에 맞추는 대신, 처음부터 함께 개발하기 시작했다. ## 크로스플랫폼 컴포넌트 설계 방식 - 기존처럼 사용자 조사, 디자인, 개발로 이어지는 과정 자체는 유지했다. - 가장 큰 변화는 디자인 단계에서 특정 플랫폼 하나만을 대상으로 하지 않는 것이었다. - iOS, Android, Web 팀이 함께 각 플랫폼의 요구사항과 특성을 조사하고, 공통 경험을 조율했다. - 플랫폼별 고유성을 없애는 것이 아니라, 공통된 구조와 시각적 언어를 유지하면서 각 환경에 맞게 적용하는 것이 목표였다. - 웹, 모바일, TV는 입력 방식과 화면 크기 등 사용 맥락이 다르므로, 동일한 컴포넌트를 그대로 복제하기보다 플랫폼의 장점을 보존해야 했다. - 이를 위해 각 플랫폼 전문가가 협업하는 구조가 중요했다. 웹과 모바일 양쪽 모두에 정통한 디자이너는 드물기 때문에, 여러 분야의 전문성을 한 과정 안에서 결합해야 했다. Spotify의 사례는 디자인 시스템을 플랫폼별 컴포넌트 모음으로 관리하기보다, 공통 기반·재사용 계층·플랫폼별 특화를 연결하는 구조로 설계해야 한다는 점을 보여준다. 실무에서는 플랫폼 팀을 초기 설계 단계부터 참여시키고, 공통 토큰과 컴포넌트의 범위를 명확히 정하는 방식이 효과적이다.

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

디자인 시스템의 미래

디자인 시스템의 미래는 단순히 색상·간격 같은 값을 표준화하는 데서 나아가, 그 값의 의미와 사용 목적을 중심으로 설계하는 시맨틱 방식에 있다. 디자인 토큰과 Figma 변수는 디자인 결정을 여러 플랫폼과 코드에 일관되게 전달하고, 테마 변경과 동적 프로토타이핑까지 가능하게 한다. 따라서 변수는 디자인 시스템을 기록하는 도구를 넘어 디자인과 개발을 연결하는 핵심 기반으로 발전하고 있다. ## 디자인 시스템의 복잡성과 토큰의 필요성 - 시간이 지나면 제품 안에 동일한 목적의 색상·간격·타이포그래피 값이 중복되면서 디자인 시스템이 복잡해진다. - Google Maps는 제품에 700개가 넘는 색상이 사용되고 있음을 발견한 뒤, 이를 25개의 색조로 정리했다. - 축소된 색상 체계가 다시 무질서하게 늘어나지 않도록 디자인 토큰을 사용해 색상 팔레트를 문서화하고 배포했다. - 토큰은 색상, 숫자, 문자열, 테두리 반경, 크기, 글꼴 등 반복되는 디자인 결정을 표현하는 데이터다. - 특정 컴포넌트나 구현 방식에서 디자인 속성을 분리하므로 플랫폼에 종속되지 않고 여러 제품과 환경에서 재사용할 수 있다. - 예를 들어 모든 “나무” 요소의 색상을 변경해야 한다면, 개별 요소를 수정하지 않고 하나의 토큰만 바꿔 전체에 반영할 수 있다. ## 디자인 토큰에서 시맨틱 시스템으로 - 토큰은 디자인 결정을 코드나 특정 컴포넌트가 아닌 독립적인 값으로 관리해 일관성과 유지보수성을 높인다. - Salesforce는 2014년부터 여러 플랫폼과 소프트웨어에 동일한 디자인 원칙을 적용하기 위해 토큰을 활용한 사례로 자주 언급된다. - 토큰의 진정한 가치는 값 자체보다 값이 제품 안에서 어떤 역할을 하는지 표현하는 데 있다. - 예를 들어 단순히 `blue-500`처럼 색상 자체를 지정하기보다, `button-background-primary`처럼 사용 목적과 의미를 나타내면 테마나 브랜드가 바뀌어도 구조를 유지하기 쉽다. - 이런 시맨틱 접근은 디자인 시스템을 시각적 스타일 모음이 아니라 제품의 의도와 규칙을 표현하는 체계로 확장한다. ## Figma 변수의 역할 - Figma 변수는 디자인 속성과 프로토타이핑 동작에 재사용 가능한 값을 저장한다. - 색상, 숫자, 문자열 등 다양한 값을 한 곳에서 관리하고 여러 디자인 요소에 적용할 수 있다. - 기존 토큰의 사용 사례를 충족하면서도 값이 실제로 “변할 수 있다”는 점을 강조한다. - 변수는 디자인 시스템의 값을 중앙에서 관리해 반복 작업을 줄이고, 변경 사항을 여러 화면에 일관되게 적용한다. - 단순한 디자인 결정의 기록을 넘어 다음과 같은 기능을 지원한다. - 라이트·다크 모드와 같은 디자인 테마 전환 - 조건에 따른 프로토타이핑 로직 - 여러 플랫폼에 공유할 수 있는 재사용 가능한 값 관리 - 디자인과 코드 사이의 연결 강화 ## 디자인과 개발을 연결하는 기반 - Config 2023에서 Figma는 Dev Mode, 변수, 고급 프로토타이핑 기능 등을 공개하며 디자인에서 구현으로 이어지는 흐름을 강화했다. - 변수는 디자인 시스템이 디자인 파일 안에만 머무르지 않고 코드와 동일한 개념과 값을 공유하도록 돕는다. - 이후 공개된 Code Connect는 개발자가 실제 코드 컴포넌트와 디자인 컴포넌트를 연결하는 방향을 더욱 강화한다. - typography 및 gradient 변수, Library Analytics API 같은 기능은 디자인 시스템의 적용 범위를 넓히고 조직 전체의 사용 현황과 도입을 관리할 수 있게 한다. - 결과적으로 디자인 시스템은 디자이너만 관리하는 라이브러리가 아니라 디자인·개발·제품팀이 함께 사용하는 공통 언어가 된다. ## 실용적인 적용 방향 - 색상이나 간격 값을 무작정 늘리기보다 먼저 제품에서 각 값이 수행하는 역할을 정의한다. - 원시 값과 의미 기반 값을 구분해 관리한다. 예를 들어 `blue-500`과 `text-color-error`를 별도 계층으로 둘 수 있다. - 테마 변경 가능성을 고려해 컴포넌트에 구체적인 색상값을 직접 넣지 않는다. - 디자인 토큰을 코드와 공유할 수 있는 형식으로 관리하고, Figma 변수와 실제 구현 값의 동기화 방식을 마련한다. - 디자인 시스템의 성공 여부를 라이브러리의 크기보다 재사용성, 일관성, 코드와의 연결성, 조직 내 adoption으로 평가하는 것이 바람직하다.

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