AI 에이전트는 SDN 이후 네트워크 관리 분야에서 일어난 가장 놀라운 변화이다

단 하나의 API 키, AI 에이전트, 그리고 동남아시아의 이중 NAT(double-NAT) 뒤에 있는 라우터 하나. 그 이후에 벌어진 일은 네트워크 관리에 대한 나의 생각을 완전히 바꾸어 놓았다.

나는 ASEAN 지역 전역에 퍼져 있는 UniFi 라우터들을 관리하고 있다. 어떤 것은 친구를 위해, 어떤 것은 친척을 위해, 하나는 자선 단체를 위해 관리한다. 이들은 서로 다른 도시, 서로 다른 ISP, 서로 다른 수준의 네트워크 적대 환경에 놓여 있다. 대부분은 캐리어급 NAT (Carrier-grade NAT) 뒤에 위치한다. 몇몇은 정부 방화벽이 전송 계층(transport layer)에서 VPN 프로토콜을 차단하는 지역에 있다.

UniFi 자체 관리 인터페이스는 항상 훌륭했다. Ubiquiti의 클라우드를 통해 접속 가능한 웹 대시보드는 장치 상태, 클라이언트 목록, 트래픽 통계, WiFi 경험 점수 등 모든 사이트에 대한 가시성을 제공한다. 이것이 내가 처음에 UniFi를 선택한 이유 중 하나이기도 하다. 중앙 집중식 GUI (Graphical User Interface)가 제대로 작동하기 때문이다.

하지만 GUI는 여전히 GUI일 뿐이다. 클릭과 메뉴, 드롭다운의 연속이다. 사이트가 하나일 때는 빠르고, 세 개일 때는 관리할 만하지만, 열 개가 되면 지루해진다. Ubiquiti가 인터페이스에 구축해 놓은 것 이상의 작업을 수행하려면 직접 툴링 (tooling)을 작성해야 한다. 나는 개발자가 아니었고, 내장된 대시보드만으로도 충분했기에 굳이 신경 쓰지 않았다.

그러다 AI 에이전트가 등장했고, 갑자기 계산법이 바뀌었다.

발견 (The Discovery)

UniFi에 API가 있다는 것은 알고 있었다. 컨트롤러를 위한 몇몇 REST 엔드포인트(endpoints)가 있고, 문서화가 모호하며, 아마도 읽기 전용(read-only)일 것이라는 이야기를 지나가듯 들은 적은 있었다. 하지만 나는 그것을 진지하게 살펴본 적이 없었다. 그걸 가지고 무엇을 할 수 있겠는가? 클라이언트 수를 조회하는 Python 스크립트를 작성할 것인가? 커스텀 대시보드를 만들 것인가? 개발 팀이 없다면 API는 그저 잠긴 문일 뿐이다.

하지만 AI 에이전트와 작업을 시작하면서, 나는 충동적으로 나의 UniFi 클라우드 API 키를 넘겨주었다. api.ui.com/v1에 있는 Site Manager API에서 기본적인 통계—대시보드 수준의 읽기 전용 정보—를 가져올 수 있을 것이라고 생각했다. 질문에 답하기 위한 컨텍스트(context)로 활용하기에 유용할 것이라고 말이다.

그런 다음 에이전트는 내가 완전히 놓치고 있었던 무언가를 발견했다. 바로 Cloud Connector API였다.

이 발견은 상당 부분 UniFi 커뮤니티에서 유지 관리하는 오픈 소스 라이브러리인 Art of WiFi PHP client 덕분입니다. AI 에이전트가 존재하기 수년 전부터, Erik Slooff와 기여자들은 이미 컨트롤러 API 표면을 매핑하고, 인증 방법(authentication methods)을 문서화했으며, 결정적으로 Site Manager API 키가 api.ui.com을 통해 로컬 컨트롤러로 프록시(proxy)될 수 있는 방법을 알아냈습니다. 그들의 connect_via_site_manager() 메서드가 저에게 힌트를 주었습니다. Cloud Connector는 문서화되지 않았던 것이 아니라, Ubiquiti가 자체 개발자 포털에 올리기 전에 이미 커뮤니티에 의해 문서화되어 있었습니다. 이러한 종류의 기초 작업이 있었기에 오늘날 에이전트들이 즉시 실행에 옮길 수 있는 것입니다. 누군가가 API를 이해하는 힘든 작업을 해두었기에, 우리 나머지는 그저 그것을 사용하기만 하면 됩니다.

