MikroTik RouterOS 트러블슈팅: 홈 네트워크 안정성 확보를 위한 5가지 해결책

집에서 MikroTik RouterOS 트러블슈팅을 해보면, 문제 자체보다 더 피곤한 건 증상이 애매하다는 점입니다. 와이파이는 붙는데 웹만 안 열리거나, 낮에는 멀쩡한데 밤에만 지연이 튀고, 게임 핑이 흔들리는데 가족들 OTT는 또 되는 식이죠. 저도 홈랩과 가정용 회선을 RouterOS로 오래 만져보면서 느낀 건 하나였습니다. 설정을 많이 아는 사람보다, 어디부터 의심할지 아는 사람이 더 빨리 고칩니다.

특히 MikroTik 홈 네트워크에서는 증상 하나를 여러 계층이 동시에 만들어냅니다. WAN 재협상, DHCP 임대 꼬임, DNS 캐시 실패, 브리지 포트 오배치, FastTrack 때문에 가려진 흐름, MTU 불일치, connection tracking 과부하가 비슷한 얼굴로 나타나거든요. 그래서 이 글은 기능 설명보다 집에서 실제로 장애를 좁혀가는 순서에 맞춰 정리했습니다. 무엇을 먼저 보고, 어떤 출력이면 어디를 의심하고, 언제 설정을 건드리지 말아야 하는지까지 담았습니다.

광고성 요약 글처럼 메뉴 이름만 나열하지 않겠습니다. 대신 제가 RouterOS를 만질 때 실제로 효과가 좋았던 기준만 추렸습니다. 핵심은 다섯 가지입니다. 백업과 증거 확보, DHCP/DNS 분리 진단, MTU/MSS 확인, 브리지 루프 차단, 방화벽·세션 병목 판별. 이 다섯 축만 제대로 보면, 홈 네트워크 안정성 문제는 꽤 높은 확률로 방향이 잡힙니다.

홈 인터넷 회선, MikroTik 라우터, 스위치, 무선 AP, NAS, IoT 기기가 어떻게 연결되는지 한눈에 보여주는 개요 이미지입니다.

MikroTik RouterOS 트러블슈팅, 왜 순서가 중요할까

RouterOS에서 흔히 하는 실수가 있습니다. 증상을 보자마자 NAT, DNS, 방화벽 규칙부터 고치는 겁니다. 이게 왜 위험하냐면, RouterOS는 기능 간 결합이 강해서 하나를 건드리는 순간 진짜 원인의 흔적이 사라질 수 있기 때문입니다. 예를 들어 DNS가 느린 것처럼 보여도 실제 원인은 WAN flap일 수 있고, 방화벽 병목처럼 보여도 브리지 루프가 CPU를 끌어올린 것일 수 있습니다.

제가 권하는 순서는 늘 같습니다.

1. 문제 범위를 먼저 자릅니다. 모든 단말이 문제인지, 특정 VLAN/AP/기기만 문제인지부터 확인합니다.
2. IP 자체가 죽는지, 이름 해석만 죽는지 분리합니다. /ping 1.1.1.1과 /ping google.com은 항상 따로 봅니다.
3. 현재 상태를 저장합니다. 로그, 인터페이스 링크 상태, 라우트, DHCP lease, 브리지 포트 구성을 남깁니다.
4. 수정은 한 번에 하나만 합니다. DNS와 MTU와 방화벽을 한 번에 건드리면, 나중에 살아난 이유도 모릅니다.
5. 수정 후에는 원래 깨지던 조건으로 다시 검증합니다. 한 번 핑이 됐다고 끝내면 재발하더라고요.

이 순서가 중요한 이유는 단순합니다. RouterOS 문제 해결은 최적화보다 감별진단에 가깝기 때문입니다. 기능이 많다는 건 옵션이 많다는 뜻이지만, 동시에 오진 가능성도 많다는 뜻입니다.

증상별로 어떤 도구를 먼저 볼지

