안녕하세요 구독자님,
오늘부터 격일로 5회에 걸쳐 "바이브코더를 위한 Git의 모든 것"을 연재합니다.
혹시 이런 경험 있으신가요?
"Claude Code나 GPT가 짜준 코드를 조금씩 수정하다가, 어느 순간 갑자기 오류가 나기 시작했는데 도대체 언제부터 잘못된 건지 감이 안 잡히더라고요. 그때 "아, 30분 전으로만 돌아갈 수 있다면..." 하고 후회한 적이요."
처음 바이브코딩을 시작하면 모두가 겪는 고통입니다. AI가 생성한 코드를 그냥 반영 또 반영하다가, 뭔가 꼬이면 처음부터 다시 시작하곤 하죠. 시간도 아깝고 스트레스도 이만저만이 아닙니다.
왜 바이브코더에게 Git이 절실한가
AI와 함께 코딩하는 시대, 우리는 전통적인 개발자보다 훨씬 더 많은 실험을 합니다.
"이 부분을 좀 다르게 해볼까?"
"Claude Code말고 GPT 버전도 시도해볼까?"
"어? 이전 버전이 더 나았던 것 같은데..."
하루에도 수십 번씩 코드가 바뀝니다. 그런데 이 모든 변경사항을 기억할 수 있을까요? 불가능하죠.
Git은 코드의 타임머신입니다.
게임할 때 세이브 포인트 만들듯이, 코드가 잘 돌아가는 순간마다 '커밋'이라는 저장 지점을 만들어둡니다. 나중에 뭔가 꼬였을 때 "아, 그때 그 버전으로!" 하고 돌아갈 수 있는 거죠.
AI 시대에 Git이 더 중요해진 3가지 이유
- 실험의 자유 AI가 제안한 코드가 마음에 안 들어도 괜찮습니다. 일단 시도해보고, 안 되면 되돌리면 그만이니까요. Git이 있으면 "일단 해보자"는 마인드를 가질 수 있습니다.
- AI별 버전 관리 Claude Code가 만든 버전, GPT가 만든 버전, Gemini가 만든 버전... 각각을 따로 보관하고 비교할 수 있습니다. 마치 여러 디자이너에게 시안을 받아보는 것처럼요.
- 점진적 개선의 기록 "어제보다 오늘 코드가 나아졌나?" Git의 히스토리를 보면 한눈에 알 수 있습니다. AI와 함께 성장하는 과정이 고스란히 기록됩니다. 바이브코더의 포트폴리오가 되는겁니다.
상상 사례: OO의 첫 Git 경험
OO가 처음 Git의 위력을 실감한 건 간단한 랜딩 페이지를 만들 때였습니다.
처음엔 Claude Code에게 기본 구조를 만들어달라고 했죠. 마음에 들어서 그대로 진행했습니다. 그런데 디자인을 수정하다가 레이아웃이 완전히 깨져버렸어요.
당황하지 않고 git log를 입력했더니, OO가 Claude Code와 만든 저장 포인트들이 쭉 나타났습니다:
- "사이트 초기 레이아웃"
- "헤더 색상 변경"
- "폰트 추가"
- "반응형 디자인 시도" ← 여기서 문제 발생!
git checkout으로 "폰트 추가" 시점으로 돌아가니, 깨끗한 상태로 복구됐습니다. 10초 만에요!
'git checkout 08f4add'를 실행하면 해당 시점으로 되돌아간다
혹은 AI에게 "08f4add로 돌아가자(체크아웃해줘)" 라고 해도 된다
오늘부터 시작하는 첫걸음
Git은 복잡해 보이지만, 사실 우리가 매일 쓸 명령어는 5개 정도입니다:
- git init (프로젝트 시작하기)
- git add (변경사항 준비)
- git commit (저장 포인트 만들기)
- git log (히스토리 보기)
- git checkout (시간여행하기)
Git을 안다는건 게임으로 치면 다시 도전할 수 있는 목숨을 여러개 선물 받은것과 같습니다. 코딩의 진정한 Vibe를 즐기실 수 있도록 오늘부터 저와 함께 Git을 내 것으로 만들어보시는거 어떨까요?
Git 설치와 오늘 소개된 Git 명령어들의 사용법 그리고 실전 꿀팁이 궁금하시다면 아래 부록을 참고해주세요.
다음 편 예고: "여러 AI 에이전트를 동시에 굴리는 방법" - 브랜치라는 평행우주를 만들어, Claude Code와 GPT가 동시에 다른 버전을 만들게 하는 비법을 공개합니다! 🚀
그럼 금요일에 뵙겠습니다!
(*아래 내용은 부록입니다)
실습: Git 설치와 첫 커밋 & 롤백
Git 설치하기 (macOS/Windows)
- macOS: 터미널을 열고 Homebrew 패키지 매니저로 Git을 설치합니다.
brew install git- _Homebrew_가 없다면 먼저 Homebrew를 설치해야 합니다 (홈브류 홈페이지 참고). 설치 후 git --version 명령으로 버전이 출력되면 성공입니다.
- Windows: 공식 사이트 git-scm.com에 접속해 Git for Windows 설치 프로그램을 다운로드합니다. 설치 마법사의 기본 옵션을 따라 진행하세요. 설치 후 “Git Bash” 터미널을 열어 git --version으로 버전을 확인합니다.
설치가 완료됐다면, 다음으로 사용자 정보를 설정해야 합니다. 깃 커밋에는 작성자의 이름과 이메일이 기록되는데, 협업이나 이력 관리 시 중요합니다:
git config --global user.name "사용자이름"
git config --global user.email "이메일주소"위 명령으로 전역 설정을 하면 앞으로 생성하는 모든 커밋에 이 이름과 이메일이 들어갑니다. (--global을 빼면 현재 프로젝트에만 설정)
로컬 깃 저장소 초기화와 첫 커밋
이제 실제 프로젝트 폴더에서 Git을 사용해보겠습니다:
- 저장소 초기화: Git으로 관리하려는 프로젝트 폴더를 하나 만들고, 폴더 안에서 터미널을 엽니다.
git init- 위 명령을 실행하면 해당 디렉터리가 깃 저장소로 초기화됩니다. 숨김 폴더로 .git 디렉터리가 생성되고, Git이 이 폴더를 통해 버전 이력을 관리합니다. (터미널에는 “Initialized empty Git repository in …” 등의 메시지가 표시됩니다.)
- 파일 생성 및 변경 추적: 프로젝트에 예시로 hello.txt 파일을 만들고 편집해봅니다. 파일을 생성하거나 수정하면 Git은 아직 커밋되지 않은 변경으로 인식합니다. 변경 내용을 확인하려면:
git status- 빨간색으로 표시된 파일명이 현재 Git이 추적하지 않는(new) 변경 파일입니다.
- 스테이징(staging): 커밋하기 전에, 어떤 변경을 커밋에 포함시킬지 스테이지 해야 합니다. 모든 변경 파일을 커밋에 포함하려면:
git add .- .은 현재 디렉터리의 모든 변경 파일을 뜻합니다. 특정 파일만 커밋하려면 git add 파일이름으로 지정할 수도 있습니다. git status를 다시 실행하면, 추가한 파일들이 녹색으로 표시되며 커밋 준비 완료 상태(staged)가 된 것을 확인할 수 있습니다.
- 커밋(commit): 이제 스테이지에 올린 변경들을 기록합니다.
git commit -m "첫 커밋 메시지"- -m 옵션은 커밋 메시지를 인라인으로 입력하는 용도로, 커밋 메시지는 변경 내용을 요약하는 한 줄 설명입니다. 예를 들어 "Add hello.txt with greeting message"처럼 작성하면 좋습니다. 이 명령을 실행하면 해당 시점의 파일 상태가 영구히 커밋 이력에 남습니다. git status를 다시 보면 “작업 트리가 깨끗함”이라는 메시지가 나오는데, 이는 현재 변경이 전부 커밋돼 밀린 변경사항이 없다는 뜻입니다.
- 히스토리(log) 확인: 커밋이 여러 개 쌓이면 git log로 전체 이력을 볼 수 있습니다. 간단히 한 줄짜리 요약으로 보려면:
git log --oneline- 각 커밋이 한 줄씩 고유한 해시 ID와 메시지로 표시됩니다. 방금 만든 첫 커밋이 리스트에 나타날 것입니다. 이 로그를 통해 언제 어떤 변경이 있었는지 추적할 수 있습니다.
커밋 롤백: 되돌리기의 안전한 방법
커밋을 해두면 코드 상태를 안전하게 돌려볼 수 있습니다. “롤백(rollback)”이란 이전 커밋 상태로 코드를 되돌리는 작업인데, Git에서는 주로 두 가지 방법을 사용합니다: git revert와 git reset입니다.
- 과거 커밋 내용 조회: 우선 특정 커밋의 상태를 잠시 확인하고 싶다면 _분기_를 이동하는 방식으로 과거 상태를 볼 수 있습니다.
git checkout <커밋ID>- <커밋ID>는 git log --oneline 등으로 본 커밋 해시의 앞 몇 자리만 적어도 됩니다. 이 명령을 실행하면, 현재 작업 디렉토리가 해당 커밋 시점의 파일 상태로 바뀝니다. (HEAD가 분리된 상태로 과거 커밋을 열람하는 것이며, 이 상태에서 작업하면 분기가 생기므로 주의) 과거 버전 파일들을 읽거나 복사할 수 있지만, 이 상태에서 직접 개발을 계속하진 않습니다. 과거 확인이 끝나면, 원래 브랜치로 돌아오기 위해 git checkout main (또는 사용 중인 브랜치명)으로 복귀하세요.
- 되돌리는 커밋 생성 (git revert): 이미 push(푸시)했거나 히스토리를 보존해야 할 상황에서는 git revert를 사용하는 것이 권장됩니다. 리버트는 지정한 기존 커밋의 변경 내용을 반대로 적용하는 “새 커밋”을 만들어 되돌립니다. 즉, 히스토리를 보존하면서 내용만 무르기 때문에 안전합니다. 예를 들어 최근 커밋이 문제를 일으켰다면:
git revert <문제가 된 커밋ID>- 이렇게 하면 자동으로 해당 커밋을 취소하는 새로운 커밋이 생성됩니다. 이 새로운 커밋은 “Revert ‘문제된 커밋 메시지’”와 같이 기록되어, 되돌린 사실이 로그에 남습니다. 장점: 다른 협업자가 봤을 때도 어떤 변경을 되돌렸는지 투명하게 파악할 수 있습니다.
- 강제로 과거 상태로 초기화 (git reset --hard): 마지막 수단으로, 특정 커밋 시점으로 아예 분기 자체를 이동시켜 이후의 기록을 지워버릴 수도 있습니다.
git reset --hard <돌아갈 커밋ID>- 이 명령을 실행하면 현재 브랜치가 지정한 옛 커밋을 가리키도록 이동하고, 작업 트리도 그 상태로 강제 변경됩니다. 예컨대 main 브랜치의 최근 5개 커밋을 날리고 5커밋 전 상태로 되돌아가는 격입니다. 주의: 이렇게 하면 해당 지점 이후의 커밋들은 로컬 저장소에서 사라지며, 작업 내용도 되돌릴 수 없게 제거됩니다. 이미 원격에 푸시한 커밋을 reset하면 저장소 이력이 꼬이기 때문에 절대 푸시된 이력에는 사용하면 안 됩니다. 오직 내 로컬에서 잘못된 실험을 모두 폐기하고 처음부터 다시 할 때만 사용하세요. 안전망으로 reset 전 현재 폴더를 복사하거나, reset 후 바로 git push --force가 필요함도 인지해야 합니다. (가능하면 revert로 해결하고, reset –hard는 최소한으로 사용하는 것이 좋습니다.)
요약하면, git revert는 안전하게 “실수 되돌리기” 커밋을 추가하고, git reset --hard는 시간 자체를 되감아버리는 위험한 방법입니다. 대부분의 상황에서는 revert로 충분하며, 프로젝트 이력을 깨끗이 유지해야 하는 특별한 경우에만 reset –hard를 고려하세요.
체크리스트 ✅
- Git이 올바르게 설치되고 git --version으로 확인하였다.
- git config로 사용자 이름과 이메일을 설정하였다.
- 로컬 프로젝트 디렉토리를 git init으로 깃 저장소로 만들었다.
- 파일을 수정하고 git add → git commit으로 변경 내역을 커밋해보았다.
- git log --oneline으로 커밋 이력을 확인하였다.
- git revert로 특정 커밋을 취소하는 새 커밋을 만들어보았다 (또는 개념을 이해했다).
- 필요 시 git reset --hard의 효과와 위험성을 이해하고, 신중하게 사용할 것이다.
의견을 남겨주세요