netflix·2026년 6월 19일·4분 읽기큐레이션 요약

개인화된 알림 시스템을 위한 빠른 사고와 느린 사고

Netflix의 개인화 알림 시스템은 장기적인 메시징 전략을 세우는 느린 정책(Slow Policy)과, 실제 발송 시점에 최적의 콘텐츠를 선택하는 빠른 정책(Fast Policy)으로 분리된다. 느린 정책은 회원별 주간 채널 빈도와 발송 페이싱을 결정하고, 빠른 정책은 해당 범위 안에서 즉각적인 관련성과 참여 가능성이 가장 높은 메시지를 선택한다. 이를 통해 단기 참여율뿐 아니라 알림 피로도와 채널 구독 해지 위험까지 함께 관리한다. ## 기존 단일 정책 방식의 한계 - 기존 시스템은 단일 알림이 단기간에 유발하는 인과적 효과를 예측해 발송 여부를 결정했다. - 즉시 시청, 클릭, 앱 방문 같은 단기 지표 최적화에는 효과적이지만, 다음과 같은 장기 영향을 반영하기 어려웠다. - 반복 발송으로 인한 알림 피로도 증가 - 몇 주에 걸쳐 나타나는 참여도 하락 - 이메일·푸시 수신 거부 가능성 증가 - 지속적인 콘텐츠 시청 습관과 회원 만족도 변화 - 발송 여부와 콘텐츠 순위를 하나의 판단으로 처리했기 때문에, 회원별 주간 발송 빈도는 명시적인 정책이 아니라 일별 의사결정의 부산물이었다. - 전체 발송량은 모델 점수 임계값으로 조절했지만, 임계값을 바꾸면 발송 빈도뿐 아니라 선택되는 메시지의 품질과 분포도 함께 변했다. - 결과적으로 회원마다 다른 참여 패턴에 맞춰 발송 빈도와 콘텐츠 선택을 독립적으로 개인화하기 어려웠다. ## 느린 정책과 빠른 정책의 계층 구조 - **느린 정책(Slow Policy)** - 주간 등 일정한 긴 시간 범위에서 회원별 메시지 계획을 수립한다. - 채널별 목표 빈도와 시간에 따른 발송 페이싱을 결정한다. - 장기 참여 패턴과 회원의 메시지 반응을 바탕으로 전략적 결정을 내린다. - **빠른 정책(Fast Policy)** - 실제 발송 기회가 발생할 때마다 작동한다. - 느린 정책이 정한 빈도와 페이싱 범위 안에서 가장 관련성 높은 메시지를 선택한다. - 특정 시점의 콘텐츠 적합성과 단기 참여 가능성을 최적화한다. - 푸시와 이메일 빈도를 독립적으로 조합한 이산적 행동 공간을 사용하며, 약 100개 수준의 채널별 페이싱 조합을 표현할 수 있다. ## 장기 효용 함수와 메시지 비용 느린 정책은 회원별 효용 함수를 최대화하는 행동을 선택한다. > U(member, action) = Σ wₖ · Rewardₖ(member, action) − Cost(action) - **긍정적 신호** - 회원이 알림을 통해 콘텐츠나 기능의 가치를 발견할 가능성 - 알림 이후의 시청, 클릭, 플랫폼 참여 가능성 - **부정적 신호** - 메시지 피로도 증가 가능성 - 특정 채널의 수신 거부 또는 이탈 가능성 - 부정적 피드백은 실제 데이터에서 매우 희소하기 때문에, 이를 모델링하는 것만으로는 충분하지 않다. - 부정적 비용이 거의 없다고 예측되면 모델이 “가능한 한 많이 발송”하는 정책으로 치우칠 수 있다. - 이를 방지하기 위해 모든 발송에 공통으로 적용되는 **보편적 메시지 비용(universal message cost)** 을 추가한다. - 이 비용은 보상 함수를 오목하고 안정적으로 만들어 과도한 발송 정책을 억제한다. - 비용의 크기는 온라인 실험과 오프라인 평가 지표를 함께 사용해 경험적으로 조정한다. ## 빈도와 시간 배분을 분리한 페이싱 - 느린 정책은 평균 발송 빈도뿐 아니라 일주일 동안 메시지를 어떻게 분산할지도 결정할 수 있다. - 가장 단순한 방식은 균등 무작위 페이싱이다. - 목표 빈도를 발송 기회별 확률로 변환한다. - 각 기회마다 확률에 따라 발송 여부를 무작위로 결정한다. - 개별 발송 시점은 달라질 수 있지만 장기적으로는 목표 발송률을 유지한다. - 향후에는 다음과 같은 비균등 페이싱도 적용할 수 있다. - 요일별 발송 패턴 - 회원의 최근 활동 여부에 따른 발송 - 콘텐츠 출시 시점에 맞춘 집중 발송 - 특정 이벤트나 캠페인에 맞춘 일시적 발송 증가 ## 두 정책 간의 비동기 통신 - 느린 정책과 빠른 정책은 저지연 feature store를 통해 연결된다. - **Planner** - 회원별 최적 페이싱 계획을 계산한다. - 계산된 전략적 의도를 feature store에 저장한다. - **Executor** - 매일 알림 발송 기회가 생기면 저장된 계획을 feature로 읽는다. - 해당 계획을 제약 조건으로 사용해 실제 발송 여부와 메시지를 결정한다. - 이 구조에서는 장기 계획 계산과 실시간 메시지 선택을 비동기적으로 분리할 수 있어, 각 정책이 서로 다른 시간 규모의 문제에 집중할 수 있다. ## 실용적인 결론 개인화 알림 시스템에서는 “무엇을 보낼 것인가”와 “얼마나 자주 보낼 것인가”를 하나의 모델에 맡기기보다 분리하는 것이 효과적이다. 장기 효용과 메시지 피로도를 반영하는 계획 계층을 먼저 만들고, 실시간 선택 계층이 그 계획 안에서 콘텐츠를 고르게 하면 단기 성과와 장기적인 회원 경험을 함께 최적화할 수 있다.

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

