04 / AI NETWORK OPERATIONS · 2026-09-09

설정부터 속도 점검까지, 에이전트가 운영하는 공유기.

NAS의 OpenWrt와 스위치·무선 AP로 네트워크를 구성했습니다. 익숙한 공유기 기능을 옮기고, 에이전트가 설정·연결 점검·속도 비교·복구를 이어서 수행합니다.

복잡한 공유기 설정을 AI의 진단·조정·재측정 흐름으로 바꾸는 생성형 이미지 — 생성형 사용 장면사용 경험을 설명하는 생성형 이미지입니다. 실제 사진·기록 및 기능별 구현 상태는 아래에서 확인하세요.

BEFORE

메뉴를 찾아 설정하고, 다른 기기와 속도를 하나씩 재확인

AFTER

요청 → 상태 수집 → 설정 조정 → 연결·속도 재검증

666.6Mbps · 조정 후 순차 실측

149 / 805GHz 채널 / 폭 MHz

↻연결 확인·장애 복구

ASK. DIAGNOSE. ADJUST. VERIFY.

와이파이 최적화, AI에게 맡겼더니.

“와이파이가 느려. 다른 기기 연결은 유지하면서 조정해줘.”

01상태·채널 확인
02백업·설정 조정
03속도·다른 기기 확인
04유지 또는 복구

실제 측정 기록Mac Studio · Wi-Fi · 2026-09-09

조정 전 · 10:05 KST311.6 Mbps

5GHz 채널 40 · 동시 부하 측정

조정 후 · 10:14 KST666.6 Mbps

5GHz 채널 149 / 80MHz · 순차 측정

다운로드 실측값입니다. 전후의 부하 방식과 측정 시간 상한이 달라 동일 조건의 개선율 비교는 아닙니다. 조정 후 업로드 694.9Mbps, 다운로드 부하 지연 29.1ms도 기록됐습니다.

인터넷→NAS / OpenWrt→스위치→유선 장치 + 무선 AP

기능을 한곳에서 운영

주소 예약·서비스 전달·IPTV 연결 경로를 구성했습니다. WOL·VPN은 각각 이전 완료 여부를 확인해 확장합니다.

고장 났을 때도 이어서

DHCP 충돌을 진단·수정한 뒤 인터넷·NAS·웹·메일을 재확인한 작업 기록이 있습니다.

채널 변경은 AP의 관리 화면으로, 상태·로그 확인은 SSH로 수행했습니다. 재접속 후 두 Mac의 5GHz와 Pi의 2.4GHz 연결을 확인했습니다. 실제 통신은 OpenWrt·스위치·AP가 처리합니다.

FROM REQUEST TO RESULT

어떻게 만들었을까요?

01
기능 옮기기
IPTV 경로·주소 예약·포트 전달 등 필요한 기능을 정리합니다.
02
운영 구조 만들기
NAS는 라우팅, 스위치는 유선, AP는 무선을 맡습니다.
03
에이전트로 조정
연결 상태·로그·채널 설정을 확인하고 필요한 변경을 합니다.
04
재측정·복구
속도와 다른 기기 연결을 비교하고 문제 시 이전 설정으로 복구합니다.

COULD THIS WORK FOR YOU?

내 환경에서도 가능할까요?

AI 공유기는 와이파이를 어떻게 점검하고 설정을 바꾼 뒤 개선 여부를 확인하나요?

THE EVIDENCE & LIMITS

기록을 더 자세히 보기

어떤 기록으로 확인했나요?

2026년 8~9월의 Codex 작업 기록, 인계 문서와 보관된 프로그램을 대조한 사례입니다. 설명용 생성 이미지는 실제 설치 사진이 아닙니다. 각 검증은 기록된 날짜와 범위에 한정됩니다.

01익숙한 공유기 기능과 번거로운 설정

기존 ipTIME을 계속 쓰던 이유는 IPTV 연결 설정과 익숙한 주소 예약·포트포워딩·WOL·VPN 기능이었습니다. 운영자는 장비를 바꿀 때마다 메뉴를 다시 익히고 홈페이지·서버의 연결 설정까지 관리하는 부담을 설명합니다.

NAS의 OpenWrt VM에 라우팅·NAT·DHCP·DNS·방화벽을 구성하고, 비관리형 스위치와 무선 AP가 각각 연결을 맡게 했습니다. 기록으로 확인된 이전은 주소 예약·서비스 전달·IPTV용 연결 경로이며 WOL·VPN을 포함한 모든 기능의 완료를 주장하지 않습니다.

