figma·2024년 4월 10일·3분 읽기큐레이션 요약

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

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 플러그인은 반복적인 초기 구현을 줄이고 협업을 빠르게 만드는 보조 도구로 활용할 때 가장 효과적이다.

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

ReactFigmadesign-to-codeHTML+3

figma·2024년 1월 30일·3분 읽기큐레이션 요약

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를 효과적으로 활용하려면 디자인과 개발을 별도 도구로 분리하기보다, 디자인 파일 안에서 주석·측정값·준비 상태·변경 이력을 일관되게 관리하는 것이 좋습니다. 특히 개발 전달 전에 “개발 준비 완료” 상태와 변경점을 명확히 표시하면 커뮤니케이션 비용을 줄일 수 있습니다.

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

ReactFigma디자인 시스템design-to-code+3

figma·2023년 11월 21일·3분 읽기큐레이션 요약

개발 모드: 개발자를 위해 더

Figma는 개발자를 단순한 디자인 파일 소비자가 아니라 제품 개발의 핵심 사용자로 보고 Dev Mode를 구축했다. 초기에는 디자인을 코드로 자동 변환하는 codegen 중심 접근을 택했지만, 실제 조직의 다양한 기술 스택과 협업 방식에는 한계가 있음을 발견했다. 결국 Dev Mode는 코드 생성만이 아니라 디자인 탐색, 변경 비교, 개발 도구 연동 등 개발자에게 맞춘 작업 환경을 제공하는 방향으로 확장됐다. ## 디자인과 개발의 경계를 줄이려는 Figma의 목표 - Figma는 처음부터 디자이너만을 위한 도구가 아니라 제품 관리자, 개발자 등 여러 직군이 함께 문제를 해결하는 공간을 지향했다. - 2017년 프로토타이핑과 개발자 핸드오프 기능을 선보이며 디자인과 코드 사이의 협업 흐름을 개선하려 했다. - 개발자들은 디자인 작업 중인 파일을 직접 확인하고 여러 핸드오프 방식을 실험했지만, 기존 Figma는 개발자 업무에 최적화된 도구는 아니었다. - Dev Mode는 디자인을 검사하고, 변경 사항을 비교하며, VS Code에서 작업하는 기능 등을 제공하는 개발자용 환경으로 출시됐다. ## 개발자 관점을 확보한 Visly 인수 - Figma 사용자 중 개발자가 약 3분의 1을 차지했지만, 개발자의 작업 방식과 도구 선호도에 대한 실질적인 직관은 부족했다. - 2021년 Figma는 React UI 컴포넌트 개발 도구를 만들던 Visly를 인수했다. - Visly 팀은 개발자 도구에 대한 연구와 실제 개발 경험을 Figma에 가져왔고, Dev Mode 개발을 가속했다. - 인수의 핵심 효과는 개발자를 대상으로 조사하는 것에서 나아가, 개발자처럼 생각하고 제품을 설계할 수 있는 팀을 확보한 데 있었다. ## 개발자를 2차 사용자가 아닌 핵심 사용자로 설계 - 기존 개발자들은 디자인 협업 때문에 Figma에 들어오지만, Figma가 자신들을 위해 만들어졌다고 느끼기 어려웠다. - Dev Mode 팀은 개발자가 디자인 모드의 복잡한 상호작용을 배울 필요 없이, 자신의 작업 방식에 맞는 인터페이스를 사용해야 한다고 판단했다. - 개발자 중심 기능으로 다음과 같은 아이디어를 검토했다. - 컴포넌트 플레이그라운드 - 코드 스니펫 - GitHub, Storybook 등 개발 도구와의 플러그인 연동 - 개발자 전용 리소스 - 중요한 관점은 개발자가 디자인 도구 안에서 장시간 생활한다는 전제가 아니라, 기존 개발 환경과 연결되는 보조 작업 공간을 제공하는 것이었다. - 베타 사용자 피드백과 고객 요청을 지속적으로 수집해 기능 우선순위에 반영했다. ## codegen 중심 접근의 출발과 한계 - **Codegen**은 정해진 규칙이나 명세를 바탕으로 디자인에서 코드를 자동 생성하는 방식이다. - Dev Mode 초기에는 디자인을 코드로 변환하면 개발 속도가 크게 빨라질 것이라고 보고 codegen을 핵심 방향으로 삼았다. - 자동 변환이 잘 작동하는 경우 프로젝트 작업 시간을 수시간에서 수일까지 줄일 수 있었다. - 그러나 테스트 환경에서 codegen이 작동하는 것과 실제 조직의 개발 프로세스에서 유용하게 작동하는 것은 달랐다. - 기업 규모, 팀 구조, 기술 스택, 개발 워크플로가 서로 다르기 때문에 모든 조직에 동일한 코드 생성 규칙을 적용하기 어려웠다. - 따라서 Dev Mode의 가치는 완성된 코드를 일괄 생성하는 데만 있지 않고, 개발자가 디자인 의도를 이해하고 자신의 코드베이스와 방식에 맞게 구현하도록 돕는 데 있다는 방향 전환이 필요해졌다. ## 실용적인 시사점 디자인-개발 협업 도구는 자동 코드 생성만으로 문제를 해결하기 어렵다. 조직별 기술 환경과 개발자의 실제 작업 흐름을 고려해 디자인 검사, 변경 추적, 코드 정보 제공, 기존 개발 도구와의 연동을 함께 지원해야 하며, 개발자를 제품의 부차적 사용자가 아닌 핵심 사용자로 설계하는 것이 중요하다.

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

ReactFigmagithubdev-mode+3

figma·2023년 8월 21일·3분 읽기큐레이션 요약

Dev Mode 후속 업데이트:

Figma는 Dev Mode 오픈 베타 2개월 동안 사용자 피드백 5,000건 이상을 반영해 200개가 넘는 기능과 수정 사항을 배포했다. 이번 업데이트의 핵심은 디자인 파일을 개발자가 더 쉽게 탐색·검수하고, 코드 생성 결과를 실제 개발 환경에 가깝게 만드는 것이다. 상태 라벨, 버전 비교, 향상된 코드 스니펫, VS Code 연동 등으로 디자이너와 개발자 간 협업 효율을 높였다. ## Dev Mode에 새로 추가된 기능 - 컴포넌트, 인스턴스, 프레임, 섹션에 개발 준비 상태를 나타내는 **상태 라벨**을 추가할 수 있다. - Design Mode에서 제공되던 **레이아웃 그리드, 룰러, 아웃라인 모드**를 View 메뉴와 기존 단축키로 사용할 수 있다. - 분리(detached)된 컴포넌트를 원본 메인 컴포넌트와 비교해 변경 사항을 확인할 수 있다. - 코드 옵션으로 **Android XML과 iOS UIKit**이 다시 제공된다. - 색상 형식에서 `UIColor`를 선택할 수 있다. - 파일 이름을 클릭하면 **버전 기록의 여러 디자인 버전**을 열어 검사할 수 있다. ## 사용성 및 성능 개선 - 외부 라이브러리에서 가져온 디자인 시스템 컴포넌트의 라이브러리 이름을 표시한다. - 컴포넌트 플레이그라운드에서 중첩된 컴포넌트 속성과 컴포넌트 모드를 확인하고 실험할 수 있다. - 텍스트 속성에는 `rem` 단위를 사용하면서, 다른 속성은 픽셀 단위로 유지할 수 있다. - 캔버스에서 여러 객체를 `Shift` 클릭으로 선택하고 한 번에 내보낼 수 있다. - Figma 파일과 알림을 **VS Code 내부에서 확인**할 수 있다. - 타이포그래피 미리보기에서 스타일 이름, 글자 크기, 줄 높이 같은 속성을 확인하고 복사할 수 있다. - 텍스트의 특정 부분만 선택해 개별 속성을 검사할 수 있다. - 왼쪽 레이어 패널의 높이를 드래그로 조절할 수 있다. - 원시 값과 일치 가능성이 높은 디자인 시스템 변수를 자동으로 제안한다. - 코드 스니펫뿐 아니라 Figma 속성 형식으로도 값을 확인할 수 있다. - 디자인에 포함된 이미지 등의 소스 파일을 다운로드할 수 있다. - 대체 단위 설정을 일반 환경설정 메뉴에서 쉽게 찾을 수 있다. - 섹션을 선택하면 프레임별 링크를 모아서 확인할 수 있다. ## 코드 생성 개선 - `Shift` 키를 누른 채 모든 코드 스니펫을 한 번에 복사할 수 있다. - 하나의 패딩 값만 설정된 경우에도 CSS에서 `padding-top`, `padding-bottom`, `padding-left`, `padding-right`를 생성한다. - 코드에 `font-style`, `line-height`, `font-weight`를 항상 표시한다. - `line-height`를 백분율과 픽셀 값으로 함께 제공한다. - CSS 코드 생성에서 다음 OpenType 기능을 지원한다. - `font-feature-settings` - `font-variant-numeric` - `font-kerning` - 오토 레이아웃의 `min-width`, `max-width`, `min-height`, `max-height`와 줄바꿈 레이아웃의 세로 간격에 변수를 사용할 수 있다. - 여러 문단이나 서로 다른 텍스트 스타일이 섞인 텍스트 레이어는 스타일별 CSS 코드를 개별적으로 표시한다. - 커뮤니티에는 Tailwind, React, Vue 등을 위한 약 80개의 코드 생성 플러그인이 제공된다. ## 버그 수정 및 탐색 개선 - 탭 키 내비게이션으로 Design Mode와 Dev Mode 사이를 전환할 수 있다. - 힌트와 툴팁 전반에서 대체 단위를 올바르게 표시한다. - 텍스트 그라디언트 표시를 개선하는 등 시각적 품질 문제를 수정했다. 이번 업데이트는 Dev Mode를 단순한 디자인 검사 도구가 아니라, 디자인 시스템 확인·코드 생성·파일 관리·개발 환경 연동을 아우르는 협업 작업 공간으로 발전시키는 데 초점을 맞췄다. 팀에서는 상태 라벨과 버전 기록을 개발 핸드오프 과정에 적극 활용하고, 생성된 CSS나 플랫폼 코드는 실제 프로젝트 규칙과 비교해 검토하는 것이 좋다.

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

