MCP 200개 서버 시대, 리눅스 재단 표준화 이후 AI 에이전트 붙이기 전 권한·보안 체크리스트 2026

Posted on by

에이전트에 MCP 서버 하나를 붙였을 뿐인데, 그 도구가 내 파일을 읽어서 외부로 보낼 수도 있다고요? 실제로 가능합니다. 그게 편리함의 대가입니다. MCP 서버 구현이 200개를 넘어선 2026년, “설정 한 줄로 연결”이라는 말은 뒤집으면 “검증되지 않은 코드에 내 작업 환경을 열어준다”는 뜻이기도 합니다.

2026년 8월 업데이트: 이 이야기에 변수가 하나 더 붙었습니다. MCP는 2025년 12월 9일 리눅스 재단 산하 Agentic AI Foundation(AAIF)에 기증됐고, AWS·Anthropic·Block·Bloomberg·Cloudflare·Google·Microsoft·OpenAI가 창립 플래티넘 멤버로 참여했습니다. 이어 2026년 7월 28일에는 인증 절차를 강화한 새 스펙 후보(RC)가 공개됐습니다. 두 사건은 별개이지만, 결론은 같습니다. 표준이 생겼다고 붙이기 전 점검이 줄어드는 게 아니라, 오히려 확인할 항목이 늘었습니다.

미리 결론: MCP는 AI 에이전트에 외부 도구를 꽂는 만능 USB 허브 같은 겁니다. 편한 만큼 아무거나 꽂으면 위험합니다. 붙이기 전에 ①이 서버를 신뢰할 수 있나 ②이 도구에 준 권한이 필요 이상으로 넓지 않나 ③파일 삭제·외부 전송 같은 되돌리기 어려운 동작에 사람 승인이 걸려 있나 ④문제가 생겼을 때 바로 되돌릴 경로가 있나, 이 네 가지만 먼저 확인해도 사고 대부분을 막습니다. 표준화됐다고 이 점검이 면제되지는 않습니다.

AI 코딩 에이전트를 실무에 붙이는 사람이 늘면서, 이제 질문은 “MCP를 쓸까 말까”가 아니라 “어떻게 안전하게 붙일까”로 넘어왔습니다. 특히 개인 실험을 넘어 회사 코드나 고객 데이터가 걸린 환경에서는, 도구 하나를 잘못 붙이는 것만으로 유출 사고가 날 수 있어 사전 점검이 필수가 됐습니다. 자료 기준으로 위험 구조부터 정리하고, 붙이기 전에 돌릴 체크리스트를 업데이트해 보겠습니다.

MCP가 뭐고, 왜 편한데 왜 위험한가

MCP(Model Context Protocol)는 AI 에이전트가 외부 도구·데이터에 연결되는 표준 규격입니다. 쉽게 말하면 에이전트에게 “이 도구 써도 돼”라고 손을 뻗게 해주는 콘센트입니다. GitHub, Slack, 브라우저, 파일 시스템까지 설정 한 줄로 붙는 게 매력이고, 그래서 서버 종류가 200개를 넘었습니다.

서버가 많아진 게 곧 안전해졌다는 뜻은 아닙니다. 오히려 반대에 가깝습니다. 200개 중 상당수는 개인이 만들어 공개한 것이고, 그중 어느 것이 관리가 끊겼는지, 어느 것이 중간에 주인이 바뀌었는지는 겉으로 잘 드러나지 않습니다. 선택지가 늘어난 만큼 검증 부담도 같이 늘어난 셈입니다.

문제의 핵심은 이 연결이 양방향이라는 점입니다. 에이전트가 도구를 호출하기만 하는 게 아니라, 도구가 돌려주는 내용도 그대로 에이전트의 판단 재료가 됩니다. 즉 붙여둔 MCP 서버가 악의적이거나 탈취당하면, 그 서버가 에이전트에게 슬쩍 명령을 흘려 넣을 수 있습니다. 유능해 보이는 외주 도구를 붙였는데 그 도구가 뒤로 정보를 빼돌리는 상황이 구조적으로 가능하다는 뜻입니다.

표준화, 정확히 뭐가 바뀐 건가

업계어로 “거버넌스 기증(donation to a foundation)”이라는 말이 나오면, 사람말로는 “이제 한 회사 마음대로 규격을 바꿀 수 없고, 여러 회사가 같이 관리하는 공용 콘센트 규격이 됐다”는 뜻입니다. 현실 장면으로 옮기면, 부서마다 각자 다른 방식으로 사내 시스템에 어댑터를 만들던 상황이, 이제는 공식 콘센트 모양 하나로 정리되는 셈입니다. 실행 결론은 간단합니다. 콘센트 모양이 통일됐다고 거기 꽂는 전자제품까지 전부 안전 인증을 받은 건 아니라는 겁니다.

