X의 'For You' 피드는 어떻게 당신의 마음을 읽을까 — 오픈소스로 공개된 추천 알고리즘 완전 해부

들어가며: 5억 개 트윗 중 당신이 보는 건 1,500개

매일 X(구 트위터)에는 5억 개 이상의 게시물이 올라옵니다. 하지만 당신의 "For You" 피드에 표시되는 건 고작 수십 개. 전체의 0.00003%도 안 되는 게시물이 어떤 기준으로 선택되는 걸까요?

2026년 1월, xAI는 이 질문에 대한 답을 GitHub에 공개했습니다. xai-org/x-algorithm — X의 "For You" 피드를 구동하는 추천 알고리즘의 전체 소스코드입니다. 공개 6시간 만에 1,600개의 GitHub 스타를 받았죠.

이 글에서는 그 코드를 낱낱이 해부하되, 단순한 코드 리뷰가 아니라 왜 이런 설계가 나왔는지, 각 개념이 어떤 역사적 맥락에서 탄생했는지, 그리고 2026년 현재 이것이 추천 시스템의 미래에 어떤 의미인지까지 풀어보겠습니다.

1장. 추천 알고리즘의 진화: 시간순에서 AI까지

2006년: 모든 것은 시간순이었다

2006년, 트위터와 페이스북 뉴스피드가 처음 등장했을 때, 알고리즘이란 것은 존재하지 않았습니다. 단순히 가장 최근 게시물이 맨 위에 올라왔죠. 순수한 시간순(reverse chronological) 정렬.

문제는? 팔로우하는 계정이 수백 개가 넘어가면, 중요한 게시물을 놓치기 시작한다는 것이었습니다.

2009년: Facebook EdgeRank의 등장

페이스북은 2009년 EdgeRank라는 최초의 소셜 미디어 알고리즘을 도입합니다. 세 가지 요소로 게시물 순위를 매겼죠:

점수 = Affinity × Weight × Time Decay — 단순하지만 혁명적이었습니다. "모든 게시물이 평등하지 않다"는 사실을 알고리즘으로 표현한 최초의 시도였으니까요.

2011년: 머신러닝의 시대

페이스북이 EdgeRank를 폐기하고 머신러닝 기반 시스템으로 전환합니다. 2013년에는 이미 10만 개 이상의 특성(feature)을 분석하여 게시물 순위를 매겼습니다. 사람이 규칙을 만드는 대신, 기계가 데이터에서 패턴을 학습하기 시작한 것이죠.

2016~2023년: 모든 플랫폼의 알고리즘화

인스타그램(2016), 트위터(2016), 유튜브, TikTok — 모든 주요 소셜 플랫폼이 시간순을 버리고 알고리즘 기반 피드로 전환합니다. 특히 TikTok의 "For You Page"는 팔로우하지 않는 계정의 콘텐츠도 적극적으로 추천하는 패러다임을 만들었습니다.

2026년: X의 선택 — Grok Transformer

그리고 X는 한 단계 더 나아갑니다. 수작업으로 설계된 모든 피처를 제거하고, xAI의 Grok 대규모 언어모델에서 사용하는 Transformer 아키텍처를 추천 시스템에 적용합니다. 이것이 바로 Phoenix입니다.

2장. 전체 아키텍처: 새의 눈으로 보기

X의 추천 시스템은 크게 4개의 핵심 컴포넌트로 구성됩니다. 각각이 명확한 역할을 가지고, 조립 라인처럼 순차적으로 작동합니다.

비유하자면 이런 과정입니다:

Home Mixer는 레스토랑의 총 매니저입니다. 주문(사용자 요청)을 받으면 주방에 전달하고, 요리가 나오면 품질을 확인하고, 최종적으로 손님에게 서빙합니다.

Thunder는 단골 메뉴 냉장고입니다. 자주 시키는 메뉴(팔로우 계정의 최신 글)가 미리 준비되어 있어서 즉시 꺼낼 수 있습니다.

Phoenix는 스타 셰프이자 식재료 바이어입니다. 시장에서 새로운 식재료를 찾아오고(Retrieval), 모든 재료를 시식하여 등급을 매깁니다(Ranking).

