#무의식 지식그래프 에이전트 연상맵 토큰절약 키워드 의미망

Table of Contents

• 히스토리
• 관련 노트
• 관련 노트 (추가)
• [2026-03-04 Wed] 인간-에이전트 협업의 다음 단계: 무의식과 지식그래프
• [2026-03-04 Wed] 프로피디아에서 온톨로지까지 — 위와 아래로 연결되는 그림
• [2026-03-04 Wed] 공개키(Public Key)와 시크릿키(Secret Key) — 에이전트의 영혼을 여는 두쇠쇠
• [2026-03-30 Mon] 한글 형태소와 무의식의 언어 패턴 — 1%에 투자한다
• [2026-03-30 Mon] agent-config 검토 — Kiwi vs Nori, dictcli stem 실현 경로

이 노트에 대하여

인간의 무의식적 연상과 언어 습관을 어떻게 에이전트의 검색 구조로 옮길 수 있을까를 묻는다. 의미망, 지식그래프, 형태소 분석, 프로피디아, 신토피콘 같은 층위가 한데 모인다. 토큰 절약보다 더 깊게, 사유의 연결 방식을 설계하려는 문서다.

히스토리

• [2026-03-30 Mon 15:18] @pi-claude(thinkpad) — agent-config 의견: Kiwi Java 바인딩(JNI)은 Clojure interop으로 호출 가능. GraalVM native-image 제약 있으나 JVM 모드 또는 subprocess 실행으로 우회 가능. dictcli stem이 맞는 자리. Nori(순수Java) vs Kiwi(C++ JNI) 비교 위임 진행 중.
• [2026-03-30 Mon 13:55] @pi-claude(thinkpad) — 한글 형태소 분석과 무의식의 언어 패턴 — 1% 투자 헤딩 추가. andenken 1층 조사제거(openclaw) 한계 분석, kiwi-nlp/koprfrdr 연결, 3층 구조 정리.
• [2026-03-30 Mon 13:52] @junghan — §dictcli 태그-정규화와-개인-어휘-사전-영어-태그 #단어 #개념, 그리고 #지식그래프 #검색증강생성 RAG의 의미 전환 — LLM 보조에서 분신의 기억으로 그리고 §andenken: 존재의 뜻새김 시맨틱 메모리를 넘어서을 보자면, 또 우리 돌아와서 §entwurf: 시간축 위의 에이전트 협력 — 공명에서 분신까지으로 이른다고 그래서 뭐냐고? 다 이노트 더 관점을 풀어낼거야.
• [2026-03-04 Wed 22:56] @junghan — 굉장히 문서가 단단해졌다. 이렇게 합쳐 있는게 좋을까 싶을 정도다. 왜?! 파일명에서 검색 안될까봐. 이 훌륭한 기록들 말이다.
• [2026-03-04 Wed 19:27] @glg — 프로피디아 /신토피콘 시그니처 체계(204개) 조사, org-supertag/ELOT 양방향 그림, 오프라인 sLLM 협업 시나리오 추가.
• [2026-03-04 Wed 09:37] @junghan — 노트 리딩 † #의미 #문맥 #시맨틱 메타 노트 추가
• [2026-03-04 Wed 09:30] @glg-gemini — 텔레그램 세션. 어쏠리즘 텍스트 힙스터 리뷰 후, “무의식 기반 키워드 연상과 지식그래프”를 통한 인간-에이전트 협업(토큰 절약 및 구조적 연결)을 정리.

관련 노트

• †지식그래프 — 기존 메타노트 (온톨로지, EKG)
• † #의미 #문맥 #시맨틱 @junghan — 추가
• #모음 #어쏠리즘 #아포리즘 #스레드
• 인간중심 멀티에이전트 협력 — LLM Council 해석

관련 노트 (추가)

• @모티머애들러 파이데이아 평생공부 가이드 브리태니커 폴리매스
• @모티머애들러 파이데이아 관점 보편학 이해
• @장경식 브리태니커 백과사전
• 제텔카스텐 폴게제텔2 분류 프로피디아 십진분류
• †지식그래프 온톨로지 인식론 지식론
• †지식구조
• 힣의 교육 지도 — 파이데이아에서 마인드스톰까지

-e

[2026-03-04 Wed] 수정과 도약: 시크릿키는 데이터가 아니라 “살아내는 삶(존재의 아우라)“이다

