바이브코딩 7편: Git은 버전 관리보다 체크포인트라고 이해하면 편하다

바이브코딩을 하다 보면 어느 순간부터 "만드는 속도"보다 "안전하게 돌아갈 수 있느냐"가 더 중요해집니다. AI에게 기능 하나를 부탁했는데 파일 세 개가 같이 바뀌고, 화면은 얼핏 좋아진 것 같은데 어디가 어떻게 달라졌는지는 잘 안 보일 때가 있죠. 이 시점부터는 실수하지 않는 것보다, 실수했을 때 돌아갈 지점을 갖고 있는 것이 훨씬 중요해집니다.

그래서 이번 글에서는 Git을 너무 거창하게 설명하지 않겠습니다. 초보자에게 지금 필요한 건 협업 이론보다 체크포인트를 남기고, 비교하고, 필요할 때 되돌아가는 습관입니다. 이 감각만 잡혀도 AI와 같이 작업할 때 훨씬 덜 불안해집니다.

이번 글은 개념 설명으로만 끝내지 않겠습니다. 실제로 프로젝트 폴더에서 저장소를 만들고, 변경 상태를 확인하고, 커밋을 하나 남기고, 잘못 바꾼 파일을 되돌려보는 데까지 같이 가보겠습니다. 초보자 기준에서는 이 정도 실습이 들어가야 Git이 비로소 손에 잡히기 시작합니다.

이번 글에서 먼저 잡아둘 핵심

초보자가 흔히 느끼는 점	실제로 보면 더 단순한 구조	가장 먼저 익혀야 할 것
Git은 복잡한 협업 도구처럼 느껴진다	지금 단계에서는 "체크포인트를 남기는 도구"처럼 보는 편이 훨씬 낫다	상태 확인 -> 담기 -> 커밋 -> 되돌리기 흐름
git add를 하면 그 파일이 끝난 줄 안다	add는 그 순간의 내용만 담고, 그 뒤 수정은 다시 add 해야 한다	staged와 unstaged를 구분해서 보는 감각
VS Code Source Control은 그냥 옆 메뉴처럼 보인다	변경 파일, diff, staging, commit이 한 흐름으로 묶인 핵심 화면이다	변경 파일부터 보고 diff로 확인하는 습관

이번 글의 핵심 한 줄
Git은 처음부터 협업 전략으로 외우기보다, "지금 잘 되는 상태를 이름 붙여 저장해두는 도구"처럼 이해하는 편이 훨씬 편합니다.

---

왜 지금 Git을 붙여야 하는가

초보자가 Git을 미루는 건 아주 자연스러운 일입니다. 당장 HTML, CSS, JavaScript도 익숙하지 않은데 또 새로운 도구가 하나 더 생기는 것처럼 느껴지기 때문입니다. 그런데 실습을 조금만 해보면 오히려 반대라는 걸 알게 됩니다. 코드를 더 잘 쓰게 된 다음에 Git을 붙이는 것보다, 아직 작은 프로젝트를 다룰 때부터 체크포인트 습관을 들이는 편이 훨씬 낫습니다.

이유는 단순합니다. 지금 단계에서는 프로젝트가 아직 작아서 Git의 효과를 이해하기 쉽습니다. 파일이 몇 개 안 되니 무엇이 바뀌었는지 비교하기도 좋고, 잘못 건드렸을 때도 "아, 여기 전 상태로 돌아가면 되겠구나"라는 감각을 잡기 좋습니다. 반대로 나중에 기능도 많고 파일도 많아진 뒤 처음 Git을 배우면, 도구 자체보다 상황이 더 복잡해서 부담이 커지기 쉽습니다.

• AI에게 큰 수정 요청을 하기 전에 현재 상태를 남길 수 있습니다.
• 기능이 잘 되던 지점과 꼬이기 시작한 지점을 나눠서 볼 수 있습니다.
• 무엇을 바꿨는지 말로만 기억하지 않고 기록으로 남길 수 있습니다.
• 코드를 되돌릴 수 있다는 안정감이 생겨서, 실험을 조금 더 차분하게 해볼 수 있습니다.

핵심 포인트
Git을 처음 배울 때는 "협업 도구"보다 실습을 망치지 않기 위한 저장 지점으로 이해하는 편이 훨씬 편합니다.

---

Git을 너무 어렵게 생각하지 말자

