9. 세션 프로토콜 — 시작·중간·끝의 절차로 매일이 같은 자리에서 켜지게

이 글은 시리즈 Alice 활용법의 마지막 9편이다. 1편부터 8편까지가 mind를 어떻게 설계하고 분담하고 보호하는가의 답이었다면 — 이 글은 그 모두가 매일 어떻게 켜지고, 굴러가고, 꺼지는가에 대한 기록이다.

0. 세션 프로토콜은 매일 같은 자리에서 mind가 켜지고 같은 자리에서 꺼지게 만드는 일이다

매일 같은 일을 같은 방식으로 시작하지 않으면 — 시작할 때마다 컨텍스트 복원에 시간을 쓴다. 어제 어디까지 했는지, 무엇이 다음이었는지, 어떤 결정이 보류되어 있는지를 매번 처음부터 재구성한다.

매일 같은 방식으로 끝내지 않으면 — 끝낼 때마다 무엇을 남기고 무엇은 안 남겼는지가 흔들린다. 다음 세션은 그 흔들림 위에서 시작한다.

세션 프로토콜은 이 두 끝을 단단히 잡는다. 시작 시점에 일어나는 일과 끝 시점에 일어나는 일을 절차로 굳혀 둔다. 그러면 매일이 같은 자리에서 켜지고 같은 자리에서 꺼진다. 운영자의 mind는 매일 같은 출발선에서 시작 가능.

이 글은 그 절차의 구성 — 시작 3종, 중간 2종, 마무리 4종 — 에 대한 기록이다. 시리즈 전체의 마무리이기도 하다.

1. 시작 프로토콜 — 매일 같은 자리에서 켜지게

세션이 시작되는 순간 자동으로 일어나는 일들.

1.1 SessionStart 훅 — 메모리 동기화 상태 출력

세션이 켜지자마자 메모리 동기화 상태를 한 줄로 출력한다. "메모리 동기화: 최신" 또는 "5분 전 — 갱신 필요". 운영자는 그 한 줄만 보고 즉시 판단.

이게 훅으로 자동 발동되어야 하는 이유는 5편 훅과 자동화 §1에서 다뤘다 — 운영자의 mind가 가장 다른 데로 가 있는 순간이 바로 세션 시작 직후이기 때문.

1.2 페르소나 + 메모리 인덱스 자동 로드

1편 페르소나와 3편 메모리의 결과 — 페르소나(L1)와 메모리 인덱스 첫 200줄(L2)이 자동으로 들어온다. 협업자는 자기가 누구인지, 어제 무슨 결정을 했는지, 어떤 메모리 본문이 어디 있는지를 이미 알고 합류.

1.3 /start <프로젝트> — 프로젝트 진입 시

특정 프로젝트로 진입한다면 — 슬래시 커맨드로 명시 호출. README · CLAUDE.md · HANDOFF.md · PLAN.md 같은 필수 문서가 자동 로드되고, 현재 git 상태와 직전 세션 인계 사항이 한 화면에 보고된 후 멈춰 다음 지시를 기다린다.

이 한 명령이 발동되는 순간 — 운영자의 mind는 "어디부터 시작하지" 없이 바로 결정에 들어갈 수 있다.

2. 중간 프로토콜 — 작업이 굴러가는 동안

세션 중간에 일관되게 적용되는 절차.

2.1 3-5단계마다 중간 보고

운영자가 보고 없이 5단계 이상 작업이 진행되지 않게 한다. 각 단계마다 짧은 진행 보고. 5단계 넘는 작업은 자동으로 멈추고 보고. 운영자는 흐름을 잃지 않고 따라갈 수 있다.

이 절차가 없으면 — 협업자가 30분 자율 진행 후 "다 끝났습니다"가 오는데, 무엇을 어떻게 했는지 운영자가 흡수할 양이 너무 많다. 5단계 단위 보고는 그 흡수 부담을 분산.