POST /v1/connector/consoles/{id}/proxy/network/api/s/default/cmd/stamgr

이것은 developer.ui.com의 "Cloud Connector" 항목 아래에 문서화되어 있으며, GET, POST, PUT, DELETE, PATCH를 지원합니다. 이것은 별도로 큐레이션된 API가 아니라, 로컬 컨트롤러의 전체 API에 대한 투명한 프록시(transparent proxy)입니다. UniFi 웹 대시보드가 내부적으로 사용하는 것과 동일한 API입니다. 모든 엔드포인트(endpoint). 모든 기능. 제가 이미 가지고 있던 것과 동일한 클라우드 API 키로 인증됩니다.

저는 물었습니다: "원격 라우터에 연결된 모든 클라이언트를 보여줘."

10초 후, 에이전트가 다음과 같이 응답했습니다:

5GHz에서 -12 dBm, 324 Mbps인 Pixel-9-Pro-XL. 2.4GHz에서 -29 dBm인 Redmi-12. 28시간 동안 작동 중인 IPC 카메라. 19일의 업타임(uptime)을 기록 중인 Xiaomi 태양광 동글. -64 dBm인 C125 — 너무 많은 벽 때문에 고전 중.

SSH도 없습니다. VPN도 없습니다. 포트 포워딩(port forwarding)도 없습니다. 터널(tunnel)도 없습니다. 요청은 싱가포르의 VPS → Ubiquiti의 클라우드 → CGNAT 뒤에 있는 인접 ASEAN 국가의 UDM → 컨트롤러로부터 실시간 데이터를 가지고 다시 돌아오는 경로를 거쳤습니다.

에이전트는 단순히 쿼리(query)만 수행한 것이 아니었습니다. 그것은 자신이 본 것에 대해 _추론(reasoned)_했습니다. 신호가 약한 클라이언트들을 식별했습니다. 두 대의 AC-Pro AP가 모두 온라인 상태이지만 유휴(idle) 상태라는 점을 알아차렸습니다. 10명의 클라이언트 모두가 UDM의 내장 라디오에 몰려 있었습니다. AP 배치를 점검할 필요가 있었습니다. 제가 질문을 타이핑하는 동안, 에이전트는 사람이 대시보드를 5분 동안 응시한 뒤에나 할 법한 일을 이미 해냈습니다.

내가 왜 이전에는 API를 사용하지 않았는가

UniFi의 GUI는 진정으로 훌륭합니다. unifi.ui.com의 클라우드 대시보드는 모든 사이트(장치, 클라이언트, 토폴로지(topology), 트래픽, 알림)에 대해 깔끔하고 중앙 집중화된 뷰를 제공합니다. 일상적인 네트워크 관리 측면에서는 충분하고도 남습니다. 인터페이스가 이미 제가 필요로 하는 모든 것을 수행하고 있었기에, 프로그래밍 방식의 접근(programmatic access)이 없다는 결핍을 느껴본 적이 없었습니다.

하지만 그것이 함정입니다. GUI가 충분히 훌륭하면, API를 찾지 않게 됩니다. 그리고 API를 찾지 않으면, 그것이 무엇을 할 수 있는지 결코 발견할 수 없습니다. "충분히 좋은" 것과 "강력한" 것 사이의 간극은 숨겨진 채로 남습니다. 그 간극을 메우려면 소프트웨어를 작성해야 하고, 소프트웨어를 작성하려면 개발자가 필요하며, 개발자는 비싸고 귀하기 때문입니다.

AI 에이전트는 그 방정식을 바꿉니다. 에이전트가 곧 _개발자(developer)_입니다. 에이전트는 자연어를 API 호출(API calls)로 번역합니다. 인증(authentication), 페이지네이션(pagination), 에러 처리(error handling), 데이터 구조화(data structuring)를 처리합니다. 에이전트는 제가 앱을 작성할 필요를 요구하지 않습니다. 그저 제가 원하는 것을 설명하기만 하면 됩니다.

