Figma

532 개의 포스트

figma3분 읽기큐레이션 요약

The Long and Short of

Figma의 뉴스레터 「Find your framework」는 디자인 시스템 구축과 확산에 도움이 되는 Framework 행사 발표와 관련 콘텐츠를 소개한다. 핵심 메시지는 디자인 시스템이 단순한 UI 산출물이 아니라, 조직 전체가 사용해야 가치를 발휘하는 제품이라는 점이다. 이를 위해 기능 개발뿐 아니라 내부 마케팅, 교육, 데이터 기반 adoption 전략이 필요하다. ## Framework 행사에서 발표한 기능 - Figma의 가상 디자인 시스템 행사인 **Framework**에서 제품 개발자와 디자인 시스템 담당자를 위한 기능을 공개했다. - 주요 발표 내용: - **Code Connect**: 디자인 시스템의 컴포넌트와 실제 코드 구현을 연결해 디자이너와 개발자 간 협업을 지원한다. - **Typography variables**: 글꼴, 크기, 행간 등 타이포그래피 속성을 변수로 관리할 수 있다. - **Gradient variables**: 그라디언트 관련 값을 변수화해 일관된 스타일 관리와 변경을 돕는다. - **Library Analytics API**: 조직 내 라이브러리 사용 현황을 분석해 디자인 시스템 adoption을 높이는 데 활용할 수 있다. - 행사에서 진행된 라운드테이블과 전문가 Q&A를 통해 디자인 시스템 운영 사례와 실무 관점도 공유했다. ## 디자인 시스템을 제품처럼 운영하기 - 디자인 시스템을 조직의 필수 도구로 만들려면 단순히 좋은 컴포넌트를 만드는 것만으로는 부족하다. - 제품처럼 다음 요소를 관리해야 한다. - 사용자의 요구와 문제 파악 - 명확한 가치 제안 - 지속적인 개선과 업데이트 - 사용 현황과 피드백 수집 - 사용자에게 변화와 이점을 알리는 커뮤니케이션 - 디자인 시스템의 성공은 완성도보다 **얼마나 많은 팀이 실제 업무에서 사용하는가**에 달려 있다. ## 내부 마케팅과 사용 확산 - 디자인 시스템은 일관성, 효율성, 확장성을 약속하지만, 실제 효과는 조직 전체의 사용이 전제되어야 나타난다. - 담당자는 “사용하라”고 지시하기보다 각 팀이 얻는 구체적인 이점을 설득해야 한다. - 디자인·개발 작업 시간 단축 - 중복 작업 감소 - 제품 간 시각적 일관성 향상 - 변경 사항을 여러 화면과 플랫폼에 빠르게 반영 - 내부 구성원을 대상으로 명확한 adoption 전략을 세우고, 교육·문서화·사례 공유를 통해 지속적인 참여를 유도해야 한다. ## 디자인 시스템 입문 - 아직 디자인 시스템을 시작하지 않은 팀을 위해 기본 개념과 구축 방법을 소개하는 입문 시리즈를 제공한다. - 디자인 시스템은 재사용 가능한 컴포넌트, 스타일, 규칙, 가이드라인을 모아 제품 제작 방식을 표준화하는 체계다. - 이를 활용하면: - 반복적인 디자인 결정을 줄일 수 있다. - 팀 간 협업 방식이 통일된다. - 제품이 성장해도 일관된 경험을 유지하기 쉽다. - 디자인과 개발 사이의 구현 차이를 줄일 수 있다. ## 성장과 확장을 지원한 Carvana 사례 - 온라인 중고차 거래 기업 **Carvana**는 급격한 고객 수요 증가와 사업 확장에 대응하기 위해 디자인 시스템을 활용했다. - 디자인 시스템과 변수를 사용해 제품 전반의 디자인 세부 사항을 일관되게 유지했다. - 특히 변수는 색상이나 기타 디자인 속성을 중앙에서 관리하고 변경할 수 있게 해, 여러 화면과 제품 영역에 일관된 수정 사항을 적용하는 데 도움을 줬다. - 이는 디자인 시스템이 시각적 통일성뿐 아니라 빠른 성장과 운영 효율성을 뒷받침하는 기반이 될 수 있음을 보여준다. 디자인 시스템을 도입할 때는 컴포넌트 제작에만 집중하기보다, 실제 사용자를 위한 제품으로 정의하는 것이 좋다. 명확한 사용 가치와 교육·홍보 전략을 마련하고, 사용 데이터를 분석하며 지속적으로 개선해야 조직 전체에서 정착시킬 수 있다.

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

Framework 2024

Figma는 디자인 시스템 구축보다 더 어려운 과제인 조직 전체의 도입과 활용을 지원하기 위해 Framework 2024에서 세 가지 기능을 공개했다. Code Connect는 디자인과 실제 코드 사이의 간극을 줄이고, 타이포그래피·그라디언트 변수는 디자인 토큰의 범위를 확장하며, Library Analytics API는 디자인 시스템 사용 현황을 측정하도록 돕는다. 결론적으로 Figma는 디자인 시스템을 만드는 도구를 넘어, 개발자 adoption과 조직 내 확산까지 지원하는 방향으로 발전하고 있다. ### 디자인 시스템의 핵심 과제: 조직 전체의 도입 - 디자인 시스템은 일관성, 효율성, 확장성을 제공하지만 실제 효과는 팀 전체가 이를 사용할 때 발생한다. - 시스템이 강력하고 정교해질수록 복잡성도 커지며, 디자이너와 개발자의 적극적인 참여를 이끌어내는 일이 어려워진다. - Figma는 변수, 테마와 상태 관리, 고급 프로토타이핑, Dev Mode 등을 통해 디자인과 코드의 연결을 강화해 왔다. - 이번 발표의 중심 목표는 디자인 시스템을 “구축”하는 데서 나아가 조직 전반에서 “채택”되도록 만드는 것이다. ### Code Connect: 디자인과 코드의 연결 - Code Connect는 Dev Mode에서 디자인 시스템 컴포넌트에 대응하는 실제 코드 스니펫을 제공한다. - 개발자는 별도의 문서나 저장소를 검색하지 않고 Figma에서 필요한 코드를 확인하고 복사할 수 있다. - 이를 통해: - 구현 시간을 줄일 수 있다. - 디자인과 코드의 불일치를 완화할 수 있다. - 개발자가 디자인 시스템 컴포넌트를 사용하는 진입 장벽을 낮출 수 있다. - 임의로 유사한 컴포넌트를 새로 만드는 일을 줄일 수 있다. - Organization 및 Enterprise 요금제에서 베타로 제공되며, React·iOS·Storybook을 지원한다. - 향후 더 많은 프레임워크와 플랫폼으로 지원 범위가 확대될 예정이다. - Bumble, GitHub, HP 등의 팀은 디자인 시스템과 실제 프로덕션 코드 사이를 연결하는 문제와 Code Connect의 활용 가능성을 논의했다. ### 타이포그래피 변수: 디자인 토큰의 확장 - 기존 변수 기능만으로는 디자인 시스템의 중요한 영역인 타이포그래피를 충분히 표현하기 어려웠다. - 타이포그래피 변수를 사용하면 글꼴 크기, 행간, 글꼴 스타일 등 타이포그래피 속성을 변수와 토큰 체계 안에서 관리할 수 있다. - 주요 활용 방식: - 폰트 스케일을 한 번 정의하고 전체 시스템에 일관되게 적용 - 플랫폼별 타이포그래피 설정 조정 - 반응형 또는 테마별 텍스트 스타일 관리 - WCAG 기준을 고려한 접근성 높은 스케일 구성 - 디자인 시스템의 색상과 간격뿐 아니라 텍스트 표현까지 체계적으로 관리할 수 있게 된다. ### 그라디언트 변수: 더 풍부한 시각 스타일 관리 - 그라디언트도 변수로 정의하고 재사용할 수 있도록 지원한다. - 여러 화면과 컴포넌트에서 동일한 그라디언트 스타일을 일관되게 적용할 수 있다. - 브랜드 테마나 모드별로 그라디언트를 교체하기 쉬워진다. - 변수 기반 관리로 디자인 시스템이 단순한 색상 팔레트를 넘어 더 표현력 있는 시각 언어를 다룰 수 있다. ### Library Analytics API: 디자인 시스템 사용 현황 측정 - Library Analytics API는 조직 내 디자인 시스템 라이브러리와 컴포넌트의 사용 데이터를 분석할 수 있도록 제공된다. - 디자인 시스템 관리자는 다음과 같은 질문에 답할 수 있다. - 어떤 라이브러리와 컴포넌트가 실제로 사용되는가? - 어느 팀이나 프로젝트가 디자인 시스템을 적극적으로 채택하는가? - 사용되지 않거나 개선이 필요한 컴포넌트는 무엇인가? - 정량적인 사용 데이터를 바탕으로 문서화, 교육, 컴포넌트 개선, 도입 전략을 세울 수 있다. - 디자인 시스템의 성공을 단순히 “만들었는가”가 아니라 “얼마나 사용되는가”로 평가할 수 있게 한다. ### 실용적인 결론 디자인 시스템 팀은 컴포넌트와 토큰을 만드는 데 그치지 말고, 개발자가 실제 코드로 쉽게 사용할 수 있는 경로와 사용 현황을 측정할 방법까지 함께 마련해야 한다. Code Connect로 개발자 경험을 개선하고, 타이포그래피·그라디언트 변수로 토큰 범위를 확장하며, Analytics API로 채택률을 추적하는 접근이 효과적이다.

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

