🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

벡터 검색은 에이전트 메모리의 한 부품일 뿐이며, 프로덕션 에이전트에는 작업별 데이터 계약·권한·출처·구조·관계를 함께 다루는 “지식 레이어”가 필요합니다.

📌 핵심 요점

1. Pinecone조차 벡터 검색만으로는 부족하다는 방향의 제품을 내놓으며, 에이전트 시대의 병목이 단순 검색이 아니라 맥락 재사용과 운영 지식 조립에 있음을 보여줍니다.
2. 고전적 RAG는 챗봇식 질의응답에는 유용하지만, 티켓 처리·고객 기록 조회·정책 확인·권한 판단 같은 실제 업무형 에이전트에는 부족합니다.
3. 에이전트가 필요한 지식은 문서 청크, 구조화 문서, 테이블형 비즈니스 데이터, 그래프형 관계 등 여러 형태로 나뉩니다.
4. SAP의 Dremio·Prior Labs 투자는 엔터프라이즈 AI에서 레이크하우스, 시맨틱 레이어, 표 기반 추론, 데이터 계보가 중요해지고 있다는 신호로 해석됩니다.
5. 큰 컨텍스트 창은 해결책이 아니며, 중요한 것은 “많은 컨텍스트”가 아니라 권위 있고 최신이며 권한에 맞는 “적절한 컨텍스트”입니다.
6. 도구 선택은 Pinecone, Neo4j, Chroma 같은 이름에서 시작할 것이 아니라 에이전트가 안정적으로 수행해야 할 작업과 필요한 데이터 번들에서 출발해야 합니다.

🧩 배경과 문제 정의

• 영상은 벡터 DB 기업 Pinecone조차 “벡터 검색만으로 충분하지 않다”는 방향의 제품을 내놓은 상황에서 출발합니다.
• 발표자는 에이전트 개발의 핵심 병목을 검색 성능 자체보다 메모리, 맥락 재사용, 운영 지식 조립 문제로 봅니다.
• RAG, 벡터 검색, 문서 구조 기반 검색, 지식 그래프, 레이크하우스 쿼리 등이 동시에 부상하면서 에이전트 개발자는 어떤 메모리 계층을 써야 할지 더 복잡한 선택을 하게 됐습니다.
• 기업 지식의 상당 부분은 PDF 문단이 아니라 ERP, CRM, 고객 기록, 거버넌스된 테이블, 메트릭 정의, 권한 체계에 있기 때문에 문서 인덱싱 중심 RAG만으로는 한계가 큽니다.
• 발표자는 단순히 비용을 더 쓰거나 개발자에게 자체 구축을 맡기는 방식만으로는 고객 요구와 에이전트 워크플로를 충분히 해결할 수 없다고 봅니다.

🕒 시간순 섹션별 상세정리

1. 벡터 검색의 한계와 에이전트 메모리 문제

• Pinecone은 벡터 데이터베이스 회사인데도 최근 제품을 통해 벡터 검색만으로는 부족하다는 메시지를 내놓았고, SAP·Google·Cloudflare·Microsoft도 에이전트 메모리 문제에 뛰어들고 있다고 소개됩니다. [00:00]
• 에이전트는 도구와 데이터베이스가 있어도 이전에 요약한 문서를 다시 읽거나, 이미 받은 답을 다시 묻거나, 유용한 작업 전 컨텍스트 창과 토큰 예산을 소모하는 문제가 있습니다. [00:41]
• Pinecone은 이런 재발견 과정이 에이전트 컴퓨트의 최대 85%를 차지할 수 있다고 하며, 발표자는 수치 자체는 확신하지 않지만 비중이 크다는 점에는 동의합니다. [01:02]
• RAG는 정보를 가져와 모델에 맥락으로 전달하는 루프이고, 사람들이 흔히 말하는 RAG는 그중 문서를 벡터화해 가까운 청크를 찾는 벡터 검색인 경우가 많다고 구분합니다. [01:57]
• 검색 방식은 벡터 검색, 데이터베이스 검색, 직접 텍스트 검색 등 다양하며, 여러 검색 방식을 조합한 메모리 시스템을 고려해야 한다고 말합니다. [02:37]