취약성 없는 CGNAT 킬러

캐리어급 NAT (Carrier-grade NAT, CGNAT)는 동남아시아 전역의 표준입니다. 포트 포워딩(port-forward)을 할 수 없습니다. DDNS를 사용할 수 없습니다. 외부에서 라우터에 먼저 도달하지 않는 한, 외부에서 라우터로 접속할 수 없습니다.

전통적인 해결책은 VPN 메쉬 (VPN mesh)입니다. Tailscale, ZeroTier, 또는 VPS를 통한 WireGuard 릴레이 (relay)를 사용하는 방식이죠. 한동안 저는 UniFi 콘솔 자체에 Tailscale을 직접 설치하는 것을 고려했습니다. 기술적으로는 가능합니다. UniFi OS는 내부적으로 Linux 기반이기 때문입니다. 하지만 모든 펌웨어 (firmware) 업데이트는 비지속성 파일 (non-persistent files)을 삭제합니다. 여러분의 Tailscale 바이너리, systemd 서비스, 설정 파일이 모두 사라집니다. 만약 펌웨어 업데이트와 정전이 동시에 발생한다면, 여러분은 접속이 차단될 것이며, 현장에 있는 사람은 SSH가 무엇인지조차 모를 것입니다.

Cloud Connector는 이 문제를 완전히 제거합니다. 라우터는 이미 Ubiquiti의 클라우드와 아웃바운드 연결 (outbound connection)을 유지하고 있습니다. 그것이 unifi.ui.com이 작동하는 방식입니다. API는 동일한 채널을 이용합니다. 설치할 것도 없고, 유지 관리할 것도 없으며, 펌웨어 업데이트로 인해 삭제될 것도 없습니다.

정부의 DPI (Deep Packet Inspection)가 SNI 필터링을 통해 VPN 프로토콜을 차단하는 지역에 배포할 때도 이 점은 중요합니다. *.tailscale.com은 일부 차단 목록 (blocklists)에 올라와 있습니다. 하지만 api.ui.com은 그렇지 않습니다. 이는 다른 모든 클라우드 서비스 API처럼 보이기 때문입니다. 이 경로는 제가 구축할 수 있는 그 어떤 VPN보다 더 은밀하며, 제가 아닌 Ubiquiti에 의해 유지 관리됩니다.

이것이 실제로 의미하는 바

네트워크 관리 (Network administration)는 복잡해졌습니다. 기술이 더 어려워졌기 때문이 아니라, 모든 것이 '더 많아졌기' 때문입니다. 더 많은 사이트, 더 많은 장치, 더 많은 VLAN, SSID, 방화벽 규칙, 클라이언트 유형, 위협 벡터 (threat vectors)가 존재합니다. 복잡성은 깊이가 아니라 규모(volume)에 있습니다.

AI 에이전트는 인터페이스를 클릭에서 대화로 바꿉니다:

• "지금 대역폭 (bandwidth)을 가장 많이 사용하는 클라이언트는 누구인가요?"
• "6.8 버전보다 낮은 펌웨어를 실행 중인 AP가 있나요?"
• "해당 MAC 주소를 향후 한 시간 동안 차단하세요."
• "오늘의 클라이언트 목록을 어제와 비교해 주세요. 새로운 것이 있나요?"
• "이번 주에 처음으로 연결된 모든 장치의 보고서를 생성하세요."
• "MAC 주소가 aa:bb:cc:dd:ee:ff인 iPhone 17을 감시하세요. 네트워크에 접속하는 즉시 Telegram으로 저에게 알림을 보내주세요."

에이전트는 번역, 인증, 페이지네이션 (pagination), 에러 처리 (error handling)를 수행합니다. 심지어 스스로 크론 잡 (cron jobs)을 예약하기도 합니다. 사용자가 스크립트를 작성하는 것이 아니라, 사양 (specification)을 작성하는 것입니다. "이 장치가 나타나면 알려줘"라는 말은 개발 팀을 위한 기능 요청 (feature request)이 아닙니다. 그것은 하나의 문장입니다.

