같은 문제를 푼 두 설계 — 남이 만든 에이전트 기억과 내가 만든 지식 금고 검색

▶ 동영상 개요 — 같은 문제를 푼 두 설계 — 남이 만든 에이전트 기억과 내가 만든 지식 금고 검색

8분 34초 — 다섯 축 비교와 '밤에 무엇을 하는가'라는 갈림길을 따라간다 — NotebookLM 동영상 개요로 생성

🎧 오디오 개요 — 두 진행자가 견주는 두 기억 설계

15분 19초 — 다섯 축의 차이와 '밤에 무엇을 하는가'라는 갈림길을 대화로 풀어낸다. 화면은 이 글의 인포그래픽 한 장 고정 — NotebookLM 오디오 개요로 생성

몇 달 전부터 개인 문서 더미를 검색하는 시스템을 직접 만들어 쓰고 있다. 마크다운 문서 3,251장을 잘게 쪼개 벡터로 바꿔 넣었고, 지금 검색 대상 조각이 17,060개다. 에이전트가 뭘 물어보면 여기서 답을 찾아 온다.

그런데 4월에 공개된 gbrain을 뜯어보다가 좀 이상한 기분이 들었다. 같은 문제를 풀고 있는데 설계가 꽤 다르다. 남의 답안지를 보는 셈이라 흥미롭기도 했고, 몇 군데는 "아, 저건 내가 안 한 건데" 싶었다. 두 설계를 같은 축 위에 올려 비교해 봤다. 갈아타려는 게 아니라 내가 무엇을 안 하고 있는지를 알기 위해서다.

내 쪽 구조

▲ 직접 만든 지식 금고 검색 흐름

다이어그램 설명. 문서가 검색 가능한 조각이 되어 질문에 답하기까지의 경로다. 눈여겨볼 대목은 조각을 자를 때 앞뒤 맥락을 덧붙인다는 단계다. 문서를 그냥 자르면 "그 방식은 실패했다" 같은 조각이 무엇에 대한 얘기인지 알 수 없게 되는데, 조각마다 원문의 맥락 한 줄을 붙여 두면 그 조각만 뽑혀 나와도 뜻이 산다. 뒤쪽 두 단계는 순위를 손보는 자리다. 오래된 문서를 뒤로 밀고, 마지막에 언어 모델이 질문과 조각을 함께 읽어 순서를 다시 매긴다. 벡터 유사도만으로는 "비슷해 보이지만 답이 아닌 것"이 상위에 올라오기 때문이다. 전체적으로 이 구조는 한 가지 일을 잘하도록 설계됐다. 질문과 의미가 가까운 문서 조각을 찾아 오는 일이다.

gbrain 쪽 구조

▲ gbrain의 흐름

다이어그램 설명. 같은 출발점에서 시작하지만 두 군데가 갈린다. 첫째, 저장할 때 관계를 함께 뽑아 그래프로 남긴다. 링크 표기를 기계적으로 읽는 방식이라 언어 모델을 부르지 않는다. 둘째, 마지막 단계가 조각을 돌려주는 것으로 끝나지 않는다. 출처를 달아 문장으로 답을 만들고, 답할 수 없는 부분이 무엇인지까지 함께 밝힌다. 예를 들어 "그 사람과 마지막으로 나눈 대화가 6주 전이고, 그 이후 기록이 없으니 이 시스템이 못 보는 경로로 소식이 오갔을 수 있다"는 식의 단서를 붙인다. 이 마지막 단계가 왜 중요한가? 검색 결과 목록을 받으면 사람이 "여기 답이 없네"를 직접 판단해야 하는데, 없다는 사실을 시스템이 먼저 말해 주면 그 판단 비용이 사라진다. 다만 이 단계는 언어 모델을 쓰므로 앞의 그래프 구축과 달리 비용과 비결정성이 여기서 다시 들어온다는 점은 짚어 둬야겠다.

다섯 축으로 갈라 보기

축	직접 만든 쪽	gbrain
저장 단위	문서 조각	페이지와 개체
관계 표현	없음 — 의미 유사도만	종류가 붙은 그래프 엣지
검색 방식	벡터 검색 후 재정렬	벡터와 키워드를 합치고 그래프를 얹음
결과 형태	조각 목록	출처를 단 답과 빈틈 안내
밤에 하는 일	바뀐 문서를 다시 색인	중복 정리, 인용 교정, 모순 탐색

이 표에서 내게 가장 뼈아픈 칸은 마지막 줄이다. 나머지 차이는 설계 취향이나 규모의 문제로 볼 여지가 있는데, 저 칸은 성격이 다르다.

밤에 무엇을 하는가가 갈림길이었다

내 시스템도 밤마다 돈다. 그런데 하는 일은 바뀐 문서를 다시 색인하는 것뿐이다. 낮에 내가 문서를 고쳤으니 그 변경을 반영한다. 어제와 오늘의 차이를 따라잡는 작업이다.

gbrain의 야간 작업은 성격이 다르다. 같은 사람을 가리키는 페이지가 둘로 갈려 있으면 합치고, 깨진 출처 표기를 고치고, 어떤 기록이 중요한지 점수를 매기고, 서로 모순되는 기록을 찾아낸다. 여기에 66개의 자동 작업이 돌고 있다고 밝히고 있다.

