모델 신선도 — 얼마나 자주 다시 만드는가, 그리고 왜 지면마다 다른가

최종 갱신: 2026-08-09

같은 회사 안에서도 컴포넌트별 재생성 주기가 주 단위에서 분 단위까지 4자릿수 차이가 난다. 이건 엔지니어링 성숙도 차이가 아니라 계층마다 신선도의 경제학이 다르기 때문이다. 이 노트의 본론은 주기 표가 아니라 그 이유다.

관측된 주기 — 한 표

출처와 인용문은 아래 각 절에.

왜 다른가 — 구조 4가지

1. 인덱스는 커버리지 문제, 랭커는 정확도 문제

후보 생성 인덱스에 없는 아이템은 점수가 낮은 게 아니라 아예 존재하지 않는다. 신규 아이템이 인덱스에 들어가기 전까지 도달 확률은 정확히 0이다. 이건 이진 문제다.

랭킹 모델은 다르다. 하루 묵은 랭커도 여전히 모든 후보에 점수를 준다. 순위가 조금 나빠질 뿐 graceful degradation이다.

[추정] — 이게 "인덱스 갱신은 분·초, 랭커 재학습은 시간·일"이라는 비대칭의 1차 원인이다. 근거: Meta가 신선도 예산을 컴포넌트별로 다르게 잡는다고 직접 서술한다(아래 3번), 그리고 SilverTorch가 인덱스 신선도만을 위해 별도 스트리밍 경로를 만들었다.

Meta 자신도 신선도를 인덱스 문제로 재정의한다:

"With index as a model module, maintaining index freshness equates to updating the model weights of a neural network in production, at scale, without taking the model offline."

[확인] — SilverTorch, engineering.fb.com, 2026-05-26

2. 출력을 캐싱하는 순간 그 타워의 재학습 주기가 내려앉는다

Two-tower의 핵심 이점은 캐싱이다. 그리고 그 캐싱이 곧 제약이 된다.

"The main advantage of the Two Tower approach is that user and item embeddings can be cached, making inference for the Two Tower model extremely efficient." "we can use an item tower to generate embeddings for items that can be used as candidates during retrieval. And we can do this on a daily basis using an offline pipeline." "During online retrieval we use the user tower to generate user embedding on the fly by fetching the freshest user-side features."

[확인] — Scaling the Instagram Explore recommendations system, Vladislav Vorotilov·Ilnur Shugaepov, 2023-08-09

같은 모델의 두 타워가 정반대 주기로 돈다. user tower는 요청마다 실행하니 언제든 바꿔도 되지만, item tower를 바꾸면 인덱스 전체를 다시 만들어야 한다. 즉 item tower의 재학습 주기는 모델 품질이 아니라 인덱스 재구축 비용이 정한다.

같은 블로그가 랭킹 쪽은 훨씬 짧게 잡는다:

"neural networks allow us to do this by utilizing continual online training, meaning we can re-train (fine-tune) our models every hour as soon as we have new data."

[확인] 같은 글. → 한 지면 안에서 랭킹 1시간 / item tower 1일 = 24배 차이가 나고, 그 차이를 만든 건 캐싱 여부다.

SilverTorch는 이 결합을 끊으려는 시도로 읽힌다 [추정]:

"SilverTorch decouples freshness from the full model publish cycle through streaming updates. As model parameters get updated based on the latest training, we periodically publish the full model as a complete snapshot. Between publishes, a continuous streaming service reads real-time signals — new items, updated engagement features, changed eligibility — and applies targeted updates in-place to the specific tensors in the in-memory model." "Updates land without interrupting serving and without redeploying the model."

[확인] — SilverTorch 블로그, 2026

publish 자체도 빨라졌다: "The publish leverages GPUs to compute item embeddings and clustering which reduce the publish time to build the model snapshot from days to 1 hour." [확인] — SilverTorch 논문 HTML, 2026

⚠ 단, 스트리밍 갱신 지연 수치는 논문에도 없다. "We leave the details of fresh index for future work." [확인] 같은 논문. 블로그가 메커니즘을 말하고 논문이 수치를 유보한, 흔치 않은 조합이다.

3. 파라미터 종류마다 신선도 예산이 다르다

가장 기계적인 서술은 Meta의 @Scale 발표에 있다.

"For instance, updates to item embeddings in late-stage ranking models can yield substantial gains with zero-second latency, whereas dense parameters can tolerate delays of tens of minutes without compromising performance."

