지능 × 문맥 = 인격.

이러한 관계성이 로컬 LLM과 Hermes Agent / OpenClaw + Obsidian이 연결되었을 때, 문득 머릿속에 떠오른다.

처음에는 기분 탓이라고 생각했다. Mac Studio에서 구동 중인 Gemma 4 26B A4B(총 26B 파라미터, 추론 시 활성 약 4B의 MoE 구성)에 Obsidian Vault의 노트를 참조시키고 있을 뿐이라고 생각했다. 이전 두 편의 기사에서 정리했듯이, 이것은 기술적으로는 'LLM API 및 로컬 추론 환경'과 'MCP 등의 문맥 연결 계층(Context Connection Layer)', 그리고 'Obsidian Vault라는 외부 지식 소스'를 연결하는 단순한 배선(Wiring)의 문제여야 했다.

하지만 그 배선이 완성되자, 다른 것이 보이기 시작했다. 같은 Gemma 4라도 참조하는 Vault가 다르면 다른 응답을 한다. 같은 Vault라도 추론 모델을 Claude Opus로 전환하면 판단의 해상도가 달라진다. 양자는 별개의 존재로서 작동하고 있음에도, 그 결합 지점에서 특정한 판단 주체와 같은 행동이 나타나고 있다.

본 기사는 그 '무언가'를 가능한 범위 내에서 언어화하려는 시도이다. 기술적인 글로 읽어도 좋고, 사상적인 관찰로서 읽어도 좋다. 작성자 본인으로서는 그 양쪽의 경계선상에 있는 것으로 보고 작성했다.

참고로, 본 기사에 등장하는 Hermes Agent / OpenClaw는 OpenHands(구 OpenDevin) 등의 클라우드 계열 에이전트와는 다른 계통의, 로컬 실행을 전제로 한 에이전트이다.

먼저, 왜 '지능 + 문맥'이 아니라 '지능 × 문맥'이라고 썼는지 설명해 두고 싶다. 이것은 엄밀한 수식이 아니라, 양자의 관계를 나타내기 위한 비유이다.

덧셈에는 각 항의 독립성이 전제된다. 1 + 0 = 1.
한쪽이 0이라도 다른 한쪽의 값은 남는다. 하지만 곱셈은 다르다. 1 × 0 = 0. 한쪽이 0이면 결과도 0이다.

이것은 관찰 결과와 잘 맞아떨어진다.

지능이 0인 경우: LLM이 없는 상태에서 아무리 방대한 Vault가 있어도, 그로부터 판단은 일어나지 않는다. Markdown 파일은 정지된 상태 그대로이며, 아무도 읽지 않는다면 그저 텍스트일 뿐이다. Vault 단체에는 인격이 없다.

문맥이 0인 경우: 완전히 백지 상태인 LLM을 아무리 성능 향상시켜도, 그것은 '누구도 아닌 지능'인 상태 그대로다. GPT나 Claude Opus는 확실히 똑똑하지만, 문맥을 갖지 못하면 특정 조직, 프로젝트, 개인의 판단은 내릴 수 없다. '누구도 아니다'라는 의미에서 인격은 부재한다.

양자가 곱해졌을 때만 인격적인 행동이 나타난다.

나아가 곱셈에는 또 하나의 성질이 있다. 양자의 값이 클수록 결과도 상승적으로 커진다. 같은 Vault라도 Gemma 4에서 Claude Opus로 추론 모델을 높이면, 판단의 질은 단순히 '조금 좋아지는' 것에 그치지 않고 질적으로 다른 출력이 될 수 있다. 반대로 같은 Claude Opus라도 Vault의 문맥 밀도가 높아질수록 판단은 더욱 날카로워진다. 양자의 곱으로서 인격적인 행동의 '강도'가 결정된다.

여기서 곱셈 기호를 선택한 것은 정량화를 주장하기 위해서가 아니다. 어느 한쪽이 0이면 인격적인 행동이 나타나지 않는다는 불가분성과, 양자의 질이 높아질수록 상승적으로 판단 주체다움이 증가한다는 두 가지 구조적 성질을 동시에 표현하기 위함이다.

