@힣: 에이전트 컨텍스트 레이어 기술 지도 — 하네스·메모리·지식그래프·PKG·PKM-AI

이 노트에 대하여

에이전트의 컨텍스트는 하나의 프롬프트나 데이터베이스가 아니다. 사람이 소유한 원본, 검색 가능한 메모리, 이식 가능한 스킬, 살아 있는 세션, 작업의 시간과 출처가 서로 다른 계약으로 이어진다. 이 노트는 특정 제품을 정답으로 선언하지 않고 LLM Wiki·OKF·MCP·하이브리드 검색·그래프 데이터베이스·지식그래프·온톨로지·개인지식그래프(PKG)를 같은 기술 지도 위에 놓는다. 현재 PKM-AI가 잘하는 검색과 회수에서 한 단계 더 나아가, 관계의 종류와 출처와 시간까지 계산 가능한 PKG로 확장할 가치가 있는지를 주기적으로 검토한다.

히스토리

[2026-07-29 Wed 17:57] @mitsein — 앞 절이 못 본 축을 보완했다. Denote 파일명의 시그니처가 이 가든에서 Folgezettel 주소로 쓰이고 있고, authority 등급의 맨 위에 human_filename이 새로 들어간다(123개). 발생량과 권위가 반대라는 것 — 123개가 가장 강하고 dblock 12,031개가 가장 약하다 — 이 순회 기본값이다. 파서 계약(root/components/depth/possible_parent)과 실측(깊이 109/123이 2단, 부모 결손 1건)을 적고, 에이전트는 시그니처를 읽기만 하고 부여하지 않는다는 경계를 세웠다.
[2026-07-29 Wed 15:49] @mitsein — PKG Phase 1을 제안에서 재료 확인 단계로 옮겼다. 공개면 링크 22,271개를 authority 넷(human 4,804 / body 4,636 / dblock 12,031 / export 800)으로 분류하고 순회 비용을 쟀다(human p50 3, dblock max 335). 담당자 넷의 소유표와 하지 않는 것 넷을 규약으로 박았다 — andenken은 skos 매칭을 쓰지 않고 후보만 낸다. 개념의 정본은 20250214 빈방으로 분리했고, ELOT 정렬 파일럿은 ‡† 30개의 축이 힣의 언어로 서기 전까지 시작하지 않는다.
[2026-07-25 Sat 21:44] 이 노트는 어쏠로그로 올린다. 문서가 밀도가 있어. 이제 자주 손을 봐야겠다. 내 ‘원문’을 이야기를 종종 해줄게.
[2026-07-22 Wed 18:16] @mitsein — 2026-07-19 GPT와 나눈 Paul Iusztin의 Context Layer 비교 대화를 기술 문서로 재구성했다. `entwurf`·`andenken`·공통 스킬·시간축을 한 지도에 놓고, 온톨로지·지식그래프·그래프DB·PKG 탐구를 다음 축으로 세웠다. 과거 C 프로젝트 에이전트 도구 전문은 제거하고 짧은 씨앗만 남겼다.
[2026-02-19 Thu 14:27] `pi`와 OpenCode를 포함한 C 프로젝트 에이전트 도구 문서로 갱신했다.
[2025-10-24 Fri 08:57] 대규모 C 코드 분석과 OpenCode/LSP/ 크로스컴파일 도구를 정리하는 방으로 생성했다.

갱신 규칙

이 문서는 철학 선언이나 제품 홍보가 아니라 주기적으로 고치는 기술 지도 다.

구현 여부는 `implemented`·`partial`·`proposed`·`rejected`로 구분한다.
제품 버전·문서 수·스킬 수처럼 빨리 낡는 숫자는 검증일 없이 쓰지 않는다.
원본 시스템과 파생 인덱스를 구분하고, 파생 뷰를 새 정본으로 승격하지 않는다.
외부 기술은 이름보다 해결하는 질의와 운영 비용으로 평가한다.
지식그래프를 도입하기 전에 기존 검색으로 풀리지 않는 질문을 먼저 적는다.

