real-time-collaboration

38 개의 포스트

figma

소프트웨어와 상호작용하는 방식을 재구상하는 6가지 디자인 | Figma 블로그 (새 탭에서 열림)

이번 Figma Make-a-thon 수상작들은 소프트웨어가 단순히 효율을 높이는 도구를 넘어, 사람들의 연결·놀이·창작 방식을 새롭게 설계할 수 있음을 보여준다. 공통적으로 기존의 익숙한 상호작용을 비틀고, 제약과 감각적 경험을 활용해 더 인간적인 디지털 경험을 만든다. 특히 Figma Make는 전문 개발 지식이 부족한 사람도 아이디어를 빠르게 프로토타입으로 구현하도록 돕는 도구로 소개된다. ## 소프트웨어 상호작용을 다시 상상한 Make-a-thon - Figma Make-a-thon은 핀치 줌, 좋아요 탭, 오른쪽 스와이프처럼 일상화된 상호작용의 다음 가능성을 탐구했다. - 수상작에는 총 10만 달러의 상금이 수여됐다. - 작품들은 새로운 기능보다 사람 사이의 연결, 놀이, 창의성, 장인정신에 초점을 맞춘다. - 얼굴 움직임으로 인터페이스를 조작하거나, 16비트 세계를 구현하는 등 익숙한 소프트웨어 사용 방식을 확장한다. ## 낯선 사람과 함께 만드는 자수 캔버스 **수상 부문: Best Overall — Common Thread** - 전통적인 자수 견본천(sampler)에서 영감을 얻은 멀티플레이어 디지털 캔버스다. - 사용자는 실의 색상과 스티치 유형을 선택해 공동 캔버스에 자신의 흔적을 남긴다. - 한 사람의 작업물이 아니라 여러 방문자가 이어서 완성하는 구조이며, 캔버스의 제한된 공간 자체가 중요한 경험이 된다. - 10만 개가 넘는 스티치가 쌓였으며, 작품은 완성되지 않은 채 계속 확장된다. - 제작자는 기능 목록보다 먼저 “어떤 느낌의 경험을 만들 것인가”를 설명하고, Figma Make로 구조를 만든 뒤 시각 디자인을 덧입히는 방식을 추천한다. - 실시간 협업과 인터랙티브 캔버스 기능을 개발 지식 없이 하루 만에 구현했다는 점도 강조된다. - 핵심 메시지는 속도와 규모를 중시하는 디지털 환경에서, 제한과 느린 공동 작업이 오히려 의미 있는 상호작용을 만든다는 것이다. ## 클릭 대신 입술 움직임으로 조작하기 **수상 부문: New Interaction — Pucker** - 손을 사용할 수 없거나 음성 명령을 원하지 않는 상황을 위해 얼굴 움직임을 입력 방식으로 활용한다. - 고개를 기울여 커서를 움직이고, 일정 시간 멈춰 항목을 선택하며, 입술을 오므리는 동작으로 선택을 확정한다. - 뜨개질, 요리, 베이킹, 디자인처럼 손이 바쁜 상황에서도 화면을 조작할 수 있다. - 전면 카메라로 실시간 추적하지만, 데이터는 저장하거나 전송하지 않는 방식으로 설계됐다. - 제작자는 기본적인 코드 구조를 이해하면 프로토타입을 수정하고 문제를 해결하는 데 큰 도움이 된다고 조언한다. - Pucker는 특정 제품이라기보다 여러 앱과 플랫폼에 적용할 수 있는 “유연한 인터랙션 레이어”로 제시된다. - 새로운 상호작용이 충분히 자연스러워지면 사용자가 의식하지 않고도 사용할 수 있으며, 이것이 접근성 높은 디자인으로 이어질 수 있다는 관점을 담고 있다. ## 시간과 공간의 제약을 없앤 사진 부스 **수상 부문: Reimagining Iconic Interactions — Duet Booth** - 1920년대부터 크게 변하지 않은 사진 부스의 개념을 원격 환경으로 확장한다. - 서로 다른 장소에 있는 두 사람이 비동기적으로 사진을 촬영할 수 있다. - 각자의 사진을 하나의 사진 스트립으로 결합해, 마치 두 사람이 같은 장소에 함께 있었던 것처럼 보여준다. - 사진 부스가 사진을 더 쉽고 즉각적이며 공유 가능한 경험으로 만들었다는 점을 디지털 공간에서 재해석한다. - 제작자는 시각적 세부 사항보다 핵심 상호작용을 먼저 완성하라고 조언한다. 기본 경험이 제대로 작동하면 이후의 디자인 요소가 이를 중심으로 정리되기 때문이다. 이 사례들이 보여주는 실용적인 방향은 기능을 많이 추가하는 것보다 사용자가 어떤 감정과 행동을 경험할지 먼저 정의하는 것이다. 그 후 핵심 상호작용을 빠르게 프로토타이핑하고, 시각 디자인과 세부 기능을 단계적으로 보완하면 제한된 시간과 개발 지식으로도 독창적인 소프트웨어 경험을 만들 수 있다.

figma

Figma Make를 소개 (새 탭에서 열림)

Figma Make는 자연어 프롬프트를 이용해 정적인 디자인을 실제로 조작 가능한 앱과 프로토타입으로 바꾸는 기능이다. 기존 Figma 프레임의 구조와 메타데이터를 유지하면서 애니메이션, 데이터, 반응형 동작 등을 빠르게 실험할 수 있으며, 디자이너와 제품팀이 코드 작성 없이 아이디어를 검증하도록 돕는다. Figma는 이를 디자인을 대체하는 도구가 아니라, 디자인 의도를 보존한 채 탐색과 구현을 가속하는 도구로 설명한다. ## 디자인에서 바로 시작하는 프롬프트 기반 제작 - 사용자는 빈 화면에서 시작할 필요 없이 Figma Design의 기존 프레임을 Figma Make로 복사할 수 있다. - 복사 과정에서 디자인의 구조와 메타데이터가 보존되어 원래 의도와 컴포넌트 계층을 유지한다. - 이후 “설정 패널을 열고 닫을 때 애니메이션을 추가해줘”처럼 자연어로 원하는 동작을 설명한다. - 현재 Figma Make는 Claude 3.7 Sonnet을 사용하며, 향후 다른 모델도 도입할 예정이다. ## 정적 디자인을 인터랙티브 프로토타입으로 전환 - 버튼, 애니메이션, 실시간 피드백 등을 추가해 정적인 화면을 실제 사용 가능한 프로토타입으로 바꿀 수 있다. - 파일 업로드나 정보 시각화처럼 동적 데이터를 사용하는 기능도 시험할 수 있다. - 모바일 앱 디자인을 데스크톱 화면으로 확장하는 등 다양한 폼팩터에 맞춘 반응형 디자인을 검증할 수 있다. - 향후 서드파티 데이터베이스와 디자인 시스템 연동도 지원할 계획이다. ## 실시간 협업과 역할 장벽 제거 - Figma 플랫폼 안에 통합되어 있어 여러 팀원이 같은 파일에서 실시간으로 탐색하고 수정할 수 있다. - 디자이너, 제품 관리자 등 기술 배경이 다른 구성원도 기능 추가, 데이터 적용, 인터랙션 모델 테스트에 참여할 수 있다. - 별도의 코딩 도구나 컨텍스트 전환 없이 하나의 작업 공간에서 아이디어 정의부터 반복 개선까지 진행한다. - 이를 통해 팀의 공통 기준점인 단일 소스 오브 트루스를 유지한다. ## 포인트 앤 프롬프트 방식의 정밀한 편집 - 특정 요소를 직접 선택한 뒤 변경 내용을 자연어로 지시할 수 있다. - 예를 들어 버튼에 애니메이션을 연결하거나, 특정 요소가 스크롤에 반응하도록 만들 수 있다. - 디자인 의도와 실제 동작 구현 사이의 간극을 줄이는 것이 목표다. - 구조화된 편집 방식은 디자인 시스템과 컴포넌트 계층을 보존해 기능을 추가하면서도 시각적 충실도를 유지한다. ## 캔버스에서 코드와 게시까지 이어지는 흐름 - Figma Make는 Figma Design 및 Figma Sites와 직접 연결된다. - 초기 아이디어를 디자인하고, 인터랙티브 프로토타입으로 검증한 뒤, 게시 가능한 사이트로 발전시키는 과정을 하나의 흐름으로 통합한다. - 별도 도구로 작업물을 다시 만들거나 맥락을 전환할 필요를 줄인다. ## 디자인 가능성의 확장 - Figma Make의 목적은 디자이너의 세밀한 반복 작업을 대체하는 것이 아니다. - 더 많은 디자인 방향을 빠르게 탐색하고, 아이디어의 실현 가능성을 조기에 검증하며, 팀에 개념을 효과적으로 전달하도록 지원한다. - 결과적으로 디자이너가 사고와 제작 사이를 빠르게 오가면서도 디자인의 완성도와 의도를 유지하도록 돕는다. 실무에서는 초기 아이디어 검증, 인터랙션 테스트, 반응형 화면 탐색처럼 반복 비용이 큰 단계에 우선 활용하는 것이 효과적이다. 다만 생성 결과를 최종 제품 코드로 바로 간주하기보다는, 팀의 디자인 시스템과 기술 요구사항에 맞춰 검토·정제하는 프로토타이핑 도구로 사용하는 것이 적절하다.

