Unix와 Linux의 역사: 1969년부터 현재까지

Unix와 Linux의 간략한 역사

Unix와 Linux의 역사는 소스 코드의 소유권이 누구에게 있는지를 둘러싼 긴 논쟁의 역사입니다. Unix는 1969년 Bell Labs에서 시작되었습니다. Linux는 1991년 Helsinki에서 시작되었으며, 초기 Unix의 코드를 전혀 공유하지 않습니다. 두 시스템 사이를 관통하는 것은 설계 철학과 공개된 인터페이스의 집합, 즉 파일, 프로세스, 파이프, 그리고 작은 프로그램들을 결합하는 셸입니다. 1956년의 반독점 합의로 인해 AT&T(American Telephone and Telegraph)가 소프트웨어를 직접 판매할 수 없게 되자, Bell Labs는 소스 코드를 저렴하게 라이선스하는 방식을 택했고, 이로 인해 1970년대에 Unix가 대학을 중심으로 널리 퍼지게 되었습니다. Unix는 AT&T 외부의 누구에게도 소유되지 않은 채 어디에나 존재하게 되었으며, 그 뒤를 이은 라이선스 분쟁들은 어떤 자유 Unix 계열 시스템이 여러분의 서버 랙에 자리 잡게 될지를 결정지었습니다.

1969년: 남는 PDP-7과 살아남은 아이디어

Bell Labs는 1969년 Multics 프로젝트에서 철수했습니다. Multics(multiplexed information and computing service)는 MIT 및 General Electric과 함께 구축한 대규모 시분할 시스템이었으나, Bell Labs는 이 프로젝트가 너무 방대하여 완수할 수 없다고 판단했습니다. Ken Thompson은 자신이 선호하는 아이디어만 남기고 나머지는 버린 뒤, 폐기된 PDP-7 미니컴퓨터에서 소규모 시분할 시스템을 작성했습니다. Dennis Ritchie가 그와 합류했습니다. Unix라는 이름은 Multics를 비꼬기 위한 농담이었습니다.

1970년, 이 시스템은 특허 부서 타이피스트들을 위해 Bell Labs가 구매한 PDP-11으로 이전되었습니다. 운영체제보다는 텍스트 처리 도구가 자금을 지원받기 더 쉬웠기 때문입니다. 해당 장비는 24 KB의 코어 메모리를 갖추고 있었으며, 시스템과 사용자 프로그램이 이를 나누어 사용했습니다. 이러한 자금 조달의 우연 덕분에 1971년 11월에 작성된 최초의 Unix 매뉴얼은 서식화된 문서 세트가 되었고, 이것이 오늘날에도 여전히 man 5 crontab을 입력하는 이유입니다. 해당 매뉴얼의 섹션 번호는 현재 여러분이 사용하는 매뉴얼의 섹션 번호와 같습니다.

두 가지 변화가 이 설계를 영구적으로 만들었습니다. 1973년 Version 3에서 파이프(pipes)가 도입되었습니다. Doug McIlroy가 수년간 프로그램을 끝에서 끝으로 연결할 수 있어야 한다고 주장해 왔기 때문이며, Thompson은 | 연산자를 추가하여 한 프로그램의 출력이 다음 프로그램의 입력이 되도록 했습니다. 그 후 1973년 후반, Version 4가 C 언어로 재작성되었습니다. 이식 가능한 언어로 작성된 운영체제는 원래 작성되지 않았던 하드웨어로도 이동할 수 있으며, 이것이 바로 Unix가 처음 시작된 모든 기기보다 더 오래 살아남은 이유입니다.

Unix가 확산된 이유: AT&T는 판매가 금지되었습니다

1956년의 동의 판결은 AT&T를 상대로 한 반독점 소송을 종결시켰습니다. AT&T는 전화 독점권을 유지하는 대신 통신 이외의 사업에는 진출하지 않겠다는 제한을 수용했습니다. 소프트웨어는 그 사업 중 하나였습니다. 따라서 대학들이 Unix를 요청했을 때, Bell Labs는 이를 제품으로 판매할 수 없었습니다. 대신 지원이나 보증 없이 명목상의 비용만 받고 소스 코드를 라이선스했습니다.

