정규화된 입력과 locale에 맞는 query·엔터티를 제한된 k개로 반환합니다.
검색 자동완성
시스템 설계
후보가 빨리 뜨는 것만으로 좋은 자동완성은 아닙니다. 한국어 입력 상태를 구분하고, 인기 신호를 쓰더라도 삭제·정책 변경이 추천보다 먼저 반영되게 해야 합니다.
개념 이해인덱스·캐시정책·안전면접 답변진도 저장
30초 핵심 요약
IME 조합 중간값, 완성 음절, 초성 검색을 같은 입력으로 처리하지 않습니다. 안정 후보는 FST에서 읽고 최신 변화는 작은 delta로 보완하며, 삭제·차단 정책을 최종 후보보다 먼저 적용합니다.
Fast pathprefix cache + FST/Trie
Rankingtop-k + freshness
Safetypolicy before response
01 · REQUIREMENTS
# 요구사항빠른 제안보다 노출 경계를 먼저 정한다
추천 후보는 전체 검색 결과가 아닙니다. 어떤 locale의 query·엔터티를 보여 줄지, 개인화가 가능한지, 삭제와 safe-search를 어떤 시간 안에 반영할지를 계약으로 분리합니다.
키 입력마다 full scan을 하지 않고 cache와 작은 index lookup에 예산을 둡니다.
삭제·비공개·tenant·safe-search 필터가 인기도보다 먼저 후보를 제거합니다.
의존성이 불명확할 때 무관한 인기어 대신 빈 배열 또는 명시된 fallback을 반환합니다.
02 · HIGH-LEVEL DESIGN
# 아키텍처후보 생산과 키 입력의 읽기 경로를 분리한다
검색·선택 신호와 카탈로그·운영 정책은 builder가 검증한 후보로 모읍니다. 클라이언트 요청은 cache와 FST/Trie를 거쳐 작은 후보를 얻고, 정책을 적용한 뒤에만 재정렬합니다.
자동완성의 snapshot·delta와 read path SVG DIAGRAM · normalize → lookup → filter → rank
설계 경계: top-k의 인기도는 최종 안전 판단이 아닙니다. snapshot은 빠른 후보 집합을 제공하고, 정책 필터와 cache invalidation은 허용되지 않은 후보가 다시 보이는 시간을 줄이는 별도 책임입니다.
한국어 IME 조합과 초성 검색을 어떤 입력 모드로 나눌 것인가?
예시 요청량
6억/day
계산 결과
예시 피크
약 8.3만 rps
계산 결과
예시 후보 수
locale별 1,500만
설계 가정
compositionend 완성 음절 + 별도 초성 index mode
IME 조합 중간값은 서버 요청과 인기 집계에서 제외합니다. 완성된 음절은 일반 FST prefix로, 확정된 자음열은 허용된 엔터티의 별도 초성 키로 조회합니다.
선택 이유
- 한글 조합 과정의 불필요한 요청과 자모 중간값 오염을 줄입니다.
- 완성 음절과 초성 후보가 같은 cache key·정규화 규칙에서 충돌하지 않습니다.
- 초성 확장을 엔터티에 제한해 후보 폭과 메모리 증가를 통제합니다.
모든 input 이벤트를 같은 prefix로 조회·집계
IME 조합 중간 자모가 검색어로 학습되고 요청 수가 늘며 “한국”과 “ㅎㄱ”의 후보·정책 의미가 섞입니다.
감수한 단점
- 클라이언트가 composition 이벤트와 확정 입력을 정확히 구분해야 합니다.
- 초성 보조 인덱스는 빌드·메모리·정책 무효화 비용을 추가합니다.
- Android·iOS·데스크톱 입력기 차이를 실제 기기에서 검증해야 합니다.
03 · BUILD / READ FLOW
# 흐름정규화·빌드와 lookup·필터를 각각 복구 가능하게 둔다
검색·선택·카탈로그 변경을 모으고 bot·비정상 요청을 후보 점수와 분리합니다.
locale과 버전을 명시해 표면형·canonical text·후보 상태를 만듭니다.
검증된 후보와 제한된 top-k로 versioned artifact를 빌드·canary 배포합니다.
hot prefix cache를 먼저 보고 miss이면 locale shard에서 후보를 가져옵니다.
삭제·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
# 장애 6가지빠른 입력 경로의 실패를 안전한 fallback으로 제한한다
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에서 “한국” 입력당 서버 요청 수와 초성 후보 정확도를 비교한다.
“한국” 조합과 “ㅎㄱㄷ” 초성 검색을 다른 경로로 처리하기
Trie/FST 설명 전에 IME 입력 상태와 제품 범위를 정의합니다.
- compositionend 전에는 서버 요청·인기 집계를 멈춥니다.
- 완성 음절과 초성 검색에 별도 mode를 둡니다.
- 초성 index는 허용된 엔터티 유형에만 적용합니다.
세 플랫폼 IME에서 요청 수와 후보 정확도를 비교합니다.
- “한국” 한 번 입력의 서버 요청 수를 측정합니다.
- 자모 중간값이 인기 후보에 남지 않는지 확인합니다.
- mode별 cache hit·p99·정책 제거를 관측합니다.
TECHNICAL DOCUMENTS
기술 규격·공식 문서
- Elastic — Search suggesters: completion suggester와 context·duplicate·shard 관련 공식 문서.
- Elastic — Search-as-you-type field type: prefix/infix, subfield와 index-size trade-off 공식 문서.
- Apache Lucene — FSTCompletion API: finite-state completion과 weight bucket의 공식 API 문서.
- Apache Lucene — FSTCompletionLookup API: lookup adapter와 weight discretization 공식 API 문서.
- 이 페이지의 규모, top-k, TTL, popularity 식, SLO와 정책 기준은 학습용 설계 가정입니다. 실제 도입 전에는 현재 품질·안전·개인정보 정책과 locale별 analyzer, 부하·장애 실험으로 검증합니다.
이 문제와 이어지는 문서주변 장소 검색
후보를 좁히고 후처리하는 검색을 비교합니다.
REAL PROJECT CASE
실제 구현 해설 보기 →
AI Systems Atlas에서 이 개념 보기
FTS 기반 노드 검색과 화면 밖 결과를 관계 탐색으로 전환하는 읽기 경로를 확인할 수 있습니다.
TECHNICAL DOCUMENTS & CONTACT
문의·정정
사실 오류·출처 정정은 문의·정정 페이지로 알려 주세요.