디자인 시스템을 위한 올바

Code Connect는 Figma의 Dev Mode에서 자동 생성된 CSS 대신 조직의 실제 디자인 시스템 코드를 보여줘 디자인 시스템 도입률을 높이는 도구다. 개발자는 목업과 연결된 컴포넌트의 올바른 코드와 사용 지침을 바로 확인할 수 있어 구현 속도와 일관성이 향상된다. 결과적으로 잘못된 컴포넌트 사용과 중복된 일회성 컴포넌트의 생성·유지보수를 줄이는 것이 목표다. ## 디자인 시스템 도입이 어려운 이유 - 디자인 시스템을 구축해도 개발자가 시스템의 모든 컴포넌트와 패턴을 알지 못하는 경우가 많다. - 일부 컴포넌트를 사용하더라도 의도된 가이드라인과 다르게 적용할 수 있다. - 디자인 시스템의 성공은 단순히 사용 여부가 아니라, 올바르고 일관되게 사용하는지에 달려 있다. - 디자인과 코드는 서로 다른 도구와 제약을 가진 별개의 작업 영역으로 발전해 왔기 때문에 연결 지점이 부족했다. ## 디자인과 코드의 연결 - 디자인은 무엇을 만들지 탐색하고 결정하는 데 초점을 두며, 코드는 이를 구조적이고 유지보수 가능한 형태로 구현하는 데 초점을 둔다. - Figma는 두 영역이 원활하게 오갈 수 있어야 한다고 보고, Code Connect를 그 연결을 강화하는 기능으로 소개한다. - 기존의 Auto Layout, Variables, Component Props, Dev Mode 등의 기능과 함께 디자인 시스템을 코드에 더 가깝게 통합하려는 흐름에 속한다. - 디자인 시스템 팀이 작성한 실제 구현 방식과 문서를 디자인 목업의 맥락 안에서 제공한다. ## Code Connect의 핵심 기능 - Dev Mode에 표시되는 코드 스니펫을 조직의 실제 디자인 시스템 코드로 사용자 지정할 수 있다. - 자동 생성 CSS가 아니라 프로젝트에서 사용하는 컴포넌트, 속성, 패턴에 맞는 코드를 개발자에게 보여준다. - 개발자가 목업에서 특정 요소를 선택하면 관련 코드와 사용법을 별도의 문서 검색 없이 확인할 수 있도록 한다. - 올바른 구현 예시와 디자인 시스템 사용 원칙을 함께 제공해 오용을 줄인다. - 디자인 시스템의 재사용을 촉진해 중복 컴포넌트와 일회성 구현의 생성을 줄인다. ## 개발자 워크플로에 맞춘 설치 방식 - Code Connect는 개발자가 익숙한 패키지 및 명령줄 기반 방식으로 설치·설정할 수 있다. - JavaScript와 TypeScript 프로젝트에서는 **npm**을 사용한다. - SwiftUI 프로젝트에서는 **Swift Package Manager**를 지원한다. - 설치 패키지와 설정 방법은 GitHub 저장소에서 제공된다. - 향후 더 많은 플랫폼을 지원해 기존 개발 환경에 자연스럽게 통합하는 것을 목표로 한다. ## 기대 효과 - 개발자가 디자인 시스템 컴포넌트를 더 쉽게 발견하고 사용할 수 있다. - 디자인에서 코드로 전환하는 과정이 빨라지고 구현 효율이 높아진다. - 실제 코드와 디자인 간의 차이를 줄여 제품 전반의 UI 일관성을 높인다. - 디자인 시스템 팀의 문서화와 모범 사례를 개발 작업의 적절한 시점에 전달할 수 있다. - 결과적으로 조직 전체의 디자인 시스템 채택률과 유지보수성을 개선한다. Code Connect를 도입할 때는 자주 사용하는 컴포넌트부터 실제 프로덕션 코드와 연결하고, 각 컴포넌트의 올바른 사용 예시와 속성 매핑을 함께 관리하는 것이 효과적이다. Primitives나 자동 생성 코드보다 조직의 표준 컴포넌트가 우선 노출되도록 구성해야 도입 효과를 극대화할 수 있다.

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

알래스카 항공, 변

