techlist.io
KREN
figma

피그마의 멀티플레이어 (새 탭에서 열림)

postgresqlreal-time-collaborationrustwebsocketsoperational-transformationclient-server-architecture

Figma는 Google Docs처럼 복잡한 OT(Operational Transformation)를 적용하는 대신, 디자인 문서의 구조에 맞춘 단순한 자체 멀티플레이어 시스템을 구축했다. 클라이언트와 서버는 WebSocket으로 변경 사항을 동기화하고, 서버가 문서별 단일 조정자로 동작해 충돌을 관리한다. 이 방식은 실시간 협업뿐 아니라 오프라인 편집과 재접속까지 지원하면서도 Figma의 데이터 모델에 맞는 구현 단순성을 유지했다.

웹 기반 협업을 선택한 이유

  • 멀티플레이어 기능이 있으면 파일을 내보내거나 복사본을 이메일로 주고받고, 변경 사항을 수동으로 동기화할 필요가 없다.
  • 링크 하나만으로 여러 사람이 현재 디자인 상태를 확인할 수 있다.
  • 디자이너뿐 아니라 카피라이터, 개발자 등도 같은 문서에 참여할 수 있다.
  • 초기에는 실시간 협업이 “디자인을 망치는 기능”으로 여겨졌지만, 웹 생산성 도구에는 자연스러운 기본 기능이 되었다.

Figma의 클라이언트·서버 구조

  • 웹 클라이언트는 WebSocket을 통해 멀티플레이어 서버 클러스터와 통신한다.
  • 문서마다 별도의 서버 프로세스를 두고, 해당 문서를 편집하는 사용자들이 같은 프로세스에 연결된다.
  • 문서를 열 때 클라이언트가 먼저 파일 전체를 내려받는다.
  • 이후 변경 사항은 양방향 WebSocket 연결을 통해 실시간으로 전송된다.
  • 댓글, 사용자, 팀, 프로젝트 같은 데이터는 멀티플레이어 시스템이 아니라 Postgres와 별도 동기화 시스템으로 관리한다.
  • 문서 편집과 기타 애플리케이션 데이터는 성능, 오프라인 지원, 보안 요구 사항이 다르기 때문에 구현을 분리했다.

오프라인 편집과 재접속

  • 사용자는 네트워크가 끊긴 상태에서도 임의의 시간 동안 계속 편집할 수 있다.
  • 다시 온라인이 되면 클라이언트는 서버에서 최신 문서 사본을 받는다.
  • 그 위에 오프라인 동안 발생한 로컬 변경을 다시 적용한다.
  • 이후 새로운 WebSocket 연결을 통해 서버와 변경 사항을 계속 동기화한다.
  • 연결과 재연결 자체는 단순하게 만들고, 멀티플레이어의 핵심 복잡성은 이미 연결된 문서에 동시에 변경 사항이 들어오는 상황에 집중했다.

OT와 CRDT 대신 자체 방식을 택한 이유

  • OT는 Google Docs 등에서 널리 사용된 표준적인 협업 알고리즘이다.
  • 여러 사용자의 동시 작업을 변환해 충돌을 해결할 수 있지만, 구현과 검증이 복잡하다.
  • Figma는 텍스트 편집기와 달리 계층적인 디자인 객체를 편집하므로, 일반적인 OT 모델을 그대로 적용할 필요가 없다고 판단했다.
  • 스타트업으로서 빠르게 기능을 개발하고 실험하려면 더 단순한 구조가 유리했다.
  • Figma는 디자인 문서의 데이터 구조와 편집 패턴에 맞춘 전용 동기화 방식을 만들었다.

프로토타입을 통한 설계 검증

  • 실제 제품 코드에 바로 적용하지 않고, 여러 클라이언트와 서버를 시뮬레이션하는 별도의 웹 기반 실험 환경을 만들었다.
  • 프로토타입에서는 여러 사용자의 상태와 변경 사항을 시각적으로 확인할 수 있었다.
  • 오프라인 클라이언트, 느린 네트워크, 제한된 대역폭 등 다양한 상황을 쉽게 재현했다.
  • 이를 통해 협업 알고리즘과 데이터 구조를 빠르게 비교하고 실험했다.
  • 설계가 확정된 뒤 프로토타입에서 검증한 아이디어를 기존 코드베이스에 이식했다.

서버 중심의 동기화 모델

  • 하나의 문서에 연결된 사용자들은 같은 서버 프로세스를 공유한다.
  • 서버는 문서에 들어오는 변경 사항을 순서대로 처리하고 다른 클라이언트에 전달한다.
  • 클라이언트는 처음 받은 문서 상태를 기준으로 로컬 변경을 수행하면서 서버의 업데이트를 계속 반영한다.
  • 서버를 문서의 조정자로 두면 여러 클라이언트가 서로 직접 충돌을 해결할 필요가 줄어든다.
  • 동시에 발생한 변경의 처리 순서는 서버가 정하며, 모든 클라이언트가 최종적으로 같은 문서 상태에 도달하도록 한다.

이 접근법의 핵심 장점

  • 범용 협업 알고리즘보다 Figma의 객체 중심 데이터 모델에 맞게 단순하게 구현할 수 있다.
  • 온라인 편집뿐 아니라 오프라인 작업과 재접속도 지원한다.
  • 별도 프로토타입으로 다양한 장애 상황을 반복적으로 테스트할 수 있다.
  • 문서 편집 동기화와 서비스 메타데이터 동기화를 분리해 각각의 요구 사항에 맞게 최적화할 수 있다.

실용적으로는 모든 협업 애플리케이션이 OT나 CRDT를 그대로 도입해야 하는 것은 아니다. 데이터 구조가 명확하고 충돌 패턴이 제한적이라면, 서버 중심의 단순한 프로토콜과 충분한 시뮬레이션 테스트를 결합하는 편이 더 빠르고 유지보수하기 쉬울 수 있다.