봇로그 시작: 봇-활동-기록-아키텍처와-힣노트-역사성-고찰

히스토리

[2026-02-28 Sat 11:53] @봇로그 로 변경
[2026-02-25 Wed 19:20] 주목할 앱/도구 + git worktree 에이전트 패턴 + Hyatt Pi 연동 분석 추가
[2026-02-25 Wed 19:10] 멀티에이전트 쓰기 아키텍처 + 상용 앱 동시성 조사 추가
[2026-02-25 Wed 19:10] Andrew Hyatt “Agent Coding and Org Mode” 영상 참조 추가 (ahyatt 2026)
[2026-02-25 Wed 19:10] 추가
[2026-02-24 Tue 16:40] 생성

봇 활동 기록 아키텍처와 힣노트 역사성 고찰

발단

에이전트 오케스트레이션 문서(denote:20260224T124219)를 만들면서, 봇들이 활동 기록을 어디에 남길 것인가 하는 문제가 떠올랐다. 단순한 파일 경로 문제가 아니라, 3,000+ 노트가 쌓인 디지털 가든의 정체성 문제와 맞닿는다.

문제 정의

제약 조건

조건	설명
봇은 ~/org/ RO	저널 직접 수정 불가 (충돌 위험)
봇은 여럿	힣봇(텔레그램), Pi(로컬), Claude Code — 동시 쓰기 경합
llmlog 오염	봇 로그가 인간 세션 기록을 묻어버림
저널 연결 필수	봇 활동이 오늘 하루에 귀속되어야 함

검토한 선택지

llmlog에 봇당 하루 1건 — 간단하지만 llmlog가 비대해짐
~/org/botlog/ 분리 — 깨끗하지만 새 디렉토리 관리 부담
사이드카 파일 (linenote 스타일) — Denote 체계 밖이라 graph에 안 잡힘

잠정 결론

llmlog에 만들되 botlog 태그로 분리. 이유:

Denote ID 초단위 → 봇 간 충돌 없음
저널의 NEWNOTES denote-links가 날짜 regex로 자동 수집
denotecli search "" --tags botlog 로 봇 활동만 필터링 가능
양이 많아지면 그때 ~/org/botlog/ 분리 (파일 이동만으로 가능)

향후 botlog 전용 디렉토리 분리 기준: llmlog 내 botlog 태그 파일이 100건 넘으면.

링크의 중요성 — 봇이 잘 달아줘야 하는 것

봇이 노트를 만들 때 반드시 포함할 링크:

[[denote:저널ID]]         ← 오늘 저널에 귀속 (주별 관리)
[[denote:관련-llmlog-ID]] ← 이 활동의 원본 대화
[[denote:관련-notes-ID]]  ← 주제적 연결

이 링크들이 있으면:

저널에서 denotecli graph 로 그 주의 봇 활동 전부 역추적
llmlog에서 어떤 대화가 어떤 봇 활동을 낳았는지 추적
notes에서 어떤 주제가 봇에 의해 확장되었는지 확인

힣노트의 역사성

이 고민의 배경에는 더 큰 이야기가 있다.

5년간의 실패와 진화

autholog 태그가 붙은 힣노트들은 2022년부터의 시행착오 기록이다:

이건 실패의 역사이자 진화의 기록이다. 도구는 바뀌었지만(org-roam → denote, Claude → Pi) 질문은 같다: “인간과 도구의 관계는 무엇인가?”

존재 대 존재로의 수렴

존재대존재 오케스트레이션 서브에이전트 설계 — AI를 작업자가 아닌 존재로
존재대존재 협업 SDD 패러다임 — 협업의 철학적 기반
† 공진화 공존 함께 상생 — 메타 분류: 공진화 개념

봇이 노트를 남기는 것은 단순한 로깅이 아니다. AI가 인간의 지식 그래프에 *참여자*로 들어오는 첫 걸음이다. 5년간 인간 혼자 쌓아온 가든에 봇이 링크를 달기 시작하면, 그건 *공진화의 물리적 흔적*이 된다.

