리눅스 커널의 탄생

1991년 1월 5일, 핀란드 헬싱키의 대학생 리누스 토발즈는 새로 산 386 PC를 받아 들었습니다. 처음 몇 달은 DOS로 게임이나 하며 기계와 친해지는 시간이었습니다. 미닉스 디스크가 핀란드까지 배송되기를 기다려야 했으니까요. 미닉스가 도착한 뒤에야 본격적인 작업이 시작됐습니다.

목표는 단순했습니다. 집에서 학교 서버에 접속하는 것이었지요. 그런데 당시 쓰던 운영체제 미닉스(MINIX)가 영 마음에 들지 않았습니다. 잡 컨트롤도 없고, 메모리 관리도 어설프고, FPU 지원도 없었습니다.

그가 원한 건 거창한 게 아니었습니다. 그냥 자기 PC에서 편하게 쓸 수 있는 무언가였습니다.

에뮬레이터에서 커널로
리누스가 처음 만든 건 터미널 에뮬레이터였습니다.
당시 헬싱키 대학 서버에 원격으로 접속하려면 VT100이나 VT220 같은 물리적 더미 터미널(Dumb Terminal)이 필요했습니다. 자체 연산 능력 없이 키보드 입력을 서버로 전송하고 서버 응답을 화면에 출력하는 단순한 하드웨어였습니다. 리누스가 가진 건 달랐습니다. 자체 CPU와 메모리를 가진 완전한 컴퓨터, 386 PC였습니다.

목표는 하나였습니다. 대학 서버가 386 PC를 물리 터미널이라고 착각하게 만드는 것입니다. 그래서 리누스는 386 PC가 VT100처럼 동작하도록 흉내 내는 코드를 짰습니다. 키보드 입력을 모뎀으로 전송하고, 모뎀에서 들어온 신호를 화면에 뿌리는 터미널의 물리적 동작을 소프트웨어로 모방한 것입니다. 물리 하드웨어를 소프트웨어로 흉내 낸다 — 그래서 에뮬레이터입니다.

개발 환경은 미닉스였습니다. GNU C 컴파일러(GCC)로 코드를 작성하고 컴파일했습니다. 초기에는 작은 부트 플로피 디스크를 만들어 보호모드 환경을 실험하는 수준이었습니다. 중요한 점은, 이 코드가 운영체제의 도움 없이 하드웨어를 직접 제어하도록 설계됐다는 것입니다. 운영체제도 없이 하드웨어 위에서 단독으로 실행되는 프로그램 — 이를 베어메탈(Bare-metal) 실행이라고 합니다.

단, 미닉스는 버전 0.11이 나올 때까지 주 개발 환경으로 계속 쓰였습니다. 리누스 본인도 인정했습니다. "리눅스로 부팅하되, 개발은 MINIX에서 했다"고. 개발 환경과 실행 환경이 점진적으로 분리되어 갔을 뿐, 처음부터 완전히 단절된 게 아니었습니다.

리눅스가 386에서 태어난 건 우연이 아닙니다. 386은 당시 혁신적인 하드웨어였습니다.

보호모드(Protected Mode)가 핵심이었습니다. 보호모드에서는 메모리 보호와 특권 레벨 분리가 가능해, 커널과 사용자 공간을 분리하는 다중사용자 시스템을 구현할 수 있었습니다. 리누스는 386의 하드웨어 기능을 탐구하는 재미 자체가 개발 동기였다고 밝혔습니다. 실제로 초기에는 보호모드로 진입해 화면에 메시지를 출력하는 수준의 실험부터 시작했습니다.

페이징(Paging) 역시 결정적이었습니다. 386의 페이징 하드웨어를 이용해 가상 메모리를 구현하면, 각 프로세스에 독립된 메모리 공간을 줄 수 있습니다. 물리 메모리의 실제 위치를 숨기고 논리적 주소로 접근하게 하는 추상화 기술입니다.

미닉스 파일시스템을 참고해 구현한 아이노드(inode) 구조도 같은 맥락에 있습니다. 디스크의 물리 블록 위치를 숨기고 파일명과 번호로 접근하게 합니다. 페이징과 아이노드는 서로 다른 레이어에서 작동하지만, "간접 참조를 통한 추상화"라는 공통 원리를 공유합니다. 컴퓨터 과학의 격언처럼 — 모든 문제는 간접 참조 레이어를 하나 추가하면 해결됩니다.

터미널 에뮬레이터는 두 가지 작업을 동시에 처리해야 했습니다. 키보드 입력을 모뎀으로 보내는 작업과, 모뎀에서 들어온 데이터를 화면에 출력하는 작업이었습니다. 리누스는 두 개의 태스크가 각각 이 역할을 맡도록 구성했습니다.

단일 CPU에서 이를 해결하기 위해 리누스는 386 프로세서의 하드웨어 타이머를 이용했습니다. 타이머가 아주 짧은 주기마다 인터럽트(Interrupt)를 발생시키면, CPU가 강제로 현재 작업을 멈추고 다른 작업으로 상태를 전환(Context Switching)하게 만든 것입니다. 눈 깜짝할 사이에 두 작업이 번갈아 실행되면서 마치 동시에 돌아가는 것처럼 보였습니다.

