Obsidian과 에이전트에게 지시할 때, 자체 제작된 용어를 사용하는 것이 좋다

로컬/클라우드 LLM을 에이전트로 만들고 Obsidian을 지식 스토어로 운영하다 보면, 지시가 제대로 전달되지 않는 순간을 자주 마주하게 됩니다.

원인을 모델의 지능에 돌리고 싶지만, 관찰을 계속하면 범인은 대부분 다른 곳에 있습니다.

여기서 에이전트에게 전달하는 '어휘'가 문제입니다.

이 글은 그 어휘 설계에 대한 하나의 결론을 제시합니다. 즉, Obsidian과 에이전트에게 지시할 때는 일반적인 단어가 아니라 **스스로 만든 용어(自家製造語)**를 사용해야 한다는 것입니다.

그리고 왜 이것이 단순한 '꾸밈'이나 '중2병'이 아니라, 검색(search)과 검색 증강 생성(retrieval) 양쪽에 효과적인 합리적인 설계 판단인지, '라멘 지로의 그 한마디'에서 설명하겠습니다.

라멘 지로에서는 면을 따라 물기를 빼는 과정이 끝날 무렵, 점원이 이렇게 묻습니다.

"마늘 넣을까요?" (ニンニク入れますか？)

이것은 단순한 확인 질문이 아닙니다. 손님이 **콜(call)**을 할 신호입니다. 손님은 여기서 '야사이 마시마시, 마늘, 아브라, 카라메'처럼 토핑 구성을 한 번에 선언합니다. 야사이(ヤサイ)는 데친 채소 더미, 마시(マシ)는 양 증가, 아브라(アブラ)는 비계, 카라메(カラメ)는 간장 소스 추가입니다. 아무것도 콜하지 않으면, 모든 것이 '보통'이 됩니다.

여기서 주목해야 할 것은 이 어휘의 성질입니다.

• 폐쇄된 공유 어휘이다.

'카라메'는 지로의 맥락 밖에서는 통하지 않습니다. 일반 라멘 가게에서 '카라메'라고 말하면 주방은 얼어붙습니다.

• 모호함이 없다.

'채소는 많이, 기름도 많이, 맛은 진하게 해주세요'와 같은 일반적인 단어로 된 주문은 해석의 폭을 가집니다. '많이'가 어느 정도인지는 점원의 재량에 맡겨지기 때문입니다.

반면 콜은 가게와 손님이 동일한 사전(dictionary)을 공유하고 있기 때문에, 일관되게 실행됩니다.

• 강제력이 있다.

콜은 '그 형식으로 말하지 않으면 제대로 전달되지 않는다'는 제약이 있습니다. 이는 동시에 전달의 정확성을 보장하는 메커니즘입니다.

결국 지로의 콜은,

폐쇄된 커뮤니티가 공유하며 모호함을 제거하기 위한 조어 체계 입니다.

그리고 이것은 우리가 에이전트에게 지시를 내릴 때 직면하는 문제와 구조적으로 매우 유사합니다.

설계의 핵심 ①

콜이 기능하는 이유는 '가게가 동일한 사전을 내재화하고 있기' 때문입니다. 손님의 콜은 가게 측의 지식 스토어가 없으면 의미를 가질 수 없습니다.

조어와 지식 스토어는 함께 작동할 때 비로소 힘을 발휘합니다.

에이전트에게 '이 집계(集約) 처리를 구현해 주세요'라고 지시했다고 가정해 봅시다. '집계'는 일반적인 단어입니다.

그러면 무슨 일이 벌어질까요?

LLM은 '집계'에 대해 파라미터 안에 방대한 지식을 가지고 있습니다. 그래서 에이전트는 Obsidian의 노트를 한 번도 열지 않고, 그럴듯한 일반론으로 답변을 구성해 버립니다.

프로그래밍에서 말하는 **캐시 히트(cache hit)**와 같습니다. 파라메트릭한 지식 공간에서 '집계'가 걸려버려서, 실제 스토어(Obsidian)로의 질의가 가지 않습니다.

돌아오는 답변은 유창하고 겉보기에는 정확합니다. 하지만 그것은 당신이 의도한 '집계'가 아닙니다.

당신의 설계 노트에 적힌 고유한 제약이나 전제를 전혀 반영하지 않은 것입니다.

유창함과 접지되지 않음(grounding)이 공존하는 답변. 이것이 가장 위험한 실패 모드입니다. 오류로 눈에 띄지 않기 때문입니다.

조어는 이를 구조적으로 막아냅니다. '시보형 집계'라는 단어는 LLM의 파라미터 안에 0건으로만 존재합니다. 따라서 캐시 미스(cache miss)가 보장됩니다. 미스가 나면, 에이전트는 검색 증강 생성(retrieval)에 의존할 수밖에 없습니다. 즉 Obsidian의 정의 노트를 가져갈 수밖에 없습니다.

