Figma IPO 추진을 위한 로드 (새 탭에서 열림)
피그마(Figma)는 초기 단일 데이터베이스 구조에서 벗어나, 폭발적인 사용자 증가와 데이터 복잡성을 해결하기 위해 아키텍처를 어떻게 진화시켰는지에 대한 기술적 여정을 상세히 공개했습니다. 이 글은 피그마가 단순한 디자인 도구를 넘어 실시간 협업 플랫폼으로서 확장성을 확보하기 위해 선택한 데이터베이스 샤딩 전략과 자체 개발한 동기화 시스템의 핵심 원리를 다룹니다. 결과적으로 피그마는 인프라의 유연성을 확보함으로써 대규모 트래픽 속에서도 데이터 정합성과 낮은 지연 시간을 유지하는 데 성공했습니다. ### 데이터베이스 샤딩을 통한 확장성 확보 피그마는 초기에 모든 데이터를 하나의 거대한 PostgreSQL 데이터베이스에 저장했으나, 트래픽 증가에 따라 한계에 직면했습니다. 이를 해결하기 위해 단계별 샤딩 전략을 도입했습니다. * **수직적 샤딩(Vertical Sharding):** 부하가 큰 특정 테이블들을 별도의 독립된 데이터베이스 인스턴스로 분리하여 I/O 병목 현상을 일시적으로 해소했습니다. * **수평적 샤딩(Horizontal Sharding):** 단일 테이블의 크기가 너무 커지는 문제를 해결하기 위해 데이터를 여러 노드에 분산 저장했습니다. 이때 'Org ID'나 'File ID'와 같은 논리적 단위를 기준으로 데이터를 그룹화하여 쿼리 효율을 높였습니다. * **애플리케이션 계층의 라우팅:** 데이터베이스 수준이 아닌 애플리케이션 계층에서 어떤 셔드(Shard)에 접근할지 결정하는 로직을 구현하여, 인프라 변경이 서비스 코드에 미치는 영향을 최소화했습니다. ### 실시간 협업을 위한 LiveGraph 시스템 디자인 파일의 변경 사항을 수만 명의 사용자에게 실시간으로 전달하기 위해 피그마는 'LiveGraph'라는 독자적인 실시간 업데이트 엔진을 구축했습니다. * **구독 기반 모델:** 사용자가 보고 있는 파일의 특정 부분에 변경이 생기면, LiveGraph가 이를 감지하고 해당 데이터를 구독 중인 클라이언트에게만 즉각 전송합니다. * **데이터 정합성 유지:** 데이터베이스 쓰기 작업과 클라이언트 알림 사이의 간극을 줄이기 위해 트랜잭션 로그를 추적하며, 이를 통해 협업 중 발생하는 데이터 충돌을 효과적으로 방지합니다. * **효율적인 쿼리 처리:** 모든 클라이언트가 전체 데이터를 다시 불러오는 대신, 변경된 차분(Delta) 데이터만 전송함으로써 네트워크 대역폭 소모를 획기적으로 줄였습니다. ### 성능 최적화와 안정성 관리 인프라가 복잡해짐에 따라 발생할 수 있는 장애를 방지하고 성능을 일정하게 유지하기 위한 다양한 기술적 장치를 마련했습니다. * **쿼리 격리 및 제한:** 특정 사용자의 과도한 요청이 전체 시스템에 영향을 주지 않도록 'Noisy Neighbor' 문제를 차단하는 쿼리 제한(Throttling) 메커니즘을 도입했습니다. * **자동화된 마이그레이션:** 데이터베이스 스키마 변경 시 서비스 중단을 방지하기 위해 가동 중지 시간 없이 수행되는 온라인 마이그레이션 도구를 자체 개발하여 운영 안정성을 높였습니다. * **모니터링 고도화:** 각 샤드별 부하 상태와 쿼리 응답 시간을 실시간으로 추적하여, 병목 구간을 사전에 예측하고 대응할 수 있는 가시성을 확보했습니다. 성공적인 확장은 단순히 서버를 늘리는 것이 아니라, 서비스의 특성(실시간성, 고용량 데이터)에 맞는 데이터 분산 모델을 설계하는 데서 시작됩니다. 피그마의 사례는 서비스 초기부터 확장성을 고려한 아키텍처 설계가 장기적으로 기술 부채를 줄이고 비즈니스 성장을 뒷받침하는 핵심 동력이 됨을 시사합니다.