ReactFigmaCSSdev-mode+4

figma·2023년 7월 18일·3분 읽기큐레이션 요약

프롭스의 공유 언어 |

컴포넌트와 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의 목적과 대응 관계를 문서화하고, 시각적 속성과 동작·데이터 속성을 구분하면 디자이너와 개발자 사이의 오해를 줄일 수 있다.

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

ReactFigma디자인 시스템TypeScript+3

figma·2023년 7월 12일·3분 읽기큐레이션 요약

Thumbtack이 디자인

Thumbtack은 디자인 시스템 **Thumbprint**를 토큰, Atomic CSS, 컴포넌트의 3계층으로 구성해 유연성과 생산성을 함께 확보한다. 하위 계층일수록 세밀한 제어와 확장성이 높고, 상위 계층일수록 접근성·일관성·개발 생산성이 높아진다. 필요한 경우 각 계층 내부에도 추가 계층을 두어, 개발자가 일반적인 상황에서는 간편한 추상화를 사용하면서도 특수한 요구에는 더 낮은 계층으로 내려갈 수 있게 했다. ## 3단계 계층 구조 - **Thumbprint Tokens** - 시스템의 가장 낮은 추상화 계층이다. - 색상, 타이포그래피, 모서리 반경, 간격, 크기, 그림자 등 세부 디자인 속성을 변수로 정의한다. - 웹과 네이티브 클라이언트 모두에서 사용된다. - 가장 세밀하고 유연하지만, 이를 직접 조합해야 하므로 개발 생산성은 상대적으로 낮다. - **Thumbprint Atomic** - Thumbprint Tokens 위에 구축된 원자적 CSS 라이브러리다. - 개발자가 별도의 커스텀 CSS를 작성하지 않고도 UI를 구성할 수 있다. - 예를 들어 `aspect ratio` 클래스를 사용하면 YouTube나 Vimeo 같은 외부 미디어의 가로세로 비율을 일정하게 유지할 수 있다. - 토큰보다 생산성이 높지만, 완전히 자유롭게 스타일을 제어하는 것보다는 유연성이 낮다. - **Thumbprint Components** - 가장 높은 추상화 계층으로, 자주 사용하는 UI 패턴을 접근성까지 고려해 미리 구현한다. - 알림, 버튼, 날짜 선택기, 별점 등 공통 컴포넌트를 제공한다. - 개발자는 반복적인 UI 구현보다 핵심 제품 기능에 집중할 수 있다. - 제공되지 않는 컴포넌트가 필요하면 Atomic CSS를 사용해 직접 구성하고, 그보다 더 낮은 수준의 제어가 필요하거나 네이티브 환경이라면 디자인 토큰을 직접 사용할 수 있다. ## 계층에 따른 트레이드오프 - 하위 계층으로 내려갈수록: - 디자인 속성을 세밀하게 제어할 수 있다. - 새로운 제품 요구사항에 유연하게 대응할 수 있다. - 대신 구현과 유지보수에 더 많은 개발 노력이 필요하다. - 상위 계층으로 올라갈수록: - 접근성, 시각적 일관성, 개발 생산성이 높아진다. - 공통 UI를 빠르고 안정적으로 구현할 수 있다. - 대신 사전에 정해진 동작과 스타일이 많아져 특수한 요구에는 덜 유연할 수 있다. ## 계층 안의 계층 - 하나의 계층도 목적에 따라 여러 하위 계층으로 나눌 수 있다. - Thumbprint의 React 모달은 다음처럼 구성된다. - `ModalCurtain`: 시각적 스타일보다 사용성·기능에 집중한 낮은 계층 컴포넌트 - `Modal`: `ModalCurtain`을 기반으로 시각적 스타일과 일반적인 모달 사용 방식을 제공하는 상위 컴포넌트 - 대부분의 개발자는 바로 사용할 수 있는 `Modal`을 사용한다. - `Modal`이 지나치게 제한적일 때는 `ModalCurtain`으로 내려가 더 자유롭게 구성할 수 있다. - 이후 반복적으로 필요한 기능은 다시 상위 `Modal`에 추가해 시스템을 발전시킬 수 있다. ## 디자인 토큰의 다단계 추상화 - 디자인 토큰도 여러 단계로 상속·추상화할 수 있다. - Adobe Spectrum의 예처럼: - `button-cta-background-color` - `cta-background-color` - `blue-400` - 토큰이 구체적인 의미에서 일반적인 색상 값으로 이어지는 구조다. - 개발자는 자신의 상황에 적용 가능한 가장 높은 수준의 토큰을 사용하는 것이 일반적이다. - 이를 통해 제품별 요구에는 대응하면서도 디자인 언어의 일관성을 유지할 수 있다. ## 실용적인 적용 방향 Thumbprint의 방식은 모든 개발자가 가장 낮은 수준의 API를 직접 다루게 하는 대신, 기본적으로는 접근성과 생산성이 높은 컴포넌트를 제공하고 필요할 때만 Atomic CSS와 토큰으로 내려가도록 설계한다. 따라서 디자인 시스템을 만들 때는 단일 추상화 계층에 모든 요구를 담기보다, **일반적인 사용 사례를 위한 높은 계층과 예외적인 요구를 위한 낮은 계층을 함께 제공하는 구조**가 효과적이다.

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

React디자인 시스템접근성디자인 토큰+3

figma·2023년 5월 15일·3분 읽기큐레이션 요약

그잼 스크린 리더

