X의 피드 랭킹 알고리즘: Grok이 200ms 만에 5억 개의 포스트를 랭킹하는 방법

요약 (TL;DR)

xAI가 X의 '추천(For You)' 피드 뒤에 숨겨진 전체 프로덕션 코드를 GitHub에 오픈 소스로 공개했습니다 — 별(star) 22.5k 개, Apache 2.0 라이선스, 상업적 이용 가능

이 시스템은 매일 5억 개의 포스트를 가져와 후보군을 좁히고, Grok 기반의 트랜스포머(Transformer)를 사용하여 200밀리초(ms) 이내에 랭킹을 매깁니다.

수동으로 설계된 피처(Hand-engineered features)가 전혀 없습니다 — Grok 트랜스포머는 14가지 참여 유형(좋아요, 답글, 리포스트, 클릭, 체류 시간, 차단, 신고 등)을 예측하고 이를 가중치 점수로 결합합니다.

네 가지 구성 요소: Home Mixer (오케스트레이션), Thunder (네트워크 내부, sub-ms 조회), Phoenix (Grok 트랜스포머 검색 + 랭킹), Candidate Pipeline (재사용 가능한 프레임워크)

사전 학습된 미니 Phoenix 모델이 저장소와 함께 제공됩니다 — 별도의 학습 없이도 추론(Inference)을 실행할 수 있습니다.

직접적인 답변 블록

X의 '추천(For You)' 피드 알고리즘은 네 가지 구성 요소로 이루어진 추천 시스템입니다: Home Mixer는 파이프라인을 오케스트레이션하고, Thunder는 팔로우 중인 계정의 네트워크 내부 포스트를 밀리초 미만(sub-millisecond)의 속도로 제공하며, Phoenix는 Grok 기반의 트랜스포머를 사용하여 네트워크 외부 포스트를 검색하고 14가지 참여 확률을 예측하여 모든 후보를 랭킹하며, Candidate Pipeline은 전체 시스템을 위한 재사용 가능하고 조합 가능한 프레임워크를 제공합니다.

서론

수억 명의 사용자에게 서비스되는 추천 알고리즘을 오픈 소스로 공개하는 것은 단순한 투명성 제스처가 아닙니다 — 이는 아키텍처의 마스터클래스입니다. X의 시스템은 매일 5억 개의 포스트를 처리하여 약 1,500개의 후보로 좁히고, 200ms 이내에 모든 것을 랭킹합니다. Grok 기반의 트랜스포머가 수동으로 설계된 피처(Hand-engineered features) 없이 모든 핵심 작업을 수행합니다. 모든 휴리스틱(Heuristic)이 제거되었습니다. 모든 수동 가중치가 제거되었습니다. 각 구성 요소별로 파이프라인이 실제로 어떻게 작동하는지 소개합니다.

X의 '추천(For You)' 피드는 어떻게 200밀리초 미만에 5억 개의 포스트를 랭킹할까요?

