infrastructure

피그마의 차세대 데이터 캐싱 플랫폼 | 피그마 블로그 (새 탭에서 열림)

피그마(Figma)는 단일 관계형 데이터베이스(RDS)의 물리적 한계에 직면하자, 이를 해결하기 위해 수직적 분할을 거쳐 최종적으로 수평적 샤딩(Horizontal Sharding) 체제로 전환했습니다. 이 과정에서 'Fidous'라는 자체 데이터베이스 프록시 계층을 구축하여 애플리케이션 코드의 복잡성을 줄이고 데이터 정합성을 유지했습니다. 결과적으로 피그마는 서비스 중단 없이 수백 개의 샤드로 데이터를 분산하며 가용성과 확장성을 획기적으로 개선하는 데 성공했습니다. **단일 데이터베이스의 한계와 임계점** * 피그마의 초기 성장은 단일 거대 RDS 인스턴스에 의존했으나, 트래픽 급증으로 인해 AWS가 제공하는 최대 하드웨어 사양(CPU, 메모리, IOPS)에 도달했습니다. * 읽기 전용 복제본(Read Replicas)으로 조회를 분산했음에도 불구하고, 쓰기 작업의 부하와 복제 지연(Replication Lag) 문제가 전체 시스템의 안정성을 위협했습니다. * 특히 특정 대형 조직의 데이터가 급증할 때마다 단일 DB의 성능 저하가 모든 사용자에게 영향을 미치는 구조적 취약점이 드러났습니다. **수직적 파티셔닝(Vertical Partitioning)을 통한 1차 대응** * 샤딩을 도입하기 전 과도기적 단계로, 특정 테이블들을 도메인별로 묶어 물리적으로 분리된 별도의 데이터베이스 인스턴스로 이동시켰습니다. * 예를 들어 '사용자(Users)' 관련 테이블과 '파일(Files)' 관련 테이블을 서로 다른 DB 인스턴스로 분리하여 쓰기 부하를 분산했습니다. * 이 방식은 당장의 급한 불을 끄는 데는 효과적이었으나, 가장 큰 테이블들이 여전히 단일 DB에 머물러 있어 근본적인 해결책은 되지 못했습니다. **수평적 샤딩(Horizontal Sharding)과 샤드 키 선정** * 데이터 행(Row)을 여러 DB에 분산 저장하는 수평적 샤딩을 최종 해결책으로 채택했습니다. * 가장 중요한 결정은 '샤드 키(Shard Key)' 선정이었으며, 피그마는 대부분의 데이터가 조직(Organization) 단위로 액세스된다는 점에 착안해 `org_id`를 주요 샤드 키로 활용했습니다. * 샤드 키가 없는 데이터나 여러 샤드에 걸친 쿼리를 처리하기 위해, Vitess의 개념을 차용한 자체 라우팅 레이어 'Fidous'를 개발하여 쿼리 라우팅과 트랜잭션 관리를 수행하게 했습니다. **무중단 마이그레이션: 라이브 백필과 섀도우 쓰기** * 수 테라바이트에 달하는 데이터를 서비스 중단 없이 새로운 샤드 체계로 옮기기 위해 다단계 마이그레이션 전략을 사용했습니다. * 기존 DB에서 새로운 샤드로 데이터를 복제하는 '백필(Backfill)' 과정을 거친 후, 실시간 쓰기 작업을 양쪽 모두에 수행하는 '섀도우 쓰기(Shadow Write)'를 통해 정합성을 검증했습니다. * '데이터 정합성 검사기(Consistency Checker)'를 상시 가동하여 기존 DB와 샤딩된 DB 간의 오차를 0으로 만든 후, 트래픽을 단계적으로 전환(Cutover)했습니다. 피그마의 사례는 데이터베이스 확장성 문제를 해결할 때 처음부터 복잡한 샤딩을 도입하기보다, 수직적 분할로 시간을 벌고 그 사이 견고한 라우팅 인프라를 구축하는 단계적 접근이 중요함을 시연합니다. 특히 애플리케이션 계층과 데이터베이스 사이에 추상화 레이어를 두는 것은 장기적인 운영 효율성과 마이그레이션의 안정성을 확보하는 핵심 요소입니다.

GitHub Enterprise Server에서 고가용성을 (새 탭에서 열림)

제공해주신 내용은 GitHub의 검색 엔지니어 데이비드(David)의 약력으로 확인됩니다. 그가 주도적으로 작성한 **GitHub의 새로운 코드 검색 엔진인 'Blackbird'의 기술적 설계와 아키텍처**에 관한 블로그 글을 바탕으로 요약해 드립니다. 깃허브는 기존 검색 엔진의 한계를 극복하고 수십억 개의 파일에 대해 전례 없는 속도와 정확도를 제공하기 위해 Rust 기반의 새로운 검색 엔진 'Blackbird'를 자체 구축했습니다. 일반적인 텍스트 검색과 달리 코드의 특성을 깊이 있게 이해해야 하는 요구사항을 충족하기 위해, 인프라 계층부터 랭킹 알고리즘까지 모든 과정을 코드 검색에 최적화된 방식으로 재설계했습니다. 이를 통해 깃허브는 대규모 코드베이스에서 복잡한 쿼리를 밀리초 단위로 처리할 수 있는 강력한 검색 경험을 구현했습니다. **기존 범용 검색 엔진의 한계** * Elasticsearch와 같은 기존의 범용 엔진은 대규모 코드 검색에서 발생하는 특수 문자 처리와 정규 표현식 쿼리에 최적화되어 있지 않습니다. * 코드 데이터의 양이 기하급수적으로 늘어남에 따라 기존의 N-gram 인덱싱 방식은 인덱스 크기가 너무 커져 저장 비용과 검색 성능 면에서 효율성이 급격히 떨어지는 문제를 겪었습니다. * 다양한 프로그래밍 언어의 구문과 구조를 이해하지 못하는 일반적인 정보 검색 방식으로는 개발자가 원하는 정확한 검색 결과를 도출하는 데 한계가 있었습니다. **Blackbird: 코드 특화 검색 엔진 아키텍처** * **Rust 기반의 고성능 설계**: 시스템의 안정성과 메모리 효율성을 극대화하기 위해 Rust 언어를 사용하여 엔진을 밑바닥부터 직접 구현했습니다. * **Sparse N-gram 인덱싱**: 모든 데이터를 인덱싱하는 대신 유의미한 코드 패턴을 효율적으로 찾는 '희소(Sparse)' 인덱스 기술을 도입하여 인덱스 크기를 획기적으로 줄였습니다. * **Content-addressable Storage**: 코드의 중복을 제거하고 데이터 무결성을 보장하기 위해 콘텐츠 주소 지정 저장 방식을 사용하여 수 페타바이트의 데이터를 효율적으로 관리합니다. **샤딩 및 분산 처리 전략** * 수십억 개의 파일을 수천 개의 샤드(Shard)로 분할하여 관리하며, 각 샤드는 독립적으로 쿼리를 처리할 수 있도록 설계되었습니다. * 쿼리가 들어오면 오케스트레이터가 관련 있는 샤드들에 작업을 분산시키고 결과를 취합하는 분산 컴퓨팅 구조를 통해 동시 사용자가 많아도 낮은 지연 시간을 유지합니다. * 특정 리포지토리의 가시성 변화나 코드 수정 사항이 실시간에 가깝게 검색 결과에 반영될 수 있도록 고안된 파이프라인을 갖추고 있습니다. **관련성(Relevance) 엔지니어링** * 단순한 키워드 일치를 넘어 코드의 품질, 해당 리포지토리의 별(Star) 개수, 최근성 등을 종합적으로 고려한 랭킹 알고리즘을 적용했습니다. * 사용자의 의도를 파악하여 함수 정의, 변수 사용처 등 코드의 구조적 맥락을 반영한 검색 결과를 상단에 배치합니다. 대규모 시스템에서 범용 솔루션이 성능의 병목이 될 때, 도메인 특화(Domain-specific) 엔진을 직접 설계하고 구현하는 것이 서비스의 질을 한 단계 높이는 결정적인 차별점이 될 수 있음을 보여줍니다. 코드와 같이 특수한 구조를 가진 데이터를 다룰 때는 그 데이터의 본질에 맞춘 인덱싱 기법과 언어 선택이 성능 최적화의 핵심입니다.