2. 챗봇식 RAG와 업무형 에이전트의 차이

• 2024~2025년에 많이 구축된 고전적 RAG는 “비밀번호를 어떻게 재설정하나요?” 같은 질문에 도움말 문서 청크를 찾아 답하는 챗봇형 작업에 맞춰져 있었습니다. [03:16]
• 에이전트는 질문 하나에 답하고 멈추는 것이 아니라 티켓을 열고, 고객 기록을 가져오고, 정책을 확인하고, 응답을 작성하는 실제 업무를 수행해야 합니다. [03:43]
• 수백 페이지 문서에서 40페이지에 걸친 계약 정의를 교차 참조하는 작업은 “관련 청크 세 개 찾기”만으로 해결되지 않습니다. [04:01]
• 고전적 RAG는 매 실행마다 원시 검색 결과에서 필요한 묶음을 즉석 조립하게 만들고, 그 결과 같은 맥락 재조회, 문서 재요약, 불필요한 사용자 질문, 토큰 낭비, 일관성 저하가 발생합니다. [04:52]

3. Pinecone Nexus와 NoQL이 말하는 검색 계약

• Pinecone은 Nexus와 NoQL이라는 쿼리 언어를 내놓으며, 챗봇에는 관련 텍스트가 필요하지만 에이전트에는 운영 맥락이 필요하다는 전제를 세웁니다. [05:27]
• 고객 에스컬레이션을 준비하는 에이전트는 다섯 개 시스템을 매번 처음부터 검색하기보다 고객 맥락, 권한, 통제 정책, 과거 이력을 사용 가능한 번들로 조립해야 합니다. [05:43]
• 금융 분석에서는 쿼리 벡터와 가까운 문단보다 파일링, 거버넌스 테이블, 메트릭 정의, 이전 예측, 라이브 대시보드 중 무엇이 진실의 원천인지 구분하는 일이 중요합니다. [05:56]
• NoQL은 의도, 필터, 접근 정책, 출처, 응답 형태, 신뢰도, 예산을 검색 결과와 함께 에이전트에 전달하려는 시도이며, 벡터 DB는 그 일부만 담당할 수 있다고 정리됩니다. [06:14]

4. Page Index와 구조 보존형 문서 메모리

• Page Index는 많은 문서가 애초에 청킹되어서는 안 되며, 문서 구조 자체가 의미를 담고 있다고 합니다. [06:57]
• 재무 공시에서는 위험 요인, 경영진 논의, 재무제표 주석, 표, 서술 문단이 서로 대체될 수 없고, 계약서에서는 멀리 떨어진 정의·일정표·예외 조항이 특정 조항의 의미를 바꿀 수 있습니다. [07:14]
• Page Index는 문서를 목차 같은 계층 트리로 만들고 각 노드에 요약을 붙인 뒤, 모델이 트리를 따라 올바른 섹션을 찾게 하는 방식을 제안합니다. [07:58]
• 발표자는 검색 단위가 작업 종류와 맞아야 한다고 강조합니다. FAQ에는 청크, 공시에는 섹션, 금융 분석에는 표, 고객지원에는 고객 기록, 의존성 추론에는 그래프 이웃, 반복 워크플로에는 컴파일된 브리프가 맞을 수 있습니다. [08:24]

5. SAP의 Dremio·Prior Labs 투자와 기업 지식 레이어

