검색 결과를 넘겨주지 않고, 답과 빈칸까지 남기는 에이전트 메모리

에이전트에게 문서를 많이 넣어 주는 것과, 조직이 아는 것을 다시 쓸 수 있게 만드는 것은 다른 일입니다. 전자는 검색입니다. 후자는 누가 무엇을 언제 어떤 근거로 알았는지, 무엇이 아직 비어 있는지까지 남겨 두는 운영 체계입니다. 검색은 문서의 위치를 찾고, 운영 체계는 답의 근거·빈칸·권한을 남깁니다.

Garry Tan이 공개한 GBrain은 이 두 번째 문제를 겨냥한 오픈소스 프로젝트입니다. 프로젝트의 표현을 빌리면 검색 결과 목록 대신 인용이 붙은 답을 만들고, 지식 그래프와 공백 분석을 한 상자에 넣으려는 "brain layer"입니다. 이번 글에서는 레포지토리에 실제로 무엇이 들어 있는지, 그리고 이런 계층을 조직의 에이전트 운영에 어디까지 써야 하는지를 정리합니다.

한 문장 결론

GBrain의 핵심은 LLM 자체가 아니라 원천, 사실, 관계, 현재 요약을 서로 다른 형태로 유지하는 데이터 모델입니다. 다만 이 구조는 기존 정본을 대체할 제품이 아니라, 권한과 출처를 보존한 채 답변 품질을 높이는 보조 계층으로 도입해야 합니다.

레포지토리 안에는 무엇이 있나

GBrain은 Bun과 TypeScript 기반의 CLI, MCP 서버, 플러그인, 관리자 화면, 테스트와 운영 문서를 함께 담은 프로젝트입니다. 가볍게는 로컬 PGLite 데이터베이스에서 돌고, 규모가 커지면 PostgreSQL과 벡터 검색을 쓰는 경로를 제시합니다. Codex, Claude Code, Hermes 등 여러 에이전트 도구에 MCP로 붙이는 방법과 에이전트용 설치 지침도 포함합니다. README의 설치 및 연결 안내가 이 제품의 첫 번째 표면입니다.

하지만 제품의 중심은 연결 방식이 아닙니다. 자료가 들어오면 다음 네 층으로 나누어 다룹니다.

층	하는 일	왜 필요한가
원천	메일, 회의, 문서, 캘린더 등 원본과 수집 시점 보존	나중에 답의 근거를 다시 확인할 수 있다
이벤트와 사실	관측 사실을 출처·시점·신뢰도와 함께 기록	새 정보가 들어와도 과거를 지우지 않는다
엔티티와 관계	사람, 회사, 딜, 프로젝트를 식별하고 연결	"누가 이 회사와 연결돼 있나" 같은 질문을 풀 수 있다
합성 답변	현재 상태를 요약하고 인용과 공백을 함께 제시	검색 결과를 읽는 시간을 줄인다

원천은 다시 확인할 재료로 남습니다. 사실과 관계는 현재 상태를 계산하고, 합성 답변은 그 결과를 사람이 읽는 형태로 돌려줍니다.

이 설계는 권장 스키마 문서에 더 노골적으로 드러납니다. 하나의 지식 페이지는 위쪽의 "현재 정리"와 아래쪽의 지우지 않는 시간축으로 나뉩니다. 페이지를 최신 상태로 고쳐 쓰되, 과거 증거를 덮어쓰지 않겠다는 약속입니다.

같은 문서는 파일 기반 위키만으로는 부족하다고 봅니다. 엔티티 식별은 레지스트리, 사건은 이벤트 원장, 주장과 출처는 사실 저장소, 연결은 관계 그래프로 별도 관리합니다. 이 네 가지가 있어야 이름이 다른 동일 인물을 합치고, 상충된 정보 두 개를 감추지 않으며, 사람이 직접 읽어야만 알 수 있던 관계를 질의할 수 있다는 논리입니다.

검색과 "생각"의 차이

GBrain은 원문 조각을 찾는 search와, 찾은 자료를 읽어 인용과 지식 공백을 포함해 답하는 think를 구분합니다. 이 구분은 중요합니다. 투자팀이나 운영팀에서 좋은 질문은 대개 "어디에 있지?"가 아니라 "우리가 지금 무엇을 알고 있고, 무엇을 더 확인해야 하지?"이기 때문입니다.

예를 들어 미팅 전 준비에는 담당자의 최근 역할, 마지막 대화, 열린 과제가 한 번에 필요합니다. 검색은 관련 문서 다섯 개를 줄 수 있습니다. 합성 계층은 그 다섯 개에서 현재 답을 만들고, 마지막 업데이트 이후 새 메일이나 대화가 수집되지 않았다는 공백까지 말해야 합니다. README의 미팅 준비 예시는 바로 이 차이를 설명합니다.

프로젝트는 문서가 쌓이면 페이지 내 엔티티 참조에서 유형화된 관계를 만들고, 하이브리드 검색과 그래프 탐색을 결합한다고 설명합니다. 공개 README에는 자체 벤치마크의 P@5 49.1%, R@5 97.9%와 그래프 비활성화 대비 P@5 31.4포인트 개선이 제시됩니다. 이는 프로젝트가 공개한 자체 평가이지 외부 독립 검증값은 아닙니다. 그래도 "검색 품질"보다 "재현 가능한 근거를 가진 답"을 제품 단위로 본다는 방향은 분명합니다.

