[번역] 10 Years of Git: An Interview with Git Creator Linus Torvalds

본문은 Git 탄생 10주년을 기념해 리눅스 재단에서 기획된 Linus Torvalds와의 인터뷰를 번역한 글입니다.
원문은 리눅스 재단에서 보실 수 있습니다.

10년전 오늘 리눅스 커널 커뮤니티는 큰 위기에 봉착합니다.

더 이상 BitKeeper와 소스 제어 시스템(SCM)만으로는 분산 시스템을 관리할 수 없었던 것이죠.

리눅스의 창시자인 리누스 토르발즈는 스스로 이 문제를 해결하기로 하고, 주말을 이용해 Git의 초기 버전을 만듭니다.

그 이후 Git은 눈부신 성장을 거듭합니다. 오늘날 수 천 개의 프로젝트가 Git을 사용하며, 이는 소셜 코딩의 새로운 지평을 열었습니다.

지난 10년 간의 성과를 치하하기 위해 리눅스 재단은 그를 초대하여 Git 탄생과 관련된 비하인드 스토리와 앞으로의 방향 그리고 Git이 소프트웨어 개발에 미친 영향에 대해 얘기해 보고자 합니다.

Git을 만들게 된 계기에 대해서 들려주세요

토르발즈: 저는 소스 제어 시스템 같은 걸 만들 생각이 없었습니다. 제게 소스 제어 시스템은 소프트웨어 개발에서 가장 따분한 분야였거든요. 시장에 존재했던 모든 종류의 SCM을 혐오하기도 했구요. 그러던 중에 BitKeeper(이하 BK)가 등장하면서 소스 제어에 대한 제 시각도 달라졌습니다.

BK는 꽤 많은 부분에서 괜찮았고, 저장소의 로컬 사본이나 분산된 머징 개념은 상당한 진보(big deal)였습니다. 가장 기본적인 아이디어는 각자에게 저장소를 제공하고, 이를 독립적으로 수정 가능하게 만드는 것이었습니다. BK는 이를 통해 SCM의 가장 근본적인 문제인 "누가 코드를 바꿀 수 있는가"와 같은 정치적 논쟁을 종식시킵니다.

물론 BK는 완벽한 시스템이 아니었습니다. 기술적인 제약 때문에 새로 이름 짓는 게 어렵다거나 하는 등 여러 작은 문제점이 있었죠. 하지만 BK의 가장 큰 단점은 BK가 오픈 소스 프로젝트가 아니라는 점이었습니다.

그 결과 리눅스 핵심 메인테이너들의 도입이나 오픈 소스 프로젝트에 대한 무료 혜택 제공에도 불구하고 BK는 널리 사용 되지 못했습니다.

그 뒤에 제가 Git을 만들게 된 결정적인 사건이 발생합니다.

Tridge(Andrew Tridgell), Larry McVoy와 함께 BK 프로토콜에 대한 리버스 엔지니어링을 시도했지만 잘 되지 않았던 일이 그것이죠.

그 결과 저는 더 이상 BK를 사용할 수 없겠다는 결론에 이릅니다. BK 이전으로 돌아가고 싶지 않았지만 기존의 소스 제어 시스템에도 만족할 수 없었습니다.

시장에 나와있는 SCM 중 몇몇은 분산 시스템을 흉내낸 무언가를 보여줬지만 그 어떤 것도 제대로 된 것은 없었습니다.

성능이나 코드 안정성 혹은 워크 플로우는 기대 이하였죠. 결국 저는 새로운 소스 제어 시스템을 만들기로 결심합니다.

Git의 작성 과정을 들려주시겠어요?

토르발즈: Git 프로젝트의 저장소를 보면 Git이 어떤 식으로 모양새를 갖춰 나갔는지를 볼 수 있습니다. 초기의 며칠을 제외하면 말이죠.

Git을 스스로 호스팅할 수 있게끔 만드는 데는 하루 정도면 충분했습니다: 그 과정이 끝난 뒤에는 Git을 이용해서 Git 코드를 올릴 수 있었죠.

흥미로운 점은 Git이 프로젝트가 얼마나 빠르게 지금의 모습을 갖추게 되었나 하는 것입니다.

Git은 적은 초기 커밋만으로도 이미 지금의 모습을 갖췄습니다. 오히려 가장 어려웠던 부분은 데이터를 어떤 식으로 조직할 건지에 대한 아이디어를 생각해내는 것이었죠.

