MikroTik 대역폭 관리: 큐와 PCQ

요약 MikroTik 대역폭 관리는 세 가지 도구로 이루어집니다. 클라이언트별로 빠르게 제한하는 심플 큐, 계층과 우선순위를 위한 큐 트리, 그리고 큐를 하나씩 만들지 않고도 많은 사용자 간에 공정하게 분배하는 PCQ입니다. 큐 트리는 방화벽 mangle 마크와 짝을 이루어 보장값, 상한, 우선순위를 제공합니다. 이 가이드는 각각을 언제 사용해야 하는지, RouterOS 명령어, 그리고 여러 대의 라우터에서 동일한 정책을 일관되게 유지하는 방법을 보여줍니다.

MikroTik의 대역폭 관리란 무엇인가?

MikroTik의 대역폭 관리는 RouterOS 큐를 사용해 각 고객, 서브넷, 트래픽 클래스가 링크를 얼마나 소비할 수 있는지 제어하는 것입니다. 속도를 제한하고, 최소치를 보장하며, 링크가 가득 찼을 때 누가 양보할지 결정합니다. RouterOS는 계층적 토큰 버킷(HTB) 스케줄러로 큐를 구현하며, 두 곳에서 노출됩니다. 순서대로 적용되는 정렬된 목록인 심플 큐, 그리고 인터페이스나 방화벽의 mangle 기능에서 생성된 패킷 마크에 연결되는 계층 구조인 큐 트리입니다(MikroTik 공식 문서 — Queues).

이 구분이 설계가 얼마나 확장될 수 있는지를 결정합니다. 심플 큐는 “이 고객을 50Mbps로 제한하라”에 답합니다. 큐 트리는 “이 500Mbps 업링크를 300명의 가입자가 공유하고, VoIP가 먼저 처리되며, 아무도 굶주리지 않고, 과도한 다운로더가 저녁 시간을 망치지 않게 하라”에 답합니다. 모든 ISP는 결국 두 번째 답을 필요로 합니다.

1단계 — 심플 큐로 단일 클라이언트 제한

심플 큐는 문제에서 해결까지 가는 가장 짧은 경로입니다. IP, 서브넷, 인터페이스를 대상으로 지정하고 상한을 설정하면 끝입니다:

/queue simple add name=client-101 target=10.10.0.101/32 max-limit=10M/50M

max-limit은 라우터 관점에서 upload/download 형식으로 작성됩니다. 규칙은 순서대로 평가되며 첫 번째로 일치하는 것이 이깁니다. 그래서 앞쪽의 광범위한 규칙이 나중에 추가한 구체적인 규칙을 조용히 삼켜버립니다. 이 순서야말로 누군가 위에 규칙을 추가한 뒤 “잘 작동하던” 큐가 멈추는 가장 흔한 이유입니다(MikroTik 공식 문서 — Queues).

심플 큐는 가입자 인증과도 짝을 이룹니다. PPPoE 프로필의 rate-limit 필드는 세션마다 동적 심플 큐를 생성하므로, 요금제가 IP가 아니라 사용자를 따라갑니다. ISP를 위한 MikroTik PPPoE 서버 가이드에서 프로필 쪽을 다룹니다.

2단계 — 방화벽 mangle로 트래픽 마킹

큐 트리는 “VoIP”나 “고객 101”을 볼 수 없습니다. 오직 패킷 마크만 봅니다. mangle에서 이를 생성하되, 먼저 연결을, 그다음 패킷을 마킹합니다. 이것이 모든 패킷을 다시 검사하는 것보다 저렴합니다:

/ip firewall mangle
add chain=forward action=mark-connection new-connection-mark=voip-conn protocol=udp port=5060,10000-20000
add chain=forward action=mark-packet connection-mark=voip-conn new-packet-mark=voip-pkt passthrough=no