feature-storereinforcement-learningpersonalizationnotification-systems+3

netflix·2026년 5월 4일·4분 읽기큐레이션 요약

넷플릭스에서 머신러닝의 민주화: 모델 수명 주기 그래프 구축

Netflix는 ML 자산이 개인화, 스튜디오, 결제, 광고 등 여러 영역으로 확장되면서 모델과 데이터가 각기 다른 시스템에 고립되는 문제를 겪었다. 이를 해결하기 위해 다양한 ML 메타데이터를 통합하는 Metadata Service(MDS)와 Model Lifecycle Graph를 구축했다. MDS는 모델·피처·파이프라인·실험·데이터셋 등의 관계를 연결해 자산의 발견, 계보 추적, 영향 분석, 재사용을 가능하게 하는 기반이다. ## ML 생태계의 확장과 사일로 문제 - Netflix의 ML 활용 영역은 개인화 중심에서 다음과 같이 확대됐다. - 콘텐츠 추천과 사용자 참여 최적화 - 스튜디오의 제작 전후 작업 - 사기 탐지, 결제 라우팅, 정기 결제 최적화 - 광고 타기팅과 실시간 의사결정 - 각 도메인은 서로 다른 기술 스택, 비즈니스 지표, 조직 구조를 사용한다. - 그 결과 모델이 블랙박스처럼 고립되고, 다른 팀이 기존 모델과 데이터를 발견하거나 재사용하기 어려워졌다. - 예를 들어 스튜디오에서 만든 콘텐츠 임베딩은 장면 전환과 콘텐츠 구조를 분석하지만, 광고의 문맥 매칭이나 개인화 추천에도 활용될 수 있다. - 그러나 모델 레지스트리, 파이프라인 오케스트레이터, 실험 플랫폼이 분리되어 있어 다음 질문에 답하기 어렵다. - 어떤 피처와 데이터 소스가 존재하는가? - 특정 모델은 어떤 파이프라인과 데이터로 생성되는가? - 해당 모델을 사용하는 A/B 테스트는 무엇인가? - 피처를 변경하면 어떤 모델이 영향을 받는가? - 각 자산의 담당자는 누구인가? ## 통합 UI보다 어려운 메타데이터 연결 - 문제의 본질은 화면을 하나로 합치는 것이 아니라, ML 라이프사이클의 서로 다른 구성 요소를 연결하는 것이다. - Netflix에는 다음과 같은 시스템이 각각 메타데이터를 생성한다. - 파이프라인 오케스트레이션: 실행 정보, 단계 의존성, 데이터 변환 - 모델 레지스트리: 모델 버전, 아티팩트, 오래된 모델 여부, 배포 이력 - 실험 플랫폼: A/B 테스트와 설정 - 피처 스토어: 피처 정의와 사용처 - AI Dataset 플랫폼: 데이터셋 생성, 관리, 검색, 로딩 - Identity 플랫폼: 사용자, 팀, 조직 정보 - 시스템마다 데이터 형식, 식별자, 개념 모델이 다르기 때문에 이질적인 메타데이터를 하나의 엔터티 모델로 변환하고 관계 그래프로 만드는 작업이 핵심 기술 과제가 됐다. ## Metadata Service와 Model Lifecycle Graph - MDS는 Netflix 전반의 ML 관련 엔터티를 색인하고 서로 연결하는 서비스다. - 모델, 피처, 파이프라인, 실험, 데이터셋 등의 메타데이터를 실시간으로 수집한다. - 다음과 같은 교차 도메인 질의를 지원하는 것을 목표로 한다. - 특정 모델을 실행 중인 실험은 무엇인가? - 특정 피처를 공유하는 모델은 무엇인가? - 모델에 사용된 데이터와 생성 파이프라인은 무엇인가? - MDS의 역할은 다음과 같다. - 여러 시스템에서 이벤트 수집 - 메타데이터에 조직·소유자 등 추가 맥락 결합 - ML 자산 간 관계 추론 및 구체화 - 연결된 그래프 형태로 탐색 가능하게 제공 - 궁극적인 목표는 모든 ML 자산을 팀과 도메인에 관계없이 발견하고, 이해하고, 재사용할 수 있도록 만드는 것이다. ## URI 기반 핵심 추상화 MDS는 시스템 간 일관된 연결을 위해 AI Platform URI를 사용한다. - **Component** - 고유한 URI로 주소 지정할 수 있는 모든 객체다. - 형식은 다음과 같다. ```text aip://<componentType>/<platformId>/<resourceId> ``` - 예: ```text aip://model/registry/ranking-v5 aip://user/identity/alice aip://pipeline/orchestrator/weekly-training ``` - **Entity** - 이름, 설명, 생성일, 소유자 등 추가 속성을 가진 ML 생태계의 구성 요소다. - 모델, 피처, 파이프라인 등이 이에 해당한다. - **Entity Type** - 동일한 데이터 구조와 속성·관계 제약을 공유하는 엔터티 집합이다. - **Domain** - 관련 엔터티 타입을 묶고 해당 ML 자산 범주의 추상 인터페이스를 정의한다. - 예를 들어 Models 도메인은 Model과 Model Instance를, Pipelines 도메인은 Schedule·Request·Execution을 정의한다. - **Provider** - 도메인을 실제로 구현하는 특정 소스 시스템이다. - 하나의 도메인에 여러 Provider를 연결할 수 있어, 모델 레지스트리가 교체되더라도 도메인 인터페이스를 변경하지 않고 확장할 수 있다. - URI는 서비스 간 ML 자산 참조를 단일 문자열로 통일하고, MDS가 이를 풍부한 메타데이터와 연결된 관계로 해석할 수 있게 한다. ## 이벤트에서 엔터티와 그래프로 - MDS는 Kafka와 AWS SNS/SQS를 통해 소스 시스템의 이벤트를 실시간으로 수집한다. - 소스 시스템은 식별자와 이벤트 유형 중심의 얇은 이벤트를 발행한다. - 예시는 다음과 같다. ```json { "event_type": "model_instance_created", "instance_id": "ranking-model-v5-20XX0101" } ``` - 생산 시스템은 복잡한 그래프 로직을 알 필요 없이 간단한 이벤트만 발행하고, MDS가 이를 엔터티로 변환하고 다른 시스템의 정보와 결합한다. - 이후 모델, 파이프라인, 피처, A/B 테스트 등의 관계를 추론해 질의 가능한 Model Lifecycle Graph로 materialize한다. - 이를 통해 모델 생성 이벤트와 실험 설정을 연결하는 것처럼, 서로 다른 시스템에 존재하는 관계도 하나의 그래프에서 탐색할 수 있다. MDS와 Model Lifecycle Graph는 단순한 모델 카탈로그가 아니라, ML 자산의 생성부터 배포·실험·재사용까지를 연결하는 메타데이터 인프라다. 여러 팀이 공통 URI와 엔터티 모델을 사용하도록 만들면 모델의 검색성, 의존성 파악, 변경 영향 분석, 조직 간 재사용이 크게 향상된다.

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

