소셜 미디어 피드의 Fan‑Out: 기본 원리로 설명

I’m ready to translate the article for you, but I don’t see the text you’d like me to translate—only the source citation is provided. Could you please paste the content you want translated? Once I have the text, I’ll keep the source line exactly as‑is and translate the rest into Korean while preserving all formatting, markdown, and code blocks.

가장 간단한 질문부터 시작하기

팬아웃에 대해 이야기하기 전에, 우리가 실제로 해결하고자 하는 문제가 무엇인지 합의해야 합니다.

브랜딩과 알고리즘을 제외한 소셜 미디어 피드는 다음과 같이 요약됩니다:

누군가가 게시물을 만들면, 다른 사람들이 이를 볼 수 있어야 합니다.

그것이 전체 기능입니다. 좋아요, 순위, 추천, 알림 등 모든 부가 기능은 그 간단한 요구사항이 규모가 커지면 엄청나게 비용이 많이 들기 때문에 존재합니다.

이 문장을 시스템 언어로 번역해 보겠습니다:

단일 쓰기 작업은 다수의 읽기 가능한 결과를 초래해야 합니다.

이 하나의 쓰기에서 다수의 읽기로의 변환을 우리는 팬아웃이라고 부릅니다. 팬아웃은 기능이 아니라 결과입니다.

기본 원칙: 현실이 우리에게 강요하는 것

디자인을 선택하기 전에 문제 공간의 형태를 이해해야 합니다. 이것은 의견이 아니라 사람과 컴퓨터가 행동하는 방식에 의해 부과되는 제약입니다.

읽기가 쓰기보다 훨씬 많다

어떤 사회 시스템에서도 사용자는 쓰기보다 훨씬 더 많이 읽습니다. 하나의 게시물은 수천, 수백만, 혹은 수억 번 읽힐 수 있지만, 작성은 정확히 한 번만 이루어집니다.

이 비대칭은 중요합니다. 읽기를 비용이 많이 들게 만드는 설계는 지속적으로 고통을 겪게 됩니다. 쓰기를 비용이 많이 들게 만드는 설계는 가끔만 고통을 겪습니다. 규모가 커질수록 시스템은 거의 항상 고통을 겪기보다는 가끔 고통을 겪는 쪽을 선택합니다.

소셜 그래프는 폭력적으로 불균형하다

대부분의 사용자는 팔로워 수가 적습니다. 소수의 사용자는 엄청난 수의 팔로워를 가지고 있습니다. 여기에는 부드러운 곡선이 없으며, 절벽과 같습니다.

이는 “이 게시물을 팔로워에게 보여주기”의 비용이 보통은 작지만, 때때로 천문학적으로 크게 될 수 있음을 의미합니다. 설계가 이를 명시적으로 고려하지 않으면 테스트에서는 완벽히 동작하지만 실제 운영에서는 붕괴합니다.

지연 시간은 사용자 감정이며, 지표가 아니다

인간 관점에서 100 ms와 300 ms의 차이는 거의 느껴지지 않습니다. 300 ms와 1 s의 차이는 깨진 것처럼 느껴집니다.

피드는 즉각적으로 느껴져야 합니다. 즉 피드 읽기는 평균이 아니라 거의 항상 빠르게 이루어져야 합니다. 평균 지연 시간보다 꼬리 지연 시간이 더 중요합니다.

저장은 계산 및 네트워크 홉보다 저렴하다

디스크는 저렴합니다. CPU 시간과 네트워크 호출은 그렇지 않습니다. 추가적인 쿼리, 추가적인 서비스 홉, 추가적인 병합 단계마다 지연 시간이 발생합니다.

이 때문에 실제 시스템은 데이터를 중복하더라도 사전 계산과 캐싱을 선호하게 됩니다.

이 제약들을 명심하세요. 팬‑아웃은 바로 이러한 제약 때문에 존재합니다.