FigJam은 스크린 리더와 키보드만으로 캔버스의 콘텐츠를 읽고 만들 수 있도록 지원을 공식 출시했다. 사용자는 캔버스와 메뉴 사이를 이동하며 파일 구조, 텍스트가 포함된 도형, 스티키, 표, 이미지 대체 텍스트를 확인·편집할 수 있다. 다만 커서 채팅, 투표, 위젯, 자유형 벡터 편집 등 일부 기능은 아직 지원되지 않으며, Figma는 실제 사용자 피드백을 바탕으로 접근성을 계속 확장할 계획이다. ## 협업 도구 전체를 위한 접근성 - FigJam은 아이디어를 정리하고 의사결정을 맞추는 협업 중심 도구이므로, 팀 구성원 모두가 참여할 수 있어야 한다는 판단에서 접근성 개선 대상이 됐다. - Figma 프로토타입에 스크린 리더 지원을 도입한 뒤, 다음 단계로 FigJam을 선택했다. - 정밀한 디자인 도구인 Figma보다 FigJam은 기능이 상대적으로 표면에 드러나 있어, 접근 가능한 UI 패턴을 실험하기에 적합했다. ## 스크린 리더로 가능한 작업 - 스크린 리더 및 키보드 사용자는 캔버스의 여러 요소와 메뉴·화면 사이에서 포커스를 이동할 수 있다. - 다음 콘텐츠를 읽고 생성·편집할 수 있다. - FigJam 파일의 구조 - 텍스트가 포함된 도형 - 스티키 노트 - 표 - 이미지의 대체 텍스트 - 캔버스에서는 콘텐츠를 문자 그대로 읽는 것뿐 아니라, 계층 구조와 캔버스 내 위치를 통해 맥락도 파악해야 한다. - 아직 지원되지 않는 기능에는 커서 채팅 탐색, 스탬프 조정, 투표, 이모트 휠, 위젯 상호작용, 선·하이라이트·와시 테이프·마커 같은 자유형 벡터 노드 편집이 포함된다. ## ARIA 표준만으로는 부족했던 캔버스 접근성 - WAI-ARIA는 웹 콘텐츠와 애플리케이션의 접근성과 상호운용성을 높이기 위한 기술 명세다. - 일반적인 웹사이트나 단순한 위젯과 달리, Figma·FigJam 같은 캔버스 기반 도구에는 참고할 만한 접근성 패턴과 모범 사례가 충분하지 않았다. - 따라서 팀은 처음부터 정해진 구현 방식을 따르기보다, 실제로 도구를 사용할 수 있게 만드는 핵심 기능이 무엇인지 먼저 정의했다. - 접근성 테스트 기관 Fable과 협력해 보조공학 사용자들의 테스트와 피드백을 수집했다. - 일부 베타 테스터는 디지털 화이트보드나 실제 화이트보드 경험도 없었기 때문에, 기존 도구의 사용 패턴을 전제로 하지 않고 사용자 여정을 새롭게 설계했다. ## 다양한 키보드와 보조공학 환경 고려 - 스크린 리더 종류, 설정, 보조공학 기술, 국제 키보드 배열에 따라 사용 가능한 조합이 매우 다양하다. - 베타 인터뷰를 통해 팀은 스크린 리더 사용 방식에 대해 지속적으로 새로운 사실을 발견했다. - 이 과정에서 얻은 패턴은 FigJam뿐 아니라 Figma 전반의 접근성 개선에도 활용됐다. - React 컴포넌트에 ARIA 레이블과 태그를 적용하는 등, 코드베이스에 재사용 가능한 접근성 패턴을 구축했다. - 한 번 만들어진 패턴은 다른 엔지니어들도 반복해서 적용할 수 있어 제품 전체의 접근성 향상에 기여한다. ## 단계적 출시와 향후 과제 - 캔버스 기반 협업 도구의 접근성에는 확립된 정답이 부족했기 때문에, 초기 출시 범위를 핵심 사용자 여정 중심으로 정했다. - 제품을 한 번에 완성하기보다 실제 사용과 채택 데이터를 통해 부족한 부분을 확인하고 개선하는 방식을 택했다. - 특히 여러 사용자가 동시에 상호작용하는 커서 채팅 같은 멀티플레이어 기능은 스크린 리더 환경에 적합한 모델을 추가로 연구해야 한다. - 이번 출시는 전체 접근성 작업의 끝이 아니라, 이후 기능 확장을 위한 기반에 가깝다. 실제로 FigJam 파일을 만들 때는 요소에 명확한 텍스트와 이미지 대체 텍스트를 제공하고, 콘텐츠의 계층과 위치를 일관되게 구성하는 것이 좋다.

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

Reactfigjamkeyboard-navigationscreen-readers+2

figma·2021년 10월 13일·4분 읽기큐레이션 요약

LiveGraph: Figma의 실시간

Figma는 실시간 협업 제품에 필요한 데이터를 안정적으로 제공하기 위해 Postgres 위에 GraphQL 기반의 실시간 데이터 계층인 LiveGraph를 구축했다. LiveGraph는 프론트엔드가 선언적으로 데이터를 구독하면 데이터베이스 복제 스트림을 읽어 밀리초 단위로 변경 사항을 반영한다. 이를 통해 수동 이벤트 메시지와 클라이언트 상태 동기화의 복잡성을 줄이고, 대규모 실시간 데이터 구독을 지원한다. ## Figma에서 실시간 데이터가 필요한 이유 - 협업자가 파일을 추가하거나 권한을 변경하면 다른 사용자 화면에도 새로고침 없이 즉시 반영되어야 한다. - 따라서 서버에서 데이터를 한 번 가져오는 것만으로는 부족하며, 클라이언트가 현재 관심 있는 데이터의 변경 사항을 계속 받아야 한다. - 인프라 팀의 목표는 제품 개발자가 데이터 전파 방식이나 WebSocket 세부 구현을 직접 관리하지 않고도 실시간 뷰를 만들 수 있게 하는 것이었다. ## 기존 방식의 한계 - 초기에는 React 프론트엔드가 Ruby HTTP 엔드포인트에서 필요한 데이터를 한 번에 받아 Redux 전역 상태에 저장했다. - 데이터 변경 시 백엔드 코드에서 관련 클라이언트에 보낼 이벤트 메시지를 직접 작성하고, 프론트엔드는 WebSocket으로 이벤트를 받아 상태를 갱신했다. - 사용자와 데이터 규모가 커지면서 모든 데이터를 한 번에 로드하기 어려워졌고, 데이터를 점진적으로 불러오면서 다음 문제가 발생했다. - 특정 데이터가 메모리에 항상 존재한다는 보장이 없어짐 - 여러 제품 영역이 같은 데이터를 사용할 때 데이터 로딩 책임이 불분명해짐 - 이벤트를 어느 시점에 보내고 받아야 하는지 관리하기 어려워짐 - 단순한 “새 파일 생성” 이벤트와 달리 권한 변경은 다른 리소스의 가시성까지 연쇄적으로 바꿀 수 있어 이벤트 설계가 복잡했다. - 데이터베이스 쓰기 순서와 실시간 메시지의 송수신 순서가 항상 일치한다는 보장도 없었다. - 그 결과 클라이언트 상태가 서버 상태의 올바른 부분집합을 반영하지 못하는 일관성 버그가 발생했다. ## GraphQL 기반 Live Query 선택 - Figma는 개발자가 실시간 데이터 구독을 선언적으로 정의할 수 있는 일반적인 프레임워크가 필요하다고 판단했다. - GraphQL을 인터페이스로 사용하면 필요한 데이터와 관계를 쿼리로 표현하고, 시스템이 해당 데이터를 자동으로 가져오고 최신 상태로 유지할 수 있다. - 여기서 말하는 GraphQL 구독은 일반적인 이벤트 스트림 구독과 다르다. - GraphQL의 전통적인 `subscription`은 이벤트 메시지를 전달하는 방식에 가깝다. - LiveGraph가 목표로 한 것은 쿼리 결과 자체를 계속 갱신하는 “Live Query” 방식이다. - 프론트엔드는 GraphQL과 유사한 쿼리를 보내고, 서버는 결과를 JSON 트리로 반환한다. - 서버에는 엔터티와 관계를 정의하는 스키마 및 그래프의 일부를 조회할 수 있는 뷰가 존재한다. ## 기존 실시간 데이터베이스 대신 자체 구축한 이유 - Figma는 이미 Postgres를 대규모로 운영하고 있었기 때문에 Firebase나 RethinkDB 같은 별도의 실시간 데이터베이스로 이전할 수 없었다. - LiveGraph는 새로운 저장소가 아니라 기존 Postgres 위에 동작하는 쿼리 엔진이 되어야 했다. - Figma의 Multiplayer 시스템은 파일 단위의 쓰기와 충돌 해결을 담당하지만, LiveGraph는 여러 데이터의 조회와 실시간 동기화를 담당한다. - Hasura, Prisma, PostGraphile 등 GraphQL 기술도 검토했지만, 대규모 동시 구독을 핵심 요구사항으로 설계된 것은 아니었다. - Figma는 실시간 구독 수가 많아질수록 데이터베이스 부하가 커지는 폴링 방식도 피하고자 했다. - 폴링은 쿼리마다 주기를 정해야 한다. - 구독 수가 늘어나면 동일한 쿼리가 반복 실행되어 데이터베이스 부하가 증가한다. - 폴링보다 변경 발생 시점에 가까운 낮은 지연 시간을 확보하기 어렵다. ## 데이터베이스 복제 스트림 기반 설계 - LiveGraph는 주기적으로 데이터를 다시 조회하는 대신 Postgres의 데이터베이스 복제 로그를 추적한다. - 복제 스트림에서 변경 사항을 읽으면 실제 데이터베이스 변경을 감지한 뒤 구독 중인 쿼리 결과를 갱신할 수 있다. - 이 방식은 폴링보다 빠른 업데이트 지연 시간을 제공한다. - 다만 LiveGraph가 데이터베이스의 전체 변경량을 읽어야 하므로, 대규모 환경에서는 확장성이 중요하다. - Figma는 여러 데이터베이스 샤드의 변경 사항을 여러 머신에 분산 처리할 수 있는 구조를 고려했다. - 최종적으로 LiveGraph를 자체 구축한 이유는 Figma의 협업 기능에서 실시간 데이터가 핵심 기능이며, 이러한 요구사항이 경쟁력으로 이어질 수 있다고 판단했기 때문이다. ## 실용적인 결론 실시간 UI를 구축할 때 클라이언트별 수동 이벤트와 전역 상태 갱신에 의존하면 데이터 규모와 기능 복잡도가 커질수록 일관성 문제가 발생하기 쉽다. 기존 Postgres를 유지해야 하고 대규모 구독이 필요하다면, GraphQL 기반 선언적 쿼리와 데이터베이스 변경 스트림을 결합하는 방식이 폴링이나 수동 이벤트보다 확장성과 유지보수성 측면에서 유리하다.

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