하지만 진정한 해방은 쿼리 (querying)가 아니라, 바로 _구축 (building)_에 있습니다.

API는 항상 그곳에 있었습니다. 이제 무언가가 실제로 그것을 사용할 수 있게 되었습니다.

커넥터 API는 UniFi 컨트롤러에 대한 완전한 접근 권한을 제공합니다. 이는 다음과 같은 의미입니다:

자동화된 사이트 감사 (site audits). 매일 밤 실행되는 크론 잡 (cron job): 모든 장치의 인벤토리 (inventory)를 파악하고, 펌웨어 (firmware) 버전을 확인하며, 알 수 없는 MAC 주소를 표시하고, 이상 징후를 보고합니다. 개발자가 필요 없습니다. 에이전트가 직접 스크립트를 작성하고 예약합니다.

예측형 WiFi 모니터링. API는 AP별 채널 이용률 (channel utilization), TX 재전송률 (TX retry rates), 시간에 따른 클라이언트 신호 강도를 반환합니다. 에이전트는 간섭이 점진적으로 누적되는 AP를 포착하여, 누군가 느린 WiFi에 대해 불평하기 전에 채널 변경을 제안할 수 있습니다.

자연어 방화벽 규칙 (firewall rules). "오후 10시 이후에 이 IP에서 22번과 3389번 포트로 향하는 모든 트래픽을 차단해줘." 에이전트는 의도 (intent)를 방화벽 API에 매핑하고 설정을 적용합니다. UniFi의 방화벽 규칙 빌더를 일일이 탐색할 필요가 없습니다.

교차 시스템 통합 (cross-system integration). 에이전트는 이미 사용자의 캘린더, 이메일, 메시징 플랫폼에 접근할 수 있습니다. 운영 시간 중에 자선 단체 사무실의 라우터가 오프라인 상태가 되면, 아무도 보지 않는 대시보드의 빨간 점으로 남는 것이 아니라 현장에 있는 사람에게 메시지를 보냅니다.

하지만 이것들은 기본 요건 (table stakes)에 불과합니다. 정말 흥미로운 점은 구성 요소 (building blocks)들을 조합하기 시작할 때 일어나는 일입니다.

소프트웨어 정의 네트워크 (SDN), 이제 영어로 가능합니다

UniFi의 컨트롤러 API는 전체 SDN 툴킷 (toolkit)을 노출합니다. VLAN 생성, 네트워크 세분화 (network segmentation), 방화벽 규칙 체인 (firewall rule chains), VPN 설정 — WireGuard 사이트 간 (site-to-site), IPsec, OpenVPN, Teleport 등입니다. 이들은 각각 잘 문서화되어 있지만, 집합적으로 오케스트레이션 (orchestrate)하기에는 복잡합니다.

AI 에이전트는 이를 워크플로 (workflows)로 구성할 수 있습니다:

한 문장으로 끝내는 사이트 간 (Site-to-site) WireGuard. "WireGuard를 통해 싱가포르 사무실을 인접 국가에 있는 자선 단체의 네트워크에 연결하세요. 싱가포르에는 10.0.1.0/24를, 원격 사이트에는 10.0.2.0/24를 사용하세요. 설정을 양쪽 라우터에 적용하세요." 에이전트는 각 컨트롤러의 VPN 엔드포인트 (endpoints)를 호출하고, 터널 (tunnel)을 생성하며, 양측이 서로를 볼 수 있는지 확인한 후 결과를 보고합니다. 과거에는 두 개의 서로 다른 UniFi 인터페이스에서 동일한 메뉴를 일일이 클릭하며 한 시간 동안 공들여야 했던 작업이 이제는 대화 한 번으로 끝납니다.

유형별 클라이언트 세그멘테이션 (Client segmentation). "이 MAC 벤더 접두사 (MAC vendor prefix)를 가진 모든 장치를 VLAN 20으로 이동시키세요. 게스트 정책을 적용하고, 새벽 2시로 예약하세요." 에이전트는 클라이언트 목록을 조회하고, 벤더별로 필터링하며, VLAN 재할당을 구성하고, 전환 (cutover)을 예약합니다. 각 장치를 수동으로 재설정할 필요도, MAC 주소 스프레드시트를 관리할 필요도 없습니다.

