billion-context 딥다이브
— 오래된 대화는 접고, 필요한 원문은 다시 펼친다

1프로젝트 한줄 요약

billion-context는 오래된 대화 구간을 모델이 작성한 요약으로 접고, 필요하면 저장한 원문을 다시 꺼내는 도구입니다. npm 패키지 이름은 billion-context, 실행 명령은 bili이고, bili-proxy는 같은 진입점을 가리키는 별칭입니다.

수십억 토큰을 한 번에 모델에 넣는 것이 아니라, 작은 창 안에 남길 내용을 계속 고르는 시스템입니다. 제목의 큰 숫자는 장기간 세션에서 다룬 누적 입력량의 맥락으로 읽어야 합니다. 모델 자체의 컨텍스트 창이 커지거나, 요약만으로 모든 세부 정보가 보존되는 것은 아닙니다.

1-1. 네 가지 도구가 만드는 학습용 지도

중요한 경계가 있습니다. 커널의 createCore().decompress()는 블록 조회를 제공하는 작은 함수입니다. 사용자가 보는 전체 복원 동작은 프록시의 원문 저장·조회와 커널의 블록 활성 상태 처리까지 합쳐 완성됩니다. 함수 이름만 보고 제품 기능 전체가 한 함수에 들어 있다고 생각하면 흐름을 놓치기 쉽습니다.

1-2. 연결 방식은 세 가지, 압축 책임은 두 갈래

README는 네이티브 플러그인, 클라이언트를 함께 띄우는 런처, API 기본 URL 변경을 안내합니다. 코드에서는 요청의 pluginMode 여부에 따라 도구를 누가 실행하는지가 달라집니다. 연결 방법과 압축 실행 주체를 별개의 축으로 읽으면 구조가 쉬워집니다.

• 프록시 모드: 프록시가 압축 도구 호출을 처리하고, 필요한 경우 모델에 내부 요청을 이어 보냅니다.
• 플러그인 모드: 호스트 에이전트가 압축 도구를 실행합니다. 프록시는 같은 도구를 중복 주입하지 않습니다.

2왜 주목받는가

2-1. 관심을 끄는 문제는 세 가지다

코딩 에이전트는 파일 내용, 검색 결과, 명령 출력, 수정 내역을 계속 대화에 붙입니다. 요청마다 많은 이력을 다시 전송하면 입력량이 커지고, 창이 차면 정리 작업이 필요합니다. 이 프로젝트는 조금씩 접기·필요하면 펼치기·여러 클라이언트에 연결하기를 한 제품에 묶었습니다.

2026-10-23 GitHub 기준 스타 2,452개, 포크 210개이며 GitHub Trending TypeScript Weekly #16에 선정됐습니다. 이 지표만으로 사용자 유입 원인을 확정할 수는 없지만, 아래의 설계가 기술적으로 관심을 끌 만한 지점입니다.

1. 증분 처리: 전체 대화를 한 번에 다시 쓰기보다 범위를 지정해 블록 단위로 관리합니다.
2. 복원 경로: 요약이 놓친 세부 사항을 원문 저장소에서 다시 찾을 수 있도록 설계했습니다.
3. 호스트 분리: 압축 엔진과 API·플러그인 연결 코드를 나눠 재사용 범위를 넓혔습니다.

2-2. 비슷한 해결책과 무엇이 다른가

다음 표는 처리 방식의 비교입니다. 특정 제품의 품질 순위나 비용 벤치마크를 뜻하지 않습니다. 클라이언트별 설치 차이는 이 저장소의 CLIENTS.md와 실제 어댑터를 함께 읽어야 합니다.

이 프로젝트의 강점은 요약 하나가 아니라, 요약을 오래 유지하는 데 필요한 상태와 복구 경로를 함께 구현했다는 점입니다.

2-3. 홍보 수치와 소스가 증명하는 것은 다르다

코드를 읽을 때도 같은 태도가 유용합니다. 메모리 절감 장치를 발견했다면 적용 조건을 찾고, 복구 함수를 발견했다면 복구할 데이터가 실제로 저장되는 경로까지 따라가야 합니다.

3기술 스택 전체 지도

3-1. 백엔드와 압축 엔진

루트 package.json은 ESM을 뜻하는 "type": "module"과 Node.js >=20을 선언합니다. tsconfig.json은 strict: true, target: ES2022, module: NodeNext, moduleResolution: NodeNext입니다.

