메타가 광고 추천에 LLM식 스케일링 법칙을 적용한 방법 (멀티스테이지 시퀀스 모델)

왜 지금 다시 '시퀀스 모델링'인가

광고 추천 시스템은 매일 수십억 건의 유저 인터랙션을 처리합니다. 클릭, 조회, 구매 같은 행동의 순서와 타이밍을 그대로 학습하면, 수작업으로 만든 정적 피처보다 훨씬 풍부한 사용자 관심사 표현을 얻을 수 있다는 건 이미 알려진 사실이었어요.

문제는 스케일입니다. 하이브리드 구조(시퀀스 모델 + 별도 희소 피처 모델)는 프로덕션 요구사항은 만족하지만, 구조적으로 세 가지 트레이드오프를 안고 갑니다.

• 컴포넌트 간 손실 있는 지식 전달(lossy knowledge transfer)
• 여전히 남아 있는 수작업 피처 엔지니어링 의존
• 랭킹 모델과 시퀀스 모델 간 간섭(interference)으로 인한 스케일링 상한

시퀀스 길이와 트랜스포머 크기를 동시에 키우면 이 트레이드오프가 곧 병목이 됩니다. 이 지점에서 메타가 던진 카드가 멀티스테이지 시퀀스 모델이에요.

근거자료: From user sequences to scaling laws (Meta Engineering)

국내 추천 시스템 팀에서도 비슷한 고민을 자주 봅니다. 특히 커머스/광고 도메인에서 실시간 랭킹 레이턴시 예산이 빡빡한데 모델은 계속 키우고 싶은 상황이라면, 이 아키텍처는 꽤 현실적인 참고가 됩니다.

멀티스테이지 시퀀스 모델: 오프라인과 온라인을 분리하라

핵심 아이디어는 단순합니다. 무거운 유저 모델링은 오프라인으로, 가벼운 랭킹은 온라인으로 분리하는 거예요. 두 스테이지는 서로 다른 목적에 최적화됩니다.

1단계: 오프라인 유저 모델 (Upstream)

• 유저 히스토리를 **비동기(async)**로 처리
• 수천 길이의 시퀀스를 다루는 딥 트랜스포머 레이어 스택
• 결과를 유저 레벨 임베딩으로 캐싱
• 유저 피처와 광고/컨텍스트 피처를 엄격히 분리해서, 임베딩이 특정 광고 후보에 종속되지 않도록 보장

2단계: 온라인 랭킹 모델 (Downstream)

• 캐시된 유저 임베딩 + 실시간 유저 시그널 + 광고 후보 정보 결합
• 엄격한 레이턴시 예산 안에서 동작하도록 속도 최적화
• 오프라인에서 계산된 깊은 표현력을 그대로 활용

# 개념적 의사코드: 멀티스테이지 파이프라인
class OfflineUserModel:
    def __init__(self, num_layers: int, seq_len: int):
        self.transformer = DeepTransformer(layers=num_layers, max_len=seq_len)

    def compute_embedding(self, user_history: list) -> "Tensor":
        # 유저 히스토리만 사용. 광고/컨텍스트 피처는 절대 섞지 않는다.
        return self.transformer.encode(user_history)


class OnlineRankingModel:
    def __init__(self, ranking_head):
        self.head = ranking_head

    def rank(self, cached_user_emb, ad_candidate, realtime_signals):
        # 캐시된 유저 표현 + 실시간 시그널 + 광고 후보를 결합해 스코어 산출
        fused = fuse(cached_user_emb, ad_candidate, realtime_signals)
        return self.head(fused)


# 서빙 파이프라인
user_emb = offline_model.compute_embedding(user_history)  # 비동기, 캐시됨
for ad in candidate_ads:
    score = online_model.rank(user_emb, ad, realtime_signals)  # 밀리초 예산

이 분리의 진짜 효과는 컴퓨트 곡선을 분리할 수 있다는 점이에요. 오프라인 모델은 레이턴시 제약이 없으니 마음껏 키울 수 있고, 온라인 랭킹 모델은 서빙 예산 안에서만 튜닝하면 됩니다. 결과적으로 모델 복잡도와 서빙 비용을 분리해서 스케일링할 수 있게 됩니다.

두 가지 아키텍처 혁신

Dense Tokenization

기존 추천 시스템은 희소 피처 간 상호작용을 수작업 표현으로 잡아냈습니다. 이 접근은 희소 피처와 시퀀스 행동 데이터를 하나의 dense vocabulary로 통합해서, 어텐션 메커니즘이 상호작용을 데이터로부터 직접 학습하게 만듭니다.

Target-Aware Multi-Head Attention