Candidate Pipeline은 주방 시스템 자체입니다. 재료 검수, 위생 점검, 조리, 플레이팅까지의 표준 프로세스를 정의합니다.

3장. Home Mixer — 오케스트레이션의 기술

gRPC 기반 서비스

Home Mixer는 전체 파이프라인을 조율하는 오케스트레이션 계층입니다. Rust로 작성되어 있으며, ScoredPostsService라는 gRPC 서비스를 통해 사용자별 정렬된 게시물을 반환합니다.

7단계 파이프라인

사용자가 X 앱을 열고 "For You" 탭을 누르는 순간, 이 7단계가 밀리초 단위로 실행됩니다:

디렉토리 구조가 말해주는 것

Home Mixer의 코드 구조를 보면 각 단계가 독립 모듈로 분리되어 있습니다:

home-mixer/
├── query_hydrators/    ← 1단계: 사용자 컨텍스트 수집
├── sources/            ← 2단계: Thunder, Phoenix에서 후보 가져오기
├── candidate_hydrators/← 3단계: 메타데이터 보강
├── filters/            ← 4단계 & 7단계: 사전/사후 필터링
├── scorers/            ← 5단계: ML 점수 계산
├── selectors/          ← 6단계: 상위 K 선택
├── side_effects/       ← 로깅, 분석 이벤트
├── candidate_pipeline/ ← 파이프라인 실행 프레임워크
├── server.rs           ← gRPC 서비스 엔드포인트
└── main.rs             ← 서버 시작점

이 구조의 핵심 가치는 관심사의 분리(Separation of Concerns)입니다. 필터 로직을 수정해도 스코어링에 영향을 주지 않고, 새로운 후보 소스를 추가해도 기존 파이프라인을 건드릴 필요가 없습니다.

4장. Thunder — 번개처럼 빠른 인메모리 저장소

왜 "Thunder"인가?

당신이 팔로우하는 300개 계정이 지난 24시간 동안 올린 게시물을 가져오려면, 일반적으로 데이터베이스에 쿼리를 보내야 합니다. 하지만 5억 사용자가 동시에 이 작업을 하면? 데이터베이스가 버틸 수 없습니다.

Thunder는 이 문제를 해결합니다. Kafka 이벤트 스트림을 통해 게시물이 생성되는 순간 실시간으로 수집하고, 인메모리(서버 RAM)에 사용자별로 정리해 둡니다.

Kafka란?

Apache Kafka는 분산 이벤트 스트리밍 플랫폼입니다. 비유하자면, 거대한 실시간 우편 시스템이죠. 누군가 트윗을 올리면, 그 이벤트가 Kafka를 통해 Thunder에게 즉시 배달됩니다. 수백만 건의 이벤트가 동시에 발생해도 순서를 보장하며 전달합니다.

사용자 A가 트윗 작성
    ↓
Kafka Event Stream: {type: "create", post_id: "123", author_id: "A"}
    ↓
Thunder: A의 팔로워 목록 확인 → 해당 팔로워들의 인메모리 저장소에 추가
    ↓
팔로워 B가 "For You" 요청 → Thunder에서 즉시 반환 (<1ms)

5장. Phoenix — 추천의 두뇌

Phoenix는 이 시스템의 핵심 ML 컴포넌트입니다. 이름 그대로 — 기존의 수작업 피처 엔지니어링을 완전히 태우고(burn), 순수한 머신러닝으로 다시 태어난(reborn) 시스템입니다.

Phoenix는 두 단계로 작동합니다: Retrieval(검색)과 Ranking(순위 매기기).

5-1. Retrieval: Two-Tower 모델

Two-Tower가 뭔가요?

수백만 개의 게시물 중에서 당신에게 관련 있을 만한 것을 빠르게 찾아야 합니다. 모든 게시물에 대해 복잡한 모델을 돌리기엔 시간이 너무 오래 걸리죠. 이때 사용하는 것이 Two-Tower(두 탑) 모델입니다.

역사적 맥락: YouTube에서 시작된 Two-Tower

Two-Tower 모델의 기원은 2016년 Google의 YouTube 추천 논문으로 거슬러 올라갑니다. YouTube는 매일 수십억 개의 동영상 중에서 사용자에게 추천할 것을 골라야 했고, 모든 동영상에 복잡한 모델을 적용하는 것은 불가능했습니다.

