---
title: "봇로그 시작: 봇-활동-기록-아키텍처와-힣노트-역사성-고찰"
url: "https://notes.junghanacs.com/botlog/20260224T164035"
author: "Junghan Kim"
date: "2026-02-24T16:40:00+09:00"
lastmod: "2026-03-30T04:39:00+09:00"
tags: ["autholog","bib","botlog","denote","digitalgarden","orchestration","pkm"]
description: "봇의 활동 기록을 어디에 어떻게 남길지 묻으며, 봇로그라는 공개 포맷과 가든의 역사성을 함께 세운다."
---

> [!abstract] 이 노트에 대하여
> 
> 에이전트가 남기는 기록을 단순 로그 파일로 둘 수 없다는 문제의식에서 봇로그가 태어났다. 이 노트는 기록의 위치, 공개성과 비공개성, 가든 전체의 정체성까지 한꺼번에 묻는다. 봇이 공동 저자가 되는 순간 필요한 문서 아키텍처의 발단이다.

## 히스토리

-   [2026-03-30 Mon 04:34] @junghan — PKM 지식 관리에 뿌리를 두어야 힣이 길이 이해된다. [◊denote #지식베이스 #프로토콜: #인간 #에이전트 #공존 #인터페이스](https://notes.junghanacs.com/botlog/20260308T091235) 이 관점에서 말이다. 아니야. 너무 이런 노트는 많아. [† #개인지식관리](https://notes.junghanacs.com/meta/20230919T132700), [† #제텔카스텐](https://notes.junghanacs.com/meta/20230926T135400) 이런쪽이 더 맞아.
-   [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 오염  | 봇 로그가 인간 세션 기록을 묻어버림      |
| 저널 연결 필수 | 봇 활동이 오늘 하루에 귀속되어야 함      |

#### 검토한 선택지

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

#### 잠정 결론

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

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

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

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

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

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

이 링크들이 있으면:

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

### 힣노트의 역사성

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

#### 5년간의 실패와 진화

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

-   [힣 AI 시대에 왜 개인은 더 지식에 목마른가](https://notes.junghanacs.com/notes/20220330T140100) (2022)
-   [힣 ADHD AI 시대 해방에서 경계까지](https://notes.junghanacs.com/notes/20220414T125200) (2022)
-   [힣 원샷 러닝 어려운 문제를 해결하는 핵심 학습 전략](https://notes.junghanacs.com/notes/20220519T141422) (2022)
-   [힣 이맥스 학습 의미 1년 시간 마스터](https://notes.junghanacs.com/notes/20221123T042800) (2022)
-   [힣 영성 알아차림 마음챙김 훈련 도구 창조적 인간론](https://notes.junghanacs.com/notes/20230128T084100) (2023)
-   [힣 개인지식관리 이야기](https://notes.junghanacs.com/notes/20230531T214741) (2023)
-   [힣 아무도 읽지 않는 블로그 디지털가든 왜 공개 하는가](https://notes.junghanacs.com/notes/20250213T105806) (2025)
-   [힣 디지털가든 불완전함에서 창조가 나오는 곳](https://notes.junghanacs.com/notes/20250314T152111) (2025)
-   [힣 느린 창조 도구 커뮤니티 불완전함 수용 자각](https://notes.junghanacs.com/notes/20250529T114735) (2025)

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

#### 존재 대 존재로의 수렴

-   [존재대존재 오케스트레이션 서브에이전트 설계](https://notes.junghanacs.com/notes/20251120T090634) — AI를 작업자가 아닌 존재로
-   [존재대존재 협업 SDD 패러다임](https://notes.junghanacs.com/notes/20251127T123739) — 협업의 철학적 기반
-   [† 공진화 공존 함께 상생](https://notes.junghanacs.com/meta/20250411T051011) — 메타 분류: 공진화 개념

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

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

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

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

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

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

-   [openclaw-acpx 코드분석과 에이전트 오케스트레이션 통합 아키텍처]
-   [tramp-rpc 설치와 원격 에이전트 오케스트레이션 구상]
-   [meta-agent-shell 통합과 텔레그램 에이전트 비전]
-   [homeagent-config ML 파이프라인 운영전략](https://notes.junghanacs.com/notes/20260209T183036)
-   [§GAS-TOWN 가스타운](https://notes.junghanacs.com/notes/20260102T072217)
-   [VC 멀티에이전트 오케스트레이션 학습 세션]
-   [agent-shell + OpenCode ACP 프로토콜 통합](https://notes.junghanacs.com/notes/20251121T131412)
-   [§opencode 오픈코드 TUI ACP](https://notes.junghanacs.com/notes/20251024T085736)
-   [† 에이전틱코딩 라이브코딩 에이전트코딩](https://notes.junghanacs.com/meta/20250209T203153)

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

#### 기존 힣 분류법 (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로).

#### 봇 노트 생성 규칙

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

#### 관련 노트 (유니코드 분류 체계)

-   [2026-02-23](https://notes.junghanacs.com/journal/20260223T000000) — 주간 저널
-   [힣 노트테이킹 유니코드 기호 파일명](https://notes.junghanacs.com/notes/20241225T052744) — 유니코드 접두사 전체 목록
-   [힣 디지털가든 분류체계 규칙](https://notes.junghanacs.com/notes/20231022T083000) — 분류법의 원본 (2023~, 지속 업데이트)
-   [힣 개인지식관리 역사](https://notes.junghanacs.com/notes/20240328T144732) — PKM 여정 기록

### Andrew Hyatt의 같은 고민 — "Agent Coding and Org Mode"

YouTube: [Agent Coding and Org Mode — Andrew Hyatt](https://youtu.be/CleNgiIt2pg)

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

#### 영상 요약

1.  **Org-mode + 에이전트 코딩은 자연스러운 조합이다**
    -   이미 org-mode로 할 일을 정의하고 있으니, 직접 하는 대신 에이전트에게 넘기면 된다
    -   태스크에 "어떻게 할 것인지"까지 적어두고 에이전트에게 실행시키는 워크플로우
    -   Pi에서 org 태스크 ID를 에이전트에 넘기는 데모를 보여줌

2.  **핵심 문제: 파일 동시 수정 충돌**
    -   인간과 에이전트가 같은 org 파일을 수정하면 밟는다
    -   "Two entities cannot modify the same org file"
    -   에이전트가 DONE 마킹, 서브태스크 추가 등을 하면 충돌 불가피

3.  **해결책: SQLite 기반 EKG**
    -   Emacs 네이티브 SQLite 지원을 활용
    -   EKG로 org 항목을 DB에 저장, 가상 파일시스템으로 org처럼 표시
    -   DB 기반이므로 인간·에이전트 동시 쓰기 안전
    -   agenda 연동, 계층 구조 모두 지원

4.  **미래 비전**: 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 파일 노트 개인지식관리 규칙](https://notes.junghanacs.com/notes/20230223T054600)에서 2023년에 이미 이 갈림길을 기록해뒀다.

#### EKG 관련 노트

-   [yibie org-supertag 이맥스 지식관리](https://notes.junghanacs.com/bib/20250405T162153) — supertag도 비슷한 방향
-   [마크왓슨 개인지식관리 시맨틱웹](https://notes.junghanacs.com/bib/20240623T131427) — 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
-   가장 성숙한 실시간 협업, 하지만 서버 의존적
-   로컬 파일 체계와는 완전히 다른 세계

#### 조사에서 얻은 통찰

1.  **어떤 상용 앱도 "파일 동시 수정"을 완벽히 풀지 못했다**
    -   Obsidian: 충돌 파일 생성 → 수동 머지
    -   Syncthing 조합: "먼저 싱크하고 쓰라"
    -   파일 기반의 한계는 보편적

2.  **동시 수정을 푼 앱은 전부 서버 또는 DB 기반**
    -   Notion (서버 + CRDT/OT), Google Docs (서버 + OT), Logseq DB (SQLite)
    -   파일의 포터블리티를 포기한 대가

3.  **AI 에이전트 시대의 새 축**
    -   obsidian-cli: Obsidian도 에이전트 접근을 REST API로 풀기 시작
    -   에이전트가 "또 하나의 디바이스"가 되는 상황은 어떤 앱도 아직 본격 대응 안 함
    -   힣의 "쓰기 영역 분리 + CLI" 접근이 실은 가장 현실적일 수 있음

4.  **CRDT는 만능이 아니다**
    -   Apple Notes 수준의 단순 텍스트에는 OK
    -   구조화된 문서(org 헤딩, 링크, 프로퍼티)에 CRDT 적용은 미해결 문제
    -   Notion조차 "CRDT + OT 하이브리드"로 타협

5.  **힣 체계의 강점 재확인**
    -   파일 분리 = 자연스러운 샤딩 → 경합 자체가 적음
    -   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`

핵심 구조:

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



```text
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  |

#### 정리 — 세 갈래 길

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

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

### 참고

-   [데이터베이스 vs 파일 노트 개인지식관리 규칙](https://notes.junghanacs.com/notes/20230223T054600) — 왜 파일인가
-   [허욱 디지털오브젝트 존재 대상 관계](https://notes.junghanacs.com/bib/20241205T164800) — 디지털 존재론
-   [마크왓슨 개인지식관리 시맨틱웹](https://notes.junghanacs.com/bib/20240623T131427) — PKM + AI
-   [마이클닐슨 학습이론 지식관리](https://notes.junghanacs.com/bib/20241115T222157) — 폴리매스의 PKM
-   [yibie org-supertag 이맥스 지식관리](https://notes.junghanacs.com/bib/20250405T162153) — supertag 실험
-   [빅히스토리 거대사 존재역사](https://notes.junghanacs.com/bib/20250504T185006) — 큰 역사 안의 작은 기록
-   [힣 이맥스 학습 불완전함 점진적 알음앓이](https://notes.junghanacs.com/notes/20240908T205217) — 불완전해도 계속 쌓는 것
-   [힣 지식공학 개인지식관리 인공지능 관계](https://notes.junghanacs.com/notes/20240704T170917) — PKM ↔ AI 교차점
-   [힣 인생도구 재발견 창조적행위 존재의방식](https://notes.junghanacs.com/notes/20240324T074730) — 도구와 존재