Elasticsearch의 라이선스 전쟁에서 AWS가 포크하여 탄생한 OpenSearch. 검색 엔진의 기원부터 Lucene, Elasticsearch의 부상, 라이선스 분쟁, 그리고 OpenSearch가 로그 분석·벡터 검색·AI까지 확장하는 현재를 풀어본다.
이전 글들에서 RDS(관계형 DB)와 DynamoDB(키-값 DB)를 다뤘다. 그런데 이런 상황을 상상해 보자:
쇼핑몰에서 사용자가 검색창에 **"갤럭시 s25 케이스 투명"**이라고 입력한다. 이 검색을 RDS의 SQL로 처리하면:
SELECT * FROM products
WHERE name LIKE '%갤럭시%'
AND name LIKE '%s25%'
AND name LIKE '%케이스%'
AND name LIKE '%투명%';
이 쿼리의 문제:
LIKE '%..%'는 인덱스를 사용할 수 없다 → 전체 테이블 스캔 → 느리다관계형 DB는 정확한 값 매칭에 최적화되어 있다. WHERE id = 123은 밀리초에 끝나지만, 자연어 텍스트 검색은 구조적으로 맞지 않는다.
이 문제를 해결하는 것이 검색 엔진이다. 그리고 오늘날 가장 널리 쓰이는 검색 엔진이 Elasticsearch — 그리고 그 오픈소스 포크인 OpenSearch다.
검색 엔진의 핵심 자료구조는 역색인(Inverted Index) 이다. 이 아이디어는 놀랍게도 도서관의 색인 카드에서 왔다.
일반적인 인덱스(정방향): "문서 1번에는 어떤 단어들이 있는가?"
문서1 → [갤럭시, s25, 케이스, 투명]
문서2 → [아이폰, 16, 케이스, 검정]
역색인: "이 단어가 어떤 문서에 있는가?"
갤럭시 → [문서1, 문서5, 문서12]
케이스 → [문서1, 문서2, 문서7, 문서15]
투명 → [문서1, 문서9]
s25 → [문서1, 문서3]
"갤럭시 s25 케이스 투명"을 검색하면? 각 단어의 문서 목록을 교집합하면 된다. {1,5,12} ∩ {1,3} ∩ {1,2,7,15} ∩ {1,9} = {1}. 100만 건의 문서에서도 밀리초 단위로 결과를 찾는다. 전체 테이블을 스캔하는 SQL LIKE와는 차원이 다르다.
1999년, Doug Cutting이 Java로 작성한 오픈소스 검색 라이브러리 Apache Lucene을 공개했다. Lucene은 역색인 구현, 텍스트 분석(토크나이징, 스테밍, 형태소 분석), 점수 매기기(TF-IDF, BM25) 등 검색의 핵심 기능을 제공했다.
Lucene 자체는 라이브러리다. 검색 기능을 제공하지만, 분산 처리, REST API, 클러스터링 같은 기능은 없다. Lucene 위에 이런 기능을 올려 서비스로 만든 것이 Elasticsearch(2010)이고, 그 이전에는 Apache Solr(2006)가 있었다.
Elasticsearch의 탄생 스토리는 개인 프로젝트에서 시작한다. 이스라엘 개발자 Shay Banon은 아내가 요리 수업을 다니면서 모은 레시피를 검색할 수 있는 앱을 만들고 싶었다. Lucene을 기반으로 작업하다가, 더 범용적인 분산 검색 시스템을 만들기로 했다.
2010년 2월, Elasticsearch 첫 버전을 공개했다. 핵심 설계 원칙:
Elasticsearch가 폭발적으로 성장한 진짜 이유는 로그 분석이었다. 2012~2013년, ELK 스택이라는 조합이 등장했다:
이 스택이 DevOps 팀의 표준이 됐다. "서비스에 에러가 났다? Kibana에서 로그를 검색하자" — 이것이 수백만 개발자의 일상이 됐다.
Elasticsearch를 만든 회사 Elastic NV는 2018년 뉴욕 증시에 상장했다. 하지만 AWS와의 갈등이 수면 위로 올라왔다.
문제의 핵심: AWS는 2015년부터 Amazon Elasticsearch Service를 출시하여, Elasticsearch를 관리형 서비스로 제공했다. Elastic의 오픈소스 코드를 가져다가 AWS 인프라에서 운영하고, 수익을 올렸다. Elastic 입장에서는 자신들이 개발한 소프트웨어로 AWS가 돈을 벌고 있었다.
Elastic CEO Shay Banon은 2019년 블로그에서 AWS를 공개적으로 비판했다:
"AWS가 우리의 소프트웨어를 가져다가 이름만 바꿔 판매하는 것은 오픈소스 커뮤니티에 해롭다."
2021년 1월, Elastic은 핵폭탄을 투하했다. Elasticsearch와 Kibana의 라이선스를 Apache 2.0에서 SSPL(Server Side Public License)과 Elastic License로 변경한 것이다.
SSPL의 핵심: 소프트웨어를 서비스로 제공하려면 전체 서비스의 소스코드를 공개해야 한다. 사실상 AWS 같은 클라우드 사업자가 Elasticsearch를 관리형 서비스로 판매하는 것을 막으려는 조치였다.
2021년 4월, AWS는 Elasticsearch 7.10.2 (라이선스 변경 직전의 마지막 Apache 2.0 버전)를 포크하여 OpenSearch를 발표했다.
AWS의 입장:
"오픈소스의 핵심은 누구나 자유롭게 사용할 수 있다는 것이다. 라이선스 변경은 이 원칙에 반한다. OpenSearch는 진정한 오픈소스로 남을 것이다."
Elastic의 입장:
"AWS가 우리의 투자에 무임승차하면서 오픈소스를 방패로 삼고 있다."
PUT /products/_doc/1
{
"name": "갤럭시 S25 투명 케이스",
"category": "액세서리",
"price": 15000,
"description": "갤럭시 S25용 투명 실리콘 케이스. 충격 방지.",
"tags": ["갤럭시", "케이스", "투명"],
"created_at": "2026-03-15"
}
문서를 인덱싱할 때 일어나는 일:
OpenSearch 클러스터는 여러 노드(Node) 로 구성된다:
검색 엔진 클러스터는 역사적으로 가장 많이 노출되는 데이터 저장소 중 하나다. 이유: 초기 Elasticsearch는 기본 설정에 보안이 없었다. 인증 없이 누구나 접근 가능했다.
AWS의 관리형 OpenSearch Service는 이 교훈을 반영하여 보안을 강화했다:
가장 기본적이면서 핵심적인 용도.
GET /products/_search
{
"query": {
"multi_match": {
"query": "갤럭시 s25 투명 케이스",
"fields": ["name^3", "description", "tags^2"],
"fuzziness": "AUTO"
}
}
}
multi_match: 여러 필드에서 동시에 검색name^3: 이름 필드의 가중치를 3배로fuzziness: AUTO: 오타 자동 교정 ("갤록시" → "갤럭시")가장 대규모로 사용되는 용도. 마이크로서비스 아키텍처에서 수십~수백 개의 서비스가 각각 로그를 생성한다. 이 로그를 중앙에서 검색·분석하는 것이 OpenSearch의 핵심 역할이다.
실전 패턴:
각 서비스 → Fluent Bit(수집) → OpenSearch(저장+검색) → Dashboards(시각화)
일반적인 로그 분석 쿼리:
OpenSearch Security Analytics는 보안 로그를 수집·분석하여 위협을 탐지한다. 방화벽 로그, VPN 로그, 인증 로그를 실시간으로 분석하여 이상 패턴을 감지한다.
2023년부터 OpenSearch에 추가된 벡터 검색(k-NN) 기능은 AI 시대에 핵심적인 역할을 한다.
전통적 검색: 키워드 매칭 (사용자가 입력한 단어와 문서의 단어를 비교) 벡터 검색: 의미 매칭 (텍스트를 벡터로 변환하여 의미적 유사도를 비교)
GET /products/_search
{
"query": {
"knn": {
"embedding_vector": {
"vector": [0.12, -0.34, 0.56, ...],
"k": 10
}
}
}
}
"따뜻한 색감의 핸드폰 케이스"라고 검색하면, 키워드 "따뜻한"이 상품명에 없어도 의미적으로 유사한 상품(파스텔, 베이지, 코랄 등)을 찾아준다.
이것이 RAG(Retrieval-Augmented Generation) 파이프라인의 핵심 구성 요소이기도 하다. LLM이 답변을 생성할 때, OpenSearch에서 관련 문서를 벡터 검색으로 찾아 컨텍스트로 제공한다.
2022년 출시된 OpenSearch Serverless는 DynamoDB처럼 용량 계획 없이 OpenSearch를 사용할 수 있게 한다:
벡터 검색 워크로드나 간헐적 로그 분석에 적합하다.
Netflix는 OpenSearch(이전 Elasticsearch)로 하루에 수 PB의 로그 데이터를 색인하고 분석한다. 수천 개의 마이크로서비스에서 생성되는 로그, 메트릭, 트레이스를 중앙에서 검색하여 장애를 진단한다.
Uber는 수백만 건의 승차 요청, 드라이버 위치, 결제 이벤트를 Elasticsearch/OpenSearch로 실시간 분석한다. 이상 거래 탐지, 서비스 상태 모니터링, 비즈니스 인텔리전스에 활용.
Wikipedia의 검색 기능은 Elasticsearch 기반이다. 수천만 개의 문서를 다국어로 검색하며, 자동 완성, 오타 교정, 관련 문서 추천을 제공한다.
| 상황 | 이유 | 대안 |
|---|---|---|
| 단순한 키-값 조회 | 오버스펙 | DynamoDB |
| 트랜잭션이 필요한 데이터 | ACID 미지원 | RDS/Aurora |
| 작은 규모의 검색 | 운영 부담 대비 효과 적음 | PostgreSQL FTS |
| 장기 아카이브 | 비용 높음 | S3 + Athena |
| 순수 벡터 검색만 | 더 특화된 도구 | pgvector, Pinecone |
이 시리즈에서 다룬 데이터 저장소들을 정리하면:
| 저장소 | "이런 질문"에 최적 |
|---|---|
| RDS/Aurora | "이 주문의 상세 정보는? 이번 달 매출 합계는?" (정확한 관계형 쿼리) |
| DynamoDB | "이 사용자의 장바구니는? 이 세션의 상태는?" (키 기반 초고속 조회) |
| S3 | "이 파일을 저장/가져와라" (오브젝트 저장) |
| OpenSearch | "이 키워드가 포함된 문서는? 이 패턴의 로그는?" (텍스트 검색 + 분석) |
각 저장소는 다른 유형의 질문에 최적화되어 있다. DynamoDB 글에서 다룬 Polyglot Persistence(다중 모델 아키텍처) 의 또 하나의 구성 요소가 OpenSearch다.
OpenSearch의 탄생 배경 — Elastic과 AWS의 라이선스 전쟁 — 은 기술 이야기인 동시에 오픈소스 비즈니스의 철학적 논쟁이기도 하다. 이 논쟁은 아직 끝나지 않았고, 2024년 Elastic의 AGPL 복귀로 새로운 국면에 접어들었다.
코어닷투데이의 AI 서비스에서도 OpenSearch는 핵심 역할을 한다. AI 추론 결과의 풀텍스트 검색, 서비스 로그 분석, RAG 파이프라인의 벡터 검색 — 이 모든 것이 OpenSearch의 역색인과 벡터 인덱스 위에서 동작한다.