이 시스템은 후보군(candidate set)을 점진적으로 좁혀나가는 계층적 파이프라인(layered pipeline)을 통해 이러한 속도를 달성합니다: Thunder는 네트워크 내(in-network) 포스트를 즉각적으로 제공합니다. 이는 밀리초 미만의 조회 속도를 가진 인메모리 포스트 저장소(in-memory post store)입니다. 당신이 팔로우하는 계정의 포스트는 이미 인덱싱되어 있어 외부 데이터베이스를 거치지 않고도 검색이 가능합니다. Thunder는 Kafka로부터 포스트 생성/삭제 이벤트를 소비하며, 보관 기간이 지난 포스트를 자동으로 정리합니다. Phoenix Retrieval은 네트워크 외(out-of-network) 후보군을 찾아냅니다. 투타워 모델(two-tower model)이 사용자(user)와 포스트(post)를 임베딩(embeddings)으로 인코딩한 다음, 전체 코퍼스(global corpus)에 대해 내적 유사도(dot product similarity)를 통해 상위 K개의 후보군을 검색합니다. 이 머신러닝(ML) 기반 검색은 당신이 팔로우하지 않는 계정의 콘텐츠를 발견합니다. Pre-scoring 필터는 부적격 후보군을 제거합니다. 비용이 많이 드는 트랜스포머 추론(transformer inference)이 실행되기 전에 중복 포스트, 오래된 포스트, 본인 포스트, 차단/뮤트된 계정, 이전에 봤거나 제공된 포스트, 뮤트된 키워드, 그리고 유료 결제 장벽(paywalled) 콘텐츠를 제거합니다. Phoenix Ranking은 남은 후보군의 점수를 매깁니다. Grok 기반의 트랜스포머(transformer)가 각 포스트에 대해 14가지 참여 확률(engagement probabilities)을 예측합니다. Weighted Scorer는 이를 결합하여 최종 점수를 산출합니다. Selection은 상위 K개를 선정합니다. 최종 점수에 따라 정렬되며, 피드 독점을 방지하기 위해 작성자 다양성 감쇄(author diversity attenuation)가 적용됩니다. "우리는 시스템에서 모든 수동 설계된 피처(hand-engineered feature)와 대부분의 휴리스틱(heuristics)을 제거했습니다. Grok 기반의 트랜스포머가 모든 핵심적인 작업을 수행합니다." — xAI, 리포지토리 README에서. 200ms 목표를 달성할 수 있는 이유는 비용이 많이 드는 ML 추론(트랜스포머 랭킹)이 5억 개의 원시 코퍼스(raw corpus)가 아니라, 이미 필터링된 후보군(약 1,500개의 포스트)에 대해서만 실행되기 때문입니다. 네 가지 구성 요소인 Home Mixer, Thunder, Phoenix, 그리고 Candidate Pipeline은 무엇이며 이들은 어떻게 결합될까요? Home Mixer (오케스트레이션 계층, Orchestration Layer): 진입점입니다. 특정 사용자에 대해 랭킹된 포스트를 반환하는 gRPC 엔드포인트(ScoredPostsService)를 노출합니다.

이 시스템은 8단계로 구성된 Candidate Pipeline (후보 파이프라인) 프레임워크를 활용합니다: Query Hydrators (쿼리 하이드레이터) → Sources (소스) → Hydrators (하이드레이터) → Filters (필터) → Scorers (스코어러) → Selector (셀렉터) → Post-Selection Filters (포스트 선택 필터) → Side Effects (사이드 이펙트). 2026년 5월 15일 업데이트에서는 팔로우하는 주제, 스타터 팩 (starter packs), 인프레션 블룸 필터 (impression bloom filters), IP, 상호 팔로우 그래프 (mutual follow graphs), 그리고 제공 이력 (served history)을 포함한 사용자 컨텍스트를 위한 쿼리 하이드레이터가 추가되었습니다.

Thunder (In-Network Post Store, 인네트워크 포스트 스토어): 모든 사용자의 최근 포스트를 추적하는 인메모리 (in-memory) 포스트 스토어입니다. Rust로 작성되었습니다. Kafka로부터 포스트 생성/삭제 이벤트를 소비하며, 원본 포스트, 답글/리포스트 (replies/reposts), 그리고 비디오 포스트에 대해 사용자별 스토어를 유지하고, 요청 사용자가 팔로우하는 계정으로부터 인네트워크 후보군을 제공합니다. 핵심 성능 특성은 외부 데이터베이스를 거치지 않고 밀리초 미만 (sub-millisecond)의 조회 속도를 구현한다는 점입니다. 포스트는 보관 기간이 지나면 자동으로 삭제됩니다. 이러한 설계는 X의 규모에서 200ms를 불가능하게 만들 데이터베이스 병목 현상을 제거합니다.

Phoenix (Grok Transformer — Retrieval + Ranking, Grok 트랜스포머 — 검색 + 랭킹): 두 가지 별개의 기능을 가진 ML (머신러닝) 컴포넌트입니다:

• Retrieval (검색, Two-Tower Model): User Tower (유저 타워)는 사용자 특징과 참여 이력을 임베딩 (embedding)으로 인코딩합니다. Candidate Tower (후보 타워)는 모든 포스트를 임베딩으로 인코딩합니다. 유사도 검색 (Similarity search)을 통해 내적 (dot product) 방식으로 상위 K개의 포스트를 검색합니다.
• Ranking (랭킹, Transformer with Candidate Isolation): 사용자 컨텍스트 (참여 이력)와 후보 포스트를 입력값으로 받습니다. 특수한 어텐션 마스킹 (attention masking)을 사용하여 후보들이 서로를 참조할 수 없도록 합니다. 즉, 후보들은 오직 사용자 컨텍스트만을 참조할 수 있습니다. 이를 통해 특정 포스트의 점수가 배치 내의 다른 어떤 포스트가 포함되어 있는지에 따라 달라지지 않도록 보장하며, 점수의 일관성을 유지하고 캐싱 (cacheable)이 가능하게 합니다.

Candidate Pipeline (Reusable Framework, 재사용 가능한 프레임워크): Source, Hydrator, Filter, Scorer, Selector, SideEffect의 6가지 트레이트 (trait)를 정의하는 Rust 트레이트 기반 프레임워크입니다. 소스(Sources)와 하이드레이터(Hydrators)는 가능한 경우 병렬로 실행되며, 구성 가능한 에러 핸들링 (error handling)을 지원합니다. 이를 통해 파이프라인의 조합 가능성 (composable)을 확보하여, 프레임워크를 수정하지 않고도 새로운 후보 소스, 필터 또는 스코어러를 추가할 수 있습니다.

Grok 기반의 Phoenix transformer는 어떻게 14가지의 서로 다른 참여 (engagement) 유형을 예측하고 이를 하나의 점수로 결합할까요? Phoenix는 단일 "관련성 (relevance)" 점수를 예측하는 대신, 다음과 같은 14가지의 구별된 행동에 대한 확률을 예측합니다:

Positive (긍정적)

• Action Type: favorite, reply, repost, quote, click, profile_click, video_view, photo_expand, share, dwell, follow_author

Negative (부정적)

• not_interested, block_author, mute_author, report

가중치 스코어러 (The Weighted Scorer)는 이를 다음과 같이 결합합니다:
Final Score = Σ (weight_i × P(action_i))

긍정적인 행동은 양(+)의 가중치를 가집니다. 부정적인 행동은 음(-)의 가중치를 가져, 사용자가 싫어할 가능성이 높은 콘텐츠의 순위를 낮춥니다. 이러한 다중 행동 (multi-action) 접근 방식은 단순히 사용자가 참여하는지 여부뿐만 아니라 어떻게 참여하는지를 포착하기 때문에, 단일 관련성 점수보다 더 미세한 차이 (nuanced)를 반영할 수 있습니다.

이 transformer 구현체는 xAI의 Grok-1 오픈 소스 릴리스를 포팅하여 추천 시스템 (recommendation system) 사용 사례에 맞게 조정되었습니다. 이는 검색 (retrieval) 및 랭킹 (ranking) 조회를 위해 해시 기반 임베딩 (hash-based embeddings)을 사용합니다.

"단일 '관련성 (relevance)' 점수를 예측하는 대신, 모델은 많은 행동에 대한 확률을 예측합니다." — xAI, 리포지토리 README 중

Phoenix의 후보 격리 (candidate isolation) 메커니즘은 어떻게 포스트들이 서로의 랭킹에 영향을 미치는 것을 방지할까요?

후보 격리는 리포지토리에서 강조된 5가지 핵심 설계 결정 중 하나입니다. transformer 추론 (inference) 동안, 후보들은 특수한 어텐션 마스킹 (attention masking)을 사용하여 서로를 참조할 수 없으며, 오직 사용자 컨텍스트 (user context)에만 집중할 수 있습니다. 이를 통해 두 가지 중요한 속성을 달성합니다:

1. 점수 일관성 (Score consistency) — 포스트의 점수는 우연히 같은 배치 (batch)에 포함된 다른 포스트가 무엇인지에 따라 변하지 않습니다. 동일한 포스트는 10개의 후보와 랭킹을 겨루든 1,500개의 후보와 겨루든 동일한 점수를 받습니다.
2. 점수 캐싱 가능성 (Score cacheability) — 점수가 배치 구성에 의존하지 않기 때문에, 미리 계산하여 캐싱할 수 있습니다. 이는 X의 규모에서 200ms 지연 시간 (latency) 목표를 달성하는 데 필수적입니다.

