Smart Agentic AI 구축을 위한 데이터베이스 설계 - Amazon Web Services (AWS)

Smart Agentic AI 구축을 위한 데이터베이스 설계 들어가며 에이전트 서비스 특히, MCP(Model Context Protocol) 서버가 새로운 메인 트렌드로 부상하고 있습니다. 많은 것들이 빠르게 변하고, 그 변화에 적응하기 조차 어려운 시대가 되었습니다. 이 블로그에서는 에이전트 서비스들의 근간에 흐르는 데이터에 초점을 맞추고자 합니다. 에이전트 아키텍쳐는 여러가지 종류가 있습니다. 비동기 Pub/Sub 메시징 기반의 멀티에이전트 프레임워크인 AutoGen, 오늘 중점적으로 논의할 그래프 기반의 워크플로우를 자유롭게 정의하는 LangGraph, 빠른 Poc에 적합한 코드중심의 미니멀 에이전트인 Smolagent 등등 여러가지가 있습니다. 특히 Strands Agent 와 같이 동적으로 도구(Tool)를 선택하고 노드를 붙여나가는 에이전틱 워크플로우는 이미 정의되어 있는 정적인 워크플로우에 비해서, 많은 자유도와 사용자의 다양한 요구사항에 유연하게 대처할수 있습니다. 최근에는 Manus Agent도 나왔습니다. Strands와 Manus Agent는 기존에 비해 훨씬 진일보한 아키텍쳐임에는 틀림 없습니다. 다만, 늘 반복되는 프로세스들조차도 실행하는 사람들마다 다른 결과를 얻기도 하고, 한개의 단순한 명령을 수행하기 위해서도 여러번의 시도와 에러가 반복되는 경우들도 있습니다. 그러면 그때마다 반복적인 실패를 하고 원하는 결과를 얻어야만 하는 걸까요? 그 뿐만 아닙니다. 사용자가 요청했을 때, 생성형 AI가 추론하고 처리했던 여러가지 내용들도 다음 비슷한 요청을 위한 컨텍스트로 활용되지 않는 경우도 많습니다. 새로운 누군가가 유사한 질문을한다면 어떻게 될까요? 같은 대답을 생성하느라 토큰과 시간을 소모할 필요가 있을까요? 특히, 프로세스가 잘못된 경우 잘못된 응답을 반복하고 토큰과 시간도 그대로 낭비해야 할까요? 이것은 프롬프트 캐싱을 사용하더라도 결국은 마찬가지가 될것입니다. 그렇다면, 에이전트의 사용자의 요청 처리내역을 저장해서, 그 데이터를 분석하고 최적의 프로세스를 정립하면 어떨까요? 이것이 이제부터 말씀드리려는 내용입니다. 에이전트의 데이터 저장을 위한 데이터베이스는 구체적으로 어떤 데이터베이스가 어떤 용도로 사용되야 하고, 데이터베이스 내의 스키마 설계는 어떻게 해야할까요? 이 블로그에서는 여러 에이전트 아키텍쳐 가운데, LangGraph와 Strands Agent를 기반으로 데이터베이스 설계를 이야기해보려고 합니다. 에이전트 서비스를 위한 데이터베이스 아키텍쳐 에이전트는 그 안에 여러가지 도구(Tool)들을 가지고 있습니다. (이하 툴이라고 하겠습니다) 이러한 툴을 미리 사전에 정의한 순서에 따라 처리되도록 하면 에이전트 자동화가 이루어집니다. Strands Agent와 같은 아키텍쳐에서는 고정된 워크플로우가 아니라 필요에 따라 에이전트가 판단하고 동적으로 워크플로우를 상황에 맞게 변경할수 있습니다. 매우 편리한 기능이지만, 한편으로는 원하는 결과를 얻기까지 통제가 어렵고 원하지 않는 결과를 얻는 경우 자칫하면 큰 문제가 생길수도 있습니다. 사실 이러한 부분때문에 PoC(Proof Of Concept)와 같은 프로젝트는 많지만, 실제 운영서비스에 에이전트 자동화 서비스를 적용하기는 쉽지 않습니다. 그래서 에이전트가 안정화된 자동화 프로세스를 정립하기까지 책임있는 사람의 개입과 통제(Human-in-the-Loop)가 부분적으로 필요하게 됩니다. 에이전트가 프로세스를 자동으로 실행하기전에 실행계획을 시각적으로 보여주면, 사람이 먼저 리뷰하고, 프로세스를 수정하거나 추가 또는 삭제하도록 합니다. 사후 리뷰도 수행하게 합니다. 주기적인 배치 리뷰 프로세스를 두어, 에이전트 스스로, 처리한 프로세스들을 평가하게 하고, 이것을 최종적으로 사람이 리뷰하여 프로세스를 보완하게 합니다. 실행된 내용들은 저장했다가 비슷한 요청이 들어오면, 이 프로세스들의 실행이력을 컨텍스트로 생성형 AI서비스에 제공하거나, 아예 기존 프로세스 그대로 재사용할 수도 있습니다. 바로 여기에 데이터베이스의 역할이 있습니다. 이렇게 사람의 승인과 검토를 거친 에이전트의 검증된 프로세스는 더욱 신뢰할수 있고 안정적으로 처리되며, 궁극적으로는 에이전트의 자동화 목표를 이루는데 도움을 줄 수 있습니다. 자, 그렇다면 어디에 무엇을 저장하면 될까요? Amazon DynamoDB : 에이전트가 실행한 모든 프로세스와 툴 실행 이력을 저장 에이전트가 처리한 내역들 성공한 프로세스와 툴 실행이력들은 DynamoDB에 저장하도록 합니다. DynamoDB는 Key-Value(키-값) 형태의 NoSQL Database로서, 사용 트래픽의 많고 적음에 영향받지 않고, 빠른 성능을 일관되게 유지하면서, 한편으로는 다양한 형태의 비정형 데이터를 유연하게 저장하는 장점을 가지고 있습니다. DynamoDB를 에이전트 서비스의 메인데이터를 저장하는 가장 큰 이유는, 바로 LangGraph의 각 노드들이 가지고 있는 키-밸류 값을 저장하는데 적합한 구조를 가지고 있기 때문이기도 합니다. Amazon Redshift : 에이전트의 실행이력을 분석하여, 최적의 프로세스를 제안 이렇게 저장된 프로세스와 툴 실행이력을 저장하는 것으로 끝나지 않습니다. 에이전트가 실행한 많은 프로세스들에는 여러가지 성공, 실패와 그 이유들이 저장되어있습니다. 이 정보들을 Redshift로 보내서 분석하게 하여, 가장 안정적이면서 검증된 프로세스를 사용자에게 제안해줄수 있습니다. DynamoDB는 ZeroETL로 Redshift에 데이터를 준실시간으로 연동할수 있습니다. 실행된 사용자의 프로세스 이력을 Redshift에서 분석한 내용을 바탕으로, 사용자의 프로세스 워크플로우에 스코어를 매겨, 가장 신뢰할수 있는 안정적인 최적의 프로세스 워크플로우를 사용자에게 제안하게 합니다. 그래서 이전에 처리된 프로세스와 비슷한 요청이 올 때, 성공적으로 처리된 프로세스를 먼저 리스트 업하여, 생성형 AI가 같은 답이나 결과를 처리하기 위해 불필요한 토큰과 시간을 낭비하지 않도록 합니다. 스코어의 기준을 정하는 것은 다양한 방식으로 정할수 있습니다. 에이전트의 특정 프로세스의 성공/실패건수, 최근 실행한 내용인지, 사용자들의 조회/실행횟수를 스코어에 더할수도 있습니다. 아래는 스코어를 정하는 하나의 예시로 여러분들의 상황에 맞춰서 다양한 방식으로 스코어의 기준을 정하고 테스트하면서 수정 또는 추가할 수 있습니다. - 스코어 = 총실행건수 × exp{-0.1 ×(오늘일시-최근실행일시) } × (성공건수/실행건수)² 위 스코어 계산 방식은 지수감쇠를 통해서 가장 최신 프로세스가 자연스럽게 상위로 올라오게 하고 성공률은 제곱하여 높은 신뢰도를 가진 워크플로우가 상위에 랭크되게 합니다. 이외에도 여러가지 방식을 고려해볼 수 있을 것입니다. Amazon Elasticache for Valkey : 자주 사용된 프로세스를 메모리에 올려서 성능 최적화 사용자가 채팅창에서 문의나 요청을 하게 되면, 먼저 생성형AI 서비스가 사용자의 요청을 판단하는데, 이때 먼저 Amazon ElastiCache for Valkey에서 해당내용이 있는지 확인하고, 없으면 DynamoDB를 조회하고 유사한 프로세스들이 있는지를 확인합니다. 만약 없다면, 새로운 프로세스를 만들고 이 프로세스들의 집합을 DynamoDB에 저장하고 처리결과도 DynamoDB에 저장합니다. Valkey 역시 Key-Value형태의 구조를 가지고 있어, 에이전트의 각 노드들의 상태값을 저장하기에 적합한 형태입니다. 또한 모든 노드의 상태값을 일일이 저장하지 않아도, 사용자가 요청을 중단하는등의 불필요한 임시 데이터는 버림으로써, 불필요한 데이터 저장공간도 절약할수 있습니다. 그리고 자주 사용하는 프로세스의 컨텍스트를 Valkey에서도 활용합니다. Redshift에서 분석하여 업데이트한 스코어값이 높은 에이전트의 프로세스 이력도 메모리에 올리고 계속 유지시킴으로써 사용자들이 가장 많이 요청하는 프로세스를 성능/비용 효율적으로 처리합니다. 에이전트를 위한 데이터베이스 아키텍쳐의 활용방법 위에서 열거한 여러 데이터베이스로 구성된 아키텍쳐는 다음과 같습니다. - 먼저 사용자 세션의 대화 및 에이전트의 실행이력은 Valkey에서 먼저 처리합니다. - Valkey 에서 조회할 데이터가 없는 경우는 DynamoDB를 조회합니다. - Valkey 에서 처리한 내역은 비동기 방식으로 DynamoDB에 저장합니다. - DynamoDB가 저장한 에이전트의 처리내역들은 ZeroETL로 Redshift로 보내집니다. - Redshift에서는 그동안 처리한 사용자 세션의 대화 및 에이전트의 실행이력을 다각도로 분석하고 스코어를 매깁니다. - Lambda가 Redshift에서 프로세스의 스코어를 다시 DynamoDB 테이블과 Valkey의 통계정보에 업데이트 합니다. - Valkey와 DynamoDB 에서 스코어가 낮은 실행이력들은 디폴트로 설정된 TTL값(예시:30일)에 따라 자연스럽게 삭제됩니다. - Valkey와 DynamoDB 에서 스코어가 높은 실행이력들은 TTL값(예시:60일)로 업데이트 하는 방식으로 계속 유지시킵니다. - 이 작업이 순환/반복되며, 성공횟수가 높은 프로세스만 살아남고, 스코어가 높은 에이전트가 먼저 조회됩니다. 전체적인 아키텍쳐에 대한 설명은 여기까지 말씀드리고, 이제부터는 블로그의 가장 핵심 주제인 에이전트 서비스에 대한 데이터베이스의 스키마 설계에 대해서 구체적으로 설명하겠습니다. 에이전트 서비스 실행이력을 저장하는 데이터베이스 스키마 설계 데이터베이스 스키마 설계에서는 개념 정립이 중요합니다. 해당 비즈니스나 서비스에 대한 이해와 배경지식이 깊을수록, 유연하고 효과적인 스키마 를 설계할 수 있습니다. 먼저 에이전트 서비스는 어떤 일을 하는지 정리해보겠습니다. 에이전트 내부에는 각각의 역할을 담당하는 노드들로 구성이 되어있고, 이 노드들은 워크플로우로 순서대로 각 노드들이 연결됩니다. 에이전트의 각 노드들은 사용자의 요청을 처리하고 다음 단계의 노드에게 상태값을 전달합니다. LangGraph의 아키텍쳐를 기반으로 좀 더 세부적인 역할을 설명하면 다음과 같습니다. - 에이전트 서비스가 사용자의 요청을 처리하려면 사