![[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 필드를 확인한다 — 그 다음 ID_LIKE 필드를 읽는다. ID_LIKE=debian이면 apt, ID_LIKE=rhel이면 dnf/yum 을 쓴다. 이 두 필드만 알면 처음 접속한 서버에서 패키지 관리자를 바로 선택할 수 있다
- VERSION_ID 숫자가 22.04처럼 짝수 연도.짝수 월이면 LTS(장기지원) 버전 — 서버 운영에 권장. 비 LTS(예: 23.10)는 9개월만 지원된다
- uname -a 출력 맨 앞이 커널 버전, 두 번째가 호스트명이다 — ID_LIKE가 debian인데 uname 출력에서 커널 버전이 5.x 이하이면 구버전 환경임을 의미하고, 최신 컨테이너 기능(cgroup v2 등)이 제한될 수 있다
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- 먼저 --help 출력 첫 줄(Usage)에서 명령어 형식을 읽는다 — 그 다음 대괄호([OPTION])는 선택, 점 세 개(...)는 반복 가능을 뜻한다. 이 규칙을 알면 모든 --help 출력을 같은 방식으로 읽을 수 있다
- -h(--human-readable)는 -l과 함께 써야만 효과가 있다 — ls -h 단독 실행 시 크기 단위가 바이트 그대로 출력된다. 옵션 조합 조건이 있는 경우 --help 설명에 'with -l' 같은 전제가 명시되어 있다
- man ls 에서 검색은 / + 키워드, 다음 결과는 n키다 — 옵션 설명이 --help보다 3배 이상 길기 때문에 검색 없이 스크롤만 하면 시간이 오래 걸린다. 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로 사용법을 먼저 확인하는 습관을 들이세요.
심화 — 커널은 하나, userspace는 여럿: 컨테이너로 이어지는 다리
심화: 컨테이너는 왜 '같은 커널, 다른 배포판'이 가능한가
앞에서 '커널은 하나, 배포판은 그 위의 userspace'라고 했습니다. 이 구분을 한 단계만 더 밀고 나가면, Docker 컨테이너가 왜 우분투 호스트 위에서 알파인·CentOS 컨테이너를 돌릴 수 있는지가 설명됩니다.
- 컨테이너는 가상머신이 아니다: 가상머신(VM)은 자기 커널을 따로 부팅합니다. 반면 컨테이너는 호스트의 커널을 공유하고, 그 위에 다른 userspace(배포판의 파일들)만 얹습니다. 그래서
alpine이미지를 우분투 호스트에서 실행하면 커널은 호스트 우분투의 것이고, 셸·라이브러리·패키지 관리자(apk)만 알파인의 것입니다. - 그래서 생기는 한계 ①: 커널을 공유하므로 컨테이너 안의 커널 버전은 항상 호스트와 같습니다. 컨테이너를 바꿔도 커널은 못 바꿉니다(호스트에서
uname -r, 컨테이너 안에서uname -r이 같게 나오는 이유). - 그래서 생기는 한계 ②: userspace가 다르므로 배포판 관습(패키지 매니저·경로·기본 셸)이 이미지마다 다릅니다. 알파인엔
apt도bash도 기본으로 없습니다. - 더 깊은 함정 — C 라이브러리까지 다르다: 알파인은 glibc가 아니라 musl libc를 씁니다. glibc로 컴파일한 바이너리를 알파인에 그냥 올리면 실행이 안 될 수 있습니다. '같은 리눅스'라도 userspace의 표준 C 라이브러리까지 다를 수 있다는 뜻입니다.
정리하면, '커널 하나 위에 userspace 여럿'이라는 그림을 이해하면 배포판 차이도, 컨테이너도 같은 원리의 다른 표현임을 알게 됩니다. 이 그림이 뒤에 나올 Docker로 넘어가는 다리가 됩니다.
상황: 처음으로 docker run -it alpine sh로 알파인 컨테이너에 들어가, 우분투에서 하던 대로 apt-get install을 치고 bash도 실행했는데 둘 다 command not found입니다. 분명 '리눅스'인데 아는 명령이 하나도 안 먹힙니다.
원인: 컨테이너는 호스트의 커널을 공유하지만 userspace(배포판)는 이미지가 정합니다. 알파인은 apt가 아니라 apk를, 기본 셸로 bash가 아니라 ash(=sh)를 씁니다. 우분투 습관이 안 통하는 것은 배포판 계열이 다르기 때문이고, 컨테이너 안에서 os-release를 보면 이유가 바로 드러납니다.
진단: 컨테이너 안에서 cat /etc/os-release로 배포판을 확인합니다(NAME="Alpine Linux", ID=alpine). which apk와 which apt로 무엇이 있는지 봅니다. 호스트에서 uname -r, 컨테이너 안에서 uname -r을 비교하면 커널 버전이 '같다'는 것도 확인됩니다 — 커널을 공유한다는 증거입니다.
해결: 알파인에선 apk를 씁니다 — apk add <패키지>로 설치하고, bash가 필요하면 apk add bash로 넣습니다. 애초에 익숙한 환경이 필요하면 ubuntu/debian 베이스 이미지를 고르는 것이 답입니다. 만약 glibc 전용 바이너리를 알파인에 올려 실행 오류가 난다면, 이는 musl libc 차이 때문이니 glibc 계열 이미지로 바꾸거나 정적(static) 빌드를 사용합니다.
상황: 새벽 모니터링 알림이 울렸습니다. 프로덕션 웹 서버 CPU가 95%를 넘겼습니다. 선임이 Slack으로 "EC2 들어가서 프로세스 확인해봐요"라고 합니다.
이 순간 Linux를 모르면 아무것도 할 수 없습니다. 반대로, 이 트랙을 마치면 다음 흐름이 자연스럽게 됩니다:
- AWS 콘솔에서 인스턴스 퍼블릭 IP 확인
ssh -i ~/.ssh/prod-key.pem ubuntu@<IP>— 서버 접속top또는htop— CPU 점유율 높은 프로세스 확인- 원인 파악 후 로그 확인
- Grafana 대시보드에서 CPU 추이 모니터링
"Linux를 배운다"는 것은 이 흐름을 혼자 해낼 수 있게 되는 것입니다.
명령어·단축키 빠른 참조
이 모듈에서 다룬 "낯선 서버 첫 접속·배포판 확인·도움말 찾기" 명령을 모았습니다. 배포판 계열부터 확인하는 습관이 핵심입니다.
| 명령어/단축키 | 용도 | 자주 쓰는 예 |
|---|---|---|
cat /etc/os-release | 배포판·버전 확인(첫 접속 시 1순위) | cat /etc/os-release | grep -E "^NAME|^ID=" |
uname -r / uname -a | 커널 버전 / 전체 시스템 정보 | 호스트·컨테이너에서 각각 실행해 커널 공유 확인 |
apt (Debian 계열) | Ubuntu/Debian 패키지 관리 | sudo apt install nginx / apt search nginx |
dnf / yum (RHEL 계열) | Amazon Linux·Rocky·RHEL 패키지 관리 | sudo dnf install nginx / dnf search nginx |
apk (Alpine) | 컨테이너 경량 이미지 패키지 관리 | apk add nginx / apk add bash |
<명령> --help | 옵션·사용법 빠른 확인 | ls --help | head -20 |
man <명령> | 상세 매뉴얼(/=검색, n=다음, q=종료) | man ls 후 /human 검색 |
which / type | 명령 설치 여부·경로 확인 | which nginx / type nginx |
ssh -i <키> <user>@<IP> | 원격 서버 접속 | ssh -i ~/.ssh/prod-key.pem ubuntu@<IP> |
관련 모듈로 더 깊이:
- 원격 리눅스 서버 안전 접속과 절대 무너지지 않는 기본 명령어 — 서버에 접속한 뒤 가장 먼저 익히는 터미널·셸 기본 조작
- 절대/상대 경로와 리눅스 디렉터리 구조 마스터 — 리눅스 디렉터리 구조 안에서 길을 찾는 첫 실전 기술
다음 모듈에서는 실제 터미널에 접속하는 방법을 실습합니다. WSL(Windows), SSH(원격 서버), 클라우드 콘솔 — 세 가지 접속 방법을 직접 연결해봅니다.