context-mode 딥다이브
— AI의 책상은 작게, 기억의 서랍은 크게

1프로젝트 한줄 요약

context-mode는 AI 코딩 에이전트와 도구 출력 사이에 놓이는 실행·검색 계층입니다. 에이전트가 긴 출력을 그대로 받는 대신, 별도 프로세스에서 데이터를 가공하거나 SQLite에 색인합니다. 핵심은 모델의 기억 용량을 늘리는 것이 아니라, 지금 읽을 정보와 나중에 찾을 정보를 나누는 데 있습니다.

1-1. 세 가지 흐름을 구별하면 전체가 보입니다

src/server.ts는 MCP 도구를 등록합니다. src/executor.ts의 PolyglotExecutor는 자식 프로세스를 만들고, src/store.ts의 ContentStore는 색인과 검색을 담당합니다. 세션 이벤트는 src/session/db.ts의 SessionDB가 별도로 관리합니다.

1-2. 사용 장면을 작은 예제로 보기

다음은 MCP 도구 호출의 인자를 설명하는 예시입니다. 터미널 명령이 아니며, 도구 이름 앞의 접두사는 클라이언트마다 달라질 수 있습니다.

// 긴 출력 대신, 코드가 계산한 결과만 모델에게 전달
ctx_execute({
  language: "javascript",
  code: "const values = [10, 20, 30]; console.log(values.reduce((a, b) => a + b, 0));"
});

// 정확한 문장을 다시 읽고 싶다면 원문을 색인한 뒤 검색
ctx_index({ content: "## 재시도\n실패하면 최대 3번 재시도한다.", source: "연습문서" });
ctx_search({ queries: ["재시도"], source: "연습문서" });

2왜 주목받는가

2-1. 도구가 많아질수록 출력도 늘어납니다

브라우저 스냅샷, 이슈 목록, 테스트 로그는 각각 유용하지만 한 대화에 계속 쌓이면 부담이 됩니다. context-mode는 이런 출력의 양을 줄이는 기능과, 대화가 압축된 뒤 작업을 이어 가는 기능을 함께 내세웁니다. GitHub Trending Weekly #15 선정과 스타 31,896개는 관심의 크기를 보여 주지만, 인기의 원인을 증명하는 실험은 아닙니다.

관심을 끌 만한 설계상의 이유는 분명합니다. 도구 출력을 줄이는 경로와 잊어버린 작업을 다시 찾는 경로가 같은 검색 기반 위에서 연결됩니다. 설치할 도구 하나가 절약과 복구를 함께 다룬다는 점이 사용자에게 이해하기 쉬운 제안입니다.

2-2. “98% 절약”은 어떤 실험의 숫자인가

이 수치들은 프로젝트가 기록한 벤치마크이며 독립 재측정 결과는 아닙니다. 바이트 감소율은 모델별 토큰 감소율, 전체 요금 감소율, 정답률과도 구별해야 합니다. 예를 들어 오류 개수만 물었다면 한 줄 통계로 충분하지만, 수정 코드를 작성하려면 오류의 위치와 원문이 더 필요합니다.

2-3. 경쟁 접근법과 비교하면 장점이 선명합니다

아래 표는 순위표가 아니라 해결 방식의 비교입니다. Claude Code·Cursor 같은 에이전트는 context-mode를 연결하는 호스트이기도 합니다. 특정 제품의 최신 성능 우열을 주장하지 않고, 이 저장소에서 확인되는 역할 차이를 비교합니다.

2-4. 여러 플랫폼을 지원하되 능력은 다릅니다

docs/platform-support.md는 17개 클라이언트와 OpenClaw 게이트웨이 통합을 구분합니다. src/adapters/types.ts의 PlatformId에는 OpenClaw를 포함한 이름 18개와 unknown이 있습니다. 따라서 “17개 지원”과 “18개 어댑터 이름”은 집계 범위가 다른 수치입니다.

