stripe·2026년 4월 29일원문

Sessions 2026에서 발표한 모든 것 (새 탭에서 열림)

Stripe는 연례 컨퍼런스 'Stripe Sessions'를 통해 AI 에이전트 경제를 지원하기 위한 혁신적인 결제 인프라와 288개의 신규 기능을 발표했습니다. 이번 업데이트의 핵심은 AI 에이전트가 직접 결제를 수행하는 '에이전틱 커머스(Agentic Commerce)'의 구현과 기업들이 전 세계 어디서나 지능적이고 안전하게 비즈니스를 확장할 수 있도록 돕는 프로그래밍 가능한 금융 네트워크 구축에 있습니다. Stripe는 이를 통해 AI 중심의 새로운 경제 생태계를 위한 기반을 마련하고 결제 전환율과 보안성을 동시에 극대화한다는 결론을 제시합니다. **AI 에이전트 상거래와 프로그래밍 가능한 결제 (Agentic Commerce)** * AI 에이전트가 직접 제품을 검색하고 결제까지 수행할 수 있는 'Agentic Commerce Suite'를 출시하여, 기업이 대시보드에서 에이전트의 접근 권한을 직접 관리할 수 있게 합니다. * 구글의 Universal Commerce Protocol(UCP) 및 메타와의 파트너십을 통해 AI 검색 환경이나 페이스북 광고 내에서 이탈 없는 즉시 결제 흐름을 구현했습니다. * 머신 결제 프로토콜(MPP)과 공유 결제 토큰(SPT)을 도입하여 에이전트가 카드, 법정화폐뿐만 아니라 스테이블코인으로도 소액 결제 및 정기 결제를 수행할 수 있는 기술적 토대를 마련했습니다. * 'Link' 에이전트 지갑을 통해 기업은 에이전트에게 결제 권한을 부여하면서도, 지출 승인 및 구매 내역 가시성을 유지하며 통제력을 확보할 수 있습니다. **최적화된 체크아웃 및 글로벌 결제 인프라 확장** * AI 어시스턴트, 라이브 트랜잭션 재생, A/B 테스트 기능을 갖춘 'Checkout Studio'를 공개하여 기업이 클릭 몇 번으로 결제 화면을 분석하고 최적화할 수 있도록 지원합니다. * 'Adaptive Pricing AI' 모델을 적용하여 실시간으로 고객의 세션 신호를 분석하고, 고객이 선호하는 통화와 현지화된 구독 가격을 자동으로 표시합니다. * 신규 하드웨어 'Stripe Reader T600' 출시와 더불어 홍콩, 멕시코 등 15개 신규 시장으로 오프라인 결제(Terminal) 서비스를 확대하고, 별도의 POS 기기 없이 리더기만으로 결제를 시작할 수 있는 '독립형 모드'를 선보였습니다. * 디지털 비즈니스를 위한 'Managed Payments' 솔루션을 통해 80개국 이상의 간접세 준수, 사기 방지, 고객 지원을 Stripe가 대행하는 판매 기록(Merchant of Record) 서비스를 제공합니다. **AI 기반의 지능형 보안 및 사기 방지 (Radar & Intelligence)** * Radar 업데이트를 통해 무료 체험판 남용, 봇을 활용한 부정 결제, 계정 공유 및 다중 계정 생성 등 고도화된 사기 패턴을 정교하게 탐지합니다. * 각 비즈니스 고유의 신호와 Stripe의 글로벌 네트워크 인텔리전스를 결합한 '맞춤형 Radar 모델'을 통해 개별 기업 환경에 최적화된 사기 방지 정책을 수립할 수 있습니다. * 'Authorization Boost'에 AI 최적화 기술을 적용하여 데이터 전용 인증 흐름과 PIN 없는 직불카드 재시도를 지원함으로써, 승인율을 평균 3.8% 높이고 처리 비용을 최대 3.3% 절감합니다. * AI 기반의 'Smart Disputes' 기능을 통해 증거 서류를 자동으로 추천받고 관리함으로써 분쟁 해결 성공률을 높였습니다. **수익 모델 다변화를 위한 빌링 시스템 고도화** * AI 네이티브 비즈니스 모델을 지원하기 위해 실시간 미터링, 차원별 가격 책정(Dimensional Pricing), 스트리밍 결제 기능을 강화했습니다. * Stripe Billing의 사용자 정의 기능을 확대하고 실시간 데이터 쿼리 접근성을 높여, 복잡한 구독 모델이나 사용량 기반 과금 체계를 더욱 유연하게 운영할 수 있게 했습니다. 기업들은 이번에 발표된 Stripe의 도구들을 활용해 단순한 결제 처리를 넘어 AI 에이전트 중심의 미래 상거래 환경에 선제적으로 대응할 수 있습니다. 특히 글로벌 시장 진출 시 복잡한 세금 및 규제 문제를 해결해 주는 'Managed Payments'와 AI 기반의 승인율 최적화 도구를 적극 도입하여 운영 효율과 매출을 동시에 극대화할 것을 추천합니다.