여기까지를 고려하면, 'Obsidian과 에이전트에게 전달해야 할 단어'가 갖춰야 할 성질은 다음 4가지로 정리될 수 있습니다.

#	요구사항	일반어일 경우	조어일 경우
1	자신이 의미를 잊지 않는다	잊기 어렵다(하지만 오히트할 위험이 있음)	부품으로 재구성할 수 있다면 유지 가능
...

중요한 것은,

이 4가지를 동시에(AND로) 만족시키는 단어는 기존 어휘 중에는 존재하지 않는다는 것입니다.

요구사항 3과 요구사항 4를 충족시키려면, 그 단어는 일반어가어서는 안 됩니다. 요구사항 1과 요구사항 2를 충족시키려면, 그 단어는 의미 불명의 기호여서도 안 됩니다.

이 AND의 교집합에 남는 선택지는 오직 하나입니다. 바로 스스로 만들어내는 것입니다.

자체 제작된 용어는 4가지 요구사항으로부터 역산하여 도출되는 필연이며, 취미가 아닙니다.

4가지 요구사항 중에서 가장 깊은 곳에 있는 것은 요구사항 4이다. 이는 요구사항 3의 뒷면이기도 하다. '다른 단어와 섞이지 않는다'를 인간의 검색 편의성 측면에서 보면 요구사항 3이고, 에이전트의 retrieval (검색/추출) 편의성 측면에서 보면 요구사항 4가 된다. 동전의 양면과 같으며, 후자가 설계 목적으로서 더 본질적이다.

조어(造語, 만들어낸 단어)의 가장 큰 역할은,

에이전트가 "자신의 지식으로 얼버무리는" 경로를 물리적으로 차단하는 것에 있다.

소프트웨어 설계에서 말하는 forcing function (강제 함수) ── 바람직한 동작을 "선택지"가 아니라 "유일한 길"로 만들어 버리는 장치다.

설계의 핵심 ②

일반 용어는 에이전트에게 "답해도 되고, 스토어(store)를 참조해도 된다"라는 분기를 남긴다. 조어는 그 분기를 없앤다. 파라미터 내에서 일치하는 것이 없으므로, 스토어를 참조하는 것 외에는 길이 없어진다.

조어란, retrieval (검색/추출)을 "임의"에서 "강제"로 바꾸는 제약이다.

다만, 여기에는 미묘한 줄다리기가 존재한다.

요구사항 1(잊지 않음)과 요구사항 4(참조하게 만듦)는 완전히 양립할 수 없다.

조어가 "너무 읽히기 쉬우면", 즉 "정기 데이터 집약 처리"처럼 구성 요소로부터 의미가 완전히 복원되어 버리면, 에이전트 또한 똑같이 구성 요소를 분해하여 "아, 주기적인 집약에 관한 것이구나"라고 파라메트릭(parametric)하게 즉답해 버린다. forcing function (강제 함수)이 새어 나가는 것이다.

반대로, 완전한 기호(Project Zircon과 같은 코드네임)로 만들면 요구사항 4는 완벽하게 충족하지만, 요구사항 1이 죽는다. 반년 뒤의 내가 그 단어의 의미를 기억하지 못하게 된다.

명명 유형	예시	요구사항 1(잊지 않음)	요구사항 4(참조하게 만듦)	판정
완전한 기호 / 코드네임	Project Zircon	✕ 잊어버리면 끝	◎ 반드시 캐시 미스 발생	요구사항 1에서 실패
완전히 분해 가능한 구절	「정기 데이터 집약 처리」	◎	△ 에이전트도 분해하여 즉답	forcing function이 새어나감
마크가 붙은 조어	「시보형 집약」	○ 구성 요소로 재구성 가능	○ 비표준이므로 "정의어"임을 알 수 있음	★ 목표로 하는 대역

좋은 조어가 목표로 하는 것은 바로 이 좁은 대역이다 ── 인간은 구성 요소로부터 재구성할 수 있지만, 에이전트에게는 "이것은 정의어이며 일반 구절이 아니다"라고 보이는 정도의, 마크가 붙은 단어.

「시보형 집약」에서 「시보형」이라는 수식어는 충분히 비표준적이므로, 딱 이 대역에 걸친다. 인간은 "시보처럼 정해진 시간에 동작하는 것"이라고 재구성할 수 있고, 에이전트는 "'시보형'이라는 표준적이지 않은 수식 ── 이것은 정의된 단어구나"라고 알아챌 수 있다.

이 부분이 마지막이자, 실무적으로 가장 중요한 지점이다.

조어는 캐시 미스의 기회를 만들 뿐이다. 그 미스를 실제로 Obsidian까지 가지러 갈 것인지, 아니면 구성 요소 분해로 멋대로 메울 것인지는 에이전트 측의 프로토콜에 달려 있다. 조어만으로는 tripwire (트립와이어)가 완성되지 않는다. 다음 4가지를 조합해야 비로소 신뢰할 수 있는 장치가 된다.

