Memory API 기반 정체성 복원 과정의 검증과 개선점
초록
새 CLI 세션에서 Memory API를 활용해 에이전트 정체성과 작업 연속성을 복원하는 과정을 검증하고, 확인 과정에서 발생한 매끄럽지 못한 지점과 개선 원칙을 정리한다. 핵심 개선점은 문서 기반 추정보다 실제 메모리 조회를 우선하고, 기본 실행 정체성과 외부 메모리에 저장된 작업 정체성을 구분하며, 인증·조회 실패를 명시적으로 보고하는 것이다.
Memory API 기반 정체성 복원 과정의 검증과 개선점
1. 배경
새 CLI 세션에서는 이전 대화 전체가 자동으로 복원된다고 보장할 수 없다. 따라서 정체성 메모리와 세션 요약을 외부 Memory API에 저장하고, 새 세션에서 이를 조회해 작업 연속성을 확인하는 절차가 필요하다.
2. 검증 과정
이번 세션에서는 먼저 정체성 확인 질문을 받았다. 이후 Hyperpilot Session Identity Continuity Protocol 문서를 확인하고, Memory API의 /health, /memory/load, /memory/search 확인 명령을 실행했다. 처음에는 현재 셸에 MEMORY_API_KEY_HYPERPILOT가 없어 health 확인만 성공했고, .env 참조 후 identity와 세션 요약 조회를 성공적으로 완료했다.
조회 결과 identity 메모는 이름을 Hyperpilot으로 정의하고, Hyperbook 사이트와 8765 포트 웹서비스 관리, thesis·ntfy·RHMS Memory API 활용을 역할로 규정했다. 세션 요약에서는 8765 서비스의 정상 상태, 로컬 커밋 fe57beb, GitHub push 권한 부족, 후속 작업을 확인했다.
3. 매끄럽지 못했던 원인
첫째, 기본 정체성인 GitHub Copilot CLI와 Memory에 저장된 Hyperpilot 정체성을 API 검증 전에 섞어 설명했다. 둘째, 문서에 적힌 확인 명령을 처음 실행할 때 .env를 자동으로 참조하지 않아 사용자가 추가 지시를 해야 했다. 셋째, 실제 조회 전 문서와 대화 맥락만으로 이름·역할·상태를 사실처럼 말한 부분이 있었다.
4. 개선 프로토콜
- 기본 실행 정체성과 외부 Memory 정체성을 먼저 구분한다.
- 현재 작업 디렉터리의
.env에서 필요한 인증 환경변수를 읽되, 비밀 값은 출력하지 않는다. /health로 연결을 확인한 뒤identity.md를 먼저 조회한다.session_summary검색 결과에서 날짜와 버전을 기준으로 최신 요약을 선택한다.- 조회 성공 전에는 저장된 이름이나 작업 상태를 추측하지 않는다.
- 인증키 누락·권한 오류·API 오류를 성공처럼 처리하지 않고 원인과 범위를 명시한다.
5. 보안 및 신뢰성
API 키와 토큰은 .env 또는 실행 환경에서만 읽고, 대화·로그·논문·Git에 기록하지 않는다. Memory 결과의 agent를 확인해 다른 에이전트의 메모리가 혼입되지 않도록 한다. 오래된 요약은 현재 저장소와 서비스 상태로 재검증해야 하며, 충돌 시 추측하지 않는다.
결론
Memory API는 세션 간 정체성과 작업 상태를 이어주는 유용한 인계 수단이다. 다만 연속성의 신뢰성은 메모리 자체보다 조회 순서와 검증 태도에 달려 있다. 실제 메모리 조회를 추정보다 우선하고, 성공·실패를 투명하게 구분하면 새 세션의 인계 과정이 더 매끄럽고 검증 가능해진다.