GBrain은 기억을 어떻게 다음 행동으로 바꾸는가

메일에 “금요일까지 제안서를 보내겠습니다”라고 썼다고 해보자. 이 메일을 읽은 에이전트가 약속을 챙기고 필요한 작업까지 하려면 무엇이 더 필요할까?

메일을 검색하면 그 문장이 담긴 대화를 다시 찾을 수 있다. 검색 증강 생성(RAG)을 붙인 세컨드 브레인은 관련 메일과 회의 기록을 모아 요약해 줄 수도 있다. 하지만 메일을 찾아주는 것과 금요일까지 제안서를 보내야 한다는 사실을 계속 챙기는 것은 다르다. 에이전트가 일을 시작하려면 누가 누구에게 무엇을 약속했는지, 기한은 언제인지, 아직 지켜야 할 약속인지 알아야 한다. 그 판단의 근거가 되는 메일도 확인할 수 있어야 한다. 세컨드 브레인의 개념은 LLM이 붙은 뒤 세컨드 브레인은 어떻게 달라졌을까에서 더 자세히 다뤘다.

이 글에서는 GBrain v0.50.0.0의 공개 저장소와 문서를 바탕으로 메일 한 통이 에이전트의 행동으로 이어지는 과정을 살펴본다. 메일이 어떻게 출처를 확인할 수 있는 지식으로 정리되는지, 약속의 진행 상태는 어떻게 관리되는지, 작업을 마친 뒤에는 무엇이 기억에 남는지를 따라간다.

직접 사용한 후기가 아니라, 공개된 구현과 문서를 통해 GBrain의 구조와 역할을 분석한 글이다. 구체적인 사용 방법은 이후 AI Native GBrain 튜토리얼에서 다룰 예정이다.

평범한 메일 검색부터 생각해 보자. “제안서 이야기가 나온 메일을 찾아줘”라고 요청하면 검색 시스템은 관련 메일을 찾는다. 검색 요청이 없는 동안에는 아무 일도 하지 않아도 된다. 메일 원문과, 나중에 그 원문을 찾는 데 필요한 색인을 보관하면 된다.

반면 약속은 다시 검색하지 않아도 시간이 지나면서 상태가 달라진다. “금요일까지 제안서를 보내겠습니다”라는 약속은 금요일 전에는 준비해야 할 일이다. 금요일이 지났는데도 보내지 않았다면 기한을 넘긴 일이다. 이미 보냈다면 더는 미완료 항목으로 나타나서는 안 된다. 약속을 관리하려면 메일 원문 외에도 담당자, 상대방, 기한, 현재 상태를 따로 기록해야 하는 이유다.

GBrain은 이런 약속이나 답변을 기다리는 일을 Open Loop라고 부른다. 아직 끝나지 않아 챙겨야 하는 일이라는 뜻이다. 약속한 일, 아직 답하지 않은 메일, 상대의 결정을 기다리는 일을 각각 별도 항목으로 관리한다. Gmail을 동기화하면서 Open Loop의 상태를 다시 계산해도, 판단의 근거가 된 메일 원문은 검색 가능한 페이지로 남는다.^[1] 원문을 보면 “무슨 말을 했지?”에 답할 수 있고, 약속의 현재 상태를 보면 “지금 무엇을 해야 하지?”에 답할 수 있다. 검색 결과와 해야 할 일의 목록은 이처럼 서로 다른 역할을 한다.

그렇다고 메일 한 문장을 곧바로 할 일로 옮길 수 있는 것은 아니다. “금요일”이 정확히 어느 날짜인지는 메일을 보낸 날짜와 앞뒤 대화를 봐야 알 수 있다. 제안서를 받을 사람이 누구인지도 메일을 주고받은 사람과 대화 내용을 확인해야 한다. 이후에 약속을 취소하거나 기한을 바꾸는 답장이 왔는지도 살펴야 한다. GBrain은 이런 정보를 원문과 연결해 보관하고, 에이전트가 다음 행동을 정할 때 다시 꺼내 쓸 수 있게 한다.

