에이전트는 기억이 필요하지 않다: 문서 기반 컨텍스트의 사례

RAG 기반 에이전트 기억의 실패

현재 대부분의 AI 에이전트 '기억' 플러그인은 검색 보강 생성(RAG)을 기반으로 한 결함이 있는 아키텍처에 의존한다. 이 접근 방식은 일반적으로 세션 대화 기록을 분석하고 고립된 '기억' 조각을 생성하며, 이를 벡터 데이터베이스에 저장한 후, 매번 프롬프트에 가장 유사한 몇 개의 조각을 삽입하는 방식이다.

이 아키텍처는 기억을 유사도 검색의 복권처럼 다루는 것이 아니라 프로젝트에 대한 구조화된 이해를 필요로 하기 때문에 실패한다. 주요 기술적 한계는 다음과 같다:

• 컨텍스트 부족: RAG 조각은 고립된 조각들이다. 원래 대화를 둘러싼 동기, 환경, 교훈은 모두 상실된다.
• 유사도 ≠ 정확성: 임베딩 기반 검색은 벡터 공간에서 수학적 가까움을 기준으로 조각을 순위 매기지만, 정보가 최신인지 또는 정확한지 여부는 고려하지 않는다.
• 노후화: 코드베이스는 매일 진화하지만, RAG 기억은 종종 불변의 진리로 간주되며, 이로 인해 에이전트는 오래된 인증 방식이나 폐기된 API에 의존하게 된다.
• 눈멀음: 에이전트는 자신이 모르는 것을 검색할 수 없다. 특정 제약 조건이 존재한다는 것을 모르면, 관련 기억 조각을 검색할 수 없다.
• 감사 불가능성: 벡터 데이터베이스는 검은 상자이다. 인간이 어떤 기억이 존재하는지, 어떤 것이 노후되었는지, 어떤 잘못된 조각이 에이전트 행동에 비밀리에 영향을 미치는지 감사하는 것은 거의 불가능하다.

기억에서 문서로의 전환

기억을 회상하는 시도 대신, 에이전트는 지침, 사양, 결정, 연구를 기록할 수 있는 구조화된 작업 공간—"뇌"—이 필요하다. 이는 에이전트 루프를 프롬프트 → 빌드 → 잊기의 사이클에서 프롬프트 → 참고 → 빌드 → 업데이트의 더 지속 가능한 사이클로 전환한다.

문서 기반 시스템에서는 에이전트가 백그라운드 데몬이 "꿈꾸거나" 컨텍스트를 압축하도록 의존하지 않는다. 대신, 작업을 시작하기 전에 관련 Markdown 파일을 읽어 컨텍스트를 얻고, 작업이 완료되면 해당 파일을 업데이트한다. 이렇게 함으로써 "기억"은 읽고, 업데이트하고, 버전 관리(Git)에 커밋하며 팀 내에서 공유할 수 있는 살아있는 문서가 된다.

구현: 오퍼레이터 메모리 모델

이 철학의 실용적 구현 중 하나는 Operator Memory로, 벡터 데이터베이스를 Markdown 기반의 뇌로 대체한다. 이 시스템은 단순한 전제에 기반한다: 중요한 지식을 일반 텍스트로 지속적으로 보관하라. 작업 전에 에이전트는 관련 문서를 뇌에서 참고하고, 작업 후에는 오래된 문서를 다시 확인하여 필요한 경우 새 문서를 추가한다.

커뮤니티의 시각과 대안적 접근법

개발자들 사이의 논의는 에이전트 컨텍스트를 관리하는 다양한 전략을 보여주며, 극단적인 최소주의에서 복잡한 구조화된 시스템에 이르기까지 다양한 방향을 포함한다.

"코드는 문서다" 학파

일부 개발자들은 외부 문서가 "루베 골드바흐 기계"이며 결국 노후화된다고 주장한다. 그들은 코드 자체만이 진실의 유일한 소스라고 주장한다:

"코드가 문서다... 문서는 항상 코드의 대체물이었다. 컨텍스트가 없는 사람들이 시작할 수 있도록 하기 위한 것이었다. 분명히 코드를 읽는 것과 문서를 읽는 것의 비용이 같다면, 문서는 완전히 쓸모없다."

구조화된 작업 공간 전략

다른 이들은 특정 폴더 구조와 전용 파일을 통해 에이전트를 안내하는 데 성공했다:

• 워크벤치 패턴: 에이전트가 일시적인 노트와 프로젝트 지도를 기록하는 .workbench 또는 internal/ 폴더(일반적으로 git-ignored)를 사용한다.
• 핸드오프 패턴: 에이전트가 세션 시작 시 반드시 읽고, 세션 종료 전에 업데이트해야 하는 STATUS.md 또는 handoff.md 파일을 만든다. 이는 서로 다른 에이전트 세션 또는 다른 모델 간의 원활한 전환을 보장한다.
• ADRs(아키텍처 결정 기록): 어떤 결정이 왜 내려졌는지에 대한 공식 기록을 사용하여, 에이전트가 프로젝트의 최종 상태가 아니라 발전 과정을 이해할 수 있도록 한다.
• 원칙 기반 개발: 과거 사건의 구체적인 기억 대신, 높은 수준의 원칙(예: "JSON 파싱에는 Python 대신 jq를 사용하라")을 작성하여 에이전트가 따라야 할 기준을 제공한다.

문서 기반 기억에 대한 기술적 비판

문서 중심 접근법에 대한 비판자들은 이 방법이 단지 문제를 한 매체에서 다른 매체로 옮길 뿐이라고 지적한다:

• 발견 문제: RAG와 마찬가지로, 정보가 존재한다는 것을 모른다면 어떤 Markdown 파일을 열어야 할지 에이전트는 알 수 없다.
• 유지보수 부담: 문서는 적극적인 유지보수가 필요하다. 에이전트가 코드와 문서를 일치시키도록 엄격히 프롬프트되지 않으면, 문서는 혼란의 원인이 된다.
• 토큰 비용: "뇌"가 커질수록 여러 대규모 문서를 읽고 업데이트하는 비용이 급증할 수 있으며, 이는 몇 개의 RAG 조각보다 비용이 더 커질 수 있다.

요약 표: RAG 기억 vs. 문서 기반 기억

기능	RAG 기반 기억	문서 기반 기억
저장소	벡터 데이터베이스(임베딩)	일반 텍스트(Markdown)
검색 방식	유사도 검색	명시적 참고/인덱싱
감사 가능성	낮음(검은 상자)	높음(인간이 읽을 수 있음/Git)
진실의 근거	역사적 대화 기록	현재 사양/문서
업데이트 메커니즘	추가 전용/백그라운드 데몬	활성 편집/업데이트
컨텍스트	고립된 조각	구조화된 문서