component-properties

4 개의 포스트

figma

Figma Buzz로 브랜드 모멘텀 (새 탭에서 열림)

Figma Buzz는 브랜드·마케팅 팀이 디자인 시스템을 지키면서도 대규모로 마케팅 자산을 제작하도록 돕는 도구다. 이번 업데이트에서는 디자인 시스템 기반의 유연한 템플릿, 외부 업무 도구를 연결하는 플러그인, 영상 트리밍 기능을 추가했다. 이를 통해 디자이너는 브랜드 가이드라인을 통제하고, 마케터는 다양한 채널과 캠페인에 맞게 자산을 직접 수정할 수 있다. ## 디자인 시스템과 연결된 구성 가능한 템플릿 - Figma Design에서 컴포넌트 세트와 컴포넌트 속성을 사용해 만든 템플릿을 Figma Buzz로 복사할 수 있다. - 복사된 템플릿에서는 디자인 시스템의 속성이 자동으로 작동한다. - 마케터는 수백 개의 템플릿 변형을 일일이 찾지 않고, 하나의 템플릿 세트 안에서 필요한 옵션을 선택할 수 있다. - 템플릿의 **Change layout** 패널에서 다음과 같은 작업이 가능하다. - Instagram, LinkedIn 등 채널에 맞는 레이아웃 선택 - 드롭다운을 통한 레이아웃 변형 전환 - 날짜, 로고, CTA 등의 요소 표시 여부 토글 - 브랜드가 승인한 컴포넌트 인스턴스 교체 - 색상 조합, 일러스트레이션 등 허용된 디자인 요소 변경 - 디자이너는 편집 가능한 범위에 제약을 둘 수 있고, 마케터는 브랜드 규칙을 벗어나지 않으면서 다양한 결과물을 만들 수 있다. ## 플러그인을 통한 외부 도구 연동 - Figma Buzz에 플러그인 탭이 추가되어, 기존 Figma 생태계의 외부 도구를 작업 화면에서 직접 사용할 수 있다. - 초기 플러그인은 디지털 자산 관리, 번역 관리, 애니메이션 등의 마케팅 업무에 초점을 맞춘다. - 팀은 Figma Buzz를 떠나지 않고 승인된 자산을 불러오거나, 완성한 디자인을 외부 시스템에 업로드할 수 있다. - 조직의 필요에 따라 내부용 플러그인을 직접 만들고 게시할 수도 있다. ### 디지털 자산 관리 시스템 연동 - 대규모 이미지·디자인 자산을 관리하는 DAM과 연결해 브랜드 승인 이미지를 바로 검색하고 가져올 수 있다. - 최신 디자인을 DAM에 업로드해 자산 라이브러리와 동기화할 수 있다. - 소개된 DAM 플러그인은 다음과 같다. - Air - Brandfolder - Bynder - OrangeLogic ### 번역 관리 시스템 연동 - 번역 관리 시스템(TMS)의 번역문을 Figma Buzz 템플릿으로 직접 가져올 수 있다. - 캠페인 문구를 여러 언어로 현지화하고, 실제 디자인 맥락 안에서 번역 결과를 확인할 수 있다. - 마케팅·번역·디자인 팀 간의 협업과 글로벌 캠페인 확장에 필요한 컨텍스트 전환을 줄인다. ### 애니메이션 및 기타 플러그인 - 애니메이션 제작 등 디지털 콘텐츠 업무를 지원하는 플러그인도 제공된다. - 마케팅 팀은 자산 관리, 번역, 모션 작업에 사용하는 기존 도구를 Figma Buzz와 연결해 하나의 제작 흐름으로 통합할 수 있다. ## Figma Buzz 안에서 영상 트리밍 - Figma Buzz에서 영상의 필요한 구간만 직접 잘라 사용할 수 있다. - 별도의 영상 편집 도구를 거치지 않고, 마케팅 자산 안에서 영상이 재생되는 범위를 조정할 수 있다. - 소셜 미디어 게시물, 디지털 광고, 이벤트 홍보물처럼 영상 길이와 시작·종료 지점이 중요한 자산을 더 세밀하게 제어할 수 있다. ## 업데이트의 배경과 목표 - Figma Buzz는 제품 출시 이후 브랜드와 마케팅 팀이 소셜 게시물, 디지털 광고, 이벤트 홍보물 등을 대규모로 제작하도록 설계됐다. - 기존에도 영상 가져오기·내보내기, 팀 라이브러리 연결, Unsplash 이미지 추가 기능이 제공됐다. - 이번 업데이트는 단순한 템플릿 제작을 넘어 다음 세 가지를 강화한다. - 브랜드 일관성을 유지하는 편집 제어 - 마케팅 업무에 필요한 외부 시스템 연동 - 이미지뿐 아니라 영상까지 포함한 자산 제작 유연성 브랜드 디자이너는 디자인 시스템과 승인된 옵션을 중심으로 템플릿을 설계하고, 마케팅 팀은 이를 활용해 채널별 자산을 빠르게 제작하는 방식으로 Figma Buzz를 활용하는 것이 효과적이다. 특히 DAM·TMS를 이미 사용 중인 조직이라면 플러그인 연동을 통해 자산 검색과 번역 작업의 반복을 크게 줄일 수 있다.

