검색 인덱스는 캐시와 비슷해 보이지만 캐시보다 책임이 큽니다. 사용자는 검색 결과를 제품의 진실처럼 받아들이고, 운영자는 검색 화면으로 장애·정산·CS를 판단합니다. 따라서 검색 인덱스는 원본 데이터에서 재생성 가능한 파생 저장소이면서 동시에 사용자 경험을 직접 결정하는 읽기 모델입니다. 이 글은 Elasticsearch 기초, CDC Connector Lag와 Snapshot Recovery, Projection Lag와 Read Model Rebuild를 검색 운영 관점으로 묶어 정리합니다.

이 글에서 얻는 것

• 검색 인덱스를 단순 조회 최적화가 아니라 freshness SLO가 있는 파생 저장소로 설계할 수 있습니다.
• CDC, outbox, dual write, bulk backfill 중 어떤 동기화 방식을 고를지 기준을 잡을 수 있습니다.
• mapping 변경, synonym 변경, analyzer 변경 때 운영 검색을 멈추지 않고 새 인덱스로 전환하는 절차를 이해할 수 있습니다.
• 삭제 전파, 중복 반영, relevance 회귀, backfill 부하를 숫자로 관리하는 체크리스트를 가져갈 수 있습니다.

핵심 개념/이슈

1) 검색 인덱스의 진짜 문제는 조회 속도보다 “얼마나 늦게 맞는가"다

검색 엔진을 붙이는 이유는 보통 성능입니다. LIKE '%keyword%', 다중 필터, 정렬, nested 조건이 느려지면 별도 인덱스로 빼고 싶어집니다. 하지만 운영 품질은 성능만으로 결정되지 않습니다. 더 중요한 질문은 “원본 변경이 검색 결과에 언제 반영되는가"입니다.

예를 들어 상품 가격이 바뀌었는데 검색 결과 카드에는 10분 전 가격이 남아 있으면 사용자는 결제 화면에서 다른 금액을 봅니다. 주문 상태가 CANCELLED로 바뀌었는데 관리자 검색에는 PAID로 남으면 CS가 잘못 대응할 수 있습니다. 개인정보 삭제 요청 후 이름이 검색 인덱스에 남으면 단순 성능 문제가 아니라 규정 위반으로 이어집니다.

그래서 검색 인덱스에는 최소 세 가지 지연 기준이 필요합니다.

모든 검색이 1초 안에 맞아야 하는 것은 아닙니다. 콘텐츠 검색이나 분석 검색은 몇 분 지연을 허용할 수 있습니다. 반대로 권한, 가격, 재고, 결제 상태처럼 사용자가 바로 행동하는 필드는 검색 결과만 믿으면 안 됩니다. 이 경우 검색 결과는 후보 목록으로만 쓰고, 상세 화면이나 최종 액션에서는 원본 DB를 다시 확인해야 합니다.

2) 동기화 방식은 “쓰기 경로 신뢰성"과 “운영 복구성"으로 고른다

검색 인덱스를 갱신하는 방식은 크게 네 가지입니다.

실무 기본값은 outbox 또는 CDC입니다. 검색 인덱스가 비즈니스 판단에 쓰이면 dual write만으로는 복구성이 부족합니다. DB commit은 성공했는데 검색 색인이 실패한 경우, 어떤 변경이 누락됐는지 나중에 재생할 근거가 있어야 합니다. outbox는 애플리케이션이 도메인 이벤트를 명시적으로 발행한다는 점이 좋고, CDC는 기존 테이블 변경을 폭넓게 잡는 데 유리합니다.

의사결정 기준은 다음처럼 잡을 수 있습니다.

• 원본 변경량이 초당 100건 미만이고 검색 지연 5분을 허용하면 batch sync로 시작 가능
• 주문·결제·권한·CS 화면에 쓰이면 outbox/CDC를 우선 검토
• 검색 인덱스가 2개 이상 sink와 공유되면 CDC lag 대시보드를 필수로 둠
• 삭제·비공개 전파가 1분 안에 필요하면 soft delete 이벤트를 별도 우선순위 큐로 분리
• 재처리 기간은 최소 7일, 운영 감사가 있으면 30~90일 이상 보관

3) 리인덱싱은 “덮어쓰기"가 아니라 “새 인덱스 생성 후 alias 전환"이다

