책에 포함된 노트처음부터 실전까지, 터미널이 두렵지 않은 Linux 활용법

실전 문제 해결 시나리오

2026-06-01Views 22약 7분생성형 AI 활용

Summary

문제 해결은 명령어 암기가 아니라 확인 순서입니다

Linux 문제 해결은 어두운 방에서 물건을 찾는 일과 비슷합니다. 손에 잡히는 것을 아무거나 뒤지는 것보다, 먼저 불을 켜고 방의 구조를 확인한 뒤 한 구역씩 살피는 편이 빠릅니다. 터미널에서도 마찬가지입니다. 문제가 생기면 바로 삭제하거나 재시작하기보다, 증상을 작게 나누고 증거를 읽어야 합니다.

기본 순서는 다음과 같습니다.

증상 확인: 무엇이 안 되는가? 느린가, 공간이 없는가, 접속이 안 되는가?
범위 확인: 내 계정만의 문제인가, 서비스 하나인가, 시스템 전체인가?
상태 읽기: df, top, ss, journalctl처럼 현재 상태를 보여 주는 명령을 먼저 실행합니다.
가설 세우기: 디스크 부족, CPU 과부하, 포트 충돌, 권한 문제처럼 가능한 원인을 나눕니다.
작게 조치하기: 한 번에 하나만 바꾸고 결과를 확인합니다.
기록하기: 어떤 명령을 실행했고 어떤 출력이 나왔는지 남깁니다.

이 장에서는 자주 만나는 다섯 가지 문제를 이 순서로 풀어 봅니다.

실전 문제 해결 시나리오 AI 생성 이미지

시나리오 1: 디스크가 가득 찼을 때

증상은 보통 이렇게 나타납니다. 파일 저장이 실패합니다. 패키지 설치가 멈춥니다. 서비스 로그에 No space left on device가 보입니다. 이때 바로 큰 파일을 지우면 위험합니다. 먼저 어느 파일 시스템이 찼는지 확인합니다.

df -h

Use%가 100%에 가까운 줄을 찾고, Mounted on을 봅니다. /가 찼는지, /home이 찼는지, /var가 찼는지에 따라 찾아야 할 위치가 다릅니다. 파일은 별로 없는데도 새 파일을 만들 수 없다면 inode가 부족할 수 있습니다.

df -ih

다음은 큰 디렉터리를 단계적으로 좁힙니다. 예를 들어 /var가 찼다면 다음처럼 한 단계만 봅니다.

sudo du -xhd1 /var 2>/dev/null | sort -h

du는 실제 파일 사용량을 찾고, -x는 다른 파일 시스템으로 넘어가지 않게 합니다. 가장 큰 디렉터리를 찾으면 다시 그 안으로 들어갑니다.

sudo du -xhd1 /var/log 2>/dev/null | sort -h

로그가 원인이라면 journalctl도 확인합니다.

journalctl --disk-usage

systemd journal이 너무 크면 보관 기간을 줄일 수 있습니다. 단, 로그는 문제의 증거이기도 하므로 장애 원인을 확인하기 전에 무조건 지우지 않습니다.

sudo journalctl --vacuum-time=7d

삭제했는데도 공간이 돌아오지 않는 경우가 있습니다. 어떤 프로세스가 이미 삭제된 파일을 계속 열고 있으면, 디렉터리에서는 사라졌지만 디스크 공간은 아직 사용 중입니다.

sudo lsof +L1

출력에서 큰 로그 파일을 잡고 있는 서비스가 보이면 서비스를 재시작해야 공간이 반환됩니다.

sudo systemctl restart 서비스이름

패키지 캐시가 원인일 때는 배포판별 명령이 다릅니다.

# Ubuntu/Debian
sudo apt clean

# Fedora/RHEL
sudo dnf clean packages

# Arch
sudo pacman -Sc

pacman -Sc는 설치되지 않은 패키지 캐시를 정리합니다. 더 강한 정리 옵션은 되돌리기 어렵기 때문에 출력 설명을 읽고 진행합니다.

삭제 전에는 항상 대상과 위치를 확인합니다.

