상품 검색이나 사내 문서 검색을 구축할 때 Amazon OpenSearch Service와 Elastic Cloud Hosted가 함께 후보에 오릅니다. AWS 계정의 네트워크·권한 운영과 OpenSearch 기반 구성을 이어가려면 전자를, Elasticsearch·Kibana를 기준으로 쌓아 온 기능과 운영 방식을 유지하려면 후자를 먼저 검토할 수 있습니다. 결정은 브랜드보다 기존 검색 기능의 호환성, 같은 가용성에서의 비용, 고객사가 맡을 운영 책임으로 내려야 합니다.
1. 비교 범위를 먼저 맞추기: 관리형 도메인과 Hosted
이 글은 Amazon OpenSearch Service의 인스턴스 기반 관리형 도메인과 Elastic Cloud Hosted 배포를 비교합니다. 두 공급사의 Serverless 상품은 용량 관리와 청구 구조가 다르므로 이 표에 그대로 대입하지 않습니다. AWS 서비스 개요와 Elastic Cloud Hosted 안내에서 각 서비스가 운영하는 검색 엔진과 배포 형태를 먼저 확인하세요.
Elasticsearch와 OpenSearch는 공통된 역사와 비슷한 API 형태가 있지만 같은 제품이 아닙니다. 기존 클라이언트의 이름만 바꾸거나 엔드포인트만 교체해서 모든 쿼리·플러그인·권한 설정이 유지된다고 가정하면 이전 비용을 과소평가하게 됩니다. 아래 호환성 점검은 “어느 쪽이 더 빠르다”는 평가가 아니라 현재 애플리케이션을 옮길 때 필요한 검증 순서입니다.
2. 제품 선택에서 확인할 비교표
| 항목 | Amazon OpenSearch Service | Elastic Cloud Hosted |
|---|---|---|
| 기존 자산 | OpenSearch 쿼리·클라이언트·Dashboards 구성을 기준으로 검증 | Elasticsearch 쿼리·클라이언트·Kibana 구성을 기준으로 검증 |
| 접근 경로 | AWS 네트워크와 인증·접근 정책이 앱 배치와 맞는지 확인 | 선택한 클라우드·리전의 접근 경로와 인증 방식 확인 |
| 용량과 가용성 | 노드·저장소·가용 영역 구성과 복구 절차를 함께 산정 | 배포 크기·역할·가용 영역 구성과 복구 절차를 함께 산정 |
| 검색 품질 | 분석기·동의어·필터·정렬을 실제 한국어 문서로 시험 | 동일한 문서·질문·정답 기준으로 기능과 결과 시험 |
| 사용자 책임 | 색인 설계·접근 권한·변경 검증·서비스 수준 관리 | 색인 설계·접근 권한·크기 선택·업그레이드 검증 관리 |
관리형이라는 이유로 색인과 샤드가 자동으로 적절해지는 것은 아닙니다. 샤드를 지나치게 잘게 나누거나 큰 집계를 반복하면 용량을 늘려도 원하는 응답 시간이 나오지 않을 수 있습니다. Elastic의 공동 책임 안내와 Hosted 운영 계획 안내를 읽으며 공급사 책임과 검색팀 책임을 문서로 나누세요. AWS에서도 서비스가 관리하는 인프라와 애플리케이션의 검색 품질은 구분해야 합니다.
3. 비용은 저장 용량 한 줄로 비교하지 않기
Amazon OpenSearch 공식 요금 안내는 관리형 클러스터의 인스턴스 시간·저장소·전송을 구분합니다. Elastic Hosted 청구 항목 안내 역시 배포 용량 외의 전송·저장 등 항목을 설명합니다. 견적에는 선택한 구성에서 실제 발생하는 항목만 넣고, 검색에 사용하지 않는 별도 기능을 기본 비용처럼 더하지 마세요.
같은 조건의 월간 총비용 비교
= 검색 노드/배포 용량 + 저장소 + 데이터 전송
+ 필요한 수집·백업·연결 서비스
+ 지원 계약 + 운영·이전 작업 시간
비교 전에 고정할 조건
문서 수 / 색인 크기 / 하루 변경량 / 질의 유형
최대 동시 요청 / 가용 영역 / 복구 목표 / 보존 기간예를 들어 문서 원본이 100GB라고 해서 두 서비스의 청구 저장량을 모두 100GB로 넣으면 안 됩니다. 이 수치는 가정일 뿐이며, 분석된 필드·색인 구조·복제본·삭제 후 병합 상태에 따라 실제 색인 크기가 달라집니다. 같은 문서 표본을 색인한 뒤 저장량을 측정하고 확장 여유를 따로 적으세요. 할인 약정은 이전 검증이 끝난 뒤 안정적인 사용량에 맞춰 검토하는 편이 낫습니다.
4. 사내 문서 검색 PoC를 이렇게 구성하기
가상의 사내 문서 서비스가 “장비 교체 신청”, 약어, 제품명과 오타가 섞인 질문을 받는다고 가정해 보겠습니다. 두 후보에 같은 공개 또는 비식별 문서 표본을 넣고 검색 조건을 맞춥니다. 쿼리 한 건의 성공 여부보다 실제 이용자가 찾는 문서가 상위 결과에 나타나는지와 권한 밖 문서가 노출되지 않는지가 중요합니다.
- 대표 질문마다 기대 문서와 허용되는 결과를 미리 기록한다. 제목 검색·본문 검색·필터·정렬을 분리한다.
- 한국어 분석, 동의어, 영문 약어, 숫자 제품명을 별도 묶음으로 평가한다.
- 평상시 읽기 부하와 대량 문서 갱신이 겹칠 때의 지연·실패율을 측정한다.
- 권한이 다른 두 테스트 사용자의 결과와 삭제한 문서의 검색 제외를 확인한다.
- 백업 복원과 원본 데이터 재색인 시간을 각각 측정하고 복구 목표와 비교한다.
기존 PostgreSQL을 원본으로 유지한다면 검색 색인은 파생 데이터로 취급하는 구성이 가능합니다. 관리형 PostgreSQL 선택 글에서 정한 원본 저장소 운영 기준과 연결해, 변경 전파가 끊겼을 때 재처리할 지점도 설계하세요. 검색 색인을 원본 데이터의 유일한 백업처럼 사용하는 것은 별도 문제입니다.
5. 이전 결정 전 마지막 체크리스트
- 사용 중인 API·클라이언트·플러그인과 대상 서비스 지원을 항목별로 대조했는가?
- 새 색인에 원본을 재색인하고 이후 변경분을 따라잡을 절차가 있는가?
- 전환 전후 검색 결과와 접근 권한을 비교할 표본을 보관했는가?
- 리전·네트워크·가용성·지원 조건을 맞춘 견적과 운영 시간을 비교했는가?
- 읽기 전환 실패 시 되돌릴 경로와 쓰기 정합성 확인 기준이 있는가?
자주 묻는 질문
AWS를 쓰고 있으면 OpenSearch가 항상 더 저렴한가요?
그렇지 않습니다. 같은 가용성·검색 작업량·전송 경로에서 견적을 내고 이전·운영 시간을 합쳐야 합니다. 클라우드 위치가 같다는 것만으로 총비용을 결정할 수 없습니다.
기존 Elasticsearch 인덱스를 그대로 옮겨도 되나요?
버전·기능·스냅샷 호환성을 확인해야 합니다. 자동 호환을 전제로 삼지 말고 원본에서 재색인하는 경로와 클라이언트 테스트를 준비하세요.
벡터 검색을 쓸 계획이면 무엇을 추가로 확인하나요?
임베딩 생성 비용·차원·필터 결합·색인 갱신·검색 품질을 별도 실험으로 분리하세요. 특정 상품의 지원 기능과 과금은 해당 공식 문서에서 다시 확인해야 합니다.
공식 출처와 함께 읽을 글
- AWS OpenSearch 서비스 개요
- Elastic Cloud Hosted
- Elastic 공동 책임
- Hosted 운영 계획
- AWS OpenSearch 요금
- Elastic Hosted 청구 항목
- 원본 저장소: PostgreSQL 선택 기준
공식 문서 확인 기준일: 2026년 10월 5일. 본문의 사례와 계산은 설명을 위한 가정이며 실제 도입·실행 결과가 아닙니다. 제품 구성과 계약 조건은 도입 시 공식 문서와 견적으로 다시 확인하세요.