데이터 사이언티스트로서 영향력을 (새 탭에서 열림)

피그마(Figma)는 데이터 규모가 급격히 팽창함에 따라 기존 배치 기반 파이프라인의 한계를 극복하기 위해 CDC(Change Data Capture) 및 스트리밍 아키텍처로의 대대적인 전환을 단행했습니다. Apache Iceberg와 Kafka, Debezium을 결합한 새로운 파이프라인을 통해 데이터 지연 시간을 수일에서 수분 단위로 단축했으며, 수백 개의 데이터베이스 샤드로부터 발생하는 대규모 데이터를 안정적으로 처리할 수 있는 기반을 마련했습니다. 이 글은 급성장하는 서비스에서 데이터 일관성과 실시간성을 동시에 확보하기 위한 피그마 엔지니어링 팀의 여정과 기술적 결정을 다룹니다. ### 기존 배치 파이프라인의 한계와 병목 현상 * 초기 피그마는 Embulk를 이용해 수백 개의 RDS 샤드에서 데이터를 추출하여 S3에 저장하고 이를 Snowflake로 로드하는 배치 방식을 사용했으나, 데이터 양이 늘어남에 따라 지연 시간이 며칠씩 발생했습니다. * 소스 데이터베이스에 직접 쿼리를 날려 데이터를 추출하는 방식은 운영 중인 DB에 과도한 부하를 주었으며, 이를 피하기 위해 읽기 전용 복제본(Read Replica)을 사용함에도 불구하고 스케일 아웃의 한계에 직면했습니다. * 스키마 변경이 발생할 때마다 파이프라인이 수동 개입 없이는 중단되거나 데이터 정합성이 깨지는 등 운영상의 복잡도가 임계치를 넘어서는 문제가 있었습니다. ### CDC 및 Kafka 기반의 실시간 스트리밍 도입 * 데이터베이스의 바이너리 로그(Binlog)를 읽어 변경 사항을 즉시 캡처하는 CDC 방식을 도입하여 원본 DB에 가하는 부하를 최소화했습니다. * Debezium 커넥터를 AWS MSK(Managed Streaming for Kafka)와 연결해 수백 개의 샤드에서 발생하는 변경 이벤트를 중앙 Kafka 클러스터로 실시간 수집하는 구조를 설계했습니다. * Confluent Schema Registry를 활용해 Avro 포맷으로 데이터를 직렬화함으로써, 업스트림의 스키마 변경이 다운스트림 파이프라인에 안전하고 자동화된 방식으로 전파되도록 구현했습니다. ### Apache Iceberg를 활용한 데이터 레이크 현대화 * S3에 저장되는 데이터를 관리하기 위해 오픈 소스 테이블 포맷인 Apache Iceberg를 도입하여 대규모 데이터셋에 대한 ACID 트랜잭션과 시간 여행(Time Travel) 기능을 확보했습니다. * 기존의 단순 파일 저장 방식과 달리 Iceberg는 메타데이터를 효율적으로 관리하므로, Snowflake와 같은 데이터 웨어하우스에서 쿼리 시 불필요한 파일을 스캔하지 않아도 되어 성능과 비용을 최적화했습니다. * Kafka Connect의 Iceberg 싱크를 사용하여 스트리밍 데이터를 즉시 Iceberg 테이블로 기록함으로써 데이터 신선도를 극대화했습니다. ### 시스템 전환의 성과와 운영 효율화 * 새로운 아키텍처 도입 후 데이터 가용 지연 시간이 수일에서 5분 이내로 줄어들었으며, 분석가와 엔지니어들이 거의 실시간에 가까운 인사이트를 얻을 수 있게 되었습니다. * 데이터 파이프라인의 가시성을 높이기 위해 사용자 정의 모니터링 대시보드와 알림 시스템을 구축하여, 특정 샤드나 커넥터에서 발생하는 문제를 즉각적으로 파악하고 대응할 수 있는 환경을 만들었습니다. * 인프라의 확장성이 크게 개선되어 향후 데이터베이스 샤드가 추가되거나 트래픽이 급증하더라도 파이프라인의 구조적 변경 없이 유연하게 대응할 수 있는 능력을 갖추게 되었습니다. 서비스 규모가 커짐에 따라 전통적인 배치 방식은 성능과 운영 면에서 한계에 부딪힐 수밖에 없습니다. 피그마의 사례처럼 CDC와 Kafka, 그리고 Iceberg와 같은 현대적인 데이터 스택을 조합하면 데이터 신선도를 획기적으로 높이면서도 시스템의 안정성을 동시에 확보할 수 있습니다. 대규모 샤딩 환경에서 데이터 파이프라인을 고민하는 팀이라면 이벤트 중심의 아키텍처와 스키마 레지스트리를 통한 자동화에 집중할 것을 권장합니다.

Delivering the Future: 글로벌 해커톤 2025, 준비부터 운영까지 | 우아한형제들 기술블로그 (새 탭에서 열림)

딜리버리히어로 산하 전 세계 7개 엔티티의 기술직군 구성원들이 참여한 ‘글로벌 해커톤 2025’는 글로벌 기술 인재들을 하나로 연결하고 미래의 고객 경험을 혁신하기 위해 개최되었습니다. 우아한형제들 DR팀은 이번 행사의 오거나이저로서 한국에서의 커뮤니티 운영 노하우를 발휘해 서로 다른 시차와 환경을 가진 팀들이 기술적으로 협업할 수 있는 온·오프라인 하이브리드 환경을 구축했습니다. 이를 통해 전 세계 270여 명의 참가자는 구글 클라우드 등 최신 기술 스택을 활용하여 비즈니스 아이디어를 실현하며 글로벌 기술 시너지를 확인했습니다. **글로벌 협업을 위한 행사 기획과 소통 구조** * 전 세계 70여 개국에 퍼져 있는 구성원들의 참여를 독려하기 위해 각국의 공휴일과 휴가 시즌을 면밀히 분석하여 가장 참여도가 높을 것으로 예상되는 일정을 확정했습니다. * 물리적 거리의 한계를 극복하고자 각 엔티티 오피스를 '베이스캠프'로 지정해 오프라인의 몰입감을 유지하는 동시에, 라이브 중계와 온라인 채널을 연계해 전 세계를 실시간으로 연결했습니다. * 시간대 차이로 발생하는 소통의 병목 현상을 해결하기 위해 정기 회의 대신 엔티티별 개별 미팅을 진행하고, 표준화된 가이드 문서와 체크리스트를 배포하여 운영 효율성을 높였습니다. **규제와 실험의 자유를 고려한 기술 환경 구축** * 참가자들이 GCP, AWS, ML 모델 등 각자 익숙한 기술 스택을 자유롭게 활용하면서도, GDPR(EU 일반 개인정보 보호 규정)과 같은 엄격한 글로벌 보안 및 컴플라이언스 규정을 준수하도록 인프라를 설계했습니다. * 딜리버리히어로 중앙 조직이 직접 조율한 공통 기술 가이드를 마련하여 리소스 제공 범위와 데이터 접근 절차를 명확히 규정함으로써 기술적 파편화를 방지했습니다. * 구글 클라우드와의 파트너십을 통해 Google AI 기반 환경을 폭넓게 제공하여, 참가자들이 실제 현업 환경과 유사한 조건에서 고도화된 기술적 실험을 수행할 수 있도록 지원했습니다. **현지 운영과 글로벌 네트워크의 확장** * 근무 형태가 서로 다른 엔티티들이 같은 도시 내 오피스를 개방하고 공유하도록 독려하여, 소속에 관계없이 글로벌 구성원들이 자연스럽게 섞여 협업할 수 있는 분위기를 조성했습니다. * 각 엔티티의 CTO와 CPO가 예선 심사에 직접 참여하고, 딜리버리히어로 글로벌 CTO 및 구글 클라우드 디렉터가 최종 심사를 맡아 프로젝트의 비즈니스 가치와 기술적 완성도를 다각도로 검증했습니다. * 수상 팀에게는 상금과 함께 미국에서 열리는 'Google Cloud Next 2026' 참가 기회를 제공하여 해커톤 이후에도 기술적 성장이 이어질 수 있는 동기를 부여했습니다. 이번 글로벌 해커톤은 거대한 조직 규모와 지리적 제약 속에서도 공통의 기술 가이드와 명확한 운영 원칙이 있다면 전 세계 엔지니어들이 하나의 팀처럼 혁신을 만들어낼 수 있음을 보여주었습니다. 서로 다른 배경을 가진 개발자들이 기술로 소통하며 시너지를 내는 과정은 글로벌 기술 기업으로서의 결속력을 다지는 중요한 발판이 됩니다.

