새벽 3시, 핸드폰 알림이 울립니다. 서버 터졌습니다. 잠에서 일어나서 노트북 열고, SSH 접속하고, 로그 확인하고, 원인 찾고, 해결하고… 이게 개발자의 숙명이었죠? 이제 AI 에이전트가 새벽 3시에 대신 일하게 만들 수 있습니다.
MCP는 AI 앱이 파일·데이터베이스·명령 같은 외부 도구를 같은 규격으로 부르게 해 주는 공개 표준이라, 서버 점검처럼 반복되는 일을 AI 에이전트에게 맡기는 연결 고리로 쓸 수 있습니다. 다만 공식 사양이 도구 실행 전에 사용자의 명시적 동의를 받으라고 정해 두었듯, 처음에는 읽기 전용 도구부터 열고 서비스를 바꾸는 명령은 사람 승인 뒤로 미루는 구성이 안전합니다.
오늘은 MCP (Model Context Protocol)로 AI 에이전트가 서버를 직접 관리하게 만드는 방법을 다룹니다. Anthropic이 만든 프로토콜인데, AI가 외부 도구(파일 시스템, 데이터베이스, API)에 직접 접근해서 작업할 수 있게 해줍니다.
MCP란?
MCP는 AI와 외부 도구 사이의 표준 연결 규격입니다. 비유하자면, AI를 위한 “USB 포트” 같은 겁니다. 예전엔 각 도구마다 따로 연결해야 했는데, 이제 표준 포트가 생겨서 꽂기만 하면 됩니다.
지금까지 AI한테 “서버 상태 확인해줘” 하면, AI가 “이 명령어를 실행하세요” 하고 가이드만 줬습니다. 실행은 내가 직접 해야 했죠. MCP가 있으면 AI가 “알겠습니다, 처리했습니다” 하고 직접 실행합니다. AI가 읽기만 하던 시대에서, AI가 직접 손을 움직이는 시대로 넘어가는 겁니다.
MCP는 지금 누가 관리하나요?
MCP는 Anthropic이 2024년 11월 25일 오픈소스로 공개한 프로토콜입니다. 2025년 12월 9일에는 Anthropic이 MCP를 리눅스 재단 산하의 에이전틱 AI 재단(Agentic AI Foundation)에 기증했고, 이 재단은 Anthropic·Block·OpenAI가 함께 세우고 구글·마이크로소프트·AWS·Cloudflare·Bloomberg가 지원합니다. 특정 회사 전용 규격이 아니라 중립적인 공개 표준으로 관리된다는 뜻이라, 한 번 만들어 둔 MCP 서버를 Claude 말고도 MCP를 지원하는 여러 AI 도구에서 그대로 쓸 수 있습니다.
MCP 서버는 어떻게 설정하나요?
VPS에 MCP 환경을 구축합니다. 기본이 되는 것은 파일 접근을 맡는 공식 참조 서버 @modelcontextprotocol/server-filesystem입니다. 명령 실행(셸)을 맡길 서버는 공식 참조 목록에 없어 커뮤니티 구현을 따로 골라야 합니다(아래에서 자세히 설명합니다).
보안이 핵심입니다. filesystem 서버의 args에 경로를 지정하면, AI는 그 경로 안의 파일만 읽고 쓸 수 있습니다. /를 주면 시스템 전체를 마음대로 뒤지게 되니, /var/log, /etc/nginx, /home/user/projects처럼 필요한 경로만 지정하세요. shell 서버는 더 위험합니다 — AI가 임의의 명령어를 실행할 수 있거든요. 프로덕션 서버에서는 shell 접근을 아예 안 주거나, 화이트리스트 명령어만 실행 가능하게 제한하는 게 좋습니다.
Python으로 커스텀 MCP 서버도 만들 수 있습니다. check_disk_usage, clean_old_logs, check_service_status 같은 도구를 만들면, AI가 직접 호출할 수 있습니다.
공식 저장소의 설정 예시는 AI 앱의 설정 파일에 서버를 등록하는 방식입니다. Claude Desktop이라면 claude_desktop_config.json의 mcpServers 항목에 filesystem 서버를 추가하고, command에는 npx를, args에는 -y와 @modelcontextprotocol/server-filesystem, 그리고 AI가 접근해도 되는 디렉터리 경로를 차례로 적습니다. 윈도우에서는 npx를 cmd /c로 감싸 실행하라고 안내합니다.
여기서 오해하기 쉬운 점이 있습니다. filesystem 서버는 읽기 도구만 주는 서버가 아닙니다. 공식 README의 도구 표에는 read_text_file, list_directory, search_files 같은 읽기 도구와 함께 기존 파일을 덮어쓰는 write_file, edit_file, 원본을 지우고 옮기는 move_file이 나란히 있습니다. 로그만 보게 하려면 README가 안내하는 대로 Docker로 띄우고 해당 경로를 ro(읽기 전용) 옵션으로 마운트하세요.
셸 실행도 짚어 둘 부분입니다. 공식 참조 서버 목록(Everything, Fetch, Filesystem, Git, Memory, Sequential Thinking, Time)에는 셸 명령을 실행하는 서버가 없습니다. 셸 실행이 꼭 필요하면 커뮤니티 구현을 골라야 하는데, 그 경우 코드를 직접 읽어 보고 허용 명령을 목록으로 제한하는 것이 전제입니다. 직접 도구를 만들 때는 공식 Python SDK를 씁니다. pip install “mcp[cli]”로 설치하고 함수 위에 @mcp.tool() 데코레이터를 붙이면 그 함수가 AI가 부를 수 있는 도구가 되고, 함수의 타입 힌트가 곧 입력 형식이 되어 JSON 스키마를 따로 쓰지 않아도 됩니다. docstring은 도구 설명으로 쓰이니 check_disk_usage가 무엇을 확인하고 무엇을 돌려주는지 한두 줄로 분명히 적어 두세요.
AI 에이전트는 로그를 어떻게 분석하나요?
MCP filesystem 서버를 통해 AI가 /var/log에 접근할 수 있습니다. “최근 24시간 동안 nginx 에러 로그를 분석해줘”라고 하면 AI가:
- filesystem MCP로 로그 파일 읽기
- 최근 24시간 로그 필터링
- 에러 패턴 분석 (빈도, 유형)
- 원인과 해결책까지 제시
단순히 “429 에러가 1,247회 발생했습니다” 하고 숫자만 알려주는 게 아니라, “이 에러는 특정 IP에서 집중적으로 발생하고 있으니, 봇 공격일 가능성이 높습니다. Fail2ban이나 UFW 방화벽으로 차단하세요” 하고 원인과 해결책까지 분석합니다.
디스크가 차기 전에 AI가 정리할 수 있나요?
디스크가 가득 차면 서버가 멈춥니다. AI가 정기적으로 체크하고 정리하게 만듭니다. daily_health_check.py를 cron에 등록하면, 매일 아침 6시에 AI가 서버를 점검하고, 문제가 있으면 알림을 보냅니다.
로그 정리 정책도 중요합니다. 무조건 삭제하면 안 되고, 보존 기간을 정해야 합니다. 7일 이상 된 로그를 삭제하되, 중요한 로그는 /backup/logs/에 백업해두는 게 좋습니다. VPS 셸 스크립팅 자동화 가이드의 백업 스크립트와 연동하면 더 체계적인 로그 관리가 가능합니다.
장애 감지 및 알림 자동화
마지막으로, n8n과 MCP를 연동한 장애 감지 시스템입니다. MCP는 “두뇌” 역할, n8n은 “손발” 역할입니다. MCP가 “디스크 사용량 90% 감지, 정리 실행” 판단하면, n8n이 Discord 알림 발송, 이메일 전송을 담당합니다.
기존 모니터링(Prometheus + Grafana)은 수치를 수집하고 그래프를 그려줍니다. 하지만 “왜 95%인지”는 알려주지 않습니다. MCP 기반 AI 에이전트는 “CPU 95%의 원인이 nginx worker_connections 부족”까지 분석합니다. “데이터 수집은 Prometheus, 분석과 조치는 AI 에이전트” 이렇게 역할을 나누면 최고의 조합이 됩니다.
AI 분석은 수치가 모여 있어야 힘을 씁니다. 아직 서버 상태를 모으는 도구가 없다면 VPS 모니터링 가이드(Uptime Kuma + Netdata)로 감시부터 세워 두고, 그 위에 AI 에이전트를 얹는 순서가 덜 위험합니다.
MCP를 도입할 때 무엇을 조심해야 하나요?
1. 권한은 최소한으로. AI에게 root 권한을 주면 안 됩니다. 전용 사용자를 만들고, sudo 권한은 특정 명령어만 허용하세요. 예를 들어 systemctl restart nginx만 가능하도록 sudoers를 설정하는 것이 안전합니다.
2. 변경 사항은 반드시 로그로 남기기. AI가 실행한 모든 명령어와 결과를 파일에 기록하세요. 나중에 “왜 이 설정이 바뀌었지?”라고 할 때 추적할 수 있어야 합니다. MCP 서버 자체에 audit log 기능을 추가하는 것을 권장합니다.
3. 프로덕션에서는 dry-run 먼저. 실제 서비스에 영향을 주는 명령어(서비스 재시작, 패키지 설치 등)는 AI가 바로 실행하지 못하게 하고, 먼저 dry-run으로 결과를 확인한 뒤 사람이 승인하는 2단계 프로세스를 만드세요.
이 원칙들은 MCP 사양 자체에도 들어 있습니다. 사양의 보안 원칙은 도구를 임의 코드 실행으로 보고, 도구를 부르기 전에 사용자의 명시적 동의를 받으라고 정합니다.
도구는 임의의 코드 실행에 해당하므로 그만큼 조심해서 다뤄야 하며, 호스트는 어떤 도구든 호출하기 전에 사용자의 명시적 동의를 받아야 한다.(의역)
— 출처: Model Context Protocol Specification(2025-06-18) — Security and Trust & Safety(확인일 2026-10-31)
그래서 새벽에 사람 없이 돌아가는 흐름을 만들 때는 이 동의 단계를 무엇으로 대신할지 먼저 정해야 합니다. 새벽에는 읽기 도구만 쓰는 점검과 원인 분석까지만 돌리고, 재시작·삭제 같은 조치는 dry-run 결과를 알림으로 받은 뒤 아침에 사람이 승인하는 구성이 현실적인 출발점입니다.
AI 인프라 시리즈 정리
| 순서 | 주제 | 핵심 |
|---|---|---|
| 1 | Ollama + Open WebUI | 나만의 AI 서버 구축 |
| 2 | AI 코딩 툴 비교 | 뭘 쓸지 결정 |
| 3 | n8n 자동화 | AI 워크플로 |
| 4 | Vibe Coding | AI로 프로젝트 만들기 |
| 5 | RAG | AI에게 지식 주입 |
| 6 | MCP Agent | AI가 서버 관리 |
결국 VPS 1대 + AI = 1인 기업의 인프라가 됩니다. 한 번 구축해두면 계속 쓸 수 있으니까, MCP 설정만 해두면 여러분의 서버 관리가 완전히 달라질 겁니다. nicepang AI 카테고리에서 더 많은 AI 인프라 가이드를 확인할 수 있습니다.
관련 글
- AI랑 코딩하면 하루 만에 앱이 완성됩니다 — Vibe Coding 실전 튜토리얼
- ChatGPT가 내 문서를 모른다? 내 서버 AI에게 RAG로 가르쳐라
- crewAI로 다중 AI 에이전트 시스템 구축하기 — 멀티 에이전트 자동화 완벽 가이드
- VPS 보안 완벽 가이드 2026: UFW 방화벽·SSH hardening·SSL 설정부터 무료 취약점 점검까지
- 프롬프트 인젝션 방어 가이드 — LLM 보안과 안전한 AI 운영 (OWASP Top 10)
