디자인 시스템

252 개의 포스트

figma3분 읽기큐레이션 요약

디자인 시스템 구축 방법

디자인 시스템은 제품 전반의 일관성을 높이고, 재사용 가능한 컴포넌트와 공통 언어를 통해 디자인·개발 업무를 효율화하는 기반이다. 성공적인 시스템은 정해진 정답을 따르기보다 조직의 목표와 문제에 맞춰 설계하고, 제품과 팀의 변화에 따라 지속적으로 발전해야 한다. 이를 위해 목표 설정, 기존 자산 조사, 협업자 확보, 적절한 구축 방식 선택이 선행되어야 한다. ## 디자인 시스템의 목표와 범위 정의 - 컴포넌트를 만들기 전에 디자인 시스템을 도입하려는 이유를 명확히 해야 한다. - 다음 질문에 답하면서 목표를 구체화한다. - 왜 디자인 시스템이 필요한가? - 어떤 문제를 해결할 것인가? - 문제가 해결되었는지 어떻게 측정할 것인가? - 플랫폼 간 UI 불일치, 반복적인 수동 수정, 디자인·개발팀 간 협업 문제 등이 주요 도입 계기가 될 수 있다. - 디자인 시스템은 소규모 팀의 단순한 컴포넌트 모음부터 대기업의 종합적인 표준 체계까지 다양한 규모로 구성할 수 있다. - 중요한 것은 조직의 현재 상황에 맞게 시작하고, 필요에 따라 확장 가능한 구조를 만드는 것이다. ## 기존 디자인과 코드 자산 조사 - 여러 플랫폼과 디바이스에서 제품 UI를 수집한다. - 일반 화면뿐 아니라 다음과 같은 변형도 함께 확인한다. - 호버·포커스·비활성·오류 등 인터랙션 상태 - 반응형 레이아웃 - 플랫폼별 또는 제품별 대체 버전 - 스크린샷을 모으면 반복되는 시각적 패턴과 일관된 요소를 파악하기 쉽다. - 디자인 파일만 조사해서는 안 되며, 코드베이스도 함께 점검해야 한다. - 개발자가 이미 구현한 다음 자산을 확인하면 기존 엔지니어링 작업을 재활용할 수 있다. - 반복적으로 사용되는 UI 요소 - 공통 CSS 변수 - 공유 컴포넌트 - 표준화된 구현 패턴 - 디자인과 코드 양쪽을 조사해야 서로 다른 시스템이 병렬로 만들어지는 문제를 줄일 수 있다. ## 패턴 분류와 문제점 평가 - 수집한 화면과 컴포넌트를 유형별로 분류해 현재 제품의 디자인 언어를 파악한다. - 같은 문제를 여러 방식으로 해결하고 있는지 확인한다. - 다음과 같은 문제는 디자인 시스템으로 개선할 후보가 된다. - 비슷한 UI가 제품마다 다르게 보이는 경우 - 중복 컴포넌트나 불필요한 변형이 많은 경우 - 디자인팀과 개발팀이 동일한 문제를 각자 다르게 해결하는 경우 - 사용자 경험이 화면이나 플랫폼에 따라 단절되는 경우 - 이 과정은 무엇을 새로 만들지뿐 아니라 무엇을 통합·정리·폐기할지도 결정하는 단계다. ## 조직 내 챔피언 확보 - 디자인 시스템은 한 직군만의 프로젝트가 아니라 디자인, 개발, 제품 관리가 함께 참여하는 팀 작업이다. - 일관된 제품 경험에 관심이 있는 사람을 조직 내 협력자로 확보해야 한다. - 개발자는 실제 코드 구현과 유지보수를 담당하므로 초기부터 참여시키는 것이 중요하다. - 개발자는 컴포넌트의 기술적 실현 가능성, API 설계, 유지보수 비용에 대한 현실적인 의견을 제공할 수 있다. - 성공적인 디자인 시스템이 반드시 대규모 전담 조직에서 시작되는 것은 아니며, 한 명의 담당자에서 출발할 수도 있다. ## 구축 방식 선택 - 디자인 시스템을 구축하는 방법은 크게 두 가지다. - 조직의 요구에 맞춰 처음부터 직접 구축하기 - 기존 프레임워크를 도입한 뒤 제품 상황에 맞게 조정하기 - 선택할 때는 현재 보유한 디자인·코드 자산, 팀 규모, 기술 역량, 유지보수 가능성을 함께 고려해야 한다. - 기존 시스템을 그대로 복사하기보다 조직의 목표와 제품 특성에 맞는 수준으로 조정하는 것이 중요하다. ## 이후의 구축 단계 - 글은 전체 과정을 다음 세 단계로 제시한다. - 기반 마련: 목표 정의, 기존 자산 조사, 문제 평가, 협력자 확보 - 디자인 기반 정의: 색상, 타이포그래피, 간격 등 공통 시각 규칙 수립 - Figma에서 구축: 디자인 자산과 재사용 가능한 컴포넌트를 체계적으로 구성 - 구축 후에도 시스템은 고정된 결과물이 아니라 제품과 팀의 변화에 맞춰 계속 관리하고 발전시켜야 한다. 실무에서는 모든 것을 한 번에 만들기보다 가장 반복적으로 사용되고 영향이 큰 패턴부터 시작하는 것이 좋다. 디자인과 코드를 함께 조사하고 개발자를 초기 단계부터 참여시키면 실제 제품에 적용되고 유지되는 디자인 시스템을 만들 가능성이 높아진다.

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