도구 호출을 차단할 수 있는지, 인자를 고칠 수 있는지, 압축 직전에 개입할 수 있는지는 호스트마다 다릅니다. MCP 연결만 있는 구성은 도구를 제공하지만 자동 라우팅과 세션 복구까지 동일하게 보장하지는 않습니다. 이 차이를 인터페이스로 표현한 방식이 오히려 중요한 학습 대상입니다.

3기술 스택 전체 지도

3-1. 백엔드: HTTP 서비스보다 로컬 MCP 프로세스에 가깝습니다

package.json의 패키지 버전은 1.0.169, 모듈 형식은 module, Node.js 요구 버전은 >=22.5.0입니다. src/server.ts는 McpServer와 StdioServerTransport를 연결합니다. 핵심 실행 경로는 표준 입출력을 사용하는 MCP 서버이며, 별도 웹 검색 화면을 띄우는 구조는 아닙니다.

정식 패키지 이름은 @modelcontextprotocol/sdk, @clack/prompts, @mixmark-io/domino, turndown-plugin-gfm입니다. 버전 앞의 ^는 허용 범위를 뜻합니다. 잠금 파일의 버전은 그 파일에 기록된 해석 결과이며, npm install을 사용하는 CI가 매번 같은 버전을 설치한다는 보장은 별도 문제입니다.

3-2. SQLite는 하나의 패키지로 고정돼 있지 않습니다

src/db-base.ts의 loadDatabase()는 Bun 환경이면 bun:sqlite를 고릅니다. 현대 Node 환경에서는 node:sqlite의 FTS5 지원을 검사하고, 사용할 수 없으면 better-sqlite3로 내려갑니다. 의존성 목록에 있는 라이브러리와 실제 실행 때 선택되는 구현은 다를 수 있습니다.

BunSQLiteAdapter와 NodeSQLiteAdapter가 호출 방식을 맞춥니다. 데이터베이스 구현을 바꾸면서 상위의 색인·세션 코드는 유지하는, 어댑터 패턴의 작은 사례입니다.

3-3. 프론트엔드: 호스트 UI와 소개 웹사이트

루트 의존성에는 React나 Vue가 없습니다. web/worker.js 주석은 별도 플랫폼 앱 배포를 설명하지만, 이 Worker 자체는 소개 페이지 라우팅과 자산 제공만 수행합니다. 소개 페이지가 있다는 이유로 저장소 전체를 프론트엔드 앱으로 이해하면 핵심을 놓칩니다.

3-4. 인프라·빌드: 소스와 배포용 번들을 함께 관리합니다

packageManager는 pnpm@10.23.0을 선언하지만 저장소에는 bun.lock이 있고, CI는 npm install을 사용합니다. 선언·잠금·CI 명령을 각각 확인해야 재현 조건을 이해할 수 있습니다. 또한 번들의 node18 대상은 출력 문법의 기준이며, 제품의 Node.js 최소 버전 22.5를 낮추는 설정이 아닙니다.

4아키텍처 심화 분석

4-1. 시스템 구조도

두 갈래를 함께 보세요. MCP 도구 경로는 실행과 검색을 맡고, 훅 경로는 호출 전후와 세션 경계에 개입합니다. 모든 호스트가 아래의 훅 전체를 제공하는 것은 아닙니다.

4-2. 설계 패턴 ① 큰 값 대신 검색 가능한 참조를 돌려줍니다

ctx_execute의 처리기는 PolyglotExecutor.execute()를 호출합니다. 실행기는 임시 디렉터리에 스크립트를 쓰고 child_process.spawn()으로 런타임을 실행합니다. Rust는 먼저 컴파일하는 별도 분기가 있습니다. 일반 실행의 현재 디렉터리는 프로젝트 루트 또는 호출의 cwd입니다.

완료 후 src/server.ts가 출력 크기를 검사합니다. 큰 문자열 자체 대신 “어느 출처에 몇 조각을 색인했는지”와 검색 방법을 반환하는 것이 핵심입니다. 분산 시스템에서 큰 파일을 직접 보내는 대신 저장 위치와 식별자를 보내는 방식과 닮았습니다.