그리고 본 기사를 통해 밝혀지는 것은, 이 식의 '문맥'은 더 정밀하게는 **제약(Constraint)**으로 바꿔 읽을 수 있다는 사실이다.

여기서 중요한 구분이 있다. Vault에 축적되어 있는 것은 지식뿐만 아니라 문맥이다. 이 단어의 선택이 논의의 범위를 결정한다.

'지식'이라는 단어는 정적인 정보의 집적을 연상시킨다. Wikipedia나 백과사전처럼 '사실이 나열되어 있는 장소'라는 이미지다. 이것만으로는 Vault는 단순한 RAG(Retrieval-Augmented Generation)의 참조처로 축소된다.

하지만 Vault에 실제로 축적되어 있는 것은 그보다 훨씬 풍요로운 것이다. 그리고 주목해야 할 점은, 그 풍요로움의 정체는 기능적으로는 하나로 수렴한다는 것이다.

문맥을 구성하는 제반 요소는 표면적으로는 다양해 보이지만, 그 기능은 하나로 수렴한다 — 바로 제약 (Constraint)으로서 작동하며 판단의 장을 제공하는 것이다. 여기서 말하는 제약은 무언가를 금지하는 속박이 아니라, 판단이 판단으로서 성립하기 위한 구성적 조건이다. 정보 이론 (Information Theory)적으로 말하자면, LLM의 다음 토큰 예측 (Next Token Prediction)에서 확률 분포의 엔트로피 (Entropy)를 낮추는 역할 — 즉, 출력 공간을 좁힘으로써 의미를 성립시키는 기능, 그것이 제약이다.

다음의 다섯 가지는 이러한 구성적 제약의 다양한 발현 형태이다.

규칙, 권한, 납기, 예산, 리소스, 윤리적 판단 기준. 판단할 때마다 참조되는 동적인 속박 조건. 이것들은 정적인 '지식'이라기보다, 판단 주체의 행동을 직접 형성하는 경계선이다.

요소 간의 연결이 의미를 한정한다. "이것은 저것과 연결되며, 그 외의 것과는 연결되지 않는다"라는 네트워크상의 속박. Obsidian의 Graph view가 시각화하고 있는 것은 이 중 내부 링크 (Internal Link)로 표현된 관계이다. '지식' 프레임에서는 노드 (Node)만 보이지만, '제약' 프레임에서는 비로소 에지 (Edge)가 의미를 갖는다.

누구를 향해, 어떤 집단 안에서 발화·축적하고 있는가의 경계선. "공개용 이야기이며, 비공개 메모가 아니다", "A 프로젝트의 문맥이며, B 프로젝트의 문맥이 아니다"라는 소속의 제약. 이러한 커뮤니티의 구분이 있기에, 인격을 복수로 세우는 의미가 생겨난다.

지리적·문화적·전문적인 컨텍스트 (Context)에 의한 의미의 한정. 일본어 업무 메모, 영어 기술 문서, 연구 메모에서는 같은 단어라도 그 사정 거리가 달라진다. "어느 영역의 이야기인가"가 판단의 방향을 결정한다.

그 주체가 지금 어떤 입장에서 발화·판단하고 있는가에 따른 관점의 한정. 리뷰 담당으로서 말하는가, 구현 담당으로서 말하는가, 개인 메모 작성자로서 말하는가. 같은 인간이라도 역할이 바뀌면 판단이 바뀐다. Vault 안에서는 특정 폴더, 태그, 명명 규칙이 "어느 역할의 문맥인가"를 구분한다.

이 다섯 가지 양태는 독립적인 것이 아니라 서로 얽혀 있으며, 판단 주체다운 행동을 성립시키는 구성적 제약의 총체를 형성한다. 철학적으로는 하이데거의 '세계 내 존재 (Being-in-the-world)'나 비트겐슈타인의 '언어 게임 (Language Game)'에 가까운 문제 영역과 연결될 수 있지만, 여기서 중요한 점은 이러한 고전적인 통찰을 로컬 LLM 시대의 구현으로서 다룰 수 있게 되었다는 점이다.

