Elasticsearch 입문 1편 — 검색·로그·AI 한 통에 다 들어가는 분산 엔진 종합

이 글은 Elasticsearch 입문에서 운영까지 시리즈 38편 중 1편이에요. 백엔드 데이터 인프라 130편 을 끝까지 보신 분에게 — PG·Redis·Kafka 셋이 영속·캐시·이벤트를 잡아 줬다면, 그 위에 얹는 검색·로그·관측·벡터 통합 엔진 한 자리가 비어 있어요. 그 빈자리를 채우는 도구가 Elasticsearch.

왜 시리즈 8이 검색·로그·AI 통합인가

자바 백엔드 입문 59편이 "Spring 으로 코드를 어떻게 짜는가" 였고, 백엔드 데이터 인프라 130편이 "그 코드가 다루는 데이터를 어디에 어떻게 담느냐" 였다면, 이번 시리즈 8은 "그 데이터를 어떻게 빠르게 검색하고, 로그·메트릭으로 관찰하고, 벡터로 AI 까지 묶느냐" 단계예요.

PG·Redis·Kafka 세 도구로는 못 잡는 자리가 있어요. "e-commerce 1억 건 상품을 한글·영문·이모지 섞어 검색", "하루 100GB 로그를 한 화면에서 필터", "임베딩 벡터 1억 개로 RAG 검색" 같은 자리예요. 이 자리에 Elasticsearch 가 사실상 표준으로 자리잡았어요.

Elasticsearch란

Elasticsearch = "오픈소스 검색·분석·AI 플랫폼". 2010년 Shay Banon 이 Apache Lucene 위에 분산 레이어를 얹어 만든 검색 엔진이고, 지금은 Elastic 사가 주도해서 벡터 데이터베이스 · AI 툴킷 · 고급 검색 을 한 통에 묶어 가는 플랫폼으로 진화 중이에요.

핵심 특성을 한 호흡에 요약하면 — JSON 문서를 그대로 던지면 자동 색인되고, 풀텍스트 검색·구조화 검색·집계·벡터 검색이 한 API 로 다 돌아가요. Lucene (Java 로 짠 풀텍스트 검색 라이브러리) 의 분산 클러스터 버전이라고 보면 됩니다.

세 가지 대표 사용 자리가 있어요. 검색 은 상품·문서·사용자 검색 같은 전통 풀텍스트 자리예요. 로그·분석 은 Kibana 와 묶어 ELK 스택 으로 운영되는 로그 집계·시계열 분석 자리고요. AI 통합 은 임베딩 벡터를 저장하고 kNN 으로 가까운 문서를 찾는 RAG (Retrieval-Augmented Generation, 검색 기반 LLM 응답) 인프라 자리예요.

작성 시점(2026-05-19) 기준 안정 메이저 버전은 Elasticsearch 8.x 이고, 9.x 가 미리보기 단계예요. 이 시리즈는 8.x 기반으로 작성합니다.

핵심 개념 5가지

Elasticsearch 를 처음 보는 사람이 가장 자주 헷갈리는 게 "RDBMS 의 무엇과 대응되는가" 매핑이에요. 다섯 가지 단어만 기억하면 90%는 잡혀요.

Index 는 RDBMS 의 테이블 에 해당하는 단위예요. 같은 종류의 문서가 모이는 컬렉션이고, 하나의 인덱스가 여러 샤드(shard) 로 쪼개져 노드에 분산돼 있어요.

Document 는 행(row) 에 해당해요. 다만 형태가 JSON 이라서 중첩 객체·배열·여러 타입 이 한 문서 안에 자유롭게 들어갈 수 있어요. _id 가 RDBMS PK 자리예요.

Shard 는 인덱스를 쪼갠 단위예요. Primary Shard 가 원본을 들고 있고, 노드를 가로질러 분산돼서 검색·쓰기 부하를 나눠요. 한 번 만들면 기본적으로 갯수 변경 불가 — 특수 명령으로 split·shrink 가 가능하지만 부담이 커서, 초기 설계가 결정적. 27편(Shard Allocation) 에서 깊이.