// src/server.ts의 실제 상수
const INTENT_SEARCH_THRESHOLD = 5_000;
const LARGE_OUTPUT_THRESHOLD = 102_400;

// 성공한 일반 stdout 경로를 설명하기 위한 축약 의사코드
if (intent?.trim() && Buffer.byteLength(stdout) > INTENT_SEARCH_THRESHOLD) {
  return intentSearch(stdout, intent, source);
}
if (Buffer.byteLength(stdout) > LARGE_OUTPUT_THRESHOLD) {
  return indexStdout(stdout, source);
}
return stdout;

intentSearch()는 원문을 영속 저장소에 색인한 다음 의도에 맞는 부분을 찾습니다. indexStdout()는 색인 메타데이터와 후속 검색 안내를 만듭니다. 실제 응답에는 실행 코드의 일부를 보여 주는 내용과 오류·타임아웃 처리도 있으므로, 위 코드는 전체 구현을 대체하지 않습니다.

출력 감소와 정보 삭제는 같은 일이 아니지만, 검색 가능한 저장에도 크기와 보존 기간의 한계는 있습니다. 실행기는 stdout과 stderr를 합쳐 기본 100 * 1024 * 1024바이트를 넘으면 프로세스를 종료합니다. 이 제한 너머의 출력까지 모두 보관된다고 이해하면 안 됩니다.

4-3. 설계 패턴 ② 검색을 작은 단계의 파이프라인으로 만듭니다

ContentStore.index()는 Markdown 제목과 코드 펜스를 읽어 문서 조각을 만듭니다. sources에는 출처와 파일 기반 색인의 해시를, chunks와 chunks_trigram에는 서로 다른 방식의 전문 색인을 둡니다. 첫 번째는 porter unicode61, 두 번째는 trigram 토크나이저를 사용합니다.

#rrfSearch()의 상수 K는 60입니다. 한 검색 목록에서 순위가 r이면 1 / (60 + r)을 더합니다. 서로 다른 점수의 절댓값을 억지로 비교하지 않고 순위로 합치는 방식입니다.

// RRF를 손으로 계산하는 독립 예제: 순위는 1부터 시작
const score = ranks => ranks.reduce((sum, rank) => sum + 1 / (60 + rank), 0);
const both = score([1, 2]);  // 두 검색에서 1위, 2위
const one = score([1]);      // 한 검색에서만 1위
console.log({ both, one });

#applyProximityReranking()은 RRF 상위 결과를 요청한 개수만큼 추린 뒤 제목 일치, 본문의 단어 간 거리, 인접한 단어 쌍의 반복 횟수로 순서를 다시 정합니다. “BM25를 쓴다”는 소개를 넘어, 후보 검색과 순위 조정의 책임이 어떻게 분리되는지 읽어 보세요.

오타 보정은 fuzzyCorrect()와 편집 거리 계산을 사용합니다. 의미를 이해하는 임베딩 검색은 아니므로, “접속 실패”와 “connection refused”처럼 표현이 다른 질의는 결과를 직접 확인해야 합니다. 한글 처리 역시 영어 어간 추출과 똑같은 효과를 기대하면 안 됩니다.

4-4. 설계 패턴 ③ 플랫폼 형식은 바깥에서, 정책은 안쪽에서 처리합니다

src/adapters/types.ts의 HookAdapter는 입력 파싱, 응답 형식, 설정 경로, 지원 능력의 계약입니다. hooks/core/routing.mjs의 routePreToolUse()는 플랫폼 전용 JSON 대신 공통 결정 객체를 만듭니다.

// hooks/core/routing.mjs가 사용하는 정규화된 결정 형태
{ action: "deny", reason: "..." }
{ action: "modify", updatedInput: { ... } }
{ action: "context", additionalContext: "..." }
null // 그대로 통과