후보군 격리 (candidate isolation)가 없다면, 랭킹은 리스트 단위 의존성 (listwise dependency)을 나타낼 것입니다. 즉, 랭킹 풀에 무엇이 포함되어 있는지에 따라 포스트의 점수가 변하게 되어, 캐싱이 불가능해지고 추론 비용 (inference costs)을 예측할 수 없게 됩니다. 어텐션 마스크 (attention mask)는 각 후보가 사용자 컨텍스트 시퀀스 (user context sequence)에는 주목할 수 있게 하되, 후보 간의 교차 어텐션 (cross-attention)은 차단함으로써 이를 달성합니다. Transformer는 여전히 효율성을 위해 단일 순전파 (forward pass) 과정에서 모든 후보를 인코딩하지만, 어텐션 패턴을 제한하여 배치 구성 효과 (batch composition effects)를 방지합니다.

xAI는 왜 모든 수동 설계된 피처 (hand-engineered features)를 제거했을까요? 그리고 Transformer는 대신 무엇을 학습할까요? 전통적인 추천 시스템은 텍스트 피처, 작성자 인기도, 최신성 부스트 (recency boosts), 콘텐츠 카테고리 매칭, 참여 속도 휴리스틱 (engagement velocity heuristics)과 같은 수동 설계된 피처에 크게 의존합니다. 각 피처는 사용자 행동이 변화함에 따라 엔지니어링 노력, A/B 테스트, 유지보수를 필요로 합니다. xAI의 접근 방식은 이 모든 것을 단 하나의 원칙으로 대체합니다: Transformer가 사용자 참여 시퀀스 (user engagement sequences)로부터 관련성 (relevance)을 학습하게 하는 것입니다.

Transformer는 다음과 같은 데이터를 입력으로 받습니다:

• 사용자의 최근 참여 이력 (좋아요, 답글, 공유, 클릭한 내용)
• 후보 포스트의 콘텐츠 및 메타데이터 (metadata)
• 사용자 피처 (팔로잉 목록, 선호도)

이 원시 데이터 (raw data)로부터, 모델은 14가지 참여 확률 (engagement probabilities)을 예측하는 법을 학습합니다. 어떤 엔지니어도 "최신성 가중치 (recency weight)"나 "작성자 인기도 승수 (author popularity multiplier)"를 정의할 필요가 없습니다. 모델이 데이터로부터 이러한 패턴을 스스로 발견하기 때문입니다. 저장소(repository)에 따르면, 이 방식의 이점은 다음과 같습니다: "이는 우리의 데이터 파이프라인과 서빙 인프라 (serving infrastructure)의 복잡성을 크게 줄여줍니다."

이전에는 전용 데이터 파이프라인, 피처 스토어 (feature stores), 서빙 인프라가 필요했던 피처들이 이제는 Transformer에 의해 암묵적으로 학습됩니다. 작성자 다양성 점수기 (Author Diversity Scorer)는 포스트-Transformer (post-transformer) 단계에서 이루어지는 몇 안 되는 조정 중 하나로, 피드가 단일 계정에 의해 지배되는 것을 방지하기 위해 반복되는 작성자의 점수를 감쇄 (attenuate)시킵니다.

이것은 수동으로 설계된 관련성 기능(relevance feature)이 아니라, 머신러닝 (ML) 스코어링 이후에 적용되는 다양성 제약 조건(diversity constraint)입니다. 개발자들은 X의 컴포저블 파이프라인 아키텍처(composable pipeline architecture)와 인메모리 포스트 저장소(in-memory post store) 설계에서 무엇을 배울 수 있을까요? 세 가지 아키텍처적 교훈이 눈에 띕니다:

1. 특성 기반 파이프라인 구성 (Trait-based pipeline composition)
   Candidate Pipeline 프레임워크는 새로운 파이프라인 단계가 구현해야 하는 6가지 특성(Trait: Source, Hydrator, Filter, Scorer, Selector, SideEffect)을 정의합니다. 이를 통해 파이프라인 실행 및 모니터링을 비즈니스 로직으로부터 분리합니다. 관련 특성을 구현함으로써 새로운 후보 소스(candidate sources), 필터(filters) 또는 스코어러(scorers)를 추가할 수 있으며, 파이프라인 코드를 변경할 필요가 없습니다.

