GBrain README의 그래프 검색 수치는 실제 제품 검색이 아닌 상한값입니다

핵심 요약

먼저 알아 둘 용어

• MCP(Model Context Protocol)는 Claude Code·Codex 같은 에이전트가 외부 도구를 호출할 때 쓰는 공개 규약입니다. GBrain은 자기 기능을 MCP 도구로 내보내고, 에이전트는 그 도구로 메모리를 읽고 씁니다.
• PGLite는 Postgres를 WebAssembly로 컴파일해 별도 서버 없이 한 프로세스 안에서 쓰는 내장 데이터베이스입니다. GBrain의 기본 엔진이고, 여러 사람이 함께 쓰거나 규모가 크면 Postgres와 벡터 확장 pgvector를 씁니다.
• 하이브리드 검색은 키워드 검색과 의미 검색(문장을 숫자 벡터로 바꾼 임베딩끼리 비교하는 검색) 결과를 합치는 방식입니다. GBrain은 두 결과 목록의 순위를 RRF(Reciprocal Rank Fusion, 순위의 역수를 더해 합치는 방법)로 합칩니다.
• 리랭커는 검색 후보를 질문과 함께 다시 읽고 순서를 다시 매기는 별도 모델입니다. 후보와 질문이 외부 API로 전송됩니다.
• R@5(재현율)는 정답으로 표시된 페이지 가운데 상위 5개 결과 안에 들어온 비율이고, P@5(정밀도)는 상위 5개 결과 가운데 정답인 비율입니다. 개발사 보고서는 P@5의 분모를 항상 5로 둡니다.
• 어댑터는 평가 저장소에서 같은 문항을 여러 비교 대상 시스템에 연결하기 위해 쓰는 코드입니다. 같은 이름의 어댑터라도 제품 그대로의 검색을 부르는지, 평가용으로 따로 만든 경로를 쓰는지가 다를 수 있습니다.
• 종합 판단 부분(compiled truth)과 타임라인은 GBrain이 페이지 본문을 나누는 방식입니다. 앞부분은 지금 기준의 종합 판단이고 새 증거가 나오면 다시 씁니다. 뒷부분은 날짜가 붙은 증거 기록이고 덧붙이기만 합니다.

GBrain은 무엇인가 — 2026-10-06에 확인한 사실

GitHub 저장소 설명은 "Garry's Opinionated OpenClaw/Hermes Agent Brain"입니다. Garry Tan이 자기 에이전트(OpenClaw·Hermes 위에서 실행하는 개인 비서)의 기억 저장소로 만든 것을 일반화했다고 README가 밝힙니다. 아래는 저장소와 GitHub API에서 직접 확인한 값입니다.

메모리를 쓰고 읽는 흐름은 이렇습니다. 에이전트가 MCP로 remember나 put_page를 부르면 GBrain이 마크다운 페이지를 쓰고 DB에 색인합니다. 검색은 gbrain search(검색 결과 페이지 목록 반환)와 gbrain think(검색 결과를 바탕으로 출처와 누락 정보를 포함한 종합 답변 생성)로 나뉩니다. 야간 정리 작업인 "dream cycle"은 현재 코드에서 26개 단계(링크 정리, 사실 추출, 모순 탐지, 임베딩 등)로 구성됩니다.

마크다운 폴더를 메모리의 원본으로 두는 흐름 전체는 에이전트 메모리는 파일로 간다에서, 메모리 벤치마크의 비용 구조는 DolphinBench 글에서 다뤘습니다. 이 글은 GBrain 한 프로젝트의 주장과 코드만 봅니다.

6월 노트의 설명과 지금의 저장소

6월 노트에 적었던 설명을 하나씩 현재 코드와 문서에 대조했습니다. 6월 이후 바뀐 것도 있고, 6월에도 정확하지 않았던 것도 있습니다.

판정은 이 글의 분류입니다. "범위 한정 필요"는 6월 설명이 틀렸다는 뜻이 아니라, 지금 문서가 적용 범위를 더 좁게 적고 있다는 뜻입니다.

README의 그래프 수치 — 평가 보고서는 상한값으로 분류합니다