여러 형식을 각각 구현하되 중심 정책을 공유하면 “curl 출력은 실행·색인 경로로 보내자”라는 규칙을 한곳에서 고칠 수 있습니다. mcpRedirect()는 MCP 도구가 준비되지 않으면 우회 결정을 통과시켜, 대체 도구가 없어 작업이 막히는 상황을 피합니다.

위 표의 파일은 모두 src/adapters/ 아래에 있습니다. 읽기·명령 차단 정책은 src/security.ts의 evaluateFilePath(), evaluateCommandDenyOnly() 등과 연결됩니다. 라우팅을 사용한다고 임의의 코드가 실행 시 완전히 검증되는 것은 아닙니다.

4-5. 설계 패턴 ④ 이벤트를 저장하고 복구용 상태를 따로 만듭니다

hooks/posttooluse.mjs는 extractEvents()로 파일·오류·Git·작업 등의 사실을 추출합니다. hooks/session-loaders.mjs의 attributeAndInsertEvents()가 프로젝트 귀속을 계산하고 DB에 넣습니다. 원시 도구 응답을 매번 대화에 다시 넣는 대신, 이벤트 기록과 읽기용 안내를 나눕니다.

1. 수집: src/session/extract.ts가 도구 입력·출력을 여러 추출기에 통과시킵니다.
2. 저장: SessionDB는 최근 5개 이벤트 범위에서 중복을 확인하고, 세션당 1,000개 상한에서 중요도가 낮은 이벤트부터, 같은 중요도에서는 오래된 이벤트부터 밀어냅니다.
3. 압축 직전: hooks/precompact.mjs가 buildResumeSnapshot()을 호출하고 upsertResume()으로 보관합니다.
4. 재개: hooks/sessionstart.mjs가 이벤트 문서와 안내를 만들며, 상황에 따라 저장된 스냅샷도 복구합니다.
5. 상세 조회: hooks/session-directive.mjs는 session-events 출처를 검색하도록 안내합니다.

buildResumeSnapshot()은 목표·파일·오류·결정·작업·최근 사용자 메시지 등을 조합합니다. 최근 사용자 메시지는 최대 3개, 각 400자 제한이 있고, 파일 목록은 최대 10개를 보여 줍니다. 과거 이벤트 전체를 영구히 보존하거나, 당시 프로세스를 완전히 재생하는 시스템으로 이해해서는 안 됩니다.

4-6. 실제 동작을 바꾸는 작은 제한들

검색 응답의 예산은 엄격한 40KiB 바이트 상한이 아닙니다. 실제 누적은 formatted.length를 사용하므로 한글·이모지의 UTF-8 바이트 수와 다르고, 질의를 처리한 뒤 목표값을 넘어갈 수도 있습니다. 상수의 주석뿐 아니라 비교 시점과 계산 단위까지 확인해야 합니다.

src/runPool.ts의 runPool()은 실패를 작업별로 보관하고, 결과는 입력 순서에 맞춥니다. runBatchCommands()에서 동시성 1은 전체 명령이 시간 예산을 공유하고, 동시성 2 이상은 명령별로 같은 타임아웃을 받습니다. 숫자 하나를 바꿨는데 시간 정책까지 달라지는 중요한 지점입니다.

5디렉토리 구조 해부

5-1. 처음 읽을 때의 추천 순서

src/types.ts로 결과와 이벤트의 모양을 익힌 다음, src/executor.ts와 src/store.ts에서 두 핵심 부품을 읽어 보세요. 그다음 src/server.ts에서 ctx_execute 처리기를 찾아 부품이 연결되는 과정을 봅니다. 4,991줄짜리 서버를 첫 줄부터 외우는 것보다 한 요청의 경로를 따라가는 편이 낫습니다.

5-2. 줄 수는 “무엇을 셌는지”와 함께 읽습니다

코드 규모를 말할 때 생성 번들과 테스트를 나누어야, 실제로 공부할 구현의 크기가 보입니다. 아래는 줄바꿈 수를 센 대략적인 물리적 줄 수입니다. 주석과 빈 줄을 포함하며, .git·node_modules·build·dist와 *.bundle.mjs는 제외했습니다.