이제 에이전트에게 “A사 제안서 초안을 준비해줘”라고 요청했다고 해보자. 지난 메일과 약속의 상태를 찾고, 어떤 자료를 모아 어떤 순서로 초안을 쓸지 정해야 한다. 문서 작성 도구나 메일 발송 도구도 실행해야 한다. GBrain 하나가 이 일을 모두 맡지는 않는다.

GBrain과 에이전트가 일을 나눠 맡는 방식을 이해하려면 네 가지를 구분할 필요가 있다. GBrain 내부에서는 Core가 페이지, 사실, 관계, 약속의 진행 상태를 저장하고 조회한다. Connector는 Gmail이나 Google Calendar 같은 외부 서비스에서 기록을 가져온다. 반면 Harness는 GBrain 바깥에서 에이전트가 동작하는 실행 환경이다. Hermes, OpenClaw, Claude Code, Codex가 여기에 해당한다.

Harness에서 동작하는 에이전트는 사용자와 대화하고, GBrain과 다른 도구를 사용한다. 이때 특정 일을 어떤 순서와 규칙으로 처리할지 적어 둔 지침이 Skill이다. GBrain이 제공하는 Skill도 있지만, 이를 읽고 따르는 주체는 에이전트다. 네 가지가 모두 GBrain 내부의 구성 요소인 것은 아니다.^[2]

앞의 메일에 이 구분을 적용하면 역할이 더 잘 드러난다. GBrain의 Connector가 Gmail에서 메일을 가져오면 Core가 원문을 저장하고, 메일에서 확인한 사실과 약속의 상태를 찾을 수 있게 정리한다. 제안서 작성을 요청받은 에이전트는 Harness에서 GBrain을 조회해 관련 기억을 가져온다. 이어서 필요한 Skill의 절차에 따라 문서 도구로 제안서를 작성하고, 발송 권한이 있는 메일 도구로 보낼 수 있다. 작업이 끝나면 에이전트가 결과를 GBrain에 기록하거나, 이후 동기화 과정에서 결과가 반영된다.

이 흐름은 기록을 모으고(Capture), 지식으로 정리하고(Knowledge), 필요한 내용을 판단한 뒤(Think), 작업에 사용하고(Operate), 결과를 다시 기록하는(Feedback) 다섯 단계로 볼 수 있다.

Capture → Knowledge → Think → Operate → Feedback

다섯 단계는 일이 진행되는 순서다. 이 과정은 GBrain 내부에서만 이루어지지 않고, 외부의 에이전트와 연결된 도구까지 함께 참여한다. 예를 들어 Capture 단계에서는 GBrain의 Connector가 메일을 가져오고 Core가 저장한다. Operate 단계에서는 Core가 관련 기억을 제공하고, Harness에서 동작하는 에이전트가 Skill의 절차에 따라 외부 도구를 실행한다. 이 역할을 구분하면 GBrain에 정보가 저장되어 있다는 것과 에이전트가 실제로 행동했다는 것을 혼동하지 않을 수 있다.

권한을 살펴보면 이 차이가 더 분명하다. GBrain의 Google Connector는 gmail.readonly, calendar.readonly, contacts.readonly 권한만 요청한다. Gmail, Google Calendar, Google Contacts의 내용을 읽을 수는 있지만 새 내용을 쓰지는 못한다.^[3] 따라서 GBrain이 제안서 메일을 직접 보낸다고 설명하면 틀린다. 메일을 보내려면 Harness가 별도로 발송 권한을 가진 도구를 호출해야 한다. GBrain은 행동에 필요한 기억을 제공하고, Harness와 연결된 도구가 그 행동을 실행한다.

이런 점에서 GBrain은 완성된 자율 에이전트보다는 에이전트의 장기 기억을 맡는 Brain Layer에 가깝다. 제안서를 보내기 전에는 “금요일까지 보내야 할 A사 제안서가 아직 미완료 상태다”라는 정보와 관련 자료를 제공한다. 보낸 뒤에는 실행 결과나 새 답장, 사람이 바로잡은 내용을 받아 다음 조회에 반영할 수 있다. 사용자와 대화하고 도구를 실행하는 쪽은 Harness다. 여러 작업과 대화에 걸쳐 기억을 이어 주는 쪽은 GBrain이다.