초보자가 Git에서 가장 먼저 막히는 지점은 명령어보다 개념입니다. 용어가 낯설고, 설명을 보다 보면 작업 트리니 스테이징이니 커밋이니 하는 단어가 한꺼번에 나옵니다. 그런데 지금 단계에서는 아주 단순하게만 이해해도 충분합니다.

Git의 흐름은 사실 세 칸으로 생각하면 편합니다.

Git을 가장 단순하게 보면

구역	쉽게 말하면	초보자 기준에서의 의미
지금 작업 중인 상태	방금 고친 현재 파일 상태	아직 마음대로 바뀔 수 있는 구역
다음 저장 지점에 넣을 내용	이번 체크포인트에 담아둘 변경	지금 커밋에 포함할 것만 고르는 구역
실제로 남겨둔 체크포인트	나중에 다시 볼 수 있는 기록	비교와 복구의 기준점

여기서 가장 중요한 건 두 번째 칸입니다. 초보자에게는 이게 조금 낯설 수 있습니다. 그냥 저장하면 끝날 것 같은데, 왜 한 번 더 고르는 과정이 있느냐는 생각이 들기도 합니다. 그런데 이 구분이 있기 때문에 "아무 변경이나 다 넣는 커밋"과 "이번 수정만 따로 남긴 커밋"을 나눌 수 있습니다.

물론 초반에는 너무 섬세하게 쪼개지 않아도 괜찮습니다. 처음에는 그냥 이번에 안정적으로 돌아가는 상태를 하나 남긴다 정도로 시작해도 충분합니다. 중요한 건 완벽한 Git 사용법이 아니라, 프로젝트에 시간 순서가 생긴다는 점입니다.

---

10분 실습: 첫 체크포인트 직접 만들기

이제 직접 한 번 해보겠습니다. 이번 실습은 Git 개념을 외우는 게 아니라, "폴더를 열고 -> 저장소를 만들고 -> 변경을 보고 -> 커밋 하나를 남기는 흐름"을 손으로 익히는 데 목적이 있습니다.

1) 실습 폴더를 엽니다

아래처럼 아주 단순한 폴더 하나면 충분합니다.

git-lab/
  index.html
  style.css

VS Code로 이 폴더를 엽니다. 이 단계에서 중요한 건 파일 하나가 아니라 폴더 단위로 여는 것입니다. Git은 보통 폴더 전체를 기준으로 움직이기 때문입니다.

2) 저장소를 시작합니다

터미널로 하면 아래처럼 시작할 수 있습니다.

git init
git status

VS Code 화면 기준으로는 Source Control로 가서 Initialize Repository를 누르면 됩니다. 둘 중 어느 쪽으로 하든 결과는 같습니다. 지금 폴더를 Git으로 관리하기 시작한다는 뜻입니다.

3) 파일을 하나 수정합니다

예를 들어 index.html 안에 제목 한 줄을 넣습니다.

<h1>Git 체크포인트 실습</h1>

이제 다시 상태를 확인합니다.

git status

이 단계에서는 "어떤 파일이 바뀌었는지"만 보이면 충분합니다. 아직 커밋까지 간 게 아니라, 지금 작업 중인 상태가 바뀐 것뿐입니다.

4) 이번 체크포인트에 담습니다

git add .
git status

여기서 중요한 건 두 번째 상태 확인입니다. add를 한 뒤 상태가 어떻게 달라졌는지 한 번 더 보는 습관이 중요합니다. 그래야 "지금 커밋될 내용"과 "아직 작업 중인 내용"이 나뉘어 보이기 시작합니다.

5) 커밋을 남깁니다

git commit -m "실습용 제목 추가"
git log --oneline

이제야 비로소 첫 체크포인트가 생긴 겁니다. 초보자에게는 이 순간이 중요합니다. "아, 지금 이 상태를 이름 붙여 저장해두는 거구나" 하는 감각이 생기기 시작하기 때문입니다.

핵심 포인트
실습에서 중요한 건 명령어를 많이 아는 게 아니라, 수정 -> 상태 확인 -> 담기 -> 커밋 이 흐름이 손에 들어오는 것입니다.

---

git add, git status, git commit은 실제로 어떻게 이어질까

초보자가 Git에서 가장 자주 헷갈리는 부분은 add입니다. add를 하면 파일이 "끝났다"고 느끼기 쉬운데, 실제로는 그 순간의 내용만 다음 커밋 후보에 올려두는 것에 가깝습니다. 이 차이를 모르고 가면 status 화면이 갑자기 이상하게 보이기 시작합니다.