02에이전트가 설정하고 다시 확인한다

에이전트는 SSH와 장비 관리 화면으로 상태·로그·설정을 읽고 변경 전 백업, 필요한 설정 조정, 다른 장치 연결과 서비스 재확인을 이어서 수행합니다. DHCP 충돌을 찾고 바로잡은 뒤 인터넷·NAS·웹·메일 경로를 확인한 기록이 있습니다.

무선 최적화의 핵심은 채널이나 폭을 바꾼 뒤 빨라졌는지, 기존 기기가 계속 연결되는지를 함께 확인하는 과정입니다. 이 역할은 네트워크 관리이며 AI가 패킷마다 판단하는 구조는 아닙니다.

03무선 300Mbps대에서 600Mbps대: 실제 측정 기록

2026년 9월 9일 같은 Mac Studio의 Wi-Fi 인터페이스를 지정한 실제 측정 기록을 확인했습니다. 10:05에는 5GHz 채널40에서 다운로드 311.551Mbps·업로드 164.836Mbps, 10:14에는 채널149·80MHz에서 다운로드 666.586Mbps·업로드 694.916Mbps를 기록했습니다. 후측정의 다운로드 부하 지연은 약 29.1ms였습니다.

전측정은 networkQuality의 기본 동시 부하 방식, 후측정은 순차 방식이며 측정 시간 상한도 다릅니다. 따라서 같은 조건에서 채널 변경만으로 정확히 두 배 개선됐다는 실험은 아닙니다. 링크 협상 속도가 아니라 실제 전송량 측정값이라는 점과 측정 방식 차이를 함께 표시합니다.

에이전트는 주변 채널과 재접속 대역을 확인하고 5GHz 채널149·80MHz를 적용한 뒤 두 Mac의 5GHz 연결과 Pi의 2.4GHz 연결을 확인했습니다. 채널 설정은 해당 AP의 HTTPS 관리 화면으로, 상태와 로그 확인은 SSH로 수행했습니다.

같은 Mac Studio · 2026-09-09 · 전후 측정 방식 다름
항목	조정 전 관측	조정 후 관측
Time KST	10:05	10:14
Download	311.6 Mbps	666.6 Mbps
Upload	164.8 Mbps	694.9 Mbps
Test mode	Simultaneous load	Sequential load
5GHz channel	40	149 / 80MHz

0401 · 배선과 역할을 확인

기존 공유기·광단말·NAS의 WAN/LAN 포트를 구별하고 설정을 백업했다.

0502 · NAS에 OpenWrt 준비

NAS 가상머신에 OpenWrt를 구성하고 WAN과 LAN을 분리했다. DHCP·DNS·방화벽을 한 게이트웨이에 모았다.

0603 · 스위치와 AP로 연결

유선 장비는 스위치에, 무선 장비는 AP에 연결했다. AP의 별도 NAT·DHCP를 없애 같은 내부망으로 맞췄다.

0704 · 에이전트로 운영·검증

SSH로 상태와 백업을 확인하고 주소 예약·서비스 전달을 조정했다. DHCP 충돌을 바로잡은 뒤 인터넷·NAS·웹·메일 경로를 재검증했다.

08확인한 결과와 범위

2026-08-27 기록: OpenWrt VM·방화벽·NAT·DHCP·DNS와 인터넷 연결 정상.

당시 물리 링크: NAS LAN 2.5 Gbps, WAN 1 Gbps. 이는 링크 협상값이며 전 구간 실효 속도가 아니다.

한계도 기록: 전환 중 기존 공유기와 DHCP 충돌이 있었다. NAS나 VM이 멈추면 인터넷에도 영향이 있어 백업·복구 경로가 필요하다.

인터넷 → NAS의 OpenWrt VM → 스위칭 허브 → 유선 장비 / 무선 AP ⇢ 무선 장비. AI 운영자는 별도 SSH 관리선으로 연결.

같은 분야의 기록 →

와이파이 최적화, AI에게 맡겼더니.

어떻게 만들었을까요?

기능 옮기기

운영 구조 만들기

에이전트로 조정

재측정·복구

내 환경에서도 가능할까요?

기록을 더 자세히 보기