SereneDB — 초고속 검색·분석 데이터베이스, AI 에이전트 대응

AI 요약

SereneDB는 전문 검색(full-text search)과 분석을 단일 엔진에 결합한 오픈소스 데이터베이스입니다. 개발팀은 12년간 개발한 검색 엔진을 바탕으로 PostgreSQL 호환성과 Elasticsearch 호환성을 제공한다고 설명합니다. 기존 SQL과 드라이버, Elastic 클라이언트를 유지하면서 검색·분석 시스템 사이의 데이터 이동과 ETL을 줄이는 것이 목표입니다. 첫 정식 릴리스 이름은 Krummelanke이며 라이선스는 Apache 2.0입니다.

검색과 분석을 한 엔진에서

CTO 안드레이(Andrey)는 SereneDB가 최신 분석 데이터베이스의 실행 방식을 검색에 적용했다고 설명합니다. 옵티마이저와 물리 실행 계획, 점수 계산을 컬럼형 분석과 한 엔진 안에 결합했습니다. 인덱스는 오브젝트 스토리지의 데이터 위에 놓이며, 팀은 이 구조가 상주해야 하는 데이터와 클라우드 비용을 줄이는 데 도움이 된다고 말합니다.

팀은 전문 검색에서 밀리초 단위 응답을 얻었던 초기 경험을 계기로 검색 엔진을 개발해 왔다고 밝혔습니다. 창업자들은 기존 검색 엔진의 한계를 오랫동안 당연하게 받아들였다고 보고, 분석 데이터베이스에서 발전한 벡터화 실행과 옵티마이저 같은 기법을 검색에 적용했다고 설명합니다.

공개 벤치마크와 결과

개발팀은 SearchBench의 질의 92개와 1억·10억·100억 건 규모 데이터를 사용해 Elasticsearch, OpenSearch, ClickHouse, PostgreSQL 및 검색 확장 기능을 비교합니다. 엔진별 공개 설정과 원시 결과를 제공하며, 각 엔진은 같은 머신에서 인스턴스 하나로 실행합니다. 질의당 제한 시간은 60초입니다. 팀은 설정이 공정하지 않다고 판단하면 PR을 제출해 재실행을 요청하라고 안내합니다.

팀이 공개한 결과에 따르면 PostgreSQL은 데이터 1억 건에서 질의 92개 중 63개에 응답하지 못했습니다. 데이터 10억 건에서는 Elasticsearch의 최선 설정이 평균적으로 SereneDB보다 약 3배 느렸다고 합니다. ClickHouse는 100억 건에서 관련도 순위가 필요한 질의 22개를 실행하지 못했고, 다른 22개도 시간 제한을 넘겼습니다. 반면 ClickHouse가 SereneDB보다 빠른 질의도 8개 있다고 팀은 밝혔습니다.

제품 소개는 10억 건 로그를 8분 이내에 인덱싱하고 Elasticsearch 대비 디스크를 약 10분의 1만 사용했다고 주장합니다. 공동창업자는 저장 공간 절감이 성능 저하를 동반하지 않는다고 답했습니다. 데이터를 압축하면 저장소에서 메모리로 읽어오는 양이 줄어 전체 성능도 좋아진다는 설명입니다. 이 수치는 개발팀이 공개한 벤치마크 결과이며, 팀은 원시 결과와 설정을 함께 공개한다고 밝혔습니다.

배포 범위와 제품 상태

팀은 페타바이트 규모 데이터에 관해 질문을 받자, 현재 연합(federated) 배포를 지원하며 클러스터형 시스템은 다음 해에 출시할 계획이라고 답했습니다. 단일 머신에서 대규모 데이터를 검색·분석하는 사용 사례를 우선 내세우며, 일반 가상 머신에서 개인 개발자나 연구자가 공개 데이터셋을 다루는 사례도 소개됐습니다.

Product Hunt 반응

