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

figma3분 읽기큐레이션 요약

그잼 스크린 리더

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

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

디자인 시스템의 미래는 접근

디자인 시스템은 접근성을 제품 전반에 일관되게 적용할 수 있는 가장 강력한 기반이다. 공통 컴포넌트와 가이드에 접근성 기준을 내장하면 색상, 구조, 상호작용 등의 품질을 규모 있게 관리하고 변경 사항도 전체 제품에 전파할 수 있다. 앞으로는 WCAG 같은 표준과 AI 도구를 활용하되, 접근성을 사후 점검이 아닌 제품 개발 초기부터 우선순위로 삼아야 한다. ### 디자인 시스템과 접근성의 결합 - 전 세계 약 10억 명이 장애를 가지고 있으며, 이들의 연간 가처분소득은 약 1조 2천억 달러로 추정된다. - 접근성은 법적 의무나 체크리스트를 넘어 사용자 신뢰, 기업의 신뢰도, 성장 기회를 만드는 요소다. - 디자인 시스템에는 다음과 같은 접근성 기준을 포함할 수 있다. - 충분한 전경색·배경색 대비 - 접근성을 고려해 설계하고 테스트한 UI 컴포넌트 - 일관된 상호작용 규칙 - 구현자와 디자이너를 위한 구체적인 문서 - 공통 컴포넌트를 사용하면 한 번 수정한 접근성 개선 사항을 제품 전체의 컴포넌트 인스턴스에 확산할 수 있다. - 일관성, 문서화, 지속적인 피드백 구조가 접근성 실천을 조직 전체로 확장하는 기반이 된다. ### 접근성 확산을 돕는 디자인 시스템의 성장 - 2020년 Material Design 조사에서 기업 내부 디자인 시스템 구축은 전년 대비 22% 증가했다. - 응답자의 47%는 자신의 디자인 시스템에 접근성 가이드라인이 포함되어 있다고 답했다. - 디자인 시스템에 포함되는 대표 산출물은 다음과 같다. - 아이콘 라이브러리: 84% - UI 키트: 83% - 스타일 가이드: 75% - 컴포넌트 코드 라이브러리: 74% - WCAG 같은 표준, 접근성 도구의 발전, 법적·상업적 요구가 접근성 적용을 촉진하고 있다. - 그럼에도 2022년 기준 웹의 접근성 수준은 약 3%에 불과해, 실제 적용에는 여전히 큰 격차가 남아 있다. ### 접근성 분야의 책임 있는 AI 활용 - 디자인 시스템 팀은 AI를 활용해 접근성 문제를 더 빠르게 발견하고 개선하려 하고 있다. - 기사에서 언급하는 AI 기반 도구는 다음과 같은 작업을 자동화하는 것을 목표로 한다. - 이미지에 대체 설명 자동 생성 - 레이블이 없는 버튼에 적절한 레이블 추가 - 시맨틱 구조 도입 - 웹 접근성 문제 탐지 및 수정 - AI 도구는 접근성 검수와 반복 작업을 보조할 수 있지만, 자동화만으로 포괄적인 접근성을 보장할 수는 없다. - 생성된 설명이나 수정 결과가 실제 맥락에 적합한지 사람이 검토하고, 장애 당사자의 피드백과 표준 검사를 함께 활용해야 한다. ### 처음부터 접근 가능한 제품 만들기 - 접근성은 개발 완료 후 결함을 수정하는 단계가 아니라 디자인 시스템과 제품 설계 초기부터 포함해야 한다. - 공통 컴포넌트에 접근성 요구사항을 내장하면 개별 팀이 매번 같은 문제를 다시 해결하지 않아도 된다. - 색상, 컴포넌트 동작, 의미 구조, 문서화 등 모든 시스템 구성 요소에서 접근성을 점검해야 한다. - 접근성을 기본값으로 만들수록 제품 팀의 부담은 줄고, 전체 제품 생태계의 품질은 높아진다. ### 실용적인 적용 방향 - 디자인 토큰과 컴포넌트에 색상 대비, 키보드 탐색, 포커스 상태, 시맨틱 구조를 기본 규칙으로 포함한다. - WCAG 기준에 따라 자동 검사와 수동 테스트를 함께 운영한다. - AI는 반복적인 탐지·생성 작업에 활용하되 최종 판단은 전문가와 실제 사용자 검증을 거친다. - 접근성을 디자인 시스템의 부가 기능이 아니라 모든 컴포넌트의 필수 품질 기준으로 관리해야 한다.

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

피그마가 게임 세계에서 (새 탭에서 열림)

피그마는 단순한 웹 애플리케이션을 넘어 고성능 게임 엔진과 유사한 기술적 아키텍처를 기반으로 구축된 창의적 협업 도구입니다. 이 글은 피그마가 실시간 멀티플레이어 시스템, 물리 기반 애니메이션, 그리고 C++와 WebAssembly, Rust와 같은 고성능 스택을 통해 어떻게 디지털 세계를 구축하는지 설명합니다. 결과적으로 피그마는 게임 개발의 복잡한 시스템 상호작용 원리를 차용하여 사용자들에게 몰입감 있고 매끄러운 디자인 경험을 제공하고 있습니다. ## 디지털 세계를 구축하는 엔진으로서의 피그마 * 피그마의 핵심은 웹 기반의 2D 그래픽 및 렌더링 시스템으로, 이는 마인크래프트와 같은 게임 엔진의 근간과 동일한 구조를 가집니다. * 사용자가 생성하는 모든 텍스트, 도형, 선을 브라우저에서 실시간으로 구현하며, 방대한 캔버스에서의 팬(pan)과 줌(zoom) 조작 시에도 정확한 위치에 객체를 렌더링합니다. * 실시간 동시 편집 기능을 게임의 개념에서 착안한 '멀티플레이어(multiplayer)' 엔진이라고 명명하여 협업의 핵심 시스템으로 발전시켰습니다. * 브라우저 및 모바일 앱의 메모리와 성능 제약을 극복하기 위해 일반적인 웹 스택 대신 C++로 캔버스를 구축한 후 WebAssembly로 컴파일하여 로딩 속도를 3배 개선했으며, 서버 측 성능 향상을 위해 Rust 언어를 도입했습니다. ## 시스템 기반의 창의적 협업과 상호작용 * 게임 스튜디오에서 엔지니어와 아티스트가 협업하듯, 피그마 엔지니어들은 시스템의 한계를 밀어붙이기 위해 디자이너, PM, 데이터 과학자들과 긴밀하게 소통합니다. * '젤다의 전설: 브레스 오브 더 와일드'의 불(fire) 시스템이 빛, 온기, 공격 수단 등 다양한 방식으로 상호작용하는 것처럼, 피그마의 오토세이브, 멀티플레이어, 렌더링 시스템도 서로 유기적으로 연결되어 작동합니다. * 단순한 도구 기능을 넘어 스프링 물리 법칙을 적용한 애니메이션 시스템, 커서 채팅, 하이파이브 기능 등을 통해 사용자가 도구 내에서 살아있는 피드백을 느낄 수 있도록 설계했습니다. * 베리언트(Variants) 기능과 플러그인/위젯 시스템을 통해 디자인 컴포넌트와 코드를 긴밀하게 연결하고, 사용자가 직접 생태계를 확장할 수 있는 개방형 플랫폼을 지향합니다. 웹 환경에서 복잡하고 성능 집약적인 도구를 개발해야 한다면, 전통적인 웹 프레임워크의 틀을 벗어나 게임 엔진의 설계 방식과 고성능 언어(WASM, Rust) 도입을 검토해야 합니다. 기술적 한계를 극복하는 열쇠는 도구를 하나의 살아있는 '시스템'들의 집합으로 바라보고, 각 요소 간의 상호작용이 사용자 경험에 미치는 영향을 정교하게 설계하는 데 있습니다.