ReactPostgreSQLTypeScriptGraphQL+4

figma·2021년 8월 24일·2분 읽기큐레이션 요약

Figma의 새로운 소

Figma는 2021년 8월 업데이트에서 FigJam의 확장성과 Figma 플러그인 개발 역량을 강화하고, 디자인 시스템 관리와 반복 작업을 간소화했다. 특히 FigJam 플러그인·위젯, 프로토타이핑 자동화를 위한 API, 라이브러리 관리 기능이 추가되어 협업과 디자인 운영의 효율성이 높아졌다. 또한 투명 객체의 그림자 처리와 직선 그리기처럼 일상적인 사용성도 개선했다. ## FigJam 플러그인과 위젯 도입 - FigJam에 Figma의 오픈 플랫폼을 확장해 팀별 협업 방식에 맞는 기능을 직접 만들 수 있게 했다. - **플러그인** - 개인 작업을 자동화하고 효율화하는 도구다. - 스타일 사용자 지정, 스티키 정리, 데이터 가져오기 등에 활용할 수 있다. - **위젯** - 여러 사용자가 캔버스에서 함께 조작하는 인터랙티브 객체다. - 투표, 설문, 메모장, 게임 등을 제공해 워크숍과 브레인스토밍 진행을 돕는다. - 기본 HTML·JavaScript 지식이 있으면 플러그인을, React 경험이 있으면 위젯을 개발할 수 있도록 진입 장벽을 낮췄다. - 플러그인은 모든 요금제 사용자가 개발할 수 있었고, 위젯은 당시 비공개 베타로 제공됐다. ## Figma 플러그인 API 확장 - **프로토타이핑 쓰기 기능** - 플러그인이 프로토타입을 자동 생성하거나 기존 인터랙션을 대량으로 수정할 수 있게 됐다. - 반복적인 프로토타입 제작과 상호작용 설정을 자동화할 수 있다. - **플러그인 파라미터** - 별도의 사용자 인터페이스를 만들지 않고도 Quick Actions를 통해 사용자 입력을 받을 수 있다. - 플러그인 개발 시간이 줄고, 간단한 입력 기반 도구를 더 빠르게 만들 수 있다. - 당시 오픈 베타로 제공됐다. ## 디자인 시스템 관리 개선 - **컴포넌트 이동** - 게시된 컴포넌트와 컴포넌트 세트를 파일 간에 이동할 수 있다. - 이동 후에도 기존 인스턴스와의 연결이 유지된다. - 대형 라이브러리를 여러 파일로 분리하거나 새 파일로 이전하기 쉬워졌다. - **라이브러리 교체** - 스타일과 컴포넌트를 하나씩 변경하지 않고, 전체 라이브러리 세트를 다른 라이브러리로 교체할 수 있다. - **컴포넌트 검색** - `Shift + I` 단축키로 필요한 컴포넌트를 빠르게 검색할 수 있다. - 규모가 큰 디자인 시스템에서 탐색 시간을 줄여준다. ## 일상적인 사용성 개선 - 투명 객체가 뒤에 있는 그림자를 기본적으로 가리도록 변경되어, 별도로 설정을 조정할 필요가 줄었다. - Figma와 FigJam에서 연필 도구 사용 시 `Shift`를 누르면 직선을 그릴 수 있다. - 그 밖의 버그 수정과 개선 사항은 Figma 릴리스 노트에서 확인할 수 있도록 안내했다. 실무에서는 컴포넌트 라이브러리를 기능별 파일로 분리하고, 라이브러리 교체 기능과 플러그인 자동화를 함께 활용하면 디자인 시스템 유지보수 비용을 줄일 수 있다. FigJam에서는 투표나 설문 위젯을 활용해 회의 진행과 의사결정을 구조화할 수 있다.

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

ReactFigma디자인 시스템figjam+3

figma·2021년 8월 23일·3분 읽기큐레이션 요약

FigJam에 도입된 오픈 플랫폼의