당근 검색 엔진, 쿠버네티스로 쉽게 운영하기 2편 — 데이터 노드 웜업 적용 (새 탭에서 열림)

당근 검색 플랫폼팀은 쿠버네티스(ECK) 환경에서 Elasticsearch 클러스터를 운영하며, 롤링 리스타트 시 발생하는 레이턴시 급증 문제를 해결하기 위해 '데이터 노드 웜업(Warmup)' 시스템을 구축했습니다. 단순히 Pod가 실행되는 것을 넘어 샤드 복구와 캐시 예열이 완료된 후에만 다음 노드를 재시작하도록 제어함으로써, 피크 타임에도 서비스 영향 없이 안정적인 배포가 가능해졌습니다. 이를 통해 운영자의 모니터링 부담을 제거하고 언제든 안심하고 배포할 수 있는 환경을 마련했습니다. **롤링 리스타트와 콜드 캐시의 위험성** * Elasticsearch는 페이지 캐시, 쿼리 캐시 등 다양한 메모리 캐시에 크게 의존하므로, 재시작 직후 캐시가 비어 있는 '콜드 캐시' 상태에서는 성능이 급격히 저하됩니다. * 쿠버네티스의 기본 롤링 업데이트는 Pod의 준비 상태(Ready)만 확인하고 다음 노드를 재시작하기 때문에, 준비되지 않은 노드에 트래픽이 몰리며 전체 검색 레이턴시가 수 초까지 치솟는 장애가 발생할 수 있습니다. * 노드 한 대가 내려간 동안 남은 노드들이 모든 부하를 감당해야 하며, 복제본(Replica) 샤드가 없는 상태에서 다른 노드에 문제가 생기면 클러스터가 'Red' 상태로 변해 가용성이 무너질 위험이 큽니다. **안전한 배포를 위한 단계별 웜업 전략** * 목표는 배포 중에도 P99 레이턴시를 평소 수준으로 유지하고, 클러스터 상태가 'Yellow'에서 다시 'Green'이 된 것을 확인한 후 다음 단계로 넘어가는 것입니다. * 이를 위해 노드 재시작 후 세 가지 단계를 거칩니다: 1) 데이터 노드가 클러스터에 정상 합류할 때까지 대기, 2) 할당된 샤드들의 데이터 복구(Recovery) 완료 확인, 3) 실제 검색 쿼리를 미리 실행하여 캐시를 채우는 과정입니다. * 특히 샤드 복구가 완료되지 않은 상태에서 웜업을 시작하면 데이터가 없는 상태에서 쿼리를 날리는 꼴이 되므로, 반드시 인덱싱 상태를 모니터링하는 로직이 포함되어야 합니다. **사이드카 패턴 기반의 웜업 시스템 구현** * Elasticsearch 컨테이너와 함께 실행되는 별도의 `warmup-sidecar`를 도입하여 노드의 상태를 정밀하게 추적합니다. * 사이드카는 API를 통해 해당 노드의 샤드들이 모두 'Started' 상태인지 확인하고, 실제 운영 환경에서 발생하는 검색 트래픽(Traffic Replay)을 신규 노드에 미리 쏘아주어 메모리에 데이터를 올립니다. * 이 모든 과정이 완료되어야만 쿠버네티스의 Readiness Probe를 통과하게 설계하여, ECK 오퍼레이터가 노드 웜업이 끝날 때까지 다음 Pod의 재시작을 자동으로 대기하도록 제어했습니다. 대규모 트래픽을 처리하는 상태 기반(Stateful) 시스템에서는 인프라 수준의 단순한 헬스체크만으로는 부족하며, 애플리케이션 내부의 데이터 준비 상태를 고려한 정교한 배포 전략이 필수적입니다. 데이터 노드 웜업 도입으로 배포 시간은 기존보다 길어졌지만, 시간에 구애받지 않고 24시간 언제든 안전하게 시스템을 업데이트할 수 있는 운영 안정성을 확보하게 되었습니다.

대규모 가시성: Figma가 (새 탭에서 열림)