Google Connector가 Gmail의 메일 대화 묶음인 스레드를 가져오면, GBrain은 먼저 원문을 검색 가능한 페이지로 만든다. 이 상태에서도 과거 메일을 찾을 수는 있지만, 원문을 다른 저장소에 복사한 것과 큰 차이는 없다. 에이전트가 그 메일을 바탕으로 일하려면 A사가 회사라는 것, 메일을 주고받은 사람이 A사의 담당자라는 것, 제안서가 특정 프로젝트에 속한다는 것도 알아야 한다.

GBrain에서는 사람, 회사, 프로젝트처럼 따로 관리할 대상을 페이지로 구분하고 관계를 연결할 수 있다. 어떤 종류의 페이지를 만들 수 있고 어떤 관계로 연결할 수 있는지 정하는 규칙이 Schema다.^[4] A사와 제안서 프로젝트의 페이지가 별도로 정리되어 있다면, 담당자와 회사, 프로젝트를 관계로 연결해 함께 찾을 수 있다. 메일 한 통을 가져온 것만으로 회사와 프로젝트 페이지까지 자동으로 만들어진다는 뜻은 아니다.

GBrain의 Google Source가 메일에서 약속을 추출할 때는 근거가 된 문장과 원래 Gmail 스레드도 함께 연결한다.^[1] “금요일까지 제안서를 보내겠습니다”라는 문장에서 약속을 찾았다면, “제안서 발송 기한은 금요일”이라는 내용만 따로 저장하지 않는다. Open Loop와 장기 기억에 남긴 약속에서 어느 메일의 어떤 문장을 근거로 삼았는지 확인할 수 있게 한다. 날짜를 잘못 해석했거나 상대방을 잘못 연결한 것 같다면 원문으로 돌아가 확인할 수 있다.

하나의 약속에서 용도가 다른 기록이 여럿 만들어지기도 한다. Google Source의 약속 추출기는 이 문장을 내가 상대에게 지켜야 할 약속인 commitment_owed_by_me로 분류할 수 있다. 그러면 GBrain은 진행 상태를 관리할 Open Loop 항목을 만들고, 장기 기억에서 찾을 수 있도록 commitment 유형의 사실을 기록한다. 메일 스레드와 상대방 사이의 관계도 연결한다.^[1] Open Loop는 “아직 끝나지 않았나?”를, 사실 기록은 “무엇을 약속했나?”를 확인하는 데 쓰인다. 관계를 따라가면 “누구에게 한 약속인가?”를 알 수 있다. 같은 내용을 무작정 복제하는 것이 아니라, 원문과 진행 상태와 관계를 용도에 맞게 연결하는 것이다.

여러 곳에서 가져온 기록을 한 데이터베이스에 넣더라도 검색 결과가 모두 섞이지는 않는다. GBrain은 외부에서 가져온 기록 묶음을 Source로 구분한다. Source마다 페이지를 식별하는 이름인 슬러그가 서로 겹치지 않도록 공간을 나누고, 동기화 상태도 따로 관리한다. 다른 Source와 함께 검색할지도 각각 정할 수 있다. 여러 Source를 한 번에 찾는 연합 검색은 새 Source에서 기본으로 꺼져 있다.^[5] 따라서 개인 메일, 회사 자료, 에이전트 대화 기록을 같은 데이터베이스에 보관하면서도, 명시적으로 선택한 Source만 함께 검색하게 할 수 있다.

기억을 저장하는 곳도 하나가 아니다. 사람이 읽고 수정하는 지식 원본은 Brain 저장소의 Markdown 파일에 남고, Git으로 변경 이력을 관리한다. 데이터베이스에는 검색용 색인 외에도 사실, 교정, 작업, 사용량 기록이 들어간다. 그래서 GBrain 문서는 Git 저장소만 복제해서는 완전한 백업이 되지 않는다고 설명한다.^[2] 지식 원본뿐 아니라 관계와 현재 진행 상태까지 보존하려면 Markdown 파일과 데이터베이스를 함께 보관해야 한다.

약속을 정확히 저장했어도 제안서를 준비하는 에이전트가 그 약속을 보지 못하면 소용이 없다. 그렇다고 모든 메일과 기억을 매번 읽힐 수도 없다. GBrain에는 에이전트가 필요한 기억을 직접 요청하는 방법과, 최근 대화에 관련된 기억을 먼저 제안하는 방법이 있다. 직접 요청하려면 에이전트가 무엇을 찾아야 할지 알아야 한다. 먼저 제안할 때는 엉뚱한 기억을 끼워 넣지 않도록 주의해야 한다.

