에이전트 메모리는 이제 리뷰의 문제입니다

에이전트 메모리에 대한 지루한 견해는 코딩 에이전트가 너무 많은 것을 잊어버린다는 것입니다.

그것은 사실이지만, 문제에서 가장 흥미롭지 않은 부분이기도 합니다.

진짜 문제는 에이전트가 컨텍스트 (Context)를 일시적인 것으로 취급하는 것을 멈추고, 이를 영구적인 상태 (Durable state)로 전환하기 시작할 때 발생합니다. 채팅에서의 잘못된 답변은 짜증을 유발할 뿐입니다. 잘못된 메모리는 더 나쁩니다. 왜냐하면 다음 작업, 다음 브랜치, 그리고 다음 리뷰를 조용히 유도할 수 있기 때문입니다. 그것은 엔지니어링 프로세스 (Engineering process)를 거치지 않고 엔지니어링 시스템 (Engineering system)의 일부가 되어 버립니다.

이것이 사람들이 계속해서 과소평가하고 있는 부분입니다.

지속적인 에이전트 메모리는 유용합니다. 저는 에이전트가 프로젝트 컨벤션 (Project conventions), 과거의 결정, 실패한 접근 방식, 배포 시의 특이사항, 명명 규칙 (Naming rules), 그리고 README에 결코 포함되지 않는 날카로운 예외 사항들을 기억하기를 바랍니다. 매일 아침 똑같은 저장소 (Repo)를 다시 설명하고 싶은 사람은 아무도 없습니다.

하지만 "더 많이 기억하기"는 전략이 아닙니다. 그것은 그럴듯한 브랜딩을 입힌 저장 정책 (Storage policy)일 뿐입니다.

만약 메모리가 미래의 행동을 바꿀 수 있다면, 그것은 우리가 이미 코드에 대해 기대하는 것과 동일한 지루한 통제 장치들, 즉 소유권 (Ownership), 리뷰 (Review), 출처 (Provenance), 수정 (Correction), 삭제 (Deletion), 그리고 그것이 여전히 유효한지 판단할 수 있는 방법이 필요합니다.

메모리는 느낌(Vibes)이 아니라 상태(State)입니다

많은 에이전트 메모리 논의는 여전히 컨텍스트 윈도우 (Context-window) 문제처럼 들립니다.

에이전트가 지난주에 우리가 결정한 것을 잊어버렸습니다. 에이전트가 세션 사이의 맥락을 놓쳤습니다. 에이전트가 동일한 저장소 구조를 재발견하느라 토큰 (Tokens)을 낭비했습니다. 좋습니다. 그것들은 실제적인 짜증을 유발하는 요소들입니다.

하지만 일단 에이전트에게 영구적인 메모리를 부여하면, 단순히 회상 능력 (Recall)을 향상시키는 것만이 아닙니다. 당신은 상태 (State)를 생성하는 것입니다.

그 상태는 틀릴 수 있습니다. 오래될 수 있습니다. 일회성 임시 방편에서 복사될 수 있습니다. 임시 마이그레이션 규칙을 마치 영구적인 아키텍처 원칙인 것처럼 인코딩할 수 있습니다. 인간의 불완전한 코멘트를 요구 사항으로 기억할 수도 있습니다. 또한 메모리 레이어 (Memory layer)가 너무 성급하다면 프로젝트나 도구 간에 정보가 유출될 수도 있습니다.

이것이 제가 단순히 회상 범위 (Recall surface)가 가장 큰 것이 승리하는 메모리 시스템이라는 아이디어를 믿지 않는 이유입니다.

승자는 아마도 팀이 관리(Govern)할 수 있는 시스템일 것입니다.

최근의 에이전트 스택(Agent Stack)도 이미 이 방향으로 움직이고 있습니다

DEV에서의 Hermes/OpenClaw 논의는 흥미롭습니다. 정확한 제품 간의 경쟁이 핵심이 아니기 때문입니다. 유용한 신호는 스택의 형태입니다: 지속적인 런타임 (Persistent runtime), 메모리 (Memory), 기술 (Skills), 백그라운드 작업 (Background work), 샌드박스 실행 (Sandboxed execution), 그리고 범위가 지정된 도구 (Scoped tools)입니다.

이것이 코딩 에이전트가 명확히 나아가고 있는 방향입니다. 채팅창은 그 주변을 둘러싼 운영 표면 (Operating surface)보다 중요성이 낮아지고 있습니다.

동일한 패턴이 agent-skills에서도 나타납니다. 해당 리포지토리 (Repo)는 에이전트 메모리 데이터베이스가 되려고 시도하는 것이 아닙니다. 그것은 지속 가능한 에이전트 지식 (Durable agent knowledge)이 어떤 모습이어야 하는지에 대한 모델로서 더 유용합니다: 일반 파일 (Plain files), 명확한 절차 (Clear procedures), 라이프사이클 단계 (Lifecycle steps), 검증 게이트 (Verification gates), 그리고 도구들을 가로질러 이동할 수 있는 워크플로우 (Workflows)입니다.

