Aegis 구축하기: Amazon Aurora와 Vercel을 활용한 디지털 유산을 위한 AI 금고

참고: 저는 이 해커톤에 참여하기 위한 목적으로 이 콘텐츠를 제작했습니다. #H0Hackathon

누군가 사망하거나 무력화되었을 때, 그들의 가족은 보통 가장 중요한 것들—보험 증권, 계정 세부 정보, 그리고 모든 것이 어디에 있는지와 다음에 무엇을 해야 하는지에 대한 단순한 지식—에 접근하지 못하게 됩니다. 그러한 정보는 한 사람의 머릿속, 편지함, 또는 아무도 찾을 수 없는 서랍 속에 들어 있습니다.

우리는 이를 해결하기 위해 Aegis를 구축했습니다. 이는 사용자의 문서를 알고 있으며, 웹이나 채팅 앱 내에서 사랑하는 사람들을 안내할 수 있는 AI 에이전트(AI agent)를 갖춘 프라이빗 금고(private vault)입니다. 이 포스트는 우리가 이를 어떻게 구축했는지, 특히 왜 데이터베이스로 Amazon Aurora를, 플랫폼으로 Vercel을 선택했는지에 대해 다룹니다.

Aegis가 하는 일

• 중요한 컨텍스트(context)를 하나의 금고에 보관: 업로드된 파일, 풍부한 마크다운(markdown) 노트, 구조화된 연락처, 그리고 보호된 자격 증명(credentials).
• 일상적인 언어로 질문에 답변: 에이전트가 금고를 검색하고, 관련 문서를 읽고, 출처를 인용합니다.
• 문서에서 추출된 갱신 및 보험료와 같이 시간이 중요한 정보를 표면화합니다.
• 소유자의 원본 로그인 정보를 노출하지 않고, 보안 부여 링크(grant link)를 통해 수혜자에게 제한된 범위의 접근 권한을 제공합니다.
• 동일한 에이전트를 사용하여 웹과 Telegram 내부에서 모두 작동합니다.

왜 Amazon Aurora인가

금고는 매우 관계적(relational)입니다. 우리는 단순히 하나의 텍스트 덩어리(blob)를 저장하는 것이 아니라, 문서, 문서의 텍스트 청크(text chunks), 연락처, 알림, 그리고 에이전트 자체의 대화 메모리를 모델링하고 있으며, 이들이 서로 깔끔하게 연결되어야 합니다. 따라서 데이터 모델이 우선적으로 설계되었으며, 이는 의도적인 것입니다:

• 업로드된 파일과 검색 가능한 텍스트를 위한 documents 및 document_chunks
• 앱 내에서 직접 작성된 마크다운 컨텍스트를 위한 notes
• 에이전트가 반환할 수 있는 구조화된 인물 및 조직을 위한 contacts
• 문서 내용에서 파생된 reminders
• 세션 간에 대화가 계속될 수 있도록 유지되는 에이전트 메모리

우리는 세 가지 이유로 Aurora PostgreSQL Serverless v2를 선택했습니다:

1. 표준 Postgres입니다. 덕분에 모든 것을 이식 가능하게(portable) 유지할 수 있었습니다. 우리의 검색(retrieval)은 독점적인 쿼리 계층이 아닌 직접 작성한 SQL을 사용하므로, 특정 기술에 종속(lock-in)되지 않습니다.
2. 서버리스 스케일링 (Serverless scaling). 개인 금고는 대부분의 시간 동안 조용하다가 누군가 실제로 필요로 할 때 급증합니다. Serverless v2는 용량을 자동으로 확장하며 라이브 데모를 진행하기에 충분할 만큼 따뜻한 상태(warm)를 유지합니다.
3. 관리형 내구성 (Managed durability). 이것은 사람들의 가장 민감한 정보입니다. Aurora의 관리형 복제(replication)와 백업이 중요합니다.

확장 기능(extensions) 없는 전문 검색 (Full-text search)

우리는 의도적으로 pgvector나 외부 검색 서비스 사용을 피했습니다. 대신 청크(chunked)된 문서들에 대해 **순수 SQL로 BM25 랭킹 (BM25 ranking)**을 작성했습니다. 에이전트는 searchVault 도구를 호출하여 가장 잘 매칭되는 스니펫(snippet)과 해당 소스 문서의 제목을 반환하며, 그 이후에 필요할 경우에만 전체 문서를 읽습니다.

그 결과: 전체 검색 파이프라인(retrieval pipeline)이 변경 없이 표준 Postgres 위에서 실행됩니다. Aurora는 마이그레이션 대상이 아닌 즉시 도입 가능한(drop-in) 선택지였으며, 검색을 작동시키기 위해 별도의 벡터 데이터베이스(vector database)를 덧붙일 필요가 전혀 없었습니다.

에이전트가 프로세스 내에 있는 Vercel을 선택한 이유

Aegis는 Vercel에 완전히 배포된 단일 Next.js 앱입니다. 흥미로운 부분은 에이전트입니다.

별도의 상시 가동되는 에이전트 서버를 실행하는 대신, 우리는 AI SDK를 사용하여 Vercel 서버리스 함수(serverless function) 내부에서 **프로세스 내 Mastra 에이전트 (Mastra agent in-process)**를 실행합니다. /api/agent/stream 경로는 에이전트를 호출하고 에이전트의 네이티브 스트리밍 청크를 NDJSON 형식으로 브라우저에 전달하여 응답이 실시간처럼 느껴지게 합니다. 동일한 에이전트가 모든 사용자층에 재사용됩니다:

• 웹에서 채팅하는 소유자
• 미들웨어에서 강제되는 상속 토큰(grant token)을 통해 권한을 부여받고, 상속 링크를 연 수혜자
• Telegram 및 WhatsApp 웹훅(webhook)을 통해 도착하는 메시지

하나의 에이전트, 하나의 검색 경로, 세 개의 접점(surfaces). 운영해야 할 중간 서버(glue server)가 없으므로 전체 시스템을 진정으로 출시 가능한(shippable) 상태로 유지할 수 있습니다.

아키텍처

Clients (Web, Telegram, WhatsApp)
        |
Vercel (Next.js, serverless)
...

우리가 배운 점

• 영리한 인덱스보다 의도적인 데이터 모델이 더 효과적입니다. 모든 것을 검색 가능한 컨텍스트 (Context)로 모델링함으로써 에이전트 (Agent)는 더 단순해졌고 답변은 더 좋아졌습니다.
• 처음부터 서버리스 함수 (Serverless function)의 제한 사항을 고려하여 설계한다면, 전용 백엔드 없이도 Vercel 위에서 실제 스트리밍 에이전트 (Streaming agent)를 완전히 실행할 수 있습니다.
• 이식성 (Portability)은 하나의 기능입니다. 검색 (Retrieval) 과정을 일반 SQL로 유지했기에 Aurora를 깔끔하게 끼워 넣을 수 있었습니다.

직접 시도해 보세요

Aegis는 현재 Amazon Aurora와 Vercel에서 작동합니다. 만약 당신이 당신의 계정이나 문서들을 설명해 줄 수 없는 상황이 되었을 때, 그것들이 어떻게 될지 궁금해한 적이 있다면, 그것이 바로 우리가 해결하고자 하는 문제입니다.

저는 이 해커톤에 참여하기 위한 목적으로 이 콘텐츠를 제작했습니다. #H0Hackathon