meta·2026년 8월 12일·4분 읽기큐레이션 요약

종단 간 암호화와 검증 가능성을 보장하는 WhatsApp용 사기 경보 시스템 구축 방법

WhatsApp의 Scam Alert는 종단간 암호화를 유지하면서 사기 가능성이 있는 메시지를 기기에서만 분석하는 선택형 기능이다. 메시지 내용은 서버로 전송되거나 자동 신고되지 않으며, 사용자가 경고를 본 뒤 차단·신고·대화 지속 여부를 직접 결정한다. WhatsApp은 온디바이스 처리, 사용자 통제, 공개 검증 가능성을 통해 개인정보 보호와 사기 탐지의 균형을 이루려 한다. ## 온디바이스 사기 탐지 - 사용자가 기능을 켜면 사기 탐지용 머신러닝 모델이 기기에 다운로드된다. - 모델은 연락처에 등록되지 않은 사람이 보낸 메시지를 대상으로 다음 신호를 분석한다. - 대화의 구조 - 문장 및 언어적 특징 - 기존 사기 대화에서 관찰된 패턴 - 분류는 확률 기반으로 수행되며, 메시지 내용은 분류를 위해 WhatsApp·Meta·제3자 서버로 전송되지 않는다. - 모델이 사기 가능성이 높다고 판단하면 해당 사용자에게만 채팅 경고가 표시된다. 상대방에게는 경고가 보이지 않는다. ## 사용자가 결정하는 대응 방식 - 경고를 본 사용자는 다음 중 하나를 선택할 수 있다. - 대화 차단 - 신고 - 계속 대화 - 오탐이라고 판단하면 채팅을 신뢰 대상으로 표시할 수 있다. - 신뢰 처리된 채팅은 경고가 제거되고, Scam Alert가 해당 채팅을 다시 경고하지 않는다. - 사용자가 원할 경우 정확도 개선을 위해 최근 수신 메시지 5개를 WhatsApp에 공유할 수 있다. - 메시지 내용이나 사기 탐지 사실이 서버에 전달되는 유일한 경로는 사용자가 명시적으로 신고하거나 공유하는 경우다. ## 설계 원칙 - **기기 내 처리**: 머신러닝 모델과 분석 대상 메시지는 모두 사용자 기기에 남는다. - **자동 신고 금지**: WhatsApp은 사용자의 행동 없이 메시지나 탐지 결과를 서버로 보낼 수 없다. - **사용자 통제**: 기능을 언제든 켜거나 끌 수 있고, 경고에 대한 최종 판단도 사용자가 내린다. - 최근 온디바이스 머신러닝 기술 발전으로 모바일 기기에서도 성능·배터리·모델 크기의 부담을 줄이면서 텍스트 분류가 가능해졌다는 점을 활용한다. ## 개인정보 보호형 분석 WhatsApp은 기능이 실제 사기를 잘 탐지하는지, 모델 업데이트 후 성능이 악화되지 않았는지를 확인하기 위해 제한적인 통계만 수집한다. - 수집 대상은 메시지 원문이 아닌 다음 두 종류의 집계 신호다. - **경고 횟수**: 기기 내 모델이 사기 경고를 표시한 횟수 - **사용자 행동 횟수**: 경고 이후 사용자가 신뢰 처리, 차단, 신고 등을 선택한 횟수 - 이 통계는 모델의 경고 발생률과 오탐률을 평가하는 데 사용된다. - 개인별 행동이나 특정 메시지를 식별할 수 있도록 설계하지 않는다. - 차등 개인정보보호(differential privacy)를 적용해 통계에 조정된 노이즈를 추가한다. - 이에 따라 특정 개인의 데이터가 포함되거나 제외되더라도 전체 통계에 미치는 영향이 매우 작아진다. ## 기밀 연합 분석 파이프라인 집계 통계를 보호하기 위해 WhatsApp은 기밀 컴퓨팅 기반의 연합 분석 구조를 사용한다. - **로컬 집계** - 원시 이벤트는 기기를 떠나지 않는다. - 기기는 데이터를 자체적으로 횟수로 합산한 뒤 집계값만 전송한다. - 전송 시점은 무작위화되고, 기기 식별자는 포함되지 않는다. - 시간 정보도 정확한 시각이 아닌 넓은 구간으로 제한된다. - **기밀 처리** - 집계값은 CPU 기반 기밀 가상머신(CVM)과 신뢰 실행 환경(TEE)에서 처리된다. - 클라이언트는 하드웨어 기반 증명을 확인하고, 허용된 소프트웨어 바이너리인지 제3자 로그와 대조한다. - 데이터는 기기와 TEE 사이에서 암호화된다. - WhatsApp이나 Meta를 포함한 중간 전달자도 처리 중인 데이터를 볼 수 없도록 설계됐다. - **안전한 집계** - 개별 기기의 통계가 직접 노출되지 않도록 여러 기기의 데이터를 결합한다. - 최종적으로 WhatsApp과 Meta에 제공되는 것은 익명화·차등 개인정보보호가 적용된 집계 결과다. ## 모델 배포와 독립 검증 - Meta와 WhatsApp은 특정 사용자에게 특정 모델을 선택적으로 배포할 수 없도록 설계했다. - 실험 모델을 포함한 모든 모델 버전은 배포 전에 공개 투명성 원장에 기록된다. - 모델 가중치도 공개해 보안 연구자들이 모델이 사기 탐지 목적에 맞게 제작됐는지 확인할 수 있도록 한다. - 버그 바운티 프로그램을 확대해 외부 연구자들이 구현을 검증하고 취약점을 찾을 수 있게 했다. - 사용자 역시 앱 내 로그를 통해 기능의 동작을 확인할 수 있도록 했다. ## 실용적인 결론 Scam Alert는 서버에서 메시지를 검사하는 방식이 아니라, 선택형 온디바이스 모델과 사용자 주도 신고를 결합한 접근이다. 개인정보 보호가 중요한 사용자는 기능을 직접 활성화해 사기 경고를 보조 수단으로 활용할 수 있지만, 머신러닝 경고는 확률적 판단이므로 최종적으로는 송금 요구, 긴급성 유도, 신원 사칭 같은 전형적인 사기 신호를 사용자가 함께 확인해야 한다.

원문 읽기(새 탭에서 열림)

differential-privacyend-to-end-encryptionconfidential-computingfederated-analytics+3

meta·2026년 8월 5일·5분 읽기큐레이션 요약

사용자 시퀀스에서 스케일링 법칙까지: Meta 광고 순위를 위한 다단계 아키텍처

Meta는 사용자 행동의 순서와 시간 정보를 활용하는 시퀀스 학습을 광고 추천 시스템에 확장하기 위해 두 가지 구조적 혁신을 제시한다. 첫째, 오프라인 사용자 모델과 온라인 랭킹 모델을 분리해 긴 사용자 이력을 효율적으로 처리하고, 둘째, dense tokenization과 target-aware attention으로 광고와 사용자 행동 간 상호작용을 모델이 직접 학습하도록 했다. 이 플랫폼은 Instagram 전환율 6%, Facebook 전환율 3%, Facebook 광고 클릭률 3.5%의 누적 향상에 기여했으며, Meta의 GEM(Generative Ads Recommendation Model)의 핵심 요소로 활용되고 있다. ## 기존 시퀀스 모델의 한계 - 광고 추천 시스템은 밀리초 단위로 수천 개의 광고를 검색·순위화해야 하며, 초당 수백만 개의 후보를 처리해야 한다. - 기존 방식은 보통 다음과 같은 하이브리드 구조를 사용했다. - 한 모델은 사용자 행동 시퀀스를 처리한다. - 다른 모델은 희소 피처 간 상호작용을 처리한다. - 이 구조는 운영 효율성은 높지만 다음과 같은 문제가 있다. - 두 모델 사이의 지식 전달이 손실될 수 있다. - 희소 피처를 조합하기 위한 수작업 피처 엔지니어링이 계속 필요하다. - 시퀀스 모델과 랭킹 모델의 규모를 동시에 키울 때 서로 간섭해 확장성이 제한된다. - 시퀀스 길이와 Transformer 규모를 키울수록 모델 복잡도와 실시간 추론 비용 사이의 균형을 맞추기 어려워진다. ## 오프라인 사용자 모델과 온라인 랭킹 모델의 분리 - 다단계 시퀀스 모델은 무거운 사용자 모델링과 실시간 광고 순위화를 두 단계로 분리한다. - 오프라인 사용자 모델 - 사용자의 긴 행동 이력을 비동기적으로 처리한다. - 수천 개 수준의 시퀀스 길이와 여러 Transformer 레이어를 사용할 수 있다. - 사용자 행동에서 장기적인 관심사와 패턴을 추출해 사용자 임베딩을 생성한다. - 계산 결과는 사용자 단위로 미리 계산하고 캐시한다. - 광고 후보나 특정 문맥 정보와 분리해, 특정 광고에 종속되지 않는 사용자 표현을 만든다. - 온라인 랭킹 모델 - 캐시된 사용자 임베딩에 최신 사용자 신호와 광고 후보 정보를 결합한다. - 실시간 요청에서 최종 광고 순위를 계산한다. - 엄격한 지연 시간 예산을 만족하도록 가볍고 빠르게 설계된다. - 이 분리를 통해 오프라인 모델의 용량과 복잡도는 크게 늘리면서도 온라인 서빙 비용과 지연 시간의 급증을 피할 수 있다. ## Dense Tokenization으로 희소 피처 통합 - 기존 추천 시스템은 희소 ID 피처 간 상호작용을 표현하기 위해 사람이 직접 조합 피처를 설계하는 경우가 많았다. - Dense tokenization은 희소 피처와 순차적 행동 데이터를 하나의 조밀한 토큰 어휘로 통합한다. - 통합된 토큰 표현을 사용하면 attention 메커니즘이 데이터에서 직접 피처 간 관계를 발견할 수 있다. - 결과적으로 다음과 같은 장점이 있다. - 수작업으로 정의한 교차 피처에 대한 의존도가 낮아진다. - 사용자 행동, 광고 속성, 문맥 정보 사이의 복잡한 관계를 통합적으로 학습할 수 있다. - 시퀀스 모델이 전통적인 희소 피처 모델의 역할까지 흡수할 수 있다. ## Target-Aware Multi-Head Attention - 사용자 행동 시퀀스와 광고 후보 정보를 함께 토큰화한 뒤, 광고별로 사용자 과거 행동의 중요도를 다르게 계산한다. - 각 attention 레이어는 현재 평가 중인 광고를 기준으로 사용자의 과거 행동을 참조한다. - 여러 개의 정렬된 attention 블록을 쌓아 다음을 수행한다. - 광고와 과거 행동 사이의 1차 상호작용을 학습한다. - 이후 레이어에서 더 높은 차원의 상호작용을 포착한다. - 긴 사용자 시퀀스를 광고별로 중요한 정보만 포함한 압축 표현으로 점진적으로 변환한다. - 이 방식은 모든 광고에 동일한 사용자 표현을 사용하는 대신, 각 광고 후보에 맞는 사용자 관심사 표현을 생성한다. ## 예측 가능한 LLM 스타일 확장 법칙 - 실제 광고 트래픽에서 모델 성능은 계산량(FLOPs)이 증가할수록 로그-선형적으로 향상되는 경향을 보였다. - 이는 대규모 언어 모델에서 관찰된 scaling law와 유사하다. - 성능은 다음 요소를 확장할 때 측정됐다. - Transformer 깊이 - 모델 폭 - 사용자 시퀀스 길이 - 콘텐츠·의미 정보의 풍부함 - 기존 Transformer 기반 시퀀스 모델보다 계산량 증가에 따른 확장 효율도 개선됐다. - 광고 추천은 텍스트처럼 조밀한 데이터만 처리하지 않고 희소 ID 피처와 시간 순서 정보를 함께 다루지만, 그럼에도 예측 가능한 확장 법칙이 나타났다는 점이 아키텍처의 적합성을 뒷받침한다. ## 성능 확장을 위한 네 가지 조절 요소 ### 균형 잡힌 모델 구조 - 깊이, 폭, 시퀀스 길이를 균형 있게 확장해야 한다. - 한 축만 키우면 다른 축이 병목이 되어 성능 향상이 둔화될 수 있다. - 이는 모델 확장에서 각 구성 요소 간의 시너지가 필요하다는 “scaling synergy principle”로 설명된다. ### 다단계 모델의 독립적 조정 - 오프라인 사용자 모델과 온라인 랭킹 모델을 서로 독립적으로 확장할 수 있다. - 온라인 모델 확장은 단위 계산량당 더 큰 성능 향상을 가져올 수 있지만, 요청 처리 시간과 서빙 지연 시간에 제한된다. - 오프라인 모델은 비동기 추론이 가능하므로 지연 시간 제약 없이 모델 규모를 점진적으로 키울 수 있다. ### 시퀀스 구성의 다양성 - 더 긴 사용자 행동 시퀀스를 사용할수록 성능이 향상된다. - 단순히 유사한 유형의 행동을 많이 넣는 것보다 다양한 행동 유형을 균형 있게 포함하는 것이 더 효과적이다. - 즉, 시퀀스의 길이뿐 아니라 행동 데이터의 다양성이 사용자 의도와 관심사를 표현하는 데 중요하다. ### 모델·데이터 확장의 결합 - 광고 추천에서는 모델 크기만 키우는 것으로 충분하지 않다. - 희소 피처, 의미 정보, 사용자 행동의 시간적 범위와 다양성을 함께 확장해야 한다. - 다단계 구조는 각 확장 요소가 온라인 비용과 오프라인 비용에 미치는 영향을 분리해 조정할 수 있게 한다. ## 실용적인 결론 대규모 추천 시스템에서는 모든 계산을 실시간으로 수행하기보다, 긴 사용자 이력은 오프라인에서 깊게 모델링하고 실시간 단계에서는 캐시된 표현과 최신 광고 신호를 결합하는 구조가 효과적이다. 또한 수작업 피처 조합을 계속 늘리기보다 dense tokenization과 target-aware attention을 통해 모델이 광고별 사용자 행동 상호작용을 직접 학습하도록 설계하는 것이 확장성과 성능 향상에 유리하다.

