유닉스 운영체제는 1969년 벨 연구소의 다락방에서 만들어진 이래로 유닉스의 창시자들이 상상하지 못한 정도로 뻗어나갔다. 유닉스는 많은 혁신적인 소프트웨어가 개발되도록 했고, 무수한 프로그래머에게 영향을 주었으며, 컴퓨터 기술의 전체 궤도를 바꿔놓았다.

주변 사람에게 듣던 대로 너무 재밌게 읽었다. 어쩌면 당연하게도 UNIX를 직접 사용해 본 적은 없지만, 개발을 하고 서버를 운영하면서 소위 UNIX 계열 OS를 계속 쓰고 있었고 그러면서 UNIX라는 말은 사용하고 있지만, 자세히 알고 있지는 못했다. 그런데도 Linux에서, macOS에서 코딩을 하면서 배운 많은 개념이 UNIX에서 유래되었다는 것을 알고는 있었지만, 자세히 알지는 못했다.

책의 제목대로 UNIX의 탄생과 발전 과정을 옆에서 보는 것 같았다. 켄 톰프슨이나 데니스 리치처럼 유명하진 않고 본인은 겸손하게 얘기하고 있지만, 저자인 브라이언 커니핸은 켄과 데니스 혹은 그 외 다른 중요한 사람 가까이서 UNIX의 탄생을 처음부터 보고 함께 한 사람이다. 이런 사람이 글재주까지 있어서 그 과정을 이렇게 생생하기 전해준다는 것은 축복이 아닐 수 없다.

이 뒤에는 기록을 위해서 인용한 사건들이 있는데 이러한 부분이 책을 읽는 재미가 반감될 것 같다면 이 후기를 그만 읽어도 좋다.

1968년경 벨 연구소의 입장에서는 멀틱스가 소수의 사용자에게는 좋은 컴퓨팅 환경일지 몰라도, 연구소 전체를 위한 컴퓨팅 서비스를 제공할 정보 유틸리티가 되지는 못하리라는 것이 분명해졌다. 너무 비쌌기 때문이다. 그리하여 벨 연구소는 1969년 4월에 프로젝트에서 발을 뺐고 MIT와 GE가 개발을 계속해나갔다.

"어느 순간 저는 3주 더 작업하면 운영체제가 만들어지리라는 걸 깨달았습니다." 그는 세 가지 프로그램을 한 주에 하나씩 개발해야 했다. 코드를 작성하기 위한 편집기, 코드를 PDP-7에서 실행 가능한 기계어로 변환하기 위한 어셈블러, 마지막으로 커널 오버레이(kernel overlay)였다. 그리고 켄은 커널 오버레이를 운영체제라고 불렀다.

"한 주, 한 주, 한 주, 그리고 유닉스가 만들어졌습니다." 분명 이것이 진정한 소프트웨어 생산성이다.

형체가 있는 유닉스 시스템의 첫 번째 버전은 1969년 중후반에 작동하고 있었으므로 그때를 유닉스가 탄생한 시기라고 말하는 것이 타당해 보인다.

벨 연구소는 멀틱스를 MIT, GE와 함께 만들다가 발을 뺐고 그때의 경험을 참가자들에게 도움이 되었다. 그리고 UNIX를 만들어졌다.

시스템에 이름이 없었기에 (내 기억이 맞는다면) 내가 라틴어 어근에 기반을 두고 멀틱스가 '모든 기능을 많이'' 제공하는 반면, 새로운 시스템은 어떤 기능을 기껏해야 하나 제공하므로 'UNICS'라고 불러야 된다고 했는데, 이는 'multi'를 'uni'로 바꾼 말장난이었다.
...
다른 버전은 피터 노이만이 'UNiplexed Information and Computing Service'를 의미하는 UNICS라는 이름을 생각해냈다는 것이다.
...
어쨌든 UNICS는 어떤 이유에서인지 Unix로 변형됐는데, 확실히 훨씬 더 나은 생각이었다.

