GBrain은 AI 에이전트에게 '지식의 뇌(brain layer)'를 부여하는 오픈소스 지식 런타임(Knowledge Runtime)입니다. 제작자는 Y Combinator의 President 겸 CEO인 Garry Tan이며, 라이선스는 MIT, 구현 언어는 TypeScript를 사용하며, GitHub에서 2만 개 이상의 스타(Star)를 기록하고 있습니다 (2026년 6월 기준).

GBrain의 위치는 리포지토리 도입부의 한 문장에 잘 나타나 있습니다. "Search gives you raw pages. GBrain gives you the answer. (검색은 가공되지 않은 페이지를 제공하지만, GBrain은 답을 제공한다)". 일반적인 개인 지식 도구가 키워드 일치나 벡터 검색(Vector Search)을 통해 '관련 있어 보이는 페이지 목록'을 반환하는 것과 달리, GBrain은 여러 페이지를 가로질러 **합성된 답(Synthesized Answer)**을 출처 및 '아직 파악되지 않은 사항'에 대한 주석과 함께 반환합니다.

이 기사에서 알 수 있는 내용:

• 🔍 GBrain이 '검색'과 무엇이 다른가 (페이지 목록이 아닌 답을 반환한다는 설계)
• ✨ 두 가지 차별화 요소 — 합성 레이어(Synthesis Layer)와 자기 배선형 지식 그래프(Self-wiring Knowledge Graph)
• 🏗️ 아키텍처 — Postgres + pgvector (WASM) 및 'Markdown 기술' 구성
• 🎯 하이브리드 검색 + 그래프의 4단계 구조와 그 실측 벤치마크
• 🌙 데이터 입력 방식과 야간에 똑똑해지는 '드림 사이클(Dream Cycle)'
• 🗂️ 브레인(Brain) / 에이전트 메모리(Agent Memory) / 세션(Session)의 3층 구조 활용법
• ⚙️ 도입 방법 (에이전트에 의한 자동 설치 / CLI / MCP) 및 3가지 배포 구성

예상 독자는 AI 에이전트에게 영속적인 지식 기반을 갖게 하고 싶은 개발자 및 팀 리더입니다.

GBrain의 출발점은 Garry Tan 씨가 자신의 AI 에이전트(OpenClaw / Hermes)를 운영하는 과정에서 맞닥뜨린 두 가지 문제였습니다. 공식 Origin 문서에 따르면, 초기 버전은 스킬과 브레인을 갖추고 있었으나 브레인의 실체는 'Markdown 파일이 나열된 평면적인 디렉토리'였으며, 검색은 ripgrep을 사용하고 기억은 직관에 의존하는 수준이었다고 합니다.

그 과정에서 드러난 문제는 다음과 같습니다.

• 에이전트가 대화를 넘어서는 사항을 잊어버린다. 새로운 세션이 시작될 때마다 기본적인 질문을 다시 해야 하며, 지난주에 소개된 사람의 이름조차 사라진다.
• 에이전트가 작업을 중복시킨다. 동일한 회사에 관한 두 개의 신호가 두 개의 서로 다른 페이지가 되고, 동일 인물과의 세 번의 회의가 세 개의 무상관 타임라인으로 남는다.

이 두 가지를 '허용할 수 없다'고 결정했을 때 만들어진 것이 GBrain입니다. 구체적인 예를 보면 차이가 명확합니다. 예를 들어 "내일 Alice와의 회의 전에 무엇을 알고 있어야 해?"라고 물었을 때, 많은 도구는 다음과 같은 페이지 목록을 반환합니다.

1. people/alice — Alice runs engineering at Acme...
2. meetings/2026-03-15-alice-q1 — Q1 product review with Alice...
3. customers/acme — Acme is a series-B fintech we work with...
...

사용자는 이 5개의 페이지를 직접 열어서 읽고 준비해야 합니다. 반면, GBrain은 출처가 포함된 답 그 자체를 반환합니다.

Alice는 Acme(시리즈 B 핀테크 기업)에서 엔지니어링을 총괄하고 있습니다.
마지막으로 대화한 내용은 4/22 가격에 관한 짧은 교신이었습니다.
그로부터 미결 사항이 3가지 있습니다:
...

끝부분의 '주의 사항'이 GBrain이 다른 것과 차별화되는 지점입니다. 모든 주장에는 출처 페이지가 연결되며, 나아가 "브레인이 아직 알지 못하는 것(정보가 오래됨, 출처 없음, 모순됨)"을 명시합니다. 검색 엔진은 페이지를 찾아내고, 뇌는 그것을 읽고 답을 작성한다는 차이가 있습니다.

