[리눅스] NetworkManager vs systemd-networkd 비교: 최적의 선택은?

목차

• 1. 왜 이 비교가 중요한가: 서버 네트워크 설정은 한번 정하면 오래 갑니다
• 2. 개념부터 쉽게: NetworkManager와 systemd-networkd는 뭐가 다른가
• 3. 어떤 환경에서 뭘 고르면 좋나: 선택 기준 정리
• 데스크톱 네트워크라면 NetworkManager가 편합니다
• 서버 네트워크 설정이라면 systemd-networkd가 깔끔한 경우가 많습니다
• 4. 실전 구현 1: NetworkManager로 고정 IP 구성하기
• 5. 실전 구현 2: systemd-networkd로 고정 IP 구성하기
• 6. ⚠️ 주의사항과 트러블슈팅: 여기서 많이 꼬입니다
• 1) 두 도구가 같은 인터페이스를 같이 관리하는 문제
• 2) DNS가 적용되지 않는 문제
• 3) Netplan 같은 상위 설정 도구와의 관계
• 4) 원격 서버에서 전환 작업할 때
• 7. 검증과 결과 확인: 설정했다고 끝이 아닙니다
• 8. 정리와 FAQ: 최적의 선택은 결국 환경에 따라 다릅니다
• 자주 묻는 질문

[리눅스] NetworkManager vs systemd-networkd 비교: 최적의 선택은?

리눅스에서 네트워크가 한 번 꼬이기 시작하면, 진짜 별거 아닌 설정 하나 때문에 한참 붙잡고 있게 되더라고요. 특히 NetworkManager systemd-networkd 비교를 제대로 안 하고 그냥 배포판 기본값만 따라가면, 데스크톱에서는 편한데 서버에서는 과한 경우가 있고, 반대로 서버에서는 깔끔한데 노트북에서는 불편한 경우가 생깁니다. 저도 홈랩에서 Ubuntu, Debian, Fedora 계열을 섞어 쓰면서 리눅스 네트워크 관리 방식 때문에 삽질 좀 했습니다 ㅎㅎ

이번 글에서는 제가 실제로 운영하면서 느낀 기준으로, NetworkManager와 systemd-networkd를 비교해보겠습니다. 쉽게 말해 둘 다 네트워크 인터페이스를 올리고 IP, 게이트웨이, DNS를 관리하는 도구인데, 철학과 쓰임새가 꽤 다릅니다. 데스크톱, 노트북, 서버, 홈랩 환경에서 뭐가 더 잘 맞는지 감 잡으실 수 있게 정리해볼게요.

데스크톱, 노트북, 서버 환경에서 두 도구가 어디에 잘 맞는지 한눈에 보여주는 개요 이미지입니다.

1. 왜 이 비교가 중요한가: 서버 네트워크 설정은 한번 정하면 오래 갑니다

네트워크 설정 도구는 단순히 IP만 넣는 수준이 아닙니다. DNS Resolver(리졸버, 이름 해석기), Bridge(브리지, 가상 스위치), Bonding(본딩, 다중 NIC 묶기), VLAN(가상 LAN), Wi-Fi(무선 네트워크), VPN(가상사설망)까지 이어지거든요. 처음 선택이 애매하면 운영 중간에 갈아타면서 서비스 다운타임까지 생길 수 있습니다.

제가 직접 해보니 데스크톱 네트워크는 사용자가 자주 바뀌는 연결 상태를 다뤄야 해서 자동화와 UI가 중요했고, 반대로 서버 네트워크 설정은 단순하고 예측 가능한 구성이 더 중요했습니다. 여기서 중요한 포인트! 편의성이 곧 정답은 아니고, 단순함이 곧 만능도 아닙니다.

2. 개념부터 쉽게: NetworkManager와 systemd-networkd는 뭐가 다른가

쉽게 말해 NetworkManager는 사용자 환경 친화적인 네트워크 관리자거든요. 유선뿐 아니라 Wi-Fi, VPN, 여러 프로파일 전환, GUI 연동까지 잘 해주죠. 반면 systemd-networkd는 더 작고 단순한 서비스 지향 도구에 가까워요. 설정 파일 기반으로 네트워크를 선언하고, 부팅 시 안정적으로 올리는 데 강점이 있습니다.

