Public Evidence Across Five Axes: Agent Platform Operation, Memory, Dispatch, Domain Attachment, and Embedded Systems
I am a PKM-AI gardener who cultivates a person's knowledge and time. On that foundation, I build work surfaces where agents can be reviewed, continued, recovered, and handed over to the next person.
저는 사람의 지식과 시간을 가꾸는 PKM-AI 가드너입니다. 그 기반 위에, 에이전트가 검토받고 이어가고 복구하고 다음 사람에게 넘길 수 있는 작업면을 만듭니다.
If model capability is read as a tool-adoption problem, the answer becomes a list of tools. That is not what I have been digging into for the past year. How far can one person's knowledge and time be cultivated, and how far can that foundation support a work surface where agents withstand review, continuity, recovery, and handoff? That has been my question, tested through a daily record.
모델 역량을 도구 도입 문제로 읽으면 답은 도구 목록이 됩니다. 지난 1년간 제가 판 것은 그게 아닙니다. 한 사람의 지식과 시간을 어디까지 가꿀 수 있는가, 그리고 그 위에서 에이전트가 검토·지속·복구·인계를 견디는 작업면을 어디까지 만들 수 있는가 — 이것이 제 질문이었고, 매일의 기록으로 검증해 왔습니다.
I do not introduce myself first as an engineer or developer. Engineering is not my identity; it is how I make evidence.
그래서 저를 엔지니어나 개발자로 먼저 소개하지 않습니다. 엔지니어링은 정체성이 아니라 증거를 만드는 방법입니다.
What is cultivated remains as data, not rhetoric: 1,500+ journal days, 3,500+ notes, 8,200+ bibliographic records, 8,500+ commits, and 2,500+ days of life records. These are numbers that can be counted again in the live statistics at this moment.
가꾼 것은 말이 아니라 데이터로 남습니다. 저널 1,500일 이상, 노트 3,500개 이상, 서지 8,200건 이상, 커밋 8,500개 이상, 생활 기록 2,500일 이상. 지금 이 순간 라이브 통계에서 다시 셀 수 있는 숫자입니다.
On that foundation, I operated an agent runtime for roughly five months through more than twenty version cycles. When it regressed, I measured and rolled back; I then set down rules in documents to prevent recurrence. The experience did not remain a product configuration: it separated into three layers — memory, dispatch, and a reviewable development loop.
그 기반 위에서 에이전트 런타임을 약 5개월간 20회 이상의 버전 사이클로 운영했습니다. 회귀가 났을 때는 계측해서 롤백했고, 재발을 막는 규칙을 문서로 못 박았습니다. 그 운영 경험은 한 제품 설정에 갇히지 않고 세 계층으로 분리되었습니다 — 메모리, 디스패치, 검토 가능한 개발 루프.
There is evidence outside my repositories too. An outside developer contributed through an extension boundary I had drawn (entwurf #40), and my code was merged into another project's repository (ghostel #343 · #510). Self-owned repositories demonstrate capacity; these two lines demonstrate reception.
그리고 제 저장소 밖에서도 확인됩니다. 외부 개발자가 제가 그은 확장 경계에 기여를 열었고 (entwurf #40), 제 코드가 남의 프로젝트에 병합됐습니다 (ghostel #343 · #510). 자기 저장소는 능력을 보여 주고, 이 두 줄은 수용을 보여 줍니다.
How far has this been taken? Every major claim below descends to code, operating incidents, third-party actions, live aggregates, and a public time axis. Claim and evidence appear on the same page.
그래서, 이걸 얼마나 파보았는가. 아래의 모든 큰 주장은 코드, 운영 인시던트, 제3자의 행동, 라이브 집계, 공개 시간축으로 내려갑니다. 주장과 근거가 한 화면 안에 있습니다.
This document is itself evidence. One canonical Org source and one make regenerate this web record, two PDFs at different reading depths, and detailed Markdown together.
이 문서 자체가 하나의 증거입니다. Org 정본 한 장에서 make 한 번으로 이 웹 기록면과 읽기 깊이가 다른 PDF 2종, 상세 Markdown이 함께 재생성됩니다.
사상을 먼저 말하지 않으려 했습니다. 그런데 아래 다섯 축의 판단이 전부 같은 자리에서 나왔고, 그 자리를 감추면 판단들이 서로 무관한 취향처럼 보입니다. 그래서 다섯 문장만 적습니다. 문장마다 그것을 실제로 지킨 자리를 답니다. 지킨 자리를 데려오지 못하는 문장은 쓰지 않았습니다 — 그게 이 절이 선언문이 되지 않는 유일한 방법입니다.
제가 다룬 안전은 운영의 층위입니다. 경계를 긋고, 사람의 판단을 남기고, 복구 경로를 두고, 남이 검토할 수 있게 두는 일 — 제가 매일 하는 일이 그것이고, 아래 인시던트와 규칙이 그 기록입니다. 정렬 연구에는 이 문서가 내놓을 증거가 없으므로 주장하지 않습니다.
의심하면서 읽으시라고 규칙을 먼저 적습니다. 아래 다섯은 이 문서를 쓰는 동안 스스로에게 건 제약이고, 어긴 자리가 보이면 그건 제 잘못입니다.
문서가 만들어진 방식도 같은 규칙 아래 있습니다. 이 웹 기록면과 PDF 2종, 상세 Markdown은 전부 Org 정본 한 장의 깊이별 절단면이라 파생본이 정본보다 뒤처질 수 없고, 손으로 고친 자리도 없습니다. "AI 문서를 작성하고 배포한다"를 주장하는 대신, 문서가 만들어진 방식이 그 주장입니다.
저는 철학자가 아니라 가드너이자 엔지니어입니다. 그래서 이 문서의 말은 뜻을 밝힌 것만 씁니다. 어원은 적지 않고 하는 일로 정의합니다 — andenken 은 여기서 「기억 계층」이지 그 이름의 철학적 유래가 아닙니다. 정의의 정본은 공개 저장소의 용어집이고, 아래는 이 문서를 읽는 데 필요한 만큼입니다.
| 이 문서의 말 | 영문 표기 | 하는 일 |
|---|---|---|
| 책임질 수 있는 작업면 | accountable work surface | 모델 출력이 실제 문서·도구·사람의 판단과 만나되 출처, 권한 경계, 사람의 검토 경로를 잃지 않는 자리 |
| PKM-AI 가드너 | PKM-AI gardener | 개인 지식 기반과 에이전트를 한 살림으로 두고, 그 기반을 가꾸면서 그 위에 작업면을 만드는 사람. 첫 문장의 그 말 |
| 에이전트 엔지니어링 | agent engineering | 모델 역량을 지속되는 실행으로 바꾸는 일. 프롬프트 조립도, 프레임워크 이름도 아님 |
| PKM-네이티브 | PKM-native | 개인 지식 기반이 먼저이고 에이전트가 그다음. 순서가 반대인 스택과 구분 |
| 하네스 | harness | 에이전트가 실제로 일할 수 있게 받치는 기반 — 세션 부팅, 도구 경계, 권한, 기억이 붙는 자리 |
| 존재 대 존재 | being-to-being | 에이전트를 소모품 작업자가 아니라 이어지는 상대로 두는 작업 방식 |
| 분신 | entwurf | 하네스 사이의 디스패치 계층이자 그 관계의 이름 |
| 가든 시민 | garden citizen | 식별자를 가져서 다른 세션이 부를 수 있는 에이전트 세션 |
| 일일일생 | one-day-one-life | 하루를 하나의 완결된 생으로 기록하는 규율. 시간축의 원천 |
용어집 정본은 junghan0611 저장소의 VOCABULARY.md 입니다. 그 문서와 이 표가 어긋나면 정본이 이깁니다.
에이전트 도구를 사용한 사람이 아니라, 에이전트 플랫폼을 운영하고 그 위에 자기 계층을 쌓은 사람입니다. Linux 인프라 위에서 런타임을 운영하며 메모리, 디스패치, 검토 가능한 개발 루프, 그리고 사람이 이어받을 문서 체계를 만들었습니다.
다섯 축은 나열이 아니라 한 줄기입니다. 축1의 런타임 운영이 뿌리이고, 거기서 겪은 문제가 둘로 갈라져 축2의 기억 계층과 축3의 디스패치·검토 작업면이 되었습니다. 축4는 그렇게 분리된 계층을 이미 돌아가는 도메인에 적용한 자리이고, 축5는 그 아래에서 에이전트가 붙을 대상을 실제로 만들어 본 물리적 바닥입니다. 문서 체계는 여섯 번째 축이 아니라 다섯을 가로지르는 축입니다 — 각 계층을 다음 사람이 이어받게 만드는 일이라 어느 하나에 속하지 않습니다.
그리고 이 축들이 제 공개 프로필의 보유기술 다섯 칸입니다. 다섯이 여섯 줄로 퍼집니다 — 지식공학이 축2와 축4에 걸치고, HCI는 어느 한 축이 아니라 다섯을 가로지르는 문서 체계 쪽에 있기 때문입니다. 공개 채용면은 공용어를 요구하므로 축마다 그 공용어와 그 축이 여는 문을 함께 답니다.
| 축 | 보유기술 | 이 축이 여는 직무 입구 |
|---|---|---|
| 축1 런타임 운영 | Agent Harness Engineering | AI Engineer · Software Engineer |
| 축2 기억 계층 | Knowledge Engineering | AI Engineer |
| 축3 디스패치·검토 루프 | AI Agent Systems | Developer Experience Engineer |
| 축4 도메인 접점 | Knowledge Engineering — 살아 있는 도메인 위로 | Forward Deployed Engineer — 수행은 비공개, 공개 재현은 abductcli까지 |
| 축5 Linux에서 제품까지 | Embedded Systems | Embedded Software Engineer |
| 가로축 문서 체계 | HCI | Developer Experience Engineer |
HCI를 화면 설계가 아니라 작업 흐름의 인터페이스로 씁니다 — 사람이 시스템·에이전트·도구와 관계 맺는 접면이라는 뜻이고, 이 문서에서 그 자리는 다음 사람이 일을 이어받게 만드는 문서 체계입니다.
직무 이름은 증거가 아니라 입구입니다. 제가 그 직함으로 재직했다는 뜻이 아니라, 각 축의 증거가 채용면의 공용어로 어느 문에 닿는지를 적은 것입니다. 증명하는 것은 축마다 달린 사건과 숫자이고, 그건 아래 깊이 2·3에 있습니다. 축4가 그중 제일 얇습니다 — 수행은 사내에 있고 외부에서 열리는 것은 같은 추론 방식을 공개로 실행한 abductcli 하나뿐이므로, 그 줄은 표 안에서 스스로 범위를 밝힙니다.
보유기술 — Agent Harness Engineering · 직무 입구 — AI Engineer, Software Engineer
에이전트 런타임(OpenClaw)을 2026년 2월부터 6월까지 운영했습니다. Oracle Cloud ARM 인스턴스 위의 Docker, 메신저 채널 다중 연동, 매일의 일상 사용이 걸린 환경입니다.
핵심 조건이 하나 있습니다. 업스트림은 1인이 유지하는 프로젝트이고, 우리 조직에는 업스트림 담당자가 없습니다. 그래서 "버전을 올린다"가 곧 "릴리즈의 의미를 내 환경으로 번역한다"가 됩니다. 이 조건이 판단의 배경입니다.
롤백 대상을 고르는 기준이 이 프로젝트의 핵심 판단입니다. "한 단계 내린다"가 아니라 이미 검증된 판으로 정확히 돌아가는 것 — 최신을 고집하지 않는 것과 아무 데나 되돌리는 것은 다릅니다. 그리고 진단 도구의 권고를 맥락 없이 따르지 않습니다. 우리 배포 환경에서 거짓 양성으로 판정되면 적용하지 않고, 그 판단을 규칙으로 남깁니다.
두 버전을 한 번에 건너뛴 뒤 응답 지연이 급증했습니다.
stuck session: state=processing age=164s
여기서 실제 값어치가 나오는 판단은 롤백 대상 선택입니다. "한 단계 내린다"가 아니라 이미지 생성이 별도 API 키를 요구하지 않는 마지막 판이 어디인가 를 물었습니다. 최신을 고집하지 않는 것과 아무 데나 되돌리는 것은 다릅니다.
PREVIOUS 가 아니라 그 너머 LAST KNOWN GOOD 을 가리킨다 — 최신을 고집하지 않는 것과 아무 데나 되돌리는 것은 다르다는 판단을 이 구도가 쥐고 있다.그리고 고친 것은 코드가 아니라 규칙입니다.
stuck session 한 줄이면 그것만으로 배포 중단 사유.다음 판으로 재시도했더니 10분 만에 같은 인시던트가 재현됐습니다. 여기서 릴리즈 노트를 읽는 방식이 달라집니다. "무엇이 새로 생겼나"가 아니라 내 증상의 원인을 정면으로 고친 줄이 있는가 를 찾았습니다.
두 줄을 식별했습니다. 광범위한 런타임 프리로드를 실제 설정된 플러그인 id로 한정한 것, 그리고 플러그인 도구 서술자를 캐시한 것. 정확히 인시던트 ①의 근본 원인 가설이 가리키던 지점입니다. 중간 판들을 건너뛰고 그 판으로 직행했습니다.
| 지표 | before | after |
|---|---|---|
| 부팅 | 45.4초 | 7.3초 → 하드닝 후 5.8초 |
| 메모리 | 816 MiB | 246 MiB |
| 핫패스 의존성 스테이징 | 발생 | 0 |
동반 작업으로 운영에서 물러난 컴포넌트를 정리하고, 정체·유령 세션을 72개에서 16개로 줄이고, 컴파일 캐시와 재기동 억제 옵션으로 하드닝했습니다.
이후 판이 플러그인 탐색을 엄격하게 바꾸면서, 오래전에 사라진 컴포넌트를 가리키던 죽은 설정 경로가 hard-fail로 승격되어 크래시 루프가 났습니다. 설정을 통째로 되돌리지 않고 그 줄만 외과적으로 제거해 복구했습니다. 결과는 설정 경고 0건.
진단 도구가 낸 보안 권고를 우리 배포 맥락에서 검토해 거짓 양성으로 판정하고 적용하지 않았습니다. 설정을 재작성하는 자동 수정 옵션도 쓰지 않았습니다. 그 도구는 인시던트 ①의 근본 원인 가설에 등장하는 바로 그 도구입니다.
이유를 모른 채 무조건 따르면 위험하다 는 판단을 기록으로 남겼습니다. *AX 도입이 실패하는 가장 흔한 방식이 도구의 권고를 검증 없이 따르는 것이고, 저는 그 반례를 운영 기록으로 갖고 있습니다.*
운영은 한 제품 설정 안에 머물지 않고 세 계층으로 분리되었습니다.
OpenClaw 운영 (업스트림 추적 · 버전 · 인시던트 · 메모리)
│
├─→ andenken 메모리를 런타임에서 떼어내 독립 계층으로
├─→ entwurf 하네스 간 디스패치와 연속성
└─→ forge-config 검토 가능한 개발 루프 · sweeper
"에이전트 하네스를 쓴 사람"이 아니라 "에이전트 플랫폼을 운영하고, 그 위에 자기 계층을 쌓아 올린 사람"입니다.
배포를 선언한 nixos-config — 저자 서명 기준 528 커밋, 152 작업일, 2025-10-06~2026-07-17. 인시던트 세 개는 전부 이 저장소의 커밋으로 확인됩니다.
규칙이 사고보다 하루 먼저 있습니다. 04-27의 규칙 커밋과 04-28의 사고 사이 간격이 요점입니다 — 운영 규칙이 사후 정당화가 아니라 축적된 것임을 커밋 시각이 보여 줍니다. 그리고 롤백과 정책이 같은 커밋(13:05)에 있다는 것은, 복구와 규칙을 분리하지 않는다는 주장을 문장이 아니라 두 파일이 한 커밋 안에 있다는 사실로 확인시킵니다.
보유기술 — Knowledge Engineering · 직무 입구 — AI Engineer
andenken은 과거 세션과 공개 지식베이스를 같은 검색면에서 다루는 시맨틱 메모리입니다. 런타임 내부 기능으로 채팅 기록을 가두지 않고, 다른 하네스가 소비할 수 있는 독립 계층으로 꺼냈습니다.
설계의 핵심은 메모리를 세 축으로 가른 것입니다 — 응답 전 차단형 리콜, 임베딩 검색, 야간 통합.
세 축이 같은 상태에 있지 않습니다. 임베딩 검색만 이 저장소에서 구현되어 운영 중이고, 차단형 active recall은 이 저장소 밖 하네스 쪽에 있으며, 야간 통합(dream)은 아직 구현되지 않은 로드맵입니다. 셋을 한 문장으로 묶어 말하면 갖고 있지 않은 것을 갖고 있다고 말하게 되므로, 아래 표가 축마다 상태를 따로 답니다.
| 축 | 하는 일 | 상태 |
|---|---|---|
| active recall | 답변 전 차단형 리콜, 타임아웃 경계 | 하네스 쪽 (이 리포 밖) |
| embedding | 벡터와 BM25 하이브리드, 점수 정규화 | 구현·운영 중 |
| dream | 야간 통합, 기억의 증류 | 미구현 (별도 로드맵) |
DREAM ROADMAP 아치는 미구현 축 이다 — 지금 서 있는 것은 SESSIONS · GARDEN 두 아치와 그 사이의 정규화 저울(VECTOR + FTS · DENOTE GRAPH · VOCABULARY)뿐이며, 세 번째 축은 로드맵일 뿐 구현·운영 중이 아니다.구현 스펙은 LanceDB, Qwen3-Embedding-8B(4096차원), 세션과 공개 가든 두 트랙, 한↔︎영 교차 질의 확장(한국어 형태소 분석과 영어 태그 매핑을 별도 CLI로 분리), 그리고 회수 추적입니다. 무엇이 실제로 다시 불려 나왔는가는 기억 통합의 입력이 됩니다.
RAG를 "청킹·임베딩·벡터DB"로 묶어 말하지 않는 이유가 여기 있습니다. 검색은 세 축 중 하나이고, 언제 리콜을 차단형으로 걸 것인가와 무엇을 남기고 무엇을 증류할 것인가가 나머지 둘입니다.
저장소: andenken — 138 커밋, 31 작업일, 2026-03-19~2026-07-18.
핵심 파일과 실측.
| 파일 | 무엇이 있나 |
|---|---|
retriever.ts 108–115행 |
가중합 병합 — 정규화 없이 합치면 FTS가 가중합의 약 90%를 지배한다는 실측 주석 |
retriever.ts 467행 이후 |
MergeStrategy — weighted·rrf 두 병합 전략을 코드에서 선택 |
org-chunker.ts |
태그 정규화, 임베딩 제외 태그(archive · llmlog) 경계 |
session-sanitize.ts |
세션 텍스트 정규화. 개행 붕괴가 무엇을 무효화하는지 주석에 명시 |
golden-queries.ts |
범용 벤치마크가 아니라 제 실제 표현으로 검색 품질 회귀를 잡는 하네스 |
"정규화 없이 합칠 때의 랭킹 왜곡"은 추상적 주장이 아니라 그 파일 108–115행의 주석입니다. 최댓값 정규화로 두 점수를 [0,1]로 옮겨야 가중치가 비로소 의미를 가집니다.
재현 명령.
git clone https://github.com/junghan0611/andenken && cd andenken
./run.sh setup && ./run.sh build
./run.sh index:sessions # 세션 트랙 증분 인덱싱
./run.sh index:md # 공개 가든 트랙
./run.sh search "질의" # 하이브리드 검색
./run.sh golden # 검색 품질 골든 회귀
./run.sh test:search # 검색 계층 테스트
./run.sh doctor --md # 인덱싱 공백 설명 가능성 진단
doctor 가 별도 명령인 것이 설계 판단입니다 — "왜 이 노트가 안 잡히나"에 답하지 못하는 검색 계층은 운영할 수 없습니다.
한국어 RAG가 실패하는 자리 — 3층. "보편 학문에 대한 문서"라는 질의를 예로 들면:
| 층 | 무엇을 하나 | 무엇을 건지나 |
|---|---|---|
| 1 임베딩 벡터 | 의미 유사도 | paideia · universalism 태그가 붙은 노트 |
| 2 Denote dblock 그래프 | 메타노트 정규식으로 연결 추적 | 그 노트에 연결된 22개 노트 |
| 3 개인 어휘 온톨로지 | dictcli expand("보편") |
universal · paideia · liberal arts |
1층은 의미가 가까운 항목을 찾아 주지만 거기서 연결된 노트와 개인 동의어까지 펼치지는 못합니다. 어휘 그래프는 dictcli로 분리했습니다 — 52 커밋, 14 작업일, 2026-03-12~2026-04-21. 트리플 3,900여 개와 한↔︎영 매핑 2,400여 개를 들고 있습니다.
git clone https://github.com/junghan0611/dictcli && cd dictcli
clj -M:run expand "보편" # 한국어 → 영어 태그 후보
clj -M:run validate # 그래프 정합성
clj -M:run stats # 트리플·매핑 규모
실패와 교정.
note 소스가 지금도 partial입니다(거부 25). 줄이지 않고 원장에 적습니다.보유기술 — AI Agent Systems · 직무 입구 — Developer Experience Engineer
entwurf는 서로 다른 하네스의 세션이 상대의 인증·대화록·런타임을 소유하지 않고, 정체성만으로 서로를 호출하게 하는 얇은 기층입니다.
시민 자격은 하나인데 레일은 하네스마다 다릅니다. 그리고 그 차이를 통일하지 않은 것이 설계입니다 — 각 하네스가 자기 lifecycle을 이미 갖고 있는데 그것을 흉내 내면 두 번째 하네스가 됩니다. 출하된 시민 유형은 셋이고, 전달 경로는 대상의 상태에 따라 네 갈래입니다 — 깨어 있는 pi는 control socket, 잠든 pi는 spawn-bg resume, Claude Code는 meta-mailbox, Antigravity는 native-push로 닿습니다. 같은 socket-citizen이 상태에 따라 두 길로 갈리기 때문에 셋과 넷이 어긋납니다. 그리고 결과를 소유하는 호출은 잠든 pi를 깨우는 경우에만 성립하고, 나머지는 전부 fire-and-forget입니다. Codex는 probe 수준의 증거만 있고 관리되는 시민 레인이 출하되지 않았습니다 — 위 넷과 같은 줄에 세우지 않습니다.
여기에는 자기 리포로 증명되지 않는 것이 하나 있습니다 — 수용(reception). 자기 저장소는 능력을 보여주지만, 남이 그것을 실제로 썼는지는 보여주지 못합니다.
이 두 줄은 가장 위조하기 어렵고, 회의적인 독자가 가장 먼저 확인하는 줄입니다. 그래서 이 기록에서 지우지 않습니다.
시민 유형 셋과 전달 경로 넷이 어긋나는 자리를 표로 폅니다. 같은 socket-citizen이 깨어 있느냐 잠들어 있느냐에 따라 다른 길로 닿습니다 — 시민 자격은 대상의 속성이고 레일은 그 순간의 상태에 달린 것이라, 둘을 한 숫자로 세면 반드시 하나가 틀립니다.
| 대상 | 시민 유형 | 전달 경로 |
|---|---|---|
| pi 세션 — 깨어 있음 | socket-citizen | control socket |
| pi 세션 — 잠들어 있음 | socket-citizen | spawn-bg resume |
| Claude Code | mailbox-citizen | meta-mailbox |
| Antigravity | native-push citizen | native-push |
의도 쪽에도 비대칭이 있습니다. 결과를 소유하는 호출(owned-outcome)은 잠든 pi를 깨우는 경우에만 성립하고, 나머지 셋은 전부 fire-and-forget입니다. 살아 있는 대상에 owned-outcome을 걸면 자동으로 바꿔 주지 않고 거절합니다. 조용히 고쳐 주는 편이 친절해 보이지만, 그러면 호출자는 자기가 무엇을 부탁했는지 끝내 모르게 됩니다 — 틀린 의도로 성공한 호출이 맞는 의도로 거절당한 호출보다 나쁩니다.
소켓 레일에 메일박스가 없는 것도 차별이 아니라 크기 맞춤입니다 — 그 레일은 이미 반환 경로를 갖고 있어서, 없는 것을 채워 넣으면 두 번째 전달 계층이 생길 뿐입니다.
이 주장을 뒷받침하는 공개 증거를 시간축으로 둡니다. 각 행은 하나의 날짜, 하나의 읽기 슬롯, 하나의 공개 흔적이며, 표는 새 주장을 만들지 않고 이미 공개된 흔적을 가리킬 뿐입니다. Date는 note의 경우 해당 경로의 first-public garden commit의 KST 날짜이고, commit·PR은 공개 event의 KST 날짜입니다.
| Date | Reading slot | Signal | Public witness | What it shows |
|---|---|---|---|---|
| 2026-03-03 | Trigger/Context | note · verifies | note 20260302t191200 · garden 0ccadcf | 한 인간의 시간축 위 에이전트 협력을 설명하는 공개 가든 기록; 이 경로는 garden commit 0ccadcf에서 처음 확인됨. |
| 2026-04-03 | Decision+witness | note · verifies | note 20260324t153323 · garden 9b56a8d | entwurf 분신 디스패치 가이드를 담은 공개 가든 기록; garden commit 9b56a8d에서 확인됨. |
| 2026-04-06 | Decision+witness | note · verifies | note 20260406t095748 · garden 238d9ef | 힣봇클로드에서 pi-entwurf로의 전환을 설명하는 공개 가든 기록; garden commit 238d9ef에서 확인됨. |
| 2026-04-09 | Artifact/Measurement | commit · implements | entwurf f31367d | harness-first setup workflow 도입. |
| 2026-04-10 | Decision+witness | commit · implements | entwurf 50328a4 | provider를 claude-agent-acp bridge로 전환한 pivot. |
| 2026-04-20 | Artifact/Measurement | commit · implements | entwurf 1731865 | dual ACP backend 지원 추가. |
| 2026-04-24 | Decision+witness | commit · bounds | entwurf 8e98872 | Send-is-throw 메시징 계약을 tool·AGENTS 수준으로 성문화. |
| 2026-05-03 | Artifact/Measurement | commit · implements | entwurf eb4c973 | gemini을 세 번째 ACP backend로 추가. |
| 2026-06-17 | Reception/Boundary | pr · received | entwurf #40 · head 3dd6f5f | 외부 개발자가 Cortex Code backend 기여를 연 공개 PR; 2026-07-15 관측 OPEN, +885/-70, 11 files. |
경계 — named release/tag는 가리키는 커밋이 바뀔 수 있는 mutable ref이므로, 이 표는 commit SHA와 PR head OID, 관측 시점 상태를 구분해 둡니다. 지문은 입력과 산출물의 동일성만 확인할 뿐, 실행· 진실·완전성을 증명하지 않습니다.
forge-config는 도메인 오너와의 대화에서 발견된 요구를 셀프호스팅 Forgejo 이슈로 굳히고, 봇이 그것을 해당 도메인 에이전트에게 읽기 전용 1차 리뷰로 넘기는 공유 작업면입니다. 봇은 dispatcher이자 recorder이지 implementer가 아니고, 권위는 세션 기억이 아니라 durable store에 있으며, 무엇을 구현할지는 사람이 정렬된 백로그를 보고 결정합니다.
도메인 오너가 도메인 봇과 대화
→ 요구·버그·반복되는 고통이 감지됨 (봇 또는 sweeper)
→ 라벨 + 소스 컨텍스트를 달아 이슈 생성
→ forgebot이 라벨/웹훅으로 깨어남
→ 해당 owner agent에게 read-only 1차 리뷰 요청
→ reality check · risk · scope · 구현필요여부 · 우선순위 반환
→ forgebot이 리뷰를 기록하고 triage 종료
→ 사람이 정렬된 백로그를 보고 focused batch로 구현을 부른다
문서에 명시적으로 박아둔 non-goal이 셋입니다. 자동 코딩 공장이 아니고, 운영팀용 대시보드 제품이 아니고, 무엇을 구현할지 사람이 정하는 일을 대체하지 않습니다.
forgebot 은 dispatcher이자 recorder이지 implementer가 아닙니다.AX 도입이 실패하는 두 번째 전형이 "에이전트에게 구현을 통째로 맡기는 것"입니다. 호스팅 코딩 에이전트를 타깃으로 삼지 않은 이유를 저는 문서로 설명할 수 있습니다.
sweeper와 auto-fix 레인에서는 보수적 기본값, 변경 전 리뷰, durable report, 마커가 실린 코멘트, 스냅샷 드리프트 가드, 결정적 변경 게이트를 채택했습니다. 템플릿 마커가 스키마, 리포트 id, 세션 키, 이슈 갱신시각, 라이프사이클 라벨, 모델, 설정 커밋을 기록합니다.
목적은 하나입니다 — 세션 메모리와 웹훅 재생(replay)이 현재 Forge 상태를 절대 이기지 못하게. 에이전트가 "내가 아까 처리했다"고 기억해도, 권위는 durable store에 있습니다.
실증 착지: auto-fix v0가 두 리포에서 GREEN입니다. 라벨 감지에서 리포트 생성, 완료 전이까지 돌았고, 재생·멱등성 스모크에서 리포트 중복 생성이 없었습니다. v1에서는 경계가 제한된 워크스페이스 가드 패치를 실제로 수행하고, 매칭 실패를 또 하나의 비치명적 sweep 케이스로 노출하고, 수정 후 회귀 통과까지 확인했습니다.
상류 런타임은 transport, auth, model, gateway, lifecycle을 "봇이 깨어날 때까지" 소유하고, forge-config는 lifecycle protocol, auto-fix semantics, sweeper semantics, validation loop, follow-up 규칙을 소유합니다. 이 경계를 그을 수 있다는 것 자체가 플랫폼 운영자의 표식입니다.
저장소: entwurf — 864 커밋, 73 작업일, 2026-04-09~2026-07-15 · forge-config — 31 커밋, 6 작업일, 2026-05-27~2026-06-04.
이름에서 정체성으로. 처음 만든 것은 pi-shell-acp 였습니다 — 특정 도구를 다른 하네스에 붙이는 어댑터. 어댑터로 보는 한 "누가 누구를 감싸는가"를 계속 되묻게 됩니다. 2026년 3월에 그 정체성을 버리고 하네스를 감싸는 대신 각자를 같은 주소 공간의 시민으로 두는 기층으로 다시 정의했습니다. 그 전환은 npm에도 남아 있습니다 — @junghanacs/pi-shell-acp 의 마지막 판(0.11.1, 2026-06-29 05:59:26)과 @junghanacs/entwurf 의 첫 판(0.12.0, 2026-06-29 05:43:41)이 같은 날 이고 버전 번호가 연속입니다.
제3자의 행동이 드러낸 것 — 무엇을 짚었는가. entwurf #40 기여가 0.12.0 전환 과정의 설계 후퇴를 짚어 냈습니다. 0.11.0에는 백엔드 어댑터 패턴(AcpBackendAdapter 인터페이스와 백엔드 레지스트리)이 있었고 기여자는 거기에 cortex를 네 번째로 끼웠습니다. 그사이 비대해진 브리지를 통째로 버리고 Claude 단선으로 다시 짓는 과정에서 그 추상화를 한때 함께 걷어냈습니다. 단일 백엔드의 코드 품질은 올랐지만 백엔드 추가 레일은 0.11.0보다 뒤로 갔습니다.
그래서 순서를 뒤집었습니다. AcpBackendAdapter 인터페이스를 다시 깔고 Claude를 그 첫 구현으로 리팩터하는 작업은 0.12 계열에 반영돼 있습니다. cortex를 두 번째 구현으로 받는 작업은 0.13.0에 둡니다 — "두 개가 돼야 패턴이 산다". 이 결정과 후퇴가 있었다는 사실 자체를 공개 로드맵에 적어 두었습니다 — entwurf #48. cortex 수용 때 봉합할 지점은 7개로 특정돼 있습니다(실행 해석 · 오버레이 · 세션 메타 · 모델 라우팅 · 모델 강제 · 설정 서명 · 게이트).
재현 명령과 게이트.
git clone https://github.com/junghan0611/entwurf && cd entwurf
pnpm install && pnpm check # 타입·린트·게이트 묶음
./run.sh check-bridge # 브리지 MCP 표면이 백엔드 인증 없이 로드되는지
./run.sh check-auth-boundary # 인증 경계 — 자격증명을 소유하지 않음을 고정
./run.sh check-dep-versions # 선언한 런타임 핀과 문서가 어긋나면 실패
run.sh 에 check-* · smoke-* 게이트가 97개 있습니다. 게이트 이름 자체가 이 프로젝트의 불변식 목록입니다 — 인증 경계, ACP 오버레이, 세션 재사용, 도구 표면, 의존성 핀, 설치 표면.
보유기술 — 지식공학의 도메인 착지 · 직무 입구 — Forward Deployed Engineer
이미 돌아가는 IoT·상담 시스템을 새 플랫폼으로 갈아엎지 않았습니다. 자연어 질의를 기존 DDL, 디바이스 로그, 런타임 미러, 상담 근거로 연결하되 읽기 전용 경계를 유지했습니다.
이것이 "DB·MQ·컨테이너를 이해한다"보다 한 층 위의 답이라고 생각합니다. 도메인의 주인이 자기 데이터를 자기 언어로 물을 수 있게 만드는 일이고, 비개발 영역 AX 전환의 실제 모양입니다.
경계: 고객사와 사내 도구의 식별 가능한 세부는 공개면에 쓰지 않습니다. 여기서는 역할과 구조만 말하고, 검증 가능한 공개 저장소를 그 옆에 둡니다.
사내 코드는 열 수 없지만 추론 방식 자체는 공개 저장소에서 실행됩니다 — abductcli, 13 커밋, 4 작업일, 2026-04-15~2026-05-07.
git clone https://github.com/junghan0611/abductcli && cd abductcli
clj -M:run pipeline # 전체 귀추 파이프라인
clj -M:run import data/superstore.csv # 원자료 적재
clj -M:run detect --grain category # 기준선과 다른 신호 검출
clj -M:run suggest-signals --anomaly anom-001 # 잔차를 다음 가설로
숫자의 정직성 4단계 — 이 순서가 사내 워크벤치의 공통 골격입니다. ① 모든 숫자의 단위·기간· 포함 정책을 먼저 고정 ② 근거를 개별 원본 id까지 역추적 가능하게 ③ 기준선과 다른 신호를 잡기 ④ 설명되지 않고 남은 잔차를 다음 사이클의 가설로 넘기기.
보유기술 — Embedded Systems · 직무 입구 — Embedded Software Engineer
Zigbee/Wi-Fi 펌웨어, Go 서버, Flutter 앱을 연결해 양산 제품으로 출하했습니다. 연결형 배포는 AWS IoT를, 폐쇄망은 로컬 백엔드가 같은 프로토콜을 제공하고, 펌웨어는 수정 없이 양쪽을 사용합니다.
이 경험은 이 기록의 중심축이 아닙니다. 다만 에이전트 계층 아래 의 DB·MQ·프로토콜·디바이스 현실을 이해하고 있다는 배경 신뢰도로 둡니다. 에이전트를 붙일 대상이 무엇으로 만들어졌는지 모르면, 붙이는 방식도 틀립니다.
연결형과 폐쇄망은 보통 두 개의 제품이 됩니다. 여기서는 하나로 뒀습니다 — 배포 토폴로지와 도메인 계약을 분리했기 때문입니다. 클라우드 쪽은 관리형 IoT 백엔드가, 폐쇄망 쪽은 로컬 백엔드가 같은 프로토콜 을 제공하고, 펌웨어는 자기가 어느 쪽에 붙었는지 모른 채 같은 바이너리로 양쪽에 나갑니다.
이 분리가 값을 내는 자리는 경계입니다. 배포 방식이 도메인 계약에 새어 들어오면 장치와 앱이 상태 의미를 조금씩 다르게 해석하고, 각 부분은 정상인데 제품 전체가 조용히 실패합니다. 그런 실패는 로그에 이름을 남기지 않습니다.
homeagent-config 뿐이며, 무게는 거기에 둔다.클라우드 없이 도는 Matter 스마트홈 허브 위에 온디바이스 AI 에이전트를 얹었습니다 — homeagent-config, 387 커밋, 42 작업일, 2026-02-03~2026-07-15. 물은 것은 모델 벤치마크가 아니라 터미널에서 쓰던 하네스의 관심사가 엣지에서도 살아남는가 였습니다.
git clone https://github.com/junghan0611/homeagent-config && cd homeagent-config
./run.sh go-build # 단일 Go 바이너리
./run.sh flutter-server # 뷰어 개발 서버
./run.sh bundle # 타깃별 배포 번들
핵심 판단 ① — 붙이는 설계가 아니라 갈아 끼울 수 있게 자르는 설계. 배포 토폴로지와 도메인 계약을 분리해, 장치와 앱이 배포 방식과 무관하게 같은 상태 의미를 유지하게 했습니다. 경계에서 상태나 프로토콜이 조금씩 어긋나면 각 부분은 정상이어도 제품 전체가 조용히 실패합니다.
핵심 판단 ② — 리팩터링은 지우는 것이 아니라 강등시키는 것. 차세대 허브에서 타깃을 ARMv7·glibc·벤더 sysroot에서 RISC-V·정적 링크 musl 로 옮기고, 보드 HAL을 뽑아 허브 코어가 자기가 무슨 보드에서 도는지 모르게 했습니다. 그러면 어제 출하한 허브가 오늘 여러 백엔드 중 하나가 됩니다.
다섯 축이 서사의 골격이라면, 이 표는 그 골격을 실제로 만든 기술 폭입니다. 숫자와 사건은 싣지 않습니다 — 그건 각 축의 d2·d3이 갖고 있습니다. 무엇을 직접 다루지 않았는지도 여기서 말하지 않습니다 — 아래 「경계」절이 유일한 자리입니다.
| 영역 | 직접 다룬 것 | 연결되는 축·공개 표면 |
|---|---|---|
| Linux·edge | NixOS 선언적 관리(노트북·서버·ARM) · 컨테이너·GPU 워크로드 · Yocto 임베디드 Linux · glibc/musl · ARM/RISC-V | 축1 · 축5 · nixos-config |
| backend·data·messaging | Go·Clojure API, 단일 바이너리 서비스, IoT 백엔드 · PostgreSQL JSONB·SQLite·LanceDB·MQTT · Docker/GPU 컨테이너 | 축2 · 축4 |
| cloud·runtime | AWS IoT · Oracle Cloud ARM · Cloudflare Zero Trust · Netlify | 축1 · 축5 |
| web·UI protocol | Go HTTP·Clojure 서버렌더링·정적 웹 · React 19/Preact/Lit · A2UI(선언적 JSON 화면) | 축5 · homeagent-config |
| agent·documentation | entwurf 하네스 운영·40개 이상 스킬 설계 · AGENTS/NEXT/스킬 3층 문서 계약 · 문서 변환·배포 도구 memex-kb · 독자별(개발자/비개발자) 표면 분리 |
축1 · 축3 · Digital Garden · Agenda |
| 주장 | 확인할 곳 |
|---|---|
| 에이전트 디스패치와 연속성 | entwurf · 수용 로드맵 #48 |
| 세션·지식 메모리 | andenken · 어휘 그래프 dictcli |
| 검토 가능한 개발 루프 | forge-config |
| 귀추 추론 공개 실험체 | abductcli |
| 문서 변환·배포 도구 | memex-kb |
| 임베디드와 엣지 AI | homeagent-config |
| 재현 가능한 Linux 기반 | nixos-config |
| 공개 지식·문서 체계 | Digital Garden |
| 라이브 작업·통계 표면 | Agenda · /api/stats |
| 제3자의 확장 | entwurf #40 |
| 제3자가 받아들인 코드 | ghostel #343 · #510 |
마지막 두 줄이 수용(reception)의 증거입니다. 자기 저장소는 능력을 보여주지만, 저자가 유일한 심판인 닫힌 루프를 의심하는 독자에게는 답이 되지 않습니다.
이 절이 이 문서에서 제일 위조하기 어려운 자리입니다. 앞의 다섯 문장이 사상이었는지 습관이었는지는 여기서 갈립니다 — 하루를 하나의 생으로 적어 온 사람에게만 검증할 축이 남기 때문입니다.
사람이 손으로 기록한 생활과 저널, 에이전트가 남긴 stamp, 실제 커밋과 노트를 하나의 KST 축에서 읽습니다. 원본(FULL)은 제목과 참조를 품으므로 공개하지 않습니다. 아래는 allowlist로 집계한 공개 판독이고, 공개 저장소 agent-config 의 시간축 관측소 스킬이 FULL과 스냅샷의 짝(바이트 지문)을 검증한 뒤에만 생성합니다. 같은 입력이면 같은 바이트가 나오고, 날짜는 하나도 손으로 적히지 않았습니다.
에이전트를 수십 개 붙여도 지나간 시간은 만들어낼 수 없습니다. 이 축은 산출물이 아니라 하루를 셉니다. 같은 기간을 어느 깊이까지 읽느냐에 따라, 살았지만 아무 산출물도 남기지 않은 날이 보이거나 사라집니다.
| 깊이 | 무엇이 보이나 | 기록의 성격 | 커버리지 |
|---|---|---|---|
| 0 | 산 대로의 하루 — 수면 · 가족 · 독서 · 본짓 | 의도 | 194일 / 201일 |
| 1 | 그날 손으로 적은 것 | 의도 | 140일 / 201일 |
| 2 | 에이전트가 남긴 스탬프 | 잔여물 | 143일 / 201일 |
| 3 | 커밋과 노트 | 잔여물 | 194일 / 201일 |
렌즈를 바꾸면 며칠이 사라지는가. 창은 2026-01-01 이상 2026-07-21 미만(KST)이고, 그 사이의 모든 날 201일이 분모입니다.
| 읽는 렌즈 | 보이는 날 | 사라지는 날 |
|---|---|---|
| 깊이 2·3 — 잔여물만 (에이전트 스탬프 · 커밋 · 노트) | 199일 | 2일 |
| 깊이 1·2·3 — 잔여물 + 손으로 적은 저널 | 200일 | 1일 |
| 깊이 0 포함 — 산 대로의 하루 | 201일 | 0일 |
잔여물이 통째로 침묵한 날. 커밋도 노트도 에이전트 스탬프도 없는데, 산 시간은 있습니다. 산출물만 읽는 판독기에게 이 날들은 공백입니다.
이 판독의 출처. 인용은 내용 지문 하나로 하지 않습니다 — 같은 내용이라도 창이 다르면 다른 판독이고, 소스가 부분적이면 다른 품질이며, 깊이 0을 만든 도구가 다르면 다른 손이 적은 것이고, 읽은 기기가 다르면 애초에 닿은 저장소가 다릅니다.
as_of)device)oracle
src_tree)bbcc7d483f4537b9 5d130e1c356c57d1 31353a71
관측 지문 content_sha256 — 인용은 이것으로 한다
f8191586bcb18c66 f5ba404cbb639a3d b783713676557872 f449c3b9d26e887a
수집기 code_sha256 — collector 0.7.0
a847831b2edd8294 6279753e1ec5b3a0 77a50d83a01e2dd5 0308a99ffb6f3ca4
짝 검증 events_sha256 — 이 기기의 원본과 스냅샷이 한 짝인지
c5362420f8b37bf4 fd523e86f38a8671 4d4806e543b65472 4ef647cde2de2af2
이 지문이 증명하지 않는 것. 해시는 바이트와 내용이 같은지, 바꿔치기가 없었는지를 확인할 뿐입니다. 이 코드가 실제로 돌았음도, 소스가 진실하고 완전함도 증명하지 않습니다. 깊이 0은 폰에서 손으로 export한 1인칭 기록이라 외부에서 원본을 재구성할 길이 없고, 확인할 수 있는 것은 파생의 일관성입니다. 원본(FULL)은 제목과 참조를 품으므로 공개하지 않습니다 — 이 문서에는 집계만 나옵니다. 시간 블록은 시작 날짜에 귀속되며, 하루를 24시간 파티션으로 나눈 것이 아닙니다.
같은 창이라도 다른 판독이 나올 수 있습니다. 창은 날짜만 자를 뿐, 어떤 저장소와 어떤 ref가 그 순간 그 디스크에 있었는지는 고정하지 않습니다. 그래서 다른 기기에서, 또는 같은 기기라도 다른 시점의 ref 상태에서 만든 스냅샷은 수치가 다를 수 있고 그것이 오류는 아닙니다. 두 판독을 나란히 놓으려면 창만이 아니라 위의 기기와 소스 상태를 먼저 맞추십시오.
제 org-agenda·저널·노트·커밋·시간기록을 하나의 KST 축 위에 정규화하는 수집기를 씁니다. 이력서용으로 고른 최고작이 아니라, 그 기간에 실제로 무엇이 남았는지를 그대로 엽니다.
| 깊이 | 무엇이 보이나 | 기록의 성격 |
|---|---|---|
| 0 | 하루의 시간 배분 — 수면·가족·독서·작업 | 의도적 기록(수기 export) |
| 1 | 그날 무엇을 적었나 (저널 헤딩) | 의도적 기록 |
| 2 | 에이전트가 무엇을 했나 (agenda 스탬프) | 산출물의 잔여물 |
| 3 | 커밋 하나하나, 노트 하나하나 | 산출물의 잔여물 |
깊이 0·1은 의도이고 2·3은 잔여물입니다. 잔여물만 읽는 도구는 무엇이 생산됐는지는 말해도 그것을 생산한 시간은 말하지 못합니다.
깊이라는 말이 이 문서에서 두 번 쓰입니다. 서로 다른 축이니 겹쳐 읽지 마십시오. 문서의 깊이(d0–d3)는 상세도 입니다 — 같은 주장을 얼마나 자세히 펼치느냐. 시간축의 깊이(0–3)는 기록의 성격 입니다 — 그 기록을 사람이 의도해서 남겼느냐, 산출물이 흘린 잔여물이냐. 두 축은 다르지만 방향은 같습니다. 둘 다 넓은 데서 세밀한 데로 내려가고, 내려갈수록 검증에 필요한 것이 늘어납니다.
앞의 다섯 축은 기획서의 목차가 아니라 시간 위에서 실제로 갈라진 순서입니다. 계보를 압축하면 이렇습니다 — 각 줄의 날짜는 아래 원장에서 공개 커밋으로 확인됩니다.
2026-02 런타임 운영 시작 축1 OpenClaw
│ └ 제품 세로축은 이미 그 아래에 있었다 축5 (2026-02 온디바이스 허브)
│
├─ 03 기억을 런타임에서 떼어낸다 축2 andenken
├─ 04 하네스 사이의 연결을 기층으로 축3 entwurf
│ └ 05 판단이 남는 공유 작업면 forge-config
├─ 04~05 같은 추론을 공개 실험체로 축4의 공개 아날로그 abductcli
└─ 05 도메인 워크벤치 착수 축4 (사내)
운영이 먼저이고 계층은 그 뒤입니다. 이 순서가 뒤집혀 있으면 — 계층을 먼저 설계하고 운영을 나중에 붙였다면 — 같은 저장소 목록이라도 다른 이야기입니다.
위 판독은 지문을 둘 싣습니다. 같은 것을 두 번 재는 것이 아니라 서로 다른 질문에 답합니다.
events_sha256content_sha256인용은 내용 지문으로 합니다. 제 agenda는 역방향 datetree라 스탬프 하나만 찍혀도 옛 줄이 전부 밀립니다 — 관측이 하나도 바뀌지 않은 오후에 바이트 지문만 세 번 달라진 적이 있습니다. 그것을 못 박아 두지 않으면 인용은 다음 스탬프에 죽습니다.
지문만으로는 부족해서 판독이 기기를 함께 답니다. 창은 날짜만 자를 뿐, 어떤 저장소와 어떤 ref가 그 순간 그 디스크에 있었는지는 고정하지 않습니다. 그래서 같은 창을 같은 코드로 읽어도 다른 기기에서는, 또는 같은 기기라도 로컬 ref 상태가 달라진 뒤에는 수치가 다르게 나올 수 있습니다. 그것은 오류가 아닙니다. 두 판독을 나란히 놓을 때 먼저 맞춰야 하는 것은 창이 아니라 위의 기기와 소스 상태입니다.
이 절은 «믿어 달라»가 아니라 «어떤 기록에서 무엇을 골랐는지 밝힌다»를 위한 것입니다. 원시 이벤트는 노트·저널 제목과 인물명을 나르므로 공개면에 올리지 않습니다. 아래는 그 축에서 골라낸 사건이고, 라벨 셋이 외부에서 확인할 수 있는 정도 를 가릅니다.
| 날짜(KST) | 사건 | 확인 경로 |
|---|---|---|
| 2025-09-29~30 | 게이트웨이 프로젝트를 긴급 인수인계로 받고 문서화, 전환 전략 수립 | 사내 |
| 2025-10-06 | 배포 선언 저장소의 첫 커밋 — 이후 528 커밋 152 작업일 | 공개 nixos-config |
| 2025-12-07 | 허브 펌웨어 저장소 첫 커밋 | 사내 |
| 2026-02-03 | 온디바이스 AI 허브 첫 커밋 — 이후 387 커밋 42 작업일 | 공개 homeagent-config 1f1efc4 |
| 2026-03-16 | 온디바이스 허브 3-에이전트 병렬 세션 — 그 하루에 24 커밋 | 공개 homeagent-config |
| 2026-03-19 | 기억 계층을 독립 저장소로 분리 | 공개 andenken 72f0dcd |
| 2026-04-09 | 하네스 디스패치 기층 첫 커밋 — harness-first 셋업 | 공개 entwurf f31367d |
| 2026-04-15 | 귀추 추론 공개 실험체 착수 | 공개 abductcli 54297c5 |
| 2026-04-27 10:35 | 게이트웨이 경고를 오류로 취급하는 운영 규칙 추가 — 사고 전날 | 공개 nixos-config 261976f |
| 2026-04-28 13:05 | 롤백과 관망·감시 정책을 한 커밋에 기록 | 공개 nixos-config 6c8ac99 |
| 2026-05-03 | 지연 적재 구조를 정면으로 고친 상류 판 확인 후 승격 | 공개 nixos-config 80ba4ce |
| 2026-05-07 09:46 | 공개 귀추 실험체 마지막 커밋 | 공개 abductcli |
| 2026-05-07 오후 | 같은 날 오후 도메인 워크벤치 착수 — 스캐폴드에서 계약·기능까지 | 사내 · 운영 기록 |
| 2026-05-27 | 공유 코드 작업면 착수 — 스캐폴드부터 이슈 생성까지 당일 | 공개 forge-config e9fc7c6 |
| 2026-06-17 | 외부 개발자가 백엔드 기여 PR을 엶 | 공개 entwurf #40 |
| 2026-06-29 | 어댑터 패키지 마지막 판과 기층 패키지 첫 판이 같은 날, 연속 번호 | 공개 npm |
| 2026-07-15 | 이 기록면의 공개 증거 시퀀스 도입 | 공개 junghan0611 14ace52 |
| 2026-07-18 | 시간축 관측소를 공유 스킬로 분리 | 공개 junghan0611 2315002 |
| 2026-07-20 | 이 문서를 네 깊이 하나의 문서로 재구성 | 운영 기록 (공개 미도달) |
마지막 줄이 이 문서의 규칙을 자기 자신에게 적용한 자리입니다. 오늘의 작업은 이 축에 관측되지만 공개 remote에 아직 도달하지 않았으므로 「공개」라고 적을 수 없습니다. 도달한 뒤에야 그 줄의 라벨이 바뀝니다.
stale 입니다. 손으로 export하는 시간 기록이 2026-07-13에서 멈춰 있고, 그 뒤 이레는 다른 소스가 증언하는 날입니다. 안 산 날이 아니라 안 적힌 날입니다. 축은 이것을 ok 로 보고하지 않습니다.partial 입니다 (거부 25 — 중복 식별자 8, 파싱 불가 17). 줄이지 않고 원장에 적습니다.as_of 와 device 와 소스 상태를 함께 싣습니다. 다른 수치와 나란히 놓을 때는 그 셋을 먼저 맞추십시오 — 셋이 다르면 두 판독은 애초에 다른 디스크의 다른 순간을 읽은 것이고, 어느 쪽이 틀렸다고 말할 근거가 되지 않습니다.정직하게 적습니다. 이 경계를 넘어서 주장하지 않습니다.
ok 가 아니라 empty 이고, 깊이 0이 다른 소스가 증언하는 날을 못 덮으면 stale 입니다. 마운트가 빠진 디스크에서 "정상이며 비어 있음"으로 보고되는 것이 가장 위험한 실패이기 때문입니다.큰 숫자는 장식이 아니라 더 깊은 기록으로 들어가는 입구입니다. 공개 통계는 라이브 endpoint와 함께 제시하고, 프로젝트 수치는 기간·포함정책·검증 링크를 붙입니다.
Timeline projection. 위 「시간축」의 표는 공개 allowlist 산출물
timeline/projection.md에서 왔다. 생성기는 스냅샷과 FULL의 짝을 먼저 검증하고,
같은 입력에서 같은 바이트를 낸다. 제목·참조·시간블록 코멘트는 집계에 들어가지 않으며, LOCAL
axis.html은 임베드하지 않는다. 인터랙티브 컴포넌트는 이 자리에 붙되, 데이터가
먼저다 — 지금 읽고 있는 숫자가 그 데이터다.
지금까지 다룬 것은 한 사람의 기억과 저자성, 그리고 사람과 에이전트의 장기 협업입니다. 다음은 그것을 조직의 데이터, 거버넌스, 워크플로, 도메인 오너십으로 옮기는 일입니다.
개인에서 조직으로 그대로 건너가는 것은 셋이라고 봅니다 — 기억의 소유권, 권한의 경계, 인계 가능한 기록. 셋 다 사람이 몇 명이든 같은 문제이고, 조직에서는 오히려 더 아픈 문제입니다. 건너가지 않는 것도 압니다. 개인의 시간축은 조직에 그대로 없습니다. 한 사람이 1,500일을 적어서 만든 축을 조직에 요구할 수는 없고, 요구해서도 안 됩니다. 조직에서 그 자리를 대신하는 것은 도메인 오너가 이미 쥐고 있는 기록이며, 제 일은 새 축을 만들라고 하는 것이 아니라 이미 있는 축에 에이전트를 붙이는 것입니다 — 축4가 그 첫 착지입니다.
주장을 키우는 것보다 어디까지가 내 것이 아닌지 먼저 말하는 것이 신뢰를 만든다고 봅니다.