techlist.io
KREN

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

figma4분 읽기큐레이션 요약

사후 분석: 202

2020년 1월 21~22일 Figma 장애는 장시간 실행된 고비용 쿼리와 PostgreSQL의 잘못된 쿼리 실행 계획, 그리고 이로 인해 누적된 공격적 autovacuum이 복합적으로 발생한 사건이었다. 1월 21일에는 문제 쿼리를 취소해 복구했지만, 그 여파로 데이터베이스 정리 작업이 밀리면서 다음 날 쓰기 IOPS와 잠금 경합이 급증했다. Figma는 PostgreSQL 11로 업그레이드해 문제를 안정화했고, 이후 고비용 쿼리 모니터링과 실행 시간 제한을 강화하기로 했다. ## 장애 발생 경과 ### 1월 21일: 장시간 실행 쿼리 - 오전 6시 11분, 자동 모니터링에서 오류율 증가를 감지했다. - 조사 결과, 데이터베이스 CPU를 과도하게 사용하는 장시간 실행 쿼리가 발견됐다. - 오전 6시 54분 해당 쿼리를 취소하자 성능이 정상으로 돌아왔다. - 그러나 쿼리 취소 과정에서 데이터베이스 내부에 정리해야 할 작업이 누적되었고, 이것이 다음 날 장애의 배경이 됐다. ### 1월 22일: 쓰기 부하와 잠금 경합 - 데이터베이스 CPU는 평소보다 낮았지만 쓰기 IOPS와 잠금 경합이 증가했다. - 오전 11시 42분에는 API 요청이 대기열에 쌓이며 일부 사용자가 서비스를 이용할 수 없게 됐다. - 불필요한 쿼리를 취소하고 할당된 IOPS를 늘려 일시적으로 안정화했지만, 오후 2시경 다시 성능이 악화됐다. - 데이터베이스를 재시작해 문제를 일으킨 것으로 추정한 백그라운드 프로세스를 임시 비활성화했다. - 오후 7시부터 긴급 점검을 진행하며 PostgreSQL을 업그레이드했고, 오후 8시 15분 서비스와 데이터베이스 지표가 정상화됐다. ## 공격적 autovacuum의 영향 - PostgreSQL의 autovacuum은 오래된 행 버전을 정리하고 트랜잭션 ID 고갈을 방지하는 자동 유지보수 작업이다. - 1월 21일 장시간 쿼리가 종료된 뒤 정리 대상 데이터가 대량으로 쌓였다. - 이 backlog가 임계치를 넘으면서 트랜잭션 ID 래핑을 막기 위한 더 공격적인 autovacuum이 실행됐다. - 당시 사용하던 PostgreSQL 버전에서는 이 작업이 테이블 잠금과 쓰기 작업에 큰 영향을 줬다. - Figma가 대형 테이블에서 실행 중인 autovacuum을 취소하자 지표가 일시적으로 개선됐지만, 작업은 다시 재개됐다. - `autovacuum_freeze_max_age` 값을 조정하고 데이터베이스를 재시작해야 공격적 autovacuum을 완전히 억제할 수 있었다. - 다만 autovacuum을 비활성화한 뒤에도 쓰기 지연과 잠금 경합이 계속되어, 이것만이 유일한 원인은 아니라고 판단했다. ## 잘못된 쿼리 실행 계획 - 문제의 핵심 쿼리는 복잡한 서브쿼리를 포함하고 있었고, 잠금 경합에 반복적으로 관여했다. - PostgreSQL 9의 통계 정보가 변경된 뒤 쿼리 플래너가 비효율적인 실행 계획을 선택한 것으로 분석됐다. - 실행 계획은 실제 결과가 3개 행뿐인데도 2천만 개 이상의 행을 반환할 것으로 잘못 추정했다. - 그 결과 인덱스를 사용하지 않고 전체 테이블 스캔을 수행했다. - 처리 과정에서 임시 버퍼에 대량의 데이터를 기록해 높은 쓰기 IOPS와 임시 데이터 사용량을 유발했다. - 즉, 낮은 CPU 사용률만으로 데이터베이스 상태가 양호하다고 판단하기 어려웠으며, 쓰기 지연·잠금·임시 버퍼 사용량을 함께 살펴야 했다. ## PostgreSQL 11 업그레이드 - PostgreSQL 9.6 이후에는 autovacuum과 관련된 중요한 최적화가 포함됐다. - PostgreSQL 10 이상에서는 Amazon RDS의 성능 분석 도구가 개선되어 원인 조사에 도움이 된다. - Figma는 이미 스테이징 환경을 PostgreSQL 11로 업그레이드하고 수개월간 테스트한 상태였다. - 운영 환경 업그레이드 절차도 사전에 마련해 두었기 때문에 긴급 상황에서도 업그레이드를 진행할 수 있었다. - PostgreSQL 11의 개선된 쿼리 플래너는 문제가 된 실행 계획이 선택될 가능성을 제거했다. - autovacuum의 성능 특성도 PostgreSQL 9에서 11로 오면서 개선되어 두 가지 주요 원인을 함께 완화했다. ## 후속 조치 - 고비용·장시간 실행 쿼리에 대한 모니터링을 강화한다. - 쿼리가 실행될 수 있는 시간에 더 엄격한 제한을 둔다. - 실행 계획의 예상 행 수와 실제 행 수 사이의 큰 차이를 지속적으로 점검한다. - CPU뿐 아니라 쓰기 IOPS, 쓰기 지연, 잠금 경합, 임시 버퍼 사용량, autovacuum backlog를 함께 모니터링해야 한다. - 데이터베이스 버전 업그레이드는 장애 발생 후 처음 검토하기보다, 스테이징 테스트와 운영 전환 계획을 미리 준비해야 한다. 실무적으로는 장시간 쿼리에 타임아웃을 설정하고, 정기적으로 `EXPLAIN ANALYZE`와 실행 계획 변화를 검토하며, autovacuum 상태를 별도 지표로 관리하는 것이 중요하다. alc-vesm.

원문 읽기(새 탭에서 열림)
PostgreSQLamazon-rdsdatabase-monitoringquery-optimization+2
figma3분 읽기큐레이션 요약

Figma on Figma: Figma

Figma는 제품 디자인뿐 아니라 마케팅 웹사이트에도 디자인 시스템이 필요하다고 판단하고, 기존 페이지의 시각 요소와 제작 방식을 체계화했다. 반복되는 요소를 통합하고 재사용 가능한 컴포넌트와 조합형 섹션을 구축한 결과, 일관성을 유지하면서도 코드 작성 없이 아이디어에서 출시까지 하루, 실제 사례에서는 48시간 이내에 웹페이지를 만들 수 있게 되었다. ## 기존 웹사이트의 불일치와 유지보수 문제 - 페이지마다 디자이너와 개발자가 각자 새로운 해결책을 만들고 있었다. - 비슷하지만 조금씩 다른 컴포넌트가 반복되어 사용자 경험과 브랜드 인상이 일관되지 않았다. - 페이지를 수정하거나 업데이트하기 어렵고, 새로운 페이지를 만들 때마다 작업 방식이 달라졌다. - 제품 디자인 분야에서 활용되던 디자인 시스템의 장점을 마케팅·웹 디자인에도 적용할 필요가 있었다. ## 전체 요소를 조사하고 패턴을 통합 - 먼저 폰트, 글자 크기, 색상, 컬럼 너비, 레이아웃 등 기존 사이트의 시각 요소를 Figma 파일에 모았다. - 조사 과정에서 다음을 구분했다. - 여러 페이지에서 반복되는 패턴 - 한 번만 사용되어 스타일 가이드에 포함하기 어려운 예외 요소 - 서로 유사하지만 세부 스타일이 다른 요소 - 큰 UI 요소는 더 작은 단위로 분해해 조합 가능한 구조로 만들었다. - 서로 다른 제목 스타일 12개를 H1~H3, 본문, 기술 문서용 텍스트 등으로 단순화했다. - 블로그와 긴 형식의 콘텐츠에는 풀 쿼트, 블록 쿼트 같은 전용 텍스트 스타일도 추가했다. ## 원자적 요소와 유연한 컴포넌트 - 작은 요소를 조합해 다양한 페이지 구조를 만들 수 있도록 디자인 시스템을 구성했다. - 핵심 목표는 특정 페이지에만 맞는 고정된 디자인이 아니라, 여러 콘텐츠와 레이아웃에 대응하는 유연한 빌딩 블록을 만드는 것이었다. - 정리된 시각 언어를 공유 라이브러리로 제공해 Figma 브랜드에 익숙하지 않은 사람도 일관된 결과물을 만들 수 있게 했다. - 타이포그래피, 간격, 패딩, 행간, 색상, 그리드 등을 하나의 기준으로 통일했다. ## FLEGOs: 조합 가능한 대형 섹션 - Figma는 컴포넌트를 조합해 자주 함께 사용되는 요소와 완성된 섹션도 미리 만들었다. - 이러한 대형 조합 단위를 “Figma + LEGO”라는 의미의 **FLEGOs**라고 불렀다. - 디자이너는 개별 텍스트나 버튼뿐 아니라 페이지의 주요 섹션을 FLEGOs로 빠르게 구성할 수 있었다. - 작은 요소부터 완성된 섹션까지 단계적으로 재사용할 수 있어 페이지 제작의 속도와 일관성을 함께 확보했다. ## Contentful 기반의 제작 workflow - 약 한 달 동안 소규모 팀이 스타일 가이드와 컴포넌트 라이브러리를 구축했다. - 시스템은 Figma 파일에만 머무르지 않고 CMS인 Contentful에도 반영했다. - 디자인팀은 Figma에서 FLEGO를 사용해 와이어프레임을 만들고, 같은 파일에서 콘텐츠를 협업한 뒤 CMS의 컴포넌트로 실제 페이지를 구성했다. - 대부분의 핵심 마케팅 사이트가 이 프레임워크를 기반으로 제작되었다. - 새로운 페이지를 만들 때 별도의 코드 작성 없이 기존 컴포넌트를 활용할 수 있었다. ## 출시 속도 향상 - 디자인 시스템 도입 후 콘셉트에서 출시까지 하루 안에 진행할 수 있게 되었다. - ‘What’s New’ 페이지는 제품 마케터와 웹 제작자가 FLEGOs로 빠르게 와이어프레임을 만들고 콘텐츠를 작성한 사례다. - 아이디어에서 실제 웹페이지 공개까지 48시간 이내에 완료했다. - 재사용 가능한 시스템 덕분에 속도를 높이면서도 브랜드의 시각적 일관성을 유지할 수 있었다. 디자인 시스템은 제품 UI에만 필요한 도구가 아니라, 마케팅 페이지와 콘텐츠 제작에도 효과적이다. 기존 결과물을 먼저 조사하고, 반복 패턴을 통합한 뒤, 작은 요소부터 조합형 섹션까지 단계적으로 라이브러리화하면 개발 부담을 줄이면서 빠르고 일관된 웹사이트 운영이 가능하다.

