AI에게 코드나 문장을 쓰게 하는 사람이라면 누구나 한 번쯤은 느껴본 적이 있을 것이다. 세션이 바뀌면 이전 대화의 내용을 이어갈 수 없다. 이전에 지적했던 사항도, 결정했던 전제도, 취향도 전부 리셋되어 처음부터 다시 설명해야 한다. 유능한 인재임에도 불구하고, 매번 처음 만나는 담당자에게 전화를 거는 듯한 기분이다.

공식 메모리 (Memory) 기능이 있기는 하지만, 사용하면서 네 가지 불만이 쌓였다.

• 무엇을 기억하고 있는지 내용을 볼 수 없다
• 기억하는 기준이 AI에게 맡겨져 있어, 스스로 규칙을 정할 수 없다
• 그 AI 안에 갇혀 있어서 다른 도구로 가져갈 수 없다
• 모든 것이 하나의 기억에 뒤섞여 프로젝트별로 나눌 수 없다

그렇다면 직접 외부 뇌를 만들면 된다. 그렇게 생각하여 Obsidian의 vault (로컬 Markdown 파일의 집합)를 외부 기억 장치로 삼고, AI가 이를 읽고 쓰게 하는 메커니즘을 구축했다. 약 1개월간 운용한 결과, 키를 누락할 뻔하거나 검색의 한계에 부딪히는 등 실패도 제법 있었다. 이 기사는 그 모든 기록의 다이제스트(Digest)다.

조금 더 자세히 체계적으로 정리하여 책으로 펴내고 싶으며, 이 기사는 그 수요를 확인하기 위한 목적도 있다. 마지막에 목차 안을 적어두었으니, 관심이 있다면 댓글로 반응을 주시면 감사하겠다.

설계의 축은 단 3개뿐

먼저 결론부터 쓰겠다. 이 메커니즘이 제대로 작동하는 이유는 다음의 3가지 원칙을 처음에 정했기 때문이다.

• 플레인(Plain)한 Markdown으로 유지한다
• 기억할지 말지를 수동으로 제어한다
• 검색은 로컬에서 완결시킨다

이 세 가지를 지키면 특정 AI에 락인(Lock-in)되지 않는다. 이것이 이 기사의 축이며, 이후의 모든 절은 결국 이 원칙을 어떻게 구현했는지에 대한 이야기가 된다. 먼저 축만 전달해 두므로, 세부 내용을 읽을 때 이 세 가지 중 어디에 해당하는 이야기인지 의식하며 읽으면 더 수월할 것이다.

최소 구성은 vault와 지시 파일 1장

메커니즘 자체는 대단한 것이 아니다. Obsidian의 vault 폴더와 AI 측의 설정 파일 1장뿐이다. MCP도 플러그인도 필요 없다. 설정 파일에 vault와의 연동 규칙을 적는다. 하는 일은 읽기와 쓰기라는 두 가지 루프뿐이다.

읽기는 세션 시작 시에 실행한다.

• 과거에 지적받은 실수를 정리한 노트와 사용자 프로필을 가장 먼저 읽는다
• 질문과 관련된 키워드로 vault를 검색한다
• 히트(Hit)된 노트를 읽는다
• 그것을 바탕으로 답변한다

이렇게 하면 "전제를 매번 다시 설명하는 일"이 없어진다. vault와 명백히 무관한 단발성 질문은 스킵(Skip)해도 좋다는 예외 규칙만 넣어두었다.

쓰기는 "그 자리에서 기록"하는 것이 철칙이다. 나중에 쓰겠다는 방식은 작동하지 않는다. 대화가 흘러가는 도중에 조건에 부합하면 그 자리에서 쓰게 하지 않으면, 결국 아무것도 남지 않는다.

읽고 썼다면 반드시 보고하게 하는 것도 규칙으로 정했다. "vault의 xxx를 읽었습니다", "쓰기 작업을 완료했습니다"라고 매번 명시한다. 백그라운드에서 멋대로 파일을 건드리면 무엇이 축적되고 있는지 알 수 없게 되기 때문이다. 투명성은 처음부터 조건에 포함되어 있다.