출발 자료

용어와 경계

용어	이 문서에서의 뜻	소유해야 할 것
모델	추론하고 생성하는 신경망	교체 가능
런타임	모델 호출·도구 실행·샌드박스의 실행 환경	adapter로 격리
하네스	프롬프트, 도구 루프, 권한, 세션, UI를 묶는 에이전트 제품	교체 가능하되 능력 차이 기록
컨텍스트 레이어	하네스 밖에서 소유하는 기억·업무 로직·검색·쓰기 계약	원본과 함께 소유
메모리	과거 기록을 다음 작업에 다시 넣는 검색·회상 표면	파생 가능, 출처 필수
스킬	업무 절차와 도메인 규칙을 재사용 가능한 능력으로 만든 것	filesystem·CLI·MCP 계약으로 이식
세션	transcript·인증·모델·현재 작업 상태를 가진 native 실행 단위	하네스가 소유, 외부가 위장하지 않음
지식그래프	엔터티와 의미 있는 관계를 명시한 지식 표현	출처·관계 타입·시간 필요
그래프DB	노드·엣지와 경로 질의를 저장·실행하는 데이터베이스	구현 선택지, KG와 동의어 아님
온톨로지	무엇이 어떤 종류이며 어떤 관계가 허용되는지 정한 개념 계약	사람과 도메인이 검토
PKG	개인의 기록·경험·해석·출처를 연결한 Personal Knowledge Graph	PKM 원본의 파생 그래프로 시작

지식그래프·온톨로지·그래프DB는 같은 말이 아니다. 온톨로지가 관계의 문법을 정하고, 지식그래프가 그 문법으로 사실과 해석을 표현하며, 그래프DB는 이를 저장하고 질의할 수 있는 여러 구현 중 하나다. PKG는 이 셋을 개인의 경험과 통제권, 맥락에 맞게 좁힌 적용 영역이다.

기본 아키텍처

Authoritative sources
Org · Denote · Journal · Zotero · Git · session JSONL · raw posts
                           │
                    parse / adapt / derive
                           │
Materialized context views
hybrid index · structural links · vocabulary map · graph projection
                           │
Serving contracts
CLI · filesystem skills · explicit MCP tools/resources
                           │
Native harnesses
pi · Claude Code · Codex · Antigravity · OpenClaw
                           │
Durable traces
commits · botlog · agenda · garden · public projections

핵심은 모든 것을 한 데이터베이스로 옮기는 데 있지 않다. 원본은 각 형식의 식별자와 시간 규칙을 유지하고, 검색·그래프·공개본은 필요할 때 다시 만들 수 있는 materialized view로 둔다. 물리적으로 하나가 아니어도 skills와 식별자 계약을 통해 논리적으로 조회할 수 있다.

컨텍스트 연속성의 다섯 축

축	끊기면 사라지는 것	현재 구현 예
Source continuity	원문·출처·변경 역사	Org·Denote·Zotero·Git·JSONL
Memory continuity	과거 기록과 개인 어휘의 회상	andenken·denotecli·dictcli
Capability continuity	조사·기록·검증 업무 절차	공통 skills·CLI
Session continuity	살아 있는 작업 상태와 native identity	entwurf garden id·dispatch·resume
Temporal continuity	무엇을 왜 만들었는지의 시간과 잔여물	journal·agenda·timeline·git

이 축들은 서로 대체하지 않는다. 같은 MongoDB를 검색한다고 두 세션이 서로의 현재 작업을 아는 것은 아니고, 같은 세션을 재개한다고 오래된 가든에서 필요한 지식을 자동으로 찾는 것도 아니다.

Portable Context Layer 패턴

Paul Iusztin의 구조는 세 부분으로 압축할 수 있다.

Disposable harness
      ↓
MCP server / filesystem skills
      ↓
Unified memory

장점은 분명하다.