[확인] — Model Freshness Systems at Scale, Xianzheng Dou·Lujia Zhang·Vahid Jazayeri·Vivek Khurana (Meta), @Scale 2025

→ "모델을 얼마나 자주 재학습하는가"라는 질문 자체가 잘못됐다. 하나의 랭커 안에서도 임베딩 테이블과 dense 층의 신선도 요구가 다르다. 이유는 [추정]이지만 명확하다 — item embedding은 새 아이템·새 인기도를 담아서 분포가 빨리 변하고, dense 층은 "참여를 어떻게 조합할 것인가"라는 느린 함수를 담는다.

같은 발표가 정의와 세대별 개선을 준다 (전부 [확인]):

• 정의: "How quickly the signals can be ingested, trained on, and used for providing recommendations is referred to as 'freshness.'" — 데이터 수집부터 서빙까지 end-to-end다. 학습 주기만이 아니다.
• "At this stage, the model-update latency was approximately three to six hours."
• "By leveraging these techniques, we achieved freshness at approximately 10-30 minutes."
• *"This brings freshness down to O (one minute)."*

4. 그래프는 "무엇의 그래프냐"가 주기를 정한다

X의 팔로우 그래프 커뮤니티 탐지: 7일.

override val firstTime: RichDate = RichDate("2020-10-04")
override val batchIncrement: Duration = Days(7)

[확인] — twitter/the-algorithm @ c54bec0, simclusters_v2/scalding/update_known_for/UpdateKnownFor20M145K2020.scala:44,46

이 숫자는 인용해도 되는 상수다. 같은 파일의 하이퍼파라미터들은 args.int(name, default) 꼴이라 코드값이 프로덕션 실행값과 다르지만(→ embedding-retrieval.md의 maxNeighbors 400 vs 100 사례), batchIncrement는 override val로 스케줄 자체에 박혀 있다. 런타임 인자로 덮이지 않는다. [확인]

Meta의 co-engagement 그래프: 3시간.

"The graph is constructed from 24 hours of engagement data and fully reconstructed every 3 hours" "The entire pipeline completes within one hour, enabling the 3-hour refresh cycle" "the 3-hour refresh may be insufficient for extremely time-sensitive scenarios"

[확인] — RankGraph-2: Lifecycle Co-Design for Billion-Node Graph Learning in Recommendation, Meta, 2026 (HTML 판. PDF 아님)

56배 차이가 나는 이유는 그래프가 담은 게 다르기 때문이다 [추정]: 팔로우 관계는 사람의 사회 구조라 느리게 변하고, co-engagement 엣지는 콘텐츠에 붙어 있어서 콘텐츠 수명만큼 빨리 죽는다. 24시간 윈도로 만든 그래프를 3시간마다 갈아엎는다는 건 엣지 절반 이상이 하루 안에 무의미해진다는 뜻이다.

같은 논문이 서빙 단에서 한 겹 더 신선도를 건다: "filtering the candidate pool to recently active users (e.g., past 15 minutes) yields the best quality" [확인]. → 인덱스 갱신 주기(3시간)와 서빙 시점 필터(15분)는 별개 레버다. 인덱스를 더 자주 못 만들면 조회 범위를 좁혀서 벌충한다.

X — 재학습 주기 대신 시간 감쇠로 신선도를 관리한다

X 공개 코드에는 모델 재학습 주기에 대한 단서가 거의 없다. 2026 Rust 레포 전체에 hourly / daily / retrain / continual 문자열이 0건이다. [확인] — GitHub code search, xai-org/x-algorithm, 2026-08-09

대신 신선도가 감쇠 상수와 TTL로 표현된다 (전부 [확인], twitter/the-algorithm @ c54bec0):

→ 같은 시스템 안에서 시간 상수가 12,500배 차이난다 (취향 100일 / 콘텐츠 8시간). 상세는 → embedding-retrieval.md.

[추정] X와 Meta는 신선도를 다른 층위에서 푼다. Meta는 모델 파라미터를 계속 갱신하고, X 공개 코드에서 보이는 건 "모델·커뮤니티는 오래 두고 입력을 시간 감쇠시킨다"에 가깝다. 단 X의 랭커 재학습 주기가 공개되지 않았을 뿐일 수 있으므로 비교로 확정하면 안 된다 — 근거는 부재이지 반증이 아니다.