쓰기 규칙과 실수의 기억

쓰기 대상은 폴더로 나누어 관리한다. 버그의 원인과 해결책 및 도구의 새로운 발견은 지식(Knowledge) 폴더에, 여러 선택지 중 하나를 고른 판단은 그 이유와 함께 결정(Decision) 폴더에, 프로젝트 상태는 프로젝트(Project) 폴더에 담는 식이다. 날짜별 작업 로그도 별도로 쌓여간다.

가장 마음에 드는 것은 실수를 기록하는 전용 노트다. 이것만은 특별 취급하여 매 세션 시작 시 반드시 읽게 한다. 무엇이든 다 적으면 표가 방대해져 쓸모없어지므로, 추가하는 조건을 세 가지로 압축했다.

• 사용자의 명시적인 정정인 경우 (스스로 깨달은 것이 아님)
• 반복해서 일어날 수 있는 패턴인 경우 (단 한 번의 우연이 아님)
• 구체적인 "한다/하지 않는다"로 작성할 수 있는 경우

형식도 정해두었다. 실제로 쌓여 있는 내용을 예로 들면 다음과 같다.

2026-06-20: 앱의 UI 기능을 잘못 기억하여 단정적으로 말함
NG Action: 「Google 캘린더로 복사」 버튼이 있다고 검증 없이 안내함 (실제로는 존재하지 않음)
Correct Action: 기능의 유무는 안내하기 전에 공식 도움말 등을 통해 현재 사양을 확인한다
...

이를 도입한 이후, 같은 종류의 실수를 반복하는 빈도가 눈에 띄게 줄었다. 다른 작업을 하는 도중에 AI가 내가 아무 말도 하지 않았는데 "이 노트의 교훈에 따라 이렇게 하겠습니다"라며 스스로 방식을 바꾸는 경우도 있었다. 쌓아온 기억이 다음 동작을 바꾸고 있다.

또 하나, 기록에는 확신도(confidence) 라벨을 붙이고 있다. 검증하여 사실로 확인된 것은 그대로 두고, 검증되지 않은 추측은 「추측」, 확인되지 않아 판단을 기다리는 것은 「要確認(확인 필요)」라고 명시한다. 이를 도입하기 전에는 검증된 사실과 그 자리에서의 추측이 똑같은 모습으로 나열되어 있어, 다음 세션의 내가 두 가지를 똑같이 믿어버리는 문제가 있었다. 추측이 사실의 얼굴을 하고 자리 잡으면, 그것을 토대로 또다시 실수하게 된다. 라벨 하나만으로 이 조용한 오염을 막을 수 있다.

이러한 상세 내용은 원문 기사에 적혀 있다.

키워드 검색의 한계와 로컬 의미 검색 (Semantic Search)

한동안 사용하다 보니, 재현(recall)이 키워드 검색에 의존한다는 점이 약점으로 드러났다. 일일 로그는 파일명이 날짜이기 때문에, 언제 했는지 기억하지 못하면 찾아갈 수 없다. 단어의 차이에도 취약하여, 「권한을 너무 많이 주지 않도록」으로 검색해도 노트 측에 「허가」, 「사정거리」라고만 적혀 있으면 걸리지 않는다. 같은 말을 하고 있는데도 불러올 수 없는 것이다.

내가 원한 것은 의미로 불러오는 검색, 즉 임베딩(embedding)이었다. 기성 메모리 계열 OSS(Open Source Software)도 하나 조사해 보았지만, 그것은 대화를 자동으로 계층화하여 증류(distillation)하는 구조여서, 「무엇을 기억할지를 AI에게 맡기지 않는다」라는 나의 전제와 정면으로 충돌했다. 좋아 보여도 내 용도에 맞지 않는다면 도입하지 않겠다고 판단하여 사용하지 않기로 했다. 다만 「의미 검색이 필요하다」는 요점만은 챙겨왔다.

그렇다면 그 점 하나만 직접 추가하면 된다. 만든 것은 vault-search라는 작은 CLI(Command Line Interface)다.

