당신은 가장 좋아하는 AI 코딩 도구로 3주 동안 앱을 빌드했습니다. 잘 작동했습니다. 그러고 나서 새로운 기능을 만들기 시작했습니다. 기능을 만들고, 변경 사항을 적용하고, 저장했습니다... 그리고 당신의 새로운 기능이 망가졌을 뿐만 아니라 원래의 앱까지 망가졌다는 사실을 발견했습니다.

이것은 당신의 AI 코딩 도구에 있는 버그가 아닙니다. 이것은 버전 관리 (Version Control) 없이 AI가 생성한 코드를 배포할 때 발생하는 현상입니다. 좋은 소식은요? 15분 안에 스스로를 보호할 수 있다는 것입니다.

이 가이드는 당신이 어떤 AI 빌더를 사용하든 상관없이, 작업 손실을 방지하고 빠른 반복 (Iteration)을 가능하게 하는 정확한 Git 워크플로우 (Workflow)를 보여줍니다.

AI가 코드를 작성할 때 Git이 중요한 이유

당신은 Git 워크플로우를 배우는 것이 아니라 수익 창출을 향해 질주하고 있습니다. 하지만 진실은 이렇습니다: 작업 내용을 잃어버리는 것이 기초를 배우는 것보다 더 느립니다.

AI가 코드의 90%를 생성할 때, Git은 당신의 생산 원장 (Production Ledger)이 됩니다. 모든 커밋 (Commit)은 복구 지점입니다. 모든 브랜치 (Branch)는 안전한 실험 공간입니다.

한 개발자는 Git 없이 Lovable에서 내보낸 후 다음과 같이 완벽하게 표현했습니다:

"버전 기록도 없고, 항목들을 별도로 테스트할 방법도 없습니다. 이건 카드 집(House of cards) 같아서 무엇 하나 건드리는 것이 두렵습니다."

Git을 전체 기능에 대한 '실행 취소 (Undo)' 버튼이라고 생각하세요. AI 프롬프트 (Prompt)가 잘못되었을 때(반드시 그렇게 될 것입니다), 몇 시간 동안 다시 만드는 대신 몇 초 만에 되돌릴 수 있습니다.

첫 번째 단계: Lovable, Base44 또는 Bolt에서 내보내는 즉시, 터미널 (Mac의 Terminal, Windows의 Command Prompt 또는 PowerShell)을 열고 프로젝트 폴더로 이동하세요. 그런 다음 다음을 실행하세요:

git init  
git add .  
git commit -m "Initial export from [platform]"

그런 다음 비공개 GitHub 리포지토리 (Repo)를 생성하고 푸시 (Push)하세요:

gh repo create my-app --private
git remote add origin https://github.com/you/my-app.git
git push -u origin main

2분이면 충분합니다. 나중에 며칠간의 복구 작업을 아껴줍니다.

...

몇 시간의 작업을 지워버리는 세 가지 실수

이것들은 안전하게 롤백 (Rollback)할 수 있는 능력이 필요하다는 것을 깨닫기 전인 첫째 주에 발생합니다.

실수 1: Main 브랜치에서 직접 작업하기

AI 코딩 도구에서 코드를 내보내고 새로운 기능을 구현하기 시작했습니다. 그런데 무언가 망가졌습니다. 이제 제품을 출시하는 대신 디버깅(Debugging)을 하고 있습니다. 이것이 바로 버전 관리(Version Control) 없이 AI가 생성한 코드를 배포할 때 발생하는 현상입니다.

해결책: 절대 main 브랜치에서 직접 작업하지 마세요. 모든 변경 사항에는 기능 브랜치(Feature branch)를 사용하세요.

## 모든 AI 코딩 세션 시작 전
git checkout -b feature/add-user-login

...

또한 Cursor나 Claude에게 기능 브랜치를 생성해 달라고 프롬프트(Prompt)를 줄 수도 있습니다:

Create a feature branch for the user login feature

그다음, 코드가 잘 작동한다면 main으로 병합(Merge)하세요:

## 잘 작동한다면, 병합하세요
git checkout main
git merge feature/add-user-login

Cursor나 Claude에게 기능 브랜치를 main으로 병합해 달라고 요청할 수도 있습니다:

...

만약 AI가 코드를 망가뜨렸다면, 브랜치를 삭제하고 다시 시작하세요:

## AI가 망가뜨렸다면, 브랜치를 삭제하고 다시 시작하세요
git checkout main
git branch -D feature/add-user-login

Cursor나 Claude에게 기능 브랜치를 삭제해 달라고 요청할 수도 있습니다:

Delete the feature branch for the user login feature

이렇게 하면 운영(Production) 코드는 안전하게 유지됩니다. AI 실험은 격리된 상태로 유지됩니다.

...

## .env.example - 이것을 커밋(Commit)하세요
STRIPE_PUBLIC_KEY=pk_test_...
OPENAI_API_KEY=sk-...
DATABASE_URL=postgresql://...

