리눅스 30주년 맞이 리누스 토발즈 인터뷰 번역 - 파트 1

리눅스 커널이 처음 공개된지 올해로 30년이 되었고, 이를 맞아 tag1 에서 리누스 토발즈와 인터뷰 를 했습니다: https://www.tag1consulting.com/blog/interview-linus-torvalds-linux-and-git 분량이 길어 두 파트로 나눠 올라왔는데, 해당 매체에 허락을 받고 이곳에 그 중 첫번째 파트의 번역을 올립니다.

두번째 파트는 여기서 보실 수 있습니다.

아래 분들께서 오타 등을 찾고 글을 다듬는 걸 도와주셨습니다. 감사의 말씀을 전합니다.

• ganadist
• Jaehoon Kim

---

리눅스 커널 개발

Jeremy Andrews: 리눅스는 어디에나 사용되고 있고, 전체 오픈소스 세계에 영향을 끼쳤습니다. 물론, 처음부터 그런 건 아니었습니다. 당신은 comp.os.minix 의 Usenet 메일링 리스트에 겸손한 메일을 보냄으로써 1991년에 리눅스 커널을 릴리즈 했고 이는 무척 유명해졌죠. 10년 후, 당신은 그 역사를 이야기 하는”Just for Fun: The Story of an Accidental Revolutionary” 라는 매력적이고도 개인적인 책을 냈습니다. 올해 8월, 리눅스는 30주년을 맞이하게 되었습니다! 대단해요, 축하합니다! 이 여정 가운데 언제쯤부터 당신은 리눅스가 “그저 취미 (just a hobby)” 보다는 더한 무엇이 되었음을 깨달았나요?

Linus Torvalds: 좀 웃기게 들리겠지만, 그건 무척 초반부터였습니다. 이미 1991년 말부터 (그리고 1992년 초부터는 분명히) 리눅스는 이미 제가 예상한 것보다 훨씬 커져 있었습니다.

그리고 그때 대략 수백명의 사용자가 있었는데 (“사용자” 라고 하는 것도 너무 어감이 강할지도요 - 사람들은 그걸 이리저리 뜯어보고 있었습니다), 리눅스가 나중에는 그보다 훨씬 거대해졌다는 점을 생각해 보면 이건 좀 이상하게 들릴 거예요. 하지만 제게 개인적으로는 다른 사람들이 활발하게 그걸 사용하고 있음을, 그리고 그것이 스스로의 삶을 시작했음을 깨달은 때가 여러 의미로 큰 변곡점이었습니다. 사람들은 패치를 보내기 시작했고, 시스템은 제가 처음에 상상했던 것보다 훨씬 많은 것들을 하기 시작했죠.

X11 이 92년 4월에 리눅스로 포팅된 걸로 기억하는데 (날짜는 틀릴 수 있어요 - 그건 오~~래전 일이예요), 이는 GUI 와 모든 새로운 기능들이 가능하게 한, 또다른 큰 한걸음이었습니다.

이 모든걸 놓고 보면 - 나는 높은 기대치의 큰 계획을 가지고 시작하지 않았습니다. 그건 새로운 운영체제를 만들어내기 위한 어떤 큰 꿈으로부터 시작된 게 아니라 말 그대로 그저 제 새 PC 하드웨어가 어떻게 작동하는지 알아보려 시작한데서 우발적으로 시작된 개인 프로젝트였습니다.

그래서 제가 최초 버전을 릴리즈 했을 때, 그건 정말 “내가 뭘 만들었는지 보세요” 에 더 가까웠고, 다른 사람들이 거기에 흥미를 갖길 제가 원했던 건 분명하지만, 그건 정말 진지하고 사용할 수 있는 OS 는 아니었습니다. 그건 그보단 컨셉의 증명에 가까웠고 제가 몇달의 시간동안 일한 개인 프로젝트에 불과했습니다.

그리고 그 “개인 프로젝트” 가 다른 사람들이 가져다 사용하고 피드백 (과 버그 레포트), 그리고 심지어 패치를 보내주는 것이 되어가는 과정은 제게 큰 변화였습니다.

단지, 정말 기본적인 무언가 예를 들어 주기 위해서 사용한 리눅스 원래의 저작권 라이센스는 “당신은 이걸 소스 형태로 배포할 수 있습니다만, 상업적으로는 안됩니다” 같은 것이었습니다.

왜냐하면 제게 있어 큰 문제들 중 하나는 말 그대로 상업용 유닉스는 비쌌다는 것이고 (글쎄요, 자기 돈을 모두 새로운 PC 사는데 쓴 가난한 학생에게는 말이죠), 때문에 제게 있어 (사람들이 그걸 고칠 수 있게끔) 소스코드가 사용 가능해야 한다는 건 크고 중요한 일 중 하나였습니다, 그리고 대안을 구매할 돈이 없는 바로 저같은 사람들에게 열려 있기를 바랬어요.

그리고 전 그 라이센스를 91년 말 (또는 92년 초일지도) GPLv2 로 바꿨는데요, 그걸 지역 유닉스 사용자 그룹에 플로피 디스크를 사용해 배포하고자 하는데 최소한 그 플로피 디스크와 그 복사본을 만드는데 들인 시간을 보상받고 싶어하는 사람들이 있었기 때문입니다. 그리고 저는 그건 분명 완전 합리적인 일임을, 그리고 정말 중요한 건 “비상업성” 이 아니라 “소스코드는 개방되어야 한다” 는 부분임을 깨달았습니다.

그 결과, 사람들은 그걸 유닉스 사용자 그룹 모임에 배포할 뿐만 아니라, SLS 와 Slackware 같은 플로피 디스크 기반 배포판들을 몇달만에 만들었습니다.

초기의 정말 기본적인 변화들에 비교해서, 다른 모든 것은 “점진적” 이었습니다. 맞아요, 그런 점진적 변화 가운데 일부는 정말 거대했습니다 (IBM 이 참여하고, 오라클 DB 가 포팅되고, 레드햇이 상장하고, 안드로이드가 전화기 등에서 거대해지고), 하지만 그것들은 정말 초기의 “내가 알지도 못하는 사람들이 리눅스를 사용함” 에 비하면 제 개인적으로는 덜 혁명적이었어요.

JA: 라이센스 선택에 대해, 또는 당신이 만든 것을 이용해 다른 사람이나 회사가 많은 돈을 벌어들이는 것에 대해 후회한 적은 없습니까?

LT: 전혀요.

일단, 전 꽤 잘 살고 있습니다. 전 미친듯한 부자는 아닙니다만, 좋은 보수를 받는 소프트웨어 엔지니어이고, 제가 좋아하는 걸 제 스스로의 스케쥴에 맞춰 하고 있습니다. 전혀 상처받지 않아요.

하지만 이와 똑같이 중요한게, 그 라이센스가 리눅스 (그리고 Git) 의 성공의 큰 이유 중 하나였음에 100% 만족하고 있습니다. 저는 프로젝트에 참여하는 모두가 모든 사람이 동일한 권리를 가졌고, 누구도 라이센스에 관해선 특별하지 않음을 깨달을 때 훨씬 행복해진다고 생각합니다.