그 효과는 컸으며, 이는 AT&T가 의도한 바가 아니었습니다. 1975년에 출시된 Sixth Edition Unix는 수백 개의 컴퓨터 과학 학과에 전체 소스 코드와 함께 전달되었습니다. 뉴사우스웨일스 대학교의 John Lions는 해당 커널 소스를 줄 단위 해설과 함께 인쇄하여 강의에 활용했습니다. 한 세대가 실제 운영 체제를 읽으며 그 작동 원리를 배웠습니다.

그 후 라이선스 정책이 변경되었습니다. 1979년 Seventh Edition 라이선스는 강의에서 소스 코드를 사용하는 것을 금지했기에, Lions의 해설서는 복사본의 복사본 형태로 유통되었습니다. 이것이 전체 이야기의 양상입니다. Unix는 어디에나 존재하면서 동시에 자유롭지 못했기에, 누군가 개선을 할 때마다 그것은 타인의 독점적 코드에 대한 개선이 되었습니다.

Berkeley: 실제로 입력하는 Unix의 구성 요소

Ken Thompson은 1975년부터 1976년까지의 학기를 캘리포니아 대학교 버클리(UC Berkeley)에서 보냈으며, 그곳에 매우 활발한 Unix 그룹을 남겼습니다. 버클리의 컴퓨터 시스템 연구 그룹(CSRG)은 지역적인 개선 사항이 담긴 테이프를 배포했고, 이 테이프들이 BSD(Berkeley Software Distribution)가 되었습니다. Bill Joy는 초기 작업의 상당 부분을 수행했습니다. 1978년에는 1BSD를, 1979년에는 vi 편집기와 C shell을 포함한 2BSD를 발표했습니다.

C shell은 !!와 !$의 기원입니다. Bash는 이 문법을 계승했으며, 이것이 바로 40여 년이 지난 지금도 큰따옴표 안에서 느낌표를 입력할 때 bash 히스토리 확장이 여전히 사람들을 놀라게 하는 이유입니다.

이후 DARPA(미국 국방고등연구계획국)는 버클리에 자금을 지원하여 새로운 인터넷 프로토콜을 Unix에 도입하도록 했습니다. 1983년 8월에 출시된 4.2BSD는 TCP/IP(전송 제어 프로토콜/인터넷 프로토콜)와 소켓 애플리케이션 프로그래밍 인터페이스를 포함했습니다. 서버의 모든 네트워크 서비스가 여전히 socket(), bind(), listen(), accept()를 이 순서대로 호출하는 이유는 버클리가 1983년에 이 이름들을 선택했기 때문입니다.

한 가지 세부 사항이 다음 10년을 결정지었습니다. BSD 테이프는 완전한 시스템이 아니었습니다. 그것은 AT&T Unix에 대한 추가 기능 세트였으며, 합법적으로 실행하려면 유효한 AT&T 소스 라이선스가 필요했습니다. 버클리는 수년에 걸쳐 파일 단위로 AT&T의 코드를 자체 코드로 교체했습니다. 그 교체가 완전히 이루어졌는지 여부는 나중에 법정으로 가게 된 쟁점이었습니다.

1984년: 해체, 그리고 유닉스 전쟁

1984년 1월 1일 Bell System이 해체되면서 AT&T의 소프트웨어 사업 진출을 막았던 동의 판결도 함께 사라졌습니다. AT&T는 이제 Unix를 제품으로 판매할 수 있게 되었고 실제로 그렇게 했습니다. 상용 소스 라이선스 비용이 비싸지면서 Unix는 대학에서 학생들에게 저렴하게 제공하던 소프트웨어의 지위를 잃었습니다.

벤더들은 이미 Unix를 포크(fork)한 상태였습니다. 모든 워크스테이션 기업이 자사 하드웨어에 맞는 독자적인 Unix를 출시했기 때문에, 1980년대 후반에 이르면 한 시스템에서 작성된 프로그램은 다른 시스템으로 이식해야만 했습니다. 업계는 1988년 Open Software Foundation과 Unix International이라는 두 표준 진영으로 갈라졌고, 누가 진정한 Unix인지 논쟁하며 수년간 서로 호환되지 않는 시스템을 출시했습니다.