마크 분류 체계는 작고 안정적으로 유지하세요. 마크는 큐가 사용하는 어휘이며, 한 번 전체 라우터에 즉흥적으로 지은 마크 이름이 세 세대쯤 쌓이면 어느 라우터가 어떤 정책을 적용하는지 아무도 알 수 없게 됩니다. 바로 이 지점에서 MKController의 구성 감사 및 이력 기능이 진가를 발휘합니다. 모든 라우터의 mangle과 큐 상태를 확인하고, 의도한 정책과 비교하며, 변경이 적용되지 않은 단 한 대를 찾으려고 서른 개의 Winbox 세션을 여는 대신 수정된 규칙을 전체 라우터에 배포할 수 있습니다.

3단계 — 큐 트리 계층 구성

큐 트리는 링크의 실제 용량을 담는 하나의 parent와 이를 나누는 자식들로 구성됩니다:

/queue tree
add name=download parent=bridge-lan max-limit=500M
add name=voip parent=download packet-mark=voip-pkt limit-at=50M max-limit=100M priority=1
add name=bulk parent=download packet-mark=bulk-pkt limit-at=50M max-limit=500M priority=8

세 개의 필드가 일을 합니다. limit-at은 링크가 포화 상태일 때도 자식이 받는 보장값입니다. max-limit은 용량에 여유가 있을 때 도달할 수 있는 상한입니다. priority는 — 1이 가장 높고 8이 가장 낮습니다 — 어느 자식이 남은 대역폭을 먼저 받을지 결정하며, limit-at과 max-limit 사이에서만 적용됩니다(MikroTik 공식 문서 — Queues). parent의 max-limit은 계약서에 적힌 값이 아니라 링크가 실제로 제공하는 값으로 설정하세요. 그러지 않으면 큐가 절대 병목이 되지 못하고 아무것도 셰이핑하지 못합니다.

4단계 — 공정 분배를 위한 PCQ 추가

Per Connection Queue(PCQ)는 사용자별 큐 목록으로는 감당할 수 없는 가입자 규모까지 MikroTik이 확장될 수 있는 이유입니다. PCQ 큐 타입은 주소 필드로 트래픽을 분류하고 서로 다른 값마다 동적 하위 큐를 생성하여 각각에 동일한 속도를 적용합니다(MikroTik 공식 문서 — PCQ example):

/queue type
add name=pcq-down kind=pcq pcq-rate=20M pcq-classifier=dst-address
add name=pcq-up   kind=pcq pcq-rate=10M pcq-classifier=src-address

pcq-down을 고객 다운로드 트래픽을 담는 자식의 queue로 연결하면 모든 고객이 자동으로 할당되어 최대 20Mbps를 받습니다. pcq-rate=0으로 설정하면 PCQ가 활성 상태인 모두에게 parent의 대역폭을 균등하게 나눠줍니다. 전형적인 “아무도 굶주리지 않는” 구성입니다. 큐 타입 하나가 손으로 작성한 수백 개의 항목을 대체합니다.

동일한 균등화 논리가 공유 WiFi에도 적용됩니다. 요금제의 속도 제한과 PCQ parent가 함께 작동해 한 게스트가 매장의 업링크를 독차지하는 것을 막아줍니다. 자격 증명 쪽은 MikroTik HotSpot 바우처 설정 가이드를 참고하세요.

5단계 — limit-at, max-limit, burst, priority 튜닝

대부분의 망가진 QoS는 잘못된 도구가 아니라 잘못된 숫자 때문입니다. 모든 자식의 limit-at 합계를 parent의 max-limit 이하로 유지하세요. 보장값이 링크를 초과 예약하면 HTB가 이를 지킬 수 없고 우선순위가 기대대로 동작하지 않게 됩니다. priority=1은 지연에 민감한 트래픽 — VoIP, 게임, DNS — 을 위해 남겨두고, 대용량 전송은 넉넉한 상한과 함께 8에 두세요.