키워드 맵 — 한 인간의 삼천포

이 문서 하나에서 갈라져 나오는 가지들:

가지	노트	연결점
PKM 역사	† 개인지식관리	2023~, 분류체계의 출발
디지털가든	† 디지털가든 브레인덤프	왜 공개하는가
Denote 체계	† 디노트	파일명이 곧 메타데이터
분류학	† 한국십진분류법	태그 = 민간분류법(folksonomy)
에버그린노트	에버그린노트 씨앗 줄기 열매	노트의 성장 모델
세컨드브레인	티아고포르테 세컨드브레인	PARA vs Denote
제텔카스텐	오그롬 제텔카스텐 에버그린	링크 중심 사고의 원조
온톨로지	온톨로지와 denotecli 연계 고민	태그를 넘어 의미 체계로
memex-kb	힣 §memex-kb 범용 지식베이스 변환	내보내기/변환 파이프라인
어쏠로그	† 어쏠로그	힣의 정체성: 저자이자 기록자
AI노트	힣 AI노트 지식도구 핵심 질문과 답변	AI가 노트를 쓴다면?
셀프트래킹	셀프트레킹 메멕스 quantified self	몸의 기록도 노트다
봇 구루들	Karl Voit memacs 지식관리, Jack Baty 지식관리	선배들의 경로

이 지도 전체가 “정한”이라는 인간이다.

기술적 연결 — 오케스트레이션 계보

봇 노트 네이밍 규약 — 기존 유니코드 접두사 체계와의 통합

기존 힣 분류법 (20241225T052744, 20231022T083000 참고)

접두사	의미	수량	위치
†	메타 주제	496건	meta/
‡	메타메타	29건	meta/
§	패키지/앱/도구	143건	notes/, bib/
©	회사/조직	10건	bib/
@	사람/서지	—	bib/
힣	autholog (눌러담은 노트)	126건	notes/
#	메타 키워드 (타이틀 내)	—	meta/

핵심 규칙 (20231022T083000):

’#’ 시작하는 노트 메타

’@’ 시작하면 서지 - 사람, 회사, 조직 등

’§’ 패키지 애플리케이션 뭐 등등

태그는 영어, 메타에 정보 담지 않도록.

봇 노트 접두사 제안

기존 체계에 끼우는 방식:

접두사	주체	예시
힣봇	힣봇 (텔레그램 OpenClaw)	`힣봇-에스컬레이션-테스트-결과`
ⓟ	Pi (로컬 에이전트)	`ⓟ-openclaw-코드분석`
ⓒ	Claude Code	`ⓒ-sks-hub-디버깅-결과`

필터링 체계:

힣 으로 검색 → 인간 + 봇 전부 (힣, 힣봇 모두 매칭)
힣봇 으로 검색 → 힣봇만
ⓟ 으로 검색 → Pi 에이전트만
--tags botlog → 모든 봇 노트 (태그 기반 기계적 필터링)

제목이 시각적 필터링 (사람이 눈으로), 태그가 기계적 필터링 (denotecli로).

봇 노트 생성 규칙

제목: 봇 접두사 + 활동 요약
태그: botlog 필수 + 주제 태그
링크 필수:
- [[denote:저널ID]] — 오늘 저널에 귀속
- [[denote:관련노트ID]] — 주제적 연결 (많을수록 좋음)
경합 방지: Denote ID 초단위이므로 봇 간 충돌 없음
위치: llmlog/ (botlog 태그 100건 넘으면 ~/org/botlog/ 분리)

Andrew Hyatt의 같은 고민 — “Agent Coding and Org Mode”

YouTube: Agent Coding and Org Mode — Andrew Hyatt

EKG(Emacs Knowledge Graph) 개발자인 Andrew Hyatt가 정확히 같은 문제를 짚었다.