POSIX(portable operating system interface)는 이러한 혼란 속에서 탄생했습니다. 1988년 IEEE 1003.1이 발표되면서 Unix 계열 시스템이 갖추어야 할 요건이 명문화되었습니다. 여기에는 시스템 호출, 셸 동작, 표준 유틸리티, C 라이브러리 인터페이스가 포함됩니다. 표준은 사양일 뿐이며 라이선스의 적용을 받지 않기 때문에, 이는 생각보다 훨씬 중요한 의미를 갖습니다. 3년 후 한 학생이 이 문서들을 바탕으로 커널을 작성했습니다.

Minix와 그로 인해 남겨진 공백

Andrew Tanenbaum은 1987년 자신의 운영체제 교재를 위한 교육용 시스템으로 Minix를 발표했습니다. Minix는 소형 Unix 계열 시스템이었으며, 소스 코드가 교재와 함께 제공되었고 학생들이 실제로 보유한 저렴한 PC에서 구동되었습니다. Seventh Edition Unix와 달리 강의실에서 읽는 것이 법적으로 허용되었습니다.

Minix는 교재에서 설명 가능해야 했기에 의도적으로 소규모로 유지되었으며, Tanenbaum은 이를 프로덕션 시스템으로 만들 수 있는 패치들을 거부했습니다. 라이선스 또한 자유롭지 않았습니다. 교재를 구매해야 했으며, 수정된 Minix를 재배포하는 것은 사용자의 결정 사항이 아니었습니다. 따라서 1991년 당시 학생들은 작동하는 Unix 계열 커널을 읽을 수는 있었지만, 그 위에 지속 가능한 결과물을 구축할 수는 없었습니다.

GNU는 커널을 제외한 모든 것을 갖추고 있었습니다

Richard Stallman은 1983년 9월, 완전한 자유 Unix 계열 시스템을 목표로 하는 GNU 프로젝트를 발표했습니다. 1991년까지 GNU는 GCC 컴파일러, GNU C 라이브러리, 바이너리 유틸리티, 그리고 Brian Fox가 1989년에 작성하여 현재 여러분의 서버에서도 기본 셸로 사용되는 bash 등 커널을 둘러싼 대부분의 구성 요소를 완성했습니다. GNU 커널인 Hurd는 계속해서 완성이 지연되던 부분이었습니다.

GNU General Public License version 2는 1991년 6월에 발표되었습니다. 이 라이선스의 규칙은 간단합니다. 코드를 사용하고 변경할 수 있으며, 그 결과물을 배포할 경우 동일한 조건으로 소스 코드를 배포해야 합니다. 이 규칙은 두 섹션 뒤에 나올 이야기의 핵심이 됩니다.

1991년 8월: comp.os.minix에 올라온 게시물

1991년 8월 25일, 헬싱키의 한 학생이 유즈넷 그룹 comp.os.minix에 게시물을 올렸습니다.

Hello everybody out there using minix -

I'm doing a (free) operating system (just a hobby, won't be big and
professional like gnu) for 386(486) AT clones.

버전 0.01은 1991년 9월에 출시되었습니다. 이 버전은 Unix나 Minix의 코드를 공유하지 않았습니다. 이는 386 프로세서를 위한 새로운 커널이었으며, Minix 머신에서 개발되었고, POSIX 인터페이스를 기반으로 작성되었으며, 이미 존재하던 GNU 도구들과 결합되었습니다. 타넨바움(Tanenbaum)은 1992년 1월 토발즈(Torvalds)에게 모놀리식 커널은 구식 설계라고 말했습니다. 설계 측면에서 그의 지적은 타당했으나, 토발즈는 학생이 소유한 저렴한 컴퓨터 한 대에서 무엇이 잘 돌아가는가라는 다른 질문에 답하고 있었습니다.

