로그 아카이브를 실시간 메모리로 바꾸는 funes의 기본 스펙
코딩 에이전트가 남긴 세션 로그는 단순한 기록물의 저장소일 뿐이며 수만 번의 대화 턴 속에서 특정 결정의 이유를 찾는 일은 사실상 불가능하다. funes는 이러한 로컬 트레이스(에이전트의 실행 기록)를 인덱싱하여 에이전트가 스스로 과거의 결정 근거를 찾게 만드는 메모리 레이어(데이터 저장 및 검색 계층)다. 단순한 텍스트 아카이브를 실시간으로 참조 가능한 메모리로 전환함으로써 개발자는 과거의 시행착오를 반복하지 않고 이전 세션의 추론 과정을 즉시 불러와 현재 작업에 반영할 수 있다.
funes는 ML 런타임(기계 학습 모델 실행 환경) 의존성이 전혀 없는 단일 바이너리 형태로 배포된다. 이는 별도의 무거운 라이브러리 설치나 환경 구성 없이 실행 파일 하나만으로 작동함을 의미한다. 텍스트를 수치 벡터로 변환하는 임베딩(Embedding) 과정과 검색 결과의 우선순위를 다시 정하는 리랭킹(Reranking) 작업이 모두 사용자 기기 내부에서 처리된다. 현재 이 시스템은 Claude Code, Codex, pi, Hermes와 같은 주요 코딩 에이전트를 지원하며 기본적으로 로컬에서 작동하지만 사용자의 선택에 따라 기본적으로 비공개 설정된 Hugging Face 데이터셋으로 메모리를 이동시켜 저장할 수도 있다.
에이전트에 funes를 연동하여 메모리 기능을 활성화하는 과정은 명령어 한 줄로 수행된다.
funes add이 명령어를 실행하면 시스템은 즉시 첫 번째 인덱스를 구축하고 에이전트에게 `recall`과 `get`이라는 두 가지 전용 도구를 제공한다. `recall`은 과거에 생성된 특정 텍스트 조각을 복구하는 기능을 수행하며 `get`은 전체 대화 턴의 내용과 그 주변 컨텍스트(맥락 정보)를 상세히 확인하는 용도로 사용된다. 또한 각 작업 턴이 완료될 때마다 해당 내용을 자동으로 인덱싱하는 자동화 기제가 함께 설치되어 메모리가 실시간으로 갱신되며 에이전트의 정상적인 작업 흐름의 일부가 된다.
데이터 인덱싱은 전체 기록을 매번 다시 처리하지 않고 새로운 실행 결과만 추가하는 증분 방식(Incremental)으로 작동한다. 이러한 구조 덕분에 기록이 쌓여도 임베딩 비용이 선형적으로 증가하지 않으며 효율적인 메모리 관리가 가능하다. 아주 오래전의 기록이나 깊은 층위의 콘텐츠는 정해진 단계에 따라 순차적으로 채워지는 백필(Backfill) 과정을 거친다. 추가만 가능한 형태의 메모리 구조를 통해 과거의 리허설 기록까지 모두 보존하며 추론의 연속성을 유지한다. 이 도구는 오픈 소스로 공개되어 있으며 상세 내용은 github.com/huggingface/funes에서 확인할 수 있다. 에이전트가 이미 작성해 둔 기록을 읽을 수 있는 메모리로 전환하여 어떤 기기에서든 이전의 추론 맥락을 그대로 이어갈 수 있다.
로컬 Lance 데이터셋과 Hugging Face를 활용한 하이브리드 파이프라인
로컬 메모리는 추가 쓰기 비용이 낮은 Lance 데이터셋(열 지향 데이터 저장소)을 사용해 인덱싱 비용을 낮춘다. 모든 트레이스는 결정론적 파이프라인을 통해 동일한 턴과 블록 형태로 파싱되어 데이터 구조의 일관성을 확보한다. 이후 텍스트를 의미 있는 작은 단위로 나누는 청킹(Chunking) 과정을 거치며, 로컬에 고정된 임베딩 모델(텍스트를 수치 벡터로 변환하는 모델)을 통해 벡터화된다. 이렇게 처리된 데이터는 Lance의 추가 전용(Append-only) 데이터셋 구조에 저장되어, 수만 번의 세션 로그가 쌓이는 환경에서도 효율적인 증분 쓰기가 가능하다.
검색 단계에서는 벡터 검색과 BM25(단어 빈도 기반의 키워드 검색) 방식을 결합해 검색 결과의 누락을 방지한다. 두 방식에서 도출된 서로 다른 순위를 하나로 통합한 뒤, 크로스 인코더(질문과 문서의 관련성을 직접 계산해 재정렬하는 모델)를 통해 후보군을 다시 정밀하게 순위 매긴다. 여기에 최신성 가중치를 적용해 오래된 정보보다 최근의 결정이나 맥락이 우선적으로 반환되도록 제어한다. 최종적으로 선택된 패시지뿐 아니라 그 주변의 인접 청크를 함께 추출해 에이전트가 단편적인 정보가 아닌 충분한 전후 문맥을 파악하고 정확한 근거를 찾도록 돕는다.
공유 메모리는 Hugging Face 데이터셋(AI 모델 및 데이터 공유 플랫폼)을 활용해 구현하며 기본적으로 비공개 설정으로 운영된다. 사용자는 다음 명령어로 현재의 로컬 메모리를 원격 저장소에 발행하고 동기화할 수 있다.
funes bind [HF_DATASET_NAME]이 명령을 실행하면 funes는 세션 경계마다 로컬에서 인덱싱된 내용을 자동으로 발행하여 메모리를 최신 상태로 유지한다. 원격 메모리 파일은 Hugging Face의 캐싱과 콘텐츠 중복 제거(Content-dedup) 기능을 통해 로컬에 저장되며, 이를 통해 네트워크 지연 없이 빠른 쿼리 속도를 유지한다. 다른 기기에서 동일한 명령을 실행하면 기존의 메모리 구조가 그대로 복제되어 작업 환경이 일관되게 유지된다.
보안 강화를 위해 인덱싱과 발행의 모든 단계에서 자격 증명(Credentials, API 키 등 인증 정보)을 자동으로 탐지해 제거하는 처리 과정을 거친다. 발행된 메모리는 데이터셋 카드와 funes 태그를 통해 허브 내에서 식별 가능하며, 이는 단순한 기록 보관소를 넘어 오픈 워킹 메모리(작업 과정의 추론과 결정이 담긴 공유 메모리)로 기능한다. 프로젝트 진행 중 내린 결정, 시도했으나 실패한 접근 방식, 그 뒤에 숨은 논리적 근거가 모두 기록된다. 이렇게 저장된 메모리는 다른 에이전트가 쿼리할 수 있으며, 해당 정보가 어떤 세션에서 생성되었는지 정확한 출처를 추적할 수 있는 결정론적 구조를 가진다.
세션 압축 및 핸드오프 대비 최대 8배 저렴한 리콜 비용
리콜(Recall, 과거 텍스트 복구) 방식은 수동 핸드오프(Handoff, 작업 내용을 요약해 새 세션으로 전달하는 방식)와 비교했을 때 한 작업에서는 8배, 다른 작업에서는 4배 더 저렴한 비용으로 작동한다. 코딩 에이전트가 복잡한 문제를 해결하기 위해 긴 조사를 수행하면 세션 데이터가 누적되어 비대해진다. 이 상태에서는 매 턴마다 이전 컨텍스트를 모델에 입력하는 비용이 실제 정답을 도출하는 작업 비용보다 더 커지는 역전 현상이 발생한다. 기존에는 이를 해결하기 위해 에이전트가 스스로 내용을 압축하거나 사용자가 직접 핸드오프 문서를 작성해 새 세션을 시작하는 방식을 사용했다. 리콜은 이러한 비용 부담을 낮추면서도 필요한 정보만 정밀하게 불러오는 제3의 대안으로 작동한다.
세션 압축(Compaction, 대화 내용을 요약해 용량을 줄이는 방식)은 요약 과정에서 핵심 발견 사항을 누락해 일부 작업에서 실패하는 한계를 보였다. 이전 세션의 지식 없이는 해결이 불가능한 두 가지 과제로 구성된 핸드오프와 리콜 벤치마크(handoff-vs-recall benchmark) 결과, 세션 압축은 단 하나의 과제만 해결하는 데 그쳤다. 요약 과정에서 중요한 기술적 발견 사항들이 평탄화되어 사라졌기 때문이다. 반면 리콜은 요약본이 아닌 원문 패시지(Passage, 텍스트 조각)를 그대로 반환한다. 정보가 요약이라는 필터를 거치지 않으므로 에이전트는 원문에 기록된 세부 사항을 그대로 활용해 과제를 완수할 수 있다.
리콜은 요약문이 아닌 원본 텍스트를 반환하며 해당 정보의 출처인 에이전트, 타임스탬프, 세션, 턴 정보를 함께 제공한다. 각 검색 결과에는 전체 턴과 그 주변 컨텍스트를 즉시 열어볼 수 있는 `get` 명령어가 포함된다. [비용 비교 바 차트] 에이전트는 리콜을 통해 찾은 단편적인 패시지에서 더 깊은 맥락이 필요하다고 판단되면 `get` 명령어를 실행해 주변 상황을 재구성한다. 이러한 방식은 에이전트가 요약된 정보에 의존해 추측하는 위험을 제거하고 실제 기록된 근거를 바탕으로 추론하게 만든다.
결과적으로 리콜은 세션 압축의 정보 손실 문제와 수동 핸드오프의 높은 비용 문제를 동시에 해결하는 구조를 가진다. 세션 압축은 많은 에이전트가 기본으로 채택하는 방식이지만 정보의 정밀도가 낮아 복잡한 추론에서 실패할 확률이 높다. 수동 핸드오프는 정확한 정보 전달이 가능하지만 매번 요약본을 작성하고 전달하는 비용이 과다하게 발생한다. 리콜은 원문 패시지를 직접 호출하는 메커니즘을 통해 정확도를 유지하면서도 토큰 소모량을 획기적으로 낮춘다. 이는 대규모 코드베이스를 탐색하며 수많은 시행착오를 기록하는 코딩 에이전트의 메모리 관리 효율을 결정짓는 핵심 요소가 된다.
모델과 머신을 넘나드는 에이전트 간 기억 공유의 실무 의미
Claude Code에서 내린 결정이나 추론 근거를 다음 주에 Codex(코딩 보조 AI)가 리콜하여 작업을 지속하는 환경이 가능하다. 메모리가 특정 모델이나 실행 머신에 종속되지 않는 독립 층으로 분리되었기 때문에, 서로 다른 에이전트가 동일한 기억 저장소에 접근할 수 있다. 원격 메모리를 읽어올 때 funes는 데이터셋 파일을 로컬에 캐싱(임시 저장)하여 반복되는 쿼리 속도를 로컬 수준으로 유지한다. 소유권과 접근 제어, 버전 관리 및 배포는 Hugging Face Hub(AI 모델 및 데이터 공유 플랫폼)의 기존 인프라를 그대로 활용한다. 사용자는 별도의 메모리 전용 서비스 계정을 생성하거나 API를 통해 메모리 접근 권한을 임대하는 비용을 지불하지 않고도 데이터셋의 배포 체계를 그대로 이용한다.
사용자는 에이전트의 지속적인 설정 변경 없이도 단발성 질문을 통해 과거 기억을 확인할 수 있다. `funes ask` 명령어는 `funes add`의 읽기 전용 형제 도구로 작동하며, 로컬 또는 공유 메모리에서 질문과 관련된 패시지(텍스트 조각)를 추출해 코딩 에이전트에게 전달한다. 에이전트는 이 패시지를 근거로 삼아 출처가 명시된 답변을 생성하며, 이 과정에서 에이전트의 영구적인 설정이나 통합 환경을 수정하지 않는다.
funes ask [질문]만약 검색된 결과가 질문에 답하기에 충분한 근거를 제공하지 못한다면, 에이전트는 임의로 답변을 생성하는 대신 정보가 부족하다는 사실을 명시적으로 알린다. 이는 모델이 기억나지 않는 부분을 억지로 메우는 할루시네이션(환각 현상)을 방지하고, 제공된 패시지에만 기반해 답변하는 그라운딩(근거 제시) 성능을 보장한다.
개별 사용자가 직접 메모리를 구축하지 않고도 공개된 공유 메모리를 통해 시스템의 작동 원리를 파악하는 것도 가능하다. 개발팀은 funes 개발 과정에서 발생한 모든 추론과 결정 사항이 담긴 메모리를 공개했다. 사용자는 공유 메모리를 지정해 funes가 왜 현재의 방식으로 설계되었는지 직접 질문하고 답을 얻을 수 있다. 이는 사용자가 과거 세션을 일일이 기억해내거나 이전 대화의 컨텍스트(맥락)를 복사해 새 세션에 붙여넣는 수동 작업의 불편함을 제거한다. 에이전트가 대화 도중 스스로 메모리에 접근해 필요한 정보를 가져오고, 답변의 근거가 된 세션 이름을 명확히 밝히며 작업의 연속성을 유지하기 때문이다.
세션 압축보다 정확하고 수동 핸드오프보다 최대 8배 저렴한 비용으로 과거 컨텍스트를 복구하는 것이 실무적인 최적의 선택이다.
