AI 에이전트가 SDN 이후 네트워크 관리에 가장 큰 변화

출처: Dev.to

AI 에이전트는 SDN 이후 네트워크 관리에 있어 가장 좋은 변화이다

A single API key, an AI agent, and a router behind a double-NAT in Southeast Asia. What happened next changed how I think about network management.

단일 API 키와 동남아시아의 이중 NAT 뒤에 있는 라우터, 그리고 AI 에이전트. 그 이후에 일어난 일은 네트워크 관리에 대한 나의 생각을 바꾸었다.

I manage UniFi routers spread throughout the ASEAN region — some for friends, some for relatives, one for a charity. They’re in different cities, different ISPs, different levels of network hostility. Most sit behind carrier-grade NAT. A few are in places where the government firewall blocks VPN protocols at the transport layer.

저는 동남아시아 전역에 퍼져 있는 UniFi 라우터를 관리하고 있습니다 — 친구용, 가족용, 그리고 자선단체용으로 각각 배치되어 있죠. 각 도시와 ISP, 네트워크 적대성의 수준이 다릅니다. 대부분은 Carrier‑Grade NAT 뒤에 위치해 있고, 일부는 정부 방화벽이 전송 계층에서 VPN 프로토콜을 차단하는 환경에 있습니다.

UniFi’s own management interface has always been good. The web dashboard, accessible through Ubiquiti’s cloud, gives me visibility into every site: device health, client lists, traffic stats, WiFi experience scores. It’s one of the reasons I chose UniFi in the first place — the centralized GUI just works.

UniFi 자체 관리 인터페이스는 언제나 좋았습니다. Ubiquiti 클라우드를 통해 웹 대시보드에 접속하면 모든 사이트의 장치 상태, 클라이언트 목록, 트래픽 통계, Wi‑Fi 경험 점수를 한눈에 볼 수 있습니다. 이는 제가 처음 UniFi를 선택한 이유 중 하나이며, 중앙 집중식 GUI가 단순히 작동합니다.

But the GUI is still a GUI. It’s clicks and menus and dropdowns. It’s fast for one site, manageable for three, and tedious at ten. For anything beyond what Ubiquiti built into the interface, you’d need to write your own tooling. I never bothered, because I’m not a developer, and the built-in dashboard was good enough.

하지만 GUI는 여전히 GUI입니다. 클릭과 메뉴, 드롭다운을 포함합니다. 한 사이트는 빠르고, 세 개는 관리 가능하며 열 개가 되면 번거로워집니다. Ubiquiti가 인터페이스에 기본으로 제공한 기능 beyond(그 이상)에는 자체 툴을 작성해야 합니다. 개발자가 아니었기 때문에, 내장 대시보드가 충분하다고 생각했습니다.

Then AI agents arrived, and suddenly the calculation changed.

AI 에이전트가 등장하면서 계산이 급격히 바뀌었습니다.

I knew UniFi had an API. I’d heard about it in passing — some REST endpoints for the controller, vaguely documented, probably read-only. I never looked into it seriously because what was I going to do with it? Write a Python script to poll client counts? Build a custom dashboard? Without a team of developers, an API is just a locked door.

UniFi에 API가 있다는 것을 알고 있었습니다. 일부 REST 엔드포인트가 있다고 들었지만, 흐릿하게 문서화되어 있었고, 아마도 읽기 전용이었습니다. 진지하게 살펴보지는 않았습니다. 무엇을 할 수 있을까요? 클라이언트 수를 폴링하는 파이썬 스크립트를 작성할까, 맞춤 대시보드를 만들까? 개발자 팀이 없으면 API는 단순히 잠긴 문에 불과했습니다.

But when I started working with an AI agent, I gave it my UniFi cloud API key on a whim. I figured it could pull basic stats — the stuff from the Site Manager API at api.​ui.com/v1. Read-only. Dashboard-level. Useful as context for answering questions.

AI 에이전트와 작업하기 시작하면서,-UniFi 클라우드 API 키를 무심코 건넸습니다. 기본적인 통계를 가져올 수 있을 것이라고 생각했죠 — api.ui.com/v1의 Site Manager API에서 제공하는 데이터입니다. 읽기 전용이며 대시보드 수준이며, 질문에 대한 답변에 필요한 맥락이 됩니다.