원문 읽기(새 탭에서 열림)

transformerrecommendation-systemsscaling-lawsattention-mechanisms+3

meta·2026년 8월 3일·5분 읽기큐레이션 요약

GEM 트레이닝: Meta가 LLM 규모의 광고 파운데이션 모델 효율성을 두 배로 높인 방법

Meta의 GEM은 Instagram과 Facebook 광고 추천을 담당하는 기반 모델로, 최신 GPU 수천 장을 활용해 LLM 규모로 학습된다. Meta는 추천 시스템에 특화된 커널·초저정밀도·병렬화·네트워크·메모리를 함께 설계해 12개월 동안 학습 FLOPs를 4배 늘리면서 E2E 학습 효율을 20~25% MFU까지, 기존 대비 2배 향상했다. 핵심 결론은 LLM용 인프라를 그대로 적용하는 것만으로는 부족하며, 추천 모델의 데이터와 구조에 맞춘 하드웨어·소프트웨어 공동 설계가 필요하다는 것이다. ## GEM의 하이브리드 구조와 추천 데이터의 특성 - GEM은 Meta 광고 시스템의 중앙 추천 파운데이션 모델이다. - 수조 개의 희소 임베딩 파라미터와 수십억 개의 밀집 파라미터를 함께 사용한다. - 입력 데이터는 크게 두 종류다. - **시퀀스 특징**: 사용자의 활동 이력처럼 순서가 있는 데이터 - **비시퀀스 특징**: 사용자 위치, 광고 크리에이티브 표현 등 - 각 특징 그룹에는 별도의 어텐션 메커니즘을 적용하면서도, 서로 다른 특징 간 상호작용을 학습한다. - 이처럼 LLM과 추천 시스템의 구조가 결합되어 있어 일반적인 LLM 학습보다 GPU 활용과 분산 확장이 어렵다. ## 추천 모델에서 높은 GPU 활용률이 어려운 이유 - **가변적인 시퀀스 길이** - 사용자 활동 이력의 길이가 샘플마다 크게 다르다. - 모든 입력을 최대 길이에 맞춰 패딩하면 최대 50%의 연산이 낭비될 수 있다. - **비대칭적인 어텐션 형태** - 긴 활동 이력에 대해 긴 시퀀스와 짧은 어텐션 윈도우를 사용하는 self-attention - 긴 쿼리와 짧은 key/value를 사용하는 사용자-광고 cross-attention - 사용자 이력을 압축해 짧은 쿼리와 긴 key/value를 만드는 PMA - 이런 다양한 행렬 형태는 GPU 내부 파이프라이닝과 연산 유닛 포화를 어렵게 만든다. - **메모리 대역폭 중심 연산** - 작은 임베딩 차원의 MLP와 여러 정규화 연산은 계산량보다 메모리 접근의 영향을 크게 받는다. - 따라서 Tensor Core 등 GPU 연산 자원이 충분히 활용되지 않을 수 있다. - **정밀도 변화에 대한 민감성** - CTR·CVR 예측은 수치 변화에 민감하다. - 단순히 낮은 정밀도를 적용하면 모델 품질이 저하될 수 있어, 연산별로 정밀도를 신중하게 선택해야 한다. ## 수천 개 GPU로 확장할 때의 병목 - GEM의 학습 단계 지연 시간은 다음과 같이 결정된다. `E2E 지연 시간 = 각 GPU rank에서의 max(로컬 연산 시간, 통신 시간)` - 선형에 가까운 확장을 위해서는 다음 조건이 필요하다. - 전체 연산 시간이 통신 시간보다 충분히 커야 한다. - 통신을 연산 뒤에 숨기되 두 작업이 자원을 놓고 경쟁하지 않아야 한다. - 메모리 부족으로 인한 activation recomputation을 최소화해야 한다. - GPU rank 간 부하가 균등해야 한다. - GEM에서는 다음 문제가 이를 방해한다. - 수조 개 희소 파라미터와 수십억 개 밀집 파라미터가 큰 통신량을 만든다. - 레이어별 구조가 달라 연산과 통신을 겹칠 수 있는 시간이 일정하지 않다. - 긴 시퀀스와 큰 activation 때문에 메모리가 부족해 재계산이 발생한다. - 가변 시퀀스 길이로 인해 GPU마다 처리량이 달라지는 부하 불균형과 straggler가 생긴다. ## E2E MFU를 연산 효율과 확장 효율로 분해 - 전체 학습 효율은 다음 두 요소의 곱으로 정의한다. `E2E MFU = Local MFU × Scaling Ratio` - **Local MFU** - 단일 GPU의 연산 유닛을 얼마나 잘 활용하는지를 나타낸다. - 커널 설계, 수치 정밀도, 시퀀스 길이와 데이터 차원이 GPU 구조에 얼마나 잘 맞는지에 좌우된다. - **Scaling Ratio** - 단일 GPU 성능이 수천 개 GPU로 확장된 뒤 얼마나 유지되는지를 의미한다. - 1.0이면 완전한 선형 확장이지만, 실제로는 통신 오버헤드·부하 불균형·straggler·activation 재계산 때문에 낮아진다. - Meta는 레이어를 단일 GPU에서 개별 실행해 Local MFU를 측정하고, 통신과 activation 재계산의 영향을 제외한 기준 성능을 산출했다. - 이후 Local MFU와 E2E MFU의 비율을 통해 Scaling Ratio를 계산해 연산 병목과 분산 시스템 병목을 분리했다. ## GPU 연산 효율을 높인 맞춤형 커널과 정밀도 - 추천 모델의 비정형적인 입력과 어텐션 패턴에 맞춰 자체 추천용 커널 라이브러리를 개발했다. - 주요 커널은 다음과 같다. - **Jagged Flash Attention(JFA)**: 가변 길이 시퀀스를 패딩 낭비 없이 처리 - **Generalized Dot-Product Attention(GDPA)**: 추천 모델의 다양한 어텐션 형태에 대응 - **BlockAttention**: 블록 단위 연산으로 메모리 접근과 GPU 활용을 최적화 - 최신 GPU 아키텍처를 직접 활용하도록 커널을 설계해 추천 워크로드의 낮은 활용률을 개선했다. - 어텐션과 MLP에는 **MXFP8**을 포함한 혼합 초저정밀도 학습을 적용했다. - 모든 연산을 무조건 낮은 정밀도로 처리하지 않고, 광고 예측 품질에 민감한 특성을 고려해 연산별로 정밀도와 안정성을 조정했다. ## 네트워크와 결합한 5차원 병렬화 - 대규모 학습에서는 병렬화 방식 자체뿐 아니라 GPU와 네트워크 토폴로지의 매핑이 중요하다. - GEM은 네트워크 계층 구조를 고려한 **토폴로지 인지형 5D 병렬화**를 적용했다. - 밀집 파라미터에는 다음 조합을 사용했다. - 2D FSDP - Expert Parallelism - 희소 파라미터에는 **Fully Sharded 2D Model Parallelism**을 적용했다. - 통신 집단 연산은 GPU의 Streaming Multiprocessor(SM)를 점유하지 않는 방식으로 설계했다. - 통신이 연산 자원을 직접 빼앗지 않도록 해 연산과 통신의 충돌을 줄인다. - Meta의 다계층 네트워크 구조와 병렬화 전략을 함께 설계해 통신량과 통신 노출 시간을 줄였다. ## 성과와 설계 원칙 - 12개월 동안 총 학습 FLOPs를 4배로 확대했다. - 동시에 E2E 학습 효율을 2배 높여 20~25% MFU를 달성했다. - 성능 개선은 단일 기법이 아니라 다음 요소들의 결합으로 이루어졌다. - 추천 특화 커널 - 혼합 초저정밀도 - 희소·밀집 파라미터별 병렬화 - 네트워크 토폴로지 최적화 - SM 비점유 통신 - 메모리와 부하 균형 관리 추천 모델을 LLM 규모로 확장하려면 LLM 인프라를 그대로 복사하기보다, 가변 길이·희소 임베딩·비대칭 어텐션·정밀도 민감성 같은 도메인 특성을 먼저 분석해야 한다. 특히 단일 GPU의 커널 효율과 수천 GPU의 통신·메모리 효율을 별도의 문제로 측정하고 동시에 최적화하는 접근이 효과적이다.

원문 읽기(새 탭에서 열림)

대규모 언어 모델recommendation-systemsdistributed-traininggpu-optimization+3

meta·2026년 7월 15일·4분 읽기큐레이션 요약

메타 광고 딥 퍼널 최적화를 위한 계층적 관심사 표현 탐구

