영속성 체인으로 세션 안정성 확보 — AI가 꺼지지 않게 만드는 4레이어

셀포지의 AI 사고 파트너 설리반은 Claude Code의 채널 모드로 텔레그램에 연결돼 있어요. CronCreate로 반복 스케줄을 등록해서 아침 브리핑, 점심 체크인, 자정 그래프 빌드 등을 자동 실행하는 구조예요.

문제는 CronCreate의 recurring=true 작업이 7일 후 자동 만료된다는 거예요. 아침 브리핑 크론 프롬프트에 “CronList를 확인하고 누락된 스케줄을 재등록하라”는 지시를 넣어뒀는데, 이 아침 브리핑 크론 자체가 만료되면 재등록 명령을 실행할 주체가 사라져요.

CronCreate(recurring=true) → 7일 후 만료
  → 크론 프롬프트에 "만료 시 재등록" 지시
    → 그 크론 자체가 만료되면?
      → 재등록 명령을 실행할 수 없음
        → 순환 의존 (deadlock)

이 순환 의존을 끊고, 재부팅과 장애까지 견디는 인프라를 만든 과정이에요.

영속성 문제를 3개 레이어로 분해했어요:

특히 세 번째 문제가 흥미로웠어요. 아침 브리핑 프롬프트에 “스케줄 만료되면 재등록해”를 넣어뒀지만, 그 아침 브리핑 cron 자체가 만료되면 재등록을 트리거할 주체가 없어요. 스스로를 살리는 구조는 자기 자신이 죽으면 작동하지 않아요.

4개 레이어를 각각 독립된 관심사로 분리했어요:

[launchd: com.hminn.sullivan-channel]
  → start.sh
    → tmux new-session -d -s sullivan-channel
    → tmux send-keys "claude --channels ..." Enter

[launchd: com.sullivan-channel.watchdog]  (5분 간격)
  → watchdog.sh
    → Telegram API pending_update_count 확인
    → 2회 연속 밀림 → 세션 재시작

[launchd: com.sullivan-channel.renew-schedule]  (5일 간격)
  → renew-schedule.sh
    → tmux send-keys로 재등록 명령 전송

launchd는 macOS의 시스템 프로세스 매니저예요. RunAtLoad: true로 부팅 시 자동 실행되고, KeepAlive 정책으로 프로세스 사망 시 재시작해요. 이 레이어가 순환 의존을 끊는 외부 트리거 역할을 해요 — CronCreate와 무관하게 OS 레벨에서 동작하니까요.

tmux는 터미널 멀티플렉서. tmux new-session -d + tmux send-keys 조합으로 백그라운드 세션을 생성하고 claude를 실행해요. 프로세스가 죽어도 tmux 세션(셸)은 유지돼서, watchdog가 같은 세션에 새 프로세스를 띄울 수 있어요.

watchdog는 5분마다 텔레그램 Bot API의 getUpdates로 pending_update_count를 확인해요. 2회 연속 밀려있으면 세션이 멈춘 것으로 판단하고, tmux 세션을 kill 후 재생성해요.

스케줄 갱신은 5일마다 launchd가 tmux에 send-keys로 재등록 프롬프트를 전송해요. CronCreate의 7일 만료 전에 갱신하는 구조. 세션은 끊기지 않고 Claude가 프롬프트를 받아 CronCreate를 다시 실행해요.

Sullivan의 크론 6개 중 3개에 하트비트 점검 로직을 넣었어요. 각 크론 프롬프트 파일의 첫 단계에서 CronList를 실행하고, 6개 작업명을 대조해요:

## 1단계: 스케줄 점검 (하트비트)
CronList를 실행해서 다음 6개가 모두 있는지 확인해:
- sullivan-아침브리핑, sullivan-점심체크인, sullivan-자기전회고,
  sullivan-주간회고, sullivan-월간체크, sullivan-graphify
누락된 것이 있으면 sullivan-scheduler.md를 읽고 해당 작업만 재등록해.

이 로직이 아침 브리핑(08:00), 점심 체크인(13:00), 자정 Graphify(00:00)에 각각 들어있어요. 핵심은 크론 프롬프트 파일을 참조하는 방식이에요. 실행 시 해당 .md 파일을 Read로 읽어서 지시를 따르는 구조라, 크론 동작을 변경하려면 파일만 수정하면 다음 발동 시 자동 반영돼요.

00:00  Graphify 크론   → CronList 점검 → 누락 시 재등록 → 그래프 빌드
08:00  아침 브리핑      → CronList 점검 → 누락 시 재등록 → 브리핑 생성
13:00  점심 체크인      → CronList 점검 → 누락 시 재등록 → 체크인 전송

7일(168시간) 만료에 대해 하루 3회 점검하면 최대 무점검 구간이 약 8시간이에요. 하루가 전체 만료 주기의 14.3%이고, 점검 포인트가 그 안에 3개 있으니 실질적으로 만료 전에 잡힐 확률이 매우 높아요.

실제 구현 과정에서 부딪힌 기술적 문제들이에요.

tmux 경로 문제

launchd plist에 /usr/bin/tmux로 적었는데, Homebrew 설치 경로는 /opt/homebrew/bin/tmux였어요. macOS에 tmux가 기본 포함되지 않으므로 exit code 78(EX_CONFIG)으로 조용히 실패했어요. launchd는 PATH를 최소한으로 설정하기 때문에 절대 경로가 필수예요.

