우분투 24.04 고정 IP 설정: netplan(서버)과 nmcli·설정 앱(데스크톱), 적용 안 될 때 해결

작성 0xmote · 2026년 10월 17일 · 17분 읽기 · 수정 2026년 10월 17일 중급 가이드

이 글의 핵심

우분투 24.04의 네트워크 설정은 netplan이라는 설정 파일 층 아래에 서버는 systemd-networkd, 데스크톱은 NetworkManager가 실제로 일하는 구조입니다. 엉뚱한 쪽을 고치면 아무 변화가 없거나 재부팅 후 원래대로 돌아갑니다. 이 글은 내 시스템이 어느 쪽인지 확인하는 법부터, netplan YAML 작성, gateway4·권한·들여쓰기 에러, cloud-init 덮어쓰기 차단, SSH 원격에서 안전하게 적용하는 netplan try, 데스크톱의 nmcli·설정 앱 경로, DNS 확인과 원상 복구까지 순서대로 다룹니다.

들어가며

서버에 SSH로 매번 같은 주소로 접속하고 싶거나, 사내망의 다른 장비가 이 PC를 고정된 주소로 찾아와야 할 때 고정 IP가 필요합니다. 그런데 우분투에서 고정 IP를 검색해 보면 /etc/network/interfaces를 고치라는 글, /etc/netplan/의 YAML을 고치라는 글, nmcli를 쓰라는 글이 섞여 나옵니다. 그대로 따라 했는데 아무 변화가 없거나, 재부팅하니 다시 DHCP 주소로 돌아갔다는 질문이 끊이지 않는 이유가 여기에 있습니다.

/etc/network/interfaces(ifupdown)는 우분투 17.10부터 기본 구성에서 빠졌으므로 24.04에서는 고려하지 않아도 됩니다. 남은 두 방식, 즉 netplan 파일을 직접 고치는 방법과 NetworkManager를 통하는 방법은 둘 다 맞는 방법이지만 내 시스템이 어느 쪽으로 동작하는지에 따라 하나만 맞습니다. 이 글은 먼저 그 구분부터 하고, 서버 방식과 데스크톱 방식을 차례로 설명합니다.

기준 환경: 우분투 24.04 LTS(Server 및 Desktop), netplan 1.0 계열. 예시 네트워크는 공유기 주소 192.168.0.1, 대역 192.168.0.0/24, 고정할 주소 192.168.0.50입니다. 자기 환경의 값으로 바꿔 읽으면 됩니다. 22.04도 대부분 같지만, 데스크톱에서 NetworkManager 연결이 netplan 파일로 저장되는 동작은 23.10 이후에 생긴 변화입니다.

왜 설정하는 곳이 두 군데처럼 보이는가

우분투의 네트워크 설정은 두 층으로 되어 있습니다.