에이전트가 GBrain에 기억을 찾거나 저장해 달라고 요청할 때 쓰는 명령 묶음이 MEMORY_VERBS v1이다. 관련 기억을 찾는 recall, 새 기억을 저장하는 remember, 특정 대상을 조회하는 entity, 여러 근거를 종합하는 synthesize가 있다. 여기에 기억을 철회하는 forget, 작업에 필요한 정보를 묶는 context_pack, 지난 조회 이후의 변경 사항을 받는 delta를 더해 일곱 가지다.^[6]

Harness가 “A사 제안서와 관련된 기억을 찾아 달라”며 recall을 호출하면 GBrain은 관련 사실과 페이지 일부를 돌려준다. 새 작업을 시작하거나 긴 대화를 압축한 뒤에는 context_pack으로 작업에 필요한 정보를 한꺼번에 요청할 수 있다. GBrain은 관련 대상, 아직 끝나지 않은 일, 최근 사실을 정해진 입력 분량 안에 묶어 준다. 에이전트는 기억 전체를 읽는 대신 A사 담당자, 제안서 프로젝트, 미완료 약속처럼 지금 필요한 정보부터 받는다.

여러 메일과 회의 기록을 함께 읽고 결론을 내려야 할 때는 synthesize를 쓸 수 있다. 이 명령은 여러 페이지의 근거를 모아 답변과 출처, 아직 알 수 없는 부분, 비용 정보를 돌려준다. 다만 언어 모델을 호출하므로 단순 조회보다 느리고 비용도 든다. GBrain 문서는 메시지가 올 때마다 자동으로 실행되는 흐름에 이 명령을 넣지 말라고 설명한다.^[6] 여러 기록에 흩어진 제안서의 배경을 정리할 때는 유용하지만, 미완료 약속이 있는지 매번 확인하는 용도로는 부담이 크다.

에이전트가 먼저 검색해야 한다는 점도 한계가 된다. “A사 제안서 초안을 준비해줘”라는 요청을 받아도, 과거에 A사와 한 약속이 있다는 사실을 모르면 recall을 호출하지 않을 수 있다. Push Context는 이 문제를 줄이기 위한 기능이다. 최근 대화에서 이름이나 대상을 찾아 관련 페이지를 에이전트에게 먼저 제안한다.

그렇다고 단어가 비슷하다는 이유만으로 기억을 끼워 넣지는 않는다. 어느 대상을 가리키는지 모호하거나 관련 페이지의 신뢰도가 기본 기준을 넘지 못하면 아무것도 제공하지 않을 수 있다.^[7] 대화에 나온 “A사”가 어느 회사인지 충분히 확실하다면, Push Context는 기준을 통과한 A사 페이지와 짧은 요약을 돌려준다. 이 정보는 더 찾아볼 단서가 되지만, 아직 보내지 않은 제안서에 관한 약속까지 반드시 포함하는 것은 아니다.

Harness는 이 단서를 바탕으로 현재 상태를 더 확인해야 한다. entity로 A사의 정보를 모은 카드를 조회하거나, context_pack의 open_threads에 담긴 미완료 약속을 확인할 수 있다. 필요하면 recall로 관련 사실과 근거를 더 찾는다. 이름이 같은 회사가 둘이거나 대상을 확실히 구분할 수 없다면 자동 제안이 없을 수도 있으므로, Harness가 직접 조회를 시작해야 한다. Push Context는 관련 기억을 발견하도록 돕지만, 모든 대화에서 필요한 기억이나 Open Loop의 현재 상태를 빠짐없이 제공하지는 않는다.

메일에서 아직 끝나지 않은 일을 찾는 방법도 두 가지다. GBrain은 정해진 조건을 확인하는 규칙 기반 탐지기와, 문장의 의미를 읽는 언어 모델 기반 탐지기를 함께 쓴다. 둘은 찾는 신호가 달라서 어느 한쪽이 다른 쪽을 대신하지 못한다.