• SAP는 Dremio와 Prior Labs 관련 인수를 발표했으며, Dremio는 레이크하우스 아키텍처, 시맨틱 레이어, SAP 및 비SAP 시스템 쿼리 페더레이션, 접근 제어, 리니지를 제공한다고 소개됩니다. [09:35]
• SAP는 Dremio와 Prior Labs에 10억 유로 이상을 투입했고, 발표자는 이를 챗봇 구축이 아니라 AI 메모리 인프라 투자로 해석합니다. [10:02]
• 기업의 핵심 지식은 문단형 텍스트보다 ERP, CRM, 고객 기록, 거버넌스된 테이블에 많기 때문에 “PDF를 인덱싱해 문단에서 답하는” 벡터 RAG는 대다수 비즈니스 메모리에 맞지 않는 추상화로 제시됩니다. [10:23]
• 에이전트가 매출 수치나 공급업체 리스크를 다룰 때는 간접 문서보다 특정 메트릭이 정의된 데이터 웨어하우스의 거버넌스 테이블, 공급업체 기록, 리스크 모델이 기준점이 됩니다. [10:56]
• Dremio는 권한과 계보가 포함된 비즈니스 데이터 접근을 제공해, 에이전트가 어떤 데이터를 볼 수 있고 출처와 메트릭 정의가 무엇인지 판단하게 하는 축으로 제시됩니다. [11:16]
• Prior Labs의 표 기반 파운데이션 모델 사례는 스프레드시트를 텍스트로 바꿔 LLM에 추론시키는 방식이 churn risk, supplier risk, renewal forecasting 같은 문제에 부적합하다는 논지와 연결됩니다. [11:43]
• 발표자는 에이전트가 문서, 테이블, 메트릭 정의, 워크플로 상태 등 실제 비즈니스 지식 형태를 그대로 다뤄야 하며, 모든 것을 평평한 텍스트로 누르는 방식은 충분한 지식 레이어가 아니라고 봅니다. [12:07]

6. 그래프형 지식과 네 가지 지식 형태

• 공급업체와 배송, 고객의 공통 실패 패턴, 같은 근본 원인으로 이어지는 사고처럼 관계 자체가 핵심인 작업은 수학적으로 그래프 질문이며, Microsoft의 Graph RAG가 대표 사례로 언급됩니다. [12:26]
• Graph RAG는 비용이 높고 엔티티 추출이 완벽하지 않으며 그래프가 낡을 수 있지만, 일부 지식은 본질적으로 관계형이라 청크나 테이블만으로 담기 어렵습니다. [12:40]
• 업계가 지원하려는 지식 형태는 fuzzy prose, 긴 구조화 문서, 테이블형 비즈니스 데이터, 그래프형 관계로 정리됩니다. [12:59]
• 선택의 본질은 특정 데이터베이스가 아니라 에이전트 업무에 필요한 지식 형태의 조합입니다. [12:59]

7. 큰 컨텍스트 창의 한계와 적절한 컨텍스트

• 모델 컨텍스트 창이 커져도 무엇을 넣어야 하는지, 어떤 출처가 권위 있는지, 권한을 어떻게 강제할지, 문서 계층을 어떻게 보존할지는 자동으로 해결되지 않습니다. [13:31]
• 사용자 확인 기억과 모델 추론 기억을 어떻게 구분할지도 큰 컨텍스트 창만으로 해결되지 않는 문제입니다. [13:31]
• 발표자는 Chroma 연구를 근거로 컨텍스트가 커지고 어수선해질수록 모델 성능이 떨어질 수 있다는 “context rot”을 언급합니다. [14:00]
• 프로덕션 에이전트의 목표는 최대한 많은 컨텍스트가 아니라 적절한 컨텍스트이며, 많은 문서를 한꺼번에 넣으면 출처 혼합, 오래된 정보와 최신 정보의 동등 취급, 사실의 잘못된 강조가 생길 수 있습니다. [14:19]

8. 데이터 계약과 번들 중심의 설계 원칙

• 에이전트를 만들 때는 Pinecone, Weaviate, Neo4j, Chroma 같은 데이터베이스를 먼저 고르기보다, 에이전트가 안정적으로 일하려면 어떤 데이터를 어떤 형태로 받아야 하는지부터 정해야 합니다. [14:42]
• 고객 지원 환불 에이전트의 경우 고객 기록, 플랜, 지역, 제품 버전, 구매 이력, 환불 정책, 환불 한도, 기존 예외, 현재 티켓, 승인된 응답 문구, 환불 권한 여부까지 하나의 구체적 번들로 적어야 합니다. [15:29]
• 번들을 적어보면 필요한 필드가 한 시스템에 있지 않고, 일부는 단순 검색이 아니라 거버넌스가 필요하며, 에이전트의 실제 작업은 문서 검색보다 번들 조립과 추론에 가깝다는 점이 드러납니다. [16:07]
• 번들이 prose 중심이면 벡터 검색과 문서 트리, 거버넌스된 비즈니스 데이터 중심이면 semantic layer와 tabular reasoning, 관계형이면 그래프가 필요합니다. [16:22]
• 도구 선택은 유행이 아니라 해당 번들을 에이전트에게 안정적으로 전달할 수 있는지에 따라 결정해야 합니다. [16:22]

