18장. Remote Control과 Dispatch

컴퓨터 앞에 앉아 있을 때만 Claude Code를 쓰는 사람은, 이제 가장 빠른 빌더가 아니다. 진짜 차이는 모델 성능보다도 내가 자리를 비운 동안에도 일이 계속 굴러가게 만드는 구조에서 난다. 책상에서는 구현을 밀어붙이고, 이동 중에는 승인과 방향 수정만 하고, 외부 이벤트가 오면 세션이 먼저 반응하게 만드는 사람. 이런 사람이 혼자 일해도 팀처럼 움직인다.

이 장에서는 그 구조를 만든다. 핵심은 단순하다. 입력하는 곳과 실행되는 곳을 분리하라. 내가 휴대폰을 들고 있든, 브라우저를 열었든, 혹은 아예 아무것도 만지지 않고 있든, Claude Code가 돌아가는 기반이 살아 있으면 된다.

원격 실행은 네 가지로 나뉜다

Claude Code를 로컬 밖에서 움직이는 방법은 비슷해 보여도 성격이 완전히 다르다. 이 차이를 먼저 머리에 넣어두면, 괜히 망치로 나사를 돌리려는 실수를 줄일 수 있다.

Remote Control은 리모컨에 가깝다. 이미 켜져 있는 TV를 다른 방에서 조종하는 느낌이다. 반면 Dispatch는 일감 접수함에 가깝다. 지금 세션이 없어도, 휴대폰에서 "이거 해놔"라고 던지면 Desktop 쪽에서 세션이 생기고 일이 굴러간다. 공식 문서도 Remote Control과 Dispatch를 "터미널 앞에 없을 때 일하는 서로 다른 방식"으로 구분한다.¹

그리고 여기서 솔로 빌더에게 중요한 깨달음이 하나 있다. 내가 어디 있느냐보다, Claude가 어디서 돌고 있느냐가 더 중요하다.

Remote Control: 이미 돌아가는 세션을 어디서든 이어받기

Remote Control은 claude.ai/code나 Claude 모바일 앱을, 지금 내 컴퓨터에서 실행 중인 Claude Code 세션에 연결하는 기능이다. 중요한 점은 세션이 클라우드로 옮겨가는 게 아니라는 것이다. 실행은 계속 내 컴퓨터에서 일어나고, 웹과 모바일은 그 세션을 비추는 창 역할만 한다.¹

이 구조가 좋은 이유는 아주 현실적이다. 로컬 파일 시스템, MCP 서버, 프로젝트 설정, CLAUDE.md, 작업 중인 브랜치 상태가 그대로 유지된다. 즉, 아침에 터미널에서 시작한 긴 작업을 점심 먹으러 나가면서 휴대폰으로 이어볼 수 있다. 컨텍스트를 다시 설명할 필요가 없다.

실전에서 시작 방식은 세 가지다.

claude remote-control

이건 서버 모드다. 터미널은 연결 대기 상태가 되고, 다른 기기에서 붙을 URL과 QR 코드가 나온다.¹

claude --remote-control "My Project"

이 방식은 로컬 터미널에서도 계속 대화하고, 동시에 웹이나 모바일에서도 같은 세션을 조작하고 싶을 때 좋다.¹

이미 세션 안에 들어와 있다면 슬래시 명령으로 바꿀 수도 있다.

/remote-control

이 방식이 솔로 빌더에게 특히 강한 이유는 핸드오프 비용이 거의 0에 가깝기 때문이다. 회의 들어가기 10초 전에도 전환할 수 있고, 침대에 누워서도 승인만 해줄 수 있다. "작업을 중단하고 나중에 다시 시작한다"가 아니라, "작업은 계속 돌고 나는 인터페이스만 바꾼다"가 된다.

여기서 한 단계 더 나가면 서버 모드의 --spawn worktree가 재미있다. 원격에서 온디맨드 세션을 새로 만들 때 각각 별도 Git worktree를 쓰게 할 수 있다. 같은 저장소에서 여러 갈래 작업을 병렬로 굴릴 때 충돌을 줄이는 데 유용하다. 최대 동시 세션 수도 설정할 수 있다.¹ 혼자 일하지만, 사실상 "한 저장소 안의 여러 작업자"를 만들 수 있다는 뜻이다.

