한 문장으로 이 프로젝트가 뭘 하는지부터.
codebase-memory-mcp = "AI 코딩 비서를 위한, 코드베이스 한 채의 색인(index) + 지도(map)." AI에게 "이 프로젝트에서 login() 함수를 누가 호출하는지 찾아줘"라고 하면, 보통은 에이전트가 파일을 하나하나 열어 읽으며(grep) 뒤진다. 큰 프로젝트일수록 이 방식은 느리고, 무엇보다 AI가 읽은 모든 글자가 토큰(요금·문맥 한도)으로 쌓여 비싸진다. 이 도구는 저장소를 미리 한 번 통째로 분석해 "어떤 함수가 어디 정의되고, 누가 호출하고, 어떤 API를 부르는지"를 그래프(점과 선의 지도)로 만들어 둔다. 그다음부터 AI는 파일을 읽는 대신 이 지도에 질문만 던지면 된다.
누가 "이 주제를 다룬 책이 어디 있죠?"라고 물을 때마다 사서가 모든 책을 첫 장부터 다시 읽는다면 — 정확하긴 해도 느리고, 인건비(=토큰)가 폭발한다. AI 코딩 에이전트가 코드를 grep으로 매번 훑는 게 딱 이 모습이다.
codebase-memory-mcp는 사서가 딱 한 번 카드 목록·상호참조 색인을 만들어 두는 일을 한다. 이후엔 "이 함수의 호출자 5곳", "이 API를 부르는 서비스" 같은 질문에 책장을 다시 뒤지지 않고 색인 카드만 보고 즉답한다. 그게 이 프로젝트가 광고하는 "질의 1ms 미만, 토큰 99% 절감"의 정체다.
마지막으로 가장 의외의 사실 하나. 요즘 이런 'AI 인프라' 도구는 보통 Rust나 Go, Python으로 짠다. 그런데 이 프로젝트는 처음부터 끝까지 순수 C(C11 표준)로 작성됐고, 외부 라이브러리는 전부 소스에 포함(vendoring)해 컴파일한다. 결과물은 설치할 게 하나도 없는 단일 실행 파일(single static binary) 하나다. 다운로드 → 실행. 끝.
TrendShift 일간 14위 — 2026년 신생 레포가 빠르게 떠오른 이유.
2025~2026년은 "모두가 AI 코딩 에이전트를 쓰는" 시대다. 그러자 곧바로 한계가 드러났다 — 에이전트가 코드를 이해하려고 파일을 마구 읽으면 문맥 창(context window)이 금세 꽉 차고 요금이 치솟는다. "AI가 코드베이스를 효율적으로 '기억'하게 하는 법"이 핵심 과제가 됐고, codebase-memory-mcp는 그 지점을 정확히 때린다. 떠오른 이유를 다섯 가지로 정리하면:
README가 내세우는 수치가 강렬하다 — 구조적 질문 5개를 던질 때 이 도구로는 약 3,400 토큰이면 되는데, 파일을 일일이 grep·읽기로 하면 약 412,000 토큰이 든다(약 120배, 99.2% 절감). 토큰은 곧 돈이자 속도라, 에이전트를 매일 쓰는 사람에게 이 차이는 체감이 크다.
벤치마크(애플 M3 Pro 기준)에 따르면 리눅스 커널(약 2,800만 줄, 7만 5천 파일)을 통째로 색인하는 데 3분, 그렇게 만든 그래프는 노드 480만·엣지 770만 개. 그리고 질의(Cypher) 응답은 1밀리초 미만. 평범한 저장소는 색인이 수 초 안에 끝난다. C로 짜고 메모리 위에서 돌리는 설계의 힘이다.
인터넷도, OpenAI 키도, Ollama 같은 별도 모델 서버도 필요 없다. 의미 검색(semantic search)에 쓰는 임베딩 벡터조차 31MB짜리 데이터 덩어리를 바이너리에 박아 두어, 네트워크 없이 동작한다. 회사 코드가 밖으로 새지 않으니 보안 측면에서도 안심이다.
이 도구 안에는 LLM이 없다. 일부러 빼놓은 것이다. 구조적 사실(누가 누구를 부른다)은 그래프가 정확히 알려주고, 그걸 해석하고 판단하는 일은 연결된 에이전트가 한다. "도구는 정확한 사실만, 추론은 모델이"라는 깔끔한 분업이다.
curl -fsSL .../install.sh | bash 한 줄이면, 설치 스크립트가 컴퓨터에 깔린 Claude Code·Codex·Cursor·Gemini CLI 등 11개 코딩 에이전트를 감지해 MCP 설정까지 자동으로 써 준다. 사용자는 "이 프로젝트 색인해줘" 한마디만 하면 된다.
| 접근 방식 | 코드를 어떻게 찾나 | codebase-memory-mcp와의 차이 |
|---|---|---|
| 순수 grep / 파일 읽기 | 매번 텍스트를 통째로 훑음 | 정확하지만 느리고 토큰 폭발. 이 도구는 한 번 색인 후 즉답. |
| 벡터 RAG (임베딩 검색) | "의미가 비슷한" 코드 조각을 확률로 검색 | "비슷함"은 알아도 "정확히 누가 호출"은 모름. 이 도구는 구조(호출 관계)를 정확히 안다. |
| LSP (언어 서버) | 한 언어의 타입·정의를 IDE에 제공 | 언어별로 따로, 무겁고 실시간. 이 도구는 158개 언어를 한 그래프로, 교차 서비스까지. |
| codebase-memory-mcp | 그래프 + 전문검색 + 의미검색을 한 번에 | 구조의 정확함 + 색인 속도 + 로컬·단일 바이너리. |
벡터 검색만 쓰는 코드 도구는 "이 질문과 의미가 가까운 코드 조각"을 추려 줄 뿐, 실제 호출 관계는 추측한다. 이 프로젝트는 tree-sitter로 코드 구조를 실제로 파싱해 그래프를 만들기 때문에, "이 함수의 호출자는 정확히 이 3곳"처럼 사실 기반 답을 준다. 11개 언어는 LSP 수준의 타입 해석까지 더한다.
버전 표기가 파일마다 제각각이고(server.json=0.8.1, 서버 응답=0.10.0), 정식 태그도 아직이다. README가 인용하는 논문(arXiv 2603.27277)은 미래 날짜의 ID라 동료 검증을 거친 게 아니라 제작자 자신의 자료로 보는 게 안전하다. "158개 언어"도 파일에 따라 156~161로 흔들린다. 벤치마크 수치는 인상적이지만 제작자 자체 측정값이니, 직접 돌려 보고 판단하는 게 좋다.
README · Makefile.cbm · THIRD_PARTY.md · server.json · 실제 소스 트리에서 확인한 구성.
먼저 마음의 준비 — 이 프로젝트는 우리가 흔히 떠올리는 "백엔드 + 프론트엔드 + DB" 웹 스택과 전혀 다르다. 거의 전부가 C 언어이고(소스 .c 683개·.h 619개, 첫 만든 코드만 약 5.9만 줄), 의존 라이브러리는 외부에서 설치하는 게 아니라 소스째로 프로젝트에 넣어(vendoring) 함께 컴파일한다. 그래서 완성품은 의존성 0인 단일 바이너리다. npm·PyPI·go에도 올라가 있지만, 그건 전부 "미리 빌드된 C 바이너리를 내려받아 주는 얇은 포장지"일 뿐 실제 엔진은 C다.
| 구성요소 | 무엇 | 역할 |
|---|---|---|
| C (C11) | 주 언어 | 엔진 전체. 컴파일 플래그 -std=c11 -Wall -Wextra -Werror로 엄격하게. |
| C++ (C++14) | 딱 2개 파일 | C/C++ 전처리기 처리용(simplecpp). 나머지는 전부 C. |
| GNU Make | Makefile.cbm | 빌드 시스템. scripts/build.sh가 "단일 진실원"으로 호출. |
| libgit2 (선택) | git 연동 | 있으면 git 이력 분석에 사용, 없으면 git log 명령으로 대체. |
| 구성요소 | 무엇 | 역할 |
|---|---|---|
| tree-sitter | 파서 런타임(MIT) | 소스 → AST(문법 나무) 변환의 핵심. 바이너리에 정적 포함. |
| 문법 156종 | 언어별 parser.c | 미리 생성된 문법을 컴파일해 넣음(약 158개 언어). 12종은 자체 제작. |
| Hybrid LSP | 자체 C 타입 해석기 | 11개 언어(Python·TS/JS·Go·C/C++·Java·Rust 등)는 타입까지 해석. |
| 구성요소 | 무엇 | 역할 |
|---|---|---|
| SQLite | 그래프 저장소(퍼블릭 도메인) | nodes/edges 테이블로 속성 그래프 저장. WAL 모드·ACID. |
| FTS5 + BM25 | SQLite 전문검색 | 이름을 camelCase 단어로 쪼개 색인 → 빠른 이름 검색. |
| Cypher 엔진 | 자체 구현(렉서·파서·플래너·실행기) | 그래프 질의어. "A를 호출하는 모든 함수" 같은 패턴 질의. |
| nomic-embed-code | 임베딩 벡터 31MB(Apache-2.0) | 의미 검색용. int8 양자화 벡터를 바이너리에 내장. |
에이전트와는 표준 입출력(stdio)을 통한 JSON-RPC 2.0으로 대화한다. JSON 처리는 yyjson, 메모리 할당은 마이크로소프트의 mimalloc, 해시는 xxHash/wyhash, 정규식은 TRE, 압축은 LZ4(소스 압축)와 Zstandard(팀 공유 그래프 압축), 해시 테이블은 Verstable — 전부 vendoring. "런타임 의존성 0"이란 "실행할 때 외부에서 끌어올 게 없다"는 뜻이지, 라이브러리를 안 쓴다는 게 아니다(컴파일 시점에 다 합쳐 넣는다).
유일한 비-C 부분. graph-ui/ 폴더에 React 19 + Three.js + Vite로 만든 3D 그래프 뷰어가 있다. --ui=true 옵션으로 켜면 자체 내장 HTTP 서버(역시 C로 작성)가 localhost:9749에 코드 지식 그래프를 3차원으로 띄운다.
먼저 전체 그림을 한 장으로 본 뒤, 대표 흐름 두 줄기(색인·질의)를 끝까지 따라간다.
이 도구의 일은 크게 둘로 나뉜다. (1) 색인(indexing) — 코드를 읽어 그래프를 만들어 SQLite에 저장. (2) 질의(query) — 에이전트가 던진 MCP 도구 호출을 그래프 조회로 바꿔 답한다. 부품 이름을 외우기 전에, 전체가 어떻게 맞물리는지 숲부터 보자.
a = f(b)는 "대입 → (왼쪽 a, 오른쪽 함수호출 f(b))"라는 가지로 펼쳐진다. tree-sitter가 만들어 주는 이 나무를 훑어야 "여기서 함수 f를 호출한다"를 기계가 안다.에이전트가 index_repository 도구를 호출하면 src/pipeline의 다중 패스(multi-pass) 파이프라인이 돈다. 핵심 5단계만 따라가면:
# src/pipeline/pipeline.c 헤더 주석이 밝히는 순서
1. 파일 탐색 discover/ 가 .gitignore·.cbmignore 보고 대상 파일 추림 + 언어 감지
2. 소스 적재 파일을 읽어 LZ4로 압축해 메모리에 올림 (RAM-first)
3. 정의 추출 tree-sitter로 파싱 → 함수·클래스·라우트를 '노드'로
4. 관계 연결 import·call·usage·의미(semantic) 엣지를 '선'으로
5. 그래프 덤프 메모리의 graph_buffer 를 SQLite로 한 번에 기록 → RAM 반납여기서 이 프로젝트 특유의 설계가 RAM-first(메모리 우선)다. 파싱·그래프 조립을 전부 메모리 위에서 끝내고 마지막에 SQLite로 단번에 쏟아낸 뒤 메모리를 OS에 돌려준다. 디스크를 자주 건드리지 않으니 빠르다(대신 거대한 모노레포는 한때 많은 RAM을 쓴다 — 리눅스 커널 색인 시 한순간 약 13GB의 회수 가능한 페이지를 점유한다고 코드 주석에 적혀 있다).
에이전트가 search_graph나 trace_path 같은 도구를 부르면:
① MCP 서버(src/mcp/mcp.c)가 도구 이름 + JSON 인자를 받음
② 알맞은 핸들러로 분배 (cbm_mcp_handle_tool)
③ search_graph → 이름검색(BM25)·정규식·의미검색(벡터 코사인)을 한 번에
trace_path → 그래프를 너비우선(BFS)으로 따라가며 호출 사슬 추적
④ store/ 가 캐시해 둔 SQL 문으로 그래프 조회 (준비된 statement 재사용)
⑤ 결과를 JSON으로 정리해 에이전트에 반환 # 토큰 적게, 1ms 안에'1ms 미만'의 비밀은 평범하다 — 자주 쓰는 SQL 문장을 미리 컴파일해 약 30개를 캐시하고, 라벨·이름·파일에 촘촘한 인덱스를 걸고, 메모리 맵(mmap)으로 파일을 읽고, 정규식 전에 LIKE로 후보를 먼저 줄인다. 화려한 마법이 아니라 기본기를 C로 단단히 쌓은 것이다.
이 레포에서 "정상"인 관례 하나 — 그래프의 노드 라벨은 Function·Method·Class·File·Route 등으로, 엣지 타입은 CALLS·IMPORTS·INHERITS·HTTP_CALLS·DATA_FLOWS처럼 전부 대문자로 적는다. 코드를 읽다 대문자 이름이 나오면 "아, 그래프의 점·선 종류구나"로 보면 된다.
루트에서 시작해, 엔진이 사는 src/와 문법이 사는 internal/cbm/까지.
파일이 1,600개가 넘지만 대부분은 158개 언어의 문법 파일과 vendoring한 라이브러리 소스다. 실제로 "이 프로젝트가 직접 만든 코드"는 src/ 한 폴더(약 5.9만 줄)에 모여 있다. 큰 덩어리만 보면 된다.
| 위치 | 한 줄 역할 |
|---|---|
| src/main.c | 실행 진입점. 인자가 없으면 stdio MCP 서버, 있으면 CLI·설치 등으로 분기. |
| src/mcp/ | 에이전트가 부르는 도구 16종을 정의·접수·응답하는 'API 창구'. |
| src/store/ | 지식 그래프를 SQLite에 넣고 빼는 모든 일. 스키마·인덱스·전문검색. |
| src/pipeline/ | 색인 공정. 탐색→파싱→추출→연결→덤프를 여러 패스로 조율. |
| src/cypher/ | 그래프 질의어 Cypher를 직접 해석·실행하는 미니 데이터베이스 엔진. |
| internal/cbm/ | tree-sitter로 코드를 AST로 만들고, 거기서 노드·엣지를 뽑아내는 추출 두뇌. |
| vendored/ | 외부 라이브러리 소스 보관소. 여기에 31MB 임베딩 벡터도 함께. |
| graph-ui/ | 코드 그래프를 3D로 돌려 보는 웹 화면(유일한 비-C 부분). |
이 레포 한 채로 배울 수 있는 기술과, 각각의 실습 아이디어.
이 프로젝트는 "요즘 인기 있는 개념"이 한 바이너리에 응축돼 있어 공부 소재로 훌륭하다. 기술별로 무엇을 건질지 짚어 본다.
src/mcp/mcp.c를 보면 도구들이 static const tool_def_t TOOLS[]라는 표 하나에 "이름 + 설명 + 입력 스키마(JSON)"로 정의돼 있고, 호출이 오면 이름으로 분배한다. MCP 서버의 본질이 의외로 단순함을 보여 준다.
실습: 도구 표를 읽고, 각 도구의 입력 파라미터를 한국어로 정리해 보기. 내 작은 MCP 서버를 Python fastmcp로 흉내 내 "도구 1개"부터 띄워 보기.
grep은 글자만 보지만, tree-sitter는 코드를 문법 나무로 만든다. internal/cbm/cbm.c는 파서를 스레드별로 재사용하고, extract_defs.c는 그 나무에서 함수·클래스 '정의'를 캐낸다. 158개 언어를 한 방식으로 다루는 비결이 여기 있다.
실습: npx tree-sitter로 내 코드 한 파일을 파싱해 AST를 눈으로 보기. "함수 선언 노드"가 어떻게 생겼는지 관찰.
Neo4j 같은 전용 그래프 DB를 쓰지 않고, 평범한 SQLite에 nodes·edges 두 테이블로 그래프를 구현했다. UNIQUE(source_id, target_id, type)로 중복 엣지를 막고, FTS5 가상 테이블 + BM25로 전문검색까지 붙였다.
실습: SQLite로 nodes(id,name)·edges(src,dst,type)를 만들고 "친구의 친구" 질의를 SQL로 써 보기. FTS5 가상 테이블도 한번 만들어 보기.
vendored/nomic/code_vectors.bin(31MB)은 코드 토큰들의 임베딩 벡터를 int8로 양자화해 박아 둔 것이다. src/semantic/semantic.c가 코사인 유사도로 "의미가 가까운 코드"를 찾되, 사전에 없는 토큰은 해시 기반 벡터로 대체한다. 외부 모델 0.
실습: 작은 임베딩 모델로 문장 몇 개를 벡터화해 코사인 유사도로 "가장 비슷한 문장" 찾기. 양자화(float→int8)가 왜 용량을 줄이는지 정리.
src/cypher/는 그래프 질의어 openCypher의 읽기 부분집합을 직접 구현했다(렉서→파서→플래너→실행기). "A가 B를 호출하고 B가 C를 호출하는 경로"를 화살표 문법으로 적는 사고방식을 배울 수 있다.
실습: 색인 후 query_graph로 간단한 Cypher 한 줄("Function 노드 상위 10개")부터 던져 보기. 복잡도 속성(cyclomatic 등)으로 정렬해 보기.
src/foundation/에는 아레나(arena) 할당기, 스레드 풀, 플랫폼 호환 계층이 들어 있다. "의존성 0 단일 바이너리"를 위해 라이브러리를 전부 소스로 넣고 컴파일하는 vendoring 전략도 실물로 볼 수 있다. C로 빠른 인프라를 짜는 정석.
실습: "아레나 할당기"가 왜 malloc을 일일이 부르는 것보다 빠른지 한 문단으로 설명해 보기. scripts/build.sh로 직접 빌드해 단일 바이너리를 손에 넣기.
쓰기만 할 때(설치형)와, 소스에서 빌드할 때로 나눠서.
이미 빌드된 바이너리를 받아 쓰는 경우엔 요구사항이 거의 없다. 단일 정적 바이너리라 라이브러리 설치가 필요 없기 때문이다. 직접 컴파일하려는 경우에만 C/C++ 컴파일러가 있으면 된다.
| 항목 | 요구사항 |
|---|---|
| 운영체제 | macOS(arm64/amd64) · Linux(arm64/amd64) · Windows(amd64). 정적 링크라 공유 라이브러리 의존 없음. |
| 설치(바이너리) | curl … install.sh | bash 한 줄. npm·PyPI·Homebrew·Scoop·Winget·AUR 등으로도 배포. |
| 빌드(소스) | C 컴파일러(gcc/clang) + C++ 컴파일러 + zlib + git. 그게 전부. |
| 디스크 | 색인 결과는 ~/.cache/codebase-memory-mcp/에 저장(CBM_CACHE_DIR로 변경). |
| 메모리(RAM) | RAM-first 설계. 일반 저장소는 가볍지만, 초대형 모노레포(리눅스 커널급)는 색인 중 한때 수~십수 GB 점유 후 반납. |
| CPU 코어 | 워커 수 자동 감지(CBM_WORKERS, 1~256). 컨테이너의 cgroup 할당량도 존중. |
| 에이전트 | MCP 지원 도구(Claude Code·Cursor·Codex·Gemini CLI·Zed·VS Code 등) — 설치 시 자동 설정. |
참고 환경변수: CBM_CACHE_DIR(캐시 위치), CBM_WORKERS(병렬 워커 수), CBM_LOG_LEVEL(로그 상세도), CBM_SQLITE_MMAP_SIZE(메모리 맵 크기, 기본 64MB).
설치만 해도 절반은 배운다. 난이도 순으로.
한 줄 설치 후, 평소 쓰는 코딩 에이전트에서 작은 오픈소스 프로젝트를 열고 "이 프로젝트 색인해줘(index this project)"라고 말해 보기. 그다음 "가장 많이 호출되는 함수 알려줘"처럼 물어, 파일을 안 읽고도 답이 나오는지 확인한다.
에이전트 없이도 터미널에서 codebase-memory-mcp cli search_graph '{"query":"login"}'처럼 도구를 직접 부를 수 있다. 16개 도구 중 list_projects·get_graph_schema·get_architecture를 차례로 호출해 출력 JSON을 읽어 본다.
query_graph 도구로 Cypher를 직접 써 본다. 예: "함수 노드를 복잡도(cyclomatic) 높은 순으로 10개", "특정 함수에서 3단계 안에 호출되는 모든 함수". get_graph_schema로 어떤 라벨·엣지가 있는지 먼저 파악하면 쉽다.
저장소를 클론하고 scripts/build.sh를 실행해 build/c/codebase-memory-mcp를 직접 만든다. --with-ui로 3D UI까지 포함해 빌드한 뒤 --ui=true로 켜서 localhost:9749에서 그래프를 돌려 본다.
리눅스 커널이나 큰 모노레포를 직접 색인해, README가 주장하는 "3분 색인 / 1ms 질의"가 내 머신에서 어떻게 나오는지 측정한다. 색인 중 메모리 사용량(RSS)도 관찰해 RAM-first 설계의 비용을 체감한다.
src/mcp/mcp.c의 TOOLS[] 표와 src/pipeline/pipeline.c의 패스 순서, src/store/store.c의 스키마(init_schema)를 함께 읽으며 "도구 호출 → 그래프 조회 → 응답" 한 줄기를 코드로 따라간다.
이 레포를 100% 소화하기 위한 6주 코스(주당 5~7시간 가정).
| 주차 | 주제 | 학습 자료 / 할 일 |
|---|---|---|
| 1주차 | MCP 프로토콜 기초 | MCP 공식 명세 읽기 + 이 도구를 에이전트에 붙여 도구 호출 관찰. 실습 1~2. |
| 2주차 | tree-sitter & AST | tree-sitter 문서 + 내 코드 파싱해 AST 보기. extract_defs.c 훑기. |
| 3주차 | SQLite 심화 + FTS5 | SQLite 공식 문서의 FTS5·인덱스·WAL. store.c의 init_schema 정독. |
| 4주차 | 그래프 & Cypher | openCypher 입문 + query_graph로 실전 질의. 실습 3. |
| 5주차 | 임베딩·의미 검색 | 벡터 임베딩·코사인 유사도·양자화 개념. semantic.c의 점수화 11신호 살펴보기. |
| 6주차 | C 시스템 프로그래밍 | 아레나 할당·vendoring·정적 링크. 직접 빌드(실습 4) + foundation/ 읽기. |
이 문서와 레포에 등장한 용어를 한자리에.
| 용어 | 의미 |
|---|---|
| MCP | Model Context Protocol. AI 에이전트와 외부 도구를 잇는 표준 규격. 이 프로젝트는 MCP '서버'. |
| 지식 그래프 | 정보를 점(노드)과 선(엣지)으로 표현한 지도. 여기선 함수·호출 관계의 지도. |
| tree-sitter | 소스 코드를 문법 나무(AST)로 파싱하는 엔진. 158개 언어 문법을 내장. |
| AST | 추상 구문 트리. 코드를 문법 구조에 따라 나무 모양으로 표현한 것. |
| 속성 그래프 | 노드·엣지에 부가 정보(속성)를 매단 그래프. SQLite의 nodes/edges 테이블로 구현. |
| FTS5 · BM25 | SQLite 전문검색 엔진(FTS5)과 그 관련도 점수 공식(BM25). 빠른 이름 검색에 사용. |
| 임베딩 / 벡터 | 단어·코드를 숫자 배열로 바꾼 것. 의미가 가까우면 벡터도 가깝다. |
| 코사인 유사도 | 두 벡터가 이루는 각도로 '의미의 가까움'을 재는 척도. 의미 검색의 핵심 계산. |
| 양자화 (quantization) | 실수(float) 벡터를 int8 같은 작은 정수로 줄여 용량·속도를 확보하는 기법. |
| Cypher | 그래프 질의어. "A가 B를 호출"을 화살표 문법으로 적는다(openCypher 부분집합). |
| LSP | Language Server Protocol. 언어별 타입·정의를 제공하는 규격. 이 도구는 11개 언어에 한해 타입 해석. |
| BFS | 너비 우선 탐색. 가까운 이웃부터 퍼지며 그래프를 훑는 방법. 호출 사슬 추적에 사용. |
| 아레나 할당 | 큰 메모리 덩어리를 한 번에 잡아 잘라 쓰는 할당 기법. malloc 남발보다 빠름. |
| vendoring | 외부 라이브러리를 소스째 프로젝트에 넣어 함께 컴파일하는 전략. 의존성 0 바이너리의 비결. |
| WAL | Write-Ahead Logging. SQLite가 안정성과 동시성을 높이는 기록 방식. |
| LZ4 / Zstandard | 빠른 압축 알고리즘. 소스 압축(LZ4)·팀 공유 그래프 압축(zstd)에 사용. |
| RAM-first | 작업을 메모리에서 끝내고 마지막에 디스크로 한 번에 쓰는 설계. 속도의 핵심. |
| JSON-RPC 2.0 | JSON으로 "이 함수를 이 인자로 불러줘"를 주고받는 원격 호출 규약. MCP의 대화 방식. |
| SLSA · DCO | 공급망 보안 등급(SLSA)과 기여자 서명 규칙(DCO). 이 레포의 CI가 적용. |
원문·명세·관련 기술 더 파기.