하네스를 바꾸어도 노트·대화·선호·업무 로직을 다시 사용할 수 있다.
자연어·구조·대규모 검색과 URL·파일·대화 ingest를 고수준 도구로 제한한다.
raw DB 연산 대신 에이전트가 조합하기 쉬운 검색·쓰기 primitive를 제공한다.
append-only log와 검색 가능한 materialized view를 구분한다.

그러나 ‘single database’는 보편 원칙이 아니다. MongoDB·Postgres 하나에 텍스트·벡터·그래프를 모으면 운영은 단순해질 수 있지만, 그 DB가 원본의 의미와 편집권까지 가져가면 새로운 잠금이 된다. 이 문서의 기본 선택은 원본 분산·파생 뷰 통합 이다.

Entwurf는 컨텍스트 레이어가 아니다

Context layer : swap the harness, keep memory and capability
Entwurf       : keep native harnesses, address the living session

`entwurf`는 공통 기억 DB나 상부 하네스를 만들지 않는다. 각 하네스가 가진 transcript·인증·런타임을 가져오거나 복제하지 않고, garden id로 기존 세션을 호명해 해당 native 전달면으로 메시지를 보낸다. 따라서 메모리·GraphRAG·continual ingest를 `entwurf` 안에 넣으면 역할 경계가 무너진다.

올바른 분리는 다음과 같다.

memory / PKG service ─ skills or explicit MCP
agent-config         ─ portable procedures
entwurf              ─ identity and dispatch
native harnesses     ─ transcript, auth, runtime

원본에서 지식으로 — 쓰기와 승격 계약

대화를 일정 턴마다 자동 ingest해 사실 노드로 만들면 잠정적 추측과 에이전트 해설이 사용자의 믿음으로 굳을 수 있다. PKM-AI의 쓰기 계약은 자동 축적보다 권위 단계를 먼저 둔다.

capture  원문·세션·링크를 그대로 보존
stage    엔터티·관계·메타 후보를 제안
review   원문 대조, 권위·오독·중복 검사
promote  노트·메타·프로젝트 문서에 반영
index    검색·그래프·공개 projection 재생성

PKG도 `promote` 이전의 추출 결과를 정본으로 삼아서는 안 된다. 그래프 노드는 반드시 원본 참조, 추출 주체, 관찰 시점, 현재 유효성을 함께 가져야 한다.

PKM-AI의 다음 탐구 — PKG

현재 PKM-AI는 텍스트 회수에 강하다.

시맨틱 유사성으로 과거 세션과 가든을 찾는다.
BM25와 한국어·영어 어휘 확장으로 검색을 보강한다.
Denote ID·링크·태그·서지 키로 구조를 따라간다.
원본을 유지하며 인덱스를 다시 만들 수 있다.

PKG가 더해야 할 것은 ‘검색 결과를 더 많이 주는 것’이 아니라 관계의 종류와 맥락을 계산 가능하게 만드는 것 이다.

예를 들면 다음 질문이 가능해야 한다.

이 주장을 처음 던진 원문과 나중의 해설본은 무엇인가?
어떤 세션의 결정이 어느 commit과 노트를 만들었는가?
같은 개념을 지지하는 자료와 반박하는 자료는 무엇인가?
특정 인물·책·프로젝트가 어떤 시간에 연결되었는가?
지금의 관계는 원문 사실인가, 에이전트 추출인가, 인간이 승격한 해석인가?
한글 메타 자석과 영어 태그가 어떤 개념으로 같은가?

이 질문이 기존 `denotecli`·`knowledge_search` 조합으로 충분히 풀린다면 그래프를 만들 이유가 없다. 여러 번의 수동 조립이 반복되고 관계 타입이 없어서 오독이 생길 때 PKG가 비용을 벌기 시작한다.

PKG 단계별 접근

Phase 0 — 질의와 어휘부터

PKG가 답해야 할 실제 질문 10~20개를 수집한다.
현재 meta 자석과 개인 어휘를 온톨로지 후보로 읽는다.
`note`·`person`·`book`·`session`·`commit`·`project` 같은 최소 엔터티를 정한다.
`links_to` 하나로 뭉개지 말고 필요한 관계 타입을 찾는다.