이 도표의 핵심은 검색 도구가 '재료를 찾는' 단계에서 멈추는 반면, GBrain은 동일한 재료를 읽고 '답을 작성하는' 단계까지 나아간다는 점입니다.

GBrain은 많은 개인 지식 도구가 갖춘 키워드 일치나 grep 기능을 내포하면서도, 다른 도구들이 잘 포함하지 않는 두 가지 기능을 조합하고 있습니다.

첫 번째는 실제 답변을 반환하는 합성 레이어 (Synthesis Layer)입니다. 사람, 회사, 프로젝트, 아이디어를 가로질러 출처가 포함된 산문(prose) 형태로 답변을 합성합니다. "쿼리에 언급된 10개의 청크(chunk)"를 반환하는 것이 아니라, "이 답변 + 출처 + 아직 파악되지 않은 사항에 대한 주석"을 반환합니다. 바로 이 **갭 분석 (Gap Analysis)**이야말로 GBrain의 사용 방식을 바꾸는 핵심 요소로 자리매김하고 있습니다.

두 번째는 자동으로 연결되어 가는 지식 그래프 (Knowledge Graph)입니다. 모든 페이지를 작성할 때 엔티티 참조 (entity reference)를 추출하여, attended (참석함) / works_at (소속됨) / invested_in (투자함) / founded (창업함) / advises (조언함)와 같은 **타입이 지정된 에지 (typed edge)**를 LLM 호출 없이 (zero LLM calls) 생성합니다. 이를 통해 "Acme AI에서 누가 일하고 있는가?", "Bob은 이번 분기에 무엇에 투자했는가?"와 같이 벡터 검색 (vector search)만으로는 도달할 수 없는 질문에 답할 수 있습니다.

다음 그림은 페이지 작성으로부터 그래프가 성장하는 흐름을 보여줍니다.

이 그림의 핵심은 에지 추출이 3개의 정규 표현식과 단 1회의 SQL만으로 완결되며, LLM을 전혀 사용하지 않는다는 점입니다. 공식 문서에 따르면, 그래프는 매번 작성할 때마다 거의 제로 코스트로 성장하며, 1만 7천 페이지 규모의 GBrain에서도 그래프 전체 추출이 몇 초 만에 완료된다고 합니다.

이 그래프의 효과는 벤치마크에서도 나타납니다. 공식 README와 문서가 보여주는 BrainBench (240 페이지의 Opus 생성 리치 산문 코퍼스)의 수치는 다음과 같습니다.

공식 문서는 그래프와 추출 품질의 고도화를 통해 P@5가 +31.4 포인트 상승했다고 설명하며, "그래프는 부수적인 기능이 아니라, 하중을 지탱하는 벽 (load-bearing wall)이다"라고 정의합니다.

GBrain 구성의 특징은 무거운 의존성을 가져오지 않는다는 것입니다. 데이터베이스는 Postgres + pgvector를 사용하지만, WASM 상에서 동작하는 PGLite를 사용함으로써 "서버 없이 2초 만에 데이터베이스가 구동되는" 상태를 실현했습니다 (공식 문서에 따르면 PGLite는 개인용 GBrain에서 대략 5만 페이지 규모까지 대응하며, 이를 초과하는 규모나 약 1,000개 이상의 파일이 있는 경우에는 Supabase를 권장합니다).

그리고 에이전트의 행동을 결정하는 "스킬 (skill)"은 코드가 아닌 Markdown으로 작성되며, 이들을 묶어주는 것은 라우터 LLM이 아닌 작은 텍스트 파일입니다. 전체 구조는 다음 그림과 같습니다.

이 그림의 핵심은 클라이언트가 MCP (Model Context Protocol)를 통해 엔진에 연결되며, 엔진 지능의 대부분이 "Markdown 스킬"과 "라우팅 표"로 외부에 분리되어 있다는 점입니다.

이 설계의 배경에는 Garry Tan이 제창하는 **Thin Harness, Fat Skills (얇은 하네스, 두꺼운 스킬)**라는 개념이 있습니다. 그의 에세이에 따르면, AI 에이전트의 생산성을 가르는 것은 모델의 똑똑함이 아니라, 모델을 감싸는 "하네스 (harness)"와 "스킬 (skill)"이라고 합니다.