Then the agent discovered something I’d completely missed: the Cloud Connector API.

그 후 에이전트는 내가 완전히 놓친 것을 발견했습니다: Cloud Connector API입니다.

I owe this discovery in large part to the Art of WiFi PHP client — an open- source library maintained by the UniFi community. Years before AI agents existed, Erik Slooff and contributors had already mapped the controller API surface, documented the authentication methods, and crucially, figured out how the Site Manager API key could proxy to local controllers through api.​ui.com. Their connect_ via_site_manager() method is what tipped me off. The Cloud Connector wasn’​t undocumented — it was documented by the community before Ubiquiti put it on their own developer portal. That kind of groundwork is why agents can hit the ground running today. Someone did the hard work of understanding the API so the rest of us can just use it.

이 발견은 대부분 Art of WiFi PHP 클라이언트 — UniFi 커뮤니티가 유지보수하는 오픈소스 라이브러리 덕분이라고 생각합니다. AI 에이전트가 등장하기 전부터 Erik Slooff와 기여자들은 이미 컨트롤러 API 표면을 매핑하고, 인증 방법을 문서화했으며, crucially(특히) Site Manager API 키가 api.ui.com을 통해 로컬 컨트롤러에 프록시될 수 있음을 파악했습니다. 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에 투명하게 프록시되는 API입니다. UniFi 웹 대시보드가 내부적으로 사용하는 동일한 API이며, 모든 엔드포인트와 기능을 제공합니다. 이미 보유한 클라우드 API 키로 인증됩니다.

“I asked: “Show me every client connected to the remote router.""

“원격 라우터에 연결된 모든 클라이언트를 보여 주세요.”

Ten seconds later, the agent returned:

10초 뒤 에이전트는 다음과 같이 회답했습니다:

Pixel-9-Pro-XL at -12 dBm, 324 Mbps on 5GHz. Redmi-12 at -29 dBm on 2.4GHz. IPC camera running 28 hours. Xiaomi solar dongle with 19 days of uptime. A C125 at -64 dBm — struggling through too many walls.

Pixel-9-Pro-XL: -12 dBm, 5GHz에서 324 Mbps. Redmi-12: -29 dBm, 2.4GHz. IPC 카메라가 28시간 작동 중. Xiaomi Solar Dongle이 19일간 가동을 유지하고 있습니다. C125: -64 dBm — 벽을 너무 많이 통과하며 약해 보입니다.

No SSH. No VPN. No port forwarding. No tunnel. The request went from a VPS in Singapore → Ubiquiti’s cloud → a UDM in a neighboring ASEAN country behind CGNAT → back with live data from the controller.

SSH 없음. VPN 없음. 포트 포워딩 없음. 터널 없음. 요청은 싱가포르의 VPS에서 시작해 Ubiquiti 클라우드를 거쳐 인근 ASEAN 국가의 UDM(게이트웨이)로, CGNAT 뒤에 있는 라우터로 돌아왔으며, 컨트롤러에서 실시간 데이터를 받아왔습니다.

The agent didn’t just query. It reasoned about what it saw. It flagged the weak-signal clients. It noticed both AC- Pro APs were online but idle — all 10 clients were clustered on the UDM’s built-in radio. The AP placement needed attention. In the time it took me to type the question, the agent had done what a human admin would do after five minutes of staring at a dashboard.

에이전트는 단순히 쿼리만 수행한 것이 아니라 observed(관찰)하고 reasoning(추론)했습니다. 약한 신호 클라이언트를 표시했고, 두 AC‑Pro AP가 온라인 상태이지만 idle(대기 중)인 것을 확인했습니다 — 10개의 클라이언트가 모두 UDM 내장 라디오에 집중되어 있었습니다. AP 배치가 조정이 필요했습니다. 질문을 입력하는 데 걸린 시간 동안, 에이전트는 인간이 대시보드에 stare(고정)하는 5분과 동일한 작업을 수행했습니다.