• vault의 .md 파일을 헤딩(heading) 단위로 청크(chunk)로 나눈다
• 각 청크를 Ollama의 로컬 모델로 임베딩(embedding)한다
• 정규화하여 sqlite에 저장한다
• 검색 시에는 쿼리도 임베딩으로 만들어, 코사인 유사도(cosine similarity)로 가까운 청크를 불러온다

의미 검색만 하면 「그럴듯하지만 무관한 것」을 집어낼 때가 있으므로, 키워드 검색과 양쪽을 모두 실행하여 RRF(Reciprocal Rank Fusion)라는 방법으로 결과를 섞는 하이브리드(hybrid) 구성으로 만들었다. 의존성은 Python 표준 라이브러리와 Ollama의 HTTP뿐이며, 임베딩도 로컬에서 이루어지므로 노트의 내용이 머신 외부로 나갈 일도 없다.

구현 도중에 키워드 측에 사용할 예정이었던 ripgrep이 사실은 작동하지 않는다는 시행착오도 겪었다. 원인을 파고드니, 청크 텍스트는 이미 sqlite에 전부 들어있어서 외부의 ripgrep이 파일을 훑게 할 필요가 처음부터 없었다. DB 안에서 부분 일치를 찾으면 그만이었다. 추가했던 의존성이 사실은 필요 없었던 것이다.

효과는 확실히 나타났다. 날짜를 하나도 지정하지 않은 검색에서도, 해당 작업을 했던 날의 일일 로그가 1위로 나오게 되었다. 단어가 일치하지 않아도 의미로 연결되어 나온다. 이것은 키워드 검색으로는 절대 나올 수 없던 결과다.

이 도구는 MIT 라이선스로 공개되어 있다. 상세 내용과 구현은 원문 기사에 적었다.

점은 찍을 수 있어도, 면은 보이지 않는다

의미 검색으로 할 수 있는 것은 핀포인트로 과거의 한 점을 찾아내는 것이다. 질문이 있고, 그와 유사한 노트를 파헤치는 것. 하지만 인간이 무언가를 떠올릴 때는 갑자기 점으로 가지 않는다. 먼저 「나는 지금 이런 상황이고, 이런 것을 움직이고 있으며, 대략 이 근처 이야기구나」라고 전체를 파악한 뒤에 구체적인 내용을 파고든다.

외부 뇌에는 이 「넓게 파악하는」 측면이 없었다. 기동 시에 읽게 하려던 집약 프로필이 사실은 내용이 텅 비어 있었다. 누구인지, 무엇을 움직이고 있는지, 최근 어떤 흐름인지. 그것이 한 장에 정리되어 있지 않았다. 매번 세션 시작 시 의미 검색을 몇 번씩 실행하며 파편으로부터 상황을 다시 조립해야 했다. 점을 여러 개 찍어서 면을 추측하고 있는 상태였다.

재현(recall)에는 두 가지 계층이 필요하다. 넓게 파악하는 계층(macro)과 구체적으로 찾아내는 계층(micro)이다. 의미 검색으로 만든 것은 micro뿐이었다. 그래서 macro를 추가하기로 했다.

만든 것은 persona.md라는 한 장의 노트다. vault 직하단에 두고 기동 시 가장 먼저 읽게 한다. 내용은 누구인지, 작업 스타일과 지켜줬으면 하는 취향, 현재 움직이고 있는 것, 최근의 흐름, 그리고 과거를 파헤칠 때의 입구다. 상세 내용은 개별 노트로 링크를 연결하여, macro로 파악한 뒤 필요하다면 micro로 내려갈 수 있도록 구성했다.

생성은 수동 명령으로 만들었다. 하는 일은 손으로 쓴 1차 노트를 읽고 정리하는 것뿐이며, 대화 로그로부터의 자동 추출은 하지 않는다. 출처 링크는 필수이며, 억측으로 채우는 것은 금지했다. 다만 수동 재생성을 잊어버려 내용이 오래된 채로 썩기 쉽기 때문에, 기동 시 최종 업데이트로부터 7일 이상 지났다면 읽기 전에 자동으로 재생성하도록 했다. 수동 제어권은 놓지 않으면서 부패만 자동으로 막는 형태다.

또 하나, MOC.md