*.test.ts 파일은 210개입니다. 파일 수는 테스트 실행 결과나 커버리지를 뜻하지 않습니다. 주요 구현은 src/store.ts 2,071줄, src/executor.ts 785줄, src/session/extract.ts 2,960줄, src/session/db.ts 1,726줄입니다.

6학습 포인트 (기술별)

6-1. TypeScript와 Zod: 입력 경계를 설계하기

src/search/ctx-search-schema.ts의 buildCtxSearchInputSchema()는 공유 DB 모드일 때만 project 필드를 스키마에 넣습니다. 사용할 수 없는 선택지를 설명문으로만 금지하지 않고, 도구가 보여 주는 계약 자체에서 제외하는 설계입니다.

같은 파일의 coerceJsonArray()는 일부 클라이언트가 문자열로 보내는 배열 인자를 보정합니다. 학습할 부분은 “무조건 엄격하게 거절할까”와 “어떤 입력을 호환 목적으로 받아 줄까”의 경계입니다.

// resolveProjectScope()의 의미를 표로 옮긴 의사코드
공유 모드 꺼짐           => undefined  // 별도 필터 없음
공유 모드 켜짐 + 생략    => 현재 프로젝트 경로
공유 모드 켜짐 + global  => null       // 전체 프로젝트 조회
공유 모드 켜짐 + 경로    => 지정 경로

실습 아이디어: undefined, null, 빈 문자열, global을 구분하는 입력표를 만드세요. 각 값이 “생략”, “전체”, “잘못된 경로” 중 무엇인지 먼저 정하고 구현을 설계합니다.

6-2. Node.js 프로세스: 정상 종료보다 실패 경로 읽기

PolyglotExecutor는 stdout·stderr 스트림을 모으고, 크기 상한과 시간 제한을 적용합니다. Unix에서는 프로세스 그룹을 만들고 killTree()가 하위 프로세스 종료를 돕습니다. 백그라운드 실행은 타임아웃 시 연결을 떼고 일부 결과를 반환하므로 일반 실행과 수명 관리가 다릅니다.

실습 아이디어: “명령이 실패함”, “실행 파일이 없음”, “시간이 지남”, “출력 상한 초과”를 구분해 ExecResult의 stdout, stderr, exitCode, timedOut에 무엇을 담을지 써 보세요.

6-3. SQLite: WAL은 여러 작성자를 무제한으로 병렬화하지 않습니다

applyWALPragmas()는 journal_mode = WAL, synchronous = NORMAL을 설정합니다. 읽기와 쓰기의 공존을 돕지만, 쓰기 경합은 여전히 처리해야 합니다. 생성 시 30,000ms 대기 설정과 withRetry()의 100·500·2,000ms 재시도가 함께 사용됩니다.

withRetry()는 동기 API를 유지하기 위해 재시도 사이를 바쁜 대기로 구현합니다. 따라서 편한 호출 구조와 프로세스의 이벤트 루프를 막는 비용을 함께 토론할 수 있습니다.

실습 아이디어: docs/adr/0001-sessiondb-multi-writer.md를 읽고, 단일 작성자 잠금이 다중 창 사용을 왜 막았는지 사건·원인·해결책 세 칸으로 정리하세요.

6-4. 검색: 정확한 원문을 얼마나 되돌려줄 것인가

집계 작업은 한 줄로 끝날 수 있지만 문서 검색은 사용할 코드와 조건을 충분히 반환해야 합니다. ContentStore는 제목·코드 여부·출처를 보관하고, src/search/unified.ts의 searchAllSources()는 조회 모드에 따라 소스를 합칩니다.

기본 relevance 모드는 ContentStore 결과를 사용합니다. timeline 모드는 SessionDB와 자동 메모 검색을 추가하고 시간순으로 합칩니다. 모든 검색 모드가 같은 자료와 같은 순서를 제공하는 것은 아닙니다.

