Git 역사, 리누스가 열흘 만에 만든 버전관리 도구

 

Git 역사를 거슬러 올라가 보면 시작은 의외로 초라합니다. 지금은 전 세계 개발자 대부분이 매일 쓰는 도구지만, 애초에는 리누스 토르발스 한 사람이 자기 리눅스 커널을 관리하려고 급하게 만든 임시방편에 가까웠거든요. 그렇게 열흘 남짓 만에 뚝딱 만든 물건이 20년이 지난 지금 사실상의 표준이 되어 있습니다.

저는 2012년에 웹 개발을 시작했는데, 그때만 해도 국내 현장에서는 이런 이야기가 흔했습니다.

"Git 그거 어렵던데, 우리는 그냥 SVN 쓰면 안 돼요?" "충돌 나면 골치 아프니까 같은 파일은 한 사람만 건드립시다." "브랜치는 무서워서 못 쓰겠어요. 그냥 하나로 갑시다." "Git이 정확히 뭐가 좋은 건데요? SVN도 잘 돌아가는데."

지금 들으면 격세지감이지만, 불과 10여 년 전만 해도 저 말들은 회의실에서 진지하게 오갔습니다. 저는 그 이후로 이 회사 저 회사를 다니며 Git을 도입시키는 일을 꽤 여러 번 했는데, 그 과정에서 Git이라는 도구가 어떻게 태어났고 왜 이렇게까지 퍼졌는지 자연스럽게 파고들게 됐습니다.

이 글에서는 Git의 탄생 비화부터 이름의 유래, GitHub의 등장과 마이크로소프트 인수, 그리고 제가 현장에서 직접 겪은 도입 이야기까지 정리해 봤습니다. 매일 git commit을 치면서도 정작 그 뒤의 사연은 모르고 지나쳤던 분들에게 도움이 될 겁니다.

목차

1. Git 이전, 버전 관리가 지옥이던 시절
2. 리누스 토르발스와 BitKeeper의 만남
3. 2005년 4월, BitKeeper 무료 라이선스가 끊기다
4. 열흘 만에 태어난 Git, 실제 타임라인
5. 'Git'이라는 이름에 담긴 뜻
6. 리누스가 넉 달 만에 손을 뗀 이유, 주니오 하마노
7. GitHub의 등장, 협업의 판이 바뀌다
8. 마이크로소프트의 75억 달러 GitHub 인수
9. 왜 Git이 결국 표준이 됐을까
10. 현장에서 Git을 도입시킨다는 것
11. Git과 다른 버전 관리 시스템 비교

1. Git 이전, 버전 관리가 지옥이던 시절

Git이 없던 시절 개발자들이 코드를 어떻게 관리했는지 아시나요? 제가 신입이던 2012년에도 일부 현장에는 이 방식이 남아 있었습니다. 바로 파일명 뒤에 날짜 붙이기입니다.

project_2003-01-15.zip
project_2003-01-15_final.zip
project_2003-01-15_final2.zip
project_2003-01-15_진짜final.zip

농담 같지만 실제로 이런 폴더를 여러 번 봤습니다. 문제는 여럿이 같이 일할 때였죠. A가 작업하는 파일을 B가 동시에 고치면, 둘 중 누구 코드를 살릴지 정하는 것부터가 일이었습니다. 결국 누군가 밤에 남아서 두 코드를 눈으로 비교해 가며 손으로 합쳐야 했고요.

1990년대 후반부터 CVS(Concurrent Versions System), 이어서 SVN(Subversion) 같은 버전 관리 시스템이 나오면서 상황은 나아졌습니다. 저도 초기에는 SVN을 썼는데, 확실히 파일명에 날짜 붙이던 것보다는 천국이었죠. 다만 이들은 모두 중앙 집중식이었습니다. 회사 서버 한 곳에 모든 코드가 있고, 그 서버에 붙지 못하면 커밋은커녕 이전 이력조차 볼 수 없었습니다. 서버가 죽으면 팀 전체가 손을 놓아야 했고, 인터넷이 끊긴 곳에서는 작업 기록을 남길 방법이 없었어요.

