리눅스가 단순히 기술적으로 뛰어난 운영체제였다면 오늘날처럼 세상을 지배하지 못했을 것이다. 리눅스의 진짜 힘은 라이선스에서 나왔다. 누구나 소스 코드를 보고, 고치고, 배포할 수 있다는 자유가 전 세계 수십만 명의 개발자를 끌어들였고, 그 자유의 규칙을 둘러싼 철학적·법적 결정들이 오늘날 우분투·레드햇·SUSE 같은 배포판 생태계를 빚어냈다. 리눅스마스터 1급에서 라이선스와 배포판 계열은 단골 출제 영역이다. GPL과 BSD의 차이, 카피레프트의 의미, 그리고 RPM 계열과 데비안 계열이 패키지 관리에서 어떻게 갈라지는지를 정확히 이해해야 한다. 오늘은 자유 소프트웨어의 철학에서 시작해 주요 라이선스를 비교하고, 3대 배포판 계열의 계보를 따라간다.
흔히 "공짜 소프트웨어"와 "오픈소스"를 같은 말로 쓰지만, 역사적·철학적으로는 미묘하게 다른 두 운동이다.
자유 소프트웨어(Free Software) 운동은 1985년 리처드 스톨먼이 설립한 **자유 소프트웨어 재단(FSF)**에서 시작되었다. 여기서 "Free"는 "무료(공짜)"가 아니라 "자유(freedom)"를 뜻한다. 스톨먼은 이를 "free as in free speech, not as in free beer(공짜 맥주가 아니라 언론의 자유)"라는 유명한 문구로 설명했다. 자유 소프트웨어는 다음 네 가지 자유를 핵심으로 한다.
오픈소스(Open Source) 운동은 1998년 **오픈소스 이니셔티브(OSI)**가 주도했다. 에릭 레이먼드 등은 "자유"라는 이념적·정치적 색채가 기업의 참여를 막는다고 보고, 더 실용적이고 비즈니스 친화적인 용어인 "오픈소스"를 내세웠다. 기술적 우수성과 협업 모델을 강조한 것이다.
두 운동은 대상 코드는 거의 같지만 강조점이 다르다. 자유 소프트웨어는 윤리적 자유를, 오픈소스는 실용적 개발 방법론을 강조한다.
📚 유래/사례: 스톨먼이 자유 소프트웨어 운동을 시작한 계기는 사소한 사건이었다. MIT 시절 그는 제록스 프린터의 종이 걸림을 알려주는 기능을 추가하려 했지만, 제조사가 소스 코드 공개를 거부했다. "내 손에 있는 도구를 내가 고칠 수 없다"는 좌절이 평생의 운동으로 이어졌다. 작은 프린터 한 대가 거대한 자유 소프트웨어 운동의 씨앗이 된 셈이다.
라이선스를 이해하는 가장 중요한 개념은 **카피레프트(Copyleft)**다. 일반적인 저작권(copyright)이 "권리를 보유(reserved)"하여 복제·수정을 막는다면, 카피레프트는 저작권법을 역이용해 "자유를 강제로 보존"한다.
카피레프트의 핵심 규칙은 이것이다. "이 소프트웨어를 자유롭게 쓰고 고칠 수 있다. 단, 당신이 배포하는 파생물도 반드시 같은 자유를 보장해야 한다." 즉, 자유를 받은 사람은 그 자유를 다음 사람에게도 똑같이 넘겨주어야 한다. 이 전염성(viral) 때문에 카피레프트 라이선스로 만든 코드를 가져다 쓰면, 결과물도 같은 라이선스로 공개해야 하는 의무가 생긴다.
이 카피레프트를 구현한 대표 라이선스가 바로 **GPL(GNU General Public License)**이다.
💡 개념: "Copyleft"는 "Copyright"의 반대말 말장난이다. Right(오른쪽/권리)를 Left(왼쪽)로 뒤집어, 권리를 독점하는 대신 자유를 보존한다는 뜻을 담았다. FSF 로고에 "All rights reversed(모든 권리 역전)"라고 써 있는 것도 같은 농담이다.
라이선스는 크게 **카피레프트 계열(GPL)**과 **허용적(permissive) 계열(BSD, MIT, Apache)**로 나뉜다. 1급 시험에서는 이 둘의 차이, 특히 "파생물 공개 의무"의 유무를 정확히 구분하는 것이 핵심이다.
| 라이선스 | 계열 | 파생물 소스 공개 | 특징 |
|---|---|---|---|
선택지를 클릭하면 정답·해설이 펼쳐집니다.
문제 1
다음 중 카피레프트(Copyleft)와 GPL 라이선스에 대한 설명으로 옳은 것은?
문제 2
폐쇄 소스 상업용 프로그램이 어떤 라이브러리를 동적 링크하여 사용하면서도 자신의 소스 코드를 공개하지 않을 수 있게 해주는 라이선스는?
문제 3
레드햇 계열과 데비안 계열의 패키지 관리 도구 대응 관계로 옳은 것은?
문제 4
다음 배포판과 그 계열의 연결이 옳지 않은 것은?
문제 5
SUSE 계열 배포판에 대한 설명으로 옳은 것은?
문제 6
자유 소프트웨어(Free Software) 운동에서 말하는 "Free"의 의미와 네 가지 자유에 대한 설명으로 옳은 것은?
| GPL |
| 강한 카피레프트 |
| 의무(전체) |
| 링크된 코드까지 GPL 강제 |
| LGPL | 약한 카피레프트 | 라이브러리만 | 동적 링크 시 비공개 앱과 결합 가능 |
| BSD | 허용적 | 의무 없음 | 저작권 표시만 유지하면 자유 사용 |
| MIT | 허용적 | 의무 없음 | 가장 간결, 상업적 폐쇄 소스 가능 |
| Apache 2.0 | 허용적 | 의무 없음 | 특허 보호 조항 포함 |
GPL은 가장 강력한 카피레프트다. GPL 코드를 포함하거나 링크한 프로그램은 전체를 GPL로 공개해야 한다. 리눅스 커널이 GPLv2를 채택했기 때문에, 커널에 통합되는 드라이버 등은 원칙적으로 GPL을 따라야 한다.
**LGPL(Lesser GPL)**은 GPL을 완화한 "약한 카피레프트"다. 주로 라이브러리에 적용되며, 폐쇄 소스 프로그램이 LGPL 라이브러리를 동적 링크하여 사용하는 것을 허용한다. 단 LGPL 라이브러리 자체를 수정하면 그 부분은 공개해야 한다. glibc(C 표준 라이브러리)가 LGPL을 쓰는 이유는, 모든 프로그램이 glibc를 링크하는데 GPL을 강제하면 폐쇄 소스 프로그램을 리눅스에서 만들 수 없게 되기 때문이다.
BSD/MIT는 허용적 라이선스의 대표다. "저작권 표시만 유지하면 무엇이든 해도 좋다"는 입장으로, 수정본을 폐쇄 소스 상업 제품으로 만들어도 된다. 이 자유 덕분에 기업들이 선호한다. macOS의 커널 일부가 BSD에서 왔고, 수많은 상업 제품이 BSD/MIT 코드를 품고 있다.
Apache 2.0은 MIT와 비슷하게 허용적이지만, 명시적인 특허 라이선스 부여 조항이 있어 기여자의 특허 소송으로부터 사용자를 보호한다. 이 때문에 안드로이드, 쿠버네티스 등 대형 프로젝트가 채택했다.
# 시스템에 설치된 패키지의 라이선스 정보 확인
# RPM 계열
rpm -qi bash | grep License
# Debian 계열 - 패키지 저작권 문서 위치
ls /usr/share/doc/bash/copyright⚠️ 함정: 시험에서 "LGPL 라이브러리를 동적 링크한 폐쇄 소스 프로그램은 소스를 공개해야 하는가?"라는 함정이 자주 나온다. 답은 공개하지 않아도 된다이다. LGPL의 핵심이 바로 이 점이다. 반면 GPL 라이브러리를 링크하면 전체를 공개해야 한다. "동적 링크 + LGPL = 비공개 가능"을 기억하자.
🔍 더 깊이: GPL에는 버전이 있다. GPLv2(1991)와 GPLv3(2007)가 대표적이다. GPLv3는 "Tivoization(하드웨어로 GPL 소프트웨어 수정을 막는 행위)"을 금지하고 특허 조항을 강화했다. 리누스 토르발스는 GPLv3의 일부 조항에 반대해 리눅스 커널을 여전히 GPLv2에 묶어두고 있다. 이는 리눅스 커널의 중요한 라이선스 특징이다.
Day 1에서 "리눅스는 커널만을 뜻한다"고 배웠다. 그렇다면 우리가 설치하는 우분투, CentOS는 무엇일까? 바로 **배포판(distribution, distro)**이다. 배포판은 다음을 하나로 묶은 완제품이다.
배포판마다 철학과 대상이 다르다. 안정성을 최우선하는 서버용, 최신 기술을 빠르게 도입하는 데스크톱용, 학습용, 보안 특화 등 수백 개가 존재한다. 하지만 1급 시험에서 중요한 것은 **계열(family)**이다. 대부분의 배포판은 세 개의 큰 뿌리에서 갈라져 나왔고, 같은 계열은 패키지 관리 방식과 디렉터리 구조가 비슷하다.
레드햇 계열은 기업 서버 시장의 강자다. 1994년 설립된 레드햇사가 만든 RHEL(Red Hat Enterprise Linux)을 중심으로 한다. 이 계열의 가장 큰 특징은 RPM(Red Hat Package Manager) 패키지 형식과 그 의존성을 자동 해결하는 YUM/DNF 도구다.
| 배포판 | 위치 | 설명 |
|---|---|---|
| RHEL | 상용 | 레드햇의 유료 엔터프라이즈 제품, 기술 지원 포함 |
| CentOS | 무료 클론 | RHEL 소스 기반 무료판(현재 CentOS Stream으로 전환) |
| Fedora | 선행 개발 | 최신 기술 테스트베드, RHEL의 상류(upstream) |
| Rocky/AlmaLinux | 무료 클론 | CentOS의 노선 변경 후 등장한 RHEL 호환 클론 |
| Amazon Linux | 클라우드 | AWS 최적화 RHEL 계열 |
패키지 관리는 두 단계로 이루어진다. 저수준 도구 rpm은 개별 .rpm 파일을 설치하지만 의존성을 자동 해결하지 못한다. 고수준 도구 yum(구버전)과 dnf(신버전)는 저장소(repository)에서 패키지와 그 의존성을 함께 내려받아 자동 설치한다.
# 저수준 - 개별 패키지 파일 설치(의존성 수동)
rpm -ivh package.rpm # install, verbose, hash
rpm -qa # 설치된 모든 패키지 조회
rpm -e package # 패키지 제거
# 고수준 - 의존성 자동 해결(저장소 기반)
dnf install httpd # 또는 yum install httpd
dnf update # 전체 업데이트
dnf remove httpd
dnf search keyword📚 유래/사례: "Fedora"라는 이름은 레드햇 로고의 빨간 중절모(fedora hat)에서 왔다. Fedora는 레드햇의 실험실 역할을 한다. 여기서 검증된 최신 기술이 안정화되면 RHEL에 들어간다. 즉 Fedora → RHEL → CentOS(클론)로 기술이 흘러내려가는 구조다.
데비안 계열은 커뮤니티 중심의 자유 소프트웨어 정신을 가장 충실히 따르는 계열이다. 1993년 이안 머독(Ian Murdock)이 시작했으며, 이름은 그와 당시 여자친구 데브라(Debra)의 이름을 합친 것이다(Deb + Ian). 이 계열은 DEB(.deb) 패키지 형식과 APT(Advanced Package Tool) 도구를 사용한다.
| 배포판 | 위치 | 설명 |
|---|---|---|
| Debian | 기반 | 안정성 극대화, 모든 데비안 계열의 뿌리 |
| Ubuntu | 데스크톱/서버 | 캐노니컬사가 만든 가장 대중적인 배포판 |
| Linux Mint | 데스크톱 | 우분투 기반, 사용 편의성 강조 |
| Kali Linux | 보안 | 데비안 기반 모의 침투 테스트 특화 |
| Raspberry Pi OS | 임베디드 | 라즈베리파이용 데비안 기반 |
데비안 계열도 저수준/고수준 도구가 나뉜다. 저수준 dpkg는 개별 .deb 파일을 다루지만 의존성을 자동 해결하지 못한다. 고수준 apt(또는 apt-get)는 저장소에서 의존성까지 자동으로 처리한다.
# 저수준 - 개별 패키지 파일(의존성 수동)
dpkg -i package.deb # 설치
dpkg -l # 설치된 패키지 목록
dpkg -r package # 제거
dpkg -L package # 패키지가 설치한 파일 목록
# 고수준 - 의존성 자동 해결(저장소 기반)
apt update # 저장소 패키지 목록 갱신
apt install nginx # 설치
apt upgrade # 업그레이드
apt remove nginx # 제거💡 개념: RPM 계열과 DEB 계열의 대응 관계를 표로 외워두면 시험에 매우 유용하다. 저수준:
rpm↔dpkg. 고수준(의존성 자동):dnf/yum↔apt/apt-get. 패키지 확장자:.rpm↔.deb. 이 대응을 묻는 문제가 거의 매 회차 출제된다.
SUSE 계열은 1992년 독일에서 시작된 유럽 중심의 배포판이다. 흥미롭게도 SUSE는 RPM 패키지를 사용하므로 레드햇 계열과 패키지 형식을 공유하지만, 독자적인 시스템 관리 도구 **YaST(Yet another Setup Tool)**와 패키지 관리자 zypper를 쓴다는 점이 다르다.
| 배포판 | 위치 | 설명 |
|---|---|---|
| SLES | 상용 | SUSE Linux Enterprise Server, 기업용 |
| openSUSE | 무료 | 커뮤니티판(Leap: 안정, Tumbleweed: 롤링릴리스) |
zypper install apache2 # SUSE의 패키지 설치
zypper update # 업데이트
yast # 텍스트/GUI 통합 시스템 설정 도구🔍 더 깊이: SUSE는 RPM을 쓰지만 레드햇 계열로 분류하지 않고 독립 계열로 보는 것이 일반적이다. 패키지 "형식"(.rpm)과 패키지 "관리 도구"(zypper vs dnf), 그리고 시스템 관리 철학(YaST)이 모두 다르기 때문이다. 시험에서 "SUSE는 어떤 패키지 형식을 쓰는가"라는 함정 문제가 나오면 답은 RPM임에 주의하자. 계열은 다르지만 형식은 RPM이다.
왜 저수준 도구(rpm, dpkg)와 고수준 도구(dnf, apt)가 따로 있을까? 핵심은 의존성(dependency) 때문이다. 프로그램 A가 라이브러리 B를 필요로 하고, B는 다시 C를 필요로 하는 식으로 의존성이 사슬처럼 얽혀 있다. 저수준 도구로 패키지를 하나씩 설치하면, 필요한 의존성을 사람이 일일이 찾아 순서대로 설치해야 하는 "의존성 지옥(dependency hell)"에 빠진다.
고수준 도구는 **저장소(repository)**라는 중앙 패키지 창고와 메타데이터를 활용해 이 문제를 해결한다. apt install nginx를 입력하면 nginx가 필요로 하는 모든 라이브러리를 자동으로 찾아 함께 설치한다. 이것이 현대 리눅스 배포판이 사용하기 편한 핵심 이유다.
⚠️ 함정:
rpm -ivh로 패키지를 설치하다 "Failed dependencies" 오류가 나는 것은 정상이다. 저수준 도구는 의존성을 해결하지 못하기 때문이다. 이때--nodeps옵션으로 강제 설치하면 프로그램이 깨질 수 있으므로, 의존성이 필요하면 반드시dnf/yum같은 고수준 도구를 써야 한다는 점이 출제 포인트다.
오늘은 리눅스를 자유롭게 만든 라이선스와, 그로 인해 형성된 배포판 생태계를 살펴봤다. 자유 소프트웨어 운동(FSF)과 오픈소스 운동(OSI)은 같은 코드를 두고 다른 철학을 강조하며, GPL의 카피레프트는 자유를 강제로 전파하는 반면 BSD/MIT는 허용적이라 상업적 폐쇄 소스도 허용한다. LGPL은 그 사이의 절충이다. 배포판은 레드햇(RPM/dnf), 데비안(DEB/apt), SUSE(RPM/zypper) 세 계열로 크게 갈리며, 각 계열은 저수준·고수준 패키지 도구가 짝을 이룬다. 다음 시간에는 실제로 리눅스를 설치할 때 마주치는 파티션 설계, 부트로더 GRUB2, 그리고 전원을 켜는 순간부터 시스템이 살아나는 부팅 과정을 다룬다.