에이전트 메모리를 파일 포맷으로 설계하는 방법

벡터DB와 RAG 파이프라인으로 에이전트 메모리를 다루는 방식에는 한 가지 운영상 약점이 있다. 인덱스 안에 무엇이 저장됐는지 사람이 직접 확인하거나 바로 고치기 어렵다는 점이다. 잘못된 기억이 검색 결과 상위에 남으면 같은 오답이 반복될 수 있고, 특정 사실만 정확히 삭제하는 일도 까다롭다.

Cal Paterson이 제기한 문제의식은 메모리를 검색 스택이 아니라 읽고 쓸 수 있는 파일 형식으로 다시 보자는 데 있다. 비임베딩 기반 지속 메모리를 제안하는 흐름도 같은 시기에 나타나며, 기억의 핵심을 사람이 도구와 함께 관리할 수 있는 저장 형식에서 찾는 관점이 겹쳤다.

파일 포맷으로 접근한다고 해서 모든 기억을 컨텍스트에 넣는다는 뜻은 아니다. 기억이 늘어날수록 전량 로딩은 컨텍스트 예산을 빠르게 소진하고 현재 요청에 필요한 정보를 밀어낼 수 있다. 저장 형식, 항목 경계, 편집과 이력, 유효 범위, 삭제·만료, 선별 로딩을 함께 설계해야 한다.

기억을 열어보고 고칠 수 있게 만드는 구조

메모리는 자유 텍스트로만 쌓아두기보다 정해진 스키마를 갖춘 항목으로 관리한다. 항목 식별자, 내용, 출처, 작성 시각, 유효 범위, 신뢰 수준을 필드로 고정하면 어떤 기억을 언제까지 어디에 적용할지 판단할 기반이 생긴다. 이런 필드가 없으면 선별 로딩과 만료 처리를 제대로 수행하기 어렵다.

항목 경계도 중요하다. 하나의 파일 또는 블록에는 하나의 사실만 담는 편이 낫다. 여러 사실이 한 항목에 섞이면 그중 일부만 바꾸거나 지울 수 없고, 필요하지 않은 정보까지 함께 로드된다.

저장 형식은 텍스트 편집기로 열어 읽고 수정할 수 있어야 한다. 별도 도구 없이는 열 수 없는 형식에서는 기억을 검증할 방법도 제한된다. 열어볼 수 있다는 성질 자체가 통제 수단이 된다.

변경은 버전 관리 시스템에 남긴다. 누가 언제 무엇을 바꿨는지와 되돌릴 수 있는 이력이 있어야 오류 기억이 어떤 경로로 들어왔는지 추적할 수 있다. 사람과 에이전트가 같은 항목을 동시에 수정할 가능성도 있으므로, 우선순위와 충돌 해소 방식을 미리 정해야 한다. 사실이 섞인 자동 병합은 새로운 오류를 만들 수 있다.

유효 범위는 특정 프로젝트, 기간, 사용자에게만 적용되는 기억을 구분하는 필드다. 이 정보가 빠지면 한 맥락에서만 유효했던 사실이 다른 맥락에 잘못 쓰일 수 있다. 만료 시점과 폐기 표시는 형식 안에 보관하고, 만료된 항목은 로딩 대상에서 제외한다. 삭제를 물리적 제거로만 처리하지 않고 폐기 이력을 남겨야 사라진 이유도 설명할 수 있다.

⤢✕

저장 규칙부터 운영 절차까지

도입의 시작점은 저장 대상의 정의다. 사용자 선호, 프로젝트 규약, 확정된 사실, 실패 경험처럼 범주를 나누고 각 범주에 보관 기간을 둔다. 모든 대화를 저장하면 기억은 관리 가능한 지식이 아니라 로그가 된다.

포맷 표준에는 필드 목록과 값 규칙을 문서화하고 예시 파일을 함께 제공한다. 사람이 직접 작성할 수 있을 정도로 단순해야 한다. 형식이 복잡해지면 결국 전용 도구에만 의존하게 된다.

기존 벡터 저장소의 항목을 파일로 옮길 때는 조회 결과를 항목 단위로 이관하고 중복을 정리한다. 출처가 불명한 항목은 폐기 후보로 분류한다. 편집 권한 역시 범주별로 정해야 한다. 에이전트가 자동으로 수정할 수 있는 범위를 제한하지 않으면, 검증되지 않은 수정이 다시 기억으로 사용된다.

오류 기억을 발견했을 때의 신고 경로와 처리 기한도 운영 절차에 포함한다. 신고가 접수된 뒤 반영되지 않으면 같은 오답이 계속 발생한다.

스키마가 바뀌면 필드 추가·삭제뿐 아니라 기존 항목을 어떻게 이행할지까지 함께 결정한다. 항목에 스키마 버전을 기록하지 않으면 오래된 항목의 해석이 흔들린다. 저장 범주와 편집 권한 정책은 문서로 관리하고 변경 승인 대상으로 둔다. 항목 수, 만료 처리율, 오류 신고 건수는 정기 보고 항목으로 편성할 수 있다.

검색 스택과 파일 메모리가 맡는 역할