Alaska Airlines는 Figma의 디자인 시스템과 Variables를 활용해 웹·모바일·디지털 사이니지·키오스크 전반의 경험을 일관되게 관리하고 있다. 45명 규모의 디자인 팀은 이를 통해 디자이너당 주당 평균 11시간을 절약했으며, 개발팀과의 협업과 접근성·구현 정확성도 개선했다. 특히 Auro 디자인 시스템의 재사용 컴포넌트는 긴급한 서비스 개편을 한 스프린트 안에 완료하도록 도왔다. ## 기존 도구와 단일 기준 부재의 문제 - Sketch와 InVision을 사용하던 시기의 디자인 시스템은 여러 도구가 뒤섞인 “프랑켄슈타인” 같은 상태였다. - 재사용 위젯이 직관적이지 않았고, 프로토타이핑과 실시간 협업 기능도 부족했다. - 디자인과 개발을 연결하는 단일 진실 공급원(Single Source of Truth)이 없어 다음 문제가 발생했다. - 컴포넌트와 패턴의 간격·색상 등이 몇 픽셀씩 어긋남 - 플랫폼별로 변경 사항을 수동 복사·붙여넣기 - 버튼, 체크박스, 모달, 색상, 날짜 선택기 등의 불일치 - 접근성 기준을 놓칠 가능성 증가 - 최신 파일이나 올바른 버전을 찾기 어려움 - 결과적으로 개발자는 실제 웹사이트와 맞지 않는 디자인을 전달받는 경우가 많았다. ## Auro 디자인 시스템과 Figma 도입 - Alaska Airlines는 Figma를 도입하며 디자이너와 엔지니어 모두를 위한 디자인 시스템 문서를 구축했다. - Auro는 웹 컴포넌트와 대응되는 디자인 컴포넌트를 제공해 설계와 구현 사이의 차이를 줄였다. - 컴포넌트, 색상, 패턴 등을 공통으로 참조할 수 있어 여러 인터페이스에서 일관된 사용자 경험을 유지할 수 있게 됐다. - 디자인 시스템 운영 과정에서 Auto Layout, 브랜치 및 병합 기능 등의 사용법도 문서화해 팀 내 채택률을 높였다. - 교육을 강화한 결과 디자이너의 Figma 활용도가 높아졌고, 디자이너와 엔지니어 간 충돌도 줄었다. ## 재사용 컴포넌트로 긴급 대응 속도 향상 - 심각한 폭풍으로 항공편 지연이 급증했을 때, 기존에 충분히 활용되지 않던 항공편 상태 페이지를 빠르게 개편했다. - 디자인·개발 타이거 팀은 개편에 필요한 컴포넌트의 90%를 Figma의 Auro 디자인 시스템에서 재사용했다. - Figma가 없었다면 최소 4~5개 스프린트가 필요했을 작업을 단 한 스프린트에 완료했다. - 개편 후 항공편 상태 페이지의 평균 체류 시간은 다음과 같이 증가했다. - 기존: 36초 - 변경 후: 5분 10초 - 증가율: 761% - 새 페이지에는 항공편 추적 정보와 항공기 세부 정보 등 고객에게 필요한 정보가 추가됐다. ## 디자인과 개발 간 신뢰 강화 - Figma는 처음에는 디자이너 간 협업 도구로 도입됐지만, 점차 엔지니어가 Auro의 설계 원칙을 이해하는 수단으로도 활용됐다. - 엔지니어가 실제로 사용하는 웹 컴포넌트와 유사한 디자인 컴포넌트를 참조할 수 있어 구현 가능성을 더 쉽게 판단하게 됐다. - 디자인이 구현 결과와 가까워지면서 팀 간 신뢰가 높아졌다. - 디자인 시스템 문서와 기능 교육은 디자이너가 Figma의 기능을 제대로 활용하도록 돕고, 협업 과정의 불필요한 충돌을 줄였다. ## Variables를 통한 다중 환경 대응 - Figma Variables를 활용해 23,000명 이상의 직원과 다양한 조직·파트너의 요구에 맞춰 디자인을 조정할 수 있게 됐다. - 다음과 같은 조건을 체계적으로 관리할 수 있다. - 다양한 화면 크기 - 라이트 모드와 다크 모드 - 팀별 테마 - 외부 파트너를 위한 테마 - 여러 환경에 맞는 디자인을 개별적으로 수정하는 대신, 변수 기반으로 체계화해 반복 작업을 줄였다. - 그 결과 Alaska의 디자이너들은 평균적으로 주당 11시간의 작업 시간을 절약했다. Alaska Airlines 사례는 디자인 시스템을 단순한 컴포넌트 모음이 아니라 디자인·개발·문서·교육을 연결하는 운영 체계로 구축해야 효과가 커진다는 점을 보여준다. 여러 플랫폼과 테마를 동시에 지원해야 하는 조직이라면 공통 컴포넌트와 Variables를 함께 도입하고, 이를 뒷받침할 문서화와 팀 교육까지 병행하는 것이 실용적이다.

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

카바나가 일관성과 확장성을

Carvana는 Figma의 디자인 시스템과 변수를 활용해 빠른 성장 속에서도 제품 경험의 일관성과 확장성을 유지했다. 분산된 디자인 도구를 Figma로 통합해 단일 기준을 만들고, 변수와 테마 기능으로 디자인·개발 협업과 브랜드 확장을 효율화했다. 그 결과 반복 작업과 수정이 줄고, 새로운 사업 영역에도 기존 디자인 언어를 빠르게 적용할 수 있었다. ## 성장에 대응하는 단일 기준 마련 - Carvana는 2019년 성장세가 가속화되면서 확장 가능한 디자인 플랫폼이 필요해졌다. - 기존 디자인 시스템은 PDF 기반 UI 키트, Principle, Sketch 등 여러 도구에 흩어져 있었다. - 컴포넌트를 복사해 사용하는 방식 때문에 동일한 요소가 조금씩 변형됐고, 디자인과 개발팀이 참조할 중앙 기준이 없었다. - Figma로 디자인 시스템을 이전하면서 디자인·개발팀이 함께 참조할 수 있는 연결된 단일 소스 오브 트루스를 구축했다. - 코로나19 시기 차량 판매가 급증했을 때도 통합된 시스템 덕분에 기존 도구에서 발생하던 협업 마찰을 줄이고 수요에 대응할 수 있었다. - 약 40명의 디자인 시스템 팀이 1만 명 규모의 회사 전반에 디자인 품질을 확산시키는 역할을 담당했다. ## 변수로 디자인 일관성과 효율성 강화 - 제품 생태계가 커지면서 색상, 간격, 타이포그래피, 모서리 반경이 화면과 컴포넌트마다 달라지는 문제가 발생했다. - Figma 변수는 색상이나 수치처럼 재사용 가능한 값을 정의하고 여러 디자인 속성에 적용할 수 있게 했다. - 특히 숫자 변수를 활용해 spacing과 corner radius를 일관된 값으로 관리했다. - 변수의 값을 중앙에서 정의하면 디자이너가 픽셀 수준의 정확성을 유지하면서도 반복적인 수정 작업을 줄일 수 있다. - 초기에는 변수 설정과 학습에 비용이 들었지만, 결과적으로 디자인 완성도가 높아지고 리뷰 과정에서 되돌아오는 수정 사항이 감소했다. - 변수 기반 시스템은 장기적으로 디자이너의 반복 작업과 리비전을 줄여 효율을 높인다. ## 테마 기능으로 인수 사업 통합 - Carvana가 자동차 경매 기업 ADESA를 인수한 뒤에도 변수는 새로운 브랜드 테마를 빠르게 도입하는 데 활용됐다. - 컴포넌트의 구조와 기능은 유지하면서 변수 값만 바꾸어 ADESA 전용 색상과 스타일을 적용할 수 있었다. - 기존 방식이라면 새 스타일에 맞춰 컴포넌트 라이브러리를 다시 구축하는 데 최소 한 달이 걸렸을 작업을, 변수 기반 테마로 1주일 이내에 처리했다. - ADESA용 디자인 시안을 평소보다 약 3배 빠르게 제작할 수 있었다. - 브랜드 변경을 개별 컴포넌트의 재작업이 아니라 테마 전환으로 처리함으로써 여러 화면 너비와 제품 영역에 일관되게 적용할 수 있었다. ## 디자인과 개발 간 연결 강화 - Figma 기반 디자인 시스템은 디자이너와 개발자가 동일한 컴포넌트와 변수 기준을 참조하도록 돕는다. - 중앙화된 라이브러리와 변수는 디자인 변경 사항을 일관되게 관리하고 핸드오프 과정의 마찰을 줄이는 기반이 된다. - 글에서는 변수와 Figma REST API를 활용한 개발 연계 및 변수 마이그레이션 사례도 소개한다. Carvana 사례는 성장하는 조직일수록 디자인 시스템을 여러 파일이나 도구에 분산시키기보다 단일 기준으로 통합해야 한다는 점을 보여준다. 특히 색상·간격·브랜드 스타일을 변수와 테마로 관리하면 제품 확장이나 인수 이후의 리브랜딩도 빠르고 안정적으로 수행할 수 있다.

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