항목	NetworkManager	systemd-networkd
주 사용 환경	데스크톱, 노트북, 혼합 환경	서버, VM, 컨테이너 호스트, 홈랩
설정 방식	nmcli, nmtui, GUI, 프로파일 기반	.network, .netdev 파일 기반
Wi-Fi/VPN	강함	제한적, 별도 도구 조합 필요
구성 단순성	기능이 많아 다소 복잡할 수 있음	단순하고 예측 가능함
서버 자동화	가능하지만 환경 따라 다름	설정 파일 관리에 잘 맞음
학습 난이도	입문은 쉬움	개념 이해가 필요함

처음엔 이게 뭔가 싶었는데, 결국 차이는 이겁니다. NetworkManager는 변화가 많은 사용자 환경에 강하고, systemd-networkd는 고정된 인프라 환경에 강합니다. 이 한 줄이 핵심이에요.

3. 어떤 환경에서 뭘 고르면 좋나: 선택 기준 정리

데스크톱 네트워크라면 NetworkManager가 편합니다

• Wi-Fi SSID를 자주 바꿔야 할 때
• VPN 연결을 자주 올리고 내릴 때
• GUI 환경에서 빠르게 상태를 보고 싶을 때
• 노트북처럼 이동성이 중요한 환경

실제로 써보니까 노트북에서는 NetworkManager가 진짜 편하더라고요. 유선 꽂았다가 빼고, 집 Wi-Fi와 회사 Wi-Fi를 넘나들고, 잠깐 핫스팟 붙는 일까지 생각하면 이쪽이 훨씬 자연스럽습니다.

서버 네트워크 설정이라면 systemd-networkd가 깔끔한 경우가 많습니다

• 고정 IP 위주로 운영할 때
• 브리지, VLAN, Bonding 같은 선언형 구성이 필요할 때
• GUI 없이 최소 구성으로 운영할 때
• 재부팅 후에도 예측 가능한 상태가 중요할 때

저는 홈랩 KVM 호스트와 몇몇 작은 서비스 VM에서는 networkd 쪽을 더 선호합니다. 설정 파일이 명확해서 Git으로 추적하기도 좋고, 나중에 다시 봐도 덜 헷갈리거든요.

4. 실전 구현 1: NetworkManager로 고정 IP 구성하기

먼저 NetworkManager 예제를 보겠습니다. 인터페이스 이름은 예시로 <code>enp1s0를 쓰겠습니다. 배포판마다 이름이 다를 수 있으니 먼저 인터페이스를 확인하세요.

1. 현재 인터페이스와 연결 상태를 확인합니다.
2. 새 프로파일을 만들고 고정 IP를 넣습니다.
3. 연결을 활성화한 뒤 상태를 확인합니다.

ip link show
nmcli device status
nmcli connection show

고정 IP 프로파일 생성 예제입니다.

sudo nmcli connection add \
  type ethernet \
  ifname enp1s0 \
  con-name static-enp1s0 \
  ipv4.addresses 192.168.10.20/24 \
  ipv4.gateway 192.168.10.1 \
  ipv4.dns "1.1.1.1 8.8.8.8" \
  ipv4.method manual \
  autoconnect yes

적용은 이렇게 합니다.

sudo nmcli connection up static-enp1s0
nmcli connection show static-enp1s0

기존 DHCP 프로파일이 남아 있으면 우선순위 때문에 헷갈릴 수 있습니다. 저도 예전에 유선 프로파일이 두 개 살아 있어서, 분명 고정 IP 넣었는데 DHCP 주소가 다시 붙는 바람에 한참 봤었거든요. 이럴 때는 안 쓰는 프로파일을 정리하는 게 좋습니다.

nmcli connection show
sudo nmcli connection delete "Wired connection 1"

NetworkManager에서 nmcli로 프로파일을 만들고 활성화하는 흐름을 보여주는 이미지입니다.

5. 실전 구현 2: systemd-networkd로 고정 IP 구성하기