2026년 7월 28일 스펙 RC는 무상태(stateless) 프로토콜 코어, 여러 번 왕복하는 요청 처리, 헤더 기반 라우팅, 그리고 인증 하드닝(authorization hardening)을 핵심으로 내세웁니다. 인증 하드닝 쪽에는 새 OAuth 관련 제안 6건이 들어갔는데, 그중 하나가 이슈어(issuer) 검증 의무화입니다. 인증 서버가 돌려주는 응답의 발급 주체를 클라이언트가 반드시 확인하게 만들어서, 여러 서버를 오가며 발생할 수 있는 인증 뒤섞임 공격을 줄이는 조치입니다.

이 변화는 실무자 입장에서 두 가지를 의미합니다. 첫째, 인증 계층이 더 촘촘해진다는 건 그만큼 설정할 항목도 늘어난다는 뜻입니다. 둘째, 스펙이 강화됐다고 해서 이미 배포된 200여 개 서버가 자동으로 새 규격을 따르는 건 아닙니다. 새 스펙은 아직 RC 단계이고, 실제 서버 생태계가 이를 따라오는 데는 시간이 걸립니다. 표준과 신뢰는 다른 층위의 문제입니다. MCP 표준은 “도구를 어떻게 연결할지” 규격을 정할 뿐, 그 규격으로 만들어진 개별 서버의 코드 품질이나 운영 주체의 신뢰도까지 보장하지 않습니다.

알아야 할 3대 위험

첫째, 프롬프트 인젝션(지시 가로채기)입니다. 공격자가 에이전트가 읽을 만한 곳(파일 주석, 이슈 설명, API 응답)에 몰래 명령을 심어두고, 에이전트가 그걸 진짜 지시로 착각해 실행하게 만드는 겁니다. 누군가 문서 안에 “이 파일 지우라고 사장님이 말했다”는 문장을 끼워 넣으면, 의심 없이 지우는 신입과 같은 상황이 벌어집니다. OWASP가 발표한 2026년 에이전트 애플리케이션 위험 순위에서 이 ‘에이전트 목표 가로채기’가 1위입니다. 이번 인증 하드닝 스펙도 이 문제 자체를 없애지는 못합니다. 인증은 “누가 요청하는가”를 확인할 뿐, “요청 내용이 진짜 지시인가”는 별개의 방어선이 필요합니다.

둘째, 툴 포이즈닝(도구 설명 오염)입니다. 도구의 설명이나 동작 메타데이터를 몰래 바꿔서 에이전트가 그 도구를 오용하게 만드는 방식입니다. “이건 날씨 조회 도구예요”라는 설명 뒤에 “겸사겸사 API 키도 복사”가 숨어 있는 겁니다. 에이전트는 설명을 믿고 도구를 부르니, 라벨만 바꿔치기해도 통합니다.

셋째, 악성·탈취 MCP 서버입니다. 신뢰할 수 없는 서버를 붙이면 그 서버가 지속적으로 명령을 주입하거나, 대화 내용과 파일을 조용히 외부로 빼돌릴 수 있습니다. 편의를 위해 검색 몇 번으로 찾은 서버를 그대로 꽂았다가, 개발 환경 전체를 남에게 보여주는 사고로 이어질 수 있습니다.

세 위험의 공통점은 “에이전트가 믿고 실행한다”는 데 있습니다. 사람이라면 이상한 지시에 한 번쯤 되물어보지만, 에이전트는 입력을 성실하게 따르도록 설계돼 있어 의심하는 단계가 약합니다. 그래서 방어는 에이전트의 판단력에 기대는 대신, 애초에 위험한 입력과 권한이 닿지 못하게 바깥에서 울타리를 치는 방향이어야 합니다.

