multiplayer-collaboration

6 개의 포스트

figma

캔버스, 코드를 만나다 (새 탭에서 열림)

Figma의 코드 레이어는 디자인 캔버스와 실제 코드를 하나의 작업 공간에서 결합하려는 시도다. React 기반 코드를 일반 Figma 레이어처럼 이동·복제·리사이즈하고, AI 또는 내장 IDE로 편집할 수 있게 해 디자인의 자유로운 탐색성과 코드의 강력한 기능을 함께 제공한다. 이를 위해 Figma는 캔버스 모델, 웹 기반 코드 편집기, 디자이너와 개발자의 협업 방식을 통합하는 하이브리드 접근법을 택했다. ## 디자인 캔버스와 코드의 충돌 - Figma 캔버스는 객체를 자유롭게 배치하고 수정하는 2D 공간이다. - 반면 코드는 디렉터리와 파일로 구성된 계층적 파일 시스템을 전제로 한다. - 이 차이 때문에 다음과 같은 문제가 발생한다. - 캔버스에서 코드 레이어를 복제하면 새 인스턴스를 만들 것인지, 코드의 분기본을 만들 것인지 결정해야 한다. - 코드의 원본이 캔버스인지 파일 시스템인지 명확히 해야 한다. - 시각적 레이어와 실제 코드 파일의 위치를 어떻게 연결할지 정해야 한다. - Figma는 코드의 구조를 캔버스에 그대로 강요하기보다, 코드가 Figma의 공간적 작업 방식에 맞도록 설계했다. ## 코드를 새로운 캔버스 기본 요소로 구현 - 코드 레이어는 일반 레이어처럼 다음 작업을 지원한다. - 자유로운 이동과 크기 조절 - 부모 레이어 변경 - 오토 레이아웃 스택에 배치 - 다른 레이어와 동일한 방식의 중첩 - 코드 레이어를 복제하면 별도의 코드 포크가 생성된다. - 따라서 Git 브랜치를 따로 만들지 않고도 `Option` 키를 누른 채 드래그해 여러 코드 버전을 나란히 비교할 수 있다. - 이러한 방식은 디자인에서 흔한 빠른 복제와 실험, 버전 비교를 코드에도 적용한다. ## React와 Figma 컴포넌트의 결합 - Figma는 컴포넌트 모델과 React의 컴포넌트 모델이 유사하다는 점에서 React를 선택했다. - 두 시스템 모두 재사용 가능한 구성 요소를 조합해 화면과 애플리케이션을 만든다. - React의 props는 Figma의 컴포넌트 속성과 연결된다. - 개발자가 코드에서 속성을 정의하면 디자이너는 Figma 화면에서 다음과 같은 컨트롤로 값을 조정할 수 있다. - 토글 - 슬라이더 - 드롭다운 - 결과적으로 코드 컴포넌트도 일반 Figma 컴포넌트처럼 시각적으로 재사용하고 변형할 수 있다. ## AI와 직접 편집을 함께 지원하는 IDE - 코드 레이어는 AI만으로 생성하고 수정할 수 있지만, 사용자가 직접 코드를 편집할 수 있는 환경도 필요했다. - Figma는 웹 기반의 내장 IDE를 만들기 위해 CodeMirror를 핵심 편집 엔진으로 채택했다. - CodeMirror의 확장 구조를 활용해 다음 기능을 제공할 수 있다. - 색상 테마 - 찾기 및 바꾸기 - 줄 번호 - Figma 환경에 맞춘 편집 동작 - 기본 편집기의 실행 취소·다시 실행 동작은 Figma의 자체 멀티플레이어 undo 스택과 통합하기 위해 교체했다. - 이를 통해 코드 편집도 Figma의 다른 작업과 일관된 협업 및 실행 취소 경험을 제공하도록 했다. ## 코드 레이어 설계에서 해결해야 할 세 가지 과제 - Figma는 코드 레이어를 구축하며 다음 문제를 핵심 과제로 삼았다. - 코드 레이어와 컴포넌트를 기존 Figma 생태계에 자연스럽게 통합하기 - 강력하면서도 쉽게 사용할 수 있는 웹 IDE 제공하기 - 디자이너와 개발자가 동시에 작업할 수 있는 멀티플레이어 협업 지원하기 - 전체 방향은 코드의 엄격한 구조를 그대로 가져오는 것이 아니라, Figma의 시각적이고 실험적인 작업 방식을 유지하면서 코드의 표현력을 추가하는 데 있다. 코드 레이어는 디자인 파일 안에 단순히 코드를 삽입한 기능이 아니라, 코드를 Figma의 레이어와 컴포넌트 모델에 맞춰 재구성한 기능이다. 디자인을 한 번의 클릭으로 코드 레이어로 바꾸고, AI나 직접 코딩으로 상호작용을 추가할 수 있으므로 디자이너와 개발자가 같은 캔버스에서 더 빠르게 실험할 수 있다는 점이 핵심이다.

