![[Linux] 개발자가 왜 리눅스 서버와 커맨드라인을 반드시 배워야 하는가 개념 다이어그램](/images/modules/linux/linux-intro.png)
입사 첫 주. 선임이 Slack으로 메시지를 보냈습니다. "프로덕션 서버 들어가서 Nginx 로그 좀 확인해봐요." AWS 콘솔을 열고 EC2 인스턴스를 찾았지만, 연결 버튼을 누르면 검은 화면에 커서만 깜빡입니다. 마우스로 클릭할 아이콘도, 메뉴도 없습니다. 여기가 Linux 서버입니다. 클라우드 인프라를 다루는 순간 Linux는 선택이 아닌 현실이 됩니다.
- 1Linux가 서버 시장을 지배하는 이유를 비용·성능·생태계로 설명할 수 있다
- 2커널과 배포판의 차이를 구분하고, 배포판별 패키지 관리자를 말할 수 있다
- 3cat /etc/os-release로 현재 서버의 배포판을 확인할 수 있다
- 4--help와 man 페이지를 사용해 모르는 명령어를 스스로 찾을 수 있다
Linux가 서버를 지배하는 이유
비용·성능·생태계 — Linux가 서버 시장을 장악한 3가지 이유
회사에서 처음으로 서버 비용 청구서를 받아보면 OS 라이선스 항목에서 놀라게 됩니다. 100대가 넘는 서버에 Windows Server를 올리면 컴퓨팅 비용과 별개로 OS 비용이 두 배 가까이 붙습니다. 인프라 팀에서 비용 최적화 업무를 맡으면 가장 먼저 손대는 항목 중 하나가 OS 선택입니다.
1. 비용: 라이선스 없음
Windows Server는 코어당 라이선스 비용이 발생합니다. 32코어 서버라면 수백만 원의 OS 비용이 추가됩니다. Ubuntu, Amazon Linux, Rocky Linux는 모두 무료입니다.
# AWS EC2 가격 비교 (us-east-1, m5.large, 2024년)
Amazon Linux 2023: $0.096/시간 ← OS 라이선스 비용 없음
Windows Server: $0.192/시간 ← OS 라이선스 포함
→ 동일 사양에서 월 ~$70 차이, 100대면 ~$7,000/월 절감
2. 성능: GUI가 없어서 빠르다
서버용 Linux는 그래픽 인터페이스를 아예 설치하지 않습니다. 이 환경을 "헤드리스(headless)"라고 부릅니다. OS 자체가 차지하는 메모리가 줄어든 만큼 애플리케이션에 더 많은 RAM이 할당됩니다.
# 신규 부팅 직후 메모리 사용량
Ubuntu 22.04 Server: ~300 MB
Windows Server 2022: ~2,000 MB
→ 남은 1.7 GB가 앱·DB·컨테이너에 할당됨
3. 생태계: 모든 도구가 Linux 우선
Docker, Kubernetes, Nginx, PostgreSQL, Kafka, Redis — 인프라 주요 도구는 전부 Linux에서 먼저 만들어졌습니다. 문서, 이슈 트래커, 커뮤니티 지식이 Linux 기준으로 쌓여 있습니다.
Docker 최초 지원 OS: Linux (2013)
Windows 지원: 2016년 (3년 후)
macOS Docker: 내부적으로 Linux VM 위에서 실행됨
커널 vs 배포판
배포판이 여러 개인 이유 — 커널은 하나, 위에 올라가는 것이 다르다
온보딩 중에 선임이 "이 서버는 Amazon Linux야"라고 했는데 apt install을 치면 "command not found"가 뜹니다. Ubuntu에서 배운 명령어가 안 먹히는 이유는 커널과 배포판을 구분하지 않았기 때문입니다.
Linux 커널: Linus Torvalds가 1991년 만든 OS의 핵심 엔진입니다. 하드웨어 제어, 메모리 관리, 프로세스 스케줄링을 담당합니다. 모든 배포판이 이 커널을 공유합니다.
배포판(Distribution): 커널 위에 패키지 관리자, 기본 도구, 기본 설정을 묶어 배포하는 완성된 OS입니다.
| 배포판 | 패키지 관리자 | 주로 쓰이는 곳 |
|---|---|---|
| Ubuntu 22.04 LTS | apt | 개발, 학습, 클라우드 범용 |
| Amazon Linux 2023 | dnf | AWS EC2 기본값 |
| Rocky Linux / AlmaLinux | dnf | 엔터프라이즈 서버 |
| Alpine Linux | apk | Docker 컨테이너 경량 베이스 |
이 트랙은 Ubuntu 22.04 LTS 기준으로 진행합니다. 학습 자료가 가장 많고, 클라우드 인스턴스 기본값으로 자주 등장하며, 기업 서버에도 폭넓게 쓰입니다.
현재 배포판 확인하기
모든 Linux 배포판은 /etc/os-release 파일에 자신의 정보를 기록합니다. 어떤 서버에 처음 접속했을 때 가장 먼저 실행하는 명령어 중 하나입니다.
cat /etc/os-release
NAME="Ubuntu"
VERSION="22.04.3 LTS (Jammy Jellyfish)"
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
ID_LIKE=debian — Ubuntu는 Debian 계열이므로 apt를 사용한다는 뜻입니다.
cat /etc/os-release- NAME 필드에 배포판 이름이 나오는가? (예: "Ubuntu")
- VERSION 필드에 버전과 코드명이 나오는가?
- ID_LIKE 필드로 어떤 패키지 관리자를 써야 할지 알 수 있는가?
Linux에서는 명령어를 외울 필요가 없습니다. 모르는 옵션이 생기면 --help를 붙이면 됩니다.
ls --help | head -20
Usage: ls [OPTION]... [FILE]...
List information about the FILEs (the current directory by default).
...
-a, --all do not ignore entries starting with .
-l use a long listing format
-h, --human-readable with -l, print sizes like 1K 234M 2G
더 자세한 설명이 필요하면 man ls를 실행합니다. q를 누르면 종료됩니다.
ls --help | head -20- Usage 줄에 명령어 사용 형식이 나오는가?
- -l, -a, -h 옵션의 의미를 읽고 이해할 수 있는가?
- man ls를 실행해 q로 종료할 수 있는가?
트러블슈팅
상황: Ubuntu에서 배운 대로 apt install nginx를 입력했는데 "command not found" 에러가 납니다. Amazon Linux나 CentOS 서버에서 자주 만나는 상황입니다.
원인: apt는 Ubuntu/Debian 계열에서만 사용하는 패키지 관리자입니다. Amazon Linux 2023, CentOS, Rocky Linux는 dnf 또는 yum을 사용합니다. 배포판마다 패키지 관리자가 다르기 때문에, 서버에 접속하면 먼저 배포판을 확인하는 습관이 중요합니다.
진단 — 배포판을 먼저 확인하세요:
cat /etc/os-release | grep -E "^NAME|^ID="
NAME="Amazon Linux"
ID="amzn"
해결:
# Ubuntu/Debian 계열
sudo apt install nginx
# Amazon Linux 2023 / RHEL 8+ / Rocky Linux
sudo dnf install nginx
# CentOS 7 / Amazon Linux 2 (구버전)
sudo yum install nginx
# Alpine (컨테이너 환경)
apk add nginx
배포판을 확인한 후 해당 패키지 관리자를 사용하면 됩니다. dnf와 yum은 기본 사용법이 거의 동일합니다.
상황: 온라인 튜토리얼을 따라하다가 "command not found"가 떴습니다. 설치가 필요한 도구인지, 철자가 틀린 것인지, 아니면 다른 이름으로 있는 건지 알 수 없습니다.
원인: 세 가지 경우가 있습니다. ① 타이포 (ls를 sl로 입력 등) ② 해당 도구가 미설치 ③ 다른 배포판에서만 사용하는 명령어
진단 — 어느 경우인지 확인하세요:
# 1. 명령어 위치 확인 — 설치는 됐지만 경로 문제?
which nginx
type nginx
# 2. 패키지 이름 검색 — 설치 가능한 패키지가 있는가?
apt search nginx # Ubuntu
dnf search nginx # Amazon Linux/RHEL
해결:
# 타이포 → 올바른 명령어 입력
# 미설치 → apt/dnf install 로 설치
# 경로 문제 → which 결과의 전체 경로로 실행 (/usr/sbin/nginx)
명령어를 모를 때는 man <명령어> 또는 <명령어> --help로 사용법을 먼저 확인하는 습관을 들이세요.
상황: 새벽 모니터링 알림이 울렸습니다. 프로덕션 웹 서버 CPU가 95%를 넘겼습니다. 선임이 Slack으로 "EC2 들어가서 프로세스 확인해봐요"라고 합니다.
이 순간 Linux를 모르면 아무것도 할 수 없습니다. 반대로, 이 트랙을 마치면 다음 흐름이 자연스럽게 됩니다:
- AWS 콘솔에서 인스턴스 퍼블릭 IP 확인
ssh -i ~/.ssh/prod-key.pem ubuntu@<IP>— 서버 접속top또는htop— CPU 점유율 높은 프로세스 확인- 원인 파악 후 로그 확인
- Grafana 대시보드에서 CPU 추이 모니터링
"Linux를 배운다"는 것은 이 흐름을 혼자 해낼 수 있게 되는 것입니다.
다음 모듈에서는 실제 터미널에 접속하는 방법을 실습합니다. WSL(Windows), SSH(원격 서버), 클라우드 콘솔 — 세 가지 접속 방법을 직접 연결해봅니다.