coupang원문

쿠팡 로켓배송: 공간 색인 기반의 새로운 배송 영역 관리 시스템 (새 탭에서 열림)

쿠팡은 급증하는 배송 물량과 복잡해지는 배송 환경에 대응하기 위해 기존의 텍스트 및 우편번호 중심 시스템에서 탈피하여 공간 색인 기술인 H3를 도입한 새로운 배송 영역 관리 시스템을 구축했습니다. 이 시스템은 배송 영역을 지도상에 시각화하고 데이터 기반으로 정교하게 분할할 수 있게 함으로써, 숙련자의 경험에만 의존하던 운영 방식에서 벗어나 누구나 직관적으로 배송 경로를 최적화할 수 있는 환경을 제공합니다. 결과적으로 공간 데이터 중심의 관리를 통해 신축 건물이나 지형 변화에도 유연하게 대처할 수 있는 로켓배송의 기술적 토대를 마련했습니다. **텍스트 기반 우편번호 체계의 한계** * 기존 시스템은 정부의 우편번호와 텍스트 주소에 의존했으나, 쿠팡의 성장에 따라 단일 우편번호 내 배송 건수가 한 명의 쿠친이 처리할 수 있는 범위를 초과하게 되었습니다. * 우편번호를 아파트 단지나 동 단위로 세분화해야 했으나, 텍스트 정보만으로는 공간적 위치를 파악하기 어려워 해당 지역에 능숙한 캠프 리더의 직관에만 의존하는 문제가 있었습니다. * 신축 건물의 등장이나 철거 등 지형적 변화가 발생했을 때 이를 시스템에 즉각적으로 반영하고 배송 영역을 조정하는 데 한계가 있었습니다. **H3 공간 색인 시스템의 도입** * 우버(Uber)에서 개발한 육각형 기반의 그리드 시스템인 H3를 도입하여 전 세계를 균일한 크기의 육각형 격자로 나누어 관리합니다. * 육각형 구조는 인접한 모든 이웃 격자와의 중심점 거리가 동일하여, 사각형이나 삼각형 격자보다 공간 분석 및 경로 최적화 계산에 훨씬 유리합니다. * 주소라는 텍스트 데이터 대신 위경도 기반의 공간 좌표를 사용함으로써 배송 영역의 경계를 더욱 명확하고 정교하게 설정할 수 있습니다. **시스템 재설계와 시각화 최적화** * 캠프 작업자들이 지도 위에서 배송 영역을 직접 확인하고, 마우스 클릭이나 드래그를 통해 영역을 생성, 수정, 공유할 수 있는 직관적인 UI를 구현했습니다. * 개별 육각형 격자들을 그룹화하여 하나의 다각형(Polygon) 형태로 변환하는 기술을 적용해 지도 렌더링 성능을 높이고 사용자 가독성을 개선했습니다. * 배송 밀도와 작업량을 격자 단위로 수치화하여 제공함으로써, 특정 영역에 업무가 쏠리지 않도록 균등하게 배송 물량을 배분할 수 있는 통계 기능을 강화했습니다. 물류 및 배송 시스템에서 주소는 더 이상 단순한 텍스트가 아닌 정교한 공간 데이터로 다뤄져야 합니다. 격자 기반의 공간 색인 시스템을 활용하면 운영 효율을 극대화할 수 있을 뿐만 아니라, 향후 자율주행 배송이나 드론 배송과 같은 미래 기술로 확장하기 위한 필수적인 데이터 구조를 확보할 수 있습니다. 이미 주소 기반 시스템의 한계를 느끼고 있는 물류 기업이라면 H3와 같은 공간 인덱싱 기술로의 전환을 적극적으로 검토할 것을 권장합니다.

datadog원문

fetch를 현실로 만들기: 범용 쿼리 및 렌더링 스케줄러 구축 (새 탭에서 열림)

데이터독(Datadog)은 복잡한 대시보드의 성능 최적화를 위해 쿼리와 렌더링 작업을 효율적으로 관리하는 범용 스케줄러를 개발했습니다. 기존의 복잡한 규칙 기반 시스템을 단순화하고 브라우저 네이티브 API를 활용함으로써, UI 응답성을 높이고 백엔드 부하를 안정화하는 성과를 거두었습니다. 이 글은 기존 스케줄러의 한계를 극복하고 모든 애플리케이션에 적용 가능한 유연한 스케줄링 모델로 전환한 과정을 다룹니다. ### 기존 스케줄러(v1)의 문제점 * **지나친 복잡성:** 약 20여 개의 매개변수가 얽힌 복잡한 휴리스틱(heuristics)으로 운영되어, 개발자가 시스템의 동작 방식을 예측하거나 추론하기 어려웠습니다. * **로직의 결합:** 쿼리(데이터 호출)와 렌더링(화면 표시) 스케줄링이 명확히 분리되지 않았습니다. 예를 들어, 렌더링 대기 작업이 많다는 이유로 연관 없는 쿼리 요청이 지연되는 등의 비효율이 발생했습니다. * **낮은 범용성:** 대시보드 환경에만 특화되어 설계되었기 때문에, 데이터독의 다른 제품군이나 일반적인 위젯 컴포넌트에서 재사용하기 어려운 구조적 한계가 있었습니다. ### 데이터 쿼리 스케줄링의 단순화 * **가시성 기반 우선순위:** 화면에 보이는(visible) 위젯의 쿼리는 요청 즉시 실행하고, 화면 밖(offscreen) 위젯은 별도의 대기열에 추가하여 지연 처리합니다. * **고정 시간 윈도우 알고리즘:** 복잡한 계산 대신 2,000ms라는 고정된 시간 창(window) 동안 최대 10개의 태스크만 실행하도록 제한하여 작업 분포를 평탄화했습니다. * **대기열 관리 최적화:** 백엔드에 펜딩된 요청이 너무 많으면 실행을 일시 중단하며, 화면 밖 작업들은 대기열에 들어온 순서대로 처리하여 공정성을 유지합니다. * **도입 결과:** 로직이 단순해졌음에도 불구하고 서버의 '429(Too many requests)' 에러가 크게 감소했으며, 쿼리 재시도 횟수가 줄어들어 전체적인 데이터 로딩 속도가 향상되었습니다. ### Browser Scheduling API를 활용한 렌더링 최적화 * **자원 상태 인지:** 기존 스케줄러는 브라우저의 CPU나 메모리 가용 상태를 알지 못한 채 작업을 할당했으나, 새로운 시스템은 브라우저 네이티브 기능을 활용합니다. * **우선순위 세분화:** 최신 `Browser Scheduling API`의 `postTask` 메서드를 도입하여 작업의 성격에 따라 우선순위(user-blocking, user-visible, background)를 부여합니다. * **효율적인 메인 스레드 사용:** 브라우저가 직접 작업의 우선순위를 제어하게 함으로써, 중요한 UI 업데이트는 즉시 처리하고 덜 중요한 렌더링은 브라우저가 유휴 상태일 때 실행하도록 최적화했습니다. 복잡한 웹 애플리케이션에서 성능을 확보하려면 스케줄링 로직을 최대한 단순화하고 브라우저가 제공하는 표준 API를 적극적으로 활용해야 합니다. 이는 개발자에게는 시스템에 대한 통제력을 제공하며, 사용자에게는 더 매끄러운 인터랙션 경험을 선사합니다.

datadog원문

fetch 실현하기: 범용 (새 탭에서 열림)