그래서 나온 개념이 분산 버전 관리 시스템(DVCS)입니다. 모든 개발자의 PC에 저장소 전체가 복제돼 있어서, 서버 없이도 커밋하고 이력을 뒤질 수 있는 방식이죠. 2000년대 초반 BitKeeper가 그 선구자였고, 바로 이 BitKeeper가 Git 탄생의 계기가 됩니다.

2. 리누스 토르발스와 BitKeeper의 만남

이야기의 주인공 리누스 베네딕트 토르발스는 1991년, 스물한 살 핀란드 대학생 시절에 리눅스 커널을 만든 개발자입니다. 그가 짠 리눅스는 지금 안드로이드 스마트폰, 웹 서버, 슈퍼컴퓨터, 스마트 TV까지 사실상 모든 컴퓨팅 기기의 심장으로 들어가 있죠.

그런데 리눅스 커널 개발은 처음부터 거대한 협업 프로젝트였습니다. 전 세계 수천 명이 각자 PC에서 코드를 짜고, 메일로 리누스에게 패치를 보내면 그가 하나하나 검토해서 합치는 방식이었어요. 1991년부터 2002년까지, 무려 11년 동안 리눅스는 패치 파일과 압축 파일만으로 관리됐습니다.

리누스도 SVN이나 CVS를 알고는 있었습니다. 다만 쓰지 않았죠. 이유는 단순했습니다. 마음에 안 들어서였습니다. 특히 CVS에 대해서는 20년 뒤 인터뷰에서도 "질색이라 못 쓴다"고 할 만큼 감정이 깊었습니다.

그러다 2002년, 리눅스 커널 개발팀이 드디어 BitKeeper라는 분산 버전 관리 시스템을 도입합니다. BitKeeper는 래리 맥보이(Larry McVoy)가 만든 상용 소프트웨어였지만, 오픈소스 프로젝트에는 무료로 열어 줬어요. 빠른 속도와 분산 방식이 마음에 들었던 리누스는 이걸 택했습니다.

💡 왜 논란이 됐나 오픈소스의 상징인 리눅스가 상용 소프트웨어에 의존한다는 점을 두고 자유 소프트웨어 진영에서 반발이 컸습니다. 리누스는 "기능이 좋으면 됐다"는 입장을 굽히지 않았고, 그렇게 약 3년간 BitKeeper는 커널 개발의 핵심 도구가 됩니다.

3. 2005년 4월, BitKeeper 무료 라이선스가 끊기다

2005년 초, 커뮤니티에 사달이 납니다. 한 개발자가 BitKeeper의 내부 동작을 리버스 엔지니어링(역공학)하려 시도한 거죠. 그것도 삼바(Samba) 프로젝트를 만든 앤드류 트리젤(Andrew Tridgell)이었습니다.

BitKeeper의 저작권자 래리 맥보이는 크게 반발했고, 곧바로 결정을 내립니다. 오픈소스 개발자에게 무료로 제공하던 BitKeeper 라이선스를 종료한다고요.

리누스는 곤란해졌습니다. 11년을 패치와 압축 파일로 버티다 겨우 3년 편해졌는데 그마저 못 쓰게 된 셈이니까요. 그는 대안을 찾아 SVN, Monotone, Mercurial 등 당시 있던 시스템을 죄다 검토했습니다. 하지만 하나같이 성에 차지 않았어요. 특히 속도가 발목을 잡았습니다. 리눅스 커널처럼 거대한 프로젝트에서는 명령 하나에 몇 시간씩 걸리는 도구도 있었거든요.

그리고 리누스는 제3의 길을 택합니다. 기존 도구가 마음에 안 들면 직접 만든다는, 그다운 결론이었죠.

4. 열흘 만에 태어난 Git, 실제 타임라인

여기서 흔히 "Git은 10일 만에 만들어졌다"고들 하는데, 날짜를 정확히 짚어 볼 필요가 있습니다. 실제 타임라인은 이렇습니다.

- 2005년 4월 3일경: 리누스가 Git 개발에 착수(본인도 "정확히는 기억 안 나지만 이날쯤"이라 회고)
- 2005년 4월 7일: Git의 첫 커밋. 이때 이미 Git이 스스로를 관리(self-hosting)할 수준
- 2005년 4월 16일: 실제 리눅스 커널의 첫 Git 커밋
- 2005년 4월 17일: 커널 첫 병합(merge) 성공