Hierarchical Interest Representation은 사용자와 광고주·제품·서비스를 하나의 그래프로 연결하고, 이들의 잠재적 관심사를 여러 수준의 임베딩으로 학습하는 Meta Ads의 상위 표현 계층이다. 희소한 광고 참여 신호에 텍스트·이미지·영상 기반의 세계 지식을 결합해, 사용자의 잠재 관심과 광고주의 상품을 연결하고 딥 퍼널 광고 성과를 높이는 것이 목표다. 수십억 건의 상호작용을 이용해 학습한 범용 임베딩과 관심 토큰은 검색, 개인화, 추천, 감독 신호, 랭킹 모델 전반에 활용될 수 있다. ## 딥 퍼널 광고 최적화를 위한 표현 계층 - 사용자가 스크롤, 클릭, 반응, 구매 등으로 표현한 선호를 바탕으로 명시적·암묵적 관심사를 추론한다. - 광고주가 제공하는 상품·서비스와 사용자의 잠재 관심을 연결해, 단순 노출이나 클릭을 넘어 전환 등 딥 퍼널 목표를 최적화한다. - Meta의 Generative Ads Model(GEM), Andromeda, Adaptive Ranking Model 등 광고 추천 생태계의 여러 단계에서 사용할 수 있는 상위 표현 계층을 지향한다. - 대규모 참여 데이터에서 안정적인 관심 앵커를 추출해, 사용자가 아직 직접 반응하지 않은 광고의 발견 가능성도 높인다. ## 광고 생태계를 그래프로 모델링 - 사용자, 광고주, 제품, 서비스, 캠페인 등을 그래프의 노드로 표현한다. - 노드 사이의 노출, 클릭, 참여, 구매 등의 활동과 이벤트는 엣지가 된다. - Meta의 광고 네트워크는 매월 수백만 광고주와 수백만 개 광고가 수십억 명의 사용자에게 제공되는 초대형 그래프다. - 사용자와 특정 광고 사이의 직접적인 딥 퍼널 신호는 희소하기 때문에, 그래프에서 멀리 떨어진 연결과 공통 패턴을 함께 학습해야 한다. ## 희소한 신호와 동적인 관심사 - 사용자는 ‘관심 있음/관심 없음’ 같은 직접 피드백뿐 아니라 광고 참여 행동으로도 관심을 표현한다. - 광고 노출 기회와 전환 피드백은 광고·상품의 전체 규모에 비해 제한적이다. - 개별 사용자와 광고의 연결만 보면 데이터가 부족하므로, 관련 사용자·상품·광고주 사이의 장거리 관계를 활용해야 한다. - 대규모 그래프에서 장거리 관계를 계산하려면 메모리 효율적인 어텐션 커널과 고성능 학습 알고리즘이 필요하다. ## 차원 축소와 관심 원시 단위 - 원시 광고 그래프를 학습된 잠재 관심 단위인 ‘슈퍼 노드’ 중심의 슈퍼 그래프로 변환한다. - 원래는 희소했던 사용자-광고 연결을 공통 관심 원시 단위로 묶어 더 조밀한 관계로 만든다. - 관심 원시 단위의 어휘는 개별 광고보다 안정적이고 정적이므로, 광고 비즈니스와 상품 구성이 바뀌어도 재사용하기 쉽다. - 이를 통해 개별 광고에 대한 충분한 이력이 없는 사용자나 상품에도 일반화할 수 있다. ## 멀티모달 지식 보강 - 광고주와 제품의 페이지 메타데이터, 카탈로그 속성, 텍스트, 이미지, 영상 정보를 활용한다. - 언어 모델과 비전 모델로 콘텐츠를 처리해, 사용자가 해당 상품과 어떻게 상호작용했는지뿐 아니라 상품 자체가 무엇인지도 표현한다. - 참여 데이터가 부족한 희귀하거나 새롭게 등장한 광고주·제품에 대해서도 의미적 유사성을 바탕으로 추론할 수 있다. - 실제 세계의 지식과 행동 기반 신호를 결합해 콜드스타트와 신호 부족 문제를 완화한다. ## 통합 관계 임베딩 - 사용자, 광고주, 제품, 서비스와 잠재 관심 원시 단위를 하나의 거리 기반 공간에 배치한다. - 임베딩 간 거리를 이용해 다음 관계를 추정할 수 있다. - 사용자와 관심 원시 단위의 근접성 - 광고·광고주가 어떤 관심사를 제공하는지 - 관심 원시 단위끼리의 유사성 - 유사한 사용자, 광고, 제품의 이웃 관계 - 서로 다른 유형의 엔터티 간 친화도 - 동일한 표현 공간을 사용하므로 사용자 관심과 광고 상품의 의미적 연결을 직접 계산할 수 있다. ## 여러 계층의 관심 표현 - 상위 계층은 여행·스포츠·패션처럼 안정적이고 넓은 관심사를 표현한다. - 하위 계층은 특정 브랜드, 세부 상품, 구매 의도처럼 희소하지만 정밀한 관심사를 표현한다. - 조밀하고 안정적인 관계는 더 거친 계층으로, 드물고 구체적인 관계는 더 세밀한 계층으로 표현한다. - 여러 계층을 연쇄적으로 학습하면 검색·개인화에는 넓은 관심 표현을, 최종 랭킹에는 구체적인 의도 표현을 선택적으로 사용할 수 있다. ## 트랜스포머 기반 그래프 학습 - LLM에서 영감을 받은 트랜스포머 구조를 대규모 광고 그래프에 적용한다. - 희소 어텐션을 사용해 모든 노드 간 연결을 계산하지 않고도 장거리 그래프 관계를 포착한다. - 편향을 고려한 어텐션과 자기지도 방식의 교차 뷰 지식 증류를 활용해 여러 관점의 그래프 정보를 통합한다. - 사용자 행동의 시간적 변화와 광고주·제품 콘텐츠의 의미 정보를 함께 학습한다. - 전체 시스템은 실제 Meta 광고 데이터의 수십억 건 상호작용으로 엔드투엔드 학습된다. ## 범용 임베딩과 Bag-of-Meaning 토큰 - 광고 생태계의 사용자·광고주·제품·서비스에 대한 범용 임베딩을 생성한다. - 여러 의미 단위로 구성된 ‘Bag-of-Meaning’ 관심 토큰은 사용자의 관심과 광고의 의미를 공통 어휘로 표현한다. - 이 결과는 다음 용도로 확장될 수 있다. - 광고 및 상품 검색·후보 생성 - 개인화 추천 - 랭킹 모델의 입력 특성 - 학습을 위한 감독 신호 - 특정 도메인에 최적화된 전문 랭킹 아키텍처 실용적으로는 직접적인 전환 데이터가 부족한 광고·상품을 다뤄야 하거나, 신규 엔터티와 장기적인 관심 관계를 포착해야 하는 시스템에 특히 유용하다. 다만 범용 임베딩을 실제 광고 순위에 적용할 때는 최신성, 사용자 프라이버시, 관심사 편향, 계층별 표현의 검증을 함께 관리해야 한다.

원문 읽기(새 탭에서 열림)

대규모 언어 모델멀티모달 AItransformerembeddings+4

meta·2026년 7월 13일·4분 읽기큐레이션 요약

오픈 소스 커널 스케줄러를 활용한 Meta 광고 서비스 현대화

Meta는 광고 서버의 워크로드 특성을 반영한 `sched_ext` 기반 커스텀 스케줄러를 도입해 광고 검색 경로의 p99 지연을 28% 줄이고, 전력 3.28MW를 절감했으며, 순위 매긴 광고 수를 1.1% 늘렸다. 일반 목적 스케줄러 대신 요청의 중요도와 실행 경로를 이해하는 스케줄링 정책을 적용한 결과다. 이후 사용자 공간 BPF 정책만 수정해 p99 지연을 추가로 60% 줄이고 타임아웃 오류도 18% 감소시켰다. ## 광고 서비스에서 지연 시간이 중요한 이유 - Meta의 광고 플랫폼은 초당 평균 500만 건 이상의 요청을 처리하며, 하루 기준 4,000억 건이 넘는다. - p99 지연 시간이 몇 밀리초만 늘어나도 광고의 관련성과 광고주 ROI가 악화될 수 있다. - 기존 Linux 스케줄러인 CFS와 EEVDF는 범용 목적이라 각 스레드의 업무 중요도나 광고 요청 처리 경로를 알지 못한다. - 광고 서비스에서는 어떤 스레드가 사용자 요청의 핵심 경로에 있는지 알고 있으므로, 이를 스케줄러에 직접 반영할 여지가 있었다. ## EEVDF 전환으로 발생한 문제 - Linux 6.6부터 도입된 EEVDF가 최신 커널 6.9에서 광고 서버의 지연 시간을 악화시켰다. - 그 결과 응답에서 검색·순위 지정되는 광고 수가 줄어들었다. - 일부 광고 서버는 성능 회귀를 피하기 위해 Linux 6.4와 CFS에 계속 남아야 했고, 커널 버전이 혼재하는 운영 부담과 기술 부채가 발생했다. - 이미 Meta 내 여러 서비스에서 성능 개선 효과를 보인 `sched_ext`가 이 문제의 해결책으로 선택됐다. ## BPF 기반 `sched_ext`의 구조 - `sched_ext`는 BPF 프로그램으로 스케줄링 정책을 구현할 수 있는 Linux의 확장 가능한 프레임워크다. - Linux 6.12에 공식적으로 포함됐으며, Google의 ghOSt 설계 경험을 바탕으로 업스트림 통합을 고려해 개발됐다. - 커널은 다음과 같은 이벤트가 발생할 때 BPF 스케줄러를 호출한다. - 스레드가 실행 가능 상태가 될 때 CPU 선택 - 실행 큐에 스레드를 넣을 때 - CPU가 유휴 상태가 되어 다음 스레드를 선택할 때 - CPU가 유휴 상태에 진입하거나 빠져나올 때 - 광고 워크로드가 실행되는 호스트에만 광고 최적화 정책을 적용할 수 있다. ## 광고 요청에 맞춘 CPU 분할과 지역성 개선 - CPU를 두 개의 논리적 풀로 나눈다. - 지연 시간에 민감한 광고 요청 처리 스레드용 - 상대적으로 덜 중요한 백그라운드·비핵심 작업용 - 어떤 스레드를 어느 풀에 배치할지는 광고 도메인 지식에 따라 결정한다. - 부하 기반 휴리스틱으로 각 CPU 풀의 크기를 동적으로 조절한다. - 관련 작업을 장기간 같은 CPU에 배치해 L3 캐시 지역성을 높이고 DRAM 접근 비용을 줄인다. - 정책은 사용자 공간 바이너리가 BPF 프로그램을 로드하는 형태로 배포된다. - 정책을 변경할 때 커널을 다시 빌드하거나 설치할 필요 없이 스케줄러 프로세스를 재시작하면 되므로 실험과 배포가 빠르다. ## 성능과 운영 효과 Linux 6.4의 CFS에서 Linux 6.9와 `sched_ext`로 전환한 초기 도입 결과는 다음과 같다. - 광고 검색 경로의 서비스 p99 지연 28% 감소 - 전체 서버 플릿에서 전력 3.28MW 절감 - 가중 광고 순위 지표 1.1% 증가 - 사용자 공간 정책을 두 차례 추가 개선한 뒤: - 서비스 p99 지연이 추가로 60% 감소 - 핵심 경로의 타임아웃 오류 18% 감소 커널 변경이 필요하지 않았기 때문에 후속 개선은 수개월이 아닌 며칠 단위로 배포할 수 있었다. ## 장기적인 전략 자산으로의 확장 - 업스트림 Linux 스케줄러의 변화와 별개로, Meta가 자체 워크로드에 맞는 정책을 병렬적으로 개선할 수 있다. - 커널 패치와 장기간의 검증이 필요했던 기능도 사용자 공간 BPF 업데이트로 빠르게 실험할 수 있다. - 예시로 로컬 캐시 인식 배치, ROI 기반 실행기 라우팅, NUMA 인식 CPU 선택 등을 적용할 수 있다. - `sched_ext`가 Linux에 업스트림되면서 클라우드 사업자, 대규모 서비스 운영자, 임베디드 시스템 등도 커널을 포크하지 않고 특화된 스케줄링 정책을 구현할 수 있게 됐다. ## 향후 방향 - 광고 서비스가 요청의 상대적 중요도 같은 애플리케이션 수준의 정보를 스케줄러에 전달할 수 있다. - 스케줄러는 중요 요청을 처리하는 스레드에 더 긴 실행 시간을 주거나, 실행 큐의 최상단에 유지하는 방식으로 대응할 수 있다. - 이를 통해 단순한 CPU 부하 균형을 넘어, 비즈니스 가치와 요청 우선순위를 반영한 스케줄링이 가능해진다. 워크로드별 우선순위와 실행 특성을 명확히 알고 있는 대규모 서비스라면, 범용 스케줄러만 고집하기보다 `sched_ext` 같은 확장 프레임워크로 지연 시간·전력·처리량을 함께 최적화하는 방안을 검토할 만하다.