여기서 포인트는 사용자가 말하는 “느리다”를 그대로 믿지 않는 겁니다. 사용자 입장에서는 DNS 지연도 느리고, MTU 문제도 느리고, 브리지 루프도 느립니다. 하지만 장비 입장에서는 완전히 다른 장애입니다. 그래서 진단 명령도 달라져야 합니다.

해결책 1: 백업과 로그부터 남기기

RouterOS에서 첫 번째 조치는 늘 같습니다. 설정을 고치는 게 아니라, 증거를 확보하는 것입니다. 실제로 여러 번 느낀 건, 문제 해결 속도는 CLI 실력보다 문제 직전 상태를 얼마나 잘 남겨뒀는가에 더 크게 좌우된다는 점이었습니다. 특히 집에서는 장애가 간헐적이라 멀쩡할 때만 장비를 들여다보게 되니까요.

최소한 아래 정도는 바로 떠두는 편이 낫습니다.

/export hide-sensitive file=before-troubleshoot
/system backup save name=before-troubleshoot password=CHANGE_ME
/log print without-paging
/system resource print
/interface print detail
/interface monitor-traffic [find] once
/ip address print detail
/ip route print detail
/ip dhcp-client print detail
/ip dns print
/interface bridge port print detail

여기서 /export hide-sensitive를 권하는 이유가 있습니다. 백업 파일은 같은 장비에 되돌릴 때 강하지만, 사람이 diff를 읽기엔 export 쪽이 훨씬 편합니다. 반대로 바이너리 백업은 원복에는 강하죠. 둘 중 하나만 고르기보다 분석용 export, 원복용 backup을 같이 가져가는 편이 실무적입니다. 다만 공식 문서 기준으로 바이너리 백업은 같은 장비, 가급적 같은 RouterOS 버전에서 복원하는 쪽이 안전합니다.

출력을 읽을 때는 이런 기준이 꽤 유용합니다.

• /interface print detail에서 WAN 인터페이스가 running 상태를 잃었다 되찾는 흔적이 있으면, DNS나 방화벽 전에 물리 링크와 상위 회선 재협상을 의심합니다.
• /ip route print detail에서 기본 경로가 여러 개이거나 distance와 활성 상태가 예상과 다르면 장애 시점에 우선순위 전환이 있었는지 봅니다.
• /log print에 link down, dhcp, pppoe, disconnect 메시지가 반복되면 라우터 내부 최적화보다 상위 연결 안정성이 우선입니다.
• /system resource print에서 메모리보다 CPU 급등이 문제라면, 다음 단계에서 /tool profile로 어떤 기능이 CPU를 먹는지 좁혀야 합니다.

반대로 이런 경우에는 설정 변경을 미루는 게 맞습니다. 문제가 지금 재현 중인데 로그가 계속 쌓이고 있는 상황입니다. 이때 NAT, FastTrack, DNS 서버 주소를 동시에 바꾸면 진짜 원인은 사라지고 운 좋게 증상만 가려질 수 있습니다. 집에서는 일단 되게 만들고 싶은 유혹이 큰데, 재발하는 장애는 대부분 여기서 시작되더라고요.

해결책 2: DHCP와 DNS부터 분리해서 확인하기

홈 네트워크에서 “인터넷이 안 된다”는 말은 진단 용어가 아닙니다. RouterOS에서는 최소한 두 개로 쪼개야 합니다. 단말이 정상 IP를 받지 못하는 문제와 IP는 되지만 이름 해석이 깨지는 문제입니다. 이 둘을 섞어서 보면 시간만 낭비합니다.

저는 이 단계에서 항상 단말 하나를 기준점으로 잡습니다. 문제를 겪는 폰이든 노트북이든 하나를 정하고, 그 기기의 IP, 게이트웨이, DNS 서버, lease 상태를 먼저 맞춰봅니다. 여러 장비를 동시에 보면 이상하게 더 헷갈릴 때가 많았습니다.

/ip dhcp-server lease print detail
/ip dhcp-server network print detail
/ip dhcp-server print detail
/ip dns print
/ip dns cache print where name~"google|cloudflare"
/ping 1.1.1.1 count=5
/ping google.com count=5
/tool traceroute 1.1.1.1

