버전 관리가 존재하는 이유: 펜드라이브 문제
Source: Dev.to
위에 있는 Source 라인은 그대로 두고, 번역하고 싶은 본문 내용을 알려주시면 한국어로 번역해 드리겠습니다.
Introduction
Git이 현대 소프트웨어 개발의 핵심이 되기 전, 협업은 매우 취약하고 수동적이며 놀라울 정도로 원시적이었습니다.
개발자들은 저장소를 복제하거나 커밋을 푸시하지 않았습니다. 대신 펜드라이브를 주고받았습니다.
각 펜드라이브에는 같은 프로젝트의 약간씩 다른 버전이 들어 있었습니다. 어느 것이 올바른 버전인지, 누가 무엇을 변경했는지, 버그가 언제 도입됐는지 아무도 알 수 없었습니다. 한 번의 잘못된 덮어쓰기로 며칠치 작업이 사라질 수 있었습니다.
이는 드문 불편함이 아니라 팀워크를 느리게 만들고 위험을 높이며 확장성을 저해하는 구조적인 문제였습니다.
그 일상적인 고통이 결국 개발자들로 하여금 코드가 어떻게 공유되고, 추적되며, 신뢰될 수 있는지를 재고하게 만들었습니다. 이 혼란 속에서 소프트웨어 개발을 영원히 바꿔 놓은 시스템, Git이 탄생했습니다.
이 글에서는 Git이 왜 만들어졌는지, 그 이전에 어떤 문제들이 있었는지, 그리고 현대 버전 관리 시스템이 등장하기 전 개발자들이 코드를 어떻게 관리했는지 살펴보겠습니다.
버전 관리가 왜 존재하는지를 이해하기 전에, 먼저 버전 관리가 실제로 무엇인지 명확히 해봅시다.
인터넷에 따르면, Version control (리비전 컨트롤, 소스 컨트롤, 혹은 소스‑코드 관리라고도 함)은 컴퓨터 파일, 주로 소스 코드를 추적하고 관리하는 소프트웨어 엔지니어링 실천입니다.
그 정의는 기술적으로 들리지만, 개념은 간단합니다.
버전 관리는 코드의 변화를 추적하여 언제, 무엇이 바뀌었는지 확인하고, 문제가 발생했을 때 이전 버전으로 되돌릴 수 있게 해주는 방법입니다.
다시 말해, 코드에 기억을 부여하는 것입니다.
그렇다면 진짜 질문은: 처음부터 왜 이런 것이 필요했을까?
펜드라이브 시대
시간을 거슬러 Git이 없는 세상을 상상해 봅시다.
당신은 프로젝트를 진행 중인 개발자입니다. 어느 날 새로운 기능을 구현하는 데 도움이 필요해 친구인 Abdul에게 협업을 요청합니다. 그는 동의하고 코드를 달라고 합니다.
코드를 공유하기 위해 프로젝트를 압축하고 펜드라이브에 복사해 그에게 보냅니다. Abdul은 기능을 구현하고, 업데이트된 프로젝트를 다시 압축해 펜드라이브를 돌려보냅니다.
프로젝트를 압축 해제했을 때 첫 번째 문제가 명확해집니다: 코드가 방대하고 누가 어떤 부분을 작성했는지 전혀 알 수 없습니다. 기능이 동작하니 이 문제는 무시하고 진행합니다.
몇 일 뒤, Abdul이 작성한 기능에서 버그를 발견합니다. 전체 프로젝트를 다시 펜드라이브에 담아 그에게 보냅니다. 그는 버그를 수정하고 다시 돌려줍니다.
이제 코드는 바뀌었지만 무엇이 바뀌었는지 혹은 어디가 바뀌었는지 알 수 없습니다. 변경 사항을 이해하려면 함께 앉아 라인‑바이‑라인으로 비교해야 하는데, 이는 시간 소모가 큽니다.
또 다른 큰 문제는 Abdul이 코드를 작업하는 동안 당신이 안전하게 작업할 수 없다는 점입니다. 만약 동시에 작업한다면 두 사람 모두 같은 프로젝트의 서로 다른 버전을 갖게 되어 충돌과 낭비된 노력이 발생합니다.
코드베이스가 커지고 개발자가 늘어날수록 이러한 문제는 더욱 고통스러워집니다. 세 번째 개발자 Chitra가 작업에 합류한다고 상상해 보세요. 세 사람 모두 실시간으로 협업하면서 동기화가 깨지지 않도록 할 방법이 없습니다.
또 다른 문제는 무엇이 언제 업데이트됐는지, 누가 업데이트했는지를 확인할 수 없고, 전체 변경 타임라인을 파악할 수 없다는 점입니다. 시간이 흐를수록 이전 버전은 사라지고, 완전히 버그가 난 코드베이스와 알려진 좋은 상태로 되돌릴 방법이 없게 됩니다.
Simple example:
- Abdul은 기능의 버그를 수정하고 코드를 변경한 뒤, Chitra의 기능도 문제가 있어 그녀에게 펜드라이브를 넘깁니다.
- Chitra는 추가 수정을 진행합니다.
- 펜드라이브가 결국 당신에게 돌아올 때, 프로젝트에 무슨 일이 일어났는지 전혀 알 수 없습니다.
Version‑Control Systems 이전에 겪은 문제들
- 덮어쓴 코드 – 마지막으로 저장한 사람이 종종 다른 사람의 작업을 지워버렸습니다.
- 잃어버린 변경 사항 – 오래된 복사본 때문에 몇 시간 동안 작업한 것이 사라질 수 있었습니다.
- 협업 이력 부재 – 누가 무엇을 왜 바꿨는지 추적할 신뢰할 만한 방법이 없었습니다.
- 시간 낭비 – 동시에 안전하게 작업할 수 있는 개발자는 한 명뿐이었습니다.
- 끊임없는 혼란 – 팀이 어떤 버전의 코드가 올바른지 파악하기 어려웠습니다.
Source: …
버전 관리가 펜드라이브 문제를 해결한 방법
이제 이러한 문제들을 해결하는 방법을 생각해 보겠습니다.
첫 번째 과제는 누가 어떤 변경을 했는지 추적하는 것입니다. 이를 해결하기 위해 다음과 같은 소프트웨어 시스템을 만든다고 상상해 보세요.
- 코드 변경을 추적한다.
- 각 변경의 작성자를 저장한다.
- 이전 코드와 새로운 코드의 차이를 보여준다.
- 전체 버전 히스토리를 유지한다.
이 솔루션은 첫 번째와 두 번째 문제, 즉 변경 추적과 기여자 식별을 해결합니다.
간단한 아이디어가 떠오릅니다: 변경이 커밋될 때마다 작성자, 타임스탬프, 상황 설명을 기록하는 도구를 만든다. 이를 CCT (Code Changes Tracker) 라고 부릅시다. 펜드라이브에 CCT를 배포하면… 문제 해결?
부분적으로는 그렇습니다. CCT는 누가 언제 무엇을 변경했는지 로그를 제공하지만, 여전히 펜드라이브를 수동으로 배포해야 하므로 동기화, 충돌 해결, 중앙 히스토리 관리라는 핵심 문제는 남아 있습니다.
다음 단계는 추적 시스템을 공유 가능한 네트워크 접근 저장소로 옮기고, 브랜치와 병합 기능을 추가하며, 변경 배포를 자동화하는 것이었습니다. 이 진화가 현대 버전 관리 시스템, 궁극적으로 Git을 탄생시켰습니다.
# From Pendrives to Distributed Version Control
Developers used to **copy code onto a pendrive**, hand it to a teammate, and hope the changes didn’t get lost.
If something went wrong, the only way to recover was to **re‑create the history manually**.
Now we can **see the history and revert**, which was not possible before.
실시간 협업 문제
적절한 버전 추적이 있더라도 각 개발자는 여전히 프로젝트의 로컬 복사본을 가지고 있었습니다.
모두가 히스토리를 가지고 있었지만, 반드시 같은 히스토리를 가지고 있지는 않았습니다.
핵심 질문은 다음으로 바뀌었습니다.
- “누가 이것을 변경했나요?”
- “무엇이 변경됐나요?”
에서:
- “모두가 작업해야 할 버전은 어느 것인가?”
이는 더 이상 단순한 버전 관리 문제가 아니라 협업 및 조정 문제가 되었습니다. 왜냐하면 소스 코드는 여전히 하나의 물리적 위치에 존재했기 때문에 동시에 한 명의 개발자만 작업할 수 있었기 때문입니다.
첫 번째 시도: 중앙 서버
개발자들은 코드를 저장하기 위해 클라우드 서버를 구축하고 이를 CCTS (Code Changes Tracker Server) 라고 명명한 뒤, CCT를 그곳에 배포했습니다.
이 시점에서 펜드라이브 시대는 끝난 듯 보였습니다.
- 변경을 추적하는 시스템
- 코드를 저장하는 서버
- 함께 작업하는 여러 개발자
하지만 초기 중앙 집중형 버전 관리 시스템은 여전히 치명적인 약점을 가지고 있었습니다: 모든 것이 중앙 서버에 의존한다는 점입니다.
- 서버가 다운되면 개발이 중단됩니다.
- 서버가 데이터를 잃으면 프로젝트 히스토리가 사라집니다.
- 개발자는 그 단일 머신에 지속적으로 접근하지 못하면 자유롭게 작업할 수 없습니다.
즉, 협업은 가능했지만 매우 취약했습니다.
Git을 다르게 만든 아키텍처 전환
Git은 모델을 완전히 뒤집었습니다. 중앙 서버가 전체 히스토리를 보관하는 대신, 각 개발자가 전체 코드베이스와 그 전체 히스토리의 완전한 복사본을 받습니다.
이 덕분에 개발자는 다음을 할 수 있게 되었습니다.
- 오프라인 작업
- 안전한 실험
- 장애 복구
- 단일 장애 지점 없이 협업
서버는 공유 조정 지점이 될 뿐, 의존성이 아니라 협업을 돕는 역할을 합니다.
핵심 인사이트
- CCT (Code Changes Tracker) 는 Git — 분산 버전 관리 시스템을 의미합니다.
- CCTS (Code Changes Tracker Server) 는 GitHub 같은 플랫폼을 의미합니다. 이 플랫폼은 협업을 더 쉽게 만들지만, Git이 동작하는 데 필수적인 요소는 아닙니다.
Git의 탄생
Git은 Linus Torvalds가 그의 주요 프로젝트인 Linux를 관리하기 위해 만들었습니다. Linux가 성장함에 따라 변경 사항을 추적하는 것이 매우 어려워졌습니다. 개발자들은 빠르고 효율적이며 대규모 분산 팀에 적합한 상용 VCS인 BitKeeper를 시도했습니다. BitKeeper는 Linux 커뮤니티에 무료 라이선스를 제공했기 때문에 그들은 이를 채택했습니다.
그러나 커뮤니티 구성원 중 한 명이 BitKeeper를 역공학하려고 시도했으며, 이는 제작자들을 화나게 했습니다. 신뢰가 깨졌고, BitKeeper에 대한 무료 접근이 취소되었습니다.
중요한 도구를 잃은 상황에서 Linus는 다시는 상용 소프트웨어에 의존하지 않겠다고 다짐했습니다. 그는 자체 분산 버전 관리 시스템을 만들기 시작했습니다—무료이고, 오픈소스이며, 완전히 독립적입니다.
그리고 Git이 탄생했습니다.
Alternatives to Git (VCS)
- SCCS (소스 코드 제어 시스템)
- RCS (리비전 제어 시스템)
- CVS (동시 버전 시스템)
- Mercurial
- Apache Subversion
- Fossil
- AWS CodeCommit
GitHub 대안 (호스팅 플랫폼)
- Bitbucket
- GitLab
- Gitea
- Codeberg
결론
버전 관리가 이론이나 모범 사례에서 나온 것이 아니라 고통에서 탄생했습니다.
펜드라이브 시대는 변경 사항을 추적할 신뢰할 만한 방법도, 공유된 히스토리도, 확장 가능한 협업 모델도 없을 때 어떤 일이 일어나는지를 보여주었습니다. 코드가 덮어써지고, 버그를 추적하기 어려웠으며, 팀워크는 단순히 확장되지 못했습니다.
- Git은 모든 변경을 히스토리로 기록함으로써 추적 문제를 해결했습니다.
- GitHub, GitLab, Bitbucket과 같은 플랫폼은 팀에게 공유된 협업 공간을 제공함으로써 조정 문제를 해결했습니다.
그래서 버전 관리는 더 이상 선택 사항이 아니라 현대 소프트웨어 개발의 기반이 됩니다.
커밋을 푸시하거나, 병합 충돌을 해결하거나, 실수를 되돌린 적이 있다면, 여러분은 펜드라이브를 주고받는 것만큼 단순하고 고통스러운 상황에서 탄생한 솔루션의 혜택을 누리고 있는 것입니다.
이 역사를 이해하는 것은 단순히 더 나은 Git 사용자가 되는 것이 아니라, 더 나은 엔지니어가 되는 것입니다.
핵심 소프트웨어 엔지니어링 개념을 초보자 친화적으로 풀어낸 글을 더 보려면 팔로우하세요.