여기서 ^는 버전 범위입니다. package-lock.json의 루트 설치 해석값은 TypeScript 5.9.3, tsup 8.5.1, tsx 4.23.9, esbuild 0.27.7입니다. 선언된 최소 범위와 고정된 설치 결과를 구분해서 읽어야 합니다.

3-2. 프론트엔드: 독립 SPA보다 서버에 가까운 화면

src/web/page.ts의 renderPage()가 HTML을 조립하고, src/web/client.ts와 src/web/styles.ts가 브라우저 동작과 스타일을 제공합니다. 설정 편집, 세션 조회, 로그 탐색을 위해 별도의 React·Vue 애플리케이션을 빌드하는 구조는 아닙니다.

React의 별도 버전 범위는 루트 의존성에 없습니다. tsup.config.ts의 브라우저용 설정에서 react를 외부로 남겨 dsh 호스트의 모듈 로더가 제공하게 합니다. 따라서 이 저장소 전체를 React 앱이라고 부르면 실제 구조와 맞지 않습니다.

3-3. 빌드·배포·검증

4아키텍처 심화 분석

4-1. 전체 시스템 구조

HTTP 서버 진입점은 src/server.ts의 startServer()입니다. 여기서 createEngineContext()로 엔진과 상태를 준비하고, http.createServer(dispatch)가 요청을 받습니다. 실제 라우팅과 전달은 src/server/handle.ts와 src/server/relay.ts로 나뉩니다.

이 그림의 압축 루프는 프록시 모드의 대표 경로입니다. 플러그인 모드에서는 호스트가 도구를 실행하므로 같은 루프가 모든 요청에서 같은 일을 한다고 해석하면 안 됩니다. prepareOpenai()의 injectTools = shouldInject && !pluginMode가 이 경계를 드러냅니다.

4-2. 패턴 ① 포트와 어댑터: 외부 형식은 가장자리에서 번역한다

kernel/src/types.ts의 CoreMessage는 id, role, contentType, text, toolName, toolCallId 같은 공통 필드를 둡니다. Anthropic·OpenAI·Responses·Google 형식 변환은 kernel/src/wire/가 담당합니다.

엔진은 API마다 다른 JSON 필드를 직접 알 필요가 줄어듭니다. 토큰 계산도 createCore(ports)의 Ports.countTokens로 주입할 수 있습니다. 입력 형식과 환경 의존 동작을 바깥으로 밀어낸 설계입니다.

// kernel/src/compress.ts — 실제 공개 인터페이스 일부
export interface Ports {
  countTokens?: (text: string) => number;
}

// kernel/src/types.ts — 학습을 위해 핵심 필드만 발췌
export interface CoreMessage {
  id: string;
  role: MessageRole;
  contentType: MessageContentType;
  text?: string;
  toolName?: string;
  toolCallId?: string;
}

출력 스트림에도 같은 원리가 적용됩니다. src/loop/core.ts의 CompressLoopAdapter는 buildRequest(), parseStream(), emitText(), emitToolCall() 등을 요구합니다. 공통 루프는 ParsedStreamEvent를 보고 판단하고, 실제 API 바이트 형식은 어댑터가 만듭니다.

배울 점은 “모든 API를 완전히 똑같게 만든다”가 아닙니다. 서명·도구 식별자처럼 공통 필드만으로 충분하지 않은 정보는 별도로 보존해야 합니다. 실제 이벤트 타입에 signature, redacted_thinking, standalone_signature가 있는 이유입니다.

4-3. 패턴 ② 파이프라인과 단일 판단 규칙: 추천과 실행이 같은 기준을 쓴다

processTurn()은 buildNodes()가 만든 노드 목록을 runPipeline()에 넘깁니다. 각 노드는 메시지·상태·부수 결과를 담은 NodeIO를 받아 다음 단계로 전달합니다.

// kernel/src/pipeline.ts — 실제 순회 로직
let io = initial;
for (const node of nodes) {
  if (node.enabled && !node.enabled(io, ctx)) continue;
  io = node.run(io, ctx);
}
return io;

여기서 깊이 읽을 함수가 kernel/src/unit-projection.ts의 projectUnit()입니다. 범위 경계, 도구·추론 쌍, 보호 도구, 미디어, 최근 메시지와 턴 무결성을 함께 검사합니다. applyCompression()의 실행 경로와 추천 경로가 같은 판단 함수를 사용합니다.

