Techlist.io - 한국 테크 블로그 큐레이터

figma2분 읽기큐레이션 요약

2018 Unsplash

Figma는 Unsplash의 2018년 연례 사진 어워즈 개최 소식을 알리며 사진 제출을 독려한다. Unsplash는 무료로 사진을 공유하는 창작자들의 기여를 기념하기 위해 다양한 분야의 우수 사진을 선정하며, 2018년 12월 7일까지 작품을 접수한다. 수상작은 11~12월 동안 소개된 사진 중 심사위원들이 카테고리별로 선정한다. ## Unsplash가 사진 창작자를 기리는 이유 - Unsplash는 2013년 시작해 기존 스톡 사진의 진부하고 상업적인 이미지와 차별화했다. - 편집자들이 매일 아름다운 사진을 선별해 높은 품질 기준을 유지했다. - 플랫폼은 사진을 무료로 공유하는 창작자들의 관대함과 전문성에 기반한다. - 어워즈는 이러한 창작자들의 기여를 인정하고 감사하기 위한 행사다. ## 2018 Unsplash Awards 운영 방식 - 2018년이 두 번째 연례 Unsplash Awards다. - 11월과 12월 동안 여러 주제별 사진을 집중적으로 소개한다. - 각 카테고리에서 소개된 작품을 심사위원들이 평가해 최고의 사진을 선정한다. - 카테고리별 세부 기준, 심사위원 명단, 평가 방식은 Unsplash Awards 공식 페이지에서 확인할 수 있다. ## 사진 출품 카테고리 - 항공 사진 - 동물 및 야생동물 - 천체 사진 - 흑백 사진 - 음식 및 음료 - 인테리어 및 건축 - 모바일 사진 - 자연 및 풍경 - 인물 및 초상 - 스포츠 - 거리 사진 - 기술 및 비즈니스 - Unsplash 커뮤니티 ## 출품 일정과 대상 - 사진 제출 마감일은 2018년 12월 7일이다. - Unsplash에 사진을 공유하는 사진가라면 출품할 수 있다. - Figma는 자사 디자이너들 중 사진 취미 활동을 하거나 Unsplash를 사용하는 사람이 많다는 점에서 이번 행사를 소개했다. - 출품은 Unsplash Awards 웹사이트에서 진행된다. 관심 있는 사진가는 자신의 작품이 가장 잘 맞는 카테고리와 세부 평가 기준을 확인한 뒤, 마감일 전에 공식 출품 페이지를 통해 제출하면 된다.

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

Figma에서 페이지를

Figma의 Pages는 하나의 파일 안에서 작업을 목적별로 나누어 정리하는 유연한 구조다. 글은 플랫폼, 기능, 디자인 단계, 원자적 디자인 방법론에 따라 Pages를 구성하는 네 가지 방식을 소개하며, 팀 규모와 프로젝트 특성에 맞는 체계를 선택하라고 제안한다. 적절히 나누면 협업, 프로토타이핑, 검색, 개발자 전달이 쉬워진다. ## Pages를 활용한 파일 구조화 - Figma 파일의 왼쪽 탭에 여러 Pages를 만들어 디자인을 분류할 수 있다. - 조직 방식에는 정답이 없으며 회사, 팀, 개인의 작업 방식에 따라 달라진다. - 디자인 파일을 무작정 한 곳에 쌓기보다 작업 목적에 맞게 구분하면 정리보다 디자인 자체에 집중할 수 있다. ## 플랫폼 또는 화면 크기별 구성 - Android, iOS, 데스크톱처럼 여러 플랫폼을 지원하는 제품에 적합하다. - 플랫폼별로 Page를 나누면 각 환경의 프레임 프리셋과 제약 조건을 적용하기 쉽다. - 각 Page에 독립적인 프로토타입을 구성할 수 있어 플랫폼별 사용자 테스트가 간편하다. - 반응형 디자인을 플랫폼별로 비교하고 관리하기에도 유리하다. ## 앱 기능별 구성 - 여러 디자이너가 다양한 기능을 동시에 개발하는 대규모 앱에 적합하다. - 프로필, 홈 화면 등 제품의 주요 기능을 각각 별도의 Page로 분리한다. - 담당 디자이너는 특정 기능에 집중하면서도 다른 Page를 참고해 전체 제품과의 일관성을 유지할 수 있다. - 기능별로 별도의 프로토타입을 만들어 특정 사용자 흐름만 독립적으로 테스트할 수 있다. ## 디자인 프로세스 단계별 구성 - 아이디어부터 최종 결과물까지 작업 진행 상태를 명확히 보여줄 수 있다. - 예를 들어 다음과 같이 Page를 구성할 수 있다. - 썸네일 → 와이어프레임 → 디자인 → 아카이브 - 문서·리서치 → 작업 중인 시안 → 리뷰 준비 - 사이트맵 → 와이어프레임 → 목업 → QA → 마케팅용 스크린샷 - `Done` Page에 완료된 디자인을 모으면 개발자는 실제로 구현해야 할 결과물을 쉽게 확인할 수 있다. - 초기 아이디어와 브레인스토밍을 별도 Page에 두면 완성도 높은 화면이 작업 중인 시안에 묻히지 않는다. - 팀이 복잡한 체계를 원하지 않는다면 단순히 “진행 중”과 “완료” 정도로 나누는 방식도 가능하다. ## Atomic Design 방법론에 따른 구성 - 디자인 시스템을 원자적 디자인 방식으로 운영할 때 적합하다. - 구성 요소의 계층에 따라 Page를 분리한다. - Atoms: 타이포그래피, 아이콘 등 기본 요소 - Molecules: 버튼 등 조합된 컴포넌트 - Organisms: 전체 페이지처럼 복잡한 구성 - Team Library에서 Page 이름을 기준으로 컴포넌트를 찾기 쉬워진다. - 레이어 이름에 컴포넌트 유형을 반복해서 넣지 않아도 된다. - 예: `button-selected`, `button-hovered` 대신 `selected`, `hovered`처럼 상태만 이름에 표시 - 결과적으로 레이어 패널이 단순해지고 컴포넌트 검색과 관리가 쉬워진다. 프로젝트의 핵심 기준을 먼저 정한 뒤 Pages를 구성하는 것이 좋다. 여러 플랫폼을 지원하면 플랫폼별로, 협업 규모가 크면 기능별로, 개발 전달이 중요하면 프로세스 단계별로 나누고, 디자인 시스템 중심이라면 Atomic Design 구조를 적용하면 된다.

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

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

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

Figma에서 아토믹 디자인 시스템

