ACENT
AI 에이전트 & 업무 자동화

AI 에이전트 메모리가 '새 벡터DB' 대신 '이미 쓰는 DB'로 돌아오는 중

ACENT•
image.png

LangChain × MongoDB 파트너십이 IT 팀에 남기는 진짜 신호

"AI 에이전트를 프로덕션에 올리려면 결국 벡터DB를 하나 더 세팅해야 한다." 최근 1~2년 사이 많은 IT 팀이 말은 안 해도 가지고 있던 암묵적 전제다. 파일럿은 노트북에서 돌지만, 실제 서비스로 넘어가려는 순간 Pinecone이든 Weaviate든 Chroma든 — 어떤 형태로든 벡터 전용 인프라 심사 요청이 따라붙었다.

그 전제가 흔들리는 신호가 이번 주에 나왔다. LangChain이 MongoDB와 공식 파트너십을 발표했다. 핵심 메시지는 한 줄이다. 에이전트의 진행 중 메모리, 장기 기억, 의미 검색, 데이터 격리, 만료 정책까지 — 새 DB를 붙이지 않고 회사가 이미 운영 중인 MongoDB 한 곳 위에서 돌린다. 기존 Atlas 운영팀이 이미 가진 자산으로 에이전트 백엔드를 세우자는 제안이다.

왜 지금까지 '새 벡터DB'가 사실상 기본값이었나

에이전트가 쓸 만해지려면 필요한 것이 "대화 기록 저장" 하나가 아니다. "지난주에 이 고객이 환불 문의했던 게 맞나"처럼 정확히 같은 단어가 아니어도 의미가 비슷한 것을 찾아주는 검색이 있어야 한다. 이걸 전통 관계형·문서 DB 위에서 그대로 구현하기는 불편했다. 그래서 지난 몇 년, 에이전트 스택은 자연스럽게 "운영 DB + 벡터 전용 DB + 캐시 + 세션 스토어"로 쪼개졌다. 기능은 됐지만, IT 팀 입장에선 승인·실사·모니터링을 통과시킬 시스템이 하나 더 늘어난다는 비용이 컸다.

5개 조각을 '고객 지원 에이전트' 시나리오로 풀어보면

하루 100건 대화를 처리하는 고객 지원 에이전트를 가정하면, 파트너십이 말하는 다섯 조각은 이렇게 쓰인다.

  • MongoDBSaver (진행 중 메모리) — 고객이 대화 중간에 탭을 닫았다가 30분 뒤 돌아와도, 에이전트가 직전 맥락부터 이어 대응한다. 끊김 복구용 책갈피.

  • MongoDBStore (장기 기억) — "지난주에 환불 건으로 연락했던 그 고객"처럼 과거 맥락을 사용자·팀·프로젝트 단위로 쌓는다.

  • Atlas Vector Search (의미 검색) — 고객이 "돈 돌려받을 수 있나요?"라고만 물어도 "환불 규정" 매뉴얼 섹션을 찾아낸다.

  • 메타데이터 필터 (데이터 격리) — 고객 A의 대화 기록이 고객 B 응답에 실수로 섞이지 않도록 쿼리 단계에서 분리한다.

  • TTL (자동 만료) — "6개월 지난 대화는 자동 삭제" 같은 개인정보 정책을 DB 레벨에서 강제한다.

지금까지는 이 다섯을 각각 다른 도구로 구현했다. 파트너십의 제안은 다섯을 같은 Atlas 위에서 쿼리 하나로 엮겠다는 것이다.

IT 팀 관점 체크리스트: 그대로 승계되는 운영 자산

에이전트 백엔드를 기존 Atlas 위에 올린다는 건, 다음이 추가 작업 없이 그대로 적용된다는 뜻이다.

  1. 백업·복구 SOP — 이미 검증된 Atlas 백업 주기와 PITR(시점 복원) 절차가 에이전트 메모리에도 동일하게 적용된다.

  2. 접근 통제·권한 체계 — RBAC, VPC 피어링, IP 허용 목록이 살아 있다. 신규 벤더 실사 불필요.

  3. 감사 로그·모니터링 — 에이전트의 읽기/쓰기가 기존 Atlas 감사 로그에 같은 형식으로 남는다. SIEM 파이프라인을 다시 짤 필요가 줄어든다.

  4. 재해 복구·리전 이중화 — 에이전트 상태가 운영 DB와 같은 복제 토폴로지에 들어가므로 DR 플랜을 따로 쓸 일이 준다.

  5. 컴플라이언스 근거 — SOC2·ISO 인증 범위에 이미 포함된 인프라이므로, 감사팀 대응 부담이 새로 생기지 않는다.

보안 리뷰를 한 번이라도 통과시켜본 팀이라면, 이 다섯이 실제로 '프로덕션으로 가는 길의 장애물'이었다는 걸 안다.

한계와 유의점

다만 "모든 조각을 한 DB에 모은다"는 선택에는 트레이드오프가 있다. 기능이 한 시스템에 집중되면 단일 실패 지점(SPOF)의 영향 반경이 커진다 — 장애 시 복구 우선순위를 다시 설계해야 한다. Atlas Vector Search도 모든 워크로드에서 전용 벡터DB와 동등한 성능을 내지는 않는다. 초고부하·초저지연·수십억 벡터 규모에서는 전용 제품이 여전히 유리한 구간이 있다. 이번 파트너십 메시지를 "전용 벡터DB는 쓸모없다"로 읽으면 과장이다. 실제 메시지는 "대부분의 기업 도입 시나리오에선 이미 쓰는 DB가 충분한 출발점"에 가깝다.

닫기: AI 도입 의사결정의 질문이 바뀐다

지난 2년, AI 도입 회의의 질문은 대체로 이랬다. "어떤 새 AI 전용 인프라를 들일 것인가, 어떤 벤더를 새로 붙일 것인가." 앞으로 12개월, 질문은 이렇게 바뀔 가능성이 크다. "이미 운영 중인 스택 위에 에이전트를 얹을 수 있는가." 새 인프라를 사는 것보다, 이미 보안·운영·감사 체계를 통과한 시스템을 재사용하는 쪽이 프로덕션까지 실제로 더 빠른 길이기 때문이다.

당신 팀은 이번 분기, 둘 중 어느 질문으로 다음 회의를 시작할 것인가?