원래 소유자가 상업성 라이센스를 소유하며 (“우리에게 라이센스 비용을 지불하면 당신은 이걸 당신의 독점 상품에 사용할 수 있습니다”), 다른 한편으로는 오픈소스의 경우엔 GPL 같은 무언가 하에 사용될 수도 있는 많은 수의 “듀얼 라이센스” 프로젝트들이 존재합니다.

그리고 전 그런 종류의 상황 하에서는 커뮤니티를 만들기가 정말 어렵다고 생각하는데, 항상 오픈소스 쪽은 “두번째 클래스” 임을 알기 때문입니다. 또한 이는 특수한 집단이 항상 특수한 권리를 유지하기 위해 단순한 라이센스 서류 작업을 많이 해야 하게 합니다. 때문에 이는 프로젝트에 많은 마찰을 일으킵니다.

다른 한편으로, 전 여러 BSD (또는 MIT 나 비슷한 것들) 라이센스를 사용하는 오픈소스 프로젝트들이 상업적으로 중요해질 만큼 거대해지는 순간 분열되고, 관련된 회사들이 자신들의 부분들을 독점화 하기로 결정해야만 하게 되는 것을 봤습니다.

따라서 저는 GPLv2 가 “모두가 같은 규칙 아래 일한다”, 그리고 그 사람들은 커뮤니티에 얻은 것을 공헌한다 (“팃포탯”) 의 완벽한 밸런스라고 생각합니다. 그리고 모두가 참여자는 같은 규칙 아래 있음을 알게 되므로, 매우 공평하고 정당합니다.

물론, 이것의 또다른 측면은 여러분 또한 공헌한 만큼 받아간다는 겁니다. 맞아요, 여러분은 프로젝트 변방에 머무르고 단순한 사용자가 될수도 있습니다, 그리고 그래도 되요. 하지만 그런다면, 여러분에겐 해당 프로젝트에 대한 제어권이 없습니다. 이것 역시 완전히 괜찮습니다, 여러분이 정말 기본적인 운영체제를 원할 뿐이라면 말이죠, 그리고 리눅스는 이미 여러분이 필요한 모든걸 하고 있습니다. 하지만 여러분에게 특수한 요구사항이 있다면, 프로젝트에 영향을 끼치는 유일한 방법은 참여하는 겁니다.

이게 모두를 정직하게 만듭니다. 저를 포함해서요. 누구나 프로젝트를 포크 (fork) 해서 스스로의 방향으로 나아가고 “안녕히 리누스, 난 내 버전의 리눅스의 관리권을 가져갑니다” 라고 할 수 있습니다. 전 그저 사람들이 제가 일을 잘 할거라 믿기 때문에 - 그리고 그 믿음이 지속되는 동안만 - “특별” 합니다. 그리고 실로 그래야만 합니다.

이 “누구나 스스로의 버전을 관리할 수 있다” 부분이 어떤 사람들을 GPLv2 에 대해 걱정하게 만듭니다, 하지만 전 그건 강점이지 약점이 아니라 생각해요. 어떤 면에선 의도된 바는 아니지만, 전 그게 리눅스의 파편화를 막아준 것이라고 생각합니다: 모두가 각자의 포크 (fork) 를 소유할 수 있고, 그래도 됩니다. 사실, 그건 “Git” 의 핵심 설계 철학 중 하나입니다 - 저장소의 모든 복사본은 그 자체로 작은 포크 (fork) 이고, 사람들 (그리고 회사들) 이 그들 스스로의 포크를 만드는 것이 바로 개발 이 이루어지는 과정입니다.

그러므로 포크 (fork) 를 하는 건 문제가 아니예요, 그들로부터 좋은 부분들을 다시 머지할 수 있는 한 말이죠. 그리고 이게 GPLv2 가 해주는 일입니다. 포크하고 여러분 스스로의 일을 할 수 있는 권한을 갖는 건 중요합니다, 하지만 동전의 반대면도 똑같이 중요합니다 - 성공적이었다 여겨지는 포크를 다시 원본으로 병합 (merge) 할 수 있는 권리.

또다른 문제는 여러분에게는 이 작업흐름을 지원하는 도구도 필요하지만, 이를 위한 마음가짐 또한 가져야만 한다는 점입니다. 포크를 원본으로 병합하는 경우의 큰 장애물에는 단순한 라이센스 문제 외에도 “나쁜 혈통” 이 있습니다. 어떤 포크가 적대적 이유로 시작되었다면, 두개의 포크를 하나로 합치는 건 무척 어려울 수 있습니다 - 라이센스나 기술적 이유가 아니라 그 포크가 무척 험악했기 때문에요. 다시 말하지만, 전 리눅스가 그걸 잘 피했으며, 이는 우리가 항상 포크 하는 행위를 자연적인 것이라 여겼고, 그럼 어떤 포크에서의 작업이 성공적이었다 여겨질 때 이를 원본에 도로 병합시키고자 하는 행위 역시 자연스러운 행위가 된다는 점 때문이 크다고 생각합니다.

그러니까, 답변이 좀 옆길로 샜습니다만, 전 이게 중요한 점이라고 생각합니다 - 전 그 라이센스 선택을 전혀 후회하지 않아요, 왜냐하면 전 정말로 GPLv2 가 리눅스의 성공의 이유 중 큰 부분이라고 생각하거든요.

돈은 정말 그렇게나 대단한 동기부여장치는 아닙니다. 그건 사람들을 끌어모으지 않아요. 공동의 프로젝트를 가지고 해당 프로젝트에 있어 여러분이 정말로 완전한 파트너가 될 수 있다고 정말로 느끼는 것, 그것이 사람들을 동기부여 시킵니다, 제 생각에는요.

JA: 요즘 사람들이 소스코드를 GPLv2 아래 릴리즈 하면, 그건 보통 리눅스 때문입니다. 당신은 그 라이센스를 어떻게 발견했고, 다른 라이센스들을 검토해 보는데는 얼마나 많은 시간과 노력을 기울였나요?

LT: 그당시, 사람들은 여전히 BSD vs GPL 에 대한 격렬하게 불타는 전쟁을 벌이고 있었습니다 (부분적으로는 rms 가 사람들을 욕하는데 가진 재능이 이를 부추겼다고 생각합니다), 따라서 저는 제가 구독중이던 일부 usenet 뉴스그룹을 통해 (comp.arch 나 comp.os.minix 등) 라이센스 토론 중 일부를 봤습니다.

하지만 제가 GPLv2 를 선택한 두가지 주요 이유는 분명, 그저 gcc - 리눅스가 돌아가게 하는데 매우 주된 역할을 했습니다, 왜냐면 전 당연하게도 C 컴파일러가 필요했으니까요 - 와 제가 당시 다니던 대학교의 스웨덴말을 하는 (핀란드에서 스웨덴어는 작은 비주류층을 형성합니다) 컴퓨터학과 학생이었던 Lars Wirzenius (“Lasu”) 때문이었습니다.

Lasu 는 저보다 훨씬 더 라이센스 토론 등에 심취해 있었습니다.

제게 있어, GPLv2 의 선택은 큰 정치적 문제가 아니었습니다, 그건 주로 제 원래 라이센스가 임시 변통의 것이고 업데이트되어야 할 필요가 있다는 것에 대한 것이었고, 전 gcc 에 신세를 졌을 뿐더러 GPLv2 는 저의 “당신은 소스코드를 되돌려줘야 합니다” 기대에 부합하는 것이었습니다.