figma

정부를 위한 피그마에 대해 (새 탭에서 열림)

Figma는 미국 연방정부의 보안·개인정보 기준인 FedRAMP Moderate 인증을 획득하고, 공공기관용 서비스인 Figma for Government를 제공한다. 이를 통해 연방기관은 FigJam, Figma, Dev Mode를 활용해 시민 대상 웹사이트와 애플리케이션을 안전하게 기획·설계·개발할 수 있다. 글은 부서 간 협업과 디자인 시스템을 강화해 더 일관되고 접근성 높은 디지털 공공서비스를 만드는 것이 이 서비스의 목표라고 설명한다. ## FedRAMP Moderate 인증과 Figma for Government - Figma for Government는 미국 연방정부의 엄격한 보안 및 개인정보 보호 기준을 충족하는 FedRAMP Moderate 인증을 받았다. - 제공 대상 제품은 다음과 같다. - **Figma**: 인터페이스 설계, 프로토타이핑, 디자인 리뷰 - **FigJam**: 브레인스토밍, 프로젝트 계획, 사용자 여정 맵 작성 - **Dev Mode**: 디자인과 개발 간 협업 - **Figma Slides**: 추후 제공 예정 - 인증을 통해 연방기관이 민감한 공공서비스를 설계하고 구축할 수 있는 보안 환경을 제공한다. ## 공공서비스 디지털화의 필요성 - 시민들은 의료, 정부 지원, 여권·비자 등 공공서비스를 온라인에서 쉽고 빠르게 이용하기를 기대한다. - 연방 정책에 따라 디지털 서비스는 다음 조건을 갖춰야 한다. - 간결하고 사용하기 쉬운 경험 - 접근성 - 일관된 디자인 - 적절한 도구가 없으면 디자인, 개발, 기획 업무가 조직별로 분리되어 효율성과 결과물의 사용성이 떨어질 수 있다. - 따라서 무엇을 출시하는지뿐 아니라, 여러 팀이 **어떻게 협업하고 출시하는지**도 중요하다고 강조한다. ## Figma for Government가 해결하는 문제 - 100개가 넘는 정부기관과 계약업체가 이미 Figma를 활용해 업무를 현대화하고 있다. - 아이디어 구상부터 디자인 반복 작업, 프로토타이핑, 최종 구현과 개선까지 하나의 플랫폼에서 연결할 수 있다. - 링크 하나로 조직 내 구성원이 작업물을 확인하고, 수정하고, 피드백을 남길 수 있다. - 이를 통해 부서 간 사일로를 줄이고 최신 작업물을 공유하는 단일 기준점(single source of truth)을 만든다. - 정부기관이 민간의 선도적인 조직과 유사한 협업 도구를 보안 환경에서 사용할 수 있도록 설계됐다. ## 공공기관 활용 사례 - **미국 국립공원관리청(NPS)**은 431개 국립공원과 기념물 정보를 제공하는 앱을 제작했다. - 기존 공원 안내 책자의 디자인 언어를 디지털 인터페이스에 적용했다. - **Amtrak**은 2만 명 이상의 직원과 2,800만 명의 승객을 지원하는 시스템을 효율화했다. - 미국 웹 디자인 시스템(USWDS)의 공식 Figma 디자인 키트도 제공된다. - 변수(variables)와 스마트 레이아웃을 활용한 42개 컴포넌트로 구성됐다. - 국무부의 여권·비자 시스템, 국세청의 온라인 납세 서비스, 시민권·이민 서비스국의 시민권 업무 등에도 활용되고 있다. ## FigJam을 활용한 공동 기획 - 여러 지역과 시간대에 분산된 팀이 실시간 또는 비동기 방식으로 협업할 수 있다. - FigJam에서 다음 작업을 한곳에서 진행할 수 있다. - 브레인스토밍 - 프로젝트 로드맵 작성 - 사용자 여정 맵 작성 - 전략 및 정보 공유 - 모든 구성원이 의견을 남기고 다른 사람의 생각을 확인할 수 있어 초기 아이디어를 정렬하는 데 유용하다. ## Figma를 활용한 디자인 협업과 표준화 - 최신 디자인 파일을 모든 이해관계자와 공유해 와이어프레임, 프로토타입, 리뷰, 수정 과정을 단축한다. - 디자이너뿐 아니라 개발자, 제품 관리자, 경영진 등도 디자인 과정에 참여할 수 있다. - 조직은 디자인 시스템을 만들고 관리해 다음을 달성할 수 있다. - 화면 간 일관성 유지 - 높은 품질의 인터페이스 제작 - 기관의 브랜드 정체성 강화 - 시민에게 신뢰감 있는 경험 제공 ## Dev Mode를 통한 디자인-개발 연결 - 디자인과 엔지니어링 팀 간 소통이 부족하면 디자인 의도 확인, 변경사항 비교, 디자인과 코드 연결에 불필요한 시간이 든다. - Dev Mode는 디자이너와 개발자가 같은 작업 공간에서 협업하도록 지원해 이러한 단절을 줄이는 역할을 한다. - 전체 개발 과정에서 디자인 결과물을 구현 단계로 원활하게 전달하는 것이 핵심이다. ## 실용적인 결론 공공기관은 Figma for Government를 활용해 아이디어 구상부터 개발까지의 협업 흐름을 하나로 통합하고, 디자인 시스템으로 서비스의 일관성과 접근성을 높일 수 있다. 특히 여러 부서와 지역에 걸쳐 운영되는 시민 서비스라면 FedRAMP Moderate 인증 환경, 공동 편집, 단일 작업 기준점이 업무 효율과 서비스 품질 향상에 도움이 된다.

figma

개발자가 디자인에 적극적으로 참여 (새 탭에서 열림)

