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 연결 과정

이번에 실제로 연결하면서 확인한 순서는 다음과 같습니다.

  1. Windows에 OpenClaw CLI 설치
  2. Tailscale로 Gateway 접근
  3. Gateway Token 설정
  4. ACP Bridge 실행
  5. Device Pairing 요청 생성
  6. Gateway 관리자 승인
  7. 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의 모습이 아닐까 생각합니다.

+ Recent posts