즉 착수에서 첫 커밋까지는 나흘, 아무것도 없던 상태에서 실제 커널을 굴리기까지가 약 2주였습니다. "10일"은 이 흐름을 대중적으로 뭉친 표현인데, GitHub 공식 블로그도 20주년 글에서 이 표현을 쓸 만큼 굳어졌습니다. 다만 원문 기사들에서 자주 보이는 "4월 3일 시작해서 10일 만인 4월 7일"이라는 문장은 계산이 안 맞으니(그건 나흘입니다) 걸러 들으시길 권합니다.

첫 커밋의 메시지가 리누스답습니다.

Initial revision of "git", the information manager from hell (지옥에서 온 정보 관리자, 'git'의 초기 버전)

자조적인 유머와 자신감이 한 줄에 같이 들어 있죠. 첫 버전은 겨우 1,200줄 남짓의 코드였는데, 리누스가 설계하며 잡은 목표는 분명했습니다.

- 빠를 것. 거대한 커널을 즉시 처리
- 단순한 설계. 복잡한 기능은 빼고 핵심만
- 브랜치 같은 비선형 개발 지원
- 완전한 분산 처리. 서버 없이도 작업
- 데이터 무결성. SHA-1 해시로 손상 방지

흥미로운 건 Git이 기존 시스템의 방식을 정면으로 뒤집었다는 점입니다. 다른 도구들은 파일의 변경분(차이)을 저장했지만, Git은 매 커밋마다 전체 스냅샷을 저장하는 방식을 택했어요. 같은 내용은 해시로 한 번만 저장하기 때문에 가능한 설계였고, 결과적으로 속도와 안정성을 모두 잡았습니다.

5. 'Git'이라는 이름에 담긴 뜻

SVN(Subversion), CVS(Concurrent Versions System)처럼 무슨 약자일 거라 생각하기 쉽지만, Git은 그렇지 않습니다. 리누스가 직접 밝힌 유래가 재밌어요. 그는 "나는 이기적인 인간이라 내 프로젝트엔 다 내 이름을 붙인다. 첫 번째가 리눅스, 두 번째가 git"이라고 농담했습니다.

무슨 말이냐면, 'git'은 영국식 영어 속어로 고집 세고 짜증나는 사람, 즉 밉살스러운 인간을 뜻합니다. 리누스가 자기 자신을 그렇게 부르며 도구 이름에 슬쩍 얹은 거죠. 실제로 그는 메일링 리스트에서 남의 코드를 두고 거침없이 쏘아붙이는 성격으로 유명했으니, 이름에 성격이 그대로 묻어난 셈입니다.

리누스는 이름의 다른 장점도 덧붙였습니다.

- 발음하기 쉬운 세 글자
- 기존 UNIX 명령어와 겹치지 않음
- 영어 "get"의 영국식 발음과 비슷함
- 기분 좋을 땐 "global information tracker"의 약자로 읽어도 됨
- 기분 나쁠 땐 알아서들 험한 뜻으로 읽어도 됨

이름 하나에도 리누스 특유의 시니컬한 위트가 담겨 있죠. 다음에 누가 "Git이 무슨 뜻이야?"라고 물으면 "영국 속어로 밉살스러운 사람"이라고 답해 주면 됩니다.

6. 리누스가 넉 달 만에 손을 뗀 이유, 주니오 하마노

여기서 의외의 사실 하나. 리눅스를 만든 리누스는 Git을 만든 지 넉 달 만에 프로젝트에서 손을 뗐습니다.

2005년 4월에 시작했지만, 그해 여름 리누스는 일본계 개발자 주니오 하마노(Junio C Hamano)에게 메인테이너 자리를 넘깁니다. 주니오는 첫 커밋 후 약 일주일 만에 합류해 이미 상당한 기여를 하고 있었고, 리누스는 7월 말 공식적으로 그를 새 메인테이너로 지명했어요. 그리고 20년이 지난 지금까지 주니오가 Git의 핵심 개발을 이끌고 있습니다. 그해 12월 21일 Git 1.0.0을 세상에 내놓은 것도 주니오였습니다.

왜 리누스는 자기가 만든 도구를 그렇게 빨리 놓았을까요? 그는 2025년 Git 20주년 인터뷰에서, 넉 달쯤 유지하다 넘겼고 그때는 "아직 살아있네" 싶은 정도였으며 이건 자기가 하고 싶은 일이 아니었다는 취지로 회고했습니다. 그의 진짜 관심은 어디까지나 리눅스 커널이었고, Git은 그걸 잘 굴리기 위한 도구일 뿐이었던 거죠.

