엔지니어링 철학: Thompson과 Ritchie, 하나를 제대로 하라

핵심 요점

• 작고 날카로운 도구. 각 프로그램은 한 가지 일을 잘 해내고, 두 번째 일은 떠맡지 않습니다. 새로운 요구가 생기면 또 하나의 플래그가 아니라 새 도구를 만듭니다.
• 기능보다 조합. 힘은 프로그램들을 보편적 텍스트 인터페이스, 즉 파이프로 잇는 데서 나옵니다. 능력은 어느 한 프로그램 안이 아니라 그 이음매에서 생겨납니다. “하나를 제대로 하라”는 정식 표현은 Thompson이나 Ritchie가 아니라 Doug McIlroy의 것입니다.
• C를 통한 이식성. Unix를 C로 다시 작성한 덕분에, 시스템 전체를 새로 짜는 대신 컴파일러만 이식하면 새 하드웨어로 옮길 수 있었습니다. Unix가 어디에나 퍼진 이유의 대부분이 여기에 있습니다.
• 직접 만들지 않은 것은 신뢰하지 마라. Thompson의 “Reflections on Trusting Trust”는 백도어가 들여다볼 수 있는 어떤 소스 코드에도 흔적을 남기지 않고 바이너리 안에 살아 있을 수 있음을 보여줍니다. 공급망 보안의 출발점이 된 통찰입니다.

원칙

“하나를 잘 해내는 프로그램을 작성하라. 서로 협력하는 프로그램을 작성하라. 텍스트 스트림을 다루는 프로그램을 작성하라. 텍스트 스트림이야말로 보편적 인터페이스이기 때문이다.” – Doug McIlroy, Unix 철학을 요약하며¹

이 문장은 Thompson의 것도, Ritchie의 것도 아닙니다. Bell Labs에서 두 사람과 함께 일했고 Unix 파이프를 발명한 Doug McIlroy가, 1978년 Bell System Technical Journal 특별호의 서문에 쓴 글입니다.¹ 그렇지만 이 문장은 Thompson과 Ritchie가 실제로 만든 것을 가장 명료하게 표현하고 있으며, 두 사람 중 누구의 말이 아니라 이 문장으로 시작하는 이유 자체가 곧 핵심입니다. Unix 철학은 단 한 명의 천재가 써 내려간 선언문이 아니었습니다. 그것은 하나의 문화였고, 그 문화가 바로 결과물이었습니다.

이 원칙은 세 가지 동작으로 이루어지며, 셋은 떼어 놓을 수 없습니다. 각 도구를 작고 날카롭게 만들 것 – 한 가지 일을, 잘, 두 번째 일에 대한 욕심 없이. 도구들을 조합 가능하게 만들 것 – 하나의 출력이 다음의 입력이 되어, 어떤 프로그램이 비대해지는 게 아니라 결합에서 능력이 나오도록. 그리고 도구들 사이의 인터페이스를 보편적으로 만들 것 – 평문 텍스트로, 그래서 어떤 도구든 상대의 존재를 알 필요 없이 다른 어떤 도구와도 이어질 수 있도록. 힘은 부품이 아니라 이음매에 깃듭니다. 줄을 정렬하는 프로그램은 웹 로그를 전혀 모르고, 중복을 세는 프로그램은 HTTP 상태 코드를 전혀 모릅니다. 그러나 파이프로 이으면, 둘 중 어느 것도 답하도록 만들어지지 않은 질문에 답합니다.

이것은 대부분의 소프트웨어를 만들어 내는 본능과 정반대입니다. 자연스러운 끌림은 하나의 프로그램이 더 많은 일을 하게 만드는 쪽입니다 – 플래그를 더하고, 모드를 더하고, 다음 요구사항을 이미 가진 것 안으로 접어 넣는 것이죠. McIlroy의 첫 번째 규칙은 그 끌림에 이름을 붙이고 거부합니다. “새로운 일을 하려면, 낡은 프로그램에 새 ‘기능’을 덧붙여 복잡하게 만들기보다 처음부터 새로 만들어라.”¹ Thompson과 Ritchie의 시스템 전체는 단순함이야말로 나머지 모든 것의 전제 조건이며, 작은 것들이 강력해지는 길은 기능이 아니라 조합이라는 주장의 증명입니다.