Figma의 Dev Mode는 개발자를 디자인의 수동적 구현자가 아니라 제품 설계에 참여하는 협업자로 바라보게 한다. 개발자가 디자인 도구를 적극적으로 사용하고 필요한 개선을 직접 제안하면, 디자인 파일 탐색의 불안과 반복적인 탭 전환을 줄이고 디자이너와의 공통 언어를 만들 수 있다. 글은 Dev Mode 도입을 조직에 요구하는 일이 개발자 경험과 생산성, 협업 품질을 개선하는 실질적인 방법이라고 결론짓는다. ## 개발자는 디자인 과정의 참여자다 - 기존에는 디자인 도구를 디자이너만 사용하는 것으로 여겨 개발자가 파일을 조심스럽게 열어보거나 여러 브라우저 탭을 오가며 사양을 확인했다. - 이런 역할 분리는 디자인과 구현 사이의 소통 비용을 키우고, 개발자가 제품 결정에 기여할 기회를 줄인다. - Dev Mode는 개발자에게 별도의 작업 공간과 기능을 제공해 기획부터 출시까지 디자인 과정에 참여할 수 있게 한다. - 개발자가 Dev Mode의 필요성을 조직에 설명하고 도입을 주도해야 더 나은 협업 환경을 만들 수 있다. ## 공유 도구가 만드는 공통 언어 - Dev Mode는 개발자가 디자인을 단순히 구현하는 사람이 아니라 적극적인 협업자라는 전제를 바탕으로 한다. - Figma의 오토 레이아웃은 개발자에게 CSS Flexbox와 유사하게 느껴져 디자인의 레이아웃 동작을 웹 구현 방식과 연결해 주었다. - 이러한 공통 개념은 디자이너와 개발자가 서로의 작업 방식을 이해하는 접점이 된다. - Dev Mode는 특정 기능 하나를 넘어, 양쪽 직군이 같은 파일과 개념을 바탕으로 소통하는 협업 프레임워크를 제공한다. ## 개발자가 직접 도입을 제안해야 하는 이유 - 관리자는 실제 작업에서 한 단계 떨어져 있어 개발자가 겪는 불편과 생산성 저하를 놓칠 수 있다. - 개발자는 GitHub 이슈, 풀 리퀘스트 의견, Stack Overflow 답변처럼 필요한 개선을 직접 제안하는 데 익숙하다. - 같은 방식으로 1:1 미팅, 스프린트 회고, 팀 회의에서 디자인 도구와 개발자 경험의 문제를 구체적으로 제기할 수 있다. - 단순히 “새 도구가 필요하다”고 말하기보다, 현재의 반복 작업과 협업 비용을 어떤 기능이 어떻게 줄이는지 설명해야 설득력이 높아진다. ## 두려움 없이 디자인 파일 탐색하기 - Dev Mode는 기본적으로 읽기 전용이므로 개발자가 실수로 디자인 파일을 수정하거나 다른 사람의 작업을 덮어쓸 위험을 줄인다. - 개발자는 여백, 컴포넌트, 레이아웃 등을 자유롭게 클릭하며 파일 구조를 탐색할 수 있다. - 이는 Git의 `main` 브랜치 보호와 비슷한 안전장치로, 파일을 망칠까 봐 지나치게 조심하는 상황을 없앤다. - 결과적으로 디자인 파일을 이해하는 데 필요한 탐색 시간이 줄고, 개발자의 사용 자신감이 높아진다. ## 변경 사항을 명확하게 비교하기 - Dev Mode의 버전 기록과 변경 사항 비교 기능은 GitHub의 커밋 기록이나 풀 리퀘스트와 유사한 방식으로 동작한다. - 디자인의 여러 버전을 시각적으로 비교해 무엇이 언제, 누구에 의해 변경되었는지 확인할 수 있다. - 문구 변경, 여백 수정, 컴포넌트 변형 추가처럼 변경 항목을 구체적인 작업 목록으로 파악할 수 있다. - 이를 통해 개발자는 최신 디자인을 빠르게 이해하고, 구현 과정에서 누락된 변경 사항을 줄일 수 있다. ## 디자인 사양과 코드 사이의 탭 전환 줄이기 - 기존 개발자는 디자인 사양, 문서, 코드 저장소를 오가며 정보를 확인해야 했고, 이 과정에서 많은 시간이 소모됐다. - Dev Mode와 Code Connect 같은 기능은 디자인 정보와 실제 코드 구현 사이의 거리를 줄이는 방향으로 설계됐다. - 디자인 확인과 개발에 필요한 정보를 한 작업 흐름 안에서 연결하면 반복적인 검색과 컨텍스트 전환을 줄일 수 있다. - 이는 단순한 편의 기능을 넘어 개발자의 집중력과 전체 개발 속도에도 영향을 준다. ## 실용적인 적용 방향 - 현재 디자인 파일을 확인할 때 발생하는 실수, 정보 탐색, 탭 전환 시간을 구체적으로 기록한다. - Dev Mode의 읽기 전용 탐색, 버전 비교, 코드 연결 기능이 각각 어떤 문제를 해결하는지 사례로 제시한다. - 디자인 시스템 개편이나 원격·하이브리드 협업처럼 여러 직군의 긴밀한 조율이 필요한 프로젝트에서 먼저 적용한다. - 도구 도입 자체보다 디자이너와 개발자가 공유할 수 있는 언어와 작업 방식을 만드는 데 초점을 둔다.

figma

피그마와 어도비, (새 탭에서 열림)

Figma와 Adobe는 15개월간의 규제 심사 끝에 인수합병을 중단하기로 공동 결정했다. 양사는 제품과 사업, 시장의 차이를 규제 당국에 설명했지만 승인 가능성이 없다고 판단했다. Figma는 독립 기업으로 남아 AI와 협업 기능을 강화하고, 향후 Adobe와는 사용자에게 도움이 되는 방식으로 협력할 계획이다. ## 인수합병 중단과 규제 승인 불확실성 - Figma와 Adobe는 15개월 동안 전 세계 규제 당국의 심사를 받았다. - 양사는 두 기업의 사업·제품·시장 사이에 차이가 있다는 점을 수천 시간에 걸쳐 설명했다. - 그러나 제안된 인수의 규제 승인을 받을 현실적인 경로가 없다고 판단해 거래를 종료했다. - 인수합병은 양사의 사용자 커뮤니티에 더 큰 가치를 제공하려는 목적에서 시작됐지만, 최종적으로 실현되지 못했다. ## 독립 기업으로서의 Figma - Figma는 Adobe에 인수되지 않고 독립적인 기업으로 계속 운영된다. - 인수 심사 기간의 불확실성 속에서도 제품 개발과 조직 확장을 지속했다. - 향후 Adobe와 경쟁만 하는 것이 아니라 사용자에게 도움이 되는 협력 기회를 모색할 예정이다. - 영국과 아시아에 새로운 거점을 열고, 500명 이상의 직원을 추가했다. ## 지난 15개월간의 제품 발전 - **FigJam AI 기능**을 출시해 시각적 협업과 아이디어 구상에 AI를 활용할 수 있도록 했다. - **Dev Mode**를 도입해 개발자가 디자인 파일에서 필요한 정보와 도구에 더 쉽게 접근하도록 개선했다. - **Variables**와 **Advanced Prototyping**을 추가해 디자인 시스템과 프로토타이핑 기능을 확장했다. - AI 스타트업 **Diagram**을 인수해 디자인 과정에서 AI가 담당할 수 있는 영역을 넓혔다. - Config 2023 행사를 통해 디자인과 개발이 하나의 흐름으로 연결되는 제품 방향을 제시했다. ## Figma의 장기 비전 - 창업 당시의 목표는 “상상과 현실 사이의 간극을 없애는 것”이었다. - 디지털 경제의 확대와 AI 기술의 발전으로 이 목표가 더욱 중요하고 실현 가능해졌다고 설명한다. - Figma는 누구나 하나의 멀티플레이어 캔버스에서 아이디어 구상부터 디자인, 개발, 제품 출시까지 진행할 수 있도록 만드는 데 집중할 예정이다. - 디자인 도구를 넘어 디지털 제품 제작 전 과정을 지원하는 플랫폼으로 발전하려는 방향이다. 이번 결정은 대형 인수합병보다 Figma의 독립성과 제품 혁신을 유지하는 결과로 이어졌다. 사용자 입장에서는 Figma가 AI, 개발자 도구, 협업 기능을 중심으로 계속 확장되는지 지켜보는 것이 중요하다.