원문 읽기(새 탭에서 열림)
Figma디자인 시스템component-libraryatomic-design+2
figma3분 읽기큐레이션 요약

Figma에서 커뮤니티

Figma는 2020년의 성장 전략 중심에 사용자 커뮤니티를 두고, 온라인·오프라인·제품 내부에서 사용자를 더 closely 연결하겠다고 밝혔다. 이를 위해 사용자 컨퍼런스와 지역 모임, 글로벌 지원 체계, 팀 협업 기능, 파일 공유 기반의 Figma Community를 확대할 계획이다. 궁극적으로는 디자인을 더 많은 사람이 배우고 공유하며 함께 발전시키는 개방형 생태계를 구축하려는 것이다. ## 오프라인 만남과 지역 커뮤니티 확대 - 2020년 2월 샌프란시스코에서 첫 사용자 컨퍼런스 **Config**를 개최한다. - 프로그램 상당 부분을 커뮤니티가 직접 구성해, 일방적인 강연보다 참여형 행사로 운영한다. - 오픈소스 디자인, 차세대 디자이너 교육, 디자인 의사결정에 대한 자신감, Chicago.gov 재설계 경험 등 실무 중심 주제를 다룬다. - 샌프란시스코에 참석하지 못하는 사용자를 위해 온라인 시청도 제공한다. - 전 세계 도시의 커뮤니티 리더들과 협력해 지역별 Figma 이벤트와 사용자 그룹을 확대할 예정이다. ## 글로벌 고객 지원 강화 - 기존 고객 지원은 북미와 유럽 업무 시간 중심이었지만, Figma 활성 사용자의 80% 이상이 미국 외 지역에 있다는 점을 고려해 지원 체계를 확장한다. - Zendesk로 지원 기술 스택을 이전해 전 세계 고객을 더 효과적으로 지원할 기반을 마련했다. - 2020년 중 다음과 같은 지원 서비스를 선보일 계획이다. - 제품 지식을 직접 검색할 수 있는 새로운 Help Center - 사용자끼리 질문하고 답변하는 커뮤니티 포럼 - Figma 내부의 처리 절차 개선을 통한 더 빠른 고객 응대 ## 제품팀 전체를 위한 협업 기능 - 2019년에는 Plugins, Auto Layout, Smart Animate, OpenType 지원, Design System Analytics 등을 출시했다. - 앞으로도 반복적이고 수동적인 디자인 작업을 줄여 창의적 생산성을 높이는 기능 개발을 이어간다. - 디자인은 디자이너만의 작업이 아니라 엔지니어, 제품 관리자 등 여러 직군이 함께하는 과정이라는 점을 강조한다. - 따라서 Figma를 개인용 디자인 도구를 넘어 제품팀 전체가 사용할 수 있는 협업 플랫폼으로 발전시키려 한다. - 대규모 조직의 Figma 파일에는 평균 6명의 협업자가 참여한다는 데이터도 제품 방향의 근거로 제시했다. - 2020년 제품 로드맵은 Config에서 경영진이 추가로 공개할 예정이라고 밝혔다. ## 파일 공유를 중심으로 한 Figma Community - 디자이너들이 서로 작업물을 공유하고 배우는 관행에서 영감을 받아 Figma Community 베타를 시작했다. - 공개된 파일을 다른 사용자가 살펴보고, 수정하거나 재활용하며 학습할 수 있다. - 발표 당시 300명 이상의 크리에이터가 약 600개의 파일을 공개했다. - 공유된 자료에는 다음이 포함된다. - 디자인 템플릿 - 실습형 교육 가이드 - 공개 디자인 라이브러리 - 향후 더 많은 크리에이터가 자료를 게시하도록 지원해, 전문 디자이너와 예비 디자이너 모두가 유명 브랜드와 제작자의 작업에서 배울 수 있는 공간으로 만들 계획이다. ## 커뮤니티와 함께 만드는 성장 전략 - Figma는 단순히 사용자를 늘리는 것보다 사용자가 서로 연결되고 지식을 나누는 구조를 만드는 데 초점을 둔다. - 컨퍼런스와 지역 모임은 사람과 사람을 연결하고, 지원 포럼과 Community는 온라인 지식 교류를 활성화한다. - 제품 자체는 여러 직군이 실시간으로 협업하는 공간으로 확장된다. - 회사는 커뮤니티의 의견을 제품, 행사, 지원 정책에 반영하기 위해 사용자에게 직접 아이디어를 요청했다. Figma의 방향은 디자인 도구를 넘어, 작업물·지식·사람이 함께 모이는 협업 생태계를 구축하는 데 있다. 사용자는 Config나 지역 모임에 참여하고, Figma Community의 파일을 공유·재활용하며, 포럼을 통해 다른 사용자와 문제를 해결하는 방식으로 이 생태계를 적극 활용할 수 있다.

원문 읽기(새 탭에서 열림)
Figma디자인 시스템auto-layoutplugins+4
figma3분 읽기큐레이션 요약

디자인 시스템의 가치 측정하기

디자인 시스템은 반복 자산을 재사용하게 해 디자이너가 제작·검색·세부 의사결정에 쓰는 시간을 줄여준다. Figma의 실험에서는 관련성이 높고 최신 상태인 디자인 시스템을 사용할 때 디자이너의 작업 완료 시간이 그렇지 않을 때보다 **34% 빨랐다**. 다만 이는 과제에 직접 적용 가능한 디자인 시스템을 사용한 조건의 결과이므로, 실제 조직에서 얻을 수 있는 최대 시간 절감에 가까운 수치로 해석해야 한다. ## 디자인 시스템의 가치와 정량화 필요성 - 디자인 시스템은 제품 전반에서 반복적으로 사용하는 자산을 위한 **단일 기준점(single source of truth)** 역할을 한다. - Figma 엔터프라이즈 고객의 약 **75%**가 조직 전체에서 디자인 시스템을 활용하고 있다. - 디자인 시스템은 구축보다도 지속적인 유지·관리와 실제 사용 현황 파악이 어렵다. - 사용 데이터를 분석하면 디자인 시스템 팀이 어떤 라이브러리와 컴포넌트를 개선하거나 폐기할지 더 정확히 판단할 수 있다. - Figma는 이러한 분석을 지원하기 위해 라이브러리 사용 추이와 컴포넌트별 사용 현황을 제공하는 Design System Analytics를 공개했다. ## 잘 유지된 디자인 시스템이 시간을 줄이는 이유 디자이너가 디자인 시스템의 자산을 사용하면 다음 작업을 피할 수 있다. - 컴포넌트나 화면 요소를 처음부터 다시 제작하는 작업 - 기존 디자인 파일을 뒤져 이미 존재하는 자산을 찾는 작업 - 글꼴, 배치, 색상 등 세부적인 시각적 결정을 매번 새로 내리는 작업 - 색상 선택이나 스타일 조정 같은 반복적인 미세 의사결정 이렇게 절약된 시간이 누적되면 디자이너는 전략적이고 창의적인 업무에 더 집중할 수 있다. ## 실험 설계: 디자인 시스템 사용 여부 비교 Figma 데이터 과학팀은 동일한 디자이너가 디자인 시스템이 있을 때와 없을 때 어떻게 달라지는지 비교했다. - 금융 계정 통합 앱을 배경으로 두 가지 과제를 설계했다. - 특정 계정의 거래 내역과 추세를 보여주는 화면 제작 - 사용자 프로필에 새 금융 계정을 연결하는 흐름 설계 - 모든 참가자는 두 과제를 모두 수행했지만, 한 과제에서만 최신 디자인 시스템을 사용할 수 있었다. - 다른 과제에서는 디자인 시스템 대신 참고용 과거 디자인 파일이 제공됐다. - 두 과제의 난이도와 완료 시간이 개인별로 비슷하도록 구성해, 각 디자이너가 자신의 통제군 역할을 하게 했다. - 과제 순서에 따른 편향을 줄이기 위해 참가자마다 수행 순서를 번갈아 배정했다. - 참가자에게 자산을 미리 익힐 시간을 충분히 제공했다. - 프롬프트는 사용자가 수행해야 할 목표만 설명하고, 디자이너가 어떤 화면을 만들어야 하는지는 지정하지 않았다. - 품질 기준을 인위적으로 통일하지 않기 위해 참가자가 스스로 적절한 완료 시점을 판단하도록 했으며, 과제별 완료 시간을 측정했다. ## 실험 결과: 작업 시간 34% 단축 - 디자인 시스템에 접근할 수 있었던 참가자는 그렇지 않은 경우보다 목표를 **34% 더 빠르게 완료**했다. - 이 결과는 디자인 시스템의 자산이 과제에 직접 적용 가능하고, 최신 상태이며, 실제 작업과 관련성이 높을 때 얻어진 효과다. - 따라서 현실의 모든 작업에서 항상 34%가 절약된다는 뜻이라기보다, 디자인 시스템이 가장 효과적으로 작동하는 조건에서의 상한선에 가깝다. - Figma는 이 비율을 실제 디자인팀의 인력과 일정에 적용해 시간과 비용 절감 규모로 환산하려 했지만, 제공된 글은 해당 계산 과정 중간에서 끝난다. ## 실용적인 적용 방향 디자인 시스템의 투자 효과를 확인하려면 단순히 라이브러리를 만들어 두는 것보다 최신성·관련성·사용률을 지속적으로 관리해야 한다. 라이브러리 분석을 통해 자주 사용되는 컴포넌트와 거의 쓰이지 않는 자산을 구분하고, 실제 작업에 맞지 않는 요소를 개선하는 것이 시간 절감 효과를 높이는 방법이다.