멀틱스와 달리 사이드 프로젝트처럼 만들어진 UNIX가 오랜 세월이 지나서 정확히 이름이 왜 UNIX가 되었는지 명확하지 않은 것은 자연스러울 수도 있다. 책에서 느껴지는 벨 연구소를 생각하면 여러 농담을 하면서 다양한 추측이 나오지 않았을까 싶기도 하다.

유닉스가 프로그래머를 위해 일찌감치 기여한 것 중 하나는 온라인 매뉴얼이다. 유닉스 프로그래머 매뉴얼은 간결한 스타일로 모든 명령어, 라이브러리 함수, 파일 포맷 등에 관해 각각의 정의와 사용법을 간단히 설명한다.

지금도 우리는 문서를 만드는 데 어려움을 겪는데 UNIX라는 놀라운 OS를 만들면서도 문서 작성에 많은 힘을 썼다는 것도 나한테는 흥미로운 부분이었다.

C 언어가 등장하면서 운영체제 전체를 고수준 언어로 작성할 수 있게 됐다. 1973년에는 유닉스를 원래 어셈블리어 형태에서 C 언어로 바꿔서 작성하는 작업이 완료됐다.
...
C 프로그래밍 언어는 1970년대 초에 만들어졌고 멀틱스 구현용 고수준 언어를 다뤘던 데니스의 경험을 바탕으로 개발됐다. C 언어는 당시 컴퓨터의 성능 제약을 감안하여 다른 고수준 언어보다 크기를 훨씬 줄인 언어였다. 정말로 당시에는 복잡한 언어를 위한 복잡한 컴파일러를 지원할 만한 메모리나 처리 능력이 충분하지 않았기 때문이다. 그러한 환경 때문에 자원을 최소한으로 사용해야만 했는데, 켄과 데니스가 선호하는 간단하고 균일한 메커니즘은 이 원칙에 잘 부합했다.
...
시스템 코드 대부분이 C 언어로 작성됐으므로 운영체제를 이식하는 작업에는 C 컴파일러를 이식하는 것 이외에 많은 일이 필요하지 않았다.

C++는 비야네 스트롭스트룹이 케임브리지 대학교에서 박사 학위를 막 받고 1127 센터에 합류했던 1979년에 시작됐다. 비야네는 시뮬레이션과 운영체제에 관심이 있었지만 기존 언어는 그의 요구사항을 제대로 충족시키지 못했다. 그래서 그는 가장 근접한 대상인 시뮬라Simula에서 몇몇 좋은 아이디어를 가져와서 C와 합쳤다. 객체 지향 프로그래밍의 아이디어를 C의 효율성 및 표현력과 조합해서 만든 결과물은 '클래스가 있는 CC with classes'라고 불렸고, 1980년에 완성됐다.

Newsqueak에서 나온 아이디어는 궁극적으로 플랜 9에 사용된 동시성 언어인 Limbo와 Alef에 적용됐고, 10여 년 후에는 Go 언어에 녹아들었는데, Go는 2008년에 구글에서 일하던 롭 파이크, 켄 톰프슨, 로버트 그리즈머가 만든 것이다.

UNIX를 시작으로 해서 지금 알고 있는 프로그래밍 언어들이 탄생하는 과정을 보는 것도 재밌었다.

유닉스에서 파일은 그저 일련의 바이트다. 파일 내용의 구조나 조직은 그 파일을 처리하는 프로그램에 의해서만 결정되고, 파일 시스템 자체는 파일 내에 뭐가 있는지 신경 쓰지 않는다. 이 말은 어떤 프로그램이든 어떤 파일이라도 읽거나 쓸 수 있음을 의미한다.

유닉스에서 가장 인상적인 발명품 하나를 꼽으라면 아마도 파이프(pipe)일 것이다.