figma

디자이너와 개발자를 직장에서 (새 탭에서 열림)

디자이너와 개발자의 직장 만족도는 조직 내 디자인의 위상, 하이브리드 근무 정책, 리더십, 협업과 커뮤니케이션에 크게 좌우된다. 설문 응답자의 41%는 전년보다 직장 만족도가 높아졌으며, 명확한 근무 제도와 자율성, 디자인·개발 간 긴밀한 협업이 긍정적인 업무 경험을 만든다. 특히 디자인을 단순한 지원 기능이 아니라 전략적 파트너로 대우하는 조직일수록 구성원의 만족도가 높아진다는 것이 글의 결론이다. ## 조사 개요와 전반적인 만족도 - Figma는 디자이너와 개발자 943명을 대상으로 제품 개발 방식과 업무 경험을 조사했다. - 응답자의 41%가 전년보다 직장 만족도가 높아졌다고 답했다. - 글은 업무 만족도에 영향을 주는 다섯 가지 요인을 소개하며, 조직·관리자·개인이 각각 어떤 환경을 만들어야 하는지 설명한다. - 제공된 본문에는 네 번째 요인까지 수록되어 있으며, 다섯 번째 요인의 내용은 포함되어 있지 않다. ## 디자인의 조직 내 위상 - 디자인을 단순히 요청받은 결과물을 제공하는 서비스 조직이 아니라 전략적 파트너로 인정하면 디자이너의 만족도가 높아진다. - 디자인이 전략 수립에 참여하면 고객 중심성을 강화하고, 디자이너가 제품과 사업에 실질적인 영향을 미칠 수 있다. - 디자이너는 탐색과 실행 사이의 균형을 보여 주어야 한다. - Wise는 다음과 같은 “현재·다음·미래” 원칙을 제시한다. - 현재 제공할 결과물에 70%의 시간 사용 - 다음 단계의 과제에 20% 사용 - 장기적인 미래 탐색에 10% 사용 - 탐색 단계가 지나치게 길어지면 실행력이 부족하다는 인상을 줄 수 있으므로, 창의적인 발견과 구체적인 납품 일정을 함께 관리해야 한다. ## 하이브리드 근무 정책 - 응답자의 97%는 적어도 일부 기간 원격으로 근무하며, 절반 이상은 대부분 또는 완전히 원격으로 일한다. - 어디서 일하는지가 업무 자체만큼 직장 만족도에 중요한 요소가 됐다. - 모든 조직에 동일한 하이브리드 정책을 적용하는 방식은 효과적이지 않을 수 있다. - 출근 요일과 장소가 불명확하면 특정 요일에만 사무실이 붐비고 좌석이나 회의실이 부족해지는 문제가 발생한다. - 완전 원격, 완전 출근, 유연한 하이브리드 중 어떤 방식을 선택하든 다음 사항을 명확히 해야 한다. - 출근이 필요한 상황 - 협업을 위한 공통 시간대 - 사무실 이용 방식 - 성과를 평가하는 기준 ## 리더의 자율성 부여와 지원 - 관리자는 팀의 실제 업무 상황을 파악하고 필요한 지원과 의사결정을 제공해야 한다. - 좋은 리더는 구성원마다 필요한 지원 방식이 다르다는 점을 이해한다. - 근무 시간이나 장소를 일률적으로 통제하기보다 결과물의 품질과 영향력을 중심으로 평가하는 접근이 효과적이다. - 리더는 팀이 최선의 결과를 내도록 지원하는 동시에, 좋은 성과가 적절히 인정되고 보상되도록 해야 한다. - 자율성을 주되 목표와 기대 수준은 분명히 제시해야 한다. ## 디자인·개발 협업과 커뮤니케이션 - 직장 만족도가 높은 디자이너 중 69%는 개발자와의 협업이 효과적이거나 매우 효과적이라고 평가했다. - 만족도가 높은 개발자일수록 디자이너와 더 자주 협업하는 경향이 있다. - 디자이너의 84%는 개발자와 최소 주 1회 협업한다. - 화이트보드와 협업형 디자인 도구는 여러 사람이 동시에 아이디어를 공유하고 작업할 수 있게 해 협업을 촉진한다. - 그러나 개발자의 91%, 디자이너의 92%는 협업 프로세스에 여전히 개선의 여지가 있다고 답했다. - 협업 불일치의 원인으로 개발자 중 47%는 디자이너가 엔지니어링의 제약과 관점을 충분히 이해하지 못하는 점을 지적했다. - 따라서 효과적인 협업을 위해서는 단순한 도구 도입을 넘어 다음이 필요하다. - 초기 단계부터 디자이너와 개발자가 함께 논의하기 - 기술적 제약과 사용자 요구를 상호 공유하기 - 정기적인 피드백과 의사결정 과정 마련하기 - 결과물보다 문제 정의와 목표를 먼저 합의하기 조직은 디자인을 전략적 의사결정에 참여시키고, 근무 방식과 성과 기준을 명확히 하며, 디자이너와 개발자가 자주 협업할 수 있는 환경을 만들어야 한다. 개인과 팀 차원에서는 탐색과 실행의 균형을 유지하고, 도구뿐 아니라 서로의 업무 맥락과 제약을 이해하는 데 집중하는 것이 실용적인 개선책이다.