burst에는 경고가 따릅니다. burst-limit, burst-threshold, burst-time은 평균이 낮게 유지되는 동안 클라이언트가 잠깐 max-limit을 초과하도록 허용합니다. 속도 측정에는 좋지만 초과 예약된 링크에는 더 나쁩니다. 모든 것이 유휴 상태인 새벽 3시가 아니라 링크가 부하를 받는 동안 /queue simple print stats나 큐 트리 카운터로 측정하세요. 피크 시점에 카운터를 읽는 것이 현실적이지 않다면, MKController의 Internet Link 화면이 동일한 그림을 지속적으로 유지합니다. 계약 속도 대비 사용률, 평균·최대·P95 지연, 그리고 각 링크가 90%를 초과한 시간이 몇 시간인지 보여주므로, 운 좋은 스냅샷이 아니라 이력을 기준으로 튜닝할 수 있습니다.

용량은 변하기도 합니다. 이중 WAN 페일오버 구성에서는 광케이블에 맞춰 튜닝한 parent의 max-limit이 트래픽이 LTE 백업으로 넘어가는 순간 허구가 됩니다. 두 번째 정책을 준비하세요.

6단계 — 전체 라우터에 정책 배포

라우터 한 대는 하나의 구성이지만, 백 대는 하나의 운영입니다. 이제 정책은 모든 장치에서 동일해야 하고, 고객의 상한을 “일시적으로” 올린 기술자에게도 살아남아야 하며, 타워 라우터가 netinstall될 때 복구 가능해야 합니다. RouterOS에는 이를 대신해주는 기능이 없습니다.

MKController는 해줍니다. 큐 타입, rate-limit 프로필, 방화벽 규칙을 전체 라우터에 배포하고, 구성 이력으로 제한이 언제 바뀌었는지 확인하고 이전 버전을 한 번의 클릭으로 복원하며, 변경 전 자동 백업을 수행하고, 공인 IP나 포트 포워딩 없이 CGNAT 뒤나 Starlink에 있는 라우터에 보안 아웃바운드 원격 접속을 제공합니다. CGNAT 뒤에서의 MikroTik 원격 관리에서 설명한 방식입니다. 그리고 Internet Link 모니터링은 방금 셰이핑한 바로 그 업링크를 감시합니다. 소스별 계약 속도 대비 사용률, P95를 포함한 지연, 그리고 라우터당 최대 4개 WAN 소스에 걸쳐 75%와 90% 구간을 넘어서는 소비량을 보여주므로, 포화를 향해 서서히 다가가는 링크가 가입자가 전화하기 전에 대시보드에, 그리고 (Telegram 알림과 함께) 알림으로 드러납니다. MikroTik을 대규모로 운영하는 ISP와 WISP는 이를 이용해 대역폭 정책을 백 번의 결정이 아니라 한 번의 결정으로 유지합니다.

팁

• 트래픽이 라우터에서 나가는 인터페이스에서 셰이핑하세요. 큐는 이그레스(egress)를 제어하므로 다운로드는 LAN 쪽에서, 업로드는 WAN 쪽에서 셰이핑됩니다.
• 가입자가 수십 명을 넘어서면 수백 개의 심플 큐보다 하나의 PCQ 큐 타입을 선호하세요.
• mark-packet 규칙의 passthrough=no는 남은 mangle 규칙을 불필요하게 순회하는 것을 줄여줍니다.
• 운영 중인 엣지 장비의 큐를 건드리기 전에 항상 백업하고, 한 번에 하나의 변수만 변경하세요.

대역폭이 어디로 갔는지 추측하지 마세요

큐는 요금제를 파는 것과 실제로 제공하는 것의 차이입니다. 심플 큐는 클라이언트를 제한하고, 큐 트리는 구조와 우선순위를 부여하며, PCQ는 공정성을 자동화합니다. 그리고 MKController는 이 세 가지를 한 번 적용하면 어디서나 적용되는 정책으로 바꿔줍니다. 중앙집중식 전체 라우터 관리, 모든 라우터로의 rate-limit 및 방화벽 배포, 원클릭 복원이 가능한 구성 이력, 공인 IP 없는 원격 접속, 그리고 계약 속도 대비 포화되는 링크를 고객보다 먼저 알려주는 Internet Link 모니터링까지 갖췄습니다.

MKController 무료 체험 시작하기