MCP가 9,400개를 넘어선 지금, 진짜 질문은 '뭘 쓸 것인가'가 아니다
2024년 말 출시 당시 월 200만 건이던 MCP SDK 다운로드가 2026년 초 9,700만 건을 넘어섰다. Claude Code, Cursor, Windsurf, VS Code Copilot, JetBrains AI까지 모든 주요 AI 코딩 플랫폼이 MCP를 지원한다. 공개 레지스트리에 등록된 서버만 9,400개를 돌파했다. 이 숫자 앞에서 대부분의 팀이 던지는 질문은 "어떤 MCP 서버를 써야 하나?"다.
틀린 질문이다. 지금 물어야 할 건 "MCP로 에이전트에게 어떤 손발을 달고, 그게 배포 루프와 어떻게 연결되는가?"다.
에이전트 확장의 실용 기준: Tier 1부터 시작하라
dev.to에 올라온 MCP 서버 가이드는 설치 우선순위를 명확히 제시한다. GitHub MCP, Context7, Filesystem, Brave Search—이 네 개가 Tier 1이다. 팀 단위 도입 관점에서 이 분류는 꽤 실용적인 기준을 제공한다.
GitHub MCP는 AI가 실제 레포지토리를 읽고 쓰게 만든다. "현재 브랜치의 diff로 PR 만들어줘"가 그냥 동작한다. Context7은 훈련 데이터 한계를 우회한다. API 키도 없이 최신 라이브러리 문서를 실시간으로 컨텍스트에 주입한다. Filesystem은 AI가 프로젝트 디렉터리를 직접 읽고 쓰게 한다. 단, 경로 스코프는 반드시 지정해야 한다. Brave Search는 훈련 컷오프 이후 정보—새 릴리즈, 최신 CVE—를 채운다.
Sentry MCP와 PostgreSQL MCP는 Tier 2지만 팀 워크플로우에서는 종종 Tier 1보다 임팩트가 크다. AI가 프로덕션 스택 트레이스를 직접 보고 디버깅하거나, 실제 스키마 기반으로 쿼리를 작성하는 건 단순 코드 생성과 차원이 다른 컨텍스트 밀도를 만든다.
보안 주의사항 하나는 짚고 가야 한다. 2026년 4월, 많은 MCP 서버가 사용하는 stdio 전송에서 RCE 취약점이 공개됐다. 빠르게 패치됐지만 공급망 리스크는 현실이다. 벤더 공식 서버를 우선하고, 버전을 고정하고, API 키는 절대 JSON 설정 파일에 하드코딩하지 말 것.
자동 배포 루프의 실전: 25% 버그율이 가르쳐준 것
MCP로 에이전트를 확장하는 건 절반이다. 나머지 절반은 그 에이전트가 생성한 코드를 어떻게 배포 루프에 연결하느냐다.
국내 개발자 frogred8이 공개한 SpiralWave 프로젝트는 이 루프의 현실을 적나라하게 보여준다. Gemini를 활용한 이 프로젝트의 목표는 유저 피드백을 매일 자동으로 반영하는 웹게임이었다. 아키텍처는 단순했다: 피드백 수집 → 정제 → Gemini 코드 생성 → 빌드 → 배포. node:cron으로 전체 파이프라인을 묶었다.
처음 설계한 2시간 단위 실시간 배포는 폐기됐다. 이유는 명확하다—런타임 버그 발생률 약 25%. AI가 생성한 코드 네 개 중 하나는 빌드를 깼다. 결국 일일 테스트 빌드 생성 후 안정성을 확인한 다음 배포하는 방식으로 전환했다.
이게 팀에 주는 시사점은 크다. AI 생성 코드의 자동 배포를 설계할 때, 배포 주기는 AI 품질 신뢰도에 맞춰 조정해야 한다. 지금 수준에서 '생성 즉시 배포' 루프는 프로덕션에서 작동하지 않는다. 검증 레이어—최소한 빌드 성공 여부 확인—가 반드시 중간에 들어가야 한다.
또 하나 주목할 포인트: GEMINI.md 파일이다. 반복 지시의 번거로움을 줄이기 위해 기술 스택과 작동 방식을 정리한 이 지침 파일은, 팀 단위로 보면 AI에게 넘기는 컨텍스트 표준화의 첫걸음이다. Claude Code의 CLAUDE.md와 같은 개념이다. 에이전트 자동화 루프를 팀이 운영하려면, 이 지침 파일의 품질이 곧 루프 안정성이 된다.
비개발자의 900커밋이 증명하는 것
요즘IT에 소개된 디자이너의 바이브 코딩 사례는 다른 각도의 데이터를 제공한다. Claude를 활용해 7일간 900커밋, 앱스토어·구글 플레이·크롬 확장까지 동시 출시. 코딩을 모르는 비개발자가 해냈다.
이 사례에서 팀 리드가 주목해야 할 건 커밋 수나 출시 속도가 아니다. 실패 패턴의 구조다.
가장 큰 위기는 42개 파일 동시 수정 후 완전한 블랙스크린이었다. Git 롤백으로 살았고, 이후 원칙이 생겼다: "str_replace로 최소한만 수정." 3,800줄 단일 파일의 고통을 겪고 나서야 파일 분리의 필요성을 배웠다. AI가 생성한 코드의 가독성 문제와 과도한 일반화 패턴은 frogred8의 후기와도 정확히 겹친다.
AI 코딩의 생산성 향상은 실재한다—frogred8은 구현 속도 약 10배를 체감했다. 하지만 검증(QA)에 드는 시간과 피로도가 비례해서 커진다는 것도 실재한다. 더 빠르게 만들수록 더 빠르게 깨진다. 이 트레이드오프를 팀 워크플로우 설계에 반영하지 않으면, AI-First 전환은 속도만 올라간 카오스가 된다.
팀 단위 실행 가이드: 오늘 당장 할 수 있는 것
세 사례를 합치면 실행 가능한 AI-First 워크플로우 레이어가 그려진다.
레이어 1 — 에이전트 확장 (MCP): Context7과 GitHub MCP부터 시작하라. Context7은 API 키 없이 즉시 설치 가능하고 훈련 데이터 한계를 바로 우회한다. GitHub MCP는 2분이면 설정되고 에이전트가 실제 코드베이스를 이해하게 만든다. 팀 공통 MCP 설정은 .cursor/mcp.json이나 .vscode/mcp.json을 레포에 버전 관리하면 된다.
레이어 2 — 컨텍스트 표준화: CLAUDE.md 또는 GEMINI.md 형식의 지침 파일을 팀 단위로 관리하라. 기술 스택, 코드 컨벤션, 파일 구조 원칙을 여기에 집어넣으면 모든 팀원의 AI 세션이 같은 출발점에서 시작한다.
레이어 3 — 자동 배포 루프: AI 생성 코드의 자동 배포는 검증 게이트 없이 설계하지 말 것. 최소한 빌드 성공 + 스모크 테스트 통과를 CI 조건으로 걸어야 한다. 25% 버그율은 현실 데이터다. Playwright MCP를 파이프라인에 연결하면 AI가 UI 자동화 테스트까지 직접 작성하고 실행할 수 있다.
레이어 4 — 수정 범위 통제: 파일 단위 분리, 최소 변경 원칙은 비개발자 사례에서도 시니어 개발자 사례에서도 동일하게 증명됐다. 팀 AI 가이드라인에 "한 세션에서 수정하는 파일 수 상한선"을 명시하는 걸 권장한다.
전망: 루프가 닫히는 순간 팀의 역할이 바뀐다
피드백 수집 → AI 코드 생성 → 검증 → 자동 배포로 이어지는 루프가 팀 단위로 안정화되면, 개발자의 주요 작업 위치가 이동한다. 코드를 직접 작성하는 자리에서 루프를 설계하고 검증 레이어를 강화하는 자리로.
MCP 레지스트리의 9,400개 서버는 에이전트에게 달아줄 수 있는 손발의 카탈로그다. Sentry로 프로덕션 에러를 보게 하고, PostgreSQL로 실제 스키마를 읽게 하고, Playwright로 브라우저를 직접 제어하게 하면—에이전트는 컨텍스트 없는 코드 생성기에서 실제 시스템을 이해하는 협업자로 격이 달라진다.
남은 질문은 단 하나다. 이 루프를 내일 팀에 도입할 준비가 됐는가. 기술은 이미 거기 있다.