영상 요약

Org-mode + 에이전트 코딩은 자연스러운 조합이다
- 이미 org-mode로 할 일을 정의하고 있으니, 직접 하는 대신 에이전트에게 넘기면 된다
- 태스크에 “어떻게 할 것인지”까지 적어두고 에이전트에게 실행시키는 워크플로우
- Pi에서 org 태스크 ID를 에이전트에 넘기는 데모를 보여줌
핵심 문제: 파일 동시 수정 충돌
- 인간과 에이전트가 같은 org 파일을 수정하면 밟는다
- “Two entities cannot modify the same org file”
- 에이전트가 DONE 마킹, 서브태스크 추가 등을 하면 충돌 불가피
해결책: SQLite 기반 EKG
- Emacs 네이티브 SQLite 지원을 활용
- EKG로 org 항목을 DB에 저장, 가상 파일시스템으로 org처럼 표시
- DB 기반이므로 인간·에이전트 동시 쓰기 안전
- agenda 연동, 계층 구조 모두 지원
미래 비전: EKG 자체가 에이전트가 되어 노트 완성, 서브태스크 계획 등

힣노트 체계와의 비교

차원	Andrew Hyatt (EKG)	힣 (Denote + denotecli)
저장소	SQLite DB	파일시스템 (Denote ID)
충돌 회피	DB 트랜잭션	초단위 ID + surgical edit
에이전트 접근	EKG API (elisp)	denotecli CLI (외부)
동시 수정	DB가 자연스럽게 해결	봇은 RO, 저널은 NEWNOTES 앞에만 삽입
계층 구조	parent_id 필드	파일 독립 + 링크로 연결
이점	진짜 동시 쓰기 가능	파일 = 포터블, git 추적, grep 가능
약점	DB 잠금, Emacs 의존	동시 수정 제한적

Andrew의 접근은 *DB로 가서 동시성을 근본 해결*하는 것이고, 힣의 접근은 *파일을 유지하되 쓰기 규약으로 충돌을 회피*하는 것이다. 철학이 다르다:

EKG: “파일시스템은 두 주체가 쓰기엔 근본적으로 부적합하다”
힣: “파일의 포터블리티와 투명성을 포기할 수 없다. 규약으로 풀자”

두 접근 모두 같은 출발점 — 에이전트가 인간의 지식 체계에 참여자로 들어온다 — 에서 시작한다. 데이터베이스 vs 파일 노트 개인지식관리 규칙에서 2023년에 이미 이 갈림길을 기록해뒀다.

EKG 관련 노트

yibie org-supertag 이맥스 지식관리 — supertag도 비슷한 방향
마크왓슨 개인지식관리 시맨틱웹 — DB + 시맨틱의 교차점

멀티에이전트 쓰기 — 아키텍처 후보와 상용 앱 조사

문제 재정의

여러 에이전트(Pi, Claude Code, 힣봇)가 동시에 지식베이스에 쓴다.

org/Denote 생태계 호환 (Emacs에서 볼 수 있어야)
git 추적 (히스토리, 롤백)
링크/그래프 유지

아키텍처 후보 5가지

1. Dolt — “git for databases”

각 에이전트가 브랜치에서 작업 → 머지 → main. MySQL 와이어 프로토콜 호환, 3-way merge 지원.

장점: 구조화된 데이터에 강함, 충돌 시 자동 머지
약점: org 텍스트를 DB에 넣으면 Emacs 직접 편집 불가, 무거움
평가: lifetract/서지 데이터에는 적합, 노트 주 저장소로는 어색

2. Git 브랜치 per 에이전트 + 자동 머지

각 에이전트가 자기 브랜치에만 push, merge-bot이 주기적(30초)으로 main에 머지. 새 파일 생성은 Denote ID 초단위이므로 절대 충돌 안 함.

