AI에게 기억을 붙이는 법: 임베딩과 GBrain으로 푸는 기억 문제

먼저, 왜 필요한가

LLM(대규모 언어 모델, 질문을 받아 문장으로 답하는 AI)에는 두 가지 한계가 있습니다. 대화가 끝나면 잊는다는 것과, 우리 회사가 실제로 일하는 방식을 모른다는 것입니다. GBrain은 이 둘을 한꺼번에 메웁니다.

LLM과 어제 나눈 이야기는 오늘 새 세션(대화 한 묶음)에 없습니다. 지난주 회의에서 정한 결정, 지난달 정한 업무 규칙도 마찬가지입니다. 모델이 모자라서가 아니라, 대화 창(컨텍스트)이 세션과 함께 사라지는 구조이기 때문입니다.

LLM이 배운 지식은 인터넷에 공개된 자료이지, 우리 회사의 업무가 아닙니다. 어떤 고객은 왜 예외로 처리하는지, 같은 말을 부서마다 다르게 쓰는 이유, 규정에는 없지만 다들 지키는 순서 같은 것입니다. 이런 것은 자료를 넣어 준다고 해결되지 않습니다. 애초에 어느 파일에도 정리돼 있지 않고 사람 머릿속에 있기 때문입니다.

규칙 문서로는 안 되는 것

지침 파일(CLAUDE.md 같은 규칙 문서)이나 시스템 프롬프트(AI에게 미리 주는 지시문)에 적어 두는 방법도 있습니다. 하지만 거기에는 글로 또렷하게 쓸 수 있는 것만 들어갑니다. 애매한 판단 기준, 예외의 예외, 설명하려면 사례를 열 개는 들어야 하는 감각은 규칙 한 줄로 정의하기 어렵습니다.

GBrain은 이런 것을 규칙으로 정리해 두라고 요구하지 않습니다. 회의 기록, 결정과 그 이유, 대화 중에 나온 사실을 그때그때 그대로 쌓아 두면 되고, 질문이 오면 그중 가까운 사례가 함께 건네집니다. 모델을 다시 학습시키는 것은 아니지만, 쓰면 쓸수록 회사 사정을 아는 것처럼 답하게 되는 효과는 같습니다.

방법은 하나입니다. AI 바깥에 문서와 기록을 쌓아 두고, 질문이 들어올 때마다 관련 있는 것을 찾아 AI에게 같이 건넵니다. 업계에서는 이 방식을 RAG(검색 증강 생성)라 부르고, GBrain은 그중 "바깥에 쌓아 두고 찾아 주는" 쪽을 맡는 제품입니다.

구성요소: 누가 무엇을 하는가

헷갈리는 이유는 "AI가 기억한다"는 한 문장 뒤에 하는 일이 전혀 다른 부품 여럿이 숨어 있기 때문입니다. 하나씩 떼어 놓으면 관계가 보입니다.

문장을 만드는 것은 클라우드(제공사의 서버)의 LLM 하나뿐입니다. 내 컴퓨터 안의 셋(GBrain, 데이터베이스, bge-m3)은 문장을 만들지 않습니다. 찾고, 저장하고, 좌표로 바꿀 뿐입니다. 그림의 실선은 요청, 점선은 결과가 돌아오는 방향입니다.

표에 나온 말을 풀면 이렇습니다. CLI는 명령어를 입력해 쓰는 프로그램이고, MCP(Model Context Protocol)는 AI가 바깥 프로그램을 불러 쓰는 연결 규격입니다. Ollama는 AI 모델을 내 컴퓨터에서 실행해 주는 프로그램이고, 리포(repository, 저장소)는 파일과 그 변경 기록을 함께 담는 폴더입니다. 임베딩은 바로 다음 절에서 설명합니다.

임베딩: 문장을 좌표로 바꾸는 일

"비슷한 문서를 찾는다"는 말이 실제로 무슨 뜻인지가 GBrain의 핵심입니다. 문장을 지도 위의 점으로 바꾸는 것입니다. 이 일을 임베딩(embedding)이라고 합니다.

컴퓨터는 두 문장이 "비슷한지"를 직접 판단하지 못합니다. 하지만 두 점이 가까운지는 계산할 수 있습니다. 그래서 임베딩 모델(bge-m3)은 문장 하나를 받아 숫자 1,024개를 내놓습니다. 이 숫자 묶음이 그 문장의 좌표입니다. 뜻이 비슷한 문장은 가까운 좌표를, 다른 문장은 먼 좌표를 받도록 훈련돼 있습니다. "환불 처리 절차"와 "결제 취소 규정"은 단어가 하나도 겹치지 않아도 가까이 찍힙니다.

요점은 둘입니다. 문서 조각은 미리 점으로 찍혀 있고, 질문은 물어보는 순간 같은 방식으로 점이 되어 가까운 이웃을 찾습니다. 실제 공간은 축이 1,024개이고, 그림은 이를 평면으로 눌러 그린 개념도입니다.

