techlist.io
KREN

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

figma3분 읽기큐레이션 요약

디자인에서 신뢰의 다양한 차

디자인 협업에서 신뢰는 단순한 친밀감을 넘어, 팀과 고객이 솔직하게 소통하고 반복적인 작업 과정을 안전하게 공유하게 만드는 기반이다. 신뢰를 구축하려면 구성원을 인간적으로 이해하고, 진행 중인 작업의 상태와 피드백 범위를 명확히 하며, 디자인의 윤리적·사회적 영향까지 공개적으로 논의해야 한다. 이러한 문화는 단기간에 만들어지지 않지만, 의도적인 대화와 명확한 협업 규칙을 통해 강화할 수 있다. ## 인간적인 관계를 통한 신뢰 형성 - 신뢰는 직속 동료뿐 아니라 제품 개발에 참여하는 모든 사람을 이해하는 데서 시작된다. - 짧은 안부 대화나 회의 전후의 캐주얼한 대화, 이메일 대신 간단한 통화 등을 통해 서로의 생각과 업무 방식을 파악할 수 있다. - 디자인 비평에서 피드백이 배려와 지원에서 비롯된다는 확신이 있어야 구성원이 방어적으로 반응하지 않는다. - 팀원들이 서로의 의도와 어려움을 긍정적으로 해석하는 문화를 만들면, 더 솔직하고 직접적인 피드백이 가능해진다. - 공감은 협업자의 관점과 작업 방식을 이해하고 신뢰를 유지하는 중요한 도구다. ## 진행 중인 작업을 안전하게 공유하기 - Figma처럼 실시간으로 작업물이 업데이트되는 환경에서는 고객이 초기 아이디어와 미완성 시안을 그대로 보게 된다. - 이러한 투명성은 프로젝트의 현재 상태를 공유하는 데 유용하지만, 충분히 다듬어지지 않은 작업에 즉각적인 피드백이 들어오는 부담도 만든다. - 협업 파일을 함께 사용할 때는 다음과 같은 운영 규칙을 미리 정해야 한다. - 작업이 탐색 단계인지, 검토 단계인지 상태를 표시한다. - 현재 피드백을 받을 수 있는지 명시한다. - 필요한 피드백의 수준을 구체적으로 설명한다. 예를 들어 세부 디자인이 아닌 방향성에 대한 의견을 요청할 수 있다. - 상태 주석이나 진행 단계 표시를 활용하면 고객과 내부 팀이 작업물을 과도하게 해석하는 일을 줄일 수 있다. - 디자인은 계속 변하므로 문서가 프로젝트의 최신 상태를 반영하도록 지속적으로 관리해야 한다. ## 공개적인 대화와 이견 장려 - 신뢰는 일상적인 업무뿐 아니라 디자인 윤리, 기술의 역할, 제품이 사회에 미치는 영향 같은 큰 주제를 논의할 때도 필요하다. - 직급이나 역할과 관계없이 누구나 문제를 제기할 수 있는 환경을 만들어야 한다. - ‘Designated Dissenter’와 같은 활동은 한 명에게 의도적으로 반대 의견을 내는 역할을 맡겨 팀의 가정과 결정에 질문을 던지게 한다. - 이견을 제도화하면 특정 개인의 성격이나 직급에 의존하지 않고 다양한 관점을 끌어낼 수 있다. - 이러한 논의는 팀원 간 이해를 넓히고, 제품이 가져올 장기적·사회적 결과를 검토하는 데 도움을 준다. ## 신뢰를 만드는 협업 원칙 - 신뢰는 한 번의 워크숍이나 규칙만으로 생기지 않고 반복적인 상호작용을 통해 형성된다. - 팀원과 고객을 업무 역할이 아닌 사람으로 이해하려는 시간을 확보한다. - 파일과 문서에 작업 상태, 피드백 요청 범위, 최신 진행 상황을 명확히 기록한다. - 긍정적 의도를 전제로 하되, 불편한 의견과 반대 의견도 안전하게 제시할 수 있도록 한다. - 실무적인 협업 규칙과 윤리적 논의를 함께 운영해야 지속 가능한 디자인 문화를 만들 수 있다. 실제로는 프로젝트 시작 시 피드백 방식과 작업 상태 표기 규칙을 합의하고, 정기적으로 짧은 관계 형성 대화와 이견 토론을 운영하는 것이 가장 효과적이다.

원문 읽기(새 탭에서 열림)
Figma프로덕트 디자인real-time-collaborationdesign-collaboration+1
figma4분 읽기큐레이션 요약

코드와 디자인 사이의 긴

Figma는 디자인의 자유로운 탐색과 코드의 구조적·재사용 가능한 접근 사이의 긴장을 없애기보다 생산적인 협업 방식으로 받아들여야 한다고 주장한다. 이를 위해 디자인 시스템을 코드의 컴포넌트 구조와 가깝게 만들고, 디자이너와 개발자가 같은 시스템을 더 효율적으로 이해하고 활용할 수 있도록 Variants, Interactive Components, 개선된 Auto Layout, Inspect Tab 등을 발표했다. 궁극적으로 Figma는 디자인과 코드를 분리된 작업이 아니라 제품을 함께 만드는 연결된 과정으로 발전시키려 한다. ## 디자인과 코드 사이의 긴장 - 디자이너는 무엇을 만들지 결정하며 자유로운 시각적 탐색과 빠른 반복을 중시한다. - 개발자는 정해진 구조 안에서 실제 제품을 구현하며 재사용성, 일관성, 규칙을 중시한다. - 개발자에게 컴포넌트를 “깨는” 행위가 디자이너에게는 창의적인 실험일 수 있고, 개발자의 구조가 디자이너에게는 제약처럼 느껴질 수 있다. - Figma는 코드의 엄격성과 재사용성을 디자인에 적용하되, 디자인의 빠른 반복과 자유로운 탐색은 유지해야 한다고 본다. ## Variants로 코드와 디자인 컴포넌트 연결 - 프런트엔드의 하나의 컴포넌트는 상태와 맥락에 따라 여러 형태로 표현된다. - 예: 버튼의 기본형·보조형 - 작은 크기·큰 크기 - iOS·Android별 스타일 - 기존 Figma에서는 이런 변형을 각각 별도의 컴포넌트로 관리해야 해 코드 구조와 디자인 구조가 달라졌다. - **Variants**는 같은 컴포넌트의 여러 변형을 하나의 논리적 컴포넌트로 그룹화한다. - 이를 통해 에셋 패널을 단순화하고, 디자인 컴포넌트를 코드의 컴포넌트 모델에 더 가깝게 표현할 수 있다. - 발표 당시 2020년 11월 출시 예정으로 소개됐다. ## Interactive Components로 프로토타이핑 간소화 - Variants를 사용하면 버튼이나 입력 필드의 여러 상태를 하나로 묶을 수 있다. - 기존에는 상태 간 전환을 표현하려면 여러 프레임과 오버레이를 수동으로 연결해야 했다. - **Interactive Components**는 Variants 사이에 프로토타이핑 상호작용을 직접 설정할 수 있게 한다. - 컴포넌트 인스턴스를 프로토타이핑 모드에서 즉시 동작하는 요소처럼 사용할 수 있어, 반복적인 프레임 연결 작업을 줄인다. - 당시 2021년 1월 출시 예정으로 발표됐다. ## 코드처럼 설계하는 Auto Layout - Auto Layout은 텍스트가 바뀌어도 버튼이나 프레임 크기가 자동으로 조정되도록 해 반응형 UI 제작을 돕는다. - Figma는 Auto Layout을 웹의 CSS 박스 모델과 Flexbox에 더 가깝게 발전시키려 했다. - 개선 사항에는 다음이 포함된다. - 더 단순해진 사용자 인터페이스 - 가로·세로 양축에서 요소를 늘리는 기능 - 방향별로 독립적인 패딩 설정 - 내비게이션 아이콘처럼 자주 쓰이는 UI 패턴에 맞춘 간격 설정 - 디자이너가 수동으로 위치와 크기를 조정하는 대신, 코드의 레이아웃 규칙에 가까운 방식으로 디자인할 수 있게 하는 것이 목표다. ## 대규모 디자인 시스템을 위한 컴포넌트 탐색 - 수천 개의 컴포넌트를 사용하는 대규모 라이브러리에서는 정확한 이름을 기억하거나 긴 목록을 직접 찾아야 하는 불편이 있었다. - **Instance Swap Menu**가 개선되어 다음 기능을 제공한다. - 컴포넌트 썸네일 - 검색 - 키보드 단축키 - Variants와 함께 사용하면 여러 컴포넌트를 일일이 찾는 부담을 줄이고, 대규모 디자인 시스템에서도 적절한 인스턴스를 빠르게 교체할 수 있다. - 이 기능은 글 작성 당시 바로 사용할 수 있는 기능으로 소개됐다. ## Inspect Tab으로 개발자 전달 정보 강화 - 기존 Code 패널을 대체하는 **Inspect Tab**은 개발자가 구현에 필요한 정보를 더 쉽게 확인하도록 설계됐다. - 선택한 레이어의 이름을 상단에 표시해 디자이너와 개발자가 어떤 요소를 구현하는지 명확히 확인할 수 있다. - 다음과 같은 디자인 속성을 구분해 보여준다. - Variants - 색상 - 그림자 - 콘텐츠 - 타이포그래피 - 테두리 - 개별 값을 클릭해 클립보드로 복사할 수 있으며, 여러 `key:value` 값으로 구성된 코드 조각도 한 번에 복사할 수 있다. - 디자인 명세를 별도로 정리하거나 개발자가 값을 수동으로 옮기는 과정을 줄여 구현 전환을 효율화한다. Figma의 방향은 디자인을 코드처럼 획일화하는 것이 아니라, 코드의 구조성과 재사용성을 디자인 시스템에 도입하면서도 디자이너의 창의적 탐색을 보존하는 것이다. 실무에서는 Variants로 상태와 스타일을 체계화하고, Auto Layout으로 레이아웃 규칙을 정의하며, Inspect Tab을 통해 개발자에게 구현 정보를 명확히 전달하는 방식이 효과적이다.

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