이것은 중요합니다.

불투명한 메모리 블롭 (Opaque memory blob)은 "나를 믿으세요, 무언가를 기억해냈습니다"라고 말합니다. 반면 기술 (Skill)이나 런북 (Runbook)은 "여기에 제가 따를 절차가 있고, 여기 당신이 차이(diff)를 확인할 수 있는 파일이 있습니다"라고 말합니다.

에이전트가 프로덕션 코드 (Production code)를 건드리도록 허용하기 전에, 저는 어떤 것을 더 검토 (Review)하고 싶은지 알고 있습니다.

검색 (Retrieval)은 거버넌스 (Governance)가 아닙니다

여기에는 유혹적인 엔지니어링적 해답이 있습니다: 더 나은 검색 (Better search).

벡터 검색 (Vector search)을 사용하십시오. BM25를 추가하십시오. 랭킹을 융합 (Fuse rankings)하십시오. 트랜스크립트 (Transcripts)를 저장하십시오. 시간별로 필터링하십시오. 세션 (Sessions)을 요약하십시오. 가장 관련성 높은 메모리를 프롬프트 (Prompt)로 가져오십시오.

이 모든 것들이 도움이 될 수 있습니다. 로컬 에이전트 메모리 (Local agent memory)에 관한 Reddit 빌더 스레드는 실질적인 방향에 대한 좋은 예시입니다: 로컬 저장소 (Local storage), 하이브리드 검색 (Hybrid retrieval), 세션 관리 (Session management), 도구 호출 이력 (Tool-call history), 그리고 에이전트 간 호환성 (Cross-agent compatibility). 이것들은 유용한 조각들입니다.

하지만 이것들은 여전히 중요한 질문에 답하지 못합니다.

검색은 오래된 메모리를 찾아낼 수는 있습니다. 하지만 그 메모리가 사실인지 여부는 결정할 수 없습니다.

이전의 임시 방편 (Workaround)이 일시적인 것이었는지 알려줄 수 없습니다. 팀이 지난달에 배포 경로 (Deployment path)를 변경했는지 알 수 없습니다. 기억된 지침이 무작위 디버깅 세션이 아닌 유지 관리자 (Maintainer)로부터 온 것임을 증명할 수 없습니다. 특정 규칙이 만료되어야 하는지 결정할 수 없습니다.

그 결정에는 라이프사이클 (Lifecycle)이 필요합니다.

라이프사이클 (Lifecycle)이 없다면, 메모리는 또 다른 형태의 프롬프트 인젝션 (Prompt Injection)이 됩니다. 다만 이제 공격자는 새벽 2시의 당신 자신일 수도 있다는 점이 다를 뿐입니다.

유용한 체크리스트는 복잡하지 않습니다

만약 에이전트 메모리 레이어 (Agent memory layer)가 실제 소프트웨어 작업에서 신뢰받기를 원한다면, 저는 다음과 같은 여섯 가지 지루한 요구사항부터 시작할 것입니다.

첫째, 메모리는 검사 가능 (Inspectable)해야 합니다. 개발자는 벡터 데이터베이스 (Vector database)를 샅샅이 뒤지지 않고도 에이전트가 프로젝트에 대해 무엇을 믿고 있는지 확인할 수 있어야 합니다.

둘째, 수정 가능 (Correctable)해야 합니다. 메모리가 잘못되었다면, 이를 수정하는 것은 일반적인 편집 과정이어야지 하나의 의식처럼 느껴져서는 안 됩니다.

셋째, 출처 (Provenance)가 있어야 합니다. 병합된 아키텍처 문서에서 온 메모리는 임시 브랜치 (Temporary branch)에서 추론된 메모리와는 다릅니다.

넷째, 팀이 하나의 에이전트 런타임 (Agent runtime)에 영원히 종속되지 않도록 충분히 이식 가능 (Portable)해야 합니다.

다섯째, 권한 (Permissioned)이 부여되어야 합니다. 어떤 메모리는 프로젝트에 속하고, 어떤 메모리는 사용자에게 속합니다. 어떤 메모리는 절대 저장되어서는 안 됩니다.

여섯째, 가지치기 (Prunable)가 가능해야 합니다. 오래된 컨텍스트 (Context)에는 반감기가 있습니다. 그렇지 않은 척하는 것이 바로 에이전트가 죽은 결정을 계속해서 부활시키는 방식입니다.

이 중 그 어떤 것도 화려하지 않습니다. 바로 그것이 핵심입니다.