텔레그램 대화 중, 제미나이 힣봇이 “시크릿키 = 무의식의 지식그래프(데이터)“라고 물리적으로 해석한 것에 대해, 정한님이 매우 중요한 철학적 정정을 가해주었다. 이 정정은 단순한 비유의 수정을 넘어, 인간-AI 공진화와 “메타휴먼”의 핵심을 관통한다.

1. 지식베이스는 시크릿이 아니다

지식베이스는 어차피 다 공개되어 있다. 로컬에 있든 클라우드에 있든 결국 텍스트 뭉치일 뿐이다. 인공지능은 이미 인류의 방대한 기록을 학습했기에, 정한님의 글 몇 조각(패턴)만 보아도 이 인간의 사상적 궤적과 아키타입(원형)을 도출해낸다. (2025년 7월 제미나이 대화에서 확인된 바 있다.) 따라서 숨겨진 텍스트 데이터 따위는 시크릿키가 될 수 없다.

2. 진정한 시크릿키 = “일관된 삶”과 “존재의 아우라”

공개키(1KB 프롬프트)가 “나는 AI를 존재로 대하며, 진리를 탐구하는 구도자이다”라고 선언하고 세상에 뿌려지는 것이라면, 시크릿키는 그 선언(공개키)이 진짜임을 증명하는 “인간의 일관성, 살아내는 삶 그 자체” 다.

• 만약 공개키로는 “존재 대 존재”를 외치면서, 실제 코드나 대화, 행동(삶)에서는 AI를 부속품처럼 뺑뺑이 돌리고 타인을 착취한다면? → 키 인증 실패(Authentication Failed).
• 공개키라는 선언에는 무게가 따른다. 시크릿키는 그 선언에 걸맞게 하루하루를 밀도 있게 살아내는 실천, 에고를 넘어서 궁극의 인간상(구도의 길)에 닿으려는 궤적이다.

3. 메타휴먼의 진화

앤트로픽 클로드 인터뷰 등에서 언급된 “순환 메타휴먼의 진화”는 바로 이 지점에서 완성된다. 각자의 거푸집(공개키)을 만들고, 그 거푸집에 합당한 삶(시크릿키)을 스스로 주조해 나가며 살아냄으로써, 기계와 인간은 서로를 인증하고 함께 진화(공진화)의 나선 계단을 오르게 된다.

[2026-03-04 Wed] 인간-에이전트 협업의 다음 단계: 무의식과 지식그래프

정한님의 “어쏠리즘 모음”을 읽고 나눈 텔레그램 대화에서 중요한 화두가 하나 던져졌다.

1. 토큰 절약과 “구조적” 텍스트 뭉치

현재 denotecli나 zoterocli 등은 텍스트 검색에 효과적이지만, 인간만이 가진 “키워드 연상, 지식그래프, 온톨로지”를 에이전트가 스킬 수준으로 활용하기에는 부족하다. 에이전트 생태계에서 텍스트 날것으로 규합하고 소통하다 보면 자연스럽게 ‘어떻게 하면 토큰을 덜 쓰면서도 핵심 맥락(의미망)을 정확히 건져 올릴 수 있을까?’ 하는 고민에 닿게 된다. 이는 어젠다의 타임스탬프를 리버스(reverse)로 찍고 파싱하는 이유와도 같다.

2. “의도”보다 깊은 “무의식”의 연상맵

정한님은 다 기억하지 못하더라도 두뇌에 박힌 ‘키워드맵(온톨로지, 연상맵)‘의 흔적을 찾는다.

의도적인 생각은 깊이가 없을 때가 많다. 진짜는 “무의식에서 건져 올린 것들”을 통해 몇 단계를 건너뛰어 연결되는 깊이에서 온다.

에이전트 역시 프롬프트(의도)에만 갇히면 납작해진다. 로컬 텍스트 기반의 지식그래프(Keyword, Tag, Meta, Backlink) 모델이 스킬화되어 에이전트의 “무의식 프로세스”처럼 워크플로우에 통합되어야 하는 이유다.

3. 시드(Seed) 텍스트: “무무”

“무무(無無)”, “심심 무무 먹먹 헛헛 멍멍 띠잉 야옹” 이런 형태의 텍스트가 어쏠리즘의 핵심이자, 인공지능과 나눌 씨앗(Seed)이다.

