Linux 실무 기초
리눅스는 전 세계 AI/ML 인프라의 표준 운영체제입니다. 클라우드 GPU 인스턴스, 온프레미스 학습 서버, Docker 컨테이너 — 모두 리눅스 위에서 동작합니다. Python 가상환경을 만들고, 학습 데이터를 관리하고, GPU 상태를 모니터링하고, 서비스를 등록하는 모든 과정이 리눅스 명령어로 이루어집니다. 이 문서에서는 GPU 서버를 운영하는 데 필요한 리눅스 실무 지식을 체계적으로 다룹니다.학습 목표
- 리눅스 파일시스템 구조를 이해하고, 각 디렉터리의 역할을 설명할 수 있다
- 파일 관리, 텍스트 처리, 검색 명령어를 상황에 맞게 조합하여 사용할 수 있다
- 프로세스와 systemd 서비스를 관리하고 문제를 진단할 수 있다
- 디스크, 메모리, GPU 모니터링을 통해 서버 상태를 실시간으로 파악할 수 있다
왜 중요한가
AI/ML 엔지니어가 마주하는 문제의 상당수는 리눅스 시스템 레벨에서 발생합니다. “디스크가 꽉 찼는데 어디서 용량을 잡아먹는지 모르겠다”, “학습 프로세스가 GPU를 안 쓰고 있다”, “서버 재시작 후 서비스가 자동으로 올라오지 않는다” — 이런 문제를 해결하려면 리눅스 명령어를 자유자재로 다뤄야 합니다. 리눅스 실무 능력은 개발 속도를 직접적으로 좌우합니다. 데이터셋에서 특정 패턴을 찾고, 로그에서 에러를 추적하고, 백그라운드 프로세스를 관리하는 것 — 이 모든 작업의 효율성이 리눅스 숙련도에 달려있습니다.리눅스 파일시스템 구조
리눅스의 모든 것은 파일입니다. 디바이스, 프로세스 정보, 커널 파라미터까지 파일 형태로 접근합니다.| 경로 | 설명 | ML 실무 연관 |
|---|---|---|
/ | 루트 디렉터리, 모든 경로의 시작점 | — |
/home | 사용자 홈 디렉터리 | 개인 설정, SSH 키, 스크립트 |
/etc | 시스템 설정 파일 | 네트워크 설정, 서비스 설정, 환경변수 |
/var | 가변 데이터 (로그, 캐시, 스풀) | 시스템 로그(/var/log), Docker 데이터 |
/tmp | 임시 파일 (재부팅 시 삭제) | 학습 중 임시 캐시, 중간 처리 파일 |
/opt | 서드파티 소프트웨어 설치 | Anaconda, 상용 소프트웨어 |
/usr/local | 로컬 설치 소프트웨어 | CUDA, cuDNN, 직접 빌드한 라이브러리 |
/data | (관례적) 대용량 데이터 전용 | 데이터셋, 모델 체크포인트, MLflow artifacts |
/proc | 가상 파일시스템 (프로세스 정보) | CPU 정보, 메모리 상태, 프로세스 상세 |
/dev | 디바이스 파일 | GPU 디바이스(/dev/nvidia*), 블록 디바이스 |
/sys | 커널과 하드웨어 정보 | GPU 전력/온도, 디바이스 속성 |
/mnt, /media | 마운트 포인트 | 외장 디스크, NFS 공유, S3 FUSE 마운트 |
/data는 FHS(Filesystem Hierarchy Standard) 표준 디렉터리는 아니지만, ML 서버에서 별도 디스크를 마운트하여 데이터셋과 모델을 저장하는 관례적 경로입니다. 프로젝트마다 /data/datasets, /data/models, /data/archive 등으로 구분하면 관리가 편합니다.필수 명령어
파일 관리
| 명령어 | 설명 | 자주 쓰는 옵션 |
|---|---|---|
ls | 디렉터리 내용 목록 | -la (전체+상세), -lhS (크기순), -lt (시간순) |
cp | 파일/디렉터리 복사 | -r (재귀), -p (권한 보존), -v (진행 표시) |
mv | 파일/디렉터리 이동/이름변경 | -i (덮어쓰기 확인), -v (진행 표시) |
rm | 파일/디렉터리 삭제 | -r (재귀), -f (강제), -i (확인) |
mkdir | 디렉터리 생성 | -p (중간 디렉터리 자동 생성) |
ln | 링크 생성 | -s (심볼릭 링크) |
touch | 빈 파일 생성 / 타임스탬프 갱신 | — |
tree | 디렉터리 트리 구조 출력 | -L 2 (깊이 제한), -d (디렉터리만) |
텍스트 처리
| 명령어 | 설명 | 자주 쓰는 옵션 |
|---|---|---|
cat | 파일 내용 출력 | -n (줄 번호) |
head | 파일 처음 N줄 출력 | -n 20 (20줄), -c 1000 (1000바이트) |
tail | 파일 마지막 N줄 출력 | -n 20 (20줄), -f (실시간 추적) |
less | 페이지 단위 파일 읽기 | /검색어 (검색), q (종료) |
wc | 줄/단어/바이트 수 카운트 | -l (줄 수만) |
sort | 정렬 | -n (숫자), -r (역순), -k (필드 지정) |
uniq | 중복 제거 | -c (카운트) |
cut | 필드 추출 | -d',' (구분자), -f1,3 (필드 선택) |
검색
| 명령어 | 설명 | 실무 예시 |
|---|---|---|
find | 파일시스템 검색 (이름, 크기, 시간 등) | find . -name "*.pt" -size +1G |
grep | 텍스트 패턴 검색 | grep -r "learning_rate" configs/ |
rg (ripgrep) | 고속 텍스트 검색 | rg "import torch" --type py |
locate | 인덱스 기반 빠른 파일 검색 | locate "*.ckpt" |
파일 검색과 텍스트 처리 실전
find + exec 조합
awk/sed 기초
xargs 활용
프로세스 관리
프로세스 확인과 제어
| 명령어 | 설명 | 핵심 사용법 |
|---|---|---|
ps | 프로세스 목록 | ps aux (전체), ps -eo pid,ppid,%cpu,%mem,cmd |
top | 실시간 프로세스 모니터 | P (CPU순), M (메모리순), 1 (코어별) |
htop | 향상된 프로세스 모니터 | 트리 뷰, 마우스 지원, 필터링 |
kill | 프로세스에 시그널 전송 | kill PID (SIGTERM), kill -9 PID (SIGKILL) |
nice | 우선순위 지정하여 실행 | nice -n 10 python preprocess.py |
renice | 실행 중 우선순위 변경 | renice -n 5 -p PID |
jobs | 현재 셸의 백그라운드 작업 목록 | — |
fg | 백그라운드 → 포그라운드 | fg %1 |
bg | 정지된 작업 → 백그라운드 실행 | bg %1 |
systemd 서비스 관리
systemd는 현대 리눅스의 서비스 관리 시스템입니다. 부팅 시 자동 실행, 프로세스 재시작, 로그 관리 등을 담당합니다.기본 명령어
커스텀 서비스 등록
디스크, 메모리, GPU 모니터링
디스크
메모리
GPU 모니터링 (nvidia-smi)
| nvidia-smi 항목 | 설명 | 주의 사항 |
|---|---|---|
| GPU-Util | GPU 코어 사용률 | 낮으면 데이터 로딩 병목 가능성 |
| Memory-Usage | GPU 메모리 사용량 | OOM 직전에 확인 필수 |
| Temperature | GPU 온도 | 80–90도에서 스로틀링 발생 (모델별 상이) |
| Power Usage | 전력 소비 | 전력 제한 설정 확인 |
| Processes | GPU 점유 프로세스 | 다른 사용자의 프로세스 확인 |
사용자/그룹 관리
| 명령어 | 설명 | 예시 |
|---|---|---|
useradd | 사용자 생성 | useradd -m -s /bin/bash mluser |
usermod | 사용자 수정 | usermod -aG docker mluser (docker 그룹 추가) |
passwd | 비밀번호 설정 | passwd mluser |
groups | 그룹 확인 | groups mluser |
id | 사용자 ID/그룹 정보 | id mluser |
sudo | 관리자 권한 실행 | sudo systemctl restart nginx |
패키지 관리
시스템 패키지
| 패키지 관리자 | 배포판 | 설치 | 검색 | 업데이트 |
|---|---|---|---|---|
apt | Debian, Ubuntu | apt install pkg | apt search pkg | apt update && apt upgrade |
dnf | RHEL, Fedora | dnf install pkg | dnf search pkg | dnf update |
pacman | Arch | pacman -S pkg | pacman -Ss pkg | pacman -Syu |
Python 패키지 관리자 비교
| 관리자 | 환경 격리 | 속도 | CUDA 호환 | 적합한 용도 |
|---|---|---|---|---|
| pip | venv와 조합 | 보통 | 수동 설정 | 일반 Python 패키지 |
| uv | 자체 venv | 매우 빠름 | 수동 설정 | 빠른 의존성 관리, 현대적 워크플로 |
| conda | 자체 환경 | 느림 | 자동 | CUDA/cuDNN 포함 설치, 과학 컴퓨팅 |
uv는 Rust로 작성된 차세대 Python 패키지 관리자로, pip보다 10-100배 빠릅니다. 새 프로젝트에서는 uv를 권장합니다. 단, CUDA 런타임은 별도로 시스템에 설치해야 합니다.문제 해결: 체계적 접근
AI/ML에서 이 개념이 중요한 이유
| 리눅스 기술 | ML 실무 활용 |
|---|---|
find + exec | 오래된 체크포인트 자동 정리, 데이터셋 파일 관리 |
grep/rg | 학습 로그 분석, 설정 파일 검색, 코드베이스 탐색 |
nvidia-smi | GPU 메모리/온도/사용률 실시간 모니터링 |
| systemd | MLflow, JupyterLab, API 서버 자동 시작 |
du/df | 데이터셋/체크포인트 용량 관리, 디스크 부족 예방 |
| 사용자/그룹 | 팀 공유 서버에서 데이터/모델 접근 권한 관리 |
| 패키지 관리 | CUDA, cuDNN, PyTorch 등 의존성 관리 |
| 프로세스 관리 | 학습 프로세스 모니터링, 좀비 프로세스 정리 |
디스크가 꽉 찼는데 뭐가 용량을 차지하는지 모르겠어요
디스크가 꽉 찼는데 뭐가 용량을 차지하는지 모르겠어요
du -sh /* 2>/dev/null | sort -rh | head로 루트 레벨에서 큰 디렉터리를 찾고, 해당 디렉터리로 들어가 반복합니다. ML 환경에서는 체크포인트(*.pt, *.ckpt), Docker 이미지(/var/lib/docker), HuggingFace 캐시(~/.cache/huggingface)가 주범인 경우가 많습니다. find / -size +1G -exec ls -lh {} \; 2>/dev/null로 1GB 이상 파일을 바로 찾을 수도 있습니다.nvidia-smi에서 GPU 사용률이 0%인데 메모리는 할당되어 있어요
nvidia-smi에서 GPU 사용률이 0%인데 메모리는 할당되어 있어요
GPU 메모리만 할당하고 연산을 수행하지 않는 상태입니다. 모델을 GPU로 전송한 후 데이터 로딩 병목이 있거나, 학습이 CPU에서 전처리 중일 수 있습니다.
DataLoader의 num_workers를 늘리거나 pin_memory=True를 설정하여 데이터 공급 속도를 높이세요. 또한, 다른 사용자의 프로세스가 GPU 메모리를 점유하고 있는 것은 아닌지 확인하세요.서버 재시작 후 서비스가 자동으로 안 올라와요
서버 재시작 후 서비스가 자동으로 안 올라와요
systemctl enable <서비스>로 부팅 시 자동 시작을 설정했는지 확인하세요. Docker 컨테이너라면 --restart=unless-stopped 옵션이 필요합니다. PM2를 사용한다면 pm2 startup과 pm2 save가 필요합니다. systemctl is-enabled <서비스>로 현재 상태를 확인할 수 있습니다.find 명령어가 너무 느려요
find 명령어가 너무 느려요
find는 실시간으로 파일시스템을 탐색하므로 대용량 디렉터리에서 느립니다. locate 명령어는 인덱스 기반이므로 훨씬 빠르지만, sudo updatedb로 인덱스를 갱신해야 합니다. 코드 검색에는 ripgrep(rg)이 grep -r보다 수십 배 빠릅니다. 또한 검색 범위를 제한하면(find /specific/path) 속도가 크게 향상됩니다.Python 패키지 관리자를 어떤 걸 써야 하나요?
Python 패키지 관리자를 어떤 걸 써야 하나요?
새 프로젝트에서는
uv를 권장합니다. 의존성 해결이 빠르고, pyproject.toml 기반의 현대적 워크플로를 지원합니다. CUDA 드라이버와 런타임은 시스템 레벨에서 설치하고, PyTorch는 uv로 --index-url https://download.pytorch.org/whl/cuXXX를 지정하여 설치합니다. conda는 CUDA를 자동으로 관리하지만 속도가 느리고, 환경이 무거워질 수 있습니다.공유 서버에서 다른 사용자의 GPU 프로세스를 확인하려면?
공유 서버에서 다른 사용자의 GPU 프로세스를 확인하려면?
nvidia-smi로 GPU를 점유하는 프로세스의 PID를 확인한 후, ps -p <PID> -o user,pid,cmd로 어떤 사용자의 어떤 프로세스인지 확인합니다. 팀 규칙으로 CUDA_VISIBLE_DEVICES를 분배하거나, NVIDIA MPS(Multi-Process Service) 또는 GPU 스케줄러(SLURM, Kubernetes GPU Plugin)를 도입하는 것이 바람직합니다.체크리스트
- 리눅스 파일시스템 주요 디렉터리의 역할을 설명할 수 있다
-
ls,cp,mv,rm,mkdir를 옵션과 함께 능숙하게 사용할 수 있다 -
find,grep/rg를 사용하여 파일과 텍스트를 검색할 수 있다 -
ps,top/htop,kill로 프로세스를 확인하고 관리할 수 있다 - systemd 서비스를 확인, 시작, 중지, 등록할 수 있다
-
journalctl로 서비스 로그를 조회할 수 있다 -
df,du,free,nvidia-smi로 시스템 자원을 모니터링할 수 있다 - 사용자와 그룹을 관리하고, 적절한 권한을 설정할 수 있다
- 문제 발생 시 5단계 체계적 접근법을 적용할 수 있다