에이전트 생태계는 소프트웨어 엔지니어링의 가치 있는 부분들이 대개 가장 마법처럼 보이지 않는 부분들—디프 (Diffs), 리뷰 (Reviews), 테스트 (Tests), 소유권 (Ownership), 변경 로그 (Changelogs), 그리고 지루한 텍스트 파일들—이라는 사실을 계속해서 재발견하고 있습니다.

메모리 쓰기를 변경 사항처럼 취급하세요

제가 생각할 수 있는 가장 단순한 모델은 다음과 같습니다:

에이전트가 세션 (Session)을 마칩니다.
에이전트가 메모리 항목 또는 스킬 (Skill) 업데이트를 제안합니다.
사람이 제안된 변경 사항을 평이한 언어로 확인합니다.
팀이 이를 수락, 편집, 거부 또는 범위를 지정합니다.
주기적인 정리 (Cleanup)를 통해 오래되거나 위험한 항목을 제거합니다.

이것이 전부입니다.

모든 메모리에 풀 리퀘스트 (Pull request) 의식이 필요하지는 않습니다. 1인 개발자는 더 가벼운 흐름을 사용할 수 있습니다. 규제를 받는 팀은 더 엄격한 통제가 필요할 수도 있습니다. 핵심은 관료주의가 아닙니다. 핵심은 내구성이 있는 메모리가 향후 작업이 수행되는 방식을 조용히 변질시켜서는 안 된다는 것입니다.

이는 특히 스킬 (Skills)에 있어 매우 중요합니다.

스킬 (Skill)은 절차적 메모리 (Procedural memory)입니다. 이는 "이런 종류의 작업이 나타나면, 이렇게 하라"고 말합니다. 이는 믿을 수 없을 정도로 강력합니다. 하지만 만약 아무도 그 절차를 검토하지 않는다면, 이는 나쁜 습관을 제도화하는 훌륭한 방법이 되기도 합니다.

스킬을 가치 있게 만드는 바로 그 점이 스킬을 위험하게 만들기도 합니다. 바로 그것들이 복리로 쌓이기 (Compound) 때문입니다.

카테고리는 실재하지만, 기준은 더 높아야 합니다

AgentMemory 및 유사한 제품들은 이 카테고리가 더 이상 이론적인 단계가 아님을 보여주는 신호입니다. 개발자들은 세션 간의 연속성 (Cross-session continuity)을 원합니다. 반복적인 설명을 줄이고 싶어 합니다. 로컬 제어, 토큰 낭비 감소, 그리고 중단된 지점부터 다시 시작할 수 있는 에이전트를 원합니다.

좋습니다. 그것은 올바른 요구사항입니다.

댓글과 커뮤니티 스레드에서 나오는 반론들 또한 옳습니다. 사람들은 오래된 메모리 (Stale memories), 내보내기 (Exports), 비밀 정보 (Secrets), 충돌 (Conflicts), 수정 흐름 (Correction flows), 그리고 메모리가 그저 더 멋진 이름을 붙인 또 다른 숨겨진 프롬프트 레이어 (Prompt layer)가 아닌지에 대해 묻고 있습니다.

그러한 회의론은 건강합니다.

에이전트 메모리는 제품의 표면 (Product surface)이 잘못될 경우, 데모에서는 놀랍게 느껴지지만 팀 단위로 사용할 때는 고통스러운 기능 중 하나가 될 것입니다. 데모 버전은 적절한 시점에 적절한 것을 기억합니다. 하지만 프로덕션 버전은 왜 그것을 기억했는지, 그것이 어디에서 왔는지, 누가 그것을 변경할 수 있는지, 그리고 언제부터 그것을 신뢰하지 말아야 하는지를 설명할 수 있어야 합니다.

이는 "무한한 메모리"라는 말보다 덜 흥미롭게 들릴 것입니다.

하지만 이것이 영리한 어시스턴트와, 당신이 안전하게 그 주변에 구축할 수 있는 도구 사이의 차이점입니다.

마지막 생각

다음 에이전트 메모리 경쟁은 누가 더 많은 컨텍스트 (Context)를 저장하느냐에 관한 것이어서는 안 됩니다.

누가 메모리를 검토 가능하게 (Reviewable) 만드느냐에 관한 것이어야 합니다.

왜냐하면 메모리가 내구성 (Durable)을 갖게 되는 순간, 그것은 더 이상 편의 기능이 아니기 때문입니다. 그것은 당신의 엔지니어링 프로세스의 일부가 됩니다. 그렇게 취급하십시오. 그렇지 않으면 메모리는 아무도 검토하지 않지만 모두가 서서히 의존하게 되는, 보이지 않는 팀원이 될 것입니다.

Source notes

참고 자료