pwd
ls -lh /삭제할/경로

디스크 부족 문제의 목표는 아무 파일이나 지우는 것이 아니라, 어느 마운트 지점이 찼고, 어떤 종류의 파일이 원인인지를 확인하는 것입니다.

시나리오 2: 서버가 느릴 때

느리다는 말은 넓습니다. CPU가 바쁜 것일 수도 있고, 메모리가 부족할 수도 있고, 디스크가 느릴 수도 있습니다. 먼저 전체 부하를 봅니다.

uptime
nproc

uptime의 load average는 최근 1분, 5분, 15분 동안 실행 대기 중인 작업의 평균입니다. nproc로 CPU 코어 수를 확인해 함께 해석합니다. 코어가 2개인데 load average가 계속 10이라면 작업이 많이 밀린 상태입니다.

실시간으로 어떤 프로세스가 자원을 쓰는지 봅니다.

top

%CPU가 높은 프로세스가 하나인지, 여러 개인지 확인합니다. 상단의 %wa가 높다면 CPU가 계산을 못 하는 것이 아니라 디스크 입출력을 기다리는 상태일 수 있습니다. 메모리는 다음 명령으로 봅니다.

free -h

Linux는 남는 메모리를 캐시로 적극 사용합니다. 그래서 free가 작다고 바로 문제는 아닙니다. available이 매우 작고 swap 사용량이 계속 늘면 메모리 부족을 의심합니다.

조금 더 흐름을 보고 싶다면 vmstat를 사용합니다.

vmstat 1 5

r은 CPU를 기다리는 작업 수, si와 so는 swap 입출력, wa는 I/O 대기 비율입니다. 숫자가 한 번 튄 것보다 여러 번 반복되는 패턴이 중요합니다.

디스크 병목은 iostat가 유용합니다. 명령이 없다면 sysstat 패키지를 설치합니다.

# Ubuntu/Debian
sudo apt install sysstat

# Fedora/RHEL
sudo dnf install sysstat

# Arch
sudo pacman -S sysstat

설치 후 확인합니다.

iostat -xz 1 3

디스크의 %util이 계속 높고 await가 크면 디스크 응답이 느린 상태입니다. 이때 CPU 프로세스만 죽여도 효과가 적을 수 있습니다. 백업, 압축, 대량 로그 쓰기, 데이터베이스 작업처럼 디스크를 많이 쓰는 작업을 찾아야 합니다.

서버가 느릴 때 조치는 원인별로 다릅니다.

CPU 과부하: 어떤 프로세스가 높은 CPU를 쓰는지 확인하고 설정, 작업량, 반복 실행 여부를 점검합니다.
메모리 부족: 불필요한 프로세스를 줄이고, 서비스 설정의 워커 수나 캐시 크기를 확인합니다.
디스크 I/O 병목: 대량 파일 작업, 로그 폭증, 백업 시간대를 확인합니다.
네트워크 지연: 다음 네트워크 점검 절차로 넘어갑니다.

무조건 재부팅하면 일시적으로 나아질 수는 있습니다. 하지만 원인을 모르면 같은 문제가 다시 옵니다.

시나리오 3: 포트가 이미 사용 중일 때

웹 서버나 개발 서버를 실행했는데 Address already in use와 비슷한 메시지가 나올 때가 있습니다. 이는 누군가 이미 그 포트를 사용 중이라는 뜻입니다. 포트는 건물의 방 번호처럼 하나의 서비스가 먼저 차지하면 다른 서비스가 같은 번호를 쓸 수 없습니다.

예를 들어 8080번 포트를 확인합니다.

sudo ss -tulpen | grep ':8080'

또는 lsof로 볼 수 있습니다.

sudo lsof -i :8080

출력에서 PID와 프로그램 이름을 확인합니다. 여기서 중요한 것은 바로 kill -9를 쓰지 않는 것입니다. 먼저 그 프로세스가 서비스로 관리되는지 봅니다.

ps -fp PID
systemctl status 서비스이름

