Elasticsearch는 언제 써야 하는가

좋습니다.
실무 개발자 관점에서, 과장 없이, “왜 쓰는지” 중심으로 정리해보겠습니다.
블로그에 그대로 올려도 되는 구조로 작성합니다.

---

Elasticsearch는 언제 써야 하는가

Elasticsearch는 “빠른 검색 엔진”이 아니다.
정확히 말하면 검색을 위해 설계된 분산 인덱싱 시스템이다.

많은 개발자가 오해하는 부분은 이거다.

데이터베이스가 있는데 왜 또 Elasticsearch를 쓰는가?

답은 간단하다.

RDB는 정합성에 강하고
Elasticsearch는 검색에 강하다.

역할이 다르다.

---

1. Elasticsearch가 강한 영역

1️⃣ 전문 검색(Full Text Search)

• 제목 + 본문 통합 검색
• 형태소 분석 (한글은 Nori)
• 오타 허용
• 동의어 처리
• 하이라이트

RDB의 LIKE로는 한계가 명확하다.

---

2️⃣ 복합 필터 + 정렬 + 집계

예:

• 상태 = 승인
• 기간 = 최근 3개월
• 금액 100만원 이상
• 부서 = 개발팀
• 정렬 = 최신순

이런 조건이 섞이면
RDB는 인덱스 설계가 복잡해지고 성능 튜닝이 필요하다.

Elasticsearch는 이런 검색을 기본 설계로 처리한다.

---

3️⃣ 실시간 집계(Aggregation)

• 일별 승인 건수
• 상태별 통계
• 금액 구간별 분포
• 특정 키워드 빈도

terms / date_histogram / range aggregation은
Elasticsearch의 핵심 기능이다.

---

2. Elasticsearch를 쓰면 안 되는 경우

❌ 트랜잭션이 핵심인 시스템

• 정산
• 회계
• 결제
• 잔액 관리

Elasticsearch는 near real-time이다.
즉시 정합성을 보장하지 않는다.

따라서

RDB가 진실(Source of Truth)
Elasticsearch는 조회용 보조 엔진

이 구조가 기본이다.

---

3. 실무에서의 올바른 사용 패턴

RDB → Elasticsearch

일반적인 구조:

1. RDB에 데이터 저장
2. 이벤트 발행 (Outbox 패턴)
3. Elasticsearch에 인덱싱
4. 검색은 Elasticsearch
5. 상세 조회는 RDB 검증

이 구조는 CQRS 패턴과 잘 맞는다.

---

4. Elasticsearch 도입 시 고려사항

1️⃣ 인덱스 설계가 곧 성능

• 매핑 설계 중요
• text vs keyword 구분
• analyzer 설정
• ngram/autocomplete 전략

잘못 설계하면 재색인(reindex)이 필요하다.

---

2️⃣ 운영 비용

• 클러스터 구성
• 샤드 전략
• 메모리 사용량
• 디스크 I/O
• 장애 시 복구

“검색 엔진 하나 붙이는 것”이 아니라
하나의 시스템을 더 운영하는 것이다.

---

5. 언제 도입해야 하는가

다음 중 2개 이상이면 고려할 만하다.

• LIKE 검색이 느려졌다
• 검색 조건이 계속 늘어난다
• 필터 + 정렬 + 집계 조합이 많다
• 검색 UX 개선이 중요하다
• 로그/이벤트 분석이 필요하다

그렇지 않다면 RDB 튜닝이 먼저다.

---

6. 한 줄 정리

Elasticsearch는 데이터베이스를 대체하는 기술이 아니라
검색을 강화하는 보조 엔진이다.

정합성이 중요하면 RDB,
검색 경험이 중요하면 Elasticsearch.