판단은 다음처럼 자르면 됩니다.

1. 1.1.1.1은 안정적으로 응답하는데 google.com이 실패한다면, 회선보다 DNS 경로가 문제일 가능성이 큽니다.
2. 문제 단말의 lease가 안 보이거나 계속 새로 생기면, DHCP pool 부족보다 먼저 브리지 소속과 AP uplink 포트 배치를 봅니다.
3. 여러 단말이 랜덤하게 DNS 실패를 겪는데 IP 통신은 된다면, allow-remote-requests, 상위 DNS 응답 품질, 또는 DNS 패킷이 특정 규칙에 막히는지 확인합니다.
4. 특정 SSID에서만 실패하면 무선 문제로 단정하기보다, 그 SSID가 매핑된 bridge 또는 VLAN과 DHCP server 바인딩을 의심하는 편이 빠릅니다.

DNS는 특히 오진이 많습니다. 예를 들어 사용자는 웹이 느리다고 하지만, 실제로는 첫 번째 도메인 조회만 실패하고 새로고침 몇 번 후 열리는 경우가 있습니다. 이럴 때 회선 속도 테스트를 돌리는 건 거의 무의미합니다. 먼저 RouterOS가 재귀 DNS를 직접 중계하는지, 단말이 외부 DNS를 직접 쓰는지, 캐시 실패가 반복되는지부터 봐야 합니다.

RouterOS에서 DNS를 라우터가 직접 받아줄 때는 보통 이렇게 확인합니다.

/ip dns print
/ip dns set allow-remote-requests=yes servers=1.1.1.1,8.8.8.8
/ip firewall filter print stats where chain=input
/log print where message~"dns"

다만 여기에는 분명한 트레이드오프가 있습니다. 라우터가 DNS를 직접 중계하면 단말 관리가 단순해지고 캐시 이점도 생기지만, 장애 지점이 하나 더 늘어납니다. 반대로 단말이 외부 DNS를 직접 보게 하면 문제 분리는 쉬워지지만, 정책 통일과 로컬 이름 해석은 불편해집니다. 가정용에서 장비 수가 적고 관리가 간단해야 하면 라우터 DNS 중계가 편하고, 홈랩처럼 실험이 잦고 원인 분리가 중요하면 외부 DNS 직결이 오히려 더 편할 때도 있습니다.

제가 자주 본 실패 모드는 이겁니다. AP를 추가하면서 포트를 브리지에 넣긴 했는데, DHCP 서버가 붙은 인터페이스와 실제 무선 트래픽이 지나가는 인터페이스가 달라진 경우입니다. 이때 단말은 와이파이에 붙지만 lease가 불안정하거나, DNS만 이상하게 새는 현상이 납니다. 겉보기엔 DNS 장애처럼 보여도, 근본 원인은 L2 경로 설계 실수인 경우가 꽤 많습니다.

DHCP 임대 목록, DNS 설정, 핑 테스트를 어떤 순서로 보는지 흐름 중심으로 보여주는 이미지입니다.

해결책 3: MTU와 MSS 문제를 의심해야 할 때

이 단계는 초보자뿐 아니라 경험자도 자주 놓칩니다. 전체 인터넷은 되는 것처럼 보이는데, 특정 로그인 페이지가 멈추거나, 대용량 업로드가 중간에 끊기거나, VPN만 유난히 불안정한 경우가 그렇습니다. 제 경험상 이런 문제는 서버 탓으로 오해되기 쉽지만, 실제로는 경로 MTU와 TCP MSS가 더 자주 원인입니다.

특히 PPPoE, 터널, VPN, 이중 NAT, 일부 ISP 장비가 섞이면 PMTUD가 기대대로 동작하지 않는 경우가 있습니다. 여기서 흔한 실수는 아무 근거 없이 MTU를 확 낮춰버리는 겁니다. 일시적으로 증상이 숨을 수는 있지만, 왜 그런지 이해하지 못한 채 덮어두는 셈이라 나중에 다른 터널이나 서비스에서 다시 터질 수 있습니다.