차이를 한 문장으로 줄이면 이렇다. 내 시스템은 따라잡고, 저쪽은 좋아진다. 내 쪽은 아무리 오래 돌려도 문서 더미의 품질 자체는 그대로다. 문서에 오류가 있으면 그 오류를 충실하게 색인할 뿐이다. 저쪽은 시간이 갈수록 기록이 정리된다.

모순 탐색은 특히 부럽다. 개인 기록이 몇 년 쌓이면 반드시 생기는 문제가 옛 사실과 현재 사실이 같은 무게로 검색되는 것이다. 작년에 "그 방식으로 가기로 했다"고 적어 뒀고 올해 뒤집었는데, 검색은 둘 다 똑같이 꺼내 온다. 어느 쪽이 지금 유효한지 시스템은 모른다. 지금은 내가 매번 날짜를 보고 판단하고 있다.

그래도 갈아타지 않기로 한 이유

비교해 놓고 보니 저쪽이 여러 축에서 앞선다. 그런데 갈아타지 않기로 했다. 이유가 셋이다.

첫째, 내 문서에는 링크가 거의 없다. 앞서 본 것처럼 gbrain의 그래프는 사람이 링크를 걸어 준 만큼만 생긴다. 내 문서 3,251장 중 인물이나 프로젝트를 링크로 걸어 둔 것은 극히 일부다. 지금 옮기면 그래프가 사실상 비어 있는 상태로 시작한다. 이 시스템에 대한 리뷰들이 공통으로 지적하는 빈 브레인 문제를 그대로 맞게 된다.

둘째, 규모가 다르다. 저쪽이 자랑하는 규모는 14만 6천 페이지다. 내 쪽은 3천 장이다. 14만 장 규모에서 필요한 장치가 3천 장 규모에서도 필요하다는 보장은 없다. 사람 페이지 중복 제거 같은 것은 인물 정보가 2만 4천 건 쌓였을 때 절실한 문제지, 내 규모에서는 눈으로 봐도 된다.

셋째, 이 시스템은 아직 초기 버전이고 스스로도 미해결 과제를 여럿 밝히고 있다. 시간이 지난 정보를 어떻게 낮출지, 모순을 발견한 다음 무엇을 지울지, 모를 때 모른다고 말하게 하는 문제 같은 것들이다. 공교롭게도 내가 가장 탐냈던 기능들이 그쪽에서도 아직 안 풀린 영역이었다.

대신 두 가지를 가져오기로 했다

갈아타지 않는 대신 훔쳐 올 것을 정했다. 도구를 통째로 바꾸는 것보다 이 편이 남는 장사다.

하나는 새 문서부터 링크를 거는 습관이다. 지금 있는 3천 장을 소급해서 손보는 건 비현실적이지만, 앞으로 쓰는 문서에 인물과 프로젝트를 링크로 걸어 두는 것은 비용이 거의 없다. 이걸 반년쯤 쌓아 두면 그때 그래프를 얹을지 다시 판단할 근거가 생긴다. 그래프를 나중에 얹을 수는 있어도, 안 걸어 둔 링크를 나중에 만들 수는 없다.

다른 하나는 야간 작업의 역할을 바꾸는 것이다. 지금은 재색인만 하는데, 여기에 정비 작업을 하나만 얹어 보려고 한다. 후보는 모순 탐색이다. 같은 주제를 다루면서 결론이 반대인 문서 쌍을 찾아 목록으로 내놓는 정도라면, 지금 있는 검색 기능만으로도 만들 수 있다. 자동으로 고치게 하지는 않을 생각이다. 찾아서 보여 주는 것과 알아서 고치는 것 사이에는 신뢰의 간극이 크다.

정리 — 남의 설계는 답이 아니라 내 빈칸을 비추는 거울이다

두 시스템을 나란히 놓고 얻은 결론은 어느 쪽이 낫다는 게 아니었다. 내 시스템이 검색은 하는데 정비는 안 한다는 사실이 선명해진 것이 소득이다. 이건 저쪽과 비교하기 전까지는 결함으로 인식조차 안 되던 부분이다. 잘 도는 시스템의 빈칸은 원래 잘 안 보인다.

비슷한 것을 직접 만들어 쓰고 있다면, 같은 문제를 푸는 남의 구현을 한 번쯤 같은 축에 올려 보길 권한다. 갈아타기 위해서가 아니라 내가 안 하고 있는 일에 이름을 붙이기 위해서다. 이름이 붙으면 그때부터 할지 말지를 고를 수 있게 된다.

---

참고한 공개 자료:

• gbrain 저장소와 설명 문서 — https://github.com/garrytan/gbrain/blob/master/README.md
• GBrain 리뷰 (Gamgee) — https://gamgee.ai/blogs/garry-tan-gbrain-ai-memory-system/
• What Is GBrain? (Vectorize) — https://vectorize.io/articles/what-is-gbrain
• 평면 파일에서 gbrain으로 옮긴 실전 기록 — https://www.mager.co/blog/2026-05-18-gbrain-garry-tan-ai-memory

---

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.