figma

두 매개변수 구조 (새 탭에서 열림)

Figma는 변수(variables)와 컴포넌트 속성(component properties)을 서로 다른 구조로 구축했지만, 두 시스템이 같은 레이어 속성에 동시에 연결될 수 있어 렌더링 불일치와 학습·유지보수의 어려움이 발생했습니다. 이를 해결하기 위해 두 기능을 하나의 파라미터 아키텍처로 통합했고, 그 결과 사용자 경험의 일관성, 개발 속도, 향후 제품 확장성을 개선했습니다. ## 파라미터 시스템의 역할 - Figma의 반응형 디자인, 타이포그래피, 애니메이션, 상태 머신 등은 값을 한 곳에서 설정하고 여러 요소에 전파하는 파라미터 개념을 기반으로 합니다. - 값이 변경되면 해당 값을 참조하는 레이어의 속성이 즉시 갱신됩니다. - 변수와 컴포넌트 속성은 모두 “한 번 설정하고 여러 곳에 적용하는” 기능이지만, 서로 다른 문제를 해결하기 위해 별도로 발전했습니다. ## 컴포넌트 속성: 범위가 제한된 파라미터 - 컴포넌트 속성은 2022년에 출시됐으며, 디자인과 코드 사이의 간극을 줄이기 위한 목적이었습니다. - 특정 컴포넌트 내부 레이어에만 적용되는 **범위 제한형 파라미터(scoped parametrization)** 를 제공합니다. - 디자인 시스템 작성자는 버튼 등의 컴포넌트에 Boolean, 텍스트, 인스턴스 교체 등의 속성을 정의할 수 있습니다. - 사용자는 컴포넌트 내부 구조를 직접 훼손하지 않고, 공개된 속성만 수정할 수 있습니다. - 코드에서 컴포넌트의 props를 사용하는 방식과 유사해 디자이너와 개발자가 동일한 mental model을 공유할 수 있게 됐습니다. - 이 구조는 Figma Sites, Figma Make, Code Connect처럼 디자인을 실제 웹·코드 결과물로 연결하는 기능의 기반이 됐습니다. ## 변수: 전역적이고 문맥을 지원하는 파라미터 - 변수는 컴포넌트 내부에 국한되지 않고 프로젝트 전반에서 사용할 수 있는 더 넓은 범위의 파라미터입니다. - 색상, 크기 등 다양한 타입을 지원하며 디자인 토큰을 표현하는 데 적합합니다. - 라이트 모드와 다크 모드처럼 하나의 변수에 여러 문맥별 값을 정의할 수 있습니다. - 예를 들어 배경색 변수 하나에 기본, 보조, 강조 값과 각 모드의 실제 색상을 연결할 수 있습니다. - 이러한 특성 덕분에 디자인 시스템의 토큰을 중앙에서 관리하고 여러 화면에 일관되게 적용할 수 있습니다. ## 두 아키텍처를 분리했을 때의 문제 - 변수와 컴포넌트 속성이 서로 다른 내부 구조를 사용하면서 기능 간 동작이 일관되지 않았습니다. - 하나의 레이어 속성에 변수와 컴포넌트 속성이 동시에 연결되는 상황이 발생할 수 있었습니다. - 이 경우 편집기에서 어떤 값이 우선하는지 예측하기 어렵고 렌더링 결과가 일치하지 않을 수 있었습니다. - 사용자 입장에서는 비슷한 기능을 서로 다른 방식으로 배워야 했습니다. - 개발팀 역시 기능을 추가할 때 두 아키텍처를 각각 수정하고 호환성을 검토해야 했습니다. - 다른 Figma 제품에 파라미터 기능을 확장하려 해도 기존의 기술적 복잡성을 함께 가져가야 했습니다. ## 단일 파라미터 아키텍처로의 통합 - Figma는 변수와 컴포넌트 속성을 공통된 내부 파라미터 모델 위에서 동작하도록 통합했습니다. - 두 기능의 사용자-facing 개념은 유지하면서도, 값의 정의·바인딩·전파를 처리하는 기반 구조를 공유하게 했습니다. - 동일한 레이어 속성에 여러 파라미터가 연결되는 경우도 일관된 규칙으로 처리할 수 있게 됐습니다. - 공통 아키텍처를 통해 편집기 내 예상치 못한 동작과 렌더링 불일치를 줄였습니다. - 새로운 파라미터 기능이나 제품을 개발할 때 기존 시스템을 각각 구현할 필요가 없어져 개발 속도도 향상됐습니다. ## 통합이 가져온 확장성 - 컴포넌트의 구조적 제어와 변수의 전역적·문맥적 제어를 하나의 기반에서 조합할 수 있습니다. - 디자인 토큰, 컴포넌트 속성, 코드 생성 기능을 더 일관된 방식으로 연결할 수 있습니다. - 향후 Figma의 다른 제품에서도 동일한 파라미터 개념과 동작 규칙을 재사용할 수 있습니다. - 이번 작업은 단순한 내부 리팩터링이 아니라, 디자인 도구 전반에서 파라미터화를 확장하기 위한 기반을 마련한 사례입니다. 실무적으로는 컴포넌트의 외부에 노출할 사용자 조정 항목에는 컴포넌트 속성을, 여러 화면과 모드에서 공유할 디자인 토큰에는 변수를 사용하는 것이 적절합니다. 두 기능이 통합된 아키텍처 위에서 동작하더라도 각 기능의 범위와 목적은 여전히 다르므로, 재사용 범위에 따라 선택하는 것이 좋습니다.

