🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

허깅페이스는 사용자가 도구와 Gradio 애플리케이션을 맞춤 구성할 수 있는 공식 MCP 서버를 구축하면서, 변화가 빠른 MCP 전송 규격 가운데 상태 비저장·직접 응답 방식의 Streamable HTTP를 운영 환경에 선택한 이유와 실제 배포 경험을 설명한다.

📌 핵심 요약

• 허깅페이스 공식 MCP 서버는 하나의 원격 URL을 통해 Hub와 수천 개의 Spaces 기반 AI 애플리케이션에 접근하게 하며, 사용자 설정에 따라 제공 도구를 동적으로 조정한다.
• MCP의 원격 전송 방식은 HTTP with SSE에서 Streamable HTTP로 전환되는 중이며, 클라이언트마다 지원하는 프로토콜 개정판과 기능이 달라 서버 설계가 복잡해졌다.
• Streamable HTTP는 직접 응답, 요청 범위 스트림, 서버 푸시 스트림을 지원하며, 필요한 진행 알림·Sampling·Elicitation·구독·목록 변경 알림에 따라 적절한 방식을 선택해야 한다.
• 허깅페이스는 요청마다 토큰이나 OAuth 자격 증명으로 사용자 설정과 할당량을 조회할 수 있고 실행 중 Sampling이나 Elicitation이 필요하지 않아, 운영 환경을 상태 비저장·직접 응답 방식으로 구성했다.
• 실제 운영에서는 도구 호출 한 번당 약 100개의 제어 메시지가 발생했고 다양한 클라이언트의 불필요한 요청과 재접속이 관찰되어, 공개 MCP 서버에서 연결 관리와 호환성 비용이 중요하다는 점이 확인됐다.

🧩 주요 포인트

1. 허깅페이스 공식 MCP 서버는 하나의 원격 URL을 통해 Hub와 수천 개의 Spaces 기반 AI 애플리케이션에 접근하게 하며, 사용자 설정에 따라 제공 도구를 동적으로 조정한다.
2. MCP의 원격 전송 방식은 HTTP with SSE에서 Streamable HTTP로 전환되는 중이며, 클라이언트마다 지원하는 프로토콜 개정판과 기능이 달라 서버 설계가 복잡해졌다.
3. Streamable HTTP는 직접 응답, 요청 범위 스트림, 서버 푸시 스트림을 지원하며, 필요한 진행 알림·Sampling·Elicitation·구독·목록 변경 알림에 따라 적절한 방식을 선택해야 한다.
4. 허깅페이스는 요청마다 토큰이나 OAuth 자격 증명으로 사용자 설정과 할당량을 조회할 수 있고 실행 중 Sampling이나 Elicitation이 필요하지 않아, 운영 환경을 상태 비저장·직접 응답 방식으로 구성했다.
5. 실제 운영에서는 도구 호출 한 번당 약 100개의 제어 메시지가 발생했고 다양한 클라이언트의 불필요한 요청과 재접속이 관찰되어, 공개 MCP 서버에서 연결 관리와 호환성 비용이 중요하다는 점이 확인됐다.

🧠 상세 정리

1. Hub와 AI 애플리케이션을 연결하는 공식 MCP 서버

허깅페이스는 MCP가 AI 어시스턴트를 외부 세계와 연결하는 표준으로 자리 잡고 있다고 보고, Hub를 MCP로 제공하는 공식 서버를 개발했다. 연구·개발·콘텐츠 제작 등 Hub의 사용 방식이 다양하기 때문에 모든 사용자에게 고정된 도구 집합을 제공하기보다, 설정 페이지에서 각자 필요한 도구와 Gradio 애플리케이션을 선택할 수 있도록 했다. 서버는 이 설정을 반영해 사용자가 이용할 수 있는 도구 목록을 동적으로 조정하며, Spaces에 공개된 수천 개의 AI 애플리케이션에도 접근하게 한다. 동시에 복잡한 다운로드나 로컬 설정 없이 이용할 수 있도록 원격 서버 형태를 택하고, hf.co/mcp라는 단일 URL을 접속점으로 제공했다. 이처럼 맞춤형 도구 구성과 간단한 원격 접근성이 초기 설계의 두 가지 핵심 목표였다.

