리눅스 방화벽 도구를 검색하면 iptables, nftables, UFW, firewalld라는 이름이 뒤섞여 나와서 뭐부터 배워야 할지 헷갈리기 쉬워요. 결론부터 말하면 iptables는 이미 커널 내부적으로 nftables에게 자리를 내줬고, UFW와 firewalld는 그 nftables 위에 얹힌 서로 다른 두 개의 관리 도구예요. 그렇다면 지금 새로 서버를 세팅한다면 이 중 뭘 배워야 할까요?
nftables는 왜 iptables를 대체하게 됐을까?
nftables는 커널 4.0부터 포함된 차세대 패킷 필터링 프레임워크로, 기존 iptables가 IPv4·IPv6·ARP·이더넷 브리지마다 별도 명령어(iptables, ip6tables, arptables, ebtables)를 써야 했던 파편화 문제를 하나의 통합 문법으로 해결했어요. 규칙을 처리하는 내부 구조도 더 효율적으로 재설계돼서, 규칙 수가 많아질수록 iptables보다 훨씬 빠르게 동작해요. 데비안, 우분투, RHEL 계열 모두 이미 기본 백엔드를 nftables로 전환했기 때문에, 지금 iptables 명령어를 입력해도 실제로는 nftables 호환 레이어가 처리하고 있는 셈이에요.
UFW는 어떤 철학으로 만들어졌을까?
UFW(Uncomplicated Firewall)는 이름 그대로 “복잡하지 않은 방화벽”을 표방하며 우분투와 데비안 계열에서 기본값처럼 쓰이는 도구예요. ufw allow 22/tcp, ufw enable 같은 짧은 명령어 몇 개로 대부분의 방화벽 작업이 끝나기 때문에, 서버 하나에 SSH와 웹 포트 정도만 열면 되는 단순한 상황에서는 이보다 편한 도구가 없어요. 다만 이 단순함은 곧 한계이기도 해서, 네트워크 인터페이스별로 다른 정책을 세밀하게 적용하거나 복잡한 NAT 규칙을 짜야 하는 상황에서는 UFW의 표현력이 금방 부족해져요.
firewalld는 UFW와 뭐가 근본적으로 다를까?
firewalld는 RHEL, Fedora, Rocky Linux 같은 엔터프라이즈 리눅스 계열의 기본 방화벽 도구로, ‘zone’이라는 개념을 중심에 둔다는 점에서 UFW와 접근 방식 자체가 달라요. zone은 네트워크 인터페이스마다 신뢰 수준을 다르게 설정하는 단위인데, 예를 들어 사내망에 연결된 인터페이스는 ‘internal’ zone으로 느슨하게, 외부 인터넷에 연결된 인터페이스는 ‘public’ zone으로 엄격하게 관리할 수 있어요. 규칙을 즉시 적용하면서도 서비스 중단 없이 런타임 설정을 갱신할 수 있다는 점이 firewalld의 가장 큰 실무적 장점이고, 그만큼 서버 대수가 많고 네트워크 구성이 복잡한 환경에서 진가를 발휘해요.
docker와 방화벽이 충돌하는 이유는 뭘까?
도커를 설치하면 UFW로 분명히 막아둔 포트가 갑자기 외부에 그대로 노출되는 경험을 하는 경우가 꽤 흔해요. 이유는 도커 데몬이 컨테이너 네트워킹을 위해 nftables(iptables) 체인에 UFW보다 우선순위가 높은 규칙을 직접 삽입하기 때문인데, UFW는 이 규칙 삽입 순서를 인지하지 못하고 자기 규칙만 관리하려고 해요. 결국 ufw deny로 막아둔 포트라도 도커가 컨테이너 포트를 퍼블리시하는 순간 그 규칙이 사실상 무시되는 상황이 벌어져요. 이 문제를 근본적으로 피하려면 UFW의 after.rules 파일을 직접 수정하거나, 아예 도커 컨테이너의 포트 바인딩을 127.0.0.1로 제한해서 애초에 외부 노출 자체를 막는 방식을 써야 해요.
그래서 뭘 골라야 할까?
환경에 따라 선택 기준이 명확하게 갈려요.
- 개인 서버, VPS 한두 대: 명령어가 짧고 직관적인 UFW로 충분해요.
- 회사 인프라, 여러 네트워크 zone 구분이 필요한 환경: firewalld의 zone 기반 관리가 장기적으로 훨씬 편해요.
- 보안이 최우선인 환경: 두 프론트엔드만으로 부족하다면 nftables 문법을 직접 배워서 세밀한 규칙을 짜는 게 맞아요.
- 컨테이너를 많이 돌리는 서버: 방화벽 도구와 별개로 도커의 iptables 개입 방식부터 먼저 이해하고 넘어가야 해요.
결국 UFW와 firewalld는 같은 nftables 엔진 위에 서로 다른 철학을 얹은 프론트엔드일 뿐이라서, 우열을 가리기보다 여러분의 서버가 얼마나 복잡한 네트워크 구조를 갖고 있는지가 선택을 결정해요.
자주 묻는 질문
Q1. iptables는 이제 완전히 못 쓰는 건가요?
명령어 자체는 호환 레이어를 통해 여전히 동작하지만, 커널 내부적으로는 이미 nftables로 변환되어 처리되기 때문에 신규 구축에서는 iptables를 직접 쓸 이유가 거의 없어요.
Q2. UFW와 firewalld 중 초보자에게 더 쉬운 건 어느 쪽인가요?
명령어 개수와 문법이 훨씬 단순한 UFW가 처음 방화벽을 다뤄보는 사용자에게 진입 장벽이 낮아요.
Q3. firewalld의 zone 개념은 왜 필요한가요?
노트북처럼 집·회사·카페 등 네트워크 환경이 자주 바뀌는 기기에서, 연결된 네트워크에 따라 방화벽 정책을 자동으로 다르게 적용하기 위해 zone을 씁니다.
Q4. 규칙을 하나 바꿀 때마다 방화벽을 재시작해야 하나요?
firewalld는 런타임 설정을 즉시 반영하면서도 서비스 중단 없이 규칙을 갱신할 수 있는 반면, 전통적인 iptables 스크립트 방식은 재적용 과정에서 순간적으로 연결이 끊길 수 있어요.
Q5. docker를 쓰면 방화벽 설정이 꼬인다고 하던데 사실인가요?
네, 도커가 자체적으로 iptables/nftables 체인에 규칙을 직접 삽입하기 때문에 UFW나 firewalld의 규칙을 우회하는 경우가 실제로 자주 발생해요.
Q6. nftables 문법을 처음부터 직접 배워야 하나요?
아니요, 대부분의 사용자는 UFW나 firewalld 같은 프론트엔드로 충분하고, nftables 문법은 세밀한 커스텀 규칙이 필요할 때만 익혀도 늦지 않아요.
BFQ 비디오 재생 벤치마크: 반응성을 높인 대가로 프레임이 얼마나 떨어졌나
BFQ+의 low-latency 휴리스틱이 반응성을 높이는 대신 소프트 실시간 애플리케이션에 어떤 지연 시간 대가를 요구하는지 논문의 비디오 재생 벤치마크로 확인합니다.
NCQ가 켜지면 디스크 스케줄러 보장이 무너지는 이유 (BFQ 논문 실측)
Native Command Queueing이 활성화되면 BFQ, CFQ 같은 OS 스케줄러의 공정성·지연 보장이 어떻게 무력화되는지 논문의 실측 데이터로 설명합니다.
BFQ+ vs BFQ vs CFQ 실측 벤치마크: 처리량과 앱 기동 시간 비교
BFQ 논문이 세 대의 리눅스 시스템에서 실측한 집계 처리량과 bash·konsole 기동 시간 벤치마크 결과를 수치 그대로 정리합니다.