피칭과 발표에 관하여

좋은 프레젠테이션은 화려한 시각 자료보다 청중에게 맞는 이야기와 명확한 메시지에서 출발한다. 발표자는 청중의 관심사와 문제를 이해한 뒤, 공감할 수 있는 문제를 제시하고 해결책과 행동 요청으로 이어지는 구조를 만들어야 한다. 또한 목소리, 몸짓, 감정 표현을 조절하고 발표 환경에 맞게 전달 방식을 다듬어야 한다. ## 스토리텔링이 발표를 설득력 있게 만드는 이유 - 발표의 목적은 정보 나열이 아니라 청중이 이해하고, 행동하고, 생각을 바꾸도록 돕는 것이다. - 글쓴이는 ‘Pet Rocks’ 피치에서 시장 통계와 제품 역사를 설명했지만, 우승팀은 앱과 마케팅 캠페인을 활용해 하나의 이야기를 만들었다. - 스토리텔링은 타고난 재능이 아니라 반복적인 연습으로 발전시킬 수 있는 기술이다. - 수업 발표, 팀 회의, 취업 면접, 투자 피치 등 다양한 상황에서 복잡한 아이디어를 명확하게 전달하는 데 유용하다. - 발표는 크게 다음 세 요소로 구성된다. - **Content**: 무엇을 말할 것인가 - **Delivery**: 어떻게 말할 것인가 - **Visuals**: 아이디어를 시각적으로 어떻게 보여줄 것인가 ## 청중의 신뢰를 얻는 콘텐츠 설계 - 발표를 준비하기 전에 청중을 파악해야 한다. - 다음 질문을 통해 청중의 관점과 기대를 분석한다. - 청중은 무엇을 중요하게 생각하는가? - 어떤 문제, 필요, 목표를 가지고 있는가? - 왜 이 발표를 듣고 있는가? - 발표를 통해 무엇을 얻을 수 있는가? - 어떤 업계 용어와 커뮤니케이션 방식을 사용하는가? - 청중이 “발표자가 우리의 상황을 이해하고 있다”고 느껴야 발표 내용에 신뢰를 갖는다. - 시각 자료와 발표 스타일은 중요하지만, 궁극적으로는 전달하려는 이야기를 뒷받침하는 역할을 해야 한다. ## 문제에서 해결책으로 이어지는 이야기 구조 - 발표의 중심에는 청중과 관련된 이야기가 있어야 한다. - 효과적인 기본 구조는 다음과 같다. 1. 청중과 상황을 조사한다. 2. 청중이 공감할 수 있는 문제를 정의한다. 3. 문제를 해결하는 해결책을 소개한다. 4. 해결책이 어떻게 작동하고 문제를 어떻게 개선하는지 설명한다. 5. 청중에게 구체적인 행동을 요청한다. - 문제 정의에는 다음 문장 구조를 활용할 수 있다. - “**[이해관계자]**는 **[과업]**에 대해 **[감정]**을 느끼며 **[행동]**해야 하지만, **[장애물]**에 직면해 있다.” - 해결책을 설명할 때 문제 정의에서 사용한 표현이나 사례를 다시 활용하면 이야기의 일관성과 기억하기 쉬운 흐름을 만들 수 있다. - 발표의 마지막에는 CTA(Call-To-Action)를 포함한다. - 프로젝트를 추가 검토하도록 승인 요청 - 자금 지원 요청 - 멘토링 요청 - 특정 관점이나 행동의 변화 요청 ## 목소리와 몸짓으로 감정 전달하기 - 같은 슬라이드라도 목소리의 높낮이, 표정, 자세, 움직임에 따라 설득력이 크게 달라진다. - 자신의 발표를 녹음해 들어보면 말투, 억양, 속도에서 개선할 점을 발견할 수 있다. - 발표 전에는 몸을 움직이거나 자세를 바로잡는 등 자신감을 높이는 준비가 도움이 된다. - 발표 중에는 다음과 같은 표현을 활용한다. - 중요한 부분에서 목소리를 높이거나 속도를 조절한다. - 손동작과 자연스러운 이동으로 메시지를 강조한다. - 핵심 내용을 말할 때 몸을 약간 앞으로 기울인다. - 청중과 눈을 맞춘다. - 발표자의 진짜 감정은 청중에게 전달된다. 발표자가 주제에 열정을 보이면 청중도 더 쉽게 몰입한다. - 청중의 눈맞춤과 몸짓을 관찰하며 발표 방식을 조정해야 한다. - 집중력이 떨어져 보이면 이동 범위를 넓힌다. - 목소리를 조금 키운다. - 청중의 여러 사람과 시선을 나눈다. ## 온라인 발표에 맞춘 전달 방식 조정 - 원격 발표에서는 기술적 문제뿐 아니라 평소의 억양과 손동작이 화면을 통해 충분히 전달되지 않을 수 있다. - 온라인 발표를 준비할 때도 자신의 목소리를 녹음해 청중이 듣는 방식과 실제 인상을 점검하는 것이 좋다. - 대면 발표에서 자연스럽던 표현이 가상 환경에서는 약하게 보일 수 있으므로, 목소리와 표정, 화면 안에서의 움직임을 의식적으로 조정해야 한다. 발표를 준비할 때는 먼저 청중과 문제를 정의하고, 문제-해결책-행동 요청의 흐름을 만든 뒤, 녹음과 리허설로 전달 방식을 점검하는 것이 좋다. 멋진 슬라이드보다 청중이 공감할 수 있는 이야기와 분명한 다음 행동이 발표의 성패를 좌우한다.

원문 읽기(새 탭에서 열림)
Figmapresentation-designstorytellingdesign-strategy+2
figma3분 읽기큐레이션 요약

피그마의 새로운 EMEA 본