1992년 2월, 버전 0.12는 GPL 라이선스로 재배포되었습니다. 토발즈는 이후 이를 자신의 가장 잘한 결정이라고 언급했습니다. 원래의 Linux 라이선스는 금전 거래를 금지했는데, 이는 이후 등장할 CD 판매 업체와 기술 지원 기업들의 활동을 가로막았을 것입니다. GPL은 상업적 이용을 허용하는 동시에, 배포되는 모든 변경 사항을 동일한 공유 트리로 다시 환원하도록 강제했습니다.

소송: 1992년 4월부터 1994년 2월까지

버클리는 1991년 6월에 Networking Release 2(Net/2)를 공개했습니다. 이는 AT&T에서 파생된 파일을 제거한, 거의 완전한 BSD 시스템이었습니다. 커널 파일 6개가 누락된 상태였습니다. 빌 졸리츠(Bill Jolitz)와 린 졸리츠(Lynne Jolitz)는 대체 파일을 작성하여 1992년 3월에 386BSD 0.0을, 1992년 7월 14일에 386BSD 0.1을 공개했습니다. 리눅스가 여전히 취미 수준의 커널이었던 당시에, 386용의 자유롭고 완전하며 성숙한 BSD가 탄생한 것입니다. Berkeley Software Design, Inc.(BSDi)는 지원이 포함된 상용 빌드인 BSD/386을 판매했으며, 1-800-ITS-UNIX라는 전화번호로 광고했습니다.

1992년 4월, 당시 유닉스를 소유하고 있던 AT&T의 자회사 Unix System Laboratories(USL)는 영업 비밀 침해와 유닉스 상표권 문제로 뉴저지 연방법원에 BSDi를 제소했습니다. 이후 소송은 캘리포니아 대학교 이사회를 피고로 추가하며 수정되었습니다. 1993년, 캘리포니아 대학교는 AT&T가 자체 라이선스에서 요구하는 출처 표기 없이 System V 내부에 버클리 코드를 포함해 배포했다며 맞소송을 제기했습니다.

법적 쟁점은 1993년에 무너지기 시작했습니다. 디킨슨 디베보이스(Dickinson Debevoise) 판사는 USL이 요청한 예비적 금지명령을 기각했습니다. AT&T가 수년간 저작권 고지 없이 32V 코드를 배포했기 때문에, 해당 코드에 대한 USL의 저작권 주장은 무효일 가능성이 높다고 판단했기 때문입니다. 1993년 중반 노벨(Novell)이 AT&T로부터 USL을 인수했고, 노벨 경영진은 분쟁을 끝내길 원했습니다. 사건은 1994년 2월에 합의되었습니다. 버클리 배포판의 약 18,000개 파일 중 3개가 제거되었고, 약 70개 파일에 USL 저작권 고지가 추가되었습니다.

버클리는 1994년 6월에 법적으로 문제가 없는 4.4BSD-Lite를 출시했습니다. 1993년에 분쟁 중이던 Net/2 코드를 기반으로 설립된 FreeBSD와 NetBSD는 새로운 기반 위에서 시스템을 재구축해야 했으며, 이 작업은 1994년 남은 기간 대부분을 차지했습니다. 리눅스 1.0은 그 재구축 과정의 한가운데인 1994년 3월에 출시되었습니다.

왜 BSD가 아닌 Linux가 서버 시장을 장악했는가?

소송이 대중적인 답변이며, 이는 사실의 일부입니다. 1992년 4월부터 1994년 2월 사이, 제품을 위해 자유 Unix를 선택해야 했던 사람들은 AT&T 변호사들의 실질적인 소송 위협과 아무도 소송을 걸 수 없는 핀란드 학생의 커널 사이에서 저울질해야 했습니다. 바로 그 시기가 웹이 등장하고 Slackware(1993년 7월), Debian(1993년 8월), 그리고 Red Hat과 SUSE 같은 최초의 Linux 배포판들이 나타난 시점과 정확히 일치합니다.

소송 외에도 네 가지 요소가 중요하게 작용했습니다.