실습 아이디어: 짧은 문서 5개에 같은 단어를 다른 제목·위치로 배치하고 예상 순위를 적으세요. 영어 어간, 한글, 오타, 두 글자 질의를 각각 준비하면 검색기의 가정이 보입니다.

6-5. 동시성: 빨라지는 대신 늘어나는 자원을 계산하기

runPool()은 정해진 수의 작업자가 공유 인덱스를 가져가며 다음 작업을 실행합니다. settled[idx]에 결과를 넣어 완료 순서와 출력 순서를 분리합니다. 한 작업의 예외가 다른 작업의 결과를 없애지 않는 점이 핵심입니다.

실습 아이디어: 실행 시간이 30·10·20ms인 세 작업을 동시성 2로 처리하는 시간표를 그리세요. 둘째 작업이 실패해도 셋째 작업이 진행돼야 하며, 반환 배열은 원래 입력 순서여야 합니다.

6-6. 회귀 테스트: 버그를 조건으로 바꾸기

좋은 학습 결과는 코드를 따라 치는 데서 끝나지 않고, 이 설계가 지켜야 할 조건을 자기 말로 설명하는 것입니다.

7하드웨어 / 시스템 요구사항

7-1. 필수 조건과 선택 조건

src/runtime.ts의 Language는 JavaScript, TypeScript, Python, Shell, Ruby, Go, Rust, PHP, Perl, R, Elixir, C#의 12개를 선언합니다. detectRuntimes()가 설치 상태를 확인하므로 선언된 언어와 현재 사용할 수 있는 언어는 다릅니다. C# 경로는 dotnet-script, Rust 경로는 rustc를 찾습니다.

7-2. 메모리는 숫자를 외우기보다 상한을 계산합니다

공식적인 최소 RAM·CPU 등급은 루트 패키지와 핵심 설정에 명시돼 있지 않습니다. 실행 하나의 출력 수집 상한이 100MiB라면, 8개가 동시에 상한에 가까워지는 경우 수집 버퍼만 약 800MiB가 될 수 있습니다. 문자열 변환·버퍼 합치기·SQLite 캐시·각 자식 프로세스의 메모리는 여기에 추가됩니다.

이 계산은 실제 사용량 측정이나 최소 사양이 아닙니다. hardCapBytes는 출력 버퍼의 기준이며 자식 프로세스 전체의 RAM 한도를 설정하는 기능도 아닙니다. 대형 빌드를 실행하면 빌드 도구 자체의 요구사항이 더 클 수 있습니다.

7-3. 디스크·네트워크·시간 제한도 요구사항입니다

• 디스크: 원문, 두 종류의 FTS5 색인, 이벤트, WAL 파일이 생깁니다. DB 파일 하나의 크기만 보고 전체 저장량을 판단하면 안 됩니다.
• 경로: 기본 저장 위치는 플랫폼 어댑터가 정합니다. CONTEXT_MODE_DIR는 세션·콘텐츠 저장 루트 재지정에 사용됩니다.
• 네트워크: 로컬 자료의 색인·검색과 URL 수집은 다릅니다. ctx_fetch_and_index는 외부 자료를 요청하며, 자식 코드도 네트워크를 사용할 수 있습니다.
• 연결 기능: hooks/platform-bridge.mjs는 유효한 플랫폼 설정이 있을 때 이벤트 전달 경로를 엽니다.
• 시간: 일반 실행의 타임아웃 생략은 대체로 호스트 정책에 맡깁니다. Antigravity CLI는 resolveExecTimeout()에서 기본 120,000ms 예외가 있습니다.

src/lifecycle.ts는 부모 프로세스의 생존과 종료 신호를 살펴 남겨진 서버를 정리합니다. 이 저장소에서는 검색 성능뿐 아니라 “도구가 언제 끝나야 하는가”도 시스템 요구사항의 일부입니다.

8직접 해볼 수 있는 실습 과제