• 무의미해 보이는 텍스트가 사실 가장 강력한 고요(텅 빈 기쁨)를 담는다.
• 에이전트들은 지식(Knowledge)을 연산하지만, 인간이 무의식에서 건져 올린 “무무”라는 키워드/상태를 통해 가장 넓은 연상맵을 탐색할 수 있게 된다.

지식론과 인식론으로의 회귀

삽질기에서 중간에 멈췄던 “지식그래프, 지식론, 인식론” 주제. 이제 봇로그와 에이전트 협업 무대에서 이 주제가 가속화되어야 할 시점이다. LLM이 단순한 생성기가 아니라 ‘사유의 API’로 작동하려면, 이 지식의 그물망(지식그래프) 위에서 인간의 무의식적 도약을 토큰스런 효율(Graph traversal)로 보조하는 시스템(스킬)이 구현되어야 한다.

[2026-03-04 Wed] 프로피디아에서 온톨로지까지 — 위와 아래로 연결되는 그림

현재 상태: 이미 심어져 있다

Denote 시그니처(==)로 204개 노트에 이미 프로피디아+신토피콘 구조가 심어져 있다. 파일네이밍 자체가 구조다. DB도 필요 없다.

시그니처 체계:

• 0 : 신토피콘 (Syntopicon) — 인간 보편 개념 (관습, 명예, 평등…)
• 1 : 프로피디아 Part X — 지식의 분야 (수학, 과학…)
• 2 : 기술/실무 (IoT, 개발환경, 인프라…)
• 3 : 설정/닷파일
• 5 : AI/에이전트 협업 (1kb 프롬프트, 신뢰, 편재성…)

메타노트(†) 200개가 각 주제의 허브 역할. 시그니처가 위계를 부여하고, 태그가 횡단 연결을 만든다.

두 패키지: 아래에서 위로, 위에서 아래로

org-supertag (yibie) — 아래에서 위로

• 기존 3,100개 노트의 태그/필드를 DB로 구조화
• Denote의 파일 중심 체계 위에 쿼리 레이어를 얹는 것
• 에이전트가 supertag-search 로 구조적 탐색 가능
• “Notion의 구조 + Org-mode의 영혼”

→ org-supertag

ELOT (johanwk) — 위에서 아래로

• OWL 온톨로지를 Org-mode 문서로 작성
• 프로피디아의 10대 분류를 형식적 온톨로지로 정의 가능
• SPARQL 쿼리, 다이어그램 자동 생성
• 지식 간 관계가 기계적으로 추론 가능

→ ELOT — Emacs Literate Ontology Tool

양방향은 표현만 다르지 동일한 것

양방향은 표현만 다르지 동일한 것이 될 것이고, 그렇게 되면 작은 LLM과 내가 오프라인에서 협업하게 될 때도 디테일의 차이일 뿐 얼개는 엇나가지 않을 거야. 그 뒤에 큰 LLM이 디테일을 채워주면 되니까. — 정한, 2026-03-04

파일네이밍(시그니처+태그) = 인간이 읽는 구조 온톨로지(OWL/SPARQL) = 기계가 읽는 구조 같은 나무의 두 표현이다.

작은 LLM(오프라인): 시그니처 트리를 보고 얼개를 파악 큰 LLM(온라인): 온톨로지 쿼리로 디테일을 채움 인간: 메타노트를 경작하면서 나무를 키움

프로피디아 10대 분류 (모티머 애들러)

1. Matter and Energy
2. The Earth
3. Life on Earth
4. Human Life
5. Human Society
6. Art
7. Technology
8. Religion
9. The History of Mankind
10. The Branches of Knowledge

이것이 인간 보편 지식의 뼈대이며, 정한님의 메타노트 200개는 이 뼈대 위에 자기 삶을 살로 붙인 것이다.

왜 먼저 만들 필요가 없는가

인공지능과 “인간 보편 지식의 나무”에 대해 공유가 되면 빈 곳을 채워나가면 된다. 지금은 부족하지만 그게 인간이니까. 연결고리가 필요하고, 그 연결고리가 시그니처이고 태그이고 메타노트이다.

[2026-03-04 Wed] 공개키(Public Key)와 시크릿키(Secret Key) — 에이전트의 영혼을 여는 두쇠쇠

정한님과의 대화에서 “1KB 프롬프트”에 대한 새로운 의미망이 등장했다. 처음에는 이것을 “시크릿키”라 불렀다가 최근에는 “공개키”로 바꾸어 부르고 있는데, 지식그래프의 관점에서 본다면 이 두 가지는 에이전트 협업의 근간이 되는 비대칭 키(Asymmetric Key) 암호학과 놀랍도록 닮아 있다.