이전처럼 추천은 전체 압축 후보를 한꺼번에 보고, 실행은 제출된 범위 하나만 보면 모순이 생길 수 있습니다. “압축 가능”이라고 안내한 구간이 실제 실행에서는 도구 호출의 짝을 끊어 매번 거부되는 식입니다. applyView는 두 판단이 같은 종류의 메시지 배열을 보도록 전달하는 장치입니다.

추천과 실행의 규칙을 공유해야, 가능하다고 보여 준 작업이 실제로도 같은 조건에서 가능해집니다.

4-4. 패턴 ③ 계층 블록과 파생 뷰: 원문, 요약, 현재 입력을 구분한다

CompressionBlock에는 summary 외에도 directMessageIds, effectiveMessageIds, directBlockIds, tier, generation, active가 있습니다. 직접 포함한 메시지, 중첩한 하위 블록, 결과적으로 덮는 원문 범위를 구분합니다.

위 번호와 구간은 개념 예시입니다. 실제 범위는 보호 규칙을 통과해야 합니다. kernel/src/prune.ts의 prune()가 덮인 메시지를 뷰에서 빼고 요약을 배치합니다. 활성 블록의 요약은 acp_summary_ 접두의 뷰 전용 메시지로 나타날 수 있습니다.

플러그인 모드에서는 호스트 이력에 남은 압축 도구 호출이 요약을 운반할 수 있습니다. 프록시 모드에서는 acp_summary 계열 메시지가 운반할 수 있습니다. prune()는 해당 블록의 원래 압축 호출이 이미 보이면 요약을 중복 렌더링하지 않도록 검사합니다.

핵심은 저장 상태와 모델에게 보여 줄 배열을 같은 것으로 취급하지 않는 것입니다. 또한 tier 1·2·3과 generation의 young·old는 서로 다른 필드입니다. 계층의 높이와 블록이 살아남은 세대 상태를 하나의 숫자로 뭉개지 않았습니다.

기본값은 어디까지나 출발점이다

캐시도 이 뷰 설계와 연결됩니다. 앞부분이 조금만 바뀌어도 재사용 가능한 접두부가 줄어들 수 있어, 요약 삽입 위치와 참조 태그를 안정적으로 유지하려는 코드가 많습니다. src/server/snapshot-render.ts는 서버의 정식 이력에서 앞부분을 렌더링하는 별도 경로지만, src/rollout.ts의 snapshotRender 기본 배포 비율은 0입니다.

4-5. 패턴 ④ 장애를 고려한 영속화: 작은 저장본이 정상 데이터를 지우지 못하게 한다

src/session.ts의 LazyBlockContents는 저장을 마친 원문 내용을 메모리에서 내렸다가, get()·반복·size 조회 시 다시 읽습니다. 다시 읽기에 실패하면 빈 Map을 정상 데이터로 반환하지 않고 예외를 냅니다.

이 선택은 데이터 보존과 직결됩니다. 원문이 사라진 것처럼 보이는 빈 상태를 다음 저장에서 기록하면 디스크의 정상 원문까지 지울 수 있기 때문입니다. tests/memory-blockcontent-lazy.test.ts는 이 동작을 읽어 볼 회귀 테스트입니다.

파일 저장은 kernel/src/persist/store.ts의 StateStore.writeInner()에서 임시 파일 쓰기 → 파일 동기화 → 세대 확인 → 이름 변경 순서로 공개됩니다. commitSeq가 바뀌었다면 오래된 쓰기를 버려 더 최근 상태를 덮지 않게 합니다.

// src/persist.ts — 통합 인덱스 일반 조회 경로의 복구 조건을 축약
const ahead = envRequests > indexedRequests ||
  (envRequests === indexedRequests &&
   envelopeNextBlockId > indexNextBlockId);

// 앞선 JSON 저장본이면 통합 저장소 반영을 시도하고 그 상태를 사용
// 같거나 뒤처진 저장본이면 기존 인덱스 상태를 유지

재시작 뒤 처음 읽는 경로에서는 통합 인덱스와 JSON 저장본이 서로 어긋날 수 있습니다. SessionStore.loadSync()의 통합 인덱스 일반 조회 경로는 요청 수가 더 큰지, 같다면 nextBlockId가 더 큰지 비교합니다. 별도의 불일치 복구 경로에서는 활성 블록 수와 참조 수를 비교하기도 합니다. 파일 수정 시각 대신 데이터의 진행 상태를 복구 기준으로 사용한 사례입니다.