와일드카드가 셸에 의해 해석되기는 하지만, PDP-7의 주기억장치가 너무 제한돼 있었기에 파일명 와일드카드를 처음으로 구현한 것은 셸이 호출하는 glob(global을 의미)이라는 별개의 프로그램이었고, 패턴에서 파일명의 확장된 목록을 만들어내는 것을 'globbing'이라고 불렀다. 오늘날 파이썬을 포함한 여러 프로그래밍 언어의 라이브러리에 glob이라는 이름이 남아 있다.

단지 재컴파일되지 않았을 뿐인 프로그램을 디버깅하려고 애쓴 바 있었다. 스튜어트는 우아한 아이디어를 생각해냈다. 프로그램의 조각들이 서로 어떻게 의존하는지 기술하는 명세 언어였다. 그가 Make(메이크)라고 부른 이 프로그램은 명세, 즉 makefile(메이크파일)을 분석하고 파일들이 변경된 시간 정보를 이용해서 모든 것을 최신으로 유지하는 데 필요한 최소한의 재컴파일을 수행했다. Make가 처음으로 구현된 것은 1976년이었다.

우리는 Awk라는 언어를 설계했다. Awk 언어 자체에 관해 설명한 문서에서도 이야기했지만, 개발자의 이름을 따서(Aho, Weinberger, Kernighan) 언어 이름을 지은 것은 어느 정도 상상력이 부족함을 나타낸다. 지금은 우리가 'awkward'와 연관된 어원에 대해 생각했었는지, Awk라는 이름이 냉소적인 어감을 줘서 어울린다고 생각했는지 잘 기억이 나지 않지만, 어쨌든 그 이름으로 굳어졌다.

플랜 9은 시대를 뛰어넘은 중요한 한 가지 기술을 세상에 기여했다. 바로 유니코드Unicode의 UTF-8 인코딩이다.
켄 톰프슨과 롭 파이크는 플랜 9 개발 과정에서 이 문제를 해결하려고 애썼다. 플랜 9에서 아스키가 아닌 유니코드를 운영체제 코드 전반에 걸쳐 사용하기로 결심했기 때문이다. 1992년 8월에 그들은 UTF-8이라는 기발한 유니코드의 가변 길이 인코딩 방식을 만들어냈다.

가장 재밌었던 부분은 지금도 내가 쓰는 프로그램이나 용어의 탄생과정을 볼 때였다. 당연한 듯 OS에 포함된 프로그램이라고 개발하면서 사용하거나 glob처럼 약속된 용어처럼 사용하던 것들이 만들어지는 과정을 보고 있으니 너무 재미있었다. 특히 Awk가 만든 사람들의 이름 첫 글자를 딴 것이라고는 생각해 본 적이 없었다.

Lex의 첫 번째 버전를 만든 직후, 여름 인턴으로 들어온 에릭 슈미트Eric Schmidt가 재작성했습니다.
더글러스 매클로이는 이렇게 말했다. "무엇이든 반복적으로 해야만 하는 일이 생겼다면, 자동화하기에 적합한 때가 된 것이다."

켄 톰프슨은 1975년과 1976년에 UC 버클리에서 안식년을 보내면서 운영체제에 관한 과목을 가르쳤다. 당시에 대학원생이었던 빌 조이(그림 6-2)는 UC 버클리에서 사용하던 유닉스를 수정해서 그만의 프로그램 몇 개를 추가했다. 그중에는 아직도 가장 인기 있는 유닉스 편집기 중 하나인 vi 텍스트 편집기와 C 셸인 csh가 있었다. 빌은 나중에 유닉스용 TCP/IP 네트워킹 인터페이스를 설계했는데, 이 인터페이스는 지금도 이용된다

유명한 사람들이 그 역사 속에서 자연스럽게 등장하는 것도 이 책의 재미있는 부분이었다. 여름 인턴인 에릭 슈미트라니... ㅎㅎ

유닉스가 비로소 날개를 펴고 연구소라는 둥지를 벗어난 것은 제7판부터였습니다. 제7판은 이식성 있는 첫 버전이었고, 무수히 다양한 하드웨어로 폭발적으로 퍼져나간 후계의 마지막 공통 조상이었습니다. 따라서 제7판의 역사는 모든 유닉스 시스템의 공통 유산의 일부입니다.