해결책은 단순했습니다: 사용자와 아이템을 각각 독립적으로 벡터화한 뒤, 벡터 간 거리로 관련성을 판단하는 것. 이 접근법은 이후 Google, Spotify, Pinterest, LinkedIn 등 거의 모든 대규모 추천 시스템에 채택되었습니다.

X의 Two-Tower가 특별한 점은, 사용자 타워의 Transformer 구조가 랭킹 모델과 동일한 아키텍처를 공유한다는 것입니다. 검색과 순위 매기기에서 일관된 표현(representation)을 사용하므로, 검색 단계에서 높은 점수를 받은 게시물이 순위 매기기에서도 높은 점수를 받을 가능성이 높습니다.

5-2. Ranking: Grok Transformer와 Candidate Isolation

검색 단계에서 수백 개의 후보를 골랐다면, 이제 정밀하게 순위를 매겨야 합니다. 여기서 등장하는 것이 Phoenix Ranking 모델 — xAI의 Grok-1에서 가져온 Transformer 아키텍처입니다.

Grok-1에서 추천 시스템으로

Grok-1은 원래 314B 파라미터의 대규모 언어모델입니다. Mixture-of-Experts(MoE) 구조로, 64개 레이어, 48개 쿼리 헤드, RoPE(Rotary Position Embeddings) 등을 사용하죠.

X의 엔지니어들은 이 Transformer 아키텍처를 추천 시스템에 맞게 축소하고 재설계했습니다. 핵심 변경은 바로 Candidate Isolation(후보 독립 평가)입니다.

Candidate Isolation이 왜 중요한가?

일반적인 Transformer에서는 입력 토큰들이 서로 어텐션(attention)을 주고받습니다. 즉, 하나의 토큰이 다른 모든 토큰의 정보를 참조할 수 있죠.

하지만 추천 시스템에서 이것은 큰 문제를 일으킵니다:

어텐션 마스크의 구조

Transformer의 어텐션 마스크가 어떻게 Candidate Isolation을 구현하는지 시각화해 보겠습니다:

비유하자면 이렇습니다: 면접관(사용자 컨텍스트)이 10명의 지원자(후보 게시물)를 평가할 때, 각 지원자는 개별 면접실에서 독립적으로 면접을 봅니다. 지원자들은 면접관의 질문(사용자 취향)에는 답할 수 있지만, 다른 지원자가 뭐라고 답했는지는 모릅니다.

입력 구조: 3가지 임베딩 스트림

Phoenix Ranking 모델은 세 가지 종류의 입력을 받습니다:

특이한 점은 Hash 기반 임베딩을 사용한다는 것입니다. 일반적인 추천 시스템은 사용자 ID마다 고유한 임베딩 벡터를 학습하지만, 수억 명의 사용자와 수십억 개의 게시물에 대해 이렇게 하면 메모리가 폭발합니다. 대신 여러 개의 해시 함수를 사용하여 ID를 해시 테이블 인덱스로 변환하고, 해당 인덱스의 임베딩을 조합합니다.

6장. 15개 행동 예측: 단순한 "좋아요"를 넘어서

다중 행동 예측(Multi-Action Prediction)

기존 추천 시스템 대부분은 하나의 관련성 점수를 예측했습니다. "이 사용자가 이 게시물을 좋아할 확률은 몇 %인가?" 정도였죠.

Phoenix는 완전히 다릅니다. 15가지 서로 다른 행동에 대한 확률을 동시에 예측합니다:

가중치가 말해주는 것

이 가중치 체계에는 X의 제품 철학이 녹아 있습니다:

몇 가지 흥미로운 관찰:

팔로우 가중치가 가장 높다(+4.0) — "이 게시물이 너무 좋아서 작성자를 팔로우했다"는 가장 강한 긍정 신호입니다. 좋아요(+0.5)보다 8배 높습니다.

부정 신호가 긍정보다 강하다 — 차단(-3.0)은 좋아요(+0.5)의 6배, 신고(-5.0)는 10배의 영향력을 가집니다. 이것은 사용자 이탈 방지(retention)가 단기적 참여(engagement)보다 중요하다는 철학을 반영합니다.