Thunder의 2일 보존에는 부작용이 하나 붙는다: 스레드 루트가 만료되면 그 밑 답글이 통째로 사라진다. 인덱스 보존기간이 제품 동작을 결정하는 사례다. [확인] → x.md

케이스: Netflix — 가장 구체적으로 공개된 재학습 주기, 그리고 신선도 압력이 낮은 이유

빅테크 추천 모델 중 재학습 주기를 가장 정확히 공개한 사례다:

"pre-trained from scratch every month on interaction data, then fine-tuned everyday"

[확인] — Integrating Netflix's Foundation Model, 2025-11. 월 사전학습(전체 재구축) + 일 파인튜닝(증분)의 이중 주기 — 위 3번(파라미터 종류별 신선도 예산)의 모델 단위 버전이다. 표현 공간 전체는 느리게, 최신 데이터 반영은 빠르게. GenRec도 같은 패턴을 반복한다: Netflix-adapted LLM은 드물게, 랭킹 post-training은 자주 [확인] GenRec 블로그 2026.

그런데 이 주기가 X·Meta보다 느슨해도 되는 구조적 이유가 있다 [추정]:

• 신규 아이템이 스케줄로 온다. UGC는 초당 수천 개가 무작위로 생기지만 편성 카탈로그는 출시일이 사전에 알려져 있다. "인덱스에 없으면 도달 0"이라는 1번의 커버리지 압력이 약하다 — 신규 타이틀 문제는 신선도 문제가 아니라 프로모션 문제(빌보드 밴딧)로 넘어간다 → netflix.md.
• 콘텐츠 수명이 길다. 트윗 임베딩 반감기 8시간짜리 세계와 달리 영화·시리즈는 몇 달을 산다. co-engagement 그래프를 3시간마다 갈아엎을 이유가 없다.

추천 결과 자체를 미리 계산해 캐시한다 — 구조 2의 극단 사례. 2013년 3계층(offline/nearline/online) 구조부터 결과 프리컴퓨트가 기본이고 [확인] 2013 블로그, 라이브 이벤트 때는 시작 전에 추천을 만들어 디바이스로 밀어놓는다(1억 디바이스에 1분 내) [확인] 라이브 전달 블로그 2025. "출력을 캐싱하면 재학습 주기가 캐시 재구축 비용에 묶인다"의 목적어가 임베딩이 아니라 추천 리스트 전체다.

고전 세대 수치로 보정: TMIS 2015가 오프라인 실험 프로토콜 예시로 "이틀 전까지의 데이터"를 든다 [확인] — 프로덕션 학습 주기 진술은 아니지만, 일 단위 이상의 지연을 정상 운영으로 전제한 서술이라 당시 신선도 우선순위가 낮았다는 방증으로는 유효하다 [추정].

광고 — 신선도를 "측정 가능한 비용"으로 다룬 게 가장 오래됐다

[확인] 2014년 논문 초록이 이미 freshness를 튜닝 레버로 나열한다:

"Picking the optimal handling for data freshness, learning rate schema and data sampling improve the model slightly, though much less than adding a high-value feature, or picking the right model to begin with."

— Practical Lessons from Predicting Clicks on Ads at Facebook, He et al., ADKDD 2014

⚠ 이 논문의 "학습–테스트 간격이 벌어지면 NE가 얼마나 나빠지는가" 수치는 본문 PDF에만 있어 확인하지 않았다. 이 저장소 규칙상 PDF에서 얻은 수치는 인용하지 않는다. 초록의 정성 서술까지만 [확인]이다.

현행 광고 쪽 서술은 정성적이다 [확인] — Meta's Generative Ads Model (GEM), 2025-11-10:

• "VMs often suffer from stale supervision caused by delays in FM training and evaluation as well as domain mismatches between GEM or FM predictions and the VMs' surface-specific objectives."
• 대응책이 student adapter다: "a lightweight component that refines the teacher's outputs using the most recent ground-truth data"
• "we also perform continuous online training to refresh the FMs"

→ 여기서 신선도 문제가 한 겹 더 접힌다. foundation model → vertical model 증류 구조에서는 선생 모델의 낡음이 학생 모델의 편향으로 전파된다. 그래서 학생 쪽에 최신 라벨로 보정하는 층을 따로 단다. 단일 모델 시대에 없던 형태의 staleness다.