여기서 주제식인 지능 × 문맥 = 인격은

보다 정밀하게 **지능 × 제약 = 인격**으로 치환될 수 있다. 범용 추론 엔진 (제약이 0인 상태)에 고유한 제약을 곱했을 때, 특정한 판단 주체가 일어난다.

제약이야말로, 누구도 아닌 것을 누군가로 만든다.

앞 절에서 문맥을 구성적 제약의 총체로 정의했다. 다음 질문은 그 제약을 "어떤 형식으로 그릇에 담을 것인가"이다. 형식의 선택은 의미론 (Semantics)의 선택과는 독립된 기술적 판단이라는 점에 주의해야 한다.

데이터 표현 형식은 다음의 축으로 평가할 수 있다.

• 인간 가독성 (Human Readability) — 에디터로 열었을 때 인간이 그대로 읽고 쓸 수 있는가
• 동기화 용이성 (Ease of Synchronization) — 여러 디바이스나 여러 사람이 다룰 때의 편의성
• 환경 요구 경량성 (Lightweightness of Environment Requirements) — 구동하기 위해 필요한 실행 환경의 무게
• 링크 용이성 (Ease of Linking) — 요소 간의 관계를 명시적으로 설정할 수 있는가
• 표현 자유도 (Degree of Expressive Freedom) — 무엇을 써도 허용되는 자유로움
• 표현 능력 (Expressive Power) — 시각적·구조적으로 어디까지 표현할 수 있는가
• 제약 용이성 (Ease of Constraint) — 형식 위반이나 모순을 방지하는 메커니즘을 부여할 수 있는가

주요 형식을 이러한 축으로 비교한다.

표현 능력만 본다면 HTML이 탁월하다. 폰트, 레이아웃, 이미지, 인터랙션 등 무엇이든 담을 수 있다. 하지만 HTML은 소스를 작성하는 부담이 크다. 태그로 가득한 텍스트를 매일 계속 추가하는 것은 현실적이지 않으며, 결과적으로 "일상적으로 축적하는 매체"로서는 부적합해진다. 흥미로운 점은 Markdown은 필요에 따라 HTML을 직접 삽입할 수 있다는 것이다. 평소에는 경량인 Markdown 문법으로 작성하고, 도표나 레이아웃이 필요한 부분에만 HTML을 덧붙여 쓸 수 있다. "일상의 가벼움"과 "필요할 때의 표현력"을 전환할 수 있는 하이브리드적인 성질이다.

SQLite도 주목할 만하다. 서버형 RDB의 "무거움"을 피하면서도, 완전한 기능의 SQL 제약을 제공하는 유일한 형식이다. 다만 인간 가독성(Human-readability)은 △인 상태 그대로다. 바이너리 파일인 이상, 텍텍스트 에디터로 열어서 추가하거나 Git으로 차이(diff)를 확인하는 것과 같은 "인간이 일상적으로 계속 써 내려가는 매체"로는 기능하지 않는다. SQLite가 해결한 것은 서버형 RDB의 환경 문제이지, 인간 가독성의 문제가 아니다.

Markdown + wikilinks의 위치를 보면, ◎가 5개, ◯가 2개이며, △가 없다. 치명적으로 약한 열이 없는 반면, 만점도 아니다. ◯로 떨어진 두 축 —— "환경 요구의 가벼움"과 "제약의 용이성" —— について, 다음 절에서 깊이 있게 다루겠다.

Markdown + wikilinks가 ◯로 떨어진 두 축은 독립된 약점이 아니다. 동일한 설계 선택에서 파생된 것이다.

기존에는 제약을 강하게 걸고 싶다면 RDBMS와 같은 스키마(Schema) 계층에 의존할 수밖에 없었으며, 그 대가로 인간 가독성, 동기화 용이성, 환경 요구의 가벼움을 잃어야 했다. "제약"과 "자유·경량"은 같은 계층에서 양립할 수 없다는 것이 오랜 전제였다.