원문 읽기(새 탭에서 열림)

Linuxebpflinux-kernelnuma+4

meta·2026년 7월 1일·5분 읽기큐레이션 요약

메타의 대규모 AI 스토리지 청사진

AI 혁신의 속도와 규모가 커질수록 스토리지는 GPU 활용률과 연구 생산성을 좌우하는 핵심 인프라가 된다. Meta는 기존 BLOB 스토리지의 긴 메타데이터 경로와 글로벌 복제 중심 설계가 AI의 낮고 예측 가능한 지연시간 요구를 충족하지 못한다고 판단했다. 이에 통합 메타데이터, 데이터 프록시 제거, GPU 인접 리전 배포를 중심으로 아키텍처를 재구축해 GPU 유휴 시간을 줄이고 데이터 처리 속도를 높이려 했다. ## AI 워크로드에서 스토리지가 중요한 이유 - AI 모델과 학습 데이터셋의 규모가 빠르게 증가하고, 프런티어 모델 출시 주기도 수개월에서 수주로 단축되고 있다. - GPU 성능은 약 2년마다 세 배 수준으로 향상된 반면, 스토리지와 네트워크 성능 향상은 상대적으로 느렸다. - 스토리지 병목은 다음과 같은 문제를 일으킨다. - GPU가 데이터를 기다리며 유휴 상태가 됨 - 학습 시간과 인프라 비용이 증가함 - 여러 리전에 분산된 GPU로 데이터를 이동·적재하는 데 시간이 걸림 - 연구자가 실험을 반복하는 속도가 느려짐 - Meta는 이러한 문제를 해결하기 위해 BLOB 스토리지를 두 가지 목표에 맞춰 발전시켰다. - GPU 활용률 최대화 - AI 연구 반복 속도, 즉 연구 생산성 최대화 ## Meta의 기존 스토리지 계층 - Meta의 스토리지 서비스는 Facebook, Instagram, Reality Labs, Meta AI, 광고, 데이터 웨어하우스 등 다양한 서비스에 사용된다. - 기반 계층인 **Tectonic**은 수평 확장 가능한 블록 스토리지 패브릭이다. - 소거 코드(erasure coding)를 이용해 높은 내구성과 가용성을 제공한다. - HDD와 플래시 등 여러 미디어 계층을 지원한다. - 핫·웜·콜드 데이터를 적절히 배치해 테넌트 간 I/O 효율을 관리한다. - 그 위의 BLOB 스토리지는 전역적으로 확장 가능한 저장소 인터페이스를 제공하며, 내구성과 가용성 사이의 정책적 선택을 지원한다. - 과거에는 Tectonic 위에 NFS와 유사한 파일 시스템 인터페이스를 제공해 Llama 학습을 수행했지만, 최근 학습 스택은 대규모 데이터 레이크에 대한 통합 접근성과 고성능을 위해 BLOB 인터페이스로 점진적으로 이동하고 있다. ## GPU 학습에서 지연시간이 중요한 이유 - 수십만 개의 GPU가 대규모 데이터셋을 여러 에폭에 걸쳐 반복 처리한다. - 각 GPU 호스트의 데이터로더는 GPU가 현재 배치를 처리하는 동안 다음 배치를 미리 읽어 계산과 I/O를 겹친다. - 대부분의 요청이 빠르더라도 일부 요청의 지연시간이 크게 튀면 GPU가 데이터를 기다리며 멈출 수 있다. - 일정한 학습 스텝마다 GPU들이 상태를 동기화하므로, 단 하나의 느린 GPU도 전체 학습 스텝과 클러스터의 진행을 지연시킨다. - 따라서 평균 지연시간보다 **pMax와 같은 최악 구간의 지연시간을 낮고 예측 가능하게 유지하는 것**이 중요하다. ## 기존 BLOB 아키텍처의 한계 - 기존 BLOB 스토리지는 여러 서비스 계층을 덧붙이는 방식으로 발전했으며, 각 계층이 별도의 상태와 메타데이터 저장소를 보유했다. - `getObject("/bucket/path")` 요청은 다음과 같은 여러 계층을 거쳐야 했다. - API 서버가 요청 수신 - namelayer, volumeslayer, containerlayer 등에서 메타데이터 조회 - 경로를 `(blockId, offset, size)` 목록으로 변환 - Tectonic에서 데이터를 가져온 뒤 API 서버가 클라이언트로 프록시 - 메타데이터 조회가 여러 리전을 넘나들 수 있고, 어느 한 단계라도 느리면 전체 지연시간이 증가했다. - 전통적인 HDD 기반 워크로드에서는 수백 밀리초의 메타데이터 지연이 큰 문제가 아니었지만, 플래시 기반 AI 스토리지에서는 데이터 접근 자체가 밀리초 단위이므로 메타데이터 조회가 주요 병목이 되었다. ## AI 시대에 달라진 설계 요구사항 - **성능과 지연시간** - 기존 서비스는 평균적인 성능이면 충분했지만, AI는 높은 처리량과 pMax까지 예측 가능한 지연시간을 요구한다. - **가용성과 내구성** - 기존에는 리전 장애에도 대응하기 위해 데이터와 메타데이터를 기본적으로 전역 복제했다. - AI는 높은 가용성을 원하지만, 모든 데이터를 전역 복제하는 설계가 항상 필요한 것은 아니다. - **비용 효율** - 기존 스택은 HDD의 바이트당 비용을 최소화하는 데 최적화됐다. - AI는 높은 IOPS 때문에 플래시가 필요하며, 스토리지 계산 비용보다 GPU 계산 비용이 훨씬 커졌다. - **전력 효율** - AI 데이터센터는 공간보다 전력 제약이 커지고 있다. - 스토리지에 사용하는 전력은 GPU에 사용할 수 없는 전력이므로, 프록시와 불필요한 계층을 줄여야 한다. ## 통합 메타데이터와 직접 데이터 스트리밍 Meta는 AI 워크로드에 맞춰 스토리지 기반을 다시 설계했다. - **통합 메타데이터 스키마** - 여러 계층에 분산돼 있던 메타데이터를 하나의 평탄한 스키마로 통합했다. - ZippyDB를 기반으로 경로와 실제 저장 위치의 매핑을 관리한다. - 청크 단위로 경로를 저장 주소로 변환하는 조회를 O(1)에 가깝게 수행할 수 있게 됐다. - **데이터 플레인 프록시 제거** - API 서버가 데이터를 중계하지 않고, 클라이언트 SDK가 스토리지 서버에서 직접 바이트를 스트리밍하도록 변경했다. - 불필요한 데이터 복사와 네트워크 홉을 줄였다. - 전력 사용량을 줄이면서 처리량을 높이고 지연시간을 낮출 수 있다. - **팻 클라이언트 SDK** - SDK에 Tectonic `BlockClient`를 내장했다. - 클라이언트는 먼저 `getReadPlan("/bucket/path")`을 호출해 읽기 계획을 얻는다. - API 서버는 메타데이터를 조회해 `(blockId, offset, size)` 정보를 반환한다. - 이후 SDK가 Tectonic 블록에서 데이터를 직접 읽는다. - **리전 단위 배포** - BLOB 스택을 전역 서비스로만 운영하지 않고, GPU가 위치한 각 AI 리전에 함께 배치한다. - 데이터와 GPU의 물리적 거리를 줄여 리전 간 데이터 이동과 지연시간을 줄인다. - 이 구조는 Tectonic 위에 추가되는 오버헤드를 사실상 제거하고, 데이터 프록시를 없애 전력 예산도 준수하도록 설계됐다. ## 실용적인 결론 AI 학습용 스토리지는 단순히 저장 용량이나 평균 처리량을 늘리는 것만으로 충분하지 않다. 메타데이터 경로를 단순화하고, 데이터 프록시를 제거하며, GPU와 가까운 곳에 스토리지를 배치하고, 최악 지연시간을 관리해야 한다. 특히 플래시 기반 AI 환경에서는 전통적인 글로벌 복제·다계층·중앙 프록시 구조보다 워크로드에 맞춘 지역성, 직접 스트리밍, 예측 가능한 지연시간이 더 중요한 설계 기준이 된다.

원문 읽기(새 탭에서 열림)

ai-trainingobject-storagedistributed-storageerasure-coding+3

meta·2026년 6월 30일·3분 읽기큐레이션 요약

메타의 10년간 파이썬 지원 commitment

Meta는 Python Software Foundation(PSF) 후원을 10년째 이어가며, Python과 오픈소스 생태계의 지속 가능성이 자사 기술 스택의 장기적 안정성과 직결된다고 강조합니다. Python은 Meta의 가장 widely used 언어로, 제품 백엔드·AI 연구·인프라·개발 도구 전반에 활용됩니다. Meta는 PSF 후원을 통해 Python 핵심 개발, PyPI 보안, 교육 및 커뮤니티 행사를 지원하고 다른 기업과 개인의 참여도 촉구합니다. ## Meta에서 Python이 중요한 이유 - Python은 Meta에서 가장 많이 사용되는 프로그래밍 언어입니다. - Instagram과 Threads를 비롯한 제품의 백엔드, 인프라, AI 연구 등 다양한 영역에서 활용됩니다. - Meta 엔지니어들이 Python 핵심 유지보수와 Python Enhancement Proposal(PEP) 작성에 참여하고 있습니다. - Meta에서 시작된 머신러닝 프레임워크 PyTorch는 오픈소스 커뮤니티와 함께 개발된 뒤 독립 재단으로 분리되었습니다. - 빠른 타입 체커이자 언어 서버인 **Pyrefly** 등 Python 개발 생산성과 성능 향상을 위한 오픈소스 도구도 개발하고 있습니다. - AI 투자, 데이터 기반 제품 확장, 대규모 인프라 운영에서 Python의 역할이 계속 커질 것으로 보고 있습니다. ## PSF 후원이 필요한 이유 - 오픈소스를 사용하는 기업은 언어와 생태계의 보안성·건강성·혁신을 유지할 공동 책임이 있습니다. - Python으로 제품을 출시하고 모델을 학습시키는 과정은 개발자 커뮤니티와 PSF의 조직적 지원에 기반합니다. - Meta는 PSF 후원을 자사 기술 스택의 장기적인 안정성을 위한 전략적 투자로 봅니다. - 특정 기업의 필요를 넘어, 전 세계 개발자가 사용하는 공통 기반을 유지하는 데 기여한다는 의미가 있습니다. ## 개발자 상주 프로그램과 핵심 기술 지원 - PSF 후원금은 Python과 생태계 개선에 전념하는 정규 개발자를 고용하는 **Developer-in-Residence** 프로그램에 사용됩니다. - 이 프로그램은 자원봉사자에게만 의존하기 어려운 핵심 작업을 지속적으로 수행할 수 있게 합니다. - Python 패키지 저장소인 **PyPI**의 보안 강화에도 자금이 투입됩니다. - PyPI 보안 개선은 개발자가 패키지를 안전하게 게시하고 설치하도록 지원하며, Meta 내부 개발자에게도 직접적인 이점이 있습니다. ## 교육과 커뮤니티 생태계 지원 - Meta는 PyCon US와 같은 주요 Python 행사를 지원합니다. - 무료 또는 할인 입장권, 워크숍 및 서밋, 커뮤니티 모금 활동 등을 후원합니다. - PyLadies와 같은 그룹에 대한 지원은 다양한 배경의 인재가 Python 커뮤니티에 참여하도록 돕습니다. - 기술 인프라뿐 아니라 교육과 커뮤니티 성장이 Python의 장기적인 지속 가능성에 필수적이라고 설명합니다. ## PSF에 참여하는 방법 - **일회성 기부:** 원하는 금액을 한 번 기부할 수 있습니다. - **PSF 회원 가입:** 후원 수준에 따라 PSF의 방향에 관한 논의와 투표에 참여할 수 있으며, 금전 대신 시간으로 기여하는 방식도 있습니다. - **조직 후원:** 기업은 연간 후원 등급을 선택해 지속적으로 지원할 수 있습니다. - 조직 후원자는 PSF 웹사이트, 연례 보고서, 주요 행사에서 기업명과 로고를 공개할 수 있습니다. - 높은 등급의 후원자는 더 큰 브랜드 노출, 커뮤니티 행사 참여, 발표 및 특별 프로그램 참여 기회를 얻을 수 있습니다. 기업은 자사 제품과 인프라가 의존하는 오픈소스 프로젝트를 단순히 소비하는 데 그치지 말고, 재정 지원·개발 참여·커뮤니티 후원으로 생태계에 환원하는 것이 좋습니다. 개인 개발자 역시 기부, 회원 가입, 행사 참여와 같은 작은 방식으로 Python의 지속 가능성에 기여할 수 있습니다.