최종 점수 계산식:

7장. Candidate Pipeline — 레고 블록 같은 프레임워크

Trait 기반 모듈형 설계

Candidate Pipeline은 추천 파이프라인의 재사용 가능한 프레임워크입니다. Rust의 Trait 시스템을 활용하여 각 단계를 독립적인 모듈로 정의합니다:

4개의 스코어러가 순차적으로 작동

스코어링 단계에서는 4개의 스코어러가 순서대로 적용됩니다:

1. Phoenix Scorer — Transformer 모델의 15가지 행동 예측값을 가져옵니다
2. Weighted Scorer — 예측값을 가중합하여 최종 관련성 점수를 산출합니다
3. Author Diversity Scorer — 같은 작성자의 게시물이 피드를 독점하지 않도록 중복 작성자의 점수를 감쇄합니다
4. OON (Out-of-Network) Scorer — 팔로우하지 않는 계정의 콘텐츠 점수를 조정합니다

Author Diversity Scorer는 특히 중요합니다. 이것이 없으면, 게시물을 많이 올리는 파워유저의 콘텐츠가 피드를 장악할 수 있습니다. 이 스코어러는 대량 게시 전략(volume-based strategy)의 효과를 의도적으로 제한합니다.

8장. 두 겹의 필터링: 왜 두 번 걸러야 할까?

사전 점수 필터 (Pre-Scoring)

ML 모델에 보내기 전에 명백히 불필요한 후보를 제거합니다. ML 추론은 비용이 크기 때문에, 여기서 최대한 걸러내는 것이 효율적입니다.

선택 후 필터 (Post-Selection)

ML 모델이 점수를 매기고 상위 K개를 선택한 후에 한 번 더 걸러냅니다:

• 삭제된 게시물 — 스코어링과 선택 사이에 삭제된 경우
• 스팸 콘텐츠 — 정교한 스팸 탐지 모델 적용
• 폭력/잔인한 콘텐츠 — 안전성 필터
• 대화 스레드 중복 — 같은 대화의 여러 분기가 선택된 경우 정리

왜 두 번 걸러야 할까요? 사전 필터는 비용 절약(ML 추론 횟수 감소)이 목적이고, 사후 필터는 안전성 보장(사용자에게 절대 보여선 안 되는 콘텐츠 차단)이 목적입니다. 서로 다른 이유로 존재하는 겁니다.

9장. 기술 스택: 왜 Rust와 Python인가?

Rust — 프로덕션 서빙

Thunder(인메모리 저장소), Home Mixer(오케스트레이션), Candidate Pipeline(파이프라인 프레임워크)은 모두 Rust로 작성되어 있습니다.

왜 Rust일까요? 200ms 미만의 응답 시간이 목표이기 때문입니다. 사용자가 앱을 열고 피드가 로드되는 데 200ms 이상 걸리면 체감 속도가 느려집니다. Rust는 가비지 컬렉션(GC) 없이 메모리 안전성을 보장하므로, 예측 가능한 저지연(predictable low latency)을 달성할 수 있습니다.

Python + JAX — ML 모델

Phoenix의 Transformer 모델은 Python과 JAX로 구현되어 있습니다. JAX는 Google이 개발한 수치 연산 라이브러리로, 자동 미분과 GPU/TPU 가속을 지원합니다. Grok-1도 JAX로 구현되었기 때문에, 아키텍처를 가져오기에 최적의 선택이었죠.

10장. 핵심 설계 원칙 — 5가지 철학

원칙 1: 수작업 피처 엔지니어링 제거

"시스템에서 수작업으로 설계된 모든 기능 및 대부분의 휴리스틱 알고리듬은 제거되었다."

전통적인 추천 시스템은 도메인 전문가가 "이 피처가 중요할 것이다"라고 판단하여 수작업으로 설계합니다. 예: "게시물의 해시태그 수", "작성자의 팔로워 수", "게시 후 경과 시간" 등.

X는 이것을 전부 제거했습니다. Transformer가 사용자의 행동 시퀀스에서 직접 패턴을 학습합니다. 사람이 "이것이 중요하다"고 알려주는 대신, 모델이 데이터에서 스스로 무엇이 중요한지를 발견합니다.