/ping 1.1.1.1 size=1472 do-not-fragment=yes count=5
/ping 1.1.1.1 size=1464 do-not-fragment=yes count=5
/ping 1.1.1.1 size=1400 do-not-fragment=yes count=5
/interface pppoe-client print detail
/ip firewall mangle print detail
/log print where message~"fragment|mtu|icmp"

해석 기준은 간단하지만, 순서는 중요합니다.

• 작은 패킷은 되는데 큰 패킷만 실패하면 MTU 관련 문제일 가능성이 큽니다.
• 웹 브라우징은 되는데 파일 업로드, HTTPS handshake, 특정 앱 로그인만 불안정하면 MSS 보정 필요성을 봅니다.
• PPPoE나 터널 인터페이스가 있다면 실제 오버헤드 때문에 usable MTU가 줄어들 수 있으니, 단순히 물리 포트 MTU만 봐서는 안 됩니다.
• ICMP가 경로에서 비정상적으로 막히면 PMTUD가 제대로 동작하지 않아 증상이 더 애매해질 수 있습니다.

RouterOS에서 실무적으로 많이 쓰는 방식은 TCP SYN 패킷에 대해 MSS를 PMTU에 맞게 clamp 하는 겁니다.

/ip firewall mangle add chain=forward action=change-mss new-mss=clamp-to-pmtu protocol=tcp tcp-flags=syn comment="Clamp TCP MSS to PMTU"
/ip firewall mangle print stats
/tool sniffer quick ip-protocol=tcp

이 설정이 유용한 상황과 피해야 할 상황도 분명합니다.

제가 겪었던 패턴 중 하나도 비슷했습니다. 외부 백업 서비스 업로드가 매번 중간에 멈추는데 웹서핑은 멀쩡했거든요. 처음엔 원격 서버 장애인 줄 알았는데, RouterOS 쪽에서 경로 MTU가 어긋난 상태였고 SYN 이후 세그먼트 크기 조정이 제대로 안 된 케이스였습니다. 이때 무작정 MTU를 줄이는 대신, 어느 크기부터 깨지는지 확인한 뒤 MSS 규칙을 넣고 재현 테스트를 하니 원인과 해결이 같이 정리됐습니다. 이거 진짜 편하더라고요.

해결책 4: 브리지 루프와 브로드캐스트 폭주 잡기

홈랩 환경에서 가장 아프게 터지는 장애는 의외로 고급 기능이 아니라 브리지 루프입니다. 스위치를 하나 더 붙이고, AP를 메쉬로 묶고, NAS를 임시로 이중 연결하고, 테스트용 케이블을 잠깐 꽂았다가 전체 네트워크가 멈춰버리는 식이죠. 이건 사용자 체감상 인터넷이 갑자기 다 죽었다로 보이지만, 실제론 회선이 아니라 L2가 폭주한 경우가 많습니다.

RouterOS에서 이 문제를 볼 때는 CPU 수치만 보면 안 됩니다. CPU가 높다는 건 결과일 뿐이고, 원인은 대개 브로드캐스트 스톰이나 MAC flapping입니다. 제가 이 유형을 볼 때는 다음 순서로 갑니다.

/tool torch interface=bridge
/interface bridge port print detail
/interface bridge monitor [find] once
/interface bridge host print
/log print where message~"bridge|topology|loop|stp|rstp"

이때 출력에서 눈여겨볼 건 세 가지입니다.

1. 특정 포트에서 비정상적으로 많은 브로드캐스트·멀티캐스트가 보이는지
2. 동일 MAC 주소가 여러 포트에서 번갈아 관측되는지
3. 포트 상태 변경이나 토폴로지 변화 로그가 반복되는지