피그마(Figma)는 서비스 규모가 확장됨에 따라 복잡해진 권한 관리 로직을 효율적으로 처리하기 위해 자체적인 권한 정의 언어(DSL)인 'Permit'을 구축했습니다. 기존의 파편화된 명령형 코드 방식에서 벗어나 선언적인 DSL을 도입함으로써 권한 정책의 일관성을 확보하고 보안 취약점 발생 가능성을 획기적으로 낮췄습니다. 이를 통해 복잡한 사용자-리소스 간의 관계를 명확하게 모델링하고 성능 저하 없이 대규모 시스템에 적용할 수 있는 권한 검증 인프라를 완성했습니다. ### 기존 시스템의 한계와 권한 관리의 복잡성 * 권한 체크 로직이 Go 애플리케이션 코드 곳곳에 흩어져 있어, 특정 리소스에 대한 접근 규칙을 한눈에 파악하거나 일관되게 수정하기 매우 어려웠습니다. * 팀, 프로젝트, 파일로 이어지는 계층 구조뿐만 아니라 엔터프라이즈 설정, 공유 링크 등 수많은 변수가 결합되면서 권한 로직 수정 시 예기치 않은 부작용(side effects)이 발생할 위험이 컸습니다. * 성능 최적화를 위해 데이터베이스 쿼리에 권한 로직을 직접 포함시켜야 하는 경우가 많았는데, 이는 비즈니스 로직과 권한 정책이 뒤섞여 코드 유지보수성을 떨어뜨리는 결과로 이어졌습니다. ### 관계 기반 접근 제어(ReBAC)와 Permit DSL 설계 * 구글의 Zanzibar 시스템에서 영감을 얻어, 객체 간의 관계를 중심으로 권한을 정의하는 ReBAC(Relationship-Based Access Control) 모델을 피그마의 환경에 맞게 커스텀화했습니다. * Permit DSL은 'Actor(사용자)', 'Resource(파일, 팀 등)', 'Action(편집, 보기 등)' 간의 관계를 선언적인 문법으로 정의합니다. * 예를 들어 "사용자가 파일이 속한 프로젝트의 편집자라면 해당 파일에 대한 편집 권한을 가진다"와 같은 전이적인(transitive) 관계를 직관적인 문법으로 표현할 수 있게 되었습니다. ### 컴파일러 및 성능 최적화 기술 * DSL로 작성된 정책을 런타임에 해석하는 대신, 효율적인 Go 코드로 변환하는 자체 컴파일러를 개발하여 실행 성능을 극대화하고 런타임 오버헤드를 최소화했습니다. * 컴파일 단계에서 정적 분석을 수행하여 순환 참조나 정의되지 않은 권한 사용 등 논리적 오류를 사전에 차단합니다. * 특히 '부분 평가(Partial Evaluation)' 기법을 도입하여, 권한 로직을 SQL 쿼리의 WHERE 절로 변환함으로써 수백만 개의 리소스 중 사용자가 접근 가능한 항목만 효율적으로 필터링할 수 있도록 구현했습니다. ### 안전한 전환을 위한 검증 및 배포 프로세스 * DSL 내부에 유닛 테스트를 직접 작성할 수 있는 기능을 포함시켜, 정책 변경이 기존의 기대 결과와 일치하는지 배포 전 즉시 검증할 수 있는 환경을 마련했습니다. * '섀도 모드(Shadow mode)'를 활용하여 실제 트래픽에서 기존의 레거시 권한 로직 결과와 새로운 Permit 시스템의 결과를 실시간으로 비교하며 데이터 정합성을 확인했습니다. * 성능 모니터링을 통해 권한 확인 작업이 전체 API 응답 시간에 미치는 영향을 정밀하게 추적하며 안정성을 확보했습니다. 권한 관리는 단순한 기능을 넘어 대규모 SaaS의 보안과 확장성을 결정짓는 핵심 인프라입니다. 피그마의 사례처럼 권한 로직을 비즈니스 코드에서 분리하여 '정책(Policy)'으로서 중앙 집중화하고 코드화하는 전략은, 제품의 복잡도가 높아질수록 개발 생산성과 시스템 안정성을 동시에 잡을 수 있는 가장 강력한 방법 중 하나입니다.

Figma 렌더링: Web (새 탭에서 열림)

Figma는 웹 브라우저라는 제한적인 환경에서 고성능 그래픽 도구를 구현하기 위해 전통적인 웹 개발 방식을 넘어선 혁신적인 엔지니어링 접근법을 취하고 있습니다. 핵심은 C++ 엔진과 WebAssembly를 활용한 저수준 최적화, 그리고 독자적인 데이터 구조를 통해 데스크톱 애플리케이션에 필적하는 속도와 안정성을 확보한 것입니다. 이러한 성능 최적화는 단순한 기능 개선을 넘어 수만 개의 레이어가 포함된 대규모 협업 환경에서도 지연 없는 사용자 경험을 제공하는 Figma의 핵심 경쟁력이 되었습니다. ### WebAssembly와 C++ 기반의 핵심 엔진 * 브라우저의 JavaScript 엔진이 가진 가비지 컬렉션(GC) 성능 저하와 예측 불가능한 실행 속도를 극복하기 위해, 서비스의 핵심 로직을 C++로 작성했습니다. * 작성된 C++ 코드를 WebAssembly(Wasm)로 컴파일하여 브라우저에서 실행함으로써, 네이티브 앱에 가까운 실행 속도를 확보하고 메모리 레이아웃을 직접 정밀하게 제어합니다. * 이를 통해 복잡한 벡터 연산이나 대량의 객체 렌더링 시에도 일정한 프레임 레이트를 유지하며, 대규모 디자인 파일 로딩 성능을 비약적으로 향상시켰습니다. ### 고성능 렌더링 파이프라인 및 GPU 활용 * 웹 표준 렌더링 방식의 한계를 넘기 위해 Skia 기반의 독자적인 렌더링 엔진을 구축하고, GPU 가속을 적극적으로 활용합니다. * 화면의 변경된 부분만 효율적으로 업데이트하는 '더티 렉트(Dirty Rect)' 알고리즘과 타일링 기법을 적용하여 불필요한 연산을 최소화합니다. * 고해상도 디스플레이 환경에서도 줌인/줌아웃 및 패닝(Panning) 시 끊김 없는 부드러운 화면 전환을 위해 픽셀당 연산 과정을 최적화했습니다. ### 실시간 협업을 위한 데이터 동기화 아키텍처 * 여러 사용자가 동시에 편집하는 환경에서 데이터 충돌을 방지하고 일관성을 유지하기 위해 CRDT(Conflict-free Replicated Data Types) 개념을 응용한 동기화 엔진을 운용합니다. * 전체 파일 데이터를 다시 전송하는 대신, 변경된 속성(Diff)만을 최소 단위로 패키징하여 전송함으로써 네트워크 대역폭 사용량을 획기적으로 줄였습니다. * 사용자의 조작을 로컬에서 즉각 반영하는 '낙관적 업데이트'와 서버와의 비동기 통신을 정교하게 결합하여, 네트워크 지연 시간이 있는 상황에서도 체감 속도를 높였습니다. ### 대규모 프로젝트를 위한 메모리 관리 전략 * 브라우저의 메모리 제한(특히 32비트 환경의 한계)을 극복하기 위해 64비트 WebAssembly를 도입하고 메모리 파티셔닝 기술을 적용했습니다. * 파일 내의 수많은 레이어와 에셋을 한꺼번에 불러오지 않고, 화면에 보이는 요소나 필요한 데이터만 우선적으로 로드하는 지연 로딩(Lazy Loading) 기법을 사용합니다. * 지속적인 성능 프로파일링을 통해 메모리 누수를 감지하고, 불필요한 객체를 즉각 해제하는 엄격한 리소스 관리 체계를 구축하여 장시간 작업 시에도 안정성을 유지합니다. Figma의 사례는 웹 기술의 한계를 탓하기보다 WebAssembly와 GPU 가속 같은 최신 표준을 밑바닥부터 활용하여 문제를 해결하는 방식의 중요성을 보여줍니다. 성능 최적화는 단기적인 작업이 아니라 제품의 설계 단계부터 고려되어야 하는 핵심 원칙이며, 특히 협업 툴에서는 성능이 곧 사용자의 생산성과 직결된다는 점을 명심해야 합니다. 최신 웹 기술 스택을 고려 중인 엔지니어라면 성능 병목 지점을 해결하기 위해 저수준 제어권을 확보하는 전략을 검토해 볼 필요가 있습니다.

LY의 테크 컨퍼런스, 'Tech-Verse 2025' 후기 (새 탭에서 열림)