가장 명백한 해결책 (그리고 왜 실패하는가)

피드를 구축하는 가장 간단한 방법은 사용자가 요청할 때마다 피드를 계산하는 것입니다. 이 접근 방식은 일반적으로 fan‑out on read 라고 불립니다.

개념적 작동 방식

1. 사용자가 피드를 열면 시스템은 사용자가 팔로우하고 있는 사람들을 조회합니다.
2. 각각의 사용자로부터 최신 게시물을 가져옵니다.
3. 모든 게시물을 병합하고 정렬·순위 매긴 뒤 결과를 반환합니다.

사전 계산은 없으며, 모든 작업이 실시간으로 이루어집니다.

모두가 여기서 시작하는 이유

• 깔끔하게 보입니다.
• 중복을 피할 수 있습니다.
• 쓰기 작업이 간단합니다.
• 저장소 사용량이 적습니다.
• 논리가 제품 정의와 직접 연결됩니다: “내가 팔로우하는 사람들의 게시물을 보여줘.”

프로토타입이나 초기 단계 제품을 만들 때는 종종 잘 동작하므로 매력적입니다.

규모가 커지면 무너지는 이유

• 피드를 읽는 비용이 팔로우하는 사람 수에 비례하게 되므로, 하나의 요청이 수십·수백 개의 데이터베이스 쿼리로 확산됩니다.
• 캐시 미스가 문제를 증폭시킵니다.
• 순위 매기기 로직이 추가적인 연산을 요구합니다.
• 네트워크 지연이 누적됩니다.

그 결과 예측할 수 없는 지연 시간이 발생합니다: 일부 피드 요청은 빠르지만, 다른 요청은 매우 느립니다. 실제 트래픽이 유입되면 시스템이 급격히 흔들리기 시작합니다.

이는 확장 가능한 시스템의 기본 규칙을 위반합니다: 읽기 경로는 비용이 제한되어야 합니다. fan‑out on read 은 사용자가 성능을 가장 중요하게 여기는 순간에 읽기 비용을 급격히 높입니다.

문제를 뒤집어 보기

이를 해결하기 위해 엔지니어들은 문제를 뒤집습니다. 사용자가 읽을 때 피드를 계산하는 대신, 사용자가 쓸 때 피드를 계산합니다. 이 접근 방식은 쓰기 시 팬‑아웃이라고 합니다.

작동 방식

사용자가 게시물을 만들면 시스템은 해당 사용자의 팔로워를 조회하고, 각 팔로워의 피드에 해당 게시물에 대한 참조를 미리 삽입합니다. 팔로워가 나중에 피드를 열면 시스템은 미리 만들어진 목록을 그대로 읽어옵니다.

왜 이렇게 하면 좋은가

• 피드 읽기는 단순 조회가 되며, 병합이나 무거운 연산이 필요 없습니다.
• 지연 시간이 예측 가능하고 낮아집니다.
• 읽기가 쓰기보다 많이 발생한다는 이전 제약과 완벽히 일치합니다: 한 번 비용을 지불하고 여러 번 이점을 얻습니다.

모든 사용자의 팔로워 수가 비슷하다면 이것으로 이야기가 끝났을 것입니다. 안타깝게도 인간은 모든 것을 망칩니다.

유명인 문제

Fan‑out on write는 숨겨진 전제가 있습니다: 사용자당 팔로워 수가 적당하다는 전제입니다. 수백만 명의 팔로워를 가진 사용자가 글을 올리면, 시스템은 단일 트랜잭션에서 수백만 개의 엔트리를 기록해야 하며, 이는 저장소, CPU 및 네트워크 자원을 압도할 수 있습니다.

나머지 기사(보여지지 않음)에서는 이러한 “유명인” 엣지 케이스를 처리하기 위한 전략을 탐구합니다. 여기에는 하이브리드 팬‑아웃, 지연 전파, 샤딩 기법 등이 포함됩니다.

