Pinterest Engineering

Pinterest는 월 6억 명 이상의 사용자를 서비스하는 추천 시스템 파운데이션 모델의 분산 훈련 스케일링 문제를 다룬다. 초기 멀티 노드 확장 시 2노드에서 성능이 0.2x로 역행했고, AWS EFA 도입 후에도 4노드 기준 1.21x에 그쳤다. 5단계 최적화를 통해 4노드 3.9x, 8노드 7.5x의 거의 선형에 가까운 스케일링을 달성했다.

Pinterest의 CDC 기반 DB 수집 파이프라인은 MySQL에서 Kafka, Flink, Spark, Iceberg를 거치는 다층 구조다. 스키마 변경이 생기면 모든 계층을 동시에 업데이트해야 해 드리프트, 배포 실패, 데이터 불일치가 반복됐다. Pinterest 엔지니어링 팀은 이를 해결하기 위해 가산적 변경만 자동화하는 스키마 진화 프레임워크를 구축하고, PR 기반 롤아웃과 SLA 기반 일관성 모델을 도입했다.

Pinterest 가 ML 모델 학습·서빙에 쓰는 사용자 시퀀스 데이터(최근 N개 행동) 플랫폼을 비용·속도·사용성 면에서 다시 설계한 사례를 다룬다. 학습·분석·온라인 추론 세 곳에서 쓰이며 ML 데이터 스택에서 가장 비싸고 깨지기 쉬운 부분이던 것을, 설정-코드·공유 엔진·Lambda 아키텍처·칼럼형 저장으로 풀었다.

에이전트가 저장소별 커스텀 skill을 항상 로드한다고 가정하면 iOS 아키텍처 같은 도메인 지식 적용이 불안정해진다.

기존 광고 후보 생성 모델은 오프사이트 행동 기반 임베딩만 써서 Related Pins나 Search의 실시간 맥락을 반영하지 못했다.

Pinterest의 root-leaf ML 서빙 구조에서 모델 추론보다 root-leaf 네트워크 대역폭이 먼저 병목이 됐다.

Pinterest 쇼핑 광고는 offsite conversion 신호가 희소하고 지연돼 engagement 중심 retrieval만으로 구매 의도를 최적화하기 어려웠다.

대규모 URL에서 추적용 query parameter와 콘텐츠를 바꾸는 parameter를 구분하지 못해 중복 제거 품질이 흔들렸다.

Pinterest의 분산 ML job이 간헐적 네트워크 timeout으로 실패해 GPU 자원을 낭비했다.

추천 모델을 100배 키우면 user sequence가 후보 item마다 중복 처리되어 storage, training, serving 비용이 급증했다.

Android 화면마다 체감 완료 시점을 따로 측정하면 성능 개선 범위가 제한되고 일관된 latency 지표를 얻기 어려웠다.

Home Feed 추천은 즉시 save 같은 단일 목표만 최적화하면 다양성이 줄고 장기 만족도와 session time이 악화됐다.

Pinterest는 AI 에이전트가 내부 데이터와 도구를 안전하게 호출할 공통 프로토콜과 거버넌스가 필요했다.