같은 인터뷰의 일화가 인상적입니다. 대학에 간 큰딸이 어느 날 문자를 보냈다고 해요. 컴퓨터과학 연구실에서는 아빠를 리눅스보다 Git으로 더 잘 안다고요. 본인은 가볍게 던진 도구가 대표작인 리눅스보다 유명해진 순간이었습니다.

7. GitHub의 등장, 협업의 판이 바뀌다

Git으로 분산 버전 관리는 가능해졌지만, 두 가지가 남았습니다. 각자 PC에 흩어진 코드를 어디에 모아 공유할 것인가, 그리고 코드 외에 이슈나 리뷰 같은 협업 과정은 어떻게 관리할 것인가.

이 틈을 파고든 게 2008년 등장한 GitHub입니다. 톰 프레스턴 워너, 크리스 원스트래스, 그리고 PJ 하이엇이 만들었죠(이후 스콧 샤콘도 공동 창업자로 합류). 톰과 크리스는 Ruby on Rails 모임에서 만난 사이였고, 처음엔 평일엔 직장을 다니면서 주말에만 붙어 사이드 프로젝트로 시작했습니다. 사무실도 없이 원격으로 일했고, 호스팅 비용을 아끼려고 엔진야드(Engine Yard)에 무료 광고를 실어 주는 대가로 서버를 얻어 썼다고 하니, 여느 스타트업다운 출발이었습니다.

GitHub가 판을 바꾼 건 단순히 저장소를 호스팅한 데 그치지 않았기 때문입니다. 여기에 협업 기능을 얹었어요.

- Pull Request. 남의 코드 변경을 검토하고 토론하는 창구
- Issue Tracker. 버그와 기능 요청을 체계적으로 관리
- Fork. 남의 프로젝트를 내 것으로 복제해 자유롭게 수정
- Star와 팔로우. 개발자와 프로젝트를 잇는 소셜 요소

재미있는 건 Pull Request라는 말의 뿌리가 Git 자체에 있다는 점입니다. Git에는 request-pull이라는 명령이 있는데, 내 변경을 가져가 달라는 요청을 메일 형식으로 만들어 주는 기능이었어요. GitHub가 이걸 버튼 하나로 바꾸면서, 오픈소스에 기여하는 문턱이 확 낮아졌습니다.

이때부터 개발자에게 GitHub 주소가 이력서 못지않은 명함이 됐습니다. 회사가 사람을 뽑을 때 "GitHub 주소 있어요?"를 묻기 시작한 것도 이 무렵부터였고요.

8. 마이크로소프트의 75억 달러 GitHub 인수

2018년 6월 4일, 개발자 커뮤니티에 큰 뉴스가 떴습니다. 마이크로소프트가 GitHub를 75억 달러(약 7조 5천억 원)에 인수한다는 발표였죠.

반응이 뜨거웠던 데는 이유가 있습니다. MS는 한때 오픈소스의 최대 적으로 여겨졌거든요. 2001년 당시 CEO 스티브 발머는 리눅스를 두고 "암 덩어리"라고 공개적으로 깎아내릴 정도였습니다. 그런 회사가 오픈소스의 성지 GitHub를 사들인다니, "고양이가 쥐를 사는 격"이라는 말까지 나왔어요.

발표 직후 "GitLab으로 옮기자"는 움직임이 일었고, 실제로 저장소를 옮긴 프로젝트도 있었습니다. 하지만 우려했던 일은 벌어지지 않았습니다. 사티아 나델라 체제의 MS는 발머 시절과 달리 오픈소스에 우호적이었고, GitHub의 독립성과 정책을 그대로 뒀거든요. 오히려 유료였던 비공개 저장소를 무료로 풀었고, GitHub Actions나 Codespaces 같은 기능을 더했습니다.

📌 지금(2026년)의 GitHub 2025년 옥토버스(Octoverse) 보고서 기준 GitHub 사용자는 1억 8천만 명을 넘어섰습니다. 2023년 1억 명을 돌파한 뒤 2년 만에 다시 크게 뛴 셈이죠. MS 입장에서 75억 달러는 결과적으로 비싼 값이 아니었던 셈입니다.