README는 지식 그래프를 설명하는 문단에 "BrainBench 관계 질문에서 그래프 어댑터가 P@5 0.3421, R@5 0.9791을 기록했고, 일반 하이브리드는 0.1917 / 0.6874였다"고 적고, 근거로 gbrain-evals의 2026-09-09 보고서를 연결합니다. README도 "전체 시스템끼리의 비교이지 그래프만의 효과나 일반적인 보장이 아니다"라는 단서를 붙여 두었습니다.

연결된 보고서를 열면 단서가 하나 더 있습니다. 9월 28일에 덧붙인 주석은 이 어댑터가 "네 가지 질문 형식을 미리 알고 있으므로" 이름을 graph-oracle-parse로 바꾸고 상한값으로 다룬다고 적습니다. 보고서 본문도 이 어댑터를 "아래에서 측정하는 제품 하이브리드 검색과는 다른, 특화된 시스템"이라고 설명합니다. 같은 보고서는 제품 검색 경로에서 관계 검색 단계(search.relational_retrieval)만 켜고 끈 통제 비교를 따로 실었습니다.

통제 비교의 내용은 이렇습니다. 관계 질문 145개를 데이터 입력 순서 세 가지로 반복한 435쌍에서, 관계 검색 단계를 켜자 재현율이 45쌍에서 올랐고 내려간 쌍은 없었습니다. 효과는 질문 형식마다 달랐습니다. "X에 누가 투자했나"는 첫 결과가 정답인 비율이 9/39에서 21/39로 올랐고, "X에 누가 참석했나"는 재현율 0.38 그대로였습니다. 보고서는 참석 질문에 대해, 평가 데이터는 회의에서 사람 방향으로 링크를 두지만 제품은 사람에서 회의 방향의 링크를 따라간다는 차이를 적어 두었습니다. 또 세 가지 입력 순서는 같은 질문의 반복이라 435개의 독립 표본이 아니고, 정답 판정이 사람 페이지에만 점수를 주며, 답변 정확도는 측정하지 않았다고 밝힙니다.

정리하면, 관계 검색 단계는 개발사 측정에서 재현율이 내려간 질문 없이 일부 질문의 재현율을 올렸습니다. 다만 README가 인용한 0.9791은 질문 형식을 미리 아는 경로의 값이고, 제품 경로의 값은 0.7241입니다. 두 값은 평가 시점의 버전(0.48.4.0)에서 나온 것이고 현재 버전에서 다시 측정한 결과는 확인하지 못했습니다.

다른 개발사 평가 — 불리한 결과와 정정 기록도 실려 있습니다

gbrain-evals는 Garry Tan 계정의 별도 저장소이므로 독립 평가가 아니라 개발사 측정입니다. 보고서에는 GBrain이 불리했던 비교와 정정 기록도 함께 실려 있습니다.

이 보고서들에서 읽을 수 있는 것은 "GBrain이 항상 낫다"가 아니라 어떤 설정을 켤지는 실제로 쓸 질문으로 직접 비교해 정해야 한다는 것입니다. 보고서 자신도 결론에서 단순 검색과 GBrain을 같은 질문으로 비교하고, 설정을 고를 때 쓰지 않은 질문을 따로 남겨 두라고 권합니다. 이 글이 확인한 범위에서는 개발사와 관계없는 곳이 같은 평가를 재현한 결과는 없었습니다.

공유와 백업 — 문서가 스스로 밝힌 한계

6월 노트에 없던 내용 가운데 도입 판단에 가장 중요한 것은 docs/guides/memory-boundaries.md와 docs/architecture/system-of-record.md가 적은 경계입니다. 코드에서 확인할 수 있는 것은 함께 대조했습니다.