figma

점진적 프레임 로 (새 탭에서 열림)

Figma는 프로토타입 전체를 메모리에 올리던 기존 방식을 버리고, 현재 화면과 곧 이동할 수 있는 화면만 단계적으로 불러오는 ‘증분 프레임 로딩’을 도입했습니다. 이를 통해 대형 프로토타입의 초기 로딩 시간을 줄이고, 특히 메모리가 제한된 모바일 환경에서 발생하던 앱 종료와 충돌을 완화했습니다. 핵심은 필요한 문서 트리 일부만 실시간으로 구독하고, 사용자의 탐색에 따라 구독 범위를 확장하는 것입니다. ## 전체 프로토타입 로딩의 한계 - 초기 프로토타이핑 기능은 프로토타입이 포함된 문서 전체를 메모리에 로드한 뒤 첫 화면을 표시했습니다. - Figma 문서가 커지면서 페이지, 디자인 시스템, 컴포넌트 변형 수가 급증했고 프로토타입도 함께 대형화되었습니다. - iPhone을 비롯한 모바일 기기는 데스크톱보다 메모리 여유가 적습니다. - 운영체제가 애플리케이션의 메모리 사용량 증가를 허용하지 않고 프로세스를 종료하면서 모바일 프로토타입 충돌이 잦아졌습니다. - 전체 데이터를 다운로드하고 메모리에 보관하는 방식은 로딩 시간과 메모리 사용량을 동시에 악화시켰습니다. ## 증분 프레임 로딩 전략 - 증분 로딩은 파일 전체가 아니라 새로 필요하거나 변경된 데이터 일부만 로드하는 방식입니다. - Figma는 이 개념을 프로토타입 화면 단위에 적용해 ‘증분 프레임 로딩’이라고 명명했습니다. - 현재 화면을 표시하는 데 필요한 데이터만 내려받고 메모리에 유지합니다. - 사용자가 처음 보는 화면과 해당 화면에서 프로토타입 인터랙션으로 바로 이동할 수 있는 인접 화면을 우선 로드합니다. - 사용자가 다음 화면으로 이동하면 새 화면과 그 화면에서 접근 가능한 인접 화면을 추가로 로드합니다. - 이미 본 화면은 사용자가 뒤로 이동할 수 있으므로 메모리에 계속 유지합니다. ## Time to Interactive 최적화 - 목표는 페이지 전체가 완전히 로드되는 시간이 아니라, 사용자가 유용한 화면을 보고 빠르게 클릭·탐색할 수 있게 되는 시간인 TTI(Time to Interactive)를 줄이는 것입니다. - 첫 화면과 즉시 이동 가능한 화면만 준비하면 사용자는 전체 프로토타입이 로드되기 전에 상호작용을 시작할 수 있습니다. - 이후 화면은 사용자의 탐색 흐름에 맞춰 지연 로딩되므로 초기 표시를 위해 기다려야 하는 데이터 양이 줄어듭니다. ## 실시간 공동 편집과 부분 동기화 - Figma 파일은 다른 사용자가 편집할 때 변경 사항이 활성 사용자에게 실시간으로 동기화되어야 합니다. - 기존 시스템은 파일 전체를 서버의 실시간 데이터 저장소와 연결해 업데이트를 전달했습니다. - 부분 로딩을 지원하기 위해 Figma는 파일의 특정 부분만 조회할 수 있는 기능을 추가했습니다. - 클라이언트는 문서 트리에서 구독할 하위 트리를 `query` 메시지로 요청합니다. - 서버는 해당 하위 트리의 현재 상태를 `reply` 메시지로 전달하고 요청이 처리되었음을 확인합니다. - 이후 구독 범위 안에서 변경이 발생하면 서버는 `changes` 메시지를 통해 업데이트를 전송합니다. ## 문서 트리 구독 프로토콜 - 특정 노드 `a`를 구독하면 해당 노드뿐 아니라 조상 노드와 모든 자손 노드도 구독 대상으로 취급됩니다. - 클라이언트가 `a`를 요청하면 서버는 `a`의 현재 콘텐츠와 함께 요청 완료 응답을 보냅니다. - 구독한 노드의 속성이 변경되면 변경 사항이 클라이언트로 전달됩니다. - 다른 노드 `y`가 `a` 아래로 이동하면 서버는 `a`의 구독 범위에 새로 들어온 `y`의 존재를 전달합니다. - 반대로 `c`가 `x` 아래로 이동하고 클라이언트가 `x`의 자손을 구독하지 않는다면, 클라이언트에는 `c`가 구독 범위에서 제거되었다는 변경 사항이 전달됩니다. - 따라서 클라이언트는 파일 전체가 아니라 현재 관심 영역에 해당하는 문서 트리만 유지하면서도 실시간 상태를 일관되게 관리할 수 있습니다. ## 실용적인 결론 대규모 문서나 프로토타입을 다루는 애플리케이션에서는 전체 데이터 선로드보다 사용자 행동을 기준으로 한 부분 로딩이 효과적입니다. 특히 초기 상호작용에 필요한 최소 데이터만 먼저 제공하고, 탐색 경로에 따라 인접 데이터를 미리 가져오며, 실시간 동기화 역시 구독 단위로 제한하는 설계가 로딩 성능과 메모리 안정성을 함께 개선할 수 있습니다.