UniFi’s GUI is genuinely good. The cloud dashboard at unifi.ui.com gives you a clean, centralized view of every site — devices, clients, topology, traffic, alerts. For day-to-day network management, it’s more than adequate. I never felt the absence of programmatic access because the interface already did everything I needed.

UniFi GUI는 realmente 좋습니다. unifi.ui.com의 클라우드 대시보드는 모든 사이트의 장치, 클라이언트, 토폴로지, 트래픽, 알림을 청결하고 중앙 집중식으로 제공합니다. 일상적인 네트워크 관리에 있어 충분하며, 프로그램적 접근이 필요 없다는 느낌을 받은 적이 없었습니다.因为界面가 이미 필요한 모든 것을 수행했기 때문입니다.

But that’s the trap. When the GUI is good enough, you don’t reach for the API. And when you don’t reach for the API, you never discover what it can do. The gap between “good enough” and “powerful” stays hidden because crossing it would require writing software, and writing software requires developers, and developers are expensive and scarce.

하지만 그것은 함정입니다. GUI가 충분히 좋다면 API를 찾지 않습니다. API를 찾지 않으면 그 자체가 가질 수 있는 power(능력)를 발견하지 못합니다. “충분히 좋은” 것과 “강력한” 사이의 간극은 숨겨져 있으며, 이를 메우려면 소프트웨어를 작성해야 하는데, 이는 개발자를 필요로 하며, 개발자는 비싸고 부족합니다.

AI agents change that equation. The agent is the developer. It translates natural language into API calls. It handles authentication, pagination, error handling, data structuring. It doesn’t need me to write an app — it just needs me to describe what I want.

AI 에이전트는 그 방정식을 바꿉니다. 에이전트는 개발자 역할을 합니다. 자연어를 API 호출로 번역합니다. 인증, 페이지네이션, 오류 처리, 데이터 구조화를 수행합니다. 앱을 직접 작성할 필요가 없으며, 원하는 것을 설명하는 것만으로 충분합니다.

Carrier-grate NAT is the norm across much of Southeast Asia. You can’​t port-forward. You can’​t DDNS. You can’​t reach the router from outside unless it reaches you first.

동남아시아의 대부분 지역에서 Carrier‑Grade NAT가 일반적입니다. 포트 포워딩을 할 수 없고, DDNS도 설정할 수 없으며, 외부에서 라우터에 직접 접근하기 위해서는 라우터가 먼저 연결해야 합니다.

The traditional workaround is a VPN mesh — Tailscale, ZeroTier, or a WireGuard relay through a VPS. For a while, I considered installing Tailscale directly on the UniFi consoles themselves. It’s technically possible — UniFi OS is Linux under the hood. But every firmware update wipes non-persistent files. Your Tailscale binary, your systemd service, your config — gone. The next time there’s a power outage coinciding with a firmware refresh, you’re locked out, and the person on the ground doesn’t know what SSH is.

전통적인 우회책은 VPN 메쉬 — Tailscale, ZeroTier, 혹은 VPS를 통해 WireGuard 릴레이입니다. 일정 기간 동안-UniFi 콘솔에 직접 Tailscale를 설치하는 것을 고려했습니다. 기술적으로는 가능합니다 — UniFi OS는 Linux 기반이니까요. 하지만 펌웨어 업데이트마다 비지속 파일(임시 파일)이 삭제됩니다. Tailscale 바이너리, systemd 서비스, 설정 파일까지 모두 사라집니다. 전원 차단이 펌웨어 갱신과 동시에 발생하면 잠금 상태가 되고, 현장에 있는 사람은 SSH가 무엇인지 모릅니다.

The Cloud Connector eliminates this entirely. The router already maintains an outbound connection to Ubiquiti’s cloud — that’s how unifi.ui.com works. The API rides the same channel. Nothing to install. Nothing to maintain. Nothing to get wiped by a firmware update.

Cloud Connector는 이를 완전히 제거합니다. 라우터는 이미 Ubiquiti 클라우드에 아웃바운드 연결을 유지하고 있습니다 — unifi.ui.com이 작동하는 방식과 동일합니다. API는 동일한 채널을 사용합니다. 설치할 것이 없으며, 유지보수할 것도 없고, 펌웨어 업데이트로 삭제될 위험도 없습니다.

