⏪Git 기초
코드의 타임머신
Git의 기본 개념을 녹음 스튜디오의 다중 테이크에 비유하여 배웁니다.
Git 기초 — 코드의 타임머신
바이브 코딩에서 AI는 여러분 대신 코드를 작성합니다. 하지만 AI도 실수를 합니다. 잘 작동하던 코드를 AI가 "개선"하다가 망가뜨리는 일은 생각보다 자주 일어납니다.
이때 Git이 없다면, 이전에 잘 작동하던 코드를 복구할 방법이 없습니다. Git은 바이브 코딩의 필수 안전망입니다.
레코딩 스튜디오에서 보컬을 녹음한다고 상상해보세요.
첫 번째 테이크: 괜찮지만 후반부가 아쉬움 → 저장 두 번째 테이크: 후반부는 좋은데 도입부가 불안 → 저장 세 번째 테이크: 전체적으로 안정적 → 저장
프로듀서는 세 개의 테이크를 모두 보관하고 있다가, 나중에 가장 좋은 것을 선택하거나, 부분적으로 편집(comp)합니다.
Git은 코드의 다중 테이크 시스템입니다.
- 매 테이크(커밋)마다 그 시점의 전체 코드를 저장합니다
- 언제든 이전 테이크로 돌아갈 수 있습니다
- 두 테이크를 비교해서 무엇이 달라졌는지 확인할 수 있습니다
- 테이크마다 메모를 남겨서 나중에 쉽게 찾을 수 있습니다
Ableton의 Undo(Ctrl+Z)가 작업 중에만 유효한 것과 달리, Git의 기록은 영구적입니다. 컴퓨터를 껐다 켜도, 한 달이 지나도, 언제든 과거의 어떤 시점으로 돌아갈 수 있습니다.
왜 Git이 바이브 코딩에 필수인가
바이브 코딩에서 Git이 특히 중요한 이유를 구체적으로 살펴봅시다.
이유 1: AI는 실수한다
AI가 "이 코드를 더 효율적으로 개선할게요"라고 하면서 기존에 잘 작동하던 코드를 완전히 다시 쓸 때가 있습니다. 결과가 더 나빠지면?
Git이 있다면: git checkout 한 번이면 원래대로 돌아옵니다.
Git이 없다면: 이전 코드를 기억하고 다시 타이핑해야 합니다. (불가능에 가깝습니다)
이유 2: 실험을 자유롭게 할 수 있다
"MediaPipe 대신 TensorFlow.js를 써볼까?" 같은 실험을 할 때, Git으로 현재 상태를 저장해두면 마음 편하게 시도할 수 있습니다. 실패하면 돌아오면 그만이니까요.
이유 3: AI에게 맥락을 제공한다
Git 히스토리를 보면 프로젝트가 어떻게 발전해왔는지 알 수 있습니다. AI에게 "이전 커밋과 비교해서 뭐가 달라졌어?"라고 물으면, 정확한 변경 사항을 알려줍니다.
"AI에게 코드 수정을 요청하기 전에, 반드시 현재 상태를 Git으로 저장하세요."
이것은 녹음 전에 반드시 "REC" 버튼을 누르는 것과 같습니다. 녹음 버튼을 안 누르고 연주하면, 아무리 훌륭한 연주도 사라집니다.
Git 핵심 명령어 — 하나씩 배우기
Git에는 수십 가지 명령어가 있지만, 바이브 코딩에 필요한 것은 7개뿐입니다. 각 명령어를 음악 비유와 함께 자세히 알아봅시다.
1. git init — 새 프로젝트 녹음 시작
새 프로젝트 폴더에서 git init을 실행하는 것은,
레코딩 스튜디오에서 새 세션을 시작하는 것과 같습니다.
Pro Tools에서 "New Session"을 누르면 프로젝트 폴더가 만들어지고,
이후의 모든 녹음과 편집이 그 세션 안에 기록되죠.
git init도 마찬가지로, 이후의 모든 코드 변경이 Git에 기록됩니다.
프로젝트 폴더 생성
mkdir my-mediapipe-project — 새 폴더를 만듭니다.
Ableton에서 새 프로젝트 폴더를 만드는 것과 같습니다.
폴더 안으로 이동
cd my-mediapipe-project — 폴더 안으로 들어갑니다.
Git 초기화
git init — 이 폴더를 Git이 관리하는 프로젝트로 만듭니다.
.git이라는 숨겨진 폴더가 생기는데, 여기에 모든 기록이 저장됩니다.
이것은 세션 파일이 저장되는 숨겨진 폴더와 같습니다.
새 프로젝트뿐 아니라, 이미 파일이 있는 프로젝트에서도 git init을 실행할 수 있습니다.
기존 파일은 그대로 있고, 이 시점부터 변경 사항을 추적하기 시작합니다.
2. git add — 이번 테이크에 포함할 파일 선택
멀티트랙 녹음에서, 이번 테이크에 어떤 트랙을 녹음할지 선택하는 것과 같습니다.
예를 들어 8트랙 중에서:
- 트랙 1 (보컬) → 이번에 녹음 ✓
- 트랙 2 (기타) → 이번에 녹음 ✓
- 트랙 3 (드럼) → 이번엔 패스 ✗
git add는 변경된 파일 중에서 이번 커밋(테이크)에 포함할 파일을 선택합니다.
이것을 "스테이징(staging)"이라고 부릅니다.
녹음할 트랙을 ARM(무장)하는 것과 같은 개념입니다.
git add . (점 포함)은 현재 폴더의 모든 변경 파일을 스테이지에 올립니다.
"모든 트랙을 한꺼번에 녹음 대기"시키는 것과 같습니다.
"그냥 모든 변경 사항을 자동으로 저장하면 안 되나?"라고 생각할 수 있습니다.
하지만 실제 작업에서는 여러 파일을 동시에 수정하되, 관련 있는 변경만 하나의 커밋으로 묶고 싶은 경우가 많습니다.
예를 들어, 손 제스처 인식 코드를 수정하면서 동시에 UI 색상도 바꿨다면, 두 변경을 별도의 커밋으로 나누는 것이 나중에 문제를 추적하기 쉽습니다.
마치 보컬 녹음과 기타 녹음을 별도의 테이크로 관리하는 것과 같습니다.
3. git commit — 테이크 저장
git commit은 녹음 버튼을 눌러서 테이크를 확정하는 것과 같습니다.
그리고 -m 옵션으로 메모를 남깁니다.
마치 테이크 시트에 "Take 3 — 후렴구 강하게, 템포 약간 빠르게"라고
적어두는 것처럼, 커밋 메시지에는 "무엇을 왜 변경했는지" 적습니다.
좋은 커밋 메시지 작성법
커밋 메시지는 미래의 자신(또는 AI)이 읽을 메모입니다.
나쁜 예시:
"수정"— 무엇을 수정했는지 알 수 없음"ㅋㅋ"— 의미 없음"asdf"— ...
좋은 예시:
"MediaPipe 손 추적 기능 추가"— 무엇을 했는지 명확"OSC 포트를 9000에서 8000으로 변경"— 구체적인 변경 내용"카메라 에러 처리 추가 — 카메라 없을 때 안내 메시지 표시"— 무엇을 왜 했는지
커밋 메시지는 "이 커밋은 ___을(를) 한다" 형식으로 쓰세요.
- "이 커밋은 MediaPipe 손 추적 기능을 추가한다" ✓
- "이 커밋은 OSC 포트를 변경한다" ✓
한국어든 영어든 상관없습니다. 일관성이 더 중요합니다.
4. git log — 지금까지의 테이크 목록
git log는 녹음실의 테이크 시트를 확인하는 것과 같습니다.
"아까 세 번째 테이크가 좋았는데..." 할 때, 테이크 시트를 보고 몇 시 몇 분에 녹음했는지, 어떤 메모가 있는지 확인하는 것입니다.
각 줄의 앞에 있는 알파벳+숫자 조합(예: d4e5f6g)은 커밋 해시라고 합니다.
각 테이크의 고유 번호와 같습니다. 이 번호로 특정 테이크를 찾을 수 있습니다.
5. git checkout — 이전 테이크로 돌아가기
git checkout은 이전 테이크를 다시 불러오는 것과 같습니다.
"세 번째 테이크가 제일 좋았는데, 그때로 돌아가자"
— 이것이 git checkout입니다.
현재 작업 중인 내용은 그대로 유지하면서, 과거의 특정 시점을 "듣기만" 할 수도 있고, 아예 그 시점으로 "되돌아가기"도 할 수 있습니다.
이전 커밋으로 이동하면 "detached HEAD" 상태가 됩니다. 겁먹지 마세요! 이것은 단순히 "과거를 구경 중"이라는 의미입니다.
현재(최신)로 돌아오려면:
6. git diff — 이전 테이크와 비교
git diff는 두 테이크를 A/B 비교하는 것과 같습니다.
마스터링할 때 EQ 적용 전후를 비교하는 것처럼, 코드의 "이전 버전"과 "현재 버전"을 나란히 비교합니다.
빨간색(-)은 삭제된 부분, 초록색(+)은 추가된 부분입니다. 마치 "이 부분은 빠지고(빨간), 이 부분이 추가됐다(초록)"는 마크업과 같습니다.
위 예시에서:
max_hands가 1에서 2로 변경됨 (손 두 개 추적)osc_port가 9000에서 8000으로 변경됨
7. git status — 현재 상태 확인
git status는 믹싱 콘솔의 미터를 확인하는 것과 같습니다.
"지금 어떤 트랙이 녹음 대기(staged)인지, 어떤 트랙이 수정됐는지, 어떤 트랙이 아직 프로젝트에 추가되지 않았는지"를 한눈에 보여줍니다.
이 출력의 의미:
- Changes to be committed: 다음 커밋에 포함될 파일 (ARM 된 트랙)
- Changes not staged: 수정됐지만 아직
git add안 한 파일 (수정했지만 ARM 안 한 트랙) - Untracked files: Git이 아직 관리하지 않는 새 파일 (프로젝트에 없는 새 트랙)
실전 연습: Git 워크플로우
이제 배운 명령어를 조합하여 실제 작업 흐름을 연습해봅시다.
프로젝트 만들기 + Git 시작
새 프로젝트 폴더를 만들고 Git을 초기화합니다.
첫 번째 파일 만들기
간단한 Python 파일을 만듭니다. (AI에게 시켜도 되고, 직접 써도 됩니다)
첫 번째 커밋 (테이크 1)
현재 상태를 저장합니다.
AI에게 코드 수정 요청
바이브 코딩으로 AI에게 수정을 요청합니다. "main.py에 MediaPipe 초기화 코드를 추가해줘"
AI가 코드를 수정하면...
변경 사항 확인
AI가 무엇을 바꿨는지 확인합니다.
마음에 들면 커밋 (테이크 2)
변경 사항이 마음에 들면 저장합니다.
마음에 안 들면 되돌리기
만약 AI의 수정이 마음에 안 들거나 에러가 났다면? 커밋하기 전이라면 이렇게 원래로 되돌립니다.
이미 커밋했다면 이전 커밋으로 돌아갑니다.
바이브 코딩에서의 Git 습관
습관 1: 자주 커밋하기 코드가 정상 작동할 때마다 커밋하세요. 녹음에서 좋은 테이크가 나올 때마다 저장하는 것처럼요. 커밋은 무료입니다 — 아끼지 마세요.
습관 2: AI에게 수정 시키기 전에 커밋하기 AI에게 "이 코드를 개선해줘"라고 말하기 전에, 현재 상태를 반드시 커밋하세요. "Save before solo" — 솔로 녹음 전에 반드시 세션을 저장하는 것과 같습니다.
습관 3: 실험 전에 커밋하기 "혹시 이 방법이 더 나을까?" 하고 실험하기 전에 커밋하세요. 실험이 실패하면 깔끔하게 돌아올 수 있습니다.
Git 명령어 치트 시트
자주 참조할 수 있도록 모든 명령어를 정리합니다:
이 장에서는 로컬 Git만 다뤘습니다. GitHub(원격 저장소)에 코드를 올리고 공유하는 방법은 이후 장에서 배웁니다.
지금은 여러분의 컴퓨터 안에서 코드의 "다중 테이크"를 관리하는 것에 집중하세요. 다음 장에서는 드디어 첫 바이브 코딩을 실습합니다! 지금까지 배운 Git과 안전장치를 활용하여, AI와 함께 첫 번째 웹페이지를 만들어봅시다.