107장

부록 G. Git으로 버전 관리하는 법

Git이 어떻게 버전을 기록하는지, 브랜치가 뭔지, 실제로 어떻게 쓰는지 초보자 기준으로 설명합니다.

버전 관리가 뭔가요

게임에 세이브 포인트가 있습니다. 어려운 보스 앞에서 저장하고, 죽으면 그 지점으로 돌아옵니다.

Git은 코드(파일)의 세이브 포인트를 만드는 도구입니다. 언제든 과거 상태로 돌아갈 수 있고, 누가 무엇을 바꿨는지 기록이 남습니다.

커밋 — 세이브 포인트 하나

파일을 저장하는 건 Ctrl+S입니다. 하지만 Git의 저장은 **커밋(commit)**입니다.

Ctrl+S는 “지금 이 내용 저장”이고, 커밋은 “이 시점을 영구 기록으로 남김”입니다.

[커밋 1] 초기 파일 생성
    ↓
[커밋 2] 홈 페이지 제목 변경
    ↓
[커밋 3] About 페이지 추가
    ↓
[커밋 4] 색상 수정  ← 지금 여기

이 줄을 **히스토리(history)**라고 합니다. 어느 커밋으로든 돌아갈 수 있습니다.

커밋 메시지

커밋할 때 “뭘 했는지” 한 줄 적습니다. 나중에 찾아볼 때 쓰는 메모입니다.

git commit -m "홈 페이지 제목을 '내 라이프 위키'로 변경"

기본 명령어 — add, commit, push, pull

Git을 쓸 때 매일 쓰는 명령어 네 개가 있습니다. 직접 타이핑하지 않더라도 “이게 뭔지”는 알면 좋습니다.

흐름으로 보기

내 컴퓨터에서 파일 수정
    ↓
git add      ← "이 파일들을 다음 커밋에 포함"
    ↓
git commit   ← "세이브 포인트 만들기"
    ↓
git push     ← "GitHub에 업로드"
    ↓
(Vercel이 감지 → 사이트 자동 업데이트)

반대로 GitHub에 있는 내용을 내 컴퓨터로 가져올 때는 git pull입니다. 혼자 작업하면 거의 쓸 일이 없지만, 컴퓨터 두 대를 오갈 때 필요합니다 — 노트북에서 push하고 데스크탑에서 이어 받을 때. 팀으로 작업할 때는 더 자주 씁니다. 다른 사람이 push한 내용을 내 컴퓨터에 반영할 때 pull합니다.

각 명령어 한 줄 설명

명령어	역할
`git add 파일명`	커밋에 담을 파일을 선택
`git add .`	변경된 파일 전부 선택
`git commit -m "메시지"`	선택한 파일들로 세이브 포인트 생성
`git push`	커밋들을 GitHub에 업로드
`git pull`	GitHub의 최신 내용을 내 컴퓨터로 가져오기
`git status`	지금 뭐가 바뀌었는지 확인

Claude가 대신 해줍니다

이 명령어들을 외울 필요는 없습니다. Claude Code에게 말로 하면 됩니다.

변경된 파일 커밋하고 GitHub에 올려줘.
커밋 메시지는 "홈 페이지 제목 수정"으로.

Claude가 git add, git commit, git push를 순서대로 실행해줍니다.

브랜치 — 평행 세계

**브랜치(branch)**는 같은 파일의 복사본을 따로 관리하는 공간입니다.

쉽게 말하면 실험실입니다. 원본은 그대로 두고, 복사본에서 마음껏 바꿔봅니다. 잘 되면 원본에 합치고, 아니면 그냥 버립니다.

main 브랜치 (원본 · 공식 버전)
│
├── 커밋 1
├── 커밋 2
└── 커밋 3  ← 여기서 실험 브랜치 분기
            │
            └── experiment 브랜치
                ├── 커밋 A  (새 디자인 시도)
                ├── 커밋 B  (색상 변경)
                └── 커밋 C  (완성) → main에 합치기

main 브랜치

거의 모든 프로젝트에 main이라는 기본 브랜치가 있습니다. Vercel은 main 브랜치를 보고 사이트를 배포합니다. 항상 잘 돌아가는 버전을 여기 두는 게 관례입니다.

실제로 어떻게 쓰나요

가장 흔한 패턴은 이렇습니다.

1. 브랜치 만들기

git checkout -b 새기능이름

-b는 “새 브랜치 만들면서 이동”입니다.

2. 변경하고 커밋

# 파일 수정 후
git add .
git commit -m "무엇을 했는지"

