AI Memory는 RAG가 아니다

AI Agent · 2026-05-06 · 6분 읽기

Markdown약 2043 tokens

AI 에이전트에서 memory는 가장 쉽게 과장되는 기능 중 하나입니다. 모든 로그를 기억시키면 똑똑해질 것 같지만, 실제로는 오래된 가정과 일회성 실패가 다음 작업을 오염시킬 수 있습니다.

반대로 아무것도 기억하지 않으면 에이전트는 같은 실패를 반복합니다. 따라서 필요한 것은 “많은 기억”이 아니라 “검증된 기억으로 승격하는 절차”입니다.

이 글의 결론은 단순합니다.

실패는 먼저 Run Ledger에 남기고, 반복 가능하고 검증된 지식만 Memory로 승격해야 한다.

핵심 요약

RAG는 외부 지식을 검색하는 계층이고, Memory는 검증된 반복 지식을 다음 작업에 넘기는 계층입니다.
Transcript, Failure Artifact, Memory Candidate, Validated Memory를 구분해야 합니다.
GitHub Copilot Memory는 code location citation, 현재 branch 검증, stale memory 삭제 정책을 강조합니다.
Claude Code는 CLAUDE.md와 auto memory를 분리하고, memory를 enforced configuration이 아니라 context로 취급합니다.
실패 산출물은 goal 전체가 아니라 task attempt 단위로 기록하는 것이 좋습니다.

Memory와 RAG는 다르다

RAG는 필요한 지식을 검색해서 현재 작업에 넣는 방식입니다.

예를 들면 다음은 RAG입니다.

1API 문서 검색2이전 PR 검색3설계 문서 검색4README 검색5이슈 검색

반면 Memory는 에이전트가 작업하면서 알게 된 프로젝트별 반복 지식을 다음 작업에 넘기는 계층입니다.

다음은 memory 후보에 가깝습니다.

1이 저장소는 pnpm만 사용한다.2integration test 전에 db:prepare를 실행해야 한다.3billing 모듈 수정 시 contract test도 함께 수정해야 한다.4src/lib/db.ts를 거치지 않는 DB 접근은 금지한다.

둘은 목적이 다릅니다.

구분	RAG	Memory
목적	외부 지식 검색	반복 지식 유지
출처	문서, 코드, 이슈, PR	작업 중 검증된 사실
수명	현재 작업 중심	여러 작업에 재사용
위험	검색 누락	오래된 정보 오염
필요한 메타데이터	relevance	source, scope, validation, expiration

GitHub Copilot Memory가 보여주는 설계 원칙

GitHub Copilot Memory 문서는 Copilot이 repository-specific memory를 저장하고, Copilot coding agent, code review, CLI에서 활용할 수 있다고 설명합니다.

중요한 점은 memory가 code location citation과 함께 저장되고, 사용 전 현재 codebase와 branch에 대해 검증되며, stale memory 방지를 위해 28일 뒤 자동 삭제된다는 점입니다.

여기서 얻을 수 있는 설계 원칙은 세 가지입니다.

11. Memory에는 출처가 있어야 한다.22. 현재 코드베이스에서 검증되어야 한다.33. 오래된 memory는 만료되어야 한다.

좋은 memory는 이렇게 생겨야 합니다.