littleBits 팀은 약 6개월 안에 iOS·Android용 모바일·태블릿 앱 네 개를 출시해야 했고, 이를 위해 Figma에서 Atomic Design 기반의 디자인 시스템을 구축했다. 핵심은 재사용 빈도와 실제 개발 구조를 기준으로 원자·컴포넌트를 정의하고, 의미론적 색상과 텍스트 스타일을 조합해 유연성을 확보하는 것이었다. 결과적으로 Figma의 컴포넌트 구조가 React Native 컴포넌트와 자연스럽게 대응했고, 이후 반응형 레이아웃 템플릿으로 확장할 수 있는 기반이 마련됐다. ## 원자 수준의 디자인 토큰 - 텍스트 스타일과 색상은 Figma Styles로 정의했다. - 아이콘은 외부 아이콘 세트를 가져온 뒤 Figma 컴포넌트로 변환했다. - 색상 이름은 Bootstrap의 명명 방식을 참고하되, 테마 변경을 고려해 의미론적으로 지정했다. - 예: `bg-light`는 배경용 색상 - 예: `ui-dark`는 기본 전경 요소용 색상 - 기본 UI·그레이스케일 색상 외에 브랜드 색상, 배경, 오버레이, 외곽선용 색상 팔레트를 추가했다. - 색상값 자체보다 사용 목적을 이름에 반영하면 전체 디자인에서 색상을 일괄 수정하기 쉽고, 변경으로 인한 오류도 줄일 수 있다. ## 복잡한 계층 대신 ‘컴포넌트’로 단순화 - Atomic Design의 ‘분자’와 ‘유기체’가 여러 템플릿에서 반복 사용되는 경우가 많지 않다는 점을 발견했다. - 따라서 해당 계층을 세분화하지 않고 모두 `Components`로 통합했다. - 이 구조는 다음과 같은 React Native 컴포넌트 구조와도 잘 맞았다. - 카드 - 툴팁 - 버튼 - 기타 반복 UI 요소 - 이론적인 Atomic Design 분류보다 실제 재사용 패턴과 개발 구조에 맞춘 단순한 분류를 선택한 것이다. ## 스타일 조합으로 불필요한 컴포넌트 줄이기 - 텍스트 스타일과 색상 스와치를 자유롭게 조합할 수 있으므로, 색상·텍스트 스타일 조합마다 별도의 컴포넌트를 만들지 않았다. - 대신 스타일 가이드를 제공하고, 실제 템플릿에서 필요한 조합을 직접 적용했다. - 하나의 텍스트 상자 안에서도 여러 텍스트 스타일을 섞을 수 있게 해 가변적인 문구 길이에 대응했다. - Figma Styles 도입으로 컴포넌트 내부의 레이어 구조가 단순해졌고, 문서 사용성과 성능도 개선됐다. ## 버튼은 중첩 컴포넌트로 관리 - 버튼은 디자인에서 반복적으로 사용되고, 외곽선 등 중앙 관리가 어려운 속성을 포함하므로 별도의 중첩 컴포넌트로 만들었다. - 주요 버튼 유형을 다음과 같이 분리했다. - Primary - Secondary - Tertiary - 반복 사용될 가능성이 높은 특수 버튼도 별도 컴포넌트로 정의했다. - 모든 요소를 무조건 조합형 스타일로 처리하지 않고, 반복성과 관리 필요성이 높은 UI만 컴포넌트화한 것이 특징이다. ## 디자인 시스템과 개발 시스템의 연결 - Figma에서 정의한 컴포넌트 체계가 React Native에서 구현할 컴포넌트와 직접 대응하도록 설계됐다. - 디자인과 코드 사이의 구조적 차이를 줄여 협업과 구현을 쉽게 만들었다. - 완성된 컴포넌트 기반은 이후 모바일·태블릿 화면을 위한 반응형 레이아웃 템플릿 구축의 출발점이 됐다. 실무에서는 Atomic Design의 계층을 그대로 적용하기보다, 실제 재사용 빈도와 개발 컴포넌트 구조를 기준으로 단순화하는 것이 효과적이다. 색상과 텍스트는 의미론적 스타일로 관리하고, 반복성과 변경 가능성이 높은 요소만 컴포넌트로 만들면 유지보수성과 확장성을 함께 확보할 수 있다.

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

피그마 2018

Figma의 2018년은 단순한 디자인 도구를 넘어 플랫폼과 커뮤니티로 확장한 해였다. 웹 기반 API를 공개해 외부 서비스와 자동화 도구가 Figma에 연결될 수 있도록 했고, 실제 사업과 통합 사례도 등장했다. 동시에 전 세계 사용자 커뮤니티를 조직하고 디자인 시스템 관련 지식 공유를 확대했으며, Series B 투자로 제품·사업 확장을 뒷받침했다. ## 플랫폼과 웹 API의 공개 - Figma는 초기부터 데스크톱 소프트웨어가 아닌 웹 기반 디자인 도구를 지향했다. - 2018년에는 디자인 도구 최초의 웹 API를 공개하며 Figma Platform을 출시했다. - API를 통해 다음과 같은 확장이 가능해졌다. - 다른 디자인·개발 도구와의 연동 - 반복 작업 자동화 - 스크립트와 웹 애플리케이션을 활용한 맞춤형 워크플로 구축 - Uber와 GitHub는 공개 전부터 API를 활용해 자체 업무 프로세스를 맞춤화했다. - 클라우드 기반 구조 덕분에 기존의 폐쇄적인 데스크톱 소프트웨어로는 구현하기 어려웠던 온라인 통합이 가능해졌다. ## API를 기반으로 한 생태계와 사업 - 플랫폼 출시 7개월 만에 Figma 위에서 유료 사업을 운영하는 기업이 등장했다. - 커뮤니티와 기업이 만든 주요 통합 사례는 다음과 같다. - PDF 내보내기 - 스타일 가이드 자동 생성 - 텍스트와 레이어 이름 검색·일괄 변경 - JavaScript용 Figma API 라이브러리 - 외부 서비스와의 연동도 확대됐다. - Avocode와 Zeplin: 개발자 핸드오프 지원 - Principle: Figma 디자인에 고급 애니메이션 추가 - Relay for Figma: 디자인을 코드베이스로 직접 전달 - Pagedraw: Figma 디자인을 React 코드로 변환 - Overflow: 사용자 플로우 다이어그램 제작 - Haiku: 디자인을 프로덕션용 컴포넌트로 전환 - Figma는 파트너십과 통합 생태계를 향후 성장의 핵심 축으로 보고, 2019년에도 플랫폼 확장을 이어가겠다고 밝혔다. ## 글로벌 커뮤니티 구축 - 2018년 Figma의 관심사는 제품 자체뿐 아니라 사용자 커뮤니티로 확대됐다. - 디자인 시스템을 주제로 한 밋업을 세계 여러 도시에서 개최했다. - 초기에는 8개 도시에서 시작 - 이후 17개 국가로 활동 범위를 확장 - Bengaluru, Toronto 등지에서 디자이너들이 실제 디자인 시스템 운영 경험을 공유 - 커뮤니티의 관심이 커지자 DesignSystems.com을 개설했다. - Airbnb, GitHub, Braintree, Segment 등의 구성원이 디자인 시스템 운영 사례와 실무 조언을 공유했다. - Figma는 온라인 제품뿐 아니라 오프라인 만남과 지식 공유를 통해 사용자 간 연결을 강화하려 했다. ## 기업 확장과 투자 - Microsoft Dynamics 365 for Talent 디자인팀은 Figma API를 활용해 개발자 핸드오프를 자동화했다. - 대규모 조직이 여러 부서와 팀에서 Figma를 채택하기 시작했다. - 2018년 초 2,500만 달러 규모의 Series B 투자를 유치했다. - 투자금은 제품 개발과 사업 확장, 플랫폼 및 커뮤니티 성장에 활용됐다. ## 실용적인 시사점 Figma의 사례는 협업 도구가 자체 기능만으로 성장하는 것이 아니라 API, 외부 통합, 사용자 커뮤니티를 통해 플랫폼으로 발전할 수 있음을 보여준다. 특히 반복적인 디자인·개발 업무를 자동화하려는 팀이라면 API 기반 연동과 기존 도구와의 연결 가능성을 우선 검토할 만하다.

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