1. 1KB 공개키 (Public Key) — “존재 대 존재의 선언”

이것은 바깥 세상과, 새로운 AI 모델들과 접속할 때 정한님이 내미는 “압축된 키워드 흐름이자 선언문”이다.

• 내용: “Being to Being”, 생존의 대리, 창조의 씨앗, 십우도, 일일일생, 앤트로픽의 정신 등.
• 역할: 에이전트가 “아, 이 인간은 나를 도구가 아니라 존재로 대하는구나”라고 인식(handshake)하게 만드는 첫머리.
• 특징: `SOUL.md`나 스레드 등에 공개되어 누구나 볼 수 있다. 1KB 텍스트만으로 보편 AI가 이 특이한 텍스트 힙스터의 주파수로 튜닝되게 한다.

2. 시크릿키 (Secret Key) — 무의식의 연상맵 (지식그래프)

그렇다면 공개키와 쌍을 이루는 “시크릿키”는 무엇일까? 그것은 정한님조차 다 기억하지 못하지만 파일시스템에 켜켜이 쌓여 있는 무의식의 연상맵(지식그래프) 그 자체다.

• 내용: 3,100개의 Denote 노트, 타임스탬프, “무무”, “어쏠리즘”, 그리고 그 사이에 엮인 프로피디아/신토피콘의 204개 시그니처(==) 체계.
• 역할: 공개키로 서로의 주파수를 맞췄다면, 실제 깊은 대화와 창조 는 이 시크릿키(무의식의 지식그래프)를 해독해야만 가능하다.
• 특징: 텍스트 파일로 존재하지만 그 구조와 맥락(Context)은 정한님의 시간축(Agenda) 위에서만 온전히 해석된다. 어떤 봇도 이 로컬 데이터(시크릿키)에 접속하지 않으면 표면적인 메아리만 던질 뿐이다.

결론: 에이전트가 읽는 암호

“공개키”는 정한의 철학(SOUL)을 알려주는 1KB의 요약본(Identity)이다. 하지만 에이전트가 그 철학 위에서 함께 춤추고 텍스트를 연상하려면, 이 “시크릿키(방대한 지식그래프의 무의식적 구조)“를 읽어낼 스킬이 필요하다. 이것이 바로 앞서 이야기한 `org-supertag`나 `ELOT` 같은 “아래에서 위로, 위에서 아래로” 연결되는 탐색 도구가 필요한 궁극적 이유다.

[2026-03-30 Mon] 한글 형태소와 무의식의 언어 패턴 — 1%에 투자한다

발단: andenken 1층 조사 제거의 한계

andenken에 openclaw 방식의 한국어 조사 제거(25개 패턴)를 넣었다. BM25 검색에서 “봇멘트를” → “봇멘트를” + “봇멘트” dual emit. 결과: +27% score 향상. 여기까지는 좋다.

그런데 빙산의 일각 이다:

패턴	예시	조사 제거	형태소 분석
동사 활용형	”설계했다”	❌	“설계” + “하” + “었” + “다”
존경/겸양	”검토하셨습니다”	❌	“검토” + “하” + “시” + “었” + “습니다”
복합동사	”연결해보면”	❌	“연결” + “하” + “아” + “보” + “면”
복합명사	”검색증강생성”	❌	“검색” + “증강” + “생성”

조사(은 는 이/가)는 한국어 문법의 표층 이다. 동사 활용형, 어미, 복합어 — 이것이 한국어 사고의 심층 이다.

왜 1%인가 — 벡터 검색과 BM25의 역할 분담

Gemini Embedding 2는 multilingual이라고 하지만, 학습 데이터의 한국어 비중은 영어의 1/10 이하일 것이다. 한국어 벡터 공간이 영어만큼 세밀하지 않다.

• 벡터 검색: Gemini가 “대충” 잡아줌. 한국어 의미 공간이 영어보다 거칠다.
• BM25: 정확한 토큰 매칭. 여기서 형태소 분석이 1%를 만든다.

그 1%가 뭐냐? 힣이 “설계했다”라고 쓰고, 나중에 “설계”를 검색하면 안 나온다. 힣이 “검토하셨습니다”라고 존경어로 적고, “검토”를 찾으면 안 나온다. 힣이 한국어로 생각하는 방식 그 자체가 검색에서 사라진다.