디자인에서 코드로의 자동화를

Dev Mode의 코드 생성(codegen)은 디자인을 완성된 코드로 자동 변환하는 기능이라기보다, 개발자가 구현을 시작할 수 있도록 돕는 출발점이다. Figma는 기본 코드 스니펫을 제공하고, 팀의 디자인 시스템과 기술 스택에 맞춰 다양한 codegen 플러그인으로 확장할 수 있다고 설명한다. Anima, Builder, Figma to Code, Locofy.ai 같은 도구는 React·HTML·Tailwind부터 Flutter·SwiftUI까지 지원하며 반응형 구현과 컴포넌트화를 가속한다. ## Dev Mode와 codegen의 역할 - Codegen은 정해진 규칙이나 명세를 바탕으로 코드를 자동 생성하는 과정이다. - Figma Dev Mode에서 캔버스의 객체를 선택하면 Inspect 패널에 자동 코드 스니펫이 표시된다. - 사용자는 코드 언어와 단위 체계를 드롭다운에서 선택할 수 있다. - codegen은 디자인을 개발로 옮기는 작업을 완전히 대체하기보다, 매번 빈 화면에서 시작하지 않도록 구현의 출발점을 제공한다. - 성숙한 디자인 시스템을 운영하는 팀은 자체 규칙과 컴포넌트를 반영하기 위해 custom codegen 플러그인을 만들 수 있다. ## Anima를 활용한 디자인 코드 변환 - Figma의 레이어·컴포넌트·프레임을 React 또는 HTML 코드로 내보낼 수 있다. - CSS, SCSS, Tailwind 형식의 스타일 코드와 함께 인터랙티브하고 반응형인 결과물을 생성한다. - 반복되는 컴포넌트를 자동으로 감지해 코드 중복을 줄인다. - 팀이 사용하는 코드 스타일과 관례를 학습해 더 적절한 코드 스니펫을 제공한다. - Dev Mode에서 애니메이션을 추가하거나 특정 스타일에 맞게 코드를 조정하도록 요청할 수 있다. ## Builder의 AI 기반 코드 컴포넌트 활용 - React, Svelte, HTML 등의 코드를 AI로 생성한다. - 팀의 기존 코드 컴포넌트를 활용해 디자인과 실제 구현 사이의 간극을 줄인다. - 생성된 코드에 대해 대화형으로 수정 사항을 요청할 수 있다. - 팀의 코드 스타일에 맞도록 AI를 학습시키고, 디자인을 자동으로 반응형으로 변환할 수 있다. - Figma 밖의 별도 웹 인터페이스에서 생성 코드를 시험하고 수정할 수 있다. ## Figma to Code로 웹·모바일 코드 생성 - Figma Community에서 제공되는 무료 오픈 소스 플러그인이다. - 반응형 웹을 위해 HTML 또는 Tailwind 코드를 생성한다. - 모바일 앱 개발을 위해 Flutter와 SwiftUI 코드도 지원한다. - 플러그인에서 생성된 Tailwind 코드를 확인한 뒤 코드 에디터로 복사해 사용할 수 있다. - 별도의 유료 도구 없이 디자인을 여러 플랫폼의 코드로 빠르게 변환할 수 있다는 점이 특징이다. ## Locofy.ai를 통한 웹·모바일 프로토타입 구현 - React, HTML/CSS, Next.js, Gatsby, Vue 기반의 인터랙티브 코드를 생성한다. - 개별 컴포넌트뿐 아니라 전체 화면 단위의 코드 생성도 지원한다. - 자동 레이아웃과 프레임 그룹화 같은 디자인 최적화를 적용한다. - 시맨틱 HTML 요소, 라이브러리, 동작을 태깅해 인터랙션을 구성한다. - 화면 크기에 따른 반응형 동작을 지원한다. - 컴포넌트와 props를 생성해 결과물을 모듈화한다. - 사람이 이해하기 쉬운 문맥 기반 클래스명을 사용해 협업과 확장성을 높인다. - 생성 코드를 다듬은 뒤 프로토타입을 공유하고, 데이터를 연결하며, 코드나 Storybook 파일로 내보낼 수 있다. - GitHub와 직접 동기화하고 자동 병합 및 충돌 해결을 지원해 지속적 통합 흐름에 연결할 수 있다. 실무에서는 생성된 코드를 최종 결과물로 그대로 사용하기보다, 팀의 디자인 시스템·컴포넌트 구조·접근성·상태 관리·성능 기준에 맞게 검토하고 수정하는 것이 좋다. codegen 플러그인은 반복적인 초기 구현을 줄이고 협업을 빠르게 만드는 보조 도구로 활용할 때 가장 효과적이다.

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

디자인 시스템의 미래는

디자인 시스템은 좋은 컴포넌트와 문서를 만드는 것만으로 성공하지 않으며, 조직 구성원이 실제로 사용하도록 만드는 채택 전략이 필요하다. 따라서 디자인 시스템 팀은 자신들의 시스템을 하나의 제품처럼 보고, 사용자 이해·메시지 설계·조직 내 홍보·성과 측정을 마케팅 방식으로 수행해야 한다. 이를 통해 디자인 시스템을 선택 사항이 아닌 조직의 필수 기반으로 자리매김할 수 있다. ## 디자인 시스템도 제품처럼 시장 적합성을 찾아야 한다 - 디자인 시스템의 효과인 일관성, 효율성, 확장성은 구성원들이 널리 사용할 때 비로소 실현된다. - 단순히 Slack 메시지를 보내거나 교육 세션을 여는 것만으로는 채택을 이끌어내기 어렵다. - 디자인 시스템 팀은 내부 사용자를 대상으로 제품-시장 적합성(product-market fit)을 지속적으로 탐색해야 한다. - 디자이너, 개발자, 의사결정자 등 다양한 사용자의 다음 요소를 파악해야 한다. - 현재 업무 방식과 프로세스 - 반복되는 병목과 불편 - 새로운 도구에 대한 우려 - 시스템이 일상 업무에 제공할 수 있는 가치 - 아직 명확히 표현하지 못한 욕구와 불만 - 개별 실무자부터 리더십까지 Product Design and Engineering 조직 전반을 인터뷰하면 역할별 관점을 전략에 반영할 수 있다. - 인터뷰는 디자인 시스템 자체를 설명하는 것보다 현재의 업무 목표와 문제점을 먼저 묻는 방식으로 시작하는 것이 효과적이다. ## 대상별로 다른 메시지를 설계해야 한다 - 디자이너, 개발자, 프로젝트 관리자, 의사결정자는 같은 시스템을 사용하더라도 관심사와 판단 기준이 다르다. - 따라서 모두에게 동일한 홍보 문구를 전달하기보다 대상별로 설득 논리를 조정해야 한다. - **디자이너에게는** - 브랜드 일관성을 유지하면서도 창의성을 발휘할 수 있다는 점을 강조한다. - **개발자에게는** - 컴포넌트 재사용과 표준화 - 디자인과 코드 사이의 원활한 협업 - 반복 작업 감소와 효율 향상을 설명한다. - **의사결정자에게는** - 출시 속도 향상 - 기술 부채 감소 - 투자 대비 효과(ROI)를 중심으로 제안한다. - 유연성 부족, 기술적 한계, 도입 비용과 같은 반대 의견도 피하지 말고 구체적으로 다뤄야 한다. - 사용자의 회의적인 이유를 이해하고 이에 답하는 메시지를 제시하면 저항을 설득과 참여로 전환할 수 있다. ## 채택을 높이는 기능과 도구 - 글에서는 조직 전체의 채택을 지원하는 사례로 다음과 같은 기능을 언급한다. - 개발자를 위한 Code Connect - 타이포그래피 및 그라디언트 변수 - 디자인 시스템 사용 현황을 파악하는 Library Analytics API - 이런 기능은 디자인과 코드의 연결을 강화하고, 시스템이 실제로 어떻게 사용되는지 확인하게 해준다. - 특히 사용 데이터를 확보하면 어떤 팀이 시스템을 사용하고 있는지, 어느 부분에서 채택이 막히는지 파악해 후속 전략을 세울 수 있다. ## 조직 내부의 마케팅으로 접근하기 - 디자인 시스템 팀의 역할은 시스템을 구축하는 데서 끝나지 않고, 조직 안에서 그 가치를 지속적으로 알리고 확산시키는 데까지 확장되어야 한다. - 시스템을 성공시키려면 다음과 같은 제품 출시 전략이 필요하다. - 대상 사용자와 문제 정의 - 대상별 가치 제안 작성 - 도입 장벽과 반론에 대한 대응 - 내부 홍보와 지지자 확보 - 사용량과 성과 측정 - 이런 마케팅 관점은 디자인 시스템을 “있으면 좋은 도구”가 아니라 디지털 제품을 설계하고 개발하는 방식의 핵심 기반으로 바꾸는 데 목적이 있다. 실무적으로는 먼저 디자이너·개발자·리더를 인터뷰해 각자의 문제를 정리하고, 대상별 가치 제안과 도입 장벽을 문서화하는 것이 좋다. 이후 사용량과 반복 사용률 같은 데이터를 추적하면서 메시지와 지원 방식을 계속 개선해야 한다.

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