원문 읽기(새 탭에서 열림)
Figma디자인 시스템데이터 사이언스design-system-analytics+1
figma3분 읽기큐레이션 요약

Made in Figma, 201

2019년 Figma 사용 데이터를 보면 디자인은 더 개방적이고 협업적인 활동으로 발전했으며, 디자인 작업을 정량적으로 분석하려는 흐름도 커졌다. 사용자들은 차가운 계열의 색상과 Google Fonts를 선호했고, 데스크톱·모바일 등 다양한 화면 크기를 기준으로 작업했다. 또한 하나의 디자인 파일에 여러 직군이 참여하며, 파일은 개인 작업에서 협업 작업으로 확장되는 양상을 보였다. ## 분석의 배경과 방법 - Figma는 2019년 사용자들의 디자인 경향을 파악하기 위해 익명화된 제품 데이터를 분석했다. - 분석 대상에는 다음과 같은 항목이 포함됐다. - 자주 사용된 색상과 폰트 - 텍스트 스타일과 굵기 - 가장 많이 선택된 프레임 크기 - 하나의 파일에서 협업한 사용자 수와 작업 흐름 - 디자인 시스템 분석 기능의 등장으로 디자인 작업의 가치와 활용도를 수치로 평가할 가능성도 커졌다. ## 차가운 계열 색상의 선호 - 회색 계열을 제외하면 녹색과 파란색이 가장 많이 사용됐다. - 가장 많이 사용된 비회색 색상은 `#009688`이었다. - 그 뒤를 짙은 파란색인 `#455A64`, `#263238`이 이었다. - 이는 2019년 Pantone 올해의 색상인 Living Coral(`#FF6F61`)과는 대조적인 결과였다. ## Google Fonts 중심의 폰트 사용 - 가장 많이 사용된 폰트는 다음과 같았다. - Montserrat - Open Sans - Lato - 상위 10개 폰트 중 6개가 Google Fonts였다. - SF Pro Text, SF Pro Display, Proxima Nova처럼 기본 제공 폰트가 아닌 글꼴도 상위권에 포함됐다. - 시스템 폰트 중에서는 Helvetica보다 Arial의 사용량이 많았다. - Figma의 기본 폰트인 Roboto는 순위에서 제외됐지만, 이를 포함하면 상위 11개 폰트가 전체 폰트 사용량의 90%를 차지했다. - Font Awesome은 아이콘 폰트임에도 31위를 기록했다. - Times New Roman은 55위였고, 첫 번째 세리프 폰트인 Playfair Display는 22위에 올랐다. ## 굵은 글꼴과 텍스트 스타일 - 사용자는 이탤릭체보다 글꼴 굵기를 조정하는 경향이 훨씬 강했다. - 글꼴을 굵게 조정하는 작업은 이탤릭체 적용보다 13배 더 자주 발생했다. - Figma 파일의 약 3분의 1은 bold 또는 heavy 스타일을 사용했다. - 이는 가독성뿐 아니라 시각적 위계와 강조를 위해 굵은 글꼴이 널리 활용됐음을 보여준다. ## 프레임과 화면 크기 선택 - Figma는 디자인 시작점으로 사용할 수 있는 36개의 사전 정의 프레임을 제공했다. - 전체 파일의 33%가 이 프리셋 프레임 중 하나로 시작됐다. - 가장 인기 있는 프레임은 `1440 × 1024` 데스크톱 화면이었다. - 그 뒤를 iPhone X와 iPhone 8 프레임이 따랐다. - Windows 사용자가 macOS 사용자보다 훨씬 많다는 점을 고려하면, 실제 운영체제 점유율과 디자인 대상 기기의 우선순위가 반드시 일치하지는 않았다. ## 개인 작업에서 팀 협업으로의 확장 - Figma는 디자인을 더 개방적이고 협력적인 활동으로 만들겠다는 방향을 제품에 반영했다. - 대규모 조직의 파일을 기준으로 하면 파일당 평균 협업자 수는 6명이었다. - 협업자는 디자이너뿐 아니라 다음과 같은 직군을 포함할 수 있었다. - 개발자 - 제품 관리자 - 라이터 - 조직 내 다른 이해관계자 - 일반적인 파일은 처음에 한 명의 사용자가 독립적으로 작업하며 시작됐다. - 평균 19일이 지나면 첫 번째 협업자가 초대됐다. - 초대된 협업자는 리뷰, 댓글 작성, 공동 디자인 등의 방식으로 파일에 참여했다. ## 실용적인 시사점 - 디자인 시스템과 협업의 효과를 평가할 때 사용 빈도, 참여자 수, 파일의 변화 과정 같은 데이터를 활용할 수 있다. - 폰트와 색상 선택에서는 유행보다 브랜드 맥락과 가독성을 우선하되, 사용자가 익숙하게 접근할 수 있는 표준 리소스도 고려할 만하다. - 파일을 개인 작업물로 끝내지 않고 개발·기획·콘텐츠 담당자와 공유하면 디자인 의사결정 과정이 더 투명해질 수 있다.

원문 읽기(새 탭에서 열림)
Figma디자인 시스템프로토타이핑collaborative-design+2
figma3분 읽기큐레이션 요약

More natural/engaging

2010년대 모바일 혁명은 기술 기업에서 디자인의 역할을 주변 업무에서 핵심 경쟁력으로 끌어올렸다. 스마트폰은 더 복잡한 사용 환경과 방대한 사용자 데이터를 만들어냈고, 디자이너는 기능 우선순위 설정과 지속적인 UI 실험을 주도하게 됐다. 특히 아이폰은 소비자가 기대하는 제품의 미적·사용성 기준을 높이며 기업 전반의 디자인 투자를 촉진했다. ## 모바일 물결이 디자인의 위상을 높이다 - 아이폰은 2007년에 출시됐지만, 2009년 인앱 결제와 2010년 아이패드 등장 이후 2010년대에 본격적으로 산업 전반을 변화시켰다. - 스마트폰 보급으로 제품이 일상생활의 중심이 되면서, 복잡한 기술 시스템을 간단한 상호작용으로 바꾸는 디자이너의 역량이 중요해졌다. - 과거 엔지니어 중심이었던 실리콘밸리 기업들은 디자인 인력을 대규모로 채용하기 시작했다. - IBM 같은 기업은 2년 동안 35개 이상의 디자인 에이전시를 인수할 정도로 디자인 역량 확보에 적극적으로 나섰다. ## 모바일 환경이 만든 복잡성 - 모바일 화면은 데스크톱보다 작고 기기별 크기도 다양해졌다. - 사용자는 마우스 클릭 대신 손가락으로 탭, 스와이프, 길게 누르기 등의 동작을 수행했다. - 사용 상황도 책상 앞에 한정되지 않고 걷거나 이동하는 중으로 확장됐다. - 기업은 제한된 화면과 사용자의 주의력 안에서 어떤 기능을 우선 제공할지 결정해야 했고, 이 과정에서 디자이너의 문제 정의와 우선순위 판단이 중요해졌다. - 컴퓨팅이 화면 안에만 머무르지 않고 사용자의 주변 환경과 일상 행동 속으로 확장됐다. ## 데이터 기반 디자인과 A/B 테스트 - 스마트폰은 카메라, 마이크, 위치 정보 등을 통해 과거보다 훨씬 많은 사용자 데이터를 만들어냈다. - 모바일 사용이 일상화되면서 제품팀은 버튼 색상, 문구, 화면 구성 같은 UI 변형을 지속적으로 실험했다. - 실험 결과는 가입, 구매, 공유 등 사용자의 실제 행동 변화로 평가됐다. - 페이스북을 비롯한 기업들은 이러한 실험을 수행할 디자이너를 적극 채용했다. - 디자인은 시각적 완성도를 만드는 일을 넘어, 성장 지표를 개선하는 데이터 기반 업무로 확장됐다. - 2011년부터 2019년 사이 미국 성인의 스마트폰 보유율은 35%에서 81%로 증가했다. ## 아이폰이 세운 디자인 기준 - 아이폰은 기술 제품이 단순히 기능적이기만 해서는 안 된다는 인식을 널리 퍼뜨렸다. - 과거의 소프트웨어가 투박하고 실무적인 도구로 여겨졌다면, 아이폰은 제품의 외관과 사용 경험 자체를 경쟁 요소로 만들었다. - 아이폰은 맥보다 더 넓은 대중에게 디자인 중심의 제품 경험을 보여주며 소비자의 기대치를 높였다. - 기업들은 애플처럼 보이고 작동하는 제품을 만들려 했고, 소비자 역시 애플 수준의 완성도를 기대하게 됐다. - 이런 영향은 아이폰뿐 아니라 안드로이드와 틴더 같은 모바일 중심 서비스의 디자인 방향에도 나타났다. - 애플의 영향은 긍정적인 디자인 혁신을 이끌었지만, 모든 제품이 애플의 미학을 모방하려는 결과도 낳았다. ## 실무적 시사점 모바일 제품을 설계할 때는 기능을 많이 넣는 것보다 사용자의 상황과 제약을 먼저 이해하고 핵심 상호작용을 선별해야 한다. 또한 정성적 사용자 이해와 A/B 테스트 같은 정량적 검증을 함께 활용하되, 단기 성장 지표뿐 아니라 전체 사용자 경험과 제품의 일관성까지 고려하는 것이 중요하다.