feature-store머신러닝Apache Kafkagraph-database+3

pinterest·2026년 2월 27일원문

격차 해소: Pinterest L1 (새 탭에서 열림)

Pinterest는 L1 전환(CVR) 모델의 오프라인 평가 지표가 대폭 개선되었음에도 불구하고, 실제 온라인 A/B 테스트에서는 CPA 성과가 정체되거나 악화되는 ‘온라인-오프라인(O/O) 불일치’ 현상을 겪었습니다. 심층적인 진단 결과, 이 문제의 핵심은 학습 시 사용된 고차원 피처들이 실시간 서빙 시스템의 임베딩 생성 과정에서 누락되거나 쿼리-핀 타워 간의 모델 버전이 어긋난 데 있었습니다. 이를 해결하기 위해 L1/L2 시스템 간 피처 온보딩을 자동화하고 정합성을 맞춤으로써 오프라인의 모델 개선을 실제 비즈니스 지표의 승리로 연결할 수 있었습니다. ### 오프라인 지표와 온라인 성과의 괴리 * **지표 상의 모순:** 새로운 L1 CVR 모델은 오프라인 평가에서 기존 모델 대비 LogMAE를 20~45% 감소시켰으며, 모든 pCVR 버킷에서 우수한 보정(Calibration) 성능을 보였습니다. * **온라인 실험 결과:** 하지만 실제 운영 환경(Budget-Split 실험)에서는 주요 oCPM 세그먼트의 CPA가 오히려 나빠지거나 중립적인 결과를 보였고, 오프라인 예측과는 다른 트래픽 믹스 변화가 관찰되었습니다. * **가설 수립:** 문제 해결을 위해 '모델 및 평가(데이터 오류)', '서빙 및 피처(시스템 정합성)', '퍼널 및 유틸리티(설계 미스)'의 세 가지 계층으로 가설을 나누어 분석을 시작했습니다. ### 원인 분석에서 제외된 요인들 * **오프라인 평가 오류:** 다양한 로그 소스(경매 낙찰 건, 전체 요청 건 등)를 재검증하고 아웃라이어를 제거한 후에도 오프라인 성능 우위는 견고하게 유지되었으므로 평가 방식 자체의 문제는 아니었습니다. * **노출 편향(Exposure Bias):** 실험군 트래픽 비중을 20%에서 70%까지 높였음에도 온라인 보정 문제가 지속되는 것을 확인하여, 대조군 모델의 지배력으로 인한 편향 문제도 주된 원인이 아님을 밝혀냈습니다. * **서빙 지연 및 타임아웃:** 처리 시간(p50/p90/p99) 및 성공률을 비교한 결과 실험군과 대조군 사이에 유의미한 차이가 없어 시스템 성능 이슈도 배제되었습니다. ### 피처 수준의 온라인-오프라인 불일치 * **누락된 피처 파이프라인:** L1 단계는 지연 시간 단축을 위해 별도의 ANN(근사 최근접 이웃) 인덱스를 사용하는데, 학습 로그에는 존재하던 고영향력 피처들이 정작 온라인 임베딩 생성기에는 온보딩되지 않은 상태였습니다. * **구체적 사례:** 타겟팅 사양(관심사, 검색어 모드), 외부 사이트 전환 방문 횟수(1/7/30/90일), MediaSage 이미지 임베딩 등이 온라인 서빙 시 누락되어 모델이 빈약한 정보만으로 예측을 수행하고 있었습니다. * **해결 방안:** UFR(Unified Feature Representation) 구성을 업데이트하여 누락된 피처를 L1 임베딩 경로에 추가했으며, 향후 L2용으로 온보딩된 피처가 L1 임베딩에도 자동 적용되도록 도구의 기본 동작을 수정했습니다. ### 임베딩 버전 및 아키텍처 불일치 * **Two-tower 버전 스큐:** 오프라인에서는 단일 체크포인트로 평가하지만, 온라인 시스템에서는 쿼리 타워(User)와 핀 타워(Ad)가 사용하는 모델 버전이 일시적으로 일치하지 않는 현상이 발생할 수 있음을 확인했습니다. * **모델 정합성:** 두 타워가 서로 다른 시점의 모델 가중치를 사용할 경우 생성된 임베딩 벡터 간의 거리 계산이 무의미해지며, 이는 곧 L1 단계의 회수(Recall) 성능 저하로 이어집니다. * **시스템적 교훈:** 단순한 모델 알고리즘의 개선보다 학습 환경과 서빙 아키텍처 간의 '기술적 정합성'을 유지하는 파이프라인 관리가 실제 성능에 더 결정적인 영향을 미친다는 것을 입증했습니다. L1 랭킹 모델의 성능 향상이 온라인 지표 개선으로 이어지지 않는다면, 모델 자체의 로직보다는 학습 데이터 피처가 실시간 서빙 아키텍처(ANN, 임베딩 빌더 등)까지 온전히 전달되고 있는지 파이프라인의 종단간 정합성을 가장 먼저 점검해야 합니다.