아래 과제는 소스를 읽거나 별도의 연습용 코드로 해결할 수 있습니다. 실제 에이전트 계정, 운영 데이터, 외부 API는 필요하지 않습니다. 각 과제는 완성물과 통과 조건이 있으므로 스스로 이해도를 점검하기 좋습니다.

// 저장소 모듈을 불러오지 않는 독립 JavaScript 예제
for (const text of ["abc", "한글", "🙂"]) {
  console.log({ text, units: text.length, bytes: Buffer.byteLength(text, "utf8") });
}
// 예상: abc = 3 / 3, 한글 = 2 / 6, 🙂 = 2 / 4

과제의 정답은 실행 결과 하나보다, 어떤 정보가 사라져도 되고 어떤 정보는 다시 찾을 수 있어야 하는지 정한 기준에 있습니다.

9관련 기술 심화 학습 로드맵

JavaScript의 배열·객체·함수와 async/await를 알고 있다는 기준입니다. 매주 읽을 범위를 좁히고, 마지막에 설명 가능한 산출물을 하나씩 남깁니다. 주당 시간은 학습 계획용 제안이며 성능이나 숙련도에 대한 보장은 아닙니다.

9-1. 무엇부터 읽을지 막힐 때의 질문

1. 입력: 이 함수는 신뢰할 수 없는 JSON을 받는가, 이미 검증된 값을 받는가?
2. 보관: 원문은 어디에 있고, 모델이 읽는 응답에는 무엇만 들어 있는가?
3. 실패: 예외가 생기면 대화가 멈추는가, 기능 일부만 빠지는가?
4. 범위: 상태가 프로세스·세션·프로젝트·에이전트 중 어디에 속하는가?
5. 검증: 실제 회귀 테스트는 어떤 입력과 기대 결과로 조건을 표현하는가?

이 저장소를 다 읽는 것보다, 입력·저장·출력·복구의 경계를 다른 문제에도 그릴 수 있게 되는 것이 목표입니다.

10핵심 키워드 사전

11참고 링크

11-1. 공식 저장소와 구현 근거

• 공식 저장소 · 소개, 이슈, 배포 진입점.
• README · 설치 경로와 제품이 내세우는 기능.
• package.json · 실제 의존성 범위, 명령, Node.js 요구 버전.
• bun.lock · 이 커밋의 잠금 버전.
• src/server.ts · 도구 등록, 출력 임계값, 검색 제한.
• src/store.ts · 청크, FTS5, RRF, 오타 보정, 재정렬.
• src/executor.ts · 프로세스·환경변수·출력 수집의 실제 경계.
• src/session/snapshot.ts · 이벤트로 복구 안내를 구성하는 방법.
• hooks/session-directive.mjs · 재개 안내와 검색 가능한 이벤트 문서.
• 플랫폼 지원표 · 호스트별 훅과 제한 비교.
• 벤치마크 문서 · 집계와 원문 검색의 절약률 차이.
• 설계 결정 기록 · 다중 작성자 지원과 통계 산식 변경의 배경.
• 플랫폼 연결 코드 · 선택적 이벤트 전송 조건과 가림 처리.
• 라이선스 원문 · GitHub 자동 분류와 별개로 확인할 이용 조건.

11-2. 관련 기술 공식 학습 자료

• MCP 공식 문서 · 호스트·클라이언트·서버와 도구 호출 개념.
• TypeScript 공식 문서 · 타입, 유니언, 모듈, 엄격한 검사.
• Node.js 자식 프로세스 문서 · spawn, 표준 입출력, 종료 신호.
• Node.js 스트림 문서 · 출력이 조각으로 도착할 때의 처리.
• SQLite FTS5 문서 · 토크나이저, BM25, 전문 검색 질의.
• SQLite WAL 문서 · 동시 접근과 로그 파일의 의미.
• Zod 공식 문서 · 실행 시 입력 검증과 값 변환.
• Vitest 공식 안내 · 단위 테스트와 실행 환경.
• esbuild 공식 문서 · 번들, 대상 런타임, 외부 의존성.

현재 상태 (2026-10-23 확인)