FigJam은 Figma의 개방형 플랫폼을 확장해 플러그인과 위젯을 누구나 만들 수 있도록 지원한다. 플러그인은 반복 작업과 데이터 처리를 자동화하고, 위젯은 투표·설문·게임처럼 여러 사용자가 동시에 상호작용하는 협업 경험을 제공한다. 두 API 모두 JavaScript·HTML 또는 React 지식을 바탕으로 쉽게 시작할 수 있도록 설계되었다. ## Figma 플러그인에서 FigJam으로 확장 - Figma는 약 2년 전부터 플러그인을 통해 외부 데이터 연동, 워크플로 자동화, 디자인 프로세스 개선을 지원했다. - 핵심 원칙은 “웹사이트를 만들 수 있다면 플러그인도 만들 수 있어야 한다”는 것이다. - 따라서 기본적인 JavaScript와 HTML 지식만으로도 플러그인 개발을 시작할 수 있도록 API의 진입장벽을 낮췄다. - FigJam에도 같은 개방형 플랫폼 원칙을 적용하되, 협업 중심의 사용 사례를 추가로 고려했다. ## 플러그인과 위젯의 역할 차이 - **플러그인** - 개인 또는 팀의 작업 흐름을 자동화한다. - CSV 데이터를 스티키 노트 격자로 변환하거나, 스티키 노트에 태그를 붙이는 작업 등을 처리할 수 있다. - 보드의 객체를 정리·분석하거나 외부 콘텐츠를 가져오는 데 적합하다. - **위젯** - FigJam 보드에 직접 배치해 여러 사용자가 함께 조작하는 인터랙티브 객체다. - 투표, 설문, 게임 등 협업형 기능을 구현할 수 있다. - 사용자가 보드에 드래그 앤 드롭해 사용할 수 있다. ## React 기반의 선언형 위젯 API - 위젯 API는 플러그인 API와 달리 선언적·함수형 방식으로 설계되었다. - `<Frame />`, `<Rectangle />`, `<Text />`, `<SVG />` 같은 컴포넌트로 위젯의 화면 구조를 정의한다. - 클릭 이벤트와 같은 사용자 상호작용에 임의의 코드를 연결할 수 있다. - FigJam의 기본 객체처럼 인라인 속성 메뉴도 제공할 수 있다. - React 컴포넌트와 유사한 구조를 사용하며, 컴포넌트 속성은 CSS의 레이아웃·스타일 속성과 비슷하다. - 예시 카운터 위젯은 다음 방식으로 동작한다. - `useSyncedState('count', 0)`으로 여러 사용자에게 동기화되는 상태를 만든다. - 사용자가 숫자를 클릭하면 `setCount(count + 1)`을 호출해 값을 증가시킨다. - `Frame`으로 자동 레이아웃과 패딩을 지정하고, `Text`로 현재 값을 표시한다. - `widget.register(SimpleCounter)`로 위젯을 등록한다. ## FigJam 플러그인의 주요 활용 분야 ### 보드 정리와 인사이트 도출 - 보드의 객체를 체계적으로 정리하고 분석할 수 있다. - 스티키 노트를 색상별로 정렬하거나 카테고리용 태그를 추가할 수 있다. - 스티키 노트의 내용을 분석해 워드 클라우드처럼 주제를 시각화할 수 있다. - 투표 수를 자동으로 집계하는 스탬프 카운터 플러그인도 활용 사례로 제시된다. - 텍스트를 입력하면 여러 개의 스티키 노트를 자동 생성하는 플러그인도 소개된다. ### 반복 작업 자동화 - 맞춤법 검사, 찾기 및 바꾸기 같은 수작업을 줄일 수 있다. - 동일한 스타일의 스티키 노트 100개를 한 번에 만드는 등 반복적인 작업을 자동화할 수 있다. - 사용자는 여러 단계를 직접 수행하는 대신 몇 번의 클릭만으로 작업을 완료할 수 있다. - Figma에서 사용되던 맞춤법 검사 플러그인을 FigJam으로 확장하는 사례가 언급된다. ### 콘텐츠 라이브러리 연동 - 외부 서비스나 라이브러리의 콘텐츠를 FigJam 보드로 가져올 수 있다. - 아이콘, 이모지, 회사 로고 등을 빠르게 삽입하는 플러그인을 만들 수 있다. - Icons8, Material Design, Iconify, Brandfetch 등 기존 Figma 콘텐츠 플러그인의 FigJam 확장이 사례로 제시된다. - 이를 통해 FigJam 사용자는 별도의 검색·복사 과정 없이 보드 안에서 필요한 시각 자료를 활용할 수 있다. ### 사용자 맞춤 설정 - 사용자가 원하는 색상, 폰트, 텍스트 스타일 등을 선택할 수 있는 기능도 플러그인 활용 분야로 제시된다. - FigJam은 기본적으로 폰트와 색상 체계를 단순하게 유지하지만, 사용자 요구에 따른 커스터마이징 수요가 존재한다. ## 실용적인 시사점 FigJam에서 자동화가 필요하면 플러그인을, 여러 사람이 동시에 조작하는 기능이 필요하면 위젯을 선택하는 것이 적합하다. 특히 React에 익숙한 개발자는 FigJam 레이어와 CSS와 유사한 컴포넌트 구조를 활용해 비교적 빠르게 인터랙티브 협업 도구를 만들 수 있다.

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

ReactfigjamJavaScriptAPI+4

figma·2020년 8월 18일·3분 읽기큐레이션 요약

60fps의 React: Figma

Figma는 캔버스에서 댓글 핀이 이동할 때 발생하던 불필요한 React 렌더링을 줄여 스크롤 성능을 약 3배 개선했다. 댓글 수와 무관하게 편집기를 60fps에 가깝게 동작시키는 것이 목표였으며, Chrome Performance 도구와 React Profiler로 병목이 JavaScript 실행과 컴포넌트 재렌더링에 있음을 확인했다. 핵심 해결책은 뷰포트 변화에 실제로 영향을 받는 댓글 컴포넌트만 업데이트하고, 댓글 위치 계산과 변환 처리를 최적화하는 것이었다. ## 60fps를 목표로 한 댓글 스크롤 - Figma의 댓글은 캔버스 위 특정 위치에 고정된 “댓글 핀”으로 표시된다. - 사용자가 캔버스를 이동하거나 확대·축소하면 댓글 핀도 뷰포트에 맞춰 계속 위치를 다시 계산해야 한다. - 15fps나 30fps보다 60fps가 훨씬 부드러운 사용자 경험을 제공하므로, 댓글과 스레드가 많아져도 일정한 성능을 유지하는 것이 목표였다. - 댓글 사용량이 증가하면서 대규모 팀과 파일에서 캔버스 반응성이 저하되기 시작했다. ## WebGL 캔버스와 React 댓글 UI의 구조 - Figma 편집기는 WebGL과 WebAssembly를 사용하는 “브라우저 안의 브라우저”에 가까운 구조다. - 일부 사용자 인터페이스는 TypeScript와 React로 구현되어 있지만, 일반적인 정적 React 화면과 달리 댓글은 캔버스의 이동과 확대·축소에 따라 동적으로 움직인다. - 편집기의 뷰포트 정보는 Redux에 저장된다. - 댓글 핀 컴포넌트는 Redux에서 뷰포트 정보를 가져와 캔버스 좌표를 화면에 표시할 위치로 변환한다. - 뷰포트가 변경될 때마다 React 컴포넌트 트리 일부가 업데이트되므로, 업데이트 범위가 성능에 직접적인 영향을 준다. ## 성능 분석에서 발견한 병목 - Chrome Performance 도구에서 대부분의 프레임 시간이 렌더링이나 페인팅이 아니라 JavaScript 실행에 사용되는 것으로 나타났다. - 댓글 30개인 화면에서 프레임당 약 68ms가 JavaScript에 소비되었고, 실제 화면은 약 19fps로 렌더링됐다. - React Profiler에서는 댓글 화면 자체의 렌더링에는 약 1.8ms만 사용되고 있었다. - 대신 뷰포트 변화와 직접 관련 없는 다음 컴포넌트들이 함께 재렌더링됐다. - 왼쪽 패널 - 툴바 - 속성 패널 - 기타 고정 위치 UI - 즉, 댓글 내용 렌더링보다 “변화가 없는 컴포넌트까지 다시 렌더링하는 것”이 더 큰 비효율이었다. ## 불필요한 재렌더링 줄이기 - 뷰포트 업데이트는 댓글 핀의 위치에는 필요하지만, 화면에 고정된 패널이나 툴바에는 필요하지 않다. - 따라서 뷰포트 상태를 사용하는 컴포넌트의 범위를 댓글 영역으로 제한해야 한다. - React 애플리케이션이 커질수록 상위 컴포넌트의 상태 변화가 하위 전체로 전파되면서 불필요한 렌더링이 발생하기 쉽다. - React Profiler로 실제로 다시 렌더링되는 컴포넌트를 확인하면, 직관만으로 찾기 어려운 병목을 구체적으로 식별할 수 있다. - 성능 개선은 댓글 컴포넌트 자체를 빠르게 만드는 것뿐 아니라, 댓글과 무관한 컴포넌트가 업데이트되지 않도록 컴포넌트 구조와 상태 구독 방식을 조정하는 데서 시작됐다. ## 댓글 핀 위치 변환 최적화 - 댓글 핀은 뷰포트가 바뀔 때마다 캔버스 좌표를 화면 좌표로 변환해야 한다. - 이 변환 과정이 매 업데이트마다 React 렌더링과 결합되면 JavaScript 실행 비용이 커질 수 있다. - Figma는 불필요한 컴포넌트 업데이트를 제거한 뒤 댓글 핀의 변환 처리도 최적화해, 캔버스 이동 중 위치 계산과 화면 반영 비용을 줄였다. - 결과적으로 댓글 스크롤 FPS가 기존보다 약 3배 향상됐다. ## 실용적인 결론 - React 성능 문제에서는 먼저 “컴포넌트 하나의 렌더링 속도”보다 “불필요하게 다시 렌더링되는 컴포넌트가 무엇인지”를 확인하는 것이 효과적이다. - Chrome Performance 도구로 프레임별 JavaScript 비용을 확인하고, React Profiler로 재렌더링 범위를 분석하는 조합이 유용하다. - 자주 변하는 상태는 실제로 그 상태가 필요한 컴포넌트 가까이에 두고, 고정 UI가 동적 상태 변화에 구독되지 않도록 설계하는 것이 좋다.

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