• **스킬 파일 (Skill file)**은 "무엇을 하는가 (WHAT)"가 아니라 "어떻게 하는가 (HOW)"를 가르치는 재사용 가능한 Markdown 절차서입니다. 파라미터를 취하고 인자를 변경하여 호출할 수 있다는 점에서 "메서드 호출 (method call)처럼 작동한다"고 설명됩니다.
• **하네스 (Harness)**는 LLM을 실행하는 프로그램으로, 루프 실행, 파일 읽기/쓰기, 컨텍스트 관리, 안전성 강제만을 담당하는 "얇은" 존재로 유지합니다. 40개 이상의 도구 정의로 컨텍스트를 소모하는 "두꺼운 하네스"는 안티 패턴으로 간주됩니다.
• **리졸버 (RESOLVER)**는 "문맥을 위한 라우팅 표"입니다. 태스크 유형 X가 나타나면 문서 Y를 먼저 읽는다는 식의 대응 관계를 정의합니다.

GBrain은 이러한 사상을 "GBrain (Brain)"이라는 형태로 구체화한 것이라고 할 수 있습니다.

GBrain의 검색이 '페이지 목록으로서 우수'한 이유는 4가지 전략을 중첩하고 있기 때문입니다. 공식 Retrieval (검색) 문서에서는 벡터 검색(Vector Search)만으로는 실제 개인 지식 검색에 역부족이라고 설명합니다.

이 그림의 핵심은 4가지 전략이 상호 보완 관계에 있다는 것입니다. 문서는 "각 전략은 단독으로는 실패한다"라고 정리하고 있습니다.

벡터(Vector)만 사용: 임베딩(Embedding)에 직접 인코딩되지 않은 사실 관계를 놓침 ("Garry의 포트폴리오 기업"을 검색했을 때 포트폴리오 이론에 관한 에세이를 반환함).

키워드(Keyword)만 사용: 유의어(Paraphrasing)에 취약 ("retrieval"을 찾으면 "search ranking"이라고 적힌 페이지를 놓침).

그래프(Graph)만 사용: "Alice의 이웃"은 잘 찾아내지만, 아직 링크되지 않은 것에는 무력함.

그래프 없는 하이브리드(Hybrid): "X란 무엇인가?"에는 강하지만, "Y와 X의 관계는?"과 같은 그래프적인 질문에는 약함.

여기에 더 상위 단계로 **리랭커(Reranker)**가 위치합니다. v0.36.0.0 버전에서는 ZeroEntropy의 zerank-2가 기본 리랭커로 탑재되었으며, 문서에 따르면 실제 코퍼스(Corpus) 20개 쿼리에서 Top 1 결과를 60% 교체한다고 합니다. 비용은 p50 기준 +150ms, 약 $0.025/M 토큰이며, 검색 후에 LLM 처리가 이어지는 에이전트 루프(Agent Loop)에서는 지연이 거의 느껴지지 않는다고 설명합니다. 랭킹은 소스(Source)에도 민감하여, originals/나 concepts/와 같은 엄선된 콘텐츠가 daily/나 media/와 같은 대량의 콘텐츠보다 상위에 오도록 SQL 레이어에서 가중치(Weighting)가 부여됩니다.

GBrain에는 성격이 다른 두 가지 쿼리 방법이 있습니다.

# 생(Raw) 검색: 하이브리드 스코어 상위의 페이지를 반환. 빠름, LLM 비용 없음
gbrain search "who's working on AI agents at portfolio companies?"
# 브레인(Brain) 레이어: 출처 포함 + 갭 분석(Gap Analysis)이 포함된 합성된 답변
...

두 방식은 역할이 다릅니다. gbrain search는 하이브리드 스코어(벡터 + 키워드 + RRF + 소스 티어 보정 + 리랭커)를 통해 상위 페이지를 반환합니다. 에이전트의 컨텍스트(Context)에 재료를 흘려넣고 싶을 때나 인용 출처를 찾고 싶을 때 적합합니다. 반면 gbrain think는 동일한 검색을 실행한 후 결과를 횡단하여 답변을 합성하며, 출처와 "아직 파악되지 않은 점"에 대한 주석을 달아줍니다.

다음 그림은 gbrain think가 답변을 구성하는 흐름입니다.

이 그림의 핵심은 think가 search와 동일한 검색을 토대로 하면서, 그 위에 "합성"과 "파악되지 않은 점의 명시"를 중첩한다는 점입니다.