컴포넌트 스프린트의

워싱턴 포스트는 디자인과 개발이 분리된 채 진행되던 컴포넌트 제작의 문제를 해결하기 위해 약 10일간의 ‘컴포넌트 스프린트’를 도입했다. 디자이너와 개발자가 처음부터 한 쌍으로 참여하고, 관련 팀의 의견을 단계별로 반영해 기술적 제약과 실제 사용 맥락을 함께 고려한다. 이 방식은 디자인 시스템 컴포넌트를 더 빠르고 일관되게 제작하면서도, 팀 전체의 공동 소유 의식을 높이는 것이 핵심이다. ## 디자인 주도·개발 주도 방식의 한계 - 초기 WPDS(The Washington Post Design System)는 컴포넌트 성격에 따라 제작 주체가 달랐다. - `select`, `radio`, `checkbox`처럼 시각적 설계가 중심인 요소는 디자인 주도로 제작했다. - `carousel`, `input search`처럼 기술적 복잡성이 큰 요소는 개발 주도로 제작했다. - 한쪽 팀이 주도하면 다른 팀의 전문 지식이 늦게 반영되어 일정 지연과 타협이 발생했다. - 개발자는 디자인 단계에서 기술적 한계를 뒤늦게 지적하거나, 구현보다 세부적인 시각 요소에 집중하도록 압박받을 수 있었다. - 디자이너는 자신의 사용 사례가 충분히 고려되지 않거나, 이미 존재하는 컴포넌트를 알지 못해 별도 솔루션을 만들기도 했다. - 그 결과 디자인 시스템에는 잦은 오버라이드와 즉석에서 판단해야 하는 기능·변형 요청이 누적됐다. ## 컴포넌트 스프린트의 운영 원칙 - 모든 컴포넌트마다 스프린트를 시작하며, 일반적으로 약 10일 동안 진행한다. - 디자이너와 개발자가 처음부터 끝까지 프로세스를 이끄는 담당자로 짝을 이룬다. - 핵심 담당자 외에도 관련 팀의 의견을 수집해 폐쇄적인 순차 작업을 개방적이고 협력적인 과정으로 바꾼다. - 프로세스는 대체로 다음 단계로 구성된다. - 킥오프 - 콘셉트 정의 - 디자인과 구현 - 개선 및 다듬기 - 문서화 - 모든 참여자가 초기에 요구사항과 기술적 제약을 공유하므로, 후반부의 재작업과 오해를 줄일 수 있다. ## 킥오프: 영향도와 노력으로 우선순위 정하기 - 매주 30분 회의에서 Jira의 후보 컴포넌트 티켓을 검토한다. - 각 아이디어를 예상 영향도와 필요한 노력의 관점에서 비교해 우선순위를 정한다. - 아이디어 보드는 단순한 목록이 아니라 다음 정보를 축적하는 협업 공간으로 활용한다. - 이해관계자의 비동기 피드백 - Slack에서 논의된 관련 정보 - 비슷한 아이디어의 묶음 - 사업 목표와의 연관성 - 시각화된 영향도-노력 매트릭스에서는 원의 크기로 투표 수나 인기도를 표현하고, 색상으로 연관된 사업 목표를 구분한다. - 우선순위가 결정되면 디자인 시스템 팀에서 디자이너와 개발자를 각각 배정한다. - 두 담당자를 초기 단계부터 정함으로써 프로세스 전반의 지속적인 커뮤니케이션을 보장한다. ## 콘셉트 정의: 범위와 목표 합의하기 - 스프린트 시작 시 전체 팀과 함께 약 2시간의 회의를 진행한다. - FigJam에서 다음 내용을 공동으로 정리한다. - 컴포넌트의 목표 - 필수 요구사항 - 작업 범위 - 기술적 요구사항 - 검토가 필요한 가정과 쟁점 - 회의 마지막 15분은 결과 검토에 사용한다. - 기술 담당자와 비기술 담당자가 같은 공간에서 의견을 남기므로, 서로 다른 관점의 기대치를 조기에 맞출 수 있다. - 이 단계에서는 구체적인 디자인 세부사항보다 문제의 범위, 사용 목적, 구현 조건을 먼저 합의한다. - FigJam을 활용하면 특정 직군이 논의를 독점하지 않고, 참여자 모두가 요구사항을 명확히 할 수 있다. ## 실용적인 적용 방향 컴포넌트 제작을 한 팀에 일괄 위임하기보다, 디자이너와 개발자를 초기부터 공동 책임자로 배치하는 것이 효과적이다. 또한 영향도·노력 기반 우선순위 보드와 공개적인 요구사항 문서를 운영하면 불필요한 컴포넌트 중복과 후반 재작업을 줄일 수 있다.

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

디자인 시스템 구축 방법

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

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

이 올드스쿨 커서

