버전 관리가 존재하는 이유: 펜드라이브 문제

Source: Dev.to

그때는 버그를 감당할 수 있었지만, 작업을 저장하는 것은 마치 폭탄을 해체하는 것 같은 느낌이었습니다.
이 파일이 맞는가? 다른 사람이 이미 수정했는가? 이 작업이 다른 사람의 수시간 작업을 지워버릴까? 팀에게는 되돌리기 버튼이 없었다—되감기도, 안전망도 없고, 오직 희망뿐이었다.

그리고 폴더들은? 절박한 이름들로 가득 차 있었다:

final
final_final
final_final_please_work
dont_touch_this_one

이것은 과장이거나 향수가 아니라; 개발자들의 일상이었으며, 바로 이것이 버전 관리가 탄생한 이유이다.

문제는 구체적이었다

Git 같은 도구가 존재하기 전에는 코드가 클라우드에 안전하게 보관되지 않았습니다. 코드는 USB 드라이브를 통해, 이메일로, 공유 폴더 안에서, 그리고 FTP 서버를 거쳐 사람에서 사람으로 옮겨졌습니다. 코드는 추적된 이력의 일부가 아니라 물리적인 문서처럼 이동했습니다.

본질적으로 버전 관리 시스템은 한 가지 근본적인 문제를 해결합니다: 여러 사람이 서로의 작업을 지우지 않고 같은 코드를 어떻게 함께 작업할 수 있을까?

개발자들은 코드를 워드 문서처럼 다루었습니다—열고, 편집하고, 저장하고, 덮어쓰기. 매번 덮어쓸 때마다 이야기의 일부가 사라졌습니다.

Source: …

Collaboration before version control

프로젝트 전체를 담고 있는 하나의 USB 드라이브를 작은 팀이 공유하고 있다고 상상해 보세요.

1. Developer A가 코드를 수정하고 저장한 뒤 드라이브를 넘깁니다.
2. Developer B가 다른 부분을 편집하고 저장하면서 A의 작업을 덮어씁니다.
3. Developer C는 아직 오래된 사본을 사용하고 있어 그곳에 변경을 추가합니다.

드라이브가 다시 돌아올 때, 아무도 알 수 없습니다:

• 최신 버전이 어느 것인지?
• 실제로 동작하는 버전이 어느 것인지?
• 어떤 변경이 버그를 일으켰는지?
• 왜 인턴이 반쯤 완성된 코드를 푸시했는지?

이것은 부주의한 습관이 아니라 당시 팀이 일할 수 있는 유일한 방법이었습니다. 핵심 질문들은 여전히 답을 찾지 못했습니다:

• 누가 이 변경을 했는가?
• 어떤 파일을 믿어야 하는가?
• 언제 이 버그가 처음 나타났는가?
• 왜 한 컴퓨터에서는 정상적으로 실행되지만 다른 모든 곳에서는 실패하는가?
• 누군가가 직접 프로덕션에서 테스트했는가?

프로젝트가 커지면서 펜드라이브는 이메일 첨부 파일, FTP 업로드, 공유 회사 폴더 등으로 대체되었지만 문제는 그대로였습니다: 코드는 공유됐지만 변경 사항은 추적되지 않았다. 개발자들은 파일과 폴더를 복제하는 방법에 의존했으며, 그 결과 디렉터리 이름이 끊임없이 늘어났습니다:

project_final
project_final_v2
project_latest
project_latest_final
project_latest_final_please_work

각 이름은 작은 희망의 표시였습니다. 한 번의 부주의한 저장이 며칠간의 진행을 지워버릴 수 있었던 이유는 나쁜 습관 때문이 아니라 워크플로우 자체가 안전한 협업을 지원하지 않았기 때문이었습니다.

실제 전환점: Linux와 BitKeeper

