네이버급 검색 포털 시스템 설계: 크롤링·색인·랭킹·신선도

사용자가 서울 주말 전시를 검색하면 빠른 결과만으로는 부족하다. 같은 행사가 여러 번 나오지 않아야 하고, 방금 공개된 일정은 제때 보여야 하며, 삭제된 페이지는 다시 나타나지 않아야 한다. 네이버급 검색 포털 시스템 설계는 이 세 기대를 크롤링·색인·랭킹·신선도 정책으로 바꾸는 일이다.

이 글은 2026년 8월 15일 기준 공개 표준, 공식 제품 문서와 원 논문을 대조한 일반 설계 사례다. 실제 네이버의 내부 구조나 성능을 재현하지 않았고, 트래픽과 저장량·지연 목표는 선택을 비교하기 위한 설계 가정이다. 웹과 모바일 사용자가 결과를 받는 과정에 집중하며 광고, 지도·쇼핑·뉴스 계약 피드와 로그인 기반 초개인화는 다루지 않는다.

20초 핵심 요약

• 무엇: 공개 웹을 수집해 중복을 묶고, 역색인을 여러 조각에 나눠 검색한 뒤 단계별로 순위를 매기는 포털 설계다.
• 왜: 수집과 검색, 일반 갱신과 삭제를 같은 경로에 두면 새 글은 늦게 보이고 삭제 문서는 캐시에 남으며 느린 한 조각이 전체 검색을 지연시킨다.
• 어떻게: 세 사용자 행동의 요청 흐름을 따라간 뒤 데이터 모델, 병목, 복구, 대안과 확장 조건을 연결한다.

세 사용자가 기대하는 결과부터 고정한다

첫째, 일반 사용자는 짧은 검색어를 입력하고 관련성이 높은 제목·요약·링크를 받는다. 결과는 중복이 적어야 하고 위험한 목적지는 걸러져야 한다. 정상 검색의 응답 목표는 설계 가정으로 p95 300ms 이내이며, p95는 요청 100개를 빠른 순서로 세웠을 때 느린 쪽 다섯 개가 시작되는 지점으로 대부분 사용자의 체감 지연을 관리하려고 쓴다.

둘째, 최신 사건을 찾는 사용자는 몇 분 전에 게시된 문서를 발견하기를 기대한다. 다만 모든 검색에서 새 문서가 먼저여서는 안 된다. 사건성 질의에는 시간 신호를 강하게 적용하고, 오래 유지되는 정보에는 관련성과 출처 품질을 우선해야 한다.

셋째, 게시자나 개인정보 당사자는 삭제·접근 제한·noindex가 결과에 반영되기를 기대한다. noindex는 페이지를 검색 결과에 넣지 말라는 표시이며, 수집기가 페이지를 읽을 수 있어야 발견할 수 있다. 따라서 robots.txt로 수집을 막으면서 noindex도 읽으라고 요구할 수는 없다.

정확성은 모든 질의에 하나의 정답을 보장한다는 뜻이 아니다. 평가 데이터에서 관련성·신선도·출처 다양성을 측정하고, 잘못된 자동 교정과 랭킹 모델은 이전 버전으로 돌릴 수 있어야 한다. 검색어와 인터넷 주소(IP)는 기본적으로 분리·축약하고 보존 기간과 접근 권한을 정한다.

규모 가정은 검색과 수집의 다른 병목을 드러낸다

아래 수치는 네이버의 공개 수치가 아니다. 구성 선택을 시험하기 위한 설계 가정이다. URL(Uniform Resource Locator)은 웹 주소, KB(킬로바이트)와 PB(페타바이트)는 저장량 단위다.