⚠ "광고 모델이 몇 시간 단위로 낡는다"는 시간 수치의 1차 출처는 찾지 못했다. [추정] — 가장 가까운 근거는 @Scale 2025의 *"three to six hours"*인데 그건 추천 모델 전반에 대한 서술이고 광고 한정이 아니다. 광고 수치로 인용하면 안 된다.

신선도가 인프라 지표에서 제품 지표로 승격됐다

Meta는 2025년부터 "당일 게시물 비중"을 실적발표에서 직접 보고한다. 전부 [확인], IR 전사본 → facebook.md:

SilverTorch 블로그가 같은 지표를 자기 성과로 연결한다: "The result shows up in the recency of recommended content. Same-day posts now represent a significant portion of recommendations..." [확인], 2026

[추정] 인프라 신선도와 제품 recency 지표가 같은 축에 놓였다. 3개 분기 연속 별도 지표로 보고된다는 건 recency가 명시적 랭킹 목표로 승격됐다는 뜻이고, 그렇다면 신선도 투자는 지연 최적화가 아니라 목적함수의 일부다.

이 케이스에서 일반화할 수 있는 것

• "모델을 얼마나 자주 재학습하나"는 단수형 질문이라 답이 없다. 한 지면 안에 랭커(1시간), item tower(1일), 그래프(3시간), 인덱스(스트리밍), 캐시(600초)가 각자 다른 주기로 돈다. 어느 컴포넌트인지 안 밝힌 주기 수치는 무의미하다.
• 출력을 캐싱하면 그 컴포넌트의 재학습 주기는 캐시 재구축 비용에 묶인다. two-tower의 item tower가 교과서 사례다. 신선도를 높이려면 모델을 자주 학습시키는 게 아니라 캐시 갱신 방식을 바꿔야 한다 — SilverTorch의 in-place tensor 갱신이 정확히 그 답이다.
• 인덱스 신선도와 서빙 시점 필터는 별개 레버다. RankGraph-2는 3시간마다 그래프를 다시 만들면서 서빙에서는 15분 내 활동 유저로 후보를 좁힌다. 인덱스를 더 자주 못 만들면 조회 범위로 벌충할 수 있다.
• 파라미터 종류별로 신선도 예산이 다르다. item embedding은 지연 0초가 이득이고 dense 층은 수십 분을 견딘다. 전체 모델을 통째로 자주 publish하는 건 비싼 데다 필요도 없다.
• 그래프의 갱신 주기는 그래프가 담은 대상의 수명을 따라간다. 팔로우 그래프 7일 vs co-engagement 그래프 3시간, 56배 차이.
• 신선도는 학습 주기가 아니라 end-to-end 지연이다. Meta의 정의가 *"ingested, trained on, and used"*다. "매시간 학습"이라고 써도 데이터 수집이 3시간 늦으면 신선도는 3시간이다.
• 증류 구조에서는 선생의 낡음이 새로운 종류의 staleness가 된다. GEM의 student adapter가 그 대응이다.
• 주기 수치를 코드에서 캘 때는 상수 종류를 봐야 한다. X의 batchIncrement = Days(7)은 override val이라 인용 가능하지만, 같은 파일의 args.int(name, default) 값들은 프로덕션 실행값이 아니다. → embedding-retrieval.md
• 신선도 압력은 아이템 유입의 형태가 정한다. 무작위 대량 유입(UGC)이면 인덱스 커버리지가 분·초 문제가 되고, 스케줄된 소량 유입(편성 카탈로그)이면 신선도가 프로모션 문제로 바뀐다. Netflix가 월+일 이중 주기로 버티는 건 기술 격차가 아니라 문제 형태 차이다.
• "전체 재구축 + 증분 갱신" 이중 주기가 반복 패턴이다. SilverTorch(스냅샷 1시간 + 스트리밍 in-place), Netflix FM(월 사전학습 + 일 파인튜닝), GenRec(어댑티드 LLM 드물게 + post-training 자주). 규모가 큰 표현일수록 느린 축에, 최신성은 빠른 축에 싣는다.

누가 이걸 쓰는가