Figma는 EMEA 지역 사용자를 더 잘 지원하기 위해 런던에 지역 본부(HQ)를 열기로 했다. 이 사무실은 단순한 물리적 공간이 아니라, 현지 사용자와 같은 시간대를 공유하고 다양한 인재를 확보하며 지역별 디자인 커뮤니티를 이해하기 위한 거점이다. 코로나19로 대면 업무가 지연된 상황에서도 하이브리드 근무와 온라인 행사로 지역 협력을 이어가겠다는 것이 글의 결론이다. ## 런던 EMEA 본부 설립 배경 - Figma는 미국 외 지역의 사용자가 매우 많은 글로벌 서비스다. - 2020년 기준 주간 활성 사용자의 **81%가 미국 외 지역**에 있었다. - 기존의 미국 중심 시간대 운영만으로는 EMEA 지역 사용자에게 충분한 지원을 제공하기 어려웠다. - 이에 따라 유럽·중동·아프리카 지역을 전담하는 런던 허브 오피스를 설립하기로 했다. ## 사무실 이상의 역할 - 런던 오피스는 단순히 직원이 출근하는 공간이 아니라 지역 사업과 커뮤니티를 연결하는 거점이다. - 주요 목적은 다음과 같다. - EMEA 사용자와 더 많은 시간을 공유해 지원 대응력을 높임 - 현지의 다양한 인재를 채용 - 지역별 업무 문화와 사용자 요구를 직접 이해 - 각국의 디자인 커뮤니티 및 기업 고객과 긴밀히 협력 - Figma는 하이브리드 근무를 추진하고 있어, 원격 근무와 대면 근무를 함께 지원하는 허브 형태를 지향했다. ## 글로벌 사용자와 현지 커뮤니티의 중요성 - 창업자는 Figma 출시 이후 여러 국가의 사용자와 커뮤니티를 직접 만나며 제품에 대한 통찰을 얻었다. - 런던, 파리, 헬싱키, 키이우, 모스크바, 자카르타, 싱가포르 등 다양한 도시의 고객을 방문했다. - Deliveroo, Zalando, Spotify, Booking.com과 같은 기업 고객과 협력하며 EMEA 지역의 성장 가능성을 확인했다. - 사용자와 직접 교류하는 과정은 제품 개선뿐 아니라 지역별 요구와 디자인 생태계를 파악하는 데 중요한 역할을 했다. ## 유럽 지역 팀 확장 - Figma는 2019년 초 암스테르담에 제품 전문가 팀을 채용하며 유럽 내 지원을 강화했다. - 이후 런던 지역 팀을 별도로 구축하기로 결정했다. - 발표 당시 런던 지역에는 **14명의 팀원**이 원격으로 근무하고 있었다. - 향후 런던 팀과 본부를 중심으로 EMEA 사용자 및 기업 고객과의 협력을 확대할 계획이었다. ## 코로나19와 온라인 전환 - 코로나19로 인해 새 사무실을 즉시 대면 업무에 활용하거나 개장 행사를 열 수 없었다. - Figma는 안전하게 대면 근무를 재개할 수 있을 때 공식적으로 오피스를 열 예정이라고 밝혔다. - 그동안에는 온라인 방식으로 지역 커뮤니티와의 연결을 유지하기 위해 첫 가상 사용자 콘퍼런스인 **Config Europe**을 개최하기로 했다. - 이는 물리적 사무실이 준비되지 않은 상황에서도 지식 공유와 커뮤니티 형성을 이어가는 대안이었다. 지역 확장을 추진하는 기업이라면 사무실 개설 자체보다 시간대 지원, 현지 인재 채용, 고객과의 직접 교류, 온라인 커뮤니티 운영을 함께 설계해야 한다. Figma의 사례는 하이브리드 근무 환경에서도 지역별 거점을 활용해 글로벌 사용자 지원을 강화할 수 있음을 보여준다.

원문 읽기(새 탭에서 열림)
Figmacollaborationdesign-toolsweb-design+2
figma3분 읽기큐레이션 요약

온라인 쇼핑객을 위해 디자인

Design Within Reach(DWR)는 온라인에서도 오프라인 쇼룸과 유사한 개인화된 구매 경험을 제공하기 위해 웹사이트를 전면 개편했다. DWR과 BASIC®은 Figma를 활용해 하나의 팀처럼 실시간 협업하고, 110시간의 고객 조사와 200명 이상의 사용자 테스트를 통해 제품 탐색과 상담 경험을 개선했다. 그 결과 라이브 채팅 이용자의 구매 가능성이 9배 높아졌으며, 여러 Herman Miller 브랜드로 확장 가능한 디자인 시스템도 구축했다. ### 투명한 에이전시 협업과 실시간 공동 작업 - DWR과 BASIC®은 업무를 분리하기보다 공동 창작을 중심으로 하나의 통합된 팀처럼 운영했다. - 서로 다른 회사와 시간대에서 일하는 디자이너들이 같은 Figma 파일에 동시에 접근해 작업했다. - 파일을 복사하거나 최신 버전을 전달하고 링크를 갱신하는 과정이 사라져 협업 효율이 높아졌다. - 시간대 차이를 활용해 한 팀이 작업을 마치면 다른 팀이 이어받는 방식으로 사실상 하루 14시간의 연속 작업이 가능했다. - CEO와 경영진도 Figma 프로토타입 링크를 통해 진행 상황을 쉽게 확인하고 의사결정에 참여할 수 있었다. ### 오프라인 쇼룸 경험의 온라인 구현 - 웹사이트 개편의 목표는 고객이 온라인에서 가구를 구매할 때 생기는 주요 질문에 답하고, 실제 쇼룸 방문에 가까운 경험을 제공하는 것이었다. - 총 110시간의 고객 조사와 200명 이상의 참가자를 대상으로 한 심층 사용자 테스트를 진행했다. - Figma 프로토타입을 실제 웹사이트처럼 제작해 사용성 테스트, 빠른 반복 수정, 즉각적인 인사이트 수집을 수행했다. - 2020년 7월 새 사이트를 출시했으며, 다양한 화면에 대응하는 반응형 디자인과 영업 담당자와 연결되는 영상·라이브 채팅 기능을 도입했다. - 라이브 채팅을 이용한 방문자는 그렇지 않은 방문자보다 온라인 구매 가능성이 9배 높았다. - 일반적으로 대규모 웹사이트 출시 직후에는 구매가 일시적으로 감소할 수 있지만, DWR은 출시 직후부터 구매 증가를 경험했다. ### 여러 브랜드로 확장되는 디자인 시스템 - DWR 웹사이트 개편을 계기로 Herman Miller 전체 브랜드를 위한 첫 디자인 시스템을 만들었다. - 공통 컴포넌트와 공유된 시각 언어를 기반으로 장기적으로 확장 가능한 구조를 설계했다. - 개발자는 반복 가능한 컴포넌트를 더 빠르게 구현할 수 있게 됐다. - 콘텐츠 작성자는 미리 제작된 컴포넌트를 드래그하고 이미지와 텍스트만 수정해 페이지를 직접 구성할 수 있게 됐다. - Figma의 클라우드 기반 에셋 라이브러리를 통해 내부 팀과 전 세계 외부 파트너가 디자인 자산과 시스템을 쉽게 공유할 수 있다. - DWR의 컴포넌트 라이브러리는 향후 Herman Miller의 다른 전자상거래 사이트에도 적용될 기반이 됐다. ### 실용적인 시사점 온라인 쇼핑 경험을 개선하려면 단순히 시각적으로 아름다운 사이트를 만드는 것보다 고객 조사, 실제 프로토타입 테스트, 실시간 협업을 하나의 흐름으로 연결해야 한다. 또한 반복 가능한 컴포넌트와 공통 디자인 언어를 디자인 시스템으로 정리하면 개발 속도와 콘텐츠 운영 효율을 높이면서 여러 브랜드와 채널로 일관되게 확장할 수 있다.

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

멀티 브랜드 디자인 시스템 구축