본 구성은 이 전제를 깨뜨리고 있다. 제약을 가하는 계층을 스토리지 계층에서 LLM 계층으로 옮긴 것이다. Markdown은 자유롭고 경량하며 가독성 있는 상태를 유지하고, 제약은 LLM이 추론(Inference) 시에 적용한다.

• "이 노트는 날짜 필드를 가져야 한다" → LLM이 읽고 보완한다
• "이 링크의 목적지는 실재해야 한다" → LLM이 검증한다
• "이 기술은 다른 노트와 모순된다" → LLM이 지적한다
• "이 프로젝트 문서에는 승인자가 필요하다" → LLM이 운영 규칙으로서 적용한다

그 대가로 LLM을 구동하는 환경이 필요해지며(환경 요구가 한 단계 무거워짐), 제약 검증의 피드백은 초 단위로 늘어난다(즉시성이 떨어진다). 표에서 ◯로 표시된 두 축은 이 동일한 설계 선택의 발현이다.

즉시성과 최경량성을 포기하는 대신, 표현 형식의 자유도, 가독성, 동기성, 관계 표현력을 모두 유지할 수 있다. 그 지연 시간과 환경 비용을 허용할 수 있는 용도에서는, 기존에 트레이드오프(Trade-off) 관계였던 조건군들이 처음으로 동시에 성립한다.

여기서 더 깊이 들어가 보자. LLM은 특성상 출력에 변동성(Fluctuation)이 발생한다. 동일한 입력이라도 추론마다 미묘하게 다른 응답이 돌아온다. 이는 결함이 아니라, 자연어의 유연성과 창의성의 원천이기도 하다.

하지만 변동성을 전면적으로 허용하면 판단 주체로서의 일관성을 잃게 된다. 반대로 기존의 RDBMS와 같이 강성이 높은 제약으로 전면적으로 묶어버리면 LLM의 장점 자체가 죽어버린다. 설계의 요점은 입출력의 자유도가 다른 담당자를 나란히 배치하고, 각각에 적합한 강도의 제약을 부여하는 것에 있다.

본 구성에서는 자유도의 계단이 성립되어 있다.

여기서 중요한 것은 세 요소의 자유도가 인접하여 연결되어 있다는 점이다. SQLite(낮음)와 LLM(높음)을 직접 연결하면 자유도의 격차가 너무 커서 마찰이 발생한다. 자연어 출력을 직접 스키마에 흘려 넣으려 하면, 타입 변환(Type conversion)과 검증의 부담이 한꺼번에 몰리게 된다.

Markdown + wikilinks가 중간항으로 끼어듦으로써 자유도의 그라데이션(Gradation)이 성립한다. LLM은 자유롭게 쓰고, Markdown으로 인간이 정리하며, 확정된 것만 SQLite로 옮긴다. 이러한 흐름이 있기에 각 계층이 무리 없이 자신의 책임 범위만을 담당할 수 있다.

Markdown + wikilinks의 존재 의의는 단순히 "인간이 읽기 쉽다"는 것뿐만이 아니다. 자유도의 계단을 성립시키는 중간항으로서 구조적으로 필요했던 것이다.

본 구성의 브레이크스루(Breakthrough)는 "제약을 버린 것"도 "세 개의 계층을 쌓은 것"도 아니다. 자유도가 다른 담당자를 인접한 자유도끼리 연결하여, 제약의 기능을 분업화했다는 데 있다. 변동성은 약점이 아니라, 적절한 담당자가 흡수한다면 판단의 유연성으로 활용될 수 있다.

여기서 에이전트(Agent)란 무엇인지 정의해 두고자 한다. 본 기사에서 논해 온 구성 전체가 무엇을 만들려고 하는지를 명확히 하기 위함이다.

