software

버전 관리가 중요한 이유: 펜드라이브 딜레마 극복 및 Git 메커니즘 학습

발행: (2025년 12월 30일 오전 11:40 GMT+9)
9 min read
원문: Dev.to

Source: Dev.to

Source: …

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

버전 관리 이전의 삶

프로젝트를 관리하는 것은 도박과 같았다. 개발자들은 같은 프로젝트를 여러 사본으로 만들고, 파일을 수동으로 공유하며, 중요한 것이 사라지지 않기를 바랐다. 누가 언제 어떤 변경을 했는지, 정확히 무엇이 수정됐는지 확인할 믿을 만한 방법이 없었다. 팀은 기본적으로 손가락을 교차시킨 채 작업했다.

펜드라이브 시나리오

Git 없이 팀이 작업한다면 다음과 같은 상황을 상상해 보라:

  • 개발자 A가 작업을 완료하고
  • 펜드라이브에 저장한 뒤
  • 개발자 B에게 전달하고
  • 개발자 B가 프로젝트를 수정한 뒤 개발자 C에게 넘긴다

그 사이에 개발자 A는 오래된 사본으로 계속 코딩한다. 갑자기 팀에는 여러 “최신” 버전이 생기고, 어느 것이 진짜 올바른 버전인지 아무도 확신하지 못한다.

같은 혼란은 다음과 같은 방식으로도 발생했다:

  • 이메일로 코드를 보내기
  • ZIP 파일을 주고받기

프로젝트 폴더가 끝없이 복제된다:

project-final
project-final-v2
project-latest-final
final-really-final

지금은 웃기게 들리지만, 그때는 일상적인 관행이었다.

버전 관리가 없을 때의 실제 문제

  • 파일이 경고 없이 덮어쓰기 됨
  • 안정적인 작업 코드가 영구적으로 사라짐
  • 변경 이력이 공유되지 않음
  • 누가 무엇을 왜 바꿨는지 명확히 설명할 수 없음

협업이 위험해졌다. 두 사람이 같은 파일을 수정하면, 코드를 수동으로 한 줄씩 비교해야 했다. 오류가 섞이고, 마감일이 늘어나며, 코드베이스에 대한 신뢰가 사라졌다.

오늘날 이것이 통하지 않는 이유

현대 개발은 다음을 포함한다:

  • 여러 지역에 퍼진 팀
  • 지속적인 업데이트
  • 장기 유지보수
  • 기능 실험

펜드라이브식 워크플로는 이러한 압박 하에 즉시 붕괴된다. 팀은 다음이 필요하다:

  • 신뢰할 수 있는 프로젝트 이력
  • 자동 변경 추적
  • 안전한 협업
  • 실수로부터 빠른 복구
  • 명확한 버전 타임라인

따라서 버전 관리는 선택이 아니라 필수가 되었다. 전문 작업, 교육, 오픈소스 기여, 그리고 모든 진지한 코딩 노력에 필수적이다.

버전 관리 없이:
여러 사본 → 혼란 → 이력 손실 → 우연한 덮어쓰기

버전 관리와 함께:
모두가 작업 → 변경 사항 추적 → 이력 보존 → 협업이 안전하게 유지

Source: …

Inside Git: How It Works and the Role of the .git Folder

Git Does More Than Store Files

Git은 단순히 파일을 저장하는 도구가 아닙니다. 프로젝트 전체 이력을 구조화된 방식으로 기록합니다. 저장소 내부에서 무슨 일이 일어나는지 이해하면 Git이 훨씬 덜 신비롭게 느껴집니다.

The .git Folder

다음 명령을 실행하면:

git init

Git은 .git이라는 숨김 폴더를 생성합니다. 이 폴더가 프로젝트의 두뇌 역할을 합니다. 여기에는 다음이 저장됩니다:

  • 모든 커밋
  • 브랜치 정보
  • HEAD와 같은 레퍼런스
  • 내부 객체 데이터베이스
  • 중요한 메타데이터

.git 폴더를 삭제하면 프로젝트는 이력이 없는 일반 폴더가 됩니다. 이것만으로도 .git 폴더가 얼마나 중요한지 알 수 있습니다.

Git’s Building Blocks: Blob, Tree, Commit

Blob

  • 파일의 원시 내용을 저장합니다.
  • 파일 이름은 저장하지 않고, 오직 데이터만 저장합니다.

Tree

  • 폴더를 나타냅니다.
  • 파일 이름을 저장하고, 블롭(파일)이나 다른 트리(하위 폴더)를 가리킵니다.

Commit

  • 프로젝트의 의미 있는 스냅샷을 나타냅니다.
  • 저장하는 내용:
    • 트리(프로젝트 상태)에 대한 레퍼런스
    • 작성자 정보와 시간
    • 커밋 메시지
    • 이전 커밋에 대한 링크

이 링크들이 프로젝트 이력을 형성합니다.

How Git Tracks Changes

Git은 파일을 한 줄씩 계속 비교하는 대신, 해시를 사용해 내용을 식별합니다. 저장된 각 버전은 고유한 SHA‑1 해시를 갖습니다. 아주 작은 변경이라도 완전히 다른 해시가 생성됩니다. 이는 다음을 보장합니다:

  • 강력한 무결성
  • 신뢰할 수 있는 이력
  • 조용한 손상으로부터의 보호

모든 커밋은 검증 가능합니다.

What Actually Happens During git add and git commit

When You Run git add

Git은:

  1. 파일 내용을 가져와서
  2. 블롭으로 변환하고
  3. 스테이징 영역에 넣으며
  4. 다음 커밋을 위해 준비합니다

즉, “이 파일의 정확한 버전을 기억해라”라고 말하는 것입니다.

When You Run git commit

Git은:

  1. 프로젝트 상태를 나타내는 트리를 생성하고
  2. 그 트리를 가리키는 커밋 객체를 만들고
  3. 이전 커밋들과 연결합니다

이렇게 타임라인이 만들어집니다:

Commit A → Commit B → Commit C → HEAD

각 커밋은 체인처럼 연결되어 이력을 안전하게 보존합니다.

A Simple Structural View

.git 디렉터리는 대략 다음과 같이 구성됩니다:

  • objects → 블롭, 트리, 커밋
  • refs → 브랜치와 태그
  • HEAD → 현재 브랜치를 가리킴
Commit
 └─ Tree
     ├─ Blobs (files)
     └─ More Trees (subfolders)

The Mental Model That Makes Git Easier

모든 명령을 외울 필요는 없습니다. 핵심 아이디어만 이해하면 됩니다:

  • .git은 이력이 살아 있는 곳
  • Git은 스냅샷을 저장하며, 단순히 파일만 저장하지 않음
  • 블롭은 내용 자체를 보관
  • 트리는 구조를 조직
  • 커밋은 모든 것을 이력으로 연결

이 그림이 떠오르면 Git은 예측 가능하고 논리적이며 훨씬 사용하기 편해집니다.

Back to Blog

관련 글

더 보기 »