• Meta / Facebook — 신선도 인프라를 가장 상세히 공개했다. @Scale 2025(3–6시간 → O(1분)), SilverTorch(index as model, 스냅샷 1시간 + 스트리밍 in-place), RankGraph-2(3시간), GEM(continuous online training + student adapter). 콜드스타트·retrieval 맥락은 → facebook.md [확인]
• Instagram Explore — 랭킹 1시간 fine-tune / item tower 1일. 이 저장소에 서비스 노트 없음. [확인]
• X — SimClusters KnownFor 7일, 트윗 임베딩 실시간 누적, 반감기 100일/8시간, Thunder 2일, 캐시 TTL 600초. 랭커 재학습 주기는 찾지 못했다. → x.md, embedding-retrieval.md [확인](감쇠·TTL) / [추정](재학습 주기 — 공개 레포 2세대에 학습 스케줄러가 없고 X 공식 블로그에도 진술이 없다. 미공개 내부 파이프라인까지 없다는 근거는 아니다)
• Netflix — FM 월 사전학습 + 일 파인튜닝(가장 구체적인 공개 주기), 임베딩 스토어 일 단위, 추천 결과 프리컴퓨트가 기본. 신선도 압력 자체가 낮은 구조. → netflix.md [확인]
• 그 외 — 미조사. 열린 질문.

아직 확인 못한 것

• X의 랭커(Phoenix/Navi) 재학습 주기. 공개 코드에 학습 파이프라인 자체가 없다 → x.md.
• SilverTorch 스트리밍 갱신의 실제 지연. 논문이 *"future work"*로 유보했고 블로그도 수치를 안 준다.
• Meta 광고 모델의 시간 단위 staleness 비용. 1차 출처 미확보. 2014 논문 본문에 실험이 있으나 PDF라 이 저장소 규칙상 인용 불가 — HTML/ACM 판을 찾으면 해결된다.
• Facebook Feed 본체(비 Reels)의 랭커 재학습 주기. system card·2021 블로그 어디에도 없다.
• @Scale 2025의 "O(1분)"이 어느 지면·어느 파라미터에 적용되는지. 발표 요약만 확인했고 세부 범위가 불명.
• Instagram Explore의 1시간 fine-tune이 2026년에도 유효한지. 근거가 2023년 글 하나뿐이다.
• X의 SimClusters 7일 주기가 2025·2026에도 도는지. simclusters_v2/는 2023-04 이후 한 바이트도 안 바뀌었고, 2026 레포에는 SimClusters 참조가 아예 없다 → x.md. 코드가 남아 있다고 도는 건 아니다.

출처

• Model Freshness Systems at Scale — 2025, 발표(@Scale, Meta). Xianzheng Dou·Lujia Zhang·Vahid Jazayeri·Vivek Khurana. 신선도 정의와 세대별 수치의 1차 출처.
• SilverTorch: Index as Model — A New Retrieval Paradigm for Recommendation Systems — 2026, 블로그.
• SilverTorch: A Unified Model-based System to Democratize Large-Scale Recommendation on GPUs — 2026, 논문. HTML 판. publish 시간 "days to 1 hour".
• RankGraph-2: Lifecycle Co-Design for Billion-Node Graph Learning in Recommendation — 2026, 논문(Meta). HTML 판. 3시간 재구축, 24시간 윈도, 15분 활성 유저 필터.
• Scaling the Instagram Explore recommendations system — 2023, 블로그. 시간당 fine-tune, item tower 일 단위.
• Meta's Generative Ads Model (GEM) — 2025, 블로그. stale supervision, student adapter.
• Practical Lessons from Predicting Clicks on Ads at Facebook — 2014, 논문(ADKDD). 초록만 확인, 본문 수치 미인용.
• twitter/the-algorithm — 2025-09-03 커밋 c54bec0, 공개 소스코드. UpdateKnownFor20M145K2020.scala:44,46, InterestedInFromKnownFor.scala:286-301, summingbird/common/Configs.scala:38, Utils.scala:47-49.
• xai-org/x-algorithm — 2026, 공개 소스코드. thunder/posts/post_store.rs:521-526.
• Meta IR 전사본 (Q3 2025 / Q4 2025 / Q1 2026) — same-day 비중 수치. 링크는 facebook.md 출처 절.
• Integrating Netflix's Foundation Model — 2025, 블로그. 월 사전학습 + 일 파인튜닝의 1차 출처.
• System Architectures for Personalization and Recommendation — 2013, 블로그. offline/nearline/online 3계층.
• The Netflix Recommender System (TMIS) — 2015, 논문. 학습 데이터 "최대 이틀 전".
• Behind the Streams: Real-Time Recommendations for Live Events — 2025, 블로그. 프리컴퓨트 + 1억 디바이스 1분 내 전달.