설계 경계: top-k의 인기도는 최종 안전 판단이 아닙니다. snapshot은 빠른 후보 집합을 제공하고, 정책 필터와 cache invalidation은 허용되지 않은 후보가 다시 보이는 시간을 줄이는 별도 책임입니다.
03 · BUILD / READ FLOW
정규화·빌드와 lookup·필터를 각각 복구 가능하게 둔다
# 흐름
1신호 수집
검색·선택·카탈로그 변경을 모으고 bot·비정상 요청을 후보 점수와 분리합니다.
2정규화·중복 제거
locale과 버전을 명시해 표면형·canonical text·후보 상태를 만듭니다.
3FST/Trie snapshot
검증된 후보와 제한된 top-k로 versioned artifact를 빌드·canary 배포합니다.
4cache → lookup
hot prefix cache를 먼저 보고 miss이면 locale shard에서 후보를 가져옵니다.
5정책·재정렬
삭제·safe-search·tenant 필터 후 신선도·품질을 적용하고 이벤트를 비동기로 남깁니다.
04 · TRADEOFFS
lookup 속도와 build·인덱스·정책 비용을 함께 비교한다
# 트레이드오프
FST는 빠르고 작지만 rebuild가 필요하고, 매 요청 검색은 신선하지만 비용이 큽니다. 안정 후보와 최신 delta를 나눠 읽기 지연과 정책 반영 시간을 함께 관리합니다.
선택
장점
제약
적용 판단
Trie terminal top-k
prefix lookup이 단순하고 빠름
prefix별 후보 복제가 메모리를 키움
명확한 prefix UX, 제한된 후보 사전
FST suggester
압축·빠른 lookup 가능
build, weight bucket, artifact 운영 필요
큰 준정적 사전, snapshot 배포 역량
search_as_you_type
prefix·infix와 검색 stack을 함께 사용
subfield·index size·query 비용 증가
다단어 문장, 기존 검색 인덱스 재사용
원문 매 요청 검색
변경 데이터 반영이 단순
keystroke마다 CPU·tail latency 발생
작은 카탈로그, 초기 제품
global top-k
cache 효율·설명이 쉬움
지역·맥락 relevance가 제한
privacy 우선 기본 결과
개인화 re-rank
문맥 적합성을 높일 여지
feature·동의·필터·실험 복잡도
명시된 동의와 안전 경계가 있을 때
05 · FAILURE MODES
빠른 입력 경로의 실패를 안전한 fallback으로 제한한다
# 장애 6가지
◈snapshot build 실패
새 후보가 배포되지 않거나 artifact 손상으로 shard가 시작하지 못합니다.
대응 · checksum·canary를 확인하고 이전 검증 version을 유지합니다. version skew가 정의된 범위인지 검증합니다.
≋hot prefix stampede
짧은 인기 입력이 cache miss와 동시 origin lookup을 증폭합니다.
대응 · single-flight, stale serve, cache replica, prefix별 제한. origin fan-in과 p99 회복을 확인합니다.
×정책 무효화 지연
삭제·금지·비공개 후보가 stale cache나 index에 남을 수 있습니다.
대응 · tombstone push, purge 재시도, fail-closed 범위. revoke-to-hide 시간과 표본 제거를 검증합니다.
!집계 오염·봇 조작
반복 요청이나 부정 click이 인기 점수와 후보 품질을 왜곡합니다.
대응 · source quarantine, abuse filter, aggregate rollback. baseline 대비 rank와 품질 지표를 확인합니다.
▣FST 메모리 압박
큰 artifact나 warm-up 때문에 OOM·tail latency·locale 실패가 발생합니다.
대응 · shard 분할, top-k 축소, 이전 artifact, overload fallback. RSS·headroom·p99를 확인합니다.
⌁re-ranker timeout
카탈로그·개인화 의존성이 늦어져 후보가 비거나 전체 요청이 지연됩니다.
대응 · timeout budget, circuit breaker, global top-k fallback. fallback ratio와 정책 오류를 확인합니다.
06 · OPERATIONS
개인정보, 관측, 비용은 인덱스 밖에서도 관리한다
# 운영
◉보안·개인정보
raw query와 계정·IP를 동일한 장기 로그에 묶지 않고, 개인화는 동의·권한·별도 저장 경계를 전제로 합니다. response에는 내부 weight와 feature를 보내지 않습니다.
raw query ≠ default trace
⌁관측 가능성
tier별 p99, prefix cache hit, index version skew, policy filter, revoke-to-hide, zero-result-after-filter, abuse reject를 분리해 봅니다.
suggest_latency_ms{tier}
₩비용 모델
FST/Trie RAM, snapshot build·배포, cache replica, event 집계, 정책 의존성, 개인정보 접근 통제가 비용을 만듭니다. 긴 TTL은 origin 비용과 철회 지연을 맞바꿉니다.
RAM + cache + build + egress
면접 모드 · 추가 질문06:00
“매일 수억 건의 키 입력을 받는 검색 자동완성을 설계해 보세요. Trie/FST와 cache를 어떻게 배포하고, 인기 점수·신선도·봇 조작·삭제와 개인정보를 어떤 순서로 다루겠습니까?”
후보 정본과 파생 indexlocale FST/Triehot prefix cachepolicy filter 우선versioned rollback
답변 구조 보기 6단계
query·엔터티·상품 중 무엇을 추천하는지, locale·safe-search·개인화·freshness 요구를 먼저 확인한다.
입력 이벤트와 후보 정본, 파생 prefix index, 정책 데이터를 구분하고 raw query를 recommendation path에서 직접 읽지 않는다고 설명한다.
Trie/FST top-k와 prefix cache를 기본 fast path로 제시하고, FST snapshot 배포·delta·rollback의 운영 계약을 말한다.
API에서 정규화, cache, index lookup, policy filter, 제한된 re-rank, 비동기 event 기록의 순서를 설명한다.
hot prefix, index 손상, invalidation 지연, bot 조작, memory pressure, dependency timeout의 감지·대응·복구 검증을 연결한다.
마지막으로 cache hit, p99, index version skew, revoke-to-hide, zero-result-after-filter, selection rate와 비용·개인정보 경계를 제시한다. 이번 선택: 완성 음절 접두사와 명시적 초성 검색을 별도 모드로 운영한다. 깨지는 신호: composition 중 요청 수가 늘거나 자모 중간값이 인기 후보에 나타난다. 다음 검증: Android·iOS·데스크톱 IME에서 “한국” 입력당 서버 요청 수와 초성 후보 정확도를 비교한다.