Molayo

© 2026 Molayo

Dev.to헤드라인2026. 05. 28. 13:09

AI에게 SQL 데이터베이스의 영구적인 메모리를 제공하는 MCP 서버를 구축했습니다

요약

AI 클라이언트가 매 세션마다 반복적으로 학습해야 하는 데이터베이스 스키마 정보를 영구적으로 저장하고 공유할 수 있는 오픈 소스 MCP 서버 'amnesic'을 소개합니다. SQL 데이터베이스의 의미론적 정보를 로컬에 저장하여 모델의 입력 토큰 비용을 절감하고 컨텍스트를 유지합니다.

핵심 포인트

  • AI의 토큰 낭비는 추론보다 반복적인 정보 조회(lookup)에서 발생함
  • amnesic은 MCP 서버를 통해 SQL 스키마 주석을 영구적으로 관리함
  • 특정 도구에 종속되지 않는 공유 가능한 컨텍스트 레이어 구축
  • 입력 토큰 비용 절감 및 AI 모델의 데이터베이스 이해도 향상

얼마 전 저는 로컬 코딩 어시스턴트 (coding assistant)를 구축하려고 시도했습니다. Qwen3를 다운로드하여 16GB RAM을 탑재한 제 MacBook에서 실행해 보았지만, 하루 만에 출력 품질이 Claude나 GPT-5에 훨씬 못 미친다는 것을 깨달았습니다. 모델은 '구동'은 될 수 있었지만, '경쟁'할 수는 없었습니다.

그래서 저는 질문을 바꾸었습니다.

내 하드웨어에서 모델을 더 똑똑하게 만들 수 없다면, 모델에게 제공하는 정보를 더 똑똑하게 만들 수는 없을까?

토큰이 실제로 소비되는 곳

저는 Claude / Cursor / Copilot 세션에서 토큰이 실제로 어디에 쓰이는지 관찰하기 시작했습니다. 놀랍게도, 대부분은 추론 (reasoning)이 아니었습니다. 그것은 바로 **조회 (lookup)**였습니다.

우리 회사의 데이터베이스에 관한 모든 새로운 채팅은 매번 똑같은 것들을 다시 찾아내야 했습니다:

  • status = 3은 무엇을 의미하는가? (취소됨)
  • orders는 어떻게 users와 조인(join)되는가? (orders.user_id → users.id)
  • 저 암호 같은 JobStatus 열거형 (enum)은 무엇인가? (아무도 기억하지 못하는 수십 개의 정수 코드)

모델은 이를 알아냈고, 세션은 종료되었으며, 내일이면 모델은 그것을 다시 알아내야 합니다. 매번 똑같은 토큰, 똑같은 지연 시간 (latency)이 발생합니다. AI와 작업할 때 비용이 많이 드는 부분은 사고 과정이 아니라, 어제 이미 배웠던 것들을 다시 가르치는 과정이었습니다.

현재 AI의 출력 (output) 토큰을 줄이는 것(원시인처럼 말하기, 인사치레 제거 등)에 많은 관심이 쏠려 있습니다. 하지만 제 워크플로우에서 더 큰 누수는 입력 (input) 측에 있었습니다. 변하지 않는 컨텍스트 (context)를 재설정하기 위해 매 세션마다 전체 토큰 비용을 지불하고 있었던 것입니다.

"메모리"는 기능이 아니라 아키텍처의 문제입니다

AI 클라이언트들이 "메모리" 기능을 덧붙이기 시작했습니다. 하지만 그것들은 독점적이고, 불투명하며, 하나의 도구에 종속되어 있습니다. Claude의 메모리는 Cursor에 도움이 되지 않습니다. Cursor의 메모리는 Copilot에 도움이 되지 않습니다. 이를 검사할 수도 없고, 팀원과 공유할 수도 없으며, 차이점(diff)을 비교할 수도 없습니다.

제가 실제로 원했던 것은 어떠한 AI 클라이언트라도 결정론적 (deterministically)으로 읽을 수 있는 **명시적이고, 검사 가능하며, 공유 가능한 컨텍스트 레이어 (context layer)**였습니다. 즉, 매번 동일한 답변을 내놓고, 우리 팀이 서로 전달할 수 있는 동일한 파일을 갖는 것입니다.

저는 제 환경에서 다시 학습하는 비용이 가장 높은 것부터 시작하기로 했습니다: 바로 **SQL 데이터베이스 (SQL databases)**입니다.

amnesic의 등장

amnesic은 모든 AI 클라이언트에게 사용자의 SQL 데이터베이스에 대한 영구적인 의미론적 메모리 (semantic memory)를 제공하는 오픈 소스 MCP 서버입니다. 이름은 반어적입니다. 결코 건망증(amnesic)이 있지 않기 때문입니다. 이 서버는 기억합니다.

사용자(또는 AI)가 테이블이나 컬럼을 한 번 주석(annotate) 달아두면:

