MCP 서버를 5개 이상 연결하고 있다면, 지금 바로 읽어보세요.
전 세계에 MCP 서버를 배치한 마켓은 얼마나 될까요? William & Mary의 연구자들이 10월 4일 arXiv에 게시한 논문 「MCPacific」은 이 중 17곳의 정보를 통째로 모아 소스 코드까지 내려가 다시 세어보았습니다.
- 마켓에 게재된 총 개수는 41만 4,733건입니다. - 중복과 무효를 제외한 실체는 12만 4,267 서버입니다. - 그 소스에서 정적으로 추출한 도구 정의는 132만 8,233개입니다.
그리고 이 도구들을 기능별로 재분류하여 나온 답이 이것입니다.
Alternatives are the norm: 98.5% of tools have at least one functionally comparable alternative, and 74.1% have at least 20.
당신이 넣은 그 도구에는 거의 확실하게 대체재가 있습니다. 4개 중 3개는 대체재가 20개 이상 있습니다.
문제는 대체재들 간의 내용물이 통일되어 있지 않다는 것입니다. 같은 기능 그룹 안에 정적 분석 경고(warning)가 나오는 도구와 나오지 않는 도구가 섞여 있습니다. 같은 기능 쌍 중 41%는 코드 복잡도에 2.5배 이상의 차이가 납니다.
그리고 또 하나. 사용할 수 있는 도구 자체는 전혀 변하지 않았는데, 에이전트에게 보여주는 방식만 바꿨을 뿐인데 합격률이 최대 12포인트나 움직였습니다.
1. 새로운 MCP 서버를 넣기 전에, 같은 기능의 후보 3개를 나열하여 유지보수(maintenance), 경고(warning), 복잡도(complexity)로 선택해야 합니다.
논문에서 세밀하게 조사한 10개 그룹에서는 경고가 발생한 도구가 각 그룹의 11.1%~40.0%를 차지했지만, 어떤 그룹에서도 경고가 없는 대체재가 있었습니다.
2. 같은 도구라도 배열 방식에 따라 합격률이 달라집니다. 무작위로 도구 50개를 추가하자 평면적인 목록은 61%에서 54%로 떨어졌지만, 계층으로 필터링하는 방식은 66%를 기록했습니다.
GPT-5.6-Luna을 사용하여 MCP-Atlas의 100개 태스크를 풀게 한 결과, 도구 30개를 추가했을 때는 둘 다 64%로 차이가 없었습니다.
3. 다만, 4개 중 1개의 기능은 대체재가 없습니다. 게다가 당신이 매일 사용하는 서버는 조사 범위 밖에 있을 수도 있습니다.
분류된 기능의 24.80%는 도구가 단 하나만 발견되었으며, 소스 비공개 서버와 원격 전용 서버는 애초에 계산되지 않았습니다.
그림: 후보 도구에 무작위 도구를 추가했을 때의 합격률 (GPT-5.6-Luna, MCP-Atlas 100태스크). 논문의 표 6을 바탕으로 필자가 작성함
수치는 MCPacific 논문(arXiv:2610.05319. v1은 2026년 10월 4일, v2는 10월 8일. 모두 UTC)에 따른 것입니다. 논문에는 마켓에서 데이터를 수집한 날짜가 기재되어 있지 않으므로, 게재 수는 모두 논문이 취득한 시점의 값입니다. 각 마켓의 현재 표시 건수와 공식 레지스트리 검색 결과는 필자가 2026년 10월 19일에 확인한 것입니다. 경고 수치는 Semgrep이 제시한 '잠재적 문제(potential issue)'이며, 취약점으로 확인된 것은 아닙니다. 에이전트 실험은 100개 태스크였으며, 채점 역할의 GPT-5.4는 피험 모델 중 하나입니다. 필자는 논문의 실험을 재현하지 않았습니다.
| 항목 | 값 |
|---|
| 조사한 마켓 | 17곳 (미국 4, 캐나다 1, 유럽 3, 중국 6, 지역 미기재 3) |
| 게재 (생 데이터 → 유효) | 414,733건 → 368,754건 |
| 중복을 제외한 실체 | 124,267 서버 |
| 추출된 도구 정의 | 1,328,233개 (7개 언어, 110,482 프로젝트) |
| 기능 분류 | 18 영역, 잎 노드(leaf) 기능 58,915개 |
| 개발 외 영역의 도구 | 85% (소프트웨어 개발은 15.0%) |
| 대체재가 1개 이상 있는 도구 | 98.5% (20개 이상은 74.1%) |
| 대체재가 없는 기능 | 24.80% |
| Semgrep 경고가 발생한 도구 | 66,912개 중 1,044개 (1.56%) |
| 복잡도가 2.5배를 초과하여 다른 같은 기능 쌍 | 41.03% (86,387쌍 중) |
여기에 논문의 수치에서 필자가 계산한 두 가지를 추가했습니다.
유효한 게재 건수 368,754건을 고유한 서버 124,267개로 나누면 약 2.97가 됩니다. 즉, 하나의 서버가 평균적으로 거의 3개의 마켓에 올라와 있다는 계산입니다. 중국의 6개 마켓(mcpmarket.cn, MCP World, SCNet MCP, AIBase MCP, ModelScope, Tencent MCP)의 유효한 게재 건수를 합치면 206,035건으로, 전체 유효 게재 건수의 55.9%를 차지합니다. 한 곳에서 가장 많은 것은 mcpmarket.cn의 134,905건으로, 2위인 Glama(57,696건)보다 2배가 넘습니다.
여기까지는 'MCP 서버가 셀 수 없이 많다'는 이야기였습니다. 흥미로운 것은 그 다음입니다.
MCPacific의 파이프라인은 5단계로 이루어져 있습니다.
- 17개 마켓의 게재를 모으고, 접근할 수 없거나 비어 있거나 실행 가능한 소스가 없는 리포지토리를 제외합니다(414,733건 → 368,754건)
- 리포지토리 URL을 정규화하여 동일한 리포지토리를 가리키는 게재를 하나로 통합합니다(→ 124,267 서버)
- Python, TypeScript, JavaScript, Go, Rust, Java, C#의 7개 언어에 대해 구문 트리(syntax tree)에서 도구 등록 패턴을 찾아 각 도구의 진입 함수까지 해결합니다(110,482 프로젝트, 1,328,233 도구)
- 5,000개의 서버(75,365개 도구) 개발용 데이터로 GPT-5.6-Luna가 기능 분류 트리를 설계하게 합니다. 제1 계층은 18개 영역이며, 잎까지의 깊이 중앙값은 5~6입니다.
- 나머지 도구를 OpenAI의 text-embedding-3-small을 사용하여 분류 트리 잎에 할당합니다(대상 1,056,806개 중 90.19%가 잎에 도달)
같은 잎에 있는 도구들끼리가 '대체재'입니다. 샘플 검사에서는 도구 할당의 87.00%가 정확했고, 같은 잎 쌍의 85.00%가 기능적으로 비교 가능하다고 판정되었습니다.
분류해 보니 MCP의 중심은 이미 소프트웨어 개발에 있지 않습니다.
MCP has outgrown software development: 85% of tools serve other domains.
잎에 할당된 953,172개 도구 중 소프트웨어 개발이 143,202개(15.0%)로 가장 큰 영역입니다. 그럼에도 인프라(11.3%)와 비즈니스(11.0%)가 바로 뒤를 잇고 있으며, 금융, 미디어, 의료, 교육 분야까지 확장되어 있습니다.
| 관점 | 논문의 측정 방식 | 결과 |
|---|
| 경고 (Warning) | 7개 언어용 Semgrep 규칙 755개를 각 도구의 진입 함수에 적용 | 66,912개 중 1,044개(1.56%)에 총 1,874건. 89.22%가 입력 검증 (input validation) |
| 같은 기능 내 차이점 | 경고 종류가 모두 갖춰지도록 선택한 10개 그룹(79개 도구)을 정밀 분석 | 경고가 있는 비율은 각 그룹의 11.1~40.0%. 모든 그룹에 경고가 없는 대체재가 존재함 |
| 복잡성 (Complexity) | Lizard로 진입 함수의 CCN(순환적 복잡도, Cyclomatic Complexity)을 측정하고, 같은 잎・같은 언어・다른 리포지토리 쌍을 비교 | 86,387쌍의 41.03%에서 2.5배가 넘는 차이 |
| 유지보수 (Maintenance) | 아카이브되지 않았고, 가져오기 전 180일 이내에 푸시가 있었는지 여부 | 60.38%의 그룹에서 작동하는 후보와 멈춘 후보가 공존함 |
경고 내역을 분류하면 입력 검증이 89.22%, 통신 보호(communication protection)가 2.56%, 리소스 관리(resource management)가 1.33%, 인증 정보 노출(credential exposure)이 1.23%, 접근 제어(access control)가 0.16%, 인증(authentication)이 0.11%, 기타가 5.39%입니다. 거의 전적으로 입력 검증에 관한 것입니다.
논문에서 제시하는 구체적인 예시는 크로마틴 가용성 분석(chromatin accessibility analysis, 게놈 분석의 일종) 그룹입니다. 3개의 도구가 입력 검증으로 경고를 받았는데, 그중 2개는 검증하지 않은 입력을 그대로 서브 프로세스 호출에 전달하고 있었습니다. 그럼에도 불구하고 같은 기능 안에 경고가 없는 도구가 있었습니다. 논문의 표현은 다음과 같습니다.
in every examined group, users could choose an alert-free tool with the same functionality.
선택 방식 하나만으로 경고를 피할 수 있었습니다.
1.56%라는 전체 숫자는 작게 보일 수 있습니다. 하지만 경고 종류가 모두 갖춰지도록 선택한 10개 그룹 중에서는, 경고가 있는 도구가 최대 40%를 차지했습니다. 전체 평균이 낮다는 것과 자신이 고른 것이 안전하다는 것은 별개의 문제입니다.
한편, 분류된 기능의 24.80%는 도구가 하나만 발견되었다(논문 본문의 건수 표기는 잎의 총 개수인 58,915로 되어 있어, 비율로부터 역산하면 약 14,600개이다. 건수는 오기인 것으로 보인다). 논문이 제시하는 예시는 암호 증명(Cryptographic Proofs)이나 발음사전 관리이다.
의외인 점은 그 하나의 기능을 지탱하는 리포지토리 쪽이 더 활발하다는 것이다. 90일 이내에 push가 있었던 비율은 47.50%(대체재가 있는 기능에서는 39.26%)였고, 조직이 보유한 리포지토리의 비율은 18.83%(동일 14.61%)였다. 논문은 대체재가 없다고 해서 리포지토리가 약한 것은 아니라고 결론짓는다. 참고로, 스타 수의 중앙값은 2(동일 1)였다.
MCP 서버의 리포지토리는 스타 1~2가 기본인 세계다.
논문의 마지막 실험(RQ4)은 이 분류 트리가 실제 에이전트에게 유용한지를 측정하고 있다.
- 벤치마크는 MCP-Atlas이다. 실존하는 36개의 MCP 서버와 220개의 도구를 사용하는 1,000개 태스크의 벤치마크로, 답이 충족해야 할 사실(claim)을 얼마나 많이 만족시켰는지로 채점한다.
- 이 중 공개된 100개 태스크를 사용한다. 태스크당 후보 도구는 평균 15.37개(최소 7, 최대 30)이다.
- 비교하는 것은 제시 방식만이다. 후보를 평평한 목록 그대로 제공하는 방식과, 분류 트리에서 해당 태스크용 부분 트리를 잘라내어 루트부터 관련성이 높아 보이는 가지들만 따라 선택하게 하는 방식(MCPacific). 사용 가능한 도구는 둘 다 동일하다.
- 지표는 [email protected](claim의 75% 이상을 만족시킨 태스크의 비율)이며, 채점 담당은 GPT-5.4이다.
논문은 MCPacific 방식의 선택 과정을 다음과 같이 설명한다.
Starting at the root, the model retains clearly or potentially relevant branches and expands only those branches.
이를 의사 코드로 나타내면 다음과 같다.
# 필자가 논문의 설명을 의사 코드로 만든 것(미실행)
def reach_tools(task, node, llm):
if node.is_leaf():
...
먼저, 원래 후보 그대로의 결과이다.
| 모델 | 평평한 목록 | 계층으로 좁히기 | 차이 |
|---|
| GPT-5.6-Luna | 61% | 70% | +9 |
| ... | | | |
| 4개 모델 모두 상승했지만, 폭은 1~9 포인트로 다양하다. | | | |
그렇다면 여기에 무작위 도구를 30개, 50개 섞으면 어떻게 될까?
먼저 예상한 후, 아래 표를 봐주세요.
여러분의 예상도 댓글로 알려주시면 좋겠습니다.
| 후보 (GPT-5.6-Luna) | 평평한 목록 | 계층으로 좁히기 | 차이 |
|---|
| 원래 후보 (평균 15.37개) | 61% | 70% | +9 |
| ... | 66% | | +12 |
50개를 추가하자, 평평한 목록은 61%에서 54%로 7 포인트 하락했다. 계층으로 좁히는 방식도 70%에서 66%로 하락했지만, 하락 폭은 4 포인트에 그쳤고, 차이는 12 포인트로 벌어졌다. 논문은 이를 Finding 10으로 정리하고 다음과 같이 요약한다.
MCPacific is more robust when the candidate-tool space becomes crowded.
정말로 그럴까? 30개를 추가한 조건에서는, 평평한 목록이 오히려 61%에서 64%로 상승했고, 둘은 64%로 나란히 했다. 만족시킨 claim의 평균(mean claim coverage)으로 보면, 이 조건에서는 계층으로 좁히는 방식이 0.67 포인트 낮다. 100개 태스크 실험에서는 1개 태스크가 1 포인트에 해당하므로, 몇 포인트 차이는 몇 개 태스크의 출입으로 움직인다.
여기서 필자의 단순 계산을 하나 한다. 논문 데이터로는 프로젝트당 도구가 평균 약 12.0개(1,328,233 ÷ 110,482)이다. MCP 서버를 5개 연결하면 약 60개가 되고, 50개 추가 조건(평균 약 65개)에 가까워진다. 실제로 연결되는 도구는 무작위가 아니므로, 어디까지나 대략적인 참고치일 뿐이다.
솔직히 말해서, 이 실험은 100개 태스크에서 변동 보고가 없고, 추가된 도구의 출처도 기재되어 있지 않으며, 분류 트리를 설계한 모델과 가장 성능이 좋았던 모델 모두 GPT-5.6-Luna이기 때문에, 12 포인트는 '경향'으로 읽는 것이 정확하다.
연결된 서버마다 MCP Inspector의 CLI 문서에 있는 방법으로 도구 목록을 가져온다(Node.js 22.19.0 이상 필요).
stdio로 동작하는 서버
npx @modelcontextprotocol/inspector --cli node build/index.js --method tools/list --format json
원격 서버 (Streamable HTTP)
...
모든 서버의 합계가 논문의 원래 후보(평균 15.37개)의 3배, 4배가 되어 있지 않은지 확인하는 것.
공식 MCP Registry는 API 문서에 있는 search
(서버 이름 부분 일치)와 version=latest
로 동일한 기능을 가진 후보를 목록화할 수 있다.
# 이름에 filesystem을 포함하는 서버의 최신 버전만 가져오기
curl -s 'https://registry.modelcontextprotocol.io/v0.1/servers?search=filesystem&version=latest&limit=20'
계속해서, 응답의 metadata.nextCursor를 cursor 파라미터에 전달하여 페이지를 전송한다. 필자가 10월 19일에 limit=5로 시도했을 때는, com.pulsemcp/remote-filesystem나 io.github.bytedance/mcp-server-filesystem 등 작성자가 다른 5건이 반환되었고, 아직 더 이어지는 것이 있었다.
후보 리포지토리를 파악했다면, GitHub CLI의 gh api로 최종 push와 아카이브 상태를 가져온다. 논문의 '유지 관리됨' 정의(아카이브되지 않았고 180일 이내에 push가 있는 경우)를 그대로 직접 적용할 수 있다.
gh api repos/OWNER/REPO --jq '{pushed_at, archived, stargazers_count}'
스타 수는 참고용으로 충분하다. 이전 장에서 봤듯이 중앙값은 1~2 수준이다.
논문과 같은 도구가 손안에서도 사용 가능하다. 경고는 Semgrep (CLI Reference), 복잡도는 Lizard를 사용한다.
# 후보 리포지토리를 손에 두고 나서
semgrep scan --config p/default --json ./candidate-a > candidate-a.json
pip install lizard
...
논문이 사용한 것은 Semgrep의 규칙 755개로, p/default와는 같지 않다. 레지스트리에서 규칙을 가져올 경우, 기본적으로 익명의 이용 통계가 전송된다 ( --metrics off로 중단 가능). Lizard는 함수별로 NLOC(주석 제외 라인 수)과 CCN을 출력하므로, 도구의 진입점 함수들을 나란히 비교할 수 있다.
논문의 17개 마켓에 게재된 건수는 414,733건이었지만, 고유한 서버는 124,267개로 약 3할밖에 되지 않는다. 마켓별로 보면, 유효성 검사(validity check)를 통과한 게재는 Smithery에서 10,338건 중 2,906건 (28.1%)이었고, 체코의 AgentForge에서는 15,049건 중 57건 (0.38%)이었다. 논문에서 가장 큰 mcpmarket.cn(생 데이터 137,327건)도 필자가 10월 19일에 본 메인 페이지 헤드라인은
필자가 얻은 결과는 이름순으로 나열되어 있으며, 1페이지는 io.github.207studio/chalkieboard-icloud-mcp로 끝났다.
GitHub용 서버를 찾고 싶은데도 네임스페이스가 같기만 한 서버에 파묻혀 버린다.
대책: 검색(search)에는 기능을 나타내는 단어(filesystem이나 postgres 등)를 넣고, github처럼 네임스페이스와 겹치는 단어는 피할 것. 문서 자체에서도 고급 검색이나 필터링은 서브 레지스트리(sub-registry)에 맡긴다고 적혀 있다.
논문 자체가 경고를 확정된 문제라기보다는 잠재적인 문제로 다루고 있다.
we interpret these alerts as potential, rather than confirmed, issues
게다가 Semgrep도 복잡성 측정 시 각 도구의 진입 함수(entry function)만 보고 있다. 경고 집계에 사용된 측정치는 66,912개 도구분이며, 소스 비공개 서버와 원격 전용 서버는 처음부터 대상에서 제외되었다.
당신이 사용하는 호스트형 원격 서버에 대해서는 이 자(物差し)로는 아무것도 알 수 없다.
대책: 경고는 '후보들끼리 비교할 자료'로 사용할 것. 소스가 보이지 않는 원격 서버는 요구하는 권한(OAuth의 스코프 등)과 제공처로 판단할 것.
같은 잎 쌍 중에서 기능적으로 비교할 수 있다고 판정된 것은 85.00%였다. 역으로 말하면, 15%는 같은 선반에 있어도 내용물이 다르다. 도구 할당 자체도 정확했던 것이 샘플의 87.00%에 불과하다.
카테고리만 보고 갈아타면 인자(argument) 형태가 달라서 워크플로우가 멈출 수도 있다.
대책: 갈아타기 전에 양쪽의 tools/list를 모두 내보내서 입력 스키마(인자의 이름・형태・필수 항목)를 나란히 놓고 비교할 것.
30개 조건을 추가해도 차이가 0이었고, 원래 후보군에서도 GPT-5.6-Terra는 1포인트밖에 오르지 않았다. 채점 역할을 하는 GPT-5.4가 피험 모델을 겸하고 있다는 점은 논문도 타당성 측면의 위협으로 인정하고 있다. 게다가 필자가 덧붙이자면, 분류 트리를 설계한 것은 가장 많이 오른 GPT-5.6-Luna 그 자체이다.
12포인트를 기준으로 자신의 도구 구성을 다시 짜더라도 같은 성장이 나올 것이라고는 할 수 없다.
대책: 도구를 좁히기 전과 후로, 자신의 대표적인 작업을 동일한 개수만큼 흘려보내고 성공한 수를 비교할 것.
| 찾기 장소 | 논문 취득 시 (원시 → 유효) | 유효 비율 | 10월 19일 표시 건수 |
|---|
| 공식 MCP Registry | 조사 대상 아님 | 없음 | 총 개수 미표시 (프리뷰 버전) |
| Glama | 61,213 → 57,696 | 94.3% | 104,869건 |
| MCP Market | 30,136 → 28,409 | 94.3% | 49,888건 |
| Smithery | 10,338 → 2,906 | 28.1% | 27,365건 이상 |
| PulseMCP | 22,021 → 21,355 | 97.0% | 21,678건 |
| mcp.so | 17,858 → 15,922 | 89.2% | 총 개수 미표시 |
유효 비율은 유효 ÷ 원시 데이터로 필자가 계산한 것이다. 10월 19일 건수는 각 사이트의 표시이며, 세는 방식이 사이트마다 다르다.
**표에서 읽을 수 있는 것: **
Glama의 표시 건수는 논문의 취득 시점 대비 약 1.7배이다. 논문은 취득일을 적지 않았기 때문에 증가 속도는 알 수 없다. 마켓의 건수는 언제의 숫자인지와 함께 읽어야 한다. -
Smithery는, 논문의 유효성 체크를 통과한 게재가 28.1%밖에 되지 않는다. 리포지토리를 따라 실행할 수 있는 소스를 확인할 수 있었던 게재가 3할에 미치지 못했다는 뜻이다. -
공식 MCP Registry는, 논문에서 언급된 17곳에 포함되어 있지 않다. 이유는 논문에 쓰여있지 않다. README가 설명하는 확인은 네임스페이스 소유이며, 보안 심사에 대해서는 아무것도 쓰여있지 않다. -
보전을 평가로 제시했던 곳은, 6곳 중 Glama뿐이었다. 어디서 찾아봐도 결국 이전 장의 3과 4, 즉 직접 손으로 체크해야 한다.
후보를 결정하면 에이전트에게 보여주는 도구 자체를 줄인다. OpenAI Agents SDK에는 문서의 Tool filtering에 이런 예시가 있다(필자는 실행하지 않음).
from pathlib import Path
from agents.mcp import MCPServerStdio, create_static_tool_filter
samples_dir = Path("/path/to/files")
...
허용 목록(allow list)과 차단 목록(block list)을 병행 사용할 수 있으며, 허용 목록을 먼저 적용한 후 차단된 도구를 제외한다. OpenAI의 Responses 모델에 한해서는 defer_loading 기능과 ToolSearchTool로 도구를 나중에 로드시키는 방법도 있다. 둘 다 논문의 '계층으로 좁히기'와는 다른 방식이며, 에이전트가 한 번에 볼 수 있는 후보의 수를 그 자체로 줄인다.
✗ "공식 레지스트리에 올라있다 = 검증됨" → README에 적힌 확인은 이름 공간 소유권만 해당
✗ "게재가 많을수록 선택지가 많다" → 41.5만 건의 게재로 실제는 12.4만 서버임
✗ "같은 기능이라면 뭘 골라도 똑같다" → 같은 기능 쌍의 41%에서 복잡도가 2.5배를 초과하여 다름
...
MCP가 확산된 것 자체는 좋은 소식이다. 도구의 85%가 개발 외 영역에 있으며, 98.5%는 대체재가 있다. 이제 '대응하는 서버가 있는지 여부'로 고민할 단계가 아니다.
다만, 선택지가 많아질수록 고르지 않는 사람만 손해를 본다. 같은 기능 안에 경고가 있는 것과 없는 것, 작동하는 것과 멈춘 것이 나열되어 있고, 후보가 뒤섞이면 에이전트의 합격률도 흔들린다. 오늘 연결하고 있는 MCP 서버 중 하나를 골라, 같은 기능의 후보 3개를 나란히 놓고 최종 푸시와 경고 개수를 비교해 보길 바란다.
Understanding the Hierarchical Structure and Functional Landscape of the Model Context Protocol Ecosystem（MCPacific）- arXiv:2610.05319
동 논문의 HTML 버전(v2) - arXiv
MCP-Atlas: A Large-Scale Benchmark for Tool-Use Competency with Real MCP Servers - arXiv:2602.00933
MCP Registry（README）- GitHub
Official Registry API - modelcontextprotocol/registry
Generic Registry API - modelcontextprotocol/registry
MCP Inspector（README）- GitHub
MCP Inspector CLI smoke testing - GitHub
CLI reference - Semgrep Docs
Lizard（README）- GitHub
gh api - GitHub CLI Manual
Model context protocol (MCP) - OpenAI Agents SDK
Open-Source MCP Servers - Glama
MCP Servers - PulseMCP
Smithery
MCP Market
mcp.so
이 글이 도움이 되었다면, 좋아요와 저장 바랍니다! 마켓에서 MCP 서버를 하나씩 모으고 있는 동료에게도 공유해 주었으면 합니다.
댓글로 알려주세요.
당신의 에이전트에는 지금 도구가 몇 개 보이나요? 15개 이내? 50개 이상?
- MCP 서버를 고를 때 가장 보는 것은 무엇인가요? 공식 여부, 별점 수, 최종 업데이트 날짜, 아니면 후기?
- '배열 방식에 따라 12포인트'라는 것을 믿나요? 아니면 오차라고 생각하나요?