두 번의 흐름: 넣을 때와 찾을 때

넣을 때는 문서를 좌표로 바꿔 쌓아 둡니다.

1. 마크다운 리포에서 커밋된(변경이 기록으로 남은) 파일을 읽습니다(gbrain sync).
2. 한 문서를 문단 단위 조각으로 자릅니다.
3. 조각마다 bge-m3에 보내 좌표(숫자 1,024개)를 받습니다.
4. 조각 원문, 좌표, 어느 문서의 몇 번째인지를 PGLite에 저장합니다.
5. 문서 속 [[다른문서]] 참조로 링크 그래프(문서끼리 이어진 관계)도 함께 만듭니다.

찾을 때는 질문도 좌표로 바꿔 이웃을 찾습니다.

1. LLM이 MCP로 GBrain에 질문 문장을 넘깁니다.
2. GBrain이 그 문장을 같은 bge-m3에 보내 좌표를 받습니다.
3. PGLite에서 그 좌표와 가장 가까운 조각들을 찾습니다(키워드 일치도 함께 봅니다).
4. 찾은 조각 원문을 출처 페이지 이름과 함께 LLM에게 돌려줍니다.
5. LLM이 그 조각들을 읽고 문장으로 답합니다.

LLM과 임베딩 모델은 하는 일이 다르다

"AI 모델"이라는 한 단어 아래에 하는 일이 전혀 다른 두 종류가 있습니다. Ollama 같은 실행기는 모델을 돌려 주는 플레이어일 뿐이라, 어떤 모델 파일을 넣느냐에 따라 둘 중 하나가 됩니다. bge-m3는 임베딩 모델이지 LLM이 아닙니다.

비유하자면 임베딩 모델은 도서관 사서입니다. 어떤 책이 어디 꽂혀야 하는지, 어떤 책들이 서로 가까운 주제인지는 정확히 알지만, 책의 내용을 요약해 들려주지는 못합니다. 그 일은 책을 받아 읽고 말해 주는 LLM이 합니다. GBrain은 사서를 고용해 서가를 정리해 두고, 질문이 오면 사서가 뽑아 준 책 몇 권을 LLM에게 건네는 시스템입니다.

혼동하기 쉬운 내용들

GBrain이 AI인가

아닙니다. GBrain은 프로그램입니다. 문서를 자르고, 좌표 계산은 임베딩 모델에 맡기고, 결과를 DB에 넣고, 질문이 오면 찾아 주는 배관입니다. AI 모델은 바깥에 둘 있습니다. 좌표를 계산하는 임베딩 모델과 답을 쓰는 LLM입니다.

AI는 원래 기억하지 않나, 왜 GBrain이 따로 필요한가

LLM이 "기억"하는 것은 지금 열려 있는 대화 창의 내용뿐입니다. 창을 닫으면 사라지고, 창이 길어지면 앞부분부터 밀려납니다. GBrain은 대화 바깥에 문서를 쌓아 두고 필요한 부분만 그때그때 창 안으로 넣어 주는 장치라, 세션이 바뀌어도, 문서가 수천 개여도 동작합니다.

데이터베이스에는 정확히 무엇이 들어 있나

문서를 자른 조각의 원문, 조각별 좌표(숫자 1,024개), 조각이 어느 문서의 어디인지, 문서 간 링크, 태그, 타임라인입니다. 원본 마크다운은 리포에 그대로 있고 DB는 검색용 복사본입니다. DB를 지워도 리포에서 다시 만들 수 있습니다.

임베딩 모델이 로컬이면 검색은 인터넷 없이도 되나

됩니다. 넣기와 찾기 양쪽 다 내 컴퓨터 안에서 끝나고 비용도 없습니다. 인터넷이 필요한 것은 찾은 조각을 읽고 답을 쓰는 LLM 쪽입니다.

GBrain 기능 중 LLM이 있어야 가능한 것은 무엇인가

GBrain이 스스로 LLM을 불러야 하는 기능들입니다. 여러 문서를 읽고 인용 달린 답을 합성하는 think, 밤사이 문서를 읽고 사실을 뽑아 정리하는 dream, 질문을 여러 표현으로 늘려 검색하는 질의 확장이 여기에 해당합니다. 채팅 서비스 구독은 사람이 대화하는 권한이지, GBrain 프로그램이 LLM API(프로그램이 서비스를 불러 쓰는 통로)를 부를 권한이 아니어서 키를 따로 넣어야 합니다.

참고 자료

• GBrain 저장소 (GitHub)
• GBrain README
• GBrain 엔진 문서 (PGLite·PostgreSQL)
• GBrain 검색 모드 안내
• GBrain 기억 동사 프로토콜 (remember·recall·forget)
• GBrain 임베딩 제공자 안내 (Ollama 포함)
• bge-m3 모델 카드 (BAAI, Hugging Face)
• Ollama 모델 라이브러리의 bge-m3
• PGLite (ElectricSQL)
• Model Context Protocol 공식 문서
• RAG 원 논문: Lewis et al., 2020