figma

피그마의 20 (새 탭에서 열림)

2023년을 돌아보며 Figma가 출시한 제품과 조직·업무에 관한 생각을 정리한 연말 회고 글이다. 글의 중심 주장은 협업을 단순한 업무 전달이나 최적화된 절차가 아니라, 서로 다른 역할이 지속적으로 대화하고 함께 문제를 해결하는 과정으로 봐야 한다는 것이다. Dev Mode와 FigJam AI는 이러한 협업을 강화하기 위한 도구로 소개되며, 인간 간 연결과 기술의 발전을 함께 추구해야 한다는 결론으로 이어진다. ## 2023년을 관통한 두 가지 흐름 - 2023년은 한편으로는 AI가 세상을 바꾼 해였고, 다른 한편으로는 팬데믹 이후 사람들이 다시 직접 연결되기 시작한 해로 묘사된다. - 이 두 흐름은 모순처럼 보이지만, Figma는 오히려 기술이 인간 간의 관계와 협업을 더 의미 있게 만들어야 한다고 본다. - 복잡한 세계와 자신의 생각을 이해하기 위해서는 다른 사람과의 상호작용이 필수적이라는 관점이 글 전체를 관통한다. ## ‘핸드오프’에서 지속적인 협업으로 - 제품 개발에서 핸드오프는 디자이너가 개발자에게 결과물을 넘기는 일회성 전달을 뜻하는 경우가 많았다. - 이 과정은 때때로 “벽 너머로 작업물을 던지는 것”처럼 변질되어, 디자이너와 개발자가 서로 다른 공간에서 일하는 문제를 만들었다. - Figma는 미식축구의 핸드오프처럼, 다음 담당자에게 공을 넘긴 뒤에도 플레이가 이어지는 협력적 과정으로 재해석한다. - 디자이너와 개발자는 서로 다른 관점을 갖지만 강하게 의존하는 관계이므로, 같은 작업 공간에서 지속적으로 의견을 주고받아야 한다. - 이러한 방식은 반복 작업과 피드백을 빠르게 하고, 각자의 강점을 살리며, 제품의 목표를 더 명확하게 만든다. ## Dev Mode와 개발자 관점의 디자인 도구 - Figma는 개발자가 필요한 정보를 필요한 시점에 얻을 수 있도록 Dev Mode를 새로운 작업 공간으로 도입했다. - Dev Mode는 디자인 도구 안에 개발자의 관점을 추가해, 기존의 일방적인 디자인 전달 방식을 개선하려는 기능이다. - 글에서는 핸드오프를 일회성 “배턴 패스”가 아니라 지속적인 대화로 다루면 반복 속도가 빨라지고 결과물의 품질도 향상된다고 설명한다. - 목표는 디자이너와 개발자 사이의 ‘핸드오프 장벽’을 없애고, 두 역할이 같은 경기장에서 협업하도록 만드는 것이다. ## FigJam AI와 인간 중심의 협업 - Figma는 FigJam에 AI 기능을 추가해 아이디어 발상과 시각적 협업을 지원한다. - AI는 회의와 브레인스토밍의 준비 및 정리 같은 작업을 보조해, 사람들이 더 중요한 논의와 관계 형성에 집중하도록 돕는 역할을 한다. - Figma가 말하는 “진입 장벽을 낮추고 가능성의 상한을 높인다”는 방향은 초보자도 쉽게 사용하면서 숙련자는 더 많은 일을 할 수 있게 하는 것을 의미한다. - AI가 협업자를 대체한다기보다, 인간 사이의 연결과 의사결정을 강화하는 도구로 활용되어야 한다는 시각이 드러난다. ## 협업에는 도구뿐 아니라 조직적 연습이 필요하다 - 모든 사람이 같은 역할을 하거나 같은 방식으로 일하면 협업이 오히려 경직될 수 있다. - 반복되는 아이디어와 역할 집중은 팀의 창의성과 발전을 제한할 수 있으므로, 새로운 인재와 다양한 관점이 필요하다. - 좋은 협업은 도구 하나로 완성되지 않으며, 서로의 요구를 이해하고 함께 일하는 연습과 충분한 역량의 “깊은 벤치”가 필요하다. - 글의 후반부는 이러한 관점에서 제품 출시, AI 기능, 회의, 업무 언어, 커리어 전환, 기계식 키보드 등 2023년의 주요 주제를 회고한다. ## 글에서 다루는 회고 주제 - 2023년에 출시한 주요 기능과 제품 10가지 - AI 기능을 시장에 출시하기 위해 제품 관리자가 고려한 과정 - 기술에 대한 관심과 애정을 되찾기 위한 질문들 - 더 나은 회의를 만들기 위한 멀티플레이어 협업 방식 - Slack-lash, Toggle Tax 등 변화하는 업무 용어 - 커리어에서 전문적으로 방향을 전환하는 방법 - 기계식 키보드를 통한 업무의 즐거움 실무적으로는 디자인과 개발을 분리된 단계로 운영하기보다, Dev Mode 같은 공유 환경에서 초기부터 함께 검토하는 방식이 효과적이다. AI 역시 아이디어 정리와 반복 작업에 활용하되, 최종적인 판단과 의미 있는 대화는 사람이 담당하도록 설계하는 것이 글의 방향과 맞는다.

