MCP 서버를 하나 더 붙이면 에이전트가 더 똑똑해질까.
초반엔 거의 다 그렇게 느껴진다.
연결할 수 있는 서비스가 늘고, 도구 목록이 길어지고, 설정 화면이 풍성해지면 왠지 시스템이 강해진 것 같아 보인다.
근데 운영은 종종 반대로 간다.
연결 수가 늘수록 실패 지점도 늘고, 권한 경계도 흐려지고, 누가 어떤 도구를 왜 남겼는지 설명할 수 없는 상태가 빨리 온다.
특히 2026년 4월의 MCP 생태계는 “서버를 더 붙이는 법”보다 “어떤 서버를 남기고 어떤 서버를 지울지” 먼저 정하는 편이 낫다.
공식 흐름도 이쪽으로 기울고 있다.
2026-04-14 기준 modelcontextprotocol/servers README는 이 저장소를 방대한 생산용 서버 모음집이 아니라, reference implementations 와 커뮤니티 리소스 참조 모음으로 설명한다.
게다가 같은 README는 이 저장소가 스티어링 그룹이 관리하는 “소수의 reference servers”를 담는 곳이라고 못 박는다.
그리고 더 중요한 문장도 있다.
이 서버들은 production-ready solutions가 아니며, 각 팀은 자기 위협 모델과 보안 요구사항에 맞춰 직접 safeguards를 설계해야 한다는 경고다.
여기서 게임이 끝난다.
README 길이가 길다고 해서 바로 production 후보 목록이 되는 게 아니라는 뜻이기 때문이다.
이 글은 공식 servers README가 지금 실제로 뭐라고 말하는지, 왜 registry와 reference repo를 혼동하면 안 되는지, 그리고 내 기준으로는 어떤 서버를 먼저 덜어내야 하는지 정리한 운영 메모다.
먼저 한 줄 판단
MCP 운영에서 제일 먼저 늘려야 하는 건 연결 수가 아니라 삭제 기준이다.
서버 하나를 더 붙이기 전에 다음 질문에 답이 안 나오면 일단 보류하는 편이 낫다.
- 이 서버는 누가 소유하나
- 실패하면 어디서 티가 나나
- 권한 범위가 어디까지인가
- 같은 역할을 하는 다른 도구와 왜 둘 다 필요한가
- 이 도구가 없어졌을 때 무엇이 실제로 깨지나
이 다섯 개가 흐리면 그 서버는 기능보다 소음이 될 가능성이 높다.
2026년 4월 공식 문서가 바뀐 포인트
이번 글에서 제일 중요한 팩트부터 적자.
modelcontextprotocol/servers README 상단에는 이미 이런 구조가 드러나 있다.
- published servers 목록은 registry에서 보라고 한다
- 이 repo는 소수의 reference servers용이라고 적는다
- reference implementations이지 production-ready solutions가 아니라고 경고한다
- README 안의 server lists는 더 이상 유지되지 않고 eventually removed 된다고 적는다
이 네 줄만 읽어도 운영 기준이 꽤 달라진다.
예전엔 README 스크롤 길이가 일종의 생태계 지도처럼 보였을 수 있다.
지금은 아니다.
지금은 오히려 공식 repo와 registry의 역할을 분리해서 봐야 한다.
쉽게 말하면 이렇다.
- 공식 repo: reference, 예제, SDK usage, 구조 이해
- registry: published servers 탐색
- production 채택: 우리 권한 모델과 운영 기준으로 별도 판단
이 차이를 안 나누면 참고용 서버를 운영용처럼 받아들이거나, 커뮤니티 서버를 바로 표준으로 오해하는 문제가 생긴다.
reference와 production을 헷갈리면 왜 바로 힘들어지나
reference server는 교육용으로는 매우 좋다.
무엇을 보여주려고 만든 도구인지가 선명하고, 프로토콜 기능 이해에도 좋다.
문제는 그걸 바로 조직 공용 서버로 받아들일 때 생긴다.
reference 구현은 종종 이걸 전제로 하지 않는다.
- 복잡한 권한 통제
- 세밀한 감사 로그
- 팀별 운영자 인수인계
- 장애 복구 루프
- 장기 유지보수
공식 README도 이 부분을 대신 보장하지 않는다고 말한다.
그래서 실무자는 기능 개수보다 먼저 운영 질문을 던져야 한다.
되냐 보다 남겨도 되냐 가 먼저다.
내가 지금 남기고 싶은 기준은 다섯 가지다
내 기준은 크게 다섯 개다.
멋있어 보이는 기능보다 이 다섯 개를 통과하는지가 더 중요하다.
1. 역할이 겹치지 않아야 한다
가장 먼저 지우는 대상은 역할이 겹치는 서버들이다.
예를 들면 이런 경우다.
- 웹 fetch도 하고 검색도 하는 서버가 둘 이상 있다
- 파일 읽기와 쓰기를 여러 서버가 중복 제공한다
- 내부 API wrapper와 generic HTTP server가 같은 결과를 낸다
- MCP server와 shell wrapper가 똑같은 보고서를 만든다
이런 중복은 처음엔 백업처럼 느껴진다.
근데 시간이 지나면 정반대로 간다.
어느 도구가 정답 경로인지 매번 판단해야 하고, 문서도 두 벌이 되고, 문제 생기면 원인 추적도 두 갈래가 된다.
도구 다양성은 정말 필요한 곳에만 써야 한다.
2. 실패가 눈에 보여야 한다
좋은 서버는 성공할 때보다 실패할 때 더 선명하다.
내가 남기고 싶은 서버는 실패 시점이 분명해야 한다.
- 권한 오류가 명시적으로 뜨는가
- 호출 로그가 남는가
- timeout이 드러나는가
- 입력 validation이 있는가
- 결과가 비어 있을 때 조용히 성공 처리하지 않는가
이 기준이 약하면 에이전트가 “어쨌든 뭔가 했다”고 말하고, 운영자는 뒤늦게 실제 산출물이 없다는 걸 발견한다.
그건 도구가 아니라 마술 상자다.
마술은 공연장에선 좋지만 운영 환경에선 혈압약이 된다.
3. 권한 경계가 설명 가능해야 한다
파일 시스템, 브라우저, Git, 내부 API, 캘린더, 메일, 프로덕션 DB.
이런 자원은 각각 리스크가 다르다.
그런데 MCP 서버를 붙이다 보면 “연결됐다”는 사실만 보고 권한 설명은 뒤로 밀리기 쉽다.
남길 서버는 반드시 설명할 수 있어야 한다.
- 읽기 전용인가
- 쓰기까지 가능한가
- 삭제/변경이 가능한가
- 네트워크 바깥으로 나가는가
- 사용자별 범위 제한이 가능한가
이 설명이 흐리면 팀 공용 운영 도구로는 이르다.
4. 소유자가 있어야 한다
진짜 별거 아닌 것 같지만 운영을 가장 많이 망치는 질문이 이거다.
이거 누가 관리해?
답이 “다 같이” 이거나 “일단 붙여둔 사람이 아마” 면 사실상 무주공산이다.
서버는 이름보다 소유자가 먼저 있어야 한다.
소유자가 있으면 업데이트도 되고, 로그도 보고, 장애 시 대응도 된다.
소유자가 없으면 설정은 남아도 신뢰는 빨리 증발한다.
5. 삭제했을 때 진짜 깨지는 것이 있어야 한다
이건 역으로 보는 기준이다.
서버를 지워도 아무 산출물도 안 깨지고, 아무 워크플로도 안 멈춘다면, 그건 이미 도구 목록만 차지하고 있을 가능성이 높다.
나는 이 테스트를 꽤 좋아한다.
이 도구를 오늘 빼면 누가 내일 불편해지나
여기에 답이 없으면 과감하게 덜어낼 이유가 충분하다.
공식 repo를 보면 오히려 기본 서버 수는 적다
2026-04-14 기준 공식 reference servers 목록은 놀랄 만큼 소박하다.
- Everything
- Fetch
- Filesystem
- Git
- Memory
- Sequential Thinking
- Time
이 목록이 주는 메시지는 꽤 분명하다.
공식 팀도 “많이 붙이는 것”보다 프로토콜 기능을 대표하는 최소 세트를 유지하는 쪽을 택하고 있다는 뜻이다.
반대로 archived 항목도 눈에 띈다.
README에는 기존 reference servers 중 일부가 servers-archived로 이동했다고 적혀 있다.
Brave Search, GitHub, Google Drive, Puppeteer, SQLite 같은 항목들이 대표적이다.
이 장면이 시사하는 건 단순하다.
MCP 생태계는 계속 커지지만, 공식 reference repo는 오히려 수렴하고 있다는 점이다.
즉, 운영자는 더 붙이는 속도보다 덜어내는 기준을 먼저 배워야 한다.
README 길이로 서버를 고르면 안 되는 이유
README 안에는 엄청 많은 third-party servers가 나온다.
근데 거기에도 중요한 경고가 붙어 있다.
The server lists in this README are no longer maintained and will eventually be removed.
이 문장은 꽤 세다.
실무 해석은 이렇다.
- README는 영구 기준서가 아니다
- 커뮤니티 리스트는 빠르게 낡을 수 있다
- 어떤 서버가 실제로 살아 있고 믿을 만한지는 별도 검증이 필요하다
- “공식 README에 있었으니 안전하다”는 논리는 성립하지 않는다
이 포인트 하나만 알아도 온보딩 문서가 많이 달라진다.
팀 문서에 “README에서 본 서버 후보들” 을 그대로 복붙하는 대신, registry 링크와 우리 승인 기준을 같이 적어야 한다.
그래서 registry를 어떻게 봐야 하냐
registry는 발견 단계엔 좋다.
하지만 채택 단계까지 자동으로 해결해주진 않는다.
내가 보는 순서는 이렇다.
- registry에서 후보를 찾는다
- 공식 문서와 repo 활동성을 본다
- 권한 범위를 확인한다
- 로컬 또는 스테이징에서 실패 시나리오를 본다
- owner와 삭제 조건을 문서화한다
즉, registry는 쇼핑몰이 아니라 후보 카탈로그에 가깝다.
카탈로그에서 본 물건을 집 구조도 안 보고 들이는 건 언젠가 현관문에 낀다.
내 워크플로에서 실제로 오래 남는 건 어떤 서버였나
최근 몇 주 동안 Obsidian, 블로그 파이프라인, 코드 작업, 리서치 흐름을 굴리면서 느낀 건 정말 오래 남는 도구는 화려한 쪽이 아니었다.
오히려 이런 종류가 오래 남는다.
- 역할이 한 줄로 설명되는 서버
- 출력이 눈에 보이는 서버
- 실패가 조용하지 않은 서버
- 셸보다 분명히 얻는 이득이 있는 서버
반대로 빨리 피곤해지는 건 이런 쪽이었다.
- 범용적인데 실제로는 아무도 끝까지 관리하지 않는 서버
- 같은 역할의 도구를 여러 개 겹쳐둔 구성
- 에이전트가 호출은 하는데 사람은 결과를 신뢰하지 못하는 서버
- 권한 경계가 애매한 서버
그래서 지금 내 기본 감각은 덜 연결된 시스템이 더 오래 간다 에 가깝다.
이건 반기술주의가 아니다.
오히려 운영주의다.
내가 지금 시작한다면 남길 기본 세트
완전히 처음부터 다시 시작한다면 일단 이런 축만 남길 거다.
1. Filesystem 계열
파일 읽기와 쓰기는 에이전트 워크플로에서 제일 자주 닿는다.
대신 범위를 아주 좁게 가져가야 한다.
무한 파일 접근은 편해 보이지만 운영 문서 관점에선 설명이 어렵다.
2. Git 계열
코드와 문서를 같이 만지는 팀이라면 Git 읽기와 검색은 효용이 크다.
단, 쓰기와 push 권한은 읽기와 분리해서 생각하는 편이 낫다.
3. Fetch 계열
웹 문서나 외부 콘텐츠를 텍스트로 읽어와야 할 때는 좋은 기본 도구가 된다.
하지만 이미 브라우저 자동화나 별도 scraper가 있으면 중복을 먼저 의심해야 한다.
4. Time 계열
사소해 보이지만 날짜와 타임존은 자주 사고를 낸다.
상대 날짜 해석을 줄이는 도구는 생각보다 운영에 도움이 된다.
5. Memory는 정말 필요한 경우에만
지속 메모리가 유용한 워크플로는 분명 있다.
다만 여기서는 “있는 게 멋있어서” 붙이면 안 된다.
메모리 저장 기준, 삭제 기준, 회수 기준이 없는 memory는 금방 잡동사니 서랍이 된다.
6. Sequential Thinking은 실험용으로 분리
사고 과정을 구조화하는 데 도움은 될 수 있다.
다만 이것도 production flow보다 실험 구역에 두는 편이 낫다.
모든 세션에 기본 탑재하면 오히려 출력이 무거워질 수 있다.
반대로 먼저 지울 후보들
이제 진짜 중요한 쪽이다.
내가 가장 먼저 정리할 후보는 이런 서버들이다.
후보 1. 같은 데이터를 다른 경로로 가져오는 중복 서버
예를 들어 웹 검색, 웹 fetch, 브라우저 자동화, 문서 크롤러가 모두 비슷한 결과를 가져온다면, 초반엔 풍부해 보이지만 나중엔 지옥문이 열린다.
어떤 결과가 authoritative한지 매번 따져야 하기 때문이다.
후보 2. 팀에 owner가 없는 “좋아 보여서 붙인” 서버
가장 흔하다.
데모 때 박수받고, 한 주 지나면 아무도 안 본다.
이런 서버는 기술 문제가 아니라 운영 문제다.
후보 3. reference와 production 경계가 흐린 서버
예제 구현을 그대로 프로덕션 안전판처럼 취급하는 순간, 보안 검토와 장애 대응이 비어 버린다.
README의 경고를 문자 그대로 받아들이는 편이 낫다.
후보 4. 입력은 쉬운데 출력 검증이 없는 서버
호출은 된다.
근데 결과가 신뢰 가능한지 사람이 빠르게 판단할 방법이 없다.
이런 서버는 생성량은 늘리지만 검수량도 같이 폭증시킨다.
후보 5. 셸 스크립트보다 이득이 명확하지 않은 서버
이건 정말 중요하다.
MCP라는 이유만으로 셸보다 우위가 생기지 않는다.
입력 스키마, 재사용성, 여러 클라이언트 공유, 권한 추상화 같은 이득이 없으면 얇은 셸 wrapper가 더 낫다.
이 판단은 Claude Code MCP vs script 2026 — 내부 도구 연결할 때 언제 커스텀 툴이 과하고 언제 셸이면 충분할까 와 거의 같은 문제다.
얇은 wrapper가 더 나은 순간
MCP를 덜 쓰자는 말은 아니다.
대신 이런 경우엔 CLI wrapper가 먼저일 가능성이 높다.
- 호출 주체가 사실상 한 팀뿐이다
- 입력 구조가 단순하다
- 실패 시 사람이 바로 재실행할 수 있다
- 결과 저장 위치가 명확하다
- 표준화보다 속도가 중요하다
이럴 땐 wrapper 하나가 MCP 서버보다 운영이 쉽다.
특히 문제의 본질이
브라우저에서 반복 프롬프트를 저장해 다시 쓰는가
수준이면
MCP보다
Gemini in Chrome Skills 2026 — 반복 프롬프트를 one-click workflow로 바꿀 때 먼저 정할 5가지
처럼 더 얇은 레이어를 먼저 보는 게 낫다.
반대로
MCP도 붙이고,
세션도 이어가고,
권한 승인과 서브에이전트까지 런타임에서 묶고 싶다
수준이면
OpenHarness를 언제 도입하고 언제 과한가 2026 — 세션·도구구조·운영비용 체크리스트
같이 한 단계 위 하네스 관점이 필요해진다.
반대로 MCP가 확실히 빛나는 경우도 있다.
- 여러 클라이언트가 같은 도구를 써야 한다
- 입력과 출력 스키마를 일관되게 유지해야 한다
- 권한 범위를 레이어로 관리해야 한다
- 팀 단위 재사용성이 중요하다
- 장기적으로 도구 카탈로그화할 계획이 있다
즉, 선택 기준은 멋짐이 아니라 운영 범위다.
MCP를 붙이기 전 체크리스트
나는 지금 이 체크리스트를 먼저 본다.
운영
- owner가 정해져 있나
- 장애 시 연락할 사람이 있나
- 버전 업데이트 주기를 설명할 수 있나
권한
- 읽기 전용인지 쓰기 가능인지 분명한가
- 삭제나 외부 전송이 가능한가
- 사용자/환경별 범위 제한이 가능한가
관측성
- 호출 로그가 남는가
- 실패가 사용자에게 보이는가
- timeout과 validation 오류가 구분되는가
산출물
- 출력 위치가 정해져 있나
- 성공 기준이 명확한가
- 사람이 빠르게 검수할 수 있나
삭제 가능성
- 이 서버를 뺐을 때 어떤 흐름이 깨지는가
- 대체 경로가 있는가
- 중복 도구와 역할을 구분할 수 있는가
다섯 칸 중 두세 칸만 비어도 나는 바로 보류 쪽으로 간다.
실수 TOP
실수 1. registry에 있으면 곧바로 믿을 만하다고 생각한다
registry는 발견 도구다.
운영 보증서가 아니다.
실수 2. reference repo를 production shortlist로 쓴다
공식 README는 이미 그걸 경계하라고 말한다.
reference는 reference로 봐야 한다.
실수 3. 도구가 많아질수록 에이전트가 똑똑해진다고 믿는다
실제론 종종 선택 비용과 오류 비용이 같이 올라간다.
실수 4. owner 없이 팀 공용 설정에 넣는다
이건 거의 예약된 기술 부채다.
실수 5. 삭제 기준 없이 추가만 한다
추가 기준보다 삭제 기준이 없을 때 스택이 제일 빨리 썩는다.
언제 이 선택이 맞고 언제 아닌가
MCP를 적극적으로 붙이는 선택이 맞는 경우는 이렇다.
- 도구를 여러 클라이언트가 공유해야 한다
- 입력/출력 인터페이스를 표준화할 이유가 크다
- 권한 계층을 분리해서 관리해야 한다
- 팀 차원의 운영 문서와 owner 체계가 있다
- 장기적으로 에이전트 툴카탈로그를 만들 생각이다
반대로 신중해야 하는 경우는 이렇다.
- 아직 문제 정의가 자주 바뀐다
- 사실상 한 명만 쓰는 자동화다
- 셸과 스크립트로 충분하다
- 출력 검증이 약하다
- owner가 없다
- reference 예제를 그냥 옮겨오려 한다
FAQ
MCP 서버는 많을수록 좋은 거 아냐?
꼭 그렇지 않다.
역할이 겹치고 owner가 없고 삭제 기준이 없으면 연결 수는 바로 운영 부담으로 바뀐다.
공식 servers repo에 있으면 프로덕션에 바로 써도 돼?
그렇게 보면 안 된다.
2026-04-14 기준 공식 README도 이 저장소의 서버들을 reference implementations로 설명하고, production-ready solutions가 아니라고 경고한다.
registry와 servers repo는 뭐가 달라?
간단히 말하면 registry는 published servers를 찾는 곳이고, servers repo는 소수의 reference servers와 관련 리소스를 보여주는 곳이다.
역할이 다르다.
README에 있는 third-party servers 목록은 믿어도 돼?
후보를 찾는 데는 쓸 수 있다.
하지만 README 자체가 그 목록이 더 이상 유지되지 않으며 언젠가 제거될 예정이라고 적고 있다.
즉, 그 자체를 장기 기준서로 쓰면 안 된다.
MCP보다 셸 wrapper가 나은 경우도 정말 많아?
많다.
입력이 단순하고, 한 팀만 쓰고, 출력 위치가 명확하고, 재사용성 요구가 낮다면 얇은 wrapper가 훨씬 관리하기 쉽다.
Memory 서버는 꼭 필요한가?
필수는 아니다.
지속 메모리가 명확한 가치가 있는 흐름에만 붙이는 편이 낫다.
기준 없이 붙이면 메모리보다 잡동사니 저장소가 되기 쉽다.
어떤 서버부터 남기는 게 좋아?
내 기준에선 Filesystem, Git, Fetch, Time처럼 역할이 선명하고 설명이 쉬운 축부터 남기는 편이 낫다.
그다음에만 메모리나 추론 보조 계열을 검토한다.