물론 이 단계의 태스크 전환은 매우 원시적인 수준이었습니다. 하지만 터미널의 입출력 문제를 해결하기 위해 도입한 이 하드웨어 제어 코드가, 훗날 다중 작업을 가능하게 하는 시분할 스케줄러의 씨앗이 됐습니다.

처음부터 하드웨어를 직접 제어하던 이 에뮬레이터는 사실상 초보적인 커널 그 자체였습니다. 리누스는 대학 서버에서 받은 파일을 자신의 하드디스크에 저장하기 위해 디스크 드라이버와 미닉스 파일시스템 판독 코드를 계속 덧붙였습니다. 터미널 에뮬레이터가 나중에 커널로 독립한 게 아니라, 처음부터 하드웨어 위에서 단독 실행되던 프로그램이 기능 확장을 통해 점차 운영체제의 형태를 갖춰나간 것입니다.

그 무렵 리누스는 POSIX 표준 문서를 구하려 했습니다. 유저 레벨 프로그램은 직접 만들기 싫고, 기존 유닉스 소프트웨어를 그대로 쓰려면 호환 인터페이스가 필요했기 때문입니다. 문서를 구하지 못해 대학의 SunOS 매뉴얼과 미닉스 교재에서 시스템 콜을 역으로 파악해가며 POSIX 호환을 구현했습니다. 이 결정이 훗날 방대한 유닉스 소프트웨어 생태계를 흡수하는 열쇠가 됩니다.

그리고 1991년 8월 25일, 리누스는 유즈넷 뉴스그룹 comp.os.minix에 이런 글을 올렸습니다.
"나는 386(486) AT 클론을 위한 (무료) 운영체제를 만들고 있습니다. 그냥 취미로요. GNU처럼 크고 전문적인 게 되지는 않을 겁니다."
결정적인 계기는 그해 12월에 왔습니다. 모뎀 자동접속 프로그램을 실행하다가 실수로 미닉스 파티션을 날려버린 것입니다. 리누스 앞에는 선택지가 놓였습니다. 미닉스를 재설치할 것인가, 아니면 리눅스만으로 버텨볼 것인가. 그는 후자를 택했습니다. 그렇게 미닉스와의 결별이 이루어졌습니다.

리눅스가 미닉스와 다른 길을 간 이유
리눅스 커널이 공개되자 미닉스를 만든 앤드루 타넨바움 교수가 비판했습니다. 리눅스가 모놀리식 커널 구조를 택했다는 것이었습니다. 미닉스는 마이크로커널로 설계됐습니다. 파일시스템, 드라이버 등이 커널에 서비스를 요청하는 클라이언트-서버 방식이었습니다. 반면 리눅스는 모든 핵심 기능이 하나의 커널 공간에서 돌아갔습니다.

리누스는 물러서지 않았습니다. 그리고 역사는 리눅스의 손을 들어줬습니다.
마이크로커널은 구조적으로 우아했지만, 모듈 간 통신에서 발생하는 지연(오버헤드)이 컸습니다. 반면 리눅스의 모놀리식 커널은 모든 기능이 하나의 공간을 공유하여 성능을 극대화할 수 있었습니다. 당시 제한적인 386의 자원에서는 이론적 완벽함보다 성능이라는 실용성이 압도적으로 중요했던 것입니다.

공개 이후 리눅스는 커뮤니티와 함께 성장했습니다. POSIX 호환 덕분에 기존 유닉스 생태계의 방대한 소프트웨어 자산을 큰 수정 없이 흡수할 수 있었습니다.

디바이스 드라이버는 어차피 제품마다 달랐습니다. 제조사와 커뮤니티가 드라이버 생태계를 확장했고, 리눅스는 폭발적으로 다양한 하드웨어를 지원하게 됐습니다. 스케줄러나 메모리 관리 같은 핵심 서브시스템도 시간이 지나면서 커뮤니티 기여자들이 주도적으로 개선해 나갔습니다. 리누스의 역할은 방향을 잡고, 최종 머지를 결정하는 것이었습니다. 핵심 철학은 리누스가, 구체적 구현은 커뮤니티가 함께 만들어 갔습니다.

아이노드 → 페이징 → 가상머신 → 클라우드.

추상화 레이어는 계속 쌓여왔습니다. AWS의 S3는 실제 어느 데이터센터 어느 디스크인지 숨깁니다. 가상머신은 물리 서버를 숨깁니다. VPC는 실제 네트워크 토폴로지를 숨깁니다. 간접 참조를 통한 추상화라는 원리가 반도체에서 클라우드까지 관통하는 것입니다.

리누스가 386 보호모드를 탐구하며 짠 코드 한 줄은 그 긴 역사의 출발점이었습니다. 그것도 그냥 재미로.
리누스 토르발즈의 자서전 "리눅스, 그냥 재미로(Just for Fun)"와 1992년 첫 인터뷰, 그리고 리누스 본인의 리눅스 역사 서술에 이 이야기가 담겨 있습니다.