AIREITER파서를 왜 바꿨는지 한 시간 동안 추적해도, 다음 작업을 다른 에이전트에서 시작하면 그 판단 근거는 쉽게 사라집니다. Funes는 에이전트 세션을 로컬에서 인덱싱하고, 출처를 포함한 원문 근거를 다시 찾아줍니다. Claude Code, Codex, pi, Hermes가 하나의 메모리를 함께 쓰게 할 수도 있습니다. 다만 Funes가 과거 기록을 찾아줄 뿐, 예전 결정이 지금도 유효한지는 에이전트가 직접 판단해야 합니다.
이 글에서는 Claude Code → Codex 구성, 로컬 전용 메모리, 선택적인 Hugging Face 동기화, 범용 MCP 클라이언트 연결, 그리고 불러온 기록을 유용하게 유지하기 위한 검증 방법을 다룹니다.
설치 전에 메모리 범위부터 정하기
Funes를 평가 중이거나 민감한 저장소를 다룬다면 로컬 메모리부터 시작하는 편이 좋습니다. 다른 장비나 팀원과 동일한 기록을 공유해야 할 때만 Hugging Face 데이터셋을 연결하세요.
| 모드 | 저장 위치 | 처음 쓰기 좋은 경우 | 주의할 점 |
|---|---|---|---|
local | 로컬 Lance 데이터셋 | 개발자 한 명, 장비 한 대 | 다른 호스트로 메모리가 자동 이동하지 않음 |
<org>/<repo> | 로컬 Lance 데이터와 Hugging Face Dataset 저장소 | 에이전트나 장비를 오가며 작업할 때 | 세션 기록에는 민감한 코드, 프롬프트, 경로, 자격 증명이 포함될 수 있음 |
Funes 보안 정책에 따르면, 파싱·청킹·임베딩·리랭킹은 기본적으로 로컬에서 처리됩니다. 데이터가 장비 밖으로 나가는 경로는 funes push 또는 세션 경계에서 게시하는 공유 메모리 통합 기능입니다. Hub 기반 메모리는 데이터셋 저장소이므로, 첫 푸시 전에 공개 범위를 확인해야 합니다.
첫 파일럿에서는 local을 쓰세요. 나중에 funes add <agent> <memory>를 다시 실행하면 연결 대상을 바꿀 수 있습니다.
Funes 설치와 첫 인덱스 생성
공식 Funes 저장소는 플랫폼을 감지하고, 태그된 바이너리를 내려받아 릴리스 체크섬을 검증한 뒤 실행 파일을 기본적으로 ~/.local/bin의 PATH 위치에 설치하는 셸 설치기를 제공합니다.
curl -fsSL https://huggingface.co/buckets/huggingface/funes/resolve/install.sh | shfunes 명령을 바로 찾지 못한다면 새 셸을 열고 설치 상태를 확인합니다.
funes status저장소에는 Linux x86_64, Linux aarch64, macOS Apple Silicon용 태그 바이너리가 제공됩니다. 사용하는 플랫폼이 목록에 없다면 사전 빌드 설치기가 지원한다고 가정하지 말고 프로젝트의 소스 빌드 안내를 따르세요.
5분 만에 시작하는 기본 설정
기억하려는 에이전트 세션이 이미 존재하는 환경에서 다음을 실행합니다.
funes add claudeClaude Code에서는 이 명령으로 첫 인덱스를 만들고, 읽기 도구를 등록하며, 통합 자동화를 설치하고, 완료된 턴을 계속 인덱싱할 수 있습니다. 확인 후 첫 처리는 약 1분이 걸리는 텍스트 우선 방식으로 문서화되어 있습니다. 방대한 도구 출력보다 설명과 추론 내용을 먼저 처리합니다. (Funes 설정 문서)
이어서 현재 상태를 살펴봅니다.
funes statusClaude 세션을 수동으로 초기 인덱싱하거나 갱신해야 한다면 다음 명령을 사용하세요.
funes index --harness claude경로를 지정하지 않은 funes index는 ~/.claude/projects, ~/.codex/sessions 등을 포함해 Claude, Codex, pi, Hermes의 표준 세션 위치를 검색할 수 있습니다. --harness claude를 붙이면 Claude Code로 스캔 범위를 제한합니다. 인덱싱 가이드에는 경로 없는 갱신에 약 60초의 텍스트 우선 예산이 적용된다고도 설명되어 있습니다. 오래된 세션과 대용량 도구 결과는 이후 처리에서 반영될 수 있습니다.
Funes 인덱싱은 증분 방식이므로 다시 실행해도 이미 기록된 청크를 재임베딩하지 않습니다. 명시적으로 지정한 트랜스크립트 경로와 Hub 트레이스 저장소는 경로 없는 실행의 시간 예산을 적용하지 않고 전체 인덱싱합니다. (인덱싱 상세 문서)
Claude Code에 Funes 연결하기
Claude Code용 로컬 메모리는 다음처럼 설정합니다.
funes add claude local
funes statuslocal이 기본값이므로 생략해도 됩니다. 터미널에서 HF 토큰을 사용할 수 있다면 Funes가 사용자 소유의 <user>/funes-memory 저장소 설정을 제안할 수 있습니다. 로컬 전용 파일럿이라면 이 제안은 거절하세요.
Claude 통합은 훅 전용 플러그인과 별도의 MCP 등록으로 구성됩니다. Funes는 Claude Code의 settings.json을 수정하지 않습니다. 자동화 기능은 완료된 턴을 인덱싱하며, 공유 메모리 구성에서는 세션 경계에서 게시도 추가됩니다. (자동화 동작 방식)
설치만 보고 판단하지 말고, Claude Code를 열어 이미 알고 있는 과거 결정을 찾아보세요.
스트리밍 파서에 관한 이전 결정을 찾아줘. 저장소 기록만으로 설명되지 않는다면 Funes recall을 사용하고, 참고한 세션을 인용해줘.좋은 결과라면 이전 기록의 해당 구절을 가리키고, 세션을 식별하며, 과거 실험과 현재 저장소 상태를 구분해야 합니다.
저장된 데이터를 지우지 않고 통합만 해제하려면 다음을 실행합니다.
funes remove claude제거 문서에 따르면, 이 명령은 Funes 연결 설정만 없애고 로컬 메모리, 원본 트랜스크립트, 캐시, 게시된 메모리는 보존합니다.
같은 메모리를 Codex에도 연결하기
Claude Code가 정상 동작하면 Codex를 같은 로컬 메모리에 추가합니다.
funes add codex local
funes statusHub 기반 공유 메모리를 쓸 때는 두 에이전트에 동일한 저장소 식별자를 지정합니다.
funes add claude <org>/<repo>
funes add codex <org>/<repo>Codex에는 놓치기 쉬운 신뢰 단계가 있습니다. Funes는 훅을 ~/.codex/hooks.json에 기록합니다. Codex 안에서 /hooks를 실행해 Funes 항목을 검토하고 신뢰 처리하세요. 훅을 신뢰하기 전까지 Codex는 이를 건너뛰므로 새 턴이 인덱싱되지 않고 메모리도 게시되지 않습니다. 문서화된 바인딩 메모리 워크플로에는 Codex 0.151.0이 필요합니다. (Codex 자동화 요구 사항)
에이전트 간 전달을 실제로 검증하기
한쪽 세션에만 존재하는, 눈에 띄는 결정을 대상으로 테스트하세요.
- Claude Code에서 파서 결정을 찾아보고, 논의에 등장한 고유한 표현 하나를 적어둡니다.
- 세션을 종료해 인덱싱과 세션 경계 자동화가 실행되게 합니다.
- Codex에서 그 표현에 대해 물어보고 이전 판단 근거를 요청합니다.
- 응답이 Claude를 소스 harness로 식별하고 원본 세션 또는 턴을 가리키는지 확인합니다.
터미널에서 근거를 직접 확인할 수도 있습니다.
funes recall "why did we switch away from the streaming parser"recall은 생성형 요약이 아니라 순위가 매겨진 원문 구절을 반환합니다. 각 결과에는 출처 정보와 생성된 get 명령이 포함됩니다. 주변 턴까지 확인해야 한다면 그 명령을 복사해 실행하세요.
Codex에서 아무것도 찾지 못한다면 버전, /hooks 신뢰 상태, funes status, 그리고 Claude 세션이 통합 설정 이전에 생성된 것은 아닌지를 확인하세요. 그 후 원래 논의의 고유한 표현으로 다시 시도합니다.
pi, Hermes 또는 다른 MCP 클라이언트 연결
Funes는 Claude Code와 Codex뿐 아니라 pi와 Hermes도 직접 지원합니다. pi는 확장 이벤트를 사용하고 Hermes는 셸 훅을 사용합니다. Hermes의 턴별 인덱싱은 베타로 문서화되어 있습니다. (지원 에이전트 상세 정보)
이 네 가지 외에 MCP를 지원하는 클라이언트라면 Funes를 로컬 stdio 서버로 실행하면 됩니다.
{
"mcpServers": {
"funes": {
"command": "funes",
"args": ["mcp"]
}
}
}서버를 공유 메모리에 연결하려면 mcp 뒤에 저장소를 추가합니다.
{
"mcpServers": {
"funes": {
"command": "funes",
"args": ["mcp", "<org>/<repo>"]
}
}
}MCP 문서에서는 recall, get, status를 제공합니다. funes mcp는 읽기 전용입니다. 세션을 인덱싱하거나 데이터를 게시하지 않습니다. 이 작업에는 funes index, funes push, 또는 지원되는 funes add 통합을 사용해야 합니다.
개별 MCP 호출에서 지정한 메모리는 서버 수준의 연결 설정을 덮어씁니다. 둘 다 지정하지 않으면 Funes는 로컬 메모리를 사용합니다.
근거를 잃지 않고 recall 활용하기
Funes에는 세 가지 구분되는 작업 방식이 있습니다.
| 명령 | 출력 | 이럴 때 사용 |
|---|---|---|
funes recall "…" | 출처가 포함된 순위별 원문 구절 | 근거를 직접 검토하고 싶을 때 |
funes get … | 인용된 턴과 주변 맥락 | 결과는 관련 있어 보이지만 내용이 불충분할 때 |
funes ask <agent> "…" | 근거 기반 자연어 답변 하나 | 통합을 설치하지 않고 Claude 또는 Codex에서 빠른 답을 얻고 싶을 때 |
문서에 명시된 recall 기본값은 결과 8개, 리랭킹 후보 풀 30개, 최근성 반감기 30일, 인접 청크 1개입니다. (Recall 플래그와 기본값)
안정적인 디버깅 흐름은 다음과 같습니다.
- 오류, 컴포넌트 이름 또는 결정 문구를 넣어
funes recall을 실행합니다. - 생성된
get명령을 따라 전체 턴을 확인합니다. - 찾아낸 결정이 현재 브랜치와 맞는지 검증합니다.
- 변경을 적용하거나 실험을 실행합니다.
- 결과를 기준으로 다시 recall해 다음 세션에서도 찾을 수 있게 합니다.
funes ask의 범위는 더 좁습니다. 먼저 검색을 수행한 뒤 선택된 구절과 질문을 Claude 또는 Codex에 전달해 답변 하나를 생성합니다. 하위 에이전트에는 도구, stdin, MCP 서버가 제공되지 않으며 검색 결과가 부정확해도 다시 검색할 수 없습니다. 검색 자체는 로컬에서 이뤄지지만, 질문과 불러온 구절은 선택한 에이전트에 설정된 제공업체로 전송됩니다. 따라서 ask 문서는 제공업체에 보내고 싶지 않은 자료에는 funes recall을 권장합니다.
신뢰할 수 있고 운영 가능한 메모리 유지하기
Funes는 원문 구절과 출처를 보존하지만, 과거의 모든 우회책이 지금도 적용되는지까지 판단해 주지는 않습니다.
“메모리를 지루한 인프라로 만들면 코딩 에이전트의 이상한 행동이 훨씬 줄어든다. 로컬 인덱스, 정확한 출처, 기본 비공개.” — X의 @TheArtemisHunts
작게 시작하는 운영 체크리스트
| 상황 | 확인할 사항 | 조치 |
|---|---|---|
| Codex가 아무것도 recall하지 못함 | 훅 신뢰와 버전 | /hooks를 실행해 Funes 항목을 신뢰 처리하고 Codex가 0.151.0인지 확인 |
| 오래된 세션이 누락됨 | 인덱스 범위와 처리 단계 | funes index --harness claude 또는 --harness codex를 실행하고, 대용량 출력은 이후 처리에서 채워질 수 있도록 둠 |
| 원격 푸시가 차단됨 | TruffleHog와 토큰 범위 | TruffleHog를 설치하거나 FUNES_TRUFFLEHOG를 설정하고, 푸시 장비에서만 세분화된 쓰기 토큰 사용 |
| 결과에 비밀 정보가 포함됨 | 로컬 scrub 상태 | funes scrub를 실행한 뒤 다시 푸시. 원본 트랜스크립트는 수정되지 않음 |
| 원격 메모리를 공유함 | 공개 범위와 신뢰 | 의도적으로 공개하는 경우가 아니라면 데이터셋을 비공개로 유지하고, 제3자에게서 불러온 텍스트는 신뢰할 수 없는 에이전트 입력으로 취급 |
| 마지막 세션이 Hub에 없음 | 세션 경계 시점 | 장비를 폐기하기 전에 funes push <org>/<repo> 실행 |
Funes는 인덱싱 중 자격 증명을 마스킹하고, 게시 전에는 실패 시 차단하는 TruffleHog 검사를 수행합니다. push 문서에 따르면 스캐너가 없으면 게시가 차단됩니다. 유효한 자격 증명이 원격 데이터셋에 올라갔다면 즉시 교체해야 합니다. 이후 커밋에서 scrub하더라도 저장소 이력까지 지울 수는 없기 때문입니다.
Hugging Face 토큰은 최소 권한 원칙으로 사용하세요. 게시하는 장비에는 쓰기 권한을, recall만 필요한 팀원이나 호스트에는 읽기 전용 권한을 부여합니다. 두 장비가 같은 원격 메모리에 동시에 게시하면 경합이 생길 수도 있습니다. 자동화 문서는 장비 간 직렬 처리를 보장한다고 말하지 않습니다.
실무에서 고를 설정
처음부터 모든 통합을 설치하기보다 다음 중 하나로 시작하세요.
| 워크플로 | 권장 설정 | 이유 |
|---|---|---|
| 지속형 메모리를 평가하는 개발자 한 명 | funes add claude local | 데이터 공유 위험이 가장 낮고 되돌리기도 가장 간단함 |
| Claude Code로 계획하고 Codex로 구현 또는 리뷰 | 두 에이전트를 같은 local 메모리에 연결 | 한 호스트 안에서 에이전트 간 추론을 보존 |
| 여러 장비에서 에이전트 사용 | 두 에이전트를 같은 비공개 <org>/<repo> 메모리에 연결 | Hub 데이터셋을 통해 개발자를 따라 메모리 이동 |
| 팀 프로젝트 이력 | 비공개 데이터셋과 열람자용 읽기 전용 토큰 | 게시 권한과 recall 접근 권한을 분리 |
| 지원하지 않는 MCP 에이전트 | funes mcp [memory] | 인덱싱은 명시적으로 유지하면서 읽기 접근만 추가 |
| 민감한 소스 자료 | 로컬 메모리와 recall | 원격 게시와 제공업체로의 일회성 전송을 피할 수 있음 |
Funes 코딩 에이전트 메모리 FAQ
Funes는 로컬에서 동작하나요?
Funes는 기본적으로 메모리를 로컬에서 처리하고 저장합니다. 다만 로컬 우선일 뿐 자동으로 로컬 전용인 것은 아닙니다. 푸시, 공유 메모리 훅, ask는 데이터를 로컬 프로세스 밖으로 보낼 수 있습니다.
Funes는 Claude Code와 Codex에서 작동하나요?
네. funes add는 Claude Code와 Codex는 물론 pi와 Hermes도 지원합니다. Codex 메모리 바인딩에는 0.151.0과 신뢰 처리된 훅이 필요합니다.
Funes가 세션을 자동으로 인덱싱하나요?
funes add 이후 지원되는 통합은 턴별 인덱싱 자동화를 설치합니다. 초기 부트스트랩에는 처리 범위 제한이 있으므로, 오래된 세션과 대용량 도구 결과는 이후 처리에서 반영될 수 있습니다.
Claude Code와 Codex가 하나의 메모리를 공유하게 하려면 어떻게 하나요?
funes add claude와 funes add codex 모두에 같은 <org>/<repo> 인수를 지정하세요. Funes는 작업용 인덱스를 로컬에 유지하고 세션 경계에서 공유 데이터셋을 게시합니다.
Funes가 오래된 결정을 불러오면 어떻게 하나요?
funes recall로 내용을 확인하고, 생성된 get 명령으로 맥락을 확장한 뒤, 실행 전 현재 브랜치와 대조하세요. 첫 검색이 빗나가면 질의 표현을 바꿔보면 됩니다.
funes ask는 데이터를 내 컴퓨터에만 보관하나요?
검색과 리랭킹은 로컬에서 처리되지만, ask는 질문과 불러온 구절을 설정된 Claude 또는 Codex 제공업체로 전송합니다. 민감한 근거에는 recall을 사용하세요.
메모리를 삭제하지 않고 Funes만 제거할 수 있나요?
네. funes remove claude, funes remove codex, funes remove pi, funes remove hermes는 통합 연결만 제거하며 인덱싱된 메모리와 원본 트랜스크립트는 보존합니다.