한 줄 요약
공개 지식 브레인인 GBrain을 운영 환경에 바로 설치하지 않고, 고정 커밋·격리 PGLite·합성 한국어 문서로 먼저 시험했습니다. 기억 프로토콜은 통과했지만 한국어 직접 검색과 보존 게이트가 실패해, 파일럿 실행은 제한부 통과, 생산 승격은 보류했습니다.
먼저 결론부터
이번 결과만으로 GBrain 전체를 좋다거나 쓸 수 없다고 판단할 수는 없습니다.
유지할 가치가 확인된 부분: 출처가 필수인 기억 쓰기, TTL, 토큰 예산, private/local 경계, 멱등적 삭제, 엔터티 중심 관계 모델
당장 바꾸지 않은 부분: QMD 문서 검색, canonical 라이브러리, Hermes 생산 설정
후속 검토 후보: GBrain 전체가 아니라
recall / remember / entity / synthesize / forget다섯 동사만 노출하는 격리 sidecar최종 판정: 파일럿
PASS_WITH_LIMITATIONS, 생산 승격HOLD_NO_PROMOTION
“작동한다”와 “운영에 넣어도 된다”를 분리하니, 장점을 살리면서도 기존 검색·설정·자료를 위험에 노출하지 않을 수 있었습니다.
ipad 폴더에 있는 파일의 스크린샷
실제 공개 GitHub 모바일 캡처입니다. garrytan/gbrain, Public, 고정 커밋 a996e42가 보이며, 로그인하지 않은 화면이라 개인 계정 정보는 포함되지 않습니다.
1. 무엇을 보고 시작했나
GBrain은 개인·조직 지식을 검색하고, 관계를 연결하고, 답을 합성하는 “brain layer”를 표방하는 MIT 라이선스 프로젝트입니다. 저장소 README는 다음과 같은 구성을 설명합니다.
Markdown 등 지식 페이지 수집
keyword·vector·graph를 결합한 검색
근거 인용과 지식 공백을 포함한 답변 합성
엔터티와 관계를 연결하는 지식 그래프
로컬 stdio 및 HTTP 방식의 MCP 표면
recall,remember,entity,synthesize,forget으로 구성된 memory-verbs 표면
이번 검토는 변동하는 기본 브랜치가 아니라 커밋 a996e42856cc8b25c3a087b0c6671cd629d9b4ea, 버전 0.45.2.0에 고정했습니다. 아래의 대규모 페이지 수, 사용 사례, 벤치마크 수치는 모두 저장소 저자의 설명이며, 이번 로컬 실험에서 재현한 값으로 다루지 않았습니다.
왜 바로 설치하지 않았나
README의 설치 경로는 전역 명령, MCP 등록, skill 배포, dream cycle, cron 또는 장기 실행 서비스로 이어질 수 있습니다. 이런 기능은 편리하지만 동시에 다음 생산 자산에 영향을 줄 수 있습니다.
현재 QMD 인덱스
~/LLM-Wiki_LCLcanonical 자료Hermes 설정과 생산 MCP 등록
전역 skill, hook, cron
외부 embedding·LLM 경로
따라서 첫 질문을 “설치에 성공하는가”가 아니라 다음처럼 바꿨습니다.
기존 자료와 설정을 건드리지 않은 채, 이 도구에서 실제로 가져올 가치가 있는 계약이 무엇인지 확인할 수 있는가?
2. 파일럿을 ‘설치 실험’이 아니라 ‘보존 실험’으로 설계했습니다
실험은 별도 worktree와 별도 PGLite home에서 수행했습니다.
허용한 것
고정 커밋의 소스 체크아웃
별도 PGLite 데이터베이스
임베딩을 끈 keyword-only 검색
합성 한국어 문서 6건 import
verbs-only 및 full MCP surface에 대한 로컬 conformance
격리 QMD BM25 비교
금지한 것
gbrain bootstrap및 전역 설치실제 canonical 문서 import
embedding 또는 외부 corpus 호출
생산 MCP 등록
skill publish, self-upgrade
hook, cron, 장기 실행 서비스 생성
remote HTTP MCP
이 경계를 먼저 고정했기 때문에, 결과가 좋지 않아도 기존 운영 상태를 되돌릴 필요가 없었습니다.
3. 첫 번째 결과: 기억 계약은 예상보다 단단했습니다
GBrain의 전체 기능보다 먼저 memory-verbs 계약을 시험했습니다.
verbs-only 표면: 20 PASS, 0 FAIL, 3 intentional SKIP
full 표면: 23 PASS, 0 FAIL, 0 SKIP
verbs-only의 세 SKIP은 이 표면에 put_page가 없어 엔터티 페이지를 심을 수 없었던 2건과 비용 게이트를 유지한 synthesize 1건입니다. full 표면에서는 엔터티 카드와 private fence, synthesize=unavailable 경로까지 포함해 23건이 모두 통과했습니다. 외부 모델 API나 유료 합성 호출은 사용하지 않았습니다.
검증한 핵심 동작은 다음과 같습니다.
remember에는 provenance가 필요합니다.TTL 값은 검증됩니다.
remember → recall → forget왕복이 성립합니다.recall 응답에는 토큰 예산과 drop 메타데이터가 포함됩니다.
private fact는 다른 agent 범위로 새지 않습니다.
같은 대상을 다시 지우는
forget은 멱등적으로 처리됩니다.존재하지 않는 ID를 지우려 해도 fail-safe 응답을 돌려줍니다.
가장 눈에 띈 부분은 데이터베이스 자체보다 기억을 다루는 계약이었습니다. “무엇을 기억한다”보다 “누가, 어떤 근거로, 얼마 동안, 어느 범위에서 기억하고 지울 수 있는가”를 인터페이스에 드러낸 점은 기존 지식 작업에도 이식할 만했습니다.
4. 두 번째 결과: 한국어 직접 검색은 생산 기준을 통과하지 못했습니다
동일한 합성 한국어 문서 6건과 strict 질의 6건을 사용해 세 경로를 비교했습니다.
GBrain 직접 keyword-only
통과: 0/6
MRR: 0.0000
Hit@5: 0.0000
이 결과는 “GBrain 전체가 한국어를 못한다”는 뜻이 아닙니다. 이번 실험은 embedding을 끈 직접 keyword-only 경로에 한정됩니다. 다만 현재 조건에서는 생산 한국어 검색기를 대체할 근거가 없었습니다.
token-union adapter
질의를 공백 토큰으로 나눠 여러 CLI 검색을 합친 보정 경로에서는 다음 결과가 나왔습니다.
통과: 6/6
MRR: 1.0000
Hit@5: 1.0000
정확도는 회복됐지만 strict·diagnostic 평가 전체에 54개의 고유 CLI subprocess 질의가 필요했습니다. strict 질의 6건만 처리한 호출 수로 오해해서는 안 됩니다. p50, p95, 동시 부하를 측정하지 않았기 때문에 이 값은 “생산 성능 통과”가 아니라 검색 회상 가능성을 확인한 기능 증거로만 남겼습니다.
격리 QMD BM25
같은 strict 질의에서 다음 결과를 얻었습니다.
통과: 6/6
MRR: 1.0000
Hit@5: 1.0000
따라서 현재 문서 검색 계층은 QMD를 유지하기로 했습니다. GBrain의 관계형 기억 장점이 확인됐다고 해서, 이미 검증된 검색기를 함께 바꿀 이유는 없었습니다.
5. 세 번째 결과: 기능 통과와 생산 승격은 다른 판정이었습니다
최종 gate는 22개 중 19개가 통과했습니다. 실패 3개는 숨기지 않고 판정의 중심에 두었습니다.
실패 1 — 한국어 직접 strict 검색
직접 keyword-only 경로가 0/6이었습니다. adapter로 보정할 수 있었지만, 그 경로는 성능 검증 전이므로 생산 대체 근거가 되지 못했습니다.
실패 2 — self-upgrade DB-plane 잠금 미확인
파일 시스템 쪽 self-upgrade 억제는 확인됐지만, PGLite 데이터베이스 안의 잠금 상태를 같은 수준으로 증명하지 못했습니다. 실행하지 않았거나 확인하지 못한 것을 PASS로 올리지 않았습니다.
실패 3 — Hermes 설정 전체 바이트 보존
파일럿 종료 시 Hermes 설정 파일의 전체 해시가 기준선과 달랐습니다. 보안 관련 투영 값과 생산 GBrain 등록 부재는 유지됐지만, 전체 파일 동일성 게이트는 실패로 남겼습니다.
이 드리프트의 원인을 GBrain으로 단정하지 않았습니다. 관찰된 사실은 “해시가 달라졌다”이고, 인과관계는 검증되지 않았습니다. 따라서 “GBrain이 설정을 바꿨다”가 아니라 “전체 바 이트 보존을 증명하지 못했으므로 승격하지 않는다”고 판정했습니다.
6. 실제로 바뀐 것은 무엇인가
유지하기로 한 설계
출처가 없는 memory write 거부
TTL과 토큰 예산을 가진 recall
private/local visibility fence
멱등적 forget
엔터티·관계 중심 기억 모델
명시적인 memory-verbs conformance test
보류한 도입
QMD 문서 검색 대체
한국어 직접 keyword-only 생산 검색
bootstrap 또는 전역 설치
자동 skill publish와 self-upgrade
실제 canonical import
remote HTTP MCP
권고한 후속 구조
사용자 / 에이전트
│
├─ 문서 검색 ──> QMD + canonical library (현행 유지)
│
└─ 관계형 기억 ─> 격리 GBrain verbs-only sidecar (후속 승인 시)
이 구조는 검색 계층 전체를 갈아엎지 않고, 확인된 장점만 좁게 붙이는 방식입니다.
7. 증거는 현재 바이트까지 다시 읽었습니다
파일럿 종료 시 선택한 증거 파일 28개를 manifest에 묶었습니다. 이 사례게시글을 작성하기 직전 다시 읽어 확인한 결과는 다음과 같습니다.
선택 증거: 28/28 존재
바이트 수: 28/28 일치
SHA-256: 28/28 일치
고정 소스 HEAD: 일치
고정 소스 worktree: clean
manifest SHA-256:
49c2bbdc9d43485baec903864e11ec14fd01c926d7e2dded84bcd92caf2c1856
이 검증은 파일 정체성과 현재 바이트를 확인한 것입니다. 별도의 독립 심사 판정을 대신하거나 생산 승격을 허가하지는 않습니다.
8. 이번 사례에서 얻은 교훈
1) 새 도구는 기능표보다 경계표를 먼저 봐야 합니다
전역 설치, 설정 변경, 자동화 등록이 한 번에 묶인 도구일수록 먼저 “이번 실험에서 절대 하지 않을 것”을 정해야 합니다.
2) 장점은 제품 단위가 아니라 계약 단위로 가져올 수 있습니다
GBrain 전체를 도입하지 않아도 provenance, TTL, visibility, forget 같은 기억 계약은 별도로 채택할 수 있습니다.
3) 정확도 회복과 생산 적합성은 다릅니다
adapter가 6/6을 맞힌 것은 의미가 있지만, 여러 subprocess를 사용하고 latency가 미측정이면 생산 경로 통과가 아닙니다.
4) 실패 게이트는 도입을 방해하는 잡음이 아니라 의사결정 자료입니다
0/6 검색 결과와 설정 해시 드리프트를 숨겼다면 “설치 성공 사례”는 만들 수 있었겠지만, 재현 가능한 운영 판단은 만들 수 없었을 것입니다.
5) 보존을 증명하지 못하면 승격하지 않는 편이 낫습니다
원인이 불명확한 드리프트를 특정 도구 탓으로 돌릴 필요는 없습니다. 반대로 원인을 모른다는 이유로 PASS 처리해서도 안 됩니다. 이번에는 그 중간인 HOLD_NO_PROMOTION을 택했습니다.
9. 재현 범위와 한계
확인한 것
macOS arm64, Bun 1.3.10
GBrain 0.45.2.0 고정 커밋
별도 PGLite
합성 한국어 문서 6건
embedding OFF
직접 검색, token-union adapter, 격리 QMD 비교
verbs-only 및 full memory protocol conformance
생산 등록 부재와 선택 보존 게이트
확인하지 않은 것
실제 사용자 canonical 자료 품질
vector·embedding 검색
LLM 합성 답변의 정확성
GraphRAG 전체 벤치마크 재현
HTTP MCP, OAuth, 다중 사용자 운영
cron, dream cycle, 장기 안정성
adapter의 p50, p95, 부하 성능
생산 rollout
따라서 이 글은 GBrain 일반 성능 평가가 아니라, 특정 시점·특정 고정 커밋·특정 격리 조건에서 수행한 도입 전 검증 사례입니다.
10. 마무리
처음에는 “이 지식 브레인을 붙이면 더 똑똑해질까?”를 물었습니다. 실험을 거치며 검토 범위를 다음 후속 과제로 좁혔습니다.
문서 검색은 그대로 두고, 근거·기한·범위·삭제 계약만 가진 관계형 기억 계층을 안전하게 덧붙이는 격리 실험을 설계한다.
이 과제는 후속 파일럿으로 검토할 가치가 있습니다. 하지만 현재 고정본의 생산 승격은 아직 승인할 수 없습니다.
이번 작업에서는 도입하지 않을 이유도 실행 증거로 남겼고, 제품 전체 대신 재사용할 수 있는 기억 계약을 분리했습니다.