Framework by Figma에 여러분을 초대합니다

Figma는 디자인 시스템을 단순한 스타일 가이드가 아니라 제품 설계와 개발을 지탱하는 기반으로 보고, 이를 주제로 한 글로벌 행사 ‘Framework by Figma’를 2024년 4월 16일 개최한다고 소개했다. 행사는 새로운 기능, 운영 모범 사례, 디자인-코드 연결, 디자이너와 엔지니어 간 협업을 다룬다. 이후 행사에서는 Code Connect, 타이포그래피·그라디언트 변수, Library Analytics API 등이 공개됐다. ## 디자인 시스템의 확장과 복잡성 - 디자인 시스템은 초기의 단순한 스타일 가이드에서 제품 개발 전반의 기반으로 발전했다. - 실제 도입과 운영 과정에서는 도구 선택, 자동화, 접근성, 조직 내 채택률 관리 등 다양한 문제가 발생한다. - Figma는 현재와 미래의 복잡한 요구를 지원하는 기능과 운영 전략을 행사에서 공유하려 했다. - 시스템을 미리 구조화한 경우뿐 아니라 자유롭게 작업하는 상황도 지원해야 한다는 철학을 강조했다. ## Framework 행사에서 다룬 내용 - 새로운 디자인 시스템 기능을 심층적으로 소개한다. - 디자인 시스템을 효과적으로 구축하고 유지하는 모범 사례를 공유한다. - Verizon 등 업계 기업의 디자인 시스템 구축 및 운영 경험을 소개한다. - Figma 제품팀이 향후 개발 방향을 설명한다. - Bumble, GitHub, Hewlett Packard가 참여하는 디자인-코드 연계 라운드테이블을 진행한다. - 참가자들의 실무 질문에 답하는 전문가 Q&A를 마련한다. ## 디자이너와 엔지니어의 연결 - 성공적인 디자인 시스템에는 디자인과 개발 조직의 긴밀한 협업이 필요하다고 설명한다. - 세션은 디자인 원칙부터 기술적 구현까지 두 직군의 공통 관심사를 다룬다. - 디자인 시스템을 코드와 더 가깝게 연결하는 새로운 기능도 소개 대상에 포함됐다. - 이는 디자인 산출물이 실제 제품 코드로 이어지는 과정의 간극을 줄이려는 방향이다. ## 행사에서 공개된 기능 - **Code Connect**: 디자인 시스템 구성 요소와 개발자가 사용하는 코드 컴포넌트를 연결한다. - **타이포그래피 변수와 그라디언트 변수**: 디자인 토큰의 표현 범위를 확장하고 일관된 스타일 관리를 돕는다. - **Library Analytics API**: 조직 내 라이브러리 사용 현황과 디자인 시스템 채택 정도를 분석할 수 있도록 지원한다. - 이러한 기능은 디자인 시스템의 구축뿐 아니라 개발 연계와 조직 전체의 활용도 측정까지 지원하는 데 초점을 둔다. ## 글로벌 디자인 시스템 커뮤니티 - 본 행사는 온라인으로 진행되며 전 세계 디자인 시스템 실무자를 대상으로 했다. - 아시아 지역 온라인 행사는 4월 18일, 도쿄 행사는 4월 23일에 별도로 진행될 예정이었다. - 런던 등 여러 도시에서는 현지 밋업도 계획됐다. - 온라인 스트림을 통해 지역과 관계없이 주요 발표와 세션에 참여할 수 있도록 했다. Figma가 제시한 방향은 디자인 시스템을 엄격한 규칙만으로 운영하기보다, 구조화된 관리와 자유로운 창작을 함께 지원하는 것이다. 조직에서는 디자인 토큰과 컴포넌트 표준화뿐 아니라 코드 연결, 사용량 분석, 디자이너·엔지니어 간 협업 체계까지 함께 구축하는 것이 실용적이다.

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