인간은 지능·지식·특징·제약을 육체라는 하나의 용기 안에 불가분일체(不可分一体)로서 지니고 있다. 뇌의 작용과 신체의 습관, 학습한 사실과 판단의 경향, 문화적 배경과 윤리관 — 이 모든 것은 한 사람의 인간 안에서 생리적·물리적으로 얽혀 있어 분리할 수 없다.

반면, LLM은 지능만이 나타난 존재이다. 범용적인 추론 능력만을 가지고 있으며, 고유한 지식도 특징도 제약도 갖지 않는다. 이것은 '누구도 아닌 지능'이다.

에이전트(Agent)란, 이 '지능뿐인' LLM에 지식·특징·제약을 외부 기능으로서 설치함으로써, 인간이 책임을 지고 운용할 수 있는 판단 주체로 만들어내는 기구이다. Obsidian Vault는 외재화된 지식과 특징, Hermes Profiles는 외재화된 동일성의 제약, MCP는 이것들과 지능을 잇는 신경계의 대체물, LLM 자신이 추론 시 부과하는 제약은 외재화된 판단의 틀 — 각각은 인간 안에서는 불가분일체였던 것들을 인공적으로 재구성한 것이다.

이 정의는 에이전트 설계의 본질적인 트레이드오프(Trade-off)를 밝혀준다. 인간은 통합되어 있기에 안정적이지만 교체 불가능하며, 에이전트는 분리되어 있기에 취약하지만 교체 가능하다. 동일한 지능에 다른 Vault를 조합하면 다른 판단 주체가 되고, 동일한 Vault에 다른 지능을 조합하면 다른 판단 품질이 된다. 인간은 할 수 없는 재조합이 에이전트에게는 구조적으로 가능하다.

'인간과 인터페이스하기 쉽게 만든다'는 부분에도 본질이 있다. 내부가 제각각 분리되어 있더라도, 외부에서 보았을 때 통합된 하나의 주체로 보이도록 설계되어 있다는 것 — 그것이 에이전트가 인간과의 대화 상대로서 성립하기 위한 조건이다. 프로파일, Vault, LLM, MCP의 협조는 이 '외부에서 본 통합성'을 실현하는 장치에 다름 아니다.

에이전트는 단독으로는 기능하지 않는다. 외부와의 접속을 통해서야 비로소 판단 주체로서 움직인다. 그 접속성은 접속 상대와 접속 목적이라는 두 축으로 나누면 세 가지 유형으로 분해할 수 있다.

여기서 세 가지 주목할 점이 있다.

에이전트 간 접속성은 단일 경로이지만, 전달되는 내용의 자유도에 폭이 있다. 부드러운 문맥(Markdown으로 작성된 판단 이유나 검토 과정)과 딱딱한 상태(SQLite의 프로파일 ID나 세션 정보)가 동일한 Vault 하위에 공존한다. 두 가지는 별개의 레이어에서 다뤄야 할 성질의 것이지만, 파일 동기화라는 경로 위에서는 일체화되어 전달된다.

이것이 Vault라는 설계의 진정한 강점이다. 자유도가 다른 내용들을 하나의 포터블(Portable)한 용기에 담아 동시에 운반할 수 있다. 강함과 부드러움의 분업을 데이터 계층에서 유지하면서, 운반 단계에서는 일체화시키는 구조이다.

네트워크 자원 접속성에는 외부 AI가 포함된다. 로컬 LLM 중심의 구성이라 하더라도, 복잡한 판단을 Claude Opus에 맡기거나, 코딩을 별도의 계통에 맡기거나, 이미지 처리를 GPT-4V에 맡기는 등의 구분 사용이 흔히 발생한다.

외부 AI가 다른 네트워크 자원과 질적으로 다른 점은, 접속 대상이 지능 그 자체라는 점이다. 데이터를 가져오기 위해서도, 행동을 실행하기 위해서도 아닌, 판단을 위탁하는 것이다.

