experimentation

2 개의 포스트

spotify원문

개인화와 실험을 위한 별도의 기술 스택을 사용하는 이유 | Spotify 엔지니어링 (새 탭에서 열림)

스포티파이는 개인화(Personalization)와 실험(Experimentation)을 서로 다른 기술 스택으로 분리하여 운영합니다. 개인화 시스템은 머신러닝(ML) 스택을 통해 구축하고, 이렇게 구축된 시스템의 성과와 가치는 실험 스택인 'Confidence' 플랫폼을 통해 검증하는 구조를 취합니다. 이러한 분리를 통해 스포티파이는 각 인프라의 전문성을 유지하면서도 기술적 부채를 방지하고 대규모 시스템을 효율적으로 확장하고 있습니다. ### 실험에서 개인화로의 진화와 컨텍스트 밴딧 * **A/B 테스트와 멀티 암드 밴딧(MAB):** 일반적인 A/B 테스트는 모든 사용자에게 평균적으로 가장 좋은 버전을 찾습니다. 반면, MAB는 실험 중에 성과가 좋은 그룹에 더 많은 트래픽을 동적으로 할당하여 효율성을 높입니다. * **컨텍스트 밴딧(Contextual Bandits):** 사용자 특성(나이, 위치, 과거 행동 등)에 따라 각기 다른 최적의 '대안(Arm)'을 제공합니다. 이는 더 이상 하나의 최고 버전을 찾는 것이 아니라, 개별 사용자에게 맞춤화된 경험을 제공하는 '개인화' 영역으로 진입함을 의미합니다. * **시스템으로서의 개인화:** 컨텍스트 밴딧이 도입되면 실험의 목적은 특정 버튼의 효과 측정이 아니라, "이 개인화 시스템이 기존 시스템보다 더 큰 가치를 창출하는가?"라는 시스템 평가로 전환됩니다. ### 기술 스택을 분리해야 하는 인프라적 이유 * **성능 및 지연 시간(Latency) 요구사항:** 개인화 모델(NN, LLM, 부스팅 모델 등)은 실시간 데이터 기반의 추론과 극도로 낮은 지연 시간을 요구합니다. 이를 위해 최적화된 ML 스택이 필요하며, 실험 도구가 이러한 성능 요구사항을 모두 수용하려 하면 시스템이 지나치게 비대해집니다. * **기술적 부채 방지:** 실험 스택과 ML 스택의 관심사를 혼합하면 시스템 간 결합도가 높아져 관리하기 어려운 기술적 부채가 발생합니다. 스포티파이는 이를 분리함으로써 각 플랫폼이 고유의 목적에 집중하게 합니다. * **복잡한 모델 지원:** ML 플랫폼은 대규모 피처 세트와 복잡한 알고리즘을 학습하고 서빙하는 데 특화되어 있어, 단순한 실험 도구보다 정교한 개인화 로직 구현에 유리합니다. ### 분리를 통한 평가 체계의 명확성 * **재귀적 평가의 필요성:** 컨텍스트 밴딧이나 추천 알고리즘 자체도 하나의 '기능'입니다. 따라서 새로운 알고리즘 버전이 기존 버전보다 나은지 확인하기 위해서는 별도의 A/B 테스트가 필요합니다. * **관심사 분리(Separation of Concerns):** ML 스택은 "어떻게 개인화할 것인가"를 담당하고, 실험 스택은 "이 개인화가 실제로 효과가 있는가"를 측정합니다. * **병렬 실험 가능:** 실험 플랫폼을 독립적으로 유지함으로써, 수천 개의 다른 실험들과 간섭 없이 개인화 모델의 성능을 동시에 테스트하고 확장할 수 있습니다. 성공적인 개인화 서비스를 구축하려면 개인화 알고리즘(컨텍스트 밴딧 등)을 실험의 도구가 아닌, **검증 대상이 되는 제품의 기능**으로 정의해야 합니다. 저지연 모델 서빙과 복잡한 피처 처리는 전용 ML 스택에 맡기고, 실험 플랫폼은 이를 객관적으로 비교·평가하는 역할에 집중하는 것이 기술적 유연성과 운영 효율성을 동시에 잡는 길입니다.

figma4분 읽기큐레이션 요약

데이터 사이언티스트로서 영향력을