Figma는 2024년 April Fun Day를 맞아 DOS부터 Y2K, 스큐어모피즘, Windows Vista의 Aero까지 과거 디지털 디자인을 재현한 커서를 공개했다. 커서는 단순한 포인터가 아니라 Figma·FigJam에서 사용자의 존재와 협업을 나타내는 아바타이므로, 시대별 시각 언어를 통해 개인 표현과 공동 작업 경험을 확장하려는 시도다. 사용자는 Figma 또는 FigJam 파일 우측 상단의 커서 아이콘에서 일주일 동안 네 가지 레트로 스타일을 선택할 수 있었다. ## 커서와 온라인 협업의 의미 - Figma와 FigJam에서 커서는 여러 사용자가 같은 캔버스에서 작업하고 있음을 보여주는 협업 아바타다. - 커서는 위치 표시뿐 아니라 커서 채팅, 이모트, 하이파이브 같은 상호작용도 지원한다. - 화면을 사이에 두고도 서로의 존재와 감정을 확인하게 해주는 인터페이스 요소라는 점에서, 단순한 UI 장식 이상의 역할을 한다. - 이번 기획은 커서를 디지털 시대의 상징적 상호작용 요소로 보고, 인터넷 역사 속 네 가지 미학으로 재해석했다. ## 8비트: 픽셀로 표현한 초기 컴퓨터 문화 - 8비트 스타일은 텍스트 기반 터미널부터 Windows 2000 초기까지의 웹과 컴퓨터 문화를 떠올리게 한다. - Pac-Man, Space Invaders 같은 아케이드 게임과 저해상도 화면, 굵은 픽셀이 주요 시각적 영감이다. - DOS는 GUI 없이 사용자가 명령어를 직접 입력하는 텍스트 기반 운영체제이며, GUI는 아이콘·창·메뉴·버튼으로 정보를 표현한다. - 제작진에게 DOS 시절의 컴퓨터 경험은 초기 컴퓨팅에 대한 개인적인 향수와 연결되어 있다. - Windows 2000의 입체적인 아이콘, 돌출된 시작 버튼, 움푹 들어간 시계 영역처럼 빛과 깊이를 표현한 디자인도 당시의 중요한 기억으로 언급된다. - 커서 디자인에서는 해상도를 의도적으로 낮춰 픽셀 격자를 강조하고, 손가락 모양이나 2번 연필처럼 단순하고 친근한 아이콘을 활용했다. - 제한적인 그래픽 안에서도 손, 하트, 연필 등 표현력 있는 형태를 사용해 레트로 감성과 개성을 살렸다. ## Y2K: 2000년 전후의 대중문화와 디지털 감성 - Y2K 섹션은 2000년 전후의 패션과 대중문화를 배경으로 한다. - 카고 팬츠, 베이비 티, Backstreet Boys의 앨범 *Millennium*, 전화 접속 인터넷의 전자음 같은 요소가 시대적 분위기를 구성한다. - 투명한 플라스틱 소재의 다마고치 이미지는 당시 소비자 전자제품과 장난감에서 나타난 미래 지향적이고 장난스러운 감성을 상징한다. - 글은 Y2K가 약 25년 전의 스타일임에도 현재 낯설지 않은 이유를 되짚으며, 당시의 시각 언어를 커서 디자인으로 재현하려 한다. ## 네 가지 레트로 스타일의 재해석 - Figma가 소개한 커서 테마는 8비트, Y2K, 스큐어모픽, Aero로 구성된다. - 각 스타일은 특정 운영체제나 장식만 복원하는 것이 아니라, 해당 시대의 기술 경험과 대중문화, 인터페이스 감각을 함께 재현한다. - 레트로 디자인을 현대 협업 도구에 적용함으로써 향수를 자극하면서도 사용자의 개성을 드러내는 기능으로 확장했다. - 커서는 작고 단순한 UI 요소지만, 색상·형태·질감만으로도 시대적 분위기와 사용자 정체성을 표현할 수 있다. 실용적으로는 레트로 스타일을 단순한 장식으로만 보지 말고, 사용자의 존재감과 감정 표현을 강화하는 인터랙션 디자인 요소로 활용할 수 있다. 특히 협업 제품에서는 작은 시각적 변화도 참여감과 친밀감을 높이는 장치가 될 수 있다.

원문 읽기(새 탭에서 열림)
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분 읽기큐레이션 요약

AI + 디자인: 피

생성형 AI의 성패는 기술 자체보다 사용자가 이해하고 실제로 활용할 수 있도록 설계하는 데 달려 있다. Figma 설문에서 대부분은 AI가 기업 제품에 영향을 줄 것으로 예상했지만, 실제 제품에서 AI의 역할은 아직 제한적이며 성과와 만족도도 낮았다. 따라서 단순히 AI 기능을 추가하기보다 기존 경험과 자연스럽게 통합하고 명확한 사용자 문제를 해결하는 디자인이 중요하다는 결론이다. ## 조사 대상과 AI의 현재 위치 - Figma는 2024년 2월 26일~3월 3일, 미국·캐나다·호주·영국·일본·프랑스·독일의 사용자 1,800명 이상을 조사했다. - 응답자는 디자이너, 개발자, 임원으로 구성됐다. - 생성형 AI는 텍스트·이미지·기타 데이터를 생성 모델과 프롬프트를 통해 만들어내는 기술로 정의됐다. - AI는 인터넷, 전기, 스마트폰처럼 범용 기술로 발전할 가능성이 있지만, 초기에는 기술을 일상에서 직관적이고 유용하게 만드는 디자인 작업이 필요하다. ## 높은 기대와 실제 성과의 격차 - 응답자의 89%는 향후 12개월 안에 AI가 자사 제품이나 서비스에 어느 정도 영향을 줄 것이라고 예상했다. - 37%는 그 영향이 “상당하거나 변혁적일 것”이라고 답했다. - 특히 의사결정을 담당하는 임원층이 AI를 회사 목표에 중요하다고 보는 경향이 더 강했다. - 그러나 AI를 제품에 도입한 사람 중 72%는 AI가 제품에서 “부수적이거나 필수적이지 않은 역할”을 한다고 평가했다. - AI 도입으로 매출, 비용, 시장점유율 등의 지표가 개선됐다고 답한 사람은 약 3분의 1에 불과했다. - 출시한 AI 기능을 자랑스럽게 생각한다는 응답도 3분의 1보다 적었다. ## AI 기능 피로와 사용자 문제의 부재 - Figma 연구진은 사용자 인터뷰와 장기간 분석을 통해 “또 하나의 AI 기능”에 대한 무관심이 나타나고 있다고 설명한다. - 이를 “AI feature fatigue”, 즉 AI 기능 피로라고 부를 수 있다. - AI 제품이나 기능을 만드는 사람 중 20% 이상은 “사용자 요구나 문제를 해결하지 못하는 것”을 주요 과제로 꼽았다. - 이 문제는 특히 해당 제품을 설계하는 디자이너에게 두드러졌다. - AI 제품을 개발 중인 응답자 가운데 실제로 기능을 출시한 사람은 절반에도 못 미쳤다. - 앞으로 AI 기능이 대량으로 출시되면, 시장이 실질적 가치 없는 AI 기능에 피로감을 느낄 가능성이 있다. ## 기존 제품에 AI를 자연스럽게 통합하기 - 응답자의 3분의 1은 11개 과제 중 “AI 기능을 기존 제품에 일관성 있게 통합하는 일”을 가장 중요한 우려로 선택했다. - 새로운 기능을 추가하는 것만으로는 AI 도입의 가치가 만들어지지 않는다. - AI가 제품의 기존 사용 흐름을 방해하지 않으면서 실제 경험을 개선해야 한다. - 사용자가 현재 어떤 도구를 이용할 수 있는지, AI가 어떤 상황에서 도움이 되는지 이해하도록 안내하는 설계가 필요하다. - AI의 성능보다 사용자가 기능을 발견하고, 이해하고, 신뢰하며, 반복해서 사용할 수 있는 인터페이스가 중요하다. ## ChatGPT 사례가 보여주는 디자인의 영향 - ChatGPT가 널리 사용되기 시작한 2022년 11월 당시 기반 모델의 기능은 이미 일정 기간 제공되고 있었다. - OpenAI는 모델 자체를 새롭게 만든 것뿐 아니라, 사용자가 쉽게 접근할 수 있는 대화형 채팅 인터페이스를 제공했다. - 대화 방식, 접근성, 도움을 주려는 상호작용 구조가 기술을 인간의 목적에 더 잘 맞도록 만들었다. - 이는 강력한 기술이라도 사용자가 이해하고 활용할 수 있는 경험으로 설계되지 않으면 대중적 채택으로 이어지기 어렵다는 점을 보여준다. ## 실용적인 시사점 - AI 기능을 추가하기 전에 해결하려는 사용자 문제와 기대 효과를 먼저 정의해야 한다. - “AI를 넣는 것”보다 기존 제품 흐름에서 AI가 어떤 행동을 개선하는지 검증해야 한다. - 사용자가 기능의 한계와 활용 방법을 이해할 수 있도록 명확한 안내와 피드백을 제공해야 한다. - 기술팀과 디자인팀이 협력해 AI의 가능성을 실제 사용 사례와 유용한 경험으로 변환해야 하며, 단순한 유행성 기능은 피하는 것이 좋다.

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