아래처럼 아주 짧게 실험해보면 바로 감이 옵니다.

1. index.html을 수정합니다.
2. git add index.html을 실행합니다.
3. 그 직후 index.html을 한 줄 더 수정합니다.
4. 다시 git status를 봅니다.

그러면 같은 파일이 "이미 담긴 변경"과 "아직 안 담긴 변경"을 동시에 가진 것처럼 보일 수 있습니다. 처음 보면 이상하지만, 사실은 자연스러운 결과입니다. Git은 add를 누른 시점의 내용을 따로 잡아두고 있기 때문입니다.

이 흐름에서 초보자가 꼭 이해해야 할 것

순간	Git이 보는 상태	무엇을 해야 하나
수정 후 add 전	아직 작업 중인 변경	status로 먼저 본다
add 직후	그 시점의 내용이 다음 커밋 후보가 된다	커밋 전 다시 수정했다면 add를 다시 해줘야 한다
commit 직후	그때 담겨 있던 내용이 체크포인트로 저장된다	log로 기록을 확인한다

즉, add는 "저장 완료"가 아니라 "이번 커밋에 넣을 버전 고르기"에 더 가깝습니다. 이 감각이 생기면 staged와 unstaged가 왜 나뉘는지도 훨씬 덜 이상하게 보입니다.

핵심 포인트
git add를 한 뒤 파일을 또 수정했다면, 최신 내용을 커밋에 넣으려면 add를 다시 해야 합니다.

---

VS Code에서는 어디부터 보면 되는가

터미널 명령을 전부 몰라도 괜찮습니다. VS Code 안에서도 Git 흐름은 꽤 잘 보입니다. 중요한 건 "그냥 옆 메뉴 하나"로 지나치지 않고, 이 화면이 변경 확인 -> 담기 -> 커밋을 한 번에 묶어주는 핵심 화면이라는 걸 아는 것입니다.

초보자 기준으로는 아래 순서만 기억해도 충분합니다.

1. Source Control 화면을 엽니다.
2. 바뀐 파일 목록을 봅니다.
3. 파일을 눌러서 diff 화면으로 무엇이 달라졌는지 확인합니다.
4. 플러스 버튼으로 파일을 staging 합니다.
5. 커밋 메시지를 쓰고 commit 합니다.

이 흐름이 좋은 이유는 바뀐 줄을 눈으로 확인한 뒤 바로 커밋으로 이어지기 때문입니다. 초보자는 종종 터미널만 "진짜 Git"처럼 느끼는데, 실제로는 Source Control 화면이 오히려 더 읽기 쉽게 해주는 경우도 많습니다.

같은 작업을 VS Code와 터미널로 보면

하려는 일	VS Code 화면	터미널 명령
저장소 시작	Initialize Repository	git init
변경 확인	Changes 목록, diff editor	git status
담기	파일 옆 + 버튼	git add . 또는 git add 파일명
커밋	메시지 입력 후 Commit	git commit -m "메시지"

초보자 기준으로는 Source Control 화면을 먼저 익히고, 그다음 같은 행동이 터미널에서는 어떤 명령인지 연결해보는 편이 훨씬 편합니다.

핵심 포인트
VS Code의 Source Control은 "Git 옆 메뉴"가 아니라, 초보자에게는 오히려 가장 읽기 쉬운 Git 입구에 가깝습니다.

---

되돌리기는 이렇게 나눠서 생각하면 편하다

Git이 진짜 편해지는 순간은 잘 저장했을 때보다, 잘못 바꿨을 때입니다. 다만 여기서도 너무 복잡하게 볼 필요는 없습니다. 초보자 기준에서는 상황을 세 가지 정도로 나누면 충분합니다.

1) 아직 커밋하지 않은 변경을 버리고 싶을 때

이 경우는 가장 단순합니다. 방금 수정한 파일이 마음에 들지 않으면 현재 작업만 버리면 됩니다.

git restore index.html

이 명령은 지금 수정한 파일을 이전 상태로 되돌리는 흐름으로 이해하면 됩니다. 다만 되돌리고 나면 방금 수정한 내용은 사라지기 때문에, 정말 버려도 되는 상태인지 한 번 더 확인하는 편이 좋습니다.