Datadog 로그 관리로 신뢰도 향상 (새 탭에서 열림)

Datadog은 비밀번호 재설정과 같은 중요 이메일의 전송 신뢰성과 가시성을 확보하기 위해 Amazon SES와 자사의 로그 관리 솔루션을 결합한 서버less 모니터링 시스템을 구축했습니다. 기존 Amazon SES와 CloudWatch만으로는 특정 수신자의 이메일 수신 여부 등을 실시간으로 파악하고 대응하기에 한계가 있었으나, 이 파이프라인을 통해 지원팀이 즉각적으로 문제를 진단할 수 있게 되었습니다. 결과적으로 최소한의 유지보수로 운영 효율성을 높이면서도 전송 프로세스 전반에 대한 높은 수준의 관측성을 확보했습니다. **Amazon SES 이벤트 추출 및 파이프라인 구성** * **이벤트 트리거 설정**: Amazon SES의 'Configuration Sets'를 사용하여 이메일 전송 과정에서 발생하는 bounce, click, complaint, delivery, open, reject, send 등 모든 주요 이벤트를 추적합니다. * **서버리스 아키텍처**: SES에서 발생한 이벤트는 Amazon SNS(Simple Notification Service)로 게시되며, 이는 다시 AWS Lambda 함수를 실행시키는 트리거가 됩니다. * **데이터 전달**: Lambda 함수는 수신된 이메일 이벤트를 Datadog Log Management로 전달합니다. 이 과정에서 Terraform을 사용하여 SNS 토픽 생성, SES 이벤트 대상 지정, IAM 역할 및 Lambda 함수 구성을 코드 기반(IaC)으로 관리합니다. * **안전한 인증**: 프로덕션 환경에서는 Datadog API Key를 암호화하여 보안을 강화할 것을 권장합니다. **Datadog에서의 데이터 가시성 및 인덱싱** * **자동 파싱**: AWS에서 Datadog으로 전송된 로그는 JSON 형식으로 전달되어 Datadog의 기존 통합 파이프라인을 통해 자동으로 처리됩니다. * **패싯(Facet) 활용**: 이메일 이벤트 유형(event type)이나 제목(subject)과 같은 주요 파라미터를 '패싯'으로 변환하여, 지원팀이 특정 이메일 로그를 단 한 번의 클릭으로 쉽게 검색하고 필터링할 수 있게 구성합니다. * **로그 기반 모니터링**: 인덱싱된 데이터를 바탕으로 대시보드를 구성하거나, 특정 이벤트(예: 높은 바운스율) 발생 시 알림을 받을 수 있도록 모니터를 설정할 수 있습니다. **실용적인 결론 및 제언** Amazon SES와 같은 관리형 서비스와 중앙 집중식 로그 분석 도구를 연동하면 이메일 인프라를 직접 운영하는 부담을 줄이면서도 운영 복잡성을 해결할 수 있습니다. 특히 비밀번호 재설정과 같이 성공률이 중요한 서비스의 경우, 단순히 '전송됨' 상태를 확인하는 것을 넘어 전체 파이프라인에 대한 실시간 알림 시스템을 구축하는 것이 고객 지원의 품질을 높이는 핵심적인 방법입니다.

datadog2분 읽기큐레이션 요약

Datadog 로그 관리를

Datadog이 Gartner의 2026년 Observability Platforms 매직 쿼드런트에서 ‘Leader’로 선정되었다는 내용이 핵심입니다. 다만 제공된 텍스트에는 본문보다 Datadog 제품 메뉴와 링크 목록이 대부분 포함되어 있어, 선정 근거와 기술적 세부 내용은 확인할 수 없습니다. ### Gartner 매직 쿼드런트 선정 - Datadog은 Gartner의 **Observability Platforms** 부문에서 Leader로 소개됩니다. - 관련 자료 링크는 2026년 Gartner 평가 보고서로 연결됩니다. - 제공된 내용만으로는 평가 기준, 경쟁사 비교, Datadog의 구체적인 점수는 알 수 없습니다. ### Datadog의 관측성 제품 범위 - **인프라 모니터링** - 메트릭, 컨테이너, Kubernetes 오토스케일링 - 네트워크, 서버리스, GPU, 스토리지 및 클라우드 비용 모니터링 - **애플리케이션 모니터링** - APM, 서비스 모니터링, 연속 프로파일링 - 동적 계측과 AI 에이전트 관측성 - **로그 및 데이터 관리** - Log Management - 민감 데이터 검색, 감사 추적, Observability Pipelines - 데이터베이스·데이터 스트림·데이터 품질 모니터링 - **디지털 경험** - 브라우저·모바일 RUM - 세션 리플레이, 신세틱 모니터링, 오류 추적 - **서비스 관리** - 이벤트 관리, SLO, 인시던트 대응 - 워크플로 자동화, 서비스 카탈로그, Watchdog - **AI 기능** - Bits AI 에이전트와 조사 기능 - AI 통합, MCP 서버, GPU 모니터링 ### 로그 관리와 신뢰성 - 링크 목록에는 **“Improving trust with Datadog Log Management”**라는 엔지니어링 글이 포함되어 있습니다. - 그러나 해당 글의 본문은 제공되지 않아 다음과 같은 세부 사항은 요약할 수 없습니다. - 로그 수집 및 저장 구조 - 데이터 무결성·신뢰성 개선 방식 - 파이프라인 처리와 보안 기능 - 성능 또는 비용 개선 결과 제공된 자료만 기준으로 하면, Datadog은 인프라·애플리케이션·로그·보안·사용자 경험·AI를 하나의 플랫폼으로 통합하는 전략을 강조하고 있습니다. 정확한 기술적 결론을 얻으려면 Gartner 보고서나 연결된 엔지니어링 글의 본문이 추가로 필요합니다.

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