real-time-datastripeagentic-commercefraud-detection+4

stripe·2026년 3월 20일원문

MRC Vegas 2026의 3가지 주요 사기 트렌드 (새 탭에서 열림)

MRC Vegas 2024 컨퍼런스에서 논의된 바에 따르면, 최근 사기(Fraud) 패턴은 더욱 자동화되고 정교해져 전통적인 규칙 기반 도구로는 탐지하기가 점점 어려워지고 있습니다. 이에 선도적인 기업들은 모든 사용자에게 동일한 보안 척도를 적용하는 대신, 사용자 의도를 파악해 신뢰를 기반으로 마찰을 줄이는 동적 인증 전략으로 선회하고 있습니다. 결론적으로 현대의 보안은 결제 인프라 내에 실시간 AI 탐지 기능을 내장하고, 생성형 AI를 활용한 딥페이크 위협에 대응하기 위해 다층적인 신원 검증 체계를 구축하는 방향으로 진화해야 합니다. **사용자 의도에 기반한 동적 인증 도입** * 모든 사용자에게 일괄적인 인증 절차를 요구하는 방식은 정상적인 고객의 결제 이탈을 초래하고 고객 생애 가치(LTV)를 훼손하는 부작용이 큽니다. * '높은 신뢰 속도(High-trust velocity)' 개념을 도입해 사용자의 과거 행동 패턴을 분석하고, 신뢰도가 높은 대다수 사용자에게는 결제 마찰을 완전히 제거해야 합니다. * Stripe Radar의 '적응형 3DS'와 같이 AI가 리스크를 실시간으로 평가하여 비정상적인 1%의 트래픽에만 인증을 요구하는 방식을 통해 사기를 30% 이상 줄일 수 있습니다. **에이전트 커머스에 최적화된 결제 인프라** * AI 에이전트가 인간을 대신해 구매를 수행하는 에이전트 커머스 시대에는 사후 분석이 아닌, 결제 흐름(Payment Fabric) 자체에 보안이 내장되어야 합니다. * 정적인 규칙 기반 시스템은 AI 에이전트의 복잡한 구매 패턴을 감당할 수 없으므로, 실시간으로 변화하는 데이터 신호에 반응하는 시스템이 필요합니다. * '공유 결제 토큰(Shared Payment Tokens)' 기술을 사용하면 결제 정보를 노출하지 않으면서도, 카드 테스팅이나 도난 카드 사용 여부 등의 리스크 신호를 실시간으로 전달하여 신뢰할 수 있는 에이전트와 악성 봇을 구분할 수 있습니다. **딥페이크 및 합성 신원 위협 대응** * 생성형 AI의 발전으로 가짜 신분증 제작이나 음성·영상 복제가 매우 쉬워졌으며, 이는 단순한 신원 확인 절차를 무력화하고 있습니다. * 단일 검구만으로는 정교한 위조를 막을 수 없으므로, 서명의 미세한 차이나 사진의 반전 여부, 만료일 데이터 불일치 등 아주 구체적인 이상 징후를 찾는 다층적 검증이 필수입니다. * 신분증 사진과 실시간 셀카 대조, 글로벌 데이터베이스를 활용한 주소 및 신원 정보 교차 검증 등 AI 기반의 프로그래밍 방식 신원 확인 솔루션을 도입해야 합니다. 자동화된 사기 위협으로부터 비즈니스를 보호하기 위해서는 고정된 보안 규칙에서 벗어나 AI가 통합된 유연한 결제 시스템을 채택해야 합니다. 동적 인증과 다층 검증 체계를 결합함으로써 보안 수준은 높이되, 선량한 고객에게는 매끄러운 결제 경험을 제공하는 것이 현대 이커머스 전략의 핵심입니다.