figma

프롭스의 공유 언어 | (새 탭에서 열림)

컴포넌트와 props는 디자인과 코드 양쪽에서 사용되지만, 환경에 따라 의미와 목적이 달라질 수 있다. 같은 이름의 컴포넌트라도 디자이너는 시각적 일관성과 표현 방식을, 개발자는 렌더링·상호작용·데이터 처리를 중심으로 생각한다. 따라서 디자인과 개발의 협업을 개선하려면 용어를 단순히 통일하기보다 각 환경의 맥락과 차이를 함께 이해해야 한다. ## 디자인과 개발에서 달라지는 언어 - 컴포넌트는 재사용 가능한 요소이며, props는 컴포넌트가 표현될 수 있는 방식과 규칙을 정의한다. - 컴포넌트의 인스턴스는 원본 컴포넌트를 실제로 사용한 결과이며, props 값을 변경해 다양한 상태와 모양을 표현한다. - 디자인과 개발 모두 `boolean` 같은 개념을 사용하지만, 디자이너는 이를 주로 시각적 차이를 표현하는 수단으로 접한다. - Figma의 대표적인 prop 유형은 다음과 같다. - Variant: 컴포넌트의 변형 - Boolean: 표시 여부나 켜짐/꺼짐 상태 - Instance swap: 내부 인스턴스 교체 - Text: 텍스트 값 변경 - 개발자는 이러한 시각적 props 외에도 이벤트 핸들러, 데이터, 동작 제어 등 비시각적 속성을 함께 다룬다. - 같은 단어를 사용하더라도 서로 다른 의미를 떠올릴 수 있으므로, 용어의 일치만으로 공통 이해가 형성되지는 않는다. ## 버튼 사례에서 드러나는 차이 - Figma의 버튼은 시각적 일관성과 디자인 파일 안에서의 구현 방식이 중요하다. - 코드의 버튼은 시각적 표현뿐 아니라 렌더링 방식, 사용자 상호작용, 접근성, 이벤트 처리까지 포함한다. - 따라서 Figma의 `Button`과 코드베이스의 `Button`은 이름과 기본 개념은 같아도 실제 책임과 props 구성이 다를 수 있다. - 글의 사례에서는 Figma에 `Button`과 `IconButton` 두 컴포넌트가 있었지만, 코드베이스에는 버튼 관련 컴포넌트가 다섯 개 존재했다. - Figma의 두 컴포넌트는 코드베이스처럼 공통 primitive를 상속하지 않았다. - Figma에서는 코드와 같은 방식의 컴포넌트 상속이 존재하지 않는다. - 디자인 관점에서 모델링하기에 두 컴포넌트를 분리하는 편이 더 적절했다. - 크기와 색상 같은 props가 중복되었지만, 동기화가 어렵지 않고 일관성을 해치지 않아 허용할 수 있었다. - 반면 코드베이스의 버튼 컴포넌트는 더 많은 props와 기능을 제공했으며, Figma 컴포넌트에는 그중 일부만 반영되어 있었다. - 이는 디자이너와 개발자가 컴포넌트를 최적화하는 기준이 다르다는 점을 보여준다. - 디자이너: 시각적 표현, 디자인 시스템 내 일관성, 파일에서의 사용성 - 개발자: 구현 편의성, 재사용 구조, 상호작용, 데이터와 접근성 ## 공통 어휘를 만들 때 필요한 관점 - 디자인과 코드의 컴포넌트를 무조건 동일한 구조로 맞추기보다, 각각의 환경에서 컴포넌트가 수행하는 역할을 먼저 구분해야 한다. - 같은 이름을 사용하는 컴포넌트라도 실제 목적과 지원하는 props가 다르면 그 차이를 명시적으로 설명해야 한다. - 협업에서는 “이 prop이 존재하는가”보다 다음 질문이 중요하다. - 어떤 시각적 또는 기능적 문제를 해결하는가? - 디자인에서의 변화가 코드에서는 어떤 prop이나 상태에 대응하는가? - 코드의 비시각적 기능을 디자인 시스템에서는 어떻게 표현하거나 문서화할 것인가? - 서로 다른 용어를 사용하는 사실 자체는 문제가 아니다. 문제는 동일한 의미라고 가정한 채 대화하는 것이다. 디자인 시스템을 운영할 때는 Figma와 코드 컴포넌트의 이름을 가능한 한 연결하되, props 목록과 의미가 완전히 같다고 가정하지 않는 것이 좋다. 각 prop의 목적과 대응 관계를 문서화하고, 시각적 속성과 동작·데이터 속성을 구분하면 디자이너와 개발자 사이의 오해를 줄일 수 있다.