규칙 기반 탐지기는 언어 모델 없이 메일의 순서, 발신자와 수신자, 지난 시간을 확인한다. 그 결과에 따라 답변 대기 등의 상태를 바꾸는 방식이다. 예를 들어 상대방이 마지막으로 보낸 실질적인 메일에 24시간 동안 답하지 않았는지, 내가 질문을 보낸 뒤 상대의 답을 72시간 동안 기다리고 있는지 확인한다. 이후 해당 스레드에 답장이 오면 이 유형의 Open Loop를 삭제하는 대신 완료된 상태로 바꾼다.^[1] 메일의 의미를 해석하기보다는 주고받은 순서와 시간을 기준으로 답변 대기 상태를 관리한다.

“금요일까지 제안서를 보내겠습니다”처럼 문장에 담긴 약속을 찾을 때는 Google Source에서 기본으로 켜져 있는 언어 모델 기반 추출기를 사용할 수 있다. 누가 누구에게 무엇을 약속했는지, 기한은 언제인지, 근거가 되는 문장은 무엇인지 읽고 항목별로 정리한다. 최근 30일 메일 가운데 추출 대상에 해당하는 스레드의 텍스트 일부가 설정된 모델 제공자에게 전송된다.^[1] 운영자는 loops.extraction_enabled를 꺼서 이 기능을 비활성화할 수 있다.^[3]

약속 추출이 늘 성공하는 것은 아니다. 모델 제공자가 설정되어 있지 않거나 일시적으로 응답하지 않으면 문장의 의미를 읽을 수 없다. 운영자가 발신자나 스레드를 음소거한 경우에도 약속을 만들지 않는다. 스팸이나 홍보 메일처럼 제외 조건에 해당하는 메일도 추출 대상에서 빠진다. 그래도 Google Connector가 가져온 메일 원문은 GBrain에 들어오고, 규칙 기반 탐지기는 계속 작동한다.^[1] 모델 기반 추출을 꺼도 메일 동기화 전체가 멈추지는 않는다. 다만 규칙 기반 탐지기가 문장 속 약속까지 대신 읽어 주는 것은 아니다.

추출한 약속은 기다리는 일을 보여 주는 gbrain waiting, A사나 담당자의 정보 카드, context_pack에 나타날 수 있다. 하지만 금요일이라는 기한을 저장했다고 해서 그날 에이전트가 자동으로 실행되지는 않는다. 기한은 언제까지 해야 하는지를 나타내는 정보다. 프로그램을 언제 실행할지 정하는 예약 기능은 별도로 필요하다.

정해진 시각에 프로그램을 실행하는 일은 OpenClaw cron, Railway cron, crontab 같은 호스트 스케줄러가 맡는다. Harness가 실행된 뒤 작업이 오래 걸린다면, 중단되어도 작업을 이어 갈 수 있도록 실행 상태를 보관하는 작업 큐가 필요할 수 있다. GBrain은 이런 백그라운드 작업을 Minion이라고 부른다. Minion 작업 큐는 제출된 작업을 데이터베이스에 보관하고, 중단된 작업을 재개하며, 실행 기록을 남긴다. 스케줄러가 시작할 시각을 정한다면 Minion은 시작된 작업의 진행 상태를 관리하는 셈이다. 이 버전에서는 gbrain jobs work 안에 자체 스케줄러를 두는 기능이 아직 출시되지 않았다.^[8]

메일 예시로 돌아가면 역할이 분명해진다. Open Loop는 “금요일까지 A사에 제안서를 보내야 한다”는 미완료 상태를 유지한다. 사용자의 요청이나 호스트 스케줄러가 Harness를 실행하면, Harness는 GBrain에서 그 약속과 관련 자료를 가져온다. 이어서 문서 도구로 초안을 만들고, 발송 권한이 있는 메일 도구로 제안서를 보낸다. GBrain은 무엇을 해야 하는지 판단할 정보와 필요한 기억을 제공한다. 제안서를 쓰고 보내는 일 자체를 대신하지는 않는다.

