GIT가 존재하는 이유: 펜드라이브 문제

Source: Dev.to

펜드라이브 문제

Git이 없는 세상을 상상해 보세요:

1. 새로운 기능이 필요해서 친구 리시에게 도움을 요청합니다.
2. 프로젝트 전체를 압축하고 펜드라이브에 복사한 뒤 건네줍니다.
3. 리시가 기능을 개발하고, 업데이트된 코드를 다시 압축해서 펜드라이브를 반환합니다.

프로젝트를 압축 해제하면 여러 문제가 발생합니다:

• 작성자 가시성 부족 – 어느 부분을 누가 작성했는지 알 수 없습니다.
• 변경 내용 불명확 – 나중에 버그가 생겨도 어떤 부분이 어떻게 바뀌었는지 알 수 없습니다.
• 시간이 많이 드는 리뷰 – 리시와 함께 파일을 한 줄씩 비교해야 합니다.
• 충돌 및 낭비된 노력 – 수정 과정에서 중요한 코드를 실수로 변경하거나 삭제할 수 있어, 전체 프로젝트를 다시 디버깅해야 합니다.

여러 개발자가 같은 코드베이스에서 작업해야 한다면 상황은 더욱 악화됩니다:

• 모든 변경마다 전체 프로젝트를 압축하고 펜드라이브를 옮겨야 합니다.
• 펜드라이브를 가진 사람만 작업할 수 있어 동시에 작업이 불가능합니다.
• 누가 어떤 파일을 수정했는지 추적하는 것이 사실상 불가능합니다.

개발자들이 필요로 했던 것

변경 추적

다음과 같은 기능을 갖춘 시스템:

• 코드에 이루어진 모든 변경을 기록한다.
• 각 변경의 작성자를 저장한다.
• 이전 버전과 새로운 버전 사이의 차이점(diff)을 보여준다.
• 전체 버전 히스토리를 유지한다.

협업 지원

• 여러 개발자가 동시에 접근할 수 있는 단일 진실 원본(single source of truth).
• 최신 코드를 pull하고 독립적으로 작업한 뒤 push할 수 있는 기능.
• 파일을 수동으로 교환하지 않아도 다른 사람의 기여를 즉시 확인할 수 있다.

Git의 탄생

Linus Torvalds는 급속히 성장하는 Linux 커널을 관리하기 위해 Git을 만들었습니다. 프로젝트가 커지면서 기존의 변경 추적 방식은 감당할 수 없게 되었습니다. Git은 **분산 버전 관리 시스템(DVCS)**을 도입해 변경 추적과 협업 문제를 동시에 해결했습니다.

• 분산 – 모든 개발자가 저장소 전체 복사본을 가지고 있어 단일 장애 지점을 없앱니다.
• 빠름 – 커밋, 브랜치, 병합 같은 작업이 로컬에서 수행됩니다.
• 신뢰성 – 암호화 해시를 사용해 데이터 무결성을 보장합니다.

GitHub(및 유사한 호스팅 서비스)는 저장소를 보관할 수 있는 중앙 서버를 제공해 개발자들이 쉽게 공유하고 협업할 수 있게 합니다.

GitHub 대안

GitHub가 가장 인기 있는 호스팅 Git 서비스이지만, 다음과 같은 대안도 있습니다:

• Bitbucket
• GitLab
• Gitea
• Codeberg

기타 버전 관리 시스템

Git이 주류가 되기 전에는 다음과 같은 VCS 도구가 사용되었습니다:

• AWS CodeCommit
• Apache Subversion (SVN)
• Unity Version Control
• Fossil
• Concurrent Versions System (CVS)

결론 및 다음 주제

Git은 “펜드라이브 문제”와 변경 추적 및 협업이라는 광범위한 과제를 해결하기 위해 등장했습니다. 이 역사를 이해하면 현대 소프트웨어 개발에서 Git의 강력함을 더욱 잘 평가할 수 있습니다.

다음 글에서는 Git이 내부적으로 어떻게 동작하는지를 살펴보고, 핵심 개념을 탐구하며, .git 디렉터리 구조를 분석해 실제로 어떤 일이 일어나는지 알아볼 예정입니다.