공식 문서는 gbrain think를 find_trajectory와 같은 도구와 결합하면, "지표가 어떻게 변했는가 × 팀의 현재 상황 × 약속한 사항 × 마지막으로 만난 시기 × 제공할 수 있는 가치"를 한 번에, 높은 스코어링과 정확한 출처를 갖춘 형태로 얻을 수 있다고 설명합니다. gbrain agent run "..."를 사용하면 동일한 기능을 Minions라는 큐(Queue)를 통해 서브 에이전트(Sub-agent)에게 공개할 수 있으며, 크래시 내성(Crash tolerance)이 있는 2단계 영속화(Persistence) 방식으로 실행됩니다.

데이터 수집은 단 한 번의 명령으로 가능하며, 동기적으로 영수증(Receipt)이 반환됩니다.

gbrain capture "기억해두고 싶은 아이디어"
gbrain capture --file ./notes/today.md
echo "from a pipe" | gbrain capture --stdin

페이지는 데이터베이스와 디스크에 동시에 저장됩니다. 기본 슬러그(Slug)는 inbox/YYYY-MM-DD-<hash8>이며, 수집된 항목들이 예측 가능한 분류(Triage) 장소로 모이도록 설계되어 있습니다. Zapier / IFTTT / Apple Shortcuts를 통해서는 Webhook(/ingest)으로 POST 요청을 보내 수집할 수도 있습니다.

그리고 GBrain의 특징적인 메커니즘은 야간에 실행되는 **드림 사이클 (dream cycle)**입니다. 에이전트를 채팅으로 계속 작동시키는 것보다, 24시간 365일 작동하는 데몬 (daemon)에게 수집·확충·통합을 맡기는 것이 더 간단하다는 발상에 기반하고 있습니다.

이 그림의 핵심은 브레인 (brain)이 단순히 '저장'하는 것에 그치지 않고, 밤사이에 스스로를 정돈한다는 점입니다. README에 따르면, 제작자의 실제 운영 중인 브레인은 회의, 이메일, 트윗, 음성 통화, 자신의 아이디어를 수집하면서 만난 사람과 회사를 순차적으로 확충하고, 인용을 스스로 수정하며, 기억을 통합하고 있습니다. 실제 운영 중인 브레인의 규모는 146,646 페이지 / 24,585명 / 5,339개 회사, 66개의 cron 잡 (job)이 자율 가동 (README의 자기 신고 값)되는 수준이라고 합니다.

GBrain을 사용할 때 중요한 것은 '무엇을 어느 계층에 둘 것인가'라는 설계입니다. 공식 가이드는 정보를 3개 계층으로 분류할 것을 권장합니다.

이 그림의 핵심은 '세계에 관한 사실'과 '에이전트의 조작 상태'를 섞지 않는 것입니다. 구체적인 예를 보면 이해하기 쉽습니다.

가이드는 "인물을 에이전트 메모리 (agent memory)에 넣지 마라", "사용자의 취향을 GBrain에 넣지 마라"고 주의를 줍니다. 특히 에이전트 메모리는 플랫폼에 따라 리셋 시 삭제될 수 있으므로, 사라지면 안 되는 세계 지식은 반드시 GBrain (영속적 저장소)에 둘 것이라는 지침이 제시되어 있습니다. 고민될 때는 "이것은 세계에 관한 것인가, 조작 방법에 관한 것인가"를 물어보면 된다는 정리입니다.

GBrain은 "AI 에이전트에 의해 설치 및 운용된다"는 전제로 설계되었습니다. 가장 빠른 경로는 에이전트 스스로 설치하게 하는 것입니다.

OpenClaw나 Hermes, 혹은 Claude Code / Codex / Cursor 등에 다음 지시 사항을 붙여넣습니다.

Retrieve and follow the instructions at:

에이전트가 GBrain을 설치하고, 브레인을 생성하며, API 키를 묻고, 43개의 스킬 (skill)을 로드하고, 드림 사이클을 설정한 뒤, 엔드 투 엔드 (end-to-end)로 검증을 수행합니다. 소요 시간은 약 30분이며, 인간은 질문에 답하기만 하면 되는 흐름입니다.

"우선 코딩 에이전트에게 기억을 갖게 하고 싶다"라면, 단 2개의 명령어로 끝납니다.

gbrain init --pglite # 2초 만에 완료되는 로컬 브레인 (Docker 불필요)
claude mcp add gbrain -- gbrain serve # Codex라면 codex mcp add ...

