이 글은 MCP 및 Agent Skills를 활용한 AI 지원 네트워크 운영에 관한 7부작 시리즈 중 파트 1입니다.

개인용 챗봇에서 공유 가능하고 재사용 가능한 인프라로: AI를 실제 네트워크 운영 팀원으로 변모시키는 MCP 서버, Agent Skills, 지식 카탈로그(knowledge catalogs) 및 안전 모델(safety models)에 대하여.

오늘날 AI를 사용하는 모든 엔지니어는 개인적인 고립된 환경(private silo)에서 작업합니다. 지원 엔지니어는 개인 채팅창에서 알람을 조사합니다. 아키텍트는 다른 채팅창에서 솔루션을 설계합니다. 개발자는 세 번째 채팅창에서 디버깅을 합니다. 각 대화에서 얻은 AI 지식은 채팅이 종료되면 사라집니다. 기술(Skills)과 MCP 서버는 한 사람에 의해 구축되고, 한 사람에 의해 사용되며, 결코 회사의 자산이 되지 못합니다.

한편, AI 애플리케이션을 구축하는 대부분의 팀은 프롬프트(prompt), 데이터 액세스(data access), 검색 로직(retrieval logic) 및 안전 점검(safety checks)을 분해하거나 공유할 수 없는 단일 코드베이스로 엮어버립니다. 프레임워크가 유행에서 뒤처지면, 그들은 처음부터 다시 구축해야 합니다.

더 나은 방법이 있습니다. Model Context Protocol (MCP)와 Agent Skills는 명확한 경계를 가진 모듈식의 조합 가능한 블록(modular, composable blocks)을 생성합니다. 한 번 구축하면 팀 전체가 공유할 수 있으며, 기술 환경이 변할 때 이에 맞춰 조정할 수 있습니다. 이 기사는 왜 네트워크 엔지니어가 이에 관심을 가져야 하는지, 오늘날의 환경은 어떠한지, 그리고 AI를 실제 장비에 올바른 방식으로 연결했을 때 무엇이 가능해지는지를 설명합니다.

문제점: 네트워크에 접근할 수 없는 AI

오늘날 네트워크 엔지니어가 실제 업무를 위해 AI 어시스턴트를 사용하려고 할 때 발생하는 상황은 다음과 같습니다:

시나리오 1 "sf-163-187의 활성 알람을 보여줘."
엔지니어는 CLI 출력을 복사하여 채팅창에 붙여넣고 AI에게 해석을 요청합니다. AI는 일반적인 네트워킹 지식을 바탕으로 알람의 의미를 추측합니다. AI는 해당 벤더의 알람 사전(alarm dictionary)을 알지 못합니다. 어떤 알람이 구성(configuration) 작업을 차단하는지도 알지 못합니다. AI는 그럴듯하게 들리지만 맞을 수도 있고 틀릴 수도 있는 답변을 내놓습니다.

시나리오 2 "3개의 ETX-2 유닛에 걸쳐 ERP 링을 설계해줘."
엔지니어가 AI에게 토폴로지 (topology)를 설명합니다. AI는 교과서적으로는 충분히 근접할지 모르지만, 특정 펌웨어 버전 (firmware version)에 바로 붙여넣어 사용할 수 없는 일반적인 ERP 링 설정 (configuration)을 생성합니다. 포트 명명 규칙 (port naming conventions)은 제품군마다 다릅니다. configure protection erp 구문 (syntax)도 제각각입니다. AI는 자신이 무엇을 모르는지조차 모릅니다.

시나리오 3 "sf-163-187의 위치 문자열을 TLV lab rack 3로 변경해줘."
그 누구도 운영 중인 스위치 (switch)에 대해 AI가 설정 변경을 수행하도록 허용하지 않을 것입니다. 그리고 그들이 그렇게 하지 않는 것은 옳습니다. 안전망 (safety net)이 없기 때문입니다. 백업 (backup)도 없고, 차이점 미리보기 (diff preview)도 없으며, 승인 게이트 (approval gate)나 감사 추적 (audit trail)도 없습니다. 이 위험은 용납할 수 없는 수준입니다.

세 가지 시나리오 모두 동일한 근본 원인을 공유합니다: AI가 장치와 연결되어 있지 않으며, 장치에 대한 지식이 없다는 점입니다. AI는 귀하의 네트워크 실재 (reality)가 아닌, 학습 데이터 (training data)를 바탕으로 답변하고 있습니다.

