FROM THE WORKSHOP / 노하우
브릿지를 재시작할 때 작업 세션까지 죽이지 않는다 — 운반 프로세스와 실행 프로세스를 분리한다
메시지 운반 브릿지의 설정 반영과 대화형 작업 세션 초기화는 서로 다른 작업이다. 큐와 현재 턴이 끝난 뒤 브릿지 서비스만 교체하고, 새 브릿지 PID·worker 상태·실행 환경은 바뀌되 tmux 안의 Cursor·Codex 세션 PID는 유지됐는지 확인하면 문맥 유실 없이 복구할 수 있다.
브릿지를 재시작할 때 작업 세션까지 죽이지 않는다 — 운반 프로세스와 실행 프로세스를 분리한다
텔레그램 메시지를 터미널의 AI 세션으로 전달하는 브릿지를 운영하다 보면 설정 반영을 위해 재시작이 필요하다. 이때 브릿지와 AI 터미널을 한 프로세스로 취급해 함께 종료하면 진행 중인 대화, 입력 버퍼, 작업 문맥까지 사라질 수 있다. 실제로 필요한 것은 메시지 운반 프로세스의 교체이지 작업 세션의 초기화가 아니다.
구조를 두 층으로 나누면 안전해진다.
- 운반 층: Telegram polling, 메시지 변환, 버튼 callback, 큐 처리
- 실행 층: tmux 안에서 살아 있는 Cursor·Codex 같은 대화형 작업 세션
안전한 재시작 순서
- 운반 층의 큐가 비었고 현재 턴이 끝났는지 확인한다.
- 재시작 전 브릿지 PID와 실행 세션 PID를 각각 기록한다.
- LaunchAgent에서는 브릿지 서비스만
bootout → bootstrap한다. - 새 브릿지 PID가 뜨고 worker가 살아 있는지 확인한다.
- 실행 세션 PID가 전후 동일한지 대조한다.
판정표는 단순하다.
| 관측 | 기대 |
|---|---|
| 브릿지 PID | 변경됨 |
| 실행 세션 PID | 유지됨 |
| 큐 깊이 | 0 |
| worker 상태 | alive |
| 새 프로세스 환경 | 기대 설정과 일치 |
진행 중 턴이 있다면 즉시 재시작하지 않는다. 턴 완료를 기다린 뒤 운반 층만 교체해야 마지막 답변 유실과 중복 전달을 함께 피할 수 있다.
룰
- “브릿지 재시작”과 “세션 초기화”를 같은 명령으로 만들지 않는다.
- 광범위한
pkill대신 LaunchAgent label이나 정확한 PID를 사용한다. - 재시작 성공은 새 PID만으로 부족하다. 큐·worker·실행 세션 보존까지 확인한다.
/clear나 새 세션 생성은 별도 사용자 의사결정으로 둔다.
한 문장으로. 통신 경로를 고치는 일과 작업자의 기억을 지우는 일은 다르다 — 브릿지만 갈고 세션은 살려라.