Introduction & Requirements
사용자가 Instagram의 Explore 화면을 엽니다. 여러 사진과 영상의 썸네일이 격자로 나타납니다. 여행 사진을 누르고, 카페 게시물을 저장하고, 관심 없는 운동 영상에는 관심 없음을 선택합니다. 화면을 조금 더 내렸을 때 서버는 무엇을 보여줘야 할까요.
방금 저장한 카페와 비슷한 게시물을 더 보여줄 수 있습니다. 그러나 카페 사진만 이어지면 다른 관심사를 발견하기 어렵습니다. 조회 수가 높은 게시물을 섞을 수도 있지만, 인기 있다는 이유만으로 이 사용자에게 적합하다고 볼 수는 없습니다. 사용자가 숨긴 게시물이나 추천 대상에서 제외된 콘텐츠는 점수가 높더라도 반환하면 안 됩니다.
서버는 추천 가능한 게시물을 찾고, 사용자와 게시물의 관계를 평가하고, 화면에 함께 놓을 조합을 결정해야 합니다. 응답을 보낸 뒤에는 실제로 어떤 항목이 화면에 나타났는지, 무엇을 눌렀는지, 무엇을 저장했는지도 알아야 합니다. 이 기록이 다음 요청의 입력이자 다음 모델의 학습 데이터가 됩니다.
가장 단순한 구현은 공개 게시물을 DB에서 읽어 최근 반응 수로 정렬하는 방식입니다. 게시물이 적다면 관심 태그와 작성 시각을 추가해도 충분합니다. 그러나 게시물 수가 늘어나면 요청마다 전체 목록을 비교하기 어렵고, 같은 인기 게시물이 반복됩니다. 사용자마다 다른 순서를 만들기 위해 복잡한 모델을 붙이면 DB 조회와 추론 시간이 함께 늘어납니다.
여기서 어려운 상태는 단순히 게시물의 점수가 아닙니다. 사용자의 관심은 계속 바뀌고, 추천 가능 여부는 별도의 속도로 바뀌며, 실제 노출 기록은 네트워크 때문에 늦게 도착합니다. 서로 다른 시점의 데이터를 한 요청에서 어떻게 조합할지 결정해야 합니다.
공개된 설명과 이 글의 설계 가정
Meta는 2023년 8월 발표한 「Scaling the Instagram Explore recommendations system」에서 Retrieval, First-stage ranking, Second-stage ranking, Final reranking으로 이어지는 구조를 설명했습니다. Two Tower 모델, 임베딩 캐시, 무거운 모델의 출력을 학습하는 초기 랭커도 당시 공개 내용에 포함됩니다. 이는 해당 시점의 구현 설명이며, 현재 모든 요청이 동일한 모델과 후보 개수로 처리된다는 뜻은 아닙니다.
2025년 5월 발표한 「Journey to 1000 models」는 Instagram의 여러 추천 화면과 실험을 합친 모델 운영을 다룹니다. 모델 등록부, 배포 용량 산정, 예측 품질 관측이 설명되어 있습니다. Explore 요청 하나가 모델 1,000개를 호출한다는 의미로 읽으면 안 됩니다.
제품 동작도 설계에 영향을 줍니다. Meta가 2024년 발표하고 2025년 갱신한 추천 초기화 안내에서는 Explore, Reels, Feed의 추천을 초기화한 뒤 새로운 상호작용에 따라 다시 개인화하는 동작을 설명합니다. 관심 없음과 같은 사용자 피드백도 소개합니다.
이 글은 이러한 공개 설명을 참고해 Explore의 격자형 발견 화면을 설계합니다. 실제 내부 구현 전체는 공개되어 있지 않으며, 아래 DB, Queue, Feature Store, API, schema, 모델 구성과 수치는 제품 동작을 만족시키기 위한 시스템 디자인 가정입니다. 추천 초기화의 내부 저장 방식 역시 여기에서 제안하는 구현입니다.
Functional Requirements
사용자는 Explore에서 관심과 관련된 사진과 영상을 발견하고, 다음 페이지를 연속해서 조회할 수 있습니다.
시스템은 여러 후보 검색 경로를 결합하고, 관련성, 다양성, 최신성, 추천 적격성을 고려해 게시물을 배치합니다.
사용자는 게시물을 열고 저장하거나, 관심 없음을 선택하고 계정을 차단할 수 있습니다.
시스템은 서버가 반환한 항목과 실제 화면에 노출된 항목을 구분해 기록합니다.
사용자는 추천을 초기화할 수 있으며, 시스템은 초기화 이전의 개인화 상태가 다시 활성화되지 않게 처리합니다.
시스템은 새 게시물과 새로운 사용자를 추천에 포함할 수 있어야 합니다.
운영자는 모델과 검색 인덱스를 점진적으로 배포하고, 문제가 발생하면 호환되는 이전 구성으로 돌아갈 수 있습니다.
Non-Functional Requirements
다음 수치는 Instagram의 공개 SLA가 아닌 설계를 위한 가정입니다.
Explore API의 서버 처리 시간은 p95 200ms, p99 350ms 이내를 목표로 합니다. 이미지 다운로드와 모바일 화면 렌더링은 별도로 측정합니다.
월간 API 가용성은 99.95%를 목표로 합니다. 대체 추천으로 성공한 요청 비율과 정상 개인화 성공률을 분리합니다.
사용자 행동이 정상적인 스트림 처리 상황에서 5초 이내에 온라인 관심 특성에 반영되도록 목표를 둡니다.
추천 초기화와 차단이 성공한 뒤 시작된 요청은 확정된 새 제어 상태를 사용해야 합니다. 권한 확인이 불가능하면 해당 후보를 제외하거나 재시도 응답을 반환합니다.
수신 완료를 알린 사용자 제어 변경은 장애 후에도 보존해야 합니다. 일반 노출 이벤트와 동일한 내구성 정책으로 취급하지 않습니다.
피크 요청과 이벤트 유입을 처리하면서 검색, 추론, 스트림 소비 자원을 독립적으로 확장할 수 있어야 합니다.
사용자 식별 정보와 관심 특성에 접근 권한, 보관 기한, 삭제 경로를 적용합니다. 초기화와 개인정보 삭제는 서로 다른 동작으로 정의합니다.
모델 변경은 추천 품질뿐 아니라 안전성, 창작자 노출 분포, 지연 시간, 요청당 비용을 함께 평가합니다.
Out of Scope
Home Feed, Stories, Reels 전용 화면의 전체 랭킹을 구현하지 않습니다.
검색어 기반 검색, 광고 경매, 결제와 쇼핑 주문 처리는 제외합니다.
영상 업로드와 인코딩의 전체 구현은 제외하되, 준비 완료와 삭제 이벤트는 입력으로 받습니다.
콘텐츠 검토 모델 자체의 학습은 제외하되, 검토 결과와 추천 적격성 적용은 포함합니다.
DM 전송은 제외합니다. 공유 완료 이벤트는 해당 시스템이 확정한 결과를 전달받습니다.
Traffic & Capacity Assumptions
아래 계산은 실제 Instagram 사용량이 아닙니다. API 요청, 모델이 평가하는 후보, 사용자 행동 이벤트의 단위를 구분하기 위한 가정입니다. 저장 용량은 십진 단위를 사용합니다.
사용자 수와 페이지 요청
Explore의 DAU를 1억 명, 사용자당 하루 페이지 요청을 10회로 가정하겠습니다. 하루 10억 요청이고, 평균 약 초당 1만 1,600건입니다. 피크를 평균의 6배로 두면 약 초당 6만 9,400건입니다.
이 계산은 인증과 추천 조합을 담당하는 API의 규모를 알려줍니다. 이미지 파일을 이 API 서버가 직접 전달하면 추천 처리량과 미디어 전송량이 결합되므로, 응답에는 미디어 참조를 넣고 전송 경로를 분리합니다.