LY Corporation(이하 LY)은 기술 컨퍼런스 'Tech-Verse 2025'를 통해 합병 이후의 플랫폼 통합 전략과 AI 기업으로의 전환 비전을 제시했습니다. LY는 자체 프라이빗 클라우드 구축을 통해 압도적인 비용 절감과 보안 강화를 실현하고, 모든 서비스에 AI 에이전트를 도입하여 사용자 경험을 혁신할 계획입니다. 특히 생성형 AI를 활용한 개발 프로세스의 전면적인 진화로 엔지니어가 서비스 본질에 집중할 수 있는 환경을 구축하는 것이 핵심입니다. **CatalystOne: 고효율 통합 플랫폼 구축** * **자체 클라우드 기반의 비용 최적화**: 퍼블릭 클라우드 대비 약 4배의 비용 절감 효과를 거두고 있으며, 50만 대의 서버와 3Tbps에 달하는 대규모 트래픽을 효율적으로 관리하고 있습니다. * **플랫폼 통합(CatalystOne)**: 합병 후 중복된 인프라를 'CatalystOne'이라는 이름 아래 통합하여 기술, 엔지니어, 시설 등 핵심 자원의 운영 집중도를 높였습니다. * **보안 및 혁신 가속화**: 통합된 플랫폼을 통해 거버넌스를 강화하고, 폭발적인 데이터 성장과 생성형 AI 수요에 기민하게 대응할 수 있는 차세대 프라이빗 클라우드 'Flava'를 구축했습니다. **전 서비스의 AI 에이전트화와 개발 혁신** * **퍼스널 에이전트 구현**: 현재 44개 서비스에 생성형 AI를 도입했으며, 수천만 개의 에이전트를 연계하여 개별 사용자의 니즈를 정교하게 지원하는 것을 목표로 합니다. * **AI 기반 개발 솔루션 도입**: 2025년 7월부터 모든 엔지니어에게 AI 개발 솔루션을 전면 도입하며, RAG(검색 증강 생성) 기술로 사내 지식을 활용해 코드 품질을 높입니다. * **생산성 지표의 획기적 개선**: PoC 결과 'Code Assist'는 96%의 정답률을 기록했고, 'Auto Test' 도입으로 테스트 시간을 97% 단축하는 등 압도적인 개발 효율성 향상을 확인했습니다. **실용적인 결론** LY의 전략은 대규모 인프라를 운영하는 기업이 단순히 AI를 도입하는 것에 그치지 않고, 인프라 통합을 통한 비용 효율화와 AI를 활용한 개발 문화 혁신이 병행되어야 함을 보여줍니다. 특히 엔지니어링 환경에 AI를 적극적으로 이식하여 확보한 리소스를 사용자 가치 증대에 재투자하는 선순환 구조는 기술 기업들이 참고할 만한 모델입니다.

테크 컨퍼런스 Tech-Verse 2025를 개최합니다 (새 탭에서 열림)

LY Corporation은 오는 6월 30일부터 7월 1일까지 양일간 글로벌 테크 컨퍼런스인 'Tech-Verse 2025'를 개최합니다. 이번 행사는 AI와 보안을 메인 테마로 하여 전 세계 그룹사 엔지니어들이 경험한 127개의 기술 세션을 온라인으로 공유할 예정입니다. 누구나 무료 사전 등록을 통해 참여할 수 있으며, 한국어, 영어, 일본어 실시간 통역이 제공되어 글로벌 기술 트렌드를 깊이 있게 파악할 수 있는 기회를 제공합니다. **Tech-Verse 2025 행사 개요 및 참여 방법** * **일정 및 방식**: 2025년 6월 30일(월)부터 7월 1일(화)까지 매일 오전 10시에서 오후 6시 사이에 진행되며, 전 세션 온라인 스트리밍으로 생중계됩니다. * **참여 대상**: 공식 사이트에서 사전 등록만 하면 누구나 무료로 시청할 수 있어 접근성이 높습니다. * **글로벌 협업**: 한국의 LINE Plus를 비롯해 일본, 대만, 베트남 등 LY Corporation 그룹사 전체의 엔지니어, 디자이너, 프로덕트 매니저가 참여하여 폭넓은 기술 생태계를 다룹니다. **12개 분야의 방대한 기술 세션 구성** * **일자별 트랙 구성**: 1일 차에는 AI, 보안, 서버사이드, 프라이빗 클라우드 등 인프라 중심의 세션이 배치되며, 2일 차에는 AI 유즈 케이스, 프론트엔드, 모바일 앱, 디자인 및 제품 관리 등 사용자 접점 기술을 중점적으로 다룹니다. * **다국어 지원**: 총 127개의 세션에 대해 3개 국어(한/영/일) 실시간 통역을 지원하여 언어 장벽 없이 기술적 디테일을 학습할 수 있습니다. * **핵심 테마**: 최근 IT 업계의 화두인 생성형 AI의 실무 적용과 고도화된 보안 전략이 전체 컨퍼런스의 중심축을 이룹니다. **분야별 주목해야 할 주요 기술 사례** * **AI 및 데이터 파이프라인**: 단순한 코드 작성을 넘어 전문적인 AI 코딩 프로세스로의 진화와 생성형 AI를 활용한 데이터 파이프라인 구축 및 분석 자동화 사례가 소개됩니다. * **인프라 및 서버사이드**: 'Central Dogma Control Plane'을 활용해 수천 개의 마이크로서비스를 연결하는 대규모 인프라 관리 기법과 LINE Call의 영상 품질 개선을 위한 서버 기술이 공유됩니다. * **앱 개발 및 사용자 경험**: 배달 서비스 '데마에칸(Demae-can)'의 개발 환경을 React Native에서 Flutter로 전면 교체한 과감한 이행 전략과 데이터 기반의 LINE Talk 사용자 인사이트 도출 과정이 포함되어 있습니다. **참여 권장 및 실용 가이드** 최신 기술 트렌드와 대규모 서비스 운영 노하우를 얻고 싶은 개발자라면 Tech-Verse 2025 공식 사이트를 통해 관심 있는 세션을 미리 타임테이블에 등록해 두는 것이 좋습니다. 특히 현업에서 AI 도입을 고민하거나 대규모 트래픽 처리를 위한 인프라 구조를 연구하는 엔지니어들에게 실질적인 기술적 영감을 줄 것으로 기대됩니다.

Figma에서 AI 기반 검색을 (새 탭에서 열림)

피그마의 AI 검색 인프라는 수십억 개의 디자인 레이어를 실시간으로 처리하고 의미론적으로 검색할 수 있도록 구축되었습니다. 대규모 벡터 데이터베이스와 멀티모달 임베딩 모델을 결합하여 단순 텍스트 매칭을 넘어 시각적 유사성을 기반으로 한 검색 경험을 제공합니다. 이 시스템은 데이터 프라이버시를 엄격히 준수하면서도 디자인 파일의 빈번한 수정을 즉각적으로 검색 결과에 반영하는 고성능 데이터 파이프라인을 핵심으로 합니다. **멀티모달 임베딩을 통한 디자인의 수치화** * 디자인 파일 내의 레이어, 텍스트, 이미지를 고차원 벡터로 변환하기 위해 멀티모달 임베딩 모델(예: CLIP 변형 모델)을 사용합니다. * 단순한 시각적 특징뿐만 아니라 디자인의 구조적 맥락과 텍스트 정보를 함께 학습하여 "로그인 페이지", "네비게이션 바"와 같은 추상적인 검색어에도 정확한 결과를 반환합니다. * AWS SageMaker를 활용해 모델 추론을 확장 가능하게 관리하며, 다양한 해상도의 이미지 자산을 효율적으로 처리하기 위한 전처리 과정을 포함합니다. **실시간 변경 사항을 반영하는 증분 인덱싱 파이프라인** * 피그마 디자인은 수시로 수정되기 때문에, 전체 데이터를 다시 인덱싱하는 대신 변경된 부분만 업데이트하는 증분(Incremental) 업데이트 방식을 채택했습니다. * 사용자가 디자인을 수정하면 해당 이벤트가 Kafka를 통해 실시간 스트리밍되며, Flink와 같은 처리 엔진을 거쳐 즉시 벡터 데이터베이스에 반영됩니다. * 이 과정을 통해 수만 명의 사용자가 동시에 작업하는 환경에서도 검색 결과와 실제 디자인 사이의 시차를 최소화합니다. **벡터 데이터베이스와 하이브리드 검색 최적화** * 대규모 벡터 검색을 위해 Pinecone과 같은 전문 벡터 데이터베이스를 활용하여 밀집 벡터(Dense Vector) 검색을 수행합니다. * 단순히 유사도만 측정하는 것이 아니라, 파일 이름, 생성 날짜, 프로젝트 위치 등 구조화된 메타데이터를 함께 필터링하는 하이브리드 검색 방식을 사용합니다. * 검색 성능을 높이기 위해 사용자별, 팀별로 데이터를 논리적으로 분할하여 검색 범위를 최적화하고 응답 속도를 밀리초(ms) 단위로 유지합니다. **엄격한 권한 관리와 데이터 격리** * AI 검색 결과는 피그마의 복잡한 권한 체계(Permissions)를 완벽히 준수해야 하므로, 검색 요청 시 실시간으로 사용자의 접근 권한을 확인하는 레이어가 포함됩니다. * 인덱싱 단계에서부터 각 벡터에 조직 및 파일 식별자(ID)를 메타데이터로 부여하여, 사용자가 접근할 수 없는 디자인 데이터가 검색 결과에 노출되는 것을 원천 차단합니다. * 데이터 보안을 위해 테넌트(Tenant) 간 데이터 격리를 보장하며, 모델 학습과 추론 과정에서도 민감한 정보가 유출되지 않도록 설계되었습니다. 피그마와 같이 데이터 업데이트가 빈번하고 권한 체계가 복잡한 환경에서 AI 검색을 구현하려면, 단순히 성능 좋은 모델을 사용하는 것을 넘어 실시간 데이터 파이프라인과 메타데이터 필터링 시스템을 정교하게 결합하는 것이 필수적입니다. 효율적인 비용 관리와 낮은 지연 시간을 동시에 달성하고자 하는 팀에게 피그마의 증분 인덱싱 및 하이브리드 검색 아키텍처는 훌륭한 벤치마킹 사례가 될 것입니다.

