Dropbox Dash에서 실시간 AI를 구동하는 feature store 내부

발행: (2025년 12월 19일 오전 03:00 GMT+9)
10 min read

Source: Dropbox Tech Blog

Dropbox Dash는 AI를 사용해 파일, 업무 채팅, 그리고 회사 콘텐츠에 대한 질문을 이해하고, 모든 것을 한 곳에 모아 더 깊고 집중된 작업을 가능하게 합니다. 수만 개에 달하는 잠재적인 업무 문서를 고려해야 하므로, 검색과 에이전트 모두 실시간 머신러닝으로 구동되는 랭킹 시스템에 의존해 올바른 파일을 빠르게 찾습니다. 그 랭킹의 핵심은 피처 스토어이며, 이는 모델이 관련성을 예측하는 데 사용하는 데이터 신호(“피처”)를 관리하고 제공하는 시스템입니다.

Dropbox Dash: 작업을 이해하는 AI 동료

왜 맞춤형 피처 스토어가 필요할까요?

사용자가 정확히 원하는 것을 찾을 수 있도록, Dash는 파일 유형, 회사 콘텐츠, 그리고 협업의 복잡하고 파편화된 현실 속에서 사용자 행동의 의미를 파악합니다. 그런 다음 필요할 때, 그리고 필요한 방식으로 가장 관련성 높은 문서, 이미지, 대화를 제공하죠.

피처 스토어는 작업 전반에 걸쳐 올바른 컨텍스트를 순위 매기고 검색하는 데 핵심적인 역할을 합니다. 피처 스토어는 다음을 목표로 구축되었습니다:

  • 피처를 빠르게 제공
  • 사용자 행동 변화에 발맞춰 지속적으로 업데이트
  • 엔지니어가 아이디어에서 프로덕션까지 신속하게 이동할 수 있도록 지원

(피처 스토어가 Dash의 컨텍스트 엔지니어링과 어떻게 연결되는지 더 알고 싶다면, **컨텍스트 엔지니어링에 대한 심층 분석**을 확인하세요.)

이 게시물에 포함된 내용

우리는 다음을 살펴볼 것입니다:

  1. Dash의 랭킹 시스템 뒤에 있는 피처 스토어를 어떻게 구축했는지
  2. 기존 솔루션이 왜 맞지 않았는지
  3. 속도와 확장성을 위해 어떻게 설계했는지
  4. 사용자 행동이 변함에 따라 피처를 최신 상태로 유지하기 위해 필요한 것

그 과정에서 우리가 만든 트레이드오프와 접근 방식을 형성한 교훈을 공유합니다.

Our Goals and Requirements

Building a feature store for Dash required a custom solution rather than an off‑the‑shelf product. The main constraints were:

AreaChallengeWhy It Matters
Hybrid InfrastructureOn‑premises low‑latency service mesh Spark‑native cloud environmentStandard cloud‑native stores couldn’t span both worlds, so we needed a bridge that kept development velocity high.
Search Ranking ScaleOne query → thousands of feature lookups (behavioral, contextual, real‑time signals)The store must sustain massive parallel reads while staying under sub‑100 ms latency budgets.
Real‑Time RelevanceSignals (e.g., document open, Slack join) must be reflected in the next search within secondsRequires an ingestion pipeline that can keep up with user‑behavior velocity at scale.
Mixed Computation PatternsSome features are streaming‑first; others need batch processing of historic dataA unified framework is needed to support both efficiently, reducing cognitive load for engineers and shortening the path from idea to production.

Summary

  • Bridge on‑prem & cloud without sacrificing speed.
  • Support massive parallel reads while guaranteeing low latency.
MetricPython (original)Go (new)
Latency≤ 100 ms25–35 ms
ThroughputThousands of req/s with high CPUThousands of req/s with lower CPU
ScalabilityLimited by GIL & process coordinationLinear scaling with goroutine count

The Go service now handles thousands of requests per second, adding only ~5–10 ms of processing overhead on top of Dynovault’s client latency and consistently achieving p95 latencies of ~25–35 ms.

Impact

  • Met Dash’s latency targets reliably.
  • Prevented feature serving from becoming a bottleneck as search traffic and feature complexity grew.

Read more about Go at the official site.

기능을 최신 상태로 유지하기

속도는 데이터 자체가 최신일 때만 의미가 있습니다. 오래된 기능은 순위 품질을 낮추고 사용자 경험을 해칠 수 있으므로, 우리 피처 스토어는 가능한 한 빨리 새로운 신호를 반영해야 합니다—보통 사용자 행동 후 몇 분 이내에.

도전 과제

  • 규모 – Dash의 가장 중요한 기능 중 다수는 대규모 조인, 집계 및 과거 컨텍스트에 의존하므로 완전 실시간 계산이 비현실적입니다.
  • 균형 – 인프라를 과부하시키거나 개발 속도를 늦추지 않으면서 데이터가 신선하고 신뢰할 수 있는 인제스트 전략이 필요했습니다.