• 에이전트가 저장한 기억은 기본적으로 연결된 모든 에이전트가 읽습니다. remember 작업의 공개 범위 기본값은 코드에서 world입니다(src/core/verbs.ts). 한 에이전트에만 두려면 visibility: "private"를 넘겨야 한다고 README가 적습니다.
• 마크다운 내보내기는 전체 백업이 아닙니다. DB 전용 사실과 페이지, 수정 이력, 철회 상태, 작업 큐, 설정, 인증 기록은 마크다운에서 복구되지 않을 수 있으므로 엔진의 전체 백업·복원 경로를 쓰고 다른 위치에 복원해 보라고 문서가 권합니다.
• 로컬 저장이 로컬 처리를 뜻하지는 않습니다. API 키 없이 쓰는 키워드 검색과 링크 추출은 모델 API를 쓰지 않지만, 임베딩·리랭커·질의 확장·종합 답변을 켜면 해당 텍스트가 설정한 제공자에게 전송됩니다. 연결된 에이전트의 모델은 API 키 없이 쓸 때도 불러온 기억을 받습니다.
• 기본 설정에서는 저장할 때마다 사실 추출 호출이 한 번 더 붙습니다. 메모·회의·이메일처럼 추출 대상인 유형의 페이지는 저장 뒤 대기열 작업으로 사실 추출 모델을 한 번 호출하고, gbrain config set facts.extraction_enabled false로 끌 수 있다고 문서가 적습니다.
• 출처(source)는 정리 단위이지 격리 단위가 아닙니다. 원격 클라이언트는 출처별 권한과 공개 범위 필터로 제한되지만, 같은 파일이나 DB 자격 증명을 쓰는 로컬 호출자는 제한되지 않습니다. 접근을 완전히 막아야 하는 내용은 권한을 주지 않은 출처에 두라고 문서가 권합니다.

확인할 수 없는 개발사 주장

README에는 저장소 밖에서는 확인할 방법이 없는 주장도 있습니다. 이 글은 아래 값을 사실로 옮기지 않고 개발사 주장으로만 적습니다.

체크리스트

아직 결론이 아닌 것

• 이 글은 2026-06-16 초기 노트를 2026-10-06에 현재 기준으로 다시 쓴 것입니다. 6월 노트는 README 설명을 옮긴 개요였고, 수치별 출처 확인과 한계 절이 없었습니다. 6월 노트의 활용 시나리오와 도입 단계 제안은 근거가 없어 뺐습니다.
• 이 글에서 새로 측정한 성능 값은 없습니다. GBrain을 설치해 실행하지 않았습니다. 이 글이 한 것은 코드 판독과, 저장소 코드를 불러와 정의된 작업·단계 목록의 개수를 센 것뿐입니다. 성능 수치는 모두 gbrain-evals 보고서에서 옮긴 개발사 측정입니다.
• 평가 수치의 버전이 현재 버전과 다릅니다. 관계 검색 비교는 0.48.4.0, LongMemEval 재측정은 0.60.37.0에서 나왔습니다. 0.60.78.0에서 같은 값이 나오는지는 확인하지 못했습니다.
• 평가 데이터가 실제 사용 데이터가 아닙니다. 보고서는 개념 검색 결과가 합성 코퍼스에서 나왔다고 밝히고, "외부 작성" 질문군도 AI가 만든 임시 질문 50개라고 9월 28일에 정정했습니다. 실제 개인·회사 데이터에서의 성능은 이 평가로 알 수 없습니다.
• 권한 경계는 문서와 코드 일부만 대조했습니다. 공개 범위 기본값과 작업 노출 규칙은 코드에서 확인했지만, 출처 격리가 모든 경로에서 지켜지는지는 확인하지 않았습니다. 개발사도 보장하지 않는다고 적습니다.
• 빠르게 바뀝니다. 6월 16일 이후에만 CHANGELOG 항목이 196개 늘었습니다. 이 글의 코드 관련 서술은 커밋 a08578c 기준이고, 저장소 수치는 2026-10-06 GitHub API 기준입니다.

참고자료

모두 2026-10-06에 원문을 받아 대조했습니다.

2026-06-16 초기 노트를 2026-10-06에 현재 기준으로 다시 썼습니다. 6월 노트가 인용한 GeekNews·Zenn 소개 글은 2차 자료라 이번 판에서는 근거로 쓰지 않았습니다. README의 그래프 수치나 평가 보고서가 바뀌면 이 글을 고치고 개정 날짜를 적겠습니다.