Figma에서의 속도 탐 (새 탭에서 열림)

피그마(Figma)는 기존 EC2 기반의 레거시 인프라가 성장을 저해하자, 개발자 생산성과 시스템 확장성을 확보하기 위해 쿠버네티스(Kubernetes, K8s) 전환을 결정했습니다. 이들은 단순한 인프라 교체를 넘어 내부 추상화 도구를 통한 '골든 패스(Golden Path)'를 구축함으로써 1년 미만이라는 짧은 기간 내에 주요 핵심 서비스를 성공적으로 이전했습니다. 결과적으로 인프라 운영의 복잡성을 낮추면서도 대규모 트래픽을 효율적으로 수용할 수 있는 현대적인 컴퓨팅 환경을 마련했습니다. ### 기존 인프라의 한계와 전환 배경 * 기존의 Chef와 Puppet 기반 EC2 환경은 배포 속도가 느리고 수동 설정이 많아 급격한 사용자 증가에 따른 스케일링 대응에 한계가 있었습니다. * 인프라 팀이 모든 프로비저닝 요청의 병목지점이 되면서 개발팀의 자율성이 저하되고, 환경 간 일관성을 유지하기 어려운 문제가 발생했습니다. * 애플리케이션의 이식성을 높이고 리소스 효율성을 극대화하기 위해 컨테이너 중심의 관리 체계로의 패러다임 전환이 필수적이었습니다. ### 개발자 경험 중심의 추상화 레이어 구축 * 개발자가 쿠버네티스의 복잡한 YAML 명세나 `kubectl` 명령어를 직접 학습하지 않아도 되도록 내부 플랫폼 인터페이스를 설계했습니다. * 표준화된 서비스 정의와 배포 프로세스를 제공하는 내부 도구를 통해, 개발자는 몇 가지 설정만으로도 보안과 모니터링이 적용된 인프라를 즉시 할당받을 수 있게 되었습니다. * 이러한 '추상화'는 인프라 팀이 하부 구조를 변경하더라도 상위의 개발자 워크플로우에는 영향을 주지 않는 유연성을 제공했습니다. ### 점진적 마이그레이션과 안정성 확보 전략 * '빅뱅' 방식의 전환 대신, 기존 EC2 서비스와 새로운 K8s 서비스를 병행 운영하며 트래픽을 단계적으로 전환하는 방식을 채택했습니다. * 실제 트래픽을 복제하여 새로운 환경의 안정성을 미리 검증하는 '섀도우 트래픽(Shadow Traffic)' 테스트를 통해 마이그레이션 시 발생할 수 있는 리스크를 사전에 차단했습니다. * 전환 과정에서의 데이터 정합성 유지와 네트워크 지연 시간을 최소화하기 위해 서비스 메쉬 및 전용 커넥터를 활용하여 두 환경 간의 통신을 최적화했습니다. 대규모 인프라 마이그레이션의 성공은 단순히 기술적 스택을 바꾸는 것이 아니라, 개발자의 진입 장벽을 낮추는 내부 플랫폼 설계에 달려 있습니다. 복잡한 기술적 세부 사항을 추상화하고 점진적인 검증 절차를 거치는 전략은 서비스 중단 없이 대규모 시스템을 현대화하려는 조직에게 훌륭한 본보기가 됩니다.

12개월 이내에 K8 (새 탭에서 열림)

피그마(Figma)는 급격한 사용자 증가에 따른 데이터베이스 부하 문제를 해결하기 위해 단일 PostgreSQL 환경에서 Vitess 기반의 수평적 샤딩 아키텍처로 성공적으로 전환했습니다. 이 과정에서 피그마는 서비스 중단 없이 대규모 데이터를 마이그레이션했으며, 수직적 확장의 한계를 극복하고 무한한 확장성을 갖춘 데이터 플랫폼을 구축했습니다. 결론적으로 이들은 기술적 부채를 체계적으로 관리하며 분산 데이터베이스 시스템으로의 진화가 서비스 성장의 필수 요소임을 입증했습니다. **수직적 확장과 수직적 분할의 한계** * 피그마는 초기 AWS RDS의 가장 큰 인스턴스(r5.24xlarge 등)를 사용하며 수직적 확장(Vertical Scaling)에 의존했으나, 결국 CPU와 IOPS의 물리적 한계에 도달했습니다. * 이를 해결하기 위해 먼저 테이블 단위로 데이터베이스를 나누는 '수직적 분할(Vertical Partitioning)'을 시행하여 특정 도메인(파일, 조직 등)을 별도 데이터베이스 인스턴스로 분리했습니다. * 수직적 분할은 일시적으로 숨통을 틔워주었지만, 각 도메인 내의 데이터가 계속 비대해지면서 단일 인스턴스가 감당할 수 없는 수준에 이르러 결국 수평적 샤딩이 불가피해졌습니다. **Vitess 도입을 통한 수평적 샤딩** * 피그마는 유튜브와 슬랙 등에서 검증된 오픈소스 데이터베이스 클러스터링 시스템인 Vitess를 도입하여 대규모 수평적 확장을 구현했습니다. * Vitess는 애플리케이션 계층에서 복잡한 샤딩 로직을 처리할 필요 없이, SQL 프록시 역할을 수행하며 쿼리를 적절한 샤드(Shard)로 라우팅해주는 기능을 제공합니다. * 데이터 분산의 핵심인 '샤딩 키(Sharding Key)'를 신중하게 선정하여 데이터가 특정 노드에 쏠리는 핫스팟 현상을 방지하고 부하를 고르게 분산시켰습니다. **무중단 마이그레이션과 데이터 정합성 보장** * 서비스를 운영하면서 데이터를 옮기기 위해 Vitess의 'MoveTables' 및 'VReplication' 기능을 활용하여 구형 데이터베이스에서 신규 샤드 클러스터로 데이터를 실시간 복제했습니다. * 마이그레이션 중 데이터 유실이나 오염을 방지하기 위해 'Shadow Mode'를 운영하여, 실제 쓰기 작업을 수행하기 전 구 데이터베이스와 신규 데이터베이스의 결과를 비교 검증했습니다. * 최종 전환 시점에는 짧은 읽기 전용(Read-only) 모드를 거쳐 트래픽을 신규 클러스터로 전환함으로써 사용자 경험에 지장을 주지 않는 제로 다운타임에 가까운 마이그레이션을 달성했습니다. **운영 자동화와 가시성 확보** * 수백 개의 샤드를 효율적으로 관리하기 위해 데이터베이스 팀은 쿼리 분석 및 자동 킬러(Query Killer) 시스템을 구축하여 비효율적인 쿼리가 전체 시스템에 영향을 주지 않도록 제어했습니다. * 대규모 분산 환경에서의 모니터링을 위해 통합 대시보드를 구축하고, 각 샤드의 성능 지표를 실시간으로 추적하여 병목 현상을 사전에 감지하고 대응하는 체계를 갖추었습니다. 성공적인 데이터베이스 스케일링은 단번에 이루어지는 것이 아니라, 수직적 분할로 시간을 벌고 그 사이 견고한 수평적 샤딩 전략을 수립하는 단계적인 접근이 필요합니다. 특히 Vitess와 같은 미들웨어 도입은 인프라 복잡성을 증가시키지만, 장기적으로는 트래픽 성장에 유연하게 대응할 수 있는 가장 확실한 투자입니다. 데이터 성장이 예견되는 초기 단계부터 데이터 간의 관계를 명확히 정의하고 적절한 샤딩 키를 고민하는 것이 미래의 마이그레이션 비용을 줄이는 핵심입니다.