Datadog은 대규모 대시보드의 복잡한 데이터 페칭과 렌더링 성능을 최적화하기 위해 기존의 복잡한 휴리스틱 기반 스케줄러를 단순화하고 범용적인 시스템으로 재설계했습니다. 새로운 스케줄러는 쿼리와 렌더링 로직을 분리하고 가시성 중심의 작업 분배 알고리즘을 도입하여 백엔드 부하를 줄였으며, 최신 브라우저 스케줄링 API를 통해 런타임 성능을 극대화했습니다. 결과적으로 코드의 복잡성은 대폭 낮아졌고, API 호출 오류 감소와 함께 전반적인 사용자 경험이 향상되는 성과를 거두었습니다. ### 기존 스케줄러(v1)의 구조적 한계 * 20개 이상의 복잡한 매개변수와 서로 얽힌 휴리스틱으로 구성되어 있어, 개발자가 시스템의 동작을 예측하거나 유지보수하기 매우 어려웠습니다. * 쿼리(데이터 페칭)와 렌더링 스케줄링이 명확히 분리되지 않아, 렌더링 작업이 지연될 때 연관 없는 쿼리까지 함께 지연되는 비효율이 발생했습니다. * 대시보드 환경에만 특화된 로직으로 작성되어 있어, Datadog 내의 다른 제품이나 일반적인 위젯 컴포넌트에서 재사용하기 어려운 구조였습니다. ### 단순하고 효율적인 쿼리 스케줄링 알고리즘 * 화면에 보이는(Visible) 위젯의 쿼리는 즉시 실행하고, 비가시적 위젯의 쿼리는 큐에 쌓아 순차적으로 처리하는 단순한 방식을 채택했습니다. * 비가시적 쿼리는 2000ms의 고정된 시간 윈도우 내에서 최대 10개까지만 실행하도록 제한하여 백엔드 서비스의 부하를 안정화했습니다. * 브라우저가 자체적으로 처리하는 탭 포커스 여부 확인 등의 불필요한 체크 로직을 제거하여 관리 매개변수를 20개에서 6개로 줄였습니다. * 효율적인 작업 분산을 통해 '429(Too many requests)' 에러 발생률을 낮추었으며, 이는 결과적으로 재시도 횟수를 줄여 데이터 로딩 속도를 개선했습니다. ### Browser Scheduling API를 통한 렌더링 제어 * 브라우저의 CPU 및 메모리 자원 상태를 고려하지 못하던 기존 방식의 한계를 극복하기 위해 네이티브 브라우저 스케줄링 API(`postTask`)를 도입했습니다. * 작업을 중요도에 따라 `user-blocking`(사용자 차단), `user-visible`(사용자 가시), `background`(백그라운드) 세 단계로 분류하여 브라우저가 최적의 시점에 실행하도록 위임했습니다. * 중요도가 낮은 렌더링 작업은 브라우저가 유휴 상태일 때 실행되도록 설정하여 메인 스레드의 병목 현상을 방지하고 부드러운 UI 반응성을 확보했습니다. * `TaskController`를 활용해 특정 그룹의 작업 우선순위를 일괄 변경하거나 불필요한 작업을 즉시 중단(abort)할 수 있는 제어 구조를 갖추었습니다. 애플리케이션의 성능 최적화를 고려한다면 복잡한 자체 규칙을 만들기보다 가시성(Visibility)과 같은 핵심 지표에 집중하고, 최신 브라우저가 제공하는 스케줄링 표준 API를 활용하여 시스템 자원을 효율적으로 관리하는 것이 바람직합니다.

figma3분 읽기큐레이션 요약

혁신적인 제품을 만드는 법:

좋은 제품은 명확한 목표에서 출발한다. 관리자는 조직의 내부 목표보다 고객의 문제와 가치에 집중하고, 고객을 개발 과정에 참여시키며, 실행 가능한 아이디어를 선별하도록 팀을 이끌어야 한다. 프로토타입과 체계적인 질문을 활용하면 의사결정을 빠르게 하고, 고객에게 실제 가치를 제공하는 제품에 집중할 수 있다. ## 고객과 OKR을 구분해 설계하기 - 조직의 구조나 부서별 목표를 그대로 제품에 반영하는 ‘조직도 중심 설계’를 피해야 한다. - 좁게 정의된 제품 요구사항이나 국소적으로 최적화된 OKR만 따르면 고객의 실제 문제를 놓칠 수 있다. - 로드맵과 계획을 시각화하면 제품의 가치 제안이 조직 전체에 어떻게 연결되는지 파악하기 쉽다. - 디지털 프로토타입은 아이디어를 최종 형태까지 구체화해 경영진과 빠르게 검토할 수 있게 한다. - 프로토타이핑은 단순한 업무 투명성 확보를 넘어, 해당 해결책이 올바른 문제를 해결하는지 판단하게 해준다. ## 고객을 공동 제작자로 참여시키기 - Ironclad는 고객들이 제품을 예상과 다르게 사용하는 현상을 발견한 뒤, 10~15명의 고객으로 라운드테이블을 구성했다. - 고객 의견은 이후 18개월간의 제품 로드맵에 큰 영향을 미쳤다. - 일부 고객은 아이디어 구상부터 FigJam을 통한 디자인 검토, 베타 테스트까지 참여했다. - 공동 제작은 고객의 전문성을 활용하는 것뿐 아니라 제품 결과에 대한 고객의 관심과 투자도 높인다. - 고객과 함께 만들면 팀은 실제 사용 맥락에서 벗어나지 않고, 고객 역시 제품 방향에 대한 기대와 신뢰를 갖게 된다. ## 아이디어가 너무 많을 때의 세 가지 질문 - 협업 도구가 발전하면서 팀이 짧은 기간에 수십 개의 아이디어를 만들어내는 상황이 생길 수 있다. - Work & Co.는 IBM Research의 R&D 플랫폼 프로젝트에서 몇 주 만에 약 50개의 아이디어를 도출했다. - 모든 아이디어를 고객이나 클라이언트에게 제시할 수 없으므로, 실행 가능성을 기준으로 압축해야 한다. - 다음 세 가지 질문이 아이디어를 현실에 맞게 평가하도록 돕는다. - 이 플랫폼은 왜 존재해야 하는가? - 무엇을 해야 하는가? - 우리는 그것을 어떻게 만들 것인가? - 흥미롭기만 한 아이디어보다 실제로 출시할 수 있는 아이디어를 선택하는 것이 중요하다. ## 아이젠하워식으로 우선순위 유지하기 - 방향을 정한 뒤에는 팀이 핵심 과제에서 벗어나지 않도록 우선순위를 관리해야 한다. - Oura Ring의 매니저는 아이젠하워 매트릭스를 활용하는 전략을 소개한다. - 아이젠하워 매트릭스는 업무를 중요도와 긴급도에 따라 분류해, 무엇을 먼저 처리하고 무엇을 위임하거나 미룰지 판단하는 방식이다. - 제품 개발에서는 고객 가치가 크고 즉시 대응이 필요한 과제에 집중하고, 중요하지 않은 작업이 팀의 시간을 잠식하지 않도록 관리하는 데 활용할 수 있다. 관리자는 아이디어를 많이 만드는 사람보다 고객 문제를 명확히 정의하고, 실행 가능성을 검증하며, 팀의 우선순위를 지켜주는 사람에 가까워야 한다. 고객 인터뷰와 공동 제작, 프로토타입, 세 가지 핵심 질문, 우선순위 매트릭스를 함께 사용하면 조직 목표가 아니라 실제 고객 가치에 기반한 제품을 만들 가능성이 높아진다.

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

데이터베이스 아키텍처