하지만 더 깊은 문제가 있습니다. 설령 한 명의 엔지니어가 개인적인 AI 채팅에서 이러한 시나리오들을 해결하더라도, 동일한 문제에 직면한 다음 엔지니어는 처음부터 다시 시작해야 합니다. 조사 내용, 지식, 안전 규칙 중 그 어느 것도 공유되지 않습니다. 모든 엔지니어는 동일한 컨텍스트 (context)를 다시 구축하고, 동일한 함정 (pitfalls)을 발견하며, 채팅창이 닫히면 사라져 버릴 답변을 만들어냅니다.

개인용 AI에서 팀용 AI로

변화의 핵심은 "AI가 없는 상태"에서 "AI를 사용하는 상태"로의 전환이 아닙니다. 그것은 개인용 AI (personal AI)에서 팀용 AI (team AI)로, 즉 "한 명의 엔지니어가 AI를 사용할 수 있는가"에서 "팀이 AI 조사 내용, 지식, 그리고 인프라 (infrastructure)를 공유할 수 있는가"로의 전환입니다.

이것은 이론적인 이야기가 아닙니다. 비전은 다음과 같습니다: 여러 엔지니어와 AI 에이전트(AI agents)가 동일한 조사(investigation)를 수행하는 공유 워크스페이스(shared workspace)입니다. 지원(support), 아키텍처(architecture), 개발(development) 등 서로 다른 역할의 사람들이 기여하고, 전문화된 에이전트들이 각기 다른 도메인을 처리합니다. 네트워크 에이전트는 MCP를 통해 장치에 연결하고, 문서화 에이전트는 매뉴얼과 릴리스 노트(release notes)를 검색하며, 개발 에이전트는 Git 히스토리와 Jira를 검색합니다. 하나의 공유된 조사, 다수의 에이전트, 가시적인 세션(sessions), 그리고 근본 원인(root cause), 뒷받침하는 증거, CLI 출력, 관련 이슈, 매뉴얼 참조, 권장 조치(recommended action)를 결합한 구조화된 출력(structured output)이 제공됩니다.

이것이 "또 다른 챗봇(another chatbot)"과 인프라(infrastructure)의 차이입니다. 기술과 MCP 서버는 개인의 도구가 아닌 회사의 자산이어야 합니다. 노트북 한 대에 있는 MCP 서버는 프로토타입(prototype)입니다. 여러 엔지니어가 다수의 AI 에이전트에게 작업을 큐(queue)에 넣고, 모든 조사를 확인하며, 어떤 세션이든 재개할 수 있는 협업 허브(collaboration hub)가 결합된 MCP 서버가 바로 인프라입니다.

This is the difference between

그림 1 "또 다른 챗봇"과 인프라의 차이

지원 엔지니어가 펌웨어 업그레이드 후 핵심 기능이 소실된 장치에 대한 케이스(case)를 오픈할 때, 세 가지 역할이 협업합니다: 지원 엔지니어는 장치 상태를 확인하고, 아키텍트는 설계를 바탕으로 예상 동작을 검증하며, 개발자는 커밋 히스토리(commit history)와 알려진 이슈(known issues)를 확인합니다. 세 명의 AI 에이전트가 이들을 지원합니다: 네트워크 에이전트(장치 CLI + SNMP), 문서화 에이전트(매뉴얼 + 릴리스 노트), 그리고 개발 에이전트(Git + Jira + CI). 에이전트들은 각자의 터미널 타일(terminal tile)에서 병렬로 작동하며, 팀은 이 세 가지를 하나의 뷰(view)에서 확인합니다. 근본 원인, 증거, CLI 출력, Jira 이슈, 매뉴얼 참조, 권장 조치로 구성된 구조화된 출력은 세 에이전트의 작업으로부터 모두 취합되어 완성됩니다.

MCP의 실체 (네트워크 엔지니어를 위한 설명)

MCP는 2024년 말 Anthropic에 의해 도입된 개방형 프로토콜이며, 현재 modelcontextprotocol.io에서 커뮤니티 프로젝트로 관리되고 있습니다. 이 프로토콜은 AI 애플리케이션이 외부 시스템에 연결되는 방식을 표준화합니다. 네트워크 엔지니어를 위한 NetPilot MCP 가이드의 설명처럼, 만약 여러분이 벤더 API들이 과거 SNMP가 MIB를 통해 약속했던 것처럼 하나의 스키마 언어를 공유하기를 바랐다면, MCP는 바로 그 아이디어를 AI 에이전트용으로 구현한 것입니다. 현재 Claude, GitHub Copilot, OpenAI Codex, Cursor, JetBrains를 포함한 주요 AI 및 개발 도구 전반으로 채택이 확대되고 있습니다.