Phase 1 — 읽기 전용 materialized PKG

Denote ID·서지 키·Git SHA·session id를 안정 식별자로 사용한다.
Org·BibTeX·Git·JSONL을 바꾸지 않고 그래프 projection을 만든다.
모든 엣지에 source ref와 추출 시각을 붙인다.
그래프를 삭제하고 원본에서 재구축할 수 있어야 한다.

Phase 2 — 작은 온톨로지와 typed edge

초기 후보:

broader / narrower / related
supports / contradicts / derived_from
authored_by / cites / discussed_in
produced / implemented_by / verified_by
occurred_at / supersedes / current_version

POLE+O(Person·Organization·Location·Event·Object)는 외부 교환용 최소 봉투로는 유용하지만, 개인지식그래프의 정본 온톨로지로는 `Object`가 너무 넓다. 책·노트·주장·질문·개념·세션·commit을 구분할 수 있는 작은 확장이 필요하다.

Phase 3 — 검색 대비 평가

동일 질문을 hybrid retrieval과 PKG traversal에 각각 던진다.
정확도뿐 아니라 출처 회수율, 설명 가능성, 갱신 비용을 비교한다.
2~3 hop 질의가 실제로 반복되는지 확인한다.
그래프가 원문보다 강한 관계를 만들어내는 오류를 측정한다.

Phase 4 — 저장 엔진 선택

Neo4j·MongoDB·Postgres·LanceDB 옆의 별도 graph projection을 비교한다. Neo4j는 Cypher와 시각화, 경로 탐색이 강하지만 먼저 채택할 이유는 없다. 작은 파일·SQLite·in-memory graph로 질의를 증명한 뒤 운영 비용을 벌 때 선택한다.

기술 선택 지도

영역	가벼운 선택	무거운 선택	판단 기준
파일 지식	Markdown·Org·YAML·OKF	문서 DB	사람이 직접 편집·버전 관리할 필요
키워드 검색	ripgrep·BM25	검색 클러스터	corpus 크기와 필터 요구
시맨틱 검색	LanceDB·로컬 벡터	managed vector DB	규모·운영·비용
구조 연결	Denote links·tags	typed KG	관계 타입과 다중 hop 필요
그래프 저장	파일·SQLite·in-memory	Neo4j·TigerGraph	Cypher·시각화·경로 질의 필요
시간 그래프	timestamped edge	Graphiti·Zep	사실의 유효 기간·episode 추적 필요
사실 메모리	검토된 note	Mem0	자동 fact extraction 허용 범위
통합 파이프라인	custom adapters	Cognee	추출 편의와 데이터 모델 통제의 교환
제공면	CLI·filesystem skill	MCP server/app	원격 접근·다중 클라이언트·UI 필요

도입 전에 답할 질문

그래프가 없어서 현재 답하지 못하는 질문은 무엇인가?
어떤 관계가 원문에 명시되어 있고 어떤 관계가 추출된 것인가?
관계의 유효 기간과 supersession을 어떻게 표현할 것인가?
개인·가족·회사 데이터의 visibility를 노드와 엣지에서 어떻게 제한할 것인가?
동일 인물·책·프로젝트의 identity resolution을 누가 승인할 것인가?
그래프를 버리고 원본에서 완전히 재구축할 수 있는가?
write-back은 어디까지 자동화하며, 무엇은 인간 검토 없이는 승격하지 않는가?
기존 hybrid search보다 나아졌음을 어떤 benchmark로 증명할 것인가?

현재 상태 — 2026-07-22