항목	설계 입력	계산	결과와 의미
검색 요청	평균 10,000 QPS, 피크 3배	10,000×3	피크 30,000 QPS. QPS(Queries Per Second)는 초당 질의 수이며 캐시와 검색 복제본 용량을 정한다.
유효 문서	10억 개	직접 가정	한 서버에 두기 어려워 색인을 나눠야 한다.
압축 원문	문서당 평균 100KB	10억×100KB	약 100PB. 약 1,000조 바이트 규모이며 원문과 검색용 데이터를 분리해야 한다.
역색인·메타데이터	문서당 평균 20KB	10억×20KB	약 20PB, 복제본 2개면 약 40PB다. 언어와 압축률에 민감하다.
하루 수집	1억 URL	1억÷86,400초	평균 약 1,157회/초다. 응답 크기와 문서 해석 비용이 좌우한다.
하루 색인 변경	5천만 문서	5천만÷86,400초	평균 약 579회/초다. 순간 증가를 흡수할 대기열이 필요하다.
질의 후보	100샤드×샤드당 1,000개	로컬 평가 10만 개	전부 전송하지 않고 각 샤드의 상위 후보만 합친다.

입력이 바뀌면 증설 위치도 달라진다. 평균 원문이 100KB에서 300KB가 되면 저장 공간과 수집 대역폭은 세 배가 되지만 검색 요청 수는 그대로다. 피크 검색이 세 배 더 늘면 수집기가 아니라 캐시와 질의 복제본을 먼저 늘린다. 새 문서 노출 목표가 하루에서 10분으로 줄면 전체 문서 수보다 변경 탐지와 증분 색인 속도가 중요해진다.

검색어를 입력하면 일곱 단계를 거쳐 결과가 돌아온다

API(Application Programming Interface)는 클라이언트와 검색 서버가 요청·응답 형식을 맞추는 접점이며, 입력을 일관되게 검사하고 결과를 돌려주기 위해 필요하다. 대표 읽기 API는 다음처럼 검색어와 다음 페이지 위치, 안전 검색 수준, 언어를 받는다. cursor는 다음 결과 묶음의 위치를 서버가 해석할 수 있게 감춘 값이다.

GET /v1/search?q=%EC%84%9C%EC%9A%B8+%EC%A3%BC%EB%A7%90+%EC%A0%84%EC%8B%9C&cursor=opaque&safe=moderate&locale=ko-KR

{
  "query_id": "public-random-id",
  "results": [
    {
      "doc_id": "d_42",
      "url": "https://example.org/exhibit",
      "title": "...",
      "snippet": "...",
      "updated_at": "2026-08-15T00:40:00Z"
    }
  ],
  "next_cursor": "opaque",
  "partial": false
}

1. API 접점이 검색어 길이, 언어와 안전 검색 옵션을 검사하고 요청 ID를 만든다.
2. 질의 해석기는 철자·띄어쓰기와 한국어 단어 형태를 정리한다. 원문과 변환 결과를 함께 보존해 잘못된 교정을 되돌린다.
3. 결과 캐시는 정리된 질의, 언어, 안전 옵션과 색인 세대 번호로 키를 만든다. 세대 번호는 어느 색인 묶음을 읽었는지 표시해 서로 다른 시점의 결과가 섞이지 않게 한다.
4. 캐시에 없으면 조정기가 관련 색인 조각에 요청을 동시에 보낸다. 샤딩은 전체 색인을 여러 조각으로 나눠 서버별로 맡기는 방식이며, 이 글에서는 10억 문서의 저장과 계산을 분산하려고 필요하다. 질의 fan-out은 한 요청을 여러 샤드에 동시에 펼쳐 보내는 동작이며, 병렬 검색을 위해 필요하지만 느린 샤드 하나가 전체 지연을 늘릴 수 있다.
5. 각 샤드는 역색인, 즉 단어에서 그 단어가 든 문서 목록으로 거꾸로 찾아가는 자료구조로 후보를 찾는다. 모든 문서를 매번 읽지 않고 검색 후보를 좁히려고 필요하다.
6. 각 샤드는 저렴한 1단계 점수로 로컬 상위 K개만 반환한다. 조정기는 이를 합친 뒤 상위 일부에만 더 비싼 2단계 모델, 출처 다양화와 안전 필터를 적용한다.
7. 문서 저장소에서 제목·URL·요약을 읽어 응답한다. 일부 샤드가 제한 시간 안에 답하지 않으면 가능한 결과와 partial: true를 반환하고, 빠진 샤드를 운영 지표에 남긴다.