검색 인덱스는 mapping, analyzer, synonym, ranking feature가 바뀌면 전체 재생성이 필요할 수 있습니다. 여기서 운영 인덱스를 직접 비우고 다시 채우는 방식은 피해야 합니다. 중간에 실패하면 검색 결과가 반쯤 비고, rollback도 어렵습니다.

안전한 방식은 새 인덱스를 만들고 검증한 뒤 alias를 바꾸는 것입니다.

1. product-search-v20260701 같은 새 물리 인덱스 생성
2. 기존 원본 DB 또는 snapshot에서 bulk backfill
3. backfill 중 발생한 변경은 outbox/CDC로 새 인덱스에도 반영
4. 문서 수, 샘플 query, 핵심 필드 checksum, 삭제 문서 잔존율 비교
5. read alias를 일부 트래픽에서 새 인덱스로 canary
6. 이상 없으면 alias atomically switch
7. 구 인덱스는 24~72시간 read-only 보관 후 삭제

숫자 기준은 초기값으로 아래 정도가 현실적입니다.

• backfill 중 원본 DB CPU 추가 사용률: 20% 이하
• 검색 클러스터 indexing CPU: 평상시 대비 150% 이내
• bulk request 실패율: 0.1% 이하
• 핵심 query top 10 overlap: 90% 이상, 단 ranking 변경 의도는 별도 승인
• 삭제 문서 잔존율: 개인정보·비공개 데이터 0%, 일반 데이터 0.1% 이하
• cutover 전 새 인덱스 lag: 30초 이하

이 흐름은 Shadow Traffic과 Dark Launch와 비슷합니다. 새 검색 경로를 바로 신뢰하지 말고, 기존 결과와 나란히 비교해야 합니다. 다만 검색은 결과 순서가 완전히 같지 않을 수 있으므로 단순 equality보다 top N overlap, 필수 문서 포함 여부, 금지 문서 미노출 여부를 따로 봐야 합니다.

4) 삭제 전파는 검색 품질보다 더 엄격하게 다룬다

검색 인덱스 운영에서 가장 자주 과소평가되는 부분이 삭제입니다. 원본 DB에서 soft delete만 했는데 인덱스에는 문서가 남아 있거나, 권한이 바뀌었는데 검색 결과 필터가 예전 권한을 기준으로 동작하는 일이 생깁니다. 특히 개인정보, 비공개 게시글, 관리자 전용 데이터는 “조금 늦게 사라짐"도 사고가 될 수 있습니다.

삭제는 일반 업데이트와 다른 우선순위를 둬야 합니다.

• 삭제·비공개 이벤트는 별도 high-priority consumer로 처리
• 인덱스 문서에는 visibility, tenant_id, deleted_at, source_version을 포함
• 검색 API는 인덱스 필터와 애플리케이션 권한 검사를 모두 수행
• 삭제 이벤트 처리 실패는 DLQ에 묻지 않고 알람으로 올림
• 삭제 후 샘플 키워드 검색으로 잔존 여부를 검증

관련 기준은 Data Retention과 삭제 아키텍처를 같이 보면 좋습니다. 검색 인덱스는 원본 저장소보다 복구와 추적이 느슨해지기 쉬우므로, 삭제 전파 SLO를 별도 숫자로 관리해야 합니다.

실무 적용

1) 검색 인덱스 계약서를 만든다

검색 인덱스마다 아래 정보를 문서화합니다.

search_index_contract:
  name: product-search
  source_of_truth: product_db.products
  sync_method: cdc
  freshness_slo:
    update_p95: 60s
    delete_p95: 10s
  owner: commerce-platform
  alias:
    read: product-search-read
    write: product-search-write
  rebuild:
    source: db_snapshot + cdc_catchup
    rollback_window: 72h
  validation:
    doc_count_tolerance: 0.1%
    top10_overlap_min: 90%
    forbidden_doc_residual: 0

이 정도만 있어도 장애 대응이 달라집니다. “검색이 이상하다"가 아니라 “product-search의 update lag가 p95 8분으로 SLO를 넘었고, delete lag는 정상"처럼 말할 수 있습니다.

2) 대시보드는 indexing, query, 품질을 분리한다

검색 운영 대시보드는 쿼리 latency만 보면 부족합니다.

• indexing: lag, bulk failure rate, retry count, DLQ count
• query: p95/p99 latency, timeout rate, shard failure, empty result rate
• quality: top query zero-result rate, top N overlap, forbidden residual count
• capacity: heap, CPU, disk watermark, merge pressure, refresh cost
• rebuild: progress percent, catch-up ETA, alias switch readiness