• 하드웨어. Linux는 코드 첫 줄부터 범용 386 PC를 목표로 했으며, 바로 그 하드웨어가 저렴해졌습니다. 반면 BSD의 중심은 VAX와 워크스테이션이었고, 386 포팅은 두 명의 외부 인력이 진행하는 작업이었습니다.
• 라이선스. GPL은 수정된 커널을 배포하는 기업이 변경 사항을 공개하도록 강제하므로, 벤더들의 작업 결과가 하나의 트리로 다시 모였습니다. BSD 라이선스는 기업이 변경 사항을 비공개로 유지할 수 있게 했고, 실제로 기업들은 그렇게 했습니다.
• 개발 모델. Torvalds는 낯선 이들이 보낸 패치를 빠르게 병합하고 지속적으로 릴리스했습니다. 386BSD는 릴리스 속도가 너무 느려 1993년에 이미 NetBSD와 FreeBSD로, 1995년에는 OpenBSD로 두 번이나 포크(fork)되었습니다.
• 모멘텀. 개발자들은 다른 개발자들이 이미 모여 있는 곳으로 향하며, 드라이버는 사용자가 가장 많은 시스템을 위해 작성됩니다.

기술적인 측면에서 솔직해질 필요가 있습니다. 1994년 당시 BSD는 일관된 기반과 문서화된 역사, 그리고 Linux가 수년간 따라잡아야 했던 네트워킹 코드를 갖춘 더 완성된 시스템이었습니다. 1994년에 Linux가 더 나았기 때문에 선택한 사람은 아무도 없었습니다. 사람들이 Linux를 선택한 이유는 그것이 가용했고, 제약이 없었으며, 이미 보유한 하드웨어에서 실행되었고, 매주 개선되고 있었기 때문입니다.

BSD가 유지한 것과 현재의 실행 환경

BSD는 계속 발전해 왔습니다. 다만 기본 운영체제라는 지위를 잃었을 뿐입니다. 가장 확실한 증거는 여러분의 기기 안에 있습니다. OpenBSD 프로젝트는 1999년에 OpenSSH를 개발했고, 오늘날 배포되는 거의 모든 Linux 시스템의 SSH 서버로 사용되고 있습니다. 이것이 바로 배워둘 가치가 있는 SSH 키 관리 습관이 두 계열 모두에서 동일한 이유입니다.

Netflix는 FreeBSD 어플라이언스를 통해 비디오를 서비스합니다. Juniper 라우터의 운영체제인 Junos는 그 기반이 FreeBSD입니다. PlayStation 시스템 소프트웨어 역시 FreeBSD에서 파생되었습니다. Apple의 macOS와 iOS는 커널과 사용자 영역 전반에 걸쳐 BSD 코드를 포함하고 있습니다. BSD가 공유 서버 트리라는 지위를 잃게 만든 허용적 라이선스는, 역설적으로 BSD 코드가 그 존재를 명시하지 않는 수많은 하드웨어 내부에 탑재되게 만들었습니다.

오늘날 선택을 고민한다면, 그 질문은 역사적인 관점이 아니라 실용적인 관점에서 접근해야 합니다. 서버로서의 Linux와 FreeBSD 비교는 ZFS, jails, ports tree, 그리고 얼마나 많은 타사 소프트웨어가 Linux를 기본 전제로 하는지에 달려 있습니다. 서버로서의 FreeBSD 15는 박물관 전시품이 아니라 현재 유지보수되고 있는 시스템입니다. 그리고 Linux와 Windows Server의 비교는 별개의 질문이며, 그 답은 여러분이 사용하는 애플리케이션 스택에 따라 달라집니다.

오늘날 VPS에서 사용하는 1969년의 설계

이들 각각은 이를 사용하는 대부분의 사람보다 더 오래되었습니다.