Replica 는 샤드의 복제본이에요. 고가용성(HA, High Availability) 과 읽기 부하 분산 둘 다 해결해요. 기본값은 Replica = 1 — 즉 데이터가 두 벌이라서 한 노드가 죽어도 데이터 손실 X.

Mapping 은 RDBMS 의 스키마 에 해당해요. 어느 필드가 text 인지 keyword 인지 number 인지 정의하고, analyzer 같은 전문 검색 옵션도 여기서 정해요. 한 번 잡으면 변경이 까다로워서 — 8편(Mapping Deep) 에서 가장 길게 다루게 돼요.

Elasticsearch vs OpenSearch — fork 이야기

2021년에 Elasticsearch 가 라이선스를 Apache 2.0 → SSPL (Server Side Public License) + Elastic License 로 바꾸면서 AWS 와 갈라졌어요. AWS 는 Apache 2.0 호환 오픈소스 를 유지하기 위해 Elasticsearch 7.10.2 를 OpenSearch 라는 이름으로 fork 해서 독립 프로젝트로 키웠어요. 그 결과 시장에 두 갈래가 생겼어요.

대부분의 한국 회사는 AWS 환경이면 OpenSearch, 멀티 클라우드·자체 운영이면 Elasticsearch 를 선택해요. 35편(AWS OpenSearch) 과 36편(Elastic Cloud) 에서 둘을 따로 깊이.

Spring Data Elasticsearch — Java 백엔드에서 ES 쓰기

자바·Spring 환경에서 Elasticsearch 를 쓰면 거의 항상 Spring Data Elasticsearch 가 함께 들어와요. Spring Data 프로젝트 의 일부라 Spring Data JPA 와 같은 Repository · Template · POJO 매핑 패턴을 그대로 따라가요. 자바 백엔드 입문 시리즈 44~50편에서 다룬 JPA 와 형태가 거의 같다 고 보면 됩니다.

핵심 추상화는 두 갈래예요. ElasticsearchTemplate (sync) 과 ReactiveElasticsearchTemplate (반응형) — 둘 다 ES 인덱스 CRUD·검색·집계를 한 메서드 호출로 풀어 줘요. 그 위에 Repository 인터페이스를 만들면 메서드 이름만으로 쿼리가 자동 생성되는 것도 JPA Repository 와 같은 메커니즘.

POJO 매핑은 어노테이션 기반 이에요. @Document 로 인덱스 이름을, @Field 로 ES 필드 타입·analyzer 를, @Id 로 PK 를, @Setting 으로 인덱스 설정을 박아요. 작성 시점(2026-05-19) 기준 최신 버전은 Spring Data Elasticsearch 6.0.0 이고, Spring Boot 3.5+ 와 함께 쓰는 게 표준 조합이에요. 32편(Spring Data Elasticsearch) 에서 깊이.

한국 회사가 Elasticsearch 로 가는 이유 4가지

2010년대 후반부터 한국 회사 신규 백엔드 프로젝트가 점점 Elasticsearch (또는 OpenSearch) 를 검색·로그 인프라 표준으로 채택해요. 이유 네 가지가 거의 항상 등장.

(1) 풀텍스트 검색의 압도적 사용성

RDBMS 의 LIKE %검색% 으로는 형태소 분석·동의어·오타 허용 같은 진짜 검색 이 안 돼요. PG 의 tsvector 는 영어엔 OK 하지만 한국어 형태소 분석이 약하고, 큰 데이터에서 느려져요. Elasticsearch + Nori (한국어 분석기) 조합이 e-commerce 상품 검색·사내 위키 검색·문서 검색 의 사실상 표준 자리.

(2) ELK 스택의 운영 편의

Logstash (수집) + Elasticsearch (저장·인덱싱) + Kibana (시각화) 의 ELK 스택 (또는 Beats 까지 합쳐 Elastic Stack) 이 로그 집계·운영 모니터링 의 표준 패턴이에요. 33편(Kibana·ELK) 에서 깊이.

(3) 벡터 검색·RAG 인프라