원문 읽기(새 탭에서 열림)
사용자 경험a-b-testingmobile-designux-ui-design+2
figma3분 읽기큐레이션 요약

오토 레이아웃

Figma의 Auto Layout은 자유로운 디자인 탐색과 HTML/CSS·SwiftUI 같은 개발 환경의 구조적 레이아웃 장점을 결합한 기능이다. 텍스트나 콘텐츠가 바뀌면 버튼과 주변 요소의 크기·위치가 자동으로 조정되어 반복적인 수작업을 줄인다. 또한 프레임 중첩을 통해 콘텐츠에 반응하는 복잡한 인터페이스와 재사용 가능한 컴포넌트를 만들 수 있다. ## 디자인과 개발 환경의 간극 - Figma의 기존 자유 배치 방식은 창의적인 탐색에는 유리하지만 반복 작업이 많았다. - 버튼 문구를 수정하려면 텍스트 편집, 버튼 크기 조정, 인접 버튼 이동을 각각 수행해야 했다. - HTML/CSS나 SwiftUI는 객체 간 구조와 관계를 표현하므로 콘텐츠 변경에 강하지만, 자유로운 시각적 실험에는 불편하다. - Auto Layout은 CSS 박스 모델, 특히 flexbox의 핵심 개념을 Figma에 도입해 두 환경의 장점을 결합했다. - 프레임의 속성으로 제공되므로 컴포넌트뿐 아니라 일반 프레임에도 적용할 수 있다. ## 콘텐츠에 따라 자동으로 변하는 레이아웃 - Auto Layout을 적용하면 내부 요소가 가로 또는 세로 방향으로 순서대로 배치된다. - 컨테이너의 크기는 내부 요소들의 전체 크기에 맞춰 자동으로 결정된다. - 프레임 자체에 패딩, 채우기, 선, 모서리 반경을 설정할 수 있어 버튼 제작에 별도 레이어가 필요하지 않다. - “Buy”를 “Add to basket”으로 변경하면 버튼이 텍스트 길이에 맞춰 자동으로 늘어난다. - 인접한 버튼이나 요소도 레이아웃 흐름에 맞춰 함께 이동한다. - 요소 간 간격은 개별 요소가 아니라 컨테이너 수준에서 설정된다. 특정 요소 사이만 다르게 조정하려면 추가 작업이 필요하다. ## 리스트와 메뉴의 자동 재정렬 - 반복되는 UI 요소를 배치하는 리스트와 메뉴 제작에 특히 유용하다. - 요소를 드래그해 순서를 바꾸면 나머지 요소가 자동으로 재배치된다. - 항목을 하나씩 올바른 위치로 옮기던 반복적인 클릭 작업을 줄일 수 있다. - 기존 컴포넌트 라이브러리와 디자인 시스템에도 적용할 수 있으며, `Shift + A` 또는 옵션 메뉴에서 활성화할 수 있다. ## 중첩 프레임으로 복잡한 인터페이스 구성 - 여러 Auto Layout 프레임을 HTML의 중첩된 `div`처럼 조합할 수 있다. - 버튼, 카드, 리스트, 화면 전체를 계층적으로 구성하면서 각 영역이 콘텐츠 변화에 반응하도록 만들 수 있다. - 콘텐츠를 수정하거나 요소를 다른 Auto Layout 프레임 안팎으로 이동하기 쉽다. - 의도하지 않은 배치를 막기 위해 큰 이미지를 버튼 안에 넣는 등의 작업에는 안전장치가 작동한다. - 실제로 원하는 작업이라면 macOS에서는 `Command`, Windows에서는 `Ctrl` 키를 눌러 안전장치를 무시할 수 있다. - 콘텐츠 변형마다 별도 컴포넌트를 만들기보다, 다양한 콘텐츠를 수용하는 범용 컴포넌트를 제작할 수 있다. ## 향후 발전 방향 - Figma는 Auto Layout을 첫 출시로 보고, 향후 더 많은 기능을 추가할 계획이라고 밝혔다. - 사용자는 플레이그라운드 파일, 동영상, 공식 문서를 통해 기능을 학습할 수 있다. - 기능 사용 후 피드백과 개선 요청을 공유하도록 독려했다. 실무에서는 텍스트 길이가 달라지는 버튼, 반복 목록, 카드와 메뉴처럼 콘텐츠 변화가 잦은 UI부터 Auto Layout을 적용하는 것이 효과적이다. 이후 프레임을 중첩해 디자인 시스템 전반을 반응형이고 재사용 가능한 구조로 확장할 수 있다.

원문 읽기(새 탭에서 열림)
Figma디자인 시스템HTML반응형 디자인+3
figma4분 읽기큐레이션 요약

일터에서의 인간미: Gust

Gusto는 기존 브랜드가 고객에게 제공하는 인간적인 경험을 충분히 반영하지 못한다고 판단해 전사적인 리브랜딩을 추진했습니다. 이 과정에서 Figma를 디자인 도구를 넘어 마케팅·콘텐츠·제품·브랜드 팀이 함께 사용하는 협업 플랫폼으로 활용했습니다. 그 결과 브랜드 철학을 로고와 캠페인뿐 아니라 제품 UI와 고객 경험 전반에 일관되게 적용하고, 여러 제품으로 확장 가능한 디자인 시스템을 구축했습니다. ## 사람 중심의 리브랜딩 - Gusto는 2012년 ZenPayroll로 시작해 10만 개 이상의 소규모 사업체에 급여, 복지, 인사 업무 자동화 서비스를 제공했습니다. - 고객들은 플랫폼을 긍정적으로 평가했지만, 기존 브랜드가 Gusto가 제공하는 인간적인 경험을 제대로 보여주지 못한다고 판단했습니다. - 리브랜딩의 목표는 로고만 바꾸는 것이 아니라 다음 요소를 하나의 브랜드 철학으로 통합하는 것이었습니다. - 브랜드 인지도 - 제품 개발 - 고객 경험 - 마케팅과 커뮤니케이션 - Gusto의 브랜드 책임자는 브랜드를 마케팅 부서나 브랜드 디자인 팀만의 소유물이 아니라, 사용자가 회사와 접촉하며 경험하는 모든 것의 총합으로 정의했습니다. ## 전사적 동의를 만드는 과정 - 리브랜딩의 가장 큰 과제는 약 1,000명의 구성원이 새 브랜드를 이해하고 실제 업무에 적용하도록 만드는 것이었습니다. - 이를 위해 모든 팀이 같은 도구를 사용하며 다음 활동을 할 수 있어야 했습니다. - 진행 중인 디자인을 실시간으로 확인 - 아이디어 공유 - 디자인에 대한 의견 교환 - 결과물에 대한 공동 소유 의식 형성 - Figma는 디자인팀뿐 아니라 콘텐츠, 제품 마케팅, 고객 확보팀 등 다양한 조직이 프로젝트에 참여할 수 있게 했습니다. - 디자인 과정이 공개되면서 비디자이너도 디자인이 만들어지는 방식과 의사결정 과정을 이해할 수 있었고, 디자인의 가치에 대한 공감대도 높아졌습니다. ## 비디자이너를 디자인 과정에 참여시키기 - Gusto는 Figma를 다음과 같은 리브랜딩 작업 전반에 활용했습니다. - 무드보드 - 타이포그래피 - UI 디자인 - 광고판과 같은 오프라인 캠페인 - 브랜드 적용 예시 - 실시간 협업 기능을 통해 관련자들이 동일한 파일을 보며 작업 상황을 확인했습니다. - 댓글 기능을 사용해 이메일이나 Slack처럼 분리된 대화가 아니라 디자인 파일 안에서 직접 의견을 주고받았습니다. - 이러한 방식은 피드백의 맥락을 보존하고, 디자이너와 다른 직군 사이의 커뮤니케이션 비용을 줄였습니다. ## 브랜드팀과 제품팀의 공동 작업 - Gusto는 제품 디자인팀과 브랜드 디자인팀을 리브랜딩의 동등한 참여자로 구성했습니다. - 두 팀은 공동 브레인스토밍과 워크숍을 열어 다음 요소를 함께 결정했습니다. - 색상 팔레트 - 타이포그래피 - 제품에 적용할 브랜드 스타터 템플릿 - Figma에서 여러 사람이 동시에 작업하면서 새 브랜드 요소를 제품의 다양한 영역에 적용해 볼 수 있었습니다. - 제품팀은 브랜드 가이드라인과 워크숍 결과를 바탕으로 새로운 UI 키트를 제작했습니다. - 목표는 단순히 제품 전체에 브랜드를 반복 적용하는 것이 아니라, 특정 화면과 순간에 브랜드를 더욱 인상적이고 영감을 주는 방식으로 드러내는 것이었습니다. - 초기 단계부터 브랜드와 제품팀이 함께했기 때문에 브랜드를 제품 경험 전체로 확장하는 과정이 자연스럽게 이어졌습니다. ## 여러 제품으로 확장 가능한 디자인 시스템 - 리브랜딩은 시각적 결과물뿐 아니라 디자이너들이 협업하는 방식과 시스템을 정립하는 계기이기도 했습니다. - Gusto는 제품이 어떤 모습이어야 하는지에 대한 단일 기준, 즉 “시스템 오브 레코드”가 필요했습니다. - 이를 위해 제품 디자인팀은 Figma의 다음 기능을 활용해 UI 키트를 구축했습니다. - 공유 라이브러리 - 재사용 가능한 컴포넌트 - 브랜드 가이드라인을 반영한 UI 요소 - 이 시스템은 각 제품과 화면에서 일관된 디자인을 유지하고, 새로운 브랜드를 회사 규모에 맞게 확장하는 기반이 되었습니다. ## 실용적인 시사점 - 리브랜딩은 브랜드팀만의 프로젝트가 아니라 제품, 마케팅, 콘텐츠, 개발 등 고객 경험에 관여하는 모든 팀의 공동 작업이어야 합니다. - 디자인 파일을 협업의 중심에 두고 실시간 확인과 댓글을 활성화하면 비디자이너의 참여와 이해를 높일 수 있습니다. - 브랜드 가이드라인을 실제 UI 키트, 라이브러리, 컴포넌트로 연결해야 브랜드가 제품 경험에 일관되게 적용되고 장기적으로 확장됩니다.

