안녕하세요. 좋은 아침입니다. 오늘부터 천천히 아침 일찍 일어나다가 깁스를 풀고나면 그때부터 미라클 모닝을 하려고 합니다. 최근 오전 5시에 일어나게 된 이유라는 영상을 보게되었는데, 결국 일찍 자면 일찍 일어나게 된다는게 당연하면서도 여태 이걸 하지 못했구나 싶더라고요? 저도 과거에 미라클 모닝했던 기억이 생각나면서 다시 도전하려고 합니다.
오늘도 일찍 수면에 취한 덕분에 알림 없이 잘 일어났네요. 그럼 검색엔진에 대한 학습 시작하도록 하겠습니다.
검색 엔진
검색 엔진(Search Engine)은 대량의 데이터에서 사용자가 원하는 정보를 빠르게 찾을 수 있도록 도와주는 시스템입니다.
일반적으로 검색이라고 하면 구글이나 네이버 같은 웹 검색을 떠올릴 수 있지만, 서비스 내부에서도 검색 엔진을 자주 사용합니다.

예를 들어 쇼핑몰에서 상품명을 검색하거나, 커뮤니티에서 게시글을 검색하거나, 운영자가 서버 로그에서 특정 에러 메시지를 찾는 경우가 있습니다.
즉, 검색 엔진은 단순히 데이터를 저장하는 것이 아니라 사용자가 입력한 검색어와 가장 관련 있는 데이터를 빠르게 찾아주는 역할을 합니다.
검색 엔진의 주요 작동 원리 3단계
1. 크롤링
검색 대상이 되는 데이터를 수집하는 단계입니다.
웹 검색 엔진이라면 웹 페이지를 수집하고, 서비스 내부 검색이라면 게시글, 상품, 사용자 데이터, 로그 데이터 등을 검색 대상으로 가져올 수 있습니다.
즉, 크롤링은 꼭 웹 페이지에만 한정되기보다 검색에 사용할 원본 데이터를 모으는 과정으로 이해할 수 있습니다.
2. 인덱싱
수집한 데이터를 검색하기 좋은 형태로 가공하고 저장하는 단계입니다.
단순히 원본 데이터를 그대로 저장하는 것이 아니라 텍스트를 추출하고, 단어를 나누고, 불필요한 요소를 정리한 뒤 검색에 적합한 인덱스를 생성합니다.
검색 엔진이 빠르게 검색할 수 있는 이유는 이 인덱싱 과정에서 미리 검색용 자료구조를 만들어두기 때문입니다.
3. 결과 제공
사용자가 검색어를 입력하면 검색 엔진은 미리 만들어둔 인덱스를 기준으로 관련 문서를 찾습니다.
이후 단순히 포함 여부만 보는 것이 아니라, 검색어와 문서의 관련도, 문서의 중요도, 사용자 행동 데이터 등을 고려해 결과의 순위를 매기고 사용자에게 제공합니다.
DB 검색과 검색 엔진의 차이
데이터베이스에서도 검색 기능을 구현할 수 있습니다. 예를 들어 MySQL에서는 'LIKE' 검색을 사용해 특정 문자열이 포함된 데이터를 조회할 수 있습니다.
SELECT * FROM posts WHERE title LIKE '%검색어%;
하지만 이러한 방식은 데이터가 많아질수록 성능 문제가 발생할 수 있습니다. 특히 앞뒤로 %가 붙는 검색은 인덱스를 효율적으로 사용하기 어렵고, 전체 데이터를 훑어보는 방식에 가까워질 수 있습니다.
또한 일반적인 DB 검색은 사용자가 입력한 검색어의 유사도, 형태소 분석, 오타 보정, 관련도 점수 계산 같은 검색 특화 기능을 처리하기 어렵습니다.
따라서 DB는 데이터를 정확하게 저장하고 조회하는데 강점이 있고, 검색 엔진은 대량의 텍스트에서 관련성 높은 결과를 빠르게 찾는 데 강점이 있습니다.
Elasticsearch란?
Elasticsearch는 대량의 데이터를 실시간으로 저장, 검색 및 분석하기 위해 사용되는 오픈소스 분산형 검색 엔진입니다. Apache Lucene을 기반으로 만들어졌으며, REST API를 통해 데이터를 저장하고 검색할 수 있습니다. 검색 기능뿐만 아니라 로그 분석, 모니터링, 통계 분석 등 다양한 상황에서도 사용됩니다.
대표적으로 기본 백엔드로 사용하거나 로그 및 지표 분석, 엔터프라이즈 검색, 보안 인텔리전스에 자주 사용됩니다.
Apache Lucene
Apache Lucene은 Java로만 작성된 무료 오픈 소스 검색 엔진 라이브러리입니다. Lucene은 주로 검색 엔진 구현 기능으로 유명합니다.
Lucene은 문서를 검색 및 인덱스의 기본 단위로 활용합니다. 모든 문서 콘텐츠를 키워드 중심 데이터 구조로 인덱싱하고 저장하기 때문입니다. 또한 매우 빠른 검색 응답 시간을 달성할 수 있습니다. Lucene에 저장된 콘텐츠는 웹 사이트, 파일 시스템 및 Postgre SQL과 같은 데이터베이스를 비롯한 다양한 소스에서 가져올 수 있습니다.
Apache Lucene의 장점
- 수평적 확장성
- 여러 코딩 언어 지원
- 자동 완성
- 플러그인 및 통합 지원
Elasticsearch의 특징
- 탁월한 검색 성능
- 역인덱스 구조를 사용하여 방대한 양의 데이터에서도 초고속 풀텍스트 검색을 제공합니다.
- 수평적 확장성
- 데이터를 여러 조각(샤드)으로 나누어 분산 저장 및 처리하므로 서버를 추가하여 용량과 성능을 손쉽게 늘릴 수 있습니다.
- RESTful API
- JSON 기반의 HTTP 요청을 통해 데이터를 간편하게 색인하고 쿼리할 수 있습니다.
- ELK 스택의 중심
- 데이터 수집 및 시각화 도구인 Logstash, Kibana와 결합하여 시스템 모니터링, 로그 분석 등 다양한 분야에 활용됩니다.
Elasticsearch 구조
논리적 구조
논리적 구조는 데이터를 어떻게 저장하고 표현하는지를 설명합니다.
Index
Index는 Document들이 저장되는 논리적인 공간입니다. 관계형 데이터베이스에 비유하면 테이블과 비슷하게 볼 수 있습니다.
예를 들어 게시글 검색 기능을 만든다면 posts라는 Index를 만들 수 있습니다.
Index : posts
다만 Elasticsearch의 Index는 RDBMS의 테이블과 완전히 같은 개념은 아닙니다.
Document
Document는 Elasticsearch에 저장되는 데이터 한 건입니다. Elasticsearch에서는 데이터가 JSON 형태의 Document로 저장됩니다.
예를 들어 게시글 하나는 다음과 같이 Document가 될 수 있습니다.
{
"title": "Elasticsearch란?",
"content": "Elasticsearch는 대량의 데이터를 빠르게 검색하기 위한 검색 엔진입니다.",
"author": "user1",
"createdAt": "2026-05-26"
}
Field
Field는 Document 안에 있는 각각의 속성입니다.
위 예시에서는 다음 값들이 Field입니다.
title
content
author
createdAt
각 Field는 검색 방식에 따라 다르게 다룰 수 있습니다.
예를 들어 title과 content는 문장을 분석해서 검색해야 하므로 전문 검색 대상이 될 수 있고, author는 정확히 일치하는 값으로 검색하는 것이 더 적합할 수 있습니다.
Mapping
Mapping은 각 Field가 어떤 타입을 가지며, 어떻게 인덱싱될지를 정의하는 설정입니다.
{
"title": "text",
"content": "text",
"author": "keyword",
"createdAt": "date"
}
여기서 text는 문장을 분석해서 검색할 때 사용하고, keyword는 정확한 값 비교에 사용합니다.
예를 들어 title이 text라면 "Elasticsearch란?"이라는 문장이 분석되어 검색 가능한 단어 단위로 처리될 수 있습니다.
반면 author가 keyword라면 "user1"이라는 값 전체를 기준으로 정확히 일치하는 데이터를 찾는 데 적합합니다.
물리적 구조
실제로 데이터를 어떻게 저장하고 분산 처리하는지를 설명합니다.
Cluster
Cluster는 하나 이상의 Node가 모여 구성된 Elasticsearch 전체 시스템입니다.
서비스 규모가 작다면 하나의 Node로도 Elasticsearch를 실행할 수 있지만, 데이터가 많아지고 안정성이 중요해지면 여러 Node를 하나의 Cluster로 구성할 수 있습니다.
Cluster
├─ Node 1
├─ Node 2
└─ Node 3
Node
Node는 Elasticsearch가 실행되는 하나의 서버입니다. 하나의 Cluster 안에는 여러 Node가 존재할 수 있습니다.
각 Node는 데이터를 저장하거나, 검색 요청을 처리하거나, Cluster 상태를 관리하는 역할을 할 수 있습니다.
즉, Node는 Elasticsearch 시스템을 구성하는 개별 서버 단위입니다.
Shard
Shard는 한의 Index를 나누어 저장하는 단위입니다.
예를 들어 posts Index에 게시글 데이터가 매우 많아졌을 때, 이 데이터를 하나의 서버에만 저장하면 저장 공간과 검색 처리에 부담이 생길 수 있습니다. 그래서 Elasticsearch는 하나의 Index를 여러 Shard로 나누어 저장할 수 있습니다.
posts Index
├─ Shard 0
├─ Shard 1
└─ Shard 2
Replica
Replica는 Shard의 복제본입니다.
예를 들어 Shard 0의 원본이 Node 1에 저장되어 있다면, 그 복제본을 Node 2에 저장할 수 있습니다.
Node 1: Shard 0
Node 2: Shard 0 Replica
Replica를 두는 이유는 크게 두 가지입니다.
첫 번째는 장애 대비입니다.
Primary Shard가 있는 Node에 문제가 생겨도 Replica Shard를 통해 데이터를 유지할 수 있습니다.
두 번 째는 검색 성능 향상입니다.
검색 요청은 Primary Shard 뿐만 아니라 Replica Shard에서도 처리할 수 있기에 요청을 분산해서 처리할 수 있습니다.
역색인 구조란?
Elasticsearch가 빠르게 검색할 수 있는 핵심 이유 중 하나는 역색인 구조를 사용하기 때문입니다.
일반적인 데이터 저장 방식은 문서 안에 어떤 단어가 있는지 확인합니다. 반면 역색인은 단어를 기준으로 해당 단어가 어떤 문서에서 등장하는지 미리 정리해둡니다.
예를 들어 다음과 같이 게시글이 있다고 가정해보겠습니다.
| 문서 ID | 제목 |
| 1 | Spring Boot 검색 기능 구현 |
| 2 | Elasticsearch 검색 엔진 학습 |
| 3 | Spring Security |
이를 역색인 구조로 정리하면 다음과 같이 볼 수 있습니다.
| 단어 | 등장한 문서 |
| Spring | 1, 3 |
| Boot | 1 |
| 검색 | 1, 2 |
| Elasticsearch | 2 |
| Security | 3 |
이렇게 단어별로 어떤 문서에 등장했는지 미리 정리해두면 사용자가 "검색"이라는 단어를 입력했을 때 모든 문서를 처음부터 끝까지 확인하지 않아도 됩니다. 이미 만들어진 역색인에서 "검색"이라는 단어가 등장한 문서 목록을 바로 찾을 수 있기 때문입니다.
Elasticsearch가 사용되는 상황
Elasticsearch는 다음과 같은 상황에서 사용할 수 있습니다.
| 상황 | 설명 |
| 상품 검색 | 상품명, 카테고리, 브랜드, 설명 등을 기준으로 검색 |
| 게시글 검색 | 제목, 내용, 작성자, 태그 기반 검색 |
| 로그 검색 | 서버 로그, 에러 로그, 사용자 행동 로그 분석 |
| 자동 완성 | 사용자가 입력하는 검색어에 맞춰 추천어 제공 |
| 필터 검색 | 가격, 지역, 날짜, 카테고리 조건을 함께 적용 |
예를 들어 제 개인 프로젝트인 커뮤니티 서비스에서는 게시글 제목과 내용을 기준으로 검색 기능을 제공할 수 있겠네요. 단순한 규모에서는 RDBMS 검색으로도 충분할 수 있지만, 게시글 수가 많아지고 검색 정확도나 속도가 중요해진다면 Elasticsearch 같은 검색 엔진을 고려할 수 있습니다.
오늘은 검색 엔진과 Elasticsearch에 대해 학습해보았습니다.
역색인 구조가 단순하지만 색인 구조가 아닌 역색인을 통해 검색 효율을 높인점이 굉장히 인상깊었던 것 같습니다. 다음 시간에는 메시지 브로커와 함께 돌아오도록 하겠습니다. 수고하셨습니다.
'백엔드 공부' 카테고리의 다른 글
| 컨테이너화 VS 가상화 - Docker란 무엇인가 (0) | 2026.05.28 |
|---|---|
| 메시지 브로커 - RabbitMQ와 Kafka (0) | 2026.05.27 |
| 아키텍처 패턴(2) - CQRS, 이벤트 소싱, 서버리스란 무엇인가? (0) | 2026.05.25 |
| 아키텍처 패턴(1) - 모놀리식, MSA, SOA란 무엇인가? (0) | 2026.05.24 |
| 개발 설계 원칙(3) - DRY와 리팩토링 (0) | 2026.05.22 |