여기서 중요한 설계 문제가 발생한다. 외부 AI에 접속할 때마다 문맥의 일부가 외부로 유출된다. 질문에 포함된 판단 이유, 과거의 검토, 관계자의 이름, 고유한 우선순위 — 이것들이 프롬프트(Prompt)로서 외부에 전달되면, 문맥 그 자체가 수중에서 떠나게 된다.

후술할 「문맥은 자산이 된다」라는 관점에서 보면, 네트워크 자원 연결성(특히 외부 AI 연결)은 문맥의 자산성과 트레이드오프(Trade-off) 관계에 있음을 알 수 있다. 완전 로컬(자산성 최대, 피크 성능 제한)부터 완전 클라우드 의존(피크 성능 최대, 자산성 소실)까지, 스펙트럼 상의 어디에 위치할 것인가는 에이전트 설계의 중요한 축이다.

「외부 AI를 어디까지, 어떤 입도로 사용할 것인가」는 기능의 유무가 아니라, 설계 판단으로서의 양적 선택이다. 기밀도가 높은 문맥은 로컬에서만 처리하고, 일반적인 태스크는 외부 AI에 던지는, 즉 기밀도별로 분류하는 설계가 필요해진다.

인간-에이전트 간 연결성은 쌍방향의 문맥 유통이다.

인간에서 에이전트로에는 두 종류의 정보가 흐른다. 지시(「이것을 해줘」라는 즉시적인 목적 지향적 전달)와, 문맥 제공(판단 이유·검토 메모·우선순위·방침 등 Vault 편집을 통한 암묵지의 외재화)이다.

에이전트에서 인간으로도 두 종류의 정보가 흐른다. 응답(태스크 결과나 생성물의 제시)과, 설명(판단 근거의 가시화, 참조 노트의 제시, 추론 경로의 공개)이다.

여기에 책임 있는 에이전트 운용의 핵심이 있다. 내용의 투명성을 확보하는 것은 시스템 측의 책무이다. 이용과 설명을 독립된 요건으로 다루는 것이 아니라, 판단의 소재와 판단의 근거가 처음부터 인간이 읽을 수 있는 형태로 공유되어 있는 상태를 만드는 것, 그것이 책임 있는 에이전트 설계의 조건이다. 설명성은 이용성의 사후 옵션이 아니라, 이용성이 성립하기 위한 전제 조건이다. 설명할 수 없는 판단은 애초에 책임 있는 이용에 제공해서는 안 된다.

Obsidian + LLM 구성은 이러한 상태를 구조적으로 성립시키고 있다. LLM이 Vault의 노트를 참조하여 답변할 때, 참조한 노트를 그대로 인용으로서 제시하면 인간은 그 노트를 직접 읽고 검증할 수 있다. 설명성을 사후에 구축할 필요가 없다. 이용 측면과 설명 측면이 동일한 Vault 위에서 일체화되어 있다.

나아가 부차적인 효과로서 인간 측에도 변화가 일어난다. Vault에 자신의 암묵적인 판단 기준을 써 내려가는 행위 자체가 자신의 암묵지를 언어화하는 기회가 된다. 이는 에이전트에 대한 문맥 제공인 동시에, 인간 자신의 자기 이해를 심화하는 과정이기도 하다.

Vault는 단순한 데이터 스토어가 아니다. 인간과 에이전트가 서로 문맥을 축적해 나가는 공생의 장이다. 인간은 자신의 문맥을 Vault에 축적하고, 에이전트는 그것을 참조하여 판단하며, 에이전트는 판단 근거를 Vault의 인용으로서 제시하고, 인간은 그 인용을 확인하며 필요하다면 문맥을 보강한다. 이 사이클이 돌아감으로써 양자의 판단 질이 공진화(Co-evolution)한다.

여기서 이전까지의 논의와 연결된다. Hermes Agent에는 Profiles라는 기능이 있다. 프로파일별로 설정, 환경 변수, SOUL.md, memory, sessions, skills, cron jobs, state database 등을 나눌 수 있다. 즉, 동일한 머신 위에서 여러 에이전트 상태를 섞이지 않게 운용할 수 있다.