멀티 브랜드 디자인 시스템은 일관성과 효율성을 제공하되, 엄격한 규칙보다 유연성을 중심으로 설계해야 한다. 기본 컴포넌트와 브랜드별 토큰, 코드 연계를 통해 다양한 요구를 수용하고 빠르게 확장할 수 있다. 또한 디자인 시스템은 완성된 산출물이 아니라 실제 사용 데이터를 관찰하며 계속 발전시키는 살아 있는 시스템이어야 한다. ## 유연성을 우선하는 설계 - 디자인 시스템을 지나치게 규정적으로 운영하면 디자이너의 창의성을 제한하고, 결국 시스템 밖에서 작업하게 만들 수 있다. - Harry’s는 복잡도와 유연성이 서로 다른 여러 계층으로 시스템을 구성했다. - 기본 컴포넌트: 단순하고 표준화된 구성 - 스타터 키트: 더 복잡하고 유연한 구성 - 대부분의 프로젝트는 단순한 계층으로 해결하되, 특수한 요구에는 커스텀 구성을 허용한다. - 기본값은 단순하게 유지하면서도 예외를 수용하면 효율성과 창의성을 동시에 확보할 수 있다. ## 토큰을 활용한 멀티 브랜드 확장 - Condé Nast처럼 여러 브랜드를 운영하는 조직에서는 브랜드마다 다른 시각적 특성을 수용해야 한다. - 모듈화된 컴포넌트와 디자인 토큰을 사용하면 동일한 구조를 유지하면서 브랜드별 값을 적용할 수 있다. - 하나의 토큰이 브랜드마다 다른 값을 가질 수 있다. - 예: `prominent text`라는 토큰에 Vogue, The New Yorker, Bon Appétit별 폰트를 각각 지정 - 이런 방식은 컴포넌트를 브랜드별로 별도 제작하지 않고도 시스템을 확장하게 해준다. ## 계속 진화하는 디자인 시스템 - 시스템을 구축한 뒤에도 실제 사용 과정에서 무엇이 잘 작동하고 실패하는지 관찰해야 한다. - Shopify는 디자인 시스템을 “휘어지지만 부러지지 않는” 기반으로 만든다는 방향을 취한다. - 디자인 시스템을 박물관의 전시물처럼 보존하려 하면 변화하는 요구사항을 반영할 수 없다. - 디자이너뿐 아니라 최종 사용자도 관찰해야 한다. - Shopify의 경우 상점 운영자인 머천트가 시스템의 실제 사용자인 만큼, 사용 중 어디서 문제가 발생하는지 확인한다. - 컴포넌트 사용량, 라이브러리 활용 추세 등의 데이터를 분석하면 개선 우선순위를 정할 수 있다. - 시스템이 어떻게 실패하는지 확인하고 이를 바탕으로 다시 설계하는 과정이 중요하다. ## 디자인과 코드의 연결 - 디자인 컴포넌트를 코드로 연결하면 디자인과 개발 간의 전달 비용을 줄이고 구현 속도를 높일 수 있다. - Condé Nast는 JavaScript 기반 사이트에서 JSON으로 토큰을 정의한다. - 커스텀 플러그인을 통해 토큰 값을 JSON으로 가져오거나 내보내 디자인과 코드의 변경 사항을 동기화한다. - 토큰 기반 구조는 새로운 시장이나 브랜드를 빠르게 구축하고 디자이너와 엔지니어 간의 핸드오프를 원활하게 한다. - 멀티 브랜드 환경이 아니더라도 색상이나 타이포그래피에 목적과 값을 연결하는 것부터 시작할 수 있다. - 예: 특정 색상을 직접 `#000000`으로 부르기보다 `text-primary`처럼 용도 중심으로 명명 - 목적과 값을 분리하면 시스템의 복잡도와 불필요한 세분화를 파악하기 쉬워진다. ## 조직에 맞는 시스템 구축 - 모든 조직에 동일하게 적용되는 디자인 시스템은 없다. - 팀 규모, 조직 구조, 브랜드 수, 개발 환경, 업무 우선순위에 맞춰 범위와 복잡도를 결정해야 한다. - 처음부터 거대한 시스템을 만들기보다 현재 반복적으로 사용되는 패턴과 컴포넌트부터 정리하는 것이 현실적이다. - 시스템의 규칙보다 실제 팀이 쉽게 사용하고 변경할 수 있는 프로세스를 만드는 것이 더 중요하다. 실무에서는 기본 컴포넌트와 목적 기반 토큰부터 시작하고, 브랜드별 차이는 토큰 값으로 관리하는 방식을 추천한다. 이후 사용 데이터와 사용자 피드백을 바탕으로 시스템을 지속적으로 수정하되, 예외와 실험을 허용해 시스템 밖으로 이탈할 필요가 없도록 해야 한다.

원문 읽기(새 탭에서 열림)
디자인 시스템JavaScript디자인 토큰웹 개발+2
figma3분 읽기큐레이션 요약

Inside Figma: 엔터프라이즈

Figma의 엔터프라이즈 제품은 고객 요청을 그대로 구현하는 데 그치지 않고, 다양한 규모와 역할의 조직이 지속적으로 사용할 수 있는 기반을 만드는 것을 목표로 한다. 이를 위해 Figma는 관리자와 최종 사용자의 업무를 함께 이해하고, 영업·지원·마케팅·디자인·엔지니어링 등 여러 팀과 협력해 Admin Settings를 전면적으로 재설계했다. 결론적으로 엔터프라이즈 기능의 핵심은 개별 기능 추가보다 확장 가능한 구조와 중요한 관리 업무에 최적화된 사용자 경험이다. ## 엔터프라이즈 제품의 역할 - Figma의 엔터프라이즈 팀은 조직 관리자가 다음 업무를 수행할 수 있도록 도구를 개발한다. - 조직 계정 관리 - 디자이너·개발자·협업자의 접근 권한 관리 - 조직 내 사용 현황과 리소스 관리 - 제품 개발 과정에서 잠재 고객과의 영업 통화, 기존 고객 인터뷰, 지원팀 피드백 등을 적극적으로 활용한다. - 고객 요구를 단순히 받아 적는 것이 아니라, 여러 고객과 조직에 공통적으로 적용될 수 있는 문제를 파악하는 데 초점을 둔다. ## 기존 Admin Settings가 가진 한계 - Figma Organization 출시 후 사용자가 크게 늘면서 관리자 업무의 범위가 넓어졌다. - 초기 Admin Settings는 어떤 기능이 관리자에게 가장 중요한지 충분히 알기 전에 설계된 화면이었다. - 고객·지원·영업팀과의 대화를 통해 다음 문제가 드러났다. - 관리자가 조직의 의사결정에 필요한 정보를 충분히 얻기 어려움 - 자신에게 유용한 기능이 무엇인지 알기 어려움 - 필요한 정보를 수동으로 내보내야 함 - 개별 기능 자체보다, 기능을 발견하고 활용하는 전체 관리 화면의 구조가 문제였다. ## 처음부터 다시 설계한 브레인스토밍 - 팀은 기존 화면을 조금 수정하는 대신 관리자 경험을 처음부터 재구성하기로 했다. - 주요 목표는 다음과 같았다. - 구성원 관리 워크플로 개선 - 기존 기능의 노출과 활용도 향상 - 향후 새 기능을 쉽게 추가할 수 있는 구조 마련 - 아이디어를 다음 세 범주로 나누어 논의했다. - 지금 실행할 항목 - 검토할 가치가 있는 항목 - 과감하고 실험적인 항목 - PM, 엔지니어링 매니저, 디자이너, 엔지니어뿐 아니라 리서치·데이터·지원·마케팅·영업팀도 참여했다. - 각 팀의 제안을 사용자 피드백과 연결해 공통 주제를 도출하고, 우선순위가 높은 항목을 정리했다. ## 단순한 UI 개선이 아닌 제품 개편 - 처음에는 기존 Admin Settings에 새로운 화면과 옵션을 추가하는 정도로 생각했다. - 그러나 영업팀과 함께 관리자들의 실제 불편을 분석하면서 문제가 특정 화면이나 기능에 국한되지 않았음을 확인했다. - 기존 설계 위에 기능을 계속 덧붙이면 단기적으로는 개선할 수 있어도, 다음 문제가 반복될 수 있었다. - 핵심 업무 흐름이 복잡해짐 - 기능 간 연결성이 약해짐 - 새로운 기능을 추가하기 어려워짐 - 따라서 문제의 증상만 고치는 대신, 관리자의 주요 워크플로를 중심으로 전체 제품 경험을 재설계하는 방향을 택했다. ## 다양한 규모의 조직을 위한 확장성 - Figma는 특정 규모 이상의 기업만 대상으로 하는 제품이 아니라, 5명 규모의 팀부터 5,000명 규모의 조직까지 지원해야 한다. - 작은 조직에서는 한 사람이 관리자, 디자인 운영 담당자, 실무 디자이너 역할을 동시에 맡을 수 있다. - 대기업에서는 예산 책임자, 디자인 운영팀, 보안팀, 개별 사용자가 서로 다른 목표와 요구를 가진다. - 경영진·예산 담당자: 조직 전체에서 제품이 제공하는 가치를 파악 - 디자인 운영 담당자: 필요한 권한과 리소스 접근을 보장 - 보안팀: 조직 데이터가 안전하게 보호되는지 확인 - 일반 사용자: 일상적인 업무를 효율적으로 수행 - 따라서 엔터프라이즈 도구는 특정 사용자 유형에만 맞추기보다, 조직 내 다양한 역할과 의사결정 구조를 수용할 수 있어야 한다. - 관리자 화면은 일반 사용자에게는 부수적인 기능처럼 보일 수 있지만, 관리자에게는 매일의 운영을 책임지는 핵심 업무 공간이다. ## 실용적인 결론 엔터프라이즈 제품을 설계할 때는 고객의 최신 요청을 개별적으로 처리하기보다, 여러 조직에서 반복되는 문제와 업무 흐름을 찾아야 한다. 특히 조직 규모와 사용자 역할이 다양하다면 단기적인 UI 수정보다 확장 가능한 정보 구조와 관리 워크플로를 먼저 설계하는 것이 장기적으로 더 효과적이다.

원문 읽기(새 탭에서 열림)
Figma사용자 경험프로덕트 디자인enterprise-software+2
figma3분 읽기큐레이션 요약

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
figma4분 읽기큐레이션 요약

쇼피파이에서 협업을