systemd 서비스라면 kill보다 systemctl로 멈추거나 재시작하는 편이 안전합니다.

sudo systemctl stop 서비스이름
sudo systemctl restart 서비스이름

일회성 개발 서버라면 먼저 정상 종료 신호를 보냅니다.

kill -TERM PID

그래도 종료되지 않고, 저장 중인 데이터가 없다는 점을 확인했을 때만 SIGKILL을 고려합니다.

kill -KILL PID

다른 방법은 새 프로그램의 포트를 바꾸는 것입니다. 이미 80번 포트에서 웹 서버가 운영 중이라면 개발 서버는 8080이나 3000처럼 다른 포트를 쓰는 편이 낫습니다.

포트 충돌 문제의 핵심 질문은 세 가지입니다.

어떤 포트가 충돌하는가?
그 포트를 어떤 PID가 쓰는가?
그 PID는 systemd 서비스인가, 일회성 프로세스인가?

이 세 가지를 확인하면 멈출지, 재시작할지, 포트를 바꿀지 판단할 수 있습니다.

시나리오 4: Permission denied가 나올 때

Permission denied는 단순히 권한이 없다는 말이지만, 원인은 여러 가지입니다. 파일 자체 권한일 수도 있고, 부모 디렉터리 권한일 수도 있고, 실행 권한이 없을 수도 있습니다. 관리자 권한이 필요한 작업일 수도 있습니다.

먼저 내가 누구인지 확인합니다.

whoami
id

그다음 대상 파일과 디렉터리 권한을 봅니다.

ls -l 파일명
ls -ld 디렉터리명

경로 중간의 디렉터리에 실행 권한 x가 없으면 파일 권한이 맞아도 접근할 수 없습니다. 긴 경로는 namei로 한 단계씩 확인하면 편합니다.

namei -l /var/www/html/index.html

스크립트를 실행할 때 거부된다면 실행 권한이 없을 수 있습니다.

ls -l script.sh
chmod u+x script.sh
./script.sh

파일을 수정할 수 없다면 소유자와 그룹을 확인합니다.

ls -l 설정파일

내가 소유자가 아니고 쓰기 권한도 없다면, 그 파일을 수정할 권한이 없는 것입니다. 설정 파일처럼 시스템 전체에 영향을 주는 파일은 sudo가 필요할 수 있습니다.

sudo nano /etc/설정파일

하지만 모든 권한 문제를 sudo로 해결하려고 하면 안 됩니다. 내 홈 디렉터리 안의 파일이 root 소유가 되었다면, 매번 sudo로 편집하는 대신 소유권을 바로잡는 것이 맞습니다.

sudo chown 사용자명:사용자명 파일명

공유 디렉터리에서는 그룹 권한을 확인합니다.

ls -ld /공유/디렉터리
id

내 계정이 필요한 그룹에 없다면 그룹 추가가 필요합니다. 단, 그룹 변경은 관리자 작업이며 새 로그인 후 적용되는 경우가 많습니다.

가장 피해야 할 해결책은 chmod 777입니다. 모두에게 읽기, 쓰기, 실행 권한을 주면 당장은 문제가 사라진 것처럼 보이지만, 보안과 실수 위험이 커집니다. 권한 문제는 다음 순서로 좁힙니다.

현재 사용자 확인
파일 권한 확인
부모 디렉터리 권한 확인
실행 권한 필요 여부 확인
소유자와 그룹 확인
정말 관리자 권한이 필요한지 확인

시나리오 5: 인터넷 연결이 안 될 때

네트워크 문제는 주소, 길, 이름, 문 순서로 보면 덜 헷갈립니다. 주소는 IP, 길은 게이트웨이와 라우팅, 이름은 DNS, 문은 포트와 방화벽입니다.

먼저 IP 주소가 있는지 봅니다.

ip addr

사용 중인 인터페이스에 inet 주소가 없다면 네트워크에 제대로 붙지 않은 상태입니다. 다음으로 외부로 나가는 기본 길을 확인합니다.

ip route

default via 줄이 없으면 외부 인터넷으로 나갈 경로가 없는 것입니다. 게이트웨이가 보이면 먼저 게이트웨이에 닿는지 확인합니다.

