에이전트 인프라의 3계층과 몽고DB의 진짜 자리

최근 해외 기술 아키텍처 포럼에서 에이전트의 데이터 저장을 둘러싸고 벌어진 뜨거운 논쟁 글을 읽었다.

한쪽에서는 “결국 언어모델이 읽고 쓸 지식이니 깃(Git)으로 형상을 관리하는 마크다운 텍스트 파일이면 충분하다”고 주장하고, 다른 쪽에서는 “에이전트가 도구를 호출하다 뻗었을 때 롤백하고 동시성을 제어하려면 분산 운영체제(DBOS) 같은 강력한 트랜잭션 런타임이 필수적이다”라며 맞서고 있었다.

양극단의 주장을 번갈아 읽으며, 수년 전 몽고DB(MongoDB) 본사 관계자들과 미팅을 가졌을 때의 기억이 떠올랐다. 당시 나는 그들에게 “지식 그래프를 네이티브로 풀지 못하는 도큐먼트 데이터베이스가 엔터프라이즈의 복잡한 온톨로지를 과연 감당할 수 있겠는가”라며 회의적인 시선을 던졌고, 한동안 몽고DB를 내 아키텍처 레이더에서 지워두었었다.

현장에서 터져 나온 엉뚱한 병목

하지만 에이전트를 실제 업무 환경에 배포해 운영해본 뒤 내 생각은 크게 달라졌다. 현장의 병목은 그래프 추론 같은 고상한 곳에서 터지는 것이 아니었다.

에이전트가 도구를 호출하고 중간 판단을 내리는 모든 인터페이스는 제멋대로 변하는 JSON이다. 어제 작동하던 입출력 구조가 오늘 새로운 도구를 붙이는 순간 확장된다. 여기에 전통적인 관계형 데이터베이스(RDBMS)의 경직된 테이블을 들이대면, 스키마 변경 쿼리를 날리느라 개발 주기가 멈춰 선다. 그렇다고 컬럼을 통째로 텍스트로 뭉개 넣으면 인덱싱의 이점은 사라지고 검색 속도는 바닥을 긴다.

이 혼란의 한가운데서 데이터 계층은 자연스럽게 세 개의 층위로 정렬된다.

사람이 직접 읽고 수정하며 깃으로 이력을 추적하는 ‘마크다운 지식 계층(Layer 1)’, 에이전트가 도구를 쓰다 실패했을 때 프로세스를 깨끗하게 원상태로 되돌리는 ‘OS 수준의 트랜잭션 계층(Layer 3)’, 그리고 그 둘 사이에서 쏟아지는 유동적인 도구 호출과 사고의 궤적을 DDL 변경 없이 빨아들이는 ‘도큐먼트 허브(Layer 2)‘다.

완충재로서의 도큐먼트 모델

이 세 층위를 바라보며 내가 깨달은 의미는, 몽고DB의 진짜 가치가 그래프 엔진을 흉내 내는 데 있는 것이 아니라 양극단을 이어주는 가장 유연한 완충재 역할을 한다는 점이다.

언어모델의 예측 불가능한 JSON 출력을 스키마 변경 없이 그대로 집어넣고 속성 단위로 즉시 색인할 수 있다. 텍스트 키워드 검색과 벡터 유사도 검색, 그리고 비즈니스 메타데이터 필터링을 별도의 파이프라인 분리 없이 단일 쿼리로 묶어내는 하이브리드 검색은 엔터프라이즈 운영 비용을 획기적으로 낮춘다.

물론 포스트그레스(PostgreSQL)의 거센 추격과 네이티브 그래프 추론의 부재라는 한계는 여전하다. 하지만 인간이 작성한 비정형 텍스트 지식과 시스템이 요구하는 엄격한 트랜잭션 사이에서, 시시각각 형태를 바꾸는 에이전트의 생각을 안정적으로 담아내는 다리 역할을 도큐먼트 모델보다 능숙하게 해내는 도구는 드물다.

에이전트 시대를 지탱하는 인프라는 하나의 만능 솔루션으로 통일되지 않는다. 사람을 위한 텍스트, 시스템을 위한 트랜잭션, 그리고 에이전트의 거친 생각을 유연하게 받아내는 도큐먼트 계층이 조화롭게 맞물릴 때 비로소 멈추지 않는 시스템이 완성된다.