tmux 세션 생성 방식

# 이렇게 하면 claude가 죽으면 세션도 사라짐
tmux new-session -d -s sullivan-channel "claude --channels ..."

# 이렇게 하면 claude가 죽어도 셸이 살아있음
tmux new-session -d -s sullivan-channel
tmux send-keys -t sullivan-channel "claude --channels ..." Enter

첫 번째 방식은 전달한 명령어가 세션의 유일한 프로세스가 돼서, 프로세스 종료 시 셸도 같이 종료되고 세션이 사라져요. 두 번째 방식은 bash 셸 위에서 명령어를 실행하는 형태라, 명령어가 실패해도 셸이 유지돼요.

--continue 플래그

처음에 claude --continue --channels ...로 이전 세션을 이어가려 했는데, 이어갈 세션이 없는 상황(최초 실행, 세션 초기화 후)에서 에러가 나서 제거했어요.

LaunchAgent 부팅 Race Condition

starter와 watchdog 모두 RunAtLoad: true로 설정하면 부팅 시 동시에 실행돼요:

부팅 → starter(RunAtLoad) + watchdog(RunAtLoad) 동시 실행
  → watchdog가 먼저 세션 생성
    → starter가 "duplicate session" 에러
      → starter가 exit 0으로 종료
        → KeepAlive.SuccessfulExit=false이므로 launchd가 재시작 안 함
          → 세션이 죽어도 즉시 복구 불가, watchdog 5분 대기

해결: watchdog에서 RunAtLoad: false로 변경 + starter의 exit code를 exit 1로 변경. 부팅 시에는 starter만 실행되고, 세션이 죽으면 launchd가 exit 1을 감지해 즉시 재시작해요.

텔레그램 MCP 환경변수 세정

이건 영속성 인프라 자체보다 채널 운영 과정에서 발견한 문제인데, 인프라와 밀접하게 연결돼 있어요.

Claude Code가 MCP 서버를 스폰할 때 환경변수를 세정(sanitize)해서 TELEGRAM_STATE_DIR이 자식 프로세스에 전달되지 않았어요. 세 채널(Sullivan, PM, 일반)이 같은 기본 봇 토큰으로 폴백하면서 409 Conflict가 발생하고, 결과적으로 하나만 살아남는 상황이었어요.

runner 스크립트: TELEGRAM_STATE_DIR=.../telegram-sullivan
  → 부모 claude 프로세스에는 env 존재
    → Claude Code가 MCP 스폰 시 env 세정
      → 자식 MCP 서버: TELEGRAM_STATE_DIR 없음
        → 세 채널이 기본 디렉토리로 폴백 → 409 Conflict

부모 프로세스 트리에서 ps eww로 환경변수를 찾아오는 브릿지 스크립트를 만들어 해결했어요. MCP의 .mcp.json에서 bun 직접 실행 대신 브릿지 스크립트를 경유하도록 변경한 거예요.

PM 채널(셀피)은 Sullivan과 독립된 launchd + tmux + watchdog 세트를 가지고 있어요. 크론 4개를 2중 하트비트로 관리해요:

Sullivan 6개 크론 + 셀피 4개 크론 = 총 10개 크론이 독립적으로 운영돼요. 각 채널이 자기 크론만 점검하고, 서로의 크론에 간섭하지 않아요. 이렇게 하면 한쪽 채널이 완전히 죽어도 다른 쪽은 영향받지 않아요.

크론 관리 원칙도 중요한데 — 모든 크론은 해당 채널 세션에서만 등록해요. 다른 세션에서 등록하면 채널 라우팅이 꼬이고, session-only로 등록돼서 세션 종료 시 사라지거든요.

정리하면 두 가지 설계 원칙이에요:

순환 의존은 외부 트리거로 끊는다. 자기 자신을 갱신하는 구조는 자기가 죽으면 작동하지 않아요. CronCreate 만료 → 재등록 cron도 만료 → 재등록 불가. 이 순환을 시스템 레벨(launchd)의 외부 트리거로 끊는 것이 가장 안정적이에요.

“언제든 깨질 수 있다”고 가정하고, 하루에 여러 번 점검한다. 7일 만료에 대해 하루 3회 점검하면 실질적인 위험 구간은 최대 8시간이에요. 완벽한 단일 보호보다 불완전하지만 반복되는 다중 점검이 더 안정적이에요.

이 글에서 다룬 것은 “시스템 인프라의 영속성”이에요. 1편: 항상 대화할 수 있는 환경 만들기에서 채널 모드 기반의 환경 구축을 다뤘고, 4편: 포착 - 회고 - 인사이트 루프에서 다룬 루프의 자동 실행이 바로 이 인프라 위에서 돌아가는 거예요.

고쳤습니다(안 고침)에서 다룬 것은 “검증 기록의 영속성” — 한 세션에서 확인한 결과가 다음 세션에서도 이어지는 문제예요. 같은 “영속성”이라는 단어를 쓰지만 스코프가 달라요. verified-fix는 파일 하나의 상태 유지, 이 글은 시스템 전체의 생존이에요.