figma

역할이 규칙이 아닌 이유 (새 탭에서 열림)

제품 개발이 협업 중심으로 바뀌면서 엔지니어의 역할은 정해진 요구사항을 구현하는 데서 벗어나, 무엇을 만들지까지 함께 결정하는 방향으로 확장되고 있다. 하지만 협업과 피드백을 항상 늘리는 것이 정답은 아니며, 다양한 의견을 탐색하는 단계와 결정을 내리고 추진하는 단계 사이의 균형이 중요하다. Figma는 역할을 고정된 규칙으로 보지 않고, 초기부터 폭넓게 협업하되 마일스톤을 통해 적절한 시점에 수렴하는 방식을 택한다. ## 엔지니어 역할의 확장 - 웹 기술의 발전과 Google Docs 같은 협업 도구의 확산, 원격·하이브리드 근무의 증가로 제품은 점점 “멀티플레이어 기본값”이 되었다. - 제품 개발은 더 이상 디자인에서 시작해 엔지니어링으로 끝나는 선형적인 과정이 아니다. - 엔지니어는 단순히 구현 방법(how)을 결정하는 사람이 아니라, 고객 피드백과 제품·디자인 동료의 의견을 바탕으로 만들 대상(what)도 함께 정의한다. - 따라서 직무의 경계를 엄격한 규칙으로 보기보다, 필요한 순간 서로의 영역을 넘나드는 협업 방식이 요구된다. ## 협업과 독립성 사이의 균형 - 다른 사람의 지식을 활용하는 것과, 방향 없이 계속 논의만 반복하는 것은 다르다. - 모든 작업에서 항상 최대한 많은 사람의 피드백을 받으면 품질이 높아질 것 같지만, 오히려 결정이 늦어지고 프로젝트가 제자리걸음할 수 있다. - 독립적으로 집중해야 하는 시기와 적극적으로 다른 팀을 끌어들여야 하는 시기는 작업마다 다르다. - 적절한 균형은 조직 문화, 제품의 특성, 팀이 최적화하려는 목표에 따라 달라진다. ## 초기 아이디어를 공개하는 방식 - 새로운 업무를 시작할 때는 가능한 한 이른 시점부터 다양한 관점을 반영한다. - 엔지니어는 완성된 설계가 아니라 초기의 생각과 가설을 문서로 작성해야 한다. - 문서는 “완성 후 검토”를 위한 산출물이 아니라, 작업 중인 상태에서 피드백을 받기 위한 협업 도구다. - 대부분의 프로젝트에 초기 생각을 기록하는 문서가 존재하지만, 각 팀이 바쁜 상황에서도 빠르게 피드백을 주고받을 수 있는 구조가 필요하다. ## 엔지니어링 크리트: 승인보다 피드백 - Figma는 디자인·엔지니어링 조직 간 정기적인 엔지니어링 크리트(crit)를 운영한다. - 크리트의 목적은 다음과 같다. - 기술 설계를 초기에 공유한다. - 다른 팀으로부터 자주 피드백을 받는다. - 전문적인 기술 지원과 문제 제기를 얻는다. - 크리트는 승인 회의가 아니다. - 회의에서 최종 결정을 내리거나 작업을 확정하지 않는다. - 작업 중인 상태(WIP)를 전제로 문제를 지적한다. - 설계 자체가 충분히 발전해 별도의 승인을 필요로 하지 않도록 돕는다. - Figma는 FigJam을 사용해 실시간으로 참여하고 의견을 시각적으로 공유한다. ## 너무 많은 의견이 만드는 정체 - 다양한 의견은 유용하지만, 입력이 지나치게 많거나 서로 충돌하면 프로젝트가 방향을 잃을 수 있다. - 특히 가격 정책처럼 불확실성과 중요한 트레이드오프가 많은 문제에서는 아이디어가 계속 추가되면서 결정을 내리지 못할 위험이 크다. - 탐색적이고 생성적인 논의만 계속하면 프로젝트가 앞으로 나아가지 못한다. - 협업의 목표는 모든 의견을 반영하는 것이 아니라, 더 나은 결정을 내릴 수 있을 만큼 설계를 발전시키는 데 있다. ## 마일스톤을 통한 수렴 - Figma는 프로젝트를 여러 마일스톤으로 나누어 탐색과 실행의 시점을 구분한다. - 마일스톤을 명확히 정의하고 공유하면 다음과 같은 효과가 있다. - 이해관계자의 기대치를 관리할 수 있다. - 현재 단계에서 무엇을 결정해야 하는지 분명해진다. - 계속 확장하기보다 수렴해야 할 시점을 알 수 있다. - 프로젝트가 진전되려면 다양한 가능성을 열어두는 단계와, 하나의 방향을 선택해 추진하는 단계가 모두 필요하다. - 추진력(momentum)이 유지되면 목표에 가까워지고 있다는 감각을 얻지만, 추진력을 잃으면 프로젝트의 방향과 목적 자체를 다시 의심하게 된다. ## 실용적인 적용 - 초기 설계와 가설을 완성되기 전에 문서로 공유한다. - 피드백 회의는 승인 절차가 아니라 문제를 조기에 발견하는 자리로 운영한다. - 모든 의견을 반영하려 하지 말고, 마일스톤마다 탐색을 멈추고 결정을 내릴 시점을 명확히 한다. - 역할과 책임을 고정된 경계로 보지 않되, 최종적으로는 누가 어떤 결정을 내리고 실행할지 분명히 해야 한다.

figma

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

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

figma

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

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

figma

WIP에 오신 것을 환영 (새 탭에서 열림)