Git은 10여일 정도 만에 세상에 나왔지만 많은 사람들이 상상하듯 며칠 밤낮을 새가며 작업 하지는 않았습니다. 초기 코드는 굉장히 작았고, 대부분 기본적인 기능을 제대로 구현하는 것에 집중됐기 때문이죠.

Git은 기대 이상의 프로젝트인가요?

토르발즈: 저는 Git에 굉장히 만족합니다. 리눅스 커널과 Git은 궁합이 잘 맞고, Git은 지금도 제 요구조건을 충족합니다.

흥미로운 점은 다른 많은 프로젝트들도 굉장히 빠른 속도로 Git을 도입했다는 점입니다. 소스 제어 시스템을 변경하려면 내부적인 관성을 이겨내는 지루한 과정을 거쳐야 하는데도 말이죠. 전통적인 CVS나 RCS가 얼마나 오랜 기간을 버티고 있는지를 생각해보세요. 놀랍게도 Git은 이를 극복하고 어느 순간부터 그들의 자리를 차지하게 되었습니다.

Git이 이렇게나 널리 사용 되는 이유는 뭐라고 생각하나요?

토르발즈: 다른 많은 개발자들도 SCM의 한계를 알고 있었습니다. 하지만 시장에 나온 솔루션은 Git과는 달리 부분적인 해결책 정도에 불과했죠.

Git의 강점은 Git을 한 번이라도 사용해본 사람들이 다시 SCM으로 돌아가지 않는다는데 있습니다.

분산 시스템의 중요성 같은 것들에 대해 알지 못하더라도, 쉽고 안정적인 백업, 중앙 저장소 엑세스 권한에 대한 걱정 없는 테스트 저장소를 사용할 수 있다는 사실을 알게 되면 다시는 SCM으로 돌아가지 않을테니까요.

Git의 미래에 대해 어떻게 생각하시나요?

토르발즈: 아마도 10 년 안에 새로운 소스 제어 시스템이 나타날 수도 있겠죠. 그래도 제 생각에 그 프로그램은 Git과 비슷한 시스템이 될 겁니다. Git이 모든 면에서 완벽하다는 얘기는 아니지만 지금까지는 Git처럼 기본적인 부분을 제대로 구현한 시스템이 없었다는 얘기가 되죠.

여기서 겸손을 떨지는 않겠습니다.

Git과 리눅스가 궁합이 좋은 이유가 뭘까요?

토르발즈: Git은 분명히 커널 개발자들의 워크플로를 위한 도구이고, 그게 한 가지 이유가 될 수 있을겁니다. 또 Git은 Linux와 같은 거대한 프로젝트에서 효율적으로 작동하게 끔 디자인되었습니다.

이 모든 일들이 Git 등장 이전에는 어려운 일이었습니다.

한 가지 예를 들어 봅시다. 전통적인 SCM에서 머징은 복잡한 일이었습니다. 머징를 할 때는 주의를 기울일 필요가 있었죠. 머징 그 자체가 굉장히 까다로운 일이었기 때문입니다.

저는 평소에도 굉장한 양의 머지를 합니다. 그런 상황에서 중요한 것은 머징을 하기 위해 에너지를 쏟기 보다는 결과를 테스트하는데 집중하는 것입니다. 그래서 저는 복잡한 머징 개념을 받아들일 수 없었습니다.

Git에서 머징은 몇 초 안에 이뤄집니다. 개발자들은 머징이라는 행위 자체보다는 머징 메세지를 작성하고 결과를 테스트하는데 더 많은 공을 들이죠. Git은 보시는 대로 자신의 역할을 훌륭히 해내고 있습니다.

Git이 소수의 똑똑한 사람만을 위한 도구라는 비판에 대해 어떻게 생각하시나요?

토르발즈: 예전에는 그렇다고 느낀 적도 있지만 지금은 그렇지 않습니다.

사람들이 그렇게 생각할만한 몇 가지 이유가 있긴 하지만 이제는 한 가지를 제외하고는 사라졌다고 생각합니다.

Git에는 "한 가지 일에 대해 무수히 많은 방법이 존재"하기 때문입니다.

Git에는 무수히 많은 기능이 존재하며, Git을 사용하는데 따르는 제약은 기술적인 것이라기 보다는 다른 사람과 함께 일하는데 따르는 제약입니다.