원문 읽기(새 탭에서 열림)

AI머신러닝오픈 소스Python+3

meta·2026년 6월 25일·5분 읽기큐레이션 요약

AI 네이티브 시대의 프라이버시 인식 인프라: 자산 분류 사례 연구

프라이버시 통제는 데이터의 정체와 사용 맥락을 정확히 이해해야 제대로 작동하며, 이를 위한 자산 분류가 모든 보존·접근·목적 제한·공유·익명화 정책의 기반이 된다. Meta는 LLM을 모든 운영 판단에 사용하는 대신, 풍부한 맥락과 인간 검토를 바탕으로 모호하거나 새로운 자산을 해석하게 하고, 검증된 패턴은 버전 관리되는 결정론적 규칙으로 전환하는 하이브리드 방식을 제안한다. 그 결과 일상적인 운영 집행은 빠르고 재현 가능하며 감사하기 쉬운 규칙이 담당하고, LLM은 점차 예외적인 경우에만 사용된다. ## 프라이버시 인프라에서 자산 분류가 중요한 이유 - 프라이버시 인식 인프라(PAI)는 다음 네 가지 운영 문제를 다룬다. - 어떤 데이터가 존재하고 어떻게 관리되는지 파악 - 특정 정책과 관련된 데이터 흐름 탐색 - 보존 기간, 접근 권한, 허용 목적, downstream 공유 제한 집행 - 검증 가능한 증거를 통한 컴플라이언스 입증 - 자산 분류는 이 중 ‘데이터 이해’ 계층에 해당하며, 이후 모든 통제의 기반이 된다. - 분류 대상은 테이블과 컬럼에 한정되지 않는다. - 중첩 페이로드의 필드 - 로그 키와 이벤트 파라미터 - API 필드 - ML 피처와 임베딩 - 중간 파이프라인에서 생성된 파생 데이터셋 - 같은 데이터가 파이프라인을 거치며 피처, 모델 학습 데이터, 결합된 파생 신호 등 여러 표현으로 바뀌므로, 분류는 데이터의 형태보다 의미와 계보(lineage)를 따라야 한다. ## 데이터 분류가 어려운 네 가지 이유 - **노이즈가 많고 신호가 약하다** - 자산마다 수십 개의 맥락 필드를 제공하면 모델이 매번 중요한 정보를 다시 찾아야 한다. - 불필요한 필드가 토큰과 주의를 소모해 실제 결정 경계를 흐린다. - 예를 들어 `age`는 개인정보 맥락에서는 사람의 나이지만, 인프라 파이프라인에서는 캐시 TTL일 수 있다. - 코드 해석과 lineage 분석이 없으면 캐시 파이프라인 전체에 불필요한 제한이 적용되는 false positive가 발생한다. - **관련 정보가 여러 시스템에 흩어져 있다** - 코드, 데이터 계보, 소유자, 의미론적 주석, 문서, 실제 사용 패턴을 함께 확인해야 한다. - **요구사항과 정책 해석이 계속 변한다** - 제품 기능이 빠르게 바뀌면 정적 규칙이나 주기적 수동 검토만으로는 정책 공백이 생긴다. - **분류 오류가 downstream 전체에 전파된다** - false positive는 불필요한 제한을 유발한다. - false negative는 보호되지 않은 데이터가 남는 문제를 만든다. - 따라서 모호성을 다루는 추론 능력과 설명·재현 가능한 집행 방식이 모두 필요하다. ## LLM과 결정론적 규칙의 역할 분담 - LLM은 다음 상황에 제한적으로 사용한다. - 기존 규칙으로 처리하기 어려운 모호한 자산 - 초기 데이터가 부족한 cold start 상황 - 이전에 보지 못한 새로운 패턴 - 검증된 패턴은 버전이 있는 결정론적 규칙으로 변환한다. - 낮은 지연 시간 - 동일 입력에 대한 재현성 - 실행 결과의 감사 가능성 - 대규모 운영에 적합한 비용과 성능 - 일반적인 운영 판단은 LLM이 아니라 규칙이 담당한다. - 인간은 다음 단계에 관여한다. - 기준 라벨(reference label) 판정 - 보호 정책에 영향을 주는 규칙 승격 검토 및 승인 - 장기적으로는 LLM이 담당하는 운영 범위를 줄이고, 규칙이 처리하는 안정적인 영역을 넓히는 것이 목표다. ## 원칙 1: 프롬프트보다 맥락이 중요하다 - 분류 실패의 주요 원인은 지시문이 약해서가 아니라 모델에 제공된 증거가 부족하거나 정리되지 않았기 때문이다. - 원시 필드를 그대로 전달하면 중요한 정보와 오해를 일으키는 정보가 섞인다. - 대신 다음 요소를 포함한 **evidence brief**를 구성한다. - 판단을 지지하는 신호 - 판단과 모순되는 신호 - 각 정보의 출처(provenance) - 모델이 이미 알고 있는 정보와 중복되는 순환 필드의 마스킹 - 프롬프트를 계속 최적화하는 것보다, 코드·계보·소유권·문서 등 관련 증거를 선별하고 구조화하는 편이 정확도 향상에 더 효과적이다. - 즉, 모델에 무엇을 어떻게 묻는지보다 먼저 무엇을 보여줄지를 설계해야 한다. ## 원칙 2: 평가와 최적화를 분리한다 - LLM의 결과는 추천이며, 그 자체가 정답 데이터가 되어서는 안 된다. - 평가 체계는 분류기와 독립적으로 유지해야 한다. - 서로 다른 모델과 프롬프트 전략 - 고정된 reference set - 사람이 검토한 라벨 - 회귀(regression) 통과 기준 - 분류 결과를 다시 평가 기준으로 사용하면 실제 개선이 아니라 모델의 드리프트를 측정할 위험이 있다. - 인간 검토 라벨은 모델 출력과 분리된 신뢰 가능한 기준점으로 사용해야 한다. ## 원칙 3: 안정적인 동작을 규칙으로 증류한다 - 반복적으로 검증된 분류 패턴은 사람이 검토한 뒤 결정론적 규칙으로 만든다. - 규칙에는 버전, 적용 조건, 판단 근거를 남겨야 한다. - 규칙 기반 집행은 LLM 추론보다 빠르고, 결과를 재생(replay)할 수 있으며, 감사와 디버깅이 쉽다. - LLM은 새로운 패턴을 발견하는 학습 장치로 활용하고, 안정화된 지식은 규칙에 축적한다. ## 플랫폼 서비스로서의 분류 계약 분류기는 개별 모델 호출이 아니라 안정적인 플랫폼 서비스처럼 설계해야 한다. - 입력 - 자산 식별자 - 정리된 맥락 정보 묶음 - 출력 - 분류기 taxonomy상의 카테고리 - 모델의 원시 confidence score - 판단에 영향을 준 증거를 보여주는 decision trace - 결정론적 규칙으로 판단했다면 매칭된 규칙 - 사용된 맥락, 규칙, 프롬프트의 버전 정보 - confidence는 모델의 자기평가일 뿐이므로, 사람이 검토한 라벨과 비교해 실제 보정 상태를 평가해야 한다. - 모든 분류기를 하나의 보편적 taxonomy로 통합하지 않고, 각 분류기가 하나의 범위가 좁은 질문을 담당하도록 한다. - 예: 사용자 데이터인지 운영 데이터인지 분류 - 예: 특정 AI 학습 용도에 적합한 자산인지 분류 - 좁은 범위의 분류기는 평가·디버깅·거버넌스가 쉽고, 여러 분류기의 결과를 downstream에서 조합할 수 있다. 실무적으로는 LLM을 최종 집행 엔진으로 삼기보다, 사람이 검토한 라벨과 충분한 맥락을 이용해 새로운 패턴을 발견하는 보조 계층으로 두는 것이 바람직하다. 이후 안정화된 판단은 버전 관리되는 규칙으로 승격해 운영하고, 모든 결과에 증거·버전·추적 정보를 남겨 재현성과 감사 가능성을 확보해야 한다.

원문 읽기(새 탭에서 열림)

대규모 언어 모델data-governancehuman-in-the-loopdata-lineage+3

meta·2026년 6월 23일·3분 읽기큐레이션 요약

메타는 AI 안경용 초슬림 배터리를 어떻게 설계했나

스마트 안경은 카메라, 스피커, AI, 디스플레이를 구동해야 하지만 배터리는 성인 새끼손가락보다 좁은 관자놀이 부분에 들어가야 한다. Meta는 기존 파우치형 배터리 대신 7mm 폭까지 줄인 초박형 스틸 캔 셀을 개발해 공간 활용도와 순간 출력 성능을 높였다. 세대별 배터리 용량 증가뿐 아니라 전력 관리, 펌웨어, 하드웨어 구조 개선을 함께 적용해 사용 시간을 크게 늘렸다는 것이 글의 결론이다. ## 스마트 안경에서 기존 배터리가 부족한 이유 - 스마트폰·노트북에 널리 쓰이는 파우치 셀은 형태를 자유롭게 줄이거나 변형하기 어렵다. - 내부 접힘 구조와 제조 공차가 좁은 공간을 차지해, 안경 다리처럼 폭이 제한된 부품에는 불리하다. - 셀 크기가 작아지면 카메라 촬영과 AI 작업을 동시에 수행할 때 필요한 순간적인 고출력을 안정적으로 제공하기 어렵다. - 따라서 배터리가 제품 형태에 맞춰 정확하고 견고하게 제작되어야 하며, 빈틈 없이 공간을 활용해야 한다. ## 7mm 폭의 스틸 캔 셀 개발 - 스틸 캔 배터리는 전동 공구나 시계 등에 사용되던 방식이지만, Meta는 기존에 없던 7mm 수준의 폭으로 축소했다. - 이를 위해 배터리 내부 부품의 구조와 제조 방식 대부분을 다시 설계했다. - 금속 캔은 형태를 일정하게 유지하므로 좁은 공간에서도 파우치 셀보다 정밀하게 배치할 수 있다. - 약 10mm 폭의 셀에서 형상 오차를 약 100마이크로미터 수준으로 관리하면, 회수한 공간이 추가 에너지 용량과 사용 시간으로 이어진다. ## 적층 전극으로 낮춘 임피던스 - 기존 스틸 캔 셀은 전극을 말아 만든 ‘젤리 롤’ 구조를 사용한다. - Meta는 전극을 정밀하게 절단해 여러 층으로 쌓는 구조를 적용했다. - 이는 작은 저항들을 병렬로 연결하는 것과 비슷한 효과를 내며, 배터리 임피던스를 크게 낮춘다. - 임피던스가 낮으면 카메라 녹화와 AI 처리처럼 전력 수요가 동시에 커질 때 전압이 급격히 떨어지는 브라운아웃을 줄일 수 있다. ## 세대별 용량 증가와 시스템 효율 - 1세대 Meta Ray-Ban의 배터리 용량은 160mAh였지만 2세대에서는 210mAh로 약 30% 증가했다. - 그러나 제품이 주장한 사용 시간은 약 2배로 늘었고, 이는 배터리 화학 조성의 변화만으로 설명되지 않는다. - 주요 개선 요소는 다음과 같다. - 전력 관리 최적화 - 펌웨어 제어 정밀화 - 더 큰 셀을 넣을 수 있는 제품 구조 - 하드웨어와 소프트웨어 전반의 에너지 효율 개선 ## 양쪽 관자놀이에 배터리를 넣은 Oakley Meta Vanguards - Oakley Meta Vanguards는 양쪽 관자놀이에 각각 배터리를 배치했다. - 두 셀은 대칭적으로 설계됐지만 실제 전자 부하가 좌우에 균등하게 분배되지는 않는다. - 이 때문에 한쪽 배터리가 다른 쪽으로 과도하게 충전되는 교차 충전 위험이 발생할 수 있다. - 부팅과 종료 과정에서도 두 배터리의 충전·방전 순서를 조정해야 하므로 전기, 펌웨어, 기계 설계가 함께 해결해야 하는 문제가 됐다. ## 디스플레이 탑재에 따른 새로운 전력 요구 - Meta Ray-Ban Display 안경은 화면이 추가되면서 가장 demanding한 전력 프로파일을 요구했다. - 카메라나 AI 작업처럼 순간적으로 전력을 많이 쓰는 기능과 달리, 디스플레이는 지속적으로 전력을 소비한다. - 이에 따라 Meta 제품군 중 가장 큰 248mAh 스틸 캔 셀이 설계됐다. - 이는 배터리 용량뿐 아니라 지속 출력 능력과 열·공간 제약까지 함께 고려해야 했음을 의미한다. ## 다른 웨어러블로의 확장 - 초박형 스틸 캔 기술은 스마트 안경 외에도 다양한 Meta 하드웨어 폼팩터에 적용될 가능성이 있다. - Meta는 여러 제조업체가 이 기술을 사용할 수 있도록 생산 규모를 키우고 공급망을 확대하려 한다. - 배터리 개발은 셀 자체의 화학 기술만으로 끝나지 않으며, 제품 설계·전력 관리 소프트웨어·제조 정밀도·규제 준수까지 통합적으로 다뤄야 한다. 작은 웨어러블의 배터리 성능을 높이려면 단순히 더 큰 배터리를 넣는 방식보다, 셀 구조를 제품에 맞게 재설계하고 전력 관리 소프트웨어까지 함께 최적화하는 접근이 효과적이다.