라이선스를 취득한 단체 중 가장 적극적으로 활동한 곳은 캘리포니아 대학교 버클리(이하, UC 버클리)였다. UC 버클리에서는 여러 명의 대학원생이 시스템 코드에 중요하게 이바지했고, 결국 버클리 소프트웨어 배포판(Berkeley Software Distribution(BSD))이 만들어졌다. BSD는 원조 연구용 유닉스(Research Unix)에서 발전한 두 가지 주요 갈래 중 하나다.

캘리포니아 대학교 버클리의 컴퓨터 시스템 연구 그룹(Computer Systems Research Group)에 있던 빌 조이와 그의 동료들은 32/V에 가상 메모리를 사용하기 위한 코드를 추가한 버전을 만들었다. 이 버전은 곧 32/V를 대체했고, 사용자들이 PDP-11에 흥미를 잃으면서 VAX는 사용자 대부분이 사용하는 주된 유닉스 컴퓨터가 됐다. 버클리에서 개발한 버전은 버클리 소프트웨어 배포판(BSD)이라는 이름의 패키지로 출하됐고, 유닉스 라이선스 사용자에게 배포됐다. BSD에서 유래한 운영체제는 아직 활발히 이용되는데, FreeBSD, OpenBSD, NetBSD 같은 변종이 계속 개발되고 있다. 맥OS의 핵심인 애플의 다윈(Darwin) 개발에 사용된 NeXTSTEP도 BSD에서 파생된 운영체제다.

켄과 데니스가 유닉스의 성공을 예측하지 못한 것처럼, 토르발스는 그가 취미로 만든 시스템의 놀라운 미래를 예측하지 못했다. 몇천 행짜리 코드로 시작한 것이 지금은 2천만 행이 훨씬 넘는 대규모 시스템이 됐다.

1980년대에 마이크로소프트가 제닉스Xenix라는 이름의 유닉스 버전을 배포했던 것이다. ... 마이크로소프트가 자체 개발한 운영체제인 MS-DOS 대신 제닉스 사업화를 더 강하게 추진하고, AT&T가 실제로 그랬던 것보다 협상하기 더 쉬운 상대였다면 세상이 어떻게 달라졌을지 궁금해할 사람도 있을 것이다.

그리고 UNIX는 지금 내가 아는 모습과 비슷하게 퍼져 나가기 시작한다.

벨 연구소 이전 시절은 어땠는지 모르고 이때가 GNU보다 빠른 시기지만 책을 읽는 내내 해커문화를 느낄 수 있었다. 개발하는 사람들의 성향이 원래 그런지는 알 수 없지만 내가 아는 개발자 문화, 해커 문화가 여기서 왔는가 하는 생각도 들었다.

벨 연구소의 평가 방식이 좋았던 점은, 연구자의 일을 이해하는 다른 사람들의 공동 판단을 최종 평가의 기초로 두었다는 점이다. 더글러스 매클로이가 말했듯이 “벨 연구소 평가 제도의 특징은 동료 간의 협력 관계를 지향했다는 점이다.

AT&T 산하의 벨 연구소의 문화를 보는 것도 흥미로운 부분이었다. 오히려 그 당시의 국가와 AT&T, 산업의 상황이었을까 놀라울 정도로 자유로운 분위기와 조직문화를 보면 그때가 더 나았구나 싶은 생각마저 들 정도였다.

경영진이 하는 긍정적인 역할은 제안을 늘 신중히 검토함으로써 자원을 쓰려는 사람에게서 더 설득력 있는 주장을 이끌어내는 게 아닐까. 자원이 한정돼 있으면 그렇지 않을 때보다 직원들이 업무를 더 신중하게 계획할 가능성이 크다.