원활한 핸드오프를

핸드오프는 디자인이 끝나는 한순간의 전달이 아니라, 작업 중인 디자인과 맥락·커뮤니케이션이 지속적으로 오가는 과정이다. 원활한 협업을 위해서는 개발자가 필요한 정보를 명확히 확인할 수 있도록 주석을 정리하고, 디자인·개발 간 공통 언어를 만들며, 파일 구조를 체계적으로 정리해야 한다. 특히 “Ready for dev”가 실제 구현 가능한 상태를 의미하도록 팀의 기준과 작업 방식을 맞추는 것이 중요하다. ## 주석과 콜아웃을 간결하고 명확하게 정리하기 - 주석은 디자인 결정의 의도와 개발자가 놓치기 쉬운 세부 사항을 전달하는 수단이다. - 모든 간격이나 색상을 반복해서 설명하기보다, 이미 변수나 스타일로 정의된 정보는 생략하고 다음과 같은 내용을 우선적으로 표시한다. - 새로 사용하는 컴포넌트 - 프로토타입만으로는 명확하지 않은 인터랙션 - 플랫폼별로 다르게 보여야 하는 요소 - 특정 레이어의 속성, 크기, 동작 방식 - 개발자와 먼저 어떤 정보가 유용한지 합의하면 불필요한 주석을 줄일 수 있다. - Figma의 annotations와 Dev Mode를 활용하면 스펙, 측정값, 설명을 최종 디자인에 직접 고정할 수 있다. - 주석은 디자이너와 개발자 간 대화를 대체하는 것이 아니라, 대화가 필요한 지점을 명확하게 해 커뮤니케이션을 개선한다. ## 디자인과 개발의 공통 언어 만들기 - 디자인과 개발은 서로 다른 분야이므로 같은 용어가 다른 의미로 해석될 수 있다. - 예를 들어 디자이너가 “toggle”이라고 했을 때 개발자가 “switch”를 떠올릴 수 있다. - 프로젝트 초기에 컴포넌트와 속성의 명칭을 합의하면 이후 구현 논의에서 불필요한 혼선을 줄일 수 있다. - 색상, 폰트, 간격처럼 기초적인 디자인 요소는 변수와 스타일로 관리해 디자인과 코드가 동일한 기준을 사용하도록 한다. - 개발팀에 이미 네이밍 규칙이 있다면 디자인 시스템에도 이를 반영하는 것이 좋다. - 예를 들어 `bg-primary-active`, `body text`처럼 공유된 명칭을 사용하면 특정 색상의 헥스 코드나 폰트 세부 정보를 매번 설명하지 않아도 된다. - 디자인 시스템의 색상 휠과 같은 도구를 활용하면 색조와 명도를 일관되게 선택하고 적용할 수 있다. ## 파일과 캔버스를 라벨로 정리하기 - Figma의 무한 캔버스는 아이디어를 자유롭게 펼치기 좋지만, 개발자가 처음 파일을 열었을 때 필요한 화면을 찾기 어렵게 만들 수 있다. - 브레인스토밍과 반복 작업 단계에서는 파일이 다소 복잡해도 괜찮지만, 개발에 넘길 시점에는 구조를 정리해야 한다. - 관련 디자인을 섹션으로 묶어 캔버스 내 탐색 범위를 좁힌다. - 구현이 준비된 섹션이나 프레임에는 “Ready for dev” 상태를 표시해 개발자가 우선 확인할 대상을 알 수 있게 한다. - 팀 차원에서 동일한 파일 템플릿을 사용하면 매번 구조를 새로 파악해야 하는 부담과 컨텍스트 전환을 줄일 수 있다. 실무에서는 주석을 많이 다는 것보다 필요한 정보만 남기고, 변수·스타일·공통 명칭을 디자인 시스템에 정착시키는 것이 효과적이다. 또한 개발 전달 전에는 파일을 정리하고 구현 범위를 명확히 표시해 “Ready for dev”가 팀 내에서 실제로 신뢰할 수 있는 상태가 되도록 관리하는 것이 좋다.

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