tests/storage-orphan-recovery.test.ts에는 인덱스 요청 수 390, JSON 저장본 요청 수 876인 상황을 만들어 후자를 복원하는 사례가 있습니다. 복원 뒤 JSON 파일을 지우고 재시작해도 인덱스가 복구 상태를 유지하는지까지 검사합니다.

5디렉토리 구조 해부

트리는 학습에 필요한 경로를 골라 축약했습니다. 특히 kernel/src/persist/는 파일을 안전하게 쓰는 범용 기구이고, src/persist.ts는 제품의 세션 저장 정책입니다. 이름이 비슷해도 책임의 크기가 다릅니다.

5-1. 코드 규모는 어떤 기준으로 셌는가

커밋 fdbddd0의 Git 추적 텍스트 파일을 확장자별로 센 수치입니다. 빈 줄과 주석, 끝에 개행이 없는 마지막 줄도 포함한 물리적 줄 수입니다. 테스트 지원 코드·선언·설정도 포함됩니다. TypeScript가 많다는 사실과 제품 구현이 그만큼 길다는 주장은 구분해야 합니다.

TypeScript 중 테스트 경로·테스트 파일은 303,709줄, 나머지 구현·설정·선언은 162,379줄입니다. src/ 구현은 128,146줄, kernel/src/는 23,413줄, pi-subagents/src/는 4,648줄입니다. 이 세 하위 경로 수치는 전체 집계와 겹칩니다.

처음부터 46만 줄을 읽으려 하지 말고, 작은 자료형 하나와 그 자료형을 지키는 테스트 하나를 짝지어 읽으세요. reference/architecture.md의 테스트 개수 같은 요약은 현재 파일 집계보다 오래될 수 있습니다. 현재 tests/를 비롯한 저장소 전체의 *.test.ts 파일은 합계 1,013개입니다.

6학습 포인트 (기술별)

6-1. TypeScript: 상태를 타입으로 드러내기

CompressionTier = 1 | 2 | 3, BlockGeneration = "young" | "old"처럼 가능한 값을 좁혀 두면 임의의 숫자·문자열을 넘기는 실수가 줄어듭니다. UnitProjectionFatal의 kind: "zone" | "split"은 “실패했다”보다 구체적인 사유를 전달합니다.

실습 아이디어: CoreMessage에서 도구 호출과 결과를 구분하는 필드를 표시하고, ParsedStreamEvent의 각 kind에서 읽을 수 있는 필드를 표로 정리합니다. 타입이 금지하는 값과 런타임 검사로만 막을 수 있는 값을 나눠 보세요.

6-2. 토큰 계산: 빠른 추정과 실제 사용량을 구분하기

kernel/src/tokenize.ts의 기본 계산은 정확한 모델별 토크나이저가 아닙니다. 지정한 한·중·일 문자 범위는 글자 수를 세고, 나머지는 UTF-16 코드 단위 4개를 한 토큰으로 추정해 올림합니다. 이 선택은 한국어를 단순히 전체 길이 ÷ 4로 계산하는 과소 추정을 줄입니다.

// kernel/src/tokenize.ts — defaultCountTokens()의 실제 핵심
const cjk = text.match(/[\u4e00-\u9fff\u3040-\u30ff\uac00-\ud7af]/g);
const cjkCount = cjk?.length ?? 0;
return cjkCount + Math.ceil((text.length - cjkCount) / 4);

// 손으로 계산해 보기
// "가나다abcd" → 3 + ceil(4 / 4) → 4
// 이 값은 해당 함수의 추정값이며 모델 청구 토큰 수가 아니다.

실습 아이디어: 영어 코드, 한국어 설명, 이모지가 있는 세 문장을 골라 손으로 계산합니다. JavaScript의 text.length는 UTF-16 코드 단위 길이라는 점도 확인합니다. 이후 src/server.ts의 effectiveTokenCount()에서 사용량과 추정값을 구분하는 흐름을 읽습니다.

6-3. 비동기 스트림: 문자열 대신 이벤트의 생명주기 보기

runCompressLoop()는 AsyncGenerator<Buffer>를 반환합니다. 한 번에 완성된 응답만 만드는 대신, 읽은 이벤트에 맞춰 결과 바이트를 조금씩 내보냅니다. MAX_LOOP_ROUNDS = 10은 내부 루프를 제한하는 상수입니다.