보안 모델도 솔로 빌더 관점에서는 꽤 중요하다. Remote Control은 내 컴퓨터에서 인바운드 포트를 열지 않는다. 로컬 프로세스가 Anthropic API로 아웃바운드 HTTPS 연결을 만들고, 원격 클라이언트와 로컬 세션 사이 메시지를 중계받는 방식이다. 트래픽은 TLS로 보호되고, 단기 자격 증명이 목적별로 나뉘어 사용된다.¹ 쉽게 말해, 집 공유기 포트 포워딩을 열어두고 기도하는 종류의 기능이 아니다.

다만 환상은 금물이다. 제약도 분명하다. 로컬 프로세스가 살아 있어야 하고, 터미널을 닫거나 컴퓨터가 오래 네트워크에서 끊기면 세션도 끝난다. 대화형 프로세스당 원격 세션은 하나이며, 일부 로컬 전용 명령은 모바일이나 웹에서 바로 쓰지 못한다.¹ 즉, Remote Control은 "어디서나 일하게 해주는 마법"이 아니라 내 로컬 환경을 원격에서 이어 쓰게 해주는 안전한 다리다.

Dispatch: 세션이 없을 때 휴대폰에서 일을 던져놓기

Remote Control의 한계는 분명하다. 이미 세션이 켜져 있어야 한다. 그런데 현실에서는 꼭 그렇지 않다. 버스를 탔는데 갑자기 떠오른 기능 아이디어가 있다. 외출 중인데 장애 알림이 왔다. 지금 당장 노트북을 열고 세션을 만들어놓은 상태가 아닐 수 있다.

여기서 Dispatch가 등장한다. Claude Desktop은 Dispatch 통합을 제공하며, 공식 비교표에서 Dispatch는 휴대폰에서 작업을 메시지로 보내면 Desktop이 세션을 생성해 처리하는 방식으로 설명된다.²¹

이 차이는 작아 보이지만, 워크플로우에서는 꽤 크다.

Remote Control이 "이미 돌아가는 주방에 들어가 불 조절하기"라면, Dispatch는 "밖에서 주문을 넣어두고 주방을 가동시키기"다. 그래서 Dispatch는 다음 같은 상황에서 진가가 난다.

• 밤에 떠오른 제품 아이디어를 잊기 전에 바로 작업으로 던지고 싶을 때

• 이동 중 버그 리포트를 보고, Desktop 쪽에 분석 세션을 생성해두고 싶을 때

• 내가 돌아오기 전까지 초안, 조사, 첫 번째 구현을 미리 해두고 싶을 때

솔로 빌더는 종종 생각보다 "아이디어 캡처 실패"로 시간을 많이 잃는다. 머릿속에서만 돌던 요구사항이 책상으로 돌아오는 동안 증발하기 때문이다. Dispatch는 이 증발을 줄인다. 휴대폰에서 던진 한 문장이 Desktop에서 실제 세션으로 바뀌고, 나는 나중에 결과만 이어받으면 된다.

이때 좋은 프롬프트는 길고 아름다운 문장이 아니라, 실행 가능한 최소 작업 단위다. 예를 들면 이런 식이다.

"회원가입 이탈률 문제 원인 가설 5개 정리하고, 로그에서 확인 가능한 지표 후보를 찾아줘."

"billing 페이지에서 플랜 변경 흐름 점검하고, 에러 가능성이 큰 부분을 메모해줘."

"어제 온 피드백 3개를 기능 제안으로 분해해서 우선순위 초안까지 만들어줘."

Dispatch의 본질은 코드를 당장 끝내는 것이 아니라, 내가 자리에 없을 때도 제품 운영 큐가 계속 움직이게 하는 것이다.

Channels: 사람이 없어도 이벤트가 Claude를 깨우게 만들기

진짜 자동화는 내가 휴대폰에서 메시지를 보내는 단계에서 끝나지 않는다. 더 나아가면 사람이 아니라 이벤트가 Claude를 깨운다.

Claude Code의 MCP 문서는, MCP 서버가 claude/channel 기능을 선언하면 외부 이벤트를 실행 중 세션에 직접 밀어 넣을 수 있다고 설명한다. CI 결과, 모니터링 알림, 채팅 메시지, 웹훅 이벤트가 세션으로 들어오고, Claude는 그 메시지에 반응할 수 있다.⁴