figma

Figma의 새로운 소식 (새 탭에서 열림)

2022년 9월 Figma 업데이트는 디자인 시스템 구축과 협업 효율 향상에 초점을 맞췄다. 컴포넌트 프로퍼티 기능을 확장해 인스턴스 커스터마이징과 관리성을 높였고, Google Calendar 연동·신규 템플릿·Schema 컨퍼런스를 통해 Figma와 FigJam을 업무 흐름 전반으로 확장했다. 특히 컴포넌트 관련 기능은 오픈 베타로 제공되어 팀별 디자인 시스템을 더 유연하게 운영할 수 있게 했다. ## 컴포넌트 프로퍼티 기능 확장 이번 업데이트의 핵심은 컴포넌트 인스턴스를 더 쉽게 교체하고, 필요한 부분만 노출하며, 중첩 컴포넌트까지 세밀하게 조정할 수 있도록 한 것이다. - **Preferred values** - 인스턴스를 교체할 때 선택 가능한 컴포넌트 목록을 미리 지정할 수 있다. - 사용자가 무분별한 컴포넌트 대신, 디자인 시스템에서 권장하는 값만 선택하도록 유도한다. - 인스턴스 교체 과정의 혼란을 줄이고 일관성을 높인다. - **Exposed nested instances** - 부모 컴포넌트에서 내부에 중첩된 인스턴스의 프로퍼티를 직접 노출할 수 있다. - 사용자는 내부 레이어를 일일이 찾아가지 않고 부모 컴포넌트 수준에서 중첩 요소를 수정할 수 있다. - 복잡한 카드, 내비게이션, 버튼 그룹 등 재사용 컴포넌트의 커스터마이징에 유용하다. - **Simplified instances** - 컴포넌트 작성자가 이후 인스턴스의 레이어 및 상세 보기에서 불필요한 요소를 숨길 수 있다. - 사용자는 실제로 편집해야 하는 프로퍼티에 집중할 수 있다. - 디자인 시스템이 복잡해져도 인스턴스 사용 경험을 단순하게 유지할 수 있다. ## Figma·FigJam과 Google Calendar 연동 Figma는 회의 일정과 관련 파일을 연결하는 Chrome 확장 기능을 제공했다. - Google Calendar 이벤트에 Figma 또는 FigJam 파일을 직접 추가할 수 있다. - 캘린더 화면을 벗어나 파일 링크를 복사할 필요가 없다. - 회의 아젠다, 협업 보드, 디자인 리뷰 파일 등을 일정과 함께 관리할 수 있어 회의 준비와 후속 작업이 편리해진다. - 해당 기능은 Google Chrome 확장 프로그램으로 설치할 수 있다. ## 디자인 시스템 컨퍼런스 Schema Figma는 디자인 시스템에 초점을 맞춘 행사인 Schema의 참가 등록을 시작했다. - 2021년 가상 행사로 시작했으며, 2022년에는 온라인 프로그램과 함께 오프라인 세션도 진행했다. - 뉴욕, 도쿄, 런던에서 현장 행사를 열고 온라인 참여도 지원했다. - 디자인 시스템 리더들의 사례와 인사이트를 공유하고, 참가자 간 커뮤니티 교류를 목적으로 한다. - 컴포넌트, 운영 방식, 조직 내 디자인 시스템 최적화에 관심 있는 팀을 위한 행사다. ## 300개 이상의 신규 템플릿 Figma와 FigJam에 다양한 업무를 바로 시작할 수 있도록 수백 개의 템플릿이 추가됐다. - 로드맵 기획, SWOT 분석, 팀 회의 아젠다, 디자인 크리틱 등 여러 업무를 지원한다. - 사용 사례나 직무별로 템플릿을 탐색할 수 있다. - 주요 예시로 다음 템플릿이 소개됐다. - **브랜드 가이드라인**: 브랜드 스토리부터 소셜 게시물까지 브랜드의 기준을 정리 - **제품 개발 로드맵**: 아이디어를 실행 단계까지 연결 - **팀 회의 아젠다**: 회의 주제와 진행 내용을 구조화 실무에서는 먼저 팀에서 자주 사용하는 컴포넌트에 Preferred values와 Simplified instances를 적용하고, 회의별 Figma·FigJam 파일을 Google Calendar에 연결하는 방식으로 이번 업데이트를 활용할 수 있다. 신규 템플릿은 반복적인 기획·회의 업무의 출발점으로 사용하면 좋다.