혁신은 제약이 있는 환경에서 나온다 - Unix의 사례

탁월한 인재들이 모여서 마음껏 자원을 쓸 수 있고 다른 일에는 신경 쓰지 않고 문제 풀이에만 집중할 수 있는 환경. 혁신적인 결과들은 당연히 이런 환경에서 가장 잘 나오지 않을까? 하지만 역사를 들여다보면 온갖 제약이 걸려있는 상황에서 세상을 바꾼 결과가 나오기도 하고, 모든 것을 갖춘 최고의 환경이 그 어떤 중요한 결과도 만들어내지 못하는 사례를 쉽게 찾을 수 있다.

컴퓨팅의 역사에서 세상을 가장 크게 바꾼 소프트웨어 단 하나를 골라야 한다면 많은 사람이 Unix를 선택할 것이다. 물론 자유 소프트웨어 운동을 완성하고 현재 가장 많이 쓰이는 운영체제인 Linux를 꼽는 경우도 있을 것이다. 하지만 BSD (Berkeley Software Distribution)를 비롯해서 수 많은 대안들이 있었던 Unix-like 운영체제 보다는 핵심 디자인과 철학을 처음 정립한 Unix가 더 중요한 발명이었다는 것에 대부분 동의할 것이다¹.

얼마 전에 Unix를 만든 Ken Thompson의 인터뷰 영상을 보게 됐다. UC Berkeley 졸업 후 벨 연구소에서 일하게 된 이야기와 Multics 운영체제 프로젝트 참여로부터 시작된 Unix의 탄생 비화, Uinx Pipe 아이디어를 얻은 과정과 Grep 도구 개발 등을 회상하는데 재밌는 구전 동화를 듣는 것 같아서 1시간이 금방 지나갔다. 그런데 인터뷰를 보고 나니 Unix가 바로 제약 있는 환경 속에서의 만들어진 혁신적인 결과물의 재밌는 예시라는 생각이 들었다.

Multics의 실패

(영상의 17분 36초) Thompson이 Multics에 대해 다음과 같이 평가한다.

Multics는 너무도 복잡하게 설계된 (over-engineered) 거대한 프로젝트였습니다. 전형적인 속편의 문제 (second-system syndrome)였죠. MIT는 정말 잘 만든 시분할 (time-sharing) 시스템을 갖고 있었는데 후속 시스템을 더 잘 만들기로 했지요. 그런건 실패할 수밖에 없어요. MIT, 벨 연구소, 제너럴 일렉트릭 (GE) 세 조직의 협력 프로젝트였는데 ...

이 부분을 보고 오래전에 재밌게 읽었던 The Art of Unix Programming (TAOUP) 의 관련된 챕터를 다시 찾아봤다. Multics의 전신은 CTSS 운영체제였고 CTSS와 Multics 모두 미국 국방성 DARPA에서 Project MAC (Mathematics and Computation)을 통해 펀딩을 받았다. 초기 지원 금액만 1960년대에 2백만 달러에 달하는 큰 규모의 프로젝트였다.

Multics는 당시에도 최고의 대학원이었던 MIT에서 이미 성공적으로 운영 체제를 만든 팀이 DARPA와 벨 연구소, GE로부터 지원을 받아 만들어졌다. 그러나 일부 시스템에서 쓰이다가 1988년에 개발이 중단되고 지금은 Unix의 역사 속에서나 언급된다. Multics의 실패에는 여러 가지 이유가 있겠지만 공통적으로 너무 잘 만들려고 필요 이상으로 복잡해져 현실에서의 사용성이 떨어진 것을 지적한다. Multics는 많은 자원이 오히려 최적의 시스템을 만드는 데 좋지 않은 영향을 미친 경우이다.

Unix를 외면한 벨 연구소

벨 연구소는 그 당시 통신과 컴퓨터 관련 최고의 연구소였으니 그 곳에서 세상을 바꾼 Unix라는 결과물이 나온 게 당연해보인다. 하지만 Multics와 달리 Unix는 개발 과정에서 제대로 된 지원을 받지 못했다.

(영상의 19분 17초) Thompson은 초기 개발 과정을 다음과 같이 회상한다.

벨 연구소가 (Multics 개발에서) 빠지면서 좋지 않은 인상을 받았죠. 그래서 연구소에서 운영체제 개발을 다시는 하지 않기로 했어요. 하지만 저는 운영체제를 개발하고 싶었고 ...

(24분 57초)

벨 연구소는 여전히 운영체제 개발을 허락하지 않았어요. (PDP-7에서 개발한) Unix를 PDP-10으로 이식하는 제안서를 냈는데 우리 네 명이 요청할 수 있는 예산 총액으로 충분하고도 남았는데도 곧바로 거절당했어요. ... 그래서 Joe Ossanna가 특허를 작성하고 수정하는 애플리케이션을 만들겠다는 속임수를 고안해냈어야 했어요.

Thompson의 회상대로 Unix는 벨 연구소의 프로젝트가 아니라 그의 개인 프로젝트였다. Space Travel 게임을 개발하려고 PDP-7 컴퓨터에서 작동하는 운영체제를 만든 게 시작이었고 연구소에서 운영체제 개발을 지원하지 않아 다른 부서의 잘 쓰이지 않는 PDP-7 컴퓨터를 찾아서 써야 했다고 한다. 새로운 컴퓨터를 사기 위해서 프로젝트를 위장했어야 했다는 기억은 "웃프다"는 표현이 어울린다.

