에이전트와 오래 대화하다 보면 이런 기대가 생깁니다.
“지난번에 말한 걸 기억하고 있겠지?”
그런데 대화창에 남아 있는 기록과 에이전트가 업무에 쓸 수 있는 지식은 같은 것이 아닙니다. 어제의 대화를 그대로 다시 읽는다고 해서 프로젝트의 원칙을 아는 것도 아니고, 검색 결과 몇 개를 컨텍스트에 넣는다고 해서 장기 기억이 생기는 것도 아닙니다.
기억은 길게 쌓는다고 좋아지지 않습니다. 무엇이 원본인지, 무엇이 사람이 정리한 지식인지, 무엇이 검색을 위해 가공된 데이터인지 구분하지 않으면 오히려 에이전트는 오래된 메모와 임시 추론을 같은 사실처럼 다루게 됩니다.
앞선 글에서 AI 팀의 역할을 나눴다면, 오늘은 그 팀이 바라볼 지식의 저장 구조를 그려 보겠습니다. Obsidian, Vertex AI RAG Engine, IP Vault, MCP를 연결해서 보되, 각각을 기억의 같은 종류로 취급하지 않는 것이 출발점입니다.
1. 대화 기록·기억·지식은 서로 다르다
먼저 세 단어를 나눠 보겠습니다.
| 구분 | 의미 | 예시 |
|---|---|---|
| 대화 기록 | 특정 시점에 주고받은 사건의 흔적 | 어제 에이전트에게 요청한 내용 |
| 기억 | 다음 작업에서 다시 사용할 만한 지속 정보 | 사용자의 선호, 프로젝트의 반복 규칙 |
| 지식 | 근거와 맥락을 갖춘 재사용 가능한 정보 | 원문에 연결된 법률·기술·업무 노트 |
대화 기록은 풍부하지만 잡음이 많습니다. 기억은 짧고 선택적이어야 합니다. 지식은 출처와 변경 이력을 가져야 합니다. 이 셋을 하나의 긴 프롬프트에 계속 붙이면 처음에는 똑똑해 보일 수 있지만, 시간이 지날수록 오래된 정보와 현재 정보가 충돌합니다.
그래서 저는 장기 컨텍스트를 “AI의 머릿속에 전부 넣는 것”이 아니라, 필요한 정보가 필요한 순간에 올바른 층에서 공급되는 구조로 생각합니다.
아키텍처 교훈 ① 좋은 기억은 많이 저장된 기억이 아니라, 다시 사용할 이유와 출처가 함께 남아 있는 기억이다.
2. 지식은 네 개의 층으로 나누는 편이 안전하다
제가 실무용 지식 구조를 그릴 때는 다음 네 층을 분리합니다.
원본 자료
→ 사람이 읽고 정리한 지식 노트
→ 검색을 위한 인덱스·임베딩
→ 현재 작업에 주입되는 실행 컨텍스트
1) 원본 자료: 바뀌지 않아야 하는 기준점
특허공보, 판례 원문, 기술 문서, 계약서, 회의 자료처럼 사실을 확인할 때 돌아가야 하는 자료입니다. 원본은 요약본으로 대체하지 않습니다. 파일명만 저장하지 말고 출처, 날짜, 버전, 접근 권한도 함께 관리해야 합니다.
2) 지식 노트: 사람이 이해할 수 있는 정리 계층
원본을 읽고 핵심, 관계, 쟁점, 확인 필요사항을 정리한 층입니다. Obsidian의 공식 도움말에 따르면 Vault의 노트는 로컬 폴더에 저장되는 Markdown 파일이므로, 특정 앱의 화면 안에만 갇히지 않고 사람이 직접 읽고 다른 도구로도 관리할 수 있습니다.
이 층의 장점은 검색 정확도보다 맥락과 판단의 가시성입니다. 어떤 원문을 읽고 어떤 연결을 만들었는지 사람이 확인할 수 있어야 합니다.
3) 검색 인덱스: 빠르게 찾기 위한 파생 계층
문서를 잘게 나누고 임베딩이나 메타데이터를 붙여 검색하는 층입니다. Vertex AI RAG Engine 같은 검색·생성 인프라는 많은 자료에서 관련 내용을 찾고 모델에 전달하는 데 유용합니다. 다만 인덱스는 원본이 아닙니다. 문서가 바뀌거나 권한이 바뀌면 다시 인제스천하거나 재색인해야 하는 재생성 가능한 파생물입니다.
4) 실행 컨텍스트: 지금 이 작업에 필요한 최소 묶음
에이전트가 현재 요청을 처리할 때 실제로 읽는 정보입니다. 모든 Vault와 모든 인덱스를 한 번에 넣는 대신, 업무·프로젝트·권한·시간 범위에 맞는 자료만 가져옵니다. MCP는 이 층으로 원본이나 검색 결과를 전달하는 연결 통로가 될 수 있지만, 그 자체가 저장소는 아닙니다.
3. Obsidian은 ‘기억 장치’보다 지식의 원장에 가깝다
Obsidian을 AI의 두뇌라고 부르면 멋있지만, 실제 운영에서는 조금 더 차분하게 보는 편이 좋습니다. Obsidian의 강점은 사람이 읽을 수 있는 Markdown, 폴더, 링크, 속성, 검색을 이용해 지식을 정리하고 다시 고치는 것에 있습니다.
저는 다음과 같은 정보는 사람이 관리하는 지식 노트에 남길 만하다고 생각합니다.
- 프로젝트의 목적과 범위
- 반복되는 업무 규칙
- 원본 문서와 관련 노트의 연결
- 판단이 바뀐 이유와 확인 날짜
- 아직 검토하지 않은 가설과 보류 사유
반대로 다음 정보는 노트에 그대로 ‘사실’처럼 굳히지 않는 편이 낫습니다.
- 출처가 없는 AI의 추론
- 임시 브레인스토밍 문장
- 만료된 서비스 기능이나 가격
- 원문 확인 없이 복사한 요약
노트에는 원문, 정리, 추론, 확인 필요를 구분하는 표식을 둘 수 있습니다. 이 단순한 구분만으로도 에이전트가 무엇을 확정된 지식으로 읽어야 하는지 훨씬 분명해집니다.
다만 Obsidian 자체가 자동으로 모든 지식을 검증해 주는 것은 아닙니다. 사람이 구조를 만들고, 링크를 고치고, 오래된 노트를 보관하거나 갱신해야 합니다. 사람이 읽을 수 있다는 장점은 사람이 관리해야 한다는 책임과 함께 옵니다.
4. Vertex AI는 지식을 보관하는 금고가 아니라 검색 파이프라인이다
검색 인프라를 붙이면 에이전트가 갑자기 모든 것을 아는 것처럼 보입니다. 질문을 던지면 관련 문서 조각을 찾고, 모델이 그 내용을 바탕으로 답을 만들기 때문입니다.
하지만 검색이 잘된다는 것과 지식이 정확하다는 것은 다른 문제입니다.
Vertex AI RAG Engine 같은 구조를 단순화하면 다음과 같습니다.
문서 수집
→ 파싱·분할
→ 임베딩·인덱싱
→ 질문과 관련된 조각 검색
→ 모델에 컨텍스트 전달
→ 답변과 근거 반환
여기에는 여러 실패 지점이 있습니다.
- 원본이 최신인데 인덱스가 오래되었을 수 있습니다.
- 문서를 너무 잘게 나눠 문맥이 사라질 수 있습니다.
- 비슷한 표현이지만 법적·기술적 의미가 다른 문서가 함께 검색될 수 있습니다.
- 검색 결과에 접근 권한이 없는 자료가 섞일 수 있습니다.
- 검색된 문장을 모델이 원문보다 강하게 해석할 수 있습니다.
따라서 검색 결과에는 가능하면 원문 식별자, 문서 버전, 위치, 검색 시점이 따라와야 합니다. 답변만 저장하지 말고 “어떤 조각을 근거로 사용했는가”를 함께 남겨야 합니다.
아키텍처 교훈 ② RAG는 기억을 만들어 주는 마법이 아니라, 원본으로 돌아가는 검색 경로를 빠르게 만드는 인프라다.
5. MCP는 기억의 장소가 아니라 기억을 운반하는 경계다
MCP를 지식 저장소처럼 생각하는 경우가 있습니다. 그러나 공식 아키텍처에서 MCP는 호스트·클라이언트·서버가 연결되어 리소스, 도구, 프롬프트를 주고받는 프로토콜입니다. 저장된 자료의 소유권이나 진실성까지 자동으로 보증하는 시스템은 아닙니다.
그림으로 보면 더 간단합니다.
Obsidian·문서 저장소·검색 인덱스
↓
MCP 서버
↓
MCP 호스트
↓
에이전트
MCP의 중요한 역할은 자료를 가져오는 것과 함께 경계를 보여 주는 것입니다.
- 이 서버는 어떤 리소스를 제공하는가?
- 읽기만 가능한가, 쓰기도 가능한가?
- 현재 작업에 필요한 범위만 전달하는가?
- 서버가 전체 대화나 다른 서버의 자료를 볼 수 있는가?
- 도구 호출과 반환 결과를 나중에 확인할 수 있는가?
MCP 공식 문서가 강조하듯 호스트는 여러 클라이언트 연결과 권한·동의를 조정하고, 서버는 전문화된 리소스와 도구를 제공하는 역할로 나뉩니다. 이 분리가 지켜져야 지식 저장소와 에이전트 실행 환경을 교체해도 전체 아키텍처가 흔들리지 않습니다.
6. IP Vault를 예로 들면 원본과 기억의 경계가 보인다
특허·상표 업무를 위한 IP Vault를 만든다고 가정해 보겠습니다. 모든 문서를 한곳에 넣는 것보다 다음 흐름을 먼저 설계하는 편이 안전합니다.
공개·승인된 원본 수집
→ 서지정보·출처·날짜 부여
→ 사람이 읽고 핵심 노트 작성
→ 구성요소·쟁점·관련 문서 연결
→ 검색 인덱스 생성
→ 요청 범위에 맞는 자료만 MCP로 조회
→ 에이전트가 근거와 함께 분석 초안 작성
→ 사람 검토·승인
→ 최종 판단과 변경 이력 기록
이 과정에서 각 층의 역할은 다릅니다.
| 층 | IP Vault에서의 예시 | 에이전트에게 보이는 방식 |
|---|---|---|
| 원본 | 공보·판례·기술자료 원문 | 필요할 때 원문 확인 |
| 지식 노트 | 구성요소 표, 쟁점 메모, 관련 문서 링크 | 정리된 맥락과 사람의 주석 |
| 검색 인덱스 | 문서 조각·임베딩·메타데이터 | 빠른 후보 검색 |
| 작업 기억 | 이번 사건의 범위·질문·보류 항목 | 현재 턴에 필요한 최소 컨텍스트 |
| 감사 기록 | 사용 자료·검색 조건·승인 이력 | 결과의 재현과 검토 |
여기서 “에이전트가 IP Vault를 기억한다”는 표현은 정확하지 않습니다. 더 정확한 표현은 에이전트가 승인된 경로를 통해 IP Vault의 일부를 조회하고, 현재 작업의 컨텍스트로 사용한다는 것입니다.
이 차이는 중요합니다. 에이전트의 답변이 틀렸을 때 전체 Vault가 틀린 것인지, 검색 인덱스가 오래된 것인지, 작업 기억에 잘못된 조건이 들어간 것인지 원인을 나눠 볼 수 있기 때문입니다.
7. 기억도 종류별로 저장해야 한다
장기 기억을 하나의 데이터베이스에 밀어 넣으면 편해 보이지만, 실제로는 서로 다른 종류의 정보를 섞게 됩니다. 저는 최소한 다음 네 가지를 구분하고 싶습니다.
사실 기억
프로젝트 이름, 담당 범위, 확인된 일정처럼 비교적 안정적인 정보입니다. 바뀌면 이전 값을 덮어쓰지 말고 변경 시점을 남기는 편이 좋습니다.
사건 기억
어떤 작업에서 무엇을 조사했고, 어떤 오류가 났으며, 무엇을 보류했는지에 대한 기록입니다. 다음 작업자가 같은 실수를 반복하지 않게 해 줍니다.
절차 기억
특정 업무를 어떻게 수행하는지에 대한 규칙입니다. 도구 사용 순서, 검증 명령, 승인 조건처럼 반복되는 절차는 지식 노트와 별도의 Skill·운영 문서로 관리하는 편이 낫습니다.
근거 기억
어떤 결론이 어떤 원문과 검색 조건에 기대고 있는지를 보여 주는 연결입니다. IP 업무에서는 이 층이 특히 중요합니다. 결론만 오래 보관하면 시간이 지나면서 출처 없는 상식처럼 변하기 때문입니다.
기억을 이렇게 나누면 “기억을 더 많이 넣어 줘”라는 요청을 “어떤 종류의 기억을, 얼마 동안, 누구에게 제공할 것인가?”라는 설계 질문으로 바꿀 수 있습니다.
8. 잘 잊는 것도 아키텍처의 기능이다
기억을 저장하는 글에서 조금 이상하게 들릴 수 있지만, 에이전트에게는 잊는 규칙도 필요합니다.
- 임시 작업 메모는 일정 기간 후 보관한다.
- 가격·기능·정책처럼 변하는 정보에는 확인 날짜를 붙인다.
- 검색 인덱스는 원본 변경 시 재생성한다.
- 검토되지 않은 가설은 확정 지식 영역으로 승격하지 않는다.
- 권한이 사라진 자료는 검색 대상과 캐시에서 함께 제외한다.
기억이 무한히 쌓이면 컨텍스트가 풍부해지는 것이 아니라 선택 비용이 커집니다. 오래된 지식과 새 지식이 동시에 검색되고, 비슷한 문장이 서로 다른 결론을 가리키며, 에이전트가 어느 것을 믿어야 할지 판단해야 하기 때문입니다.
그래서 장기 컨텍스트에는 저장 정책만큼 갱신·폐기·재색인 정책이 중요합니다. 지식을 많이 모으는 사람보다, 낡은 지식이 현재 업무를 방해하지 않도록 관리하는 사람이 더 안정적인 아키텍처를 만듭니다.
9. 최소한 이 네 가지는 답할 수 있어야 한다
에이전트에 지식 저장소를 연결하기 전에 저는 다음 질문을 먼저 적어 보려 합니다.
원본: 이 정보의 최종 기준은 어디에 있는가?
상태: 사실·정리·추론·보류 중 무엇인가?
범위: 어떤 작업과 어떤 권한에서 조회할 수 있는가?
갱신: 언제 다시 확인하거나 인덱스를 재생성하는가?
이 네 줄에 답하지 못한 상태에서 “일단 전부 연결”하면, 에이전트는 많은 자료를 얻지만 무엇이 중요한지 알 수 없게 됩니다. 반대로 자료가 많지 않더라도 원본·상태·범위·갱신을 분리해 두면 답변의 근거와 한계를 설명하기 쉬워집니다.
지식 아키텍처의 목표는 에이전트가 모든 것을 기억하는 것이 아닙니다. 필요한 순간에 필요한 자료를, 그 자료의 성격을 잃지 않은 채 꺼내는 것입니다.
마치며
에이전트에게 기억을 준다는 말은 낭만적으로 들립니다. 하지만 실무에서 필요한 것은 모든 것을 잊지 않는 디지털 인간이 아니라, 원본과 해석을 구분하고, 오래된 정보는 갱신하며, 필요한 근거를 다시 찾아갈 수 있는 작업 환경입니다.
Obsidian은 사람이 읽고 고치는 지식의 원장으로, Vertex AI는 많은 자료에서 후보를 찾는 검색 인프라로, MCP는 저장소와 에이전트 사이의 연결·권한 경계로 볼 수 있습니다. 어느 하나도 다른 역할을 대신하지 않습니다.
원본을 보존하고
→ 사람이 지식을 정리하고
→ 검색 계층을 파생시키고
→ MCP로 필요한 범위만 전달하고
→ 에이전트의 답변에 근거와 상태를 붙인다
이 흐름이 유지되면 에이전트의 기억은 신비한 내부 상태가 아니라, 확인하고 고칠 수 있는 디지털 아키텍처가 됩니다.
다음 글에서는 이 구조에서 만들어진 결과를 GitHub와 배포 파이프라인에 어떻게 넘겨야 재현 가능하고 운영 가능한 결과가 되는지 살펴보겠습니다. 지식과 기억이 잘 정리되어도, 마지막 결과가 어디에 어떤 버전으로 남는지 설명할 수 없다면 업무는 아직 끝난 것이 아니기 때문입니다.