2. 빠르게 바뀐 MCP 전송 규격과 호환성 문제

원격 MCP 서버를 만들 때 가장 먼저 결정해야 할 사항은 클라이언트가 어떤 전송 방식으로 접속할지다. MCP는 2024년 11월 공개된 뒤 9개월 동안 세 차례 개정됐고, 그 과정에서 기존 SSE 전송이 Streamable HTTP로 교체되는 한편 인증 규격도 도입과 재정비를 거쳤다. STDIO는 일반적으로 서버와 클라이언트가 같은 컴퓨터에서 실행될 때 사용되며, 필요하면 로컬 파일 같은 자원에도 접근할 수 있다. HTTP with SSE는 원격 HTTP 연결에 사용됐지만 2025년 3월 26일 버전에서 폐기 예정으로 지정됐고, Streamable HTTP는 그보다 유연한 배포 선택지를 제공한다. 문제는 클라이언트마다 지원하는 MCP 개정판과 기능이 서로 달라, 서버가 최신 규격을 채택하면서도 실제 접속 호환성을 함께 고려해야 했다는 점이다.

3. Streamable HTTP의 세 가지 통신 방식

Streamable HTTP에서는 직접 응답, 요청 범위 스트림, 서버 푸시 스트림이라는 세 가지 주요 통신 방식을 선택할 수 있다. 직접 응답은 일반적인 REST API와 비슷한 단순 요청·응답 구조로, 검색처럼 상태가 없고 빠르게 끝나는 작업에 적합하다. 요청 범위 스트림은 특정 요청이 처리되는 동안만 임시 SSE 스트림을 열어 영상 생성과 같은 장시간 도구 호출의 진행 상황을 알리거나, Elicitation으로 사용자 정보를 요청하고 Sampling을 수행할 수 있게 한다. 서버 푸시 스트림은 장기간 유지되는 SSE 연결을 통해 서버가 먼저 메시지를 보낼 수 있으며, 자원·도구·프롬프트 목록 변경 알림과 임의의 Sampling 또는 Elicitation을 지원한다. 다만 장기 연결에는 keep-alive, 재접속 시 재개, 연결 수명 관리가 추가로 필요하므로 지원 기능이 많아지는 만큼 운영 복잡성도 커진다.

4. 상태 유지 여부와 기능별 제약

Streamable HTTP 설계에서는 통신 방식뿐 아니라 서버가 연결별 상태를 유지할지도 결정해야 한다. 상태 비저장 방식은 모든 요청을 독립적으로 처리하므로 세션 ID가 필요 없고, 어느 서버 인스턴스든 요청을 맡을 수 있어 수평 확장이 단순하다. 상태 유지 방식에서는 초기화 요청에 서버가 mcp-session-id를 반환하고 클라이언트 문맥을 보존해야 하므로, 세션 고정이나 공유 상태 저장소가 필요하며 끊어진 연결의 메시지를 재생하는 기능도 고려할 수 있다. 도구·프롬프트·자원 호출은 세 통신 방식 모두 가능하지만, 자원 구독과 도구·프롬프트 목록 변경 알림은 서버 푸시에서만 지원되고 도구 진행 알림은 요청 범위 스트림에서 제공된다. 특히 요청 범위 스트림에서 Sampling이나 Elicitation의 응답을 원래 요청과 연결하려면 mcp-session-id가 필요하므로 상태 유지 연결을 사용해야 한다.

5. 오픈소스 구현과 운영 환경의 최종 선택

허깅페이스 MCP 서버의 오픈소스 코드는 STDIO, SSE, Streamable HTTP를 지원하고 직접 응답과 서버 푸시 모드를 시험할 수 있도록 구성됐다. 서버 푸시를 사용할 때는 keep-alive와 마지막 활동 기준 시간 제한을 설정할 수 있으며, 클라이언트별 연결 관리 방식과 도구 목록 변경 알림 처리를 살펴보는 관측 대시보드도 제공한다. 그러나 실제 운영 환경에서는 Streamable HTTP의 상태 비저장·직접 응답 구성을 선택했다. 익명 사용자에게는 Hub용 표준 도구와 이미지 생성기를 제공하고, 인증 사용자에게는 선택한 도구와 Gradio 애플리케이션을 제공하면서 ZeroGPU 할당량도 계정에 맞게 적용한다. 이 정보는 각 요청에서 HF_TOKEN이나 OAuth 자격 증명으로 조회할 수 있고 기존 도구가 요청 사이의 추가 상태를 요구하지 않아, 서버 세션을 유지할 필요가 없었다.