real-time-data머신러닝생성형 AIstripe+4

netflix·2025년 11월 14일원문

넷플릭스가 실시간 분산 그래프를 구축한 방법과 이유: 1부 — 인터넷 규모의 데이터 스트림 수집 및 처리 (새 탭에서 열림)

넷플릭스는 비디오 스트리밍을 넘어 광고, 라이브 이벤트, 모바일 게임으로 비즈니스를 확장하면서 발생하는 데이터 파편화 문제를 해결하기 위해 '실시간 분산 그래프(RDG)'를 구축했습니다. 기존 마이크로서비스 아키텍처에서 발생하는 데이터 고립을 극복하고, 다양한 서비스 접점에서 발생하는 사용자 활동을 실시간으로 연결하여 개인화된 경험을 제공하는 것이 핵심 목표입니다. 이를 통해 복잡한 데이터 조인 없이도 수억 개의 노드와 엣지 사이의 관계를 즉각적으로 파악할 수 있는 기술적 기반을 마련했습니다. **데이터 파편화와 비즈니스 환경의 변화** * 스트리밍, 게임, 라이브 스포츠 등 서비스 영역이 넓어지면서 사용자가 여러 기기와 도메인에서 수행하는 활동을 하나의 맥락으로 통합해야 할 필요성이 커짐. * 넷플릭스의 강점인 마이크로서비스 아키텍처(MSA)는 서비스 독립성에는 유리하지만, 데이터가 각 서비스에 고립(Silo)되어 있어 통합적인 데이터 과학 및 엔지니어링 작업에 큰 비용이 발생함. * 기존 데이터 웨어하우스 방식은 데이터가 서로 다른 테이블에 저장되고 처리 주기가 제각각이라, 실시간으로 연관 관계를 분석하는 데 한계가 있음. **그래프 모델 도입의 기술적 이점** * **관계 중심 쿼리:** 테이블 기반 모델에서 필요한 비용 중심적인 조인(Join)이나 수동적인 비정규화 없이도 노드와 엣지 사이를 빠르게 탐색(Hop)할 수 있음. * **유연한 확장성:** 새로운 엔티티나 관계 유형이 추가될 때 대대적인 스키마 변경이나 아키텍처 재설계 없이도 신속하게 데이터 모델을 확장할 수 있음. * **패턴 및 이상 탐지:** 숨겨진 관계, 순환(Cycle) 구조, 그룹화 등을 식별하는 작업을 기존의 포인트 조회 방식보다 훨씬 효율적으로 수행함. **실시간 데이터 수집 및 처리 파이프라인 (RDG 레이어 1)** * 전체 시스템은 수집 및 처리, 저장, 서빙의 3개 레이어로 구성되며, 첫 번째 단계인 수집 레이어는 이기종 업스트림 소스로부터 이벤트를 받아 그래프 데이터를 생성함. * DB의 변경 사항을 추적하는 CDC(Change Data Capture)와 애플리케이션의 실시간 로그 이벤트를 주요 소스로 활용하여 데이터 소외 현상을 방지함. * 수집된 원시 데이터는 스트리밍 처리 엔진을 통해 그래프 스키마에 맞는 노드와 엣지 형태로 변환되며, 대규모 트래픽 환경에서도 실시간성을 유지하도록 설계됨. 복잡하게 얽힌 현대의 서비스 환경에서 데이터 간의 관계를 실시간으로 규명하는 것은 사용자 경험 고도화의 핵심입니다. 넷플릭스의 RDG 사례처럼 파편화된 마이크로서비스의 데이터를 그래프 형태로 통합하는 접근 방식은, 실시간 통찰력이 필요한 대규모 분산 시스템 설계 시 강력한 해결책이 될 수 있습니다.