figma

변화하는 일의 방식, 우리가 (새 탭에서 열림)

팬데믹 이후 분산 근무와 디지털 협업은 일시적 현상이 아니라 업무의 기본 방식으로 자리 잡았다. 그러나 제품 개발에는 더 많은 사람이 참여하고, 팀은 물리적으로 분산되었으며, 동시에 진행되는 업무도 늘어나면서 정렬 부족·의사결정 지연·개발 주기 장기화가 심해졌다. 글은 이런 혼란을 줄이고 성과를 내는 팀의 차별점으로 투명성, 공유된 이해, 의도적인 연결을 제시한다. ## 분산 근무의 정착 - 유럽과 아시아 디자이너 대상 Figma 조사에서 **75%가 팬데믹 이전보다 재택근무를 더 자주 한다**고 답했다. - 미국의 재택근무 일수는 2019년보다 **약 5배 증가**했다. - 사무실 점유율과 대중교통 이용률 등은 팬데믹 이전으로 완전히 돌아가지 않았으며, 분산 근무는 장기적으로 지속될 가능성이 크다. - 협업은 회의실 중심에서 파일·문서·프레젠테이션에 커서와 아바타가 함께 나타나는 **‘멀티플레이어 업무’** 방식으로 확장되었다. ## 제품 개발을 어렵게 만드는 세 가지 변화 ### 더 많은 사람의 참여 - 과거에는 주로 디자이너와 엔지니어가 제품 개발을 이끌었다. - 현재는 데이터, 보안, 콘텐츠, 마케팅, 제품관리, 경영진 등 다양한 직무가 같은 프로젝트와 파일에 참여한다. - 참여자가 늘면서 전문성을 결합할 수 있다는 장점이 생겼지만, 이해관계 조정과 의사결정은 더 복잡해졌다. - 디지털 제품이 사업에서 차지하는 중요성이 커질수록 관련 역할과 검토 절차도 증가한다. ### 더 분산된 업무 - 지리적 장벽이 낮아져 세계 각지의 인재가 협업할 수 있게 되었다. - 반면 물리적 거리는 팀 사이의 정서적 거리로 이어질 수 있으며, 신뢰 형성이 어려워진다. - 과거의 “돌아다니며 관리하기”처럼 자연스럽게 상황을 파악하고 관계를 쌓는 방식이 Zoom, Teams, Slack만으로는 쉽게 대체되지 않는다. - 실시간 공동 편집과 단일 정보 출처는 효율적이지만, 알림·댓글·변경사항이 지나치게 많아지면 협업이 ‘협력적 혼란’으로 변할 수 있다. ### 더 많은 진행 중인 업무 - 웹사이트, 앱, 디지털 제품을 더 자주 업데이트해야 한다는 기대가 커졌다. - 여러 프로젝트와 버전이 동시에 진행되면서 팀의 주의력과 조정 비용이 증가한다. - 빠른 출시를 잘 활용하는 팀도 있지만, 일부 팀은 업무량과 복잡성 때문에 심각한 좌절을 겪는다. ## 제품 개발 과정의 주요 장애물 - Forrester Consulting 조사에서 **응답자 10명 중 9명**이 제품 개발 과정에서 어떤 형태로든 장애를 경험했다. - 특히 다음 세 가지 문제가 두드러졌다. - 팀 간 정렬 부족 - 의사결정의 어려움 - 긴 개발 주기 - 응답자 10명 중 6명은 이 세 가지 문제 중 하나 이상을 경험했다. - 이러한 문제는 새롭게 생긴 것이라기보다, 참여자 증가·분산 근무·동시 진행 업무 증가로 기존 문제가 증폭된 결과다. ## 성과가 높은 팀을 만드는 조건 - 혼란스러운 협업과 높은 성과를 가르는 요소는 다음 세 가지다. - **높은 수준의 투명성** - **팀 전체의 공유된 이해** - **의도적으로 설계된 연결과 관계 형성** - 모든 사람이 같은 파일에 접근하는 것만으로는 충분하지 않다. - 구성원들이 프로젝트의 맥락, 결정 이유, 현재 상태를 이해하고 서로 신뢰할 수 있어야 협업 도구의 효과가 나타난다. - 글은 이후 섹션에서 성공적인 제품·디자인 팀이 투명성을 어떻게 실천하는지 구체적으로 설명하려 한다. ## 실용적인 결론 분산된 환경에서는 협업 도구를 도입하는 것보다 **정보를 투명하게 공유하고, 결정의 맥락을 기록하며, 팀 간 공통 이해와 신뢰를 의도적으로 만드는 운영 방식**이 더 중요하다. 참여자가 많고 업무가 동시에 진행될수록 알림과 산출물을 늘리기보다, 누구나 현재 상태와 다음 결정을 명확히 파악할 수 있는 구조를 마련해야 한다.