Figma 데이터베이스 팀이 대 (새 탭에서 열림)

제시해주신 Figma의 기술 블로그 글 **"The growing pains of database architecture"**는 급격한 성장 과정에서 단일 Postgres 데이터베이스의 한계를 극복하기 위해 Figma 엔지니어링 팀이 수행한 아키텍처 혁신 과정을 다루고 있습니다. 이 글은 수직적 확장이 불가능한 시점에서 어떻게 가동 중단 없이 수평적 확장(Sharding) 체제로 전환했는지에 대한 기술적 여정을 상세히 설명합니다. --- Figma는 사용자 트래픽의 폭발적인 증가로 인해 AWS RDS의 가장 큰 인스턴스조차 감당할 수 없는 병목 현상에 직면했습니다. 이를 해결하기 위해 단순한 읽기 복제본 추가를 넘어, 데이터를 기능별로 나누는 '수직적 분할'과 동일 테이블을 여러 장비에 분산하는 '수평적 샤딩'을 단계적으로 도입했습니다. 결과적으로 Figma는 데이터베이스를 유연하게 확장할 수 있는 구조를 갖추게 되었으며, 이는 서비스 안정성과 성능을 획기적으로 향상시켰습니다. ### 수직적 확장의 한계와 초기 대응 * **단일 DB의 임계치 도달:** 초기에는 단일 AWS RDS 인스턴스에 모든 데이터를 저장했으나, 쓰기 작업량이 r5.24xlarge 등 최고 사양 인스턴스의 처리 용량을 넘어섰습니다. * **읽기 복제본(Read Replicas)의 활용:** 읽기 트래픽은 복제본을 통해 분산했으나, 데이터 수정이 빈번한 작업 특성상 복제 지연(Replication Lag)이 발생하여 사용자 경험에 악영향을 주었습니다. * **수직적 테이블 분할 (Vertical Partitioning):** 첫 번째 해결책으로 관련 있는 테이블들을 묶어 별도의 데이터베이스 인스턴스로 분리했습니다. 이는 단기적으로 부하를 분산했지만, 테이블 간 Join 쿼리가 불가능해지고 트랜잭션 관리가 복잡해지는 비용이 발생했습니다. ### 수평적 샤딩(Horizontal Sharding) 도입 과정 * **샤드 키(Shard Key) 선정:** 특정 테이블(예: 파일, 레이어)이 너무 커져서 단일 인스턴스에 담을 수 없게 되자, 데이터를 행(Row) 단위로 분산하는 샤딩을 결정했습니다. '조직 ID(Org ID)'를 주요 샤드 키로 설정하여 관련 데이터를 동일한 물리적 위치에 배치했습니다. * **쿼리 라우팅 계층 구축:** 애플리케이션과 DB 사이에 쿼리를 적절한 샤드로 전달하는 중간 계층(Query Router)을 직접 구현했습니다. 이를 통해 애플리케이션 코드는 데이터가 어느 물리적 서버에 있는지 몰라도 쿼리를 수행할 수 있게 되었습니다. * **Vitess의 검토와 채택:** 처음에는 자체 솔루션을 사용했으나, 관리의 복잡성을 줄이기 위해 오픈소스 데이터베이스 클러스터링 시스템인 Vitess 도입을 결정하고 이를 Postgres 환경에 맞게 최적화했습니다. ### 무중단 데이터 마이그레이션 전략 * **섀도우 쓰기(Shadow Writes):** 새로운 샤딩 환경을 구축한 후, 실시간 데이터를 기존 DB와 신규 DB에 동시에 기록하며 시스템의 안정성을 검증했습니다. * **데이터 검증(Data Validation):** 스냅샷 비교와 실시간 체크섬 확인을 통해 기존 데이터와 샤딩된 데이터 간의 일관성을 100% 보장했습니다. * **점진적 전환(Canary Rollout):** 전체 트래픽을 한 번에 옮기지 않고, 일부 사용자나 조직부터 단계적으로 신규 아키텍처로 전환하여 리스크를 최소화했습니다. ### 운영 효율화를 위한 도구 및 인프라 * **DBProxy 개발:** 수만 개의 애플리케이션 연결을 효율적으로 관리하기 위해 고성능 커넥션 풀링(Connection Pooling)과 쿼리 분석 기능을 갖춘 DBProxy를 구축했습니다. * **가시성(Observability) 확보:** 샤드별 부하 상태, 쿼리 성능, 복제 지연 등을 실시간으로 모니터링할 수 있는 대시보드를 구축하여 병목 지점을 즉각 파악하도록 했습니다. --- **결론 및 추천** Figma의 사례는 서비스 초기부터 복잡한 샤딩을 도입하기보다는, **수직적 분할 → 논리적 샤딩 → 물리적 샤딩**으로 이어지는 단계적 접근이 실무적으로 유효함을 보여줍니다. 데이터베이스 확장을 고민하는 팀이라면 처음부터 완벽한 분산 시스템을 구축하기보다, 데이터 간의 관계를 분석하여 적절한 샤드 키를 선정하고 쿼리 라우팅 계층을 추상화하는 작업부터 시작할 것을 권장합니다.

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