각 구성 요소는 사용자 요청에서 맡은 일이 하나다. API 접점은 입력을 지키고, 질의 해석기는 검색어를 검색 가능한 형태로 바꾸며, 조정기는 여러 샤드 결과를 하나로 합친다. 샤드는 후보를 찾고 점수를 매기며, 문서 저장소는 화면에 보여줄 필드를 제공한다.

새 글은 수집 대기열에서 검색 가능한 세대로 이동한다

여기서 URL frontier는 아직 방문하지 않았거나 다시 방문할 주소를 우선순위와 웹사이트별 요청 간격에 따라 꺼내는 대기열이다. 새 글을 빨리 찾으면서 특정 사이트에 요청을 몰아주지 않기 위해 필요하다.

1. 게시자가 공개 링크나 사이트맵으로 새 URL과 수정 시간을 알린다. Google의 공개 문서에서 사이트맵과 lastmod는 수집을 보장하는 일정이 아니라 정확할 때 활용되는 힌트다.
2. URL frontier가 새 주소인지, 과거에 자주 바뀌었는지, 마지막 수집이 성공했는지와 사이트별 허용 속도를 보고 우선순위를 정한다.
3. 수집기는 Robots Exclusion Protocol(로봇 배제 표준)을 확인한다. 이는 사이트 운영자가 자동 수집기에 허용·차단 경로를 알리는 규칙이며, 예의 있는 수집을 위해 필요하지만 로그인 같은 접근 통제는 아니다. RFC(Request for Comments) 9309는 이 인터넷 표준 문서의 번호이며, 네트워크나 서버 오류로 robots.txt에 닿지 못하면 해당 사이트 수집을 막고 재시도하고 캐시 사본은 보통 24시간을 넘기지 말라고 권고한다.
4. 가져오기 작업은 문서를 받아 텍스트, 링크, 대표 URL 힌트와 noindex를 추출한다. canonical은 여러 주소 가운데 대표로 삼고 싶은 URL을 알리는 힌트이며, 이 글에서는 중복 후보를 묶는 신호로 쓰되 단독 판정으로 믿지 않는다.
5. 중복 판별기는 안전한 URL 정규화, 본문 지문, 리디렉션과 canonical 신호를 함께 보고 대표 문서 ID를 정한다.
6. 색인 빌더는 새 세그먼트, 즉 따로 검색할 수 있고 만들어진 뒤에는 내용을 직접 고치지 않는 작은 색인 묶음을 만든다. 기존 검색을 멈추지 않고 새 문서를 공개하고, 나중에 작은 묶음을 합쳐 읽기 비용을 낮추기 위해 필요하다.
7. 검색기가 새 세그먼트를 포함한 색인 세대로 전환하면 관련 문서·질의 캐시를 무효화한다.

두 주요 경로는 아래 그림의 왼쪽 사용자 행동부터 오른쪽 결과까지 읽는다. 위쪽은 검색 요청이 즉시 되돌아오는 경로이고, 아래쪽은 새 문서와 삭제가 나중에 검색 상태를 바꾸는 경로다.

그림의 결론은 검색 요청이 웹페이지를 그 자리에서 읽지 않는다는 점이다. 온라인 질의는 이미 준비된 색인을 읽고, 수집·색인·삭제는 별도 경로에서 다음 검색 상태를 만든다. 이 분리가 느린 외부 사이트나 색인 병합 때문에 현재 검색이 멈추는 일을 막는다.

삭제는 일반 갱신보다 빠르고 확인 가능해야 한다

삭제는 404, 410, 접근 제한, noindex 관측 또는 승인된 삭제 요청에서 시작한다. 정규 URL 하나만 지우면 매개변수나 다른 주소로 남은 복제본이 다시 보일 수 있으므로 대표 문서 ID와 연결된 URL 변형을 함께 찾는다.