db_annotate(
    table="orders",
    column="status",
...

…그 정보는 로컬 SQLite 파일에 저장됩니다. 이후의 모든 db_get_schema 호출은 세션이 바뀌어도, AI 클라이언트가 바뀌어도, 영원히 해당 주석들을 응답에 다시 병합하여 포함합니다:

사용자: 이번 달에 취소된 주문이 몇 건인가요?
AI: [db_get_schema("orders") 호출]
    → status 컬럼: enum {"3": "cancelled", ...}
...

다시 설명할 필요도, 대화 턴을 낭비할 필요도 없습니다. 주석이 영구적으로 유지되었기 때문입니다.

내가 고수하고 싶은 기술적 결정들

유사한 도구를 만드는 분들이 흥미로워할 만한 몇 가지 선택 사항입니다:

벡터 DB 대신 SQLite FTS5 사용

처음에는 "결제(payments)를 처리하는 테이블을 찾아줘"와 같은 검색을 위해 ChromaDB로 시작했습니다. 그러다 결국 그것을 제거했습니다. BM25 랭킹을 지원하는 SQLite의 내장 FTS5 기능은 의존성 비용이 전혀 없이 "올바른 테이블/컬럼 찾기" 유스케이스를 해결해 줍니다. 임베딩 (embeddings), 모델 다운로드, 외부 서비스가 필요 없습니다. 가벼운 로컬 레이어(local layer)를 지향하는 도구로서, 50MB 이상의 벡터 스택을 끌어들이는 것은 잘못된 트레이드오프 (trade-off)였습니다.

db_search("payment")
# → 랭킹 결과: orders.payment_method, consumerpayments 테이블, ...
#   모두 로컬 FTS5 인덱스에서 가져온 것이며, 네트워크나 임베딩은 필요 없음

2단계 읽기 전용 (read-only) 강제 적용

amnesic은 운영 데이터베이스 (production databases)에 연결되므로, AI는 절대로 어떤 것도 변경할 수 없어야 합니다. 이를 위해 두 개의 독립적인 레이어를 두었습니다:

  1. 정적 SQL 분석 (Static SQL analysis) — SELECT / WITH가 아닌 모든 것을 거부합니다. 쓰기 키워드, SELECT ... INTO OUTFILE, 그리고 CTE (Common Table Expressions) 내부에 숨겨진 쓰기 작업 등을 잡아냅니다.
  2. 트랜잭션 롤백 (Transaction rollback) — 모든 쿼리는 즉시 롤백되는 트랜잭션 내에서 실행됩니다. 설령 쓰기 작업이 1단계 레이어를 통과하더라도, 아무것도 커밋 (commit)되지 않습니다.

이중 안전장치(Belt and suspenders)입니다. AI가 실수로라도 사용자의 테이블을 삭제(drop)할 수 없어야 합니다.

연결당 하나의 SQLite 파일

스키마 캐시 (Schema cache) + 어노테이션 (annotations) + 외래 키 (FK) 관계 그래프 + FTS5 인덱스가 데이터베이스 연결당 하나의 SQLite 파일에 모두 저장됩니다. 휴대 가능하고, 검사 가능하며, chmod 600으로 관리할 수 있습니다. 축적된 지식을 팀원에게 전달하고 싶으신가요? 파일 하나면 충분합니다.

부수적인 효과로서의 데이터 최소화 (Data minimization)

설계 과정에서 아주 좋은 특성이 파생되었습니다. 어노테이션이 잘 작성된 스키마는 AI가 데이터베이스에 쿼리를 날리지 않고도 로컬 지식 파일 (local knowledge file) 만으로 대부분의 질문에 답할 수 있음을 의미합니다. _"status=3이 무엇을 의미하나요?"_라는 질문은 어노테이션을 통해 해결됩니다. _"orders 테이블이 users 테이블과 어떻게 조인되나요?"_라는 질문은 FK 그래프를 통해 해결됩니다. 이는 혼란스러울 때마다 SELECT DISTINCT status FROM orders를 실행하는 "가공되지 않은 (naked)" SQL MCP보다 측정 가능한 수준으로 훨씬 적은 양의 행 데이터 (row data)가 기기를 벗어나게 합니다.

이것이 아닌 것

  • 모델을 더 똑똑하게 만들지 않습니다.
  • 자연어-to-SQL (natural-language-to-SQL)을 수행하지 않습니다.
  • 실행 중심의 MCP 서버를 대체하는 것이 아닙니다. 실행 중심 서버들은 쿼리 실행과 실시간 조사 (live introspection)를 잘 처리합니다. amnesic의 유일한 역할은 기존의 어떤 서버에서도 찾을 수 없었던 지속성/어노테이션 계층 (persistence/annotation layer) 을 제공하는 것입니다.

사용해 보기

pip install amnesic
amnesic init          # 대화형 설정 마법사

그 다음 AI 클라이언트의 mcp.json에 추가하고 재시작하세요. PostgreSQL, MySQL, MSSQL, 그리고 SQLite와 함께 작동합니다. MIT 라이선스이며, PyPI에 등록되어 있고, 공식 Linux Foundation MCP 레지스트리에 등록되어 있습니다.

GitHub: github.com/SurajKGoyal/amnesic

요점

모든 AI 문제에 더 똑똑한 모델이 필요한 것은 아닙니다. 때로는 결정론적이고 (deterministic), 검사 가능하며 (inspectable), 공유 가능한 (shared) 외부 컨텍스트 계층을 구축하는 것이 승리 요인이 될 수 있습니다. 이를 통해 모델이 같은 것을 두 번 배울 필요가 없게 만듭니다.

특히 읽기 전용 강제 (read-only enforcement) 부분에 대한 피드백을 환영합니다. 이 부분은 반드시 완벽해야 하기 때문입니다. 이슈 (Issues) 및 풀 리퀘스트 (PRs)를 환영합니다.

AI 자동 생성 콘텐츠

본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
1

댓글

0