에이전트 데이터베이스란 무엇인가?
프로덕션 AI 에이전트를 위한 메모리, 상태, 검색 및 거버넌스
요약
에이전트 데이터베이스는 AI 에이전트가 기억하고, 검색하고, 행동하기 위해 의존하는 데이터 레이어입니다. 이는 자율 에이전트가 프로토타입에서 운영 단계로 전환하는 데 필요한 영구 메모리, 지속 상태, 멀티모달 검색, 저지연 액세스, 그리고 거버넌스를 제공합니다. 기업들이 AI 에이전트 배포를 확장함에 따라, 에이전트 데이터베이스는 실패하는 파일럿 프로젝트와 대규모로 안정적으로 실행되는 시스템을 구별하는 근본적인 인프라로 부상했습니다.
에이전트 데이터베이스란 무엇인가? 작동 정의
에이전트 데이터베이스는 목적에 맞게 구축된 데이터 레이어로, AI 에이전트 세션, 작업, 사용자 전반에 걸쳐 문맥을 잃거나 권한 범위를 벗어나지 않고 에이전트가 작동하는 데 필요한 모든 것. 에이전트가 수행한 작업을 저장하고, 에이전트가 알아야 할 내용을 검색하며, 다단계 워크플로에서 에이전트의 위치를 추적하고, 에이전트가 액세스할 수 있는 권한을 적용합니다.
에이전트 데이터베이스는 저장 모델이 아니라 그것이 수행하는 역할에 의해 정의된다. 그것은 가 아니며 벡터 데이터베이스 좁은 검색 기능을 갖추고 있으며, 인간이 주도하는 트랜잭션에 최적화된 전통적인 운영 데이터베이스가 아닙니다. 이는 프로덕션 환경에 있는 자율형 AI 에이전트의 데이터 요구사항에 맞춰 구체적으로 형성된 다기능 데이터 계층입니다.
아래의 내용은 에이전트 데이터베이스를 정의하는 다섯 가지 요건, 에이전트 데이터베이스가 인접 개념과 다른 점, 멀티 모델 데이터베이스가 에이전트 워크로드에 적합한 이유, Couchbase가 실제로 이 계층을 구현하는 방식, 그리고 이러한 요건에 따라 플랫폼을 평가하기 위한 체크리스트를 다룹니다.
- AI 에이전트가 데이터 계층에서 필요로 하는 것
- 에이전트 데이터베이스 대 인접 개념
- 멀티모들 데이터베이스가 에이전트 워크로드에 적합한 이유
- 카우베이스가 에이전트 데이터베이스를 구현하는 방법
- 주요 내용 및 관련 리소스
- 자주 묻는 질문
AI 에이전트가 데이터 계층에서 필요로 하는 것
에이전트 데이터베이스는 다섯 가지 핵심 요건을 충족해야 하며, 그에 못 미치는 것은 목적을 무색하게 만듭니다. 데이터베이스가 네 가지 요건을 잘 처리하더라도 다섯 번째 요건을 위한 별도의 시스템이 여전히 필요하며, 이는 통합 데이터 레이어가 제거하도록 설계된 단편화와 지연 시간을 다시 유발할 것입니다. 다섯 가지 요건은 다음과 같습니다:
기억
에이전트 데이터베이스는 모든 프롬프트마다 컨텍스트를 다시 전송할 필요 없이 세션, 재시작, 사용자 간에 컨텍스트를 유지해야 합니다. 에이전트 메모리는 세 가지 수준에서 작동합니다.
- 단기 기억 현재 대화 컨텍스트와 활성 세션 상태를 유지합니다.
- 장기 의미 기억 세션 간에 유지되어야 하는 관찰 결과와 사실을 저장합니다. 이 정보는 일반적으로 의미론적 유사성을 기반으로 검색할 수 있도록 벡터 임베딩으로 저장됩니다.
- 프로필 메모리 결정론적이고 지연 시간이 짧은 조회가 필요한 기본 설정 및 액세스 권한과 같은 구조화된 사용자 속성을 저장합니다.
영구적인 메모리가 없으면, 모든 세션은 처음부터 시작되며 모든 사용자를 낯선 사람처럼 대합니다. 에이전트는 이미 완료한 단계를 반복해야 하며, 이전 상호작용을 바탕으로 발전할 수 없습니다. 대규모로 볼 때, 이러한 상태 비저장성(statelessness)은 에이전틱 AI를 가치 있게 만드는 사용자 경험을 파괴합니다.
상태
여러 단계의 작업을 수행하는 에이전트는 지속적이고 검사 가능한 방식으로 해당 작업의 진행 상황을 추적해야 합니다. 에이전트가 충돌하거나 재시작되거나 다른 에이전트에 작업을 인계할 때, 작업 상태는 유지되어야 하고 다음 프로세스에서 읽을 수 있어야 정확히 이러한 종류의 연속성을 지원하는 에이전트 데이터베이스는 지속적이고 구조화된 상태 스토리지를 제공합니다. 또한 엔지니어링 및 컴플라이언스 팀이 에이전트가 무엇을 언제 수행했는지 이해하는 데 필요한 가시성을 제공합니다.
검색
에이전트는 단일 쿼리로 벡터, 문서, 정형 데이터 전반에서 관련 컨텍스트를 가져와야 합니다. 이를 멀티모달 검색이라고 하며, 이는 벡터 전용 검색과 구별되는 핵심적인 특징입니다.
단일 작업에서 프로덕션 에이전트는 벡터 검색을 사용하여 의미론적으로 유사한 문서를 검색하고, 계정 상태나 날짜와 같은 구조화된 속성으로 결과를 필터링하며, 키를 기준으로 특정 값을 조회해야 할 수 있습니다. 벡터 유사도 검색만 지원하는 데이터 레이어는 애플리케이션 레이어가 나머지 검색 모드를 조합하도록 요구하므로 지연 시간과 복잡성이 가중됩니다.
벡터 검색 역량 있는 에이전트 데이터베이스의 구성 요소일 뿐이며, 그 대체제가 아닙니다.
저지연
단일 추론 호출 동안 에이전트는 메모리를 검색하고, 컨텍스트를 가져오며, 상태를 확인하고, 관찰 내용을 기록하기 위해 데이터 레이어와 수많은 순차적 왕복 통신을 수행합니다. 각 홉마다 지연 시간이 추가되며, 이 지연 시간은 다단계 에이전트 워크플로우 전반에 걸쳐 누적됩니다. 에이전트 데이터베이스는 일관되게 1초 미만의 읽기 및 쓰기 성능을 제공해야 하며, 이를 위해서는 모든 요청마다 디스크에서 데이터를 가져오는 대신 RAM에서 핫 데이터를 제공하는 메모리 우선(memory-first) 아키텍처가 필요합니다.
프로덕션 에이전틱 워크로드에서 인메모리 데이터베이스 요구사항은 선택사항이 아닙니다. 단일 사용자 부하 하의 데모 데이터셋에서는 허용 가능한 지연 시간으로 작동하는 데이터 레이어라도, 프로덕션 에이전트가 실제 세계에서 생성하는 읽기/쓰기 밀도를 견뎌내지 못할 것입니다.
거버넌스
기록 업데이트, 메시지 전송, 워크플로 트리거 등 현실 세계의 작업을 수행할 수 있는 에이전트는 인프라 수준에서 적용되는 제어 장치로 제한되어야 합니다. 에이전트 데이터베이스가 제공하는 기능은 다음과 같습니다:
- 에이전트가 읽고 쓸 수 있는 데이터를 정의하는 역할 기반 접근 제어
- 에이전트가 어떤 데이터와 도구에 언제 접근했는지 기록하는 감사 추적(Audit trails)
- 에이전트가 호출한 프롬프트 및 함수에 대한 가시성
규제 산업에서 이러한 통제 장치는 선택 사항이 아니며, 모든 기업용 AI 배포에서 그 필요성이 점차 커지고 있습니다.
데이터 레이어에 거버넌스가 내장되어 있지 않으면, 에이전트 시스템은 규모가 커짐에 따라 예측 불가능하고 통제 불능 상태가 됩니다. 애플리케이션 레이어에 거버넌스를 덧붙이면 시스템이 취약해지고 감사가 어려워집니다.
에이전트 데이터베이스 대 인접 개념
에이전트 데이터베이스 카테고리는 여전히 정의되는 중이며, 그 결과 여러 인접한 용어들이 의미 있는 차이를 모호하게 만드는 방식으로 혼용되고 있습니다. 개념 간의 차이는 다음과 같습니다:
에이전트 데이터베이스 대 벡터 데이터베이스
벡터 데이터베이스는 고차원 임베딩을 저장하고 유사성에 기반하여 정보를 검색합니다. 에이전트 데이터베이스는 다양한 유형의 메모리, 지속성 상태, 멀티모달 검색, 저지연 액세스, 거버넌스를 지원하는 더 넓은 데이터 계층을 제공합니다. 벡터 검색은 그 계층의 중요하지만 단일한 일부분일 뿐입니다. 독립형 벡터 데이터베이스를 선택하는 경우, 다른 시스템들을 별도로 조립해야 합니다.
에이전트 데이터베이스 대 에이전트 메모리
에이전트 메모리는 시스템이 아니라 기능이다. 이는 에이전트가 무엇을 할 수 있는지(세션 간에 컨텍스트를 유지하고 검색하는 것)를 설명하는 것이지, 그 기능이 어디에 존재하는지를 나타내는 것은 아니다. 에이전트 데이터베이스는 메모리, 상태, 검색, 캐시, 거버넌스가 함께 존재하는 시스템이다. 메모리 전용 구현은 여전히 검색, 상태, 거버넌스를 다른 곳에서 처리해야 하므로 이러한 구별은 중요하다. 이는 일반적으로 문제를 해결하기보다는 단편화를 가중시키는 개별 솔루션 모음으로 처리되곤 한다.
RAG 아키텍처에서 메모리가 어떻게 적용되는지에 대한 더 자세한 내용을 보려면 다음을 참조하세요. 에이전트형 RAG 설명자.
에이전트 데이터베이스 대 전통적인 데이터베이스
전통적인 관계형 및 문서형 데이터베이스는 애플리케이션 데이터를 저장하고 검색하는 데 탁월하며, 사용자나 미리 정의된 코드가 로직을 구동하는 애플리케이션을 위해 구축되었습니다. 에이전트는 다른 요구사항을 가지고 있습니다. 에이전트는 메모리를 지속적으로 읽고 써야 하고, 실시간으로 관련 컨텍스트를 검색해야 하며, 도구 및 데이터와 상호작용할 때 거버넌스를 적용해야 하고, 에이전트 간에 작업이 이동할 때 공유 상태를 유지해야 합니다. 전통적인 데이터베이스는 커스텀 코드와 추가 시스템을 통해 이러한 요구사항을 지원할 수 있지만, 에이전트 데이터베이스는 그러한 기능들을 대신 데이터 계층에서 하나로 모아줍니다.
멀티모들 데이터베이스가 에이전트 워크로드에 적합한 이유
프로덕션 AI 에이전트는 빠른 메모리 및 캐시 조회를 위한 키-값 액세스, 정형 데이터를 검사하고 추론하기 위한 쿼리 레이어, 문서 검색을 위한 전문 및 하이브리드 검색, 그리고 시맨틱 유사도를 위한 벡터 검색이 필요합니다.
A 다중 모델 데이터베이스 이 모든 접근 패턴을 네이티브로 처리하는 시스템이 에이전트 워크로드에 이상적인 아키텍처입니다. 단일 목적의 벡터 데이터베이스는 검색은 담당하지만 메모리, 상태, 거버넌스는 외부에 맡깁니다. 전통적인 문서 또는 관계형 데이터베이스는 영속성과 쿼리는 담당하지만 네이티브 의미 검색과 프롬프트 캐싱, 의미 중복 제거 같은 LLM 전용 기능이 부족합니다.
인메모리, 실시간, 문서 지향 NoSQL 기반 구조는 에이전트가 필요로 하는 바와 정확히 일치합니다. 이는 1밀리초 미만의 지연 시간으로 메모리 우선 읽기를 제공하고, 스키마 제약 없이 에이전트의 관찰 결과와 구조화된 상태를 저장하는 유연한 JSON 문서를 지원하며, 성능 저하 없이 에이전트 배포 볼륨과 함께 성장하는 수평적 확장을 제공합니다.
카우치베이스의 멀티 모델 데이터베이스는 SQL++ 에이전트와 엔지니어링 팀이 문서, 벡터, 전문 검색(full-text), 키-값 데이터 전반에서 단일 쿼리 언어를 사용할 수 있도록 하기 위함입니다. 여러 API를 호출하며 오케스트레이션하는 대신, 에이전트는 하나의 언어로 하나의 시스템에 쿼리하여 통합된 결과를 얻습니다. 또한 이를 통해 엔지니어들은 동일한 쿼리 언어를 사용하여 에이전트가 무엇을 검색하고 이에 따라 어떤 조치를 취했는지 감사(audit)할 수 있으므로 에이전트의 동작을 검사할 수 있게 됩니다.
카우치베이스도 제공합니다 전체 텍스트 검색 벡터 및 구조화된 쿼리 기능이 네이티브로 통합되어 있습니다. 즉, 하이브리드 검색(단일 쿼리 내에서 벡터 유사도 + 키워드 + 메타데이터 필터)이 애플리케이션 코드에서 조합되는 것이 아니라 데이터베이스 내부에서 처리됩니다.
카우베이스가 에이전트 데이터베이스를 구현하는 방법
그리고 쿠체베이스 AI 데이터 플레인™ Couchbase의 JSON 네이티브, 메모리 우선, 스케일 아웃 플랫폼 위에 구축된 목적형 에이전트 데이터베이스 레이어입니다. 이는 프로덕션급 에이전틱 애플리케이션을 구축하는 엔터프라이즈를 위해 설계되었으며 위에 정의된 다섯 가지 요구사항에 직접적으로 부합합니다.
| 요구사항 | AI 데이터 플레인 기능 |
|---|---|
| 기억 | 에이전트 메모리 단일 API를 통해 단기 대화 컨텍스트, 장기 시맨틱 메모리, 프로필 메모리를 저장합니다. 모든 메모리 블록은 임베딩 벡터, 요약, 컨텍스트, 타임스탬프, 그리고 보존 준수를 위한 설정 가능한 TTL을 갖춘 구조화된 JSON 문서입니다. |
| 상태 | 구조화된 JSON 문서로 저장되는 내구성 있고 검사 가능한 작업 상태. 상태는 재시작 및 에이전트 핸드오프 후에도 유지되며, 감사 및 디버깅을 위해 SQL++를 통해 쿼리할 수 있습니다. |
| 검색 | 하나의 엔진에서 네이티브 벡터 검색, 전문 검색(full-text search), 하이브리드 검색, 키-값 접근을 제공합니다. 동기화할 별도의 시스템이 필요하지 않습니다. |
| 저지연 | 메모리 우선 아키텍처는 하위 밀리초의 지연 시간으로 RAM에서 핫 에이전트 데이터를 제공합니다. 내장된 LLM 캐시는 동일하거나 의미론적으로 유사한 프롬프트에 대한 응답을 저장하고 재사용하여 대규모 환경에서 토큰 비용과 추론 지연 시간을 줄입니다. |
| 거버넌스 | MCP 서버 Model Context Protocol 표준을 구현하여, 모델이 도구 및 데이터에 연결할 수 있도록 구조화되고 관리되는 인터페이스를 제공합니다. Agent Catalog는 도구, 프롬프트 및 에이전트 기능을 체계적으로 관리하는 레지스트리로, 모든 에이전트 동작 및 데이터 액세스에 대한 완전한 감사 로그를 제공합니다. |
AI 데이터 플레인은 다음에서 실행됩니다 카우치베이스 카펠라, AWS, Azure, Google Cloud에서 모두 이용할 수 있는 완전 관리형 DBaaS입니다. 또한 자체 관리형 및 하이브리드 구성에서도 구동되며, 다음을 통해 엣지 및 오프라인 환경까지 확장됩니다. Couchbase Lite (카우치베이스 라이트) 연결이 복구되면 클라우드와 자동으로 양방향 동기화됩니다.
Couchbase는 에이전트 워크로드는 잘 처리하지만, 기본 액세스 패턴으로 심층적인 그래프 탐색을 수행하기에는 적합하지 않습니다. 전용 그래프 데이터베이스 엔진이 그 목적에 더 부합합니다.
주요 내용 및 관련 리소스
에이전트 데이터베이스는 AI 에이전트 프로토타입을 프로덕션 시스템과 분리하는 인프라 레이어입니다. 자율 에이전트가 엔터프라이즈 워크플로우에서 더 중대한 역할을 맡게 됨에 따라, 이들이 의존하는 데이터 레이어는 다른 컴퓨팅 시대를 위해 설계된 시스템을 조합하는 것이 아니라 에이전트의 요구사항을 중심으로 구축되어야 합니다.
주요 내용:
- 에이전트 데이터베이스는 저장 모델이 아니라 역할에 의해 정의됩니다. 이는 AI 에이전트가 세션과 작업 전반에 걸쳐 메모리, 상태, 검색, 거버넌스를 위해 사용하는 데이터 계층입니다.
- 이 범주를 정의하는 다섯 가지 요건은 다음과 같습니다: 영속 메모리, 내구성 있는 상태, 다중 모드 검색, 1초 미만의 지연 시간, 인프라 수준의 거버넌스. 이 다섯 가지 요건 중 네 가지를 충족하는 플랫폼이라 할지라도 여전히 다섯 번째 시스템이 필요하며, 이는 에이전트 데이터베이스가 제거하고자 하는 분산 현상을 다시 초래하게 됩니다.
- 에이전트 데이터베이스는 벡터 데이터베이스와 같지 않습니다. 벡터 검색은 에이전트 데이터베이스의 하나의 검색 구성 요소일 뿐, 전체 데이터 계층을 대체할 수 없습니다.
- 에이전트 메모리는 하나의 기능입니다. 에이전트 데이터베이스는 메모리와 상태, 검색, 캐시, 거버넌스가 통합된 시스템으로 존재하는 곳입니다.
- 애플리케이션 측의 조합(스itching) 없이 키-값, 문서, 전문 검색, 하이브리드, 벡터 액세스를 단일 엔진에서 처리하는 멀티 모델 데이터베이스는 에이전트 워크로드에 적합한 아키텍처입니다.
- Couchbase AI Data Plane은 에이전트 메모리, 영구 상태 스토리지, 네이티브 멀티모달 검색, LLM 캐시를 활용한 메모리 우선 지연 시간, MCP 서버 및 에이전트 카탈로그를 통한 거버넌스 액세스의 다섯 가지 요구 사항 모두에 직접 대응합니다.
- 엔터프라이즈 AI 배포에 있어서 인프라 수준의 거버넌스(접근 제어, 감사 추적, 도구 및 프롬프트 가시성)는 선택 사항이 아닙니다. 이는 애플리케이션 계층에 덧붙이는 것이 아니라 데이터 계층에 내장되는 것이 가장 좋습니다.
관련 자료:
자주 묻는 질문
에이전트 데이터베이스란 무엇인가요? 에이전트 데이터베이스는 AI 에이전트가 기억하고, 정보를 검색하며, 행동을 수행하는 데 의존하는 데이터 계층입니다. 이 데이터베이스는 세션과 사용자를 초월한 영구적인 메모리, 다단계 작업 전반에 걸친 내구성 있는 상태 추적, 벡터, 문서 및 구조화된 데이터를 아우르는 다중 모드 검색, 1초 미만의 읽기 및 쓰기 지연 시간, 그리고 접근 제어 및 감사 로깅을 포함한 거버넌스 제어 기능을 제공합니다. 이는 단일 스토리지 모델이 아닌, 자율 에이전트를 지원하는 데 있어 수행하는 역할에 의해 정의됩니다.
AI 에이전트는 데이터베이스에서 무엇을 필요로 할까요? AI 에이전트는 데이터 계층에서 다섯 가지가 필요합니다. 세션 경계와 에이전트 재시작 시에도 유지되는 지속성 메모리, 다단계 워크플로우 전반의 진행 상황을 추적하는 지속성 및 검사 가능 상태, 단일 쿼리 내에서 벡터, 전문 검색, 구조화된 데이터를 아우르는 멀티모달 검색, 모든 에이전트 왕복(round trip)에서 읽기와 쓰기의 1초 미만 지연 시간, 그리고 인프라 수준에서 접근 제어를 시행하고 감사 추적을 유지하는 거버넌스입니다. 에이전트 데이터베이스로 평가되는 모든 플랫폼은 특정 워크로드에 맞게 가중치를 조정하여 이 다섯 가지 항목 모두에 대해 평가되어야 합니다.
에이전트 데이터베이스와 벡터 데이터베이스의 차이점은 무엇인가요? 벡터 데이터베이스는 고차원 임베딩을 저장하고 유사도에 따라 결과를 검색합니다. 이는 하나의 검색 문제를 해결합니다. 에이전트 데이터베이스는 에이전트가 작동하는 전체 데이터 계층으로, 여러 수준의 메모리, 영구 상태, 다중 모달 검색(벡터 검색이 그 구성 요소 중 하나임), 저지연 액세스 및 거버넌스를 처리합니다. 에이전트의 데이터 계층으로 독립형 벡터 데이터베이스를 선택하면 메모리, 상태 및 거버넌스를 별도의 시스템에서 구성해야 합니다.
에이전트 데이터베이스는 에이전트 메모리와 같습니까? 아닙니다. 에이전트 메모리는 에이전트가 세션 간에 컨텍스트를 유지하고 검색할 수 있는 기능을 의미합니다. 에이전트 데이터베이스는 메모리뿐만 아니라 검색, 상태, 캐시, 거버넌스 기능을 함께 제공하는 시스템입니다. 메모리 전용 구현 방식의 경우에도 나머지 요구 사항을 충족하기 위해 추가 시스템이 필요하며, 이로 인해 전용 에이전트 데이터베이스가 제거하고자 설계된 분산 현상과 운영 오버헤드가 다시 발생하게 됩니다.
전용 에이전트 데이터베이스가 필요하십니까? 반드시 별도의 시스템으로 구매해야 하는 새로운 제품 카테고리는 아닙니다. 여러분에게 필요한 것은 메모리, 상태, 다중 모드 검색, 낮은 지연 시간, 거버넌스라는 다섯 가지 요구 사항을 모두 충족하는 데이터 계층입니다. 이 모든 요소를 하나의 엔진에서 기본적으로 처리하는 멀티모델 플랫폼은, 새로운 전용 제품이나 여러 개의 점 솔루션들을 억지로 묶어놓은 조합 없이도 에이전트 데이터베이스 역할을 수행할 수 있습니다. 스택에 전용 시스템을 추가하기 전에, 모든 플랫폼을 이 다섯 가지 요구 사항에 비추어 평가해 보십시오.
에이전트 데이터베이스는 어떻게 평가합니까? 다음 다섯 가지 요건을 기준으로 모든 후보자를 평가하십시오:
- 통합된 API를 통해 단기, 장기, 의미론적, 프로필 수준에 걸쳐 지속적 메모리를 지원합니까?
- 재시작 및 에이전트 인계 시에도 유지되는, 내구성이 뛰어나고 상태를 확인할 수 있는 상태 저장 기능을 제공합니까?
- 단일 쿼리로 다중 모드 검색(벡터, 전체 텍스트, 하이브리드, 키-값)을 기본적으로 처리할 수 있나요?
- 에이전트가 생성하는 읽기/쓰기 밀도 하에서 1초 미만의 지연 시간을 보장합니까?
- 인프라 수준에서 접근 제어, 감사 로깅 및 도구 거버넌스를 시행합니까?
다섯 가지 요구 사항을 모두 충족하면서도 그 어느 하나에 대해서도 별도의 시스템을 필요로 하지 않는 플랫폼이야말로 프로덕션 에이전트 배포에 적합한 아키텍처입니다.