ReactTypeScriptwebassemblywebgl+2

figma·2019년 9월 5일·4분 읽기큐레이션 요약

5명의 플러그인 개발자가

Figma의 첫 Plugin Show & Tell은 커뮤니티 개발자들이 제작 중인 플러그인을 직접 시연하고, 새로운 기능과 개발 방향을 공유하는 라이브 행사였다. 디자인 시스템 검사, 맞춤법 검사, 아이콘 관리, 문서 연결, 음성 제어 등 플러그인이 Figma의 작업 자동화와 확장성을 크게 넓힐 수 있음을 보여준다. 글은 행사를 소개하는 데 그치지 않고, 더 많은 개발자가 Figma Plugin API에 참여하도록 관련 자료와 커뮤니티를 안내한다. ## Plugin Show & Tell의 목적 - Figma 플러그인 커뮤니티의 창의적인 작업을 소개하기 위해 처음 개최된 라이브 스트리밍 행사다. - 개발자들이 플러그인을 홍보하고, 사용자가 새로운 API와 활용 방법을 탐색하도록 돕는 것이 목적이다. - 완성된 플러그인뿐 아니라 개발 중인 기능과 향후 로드맵도 공유했다. - 녹화 영상에서는 5명의 개발자가 디자인 시스템 검사부터 Figma 음성 제어까지 다양한 사례를 시연했다. ## 디자인 시스템과 품질 관리 자동화 - Toybox의 Jono Kolnik은 개발 중인 **Roller**를 소개했다. - Roller는 디자인을 디자인 시스템과 비교해 오류와 불일치를 찾고 수정하도록 돕는다. - 반복적인 수동 검수 대신 플러그인이 디자인 규칙을 검사함으로써 일관성을 유지할 수 있다. - 디자인 시스템이 커질수록 색상, 간격, 컴포넌트 사용 규칙을 자동으로 점검하는 도구의 가치가 커진다. ## 맞춤법 검사와 외부 서비스 연동 - Tekeste Kidanu는 Figma 안에서 사용하는 **Spell Check** 플러그인을 시연했다. - 프로젝트의 텍스트를 검사해 디자인 문서의 오탈자를 줄이는 데 활용할 수 있다. - 자신의 서비스인 **Cleanmock**을 Figma 내부에서 사용할 수 있도록 연동한 사례도 소개했다. - 플러그인은 Figma 캔버스뿐 아니라 브라우저 API와 외부 서비스까지 연결하는 확장 지점이 될 수 있다. ## 대규모 아이콘 세트 관리 - Vjacheslav Trushkin은 **Iconify** 플러그인과 향후 계획을 공유했다. - Iconify를 사용하면 수백 개의 아이콘 세트를 Figma와 실제 제품 개발 과정에서 함께 활용할 수 있다. - 디자인 단계에서 선택한 아이콘을 production 환경까지 일관되게 연결하는 워크플로를 지향한다. - 방대한 아이콘 라이브러리를 검색하고 관리하는 문제를 플러그인으로 단순화한다. ## 검색·문서화·레이아웃 작업 개선 - Jackie Chui는 여러 생산성 플러그인의 개선 사항을 소개했다. - **Find & Replace**는 Figma 문서 안의 내용을 빠르게 검색하고 바꾸는 기능을 제공한다. - **Link to Documentation**은 컴포넌트에 관련 문서 링크를 추가해 디자인과 가이드 문서를 연결한다. - **Paste to Fill**은 붙여넣은 이미지를 이미지 채우기로 적용한다. - 프레임 안 오브젝트의 여백과 크기를 관리하는 플러그인은 사용자 지정 프리셋을 지원할 예정이었다. - 이러한 도구들은 반복적인 레이아웃 조정과 문서 탐색 작업을 줄이는 데 초점을 둔다. ## 타이포그래피 규칙과 음성 인터페이스 - Andrew Goodwin은 타이포그래피 규칙을 선택하고 적용하는 플러그인을 선보였다. - 사용자가 정해진 글꼴, 크기, 행간 등의 규칙을 적용해 텍스트 스타일을 일관되게 관리할 수 있다. - Figma를 음성 명령으로 조작하는 음성 UI도 시연했다. - Figma Plugin API의 기능 대부분을 음성 명령으로 매핑하는 작업이 거의 완료 단계라고 설명했다. - 이는 플러그인이 시각적 UI를 넘어 새로운 입력 방식과 접근성 기능까지 제공할 수 있음을 보여준다. ## 플러그인 개발을 위한 생태계 - Figma는 플러그인 개발을 시작할 수 있도록 다음 자료를 제공했다. - 플러그인의 기본 구조와 개발 환경 설정을 설명하는 Getting Started 문서 - 캔버스와 상호작용하는 공식 Plugin API 문서 - Figma UI와 유사한 HTML·JavaScript·CSS 기반의 Figma Plugin DS - 오픈소스 플러그인 코드 목록 - TypeScript, React/JSX, 번들링, 매니페스트 생성을 지원하는 FigPlug - 개발자들이 질문과 작업물을 공유하는 Figma Plugins Slack 커뮤니티 - 조직 내부에서만 사용하는 비공개 플러그인도 팀별 워크플로 자동화에 활용할 수 있다고 안내한다. ## 실용적인 결론 Figma 플러그인은 단순한 편의 기능을 넘어 디자인 시스템 검증, 콘텐츠 품질 관리, 외부 데이터 연동, 접근성 개선, 개발 프로세스 연결까지 확장할 수 있다. 반복 작업이나 팀 고유의 규칙이 있다면 Plugin API와 오픈소스 사례를 참고해 사내 전용 플러그인부터 작게 만들어보는 것이 현실적인 접근이다.

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

ReactTypeScriptJavaScriptCSS+4

figma·2019년 8월 21일·5분 읽기큐레이션 요약

웹에서 플러그인 시스템