원문 읽기(새 탭에서 열림)
Figma디자인 시스템collaborative-designuser-interface-design+2
figma3분 읽기큐레이션 요약

Figma의 인프라: 웹

Figma는 웹 기반 디자인 도구도 데스크톱 애플리케이션 수준의 속도와 안정성을 제공해야 한다고 주장한다. 이를 위해 클라우드 기반의 단일 진실 공급원, 실시간 협업, 프로토타이핑과 개발자 핸드오프를 통합했으며, 사용자와 데이터가 증가함에 따라 인프라를 확장 가능한 구조로 전환하고 있다. 핵심 과제는 불필요한 데이터 로딩을 줄이고, 데이터베이스를 수평 확장하며, 전 세계 사용자의 지연 시간을 낮추는 것이다. ## Figma가 해결하려는 문제 - 기존 디자인 작업은 특정 데스크톱 애플리케이션과 플랫폼에 종속됐다. - 파일을 내보내거나 여러 도구 사이에서 옮기는 과정에서 최신 버전 관리와 협업이 어려웠다. - Figma는 디자인 파일을 클라우드에 저장하고 고유 URL을 부여해 팀 전체의 단일 진실 공급원으로 만든다. - 프로토타이핑과 개발자 핸드오프 기능을 제품 안에 포함해 별도 도구와 파일 변환의 필요성을 줄였다. ## 실시간 협업과 인프라 요구사항 - 여러 사용자가 하나의 파일을 동시에 보고 편집할 수 있는 멀티플레이어 기능을 제공한다. - 디자인 파일에는 복잡한 도형과 대용량 이미지가 포함될 수 있어 백엔드와 네트워크로 전송되는 데이터가 많다. - 사용자는 데스크톱 도구와 같거나 더 나은 상호작용 성능을 기대한다. - 따라서 인프라는 다음 요구사항을 동시에 충족해야 한다. - 낮은 상호작용 지연 시간 - 높은 가용성 - 대규모 파일과 동시 접속 처리 - 실시간 변경사항 동기화 ## 초기 인프라의 한계 - 초기 Figma는 단순한 백엔드 구조를 사용해 빠르게 제품을 개발하고 운영했다. - 예를 들어 파일을 로드할 때 사용자가 접근 가능한 공유 컴포넌트를 모두 미리 불러왔다. - 공유 디자인 요소가 수천 개일 때는 효과적이었지만, 조직의 라이브러리가 약 1만 개에 가까워지면 백엔드에 큰 부담이 발생했다. - Microsoft, Uber 같은 대규모 조직의 도입과 글로벌 사용자 증가로 이러한 문제가 일반적인 확장성 문제로 나타났다. ## 필요한 데이터만 불러오는 구조 - 기존 시스템은 사용자가 실제로 즉시 필요로 하지 않는 데이터까지 파일 로드 시점에 미리 가져오는 경우가 있었다. - 이 방식은 초기 진입 속도와 백엔드 부하 모두에 악영향을 준다. - 단순히 서버 성능만 개선하는 것으로는 해결되지 않으며, 클라이언트와 서버 간 상호작용 방식을 다시 설계해야 한다. - 클라이언트가 필요한 정보만 요청하도록 제품의 데이터 로딩 방식과 사용자 경험을 함께 바꿔야 한다. - 인프라 팀뿐 아니라 제품과 클라이언트 개발팀의 협업이 필요한 문제다. ## 단일 데이터베이스에서 수평 확장으로 - 당시 Figma의 전체 인프라는 AWS의 매우 강력한 단일 데이터베이스 인스턴스에 의존했다. - 단순한 구조를 선호하는 KISS 원칙 덕분에 초기에는 운영이 쉬웠고 빠르게 성장할 수 있었다. - 그러나 단일 인스턴스는 성능과 용량 확장에 한계가 있다. - 다음 단계에서는 여러 노드로 확장할 수 있는 수평 확장형 데이터베이스 계층을 구축하려 했다. - 데이터베이스를 거의 모든 시스템과 서비스가 사용하므로, 일관성·장애 처리·서비스 의존성까지 함께 재설계해야 하는 대규모 작업이다. ## 글로벌 사용자의 지연 시간 개선 - 주간 활성 사용자의 80% 이상이 미국 외 지역에 있었다. - 당시 요청은 미국 오리건의 데이터센터까지 왕복해야 했기 때문에, 사용자 경험이 물리적 네트워크 거리에 영향을 받았다. - 이를 개선하기 위해 사용자와 가까운 곳에 인프라 구성 요소를 배치하려 했다. - 첫 단계로 전 세계 주요 지역에 원격 프록시를 전략적으로 배치해 데이터센터까지의 네트워크 지연을 줄이는 방안을 추진했다. - 장기적으로는 글로벌 사용자에게 더 가까운 위치에서 요청을 처리하는 방향으로 인프라를 발전시키려 했다. ## 실용적인 결론 웹 기반 협업 도구의 확장은 서버를 더 큰 장비로 교체하는 것만으로 해결되지 않는다. 필요한 데이터만 지연 로딩하고, 데이터베이스를 수평 확장하며, 사용자가 가까운 위치에서 서비스를 이용하도록 네트워크 구조를 개선하는 등 제품 경험과 시스템 아키텍처를 함께 재설계해야 한다.

원문 읽기(새 탭에서 열림)
AWSreal-time-collaboration분산 시스템성능 최적화+2
figma4분 읽기큐레이션 요약

디자인 시스템을 뒷받침