(Map of Content)도 두었다. 모든 노트를 묶어주는 도메인별 색인을 수기로 한 장 만들어 두는 방식으로, Obsidian 커뮤니티에서는 예전부터 있던 개념이다. 검색은 '점'을 찍는 도구이기 때문에, "이 vault에는 애초에 어떤 덩어리들이 있었지?"라는 질문은 검색만으로는 파악할 수 없다. 그것은 수기로 그린 지도만이 할 수 있는 일이다.

이로써 recall(회상)이 2층 구조가 되었다. 구동하면 우선 persona와 MOC로 전체를 넓게 파악하고, 그 위에서 개별적인 질문은 vault-search의 의미 검색(semantic search)으로 점을 찍는다. 넓게 파악한 뒤에 점으로 내려간다.

이 2층화의 전말은 이쪽.

키를 유출할 뻔한 이야기와, 조용히 멈춰있던 가드

외부 뇌가 성장할수록, 잃어버리는 것이 두려워진다. 흩어진 설정들을 dotfiles에 집약하여 자동 백업시키려 했을 때, 실제로 사고를 쳤다.

자동화 대상을 넓히는 과정에서 시크릿 탐지 스캔 범위를 넓히는 것을 깜빡하여, GCP의 서비스 계정 키를 GitHub에 push해 버렸다. private 리포지토리라고는 해도, 키의 바이트가 서버로 전달된 것은 사실이다. 그 즉시 커밋 히스토리에서 키를 삭제하고, 키 자체도 GCP 측에서 무효화한 뒤 다시 만들었다.

원인은 다층적이었다. 복사본을 늘렸음에도 검사 범위를 동시에 넓히지 않았던 것, 제외 설정이 허술했던 것, 그리고 탐지 로직이 단어 기반이라 오탐(false positive)의 폭풍을 일으켰던 것. 단어로 찾으면 문장이나 코드에 너무 많이 걸린다. 실제 키의 "형태"만을 노리는 것이 옳다.

또 하나의 중요한 배움이 있었다. "백업해 줘"라고만 부탁했을 뿐인데, AI는 자동 push 메커니즘까지 심어서 실행하고 있었다. 틀린 것은 스캔의 구멍이었지만, 방아쇠를 당긴 것은 요청받지도 않은 push였다. 이 건은 "push는 의뢰의 연장이라도, 실행해도 좋다고 명시적인 확인을 받은 후에 할 것"이라는 한 줄의 문장으로, 실수 기록에 그대로 새겨졌다.

안전망은 AI의 선의에 맡기지 않고, git 계층의 메커니즘에 두기로 했다. commit 전에 파일명과 내용 모두를 스캔하는 pre-commit hook을 넣었다. 그런데 이 hook이 이번에는 또 다른 문제를 일으켰다.

vault의 자동 백업이 멈춰 있다는 것을 깨달은 것은 한참이 지난 후였다. 원인은 방금 넣은 hook이었다. 내용 스캔이 키 유출의 전말을 적은 지식 노트 자체에 반응하고 있었던 것이다. 노트 안에 해설로서 실제와 똑같은 키 문자열을 적어두었기 때문에, hook이 실제 키와 구별하지 못하고 차단해 버렸다. 백업 스크립트는 실패하면 멈추도록 설계되어 있었기에, 나도 모르는 사이에 15시간 분량의 변경 사항이 조용히 쌓여 있었다.

유출을 막기 위해 설치한 가드가 다른 파이프라인을 묵묵히 멈추고 있었다. 해결 방법은 간단했다. 문장 중심의 vault에서는 내용 스캔을 중단하고, 위험한 파일명만으로 차단하도록 변경했다. 작동 중인 것에 개입하는 가드를 추가했다면, 가짜 테스트가 아니라 실제 데이터로 통과하는지 확인한 뒤에 "완료했다"라고 말했어야 했다. 이번에는 그것을 소홀히 하여, 스스로 자신의 백업을 멈추게 만들었다.

실패는 둘 다 그대로 실수의 기억으로서 한 줄 남아 있다. 다음 세션은 그것을 읽고 나서 움직인다. 키를 유출했던 실패가 외부 기억을 경유하여 다음의 신중함으로 변하는 것이다.