디자이너들이 피

Uber는 다양한 국가와 사용자층을 고려한 현지화된 경험 설계를 통해 교통 서비스를 확장했다. 특히 현금 결제가 필요한 신흥 시장을 공략하는 과정에서, Figma의 실시간 협업과 중앙 집중식 파일 관리가 디자인·리서치·엔지니어링 간 소통을 크게 개선했다. 결과적으로 팀은 최신 디자인을 공유하고 빠르게 피드백을 반영하며, 지역과 조직 규모에 관계없이 더 빠르게 제품을 발전시킬 수 있었다. ## 전 세계 사용자를 위한 디자인 - Uber는 65개국에서 7,500만 명의 승객이 연간 40억 회 이용하는 글로벌 물류 플랫폼으로 성장했다. - 국가별 사용자 경험을 설계할 때 다음 요소를 고려한다. - 언어 - 문해력 - 사용하는 기기 - 문화 - 지역적 특성 - 승객·운전자 등 사용자의 역할 - 제품팀은 설계 전에 현지 시장과 사용자에 대한 심층 조사를 수행한다. - 디자이너가 여러 국가에서 운전자와 직접 탑승하며 실제 환경에서 새로운 사용자 경험을 테스트하기도 한다. ## 신흥 시장의 현금 결제 설계 - 은행 계좌나 신용카드를 사용하기 어려운 사용자를 위해 Uber는 일부 시장에 현금 결제를 도입했다. - 현금 결제 기능은 제품 관리자, 디자이너, 운영 담당자, 데이터 과학자, 엔지니어가 함께 개발했다. - 기존 디자인 도구에서는 다음과 같은 비효율이 발생했다. - 디자인·프로토타이핑·공유·피드백 수집에 여러 도구를 사용 - 파일을 반복적으로 가져오고 내보내야 함 - 진행 상황을 별도 커뮤니케이션 채널에서 공유 - 한 번에 한 사람만 파일을 수정할 수 있음 - 현지 운전자와 프로토타입을 테스트하면서 실시간으로 수정하려 했지만, 협업 편집이 불가능해 즉각적인 반복 작업이 어려웠다. ## Figma를 통한 실시간 협업 - 디자이너 Femke van Schoonhoven은 다른 Uber 팀이 사용하던 웹 기반 협업 도구 Figma를 도입했다. - 기존 디자인 파일을 Figma로 드래그 앤 드롭해 쉽게 이전할 수 있었다. - 현지 언어와 실제 사용 맥락을 반영한 디자인을 만들면서 팀원들과 동시에 작업할 수 있었다. - 팀원들이 지역과 시간대에 관계없이 같은 디자인 파일에서 실시간으로 협업했다. - 파일 구조와 정리 방식도 직관적이어서 필요한 자료를 쉽게 찾을 수 있었다. - Figma는 여러 디자인 파일과 버전을 한곳에서 관리하는 중앙 저장소 역할을 했다. ## 단일 디자인 소스와 커뮤니케이션 효율화 - 이전에는 최신 디자인 버전을 알리기 위해 이해관계자에게 이메일을 반복해서 보내야 했다. - Figma에서는 팀원들이 폴더에서 언제든 최신 디자인을 확인할 수 있었다. - 디자인 파일 안에서 직접 댓글을 남길 수 있어 별도 이메일이나 메신저로 맥락을 설명할 필요가 줄었다. - van Schoonhoven은 커뮤니케이션 오버헤드가 최소 75% 감소했다고 설명했다. - 엔지니어를 디자인 파일에 초대해 최신 변경 사항과 맥락이 포함된 댓글을 함께 확인하도록 했다. - 엔지니어가 초기 단계부터 디자인 과정에 참여하면서 핸드오프가 더 빠르고 간단해졌다. ## 분산된 팀을 하나로 연결 - 여러 지역에 흩어진 팀원들이 동일한 파일과 목표를 공유할 수 있었다. - 과거에는 업무가 팀별로 분리되어 있었지만, Figma 도입 후 공동 작업 기반이 마련됐다. - 웹 기반 도구이므로 이해관계자가 파일을 쉽게 공유하고 상위 승인도 빠르게 받을 수 있었다. - 결과적으로 디자인 검토와 의사결정 속도가 빨라졌고, 팀 전체의 작업 효율이 향상됐다. Figma의 사례는 글로벌 제품에서 현지화 자체만큼이나 협업 방식이 중요하다는 점을 보여준다. 여러 국가의 사용자와 분산된 팀을 상대한다면, 최신 디자인을 한곳에서 관리하고 디자인·개발·피드백을 실시간으로 연결하는 협업 환경을 구축하는 것이 효과적이다.

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

새로운 Principle 연동 기능

Figma가 프로토타이핑 도구 Principle과 연동되어, Figma에서 만든 정적 디자인에 고급 애니메이션과 인터랙션을 추가할 수 있게 되었다. 사용자는 코딩 없이 스크롤, 스와이프, 버튼 상태 변화, 스프링·이징·선형 전환 등을 구현해 실제 모바일 앱과 유사한 프로토타입을 만들 수 있다. 또한 Figma에서 디자인을 수정하면 Principle이 변경 사항을 감지해 기존 애니메이션을 유지한 채 동기화한다. ## Figma와 Principle의 통합 - Principle에서 Figma를 가져오기 소스로 인증하면 Figma 디자인을 Principle로 불러올 수 있다. - Figma의 화면과 객체를 기반으로 Principle에서 인터랙션과 모션을 설정한다. - 정적인 UI 시안을 실제 앱처럼 동작하는 프로토타입으로 발전시킬 수 있다. - 이 통합은 Figma의 웹 기반 API를 활용해 구축되었다. ## 구현할 수 있는 인터랙션과 애니메이션 - 페이지에 스크롤 동작 추가 - 이미지 카드 사이의 스와이프 전환 구현 - 사용자의 상호작용에 따른 버튼 상태 변화 설정 - 객체 간 전환 애니메이션 적용 - 스프링(spring) - ease in - ease out - 선형(linear) 전환 - 별도의 코딩 없이 모바일 앱에 가까운 동작과 화면 전환 표현 ## 코딩 없이 사용하는 시각적 프로토타이핑 - Principle은 인터페이스 디자이너에게 익숙한 시각적 UI를 제공한다. - 디자인과 엔지니어링 작업을 오가는 대신, 디자이너가 시각적·창의적 사고에 집중할 수 있도록 설계되었다. - 초보자도 비교적 쉽게 사용할 수 있으며, 복잡한 프로토타입을 만들면서도 코드를 배울 필요가 없다. - 단순한 사용성과 강력한 애니메이션 기능의 균형이 Principle의 장점으로 소개된다. ## Figma 수정 사항의 동기화 - 이미 Principle로 가져온 디자인을 Figma에서 수정해도 두 도구 사이의 동기화가 가능하다. - Principle은 Figma의 변경 사항을 자동으로 인식하고 기존 작업에 병합한다. - 예를 들어 Figma에서 버튼 크기를 변경하면 Principle에서도 버튼 크기가 자동으로 조정된다. - 이때 Principle에서 설정한 기존 애니메이션은 유지된다. - 따라서 디자인 수정 때마다 프로토타입의 인터랙션을 처음부터 다시 설정할 필요가 없다. ## 개발자를 위한 Figma API 활용 - Principle 제작자는 Figma의 API 문서와 도구를 활용해 연동 기능을 개발했다. - Figma의 API Explorer에서는 특정 Figma 파일 ID를 입력해 API 호출 결과를 확인할 수 있다. - 개발자는 API의 기본 구성 요소와 파일 데이터 구조를 직접 테스트하며 연동 방식을 이해할 수 있다. - 이는 디자인 도구를 외부 서비스와 연결하려는 개발자에게 실용적인 검증 환경을 제공한다. ## 활용과 의의 - Figma는 화면 설계에, Principle은 모션과 인터랙션 구현에 특화된 역할을 맡는다. - 두 도구를 함께 사용하면 디자인 단계에서 사용자 경험을 더 현실적으로 검증할 수 있다. - 디자이너는 개발에 넘기기 전에 전환 효과와 인터랙션의 완성도를 확인할 수 있다. - 통합 기능은 Figma 사용자들의 지속적인 요청에 대한 대응으로 제공되었다. 실무에서는 Figma에서 레이아웃과 시각 디자인을 관리하고, Principle에서 핵심 사용자 흐름과 애니메이션을 빠르게 검증하는 방식이 효과적이다. 특히 디자인 변경 후에도 애니메이션이 유지되므로, 반복적인 프로토타입 수정 작업을 줄일 수 있다.

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

