SurrealDB 3.0은 당신의 다섯 개 데이터베이스 RAG 스택을 하나로 대체하고자 합니다

Source: VentureBeat

번역할 텍스트가 제공되지 않았습니다. 번역이 필요한 본문을 알려주시면 한국어로 번역해 드리겠습니다.

Source: https://venturebeat.com/data/how-openai-is-scaling-the-postgresql-database-to-800-million-users

소개

AI 에이전트를 위한 검색‑증강 생성(RAG) 시스템을 구축할 때는 구조화된 데이터, 벡터, 그래프 정보를 위한 여러 레이어와 기술을 사용하게 됩니다. 최근 몇 달 동안 에이전시 AI 시스템이 효과적으로 작동하려면 메모리—때때로 컨텍스트 메모리라고도 불리는—가 필요하다는 점이 점점 더 명확해지고 있습니다.

다양한 데이터 레이어를 사용해 컨텍스트를 제공하려면 복잡성과 동기화 문제가 발생할 수 있으며, 이는 성능 및 정확도 이슈로 이어집니다. 이것은 SurrealDB가 해결하고자 하는 과제입니다.

SurrealDB는 화요일에 자체 데이터베이스의 버전 3.0을 출시하고 2,300만 달러 규모의 Series A 확장을 발표했으며, 총 자금은 4,400만 달러에 이릅니다. 이 회사는 PostgreSQL 같은 관계형 데이터베이스, Pinecone 같은 네이티브 벡터 데이터베이스, Neo4j 같은 그래프 데이터베이스와는 다른 아키텍처 접근 방식을 취했습니다. OpenAI 엔지니어링 팀은 최근 읽기 복제본을 활용해 Postgres를 8억 명 사용자에게 확장한 방법을 상세히 설명했는데(읽기‑중심 워크로드에 적합한 접근 방식) SurrealDB는 다른 방식을 선택했습니다: 에이전트 메모리, 비즈니스 로직, 멀티모달 데이터를 데이터베이스 내부에 직접 저장합니다. 여러 시스템을 동기화하는 대신, 벡터 검색, 그래프 탐색, 관계형 쿼리가 모두 단일 Rust‑네이티브 엔진에서 트랜잭션적으로 실행되어 일관성을 유지합니다.

“사람들이 DuckDB, Postgres, Snowflake, Neo4j, Quadrant 혹은 Pinecone을 모두 함께 사용하면서 에이전트의 정확도가 떨어지는 이유가 무엇인지 궁금해하고 있습니다,” 라고 CEO 겸 공동 설립자 Tobie Morgan Hitchcock이 VentureBeat에 말했습니다. “그 이유는 다섯 개의 서로 다른 데이터베이스에 다섯 개의 서로 다른 쿼리를 보내야 하고, 각 데이터베이스가 보유한 지식이나 컨텍스트만을 사용하기 때문입니다.”

이 아키텍처는 개발자들 사이에서 큰 반향을 일으켰으며, 현재까지 230만 건의 다운로드와 31,000개의 GitHub 스타를 기록하고 있습니다. 기존 배포 사례로는 자동차 및 방위 시스템의 엣지 디바이스, 뉴욕 대형 소매업체의 제품 추천 엔진, Android 광고 서빙 기술 등이 있으며, 이는 모두 Hitchcock이 언급한 바 있습니다.

Source: (원본 링크가 제공되지 않았습니다)

에이전시 AI 메모리가 데이터베이스에 내장됨

SurrealDB는 에이전트 메모리를 애플리케이션 코드나 외부 캐시 레이어가 아니라 데이터베이스 자체에 그래프 관계와 의미 메타데이터로 저장합니다.

SurrealDB 3.0의 Surrealism 플러그인 시스템을 통해 개발자는 에이전트가 이 메모리를 구축하고 조회하는 방식을 정의할 수 있습니다; 이 로직은 미들웨어가 아니라 트랜잭션 보장을 갖는 데이터베이스 내부에서 실행됩니다.