지금 바로 북마크해야 할

프로토타이핑은 제품 개발 막바지의 보조 수단이 아니라, 아이디어 검증·사용자 조사·이해관계자 피드백·프레젠테이션 등 전 과정에서 팀의 공통 비전을 만드는 핵심 도구다. 이 글은 Figma 프로토타이핑 학습을 위해 기초 강의부터 발표, 모션과 플로우, 변수, 오피스 아워까지 23개의 영상·커뮤니티 파일·콘텐츠를 단계별로 큐레이션한다. 학습자는 자신의 수준과 목적에 맞는 자료를 골라 인터랙션 구현 능력을 높이고 더 나은 제품을 설계할 수 있다. ## 프로토타이핑의 역할 - 프로토타입은 제품의 동작과 사용자 경험을 시각화해 팀이 아이디어를 공유하도록 돕는다. - 사용자 테스트와 이해관계자 피드백을 통해 문제를 조기에 발견하고 반복적으로 개선할 수 있다. - 발표 자료에도 인터랙션을 추가해 정적인 화면보다 설득력 있게 제품의 흐름과 기능을 전달할 수 있다. - Figma는 모바일·태블릿·워치 등 다양한 디바이스 화면을 고려한 프로토타이핑 기능을 강화하고 있다. ## 기초 기능 익히기 - **「Build prototypes」(8분)** - 인터랙티브 프로토타입 제작의 기본 흐름을 소개한다. - 애니메이션을 적용하고 테스트 사용자에게서 피드백을 반영하는 방법을 다룬다. - **「Prototyping playlist」(50분)** - easing curve, transition, Smart Animate, 스크롤, 디바이스 프레임 등 핵심 기능을 짧은 영상들로 학습할 수 있다. - **「Prototyping 101」(63분)** - 프레임 간 기본 내비게이션부터 인터랙티브 컴포넌트 같은 고급 기능까지 설명한다. - **제품 담당자를 위한 Figma 학습 시리즈** - 디자이너가 아닌 제품 담당자도 가벼운 프로토타입을 직접 만들 수 있도록 안내한다. - 두 번째 영상에서는 transition, Smart Animate, 스크롤 동작 등을 활용해 화면을 더 실제처럼 만드는 방법을 다룬다. - **접근 가능한 프로토타입 커뮤니티 파일** - Figma의 접근성 모드를 활용해 프로토타이핑 화면의 정보를 스크린 리더로 읽을 수 있다. - macOS의 VoiceOver와 Windows의 JAWS 같은 도구를 통한 접근성 테스트에 활용할 수 있다. ## 발표 자료를 인터랙티브하게 만들기 - **「Presenting with Figma」(70분)** - Figma 프로토타이핑 기능을 활용해 역동적인 슬라이드 프레젠테이션을 구성하는 방법을 소개한다. - **발표 팁 영상** - 슬라이드 안에 프로토타입을 중첩해 실제로 스크롤되는 모바일 화면 등 인터랙티브 요소를 넣을 수 있다. - 이 방식은 이사회 보고, 수업, 제품 소개처럼 메시지 전달이 중요한 상황에 유용하다. - **Figma 앱으로 발표하기** - 모바일 앱에서 슬라이드를 직접 클릭하며 발표하는 방법을 보여준다. ## 영상·모션·사용자 플로우 학습 - 프로토타입의 완성도를 높이려면 단순한 화면 연결뿐 아니라 전환 효과, 애니메이션, 스크롤 동작을 함께 설계해야 한다. - Smart Animate와 easing curve를 사용하면 화면 변화가 더 자연스럽고 제품의 실제 동작에 가까워진다. - 모션과 플로우를 활용하면 사용자가 어떤 순서로 기능을 경험하는지 명확하게 검증할 수 있다. ## 변수와 고급 프로토타이핑 - 변수 기능을 활용하면 하나의 프로토타입에서 상태, 값, 조건에 따른 다양한 동작을 관리할 수 있다. - 반복되는 상태나 화면을 개별 프레임으로 복제하는 대신 변수와 인터랙티브 컴포넌트로 구성해 유지보수성을 높일 수 있다. - 복잡한 사용자 플로우와 여러 상태를 표현할 때 변수 기반 설계가 특히 유용하다. ## 오피스 아워와 실습 자료 - Figma의 오피스 아워 콘텐츠는 프로토타이핑 기능과 실제 활용 사례를 보충 학습할 수 있는 자료로 제공된다. - 영상뿐 아니라 Figma 커뮤니티 파일을 직접 열어 결과물을 확인하고 따라 해볼 수 있다. - 학습 방식에 따라 짧은 영상, 장시간 강의, 실습 파일, 소셜 콘텐츠 중 적합한 자료를 선택할 수 있다. 처음 시작한다면 기초 프로토타입 제작과 프레임 간 내비게이션부터 익힌 뒤, Smart Animate·스크롤·인터랙티브 컴포넌트로 확장하는 순서가 좋다. 이후 접근성 테스트, 변수, 발표용 프로토타입을 적용하면 실무에서 검증과 커뮤니케이션을 동시에 강화할 수 있다.

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

기능 비하인드: 멀