feature-store머신러닝ranking-modelstwo-tower-architecture+4

pinterest·2026년 1월 28일원문

행동 시퀀스 모델링 (새 탭에서 열림)

핀터레스트는 사용자의 오프사이트(offsite) 행동 이력을 분석하여 미래의 전환 가능성을 예측하는 행동 시퀀스 모델링(Behavioral Sequence Modeling)을 통해 광고 후보군 생성 시스템을 혁신했습니다. 이 시스템은 트랜스포머(Transformer) 기반의 투타워(Two-tower) 구조를 활용해 사용자별로 개인화된 광고주 및 상품을 추천하며, 이를 통해 광고의 관련성을 높이고 광고주 측면에서는 전환 비용(CPA)을 낮추는 성과를 거두었습니다. 결과적으로 수억 개의 상품 카탈로그 속에서 사용자의 진화하는 쇼핑 의도를 실시간으로 포착하여 정교한 광고 서빙이 가능해졌습니다. **광고주 상호작용 예측 모델 (Phase 1)** - 사용자가 과거에 조회, 구매, 장바구니에 담은 상품 시퀀스를 분석하여 다음에 상호작용할 가능성이 높은 광고주를 예측합니다. - 사용자 타워는 양방향 트랜스포머(Bidirectional Transformer)를 사용하여 이벤트 시퀀스를 인코딩하고, 광고주 타워는 MLP 레이어를 통해 광고주를 표현하는 투타워 구조를 채택했습니다. - 학습 시에는 체크아웃, 장바구니 담기, 가입 등을 양성(Positive) 샘플로 정의하고, 샘플링된 소프트맥스 손실(Sampled Softmax Loss)과 인기 항목에 대한 과도한 페널티를 방지하기 위한 Log-Q 편향 수정을 적용했습니다. - 오프라인 평가에서 200만 개의 광고주 임베딩을 대상으로 Recall@K를 측정하여 성능을 검증했으며, 온라인 실험 결과 전환수 증가와 CPA 감소라는 유의미한 비즈니스 지표 개선을 확인했습니다. **상품 단위(Item-level) 예측으로의 확장 (Phase 2)** - 광고주 단위를 넘어 특정 상품(Pin)을 직접 예측함으로써 더욱 깊이 있는 개인화와 효율적인 광고 전달 시스템을 구축했습니다. - 10억 개 이상의 방대한 상품 데이터를 처리하기 위해 핀터레스트 내부의 핀(Pin) 임베딩과 카탈로그 메타데이터를 통합하여 더욱 풍부한 상품 표현력을 확보했습니다. - 대규모 아이템 코퍼스를 다루기 위해 인배치 부정 샘플(In-batch negatives)과 2,000만 개의 무작위 샘플링된 핀을 혼합하여 대조 학습(Contrastive Learning)의 효과를 극대화했습니다. - 일 단위 추론 작업을 통해 최근 활동이 있는 사용자의 임베딩을 업데이트하고, 이를 온라인 피처 스토어에 게시하여 실시간 서빙 시스템에서 활용합니다. **서빙 플로우 및 성능 평가** - 오프라인 배치 워크플로우에서 예측된 상위 100개의 광고주/상품 리스트를 온라인 피처 스토어에 저장하고, 광고 요청 시 L1 랭커와 L2 랭커로 전달하여 최종 광고를 선정합니다. - 모델 성능은 단순 MLP 기반의 풀링(Max/Mean Pooling) 모델을 베이스라인으로 설정하고, 이보다 우수한 Recall@K 성능을 보이는 트랜스포머 모델을 최종 선택했습니다. - 아이템 단위 예측은 하위 단계의 랭킹 모델이 처리해야 할 후보군 수를 최적화함으로써 시스템의 확장성을 높이고 사용자 만족도를 증진시키는 역할을 합니다. 단순한 인구통계학적 타겟팅에서 벗어나 사용자의 실시간 행동 시퀀스를 반영하는 임베딩 기반 검색(Embedding-based Retrieval) 시스템을 구축하는 것이 대규모 커머스 플랫폼에서 광고 효율을 극대화하는 핵심 전략임을 보여줍니다. 특히 아이템 수가 기하급수적으로 늘어날수록 광고주 단위가 아닌 개별 상품 단위의 시퀀스 모델링이 필수적입니다.