ChatGPT·Claude 같은 LLM 등장 이후 임베딩 벡터 를 저장하고 유사도 검색 하는 자리가 모든 회사에 생겼어요. Elasticsearch 의 dense_vector 필드 + kNN (k-Nearest Neighbors, k개 최근접 이웃) 쿼리가 이 자리를 별도 벡터 DB (Pinecone·Weaviate) 없이 잡아 줘요. 21편·22편에서 깊이.

(4) 매니지드 서비스의 비용 효율

자체 운영이 부담스러우면 AWS OpenSearch Service (또는 Elastic Cloud) 가 t3.small 부터 r7g.16xlarge 까지 다양한 인스턴스 옵션과 자동 백업·자동 패치 를 제공해요. 작은 규모는 Serverless 옵션도 있어서 월 $30~50 부터 시작 가능.

Elasticsearch 가 잘 안 어울리는 시나리오

만능은 아니에요. 다음은 신중.

• 트랜잭션 ACID 가 핵심 — PG·MySQL 같은 RDBMS 가 더 적합해요. ES 는 near real-time (refresh 주기 1초) 이라 진짜 ACID 보장이 X.
• 단순 KV 캐시 — Redis 가 압도적으로 적합해요. μs 단위 응답 vs ES 의 ms 단위 차이.
• 이벤트 스트리밍 — Kafka 가 더 어울려요. ES 도 가능하지만 retention·ordering 측면이 약합니다.
• 소규모 데이터 (< 1만 행) — RDBMS 의 LIKE 나 PG 의 tsvector 로 충분해요. ES 운영 비용이 데이터 가치보다 큼.

시리즈 38편 한눈에

이번 시리즈가 다루는 영역을 한 페이지로 압축하면 이렇게 흐릅니다.

자주 만나는 사고

사고 1 — Mapping Explosion

원인 — 동적 매핑(Dynamic Mapping) 을 켠 채로 임의의 키 가 들어오는 JSON 을 그대로 색인하면, 필드 수가 폭증해서 클러스터 메모리가 터져요.

해결 — 운영 인덱스는 dynamic: strict 로 잠그고, 총 필드 한도(index.mapping.total_fields.limit)를 1,000 으로 박는 게 표준이에요. 8편(Mapping Deep) 에서 깊이.

사고 2 — Shard 수 미설계

원인 — 1차 설계 때 Primary Shard = 1 또는 = 100 같이 극단으로 잡으면 나중에 split·shrink 비용 이 막대해요.

해결 — 데이터 1TB 기준 Primary Shard 20~30개 가 거친 가이드예요. 시간 데이터는 날짜별 인덱스 + Rollover 패턴이 일반이고, 6편(ILM) 에서 깊이.

사고 3 — Deep Pagination 폭망

원인 — from + size 로 100,000번째 페이지를 가져오면 모든 샤드에서 100,000번째까지 정렬 후 반환 해야 해서 수십 초~분 단위 응답 폭증.

해결 — search_after 또는 scroll 을 써요. 19편(Search Features) 에서 깊이.

사고 4 — Korean Tokenizer 미설정

원인 — 한국어 텍스트를 기본 standard 분석기로 색인하면 형태소 분석이 안 돼서 "신촌·연세대학교" 같은 자연어 검색이 어절 단위로만 잡혀요.

해결 — nori_tokenizer 를 깔고 사용자 사전으로 도메인 단어를 추가해요. 11편(Korean Analyzer) 에서 깊이.

사고 5 — Red 상태

원인 — 어느 Primary Shard 가 어떤 노드에도 할당되지 못해 클러스터 health 가 red 가 됨. 인덱스 일부 데이터 읽기·쓰기 불가.

해결 — _cluster/allocation/explain 으로 원인 진단 → 디스크 watermark 체크 → 노드 추가 또는 reroute. 26편(Cluster Operations) 에서 깊이.

사고 6 — split-brain

원인 — 네트워크 파티션으로 master-eligible node 가 둘로 갈려 각자 마스터를 선출해 데이터 무결성이 깨져요.

해결 — quorum (= (N/2)+1) 기반 voting + master 노드 3개 최소 구성. 26편에서 다시.

사고 7 — 라이선스 충돌