3. main에 합치기

잘 됐으면 main 브랜치로 돌아와서 합칩니다.

git checkout main
git merge 새기능이름

4. 다 쓴 브랜치 삭제

git branch -d 새기능이름

이 튜토리얼에서 실제로 한 것

이 튜토리얼 자체가 브랜치를 사용해서 만들어졌습니다.

main (원래 튜토리얼)
│
└── tutorial-v2 브랜치 분기
    ├── 필수/심화/부록 구조 추가
    ├── 1장~10장 개편
    ├── 부록 A~F 작성
    └── 완성 → main에 합침

작업하는 동안 main은 원래 상태 그대로였습니다. tutorial-v2에서 마음껏 고치고, 다 됐을 때 main에 합쳤습니다. 실수가 있어도 main은 안전했습니다.

자주 쓰는 명령어

# 현재 브랜치 확인
git branch

# 새 브랜치 만들고 이동
git checkout -b 이름

# 브랜치 이동
git checkout 이름

# 현재 브랜치에 다른 브랜치 합치기
git merge 이름

# 변경 내역 확인
git log --oneline

# 특정 시점으로 돌아가기 (조심해서)
git checkout 커밋해시

Claude에게 시키는 방법

Git 명령어를 외울 필요는 없습니다. Claude Code에게 말로 하면 됩니다.

새 브랜치 만들어서 지금 내용으로 이동해줘. 이름은 "새-디자인"으로.

지금 브랜치에서 변경한 내용을 main에 합쳐줘.

지난 5개 커밋 목록 보여줘.

3번 전 커밋 상태로 돌아가고 싶어. 어떻게 해?

바이브 코딩할 때 Git이 특히 중요한 이유

바이브 코딩 이전에는 코드 한 줄 고치는 데도 시간이 걸렸습니다. 그래서 신중하게 짜고, 한번 만든 걸 조금씩 고쳐가는 게 합리적이었습니다.

바이브 코딩은 다릅니다. 만드는 게 너무 쉬워졌습니다.

이게 버전 관리 방식도 바꿉니다.

고치는 것보다 새로 만드는 게 빠를 때가 있다

뭔가 잘 안 되는 코드가 있을 때, 예전에는 원인을 찾아서 수정하는 게 최선이었습니다. 지금은 다릅니다.

(기존 방식)
코드 안 됨 → 원인 파악 → 디버깅 → 수정 → 또 안 됨 → ...

(바이브 코딩)
코드 안 됨 → 새 브랜치 → Claude에게 처음부터 다시 만들어달라고 → 됨 → main에 합침

고치는 게 막힌다면, 그냥 새로 생성하는 게 빠릅니다.

실험 비용이 0에 가까워졌다

“이거 다른 방식으로 해보면 어떨까?”라는 생각이 드는 순간, 브랜치 하나 만들고 바로 시도해볼 수 있습니다.

main (잘 돌아가는 현재 버전)
├── experiment-A 브랜치 — 새 레이아웃 시도
├── experiment-B 브랜치 — 다른 색상 팔레트
└── experiment-C 브랜치 — 완전 다른 구조

잘 되면 main에 합치고, 아니면 브랜치째 버립니다. main은 건드리지 않았으니 언제든 원상태입니다.

예전에는 실험 하나에 큰 비용이 따랐습니다. 이제는 아닙니다. 실험을 많이 할수록 브랜치가 더 유용합니다.

요약

바이브 코딩 시대에 Git이 중요한 이유:

만들기 쉬워진 만큼 잘못 만들기도 쉬워졌다 → 되돌아갈 포인트가 필요
실험이 쉬워진 만큼 더 많이 시도하게 된다 → 각 실험을 브랜치로 분리
고치는 것보다 다시 만드는 게 나을 때 → 새 브랜치에서 깔끔하게 시작

언제 브랜치를 쓰나요

매번 쓸 필요는 없습니다. 간단한 수정은 그냥 main에서 해도 됩니다.

브랜치를 만드는 게 유용할 때:

큰 변경을 할 때 — 페이지 전체 구조를 바꾸거나, 여러 파일을 동시에 손댈 때
실험할 때 — “이게 될지 모르겠는데 한번 해볼까” 싶을 때
원본을 지키고 싶을 때 — 지금 상태가 잘 돌아가고 있어서 건드리기 무서울 때

이 튜토리얼 정도 규모에서는 “큰 개편을 하기 전에 브랜치 하나 만들고 시작한다” 정도면 충분합니다.