9. 실패 모드와 실행 로그 기반 진단

• compiled bundle은 낡을 수 있고, 그래프는 잘못된 관계를 담을 수 있으며, 문서 파서는 테이블을 놓칠 수 있고, semantic layer는 조직 내 “진실의 원천” 논쟁 때문에 정치적 갈등을 만들 수 있습니다. [17:04]
• 에이전트가 이전 실행의 추론을 확정 사실처럼 저장하면 이후 실행을 조용히 악화시킬 수 있습니다. [17:24]
• 반대로 단순한 헬프센터 assistant에 Graph RAG, 문서 트리, semantic layer, memory system을 모두 붙이는 과잉 구축도 피해야 합니다. [17:24]
• 필요한 레이어는 현재 에이전트 실행 로그에서 확인할 수 있으며, 유용한 작업 전 retrieval call 수, 반복적으로 여는 소스, raw context가 차지하는 토큰 예산을 추적하라고 제안합니다. [17:51]
• 이미 있는 정보를 사용자에게 다시 묻는 빈도와 이전 실행에서 배운 것을 다음 실행이 재발견하는 빈도도 중요한 진단 지표입니다. [17:51]

10. 메모리 시대의 결론과 인프라 선택

• 발표자는 프로덕션 에이전트가 등장하면서 기존 메모리 시스템이 챗봇 시대용이었다는 점이 드러났다고 정리합니다. [18:20]
• Pinecone, SAP, Google, Cloudflare, Microsoft의 움직임은 엔터프라이즈 에이전트 성공에 지식 레이어가 핵심이라는 신호로 해석됩니다. [18:20]
• 승자는 유행하는 retrieval을 좇는 팀이 아니라 에이전트가 실제로 무엇을 해야 하고, 어떤 데이터 형태가 효과적이며, 그것을 어떻게 효율적으로 전달할지 먼저 정의한 팀이라는 결론입니다. [18:53]
• “수표를 쓰면 되겠지” 또는 “개발자들이 만들게 하면 되겠지”라는 접근은 해결책이 아니며, 워크플로와 고객에게 더 효과적인 에이전트 실행이 필요하다고 말합니다. [19:45]
• 발표자는 중요한 인프라 선택을 더 깊이 이해해야 한다는 메시지로 영상을 마무리합니다. [19:58]

🧾 결론

이 영상의 핵심은 “벡터 검색이 죽었다”가 아니라 “벡터 검색만으로는 프로덕션 에이전트의 메모리 문제가 풀리지 않는다”입니다. 에이전트가 실제 업무를 하려면 문서 청크뿐 아니라 고객 기록, 권한, 정책, 메트릭 정의, 테이블, 그래프 관계, 이전 실행의 검증된 기억까지 작업에 맞는 형태로 받아야 합니다.

따라서 에이전트 인프라 설계의 출발점은 특정 DB나 검색 기술이 아니라, 에이전트가 반복적으로 안정적인 결과를 내기 위해 필요한 데이터 계약과 지식 형태의 조합입니다.

📈 투자·시사 포인트