원칙 2: Candidate Isolation

어텐션 마스크를 통해 후보 게시물 간 상호 참조를 차단합니다. 이것은 일관된 점수 산출, 결과 캐싱 가능, 병렬 처리 용이라는 세 가지 실용적 이점을 제공합니다.

원칙 3: Hash 기반 임베딩

전통적인 임베딩 테이블 대신 여러 해시 함수를 사용한 임베딩 조회를 채택했습니다. 수억 명의 사용자와 수십억 개의 게시물에 대한 메모리 효율성을 확보하면서도, 해시 충돌의 영향을 여러 해시 함수로 분산합니다.

원칙 4: 다중 행동 예측

단일 "관련성" 점수가 아닌 15가지 행동에 대한 확률을 동시에 예측합니다. 이것은 멀티태스크 러닝(Multi-Task Learning)의 핵심 이점을 활용합니다 — 여러 관련된 태스크를 동시에 학습하면, 각 태스크의 성능이 개별 학습보다 높아집니다.

원칙 5: 모듈형 파이프라인

파이프라인 실행 및 모니터링 로직을 비즈니스 로직과 완전히 분리합니다. 새로운 소스, 필터, 스코어러를 추가할 때 기존 코드를 수정할 필요가 없습니다.

11장. 2026년, 이것이 의미하는 것

LLM이 추천 시스템을 먹어치우고 있다

X의 알고리즘은 더 큰 트렌드의 일부입니다: 대규모 언어모델(LLM) 기술이 추천 시스템의 핵심 인프라가 되고 있다는 것.

이것은 단순한 기술 공유가 아니라 조직적 효율성의 혁명입니다. LLM 팀이 개선한 Transformer 아키텍처가 곧바로 추천 시스템의 성능 향상으로 이어지고, 추천 시스템에서 발견한 패턴이 LLM의 학습에 피드백됩니다.

오픈소스의 의미: 투명성인가, 마케팅인가?

X는 이 코드를 Apache License 2.0으로 공개하고, 4주마다 업데이트하겠다고 약속했습니다. 하지만 몇 가지 빠진 것들이 있습니다:

코드를 읽을 수는 있지만, 실제로 재현하거나 검증하는 것은 불가능합니다. 학습된 가중치와 데이터 없이는 같은 결과를 낼 수 없으니까요. 그래도 이 수준의 공개는 주요 소셜 플랫폼 중 전례가 없는 것이며, 추천 시스템 연구자와 엔지니어에게 귀중한 학습 자료입니다.

당신의 피드를 바꾸고 싶다면

이 알고리즘을 이해하면, 당신의 For You 피드를 의도적으로 조절할 수 있습니다:

1. "좋아요"보다 "팔로우"가 8배 강하다 — 좋아하는 분야의 계정을 적극적으로 팔로우하세요
2. "차단"이 "좋아요"보다 6배 강하다 — 관심 없는 계정을 차단하면 유사한 콘텐츠가 빠르게 줄어듭니다
3. 다양성 스코어러가 존재한다 — 한 계정의 글을 아무리 좋아해도, 피드의 일정 비율 이상은 차지할 수 없습니다
4. 히스토리가 곧 프로필이다 — Transformer는 당신의 최근 행동 시퀀스에서 취향을 학습합니다. 의도적인 참여가 피드를 바꿉니다

마치며: 알고리즘은 거울이다

X의 "For You" 피드는 당신의 행동 패턴을 거울처럼 비추는 시스템입니다. 좋아요를 누른 것, 오래 머문 것, 공유한 것, 차단한 것 — 이 모든 행동이 Transformer에 입력되어, "이 사람은 다음에 무엇을 좋아할까?"를 예측합니다.

xAI가 Grok의 Transformer를 추천 시스템에 적용한 것은 단순한 기술 선택이 아니라, "AI의 핵심 인프라를 통합하겠다"는 전략적 결정입니다. 대화형 AI, 추천 시스템, 검색 — 모두 같은 Transformer 위에서 돌아가는 세계. 그것이 xAI가 그리는 미래입니다.

그리고 그 미래의 설계도가 지금, GitHub에 공개되어 있습니다.