동적 사고 대응 (Dynamic incident response). "만약 신호 세기가 -75 dBm 미만인 클라이언트가 연결되어 10분 이상 유지될 경우, 이를 플래그 (flag) 처리하고 요약본을 보내주세요." 이는 보통 스크립트 (script), 상태 추적을 위한 데이터베이스 (database), 그리고 알림 파이프라인 (notification pipeline)이 필요한 조건부 로직 (conditional logic)입니다. 에이전트는 이 세 가지를 단 하나의 명령으로 처리합니다.

구성 요소들은 항상 존재해 왔습니다. 변한 것은 이제 그것들을 조립할 수 있는 무언가가 생겼다는 점입니다.

경쟁 환경 (The Competitive Landscape)

벤더 (Vendor)	클라우드 API (Cloud API)	원격 쓰기 (Remote Write)	인증 (Auth)	상태 (Status)
UniFi	✅ 공식 (Official)	✅ 로컬 API로의 전체 프록시 (Full proxy)	API 키 (API key)	프로덕션 (Production), 문서화됨
...

UniFi의 커넥터 API (Connector API)는 해당 카테고리에서 진정으로 독보적입니다. 공식 지원, 전체 컨트롤러 액세스 (선별된 일부가 아닌), 간단한 API 키 인증, 그리고 추가 인프라 없이도 어떤 NAT 뒤에서도 작동하는 투명한 클라우드 프록시 (cloud proxying)를 결합한 유일한 API입니다.

시장의 신호: 최고의 API가 승리하지만, 그것을 사용할 수 있는 무언가가 있을 때만 가능하다

API에 관한 핵심은 이것입니다: 개발자가 없다면 API는 무용지물입니다. 업계에서 가장 우아하고, 포괄적이며, 문서화가 잘 된 API를 가지고 있더라도, 아무도 그 API를 기반으로 소프트웨어를 작성하지 않는다면 그것은 존재하지 않는 것이나 다름없습니다. 수년 동안 UniFi의 API는 기술적으로는 사용 가능했지만 실질적으로는 휴면 상태였습니다. 통합업체(integrators)와 MSP(Managed Service Providers)로 구성된 소규모 커뮤니티에는 알려져 있었지만, GUI(그래픽 사용자 인터페이스)가 충분히 훌륭했고 커스텀 툴링(custom tooling)을 작성하는 데 대부분의 사람들이 갖지 못한 리소스가 필요했기 때문에 다른 모든 이들에게는 무시되었습니다.

AI 에이전트(AI agents)는 그 방정식의 공급 측면을 변화시킵니다. 에이전트가 바로 개발자입니다. 에이전트는 어떤 언어로든, 즉각적으로, 어떤 API든 소비하고, 어떤 워크플로(workflow)든 구성하며, 어떤 통합(integration)이든 구축할 수 있습니다. 에이전트에게는 SDK(소프트웨어 개발 키트), 클라이언트 라이브러리(client library), 심지어 훌륭한 문서조차 필요하지 않습니다. API 레퍼런스(reference) 페이지를 읽고 바로 호출(call)을 시작할 수 있기 때문입니다.

이는 경쟁 역학이 변화함을 의미합니다. 최고의 API를 가진 벤더(vendor)는 더 이상 고객이 이를 활용하기 위해 개발자를 고용할 것이라는 데 도박을 걸지 않습니다. 그들은 고객이 AI 에이전트를 그 API에 투입할 것이라는 데 도박을 겁니다. 그리고 그 에이전트들은 벤더가 전혀 예상하지 못한 방식으로, 철저하고 창의적으로 API를 활용할 것입니다.

향후 5년을 살아남을 벤더는 최고의 라디오를 가진 기업이 아닐 것입니다. 그들은 AI 에이전트가 벤더가 출시하지 않은 기능들을 그 위에서 구축할 수 있을 만큼 API 표면(API surface)이 충분히 깊은 기업이 될 것입니다.

이것이 역할에 미치는 영향