그러나 역설적이게도 벨 연구소에서 제대로 지원을 받지 못했기에 Unix가 성공했다고도 볼 수 있다. "간단하고 바보같이" 만든다는 KISS (Keep It Simple and Stupid)는 Unix를 성공하게 만든 철학들을 요약하는 가장 중요한 원칙이다. 만약 Unix가 벨 연구소 차원의 프로젝트로 전폭적인 지원을 받았다면 Multics가 그랬듯이 더 잘 만들어야 하고 복잡해져야 한다는 압력을 받아 같은 전철을 밟지 않았을까? TAOUP에서도 Multics와 Unix를 비교하며 같은 점을 환기해준다.

Multics는 수천 장의 기술 명세를 하드웨어가 도착하기도 전에 작성했던 거대한 프로젝트인 반면에 처음 동작했던 Unix는 세 명이 브레인스토밍하고 Ken Thompson이 구식 컴퓨터에서 이틀 만에 작성했다.

Ken Thompson의 개인적인 상황

연구소에서 운영체제 개발을 지원해주지 않는 문제도 있었지만, Unix를 개발할 당시의 Thompson은 개인적으로도 일에만 온전히 몰두할 수 있는 상황은 아니었던 것 같다.

(22분 42초)

(디스크 스케쥴링 프로그램을 작성하다가) 그 순간이 오기 전까지는 몰랐는데 운영체제를 완성하기까지 3주의 시간이면 될 거라는 걸 깨달았어요. ... 다행히도 그때 제 아내가 3주의 휴가를 가기로 했고 (청중 웃음) - 돌을 맞은 아이와 캘리포니아에 있는 처가에 가려고 말이죠 - 떠나고 혼자 남은 덕에 3주 만에 Unix를 완성할 수 있었죠.

Thompson은 Unix를 개발할 때 갓난아이를 키우고 있었다. 아이와 함께 아내가 떠난 3주의 기간이 주어져 다행이었다고 하는 걸 보니 육아 때문에 많은 개인 시간을 Unix 개발에 투자하기는 어려웠을 것이라 쉽게 추측할 수 있다. 이 시기와 Unix 개발이 겹치는 건 그저 우연일까? 프로그래밍 언어를 연구하시는 이광근 교수님이 번역한 Donald Knuth의 글을 읽고는 아닐 수도 있다는 생각이 들었다.

"내 인생에서 제일 창의적이었던 일들을 꼽으려고 회고해 보면, 그것들이 모두 어느 한 시절, 가장 많은 제약조건과 잡무로 치이고 있었던 시기에 일어났었다는 것을 알게된다. ... 쓰고있던 책(The Art of Computer Programming)이 곧 출판을 준비하고 있었고, 태어난 애기 둘을 아내와 함께 돌봐야 했고, 잠깐 입원까지 하기도 했었고, ... "

지금까지의 내 인생에서도 가장 생산적이었던 시절은 3년 동안 산업기능요원으로 병역 의무를 수행하던 때였다. 회사에서 일을 해야 하니 개인적으로 배우고 하고 싶었던 일을 할 시간이 학생 때와 비교도 안 되게 부족했다. 하지만 이 시기에 출퇴근 시간을 포함한 남는 시간을 최대한 활용해서 그 전에 학교에서 보낸 3년보다 더 많은 책을 읽고 더 많은 것들을 해내며 발전할 수 있었다.

어쩌면 우리는 시간이 제한되면 꼭 해야 하는 중요한 일에 더 잘 집중할 수 있는 게 아닐까? Stephen Covey를 통해서 유명해진 아이젠하워 시간 관리법에서는 일을 중요도와 긴급성에 따라 네 가지로 분류한다. 여기서 시간 관리의 핵심은 "중요하지만 급하지 않은 일" (책읽기, 가족과 시간 보내기 등)의 우선순위를 높여서 처리하는 것이다. 시간이 많을 때는 급하지 않다고 생각했던 일들이 시간에 제약이 생기면 상대적으로 급해 보이게 된다. 거기에 시간이 제한되었다는 생각에 집중력이 향상되는 효과까지 더해졌던 게 내 경우에는 좋게 작용했다. Thompson과 Knuth의 경우처럼 해결하고자 하는 중요한 일을 알고 있다면, 시간의 제약조차도 성취를 하는데 도움이 될 수 있다고 생각하게 된다.

마치며

앞에서 인용했던 이광근 교수님의 웹 페이지에서 혁신적인 성취가 제약된 환경에서 이루어졌다는 여러 위인의 회고를 볼 수 있다. 이후 Unix의 역사에서도 비슷한 다른 사례들을 더 자세히 들여다보아도 재밌을 것이다. 가장 성공하기 좋아 보였던 환경에서 만들어진 UC Berkeley의 BSD가 아니라 핀란드의 대학원생이 만든 Linux가 성공한 사례, 그리고 벨 연구소 차원에서 제대로 만들어보려 했던 Unix의 후속 Plan 9의 사례 등에서 비슷한 패턴을 찾을 수 있을 것 같다.

이런 역사를 배우는 게 흥미로울 뿐만 아니라 내 삶의 태도를 더 낫게 만든다고 느낀다. 누구나 온갖 제약 조건에 시달리지만 그것들을 기회로 바라볼 수 있는 관점은 모두가 갖고 살아가지는 않을 것이다. 더 나은 환경에서 일하기 위한 노력을 계속하면서도 어쩔 수 없는 제약들은 긍정적으로 받아들인다면 어느 곳에 있어도 혁신적인 일을 해낼 수 있다는 것, 내가 Unix로부터 배운 또 하나의 교훈이다.