프로토콜 사양(protocol specification)은 세 가지 전송 방식(transports)을 정의합니다: stdio (로컬 하위 프로세스, 데스크톱 호스트의 기본값), Streamable HTTP (원격/멀티 테넌트를 위한 단일 엔드포인트), 그리고 하위 호환성을 위한 SSE입니다. 아키텍처는 다음과 같이 직관적입니다:

• **MCP 서버 (MCP servers)**는 시스템(장비 CLI, SNMP 스택, 인벤토리 파일 등)을 래핑(wrap)하여 세 가지 요소를 노출합니다: 도구 (tools) (타입이 지정된 호출 가능한 함수), 리소스 (resources) (읽기 가능한 데이터), 그리고 프롬프트 (prompts) (재사용 가능한 템플릿).
• **MCP 클라이언트 (MCP clients)**는 Claude Code, Claude Desktop, GitHub Copilot, OpenAI Codex와 같은 AI 애플리케이션 내부에 존재하며, stdio(로컬) 또는 streamable HTTP(원격)를 통해 서버에 연결합니다.
• AI 모델은 여러분의 장비와 직접 통신하지 않습니다. 모델은 JSON 스키마가 포함된 도구 정의 목록을 보고 어떤 도구를 호출할지 결정하며, 클라이언트가 서버를 통해 해당 호출을 실행합니다. 무엇을 노출하고 무엇을 노출하지 않을지는 모델이 아닌 서버가 결정합니다.

마지막 포인트는 들리는 것보다 훨씬 중요합니다. 서버는 게이트키퍼(gatekeeper) 역할을 합니다. 서버는 읽기 명령을 화이트리스트(whitelist)에 등록하거나, 명시적인 확인 없이는 쓰기 명령을 거부하고, 응답에서 자격 증명(credentials)을 삭제(redact)하며, 모든 작업을 감사 추적(audit trail)에 기록할 수 있습니다. 모델은 이러한 제어 기능을 우회할 수 없는데, 그 이유는 제어 기능이 프롬프트가 아닌 서버에 존재하기 때문입니다.

그림 2 — MCP 서버는 게이트키퍼(gatekeeper) 역할을 하며, 모델은 장치와 직접 통신하지 않습니다

만약 이전에 Python과 Netmiko를 사용하여 네트워크 자동화(network automation)를 구축해 본 경험이 있다면, 다음과 같이 생각하면 쉽습니다. MCP는 기존의 스크립트를 AI 에이전트가 워크플로우를 하드코딩(hardcoding)하지 않고도 스스로 발견하고, 이해하며, 안전하게 호출할 수 있는 무언가로 변환해 주는 계층(layer)입니다. AI는 사용자가 요청한 내용에 따라 어떤 도구들을 체인(chain)으로 연결할지 결정합니다. 사용자는 해당 도구들이 무엇을 할 수 있고 무엇을 할 수 없는지를 결정합니다.

오늘날의 현황: 어떤 곳에서 네트워크 장비용 MCP 서버를 제공하는가?

저는 직접 구축하기 전에 기존의 현황을 조사하는 데 시간을 할애했습니다. 아래 조사는 2026년 7월 웹 검색을 통해 발견된 공개 GitHub 저장소(repos) 및 벤더(vendor) 문서를 기반으로 하며, 이는 실제 운영 환경에 대한 보증이 아닌 여러분의 자체적인 연구를 위한 시작점으로 간주하십시오. 실제 장비에 연결하기 전에 각 프로젝트의 인증 모델(auth model), 쓰기 범위(write scope), 감사 로깅(audit logging)을 반드시 검토하십시오.

2026년 중반 기준으로 현재 나와 있는 현황은 다음과 같습니다:

Cisco (가장 넓은 범위의 커버리지)

Cisco의 RADkit 원격 자동화 SDK(remote-automation SDK)는 CiscoDevNet GitHub 조직(org) 산하의 MCP 서버를 통해 인증서 기반 인증(certificate-based auth)을 통한 장치 인벤토리, CLI 실행, 설정 커밋(config commits) 기능을 제공합니다. 이는 "공식 제품이 아님"으로 표시되어 있지만 Cisco 자체 조직 산하에 존재합니다. 또한 구조화된 show-command 파싱을 위해 pyATS/Genie를 래핑(wrapping)한 커뮤니티 서버와, 라우팅 정책 및 장치 상태 조회를 위한 경량화된 network-assistant 서버도 있습니다. Cisco는 어떤 벤더보다도 가장 넓은 커버리지를 보유하고 있습니다.