디지털 제품 개발은 연구→아이디어→설계→테스트→출시로 끝나는 선형 과정이 아니라, 계속 수정·공유·협업하는 “진행 중인 작업(WIP)”에 가깝다. 이 변화는 초기 공유와 빠른 피드백을 가능하게 하지만, 피드백의 유효성이 쉽게 사라지고 최종 상태를 판단하기 어려워지는 혼란도 만든다. 따라서 완벽한 검토 시점을 기다리기보다 예측 가능한 주기로 작업을 검토하고, WIP 상태에 맞는 협업 방식을 설계해야 한다. ## 선형적 제품 개발 모델의 한계 - 전통적인 제품 개발은 다음과 같은 이상적인 순서를 전제로 한다. - 리서치 - 브레인스토밍 - 스케치 - 테스트 - 출시 - 물리적 제품은 제작과 변경에 비용이 많이 들었기 때문에 단계별로 신중하게 진행하는 선형 프로세스가 중요했다. - 하지만 디지털 제품은 몇 분 만에도 업데이트할 수 있어, 문제 정의·해결책·제품이 명확히 고정된 순간을 찾기 어렵다. - 실제 프로젝트는 이전 단계로 되돌아가거나 여러 단계가 동시에 진행되는 등 훨씬 비선형적이고 복잡하다. ## 디지털 제품은 항상 진행 중이다 - 브라우저 기반 협업 도구에서는 파일이 이메일로 전달되는 정적 문서가 아니라, 누구나 URL을 통해 동시에 확인하고 수정하는 공동 작업 공간이 된다. - 실시간으로 수정할 수 있기 때문에 팀은 완성될 때까지 기다리지 않고 초기 결과물을 더 일찍 공유한다. - 파일 제목에 `[WIP]` 또는 `Work in Progress`를 표시하면 결과물이 미완성임을 알리고, 피드백을 주는 사람의 부담과 기대치를 낮출 수 있다. - 디자이너는 초기 방향을 제품 관리자와 공유하고, 작가는 초고를 편집자에게 보여주는 방식으로 작업 초기에 협업할 수 있다. ## WIP 협업이 만드는 새로운 문제 - 작업이 계속 바뀌면 과거에 남긴 댓글이나 피드백이 더 이상 현재 결과물에 적용되지 않을 수 있다. - 전날 합의하거나 승인한 내용이 다음 날에는 이미 변경되어, “무엇이 확정되었는가”를 추적하기 어려워진다. - 파일이 실제로 최종 상태가 되는 명확한 순간이 없으며, 제품 출시 후에도 WIP 표시를 삭제하지 않는 경우가 생긴다. - 따라서 팀 구성원이 변화와 피드백을 놓치지 않도록 지속적인 알림과 소통 체계가 필요하다. - Figma는 이러한 문제를 보완하기 위해 알림과 모바일 댓글 기능을 제공하고, Google Calendar·Microsoft Teams·Zoom 등 외부 도구와의 연동도 확장하고 있다. ## 완벽한 검토 시점보다 예측 가능한 검토 주기 - 항상 변화하는 환경에서는 다음 중 언제 리뷰해야 할지 판단하기 어렵다. - 문제를 정의할 때 - 해결책을 정렬할 때 - 출시 직전 - 이상적인 방식은 작업이 각 단계를 자연스럽게 통과하며 팀의 확신이 점점 높아지는 것이지만, 실제로는 작업 상태가 계속 움직인다. - 특정 단계가 “완벽해질 때”까지 기다리기보다, 정해진 주기에 따라 정기적으로 리뷰하면 이해관계자와 팀이 지속적으로 방향을 확인할 수 있다. - 예측 가능한 리뷰 cadence는 피드백을 한 번에 몰아서 받는 대신, 작업의 변화에 맞춰 반복적으로 조정할 수 있게 한다. - 결과적으로 중요한 것은 최종 승인 순간을 찾는 것이 아니라, 반복적인 검토를 통해 제품 방향에 대한 신뢰를 점진적으로 높이는 것이다. ## 실용적인 적용 방법 - 초기 산출물에는 WIP 상태를 명확히 표시해 피드백의 기대 수준을 조정한다. - 피드백이 특정 버전이나 상태를 기준으로 한다는 점을 댓글과 리뷰 기록에 남긴다. - 완벽한 결과물을 기다리지 말고 정기적인 리뷰 일정을 운영한다. - 알림, 모바일 댓글, 협업 도구 연동을 활용해 작업 변화와 의사결정을 공유한다. - “완료”를 단 한 번의 최종 승인으로 정의하기보다, 반복적인 검토와 업데이트의 과정으로 바라보는 것이 적합하다.

figma

멀티플레이어를 더 안정적으로 (새 탭에서 열림)

Figma는 인메모리 상태와 30~60초 간격의 체크포인트에 의존하던 멀티플레이어 시스템에 변경 이력을 기록하는 저널(write-ahead log)을 도입했다. 저널은 파일의 전체 상태가 아닌 증분 변경을 자주 저장하므로 장애 발생 시 최신 체크포인트 이후의 변경을 재생해 복구할 수 있으며, 목표 데이터 손실을 1초 미만으로 줄였다. 또한 배포 시 모든 파일을 동시에 체크포인트하는 쓰기 부하 급증도 해소했다. ## 기존 멀티플레이어 구조 - 브라우저 클라이언트는 WebSocket으로 `multiplayer` 서비스에 연결한다. - 서버는 파일 상태를 메모리에 보관하면서 여러 클라이언트의 변경 사항을 수신·검증·정렬·충돌 해결한 뒤 전체 클라이언트에 전달한다. - 메모리 상태는 휘발성이므로 30~60초마다 파일 전체를 바이너리로 인코딩하고 압축해 S3에 체크포인트로 저장한다. - 체크포인트는 버전 기록 등 일부 기능의 기반이 된다. ## 체크포인트 중심 방식의 문제점 - 서버가 장애를 일으키면 마지막 체크포인트 이후 최대 60초의 작업을 잃을 수 있다. - 파일 전체를 저장하므로 파일의 크기와 복잡도가 커질수록 저장 비용도 증가한다. - 멀티플레이어를 재배포하면 메모리에 있던 모든 파일을 닫아야 하므로 동시에 대량의 체크포인트 쓰기가 발생한다. - 이로 인해 데이터베이스 부하가 급증하고, 배포가 사용자에게 보이지 않는 작업이어야 한다는 목표를 방해한다. ## 증분 변경을 저장하는 저널 - Figma는 파일 변경 사항을 기록하는 내구성 있는 트랜잭션 로그인 저널을 추가했다. - 멀티플레이어가 변경을 수락하면 변경 내용을 비동기적으로 저널에 기록한다. - 각 변경에는 파일별로 증가하는 시퀀스 번호를 부여한다. - 체크포인트에도 해당 시점의 시퀀스 번호를 함께 저장한다. - 저널에는 전체 파일이 아니라 사용자가 수행한 증분 변경만 저장한다. - 예: 텍스트 수정, 디자인 요소의 위치 변경, 목업 업데이트 등 - 증분 변경은 전체 파일보다 훨씬 작기 때문에 더 자주 기록해도 효율적이다. ## 장애 복구 방식 - 서버가 재시작되면 기존 체크포인트를 먼저 불러온다. - 체크포인트의 시퀀스 번호보다 큰 시퀀스 번호를 가진 저널 항목을 조회한다. - 해당 변경들을 순서대로 재생해 최신 파일 상태를 복원한다. - 기존 체크포인트 방식은 약 60초 간격으로 저장했지만, 저널은 약 0.5초 수준으로 변경 사항을 기록하는 방향을 취한다. - 그 결과 장애 시 데이터 손실 목표를 1초 미만으로 낮췄다. ## 배포 시 쓰기 부하 안정화 - 배포할 때 모든 연결을 종료하고, 아직 저장되지 않은 변경이 저널에 기록될 때까지 기다린다. - 99번째 백분위수 기준으로 이 과정은 1초 이내에 완료된다. - 배포를 위해 대규모 체크포인트를 한꺼번에 생성할 필요가 없어졌다. - 저널 쓰기는 평상시에도 지속적으로 발생하므로 데이터베이스 부하가 일정하고 예측 가능해진다. ## 데이터 저장소 선택 - 저널의 백엔드 저장소로 DynamoDB를 사용했다. - Postgres와 로컬 디스크 등 여러 선택지를 검토했지만, 높은 쓰기량을 수평 확장해야 한다는 점 때문에 Postgres는 선택하지 않았다. - 이 사례에서는 익숙한 데이터베이스보다 쓰기 규모와 확장성을 감당할 수 있는 저장소가 더 중요한 기준이었다. ## 변경 사항 배치 처리 - 클라이언트는 초당 30프레임, 즉 약 33ms마다 업데이트를 보낸다. - 모든 업데이트를 같은 빈도로 저널에 기록할 필요는 없으므로 여러 변경 사항을 묶어 일정 주기로 저장한다. - 이 배치 처리는 저널 쓰기 횟수를 줄이고 성능을 개선하면서도 체크포인트보다 훨씬 짧은 복구 지연 시간을 유지하기 위한 방식이다. Figma의 사례는 전체 상태를 드물게 저장하는 체크포인트와, 작은 변경을 자주 저장하는 저널을 함께 사용하는 구조가 실시간 협업 시스템에 적합하다는 점을 보여준다. 장애 복구 시간과 데이터 손실을 줄이려면 증분 로그를 도입하고, 시퀀스 번호를 기준으로 체크포인트와 로그를 연결하는 방식을 고려할 수 있다.