배경

Unix는 하나의 실패에서 태어났습니다. 1960년대 중반 내내 Bell Labs는 MIT, General Electric과 함께 Multics를 개발하고 있었습니다. 거의 모든 것을 해내려 했던, 엄청나게 야심 찬 시분할 운영체제였습니다. 1969년에 이르러 그것은 너무나 복잡하고 너무나 지연되어, Bell Labs는 손을 뗐습니다. 그 일에 매달렸던 연구자들 – Ken Thompson, Dennis Ritchie, Doug McIlroy, Joe Ossanna – 은 편안한 대화형 컴퓨팅 환경을 잃은 데 좌절했지만, 동시에 시스템을 어떻게 만들면 안 되는지에 대한 강한 감각을 얻었습니다.²

1943년 2월 4일 뉴올리언스에서 태어난 Ken Thompson은 UC Berkeley에서 전기공학과 컴퓨터과학으로 학사와 석사를 마친 뒤 1966년 Bell Labs에 합류했습니다.³ 1941년 9월 9일 뉴욕 브롱스빌에서 태어난 Dennis Ritchie는 1967년 Computing Sciences Research Center에 들어왔습니다.⁴ 1969년, Thompson은 버려진 PDP-7 – 그 무렵 이미 구식이 된 작은 미니컴퓨터 – 을 찾아내, 그 위에 작은 운영체제를 짓기 시작했습니다. 어느 정도는 자신이 만든 Space Travel이라는 게임을 돌리기 위해서였습니다. Thompson은 훗날 역할 분담을 이렇게 잘라 말했습니다. “UNIX의 처음 두세 버전은 내가 전부 혼자 만들었다. 그리고 Dennis는 전도사가 되었다.”³ 첫 버전은 PDP-7 어셈블리로 작성되었습니다.

이름은 농담에서 왔습니다. Multics가 “Multiplexed(다중화된)”였던 반면, 새 시스템은 의도적으로 작았기에, 사람들은 그것을 “UNICS” – Uniplexed Information and Computing Service – 라고 불렀습니다. Multics를 빗댄 말장난이었죠. 철자는 “Unix”로 흘러갔고, 보통 이 이름의 작명자로 꼽히는 Brian Kernighan은 훗날 최종 형태가 정확히 어떻게 나왔는지 아무도 잘 기억하지 못한다고 적었습니다.² 그 작음은 우연도, 언젠가 벗어나야 할 한계도 아니었습니다. 그것이 곧 설계였습니다.

작업

Unix와 파일 시스템

Unix가 처음으로 제대로 해낸 것은 컴퓨터의 자원이 무엇인가에 대한 모델이었습니다. 이전 시스템들은 파일, 장치, 통신 채널을 저마다 다른 종류의 것으로 다루었고, 각각에 고유한 특수 인터페이스를 두었습니다. Unix는 그것들을 하나로 합쳤습니다. 단 하나의 계층적 파일 시스템 – 디렉터리의 트리 – 을 제시하고, 그 안에서 거의 모든 것을 파일로 다루었습니다. 문서뿐 아니라 장치도, 프로세스 간 통신 채널도 마찬가지였죠.² 파일을 읽고 쓸 수 있는 프로그램이라면, 아무것도 바꾸지 않고도 터미널이나 테이프 드라이브, 또는 다른 프로그램에서 읽을 수 있었습니다. 그 프로그램에게는 그 모두가 그저 파일이었기 때문입니다.

이것이 첫 번째 형태로 나타난 보편적 인터페이스입니다. “모든 것은 파일이다”라는 말은, 작은 도구가 입력의 종류마다 다른 버전을 둘 필요 없이 단 하나만 있으면 된다는 뜻입니다. 모든 구성 요소가 이미 같은 언어를 쓰기에, 조합의 비용은 거의 0으로 떨어집니다. 계층적 파일 시스템과 통일된 open/read/write/close 인터페이스야말로 나머지 철학이 애초에 가능했던 이유입니다. 저마다 맞춤형 연결부를 요구하는 도구들은 조합할 수 없으니까요.