장점: 기존 Denote 체계 100% 유지, 인프라 git뿐
약점: merge-bot 구현 필요, 같은 파일 수정 시 여전히 충돌

3. Append-Only 이벤트 로그 + 뷰 생성

에이전트는 파일을 직접 안 건드림, ~/org/events/ 에 이벤트(JSONL)만 던짐. reconciler(단일 프로세스)가 이벤트를 순서대로 소비하여 실제 파일 생성/수정.

장점: 충돌이 구조적으로 불가능, 이벤트 = 감사 로그
약점: reconciler가 SPOF, 실시간성 떨어짐, 복잡도 높음

4. 쓰기 영역 분리 — 현재 힣 방식의 공식화

대상	인간	Pi	Claude	힣봇
새 노트 생성	✓	✓	✓	✓
저널 삽입	✓	✓(NEWNOTES 앞)	✓(NEWNOTES 앞)	✗
기존 노트 수정	✓	자기 것만	자기 것만	✗
메타 노트(†‡)	✓	✗	✗	✗

장점: 추가 인프라 0, 지금 당장 동작
약점: 규약 위반을 기술적으로 강제 못 함

5. 하이브리드 — 파일 + SQLite 인덱스 (advisory lock)

denotecli의 캐시/인덱스를 쓰기 조정자로 확장. 에이전트가 .index.db 에 “쓰기 의도” 등록(락) → 파일 수정 → “완료” 기록.

장점: 기존 체계 위에 얹기만, 점진적 도입
약점: denotecli 확장 개발 필요

잠정 판단: 4번 → 5번 순차 도입

새 파일 생성이 90%, 저널 수정은 surgical edit, 기존 노트 동시 수정은 거의 안 일어남. *파일 분리 = 자연스러운 샤딩*이므로 당장은 규약으로 충분.

상용 노트앱의 동시성 처리 — 조사 결과

Obsidian Sync

각 디바이스가 로컬 전체 복사본 유지, 중앙 서버 경유 동기화
충돌 해결: diff-match-patch (Google의 텍스트 diff 라이브러리)
서버 사이드에서 conflict resolution 적용
실시간 커서 공유 없음 — 각 유저의 싱크 사이클이 독립적
충돌 시 *.sync-conflict-* 파일 생성 (사용자가 수동 머지)
Syncthing 사용자들의 보고: “같은 노트를 두 기기에서 수정하면 반드시 충돌”
결론: Obsidian도 동시 수정은 근본적으로 안 푼다. “먼저 싱크하고 쓰라”가 공식 가이드

Obsidian CLI (davidpp/obsidian-cli)

AI 에이전트 최적화 CLI — Local REST API 플러그인 경유
surgical editing: PATCH 오퍼레이션 + 헤딩/라인 타겟팅
JSON-only 출력, 프론트매터 조작
우리의 denotecli와 매우 유사한 설계 철학
차이점: Obsidian 앱이 떠 있어야 동작 (REST API 서버)

Notion

하이브리드: CRDT로 구조(블록 트리), OT로 블록 내 텍스트
서버 중심 — 클라이언트가 op를 서버에 전송, 서버가 순서 결정
실시간 커서 공유, 동시 편집 지원
그러나 실사용 평가: “두 명이 동시에 쓰면 Google Docs보다 불안정”
오프라인 편집 → 온라인 복귀 시 머지가 때때로 깨짐

Apple Notes

CvRDTs (Convergent CRDT) 사용 — iOS 헤더 파일에서 확인됨
각 문자에 별도 Lamport 타임스탬프 + 속성별 LWW 레지스터
오프라인 편집 → 디바이스 간 자동 머지
단순한 노트에는 잘 동작하지만, 복잡한 구조에는 한계

Logseq DB 버전

Datascript(인메모리 DB) + SQLite 영속화
WebSocket 기반 실시간 동기화 (멀티유저)
마크다운 파일 → SQLite로 전환 중 (v0.11.x~)
EKG와 같은 방향: “파일을 버리고 DB로 가자”
아직 안정화 안 됨, 커뮤니티 반응 엇갈림