토큰화된 희소 피처 + 광고 후보 정보를 유저 행동 시퀀스와 융합한 뒤, 메모리 효율적인 멀티헤드 어텐션으로 처리합니다. 각 레이어가 유저의 과거 행동을 스코어링 대상 광고에 비추어 가중할 수 있게 되는 구조예요. 여러 어텐션 블록을 안정적인 분포로 쌓으면, 긴 시퀀스가 점진적으로 **컴팩트한 표현으로 증류(distill)**됩니다.

실무 감각으로 말하면, 이건 "피처 엔지니어링을 모델이 대신하게 만든다"는 방향과 같습니다. 다만 초기 학습 비용과 데이터 파이프라인 복잡도는 확실히 올라가니, 팀 역량과 데이터 규모를 먼저 냉정하게 봐야 해요.

스케일링 법칙: 무엇이 진짜 레버인가

메타가 공개한 결과에서 가장 눈에 띄는 건 LLM 스타일의 로그-선형(log-linear) 스케일링 법칙이 광고 추천에서도 나타났다는 점입니다. 컴퓨트(FLOPs)가 늘어날수록 성능(정규화 엔트로피, NE)이 예측 가능하게 개선된다는 거죠.

실측 임팩트

• Instagram 전환율 +6%
• Facebook 전환율 +3%
• Facebook 광고 클릭 +3.5%

이 수치는 다른 모델 혁신과 합산된 누적 리프트라는 점을 감안해야 합니다. 단일 아키텍처 변경의 효과로만 읽으면 과대해석이에요.

이 기술의 한계와 주의사항

• 오프라인 임베딩의 staleness: 캐시된 유저 임베딩은 실시간 행동을 반영하지 못합니다. 캐시 무효화 전략과 TTL 설계가 성능의 절반입니다.
• 콜드 스타트 유저: 히스토리가 짧은 신규 유저는 오프라인 모델의 이점을 거의 못 받습니다. 시맨틱 피처가 이를 일부 보완하지만 완전한 해법은 아닙니다.
• 운영 복잡도 증가: 두 개의 모델, 두 개의 배포 파이프라인, 임베딩 스토어까지. 팀 규모가 작으면 오히려 독이 될 수 있습니다.
• 평가 지표 해석: NE(정규화 엔트로피) 개선이 곧 비즈니스 지표 개선으로 이어지는지는 별도 검증이 필요합니다.

국내 환경에서는 특히 개인정보 규제와 로그 보존 정책 때문에 긴 시퀀스를 그대로 쓰기 어려운 경우가 있습니다. 시퀀스 길이를 늘리는 전략을 세울 때는 법무/프라이버시 팀과 초기에 정렬해두는 게 안전해요.

정리: 무엇을 가져갈 것인가

메타의 이번 사례에서 실무적으로 가져갈 만한 건 세 가지입니다.

1. 구조 분리가 곧 스케일링 전략이다. 무거운 계산을 오프라인으로 밀어내고 온라인은 얇게 유지하는 패턴은, 광고가 아니더라도 검색·피드·알림 랭킹 등 레이턴시 민감한 모든 시스템에 적용 가능합니다.
2. 시퀀스는 길이보다 다양성이 먼저다. 시퀀스 길이만 늘리는 건 비용 대비 효율이 떨어질 수 있어요. 액션 타입을 섞는 것부터 시작하세요.
3. 스케일링 법칙은 예측 가능성이다. 로그-선형 곡선이 보인다는 건 "얼마를 투자하면 얼마나 좋아지는지"를 사전에 추정할 수 있다는 뜻입니다. 이건 조직 설득에 강력한 무기입니다.

이 아키텍처는 GEM(Generative Ads Recommendation Model)의 핵심 컴포넌트로 자리 잡았고, 저자들은 아직 스케일링 법칙이 포화되지 않았다고 밝히고 있습니다. 다음 단계로는 MoE(mixture-of-experts), cross-user 컴퓨트 공유, 고급 어텐션 기법 등 LLM에서 검증된 기법들을 추천 도메인에 이식하는 방향이 유력해 보입니다.

다음 단계 학습 방향

• LLM 스케일링 법칙 원논문을 먼저 읽고, 로그-선형 관계와 Chinchilla 최적점 개념을 이해하세요.
• Two-Tower / Retrieval-Ranking 분리 아키텍처를 직접 구현해보면, 이 글의 "분리" 개념이 왜 강력한지 체감할 수 있습니다.
• 임베딩 캐시 스토어(예: Redis, Feast) 운영 경험을 쌓아두면, 오프라인/온라인 분리 설계가 훨씬 수월해집니다.

함께 보면 좋은 글

• PDF 의료 기록을 FHIR 데이터로 자동 변환하는 서버리스 파이프라인 구축 가이드 (Bedrock + HealthLake) — 비동기 파이프라인 설계 감각을 함께 키울 수 있는 실습형 글입니다.
• 개인화와 실험은 왜 별도의 기술 스택이 필요한가? (스포티파이의 인사이트) — 이 글과 정확히 같은 문제의식(개인화 스택 분리)을 다른 각도에서 다룹니다.