(자주 있는 일) 세션이 사라져서 스마트폰으로 작업할 수 없다

Claude Code에 긴 태스크를 던져두고 자리를 비운다. 소파에서 스마트폰을 열어 계속 확인하려고 하면, 세션이 오프라인 상태가 되어 있다.

리모트 컨트롤 (/remote-control)을 사용하는 사람이라면 아마 한 번쯤은 경험했을 것이다.

손에 든 기기에서 돌아가고 있는 세션을 스마트폰이나 claude.ai/code에서 조작할 수 있는 기능이지만, 이것이 종종 아무 말 없이 끊길 때가 있다.

가장 간단한 복구 방법은 공식 문서에도 나와 있듯이 "기기로 돌아가서 /remote-control을 다시 입력하는 것"이다. 자리를 비우기 위한 기능인데, 복구하려면 다시 자리로 돌아와야 한다.

재연결을 시도하는 시간은 31초뿐

왜 끊기는가. 어느 정도의 시간 동안 끊기는가. Claude에게 실측을 요청해 보았다.

macOS 15 / Claude Code 2.1.220 환경에서, 리모트 컨트롤 연결 중에 Wi-Fi를 껐다가 다시 켜는 실험을 반복했다.

경계는 약 10회의 시도 끝에 일관되게 20~45초 사이에서 나타났다. 리모트 컨트롤의 자동 재연결은 30초 전후로 완전히 중단된다. 노트북을 닫고 방을 이동하거나, Wi-Fi에서 LTE로 전환되거나, 엘리베이터를 타는 등의 행동은 모두 이 허용 범위를 가볍게 초과한다.

고장 형태는 두 가지가 있다

관찰해 보니, 고장 모드는 두 가지로 나뉜다.

• 포기형: 푸터(Footer)의 /rc 인디케이터가 사라지고, Remote Control disconnected 알림이 뜬다. 연결이 명시적으로 닫힌 상태다.
• 고착형: /rc reconnecting 표시가 나타난 채로 영원히 움직이지 않는다. 40분을 방치해도 돌아오지 않는다.

고착형은 anthropics/claude-code#34255로 보고되어 있으며, 2026년 3월부터 open, 👍 100건, 미수정 상태이다.

중요한 점은, 어느 경우든 수동으로 /remote-control을 입력하면 즉시 재연결된다는 것이다.

그렇다면 자동으로 입력하면 된다... 하지만 경로가 없다

"끊기면 자동으로 /remote-control을 입력한다"는 이야기처럼 보인다. 하지만 이것이 순순히 되지 않는다.

• 실행 중인 Claude Code의 TUI에 외부 프로세스로부터 입력을 보낼 수단이 없다. 표준 입력(Standard Input)은 터미널에 연결되어 있어 외부에서 쓸 수 없다.
• 프로세스 재시작은 해결책이 되지 않는다. 재시작하면 대화가 종료된다.
• 재시도 횟수는 바이너리 내의 상수이며, 설정이나 환경 변수로 변경할 수 없다.

외부에서 살아있는 세션에 개입할 수 있는 경로는 실질적으로 하나뿐이다. tmux의 페인(Pane)에 키를 보내는 것(tmux send-keys)이다. 즉, 간단하게 Claude Code를 tmux 안에서 실행해 두어야 한다.

tmux로 Claude Code를 운용해 보기

tmux를 통한 운용에는 리모트 컨트롤과 무관한 장점도 있다. 터미널을 닫아도 세션이 살아있고, 다른 단말기에서 어태치(Attach)할 수 있다는 점 등이다.

다만 순수한 claude를 tmux로 감싸면 claude update나 claude -p까지 tmux에 먹혀버려 불편하므로, **대화형 실행만을 감싸는 쉘 함수(Shell Function)**를 사용하고 있다.

cc() {
local a
for a in "$@"; do
...

포인트는 세 가지다.

• 서브 커맨드와 플래그는 그대로 통과시키므로, cc update도 cc -p "..."도 이전과 동일하게 작동한다.
• 세션 이름에 전체 경로의 해시(Hash)를 포함하므로, 동일한 이름의 디렉토리를 가진 프로젝트가 충돌하지 않는다.
• claude가 종료되어 tmux 세션만 남아 있는 경우, 어태치하기 전에 claude --continue를 보내 대화를 복구한다.

함께 ~/.tmux.conf에 다음 설정도 필요하다. 이것이 없으면 tmux 안에서 Shift+Enter와 데스크톱 알림이 깨진다(공식 안내).

set -g allow-passthrough on
set -s extended-keys on
set -as terminal-features 'xterm*:extkeys'

Ctrl+B 충돌은 걱정할 필요 없습니다. Claude Code가 tmux를 감지하여 자신의 단축키를 Ctrl+B Ctrl+B로 해석해 줍니다.

자동으로 연결해 주는 도구를 제작하여 공개했습니다

이 정도 준비가 되었다면, 남은 것은 "tmux의 페인(pane)을 감시하다가, 리모트 컨트롤(remote control)이 끊긴 페인에 /remote-control을 입력하는" 프로그램을 작성하는 것입니다. 이를 cckeep이라는 이름으로 공개했습니다.

npm install -g cckeep
cckeep enable # launchd(macOS)/ systemd user timer(Linux)에 15초 간격으로 등록

"입력하는 것"이 아니라 "입력하지 않는 것"

타이머를 이용해 사람의 터미널에 문자를 입력하는 도구는 타이밍을 잘못 맞추면 흉기가 될 수 있습니다. 권한 프롬프트(permission prompt)를 멋대로 승인하거나, 대화 내용에 문자열을 혼입시킬 수 있기 때문입니다.

그래서 cckeep 코드의 대부분은 "입력하지 않을 조건"으로 구성되어 있습니다.

턴(turn) 실행 중에는 입력하지 않음. 페인을 3회 캡처하여 모두 동일할 때만 "정지" 상태로 판단
작성 중인 초안 위에는 입력하지 않음. Enter는 입력란의 내용까지 함께 전송해 버리므로, 입력란에 무언가 있다면 건너뜀
다이얼로그에는 입력하지 않음. 권한 프롬프트에서는 Enter가 "선택"이 되기 때문
한 번도 연결을 확인하지 않은 세션에는 관여하지 않음. 리모트 컨트롤을 사용하지 않는 주의를 가진 사람의 세션을 멋대로 켜지 않음
동일한 페인에는 5분에 한 번까지만. 락(lock)을 통해 다중 실행도 방지

가장 좋은 결말은 이것이 필요 없어지는 것

cckeep가 하고 있는 것은 응급처치입니다.

본래는 Claude Code 측에서 재시도를 계속하거나, 비대화형(non-interactive)으로 재연결을 호출하는 수단(--restart와 같은)을 마련해야 하며, 여러 이슈(issue)에 해당 요구사항과 실측 데이터가 올라와 있습니다.

공식적으로 대응될 때까지, 비슷한 문제를 겪고 계신 분이 있다면 꼭 한 번 사용해 보세요!

Discussion