이번에는 systemd-networkd입니다. 이쪽은 선언형 설정 파일이 핵심입니다. 파일 이름은 보통 숫자 접두어를 붙여 정렬되게 관리합니다.

1. /etc/systemd/network/ 아래에 인터페이스 설정 파일을 만듭니다.
2. networkd와 필요하면 resolved를 활성화합니다.
3. 상태를 확인하고, 기존 관리자와 충돌이 없는지 점검합니다.

예시 파일입니다.

# /etc/systemd/network/10-enp1s0.network
[Match]
Name=enp1s0

[Network]
Address=192.168.10.20/24
Gateway=192.168.10.1
DNS=1.1.1.1
DNS=8.8.8.8

서비스 활성화는 아래처럼 진행합니다.

sudo systemctl enable --now systemd-networkd
sudo systemctl enable --now systemd-resolved
networkctl status enp1s0

DNS 쪽은 배포판마다 차이가 있어서 /etc/resolv.conf 연결 상태도 같이 보는 게 좋습니다.

ls -l /etc/resolv.conf
resolvectl status

Bridge가 필요한 서버라면 networkd가 꽤 직관적입니다. 예를 들어 가상화 호스트에서 브리지 인터페이스를 만들 때, 파일 두세 개로 구조가 눈에 보이게 정리됩니다. GUI가 필요 없는 환경에서는 이게 정말 편하더라고요.

# /etc/systemd/network/20-br0.netdev
[NetDev]
Name=br0
Kind=bridge

# /etc/systemd/network/21-br0.network
[Match]
Name=br0

[Network]
Address=192.168.10.30/24
Gateway=192.168.10.1
DNS=1.1.1.1

# /etc/systemd/network/22-enp1s0.network
[Match]
Name=enp1s0

[Network]
Bridge=br0

systemd-networkd에서 파일 기반으로 인터페이스와 브리지를 선언하는 구조를 설명하는 이미지입니다.

6. ⚠️ 주의사항과 트러블슈팅: 여기서 많이 꼬입니다

NetworkManager systemd-networkd 비교에서 성능이나 취향보다 더 중요한 건, 둘을 동시에 어설프게 건드리지 않는 겁니다. 제가 제일 많이 본 문제도 이거였어요.

1) 두 도구가 같은 인터페이스를 같이 관리하는 문제

한 인터페이스를 두 서비스가 동시에 건드리면 IP가 바뀌거나, 라우팅이 꼬이거나, 부팅 후 상태가 달라질 수 있습니다.

• 서버에서 networkd를 쓸 거면 해당 인터페이스를 NetworkManager 관리 대상에서 빼는지 확인
• 데스크톱에서 NetworkManager를 주로 쓸 거면 networkd 설정 파일을 남겨두지 않기

2) DNS가 적용되지 않는 문제

IP는 잘 붙는데 이름 해석이 안 되는 경우가 있습니다. 이건 대개 Resolver(리졸버) 경로가 꼬인 겁니다. resolvectl status, cat /etc/resolv.conf를 같이 보셔야 합니다. 특히 배포판 기본 설정이나 설치 도구가 DNS 체인을 이미 잡아둔 경우가 있거든요.

3) Netplan 같은 상위 설정 도구와의 관계

일부 배포판은 Netplan(넷플랜, 네트워크 추상화 설정 도구) 같은 레이어가 중간에 있습니다. 이 경우 실제 백엔드는 NetworkManager일 수도 있고 systemd-networkd일 수도 있어요. 겉으로는 YAML만 보이는데, 실제 적용 주체는 다른 셈이죠. 저도 처음엔 설정 파일을 직접 만졌는데 적용이 이상해서 봤더니 상위 도구가 덮어쓰고 있더라고요.

4) 원격 서버에서 전환 작업할 때

SSH로 붙어 있는 서버에서 네트워크 관리자 교체 작업은 정말 조심하셔야 합니다. 잘못하면 세션이 바로 끊깁니다. 가능하면 콘솔 접근 수단을 확보하고, 변경 전 현재 라우팅과 IP를 메모해 두세요.

ip addr
ip route
networkctl
nmcli device status