The Cost of Fan‑out on Write

대부분의 사용자에게는 fan‑out on write가 관리 가능한 수준입니다.
예를 들어 누군가가 200명의 팔로워를 가지고 있다면, 200개의 피드 항목을 삽입하는 것은 큰 일이 아닙니다.

하지만 일부 사용자들은 수백만 명의 팔로워를 보유하고 있습니다.
이 경우 단 하나의 게시물이 수백만 건의 쓰기를 발생시키며—샤드에 걸쳐, 복제되고, 큐에 쌓일 수도 있습니다. 비동기식이라 할지라도 시스템에 막대한 부하를 줍니다.

Rule: No single request should have unbounded cost.

따라서 순수한 fan‑out on write는 다른 방식으로 실패합니다.

The Solution Real Systems Converge On

Large social systems don’t pick one approach; they combine them. This is called a hybrid fan‑out model.

How It Works

이 방식은 최악의 경우 쓰기 비용을 제한하면서 대부분 사용자에게 빠른 읽기를 유지합니다.

• Is it elegant? Not really.
• Does it survive real traffic? Yes.

That trade‑off is what matters.

피드가 실제로 무엇인지 재고하기

일반적인 오해: 피드는 쿼리가 아니다.

피드는 구현된 뷰 — 사전에 계산된, 사용자별 콘텐츠 참조(포인터) 인덱스이며, 실제 콘텐츠 자체는 아니다.

일반적인 피드 항목 필드:

• user_id
• post_id
• timestamp
• metadata (랭킹에 사용)

게시물 콘텐츠는 다른 곳에 저장된다.

이러한 분리를 통해 시스템은 다음을 할 수 있다:

• 피드 재구축
• 콘텐츠 재랭킹
• 모든 것을 다시 쓰지 않고 삭제 처리

피드를 캐시된 인덱스로 보면 팬‑아웃이 계산 문제가 아니라 유지보수 문제가 된다.

이벤트 기반 팬‑아웃은 필수

팬아웃을 동기식으로 수행하지 마세요.

1. 이벤트를 발생시켜 포스트가 생성될 때.
2. 백그라운드 워커가 이벤트를 소비하고 피드를 비동기적으로 업데이트합니다.

혜택

• 재시도 및 백프레셔 처리
• 장애 복구
• 소셜 미디어가 궁극적으로 일관성을 가진다는 현실에 부합

사용자는 포스트가 피드에 200 ms 후에 나타났는지 1초 후에 나타났는지 구분할 수 없습니다. 여러분의 인프라는 확실히 구분할 수 있습니다.

실제로 중요한 마인드셋

피드 시스템을 설계할 때, 구체적인 데이터베이스나 큐 기술은 덜 중요하고, 여러분이 묻는 질문이 더 중요합니다:

• 최악의 경우 팬‑아웃 규모는 얼마인가?
• 요청 비용이 제한되어 있는가?
• 워커가 지연될 경우 어떻게 되는가?
• 피드를 재구성할 수 있는가?
• 삭제와 프라이버시 변경은 어떻게 전파되는가?

팬‑아웃은 영리함에 관한 것이 아니라 제약을 존중하는 것입니다.

실제로 적용되는 최종 비유

• Fan‑out on read = 배가 고플 때마다 요리하기.
• Fan‑out on write = 식사 준비하기.

요리는 한 번에 millions 명에게 제공해야 할 때까지는 유연해 보입니다.
대규모에서는 준비가 승리합니다.

요약

Fan‑out은 최적화가 아니다; 이는 극단적인 편향 하에서 하나의 행동을 여러 경험으로 전환하는 불가피한 결과이다.

피드가 사전 계산된, 사용자별 뷰이며 지속적인 압력 하에 유지된다는 것을 이해하면, 소셜 미디어 시스템 설계의 나머지 부분이 불편할 정도로 이해가 된다.

그리고 맞다, 여기서부터는 더 어려워진다.