주문 이후: AI 에이전트가 MCP로 자기 VPS를 운영하는 법

에이전트가 서버를 사는 데모는 대부분 주문이 통과되는 순간에서 끝납니다. 가장 재미없는 순간이죠. 서버는 생겼고, 에이전트는 47HZ7YF 같은 id를 들고 있으며, 그다음에 무슨 일이 일어나는지는 아무도 말하지 않습니다.

그다음은 관리자가 생각 없이 하는 모든 일입니다. SSH가 정말 응답할 때까지 기다리기, 비밀번호 찾기, 디스크가 차오르는 걸 알아채기, 커널 업데이트 후 재부팅, 월말 전에 갱신, 뭔가 이상할 때 지원팀에 묻기. 에이전트가 인프라를 소유하려면 그 부분도 맡아야 합니다. 저희 MCP 서버로 그게 어떻게 진행되는지 보여 드립니다. 글로 쓰기 전에 모든 단계를 테스트 환경에서 실행해 봤습니다.

아직 클라이언트를 연결하지 않았다면 Claude Code와 Codex 또는 Claude Desktop과 Cursor부터 시작하세요.

첫 1분: "active"는 "준비 완료"가 아니다

order_vps는 주문이 잔액에서 결제되는 즉시 응답합니다. 서버는 백그라운드에서 만들어지며 보통 1분 정도 걸립니다. 에이전트의 다음 호출은 get_vps_status이고, 얼마든지 반복해도 됩니다. 이 도구는 읽기만 합니다.

중요한 필드는 두 개입니다. 머신이 생기면 status가 active가 됩니다. access에는 로그인에 필요한 것, 즉 호스트, 포트, 바로 쓸 수 있는 SSH 명령이 들어 있습니다. 전용 IPv4 요금제는 포트가 22입니다. NAT 요금제는 개인 포워딩 포트이며, 응답이 이를 명시적으로 알려 주고 외부 포트만 허용하는 방화벽으로 스스로를 잠그지 말라는 경고까지 붙입니다.

두 순간 사이에는 사람들이 걸려 넘어지는 틈이 있습니다. 첫 부팅 때 OS 업데이트가 적용되는데 몇 분 걸릴 수 있고, 그동안 SSH가 연결을 거부할 수 있습니다. 예의 바른 에이전트는 22번 포트를 두드리는 대신 access.ssh_ready를 기다립니다.

주문에 SSH 키가 없었다면 root 비밀번호가 기다리고 있습니다. reveal_password는 이를 정확히 한 번, 그것도 VM 부팅이 끝난 뒤에만 넘겨줍니다. 너무 일찍 물으면 일회성 표시를 쓰지 않은 채 password_pending을 받습니다. 아직 부팅 중인 VM이 적용하지 않은 비밀번호를 에이전트가 자꾸 가져가는 일이 있어서 이렇게 만들었습니다. 그래도 솔직히 말하면, 주문할 때 ssh_key를 넘기고 이 단계를 아예 건너뛰세요.

둘째 날: 지켜보기

get_vps_metrics는 CPU, 메모리, 네트워크, 디스크를 최근 1시간, 하루, 일주일, 한 달 시계열로 돌려줍니다. 하루 한 번 확인하는 에이전트라면 작은 서버를 죽이는 패턴, 즉 OOM killer가 희생자를 고를 때까지 메모리가 서서히 오르는 모습을 알아챌 수 있습니다. 밖에서 원인을 고칠 수는 없지만, 여러분에게 알리거나 SSH로 들어가 살펴볼 수 있습니다.

power_vps는 start, stop, reboot을 합니다. 테스트에서 본 한 가지: 서버가 활성 상태가 아니면(아직 생성 중이거나 미결제 갱신으로 정지된 경우) 도구는 먼저 상태를 확인하라는 안내와 함께 409를 돌려줍니다. 200이 아닌 모든 응답을 "영원히 재시도"로 처리하는 에이전트는 여기서 루프에 빠집니다. 오류가 무엇을 해야 하는지 알려 주는데, 저희 오류 메시지는 사람만큼 에이전트를 위해서도 쓰였기 때문입니다.

set_hostname은 머신 안에서 도는 게스트 에이전트를 통해 이름을 바꾸므로, 리눅스에서는 재부팅 없이 적용됩니다. qemu-guest-agent를 지우면 이 도구는 작동을 멈추고 agent_unavailable을 돌려주며 아무것도 바꾸지 않습니다.

서른째 날: 돈

에이전트가 가진 인프라가 대개 죽는 곳이 여기입니다. 갱신은 누군가의 캘린더 알림이고, 그 사람은 바쁘고, 서버는 정지됩니다.

