AI 에이전트를 며칠 이상 써본 팀이라면 비슷한 경험을 한다. 어제 결정한 설계 방향을 에이전트가 오늘 모른다. 이전 세션에서 합의한 내용을 다시 설명해야 한다. 작업이 쌓일수록 에이전트가 처음 보는 것처럼 반응한다.
이 상황에서 팀은 자연스럽게 메모리 플러그인을 찾는다. 하지만 그 선택이 실제로 문제를 해결하는지 먼저 따져볼 필요가 있다. 문제의 원인이 다른 곳에 있다면, 플러그인을 붙여도 같은 불만이 반복된다.
메모리 플러그인이 공통으로 가진 구조적 가정
시장에 나와 있는 메모리 플러그인들은 구현 방식이 다양해 보이지만 기본 구조는 같다. 대화 이력을 분석해 기억 조각을 만들고, 벡터 데이터베이스에 저장한 뒤, 매 프롬프트마다 현재 입력과 유사도가 높은 조각을 꺼내 에이전트에 주입한다. 일부 도구는 여기에 단기·장기 메모리를 별도로 분류하는 계층을 추가하거나, 백그라운드 프로세스를 통해 기억 조각을 검토·병합·중복 제거하거나, 야간에 기억을 재작성하는 처리, 지속적인 맥락 압축, 재랭킹까지 얹는다.
이 모든 변형의 공통된 가정은 하나다. "에이전트가 잊는 것이 문제이므로, 더 많이 기억하게 만들면 해결된다." 기억 조각을 더 많이 쌓고, 더 정교하게 검색하고, 더 스마트하게 주입하면 에이전트가 맥락을 유지할 수 있다는 논리다.
이 가정 자체가 틀렸다는 것이 문제의 핵심이다.
유사도 검색이 작업 맥락을 대체할 수 없는 이유
벡터 검색은 현재 프롬프트와 의미적으로 가까운 조각을 꺼낸다. 그 조각이 현재 작업에 맞는 정보인지, 지금도 유효한 정보인지는 따지지 않는다.
에이전트가 실제로 필요한 것은 "이 기능이 왜 이렇게 설계됐는가", "그 결정 당시 어떤 조건이 전제됐는가" 같은 맥락이다. 유사도가 높다고 해서 지금 작업에 맞는 정보라는 보장이 없고, 유사도가 낮다고 해서 중요하지 않다는 뜻도 아니다.
몇 가지 구조적 한계가 더 있다.
에이전트는 자신이 모르는 것이 무엇인지 모른다. 검색 도구를 줘도, 어떤 키워드로 무엇을 찾아야 하는지 판단하기 어렵다. 코드베이스가 어제 변경됐어도, 벡터 데이터베이스 안의 수백 개 기억 조각이 여전히 유효한지 에이전트는 알 방법이 없다. 저장소 전체가 감사 불가능한 상태가 된다. 어떤 조각이 오래됐는지, 어떤 조각이 실제로 검색된 적이 있는지, 어떤 조각이 지금 에이전트의 판단에 영향을 주고 있는지 팀은 확인할 수 없다.
이것은 특정 플러그인의 구현 품질 문제가 아니다. 구조 자체가 틀린 문제를 해결하려 하고 있다.
조직이 지식을 관리하는 방식을 생각해보면 이해하기 쉽다. 3년 전 회의 녹취를 다시 들어서 설계 제약 조건을 파악하는 사람은 없다. 그 내용을 문서로 정리해두고, 필요할 때 그 문서를 읽는다. 에이전트에게도 같은 방식이 적용된다.
에이전트에게 필요한 것은 검색 능력이 아니라 읽을 수 있는 구조
이미 많은 팀이 AGENTS.md 파일을 사용한다. 에이전트가 코드베이스를 아무런 정보 없이 시작하지 않도록 기본 지침을 적어두는 방식이다. 이것이 실제로 작동한다는 사실 자체가 방향을 알려준다. 문제는 대부분의 프로젝트에서 이 단일 파일이 에이전트에게 주어진 유일한 문서라는 점이다.
파일 하나로는 부족하다. 어떤 기능이 어떤 이유로 그렇게 설계됐는지, 외부 라이브러리나 API에 대해 이미 확인된 사항이 무엇인지, 사용자와 어떤 내용을 합의했는지를 에이전트가 작업 전에 읽고 작업 후에 갱신할 수 있는 구조가 있어야 한다.
이 구조가 갖춰지면 에이전트의 작업 흐름이 달라진다. 프롬프트를 받으면 관련 문서를 먼저 읽고, 작업을 마친 뒤에는 문서가 여전히 유효한지 확인하고 필요하면 갱신한다. 기억이 검색 데이터베이스에서 확률적으로 떠오르는 것이 아니라, 팀이 함께 읽고 수정하고 버전 관리할 수 있는 파일로 존재한다. 임베딩도, 백그라운드 요약 프로세스도 필요하지 않다. 에이전트가 무엇을 알고 있는지 팀이 직접 열어서 확인하고 고칠 수 있다.
요구사항 단계에서 먼저 답해야 할 질문들
AI 에이전트 도입을 검토 중이라면, 메모리 관련 요구사항을 정의하기 전에 아래 질문에 답할 수 있는지 확인하는 것이 현실적이다.
프로젝트의 주요 설계 결정이 어딘가에 적혀 있는가. 회의록, 이슈 댓글, 구두 합의에만 존재한다면, 에이전트가 그 내용을 찾아낼 방법이 없다. 메모리 플러그인도 마찬가지다. 대화 이력에서 조각을 긁어모아 맥락을 재구성하려 해도, 결정 이유와 설계 원칙이 대화 속에 흩어져 있다면 검색 품질이 낮아지고 오래된 정보와 최신 정보가 뒤섞인다.
에이전트가 작업 전에 읽을 수 있는 파일 형태가 있는가. 코드베이스 구조, 기능별 설계 스펙, 외부 의존성 정리 파일 중 어느 것이든, 참고할 수 있는 파일이 있어야 한다.
문서를 누가, 언제 갱신하는가. 에이전트가 작업 후 직접 갱신하든, 팀원이 정기적으로 갱신하든, 갱신 주체와 시점이 정해지지 않으면 문서는 금방 낡는다. 낡은 문서를 읽는 에이전트는 낡은 판단을 내린다.
에이전트가 작성하거나 갱신한 문서를 팀이 검토할 수 있는가. 에이전트가 문서를 직접 업데이트하는 구조라면, 그 내용이 사람이 읽고 확인할 수 있는 형태여야 한다. 팀이 검토하지 않는 자율 갱신 구조는 신뢰할 수 없는 정보가 누적되는 경로가 된다.
팀이 에이전트에게 "이전에 우리가 무엇을 결정했는지 알아야 한다"고 요구하는 상황이라면, 그 결정이 어디에 적혀 있는지부터 확인해야 한다. 아무 데도 적혀 있지 않다면, 문제는 에이전트의 기억 능력이 아니라 팀의 기록 방식이다.
어디서부터 시작할 수 있는가
완성된 문서화 시스템을 먼저 갖춰야 AI 에이전트를 쓸 수 있다는 말이 아니다. 그렇게 되면 시작 자체가 어려워진다.
현실적인 출발점은 에이전트가 작업을 시작하기 전에 읽을 파일 하나를 만드는 것이다. 프로젝트 구조, 최근 주요 결정, 진행 중인 작업의 상태를 담는다. 에이전트가 작업을 마칠 때마다 그 파일을 갱신하도록 지시한다. 규모가 커지면 기능별로 파일을 나누고, 어떤 파일이 어디에 있는지 안내하는 인덱스 파일을 추가한다.
메모리 플러그인 도입 여부는 이 기반이 어느 정도 갖춰진 다음에 평가해야 판단이 가능하다. 에이전트가 읽을 문서가 없는 상태에서 기억 능력을 보강하는 일은, 어디로 가야 하는지 모르면서 더 빠른 이동 수단을 구하는 것과 비슷하다. 방향이 먼저고, 도구는 그다음이다.