Figma는 디자인 시스템의 사용 데이터를 분석하면 팀이 실제로 어떤 라이브러리와 컴포넌트를 사용하는지 파악하고, 이를 바탕으로 시스템을 지속적으로 개선할 수 있다고 주장합니다. Design System Analytics는 라이브러리 사용 추이, 라이브러리 간 채택률, 개별 컴포넌트의 삽입·분리 현황을 제공해 디자인 시스템 운영을 정성적 피드백에서 정량적 개선으로 확장합니다. 다만 목적은 디자이너를 감시하는 것이 아니라 사용 패턴을 이해하고 더 나은 컴포넌트와 라이브러리를 만드는 데 있습니다. ## 디자인 시스템 사용 데이터를 분석하는 이유 - Figma는 클라우드 기반 브라우저 도구이므로 디자이너들이 디자인 시스템을 어떻게 사용하는지 데이터를 통해 파악할 수 있습니다. - Design System Analytics를 사용하면 다음 정보를 확인할 수 있습니다. - 라이브러리 사용량의 시간별 추이 - 여러 라이브러리 간 사용량 비교 - 개별 컴포넌트의 사용, 삽입, 분리 현황 - 분석 결과는 조직 내 누구나 확인할 수 있어 디자이너와 관리자가 필요한 리포트를 직접 살펴볼 수 있습니다. - Figma는 분석 기능을 설계할 때 디자이너의 모든 행동을 통제하거나 감시하지 않는 방향을 강조했습니다. ## 사용되지 않거나 개선이 필요한 컴포넌트 찾기 - 라이브러리와 컴포넌트별 사용량을 보면 어떤 요소가 실제 업무에 기여하는지 파악할 수 있습니다. - Microsoft의 Fluent 디자인 시스템은 다음과 같은 질문에 데이터를 활용합니다. - 거의 사용되지 않는 컴포넌트는 무엇인가? - 자주 분리(detach)되는 컴포넌트는 무엇인가? - 유지보수가 불필요하거나 개선이 필요한 컴포넌트는 무엇인가? - Google Material Design 팀은 버튼 컴포넌트가 가장 많이 사용되는 동시에 가장 많이 분리되는 현상을 발견했습니다. - 이를 통해 기존 버튼 컴포넌트가 지나치게 복잡하다는 점을 파악하고, 더 단순한 대체 컴포넌트를 추가하는 개선으로 이어졌습니다. - 즉, 높은 사용량만 보는 것이 아니라 높은 분리율도 컴포넌트 설계가 실제 요구와 맞지 않는다는 신호로 활용할 수 있습니다. ## 라이브러리 채택과 마이그레이션 추적 - 두 라이브러리의 사용량을 시간에 따라 비교해 새 라이브러리로의 전환이 제대로 진행되는지 확인할 수 있습니다. - Squarespace는 기존 공유 라이브러리를 Auto Layout 기반의 새 라이브러리로 교체하는 과정에서 이 기능을 활용하려 했습니다. - 분석 화면에서는 다음과 같은 정보를 확인할 수 있습니다. - 기간별 컴포넌트 삽입 수 - 구버전과 신버전 라이브러리의 사용량 비교 - 새 라이브러리를 적극적으로 사용하는 상위 팀 - 컴포넌트별 전체 인스턴스 수, 최근 삽입 수, 분리 수 - 이를 통해 새 라이브러리의 채택률을 측정하고, 구버전 라이브러리의 폐기(deprecation)를 관리할 수 있습니다. - 예시 화면에는 최근 60일간의 삽입 추이와 팀별 사용 비중, 개별 버튼 컴포넌트의 인스턴스·삽입·분리 통계가 표시됩니다. ## 개별 컴포넌트 사용 방식 파악 - 단순히 라이브러리 전체의 사용량만 보는 것을 넘어 개별 컴포넌트가 실제로 어떻게 활용되는지 조사할 수 있습니다. - Pluralsight는 공유 컴포넌트가 팀원들의 작업에서 어떻게 사용되는지 파악하는 데 Analytics를 활용하려 했습니다. - 조직 내 모든 디자이너와 관리자가 분석 결과와 사용 사례를 확인할 수 있으므로: - 특정 컴포넌트의 실제 활용 사례를 빠르게 찾을 수 있습니다. - 다른 팀의 사용 방식을 참고할 수 있습니다. - 디자인 시스템 팀이 개선 우선순위를 정하기 쉬워집니다. ## 디자인 초기 단계에서 영향 측정 - 기존에는 디자인 시스템 도입 효과를 개발 단계에서 측정하는 경우가 많았습니다. - Design System Analytics를 이용하면 제품 개발이 개발 단계에 도달하기 전, 디자인 과정에서 시스템이 얼마나 채택되고 있는지도 확인할 수 있습니다. - 따라서 디자인 시스템 팀은 다음을 더 일찍 파악할 수 있습니다. - 제품팀이 공통 컴포넌트를 실제로 사용하고 있는지 - 새 라이브러리가 설계 작업에 자연스럽게 도입되고 있는지 - 특정 팀이나 프로젝트가 시스템에서 이탈하고 있는지 - 이는 개발 단계의 준수 여부를 사후 점검하는 방식에서, 디자인 단계부터 채택을 높이는 방식으로 관점을 바꿉니다. ## 기능의 변화 - 원문은 2019년 발표 내용을 다루지만, 안내문에 따르면 2025년 2월 기준 Figma Library Analytics는 컴포넌트뿐 아니라 스타일과 변수 데이터도 지원합니다. - Organization 및 Enterprise 고객에게 관련 데이터가 제공되며, Enterprise 고객은 Library Analytics API를 통해 확장된 기능을 사용할 수 있습니다. - 따라서 현재 기능은 원문에 설명된 초기 버전보다 범위가 넓어졌을 수 있습니다. 실무적으로는 사용량이 낮은 컴포넌트를 무조건 제거하기보다, 삽입 수와 분리율을 함께 분석하는 것이 좋습니다. 또한 라이브러리 마이그레이션 시 팀별 채택률과 구버전 사용량을 지속적으로 추적하면 디자인 시스템 개선과 폐기 계획을 데이터에 근거해 운영할 수 있습니다.

원문 읽기(새 탭에서 열림)
Figma디자인 시스템auto-layoutcomponent-libraries+1
figma2분 읽기큐레이션 요약

피그마의 첫 번째 사용자 컨

Figma는 사용자들이 서로 배우고 교류할 수 있는 첫 사용자 컨퍼런스를 2020년 2월 6일 샌프란시스코에서 개최한다고 발표했다. 이 행사는 Figma 커뮤니티의 지식과 경험을 오프라인에서 공유하는 자리로, 짧은 발표·워크숍·라운드테이블 중심으로 구성된다. Figma는 다양한 배경의 참가자와 발표자를 모집하고, 비용 부담을 줄이기 위해 장학금도 제공할 계획이다. ## 커뮤니티를 오프라인으로 확장 - Figma의 사용자는 초기 베타 고객 중심에서 전 세계 수십만 명의 활성 사용자로 성장했다. - 디자인은 계속 변화하기 때문에 디자이너들은 동료에게서 영감, 지식, 실무 아이디어를 얻는다. - Figma는 앞서 제품 안에 디자인 파일을 공유하고 사용자끼리 연결되는 **Figma Community**를 공개했다. - 첫 사용자 컨퍼런스는 이러한 커뮤니티 활동을 오프라인 공간으로 확장하려는 시도다. ## 사용자 중심의 발표 프로그램 - 컨퍼런스 프로그램은 Figma 사용자들의 참여를 중심으로 구성된다. - 주요 형식은 다음과 같다. - 짧은 라이트닝 토크 - 실습 중심 워크숍 - 참가자 간 라운드테이블 - 일부 기조연설 - 발표 시간은 **15분부터 1시간**까지 가능하다. - Figma 활용 사례, 어려운 경험에서 얻은 교훈, 동료와 논의하고 싶은 주제, 협업 활동 등을 제안할 수 있다. - 직접 발표하거나 다른 사람을 발표자로 추천할 수 있으며, 제안 마감은 **2019년 11월 20일 오후 11시 59분(PST)**이었다. ## 다양성과 의미 있는 대화를 위한 참가자 선정 - 행사의 규모를 작게 유지해 참가자 간 깊이 있는 대화가 가능하도록 할 계획이다. - 능력, 나이, 교육 수준, 민족, 성별, 인종, 성적 지향, 사회경제적 배경 등 다양한 특성을 고려한다. - 신청자가 많을 경우 매진을 피하고 다양성을 확보하기 위해 추첨 방식이 사용될 수 있다. - 선정된 참가자는 통보 후 일주일 동안 티켓을 구매할 수 있다. ## 참가비와 장학금 - 컨퍼런스 참가비는 **299달러**다. - 비용 때문에 참여하지 못하는 사람이 없도록 재정 지원이 필요한 참가자를 위한 장학금 프로그램을 운영한다. - 참가 신청 마감 역시 **2019년 11월 20일**로 안내됐다. Figma는 단순히 제품을 소개하는 행사가 아니라, 사용자들이 직접 지식과 경험을 나누며 함께 프로그램을 만들어가는 커뮤니티 행사로 첫 컨퍼런스를 기획했다. 참여를 원한다면 발표 제안이나 참가 신청을 제출하고, 비용 부담이 있다면 장학금 신청을 함께 고려하는 방식이 적절하다.

원문 읽기(새 탭에서 열림)
Figmacollaborative-designfigma-pluginsfigma-community+1
figma4분 읽기큐레이션 요약

멀티플레이어를 넘어: Figma