figma

Figma의 새로운 소식: (새 탭에서 열림)

이 글은 2022년 8월 Figma와 FigJam에 추가된 기능과 개선 사항을 소개한다. 가장 큰 변화는 Microsoft Teams 통합으로, 사용자가 Teams를 떠나지 않고도 Figma 파일을 발표·공유하고 실시간 피드백을 확인할 수 있게 된 점이다. 이와 함께 일상적인 사용성을 높이는 20개 이상의 소규모 개선과 교육용 기능 및 리소스도 공개됐다. ## Microsoft Teams 통합 - Figma와 FigJam을 Microsoft Teams 안에서 직접 사용할 수 있는 앱을 출시했다. - Teams 회의 중 Figma 파일을 발표하고, 협업 아이디어를 논의할 수 있다. - Teams 채널에 관련 Figma 파일을 추가해 팀원이 쉽게 접근하도록 할 수 있다. - Figma와 FigJam에서 발생한 피드백과 업데이트를 실시간 알림으로 확인할 수 있다. - 업무 공간을 Teams에서 벗어나지 않고 디자인 협업과 커뮤니케이션을 이어갈 수 있다는 점이 핵심이다. ## 20개 이상의 사용성 개선 Figma는 1년에 두 번 ‘Little Big Updates’를 통해 작지만 실무에 큰 영향을 주는 기능을 추가한다. - **그라디언트 편집 개선** - 그라디언트를 더블 클릭하면 색상 지점을 균등하게 배치할 수 있다. - 색상 채우기에 깊이감과 입체감을 더하기 쉬워졌다. - **프레임 내부 마크업 개선** - 프레임 위에 주석이나 표시를 남겨도 내용이 잘리거나 자동 레이아웃에 포함되는 문제를 줄였다. - 디자인 리뷰와 시각적 피드백 작성이 편리해졌다. - **FigJam 다이어그램 제작 개선** - 새로운 프롬프트를 사용해 도형을 자동으로 만들 수 있다. - 커넥터 모드를 유지한 채 작업할 수 있어 플로차트와 다이어그램을 빠르게 구성할 수 있다. - 이 밖에도 단축키, 디자인 편집, 협업 과정 전반에 걸쳐 20개 이상의 세부 개선이 제공됐다. ## 교육용 Figma와 FigJam 확대 Figma는 교육 커뮤니티를 위한 행사와 기능도 강화했다. - 교육 커뮤니티를 대상으로 첫 컨퍼런스인 ‘Commons’를 개최했다. - 교실 수업에 활용할 수 있는 FigJam 스티커 팩 2종을 추가했다. - 교육용 템플릿을 모은 Education Community 컬렉션을 공개했다. - 매달 교육 관련 YouTube 콘텐츠를 제공하는 ‘Study Hall’ 시리즈를 시작했다. - Chromebook 베타를 업데이트해 미국 고등학교 학군이 학생과 교사에게 Figma Organization을 무료로 배포할 수 있도록 지원했다. ## 제품 발전과 커뮤니티 중심 전략 - Figma 공동 창업자이자 CEO인 Dylan Field는 2014년 알파 출시부터 2022년까지의 10년간의 발전을 되돌아봤다. - 제품 자체의 대형 기능뿐 아니라 반복적으로 사용하는 작업의 불편을 줄이는 세부 개선에도 집중하고 있다. - 협업 도구 연동, 교육 지원, 커뮤니티 콘텐츠를 통해 Figma를 디자인 도구를 넘어 협업 플랫폼으로 확장하려는 방향이 드러난다. 실무 사용자는 Microsoft Teams 앱을 도입해 회의·피드백·파일 공유 흐름을 통합하고, 그라디언트·마크업·FigJam 커넥터 개선을 작업 방식에 적극 활용해볼 만하다. 교육 기관이라면 무료 Organization 배포와 교육용 템플릿 및 콘텐츠를 검토할 가치가 있다.

figma

마이크로소프트 존 프리드 (새 탭에서 열림)

Figma와 Microsoft Teams의 통합은 디자인·개발·제품·마케팅 팀이 하나의 생태계에서 실시간 또는 비동기적으로 협업하도록 돕는다. Jon Friedman은 하이브리드 근무가 인재 확보와 협업 방식을 넓혔지만, 대면 만남만이 제공하는 인간적·사회적 경험은 여전히 중요하다고 말한다. 또한 디자인 시스템과 도구 체인은 창의성을 제한하는 규칙이 아니라 반복 작업을 줄이고 더 중요한 문제에 집중하게 하는 기반이라고 강조한다. ### 하이브리드 근무가 확장한 인재의 범위 - 코로나19 이전부터 Microsoft는 특정 지역에 한정되지 않은 인재 확보의 필요성을 인식하고 있었다. - 인도, 중국, 애틀랜타, 노르웨이 등 다양한 지역에 뛰어난 디자인 인재가 존재하며, 반드시 본사 근처로 이주해야 할 이유는 없다고 보았다. - 뉴욕에 있는 사람이 워싱턴주 레드먼드의 직원보다 더 큰 영향력을 낼 수 있다면, 지역을 이유로 승진이나 참여 기회를 제한해서는 안 된다는 관점이 제시된다. - 팬데믹은 새로운 가능성을 만든 것이라기보다, 기존에 검토하던 원격 근무 방식을 실제 운영에 적용하도록 가속했다. ### 디지털 협업 도구와 평등한 참여 - Microsoft의 경험상 Teams, Figma 같은 도구를 활용한 협업이 일부 대면 상황보다 더 효과적일 수 있다. - 디지털 도구는 조직 내 직급이나 물리적 위치의 영향을 덜 받는 비계층적 환경을 제공한다. - 그 결과 회의실에서 발언권을 얻기 어려운 사람도 자신의 의견을 더 쉽게 공유할 수 있고, 팀 구성원 모두가 동등하게 참여할 가능성이 커진다. - 다만 앞으로는 “대면 만남은 무엇을 위해 필요한가”와 “어떤 상황에서 대면 방식을 선택해야 하는가”를 구분해야 한다. ### 대면 만남이 제공하는 인간적 경험 - 온라인 환경에서도 우연한 대화나 비공식적 만남은 가능하지만, 대면 만남을 완전히 대체하기는 어렵다. - 사람은 표정, 몸짓, 옷차림, 움직임 등 시각적·비언어적 신호를 통해 상대를 이해한다. - 화상회의에서는 얻기 어려운 이런 정보가 관계 형성과 신뢰 구축을 돕는다. - 따라서 하이브리드 근무의 목표는 대면을 없애는 것이 아니라, 온라인 협업과 대면 활동을 각각 가장 효과적인 상황에 사용하는 것이다. ### 디자인 시스템은 창의성을 제한하지 않는다 - 디자인 시스템을 도입하려면 개인의 산출물보다 협업과 일관성을 중시하는 방향으로 조직 문화를 바꾸어야 하며, 이런 변화에는 수년이 걸릴 수 있다. - 처음에는 디자이너가 모든 픽셀을 직접 설계하고 싶어 하는데 공통 시스템을 사용하라고 요구하는 것이 창의성을 억누르는 것처럼 보일 수 있다. - 그러나 잘 만들어진 디자인 시스템은 규칙을 강제하는 장치가 아니라, 이미 검증된 요소를 재사용해 불필요한 반복을 줄이는 기반이다. - 기본적인 구조와 컴포넌트가 마련되면 디자이너는 더 중요한 사용자 문제와 새로운 해결책에 집중할 수 있다. - 일관된 시스템은 제품 간 연결성을 높이고, 팀이 매번 같은 문제를 처음부터 다시 해결하지 않도록 한다. ### Figma와 Teams가 만드는 도구 생태계 - Figma에서 소프트웨어를 설계하면서 Teams의 영상 통화와 채팅을 동시에 사용하면, 디자인 작업과 논의를 하나의 흐름으로 연결할 수 있다. - 협업은 실시간으로 함께 작업하는 방식뿐 아니라, 각자가 다른 시간에 작업하고 의견을 남기는 비동기 방식으로도 가능하다. - Teams는 Microsoft 내부 도구에만 머무르지 않고 외부 기업과 제3자 개발자가 좋은 제품을 만들 수 있도록 지원하는 플랫폼 역할을 지향한다. - Figma의 디자인 기능과 Teams의 커뮤니케이션 기능을 결합하면, Microsoft가 개인별로 따로 만드는 조직에서 함께 구축하는 조직으로 전환하는 데 도움이 된다. ### 실용적인 결론 하이브리드 협업을 성공시키려면 원격 도구를 도입하는 데 그치지 말고, 지역과 직급에 관계없이 참여할 수 있는 문화와 프로세스를 함께 설계해야 한다. 반복 작업은 디자인 시스템과 통합 도구로 줄이고, 관계 형성·신뢰 구축처럼 디지털 환경이 대체하기 어려운 활동은 의도적으로 대면에서 진행하는 방식이 효과적이다.