따라서 다른 라이센스를 만드는 것보다는 (또는 원래의 것을 수정하는 것 - 그저 “상업적으로 쓰이면 안됨” 부분만 제거하는 게 하나의 선택이 될 수 있었을 겁니다 - 보다는), 전 다른 사람들이 이미 알고 있는것을 고르고 일부 법률가들을 참여하게 하고 싶었습니다.

JA: 당신의 평범한 하루는 어떻습니까? 얼마나 많은 시간을 코딩, 코드 리뷰, 이메일 읽고 쓰기에 사용하나요? 그리고 개인적 삶과 리눅스 커널을 위해 일하는 사이의 균형을 어떻게 잡습니까?

LT: 요즘 저는 매우 적은 코드만을 작성합니다, 그런지 꽤 됐어요. 그리고 제가 코드를 작성하는 가장 흔한 상황은 어떤 특정한 문제에 대한 토론이 있을때 제가 제안하는 해결책을 설명하기 위함을 주목적으로 하는 패치를 만들어 보내는 때입니다.

달리 말하면, 제가 작성하는 대부분의 코드는 “보세요, 이렇게 하면 어떨까요” 하는데 매우 구체적인 예를 드는 패치에 가깝습니다. 무언가를 어떻게 해결하는가에 대한 고수준의 이론적 토론에 빨려들어가기가 쉽습니다, 그리고 어떤 해결책을 설명하는 최선의 방법은 많은 경우 전체가 아니라 약간의 코드를 작성하고 그걸 구체적으로 만드는 것임을 알고 있습니다.

저의 진짜 작업시간은 이메일을 읽고 쓰는데 쓰이기 때문입니다. 그건 대부분 소통을 하는 것이지, 코딩하는 게 아닙니다. 사실, 저는 지금과 같이 저널리스트나 기술 블로거들 등과 대화하는 종류의 것들을 말 그대로 제 업무시간의 한 부분으로 여깁니다 - 실제 기술적 토론에 비해 낮은 우선순위를 가질 수 있겠지만, 전 이런 종류의 일에도 적지 않은 시간을 사용합니다.

그리고, 맞습니다, 전 코드리뷰에도 시간을 씁니다만, 솔직히 제가 풀리퀘스트를 받는 시점에서는 해당 코드는 일반적으로 이미 여러 사람들에게 리뷰가 되어 있어야 합니다. 따라서 저는 여전히 패치들을 들여다 보긴 합니다만, 실제로는 그 패치에 대한 설명과 그 패치가 어떻게 제게 오게 되었는지에 대한 과정을 더 보는 경향이 있습니다. 그리고 제가 오랫동안 함께 일한 사람들에 대해서는 그것조차 하지 않습니다: 그들은 그들의 서브시스템의 메인테이너이고, 전 그들의 일을 마이크로매니징 하기 위해 존재하지 않습니다.

따라서 상당히 자주, 제 주된 일은 “거기 있는 것”, 취합 지점이 되는것, 그리고 릴리즈를 관리하고 강제하는 사람이 되는 것입니다. 달리 말하자면, 제 일은 일반적으로 낮은 수준의 코드보다는 관리 프로세스에 대한 것입니다.

JA: 당신의 작업 환경은 어떤가요? 예를 들어, 방해 없는 어두운 방을, 아니면 경치가 좋은 방을 선호하나요? 주로 조용한 곳에서 일합니까, 아니면 음악을 들으며 일합니까? 어떤 하드웨어를 주로 사용하나요? 터미널에서 ‘vi’ 를 사용해 코드리뷰를 하나요, 아니면 화려한 IDE 를 사용하나요? 그리고, 이 일을 위해 선호하는 리눅스 배포판이 있나요?

LT: 제 방은 완전히 어둡지는 않습니다만 제 책상 옆 창문에 블라인드를 닫아두고는 있는데, 밝은 태양빛을 (오레곤의 이맘때에는 흔치 않지만요) 원치 않기 때문입니다. 그러니 경치는 없어요, 그저 (혼잡한) 책상과 두개의 4k 모니터 그리고 책상 아래 고성능 데스크탑 컴퓨터 만 있습니다. 그리고 제가 밖에 있을 때 테스트를 하기 위해 두개의 랩탑이 있습니다.

그리고 저는 조용한데서 일하길 바랍니다. 전 기계식 디스크 드라이브의 - 지금으로부터 10년도 전에 SSD 만을 사용했기에 행복하게도 쓰레기통에 버렸죠 - 소음을 싫어해왔고 시끄러운 CPU fan 도 받아들일 수 없어요.

그리고 모든 일은 전통적인 터미널에서 합니다, ‘vi’ 를 사용하진 않지만요. 저는 “micro-emacs” 라고 불리는, 일부 키 바인딩이 비슷하단 점을 제외하면 GNU emacs 와 전혀 관련없는 혐오스런 것을 사용합니다. 전 헬싱키 대학에 있던 어린 시절부터 이것에 익숙해졌고, 이로부터 아직 졸업하지 못했어요, 조만간 그래야만 한다고 생각하지만요. 저는 몇년 전에 이 에디터에 (매우 약간의) utf-8 지원 기능을 추가했습니다만, 이젠 정말 이 도구의 나이가 보이기 시작하고, 80년대에 만들어졌다는 모든 징표를 보이고 있으며 제가 사용하는 버전은 90년대 중반부터 관리되지 않고 있는 한 fork 입니다.

헬싱키 대학은 이게 DOS, VAX/VMS 와 유닉스에서 동작한다는 이유로 이걸 사용했고, 그게 제가 이걸 소개받은 이유입니다. 지금 제 손가락은 이것에 너무 익숙해졌습니다. 전 이제 정말 관리되고 있고 utf-8 을 올바르게 지원하는 무언가로 옮겨타야만 합니다. 아마도 ‘nano’ 로 넘어갈 수 있겠죠. 하지만 제 과거의 쓰레기 작업물들은 제 늙은 손가락들에게 새로운 기술을 가르치도록 강제할 만한 것이 되진 않았죠.

그러니 제 데스크탑 환경은 매우 간단합니다: 몇개의 텍스트 기반 터미널이 열려 있고, 웹브라우저에 이메일이 (그리고 몇개 더 탭이 있는데, 대부분 뉴스와 기술 사이트를 열어둡니다) 열려 있죠. 전 충분한 데스크탑 공간을 갖길 원하는데, 제법 큰 터미널 윈도우들에 (전 터미널을 100x40 크기로 일단 띄우고 필요에 따라 크기를 조정해 나갑니다) 익숙하고, 여러 터미널을 나란히 띄워두기 때문입니다. 그래서 두개의 4k 모니터를 사용하죠.

전 제 컴퓨터에 페도라를 사용합니다, 그걸 “선호” 하기 때문은 아니고, 제가 거기 익숙하기 때문입니다. 전 배포판에 대해선 크게 신경쓰지 않습니다 - 제게 있어 그건 대부분 어떤 기계의 커널을 교체하고 그 위에서 일할 수 있게끔 리눅스를 설치하고 제 도구들을 셋업하기 위한 하나의 방법일 뿐입니다.