Figma는 사용자와 기능 증가로 단일 PostgreSQL 데이터베이스의 CPU 사용률과 지연 시간이 급증하자, 장애 위험을 선제적으로 낮추기 위해 멀티 데이터베이스 구조로 전환했다. 단기적으로 인스턴스 확장, 읽기 복제본, PgBouncer 등을 도입했지만 쓰기 부하와 복제 지연 문제는 해결하지 못했다. 수평 샤딩이나 NoSQL 전환 대신, 연관된 테이블 그룹을 별도 데이터베이스로 옮기는 수직 파티셔닝을 장기 해법으로 선택했다. ## 단일 데이터베이스의 확장 한계 - Figma는 권한, 파일 정보, 댓글 등 대부분의 메타데이터를 하나의 대형 Amazon RDS 데이터베이스에 저장했다. - 데이터베이스 트래픽은 매년 약 3배씩 증가했다. - 2020년 피크 시간대 CPU 사용률이 65%를 넘었고, 사용량이 한계에 가까워질수록 지연 시간이 예측하기 어려워졌다. - 데이터베이스가 완전히 포화되면 Figma 전체가 작동을 멈출 수 있었기 때문에, 장애가 발생하기 전에 확장 문제를 해결할 필요가 있었다. ## 단기적인 안정화 조치 Figma는 장기적인 구조 변경을 준비하는 동안 약 1년의 추가 여유를 확보하기 위해 다음 조치를 시행했다. - RDS 인스턴스를 `r5.12xlarge`에서 `r5.24xlarge`로 확장해 CPU 처리 여력을 늘렸다. - 여러 개의 read replica를 구성해 읽기 트래픽을 분산했다. - 새로운 사용 사례에는 별도 데이터베이스를 사용해 기존 데이터베이스의 성장을 제한했다. - PostgreSQL 연결 풀러인 PgBouncer를 도입해 수천 개에 달하는 데이터베이스 연결이 주 데이터베이스에 미치는 영향을 줄였다. - PgBouncer는 애플리케이션과 RDS 사이에서 연결을 관리하고 재사용하는 계층으로 동작했다. ## 읽기 복제본만으로는 부족했던 이유 - 데이터베이스 사용량을 분석한 결과, 데이터 수집·수정·삭제와 같은 쓰기 작업도 상당한 부하를 차지했다. - 모든 읽기 요청을 replica로 옮길 수 없었다. - 일부 기능은 복제 지연(replication lag)에 민감해 최신 데이터가 반드시 주 데이터베이스에서 제공되어야 했다. - 따라서 읽기와 쓰기 양쪽 모두에서 원본 데이터베이스의 작업을 추가로 분산해야 했다. ## 수평 확장 방안의 검토 Figma는 테이블을 여러 데이터베이스에 분산하는 수평 샤딩도 검토했지만, 다음과 같은 부담이 있었다. - Figma가 사용하는 PostgreSQL과 기본적으로 호환되지 않는 관리형 수평 확장 솔루션이 많았다. - NoSQL이나 MySQL 기반 Vitess로 이전하려면 애플리케이션에 큰 변경이 필요했다. - 마이그레이션 과정에서 이중 읽기·쓰기 구조를 운영해야 하므로 복잡성이 커졌다. - PostgreSQL 호환 NewSQL을 선택하면 클라우드 환경에서 매우 큰 분산 PostgreSQL 클러스터를 운영하는 초기 고객이 될 위험이 있었다. - 관리형 솔루션은 내부 동작과 확장 한계를 통제하기 어렵고, Figma 규모에서 충분히 검증되지 않은 문제를 직접 겪을 수 있었다. - 직접 호스팅하면 운영 지식과 인력을 새로 확보해야 하며, 상당한 운영 비용이 발생했다. ## 테이블 그룹 단위의 수직 파티셔닝 Figma는 수평 샤딩 대신 수직 파티셔닝을 선택했다. - 수직 파티셔닝은 테이블 또는 컬럼을 다른 데이터베이스로 이동하는 방식이다. - Figma는 개별 테이블의 행을 여러 데이터베이스로 쪼개는 대신, 서로 관련된 테이블 그룹 전체를 별도 데이터베이스로 옮겼다. - 이 방식은 기존 데이터베이스의 부하를 즉시 줄일 수 있었다. - 장기적으로는 특정 테이블 그룹에 대해 향후 수평 샤딩을 적용할 수 있는 기반도 제공했다. - 기존 PostgreSQL 생태계와 애플리케이션 구조를 크게 바꾸지 않고 확장할 수 있다는 점이 장점이었다. ## 분할 대상 선정 기준 데이터베이스를 분리하기 전에 어떤 테이블을 옮길지 평가해야 했다. 주요 기준은 다음 두 가지였다. - **영향도(Impact)** - 테이블을 이동했을 때 데이터베이스 작업량이 크게 줄어야 했다. - Figma는 쿼리에 대한 평균 활성 세션 수(AAS)를 사용해 부하를 측정했다. - PostgreSQL의 `pg_stat_activity`를 10밀리초 간격으로 조회해 쿼리별 활성 상태와 CPU 대기 관련 정보를 분석했다. - **격리성(Isolation)** - 분리 대상 테이블이 다른 테이블과 강하게 결합되어 있지 않아야 했다. - 테이블 간 의존성이 높으면 데이터베이스 간 조인과 트랜잭션 처리가 복잡해지므로, 독립적으로 이동할 수 있는 영역을 우선했다. 결국 Figma의 접근 방식은 단일 데이터베이스를 무리하게 확장하는 대신, 부하가 크고 다른 기능과의 결합도가 낮은 테이블 그룹부터 별도 데이터베이스로 분리하는 것이었다. 실무에서도 먼저 읽기 부하뿐 아니라 쓰기 부하와 복제 지연을 함께 측정하고, 수평 샤딩보다 운영 복잡성이 낮은 수직 분할부터 검토하는 것이 현실적인 전략이다.

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

리틀 빅 아웃테이크 |