Shopify는 Figma 파일을 팀 간 협업의 공용 작업 공간으로 활용하기 위해, 프로젝트 상태와 산출물을 일정한 구조로 정리하는 템플릿을 사용한다. 이 템플릿은 GSD(Get Sh*t Done)의 **Think–Explore–Build** 프로세스를 기반으로 하며, 실제로 구현할 결과물을 가장 앞에 배치해 필요한 정보를 빠르게 찾도록 설계됐다. 핵심은 파일마다 예측 가능한 구조와 상태 표시를 적용해 디자인·제품·엔지니어링 팀의 커뮤니케이션 비용을 줄이는 것이다. ## 일관된 파일 구조가 필요한 이유 - Figma는 협업을 쉽게 만들지만, 시간이 지나면서 파일과 산출물이 많아지면 다음과 같은 문제가 생긴다. - 어떤 디자인이 최신인지 파악하기 어렵다. - 특정 레이아웃이 승인됐는지 알기 어렵다. - 실제 구현 대상과 사용자 테스트용 프로토타입을 구분하기 어렵다. - 제품 관리자, 엔지니어, 다른 디자이너가 필요한 정보를 찾기 어렵다. - Shopify는 팀마다 다른 파일 정리 방식을 사용하는 문제를 해결하기 위해 공통 템플릿을 만들었다. - 일정한 형식은 여러 팀이 파일을 탐색할 때 기대할 수 있는 공통 규칙을 제공하고, 프로젝트 초기 설정 시간도 줄여준다. ## GSD 프로세스와 템플릿의 페이지 순서 - Shopify의 GSD 프레임워크는 세 단계로 구성된다. - **Think**: 문제와 배경을 이해한다. - **Explore**: 다양한 해결책을 탐색한다. - **Build**: 선택한 해결책을 구체화하고 출시한다. - 템플릿의 페이지는 이 순서와 반대로 구성된다. - 가장 중요한 구현 준비 상태의 결과물을 파일 앞부분에 둔다. - 사용자가 파일을 열었을 때 최근 작업과 실행 가능한 결과를 먼저 확인할 수 있다. - 새 파일을 만들 때는 표지와 프로젝트 개요를 먼저 작성한 뒤, Think 섹션의 정보를 채우는 방식으로 시작한다. - Explore 단계에서는 필요한 만큼 페이지를 만들고 자유롭게 실험한다. - Build 단계에 들어가면 Explore에서 선택된 페이지나 레이아웃을 Build 섹션으로 이동한다. ## 표지: 프로젝트의 현재 상태를 한눈에 표시 - 새 Figma 파일을 만들 때 표지를 먼저 구성한다. - 표지에는 다음과 같은 정보를 담는다. - 프로젝트명 - 담당 팀 - 프로젝트 상태 - Figma 프로젝트의 그리드 보기에서도 파일을 쉽게 식별할 수 있다. - 프로젝트가 진행될 때마다 상태 표시를 갱신해야 현재 단계가 혼동되지 않는다. ## 프로젝트 개요: 배경과 담당자 연결 - 개요 페이지에는 프로젝트를 이해하는 데 필요한 추가 정보를 제공한다. - 포함할 수 있는 내용은 다음과 같다. - 관련 문서와 리서치 링크 - 프로젝트 브리프 - 피드백을 줄 담당자 - 질문이나 문의를 전달할 연락처 - 필요에 따라 섹션과 항목을 추가하거나 삭제할 수 있다. - Figma 문서에 문서 링크나 Slack 프로필 링크를 붙여 넣으면 관련 앱을 바로 열 수 있어 탐색 과정이 단순해진다. ## Think: 문제 공간과 프로젝트 기반 정리 - Think 섹션은 탐색을 시작하기 전에 문제와 맥락을 정리하는 공간이다. - 다음과 같은 자료를 모을 수 있다. - 사용자 플로우 - 고객 여정 지도 - 잡 스토리(job story) - 디자인 스프린트 결과물 - 과거 디자인이나 영감을 위한 스크린샷 - 관련 외부 문서 링크 - 이 단계의 목적은 해결책을 바로 결정하는 것이 아니라, 탐색에 필요한 정보를 한곳에 모아 프로젝트의 기반을 만드는 것이다. ## Explore: 다양한 아이디어를 실험하고 피드백 수집 - Explore는 여러 해결책을 넓고 깊게 시도하는 작업 공간이다. - 협업과 댓글, 피드백이 가장 활발하게 발생하는 영역으로 활용한다. - 효과적인 정리를 위해 다음 규칙을 적용할 수 있다. - 태블릿·모바일처럼 기기나 화면 형태가 다르면 별도 페이지로 나눈다. - 탐색 결과와 사용자 플로우에 제목을 붙여 내용을 명확히 한다. - 진행 상태를 나타내는 배지를 추가한다. - 새 페이지마다 날짜를 기록해 최신 작업인지 확인할 수 있게 한다. - 사용자 테스트용 프로토타입은 별도 페이지로 관리한다. - 스티키 노트로 메모, 아이디어, 피드백, 후속 작업을 기록한다. - 이 단계에서는 가능한 접근법을 많이 시도한 뒤, 피드백을 바탕으로 구현할 방향을 좁혀 간다. ## Build: 선택된 결과물을 구현 단계로 이동 - Build는 탐색을 마친 뒤 적절한 해결책을 구체화하고 출시 및 피드백으로 연결하는 단계다. - Explore에서 검토한 여러 시안 중 실제로 진행할 페이지나 레이아웃만 Build 섹션으로 이동한다. - 이를 통해 실험 중인 아이디어와 구현 대상으로 확정된 결과물을 명확히 분리할 수 있다. - 파일 앞부분에 Build 관련 결과물이 배치되므로 다른 직군도 현재 구현 대상과 프로젝트 진행 상황을 빠르게 파악할 수 있다. 팀 단위로 Figma를 운영한다면 표지, 개요, Think–Explore–Build 섹션을 기본 템플릿으로 정하고, 날짜·상태 배지·담당자·관련 링크를 의무적으로 기록하는 방식이 실용적이다. 특히 Explore의 자유로운 실험 공간과 Build의 확정 산출물을 분리하면 최신 디자인과 구현 대상을 찾는 데 드는 커뮤니케이션 비용을 크게 줄일 수 있다.

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

나의 갭 이어에 관한

코로나19로 대학의 가을학기가 원격 수업으로 전환되면서, USC 학생 Abigail Africa는 졸업반 진학과 갭이어 사이에서 고민한다. 그녀는 학교 공동체와 실습 중심 교육을 제대로 경험할 수 있을 때 복귀하고, 그동안에는 일하며 저축과 스타트업 경험을 쌓는 방안을 고려한다. 그러나 가족에게 교육은 성공을 위한 필수 경로였고, 갭이어가 결국 학위 포기로 이어질 수 있다는 우려 때문에 선택은 개인적·경제적 문제를 넘어 문화적 정체성의 문제로 확장된다. ### 코로나19가 바꾼 대학 생활 - 학생들은 기숙사와 캠퍼스 공동체, 메이커스페이스에서의 협업, 하드웨어·팟캐스트·영상 제작 같은 실습 경험을 잃을 가능성이 커졌다. - 일부 학생은 부모의 집에서 온라인 수업을 듣고, 장학금이 없는 학생들은 Zoom으로 제공되는 교육에 등록금을 내는 상황에 불만을 느낀다. - 유학생은 비자 문제 때문에 선택의 여지가 적고, 일부 학생은 이미 집세를 내고 있다는 이유로 학교 주변에 남으려 한다. - 학교가 “유연한 태도”를 요구하지만, 화자는 오랫동안 계획해 온 졸업반 프로젝트와 캠퍼스 활동을 포기하기 어려워한다. ### 갭이어를 고려한 세 가지 이유 - 학교의 커뮤니티와 수업, 과외활동에 충분히 투자할 수 있는 시기에 복학하고 싶다. - 팬데믹 중에도 의미 있는 일자리를 얻을 수 있다면, 1년간 일해 저축을 늘리고 이후 학업과 생활비 부담을 줄일 수 있다. - 장래에 직접 스타트업을 운영하고 싶다면, 스타트업에서 더 오래 일하며 실제 운영 경험을 쌓는 것이 도움이 된다. - 반면 갭이어를 선택하면 학교로 돌아가지 않거나 학위를 끝내지 않을 가능성이 커질 수 있다는 가족의 우려도 타당하다. ### 가족이 바라보는 교육과 성공 - 부모와 조부모 세대에게 교육은 선택지가 아니라 성공에 이르는 가장 확실한 사다리였다. - 이민자였던 조부모들은 미국에서 여러 최저임금 일자리를 전전하며 자녀의 대학 교육을 지원했다. - 화자의 부모 역시 여행이나 소비보다 교육비를 우선시했고, 화자는 전액 성적 장학금으로 USC에 진학했다. - 따라서 화자에게 시간 off는 새로운 가능성이지만, 가족에게는 이미 거의 도달한 학위를 포기할 위험으로 받아들여진다. - 친구들과의 논의에서는 교육비, 취업 전망, 사회적 관계, 학위의 가치뿐 아니라 유색인종 여성으로서 이러한 선택이 어떻게 다르게 작용하는지도 중요한 쟁점이 된다. ### 실리콘밸리의 ‘중퇴 신화’와 대표성 - 기술 업계에는 대학을 중퇴하고 성공한 창업자, 특히 아이비리그 출신 남성 창업자를 이상화하는 문화가 있다. - 화자는 그 신화 속에서 자신과 같은 배경의 사람을 충분히 보지 못했다고 느낀다. - 현재 인턴 중인 스타트업에서 능력과 성과를 인정받으며, 학위를 마치지 않아도 자신에게 맞는 일과 고용주를 만날 수 있다는 가능성을 발견한다. - 그러나 실력만으로 평가받는다는 믿음은 대표성, 특권, 기회 접근성 같은 사회적 조건과 얽혀 있어 완전히 단순하지 않다는 점도 인식한다. 결국 글은 갭이어를 무조건 권하거나 반대하기보다, 학위의 가치와 개인의 성장 기회, 경제적 현실, 가족의 기대, 인종과 성별에 따른 사회적 조건을 함께 따져야 한다고 말한다. 갭이어를 선택한다면 복학 시점과 재정 계획, 일의 목표를 구체화해 ‘중단’이 아니라 의도적인 학습·경험의 기간으로 설계하는 것이 중요하다.

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