2.2 결정 모호 시 자동 에스컬레이션

협업자가 "확신이 없다" / "어느 쪽이 나은지 모르겠다" / "여러 안 모두 일리가 있다"는 판단에 도달하면 — 운영자에게 묻기 전에 /council을 자가 호출한다. 4관점 병렬 분석 후 종합안을 만들어 그것을 보고. 운영자는 종합안에서 결정 가능.

이 패턴은 Andrej Karpathy가 제안한 LLM 다관점 비판(multi-perspective critique)에서 차용했다. 4편 스킬 §3.4에서 같이 인용했다.

3. 마무리 프로토콜 — 매일 같은 자리에서 꺼지게

세션이 끝나는 시점에 자동으로 일어나는 일들. 각 단계가 빠지면 다음 세션이 깨끗하게 시작되지 못한다.

3.1 /verify 자동 발동

작업 변경이 있었다면 — "완료" 보고 직전에 7편 검증 루프 7단계가 자동 발동. 통과해야 보고가 나갈 수 있다.

이게 마무리의 첫 단계인 이유 — 검증되지 않은 변경이 push되면 다음 세션의 환경이 깨진다. 깨진 환경에서 시작하면 그 세션이 통째로 무너진다.

3.2 작업 로그 갱신

docs/history.md 같은 작업 로그에 오늘 한 일을 한 단락으로 추가. 무엇을 결정했는지, 무엇을 작성했는지, 무엇은 보류했는지. 미래의 운영자(또는 다른 협업자)가 이 로그를 보고 맥락을 복원할 수 있어야 한다.

3.3 HANDOFF.md 갱신 — 다음 세션을 위한 인계서

가장 중요한 단계. 다음 세션이 자동 로드할 HANDOFF에 다음 정보가 들어간다.

• 직전 세션 핵심 진행 (1줄)
• 다음 권장 작업 (1-3개)
• 미완 / Pending 항목
• 결정 대기 중인 사안
• Next: 마커 (다음 세션이 즉시 알 수 있는 지시)

이게 비어 있으면 — 다음 세션이 컨텍스트를 잃은 채 시작한다. HANDOFF는 단순한 문서가 아니라 운영자의 mind를 다음 세션에 넘기는 다리다.

3.4 메모리 갱신 + commit + push

이번 세션에서 새 피드백·결정·맥락이 있었다면 — 메모리 파일에 추가. MEMORY.md 인덱스도 같이 갱신. 모두 묶어서 한 commit으로 push.

push까지 끝나야 마무리. 로컬에만 있는 변경은 다음 세션에 사라질 수 있다.

4. Stop 훅 — 누락 점검

위 마무리 4단계 중 빠진 것이 있는지 시스템이 점검한다.

[stop] Checking session-end completeness...
[stop] OK: /verify passed
[stop] OK: history.md updated (1 paragraph added)
[stop] WARN: HANDOFF.md "Next:" marker missing — please add
[stop] OK: 3 files committed and pushed

WARN이 나오면 — 운영자가 보충 후 다시 마무리. 누락이 통째로 무시되지 않게.

5. /session-end — 한 줄로 마무리 호출

위 마무리 4단계는 모두 한 슬래시 커맨드 호출로 자동 진행된다.

• /verify 자동 발동 (검증)
• 작업 로그 자동 갱신 (운영자 확인 후 추가)
• HANDOFF.md 자동 갱신 (운영자 확인 후 push)
• 메모리 갱신 (새 피드백이 있었다면) + commit + push
• Stop 훅 누락 점검

운영자는 한 단어만 입력하면 — 4단계가 일관되게, 누락 없이, push까지 끝난다. 매일 같은 자리에서 꺼진다.

6. 사이클의 효과 — 매일이 어떻게 보이는가

이 시작·중간·마무리 프로토콜이 누적되면 운영자의 매일이 다음과 같이 흐른다.