JA: 리눅스 커널 메일링 리스트 는 커널 개발이 공개적으로 일어나는 곳이고, 매우 소통량이 많습니다. 그 수많은 이메일을 어떻게 다루시나요? 메일링 리스트 외부에서 협업하고 소통하기 위한 다른 방법들을 알아보셨나요, 또는 당신이 하는 일을 위해 완벽한 간단한 메일링 리스트 같은게 있나요?

LT: 오, 전 커널 메일링 리스트를 직접 읽지 않아요, 수년째 그래왔어요. 그건 너무 너무 많아요.

커널 메일링 리스트의 핵심은 그게 모든 토론에 cc로 붙는다는 (음 - 여러개의 커널 메일링 리스트들 가운데 하나가요, 그리고 전통적인 lkml 리스트는 더 적당한 리스트가 없을 때 사용됩니다) 점입니다. 그리고 그런 방법으로, 새로운 사람이 토론에 참여하게 될 때, 그들은 커널 메일링 리스트를 봄으로써 과거 기록과 배경을 알 수 있는 거죠.

그러므로 저는 이 리스트를 구독하지만 제가 개인적으로 cc 되지 않은 모든 lkml 이메일은 자동으로 기록함으로 가게 해서 기본적으로는 전 그것들을 읽지 않게 해왔습니다. 하지만 이후에 어떤 문제가 제게 올라오면, 그 모든 토론은 필요해지기 전까지는 제 인박스에 있진 않았지만 제 이메일에 있기 때문에, 제게 보이게 되는 거죠.

요즘은 저는 lore.kernel.org 기능을 대신 사용하는데, 그게 잘 작동하기도 하고 그걸 바탕으로 만들어진 도구들도 몇가지 있기 때문입니다. 따라서 제 메일 저장함으로 자동으로 옮겨지도록 하는 대신, 토론들이 그 방법으로 보여지게 합니다. 하지만 기본적인 워크플로우는 개념적으로 동일합니다.

전 여전히 상당한 양의 이메일을 받습니다, 분명히요 - 하지만 여러 측면에서 수년간 상황이 좋아져 가고 있습니다. 그 중 큰 부분은 Git 과 커널 릴리즈 흐름이 잘 동작하고 있다는 점입니다: 우린 코드 흐름과 도구들에 대한 많은 문제들을 가져왔습니다. 제 이메일 상황은 20세기에서 21세기로 넘어오던 시절, 즉 여전히 거대한 패치 폭탄을 다뤄야 했고 개발 흐름에 큰 확장성 문제를 가지고 있던 때에는 정말 훨씬 훨씬 더 나빴습니다.

그리고 이 메일링 리스트 (와 이를 둘러싼 도구 사용) 모델은 정말 잘 동작했습니다. 이는 사람들이 이메일 (1대1 메일과 메일링 리스트) 에 더해 다른 소통 수단을 사용하지 않는다는 말이 아닙니다: 다양한 실시간 채팅을 (IRC 가 전통적인 수단이죠) 좋아하는 사람들이 있습니다. 전 그걸 사용하지 않았지만, 어떤 사람들은 브레인스토밍에 그걸 사용하는 걸 좋아하는게 분명합니다. 하지만 “저장소로써의 메일링 리스트” 모델은 매우 잘 동작하며, 모든 “개발자간에 패치를 이메일로 보내기” 와 “문제 보고서를 이메일로 보내기” 와 함께 매끄럽게 잘 동작합니다.

그러므로 이메일은 주요 소통 채널로 남아있고, 이메일에 패치를 포함시킴으로써 기술 문제를 토론하기 쉽게 합니다. 그리고 이건 여러 시간대에서 협업하는 환경에서도 잘 동작하는데, 이는 사람들이 지리적으로 흩어져 있을 때 매우 중요합니다.

JA: 전 대략 10년간 커널 개발 동향을 자세히 들여다보며 이를 KernelTrap 에 블로깅하고 새로운 기능이 발전될 때마다 그에 대해서도 글을 써왔습니다. 전 이를 8년간 지속된 2.6.x 버전을 이어 3.0 커널이 릴리즈 되던 즈음부터 그만뒀습니다. 3.0 릴리즈 후 커널에 일어난 더 흥미로운 일들 몇가지를 요약해 주실 수 있을까요?

LT: 헤헤. 그건 제가 요약을 시작할수도 없을 만큼 오래 전 일입니다. 3.0 이후 10년이 지났습니다, 그리고 그 시간 동안 많은 기술적 변화가 있었습니다. ARM 이 성장했고 ARM64 는 우리의 주요 아키텍쳐 중 하나가 되었습니다. 무척 많은 새로운 드라이버들과 핵심 기능들이 추가되었습니다.

지난 10년간 흥미로운 것이 있다면 우리가 실제 개발 모델을 어떻게 정말 매끄럽게 유지했는가, 그리고 무엇이 변화되지 않았는가일 겁니다.

우린 수십년간 여러 버전명 규칙과 개발 모델들을 사용해 왔지만, 3.0 릴리즈는 우리가 그간 사용해온 모델을 완성시켰습니다. “릴리즈는 시간 기반의 것임, 버전명의 숫자는 그저 숫자일 뿐이며 어떤 기능에 종속적이지 않음” 이라는 모든 원칙을 공식적이게 만든 것이죠.

우리는 이 시간 기반 릴리즈를 2.6.x 시대 머지 윈도우부터 시작했으므로, 그 부분은 새로운 건 아니었습니다. 하지만 3.0 은 “숫자가 의미를 가지는” 것에 대한 마지막 흔적을 지워버렸습니다.

우린 무작위 숫자 규칙을 가졌었고 (주로 1.0 전), “홀수 마이너 버전 숫자는 개발 커널을 의미하고 짝수 마이너 버전 숫자는 안정화된 제품 커널을 의미함” 모델을 사용했고, 그 후 2.6.x 시작과 함께 시간 기반 릴리즈 모델을 사용했습니다. 하지만 사람들은 여전히 “메이저 버전 숫자를 올리는 건 무슨 의미를 가질까” 라는 질문을 가지고 있었죠. 그리고 3.0 은 메이저 버전 숫자 또한 의미가 없음을, 우린 그저 숫자들이 쉽게 다룰 수 있도록, 너무 커지지 않도록 노력할 뿐임을 공식화 했습니다.

지난 10년간, 우린 분명 거대한 변화들을 만들었습니다 (Git 이 통계 숫자를 쉽게 볼 수 있게 해줍니다: 17,000여명의 개발자에 의해 만들어진 75만여개의 커밋). 하지만 그 개발 모델 자체는 정말로 상당히 매끄럽고 안정적이었습니다.

그리고 항상 그랬던 건 아닙니다. 커널 개발의 처음 20년간은 무척 고통스런 개발 모델 변화로 가득했습니다. 최근 10년은 릴리즈 측면에서 훨씬 예측 가능하게 되었습니다.

JA: 지금 기준으로 가장 최신 릴리즈는 5.12-rc5 입니다. 릴리즈 프로세스는 얼마나 표준화 되었나요? 예를 들어, 어떤 종류의 변경사항들이 -rc1, -rc2 등으로 들어갑니까? 그리고 어느 시점에서 당신은 해당 릴리즈가 공식적으로 이뤄질 준비가 되었다고 결정하나요? 만약 당신이 틀렸고 최종 릴리즈 후에 큰 퇴행적 문제가 발견되면 어떤 일이 벌어지며, 그런 일이 얼마나 자주 일어나나요? 이 프로세스는 수년간 어떻게 발전해 왔습니까?