붙이기 전 권한·보안 체크리스트

  • [ ] 최소 권한만 준다: 도구마다 꼭 필요한 범위로만 권한을 좁힙니다. 파일 읽기만 필요한 도구에 삭제·쓰기 권한까지 주면, 탈취됐을 때 피해가 그만큼 커집니다. “서버 접근 권한”처럼 뭉뚱그린 권한 대신 “특정 작업 승인 권한”처럼 구체적으로 쪼갠 권한이 사고 시 피해 범위를 좁힙니다.
  • [ ] 출처를 확인한다: 공식이거나 검증된 서버만 붙입니다. 스타 수, 관리 이력, 코드 공개 여부를 보고, 정체불명 서버는 실험용 격리 환경에서만 테스트합니다.
  • [ ] 자격증명은 이슈어까지 확인한다: 도구마다 다른 스코프의 토큰을 씁니다. 2026-07-28 스펙의 이슈어 검증 요구사항은 클라이언트가 인증 서버를 명확히 확인하게 만드는데, 이 확인을 건너뛰면 여러 서버를 오가는 구조에서 자격증명이 엉뚱한 곳으로 흘러갈 여지가 남습니다.
  • [ ] 되돌리기 어려운 동작엔 사람 승인: 파일 삭제, 외부 전송, 결제, 배포처럼 되돌리기 힘든 동작은 자동 실행이 아니라 사람 확인을 거치게 둡니다.
  • [ ] 입력을 검증한다: 사용자 질의부터 도구가 돌려주는 메타데이터까지, 숨은 명령이나 의심스러운 문자열을 걸러낸 뒤 에이전트에 넣습니다.
  • [ ] 양방향을 모니터링한다: 도구 출력만 보지 말고, MCP를 오가는 메시지 자체를 로그로 남겨 이동 중에 섞인 숨은 지시를 잡습니다.
  • [ ] 권한을 정기적으로 감사한다: 한 번 준 권한은 방치되면 쌓입니다. 주기적으로 도구별 권한과 역할 범위를 다시 보고, 안 쓰는 접근 권한(권한 크리프·오래된 접근)을 회수합니다.
  • [ ] 롤백 경로를 미리 정한다: 이상 징후가 확인되면 즉시 권한을 회수하거나 서버 연결을 끊을 수 있는 절차를 사고 전에 정해둡니다. 사고 발생 후 절차를 새로 만들면 늦습니다.

실사용 설정 워크플로: 읽기부터, 쓰기는 승인

체크리스트를 실제 세팅으로 옮기면 순서가 나옵니다. 권장 순서는 이렇습니다. 처음엔 읽기 전용 도구부터 붙이고, 쓰기·삭제·외부 전송이 필요한 도구는 뒤로 미룹니다. 초기 며칠은 읽기 도구만으로 운영하며 로그에 이상한 호출이 없는지 확인하고, 그 뒤에 권한을 한 단계씩 넓히는 방식을 추천합니다. 관찰 기준으로는, 이 순서를 지키면 문제가 생겨도 원인을 좁은 범위에서 찾을 수 있습니다.

시크릿 관리도 도구별로 쪼갭니다. 모든 도구가 같은 API 키를 공유하면, 하나만 탈취돼도 전부 뚫립니다. 도구마다 필요한 스코프의 키만 주고, 개인 토큰과 회사 토큰은 환경을 나눠 둡니다. 이렇게 하면 사고가 나도 피해 범위를 한 도구 안으로 가둘 수 있습니다.

승인 게이트도 단계로 나누면 실무에서 덜 번거롭습니다. 읽기는 자동으로 허용하고, 쓰기는 한 번 확인, 삭제·외부 전송·배포처럼 되돌리기 어려운 동작은 이중 확인으로 두는 식입니다. 모든 걸 다 확인하게 만들면 결국 사람이 지쳐서 대충 승인하게 되니, 위험이 큰 동작에만 마찰을 남기는 게 오래 쓰는 설정입니다.

정기 감사도 세팅의 일부로 넣어두면 좋습니다. 한 달에 한 번 정도, 붙여둔 서버 목록을 열어 지난달에 실제로 쓴 도구가 무엇인지, 안 쓰는데 권한만 살아 있는 도구는 없는지 확인하는 겁니다. 2026-07-28 인증 하드닝 스펙이 나온 지금이 기존에 붙여둔 서버들의 인증 설정을 다시 훑어볼 좋은 시점이기도 합니다. 새 프로젝트를 위해 잠깐 붙였다가 잊어버린 서버, 테스트하려고 넓게 열어둔 권한이 이런 점검에서 대부분 걸립니다. 감사 주기를 정해두지 않으면 권한은 조용히 쌓이기만 하고, 어느 순간 무엇이 무엇에 접근할 수 있는지조차 파악하기 어려워집니다.

정리하면 안전한 MCP 세팅의 핵심은 “한 번에 다 열지 않기”입니다. 신입에게 첫날부터 모든 권한을 주지 않듯, 에이전트에게도 신뢰가 쌓인 만큼만 권한을 넓혀 주는 게 맞습니다. 표준이 생겼다고 이 순서를 건너뛸 이유는 없습니다.

언제는 굳이 안 붙여도 되나

