MCP 서버를 호스팅하는 데 전용 IP가 필요한가요?

공개 HTTPS 엔드포인트에는, 네. NAT 요금제는 단일 SSH 포트를 포워딩하고 포트 443을 인터넷에 노출하지 않습니다. 전용 IP 요금제는 모든 포트와, 박스에 직접 향하게 할 수 있는 도메인을 줍니다.

stdio냐 HTTP냐 — 어떤 전송을 호스팅하나요?

HTTP(SSE 또는 더 새로운 streamable-HTTP). stdio 서버는 같은 기기의 클라이언트하고만 대화합니다; 네트워크 너머에서 닿게 하고 싶은 것은 URL 뒤에서 HTTP를 말해야 합니다.

하나의 VPS가 여러 MCP 서버를 돌릴 수 있나요?

네. 각 서버를 다른 로컬 포트에 바인딩하고 리버스 프록시에서 각각에 자체 서브도메인을 주세요. RAM이 실질적 한계이고, 도구 서버는 그것을 아주 조금만 씁니다.

MCP 서버에 RAM이 얼마나 필요한가요?

대개 적게. 도구 서버는 I/O 바운드입니다 — 숫자를 가는 게 아니라 API와 데이터베이스를 기다리므로 1~2 GB가 대부분을 처리합니다. 답을 생성하려 모델을 돌리는 것은 별개의, 훨씬 무거운 일입니다.

자신의 MCP 서버를 VPS에서 호스팅하기

당신은 MCP 서버를 작성했습니다. 로컬에서는 잘 돌아갑니다 — 에이전트가 부르고, 도구가 발화하고, 모든 게 배선됐습니다. 그다음 노트북을 닫으면 사라집니다. 그 서버를 에이전트가 필요로 할 때 언제든 닿게 하고 싶다면 — 다른 기기에서, 팀원의 설정에서, 새벽 3시의 예약 작업에서 — 안정적인 주소와 HTTPS를 갖춘, 늘 켜져 있는 곳에 살아야 합니다. 그것이 VPS의 용도입니다.

MCP 서버를 노트북에서 떼어내 당신이 실제로 통제하는 박스로 옮기는 법을, 노력이 어디로 가는지에 대한 솔직한 메모와 함께 적습니다.

로컬 대 원격: "호스팅"이 실제로 뜻하는 것

MCP 서버는 두 가지 형태로 옵니다.

stdio 서버는 로컬 프로세스로 돌고 같은 기기의 클라이언트와 표준 입출력으로 대화합니다. 만드는 동안에는 완벽하지만 — 네트워크 너머의 무엇으로도 닿을 수 없습니다.

원격 서버는 URL 위에서 HTTP(Server-Sent Events, 또는 더 새로운 streamable-HTTP 전송)를 말합니다. URL을 알고 올바른 자격 증명을 가진 클라이언트라면 무엇이든 부를 수 있습니다. 자신의 MCP 서버를 호스팅한다는 것은 원격 유형을 어딘가 공개적이고 안정적인 곳에서 돌리는 것입니다.

왜 그냥 노트북을 터널링하지 않나

기술적으로 가정용 기기를 터널로 노출할 수 있고, 빠른 시연에는 그것으로 괜찮습니다. 의존하는 무엇에든, 기기의 문제를 물려받습니다: 잠들고, ISP가 IP를 돌리고, 업로드가 느리고, 이제 실제 도구로 가득한 서비스가 다른 모든 것 옆에서 가정 네트워크에 앉아 있습니다. VPS는 고정된 공개 IP, 진짜 도메인, 제대로 된 가동 시간, 격리를 줍니다. 월 몇 달러로 "왜 내 에이전트가 연결을 잃었나"라는 질문의 범주 전체를 지웁니다.

스택, 구체적으로

작은 박스를 고르세요. MCP 도구 서버는 대체로 I/O입니다 — API, 파일, 데이터베이스를 기다리지 무거운 계산을 하지 않습니다. 대부분에는 1~2 GB RAM이면 충분합니다. (답하려 모델을 인라인으로 돌리는 것은 다른 이야기 — Ollama로 LLM 자체 호스팅 참조.)

서버를 localhost에 바인딩해 돌리세요, 이를테면 Node나 Python이 127.0.0.1:3100에서 대기. 공개 인터페이스에서 직접 떨어뜨려 두세요 — 프록시가 그것을 다룹니다.