눈여겨볼 운영 장치 세 가지

첫째는 사실과 의견의 분리입니다. 프로젝트는 실시간 대화에서 잡은 개인의 사실과, 여러 문서에서 추출한 타인의 주장·예측·추정을 다른 저장층에 둡니다. 밤사이 통합 과정에서만 전자를 후자의 장기 지식으로 승격합니다. Takes vs Facts 문서가 강조하는 것은 간단합니다. 창업자의 매출 주장, 심사역의 견해, 확인된 사실을 한 칸에 넣는 순간 지식 시스템은 위험해진다는 것입니다.

둘째는 저장 계층의 분리입니다. 사람 손으로 관리할 핵심 지식은 Git 추적 경로에, 대량의 기사·소셜 자료·녹취는 데이터베이스 전용 경로에 둡니다. 대규모 수집 때문에 사람이 읽을 지식 저장소가 비대해지는 것을 막고, 필요할 때 데이터베이스에서 복구합니다. Storage Tiering 문서는 이 구분과 복구 절차를 설명합니다.

셋째는 권한 경계입니다. 팀용 brain은 로그인별 가시성을 두고, 원격 에이전트 호출과 로컬 CLI 호출을 신뢰 경계로 구분합니다. 콘텐츠 가드레일은 관찰 전용이며, 수집이나 답변을 차단하지 않습니다. 가드레일을 정책 집행으로 오인하면, 제공자가 실패했을 때 위험해지기 때문입니다. 가드레일 설계 문서는 이 지점을 명시합니다.

Thesis OS에 적용한다면, 무엇을 가져오고 무엇을 남겨야 하나

도입의 첫 단계는 공개 자료나 이미 비식별화된 내부 메모만으로 제한하는 것입니다. 두세 개의 실제 질문을 정해, 답변마다 원문 인용이 정확한지, 최신성이 표시되는지, 서로 다른 권한의 정보가 섞이지 않는지를 측정해야 합니다. 통과 기준은 답변의 문장력이 아니라 인용 정확도, 누락 탐지율, 권한 누출 0건, 그리고 사람이 확인하는 데 걸리는 시간의 감소여야 합니다.

조직의 투자 기록, 운영 레지스트리, 승인 원장, 원본 보관소는 각자 정본과 권한 체계를 이미 갖고 있습니다. 새로운 brain이 이들을 다시 쓰거나 여러 에이전트의 대화 원문을 한꺼번에 섞으면, 감사 가능성과 기밀 경계가 무너집니다. GBrain은 이 정본을 대체하지 않고 읽는 역할에 머물러야 합니다.

대신 아래의 분업이 적절합니다.

기존 정본	GBrain형 보조 계층
정책, 워크플로, 승인, 의사결정 기록	정본을 읽고 근거 링크가 붙은 현재 브리핑 생성
Vault의 검증된 리서치와 메모	엔티티, 시간축, 충돌 후보를 색인
역할별 권한과 비공개 범위	같은 범위를 강제한 읽기 전용 검색과 합성
사람의 승인 게이트	다음 확인 항목을 제안하되 승인·발송·투자 행동은 수행하지 않음

그 다음에야 역할별 읽기 범위와 별도 데이터베이스를 붙일 수 있습니다. 쓰기는 마지막입니다. 자동 수집 결과가 정본에 반영되려면 출처, 시점, 신뢰도, 충돌 여부, 담당자 승인이 모두 남아야 합니다. 특히 투자 관련 사실과 판단은 자동 합성 결과가 아니라 검증된 증거와 명시적 승인에 의해 갱신되어야 합니다.

투자 관점에서 남는 질문

이 분야의 해자는 벡터 데이터베이스나 대화형 화면 하나가 아닙니다. 합법적으로 계속 들어오는 고품질 원천, 주장과 증거를 섞지 않는 데이터 모델, 틀린 인용과 오래된 요약을 고치는 평가·운영 루프가 함께 작동해야 합니다.

GBrain은 이 조건을 오픈소스의 언어로 보여 줍니다. 동시에 수집 범위가 넓어질수록 개인정보, 권한, 비용, 잘못된 자동 정리의 위험도 함께 커진다는 한계도 드러냅니다. 처음의 구분으로 돌아가면, 좋은 company brain은 "모든 것을 기억하는 AI"가 아니라 권한 안에서 근거를 보이며 무엇을 아직 모르는지 말하는 운영 체계여야 합니다.

출처와 한계

2026년 8월 27일 기준 GBrain 공개 GitHub 레포지토리의 README, 권장 스키마, 저장 계층, 사실·의견 분리, 가드레일 문서를 근거로 삼았습니다. 레포지토리에 기재된 운영 규모, 성능 지표, 보안 테스트 결과는 저자 및 프로젝트의 공개 주장으로서 별도 독립 감사를 거친 사실로 보지 않았습니다.