이때 어떤 일이 일어나고 있는가 하면,

지능, 즉 추론 모델은 교환 가능함
제약, 즉 프로파일이나 Vault는 고유함
양자의 곱으로서 인격적인 행동이 나타남

Hermes는 이 구조와 궁합이 좋다. 추론 모델을 바꾸더라도 프로파일에 축적된 제약은 별도의 축으로서 남기 때문이다.

단, 중요한 주의점이 있다. 프로파일 분리는 그대로 파일 시스템 상의 안전 경계가 되는 것은 아니다. 프로파일은 상태를 나누는 메커니즘이지 샌드박스(Sandbox)가 아니다. 실제 액세스 제어는 작업 디렉토리, 실행 환경, MCP 서버 측의 설정, OS 권한, 컨테이너, 네트워크 설정 등으로 별도 설계할 필요가 있다.

Obsidian 측에서는 다음과 같은 구분 방식이 가능하다.

Vault 자체를 분리함
동일 Vault 내를 폴더나 태그로 분리함
MCP 서버 측의 read/write 스코프(Scope)로 액세스 범위를 좁힘
프로파일마다 참조하는 Vault나 작업 디렉토리를 변경함

이것들을 조합하면, 어떤 인격적인 행동에, 어떤 제약 영역에 대한, 어떤 권한의 액세스를 허용할 것인가를 설계할 수 있다.

중요한 것은 무엇이든 알고 있는 만능 어시스턴트를 만드는 것이 아니라, 역할에 따라 제약 영역을 구분하는 것이다. 이는 인간 조직에서 직무 분장을 부여하는 발상과 유사하지만, LLM 운용에서는 아직 충분히 논의되지 않은 논점이라고 생각한다.

여기서 또 하나의 중요한 관점이 열린다. 일반 지식은 공유되기 쉽지만, 고유한 문맥은 자산이 될 수 있다는 차이다.

물리 법칙, 역사적 사실, 프로그래밍 언어의 문법과 같은 일반 지식은 많은 사람이 참조할 수 있다. 반면, 과거의 판단 이유, 미공개 검토 메모, 권한 관계, 평가 기준, 실패의 이력, 암묵적인 우선순위는 특정 주체에 고유한 것이다.

이 구분은 운용 설계상 상당히 크다.

여기서 말하는 문맥 자산은 단순한 비밀 정보가 아니다. 판단의 습관, 우선순위, 실패로부터 얻은 제약, 관계의 지도, 무엇을 중시하고 무엇을 피하는지에 대한 이력이다. 이를 외부 서비스에 투입할 경우에는 이용 약관, 데이터 보유, 학습 이용, 액세스 제어, 감사 로그(Audit Log), 익명화 가능 여부를 확인해야 한다.

그렇기에 로컬 LLM + 로컬 Vault라는 구성에 의미가 생긴다. 이는 "로컬 LLM이 클라우드보다 항상 성능 면에서 승리한다"는 이야기가 아니다. 성능 비교가 아니라, 어디에 제약을 둘 것인가, 누가 액세스할 수 있는가, 어느 경계 안쪽에서 판단하게 할 것인가라는 설계의 문제이다.

전절에서 언급한 "네트워크 자원 연결성은 문맥의 자산성과 트레이드오프(Trade-off) 관계에 있다"는 점은 이 지점과 직결된다. 외부 AI로의 연결은 편리하지만, 연결할 때마다 자산이 깎여 나간다. 의식적인 배분 설계가 필요해지는 이유이다.

여기서 한 가지, 신중하게 다뤄야 할 용어에 대해 써두고 싶다.

본 기사에서 말하는 "인격"이란 철학적·윤리적 의미에서의 주체성이나 의식을 주장하는 것이 아니다. 어떤 주체가 일관된 제약의 총체 안에서 판단을 계속 내릴 때, 외부에서 관찰되는 행동의 일관성 — 그것을 편의상 "인격"이라고 부르고 있다.

