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

비하인드 스토리: 국제 키

Figma는 미국 키보드 기준으로 설계된 단축키가 국제 키보드 사용자에게 작동하지 않는 문제를 해결하기 위해 1년간 단축키 시스템을 개선했다. 문제는 단순히 키 조합을 추가하는 것이 아니라, 브라우저의 키보드 이벤트 처리, 문자 정규화, 키보드 레이아웃 감지 등 여러 계층에 걸쳐 있었다. 특히 독일어 `ß`처럼 대소문자 변환만으로는 안전하게 처리할 수 없는 문자와 수천 가지 키보드 레이아웃이 복잡성을 높였다. ### 국제 키보드에서 발생한 단축키 문제 - Figma의 기존 단축키는 미국 키보드를 기준으로 설계되었다. - 일부 사용자는 키보드에 존재하지 않는 키를 요구받았다. - `⌘ + \`로 UI를 전환해야 하지만 `\` 키가 없는 경우 - `/` 키를 누를 수 없어 Cursor Chat을 시작할 수 없는 경우 - 단축키는 작업 효율성과 접근성에 중요한 기능이므로, 모든 지역의 사용자가 동일한 기능을 이용할 수 있어야 했다. - 이를 해결하기 위해 에디터 사용성 팀을 중심으로 여러 직군이 참여한 프로젝트가 시작되었다. ### Figma의 단축키 처리 구조 - 사용자가 키를 누르면 브라우저가 `KeyboardEvent`를 Figma에 전달한다. - Figma는 이벤트를 에디터가 해석할 수 있는 내부 표현으로 변환한다. - 가능한 단축키와 실행할 동작은 JSON 파일에 정의되어 있다. - 단축키 활성화 여부는 다음과 같은 상태에 따라 달라진다. - 사용자 설정 - 현재 사용 중인 Figma 제품 - 운영체제 - 기타 제품 상태 - 입력된 키 조합을 정의된 단축키 목록과 비교해 일치하면 해당 동작을 실행한다. ### 단순한 단축키 추가로 해결되지 않은 이유 - 처음에는 키보드별 대체 조합을 JSON에 추가하면 될 것처럼 보였다. - 스웨덴어 키보드: `⌘ + ]` 대신 `Meta + Ä` - 한국어 키보드: `⌘ + \` 대신 `₩` - 그러나 단축키를 정규화하는 과정에서 언어별 문자의 특수성이 드러났다. - 독일어 키보드의 `Meta + Alt + ß`를 처리할 때 JavaScript의 `"ß".toUpperCase()`가 `SS`로 변환되었다. - 하나의 키 문자가 두 글자로 늘어나면서 단일 키 단축키라는 전제가 깨졌다. - 더 나아가 `"ß".toUpperCase().toLowerCase()`도 원래의 `ß`로 되돌아가지 않았다. - Figma는 대문자 에스체트인 `ẞ`를 사용해 우회했다. - `ẞ`는 대문자로 변환해도 동일하게 유지된다. - 이 문자는 2017년 독일 철자위원회에서 공식 채택되었지만, 프로그래밍 언어와 도구의 지원은 아직 완전하지 않았다. ### 키보드 레이아웃 감지의 어려움 - 전 세계에는 매우 많은 키보드 레이아웃이 있어, 처음부터 모두 지원하기는 어려웠다. - Figma는 사용자가 많이 사용하는 레이아웃부터 지원하기로 했다. - 데스크톱 앱에서는 운영체제의 키보드 설정을 직접 감지할 수 있었다. - 브라우저에서는 운영체제 정보를 충분히 얻기 어려워 실험적인 Keyboard API와 휴리스틱을 사용했다. - API가 제공하는 키 위치별 문자를 알려진 레이아웃과 비교해 사용자의 레이아웃을 추정했다. - 예를 들어 `Quote` 키 위치에 `ä`가 입력되는지 확인하고 다른 키 정보와 조합해 스웨덴어 키보드인지 추론한다. - 실제 사용 데이터를 수집한 결과, 30일 동안 Figma에서 2,500개가 넘는 서로 다른 키보드 레이아웃이 관찰되었다. - 이는 키보드 레이아웃의 다양성이 예상보다 훨씬 크며, 국제 단축키 지원이 단순한 지역별 매핑 이상의 문제임을 보여준다. 국제 키보드 단축키를 설계할 때는 특정 국가의 키 조합을 추가하는 데 그치지 말고, 문자 정규화의 언어적 예외, 브라우저와 데스크톱 환경의 감지 차이, 레이아웃의 폭넓은 다양성을 함께 고려해야 한다. 특히 키 이름이나 문자를 문자열로만 처리하면 `ß` 사례처럼 예기치 않은 변환이 발생할 수 있으므로, 키 위치와 입력 문자를 구분하는 견고한 설계가 필요하다.

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