1. 삭제 접점이 대상 URL, 근거와 요청 시각을 확인하고 삭제 버전을 높인다.
2. 삭제 원장은 요청과 상태 변화를 순서대로 남기는 변경이 어려운 감사 기록이다. 어느 샤드·저장소·캐시까지 반영됐는지 증명하고 빠진 대상을 재처리하려고 필요하다.
3. 높은 우선순위의 삭제 이벤트를 검색 샤드, 문서·요약 저장소와 결과 캐시에 보낸다.
4. 각 대상은 같은 이벤트를 여러 번 받아도 같은 최종 삭제 상태를 만든다. 이 성질을 멱등성이라고 하며, 메시지가 중복 전송돼도 삭제가 되살아나거나 버전이 거꾸로 가지 않게 하려고 필요하다.
5. 색인 파일이 합쳐지기 전에도 응답 직전의 문서 ID 삭제 필터가 노출을 막는다.
6. 모든 복제본과 캐시의 삭제 버전을 대조한 뒤에만 원장의 요청을 완료로 표시한다.

Google 공개 동작에서 빠른 URL 제거는 임시 조치이고 영구 제거에는 원문 삭제, 접근 제한 또는 접근 가능한 페이지의 noindex 같은 지속 조건이 필요하다. 이는 모든 검색엔진의 내부 구현이라는 뜻이 아니라, 빠른 차단과 영구 상태를 분리해야 한다는 운영 예시다.

문서 ID와 버전이 중복·갱신·삭제를 잇는다

핵심 레코드는 다음 네 묶음이면 흐름을 설명할 수 있다. PK(Primary Key)는 레코드를 하나로 식별하는 기본 키다. Posting은 단어 하나가 등장한 문서 ID와 빈도·위치를 정렬한 목록이며, 역색인이 후보를 빨리 찾도록 필요하다. simhash는 비슷한 본문에 비슷한 짧은 숫자를 주는 지문이며, 일부만 바뀐 복제 문서의 후보를 빨리 묶기 위해 필요하다.

UrlRecord
- normalized_url (PK)
- host_key
- discovered_at, last_fetch_at, next_fetch_at
- robots_policy_version
- fetch_status, content_hash
- canonical_doc_id, priority_score

Document
- doc_id (PK)
- canonical_url
- title, body_object_key, language
- content_hash, simhash
- published_at, fetched_at, source_updated_at
- index_version, deletion_version, state

Posting
- term + shard_id (lookup key)
- ordered list of (doc_id, term_frequency, positions)

DeletionEvent
- event_id (PK)
- doc_id, normalized_url, deletion_version
- reason_code, requested_at
- per_target_status, completed_at

문서 ID에서 제목 같은 화면 필드를 가져오는 저장소는 Posting과 반대 방향 조회를 맡는다. simhash는 잘못 묶을 수 있으므로 자동 영구 삭제의 단독 근거로 삼지 않는다. 정확히 같은 본문은 암호학적 내용 해시로 묶고, 비슷한 본문은 언어·출처·canonical·리디렉션과 시간 정보까지 확인한다.

원시 HTML은 재처리와 감사에 필요한 기간만 저비용 객체 저장소에 보관하고, 파생 텍스트와 역색인은 활성 검색 기간 동안 둔다. 백업에서 즉시 물리 삭제하기 어렵다면 복원할 때도 deletion_version을 적용해 온라인 결과로 되살아나지 않게 한다. 구체적인 보존·파기 기한은 관할 규정과 운영 정책이 정해야 한다.

색인과 랭킹의 병목은 후보 수에서 생긴다

문서 기준 샤딩은 문서 ID의 해시값으로 색인을 고르게 나눈다. 쓰기 분산과 용량 균형은 쉽지만 대부분의 질의가 여러 샤드로 펼쳐진다. 반대로 용어 기준 샤딩은 단어별 Posting을 나눠 일부 질의의 대상 샤드를 줄일 수 있지만, 흔한 단어에 요청이 몰리고 여러 단어의 교집합을 네트워크로 계산해야 한다. 여기서 핫키는 요청이 유난히 몰려 한 서버를 과부하시키는 키이며, 흔한 단어가 한 조각을 압박하는 문제를 설명한다.

