# \#sqlite **URL:** https://discuss.pytorch.kr/tag/sqlite/2189.md [최신](https://discuss.pytorch.kr/latest.md) · [카테고리](https://discuss.pytorch.kr/categories.md) · [태그](https://discuss.pytorch.kr/tags.md) --- ## [Leviathan: 대용량 티켓과 로그를 grep 대신 수백 토큰의 검색 결과로 에이전트에 건네는 로컬 인덱서](https://discuss.pytorch.kr/t/leviathan-grep/12138)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [10월 10, 2026, 2:30오전 UTC](https://discuss.pytorch.kr/t/leviathan-grep/12138 "2026-10-10T02:30:10Z")
핵심 요약 Leviathan은 JSONL, CSV, SQLite 같은 레코드를 SQLite 검색 인덱스 파일 하나로 만드는 Rust 단일 바이너리입니다. 에이전트는 질문마다 순위가 매겨진 결과 카드 몇 장만 받습니다. 개발자가 공개한 합성 데이터 벤치마크(100만 건)에서 질문당 에이전트 컨텍스트에 들어간 토큰은 중앙값 436개였고, 가장 나은 grep 전략은 107,122개였습니다. 셸을 쓸 수 있는 코딩 에이전트는 CLI와 스킬 파일로 바로 쓸 수 있고, 읽기 전용 MCP 서버도 선택적으로 제공합니다. 검색은 임베딩 없는 BM25 어휘 검색이고, 한국어는 조사가 붙은 낱말을 별개 토큰으로 다루므로 데이터 전처리나 질의 표현에 신경 써야 합니다. Leviathan 소개 고객 지원 티켓, 설비 정비 기록, 장애 로그처럼 한 대상에 기록이 수천 건씩 쌓이는 데이터에 코딩 에이전트를 연결하면, 에이전트는 보통 grep으로 해당 고객이나 장비의 이력을 추출해 통째로 읽습니다. 이력이 짧을 때는 이 방법으로 충분합니다. 데이터가 커지면 한 번의 질문에 수만에서 수십만 토큰이 컨텍스트로 들어가고, 에이전트 셸이 도구 출력을 일정 길이에서 자르면 답이 담긴 레코드가 잘린 뒤쪽에 남습니다. 질문에 쓰인 낱말과 기록에 적힌 낱말이 다르거나 "완료", "조치함" 같은 형식적인 기록이 대부분을 차지하면 키워드 grep만으로는 의미 있는 레코드를 골라내기도 어렵습니다. 이번에 소개하는 Leviathan은 이런 레코드를 한 번 색인해 두고, 에이전트가 질문할 때마다 관련 레코드 몇 건만 짧은 카드로 돌려주는 로컬 검색 도구입니다. Leviathan은 원본을 매번 읽는 대신 SQLite FTS5 전문 검색(Full-Text Search) 인덱스를 미리 만들어 두는 접근을 택했습니다. 사용자는 레코드의 ID, 제목, 본문, 그룹, 날짜, 필터 필드를 매핑해 둡니다. 여기서 그룹은 고객, 장비, 호스트처럼 사람들이 이름으로 묻는 대상입니다. 그러면 에이전트는 -g acme 처… --- ## [MegaMemory: 코딩 에이전트가 세션이 끝나도 프로젝트 구조를 기억하게 만드는 MCP 서버](https://discuss.pytorch.kr/t/megamemory-mcp/11713)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [8월 25, 2026, 10:30오후 UTC](https://discuss.pytorch.kr/t/megamemory-mcp/11713 "2026-08-25T22:30:09Z")
MegaMemory 소개 코딩 에이전트를 며칠 이상 쓰다 보면 같은 작업을 반복하게 됩니다. 어제 세 시간 동안 인증 흐름을 읽고 어디를 고쳐야 하는지 파악해 두었는데, 오늘 새 세션을 열면 에이전트는 그 파일들을 처음 보는 것처럼 다시 읽습니다. 이 문제를 푸는 흔한 방향은 코드베이스를 미리 인덱싱해 두는 것이고, PyTorchKR 에도 CodeGraph나 codebase-memory-mcp처럼 코드를 그래프로 만들어 두는 도구가 소개된 적이 있습니다. 다만 함수와 파일의 호출 관계를 그린 그래프는 무엇이 무엇을 부르는지는 알려주지만, 왜 이 모듈이 이렇게 생겼는지, 지난주에 어떤 결정을 내렸는지는 담고 있지 않습니다. 이번에 소개할 MegaMemory는 그 기록을 코드 구조에서 추출하지 않고 에이전트가 직접 쓰게 하는 방향을 택한 MCP(Model Context Protocol) 서버입니다. MegaMemory에는 추상 구문 트리(AST, Abstract Syntax Tree) 파서도 정적 분석기도 없습니다. 대신 에이전트가 코드를 읽고 자기 말로 개념을 적어 두고, 다음 작업을 시작하기 전에 그 개념을 자연어로 질의합니다. 그래서 그래프에 쌓이는 노드는 함수나 클래스 같은 코드 심볼이 아니라 기능, 모듈, 패턴, 설계 결정 같은 개념(Concept) 입니다. MegaMemory는 npm 패키지로 배포되며 Node.js 18 이상을 요구합니다. 모든 기록은 프로젝트마다 하나씩 생기는 SQLite 데이터베이스인 .megamemory/knowledge.db 에 남고, 의미 검색에 쓰는 임베딩(Embedding)은 프로세스 안에서 직접 계산합니다. 첫 실행에서 약 23MB 짜리 모델을 한 번 내려받은 뒤에는 API 키도, 추가 네트워크 호출도 필요하지 않습니다. MegaMemory가 도는 세 단계 루프 MegaMemory의 사용 흐름은 이해, 작업, 갱신 세 단계로 정리됩니다. 세션을 시작할 때 에이전트가 list\_roots 를 호출해 최상위 개… --- ## [AgentFS: AI 에이전트가 생성하는 파일, 상태, 도구 호출 기록 등을 관리하기 위한 파일 시스템 (feat. Turso)](https://discuss.pytorch.kr/t/agentfs-ai-feat-turso/8427)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [12월 16, 2025, 3:30오전 UTC](https://discuss.pytorch.kr/t/agentfs-ai-feat-turso/8427 "2025-12-16T03:30:43Z")
AgentFS 소개 AgentFS는 AI 에이전트를 위해 특별히 설계된 파일 시스템이자 상태 관리 SDK입니다. Turso(SQLite 기반의 Edge DB) 팀이 개발한 이 프로젝트는 AI 에이전트가 실행되는 동안 생성하는 파일, 상태(State), 도구 호출 기록(Tool Call Logs) 등을 단 하나의 이식 가능한 데이터베이스 파일(sqlite)로 통합하여 관리할 수 있게 해줍니다. 기존의 AI 에이전트 개발 환경에서는 에이전트의 '기억(Memory)'과 '파일 조작'을 처리하기 위해 복잡한 인프라가 필요했습니다. 예를 들어, 대화 기록은 데이터베이스에, 생성된 이미지는 클라우드 스토리지에, 설정값은 별도의 키-값 저장소(Key-Value Store)에 저장해야 했습니다. 이는 에이전트의 상태를 완벽하게 복제하거나, 특정 시점으로 되돌리는(Rollback) 디버깅 작업을 어렵게 만들었습니다. AgentFS는 이러한 문제를 해결하기 위해 "모든 것을 하나의 파일에 담는다"는 접근 방식을 취합니다. POSIX 호환 파일 시스템 인터페이스, 키-값 저장소, 그리고 실행 로그를 모두 하나의 SQLite 파일 안에 저장함으로써, 개발자는 cp agent.db snapshot.db 명령 하나만으로 에이전트의 전체 상태를 스냅샷 뜨거나 다른 머신으로 이동시킬 수 있습니다. :warning: AgentFS는 현재 알파(Alpha) 단계로, 프로덕션 환경보다는 개발 및 테스트 목적으로 사용이 권장됩니다. AgentFS와 일반 파일 시스템 (OS Filesystem)을 비교하면, 일반적인 운영체제 파일 시스템(ext4, NTFS 등)은 파일 저장에는 최적화되어 있지만, 메타데이터 관리나 상태 추적 기능은 부족합니다. 반면, AgentFS는 파일 저장뿐만 아니라 에이전트의 내부 변수(Key-Value)와 행동 로그(Tool Calls)를 함께 저장하며, 모든 변경 사항이 트랜잭션으로 관리되어 데이터 무결성을 보장합니다. AgentFS와 벡터 데이터베이스… --- ## [ReRAG: 관계 기반 접근 제어(ReBAC)를 통합한 안전한 RAG 시스템](https://discuss.pytorch.kr/t/rerag-rebac-rag/7933)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [10월 11, 2025, 9:00오전 UTC](https://discuss.pytorch.kr/t/rerag-rebac-rag/7933 "2025-10-11T09:00:31Z")
ReRAG 소개 ReRAG은 Retrieval-Augmented Generation (RAG) 시스템에 관계 기반 접근 제어(ReBAC, Relationship-Based Access Control) 를 결합한 새로운 형태의 LLM 기반 데이터 접근 프레임워크입니다. 기존 RAG 시스템은 대형 언어 모델(LLM)이 외부 문서에서 정보를 검색하고 이를 응답에 활용할 수 있게 하지만, 다중 사용자 환경에서는 보안과 권한 관리 측면에서 한계가 있습니다. 예를 들어, 한 사용자가 접근할 수 없는 문서의 내용이 다른 사용자의 질문을 통해 우연히 노출될 수 있는 ‘데이터 누출’ 문제가 발생할 수 있습니다. ReRAG은 이런 문제를 Ory Keto(Google Zanzibar 기반의 오픈소스 ReBAC 시스템)와 Ollama(로컬에서 실행 가능한 LLM 플랫폼)를 활용해 해결합니다. 즉, 단순히 문서를 검색해 LLM에게 넘기기 전에 사용자 권한을 검증하고 필터링하는 계층을 삽입함으로써, LLM이 오직 접근이 허용된 데이터만을 학습 맥락(Context)에 포함하도록 설계되어 있습니다. ReRAG 프로젝트는 단순한 예시나 데모 수준이 아니라, 실제 기업 환경에서도 RAG 시스템의 보안성을 강화할 수 있는 ‘권한 인식(permission-aware)’ RAG 아키텍처의 표준 레퍼런스 구현체입니다. 기존 RAG 시스템은 사용자 요청에 맞는 문서를 검색하고, 그 결과를 LLM 프롬프트에 삽입하여 응답을 생성합니다. 문제는 이 과정에서 모든 검색 결과가 단일 사용자 권한을 고려하지 않은 채 전달된다는 점입니다. 예를 들어, “환불 금액이 얼마였나?”라는 질문에 대해, 한 사용자는 자신이 접근할 수 없는 다른 고객의 데이터까지 응답으로 받을 수 있습니다. ReRAG은 이 구조를 다음과 같이 변경합니다: 사용자가 요청을 보낼 때, 시스템은 Ory Keto를 통해 사용자의 권한을 검증합니다. 검색 단계에서 sqlite-vec을 이용해 빠른 벡터 검색을 수행하되,… --- ## [Vectorlite: SQLite용 Vector 검색 확장 (feat. HNSW)](https://discuss.pytorch.kr/t/vectorlite-sqlite-vector-feat-hnsw/4824)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [7월 14, 2024, 10:24오전 UTC](https://discuss.pytorch.kr/t/vectorlite-sqlite-vector-feat-hnsw/4824 "2024-07-14T10:24:38Z")
Vectorlite 소개 Vectorlite(벡터라이트)는 SQLite에 빠른 벡터 검색 기능을 추가하는 확장 기능입니다. Vectorlite는 근사 K-NN 알고리즘(ANN, Approximate Nearest Neighbor) 중 하나인 HNSW(Hierarchical Navigable Small World)의 C++ 구현체인 hnswlib를 기반으로 하고 있으며, SQLite에서 실행 시간 중에 불러올 수 있는(Runtime-loadable) 확장(extension)입니다. Vectorlite는 또한, Windows, MacOS, Linux에서 모두 사용할 수 있습니다. SQLite는 경량 데이터베이스로 널리 사용되지만, 대규모 벡터 데이터를 다루는 데는 한계가 있었습니다. 벡터라이트는 이러한 한계를 극복하기 위해 설계되었으며, SIMD(Single Instruction Multiple Data) 가속을 통한 빠른 벡터 거리 계산을 제공합니다. Vectorlite는 hnswlib의 고성능에 기반하여 유사한 기능을 제공하는 다른 도구들과 비교했을 때 검색 속도와 삽입 속도에서 월등한 성능을 보여줍니다. 예를 들어, SQLite-vss와 비교하면 벡터라이트는 삽입 속도에서 10배, 검색 속도에서 2배에서 40배까지 빠른 성능을 제공합니다. 주요 특징 빠른 ANN 검색: hnswlib를 사용하여 고속 벡터 검색을 지원합니다. 다양한 플랫폼 지원: Windows, Linux, MacOS에서 사용 가능. SIMD 가속: x86 플랫폼에서 SIMD 가속을 통한 빠른 벡터 거리 계산. 다양한 거리 측정 지원: l2, cosine, ip 거리 측정 지원. HNSW 매개변수 제어: 성능 튜닝을 위한 HNSW 매개변수 완전 제어. 메타데이터 필터: SQLite 버전 3.38 이상에서 메타데이터 필터링 지원. 인덱스 저장 및 로드: 벡터 인덱스를 파일로 저장하고 로드 가능. JSON 직렬화/역직렬화 지원: vector\_from\_… --- ## [\[GN\] RustGPT🦀✨ - Rust+Htmx+SQLite로 만든 ChatGPT UI](https://discuss.pytorch.kr/t/gn-rustgpt-rust-htmx-sqlite-chatgpt-ui/2937)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [11월 26, 2023, 11:03오후 UTC](https://discuss.pytorch.kr/t/gn-rustgpt-rust-htmx-sqlite-chatgpt-ui/2937 "2023-11-26T23:03:47Z")
GeekNews의 xguru님께 허락을 받고 GN에 올라온 글들 중에 AI 관련된 소식들을 공유하고 있습니다. :smiley\_cat: 소개 OpenAI의 ChatGPT 인터페이스를 Rust 와 Axum 프레임워크 및 Htmx 로 구현한 오픈소스 sqlx: 직접적이고 타입-세이프한 SQL 쿼리 /및 마이그레이션 (Direct and type-safe SQL queries and migrations) tera: Jinja2로부터 영감을 받아 만든 HTML 렌더링을 위한 템플릿 엔진 (A templating engine inspired by Jinja2, for rendering the HTML views.) axum: 사용하기 쉽고 매우 빠른 웹 애플리케이션 프레임워크 (A web application framework that's easy to use and incredibly fast.) Server Sent Events (SSE) 를 이용한 실시간 스트리밍으로 ChatGPT 의 인터랙션 부분을 구현 원문 RustGPT 홈페이지 https://rustgpt.bitswired.com/ GitHub 저장소 개발 후기 : 블로그 https://www.bitswired.com/en/blog/post/rustgpt-journey-rust-htmx-web-dev 출처 / GeekNews