• @svetlana_ragimova — SereneDB는 보통 큰 비용을 감당하는 업체만 제공하던 기능을 만들었습니다. 일반 머신 한 대에 방대한 데이터를 담고 엔터프라이즈 수준의 빠른 검색과 분석을 실행합니다. 누구나 검증할 수 있는 벤치마크를 보면 전문 검색 속도가 현재 가장 빠르며, 오픈소스입니다. 저는 컴퓨터과학 석사 학위가 있지만 코딩은 완전히 잊었습니다. 그래도 소프트웨어를 만드는 기본 원리는 기억합니다. 바이브 코딩 시대에 AI를 이용해 오래전부터 만들고 싶었던 것을 만들고 있습니다. 사용하기 쉬운 데이터베이스가 빠져 있었는데, PostgreSQL은 설정하고 튜닝하려면 전문 지식이 필요합니다. SereneDB에서는 Claude Code에 명령어를 붙여 넣고 문서 MCP를 연결해 작업했습니다. 중간에 Docker는 설치해야 했습니다. 이제 일반 가상 머신에서도 엔터프라이즈 데이터셋을 검색하고 분석할 수 있어 데이터 규모에 거의 제한이 없습니다. 연구자들이 PubMed 초록 3,700만 건, 10만 곳이 넘는 관측소의 NOAA 일일 기후 기록, NASA 화성 탐사 로봇이 보낸 사진을 검색·분석한다고 상상해 보세요. 코딩 보조 도구와 SereneDB를 결합하면 더 많은 활용 사례가 생길 것입니다. 저는 이 팀의 헌터로 참여해 자랑스럽습니다. 팀은 미래를 보고 바이브 코더에게 친화적인 수준 높은 데이터베이스를 만들었습니다.
• @malandin — 안녕하세요, Product Hunt 여러분. SereneDB 공동창업자 겸 CEO 알렉산더입니다. 안드레이와 저는 약 17년 전 작은 사무실을 함께 쓰던 초급 기술자로 만났습니다. 언젠가 함께 제품을 만들 거라고 생각했지만, 무엇을 만들지 찾는 데 거의 20년이 걸렸습니다. 저는 고객의 데이터 문제를 해결하며 데이터베이스를 선택하고 도입하는 일을 했습니다. 어떤 문제가 들어오든 안드레이가 만든 검색 엔진이 문제 해결용으로 설계된 도구보다 더 빠르고 잘 해결하는 모습을 반복해서 봤습니다. 친구라서 믿은 게 아니라 실제 운영 환경에서 작동하는 걸 봤기 때문입니다. 검색 기술을 더 깊이 다루면서 업계의 검색 개념이 거의 10년 전에 멈췄다는 생각이 들었습니다. 기존 업체의 한계를 기준으로 아키텍처를 만들고 더 나은 방법을 묻지 않았습니다. 기술은 계속 발전했지만, 지금은 데모에서 본 결과를 믿지 못하는 사람도 있습니다. 그래서 검색과 분석을 하나로 합친 오픈소스 PostgreSQL 호환 엔진 SereneDB를 만들었습니다. 첫 빌드 서버는 안드레이의 아파트에서 조립했습니다. 오늘 첫 번째 이름 있는 릴리스 Krummelanke를 공개합니다. GitHub에서 내려받아 실행해 보세요. 시장에서 가장 빠른 검색·분석 데이터베이스라고 말하면 어떻게 들릴지 압니다. 그래서 SearchBench를 공개했습니다. 1억·10억·100억 건 데이터에서 실제 질의 92개를 실행하고, 모든 엔진의 공개 설정과 결과를 라이브 보드에 올렸습니다. 불공정한 설정이 있다고 생각하면 PR을 보내 주세요. 다시 실행하겠습니다. 불편한 질문까지 모두 답하겠습니다.
  • @dipanshu_kushwaha5 — 대규모 운영 환경에서 SereneDB는 Elasticsearch와 어떻게 비교되나요?
  • @malandin — 질문 감사합니다. 로그 10억 건으로 Elasticsearch와 비교했으며 효율성 차이를 확인했습니다. SearchBench를 살펴보세요. 페타바이트 규모를 물으신 거라면 현재 연합 배포로 지원합니다. 클러스터형 시스템도 지원할 수 있도록 작업 중이며 내년에 출시할 계획입니다.
• @aymi_malik — Elasticsearch보다 디스크를 10분의 1만 쓰는 데 단점은 무엇인가요? 질의 지연 시간 문제인가요, 아니면 저장 공간 효율 문제인가요? 그리고 축하합니다, @malandin과 @gnusi!
  • @malandin — 감사합니다! 단점은 없는 것 같습니다. 오히려 성능이 크게 좋아집니다. 데이터를 압축하면 저장소에서 메모리로 읽어오는 양이 줄어 전체 성능이 높아집니다. serenedb.com/searchbench의 벤치마크에서 확인할 수 있습니다. 관련 내용은 ‘Search Benchmark, The Game’ 이야기의 Adaptive Posting Lists 부분에서도 다룹니다.
