당신의 뇌에는 붙여넣기 버튼이 없습니다

나는 몇 달 동안 skippy-context-may.md라는 파일을 관리해 왔다. 프로젝트 상태, 아키텍처 결정(architectural decisions), 도구 버전, 고장 난 것들, 내가 수정한 것들 등 400줄에 달하는 내용이었다. 새로운 AI 세션은 항상 같은 방식으로 시작되었다. 파일을 열고, 전체 선택을 하고, 붙여넣은 다음, 마지막 편집 이후에 발생한 일들을 채워 넣는 방식이었다. 매일 15분의 오버헤드(overhead)가 발생했고, 나는 이것이 단순히 워크플로(workflow)의 일부라고 스스로를 다독였다.

그러다 이를 자동화하면서 내가 얼마나 많은 시간을 낭비하고 있었는지 깨달았다. 생산적인 것처럼 느껴졌지만 실제로는 그저 AI의 비서 역할을 하고 있었던 이 의식적인 작업에 최소 한 달에 6시간을 쓰고 있었다.

자동 인입(automatic ingestion)이 실제로 작동하는 방식

이 시스템은 일반적인 Claude Code 사용 중에 네 가지 훅(hook)을 실행한다. 하나는 세션 시작 시, 하나는 프롬프트(prompt) 제출 시, 하나는 중단(stop) 시, 그리고 하나는 압축(compaction) 시에 실행된다. 중단 훅이 가장 핵심적인 역할을 수행한다. 세션이 종료되면, 시스템은 전체 대화 기록을 가져와 추출 파이프라인(extraction pipeline)을 실행한다.

추출 과정은 원문 텍스트에서 7가지 범주의 정보를 뽑아낸다:

• 개인적 사실 (Personal facts) (사용자에 관한 변하지 않는 정보)
• 선호도 (Preferences) (사용자가 표현한 선택 사항)
• 결정 사항 (Decisions) (세션 중에 도달한 결론)
• 수정 사항 (Corrections) (이전 답변을 변경한 순간들)
• 시간적 사건 (Temporal events) (날짜, 마감일, 특정 날짜와 관련된 사항들)
• 기술적 컨텍스트 (Technical context) (설정, 아키텍처 선택, 도구 버전)
• 프로젝트 상태 (Project state) (작동하는 것, 고장 난 것, 다음에 할 일)

각 범주는 나중에 서로 다른 검색 패턴(retrieval pattern)으로 활용되기 때문에 중요하다. 시스템이 당신이 어떤 도구를 사용하는지 알아야 할 때는 선호도와 기술적 컨텍스트를 가져온다. 당신이 아키텍처 결정을 내리려 할 때는 이전의 결정 사항들을 표면화한다. 당신이 3주 전에 스스로를 수정했다면, 그 수정 사항은 이전 답변과 경쟁하는 대신 이전 답변을 덮어쓴다.

인코딩 게이트: 무엇이 저장되고 무엇이 버려지는가

Raw extraction(원시 추출)은 너무 많은 후보를 생성합니다. 하루 15회의 세션과 3개의 프로젝트를 수행한다면 수백 개의 잠재적 기억이 생기는데, 그중 대부분은 노이즈(noise)입니다. "47번 라인의 들여쓰기를 수정할 것"은 저장할 가치가 없습니다. 하지만 "이 프로젝트의 들여쓰기 규칙은 탭(tabs)이다"는 아마도 저장할 가치가 있을 것입니다.

인코딩 게이트(encoding gate)가 필터링을 처리합니다. 세 가지 신호가 각 후보 기억의 점수를 매깁니다:

1. 신규성 (Novelty) - 이것이 우리가 이미 알고 있는 것과 얼마나 다른가?
2. 현저성 (Salience) - 이 정보가 얼마나 중요한가?
3. 예측 오차 (Prediction error) - 이것이 우리가 이미 저장한 내용과 모순되는가?

이 점수들은 결합되어 임계값(threshold) 결정을 내립니다. 게이트를 통과하면 저장됩니다. 통과하지 못하면 버려집니다. 아카이브(archive)되지 않고 버려집니다. 모든 것을 저장하는 것은 검색을 개선하는 것이 아니라 오히려 악화시키기 때문입니다. 저장된 모든 기억은 검색 과정에서 다른 모든 기억과 경쟁하게 됩니다.

예측 오차 신호는 모순에 대해 직관에 반하는 동작을 수행합니다. 새로운 기억이 기존의 기억과 모순될 때, 예측 오차는 급증하며 실제로 저장 임계값을 낮춥니다. 모순은 더 쉽게 저장되는데, 이는 사용자의 생각이 바뀌었음을 의미하기 때문입니다. 저는 3월에 npm을 선호한다고 말했습니다. 5월이 되었을 때 저는 Bun을 사용하고 있었고, 명시적으로 "바꿨다"라고 말한 적은 없었습니다. 시스템은 이러한 행동 변화를 포착하여, 제가 공표하지 않아도 새로운 선호도를 인코딩(encoding)했습니다.

