코딩 에이전트의 가용성은 결국 그것이 실행되는 머신에 달려 있습니다. Claude Code나 Codex로 긴 리팩터링을 시작하고, 기차를 타려고 노트북 덮개를 닫는 순간, SSH 세션과 함께 실행도 죽어버립니다. 같은 노트북에서 에이전트 두 개를 돌리면 팬은 돌아가고 에디터는 버벅거립니다. 어느 순간 질문은 "어떤 에이전트를 쓸까"가 아니라 "에이전트를 어디서 실행할까"가 됩니다.
답은 보통 세 가지 중 하나입니다. 노트북에 그대로 두거나, 원격 서버로 옮기거나, 양쪽에 작업을 나눠 돌리는 것입니다. 각 선택은 편의성과 안정성을 맞바꿉니다. 노트북은 바로 옆에 있지만 잠들고, 성능이 제한되고, 연결이 끊깁니다. 서버는 깨어 있고 코어도 많지만 셋업이 필요하고 "지금 뭐 하고 있는 건지" 알 수 없는 층이 하나 더 생깁니다. 둘을 절충하면 양쪽의 장점을 다 얻는 대신 양쪽의 관리 부담도 다 떠안게 됩니다.
이 글에서는 원격 에이전트 셋업을 처음부터 끝까지 살펴봅니다. 실제 명령어로 직접 구축하는 방법, 각 단계에서 기다리는 실패 유형, 그리고 Sharkly의 연결된 Computer가 계속 고장 나는 부분을 어떻게 없애주는지까지 다룹니다. 여러분에게는 이미 코딩 에이전트가 있습니다. 문제는 그것을 어딘가 오래 살아남는 곳에서 실행하고, 자리를 비운 사이에 무슨 일이 있었는지 아는 것입니다.
에이전트를 노트북 밖으로 옮겨야 하는 이유
노트북이 기본값인 이유는 타이핑하는 곳이기 때문입니다. 하지만 노트북은 여러분의 집중력보다 오래 걸리는 작업에는 최악의 호스트입니다. macOS는 덮개를 닫으면 잠들고, 배터리 모드에서는 CPU가 스로틀링되고, 회사 VPN은 끊깁니다. 이런 일이 하나라도 벌어지면 작업 중이던 에이전트는 죽어버리고, 에이전트는 자신이 중단됐다는 사실조차 모릅니다. 여러분은 터미널을 다시 열어 죽은 프롬프트와 아무 요약도 없는 상황을 보고 나서야 알게 됩니다.
원격 호스트는 이런 물리적 한계를 해결해줍니다. 클라우드 VM이나 예비 리눅스 박스는 전원이 유지되고, 네트워크도 살아 있으며, 병렬 작업을 위한 여유 코어도 있습니다. 대가는 에이전트가 이제 보이지 않는 곳에서 실행된다는 점입니다. 확인하려면 SSH로 접속하고, 로그를 스크롤하며 어디까지 진행됐는지 추측하고, 결과는 복사해오기 전까지 그 박스에만 존재합니다.
둘 다 돌리는 것이 대부분 사람에게 정직한 최종 형태입니다. 피드백이 즉각적인 노트북에서는 빠르고 인터랙티브한 편집을 유지하고, 한 시간 동안 옆에서 지켜보지 않아도 되는 길거나 병렬적인 작업은 서버로 밀어 넣습니다. 비결은 호스트 하나든 다섯 개든, IP 주소 목록이 아니라 하나의 장소처럼 느껴지게 만드는 것입니다.
직접 구축하는 원격 셋업, 그리고 각 단계가 무너지는 지점
수동 경로는 잘 알려져 있습니다. 각 단계에서 나타나는 실패 유형과 함께 간단히 정리하면 다음과 같습니다.
호스트를 준비하고 에이전트를 올려놓습니다:
ssh you@build-server
# install the agent's CLI, e.g. Claude Code or Codex
# authenticate it with your own subscription or API key
git clone [email protected]:your-org/your-repo.git
cd your-repo
claude
실패 유형: 에이전트가 다른 사람도 손댈 수 있는 박스에서 여러분의 계정으로 인증하고, 자격 증명은 그 셸의 히스토리와 설정에 남습니다. 어느 호스트가 어떤 키를 들고 있는지에 대한 기록은 없습니다.
SSH 세션이 끝나도 실행을 유지합니다:
tmux new -s agent
claude # start the long task
# Ctrl-b d to detach, close the laptop, reconnect later
tmux attach -t agent
실패 유형: tmux는 SSH 연결이 끊기는 건 견디지만, 서버 재부팅, OOM 킬, 또는 세 대의 서버 중 여섯 개 세션 중 어느 것이 중요한 실행인지 잊어버리는 것까지는 견디지 못합니다. 분리(detach)는 지속성(durable)과 다릅니다.
결과를 가져오고 무슨 일이 있었는지 확인합니다:
scp you@build-server:~/your-repo/CHANGES.md .
ssh you@build-server 'cd your-repo && git diff'
실패 유형: diff는 박스 위에 있고, 추론 과정은 이미 잘려나간 스크롤백 버퍼에 있으며, "왜"는 사라졌습니다. 두 호스트에 두 에이전트로 이걸 곱하면, 확인할 때마다 상태를 손으로 재구성하게 됩니다.
이 단계 중 어느 것도 어렵지 않습니다. 문제는 이들이 서로 조합되지 않는다는 점입니다. 새 호스트, 새 에이전트마다 또 하나의 SSH 대상, 또 하나의 tmux 세션, 또 하나의 비밀이 사는 곳, 그리고 "끝났나"라는 질문에 답하기 위해 읽어야 할 또 하나의 로그가 늘어납니다.
연결된 Computer가 바꾸는 것
Sharkly는 여러분이 임기응변으로 해오던 것에 이름을 붙입니다. Computer는 에이전트가 작업을 실행할 수 있는 연결된 기기, 서버, 또는 컨테이너로, 에이전트에 필요한 운영체제, 파일, 자격 증명, 네트워크 접근, 도구를 제공합니다. 이 정의는 세 가지 선택지를 모두 포괄합니다. "로컬 컴퓨터, 원격 서버, 컨테이너, 또는 지원되는 클라우드 호스트가 될 수 있습니다."
매번 SSH로 접속하는 대신 호스트를 한 번만 등록하면 됩니다. 대상 머신에서 Settings, Computers에서 일회용 설치 토큰을 생성한 뒤 다음을 실행합니다:
sharkly computer register --install-token <install-token>
이 토큰은 수명이 짧고 일회용이라 이미지나 스크립트에 넣어두면 안 됩니다. 등록이 끝나면 Computer에서 백그라운드 로컬 서비스가 실행됩니다. 이 서비스는 호스트를 등록하고, 설치된 에이전트 도구를 감지해 각각을 Runtime으로 보고하고, 하트비트를 보내고, 대기 중인 실행을 받아 디렉터리를 준비하고, 진행 상황과 결과를 다시 보고합니다.
두 가지 경계는 분명히 짚고 넘어갈 만합니다. 사람들이 여기서 잘못 가정하기 때문입니다. 첫째, 로컬 서비스가 서버로의 연결을 시작하므로 일반적인 셋업에는 인바운드 포트가 필요하지 않습니다. 빌드 박스를 인터넷에 열어두는 게 아닙니다. 둘째, Computer가 Online으로 표시되는 것은 로컬 서비스가 하트비트를 보내고 있다는 뜻일 뿐입니다. Runtime이 Task를 실행할 수 있다는 뜻은 아닙니다. 온라인 호스트에서 실행이 시작되지 않는다면 네트워크를 건드리기 전에 Runtime의 기능 상태를 확인하세요.
여기서부터 앞서 나온 실패 유형들에는 대응책이 생깁니다. 자격 증명은 호스트의 것이고, 그 호스트에 한정됩니다. 실행은 tmux 세션이 아니라 로컬 서비스가 소유하기 때문에 여러분의 터미널보다 오래 살아남습니다. 그리고 diff, 요약, 추론 과정은 SSH로 들어가야 하는 박스의 스크롤백 버퍼에 사는 대신 Task로 돌아옵니다.
노트북, 서버, 아니면 둘 다: 실제로 선택하는 법
호스트가 많다고 자동으로 더 좋은 건 아니니, 작업에 따라 고르세요.
노트북을 쓰세요 — 작업이 짧고 인터랙티브하며 옆에서 지켜보고 싶을 때. 개인 Computer로 등록하고 Sharkly Desktop에서 Prevent sleep을 켜면 짧은 작업이 시스템 잠자기로 중단되지 않습니다. 단, Prevent sleep은 데스크톱 앱의 로컬 머신에서만 나타나며 공유 또는 원격 Computer에서는 사용할 수 없습니다. 여러분이 돌리는 모든 것이 커피 한 잔 시간 안에 끝나고 덮개를 닫아도 살아남을 필요가 없다면, 아직 서버는 필요 없습니다. 서버를 추가하는 건 나중에 원망하게 될 유지보수일 뿐입니다.
원격 서버를 쓰세요 — 작업이 오래 걸리거나, 코어가 더 필요하거나, 에디터와 리소스를 두고 다투면 안 될 때. 등록된 리눅스 호스트나 클라우드 VM은 기본적으로 깨어 있고 병렬 에이전트가 작업할 공간을 줍니다. 여기서 Computer의 호스트별 작업 동시성 한도와 Organization 또는 Space 가시성이 빛을 발합니다. 이 박스와 그 자격 증명은 공유되도록 만들어진 것이고, Sharkly도 그렇게 다룹니다.
둘 다 쓰세요 — 인터랙티브 편집은 로컬에서, 무거운 실행은 원격에서 하되 두 개의 멘탈 모델을 유지하고 싶지 않을 때. 노트북과 서버를 등록한 다음 각 Task를 적합한 Computer와 Runtime에 할당하세요. 병렬 에이전트가 충돌하지 않도록 막아주는 worktree 격리는 에이전트가 한 호스트를 공유하든 여러 호스트에 걸쳐 있든 똑같이 작동하므로, "둘 다"는 두 번째 워크플로가 아니라 선택의 비용만 치르면 됩니다.
DIY가 확장을 멈추는 지점, 그리고 태스크 보드가 더하는 것
SSH와 tmux 셋업은 한 호스트에 한 에이전트일 때는 통합니다. 여러 머신에 여러 에이전트가 있는 순간 무너집니다. "어떤 에이전트가 무엇을 하고 있고, 무엇이 끝났고, 무엇이 실패했고, 무엇이 내 검토를 기다리는가"에 대한 공유된 답이 없기 때문입니다. 이 질문이야말로 한 번에 여러 에이전트를 돌리는 이유 전체이며, 터미널 더미가 답할 수 없는 바로 그 질문입니다.
태스크 보드는 단위를 "호스트 위의 세션"에서 "기록을 가진 Task"로 바꿉니다. 에이전트는 조사하고, 실행하고, 테스트하고, 보고하며, 사람은 방향을 정하고, 권한을 부여하고, 결과를 승인합니다. 실행, 블로커, 결과, 후속 논의가 Task 타임라인으로 돌아오므로, 원격 실행을 확인하는 건 추측하며 SSH로 들어가는 게 아니라 Task를 여는 일이 됩니다. 자동화는 팀의 판단이 필요한 지점에서 멈춥니다. 에이전트가 요약과 근거와 함께 변경 사항을 건네면, 병합과 릴리스 결정은 여러분의 몫으로 남습니다.
이것이 두 접근법의 차이입니다. DIY는 에이전트를 원격으로 실행합니다. 태스크 보드는 어느 호스트가 작업했든 상관없이 요청부터 릴리스까지 컨텍스트, 진행 상황, 블로커, 결과, 사람의 검토를 계속 보이게 유지합니다.
오늘 바로 실행할 수 있는 체크리스트
사용할 예정인 호스트에서 이 목록을 차례로 따라가세요:
- [ ] 호스트를 솔직하게 고르기: 인터랙티브용은 노트북, 길거나 병렬 작업용은 서버, 정말 필요하면 둘 다.
- [ ] 각 호스트에 지원되는 에이전트 Runtime을 설치하고, 자신의 구독이나 API 키로 인증하기.
- [ ] 실행마다 SSH로 들어가는 대신
sharkly computer register --install-token <token>로 각 호스트를 한 번씩 등록하기. - [ ] 각 Computer가 Online으로 표시되는 동시에 최소 하나의 Runtime이 Available로 보고되는지 확인하기. 온라인만으로는 Task가 실행되지 않습니다.
- [ ] 노트북은 Computer 가시성을 Personal로, 공유 서버는 Organization 또는 Space로 설정하기.
- [ ] 노트북에서 덮개를 닫아도 살아남아야 하는 실행에는 Prevent sleep 켜기.
- [ ] 작고 지루한 Task 하나를 원격 호스트에 할당하고, 결과가 스크롤백 버퍼가 아니라 Task로 돌아오는지 확인하기.
- [ ]
sharkly computer list와sharkly daemon disk-usage로 호스트를 관리하고 공간을 회수하기.
SSH, tmux, worktree로 원격 셋업을 직접 구축할 수도 있고, 기존 호스트를 Computer로 등록해 로컬 서비스가 실행을 맡게 할 수도 있습니다. 이미 여러 머신에 걸쳐 여러 코딩 에이전트를 돌리고 있다면, Sharkly가 그들의 태스크와 결과를 관리할 한 곳을 제공합니다. Computer 하나를 연결하고, Agent 하나를 만들고, 먼저 지루한 일을 하나 맡겨보세요.
