muse 에이전트 샌드박스에 tailscale 리버스 터널로 접속한 사례

중국 개발자 커뮤니티 v2ex에 muse 에이전트가 띄운 리눅스 환경의 터미널에 외부에서 접속한 사용자 경험이 올라왔다. 에이전트가 만들어 준 샌드박스 안으로 직접 들어가 보고 싶다는 요구에서 출발한 시도로, 정공법 대신 리버스 터널을 경유하는 우회 경로를 택했다는 점이 핵심이다.

출발점은 muse에 내장된 tailscale 커넥터다. 별도 설치 없이 페이지의 설정 메뉴 안 커넥터 항목에서 바로 tailscale 연결을 맺을 수 있다고 한다. 작성자는 여기서 한 걸음 더 나아가 muse 쪽에 SSH 서비스를 직접 세워 보려 했지만 연결이 되지 않았고, 그 원인을 샌드박스 격리 때문으로 추정했다.

대안으로 선택한 것이 리버스 터널이다. 작성자는 이미 tailscale 네트워크에 소형 호스트 여러 대를 두고 있었고, 그중 한 대에 sshd를 열었다. 그리고 해당 장비의 인증 정보를 muse에 넘기면 나머지 연결 설정은 에이전트가 알아서 처리한다. 이후 그 호스트에서 ssh localhost:port 형태로 접속하면 반대 방향으로 muse의 리눅스 환경에 도달한다.

접속된 환경의 사양은 8GB 메모리, 2코어 2스레드다. 이 정도 구성에서 구글 접속은 정상적으로 동작했다고 작성자는 전했다. 에이전트가 실행되는 격리 환경 자체가 그리 무겁지 않은 자원으로 돌아가고 있다는 뜻이다.

배경에는 에이전트 샌드박스의 구조적 특성이 있다. 에이전트가 코드를 실행하고 파일을 만지는 공간은 보통 외부에서 직접 들어올 수 없게 막혀 있다. 그래서 에이전트가 남긴 결과물을 사람이 직접 열어 확인하거나, 예상과 다르게 동작할 때 내부 상태를 들여다보려면 이런 우회 경로가 필요해진다. 이미 tailscale 같은 오버레이 네트워크를 쓰는 팀이라면 같은 방식으로 접근 통로를 만들 수 있다.

실무적으로는 에이전트가 수행한 작업을 사후에 검증하거나, 실패한 실행의 흔적을 직접 확인하는 용도로 쓸 만하다. 다만 이 방식은 별도 호스트의 SSH 인증 정보를 에이전트에 전달하는 구조이므로, 해당 계정의 권한 범위를 필요한 만큼만 열어 두는 편이 안전하다.

작성자가 명시한 한계도 분명하다. 리버스 터널을 거치는 방식이라 지연이 상당히 크다고 밝혔다. 또한 muse에 SSH 서비스를 직접 세우는 시도가 실패한 이유는 확정된 것이 아니라 샌드박스 때문일 것이라는 추정에 그친다.