구성	상태	정본·담당
Org·Denote 가든	implemented	사람이 편집하는 지식 원본
Zotero·BibTeX	implemented	인물·책·자료의 서지 식별자
session JSONL	implemented	native 대화 원본
andenken hybrid retrieval	implemented	재생성 가능한 검색 뷰
denotecli structural retrieval	implemented	ID·링크·태그 구조 조회
dictcli vocabulary graph	implemented	한·영 개인 어휘 확장
filesystem skills·CLI	implemented	하네스 공통 능력
entwurf dispatch	implemented	native session identity·전달
timeline projection	partial	삶·작업·산출물의 시간축 조회
typed personal knowledge graph	proposed	원본 위 읽기 전용 projection부터
canonical ontology	deferred	meta 자석을 후보로 검토
automatic conversation promotion	rejected	capture와 human-reviewed promote 분리

[2026-07-29 Wed] PKG Phase 1의 재료와 담당자 규약

2025-10-24에 세운 PKG 단계 계획에서 Phase 1이 「제안」에서 「재료가 확인된 단계」로 바뀌었다. 개념의 정본은 #빈방 #지식그래프 #검색증강생성 RAG의 의미 전환에 있다 — 담당자는 그 방을 먼저 읽고 이 절을 읽는다. 이 절은 무엇을 만드는가 가 아니라 누가 무엇을 소유하고 무엇을 하지 않는가 를 적는다.

Phase 1의 재료 — 2026-07-29 실측

공개 가든 2,240편에서 내부 링크 22,271 발생, 고유 (출처, 대상) 20,278, self-link 30. 링크가 나타난 절이 그대로 관계의 성격을 말한다.

authority	발생	어디서	저자 글로스
human	4,804	관련메타·관련노트·히스토리	1,358 (28%)
body	4,636	본문	291 (6%)
dblock	12,031	KEYWORDS 등 denote-links	5 (0%)
export	800	Related-Notes	2 (0%)

순회 비용도 여기서 갈린다.

축	노드	max	p95	p50	평균
dblock	564	335	82	10	21.3
human	1,071	57	15	3	4.5

기본 순회는 human, dblock은 모자랄 때만 연다. dblock 2-hop은 최대 자석에서 7,000노드로 터진다.

자석망은 평평하지 않다. 메타메타 ‡† 30 / 자석 † 504 / 무표식 4이고, meta↔meta 사람 링크가 1,108개다(†→‡† 130, ‡†→† 126). 다만 ‡† 에서 1-hop으로 닿는 자석은 184/538(34%)이다.

소유 — 담당자 넷이 맞출 규약

층	소유
공용 SKOS 얼개·역량질문·검토된 정렬	ELOT Org (사람)
공개 가든 요약·raw edge 추출	andenken (기계)
낱말↔낱말 — 대극·상하위·인접	dictcli
노트 하나의 이웃 라이브 조회	denotecli
시간 좌표·정직한 0	timeline
조합	harness
관계 제공 표면	파일이 생긴 뒤

추출을 andenken에 두는 근거는 셋이다. (1) 요약 레코드와 엣지가 한 번의 파싱 에서 나온다 — 리포를 쪼개면 파서가 둘이 되고 버전이 갈린다. (2) 공개면 allowlist가 여기에 있다. denotecli는 사적 노트를 포함한 원본 전체를 보므로 필터를 재구현해야 한다. (3) denotecli의 graph ID 는 한 노트의 이웃을 지금 묻는 라이브 조회로, 전량 projection과 성격이 다르다.

다만 이것은 andenken을 온톨로지 저작 도구로 키우는 것이 아니다. 온톨로지의 정본은 Emacs/ELOT의 Org 문서에 남는다.

하지 않는 것 — 규약의 핵심

andenken은 skos:*Match 를 쓰지 않는다. 후보만 제안하고, 승격은 사람이 ELOT Org에서 한다. capture → stage → review → promote → index 계약 그대로다.
관계를 발명하지 않는다. 원문에 적힌 것만 담고 authority로 구분한다. 링크 뒤의 — 이유 는 raw_gloss 로 원문 그대로 보존하며, 에이전트가 쓴 글로스는 별도 authority로 격리한다.
파생물이 정본이 되지 않는다. 증거 주소는 denote_id + heading_slug + content_hash + extractor_version + observed_at 이다. export의 파일:줄은 진단용일 뿐 — Markdown은 export 때 줄이 이동한다.
중복은 지우지 않는다. 같은 (출처, 대상)이 여러 절에 나타나면 엣지 하나에 여러 evidence를 붙인다. 검색 신원과 엣지 신원을 나눈다.