figma

Shortcut 편집장의 편지를 소개 (새 탭에서 열림)

Figma는 새로운 블로그 **Shortcut**을 통해 제품 기능뿐 아니라, 아이디어가 만들어지고 발전하는 과정에 참여한 사람들의 이야기를 전하려 한다. 이 블로그는 Figma의 핵심 철학인 멀티플레이어 협업과 사용자·팀·커뮤니티의 상호작용을 콘텐츠 경험에도 적용해, 정적인 정보 전달을 넘어 발견과 영감을 유도하는 공간을 목표로 한다. ## Shortcut의 탄생 배경 - 모든 제품에는 이야기가 있으며, Shortcut은 새로운 아이디어가 현실화되는 과정에서 사람들이 겪는 우선순위 변화, 계획 수정, 시행착오를 다룬다. - Figma는 처음부터 웹 기반이자 멀티플레이어 제품으로 설계되었다. - 2015년에는 실시간 공동 편집이 오히려 디자이너들의 반감을 살 수 있다는 우려가 있었지만, 사용자들의 행동과 요구가 Figma의 발전 방향을 결정했다. - 따라서 Figma는 제품 자체뿐 아니라 사용자와 팀이 협업하고 문제를 해결하는 과정도 브랜드의 핵심 이야기로 본다. ## 게임과 ‘하우스 룰’에서 얻은 영감 - 글은 놀이가 사람을 이해하고 협력하는 지름길이 될 수 있다는 관점에서 Shortcut이라는 이름의 의미를 설명한다. - 사람들은 같은 게임도 서로 다른 방식으로 즐기며, 경험을 개선하기 위해 규칙을 수정하거나 새로운 ‘하우스 룰’을 만든다. - Figma 역시 사용자의 취향, 행동 방식, 필요에 따라 제품이 계속 변하고 확장된다는 점에서 이런 놀이의 특성과 닮아 있다. - 한 사람의 아이디어가 다른 사람의 수정과 참여를 거쳐 발전하는 과정이 Figma의 멀티플레이어 철학과 연결된다. ## 정적인 블로그에서 몰입형 경험으로 - 기존 블로그가 정적이고 일방향적인 콘텐츠 경험에 가까웠다면, 새 블로그는 더 생생하고 몰입감 있게 redesigned되었다. - Figma가 정적인 디자인 파일을 협업 가능한 캔버스로 바꾼 것처럼, 블로그도 독자가 탐색하고 발견할 수 있는 공간으로 바꾸려 했다. - 콘텐츠에는 글뿐 아니라 일러스트레이션, 모션 스터디, 영상 등 다양한 시각적 요소가 활용된다. - 이를 통해 독자가 단순히 글을 읽는 데 그치지 않고, Figma가 추구하는 창의성과 가능성을 직접 느끼도록 한다. ## 주제별 탐색과 새로운 콘텐츠 구성 - 독자는 디자인 시스템, 엔지니어링 등 주제별 카테고리로 글을 분류해 볼 수 있다. - 특정 주제를 묶은 큐레이션 컬렉션도 제공한다. - 주요 콘텐츠 유형은 다음과 같다. - 디자인 시스템의 미래를 다루는 기획 시리즈 - 제품 디자인과 개발의 역할 변화를 논하는 오피니언 - Figma의 기능과 제작 과정을 설명하는 비하인드 스토리 - 게임 산업에서 영감을 얻은 백엔드 엔지니어링 등 기술 심층 분석 - Figma를 활용한 음악가와 창작자의 실제 사례 - 외부 일러스트레이터와 작가들의 참여를 통해 다양한 관점과 표현 방식을 담았다. ## 입력이 출력으로 이어지는 커뮤니티 - Shortcut은 “하나의 아이디어가 또 다른 아이디어를 낳는” 양방향 영감의 구조를 지향한다. - 독자가 콘텐츠를 통해 새로운 시도를 하도록 자극하는 동시에, Figma 내부의 작가·디자이너·엔지니어·제품팀도 더 적극적으로 아이디어를 공유하기를 기대한다. - Figma의 가능성을 기능 설명만으로 전달하지 않고, 실제 사람과 팀의 작업 방식 및 창작 과정을 통해 보여주려 한다. - 궁극적으로 Shortcut은 읽는 공간을 넘어, 발견하고 영감을 얻고 함께 만들어가는 커뮤니티 경험을 목표로 한다. 실용적으로는 제품 사용법만 찾기보다 Shortcut의 사례·기술 글·큐레이션을 함께 살펴보면, Figma를 도구가 아닌 협업과 아이디어 발전을 위한 작업 방식으로 이해하는 데 도움이 된다.