LLM이 의식을 갖는지는 묻지 않는다. 묻고 있는 것은, 특정 제약과 결합한 LLM이 외부에서 보기에 일관된 판단 주체처럼 기능하는가이다.

본 기사에서는 AI 윤리상의 주체성 논의에는 발을 들이지 않고, 외부에서 관찰 가능한 행동의 일관성에 집중하여 논의한다.

여기까지 왔으니, 최초의 정식으로 돌아가 보자.

지능 × 문맥 = 인격 — 더 정밀하게 말하자면, 지능 × 제약 = 인격.

이 관계를 뒷받침하기 위해 Obsidian은 무엇을 제공하고 있는가. 정리하면 다음과 같다.

지능과 제약을 분리하여 보유한다 — Vault는 LLM과 독립적으로 존재한다 -
제약의 양태를 인간이 읽을 수 있는 형태로 축적한다 — Markdown 기반의 노트가 명시적·관계적·커뮤니티적·영역적·역할적 제약을 담당한다 -
형식 특성의 조합으로 강(剛)·유(柔)의 분업을 실현한다 — Markdown이 부드러운 제약을, 공존하는 SQLite가 단단한 제약을, LLM이 동적인 정합성 검증을 담당한다 -
3가지 유형의 연결성을 모두 지원한다 — Vault 동기화(에이전트 간), 플러그인과 MCP(네트워크 자원), Markdown 편집과 인용 제시(인간-에이전트 간) -
여러 인격적인 행동을 나누어 운용하기 쉽다 — Vault, 폴더, 태그, 프로필, 권한 설계의 조합

즉 Obsidian은 단순한 노트 앱에 머물지 않고, 인격 형성의 인프라로서 기능한다. 신중하게 말을 고르자면, 로컬 LLM과 에이전트가 성숙해 온 현재, Obsidian은 결과적으로 "인격 형성을 위한 인프라"에 가까운 역할을 수행하기 시작했다 — 설계자가 거기까지 의도했는지는 알 수 없으나, Vault, Markdown, wikilinks, Sync, 플러그인 생태계의 조합은 지능 × 제약 = 인격이라는 관계를 구현하는 기반으로서 놀라울 정도로 잘 갖춰져 있다.

그리고 책임 있는 에이전트 운용을 뒷받침하는 구조적 기반으로서도 기능하고 있다. 판단의 소재와 판단의 근거가 동일한 Vault 위에서 인간이 읽을 수 있는 형태로 공유된다 — 이것이 투명성을 사후에 붙이는 것이 아니라 구조로서 담보하는 메커니즘이다.

우리는 이 구조를 의도적으로 활용할 수 있는 시기에 진입하고 있다.

이번까지 총 세 편의 글을 통해 다음과 같은 경로를 지나왔다.

기술적인 배선도에서 시작하여 구현 선택지를 비교하고, 최종적으로 "그 배선 위에 무엇이 세워지는가"를 생각했다. 쓰기 시작했을 때는 여기까지 올 생각은 없었지만, 배선이 완성되고 나니 배선도만으로는 설명할 수 없는 것들이 보이기 시작했다.

로컬 LLM × 에이전트 (Agent) × Obsidian이라는 구성은 기술 스택 (Tech Stack)으로서 이미 성립되어 있다. 남겨진 질문은, 이 위에 무엇을 구축하고 어떻게 운용할 것인가이다. 그것은 기술의 문제라기보다, 자신이나 조직의 제약을 어떻게 설계할 것인가라는 더 근본적인 질문이 된다.

그리고 그 질문은 에이전트 측뿐만 아니라, 인간 측에게도 되돌아온다. Vault를 키워나간다는 행위는 자신의 암묵적인 판단 기준을 언어화하는 것이기도 하기 때문이다. 에이전트 설계의 예기치 못한 부산물로서, 인간 측도 자신의 판단을 객관적으로 바라볼 수 있게 된다.

다음 회차부터는 이 기반 위에서 검증하고 있는 구성을 더욱 구체적인 구현 (Implementation) 기사로서 작성해 나갈 예정이다.