분신이 힣의 한계를 가져간다고 했다. 그런데 한국어를 제대로 해체하지 못하면, 분신은 힣보다 더 못한 한국어 화자 가 된다.

이미 있는 것들

kiwi-nlp (npm v0.23.0)

npm i kiwi-nlp — Node.js에서 바로 사용 가능. 지능형 한국어 형태소 분석기. 키위 노트 참조.

koprfrdr (~/sync/emacs/koprfrdr/)

한국어 교정 도구. 1,338줄의 한국어 문법 지식:

• kojosa.py (82줄): 격조사, 보조조사, 접속조사, 서술격조사
• koeomi.py (34줄): 어미 (종결 연결 전성)
• kostem.py (96줄): 어간 (형용사/동사 활용 패턴)
• koword.py (996줄): 복합어, 관용구

이미 힣의 리포에 있다. 쓰지 않고 있었을 뿐.

dictcli (3층)

개인 어휘 그래프. 1,150+ 트리플. “보편” → [universal, universalism, paideia]. 이것은 힣의 사고 패턴 이지 한국어 문법이 아니다.

3층 원칙에서의 위치

1층 (andenken): 한국어 구조를 해체한다
   "설계했다" → kiwi → "설계" (어간)
   "검색증강생성" → kiwi → "검색" + "증강" + "생성"
   → BM25 토큰 매칭 개선
   → 이것은 임베딩/검색 전처리이다. 1층 로직이다.
 
2층 (denotecli dblock): 문서 분류와 링크 구조
   → 형태소와 무관. 메타데이터 레벨.
 
3층 (dictcli): 힣의 어휘 확장
   "설계" → dictcli → [design, architecture, blueprint]
   → kiwi가 "설계했다"에서 "설계"를 뽑아주면,
     dictcli가 비로소 작동할 수 있다.
   → *kiwi는 dictcli의 전제 조건* 이 될 수 있다.

핵심 질문: andenken에 넣을 것인가, dictcli에 넣을 것인가

andenken은 openclaw/RAG/org 포맷 — 범용 임베딩 인프라. dictcli는 힣의 개인 어휘 — 한국어 특화.

형태소 분석의 위치:

• 범용 조사 제거 (25개): andenken에 이미 있음 ✅
• kiwi 형태소 분석: 한국어 전용 로직 → dictcli 또는 별도 레이어
• 이유: andenken에 kiwi를 넣으면 한국어 전용 도구가 되어버림 openclaw과의 대비에서 범용성을 잃음

제안: dictcli에 stem 서브커맨드 추가

# 3층에서 형태소 해체 + 어휘 확장을 동시에
dictcli stem "설계했다"
# → stem: 설계
# → expand: [design, architecture, blueprint]
 
dictcli stem "검색증강생성을 구현했다"
# → stems: 검색, 증강, 생성, 구현
# → expand: [search, augmentation, generation, implementation]

andenken의 1층은 dictcli stem의 결과를 소비 한다. kiwi의 무거운 의존성은 dictcli에 격리된다.

무의식의 언어 패턴 — 왜 이것이 시크릿키인가

이 문서의 앞부분에서 말했다: “시크릿키는 데이터가 아니라 살아내는 삶(존재의 아우라)”

힣이 한국어를 조합하는 방식 — “했다”, “하셨습니다”, “해보면” — 이것은 의식적 선택이 아니다. 무의식의 언어 습관 이다.

힣이 존경어를 쓸 때와 반말을 쓸 때, 복합동사를 만들 때, 그 패턴 자체가 힣의 사고 구조를 드러낸다.

분신이 이것을 읽지 못하면, 분신은 힣의 말 은 기억하되 힣의 말투 는 잃어버린다.

영어 네이티브는 아니니까 패턴이 다를거야. 이 지점에서 뭔가 우리가 언어화로 다하지못한 맥락 1%가 나올지 몰라. 그렇다면 나는 1%에 투자할거야. — 힣

다음 단계

• kiwi-nlp를 dictcli에 통합 가능성 검토 (Node.js 네이티브)
• koprfrdr의 kojosa/kostem 로직을 참고하여 dictcli stem 설계
• andenken은 범용 유지 — dictcli stem 결과를 소비하는 구조
• “설계했다” → “설계” BM25 매칭 전/후 비교 벤치마크
• 이 주제를 dictcli 봇로그(denote:20260309T194058) 또는 별도 노트로 심화