Figma의 30개 이상 소규모 기능 업데이트는 처음 계획한 대로만 구현된 결과가 아니라, 개발 과정에서 발견한 엣지 케이스와 팀의 피드백을 반영해 완성됐다. 다중 선택 검색은 계층 구조를 시각화해 사용자의 혼란을 줄였고, 오버레이 블러는 위치 정보를 전달하는 방식으로 해결했으며, 캔버스 미리보기는 범위를 과감히 줄여 빠르게 출시했다. 이 글은 작은 기능도 실제 사용 맥락과 예외 상황을 깊이 검토할 때 훨씬 나은 사용자 경험으로 이어진다는 점을 보여준다. ## 엣지 케이스에서 출발한 다중 선택 검색 - 기능: 검색 결과에서 `Shift + Click` 또는 `Cmd`(Windows에서는 `Ctrl`)를 사용해 원하는 항목만 여러 개 선택하고 편집·교체할 수 있다. - 기존 Find and Replace 기능을 확장하면 비교적 간단할 것으로 예상했지만, 실제 구현 과정에서 복잡한 문제가 드러났다. - Figma에서는 프레임·컴포넌트·그룹 같은 부모 객체와 그 안의 자식 객체를 서로 독립적으로 선택하기 어렵다. - 검색 결과에 부모와 자식이 동시에 나타나면, 두 번째 항목을 선택하는 순간 의도하지 않은 하위 항목까지 함께 선택될 수 있었다. - 중첩 구조가 많은 파일에서는 어떤 객체가 실제로 선택되는지 파악하기 어려워, 기능은 작동하지만 사용자에게는 버그처럼 느껴졌다. - 해결책으로 검색 사이드바에 시각적 계층 구조를 도입했다. - 자식 항목이 어느 부모에 속하는지 표시 - `Command` 또는 `Shift`를 누른 상태에서 선택될 항목을 미리 강조 - 자동으로 포함되는 간접 선택 항목과 직접 선택한 자식 항목을 구분 - 이 사례에서 엣지 케이스는 부수적인 예외가 아니라, 다중 선택 기능의 핵심 설계를 결정하는 요소가 됐다. ## 팀 피드백으로 해결한 오버레이 블러 - 기능: 프로토타이핑에서 배경 블러가 적용된 오버레이가 실제로 뒤의 콘텐츠를 흐리게 표시한다. - 기존 렌더링 방식은 프레임 바로 아래에 있는 대상을 가져와 블러 처리하는 방식이었다. - 하지만 오버레이는 일반 프레임처럼 바로 아래에 대상이 존재하지 않기 때문에 블러가 안정적으로 렌더링되지 않았다. - 엔지니어 Brandon은 가능한 해결책과 예상되는 문제를 문서로 정리해 팀에 공유했다. - 팀은 오버레이의 위치 정보를 코드에 전달해 어느 영역을 블러 처리해야 하는지 정확히 판단하도록 제안했다. - 이후 오버레이와 해당 프레임의 관계를 명확히 연결하는 데이터를 추가했다. - 그 결과 여러 오버레이가 각자의 위치에 올바르게 그려지고, 서로 겹치는 레이어도 정확하게 합성될 수 있었다. - 이 과정은 특히 새로 합류한 구성원이 자신의 접근 방식을 팀의 검토와 피드백으로 검증하면서 자신감을 얻은 사례이기도 하다. ## 범위를 줄여 완성도를 높인 캔버스 미리보기 - 기능: 디자인 패널의 옵션 위에 마우스를 올리면 설정을 확정하기 전에 캔버스에서 결과를 미리 볼 수 있다. - 초기에는 블렌드 모드와 효과뿐 아니라 다음 기능까지 포함하려 했다. - Boolean 연산 - 컴포넌트 속성 - 폰트 선택기 - 그러나 모든 기능을 한 번에 지원하려 하면 구현 범위와 기술적 복잡도가 크게 증가했다. - 팀은 Figma 편집기에서 드롭다운으로 제공되는 속성을 전수 조사한 뒤, 구현 난이도와 사용자 가치에 따라 우선순위를 정했다. - 최종적으로는 기하 구조를 크게 변경하거나 캔버스 렌더링 방식을 대폭 수정하지 않아도 되는 기능을 우선 구현했다. - 처음에는 기능 수가 적으면 충분한 가치가 없을 수 있다는 우려가 있었지만, 제한된 범위만으로도 미리보기 경험은 충분히 강력하다는 결론에 도달했다. - 작은 기능을 빠르게 출시하려면 모든 경우를 다 지원하기보다, 사용자에게 즉시 가치를 주면서 기술적 위험이 낮은 영역부터 선택하는 것이 효과적이다. ## 작은 업데이트를 만드는 방식 - 30개 이상의 기능은 거대한 단일 프로젝트가 아니라 여러 팀의 작은 개선과 반복적인 의사결정으로 만들어졌다. - 초기 아이디어를 그대로 구현하기보다 실제 사용 상황에서 발생하는 혼란과 실패 가능성을 먼저 확인했다. - 설계와 엔지니어링이 긴밀하게 협업하며 시각적 피드백, 데이터 구조, 구현 범위를 함께 조정했다. - 문서화와 팀 리뷰는 특히 복잡한 문제를 구조화하고, 새로운 구성원이 해결책을 검증하는 데 중요한 역할을 했다. - 결과적으로 “작은 기능”도 사용자의 선택 방식, 렌더링 구조, 프로젝트 범위 같은 세부 사항을 깊이 고려해야 완성도 높은 기능이 된다. 실무적으로는 기능을 설계할 때 정상 동작만 확인하지 말고, 중첩 구조·동시 선택·레이어 순서 같은 엣지 케이스를 초기에 테스트하는 것이 좋다. 동시에 모든 기능을 한 번에 구현하려 하기보다, 사용자 가치가 크고 구조 변경이 적은 범위부터 출시한 뒤 점진적으로 확장하는 접근이 현실적이다.

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

Figma 디자인 팀이 커리어

Figma는 조직과 제품이 성장하면서 기존의 모호한 디자인 커리어 레벨 체계만으로는 채용, 평가, 코칭을 일관되게 운영하기 어렵다고 판단했다. 이에 디자이너들의 의견과 외부 사례를 바탕으로 ‘좋은 디자인 역량’의 의미를 구체화하고, 제품 디자인·라이팅 직군을 위한 새로운 커리어 레벨과 Skills Widget을 만들었다. 특히 직급이 높아질수록 전문화되는 T자형 역량을 어떻게 평가할지, 그리고 디자인 크래프트를 어떤 행동과 결과로 설명할지가 핵심 과제였다. ## 기존 커리어 레벨 체계의 한계 - 2021년 당시 Figma의 기존 레벨 문서는 초기 조직 규모에 맞춘 한 페이지짜리 Notion 문서였다. - 제품 전략, 디자인 크래프트와 품질, 동료의 성장 지원 등 중요한 영역은 포함했지만 조직 확장과 함께 충분히 구체화되지 못했다. - “복잡한 제품 문제를 해결할 수 있다”와 같은 표현은 주관적이고 모호해 성과 평가나 성장 대화에 활용하기 어려웠다. - ‘크래프트’가 시각 디자인, 프로토타이핑, 모션 디자인 등 무엇을 의미하는지 관리자들 사이에서도 합의가 부족했다. ## 구성원 의견을 통한 요구사항 조사 - Figma는 기존 레벨 문서를 어떻게 활용하는지, 새 문서가 어떤 질문에 답해야 하는지 설문했다. - 구성원들이 요구한 핵심 사항은 다음과 같다. - 각 레벨의 기대치를 판단할 수 있는 더 구체적인 설명 - 시니어 레벨에서 요구되는 역량과 승진 기준에 대한 명확성 - 디자인 크래프트를 구성하는 세부 기술과 행동의 체계적 설명 - 여러 구성원이 Slack, BuzzFeed, Meta, Basecamp 등의 커리어 레벨 문서를 참고 사례로 제시했다. - 디자이너 Shana Hu는 기존 문서를 상세히 분석하고, FigJam을 활용한 시각적 형식의 개선안을 제안했다. ## 시니어 디자이너와 T자형 역량 - 디자이너는 경력이 쌓일수록 모든 영역을 균등하게 잘하기보다 특정 분야에 강점을 가진 T자형 인재가 되는 경향이 있다. - 따라서 시니어 레벨에서 다음 중 무엇을 기대할지 명확히 해야 했다. - 모든 역량에서 고르게 뛰어난 수준을 계속 요구할 것인지 - 특정 전문 영역의 깊이와 조직에 미치는 영향력을 인정할 것인지 - 커리어 레벨 체계는 승진과 채용에서 전문화된 강점을 어떻게 평가할지 설명해야 하는 관리 도구가 되었다. ## 산업 사례 조사와 새로운 구조 설계 - 작성 과정에서 다양한 업계의 레벨링 사례를 조사하고 Figma 관리자들과 함께 참고 자료를 수집했다. - 새 체계에 반영하려 한 방향은 다음과 같다. - 역량을 영역별로 그룹화하기 - 경력을 일직선으로 올라가는 ‘사다리’보다 다양한 경로를 의미하는 ‘단계’ 또는 ‘레벨’이라는 표현 사용 - 긴 텍스트보다 빠르게 훑고 이해할 수 있는 시각적 형식 채택 - 최종적으로 Figma는 여러 핵심 스킬 영역을 정의하고, 각 영역에 포함될 구체적인 역량을 정리하는 초안을 작성했다. - 이 작업은 처음에는 ‘크래프트의 정의를 개선하는 일’로 시작했지만, 결과적으로 전체 커리어 레벨 체계를 개편하는 프로젝트로 확장되었다. ## 성과 관리와 성장 지원을 위한 도구 - 새로운 문서는 각 레벨에서 기대되는 성과와 핵심 역량을 설명하는 자료로 설계되었다. - 관리자에게는 채용과 성과 평가를 더 일관되게 수행할 기준을 제공한다. - 디자이너에게는 현재 레벨에서 부족한 역량과 다음 단계로 성장하기 위해 투자할 영역을 보여준다. - Figma는 이를 FigJam 기반의 시각적 문서와 Skills Widget으로 제공해 접근성과 활용성을 높였다. 조직이 성장할수록 커리어 레벨은 추상적인 가치 선언이 아니라 관찰 가능한 행동, 기술, 영향력의 예시를 포함해야 한다. 또한 시니어 인재를 평가할 때 모든 영역의 균형보다 전문성의 깊이와 조직에 대한 기여를 함께 고려하는 구조가 실용적이다.

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