Linux는 매일 수천 명의 기여자가 코드를 변경하는 대규모 글로벌 프로젝트였습니다. 2002년부터 Linux 프로젝트는 BitKeeper라는 독점 도구에 의존했습니다. 2005년에 무료 사용이 중단되면서 커뮤니티는 의존하던 시스템을 갑자기 잃게 되었고, 진행 속도가 느려졌습니다.

BitKeeper를 대체할 충분히 강력한 오픈소스 대안이 없었기에, Linus Torvalds는 좋은 옵션이 없을 때 흔히 하는 일을 했습니다: 그는 직접 만들었습니다. 그 결과가 Git입니다.

Git의 탄생

Git은 첫 날부터 보기 좋게 혹은 사용하기 쉽게 만들어진 것이 아니다. 대규모 혼란을 처리하도록 설계되었다. 목표는 간단하면서도 엄격했다:

• 작업을 절대 잃지 않음 – 모든 변경 사항은 저장되어야 한다.
• 매우 큰 프로젝트 지원.
• 극도로 빠름.
• 분산 팀에 잘 맞음, 단일 중앙 서버에 의존하지 않는다.

Git은 개발자를 편안하게 만들기 위해 설계된 것이 아니라, 협업을 신뢰할 수 있게 만들기 위해 설계되었다.

Git이 개발을 바꾼 방법

개발자들이 한때 정상으로 받아들였던 문제들이 갑자기 해결책을 갖게 되었습니다:

• 삭제되거나 덮어쓴 코드를 복구할 수 있게 되었습니다.
• 충돌하는 변경 사항을 깔끔하게 해결할 수 있었습니다.
• 팀 작업이 구조화되고 예측 가능해졌습니다.
• 모든 변경 사항에 영구적인 기록이 남게 되었습니다.

버전 관리가 임시 방편이 아니라 현대 소프트웨어 개발의 핵심이 되었습니다.

이제 개발자들은 다음을 할 수 있게 되었습니다:

• 걱정 없이 새로운 아이디어를 시도할 수 있습니다.
• 별도의 브랜치에서 기능을 작업할 수 있습니다.
• 실수를 몇 초 만에 되돌릴 수 있습니다.
• 자신감을 가지고 협업할 수 있습니다.

오류가 두렵지 않게 되었고, 학습의 순간으로 바뀌었습니다.

영향

• 오픈‑소스 프로젝트가 빠르게 성장했습니다.
• 개인 프로젝트가 덜 위험하게 느껴졌습니다.
• 팀이 변화에 더 개방적이 되었습니다.
• 개발이 덜 스트레스가 되었습니다.

Git은 실수를 없애지는 않았지만, 실수에 대한 두려움을 없앴습니다.

Clarifying the difference between Git and GitHub

• Git – 컴퓨터에 설치되는 소프트웨어 도구로, 코드 변경 사항을 추적합니다. 오프라인에서도 동작하며 인터넷 연결이 필요 없습니다.
• GitHub (and similar services) – Git 저장소를 온라인에 저장하고, 이슈, 풀 리퀘스트, 코드 리뷰와 같은 협업 기능을 추가하며, 사람들이 함께 작업할 수 있도록 돕는 웹사이트입니다.

Git이 먼저 존재했으며, GitHub가 이를 모든 사람에게 확산시키는 역할을 했습니다. Git은 개발자들이 다음 번 화려한 도구를 쫓아서 생겨난 것이 아니라, 기존 워크플로우가 압박에 의해 무너지기 시작하면서 등장한 것입니다.

앞으로의 전망

Git이 성숙해지면서 GitHub, GitLab, Bitbucket, SourceForge, AWS CodeCommit, Perforce 등 전체 생태계가 형성되었습니다—각각이 자체적인 방식으로 협업을 해결합니다. 특히 GitHub는 개발자들이 공개적으로 협업하고 아이디어가 공개적으로 성장하는 공유 무대로 진화했습니다.

다음 기사에서는 Git이 존재하는 이유에서 작동 방식으로 이동하여, Git 기본 개념과 필수 명령을 단계별로 탐구할 것입니다.