실제로 이것이 의미하는 바는 다음과 같습니다: 에이전트가 데이터와 상호작용할 때 컨텍스트 그래프를 생성하여 엔터티, 결정, 도메인 지식을 데이터베이스 레코드로 연결합니다. 이러한 관계는 벡터 검색과 구조화된 데이터를 위해 사용되는 동일한 SurrealQL 인터페이스를 통해 쿼리할 수 있습니다. 고객 이슈에 대해 질문하는 에이전트는 그래프 연결을 따라 과거 유사 사건을 탐색하고, 유사 사례의 벡터 임베딩을 가져오며, 구조화된 고객 데이터와 조인할 수 있습니다—모두 하나의 트랜잭션 쿼리 안에서 이루어집니다.

“사람들은 이제 최신 데이터만 저장하고 싶어하지 않습니다,” 히치콕이 말했습니다. “그들은 모든 데이터를 저장하고 싶어합니다. 조직의 지난 1~2년간 모든 데이터를 분석하고 AI가 이해하도록 하여, 그 데이터가 모델과 AI 에이전트에게 컨텍스트와 역사를 제공하도록 함으로써 더 나은 결과를 도출할 수 있게 하길 원합니다.”

SurrealDB의 아키텍처가 기존 RAG 스택과 다른 점

전통적인 RAG 시스템은 데이터 유형에 따라 데이터베이스를 쿼리합니다. 개발자는 벡터 유사도 검색, 그래프 탐색, 관계형 조인을 위한 별도 쿼리를 작성하고, 애플리케이션 코드에서 결과를 병합합니다. 이 과정에서 시스템 간 라운드‑트립이 발생해 동기화 지연이 생깁니다.

반면 히치콕은 SurrealDB가 데이터를 바이너리 인코딩된 문서 형태로 저장하고, 그래프 관계를 문서와 직접 함께 포함시킨다고 설명했습니다. SurrealQL을 통한 단일 쿼리만으로도:

• 그래프 관계 탐색
• 벡터 유사도 검색 수행
• 구조화된 레코드 조인

— 모두 데이터베이스를 떠나지 않고 수행할 수 있습니다.

이 아키텍처는 규모에 따른 일관성에도 영향을 미칩니다. 모든 노드가 50개 이상의 노드 규모에서도 트랜잭션 일관성을 유지합니다. 에이전트가 노드 A에 새로운 컨텍스트를 기록하면, 노드 B에서의 쿼리가 즉시 해당 업데이트를 확인합니다. 캐시도, 읽기 복제본도 없습니다.

“우리의 많은 사용 사례와 배포 환경은 데이터가 지속적으로 업데이트되고, 그 데이터 간의 관계, 컨텍스트, 의미적 이해 혹은 그래프 연결이 지속적으로 새로워져야 하는 경우입니다.” 그는 말했습니다. “그래서 캐시가 없고, 읽기 복제본도 없습니다. SurrealDB에서는 모든 것이 트랜잭션으로 처리됩니다.”

이것이 기업 IT에 의미하는 바

“SurrealDB가 모든 작업에 가장 적합한 데이터베이스가 아니라는 점을 말하는 것이 중요합니다. 우리가 최고라고 말하고 싶지만, 그렇지 않으며, 그렇게 될 수도 없습니다,”라고 히치콕은 말했습니다. “만약 페타바이트 규모의 데이터를 분석만 필요하고 그 데이터를 거의 업데이트하지 않는다면, 객체 스토리지나 컬럼형 데이터베이스를 사용하는 것이 가장 좋습니다. 벡터 검색만 다루는 경우라면 Quadrant나 Pinecone과 같은 벡터 데이터베이스를 사용하면 충분합니다.”

전환점은 여러 데이터 유형을 함께 사용할 필요가 있을 때 찾아옵니다. 실질적인 이점은 개발 일정에서 나타납니다: 다중 데이터베이스 오케스트레이션으로 구축하는 데 몇 달이 걸리던 것이 이제는 며칠 안에 출시될 수 있다고 히치콕은 말했습니다.