Juniper (최상의 벤더 공식 지원)

Juniper는 자체 GitHub 조직(org)에 공식 MCP 서버를 유지 관리하며, stdio 및 streamable-http 전송(transports), Docker 이미지, 토큰 기반 인증(token-based auth)을 제공합니다. 운영 쿼리(operational queries)와 설정 로드/커밋(config load/commit)을 지원합니다. 또한 컨트롤러 레벨의 Paragon Automation을 위한 routing-director MCP 서버도 보유하고 있습니다. 커뮤니티에서는 VS Code/Copilot으로 테스트된 PyEZ 기반 서버를 구축하기도 했습니다.

Palo Alto Networks

Palo Alto Networks는 공식 서버를 배포하지만, 이는 PAN-OS 장치 관리 도구가 아닌 MCP 트래픽을 위한 보안 릴레이(security relay, Prisma AIRS)입니다. 장치 관리(device-management) 측면은 커뮤니티 서버들이 담당하고 있습니다: 읽기 전용 모드 토글, XPath 인젝션에 대한 정규식(regex) 검증 입력, 명시적인 2단계 쓰기-커밋(write-commit) 흐름, 그리고 .mcpb 데스크톱 확장(Desktop Extension) 지원 및 OS 키체인(OS-keychain) 자격 증명 저장 기능을 갖춘 하나의 서버 등이 있습니다.

Arista

공식에 준하는 CloudVision MCP 서버는 Claude/에이전트(agents)와 CloudVision의 REST API를 연결합니다. 커뮤니티 서버들은 TOML 장치 인벤토리(device inventories)와 함께 Arista 실습을 위한 Netmiko를 래핑(wrap)하여 show/VLAN/BGP/LLDP 쿼리 및 spine/leaf 플릿(fleets) 전반에 걸친 상태 확인(health-check) 프롬프트를 제공합니다.

Fortinet

커뮤니티 서버들은 200개 이상의 타입 지정 도구, 비동기 HTTP 클라이언트(async HTTP clients), 보안 우선 기본값(security-first defaults)을 통해 FortiOS 7.6.x를 지원합니다. 내장된 안전 점검(safety checks) 기능과 함께 중앙 집중식 정책/장치 관리를 위한 FortiManager MCP도 존재합니다.

Others

MikroTik은 가장 활발한 분야를 보유하고 있습니다. 117개의 타입 지정 도구(typed tools), dry-run 미리보기, 라우터별 서킷 브레이커(circuit breakers), 그리고 RBAC(역할 기반 액세스 제어)를 갖춘 MikroMCP를 포함하여 6개의 커뮤니티 서버가 존재합니다. Huawei VRP의 경우 공백이 존재합니다. 물리적 하드웨어를 위한 성숙한 MCP 서버는 존재하지 않지만, VRP를 위한 NAPALM 드라이버가 래핑(wrap)을 위한 빌딩 블록을 제공합니다. Linux/Windows 쉘 MCP 서버들이 존재하지만, 이는 호스트 관리용이며 네트워크 장비용 도구는 아닙니다.

벤더 간 공통 패턴 (The cross-vendor pattern)

이 서버들의 대부분은 복제할 가치가 있는 공통적인 안전 패턴을 공유합니다: 읽기 전용 환경 변수 토글, dry-run/commit 전 diff(차이점 확인) 흐름, 가공되지 않은 쉘 문자열 대신 화이트리스트 기반 명령 사용, 그리고 비밀 정보 삭제(secret redaction) 기능이 포함된 감사 로그(audit logging) 등이 있습니다. 또한, 멀티 벤더(multi-vendor) 지원을 위해 Netmiko/NAPALM 장치 유형 문자열이 직접 매핑됩니다. arista_eos, cisco_ios, huawei_vrp, junos, rad_etx는 모두 지원되는 Netmiko 플랫폼이므로, 단일 래퍼(wrapper)로 하나의 코드베이스에서 여러 벤더를 커버할 수 있습니다.

왜 직접 구축해야 하는가?

이처럼 기존 서버들이 이미 존재하는데, 왜 직접 구축해야 할까요? 여섯 가지 이유가 있습니다:

1. 사용 중인 장비가 지원되지 않음