루프는 특히 잠깐 연결했다가 괜찮아 보이는 상황이 더 위험합니다. 완전히 즉시 다운되지 않고, 트래픽이 많아지는 시간대에만 장애가 재현되기도 하거든요. 그래서 평소엔 멀쩡한데 백업 시간, 카메라 업로드 시간, 스마트홈 장비 재접속 시간에만 갑자기 망가지는 패턴이 나옵니다.

이럴 때 제 권고는 명확합니다. 브리지 설계를 사람 기억에 맡기지 말고, 포트 역할을 문서화하고 RSTP 같은 루프 방지 보호를 켜는 쪽이 낫습니다. 장비마다 세부 구성은 다르지만, 원칙은 같습니다. 실수해도 전체가 안 죽게 해야 합니다. 홈 네트워크는 가용성을 지키는 게 최고급 최적화보다 훨씬 가치가 큽니다.

자주 놓치는 실패 모드도 있습니다.

• AP uplink를 access처럼 써야 하는데 trunk처럼 연결해 VLAN이 예상 밖으로 섞이는 경우
• 브리지 포트에 임시 테스트 스위치를 연결했다가 원형 경로가 생기는 경우
• 메시 Wi-Fi와 유선 uplink가 동시에 살아 있는데, 설계 의도와 다르게 중복 경로가 열린 경우
• NAS나 스위치 이중 연결을 했지만 LACP나 스패닝트리 정합 없이 물리적으로만 두 줄 꽂은 경우

이 유형은 방화벽 규칙을 아무리 다듬어도 해결되지 않습니다. 근본 원인이 L2 토폴로지이기 때문입니다. CPU가 높다고 해서 곧바로 성능 튜닝으로 들어가면 안 되는 이유가 바로 여기 있습니다.

잘못 연결된 스위치 또는 AP uplink 때문에 루프가 생기고 트래픽이 폭주하는 상황을 시각적으로 설명하는 이미지입니다.

해결책 5: Firewall과 Connection Tracking 상태를 봐야 할 때

홈 네트워크가 느려졌다고 해서 항상 회선이 포화된 건 아닙니다. 요즘은 NAS 동기화, 카메라 스트림, 토렌트, 게임 런처, IoT 장비 재접속이 겹치면서 세션 수 자체가 병목이 되는 경우가 많습니다. RouterOS에서는 특히 connection tracking과 방화벽 규칙 순서가 얽히면 랜덤하게 느림처럼 체감되기 쉽습니다.

제가 이 구간을 볼 때는 단순히 규칙 개수보다 어떤 규칙이 실제로 많이 맞는지를 먼저 봅니다. 규칙은 적어도 순서가 나쁘면 손해를 보고, 규칙이 많아도 상단이 정리돼 있으면 생각보다 안정적입니다.

/ip firewall connection print count-only
/tool profile
/ip firewall filter print stats
/ip firewall nat print stats
/ip firewall raw print stats
/log print where message~"drop|invalid|fasttrack"

판단 기준은 이렇습니다.

• /tool profile에서 firewall, networking, bridge가 문제 시점에 튄다면 해당 경로를 의심합니다.
• /ip firewall filter print stats에서 오래된 테스트 규칙이 상단에서 계속 hit 된다면, 규칙 순서 정리가 성능과 가독성을 동시에 개선합니다.
• 세션 수가 급격히 늘어나는데 특정 장비나 특정 시간대와 겹치면, 회선 자체보다 내부 트래픽 성격이 원인일 수 있습니다.
• invalid 패킷 drop 로그가 과도하게 쌓이면 비정상 트래픽, 비대칭 경로, 또는 추적이 꼬이는 상황인지 구분해야 합니다.

여기서 실무적으로 중요한 게 FastTrack입니다. FastTrack은 분명 성능에 도움이 될 수 있지만, 트러블슈팅 중에는 관측성을 떨어뜨릴 수 있습니다. QoS나 일부 카운터, 특정 규칙 흐름이 기대만큼 보이지 않는 상황이 생길 수 있기 때문입니다. 그래서 증상 분석 단계에서는 왜 느린지를 먼저 보고, 안정화 이후에 어디를 빨리 할지를 정하는 편이 훨씬 낫습니다.