bun install -g github:garrytan/gbrain
gbrain init --pglite # 2초. 서버 없음, Docker 없음
gbrain doctor # 헬스 체크 (health check)
...

GBrain은 MCP (stdio 및 HTTP)를 통해 30개 이상의 도구 (tool)를 공개합니다. HTTP 서버는 OAuth 2.1 + 관리 대시보드 (/admin)를 갖추고 있으며, DCR 스타일의 클라이언트 등록, 스코프 (scope)에 따른 액세스 제어 (read / write / admin), 그리고 속도 제한 (rate limiting) 기능을 포함합니다.

GBrain은 3가지 배포 형태를 지원하며, 이들은 조합이 가능합니다.

이 그림의 핵심은 어떤 형태든 최종적으로는 "현재 어떤 ~/.gbrain/config.json이 유효한가"로 귀결된다는 통일된 개념입니다. Thin client에서는 로컬 DB 대신 remote_mcp 필드가 설정에 포함되며, DB를 조작하는 명령은 명확한 에러 메시지와 함께 원격 호스트로 안내됩니다.

GBrain은 개인 용도뿐만 아니라 팀의 '지식 베이스 브레인 (knowledge base brain)'으로도 작동합니다. 팀의 각 구성원은 로그인을 통해 스코프가 지정된 자신만의 슬라이스 (slice)를 가지며, 쿼리 (query) 시에는 자신이 볼 수 있는 것만 보이게 됩니다. 타인의 메모나 다른 팀의 데이터는 보이지 않습니다.

공식 README에 따르면, 브레인 (brain)을 읽는 모든 경로(검색, 목록, 룩업, 다중 소스 읽기)에 대해 퍼즈 테스트 (fuzz test)를 수행하여 **데이터 유출 제로 (leak zero)**를 확인했다고 합니다. 이는 Y Combinator가 Request for Startups에서 언급한 'company-brain'의 형태에 대응하는 것으로 정의되어 있습니다.

💡 보안의 핵심은 OAuth 2.1과 스코프 제어 (read / write / admin), 그리고 속도 제한 (rate limiting)입니다. ChatGPT 연동 시에는 PKCE가 포함된 OAuth 2.1이 필수이며, Perplexity 연동 시에는 최소 권한의 OAuth 클라이언트 (OAuth client)를 발행하는 등 클라이언트별 프로토콜이 마련되어 있습니다.

마지막으로, GBrain의 본질을 3가지로 요약합니다.

도입을 시도한다면, 우선 작게 시작하는 것이 현실적입니다. gbrain init --pglite 명령어로 서버 없는 로컬 브레인 (local brain)을 2초 만에 구축하고, Claude Code나 Codex에 MCP로 연결하는 것부터 시작할 수 있습니다. 그 후 데이터 수집 (capture)을 습관화하고, search와 think를 구분하여 사용하며, 필요에 따라 드림 사이클 (dream cycle)이나 씬 클라이언트 (thin client) 구성으로 확장해 나가는 순서가 무리가 없습니다.

GBrain이 보여주는 것은 에이전트를 똑똑하게 만드는 것이 모델의 크기가 아니라, "올바른 문맥을 올바른 타이밍에 전달하는 메커니즘"이라는 생각입니다. 코드를 작성하기 전의 지식 기반을 재현 가능한 형태로 정비함으로써, 에이전트를 '일회성 채팅'에서 '조직에서 운용 가능한 뇌'로 격상시킬 수 있습니다. 이러한 설계를 오픈소스 (open source)로 확인할 수 있다는 점에 가치가 있습니다.

• garrytan/gbrain (GitHub 리포지토리) — GBrain 본체. README에 가치 제안, 설치 방법, 프로덕션 (production) 수치, 벤치마크 요약이 포함되어 있습니다.
• gbrain docs/architecture/RETRIEVAL.md — 하이브리드 + 그래프 + 리랭커 (reranker)의 4단계 구조와 BrainBench 수치의 근거.
• gbrain docs/ethos/THIN_HARNESS_FAT_SKILLS.md — 스킬 / 하네스 / 리졸버 (resolver)의 정의 (Thin Harness, Fat Skills).
• gbrain docs/guides/brain-vs-memory.md — 브레인 / 에이전트 메모리 / 세션의 3계층 분류.
• gbrain-evals (BrainBench) — 검색 품질 벤치마크의 코퍼스 (corpus) 및 하네스 (harness).