C와 이식성

두 번째 돌파구는 시스템을 이식 가능하게 만드는 것이었고, 그러려면 언어가 필요했습니다. Ritchie는 1969년부터 1973년 사이에 C를 만들었습니다. Thompson의 B 언어에서 발전시킨 것인데, B는 다시 BCPL에서 내려온 것이었죠.⁴ B는 자료형이 없고 인터프리터로 동작했습니다. C는 자료형과 구조체를 더하고 효율적인 기계어로 컴파일되었습니다. 운영체제를 짤 수 있을 만큼 하드웨어에 가깝고, 기계 사이를 옮겨 다닐 수 있을 만큼 추상적이었습니다.

결정적 순간은 1973년 무렵, Version 4 Unix가 C로 다시 작성되었을 때 찾아왔습니다.² 그때까지 운영체제란 어셈블리 언어였고, 그것이 쓰인 단 한 대의 기계에 영구히 용접되어 있었습니다. Unix를 고급 언어로 다시 쓰는 것은 거의 이단에 가까웠습니다 – 통념상 시스템 코드는 손수 다듬은 어셈블리여야 했고, 그렇지 않으면 너무 느릴 거라고 여겨졌으니까요. Thompson과 Ritchie는 그래도 그 일을 해냈고, 그 대가로 이식성을 얻었습니다. 이제 Unix는 시스템 전체를 다시 쓰는 게 아니라 컴파일러를 이식하는 것만으로 새 하드웨어로 옮길 수 있었습니다. 동시대의 시스템들이 처음 올라탔던 쇳덩이에 못 박힌 채 머무는 동안 Unix가 컴퓨팅의 구석구석까지 퍼진 이유의 대부분이 바로 그 하나의 결정에 있습니다. 1978년, Ritchie와 Kernighan은 The C Programming Language – “K&R” – 를 펴냈습니다. 한 세대에게 C 작성법을 가르쳤고 지금도 기술 산문의 본보기로 남아 있는, 군더더기 없고 정확한 책입니다.⁵ Thompson과 Ritchie는 1974년 7월 Communications of the ACM에 실린 논문 “The UNIX Time-Sharing System”으로 시스템 자체를 더 넓은 세상에 알렸습니다.⁶

파이프와 조합 모델

파일 시스템이 도구들에게 같은 언어를 말하게 했다면, 파이프는 그들이 서로 말하게 했습니다. 그 아이디어는 Doug McIlroy의 것이었습니다. 그는 여러 해 동안 프로그램들을 끝과 끝으로 잇는 방법, 즉 한 프로그램의 출력이 정원용 호스를 이은 것처럼 다음 프로그램으로 곧장 흘러드는 방법을 밀어붙였습니다. Thompson은 1973년에 – 유명하게도 단 하룻밤 만에 – 그것을 구현해, pipe() 시스템 호출과 | 연산자를 셸에 추가했습니다.⁷ McIlroy는 그다음 벌어진 일을 이렇게 묘사했습니다. “이튿날, 모두가 배관 작업의 흥분에 동참하면서 잊을 수 없는 한 줄짜리 명령의 향연이 펼쳐졌다.”⁷

그 한 줄짜리 명령의 향연이 바로 철학의 실천이었습니다. 누구도 새 프로그램을 쓸 필요가 없었습니다. 사람들은 이미 가진 작은 프로그램들을 엮으면 그 어느 것도 답하도록 설계되지 않은 질문에 답할 수 있다는 것을 발견했죠. grep 다음 cut 다음 sort 다음 uniq -c 다음 sort -rn 다음 head로 이어지는 파이프라인은 여섯 단계로 이루어집니다. 각 단계는 다른 단계를 모르고, 각각 한 가지 일만 하며, 텍스트 스트림을 통해 왼쪽에서 오른쪽으로 조합됩니다. 능력은 창발적입니다. 그것은 어느 한 명령이 아니라 | 안에 깃듭니다.