• @gnusi — 안녕하세요, SereneDB CTO 안드레이입니다. 2012년부터 검색 엔진을 만들었고, 오늘 10년 넘게 만들고 싶었던 엔진의 첫 정식 버전을 공개합니다. 단일 엔진에서 수십억 건의 데이터에 1초 미만 전문 검색과 빠른 컬럼형 분석을 제공합니다. 오픈소스이며 PostgreSQL과 호환되고 인프라 비용이 낮습니다. 코딩 보조 도구를 쓰는 1인 개발자도 오후 한나절이면 배포할 수 있을 만큼 간단합니다. 2012년 Quest Software에서 로그 저장소를 만들다가 관계형 데이터베이스의 여러 방법을 한 달간 시도했지만 실패했습니다. Lucene을 써 보니 몇 초 걸리던 작업이 밀리초 만에 끝나는 시제품을 만들었습니다. 이후 EMC에서 검색 프로젝트를 제안하고 만들었으며 특허도 공동 집필했습니다. 엔진을 오픈소스로 공개하기까지 회사 안에서 6개월간 절차를 밟았습니다. 그 시제품은 나중에 페타바이트 규모 데이터를 다루는 분산 시스템으로 발전했습니다. 하지만 검색 기술이 멈췄다는 점이 계속 마음에 걸렸습니다. 분석 데이터베이스는 벡터화 실행, 비용 기반 옵티마이저, 수십 년간 축적된 연구를 적용했지만 검색 엔진은 제가 시작할 때와 같은 방식으로 포스팅 리스트를 교차했습니다. SereneDB에서는 분석 데이터베이스의 실행 방식과 컬럼형 분석을 PostgreSQL 호환 엔진 하나에 결합했습니다. 오브젝트 스토리지 데이터 위에 인덱스를 두어 자주 쓰는 데이터의 크기를 줄이고 클라우드 비용을 낮춥니다. SearchBench에서는 같은 머신과 엔진별 단일 인스턴스, 92개 검색·분석 질의, 60초 제한을 적용하고 설정과 원시 결과를 공개합니다. PostgreSQL은 데이터 1억 건에서 92개 질의 중 63개에 응답하지 못했습니다. Elasticsearch는 10억 건에서 네 가지 설정 중 가장 좋은 설정도 평균 약 3배 뒤처졌습니다. ClickHouse는 컬럼형 저장소로 뛰어나지만 100억 건에서 관련도 순위 질의 22개를 실행하지 못하고 다른 22개도 시간 초과됐습니다. ClickHouse가 SereneDB보다 빠른 질의 8개도 있으며, 보고서에서 차이가 난 이유를 분석합니다. 아키텍처와 실행 엔진, 벤치마크에 관해 질문해 주시면 자세히 답하겠습니다.
• @mackenzie_jackson — 지금 개발할 가치가 있는 기술입니다. AI 에이전트가 트래픽을 크게 늘리면 데이터베이스 병목은 프롬프트로 해결할 수 없는 운영 문제가 됩니다. 좋은 작업입니다.
  • @svetlana_ragimova — 맞습니다. 아직 분명하지 않을 수 있지만 곧 그렇게 됩니다. 에이전트는 데이터도 많이 만듭니다. 데이터를 한 노드에 두고 데이터가 있는 곳에서 바로 검색과 분석을 실행하는 데이터베이스가 필수적일 것입니다.
• @solodnev — 출시를 축하합니다. 이런 엔터프라이즈급 제품을 무료로 제공한다니 대단합니다. 최대 성능을 활용할 만큼 큰 공개 데이터셋이 충분히 있는지 궁금합니다.
  • @gnusi — 감사합니다! Reddit 데이터셋이 좋은 후보일 것 같습니다.
• @dzianis_yatsenka — 출시를 응원합니다. 좋은 제품입니다.
  • @malandin — 감사합니다, @dzianis_yatsenka! 큰 힘이 됩니다.

원문: Product Hunt / 번역·요약: Trawling