MCP 서버를 CI/CD에 연결하는 팀이 빠르게 늘고 있다. 에이전트가 GitHub 이슈를 읽고, 코드를 짜고, PR을 올리는 루프가 가능해졌기 때문이다. 문제는 그 속도에 비해 검증 구조가 턱없이 부족하다는 점이다. MCP 서버가 시작됐다고 해서 툴 호출이 실제로 작동한다는 보장은 없다. 인증이 깨져 있거나, 다운스트림 권한이 없거나, stderr에 치명적 에러가 섞여 있어도 파이프라인은 그냥 통과된다. 세 가지 최근 사례를 겹쳐보면, 이 문제의 윤곽이 꽤 선명하게 드러난다.
Vibe Coding이 CI 리스크를 증폭시키는 구조
dev.to의 분석에 따르면 2026년 Vibe Coding은 이미 전문 워크플로우로 자리 잡았다. Cursor Agent Mode는 반복 구현 시간을 60~70% 줄이고, GitHub Copilot Workspace는 이슈에서 PR까지 자연어로 처리한다. 속도는 확실히 빠르다. 그런데 문제는 여기서 시작된다. MIT 연구는 시니어 엔지니어가 AI를 '사고 파트너'로 쓸 때 최종 산출물 품질이 올라간다고 보고했지만, 반대로 부트캠프 출신 주니어들이 AI 보조 워크플로우로만 학습했을 때 알고리즘·디버깅 역량이 이전 코호트 대비 유의미하게 낮아졌다는 데이터도 함께 나왔다. Stack Overflow 데이터는 AI 없이 디버깅에 자신 있는 개발자 비율이 2023~2025년 사이 23% 감소했다고 집계한다.
이게 CI/CD와 무슨 상관이냐고? 직접적이다. Vibe Coding으로 생성된 코드는 '작동처럼 보이지만 아무도 이유를 모르는' 코드일 가능성이 높다. 그 코드가 MCP 에이전트를 통해 자동으로 파이프라인에 올라온다면, 검증 게이트 없이는 그 불확실성이 그대로 프로덕션으로 전파된다. 속도가 빠를수록 게이트는 더 촘촘해야 한다.
mcp-probe: CI 게이트의 실질적 빈자리를 채우는 도구
mcp-probe v1.0.0은 이 빈자리를 직접 겨냥한다. 기존에 MCP 서버 검증은 'tools/list가 반환되면 정상'이라는 수준에 머물렀다. 그런데 서버가 시작되고 툴 목록을 반환해도, OAuth가 깨져 있거나 다운스트림 권한이 없으면 실제 툴 호출은 전부 실패한다. 이 갭을 메우는 것이 --probe-tools 옵션이다. 단순 스키마 확인이 아니라 실제 툴 호출 dry-run을 실행하고, sidecar 파일로 의미 있는 입력값과 기대값을 지정할 수 있다.
실제 CI 활용 관점에서 눈에 띄는 기능은 두 가지다. 첫째, stderr classification이다. 서버 시작 시 출력되는 경고가 무해한 deprecation 메시지인지 치명적 초기화 에러인지를 규칙으로 구분한다. 지금까지 많은 팀이 stderr를 그냥 무시하거나 전부 실패로 처리했는데, 이 이분법만으로도 오탐과 미탐을 상당히 줄일 수 있다. 둘째, 배치 검증과 GitHub Actions 연동이다. 팀이 여러 MCP 서버를 운영한다면 config 파일 하나로 전체 플릿의 readiness를 단일 게이트로 묶을 수 있고, Step Summary와 badge JSON까지 자동 생성된다. 툴 하나를 추가할 때마다 파이프라인 설정을 손댈 필요가 없어진다.
거버넌스 없이 배포한 팀이 맞닥뜨리는 Phase 3
mcp-probe가 '기술적 readiness'를 검증하는 도구라면, 그 위에 올라와야 하는 레이어가 있다. dev.to의 엔터프라이즈 MCP 거버넌스 분석은 대부분의 조직이 반드시 거치는 세 단계를 정리한다. 탐색(Exploration) → 팀 확산(Team Adoption) → 인시던트(Incident). 1단계에서는 몇몇 개발자가 개별적으로 MCP 서버를 쓴다. 2단계에서는 팀이 설정을 공유하고, 워크스페이스 토큰 하나가 Slack에 돌아다니며 모두가 동일한 접근 권한으로 작업한다. 로깅은 없고, 보안팀은 아무것도 모른다. 3단계는 예측 가능하다. 누군가 권한을 가져선 안 되는 API를 에이전트가 호출하거나, 수정되어선 안 될 파일이 바뀐다. 그때 "무슨 일이 있었나?"라는 질문에 아무도 답할 수 없다.
문제는 이 시점에 거버넌스를 소급 적용하는 게 사실상 불가능하다는 것이다. 히스토리 데이터가 없고, 감사 트레일이 없고, 접근 기록이 없다. 규제 산업이 아니더라도 이 상태에서 AI 에이전트가 프로덕션 시스템에 접근한다는 건 용납하기 어렵다. 해당 분석이 제시하는 엔터프라이즈 MCP의 7가지 필수 요건—중앙화된 엔드포인트, 멤버별 신원, 툴 레벨 접근 제어, 격리된 서버 배포, 즉각 권한 회수, 프로토콜 레벨 감사 로그—은 사실 새로운 요건이 아니다. 기존 엔터프라이즈 보안 원칙을 MCP 레이어에 그대로 적용하는 것이다. 새로운 건 그것을 '배포 이전에' 해야 한다는 타이밍이다.
테크 리드가 지금 당장 잠가야 할 것들
세 사례를 조합하면 실행 우선순위가 꽤 명확해진다. 첫째, Vibe Coding 산출물에 대한 리뷰 게이트를 명시화해야 한다. AI가 생성한 코드를 PR에 올리기 전, 담당자가 실제로 읽고 설명할 수 있어야 한다는 기준을 팀 규칙으로 문서화한다. "AI가 짰으니까 빠르게 머지"는 팀 전체의 디버깅 역량 저하로 직결된다. 둘째, mcp-probe 같은 readiness gate를 CI 파이프라인에 명시적으로 삽입해야 한다. 서버 시작 여부 확인이 아니라 실제 툴 호출 검증까지 포함한 게이트가 없으면, MCP 에이전트를 자동화 파이프라인에 연결하는 순간부터 검증되지 않은 호출이 프로덕션으로 흘러 들어간다. 셋째, 거버넌스 레이어는 배포 전에 설계해야 한다. 멤버별 토큰, 툴 레벨 접근 제어, 감사 로그. 이 세 가지가 없는 상태에서 팀 전체에 MCP를 확산시키면, 6개월 뒤 감사 질문에 "모릅니다"로 답하게 된다.
AI-First 파이프라인에서 속도와 안전이 공존하는 조건
"Vibe coding은 강력한 도구다. 테이블쏘처럼." dev.to의 표현이 정확하다. 테이블쏘는 빠르고 강력하지만, 안전 가이드 없이 쓰면 다친다. MCP를 CI/CD에 연결하는 것도 마찬가지다. 빠르게 움직일수록 게이트가 먼저여야 한다. mcp-probe는 기술 레이어의 게이트를, 거버넌스 설계는 조직 레이어의 게이트를 담당한다. 두 레이어가 모두 갖춰지지 않으면 AI-First 파이프라인의 속도는 생산성이 아니라 리스크 속도가 된다.
지금 대부분의 팀은 Phase 1과 Phase 2 사이 어딘가에 있다. 거버넌스를 설계할 창이 아직 열려 있다는 뜻이다. Phase 3 이후에 잠그는 건 가능하지만, 그건 이미 잃어버린 것들을 되돌릴 수 없는 상태에서 하는 작업이다.