한 달 후의 모습

3일 차에 저는 약 12번의 세션을 통해 200개가 넘는 추출된 기억을 가졌습니다. 수동으로 저장한 것은 0개였습니다. skippy-context-may.md 파일은 이미 오래된 정보가 되어 있었고, 저는 습관적으로 그 파일을 계속 열어보았으나, 시스템이 그 안의 모든 내용뿐만 아니라 제가 한 번도 적지 않았던 100가지 사항까지 이미 알고 있다는 사실을 깨닫기 전까지는 계속 그랬습니다.

진정한 증거는 3주 차쯤에 나타났습니다. 저는 2시간마다 NAS 연결이 끊어지는 Pi 노드를 디버깅(debugging)하고 있었습니다. 원인을 도저히 알 수 없었죠. 제가 문제를 설명하기도 전에, 시스템은 11일 전의 기억을 떠올렸습니다. 전혀 관련 없는 라우터 설정 세션 중에, 제가 DHCP 임대 시간(lease time)을 24시간에서 2시간으로 변경했다고 언급했던 내용이었습니다. 그냥 지나가는 한 문장이었죠. 시스템은 이를 기술적 문맥(technical context)으로 저장했고, 11일 후 그것이 근본 원인(root cause)임이 밝혀졌습니다.

4주 차에 접어들자 시스템은 제 결정 사이의 모순을 지적하기 시작했습니다. 저는 초기에 모든 것에 SQLite를 사용하고 싶다고 말했으나, 이후 특정 유스케이스(use case)를 위해 조용히 Postgres를 탐색하기 시작했습니다. 제가 이와 관련된 아키텍처(architecture) 결정을 내리려 할 때, 시스템은 두 가지 입장을 모두 제시하며 이전 입장을 업데이트할 것인지 물었습니다. 컨텍스트 파일(context file)은 그런 일을 할 수 없습니다. 컨텍스트 파일은 당신이 마음을 바꾼 것과 당신이 결정했던 것을 잊어버린 것의 차이를 알지 못합니다.

프로젝트 간의 연결(Cross-project connections) 또한 수동으로는 복제할 수 없는 또 다른 요소입니다. 한 프로젝트에서의 디버깅 통찰이 몇 주 후 다른 프로젝트에서 관련 문맥으로 나타났는데, 이는 근본적인 패턴이 동일했기 때문입니다. 이것이 가능한 이유는 TrueMemory가 기억을 단일 프로젝트로 범위를 제한(scoping)하지 않고 저장하기 때문입니다.

대부분의 제품이 인제스션(ingestion)을 건너뛰는 이유

솔직히 말해서, 검색(search)이 더 쉽기 때문입니다. 벡터 임베딩(Vector embeddings), 재순위화(reranking), RAG 파이프라인(RAG pipelines)은 이미 잘 알려진 문제이며 수십 개의 오픈 소스 구현체가 존재합니다. 기성 도구(off-the-shelf tools)만으로도 LoCoMo에서 86%의 성능을 얻을 수 있습니다.

인제스션(Ingestion)은 판단의 문제입니다. 미래의 어떤 쿼리(query)가 무엇을 필요로 할지 알기 전에, 무엇을 보관할 가치가 있는지 결정해야 합니다. 이는 쿼리를 문서와 매칭하는 것보다 아키텍처 측면에서 훨씬 어렵습니다. 참신함(novelty), 중요도(salience), 모순 상태(contradiction state)에 대한 실시간 평가가 필요하며, 메모리 저장소가 커짐에 따라 확장성(scale) 처리도 요구됩니다.

대부분의 기업들은 어려운 부분을 건너뛰고 사용자가 수동으로 저장하는 무엇이든을 기반으로 더 나은 검색 기능을 구축합니다. 이것도 작동은 하지만, 그것은 메모리(memory)가 아니라 검색 기능이 좋은 노트(notebook)일 뿐입니다. 인코딩 게이트(encoding gate) 설계와 벤치마크(benchmark) 결과를 포함한 전체 아키텍처(architecture)는 arXiv 논문에 수록되어 있습니다.

당신의 뇌에는 붙여넣기 버튼이 없습니다. 그럴 필요도 없습니다. 그리고 데이터를 자동으로 수집(ingestion)하는 시스템을 실제로 한 달 동안 운영해 본 결과, 저는 예전 방식으로 돌아갈 수 없습니다.

Josh Adler는 Sauron의 계열사인 TrueMemory의 연구원입니다. 연구: arXiv:2605.04897. 더 자세한 내용은 joshadler.com에서 확인하세요.