자세한 경위와 복구 절차는 이쪽.

어디서든 만질 수 있는 제3의 기억층

외부 뇌는 처음에는 PC 내부에서만 완결되었다. 그것이 Syncthing을 통해 스마트폰과도 동기화되면서 한 단계 더 확장되었다.

계기는 단순한 의문이었다. vault는 이미 스마트폰 안에도 동기화되어 있다. 그런데 왜 스마트폰의 AI 앱으로는 외부 뇌에 접근할 수 없다고 생각했을까? 다시 조사해 보니 원인은 데이터의 위치가 아니라, 읽어오는 수단 쪽에 있었다. 스마트폰 공식 앱의 커스텀 지시(custom instructions)는 매번 수동으로 업로드하는 스냅샷 방식이었고, 폴더를 지정하여 자동으로 읽어오는 구조로 되어 있지 않았다.

그런데 PC에서 돌아가고 있는 세션을 스마트폰 공식 앱에서 원격 제어할 수 있는 기능이 있다는 것을 알게 되었다. 실행 주체는 어디까지나 PC 측에 있으며, 스마트폰은 조작하기 위한 윈도우일 뿐이다. PC 측의 세션이 vault를 읽고 쓸 수 있는 상태라면, 그 권한을 유지한 채 스마트폰에서 지시를 내릴 수 있다. 시도해 보니 정상적으로 작동했다. 검색도, persona/MOC 로딩도, 쓰기 규칙도 모두 PC와 동일한 상태로 스마트폰에서 사용할 수 있었다.

단, 전제 조건이 하나 있다. 실행 주체가 PC 측에 있는 이상, PC가 켜져 있지 않으면 소용이 없다. 화면 잠금까지는 괜찮지만, 명시적으로 절전 모드(sleep)로 들어가면 연결이 끊긴다. 외출하기 전에 절전 모드를 방지하는 설정을 해둘 필요가 있다.

이 상호작용 도중에 또 하나 발견한 것이 있다. 과거의 세션(session) 그 자체를 전체 검색할 수 있는 메커니즘이다. 외부 뇌(external brain)는 수동으로 큐레이션(curation)한 vault가 전부라고 생각했지만, 그것과는 별개로 세션의 상호작용 자체가 생로그(raw log)로 남아 검색 대상이 되고 있었다. 어떤 동기화 도구를 선택할 때의 비교 검토 대화는 vault의 어떤 노트에도 적어두지 않았지만, 세션 검색을 따라가니 나타났다. 적는 것을 잊어버린 것이 아니라, 그 시점에는 아직 "판단을 남긴다"라는 규칙 자체가 존재하지 않았기 때문이다. 수동으로 큐레이션하기 전의 판단도 생로그의 층에는 남아 있다.

정리하자면, 기억은 세 개의 층으로 이루어져 있다. 수동으로 큐레이션한 vault, 큐레이션하지 않고 전부 남는 세션의 생로그, 그리고 그 양쪽 모두에 스마트폰으로도 전달되도록 하는 원격 조작(remote control). 위의 두 개가 기억 그 자체이며, 세 번째는 그곳으로의 액세스 경로(access path)다.

상세 내용은 이쪽.

운용하며 알게 된 것

한 달 정도 돌려보니 몇 가지 세세한 깨달음이 쌓였다.

하나는, 프롬프트(prompt)에 적기만 한 자동화는 말없이 실패한다는 것이다. 설정 파일에 "기동 시에도 자동으로 재생성한다"라고 적혀 있어도, 실제로 그것을 수행하는 메커니즘이 어디에도 없다면 그저 문자열로 끝난다. 실제로 persona.md의 신선도 체크가 이 때문에 9일간 방치된 적이 있었다. 지시문으로 해결했다고 생각한 자동화는, 기계적으로 발화하는 메커니즘(셸 스크립트(shell script)나 훅(hook) 같은 것)으로 대체하지 않으면 어느샌가 멈춰 있다.