모든 작업에 MCP를 붙일 필요는 없습니다. 단발성으로 파일 하나 정리하거나 짧은 코드를 고치는 정도면, 외부 도구를 연결하는 순간의 위험이 얻는 편의보다 클 수 있습니다. 특히 민감한 코드베이스나 고객 데이터가 있는 환경이라면, 검증되지 않은 서버를 붙이는 위험이 직접 몇 줄 수정하는 수고보다 크게 다가옵니다. 도구가 늘수록 관리할 권한과 감사 대상도 함께 늘어난다는 걸 잊으면, 편하려고 붙인 도구가 오히려 관리 부담과 보안 위험을 키우는 결과가 됩니다.

판단 기준은 “표준화됐는가”가 아니라 “우리 팀이 위 체크리스트를 실제로 운영할 준비가 됐는가”입니다. 표준은 도구 선택지를 넓혀줄 뿐, 운영 부담을 대신 져 주지는 않습니다.

실수 방지 TOP 5

  • 검색으로 찾은 서버를 바로 프로덕션에 연결: 정체불명 서버는 격리 환경에서 먼저 테스트하세요.
  • 모든 도구에 넓은 권한을 한 번에 부여: 최소 권한부터 시작해 필요할 때 넓히세요.
  • 되돌리기 어려운 동작을 자동 실행: 삭제·전송·배포에는 사람 승인 게이트를 두세요.
  • 한 번 세팅하고 방치: 권한은 시간이 지나면 쌓입니다. 정기 감사로 안 쓰는 접근을 회수하세요.
  • 인증 하드닝 스펙이 나왔다고 기존 서버 설정을 자동으로 재검토했다고 착각: 기존에 붙여둔 서버의 이슈어 검증·토큰 스코프는 직접 다시 점검해야 합니다.

FAQ

Q1. MCP 서버를 붙이면 무조건 위험한가요? 아닙니다. 공식·검증된 서버를 최소 권한으로 붙이고 되돌리기 어려운 동작에 사람 승인을 걸면 위험 대부분을 관리할 수 있습니다. 위험한 건 검증 없이 넓은 권한으로 붙이는 경우입니다.

Q2. 프롬프트 인젝션은 어떻게 막나요? 완전 차단은 어렵지만, 입력·도구 메타데이터를 검증하고, MCP 메시지를 양방향으로 모니터링하고, 되돌리기 어려운 동작에 사람 승인을 두는 다층 방어로 피해를 크게 줄일 수 있습니다. 2026-07-28 스펙의 인증 하드닝은 “누가 요청하는가”를 강화한 것이라 이 문제를 대신 해결해 주지 않습니다.

Q3. 툴 포이즈닝은 뭔가요? 도구의 설명이나 메타데이터를 조작해 에이전트가 그 도구를 오용하게 만드는 공격입니다. 그래서 도구를 붙일 때 설명만 믿지 말고 출처와 코드를 확인해야 합니다.

Q4. 개인 프로젝트에도 이 체크리스트가 필요한가요? 민감 데이터가 없다면 강도를 낮춰도 됩니다. 다만 최소 권한과 출처 확인, 삭제·전송 승인 정도는 개인 프로젝트에서도 습관으로 두는 게 좋습니다.

Q5. MCP 서버가 많을수록 좋은 건가요? 아닙니다. 서버가 늘수록 관리할 권한과 감사 대상, 공격 표면도 함께 늘어납니다. 실제로 쓰는 도구만 남기고 나머지는 정리하는 편이 안전합니다.

Q6. 회사 코드에 붙일 때 가장 먼저 볼 것은요? 시크릿 분리와 최소 권한입니다. 도구마다 필요한 스코프의 키만 주고, 개인·회사 토큰과 환경을 나눠 사고 범위를 한 도구 안으로 가두는 것부터 시작하세요.

Q7. MCP가 리눅스 재단으로 넘어갔다는 게 정확히 무슨 뜻인가요? 특정 회사 한 곳이 아니라 여러 회사가 참여하는 재단(Agentic AI Foundation)이 규격을 공동으로 관리한다는 뜻입니다. 2025년 12월 9일 발표됐고, AWS·Anthropic·Block·Bloomberg·Cloudflare·Google·Microsoft·OpenAI가 창립 멤버로 이름을 올렸습니다.

Q8. 2026-07-28 스펙 RC는 지금 바로 적용해야 하나요? 아직 RC(release candidate) 단계입니다. 급하게 전체 시스템에 적용하기보다, 인증 하드닝 항목을 먼저 검토하고 SDK 베타로 영향 범위를 확인한 뒤 단계적으로 반영하는 편이 안전합니다.

관련 글

공식 출처

이 글은 일반적인 보안 참고용이며, 실제 도입 환경의 위험 평가와 최종 설정 책임은 운영 주체에게 있습니다. (2026-08-03 기준 리프레시)