feature-storetransformerembeddingscontrastive-learning+4

dropbox·2025년 12월 18일원문

Dropbox Dash의 실시간 (새 탭에서 열림)

Dropbox Dash는 흩어져 있는 업무 데이터를 통합하여 실시간으로 답변과 검색 결과를 제공하는 AI 도구이며, 이 시스템의 핵심은 머신러닝 모델에 필요한 데이터 신호인 '피처(Feature)'를 관리하고 전달하는 피처 스토어입니다. 수만 개의 문서 중 가장 관련성 높은 정보를 순위화하기 위해 드롭박스는 온프레미스와 클라우드가 결합된 하이브리드 인프라 위에서 초저지연 읽기와 실시간 데이터 업데이트가 가능한 독자적인 피처 스토어를 구축했습니다. 결과적으로 이 시스템은 수천 개의 피처를 병렬로 조회하면서도 100ms 미만의 응답 속도를 유지하여 사용자에게 최적화된 검색 경험을 제공합니다. ### 하이브리드 인프라를 위한 설계 목표와 요구사항 * **복합적인 인프라 환경 대응:** 저지연 통신을 위한 온프레미스 에코시스템과 대규모 데이터 처리를 위한 Spark 기반 클라우드 환경을 동시에 지원해야 했습니다. * **대규모 병렬 조회 처리:** 사용자 쿼리 하나당 수천 건의 피처 룩업(Lookup)이 발생하므로, 엄격한 지연 시간 예산 내에서 막대한 병렬 읽기를 처리할 수 있는 구조가 필요했습니다. * **실시간성 확보:** 사용자의 최근 행동(문서 열람, 채널 참여 등)이 몇 초 내에 다음 검색 결과에 반영될 수 있도록 빠른 데이터 수집 파이프라인이 요구되었습니다. * **통합 프레임워크 구축:** 실시간 스트리밍과 배치 처리를 통합하여 엔지니어가 아이디어 단계부터 실제 배포까지 빠르게 진행할 수 있는 환경을 목표로 했습니다. ### Feast와 Dynovault를 활용한 아키텍처 설계 * **Feast 프레임워크 채택:** 피처 정의와 인프라 구현을 분리하고 모듈화된 어댑터 생태계를 가진 Feast를 선택하여 인프라 복잡성을 추상화했습니다. * **Dynovault 활용:** 드롭박스 자체 개발 DynamoDB 호환 스토리지인 Dynovault를 온라인 저장소로 사용하여 공용 인터넷 호출 없이 약 20ms의 클라이언트 지연 시간을 달성했습니다. * **관측 가능성 강화:** 작업 실패 모니터링, 데이터 신선도 추적, 데이터 계보(Lineage) 가시성 등을 추가하여 안정적인 운영 기반을 마련했습니다. ### Go 언어 재작성을 통한 성능 최적화 * **Python SDK의 한계 극복:** 초기 Python 기반 구현에서는 JSON 파싱 속도와 GIL(Global Interpreter Lock)로 인해 동시성 처리에 병목이 발생했습니다. * **고성능 서빙 레이어 구축:** 서빙 레이어를 Go 언어로 재작성하고 가벼운 고루틴(Goroutine)과 공유 메모리를 활용하여 동시성 성능을 극대화했습니다. * **지연 시간 단축:** 최적화 결과 p95 기준 지연 시간을 25~35ms 수준으로 유지하며, 초당 수천 개의 요청을 처리할 수 있는 확장성을 확보했습니다. ### 효율적인 데이터 신선도 유지 전략 * **계층화된 수집 방식:** 복잡한 연산이 필요한 데이터는 메달리온 아키텍처(Medallion architecture) 기반의 배치 수집을, 실시간 신호는 스트리밍 방식을 병행합니다. * **지능형 변경 감지:** 모든 데이터를 매번 다시 쓰는 대신 변경된 레코드만 온라인 스토어에 기록하는 방식을 도입했습니다. * **비용 및 성능 최적화:** 변경 감지 기술을 통해 쓰기 작업량을 수억 건에서 백만 건 미만으로 줄여 업데이트 시간을 단축하고 인프라 부하를 최소화했습니다. 이러한 드롭박스의 접근 방식은 기성 제품을 그대로 사용하기보다 오픈소스를 활용해 내부 인프라에 최적화된 형태로 커스터마이징하는 것이 대규모 AI 서비스 운영에 얼마나 중요한지를 잘 보여줍니다. 특히 성능 병목 지점을 정확히 파악하여 서빙 레이어를 Go로 전환한 결정은 지연 시간에 민감한 실시간 랭킹 시스템 구축 시 고려해 볼 만한 전략입니다.