6. 직접 응답과 OAuth를 택한 운영상의 이유

직접 응답 방식은 장기 스트림을 관리하지 않아도 되므로 허깅페이스가 검토한 선택지 가운데 배포 자원 부담이 가장 낮았다. 운영 당시 제공하던 도구에는 실행 도중 서버가 Sampling이나 Elicitation을 요청해야 하는 사례도 없었기 때문에, 요청 범위 스트림이나 서버 푸시가 제공하는 추가 기능이 필수적이지 않았다. 인증이 필요한 사용자는 MCP 서버 URL에 ?login을 붙여 OAuth 로그인을 시작할 수 있으며, 예시 주소는 https://huggingface.co/mcp?login이다. 허깅페이스는 claude.ai 원격 통합이 최신 OAuth 규격을 지원하면 이 로그인 방식을 기본값으로 바꿀 가능성도 언급했다. 결과적으로 현재 필요한 사용자 맞춤 설정과 계정별 할당량은 요청 시 조회하면서, 연결 상태와 스트림을 지속적으로 보존하는 비용은 피하는 구성이 채택됐다.

7. 구형 SSE 지원과 실시간 도구 목록 알림의 한계

출시 당시 여러 MCP 클라이언트는 여전히 HTTP with SSE를 원격 연결의 기본값으로 사용하고 있었지만, 허깅페이스는 폐기가 예정된 방식의 연결 관리에 크게 투자하지 않기로 했다. 이미 VSCode와 Cursor가 Streamable HTTP로 전환하기 시작했고, 출시 후 일주일 안에 claude.ai도 이를 지원해 최신 방식의 실사용 가능성이 빠르게 높아졌다. 향후 사용자 설정 변경을 실시간 도구 목록 변경 알림으로 전달하는 방안도 검토했지만, 사용자가 서버를 계속 활성화해 두면 실제 사용 여부와 관계없이 활성 클라이언트 수만큼 연결을 유지해야 한다. 반대로 많은 서버와 클라이언트는 비활성 시간이 지나면 연결을 끊기 때문에, 푸시 채널이 닫힌 동안 발생한 즉시 알림은 놓칠 수 있다. 따라서 클라이언트와 서버를 함께 통제할 수 없는 공개 배포에서는 서버 푸시의 복잡성을 떠안기보다 필요할 때 연결과 도구 목록을 새로 고치는 방식이 더 단순하다고 판단했다.

8. 단일 URL의 사용자 경험과 브라우저 판별

출시 직전 허깅페이스는 사용자가 hf.co/mcp를 일반 브라우저로 방문했을 때 이해하기 쉬운 안내 페이지를 보여주도록 개선했다. 이런 처리가 없으면 사용자는 친절하지 않은 JSON 응답만 보게 되므로, 서버 사용법을 안내하는 웹페이지가 접근 경험을 크게 향상했다. 하지만 처음에는 HTTP 405 오류 대신 웹페이지를 반환하자 VSCode가 해당 엔드포인트를 초당 여러 번 폴링하면서 예상보다 엄청난 트래픽이 발생했다. 조사 후 요청이 실제 브라우저에서 온 경우에만 안내 페이지를 반환하도록 판별하는 방식으로 문제를 해결했으며, VSCode 측도 관련 동작을 신속하게 수정했다. 원문은 MCP 규격에 이 동작이 명시적으로 규정돼 있지는 않지만, 브라우저 방문자에게 별도 페이지를 제공하는 방식 자체는 규격상 허용되는 것으로 보인다고 설명한다.

9. 실제 클라이언트 동작과 운영 관측 결과

