처음엔 단순한 문제라고 생각했다
ATLAS는 모든 걸 노드로 저장한다. 메모 하나, 회고 하나, 결정 하나가 각각 노드다. 6편에서 이 노드들을 타입·태그·관계로 엮는 구조를 만들었다. 그리고 AI는 이 노드들을 load_memory, recall_knowledge 같은 MCP 툴로 불러온다 — 기억이 툴 뒤에 있다는 것 자체는 처음부터 당연했다.
그러니 진짜 문제는 그 툴이 무엇을 돌려주느냐였다. 처음 답은 단순했다. "전부 돌려주면 되지. 많이 알수록 잘하겠지."
키워드 검색은 너무 약했다
전부 넣는 게 무리라는 건 금방 알았다. 그래서 처음 시도한 건 키워드 검색이었다. 질문에서 단어를 뽑아 노드를 찾는 방식.
문제는 검색이 거의 안 됐다는 것이다. "운동 컨디션"이라고 적어둔 걸 "몸 상태"로 물으면 안 떴다. 의미는 같은데 글자가 다르면 그냥 스쳐 지나갔다. 내가 쓴 정확한 단어를 기억해야만 찾히는 검색은, 안 쓰는 것과 크게 다르지 않았다.
키워드 검색은 접었다.
진짜 문제는 '느림'이었다
그럼 다시 전부 넣으면 되지 않나. 그렇게 돌아가 보기도 했다. 그런데 이건 답이 틀리는 문제가 아니었다. 너무 느리고, 너무 비쌌다.
간단한 질문 하나에도 AI는 수백 개 노드를 헤집었다. 별것 아닌 걸 물어도 한참 걸렸고, 토큰은 토큰대로 쏟아졌다. 컨텍스트 윈도우는 무한하지 않다. 수백 개 노드와 천 개가 넘는 관계를 매번 통째로 넣는 건 "많이 아는 것"이 아니라, 질문마다 백과사전을 처음부터 다시 펼치는 것이었다.
바꿔야 할 건 그릇이 아니라 그 안이었다
키워드는 너무 약하고, 전부는 너무 무겁다. 그릇 — MCP 툴 — 은 그대로였다. 바뀌어야 할 건 그 안에서 무엇을, 어떤 순서로 골라 돌려주느냐였다.
그래서 질문을 뒤집었다. "어떻게 다 넣지?"가 아니라 "어떻게 안 넣을 걸 정하지?"
툴 안을 이렇게 설계했다
먼저 키워드 대신 의미로 찾게 했다. 모든 노드를 미리 벡터로 바꿔 저장해 두고(임베딩), 질문도 같은 방식으로 벡터로 바꿔 의미가 가장 가까운 노드가 뜨게 했다(코사인 유사도). 이제 "몸 상태"로 물어도 "운동 컨디션" 노드가 걸린다. 글자가 아니라 의미가 가까우니까.
하지만 가깝다고 다 좋은 기억은 아니었다. 그래서 유사도 위에 판단을 얹었다. 이미 접은(보관된) 노드는 빼고(옛 계획이 현재처럼 끼는 걸 막고), 태그가 겹쳐야 하며, 최근 것에 가중치를 준다. 두 가지를 더했다. 실제로 꺼내 쓴 노드는 "따뜻하게" 유지되고 안 쓰는 건 식어서 뒤로 밀린다. 그리고 거의 똑같은 노드는 하나로 병합해, "같은 얘기를 반복해 읽던" 문제를 없앴다.
툴의 진짜 일은 "가까운 것 찾기"가 아니라 **"안 줄 것을 정하는 것"**이었다.
ATLAS에는 어떤 노드가 있나
여기서 노드의 종류를 알아야 다음 이야기가 이어진다. ATLAS의 노드는 크게 두 층이다.
기억 노드 — 실제 내용이 담기는 곳
- Journal: 날 것 그대로의 기록. 오늘 있었던 일, 대화, 회고.
- Document: 정리된 참고 자료. 기획, 결정, 긴 문서.
- Insight: 그 기록들에서 뽑아낸, 재사용 가능한 통찰 한 줄.
메타 노드 — AI가 '어떻게 움직일지'가 담기는 곳
- Context: 역할과 규칙.
agent-core(너는 이런 비서다),save-node-protocol(기록은 이렇게 남겨라)이 여기 속한다. - Goal: 지금 향하는 목표.
- Lesson: 교정받으며 배운 교훈. 같은 실수를 반복하지 않도록.
기억 노드는 recall_knowledge가 의미로 검색해 꺼내고, 메타 노드는 load_memory가 매 대화 시작에 펼친다.
검색보다 먼저 필요한 건 '시작점'이었다
검색을 잘 만들고 나서도 AI는 매번 어디서 시작해야 할지를 몰랐다. 그래서 규칙을 정했다. 매 대화의 첫 호출은 무조건 load_memory.
이 툴이 돌려주는 건 하나가 아니라 "지금 네 상태"의 요약이다. 네가 어떤 역할인지(Context), 지금 뭘 향하는지(Goal), 뭘 배웠는지(Lesson) — 중요한 노드들을 우선순위로 쫙 펼쳐 보여준다. 우선순위에서 Context 노드가 가장 높게 설정돼 있어, agent-core가 언제나 맨 앞에 온다.
거기서 "구체적으로 어떻게 할지"는 각 노드로 직접 들어가서 확인한다. agent-core가 "이미지는 이 툴로, 쓰기 전엔 save-node-protocol을 봐라"라고 가리키면, AI는 그 노드로 들어가 규칙을 읽는다.
이게 사실상 메타인지다. 내 모든 기록을 통째로 아는 게 아니라, 내가 뭘 아는지, 어떻게 움직여야 하는지를 먼저 아는 것. load_memory가 돌려주는 건 데이터가 아니라, AI가 자기 자신을 파악하는 지도였다.
검색이 놓치면, AI가 직접 더 판다
이 방식엔 분명한 약점이 있다. 상위 몇 개만 주니까, 정말 필요한 노드가 그 안에 없으면 놓친다.
그런데 이게 MCP 툴로 만든 이유이기도 하다. 검색이 한 번에 끝나는 고정된 프롬프트였다면, 놓치면 그걸로 끝이다. 하지만 기억이 AI가 호출하는 도구로 열려 있으면, AI는 놓쳤다 싶을 때 직접 다시 검색한다. 질문을 바꿔 다시 부르고, 태그를 좁히고, 이웃 노드를 따라가고, 원본을 확인한다. 검색이 시스템이 한 번 떠먹여 주는 게 아니라, AI가 능동적으로 파고드는 과정이 됐다. 이것이 정적인 컨텍스트 덩어리와 도구의 결정적 차이다.
결국 '툴이 무엇을 돌려줄지'의 문제였다
정리하면 이 편은 프롬프트 이야기가 아니다. MCP로 만들지 말지의 이야기도 아니다 — 그건 처음부터 정해져 있었다. 이 편은 그 툴이 무엇을 돌려줄지를 어떻게 설계하느냐의 이야기다.
좋은 도구는 가진 걸 전부 게워내지 않는다. 선별을 도구 안에서 하고, 초점 잡힌 결과만 돌려주고, 부족하면 부르는 쪽이 더 파고들 수 있게 열어둔다. 회의에 들어온 유능한 비서가 내 인생 전체가 아니라 오늘 안건에 필요한 것만 꺼내오고, 물으면 더 찾아오듯이. 기억을 잘 준다는 건, 결국 그 도구를 잘 설계하는 것이었다.
그런데 읽는 것만으로는 부족했다 — AI가 자기 노트를 쓰기 시작했다
검색이 탄탄해지고 나니 다른 게 보였다. load_memory가 "내가 뭘 아는지"를 비추는 거울이라면, 그 거울에 비칠 내용은 누가 채우나. 지금까지는 전부 내가 채웠다. 내가 적은 Journal, 내가 정리한 Document.
그런데 비서가 자기 일도 하려면, 자기가 관찰한 것도 남겨야 했다. AI가 스스로 Insight를 쓰고, 교정받은 걸 Lesson으로 남기기 시작했다.
기억을 넘어 학습으로
여기서 저장과 학습이 갈린다. 저장은 사실을 쌓아두는 것이다. 학습은 다르다 — 교정을 받으면 Lesson 노드를 남기고, 다음 대화에서 그 Lesson이 우선순위로 올라와 AI가 실제로 다르게 행동한다. 노드가 그냥 쌓이는 게 아니라, 다음 행동을 바꾼다. 기억이 스스로를 갱신하기 시작한 것이다.
다음 문제
그런데 여기까지 온 기억은 전부 텍스트였다. 노드도, 검색도, 학습도 글자 위에서 일어났다.
하지만 내 기록은 글자만이 아니다. 스크린샷, 다이어그램, 사진. 기억이 진짜 기억이려면 이미지도 기억해야 했다.
다음 편: 이미지도 기억하게 만들기.