이것이 시스템 전체에서 가장 깊은 아이디어입니다. 대부분의 소프트웨어는 누적으로 자랍니다. 하나의 프로그램이 새 요구사항을 하나씩 흡수하다가, 결국 작성한 사람만이 이해하는 단일체가 됩니다. Unix는 조합으로 자랍니다. 시스템은 작은 부품들의 키트로 남고, 새로운 능력은 낡은 부품들의 새로운 배열에서 나옵니다. 텍스트 스트림은 그 배열을 거저 만들어 주는 보편적 인터페이스입니다. 그래서 Unix 셸은 50년이 지난 지금도 여전히 가장 표현력 높은 프로그래밍 환경 가운데 하나로 남아 있습니다 – 작은 단일 목적 프로그램들로 이루어졌음에도 불구하고가 아니라, 바로 그렇기 때문에 말이죠.

Trusting Trust와 이후의 유산

1983년 Thompson과 Ritchie는 ACM 튜링상을 공동 수상했습니다. 수상 사유는 “범용 운영체제 이론의 발전, 그리고 특히 UNIX 운영체제의 구현에 대하여”였고, 위원회의 성명은 그 원칙을 정확히 짚었습니다. “UNIX 시스템의 성공은 몇 가지 핵심 아이디어를 취향 있게 선별하고 그것을 우아하게 구현한 데서 비롯된다.”⁸ 몇 가지 핵심 아이디어의 취향 있는 선별 – 그 상은 사실상 절제에 주어진 것이었습니다.

1984년 “Reflections on Trusting Trust”로 발표된 Thompson 자신의 튜링상 강연은, 같은 미니멀리즘적 엄밀함을 보안으로 돌렸습니다. 그는 컴파일러가 login 프로그램에 백도어를 삽입하도록 학습될 수 있고, 나아가 자신이 컴파일하는 미래의 모든 컴파일러에 그 백도어 삽입 기능을 다시 심도록 만들 수 있음을 보여 주었습니다 – 그래서 악성 코드는 오직 바이너리 안에만 살아 있고, 들여다볼 수 있는 어떤 소스 코드에도 흔적을 남기지 않습니다. 그의 결론은 컴퓨팅에서 가장 많이 인용되는 문장 가운데 하나입니다. “당신이 전적으로 직접 만들지 않은 코드는 신뢰할 수 없다… 아무리 많은 소스 수준의 검증이나 검사도, 신뢰할 수 없는 코드를 사용하는 일로부터 당신을 지켜 주지 못한다.”⁹ 이것이 공급망 보안 사고의 출발점이 된 글입니다 – 우리가 신뢰하는 대상은 소스 코드가 아니라 바이너리를 만들어 낸 전체 툴체인이라는 깨달음 말이죠.

두 사람의 이후 경력은 같은 본능을 이어 갔습니다. Thompson은 좀처럼 가만있지 못했습니다. Bell Labs에서 그는 Plan 9 운영체제(“모든 것은 파일이다”를 네트워크 너머까지 한층 더 밀어붙인), ed 편집기, 그리고 정규 표현식과 grep의 실용 이론을 만들었습니다. 1992년에는 Rob Pike와 함께 UTF-8 – 이제 세상의 거의 모든 텍스트를 실어 나르는 가변 폭 텍스트 인코딩 – 을 단 하룻저녁에 설계했는데, 유명하게도 식당 매트 위에 끄적여 만들었습니다.³ 그리고 2007년 Google에서 Thompson은 Robert Griesemer, Rob Pike와 함께 Go 프로그래밍 언어를 공동 설계해 2009년에 공개했습니다. 의도적으로 작고, 빠르게 컴파일되며, 조합 가능한 언어로, Unix의 가치로 의식적으로 돌아간 것처럼 읽힙니다.¹⁰ 2011년 10월 12일에 세상을 떠난 Ritchie는 더 조용하지만 훨씬 더 널리 스며든 자취를 남겼습니다. 역사가 Paul Ceruzzi의 말처럼, “현미경으로 컴퓨터 안을 들여다볼 수 있다면, 그 안 어디에서나 그의 작업을 보게 될 것”입니다.⁴