즉, 이럴 땐 이렇게 가면 됩니다.

제가 실제로 겪은 패턴도 비슷했습니다. 밤마다 NAS 백업과 외부 동기화가 겹치면 웹이 버벅이고 스트리밍이 불안정해졌는데, 속도 테스트만 보면 회선이 완전히 죽은 건 아니었습니다. 확인해보니 특정 시간대에 세션 수가 급증했고, 오래전에 넣어둔 테스트용 필터 규칙이 위쪽에서 계속 맞고 있었습니다. 이럴 때 회선 사업자를 탓하는 건 정확한 접근이 아닙니다. 규칙 흐름과 내부 트래픽 성격을 봐야 맞습니다.

재현 가능한 시나리오 하나: 밤마다 끊기던 홈랩 라우터

추상적인 얘기만 하면 현장감이 떨어져서, 제가 실제로 많이 보는 유형으로 재구성해보겠습니다. 집에서 밤마다 NAS 백업, 클라우드 동기화, 카메라 업로드가 겹치는 시간대만 인터넷이 흔들립니다. 증상은 이렇습니다. 휴대폰 와이파이는 붙어 있고, 메신저는 가끔 되는데 웹페이지 첫 로딩이 느리고, TV 스트리밍은 버퍼링이 생깁니다. 낮에는 멀쩡합니다.

이럴 때 저는 순서를 이렇게 잡습니다.

1. /ping 1.1.1.1 count=20와 /ping google.com count=20으로 IP와 DNS를 먼저 분리합니다.
2. /tool profile로 문제 시간대에 CPU가 어디서 쓰이는지 봅니다.
3. /ip firewall connection print count-only로 세션 수가 급증하는지 확인합니다.
4. /ip firewall filter print stats, /ip firewall nat print stats로 어떤 규칙이 실제 hit 되는지 봅니다.
5. 그래도 애매하면 /tool torch interface=bridge로 내부 브로드캐스트 폭주가 없는지 확인합니다.

이 시나리오에서 중요한 건 한 번에 모든 가설을 세우지 않는 겁니다. 밤마다 느려진다고 해서 곧바로 회선 품질, DNS 사업자, 장비 성능, 무선 간섭을 다 의심하면 진도가 안 나갑니다. 시간대 의존성이 보이면 먼저 내부 트래픽 이벤트를 겹쳐보는 게 맞습니다. 백업, 동기화, 카메라 업로드, 펌웨어 자동 업데이트처럼 일정성 있는 작업이 생각보다 자주 원인입니다.

이 유형에서 제가 내리는 추천은 분명합니다. 밤에만 느리면 회선보다 내부 이벤트를 먼저 보세요. IP 핑은 되는데 웹만 느리면 DNS와 세션 처리, 전체가 같이 흔들리면 브리지와 방화벽 쪽을 먼저 보시는 게 효율적입니다.

검증: 수정 후에는 이렇게 확인하면 됩니다

RouterOS에서 수정의 절반은 적용이고, 나머지 절반은 검증입니다. 장애가 한 번 안 보였다고 끝내면 안 됩니다. 특히 간헐 장애는 수정 직후보다, 원래 깨지던 조건에서 다시 확인해야 의미가 있습니다.

/ping 1.1.1.1 count=20
/ping google.com count=20
/log print follow
/ip firewall filter print stats
/ip firewall nat print stats
/interface print detail

수정 후 검증은 아래 기준이면 충분히 실무적입니다.

1. IP 핑과 도메인 핑이 둘 다 안정적인지 확인합니다.
2. WAN 인터페이스나 DHCP, PPPoE 상태가 다시 flap 하지 않는지 봅니다.
3. 문제 시점에 반복되던 로그가 사라졌는지 확인합니다.
4. 원래 깨지던 시간대나 트래픽 조건에서 재현 테스트를 다시 합니다.
5. 규칙 hit 수와 CPU profile이 수정 전과 어떻게 달라졌는지 비교합니다.

