MCP 서버 주소, 어떻게 정할까? 33개를 조사했어요

공개 MCP 서버는 어떤 URL을 쓰나요?

대부분 전용 mcp. 서브도메인을 쓰고, 경로는 보통 /mcp예요. 저희는 mcp.scorestarling.com/mcp와 ElevenLabs가 쓰는 형태인 api.scorestarling.com/v1/mcp 중에서 고르다가, 다른 서비스들이 실제로 어떻게 하는지 알고 싶어서 직접 찾아봤어요.

2026년 10월 2일 UTC 17:40에서 17:42 사이에, 서비스 27곳의 주소 33개에 각각 인증 없는 POST를 한 번씩 보냈어요. 본문은 {}, 헤더는 Accept: application/json, text/event-stream, 타임아웃은 8초였고 상태 코드만 기록했어요. 401은 그 주소에서 무언가가 응답하며 토큰을 요구한다는 뜻으로, 보호된 MCP 서버가 로그인을 시작하는 방식이에요. 404는 그 경로에서 아무것도 제공되지 않는다는 뜻이에요. 일부 주소는 서비스가 공개한 것이고, 나머지는 어느 경로가 응답하는지 보려고 저희가 시도한 변형과 추측이에요. 이름난 서비스들의 스냅샷이지 전수 조사가 아니며, 그 뒤로 바뀐 것도 있을 수 있어요.

404에 실용적인 교훈이 있어요. MCP URL은 도메인에서 유추할 수 없다는 거예요. Stripe와 Vercel은 호스트만 있는 주소에서 답하고 /mcp에서는 404를 돌려줘요. Higgsfield는 그 반대이고, ElevenLabs는 /v1이 필요해요. 클라이언트는 받은 URL을 그대로 쓰고, RFC 9728은 그 URL을 서버 메타데이터가 일치해야 하는 식별자로 정해요. 그래서 같은 문자열이 문서, 설치 링크, 플러그인 매니페스트에 똑같이 들어 있어야 해요. 매니페스트에는 더 다양한 형태가 있어요. 저희가 설치해 둔 플러그인 중에는 gitlab.com 자체의 경로인 gitlab.com/api/v4/mcp와 mcp.hubspot.com/anthropic이 있었어요. 이 두 곳은 확인하지 않았어요.

MCP 엔드포인트가 웹사이트와 호스트를 같이 써도 되나요?

저희는 그렇지 않다고 봐요. 엔드포인트는 소프트웨어를 위한 것이고 연결 가이드 페이지는 사람을 위한 것인데, 둘 다 누가 봐도 알 만한 주소를 원해요. 2026년 10월 2일까지는 scorestarling.com/mcp가 저희 MCP 서버였기 때문에 가이드는 다른 곳에 둬야 했어요. 그 URL의 401이 모든 클라이언트가 로그인을 찾아내는 방법이어서, 같은 URL이 웹 페이지가 될 수도 없었어요.

한 URL에서 브라우저에는 페이지를, 클라이언트에는 MCP를 내주는 방법도 생각해 봤지만, 영구적인 구성으로는 접었어요. 요청을 한 번만 잘못 짐작해도 모든 클라이언트의 로그인 탐색이 깨지기 때문이에요. 전송 명세도 클라이언트가 이벤트 스트림을 열려고 엔드포인트에 GET을 보낼 수 있게 하고, 응답으로는 그 스트림이나 405를 기대하지 HTML 페이지를 기대하지 않아요.

호스트를 따로 두면 웹사이트의 변경이 엔드포인트에 닿지 않는 이점도 있어요. 사이트를 리디자인해도 엔드포인트가 옮겨 가지 않고, 마케팅 사이트에는 어울리는 CDN 캐시나 브라우저 챌린지가 엔드포인트 앞에 놓일 일이 없어요. 어시스턴트는 브라우저가 아니라 자체 인프라에서 서버를 호출해요. Anthropic의 커넥터 문서는 Claude가 Anthropic의 클라우드에서 연결하고, 아이덴티티 제공자 앞의 방화벽이 로그인을 깨뜨릴 수 있다고 말해요. 저희가 살펴본 두 곳도 같은 식으로 나눠 두었어요(2026년 10월 2일과 10월 3일에 다시 확인). Higgsfield의 가이드는 higgsfield.ai/mcp에, 서버는 mcp.higgsfield.ai/mcp에 있고, ElevenLabs의 가이드는 elevenlabs.io/mcp에, 서버는 api.elevenlabs.io/v1/mcp에 있어요.