디자인 시스템이란 무엇

디자인 시스템은 제품의 시각적 요소와 상호작용 방식을 일관되게 유지하도록 돕는 공통 언어이자 설계·개발을 위한 체계다. 색상, 아이콘, 버튼, 문구 같은 요소를 표준화하고 재사용함으로써 제작 시간을 줄이고 사용자 경험과 브랜드 정체성을 보호한다. 단순한 스타일 가이드가 아니라 원칙, 컴포넌트, 패턴, 기술 문서와 프로세스를 포괄하는 지속적으로 발전하는 기반이다. ## 디자인 시스템이란 무엇인가 - 제품과 서비스의 디자인·개발을 안내하는 **재사용 가능한 구성 요소와 표준의 집합**이다. - 복잡한 디지털 제품을 만들 때 팀이 공유할 수 있는 통일된 언어와 구조를 제공한다. - 요소를 매번 새로 설계하지 않아도 되므로 대규모 제품 개발에서 시간과 노력을 줄인다. - 디자인 시스템이 없으면 화면마다 스타일과 동작이 달라지는 **일관성 위기**가 발생할 수 있다. - 사용자가 인터페이스를 혼란스럽게 느낄 수 있다. - 브랜드 정체성이 약화될 수 있다. - 반복적인 디자인 작업과 구현 비용이 늘어난다. ## 디자인 시스템의 계층 구조 ### 1. 디자인 시스템 - 제품 생태계 전체를 아우르는 최상위 개념이다. - 다음과 같은 자원을 포함할 수 있다. - 기술 사양 - 디자인 토큰 - 컴포넌트 및 패턴 문서 - 모범 사례 - UX 설계 원칙 - 제품 개발 프로세스 - 고정된 규칙집이 아니라 제품과 조직의 변화에 따라 계속 발전하는 기반이다. ### 2. 컴포넌트 및 패턴 라이브러리 - 제품에서 반복적으로 사용하는 시각 요소와 상호작용 방식을 모아 둔 라이브러리다. - 컴포넌트의 예: - 버튼 - 입력 필드 - 기타 UI 요소 - 패턴의 예: - 내비게이션 흐름 - 데이터 표시 방식 - 레이아웃과 템플릿 - 반복되는 사용자 상호작용 - 코드 스니펫, 기술 사양, 사용 지침을 함께 제공해 디자인 의도를 실제 구현으로 연결한다. - 디자이너와 개발자가 동일한 기준을 참고하는 협업 지점 역할을 한다. - **컴포넌트 라이브러리**가 개별 UI 요소에 집중한다면, **패턴 라이브러리**는 더 넓은 문제 해결 방식과 사용자 흐름을 다룬다. ## 디자인 시스템과 스타일 가이드의 차이 - 스타일 가이드는 주로 다음과 같은 시각적 요소를 정의한다. - 색상 - 글꼴과 타이포그래피 - 이미지와 시각적 표현 - 디자인 시스템은 스타일 가이드보다 범위가 넓다. - 코딩 표준 - 사용성 원칙 - 상호작용 패턴 - 기술 문서 - 제품 개발 프로세스까지 포함할 수 있다. - 따라서 스타일 가이드는 디자인 시스템을 구성하는 일부로 볼 수 있다. ## 3. 기초 요소 - 제품의 전반적인 시각 언어와 목소리·말투를 정의한다. - 대표적인 구성 요소는 다음과 같다. - 색상 - 타이포그래피 - 아이콘 - 로고 - 일러스트레이션 - 접근성 가이드라인 - 브랜드 가이드라인 - 단순히 화면을 예쁘게 만드는 것을 넘어, 제품이 어떤 인상을 주고 어떤 방식으로 소통할지를 결정한다. ## 디자인 시스템과 UX - 디자인 시스템이 디자이너의 창의성을 제한하고 모든 화면을 똑같이 만든다는 것은 흔한 오해다. - 실제로는 반복적인 문제를 해결해 디자이너가 더 중요한 사용자 경험과 제품 문제에 집중하도록 돕는다. - 공통 요소와 기준을 재사용하면 일관성을 확보하면서도 제품 목적에 맞는 새로운 경험을 설계할 수 있다. - 색상, 아이콘, 버튼의 형태뿐 아니라 명확한 언어와 접근성까지 관리하므로 UX 전반에 영향을 준다. 디자인 시스템을 도입할 때는 단순히 UI 컴포넌트 목록을 만드는 데 그치지 말고, 디자인 원칙·접근성·코드·문서·협업 프로세스까지 함께 정의하는 것이 좋다. 또한 처음부터 모든 요소를 완성하려 하기보다 반복적으로 사용되는 핵심 요소부터 구축하고, 제품과 팀의 변화에 맞춰 지속적으로 관리해야 한다.

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