internationalization접근성jsonkeyboardevents+3

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

Schema 2022 미리 보기

Figma의 연례 디자인 시스템 콘퍼런스 Schema 2022는 디자인 시스템의 구체적인 과제와 기회를 깊이 다루기 위해 뉴욕, 런던, 도쿄 및 온라인에서 개최된다. 글은 행사 일정뿐 아니라 디자인·개발 협업, 디자인 토큰, 플러그인과 통합 등 주요 관심사를 소개하며, 다양한 수준의 참가자가 배울 수 있도록 프로그램을 구성했다고 설명한다. 행사의 발표 영상은 이후 DesignSystems.com에 공개되었다. ### 도시 순회 및 온라인 행사 - Schema 2022는 다음 방식으로 진행된다. - 뉴욕, 런던, 도쿄에서 오프라인 행사 개최 - 장소와 관계없이 참여할 수 있는 온라인 행사 제공 - 각 도시 행사는 해당 지역과 연사에 맞춘 개별 프로그램으로 구성된다. - 오프라인 행사는 초청제로 운영되지만 참가 신청이 가능하다. - 각 도시에서는 지역 디자인 커뮤니티를 위한 밋업도 열린다. - 온라인 콘퍼런스는 오프라인 참석이 어려운 사람도 참여할 수 있도록 공개된다. ### 디자인 시스템에 집중한 전문 콘퍼런스 - Config가 디자인 전반을 다룬다면, Schema는 디자인 시스템에 초점을 맞춘 보다 전문적인 행사다. - 디자인 시스템의 고유한 기회와 문제를 깊이 탐구할 수 있다는 점이 Schema의 특징이다. - 주제가 구체적이기 때문에 연사와 참가자가 다음과 같은 논의에 집중할 수 있다. - 디자인 시스템 구축과 운영 - 조직 내 협업 방식 - 디자인 시스템의 확장과 활용 - 동시에 디자인 시스템을 처음 접하는 사람과 숙련된 실무자 모두에게 의미 있는 발표를 제공하는 것이 프로그램 구성의 과제다. - 발표 내용은 새롭고 혁신적이어야 하면서도, 디자인 시스템의 기본 개념을 배우려는 사람도 이해할 수 있어야 한다. ### 디자이너와 개발자의 창의적 교류 - 디자인 시스템은 디자인뿐 아니라 개발, 도구 제작, 조직 협업 등 다양한 역량을 필요로 한다. - Schema는 디자이너와 개발자가 서로의 작업과 아이디어를 공유하는 공간으로 기능한다. - 디자이너는 다음과 같은 주제에 대해 아이디어를 나눌 수 있다. - 플러그인 - 확장 기능 - 외부 서비스 및 도구와의 통합 - 개발자는 자신들이 구축한 도구와 시스템을 소개하며 디자인 분야와 연결점을 찾는다. - 이러한 상호작용을 통해 디자인 시스템이 단순한 시각 요소 모음이 아니라, 여러 직군이 함께 발전시키는 기술·프로세스라는 점이 드러난다. ### W3C 디자인 토큰 커뮤니티 그룹 - 디자인 토큰은 특정 도구나 플랫폼에 종속되지 않고 디자인 스타일을 관리·공유하기 위한 방법론이다. - 디자인 토큰은 여러 도구, 디바이스, 플랫폼에서 디자인을 확장하는 데 활용될 수 있다. - W3C Design Tokens Community Group은 다음을 목표로 한다. - 디자인 시스템의 스타일 정보를 도구 간에 공유할 수 있는 표준 마련 - 제품과 디자인 도구가 대규모로 디자인 토큰을 활용할 수 있는 기반 제공 - 디자인 토큰은 디자이너와 개발자가 공통의 언어로 시스템을 다루게 하는 연결 고리로 소개된다. - 표준화 논의에서는 특히 다음과 같은 주제를 장기적으로 고려한다. - 국제화 - 접근성 - 다양한 플랫폼과 환경에서의 일관성 ### 실무적 시사점 디자인 시스템을 도입하거나 확장하려는 팀이라면 시각 디자인 요소뿐 아니라 개발자 핸드오프, 도구 간 통합, 디자인 토큰의 표준화까지 함께 고려해야 한다. 특히 디자이너와 개발자가 초기부터 공통 언어와 공유 가능한 토큰 체계를 마련하면 여러 제품과 플랫폼으로 시스템을 확장하기 쉬워진다.

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

internationalizationFigma디자인 시스템접근성+2

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와 코드의 반응형 규칙을 함께 설계하는 것이 좋다. 다만 텍스트와 다국어처럼 예외가 잦은 영역에는 고정 규칙을 강제하기보다 단계적 축소나 안전 영역 같은 유연한 예외 처리를 마련해야 한다.

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

internationalizationFigma디자인 시스템React+2