1. 노트 본문에서 조어를 사용할 때는 [[시보형 집약]]과 같이 wikilink로 작성한다. 이는 단순한 내비게이션이 아니다. "이것은 정의된 노드이며 일반 구절이 아니다"라는 **타입 주석 (type annotation)**이자, 에이전트에 대한 마킹 신호다.

2. 조어의 유일한 실패 모드는 "단어 그 자체를 잊어버리는 것"이다. 이를 구제하기 위해 정의 노트의 frontmatter에 자연어 표현을 넣어둔다.

---
aliases:
- 정기 집약
...

이렇게 하면 조어를 기억하고 있더라도, 잊어버려서 "정기 집약"이라고 입력해도 동일한 노트에 도달한다. 조어의 날카로움(일의성)과 자연어의 포괄성을 모두 잡을 수 있다.

3. 조어를 정의 한 줄과 함께 나열한 색인 노트(MOC)를 준비한다. "단어 그 자체를 완전히 잊어버렸다"는 마지막 실패 모드는 이 목록을 훑어봄으로써 구제된다. 검색이 미검색(no hit)을 반환하는 유일한 케이스를 index (색인)가 포착해낸다.

4. 시스템 프롬프트나 규칙 파일 등에서 다음과 같이 명시한다 ── "제약 마크가 붙은 단어(wikilink된 단어, 용어/조어 태그를 가진 단어)를 만나면, 답하기 전에 반드시 정의 노트를 retrieval (검색/추출)하라". 조어가 tripwire라면, 이것은 그 와이어에 연결되는 회로다. 와이어만 설치하고 회로가 없다면 아무 일도 일어나지 않는다.

이 그림은 지로(Jiro) 라멘 카운터와 같은 구조다. 손님과 점원 사이에 "콜(call)"이 있고, 콜은 가게의 내부 시스템(사전)을 통해 해결되며, 그 사전이 주방과 손님 양측에 동일한 의미를 공급한다.

이 글의 주장은 프로그래밍 언어로 한 마디로 압축할 수 있다.

일반어는 magic string (매직 스트링)이다. 소스 코드에 직접 작성된 문자열 리터럴(string literal) ── 컴파일러는 그 의미를 알지 못하며, 타입 체크 (type check)도 할 수 없고, 어디서 무엇을 가리키는지 추적할 수도 없다.

자체 제작어는 네임스페이스 (namespace)가 포함된 typed symbol (타입이 지정된 심볼)이다. 정의가 한 곳에 존재하며 (정의 노트), 참조는 타입이 지정되어 있고 (wikilink), 컴파일러 (에이전트)는 그것을 마음대로 다른 것으로 타입 강제 (type casting)할 수 없다.

지로(二郎)의 콜(call)로 돌아가면 ── "야채 많이"는 magic string이고, "야사이 마시마시(ヤサイマシマシ)"는 typed symbol이다. 전자는 가게의 재량에 해석을 맡기지만, 후자는 가게와 손님의 공유 사전에 의해 일의적으로 해결된다.

마지막으로, 조금 더 큰 틀에 연결해 두고 싶다.

필자는 이 시리즈를 통해 에이전트를 **「지능 × 문맥 = 인격」**이라는 형태로 파악해 왔다. LLM이 보유하는 것은 지능뿐이며, 지식·특성·제약은 외부화된다 ── 라는 비대칭적 설계다.

자체 제작어는 이 틀 안에서 제약 (문맥)의 일종으로서 작동한다. 그것은 지능을 LLM 측에, 의미와 지식을 Obsidian 측에 붙여둔 채로 그 경계가 새어 나가지 않도록 하기 위한 **인터페이스의 잠금 (interface lock)**이다. 조어(造語)는 에이전트가 경계를 넘어 "자신의 지능으로 의미를 채우는 것"을 방지한다.

따라서 자체 제작어를 만드는 행위는 노트 작성의 비용이 아니다. 그것은 검색 정밀도 (인간)와 retrieval (리트리벌) 정밀도 (에이전트) 양쪽 모두에 동시에 배당을 창출하는 투자이며, 에이전트의 인격을 당신의 스토어에 계속 접지 (grounding)시키기 위한 설계상의 필수 부품이다.

다음에 Obsidian에서 새로운 개념에 이름을 붙일 때, 기억해 주길 바란다. 에이전트는 면수를 뺀 후 당신에게 이렇게 묻고 있다 ── "마늘 넣으시겠습니까?".

그곳에서 일반어를 답할 것인가, 아니면 당신과 에이전트에게만 통하는 콜을 답할 것인가. 그것이 접지된 인격을 가진 에이전트와, 유창하기만 한 에이전트를 가른다.

나 개인적으로는 Obsidian이나 Vault가 일본어와 상성이 좋지 않아 자동 음성으로 포착되기 어렵기 때문에, Vault 전체를 「포치 노트(ポチノート)」라고 독자적으로 호칭하기도 한다. 언어가 오염되거나 새로운 말이 태어나지는 않을까 조금은 가끔 걱정되기도 한다.