이 구조가 왜 중요할까. 솔로 빌더는 보통 병목이 명확하다. 내가 한 명뿐이라서, 문제 인지 → 맥락 수집 → 첫 대응이 늦어지면 전부 늦어진다. Channels는 이 앞단을 줄여준다.

예를 들어 이런 흐름을 만들 수 있다.

• GitHub Actions 실패 → 채널이 세션에 실패 로그 전달 → Claude가 원인 후보 정리

• 운영 알림 발생 → 채널이 에러 요약과 최근 배포 정보 전달 → Claude가 초기 트리아지 작성

• Discord나 Telegram의 사용자 제보 → 채널이 세션으로 전달 → Claude가 재현 조건 질문 초안 생성

여기서 중요한 건 "Claude가 모든 걸 자동으로 고친다"가 아니다. 더 현실적인 목표는 첫 반응 시간을 줄이는 것이다. 장애가 났을 때 가장 비싼 시간은 대개 처음 10분이다. 무슨 일이 벌어졌는지도 모르고 헤매는 시간. Channels는 그 시간을 줄여준다.

즉, Dispatch가 사람 손으로 작업을 던지는 방식이라면, Channels는 시스템이 스스로 작업을 던지는 방식이다. 둘은 경쟁 관계가 아니라 단계 관계다. 먼저 Dispatch로 사람이 없는 시간의 작업 큐를 만들고, 그다음 Channels로 외부 사건이 큐에 자동으로 들어오게 만들면 된다.

웹, 클라우드, SSH: 로컬 밖에서 아예 새 작업을 시작하는 방법

원격 실행을 이야기할 때 많은 사람이 Remote Control만 떠올리지만, 더 큰 그림은 Claude가 어디서 실행되는가다. Claude Desktop은 Local, Remote, SSH 환경을 고를 수 있다고 문서에 나와 있다.² 그리고 웹의 Claude Code는 Anthropic이 관리하는 클라우드 인프라에서 세션을 실행한다.³

이 차이를 감으로 정리해보자.

내 노트북이 켜져 있고, 그 환경의 MCP와 파일을 그대로 쓰고 싶다면 Remote Control이 맞다. 반대로 로컬 설정 없이 새 작업을 시작하고 싶거나, 컴퓨터를 들고 있지 않거나, 완전히 새로운 클라우드 세션에서 분리된 작업을 돌리고 싶다면 웹 기반 세션이 더 맞다.¹³

웹 세션은 브라우저를 닫아도 계속 유지될 수 있고, 모바일 앱으로도 모니터링할 수 있다. 대신 로컬 머신의 사용자 설정이나 로컬에서만 추가한 MCP 서버는 자동으로 따라오지 않는다. 저장소에 커밋된 CLAUDE.md, .claude/settings.json, .mcp.json 같은 설정만 가져간다.³ 다시 말해 웹 세션은 편리하지만, 내 컴퓨터 전체를 들고 다니는 기능은 아니다.

SSH 환경은 또 다르다. 이건 내가 관리하는 원격 머신에서 Claude를 돌리는 그림이다. 예를 들어 집에 미니 PC나 클라우드 VM을 두고, 여기에 빌드 도구와 데이터 접근 경로를 마련해놓으면, 내 노트북이 잠들어도 그 머신이 계속 일한다. 솔로 빌더에게는 이게 작은 전환점이 된다. "내 작업 환경"이 특정 노트북이 아니라 항상 켜져 있는 작업 노드로 바뀌기 때문이다.

결국 선택 기준은 단순하다.

• 로컬 컨텍스트를 그대로 이어가야 하면 Remote Control

• 휴대폰에서 새 작업을 던져놓고 싶으면 Dispatch

• 외부 사건이 자동으로 반응하게 만들고 싶으면 Channels

• 로컬 머신에 묶이고 싶지 않으면 Web 또는 SSH

솔로 빌더를 위한 원격 실행 아키텍처

혼자 제품을 만드는 사람에게 추천하는 가장 실용적인 구조는 거창하지 않다. 세 층만 있으면 된다.

첫째, 주 작업 노드가 있다. 보통은 내 메인 개발 머신이나 Desktop이 된다. 여기에 프로젝트, MCP, 로컬 도구, 인증이 붙어 있다. 긴 구현 작업, 대규모 리팩터링, 배포 전 점검은 여기서 돈다.