저희 MCP 호스트는 /mcp와 /.well-known/*만 제공해요. 그 밖의 모든 경로는 웹사이트의 같은 경로와 쿼리로 308을 돌려줘서, 로그인, 동의 화면, 페이지, 다운로드 링크, 쿠키가 한 호스트에 머물러요. 웹사이트의 /mcp는 이제 Claude, ChatGPT 등 다른 클라이언트를 위한 연결 가이드예요.

$ curl -si "https://mcp.scorestarling.com/login?x=1"
HTTP/2 308
location: https://app.scorestarling.com/login?x=1

mcp.example.com/mcp, 호스트만 있는 주소, api.example.com/v1/mcp 중 무엇이 좋을까요?

어느 쪽이든 동작해요. 그 호스트에 또 무엇이 있는지를 보고 고르세요. MCP 인증 명세는 https://mcp.example.com/mcp와 https://mcp.example.com을 유효한 표준 서버 URI로 들고, 슬래시가 의미를 갖지 않는 한 끝 슬래시 없는 형태를 요구해요. 전송 명세는 POST와 GET을 받는 엔드포인트 경로 하나만 요구하고 예시로 https://example.com/mcp를 들며, Anthropic의 커넥터 문서는 https://mcp.example.com/mcp를 써요.

작은 규칙이 두 가지 더 있어요. Streamable HTTP 엔드포인트를 /sse로 끝내지 마세요. Anthropic 문서에 따르면 그렇게 끝나는 URL은 Claude의 커넥터 입력 양식에서 옛 SSE 전송 방식으로 선택돼요. 그리고 끝 슬래시는 꼭 필요할 때만 붙이세요. 401로 답한 주소 23개 중 끝 슬래시가 있는 것은 GitHub의 주소뿐이었어요.

MCP 서버를 새 URL로 옮기려면 어떻게 하나요?

한동안 두 주소를 모두 제공하고, 각 주소가 따로따로 완전하게 동작하도록 하세요. 주소마다 자체 401, 자체 메타데이터를 두고, 어느 오디언스의 토큰이든 받으세요. 저희는 네 단계로 옮겼고, 모두 2026년 10월 2일(UTC) 저녁 한 시간 안에 적용했어요:

1. 아무도 쓰지 않을 때 별칭(alias) 지원부터 배포하세요. 설정 하나에 이전 주소들을 나열하는데, 모두 HTTPS이고 /mcp로 끝나요. 토큰은 오디언스가 현재 주소이거나 별칭이면 검증을 통과하고, 그 밖의 오디언스는 거부돼요. 호스트 허용 목록(Starlette의 trusted hosts와 MCP SDK의 DNS 리바인딩 보호)에는 모든 주소와 웹사이트가 들어 있어요. 별칭을 설정하지 않으면 운영 환경은 이전과 똑같이 동작했어요.

2. 호스트를 추가한 다음, 주소 전환과 별칭 설정을 한 번의 변경으로 하세요. 새 서브도메인에 DNS 레코드를 넣었고, 인증서는 약 6분 뒤에 따라왔고, 저희 서버가 그 호스트를 신뢰하도록 설정하기 전까지는 호스트가 400으로 답했어요. 설정 변경 한 번으로 새 리소스 URL을 지정하고 옛 URL을 별칭으로 나열했기 때문에, 재배포 한 번에 둘 다 반영됐어요. 1단계가 적용되기 전에 이렇게 했다면 실행 중인 코드가 웹사이트 자체의 호스트를 거부했을 거예요.

3. 사람들이 복사하는 모든 곳의 주소를 새 주소로 바꾸세요. Claude, Cursor, VS Code용으로 인코딩된 원클릭 설치 링크를 포함한 연결 가이드, 플러그인 매니페스트, 문서예요.

4. 토큰 오디언스를 바꾼 다음 옛 주소를 폐기하세요. 마이그레이션으로 액세스 토큰 훅이 새 오디언스를 발급하게 했고, CI가 코드를 배포하기 전에 그 마이그레이션을 적용했어요. 별칭이 있는 동안에는 어느 오디언스의 토큰이든 여전히 동작했어요. 그런 다음 별칭을 제거하고 재배포했어요. 그 릴리스와 재배포 사이의 몇 분 동안에는 웹사이트의 /mcp가 브라우저에는 가이드를, MCP 클라이언트에는 서버를 내줬어요. 지금은 가이드만 제공하고, 가이드의 예전 주소인 /connect는 가이드로 308을 돌려줘요.

메타데이터는 놓치기 쉬운 부분이에요. RFC 9728은 resource가 클라이언트가 연결한 URL과 같아야 한다고 요구하고, Anthropic 문서는 Claude에 입력한 URL과 같아야 한다고 요구해요. 그래서 두 주소가 겹쳐 있는 동안 각 호스트가 자기 자신을 설명했고, 각 401은 자기 호스트의 문서를 가리켰어요:

GET https://scorestarling.com/.well-known/oauth-protected-resource/mcp
→ "resource": "https://scorestarling.com/mcp"

GET https://mcp.scorestarling.com/.well-known/oauth-protected-resource/mcp
→ "resource": "https://mcp.scorestarling.com/mcp"

/mcp 자체는 리다이렉트하지 않았어요. 전송 명세는 엔드포인트의 리다이렉트를 설명하지 않고, 엔드포인트 URL은 리소스이자 토큰 오디언스로서 OAuth 핸드셰이크의 일부이기 때문에, 대신 두 주소 모두에서 MCP를 제공했어요. 그 밖의 모든 경로에는 301이 아니라 308을 썼는데, 메서드가 유지되기 때문이에요. RFC 9110은 클라이언트가 308 뒤에 POST를 GET으로 바꾸는 것을 허용하지 않아요. 토큰에 오디언스가 들어가는 방식은 원격 MCP 서버의 OAuth, 출시하며 배운 것 글에 있어요.

이렇게 빨리 옮길 수 있었던 건 ScoreStarling이 아직 초대 전용의 작은 파일럿이었고 아무도 옛 주소에 의존하지 않았기 때문이에요. 별칭이 사라지면 scorestarling.com/mcp로 설정된 클라이언트는 다시 연결해야 해요. 저희 런북은 이미 새 주소를 쓰면서 옛 오디언스의 토큰을 가진 클라이언트가 401 invalid_token을 한 번 받고, 토큰을 갱신해서 새 오디언스를 받을 것으로 예상해요. 실제 Claude나 ChatGPT 클라이언트가 그렇게 하는 것은 아직 확인하지 못했어요. 실제 사용자가 있다면 옛 주소의 트래픽이 끊길 때까지 별칭을 유지하세요.

옮기는 중에 무엇이 깨졌나요?

작은 문제 세 가지가 있었어요:

• 확인 스크립트가 메타데이터 URL을 resource.replace('/mcp', '/.well-known/oauth-protected-resource/mcp')로 만들었어요. 옛 주소에서는 잘 됐어요. 하지만 https://mcp.scorestarling.com/mcp에서는 //mcp. 안에서도 /mcp가 일치해서 결과가 https://.well-known/oauth-protected-resource/mcp.scorestarling.com/.well-known/oauth-protected-resource/mcp가 됐어요. URL은 파싱한 부분들로 만드세요. 스킴과 호스트, 그다음 well-known 구간, 그다음 경로 순서예요.
• 더 길어진 주소가 너비 320픽셀 화면에서 가이드 페이지 밖으로 삐져나왔고, 인라인 코드가 줄바꿈되도록 허용한 뒤에야 해결됐어요.
• Railway의 명령줄 도구로 별칭 변수를 삭제해도 변경이 스테이징만 되었고, 직접 재배포하기 전까지는 옛 주소가 계속 받아들여졌어요.

MCP 서버 주소를 정하는 체크리스트

• 엔드포인트에는 사람을 위한 것은 아무것도 제공하지 않는 호스트를 주세요. 저희 표본에서는 mcp.에 내 도메인을 붙이는 것이 흔한 선택이에요.
• 경로는 한 번만 정하세요. /mcp가 가장 흔하고 호스트만 있는 주소도 유효해요. 끝 슬래시와 /sse로 끝나는 경로는 피하세요.
• 사람을 위한 연결 가이드 페이지는 메인 사이트의, 짐작할 수 있는 주소에 두고 내비게이션에서 링크하세요.
• 정확한 URL에 대한 RFC 9728 메타데이터를 /.well-known/oauth-protected-resource에 내 경로를 붙인 주소와 루트에서 제공하고, resource는 클라이언트가 쓴 주소와 같게 하세요.
• 그 URL을 토큰 오디언스로 삼고, 옮겨야 하기 전에 별칭 지원을 미리 만들어 두세요.
• MCP 호스트의 그 밖의 모든 경로는 쿼리 문자열을 유지한 채 308로 웹사이트에 리다이렉트하세요.
• 브라우저 챌린지와 HTML 캐싱이 MCP 호스트에 닿지 않게 하세요.
• 어디에서나 같은 문자열 하나를 공개하고(가이드, 설치 링크, 플러그인 매니페스트, 문서), 모든 사본이 일치하는지 테스트하세요.
• 옮길 때는 별칭 먼저, 그다음 새 주소와 별칭을 한 번의 변경으로, 모든 사본의 주소 교체, 오디언스 전환, 그리고 트래픽이 끊긴 뒤 옛 주소 폐기 순서예요.