프로덕션 AI 에이전트 아키텍처: 마크다운 지식베이스가 확장되지 않는 이유

핵심 메시지

• AI 에이전트에는 성격이 전혀 다른 두 종류가 있다. 내 기기에서 마크다운 지식베이스로 도는 개인용 에이전트와, 여러 사용자에게 서비스로 제공되는 프로덕션 에이전트다.
• 개인용 에이전트는 마크다운이 가장 단순하고 유연해 잘 맞지만, 다른 사람에게 배포하는 순간 마크다운 기반 지식베이스는 더 이상 확장되지 않는다.
• 프로덕션 에이전트는 데이터베이스 위에 컨텍스트 검색(context retriever)과 에이전트 메모리라는 두 층을 얹어 대규모 데이터 접근과 사용자별 기억을 감당해야 한다.
• 스키마와 도구를 갖춘 컨텍스트 층 덕분에 에이전트는 문서 전체를 읽지 않고 단 한 번의 도구 호출로 필요한 데이터를 저비용으로 찾아낸다.

쉽게 이해하기

발표자는 요즘 사람들이 퍼스널 에이전트 혹은 세컨드 브레인에 지나치게 몰려 있다고 짚는다. 이 방식은 클로드 코드나 헤르메스 같은 코딩 에이전트를 내 기기에서 돌리며, 카르파티가 제안한 LLM 위키처럼 태그·분류·색인 문서로 이뤄진 마크다운 지식베이스를 대화하며 쌓아 올리는 형태다. 모든 것을 내 시스템에 두어 빠르고 자유롭게 접근하고, 접근 제어나 감사 추적을 신경 쓸 필요가 없어 단순하다는 게 장점이다.

문제는 그 에이전트를 다른 사람들에게 배포하는 순간 시작된다. 여러 사용자가 동시에 접속하고 실시간 데이터가 오가며 접근 제어와 대규모 검색이 필요해지면 마크다운 문서 뭉치는 감당이 되지 않는다. 애초에 데이터베이스가 존재하는 이유가 여기 있고, 세컨드 브레인은 코딩 에이전트 구독에 의존하는 구조라 비용 면에서도 프로덕션에 맞지 않는다. 문서 전체를 읽게 하는 방식은 아무리 최적화해도 프로덕션 규모의 검색과 비용 절감을 따라가지 못한다.

그래서 제시하는 프로덕션 아키텍처는 데이터베이스를 중심에 두고 두 가지 능력을 얹는 것이다. 첫째는 컨텍스트 검색으로, 비정형 데이터에 구조(엔티티·타입·관계)를 부여하고 에이전트가 쓸 검색·필터 도구를 자동으로 만들어 준다. 둘째는 에이전트 메모리로, 대화별 단기 기억을 저장하고 백그라운드 과정이 그중 중요한 내용을 장기 기억으로 승격시킨다. 영상에서는 이를 레디스와 레디스 아이리스로 시연하지만, 같은 아이디어를 어떤 프로덕션 시스템에도 적용할 수 있다고 반복해 강조한다.

시연에서는 파이덴틱 AI로 만든 전자상거래 지원 에이전트가 등장한다. 왜 내 주문이 늦나, 지난번처럼 처리해 달라는 한 문장 요청에 대해, 에이전트는 먼저 사용자의 선호(환불보다 재발송)를 메모리에서 찾고 이어 고객·주문·배송 데이터를 도구 호출로 조회해 완결된 답을 내놓는다. 이 모든 과정이 수천 토큰도 쓰지 않고 끝난다는 점이 핵심이다.

주요 인사이트

• 컨텍스트 검색 층의 본질은 비정형 키-값 데이터에 스키마와 도구를 씌우는 것이다. 개인용 에이전트에서 LLM 위키의 색인·메타데이터가 하던 역할을 프로덕션 규모로 옮겨 놓은 셈이다.
• 도구 호출과 MCP 서버 덕분에 에이전트는 데이터가 아무리 많아도 속성별 필터·텍스트 검색을 단일 호출로 수행하며, 마크다운 문서를 통째로 읽을 때보다 훨씬 적은 토큰으로 답한다.
• 단기 기억을 장기 기억으로 자동 승격시키는 방식은 세컨드 브레인에서 대화의 핵심을 memory.md로 추려 두는 습관과 같은 원리이며, 벡터·의미 검색(RAG)으로 사용자당 수백만 개의 기억도 확장 가능하게 만든다.
• 프로덕션 에이전트에는 코딩 에이전트 SDK보다 파이덴틱 AI를 권한다. 코딩용 SDK는 긴 코딩 작업에 맞춰져 있어 느리고 토큰 소모가 크기 때문이다.

자주 묻는 질문

관련 AI 소식