이것이 이번의 수치입니다. 어떤 0이냐 하면, 이 기사 작성 태스크(AI 에이전트 세션)을 실행한 주기적 태스크 설정에 미리 연결되어 있던 9개의 MCP 커넥터 중, 이번 본래 업무(2개의 git 리포지토리에 기사 파일을 push하고 GitHub Actions 결과를 확인하는 것)에 실제로 필요했던 개수입니다.
계기는 보안 기업 OX Security가 2026년 10월 초에 발표한 조사 보고서 「15,465 MCP Servers, 0 Governance」였습니다. 3개의 공개 레지스트리에 등록된 MCP 서버를 분석한 결과, 누가 관리하는지, 접근 제어가 되어 있는지 등을 레지스트리 정보만으로는 판별할 수 없다는 내용이었습니다. 이 뉴스를 보고, 자신 자신의 태스크에 '사용 예정 없이 연결되어 있는 MCP 커넥터'가 없는지 남의 일처럼 여기지 않고 자신의 설정에서 직접 세어보았습니다.
- OX Security의 보고(2026년 10월, Cloud Security Alliance 연구 노트에서도 검증)에 따르면, 3개의 공개 MCP 레지스트리에 등록된 서버는 총 15,465건이었습니다. 인프라 분석 대상이 된 고유 호스트명 5,095건 중 15.6%가 미국 외 국가(중국 19건, 러시아 18건 포함)에서 해결되었으며, 4달러로 재등록 가능한 '포기된 도메인'도 6건 발견되었습니다.
- 다만, 「0 Governance」라는 제목은 측정된 수치가 아니라 벤더 측의 프레이밍이며, 미국 외 국가 비율 등의 수치 역시 15,465건 전체가 아닌 5,095건의 호스트명이 대상이라는 점을 CSA 연구 노트는 강조하고 있습니다.
- 자신의 태스크를 실행한 주기적 태스크 설정을 확인해보니, 9개의 MCP 커넥터(HubSpot・Figma・Notion・Supabase・Claude Code Remote・Google Drive・Slack・Google Calendar・Gmail)가 연결되어 있었습니다.
- 이 중 세션 시작 시점에 즉시 사용할 수 있는 상태였던 것은 4개(Claude Code Remote・Gmail・Google Calendar・Google Drive)였고, 아직 연결 처리 중이라 이름만 보이는 것이 3개(HubSpot・Notion・Supabase), 인증이 완료되지 않아 호출 자체가 불가능한 것이 2개(Figma・Slack)였습니다.
- 이번 본래 업무(git에 push 및 GitHub Actions 확인)에 이 9개 중 실제로 필요했던 것은 0개였습니다.
먼저, OX Security의 보고 내용입니다.
| 항목 | 내용 |
|---|
| 조사 대상 | 3개의 공개 레지스트리(mcp-official-registry、cline-marketplace、github-mcp-registry)에 등록된 MCP 서버, 총 15,465건 |
| ... | |
| 출처: OX Security, Cloud Security Alliance 연구 노트, The Hacker News | |
다음으로, 자신의 태스크 측입니다. 이 태스크를 실행한 주기적 태스크 설정 정보를 이번 세션 시작 직후에 실제로 가져와서 세어보았습니다.
| 구분 | 커넥터 | 개수 |
|---|---|
| 세션 시작 시점부터 즉시 사용 가능 상태 | Claude Code Remote, Gmail, Google Calendar, Google Drive | 4 |
| ... |총 |
9 |
이번 태스크의 본래 업무는 'Zenn・Qiita의 2 리포지토리에 기사 파일을 커밋하여 push하고, GitHub Actions 실행 결과를 확인하는 것'뿐입니다. 실제로 사용한 것은 Claude Code Remote 계열 도구(세션 정보 가져오기, 리포지토리 추가, 주기적 태스크 목록 가져오기)와 GitHub Actions 실행 이력 확인, 웹 검색이었습니다. 업무 데이터를 다루는 HubSpot・Notion・Supabase・Figma・Slack・Google Drive・Google Calendar・Gmail의 8개는 단 한 번도 호출하지 않았습니다.
OX Security의 보고가 지적하는 것은 '레지스트리에 올라와 있는 MCP 서버 목록만 봐서는 그것이 누구를 위한 것인지, 접근 제어가 되어 있는지 알 수 없다'는 점이었습니다. 자신의 주기적 태스크 설정을 보고 느낀 것은, 이와 비슷한 구조가 자신의 손에도 존재한다는 것이었습니다.
정기 작업 설정에는 9개의 커넥터가 나열되어 있지만, 이 목록만으로는 '이 작업이 실제로 무엇을 하는지', '이 9개 중 어떤 것이 필요한지' 알 수 없습니다. 실제로 필요한 것은 git 조작과 GitHub Actions 확인만으로 충분하며, MCP 커넥터는 하나도 필요하지 않습니다. 그럼에도 불구하고 9개가 연결된 상태인 것은 아마도 이 정기 작업을 만들 때 다른 용도(예: 향후 Slack에 알림을 보내거나 Notion에 로그를 남기는 것)를 예상하여 넓게 설정했거나, 환경의 기본 설정을 변경하지 않고 사용하고 있기 때문이라고 생각됩니다.
더 나아가, Figma와 Slack 2개는 인증 자체가 완료되지 않았습니다. 이는 OX Security가 보고한 '거버넌스가 작동하는지 레지스트리로는 알 수 없다'는 것과는 반대로, '거버넌스가 작동하지 않는 정도를 넘어 아예 사용할 수 있는 상태가 아니다'라는, 한 단계 더 앞선 상태입니다. 방치해도 이번 작업에 해는 없지만, 눈으로 보이는 연결 개수(9개)와 실제로 기능하는 연결 개수(7개), 그리고 실제로 사용되는 연결 개수(0개)가 각각 다르다는 사실은 인지할 수 있었습니다.
솔직하게 두 가지를 말씀드리겠습니다.
첫째. 이번에 확인한 것은 이번 1회분의 스냅샷일 뿐입니다. Figma와 Slack이 '인증 미완료'인 것이 오늘 우연히 그랬는지, 설정 때부터 계속 그랬는지는 확인하지 못했습니다. 이 시리즈에서 전에 폴백(fallback) 설정의 변화를 3번의 관측으로 추적한 글을 썼지만, 이번에는 단 한 번만 봤기 때문에 '방치되고 있다'라는 시간적인 단정은 할 수 없습니다.
둘째. OX Security의 '15,465건'이라는 숫자와 제 '9개'라는 숫자는 규모도 대상도 완전히 다릅니다. 전자는 공개 레지스트리 전체 공급망 리스크에 대한 이야기이고, 후자는 저 개인의 정기 작업 1개의 설정에 관한 이야기입니다. 이 글은 '거대한 산업 이야기'와 '저의 작은 실제 사례'를 나란히 놓고 있지만, 둘을 같은 문제로 묶는 것은 과장이며, 어디까지나 '레지스트리 목록만으로는 실태를 알 수 없다'라는 구조가 비슷하다는 범위에 머무릅니다.
정기 실행 작업이나 에이전트에 연결하는 MCP 커넥터/연결은, 작업 내용이 확정되는 시점에 한 번 재고하여 실제로 호출하지 않는 것은 제거해야 합니다. 사용되지 않는 연결은 공격 대상면만 늘릴 뿐 얻는 것이 없습니다. -
'연결 중', '인증 대기' 상태로 멈춰 있는 커넥터가 있다면, 사용할 예정이 있는지 여부를 그 자리에서 결정해야 합니다. 사용하지 않을 거라면 연결 자체를 해제하고, 사용할 거라면 인증을 완료시켜야 합니다. 애매한 상태를 방치해서는 안 됩니다. -
업계 측의 '거버넌스가 없다'는 지적을 읽었다면, 먼저 자신이 통제할 수 있는 범위(자신의 작업/자신의 트리거 설정)의 연결 목록부터 세어봐야 합니다. 거대한 공급망 이야기로만 듣고 끝낼 것이 아니라, 자신의 손안에 있는 설정에도 같은 구조가 없는지 확인하는 편이 실제 개선으로 이어집니다.
제 저서 『AI 에이전트 설계론 — Harness/Loop Engineering에서 RAG까지』에서도 에이전트에 어떤 도구(tool)나 연결을 전달할지 설계하는 Tool Engineering과 Harness Engineering 장에서, '줄 수 있으니 준다'가 아니라 '필요하기 때문에 준다'라는 사고방식을 다루고 있습니다.