Figma는 세계 최초의 실시간 협업 디자인 도구로서, 다수의 사용자가 동시에 디자인 작업을 수행할 때 발생하는 데이터 동기화 문제를 해결하기 위해 자체적인 멀티플레이어 기술 스택을 구축했습니다. 이 시스템은 중앙 집중식 서버를 진실의 원천(Source of Truth)으로 삼아 클라이언트 간의 상태를 일관되게 유지하며, 복잡한 알고리즘 대신 도메인에 특화된 단순화된 충돌 해결 로직을 통해 성능과 사용자 경험을 동시에 잡았습니다. 결과적으로 Figma는 웹 환경에서도 네이티브 수준의 성능을 제공하며 실시간 협업의 기술적 표준을 제시하고 있습니다. ### 객체 기반 데이터 모델과 동기화 방식 * Figma의 디자인 파일은 객체(Node)들의 트리 구조로 구성되며, 각 객체는 고유한 ID와 속성(Property) 집합을 가집니다. * 일반적인 텍스트 편집기에서 사용하는 OT(Operational Transformation)나 복잡한 CRDT 방식 대신, 디자인 도구의 특성에 맞춰 '속성 단위의 결과적 일관성' 모델을 채택했습니다. * 문서 전체를 동기화하는 대신 변경된 속성만 패킷으로 전송하여 네트워크 부하를 최소화하고 효율적인 실시간 통신을 구현했습니다. ### 서버 중심의 상태 관리와 낙관적 업데이트 * 중앙 서버는 동기화 허브 역할을 수행하며, 클라이언트로부터 받은 변경 사항을 정렬하고 다른 참여자들에게 전파합니다. * 클라이언트는 네트워크 지연 시간 동안에도 사용자에게 즉각적인 반응성을 제공하기 위해 '낙관적 업데이트'를 적용합니다. * 서버에서 승인된 최종 상태가 클라이언트에 도착하면, 클라이언트는 자신의 로컬 상태를 서버의 상태에 맞춰 재정렬(Rebase)하여 최종적인 일관성을 유지합니다. ### 효율적인 충돌 해결 로직 * 단순 속성 변경의 경우 '마지막에 작성한 사람이 승리(Last Writer Wins)'하는 방식을 사용하여 충돌 해결 프로세스를 단순화했습니다. * 레이어 계층 구조 관리 시 발생할 수 있는 순환 참조 문제(예: 부모 노드가 자신의 자식 노드 하위로 들어가는 경우)를 방지하기 위한 특수한 유효성 검사 로직을 서버와 클라이언트에 동일하게 구현했습니다. * 여러 사용자가 동일한 객체의 서로 다른 속성(예: 하나는 색상, 하나는 크기)을 수정할 때는 충돌 없이 자연스럽게 병합되도록 설계되었습니다. ### WebAssembly를 활용한 성능 최적화 * 브라우저 환경에서 대규모 디자인 파일을 부드럽게 처리하기 위해 핵심 편집 엔진을 C++로 작성하고, 이를 WebAssembly로 컴파일하여 실행합니다. * 이를 통해 자바스크립트의 가비지 컬렉션으로 인한 성능 저하를 피하고, 복잡한 벡터 연산과 렌더링을 네이티브 앱에 가까운 속도로 수행할 수 있습니다. * 클라이언트와 서버 간의 데이터 직렬화 및 역직렬화 과정에서도 고성능 바이너리 포맷을 사용하여 데이터 전송 효율을 극대화했습니다. Figma의 기술적 선택은 복잡한 실시간 시스템을 구축할 때 학술적인 표준 알고리즘을 맹목적으로 따르기보다, 비즈니스 도메인의 특성에 맞춰 시스템을 단순화하는 것이 얼마나 효율적인지 잘 보여줍니다. 고성능 웹 애플리케이션을 지향한다면 WebAssembly를 통한 엔진 구축과 서버 중심의 명확한 상태 관리 전략을 검토해 볼 가치가 있습니다.

데이터베이스 아키텍처 (새 탭에서 열림)

피그마(Figma)는 급격한 사용자 증가에 따른 데이터베이스 부하 문제를 해결하기 위해 단일 Postgres 인스턴스에서 분산된 Vitess(MySQL 기반) 클러스터로 전환하는 대규모 샤딩 프로젝트를 성공적으로 완수했습니다. 이 과정에서 피그마 엔지니어링 팀은 서비스 중단 없이 테라바이트급 데이터를 이전하기 위해 정교한 실시간 복제 및 검증 시스템을 구축했습니다. 결론적으로 이들은 인프라의 한계를 미리 예측하고, 애플리케이션 계층의 수정을 최소화하면서도 수평적 확장이 가능한 데이터 아키텍처를 확보하게 되었습니다. ### 수직적 확장의 한계와 샤딩의 필연성 * 초기 피그마는 단일 AWS RDS Postgres 인스턴스에 의존했으나, 트래픽이 급증하며 가장 큰 인스턴스 크기로도 쓰기 부하를 감당할 수 없는 임계점에 도달했습니다. * 수직적 확장(Vertical Scaling)과 읽기 복제본(Read Replicas) 추가만으로는 쓰기 성능 문제를 해결할 수 없음을 인지하고, 데이터를 여러 노드에 나누어 저장하는 수평적 확장(Sharding)을 결정했습니다. * 자체적인 샤딩 솔루션을 구축하는 대신, 유튜브 등에서 검증된 오픈소스 데이터베이스 클러스터링 시스템인 Vitess를 도입하여 운영 복잡성을 관리하기로 했습니다. ### Postgres에서 Vitess로의 대규모 이관 전략 * 기존 Postgres 환경에서 MySQL 기반의 Vitess로 전환하는 것은 데이터 모델과 쿼리 호환성 측면에서 큰 도전이었으며, 이를 위해 'FDB(Figma Database)'라는 중간 레이어를 구축했습니다. * **Shadow Writing(새도우 라이팅):** 모든 쓰기 작업을 기존 DB와 새 Vitess DB에 동시에 수행하여 데이터 정합성을 실시간으로 확인했습니다. * **Logical Replication(논리적 복제):** 기존 데이터를 중단 없이 옮기기 위해 CDC(Change Data Capture) 기술을 활용하여 소스 데이터베이스의 변경 사항을 실시간으로 Vitess에 반영했습니다. ### 무중단 컷오버와 정합성 검증 * 데이터 이전의 신뢰성을 확보하기 위해 'Consistency Checker'를 가동하여 기존 DB와 새 DB의 레코드를 지속적으로 비교하고 불일치를 해결했습니다. * **Query Replay:** 실제 운영 트래픽을 복제하여 대상 시스템에 미리 실행해 봄으로써 성능 병목 지점과 쿼리 호환성 문제를 사전에 파악했습니다. * 최종 전환 시에는 아주 짧은 읽기 전용(Read-only) 시간을 가진 후, 트래픽의 방향을 Vitess로 돌리는 방식을 통해 사용자 경험에 영향을 주지 않고 성공적으로 전환했습니다. ### 개발자 경험 보존을 위한 쿼리 라우팅 * 샤딩된 환경에서도 개발자들이 개별 샤드의 위치를 신경 쓰지 않고 개발할 수 있도록 투명한 쿼리 라우팅 시스템을 구현했습니다. * 크로스 샤드 조인(Cross-shard join)과 같이 분산 환경에서 성능이 저하될 수 있는 쿼리들을 모니터링하고, 필요에 따라 스키마 설계를 최적화하여 분산 시스템의 성능 이점을 극대화했습니다. * 애플리케이션 코드의 대대적인 수정 없이도 샤딩된 데이터베이스를 활용할 수 있게 함으로써 피쳐 개발 속도를 유지했습니다. 급격히 성장하는 서비스에서 데이터베이스 확장은 피할 수 없는 과제이며, 이를 위해 서비스 초기부터 데이터 간의 관계(Entity Groups)를 명확히 정의해두는 것이 추후 샤딩 난이도를 낮추는 데 결정적인 역할을 합니다. 또한, 대규모 인프라 변경 시에는 완벽한 자동화보다는 단계적인 검증과 새도우 트래픽 테스트를 통해 데이터 유실 리스크를 최소화하는 보수적인 접근 방식이 권장됩니다.