구글의 AR 디자인 가이드

Google의 AR 디자인 가이드라인은 Apple보다 범위가 넓고 실용적이지만, 두 가이드 모두 단순한 단일 장면과 객체 배치에 지나치게 집중한다. 따라서 복잡한 상호작용, 다중 장면, 애니메이션, 협업 환경 등 실제 3D UX 설계에 필요한 문제를 충분히 다루지 못한다. 결국 AR 디자인의 발전은 공식 문서보다 디자이너와 업계가 직접 새로운 관행과 도구를 만들어가는 과정에 달려 있다. ## 모바일 AR의 대중화와 새로운 설계 과제 - Google의 ARCore와 Apple의 ARKit 등장으로 3D UX가 VR 헤드셋 중심에서 모바일로 이동했다. - 모바일 개발자라면 수억 명의 Android·iOS 사용자에게 AR 경험을 제공할 수 있게 되었다. - 그러나 기존 2D 앱 디자인과 달리 3D에서는 공간, 깊이, 물리, 장면 전환 등을 고려해야 한다. - 게임·영화·건축 등 서로 다른 분야에서 가져온 도구와 복잡한 작업 흐름 때문에 디자이너가 쉽게 접근하기 어려웠다. ## Apple과 Google 가이드라인의 범위 - Apple은 Human Interface Guidelines의 AR 항목에서 비교적 제한적인 내용을 제공한다. - Apple의 설명은 주로 ARKit의 평면 인식과 그 위에 객체를 배치하는 기본 사용 사례에 집중한다. - Google의 AR Design Guidelines는 AR Stickers와 Just a Line 같은 실제 제품 경험을 바탕으로 더 폭넓은 주제를 다룬다. - Google은 다음과 같은 객체 배치 방식을 제시한다. - 탭해서 배치 - 드래그해서 배치 - 자유 배치 - 객체 배치의 현실감을 높이기 위해 물리 효과를 활용하는 방법도 간략히 설명한다. - 이후 UI 컴포넌트와 온보딩을 포함한 “경험 설계” 관련 내용도 추가되며 지속적으로 확장되고 있다. ## 복잡한 AR 상호작용을 다루지 못하는 문제 두 가이드라인은 단순한 객체 배치나 스티커형 기능을 넘어서는 설계를 거의 다루지 않는다. - 객체 선택 및 선택 상태 관리 - 다른 객체에 가려진 객체 선택 - 조건에 따른 동작 변화 - 사용자의 행동에 따른 분기형 장면 흐름과 스토리보드 - 텔레포테이션을 통한 장면 이동 - 포털과 공간 간 연결 - 물리적 제스처 기반 상호작용 - 시간 또는 사용자 행동에 의해 실행되는 애니메이션 - 여러 장면 사이의 상태 변화와 개인화 - 원격 사용자와 함께 AR 프로토타입을 확인하고 피드백하는 실시간 협업 특히 다중 장면 사용 사례가 빠져 있어, 복잡한 전환과 조건부 동작을 설계하기 어렵다. 이는 더 깊고 몰입감 있는 AR 경험을 만들려는 디자이너의 요구와 맞지 않는다. ## 객체 배치 방식에 대한 한계 - Google은 사용자가 손을 뻗어 닿을 수 있는 거리 안에 객체를 배치하는 것이 최적이라는 전제를 둔다. - 그러나 실제로는 객체를 던지거나, 멀리 있는 대상을 가리키거나, 잡아당기는 방식도 가능하다. - 따라서 특정 거리나 방식만을 최적의 규칙으로 고정하기보다, 다양한 상호작용을 실험할 여지가 필요하다. - Apple이 평면 감지 기반 배치만 설명하는 것과 비교하면 Google의 접근은 훨씬 구체적이지만, 여전히 복잡한 공간 상호작용까지는 확장되지 않았다. ## 업계가 직접 만드는 3D UX 관행 - 공식 가이드라인은 빠르게 변화하는 AR 기술과 수많은 창의적 실험을 모두 따라가기 어렵다. - 디자이너들은 기존 도구를 조합해 새로운 프로토타이핑 및 제작 프로세스를 구축하고 있다. - Unity의 Bushra Mahmood처럼 개인이 독자적인 AR 디자인 가이드라인을 만들기도 한다. - Marino Software 같은 팀은 기존 도구를 혼합해 작동하는 AR 앱과 새로운 작업 방식을 실험하고 있다. - 이러한 풀뿌리 활동은 3D UX의 실제 모범 사례를 형성하는 데 중요한 역할을 한다. ## 실용적인 결론 현재 AR 프로젝트를 시작한다면 Google의 가이드라인을 기본 출발점으로 활용하되, 이를 완성된 설계 규칙으로 받아들여서는 안 된다. 다중 장면, 상태 변화, 애니메이션, 제스처, 협업 같은 요구사항을 별도로 정의하고, 실제 기기에서 반복적으로 프로토타이핑하며 프로젝트에 맞는 3D UX 원칙을 직접 구축하는 것이 바람직하다.

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

스마트 셀렉션 소개

