올해 기업용 AI 에이전트(AI agents)를 구축하는 데 시간을 할애했다면, 여러분은 필연적으로 "RAG 장벽(RAG Wall)"에 부딪혔을 것입니다.

파운데이션 모델(Foundation models, Claude 3.5, GPT-4o)은 추론 능력이 놀랍지만, 근본적으로 상태가 없는(stateless) 특성을 가집니다. 이를 해결하기 위해 업계의 기본 방식은 평면적인 시맨틱 RAG(flat semantic RAG)였습니다. 즉, 모든 기업 데이터를 청커(chunker)에 쏟아붓고, 이를 Vector DB에 임베딩(embedding)한 뒤, 사용자가 질문을 하면 코사인 유사도 검색(cosine similarity search)을 실행하는 방식입니다.

이 방식은 특정 PDF를 찾는 데는 완벽하게 작동합니다. 하지만 에이전트가 여러 시스템에 걸쳐 왜 특정 결정이 내려졌는지 이해해야 할 때는 처참하게 실패합니다.

문제점: 벡터 검색은 계보(Lineage)를 파괴합니다

실제 기업 데이터가 복잡한 이유는 바로 관계형(relational)이기 때문입니다. 하나의 결정은 종종 Slack 스레드에서 시작되어, Jira 티켓으로 공식화되고, 최종적으로 SharePoint 계약서의 수정된 조항으로 끝납니다.

이러한 문서들을 Vector DB를 위해 500토큰 단위의 청크(chunks)로 맹목적으로 자르면, 엣지(edges)와 연결 고리(linkages)를 완전히 제거하게 됩니다. 응집력 있는 연대기적 타임라인을 고립된 문단들로 바꾸어 버리는 것입니다. AI 에이전트가 "Acme Corp의 청구 분쟁 상태는 무엇인가요?"라고 물을 때, 표준 RAG는 단지 관련 없는 세 개의 텍스트 청크를 프롬프트(prompt)에 던져 넣을 뿐이며, 모델이 타임라인을 환각(hallucinate)하도록 방치합니다.

아키텍처: Vector DB + 지식 그래프(Knowledge Graph)

이러한 기업적 기억상실증을 해결하기 위해, 우리는 AI가 프롬프트를 보기 전에 인제스션 파이프라인(ingestion pipeline)이 변경되어야 한다는 것을 깨달았습니다. 평면적인 벡터 저장소 대신, 데이터를 이중 저장소 아키텍처(dual-store architecture)로 라우팅하는 이벤트 스트리밍 컨텍스트 레이어(event-streaming context layer)를 구축했습니다.

다음은 우리가 PipesHub에서 사용하는 상위 수준의 흐름입니다:

1. 이벤트 스트리밍 (Kafka): 사일로(silos, Slack, GitHub, Salesforce, Drive)로부터 비정형 데이터를 지속적으로 인제스트(ingest)합니다.

2. 엔티티 추출 (Entity Extraction): 데이터를 저장하기 전에, 추출 레이어에서 엔티티(Entities, 사용자, 회사, 티켓, Pull Requests)와 그들 사이의 관계(relationships)를 식별합니다.

3. 이중 라우팅 (Dual Routing):

• 원문 텍스트 청크는 Vector DB (광범위한 의미론적 문맥 (semantic context) 용)로 이동합니다.

• 추출된 관계(relationships)는 Knowledge Graph (확실한 계보 (lineage) 및 시간적 추적 용)로 이동합니다.

이제 백엔드 인프라는 단순히 모호한 키워드 매칭 (fuzzy keyword matching)을 수행하는 대신, 여러분의 도구들이 실제로 어떻게 연결되는지를 매핑합니다.

MCP를 통한 아키텍처 노출

Knowledge Graph를 Vector DB와 결합하는 것은 훌륭하지만, AI 에이전트가 이에 접근하기 위해 커스텀 Cypher 쿼리를 작성하거나 맞춤형 API 커넥터를 직접 구축하도록 강제하는 것은 매우 취약한 (brittle) 방식입니다.

이 지점에서 Model Context Protocol (MCP)가 등장합니다.

우리는 결합된 데이터베이스 아키텍처를 MCP Server로 노출합니다. 오케스트레이션 프레임워크 (LangGraph 또는 OpenAI Agents SDK와 같은)가 복잡한 쿼리에 답해야 할 때, 이는 MCP Client 역할을 수행합니다. 우리의 서버는 이중 저장소 데이터를 표준 MCP Tools로 동적으로 노출하여, 에이전트가 자신의 메모리를 가져오는 방법을 스스로 결정할 수 있게 합니다:

• Tool A (query_graph_relations): 에이전트가 그래프를 조회하여 Slack 승인과 Jira 티켓 사이의 정확한 계보 (lineage)를 찾아냅니다.
• Tool B (semantic_search): 에이전트가 Vector DB를 조회하여 계약서의 실제 텍스트를 가져옵니다.

Headless Context로의 전환

우리가 PipesHub를 오픈 소스로 공개한 이유는 AI의 미래가 또 다른 빈 채팅 인터페이스가 아니라고 믿기 때문입니다. 장기적인 승자는 백그라운드에서 실행되며, 어떤 에이전트라도 MCP를 통해 연결할 수 있는 지속적이고 권한을 인식하는 (permission-aware) 메모리 그래프를 유지하는, 보이지 않는 헤드리스(headless) 데이터 기질 (substrate)이 될 것입니다.

청크로 나뉜 문서들을 프롬프트에 맹목적으로 쏟아붓는 것을 멈추세요. 엔티티 (entities)를 매핑하기 시작하세요. 토큰 비용은 낮아지고, 환각 (hallucinations) 현상은 사실상 사라질 것입니다.

만약 여러분이 RAG Wall과 싸우고 있거나 MCP 서버를 구축하고 있다면, 엔티티 추출 (entity extraction)을 어떻게 처리하고 있는지 듣고 싶습니다. 저희 리포지토리에서 그래프 라우팅을 어떻게 구현했는지 확인하실 수 있습니다: https://github.com/pipeshub-ai/pipeshub-ai