Ask HN: 프로덕션에서 MCP를 사용하는 사람이 있나요?
Ask HN: Who is using MCP in production?
저는 MCP가 처음 나온 이후로 계속 지켜봐 왔습니다. 초기에 많은 관심을 받았지만, 프로덕션에서 사용하는 사람들을 많이 접하지 못했습니다. 아마 제가 놓쳤을 수도 있습니다. 프로덕션에서 MCP를 사용하고 계신다면, 어떤 용도로 사용하시나요? 일반 API나 직접적인 도구 통합, 또는 CLI에 비해 어떤 장점을 발견하셨나요?
저는 사람들이 버그나 기능 요청을 직접 보고할 수 있게 해주는 AI 도구에 MCP를 사용했습니다. 중복 여부를 검색한 후 티켓을 작성하고 제출합니다. 프로덕션 도구이기 때문에 너무 부정확하지 않으면서 가장 저렴한 것을 원했습니다. API 등을 사용한다면 결국 자연어로 소통할 수 있도록 그 위에 MCP와 같은 어댑터를 구축하게 될 것입니다. JSON 등을 다루는 대신 말이죠. Linear의 MCP도 매우 깔끔하고 잘 설계되어 있어서, 예를 들어 Jira보다 핵심적인 장점 중 하나일 것입니다. API가 어떤지 알 수는 없지만 MCP가 훌륭하게 작동하기 때문입니다.
저희는 최근에 프로덕션에 배포한 새로운 도구를 가지고 있습니다. 앱 리소스와의 통신을 더 쉽게 만들어 줍니다. 그리고 에이전트가 원격 리소스와 대화하는 표준화된 방법으로, 무엇을 사용할 수 있고 어떻게 사용하는지 이해하기 쉽게 해줍니다. mcp tools/resources/prompts에 대해 더 읽어보세요.
저는 CLI나 API를 직접 호출하는 것이 훨씬 저렴하고 빠르다고 생각합니다. 현재 제가 사용하는 유일한 MCP는 Jira MCP인데, 한동안 설정해 두었고 오랫동안 사용해 왔기 때문입니다.
HN 토론
191- cgarvis
MCP는 최종 사용자(LLM 에이전트를 조종하는 사람)가 비기술적일 때를 위한 것입니다. 대부분의 비기술적 사용자는 컴퓨터에 CLI를 설치하지 않을 것입니다. 대부분 터미널을 통해 LLM 에이전트를 조종하지도 않을 것입니다.
또한 인증이 필요할 때 매우 유용합니다. CIMD와 함께하는 MCP OAuth는 API 키를 생성하는 번거로운 과정 대신 쉽게 만들어 줍니다.
기술적이고 이미 CLI를 사용하고 있다면, MCP는 많은 것을 제공하지 않습니다.
- Aldipower
우리는 3월 26일부터 프로덕션에서 MCP를 사용하고 있습니다. 사용자 대상 지구력 스포츠 분석 및 계획을 위해, MCP 호스트(이 경우 ChatGPT, Claude, Grok, Perplexity.ai, Mistral 등 챗 인터페이스)와 직접 통합됩니다. 이 모든 플랫폼은 사용자가 간단한 설명만으로 커스텀 MCP 서버를 추가할 수 있게 합니다. 예를 들어 Claude를 연결하려면: https://www.tredict.com/faq/connect-claude-web-with-tredict/
이렇게 하면 사용자는 이전 분석을 기반으로 Claude를 사용하여 Garmin 기기로 운동을 만들고 푸시할 수 있습니다.
또한 백그라운드에서 MCP를 사용하는 ChatGPT 앱도 있습니다: https://chatgpt.com/plugins/plugin_asdk_app_69aef5b699a08191...
여기서 핵심은 MCP가 제품 뒤에서 백본 역할을 하며 일반 사용자가 아무것도 모르고도 작업을 수행할 수 있게 한다는 점입니다.
"MCP가 쓸모없나?"라는 논의는 일반 소비자 관점에서 완전히 무의미합니다. 그들은 때때로 MCP가 무엇인지조차 모릅니다. Tredict ChatGPT 앱은 한 번의 클릭과 간단한 OAuth 흐름으로 연결됩니다. 그게 전부입니다.
- konart
우리 회사(저는 AI 관련 팀이 아닙니다)는 Jira, Confluence, Mattermost 포크 및 몇 가지 다른 통합을 위한 MCP를 보유하고 있습니다.
MCP 대 API 문제에 대해서는 잘 모르지만, 항상 MCP의 핵심은 모델과 도구/서비스 사이의 추상화라고 생각했습니다.
즉, 모델이 특정 API(특정 버전은 말할 것도 없고)를 알 필요 없이 서비스와 작업할 수 있다는 것입니다.
- 5ersi
MCP의 가치는 다소 줄어들고 있습니다. AI 에이전트가 API/CLI 사용에 더 능숙해지고 있기 때문입니다. 예를 들어, 저는 Claude를 통해 gh CLI를 사용합니다. MCP 대신에, 이미 CLI를 설정해 두었기 때문에 MCP를 사용할 필요가 없습니다.
MCP는 여러 소스를 교차하고 결과를 결합할 때 큰 가치를 가질 수 있습니다. 예를 들어, 직장에서 우리는 다섯 개의 다른(레거시) 시스템에서 로그/메트릭 검색을 위한 사내 MCP를 사용합니다. 몇 분 안에 다른 시스템의 이벤트 간 상관 관계를 찾아냅니다.
- throwup238
저는 두 가지 유형의 작업에 MCP를 사용합니다: Qt GUI를 검사하는 MCP 서버와 같이 프로세스의 메모리에 접근 권한을 부여해야 하는 작업, 그리고 ChatGPT/Claude 웹/모바일 앱에 내 데이터에 대한 인증된 접근을 제공해야 하는 작업입니다. 이러한 용도에서는 CLI가 사용이나 인증 측면에서 너무 번거로울 수 있습니다.
후자의 경우, Cloudflare 터널 + Zero Trust + GitHub SSO는 보안을 상당히 쉽게 만들어 주며, 최근 cf CLI를 통해 에이전트가 모든 작업을 수행합니다. base64로 인코딩된 이미지에 대한 기본 지원은 지속적인 재촉 없이 LLM이 무언가를 보도록 "장려"하는 데 유용합니다.
- navigate8310
저는 중국어 교과서를 OCR로 스캔하고, 교과서에만 기반하여 중국어 학습을 할 수 있게 해주는 상태 비저장 MCP를 만들었습니다. 이것으로 퀴즈를 시작하고, 복습할 때 추가 문법이 주입되지 않는다는 것을 알면서도 비슷한 의미를 가진 단어 간의 차이를 이해할 수 있습니다. 저는 특히 glm 5.3과 함께 사용합니다. 뉘앙스를 이해하는 가장 언어 특화적인 LLM이기 때문입니다.
저장소는 다음과 같습니다: https://github.com/iodize6399/xuexi-keben
서버 자체는 다음과 같습니다: https://keben.555420.xyz
- MitziMoto
우리는 고객 대면 음성 에이전트를 위해 프로덕션에서 MCP를 사용합니다. 우리의 커스텀 MCP 서버는 음성 에이전트가 고객과 상호작용하기 위해 접근해야 하는 도구와 리소스를 정의합니다 (예: 약속 예약, 주문 상태 확인 등).
이제 우리는 Eleven Labs, Vapi, Pipecat 등 어떤 음성 에이전트 플랫폼을 선택하든 우리의 커스텀 MCP 서버를 가리키기만 하면 즉시 사용 가능한 도구, 입력 및 사용 방법을 이해합니다.
HN에서 모두가 찬양하는 CLI나 API 같은 대안과 비교할 때, 이것은 명백한 선택입니다. 솔직히 현실적인 대안이 무엇인지조차 모르겠습니다.
ElevenLabs에 CLI를 패키징하여 배포하고 사용하라고 요청해야 할까요? 그들에게 전체 API 사양을 제공하여 구현하도록 해야 할까요?
저는 그들에게 엔드포인트와 자격 증명을 제공하면 그들의 플랫폼은 즉시 우리와 대화하는 방법을 알게 됩니다. ElevenLabs의 누구도 우리의 구현 세부 사항을 알거나 신경 쓰지 않습니다.
HN은 터미널에서 Claude Code로 코딩하는 "개발자" 사용 사례를 넘어서는 데 어려움을 겪고 있습니다. 실제 프로덕션 에이전트는 매우 다른 사용 사례를 가지고 있습니다!
다른 시스템과의 통합의 모든 부분을 소유하지 않을 때는 잘 정의된 표준이 필요합니다. 그것이 MCP가 제공하는 것입니다.
- cagz
네, 프로덕션에서 꽤 많은 용도가 있습니다. 주요 사용 사례는 에이전트를 위한 API 접근을 추상화하는 것입니다. 우리의 경우 대부분 특정 에이전트를 위해 맞춤 제작된 사내 MCP 서버입니다.
CLI나 에이전트가 API를 직접 접근하는 대신 MCP를 사용하는 이유는 무엇일까요?
직접 접근 (Curl/자체 작은 함수): 에이전트가 API 사양을 완전히 이해해야 합니다. 물론 점진적 공개를 통해 컨텍스트를 보호할 수 있지만, 이는 본질적으로 에이전트가 해당 컨텍스트에서 사용할 때마다 API를 계속해서 이해해야 함을 의미합니다. 또한 일반적인 API 사양은 에이전트 친화적일 수도 있고 아닐 수도 있습니다. 엔드포인트를 호출할 때 미묘한 차이가 있다면, 우리는 그것을 어디에 둘까요? OAS 설명에? 작동하지만 번거롭습니다.
CLI: 특히 복잡한 백엔드를 위한 타사 CLI가 이미 존재한다면 훌륭하게 작동합니다. 잘 문서화되고 에이전트 친화적인 CLI를 가정하지만, 대부분의 CLI는 인간 또는 CI/CD 소비를 위해 설계되었습니다. MCP가 너무 많은 컨텍스트를 차지한다는 이야기를 하자면, 에이전트가 my_cli --help로 시작하여 CLI가 어떻게 호출되어야 하는지 알아내기 위해 스위치와 매개변수를 하나씩 내려가는 것을 생각해 보십시오. 잘 알려진 CLI(예: aws)를 호출할 때는 문제가 덜하지만, 더 틈새(또는 커스텀)인 것은 최종 CLI 명령을 구성하기 위해 여러 번의 턴이 필요합니다.
MCP: 문제가 있지만 에이전트 네이티브 솔루션을 제공합니다. 에이전트가 도구에 대해 알아야 할 모든 것이 한 번에 제공됩니다. 엔터프라이즈 환경에서 MCP는 MCP 게이트웨이를 통해 제공되어 거버넌스와 권한 관리를 제공할 수 있습니다. 이는 상당히 반대입니다 […]