Figma에서 일하는 방식

Figma는 코로나19 이후 사무실 중심 근무에서 벗어나 대면 근무와 원격 근무를 결합한 하이브리드 모델로 전환하기로 했다. 회사는 불확실성이 해소될 때까지 기다리기보다 직원 설문과 기업 가치에 기반해 장기적인 근무 정책을 먼저 결정했다. 설문 결과 직원들은 유연성을 원하면서도 사무실의 연결감과 우연한 협업 기회를 중요하게 여겼고, 이에 따라 예측 가능한 출근 방식이 필요하다는 결론을 내렸다. ## 코로나19가 바꾼 업무 환경 - 코로나19로 도시의 네트워크 효과가 약해지면서 많은 사람들이 비싼 임대료를 줄이거나 가족과 가까워지기 위해 다른 지역으로 이동하기 시작했다. - Figma는 기존의 대면 중심 근무 방식이 코로나19 이후에도 적합할지 재검토했다. - 사무실 재개방 문제와 장기적인 근무 방식은 서로 다른 의사결정이라고 보고, 먼저 미래의 workplace 정책부터 정하기로 했다. ## 불확실한 상황에서의 의사결정 - 리더십 내부에서도 원격 근무 정책을 어떻게 바꿀지 의견이 나뉘어 있었다. - 다른 기업의 결정을 지켜본 뒤 따라가는 대신, 직원들의 불안을 줄이고 조직 문화를 최적화하기 위해 선제적으로 방향을 정했다. - “Be Bold”라는 회사 가치에 따라 어렵더라도 의미 있는 결정을 직접 내리는 것을 택했다. - 직원의 실제 선호를 파악하기 위해 People 조직과 함께 맞춤형 설문을 설계했다. - 설문에는 다음과 같은 정량·정성 질문을 함께 포함했다. - 통근 습관 - 코로나19 기간의 생산성 - 원격 근무 선호도 - 유연한 근무 일정의 의미 - 거주지와 이사 계획 - 단순한 다수결이 아니라 자유 서술 답변과 개인적인 이야기를 함께 수집해 직원들의 맥락을 이해하려 했다. ## 설문에서 드러난 직원들의 상반된 요구 - 설문은 일주일 동안 진행됐지만 직원의 90% 이상이 응답했다. - 직원들의 의견은 특정 선택지로 거의 수렴하지 않았으며, “유연한 일정”이라는 말조차 사람마다 다르게 해석했다. - 샌프란시스코 거주 직원 중 거의 절반은 주당 여러 날 재택근무가 가능하다면 통근 가능한 다른 도시로 이주할 의향을 보였다. - 약 3분의 2는 모든 직무에 원격근무 선택권이 주어진다면 2022년 말 이전에 비거점 지역으로 이동할 수 있다고 답했다. - 원격근무와 이주를 원하는 이유로는 다음이 언급됐다. - 낮은 생활비 - 주택 소유 가능성 - 가족과 가까이 지내고 싶은 욕구 - 반면 많은 직원은 사무실을 좋아하고, 사무실이 제공하던 연결감과 우연한 만남을 그리워했다. - 업무 생산성 자체는 높게 평가했지만, 핵심 팀 외부의 동료와 관계를 맺기 어렵고 신규 입사자를 알지 못할 수 있다는 불안도 컸다. ## 하이브리드 기업에서 얻은 교훈 Figma는 설문 결과를 검증하기 위해 하이브리드 근무를 운영하는 여러 기업과 대화했다. - **사람을 찾을 수 있는 위치가 예측 가능해야 한다** - 직원들이 함께 일하는 사람을 언제, 어디서 만날 수 있는지 명확히 알 수 있어야 한다. - **출근일을 어느 정도 맞춰야 한다** - 완전히 자유로운 재택 일정은 사람들이 서로 다른 날에 출근하게 만들 수 있다. - 그 결과 사무실이 비어 있는 “유령 도시”처럼 변하고, 대면 근무의 연결감과 우연한 협업 기회가 사라질 수 있다. - **하이브리드 모델은 운영이 어렵다** - 특히 사무실에 있는 직원과 원격 직원 사이의 정보 격차와 참여 격차를 줄이는 것이 주요 과제다. ## Figma가 선택한 하이브리드 정책 - 직원은 허브 오피스에 소속될지, 완전 원격 직원으로 일할지 선택해야 한다. - 샌프란시스코 허브는 유연한 근무 모델을 적용하되, 사무실 소속 직원은 주 2일 이상 출근하도록 했다. - 출근일은 직원마다 제각각 정하는 것이 아니라 모두가 같은 특정 요일에 출근하도록 해 만남과 협업의 가능성을 높이려 했다. - 이 방식은 직원에게 원격근무의 유연성을 제공하면서도, 사무실의 사회적 연결과 예측 가능성을 유지하려는 절충안이다. 회사가 하이브리드 근무를 도입할 때는 단순히 “재택근무를 허용할 것인가”를 묻기보다, 직원 선호·조직 문화·협업 방식·사무실 출근 패턴을 함께 설계해야 한다. 특히 완전한 자유보다 사람들이 서로 만날 수 있는 일정과 위치에 대한 명확한 규칙을 마련하는 것이 중요하다.

원문 읽기(새 탭에서 열림)
Figmaremote-workhybrid-workworkplace-strategy+1
figma3분 읽기큐레이션 요약

Figma 커뮤니티