둘째, 원격 조작 면이 있다. Claude 모바일 앱, claude.ai/code, 혹은 Desktop의 다른 표면이다. 여기서는 긴 코드를 쓰는 게 아니라 승인, 방향 수정, 질문 답변, 상태 확인을 한다. 작은 입력으로 큰 흐름을 바꾸는 곳이다.

셋째, 이벤트 유입 면이 있다. CI, 모니터링, 채팅, 사용자 피드백이 Channels나 비슷한 경로를 통해 세션으로 들어온다. 이 층이 있어야 일이 "내가 기억할 때만 움직이는 시스템"에서 벗어난다.

이 세 층이 합쳐지면 하루가 꽤 다르게 돌아간다. 아침에는 로컬에서 구현을 시작한다. 점심 이동 중에는 Remote Control로 테스트 결과를 확인한다. 오후에는 Desktop에서 Dispatch로 받은 아이디어 초안을 검토한다. 저녁에는 CI 실패가 채널로 들어오면 Claude가 먼저 로그를 정리해놓는다. 나는 그때 정말 필요한 판단만 한다.

이게 바로 1인 개발자가 AI 에이전트를 쓰며 얻는 비대칭 우위다. 내 시간이 늘어나는 게 아니라, 내 부재 시간이 덜 낭비되는 것이다.

잘못 쓰면 오히려 느려지는 함정

원격 실행은 강력하지만, 잘못 설계하면 오히려 산만해진다.

첫 번째 함정은 모든 걸 Remote Control로 해결하려는 것이다. 이미 세션이 없는데도 무조건 RC를 떠올리면, 밖에서 할 수 있는 일이 생각보다 적어진다. 이럴 때는 Dispatch가 더 맞다.

두 번째 함정은 모바일에서 긴 편집까지 하려는 것이다. 휴대폰은 구현 장치가 아니라 판단 장치에 가깝다. 승인, 우선순위 수정, 짧은 지시, 결과 확인에 집중해야 효율이 난다.

세 번째 함정은 이벤트를 너무 많이 연결하는 것이다. 모든 알림이 Claude 세션으로 흘러들어오면, 결국 세션이 또 다른 잡음 저장소가 된다. Channels는 "중요한 사건만" 들어오게 해야 한다. 빌드 실패, 결제 오류, 주요 사용자 제보 정도면 충분하다.

네 번째 함정은 실행 위치를 흐리게 만드는 것이다. 지금 Claude가 로컬에서 도는지, 웹 클라우드에서 도는지, SSH 머신에서 도는지 모르면 권한과 파일 접근을 헷갈리게 된다. 원격 실행의 첫 규칙은 늘 같다. 지금 누가 어디서 실행 중인지 먼저 확인하라.

원격 실행을 도입하는 가장 좋은 순서

욕심내지 말고 이 순서로 가는 것이 좋다.

먼저 Remote Control을 붙인다. 이미 하던 일을 휴대폰에서 이어받는 경험을 만들어야, 원격 실행이 몸에 들어온다.¹

그다음 Desktop과 Dispatch를 붙인다. 이제 밖에서도 일을 "시작"할 수 있다.²¹

그다음 Channels를 붙인다. 이제는 사람 없이도 중요한 사건이 Claude를 깨운다.⁴

마지막으로 정말 필요할 때만 Web이나 SSH를 섞는다. 내 로컬 머신 의존성을 줄이고, 특정 작업을 별도 환경으로 분리한다.²³

여기까지 오면 Claude Code는 더 이상 내 터미널 안의 도구가 아니다. 제품 운영 체계의 일부가 된다.

혼자 만드는 사람에게 가장 무서운 건 일이 많다는 사실이 아니다. 내가 자리를 비우는 순간 시스템이 멈춘다는 사실이다. Remote Control과 Dispatch, 그리고 Channels는 그 멈춤을 줄여준다. 결국 더 빠른 솔로 빌더는 더 오래 앉아 있는 사람이 아니라, 자리를 비운 동안에도 흐름이 끊기지 않게 만든 사람이다.

참고

¹모든 기기에서 로컬 세션 계속하기 (Remote Control)

²Claude Code Desktop 사용하기

³Use Claude Code on the web

⁴Connect Claude Code to tools via MCP