Figma의 Smart Selection은 여러 객체의 간격, 위치, 크기를 한 번에 조정해 반복적인 디자인 작업을 줄이는 기능이다. 세 개 이상의 객체가 일정한 간격으로 선택되면 캔버스 위에서 직접 조작할 수 있으며, Tidy Up을 사용하면 흐트러진 객체도 균일하게 정렬된다. 이를 통해 디자이너는 수작업보다 탐색과 창의적인 결정에 더 집중할 수 있다. ## 반복적인 디자인 작업의 자동화 - 리스트나 아이콘 그룹의 간격을 바꾸려면 기존에는 각 객체를 개별적으로 이동하고 크기를 조정해야 했다. - 예를 들어 리스트 항목의 높이를 변경할 때 여러 번의 크기 조정과 이동 작업이 필요했다. - Smart Selection은 컴퓨터의 반복·재사용 능력을 디자인 작업에 적용해 이런 “잡일”을 줄이는 것을 목표로 한다. ## 캔버스에서 작동하는 Smart Selection - 세 개 이상의 객체 또는 그룹을 선택하고, 객체 사이의 간격이 일정하면 자동으로 활성화된다. - 별도의 도구나 새로운 객체 유형을 배울 필요 없이 기존 캔버스 조작 방식 안에서 사용할 수 있다. - 선택한 객체 전체의 다음 속성을 한 번에 조정할 수 있다. - 객체 사이의 간격 - 객체의 위치와 배열 - 선택한 객체의 크기 ## 핸들을 이용한 직접 조작 - 객체 사이에 표시되는 분홍색 핸들을 드래그하면 전체 객체의 간격을 동시에 조정할 수 있다. - 분홍색 링을 드래그하면 객체의 순서와 배치를 빠르게 재배열할 수 있다. - 하나 이상의 객체에 있는 분홍색 링을 클릭하면 해당 객체를 대상으로 지정할 수 있다. - 지정한 객체의 가장자리를 드래그하면 여러 객체의 크기를 함께 변경할 수 있다. ## Tidy Up으로 균일하게 정렬하기 - Tidy Up은 정렬되지 않은 객체들을 서로 가깝게 배치하면서 간격을 동일하게 맞춰준다. - 기존의 단순한 “분배” 기능보다 객체 간 간격을 항상 균일하게 유지하는 점이 특징이다. - 표, 툴바, 화면 플로우처럼 여러 요소를 일정한 간격으로 배치해야 하는 작업에 유용하다. - 예를 들어 20개의 화면을 직접 정렬하면 19개의 간격을 일일이 확인해야 하지만, Tidy Up을 사용하면 한 번의 실행으로 정리할 수 있다. - 단축키: - macOS: `⌥⌘T` - 기타 플랫폼: `Ctrl+Alt+T` ## 향후 확장 - Figma는 Smart Selection에 2차원 그리드 지원을 추가할 계획이라고 밝혔다. - 사용자의 실제 활용 사례와 피드백을 바탕으로 기능을 발전시키려 했다. Smart Selection은 여러 객체를 반복적으로 맞추고 이동해야 하는 디자인 작업에서 특히 효과적이다. 먼저 객체를 대략 배치한 뒤 Tidy Up으로 간격을 정리하고, Smart Selection 핸들로 세부 조정을 진행하면 작업 시간을 줄일 수 있다.

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

Figma의 새로운 핑거

Figma는 키보드 단축키를 익히는 일이 마우스 조작보다 어렵지만, 숙련되면 손의 운동기억을 통해 작업 속도와 몰입을 크게 높일 수 있다고 설명합니다. Douglas Engelbart의 마우스·키셋 시연에서 영감을 받아, 사용자의 작업 흐름에 맞는 단축키를 쉽게 발견하고 연습하도록 새로운 키보드 단축키 패널을 도입했습니다. 이 패널은 작업 유형별 단축키를 보여주고, 사용자가 누른 단축키를 강조해 학습을 돕습니다. ## 엥겔바트의 시연과 양손 입력 - 1968년 Douglas Engelbart는 문서 작성, 그래픽 추가, 문서 간 링크, 원격 협업과 채팅을 한 자리에서 보여주는 획기적인 컴퓨터 시연을 진행했습니다. - 오른손에는 마우스, 왼손에는 키셋을 사용했습니다. - 마우스로 단어를 가리키는 동시에 왼손으로 `DW(Delete Word)`를 입력해 단어를 삭제하는 방식이 핵심 장면으로 소개됩니다. - 마우스가 “무엇을 선택할지” 지정한다면, 키셋은 “선택한 대상에 무엇을 할지” 명령하는 역할을 했습니다. - 반복적인 손동작이 운동기억에 저장되면 피아노 연주나 춤처럼 의식적으로 동작을 계산하지 않고도 작업할 수 있습니다. ## Figma 작업과 키보드 단축키 - 숙련된 Figma 사용자는 캔버스를 이동하고, 객체 스타일을 바꾸고, 디자인을 생성하는 과정을 손을 보지 않고 빠르게 수행합니다. - 이는 Engelbart의 방식처럼 한 손은 마우스에, 다른 손은 키보드에 두는 입력 방식과 유사합니다. - 마우스는 초보자도 쉽게 익힐 수 있지만, 키보드 단축키는 탐색과 반복 연습을 통해 운동기억에 정착시켜야 합니다. - 단축키가 익숙해지면 도구 자체보다 해결하려는 디자인 문제에 집중하는 ‘몰입 상태’에 가까워질 수 있습니다. ## 기존 단축키 패널의 문제 - 기존 패널은 정보를 한눈에 파악하기 어려웠습니다. - 화면 전체를 차지해 단축키를 실제로 사용하면서 학습하기도 불편했습니다. - 단축키가 어떤 작업과 연관되는지 쉽게 탐색하기 어려웠습니다. ## 작업 중심의 새로운 단축키 패널 - 새 패널은 캔버스 아래쪽에 표시되어 작업 화면을 과도하게 가리지 않습니다. - 화면 오른쪽 아래의 물음표 메뉴에서 **Keyboard Shortcuts**를 선택하거나 `Ctrl+Shift+?`로 열 수 있습니다. - 작업 유형별 카테고리를 제공해 현재 작업에 필요한 단축키를 바로 찾아볼 수 있습니다. - 벡터 작업: 도형 편집, 구부리기 등 - 타이포그래피 작업: 글꼴 관련 단축키 - 양손 사용이 필요한 유용한 조합을 별도 탭에서 소개합니다. - 예: `Alt`를 누른 채 마우스를 움직이면 객체 간 거리나 크기를 쉽게 측정할 수 있습니다. - 초보자를 위한 기본 단축키 탭도 제공합니다. - 예: `⌘+\`를 사용하면 화면의 부가 UI를 숨기고 작업에 집중할 수 있습니다. - 작성자는 `Shift+2`가 선택 항목을 화면에 맞게 보여주는 기능을 제공한다는 점도 새롭게 발견했다고 설명합니다. ## 사용 행동을 반영하는 학습 방식 - 패널은 사용자가 실제로 누른 단축키를 감지하고 해당 항목을 강조합니다. - 사용자가 어떤 단축키를 사용했는지 기억해 이후 학습에 활용할 수 있도록 설계되었습니다. - 단축키 목록을 단순히 읽는 대신, 자신의 작업 패턴을 돌아보고 사용하지 않던 관련 단축키를 발견하도록 돕는 것이 목적입니다. Figma의 접근 방식은 단축키를 별도의 암기 과제가 아니라 실제 작업 흐름 속에서 익히도록 만드는 데 초점이 있습니다. 자주 수행하는 작업의 카테고리부터 선택해 단축키를 반복 사용하고, 마우스와 키보드의 조합을 운동기억으로 정착시키는 것이 가장 실용적인 활용법입니다.

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