real-time-data분산 시스템마이크로서비스data-architecture+3

netflix·2025년 10월 21일원문

스트림 뒤편: 라이브 이벤트를 위한 실시간 추천 3부 | 넷플릭스 기술 블로그 | 넷플릭스 테크블로그 (새 탭에서 열림)

넷플릭스는 수천만 명의 시청자가 동시에 접속하는 라이브 이벤트 상황에서 시스템 과부하를 방지하면서도 실시간 개인화 추천을 제공하기 위해 '프리페칭(Prefetching)'과 '실시간 브로드캐스팅'이라는 2단계 전략을 도입했습니다. 이 시스템은 이벤트 시작 전 미리 데이터를 기기에 저장해 두었다가, 실제 시작 시점에는 최소한의 신호만 보내 로컬에서 추천 정보를 활성화함으로써 '천둥 번개 효과(Thundering Herd)' 문제를 효과적으로 해결합니다. 이를 통해 넷플릭스는 클라우드 자원을 무리하게 확장하지 않고도 전 세계 수억 대의 기기에 지연 없는 실시간 스트리밍 경험을 제공할 수 있게 되었습니다. **라이브 이벤트와 시동 시간의 제약** * VOD와 달리 라이브 이벤트는 모든 시청자가 특정 시점에 동시에 접속하므로, 짧은 시간 내에 수억 개의 기기에 업데이트를 전달해야 하는 기술적 난관이 존재합니다. * 단순히 서버를 증설하는 선형적 확장은 비효율적이며, 다른 핵심 서비스의 자원을 고갈시킬 위험이 있습니다. * 성공적인 실시간 추천을 위해서는 업데이트 소요 시간(Time), 서비스 처리 용량(Request Throughput), 요청의 다양성(Compute Cardinality)이라는 세 가지 제약 조건을 동시에 최적화해야 합니다. **프리페칭을 통한 트래픽 분산** * 이벤트 시작 전 사용자가 평소처럼 앱을 탐색하는 동안, 라이브 이벤트와 관련된 메타데이터, 아트워크, 개인화된 추천 리스트를 미리 기기 캐시에 저장합니다. * 이를 통해 서버 요청을 시간에 따라 자연스럽게 분산시켜, 이벤트 직전 발생하는 트래픽 스파이크를 제거하고 시스템 안정성을 확보합니다. * 서버 측에서 미리 계산된 '구체화된 추천(Materialized Recommendations)'을 제공함으로써 기기별 요청의 복잡도를 낮춥니다. **저카디널리티 실시간 브로드캐스팅** * 이벤트가 실제로 시작되거나 일정이 변경될 때, 넷플릭스의 푸시 서비스(Zuul Push)를 통해 연결된 모든 기기에 '저카디널리티(Low-cardinality)' 메시지를 전송합니다. * 이 메시지는 복잡한 데이터를 담지 않고 단순히 미리 캐싱된 데이터를 화면에 표시하라는 트리거 역할만 수행하여 네트워크 부하를 최소화합니다. * '최소 한 번(At-least-once)' 전달 방식을 채택하여 네트워크 상태가 불안정한 기기도 다시 온라인 상태가 되면 누락된 업데이트를 즉시 따라잡을 수 있도록 설계되었습니다. **데이터 기반의 동적 적응** * 라이브 이벤트의 특성상 경기 시간이 지연되거나 일정이 변동될 수 있는데, 브로드캐스팅 시스템은 이러한 실시간 제작 상황에 맞춰 전송 타이밍을 동적으로 조절합니다. * 수천만 대의 기기가 동시에 서버에 데이터를 재요청하는 대신 로컬 데이터를 활용하게 함으로써, 전 세계 모든 사용자가 동일한 순간에 일관된 추천 UI를 볼 수 있게 합니다. 라이브 이벤트와 같은 초고부하 상황에서는 무조건적인 서버 증설보다는 클라이언트의 로컬 자원을 활용하고 서버 부하를 시간적으로 분산하는 아키텍처가 필수적입니다. 실시간성이 중요한 서비스라면 모든 데이터를 실시간으로 전송하기보다, 정적인 데이터는 미리 배치하고 상태 변화를 알리는 최소한의 신호만 실시간으로 처리하는 하이브리드 접근 방식을 권장합니다.