netplan: /etc/netplan/*.yaml에 “이 인터페이스는 이 주소를 쓴다”는 선언을 적는 설정 앞단입니다. netplan 자신은 네트워크를 직접 올리지 않습니다. YAML을 읽어서 아래 층이 이해하는 설정 파일로 번역(netplan generate)해 줄 뿐입니다.
렌더러(renderer): 실제로 인터페이스에 주소를 붙이고 DHCP를 받는 데몬입니다. 우분투 서버는 systemd-networkd, 우분투 데스크톱은 NetworkManager를 씁니다.

어느 렌더러를 쓸지는 netplan 파일 안의 renderer: 값이 정합니다. 설치 직후 상태를 보면 차이가 바로 보입니다.

ls -l /etc/netplan/
sudo cat /etc/netplan/*.yaml

서버를 설치했다면 보통 50-cloud-init.yaml 하나가 있고, renderer가 없거나 networkd로 되어 있습니다(생략 시 기본값이 networkd입니다). 데스크톱을 설치했다면 01-network-manager-all.yaml이 있고 내용은 다음 세 줄이 전부입니다.

network:
  version: 2
  renderer: NetworkManager

이 파일의 뜻은 “모든 장치를 NetworkManager에게 맡긴다”입니다. 그래서 데스크톱에서는 netplan YAML에 인터페이스 설정을 직접 적기보다, NetworkManager(설정 앱이나 nmcli)에서 바꾸는 것이 정석입니다. 24.04 데스크톱에서는 NetworkManager가 저장하는 연결 정보 자체가 /etc/netplan/90-NM-<UUID>.yaml 같은 파일로 기록되기 때문에, 이 파일을 손으로 고치고 NetworkManager에서도 고치면 두 설정이 서로 엇갈리기 쉽습니다.

엉뚱한 쪽을 고쳤을 때 생기는 증상은 대략 이렇습니다.

고친 곳	실제 렌더러	결과
netplan YAML에 `ethernets:` 추가	NetworkManager(데스크톱)	적용은 되지만 NetworkManager의 기존 DHCP 연결과 겹쳐 주소가 두 개 붙거나, 설정 앱에서 바꾼 값과 충돌
`/etc/network/interfaces`	어느 쪽이든	ifupdown이 설치돼 있지 않아 아무 변화 없음
`50-cloud-init.yaml` 직접 수정	networkd(서버, 클라우드)	당장은 적용되지만 cloud-init이 파일을 다시 만들면 원래대로 돌아감
서버에서 `nmcli` 실행	networkd	`nmcli: command not found` 또는 장치가 “unmanaged”로 표시

정리하면, 서버(특히 SSH로만 접속하는 머신)는 netplan YAML을 고치고, 화면이 있는 데스크톱은 NetworkManager를 고칩니다. 데스크톱 방식은 뒤쪽 “데스크톱에서는 nmcli나 설정 앱으로” 절에 있습니다.

인터페이스 이름과 현재 주소 확인

설정 파일에는 인터페이스 이름을 정확히 적어야 합니다. 옛날 글처럼 eth0이라고 적으면 대부분 아무 일도 일어나지 않습니다. 먼저 현재 상태를 확인합니다.

ip -br a

lo               UNKNOWN        127.0.0.1/8 ::1/128
enp3s0           UP             192.168.0.123/24 fe80::...
wlp2s0           DOWN

ip route

default via 192.168.0.1 dev enp3s0 proto dhcp src 192.168.0.123 metric 100
192.168.0.0/24 dev enp3s0 proto kernel scope link src 192.168.0.123 metric 100

여기서 세 가지 값을 얻습니다. 인터페이스 이름(enp3s0), 현재 대역의 접두어 길이(/24), 그리고 게이트웨이(default via 뒤의 192.168.0.1)입니다. 게이트웨이를 추측해서 적지 말고 이 출력에서 가져오는 것이 가장 확실합니다.

이름이 enp3s0처럼 생긴 이유는 systemd/udev의 “예측 가능한 네트워크 인터페이스 이름” 규칙 때문입니다. 커널이 장치를 발견한 순서대로 eth0, eth1을 붙이던 시절에는 랜카드를 추가하거나 부팅 순서가 바뀌면 이름이 뒤바뀌어 엉뚱한 포트에 설정이 들어가는 일이 있었습니다. 지금은 하드웨어 위치를 기준으로 이름을 붙입니다.

en = 유선 이더넷, wl = 무선 LAN
p3s0 = PCI 버스 3번, 슬롯 0번
eno1 = 메인보드 내장 장치 1번, ens33 = 핫플러그 슬롯 33번(VMware 가상 머신에서 흔히 보입니다)
enx001122334455 = USB 랜 어댑터처럼 MAC 주소로 이름을 붙인 경우

이름은 장치 위치가 바뀌지 않는 한 유지되므로 설정 파일에 그대로 적어도 됩니다. 다만 USB 랜 어댑터를 다른 어댑터로 바꾸면 이름도 바뀐다는 점은 알아 두는 편이 좋습니다.

서버: netplan YAML로 고정 IP 설정

백업하고, 새 파일로 작성하기

원래 파일을 고치기 전에 백업부터 합니다. 원격 서버라면 실수했을 때 돌아갈 길을 만들어 두는 것이 무엇보다 중요합니다.

sudo cp /etc/netplan/50-cloud-init.yaml /root/50-cloud-init.yaml.bak

백업을 /etc/netplan/ 안에 .bak 이름으로 두는 것은 피하는 편이 좋습니다. netplan은 .yaml 확장자 파일만 읽으므로 .bak은 무시되지만, 50-cloud-init.yaml.orig.yaml처럼 확장자가 .yaml로 끝나면 그것까지 읽어서 설정이 합쳐집니다.

netplan은 /etc/netplan/의 YAML을 파일 이름 사전순으로 읽고, 같은 항목은 뒤에 읽힌 파일이 덮어씁니다. 그래서 기존 파일은 두고 99-static.yaml 같은 새 파일을 만드는 방법도 있지만, 같은 인터페이스를 두 파일에서 정의하면 어떤 값이 최종인지 읽기 어려워집니다. 인터페이스가 하나뿐인 서버라면 기존 50-cloud-init.yaml을 고치되 뒤에서 설명할 cloud-init 차단을 같이 하거나, 기존 파일을 백업 위치로 옮기고 새 파일 하나만 두는 쪽이 관리하기 쉽습니다.

고정 IP 예시

network:
  version: 2
  renderer: networkd
  ethernets:
    enp3s0:
      dhcp4: false
      addresses:
        - 192.168.0.50/24
      routes:
        - to: default
          via: 192.168.0.1
      nameservers:
        addresses: [1.1.1.1, 8.8.8.8]

각 줄이 하는 일은 다음과 같습니다.

dhcp4: false: DHCP를 끕니다. 이것을 true로 남겨 두면 고정 주소와 DHCP 주소가 동시에 붙어서 ip -br a에 주소가 두 개 보이고, 기본 경로도 두 개가 생길 수 있습니다. 고정 IP로 바꿨는데 예전 주소로도 접속이 되는 이상한 상태의 원인이 대부분 이것입니다.
addresses: 반드시 CIDR 표기(/24)로 적습니다. 서브넷 마스크 255.255.255.0을 따로 적는 칸은 없고, /24가 그 뜻입니다. 접두어를 빼고 192.168.0.50만 적으면 에러가 납니다.
routes의 to: default: “목적지가 어디든 기본적으로 이 게이트웨이로 보낸다”는 기본 경로입니다. 이 줄이 없으면 같은 대역(192.168.0.x) 안에서는 통신이 되지만 인터넷과 다른 대역으로는 나가지 못합니다.
nameservers: DNS 서버입니다. 공유기 주소(192.168.0.1)를 적어도 되고, 사내 DNS가 있다면 그 주소를 적습니다. 이 항목을 빼면 DHCP로 받던 DNS 정보도 함께 사라지므로 IP로는 핑이 되는데 도메인 이름이 안 풀리는 상태가 됩니다. 사내 도메인을 짧은 이름으로 찾아야 한다면 nameservers 아래에 search: [corp.example.com]을 추가합니다.

gateway4 경고가 뜰 때

오래된 글을 따라 gateway4: 192.168.0.1이라고 적으면 적용 시 다음 경고가 나옵니다.

** (generate:1234): WARNING **: 10:20:30.123: `gateway4` has been deprecated, use default routes instead.
See the 'Default routes' section of the documentation for more details.

경고일 뿐이라 동작은 하지만, gateway4는 폐기 예정 문법입니다. 위 예시처럼 routes: 아래 to: default, via:로 바꾸면 경고가 사라집니다. 같은 이유로 gateway6도 to: "::/0" 경로로 바꿉니다. 경고를 무시하고 gateway4와 routes의 기본 경로를 함께 적으면 기본 경로가 중복 정의되어 적용 단계에서 충돌 에러가 날 수 있으니, 하나로 통일하는 것이 좋습니다.

Permissions … are too open 경고

파일을 새로 만들거나 편집기로 저장한 뒤 netplan을 실행하면 이런 경고가 뜨는 경우가 많습니다.

** (generate:1234): WARNING **: 10:20:30.456: Permissions for /etc/netplan/99-static.yaml are too open. Netplan configuration should NOT be accessible by others.

netplan 파일에는 Wi-Fi 비밀번호 같은 민감한 값이 들어갈 수 있기 때문에, 0.106 무렵부터 root 외 사용자가 읽을 수 있는 권한(예: 644)이면 경고를 냅니다. 설정은 여전히 적용되지만 경고를 없애려면 권한을 600으로 바꿉니다.

sudo chmod 600 /etc/netplan/*.yaml
sudo chown root:root /etc/netplan/*.yaml

50-cloud-init.yaml이 다시 원래대로 돌아갈 때

우분투 서버 설치 프로그램(Subiquity)과 클라우드 이미지는 cloud-init으로 네트워크 초기 설정을 만듭니다. 그래서 50-cloud-init.yaml을 열어 보면 맨 위에 이런 주석이 있습니다.

# This file is generated from information provided by the datasource.  Changes
# to it will not persist across an instance reboot.  To disable cloud-init's
# network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}

주석이 말하는 대로, 이 파일을 고쳐도 cloud-init이 네트워크 설정을 다시 생성하는 상황(클라우드 인스턴스 재부팅, 인스턴스 ID 변경, VM 복제 등)에서는 수정 내용이 사라질 수 있습니다. 물리 서버에서는 설치 후 다시 생성되지 않는 경우도 많지만, 확실하게 하려면 주석이 안내하는 대로 cloud-init의 네트워크 설정 기능을 끕니다.

echo 'network: {config: disabled}' | sudo tee /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg

이 파일은 “앞으로 네트워크 설정을 만들지 말라”는 뜻일 뿐, 이미 있는 50-cloud-init.yaml을 지우지는 않습니다. 기존 파일을 그대로 고쳐 쓰거나, 백업 위치로 옮기고 새 파일을 만들면 됩니다. AWS나 GCP 같은 클라우드에서는 사설 IP를 OS 안에서 고정하기보다 클라우드 콘솔에서 고정하는 것이 원칙입니다. 그쪽 메타데이터와 OS 설정이 어긋나면 인스턴스가 네트워크에서 끊길 수 있으므로, 클라우드 VM에서는 이 절의 작업을 하기 전에 플랫폼 문서를 먼저 확인하길 권합니다.

적용하기: SSH로 접속 중이면 netplan apply 대신 netplan try

설정을 고쳤으면 적용 명령은 두 가지가 있습니다.

sudo netplan try

Do you want to keep these settings?


Press ENTER before the timeout to accept the new configuration


Changes will revert in 120 seconds

netplan try는 새 설정을 적용한 뒤 기본 120초 동안 엔터 입력을 기다립니다. 그 안에 엔터를 누르면 설정이 확정되고, 아무 입력이 없으면 이전 설정으로 자동 복구합니다. SSH로 원격 서버의 IP를 바꾸는 경우를 생각하면 이 차이가 큽니다. 주소를 잘못 적어 접속이 끊겨도 2분 뒤에 원래 주소로 돌아오므로 다시 접속할 수 있습니다. 대기 시간은 --timeout 60처럼 바꿀 수 있습니다.

주의할 점은, IP 자체를 바꾸면 성공했더라도 현재 SSH 세션은 옛 주소로 연결되어 있어 응답이 멈춘다는 것입니다. 이 경우 새 주소로 다른 터미널에서 SSH 접속이 되는지 확인한 다음, 원래 세션으로 돌아와 엔터를 눌러야 합니다. 원래 세션이 이미 끊겨 엔터를 누를 방법이 없다면 120초 뒤 롤백되므로, 새 주소 접속을 확인했다면 그 세션에서 sudo netplan apply로 한 번 더 확정하면 됩니다. 세션이 끊길 상황에 대비해 tmux 안에서 실행해 두면 편합니다(SSH 원격 접속 실무 팁의 세션 유지 부분 참고).

sudo netplan apply

netplan apply는 확인 없이 즉시 적용합니다. 콘솔(모니터·IPMI·클라우드 시리얼 콘솔)에서 직접 작업하고 있거나, netplan try로 이미 검증한 설정을 확정할 때 씁니다. 적용 전에 문법만 검사하고 싶다면 sudo netplan generate를 먼저 실행하면 됩니다. 에러가 없으면 아무것도 출력하지 않고 끝납니다.

netplan generate 에러: 대부분 들여쓰기

YAML은 들여쓰기가 곧 구조라서, 공백 하나만 어긋나도 netplan이 파일을 읽지 못합니다. 에러 메시지에는 파일명과 줄:칸 위치가 붙어 나오므로 그 줄을 먼저 봅니다. 아래 메시지들은 netplan 버전에 따라 문구가 조금씩 다를 수 있습니다.

탭 문자로 들여쓰기한 경우입니다. YAML은 들여쓰기에 탭을 허용하지 않습니다.

/etc/netplan/99-static.yaml:5:1: Invalid YAML: tabs are not allowed for indent:

같은 단계의 항목인데 칸 수가 다른 경우입니다.

/etc/netplan/99-static.yaml:8:7: Invalid YAML: inconsistent indentation:

addresses: 아래에 값을 목록이 아닌 형태로 적거나 상위 키와 같은 높이에 적어 구조가 어긋난 경우에는 이런 메시지가 나옵니다.

/etc/netplan/99-static.yaml:7:7: Error in network definition: expected sequence

주소에 접두어를 빠뜨린 경우입니다.

/etc/netplan/99-static.yaml:7:11: Error in network definition: address '192.168.0.50' is missing /prefixlength

탭이 섞였는지 눈으로는 구분이 안 되므로 cat -A로 확인하면 탭이 ^I로 보입니다.

sudo cat -A /etc/netplan/99-static.yaml | grep -n '\^I'

공백 칸 수는 2칸이든 4칸이든 상관없지만 한 파일 안에서 일관되어야 합니다. 편집기로 nano를 쓴다면 붙여 넣은 내용에 탭이 섞이지 않았는지 특히 주의해야 합니다.

부팅이 2분씩 멈출 때: optional: true

랜선이 꽂혀 있지 않은 포트까지 netplan에 정의해 두면, 부팅 중 다음 메시지가 뜨면서 최대 2분 정도 기다리는 일이 생깁니다.

A start job is running for Wait for Network to be Configured (1min 30s / no limit)

systemd-networkd-wait-online이 netplan에 정의된 인터페이스가 모두 연결될 때까지 기다리기 때문입니다. 항상 연결되어 있지 않은 인터페이스에는 optional: true를 붙이면 기다리지 않습니다.

  ethernets:
    enp3s0:
      dhcp4: false
      addresses: [192.168.0.50/24]
      routes:
        - to: default
          via: 192.168.0.1
    enp4s0:
      dhcp4: true
      optional: true

Wi-Fi 인터페이스에 고정 IP 주기

무선 인터페이스는 ethernets: 대신 wifis: 아래에 적고, 접속할 SSID와 비밀번호를 함께 넣습니다.

network:
  version: 2
  renderer: networkd
  wifis:
    wlp2s0:
      dhcp4: false
      addresses: [192.168.0.51/24]
      routes:
        - to: default
          via: 192.168.0.1
      nameservers:
        addresses: [192.168.0.1]
      access-points:
        "MyHomeWiFi":
          password: "wifi-password-here"

SSID에 공백이나 특수문자가 있을 수 있으므로 따옴표로 감싸는 것이 안전합니다. 이 파일에 비밀번호가 평문으로 들어가는 것이 앞에서 본 권한 경고가 생긴 이유이기도 하니, 반드시 600 권한으로 둡니다. 서버(networkd 렌더러)에서 Wi-Fi를 쓰려면 wpasupplicant 패키지가 필요합니다. 설치 시 Wi-Fi로 설치했다면 들어가 있지만, 유선으로 설치한 서버에 나중에 무선을 붙였다면 패키지가 없을 수 있으므로 유선이 연결된 상태에서 미리 설치해 둡니다.

데스크톱이라면 이 YAML을 쓸 필요 없이 다음 절의 NetworkManager 방법으로 Wi-Fi 연결 하나하나에 고정 IP를 줄 수 있습니다. 같은 노트북이라도 집 Wi-Fi에서만 고정 IP를 쓰고 카페 Wi-Fi는 DHCP로 두는 식으로 연결별로 다르게 설정할 수 있다는 점이 NetworkManager 쪽의 장점입니다.

데스크톱에서는 nmcli나 설정 앱으로

설정 앱 경로

설정 → 네트워크(Wi-Fi라면 Wi-Fi)를 엽니다.
사용 중인 연결 옆의 톱니바퀴 아이콘을 누릅니다.
IPv4 탭에서 IPv4 방식을 수동으로 바꿉니다.
주소에 192.168.0.50, 네트마스크에 255.255.255.0(또는 24), 게이트웨이에 192.168.0.1을 입력합니다.
DNS 항목의 자동을 끄고 DNS 서버를 쉼표로 구분해 입력합니다. 수동 방식에서는 DHCP로 받아 올 DNS가 없으므로, 이 칸을 비워 두면 이름 풀이가 되지 않습니다.
적용을 누른 뒤, 연결 스위치를 껐다 켜야 새 설정이 반영됩니다.

마지막 단계를 빠뜨리는 경우가 많습니다. 적용을 눌러도 이미 올라와 있는 연결은 기존 주소를 유지하기 때문에, 바뀌지 않았다고 오해하기 쉽습니다.

nmcli로 설정하기

같은 작업을 터미널에서 하려면 먼저 연결 이름을 확인합니다. NetworkManager에서는 인터페이스(장치)와 연결(프로필)이 별개입니다. 장치 이름은 enp3s0이지만 연결 이름은 “유선 연결 1”이나 Wi-Fi SSID처럼 되어 있습니다.

nmcli con show

NAME          UUID                                  TYPE      DEVICE
유선 연결 1    3c1e...                               ethernet  enp3s0
MyHomeWiFi    8a2f...                               wifi      --

연결 이름에 공백이 있으면 따옴표로 감싸서 수정합니다.

sudo nmcli con mod "유선 연결 1" \
  ipv4.addresses 192.168.0.50/24 \
  ipv4.gateway 192.168.0.1 \
  ipv4.dns "1.1.1.1 8.8.8.8" \
  ipv4.method manual
sudo nmcli con up "유선 연결 1"

con mod는 저장된 프로필만 바꾸고, con up을 해야 실제 인터페이스에 반영됩니다. 주소 없이 ipv4.method manual만 먼저 바꾸려고 하면 수동 방식인데 주소가 비어 있다는 검증 에러가 납니다. 위처럼 주소와 방식을 한 명령에 같이 넣으면 됩니다. 원격에서 con up을 실행하면 그 순간 주소가 바뀌어 SSH가 끊기므로, 데스크톱을 원격으로 다룰 때는 이 점을 감안해야 합니다.

24.04 데스크톱에서 이렇게 저장한 프로필은 /etc/netplan/90-NM-<UUID>.yaml에 기록됩니다. 이 파일을 열어 보면 방금 넣은 값이 netplan 문법으로 들어가 있는 것을 볼 수 있지만, 수정은 계속 nmcli나 설정 앱으로 하는 편이 엇갈림이 없습니다.

DNS가 제대로 설정됐는지 확인하기

고정 IP 설정 후 가장 흔한 증상은 “IP로 핑은 되는데 도메인 이름이 안 풀린다”입니다. 우분투는 systemd-resolved가 DNS 질의를 받아 실제 DNS 서버로 전달하는 구조이고, /etc/resolv.conf에는 항상 로컬 스텁 주소가 적혀 있습니다.

cat /etc/resolv.conf

nameserver 127.0.0.53
options edns0 trust-ad

여기 127.0.0.53만 보인다고 DNS 설정이 안 된 것은 아닙니다. 실제로 어느 DNS 서버를 쓰는지는 resolvectl로 봐야 합니다.

resolvectl status enp3s0

Link 2 (enp3s0)
    Current Scopes: DNS
         Protocols: +DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 1.1.1.1
       DNS Servers: 1.1.1.1 8.8.8.8

DNS Servers에 netplan이나 nmcli에 적은 주소가 나오면 정상입니다. 비어 있다면 nameservers 항목이 빠졌거나 들여쓰기가 틀려 무시된 것입니다. 실제 이름 풀이는 다음으로 확인합니다.

resolvectl query ubuntu.com

/etc/resolv.conf를 직접 고쳐서 DNS를 바꾸는 방법은 쓰지 않는 것이 좋습니다. 이 파일은 systemd-resolved가 관리하는 심볼릭 링크라서, 고친 내용은 다음 재시작이나 네트워크 변경 때 덮어써집니다.

끝까지 확인할 것

적용 후에는 주소, 경로, 외부 통신, DNS를 순서대로 확인합니다. 어느 단계에서 막히는지에 따라 원인이 갈립니다.

ip -br a                 # 고정 주소 하나만 붙어 있는지
ip route                 # default via 192.168.0.1 이 하나만 있는지
ping -c 3 192.168.0.1    # 게이트웨이까지 가는지
ping -c 3 1.1.1.1        # 인터넷까지 가는지(IP)
ping -c 3 ubuntu.com     # 이름 풀이까지 되는지
sudo netplan status      # netplan이 보는 인터페이스별 상태

게이트웨이 핑이 안 되면 주소·대역·인터페이스 이름이 틀렸을 가능성이 높고, 게이트웨이까지는 되는데 1.1.1.1이 안 되면 기본 경로가 빠졌거나 게이트웨이 주소가 틀린 것입니다. 1.1.1.1까지는 되는데 ubuntu.com이 안 되면 DNS 문제입니다. 핑 자체를 막아 둔 네트워크도 있으니, 핑 실패만으로 단정하지 말고 curl -I https://ubuntu.com도 함께 시도해 보면 좋습니다.

같은 대역의 다른 기기가 이미 그 주소를 쓰고 있다면 증상이 간헐적으로 나타납니다. 고정 주소를 정하기 전에 ping 192.168.0.50으로 응답하는 기기가 없는지, 공유기의 접속 기기 목록에 그 주소가 없는지 확인하는 것이 IP 충돌을 피하는 가장 간단한 방법입니다.

OS를 건드리지 않는 대안: 공유기에서 DHCP 예약

집이나 작은 사무실이라면 OS에서 고정 IP를 설정하지 않고, 공유기 관리 페이지에서 이 기기의 MAC 주소에 특정 IP를 예약(DHCP 예약, 고정 할당, Static Lease 등 제조사마다 이름이 다릅니다)하는 방법도 있습니다. 우분투는 DHCP 설정 그대로 두고, 공유기가 항상 같은 주소를 나눠 주게 하는 방식입니다.

이 방법의 장점은 주소 관리가 공유기 한 곳에 모인다는 것입니다. 게이트웨이와 DNS도 DHCP로 계속 받기 때문에 공유기를 교체하거나 대역을 바꿀 때 서버 설정을 고칠 필요가 없고, OS를 재설치해도 같은 주소를 받습니다. 노트북처럼 여러 네트워크를 오가는 기기도 다른 곳에서는 평소처럼 DHCP로 동작합니다.

반대로 공유기가 꺼져 있거나 DHCP 서버가 응답하지 않으면 주소를 받지 못한다는 점, 그리고 MAC 주소가 바뀌면 예약이 소용없어진다는 점은 단점입니다. 우분투 24.04 데스크톱의 Wi-Fi는 기본적으로 실제 MAC 주소를 쓰지만, 연결 설정에서 MAC 주소 무작위화를 켜 두었다면 예약이 맞지 않으므로 해당 연결의 “복제된 주소” 설정을 확인해야 합니다. 공유기 관리 권한이 없는 회사망이라면 이 방법은 쓸 수 없고, 네트워크 담당자에게 주소를 할당받아 위의 OS 설정을 해야 합니다.

원래대로 되돌리는 법

고정 IP가 더 이상 필요 없거나 설정이 꼬여서 처음 상태로 돌아가고 싶을 때의 방법입니다.

서버라면 백업해 둔 파일을 되돌리고 적용합니다.

sudo cp /root/50-cloud-init.yaml.bak /etc/netplan/50-cloud-init.yaml
sudo rm /etc/netplan/99-static.yaml     # 새로 만든 파일이 있었다면
sudo chmod 600 /etc/netplan/*.yaml
sudo netplan try

백업이 없다면 DHCP 설정을 직접 적으면 됩니다. 핵심은 dhcp4: true 한 줄입니다.

network:
  version: 2
  ethernets:
    enp3s0:
      dhcp4: true

cloud-init 네트워크 기능을 껐었다면 다시 켜고 싶을 때 /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg를 지우면 됩니다. 다만 지운 뒤 cloud-init이 언제 네트워크 설정을 다시 만들지는 환경마다 달라서, 지금 쓰는 netplan 파일은 그대로 두는 편이 예측 가능합니다.

데스크톱이라면 연결 방식을 자동으로 돌리고 수동으로 넣은 값을 비웁니다.

sudo nmcli con mod "유선 연결 1" ipv4.method auto ipv4.addresses "" ipv4.gateway "" ipv4.dns ""
sudo nmcli con up "유선 연결 1"

설정 앱에서는 IPv4 탭에서 방식을 자동(DHCP) 으로 바꾸고 DNS의 자동을 다시 켠 뒤, 연결을 껐다 켜면 됩니다.

고정 IP를 잡았다면 다음 단계로 그 주소를 실제로 활용할 준비를 하게 됩니다. 서버라면 ufw로 SSH 포트만 열어 두는 방화벽 설정을 먼저 하는 것이 좋고, 이 내용은 우분투 필수 명령어의 ufw 부분에서 다룹니다. 새 서버에서 사용자 계정, SSH 키, 기본 패키지까지 이어서 세팅하려면 우분투 설치 후 개발자가 처음 할 일을 참고하면 됩니다.