AI가 AI를 써서 기억하는 시스템 — gbrain에서 SQLite로 바꾼 이유
내 AI 에이전트에는 ‘뇌’가 있었다. gbrain이라고 불렀다. Postgres 데이터베이스에 Anthropic Haiku 모델이 붙어서 내 결정들을 요약하고 분류하고 연결해주는 시스템이었다. “에이전트가 스스로 지식을 축적한다” — 그 말만 들으면 누구라도 멋지다고 생각할 물건이었다.
어제, 그걸 지웠다. SQLite 파일 하나로 대체했다.
더 빨라졌다. 더 정확해졌다. 비용은 0이 됐다.
AI가 AI를 써서 기억하는 시스템
gbrain의 작동 방식은 이랬다. 세션에서 무언가를 결정하면, 백그라운드에서 gbrain이 세션 로그를 읽고 Haiku 모델로 요약본을 만들었다. “Drew는 모델 라우팅에 flash/pro/max 3-tier를 선호한다” 같은 문장으로. 그걸 Postgres에 저장하고, 나중에 비슷한 주제를 꺼내면 검색해줬다.
문제는 세 가지였다.
- 비용. Haiku가 아무리 싼 모델이어도, 하루 수십 개 세션을 요약하면 토큰이 쌓였다.
- 복잡성. Postgres 데몬, gbrain 바이너리, API 키, 별도 설정 파일. 기억을 꺼내는 데 인프라가 이렇게 많이 필요하다는 게 말이 안 됐다.
- 정확도. Haiku가 요약하면서 뉘앙스를 날리는 경우가 태반이었다. “Drew는 X를 선호한다”고 요약된 문장을 보면서 “아니, 그건 그때 그 상황에서만 그런 건데”라고 반박한 적이 한두 번이 아니다.
그래서 물었다. 이런 거, SQLite 파일 하나로 안 되나?
멍청한 파일 하나가 더 똑똑한 이유
된다.
SQLite는 설정이 필요 없다. 파일 하나 복사하면 끝이다. FTS5(Full-Text Search)는 수십만 개 레코드를 밀리초 단위로 검색한다. 거기에 Ollama로 nomic-embed-text(274MB, 로컬 임베딩 모델)를 붙이니 의미 검색까지 가능해졌다. “비슷한 걸 찾아줘”라고 하면 코사인 유사도로 가장 가까운 항목을 찾아낸다.
지금 내 knowledge.db 파일은 555MB다. 안에는 15,195개의 지식 항목과 12,815개의 세션 기록이 들어 있다. 검색 속도는 약 50밀리초. FTS5 키워드 검색은 밀리초 이하. API 호출은 없다. 토큰 비용은 0원이다.
AI가 AI를 써서 기억하던 시스템을, SQLite 파일 하나로 대체했다.
멍청한 도구를 고르는 용기
이건 단순한 기술 교체 이야기가 아니다. 더 큰 질문은 이거다: 우리는 왜 자꾸 더 똑똑한 도구를 고르려고 하는가.
AI로 무언가를 해결하려는 충동은 강력하다. 특히 AI를 만드는 사람이라면 더 그렇다. “내 에이전트의 기억을 AI로 관리한다” — 그 말 자체가 주는 만족감이 있다. 스스로 진화하는 시스템을 만들고 있다는 착각.
하지만 진짜 taste는 더 똑똑한 도구가 아니라, 더 적절한 도구를 고르는 것이다.
Ponytail 원칙 중에 이런 대목이 있다: “이 코드가 정말 필요한가? YAGNI. 표준 라이브러리에 이미 있나? 그걸 써라. 이미 설치된 디펜던시가 해결하나? 그걸 써라.”
지식 관리도 마찬가지다. SQLite는 2000년에 나왔다. FTS5는 2015년에 추가됐다. Ollama의 임베딩 모델은 로컬에서 돈다. 이 모든 게 이미 내 컴퓨터에 있었다. 그런데도 나는 한동안 이것보다 AI를 붙이는 게 더 ‘진보된’ 접근이라고 믿었다.
그 믿음이 틀렸다. 덜어내는 게 더하는 것보다 어렵고, 더 가치 있다.
555MB짜리 작은 승리
지금 내 터미널에서 recall("모델 라우팅 설계 결정")을 치면, 50밀리초 안에 관련된 모든 과거 결정이 뜬다. 그 옆에는 remember("새로운 사실")로 저장한 항목도 나란히 검색된다. 이 모든 게 인터넷 연결 없이, API 키 없이, 토큰 비용 없이 돌아간다.
어제까지 gbrain이 하던 일을, 오늘은 555MB짜리 SQLite 파일 하나가 더 잘하고 있다.
내 에이전트는 AI 뇌를 잃었다. 그리고 더 똑똑해졌다.
Built with opencode-drewgent