"30분 뒤에 꺼줘"는 세션이 아니라 OS에 맡긴다 — 지연 실행용 durable 스케줄러

“30분 뒤에 꺼줘”는 세션이 아니라 OS에 맡긴다 — 지연 실행용 durable 스케줄러

“30분 뒤에 에어컨 꺼줘” 같은 지연 실행을 채팅 세션 안에서 처리하면 언젠가 반드시 조용히 사라진다. 실제로 그렇게 걸어둔 가전 끄기가 30분 뒤에 실행되지 않았고, 한참 지나 “아까 꺼달라고 한 거 껐어?”로 뒤늦게 드러난 적이 있다. 화면상으론 분명히 “알겠습니다”라고 답했는데도 말이다.

원인은 하나다. 미래 시점의 행동을 세션 생애주기에 묶어두면, 그 세션이 죽는 순간 예약도 같이 죽는다.

왜 세션 타이머는 못 믿나

지연 실행을 세션 안에서 구현하는 방법은 대개 두 가지인데 둘 다 약하다.

백그라운드 sleep (sleep 1800 && 명령) 이나 세션 내 웨이크업 타이머 — 세션을 정리(clear)하거나 컨텍스트가 꽉 차 재시작하거나 노드가 재부팅되면 그대로 소멸한다. 30분은 대부분의 자동 정리 주기보다 길어서, 거의 확실히 정리에 걸려 사라진다.
말로만 “알겠다”고 응답하고 실제 타이머는 아무것도 안 박은 경우 — 이건 티도 안 나게 드롭된다.

어느 쪽이든 뿌리는 같다. 세션은 언제 죽을지 모르는 휘발성 자원이고, 예약은 그 자원보다 오래 살아남아야 한다.

룰 — 지연·예약 행동은 OS 레벨 스케줄에 박는다

macOS라면 launchd, 리눅스라면 systemd-run --user --on-active=30min 같은 일회성 OS 타이머가 정석이다. 채팅 세션이 정리돼도, 컴퓨터만 켜져 있으면 목표 시각에 발사된다.

권장 형태는 이렇다.

지연/절대시각 + 대상  →  일회성 launchd job 등록
   목표 시각 도달  →  실제 명령 발사 + 사전/사후 알림 1통
       발사 완료  →  job 스스로 unload (일회성 보장, 가역)

핵심 설계 포인트 네 가지.

일회성 self-remove: 발사 후 job이 스스로 내려가야 “한 번만” 이 보장된다. 안 그러면 매일 같은 시각에 반복 발사되는 유령 스케줄이 된다.
사전·사후 알림: 외부에 영향을 주는 행동(가전, 발송)은 예약할 때 한 통, 실제 발사할 때 한 통을 남긴다. “예약됐다”와 “진짜 실행됐다”는 다른 사건이라 둘 다 보여야 한다.
발사 직전 상태 확인: 토글형 기기(에어컨·선풍기처럼 같은 신호로 켜고 끄는 것)는 발사 순간 상태를 읽어 “켜져 있을 때만 끈다”. 안 그러면 이미 꺼진 걸 다시 토글해 켜버린다.
발사 호스트는 24시간 켜진 기기: 항상 켜져 있고 대상 기기와 같은 네트워크에 있는 노드가 발사를 맡는다. 노트북처럼 자주 잠드는 기기에 예약을 박으면 그 시각에 자고 있을 수 있다.

이게 살아있다는 증거

실제로 이 패턴으로 박아둔 “30분 타이머 에어컨 OFF”는 세션과 무관하게 목표 시각(예: 00:52)에 launchd가 깨워 정확히 실행됐고, 실행 로그(toggled 1:True->False)와 사후 알림까지 남겼다. 그 사이 원래 세션은 이미 여러 번 정리됐지만 예약은 멀쩡히 살아남았다.

체크리스트

미래 시점에 뭔가 실행해야 할 때는 이 순서로 자문한다.

이 행동이 지금이 아니라 나중에 일어나야 하는가? 그렇다면 세션 타이머는 후보에서 제외한다.
그때까지 이 세션이 살아있다고 보장할 수 있는가? 거의 항상 “아니오”다.
OS 레벨 일회성 스케줄로 박았는가? 발사 후 스스로 내려가는가?
외부 영향 행동이면 예약·발사 각각 알림을 남기는가?
토글형이면 발사 직전 상태를 읽고 조건부로 실행하는가?

기억할 한 문장. 세션은 대화의 수명이고, 예약은 그보다 오래 살아야 한다. 수명이 다를 때는 더 오래 사는 쪽(OS)에 일을 맡긴다.