방법론

그 방법론은 40년에 걸쳐, 그리고 그것을 굳이 설명할 필요가 거의 없었던 두 사람에게서 일관됩니다.

작고 날카로운 도구를 만든다. 각 프로그램은 한 가지 일을 합니다. 그 규율은 거부입니다. 새로운 요구가 나타나면, 답은 낡은 도구에 볼트로 붙인 새 플래그가 아니라 새 도구입니다. “낡은 프로그램을 복잡하게 만들기보다 처음부터 새로 만들어라.”¹

누적이 아니라 조합한다. 능력은 결합에서 창발하도록 되어 있습니다. 시스템은 작은 부품들의 키트일 때 이해 가능한 채로 남고, 어떤 부품이 단일체로 부풀어 오르는 게 아니라 재배열로 자랍니다.

도구가 아니라 인터페이스를 표준화한다. 통합의 동작 – “모든 것은 파일이다”, 프로그램 사이를 흐르는 평문 텍스트 스트림 – 은 연결을 보편적으로 만들어 구성 요소들이 서로를 모르는 채로 남을 수 있게 하는 것입니다. 값싼 이음매야말로 작은 부품들을 강력하게 만드는 것입니다.

몇 가지 핵심 아이디어를, 취향 있게 고른다. 튜링상 위원회의 표현은 입에 발린 말이 아니라 방법론이었습니다. Unix는 무엇을 빼냈는가로 유명합니다. C를 통한 이식성, 파일 추상화, 파이프 – 한 줌의 결정, 각각이 엄청난 무게를 지고, 군더더기는 의도적으로 부재한 채로.

들여다볼 수 없는 것은 불신한다. “Trusting Trust”는 방법론을 안으로 겨눈 것입니다. 단순함과 가독성은 미적 미덕일 뿐 아니라 신뢰의 유일한 실질적 근거입니다. 복잡함이야말로 당신이 볼 수 없는 것들이 숨어드는 곳이기 때문이죠.

영향의 사슬

그들을 빚은 사람들

반면교사로서의 Multics. 가장 결정적인 영향은, 그들이 직접 만드는 데 참여했다가 떠나 버린 시스템이었습니다. Multics는 Thompson과 Ritchie에게, 가능한 한 가장 값비싼 방식으로, 과욕의 대가가 무엇인지를 가르쳤습니다 – 그리고 Unix는 상당 부분 그것에 대한 규율 잡힌 반작용입니다. (형성적 영향)

Doug McIlroy. Computing Sciences Research Center의 책임자였던 McIlroy는 파이프를 발명했고, “하나를 제대로 하라”는 철학을 글로 표현했으며, 그룹의 집요한 취향 비평가 역할을 했습니다. 조합 모델은 누구의 것 못지않게 그의 것이고, 그가 바로 이 철학의 정식 표현에 대한 올바른 출처입니다. (직접적 영향)

Bell Labs의 연구 문화. 자유와 좋은 기계를 부여받은 소수의 동료 집단이, 제품 로드맵이 아니라 자기들끼리의 우아함을 위해 최적화했습니다. Unix는 경영진이 사양을 정한 것이 아니라, 취향 있는 것을 가치 있게 여기고 비대한 것을 비웃은 문화에서 누적되어 나왔습니다. (형성적 영향)

그들이 빚은 사람들

모든 Unix 후예. Linux, BSD 계열, macOS는 직계 상속자입니다. Thompson과 Ritchie가 버려진 PDP-7 위에 쓴 시스템은 이제 지구상 대부분의 서버, 전화기, 임베디드 장치를 돌립니다.

모든 셸과 명령줄. 파이프와 조합 모델은 50년이 지난 지금도 사실상 모든 프로그래머와 시스템 관리자의 일상 작업 환경입니다 – 본질은 그대로인데, 그 본질이 옳았기 때문입니다.