Figma Community는 사용자들이 디자인 시스템, 아이콘, 와이어프레임, 일러스트, 프로토타입 등을 공개하고 서로 탐색·재사용·리믹스할 수 있는 공간이다. 2020년 8월부터 전체 Figma 사용자에게 단계적으로 공개되었으며, 검색과 태그 탐색, 프로필 핸들, 좋아요, 파일 복제 기능을 제공한다. 글은 베타 기간 동안 커뮤니티가 만든 다양한 리소스와 그 제작 배경을 소개하며, Figma Community가 협업과 지식 공유의 기반으로 성장할 가능성을 강조한다. ## Figma Community의 공개와 기능 - 수천 명의 제작자가 베타에 참여해 파일과 프로필을 공개했다. - 사용자는 다음과 같은 자료를 검색하고 탐색할 수 있다. - 디자인 시스템 - 아이콘 팩 - 와이어프레임 - 일러스트레이션 - 애니메이션 프로토타입 - 보드게임 등 실험적인 작업물 - 주요 기능은 검색, 태그 탐색, 프로필 핸들 선점, 좋아요, 파일 복제다. - 초기 공개 단계에서는 모든 사용자가 파일과 프로필을 볼 수 있지만, 파일을 직접 게시하려면 여전히 베타 참여가 필요했다. - Microsoft, Google Material Design, Mixpanel 같은 조직과 개인 디자이너들이 실용적인 리소스를 공개했다. ## Material Design Baseline Kit: 디자인 시스템의 출발점 - Google Material Design 팀의 Jessie Z가 제작한 리소스다. - 디자인 시스템을 처음부터 구축하는 부담을 줄이고, 다양한 프로젝트에서 활용할 수 있도록 설계됐다. - 두 부분으로 구성된다. - **Material Theme**: 타이포그래피와 색상 팔레트를 수정하고, 변경 사항이 컴포넌트·상태·예시 레이아웃에 미치는 영향을 빠르게 확인한다. - **Sticker sheet**: 기존 컴포넌트를 조합하고 활용하는 전통적인 UI 리소스 모음이다. - 사용자는 이 키트를 기반으로 Material 가이드라인을 학습하거나, 제품과 브랜드에 맞는 테마를 시각화할 수 있다. ## Open Figures: 재사용 가능한 일러스트 라이브러리 - Bonnie Kate Wolf가 제작한 일러스트레이션 라이브러리다. - 특정 회사의 브랜드 가이드에 얽매이지 않고 독립적인 스타일을 만들 수 있었던 프로젝트다. - 제품 화면, 프레젠테이션, 개인적인 창작 활동 등 다양한 목적에 사용할 수 있도록 구성됐다. - 모듈형 일러스트를 설계하면서 접근성과 포용성을 고려했다. - 휠체어를 사용하는 캐릭터의 의상 교체가 가능하도록, 드레스나 긴 재킷처럼 다른 요소와 충돌하는 형태를 조정했다. - 단순히 보기 좋은 그림을 제공하는 것을 넘어, 다양한 사용자를 표현할 수 있는 디자인 구조를 보여준다. ## Spotify Ways of Working: 팀 협업 방식의 공유 - Spotify의 Barton Smith, Cliona O’Sullivan과 Figma 워킹 그룹이 제작했다. - Figma에서 팀의 업무를 조직하고 협업하는 방식을 외부 커뮤니티에 공개한 자료다. - Spotify는 회사마다 Figma 파일과 프로젝트를 정리하는 표준 방식이 없고, 이를 어려워하는 팀이 많다는 점에서 출발했다. - 이 파일은 특정 도구 사용법보다 실제 조직이 업무를 구조화한 사례를 보여주는 데 목적이 있다. - Spotify 팀 역시 운영 과정에서 얻은 학습을 바탕으로 기존 결정을 계속 수정하고 있다고 설명한다. ## 커뮤니티가 만드는 공유 생태계 - Figma Community는 완성된 결과물뿐 아니라 제작자의 문제의식과 작업 방식을 공유하는 장으로 기능한다. - 대기업의 디자인 시스템부터 개인 창작자의 일러스트, 팀 운영 문서까지 자료의 범위가 넓다. - 공개된 파일을 복제해 자신의 프로젝트에 맞게 수정할 수 있어 학습과 실무 적용이 동시에 가능하다. - Figma는 초기 출시를 완성된 제품이 아니라 앞으로 확장될 기반으로 설명하며, 사용자들이 무엇을 만들고 어떻게 활용하는지에 따라 발전시킬 계획을 밝혔다. 실무에서는 Material Design Baseline Kit처럼 구조화된 시스템을 출발점으로 삼고, Open Figures처럼 재사용 가능한 시각 자산을 활용하며, Spotify 사례처럼 팀의 파일 관리 규칙을 문서화하는 방식으로 Figma Community를 활용할 수 있다.

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

피그마 내부: 원격 인

원격 인턴십은 관계 형성과 업무 맥락 습득에 어려움이 있을 수 있지만, 의도적으로 소통 기회를 만들고 적극적으로 질문하면 충분히 의미 있는 경험이 될 수 있다. Jenning Chen은 Figma에서 스타일 피커 개선 프로젝트를 맡아 검색, 색상 스타일 목록 보기, 텍스트 스타일 지표 표시를 구현했으며, 인턴도 실제 사용자 기능의 기획부터 출시까지 주도할 수 있음을 보여준다. 이 과정에서 협업과 피드백, 대규모 데이터 마이그레이션을 경험하며 제품 이해도와 기술 역량을 함께 넓혔다. ## 원격 환경에서의 따뜻한 온보딩 - 입사 직후 Slack 환영 메시지와 온라인 커피챗을 통해 팀원들과 관계를 형성했다. - 동료들이 만든 Figma 환영 카드와 낙서가 담긴 파일을 받으며 대면 없이도 회사의 개방적 문화를 느꼈다. - 원격 근무에서도 신입 구성원이 소속감을 느끼도록 의도적인 환영 절차가 중요했다. ## 원격 인턴십의 우려와 관계 형성 - Slack이나 이메일에서 메시지를 놓치거나 오해할 가능성, 팀원들과 깊은 관계를 만들기 어려울 가능성을 걱정했다. - 회사 전체 쇼앤텔, 기술 강연, 일대일 미팅 등을 통해 다른 팀의 업무와 구성원들의 관심사를 접했다. - 온라인 요리 수업, 방 탈출, 보물찾기 같은 활동은 업무 외적인 관계 형성에도 도움이 됐다. - 원격 환경에서는 우연한 대화가 줄어드는 대신, 조직이 교류 기회를 의도적으로 설계해야 했다. ## 제품 이해도와 질문하는 문화 - 프로젝트를 시작하기 전 Figma의 기능과 디자인 용어를 충분히 익혀야 했다. - 멘토, 팀원, Slack 채널에 적극적으로 질문하며 제품과 업무 맥락을 파악했다. - 문제가 생겼을 때 동료들이 기꺼이 화상 통화를 열어 함께 해결해 주었고, 이는 원격 환경에서도 빠르게 배울 수 있는 기반이 됐다. ## 스타일 피커의 기존 문제 - 스타일 피커는 페인트, 텍스트, 효과, 레이아웃 그리드 스타일을 찾아 적용하는 기능이다. - 스타일 수가 늘어나면서 기존 인터페이스가 복잡해졌다. - 긴 목록을 수동으로 스크롤해야 했고, 특히 색상 스타일의 이름처럼 중요한 정보가 잘 드러나지 않았다. - 사용자가 원하는 스타일을 빠르게 찾고 비교할 수 있도록 개선 요구가 컸다. ## 스타일 피커 개선 기능 - **검색 기능** - 사용자가 몇 글자만 입력해 원하는 스타일을 빠르게 찾을 수 있게 했다. - **색상 스타일 목록 보기** - 기존 격자 보기에서는 가려지던 스타일 이름을 썸네일 옆에 명확히 표시했다. - 목록 보기와 격자 보기를 전환할 수 있도록 했다. - **텍스트 스타일 지표 표시** - 텍스트 스타일을 선택할 때 중요한 글꼴 크기와 줄 높이를 직접 보여줬다. - 스타일을 적용하기 전에 핵심 속성을 확인할 수 있어 선택 시간을 줄였다. ## 여러 기술 스택을 활용한 구현 - 디자인 시스템 팀의 프로젝트 특성상 에디터부터 백엔드까지 전체 기술 스택을 다뤘다. - 에디터에서는 TypeScript와 C++를, 백엔드에서는 Ruby를 사용했다. - 단일 기능을 구현하면서 프론트엔드, 에디터 내부 로직, 백엔드 데이터 처리까지 폭넓은 경험을 쌓았다. ## 출시 과정의 협업과 기술적 난관 - 완성된 기능을 사내 쇼앤텔에서 발표하고 동료들의 피드백을 받았다. - 출시 전 수백만 개의 기존 텍스트 스타일에 글꼴 크기와 줄 높이 메타데이터를 추가하는 마이그레이션이 필요했다. - 해당 마이그레이션만 실행하는 데 하루가 걸렸으며, 리뷰 피드백 반영과 출시 직전 버그 수정도 진행했다. - 구현 과정의 어려움은 제품 구조와 데이터 흐름을 더 깊이 이해하는 계기가 됐다. ## 실용적인 시사점 원격 인턴십이나 신규 프로젝트에서는 정기적인 일대일 미팅, 공개적인 질문 채널, 업무 외 교류 기회를 미리 마련하는 것이 효과적이다. 또한 작은 기능이라도 사용자 문제를 명확히 정의하고, 기존 데이터와 마이그레이션 비용까지 고려하면 실제 출시 가능한 제품으로 발전시킬 수 있다.

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

Config Europe 발표: 발표자