9. 왜 Git이 결국 표준이 됐을까

2005년 당시엔 Git 말고도 SVN, Mercurial, Bazaar 같은 선택지가 많았습니다. 그런데 왜 Git만 살아남았을까요. 제가 보기엔 몇 가지가 맞물렸습니다.

우선 리눅스를 만든 사람이 만들었다는 사실 자체가 큰 힘이었습니다. 개발자라면 그 이름값에 한 번은 관심을 가질 수밖에 없었죠. 게다가 거대한 커널을 굴리려고 만든 만큼 속도가 유독 빨랐습니다. 커밋 이력을 뒤지는 명령이 SVN보다 수십 배 빠른 경우도 있었어요. 인터넷이 끊긴 비행기 안에서도 작업이 되는 완전한 분산 방식, 그리고 가볍고 빠른 브랜치도 결정타였습니다. 브랜치를 부담 없이 만들고 합칠 수 있게 되면서 요즘의 개발 방법론이 비로소 가능해졌으니까요.

그리고 앞서 본 GitHub와의 시너지가 있었습니다. Git이 GitHub를 만든 게 아니라, 두 도구가 나란히 크면서 서로를 끌어올린 거죠. 실제로 초창기 사용성을 끌어올린 건 도구 자체보다 GitHub라는 판이었다고 보는 시각도 많습니다.

물론 Git이 모두의 사랑을 받는 건 아닙니다. SQLite를 만든 리처드 힙은 지금도 자체 도구인 Fossil을 쓰고, 페이스북은 커스터마이즈한 Mercurial을 씁니다. Git이 직관적이지 않아서 처음 배우는 사람을 좌절시킨다는 지적도 오래됐고요. 이 부분은 다음 섹션에서 제 경험으로 풀어 보겠습니다.

10. 현장에서 Git을 도입시킨다는 것

여기서부터는 역사책엔 안 나오는, 제가 실제로 겪은 이야기입니다. 결론부터 말하면 Git은 개념 자체가 생각보다 어렵고, 그걸 남에게 가르치는 건 더 어렵습니다.

처음 팀에 Git을 들일 때 가장 애먹은 게 개념 설명이었어요. 브랜치니 커밋이니 하는 말이 초심자에겐 외계어처럼 들리거든요. 그래서 저는 정확하지는 않지만 이렇게 뭉뚱그려 설명하곤 했습니다. 브랜치는 폴더, 커밋은 그 안에 저장하는 파일이라고요. 엄밀히 따지면 브랜치는 특정 커밋을 가리키는 포인터일 뿐이라 틀린 비유지만, 처음 겁먹은 사람에게 정확한 정의부터 들이밀면 도망갑니다. 일단 손에 익게 만드는 게 먼저였어요.

그래서 도입 초반에는 브랜치를 여러 개 열지 않았습니다. dev 브랜치 하나만 두고 다 같이 거기에 올리게 했죠. 전략이랄 것도 없이, 우선 커밋하고 푸시하는 감각부터 몸에 배게 하는 게 목표였습니다.

💡 진짜 벽은 '충돌'이었다 사람들이 가장 무서워한 건 충돌(conflict)이 났을 때입니다. 그런데 Git에서 충돌은 잘못이 아니라 당연한 일이에요. 여럿이 같은 곳을 고치면 나는 게 정상이고, 그저 받아들이고 정리하면 그만입니다. 문제는 이걸 머리로는 알아도 감정으로 못 받아들이는 분이 많았다는 거죠.

돌이켜 보면 충돌을 유독 싫어하던 분들은, 어쩌면 남과 코드로 부딪히고 조율하는 그 과정 자체가 불편했던 게 아닐까 싶습니다. 충돌 메시지가 뜨면 "내가 뭘 잘못했나" 하고 굳어 버리는 거죠. 도입 초기엔 이런 분들이 절반을 넘었습니다. 그래서 저는 기능 설명보다 "충돌은 사고가 아니라 일상"이라는 걸 납득시키는 데 더 많은 시간을 썼어요.