원인 — Elasticsearch 7.11+ 의 SSPL/Elastic License 가 오픈소스 정의에 부합 X 라 상업 SaaS 재판매가 막혀요.

해결 — 운영 요구가 Apache 2.0 만 허용 이면 OpenSearch 로 전환해요. 35편(AWS OpenSearch) 에서 깊이.

운영 권장 패턴 5가지

운영 시작 전에 데이터 1TB · QPS 100 · 풀텍스트 검색 · 한국어 같은 요구를 먼저 정량화해서, 인덱스 설계·샤드 수·노드 사양을 거기서부터 거꾸로 짜요.

인덱스는 항상 alias 로 노출 합니다. 앱은 실제 인덱스 이름이 아닌 alias 로 조회하고, 재색인·rollover 할 때 alias 만 갈아끼우면 다운타임 0.

Mapping 은 strict + 명시적 으로 가져가요. 동적 매핑을 끄고 모든 필드를 미리 정의해 두면 Mapping Explosion 사고 의 70% 가 사라져요.

로그·메트릭은 별도 클러스터 로 분리해요. 검색용 클러스터와 로그·관측용 클러스터를 같은 곳에 두면 로그 쓰기 폭증이 검색 응답을 막는 사고가 잦아요.

운영 monitoring 표준 셋업으로 _cluster/health · _nodes/stats · slow log 세 가지를 Grafana 또는 Kibana 대시보드에 박아 둡니다. 30편(Monitoring) 에서 깊이.

시험 직전 한 번 더 — 압축 노트

• Elasticsearch = Lucene 위 분산 검색·분석·AI 플랫폼. 2010 Shay Banon 발표.
• 핵심 5단어: Index · Document · Shard · Replica · Mapping.
• RDBMS 대응: Index = 테이블, Document = 행, Mapping = 스키마.
• Shard = 인덱스 쪼갠 단위, 한 번 정하면 갯수 변경 부담 큼.
• Replica = 샤드 복제본. 기본 1 → 데이터 두 벌, HA + 읽기 부하 분산.
• Mapping = JSON 필드 타입·analyzer 정의. strict 모드 권장.
• Mapping Explosion · Shard 미설계 · Deep Pagination · Korean Tokenizer 미설정 · Red 상태 · split-brain · 라이선스 가 7대 사고.
• OpenSearch = AWS 가 ES 7.10.2 에서 fork, Apache 2.0. AWS 환경 기본 선택.
• Spring Data Elasticsearch 6.0.0 = Spring 환경 ES 표준. @Document · @Field · Repository · ElasticsearchTemplate.
• 세 가지 사용 자리: 풀텍스트 검색 · ELK 로그 · 벡터 검색·RAG.
• 운영 안 어울리는 자리: ACID · 단순 KV · 이벤트 스트림 · 소규모 데이터.
• 현재 안정 버전 (2026-05): Elasticsearch 8.x. 9.x 미리보기.
• 검색·분석·AI = 한국 회사 신규 백엔드의 4번째 데이터 인프라 도구.

시리즈 다른 편

• 다음 글 = 2편 Elasticsearch 핵심 개념 — Index·Document·Shard·Replica·Mapping 깊이
• 3편 = Lucene 내부 — Segment·Inverted Index·Posting List
• 4편 = Quickstart — Docker·curl·Kibana 첫 화면
• 5편 = Index 관리 — Create·Settings·Alias·Reindex
• 8편 = Mapping Deep — Static·Dynamic·Multi-field·Runtime
• 11편 = Korean Analyzer — Nori·mecab-ko·사용자 사전
• 32편 = Spring Data Elasticsearch — Repository·Template·POJO
• 35편 = AWS OpenSearch Service — Domain·Serverless·Provisioned
• 38편 = 시리즈 마무리 — 결정 트리·체크리스트·자격증

한 줄 정리 — Elasticsearch = Lucene 위에 분산·실시간·JSON 색인 + 풀텍스트·집계·벡터 검색을 묶은 검색·로그·AI 통합 플랫폼. 한국 회사가 4번째 데이터 인프라 로 채택하는 표준 도구.