구글이 0.3초 만에 검색 결과를 보여주는 방법 (그들은 속이고, 당신도 그래야 합니다)
Source: Dev.to
실시간 검색의 착각
검색 버튼을 누를 때 실제로 인터넷을 검색하는 것이 아닙니다. 구글이 미리 계산해 둔 인터넷 인덱스를 검색하는 것이며, 이는 완전히 다른 개념입니다.
도서관에 백만 권의 책이 있는데 누군가가 “jollof rice”가 언급된 모든 책을 찾아 달라고 한다고 상상해 보세요. 모든 페이지를 뒤지는 데는 며칠, 몇 주가 걸릴 수 있습니다. 대신 미리 몇 달을 들여 인덱스라는 거대한 책을 만들 수 있습니다—도서관에 나오는 모든 단어와 그 단어가 들어 있는 책과 페이지를 모두 나열한 책이죠.
누군가가 “jollof rice”를 찾으면, 인덱스의 “jollof” 섹션을 열어 해당 단어가 들어 있는 책과 페이지 번호를 확인하고, “rice” 섹션도 같은 방식으로 확인한 뒤 두 리스트에 모두 나타나는 책을 찾아 몇 초 만에 답을 제공할 수 있습니다. 질문이 들어오기 전에 이미 어려운 작업을 해 놓은 것이죠.
구글이 하는 일도 바로 이것이며, 규모만 지구 전체 수준으로 확장된 것입니다.
검색 시 실제로 일어나는 일
300밀리초 안에 일어나는 과정을 단계별로 살펴보겠습니다:
- 프론트‑엔드 서버 (GFE) – 사용자의 쿼리는 전 세계에 분산된 구글 프론트‑엔드 서버에 도달합니다. 예를 들어 라고스에 있다면 서아프리카 GFE가 담당합니다.
- 맞춤법 교정 – 구글은 오타를 검사하고 필요하면 자동 교정을 수행합니다. 이 과정은 구글 내부 인프라인 Borg(쿠버네티스의 전신)에서 실행됩니다.
- 인덱스 샤드 – 교정된 쿼리는 구글 인덱스 샤드에 전달됩니다. 인덱스는 전 세계 데이터센터에 걸쳐 수천 개의 샤드로 나뉘어 있습니다. 각 샤드는 역인덱스의 일부와 실제 문서 데이터를 보유합니다.
- Top‑k 가져오기 – 각 관련 샤드는 쿼리와 일치하는 상위 약 1,000개의 문서를 빠르게 가져옵니다. 인덱스는 이미 정렬되어 있어 이 조회가 최적화되어 있습니다.
- 랭킹 – 모든 결과는 구글 랭킹 시스템으로 전달되며, 위치, 검색 이력, 최신성, 백링크, 모바일 친화성, 페이지 속도 등 200가지가 넘는 신호를 사용해 밀리초 안에 정렬됩니다.
- 포맷팅 – 상위 10개의 결과가 포맷팅되어 브라우저로 반환됩니다. 전체 과정은 0.5초 미만에 끝납니다.
핵심 인사이트: 구글은 실시간으로 수십억 페이지를 검색하는 것이 아니라, 백그라운드에서 지속적으로 업데이트되는 미리 계산된 인덱스에서 결과를 찾아내는 것입니다.
역인덱스: 구글의 비밀 무기
역인덱스는 전체 문서를 저장하는 대신 단어와 그 단어를 포함하는 문서 목록을 저장합니다.
일반 저장 방식
Document 1 contains “I love jollof rice”역인덱스
- “jollof” appears in: Document 1, Document 2
- “rice” appears in: Document 1
- “Lagos” appears in: Document 2
누군가가 “jollof Lagos”를 검색하면 시스템은 즉시 두 단어가 모두 포함된 문서는 Document 2뿐이라는 것을 알 수 있습니다—문서를 스캔할 필요가 없습니다.
구글의 역인덱스는 수백억 개의 웹 페이지와 수조 개의 단어를 추적합니다. 미리 계산되고 수천 대의 서버에 샤딩되어 있기 때문에 조회 속도가 매우 빠릅니다.
증분 인덱싱: 구글이 최신 상태를 유지하는 방법
웹은 끊임없이 변합니다—새 페이지가 생기고, 기존 페이지가 업데이트되며, 사이트가 사라집니다. 매번 전체 인덱스를 처음부터 다시 만드는 것은 불가능합니다.
구글은 증분 인덱싱을 사용합니다:
- 크롤러가 지속적으로 웹을 탐색하며 새롭거나 변경된 콘텐츠를 찾습니다.
- 변화가 감지되면 인덱스의 해당 부분만 업데이트합니다.
- 인기 뉴스 사이트는 몇 분마다 크롤링되고, 작은 사이트는 며칠 혹은 몇 주에 한 번씩 크롤링됩니다.
인덱스가 완벽하게 최신 상태는 아니지만, 사용자는 차이를 거의 느끼지 못합니다. 속보는 몇 분 안에 검색 결과에 반영되고, 작은 블로그 글은 몇 시간에서 며칠 정도 걸릴 수 있습니다.
왜 99 %의 앱이 느린가
대부분의 애플리케이션은 매 요청마다 전체 데이터베이스 스캔이나 복잡한 계산을 수행하기 때문에 느립니다. 구글의 접근 방식은 정반대입니다: 가능한 모든 것을 미리 계산해 두는 것이죠.
예시: 배달 앱
느린 접근 방식
- 사용자가 앱을 연다.
- 앱이 사용자의 위치를 가져온다.
- 앱이 데이터베이스에 질의한다: “모든 식당을 찾고, 거리 계산을 하고, 5 km 이내로 필터링하고, 평점 순으로 정렬해 줘.”
- 데이터베이스가 수천 행을 스캔하고 거리 계산을 수행한 뒤 몇 초 후에 결과를 반환한다.
구글 스타일 접근 방식
- 몇 분마다 주요 동네별로 어느 식당이 가까운지 미리 계산한다.
- 이 리스트를 빠른 메모리(Redis 등)에 저장한다.
- 사용자가 앱을 열면 해당 동네에 대한 미리 계산된 리스트를 조회한다.
- 결과가 수백 밀리초 안에 나타난다.
비싼 작업(거리 계산, 필터링, 정렬)은 요청 시점이 아니라 백그라운드 작업으로 옮겨집니다.
미리 계산이 중요한 실제 사례
- YouTube 추천 – 알고리즘이 백그라운드에서 지속적으로 실행되어 수억 명의 사용자에 대한 추천 리스트를 업데이트합니다. 앱을 열면 몇 분 혹은 몇 시간 전에 미리 계산된 리스트를 보게 됩니다.
- Instagram 피드 – 팔로우 관계와 참여 이력을 기반으로 피드가 백그라운드에서 조립됩니다. 새로 고침은 미리 만든 피드를 가져오는 것뿐입니다.
- 이커머스 검색(Amazon) – 키워드, 카테고리, 속성별 역인덱스를 사용해 전체 상품 카탈로그를 스캔하지 않고 즉시 조회합니다.
- 은행 대시보드 – 계좌 잔액과 거래 내역이 대시보드용으로 집계·캐시되어 제공됩니다; 메인 거래 DB는 새로운 쓰기만 담당하고, 보고용 뷰는 미리 계산됩니다.
트레이드‑오프: 신선도 vs. 속도
미리 계산은 하나의 주요 트레이드‑오프를 동반합니다: 데이터가 약간 오래될 수 있다는 점입니다. 구글 인덱스가 10분 전에 업데이트됐고, 웹사이트가 5분 전에 바뀌었다면 검색 결과에 그 변화가 반영되지 않을 수 있습니다.
대부분의 경우 이는 충분히 감수할 수 있는 수준입니다. 사용자는 완벽한 실시간 정확성보다 빠른 응답을 기대합니다. 약간의 지연은 미리 계산된 인덱스가 제공하는 엄청난 성능 향상의 작은 대가에 불과합니다.