Figma의 **멀티 편집(multi-edit)**은 여러 프레임이나 컴포넌트 세트에 속한 객체를 한 번에 선택하고 수정할 수 있게 해 반복 작업을 줄이는 기능이다. 이 아이디어는 2019년 variants 기능을 설계하던 중 시작됐지만, 선택 방식과 편집 동작을 새롭게 정의해야 해 오랜 기간 다듬어졌다. Figma는 멀티 편집처럼 사용자가 별도 학습 없이 자연스럽게 쓰는 기능을 만드는 일을 제품 개발의 중요한 목표로 본다. ## 멀티 편집의 출발점: variants의 반복 작업 - 2019년 variants 기능을 설계하던 중, 여러 변형에 같은 수정 작업을 반복해야 하는 문제가 드러났다. - Figma 팀은 이 문제를 해결하기 위해 이틀간 디자인 서밋을 열고 다양한 접근법을 논의했다. - 핵심 아이디어는 특정 모드에 들어가면 한 객체에 한 수정이 모든 variants에 동시에 적용되도록 하는 것이었다. - 이후 이 방식은 variants뿐 아니라 여러 디자인 객체를 한꺼번에 편집해야 하는 다양한 상황에도 유용하다고 판단됐다. - 팀은 화이트보드에 아이디어를 그린 뒤 이를 “multi-edit”라고 이름 붙였다. ## 기존 다중 선택 방식의 한계 - Figma는 이미 여러 객체를 선택해 일부 속성을 동시에 수정할 수 있었지만, 실용성에는 한계가 있었다. - 사용자가 실제로 수정하려는 객체만 정확히 선택하기 어려웠다. - 여러 객체를 선택한 뒤에도 편집 종류에 따라 결과가 제대로 작동하지 않았다. - 여러 객체의 색상 변경은 비교적 쉬웠지만, 크기 조정은 어려웠다. - 여러 텍스트 노드의 글꼴이나 글자 크기는 바꿀 수 있지만, 텍스트 내용 자체를 동시에 수정하기는 어려웠다. - 따라서 단순히 “여러 개를 선택하는 기능”이 아니라, 선택과 편집 동작 전체를 재설계해야 했다. ## 아이디어의 긴 숙성 기간 - 초기에는 멀티 편집을 고급 텍스트 편집기의 다중 커서처럼 강력한 별도 편집 모드로 구상했다. - 그러나 실제 구현을 검토하면서 Figma의 기존 선택 모델과 어떻게 결합할지 해결해야 했다. - 어떤 객체를 같은 대상으로 간주할지, 선택된 객체에 어떤 편집을 허용할지 등 핵심 원칙이 명확하지 않았다. - 이러한 문제를 정리하는 데 시간이 필요해 아이디어는 곧바로 개발되지 못하고 오랫동안 “동면” 상태에 머물렀다. - 글은 멀티 편집이 처음부터 완성된 기능이 아니라, 반복적인 시행착오와 세부 조정을 거쳐 출시됐음을 강조한다. ## 현재 제공되는 멀티 편집 사용법 - `⌘ Command + ⌥ Option + A`: 조건에 맞는 동일한 객체를 모두 선택한다. - `Shift`를 누른 채 드래그: 원하는 동일 객체만 직접 선택한다. - 여러 텍스트 객체를 선택한 뒤 `Enter`: 텍스트 멀티 편집 모드로 들어간다. - 컴포넌트 세트를 선택한 뒤 `Q`: variants 멀티 편집 모드로 전환한다. - 멀티 편집을 사용하면 여러 프레임과 컴포넌트 세트에 걸친 객체를 몇 번의 동작만으로 동시에 수정할 수 있다. ## 실용적인 결론 반복적으로 여러 화면이나 variants를 수정해야 한다면 멀티 편집을 우선 활용하는 것이 좋다. 특히 동일한 텍스트를 수정하거나 여러 컴포넌트의 공통 속성을 변경할 때 기존 객체를 하나씩 편집하는 것보다 훨씬 효율적이다.

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

Figma에서 Eng Crits

Figma의 엔지니어링 크리트(eng crit)는 완성된 설계를 승인하는 절차가 아니라, 기술적 아이디어를 초기에 공유하고 다양한 관점의 피드백을 받아 팀의 진행을 돕는 협업 방식이다. 늦은 기술 리뷰에서 발생하는 방향 전환이나 출시 차단 문제를 줄이기 위해, 디자인 크리의 개방성과 브레인스토밍 방식을 엔지니어링에 적용했다. Figma는 이를 FigJam의 열린 캔버스에서 운영하며, 참여자가 많아도 누구나 의견을 보태는 구조를 만들었다. ## 늦은 기술 리뷰의 한계 - 일반적인 기술 리뷰는 프로젝트 후반부에 상세한 엔지니어링 스펙을 검토하고 승인받는 절차로 진행된다. - 리뷰 시점이 너무 늦으면 주요 방향이나 설계가 이미 구현된 뒤라서, 피드백이 출시를 막는 문제로 이어질 수 있다. - 승인 여부가 “찬성/반대”로 나뉘는 이진적 구조에서는 새로운 아이디어를 탐색하거나 함께 개선하기 어렵다. - 초기 단계의 미완성 아이디어를 공유하려면 실수를 비난하지 않고 열린 대화를 장려하는 문화가 필요하다. ## 엔지니어링 크리의 목적 - 기술적 문제에 대한 새로운 접근법을 함께 브레인스토밍한다. - 진행 중인 작업과 기술 설계를 일찍, 자주 공유한다. - 전문성을 가진 동료에게 조언을 구하고 팀의 작업을 막고 있는 문제를 해결한다. - 승인이나 통과 여부를 결정하는 공식 게이트가 아니라, 프로젝트를 앞으로 나아가게 하는 지원 포럼으로 운영한다. - Figma CTO Kris Rasmussen은 이를 “아이디어를 함께 키우는 장소”로 설명하며, 정원에 비유해 다른 사람이 아이디어를 발전시키는 과정에 참여해야 한다고 강조한다. ## 디자인 크리에서 얻은 영감 - Figma의 디자인 크리는 결과물을 승인하는 자리가 아니라, 탐색과 피드백을 위한 안전한 공간으로 운영된다. - 엔지니어링 크리는 디자인 크리와 기술 리뷰의 중간 형태로 설계됐다. - 디자인 크리처럼 초기 작업을 공유하되, 기술 리뷰처럼 기술적 설계에 대한 전문적인 피드백을 받을 수 있도록 했다. - 핵심은 완성된 결과를 평가하는 것이 아니라, 작업자가 다음 단계로 나아가는 데 필요한 도움을 제공하는 것이다. ## 기존 리뷰 방식의 문제점과 협업형 포맷 - 동기식 기술 리뷰에서는 소수의 팀 리드가 대화를 주도하고, 다른 참가자는 충분히 의견을 내기 어려웠다. - 비동기식 리뷰에서는 각자가 댓글을 남기는 데 그쳐, 서로 연결되지 않은 피드백이 긴 댓글 스레드로 쌓였다. - Figma는 FigJam을 사용해 이 문제를 해결했다. - 여러 사람이 짧은 시간에 동시에 의견을 남길 수 있다. - 한 사람이 발표하고 나머지가 순서대로 응답하는 방식이 아니다. - 초기 아이디어, 참고 자료, 진행 중인 화면, 스크린샷, 질문과 맥락을 한 캔버스에 함께 배치할 수 있다. - 단순한 피드백 목록이 아니라 공동 브레인스토밍과 대화가 가능하다. ## 참여 규모를 확장한 과정 - 처음에는 8~10명 규모의 가까운 팀에서 파일럿을 진행했다. - 반복 가능한 진행 형식을 정립한 뒤 캘린더 초대를 개방했다. - 참여자는 점차 늘어 200명 이상이 참석하는 조직 단위 프로세스로 발전했다. - 현재는 Figma 에디터를 개발하는 모든 엔지니어에게 초대장을 보내며, 참석자는 “선택 사항”으로 표시한다. - 다른 조직이나 직군도 자유롭게 참여할 수 있고, 자신의 전문성과 관련된 주제일 때 주로 참석한다. ## 실용적인 적용 방법 - 리뷰를 승인 절차로 정의하지 말고, 초기 피드백과 문제 해결을 위한 자리로 명확히 규정한다. - 완성된 문서만 요구하지 말고, 미완성 설계·스크린샷·참고 자료도 공유하도록 허용한다. - 특정 리더 몇 명에게 발언이 집중되지 않도록 여러 사람이 동시에 참여할 수 있는 도구와 형식을 사용한다. - 참석을 의무화하기보다 선택적으로 운영해 관심과 전문성에 기반한 참여를 유도한다. - 중요한 것은 회의 자체보다, 아이디어를 일찍 공개하고 함께 발전시킬 수 있는 심리적 안전감과 협업 문화를 만드는 것이다.

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