Figma는 실시간 공동 편집을 넘어, 디자인을 공개하고 함께 배우며 재사용하는 커뮤니티 중심의 생태계를 구축하려 했다. 이를 위해 누구나 디자인 파일을 탐색·검사·리믹스할 수 있는 Figma Community 베타와, 팀 구성원이 중요한 작업을 쉽게 찾도록 개편한 workspace를 공개했다. 핵심은 디자인 과정을 더 개방적으로 만들고, 기업·교육기관·정부·개인 디자이너가 지식과 자산을 공유하도록 지원하는 것이다. ## 멀티플레이어에서 공개형 디자인 생태계로 - Figma는 4년 전 실시간 공동 편집 기능을 도입하면서 디자인이 더 개방적이고 클라우드 중심이어야 한다고 보았다. - 사용자들은 점차 다음과 같은 방식으로 디자인 프로세스를 개방했다. - 비디자이너를 작업 과정에 참여시킴 - 팀원과 동시에 파일을 편집함 - 작업물과 제작 방법을 커뮤니티에 공유함 - Figma는 이러한 변화를 확장하기 위해 두 공간을 도입했다. - **Figma Community**: 공개된 디자인 파일을 누구나 살펴보고, 리믹스하고, 학습할 수 있는 공간 - **개편된 Figma workspace**: 팀 구성원 중심으로 중요한 작업과 프로젝트를 쉽게 발견하는 공간 ## Figma Community 베타의 구조 - 사용자는 자신의 공개 프로필에 어떤 파일을 게시할지 직접 선택할 수 있다. - 초기 기본 라이선스로 **Creative Commons Attribution 4.0 International(CC BY 4.0)**을 제공했다. - 다른 사람이 파일을 사용·수정·공유할 수 있음 - 원작자 표시가 필요함 - Figma는 향후 더 제한적인 라이선스도 검토할 계획이며, 베타 기간 동안 사용자 의견을 수집하려 했다. - 여러 달 동안 베타를 운영하며 기업, 학교, 정부기관, 독립 디자이너의 요구를 확인하는 방식으로 제품을 발전시키려 했다. ## 기업이 공유하는 디자인 시스템과 리소스 - 기업은 파트너나 다른 디자이너가 활용할 수 있는 공개 디자인 자산을 배포할 수 있다. - 사례: - **Slack**: 파트너가 Slack 앱을 더 잘 만들 수 있도록 UI 키트 공개 - **Dropbox**: 디자인 관리자가 조직에서 활용할 수 있는 문화 키트 공유 - **Unsplash**: 디자인에 사용할 수 있는 아바타를 쉽게 제공 - **VMware**: 공개 디자인 시스템인 Clarity를 더 쉽게 활용하도록 지원 - Community는 기업의 디자인 시스템을 문서로만 설명하는 대신, 실제 편집 가능한 파일과 구성 요소로 배포하는 수단이 된다. ## 공공기관과 교육기관의 활용 - **시카고시**는 시민들이 자신의 정체성에 맞게 수정할 수 있는 공개 디자인 시스템을 준비했다. - **Lambda School**과 **Stanford d.school**은 무료 학습 템플릿을 공개하려 했다. - 이를 통해 Figma Community는 단순한 포트폴리오 공간을 넘어 다음 용도로 활용될 수 있다. - 교육 자료 배포 - 공공 서비스용 디자인 시스템 공유 - 시민·학생·학습자의 직접적인 수정과 실습 - 조직 간 디자인 표준 확산 ## 개인 디자이너의 포트폴리오와 튜토리얼 - 개인 디자이너는 Dribbble이나 Behance를 보완하는 공개 Figma 프로필을 만들 수 있다. - 발표 자료 디자이너 **Zach Grosser**는 인기 있는 슬라이드 템플릿을 공개하려 했다. - 디자이너 **David Kulakevich**의 사례는 Community의 학습 기능을 보여준다. - Figma로 제작한 그림을 처음에는 피드백을 받기 위해 공유 - 다른 사람들이 제작 과정을 궁금해하자 레이어별 작업 과정을 영상으로 설명 - 이후 원본 파일을 공개해 누구나 각 레이어와 제작 방식을 직접 확인할 수 있도록 함 - 완성된 이미지뿐 아니라 편집 가능한 원본을 공유함으로써 결과물 감상에서 실제 학습과 재현으로 확장된다. ## 기업 경계를 넘는 협업 - Square Crypto는 Bitcoin 생태계에 디자인과 코드를 개방적으로 기여하는 방식을 연구하고 있었다. - Figma는 이 팀과 협력해 회사 간 경계를 넘는 디자인 프로젝트에 필요한 기능을 탐색했다. - 이는 Community가 개인 파일 공유를 넘어, 여러 조직이 투명하게 공동 작업하는 기반이 될 가능성을 보여준다. - 공개성과 투명성을 중시하는 오픈소스 커뮤니티의 협업 방식에 디자인 도구를 연결하려는 시도이기도 하다. ## 워크스페이스 내부의 커뮤니티 - Figma는 공개 Community뿐 아니라 각 팀의 workspace 안에도 사람 중심의 공동 공간을 만들고자 했다. - 기존 디자인 파일은 파일 자체를 중심으로 구성되어 팀의 구성원이나 관계를 충분히 드러내지 못했다. - 개편된 workspace는 팀원이 중요한 작업과 프로젝트를 더 쉽게 발견하도록 설계되었다. - 제공된 글 내용에서는 이 내부 커뮤니티 기능의 구체적인 동작이나 세부 기능은 추가로 설명되지 않는다. ## 실용적인 결론 Figma Community는 디자인 파일을 단순히 보여주는 곳이 아니라, 편집 가능한 원본·템플릿·디자인 시스템을 공유해 다른 사람이 직접 배우고 재사용하도록 만드는 플랫폼이다. 조직은 공개 가능한 UI 키트와 시스템을 배포하고, 개인 디자이너는 작업 과정과 원본 파일을 포트폴리오 및 교육 자료로 활용할 수 있다. 다만 공개 전에는 라이선스 조건과 파일에 포함된 기밀 정보·브랜드 자산을 반드시 확인해야 한다.

원문 읽기(새 탭에서 열림)
Figma디자인 시스템real-time-collaborationplugins+2
figma4분 읽기큐레이션 요약

피그마의 멀티플레이어

Figma는 Google Docs처럼 복잡한 OT(Operational Transformation)를 적용하는 대신, 디자인 문서의 구조에 맞춘 단순한 자체 멀티플레이어 시스템을 구축했다. 클라이언트와 서버는 WebSocket으로 변경 사항을 동기화하고, 서버가 문서별 단일 조정자로 동작해 충돌을 관리한다. 이 방식은 실시간 협업뿐 아니라 오프라인 편집과 재접속까지 지원하면서도 Figma의 데이터 모델에 맞는 구현 단순성을 유지했다. ## 웹 기반 협업을 선택한 이유 - 멀티플레이어 기능이 있으면 파일을 내보내거나 복사본을 이메일로 주고받고, 변경 사항을 수동으로 동기화할 필요가 없다. - 링크 하나만으로 여러 사람이 현재 디자인 상태를 확인할 수 있다. - 디자이너뿐 아니라 카피라이터, 개발자 등도 같은 문서에 참여할 수 있다. - 초기에는 실시간 협업이 “디자인을 망치는 기능”으로 여겨졌지만, 웹 생산성 도구에는 자연스러운 기본 기능이 되었다. ## Figma의 클라이언트·서버 구조 - 웹 클라이언트는 WebSocket을 통해 멀티플레이어 서버 클러스터와 통신한다. - 문서마다 별도의 서버 프로세스를 두고, 해당 문서를 편집하는 사용자들이 같은 프로세스에 연결된다. - 문서를 열 때 클라이언트가 먼저 파일 전체를 내려받는다. - 이후 변경 사항은 양방향 WebSocket 연결을 통해 실시간으로 전송된다. - 댓글, 사용자, 팀, 프로젝트 같은 데이터는 멀티플레이어 시스템이 아니라 Postgres와 별도 동기화 시스템으로 관리한다. - 문서 편집과 기타 애플리케이션 데이터는 성능, 오프라인 지원, 보안 요구 사항이 다르기 때문에 구현을 분리했다. ## 오프라인 편집과 재접속 - 사용자는 네트워크가 끊긴 상태에서도 임의의 시간 동안 계속 편집할 수 있다. - 다시 온라인이 되면 클라이언트는 서버에서 최신 문서 사본을 받는다. - 그 위에 오프라인 동안 발생한 로컬 변경을 다시 적용한다. - 이후 새로운 WebSocket 연결을 통해 서버와 변경 사항을 계속 동기화한다. - 연결과 재연결 자체는 단순하게 만들고, 멀티플레이어의 핵심 복잡성은 이미 연결된 문서에 동시에 변경 사항이 들어오는 상황에 집중했다. ## OT와 CRDT 대신 자체 방식을 택한 이유 - OT는 Google Docs 등에서 널리 사용된 표준적인 협업 알고리즘이다. - 여러 사용자의 동시 작업을 변환해 충돌을 해결할 수 있지만, 구현과 검증이 복잡하다. - Figma는 텍스트 편집기와 달리 계층적인 디자인 객체를 편집하므로, 일반적인 OT 모델을 그대로 적용할 필요가 없다고 판단했다. - 스타트업으로서 빠르게 기능을 개발하고 실험하려면 더 단순한 구조가 유리했다. - Figma는 디자인 문서의 데이터 구조와 편집 패턴에 맞춘 전용 동기화 방식을 만들었다. ## 프로토타입을 통한 설계 검증 - 실제 제품 코드에 바로 적용하지 않고, 여러 클라이언트와 서버를 시뮬레이션하는 별도의 웹 기반 실험 환경을 만들었다. - 프로토타입에서는 여러 사용자의 상태와 변경 사항을 시각적으로 확인할 수 있었다. - 오프라인 클라이언트, 느린 네트워크, 제한된 대역폭 등 다양한 상황을 쉽게 재현했다. - 이를 통해 협업 알고리즘과 데이터 구조를 빠르게 비교하고 실험했다. - 설계가 확정된 뒤 프로토타입에서 검증한 아이디어를 기존 코드베이스에 이식했다. ## 서버 중심의 동기화 모델 - 하나의 문서에 연결된 사용자들은 같은 서버 프로세스를 공유한다. - 서버는 문서에 들어오는 변경 사항을 순서대로 처리하고 다른 클라이언트에 전달한다. - 클라이언트는 처음 받은 문서 상태를 기준으로 로컬 변경을 수행하면서 서버의 업데이트를 계속 반영한다. - 서버를 문서의 조정자로 두면 여러 클라이언트가 서로 직접 충돌을 해결할 필요가 줄어든다. - 동시에 발생한 변경의 처리 순서는 서버가 정하며, 모든 클라이언트가 최종적으로 같은 문서 상태에 도달하도록 한다. ## 이 접근법의 핵심 장점 - 범용 협업 알고리즘보다 Figma의 객체 중심 데이터 모델에 맞게 단순하게 구현할 수 있다. - 온라인 편집뿐 아니라 오프라인 작업과 재접속도 지원한다. - 별도 프로토타입으로 다양한 장애 상황을 반복적으로 테스트할 수 있다. - 문서 편집 동기화와 서비스 메타데이터 동기화를 분리해 각각의 요구 사항에 맞게 최적화할 수 있다. 실용적으로는 모든 협업 애플리케이션이 OT나 CRDT를 그대로 도입해야 하는 것은 아니다. 데이터 구조가 명확하고 충돌 패턴이 제한적이라면, 서버 중심의 단순한 프로토콜과 충분한 시뮬레이션 테스트를 결합하는 편이 더 빠르고 유지보수하기 쉬울 수 있다.

원문 읽기(새 탭에서 열림)
PostgreSQLreal-time-collaborationRustwebsockets+2
figma3분 읽기큐레이션 요약

Figma 브랜드에 새로운 생