LT: 전 이걸 앞에서 암시적으로 언급했습니다: 프로세스 자체는 정말 상당히 표준화 되었습니다, 그리고 지난 10년간 변하지 않았습니다. 그 전에는 여러번의 대격변을 거쳐왔습니다만 3.0 부터는 사실상 거의 시계장치처럼 되었습니다 (그리고 사실 그로부터 수년 전 - Git 으로의 전환이 여러 측면에서 오늘날의 프로세스의 시작이었으며, 모두가 거기 익숙해지기까진 시간이 조금 걸렸습니다).

그러니까, 제가 생각하기로는 우린 지금까지 대략 15년간 “2주일의 머지 기간” 에 이어 최종 릴리즈 전에 대략 6-8개의 주간 릴리즈 후보를 내놓기를 계속해 왔습니다.

그리고 그 규칙은 항상 동일했습니다, 항상 완전하고 엄격하게 강제된 건 아니었지만요: 머지 기간은 “테스트 되었고 준비되었다” 생각되는 새로운 코드를 위한 시간이고, 이어지는 대략 두달의 기간은 수정사항들을 받아들이고 모든 문제가 해결되었음을 확실히 하기 위한 시간입니다. 항상 그랬던 건 아니고, 어떤 때에는 “준비되었다” 여겨진 코드가 비활성화되거나 릴리즈 전에 완전히 제거되기도 했습니다.

그리고 이게 반복됩니다 - 그러니 우린 대략 매 10주 정도마다 릴리즈를 합니다.

그리고 이 릴리즈 기준은 제가 충분히 준비되었다는 자신감을 느끼는가로, 어떤 종류의 문제들이 여전히 보고되고 있는가에 기반합니다. 어떤 영역이 여전히 이 rc 게임 기준으로는 늦은 문제들을 보인다면, 전 문제에 연관된 변경사항들을 무효화 시켜버리고 “우린 이걸 완전히 이해한 후에 나중 릴리즈에서 처리합시다” 라고 말하는데 무척 적극적이 됩니다, 다만 전체적으로 이런 경우는 상당히 드뭅니다.

이게 항상 잘 동작할까요? 아니요. 커널이 일단 릴리즈 되면 - 그리고 특히 어떤 배포판이 그걸 일단 골라잡으면 - 새로운 사용자가 생기고, 개발 중에는 그걸 테스트 하지 않았던, rc 시리즈 기간에 우리가 발견하지 못했던, 제대로 동작하지 않는 것들을 발견해내는 사람들이 생깁니다. 이건 피할 수 없는 문제에 가깝습니다. 이게 우리가 릴리즈 후에 수정 사항들을 추가하는 “안정화 (stable) 커널” 트리들을 갖는 이유 중 하나입니다. 그리고 일부 안정화 커널들은 다른 것들보다 더 오래 관리되어서 LTS (“Long Term Support”) 커널이라 불립니다.

이 모든 것들이 지난 10년간 거의 변하지 않았습니다, 더 많은 자동화를 하게 되곤 했지만 말이죠. 커널 테스트 자동화는 일반적으로 어렵습니다만 - 부분적으로는 커널의 많은 부분이 하드웨어가 있어야 돌아갈 수 있는 드라이버들이기 때문이죠 - 부팅과 성능, 다양한 무작위적 부하 테스트를 하는 여러 곳이 존재합니다. 그리고 이게 수년간 상당히 개선되었습니다.

JA: 작년 11월에 당신은 애플의 새 컴퓨터들에 장착된 애플의 신형 ARM64 칩에 감명받았다고 알려졌습니다. 리눅스에서 그것들을 지원하기 위한 개발 노력을 팔로우 하고 있나요? 그걸 위한 작업물이 ‘for-next’ 에 머지된 걸 봤습니다. 조만간 나올 5.13 커널부터는 애플의 맥북 하드웨어가 리눅스로 부팅될 수 있을까요? 당신은 얼리어답터가 되곤 합니까? ARM64 는 얼마나 중요합니까?

LT: 저는 매우 가끔 그걸 체크합니다만, 아직 그 작업은 초기 단계에 있습니다. 당신도 이야기 했듯, 이 초기 지원 기능이 5.13 에 머지될 확률이 높습니다, 하지만 그건 그저 시작 단계일 뿐이란 걸, 그리고 아직은 리눅스를 가지고 애플 하드웨어를 유용하게 운용할 수 있게 만들 수준은 아님을 알아두셔야 합니다.

문제가 되는건 arm64 부분이 아니라, 그 주변에 위치하는 하드웨어를 (특히 SSD 와 GPU) 위한 드라이버들입니다. 지금까지, 그 초기 작업물은 일부 낮은 단계의 것들을 동작하게 만들어냈지만, 부팅 초기에 하드웨어를 사용 가능하게 하는것 외의 유용한 것은 어느것도 해내지 못했습니다. 사람들이 시도해 볼만한 진짜 선택 사항이 되기까지는 시간이 걸릴 겁니다.

하지만 개선된 건 애플 하드웨어만이 아닙니다 - arm64 를 위한 인프라는 상당히 발전했고, 그 코어는 서버 환경에서 “그저 그런” 수준을 넘어서서 훨씬 경쟁적인 것이 되었습니다. 얼마전만 해도 arm64 서버 환경은 무척 슬픈 상황이었습니다만, Amazon 의 Graviton2 와 Ampere 의 Altra 프로세서들은 - 둘 다 훨씬 개선된 ARM Neoverse IP 에 기반해 있습니다 - 수년전에 제공되던 것들에 비해 훨씬 낫습니다.

전 사용할 수 있는 ARM 기계를 이제 10년도 넘게 기다려왔습니다, 그리고 여전히 그 단계는 아니지만, 어느때보다도 그 때가 가까워진게 분명합니다.

사실, 전 제가 ARM 기계를 그보다도 훨씬 오랫동안 원해왔다고 말할 수 있다고 생각합니다 - 제가 10대이던 시절, 제가 정말 원했던 건 Acorn Archimedes 였는데, 구하기도 어렵고 가격도 비싸서 Sinclair QL (M68008 프로세서) 쪽으로 방향을 틀어야 했고, 수년 후에는 i386 PC 를 대신 사용했죠.

그러니 말하자면 수십년간의 개발이 이어졌습니다만, 그것들은 여전히 어디서나 구하기가 쉽지는 않고 컴퓨터로써의 가성비가 제게는 충분하지 않습니다. 어느 날인가는 그렇게 될겁니다. 바라건대, 너무 멀지는 않은 미래에요.

JA: 커널 내에 최적화 되어 있지 않으며 그걸 제대로 해결하려면 완전히 재작성해야 하는 부분이 있을까요? 달리 말하자면, 커널은 서른살이나 나이를 먹었고 지식, 언어, 그리고 하드웨어는 그 30년간 많이 바뀌었습니다: 만약 당신이 지금부터 무언가를 바닥부터 다시 작성한다면, 무엇을 바꾸겠습니까?

LT: 사실 우린 필요하다면 무언가를 완전히 재작성하는데에도 무척 훌륭했습니다, 따라서 해결되지 않은, 재앙이 될만한 것들은 재작성된 지 오래입니다.

