벡터 파이프라인을 처음 설계할 때 대부분 배치 방식으로 시작한다. 데이터를 긁어서 임베딩하고, 벡터 DB에 밀어 넣고, 에이전트가 그걸 조회한다. 깔끔하고, 테스트하기 쉽고, 데모에서 잘 돌아간다. 문제는 운영에 들어가는 순간 데이터가 멈추지 않는다는 점이다.
문서 수십만 건 중 일부가 매일 업데이트된다면, 전체를 재임베딩하는 비용은 곧 감당하기 어려운 수준이 된다. 더 큰 문제는 재빌드가 진행되는 동안 에이전트는 오래된 인덱스를 보고 추론한다는 것이다. 'long horizon agent'를 목표로 하면서 인덱스 자체가 며칠씩 뒤처지는 상황은 구조적 모순이다. 에이전트의 기억이 길어질수록 그 기억의 신선도 관리가 파이프라인의 핵심 문제가 된다.
CocoIndex는 이 지점을 정면으로 겨냥한다. 변경된 데이터가 생기면 전체 파이프라인을 재실행하는 대신, 어떤 노드가 stale해졌는지 추적하고 해당 부분만 다시 계산한다. 에이전트 메모리 레이어에서 CDC(Change Data Capture)에 해당하는 역할을 하겠다는 설계다. "Incremental engine for long horizon agents"라는 한 줄 설명이 마케팅 문구가 아니라 아키텍처 선언에 가깝다.
오늘 GitHub 트렌딩 14위에 오른 이 Python 프로젝트는 아직 초기 단계다. 성숙도나 스타 수보다 중요한 건 이 라이브러리가 제기하는 질문이다 — 에이전트 파이프라인을 설계할 때 인덱스 업데이트 전략을 처음부터 고려하고 있는가? 배치 재빌드로 출발해서 나중에 고치면 된다는 생각이라면, 그 '나중'이 얼마나 복잡해지는지를 CocoIndex의 접근 방식이 먼저 보여준다.