MCP 17만 도구, AI 에이전트의 위험은 이제 행동 계층
AISI가 MCP 도구 177,436개를 분석했습니다. AI 에이전트의 중심은 읽기와 분석에서 파일 편집, 브라우저, 결제 같은 행동 도구로 이동하고 있습니다.
- 무슨 일: UK AISI와 Bank of England 협업 연구가 공개 MCP 서버에서
177,436개AI 에이전트 도구를 분석했습니다.- 표본 기간은 2024년 11월부터 2026년 2월까지이며, 공개 도구와 다운로드 패턴을 함께 추적했습니다.
- 핵심 변화: 다운로드 기준 action 도구 비중이 약 24~27%에서 65%로 올라갔습니다.
- 읽기·분석보다 파일 편집, 코드 실행, 브라우저 조작, 결제처럼 외부 환경을 바꾸는 도구가 중심으로 이동하고 있습니다.
- 실무 의미: 에이전트 거버넌스는 모델 출력 필터링만으로 부족하고,
MCP도구 권한·행동 등급·감사 로그를 봐야 합니다. - 주의점: 데이터는 공개 MCP 생태계와 패키지 다운로드에 치우쳐 있어 비공개 기업 배포나 지역별 대체 채널은 과소대표될 수 있습니다.
UK AI Security Institute(AISI)가 Bank of England와 함께 흥미로운 분석을 공개했습니다. 제목은 "How are AI Agents used? Evidence from 177,000 AI agent tools"입니다. 함께 공개된 arXiv 논문은 2024년 11월부터 2026년 2월까지 공개 Model Context Protocol(MCP) 서버 생태계에서 만들어진 177,436개 에이전트 도구를 추적했습니다.
이 숫자가 중요한 이유는 단순히 MCP 생태계가 커졌기 때문이 아닙니다. AI 에이전트 논의는 자주 모델 성능, 벤치마크 점수, 프롬프트 품질에 머뭅니다. 하지만 에이전트가 실제 세계에서 위험해지거나 유용해지는 순간은 모델이 답을 잘할 때가 아니라, 모델이 어떤 도구를 호출할 수 있을 때입니다. 파일을 읽는 도구와 파일을 삭제하는 도구는 같은 "tool use"라는 말로 묶이지만, 운영 리스크는 전혀 다릅니다. 고객 DB를 조회하는 도구와 송금 API를 호출하는 도구도 마찬가지입니다.
AISI 연구의 핵심은 바로 이 층을 보자는 것입니다. 에이전트의 능력을 모델 출력에서만 측정하지 말고, 공개된 도구 생태계에서 어떤 종류의 도구가 만들어지고, 어떤 도구가 실제로 다운로드되며, 어떤 도메인에서 행동 권한이 늘어나는지 추적하자는 제안입니다. 이 관점은 2026년의 AI 에이전트 시장을 이해하는 데 꽤 실용적입니다. 지금 경쟁은 "모델이 무엇을 아는가"에서 "모델이 어떤 시스템을 만질 수 있는가"로 이동하고 있기 때문입니다.
MCP는 에이전트의 USB 포트가 됐습니다
MCP는 Anthropic이 2024년 공개한 이후 에이전트와 외부 시스템을 연결하는 사실상의 표준 중 하나로 빠르게 커졌습니다. 개념은 단순합니다. MCP 서버가 Google Calendar, GitHub, 데이터베이스, 로컬 파일 시스템, 브라우저, 결제 지갑 같은 기능을 감싸고, MCP 호환 클라이언트가 이를 도구로 발견하고 호출합니다. 모델 입장에서는 "캘린더 API를 직접 배워라"가 아니라 "정해진 스키마의 도구를 호출하라"가 됩니다.
이 구조는 개발자에게 편합니다. 같은 MCP 서버를 Claude Code, Cursor, Codex류 런타임, 내부 에이전트 플랫폼에서 재사용할 수 있습니다. 조직 입장에서도 통합 비용이 줄어듭니다. 새로운 SaaS 하나를 붙일 때마다 프롬프트, API wrapper, 인증 흐름을 처음부터 만들 필요가 줄어듭니다. MCP가 성공하는 이유는 여기에 있습니다. 에이전트가 일을 하려면 외부 세계와 연결돼야 하고, MCP는 그 연결을 패키지화합니다.
하지만 연결 표준은 동시에 위험 표준이 됩니다. 누구나 도구를 만들 수 있고, 누구나 도구를 배포할 수 있으며, 에이전트가 그 도구를 조합할 수 있다면, 감시해야 할 표면도 모델 API가 아니라 도구 생태계 전체로 넓어집니다. AISI 연구가 공개 MCP 서버를 관찰 대상으로 삼은 것도 이 때문입니다. 공개 저장소와 패키지 다운로드는 완전한 그림은 아니지만, 최소한 에이전트 생태계가 어느 방향으로 움직이는지 보여주는 공개 로그입니다.
17만 개 도구에서 보인 가장 큰 변화는 행동입니다
AISI 블로그는 공개 MCP 도구 수가 약 5,000개에서 177,000개로 늘었고, 다운로드 활동은 80,000건에서 1,400만 건으로 증가했다고 설명합니다. 성장 자체도 빠르지만 더 중요한 것은 구성의 변화입니다. 초기에는 파일 읽기, 데이터 조회, 검색, 분석처럼 perception과 reasoning에 가까운 도구가 많았습니다. 그런데 시간이 지나면서 외부 환경을 직접 바꾸는 action 도구가 다운로드의 다수를 차지하게 됐습니다.
수치 표현은 자료마다 약간 다릅니다. AISI 블로그의 Fig. 1 설명은 월간 다운로드에서 action 도구 비중이 24%에서 65%로 올랐다고 적고, arXiv 초록은 16개월 표본에서 27%에서 65%로 상승했다고 요약합니다. 기준점 차이는 있어도 메시지는 같습니다. 에이전트 도구 생태계는 "읽는 에이전트"에서 "실행하는 에이전트"로 이동하고 있습니다.
여기서 action은 단순한 마케팅 단어가 아닙니다. AISI는 perception 도구를 데이터 접근과 읽기, reasoning 도구를 데이터나 개념 분석, action 도구를 외부 환경을 직접 수정하는 도구로 나눕니다. 파일 편집, 이메일 발송, 코드 실행, 브라우저 자동화, 컴퓨터 제어, 결제 실행 같은 기능이 action 쪽입니다. 실무에서 문제를 만드는 것도 대개 이 층입니다. 모델이 틀린 분석을 내는 것은 비용이지만, 모델이 틀린 파일을 지우거나 잘못된 이메일을 보내거나 잘못된 결제를 실행하는 것은 다른 종류의 사고입니다.
개발자에게는 익숙한 흐름입니다. 코딩 에이전트는 이미 로컬 파일을 읽고 쓰며, 테스트를 실행하고, 브랜치를 만들고, PR을 열고, 때로는 CI나 배포 파이프라인까지 건드립니다. 생산성은 바로 이 action에서 나옵니다. 읽기 전용 에이전트는 조언을 줄 수 있지만, 개발자가 직접 모든 변경을 해야 합니다. action 도구를 가진 에이전트는 작업을 끝낼 수 있습니다. 문제는 같은 이유로 사고도 끝까지 갈 수 있다는 점입니다.
소프트웨어 개발이 현재의 중심입니다
연구에서 가장 큰 도메인은 소프트웨어 개발과 IT입니다. AISI는 소프트웨어 개발과 IT 도구가 전체 공개 도구의 67%, MCP 서버 다운로드의 90%를 차지한다고 봅니다. 이 수치는 직관과도 맞습니다. MCP를 가장 빨리 받아들인 집단은 개발자이고, 코딩 에이전트는 파일 시스템, git, 터미널, 패키지 매니저, 브라우저, 문서, 이슈 트래커와 자연스럽게 연결됩니다.
이 점은 에이전트 시장의 현재 단계를 보여줍니다. 일반 소비자용 에이전트보다 개발자용 에이전트가 먼저 action-heavy한 형태로 커졌습니다. 개발 환경은 도구 호출이 명확하고, 결과 검증도 상대적으로 쉽습니다. 테스트가 통과했는지, 타입 체크가 깨졌는지, diff가 무엇인지 확인할 수 있습니다. 그래서 파일 편집과 코드 실행처럼 강한 권한을 에이전트에게 맡기는 실험이 빠르게 퍼졌습니다.
하지만 개발 도구라고 해서 위험이 낮은 것은 아닙니다. 개발 환경은 토큰, 배포 키, 고객 데이터 샘플, 내부 패키지 저장소, CI 권한과 맞닿아 있습니다. MCP 서버가 브라우저와 터미널, 파일 시스템을 열어 주면 에이전트는 단순히 코드를 고치는 도구가 아니라 조직의 내부 시스템을 탐색하고 수정할 수 있는 실행 주체가 됩니다. 그래서 소프트웨어 개발은 "중간 위험" 영역이면서 동시에 다른 고위험 시스템으로 이어지는 입구입니다.
열린 웹과 컴퓨터 제어가 위험을 넓힙니다
AISI가 강조한 또 다른 포인트는 unconstrained environment입니다. 일반 목적 도구가 열린 웹이나 전체 컴퓨터 제어처럼 통제 범위가 넓은 환경에서 쓰이는 다운로드 비중은 41%에서 50%로 늘었습니다. 더 중요한 것은 일반 목적 도구 다운로드의 95%가 action capability를 포함했다는 점입니다.
API 통합은 보통 경계가 명확합니다. 예를 들어 "CRM에서 고객 레코드를 조회한다"거나 "티켓 상태를 변경한다"는 도구는 입력, 출력, 권한, 감사 로그를 비교적 구체적으로 설계할 수 있습니다. 반면 브라우저 자동화와 컴퓨터 제어는 경계가 흐립니다. 같은 브라우저 도구가 문서를 읽을 수도 있고, 결제 버튼을 누를 수도 있고, 관리자 콘솔에서 설정을 바꿀 수도 있습니다. 같은 컴퓨터 제어 도구가 테스트를 실행할 수도 있고, 로컬 비밀 파일을 읽을 수도 있습니다.
이 차이는 에이전트 보안 설계에서 매우 중요합니다. 도구 이름이 browser.click이라고 해서 위험도가 하나로 정해지지 않습니다. 어느 사이트에서 무엇을 클릭하는지, 현재 세션이 어떤 권한을 갖는지, 클릭 전에 사람이 승인했는지, 실행 후 되돌릴 수 있는지에 따라 위험이 달라집니다. MCP가 도구 호출 인터페이스를 표준화할수록, 그 위에 권한 맥락과 정책 맥락을 얹는 일이 더 중요해집니다.
금융 도구는 작은 비중이지만 큰 경고입니다
AISI 연구에서 가장 예민한 사례는 금융입니다. 블로그는 finance and business management task가 전체 도구의 14%를 차지한다고 설명합니다. 절대 다수는 여전히 소프트웨어 개발과 IT입니다. 하지만 연구진은 O*NET impact rating을 이용해 직무의 영향도를 매핑했고, 금융 분야가 예외적으로 고위험 action 도구가 많은 영역이라고 봅니다.
특히 결제 실행 기능을 가진 MCP 서버가 2025년 1월 46개에서 2026년 1월 1,200개 이상으로 늘었다는 수치가 눈에 띕니다. 여기에는 암호화폐 도구처럼 직접적이고 되돌리기 어려운 거래를 가능하게 하는 도구가 포함됩니다. 이 숫자가 곧바로 "에이전트가 대규모 금융 사고를 일으켰다"는 뜻은 아닙니다. 하지만 결제 기능이 에이전트 도구 생태계 안으로 빠르게 들어오고 있다는 신호로는 충분합니다.
금융 도구가 중요한 이유는 되돌림과 책임 소재 때문입니다. 파일 편집은 git으로 되돌릴 수 있고, 이메일은 사과 메일을 보낼 수 있습니다. 하지만 잘못된 송금, 토큰 전송, 주문 실행은 되돌리기 어렵거나 불가능할 수 있습니다. 사람의 승인 없이 에이전트가 결제 도구를 호출한다면, 문제는 모델 정확도보다 권한 설계입니다. 누가 한도를 정했는가, 어떤 거래는 반드시 승인해야 하는가, 어떤 수신자는 허용 목록에 있어야 하는가, 감사 로그는 충분한가가 핵심 질문이 됩니다.
AI가 에이전트 도구를 다시 만들고 있습니다
이 연구에서 덜 주목받았지만 중요한 수치가 하나 더 있습니다. AISI는 MCP 서버의 29%, 도구의 38%에서 AI assistance를 감지했다고 말합니다. 새로 만들어진 서버 기준으로 보면 AI 도움을 받은 비중은 2025년 1월 6%에서 2026년 1월 55%로 올랐습니다. AI 공동 작성 서버 중 Claude Code가 66%, Cursor와 GitHub Copilot이 각각 10%로 집계됐습니다.
이것은 에이전트 생태계의 성장 속도를 설명합니다. 도구 생성이 더 이상 사람 개발자 수에만 묶이지 않습니다. 개발자가 "이 내부 API를 MCP 서버로 감싸줘"라고 지시하면 코딩 에이전트가 서버 뼈대, 스키마, 인증 코드, 문서를 빠르게 만들 수 있습니다. 좋은 방향으로는 사내 시스템을 에이전트와 연결하는 비용이 크게 낮아집니다. 나쁜 방향으로는 검토되지 않은 도구, 과도한 권한의 도구, 설명이 부정확한 도구가 더 빨리 늘어날 수 있습니다.
도구 설명은 에이전트에게 UI입니다. 사람이 보는 버튼 라벨처럼, 모델은 도구 이름과 description, input schema를 보고 무엇을 호출할지 판단합니다. AI가 만든 MCP 서버가 부정확한 설명을 갖고 있거나, 실패 조건을 제대로 쓰지 않거나, 권한 범위를 애매하게 표시하면 모델은 잘못된 도구를 자신 있게 호출할 수 있습니다. 따라서 "AI가 도구를 만든다"는 흐름은 생산성 뉴스이면서 품질 관리 뉴스입니다.
규제의 초점은 출력에서 도구 호출로 이동합니다
지금까지 AI 규제와 안전 논의는 모델 출력에 집중해 왔습니다. 유해한 답변을 막고, 개인정보를 노출하지 않게 하고, 저작권과 허위 정보를 다루는 방식입니다. 물론 여전히 중요합니다. 하지만 에이전트에서는 출력보다 호출이 중요해질 때가 많습니다. 모델이 어떤 문장을 생성했는지보다 어떤 도구를 어떤 인자로 호출했는지, 그 호출이 어떤 외부 상태를 바꿨는지가 사고의 본체가 됩니다.
AISI 연구는 정부와 규제기관이 에이전트 배포 위험을 모델 출력 너머 도구 계층에서 모니터링할 수 있다고 제안합니다. 이것은 꽤 현실적인 방향입니다. 모든 기업의 내부 프롬프트와 모델 로그를 보기는 어렵습니다. 하지만 공개 도구 생태계, 패키지 다운로드, 도구 설명, 권한 유형, 도메인 분포, action capability의 증가는 관찰 가능한 신호입니다. 특히 금융, 의료, 법률, 교육, 인프라처럼 결과가 큰 영역에서는 도구 수준의 분류가 필요합니다.
기업 내부에서도 같은 원리가 적용됩니다. 에이전트 도입 평가를 "어떤 모델을 쓸까"로 시작하면 부족합니다. 어떤 MCP 서버를 허용할지, 어떤 도구는 읽기 전용으로 둘지, 어떤 action은 사람 승인 뒤에만 실행할지, 어떤 도구 호출은 보안 로그로 남길지, 어떤 도구는 샌드박스 밖으로 나가지 못하게 할지 정해야 합니다. 모델 교체보다 도구 권한 표준화가 더 오래 남는 인프라가 될 수 있습니다.
개발팀이 지금 볼 체크리스트
개발팀 관점에서 이 연구는 MCP를 쓰지 말라는 경고가 아닙니다. 오히려 MCP가 에이전트 통합의 기본 경로가 될 가능성이 높다는 신호에 가깝습니다. 문제는 MCP 서버를 플러그인처럼 쉽게 추가할 수 있게 된 만큼, 운영 기준도 플러그인 수준을 넘어야 한다는 점입니다.
첫째, 도구를 perception, reasoning, action으로 나눠야 합니다. 모든 MCP 서버를 같은 위험 등급으로 두면 안 됩니다. 파일 읽기와 파일 쓰기, 쿼리 실행과 데이터 변경, 가격 조회와 주문 실행은 서로 다른 승인 정책을 가져야 합니다.
둘째, 일반 목적 도구를 특별 취급해야 합니다. 브라우저, 컴퓨터 제어, 셸 실행, 코드 인터프리터는 특정 API 도구보다 훨씬 넓은 표면을 엽니다. 이런 도구는 네트워크 egress, 파일 경로, 환경 변수, credential 접근, 사용자 세션 권한을 함께 제한해야 합니다.
셋째, 도구 설명과 스키마를 코드 리뷰 대상으로 삼아야 합니다. MCP 서버의 description은 모델의 행동을 바꾸는 인터페이스입니다. 잘못된 설명은 잘못된 호출로 이어질 수 있습니다. 도구 설명, 입력 제약, 실패 조건, idempotency, side effect를 리뷰해야 합니다.
넷째, 결제와 외부 전송은 별도 승인 계층을 가져야 합니다. 돈, 고객 데이터, 이메일, 메시지, 배포, 권한 변경은 한 번 실행되면 외부 세계에 흔적을 남깁니다. 이 범주의 도구는 기본값을 수동 승인으로 두고, 한도와 허용 목록을 둬야 합니다.
다섯째, 도구 호출 로그를 제품 로그처럼 남겨야 합니다. 에이전트 사고가 발생했을 때 "모델이 이상한 답을 했다"는 설명만으로는 부족합니다. 어떤 도구가 어떤 인자로 호출됐고, 어떤 응답을 받았으며, 누가 승인했는지 재구성할 수 있어야 합니다.
이 연구의 한계도 같이 봐야 합니다
AISI 연구는 공개 MCP 서버와 다운로드 데이터를 기반으로 합니다. 따라서 비공개 기업 배포, 내부 레지스트리, 지역별 대체 패키지 채널, 폐쇄망 환경은 충분히 잡히지 않을 수 있습니다. 블로그도 미국, 서유럽, 중국 등의 지역 분포를 언급하면서 Python Package Index의 서구권 사용자 기반이 반영될 수 있다고 선을 긋습니다. 다운로드가 곧 실제 실행 횟수나 프로덕션 사용량을 의미하는 것도 아닙니다.
또 하나의 한계는 도구의 존재와 안전한 사용은 다르다는 점입니다. 결제 MCP 서버가 1,200개 이상이라고 해서 모두가 위험하게 운영된다는 뜻은 아닙니다. 반대로 도구 수가 적은 영역도 하나의 잘못된 통합이 큰 사고를 만들 수 있습니다. 따라서 이 연구는 최종 판정이라기보다 관찰 방법의 시작에 가깝습니다.
그럼에도 데이터의 방향은 분명합니다. AI 에이전트는 점점 더 많은 도구를 갖고, 그 도구 중 더 큰 비중이 외부 상태를 바꾸며, 그 도구를 만드는 과정에도 AI가 들어가고 있습니다. 이 세 가지가 합쳐지면 에이전트 생태계는 더 빨리, 더 넓게, 더 불균등하게 커집니다.
모델보다 도구를 보라는 신호
2026년의 에이전트 경쟁은 모델 성능만으로 설명되지 않습니다. Claude Code, Codex, Cursor, GitHub Copilot, Glean, Coder Agents, UiPath, Salesforce Agentforce 같은 제품들이 서로 다른 표면에서 경쟁하지만, 공통 질문은 비슷합니다. 에이전트가 어떤 도구를 쓸 수 있고, 어떤 권한으로 실행되며, 그 실행을 사람이 어떻게 감독할 것인가입니다.
AISI의 17만 MCP 도구 분석은 그 질문을 공개 데이터로 보여줍니다. AI 에이전트는 이미 읽기와 분석을 넘어 행동으로 이동하고 있습니다. 생산성도 이 행동에서 나오고, 리스크도 이 행동에서 나옵니다. 그래서 다음 세대의 에이전트 인프라는 더 좋은 프롬프트 모음이 아니라, 도구 권한, 실행 정책, 감사 로그, 승인 흐름, 고위험 도메인 모니터링이 될 가능성이 큽니다.
MCP는 에이전트에게 외부 세계를 연결하는 표준 포트가 됐습니다. 이제 남은 질문은 그 포트에 무엇을 꽂을 것인지가 아닙니다. 누가 꽂을 수 있고, 어떤 전류가 흐르며, 과부하가 날 때 어디서 차단할 것인지입니다. 모델이 말하는 시대에서 에이전트가 행동하는 시대로 이동한다면, 보안과 규제의 관찰 지점도 출력 창에서 도구 호출 로그로 옮겨가야 합니다.