Figma의 브랜드 리프레시는 기존 정체성을 버리는 대신, 회사의 성장에 맞춰 확장하는 작업이었다. 핵심 방법은 여러 팀의 협업과 Figma 자체를 활용한 제작 과정이었으며, 브랜드를 더 유연하고 생동감 있게 만드는 데 초점을 맞췄다. 새로운 시각 언어는 호기심·활력·정직함·대담함이라는 성격을 바탕으로 일관성과 실험성을 함께 추구했다. ## 기존 브랜드 언어의 확장 - Figma는 새로운 브랜드를 처음부터 만들지 않고, 기존 브랜드의 강점과 가치관을 분석해 발전시켰다. - 초기 브랜드 가이드는 회사 규모가 작을 때 만들어졌기 때문에 블로그, 다양한 콘텐츠, 기업 고객 등 성장한 조직의 요구를 충분히 다루지 못했다. - 기존의 색상, 형태, 개념을 유지하면서도 새로운 활용 규칙과 가이드 문서를 추가했다. - 브랜드의 형태와 요소를 더 다양한 상황에 배치하고 활용해, 익숙함은 유지하면서 표현의 범위를 넓혔다. ## 브랜드 성격을 정의하는 네 가지 기준 브랜드를 하나의 인격체처럼 바라보며, 디자인과 커뮤니케이션의 방향을 정할 네 가지 성격을 정립했다. - **호기심 있는(Curious)**: 영리하고 장난기 있으며 상상력이 풍부하다. 당연하지 않은 가능성을 탐구한다. - **생동감 있는(Vibrant)**: 역동적이고 자신감 있으며 특정 주제에 깊이 몰입한다. - **정직한(Honest)**: 포용적이고 공감 능력이 있으며 approachable하다. 모든 것을 안다고 가장하지 않고 함께 해결한다. - **대담한(Bold)**: 강력하고 예상 밖이며 비순응적이다. 관습보다 자신에게 맞는 방식을 선택한다. - 이 기준은 소비자 대상 콘텐츠부터 엔터프라이즈 커뮤니케이션까지 폭넓게 적용될 수 있도록 설계됐다. ## 협업을 표현하는 도형과 일러스트 - 도형은 단순한 장식이 아니라 서로 대화하고 협력하거나 충돌하는 사람처럼 설정됐다. - 도형의 위치와 조합에 따라 조화로운 구성을 만들 수 있으며, 모든 도형이 서로 잘 어울리는 것은 아니라는 점도 반영했다. - 상황에 따라 일러스트의 추상화 수준을 조절했다. - 학습이나 명확한 안내가 필요한 장면에서는 단순하고 직관적인 일러스트를 사용한다. - 보다 개념적인 콘텐츠에서는 여러 도형을 조합해 풍부한 의미를 만든다. - 복잡한 결과물도 기본 도형에서 출발한다는 점을 보여 주며 디자인 과정을 쉽게 이해하도록 했다. - 완성되고 완벽한 결과만 보여 주는 대신, 최소 한 요소가 편집되거나 조작되는 상태를 표현했다. - 이러한 미완성의 모습은 디자인이 실제로는 messy하고 계속 변화하는 과정임을 강조하며, 사람들이 자신의 제작 과정을 공유하도록 장려한다. ## 개성이 드러나는 서체 선택 - 새로운 브랜드 서체로 Dinamo의 **Whyte**를 선택했다. - Whyte에는 일반 버전과 **inktrap** 버전이 있으며, Figma는 후자의 독특한 형태에 주목했다. - 잉크트랩은 금속 활판 인쇄에서 잉크가 번지는 것을 제어하기 위해 글자에 만든 홈에서 유래했다. - 작은 크기에서는 잘 보이지 않지만 확대하면 글자 모서리의 홈이 드러나며, 서체 자체에 일러스트적인 개성을 더한다. - 이 서체는 평범하고 절제된 인상과 비정형적이고 실험적인 인상을 동시에 전달해, Figma가 추구한 유연한 브랜드 성격과 맞았다. ## Figma로 Figma를 재설계하다 - 브랜드 리프레시 작업 전체를 Photoshop이나 Illustrator가 아닌 Figma에서 진행했다. - 기존 도구에 익숙했던 디자이너들은 Figma의 제약과 기능에 맞춰 새로운 제작 방식을 찾아야 했다. - 이 과정에서 도구의 특성이 새로운 아이디어를 발전시키는 계기가 됐다. - 여러 팀이 함께 작업하고 의견을 주고받는 협업 방식 자체가 브랜드 리프레시의 핵심 주제와 연결됐다. - 결과적으로 브랜드를 설명하는 시각 언어뿐 아니라, 브랜드를 만드는 과정도 Figma의 협업 철학을 보여 주게 됐다. 브랜드를 새로 만들 때는 기존 자산을 무조건 폐기하기보다, 핵심 정체성을 먼저 찾아 성장한 조직에 맞게 확장하는 접근이 효과적이다. 또한 성격을 구체적인 언어로 정의하고, 시각 요소와 제작 과정 모두에 그 기준을 적용하면 일관되면서도 유연한 브랜드를 만들 수 있다.

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

Figma로 하는 고객

고객 여정 지도는 고객이 특정 과정을 거치며 경험하는 단계와 감정, 고충을 시각적으로 보여 주어 팀의 공통 이해를 돕는 도구다. 글은 Figma를 활용하면 여정 지도 제작부터 인터뷰 기록, 협업, 버전 관리, 고객 피드백 수집까지 하나의 공간에서 수행할 수 있다고 설명한다. 다만 프로세스가 비선형적이거나 분기·의존성이 많다면 고객 여정 지도보다 사용자 흐름도가 더 적합할 수 있다. ## 고객 여정 지도가 필요한 이유 - 자동차 구매, 웹사이트 상품 구매, 의료 서비스 이용처럼 고객이 여러 단계를 거치는 과정을 시각적으로 표현한다. - 각 단계에서 고객이 무엇을 하고, 어떤 감정을 느끼며, 어떤 불편이나 고충을 겪는지 함께 기록할 수 있다. - 서로 다른 관점을 가진 팀원도 동일한 지도를 보며 조사 결과를 빠르게 이해할 수 있다. - 고객 경험을 개선할 수 있는 문제 지점과 기회를 공동으로 발견하는 데 유용하다. - 프로세스가 단순하고 순차적일 때 특히 효과적이다. - 반대로 분기나 의존성이 많은 비선형 프로세스에는 전통적인 2차원 사용자 흐름도가 더 적합하다. ## 여정 지도 컴포넌트 라이브러리 구축 - 팀 전용 컴포넌트와 스타일 라이브러리를 만들면 지도마다 일관된 시각 언어를 유지할 수 있다. - 반복적으로 사용하는 단계, 감정 표현, 아이콘, 라벨 등을 재사용해 새 지도를 빠르게 제작할 수 있다. - 디자인 변경이 필요할 때 개별 요소를 수정하는 대신 컴포넌트를 업데이트하면 전체 지도에 일괄 반영할 수 있다. - Figma의 샘플 파일이나 고객 여정 지도 템플릿을 출발점으로 활용할 수 있다. ## Tidy Up으로 단계 정리 - Figma의 **Tidy Up** 기능을 사용하면 여정 단계 사이의 간격을 쉽게 조정할 수 있다. - 중간에 새로운 단계를 삽입하거나 기존 단계를 재배치할 때 전체 레이아웃을 크게 다시 작업하지 않아도 된다. - 단계가 많아질수록 수동 정렬에 드는 시간을 줄이고 구조적인 배치를 유지할 수 있다. ## 실시간 협업과 인터뷰 기록 - 여러 디자이너가 동시에 같은 여정 지도를 편집할 수 있다. - 인터뷰 노트를 Figma에 직접 기록하면 조사 자료와 디자인 결과물이 여러 도구로 분산되지 않는다. - 리서치 담당자와 디자이너가 동일한 파일에서 내용을 확인하고 즉시 보완할 수 있다. - 인터뷰 정보와 지도 요소가 한곳에 모이므로 조사 결과를 시각적 산출물에 연결하기 쉽다. ## 버전 기록으로 변화 추적 - 고객 리뷰 전에 Figma 버전 기록에 수동으로 타임스탬프를 남겨 특정 시점의 결과물을 보존한다. - 프로젝트가 진행되며 고객에 대한 이해가 어떻게 바뀌었는지 이전 버전과 비교할 수 있다. - 클라이언트에게 여정 지도가 조사 결과에 따라 어떻게 발전했는지 보여 주는 자료로도 활용할 수 있다. ## 댓글을 활용한 지속적인 피드백 - 완성본이 아닌 초기 여정 지도를 실제 고객에게 공유해 조사 결과가 고객 경험과 일치하는지 검증한다. - 고객이 빠진 단계나 새롭게 탐색해야 할 경험을 댓글로 지적할 수 있다. - 댓글을 특정 지도 요소에 직접 배치하면 나중에 어느 단계에 대한 의견인지 명확하게 확인할 수 있다. - 비동기 검토에서는 고객이 파일에 댓글을 남기고, 팀이 댓글 스레드에서 추가 질문을 할 수 있다. - 회의나 화상 통화 중에는 디자이너가 참석자들의 의견을 해당 위치에 바로 기록할 수 있다. - 필요하면 파일을 복제해 고객, 클라이언트 등 피드백 출처별로 분리한다. - 새 검토자가 이전 댓글에 영향을 받지 않도록 하여 편향되지 않은 의견을 얻을 수 있다. - 고객과 클라이언트의 피드백을 비교해 두 집단의 인식 차이도 파악할 수 있다. ## 실용적인 적용 방향 Figma로 고객 여정 지도를 만들 때는 먼저 재사용 가능한 컴포넌트와 스타일을 정하고, 인터뷰 노트와 지도를 같은 파일에서 관리하는 것이 좋다. 이후 버전을 저장하며 고객과 클라이언트에게 단계별 댓글 피드백을 받아 지도를 반복 개선하면, 단순한 시각 자료를 넘어 지속적으로 검증되는 리서치 문서로 활용할 수 있다.

원문 읽기(새 탭에서 열림)
Figma프로토타이핑real-time-collaborationcomponent-library+2