C와 그 자식들. C는 시스템 프로그래밍의 공용어가 되었고, 그 문법과 의미론은 C++, Java, Go, Rust, 그리고 오늘날 쓰이는 대부분의 것을 통해 메아리칩니다. K&R은 언어를 어떻게 문서화할 것인가의 본보기로 남아 있습니다.

Unix 철학 그 자체. “하나를 제대로 하라”는 Unix를 넘어 일반적인 설계 원칙이 되었습니다 – 마이크로서비스에, 명령줄 도구에, 빌드 없는, 작은 조각들로 이루어진 웹 접근법에, 그리고 AI 시스템을 안전하고 읽을 수 있을 만큼 작게 유지하는 법에 말이죠.

관통하는 한 줄기

Thompson과 Ritchie는 이 시리즈를 관통하는 동일한 신념의 시스템 수준 표현입니다. Edsger Dijkstra는 단순함이 신뢰성의 전제 조건이라고 주장했고, Unix는 그 주장을 컴파일해 출하한 것입니다 – 몇 가지 핵심 아이디어의 알맹이를, 신뢰할 수 있을 만큼 작게 유지한 채로. Linus Torvalds의 “좋은 취향”, 즉 특수 케이스가 사라지는 그 재작성은, 파이프라인을 가로질러서가 아니라 하나의 함수 안에서 이루어지는 “하나를 제대로 하라”입니다. 그리고 Torvalds는 바로 이 두 사람이 놓은 토대 위에 Linux와 Git을 곧장 지었습니다. John Carmack의 빠르고 단순한 핵심은, 하드웨어 천장을 겨냥한 동일한 뺄셈입니다. 그리고 인간의 행복을 위한 Yukihiro Matsumoto의 Ruby 설계는, 조합 가능하고 표현력 있는 작은 조각들이라는 Unix의 본능을 고급 언어로 끌어올린 것입니다. 관통하는 한 줄기는 한 문장입니다. 힘은 어느 한 부품이 비대해지는 데서가 아니라, 작고 이해 가능한 부품들을 보편적 인터페이스를 통해 조합하는 데서 나와야 한다. (시리즈 가교)

내가 여기서 얻는 것

내가 간직하는 교훈은, 인터페이스가 곧 아키텍처라는 것입니다. 이제 무엇이든 설계할 때 – 에이전트든, 도구 루프든, 스크립트 파이프라인이든 – 늘 따라오는 유혹은 하나의 구성 요소를 더 똑똑하게 만들고, 다음 요구사항을 이미 가진 것 안으로 접어 넣어, 끝내 나만 이해하는 단일체로 만드는 것입니다. Unix의 동작은 그 반대입니다. 각 조각을 완전히 이해할 수 있을 만큼 작게 유지하고, 지능은 조각들이 어떻게 연결되는가에 넣는 것이죠. 깨끗한 이음매가 없는 영리한 부품보다, 멍청한 부품들 사이의 깨끗하고 보편적인 이음매가 언제나 낫습니다. 이것은 품질이 유일한 변수라는 것과 같은 기준입니다 – 질문은 결코 “이 한 프로그램이 더 많은 일을 할 수 있는가?”가 아니라 “이 시스템은 여전히 내가 추론할 수 있는 조각들로 이루어져 있는가?”입니다.