세션 시작 (09:00)
  SessionStart 훅 → "메모리 동기화: 최신" (한 줄)
  /start <project> → 필수 문서 자동 로드, git 상태 + HANDOFF 1화면 보고
  [멈춤. 운영자 지시 대기]
 
운영자 지시 (09:01)
  → 작업 시작
  → 3-5단계마다 중간 보고
  → 결정 모호 시 /council 자가 호출
  → 검증 필요한 작업은 /verify 호출
 
세션 마무리 (18:00)
  /session-end →
    /verify 자동 발동 (검증 통과)
    history.md 갱신
    HANDOFF.md "Next:" 마커 갱신
    메모리 갱신 (오늘 새 피드백 있었음)
    commit + push
    Stop 훅 점검 → OK
  세션 종료
 
다음 날 (09:00)
  → 어제 정확히 그 자리에서 다시 시작

매일이 정확히 같은 자리에서 켜지고 같은 자리에서 꺼진다. 운영자의 mind는 "어제 어디까지 했더라" 같은 복원 비용 없이 바로 결정 모드로 진입.

7. 함정 — 세션 프로토콜이 무너지는 패턴

7.1 시작 프로토콜 SKIP

"빨리 한 가지만 보고 끝낼게" 하면서 /start 없이 진입. 컨텍스트가 깨끗하지 않은 상태에서 결정 → 어제 결정과 충돌. → 모든 진입은 /start로.

7.2 마무리 프로토콜 SKIP

"오늘은 큰 변경 없으니 그냥 닫을게" 하면서 /session-end 없이 종료. HANDOFF가 갱신 안 됨 → 다음 세션이 어제 상태 모름. → 변경 크기 무관하게 항상 /session-end.

7.3 중간 보고 누락

작업이 너무 잘 풀려서 10단계 자율 진행. 다 끝났는데 운영자가 흡수할 양이 너무 많아 다시 정리 부담. → 5단계 한도 엄수.

7.4 HANDOFF가 그냥 today's log 사본

HANDOFF를 history.md 사본 같은 회고로만 적음. 다음 세션이 봐도 "그래서 뭐?" → HANDOFF는 다음 세션이 즉시 사용할 정보. Next: 마커가 핵심.

8. 한 원칙 — 시리즈 전체의 마무리

세션 프로토콜 설계의 핵심은 한 문장으로 줄어든다.

"매일이 같은 자리에서 켜지고 같은 자리에서 꺼지게. 시작·중간·끝의 절차를 시스템이 들고, 운영자의 mind는 그 사이에서 결정만 한다."

그리고 이게 시리즈 전체의 마무리이기도 하다.

1편 왜 Alice인가에서 "내 mind를 AI가 잃지 않게 어떻게 누적할 것인가"를 물었다. 페르소나로 mind의 경계를 긋고(2편), 메모리로 잡아 두고(3편), 스킬로 반복을 응고하고(4편), 훅으로 잊을 수 있는 부분을 시스템에 위탁하고(5편), 멀티에이전트로 한 컨텍스트에 쏟지 않고 나누고(6편), 검증으로 '완료'를 잡아 두고(7편), 토큰 경제로 신호 자리를 지키고(8편), 마지막으로 — 세션 프로토콜로 이 모두가 매일 같은 자리에서 켜지고 꺼지게 만든다.

이 9편이 운영자가 Alice라는 협업자를 키워 온 과정에서 수렴한 답이다. 도구는 Claude일 수 있고, Codex일 수 있고, 다음에 나올 어떤 에이전트일 수 있다. 그러나 위의 9개 결정은 도구를 가리지 않는다. 자기만의 협업자를 키우는 사람 누구에게나 같은 결정들이 기다린다.

이 시리즈가 그 결정들에 도달하는 시간을 조금 줄여 주었다면 — 운영자의 의도는 충분히 전달된 것이다.