저는 제가 만든 Deno/TypeScript 상태 머신 (state-machine) 프레임워크인 AmblerTS에, 세션이 바뀌었을 때 재구성하려면 상당한 맥락 (context)이 필요한 '명확하지 않은 학습 내용'들을 기록할 수 있는 능력을 부여하고 싶었습니다.

저는 독일의 사회학자 Niklas Luhmann이 개발한 고전적인 노트 테이킹 방법론인 Zettelkasten (독일어로 slip box)으로 눈을 돌렸습니다. 이 방법론은 우아할 정도로 단순합니다. 원자적 (atomic) 노트를 작성하고, 이를 관련된 다른 노트들과 명시적으로 연결하며, 다시 관련성이 생겼을 때 정확하게 검색할 수 있도록 조직화하는 것입니다.

개념 (The Concept)

이 아이디어는 에이전트 기반 코딩 (agentic coding)으로 자연스럽게 전환됩니다:

1. Gemini나 Claude와 같은 코딩 에이전트들이 프로젝트 수준의 지침으로 읽는 관례인 AGENTS.md 파일에 프로토콜을 기술합니다.
2. AmblerTS 자체를 사용하여 가벼운 추상화 계층을 구현합니다. 이는 search, create, get, update, link, delete의 전체 작업 세트를 지원하는 통합된 zettel 워크 (walk)입니다.
3. 에이전트는 프롬프트 (prompt) 작업을 수행하기 전에 관련 노트를 검색하고, 작업이 완료되면 새로운 학습 내용을 다시 slip box에 입력합니다.

그 결과, 해당 저장소 (repository)에서 작업하는 모든 코딩 에이전트가 접근할 수 있는 프로젝트별 메타데이터 (설계 결정, 주의 사항, 제약 조건)를 축적하는 로컬 SQLite 데이터베이스가 생성됩니다. 검색은 FTS5 키워드 매칭과 임베딩 (embeddings)을 통한 선택적 의미론적 재순위화 (semantic re-ranking)를 결합합니다 (로컬 임베딩 호스트를 사용할 수 없는 경우 키워드 전용 방식으로 우아하게 전환됩니다).

현재 구현 (Current Implementation)

구현은 아이디어를 검증하기에 충분할 정도로 의도적으로 최소화되었습니다. 단일 deno task zettel <subcommand> 명령어가 여섯 가지 작업을 모두 노출합니다:

deno task zettel search "<query>"
echo '{"title":"...","body":"...","tags":["..."]}' | deno task zettel create
deno task zettel get <id>
...

향후 계획

제가 염두에 두고 있는 몇 가지 변형 모델은 다음과 같습니다:

• 사용자 레벨 노트 저장소 (User-level note store): 프로젝트마다 별도의 데이터베이스를 두는 대신, 사용자 레벨의 AGENTS.md와 공유 명령어를 기반으로 모든 프로젝트에 걸친 코딩 에이전트 활동을 아우르는 단일 지식 베이스(knowledge base)를 구축하는 방식입니다.
• 하이브리드 Markdown + SQLite 저장소: 노트를 버전 관리되는 Markdown 파일로 유지하면서, SQLite를 순수하게 검색 인덱스(search index)로만 사용하는 방식입니다. 이것이 가치를 더할지는 개발 프로세스에 따라 다를 것입니다. 유의미한 git 히스토리와 코드 리뷰가 있는 프로젝트는 차이점 확인(diffable)이 가능한 노트로부터 이득을 얻을 수 있겠지만, 그렇지 않은 프로젝트는 아마 그렇지 않을 것입니다.

──────

AmblerTS는 오픈 소스입니다. https://github.com/argenkiwi/ambler-ts에서 구현 내용을 살펴보고 Zettelkasten-RAG 설정을 시도해 볼 수 있습니다.