MCP는 안 쓴다던 Pi, 결국 품었다
Pi.dev: You Said No MCP
Pi는 한때 MCP 미지원을 당당히 선언했고, 팟캐스트에서도 MCP를 여러 번 폄하했다. 하지만 이제 Pi를 업그레이드하면 MCP가 핵심 기능으로 포함된다. MCP 자체가 변했고, 그 변화가 Jev와 Codemode 같은 다른 기능에도 유용했기 때문이다. 저자들은 MCP가 OpenAPI처럼 지능형 도구 탐색을 제공해야 한다고 보며, 직접 참여해 작은 하네스에 맞게 발전시키려 한다.
우리는 무언가에 긍정적인 영향을 주는 가장 좋은 방법은 그것을 받아들이는 것이라고 믿는다.
HN 토론
336- alin23
최근에 MCP가 코딩 도구 그 이상이라는 걸 알게 됐다. 예를 들어 rcmd, Clop, Lunar 같은 내 복잡한 macOS 앱들[0]에 MCP를 구현해서 자연어로 설정할 수 있게 만들었다.
그래서 이제 로컬 Qwen과 Pi만 있어도 이런 말을 할 수 있다:
내 웹사이트 에셋 폴더에 떨어뜨린 모든 PNG를 최적화하고 같은 이름의 webp로 변환하도록 Clop을 설정해줘
HDD를 연결하면 Crank가 즉시 Time Machine 백업을 시작하고, 백업이 끝나면 알려주게 해줘.
rcmd를 누른 채로 퍼지 검색하고 cmux 에이전트 패널에 포커스할 수 있으면 좋겠어
BetterTouchTool에는 네이티브 SwiftUI 뷰를 만들어 핫키, 트랙패드 제스처 등에 바인딩할 수 있는 훌륭한 MCP가 있다. 이걸 통해 방대한 macOS 자동화 도구와 프라이빗 API를 활용해 에이전트가 Computer Use를 할 수 있게 해준다.
그런 도구들을 처음부터 직접 코딩하고, 앱들이 수년간 다듬어온 것과 같은 페일세이프 로직을 구현하려면 훨씬 더 유능한 코딩 모델이 필요할 것이다.
예를 들어 MCP 이후로 Crank[1]는 내 crontab, launchd, 일주일에 한 번 돌리는 여기저기 흩어진 스크립트 사용을 완전히 대체했다. 예전에도 못 했던 건 아니지만, 이제는 자동화를 그냥 설명하면 안정적으로 실행되고 UI에서 보이는 게 훨씬 간단하다. 마찰이 사라졌다.
[0] https://reddit.com/r/macapps/comments/1wkv0dy/mcp_in_macos_a...
- gk1
확고하게 믿고 있던 입장을 바꾼 것뿐만 아니라, 그것이 번복이라는 사실을 숨기지 않고 아주 공개적으로 알린 팀에 박수를 보낸다.
Armin의 링크된 글은 금이다:
"... 어떤 주제에 대해 매우 강한 의견을 마주할 때마다, 그 주제에 대한 합리적인 논의는 이미 오래전에 낡아버렸거나 더 이상 대화에 엄밀히 관련되지 않는 논거를 포함하는 경우가 많다."
(https://lucumr.pocoo.org/2016/11/5/be-careful-about-what-you...)
그리고 그게 2016년 글이다! 요즘은 일주일 전에 취한 입장을 가지고 논쟁한다 해도 이미 시대에 뒤처져 있을 수 있다.
- CharlieDigital
이건 가장 쉬운 판단이었고, 나 같은 많은 사람들이 3월[0]에 MCP를 죽었다고 주장하는 반(反)-MCP 물결 속에서 그렇게 판단했다 (Garry Tan을 포함한 수많은 저명한 테크 인물들이 그랬다). 말 그대로 3월의 모든 소셜 피드에 있는 모든 테크 인플루언서가 MCP는 죽었다고 외치며 CLI를 승자로 추대했다 (보안, 관측 가능성/텔레메트리, 배포와 운영의 용이성 등에 관한 모든 합리적인 논거를 완전히 무시하면서).
2026년 3월의 직접 인용[1]:
> [MCP의 죽음에 관한] 이 담론 상당수가 미묘함이 결여된 그냥 과대광고라는 데 아직도 확신이 안 선다면, 현재의 AI 인플루언서 FOMO 과대광고 사이클에 편승한 걸 축하한다; 인플루언서들이 관련성을 유지하고 네 눈과 돈을 얻기 위해 다음 순간의 새로운 계시로 넘어갈 6개월 뒤에 보자.
AI 엔지니어링과 도입이 '나에게 뭐가 통하느냐' 대 '우리 팀에게 뭐가 통하느냐'라는 솔로 개발자와 단일 하네스 스택을 넘어서면, 특히 엔터프라이즈 맥락에서 MCP가 왜 필요한지 꽤 명백했다. 사람들이 한 핵심 실수는 팀의 워크플로와 팀의 운영 스택이 아니라 자기 자신의 워크플로와 로컬 스택 관점에서 생각한 것이었다. 또한 로컬 `stdio` 대비 MCP의 무상태 HTTP 모드(그렇다, 3월에도 이미 존재했다; 스펙의 2026-07-28 개정판이 앞으로 이를 주요 초점으로 우선시할 뿐이다)에 대한 무지도 있었다.
지금 내 가장 큰 불만은 OpenAI가 여전히 MCP Prompts 스펙[2]을 구현하기를 거부하고 있고, g […]
- _fw
MCP에 대한 그들의 주저함은 이해하지만, /뭔가/가 아무것도 없는 것보다는 낫다.
글쓴이가 설명한 이유들로 인해 최적이 아닌 건 맞다: 하지만 USB-C도 그렇다. NVME도 그렇고, HDMI도 그렇다.
우리는 이런 대단히 성공한 기술들을 결함에도 불구하고 사용한다. 널리 호환되고 최종 사용자에게 쉽기 때문이다.
그래서 MCP가 어디에나 있다. 성능이 좋지 않고, 견고하지도 않고, 일관되지도 않을 수 있지만 시간이 지나면 WILL 더 나아질 것이다.
그리고 나는 지금 우리가 가진 광범위한 MCP 생태계가, LLM을 유용한 무언가에 꽂는 일곱여덟 가지 서로 다른 '최적' 방식보다 훨씬 낫다.
- kingkongjaffa
우리는 회사 이름을 반지의 제왕 설정에서 따오는 걸 그만둬야 한다.
- KronisLV
서브 에이전트 지원이 필요하다는 점에 대해 나도 같은 생각이다. 그건 내게 꽤 근본적인 것처럼 느껴진다.
똑똑한 모델이 여러 멍청한 모델을 굴려 작업을 시키고, 그런 다음 같은 똑똑한 모델로 서브 에이전트를 써서 적대적 리뷰를 하는 게 꽤 흔한 패턴이 될 것 같다.
개인적으로는 Pi가 그런 것 대부분을 플러그인으로 처리한다는 게 좀 혼란스러웠다. Eclipse가 얼마나 엉망이었는지, 얼마나 많은 게 그냥 느슨하게 맞물린 플러그인 투성이였는지 기억하기 때문이다. 그래서 내 필요 대부분을 기본으로 커버해주는 OpenCode로 갔다. 이게 내가 나이 드는 신호일 수도 있겠다. 내 IDE와 데스크톱 환경도 다 기본에 가까우니까.
- abtinf
> 이 시점에서 우리가 MCP를 생각하는 방식은, 지능형 도구 발견 기능을 갖춘 OpenAPI에 훨씬 가까워야 한다는 것이다. 즉 도구는 구조화된 데이터를 반환해야 하고, 도구는 문서와 설명으로 발견 가능해야 한다.
OpenAPI가 바로 '지능형 도구 발견'(그게 뭐든 간에)이다. OpenAPI는 말 그대로 '구조화된 데이터를 반환'하고 '문서와 설명으로 발견 가능'하다.
딱 한 번만이라도, 자기들이 무슨 말을 하는지 아는 것처럼 보이는 용어로 MCP를 설명하는 사람을 보고 싶다.
- statenjason
적절한 CLI가 없을 때 MCP를 소비하려고 나는 mcporter[0]를 쓴다. MCP를 셸 명령으로 노출시켜준다. 에이전트는 표준 셸 기본 요소로 조합한다. 도구가 json을 반환한다? jq로 파이프하면 된다.
또 다른 장점은 MCP를 서비스를 호출하는 특별한 방식으로 취급하는 대신, 에이전트와 정확히 같은 방식으로 도구를 실행할 수 있게 해준다는 것이다. 디버깅할 때 대단히 유용하다.
- CamilleScholtz
나는 아직도 MCP를 이해하지 못하겠다? 스킬 + cli로는 못 하는 걸 MCP가 뭘 할 수 있나? 나는 hax(https://usehax.dev)를 쓰고 있는데, 솔직히 스킬이 전혀 그립지 않다.
- NichoPaolucci
pi가 MCP를 지원하지 않는다는 걸 전혀 몰랐다! 나는 신규 사용자이고, 막 이것저것 만져보기 시작했다. 툴링을 세팅하고 내 데이터베이스 MCP 중 하나를 작동시키려 했는데 (돌이켜 보면 좀 고통스러워 보였다 - 하지만 그 연결을 만들고 유지하는 건 내 책임이라고 생각했던 것 같다).
또 하나 돌이켜 보면, 'No MCP'가 그들 프런트 페이지의 첫 번째 아이콘인 것 같다 - 내가 어떻게 그걸 놓쳤는지 모르겠다.
이걸 읽고 얼마나 놀랐을지 상상해 보라!