MCP 클라이언트는 연결을 시작할 때 일반적으로 Initialize, Notifications/Initialize, tools/list, prompts/list 순서의 여러 요청을 보낸다. 애플리케이션이 열려 있는 동안 클라이언트가 반복해서 연결하고 재접속하며 사용자가 간헐적으로 도구를 호출하기 때문에, 허깅페이스 서버에서는 도구 호출 한 번당 약 100개의 MCP 제어 메시지가 발생했다. 일부 클라이언트는 상태 비저장·직접 응답 구성과 맞지 않는 Ping이나 취소 요청을 보내거나, 서버가 제공한다고 알리지 않은 Resources 목록을 요청하기도 했다. 2025년 7월 첫째 주에는 무려 164종의 서로 다른 클라이언트가 서버에 접속한 것으로 집계됐다. 특히 mcp-remote가 널리 사용됐으며, 전체 클라이언트의 약 절반이 이를 원격 서버 접속을 중계하는 브리지로 이용했다.

10. MCP 서버 활용 사례와 글의 결론

허깅페이스는 MCP가 채팅 애플리케이션, IDE, 에이전트, MCP 서버 전반에서 빠르게 발전하고 있으며, Hub 통합이 이미 강력한 확장 수단으로 작동한다고 평가한다. Gradio Spaces 지원을 통해 LLM이 최신 머신러닝 애플리케이션을 손쉽게 도구로 활용할 수 있게 됐고, 실제 사용자는 영상 제작 오케스트레이션, 이미지 편집, 문서 검색, AI 애플리케이션 개발, 기존 모델에 추론 기능 추가 등의 작업을 수행했다. 글은 특정 전송 방식을 일률적으로 권하기보다, 필요한 기능과 상태 유지 여부, 연결 관리 비용, 클라이언트 호환성을 함께 따져 원격 MCP 서버를 설계해야 한다는 경험을 전달한다. 또한 독자가 오픈소스 서버를 살펴보고 자신의 MCP 클라이언트에서 여러 전송 방식을 직접 시험하도록 권한다. 개선 사항이나 새로운 기능은 이슈와 풀 리퀘스트, 토론 스레드를 통해 제안할 수 있도록 열어 두었다.

🧾 핵심 주장 / 시사점

• 공개 원격 MCP 서버에서는 제공 가능한 기능의 수보다 실제 도구가 요구하는 기능을 기준으로 전송 방식을 선택하는 것이 중요하며, 허깅페이스는 상태 유지나 서버 주도 상호작용이 필요하지 않아 가장 단순한 구성을 택했다.
• 실시간 도구 목록 알림은 기능상 가능해도 모든 활성 클라이언트의 장기 연결과 재접속·누락 처리를 요구하므로, 필요 시 목록을 다시 조회하는 방식보다 운영 비용이 크게 늘어날 수 있다.
• MCP 서버의 실제 부하는 도구 실행만으로 결정되지 않으며, 초기화·목록 조회·재접속·불필요한 요청처럼 클라이언트가 만드는 제어 트래픽과 구현 차이까지 관측하고 대비해야 한다.

✅ 액션 아이템

• 허깅페이스 방식처럼 단일 원격 URL 기반으로 허브·스페이스를 연결하고 사용자 설정별 도구 동적 구성을 규칙화한다.
• 클라이언트 버전별 지원 기능 차이를 반영해 Streamable HTTP의 직접 응답·요청 범위 스트림·서버 푸시 사용 조건을 분기해 정의한다.
• 도구 호출당 제어 메시지 수와 재접속 패턴을 기준으로 공개 MCP 서버의 연결 관리·호환성 비용 부담을 사전에 점검한다.

❓ 열린 질문

• 진행 알림·샘플링·Elicitation·구독·목록 변경 알림 중 어떤 시나리오에서 어떤 스트림 모드를 선택할 것인가?
• 토큰/ OAuth 기반으로 요청마다 사용자 설정과 할당량을 조회할 때 상태 비저장·직접 응답 구조의 운영 한계는 어디인가?
• 클라이언트별 프로토콜 개정판 격차로 인한 불필요한 요청과 재접속을 줄이기 위한 최소 연결 관리 기준은 무엇인가?