알람 우선순위는 삭제 실패 > indexing 완전 중단 > 운영 화면 lag 초과 > query latency > relevance 회귀 순으로 둡니다. relevance는 중요하지만, 비공개 문서 노출이나 원본 변경 누락보다 먼저 볼 수는 없습니다.

3) 검색 API는 최종 권한 판단을 인덱스에만 맡기지 않는다

검색 엔진은 후보를 빠르게 찾는 데 강하지만, 최종 권한 판단까지 모두 맡기면 위험합니다. 인덱스 문서의 tenant_id나 visibility가 밀리면 권한이 깨질 수 있습니다. 따라서 민감 데이터는 검색 결과를 받은 뒤 애플리케이션에서 한 번 더 권한을 확인합니다. 비용이 걱정되면 상위 20~100건만 검증하고, 권한 실패율이 1%를 넘으면 인덱스 동기화 이상으로 알람을 올립니다.

페이지네이션도 주의해야 합니다. relevance score가 변하는 검색 결과에는 단순 offset이 흔들릴 수 있습니다. 긴 검색 세션이나 관리자 화면은 point-in-time 검색, snapshot token, search-after를 검토합니다. 이 기준은 Cursor Pagination 일관성 플레이북과 연결됩니다.

트레이드오프/주의점

첫째, 검색 인덱스를 정교하게 만들수록 원본 DB 부담은 줄지만 운영해야 할 데이터 제품이 늘어납니다. mapping version, analyzer version, synonym 배포, shard 수, refresh interval, backfill worker까지 모두 릴리즈 대상입니다. 작은 서비스에서는 RDB 인덱스와 제한된 검색 조건으로 충분할 수도 있습니다.

둘째, relevance 개선은 기능 배포보다 회귀 검증이 어렵습니다. 정확도는 “더 좋아졌다"로 끝나지 않습니다. 상위 검색어, 매출 기여 검색어, CS 검색어, 금지어, 비공개 문서, 다국어 케이스를 fixture로 만들어야 합니다. ranking 변경은 최소 1~5% canary로 시작하고, zero-result rate와 클릭률이 동시에 나빠지면 되돌리는 편이 안전합니다.

셋째, refresh interval을 무작정 줄이면 최신성은 좋아지지만 indexing 비용이 커집니다. 실시간성이 필요한 필드만 우선 큐로 보내고, 나머지는 30초~5분 지연을 허용하는 편이 비용 대비 효과가 좋습니다.

넷째, 검색 인덱스를 원본처럼 오래 보관하면 삭제·보안·비용 문제가 커집니다. 재생성 가능한 데이터라면 raw snapshot과 이벤트 로그 보존 정책을 기준으로 인덱스 자체는 짧게 유지하는 편이 낫습니다.

의사결정 우선순위는 비공개/삭제 전파 > 원본 정합성 > 운영 검색 신뢰도 > relevance 개선 > 비용 최적화입니다. 검색이 빨라도 틀린 문서를 보여주면 제품 신뢰가 먼저 깨집니다.

체크리스트 또는 연습

체크리스트

• 검색 인덱스별 source of truth, owner, freshness SLO가 있다.
• update lag와 delete lag를 별도 지표로 본다.
• mapping/analyzer 변경은 새 인덱스 생성 후 alias 전환으로 처리한다.
• cutover 전 문서 수, top N overlap, 금지 문서 잔존율을 검증한다.
• 삭제·비공개 이벤트는 일반 업데이트보다 높은 우선순위로 처리한다.
• 검색 결과의 최종 권한 판단을 인덱스 필터에만 맡기지 않는다.
• 구 인덱스 rollback window와 삭제 조건이 문서화되어 있다.

연습

1. 운영 중인 검색 화면 하나를 골라 update lag와 delete lag 허용치를 초 단위로 적어 보세요. 둘이 같은 값이면 정말 같은 위험인지 다시 검토합니다.
2. 상품 검색 인덱스 mapping을 바꾼다고 가정하고, v2 인덱스 생성부터 alias switch까지 10단계 runbook을 작성해 보세요.
3. 삭제된 문서가 검색에 남는 사고를 가정하고, 탐지 지표·즉시 조치·재처리 범위·고객 영향 확인 방법을 분리해 적어 보세요.

관련 글

• Elasticsearch 기초
• CDC Connector Lag와 Snapshot Recovery
• Projection Lag와 Read Model Rebuild
• Data Retention과 삭제 아키텍처
• Cursor Pagination 일관성 플레이북