원문 읽기(새 탭에서 열림)

wearablessmart-glassesbattery-technologysteel-can-cells+3

meta·2026년 6월 22일·3분 읽기큐레이션 요약

대규모 실시간 통신(RTC)을 위한 AV1 도입

Meta는 실시간 통신(RTC)에서 AV1을 도입해 H.264/AVC보다 낮은 비트레이트로 비슷하거나 더 나은 화질을 제공하고, 저대역폭 환경의 통화 품질을 개선했다. 그러나 300ms 이하의 지연 시간, 네트워크 변화와 패킷 손실, 모바일 기기의 전력·메모리 제약 때문에 VOD보다 훨씬 복잡한 문제가 발생했다. Meta는 저복잡도 인코더와 기기별 프리셋, 효율적인 디코더를 적용해 2023년 고급 기기 중심이던 AV1 지원을 대부분의 모바일 기기로 확대했다. ## AV1을 RTC에 도입한 이유 - 동일한 화질을 유지하면서 H.264/AVC보다 훨씬 낮은 비트레이트를 사용할 수 있다. - Meta의 오프라인 테스트에서 제품 설정 기준 AV1은 저가·중급 기기에서 H.264/AVC보다 최소 20% 낮은 비트레이트를 기록했다. - RTC 영상 통화의 비트레이트는 실제 환경에서 약 10~400kbps까지 크게 변하며, 특히 100kbps 이하에서 화질을 유지하기 어렵다. - 100kbps로 비교했을 때 H.264/AVC 영상은 흐릿했지만 AV1 영상은 더 선명하게 유지됐다. - 화면 공유나 컴퓨터 생성 콘텐츠에도 유리하다. - **Palette mode**: 화면에 반복적으로 등장하는 제한된 색상 집합을 효율적으로 표현한다. - **Intra-block copy**: 같은 프레임 안의 반복 패턴을 참조해 텍스트와 고주파 화면 콘텐츠를 더 잘 압축한다. ## RTC 환경에서의 도입 난제 - RTC는 대화 지연을 줄이기 위해 종단 간 지연 시간을 이상적으로 300ms 이하로 유지해야 한다. - 화질 개선 기법과 낮은 지연 시간 사이에 trade-off가 존재한다. - 다중 패스 인코딩은 화질을 높이지만 추가 지연을 만든다. - 디코더의 큰 버퍼는 지연 시간을 증가시킨다. - 갑작스러운 비트레이트 상승은 영상 멈춤을 유발할 수 있다. - 네트워크 대역폭 변화에 따라 해상도와 프레임 레이트를 동적으로 조정해야 한다. - 해상도 변경에는 보통 새 키 프레임이 필요해 순간적인 비트레이트 급증과 프리징이 발생할 수 있다. - 패킷 손실 역시 재전송이나 추가 키 프레임을 유발해 영상 정지를 일으킨다. - 모바일 클라이언트는 실시간 인코딩과 디코딩을 동시에 수행하므로 전력 효율도 중요한 요소다. ## 인코더 선택과 모바일 제약 - AV1은 고급 코딩 도구 덕분에 압축 효율이 높지만, 특히 인코딩 계산량이 크다. - 오픈소스 AV1 인코더를 Pixel 8에서 테스트한 결과 H.264/AVC보다 전력 사용량이 14% 증가했다. - AV1은 H.264/AVC보다 메모리 사용량도 많아 모바일 앱의 크래시 증가로 이어졌다. - 따라서 단순히 압축 효율이 높은 인코더가 아니라, 화질·복잡도·전력 소비를 함께 조절할 수 있는 인코더가 필요했다. ## 저복잡도 AV1 인코더 - 최신 코덱이 반드시 높은 복잡도의 인코더를 요구하는 것은 아니다. - 다양한 코딩 도구를 활용하면 여러 수준의 품질과 계산량을 프리셋으로 제공할 수 있다. - Meta는 고복잡도 프리셋을 최적화하는 동시에 H.264/AVC와 비슷한 계산량을 갖는 **초저복잡도 프리셋**을 개발했다. - 기기 성능에 따라 인코더 프리셋을 자동 선택하도록 설계해 중급·저가 기기까지 AV1 지원 범위를 넓혔다. - 그 결과 고급 기기에서만 가능하다고 여겨졌던 AV1을 더 다양한 모바일 기기에 적용할 수 있었다. ## 디코더 선택 - 디코더는 일반적으로 인코더보다 복잡도가 낮지만, 저가 모바일 기기에서는 실시간 디코딩조차 부담이 될 수 있다. - 초기 A/B 테스트에서 일부 저가 기기는 AV1을 실시간으로 디코딩하지 못해 영상 프리징과 오디오·비디오 동기화 문제가 발생했다. - Meta는 여러 오픈소스 디코더를 비교한 뒤 전력 효율과 안정성이 우수한 **dav1d**를 선택했다. - 이는 AV1 도입 시 인코더뿐 아니라 실제 기기에서의 디코딩 성능과 전력 소비도 함께 검증해야 함을 보여준다. ## 실용적인 결론 RTC에서 AV1을 도입하려면 코덱의 압축 효율만 평가해서는 부족하다. 기기별 인코더 복잡도 조절, 전력·메모리 사용량, 디코더 안정성, 비트레이트 급증과 패킷 손실에 대한 대응을 함께 설계해야 하며, 특히 저가 기기까지 지원하려면 초저복잡도 인코더와 기기별 최적화가 핵심이다.

원문 읽기(새 탭에서 열림)

real-time-communicationav1video-codecdav1d+4

meta·2026년 6월 3일·4분 읽기큐레이션 요약

불은 꺼지고 시스템은 켜진다: 즉각적인 정전 대비 태세 검증

Meta는 데이터센터의 무경고 전력 상실에 대비하기 위해 **Instantaneous PowerLoss Storm**이라는 새로운 재해 대응 테스트 체계를 도입했다. 기존 시스템에 방어 심층화 전략을 적용하고, 지역 전체의 전원을 실제로 차단하는 단계적 검증을 통해 서비스·데이터·시설의 복원력을 확인했다. 목표는 한 지역 전체의 전력 상실을 개별 장애 도메인 손실만큼 안정적으로 처리하는 것이다. ## 무경고 재해에 대비한 새로운 테스트 패러다임 - 기존의 허리케인, 산불, 전력·네트워크 장애 대응책은 사전 경보가 있을 때 효과적이다. - 그러나 순간적인 전력 상실처럼 전혀 예고되지 않는 재해는 기존 전략만으로 대응하기 어렵다. - Instantaneous PowerLoss Storm은 Meta의 기존 Disaster Readiness(재해 대비) “Storm” 프로그램에 추가된 최종 방어선이다. - 알려진 위험뿐 아니라 새롭게 등장하거나 아직 발견되지 않은 위험까지 검증 대상으로 삼는다. ## 데이터센터 전 계층에 적용한 방어 심층화 - 전력 상실 내성을 데이터센터의 전체 스택에 내장했다. - 기계·전기 설비 - 서버 랙 - 스토리지와 컴퓨트 - Twine 컨테이너 오케스트레이터 - 랙 전원이 끊겨도 배터리와 Power Loss Siren(PLS)을 이용해 메모리 데이터를 보존할 수 있도록 했다. - Twine 서비스 간에는 지역 전체에서 동작하는 비동기 신호 체계인 Unavailability Event(UE)를 구축했다. - 기존 기능은 단일 데이터센터의 장애 도메인에서 검증되어 있었지만, 여러 데이터센터가 연결된 지역 전체 장애에서는 다음 문제가 추가로 발생했다. - 장애 규모가 일반 장애 도메인보다 약 50~60배 큼 - 서비스 복제본 배치 문제 - 수백만 개 서비스의 동시 재시작과 자동 발견 - 전원이 꺼진 지역을 스스로 부팅해야 하는 문제 ## 전체 지역 부팅과 순환 의존성 문제 - Twine의 Scheduler, Allocator, Broker, Zelos 같은 제어 플레인 서비스는 다른 서비스를 시작하기 위한 필수 구성요소다. - 전체 지역이 동시에 부팅될 때 제어 플레인 서비스끼리 서로를 필요로 하는 순환 의존성, 즉 “ouroboros” 문제가 발생할 수 있다. - 이를 해결하기 위해: - 핵심 시작 의존성을 식별했다. - CI/CD에서 Belljar 테스트를 지속적으로 실행해 의존성 문제를 조기에 발견했다. - 예기치 않은 순환 의존성을 끊을 수 있도록 Twine recovery kit을 제공했다. - 이 복구 키트는 Twine 자체를 구동하는 서비스에 대한 “jumpstart” 역할을 한다. - Belljar, Twrko, recovery kit을 함께 사용해 지역 전체 부팅 시 발생할 수 있는 순환 의존성 위험을 줄였다. ## 제어 플레인을 종료시키는 ‘부메랑’ 문제 - UE는 서비스 종료와 복구를 조정하는 신호지만, 이 신호를 생성·전달하는 제어 플레인 자체가 UE에 의해 종료될 수 있었다. - 그러면 일부 서비스가 종료 신호를 받지 못한 채 고아 상태로 남을 수 있다. - 특정 서비스를 UE 전달 대상에서 제외하는 복잡한 방식 대신, 전력 관련 UE를 제어 플레인 서비스가 무시하도록 설계했다. - 단순한 예외 처리로 시스템 복잡도와 유지보수 부담을 낮췄다. ## 신뢰성과 개발 속도 사이의 절충 - 순간 장애에 완벽히 대응하려는 설계는 과도한 엔지니어링이나 정상 운영 중 오탐 위험을 만들 수 있다. - 따라서 반드시 방지해야 할 영향과 감수할 수 있는 영향을 구분했다. - 반드시 방지해야 하는 영향: - 스토리지·데이터베이스 데이터 손실 - 데이터센터 기계·전기 설비의 영구 손상 - 단일 지역을 넘어 지속되는 광범위한 장애 - 허용 가능한 영향: - 일시적인 서비스 오류 - 사전에 정한 한도 내의 랙 장애 - 서비스 라우팅 테이블의 제한된 최신성 저하 - 지역 장애 감지의 일시적인 지연 - 사후 복구가 어렵거나 합리적인 MTTR 내에 완화할 수 없는 문제를 허용 범위 밖으로 정의했다. ## 단계적 검증으로 위험과 폭발 반경 축소 - 전원을 직접 차단하는 테스트는 큰 위험을 동반하므로 점진적인 검증 방식을 택했다. - 검증 단계는 다음과 같다. - 신규·사전 운영 지역에서 의존성 등 독립적인 문제를 먼저 테스트 - 운영 지역을 복제한 shadow 지역에서 실험 - 가장 작고 새로운 운영 지역에서 실제 전력 차단 수행 - 이후 스토리지, AI, 데이터 웨어하우스가 위치한 대규모 운영 지역까지 확대 - 최종 단계의 전력 차단 훈련을 Instantaneous PowerLoss Storm이라고 명명했다. ## 실제 Storm 실행 방식 - 전체 지역에 전력 공급 장애를 주입해 즉시 전원을 차단한다. - 실제 장애처럼 보이도록 테스트 전에 선제적인 보호 조치를 최소화했다. - 현실적인 사고 상황의 MTTR을 반영한 뒤, 영향을 받은 지역을 전역 컨트롤러와 스케줄러에서 격리하는 “drain” 조치를 수행했다. - 반복적인 훈련을 통해 인프라와 엔지니어가 지역 전체 장애를 개별 장애 도메인 장애처럼 처리하도록 개선하고 있다. ## 실용적인 결론 대규모 인프라의 무경고 장애 대비에는 단일 복구 기능보다 시설부터 오케스트레이터까지 이어지는 방어 심층화가 중요하다. 특히 전체 시스템 부팅 시의 순환 의존성과 제어 플레인 보호를 사전에 검증하고, 작은 환경에서 시작해 실제 운영 지역으로 단계적으로 확대하는 방식이 안전성과 개발 속도를 함께 확보하는 현실적인 접근이다.