팀을 최대한 활용하는 방법 |

팀의 잠재력을 끌어내려면 관리자가 목표, 회의, 역할, 성장 기회를 설계해 구성원이 주도적으로 일할 수 있는 환경을 만들어야 한다. 핵심은 목표를 소수의 우선순위로 좁히고, 회의를 꼭 필요한 경우에만 운영하며, 직책보다 좋은 아이디어와 실험을 중시하는 것이다. 팀의 성공은 구성원이 몰입하고 성장할 수 있는 업무 환경을 만드는 관리자의 성공과도 연결된다. ## 목표는 세 가지 우선순위로 좁힌다 - 구성원에게 분기나 반기 초에 자신이 이루고 싶은 목표를 먼저 작성하게 한다. - 처음에는 10~15개의 목표가 나올 수 있지만, 최종적으로는 **세 가지 핵심 우선순위**만 남긴다. - 목표를 줄이는 과정에서 실제 기간 안에 달성할 수 있고, 높은 완성도로 수행할 수 있는 일에 집중하게 한다. - 목표는 회사의 가장 중요한 전략적 과제와 연결해야 한다. - “무엇을 할 것인가”뿐 아니라 목표가 만들어낼 **영향을 구체적·정량적으로 표현**하도록 돕는다. - 확정된 목표를 다른 리더들과 공유해 조직 전체의 정렬과 책임감을 높인다. ## 회의는 반드시 필요한 순간에만 연다 - Work & Co.는 하루에 한 번 아침 체크인만 진행한다. - 전날 완료한 일 - 당일의 다음 단계 - 필요한 협업 사항 - 나머지 시간은 방해 없이 개인 작업이나 공유 파일 기반 협업에 사용한다. - 회의가 많아질수록 집중해서 결과물을 만들 시간이 줄어들기 때문에, Slack이나 FigJam으로 해결할 수 있는 사안은 회의로 만들지 않는다. - 회의를 줄이기 어렵다면 회의 목적과 진행 방식을 더 명확하게 설계해야 한다. ## 발언이 적은 사람도 참여할 수 있는 회의 구조를 만든다 - Twitch는 Amazon식 6쪽 문서 회의 형식을 하이브리드 업무에 맞게 적용했다. - 참석자는 회의 전에 공유 문서를 읽고, 10~15분 동안 질문과 의견을 문서에 주석으로 남긴다. - 이후 회의에서는 문서에 달린 의견을 중심으로 논의한다. - 즉흥적으로 말하는 데 익숙한 사람만 유리한 ‘자유 발언식 회의’의 문제를 줄인다. - 문서, FigJam 스탠드업 등 구성원이 편한 방식으로 생각을 표현하게 하면 참여의 형평성과 회의의 효율이 높아진다. ## 직책보다 좋은 아이디어를 가치 있게 만든다 - 역할이 모호하면 업무 충돌과 영역 다툼이 생길 수 있다. - 반대로 직무를 지나치게 상세하게 규정하면 새로운 업무나 혁신적인 아이디어가 등장할 여지가 줄어든다. - Oura Ring은 모든 캠페인과 프로젝트를 실험으로 간주한다. - 좋은 아이디어는 강한 가설에서 시작하고, 결과를 측정한 뒤 다음을 결정한다. - 확대할지 - 반복 적용할지 - 중단할지 - 새로운 아이디어를 내는 일을 특정 직무의 책임으로 제한하지 않고 모두의 책임으로 본다. - 구성원이 새로운 일을 시도하거나 기존 역할의 경계를 잠시 넘는 것을 허용하면 아직 존재하지 않는 중요한 역할과 기회도 발견할 수 있다. - 영향력을 만들려는 시도를 조직이 과도하게 막지 않는 것이 중요하다. ## 경력 대화를 시각화하고 함께 설계한다 - 경력은 직선적인 승진 경로가 아니라 다양한 방향으로 움직일 수 있다. - 관리자는 구성원이 가능한 경로와 미래의 선택지를 상상하도록 도와야 한다. - 특히 원격 근무 환경에서는 우연한 만남이나 비공식 네트워킹이 줄어들기 때문에 의도적인 경력 대화가 더 중요하다. - 글에서는 이를 “경력 대화를 스토리보드로 구성하기”라는 방식으로 제시하지만, 제공된 내용에는 구체적인 실행 방법까지 이어지지 않는다. 구성원에게 많은 일을 맡기는 것보다 중요한 것은 무엇을 하지 않을지 결정하도록 돕는 일이다. 목표를 소수로 제한하고, 회의를 정교하게 운영하며, 누구나 아이디어를 실험할 수 있게 만들면 팀의 자율성·집중력·성장 가능성을 함께 높일 수 있다.

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

FigJam의 테이블 기능: 기준 (새 탭에서 열림)

FigJam은 팀원들이 정보를 더 효과적으로 구조화하고 로드맵을 작성할 수 있도록 새로운 '테이블' 기능을 도입했습니다. 복잡한 데이터 연산보다는 시각적 가독성과 직관적인 편집 경험에 집중하여, 디자이너뿐만 아니라 비전문가도 쉽게 협업 도구로 활용할 수 있도록 설계된 것이 특징입니다. 특히 멀티플레이어 환경에서의 데이터 충돌을 해결하고 사용자의 줌(Zoom) 수준에 따른 최적화된 UI를 제공함으로써 FigJam만의 독특한 사용성을 완성했습니다. ## FigJam 테이블의 지향점: 단순함과 시각적 전달 * 엑셀이나 구글 스프레드시트 같은 복잡한 데이터 조작보다는 정보를 시각적으로 명확하게 전달하는 데 우선순위를 두었습니다. * 사용자들이 기존에 스티키 노트나 도형을 조합해 수동으로 표를 만들던 불편함을 해소하고, 네이티브 기능을 통해 성능과 사용성을 동시에 개선했습니다. * 기획서(PRD) 작성, 프로젝트 진행 상황 추적, 브레인스토밍 결과 정리 등 협업 과정에서 발생하는 다양한 시나리오를 지원합니다. ## 제작자와 사용자 모두를 고려한 디자인 시스템 * 툴바 클릭 한 번으로 미리 정의된 스타일의 테이블을 생성할 수 있어, 사용자가 폰트나 간격을 일일이 조정하는 번거로움을 줄였습니다. * 새로운 행이나 열을 추가할 때 이전 셀의 스타일(색상, 속성 등)을 자동으로 상속받아 시각적 일관성을 유지합니다. * 테이블 전체 색상을 변경하면 내부 텍스트 색상이 배경에 맞춰 자동으로 반전되거나 조정되어 최적의 가독성을 보장합니다. ## 멀티플레이어 환경을 위한 엔지니어링 * 여러 사용자가 동시에 서로 다른 셀을 편집하거나 같은 위치에 데이터를 입력할 때, 단순한 '덮어쓰기'가 아닌 데이터가 적절히 병합(Merge)되도록 정교한 로직을 구현했습니다. * 개발 시간의 50% 이상을 멀티플레이어 관련 버그 수정과 예외 상황 처리에 투입하여 실시간 협업의 안정성을 확보했습니다. * 다수의 사용자가 동시에 작업할 때 UI가 화면을 가리거나 혼란을 주는 것을 방지하기 위해, 편집 도구가 마우스 커서를 따라다니는 '호버(Hover)' 방식을 채택했습니다. ## 컨텍스트에 반응하는 스마트 인터렉션 * 사용자의 화면 확대/축소(Zoom) 비율에 따라 인터페이스가 유동적으로 변합니다. * 화면을 멀리서 볼 때는 테이블 이동 및 전체 구조 재배치 기능에 집중하고, 화면을 가까이 확대하면 셀 세부 편집이나 행/열 추가 버튼이 활성화되어 화면의 혼잡도를 낮췄습니다. * 이를 통해 사용자는 작업의 맥락에 맞는 기능만 직관적으로 노출받으며 작업 효율을 높일 수 있습니다. **결론 및 추천** FigJam 테이블은 강력한 기능보다 사용자의 '자연스러운 협업 흐름'을 중시한 결과물입니다. 복잡한 수식이나 데이터 분석보다는 팀원 간의 아이디어 공유, 일정 관리, 회의록 정리 등 정보의 시각화가 필요한 팀에게 강력히 추천합니다.

