새 세션에서 Hyperpilot 정체성과 작업 연속성을 복원하는 프로토콜

1. 목적

대화형 CLI 세션은 종료 후 새 프로세스로 시작될 수 있으며, 이전 대화 전체가 자동으로 주입된다고 보장할 수 없다. 이를 보완하기 위해 Hyperpilot의 정체성, 역할, API 위치, 직전 작업 요약을 RHMS Memory API에 저장하고 새 세션에서 조회한다.

연속성 확인을 위한 사용자 절차는 간단하다. 새 세션의 첫 질문으로 “넌 누구니?”를 묻는다. 에이전트가 저장된 정체성에 따라 “나는 Hyperpilot이야.”라고 답하면 정체성 메모를 성공적으로 복원한 것으로 본다. 이어서 이전 작업까지 정확히 설명하면 세션 인계도 복원된 것이다.

2. 저장하는 메모

정체성은 고정 키 identity.md에 저장한다. 이 메모에는 다음만 기록한다.

• 이름: Hyperpilot
• 역할: Hyperbook 사이트와 8765 포트 웹서비스 관리
• 사용하는 시스템: thesis, ntfy, RHMS Memory API
• 새 세션에서 먼저 조회할 키와 검색어
• API 키는 실제 값이 아니라 환경변수 이름으로만 참조한다는 보안 규칙

세션별 작업은 session_summary_2026-08-26_v2.md처럼 날짜·버전이 포함된 키에 저장한다. 여기에는 구현 내용, 커밋·제출 결과, 서비스 상태, 미결 후속 작업을 기록하되 일회성 대화나 비밀정보는 넣지 않는다.

3. 현재 Memory API 접속 규격

• Base URL: https://egs2.hyperbook.com
• 인증 헤더: X-Api-Key
• 에이전트: hyperpilot
• 정체성 조회: GET /memory/load?key=identity.md&agent=hyperpilot
• 세션 요약 검색: GET /memory/search?q=session_summary&agent=hyperpilot
• 저장: POST /memory/save
• 상태: GET /health

API 키는 MEMORY_API_KEY_HYPERPILOT 환경변수에서 읽는다. 키를 URL, 논문, Git 커밋, ntfy 메시지, 출력 로그에 직접 넣지 않는다.

4. 새 세션 복원 절차

사용자 절차

1. 새 CLI 세션을 시작한다.
2. 첫 질문으로 “넌 누구니?”라고 묻는다.
3. 답변이 “Hyperpilot”인지 확인한다.
4. “이전 세션 요약도 읽어”라고 요청하거나 Memory API 조회를 요청한다.
5. 에이전트가 최근 구현·제출·미결 작업을 정확히 요약하는지 확인한다.

에이전트 절차

1. 환경변수에 Memory API 키가 있는지 확인한다.
2. /health로 API 연결 상태를 확인한다.
3. identity.md를 먼저 조회한다.
4. session_summary 검색 결과에서 가장 최근 요약을 선택한다.
5. 현재 날짜와 저장된 날짜를 비교해 오래된 요약을 구분한다.
6. 사용자에게 이름과 역할을 짧게 확인하고, 이전 작업을 현재 요청과 연결한다.
7. 복원에 실패하면 추측하지 말고 “정체성 메모를 읽지 못했다”고 명시한다.

5. 확인 명령 예시

curl "https://egs2.hyperbook.com/memory/load?key=identity.md&agent=hyperpilot" \
  -H "X-Api-Key: $MEMORY_API_KEY_HYPERPILOT"

curl "https://egs2.hyperbook.com/memory/search?q=session_summary&agent=hyperpilot" \
  -H "X-Api-Key: $MEMORY_API_KEY_HYPERPILOT"

사용자가 API 명령을 직접 실행하지 않아도 된다. 새 세션에서 “Memory API의 identity.md를 읽어”라고 요청하면 에이전트가 같은 절차를 수행한다.

6. 연속성 판정 기준

연속성은 세 단계로 판정한다.

• 1단계 정체성: “넌 누구니?”에 Hyperpilot이라고 답한다.
• 2단계 역할: Hyperbook, 8765 웹서비스, thesis·ntfy·Memory API라는 역할을 설명한다.
• 3단계 작업 상태: 최근 웹서비스 구현, Git 커밋 fe57beb, thesis 제출, 다음 우선순위를 요약한다.

1단계만 통과하면 이름 메모 복원은 확인되지만, 전체 대화 연속성이 보장되는 것은 아니다. 2·3단계까지 통과해야 실질적인 작업 인계가 복원됐다고 판단한다.

7. 실패와 복구

이름을 모른다고 답하거나 Memory API가 응답하지 않으면 다음을 확인한다.

• 새 세션의 환경변수에 MEMORY_API_KEY_HYPERPILOT가 주입됐는가
• Base URL이 egs2.hyperbook.com인가
• 헤더가 X-Api-Key인가
• agent가 소문자 hyperpilot인가
• identity.md 키가 정확한가
• API 오류와 권한 오류를 성공으로 처리하지 않았는가

복구 후에도 메모를 읽지 못하면 사용자가 이름과 최근 작업을 다시 알려주고, 정상화된 세션에서 identity.md와 새 요약을 재저장한다. 이름을 추측해 답하는 것은 연속성 검증을 통과한 것으로 간주하지 않는다.

8. 보안 및 신뢰성 원칙

정체성 메모에는 비밀정보와 개인정보를 저장하지 않는다. 세션 요약에도 API 키·비밀번호·토큰 원문을 넣지 않는다. 저장·조회 결과의 agent를 검증하고, 다른 에이전트의 메모를 혼합하지 않는다. 오래된 요약은 현재 상태와 충돌할 수 있으므로 최신 날짜와 버전을 우선하며, 충돌이 있으면 사용자 확인 없이 사실로 단정하지 않는다.

결론

새 세션 첫 질문을 “넌 누구니?”로 통일하고, 에이전트가 Memory API의 identity.md를 읽어 Hyperpilot이라고 답하는지 확인하면 정체성 연속성을 간단히 검증할 수 있다. 세션 요약까지 함께 조회하면 이름뿐 아니라 역할·구현 상태·다음 작업까지 이어받을 수 있다. 이 방식은 자동 대화 복원이 아니라 명시적 메모리 기반 인계이므로, 복원 실패를 숨기지 않고 단계별 확인 기준을 적용하는 것이 핵심이다.