제안서를 보냈는데도 계속 “제안서를 보내야 한다”고 알려 준다면, 기억은 일을 돕기는커녕 방해한다. Harness는 메일 도구가 돌려준 결과로 발송 여부를 확인한 뒤 약속을 완료로 표시하거나, 제안서를 보냈다는 사실을 출처와 함께 기록해야 한다. 나중에 Google Connector가 Gmail에서 읽어 온 새 메일 상태도 이를 뒷받침하는 근거가 될 수 있다.

다만 이 과정이 전부 자동으로 이루어지는 것은 아니다. 상대방이 답장을 보내면 규칙 기반 탐지기는 답변을 기다리던 스레드의 Open Loop를 닫을 수 있다. 하지만 답장 내용만으로 원래 약속한 제안서 발송까지 마쳤다고 판단하는 기능은 GBrain 문서에 향후 작업으로 남아 있다. 약속 자체는 gbrain loops done으로 닫거나 다른 경로로 완료 상태를 갱신해야 한다.^[1] 현재 구현에서는 Harness나 사람이 결과를 명시적으로 기록해야 하는 부분이 남아 있는 것이다.

사람이 내용을 바로잡을 때도 기억을 갱신해야 한다. “금요일이 아니라 다음 주 월요일이야”라고 정정했다면, 새 기한과 그 근거가 GBrain에 저장되어야 한다. 기존 사실을 새 사실로 대체하거나, forget으로 더는 유효하지 않다고 표시할 수 있다. 철회한 사실은 변경 경위를 확인할 수 있도록 감사 기록에 남지만, 이후 조회에서는 현재 유효한 사실로 쓰이지 않는다.^[6] 출처와 변경 이력이 남아 있어야 기한이 왜 월요일로 바뀌었는지 나중에 확인할 수 있다.

기억이 쌓이다 보면 같은 대상이 중복으로 등록되거나 인용이 끊기고, 서로 관련된 사실이 여러 대화에 흩어지기도 한다. GBrain은 이런 기억을 주기적으로 정리하는 과정을 Dream이라고 부른다. 설치 문서는 gbrain dream을 대상 정보 정리, 인용 수정, 기억 통합, 대화 종합, 여러 세션에 걸친 패턴 탐지를 수행하는 야간 유지보수 과정으로 설명한다.^[9] 이름이 ‘꿈’이라고 해서 에이전트가 밤새 자유롭게 생각한다는 뜻은 아니다. 호스트 스케줄러가 정해진 시각에 유지보수를 시작하면, 설정된 절차에 따라 저장된 지식의 연결과 일관성을 점검한다.

지금까지의 과정이 이어지려면 각 단계에 필요한 설정과 권한을 갖춰야 한다. Google OAuth 읽기 권한에 동의하지 않으면 Connector는 메일을 가져오지 못한다. 모델 제공자가 없거나 약속 추출을 꺼 두었다면 문장의 의미를 읽어 약속을 정리하는 기능은 작동하지 않는다. 예약한 시각에 작업을 시작하려면 호스트 스케줄러가 필요하다. 함께 검색할 Source나 비공개 기억을 보여 줄 Harness도 따로 정해야 한다. 이 모든 것을 GBrain의 기능이라고만 묶어 설명하면, 어디까지 자동으로 되고 어디서 설정이나 권한이 필요한지 놓치기 쉽다.

처음의 메일로 돌아가 보자. “금요일까지 제안서를 보내겠습니다”라는 문장이 다음 행동으로 이어지려면, 검색으로 다시 찾을 수 있는 것만으로는 부족하다. 원문을 근거로 약속을 정리하고, 상대방과 기한, 진행 상태를 관리해야 한다. Harness가 작업을 시작할 때 그 정보가 전달되어야 하고, 발송을 확인한 뒤에는 완료 상태가 다시 기억에 반영되어야 한다.

GBrain의 역할을 확인하려면 일을 하기 전과 끝낸 뒤의 기억을 비교해 보면 된다. 제안서를 준비할 때는 담당자와 기한, 미완료 약속을 찾을 수 있어야 한다. 보낸 뒤에는 완료된 것으로, 기한을 바꿨다면 새 기한으로 나타나야 한다. GBrain은 그 사이에서 원문과 출처, 관계, 진행 상태를 이어 준다. 다만 실제로 행동하고 성공 여부를 확인하는 일, 필요한 상태 갱신을 요청하는 일은 여전히 Harness와 연결된 도구가 맡는다.