figma

제작 비하인드: 개발 (새 탭에서 열림)

개빈 맥팔랜드는 사용자들이 겪는 불편에서 아이디어를 얻어 Figma 플러그인과 FigJam 위젯을 개발해 왔다. 대표작인 Table Creator와 테이블 위젯은 FigJam을 떠나지 않고 표 데이터를 생성·관리하도록 돕는다. 그는 단순한 API 실험에서 출발했지만, 실시간 협업과 대규모 데이터 처리 같은 문제로 관심을 확장하며 도구가 팀의 생산성과 협업을 높여야 한다고 강조한다. ## 사용자 문제에서 출발한 개발 - 개빈은 사용자 중심 디자인을 바탕으로 기업의 디지털 전환을 돕는 프리랜서 디자인 컨설턴트다. - 친구와 가족의 웹사이트를 제작하던 경험에서 시작해, 새로운 기술과 작업 방식을 꾸준히 시도해 왔다. - 트위터에서 “Figma에서 표를 더 쉽게 만들고 싶다”는 요청을 본 것이 플러그인 개발의 계기가 됐다. - Figma의 `Rectangle Creator` 예제를 수정해 표 생성 기능을 만들었고, 이를 **Table Creator**라는 첫 플러그인으로 출시했다. - 해당 플러그인은 수만 명이 사용할 정도로 확산됐다. ## FigJam용 테이블 위젯 - 첫 플러그인 개발 경험을 바탕으로 FigJam용 테이블 위젯을 제작했다. - 위젯의 주요 기능은 다음과 같다. - 행과 열 추가 - 데이터 가져오기 - 열 기준 정렬 - 표의 디자인과 구조 조정 - 별도의 도구로 이동하지 않고 FigJam 작업 공간에서 표 데이터를 바로 확인하고 활용할 수 있도록 설계됐다. - 디자인 작업, 협업 회의, 데이터 정리 등 표 형식의 정보를 사용하는 다양한 팀을 대상으로 한다. ## 예제 코드로 시작한 개발 방식 - 처음에는 FigJam 위젯의 `notepad` 예제를 수정하며 API 동작을 단계적으로 익혔다. - 간단한 변경을 반복하면서 위젯의 구조와 동작 방식을 파악했다. - 기존에 익숙하지 않았던 JSX 코드도 개발 과정에서 학습했다. - 기본적인 사용법을 이해한 뒤 행과 열을 표시하고, 여러 레이아웃과 디자인을 실험했다. - 완성된 설계에서 시작하기보다 작은 프로토타입을 빠르게 수정하는 방식으로 기능을 발전시켰다. ## 단순한 기능에서 협업 문제로 확장 - 처음에는 위젯 API를 익히기 위한 연습 프로젝트였지만, 팀 협업을 개선할 수 있는 도구로 발전했다. - 여러 사용자가 같은 표를 동시에 편집할 때 발생하는 문제에 관심을 갖게 됐다. - 특히 다음과 같은 과제가 중요하다고 보았다. - 다른 사용자가 같은 표를 편집 중임을 어떻게 표시할 것인가 - 실시간 멀티플레이어 상호작용을 어떻게 설계할 것인가 - 대량의 데이터를 다루면서도 인터페이스가 느려지지 않게 하려면 어떻게 해야 하는가 - 시각적 디자인과 기술적 구현을 함께 고민해야 한다는 점이 개발의 매력으로 작용했다. ## 영감과 개발자 커뮤니티 - 영감은 사람들이 디자인 과정에서 어떤 부분을 어렵게 느끼는지 관찰하는 데서 얻는다. - Friends of Figma Slack 그룹에서 사용자들의 요구와 작업상의 불편을 파악한다. - 플러그인 개발자 커뮤니티에도 적극적으로 참여하며 다른 제작자들과 아이디어와 개선 방법을 공유한다. - 사용자 피드백과 개발자 간 협업을 통해 실제 업무 문제를 해결하는 기능을 찾으려 한다. ## 생산성과 협업을 위한 도구 - 위젯을 사용하는 사람들이 더 생산적으로 일하고, 중요한 문제에 집중하기를 기대한다. - 개인의 작업 속도 향상뿐 아니라 팀원 간 협업을 더욱 긴밀하게 만드는 것이 목표다. - 개빈에게 좋은 도구란 기능을 추가하는 데 그치지 않고, 사람들이 일상적으로 겪는 문제를 함께 해결하도록 돕는 도구다. - 이후에도 Figma 플러그인인 **Node Decoder**를 만드는 등 새로운 개발 작업을 이어가고 있다. 사용자들이 반복적으로 겪는 불편을 관찰하고, 작은 예제에서 출발해 실제 협업 환경에 필요한 기능으로 확장한 점이 이 사례의 핵심이다. Figma·FigJam 플러그인을 개발할 때도 기능 자체보다 사용자의 작업 흐름, 실시간 협업, 데이터 규모와 성능을 함께 고려하는 것이 중요하다.

figma

브랜칭을 만든 방법 (새 탭에서 열림)

