MongoDB Atlas를 쓰다 보면 컬렉션 화면에서 `Indexes`와 `Search Indexes`라는 두 가지 메뉴를 보게 된다. 이름이 비슷해서 같은 기능의 확장판처럼 느껴질 수 있지만, 실제로는 해결하는 문제가 꽤 다르다. 특히 검색 기능을 붙이려는 시점에는 이 차이를 정확히 이해하지 못하면 방향을 잘못 잡기 쉽다.
이 글은 다음 질문에 답하는 형태로 정리했다.
- 일반 `Indexes`와 `Search Indexes`는 무엇이 다른가?
- `Atlas Search`와 `Vector Search`는 어떻게 구분해야 하는가?
- `M10` 클러스터에서도 Atlas Search를 사용할 수 있는가?
- 왜 앱을 배포했다고 해서 Search Index가 자동으로 생기지 않는가?
- Atlas 웹 콘솔과 MongoDB Compass 중 어디에서 작업하는 것이 맞는가?
일반 `Indexes`는 데이터 조회를 빠르게 만드는 기본 인덱스다
MongoDB의 일반 인덱스는 우리가 보통 데이터베이스 최적화에서 떠올리는 인덱스다. `slug`로 문서를 하나 찾거나, `createdAt` 기준으로 최신 글을 정렬하거나, `category`로 필터링하는 쿼리를 빠르게 만들 때 사용한다.
대표적인 예시는 다음과 같다.
{ slug: 1 }
{ createdAt: -1 }
{ category: 1, createdAt: -1 }이런 인덱스는 `find`, `sort`, `range query`, `exact match` 같은 쿼리에 강하다. 다시 말해 "어떤 필드 값을 기준으로 빨리 찾을 것인가"에 최적화돼 있다.
문제는 일반 인덱스만으로는 검색창 UX를 충분히 만들기 어렵다는 점이다. 예를 들어 아래 요구사항은 금방 한계에 부딪힌다.
- 제목 부분일치 검색
- 태그와 요약을 함께 검색
- 검색어 자동완성
- 검색 결과 relevance 순위
- 언어 분석기 기반 토큰화
그래서 많은 팀이 처음에는 `$regex`로 검색을 흉내 내다가, 데이터가 쌓이면서 느려지고 결과 품질도 아쉬워지는 경험을 하게 된다.
`Search Indexes`는 전문 검색을 위한 별도 인덱스다
Atlas의 `Search Indexes`는 일반 MongoDB 인덱스와 별개의 검색 인덱스다. 이 인덱스는 `$search`, `$searchMeta` 같은 Atlas Search 전용 연산자와 함께 사용된다.
Search Index의 핵심은 단순히 "빠르다"가 아니라, 검색이라는 문제를 더 잘 푼다는 데 있다.
- 텍스트 분석기(analyzer)를 설정할 수 있다
- 부분일치와 자동완성을 지원할 수 있다
- 검색 결과에 점수(score)를 부여할 수 있다
- 여러 필드에 서로 다른 가중치를 줄 수 있다
- 필터와 검색을 함께 조합할 수 있다
예를 들어 기술 블로그 검색이라면 다음과 같은 요구가 자연스럽다.
- 제목이 일치하면 가장 위에 보여주기
- 태그가 일치하면 가중치 높게 주기
- 요약은 보조 점수만 부여하기
- 책 리뷰라면 출판사도 검색 대상에 포함하기
이런 요구는 일반 인덱스보다 Search Index에서 훨씬 자연스럽게 모델링된다.
`Indexes`와 `Search Indexes`는 대체 관계가 아니라 역할 분담 관계다
실무에서 가장 많이 생기는 오해는 "Search Index를 만들면 일반 인덱스는 필요 없어지는가?"라는 질문이다. 답은 아니다.
두 인덱스는 서로 다른 문제를 푼다.
일반 `Indexes`가 필요한 경우:
- 상세 페이지 조회
- 고유값 조회
- 정렬 최적화
- 카테고리 필터
- 운영 쿼리 전반
`Search Indexes`가 필요한 경우:
- 검색창
- 검색 결과 랭킹
- 자동완성
- 복합 텍스트 검색
- relevance 기반 검색 UX
즉 일반 인덱스는 CRUD와 목록/상세 성능을 담당하고, Search Index는 검색 경험을 담당한다고 이해하는 편이 정확하다.
`Atlas Search`와 `Vector Search`는 같은 것이 아니다
이 부분도 헷갈리기 쉽다. 특히 Atlas UI나 Compass에서 `Search`와 `Vector Search`를 나란히 보게 되면 더 그렇다.
Atlas Search란?
일반적인 검색창을 위한 기능이다.
- 제목 검색
- 태그 검색
- 요약 검색
- 자동완성
- 부분일치
- relevance ranking
즉 사용자가 검색창에 `"react server actions"`나 `"C++"` 같은 키워드를 입력했을 때 잘 동작해야 하는 기능은 Atlas Search가 맡는다.
Vector Search란?
의미 기반 검색을 위한 기능이다.
- 비슷한 글 추천
- 문맥상 유사한 문서 찾기
- 임베딩 기반 검색
- 자연어 질의와 문서 의미 매칭
이건 검색창 대체재라기보다 추천, RAG, 시맨틱 탐색 쪽에 가깝다. 임베딩 생성 파이프라인도 필요하다. 따라서 대부분의 콘텐츠 사이트에서는 먼저 `Atlas Search`를 붙이고, 이후 추천 시스템이나 의미 검색이 필요할 때 `Vector Search`를 검토하는 순서가 맞다.
Atlas Search는 `M10`부터 사용할 수 있다
운영 비용이나 티어와 관련해서도 자주 질문이 나온다. 결론부터 말하면, Atlas Search는 `M10` 이상의 dedicated cluster에서 사용할 수 있다.
왜 코드 배포만으로 끝나지 않을까?
일반 MongoDB 인덱스는 애플리케이션 코드나 마이그레이션 로직을 통해 어느 정도 자동화하는 경우가 많다. 하지만 Atlas Search Index는 별도의 Atlas Search 인덱스 리소스이기 때문에, 애플리케이션을 배포했다고 해서 자동으로 생성되지 않는다.
이 차이는 운영 단계에서 중요하다.
보통 완료 절차는 다음과 같다.
1. 앱 코드에 `$search` 쿼리를 반영한다.
2. Atlas 콘솔 또는 Compass에서 Search Index를 생성한다.
3. 인덱스 상태가 `Ready` 또는 `Active`가 될 때까지 기다린다.
4. 실제 검색 테스트를 수행한다.
즉 "코드 반영 완료"와 "Search Index 운영 반영 완료"는 같은 말이 아니다.
코드가 준비돼 있어도 Search Index가 없으면
- 검색 기능은 fallback 로직으로 동작할 수는 있다
- 하지만 Atlas Search의 성능/품질 이점은 아직 적용되지 않는다
MongoDB Compass에서 설정하는 방법
- Atlas 클러스터여야 한다
- `M10` 이상이어야 한다
- MongoDB 7.0+ 환경이어야 한다
Compass에서는 컬렉션의 `Indexes` 탭에서 `Create`를 누른 뒤 `Search Index`를 선택하는 방식으로 생성할 수 있다. 이때 보이는 일반 인덱스 목록과 Search Index는 같은 메뉴 아래에 있지만, 실제로는 다른 유형의 인덱스라는 점을 기억하면 된다.
인덱스 상태는 어떻게 읽어야 할까?
Search Index를 만들면 보통 다음 상태를 보게 된다.
- `Pending`
- Atlas가 아직 인덱스 빌드를 시작하지 않은 상태
- `Building` 또는 `Build in Progress`
- 인덱스 생성 중
- `Ready` 또는 `Active`
- 쿼리에서 사용할 수 있는 상태
컬렉션이 크지 않다면 보통 수분 내에 끝나는 경우가 많지만, 고정된 시간 보장은 없다. 장시간 `Pending`에 머물면 상태 상세를 확인하는 편이 좋다.
실무에서 기억하면 좋은 판단 기준
일반 `Indexes`는 데이터 조회를 빠르게 만들기 위한 기본 인덱스이고, `Search Indexes`는 검색 경험 자체를 설계하기 위한 전문 검색 인덱스다.
그래서 아래 판단 기준이 유효하다.
- `slug`, `createdAt`, `category` 같은 조회/정렬 문제라면 일반 인덱스를 먼저 본다
- 검색창, 자동완성, relevance 정렬 문제라면 Search Index를 본다
- 의미 검색이나 추천 문제라면 그 다음에 Vector Search를 본다
- Atlas Search는 `M10`부터 시작할 수 있다
- 코드 배포만으로 Search Index가 자동 생성되지는 않는다