Figma는 커뮤니티의 경험과 아이디어를 중심으로 한 가상 컨퍼런스 **Config Europe**를 2020년 9월 17일 개최한다고 발표했다. 온라인 전환을 통해 지역과 규모의 한계를 넘어 누구나 참여할 수 있도록 했으며, 발표자 제안과 무료 참가 신청을 모두 열었다. 특히 처음 발표하는 사람도 환영하고 지원하겠다는 점을 강조했다. ## Config Europe 개최 배경 - Figma는 앞서 샌프란시스코에서 첫 사용자 컨퍼런스 Config를 개최했다. - 약 1,200명이 현장에 참석했고 온라인으로도 많은 사용자가 참여했다. - 하지만 행사 장소와 규모 때문에 참석하고 싶어도 참여하지 못하는 사람들이 있었다. - 세계 여러 도시에서 행사를 열 계획이었지만, 코로나19로 인해 오프라인 계획을 잠정 중단했다. - 온라인 행사를 통해서도 Config의 핵심 목표인 커뮤니티의 목소리 확대, 지식 공유, 연결을 실현하고자 했다. ## 발표자 모집과 참여 방식 - 발표 제안 마감일은 **2020년 7월 31일**이었다. - 발표 형식은 다음과 같이 다양했다. - 일반 발표 - 패널 토론 - 라이트닝 토크 - 워크숍 - 발표 경험이 없는 사람도 지원할 수 있으며, 첫 발표자를 적극적으로 환영했다. - 발표자로 선정되면 다음과 같은 지원을 제공했다. - IT 지원 및 장비 - Figma 제품 전문가의 도움 - 발표 아이디어를 구체화하는 편집 지원 - 선정되지 않은 제안도 라이브스트림이나 블로그 글 등 다른 콘텐츠 기회에 적합하면 별도로 안내할 예정이었다. ## 주요 콘텐츠 트랙 ### 디자인 시스템 구축과 유지 - 디자인 시스템을 처음 시작하는 방법 - 규모가 커지는 조직에서 디자인 시스템을 확장하는 방법 - 컴포넌트 구축과 관리 - 스타일 가이드 개선 - 팀 구성원의 참여와 도입을 이끌어내는 방법 ### Figma 심층 활용 - Figma에서 디자인 작업 속도를 높이는 방법 - 플러그인 활용 - Auto Layout 사용법 - 컴포넌트 기반 작업 - 효율적인 디자인 워크플로 구축 ### 프로세스, 문화, 팀 빌딩 - 디자이너와 팀원 채용 및 채용 기준 - 팀 문화를 만드는 방법 - 조직 내 프로세스와 협업 규칙 수립 - 원격 근무 환경에서의 팀 운영과 커뮤니케이션 ### 디자인의 개방과 포용성 - 디자인 프로세스를 더 포괄적으로 만드는 방법 - 접근성을 고려한 디자인 - 디자이너가 아닌 사람도 디자인 과정에 참여시키는 방법 - 다양한 구성원의 의견을 반영하는 협업 방식 ## 참가자 모집과 행사 운영 - Config Europe는 전 세계 누구나 무료로 참가할 수 있도록 계획됐다. - 2020년 8월 20일에 행사 일정 공개와 참가 등록을 시작할 예정이었다. - 발표자 외에도 다음과 같은 커뮤니티 프로그램이 마련될 예정이었다. - 멘토링 - 네트워킹 세션 - 소셜 이벤트 - 발표 제안 결과는 2020년 8월 11일까지 안내할 계획이었다. 이번 발표는 온라인 행사를 단순히 오프라인 행사의 대체재로 보는 대신, 더 많은 사용자가 참여하고 자신의 경험을 공유할 수 있는 커뮤니티 플랫폼으로 활용하려는 시도였다. 기술 행사나 커뮤니티를 기획할 때도 규모나 장소보다 참여 장벽을 낮추고, 초보자와 다양한 배경의 참가자가 기여할 수 있도록 지원하는 것이 중요하다는 점을 보여준다.

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

기능 비하인드:

Figma의 그림자 `spread` 기능은 겉보기와 달리 단순히 도형을 확대하는 문제를 넘어선다. 사각형에서는 기하 도형을 키우는 방식이 작동하지만, 구멍이나 복잡한 윤곽을 가진 도형에서는 “모든 방향으로 일정 거리만큼 확장”해야 하므로 별도의 알고리즘과 렌더링 설계가 필요하다. 이 글은 CSS `box-shadow`와 호환되는 기능을 만들기 위해 알고리즘, W3C 명세, 기존 렌더러의 제약, 제품 우선순위를 검토한 과정을 설명한다. ## 그림자 `spread`가 필요한 이유 - Figma는 2020년 7월 23일부터 사각형, 타원, 프레임 배경, 컴포넌트 배경에 그림자 확산 거리를 조절하는 기능을 제공했다. - CSS의 `box-shadow`와 마찬가지로 `spread` 값은 그림자를 모든 방향으로 확장하거나 수축하는 거리다. - 사용자는 오랫동안 이 기능을 요청했지만, 기본적인 CSS 기능처럼 보이는 요구사항이 실제로는 그래픽스 엔진 수준의 문제였다. ## 기존 그림자 렌더링 방식 - 일반적인 드롭 섀도는 다음 순서로 만든다. - 원본 객체의 기하 구조를 복사한다. - 단일 색상으로 채운다. - 블러 효과를 적용한다. - 원본 노드 아래에 렌더링한다. - 이 방식은 단순한 도형의 그림자를 만드는 데는 충분하다. - 특히 사각형은 그림자 기하 구조를 확대하는 것만으로도 어느 정도 `spread` 효과를 낼 수 있다. ## 단순한 확대가 실패하는 복잡한 도형 - 복잡한 도형이나 Figma 로고처럼 내부에 구멍이 있는 도형은 전체 기하 구조를 스케일링하면 올바른 결과가 나오지 않는다. - 스케일링은 도형의 중심과 전체 비율을 기준으로 크기를 바꾸지만, `spread`는 원래 윤곽선에서 모든 방향으로 일정한 픽셀 거리만큼 확장해야 한다. - 따라서 원하는 결과는 단순히 외곽 크기가 커지는 것이 아니라 다음과 같은 형태다. - 볼록하거나 오목한 윤곽을 각각 일정 거리만큼 이동한다. - 내부 구멍도 동일한 규칙에 따라 확장 또는 축소한다. - 각 경계와 꼭짓점에서 일정한 거리 관계를 유지한다. ## 알고리즘과 렌더러의 제약 - 그림자 확산을 구현하는 알고리즘적 방법은 여러 가지가 있지만, 기존 Figma 렌더링 시스템에 자연스럽게 끼워 넣기 어려웠다. - 스트로크를 이용해 그림자를 흉내 내는 비알고리즘적 접근도 검토했지만 적합하지 않았다. - Figma의 스트로크는 특정 꼭짓점 각도를 그림자 확산에 필요한 방식과 다르게 처리한다. - 프로토타입 렌더러에는 스트로크 생성 코드 자체가 없었다. - Figma는 서로 다른 두 렌더링 코드베이스를 사용하고 있었기 때문에, 복잡한 기하 생성 로직을 양쪽에 모두 추가하는 방식은 유지보수 비용이 컸다. - 결국 문제는 “그림자를 크게 만드는 것”이 아니라, 기존 렌더링 구조를 크게 훼손하지 않으면서 임의의 2D 도형을 일정 거리만큼 확장하는 방법을 찾는 일이었다. ## 기능 개발 과정에서의 판단 - 작성자는 Maker Week에서 며칠 만에 끝낼 수 있는 간단한 기능이라고 생각했지만, 실제로는 몇 주가 걸리는 프로젝트가 되었다. - 개발 과정에서 처음 시도한 접근이 잘못되었음을 확인하고, 도형 확장 알고리즘과 W3C 명세를 다시 검토했다. - 이 사례는 사용자에게 단순해 보이는 기능도 다음 요소를 함께 고려해야 한다는 점을 보여준다. - 시각적으로 정확한 결과 - CSS와의 동작 호환성 - 기존 렌더링 엔진과의 통합 가능성 - 구현 복잡도와 장기적인 유지보수 비용 복잡한 도형의 그림자 `spread`를 구현할 때는 단순 확대나 스트로크 재활용만으로 해결하려 하지 말고, “윤곽선에서 모든 방향으로 일정 거리”라는 의미를 먼저 명확히 정의해야 한다. 이후 정확도, 렌더링 성능, 기존 코드베이스와의 통합 비용을 비교해 가장 현실적인 구현 방식을 선택하는 것이 중요하다.

원문 읽기(새 탭에서 열림)
CSScomputational-geometrycomputer-graphicsbox-shadow+2