원문 읽기(새 탭에서 열림)

CI/CD분산 시스템fault-tolerancedisaster-recovery+3

meta·2026년 5월 26일·4분 읽기큐레이션 요약

SilverTorch: 모델로서의 인덱스 — 추천 시스템을 위한 새로운 검색 패러다임

SilverTorch는 추천 시스템의 검색(retrieval) 단계를 여러 마이크로서비스가 아닌 하나의 통합 신경망으로 재설계한 아키텍처다. ‘Index as Model’ 패러다임을 통해 사용자 임베딩, ANN 검색, 적격성 필터링, 재순위화와 다중 작업 점수화를 하나의 PyTorch 모델에서 처리한다. 그 결과 기존 방식보다 최대 23.7배 높은 처리량과 20.9배 높은 컴퓨팅 비용 효율을 달성하면서도 추천 품질을 개선하고, 100ms 이하의 지연시간 제약을 유지할 수 있다고 설명한다. ## 기존 마이크로서비스 기반 검색의 한계 - 전통적인 추천 검색 시스템은 다음과 같은 서비스 조합으로 구성된다. - 사용자 타워 모델: 사용자의 관심사를 벡터인 사용자 임베딩으로 변환 - 후보 검색·필터링 서비스: 사용자 벡터와 유사한 콘텐츠를 찾고 언어·지역·정책 등을 기준으로 필터링 - 점수화 서비스: 남은 후보의 참여 가능성을 계산하고 순위를 조정 - 오케스트레이터: 각 서비스에 요청을 분산하고 결과를 통합 - 서비스 간 네트워크 왕복과 데이터 직렬화 과정이 100ms 이하의 검색 지연시간을 소모한다. - 사용자 모델, 아이템 인덱스, 필터링 규칙이 서로 다른 시점에 배포되어 버전이 불일치할 수 있다. - 예를 들어 사용자 모델은 v2인데 아이템 인덱스가 v1이면 서로 다른 버전의 임베딩이 비교된다. - ML 엔지니어는 주로 PyTorch를, 인프라 엔지니어는 C++를 사용해 개발 환경과 배포 주기가 분리된다. - Faiss-GPU와 같은 개별 최적화는 특정 서비스만 빠르게 만들 뿐, 서비스 간 데이터 이동과 독립적인 실행 구조라는 근본 문제는 해결하지 못한다. ## Index as Model: 인덱스를 모델 안으로 통합 - SilverTorch는 아이템 인덱스 자체를 모델 내부의 텐서로 표현한다. - 사용자 타워, ANN 검색, 적격성 필터, 점수화 계층을 모두 하나의 PyTorch 신경망에 포함한다. - 사용자의 요청은 단일 모델의 한 번의 forward pass를 거치며 다음 작업을 수행한다. - 사용자 관심사와 유사한 콘텐츠 검색 - 언어·국가·콘텐츠 정책 등에 따른 노출 가능 여부 확인 - 후보 재순위화 - 좋아요·공유·댓글 등 여러 참여 행동의 확률 예측 - 여러 예측값을 결합한 최종 점수 계산 - 하나의 모델 아티팩트와 단일 실행 경로를 사용하므로 구성 요소 간 공동 최적화와 일관된 버전 관리가 가능하다. - 모델 복잡도와 평가 후보 수를 늘리면서도 100ms 이하의 응답시간을 유지하는 것을 목표로 한다. ## 모델 내부의 검색·필터링·재순위화 - ANN 검색 영역은 전체 카탈로그를 모두 확인하지 않고 사용자와 가까운 아이템을 빠르게 찾는다. - 적격성 필터링 영역은 후보가 사용자에게 노출 가능한지 검사한다. - 언어 - 국가 및 지역 - 콘텐츠 정책 - 기타 서비스별 자격 조건 - 다중 작업 재순위화 영역은 여러 참여 행동을 동시에 예측한다. - 좋아요 - 공유 - 댓글 - 예측 결과를 종합해 참여 가능성이 높은 후보를 계산한다. - 일부 연산은 엔지니어가 직접 작성하고, 일부는 역전파를 통해 종단 간 학습할 수 있다. - 런타임에서는 모든 구성 요소가 동일한 `nn.Module`로 취급되므로 검색 모듈과 학습된 재순위화 모델을 자유롭게 조합할 수 있다. ## 모든 단계를 순수 PyTorch 모듈로 재구현 - 기존 ANN 검색, Bloom 인덱스 필터, 신경망 재순위화, 복합 점수화는 주로 독립적인 C++ 서비스로 구현되어 있었다. - 이러한 구현은 안정적이지만 각자 별도의 메모리·자료구조·실행 모델을 사용해 모듈 간 공동 최적화가 어렵다. - SilverTorch는 모든 데이터를 텐서로 표현하고, 모든 로직을 텐서 입력과 텐서 출력으로 통일한다. - 각 구성 요소는 PyTorch의 표준 `nn.Module` 인터페이스를 따른다. - 이를 통해 다음과 같은 최적화가 가능해진다. - 유망한 클러스터를 먼저 선택 - 선택된 클러스터 안에서만 필터링 - 필터를 통과한 후보만 점수화 - ML 엔지니어와 인프라 엔지니어가 서로 다른 계층에서 작업하는 대신 동일한 실행·개발 계층에서 모듈을 구성하고 최적화할 수 있다. ## 성능과 확장성 - 8천만 개 아이템을 대상으로 한 종단 간 평가에서 기존의 강력한 다중 서비스 기준선보다 초당 요청 처리량이 최대 23.7배 높았다. - CPU 기반 솔루션보다 추정 총소유비용(TCO) 효율이 20.9배 개선되었다. - 피드와 동영상 콘텐츠를 제공하는 여러 애플리케이션 제품군에 적용 가능한 규모 확장성을 보였다고 설명한다. - 신경망 재순위화와 다중 작업 점수화를 지연시간 예산 안에서 실용적으로 수행해, 기존 마이크로서비스 구조에서는 적용하기 어려웠던 추천 품질 개선을 가능하게 했다. 실용적으로는 검색 단계의 서비스 수가 많고, 후보 수·모델 복잡도·지연시간 간 충돌이 큰 시스템일수록 SilverTorch와 같은 통합 모델 구조의 효과가 크다. 다만 모든 구성 요소를 PyTorch로 통일하려면 GPU 메모리 관리, 모델 배포 안정성, 디버깅과 장애 격리 같은 운영 과제를 함께 해결해야 한다.

원문 읽기(새 탭에서 열림)

마이크로서비스recommendation-systemsneural-networkspytorch+3

meta·2026년 5월 13일·2분 읽기큐레이션 요약

릴 프렌즈: 수십억 명까지 확장 가능한 소셜 디스커버리 구축

Friend Bubbles는 친구들이 시청하거나 반응한 릴스를 강조해 보여주는 기능이다. 겉보기에는 단순하지만, 실제 구현에는 머신러닝 모델의 발전과 iOS·Android 사용자 행동 차이 분석 등 복잡한 엔지니어링 작업이 필요했다. Meta Reels 팀은 개발 과정에서 기능의 작동 방식을 결정짓는 중요한 발견을 통해 최종적인 사용자 경험을 완성했다. ### 친구 활동을 활용한 릴스 추천 - 친구들이 시청하거나 반응한 릴스에 친구 정보를 표시해 콘텐츠의 사회적 맥락을 강화한다. - 사용자는 친구들의 활동을 바탕으로 새로운 릴스를 발견할 수 있다. - 단순히 친구의 반응을 수집하는 것이 아니라, 어떤 활동을 어떤 방식으로 노출할지 결정해야 한다. ### 머신러닝 모델의 발전 - Friend Bubbles의 핵심에는 친구 활동과 콘텐츠 노출을 연결하는 머신러닝 모델이 있다. - 모델은 어떤 친구의 어떤 반응이 사용자에게 의미 있을지 판단해야 한다. - 기능 개발 과정에서 모델이 초기 형태에서 발전했으며, 데이터와 실제 사용자 행동을 반영해 개선됐다. - “친구가 반응했다”는 사실만으로는 충분하지 않고, 콘텐츠와 사용자 사이의 관련성까지 고려해야 했다. ### iOS와 Android 사용자의 행동 차이 - iOS와 Android 사용자 사이에는 릴스 소비 방식과 친구 활동에 반응하는 방식에서 차이가 나타났다. - 동일한 기능을 두 플랫폼에 제공하더라도 사용자 행동이 다르기 때문에, 플랫폼별 데이터를 별도로 분석해야 했다. - 이러한 차이는 모델 학습과 기능 설계, 노출 방식 조정에 영향을 미쳤다. ### 예상 밖의 발견과 기능 완성 - 개발팀은 초기 가정만으로는 기능이 기대한 만큼 자연스럽게 작동하지 않는 문제를 겪었다. - 사용자 행동을 분석하는 과정에서 기능의 효과를 결정하는 “놀라운 발견”을 찾아냈다. - 이 발견을 바탕으로 친구 활동과 릴스 추천의 연결 방식을 조정했고, Friend Bubbles가 의도한 사용자 경험을 구현할 수 있었다. ### 단순한 기능에 필요한 깊은 엔지니어링 - Friend Bubbles 사례는 화면에 작은 정보를 추가하는 기능도 대규모 추천 시스템과 사용자 행동 분석을 요구할 수 있음을 보여준다. - 기능 구현에는 모델 설계뿐 아니라 플랫폼별 차이, 데이터 해석, 실험과 반복 개선이 함께 필요했다. - 글의 내용은 Meta Tech Podcast에서 Facebook Reels 팀 엔지니어들이 이러한 개발 과정을 설명한다는 소개에 해당하며, 세부 구현 방식은 팟캐스트 에피소드에서 다뤄진다. 작아 보이는 사용자 기능일수록 실제로는 추천 모델, 행동 데이터, 플랫폼별 최적화가 긴밀하게 결합되어야 한다. 비슷한 기능을 개발할 때는 초기 직관에만 의존하지 말고, 실제 사용자 행동과 플랫폼별 차이를 지속적으로 검증하는 것이 중요하다.