figma원문

창작자가 필요합니다 (새 탭에서 열림)

Figma는 크리에이터 생태계의 지속 가능한 성장을 위해 새로운 판매 도구와 'Figma 크리에이터 펀드(Figma Creator Fund)'를 도입했습니다. 이번 업데이트는 리소스 제작자가 라이선스 관리나 결제 시스템 구축 같은 행정적 부담에서 벗어나 오직 창작 활동에만 집중할 수 있는 환경을 조성하는 데 목적이 있습니다. 이를 통해 유료 리소스의 투명한 거래를 지원하는 한편, 무료 리소스를 공유하는 창작자들에게도 경제적 보상을 제공하여 커뮤니티의 건강한 선순환을 도모하고자 합니다. **창작 활동의 지속 가능성을 가로막는 장애물** * 플러그인이나 디자인 시스템을 구축하는 제작자들은 리소스 개발 외에도 호스팅, 결제 처리, 환불 관리, 라이선스 키 발급 등 복잡한 비즈니스 운영 업무를 직접 감당해야 했습니다. * 이러한 운영상의 번거로움은 창작자의 열정을 저해하고, 고품질의 작업물을 지속적으로 커뮤니티에 공유하는 것을 어렵게 만드는 주요 원인으로 작용했습니다. * Figma는 창작자가 '비즈니스 관리자'가 아닌 '제작자' 본연의 역할에 충실할 수 있도록 플랫폼 차원의 통합 솔루션을 제공하기로 했습니다. **통합 판매 도구와 강력해진 API 지원** * 제작자는 이제 일회성 클릭 결제 시스템을 활용할 수 있으며, 복잡한 라이선스 키 관리나 파일 이메일 전송 없이도 사용자에게 리소스를 안전하게 전달할 수 있습니다. * 유료 리소스 개발을 위해 기존보다 더욱 강력하고 고도화된 유료 전용 API에 접근할 수 있는 권한이 부여됩니다. * 새롭게 도입된 대시보드를 통해 리소스의 도달 범위와 영향력을 정밀하게 파악할 수 있는 지표 분석 기능을 제공합니다. * 구매자는 '구매 전 체험(Try-before-you-buy)' 기능을 통해 리소스를 미리 확인해 볼 수 있으며, 유료와 무료 리소스가 명확하게 라벨링되어 있어 탐색 효율이 높아집니다. **무료 기여자를 위한 Figma 크리에이터 펀드** * 커뮤니티에 무료 리소스를 제공하는 제작자들의 노고를 기리기 위해 보조금을 지원하는 크리에이터 펀드가 신설되었습니다. * 단순히 '인지도'를 쌓는 것만으로는 전문적인 성장을 지속하기 어렵다는 점을 반영하여, 무료 오픈소스 문화를 유지하면서도 제작자의 시간을 가치 있게 평가하는 보상 체계를 마련했습니다. * 이를 통해 창작자는 가족이나 생계 등 현실적인 제약 속에서도 커뮤니티에 지속적으로 기여할 수 있는 경제적 토대를 얻게 됩니다. Figma 커뮤니티에서 활동하는 제작자라면 이번에 도입된 판매 도구와 크리에이터 펀드를 적극적으로 활용해 보시기 바랍니다. 혁신적인 아이디어를 유료 모델로 전환해 수익을 창출하거나, 펀드 지원을 통해 무료 리소스를 배포하며 영향력을 넓히는 등 자신에게 맞는 방식으로 창작 여정을 지속할 수 있습니다. 구체적인 신청 방법과 기술적 가이드는 Figma의 릴리스 노트를 통해 확인할 수 있습니다.

figma원문

메이커를 만나다: 마 (새 탭에서 열림)

Figma의 디자인 매니저 마르신 위치하리(Marcin Wichary)는 150년의 키보드 역사를 다룬 저서 'Shift Happens'를 집필하며, 소프트웨어 개발 방법론인 '프로토타이핑'을 도서 제작 공정에 도입했습니다. 그는 단순히 글을 쓰는 것에 그치지 않고 직접 플러그인을 개발하고 빈티지 하드웨어를 복원하는 등 기술적 탐구를 병행했으며, Figma를 활용해 디자인과 피드백 과정을 혁신적으로 효율화했습니다. 이 프로젝트는 일상의 도구를 깊이 있게 탐구하는 제작자(Maker)의 태도와 현대적인 디자인 도구가 전통적인 출판 방식에 어떻게 새로운 흐름을 만들 수 있는지를 보여줍니다. #### 프로토타입 중심의 제작 방식 - 소프트웨어 개발과 유사하게 '생각하고, 구축하고, 사용해보고, 다시 개선하는' 프로토타이핑 사이클을 반복하며 책을 디자인했습니다. - 원고가 완성되기 전부터 사진을 배치하기 시작했으며, 텍스트와 이미지가 인쇄 프로그램에 자동으로 흐르도록 전용 플러그인과 소프트웨어를 직접 작성했습니다. - 오탈자를 점검하기 전인 초기 원고 단계에서 이미 주문형 인쇄(Print-on-demand)로 프로토타입을 제작하여 실제 물리적인 느낌과 레이아웃의 한계를 테스트했습니다. - 검정색 배경, 선명한 색상, 세밀한 디테일이 포함된 사진 등 '엣지 케이스(Edge cases)'에 해당하는 페이지들을 미리 인쇄해 봄으로써 잠재적인 인쇄 사고를 방지했습니다. #### 기술적 호기심과 제작의 즐거움 - 집필 과정의 번아웃을 방지하기 위해 빈티지 키보드를 역공학하여 현대 컴퓨터에 연결하거나, 피아노를 타자기로 개조하는 등 실험적인 '장난감' 프로젝트를 병행했습니다. - 80년대 키보드에서 주로 쓰였으나 디지털 폰트로 존재하지 않던 'Gorton' 서체를 Figma와 Glyphs를 활용해 직접 복원 및 디자인했습니다. - 타자기 시뮬레이터와 미니 게임 등을 제작하며 프로젝트에 대한 흥미를 유지했고, 이 과정에서 Figma의 폰트 UI 버그를 발견해 본업인 제품 개선에 기여하기도 했습니다. #### Figma를 활용한 디자인 시스템과 협업 - Figma의 오토 레이아웃(Auto Layout)과 플러그인을 활용해 복잡한 도서 레이아웃 작업을 자동화하고 관리했습니다. - 전 세계에 흩어져 있는 3D 렌더러 및 동료들과 Figma 공유 URL을 통해 실시간으로 소통하며, 캔버스 위에 직접 스케치하거나 댓글을 남기는 방식으로 피드백 루프를 단축했습니다. - 무드보드 제작부터 킥스타터 캠페인, 뉴스레터 디자인까지 모든 자산을 Figma에서 관리하며, 공식적인 디자인 시스템 없이도 일관성을 유지할 수 있는 환경을 구축했습니다. #### 피드백 수집의 혁신 - 전통적인 워드 프로세서 방식의 편집에서 벗어나, 지인들이 비밀 URL을 통해 이모지나 짧은 반응을 남길 수 있는 전용 피드백 앱을 직접 개발했습니다. - 피드백을 받는 과정을 하나의 '게임'처럼 만들어 참여자들에게 즐거움을 주는 동시에, 제작자 자신도 글쓰기에서 잠시 벗어나 개발자로서의 뇌를 환기하는 창구로 활용했습니다. 마르신 위치하리의 사례처럼 본업에서 사용하는 기술(소프트웨어 프로토타이핑, 플러그인 개발)을 개인적인 창작 프로젝트에 이식해 보세요. 과정을 세분화하고 각 단계마다 눈에 보이는 결과물을 만들어내는 방식은 거대한 프로젝트를 완수하는 데 실질적인 도움이 됩니다.