선택안은 문서 기준 샤딩을 기본으로 하고 언어·기간·콘텐츠군처럼 질의에서 안전하게 제외할 수 있는 범위만 앞단에서 거른다. 각 샤드는 넓은 후보에 단어 일치도, 문서 품질, 언어와 기본 신선도처럼 싼 신호를 적용한다. 조정기가 모은 상위 일부에만 복잡한 의미 일치 모델과 출처 다양화를 적용한다. 싸게 넓게 찾고 비싸게 좁게 다시 매기는 이유는 Vespa 공식 문서가 설명하는 것처럼 첫 단계 비용이 후보 수와 계산 복잡도에 함께 커지기 때문이다.

주요 병목과 측정값은 다음처럼 연결한다.

• 수집은 느린 외부 서버, 큰 응답, 끝없이 생기는 URL과 문서 해석 비용에 막힌다. 호스트별 동시성, 최대 본문 크기, 허용 파일 형식, URL 패턴별 예산과 재시도 상한을 둔다.
• 색인은 한국어 단어 분리 계산, 세그먼트 쓰기와 병합 입출력에 막힌다. 작은 세그먼트를 너무 자주 공개하면 새 글은 빨리 보이지만 파일 수와 병합 비용이 는다.
• 질의는 흔한 단어의 긴 Posting, 모든 샤드로 가는 요청, 느린 복제본과 비싼 2단계 모델에 막힌다. K는 각 샤드가 돌려줄 후보 개수의 상한이며, 이를 제한하고 검색하지 않아도 될 샤드를 미리 제외하며 복제본의 최근 응답 시간과 단계별 시간 예산을 적용한다.
• 조정기는 설계 가정상 요청마다 100샤드×1,000개인 10만 후보를 그대로 받으면 병목이 된다. 로컬 K와 2단계 후보 상한을 고정하고 조정기 자체는 요청 상태를 저장하지 않은 채 여러 대로 늘린다.

운영 지표는 CPU(Central Processing Unit, 중앙 처리 장치) 사용률보다 사용자가 보는 결과에 붙인다. 검색 p50·p95·p99, 샤드 시간 초과율, 부분 응답률, 결과 없음 비율, 중복률, 클릭 후 404 비율, 게시부터 검색 가능까지 걸린 시간, 삭제 접수부터 모든 화면 차단까지 걸린 시간을 본다.

사용자가 먼저 보는 실패에서 복구를 시작한다

사용자가 보는 현상	감지	즉시 완화	복구와 일치 여부 확인
검색이 오래 걸린다	전체·샤드 p95/p99, 대기열, 시간 초과	느린 샤드 중단, 2단계 후보 축소, 캐시 또는 부분 결과	복제본 교체·재분배 뒤 같은 질의의 샤드 완결률과 순위 차이 확인
같은 내용이 반복된다	결과군별 내용 해시·simhash 중복률	응답에서 같은 문서군 접기	대표 URL 군 재계산, 문서 ID 교체, 캐시 무효화
새 글이 보이지 않는다	발견·수집·색인·서비스 시각별 지연	신선도 우선 대기열, 사이트맵 재처리	누락 단계 재실행 뒤 색인 세대와 실제 결과 확인
삭제 페이지가 보인다	클릭 후 404/410, noindex, 삭제 목표 시간 초과	온라인 삭제 필터, 캐시 즉시 무효화	모든 샤드·복제본·요약 저장소의 삭제 버전 대조
결과 일부가 빠진다	partial 비율과 샤드 오류	가능한 결과를 제공하고 재시도	같은 색인 세대에서 결과 수와 상위 순위 비교
오래된 제목·요약이 보인다	본문 해시와 요약 버전 불일치	문서 캐시 우회, 오래된 요약 숨김	재수집·요약 재생성 뒤 본문·색인·캐시 버전 대조