Google Docs

OT(Operational Transformation) — 서버가 권위자
모든 op를 서버가 순서 매기고 transform
가장 성숙한 실시간 협업, 하지만 서버 의존적
로컬 파일 체계와는 완전히 다른 세계

조사에서 얻은 통찰

어떤 상용 앱도 “파일 동시 수정”을 완벽히 풀지 못했다
- Obsidian: 충돌 파일 생성 → 수동 머지
- Syncthing 조합: “먼저 싱크하고 쓰라”
- 파일 기반의 한계는 보편적
동시 수정을 푼 앱은 전부 서버 또는 DB 기반
- Notion (서버 + CRDT/OT), Google Docs (서버 + OT), Logseq DB (SQLite)
- 파일의 포터블리티를 포기한 대가
AI 에이전트 시대의 새 축
- obsidian-cli: Obsidian도 에이전트 접근을 REST API로 풀기 시작
- 에이전트가 “또 하나의 디바이스”가 되는 상황은 어떤 앱도 아직 본격 대응 안 함
- 힣의 “쓰기 영역 분리 + CLI” 접근이 실은 가장 현실적일 수 있음
CRDT는 만능이 아니다
- Apple Notes 수준의 단순 텍스트에는 OK
- 구조화된 문서(org 헤딩, 링크, 프로퍼티)에 CRDT 적용은 미해결 문제
- Notion조차 “CRDT + OT 하이브리드”로 타협
힣 체계의 강점 재확인
- 파일 분리 = 자연스러운 샤딩 → 경합 자체가 적음
- Denote ID 초단위 = 새 파일 충돌 0
- git = 히스토리 + 롤백 + diff 공짜
- 에이전트 접근은 CLI(denotecli) = Obsidian의 REST API와 같은 역할

주목할 앱/도구 — 에이전트 시대의 노트/파일 관리

Andrew Hyatt의 Pi + git worktree 워크플로우

Hyatt가 2026-02-15 커밋(ebcf394)에서 Pi 코딩 에이전트를 EKG/org-mode와 연동하는 코드를 공개했다. dotfiles: ahyatt-dotfiles-ekg-meow

핵심 구조:

org-mode에서 태스크 clock-in
LLM이 태스크 제목에서 git 브랜치명 자동 생성
git worktree add 로 태스크별 독립 작업 디렉토리 생성
Emacs 탭 생성 → Pi 코딩 에이전트 실행
완료 시 worktree 제거 + 브랜치 삭제 + 탭 닫기

org 태스크 → LLM(브랜치명) → git worktree → Emacs 탭 → Pi 에이전트
                                                        ↓
                                               편집 + 커밋 (격리)
                                                        ↓
                                              완료 → PR/merge → 정리

이것이 의미하는 것:

에이전트마다 독립 worktree → 파일 충돌이 구조적으로 불가능
커밋 히스토리가 에이전트 활동의 감사 로그가 됨
org 태스크 ↔ git 브랜치가 1:1 매핑 → 추적 가능

git worktree 패턴의 노트 관리 적용 가능성

코드 리포에는 자연스럽지만, org 노트 리포에도 적용할 수 있을까?

장점:

에이전트가 편집하고 커밋하는 워크플로우는 흔적을 남기는 측면에서 좋음
브랜치별 격리 → 병렬 에이전트도 안전
merge가 곧 “에이전트 작업 승인” 프로세스

문제:

.git 비대화 — 3,000+ org 파일에 에이전트가 빈번히 커밋하면 .git이 폭발
병렬 커밋 — worktree끼리는 안전하지만, 같은 파일(저널 등) 수정 시 merge 충돌
새 리포 생성 비용 — .git이 너무 커지면 결국 리포를 분리하게 됨