원문 읽기(새 탭에서 열림)

머신러닝AndroidiOSsoftware-engineering+1

meta·2026년 5월 12일·4분 읽기큐레이션 요약

메타급 규모에서 데이터 수집 시스템 마이그레이션하기

Meta는 수 페타바이트 규모의 소셜 그래프 데이터를 매일 MySQL에서 데이터 웨어하우스로 수집하는 시스템을 기존 고객 소유 파이프라인에서 단순한 자체 관리형 아키텍처로 전환했다. 이 과정에서 수천 개 작업을 단계적으로 검증하고, 데이터 품질·지연 시간·리소스 사용량을 비교하며 안전하게 마이그레이션했다. 섀도 작업, 리버스 섀도, 자동화된 데이터 품질 분석, 신속한 롤백 체계를 통해 전체 워크로드를 성공적으로 이전하고 레거시 시스템을 폐기했다. ## 대규모 데이터 수집 시스템 개편 배경 - Meta의 소셜 그래프는 세계 최대 규모의 MySQL 환경 중 하나에서 운영된다. - 데이터 수집 시스템은 매일 수 페타바이트의 데이터를 증분 방식으로 데이터 웨어하우스에 적재한다. - 적재된 데이터는 다음과 같은 용도로 활용된다. - 분석 및 리포팅 - 머신러닝 모델 학습 - 제품 개발 - 사내 의사결정 및 데이터 기반 서비스 - 기존 시스템은 소규모에서는 효과적이었지만, 규모가 커지면서 엄격해진 데이터 적재 시간 요구사항을 안정적으로 충족하기 어려워졌다. - 이에 따라 고객 팀이 직접 운영하던 파이프라인을 단순한 자체 관리형 데이터 웨어하우스 서비스로 대체했다. ## 마이그레이션 성공 기준 각 작업은 다음 조건을 충족해야 다음 단계로 진행됐다. - **데이터 품질 일치** - 기존 시스템과 신규 시스템의 행 개수를 비교했다. - 데이터 체크섬을 비교해 두 시스템의 결과가 완전히 일치하는지 검증했다. - **적재 지연 시간 개선** - 신규 시스템의 데이터 적재 지연 시간이 기존보다 개선되거나 최소한 동등해야 했다. - **리소스 사용량 개선** - 컴퓨팅 및 스토리지 사용량이 기존보다 줄어들거나 최소한 비슷해야 했다. - **핵심 테이블 추가 기준** - 중요 테이블은 해당 데이터를 사용하는 팀들과 별도의 마이그레이션 조건을 합의했다. ## 1단계: 섀도 단계 - 사전 운영 환경에 신규 시스템 기반의 섀도 작업을 생성했다. - 섀도 작업은 운영 작업과 동일한 실제 데이터를 읽지만, 별도의 섀도 테이블에 결과를 기록했다. - 실제 운영 데이터와 동작을 사용하므로 다음과 같은 문제를 사전에 발견할 수 있었다. - 데이터 변환 오류 - 특수한 데이터 패턴에서 발생하는 예외 - 신규 시스템의 리소스 부족 - 운영 테이블과 섀도 테이블의 행 개수 및 체크섬을 지속적으로 비교했다. - 불일치가 발생하면 원인을 조사하고 사전 운영 환경에 수정 사항을 배포한 뒤 재검증했다. - 동시에 섀도 작업의 컴퓨팅·스토리지 사용량을 측정해 운영 환경에 충분한 자원이 있는지 확인했다. - 기준을 통과한 작업은 운영 환경에서도 안정적으로 실행되는지 추가로 검증했다. ## 2단계: 리버스 섀도 단계 - 신규 시스템의 섀도 작업이 운영 테이블에 데이터를 기록하도록 전환했다. - 기존 시스템의 운영 작업은 섀도 테이블에 데이터를 기록하게 했다. - 이로써 신규 시스템이 실제 운영 작업이 되고, 기존 시스템은 비교용 섀도 작업으로 역할이 바뀌었다. - 이 방식의 장점은 다음과 같다. - 전환 이후에도 기존 시스템과 신규 시스템의 결과를 계속 비교할 수 있다. - 데이터 불일치가 발견되면 기존 작업을 다시 구성하지 않고 즉시 되돌릴 수 있다. - 신규 시스템이 실제 운영 환경에서 지속적으로 안정적인지 확인할 수 있다. ## 3단계: 마이그레이션 정리 - 두 시스템의 결과를 계속 비교하면서 불일치 여부를 감시했다. - 문제가 발견되지 않으면 기존 시스템에서 실행 중인 섀도 작업을 제거했다. - 이후 신규 시스템이 운영 작업으로서 데이터 적재를 계속 수행하며 마이그레이션이 완료됐다. ## 자동화된 데이터 품질 분석 도구 - 각 섀도 테이블 파티션과 대응하는 운영 테이블 파티션을 읽어 행 개수와 체크섬을 비교했다. - 불일치 내역은 Meta의 실시간 데이터 분석 시스템인 Scuba에 기록했다. - 매시간 Scuba 로그를 분석해 불일치를 일으킨 실제 예시 행을 찾았다. - 원인 분석에 필요한 상세 디버깅 정보도 다시 Scuba에 기록했다. - 이를 통해 엔지니어는 다음을 빠르게 판단할 수 있었다. - 불일치의 근본 원인 - 이미 알려진 문제인지 여부 - 해당 문제가 수정 진행 중인지 여부 - 이 도구는 마이그레이션 이후에도 릴리스 검증 과정에서 계속 사용되고 있다. ## CDC 기반 구조와 롤백 문제 - 기존 시스템과 신규 시스템 모두 CDC(Change Data Capture)를 사용해 변경분을 대상 테이블에 증분 반영했다. - 각 작업은 다음 테이블을 관리한다. - 소스 데이터베이스의 전체 덤프를 저장하는 내부 테이블 - 소스 변경 사항을 저장하는 델타 테이블 - 데이터 소비자가 사용하는 대상 테이블 - 작업 엔터티, 테이블 이름, 스키마 등의 메타데이터는 중앙 관리 서비스가 관리했다. - CDC에서는 이전에 적재된 데이터가 이후 데이터 생성에 다시 사용된다. - 따라서 과거 데이터에 문제가 있으면 해당 문제가 신규 적재 데이터로 계속 전파될 수 있다. - 마이그레이션 후 문제가 발생하면 잘못된 데이터가 계속 확산되는 것을 막기 위해 신속한 롤백이 필요했다. ## 조기 신호와 신속한 롤백 - 데이터 소비자가 문제를 발견할 때까지 기다리지 않고, 리버스 섀도 단계에서 두 시스템의 결과를 지속적으로 비교했다. - 이를 통해 마이그레이션 성공 여부에 대한 조기 신호를 확보했다. - 문제가 발견되면 기존 시스템이 이미 섀도 작업으로 실행 중이므로 빠르게 이전 상태로 되돌릴 수 있었다. - 마이그레이션 작업을 처음부터 다시 생성하거나 재구성하지 않아도 된다는 점이 롤백 위험을 줄였다. 대규모 데이터 시스템을 이전할 때는 한 번에 전환하기보다, 실제 데이터 기반의 섀도 실행과 양방향 역할 전환을 통해 검증하는 방식이 안전하다. 특히 행 개수·체크섬·지연 시간·리소스 사용량을 자동 비교하고, 문제가 생겼을 때 즉시 롤백할 수 있는 구조를 마이그레이션 설계에 포함하는 것이 중요하다.

원문 읽기(새 탭에서 열림)

머신러닝mysqldata-ingestionchange-data-capture+3

meta·2026년 5월 11일·2분 읽기큐레이션 요약

Labyrinth 1.1: 종단 간 암호화 백업을 더욱 안정적으로 만들기

메타는 메신저의 종단간 암호화(E2EE) 저장 시스템인 Labyrinth 1.1을 출시했다. 이번 버전은 기기가 오프라인이어도 메시지가 전송되는 즉시 암호화 백업에 저장되도록 개선해, 기기 분실·교체나 장기간 미로그인 상황에서도 메시지 복구 가능성을 높인다. 메시지 내용은 메타를 포함한 제3자가 읽을 수 없으며, 실제 배포 결과 백업 성공률과 전체 대화 기록 복원율이 향상되고 있다. ## Labyrinth와 메신저 암호화 백업 - Labyrinth는 메신저 계정에 연결된 여러 기기 사이에서 저장된 메시지 기록을 종단간 암호화하는 시스템이자 프로토콜이다. - 2023년 도입된 암호화 백업은 메시지 기록을 기기 간에 이동할 수 있게 하면서도 메타가 내용을 열람하지 못하도록 설계됐다. - 사용자는 기기를 바꾸더라도 백업에서 기존 대화 기록을 복원할 수 있다. ## 기존 암호화 백업의 한계 - 기존 방식에서는 메시지를 보낸 뒤 수신자의 기기가 다시 온라인 상태가 될 때까지 암호화 백업에 저장되지 않을 수 있었다. - 따라서 다음과 같은 상황에서 일부 메시지가 백업되지 않을 가능성이 있었다. - 휴대전화를 분실한 경우 - 새 기기로 교체한 경우 - 오랫동안 메신저에 로그인하지 않은 경우 - 기기 자체에 메시지가 남아 있지 않으면, 백업에 도달하지 못한 메시지를 복원하기 어려웠다. ## Labyrinth 1.1의 새로운 하위 프로토콜 - 메시지가 전송되는 시점에 수신자의 암호화 백업으로 직접 전달되도록 동작한다. - 수신자의 기기가 온라인으로 돌아올 때까지 메시지 백업을 기다리지 않아도 된다. - 각 메시지는 별도의 메시지 암호화 키로 보호된다. - 발신자는 해당 키를 수신자의 암호화 백업에 직접 넣으며, 이는 “수신자만 열 수 있는 잠긴 상자에 봉인된 편지를 넣는 것”에 비유된다. - 결과적으로 메시지 내용과 암호화된 백업은 메타가 접근할 수 없고, 대화 당사자만 메시지를 읽을 수 있다. ## 안정성 및 배포 효과 - Labyrinth 1.1은 메신저 전체에 광범위하게 배포되고 있다. - 메타에 따르면 다음과 같은 개선 효과가 나타나고 있다. - 암호화 백업에 성공적으로 저장되는 메시지 증가 - 기기 변경 후 전체 메시지 기록을 복원하는 사용자 증가 - 세부 설계와 암호화 프로토콜은 업데이트된 백서인 「The Labyrinth Encrypted Message Storage Protocol」에서 확인할 수 있다. 사용자 입장에서는 메신저의 암호화 백업 기능을 활성화하고, 기기를 교체하기 전에 백업 설정과 복구 방법을 확인하는 것이 좋다. 이번 업데이트는 특히 기존 기기에 접근할 수 없는 상황에서도 메시지 손실을 줄이는 데 초점을 둔 개선이다.

원문 읽기(새 탭에서 열림)

end-to-end-encryptionencrypted-backupsmessengercryptographic-protocol+1