데이터 과학의 영향력은 A/B 테스트나 최적화에만 있지 않으며, 복잡한 시스템을 이해하기 쉽게 만들고 정확성과 운영 안정성을 높이는 데에도 있다. 특히 빌링처럼 여러 시스템과 상태 변화가 얽힌 영역에서는 데이터 과학자가 도메인 지식, 데이터 모델링, 검증 도구, 엔지니어링 협업을 함께 수행해야 한다. 글은 데이터 과학을 ‘풀스택’ 분야로 보고, 과거와 현재의 시스템 동작을 설명하며, 기술적 방향과 품질 기준까지 정의해야 한다고 주장한다. ## 데이터 과학은 풀스택 분야다 - 데이터 과학자의 역할은 팀에 따라 실험 설계, 제품 분석, 데이터 모델링, 계측, 시스템 검증 등 크게 달라진다. - Figma는 한 프로젝트 안에서도 여러 역할을 수행할 수 있는 풀스택 데이터 과학자를 지향한다. - 빌링은 사용자에게 직접 보이는 제품이면서 동시에 복잡한 백엔드 시스템이므로, 단순한 기회 분석이나 실험만으로는 충분하지 않다. - 정확한 청구는 고객 경험과 플랫폼에 대한 신뢰에 직접 영향을 미친다. - 따라서 데이터 과학자는 다음과 같은 업무를 수행한다. - 빌링 도메인과 업무 규칙 이해 - 여러 팀과의 협업 - 시스템 동작을 설명하고 검증하는 도구 개발 - 데이터 품질과 계측 개선 - 정해진 데이터 과학 플레이북을 적용하기보다, 파트너 팀과 함께 실제로 필요한 지원 방식을 정의하는 것이 중요하다. ## 차트와 모델 외에도 시스템을 설명하는 방법이 있다 - 예측이나 추론 모델이 항상 가장 영향력 있는 데이터 과학 작업은 아니다. - 복잡한 시스템에서는 현재 또는 과거의 결과가 왜 발생했는지 설명하는 일이 더 중요할 수 있다. - Figma의 좌석 기반 빌링에서는 다음 요소가 여러 시스템에 걸쳐 상호작용한다. - 좌석 할당 및 제거 - 권한 변경 - 계약 조건 - 업그레이드 경로 - 워크스페이스 상태 - 특정 시점에 발생한 상태 전환 - 인보이스의 단순한 한 줄 청구 항목도 실제로는 여러 제품 이벤트와 빌링 규칙의 결과다. - 이를 해결하기 위해 **Invoice Seat Report**라는 데이터 애플리케이션을 구축했다. - 제품 사용 이벤트, 계약 메타데이터, 빌링 규칙, 과거 상태 전환을 통합한다. - 각 좌석 요금이 왜 발생했는지 평이한 언어로 설명한다. - 고객 지원, 주문 관리, 엔터프라이즈 담당자가 고객에게 청구 내역을 설명할 수 있게 한다. - 엔지니어가 예상치 못한 청구 동작을 디버깅할 때도 활용된다. ## 신뢰할 수 있는 설명에는 데이터 기반이 필요하다 - 보고서를 만드는 일은 단순히 여러 테이블을 조회하는 작업이 아니었다. - 좌석 상태가 시스템마다 어떻게 변화하는지에 대한 공통된 정신 모델을 먼저 만들어야 했다. - 이를 위해 다음 작업이 필요했다. - 엔지니어와 데이터 흐름 및 업무 규칙 검증 - 과거 데이터의 불일치 정리 - 누락된 이벤트에 대한 새로운 계측 요청 - “무슨 일이 일어났는가”뿐 아니라 “왜 일어났는가”를 기록하도록 로그 개선 - 기존 로그는 결과만 남기고 원인을 기록하지 않는 경우가 있어, 미래의 분석 가능성을 높이기 위한 시스템 변경도 함께 진행했다. - 특히 레거시 다년 계약처럼 좌석 이력이 드문 경우나, 초기 업그레이드로 데이터에 공백이 생기는 경우를 별도로 처리해야 했다. - 빌링 규칙을 SQL과 데이터 변환 로직으로 옮길 때는 각 규칙을 추적하고 디버깅할 수 있도록 구현해야 했다. ## 데이터 과학자는 기술적 방향도 정의할 수 있다 - 비즈니스 규칙을 측정 가능한 검증 조건으로 바꾸면 데이터 과학은 제품 분석을 넘어 시스템 품질 관리에 기여할 수 있다. - 이런 검증은 다음 목적에 활용된다. - 무엇이 “정상”인지 정의 - 데이터 및 시스템 동작의 드리프트 감시 - 회귀 버그 조기 탐지 - 미묘한 이상 상태 발견 - 개발 환경과 운영 환경에서 결과 검증 - 빌링처럼 상태가 누적되는 시스템에서는 좌석 할당, 상태 전환, 인보이스 계산이 모두 의도한 규칙과 일치해야 한다. - 작은 계산 오류도 고객의 청구 금액과 서비스 신뢰도에 영향을 줄 수 있다. - Figma가 가격·상품 구성·빌링 로직을 대규모로 재설계했을 때도 데이터 과학은 다음을 검증하는 역할을 맡았다. - 새 로직이 의도대로 작동하는지 - 데이터가 파이프라인을 통해 정확히 흐르는지 - 예상하지 못한 빌링 상태가 발생하지 않는지 - 개발과 운영 환경 모두에서 결과가 일관적인지 복잡하고 중요한 시스템에서 데이터 과학자는 분석 결과를 제공하는 사람을 넘어, 시스템을 설명 가능하게 만들고 정확성을 검증하는 기술 파트너가 되어야 한다. 따라서 실험 중심의 역할에만 한정하지 말고, 도메인 모델링·데이터 품질·계측·자동 검증까지 업무 범위를 확장하는 것이 실용적인 접근이다.

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