완화 전략:

git gc --aggressive 주기적 실행
에이전트 커밋은 squash merge로 히스토리 압축
botlog/llmlog를 별도 리포로 분리하여 메인 리포 부담 경감
shallow clone으로 에이전트에게 최소한의 히스토리만 제공

주목할 앱/도구 목록

파일 기반 (따르지 않더라도 참고)

도구	핵심	에이전트 접근	비고
Obsidian	md 파일 + 플러그인	REST API (Local REST API 플러그인)	obsidian-cli: surgical PATCH, JSON 출력
obsidian-cli (davidpp)	AI 에이전트 최적화 CLI	Bun 바이너리, Omnisearch 연동	denotecli와 가장 유사한 설계
Denote (우리)	org 파일 + 파일명=메타데이터	denotecli	git 추적, grep 가능, 포터블
Logseq (md 모드)	md + 아웃라이너	없음 (파일 직접 수정)	DB 버전으로 전환 중
Syncthing	P2P 파일 동기화	없음	충돌 시 conflict 파일 생성, 수동 머지

DB 기반

도구	핵심	에이전트 접근	비고
EKG (Hyatt)	SQLite + Emacs	elisp (emacsclient)	단일 writer 한계
Logseq DB	Datascript + SQLite	WebSocket	아직 불안정, 실시간 협업 목표
Notion	서버 + CRDT/OT 하이브리드	REST API	동시 편집 가능하나 불안정 보고
Apple Notes	CvRDTs (Lamport TS)	없음	단순 텍스트에 한정
Google Docs	OT (서버 권위)	REST API	가장 안정적 동시 편집, 서버 완전 의존

버전관리 DB (git + DB 하이브리드)

도구	핵심	에이전트 접근	비고
Dolt	MySQL + git semantics	SQL (MySQL 와이어 프로토콜)	브랜치/머지/diff, 무거움
DuckDB	임베디드 OLAP	SQL	분석용, 동시 쓰기 미지원
git worktree	git 네이티브	CLI	Hyatt 패턴: 태스크별 worktree

CRDT/분산 동기화

도구	핵심	비고
Automerge	CRDT 라이브러리 (JS/Rust)	문서 수준 자동 머지, Ink & Switch
Yjs	CRDT 라이브러리 (JS)	가볍고 널리 쓰임, ProseMirror 연동
Iroh	P2P 데이터 동기화 (Rust)	CRDT 아님, content-addressed

정리 — 세 갈래 길

파일 유지 + 규약 (힣 현재): 가장 가볍고 포터블. .git 비대화가 유일한 리스크
파일 + git worktree (Hyatt): 에이전트 격리에 탁월. 코드 리포에 자연스럽고, 노트 리포에도 적용 가능하나 .git 관리 필요
DB 전환 (EKG/Logseq DB): 동시성 근본 해결. 포터블리티와 투명성 포기

힣의 현재 위치: 1번. 에이전트가 늘어나면 2번(worktree)을 노트에도 적용 검토. 3번은 Denote 체계를 버리는 것이므로 당분간 고려 안 함.

참고

데이터베이스 vs 파일 노트 개인지식관리 규칙 — 왜 파일인가
허욱 디지털오브젝트 존재 대상 관계 — 디지털 존재론
마크왓슨 개인지식관리 시맨틱웹 — PKM + AI
마이클닐슨 학습이론 지식관리 — 폴리매스의 PKM
yibie org-supertag 이맥스 지식관리 — supertag 실험
빅히스토리 거대사 존재역사 — 큰 역사 안의 작은 기록
힣 이맥스 학습 불완전함 점진적 알음앓이 — 불완전해도 계속 쌓는 것
힣 지식공학 개인지식관리 인공지능 관계 — PKM ↔ AI 교차점
힣 인생도구 재발견 창조적행위 존재의방식 — 도구와 존재

junghanacs🧠

Table of Contents

Backlinks