.env.example 파일은 앱을 실행하는 데 어떤 비밀 값(Secrets)이 필요한지 문서화하는 데 유용합니다.

...

이제 템플릿이 생겼습니다. 재난이 닥쳤을 때, 어떤 비밀 값을 다시 생성해야 하는지 정확히 알 수 있습니다.

.env 파일이란 무엇인가요?

.env 파일은 앱을 위한 환경 변수(Environment variables)를 포함하는 파일입니다. API 키나 비밀 값(Secrets)과 같은 민감한 데이터를 Git에 커밋하지 않고 저장하는 방법입니다.

.env.local과 .env 파일의 차이점은 무엇인가요?

차이점과 권장 사항(best practices)에 대한 자세한 설명은 전용 포스트인 Understanding .env and .env.local Files를 참조하세요.

.gitignore 파일이란 무엇인가요?

.gitignore 파일은 Git이 무시해야 할 파일과 디렉터리의 목록입니다. 이는 민감한 데이터가 Git에 커밋되는 것을 방지하는 방법입니다.

실수 3: Git 없이 프로젝트 다운로드하기

어떤 사람들은 Lovable, Replit 또는 Base44 프로젝트를 UI에서 직접 다운로드합니다. 그런 다음 코드를 직접 수정합니다.

해결책: 항상 GitHub에 연결한 다음, 로컬에 저장소(repo)를 클론(clone)하세요.

## 프로젝트 클론하기
git clone https://github.com/you/project.git project-copy

BrainGrid의 GitHub 통합 기능은 브랜치(branch) 전반에 걸쳐 요구 사항을 추적하므로, 각 브랜치가 무엇을 하고 있는지 파악할 수 있습니다.

AI 빌더를 위한 이상적인 Git 워크플로우 (Workflow)

빠르게 움직이면서도 코드를 안전하게 유지하는 브랜칭 전략(branching strategy)은 다음과 같습니다.

브랜치 구조 (Branch Structure)

gitGraph
    commit id: "Initial commit"
    branch dev
...

두 개의 주요 브랜치:

• main - 라이브 상태이거나 배포 준비가 된 프로덕션(Production) 코드
• dev - 구축 중인 기능들을 위한 통합 브랜치(Integration branch)

기능 브랜치 (Feature branches): 기능당 하나씩 생성하며, dev에서 생성합니다.

일일 워크플로우 (Daily Workflow)

오전: dev에서 새롭게 시작하기

git checkout dev
git pull origin dev
git checkout -b feature/user-profile

업무 중: 무언가 작동할 때마다 커밋(Commit)하기

## 변경 사항 테스트, 작동 확인!
git add .
git commit -m "User profile page displaying correctly"

일과 종료: 기능 브랜치 푸시(Push)하기

...

기능 완료 시: dev로 PR(Pull Request) 생성하기

feature/user-profile 브랜치에서
dev 브랜치로 Pull Request를 생성하세요

dev에 여러 기능이 준비되었을 때: main으로 머지(Merge)하기

## GitHub에서 Pull Request 생성: dev → main
## 모든 변경 사항 검토 후 PR 머지
## 릴리스(release) 태그 지정
...

Claude Code / Cursor 프롬프트:

dev 브랜치에서 main 브랜치로 Pull Request 생성

Pull Request 프로세스 (Pull Request Process)

graph LR
    A[Feature Branch] -->|Pull Request| B[dev branch]
    B -->|기능 축적 (Accumulate features)| B
    B -->|준비되면 Pull Request| C[main branch]
    C -->|태그 지정 및 GitHub로 Push| D[v1.0.0]

Feature → dev Pull Request: 개별 변경 사항을 검토하고 빠르게 머지(merge)합니다.

...

패턴: `type/short-description` (유형/짧은 설명)

**유형 (Types)**:
- `feature/` - 새로운 기능 (New functionality)
- `fix/` - 버그 수정 (Bug fixes)
- `hotfix/` - 긴급 운영 환경 수정 (Urgent production fixes)
- `refactor/` - 동작 변경 없는 코드 정리 (Code cleanup without behavior change)

## 재앙을 방지하는 데일리 습관 (Daily Habits That Prevent Disasters)

이 습관들은 30초밖에 걸리지 않지만, 복구 작업에 들어갈 수 있는 수 시간을 아껴줍니다.

### 모닝 루틴 (Morning Routine)

```bash label="Terminal"
## 최신 변경 사항 동기화 (Sync latest changes)
git checkout dev
git pull origin dev
...

기능 구현 완료 후 매번 (After Every Working Feature)

## 작동합니다! 확정하세요 (It works! Lock it in.)

git add .
git commit -m "Feature X working: [간략한 설명]"

기능이 "완벽"해질 때까지 기다리지 마세요. 코드가 지저분하더라도 작동한다면 커밋(commit)하세요.

...

## AI가 다시 생성하기 전 안전 커밋 (Safety commit before letting AI regenerate)
git add .
git commit -m "Before AI regeneration - working state"

이제 AI가 모든 것을 망가뜨리더라도, 단 한 번의 명령으로 안전을 확보할 수 있습니다:

...

### 하루 일과 종료 (End of Day)

```bash label="Terminal"
## 클라우드 백업 - 작업 내용을 절대 잃어버리지 마세요 (Cloud backup - never lose work)
git push origin feature/todays-work