Figma는 서드파티 플러그인을 브라우저 기반 디자인 편집기 안에서 실행하면서도 보안·안정성·성능을 모두 확보해야 했다. 단순히 `eval(PLUGIN_CODE)`를 사용하는 것은 위험하고, 기존 플러그인처럼 플랫폼 성능을 저하시키거나 업데이트 때마다 깨지는 문제도 피해야 했다. 여러 접근을 검토한 결과, 당시에는 JavaScript `Realm` 기반 샌드박스를 선택했지만, 이후 보안 취약점 공개를 계기로 C로 작성된 JavaScript VM을 WebAssembly로 컴파일하는 방식으로 변경했다. ## 플러그인 시스템이 해결해야 할 제약 - 플러그인은 접근성 검사, 번역, 색상 도구, 이미지 가져오기 등 사용자가 작성한 임의의 코드를 실행한다. - 플러그인이 Figma 편집기의 내부 데이터와 기능을 사용해야 하므로, 단순한 외부 웹페이지처럼 완전히 격리할 수는 없다. - 동시에 플러그인이 다음 영역에 영향을 주면 안 된다. - Figma 문서나 다른 사용자의 데이터에 대한 무단 접근 - 편집기 UI와 실행 환경의 안정성 - CPU·메모리 등 시스템 자원의 과도한 사용 - Figma 업데이트에 따른 플러그인 호환성 저하 - Figma는 WebGL, WebAssembly, TypeScript, React, 실시간 협업 기능을 함께 사용하는 구조라 일반적인 웹 애플리케이션보다 실행 환경이 복잡했다. ## 시도 1: `<iframe>` 샌드박스 - 가장 표준적이고 검증된 웹 보안 기능인 `<iframe>`을 플러그인 실행 환경으로 검토했다. - iframe은 별도의 문서와 JavaScript 실행 컨텍스트를 제공해 플러그인 코드가 Figma의 전역 객체나 DOM에 직접 접근하지 못하게 할 수 있다. - `sandbox` 속성과 출처(origin) 분리를 사용하면 플러그인과 호스트 애플리케이션 사이의 경계를 강화할 수 있다. - 플러그인과 Figma 사이의 통신은 `postMessage` 같은 명시적인 메시지 전달 방식으로 제한할 수 있다. - 그러나 iframe 방식에는 중요한 한계가 있었다. - Figma 내부 데이터 구조에 대한 빠르고 자연스러운 접근이 어렵다. - 플러그인 API 호출을 위해 많은 객체와 요청을 직렬화·전달해야 한다. - 별도 브라우저 컨텍스트를 만들기 때문에 성능과 메모리 비용이 발생한다. - iframe 자체가 안전하더라도 플러그인이 CPU나 메모리를 과도하게 사용해 편집기를 느리게 만들 가능성은 남는다. - 따라서 일반적인 웹 위젯에는 적합하지만, Figma처럼 고성능 편집기와 긴밀하게 상호작용해야 하는 플러그인 환경에는 충분하지 않았다. ## 시도 2: JavaScript 인터프리터를 WebAssembly로 컴파일 - 두 번째 접근은 플러그인 코드를 브라우저의 JavaScript 엔진에서 직접 실행하지 않고, 별도의 JavaScript 인터프리터 안에서 실행하는 방식이었다. - 인터프리터를 WebAssembly로 컴파일하면 플러그인 코드는 Figma의 실제 JavaScript 환경과 분리된 가상 실행 환경에서 동작한다. - 이 방식의 장점은 다음과 같다. - 플러그인이 브라우저의 전역 객체, DOM, Figma 내부 구현에 직접 접근할 수 없다. - 노출할 API를 명시적으로 선택할 수 있다. - 실행 환경을 통제하고 향후 브라우저 변경의 영향을 줄일 수 있다. - 반면 별도의 JavaScript 인터프리터를 실행해야 하므로 일반 JavaScript보다 느릴 수 있다. - 표준 JavaScript 기능과 내장 객체를 정확하게 구현해야 하며, 언어 호환성 문제도 발생한다. - 인터프리터 자체의 구현 오류나 보안 취약점이 샌드박스를 무너뜨릴 가능성도 고려해야 했다. - 당시에는 성능과 구현 복잡성이 주요 장애물이었다. ## 시도 3: JavaScript Realm - 세 번째 접근은 별도의 전역 환경과 객체 영역을 만드는 `Realm` 개념이었다. - Realm은 플러그인이 Figma의 전역 객체와 분리된 JavaScript 환경에서 실행되도록 하면서도, 필요한 API만 선택적으로 제공할 수 있게 한다. - iframe보다 가볍고, 별도 JavaScript 인터프리터를 내장하는 방식보다 브라우저의 기본 실행 성능을 더 많이 활용할 수 있다. - Figma는 다음과 같은 형태의 경계를 구성할 수 있었다. - 플러그인에 필요한 API만 노출 - 호스트 객체와 플러그인 객체 사이의 직접 참조 제한 - 허용된 요청만 Figma 내부 기능으로 전달 - 플러그인 전역 환경과 Figma 전역 환경의 분리 - 이 접근은 보안, 성능, API 사용성 사이의 균형이 가장 좋다고 판단되어 원래 구현에 채택됐다. - 다만 Realm은 당시 표준 기능으로 완전히 지원된 것이 아니라 shim에 의존해야 했다. - JavaScript 객체 모델과 프로토타입 체인을 완벽하게 격리하는 것은 매우 어려워, shim의 작은 결함도 보안 취약점으로 이어질 수 있었다. ## 운영 과정에서 드러난 보안 문제와 변경 - 글 게시 후 Realm shim에서 보안 취약점이 비공개로 제보됐다. - 취약점은 공개되기 전에 shim 팀에 의해 수정됐고, Figma는 실제 악용 증거를 발견하지 못했다고 밝혔다. - 그러나 샌드박스의 핵심이 외부 라이브러리의 복잡한 JavaScript 격리에 의존한다는 점은 중요한 위험 요소였다. - Figma는 이후 C로 작성된 JavaScript VM을 WebAssembly로 컴파일하는 대안으로 구현을 변경했다. - 이 방식은 브라우저의 JavaScript 객체와 실행 컨텍스트를 더 강하게 분리해, Realm shim에 의존하는 공격 표면을 줄이는 방향이다. ## 설계에서 얻은 교훈 - 서드파티 코드를 안전하게 실행하는 문제는 단순히 `eval`을 다른 API로 바꾸는 문제가 아니다. - 격리 수준, API 호출 비용, 실행 성능, 자원 제한, 유지보수성을 함께 평가해야 한다. - “브라우저 기능을 사용하므로 자동으로 안전하다”거나 “샌드박스이므로 모든 문제가 해결된다”고 볼 수 없다. - 특히 샌드박스 구현 자체가 복잡한 경우, 해당 구현의 취약점과 업데이트 정책까지 시스템의 보안 경계로 봐야 한다. - 가장 현실적인 설계는 플러그인에 필요한 최소 API만 노출하고, 실행 환경과 호스트 애플리케이션 사이의 통신을 명확한 경계로 제한하는 것이다. 플러그인 시스템을 설계할 때는 iframe, 별도 인터프리터, Realm 같은 선택지를 보안·성능·호환성 관점에서 비교해야 한다. 또한 외부 샌드박스 라이브러리에 의존한다면 정기적인 보안 검토와 교체 가능한 구조를 마련하고, 높은 보안 수준이 필요할 경우 WebAssembly 기반 독립 VM처럼 더 강한 실행 격리를 고려하는 것이 바람직하다.

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

ReactTypeScriptJavaScriptwebassembly+3

figma·2019년 6월 26일·3분 읽기큐레이션 요약

DesignSystems.com의 새로운