장애 기록은 감지에서 끝내지 않는다. 즉시 노출을 줄인 뒤 실패한 작업을 재실행하고, 마지막에는 문서와 색인·캐시 버전이 같은지 확인한다. 잘못된 새 색인이 배포되면 읽기 위치를 이전 세대로 돌리고 누락 이벤트를 다시 처리한 뒤 표본 질의와 문서 수를 대조한다.

캐시 수명과 삭제 이벤트를 함께 써야 오래된 상태가 끝난다

TTL(Time To Live)은 캐시를 자동 폐기하기 전 최대 수명이다. 이 글에서는 일반 검색 결과가 무한히 낡지 않게 하는 마지막 안전망으로 필요하다. TTL만 쓰면 그 시간 동안 속보와 삭제 결과가 오래되고, 이벤트 알림만 쓰면 알림이 유실됐을 때 낡은 값이 계속 남는다.

선택안은 짧은 TTL, 색인 세대가 포함된 캐시 키, 변경 이벤트를 함께 쓴다. 이벤트는 빠른 무효화 경로이고 TTL은 누락을 끝내는 경로다. 삭제는 여기에 응답 직전 온라인 필터와 원장 완료 확인을 더한다. 매 질의의 필터 조회와 감사 저장 비용이 들지만 사용자가 이미 지운 정보를 캐시 수명 동안 보는 위험을 줄인다.

보안과 비용은 수집 범위와 랭킹 깊이를 제한한다

수집기는 Server-Side Request Forgery(서버 측 요청 위조)를 막아야 한다. 이는 공격자가 수집기를 사설망 접근 도구로 악용하는 공격이며, 공개 웹만 가져오도록 보호하려면 도메인 이름을 주소로 바꾸기 전후와 리디렉션 때마다 사설·링크 로컬 주소를 차단해야 한다. 포트, 프로토콜과 응답 크기도 제한한다.

HTML(HyperText Markup Language, 웹문서 형식)과 PDF(Portable Document Format, 문서 파일 형식)·압축 파일은 외부에서 받은 입력이므로 신뢰하지 않는다. 스크립트를 실행하지 않는 격리된 해석기, 압축 해제 비율 제한과 악성 파일 검사를 둔다. robots.txt에 적힌 경로는 공개되므로 민감한 자료는 로그인과 권한 검사로 보호해야 한다.

검색 로그에는 건강·정치·위치·개인식별 정보가 섞일 수 있다. 원문 질의와 IP의 분리·축약, 최소 권한, 짧은 보존 기간과 삭제 처리 기준을 두고 모델 학습용 사용에는 별도 동의·익명화 조건을 정한다.

큰 비용은 원문 저장, 외부 대역폭, 한국어 분석과 문서 해석 CPU, 역색인 복제, 세그먼트 병합, 2단계 모델 추론에서 생긴다. 모든 문서를 같은 빈도로 다시 방문하거나 모든 후보에 비싼 모델을 적용하지 않는 것이 직접적인 비용 제어다.

대안은 빨라 보이는 정상 경로보다 실패 형태로 고른다

