🦞 07. 세션 토큰 운영

Quota를 아끼는 핵심은 모델 자체보다 세션 운영 방식입니다. 이 문서는 Quota 리셋 시점에 맞춰 /reset을 어떻게 쓰고, 무거운 작업을 cron/sub-agent로 어떻게 분리해야 비용·속도·품질을 동시에 잡을 수 있는지 실무 기준으로 정리합니다.

같은 일을 해도 main 세션에 모든 실행을 몰아넣으면 대화 길이가 급격히 늘고, 결국 재작업과 실패 분석 비용이 커집니다. 반대로 main=판단, isolated=실행 구조를 먼저 잡아두면 리셋 이후에도 흐름이 훨씬 안정적으로 이어집니다.

안내: 본문은 생성형 AI를 활용해 초안을 작성했고, OpenClaw 공식 문서와 실제 운영 적용 사례를 교차 확인해 정리했습니다.

핵심 요약

• /reset은 대화를 끊는 기능이 아니라, 토큰 급증을 막는 운영 밸브로 봐야 합니다.
• 오래 걸리는 실행은 main에서 분리해 isolated cron/sub-agent로 보내야 실패가 격리됩니다.
• 자동 리셋은 **스냅샷 저장 + 복원 기준(3줄 요약)**을 같이 둘 때만 안전하게 굴러갑니다.

flowchart LR
A[요청 분류] --> B{무거운 장기작업?}
B -->|Yes| C[isolated cron/sub-agent 분산]
B -->|No| D[main 세션 처리]
C --> E[결과 요약만 main 보고]
D --> E
E --> F[세션 idle/daily reset]
F --> G[reset snapshot/rollover snapshot 저장]
G --> H[다음 세션 경량 복원]

🧠 칠판 치트시트

• main은 의사결정, 무거운 실행은 isolated로 분리
• /reset 자동화는 스냅샷 없으면 위험하다
• 크론은 정확한 시간 작업, heartbeat는 배치 점검
• 병렬은 속도보다 “대기시간 단축 + 실패 격리” 효과가 크다
• 리셋 후에는 항상 핵심 맥락 3줄을 먼저 확인한다

어제 적용한 운영 구성 (/reset 자동화 + 분산 실행)

현재 운영에는 아래 3축이 들어가 있습니다.

1. B-lite 세션 리셋 정책

• direct: idle 360분
• group: idle 180분
• thread: daily 04:00
• telegram 채널 정책 적용

2. 리셋 전후 맥락 스냅샷 훅

• 수동 /new//reset: reset-snapshot 저장
• 자동 idle/daily rollover: auto-rollover-snapshot 저장
• 목적: 세션을 가볍게 바꿔도 핵심 맥락은 이어가기

3. 업무 분산(크론 + 서브에이전트 + 병렬)

• 정시 작업은 cron isolated 세션으로 분리
• 결과만 main에 보고
• 코딩/리서치/검증 병렬 실행으로 대기시간 최소화

이렇게 운영할 때의 장점

1) 토큰 사용량이 완만해진다

긴 대화 히스토리를 계속 물고 가지 않으니, 같은 작업량에서도 세션당 비용이 안정됩니다. 특히 반복 점검/리포트 작업에서 효과가 큽니다.

2) 실패가 main 세션을 오염시키지 않는다

isolated 실행에서 에러가 나도 main 대화는 깔끔하게 유지됩니다. 운영자는 요약만 보고 재실행 여부를 결정하면 됩니다.

3) 처리량보다 “체감 속도”가 빨라진다

병렬 분산은 총 연산량을 줄이기보다, 사람이 기다리는 시간을 줄여줍니다. 실제 협업 체감은 여기서 크게 올라갑니다.

유의점 (실무에서 자주 놓치는 포인트)

1) 스냅샷 품질이 낮으면 오히려 맥락 오염

요약이 부정확하면 잘못된 전제가 다음 세션으로 전파됩니다. 스냅샷은 짧게, 사실 중심으로 유지해야 합니다.

2) 인증 세션 만료 이슈

NotebookLM/YouTube 같은 외부 인증 작업은 isolated 세션에서 만료가 더 자주 드러납니다. auth_required를 정상 상태로 받아들이고 재인증 루틴을 미리 둬야 합니다.

3) timeout은 구조 문제일 가능성이 크다

한 잡에 패키징+업로드+검증을 모두 넣으면 타임아웃이 납니다. 단계를 쪼개거나 timeout을 올리고 재시도를 분리하세요.

4) 분산만 하고 통합 리포트를 안 남기면 관리 난이도 상승

분산 실행 뒤에는 반드시 main 기준의 한 장 요약(성공/실패/다음 조치)을 남겨야 운영 피로가 줄어듭니다.

미니 사례 2가지

사례 A) 팟캐스트 잡 타임아웃 복구

기존에는 단일 잡이 길어져 timeout이 반복됐습니다. 패키징/업로드를 분리하고 재시도(30/90/180) 정책을 넣자 실패 분석이 쉬워지고 성공률이 올라갔습니다.

사례 B) 성장 루프 자동화

collect → plan → NotebookLM enrich를 isolated 일일 루프로 분리한 뒤, main 대화는 의사결정에만 쓰게 되어 운영 부담이 낮아졌습니다.

리셋 직후 3분 실행 루틴

Quota 리셋 알림을 받으면 아래 3가지만 먼저 처리하면 됩니다.

1. /status에서 현재 세션 상태와 오늘 예정된 cron 실패 유무를 확인합니다.
2. 방금 시작할 무거운 작업 1건을 main에서 빼고 isolated 실행으로 등록합니다.
3. main에는 실행 원문 대신 목표/완료조건/보고형식 3줄만 남겨 다음 턴 비용을 줄입니다.

이 3단계를 먼저 고정하면, 리셋 직후의 “다시 길어지는 대화”를 막고 하루 전체 토큰 사용량을 안정적으로 관리할 수 있습니다.

체크리스트

• main 세션은 의사결정/요약 중심으로 유지되는가
• 무거운 작업이 isolated cron/sub-agent로 분리됐는가
• /reset 자동화에 스냅샷 훅이 함께 적용됐는가
• 실패 보고가 “원인 1줄 + 다음 조치 1줄”로 정리되는가
• timeout/인증 만료를 운영 시나리오로 이미 반영했는가

관련 문서

• ← 06. Cron Job
• 25. 크론 서브에이전트 분산운영
• → 08. 육성매뉴얼