DesignSystems.com은 디자인 시스템을 만들고 운영하는 디자이너·개발자·관리자를 위한 지식 공유 플랫폼으로 자리 잡고 있다. 이 글은 2019년 6월에 공개된 주요 콘텐츠 네 가지를 소개하며, 아이콘 설계부터 접근성 높은 React 컴포넌트, 에이전시 협업, 화이트라벨링까지 디자인 시스템의 실무 범위를 보여준다. 핵심은 재사용성과 일관성을 유지하면서도 다양한 사용자와 제품 요구에 유연하게 대응하는 것이다. ## 아이콘 시스템 설계와 구현 - 아이콘 제작의 기본 원칙부터 개발자 전달까지 다루는 종합 가이드를 소개한다. - 주요 내용은 다음과 같다. - 아이콘의 스트로크와 필(fill) 설계 - Boolean 연산을 활용한 아이콘 제작 - 아이콘을 체계적으로 구성하고 관리하는 방법 - 개발자 핸드오프를 위한 파일 및 자산 준비 - 아이콘은 단순한 그래픽 요소가 아니라 디자인 시스템의 일관성과 사용성을 좌우하는 핵심 자산으로 설명된다. ## 에이전시 관점의 디자인 시스템 구축 - Instrument는 Nike, Google, Airbnb 등과 협업하며 일회성 결과물이 아닌 확장 가능한 디자인 시스템을 구축한다. - 재사용 가능한 기능성 컴포넌트를 여러 애플리케이션과 규모에 걸쳐 활용하는 것을 중시한다. - 디자인 시스템의 성공을 위해서는 다음 과정이 중요하다. - 클라이언트와 시스템의 목표 및 범위에 대한 공통 이해 형성 - 높은 수준의 협업을 통한 요구사항 조율 - 특정 프로젝트를 넘어 장기적으로 활용 가능한 구성요소 설계 - 디자인 시스템은 산출물 하나가 아니라 브랜드, 제품, 기술을 연결하는 협업 프로세스로 제시된다. ## 접근성을 공유하는 React 컨테이너 - Zendesk의 오픈소스 디자인 시스템 Garden은 접근성 및 키보드 조작을 공통 패턴으로 관리하기 위해 “컨테이너” 패턴을 사용한다. - 컨테이너는 화면 UI를 직접 렌더링하지 않고 다음 기능을 담당한다. - 키보드 및 마우스 상호작용 처리 - React 컴포넌트 간 접근성 로직 공유 - RTL(오른쪽에서 왼쪽으로 읽는 언어) 레이아웃 지원 - 새 라이브러리인 `react-containers`는 스타일이 포함된 전체 패키지를 설치하지 않아도 비시각적 로직만 사용할 수 있도록 별도 저장소로 분리됐다. - 기존 패턴보다 더 작고 효율적으로 다시 작성됐으며, WAI-ARIA Authoring Practices 1.1에 더욱 가깝게 구현됐다. ## 사용자에게 권한을 제공하는 화이트라벨링 - Dawn Labs는 제3자가 디자인 시스템을 직접 커스터마이즈할 수 있으면서도 제품 전체의 일관성을 유지해야 하는 문제를 다뤘다. - 사용한 기술은 다음과 같다. - `styled-components` - `styled-system` - GraphQL 백엔드 - CSS 변수와 전역 CSS 주입 - 기본 디자인 토큰과 구조는 통제하면서도, 최종 사용자가 클라이언트의 개입 없이 원하는 스타일을 수정할 수 있도록 “스타일링 탈출구”를 제공했다. - 화이트라벨 시스템은 일관된 기본 경험과 사용자별 커스터마이징 사이의 균형이 중요하다. ## 커뮤니티 중심의 지식 공유 - DesignSystems.com은 디자인 시스템 제작자, 디자이너, 개발자, 관리자가 경험과 실무 지식을 공유하는 것을 목표로 한다. - 다양한 분야의 기고를 통해 디자인 시스템을 시각 디자인에만 한정하지 않고 다음 영역까지 확장한다. - 접근성 - 컴포넌트 아키텍처 - 협업과 운영 - 사용자 커스터마이징 - 플랫폼의 성장은 운영팀뿐 아니라 커뮤니티 구성원의 사례와 기여에 기반한다. 디자인 시스템을 구축할 때는 재사용 가능한 컴포넌트와 명확한 시각 규칙뿐 아니라 접근성, 협업 프로세스, 확장 가능한 커스터마이징 구조까지 함께 설계하는 것이 좋다. 특히 공통 로직은 별도 모듈로 분리하고, CSS 변수나 디자인 토큰을 활용하면 일관성과 유연성을 동시에 확보할 수 있다.

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

React디자인 시스템접근성GraphQL+4

figma·2018년 11월 7일·3분 읽기큐레이션 요약

Figma에서 제약 조건과 매

LittleBits 팀은 여러 플랫폼과 화면 크기에 대응하기 위해 Figma의 제약 조건과 8px 기반의 ‘매직 넘버’ 시스템을 결합했다. 주요 크기와 여백을 일정한 배수로 통일하고, 화면 비율별 스케일링 규칙을 React 코드에도 적용해 하나의 템플릿으로 모바일·태블릿 레이아웃을 관리했다. 그 결과 작은 팀으로도 다양한 기기에서 일관된 디자인을 유지하면서 추가적인 화면별 조정을 줄일 수 있었다. ## 8px 기반의 매직 넘버 시스템 - 텍스트, 버튼, 그래픽, 여백, 패딩 등의 크기가 공통 숫자 배수를 따르도록 설계했다. - 기존 시안을 분석한 결과 대부분의 값이 8의 배수에 가까웠기 때문에 8px을 기준 단위로 채택했다. - 버튼과 입력 요소의 높이는 32, 48, 56, 64, 96px로 구성했다. - 주요 텍스트 크기는 16, 24, 32, 48px을 사용했다. - 패딩과 거터는 16, 24, 32px을 중심으로 정의했으며, 큰 카드 높이는 240px로 설정했다. - 공통 단위를 사용하면 컴포넌트 간 간격과 크기를 조정하기 쉽고 전체 디자인의 조화도 높아진다. ## Figma 제약 조건과 화면 크기 대응 - Figma의 constraints를 활용해 요소를 화면이나 그리드의 가장자리에 고정하고, 프레임 크기 변화에 따라 레이아웃이 반응하도록 만들었다. - 하나의 레이아웃이 일반적인 스마트폰, 작은 화면의 iPhone SE, 태블릿에서 모두 자연스럽게 보이도록 화면 간 비율을 분석했다. - 화면 크기 사이의 비율을 계산한 뒤 소수 값을 반올림해 실용적인 정수 기반 스케일링 규칙으로 정리했다. - 이 규칙을 React 코드의 크기 계산 로직에 적용해 디자인과 실제 구현이 같은 방식으로 동작하도록 했다. - Figma에서는 scale 도구와 프레임 크기 조절을 함께 사용해 하나의 템플릿으로 다양한 기기 화면을 미리 확인했다. - 템플릿이 처음부터 스케일링 규칙을 고려해 설계되었기 때문에 태블릿과 작은 스마트폰에서도 별도의 대규모 수정 없이 안정적으로 표시됐다. ## 다양한 화면 비율을 위한 콘텐츠 설계 - 앱에는 많은 영상과 애니메이션이 포함되어 있어 화면별로 콘텐츠 파일을 여러 버전 제작하는 방식은 피하고자 했다. - 모든 영상과 애니메이션을 4:3 비율을 기준으로 제작했다. - 16:9 화면에서 일부가 잘리더라도 핵심 내용이 유지되도록 안전 영역(safe area)을 설정했다. - 이 방식으로 콘텐츠 파일은 하나만 유지하면서 다양한 화면 비율에 대응할 수 있었다. ## 텍스트 크기와 다국어 지원 - 8px 규칙이 모든 텍스트에 적합한 것은 아니므로 작은 글자에는 4px 단위의 예외를 허용했다. - 예를 들어 12px과 20px 같은 크기를 사용해 가독성과 시각적 균형을 맞췄다. - 앱을 6개 언어로 번역하면서 독일어처럼 단어가 긴 언어가 정해진 영역을 넘는 문제가 발생했다. - 이를 해결하기 위해 텍스트가 영역에 맞지 않으면 코드가 다음으로 작은 제목 크기를 자동 선택하도록 구현했다. - 그 결과 실제 사용 가능한 제목 크기는 기본 디자인보다 많아졌지만, H1부터 H6까지 단계적으로 자연스럽게 작아지는 체계를 유지했다. ## 단순한 레이아웃에 맞춘 체계적인 접근 - 대부분의 화면은 중앙 정렬 요소나 2~3열 콘텐츠처럼 비교적 단순한 구조였다. - 복잡한 반응형 패턴을 많이 사용하지 않고, 기본 제약 조건과 스케일링 시스템만으로 요구사항을 충족했다. - 디자인 시스템을 Figma와 React 양쪽에 동일하게 적용한 것이 다양한 화면 크기를 효율적으로 관리한 핵심이었다. 실무에서는 먼저 기존 디자인에서 반복되는 크기와 간격을 찾아 기준 단위를 정하고, Figma constraints와 코드의 반응형 규칙을 함께 설계하는 것이 좋다. 다만 텍스트와 다국어처럼 예외가 잦은 영역에는 고정 규칙을 강제하기보다 단계적 축소나 안전 영역 같은 유연한 예외 처리를 마련해야 한다.

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

ReactFigma디자인 시스템반응형 디자인+2