For deployments in regions where government DPI blocks VPN protocols via SNI filtering, this also matters. *.tailscale.com is on some blocklists. api.ui.com isn’t — it looks like every other cloud service API. The path is stealthier than any VPN I could build, and it’s maintained by Ubiquiti, not me.

정부 DPI가 SNI 필터링을 통해 VPN 프로토콜을 차단하는 지역에서는 이 점도 중요합니다. *.tailscale.com은 일부 차단 목록에 포함되어 있지만, api.ui.com은 그렇지 않으며 다른 클라우드 서비스 API와 동일하게 보입니다. 이 경로는 내가 직접 구축한 VPN보다 더 은밀하며, Ubiquiti가 유지보수합니다.

Network administration has gotten complicated — not because the technology is harder, but because we have more of everything. More sites. More devices. More VLANs, SSIDs, firewall rules, client types, threat vectors. The complexity is in the volume, not the depth.

네트워크 관리가 복잡해졌습니다 — 기술이 더 어려워서가 아니라 모든 것이 많아졌기 때문입니다. 사이트가 많아지고, 장치가 늘어나며, VLAN, SSID, 방화벽 규칙, 클라이언트 유형, 위협 벡터도 증가했습니다. 복잡성은 깊이보다 양에 있습니다.

An AI agent changes the interface from clicks to conversation:

• 가장 많이 대역폭을 사용하는 클라이언트는 누구인가요?
• 어느 AP가 6.8보다 오래된 펌웨어를 실행 중인가요?
• 해당 MAC 주소를 다음 시간 동안 차단하세요.
• 오늘의 클라이언트 목록을 어제의 목록과 비교해 보세요 — 새로운 항목이 있나요?
• 이번 주에 처음 연결된 모든 장치를 보고서로 작성하세요.
• iPhone 17 (MAC aa:bb:cc:dd:ee:ff)를 감시하세요. 네트워크에 접속하는 순간 텔레그램으로 알리세요.

The agent handles translation, authentication, pagination, error handling. It even schedules its own cron jobs — you don’t write the script, you write the specification. “Tell me when this device shows up” is not a feature request for a development team. It’s a sentence.

에이전트는 번역, 인증, 페이지네이션, 오류 처리를 수행합니다. 또한 자체 크론 잡을 스케줄링합니다 — 스크립트를 작성하지 않고 사양만 쓰면 됩니다. “이 장치가 나타날 때 알려 주세요”는 개발팀의 기능 요청이 아니라 한 문장입니다.

But the real unlock isn’t querying — it’s building.

하지만 진정한 해방은 쿼리 자체가 아니라 구축에 있습니다.

The connector API gives full access to the UniFi controller. That means:

• 자동 사이트 감사.
• 밤새 실행되는 크론 잡: 모든 장치를 인VENTORY(점검)하고 펌웨어 버전을 확인하며, 알 수 없는 MAC 주소를 표시하고 이상을 보고합니다. 개발자가 필요 없으며, 에이전트가 스크립트를 작성하고 일정을 잡습니다.

Predictive WiFi monitoring. The API returns per-AP channel utilization, TX retry rates, client signal strength over time. An agent can spot the AP that’s gradually accumulating interference and suggest a channel change before anyone complains about slow WiFi.

예측형 Wi‑Fi 모니터링. API는 각 AP의 채널 사용률, 전송 재시도 비율, 시간 경과에 따른 클라이언트 신호 강도를 반환합니다. 에이전트는 간접적인 간섭이 누적되는 AP를 감지하고, 사용자가 느린 Wi‑Fi에 불만을 제기하기 전에 채널 변경을 제안할 수 있습니다.

Natural language firewall rules.

“Block all traffic from this IP to ports 22 and 3389 after 10 PM.” The agent maps the int

“이 IP의 모든 트래픽을 오후 10시에 포트 22와 3389로 차단하세요.” 에이전트는 이를 해당 IP와 포트에 대한 방화벽 규칙으로 변환합니다.