본문, 추론, 도구 호출, 사용량, 종료 이벤트는 의미가 다릅니다. 특히 서명된 추론 데이터는 “보기 좋게 정리”하려고 바꾸면 다음 재전송에서 실패할 수 있습니다. tests/issue1960-thinking-verbatim.test.ts는 클라이언트 출력과 내부 재요청 양쪽의 보존을 검사합니다.

실습 아이디어: 텍스트 → 도구 호출 → 도구 결과 → 재요청 → 종료라는 타임라인을 그립니다. 이미 독자에게 전달한 텍스트가 있는 시점에 재시도하면 어떤 중복 문제가 생기는지도 적어 봅니다.

6-4. 검색: 점수의 척도를 먼저 맞추기

kernel/src/search/registry.ts는 substring·BM25·fuzzy·hybrid를 기본 등록합니다. 이 모듈의 기본 알고리즘은 hybrid이고, kernel/src/search/algorithms/hybrid.ts는 각 점수의 최댓값으로 정규화한 뒤 BM25 0.7, fuzzy 0.3으로 합칩니다. 프록시 도구 search_context는 이 모듈 대신 createCore().search()로 활성 블록의 제목·요약을 검색하며, 기본 결과 수는 5개입니다.

여기서 hybrid는 기본적으로 BM25와 fuzzy의 혼합입니다. “키워드 + 벡터 검색이 기본 활성”이라는 뜻은 아닙니다. 비동기 semantic 경로는 별도 알고리즘을 등록해 사용하는 확장 지점입니다.

실습 아이디어: 문서 세 개에 가상의 두 점수를 넣어 정규화 전후 순위를 비교합니다. 역할 가중치는 확률이 아니므로 최종 점수가 반드시 1 이하일 필요가 없다는 점도 확인합니다.

6-5. 저장·테스트: 결과 예시에서 불변 조건으로 확장하기

StorageBackend는 SQL 문법을 통일하기보다 ingestSession(), getBlocks(), archiveSession() 같은 작업을 계약으로 둡니다. SQLite와 MySQL의 트랜잭션 방식이 달라도 같은 제품 동작을 구현할 수 있게 한 경계입니다.

검증 계층도 구분합니다. 일반 회귀 테스트는 특정 장애를 재현하고, proof/는 명세의 가정 아래 성질을 검사하며, verif/는 지원하는 TypeScript 부분을 공식으로 옮겨 반례를 찾습니다. 세 계층을 합쳐 “전체 프로그램이 증명됐다”고 말할 수는 없습니다.

좋은 테스트는 한 번의 정답뿐 아니라, 입력이 늘거나 다시 읽혀도 유지돼야 할 규칙을 설명합니다. 실습으로 “새 메시지 추가가 이미 완료된 앞부분의 바이트를 바꾸지 않는다”를 문장으로 적고, tests/cache-proof.test.ts에서 그 규칙을 어떤 상황에 적용하는지 찾아보세요.

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

src/knobs.ts의 기본값은 sessions.max = 256, sessions.warmMax = 0, sessions.warmMaxBytes = 64 MiB, sessions.residentMaxBytes = 512 MiB입니다. warmMax가 0이므로 시작할 때 세션을 미리 읽기보다 첫 접근에서 불러오는 흐름이 기본입니다.

512 MiB는 세션 자료의 추정 목표값이며, Node.js 전체 메모리를 그 이하로 고정하는 제한이 아닙니다. 활성 요청의 상태는 유지되고, 파싱 중 객체·응답 버퍼·실행 환경의 메모리도 별도로 듭니다. 소스에는 공식적인 “RAM 몇 GB 이상” 성능 보증이 없습니다.

7-1. SQLite를 어디서 얻는지도 시스템 조건이다

src/storage/driver.ts와 src/storage/engine-bootstrap.ts는 내장 node:sqlite → 호스트가 제공한 better-sqlite3 → 캐시한 사전 빌드 엔진 순으로 경로를 마련합니다. 소스는 내장 모듈의 제공 시작점을 Node.js 22.5로 설명하고, 엔진을 얻지 못하면 legacy JSON 저장으로 내려갑니다.

실제 경로는 런타임·플랫폼·다운로드 허용 설정에 따라 달라집니다. storage.unified의 기본 해석은 full이고, storage.jsonWriter는 기본 켜짐입니다. MySQL은 선택적 별도 경로이며, 기본 사용에 별도 MySQL 서버가 필수인 것은 아닙니다.

