Two decades of Git: A conversation with creator Linus Torvalds - https://www.youtube.com/watch?v=sCr_gb8rdEI

Git이 자체 호스팅될 만큼 발전해 초기 커밋을 작성한 지 20년이 되어갑니다. 20년 후에도 여전히 Git을 사용하고 이에 대해 이야기하고 있을 거라고 예상하셨나요? 여전히 사용하고 있다는 건 예상했지만, 이야기하고 있을 줄은 몰랐죠. 가장 큰 놀라움 중 하나는 Git이 버전 관리 세계를 얼마나 장악했는지였습니다. 제 문제를 해결하기 위한 솔루션으로 보았기 때문에 당연히 우수하다고 생각했죠. 정확히 20년 전 오늘, 첫 버전이 솔직히 말해 꽤 거칠었음에도 불구하고, CVS보다 우수하다고 생각했습니다. 그렇지만 동시에 CVS가 시장을 계속 장악하고 있는 것을 봤죠. SVN이 등장했지만 그건 그저 CVS를 다르게 포장한 것에 불과했습니다. 수십 년 동안 그랬죠. 그래서 저는 이 시장이 매우 고착화되어 있다고 생각했습니다. CVS를 정말 싫어해서 사용할 수 없었고, BitKeeper도 더 이상 사용할 수 없게 되었죠. 그래서 제가 직접 무언가를 만들어야겠다고 생각했습니다. 그래서 저는 "좋아, 뭔가를 만들어보자"라고 생각했죠.그건 나한테 잘 맞고 다른 사람들은 신경 쓰지 않을 거예요. 그리고 그게 바로 드러났죠. 처음 몇 달과 몇 년 동안 사람들은 사용하기 어렵고 직관적이지 않다고 불평했어요. 맞아요. 그러다 뭔가가 일어났죠, 마치 스위치가 켜진 것처럼요. 네, 당신이 비트키퍼를 언급했는데요. 그것에 대해 조금 이야기해볼까요? 꽤 유명한 이야기인데, 당신이 git의 초기 버전을 약 10일 만에 커널의 대체품으로 작성했다고 하죠. 네 그렇고 아니에요. 사실은 10일보다 적게 걸렸어요. 음, 커널에 사용할 수 있을 때까지는 10일 정도 걸렸죠. 네, 하지만 공정하게 말하자면, 전체 과정은 시작되었죠 전년도 12월이나 11월 즈음에요. 그러니까 2004년에 일어난 일은 비트키퍼가 항상 나에게 꽤 잘 작동했다는 거예요. 완벽하진 않았지만, 내가 시도해본 다른 것들보다 훨씬 앞서 있었죠. 하지만 커널 커뮤니티에서 비트키퍼는 항상 완전히 환영받지는 못했어요. 상업적이었기 때문이죠, 오픈소스 사용에는 무료였어요. 래리 맥보이가 오픈소스를 정말 좋아했기 때문이죠, 맞아요? 그는, 동시에 그것을 중심으로 사업을 만들고 있었고 비트키퍼를 판매하고 싶어 했죠대기업들에게는 좋았습니다. 하지만 오픈소스가 아니면서 가장 큰 오픈소스 프로젝트 중 하나에 사용된다는 점이 많은 사람들에게 걸림돌이 되었습니다. 저도 마찬가지였죠. 어느 정도 오픈소스를 정말 사용하고 싶었지만, 동시에 매우 실용적이었고 오픈소스 중에는 충분히 좋은 것이 전혀 없었습니다. 그래서 더 나은 무언가가 나오기를 바라고 있었죠. 하지만 실제로 일어난 일은 호주의 Tridge가 기본적으로 BitKeeper를 리버스 엔지니어링한 것이었습니다. 그리 어렵지 않았죠. BitKeeper는 내부적으로 SCCS를 감싼 좋은 래퍼였기 때문입니다. SCCS는 60년대로 거슬러 올라가는데, SCCS는 거의 CVS보다 더 안 좋습니다. 거의 CVS보다 더 나쁘죠. 하지만 그것은 명백히 BitKeeper의 라이선스 규칙을 위반한 것이었습니다. BitKeeper는 오픈소스에 사용할 수 있지만, 리버스 엔지니어링을 하거나 BitKeeper를 클론하려고 시도해서는 안 된다고 했거든요. 그래서 큰 문제가 되었습니다. 우리는... 이것은 사적인 일이었죠. 저는 Larry와 대화하고 Tridge와 이메일을 주고받으며 해결책을 찾으려 노력했습니다. 우리는 해결책을 찾으려고 노력했죠.하지만 트리지와 래리는 완전히 상반된 입장이었습니다. 그리고 해결책이 나오지 않았습니다. 그래서 제가 Git을 작성하기 시작했을 때는 이미 4개월 동안 이 문제에 대해 생각해왔고,  제게 어떤 것이 효과적일지, 어떻게 BitKeeper보다 더 나은 것을 만들 수 있을지 고민했습니다. 하지만 BitKeeper와 같은 방식으로 하고 싶지는 않았습니다.  래리가 "너는 하지 말았어야 할 일을 했어"라고 말하는 상황을 원치 않았기 때문입니다. 그래서 실제 작성 부분은 커널에 Git을 사용하기 시작할 때까지 약 10일 정도 걸렸지만, 아이디어가 어떤 것이어야 하는지에 대해 많은 정신적 고민이 있었습니다. 그 10일 기간에 대해 이야기해보고 싶습니다. 제가 알기로는 그 기간 동안 커널에서 벗어나 Git에만 집중하셨다고 들었습니다. 커널이 아닌 Git에만 집중하는 것은 어떤 경험이었나요? 2주밖에 되지 않아서 큰 문제는 아니었습니다. 지난 35년 동안  이런 식으로 일한 적이 있었기 때문입니다.휴가를 몇 번 갔었죠? 많이는 아니지만, 커널 작업에서 2주 정도 떠난 적이 있습니다. 그리고 그게 꽤 흥미로웠어요 제 반응 중 하나는 사용자 프로그래밍이 얼마나 더 쉬운지였죠. 신경 써야 할 것이 훨씬 적습니다. 메모리 할당에 대해 걱정할 필요가 없고, 많은 것들을 신경 쓸 필요가 없죠. 디버깅도 훨씬 쉬워요. 모든 인프라가 있으니까요. 그래서 실제로 약간... 완전히 편안하다고는 못하지만, 재미있었어요 사용자 공간에서 뭔가를 할 수 있어서 제가 원하는 것이 꽤 명확했거든요.  방향은 알았지만 세부사항은 몰랐다는 의미에서요 그리고 또 하나 얘기하고 싶은 게 있는데, git에 대해 20년이 지난 지금 흥미로운 점은 그것이 장려하는 개발 모델이 너무나 단순해서 이제는 거의  당연한 것처럼 보인다는 거예요. 하지만 이건  평가절하하는 말이 아닙니다. 버전 관리의 온갖 아이디어에서 git으로 정제하는 데에는  많은 고민이 있었을 거예요. 얘기해주세요, 어떤당시에 우리가 현재의 결과를 얻기 위해 내린 불분명한 선택들이 있나요? 지금은 당연해 보이지만, 당시에는 그렇지 않았습니다. Git을 사용하기 어렵다고 느낀 이유 중 하나는 대부분의 사람들이 Git을 처음 사용할 때 CVS와 같은 배경에서 왔기 때문입니다. 그리고 Git의 사고방식은... 나는 파일 시스템 전문가 관점에서 접근했습니다. 나는 대부분의 소스 컨트롤 관리 프로젝트에 대해 경멸과 거의 증오에 가까운 감정을 가지고 있었습니다. 그래서 현상 유지에는 전혀 관심이 없었죠. 제게 가장 큰 문제는... 음, 두 가지 큰 문제가 있었습니다. 하나는 성능이었습니다. 왜냐하면 그 당시에 저는 여전히 많은 패치를 적용했는데, 지금은 Git으로 인해 거의 사라졌죠. 이제는 그냥 다른 사람의 코드를 병합하니까요. 하지만 제게 목표 중 하나는 패치 시리즈를 적용할 수 있는 것이었습니다. 기본적으로 30초 안에, 심지어 50개나 100개의 패치라도 말이죠. 커피 한 잔 마실 시간도 필요 없어야 했습니다. 맞아요, 정확히 그렇죠. 그게 제게 중요했던 이유는 삶의 질과 관련된 문제였기 때문입니다. 만약 일이 너무 오래 걸린다면...잠깐 실수가 발생하면, 즉시 결과를 보고 계속 진행하면서 수정할 수 있습니다. 다른 프로젝트들은 패치 하나당 30초 정도 걸렸는데, 이는 제게 용납할 수 없는 수준이었죠. 커널은 꽤 큰 프로젝트이고 많은 SCM들이 단순히 확장성을 고려해 설계되지 않았기 때문입니다. 그래서 그게 문제 중 하나였죠. 하지만 제가 정말로 필요했던 건 분산형이면서도 매우 안정적인 시스템이었습니다. 사람들은 SHA1 해시 사용이 큰 실수라고 생각하는 경향이 있죠. 하지만 제게 SHA1 해시는 보안이 아닌 손상을 찾기 위한 것이었습니다. BitKeeper 사용 중에 실제로 그런 일이 있었거든요. BitKeeper는 CRC와 MD5를 사용했지만 모든 곳에 사용하지는 않았습니다. 그래서 제 초기 설계 중 하나는 모든 것을 매우 강력한 해시로 보호하는 것이었습니다. 그게 전체 프로젝트를 이끌었죠. 두세 가지 정말 근본적인 설계 아이디어가 있었는데, 그래서 처음에는저수준의 Git은 사실 꽤 단순합니다. 그리고 복잡성은 세부사항과 사용자 인터페이스, 그리고 수행해야 하는 모든 것들에 있습니다 모든 사람들이 미친 짓을 하길 원하기 때문에 그렇게 할 수 있어야 합니다. 하지만 몇 가지 핵심 개념을 가진 저수준 설계를 갖는 것이 더 쉽게 작성할 수 있게 만들었고 생각하기도 훨씬 쉽게 만들었으며, 또한 어느 정도 사람들에게 아이디어를 설명하기 쉽게 만들었습니다. 그리고 저는 이것을 Unix와 비교합니다. UNIX는 모든 것이 프로세스이고, 모든 것이 파일이라는 핵심 철학을 가지고 있습니다. 여러분은 이것들 사이에서 파이프로 연결합니다. 그리고 실제로는 그렇게 단순하지 않습니다. 즉, 철학의 근간이 되는 단순한 개념들이 있지만, 모든 세부사항은 매우 복잡합니다. 그리고 저는 이것이 제가 처음에 UNIX를 높이 평가하게 된 이유라고 생각합니다. 네. 그리고 Git도 비슷한 면이 있다고 생각합니다. 설계에 근본적인 핵심 단순성이 있고 그 다음에 구현의 복잡성이 있습니다. UNIX에서 Git이 설계된 방식으로 이어지는 맥락이 있습니다. 네, 맞습니다. SHA1을 언급하셨는데요. 제가 생각하는 것 중 하나는 Git의 첫 번째 버전을 개발하던 1-2주 동안 여러분이 많은 결정을 내렸다는 것입니다. 이 결정들이 일종의우리와 함께 있었죠. 네. 혹시 SHA-1을 포함해서 후회하거나 다르게 했으면 좋았을 것들이 있나요? 음, SHA-1은 후회돼요. 불필요한 혼란을 많이 야기했다고 생각하거든요 SHA-256도 지원하려고 하면서요. 왜 그렇게 됐는지는 이해하지만, 대부분 무의미했다고 봅니다. 실제로 큰 필요성은 없었는데 사람들이 걱정해서 그렇게 된 거죠. 많은 노력이 낭비됐다고 봐요. 다른 작은 문제들도 있어요. 제가 인덱스 파일 항목 정렬 방식에서 실수를 했다고 생각해요. 이런 사소한 세부사항들이 일을 더 어렵게 만들었죠. 하지만 동시에 이런 것들은 대부분 고칠 수 있지만, 너무 작아서 크게 중요하지 않아요. 복잡성은 다른 곳에 있죠. 네. 후회가 별로 없으신 것 같네요. 좋은 거 같아요. 그 2주 동안에 혹시 하려는 게 될지, 완성될지, 쓸 만할지 확신이 없었던 순간이 있었나요? 아니면 항상 명확했나요? 저는 꽤 명확한 생각이 있었어요.초기 단계에 대한 명확한 아이디어는 있었지만 장기적으로 어떻게 작동할지는 확실하지 않았습니다. 솔직히 첫 주 후에는 패치를 적용하는 데는 좋았지만 다른 것들에는 그다지 좋지 않았습니다. 병합을 위한 기본 사항과 그에 필요한 데이터 구조는 갖추고 있었지만 실제로 첫 병합을 하는 데는 추가로 일주일이 더 걸렸던 것 같습니다. 거기에는 여러 가지 문제가 있었는데, 저는 큰 그림의 최종 결과는 염두에 두고 있었지만 그곳에 도달할 수 있을지는 확실하지 않았습니다. 네, 첫 단계들, 즉 첫 1-2주 동안은 코드를 보면 알 수 있듯이, 그리고 사람들도 봤겠지만 복잡한 코드는 아닙니다. 아니죠. 첫 버전은 약 10,000줄 정도였던 것 같은데 한 번에 거의 다 읽을 수 있는 분량입니다. 네. 꽤 간단하고 오류 검사 같은 것도 많이 하지 않습니다. 정말로 이것을 작동시키는 데 집중했죠. 왜냐하면 더 중요하다고 생각하는 다른 프로젝트로 돌아가야 했기 때문입니다. 정말로 그랬습니다. 제 말은, 그리고 실제로 그렇게 되었는데 제가 도달하고자 했던 지점에 이르렀을 때일부 변경이 필요한 문제에 부딪혔습니다. 첫 번째 버전에서는 그렇지 않았죠. 결국 우리는 한 시점에 하위 호환성이 없는 객체 저장소 전송을 수행했던 것 같습니다. FSCK가 일부 오래된 객체에 대해 불평합니다. 데이터 형식을 변경했기 때문입니다. 그게 어디서 왔는지 몰랐어요. 네. 그래서 문제가 있었던 것들이 있었죠. 첫 번째 버전은 필요한 모든 것을 수행하지 않았습니다. 네. 그리고 실제로 변환을 했는지 기억이 나지 않습니다. 변환이 필요 없었을 수도 있어요. 네. 그리고 커널의 몇몇 객체에 대해 약간의 경고만 있습니다. FSCK가 "이건 더 이상 지원되지 않는 오래된 형식입니다"라고 말하는 정도죠. 하지만 전반적으로 정말 잘 작동했습니다. 놀랍게도요. 네. 큰 문제는 항상 사람들의 수용이었죠. 맞아요. 그리고 그건 오랜 시간이 걸렸습니다. 네. 우리는 병합이 어떻게 구현되었지만 2주차나 3주차까지 기능하지 않았는지에 대해 조금 이야기했습니다. 다른초기 버전에서 제외했지만 나중에 프로젝트에 필수적이라고  깨달은 기능들이 있나요? 사실 나중에 깨달았다기보다는 내가 신경 쓰지 않았던 것들이었죠. 하지만 이게 어딘가로 갈 거라면 누군가는 신경 쓸 거라는 걸 알았어요. 처음 일주일 동안 커널에 사용할 때는 지금은 plumbing 명령어라고 불리는 걸 그대로 수동으로 사용했어요. 아무것도 없었죠. 이른바 porcelain도 없었고, 그 위에  사용 가능하게 만드는 것도 없었어요. 커밋을 하려면 매우 난해한 작업들을 해야 했죠. Commit tree예요. 네, commit tree죠. 그게 그냥 SHA를 반환하면 당신이 직접 head 파일에 써넣어야 했어요 그게 다였죠. 첫 버전에 hash object가 있었나요? 그게 제가 가진 첫 바이너리 중 하나였던 것 같아요 거기서 모든 걸 수동으로 해시할 수 있는지 확인하고 표준 출력으로 해시를 반환했죠. 그러면 원하는 대로 할 수 있었어요. 하지만 초기 porcelain은 이런 사용하기 어려운 것들을 쉘 스크립트로 감싸는 정도였어요 사용하기 정말 어려웠죠. 솔직히 제 쉘 스크립트로도 쉽게 사용할 수 없었어요셸 스크립트입니다. 하지만 공정하게 말하자면, 초기 목표 대상은 BitKeeper를 사용하지 않았던 상당히 핵심적인 커널 개발자들이었습니다. 그들은 적어도 제가 목표로 하는 많은 개념들을 알고 있었고 사람들이 이를 받아들였습니다. 제 생각에는 오래 걸리지 않아 다른 커널 개발자들이 실제로 사용하기 시작했습니다. 그리고 일부 버전 관리 시스템 전문가들이 얼마나 빨리 관심을 보였는지 놀랐습니다. 첫 번째 Git 버전이 공개된 지 며칠 만에 외부에서 패치를 받기 시작했습니다. 우리는 Git의 첫 몇 주에 대해 많이 이야기했습니다. 조금 앞으로 넘어가 보겠습니다. 프로젝트 초기에 June에게 관리를 넘기기로 결정하셨죠. 그가 프로젝트를 운영하는 것과 커뮤니티가 그와 상호 작용하는 것을  이 모든 세월 동안 약간 거리를 두고 지켜보신 소감이 어떠신지 말씀해 주시겠습니까? 솔직히 말해서, 저는 Git을 3-4개월 정도 유지보수했습니다. 8월 즈음에 넘겼던 것 같습니다. 그리고 넘길 때는 정말로 완전히 넘겼습니다. 저는 이렇게 생각했죠,저는 여전히 남아있습니다. 예전에는 git 메일링 리스트를 읽곤 했는데, 이제는 더 이상 하지 않습니다. 주니오는 제게 뭔가 물어보면 제가 괜찮을지 확인하고 싶어 했습니다. 하지만 동시에 저는 이것이 내가 하고 싶은 일이 아니라고 생각했죠. 아직도 어리석다고 느낍니다. 제 큰 딸이 대학에 갔는데 두 달 후 문자를 보내왔습니다. 그 내용은 컴퓨터 과학 실험실에서 저는 리눅스보다 Git으로 더 유명하다는 것이었습니다. 거기서 모든 것에 Git을 사용하기 때문이죠. 저는 Git이 제게 큰 의미가 없었다고 말했습니다. 그저 커널 작업을 위해 필요해서 만든 것뿐이었죠. 그리고 좀 우스운 점은, 제가 4개월 동안 유지보수를 했지만, 20년이 지난 지금, 여러분은 제게가 아니라 주니오에게 물어봐야 합니다. 그가 훌륭하게 일을 해왔고 저는 그 결과에 매우 만족합니다. 솔직히 말해서, 저는 인터넷에서 오랫동안 사람들과 일한 경험 덕분에 4개월 동안 유지보수를 하면서 누가 좋은 안목을 가졌는지 꽤 잘 파악할 수 있었습니다. 좋은 유지보수자가 될 수 있는 사람을요.당신에게는 취향의 문제겠죠. 저에게는 설명하기 어려운 부분이에요. 네, 당신은 해야 해요. 부분적으로 볼 수 있죠. 다른 사람의 코드에 대한 반응이나 그들의 사고방식에서 볼 수 있어요. 그리고 그는 프로젝트의 첫 번째 사람은 아니었지만, 초기 멤버 중 한 명이었어요. 제가 공개한 지 거의 첫 주부터 참여했죠. 그래서 그는 초기 멤버 중 한 명이었어요. 하지만 '너가 첫 번째니까 너야'라는 식은 아니었어요. 더 정확히는, '이 사람이 3개월 동안 일하는 것을 봤고, 나는 이 프로젝트를 유지보수하고 싶지 않아. 그에게 메인테이너가 되고 싶은지 물어볼 거야'였죠. 처음에는 좀 긴장했던 것 같아요. 하지만 정말 잘 해냈죠. 네, 그는 확실히 프로젝트를 매우 훌륭하게 운영했어요. 네, 저에게 취향은 매우 중요해요. 하지만 실질적으로, 20년 동안 프로젝트에 남아있었다는 사실이 더 중요한 부분이에요. 맞아요. 그리고 그는 물어봐요. 네, 그는 트리의 거의 모든 영역에 대해 놀라울 정도로 잘 알고 있어요. 거의 모든 영역에 대해 놀라울 정도로 지식이 풍부해요. 좋아요, 우리는 초기 Git에 대해 많이 이야기했네요. 이제 Git의 중기에 대해 조금 이야기해보고 싶어요.이 도구에 대해 제가 매우 흥미롭게 생각하는 점 중 하나는, 얼마나 보편화되었는지를 고려할 때, 분명히 효과적이었다는 것입니다 커널 개발을 돕는 데 있어서, 하지만 또한 매우 효과적이었습니다 노트북으로 작은 수업 프로젝트를 작성하는 대학생들에게도. Git의 어떤 특별한 점이  소프트웨어 엔지니어링 스펙트럼의 양 극단에서 모두  효과적이었다고 생각하시나요? 분산된 특성이 정말로 많은 것들을 매우 쉽게 만들었습니다. 그리고 그것이 Git을 다른 모든, 사실상 모든 이전 SCM들과 구별짓는 큰 부분 중 하나였죠. 네, 맞아요. 분산 SCM들이 있긴 했지만, 제가 아는 한, 그것이 가장 중요한 설계 목표였던 것은 없었습니다. 다른 주요 목표들과 함께,  Git으로 순수하게 로컬에서 작업할 수 있고 나중에 다른 곳에서 사용 가능하게 하고 싶다면 매우 쉽습니다. 그리고 이는 CVS와는 매우 다릅니다. CVS에서는 작업하기 위해 이런 중앙 집중식 저장소를 설정해야 하고, 만약 다른 곳으로 옮기고 싶다면, 그것은 매우 어렵습니다.매우 고통스럽고 다른 사람과 공유할 수 없습니다 추적을 잃지 않고는 말이죠. 전통적인 SCM을 사용할 때는 항상 특별한 저장소 하나가 있어야 합니다. Git이 그렇게 하지 않았다는 사실, 의도적으로 그렇게 하지 않았다는 점이 GitHub 같은 서비스를 간단하게 만들었죠. GitHub을 단순화시키고 있지만, Git 주변의 인프라를 만드는 데 많은 작업이 필요하다는 걸 알고 있습니다. 하지만 동시에 기본적인 Git 호스팅 측면은 사실상 아무것도 아닙니다 Git의 전체 설계가 복사를 쉽게 만들도록 설계되어 있기 때문이죠 모든 저장소가 동일하고 평등합니다. 이것이 개인 개발자가 쉽게 사용할 수 있게 만든 이유라고 생각합니다. 새로운 Git 저장소를 만들 때, 대단한 일이 아닙니다. git init을 하면 끝이고 인프라를 설정할 필요도 없고 전통적인 SCM에서 필요했던 작업을 할 필요가 없습니다. 그리고 나중에 그 프로젝트가 성장해서 다른 사람들과 공유하고 싶다고 결정하면그것도 괜찮습니다. 그리고 다시 말하지만, 당신은 아무것도 할 필요가 없습니다. GitHub에 푸시하기만 하면 끝입니다. 그것은 제가 정말 원했던 것이었고 다른 사람들도 얼마나 많이 원하는지 몰랐습니다. 사람들이 CVS와 SVN에 만족한다고 생각했습니다. 글쎄, 사실 그렇게 생각하지 않았지만, 당시 대부분의 사람들에게 충분하다고 생각했습니다. 우리는 방금 Git이  소프트웨어 엔지니어링의 양 극단에 모두 적용 가능하다는 점에 대해 조금 이야기했습니다. 소프트웨어 개발의 한 부분으로서의 버전 관리와 함께 평생을 살았습니다. 제가 궁금한 점 중 하나는 오늘날 소프트웨어 개발이 이루어지는 방식을  형성하는 데 있어 Git의 역할을 어떻게 보시는지입니다. 소프트웨어 개발이 이루어지는 방식을  형성하는 데 있어 Git의 역할 말입니다. 그건 너무 큰 질문입니다. 저는 모르겠습니다. 그건 제가  Git을 만든 이유가 아닙니다. 저는 제 자신의 문제를 위해 만들었습니다. GitHub와 다른  호스팅 서비스들이 이제 얼마나 쉽게 이런 무작위의 작은 프로젝트들을 만들 수 있는지 보여주었다고 생각합니다. 예전에는 그렇지 않았던 방식으로 말이죠. 그 결과 많은 죽은 프로젝트들도 생겼습니다. 누군가가 뭔가를 하고  남겨둔 일회성 프로젝트들을 발견할 수 있죠. 그게 아직도 거기 있습니다. 하지만 그게그것이 정말로 큰 그림에서 소프트웨어 개발 방식을 변화시켰나요? 잘 모르겠어요. 세부적인 것들은 바뀌었죠. 어느 정도 협업을 더 쉽게 만들었어요. 일회성 프로젝트를 더 쉽게 할 수 있게 되었고 잘 안 되면 그만두고, 잘 되면 이제 다른 사람들과 함께 작업할 수 있죠. 하지만 소프트웨어 개발에서 근본적으로  뭔가 바뀌었는지는 확신할 수 없어요. 조금 더 나아가서, 현대 소프트웨어 개발은 그 어느 때보다 빠르게 변화하고 있어요. AI라는 말을 하려나요? 저는 AI라는  말을 하지 않을 거예요. 원한다면 모르지만요. 아니요, 아니요. 도구의 어떤 영역이 발전했거나  아직 발전이 필요하다고 생각하시나요? 새롭고 까다로운 워크플로우를 지원하기 위해서요. 버그 추적 기능이 더 많아졌으면 좋겠어요. 모든 사람들이 그걸 하고 있죠.  버그 추적이든 이슈든 뭐라고 부르든 간에, 모두가 하고 있어요. 그게 더 통합되었으면 좋겠어요. 지금은 매우 파편화되어 있거든요. 모든 호스팅 사이트가 자체 버전을 만들고 있어요. 그 이유를 이해합니다. 첫째, 표준화된 좋은 기반이 없고  둘째, 그들 나름의 이유가 있겠죠. 하지만 더 통합되었으면 좋겠어요.이것은 또한 가치를 더하고 사람들을 그 생태계에 머물게 하는 방법이기도 합니다. Git 자체가 코드를 쉽게 이동할 수 있게 해주지만 말이죠. 하지만 저는 바랍니다 버그 추적과 이슈 관리가 호스팅 사이트들 간에 더 통합된  형태로 공유되었으면 좋겠습니다. 그렇군요. 당신은 앞서 언급했는데 아주 빠르진 않았지만 적어도 한동안 메일링 리스트를 정기적으로 팔로우하지 않으셨다고요. 네. 사실, 프로젝트에 커밋한 지도  꽤 시간이 지났습니다. 제가 확인한 바로는 2022년 8월이 마지막 커밋이었던 것 같습니다. 네. 제 트리에 몇 가지 실험적인 패치들이 있는데 그냥 갖고 있습니다. 요즘은 Git 소스를 풀 받아서 4-5개 정도의 패치를  직접 사용하고 있고 그 중 몇 개는 Git 메인 리스트에 올렸지만 그리 중요하진 않습니다. 제 워크플로우에 매우 특화된  세부 사항들이죠. 하지만 솔직히 말해서 이건 리눅스 커널에도 해당되는 얘기인데 35년 동안 리눅스를 해왔고첫 해에 필요한 모든 것을 했습니다. 맞아요. 그리고 커널 쪽에서 계속 나아갈 수 있게 하는 것은 하드웨어가 계속 발전하고 있고 당연히 커널도 그에 맞춰 발전해야 한다는 점입니다. 그리고 다른 사람들의 모든 요구사항들이 있죠. 제 평생 커널이 하는 모든 기능이 필요하진 않을 겁니다. 하지만 저는 커널에 관심이 있고 35년이 지난 지금도 여전히 그 일을 하고 있죠. Git에  관해서는, Git은 첫 해 안에 제가 필요한 걸 다 해냈어요. 사실 대부분 처음 몇 달 안에 말이죠. 그리고 제가 필요한 걸 다 했을 때 흥미를 잃었습니다. 왜냐하면 커널에 대해서는 정말 관심이 있고 이게 제가 하는 일이지만 소스 코드 관리 시스템에 대해서는 전혀 관심이 없거든요. 최근 몇 년간 프로젝트에서 흥미롭다고 생각한 기능이 있나요? 병합 전략이 조금 더 똑똑해진 게 마음에 들었어요. 일부 스크립트들이 마침내 C로 다시 작성되어 더 빨라진 것도 좋았습니다. 제가 더 이상 100개의 패치 시리즈를 적용하지는 않지만, 테스트 트리를 위해 리베이스 같은 작업을 하게 되는데, 이런 성능 개선이 도움이 됐습니다.하지만 그런 것들은 꽤 작은 구현 세부사항입니다. 결국에는 큰 변화는 아닙니다. 제가 생각하기에 가장 큰 변화는 몇 년 전에 여전히 추적하고 있었던 다중 해시 기능인데, 이는 정말 매우 고통스러워 보였습니다. 제게는 말이죠. 생태계에서 함께 사용한 도구들이 있나요? 저는 틱(tick)을 많이 사용하는데, 당신은 어떠신가요? 저는 한 번도... 아니요, 초기에도 Git이 정말 사용하기 어려웠고 추가 UI들이 있었을 때도 Git 주변의 유일한 래퍼로 제가 사용한 것은 Git K뿐이었고, 그것도 빠르게 Git에 통합되었죠. 하지만 저는 여전히 전적으로 명령어 인터페이스만 사용합니다. 에디터 통합 기능은 전혀 사용하지 않아요. 그런 것들은 사용하지 않습니다. 제 에디터가 너무 단순해서 어떤 것과도 통합되기 어렵거든요. 훨씬 덜 좋죠. 그래서 가끔 제 Git 사용 기록에 대한 통계를 내보는데, 어떤 명령어를 사용하는지 궁금해서요. 그리고 알게 된 것은 제가 다섯 가지 Git 명령어를 사용한다는 거예요. Git merge와 Git blame, 그리고 Git log가 그 중 세 가지입니다. 꽤 많이 사용하죠.많이요. 저는 그런 의미에서 매우 가벼운 git 사용자입니다. 다른 두 가지가 무엇인지 물어봐야겠네요. 물론 Git commit과 git push는 알겠는데 언젠가 이 상위 5개 목록을 만들었고 변경되었을 수 있지만, 많지는 않습니다. Git rev-list를 사용해서 프로젝트 통계를 내는 몇 가지 스크립트는 있긴 합니다. 아주 세밀하게 말이죠. 하지만 그건. 프로젝트와의 상호작용 측면에서. 네, 네. 초기부터 또는 그 이후에 프로젝트에서 어떤 기능들이 충분히 인정받지 못했다고 느끼시나요? 오. 음, 사실 받아야 할 것보다  훨씬 더 많은 인정을 받았죠. 제가 물어본 것과는 반대의 질문이네요. 제게 중요했던 건 사람들이 Git이 얼마나 다른지 불평하는 대신 Git이 할 수 있는 일을 실제로 인정하기 시작했을 때였어요. 네. 그리고 그건, 음 그건. Git이 처음 나온 지 몇 년이 지난 후였던 것 같아요. 어떻게 됐더라? 그랬죠. 이상한 웹 개발자들이 Git을 대대적으로 사용하기 시작했어요. Ruby onRails인 것 같아요. 저는 전혀 몰랐죠. 아직도 Ruby가 뭔지도 모르겠어요. 맞아요. 하지만 Ruby on Rails 사용자들이 2008년 즈음에 git을 사용하기 시작했어요. 그렇죠. 그리고 그것은 이상했어요. 왜냐하면 완전히 새로운 종류의 Git 사용자를 불러왔기 때문이에요. 적어도 제가 전에 본 적 없는 사용자들이었죠. 맞아요. 배경에 있었겠지만 갑자기 드러났어요. 갑자기 SCM을 한 번도 사용해본 적 없는  젊은 사람들이 많이 생겼고 Git이 그들이 처음 사용한 것이었어요. 그들이 사용하는 프로젝트가 사용하고 있어서 기본이 된 거죠. 그리고 저는 이게 역학을 바꿨다고 생각해요. 평생 매우 다른 SCM을 사용한 노련한 사용자들이 아니라 다른 것을 본 적 없는 젊은 사람들이 갑자기 생겼고 그들은 이를 높이 평가했어요. 그리고 Git이 너무 어렵다고 말하는 대신, 이 사람들이 이 오래된 프로젝트가 CVS에 있을 때  어떻게 해야 하는지 불평하는 걸 보기 시작했어요. 그래서 그게 재미있었죠. 하지만 네, 이제 사람들이 git을 높이 평가한다는 사실이,생각했던 것보다 훨씬 더 많았죠. 특히 고려해보면 처음 몇 년 동안 많은 비난을 받았어요. 정말 인터뷰를 받으려고요. 오, 불평이 계속 들어왔죠. 말씀해 주세요 그것에 대해. 음, 제 말은... 그건 더 like... 정확히 지적할 순 없어요. 구글에서 찾아봐야 할 거예요. 하지만 많은 사람들이 저에게 보냈죠, "왜 이렇게 되는 거죠?"라고 그리고 제가 선택한 이름에 대한 논쟁도 있었고요. 이름에 대해서요. 예를 들어, 'git status' 같은 게 없었어요. 사실 그건 제가 꽤 자주 사용하는 명령어 중 하나죠. 상위 5개 안에 들어요. 아마 상위 5개는 아니겠지만, 여전히 꽤 일반적인 거죠. 제가 CVS에서는 너무 느려서 거의 사용하지 않았던 것 같아요. 사람들은 많은 기대를 가지고 있었죠. 그래서 처음 몇 년간 기억나는 건 불평이에요. 왜 하위 명령어 이름들이 아무 이유 없이 다른지에 대해서요. 주된 이유는 제가 그냥 CVS를 별로 좋아하지 않았기 때문이에요. 그래서 때때로 일부러 다르게 했죠. 그리고 그 변화는 말 그대로 2007년과 2010년 사이, 그 몇 년 동안이었어요. 네,네. 사람들이 Git이 사용하기 어렵다고 불평하다가 Git의 강력함을 진정으로 인식하게 된 것이 제게는 흥미로웠습니다. 그렇죠. 우리는 초기 단계와 프로젝트의 시작에 대해 이야기했습니다. Git이 현재 어떻게 사용되고 있는지도 조금 얘기했고요. 오늘은 잠시 시간을 내어 프로젝트의 미래에 대해 생각해보고 싶습니다.  우선 시작하자면, 당신이 생각하기에 Git이 직면하고 있거나 직면할 가장 큰 과제는 무엇인가요? 잘 모르겠습니다. Git은 제가 예상했던 것보다  훨씬 더 성공적이었거든요. 통계가 말도 안 되게 대단합니다. Git은 커널과 몇몇  프로젝트에서만 쓰이다가 꽤 인기를 얻더니 이제는 98%의 SCM 점유율을 차지하고 있어요. 그게 맞죠. 작년 어떤 보고서에서 본 숫자예요. 그게 얼마나 정확한지는 모르겠지만, 엄청난 수치죠. 네. 그런 의미에서 저는 과제에 대해 걱정하지 않습니다. SCM은 매우 강력한 네트워크 효과가 있기 때문이에요. 그래서 아마도 한번 인기를 얻자 급속도로 퍼진 것 같아요. 다른 모든 프로젝트가 Git을 사용하고 있다면 그냥... 다른 모든 프로젝트가 Git을 사용하고 있을 때기본적으로 모든 새 프로젝트는 git을 사용할 것입니다. 두 개의 다른 프로젝트에 두 가지 다른 SCM을 사용하는 고통은 그만한 가치가 없기 때문입니다. 그래서 저는 이것을 git의 도전으로 보지 않고 더 나은 것이 있다고 생각하는 다른 사람들의 도전으로 봅니다. 솔직히 git이 제가 필요한 모든 것을 수행하기 때문에, 도전은 아마도 새로운 사용 사례에서 올 것입니다. 우리는 그런 일부를 보았습니다. 우리는 git을 명시적으로 잘못된 접근 방식이라고 생각한 방식으로 사용한 사람들을 보았습니다. 예를 들어 Microsoft가 모든 것에 대해 모노 레포를 사용한 것처럼요. 이는 확장성 문제를 보여주었습니다. Microsoft가 그렇게 한 것이 잘못됐다고 말하는 것은 아닙니다. 이것은 말 그대로 git이 설계되지 않은 용도라고 말하는 것입니다. Microsoft가 그렇게 한 것이 잘못되었다고 말하는 게 아닙니다. 이것은 말 그대로 git이 설계되지 않은 용도입니다. 불만을 듣지 못하고 있어서 대부분의 문제가 해결되었다고 생각합니다. 하지만 동시에 예전만큼 git 메일링 리스트를 따라가지 않고 있습니다. 대용량 파일 문제가 해결된 것으로 간주되는지도 모르겠습니다. git에 DVD 이미지를 넣으려고 한다면 그건 왜 그렇게 하고 싶어 하는지 모르겠습니다. 하지만 그것이 도전입니다. git에 DVD 이미지를 넣으려고 한다면 그건 왜 그렇게 하고 싶어 하는지 모르겠습니다. 하지만 그것이 도전입니다.Git이 모든 곳에 있을 때, 당신은 이상한 일을 하는 사람들을 발견하게 됩니다 내가 상상도 못했고 완전히 잘못됐다고 생각한 일들을 말이죠 하지만 그건 개인적인 의견이에요. 분명히 다른 사람들은 매우 다른 개인적인 의견을 가지고 있죠. 그래서 항상 도전이 됩니다 이건 커널에서도 보는 것인데, 제가 '왜 그렇게 하는 거지?'라고 생각하는 거죠 그건 작동하지 않을 텐데. 하지만 당신은 분명히 그렇게 하고 있어요 도대체 왜 그러는 거죠? 그건 작동하지 않을 텐데. 하지만 당신은 분명히 그렇게 하고 있어요 그 정도로 말이에요. 우리가 얘기했듯이, 98%인지 아닌지는 모르겠지만 Git이 소프트웨어 개발에서 확실히 지배적인 요소라는 거죠 동시에 새로운 버전 관리 시스템들이 계속 나타나고 있어요 Pjool이 떠오르네요. Jiu Jitsu, Piper 같은 것들이요. 혹시 그것들을 사용해 보신 적이 있나요? 아니요, 전혀요 사실 저는 소스 컨트롤에 전혀 관심이 없었던 사람이었기 때문에 제가 쓰는 게 있는데 왜 다른 대안을 찾아보겠어요? 제가 사용하는 게 잘 작동하는데 말이죠 지금 제게 잘 맞는 게 있는데 왜 다른 걸 찾아보겠어요? 네, 저는 정말로 소스 컨트롤을 좋아하지 않는 상태에서 Git을 접했고 이제는 더 이상 싫어하지 않아요 그리고 제가 생각하기에 데이터베이스가 제게는 특히, 삶에서 가장 지루한 것 같아요 하지관심있는 분야가 아니었습니다. 마지막 질문에 대한 답변을 어느 정도 해주셨네요. 예정대로라면 리눅스는 34년 전에 나왔습니다. 그렇죠, Git은 20년 전이고요. 그 질문에 대해서는, 아마 다음 큰 일이 5년 정도 지연되고 있는 것 같습니다. 아니요, 저는 다르게 봅니다. 제가 만들어야 했던 모든 프로젝트는 다른 사람이 만든 더 나은 것을 찾지 못해서 만들어야 했습니다. 하지만 저는 다른 사람들이 제 문제를 해결해주는 걸 훨씬 더 선호합니다. 그래서 제가 프로젝트를 만들어야 하는 건 사실 세상의 실패입니다. 그리고 지난 20년 동안 세상은 저에게 실패하지 않았습니다. 맞아요. 저는 운영체제가 필요했고 제 요구를 충족시키는 것이 없어서 리눅스를 시작했습니다. 같은 이유로 Git을 시작했고, 제 다이빙 로그 소프트웨어인 subsurface도 시작했습니다. 더 이상 제 것은 아니지만, 그건 너무 특화되어 있어서 크게 성공하지 못했고 특정 문제를 해결하려 했습니다. 하지만 제 컴퓨터 사용은 실제로 매우 제한적이어서제가 모든 문제를 해결했다고 생각합니다. 아마도 그 이유 중 하나는 오랫동안 해왔기 때문에 특정 방식으로만 할 수 있다는 것입니다. 저는 여전히 대학 시절에 사용하던 동일한 에디터를 사용하고 있습니다. 왜냐하면 제 손가락이 하나만 배웠고 돌이킬 수 없기 때문입니다. 그 에디터가 형편없다는 걸 알지만, 더 이상 아무도 사용하지 않는 죽은 프로젝트이기 때문에 제가 유지보수합니다. 소스 트리가 있어서 새 기계를 설치할 때마다 제 버전을 직접 컴파일합니다. 그리고 저는 누구도 그 에디터를 사용하지 말라고 제안하겠지만, 저는 그럴 수 없습니다. 시도해봤습니다. 여러 번 더 현대적이고 멋진 기능이 있는 에디터를 찾으려고 노력했습니다. 소스 코드에 색상을 입히고 그런 일들을 하는 에디터 말이죠. 하지만 매번 시도할 때마다 '그래, 이 손은 이제 너무 늙었어'라고 생각합니다. 그래서 정말 '이건 꼭 해야 해'라고 생각하게 만드는 프로젝트가 없기를 바랍니다. 음, 그런 의미에서, 그런 의미에서, 20년간의 선물에 감사드립니다. 글쎄요, 제가 매우 이기적인 이유로 했습니다. 정말로, 이 시점에서 다시 한 번 말씀드리자면 20년 중에서 4개월만 투자했고, 사실 그게 전부입니다.모든 공로는 주니어와 Git에 관여한 다른 모든 사람들에게 돌아갑니다. 그들은 이제 제가 했던 것보다 훨씬 더 많은 일을 해냈습니다. 감사합니다.