Figma는 대규모 협업에서 실험적 변경과 승인된 디자인을 분리하기 위해 브랜칭을 구축했다. 메인 파일은 단일 진실 공급원으로 유지하고, 브랜치에서는 기존 디자인을 훼손하지 않으면서 아이디어를 탐색·검토·수정할 수 있도록 한 것이다. Figma는 소프트웨어 개발의 브랜치 개념을 그대로 복제하기보다, 클라우드 기반 멀티플레이어 협업에 맞춰 단순성과 일관성을 우선했다. ## 대규모 협업에서 자유와 구조의 균형 - 실시간 협업은 모든 사람이 같은 파일에서 작업할 수 있다는 장점이 있다. - 그러나 팀 규모가 커지면 다음과 같은 문제가 발생한다. - 승인되지 않은 변경 사항이 코드에 반영됨 - 작업 내용이 다른 사람에 의해 덮어써짐 - 진행 중인 작업(WIP)과 실제 배포 가능한 디자인을 구분하기 어려움 - 브랜치는 메인 파일을 직접 변경하지 않고 새로운 아이디어를 시도할 수 있는 탐색 공간이다. - 디자인 라이브러리에 기여하거나, 이해관계자에게 작업물을 미리 보여주거나, 실험적인 반복 작업을 진행할 때 특히 유용하다. - 충분히 검토·승인된 변경만 메인 파일에 반영함으로써 메인 파일의 무결성을 유지한다. ## 소프트웨어 브랜칭과 Figma의 차이 - 소프트웨어 개발의 브랜치는 일반적으로 변경 사항이 개발자의 로컬 컴퓨터에 저장되는 구조를 전제로 한다. - 반면 Figma 파일은 클라우드에 저장되며, 여러 사용자가 동시에 같은 파일에 접속해 변경한다. - 따라서 Figma는 다음과 같은 설계 문제를 검토해야 했다. - 메인 파일에서 여러 사용자의 동시 편집을 계속 허용할 것인가 - 브랜치에서도 여러 사람이 동시에 작업할 수 있게 할 것인가 - 기존 멀티플레이어 협업 경험에 복잡성을 얼마나 추가할 것인가 - 핵심 과제는 전통적인 버전 관리 방식을 그대로 적용하지 않고, 온라인 협업 환경에 맞는 브랜칭 모델을 만드는 것이었다. ## 단순성과 일관성을 우선한 설계 - Figma는 브랜칭과 멀티플레이어 편집을 하나의 일관된 버전 관리 방식으로 이해할 수 있도록 설계했다. - 메인 파일은 기존처럼 여러 사람이 동시에 편집할 수 있다. - 브랜치도 일반적인 Figma 파일과 동일한 방식으로 작동한다. - 편집자와 뷰어의 접근 권한 및 권한 관리 방식은 변경하지 않았다. - 사용자의 데이터가 어떤 상황에서도 안전하게 보존되도록 데이터 무결성을 우선했다. - 기능을 의도적으로 단순하게 유지하기 위해 브랜치에서 다시 브랜치를 만드는 기능은 제공하지 않았다. - 이는 기능을 많이 추가하기보다, 디자이너가 별도의 복잡한 개념을 학습하지 않고 사용할 수 있게 하려는 선택이다. ## 병합 과정에서 고려한 예외 상황 - 병합의 가장 어려운 문제는 단순히 충돌을 해결하는 것만이 아니다. - 실제 구현에서는 다음과 같은 상황도 처리해야 했다. - 사용자가 병합 내용을 검토하는 동안 원본 파일이 변경되는 경우 - 병합 작업 도중 네트워크 연결이 끊기는 경우 - 병합이 완료되기 전에 다른 사용자의 변경 사항이 추가되는 경우 - 따라서 병합 기능은 충돌 해결 알고리즘뿐 아니라, 검토 중인 상태의 일관성, 연결 손실, 동시 변경에도 사용자의 데이터가 안전하게 유지되도록 설계되어야 했다. - 제공된 글은 이러한 병합 문제를 설명하던 중 문장이 중단되어 있어, 구체적인 해결 방식 전체는 확인할 수 없다. 브랜칭은 메인 파일을 무분별한 실험의 공간으로 사용하는 대신, 승인된 결과와 진행 중인 작업을 분리하고 싶은 팀에 적합하다. 특히 디자인 시스템이나 제품 디자인을 여러 사람이 함께 관리한다면, 메인 파일은 안정적인 기준점으로 유지하고 브랜치에서 탐색·리뷰·협업한 뒤 승인된 변경만 병합하는 운영 방식을 추천할 수 있다.

figma

Figma의 새로운 소식: (새 탭에서 열림)

Figma는 원격 협업에서도 즉흥적인 대화와 팀의 반응을 자연스럽게 주고받을 수 있도록 Figma와 FigJam에 오디오, 커서 채팅, 하이파이브 기능을 추가했습니다. 또한 스프레드시트 연동, 다이어그램 내보내기, 텍스트 편집, 붙여넣기 개선 등 실무 흐름을 간소화하는 기능도 함께 선보였습니다. 이번 업데이트의 결론은 디자인 작업과 커뮤니케이션을 별도 도구로 분리하지 않고 하나의 협업 환경 안에서 처리하도록 만드는 것입니다. ## 오디오로 실시간 협업 강화 - Figma와 FigJam 파일 안에서 버튼 한 번으로 팀원과 음성 대화를 시작할 수 있습니다. - 아이디어를 빠르게 공유하거나 질문하고, 작업 세션을 진행하거나 결과물을 발표하는 용도로 활용할 수 있습니다. - 별도의 화상회의 도구로 이동하지 않아도 파일을 보며 대화할 수 있어 협업의 흐름이 끊기지 않습니다. - Figma 데스크톱 앱에서는 오디오 내용을 실시간으로 보여주는 라이브 캡션 베타도 출시될 예정입니다. ## 커서 채팅과 하이파이브 - **커서 채팅**을 사용하면 각자의 커서에 짧은 메시지를 표시할 수 있습니다. - 발표자를 방해하지 않고 질문이나 의견을 남길 수 있습니다. - 격려나 간단한 반응을 전달하는 가벼운 커뮤니케이션 수단입니다. - **하이파이브**는 FigJam에서 협업을 마무리하거나 좋은 아이디어를 축하할 때 사용할 수 있는 반응 기능입니다. - 화상회의에서 놓치기 쉬운 고개 끄덕임이나 표정 같은 비언어적 반응을 디지털 작업 공간에 추가하려는 목적입니다. ## FigJam의 스프레드시트 데이터 연동 - 스프레드시트의 셀을 복사해 FigJam에 붙여넣으면 여러 셀을 스티키 노트로 변환할 수 있습니다. - 사용자 조사 결과나 인터뷰 데이터를 빠르게 시각화하고 정리하는 데 유용합니다. - FigJam의 스티키 노트 선택 영역은 CSV 파일로 내보낼 수 있어 후속 분석이나 데이터 공유가 가능합니다. ## FigJam 다이어그램 내보내기 - 선택한 객체 또는 전체 FigJam 파일을 PNG, PDF, JPG 형식으로 내보낼 수 있습니다. - FigJam에서 만든 다이어그램과 시각 자료를 프레젠테이션, 이메일, 문서 등 다른 커뮤니케이션 채널에 재사용할 수 있습니다. ## 텍스트 편집 기능 개선 - 글머리 기호 및 번호 매기기 목록의 줄 간격을 조정할 수 있습니다. - FigJam의 하나의 텍스트 상자, 스티키 노트, 도형 안에서 일부 문장이나 특정 줄만 선택해 서로 다른 글자 크기를 적용할 수 있습니다. - 이를 통해 긴 메모나 워크숍 결과물을 더 계층적으로 구성할 수 있습니다. ## 붙여넣기 작업 개선 - **Paste here**: 마우스 오른쪽 메뉴에서 선택하면 원하는 위치에 정확하게 붙여넣을 수 있습니다. - **Paste to replace**: 객체를 선택한 뒤 `Shift + ⌘ + V` 또는 `Shift + Ctrl + V`를 사용하면 클립보드의 콘텐츠로 해당 객체를 교체할 수 있습니다. - **Multi-paste**: 여러 프레임이나 그룹을 선택한 상태에서 `Shift + ⌘ + V` 또는 `Shift + Ctrl + V`를 사용하면 같은 콘텐츠를 동일한 위치에 한 번에 붙여넣을 수 있습니다. 이번 업데이트는 원격 환경에서 부족해진 즉각적인 소통을 보완하면서, 조사 데이터 정리와 시각 자료 재사용까지 Figma 생태계 안에서 처리하도록 개선한 사례입니다. 특히 사용자 조사에는 스프레드시트-스티키 노트 변환을, 반복적인 화면 수정에는 붙여넣기 기능을 활용하면 작업 시간을 줄일 수 있습니다.