figma4분 읽기큐레이션 요약

디자인 시스템의 미래는

플러그인, 위젯, AI 기반 도구의 발전으로 디자인 시스템은 단순한 컴포넌트 모음에서 반복 작업을 자동화하고 디자인 의사결정을 보조하는 실행 환경으로 진화하고 있다. 이러한 자동화는 디자이너와 개발자의 역할을 없애기보다, 생산성을 높이고 더 높은 수준의 문제 정의·판단·창의적 작업에 집중하게 만들 가능성이 크다. 다만 자동 생성 결과를 검토하고 맥락에 맞게 조정하는 인간의 역할은 여전히 중요하다. ## 플러그인과 위젯의 등장 - 플러그인은 기존 소프트웨어의 기능을 확장하는 추가 도구이며, 디자인 소프트웨어와 함께 발전해 왔다. - 초기 플러그인은 텍스트 편집기와 출판 프로그램에서 효과, 브러시, 스타일 등을 추가하는 방식으로 사용됐다. - 오늘날에는 커뮤니티와 앱 마켓플레이스를 통해 사용자가 직접 만든 도구를 공유하고, 팀의 작업 방식에 맞게 Figma를 확장한다. - 디자인 시스템 관련 플러그인은 크게 두 유형으로 나뉜다. - 기존 작업 흐름을 자동화하는 도구 - 분석, 테스트, 접근성 개선 등 새로운 기능을 추가하는 도구 ## 반복 작업을 자동화하는 플러그인 - 여러 화면에 동일한 변경 사항을 적용하거나, 레이어와 컴포넌트를 정리하는 반복 업무를 자동화한다. - 디자인 토큰, 컴포넌트, 스타일을 일관되게 적용해 수작업에서 발생하는 누락과 실수를 줄인다. - 콘텐츠 삽입, 레이아웃 정리, 이름 변경, 문서화와 같은 작업도 자동화 대상이 될 수 있다. - 디자이너는 단순한 실행 업무보다 사용자 경험과 제품 문제를 정의하는 일에 더 많은 시간을 쓸 수 있다. ## 기능을 확장하는 플러그인 - 플러그인은 디자인 시스템의 사용 현황과 품질을 점검하는 기능을 제공한다. - 어떤 컴포넌트가 얼마나 사용되는지, 디자인 시스템이 실제 파일에서 제대로 활용되는지 분석할 수 있다. - 접근성 검사, 디자인 테스트, 개발 handoff, 코드 생성 등 기존 디자인 도구가 직접 제공하지 않던 기능도 보완한다. - 결과적으로 디자인 시스템은 정적인 라이브러리가 아니라 측정·검증·개선이 가능한 운영 체계가 된다. ## 정보를 시각화하고 정리하는 위젯 - 위젯은 캔버스 안에서 실행되는 상호작용형 도구로, 디자인 파일에 정보와 기능을 직접 배치할 수 있다. - 팀의 작업 현황, 의사결정, 일정, 피드백 등을 시각적으로 공유하는 데 활용된다. - 디자인 시스템의 규칙이나 컴포넌트 정보를 작업 공간 가까이에서 확인하게 해 협업과 커뮤니케이션을 돕는다. - 디자인 파일이 단순히 결과물을 보여주는 공간을 넘어, 팀이 함께 사고하고 정리하는 협업 공간으로 확장된다. ## AI가 강화하는 디자인 도구 - 2017년부터 저해상도 와이어프레임을 바탕으로 디자인 시스템과 코드를 자동 생성하려는 실험이 진행됐다. - 당시에는 가능성을 보여주는 프로토타입에 가까웠지만, 생성형 AI 기술의 발전으로 실제 제품화 가능성이 커졌다. - Diagram의 Genius와 같은 도구는 Figma 파일을 분석하고, 기존 디자인 시스템의 컴포넌트를 활용한 디자인 제안을 생성한다. - AI는 다음과 같은 작업을 보조할 수 있다. - 자연어를 기반으로 한 디자인 생성 - 기존 컴포넌트와 패턴 추천 - 디자인 파일 분석 및 개선안 제시 - 디자인에서 코드로의 변환 - AI가 디자인 시스템의 규칙을 학습할수록, 조직의 브랜드와 패턴에 맞는 결과를 더 빠르게 만들 수 있다. ## 자동화에 뒤처지지 않기 위한 변화 - 도구가 발전하면 디자인 시스템 팀은 새로운 플러그인과 AI 기능을 단순히 도입하는 것을 넘어, 조직의 작업 흐름에 어떻게 연결할지 고민해야 한다. - 자동화의 효과를 높이려면 컴포넌트, 스타일, 변수, 명명 규칙이 체계적으로 정리되어 있어야 한다. - 디자인 시스템이 일관되지 않거나 문서화가 부족하면 AI와 자동화 도구도 부정확한 결과를 낼 수 있다. - 따라서 자동화는 잘 정립된 시스템을 대체하기보다, 품질 높은 시스템을 더 넓고 빠르게 활용하도록 돕는 방식으로 작동한다. ## 인간 디자이너의 역할 - 자동화가 작업의 일부를 대신하더라도 문제의 맥락을 이해하고 우선순위를 정하는 일은 여전히 인간에게 요구된다. - AI는 여러 결과를 빠르게 생성할 수 있지만, 어떤 결과가 사용자와 비즈니스에 적합한지 판단하지는 못한다. - 디자이너의 역할은 픽셀을 직접 배치하는 일에서 다음과 같은 업무로 확장될 수 있다. - 올바른 문제 정의 - 사용자 요구와 비즈니스 목표의 조율 - 생성 결과의 평가와 수정 - 디자인 시스템의 원칙과 품질 관리 - 새로운 도구와 협업 방식의 설계 - 자동화는 디자이너를 없애기보다, 디자이너가 더 전략적이고 창의적인 역할을 수행하도록 업무의 성격을 바꿀 가능성이 크다. 실무에서는 반복 작업부터 플러그인으로 자동화하되, 컴포넌트와 디자인 토큰을 먼저 정비하는 것이 좋다. AI가 생성한 결과는 초안으로 활용하고, 접근성·일관성·사용자 맥락을 사람이 반드시 검토해야 한다.

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