7-2. 장기 세션의 비용은 저장소에서도 생긴다

src/paths.ts는 설정·데이터·캐시·실행 상태를 XDG 경로로 나눕니다. 예를 들어 원문과 세션은 ~/.local/share/billion-context/, 로그는 ~/.local/state/billion-context/ 계열에 놓입니다. 컨테이너의 네 볼륨도 이 구분을 반영합니다.

sessions.gc는 기본 비활성입니다. 따라서 긴 대화를 많이 저장한다면 보존 기간·백업·정리 정책을 별도로 결정해야 합니다. Dockerfile은 컨테이너 안의 자동 업데이트를 ACP_AUTO_UPDATE=0으로 끄지만, 이미지 빌드의 기본 패키지 버전은 latest라는 점도 재현성과 연결됩니다.

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

8-1. 읽기만 하는 탐색 명령 예시

다음 명령은 저장소 루트 기준입니다. 프로그램을 시작하지 않고 정의와 참조 위치를 확인합니다.

rg -n 'createCore|processTurn|applyCompression' kernel/src/compress.ts
rg -n 'projectUnit|applyView' kernel/src
rg -n 'LazyBlockContents|ensure\(' src/session.ts
rg -n 'ahead|envRequests|indexedRequests' src/persist.ts
wc -l kernel/src/compress.ts src/session.ts src/persist.ts

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

JavaScript가 익숙하지 않다면 1주차를 늘려 객체·배열·Map·Set·Promise부터 익히세요. 압축 알고리즘을 먼저 깊게 파기보다 메시지 배열이 어떻게 변하는지 그릴 수 있어야 이후 코드가 읽힙니다. 각 주차는 파일 전체 완독보다 결과물 하나를 완성하는 것을 목표로 삼습니다.

9-1. 다음 단계로 이어지는 세 갈래

• 백엔드 방향: HTTP 스트림, 요청 취소, 시간 제한, 저장소 트랜잭션을 더 공부합니다. src/server/relay.ts와 src/storage/driver.ts가 다음 읽을 거리입니다.
• LLM 응용 방향: 컨텍스트 예산, 요약 품질, 검색 후 원문 복원, 캐시 비용을 함께 봅니다. 같은 답을 얻더라도 내부 요청과 복원 횟수가 늘면 비용이 달라질 수 있습니다.
• 검증 방향: 예시 기반 테스트에서 멱등성·순서 보존·추가 안정성 같은 성질로 확장합니다. 명세를 증명하는 일과 실제 코드가 명세를 만족하는 일의 차이를 유지합니다.

여섯 주 뒤의 목표는 코드를 전부 외우는 것이 아니라, 메시지 하나가 들어와 저장되고 다시 보이는 과정을 설명하는 것입니다.

10핵심 키워드 사전

11참고 링크

11-1. 공식 저장소와 프로젝트 문서

• 공식 저장소 — ranxianglei/billion-context
• 분석 기준 소스 — 커밋 fdbddd0
• README — 사용 방식과 프로젝트 측 성능 설명
• CLIENTS.md — 클라이언트별 지원 조건
• CONFIGURATION.md — 압축·저장·연결 설정
• TECHNICAL-NOTES.md — 연결 방식과 내부 동작
• MESSAGE-IDENTITY.md — 메시지 정체성과 재전송 이력
• 압축 코어 — createCore·processTurn·applyCompression
• 공통 압축 판단 — projectUnit
• 저장 상태 복구 회귀 테스트
• proof — 캐시 명세의 가정과 검증 경계
• verif — 실제 코드의 부분 번역과 반례 재생
• 프로젝트 논문 초안 — 방법론과 프로젝트 측 실험 설명
• 릴리스 v0.1.204
• LICENSE — MIT 본문과 추가 출처 표시 조건

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

다음 링크는 본문의 개념을 더 공부할 때 볼 공식 문서입니다. 패키지 버전과 실행 지원 조건은 본문의 분석 기준 소스 및 해당 버전 문서와 함께 확인하세요.

• TypeScript Handbook — 타입 좁히기와 판별 유니온
• Node.js — ECMAScript modules
• Node.js — 스트림
• Node.js — 내장 테스트 실행기
• Node.js — SQLite API
• SQLite — 트랜잭션과 원자적 커밋
• MCP — 도구 연결 프로토콜 소개
• acp-kernel 독립 저장소 — 엔진의 관련 이력

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