노트북이 고장 나더라도, 당신의 작업물은 GitHub에 안전하게 보관되어 있습니다.

보상 (The payoff): 이러한 습관을 갖추면, 고장 난 기능 하나를 고치느라 허우적거리는 대신 매주 여러 개의 기능을 베타 사용자에게 배포할 수 있으며, 이는 제품 로드맵을 결정하는 피드백 루프(feedback loops)를 가속화합니다.

BrainGrid의 작업 시스템은 각 작업을 완료한 후 커밋하도록 상기시켜 줍니다. 이를 통해 버전 관리(version control)를 재앙이 닥친 후에야 떠올리는 것이 아니라, 내장된 습관으로 만들어 줍니다.

재앙이 닥쳤을 때: 복구 플레이북 (When Disaster Strikes: Recovery Playbook)

완벽한 습관을 가졌더라도, AI 빌더들은 때때로 혼돈을 초래하곤 합니다.

시나리오 1: AI가 모든 것을 망가뜨렸을 때 (하지만 커밋은 해둔 상태)

마지막으로 작동하던 커밋을 찾으세요:

git log --oneline

## 출력 내용: abc1234 Feature X working

## def5678 Before AI regeneration

## ghi9012 Login flow complete

git reset --hard def5678

이제 작동하던 상태로 돌아왔습니다. AI가 만든 혼돈이 사라졌습니다.

...

git push origin feature/broken-thing --force

시나리오 2: 실수로 비밀 정보(Secrets)를 커밋했을 때

...

시나리오 3: 완전한 대재앙 (최근 커밋이 없음)

AI 빌더의 버전 히스토리(version history)를 사용하세요:

Base44: 시계 아이콘 클릭 → 마지막 작동 버전 복구 (restore last working version) → 즉시 내보내기 (export) → 커밋

Lovable: GitHub 커밋 확인 (자동 동기화가 활성화된 경우) → 작동하던 커밋으로 되돌리기 (revert)

Git도 없고, 빌더 히스토리도 없다면: 기억에 의존해 다시 만들어야 합니다. 당신이 이런 상황에 처하게 두지 마세요.

핵 옵션 (The Nuclear Option)

모든 것이 망가졌고 Git 히스토리가 엉망이 되었다면:

## 마지막으로 확인된 정상 지점으로부터 새로운 복사본을 클론 (Clone)
git clone https://github.com/you/project.git project-recovery
cd project-recovery
...

복구 속도가 핵심입니다: 10분의 다운타임(downtime)과 10시간의 다운타임은 고객의 신뢰와 수익 모멘텀을 유지할 수 있는지 여부를 결정합니다.

빠른 참조: 필수 Git 명령어

설정 및 일상적인 사용

## 새로운 기능 시작
git checkout dev  
git pull origin dev  
git checkout -b feature/my-feature

## 진행 상황 저장
git add .  
git commit -m "작동하는 내용에 대한 설명"  
git push origin feature/my-feature

## 기능을 dev로 병합 (GitHub에서 PR을 통해)

## 그 다음 로컬에서:
git checkout dev  
git pull origin dev

문제가 발생했을 때

## 변경 사항 확인
git status
git diff

## 변경 사항 취소 (아직 커밋하지 않은 경우)
git checkout -- filename.ts

## 마지막 커밋 취소 (변경 사항은 유지)
git reset --soft HEAD~1

## 마지막 커밋 취소 (변경 사항을 폐기)
git reset --hard HEAD~1

## 임의의 커밋으로 되돌아가기
git log --oneline
git reset --hard <commit-hash>

브랜치 관리 (Branch Management)

...

오늘 바로 작업물을 보호하기 시작하세요

다음은 15분 만에 완료할 수 있는 설정 방법입니다:

1. 내보낸 프로젝트에서 Git 초기화 (Initialize Git)
2. GitHub 저장소 (repo) 생성 및 푸시 (push)
3. main 브랜치로부터 dev 브랜치 생성
4. .gitignore 파일 생성 (.env, node_modules, .next 추가)
5. 매일 커밋 (Commit) - 습관으로 만드세요

AI가 생성한 코드가 망가져서 롤백 (rollback)해야 하는 첫 순간이 오면, 미리 설정해두길 잘했다고 생각하게 될 것입니다.

버전 관리 (Version control)는 "복잡성을 더하는 것"이 아닙니다. 여러분이 투자한 시간을 보호하고, 유료 고객에게 더 빠르게 제품을 출시 (shipping)하기 위한 것입니다.

원문은 BrainGrid 블로그에 게시되었습니다.