약 17분 읽기
IoT 기기가 20개가 되고 나서
처음 몇 개의 IoT 기기를 사용할 때는 별 문제가 없었다. 하지만 10개를 넘고 20개에 가까워지면서 네트워크가 점점 복잡해졌다. 기기의 수가 늘어날수록 관리와 유지보수의 필요성을 절실히 느꼈다. 가령, 별다른 설정 없이 사용하는 기본 설정이 문제를 일으킬 때가 많았다. 한두 대의 기기라면 대수롭지 않게 넘길 수 있었겠지만, 수십 대가 동시에 문제를 일으키면 상황이 달라진다.
기기들이 제멋대로 작동하거나 응답이 느려지는 경우도 빈번했다. 특히 Zigbee 같은 프로토콜을 사용하는 기기는 주파수 간섭 문제를 자주 일으켰다. 채널 설정이 잘못되면 명령을 내렸을 때 응답 시간이 길어졌다. 이 문제는 여러 번의 시행착오를 거쳐 겨우 해결할 수 있었다. 적절한 주파수 채널 설정이 얼마나 중요한지를 깨닫는 데 시간이 걸렸다.
네트워크 보안도 큰 과제로 떠올랐다. 값싼 IoT 기기의 특성상 보안 업데이트가 제때 이뤄지지 않는 경우가 많았다. 메인 네트워크와 같은 환경에 두는 것이 위험하다고 판단했다. 결국 네트워크를 분리하여 IoT 기기 전용 환경을 만들기로 결정했다. 초기에는 설정 과정에서 여러 번의 실수가 있었지만, 점차 익숙해지면서 안정적인 환경을 구축할 수 있었다.
물론, 이렇게 많은 IoT 기기를 운영하는 데는 적지 않은 노력이 필요했다. 특히 네트워크를 분리하면서 발생한 DHCP 충돌 문제는 예기치 못한 난관이었다. 새로운 네트워크 대역을 설정하는 데 시간이 걸렸지만, 이 과정에서 네트워크 관리의 필요성을 다시 한 번 실감하게 되었다. 작은 실수 하나가 전체 시스템에 큰 영향을 미칠 수 있다는 것을 알게 되었다.
펌웨어 업데이트를 안 해주는 기기들
스마트홈 기기를 사용하면서 경험한 또 다른 문제는 바로 펌웨어 업데이트가 지원되지 않는 기기들이었다. 많은 IoT 기기들은 제작사가 비용 절감을 위해 펌웨어 업데이트 지원을 생략한다. 이로 인해 보안 취약점이 발생할 가능성이 높아졌다. 특히, 값싼 IoT 기기들은 기본적인 보안조차 취약하다는 문제점을 가지고 있다.
이러한 기기들은 네트워크에 연결된 다른 장치들에게도 위협이 될 수 있다. 만약 어떤 기기가 해킹당한다면, 그 기기를 통해 다른 기기들로 침투할 수 있는 길이 열리게 된다. 이런 상황을 방지하기 위해서는 네트워크를 물리적으로 분리하는 것이 필요했다. IoT 기기들을 메인 네트워크와 분리해 놓으면, 해킹된 기기가 다른 기기들로의 직접적인 접근을 막을 수 있다.
펌웨어 업데이트가 안 되는 기기를 선택하는 것은 결국 장기적으로 더 큰 문제가 될 수 있다는 것을 알게 되었다. 기능이 우수해 보이는 기기라도, 펌웨어 업데이트가 지원되지 않는다면 망설여야 한다. 지속적인 보안 패치를 받을 수 없는 기기를 네트워크에 두는 것은 무척 위험한 선택이다. 이런 이유로, 앞으로는 펌웨어 업데이트가 가능한 기기만을 선택할 계획이다.
전구가 3초 뒤에 켜지던 이유
스마트홈 시스템에서 가장 짜증나는 경험 중 하나는 바로 전구가 지연되면서 켜지는 것이다. 처음에는 단순히 네트워크 트래픽이나 기기 문제라고 생각했다. 그러나 사용자가 증가하고, 기기가 많아지면서 문제는 더욱 심각해졌다. 어느 순간부터 지연 시간이 3초 이상씩 발생하자, 근본적인 문제를 찾기 위해 조사에 들어갔다. 그 결과, Zigbee와 WiFi 간의 채널 간섭이 주요 원인임을 알게 되었고, 이를 해결하기 위해 채널 설정을 최적화하기로 결정했다.
Zigbee 네트워크는 2.4GHz 주파수 대역을 사용하기 때문에 WiFi와 간섭이 일어나기 쉽다. 특히 Zigbee 채널 11번과 14번은 WiFi의 주로 사용되는 1/6/11번 채널과 겹칠 가능성이 높다. 이로 인해 Zigbee 신호가 방해를 받아 전구의 응답 속도가 떨어졌다. 따라서 Zigbee 채널을 WiFi와 겹치지 않는 채널 20번이나 25번으로 설정하여 문제를 해결하고자 했다.
# zigbee2mqtt/data/configuration.yaml serial: # ttyUSB0 로 두면 재부팅 때 번호가 밀린다. by-id 로 고정한다 port: /dev/serial/by-id/usb-ITead_Sonoff_Zigbee_3.0_USB_Dongle-if00 adapter: ezsp advanced: # Zigbee 도 2.4GHz 다. 와이파이 1/6/11 채널과 겹치면 응답이 느려진다. # WiFi 1 → 2412MHz : Zigbee 11,12,13,14 # WiFi 6 → 2437MHz : Zigbee 15,16,17 # WiFi 11 → 2462MHz : Zigbee 21,22,23 # 20 과 25 가 비교적 깨끗하다. 25 로 갔다. channel: 25 transmit_power: 20 network_key: GENERATE pan_id: GENERATE mqtt: server: mqtt://192.168.30.10:1883 base_topic: zigbee2mqtt frontend: port: 8099 # 채널을 바꾸면 모든 기기를 다시 페어링해야 한다. 20개를 다시 붙였다.
Zigbee 채널을 와이파이와 겹치지 않게 — 이걸 몰라서 3초 지연을 겪었다
코드를 작성하면서 가장 신경 썼던 부분은 새로운 채널 설정이 기존 네트워크와의 호환성을 유지해야 한다는 점이다. 그래서 기존 세팅을 변경하지 않고도 Zigbee 채널만 독립적으로 조정할 수 있도록 했다. 이렇게 해서 응답 지연 문제가 크게 개선되었고, 전구는 이제 즉각적으로 켜지기 시작했다. 이렇게 채널 간섭 문제를 해결하면서 네트워크의 다른 부분에도 긍정적인 영향을 미쳤다. 기기 간 연결이 더 안정적이면서 빠르게 이루어지게 되었다.
공유기 2대로 물리 분리
스마트홈 환경에서 IoT 기기의 수가 늘어나면서 보안과 네트워크 간섭 문제가 발생했다. 값싼 IoT 기기는 펌웨어 업데이트가 이루어지지 않아 보안에 취약하고, 2.4GHz 대역의 채널 포화로 인해 응답 지연이 생겼다. 이를 해결하기 위해 물리적으로 네트워크를 분리하기로 했다. 메인 네트워크와 IoT 네트워크를 각각의 공유기를 통해 분리하여 보안성을 강화하고 네트워크 간섭 문제도 완화할 수 있었다.
보안 강화를 위해 IoT 네트워크에서 메인 네트워크로의 접근을 차단하는 것이 필요했다. 이를 위해 IoT 전용 공유기에 설정을 추가해 메인 네트워크로의 접근을 막았다. 이 설정은 NAT(네트워크 주소 변환)가 이중으로 걸리게 되어 접속 속도가 약간 느려질 수 있지만, IoT 기기가 외부로 접속할 필요가 없기 때문에 큰 문제가 되지 않았다.
#!/bin/sh
# IoT 공유기(192.168.30.0/24)는 인터넷만 되면 된다.
# 메인 망(192.168.0.0/24)으로는 넘어오지 못하게 한다.
MAIN="192.168.0.0/24"
IOT="192.168.30.0/24"
HA="192.168.0.10" # Home Assistant 가 있는 홈서버
# IoT → 메인 차단 (기본)
iptables -I FORWARD -s $IOT -d $MAIN -j DROP
# 예외 1: HA 가 IoT 기기를 제어해야 하니 메인 → IoT 는 허용하고
# 그 응답만 되돌아올 수 있게 한다
iptables -I FORWARD -s $MAIN -d $IOT -j ACCEPT
iptables -I FORWARD -s $IOT -d $MAIN \
-m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
# 예외 2: IoT 기기 → MQTT 브로커(1883)만 열어준다
iptables -I FORWARD -s $IOT -d $HA -p tcp --dport 1883 -j ACCEPT
# 확인: IoT 쪽 기기에서
# ping 8.8.8.8 → 된다
# ping 192.168.0.10 → 안 된다 (1883 만 열림)
iptables -L FORWARD -n --line-numbers | head -20
IoT 망에서 메인 망으로 넘어오지 못하게 막기
이 설정으로 인해 IoT 기기가 메인 네트워크로 접근할 수 없게 되어 보안이 강화되었다. 추가로 NAT 이중화로 인한 속도 저하를 감수했지만, IoT 기기의 주된 기능이 내부 네트워크에서만 작동하므로 큰 영향을 받지 않았다. 그리고 이러한 물리적 분리 덕분에 스마트홈 환경의 안정성과 보안성이 동시에 개선되었다.
DHCP 대역이 겹쳐서 꼬인 것
IoT 네트워크를 따로 분리한 후, 뜻밖의 문제에 봉착하게 되었다. IoT 전용 공유기가 메인 네트워크와 동일한 IP 대역인 192.168.0.x를 사용하고 있어서 DHCP 충돌이 발생했다. 그 결과, 메인 네트워크와 IoT 네트워크 간의 라우팅이 꼬이는 상황이 종종 발생했다. IoT 기기들이 IP를 얻지 못하거나 잘못된 네트워크로 인식하는 문제가 생겨서 디버깅에 많은 시간을 소비했다.
이 문제를 해결하기 위해 IoT 전용 네트워크의 IP 대역을 192.168.30.x로 변경했다. 이로 인해 DHCP 충돌 문제는 사라졌고, 각 네트워크가 독립적으로 운영될 수 있었다. 네트워크 설정을 변경하는 작업은 쉽지 않았고, 기존에 설정해놓았던 장치들의 네트워크 정보를 다시 입력해야 하는 번거로움이 있었다. 하지만 이런 번거로운 작업을 감수한 덕분에 네트워크 안정성이 크게 개선되었다.
이 과정에서 네트워크 구조와 DHCP 설정의 필요성을 다시금 실감했다. IP 대역이 겹치지 않도록 관리하는 것이 얼마나 중요한지 알게 되었고, 무작정 기기를 추가하기보다는 네트워크 구조를 미리 설계하는 것이 중요하다는 것을 깨달았다. 또한, 네트워크 변경 후 모든 기기를 하나씩 재설정하면서 전체 시스템을 점검하는 기회를 가질 수 있었다. 이 과정은 시간이 많이 걸렸지만, 결국 스마트홈의 속도를 높이는 데 기여했다.
mDNS가 서브넷을 못 넘는다
스마트홈 시스템에서 가장 불편했던 부분 중 하나는 mDNS가 기본적으로 서브넷을 넘지 못한다는 점이었다. Home Assistant가 홈서버에 설치되어 있었는데, IoT 기기는 별도의 서브넷에 있었으므로 mDNS를 통한 자동 기기 검색이 어려웠다. mDNS가 서브넷을 넘지 못하면, 수동으로 IP 주소를 설정해야 하기에 관리가 번거로워졌다. 이를 해결하기 위해 다양한 접근법을 고려했지만, 결국 정적 라우팅과 함께 다른 방법을 사용하여 문제를 해결하기로 했다.
mDNS는 멀티캐스트를 사용해 같은 네트워크 내의 기기들을 검색하는데, 서브넷이 달라지면 이 멀티캐스트 패킷이 전달되지 않는다. 그래서 각 기기들이 서로의 IP를 알아야 하는 상황에서는 mDNS가 무용지물이 된다. 이 문제를 해결하기 위해, Zigbee 기기는 USB 동글을 통해 직접 연결하고, 와이파이 기기는 MQTT를 통해 통신하도록 했다. MQTT는 TCP/IP를 기반으로 하여 서브넷 간 통신이 가능하기 때문에, 홈서버와 IoT 기기가 서로 소통할 수 있게 해줬다.
services:
homeassistant:
image: ghcr.io/home-assistant/home-assistant:stable
container_name: homeassistant
restart: unless-stopped
# mDNS 검색(_hap._tcp, _googlecast._tcp)은 브리지 네트워크에서 안 된다.
# host 모드가 사실상 필수다.
network_mode: host
privileged: true
volumes:
- ./config:/config
- /etc/localtime:/etc/localtime:ro
environment:
- TZ=Asia/Seoul
mosquitto:
image: eclipse-mosquitto:latest
container_name: mosquitto
restart: unless-stopped
ports:
- "1883:1883" # IoT 망에서 붙어야 하니 여기는 열어둔다
volumes:
- ./mosquitto/config:/mosquitto/config
- ./mosquitto/data:/mosquitto/data
# mDNS 가 안 넘어가니 IoT 망 기기는 두 갈래로 붙인다
# Zigbee 기기 → USB 동글 직결 (네트워크를 아예 안 탄다)
# WiFi 기기 → MQTT 브로커 경유 (mDNS 불필요)
#
# 홈서버에 IoT 망 정적 라우트 추가
# ip route add 192.168.30.0/24 via 192.168.0.1 dev eth0
mDNS가 서브넷을 넘지 못하는 문제
이 설정을 통해 mDNS 문제는 해결됐다. 와이파이 기기는 MQTT 브로커와 통신하며 필요한 데이터를 주고받을 수 있게 되었고, Zigbee 기기는 USB 동글을 통해 직접 Home Assistant에 연결되었다. 이렇게 하여 Home Assistant에서 모든 IoT 기기를 한곳에서 관리할 수 있었다. DHCP 충돌 문제도 이와 함께 해결되었고, 전체 네트워크 구조가 보다 안정적이게 되어 기기 응답 속도도 개선되었다. 물론 초기 설정 작업이 다소 복잡했지만, 이후에는 시스템이 안정적으로 동작하여 관리 부담이 줄었다.
Zigbee는 동글로, WiFi는 MQTT로
스마트홈을 운영하면서 Zigbee와 WiFi 기기를 효과적으로 연결하는 방법을 고민했다. 특히, 서로 다른 네트워크를 통합적으로 관리하기 위해서는 중간 브로커가 필요했다. Zigbee 기기는 USB 동글을 통해 직접 연결하는 방식을 택했다. 이는 네트워크의 간섭을 줄이고, 보다 안정적으로 기기를 제어할 수 있게 했다. 직접 연결 덕분에 Zigbee 기기들의 신호가 지연되는 현상도 해결할 수 있었다.
WiFi 기기의 경우는 MQTT를 활용했다. MQTT는 경량 메시지 프로토콜로, IoT 기기 간의 신속한 통신을 가능하게 해준다. WiFi 기기를 하나씩 Home Assistant에 직접 연결하는 대신, MQTT 브로커를 통해 정보를 중계하는 방식을 채택했다. 이렇게 해서 각 기기의 상태와 명령을 효과적으로 관리할 수 있었고, 여러 기기들이 동시에 명령을 받아도 성능이 떨어지지 않았다.
Zigbee와 WiFi 기기를 각각 다른 방식으로 연결했지만, Home Assistant 내에서는 이 둘을 통합하여 관리할 수 있었다. 이로 인해 기기 간의 상호작용이 원활해졌고, 전체적인 사용자 경험도 향상되었다. 이러한 설정을 통해 스마트홈의 복잡성을 줄이고, 보다 나은 제어 환경을 구축할 수 있었다.
처음에는 설정이 복잡하게 느껴졌지만, 일단 구조가 잡히고 나니 관리가 훨씬 쉬워졌다. 특히, Home Assistant의 기능을 최대한 활용할 수 있게 되어, 기기 추가나 변경이 있을 때도 빠르게 대응할 수 있었다. Zigbee와 WiFi를 적절히 분리하여 각각의 장점을 살릴 수 있었던 점이 큰 성과였다.
1년 쓰고 나서
IoT 기기들을 VLAN으로 분리하고 1년을 사용해보니, 초기 설정에 대한 불편함은 있었지만 장기적으로는 안정성이 크게 향상되었다. 특히, 네트워크의 혼잡도가 줄어들면서 다양한 기기가 더 원활하게 작동하는 것을 확인할 수 있었다. 보안 측면에서도 불안감이 많이 해소되었다. 동일 네트워크에 있던 PC나 NAS가 IoT 기기와 분리됨으로써, 해킹의 위험을 크게 줄일 수 있었다.
반면, 예상치 못한 문제도 있었다. IoT 기기의 일부분은 여전히 불안정한 연결을 보이는 경우가 있었다. 특히, 펌웨어 업데이트가 되지 않는 오래된 기기들이 가끔씩 네트워크 연결을 잃어버리곤 했다. 이 경우엔 해당 기기의 전원을 껐다가 다시 켜야 하는 번거로움이 있었다. 이러한 문제를 해결하려면 기기 교체가 필요하겠다는 생각이 들었다.
또한, 처음에는 격리된 네트워크 환경에서의 기기 간 연동이 원활하게 이루어질지 걱정되었지만, Home Assistant의 MQTT 설정을 통해 대부분의 문제를 해결할 수 있었다. 기기 간의 연결 상태를 실시간으로 모니터링할 수 있었고, 필요할 때 즉각적인 조치를 취할 수 있었다. 이러한 경험은 네트워크 구성의 필요성을 다시금 일깨워주는 계기가 되었다.
이렇게 1년을 보내고 나니, 앞으로의 과제도 보였다. 새로운 기기를 추가할 때마다 네트워크 설정을 다시 점검해야 하는 번거로움은 여전히 남아 있고, 이는 자동화나 빠른 관리 방안으로 개선해 나가야 할 부분이다. 그러나 이러한 경험을 통해 더욱 견고한 스마트홈 환경을 구축하는 데 큰 도움이 되었음을 확신하게 되었다.
함께 볼 글
이 글과 이어지는 내용은 아래에 정리해뒀다.