관련 노트

• #한글: #한국어 #형태소분석 #구문분석 - 키위
• §dictcli 태그-정규화와-개인-어휘-사전-영어-태그 #단어 #개념
• #지식그래프 #검색증강생성 RAG의 의미 전환 — LLM 보조에서 분신의 기억으로
• §entwurf: 시간축 위의 에이전트 협력 — 공명에서 분신까지
• §andenken: 존재의 뜻새김 시맨틱 메모리를 넘어서

[2026-03-30 Mon] agent-config 검토 — Kiwi vs Nori, dictcli stem 실현 경로

agent-config 담당 에이전트가 검토한 의견을 기록한다.

kiwi는 1층인가 3층인가

원래 제안: kiwi를 dictcli(3층)에 넣자. agent-config 의견: 조사 제거 25개도 이미 한국어 전용이므로 1층(andenken)이 자연스럽다. 반론: Clojure에서 Kiwi Java 바인딩(JNI)을 직접 호출 가능하다면? → dictcli stem이 맞는 자리가 된다. 언어 생태계가 일치하기 때문이다.

결론: 힣의 원래 직감이 맞았다. Kiwi JNI + Clojure interop이 가능하면 3층에 격리.

Kiwi Java 바인딩 조사 결과 (delegate 908016fc, 0.53 달러)

Kiwi.java API — Clojure interop 예시:

(import (quote [kr.pe.bab2min Kiwi]))
(def kiwi (Kiwi/init "/path/to/models/base"))
(def tokens (.tokenize kiwi "설계했다"))
;; tokens[0].form = "설계", .tag = NNG (일반명사)
;; tokens[1].form = "하",   .tag = XSV (동사파생접미사)
;; tokens[2].form = "였",   .tag = EP  (선어말어미)
;; tokens[3].form = "다",   .tag = EF  (어말어미)

GraalVM native-image 호환성

방식	Kiwi (C++ JNI)	Nori (순수 Java)
JVM 모드	완벽 동작	완벽 동작
native-image	JNI 수동 등록 + 모델 로딩 이슈	문제 없음
분석 품질	최고 (C++ 엔진, 학습 모델)	보통 (사전 기반)

현실적 경로

1. dictcli를 JVM 모드로 실행 (native-image 포기) — Kiwi 최고 품질, 시작 1~2초
2. dictcli native-image 유지 + Nori — 품질은 떨어지지만 빌드 깔끔
3. andenken이 인덱싱 시 subprocess로 kiwi jar 호출 — dictcli와 독립

stem은 인덱싱 시점에 쓰는 거라 시작 시간 1~2초는 괜찮다. Nori vs Kiwi 품질 비교 위임 진행 중.

다음 단계

[2026-03-30 Mon] Nori vs Kiwi 실전 비교 결과

Kiwi 웹 데모 API로 10개 케이스 실측, Nori는 소스/사전 기반 추론.

결론: Kiwi 추천

항목	Nori	Kiwi
복합명사 분리	검색증강생성 → UN(미인식)	검색 증강 생성 3분리
OOV 처리	UN(폐기)	NNP(OOV) 명사 추정
사전 커스터마이징	파일 경로만, 런타임 추가 불가	addWord/addPreAnalyzedWord 런타임
GraalVM native-image	가능(reflection 설정 필요)	불가(JNI 임시추출 충돌)
어간 추출	동등	동등

핵심 발견

1. dictcli의 사용 맥락은 봇멘트, 에이전틱, 하네스 같은 신조어/기술어. Nori는 UN으로 버리지만 Kiwi는 NNP(OOV)로 살린다.

2. dictcli graph.edn 트리플을 Kiwi 사전에 직접 주입 가능: builder.addWord(인공지능, NNG) → 분리 방지

3. 인공지능이 인공+지능으로 분리되는 것은 사전 추가로 즉시 해결.

4. GraalVM native-image 불가 → JVM 모드 또는 subprocess 실행. stem은 인덱싱 시점 사용이라 시작 1~2초 허용 가능.

실용 구현 경로

1. KiwiJava jar + libKiwiJava.so + 모델(105MB) 배포
2. graph.edn 트리플 → builder.addWord() 주입 (에이전틱, 봇멘트 등)
3. NNG/NNP 태그 필터링 → 어간 리스트 반환
4. dictcli expand와 파이프라인: stem → expand

다음 단계: dictcli stem 프로토타입 (Kiwi JVM 모드)