원활한 피그마 마이

Figma 마이그레이션은 단순히 디자인 도구를 교체하는 일이 아니라, 협업 방식과 조직 문화를 바꾸는 변화 관리 과정이다. 성공하려면 계획 수립부터 커뮤니케이션, 라이브러리 재구축, 교육과 온보딩까지 여러 단계를 체계적으로 준비해야 한다. 특히 부서 간 대표로 구성된 옹호 팀과 조직 전체의 공감대가 핵심이다. ## 도구 교체가 아닌 변화 관리 - Figma 도입의 주요 목적은 협업 강화, 작업의 투명성 향상, 프로세스 간소화다. - 마이그레이션은 디자이너만의 과제가 아니라 개발자, 제품 관리자, 이해관계자 등 모든 구성원이 참여해야 한다. - 기존 업무 방식과 조직 문화를 새로운 협업 방식에 맞게 조정해야 한다. - 계획, 커뮤니케이션, 재구축, 온보딩, 문화적 규범 정착을 단계적으로 추진해야 한다. ## 부서 간 Figma 옹호 팀 구성 - 개발, 제품 관리, 디자인 시스템, 주요 이해관계자 등 다양한 부서의 구성원을 핵심 팀으로 참여시킨다. - 옹호 팀의 주요 역할은 다음과 같다. - 조직의 요구사항을 수집하고 균형 잡힌 피드백 제공 - 전체 조직에 적합한 Figma 워크스페이스 구성 - 마이그레이션 관련 공지와 커뮤니케이션 관리 - 기존 라이브러리와 컴포넌트 이전 감독 - Figma 사용 경험이 많거나 변화에 적극적인 사람을 중심으로 구성하는 것이 효과적이다. - Wells Fargo는 숙련자와 열성 사용자를 “Figma Jedis”로 조직했고, JPMorgan Chase는 디자인 시스템에 관심 있는 인재를 리더십과 여러 부서에서 추천받았다. - Uber는 기존 디자인 시스템 워크숍에 Figma 기초 교육과 데모를 결합해 점진적으로 도입했다. ## 부서별 지지와 리더십의 동의 확보 - 디자인 팀뿐 아니라 개발자, 제품 관리자, 경영진과 이해관계자의 동의를 초기부터 확보해야 한다. - 도입 제안서에는 기존 도구와 Figma의 장단점, 예상 효과, 비용과 운영상의 변화를 명확히 정리한다. - Dropbox는 다음과 같은 방식으로 조직의 참여를 이끌었다. - 워크숍 개최 - 모범 사례 공유 - 라이브러리와 컴포넌트의 조기 공개 - 팀별 실습과 교육 제공 - 구성원이 실제 결과를 미리 경험하도록 하면 도구 교체에 대한 저항을 줄일 수 있다. - Figma Migration Toolkit과 같은 자료를 활용해 다른 디자인 도구에서 이전할 때 필요한 지침을 표준화할 수 있다. ## 다른 조직의 경험 활용 - 비슷한 규모와 복잡성을 가진 조직의 마이그레이션 사례를 조사하면 시행착오를 줄일 수 있다. - 이미 Figma를 도입한 팀에 직접 문의해 다음 정보를 얻을 수 있다. - 교육 프로그램 구성 - 단계별 도입 플레이북 - 파일과 프로젝트를 정리하는 커버 페이지 방식 - 피해야 할 운영 방식 - 대규모 배포 시 발생한 문제와 해결책 - Wells Fargo의 사례처럼 외부 조직의 실전 경험을 참고하면 대규모 롤아웃 계획을 구체화하는 데 도움이 된다. - Workday, Uber, Dropbox 등의 사례와 마이그레이션 관련 라이브스트림도 참고 자료로 활용할 수 있다. ## 현실적인 마이그레이션 일정 수립 - 조직의 업무 일정과 기존 디자인 도구의 계약·사용 종료 시점을 함께 고려해 타임라인을 작성한다. - 한 번에 전체 조직을 전환하기보다 준비 상황과 팀별 업무 우선순위에 따라 단계적으로 진행하는 것이 안전하다. - 일정에는 교육, 라이브러리 이전, 파일 정리, 파일럿 운영, 피드백 수집, 전체 배포를 포함해야 한다. - 기존 프로젝트와 신규 프로젝트의 전환 기준을 사전에 정하면 팀 혼란을 줄일 수 있다. Figma 마이그레이션은 도구를 설치하는 프로젝트가 아니라 조직의 협업 체계를 재설계하는 프로젝트로 접근해야 한다. 먼저 부서 간 옹호 팀을 만들고, 리더십과 실무자의 지지를 확보한 뒤, 외부 사례와 단계별 일정을 바탕으로 파일럿부터 시작하는 방식을 추천한다.

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