물론, 우린 상당히 많은 “호환성” 계층들이 있습니다만, 그것들은 일반적으로 끔찍하지는 않아요. 그리고 설령 그것들을 바닥부터 재작성 한다고 해도 그 호환성 계층들이 사라질 것인지도 분명치 않습니다 - 그것들은 오래된 바이너리들을 위한 하위 호환에 대한 (그리고 종종 오래된 아키텍쳐, 예를 들어 32-bit x86 앱을 x86-64 에서 돌리는, 하위 호환을 위한) 것들입니다. 전 하위 호환을 매우 중요하다고 여기기 때문에, 저는 설령 재작성을 하더라도 그것들은 유지하고 싶습니다.

모든 것은 개선될 수 있다는 점에서 “최적화 되지 않은” 것들은 분명 많습니다, 하지만 당신의 질문의 논조를 놓고 보건대, 그 중 제가 경멸하는 것은 어느 것도 없다고 말해야겠습니다. 누구도 정리를 할만큼 신경쓰지도 않을, 따라서 추한 일들을 할지도 모르는 구식 드라이버들이 있습니다, 하지만 여기서 핵심은 “아무도 신경쓰지 않음” 입니다. 그건 문제가 되지 않아왔습니다, 그리고 그게 문제가 되는데 그게 우리가 그걸 신경쓸 사람을 찾을 수 없는 구식 지원이라면 그걸 제거해 버리는 데에 상당히 적극적이 되곤 합니다. 따라서 수년간 우리는 많은 수의 드라이버를 제거해 왔고, 더이상 유지보수할 의미가 없는 경우엔 아키텍쳐 전체 지원도 제거해 왔습니다.

“재작성” 의 유일한 주요 이유는 전체 구조가 더이상 말이 되지 않는 어떤 사용 사례를 찾았을 경우일 겁니다. 가장 있을법한 시나리오는 리눅스가 제공하는 모든 것을 필요로 하지 않는, 그리고 매우 적은 하드웨어 사용량을 가져서 지난 세월동안 거대해진 리눅스보다는 더 작고 간단한 무언가를 원하는, 어떤 작은 임베디드 시스템 같은 경우가 되겠습니다.

리눅스는 거대해졌으니까요. 오늘날에는 작은 하드웨어 (예를 들어 휴대폰을 생각해 봅시다) 도 리눅스가 처음 개발된 기계보다 훨씬 기능이 많습니다.

JA: 성능과 안전성을 위해 특별히 설계된 언어인 Rust 를 이용해 최소 일부 부분을 재작성하는 건 어떻게 생각합니까? 이 방법으로 개선해볼 곳이 있습니까? Rust 같은 다른 언어가 커널의 C 를 대체하는 것이 가능할 수는 있다고 느끼십니까?

LT: 우린 지켜볼 겁니다. 전 Rust 가 커널의 핵심부에 사용될 거라고는 생각지 않습니다, 하지만 개별 드라이버들 (그리고 어쩌면 전체 드라이버 서브시스템들) 을 그걸로 돌리는 건 완전히 불가능하게 들리지는 않습니다. 어쩌면 파일시스템도요. 그러니 “C 를 대체” 하는 건 아니지만, “말 되는 곳에서는 C 코드를 강화” 시키는 것에 가깝겠습니다.

물론, 특히, 드라이버는 실제 커널 코드의 절반 가량을 차지합니다, 따라서 Rust 로 개선할 공간이 많습니다, 하지만 누구도 현존하는 드라이버들을 대대적으로 Rust 로 재작성할 것이라 기대하진 않는다고, 그보다는 “어떤 사람들은 새 드라이버를 Rust 로 짤 수도, 몇몇개의 드라이버는 그게 말이 된다면 재작성될 수도 있겠다” 고 생각하는 편에 가깝습니다.

하지만 지금 당장의 상황은 “사람들이 그걸 시도해 보고 가지고 놀고 있다” 에 불과합니다. 장점을 내세우기는 쉽지만, 분명한 복잡성도 존재합니다, 따라서 저는 그 약속된 장점들이 정말로 실현될 것인지 기다리며 지켜보는 접근법을 취할 겁니다.

JA: 개인적으로 커널에서 가장 자랑스러운 특별한 부분이 있습니까?

LT: 제가 이야기 하곤 하는 부분은 VFS (“virtual filesystem”) 계층 (그리고 특히 pathname 탐색) 과 VM 코드입니다. 앞의 것은 리눅스가 그 기본적인 일들을 (pathname 을 탐색하는 건 운영체제의 매우 핵심 작업입니다) 현존하는 그 무엇보다도 훨씬 잘 하기 때문입니다. 그리고 뒤의 것은 우리가 20개 이상의 아키텍쳐를 지원하고, 우린 여전히 통합된 VM 계층으로 그걸 해내고 있는데, 제 생각에 이건 무척 인상적이기 때문입니다.

하지만, 이는 또한 “커널의 어떤 부분을 당신은 신경쓰십니까” 라는 질문이기도 합니다. 커널은 뭐가 가장 중요한지에 대해 다른 개발자들은 (그리고 다른 사용자들이) 다른 의견을 가질 수 있기 충분할 정도로 거대합니다. 어떤 사람들은 스케쥴링이 커널의 가장 짜릿한 부분이라 생각합니다. 또다른 사람들은 디바이스 드라이버의 핵심을 찌르는 부분을 (우린 그런 것들을 많이 가지고 있습니다) 좋아합니다. 전 개인적으로 VM 과 VFS 영역에 더 참여하는 경향이 있으므로, 자연적으로 그것들을 꼽게 됩니다.

JA: Pathname 탐색에 대한 설명 을 찾았는데, 제가 생각한 것보다 더 복잡하군요. 무엇이 리눅스의 구현을 다른 운영체제의 것들에 비해 훨씬 낫게 만듭니까? 그리고 “더 낫다” 는 말로 당신이 의미하는 건 뭡니까?

LT: Pathname 탐색은 커널 개발자 외의 대부분의 사람들은 그걸 문제라고 여기지도 않을 정도로 흔하고 기본적인 것입니다: 그들은 그저 파일을 열고 그 모든 걸 당연한 것으로 여기죠.

하지만 그건 정말 잘하기가 무척 복잡합니다. 모든 것들이 항상 pathname 탐색을 하기 때문에, 그건 무척 성능에 중요하고, SMP 환경에서 당신 역시 확장 가능하길 바라는 영역 중 하나일 것이 분명하고, 락킹 (locking) 관련한 복잡성이 높기 때문입니다. 그리고 당신은 어떤 IO 도 하고 싶지 않을 게 분명합니다, 따라서 캐쉬 사용이 매우 중요합니다. 사실, pathname 탐색은 그걸 낮은 단계의 파일시스템이 하도록 둘 수 없을 정도로 중요한데, 우린 20개가 넘는 다른 파일시스템을 가지고 있고 그것들이 각자의 캐쉬 사용과 락킹을 하도록 두는건 완전한 재앙이 될 것이기 때문입니다.

