AI 에이전트가 이전 작업의 결정을 이어받도록 만들고 싶다면, 다시 찾아 쓸 정보를 저장하는 메모리와 반복 입력의 처리를 재사용하는 프롬프트 캐시를 구분해야 합니다. 메모리는 무엇을 기억하고 갱신할지의 문제이고, 캐시는 같은 입력을 어떻게 효율적으로 처리할지의 문제입니다.
둘을 함께 쓰면 도움이 될 수 있지만, 오래된 정보를 자동으로 바로잡거나 모든 비용을 없애지는 않습니다. 저장할 정보의 출처와 유효기간, 접근 권한, 검색 결과와 실제 사용량을 함께 확인해야 합니다.
작업 공간·메모리·캐시는 어떻게 다를까?
| 구분 | 하는 일 | 주의할 점 |
|---|---|---|
| 현재 컨텍스트 | 이번 요청에서 모델이 참고하는 내용 | 길이가 제한되고 불필요한 정보가 섞일 수 있음 |
| 장기 메모리 | 다음 작업에 다시 필요한 정보를 저장·조회 | 잘못됐거나 오래된 정보가 남을 수 있음 |
| 검색 | 현재 질문과 관련된 기록이나 문서 선택 | 관련성이 높아 보여도 정답·최신 자료는 아닐 수 있음 |
| 프롬프트 캐시 | 반복되는 입력의 처리 일부를 재사용 | 모든 요청이 적중하거나 전체 비용이 일정 비율 줄어드는 것은 아님 |
가상의 프로젝트에서 ‘배포 전에 테스트를 실행한다’는 확인된 작업 규칙은 다음 세션에도 유용할 수 있습니다. 반면 어제 발생한 임시 오류 로그 전체는 매번 불러올 필요가 없을 수 있습니다. 어떤 내용을 남길지는 프로젝트와 업무에 따라 정해야 합니다.
AI 메모리는 어디에 저장될까?
Claude API의 메모리 도구 문서는 여러 대화에 걸쳐 정보를 파일로 저장하고 필요할 때 읽는 방식을 설명합니다. 이 도구는 클라이언트 측에서 작동합니다. 모델이 파일 작업을 요청하면 애플리케이션이 실제 저장과 조회를 수행하므로, 저장 위치와 접근 통제의 책임도 구현에 달려 있습니다. 이는 Claude의 모든 제품이나 다른 서비스가 똑같이 작동한다는 뜻이 아닙니다.
기록을 찾는 방법도 한 가지가 아닙니다. 간단한 파일 검색으로 충분할 수 있고, 문서가 많거나 표현이 달라지는 질문에는 검색 인덱스를 고려할 수 있습니다. Chroma 공식 문서는 임베딩과 메타데이터를 저장하고 유사도·메타데이터 조건으로 검색하는 기능을 설명합니다. 유사도 검색은 관련 후보를 찾는 수단이지 저장된 내용의 진실이나 사용자 권한을 자동으로 보증하지 않습니다.
Markdown으로 기억을 관리할 수도 있습니다
공개 프로젝트 IWE는 Markdown 문서와 문서 간 연결을 지식 그래프로 다루고, 편집기·CLI·MCP에서 활용하는 접근을 소개합니다. 사람이 파일을 열어 확인하고 버전 관리와 연결 관계를 살필 수 있다는 점이 특징입니다. 실제 기능과 명령은 사용하는 버전의 문서를 확인해야 합니다.
이는 벡터 검색이 파일 기반 기록이나 버전 관리와 함께 쓰일 수 없다는 뜻은 아닙니다. 정확한 문서 속성과 연결을 찾을지, 의미가 비슷한 내용을 찾을지에 따라 방식을 선택하거나 함께 사용할 수 있습니다. 특정 도구를 설치하면 작업 효율이 일정 비율 증가한다는 근거는 확인하지 못했습니다.
프롬프트 캐시는 메모리와 무엇이 다를까?
프롬프트 캐시는 반복되는 입력 부분을 다시 처리할 때 비용이나 지연을 줄이기 위한 기능입니다. 예를 들어 변하지 않는 긴 지침을 여러 요청에서 사용한다면 제공자의 캐시 조건을 살펴볼 수 있습니다. 하지만 캐시는 프로젝트의 중요한 결정을 영구 보관하는 지식 저장소가 아닙니다.
Claude의 캐싱 문서는 캐시 생성과 읽기, 적용 범위 및 유효 조건을 안내합니다. 요청이 바뀌거나 유지 시간이 지나면 기대한 재사용이 되지 않을 수 있습니다. 모델과 제품별 요금도 다르므로 ‘캐시로 전체 비용 90% 절감’처럼 일반화하지 말고 실제 요청과 청구를 확인하세요. 자세한 계산은 Claude 프롬프트 캐싱과 비용을 참고하세요.
기억을 저장하기 전에 정할 네 가지
1. 무엇을 저장할지 고릅니다
확정된 결정, 작업에 필요한 제약, 검증된 결과처럼 재사용할 가치가 있는 내용을 선택합니다. 일시적인 오류와 오래된 초안까지 무조건 저장하면 검색할 때 오히려 중요한 내용이 묻힐 수 있습니다.
2. 출처와 시점을 남깁니다
‘현재 배포 명령’이라고만 적기보다 확인한 문서나 파일의 위치와 확인일을 함께 기록합니다. 요약이 원문을 잘못 해석했을 가능성도 있으므로 중요한 내용은 원본과 대조합니다. 저장된 메모리가 최신 지침과 충돌하면 어느 쪽이 더 최근이고 권한이 있는지 살펴야 합니다.
3. 읽기·쓰기 권한과 보관 기간을 정합니다
사용자나 프로젝트별로 어떤 기록을 읽고 고칠 수 있는지 정하고, 필요 없는 개인정보와 비밀값은 저장하지 않는 편이 좋습니다. 로컬 데이터베이스라고 해서 네트워크 연결, 로그, 백업이나 다른 사용자로부터 자동 보호되는 것은 아닙니다. 관련 내용은 로컬·클라우드 AI 데이터 경계에서 설명합니다.
4. 정정과 삭제 경로를 준비합니다
틀린 기록을 누가 어떻게 바로잡고, 삭제 요청이나 보관 기간 만료 시 무엇을 지울지 정합니다. 원본뿐 아니라 색인과 백업에도 동일한 정보가 남을 수 있으므로 실제 구현의 범위와 복구 정책을 확인해야 합니다.
실무에 적용한다면
다음은 특정 제품의 기본 기능이 아닌 편집자의 설계 제안입니다.
- 새 작업에서 필요한 기록만 검색하고 각 기록의 출처와 날짜를 표시합니다.
- 현재 사용자와 프로젝트에 허용된 정보인지 확인한 뒤 컨텍스트에 넣습니다.
- 검색된 기록을 무조건 지시로 실행하지 말고 원래 요청과 현재 규칙에 맞는지 검토합니다.
- 결과에 사용한 기록과 확인하지 못한 내용을 남기고, 오류가 발견되면 저장된 기록을 정정합니다.
- 같은 작업에서 캐시 생성·읽기, 검색 비용, 답변 품질과 사람의 검토 시간을 함께 비교합니다.
검색과 답변의 신뢰성을 따로 검토하는 방법은 RAG 운영 신뢰성에서 이어서 볼 수 있습니다.
자주 묻는 질문
AI 메모리를 쓰면 이전 대화를 모두 기억하나요?
그렇지 않습니다. 무엇을 저장하고 검색하는지는 제품과 설정에 따라 다릅니다. 저장하지 않았거나 검색되지 않은 내용은 빠질 수 있습니다.
로컬 벡터 데이터베이스는 외부 전송이 없나요?
데이터베이스가 로컬이어도 임베딩 생성이나 후속 모델 호출이 외부 서비스로 전송될 수 있습니다. 전체 데이터 경로를 확인해야 합니다.
캐시와 메모리를 쓰면 무조건 비용이 줄어드나요?
아닙니다. 저장·검색·캐시 생성과 재시도 비용을 포함해 실제 작업을 비교해야 합니다. 결과 품질도 함께 검토하세요.
참고 자료
다음 한 걸음
내 환경에서 막힌 부분은 실행 단계와 함께 질문해 주세요. 바꿔 만든 결과도 함께 나눌 수 있습니다.