Git은 바이브 코딩을 하는 1인 개발자에게 가장 현실적인 안전장치입니다. Git을 협업 도구나 어려운 명령어 묶음으로만 생각하면 시작하기가 부담스럽지만, 개인 개발에서는 훨씬 단순하게 써도 충분합니다. 오늘 내가 무엇을 바꿨는지 기록하고, 내 PC 밖에도 한 벌을 백업하고, 수정이 산으로 갔을 때 돌아갈 수 있는 타임머신으로 사용하는 것만으로도 가치가 큽니다.
Git을 전부 배울 필요는 없습니다
Git은 매우 넓은 도구입니다. 여러 개발자가 같은 프로젝트에서 동시에 작업하도록 돕는 branch, merge, rebase, pull request, conflict 해결, 태그, 릴리스 같은 기능이 있고, 회사나 오픈소스 프로젝트에서는 이런 기능들이 중요합니다. 하지만 혼자 앱을 만들고 AI 에이전트와 함께 바이브 코딩을 하는 단계라면 처음부터 모든 기능을 익힐 필요는 없습니다.
우리에게 먼저 필요한 것은 “지금 작업분이 의미 있는 단위로 저장되었는가”, “내 PC가 고장 나도 원격 저장소에 남아 있는가”, “AI가 수정한 방향이 틀렸을 때 이전 상태로 돌아갈 수 있는가”입니다. 이 세 가지를 해결하면 수동으로 폴더를 복사해 두던 백업보다 훨씬 안정적으로 프로젝트를 관리할 수 있습니다.
이미 개발자 백업 체크리스트에서 정리했듯이, 백업은 “언젠가 해야 하는 일”이 아니라 사고가 난 뒤에야 가치가 드러나는 작업입니다. Git은 그 백업 습관을 개발 흐름 안으로 끌어오는 가장 좋은 도구 중 하나입니다.
가장 중요한 개념 1: commit은 코딩 일지입니다
commit은 현재 프로젝트 상태를 하나의 기록으로 남기는 일입니다. 단순 저장과 다른 점은 “왜 이 상태를 남겼는지”를 메시지로 함께 적는다는 데 있습니다. 예를 들어 “로그인 화면 추가”, “Supabase 연결 설정”, “빌드 오류 수정”처럼 짧게 적어 두면 나중에 프로젝트 흐름을 되짚을 수 있습니다.
바이브 코딩에서는 이 메시지가 특히 중요합니다. AI가 많은 파일을 빠르게 바꾸기 때문에, 사람이 직접 모든 변경 내용을 머릿속에 들고 있기가 어렵습니다. 그래서 “현재 작업분을 적절한 코멘트와 함께 커밋해 줘”라고 요청하면, AI가 변경 파일을 확인하고 의미 있는 메시지를 붙여 기록을 남길 수 있습니다.
처음에는 Git 명령어를 깊게 외울 필요가 없습니다. 그래도 개념을 이해하기 위해 세 단어만 알고 있으면 좋습니다.
git init: 지금 폴더를 Git 저장소로 시작합니다.git commit: 현재 작업 상태를 메시지와 함께 기록합니다.git push: 로컬 기록을 원격 저장소로 올립니다.
Git 공식 문서에서도 git init은 빈 Git 저장소를 만드는 명령으로, git push는 로컬에 있는 변경 기록을 원격 저장소로 보내는 명령으로 설명합니다. 다만 실제 사용에서는 명령어를 직접 치기보다 AI에게 “현재 작업분 커밋하고 푸시해 줘”라고 맡겨도 됩니다. 중요한 것은 명령어 암기가 아니라 지금 어떤 기록을 만들고 있는지 이해하는 것입니다.
가장 중요한 개념 2: push는 내 PC 밖의 백업입니다
commit은 내 컴퓨터 안에 남는 기록입니다. 그래서 commit만 하고 push를 하지 않으면 PC 고장, 디스크 손상, 실수로 프로젝트 폴더 삭제 같은 상황에서 여전히 위험합니다. push를 해야 원격 저장소에 기록이 올라가고, 다른 PC나 서버에서도 다시 받을 수 있는 백업이 됩니다.
Git을 관리해 주는 대표적인 서비스로는 GitHub가 있습니다. 웹에서 저장소를 만들고, repo 주소를 프로젝트에 연결하고, commit한 내용을 push하면 외부 서버에 코드 기록이 남습니다. 예전에는 외부에 공개하지 않는 나만의 저장소를 만드는 데 제한이 있었지만, 지금은 비공개 저장소도 여러 개 만들 수 있어 훨씬 편리해졌습니다.
다만 GitHub가 편하다는 것과 내 코드가 외부 서비스에 올라간다는 사실은 별개의 문제입니다. 공개 저장소로 만들면 다른 사람이 코드를 볼 수 있고, private 저장소로 만들더라도 코드는 GitHub 같은 외부 서비스에 보관됩니다. 코드를 외부 서비스에 맡기기 싫거나, 내 PC와 내부망 안에서만 관리하고 싶다면 대안도 있습니다. Gitea나 GitLab Self-Managed를 로컬 PC 또는 개인 서버에 Docker로 설치해 나만의 Git 저장소 서비스를 운영하는 방식입니다.
개인 개발자에게는 Gitea가 비교적 가볍고 단순한 선택지입니다. GitLab은 기능이 더 크고 강력하지만 그만큼 무겁습니다. Docker로 설치하는 흐름은 Gitea 공식 Docker 설치 문서와 GitLab 공식 Docker 설치 문서에 정리되어 있습니다. 이 글에서는 자세한 설치 명령을 반복하지 않겠습니다. 운영체제와 환경마다 달라지는 부분은 AI에게 물어보는 편이 더 안전합니다.
가장 중요한 개념 3: Git은 되돌리기 타임머신입니다
AI와 코딩하다 보면 어느 순간 작업이 산으로 갈 때가 있습니다. 처음에는 작은 수정이었는데 파일 구조가 과하게 바뀌거나, 잘 되던 기능이 깨지거나, 원래 의도와 다른 방향으로 구현될 수 있습니다. 이때 Git 기록이 있으면 “아까 그 정상 상태”로 돌아갈 기준점이 생깁니다.
되돌리기 명령은 상황에 따라 다릅니다. 아직 commit하지 않은 파일만 버릴지, 특정 commit 이후로 되돌릴지, 원격 저장소에 올린 기록까지 어떻게 다룰지에 따라 방법이 달라집니다. 그래서 초보자라면 명령어를 바로 검색해 따라 하기보다 AI에게 현재 상태를 먼저 점검하게 하는 편이 좋습니다.
현재 변경사항이 너무 많이 꼬인 것 같아. Git 상태를 확인하고, 어떤 변경을 되돌릴 수 있는지 설명한 뒤 안전한 되돌리기 방법을 제안해 줘. 아직 실행하지 말고 먼저 설명해 줘.
이런 식으로 요청하면 AI가 바로 위험한 명령을 실행하기 전에 현재 변경 범위와 선택지를 설명할 수 있습니다. 특히 이미 push한 저장소라면 되돌리기 방식이 더 중요해지므로, “먼저 설명하고 승인 후 실행”이라는 조건을 붙이는 습관이 좋습니다.
저장소를 만드는 흐름은 AI에게 맡겨도 됩니다
처음 Git 저장소를 만들 때의 흐름은 대략 이렇습니다. 프로젝트 폴더에서 Git을 시작하고, 원격 저장소를 만들고, 그 주소를 프로젝트에 연결하고, 첫 commit을 만든 뒤 push합니다. 여기까지가 한 번만 해 두면 되는 기본 설정입니다.
GitHub를 쓴다면 웹사이트에서 New repository를 눌러 저장소를 만들고, public/private 여부를 선택한 뒤 repo 주소를 AI에게 알려주면 됩니다. GitHub 공식 요금제 문서 기준으로 GitHub Free 개인 계정도 private repository를 만들 수 있지만, private 저장소는 유료 기능에 비해 일부 기능 제한이 있을 수 있습니다. 민감한 프로젝트라면 저장소 공개 여부를 반드시 확인해야 합니다.
self-hosting을 선택한다면 먼저 Docker 실행 환경이 필요합니다. Windows라면 Docker Desktop 설치를 요청하고, Linux라면 Docker Engine 설치를 요청하면 됩니다. Mac에서는 Docker Desktop도 가능하지만 제가 써 본 환경에서는 OrbStack이 더 가볍게 느껴졌습니다. 그다음 “Gitea를 Docker로 설치해 줘” 또는 “GitLab을 Docker로 설치해 줘”라고 요청하고 안내에 따라 계정과 저장소를 만들면 됩니다.
설치 후에는 구입한 도메인을 연결하거나, 내부 IP 주소, localhost, 127.0.0.1과 설치 시 지정한 포트로 접속할 수 있습니다. 그 안에서 private repository를 만들고, repo 주소를 AI에게 알려주면 됩니다. 이후 계정 ID, 비밀번호나 토큰, commit에 표시할 이름, 이메일 주소 같은 정보를 확인하는 질의응답이 한 번 오갑니다. 한 PC에서는 보통 이 설정을 한 번만 해 두면 계속 사용할 수 있습니다.
AI에게 이렇게 요청하면 됩니다
바이브 코딩에서는 세세한 Git 명령어보다 요청 문장이 더 중요합니다. 아래 정도만 관리 문서나 개인 메모에 넣어 두어도 충분합니다.
- 현재 프로젝트가 Git 저장소인지 확인하고, 아니면 초기화해 줘.
- 원격 저장소 주소를 연결하고 첫 commit을 만든 뒤 push해 줘.
- 현재 작업분을 의미 있는 커밋 메시지와 함께 commit하고 push해 줘.
- 이번 턴에서 수정한 내용을 요약하고, 문제가 없으면 commit 후 push해 줘.
- 현재 변경사항이 위험해 보이면 commit하지 말고 먼저 설명해 줘.
자동 관리를 더 강하게 하고 싶다면 프로젝트의 관리 문서에 다음과 같은 지침을 넣을 수도 있습니다.
턴 종료 시 현재 변경사항을 요약하고, 테스트 가능한 항목을 확인한 뒤 Git commit과 push를 실행한다. 단, 비밀정보나 불필요한 대용량 파일이 포함된 경우 먼저 보고하고 중단한다.
이 지침은 편하지만 무조건 자동화하면 안 됩니다. API 키, 인증서, 빌드 산출물, 대용량 임시 파일이 실수로 들어갈 수 있기 때문입니다. 그래서 AI에게 commit 전 변경 파일 목록과 민감정보 가능성을 확인하게 하는 조건을 붙이는 편이 좋습니다. goal 명령어로 반복 작업을 맡길 때도 Git commit과 push를 검증 단계에 넣으면 작업 흐름이 훨씬 안정됩니다.
처음에는 단순하게 쓰고, 필요할 때 넓히면 됩니다
Git을 제대로 설명하려면 글 하나로는 부족합니다. branch를 나누는 법, pull request로 검토하는 법, conflict를 해결하는 법, release tag를 남기는 법, GitHub Actions나 GitLab CI로 배포를 자동화하는 법까지 들어가면 끝이 없습니다. 하지만 1인 개발자가 처음부터 그 모든 기능을 알아야 하는 것은 아닙니다.
처음 목표는 단순합니다. Git 코딩 일지를 남기고, 원격 저장소에 백업하고, 잘못된 수정에서 되돌아올 기준점을 만드는 것입니다. 이 정도만 해도 수동 폴더 복사보다 훨씬 낫습니다. 이후 프로젝트가 커지고 협업이나 배포 자동화가 필요해지면, 그때 Git의 더 많은 기능을 하나씩 찾아보면 됩니다.
Android 바이브 코딩 프로젝트 준비 글에서도 원격 저장소와 로드맵 준비를 함께 다뤘습니다. 프로젝트를 새로 시작한다면 Git 저장소를 만들고, 로드맵 문서를 넣고, 첫 commit을 만든 뒤 개발을 시작하는 흐름을 기본값으로 삼아 보세요. AI와 함께 코딩하더라도 기록과 백업의 책임은 결국 내 프로젝트를 지키기 위한 가장 기본적인 습관입니다.
답글 남기기