구분	파일 포맷 메모리	벡터DB 파이프라인
검증 가능성	높음	낮음
의미 검색 능력	제한적	높음
수정·삭제	쉬움	어려움
대규모 확장	제한	유리
운영 구성요소	적음	많음
이력 추적	버전 관리로 확보	별도 구현

파일 포맷 메모리의 장점은 저장된 내용을 사람이 확인하고 바로 고칠 수 있다는 데 있다. 잘못된 기억의 재사용을 끊을 수 있고, 버전 관리를 통해 이력과 되돌림도 확보할 수 있다. 임베딩 모델, 인덱스, 재색인 같은 구성요소가 필요하지 않다는 점도 운영을 단순하게 만든다. 반대로 항목이 수만 건을 넘으면 관련성을 판단하기 어려워지고, 표현은 달라도 뜻이 같은 질의를 놓칠 수 있다. 대규모 문서 지식 검색에는 맞지 않을 수 있다.

벡터DB 파이프라인은 의미 유사도를 이용해 표현 차이를 넘어 관련 항목을 찾고, 대규모에서도 검색 지연을 안정적으로 유지하는 데 유리하다. 다만 인덱스 내부를 사람이 목록으로 검증하기 어렵고, 특정 사실을 정확히 삭제하기가 까다롭다. 임베딩 모델을 바꾸면 전량 재색인도 필요하다. 개인·팀 규모의 운영 기억에는 파일 포맷이, 대규모 문서 지식에는 검색 스택이 맞는 도구라는 구분이 먼저다.

사람 편집을 허용하면 오류를 발견한 시점에 바로 수정할 수 있고, 도메인 지식을 직접 반영하며, 조직이 저장 내용에 대한 통제권을 유지할 수 있다. 대신 형식을 어긴 편집, 사람과 에이전트의 동시 수정 충돌, 검증되지 않은 개인 판단의 반영 문제가 생긴다. 시스템 전용 관리는 형식을 일관되게 유지하고 충돌을 줄이며 저장 규칙을 코드로 강제할 수 있지만, 오류를 발견해도 고칠 수단이 없고 저장 로직의 결함이 기억의 결함으로 이어진다. 편집을 허용하되 커밋 단계에서 스키마를 검증하고 범주별 권한을 나누는 방식이 두 요구를 함께 다룬다.

전량 로딩은 관련 기억을 놓치지 않고 선별 로직 없이 예측 가능한 동작을 제공한다. 그러나 기억이 늘수록 컨텍스트를 잠식하고, 무관한 과거 사실이 판단을 왜곡하며, 입력 비용은 항목 수에 비례해 증가한다. 선별 로딩은 관련 항목만 넣어 컨텍스트 예산을 아끼고 신호 대비 잡음을 줄여 정확도를 높일 수 있다. 대신 선별에서 빠진 기억은 없는 것과 같고, 선별 기준도 유지 관리 대상이 되며, 왜 어떤 기억이 쓰이지 않았는지 설명하기 어려워진다. 유효 범위로 먼저 필터링한 뒤 그 안에서 관련성을 기준으로 다시 고르는 방식은 누락 위험과 예산 문제를 함께 줄인다.

데이터 수명과 형상 통제로 보는 메모리

스키마 정의와 항목 단위 경계는 데이터 표준화와 정합성 확보 활동에 해당한다. 유효 범위 필드는 데이터가 적용되는 범위와 맥락 메타데이터를 관리하는 장치다.

만료 표현과 폐기 표시는 보유 기간 정책과 파기 절차를 저장 형식에 구현하는 방식이다. 저장 범주마다 보관 기간을 달리 두는 것은 정보 분류에 따른 수명주기 차등 적용으로 볼 수 있다.

버전 관리 기반의 이력과 되돌림은 형상 항목 통제와 변경 추적성 요구에 대응한다. 항목에 남기는 스키마 버전은 베이스라인 식별과 호환성 관리의 역할을 한다.

저장 형식 중심의 메모리 운영이 향하는 곳

에이전트 메모리를 검색 문제가 아니라 저장 형식 문제로 다루는 접근은 소규모 운영 기억 영역에서 표준이 되는 방향으로 움직이고 있다. 메모리 파일 스키마의 사실상 표준이 오픈소스 진영에서 형성되고 도구 간 이식이 논의되는 흐름도 이어지고 있다.

버전 관리 시스템 위에 기억을 올리는 구성은 감사 가능성 요구와 맞물려 확산되는 방향이다. 유효 범위와 만료를 형식에 명시하는 관행 역시 잘못된 기억의 수명을 줄이는 통제 수단으로 자리 잡는 흐름이다.

기억이 인프라 안에 갇히면 사람은 저장 내용을 확인하거나 수정하기 어렵고, 오류는 조용히 재사용된다. 파일 포맷 중심의 설계는 열어볼 수 있는 형식이 통제 수단이라는 점에서 출발한다. 사실 하나를 항목 하나에 담고, 유효 범위와 만료를 필드로 남기며, 버전 관리로 이력을 확보하는 구성이 최소 기반이 된다. 다만 항목이 크게 늘면 파일 포맷은 관련성 판단에 한계를 드러내므로, 운영 기억과 대규모 문서 지식을 같은 저장소 문제로 묶지 않는 판단이 필요하다.