인프라를 공부하다 보면 Unix, BSD, POSIX, GNU, Linux 같은 용어가 한 번에 쏟아져 나와서 처음에는 전부 비슷한 말처럼 느껴졌다.
이번에 정리하면서 느낀 건, 이 개념들은 하나의 직선 계보라기보다 서로 다른 문제의식에서 출발한 흐름이 나중에 연결된 것들이라는 점이다.
이번 글에서는 그 관계를 내가 이해한 방식대로 차근차근 정리해보려고 한다.
1. Unix는 어디서 시작됐을까
Unix는 1969년경 Bell Labs에서 개발된 운영체제다.
처음엔 막연히 “오래된 시스템”, “어딘가 군사용 느낌이 있는 OS” 정도로만 알고 있었는데, 실제로는 연구자와 개발자가 프로그램을 만들고 실행하기 편한 범용 컴퓨팅 환경을 만들기 위한 흐름에서 나온 운영체제였다.
여기서 중요한 건 Unix가 단순히 옛날 OS가 아니라, 지금도 익숙한 많은 개념의 출발점이라는 점이다.
- 파일과 디렉터리 구조
- 사용자와 권한
- 프로세스 개념
- 셸 기반 작업 방식
- 작은 도구를 조합하는 철학
이런 것들은 지금 리눅스를 쓰든 macOS를 쓰든 계속 만나게 된다.
왜 Unix를 군사용으로 착각하기 쉬울까?
이건 Unix 이전/주변의 역사와 섞여서 기억되기 쉬운 것 같다.
Bell Labs가 참여했던 Multics 프로젝트는 ARPA 지원과 연결되어 있었고, 초기 인터넷의 전신인 ARPANET도 같은 맥락에서 언급되기 때문이다.
하지만 정리해보면 핵심은 이거다.
Unix 자체가 군사용 운영체제로 개발된 것은 아니다.
2. BSD는 Unix와 어떤 관계일까
BSD는 Berkeley Software Distribution의 약자다.
처음엔 “Unix랑 다른 무언가인가?” 싶었는데, 이해하고 나니 BSD는 Unix를 대체하기 위해 새로 만든 표준이 아니라, 기존 Unix를 Berkeley에서 발전시킨 계열에 가깝다.
BSD 계열은 네트워크 기술 발전에도 큰 영향을 줬고, macOS 역시 BSD 계열 기술의 영향을 많이 받았다.
그래서 BSD를 볼 때는 “Unix와 경쟁하는 별개 세계”라기보다, Unix 계열이 분화되며 발전한 중요한 가지로 이해하는 편이 더 자연스러웠다.
3. POSIX는 운영체제가 아니라 표준이다
이 부분은 처음에 가장 헷갈렸다.
이름만 보면 POSIX도 Unix나 Linux처럼 어떤 운영체제 이름 같았는데, 실제로는 호환성을 위한 규칙이다.
Unix 계열 OS들이 각자 다르게 발전하다 보니, 같은 프로그램도 시스템마다 조금씩 수정이 필요해졌다.
이 문제를 줄이기 위해 나온 것이 POSIX다.
내가 이해한 방식으로 아주 단순하게 말하면:
- Unix = 운영체제 계열
- POSIX = 그 계열들 사이의 공통 약속
즉, POSIX는 운영체제가 아니라 “이 정도는 공통으로 맞추자”는 인터페이스 표준이다.
4. Linux는 Unix가 아니라 Unix-like다
많이들 “Linux = Unix”처럼 말하지만, 엄밀하게는 다르다.
Linux는 Unix 코드를 그대로 가져온 것이 아니라, Unix의 구조와 철학을 참고해서 독립적으로 개발된 커널이다.
이 차이가 중요한 이유는, 역사적으로도 법적으로도 기술적으로도 Linux를 그냥 Unix라고 부르기엔 무리가 있기 때문이다.
그래서 보통은 Unix-like라는 표현을 쓴다.
정리하면서 오히려 더 명확해진 건, Linux는 “Unix의 후계자”라기보다 Unix가 남긴 설계 감각을 이어받아 성장한 별도의 흐름이라는 점이었다.
5. Linux는 운영체제 전체가 아니라 커널이다
이 부분도 실무나 인프라 공부를 하다 보면 반드시 짚고 넘어가야 할 구분 같다.
우리가 평소 “리눅스 서버”, “리눅스 설치”라고 말하지만, 엄밀하게 Linux는 커널 이름이다.
커널은 운영체제의 핵심으로, 하드웨어 자원을 관리하는 계층이다.
Linux 커널은 대표적으로 이런 일을 담당한다.
- CPU 관리
- 메모리 관리
- 프로세스 관리
- 파일 시스템 관리
- 네트워크 관리
- 장치 관리
즉, 커널은 하드웨어와 직접 맞닿아 있는 핵심 층이고, 사용자가 직접 쓰는 명령어/프로그램 전체와는 구분해야 한다.
6. GNU는 Linux와 왜 같이 언급될까
GNU는 “GNU’s Not Unix”의 약자다.
이름부터가 이미 Unix를 의식하고 있다.
GNU 프로젝트는 Unix처럼 사용할 수 있지만 자유롭게 수정·배포할 수 있는 소프트웨어 환경을 만들기 위해 시작됐다.
여기서 중요한 건 GNU가 Unix를 “이어받은 것”이 아니라, Unix와 호환되는 자유 소프트웨어들을 별도로 만든 프로젝트라는 점이다.
그리고 우리가 흔히 Linux 환경에서 사용하는 여러 도구가 GNU 쪽에서 왔다.
- bash
- ls
- cp
- mv
- rm
- gcc
여기서 내가 가장 중요하게 느낀 포인트는 이거다.
Linux 커널만으로는 일반 사용자가 익숙하게 쓰는 운영체제 환경이 완성되지 않는다.
여기에 GNU 같은 사용자 공간 도구들이 결합되면서 우리가 아는 Linux 시스템이 구성된다.
그래서 어떤 맥락에서는 GNU/Linux라고 부르는 이유도 이해가 됐다.
7. 배포판은 “커널 + 도구 + 정책”의 묶음이다
Ubuntu, Debian, Fedora 같은 이름은 Linux 자체의 다른 버전이라기보다,
Linux 커널과 여러 사용자 공간 소프트웨어를 묶어서 실제로 설치 가능한 형태로 만든 배포판이다.
예를 들어 배포판은 대략 이런 요소들의 조합이다.
- Linux 커널
- GNU 도구
- 라이브러리
- 패키지 관리자
- 서비스 관리자
- 기본 유틸리티와 설정 정책
그리고 배포판마다 달라질 수 있는 것도 꽤 많다.
- 패키지 관리자
- 업데이트 정책
- 안정성 지향 정도
- 서버 중심인지 데스크톱 중심인지
- 기본적으로 포함되는 프로그램
예를 들면:
- Ubuntu / Debian →
apt - Fedora / RHEL / Rocky →
dnf - Arch →
pacman - Alpine →
apk
그래서 “리눅스를 쓴다”는 말은 실제 현장에서는 보통 특정 배포판을 쓴다는 의미로 더 구체화된다.
8. 결국 큰 흐름은 어떻게 이어질까
여기까지 정리하고 나니, 이 주제는 “누가 누구를 계승했다” 식으로 외우면 오히려 더 헷갈린다는 생각이 들었다.
핵심은 서로 다른 흐름이 나중에 연결되었다는 것이다.
내 식으로 다시 요약하면:
- Unix는 중요한 출발점
- BSD는 Unix 계열의 발전 흐름 중 하나
- POSIX는 여러 Unix 계열 사이의 공통 규칙
- GNU는 자유 소프트웨어 도구 생태계
- Linux는 Unix 영향을 받아 독립 개발된 커널
- 배포판은 이 요소들을 실제 사용 가능한 운영체제로 묶은 결과물
이 관계를 한 번 머릿속에 정리해두면, 인프라를 공부하면서 만나는 운영체제 관련 용어들이 훨씬 덜 흐릿하게 느껴진다.
9. OS는 하드웨어와 분리된 추상 개념만은 아니다
운영체제를 공부하다 보면 “OS는 소프트웨어니까 어디서든 돌아가는 거 아닌가?”라는 감각이 들 수 있는데, 실제로는 그렇지 않다.
커널이 CPU, 메모리, 디스크, 네트워크 장치와 직접 맞닿아 있기 때문에 하드웨어 아키텍처와 장치 지원을 고려해야 한다.
대표적인 CPU 아키텍처는 다음과 같다.
- x86 / x86-64
- ARM / ARM64
- RISC-V
- PowerPC
이 관점에서 보면 OS 설치는 단순히 앱 하나 올리는 일이 아니라,
그 하드웨어에 맞는 커널과 시스템을 올리는 일에 가깝다.
Linux가 여러 아키텍처로 포팅되었다는 사실도 결국 커널이 다양한 하드웨어 환경에 맞게 적응해왔다는 의미로 읽혔다.
10. 왜 서버 Linux는 가볍게 느껴질까
이 부분도 흔히 오해하기 쉬운 지점이었다.
막연히 “Linux 커널이 가벼워서”라고 생각하기 쉬운데, 실제로는 운영체제가 기본적으로 무엇을 켜고 무엇을 제공하느냐의 차이가 더 크다.
데스크톱 OS는 보통 이런 것들을 기본으로 안고 간다.
- GUI
- 검색/인덱싱
- 폰트/애니메이션
- 오디오
- 클라우드 동기화
- 여러 백그라운드 서비스
- 사용자 반응성 중심의 설정
반면 서버 Linux는 GUI 없이, SSH와 필요한 서버 프로세스만으로 아주 최소 구성도 가능하다.
즉, “Linux가 가볍다”는 말은 커널 하나의 단순성이라기보다,
불필요한 요소를 덜어내고 필요한 역할 중심으로 구성하기 쉬운 환경이라는 쪽에 더 가깝게 이해됐다.
11. VM과 Container는 무엇이 다를까
인프라를 공부하다 보면 결국 가상화 개념을 만나게 된다.
이때 가장 중요한 구분은 VM은 자기 커널이 있고, 컨테이너는 호스트 커널을 공유한다는 점이다.
VM 구조
VM은 하이퍼바이저 위에서 가상 하드웨어를 받은 독립 시스템처럼 동작한다.
각 VM은 자기 운영체제와 자기 커널을 가진다.
Container 구조
컨테이너는 별도 커널이 없고, 호스트의 Linux 커널을 공유한다.
대신 namespace와 cgroup 같은 메커니즘으로 보이는 환경과 자원 사용량을 분리한다.
차이를 한 번 더 비교하면
이 차이를 이해하고 나니 왜 VM은 더 무겁고, 컨테이너는 더 빠르게 뜨고, 둘이 완전히 같은 대체재는 아닌지도 조금 더 명확해졌다.
12. QEMU, KVM, Hyper-V, WSL2도 같이 정리해보기
가상화 관련 용어도 처음엔 비슷하게 들리는데 역할이 다르다.
QEMU + KVM
- QEMU: 가상 하드웨어를 구성하고, 필요하면 다른 CPU 아키텍처 에뮬레이션도 가능
- KVM: Linux 커널이 제공하는 CPU 가상화 기능
같은 아키텍처에서는 KVM을 활용해 빠르게 돌릴 수 있고,
다른 아키텍처를 흉내내는 경우에는 에뮬레이션이 들어가므로 느려질 수 있다.
여기서 중요한 포인트는:
QEMU가 흉내내는 것은 커널이 아니라 하드웨어다.
Hyper-V와 WSL2
Windows 쪽에서는 Hyper-V가 대표적인 가상화 플랫폼이다.
그리고 WSL2는 하이퍼바이저 자체가 아니라, Hyper-V 기반 경량 VM 위에서 Linux 커널을 실행하는 환경으로 이해하는 게 맞다.
이 구조를 이해하면, “Windows에서 Linux를 쓴다”는 말이 실제로는 어떤 계층 위에서 가능한지도 더 잘 보인다.
마무리하며
이번 정리를 통해 가장 크게 느낀 건,
운영체제와 인프라 용어들은 비슷한 이름 때문에 헷갈리는 게 아니라, 서로 다른 층위의 개념이 한꺼번에 등장해서 헷갈리는 것이라는 점이었다.
특히 아래 구분은 앞으로도 계속 기준점으로 가져가면 좋겠다고 느꼈다.
- Unix: 운영체제 계열의 중요한 뿌리
- POSIX: 호환성을 위한 표준
- GNU: 사용자 공간 도구 생태계
- Linux: 커널
- 배포판: 커널과 도구들을 묶어 실제 사용 가능한 시스템으로 만든 결과물
- VM: 자기 커널을 가진 가상 머신
- Container: 호스트 커널을 공유하는 격리된 프로세스 환경
이번에 배운 점 / 다음에 더 볼 점
배운 점
- Linux를 운영체제 전체로 뭉뚱그리기보다 커널로 보는 관점이 중요했다.
- POSIX를 OS가 아니라 표준으로 이해하니 전체 구조가 훨씬 선명해졌다.
- VM과 컨테이너의 차이는 결국 “커널을 누구 것이냐”로 정리하면 기억하기 쉬웠다.
다음에 더 볼 점
- systemd와 init 시스템은 실제로 어떤 역할을 하는지
- 파일 시스템(ext4, XFS, APFS, NTFS)의 차이는 무엇인지
- Docker/Kubernetes가 컨테이너 위에서 어떤 문제를 해결하는지