리버스 프록시를 앞에 두어 당신의 도메인에서 TLS를 종료합니다. Caddy는 그것을 약 네 줄로 하고 무료 인증서를 자동으로 가져옵니다:

mcp.yourdomain.com {
    reverse_proxy 127.0.0.1:3100
}

mcp.yourdomain.com을 VPS IP로 향하게 하고, Caddy를 리로드하면, 서버가 streamable-HTTP로 https://mcp.yourdomain.com에서 살아납니다.

상시 가동으로 유지하기

첫 크래시나 재부팅에 죽는 서버는 "호스팅된" 게 아닙니다 — "지금은 돌고 있는" 것입니다. systemd 유닛으로 감싸 크래시에 재시작하고 재부팅 후 돌아오게 하세요:

[Unit]
Description=My MCP server
After=network.target

[Service]
ExecStart=/usr/bin/node /opt/mcp/server.js
Restart=always
RestartSec=2

[Install]
WantedBy=multi-user.target

systemctl enable --now my-mcp, 그러면 진짜 상시 가동입니다. (같은 패턴이 어떤 에이전트나 봇이든 24시간 내내 살립니다.)

사람들이 놓치는 부분: 닿을 수 있는 포트가 필요하다

공개 MCP 엔드포인트에는 인터넷에서 닿을 수 있는 인바운드 포트 — 443 — 가 필요합니다. NAT 요금제에서는 SSH용으로 포워딩된 포트가 정확히 하나 있고 그 외엔 없습니다; 443을 세상에 열 수 없습니다. 공개 HTTPS MCP 서버를 호스팅하려면 모든 포트가 당신 것이고 도메인을 박스에 직접 향하게 할 수 있는 전용 IP 요금제가 필요합니다. 그것이 "같은 노트북의 내 에이전트가 닿을 수 있다"와 "어디의 누구 클라이언트든 닿을 수 있다"의 차이입니다.

잠그기 — 이것은 권한을 가진 API다

MCP 서버는 대개 무언가를 하는 도구를 노출합니다: 파일 읽기, 유료 API 치기, 돈 옮기기. 그것을 벌거벗은 채 열린 인터넷에 두지 마세요.

모든 호출에 토큰을 요구. 익명 요청을 거부; 어떤 도구가 돌기 전에 bearer 토큰이나 API 키를 확인.
443과 SSH 포트를 제외한 모든 것을 방화벽으로.
키 전용 SSH, 비밀번호 로그인 없음. (10분 체크리스트는 여기.)

엔드포인트를 그것이 그러한 것 — 실제 권한을 가진 API — 로 다루면, 위험의 대부분이 사라집니다.

솔직한 한계

이제 운영은 당신 것. OS 업데이트, 프로세스 건강 유지, 로그 감시. Caddy가 인증서를 갱신해 주지만 나머지는 당신 것입니다. 관리형 클라우드 함수는 이것을 숨깁니다; VPS는 통제와 훨씬 낮은 청구와 맞바꿔 당신에게 넘깁니다.
MCP 스펙은 여전히 움직입니다. 전송과 인증 패턴이 릴리스마다 바뀝니다. SDK 버전을 고정하고 이따금 업데이트할 각오를 하세요.
CPU 박스는 도구 서버에는 알맞고, 로컬 모델로 답을 생성하는 데는 부적합. 서버가 응답을 위해 LLM을 돌린다면, 그것은 별개의 무거운 기기입니다 — Ollama 가이드 참조.
파괴적 도구를 인증과 확인 단계 없이 절대 노출하지 마세요. 물건을 지우는 열린 도구는 결국 모든 것을 스캔하는 봇을 만납니다.

결제

이메일로 가입하고 USDC나 USDT로 결제하세요 — 카드도 신분증도 없이. 그리고 이것을 에이전트를 위해 배선하고 있다면, 같은 종류의 박스를 우리 자신의 MCP 서버를 통해 프로그램적으로 주문하고 결제할 수 있습니다 — 에이전트가 등록하고, 잔액을 채우고, 스스로 주문합니다.

서버를 한 번 호스팅하면, 에이전트가 손을 뻗을 때는 언제든 당신의 도구가 거기 있습니다.

바로 쓸 수 있는 설정: MCP 서버용 VPS를 보세요 — 권장 요금제와 1분 암호화폐 배포.