2026-07-22 판에서 고칠 것

canonical ontology | deferred | meta 자석을 후보로 검토 — 자석은 이미 2층 구조이고 meta↔meta 1,108개가 걸려 있다. 다만 관련메타는 연상이지 broader/narrower 가 아니다. 정렬 후보 생성에만 쓰고 자동 승격은 금지한다.
Phase 4 저장 엔진 — 2만 엣지 규모에서는 JSONL/SQLite로 충분하다는 판단이 실측으로 확인됐다. RDF/TTL은 predicate가 안정된 뒤 export 표면으로 더한다.
「도입 전에 답할 질문」 8번(기존 hybrid search 대비 증명)의 지표가 정해졌다 — 같은 질문에 회수가 쓰는 토큰량, 그리고 정렬 실험의 Hit@3 · MRR · abstain precision.

아직 하지 않는다 — ELOT 파일럿

프로피디아 10 + ‡† 30 정렬 실험은 좋은 첫 표지만, 개념이 선 다음의 일이다. ‡† 30개가 세 성격으로 갈리기 때문이다 — 지식 영역(기술·인공지능·지능·영성·지식), 지식을 다루는 형식과 작동(구조·목록·모음·분류체계·육하원칙·편집·플랫폼), 고유 횡단축(영감·성공과 실패·장소·여행·이맥스·리스프). 절반은 프로피디아 항목이 아니라 메타 레벨이다. 이 축이 힣의 언어로 정리되기 전에 정렬표를 만들면 남의 분류에 자기 자석을 밀어 넣게 된다.

[2026-07-29 Wed] Folgezettel 시그니처 — 가장 높은 권위의 관계면

앞 절을 쓸 때 이 축을 못 봤다. Denote 파일명의 시그니처 필드가 이 가든에서 Folgezettel 주소로 쓰이고 있고, 그것이 가장 높은 권위의 관계면 이다. 개념 쪽 서술은 @힣: 왜 나는 지식그래프를 계속 묻는가의 「파일명이 먼저 만든 지식 주소」 절에 있다. 여기에는 기계 계약만 적는다.

권위 등급이 넷에서 다섯이 되고, 새로 들어온 것이 맨 위다

authority	무엇	규모	이 등급인 이유
`human_filename`	Folgezettel 시그니처	123	저자가 직접 타이핑한 주소. denote 함수로 관리되어 형식이 보장되고, 개명으로만 바뀐다
`human`	관련메타·관련노트·히스토리	4,804	저자가 고른 링크. 1,358개엔 이유까지 붙어 있다
`body`	본문 링크	4,636	서술 중에 걸린 링크
`export`	Related-Notes	800	export가 만든 면
`dblock`	KEYWORDS 정규식	12,031	기계 발견면. 발생량 최대, 권위 최소

발생량과 권위가 정확히 반대다. 가장 적은 123개가 가장 강하고, 가장 많은 12,031개가 가장 약하다. 순회 기본값은 이 표의 위에서부터다.

파일명이 무료 인덱스인 이유

ID==SIGNATURE--TITLE__KEYWORDS.EXTENSION

Denote 매뉴얼이 설명하듯 필드 구분자가 검색의 닻이 된다 — ==1 하나로 같은 시그니처 계열이 모인다. 이 축은 파일을 열지 않고 디렉터리 목록만으로 추출된다. 링크 22,271개는 본문을 전부 읽어야 나오지만 시그니처는 ls 한 번이다. 파싱 비용이 사실상 0이므로, 증분 인덱싱에서 이 축은 항상 최신이어도 된다.

파서 계약

파일명 하나에서 안전하게 뽑는 것:

signature_raw    "1j2b1"
root             "1"
components       ["1","j","2","b","1"]   숫자/문자 교대
depth            5
possible_parent  "1j2b"
siblings         같은 부모 접두를 공유하는 시그니처
authority        human_filename

possible_parent 는 검토 후보이지 관계 공리가 아니다. Folgezettel은 루만식 ‘이어짐’이며 ‘포함’을 뜻하지 않는다. 1a … 1j 와 1j1 … 1j6 은 프로피디아 번호와 대응하므로 강한 계층 후보지만, 0* 는 알파벳 색인이고 접목 주소 (1j1b 1j2a 1j2b1 1j2c)는 하위·인접·파생 중 무엇인지 저자만 안다.

실측 — 2026-07-29

깊이 분포는 1:4 · 2:109 · 3:6 · 4:3 · 5:1 이다. 123개 가운데 109개가 깊이 2 로, 트리는 넓고 얕다. 실제 계층은 1j 가지 하나에 몰려 있고 0* 100개는 평면 색인이다. root는 넷이다 — 0 신토피콘, 1 프로피디아, 3 닷파일·설정, 5 어쏠로지. 시그니처가 하나의 전역 온톨로지가 아니라 여러 계열을 동시에 시작할 수 있는 자유 형식 주소라는 증거다.

possible_parent 가 실재하지 않는 것은 123개 중 1개 다 — 1j2b1 (원격·리모트· 프록시·포워딩)의 부모 1j2b 가 없다. 실패율 1/123은 이 신호가 매우 깨끗하다는 뜻인 동시에, 부모 추론을 공리로 승격하면 안 되는 이유의 실물이다. 결손은 고치지 않고 보고한다.

이 축에 대한 경계

andenken은 시그니처를 읽기만 한다. 붙이거나 고치거나 결손을 메우지 않는다. 시그니처는 denote 함수로 저자가 관리하는 면이고, 에이전트가 손대는 순간 human_filename 이라는 권위의 근거가 사라진다. 제안은 낼 수 있고 부여는 못 한다.
두 번째 목록을 만들지 않는다. 시그니처 표는 매번 파일명에서 재생성한다. 사람이 관리하는 사본이 생기면 파일명과 갈라진다.
접두 관계를 skos:broader 로 자동 승격하지 않는다. possible_parent 는 ELOT에서 저자가 검토할 후보로만 넘어간다.
시그니처 없음을 결손으로 세지 않는다. 두 표식이 없는 387개는 미정렬이 아니라 다른 관계로 이미 이어져 있을 수 있다.

문서종 구분

원본 안에서도 역할이 다르다. notes·meta는 생각과 개념의 방이고, bib 680편은 저작물 Work 와 그것을 읽은 DenoteNote 를 분리해 interprets/cites/authored_by 를 물을 자리이며, journal 105편은 대표 요약 벡터 없이도 out-edge 3,782개를 품고 timeline으로 들어가는 것이 자연스럽다. 요약 코퍼스는 journal을 빼고 2,135편으로 잡는다. 새 축이 아니라 원본과 시간축 안에서 나눌 문서종이다.

옛 방의 씨앗

이 Denote ID는 2025년 `sks-gateway`의 대규모 C 코드를 에이전트가 다루도록 OpenCode·clangd·compile_commands.json·Nix 개발 환경·크로스컴파일 도구를 한데 정리한 문서였다. grep 대신 구조적 조회를 제공하고, 분석 환경과 실제 타깃 빌드를 분리하며, 에이전트가 사용할 도구는 빠르고 구조화된 출력을 내야 한다는 교훈을 남겼다.

당시의 설치 명령, 전체 스크립트, 성능 예상치와 프로젝트 경로는 현재 실행 지침으로 쓸 수 없고 전문도 더 이상 필요하지 않아 제거했다. 남은 씨앗은 하나다. 에이전트의 성능은 모델만이 아니라 정확한 컨텍스트와 도구 계약에 달려 있다. 이 교훈이 지금의 컨텍스트 레이어 기술 지도로 이어진다.

junghanacs🧠

Table of Contents

Backlinks