따라서 VFS 계층이 하는 주요 작업 중 하나는 pathname 요소들의 모든 락킹과 캐쉬 사용을 처리하고, 모든 직렬화와 mount point 횡단을 처리하고, 모든 일을 대부분 lock-free 알고리즘 (RCU) 으로 , 경우에 따라선 일부 무척 영리한 lock 같은 것들을 (리눅스 커널의 “lockref” lock 은 매우 특수한 “레퍼런스 카운트를 갖는 spinlock” 으로 말 그대로 dcache 사용을 위해 설계되었으며, 기본적으로는 많은 일반적 상황에서 lock 사용을 제거할 수 있는 특수한 락을 인지하는 레퍼런스 카운트입니다) 사용해 처리하는 것입니다.

결과: 낮은 단계의 파일 시스템들은 캐쉬에 올라오지 않은 것들을 위해선 여전히 탐색을 해야 하지만, pathname 탐색을 위한 캐쉬 사용과 모든 일관성 규칙들과 원자성 규칙들에 대해선 걱정하지 않아도 됩니다. VFS 가 그것들을 위해 이 모든 걸 처리합니다.

그리고 그건 모든 다른 운영체제들이 구현한 모든 것보다 성능이 나으며, 수천개의 CPU 를 가진 기계에서조차 기본적으로는 완전하게 확장됩니다. 그리고 그 기계들이 같은 디렉토리들을 건드는 경우에조차 그렇습니다 (루트 디렉토리나 프로젝트 홈 디렉토리 같은 것들에는 많은 수의 쓰레드로 돌아가는 어플리케이션이라 해도 쓰레드별 행동 같은 것으로 분산되지 않고 모두 동시에 접근하려 할 것이니까요).

따라서 이건 단순히 “더 나은” 게 아니라, “더 나은” 것입니다, ‘더’ 에 대한 강조와 함께 말이죠. 어떤 것도 여기 근접하지 않고 있습니다. 리눅스의 dcache 는 자신만의 클래스에 있습니다.

JA: 작년은 전세계적으로 힘든 해였습니다. COVID-19 판데믹은 커널 개발 프로세스에 어떤 영향을 끼쳤습니까?

LT: 실제로 매우 최소한의 영향만을 끼쳤습니다, 우리가 항상 일해온 방식 때문입니다. Email 은 실로 놀라운 도구임이 드러났고, 우린 대면 미팅에 의존하지 않았습니다.

그래요, 작년의 연간 커널 서밋에는 영향을 미쳤습니다 (그리고 올해도 불투명합니다 – 역자 주: 2021년 커널 서밋도 virtual 로 가게 되었습니다), 그리고 대부분의 컨퍼런스가 취소되거나 가상으로 전환되었습니다. 그리고 전에는 사무실에서 일하던 사람들이 집에서 일하기 시작했습니다 (하지만 많은 코어 커널 메인테이너들은 이미 그래왔습니다). 그러니 많은 것들이 바뀌었지만, 핵심 개발 그 자체는 전과 동일하게 동작했습니다.

그리고 그건 우리 모두의 삶에 다른 형태로 영향을 끼친 것 같습니다 - 그저 일반적인 사회적 영향이요. 하지만 전체적으로 보면 우린 이미 사람들과 거의 전부 이메일로만 소통해오던 커널 개발자들이었기에 가장 적게 영향받은 사람들일 겁니다.

분산 버전 컨트롤 시스템, Git

JA: 리눅스는 당신의 오픈소스에의 여기저기 퍼져있는 공헌들 가운데 하나에 불과합니다. 2005년에 당신은 또한 엄청나게 인기 있는 분산 소스 컨트롤 시스템인 Git 을 만들었죠. 당신은 리눅스 커널 소스 트리를 독점 소프트웨어인 Bitkeeper 에서 새로 만들어진 오픈소스 기반의 Git 으로 곧바로 옮겼고, 같은 해에 관리 권한을 Junio Hamano 에게 넘겼습니다. 여기에 매력적인 역사적 일들이 많이 있습니다, 무엇이 당신에게 이 프로젝트의 리더쉽을 그렇게 빨리 넘기도록 만들었으며, 당신은 어떻게 Junio 를 발견하고 선택했습니까?

LT: 이에 대한 답변은 두 부분으로 나뉠 수 있겠습니다.

첫번째 부분은 저는 새로운 소스 컨트롤 시스템을 만들고 싶지 않았다는 겁니다. 리눅스는 제가 하드웨어와 소프트웨어 간의 낮은 단계의 인터페이스가 매력적임을 발견했기 때문에 만들었습니다. 반면에, Git 은 필요에 의해 만들어졌습니다: 제가 소스 컨트롤이 흥미롭다고 여겨서가 아니라, 당시 존재하던 대부분의 소스 컨트롤 시스템을 경멸했고, 제가 발견한 입에 맞고 리눅스 개발 모델을 위해 상당히 잘 동작했던 것 (BitKeeper) 은 더이상 사용할 수 없게 되었기 때문이었습니다.

그 결과: 전 리눅스를 30년 넘게 개발하고 있습니다 (첫번째 릴리즈의 기념일은 아직 몇달 남았습니다만 전 리눅스가 될 것의 개발을 30년 전에 이미 시작했습니다), 그리고 그동안 이것을 계속 유지보수해 왔습니다. 하지만 Git 은요? 전 제가 그걸 장기적으로 유지보수하고 싶다고 한번도 생각하지 않았습니다. 전 그걸 사용하는 건 좋아합니다, 그리고 분명히 세계에 존재하는 최고의 SCM 이라고 생각합니다, 하지만 그건 제 근본적인 열정과 흥미가 아닙니다, 제가 말하고자 하는게 뭔지 안다면 이해하시겠죠.

그렇기 때문에 전 항상 누군가가 그 SCM 을 저를 위해 유지보수해 주기를 원했습니다 – 사실 애초에 그걸 만들 일도 없었다면 가장 행복했을 겁니다.

이게 말하자면 그 배경입니다.

Junio 에 대해 말하자면 - 그는 Git 개발자로 나선 바로 첫번째 사람들 가운데 한명이었습니다. 그는 제가 Git 의 첫번째 (그리고 매우 조악한) 버전을 공개한지 몇일만에 그의 변경사항들을 보내왔습니다. 그러니 Junio 는 실제로 Git 의 초창기부터 함께해 왔습니다.

하지만 제가 첫번째로 나타난 아무에게나 프로젝트를 넘긴 건 아니었습니다. 전 Git 을 몇달동안 유지보수했고, 제가 Junio 에게 그가 메인테이너가 되고 싶은지 물어보게끔 만든 것은 설명하기 어려운 “좋은 취향” 에 대한 것이었습니다. 이걸 위한 더 나은 설명을 저는 못하겠습니다: 프로그래밍은 기술적 문제를 해결하는 것입니다만, 그걸 어떻게 해결하는가, 그걸 어떻게 생각하는가 또한 중요하고, 그건 시간에 걸려 깨닫게 되는 것들 중 하나입니다: 많은 사람들이 그 “좋은 취향” 을 갖고 “옳은” 해결책을 고릅니다.

저는 프로그래밍이 예술이라 말하고 싶지는 않습니다, 그건 대부분 그저 “좋은 엔지니어링” 이기 때문입니다. 전 토마스 에디슨의 “1퍼센트의 영감과 99퍼센트의 땀” 이야기를 믿습니다: 그건 작은 디테일들과 매일 끙끙대는 일의 거의 본질입니다. 하지만 그 “영감” 부분도 존재합니다, 단순히 어떤 문제를 해결하는 것을 넘어서는 그 “좋은 취향” 이요 - 깨끗하고 훌륭하게, 그리고 그래요, 심지어 아름답게.