real-time-data분산 시스템recommendation-systemscaching+4

datadog·2025년 8월 12일원문

규모를 줄여 100배 향상한 실시간 프로세스 메트릭 효율성 (새 탭에서 열림)

Datadog은 프로세스 및 컨테이너 모니터링 시스템의 실시간 데이터 처리 방식을 '호스트 구독(Host Subscription)' 기반 모델로 전환하여 확장성 문제를 해결했습니다. 사용자가 현재 화면에서 보고 있는 특정 호스트(최대 50개)에 대해서만 2초 간격의 고빈도 수집을 활성화함으로써, 전체 트래픽 볼륨을 100배 줄이고 인프라 비용을 98% 절감하는 성과를 거두었습니다. 이 글은 불필요한 데이터 수집을 최소화하면서도 사용자 경험과 시스템 효율성을 동시에 개선한 기술적 여정을 다룹니다. ## 기존 실시간 데이터 수집의 한계 * **전체 활성화 방식의 비효율성:** 기존에는 테넌트 내 한 명의 사용자만 페이지를 조회해도 해당 테넌트 전체 인프라의 모든 호스트에서 2초 간격의 데이터 수집이 시작되었습니다. 이로 인해 초당 수백만 개의 프로세스 데이터가 유입되는 부하가 발생했습니다. * **수평적 확장 불가능:** 실시간 정렬 기능을 제공하기 위해 테넌트의 모든 데이터를 단일 서버의 메모리에 보관해야 했습니다. 이는 시스템을 수평적으로 확장하는 것을 불가능하게 만들었으며, 서버 사양을 높이는 수직적 확장에만 의존하게 했습니다. * **리소스 낭비:** 실제 사용자가 한 번에 확인하는 프로세스는 약 50개 내외임에도 불구하고, 보이지 않는 수만 개의 프로세스 데이터를 실시간으로 수집하고 처리하는 비효율이 존재했습니다. ## 사용자 가시성 중심의 설계 전환 * **실시간 수집 대상의 최소화:** 사용자가 보고 있는 화면에 노출된 프로세스가 실행 중인 호스트에 대해서만 실시간 모드를 활성화하도록 전략을 수정했습니다. * **데이터 용도 분리 및 정렬 로직 최적화:** 2초 간격의 실시간 데이터는 화면 갱신에만 사용하고, 10초마다 수행되는 정렬 작업에는 일반적인 10초 간격 데이터를 활용하도록 변경했습니다. * **시스템 단순화:** 실시간 뷰와 히스토리 뷰에서 동일한 정렬 로직을 사용할 수 있게 되어 시스템 복잡성이 줄어들었고, 고빈도 메트릭을 메모리에 상주시켜야 할 필요성도 사라졌습니다. ## 호스트 구독 모델 및 필터링 최적화 * **호스트 구독(Host Subscription) 도입:** 사용자가 현재 보고 있는 호스트 목록을 추적하고, 이 상태를 Kafka를 통해 인테이크(Intake) 서비스와 라이브 서버 간에 공유합니다. * **조기 필터링(Early Filtering):** 구독 정보를 바탕으로 데이터 수집 단계(Intake)에서부터 필요한 데이터만 선별하여 처리합니다. 이는 Datadog 에이전트와 백엔드 서버 모두의 부하를 줄이는 핵심 기여를 했습니다. * **성능 개선 결과:** 개념 증명(PoC) 단계에서 이미 라이브 데이터 서버의 메모리 사용량은 85%, CPU 사용량은 33% 감소했으며, 이는 시스템 전체의 안정성 향상으로 이어졌습니다. 대규모 인프라 모니터링 환경에서 모든 데이터를 실시간으로 수집하는 것은 막대한 비용과 확장성 문제를 야기합니다. 사용자의 가시성 범위 내로 수집 대상을 제한하고 데이터의 용도(갱신 vs 정렬)에 따라 수집 빈도를 이원화하는 접근 방식은 리소스 효율성을 극대화하면서도 고성능 실시간 뷰를 제공할 수 있는 실용적인 해결책이 됩니다.