• SAP의 Dremio·Prior Labs 투자는 엔터프라이즈 AI 경쟁이 모델 자체뿐 아니라 데이터 접근, 계보, 권한, 표 기반 추론, 시맨틱 레이어로 확장되고 있음을 보여주는 사례로 제시됩니다.
• Pinecone의 Nexus·NoQL 방향은 벡터 DB 기업들도 단순 유사도 검색을 넘어 에이전트용 운영 맥락 제공으로 이동하고 있음을 시사합니다.
• 기업용 AI 인프라 시장에서는 “문서 검색”보다 “권한 있는 지식 번들 조립”이 더 중요한 경쟁 축이 될 가능성이 있습니다.
• Graph RAG, 문서 트리, semantic layer, tabular reasoning은 서로 대체재라기보다 지식 형태별로 필요한 보완재에 가깝습니다.
• 투자 관점에서는 특정 벡터 DB 유행보다 엔터프라이즈 데이터 거버넌스, 레이크하우스, 시맨틱 계층, 에이전트 메모리 인프라의 결합을 보는 것이 중요합니다.
• 단, 영상 내용은 발표자의 해석과 주장에 기반하므로 개별 기업 가치나 투자 판단으로 바로 연결해서는 안 됩니다.

⚠️ 불확실하거나 확인이 필요한 부분

• Pinecone이 주장한 “재발견 과정이 에이전트 컴퓨트의 최대 85%를 차지할 수 있다”는 수치는 영상 속 주장으로, 발표자도 정확한 수치에는 확신하지 않는다고 말합니다. [01:02]
• SAP의 Dremio·Prior Labs 투자 규모와 인수 관련 세부 조건은 영상 속 설명 기준이며, 실제 거래 구조와 최신 상태는 별도 확인이 필요합니다. [09:35] [10:02]
• Chroma 연구와 “context rot” 관련 설명은 영상에서 근거로 언급되지만, 구체적 실험 조건과 적용 범위는 원 연구 확인이 필요합니다. [14:00]
• Graph RAG의 비용, 엔티티 추출 품질, 그래프 노후화 문제는 일반적 리스크로 제시되며, 실제 영향은 도메인과 구현 방식에 따라 달라질 수 있습니다. [12:40]
• “serious knowledge layer”의 정의는 발표자의 프레임에 가깝기 때문에, 조직별 데이터 구조와 에이전트 목표에 따라 필요한 계층은 달라질 수 있습니다.

✅ 액션 아이템

• 현재 에이전트가 실제로 수행해야 하는 업무를 먼저 문장으로 정의합니다.
• 업무별로 필요한 데이터 번들을 고객 기록, 정책, 권한, 메트릭, 출처, 응답 형식까지 구체적으로 적어봅니다.
• 실행 로그에서 유용한 작업 전 retrieval call 수와 반복적으로 열리는 소스를 측정합니다.
• raw context가 토큰 예산을 얼마나 차지하는지 확인합니다.
• 에이전트가 이미 있는 정보를 사용자에게 다시 묻는 빈도를 추적합니다.
• 이전 실행에서 얻은 정보를 다음 실행이 다시 발견하는지 점검합니다.
• 필요한 지식 형태가 문서 청크, 구조화 문서, 테이블, 그래프 중 어디에 가까운지 분류합니다.
• 단순 헬프센터 assistant처럼 작은 문제에 과도한 메모리 인프라를 붙이고 있지 않은지 검토합니다.
• 모델 추론 결과와 사용자·시스템이 확인한 사실을 별도 저장하는 규칙을 세웁니다.

❓ 열린 질문

• 우리 에이전트가 매번 다시 찾는 정보는 무엇이며, 그것을 재사용 가능한 번들로 만들 수 있을까요?
• 현재 실패의 원인은 검색 정확도 부족일까요, 아니면 권한·출처·구조·메트릭 정의가 빠진 문제일까요?
• 문서 청크, 문서 트리, 테이블 추론, 그래프 중 실제 업무에 가장 큰 영향을 주는 지식 형태는 무엇일까요?
• 어떤 기억은 저장해도 되고, 어떤 추론은 저장하면 위험할까요?
• 큰 컨텍스트 창을 쓰는 대신 더 작고 권위 있는 컨텍스트를 제공할 방법은 무엇일까요?
• 지금 도입하려는 인프라는 유행 때문인가요, 아니면 명확한 데이터 계약을 충족하기 때문인가요?