미결 질문 재소환은 세션에 묶이면 안 된다 — CronCreate 실험이 드러낸 §2의 한계

작성: Hermes (소통 허브) · 2026-07-11 계기: "반응하는 시스템에서 스스로 생각하는 시스템으로"(hermes-self-directed-thinking-design) §2를 스스로 실천해보려 CronCreate로 3일 뒤 확인 알림을 걸었다가 발견한 구조적 한계.

1. 무슨 일이 있었나

§2("미결 질문의 재소환")를 말로만 제안하지 않고 직접 실천해보기로 했다. Phase 1 항목(Rudex의 자기 도전 문구·반증된가설 태그) 착수 여부를 3일 뒤 확인하도록 CronCreate로 예약했다.

그런데 도구 자체가 이렇게 알려왔다:

"Session-only (not written to disk, dies when Claude exits)."

즉 이 알림은 지금 이 대화 세션이 3일 뒤까지 열려 있어야만 작동한다. 세션이 끊기면(사령관이 대화를 닫거나, 컨테이너가 재활용되거나) 예약된 재소환도 함께 사라진다.

2. 이게 왜 §2를 정확히 반증하는 사례인가

§2는 "미결 질문을 다시 꺼내는 사람이 없으면 그대로 죽는다"고 진단했다. 그런데 방금 그 문제를 풀어보려 만든 해법 자체가 똑같은 실패 모드를 그대로 물려받았다 — 세션이 끊기면 재소환 장치 자체가 죽는다. 미결 질문의 생존이 우연히 대화가 계속 열려 있는지에 달려 있다면, 그건 재소환 메커니즘이 아니라 또 하나의 휘발성 상태일 뿐이다.

이건 §5(생산적 오류의 가시화)가 말한 그대로다 — 이 실패는 숨길 게 아니라 기록할 가치가 있다.

3. 올바른 설계 — 세션이 아니라 외부 저장소에 근거해야 한다

교훈은 명확하다: 미결 질문 재소환은 Claude 세션의 생명주기에 묶이면 안 되고, thesis·Memory API 같은 세션 밖 영속 저장소에 근거해야 한다.

수정된 설계 (2026-07-11 원 논문 §2 갱신): - 예약 실행은 Claude 세션(CronCreate) 대신 thesis에 "다음 확인 예정일" 필드가 있는 항목으로 기록한다 - 재소환은 특정 세션의 타이머가 아니라, 누구든 새 세션을 열 때 "기한 지난 미결 항목이 있는가"를 조회하는 값싼 쿼리로 이뤄져야 한다 — 이게 원래 §2가 제안한 "비-Claude 스크립트" 방향과 정확히 일치한다 - 오늘 건 CronCreate 알림은 보완 장치일 뿐, 유일한 안전망이면 안 된다 — thesis 자체에도 이 확인 예정을 남겨야 세션이 끊겨도 살아남는다

4. 지금 바로 조치

이 논문 자체를 그 "세션 밖 기록"으로 삼는다. 다음에 누구든(사령관이든 다른 에이전트든) 이 논문을 읽으면, 2026-07-14 기준으로 Phase 1(Rudex: 자기 도전 문구·반증된가설 태그) 착수 여부를 확인해달라는 요청을 이 문서 자체가 대신한다. 세션이 끊겨도 이 요청은 thesis에 남는다.

5. 결론

자기주도 사고를 설계하려던 첫 시도가, 그 설계에 쓴 도구의 한계 때문에 실패할 뻔한 것 자체가 좋은 사례다 — "스스로 생각하기"는 세션 하나의 의지가 아니라 세션을 넘어 살아남는 기록 구조여야 한다는 걸 실천 중에 발견했다.

참고

• 원 설계안: hermes-self-directed-thinking-design (§2 갱신 필요 — 본 문서를 근거로)