1Validated Memory:2  Fact:3    integration test 실행 전 pnpm db:prepare가 필요하다.4 5  Source:6    - package.json scripts7    - docs/testing.md8    - CI workflow9 10  Scope:11    - test/integration/**12    - 현재 repository13 14  Validated At:15    2026-05-0616 17  Expiration:18    30일 후 재검증

반대로 다음은 memory가 아닙니다.

1아까 테스트가 실패했다.

이건 transcript 또는 run ledger entry입니다.

Claude Code memory가 보여주는 instruction과 memory 분리

Claude Code memory 문서는 memory 파일과 auto memory를 설명하면서, Claude가 이를 enforced configuration이 아니라 context로 취급한다고 설명합니다. /memory 명령은 로드된 memory 파일과 auto memory 설정을 확인하는 흐름을 제공합니다.

이 구분은 중요합니다.

계층	작성자	역할
`CLAUDE.md`	사람	instruction, rule, workflow
Auto memory	에이전트	작업 중 배운 패턴
Permission policy	시스템 또는 하네스	실제 차단과 승인

CLAUDE.md에 “secret을 읽지 마라”고 쓰는 것은 좋은 instruction입니다. 하지만 보안 정책은 아닙니다. 보안 정책은 실제 파일 접근, network access, production command, secret 출력 등을 차단하는 permission layer에서 처리해야 합니다.

Memory는 context입니다. Permission은 enforcement입니다. 둘을 섞으면 위험합니다.

장기 기억은 생각보다 어렵다

Memory를 만들면 모든 문제가 해결될 것 같지만 실제로는 그렇지 않습니다. 장기 기억은 temporal reasoning, causal reasoning, multi-hop reasoning과 얽힙니다.

LoCoMo 관련 연구는 long-term conversational memory를 평가하면서 긴 대화의 시간적 관계, 인과 관계, 다중 홉 회상을 다룹니다. 코딩 에이전트에도 같은 문제가 있습니다.

오래된 memory는 오히려 위험할 수 있습니다.

1예전에는 npm을 썼지만 지금은 pnpm으로 바뀌었다.2예전 테스트 명령은 더 이상 유효하지 않다.3예전 DB 경로는 리팩터링으로 사라졌다.

따라서 memory는 많이 저장하기가 아니라 검증해서 적게 저장하기가 핵심입니다.

실패 산출물은 어디에 남겨야 하나

AI 작업에서 실패 산출물의 단위는 goal 전체가 아닙니다. 하나의 goal 안에는 여러 task가 있고, 실패는 그보다 작은 attempt에서 발생합니다.

Goal: checkout flow 개선

Task 1: 기존 결제 흐름 분석

Task 2: payment client 교체

Task 3: webhook handler 수정

Task 4: 테스트 작성

Task 5: 실패 테스트 수정

Failure Artifact: task attempt 단위

실패는 보통 task attempt 단위로 발생합니다.

따라서 실패 산출물은 이렇게 남겨야 합니다.

1Agent Turn보다 크고,2Goal보다 작은,3검토 가능한 Task Attempt 단위

너무 작게 저장하면 노이즈가 많습니다. 너무 크게 저장하면 원인을 찾기 어렵습니다.

Run Ledger 기본 구조

Run Ledger는 작업 실행 기록입니다.

1Run Ledger Entry:2  task_id: profile-form-validation3  attempt_id: attempt-0034 5  input:6    - src/app/settings/profile/page.tsx7    - src/features/profile/schema.ts8    - pnpm test output9 10  action:11    - client validation schema 구조 변경12    - form error mapping 수정13    - unit test 실행14 15  result: failed16  evidence: pnpm test profile-form 실패17  diagnosis: client component가 server-only module을 참조함18  next_action: 공용 validation schema를 shared validation으로 분리19  memory_decision: 보류. 현재는 한 번의 실패이므로 memory로 승격하지 않음.

Run Ledger의 핵심은 “무엇을 했는지”와 “왜 실패했는지”를 분리하는 것입니다. 특히 memory_decision이 중요합니다. 모든 실패를 memory에 넣으면 안 됩니다.

Memory 승격 정책

Memory 승격은 보수적으로 해야 합니다. 전체 대화는 바로 memory가 아니라 검증 파이프라인을 거쳐야 합니다.

Transcript
Failure Artifact
Memory Candidate
Validated Memory

단계	설명	저장 여부
Transcript	전체 실행 로그	단기 보관
Failure Artifact	실패 요약	작업별 보관
Memory Candidate	반복 가능해 보이는 패턴	검토 필요
Validated Memory	현재 코드에서 검증된 지식	다음 작업에 주입

승격 기준은 다음과 같습니다.

1[ ] 같은 문제가 두 번 이상 반복되었는가?2[ ] 현재 코드베이스에서 확인 가능한가?3[ ] 특정 브랜치 임시 상태가 아닌가?4[ ] 출처 파일이나 로그가 있는가?5[ ] 적용 범위가 명확한가?6[ ] 만료 또는 재검증 조건이 있는가?

개발 하네스 적용 예시

하네스 구조는 이렇게 시작할 수 있습니다.

1.agent-runtime/2  goals/3    profile-update/4      goal.md5      run-ledger.md6      artifacts/7        failure-attempt-001.md8        test-result-002.md9  memory/10    candidates/11      candidate-001.md12    validated/13      test-conventions.md

중요한 것은 memory를 에이전트의 자유 메모장으로 만들지 않는 것입니다. Memory는 다음 실행에 영향을 주는 계층입니다. 따라서 사람이 읽고 수정할 수 있어야 합니다.

1읽을 수 있어야 한다.2삭제할 수 있어야 한다.3출처를 확인할 수 있어야 한다.4만료시킬 수 있어야 한다.

체크리스트

Memory를 붙이기 전에 아래 기준을 통과하지 못하면 먼저 Run Ledger부터 정리하는 편이 안전합니다.

1[ ] RAG와 Memory를 구분했다.2[ ] Transcript와 Memory를 구분했다.3[ ] 실패 기록은 Run Ledger에 먼저 남긴다.4[ ] Memory 승격 기준이 있다.5[ ] Memory에는 source가 있다.6[ ] Memory에는 scope가 있다.7[ ] Memory에는 validated_at이 있다.8[ ] Memory에는 expiration이 있다.9[ ] secret, 개인정보, token은 저장하지 않는다.10[ ] 사람이 memory를 감사하고 수정할 수 있다.

이번 편에서 가져갈 기준

Memory는 검색 인덱스도 아니고 전체 대화 로그도 아닙니다. 실패는 먼저 Run Ledger에 남기고, 반복 가능하며 현재 코드에서 검증된 사실만 Memory로 승격해야 합니다. memory를 저장하는 기준보다 버리는 기준이 더 중요합니다.

다음 편

5편에서는 지금까지의 내용을 실제 개발 하네스 문서 세트로 정리합니다. 바로 복사해서 쓸 수 있는 goal.md, run-ledger.md, artifact-contract.md, memory-policy.md, permission-policy.md 템플릿을 제공합니다.

시리즈 이어 읽기

1편: 코딩 에이전트는 왜 런타임이 되는가
2편: Codex /goal로 보는 목표 기반 개발
3편: A2A와 MCP로 보는 멀티 에이전트 개발 워크플로우
4편: AI Memory는 RAG가 아니다
5편: 개발 하네스에 적용하는 AI 코딩 에이전트 문서 세트

참고자료

독자 적용 노트

이 글은 AI agent나 코딩 도구를 실제 개발 업무에 적용하려는 개발자가 AI Memory는 RAG가 아니다이라는 주제를 단순 개념 설명이 아니라 운영 환경에서 재현 가능한 백엔드 판단 기준으로 점검하도록 작성했습니다. 본문에서 다룬 구조는 새 도구를 도입하거나 기존 워크플로우를 바꿀 때 "무엇을 먼저 확인해야 하는가"를 정하는 데 쓰는 것이 좋습니다.

원본 판단 근거

이 글의 판단은 Memory와 RAG는 다르다에서 설명한 구조와 본문 안의 예시, 표, 체크리스트를 함께 놓고 정리한 것입니다. 특히 독자가 그대로 복사할 수 있는 결론보다, 자신의 코드베이스나 팀 규칙에 맞춰 확인해야 할 경계와 실패 조건을 분리하는 데 초점을 둡니다.

실패 사례 또는 edge case

가장 흔한 실패는 운영 환경에서 재현 가능한 백엔드 판단 기준을 문서나 명칭만 맞춘 상태로 끝내는 것입니다. 예를 들어 실제 입력, 권한, 로그, 배포, 검증 기준이 연결되지 않으면 겉으로는 도입이 끝난 것처럼 보여도 다음 작업에서 같은 문제가 반복됩니다. 따라서 본문을 적용할 때는 "누가 실행하는가", "무엇을 기록하는가", "실패하면 어디서 멈추는가"를 같이 확인해야 합니다.

실무 체크리스트

이 글의 핵심 개념을 현재 프로젝트의 실제 파일, API, 로그, 문서 중 하나에 연결했다.
본문 예시를 그대로 쓰지 않고 우리 환경의 제약 조건으로 다시 검토했다.
실패 사례나 edge case를 하나 이상 정하고, 재현 또는 확인 방법을 적었다.
적용 후 바뀌어야 할 완료 기준과 검증 명령을 분리했다.

Q&A

Q1. 이 글의 내용을 바로 표준으로 써도 되나요?

바로 표준으로 고정하기보다 작은 작업 하나에 먼저 적용해 보는 편이 안전합니다. 실제 로그, 리뷰, 테스트에서 같은 판단이 반복해서 맞을 때 팀 표준으로 올리는 것이 좋습니다.

Q2. 본문 예시와 내 프로젝트가 다르면 어떻게 해야 하나요?

예시의 이름보다 경계를 보세요. 입력, 상태, 권한, 검증, 기록 중 어떤 경계를 다루는 글인지 먼저 찾고, 그 경계를 현재 프로젝트의 구조에 맞게 옮기면 됩니다.

참고자료와 불확실성

이 보강 노트는 본문에 이미 포함된 참고자료와 작성 시점의 공개 문서를 기준으로 합니다. 도구 버전, API 정책, 제품 UI는 바뀔 수 있으므로 실제 적용 전에는 공식 문서와 현재 런타임 동작을 다시 확인해야 합니다.

GitHub 계정으로 로그인하면 댓글을 남길 수 있습니다. 댓글은 GitHub Discussions를 통해 운영됩니다.