Git은 굉장히 강력한 도구이며, 이 때문에 배우기 까다로운 도구로 인식될 수 있습니다.

그러므로 Git을 배우는 가장 좋은 방법은 몇 가지 기본적인 것들에 대해서만 배우고 나서 기본기에 익숙해 지기 전까지는 더 어려운 개념을 배우지 않는 것입니다.

Git이 어려운 도구로 인식된 데에는 몇 가지 역사적인 이유도 있습니다. 한 가지 이유는 과거에 Git이 정말로 어려운 시절이 있었다는 것입니다. 초기 Git사용자들은 몇 가지 복잡한 스크립트를 이해해야만 했습니다.

또 초기에 Git은 중심 기능이 작동하게 끔 하는데 모든 노력을 기울였고 도구를 쉽게 만들거나 조금 더 직관적으로 만드는 데는 큰 노력을 기울이지 않았습니다. 그 결과 Git을 사용하려면 Git이 무슨 일을 하는지를 알아야만 한다는 오명이 씌워 졌습니다. 물론 Git이 나오고 6개월에서 1년 간은 맞는 말이기도 했죠.

많은 사람들이 Git을 어려워하는 또 다른 이유는 Git이 굉장히 다른 종류의 도구이기 때문입니다. Git 이전에 사람들은 CVS와 같은 도구를 10년 이상 써 왔습니다. 하지만 Git은 CVS와는 전혀 다릅니다. 기본적인 컨셉이나 커맨드는 물론이고, Git은 CVS와 지향점 자체가 다릅니다. 그렇기 때문에 CVS와 같은 시스템을 오랜 기간 사용해 왔다면 Git을 어렵고 복잡한 시스템으로 느낄 수 있습니다.

몇몇 사람들은 Git이 CVS의 "1.3.1" 같이 딱 떨어지는 예쁜 리비전 번호 대신 40 글자 짜리 HEX 코드로 된 커밋 id를 사용하는 이유가 무엇인지 궁금해 합니다. 이 변화가 "아무 의미 없이" 일어난 것은 아닙니다. (역자 주: 분산 시스템과 중앙 집중형 시스템의 차이) 하지만 이런 차이점으로 인해 몇몇 사람들은 Git이 필요 이상으로 복잡하다고 느끼게 됐습니다.

그럼에도 긍정적인 것은 CVS 경험이 점점 사라지고 있다는 점입니다. CVS를 전혀 사용해 보지 않은 새로운 프로그래머들이 나타나고 있고, 이들은 CVS를 굉장히 어려운 시스템이라고 생각할 겁니다. 그들에게는 Git이 처음으로 접한 시스템이기 때문이죠.

Git 없이도 현재와 같은 수준의 커널 개발이 가능했다고 생각하나요?

토르발즈: Git없이는 힘들었을 겁니다. 아마도 다른 누군가가 Git과 같은 종류의 프로그램을 작성할 필요가 있었겠죠. 커널 개발에는 Git과 같은 프로그램이 절실하게 필요했습니다.

Github에 대한 의견을 들려주세요

토르발즈: Github는 훌륭한 호스팅 플랫폼입니다. 그 점에 대해서는 전혀 불만이 없습니다.

하지만 개발 플랫폼으로서의 Github는 여전히 제대로 작동하지 않고 있다고 생각합니다.

커널과 같은 시스템에 비하면 Github는 아직 걸음마 단계라고 생각합니다. 기능적인 제약이 너무 많아요.

그 이유는 Github의 웹 인터페이스가 부실하기 때문입니다. Github 웹 인터페이스를 통해 커밋을 하면 나쁜 커밋 메시지를 작성하기 일쑤입니다.

많은 부분이 개선되고 있지만 리눅스 커널 개발과 같은 프로젝트를 위해서는 절대로 충분하지 않다고 생각합니다.

Git 혹은 Github를 활용한 가장 흥미로운 프로젝트는 어떤 것인가요?

토르발즈: 저는 Git이 새로운 프로젝트를 시작하는 것을 얼마나 쉽게 만들었는가에 놀랍니다.

프로젝트를 호스팅하는데 걸리는 시간과 노력은 Git 이전에 비하면 현저히 줄어들었죠.

현재 계획 중인 사이드 프로젝트가 있나요?

토르발즈: 현재 계획된 것은 없습니다. 생기게 된다면 말씀드리도록 하죠.