지금이야 Git이 안 깔린 회사를 찾기가 더 어렵습니다. 신입도 입사 첫날 자연스럽게 git clone을 치죠. 하지만 그 당연함이 처음부터 있던 건 아닙니다. 저를 포함한 수많은 개발자가 이 회사 저 회사 다니며 하나씩 도입시키고, 겁먹은 동료를 붙들고 충돌을 함께 풀어 준 시간이 쌓여서 만들어진 문화입니다. 리누스가 열흘 만에 씨앗을 심었다면, 그 씨앗을 각 현장에 옮겨 심은 건 이름 없는 실무자들이었던 셈이에요.

11. Git과 다른 버전 관리 시스템 비교

지금까지 나온 시스템들을 한눈에 정리하면 이렇습니다.

반응형

항목	Git	SVN	Mercurial	BitKeeper
출시	2005	2000	2005	2000
만든 곳	리누스 토르발스	CollabNet	올리비아 매콜	래리 맥보이
방식	분산형	중앙 집중식	분산형	분산형
라이선스	GPL v2 (무료)	Apache 2.0 (무료)	GPL v2 (무료)	상용 (유료)
오프라인 작업	가능	불가	가능	가능
학습 난이도	높은 편	쉬운 편	보통	보통
2026년 위상	사실상 표준	레거시 유지보수	일부 사용	사실상 종료

표에서 보듯 Mercurial은 Git과 거의 같은 시기에, 같은 이유(BitKeeper 사태)로 태어났습니다. 기술적으로는 더 낫다는 평가도 있었지만, 리눅스 커널 개발팀이 Git을 택하면서 흐름이 그쪽으로 굳었죠. 좋은 기술이 이기는 게 아니라, 큰 판이 채택한 기술이 이긴다는 걸 보여 주는 사례이기도 합니다.

자주 묻는 질문

Git과 GitHub는 같은 건가요?

다릅니다. Git은 내 PC에서 코드 버전을 관리하는 도구(소프트웨어)이고, GitHub는 그 Git 저장소를 인터넷에 올려 공유하고 협업하게 해 주는 서비스(플랫폼)입니다. Git 없이도 GitHub는 의미가 없고, GitHub 없이도 Git은 잘 돌아갑니다.

Git이라는 이름은 무슨 뜻인가요?

약자가 아니라 영국식 영어 속어로 밉살스럽고 고집 센 사람을 뜻합니다. 리누스 토르발스가 자기 자신을 농담 삼아 그렇게 부르며 붙인 이름입니다.

정말 10일 만에 만든 게 맞나요?

대략 맞습니다. 2005년 4월 3일경 착수해 4월 7일 첫 커밋을 했고, 약 2주 뒤엔 실제 리눅스 커널을 관리하기 시작했습니다. "10일"은 이 흐름을 대중적으로 표현한 것으로, GitHub 공식 블로그도 이 표현을 씁니다.

마무리

2005년 4월, 핀란드 개발자 한 명이 BitKeeper 사태에 몰려 급하게 만든 도구가 20년 뒤 전 세계 개발의 기본기가 되리라고는 누구도 예상하지 못했을 겁니다. 리누스 본인조차 "리눅스를 잘 만들기 위한 도구"쯤으로 여겼으니까요.

그런데 저는 이 이야기에서 리누스만큼이나 현장의 몫이 컸다고 봅니다. 열흘 만에 만든 도구가 정말로 표준이 되기까지는, 겁먹은 동료 옆에서 충돌 하나를 같이 풀어 주던 수많은 시간이 필요했거든요. 오늘 터미널에서 git commit을 칠 때, 그 한 줄 뒤에 리누스의 짜증과 위트, 그리고 도구를 현장에 옮겨 심은 사람들의 품이 함께 담겨 있다는 걸 떠올려 보면 좋겠습니다.

📚 함께 보면 좋은 글

지라(Jira) 완벽 가이드: 프로젝트 관리의 표준이 된 이유와 핵심 원리

노션이 바꾼 건 메모가 아니라 회사의 문서 문화였습니다

[프로젝트 관리] 돈 쓰지 마세요! 무료 끝판왕 '레드마인(Redmine)' 완벽 가이드 (Jira와 비교 분석)

트렐로(Trello) 칸반보드, 도요타 공장에서 시작된 무료 협업 도구의 역사와 실전 활용법

깃(Git)과 깃허브(GitHub) 차이, 깃 호스팅 4대장 정리 (feat. 죽다 살아난 CodeCommit)