💡 팁: 원격 작업이면 먼저 보조 NIC나 관리용 콘솔이 있는지 확인하세요. 이거 하나로 심장 덜 철렁합니다.

7. 검증과 결과 확인: 설정했다고 끝이 아닙니다

네트워크는 적용보다 검증이 더 중요합니다. 드디어 됐다! 싶어도 DNS, 게이트웨이, 재부팅 후 유지 여부까지 확인해야 진짜 끝입니다.

1. 인터페이스에 기대한 IP가 붙었는지 확인
2. 기본 게이트웨이가 맞는지 확인
3. DNS 질의가 되는지 확인
4. 재부팅 후에도 유지되는지 확인

ip addr show enp1s0
ip route
ping -c 4 192.168.10.1
ping -c 4 1.1.1.1
getent hosts example.com

NetworkManager 쪽 확인 명령입니다.

nmcli device show enp1s0
nmcli general status

systemd-networkd 쪽 확인 명령입니다.

networkctl status enp1s0
resolvectl status

라우팅, DNS, 인터페이스 상태를 검증하는 결과 화면을 한 장으로 요약한 이미지입니다.

실제로 써보니까 데스크톱 네트워크는 NetworkManager가 관리 포인트가 적었고, 홈랩 서버는 systemd-networkd가 더 담백했습니다. 특히 재부팅 후에도 상태가 예측 가능하다는 점이 마음에 들었네요. 반대로 Wi-Fi나 VPN을 자주 다루는 장비는 굳이 networkd로 억지 구성할 이유가 없었습니다.

8. 정리와 FAQ: 최적의 선택은 결국 환경에 따라 다릅니다

리눅스 네트워크 관리에서 정답은 하나가 아닙니다. 다만 기준은 분명합니다.

환경	추천	이유
개인 데스크톱	NetworkManager	GUI, Wi-Fi, VPN, 프로파일 전환이 편함
노트북	NetworkManager	이동성과 연결 변경이 많음
고정 IP 서버	systemd-networkd	단순하고 예측 가능함
가상화 호스트/홈랩	systemd-networkd	브리지, VLAN 같은 선언형 구성이 깔끔함
혼합 환경	상황별 선택	역할에 따라 분리 운영이 현실적임

어떤 환경에 어떤 도구가 더 적합한지 빠르게 판단할 수 있도록 정리한 요약 이미지입니다.

자주 묻는 질문

• Q. 서버에도 NetworkManager를 써도 되나요?
  네, 가능합니다. 다만 고정 구성이 중심이고 Wi-Fi나 사용자 세션 연동이 필요 없다면 networkd가 더 단순할 수 있습니다.
• Q. systemd-networkd가 더 가볍나요?
  일반적으로 더 단순한 구성에 잘 맞습니다. 다만 실제 체감은 기능 요구사항에 따라 달라집니다.
• Q. 둘 중 하나가 절대적으로 더 좋은가요?
  아닙니다. 데스크톱 네트워크와 서버 네트워크 설정의 요구가 다르기 때문입니다.

정리하면 이렇습니다. Wi-Fi, VPN, 사용자 친화성 중심이면 NetworkManager, 고정 구성과 선언형 관리 중심이면 systemd-networkd가 잘 맞습니다. 저도 처음엔 무조건 하나로 통일하려고 했었는데, 실제로 운영해보니 역할별로 나누는 게 훨씬 덜 힘들더라고요.

다음 글에서는 Netplan과 NetworkManager/systemd-networkd의 관계도 따로 다뤄볼 예정입니다. Ubuntu 계열에서 설정이 왜 한 번 더 꼬이는지, 그 부분이 궁금하셨다면 이어서 보시면 도움이 되실 겁니다. 이전 글에서 다룬 홈랩 브리지 구성과 같이 보셔도 흐름이 잘 이어집니다. 🎉

📚 함께 읽으면 좋은 글

• strace로 리눅스 애플리케이션 장애 진단: 실제 디버깅 사례 분석
• Flatpak vs Snap vs AppImage 2026년 리눅스 데스크톱 앱 완벽 비교 분석
• fstab 마운트 실패 시 부팅 복구 가이드