• 파이프(pipe). who | wc -l은 1973년 Version 3 Unix에서 한 프로그램의 출력을 다른 프로그램의 입력으로 전달할 수 있게 되면서 로그인한 사용자를 계산합니다.
• 매뉴얼 섹션. man 1 ls과 man 5 crontab는 1971년 11월 매뉴얼의 번호 체계를 사용합니다.
• 파일 시스템 분할. /usr은 1971년 PDP-11의 루트 디스크가 가득 차서 개발자들이 파일을 두 번째 디스크 팩으로 옮기면서 존재하게 되었습니다. 이후 배포판들은 이 분할을 되돌렸습니다. Ubuntu 24.04나 Debian 13에서 ls -ld /bin를 실행하면 usr/bin로 향하는 심볼릭 링크를 확인할 수 있습니다.
• 소켓 호출. Berkeley는 1983년 4.2BSD를 위해 이를 작성했으며, 모든 네트워크 데몬이 여전히 이를 사용합니다.
• POSIX. 표준에 맞춰 작성된 #!/bin/sh 스크립트는 Linux, FreeBSD, macOS, Solaris에서 수정 없이 실행됩니다. 모든 운영체제가 해당 표준을 구현했기 때문입니다.

가상 사설 서버를 임대하여 로그인할 때, 여러분은 24 KB 메모리와 특허 부서를 지원하기 위해 설계된 인터페이스에 명령을 입력하고 있는 것입니다. 이 인터페이스가 살아남은 이유는 공개되고, 논의되고, 표준화되었으며, 원본 코드를 볼 권한이 없던 사람들에 의해 처음부터 다시 구현되었기 때문입니다.

FAQ

리눅스에는 원본 유닉스 코드가 포함되어 있습니까?

아니오. 리누스 토발즈는 1991년부터 AT&T 소스 코드가 아닌 POSIX 인터페이스를 목표로 커널을 처음부터 직접 작성했습니다. 유닉스의 유산은 파일, 프로세스, 파이프, 시스템 호출 이름과 같은 설계 방식과 공개된 인터페이스에 있습니다. 커널 주변의 GNU 도구들 또한 1983년부터 처음부터 새로 작성되었습니다. 이러한 독립성 덕분에 BSD 코드를 둘러싼 AT&T의 소송은 리눅스에 전혀 영향을 미치지 않았습니다.

AT&T의 BSD 소송은 언제였으며, 그 소송으로 BSD가 사라졌습니까?

유닉스를 소유했던 AT&T의 자회사 USL은 1992년 4월 BSDi를 고소했고, 이후 캘리포니아 대학교를 피고로 추가했습니다. 1993년 판사는 구형 32V 코드에 대한 저작권 주장이 무효일 가능성이 높다고 판단하여 예비 금지 명령을 거부했습니다. 노벨은 1993년 중반 USL을 인수하고 1994년 2월에 합의했는데, 약 18,000개의 파일 중 3개의 파일을 제거하고 약 70개의 파일에 새로운 저작권 고지를 추가하는 수준이었습니다. 이 소송으로 BSD가 사라지지는 않았습니다. 다만 전 세계가 자유 유닉스를 선택하던 2년 동안 BSD의 도입을 정체시켰습니다.

왜 BSD가 아닌 리눅스가 서버 시장을 장악했습니까?

법적 확실성이 한 가지 이유입니다. 1992년과 1993년 동안 리눅스는 소송에 휘말리지 않았지만 BSD는 소송 중이었습니다. 다른 이유로는 첫날부터 386 아키텍처를 목표로 삼았다는 점, GPL을 통해 벤더의 변경 사항을 단일 트리로 다시 통합했다는 점, 그리고 386BSD가 세 갈래로 분기되는 동안 기여자들의 관심을 유지할 만큼 병합 과정이 빨랐다는 점을 들 수 있습니다. 1994년 당시 BSD가 더 완성된 시스템이었기 때문에 기술적 우수성이 결정적인 요인은 아니었습니다.

오늘날에도 FreeBSD를 운영할 가치가 있습니까?

네, 구체적인 이유가 있습니다. 기본 시스템에 통합된 ZFS, 성숙한 격리 모델인 jails, 하나의 일관된 단위로 개발되는 기본 시스템, 그리고 정확하게 유지되는 문서화가 그 이유입니다. 대가는 호환성 작업입니다. 대부분의 서드 파티 서버 소프트웨어, 컨테이너 도구, 벤더 지원이 리눅스를 전제로 하기 때문입니다. 오래된 계보에 대한 충성심보다는, 스토리지와 네트워킹 작업이 그 대가를 상쇄할 만큼 가치가 있을 때 FreeBSD를 선택하십시오.