그리고 Junio 는 그 “좋은 취향” 을 가지고 있었습니다.

그리고 매번 Git 이 이야기 될 때마다, 전 그걸 아주 아주 분명하게 기억하려 노력합니다: 제가 Git 의 개발을 시작했고 그 핵심 아이디어들을 설계했을 거예요, 하지만 전 종종 그 부분만을 가지고 너무 많은 명성을 받습니다. 15년이 넘게 지났습니다, 그리고 전 그 첫번째 해에만 Git 에 참여했습니다. Junio 는 모범적인 메인테이너가 되었고, 그가 Git 을 오늘날의 모습으로 만든 바로 그 사람입니다.

그건 그렇고, 이 모든 “좋은 취향” 그리고 그걸 가진 사람을 찾는것, 그리고 그들을 믿는 것 - 그건 Git 에 대한 것만이 아닙니다. 그건 또한 리눅스의 역사이기도 합니다. Git 과 달리, 리눅스는 분명 제가 여전히 활발히 관리하는 프로젝트입니다만, Git 과 매우 유사하게, 많은 다른 사람들이 참여하는 프로젝트이기도 하고, 리눅스의 큰 성공의 이유 중 하나는 말 그대로 수백명의, 그 정의하기 어려운 “좋은 취향” 을 가진, 그리고 커널의 각 부분을 관리하는 메인테이너들을 가졌다는 점이라고 생각합니다.

JA: 어떤 메인테이너에게 권한을 줬지만 그건 잘못된 판단이었음이 드러난 적이 있나요?

LT: 우리의 메인테이너쉽 구조는 그렇게 흑백논리적이거나 경직되어 있던 적이 없기 때문에 그런 문제가 일어난 적은 없습니다. 실제로, 우린 심지어 메인테이너쉽 제어를 제대로 문서화 하지도 않았습니다: 우린 MAINTAINERS 파일을 가지고 있습니다, 하지만 그건 여러분이 옳은 사람들을 찾기 위함이지, 어떤 배타적 소유권의 표시가 아닙니다.

따라서 그 모든 “누가 무얼 소유하는가” 는 유동성 있는 가이드라인일 뿐이고, “이 사람이 활발히 활동 중이고 일을 잘 합니다” 에 가깝지 “앗, 우리가 저 사람에게 소유권을 줬는데 저사람이 일을 망쳤어” 같은게 아닙니다.

그리고 그건 여러분이 한 서브시스템의 메인테이너인데 다른 서브시스템에서 필요한 게 생긴다면 종종 그 영역을 가로지를 수도 있다는 점에서 유동적입니다. 물론, 사람들은 실제로 그러기 전에 매우 많은 대화를 먼저 합니다만, 핵심은 그런 일이 실제로 벌어지고 있으며, “너만이 그 파일을 만질 수 있어” 부류의 규칙이 아니란 겁니다.

사실, 이건 라이센스에 대해 이야기한 앞의 토론과 관계되어 있는 것이고, 어떻게 “Git” 의 설계 규칙 중 하나가 “모두가 각자의 트리를 가지고, 어떤 트리도 기술적으로 특별하지 않음” 이 되었는지에 대한 또다른 예입니다.

많은 다른 프로젝트들이 기본적으로 어떤 사람들을 특별하게 만드는 도구들 - CVS 나 SVN 같은 - 을 사용했기 때문에 그리고 그게 기본적으로 그와 함께 “소유권” 을 가졌기 때문입니다. BSD 세계에서는 그걸 “commit bit” 이라 부르죠: 메인테이너에게 “commit bit” 을 부여함은 그 사람은 이제 그 중앙 저장소에 (또는 그 중 한 부분에) 커밋을 할 수 있음을 의미합니다.

전 항상 그 모델을 싫어했는데, 그건 어쩔 수 없이 정치와, 어떤 사람들은 특별하고 암묵적으로 믿어지는 “파벌” 개발 모델을 초래하기 때문입니다. 그리고 문제는 “암묵적으로 믿어지는” 부분도 아닙니다 - 그건 사실 이 동전의 반대면으로, 다른 사람들은 믿음받지 못한다, 즉 정의에 따라 그들은 아웃사이더이며, 감시하에서만 움직일 수 있다는 겁니다.

다시 말하지만, Git 에서 그런 상황은 존재하지 않습니다. 모두가 동등합니다. 누구나 저장소를 복사할 수 있고, 각자의 개발을 하며, 훌륭한 일을 해냈다면 그건 도로 원본 저장소로 병합될 수 있습니다 (그리고 그들이 뛰어난 일을 해낸다면, 그들은 메인테이너가 되어, 그 병합 작업을 스스로의 트리에 하는 사람들 중 하나가 될 겁니다).

그러니 사람들에게 특별한 권한을 줄 필요가 없습니다 - 그 “commit bit” 은 필요 없습니다. 그리고 이는 또한 여러분이 정치행위를 방지하며, 암묵적으로 사람들을 믿을 필요도 없음을 의미합니다. 그들이 나쁜 일을 해버리는 경우가 생긴다면 - 또는 더 흔하게, 또다른 흥미를 찾아서 이 개발 커뮤니티에서 사라진다면 - 그것들은 도로 병합되지 않고, 신선한 새 아이디어를 가진 다른 사람들을 방해하지 않게 됩니다.

JA: Git 의 새로운 기능들이 당신에게 감동을 주고, 당신의 워크플로우의 한 부분을 차지하게 되곤 하나요? 추가되길 바라는 기능이 있습니까?

LT: 저의 사용처는 당연하게도 충족되어야 하는 첫번째 것이었습니다, 따라서 제게 있어 새로운 기능은 드물게만 필요했습니다.

수년간, Git 은 상당히 개선되었고 그 중 일부는 제 워크플로우에도 눈에 띄는 것이 되었습니다. 예를 들어, Git 은 항상 무척 빨랐습니다만 - 무엇보다, 그건 제 설계 목표 중 하나였습니다 - 그 중 많은 것들은 일부 코어 프로그램들 간의 상호작용을 이루어지게 하는 셸 스크립트를 통해 이루어졌습니다. 수년간, 그 셸 스크립트 작업 중 대다수는 사라졌는데, 이는 제가 Andrew Morton 으로부터 받은 패치 폭탄을 제가 원래 할 수 있던 것보다도 빠르게 적용할 수 있음을 의미합니다. 이건 매우 만족스러운 일입니다, 그건 실제로 제가 성능 테스트를 위해 사용하던 초기의 벤치마크 중 하나였으니까요.

그러니 Git 은 항상 제게 훌륭했지만, 더 나아져 가고 있습니다.

바라는 큰 개선사항은 “규칙적인 사용자” 로써 사용하기에 더 나아지는 것입니다. 그것은 Git 워크플로우를 배우는 사람들과 이제 막 그것에 익숙해진 사람들 (Git 은 사람들이 기존에 익숙한 CVS 나 다른 것들과 무척 다른 워크플로우를 갖습니다) 에 달려있던 것이지만, 그 중 많은 부분은 Git 자체가 사용하기 더 즐거운 것이 되어가는 것에 달려 있습니다.

---

두번째 파트는 여기서 보실 수 있습니다.