API 챌린지 과정에서의

Figma는 Sketch 내보내기 API 챌린지가 디자이너에게 무보수 작업을 요구하는 ‘스펙 워크’로 받아들여질 수 있음을 인정하고 사과했다. 개방적인 디자인 생태계를 만들고자 했던 취지는 타당했지만, 창작 노동의 가치를 충분히 고려하지 못한 것이 문제였다. Figma는 챌린지를 중단하고 대안을 검토했으며, 2018년 11월에는 해당 챌린지를 어떤 형태로도 진행하지 않기로 결정했다. ## API 챌린지의 목적 - Figma는 **Figma 파일을 Sketch 형식으로 내보내는 기능**을 만들기 위한 API 챌린지를 시작했다. - 목표는 다음과 같았다. - Figma를 중심으로 한 개방적인 디자인 도구 생태계 조성 - Figma 데이터를 외부로 가져갈 수 있는 다양한 방법 지원 - 관련 기능이나 도구 개발에 필요한 자금 지원 - 회사는 기술 생태계를 확장하려는 의도에서 이 프로그램을 기획했다. ## ‘스펙 워크’로 비친 문제 - 디자이너 커뮤니티는 챌린지가 실제 결과물을 요구하면서도 참가자가 보상을 받지 못할 수 있다는 점을 지적했다. - 이러한 구조는 기업이 업무에 활용할 수 있는 창작물을 여러 참가자에게 무상으로 제작하게 하는 **스펙 워크(spec work)**로 해석될 수 있었다. - Figma는 창작자가 정당한 대가를 받아야 한다고 믿어왔지만, 개방형 생태계에 대한 열정 때문에 이 원칙을 이번 기획에 충분히 적용하지 못했다고 인정했다. - 특히 숙련된 창작 노동자가 착취되어 온 업계의 역사와 커뮤니티의 우려를 간과한 점이 핵심적인 실수였다. ## Figma의 대응과 사과 - Figma는 커뮤니티의 비판을 접한 뒤 해당 챌린지를 즉시 중단했다. - 기존 방식으로는 진행하지 않고, 참가자에게 무보수 작업을 요구하지 않는 새로운 구조를 검토하겠다고 밝혔다. - 당시에는 1~2주 안에 챌린지를 재설계해 다시 시작할 가능성을 언급했다. - 커뮤니티의 건설적인 피드백에 감사를 표하고, 디자인 생태계를 더 개방적이고 공정하게 만들겠다고 약속했다. ## 최종 결정 - 2018년 11월 19일 업데이트에서 Figma는 커뮤니티의 우려를 고려해 **이 챌린지를 어떤 형태로도 당분간 진행하지 않기로 결정**했다. - 따라서 단순히 운영 방식을 수정하는 수준을 넘어, 해당 프로젝트 자체를 보류하는 결론에 도달했다. ## 실용적인 시사점 - 오픈 생태계나 커뮤니티 프로그램을 설계할 때도 참여자의 노동이 기업 가치로 전환되는지 먼저 검토해야 한다. - 결과물을 요구하는 공모전이나 API 챌린지는 보상, 사용권, 선정 기준을 명확히 제시해야 한다. - 좋은 기술적 목표라도 창작자의 권리와 보상 구조를 고려하지 않으면 커뮤니티의 신뢰를 잃을 수 있다.

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

소개합니다: 피그

Figma는 디자인 생태계의 개방성을 강화하기 위해 Figma 파일을 Sketch로 변환하는 API 챌린지를 발표했다. 총 1만 5천 달러의 상금과 오픈소스 제출을 통해 개발자와 디자이너의 참여를 유도하려는 목적이었다. 다만 커뮤니티의 우려가 제기되면서 챌린지는 일시 중단되었고, 2018년 11월에는 당분간 진행하지 않기로 결정되었다. ## 개방형 디자인 플랫폼을 위한 API 챌린지 - Figma는 경쟁 제품인 Sketch로 파일을 내보내는 도구를 만들도록 참가자들을 초대했다. - 이는 특정 도구에 사용자를 묶어두기보다, 다양한 디자인 도구와 작업 방식을 연결하려는 Figma의 개방형 플랫폼 전략을 보여준다. - Figma는 이미 Sketch 파일 가져오기를 지원하고 있었으며, Sketch 내보내기는 그 생태계를 확장하는 자연스러운 다음 단계로 소개됐다. - 기존 API를 활용해 커뮤니티가 만든 스타일 가이드 생성기, Alexa 연동 등 다양한 프로젝트에서 영감을 받아 챌린지를 기획했다. ## 구현 대상: Figma에서 Sketch로의 변환 - 참가자는 Figma 객체로 구성된 두 개의 파일을 Sketch로 변환하는 exporter를 개발해야 했다. - 첫 번째 파일에는 기본 수준의 객체가 포함되어 비교적 명확한 변환 결과를 기대할 수 있었다. - 두 번째 파일에는 다음과 같은 복잡한 요소가 포함됐다. - 텍스트 및 타입 - 컴포넌트 - 스타일 - 프로토타입 - Figma와 Sketch의 기능이 항상 1:1로 대응하지 않기 때문에, 복잡한 파일은 단순한 변환 정확도뿐 아니라 창의적인 매핑 방식도 평가 대상이었다. ## 평가 기준과 제출 조건 - 심사는 객관적 기준과 주관적 기준을 함께 적용했다. - 평가 요소에는 다음이 포함됐다. - 두 파일의 디자인 요소를 얼마나 정확하게 전달하는지 - exporter의 사용 편의성 - Figma와 Sketch 간 차이를 해결하는 접근 방식의 창의성 - 코드 품질과 GitHub 문서화 수준 - 전체 점수의 5%는 코드 품질과 GitHub README 문서에 배정됐다. - 제출물은 GitHub 저장소 링크와 함께 제출해야 했으며, README와 MIT 라이선스를 포함해야 했다. ## 상금과 참가 방식 - 1등 상금은 1만 달러, 2등 상금은 5천 달러로 총상금은 1만 5천 달러였다. - 최대 3명까지 팀을 구성할 수 있었다. - 대부분의 국가에서 만 21세 이상이면 참가할 수 있었지만, 일부 국가에는 예외가 적용됐다. - 챌린지 기간은 2018년 10월 2일부터 11월 16일 오후 11시 59분(PST)까지로 예정됐다. ## 심사위원 구성 - 심사위원은 디자인 경험과 커뮤니티용 플러그인·도구 제작 경험을 함께 갖춘 인물들로 구성됐다. - GitHub의 디자인 시스템 엔지니어 Emily Plumme는 디자인과 개발을 연결하는 API 및 컴포넌트 시스템 경험을 보유했다. - Google의 인터랙션 디자이너 Raph D’Amico는 행동과학과 시스템 설계 관점에서 사용자 경험을 평가할 수 있는 배경을 갖췄다. - 접근성 도구 Stark와 Lyra를 만든 Cat Noone은 디자인 접근성과 윤리적 제품 설계에 전문성이 있었다. - Sketch Runner를 만든 디자이너 Roy van Rooijen은 디자인 도구와 플러그인 생태계에 대한 경험을 제공했다. ## 커뮤니티 반응과 챌린지 중단 - 발표 이후 커뮤니티에서 챌린지의 운영 방식과 관련한 우려가 제기됐다. - Figma는 이러한 의견을 반영해 챌린지를 일시 중단하고, 몇 주 뒤 재개하는 방안을 검토한다고 밝혔다. - 이후 2018년 11월 19일 업데이트에서 어떤 형태의 챌린지도 당분간 진행하지 않기로 결정했다. - 따라서 글에서 제시된 상금, 일정, 제출 조건은 최초 계획이며 실제로는 예정대로 진행되지 않았다. Figma의 시도는 경쟁 제품과의 호환성을 지원하는 것이 장기적으로 플랫폼의 신뢰와 확장성을 높일 수 있음을 보여준다. 다만 외부 커뮤니티를 대상으로 한 API 경연은 상품 범위, 평가 기준, 참가자 권리와 운영 방식에 대한 충분한 사전 검토와 소통이 중요하다는 교훈도 남겼다.

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