feature-store머신러닝Godynamodb+4

coupang·2024년 11월 14일원문

쿠팡의 머신러 (새 탭에서 열림)

쿠팡의 머신러닝 플랫폼은 데이터 탐색부터 모델 배포에 이르는 전체 ML 생애주기를 가속화하여 개발 생산성을 혁신적으로 높이는 것을 목표로 합니다. 이를 통해 검색, 가격 책정, 물류 최적화 등 쿠팡의 다양한 서비스에 머신러닝을 효율적으로 적용하고 있으며, 인프라 관리 부담을 줄여 엔지니어들이 모델 고도화에만 집중할 수 있는 환경을 제공합니다. 결과적으로 이 플랫폼은 복잡한 비즈니스 문제를 해결하는 핵심 기술 기반으로서 쿠팡의 비즈니스 성장을 견인하고 있습니다. **플랫폼 구축의 동기와 목표** * **생산 모드 전환 시간 단축**: 실험 단계의 모델을 실제 서비스 환경에 배포하기까지 걸리는 시간을 줄여 비즈니스 요구사항에 빠르게 대응합니다. * **ML 개발의 CI/CD 도입**: 소프트웨어 공학의 지속적 통합 및 배포(CI/CD) 개념을 ML에 접목하여, 모델 학습과 배포 과정을 자동화하고 일관된 품질을 유지합니다. * **컴퓨팅 자원의 효율적 확장**: 하부 인프라에 대한 개입 없이도 대규모 학습 및 추론을 수행할 수 있도록 유연한 확장성을 제공하여 비용과 성능을 최적화합니다. **플랫폼의 핵심 기능 및 구성 요소** * **관리형 노트북 및 파이프라인 SDK**: 데이터 과학자들이 익숙한 Jupyter 기반 환경에서 작업할 수 있도록 지원하며, 전용 SDK를 통해 복잡한 ML 파이프라인을 손쉽게 정의하고 실행할 수 있습니다. * **피처 스토어(Feature Store)**: 학습과 추론 단계에서 동일한 피처 데이터를 재사용하고 공유할 수 있는 중앙 저장소를 제공하여, 데이터 정합성 문제를 해결하고 개발 효율을 높입니다. * **모델 학습 및 추론 서비스**: 다양한 ML 프레임워크를 지원하는 매니지드 학습 환경과, 대규모 트래픽을 처리할 수 있는 실시간 및 배치 추론 인프라를 운영합니다. * **모니터링 및 관측 가능성**: 배포된 모델의 성능 저하(Drift)나 이상 징후를 실시간으로 추적하여 모델의 신뢰성을 보장하고 신속한 재학습 여부를 결정합니다. **주요 성공 사례** * **Ko-BERT를 통한 검색 고도화**: 한국어 특화 언어 모델인 Ko-BERT를 학습시켜 고객의 검색 쿼리 의도를 더 정확하게 파악하고 상품 검색의 질을 향상시켰습니다. * **실시간 가격 예측**: 수백만 개의 상품에 대해 시장 변화를 즉각적으로 반영하는 실시간 가격 예측 모델을 성공적으로 배포하여 비즈니스 의사결정을 지원하고 있습니다. 쿠팡 ML 플랫폼은 단순히 도구의 집합을 넘어, 데이터 과학자가 비즈니스 가치 창출에만 전념할 수 있도록 돕는 강력한 엔지니어링 생태계입니다. 대규모 데이터와 복잡한 모델을 다루는 조직이라면 쿠팡의 사례처럼 파이프라인 자동화와 피처 정합성을 보장하는 통합 플랫폼 구축을 통해 개발 사이클을 획기적으로 단축할 수 있습니다.

feature-storeAI머신러닝CI/CD+5