본문 바로가기
서비스 웹 서비스 개발 앱 개발 AI 알고리즘 개발 AI 컨설팅 AI 마케팅 프로젝트 인사이트 회사소개 고객게시판
데이터 아키텍처 8 MIN READ

저장했는데 검색에 안 나온다면: DB와 검색 색인의 정합성 운영법

원본 DB에는 새 문서가 있는데 검색 결과는 옛 내용일 수 있습니다. 색인 반영 지연, 삭제 누락, 변경 순서 역전까지 다루는 검색 운영 설계를 정리했습니다.

Category
데이터 아키텍처
Published
Read
8분
Author
네이처프랙탈
저장했는데 검색에 안 나온다면: DB와 검색 색인의 정합성 운영법 대표 이미지

관리자가 상품 설명을 수정했습니다. 상세 화면은 새 설명을 보여주는데 검색 결과에는 어제의 문장이 남아 있습니다. 어떤 경우에는 삭제한 문서가 여전히 검색됩니다. ‘검색 엔진이 느리다’고 뭉뚱그리기 쉽지만 문제는 데이터의 복제 경로에 있을 수 있습니다. 업무 DB와 검색 색인은 보통 서로 다른 저장소이며, 같은 순간에 같은 내용을 보장하지 않습니다. 이 차이를 제품 동작과 운영 지표로 관리해야 합니다.

저장 완료와 검색 가능을 구분한다

원본 DB의 트랜잭션이 끝난 뒤 색인 작업자가 변경을 읽고 검색 시스템에 보냅니다. 검색 시스템이 문서를 저장한 다음에도 실제 검색에 보이기까지는 내부 갱신 단계가 있을 수 있습니다. Elastic의 실시간에 가까운 검색 설명은 색인 작업과 검색 노출 사이에 refresh가 필요하다고 설명합니다. 따라서 ‘저장 성공’ 메시지 직후 검색 결과에 반드시 나온다고 약속할지, 잠시 지연을 허용할지 먼저 정해야 합니다.

사용자 경험에서는 방금 수정한 항목을 상세 화면에서 원본 DB로 즉시 확인하고, 검색 목록에는 ‘반영 중’ 상태를 보여줄 수 있습니다. 반대로 즉시 검색 노출이 핵심인 업무라면 완료 응답을 색인 확인 뒤에 보내는 등 더 비싼 보장을 선택해야 합니다. 모든 요청에 강제로 검색 색인을 새로 고치면 비용과 지연이 커질 수 있으므로 필요한 경로에만 적용합니다.

원본 저장과 색인 요청의 틈을 막는다

애플리케이션이 DB를 저장하고 곧바로 색인 API를 호출하는 방식은 간단하지만 둘 중 하나만 성공할 수 있습니다. DB 저장 뒤 프로세스가 죽으면 색인 요청이 사라집니다. 원본 변경 내역을 같은 트랜잭션 경계에서 기록하는 아웃박스나 DB 변경 캡처를 사용하면 복구할 단서를 남길 수 있습니다. 다만 전송은 다시 시도될 수 있으므로 색인 작업은 중복 요청에 안전해야 합니다.

변경 순서도 중요합니다. ‘승인’ 뒤 ‘취소’가 일어났는데 취소 이벤트가 먼저 색인되고 오래된 승인 이벤트가 나중에 도착하면 결과가 거꾸로 됩니다. 원본 레코드의 버전 또는 갱신 순서를 색인 문서에 함께 저장해 오래된 변경이 새 상태를 덮지 못하게 합니다. Elasticsearch의 동시성 제어 문서도 비동기 변경이 순서 밖으로 도착할 수 있음을 전제로 설명합니다.

원본 데이터베이스의 변경이 이벤트와 색인 작업자를 거쳐 검색 인덱스에 반영되는 순서
DB 저장 완료와 검색 가능 시각 사이에는 별도의 동기화 단계가 있습니다.

삭제와 권한 변경이 더 위험하다

신규 문서 누락은 사용자가 못 찾는 문제지만, 삭제 또는 권한 변경 누락은 보여서는 안 되는 정보가 검색될 수 있다는 뜻입니다. 원본에서 삭제된 문서를 색인에서도 지우는 이벤트가 반드시 전달돼야 합니다. 삭제 기록을 곧바로 완전히 없애면 색인 작업자가 어떤 문서를 지워야 하는지 알 수 없어 ‘삭제 표식’이나 변경 로그가 필요할 수 있습니다. 검색 결과의 권한 필터도 원본 정책을 따라가야 합니다.

고객사별로 데이터가 분리된 SaaS라면 색인 문서에도 테넌트 식별자를 명시하고 모든 검색 요청에서 필터를 강제합니다. 검색에서 나온 ID를 상세 API로 다시 열 때도 권한 검사를 반복합니다. 색인은 조회 성능을 위한 복제본이지 보안의 최종 판정자가 아닙니다.

주기적 대조 없이는 조용한 누락을 모른다

동기화 작업의 성공 건수만 보면 놓친 메시지는 보이지 않을 수 있습니다. 원본과 색인의 문서 수, 샘플 ID, 버전, 마지막 반영 시각을 비교합니다. 테넌트나 날짜 구간별로 차이를 찾고, 차이가 있는 문서만 재색인할 수 있게 합니다. 일정 주기의 전체 재동기화는 오래된 누락을 회복하는 장치가 됩니다. Elastic의 콘텐츠 동기화 문서도 증분 동기화와 전체 동기화의 역할을 구분합니다.

원본과 색인에서 누락·오래된 값·삭제 누락을 비교하고 복구하는 절차
정합성 점검은 새 문서뿐 아니라 수정과 삭제까지 비교해야 합니다.

운영 체크리스트

  • 저장 완료와 검색 반영 완료를 사용자에게 어떻게 구분할지 정했는가?
  • DB 저장 뒤 색인 요청이 유실돼도 다시 찾을 수 있는가?
  • 중복·역순 변경이 옛 문서를 되살리지 않는가?
  • 삭제와 권한 변경이 검색 결과에 반영되는가?
  • 원본과 색인의 차이를 주기적으로 대조하고 복구할 수 있는가?

검색 품질은 단어를 잘 찾는 것만이 아닙니다. 사용자가 볼 수 있어야 할 최신 데이터만 보여주는 정합성도 검색 서비스의 일부입니다.

#검색색인 #검색인덱스 #데이터정합성 #CDC #색인지연 #Elasticsearch #재색인 #데이터아키텍처 #검색운영 #변경동기화

검색 데이터 데이터 아키텍처 시스템 통합

/ 다음 단계

이런 문제, 직접 겪고 계신가요?

글로 정리한 방법을 실제 환경에 맞춰 적용하는 일까지 함께 하겠습니다.

영업일 기준 3일 이내 회신 · 상담 및 범위 견적 무료