ping -c 3 게이트웨이IP

게이트웨이는 되지만 인터넷 IP가 안 되면 외부 회선이나 라우팅 문제일 수 있습니다.

ping -c 3 1.1.1.1

IP는 되는데 도메인만 안 되면 DNS 문제를 의심합니다.

getent hosts example.com
resolvectl status

resolvectl이 없는 환경에서는 다음 파일을 확인할 수 있습니다.

cat /etc/resolv.conf

웹 서비스 접속 문제라면 원격 서버의 포트 응답을 봅니다.

curl -I https://example.com

내 서버에서 특정 포트를 열었는데 외부에서 접속이 안 된다면 로컬 방화벽도 확인합니다.

# Ubuntu 계열에서 ufw 사용 시
sudo ufw status verbose

# Fedora/RHEL 계열에서 firewalld 사용 시
sudo firewall-cmd --list-all

서버 안에서 서비스가 실제로 듣고 있는지도 확인합니다.

sudo ss -tulpen
systemctl status 서비스이름

여기서 127.0.0.1:포트에만 묶여 있으면 같은 서버 내부에서만 접속할 수 있습니다. 외부 접속이 필요하면 서비스 설정에서 바인드 주소를 확인해야 합니다. 반대로 0.0.0.0:포트는 모든 IPv4 인터페이스에서 받을 수 있으므로 방화벽과 보안 설정을 함께 점검합니다.

네트워크 점검 순서는 다음처럼 기억하면 됩니다.

IP가 있는가?
기본 게이트웨이가 있는가?
게이트웨이에 ping이 되는가?
외부 IP에 ping이 되는가?
도메인 이름 해석이 되는가?
방화벽이 막고 있지 않은가?
원격 서버의 서비스가 살아 있는가?

짧은 실습 과제

실제 장애 상황을 만들지 않아도 점검 순서는 연습할 수 있습니다. 아래 명령을 실행하고 출력에서 무엇을 봐야 하는지 적어 보세요.

df -h
journalctl --disk-usage
uptime
free -h
vmstat 1 5
sudo ss -tulpen
ip addr
ip route

추가로, 현재 사용자 홈 디렉터리에서 작은 스크립트를 만들고 권한 변화를 확인해 봅니다.

cd ~/linux-practice
printf '%sn' '#!/usr/bin/env bash' 'echo hello' > hello.sh
ls -l hello.sh
./hello.sh
chmod u+x hello.sh
./hello.sh

처음 실행이 실패했다면 그 실패 메시지를 읽습니다. 그다음 chmod u+x 후 권한 문자열이 어떻게 바뀌었는지 확인합니다. 문제 해결 능력은 성공한 명령보다 실패한 출력에서 더 많이 자랍니다.

마지막 점검표

실전에서는 명령어를 많이 입력하는 사람이 아니라, 순서를 잃지 않는 사람이 문제를 빨리 해결합니다.

공간 문제는 df로 위치를 찾고 du로 원인을 좁힙니다.
삭제 후 공간이 안 돌아오면 lsof +L1을 봅니다.
느린 서버는 CPU, 메모리, 디스크 I/O를 나누어 확인합니다.
포트 충돌은 ss나 lsof로 PID를 찾고, 서비스인지 확인한 뒤 조치합니다.
권한 문제는 파일뿐 아니라 부모 디렉터리, 실행 권한, 소유권, sudo 필요 여부를 함께 봅니다.
네트워크 문제는 IP, 게이트웨이, DNS, 방화벽, 원격 서비스 순서로 점검합니다.

Linux 활용의 핵심은 모든 명령어를 외우는 것이 아닙니다. 현재 상태를 읽고, 원인을 좁히고, 안전하게 한 단계씩 바꾸는 것입니다. 이 흐름을 익히면 낯선 오류 메시지를 만나도 터미널 앞에서 멈추지 않을 수 있습니다.

책 목록

처음부터 실전까지, 터미널이 두렵지 않은 Linux 활용법

전체 목차 보기