Tailscale과 ACP를 이용해 내 Laptop에서 전문 OpenClaw 팀원과 함께 작업하기
왜 이 구성을 시도했을까?
저는 여러 대의 OpenClaw를 서로 다른 역할로 운영하고 있습니다.
- neo-vps / neo : PM 및 문서 작성
- M-Cube / kusanagi : 정보 수집, 정책, 분석
- GMTek / morpheus : 개발 및 코딩
각 OpenClaw는 자신만의 Workspace, Skill, Memory를 가지고 독립적으로 동작합니다.
하지만 실제 개발은 항상 내 Laptop의 VS Code와 GitHub 프로젝트에서 이루어집니다.
그래서 자연스럽게 이런 질문이 생겼습니다.
"원격 OpenClaw를 내 자리로 불러와 Pair Work를 할 수 없을까?"
Pair Work 관점에서 바라본 OpenClaw
사람과 Pair Programming을 할 때는 하나의 Workspace를 공유합니다.
Developer
│
Shared Git Workspace
│
Partner
하지만 현재 대부분의 Agent Framework는 반대입니다.
User
↓
Agent
↓
Workspace
즉,
- Agent가 Workspace를 가지고 있고
- 사용자가 Agent에게 갑니다.
OpenClaw도 기본적으로는 이 철학에 가깝습니다.
OpenClaw와 Pair Work하는 세 가지 방법
1. 내 자리로 Agent를 부르기
VS Code
↓
openclaw acp
↓
OpenClaw Gateway
↓
neo (openclaw agent)
Laptop에서는 IDE를 그대로 사용하고,
ACP Bridge가 원격 OpenClaw와 연결해 줍니다.
장점
- IDE는 항상 동일
- Agent만 변경 가능
단점
- ACP Bridge 설정이 필요
- Gateway 연결과 인증을 이해해야 함
2. Agent의 작업실로 가기
VS Code Remote SSH
↓
neo-vps
↓
OpenClaw
Workspace와 OpenClaw가 같은 머신에 있습니다.
가장 단순한 구조입니다.
하지만
PM 작업을 하다가
개발을 위해 Morpheus로 이동하면
VS Code 자체가 다른 머신으로 이동하게 됩니다.
3. 메신저처럼 사용하기
SSH나 CLI를 통해 명령만 보내고 결과를 받는 방식입니다.
간단하지만 IDE와 깊게 통합된 Pair Programming 경험과는 거리가 있습니다.
왜 Tailscale인가?
처음에는 단순히 VPN 정도로 생각했습니다.
하지만 실제로는
- VPS
- Windows
- Linux
- Mac
를 하나의 사설 LAN처럼 만들어 줍니다.
그 결과
Laptop
↓
100.x.x.x
↓
neo-vps
처럼 공인 IP나 포트포워딩 없이 서로 접근할 수 있습니다.
OpenClaw Gateway도 Tailnet 내부에서 안전하게 사용할 수 있습니다.
OpenClaw ACP 연결 과정
이번에 실제로 연결하면서 확인한 순서는 다음과 같습니다.
- Windows에 OpenClaw CLI 설치
- Tailscale로 Gateway 접근
- Gateway Token 설정
- ACP Bridge 실행
- Device Pairing 요청 생성
- Gateway 관리자 승인
- ACP 연결 완료
특히 최근 OpenClaw는 단순히 Token만 맞으면 접속되는 구조가 아니라,
Device Pairing을 통한 승인 절차가 추가되었습니다.
Windows에서 처음 연결을 시도하면
device pairing required
requestId: ...
가 발생합니다.
Gateway에서는
openclaw devices list
로 Pending Device를 확인할 수 있습니다.
승인 후에는
[acp] ready
가 출력되며 연결이 완료됩니다.
이 구조는 예전의 "토큰만 알면 접속 가능"보다 훨씬 안전한 방식이라고 생각합니다.
Windows를 ACP Client로 사용하기
이번에는 Windows에 OpenClaw CLI를 설치했습니다.
역할은 단 하나입니다.
VS Code
↓
openclaw acp
↓
neo-vps
즉,
Windows의 OpenClaw는 Agent가 아니라
ACP Bridge(Client) 역할만 수행합니다.
실제 작업은 모두 원격 OpenClaw가 수행합니다.
구축하면서 알게 된 점
ACP 연결 자체보다도
Tailscale, Gateway Token, Device Pairing, 방화벽(UFW) 등
여러 요소가 함께 맞아야 정상적으로 동작했습니다.
특히 UFW에서 Tailscale 대역을 허용하지 않으면
Gateway까지 연결되지 않았습니다.
또한 최신 OpenClaw는 SecretRef와 Device Pairing 중심으로 인증 구조가 변경되어,
예전처럼 단순히 토큰만 복사하는 방식과는 다른 운영 방식을 이해할 필요가 있었습니다.
앞으로 기대하는 방향
현재 구조는
User
↓
Agent
↓
Workspace
에 가깝습니다.
하지만 개발자의 실제 작업 방식은
Workspace
↑
Neo
Morpheus
Kusanagi
가 더 자연스럽습니다.
즉,
- IDE는 그대로 유지하고
- GitHub Workspace도 그대로 유지한 채
- 필요한 Agent만 선택해서 함께 작업하는 것입니다.
예를 들어
- Neo는 PRD를 작성하고
- Morpheus는 코드를 작성하고
- Kusanagi는 관련 기술과 최신 동향을 조사합니다.
사용자는 IDE를 떠나지 않고,
필요한 전문가를 바꿔가며 Pair Work를 수행합니다.
저는 이것이 앞으로 OpenClaw와 같은 Agent Framework가 발전해야 할 중요한 방향이라고 생각합니다.
Agent가 자신의 작업실을 지키는 것이 아니라,
사용자의 Workspace로 찾아와 함께 일하는 경험.
그것이 진정한 AI Pair Programming의 모습이 아닐까 생각합니다.
'Agentic Coding' 카테고리의 다른 글
| cron만으로는 부족했다: 라벨 하나로 AI 봇 팀 깨우기 (0) | 2026.08.05 |
|---|---|
| Skill 작성의 다양한 접근 방법 (0) | 2026.07.22 |
| 2026년 상반기 AI 회고: Agent Orchestration의 해가 시작되었다 (2) | 2026.06.24 |
| 적응을 넘어 대응으로- 바둑이 보여준 미래, 그리고 개발자가 가야 할 다른 길 (2) | 2026.06.17 |
| 학습, 확장, 버리기: AI로 성장하는 법 (0) | 2026.06.03 |