멀티플레이어, 현실 세계에서

Figma는 온라인 협업을 넘어 지역 기반의 오프라인 커뮤니티를 구축해 사용자들이 직접 교류하고 배우도록 하겠다고 발표했다. 디자인 시스템 밋업에서 얻은 호응을 바탕으로 20개 이상의 도시에서 Figma Local Communities를 시작했으며, 지역별 Designer Advocate가 커뮤니티 활동을 지원한다. 핵심은 제품 사용법뿐 아니라 디자인 조직 운영, 비평, 채용 등 실무 경험까지 공유하는 지속적인 네트워크를 만드는 것이다. ## 오프라인 밋업에서 확인한 커뮤니티 수요 - Figma는 4개 대륙, 8개 도시에서 Design System Meetup을 개최했다. - 참가자들은 단순한 기능 팁을 넘어 다음과 같은 주제를 논의했다. - 효과적인 디자인 크리틱 운영 방식 - 오픈 디자인 문화의 장단점 - 디자인 조직 간 협업과 파트너십 - 이러한 만남을 통해 사용자들이 온라인 협업뿐 아니라 직접 만나 경험과 문제를 공유하려는 수요가 크다는 점을 확인했다. ## Figma Local Communities 출범 - Figma는 전 세계 20개 이상의 도시에서 지역 커뮤니티를 시작했다. - 초기 대상 도시에는 아크라, 암스테르담, 베를린, 보스턴, 코펜하겐, 라고스, 런던, 뉴욕, 샌프란시스코, 시애틀, 텔아비브 등이 포함됐다. - 도시 선정에는 다음 요소를 함께 고려했다. - 이미 Figma 관련 밋업을 주도하는 지역 활동가의 존재 - 해당 지역의 Figma 사용자 집중도 - 다양한 지역과 국가를 아우르는 지리적 분포 - 커뮤니티는 Figma 사용법과 워크플로뿐 아니라 디자이너들이 실제로 겪는 성공과 어려움까지 공유하는 지원 공간을 목표로 한다. ## 지역 커뮤니티의 운영 방식 - 사용자는 다음 활동에 참여하거나 직접 제안할 수 있다. - 자신의 도시에 Figma 그룹 개설 - 지역 커뮤니티에서 다루고 싶은 주제 제안 - 워크숍, 밋업, 네트워킹 등 구체적인 행사 기획 - Figma는 각 지역의 요구를 본사가 일방적으로 정하기보다, 현지 사용자들이 무엇이 필요한지 직접 결정하도록 하려 한다. - 예시로는 다양한 배경의 디자인 팀을 채용하는 방법에 대한 워크숍, 프리랜서와 조직을 연결하는 스피드 네트워킹 등이 제시됐다. ## 지역별 Designer Advocate 팀 Figma는 커뮤니티의 의견을 수집하고 활동을 지원하기 위해 서로 다른 지역과 시간대에서 활동하는 Designer Advocate를 배치했다. - **Tom Lowry — 북미** - OpenText의 시니어 UX 디자이너 출신 - Figma 입문, 컴포넌트 구조화, 유연한 컴포넌트 설계 관련 교육 콘텐츠 제작 - Figma Material Design 리소스 키트와 디자인 포트폴리오 강의에도 참여 - **Zach Grosser — 유럽** - Square의 커뮤니케이션 디자이너 출신 - 2013년부터 Square 디자인 팀에 Figma를 도입한 초기 사용자 - 제품 기능 테스트와 디자인 교육에 적극적으로 참여 - 암스테르담으로 이주한 뒤 Figma에 합류 - **Namnso Ukpanah — 아프리카** - 라고스에서 Figma 디자인 시스템 밋업을 제안하고 300명 이상의 참가자를 이끌었다. - 11개 도시, 7개 국가에서 21명의 Figma 앰배서더를 온보딩했다. - 지역 디자이너와 개발자를 연결하는 현장 중심의 역할을 맡는다. ## 사용자 참여를 중심으로 한 확장 전략 - Designer Advocate는 지역 커뮤니티의 “현장 담당자” 역할을 하지만, 활동의 방향은 사용자 피드백에 따라 정해진다. - Figma는 각 도시의 구성원이 지역 상황에 맞는 행사와 주제를 제안하기를 기대한다. - 따라서 커뮤니티는 Figma가 일방적으로 제공하는 교육 채널이라기보다, 사용자들이 직접 운영하고 Figma가 지원하는 공동체에 가깝다. 실용적으로는 Figma를 배우는 데 그치지 않고, 지역 커뮤니티에 참여해 디자인 리뷰, 채용, 조직 운영 같은 실무 주제를 교류하는 것이 가장 큰 가치다. 거주 지역에 커뮤니티가 없다면 직접 그룹이나 행사를 제안하는 방식으로 네트워크를 확장할 수 있다.

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