AI와 코딩할 때 가장 무서운 순간은 오류 메시지가 아닙니다. **“어제까지 되던 것이 오늘 안 되는데, 어디를 되돌려야 할지 모르는 상태”**입니다. 버튼 색을 바꿔 달라고 했는데 로그인까지 깨지고, 에러를 고쳐 달라고 했더니 데이터 저장 방식까지 바뀌는 일이 반복됩니다.
비개발자에게 Git은 개발자처럼 명령어를 외우기 위한 도구가 아닙니다. AI가 실수해도 언제든 마지막 정상 상태로 돌아가기 위한 안전장치입니다.
Git을 딱 네 가지 개념으로 이해하기
1. Repository — 프로젝트의 공식 원본
Repository(저장소)는 코드 폴더를 “버전이 기록되는 프로젝트”로 바꿉니다. 중요한 것은 단순 백업이 아니라 언제 어떤 변화가 들어왔는지 기록된다는 점입니다.
Google Drive에 폴더를 복사해 final, final2, final_real을 만드는 것과 다릅니다. Git은 같은 프로젝트 안에서 변화의 시간축을 관리합니다.
2. Commit — 잘 되는 상태를 저장하는 세이브 포인트
Commit은 “이 시점의 파일 상태를 저장한다”는 뜻입니다. 게임의 세이브 포인트에 가깝습니다.
비개발자에게 가장 좋은 규칙은 간단합니다.
잘 되는 순간에 작게 저장한다.
예를 들어 다음처럼 나눕니다.
- 로그인 화면 UI 완성
- 이메일 로그인 동작 확인
- 카카오 로그인 추가
- 회원 프로필 저장 확인
이 네 가지를 한 번에 바꾸고 마지막에 한 번 커밋하면, 어느 변경이 문제인지 찾기 어렵습니다. 반대로 작은 단위로 저장하면 문제가 생겼을 때 되돌릴 범위가 작아집니다.
3. Branch — 운영본을 건드리지 않는 실험실
GitHub 공식 문서도 브랜치를 기능 개발이나 버그 수정, 새로운 아이디어 실험을 기존 작업과 분리하는 수단으로 설명합니다. 실무에서는 main을 항상 배포 가능한 안정 버전으로 두고, 큰 수정은 별도 branch에서 진행하는 방식이 가장 이해하기 쉽습니다.
예를 들어 AI에게 “예약 페이지 전체 UX를 바꿔줘”라고 요청하기 전에 feature/reservation-redesign 브랜치를 만듭니다. 결과가 좋으면 main에 합치고, 망가지면 브랜치 자체를 버리면 됩니다.
4. Pull Request — 본편에 넣기 전 마지막 검토
혼자 개발하더라도 Pull Request(PR)를 쓸 가치가 있습니다. “이 브랜치에서 무엇이 바뀌었는지”를 한 번에 비교할 수 있기 때문입니다. AI가 예상보다 많은 파일을 수정했는지도 이 단계에서 알 수 있습니다.
비개발자 대표가 꼭 지켜야 할 Git 운영 규칙 7개
main은 항상 서비스가 돌아가는 상태로 유지합니다.- 큰 수정 전에 새 브랜치를 만듭니다.
- 한 커밋에는 하나의 목적만 넣습니다.
- AI에게 여러 기능을 한 번에 시키지 않습니다.
- 커밋 전에 직접 최소 테스트를 합니다.
.env, API Secret, 인증키는 Git에 올리지 않습니다.- 배포된 버전과 Git의 버전을 연결합니다.
“AI한테 Git까지 시키면 되지 않나요?”
가능합니다. 오히려 좋은 방법입니다. 다만 AI에게 명령을 맡기더라도 무슨 상태를 만들고 있는지는 사람이 이해해야 합니다.
좋은 요청은 이런 형태입니다.
현재 main 브랜치는 안정 버전이야. 먼저 현재 상태가 clean인지 확인하고,
feature/payment-refund브랜치를 만들어. 수정 전에 현재 테스트 상태를 기록하고, 환불 기능에 필요한 파일만 변경해. 완료 후 변경 파일 목록과 테스트 결과를 알려줘. 내가 확인하기 전에는 main에 merge하지 마.
이 요청에는 네 가지 안전장치가 들어 있습니다.
- 기준 브랜치 확인
- 새 브랜치 분리
- 변경 범위 제한
- 자동 merge 금지
되돌리기에도 종류가 있다
“롤백해줘”라고만 말하면 AI가 어떤 방법을 쓸지 예측하기 어렵습니다. 상황을 구분해야 합니다.
아직 커밋하지 않은 수정
파일만 수정했고 저장 포인트를 만들지 않았다면 변경 파일을 확인하고 필요 없는 수정만 되돌립니다. 이때 중요한 것은 전체 폴더를 무조건 초기화하지 않는 것입니다. 다른 정상 수정까지 사라질 수 있습니다.
커밋했지만 아직 배포하지 않은 수정
문제 커밋을 되돌리는 새 커밋을 만들거나, 브랜치를 정상 커밋 지점으로 재설정할 수 있습니다. 협업 중이라면 기록을 지우기보다 “되돌리는 커밋”을 만드는 방식이 안전합니다.
이미 운영 배포된 수정
가장 먼저 서비스 복구가 우선입니다. 마지막 정상 커밋으로 배포를 되돌리고, 장애가 난 버전은 별도 브랜치에서 분석합니다. 운영 중인 서비스를 장애 상태로 둔 채 AI와 몇 시간 디버깅하는 것은 좋은 순서가 아닙니다.
AI 개발에서 가장 효과적인 커밋 단위
기능이 아니라 검증 가능한 결과를 기준으로 끊으면 좋습니다.
나쁜 예:
회원 시스템 전체 구현
좋은 예:
회원가입 폼과 입력 검증 추가회원 생성 API 연결가입 성공 후 프로필 저장로그아웃 처리 추가
각 단계가 끝날 때 “직접 확인할 수 있는 결과”가 있어야 합니다.
브랜치를 너무 많이 만들 필요는 없다
Git을 처음 쓰는 대표가 가장 쉽게 빠지는 함정은 개발팀처럼 복잡한 Git Flow를 흉내 내는 것입니다. 초기 1인 또는 2~3인 팀이라면 다음 정도면 충분합니다.
main: 운영 배포 가능한 코드feature/기능명: 기능 추가fix/문제명: 버그 수정
릴리즈 브랜치, develop 브랜치, 여러 단계의 승인 규칙은 팀 규모와 배포 빈도가 커질 때 추가하면 됩니다.
Git과 배포를 연결해야 진짜 안전벨트가 된다
Git이 있어도 서버에 수동으로 파일을 복사한다면 운영 버전이 어떤 커밋인지 알기 어려워집니다. GitHub의 특정 브랜치나 커밋이 자동으로 배포되도록 연결하면 다음이 명확해집니다.
- 어떤 코드가 현재 운영 중인지
- 언제 배포됐는지
- 직전 버전이 무엇인지
- 문제가 생기면 어디로 되돌릴지
즉 Git은 코드 저장소가 아니라 운영 변경 이력이 됩니다.
실전: AI와 새 기능을 만드는 가장 안전한 8단계
- 현재 main을 실행해 정상인지 확인합니다.
- 변경 전 커밋을 하나 남깁니다.
- 새 기능 브랜치를 만듭니다.
- AI에게 변경 목적과 “건드리지 말아야 할 영역”을 함께 줍니다.
- 한 번에 작은 기능만 수정합니다.
- 브라우저에서 핵심 흐름을 직접 테스트합니다.
- 변경 diff를 확인하고 커밋합니다.
- main에 합친 뒤 배포하고 다시 핵심 흐름을 확인합니다.
대표가 직접 봐야 하는 최소 테스트
코드를 읽지 못해도 테스트는 할 수 있습니다. 오히려 사용 흐름을 아는 대표가 더 잘 찾는 문제도 많습니다.
- 신규 가입
- 기존 사용자 로그인
- 로그아웃 후 재로그인
- 핵심 데이터 생성/수정/삭제
- 결제 또는 예약 같은 핵심 전환
- 관리자에서 결과 확인
- 모바일 화면
이 테스트 결과까지 커밋 메시지나 PR 설명에 적어두면 AI와의 다음 작업이 훨씬 안정적입니다.
정리
Git을 배우는 목적은 개발자가 되는 것이 아닙니다. AI와 더 공격적으로 실험하면서도, 제품의 안정성을 잃지 않는 것입니다.
커밋은 세이브 포인트, 브랜치는 실험실, PR은 합치기 전 검토, 롤백은 복구 절차라고 기억하면 충분합니다. 이 네 가지가 익숙해지는 순간 바이브코딩은 “망가질까 봐 무서운 작업”에서 “실패해도 다시 시도할 수 있는 작업”으로 바뀝니다.
참고
GitHub는 브랜치를 기능 개발·버그 수정·아이디어 실험을 저장소의 다른 변경과 분리하기 위한 방식으로 설명합니다: https://docs.github.com/en/pull-requests/reference/branches