지금 내가 짓고 있는 세계 – 도구와 텍스트로 함께 엮인 AI 에이전트 – 에서, Thompson과 Ritchie의 설계는 쉰 살 남짓 된 것치고는 당치도 않게 적실합니다. 에이전트는 작은 프로그램이고, 도구도 작은 프로그램입니다. 그것들을 강력하게 만드는 것은 그 사이의 깨끗하고 보편적인 인터페이스이며, 오늘날 그것은 대개 구조화된 텍스트입니다. 그것이 다시 지어진 파이프입니다. 그리고 “Trusting Trust”는 내가 가장 진지하게 받아들이는 경고입니다. 누구도 읽을 수 있는 속도보다 빠르게 시스템이 코드를 생성할 때, 신뢰의 유일한 지속적 근거는 부품을 작게, 이음매를 읽을 수 있게 유지하는 것입니다. 복잡함이야말로 당신이 볼 수 없는 것들이 숨으러 가는 바로 그곳이기 때문이죠. 그 신념 – 취향은 기술적 시스템이며, 작고 조합 가능하고 들여다볼 수 있는 조각들은 한낱 미덕이 아니라 게임의 전부라는 신념 – 은 1969년의 PDP-7에서 2026년의 에이전트 하니스까지 곧장 이어집니다.

자주 묻는 질문

Unix 철학이란 무엇인가요?

Unix 철학은 작고 단일 목적인 도구들이 보편적 인터페이스를 통해 조합된다는 데 기반을 둔 설계 접근법입니다. 1978년 Doug McIlroy가 남긴 그 정식 표현은 이렇습니다. “하나를 잘 해내는 프로그램을 작성하라. 서로 협력하는 프로그램을 작성하라. 텍스트 스트림을 다루는 프로그램을 작성하라. 텍스트 스트림이야말로 보편적 인터페이스이기 때문이다.” 첫 번째 원칙은 기존 도구에 기능을 더하기보다 새 도구를 만드는 것이며, 시스템의 힘은 어느 한 프로그램이 비대해지는 데서가 아니라 – 파이프와 평문 텍스트를 통해 – 작은 부품들을 결합하는 데서 나옵니다.¹

Ken Thompson이 “하나를 제대로 하라”고 말했나요?

아닙니다. “하나를 제대로 하라”는 격언과 더 넓은 Unix 철학은, Bell Labs Computing Sciences Research Center의 책임자였던 Doug McIlroy가 1978년 Bell System Technical Journal Unix 특별호 서문에 글로 표현한 것입니다.¹ Thompson과 Ritchie는 그 철학을 구현하는 시스템을 만들었고, Unix 파이프를 발명하기도 한 McIlroy는 그 철학의 가장 명료한 표현자이자 그룹의 상주 취향 비평가였습니다. 이 격언을 Thompson에게 돌리는 것은 흔하지만 잘못된 지름길입니다.

Thompson과 Ritchie는 실제로 무엇을 만들었나요?

Ken Thompson은 1969년부터 PDP-7 위에 Unix 운영체제의 첫 버전들을 지었고, 이후 B 언어, ed 편집기, 실용적인 정규 표현식 검색(grep), Plan 9 시스템, UTF-8(Rob Pike와 함께)을 만들었으며, Google에서 Go를 공동 설계했습니다.³ Dennis Ritchie는 C 프로그래밍 언어(1969–1973)를 만들어 1973년 Unix를 이식 가능하게 만들기 위해 다시 작성하는 데 썼고, 1978년 Brian Kernighan과 함께 The C Programming Language를 공동 저술했습니다.⁴⁵ 두 사람은 Unix로 1983년 ACM 튜링상을 공동 수상했습니다.⁸

“Reflections on Trusting Trust”란 무엇인가요?

이것은 Communications of the ACM에 실린 Ken Thompson의 1984년 ACM 튜링상 강연입니다. 그는 컴파일러가 프로그램에 숨겨진 백도어를 삽입하도록, 그리고 자신의 새 버전을 컴파일할 때마다 그 백도어를 재생산하도록 만들 수 있음을 보여 주었습니다 – 그래서 악성 코드는 오직 바이너리 안에만 존재하고, 읽을 수 있는 어떤 소스 코드에도 흔적을 남기지 않습니다. 그의 결론은 이렇습니다. “당신이 전적으로 직접 만들지 않은 코드는 신뢰할 수 없다… 아무리 많은 소스 수준의 검증이나 검사도, 신뢰할 수 없는 코드를 사용하는 일로부터 당신을 지켜 주지 못한다.” 이것은 소프트웨어 공급망 보안의 토대가 된 글입니다.⁹

출처