real-time-data데이터베이스 설계datadogApache Kafka+4

figma·2024년 5월 16일·3분 읽기큐레이션 요약

대규모 실시간 데이터를

Figma의 실시간 데이터 서비스 LiveGraph는 사용자와 쿼리 증가, 데이터베이스 샤딩으로 기존 구조의 한계에 도달했다. Figma는 초기 로컬 캐시와 단일 PostgreSQL의 전역 변경 스트림에 의존하던 아키텍처를 100배 규모까지 확장할 수 있도록 근본적으로 재설계하려 했다. 새 설계의 목표는 성능과 안정성을 유지하면서 데이터베이스 샤드와 읽기·업데이트 부하를 독립적으로 확장하고, 사용자 영향 없이 점진적으로 마이그레이션하는 것이다. ## LiveGraph의 역할 - LiveGraph는 GraphQL과 유사한 쿼리를 구독하는 웹 API를 제공한다. - 쿼리 결과를 JSON 트리로 반환하며, 객체와 관계를 정의한 스키마와 특정 그래프 일부를 조회하는 뷰를 사용한다. - Figma의 커스텀 React Hook을 통해 데이터가 변경되면 프런트엔드가 자동으로 다시 렌더링된다. - 캔버스 공동 편집, 댓글, FigJam 투표 등 여러 협업 기능에서 최신 데이터를 유지하는 기반 역할을 한다. ## 규모 증가로 드러난 문제 - 2021년 이후 LiveGraph 세션 수가 3배 증가했다. - 최근 1년 동안 뷰 요청 수는 5배 늘어났고, 세션 하나의 처리 비용도 점점 커졌다. - 데이터베이스 역시 단일 PostgreSQL 인스턴스에서 여러 수직·수평 샤드 구조로 변화하고 있었다. - 따라서 문제는 단순히 각 LiveGraph 서버가 데이터베이스 변경 사항을 모두 수집하는 데 그치지 않고, 클라이언트 세션·읽기 요청·데이터베이스 업데이트가 동시에 증가하는 복합적인 확장성 문제였다. ## LiveGraph 100x의 설계 목표 Figma는 현재의 읽기 및 데이터베이스 업데이트 부하를 장기적으로 100배까지 처리하기 위한 “LiveGraph 100x” 계획을 시작했다. - **서비스 속도 유지** - 초기 로드 시간과 실시간 업데이트에 대한 SLO를 유지하거나 개선해야 했다. - **데이터베이스 확장 지원** - 수직 확장뿐 아니라 수평 샤딩도 기본적으로 지원해야 했다. - 샤드가 늘어나도 신뢰성과 성능이 저하되지 않아야 했다. - **독립적인 확장 수단 확보** - 클라이언트 읽기량이 증가할 때와 쿼리 업데이트량이 증가할 때 서로 다른 구성 요소를 확장할 수 있어야 했다. - **안전한 점진적 마이그레이션** - 기존 LiveGraph 사용자를 중단시키지 않고 단계적으로 구조를 개선해야 했다. ## 초기 아키텍처와 변경 스트림 초기 LiveGraph는 단일 PostgreSQL과 하나의 서버를 중심으로 구성됐다. - PostgreSQL의 논리적 복제 스트림은 WAL에 기록된 행 단위 변경 사항을 전달한다. - 각 변경에는 행의 변경 전·후 이미지와 단조 증가하는 시퀀스 번호가 포함된다. - LiveGraph는 이 스트림을 추적해 데이터 변경을 실시간 업데이트로 재사용했다. - 모든 LiveGraph 쿼리는 기본 데이터베이스인 primary를 조회했다. - 서버 내부에는 인메모리 쿼리 캐시가 있었고, PostgreSQL의 각 행 변경이 발생할 때마다 관련 쿼리 결과를 직접 수정했다. - 즉, 캐시는 전체 결과를 다시 계산하기보다 개별 mutation을 결과에 반영하는 방식이었다. ## 단일 데이터베이스 구조의 한계 초기 구조에서는 데이터베이스가 하나였기 때문에 변경 스트림의 전역 순서를 가정할 수 있었다. - 모든 변경 사항이 하나의 PostgreSQL 인스턴스에서 생성됐다. - 따라서 LiveGraph는 하나의 전역적으로 정렬된 업데이트 스트림을 처리하면 됐다. - 하지만 단일 PostgreSQL 인스턴스가 용량 한계에 도달하면서 데이터베이스를 여러 수직 샤드로 나누게 됐다. - 여러 샤드가 동시에 변경 사항을 생성하면서 업데이트의 전역 순서가 더 이상 보장되지 않았다. - 기존의 “하나의 전역 순서 스트림”이라는 가정은 샤딩된 데이터베이스 환경에서 유지될 수 없었다. ## 재설계가 필요해진 이유 - LiveGraph는 데이터베이스 확장에 맞춰 변경 사항 수집과 캐시 갱신 방식을 바꿔야 했다. - 수직·수평 샤딩 환경에서는 여러 변경 스트림을 안정적으로 처리해야 한다. - 읽기 요청과 실시간 업데이트가 서로 다른 속도로 증가하므로, 전체 시스템을 한 방식으로만 확장해서는 효율적이지 않다. - Figma는 데이터베이스 용량 문제에 신속히 대응하면서도 기존 서비스의 성능과 안정성을 유지할 수 있는 전략적 변경이 필요했다. 실무적으로는 단일 데이터베이스의 전역 순서와 중앙 캐시에 의존하는 실시간 시스템이 초기에는 단순하고 효율적이지만, 샤딩 단계에서는 변경 순서·캐시 일관성·부하 분리 문제를 별도로 설계해야 한다는 점을 보여준다.

