* 이 게시물은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.
(pfSense 홈랩 방화벽 ㉕)
집에서 누군가 큰 파일을 받기 시작하면 화상회의가 뚝뚝 끊긴 경험, 다들 있을 거다. 회선 용량은 정해져 있는데 한 놈이 다 먹어서다. QoS(트래픽 셰이핑)는 이 대역폭을 나누고, 중요한 트래픽에 우선권을 줘서 이런 상황을 막는다.
두 가지 접근
| 방식 | 하는 일 | 적합한 경우 |
|---|---|---|
| Limiter | 특정 기기·트래픽의 속도 상한을 정함 | 게스트망 대역 제한 등 |
| Shaper(ALTQ) | 트래픽에 우선순위 큐를 부여 | 회의·게임 우선 등 |
개념은 이렇다. 회선 전체 용량을 pfSense에 알려 주면, pfSense가 그 안에서 트래픽을 큐로 나눠 관리한다. 지연에 민감한 트래픽(화상회의·게임·VoIP)은 높은 우선순위 큐에, 대용량 다운로드는 낮은 큐에 넣는다. 그러면 회선이 꽉 차도 회의 패킷이 먼저 빠져나가 끊김이 준다.
셰이퍼 마법사
Firewall > Traffic Shaper > Wizards가 제일 쉽다. 회선 업/다운 속도를 입력하고, 우선순위를 줄 애플리케이션 유형을 고르면 큐와 규칙을 자동으로 만들어 준다. 세밀한 제어는 Limiter로 '이 기기는 최대 10Mbps' 같은 상한을 직접 걸면 된다. 정확한 회선 속도 입력이 중요한데, 실제보다 살짝 낮게 잡아야 셰이핑이 제대로 먹는다.
직접 해보기
- 셰이퍼 마법사로 회선 속도를 입력하고 기본 큐를 생성한다.
- 또는 Limiter를 만들어 특정 클라이언트의 다운로드 속도를 제한하는 규칙을 건다.
- 그 기기에서 속도 측정을 해 상한이 걸리는지 확인한다.
✅ 확인 — 대역 제한이나 우선순위가 실제로 적용되는 걸 측정으로 확인하면 성공이다. 회선 속도를 실제보다 낮게 잡는 이유를 설명해 보자.
실무 팁 — 트래픽 셰이핑의 핵심 함정: 회선 속도를 실제보다 살짝 낮게(약 90~95%) 입력해야 셰이퍼가 큐를 제대로 통제한다. 실제 속도를 그대로 넣으면 상류(ISP) 버퍼에 지연이 쌓이는 버퍼블로트가 남는다. 설정 후 회선 부하 상태에서 핑 지연이 안 튀는지 측정으로 확인하자.
Limiter로 게스트망 속도 제한 (제일 실용적)
가장 쉽고 자주 쓰는 게 Limiter다. 게스트 와이파이가 회선을 다 먹지 않게 상한을 건다. Firewall > Traffic Shaper > Limiters에서 다운/업 파이프를 만들고(예: 다운 20Mbps), 게스트 방화벽 규칙의 In/Out Pipe에 그 파이프를 붙인다. 그러면 게스트 전체가 그 상한 안에서만 쓴다. 기기마다 공평하게 나누고 싶으면 파이프 마스크를 Source/Destination address로 두면 IP별로 상한이 걸린다.
Shaper로 우선순위 — 회의·게임을 먼저
속도 제한이 아니라 ‘누가 먼저‘가 목적이면 Shaper(ALTQ)다. 마법사로 큐를 만들고, 지연에 민감한 트래픽(화상회의·VoIP·게임)을 높은 우선순위 큐에, 대용량 다운로드는 낮은 큐에 넣는다. 이 우선순위는 회선이 꽉 찰 때만 발동한다 — 평소 여유로울 땐 아무 영향이 없다가, 붐빌 때 중요한 트래픽을 먼저 보내준다.
회선 용량을 정확히 넣어야 작동한다
QoS가 먹히는 전제는 pfSense가 ‘내 회선의 진짜 용량’을 아는 것이다. 마법사에 넣는 상/하향 대역폭을 실측보다 약간 낮게(예: 90~95%) 잡는 게 요령이다. 그래야 병목이 ISP 장비가 아니라 pfSense 안에서 생겨서, pfSense가 큐로 통제할 수 있다. 용량을 실제보다 높게 적으면 병목이 바깥에 생겨 셰이핑이 사실상 안 먹는다. 회선 속도를 먼저 실측하고 그 값을 조금 깎아 넣자.
요즘 회선엔 왜 덜 복잡해도 되나 — FQ-CoDel
예전엔 버퍼블로트(과한 버퍼 탓에 지연이 폭증하는 현상) 때문에 QoS가 사실상 필수였다. 요즘 pfSense는 FQ-CoDel 같은 똑똑한 큐 알고리즘을 Limiter에 붙일 수 있어서, 복잡한 우선순위 설계 없이도 버퍼블로트를 크게 잡아준다. 회선이 넉넉하다면 ‘Limiter + FQ-CoDel’만으로 대부분의 끊김이 사라진다. 손 많이 가는 ALTQ 큐 설계는 회선이 자주 포화되는 환경에서 빛을 본다.
정리하면 — 단순히 상한만 걸 땐 Limiter, 우선순위가 필요하면 Shaper, 끊김만 잡으면 되면 Limiter+FQ-CoDel. 목적에 맞는 걸 고르면 QoS는 생각보다 어렵지 않다.
이제 회선 하나를 잘 나눴다. 다음 편은 회선을 둘로 늘려, 하나가 죽어도 인터넷이 안 끊기게 만드는 다중 WAN이다.
자주 묻는 질문 (FAQ)
트래픽 셰이핑(QoS)은 언제 필요한가요?
회선이 포화될 때 화상회의·게임 같은 지연 민감 트래픽을 우선시하고 싶을 때입니다. 대용량 다운로드가 통화를 끊는 걸 막습니다.
설정이 복잡한데 꼭 해야 하나요?
회선이 넉넉하면 없어도 됩니다. 여러 명이 한 회선을 나눠 쓰며 버벅임이 있을 때 효과가 큽니다.
답글 남기기