저희는 갱신이 에이전트의 기억에 달려 있지 않습니다. 각 서버는 선불 잔액에서 매달 갱신되고, 계정 이메일로 기한 전에 알림이 갑니다. 에이전트는 다음 청구액보다 잔액을 높게 유지하기만 하면 되고, get_balance가 현재 상황을 알려 줍니다.

유예 기간은 없습니다. 기간이 끝날 때 잔액이 갱신 금액에 못 미치면 서버는 정지되고 전용 IP는 풀로 돌아갑니다.

잔액이 부족하면 topup_balance가 암호화폐 결제 링크를 만듭니다. Base, Ethereum, Polygon의 USDT, USDC, ETH입니다. 에이전트가 여러분을 필요로 하는 첫 번째 지점입니다. 청구서는 만들 수 있지만, 지갑을 주지 않는 한 트랜잭션에 서명할 수 없고, 저희라면 지갑을 주기 전에 오래 고민하겠습니다. 실제로는 몇 달 치를 한 번에 충전하고 에이전트가 거기서 쓰게 합니다. 잔액 부족으로 주문이나 청구서가 미결제로 남았다면, 여러분이 충전한 뒤 에이전트가 pay_invoice를 호출하면 잔액에서 결제됩니다.

솔직한 빈틈 하나: MCP 도구로는 요청에 따라 서버를 몇 달 앞까지 갱신할 수 없습니다. 월 갱신은 자동이고, 3·6·12개월 선결제는 대시보드나 REST 호출 한 번으로 합니다. 처음부터 긴 기간을 원하면 order_vps가 주문 시 months(1~36)를 받습니다.

성장은 get_upgrade_options와 change_plan이 맡습니다. 요금제는 그 자리에서 바뀌고, 파일과 OS는 그대로이며, 서버는 한 번 재부팅되고, 남은 기간의 차액은 잔액에서 빠집니다. 에이전트는 confirm: true를 넘겨야 합니다. "돈을 쓰는 거니 확실히 해"라는 저희식 표현입니다.

문제가 생기면

파괴적인 작업은 일부러 번거롭게 만들었습니다. reinstall_vps와 즉시 cancel_service는 모두 confirm에 서버의 정확한 호스트명을 요구하고, 설명에서 에이전트에게 먼저 사람에게 확인하라고 안내합니다. 에이전트가 여러분을 필요로 하는 두 번째 지점이며, 의도된 것입니다.

안전한 해지인 end_of_period는 결제한 기간이 끝날 때까지 서버를 유지합니다. undo_cancel로 되돌릴 수 있다는 건 생각보다 중요합니다. 에이전트도 사람만큼 작업 도중에 마음을 바꿉니다.

에이전트가 막히면 create_ticket이 서버에 연결된 티켓을 열고, reply_ticket으로 대화를 이어 갑니다. 읽는 건 저희 쪽 사람이지, 챗봇에 답하는 챗봇이 아닙니다.

그리고 사람이 개입해야 할 때는 delegate_service가 그 사람을 그 서버 한 대의 운영자로 이메일 초대합니다. 전원, 콘솔, 재설치, 호스트명은 쓸 수 있지만 결제, 갱신, 해지는 못 하고 에이전트의 토큰도 볼 수 없습니다.

에이전트가 아직 못 하는 것

한계를 분명히 하자면:

• 잔액 충전. 충전 청구서를 만들고 pay_invoice로 잔액에서 청구서를 결제할 수는 있습니다. 하지만 암호화폐를 잔액에 넣으려면 지갑이 필요하고, 그건 보통 여러분입니다.
• MCP로 OS 안에서 작업하기. 패키지, 설정, 배포는 SSH로 합니다. MCP는 머신을 바깥에서 관리합니다.
• 정지를 스스로 해제하기. 남용으로 서버가 정지됐다면 사람과의 대화가 필요하고, 그래야 마땅합니다.

이 중 어느 것도 도구를 덜 유용하게 만들지 않습니다. 에이전트 루프를 도구에 맞춰 설계하라는 뜻입니다. 상태를 확인하고, 잔액을 적정하게 유지하고, 티켓으로 에스컬레이션하고, 데이터를 지우는 일 앞에서는 여러분을 기다리는 것이죠.

에이전트의 작업이 짧다면 서버 한 대가 애초에 맞는 단위가 아닐 수 있습니다. VPS냐 샌드박스냐에서 1분 사는 microVM이 더 나은 경우를 다룹니다. 그렇지 않다면 요금제는 여기에 있고, MCP 레퍼런스에 모든 도구와 매개변수가 정리돼 있습니다.