2. 지연 시간에 민감한 경로를 위한 인메모리 서빙 (In-memory serving for latency-critical paths)
   Thunder는 행성 규모(planet scale)의 환경에서 가장 빠른 데이터베이스 쿼리는 데이터베이스 쿼리가 아니라는 점을 입증합니다. 최근 포스트를 메모리에 유지하고, 업데이트를 위해 Kafka에서 데이터를 소비하며, 오래된 데이터를 자동으로 정리함으로써, Thunder는 외부 저장소 의존성 없이 밀리초 미만(sub-millisecond)의 조회 성능을 달성합니다. 이 패턴은 워킹 셋(working set)이 메모리에 적합하고 최신성(freshness)이 중요한 모든 시스템에 적용 가능합니다.

3. 독립적인 요소의 병렬 실행 (Parallel execution where independent)
   프레임워크는 가능한 경우 소스(sources)와 하이드레이터(hydrators)를 병렬로 실행합니다. 이는 단순히 속도에 관한 것이 아니라, 비용이 많이 드는 트랜스포머 추론(transformer inference) 단계 동안 GPU 파이프라인에 데이터가 계속 공급되도록 유지하기 위함입니다. 만약 하이드레이션(hydration)이 느려지면 GPU는 유휴 상태(idle)가 됩니다. 병렬 실행은 이러한 유휴 시간을 최소화합니다.

해당 리포지토리에는 Git LFS를 통해 배포되는 사전 학습된 미니 Phoenix 모델(256차원 임베딩, 4개의 어텐션 헤드, 2개의 트랜스포머 레이어, 약 3GB)이 포함되어 있어, 별도의 학습 없이도 즉시 추론이 가능합니다. 이는 시스템을 실험과 학습에 용이하게 만듭니다. 즉, X의 학습 인프라를 필요로 하지 않고도 실제 운영 중인 추천 시스템이 어떻게 작동하는지 연구할 수 있습니다.

자주 묻는 질문 (FAQ)
Q: X의 랭킹 알고리즘을 상업적 제품에 사용할 수 있나요?
네. 해당 리포지토리는 Apache 2.0 라이선스 하에 배포되어 상업적 이용, 수정 및 배포가 허용됩니다.

Grok-1 모델 가중치(weights)는 별도로 분리되어 있으며 자체 라이선스를 따릅니다. Q: 시스템은 어떤 언어로 작성되었나요? Candidate Pipeline, Thunder, 그리고 Home Mixer는 Rust(리포지토리의 57.4%)로 작성되었습니다. Phoenix(ML 컴포넌트)는 Python(42.6%)으로 작성되었습니다. Grok 기반의 트랜스포머(transformer)는 xAI의 Grok-1 오픈 소스 릴리스에서 포팅되었습니다. Q: 리포지토리에 학습 데이터가 포함되어 있나요, 아니면 추론(inference) 코드만 포함되어 있나요? 리포지토리에는 추론 파이프라인과 사전 학습된 미니 Phoenix 모델이 포함되어 있습니다. 학습 데이터와 전체 프로덕션 모델 가중치는 포함되어 있지 않습니다. 이는 추천 시스템(recommendation system)의 오픈 소스 릴리스에서 흔히 볼 수 있는 형태입니다. 즉, 사용자 데이터가 아닌 아키텍처와 추론 코드를 제공받게 됩니다. Q: 이것은 Twitter의 2023년 알고리즘 공개와 비교했을 때 어떤 차이가 있나요? Twitter의 2023년 공개 버전은 전신(precursor)에 해당합니다. xAI의 릴리스는 대대적인 업데이트입니다. 트랜스포머가 Grok-1에서 포팅되었고(이전의 ML 모델을 대체), 모든 수동 설계된 특징(hand-engineered features)이 제거되었으며, 이제 시스템에는 광고 혼합(ads blending), Grox 콘텐츠 이해(스팸, 분류, 정책 집행), 그리고 엔드 투 엔드(end-to-end) 추론 파이프라인이 포함됩니다. Q: 제 노트북에서 미니 Phoenix 모델을 실행할 수 있나요? 네. 사전 학습된 미니 모델은 약 3GB이며 배포 가능합니다.