여기에는 몇 가지 이유가 있다고 본다. 첫째, 벨 연구소 연구자들은 글쓰기를 진지하게 대했고, 스스로 글을 공들여 썼으며, 다른 사람들이 쓴 글을 읽고 훌륭한 비평을 제시했다.
둘째, 연구소 경영진이 책 쓰기를 지지해주었다. 출판물은 과학계와 학계에서 벨 연구소의 평판을 유지하는 데 중요했고, 책도 그중 하나였다.
금상첨화로, 벨 연구소가 책 저작권을 보유하기는 했지만 저자가 인세를 받았다. 우리 중 누구도 돈을 벌자고 책을 썼다고는 생각하지 않는다. 벨 연구소에서 일하던 누구도 기술 서적을 쓰는 것이 돈벌이가 된다고 생각할 정도로 어리석지는 않았을 것이다. 그래도 책이 성공을 거두면 저자에게 수입이 생겼다.
세 번째 요인은 더 기술적이다. 프로그래밍 환경으로서 C와 유닉스, 연구 분야로서의 문서 생성, 컴퓨터 기술을 주제로 한 글쓰기를 주요 활동으로 삼은 것 간의 공생관계다.

당시 내가 비공식적으로 작성한 보고서에 쓴 의견처럼 말이다. "우리가 인터넷 사업에 조금이라도 발을 담그려면 이 영역에서 재빨리 행동하는 법을 배워야 합니다."

일을 즐기고 동료와 즐거움을 나누는 것은 중요하다. 1127 센터는 거의 항상 재미있는 공간이었고, 일 때문만이 아니라 놀라운 그룹의 일원이라는 정신이 우리를 하나로 묶어주었다.

"연구 과학자에게 선택의 자유는 극도로 중요합니다. 연구란 미지의 영역을 탐구하는 일이고, 여기에는 어떤 길을 택해야 할지 알려주는 로드맵이 없기 때문입니다. 각각의 과학적 발견은 연구의 다음 경로에 영향을 미치며, 누구도 발견을 예측하거나 예정할 수 없습니다. 그래서 벨 연구소 관리자들은 연구자들에게 가능한 최대한의 자유를 제공합니다. 이는 벨 연구소의 목적과 일치합니다. 연구하는 사람들은 그들의 창조적인 능력 때문에 선택됐고, 우리는 그들이 창조력을 최대한 발휘할 것을 장려합니다."

물론 지금은 대부분 스타트업 같은 회사 중심이지만 이때는 PARC도 그렇고 연구소 분위기라서 더 그런 부분이 가능했나 싶기도 하다.

정말 꼭 봐야 할 책이라고 생각한다.

프로그래밍 스타일이자 컴퓨팅 과제에 접근하는 방법에 대한 스타일인 유닉스 철학The Unix philosophy은 더글러스 매클로이가 『Bell System Technical Journal』의 유닉스 특별호(1978년 7월) 머리말에서 요약한 내용으로 다음과 같다.
(1) 각 프로그램이 한 가지 일을 잘 하게 만들라. 새로운 일을 하려면 오래된 프로그램에 새로운 ‘기능’을 추가함으로써 복잡하게 만드는 대신 프로그램을 새로 만들라.
(2) 모든 프로그램의 출력이 다른(아직 알려지지 않은) 프로그램의 입력이 될 것을 예상하라. 프로그램의 출력에 관련 없는 정보를 집어넣지 말라. 엄격히 열로 구분되거나 바이너리 형식으로 된 입력을 피하라. 대화식 입력 방식을 고집하지 말라.
(3) 소프트웨어를(심지어 운영체제라도) 일찍, 이상적으로는 수주 이내에 사용해볼 수 있게 설계하고 구축하라. 어설픈 부분을 버리고 다시 구축하는 것을 망설이지 말라.
(4) 프로그래밍 과제의 부담을 덜고자 할 때 비숙련자의 도움보다는 도구를 우선적으로 사용하라. 도구를 구축하기 위해 시간이 더 걸리고 도구를 사용한 다음에 일부는 버려야 할 것으로 예상하더라도 그렇게 하라.