우리의 솔루션: 3단계 인제스트 시스템

인제스트 유형처리 내용주요 장점
Batch ingestionmedallion architecture(raw → refined 단계) 기반의 복잡하고 대용량 변환• 지능형 변경 감지 → 수정된 레코드만 기록.
• 쓰기량이 시간당 수억 건에서 < 5 분으로 감소.
Streaming ingestion빠르게 변하는 신호(예: 협업 활동, 콘텐츠 상호작용)• 무한 데이터셋에 대한 거의 실시간 처리.
• 기능이 사용자의 현재 행동과 일치함.
Direct writes경량 또는 사전 계산된 피처(예: LLM 평가 파이프라인의 관련성 점수)• 배치 파이프라인을 완전히 우회.
• 데이터가 온라인 스토어에 초단위로 나타남.

결과

이 세 가지 인제스트 경로를 결합함으로써 Dash는 모든 계산을 단일 파이프라인에 강요하지 않고도 피처 값을 최신 상태로 유지할 수 있습니다. 이는 순위 품질을 유지하면서 실제 사용 규모에 맞게 확장할 수 있게 합니다.

우리가 배운 것

Dropbox 규모에서 피처 스토어를 구축하면서 시스템 설계에 대한 여러 귀중한 교훈을 다시 확인했습니다.

서빙 측면 인사이트

  • Python의 동시성 모델이 고처리량, CPU‑I/O 혼합 워크로드에 제한 요소가 되었습니다.
  • 신중한 병렬 처리에도 불구하고, 전역 인터프리터 락(GIL)이 JSON 파싱과 같은 CPU‑집약 작업의 성능을 제한했습니다.
  • 다중 프로세스로 전환하면서 새로운 조정 병목 현상이 발생했습니다.
  • 서빙 레이어를 Go로 재작성함으로써 이러한 트레이드오프를 없애고 동시성을 예측 가능하게 확장할 수 있었습니다.

데이터 측면 인사이트

  • 인프라 변경도 중요했지만, 접근 패턴을 이해하는 것 역시 동일하게 중요했습니다.
  • 일반적인 15분 창에서 피처 값의 1–5 %만 변경됩니다.
  • 이 사실을 활용해 쓰기량과 수집 시간을 크게 줄여, 시간 단위 배치 사이클을 5분 업데이트로 전환했습니다—시스템 부하를 늘리지 않고 신선도를 향상시켰습니다.

하이브리드 아키텍처

  • Feast – 오케스트레이션 및 일관성
  • Spark – 대규모 연산
  • Dynovault – 저지연 온라인 서빙

단일 벤더 솔루션에 의존하는 대신, 이 접근 방식은 각 레이어를 강점에 맞게 조정하면서 학습과 서빙을 일치시킬 수 있게 합니다.

요약

이 작업은 모든 것을 처음부터 구축하는 것과 기성 시스템을 그대로 도입하는 사이의 중간 경로의 가치를 강조했습니다. 오픈소스 기반을 내부 인프라와 결합하고 실제 제약에 맞게 맞춤화함으로써, 현재 요구를 충족하고 앞으로도 함께 진화할 수 있는 피처 스토어를 구축했습니다.

감사의 글

현재와 과거의 AI/ML PlatformData Platform 팀 구성원 모두의 기여에 특별히 감사드리며, 우리가 구축한 도구로 마법을 구현하는 머신러닝 엔지니어들에게도 감사드립니다.

혁신적인 제품, 경험, 인프라를 구축하는 것이 흥미롭다면, 우리와 함께 미래를 만들어보세요! 우리 채용 공고를 보려면 jobs.dropbox.com 를 방문하세요.

Back to Blog

관련 글

더 보기 »

“함께 구매하면 좋은 상품” 추천 모델 고도화

배달의민족에서는 음식 배달뿐만 아니라 장보기도 당일 배송이 가능하다는 사실, 알고 계셨나요? 배민의 장보기·쇼핑 서비스는 배민B마트를 비롯해 마트, 편의점, 꽃, 전자제품 등 다양한 셀러가 입점해 있어 다양한 물건을 빠르게 받아보실 수 있습니다. 고객이 서비스에 진입한 순간부터 구매를...

우리는 코드처럼 문화도 리팩토링한다

팀 소개 커머스웹프론트개발팀 이하 “커머프팀”은 배달의민족의 모든 커머스 서비스와 플랫폼은 물론, 백오피스부터 뒷단의 물류시스템에 이르기까지 웹 클라이언트 영역을 담당하는 거대한 규모의 팀입니다. 각기 다른 서비스를 담당하던 팀이 모여 하나의 큰 팀을 이루었고, 배달의민족이 꿈꾸는 커머스의 미래를 함께 만들어갑니다.