client-server-architecture

2 개의 포스트

figma

Figma의 인프라: 웹 (새 탭에서 열림)

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

figma

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

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