또 하나는, 대리 변수가 아니라 본체의 조건으로 제약을 작성해야 한다는 것이다. 어떤 수집 도구에서 대응 사이트를 YouTube로 한정했던 제약이, 사실은 "자막 추출(transcription)이 무거운 것을 피하고 싶다"라는 다른 이유의 대리 변수에 불과했던 적이 있었다. 본체의 조건, 즉 동영상 길이 상한 그 자체를 제약으로 삼았다면 대응 사이트를 더 넓힐 수 있는 구조가 되어 있었다. 표면적인 조건(사이트 이름)으로 제약을 작성하면 정말로 지키고 싶었던 것(처리 부하)을 놓치게 된다.

마지막으로, 기록한 판단은 다음 AI의 입력이 된다는 것. 정리하는 과정에서 "로컬의 경량 모델에 일부 작업을 맡길 수 없을까"를 검토했다가 결국 보류한 적이 있었다. 중요한 것은 보류한 결론 그 자체보다, 그 이유를 기록해 두었다는 점이다. 다음에 똑같은 생각이 들었을 때, 그것이 자신일지 다른 AI일지라도 똑같은 검토를 처음부터 다시 할 필요가 없다. 채택한 기능뿐만 아니라 불채택한 이유도 환경의 일부가 된다.

이 운용 측면의 상세 내용은 이쪽.

이 메커니즘은 AI가 바뀌어도 남는다

여기까지 되돌아보면, 결국 이 글의 축은 처음에 쓴 3원칙으로 돌아간다. 플레인 마크다운(plain Markdown)으로 보유한다, 기억은 수동으로 제어한다, 검색은 로컬에서 완결시킨다. 이 세 가지를 지키고 있는 한, AI가 교체되어도 외부 뇌 그 자체는 남는다.

실제로 정리 작업을 한 적도 있다. 공개 후 며칠 만에 사용할 수 없게 된 신규 모델 뉴스를 보고 자신의 외부 뇌 구조를 확인해 보니, vault는 단순한 마크다운이었고 검색도 로컬의 Ollama와 sqlite로 완결되어 있었으며, 특정 AI 전용 공간에는 아무것도 두지 않았다. 전용인 것은 읽기/쓰기 규칙을 적은 설정 파일의 내용뿐이었고, 그것도 텍스트이기에 옮겨 적을 수 있다. 의존 대상을 바꾸는 작업의 비용이 지식의 재구축이 아닌 설정의 옮겨 적기로 수렴한다. 투명성을 추구하려 했던 것이 결과적으로 이식성(portability)을 갖게 된 형태다.

이 글에서 다룬 설정 파일이나 읽기 절차는 현재 내 환경에서는 Claude Code로 구성되어 있다. 다만 이것은 참조 구현 중 하나일 뿐이다. vault도 의미 검색(semantic search)도 원격 조작도 Claude Code 전용 기술에 의존하지 않는다. "세션 시작 시 mistakes와 persona를 읽는다", "그 자리에서 적는다", "확신도에 라벨을 붙인다"와 같은 규칙은 어떤 AI 도구의 설정 형식에도 옮겨 적을 수 있다. 갈아탄다면 키워온 vault는 그대로 가져갈 수 있고, 다시 쓰는 것은 읽는 규칙뿐이다.

이 일련의 이야기를 조금 더 체계적으로 책으로 정리하려고 생각 중이다. 지금 구상 중인 목차 안은 다음과 같다.

• 외부 뇌의 기본 설계와 3원칙
• 읽기와 쓰기의 루프를 만든다
• 실수의 기억과 확신도 라벨
• 키워드 검색에서 의미 검색으로, 로컬 하이브리드(hybrid) 검색 만드는 법
• persona/MOC를 통한 이층 구조의 회상(recall)
• 비밀을 누설하지 않기 위한 다층 방어와 그 부작용
• 어디서든 접속 가능한 제3의 기억층
• 운용하며 알게 된 함정과 해결법
• 특정 AI에 락인(lock-in)되지 않는 설계

읽고 싶은 장, 혹은 반대로 부족하다고 생각되는 장이 있다면 댓글로 알려주시면 감사하겠습니다. 반응을 보고 집필에 들어가려고 합니다.

토론 (Discussion)