원문 읽기(새 탭에서 열림)

real-time-dataPostgreSQL분산 시스템GraphQL+4

figma·2021년 10월 13일·4분 읽기큐레이션 요약

LiveGraph: Figma의 실시간

Figma는 실시간 협업 제품에 필요한 데이터를 안정적으로 제공하기 위해 Postgres 위에 GraphQL 기반의 실시간 데이터 계층인 LiveGraph를 구축했다. LiveGraph는 프론트엔드가 선언적으로 데이터를 구독하면 데이터베이스 복제 스트림을 읽어 밀리초 단위로 변경 사항을 반영한다. 이를 통해 수동 이벤트 메시지와 클라이언트 상태 동기화의 복잡성을 줄이고, 대규모 실시간 데이터 구독을 지원한다. ## Figma에서 실시간 데이터가 필요한 이유 - 협업자가 파일을 추가하거나 권한을 변경하면 다른 사용자 화면에도 새로고침 없이 즉시 반영되어야 한다. - 따라서 서버에서 데이터를 한 번 가져오는 것만으로는 부족하며, 클라이언트가 현재 관심 있는 데이터의 변경 사항을 계속 받아야 한다. - 인프라 팀의 목표는 제품 개발자가 데이터 전파 방식이나 WebSocket 세부 구현을 직접 관리하지 않고도 실시간 뷰를 만들 수 있게 하는 것이었다. ## 기존 방식의 한계 - 초기에는 React 프론트엔드가 Ruby HTTP 엔드포인트에서 필요한 데이터를 한 번에 받아 Redux 전역 상태에 저장했다. - 데이터 변경 시 백엔드 코드에서 관련 클라이언트에 보낼 이벤트 메시지를 직접 작성하고, 프론트엔드는 WebSocket으로 이벤트를 받아 상태를 갱신했다. - 사용자와 데이터 규모가 커지면서 모든 데이터를 한 번에 로드하기 어려워졌고, 데이터를 점진적으로 불러오면서 다음 문제가 발생했다. - 특정 데이터가 메모리에 항상 존재한다는 보장이 없어짐 - 여러 제품 영역이 같은 데이터를 사용할 때 데이터 로딩 책임이 불분명해짐 - 이벤트를 어느 시점에 보내고 받아야 하는지 관리하기 어려워짐 - 단순한 “새 파일 생성” 이벤트와 달리 권한 변경은 다른 리소스의 가시성까지 연쇄적으로 바꿀 수 있어 이벤트 설계가 복잡했다. - 데이터베이스 쓰기 순서와 실시간 메시지의 송수신 순서가 항상 일치한다는 보장도 없었다. - 그 결과 클라이언트 상태가 서버 상태의 올바른 부분집합을 반영하지 못하는 일관성 버그가 발생했다. ## GraphQL 기반 Live Query 선택 - Figma는 개발자가 실시간 데이터 구독을 선언적으로 정의할 수 있는 일반적인 프레임워크가 필요하다고 판단했다. - GraphQL을 인터페이스로 사용하면 필요한 데이터와 관계를 쿼리로 표현하고, 시스템이 해당 데이터를 자동으로 가져오고 최신 상태로 유지할 수 있다. - 여기서 말하는 GraphQL 구독은 일반적인 이벤트 스트림 구독과 다르다. - GraphQL의 전통적인 `subscription`은 이벤트 메시지를 전달하는 방식에 가깝다. - LiveGraph가 목표로 한 것은 쿼리 결과 자체를 계속 갱신하는 “Live Query” 방식이다. - 프론트엔드는 GraphQL과 유사한 쿼리를 보내고, 서버는 결과를 JSON 트리로 반환한다. - 서버에는 엔터티와 관계를 정의하는 스키마 및 그래프의 일부를 조회할 수 있는 뷰가 존재한다. ## 기존 실시간 데이터베이스 대신 자체 구축한 이유 - Figma는 이미 Postgres를 대규모로 운영하고 있었기 때문에 Firebase나 RethinkDB 같은 별도의 실시간 데이터베이스로 이전할 수 없었다. - LiveGraph는 새로운 저장소가 아니라 기존 Postgres 위에 동작하는 쿼리 엔진이 되어야 했다. - Figma의 Multiplayer 시스템은 파일 단위의 쓰기와 충돌 해결을 담당하지만, LiveGraph는 여러 데이터의 조회와 실시간 동기화를 담당한다. - Hasura, Prisma, PostGraphile 등 GraphQL 기술도 검토했지만, 대규모 동시 구독을 핵심 요구사항으로 설계된 것은 아니었다. - Figma는 실시간 구독 수가 많아질수록 데이터베이스 부하가 커지는 폴링 방식도 피하고자 했다. - 폴링은 쿼리마다 주기를 정해야 한다. - 구독 수가 늘어나면 동일한 쿼리가 반복 실행되어 데이터베이스 부하가 증가한다. - 폴링보다 변경 발생 시점에 가까운 낮은 지연 시간을 확보하기 어렵다. ## 데이터베이스 복제 스트림 기반 설계 - LiveGraph는 주기적으로 데이터를 다시 조회하는 대신 Postgres의 데이터베이스 복제 로그를 추적한다. - 복제 스트림에서 변경 사항을 읽으면 실제 데이터베이스 변경을 감지한 뒤 구독 중인 쿼리 결과를 갱신할 수 있다. - 이 방식은 폴링보다 빠른 업데이트 지연 시간을 제공한다. - 다만 LiveGraph가 데이터베이스의 전체 변경량을 읽어야 하므로, 대규모 환경에서는 확장성이 중요하다. - Figma는 여러 데이터베이스 샤드의 변경 사항을 여러 머신에 분산 처리할 수 있는 구조를 고려했다. - 최종적으로 LiveGraph를 자체 구축한 이유는 Figma의 협업 기능에서 실시간 데이터가 핵심 기능이며, 이러한 요구사항이 경쟁력으로 이어질 수 있다고 판단했기 때문이다. ## 실용적인 결론 실시간 UI를 구축할 때 클라이언트별 수동 이벤트와 전역 상태 갱신에 의존하면 데이터 규모와 기능 복잡도가 커질수록 일관성 문제가 발생하기 쉽다. 기존 Postgres를 유지해야 하고 대규모 구독이 필요하다면, GraphQL 기반 선언적 쿼리와 데이터베이스 변경 스트림을 결합하는 방식이 폴링이나 수동 이벤트보다 확장성과 유지보수성 측면에서 유리하다.

원문 읽기(새 탭에서 열림)

real-time-dataReactPostgreSQLTypeScript+4