결정	선택안	더 단순한 대안의 장점	대안의 한계와 전환 조건
재수집	변경 확률·중요도·호스트 상태로 우선순위 결정	고정 주기는 구현과 예측이 쉽다	뉴스는 늦고 정적 문서는 낭비된다. 작은 초기 규모라면 고정 주기로 시작할 수 있다.
중복 대표	URL·리디렉션·canonical·본문 지문 결합	URL 정규화만 하면 저렴하다	다른 주소의 같은 본문을 놓친다. 유사도만 쓰면 별도 문서를 잘못 합칠 수 있다.
색인 분할	문서 기준과 안전한 앞단 분류	용어 기준은 일부 fan-out을 줄인다	인기 용어가 핫키가 되고 여러 단어 결합에 네트워크 비용이 든다.
분산 점수	샤드 로컬 1단계와 제한된 전역 재랭킹	전역 통계를 먼저 모으면 점수가 더 일관될 수 있다	왕복 시간과 비용이 는다. 희귀 질의 품질 문제가 측정될 때 확대한다.
색인 공개	작은 증분 세그먼트와 뒤쪽 병합	큰 일괄 처리는 검색 효율과 재현성이 좋다	새 글 노출이 늦다. 변경이 적은 내부 문서에는 일괄 처리가 단순하다.
캐시	TTL·세대 키·이벤트 무효화	TTL만 쓰면 단순하다	속보와 삭제가 TTL 동안 낡는다. 이벤트만 쓰면 유실 시 계속 남는다.
삭제	고우선 이벤트·온라인 필터·감사 원장	일반 색인 갱신에 맡기면 저렴하다	사용자·법적 위험과 완료 검증이 약하다. 삭제 목표가 느슨한 내부 검색에서만 단순화를 검토한다.
랭킹	싸게 넓게 찾고 비싸게 좁게 재정렬	단일 점수는 구현과 원인 분석이 쉽다	복잡한 모델을 모든 후보에 적용하면 지연과 비용이 급증한다.

Elasticsearch의 샤드 로컬 점수와 전역 통계 우선 방식, Vespa의 단계별 랭킹은 이 장단점을 보여주는 공개 구현 예시다. 특정 제품의 기본값이나 후보 수를 보편적인 정답으로 가져오지는 않는다.

확장은 사용자 지표가 한계를 넘을 때 한 경로씩 연다

1. 초기 단계: 수백만 문서까지 단일 검색 클러스터, 단순 호스트별 대기열, 일괄 색인과 기본 단어 일치 점수로 시작한다. 문서 ID와 삭제 이벤트는 처음부터 분리한다.
2. 성장 단계: 검색 p95나 저장 한계가 드러나면 문서 기준 샤딩과 복제본을 추가한다. 게시부터 검색 가능까지의 시간이 길어지면 증분 세그먼트와 변경 확률 기반 재수집을 연다.
3. 대규모 단계: fan-out 지연이 커지면 언어·콘텐츠군 앞단 분류, 불필요한 샤드 제외와 최근 상태가 좋은 복제본 선택을 도입한다. 삭제 완료가 흔들리면 전용 원장과 온라인 필터를 둔다. 수집·색인·질의 용량은 따로 늘린다.
4. 품질 최적화 단계: 인프라 용량만으로 해결되지 않는 결과 품질을 오프라인 관련성 평가와 온라인 사용자 지표로 확인한다. 그때 신선도 의도 분류, 출처 다양성, 한국어 질의 이해와 학습 랭커를 롤백 가능한 버전으로 추가한다.

선택한 설계의 중심은 검색 요청이 읽는 경로와 웹 문서가 바뀌는 경로를 분리하는 것이다. URL frontier는 사이트별 부하와 재방문 시점을 조절하고, 문서 기준으로 나눈 역색인은 저렴한 로컬 랭킹과 제한된 전역 재랭킹을 거친다. 일반 갱신에는 잠깐의 차이를 허용하되 삭제는 원장·온라인 필터·캐시 무효화로 먼저 막는다.

아직 정하지 못한 값도 분명하다. 실제 한국어 문서와 트래픽으로 샤드 수, 로컬 후보 K, 재수집 점수와 모델 비용을 측정하지 않았다. 구현 전에는 아래 표준과 공식 문서에서 robots 오류 처리, canonical·사이트맵의 신호 범위, 색인 갱신과 삭제 조건을 다시 확인한 뒤 작은 문서군에서 사용자 지표를 측정해야 한다.

참고 링크

• RFC 9309 — Robots Exclusion Protocol
• Google Search Central — 사이트맵 만들기 및 제출
• Google Search Central — Canonical URL 지정 방법
• Google Search Central — noindex로 색인 차단
• Google Search Central — 사이트의 페이지 삭제
• Apache Lucene 9.12.0 — Index API
• Elasticsearch — Search API
• Elasticsearch — Shard request cache
• Vespa — Phased Ranking
• Google 공식 블로그 — Caffeine 검색 색인