2) 커밋은 했지만, 그냥 다음 커밋으로 고치면 되는 경우

초보자에게는 이 경우가 생각보다 많습니다. 이미 남긴 커밋을 지우려 하기보다, 문제를 고친 새 커밋을 하나 더 남기는 편이 훨씬 안전한 경우가 많기 때문입니다.

이 방식의 좋은 점은 기록이 남는다는 겁니다. 나중에 봐도 "무엇을 잘못했고, 어떻게 고쳤는지"가 시간 순서로 남습니다.

3) 이미 남긴 커밋의 효과를 되돌리고 싶을 때

이럴 때는 예전 커밋을 없애기보다, 그 효과를 반대로 되돌리는 새 기록을 만드는 흐름이 있습니다.

git revert 커밋아이디

아직은 이 명령을 자주 쓸 단계는 아닐 수 있습니다. 다만 "되돌리기에도 기록을 남기는 방식이 있다"는 점은 알아두는 편이 좋습니다. 반대로 강하게 되감는 명령은 지금 단계에서는 섣불리 손대지 않는 쪽이 훨씬 안전합니다.

핵심 포인트
처음 Git에서는 "멋지게 없애기"보다 안전하게 되돌리고 기록을 남기기 쪽이 더 중요합니다.

---

AI와 같이 작업할 때 Git이 왜 더 중요해지는가

바이브코딩에서는 이 질문이 꽤 중요합니다. Git을 알고 있어도 타이밍이 흐리면 실제로 잘 안 쓰게 되기 때문입니다. 커밋은 자주 남기되, 아무 때나 마구 남기기보다 작업 단위가 분명할 때 남기는 편이 좋습니다.

초보자 기준에서는 아래 순간들이 특히 좋습니다.

• 큰 수정 요청을 하기 직전
• 기능 하나가 안정적으로 동작하기 시작한 직후
• 오류를 고쳐서 다시 정상 상태로 돌아온 직후
• 파일 구조를 크게 바꾸기 직전

Codex를 같이 쓸 때는 이 점이 더 중요합니다. Codex의 review pane은 "Codex가 건드린 줄만" 보여주는 게 아니라, 현재 Git 저장소 전체의 변경 상태를 기준으로 보여줍니다. 즉, 저장소가 있어야 바뀐 내용을 읽기 훨씬 좋아집니다.

예를 들어 큰 수정 전에 아래처럼 체크포인트를 남겨두고 시작할 수 있습니다.

git add .
git commit -m "프로필 카드 기본 기능 안정화"

그다음 Codex에게는 이런 식으로 묻는 편이 좋습니다.

지금 상태는 기본 기능이 정상 동작하는 버전이야.
이 상태를 유지하면서 저장 기능만 추가하고 싶어.
수정 전에 어떤 파일을 왜 바꿀지 먼저 설명해줘.

이렇게 하면 AI도 현재 안정 상태를 기준으로 움직이기 쉬워집니다. 그리고 내가 보기에도 "무엇이 이번 턴의 변경인지"를 훨씬 읽기 쉬워집니다.

핵심 포인트
바이브코딩에서 Git은 단순한 버전 관리 도구를 넘어서, AI가 크게 흔들기 전에 내가 기준점을 남겨두는 장치에 더 가깝습니다.

---

마무리

Git은 처음 보면 어렵고, 설명을 듣다 보면 더 어려워 보일 때도 있습니다. 그런데 초보자 기준에서는 그렇게 볼 필요가 없습니다. 지금 단계에서 Git은 협업 이론보다 실습을 망치지 않기 위한 체크포인트 도구에 더 가깝습니다.

이번 글에서 중요한 건 명령어를 많이 외운 게 아닙니다. 오히려 수정 -> 상태 확인 -> 담기 -> 커밋 흐름을 한 번 손으로 해봤다는 점, 그리고 add 뒤에 또 수정하면 왜 status가 달라 보이는지까지 이해하기 시작했다는 점이 더 중요합니다. 이 감각이 붙으면 Git이 훨씬 덜 추상적으로 느껴집니다.

여기까지 직접 해봤다면, 이제부터는 AI가 크게 수정해도 예전처럼 막막하지 않을 겁니다. 일단 돌아갈 지점은 남길 수 있고, 무엇이 바뀌었는지도 diff로 다시 볼 수 있기 때문입니다. 그 안정감이 생각보다 큽니다.