여기서 중요한 건 한 번 성공보다 실패하던 조건에서 다시 안 깨지는지입니다. 예를 들어 업로드 중단 문제가 원인이었다면, 웹 열림만 확인할 게 아니라 실제 업로드를 다시 만들어봐야 합니다. 브리지 루프가 문제였다면 한가한 시간대가 아니라 트래픽이 몰리는 시간대까지 봐야 하고요.

수정 전후를 비교하면서 핑 안정성, 로그 변화, 트래픽 상태를 한눈에 확인하는 검증용 이미지입니다.

MikroTik RouterOS 트러블슈팅에서 자주 놓치는 체크포인트

• 케이블과 포트 협상: 설정만 보다가 물리 링크 재협상을 놓치는 경우가 많습니다. WAN flap은 DNS 장애처럼 보일 수 있습니다.
• 브리지 포트 오배치: AP나 스위치 uplink가 기대한 브리지 또는 VLAN에 안 붙어 있으면 증상이 랜덤하게 보입니다.
• DNS와 인터넷 연결 혼동: IP 핑과 도메인 핑을 분리하지 않으면 진단이 처음부터 틀어집니다.
• 오래된 테스트 규칙 방치: 방화벽 규칙은 개수보다 순서와 실사용 hit가 더 중요합니다.
• FastTrack을 너무 일찍 켬: 최적화는 유용하지만, 분석 단계에서는 흐름을 가릴 수 있습니다.
• 문제 시점 기록 부재: 언제 느려졌는지 모르는데 로그를 읽는 건 거의 점치기에 가깝습니다.
• MTU를 감으로 낮춤: 원인 확인 없이 전체 MTU를 줄이면 다른 서비스에서 더 애매한 문제가 생길 수 있습니다.

마지막으로, 이런 경우엔 이렇게 가시면 됩니다

MikroTik RouterOS 트러블슈팅은 기능 백과사전을 외우는 작업이 아닙니다. 집이나 홈랩에서는 판단 기준을 최대한 단순하게 가져가는 편이 좋습니다.

인터넷 전체가 같이 흔들리면 WAN 링크와 기본 경로부터 보시면 됩니다. 이 경우 DNS나 애플리케이션별 미세 조정보다 상위 연결 안정성이 먼저입니다. 와이파이는 붙는데 웹만 이상하면 DHCP와 DNS를 먼저 분리하세요. IP 핑이 되면 회선이 완전히 죽은 건 아닙니다. 특정 업로드, 로그인, VPN만 깨지면 MTU/MSS를 의심하는 편이 맞고, 갑자기 전체가 먹통이 되거나 CPU가 튀면 브리지 루프와 브로드캐스트 폭주를 먼저 배제해야 합니다. 밤마다 버벅이거나 내부 장비가 많다면 방화벽 규칙 통계와 connection tracking을 보는 게 가장 실용적입니다.

최종적으로 드리고 싶은 추천은 이겁니다. 가정용 RouterOS 안정화의 우선순위는 백업과 로그 확보, DHCP/DNS 분리 진단, MTU/MSS 확인, 브리지 설계 점검, 방화벽·세션 정리 순서로 가져가세요. 기능 추가는 그다음입니다. 반대로 장비를 자주 붙였다 뗐다 하는 홈랩이라면 RSTP 계열 보호와 포트 문서화가 생각보다 훨씬 큰 가치를 줍니다. 회선이 멀쩡한데 특정 서비스만 실패한다면, 그때는 회선 속도보다 패킷 크기와 세션 흐름을 보는 쪽이 더 정확합니다.

다음 글에서는 RouterOS에서 VLAN 분리와 Guest Wi-Fi 구성할 때 실제로 많이 틀리는 포인트를 이어서 다뤄보겠습니다. RouterOS VLAN 분리 가이드도 함께 보면 흐름을 잡는 데 도움이 됩니다.

백업, DHCP/DNS, MTU/MSS, 브리지 루프, 방화벽/세션 점검까지 핵심 흐름을 한 장으로 요약한 이미지입니다.