Anthropic은 2026년 11월 6일, AI 에이전트가 작업 과정에서 얻은 지식을 다음 세션으로 넘겨주는 메커니즘에 대해 기술 설명 자료인 'The components of agent memory'를 공개했습니다. 이 자료는 대화 기록, 여기서 생성하는 메모, 그리고 나중에 다시 읽고 수정하는 처리 과정을 분리하여 설명하고 있습니다.
Anthropic의 기술 설명 자료
개발 과정에서도 조사에 많은 시간을 들여 알아낸 내용을 다음 작업으로 인계하고 싶은 경우가 있습니다. 하지만 단순히 '이 에러는 Redis가 원인'이라고만 남겨두면, 다른 원인으로 같은 에러가 발생했을 때도 그 메모를 바탕으로 조사를 진행해 버릴 위험이 있습니다.
이번 글에서는 공식 설명 자료의 관점을 토대로 Claude Code에 남길 메모를 재검토해 봅니다. 이 연구 기사는 Claude Code에 새로운 자동 정리 기능이 추가되었다는 공지사항으로 취급해서는 안 됩니다. 아래 개발 예시와 요청 문구는 필자가 설명을 위해 구성한 것이며, 실제 측정하여 효과를 확인한 사례가 아닙니다.
Anthropic의 설명 자료에서는 검증되지 않은 추측이 흩어져 있는 메모와, 확인된 사실이나 근거를 정리한 메모의 차이를 소개하고 있습니다. 또한, 메모는 처음부터 틀릴 수도 있고, 환경 변화로 인해 오래될 수도 있기 때문에, 원래 기록으로 돌아가 수정하는 사고방식을 제시합니다.
메모 검증과 수정에 대하여
예를 들어, 로컬 브라우저 테스트에서 로그인 실패를 경험했고, Redis를 실행하니 통하게 되었다고 가정해 봅시다. 다음 메모만으로는 어디까지 조사했는지 알 수 없습니다.
로그인 테스트가 실패하면 Redis를 실행한다.
이런 경우라면 다음과 같이 남길 수 있습니다. 파일명이나 테스트명은 가상의 것입니다.
로컬 로그인 E2E(End-to-End) 조사 메모
확인한 사항:
- tests/e2e/login.spec.ts는 로그인 후 세션 저장까지 확인한다.
...
'Redis를 실행하니 해결되었다'라는 결과에, 어떤 처리를 했고 적용할 수 있는 조건을 함께 적었습니다. 이렇게 하면 다음 세션에서 처음부터 로그인 처리 전체를 다시 조사해야 할지, 아니면 연결처 확인부터 시작해야 할지를 판단하는 자료가 됩니다.
비밀번호나 연결 URL의 실제 값은 쓰지 않고, 확인해야 할 설정명이나 코드의 위치만 남기는 것이 좋습니다.
'현재 브랜치 이름', '테스트는 모두 성공', 'PR(Pull Request)은 리뷰 대기 중'과 같은 정보는 다음에 작업을 할 때 이미 바뀌어 있을 수 있습니다. 이런 상태 정보를 오래 사용하는 메모에 섞으면, 과거의 결과를 현재의 상태로 오해할 원인이 됩니다.
메모에 남길 내용을 고를 때는 다음 차이점을 의식하는 것이 좋습니다. 이는 개발 작업용 정리 예시입니다.
| 남기고 싶은 정보 | 다음 작업으로 전달할 형태 |
|---|
| 테스트가 성공했다 | 필요한 경우 확인한 커밋과 실행 조건을 작업 기록에 남기고, 다음 번의 성공은 재확인한다 |
| ... | |
바로 조사할 수 있는 상태를 대량으로 복사하는 것보다, '왜 그렇게 판단했는지'가 있으면 구현을 변경해도 되는지 생각할 때도 사용될 수 있습니다.
Claude Code 공식 문서에서는 사람이 지속적인 지시를 작성하는 CLAUDE.md와 Claude가 수정이나 선호도를 기록하는 auto memory를 분리하고 있습니다. 둘 다 모델이 참조하는 컨텍스트이며, 강제로 실행을 제어하는 설정은 아닙니다. Claude Code의 메모 메커니즘
예를 들어 '인증 방식을 변경했을 때는 로그인/로그아웃 E2E 테스트를 확인한다'는 팀에서 합의된 방침은 공유할 CLAUDE.md 후보가 될 수 있습니다. 반면, 이번 조사에서 알게 된 주의점은 먼저 메모로 정리하고, 모두에게 적용하는 규칙으로 확장해도 좋을지 별도로 판단해야 합니다.
터미널 버전 Claude Code에서는 세션 내에서 /memory를 열면 지시 파일이나 메모의 위치를 확인할 수 있습니다. auto memory 폴더를 열어 무엇이 저장되어 있는지 살펴보세요. 팀과 공유할 목적이라면, 개인 메모에만 저장했다고 해서 공유가 된 것으로 간주하지 말고, 공유 대상 파일과 차이점도 확인해야 합니다. 공식적인 메모 확인 절차
조사가 끝난 후 Claude에게 정리를 요청하고 싶다면, 예를 들어 다음의 요청 문구를 사용할 수 있습니다.
이번 조사 내용을 바탕으로 다음 세션에서도 유용할 만한 것을 정리해 주세요.
우선 저장하지 말고, 메모 후보를 보여주세요.
확인된 것은 근거 코드나 검증 조건과 연결하고, 가설과 구분해 주세요.
...
후보를 읽어본 후에 저장 위치를 지정합니다. CLAUDE.md에 추가되기를 원한다면, 해당 파일명을 명시하는 것이 의도를 전달하는 데 도움이 됩니다.
저장만 된 것뿐 아니라, 다음 작업에서 참조할 수 있을지까지 확인해 보는 것도 좋습니다. 앞서의 예시라면, 새로운 세션에서 다음과 같이 요청할 수 있습니다.
이 프로젝트에서 로그인 E2E가 실패했을 경우의 조사 절차를 제안해 주세요.
관련된 메모와 현재 코드를 확인하고, 근거의 위치도 보여주세요. 아직 코드 변경이나 테스트 실행은 하지 마세요.
메모를 근거로 삼아 현재 구현을 확인하고, “Redis 연결 오류의 경우”라는 조건을 유지하고 있는지 살펴봅니다. 과거 테스트 성공을 현재의 성공으로 답하거나, 모든 로그인 실패를 Redis 탓으로 돌린다면, 메모 표현을 수정할 여지가 있습니다.
이것은 응답을 한 번 확인하기 위한 예시일 뿐이며, 이후의 동작을 보장하는 것은 아닙니다. 실제 수정에 들어갈 때는 그 시점의 에러와 테스트 결과로 판단해 주세요.
우선 최근 조사 메모 하나를 열어보면서, “무엇을 근거로 했는지”, “언제 재검토해야 하는지”가 읽히는지 확인해 보세요. 조사를 다시 할 필요가 없는 정보를 남기면서도, 다음 작업에서 다시 확인할 부분이 명확하게 보이는 메모를 만들어 두는 것이 좋습니다.
