Meta Muse VM을 공인 IP 없이 VPS처럼 쓰는 방법이 공개됐다

Meta가 제공하는 에이전트 실행 환경 Muse는 사용자마다 독립된 Linux 가상머신 한 대를 할당한다. 에이전트가 그 안에서 코드를 작성하고 스크립트를 돌리며 작업을 처리하는 구조다. 최근 한 개발자가 이 가상머신을 공인 IP 없이도 외부에서 접속 가능한 개인 서버처럼 쓰는 구성과 도구를 공개했다.

할당되는 사양은 Ubuntu 24.04에 2코어 CPU, 8GB 메모리, 100GB 디스크다. 제약은 두 가지다. 작업이 끝나거나 일정 시간 유휴 상태가 되면 가상머신이 회수되고, 재시작하면 루트 파일시스템이 초기화된다. 다만 /home/hatch/workspace 경로는 영구 보존된다. 도구와 스크립트, 데이터를 모두 이 디렉터리에 두면 머신이 재생성돼도 남는다.

외부 접속은 경량 터널 도구 rathole로 뚫는다. 가상머신은 공인 IP가 없지만 바깥으로 나가는 연결은 가능하므로, 안쪽 포트를 자신이 가진 공인 중계 서버에 매핑하는 방식이다. 걸림돌은 Muse 가상머신의 외부 트래픽이 플랫폼 게이트웨이 프록시를 반드시 거쳐야 하는데 rathole이 상위 HTTP 프록시 설정을 지원하지 않는다는 점이다. 이때 socat으로 로컬 프록시 다리를 놓아 중계 서버까지 연결한다.

유휴 회수로 사라진 프로세스는 Muse의 예약 작업 기능으로 되살린다. 5분 주기로 작업을 걸어두면 에이전트가 깨어나 가상머신을 다시 올리고, 영구 디렉터리에 있는 점검·기동 스크립트를 실행해 터널과 콘솔 프로세스를 재연결한다. SSH가 기본 제공되지 않는 점은 단일 파일 무의존성 웹 콘솔 muse-console로 메운다. CPU·메모리·영구 디스크 사용량과 72시간 하트비트 타임라인을 보여주는 대시보드, xterm.js 기반 웹 터미널, 파일 업로드·다운로드와 미리보기를 지원하는 파일 브라우저를 갖췄다. 배포는 저장소 링크를 Muse에 넘기면 중계 서버 정보를 물어본 뒤 설치와 설정, 터널, 예약 작업까지 자동으로 처리하는 방식이다.

샌드박스에는 외부 요청이 모이는 출구 프록시 hatch-egress-proxy:3128이 있다. 이 주소는 Muse 사설망 안에서만 닿을 수 있다. 가상머신 안에서 tcp-relay를 서버 모드로 띄워 터널 트래픽을 복호화한 뒤 이 프록시로 넘기고, rathole로 그 포트를 공인 중계 서버에 노출하면 로컬에서는 tcp-relay 클라이언트 모드로 암호화 연결을 맺어 로컬 HTTP 프록시 포트로 쓸 수 있다. 작성자는 이 출구 IP의 평판과 청정도가 높아 일반 데이터센터 IP를 차단하는 서비스도 대체로 통과한다고 주장했다.

Meta가 이런 구조를 택한 이유는 샌드박스 보안이다. 가상머신을 사설 네트워크에 격리해 내부 서비스에 대한 비인가 접근과 내부 횡적 탐색, SSRF를 막고, 모든 외부 요청을 출구 프록시 한 곳으로 모아 도메인 허용 목록 필터링과 감사, 위험 통제를 적용한다. 이번 구성은 그 경계를 개인이 우회해 쓰는 사례에 해당한다.

개발자 입장에서는 상시 가동 환경과 깨끗한 출구 IP를 확보하는 방법으로 읽힌다. 다만 전제가 많다. 공인 중계 서버가 따로 있어야 하고, 5분 주기 작업이 계속 돌아야 하며, 유휴 회수 정책 자체는 그대로다. 무엇보다 플랫폼이 의도하지 않은 방식으로 샌드박스 경계를 우회하는 만큼 이용약관 위반과 계정 제재 위험이 따른다. 원문 댓글에서도 이런 공개가 오히려 계정 정지로 이어질 수 있다는 지적이 나왔다.