Dev Mode에 대해 알아

Figma는 디자이너와 개발자가 하나의 파일과 협업 공간에서 더 효율적으로 제품을 만들 수 있도록 Dev Mode를 개발했고, 2024년 1월 베타를 종료했습니다. Dev Mode는 개발자에게 필요한 정보와 도구를 별도 워크스페이스로 제공하면서도 디자인 맥락과 협업은 유지하는 것이 핵심입니다. Figma는 사용자 피드백을 바탕으로 주석, 변경점 비교 등 핸드오프와 구현을 지원하는 기능을 강화했습니다. ## 개발자 중심의 작업 공간이 필요한 이유 - 개발자는 Figma 주간 활성 사용자의 약 3분의 1을 차지했습니다. - 하지만 기존 Figma는 디자인 작업에 최적화되어 있어 개발자의 워크플로, 도구 체계, 선호 사항을 충분히 지원하지 못했습니다. - Figma는 프런트엔드 개발자, 디자인 시스템 엔지니어, 콘텐츠 레이아웃 및 에셋을 다루는 개발자 등 다양한 역할을 고려해 개발자 전용 경험을 만들고자 했습니다. - 핵심 방향은 개발자가 디자인 모드의 모든 상호작용을 학습하지 않아도 되도록, 개발자에게 필요한 방식으로 Figma를 맞추는 것이었습니다. ## Visly 인수와 개발자 직관 확보 - Figma는 2021년 React UI 컴포넌트 개발 도구를 만들던 Visly 팀을 인수했습니다. - 8명의 디자이너와 엔지니어로 구성된 Visly 팀은 개발자 도구에 대한 실무 경험과 연구 결과를 보유하고 있었습니다. - Figma는 개발자와 대화하는 것만으로는 부족하며, 실제 개발 환경에 몰입해 얻는 ‘개발자 직관’이 필요하다고 판단했습니다. - Visly 팀은 개발자가 Figma를 사용하는 실제 방식과 다양한 개발 환경에 대한 관점을 제공했습니다. ## 디자인과 개발을 연결하는 통합 모드 - Dev Mode의 형태를 결정하는 과정에서 디자인 파일과 개발 파일을 완전히 분리할지, 하나로 통합할지 오랜 기간 검토했습니다. - 최종적으로 Dev Mode를 Figma 안의 별도 공간으로 구현했습니다. - 개발자는 개발에 최적화된 인터페이스를 사용하면서도 디자인 파일, 변경사항, 디자이너의 의도 같은 중요한 맥락을 그대로 확인할 수 있습니다. - 별도 도구나 파일로 전환하지 않고 디자인 공간과 개발 공간을 오갈 수 있다는 점이 핵심입니다. ## 오픈 베타와 사용자 피드백 - Dev Mode는 Config 2023에서 오픈 베타로 공개되었습니다. - 베타 기간 동안 고객 요청을 적극적으로 수집했고, 처음 두 달 동안 가장 많이 요청된 업데이트와 수정 사항 200개 이상을 배포했습니다. - 사용자 피드백은 Dev Mode의 기능 우선순위와 제품 결정에 직접 반영되었습니다. - 이후 Dev Mode는 베타를 종료하고 정식 제품 단계로 이동했습니다. ## 디자인 의도를 명확히 전달하는 주석 - 기존에는 디자이너가 개발자에게 필요한 치수와 설명을 수동으로 만들고 디자인을 별도로 정리해야 했습니다. - Dev Mode의 주석 기능은 디자인에 직접 연결된 설명, 사양, 측정값을 제공합니다. - 디자인이 변경되면 주석도 실시간으로 업데이트되어 최신 상태를 유지할 수 있습니다. - 캔버스를 복잡하게 만들지 않으면서 중요한 세부사항을 강조할 수 있습니다. - 플러그인을 이용해 주석을 자동화하거나 사용자 지정할 수 있습니다. - 클릭하고 드래그하는 방식으로 요소 간 거리를 측정할 수 있습니다. ## 개발 준비 상태와 변경점 비교 - 디자이너는 섹션을 “개발 준비 완료(ready for development)”로 표시하고 별도의 페이지나 파일 없이 개발자에게 전달할 수 있습니다. - 변경점 비교(diff) 기능을 사용하면 서로 다른 버전의 프레임을 비교할 수 있습니다. - 이를 통해 디자인 변경 사항을 확인하고, 개발자가 최신 디자인을 기준으로 작업하도록 지원합니다. - 목적은 디자인 핸드오프 과정에서 누락되는 설명이나 변경사항을 줄이고 구현 정확도를 높이는 것입니다. Dev Mode를 효과적으로 활용하려면 디자인과 개발을 별도 도구로 분리하기보다, 디자인 파일 안에서 주석·측정값·준비 상태·변경 이력을 일관되게 관리하는 것이 좋습니다. 특히 개발 전달 전에 “개발 준비 완료” 상태와 변경점을 명확히 표시하면 커뮤니케이션 비용을 줄일 수 있습니다.

원문 읽기(새 탭에서 열림)
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는 이러한 연계를 앞으로 타이포그래피까지 확장하려 하며, 글꼴 크기·행간·문자 간격 등도 더 유연하게 관리할 가능성을 제시한다. 실무에서는 먼저 색상과 간격처럼 반복 사용이 많은 값을 변수화한 뒤, 라이트·다크 모드나 모바일·데스크톱 모드를 구성하는 것이 좋다. 이후 효과, 투명도, 그리드, 컴포넌트 상태로 범위를 넓히면 디자인 시스템의 일관성과 반응형 설계 효율을 함께 높일 수 있다.

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