바이브코딩 초보를 위한 Git 사용법: 명령어는 몰라도 이것만 알면 됩니다.

바이브코딩을 시작하고 AI에게 코드를 맡기다 보면 생각보다 빨리 Git이라는 단어를 만나게 됩니다.

GitHub에 올려라, 커밋해라, 브랜치를 만들어라, push를 해라, 충돌이 났다….

처음 보는 사람 입장에서는 코드도 AI가 작성해주는데 갑자기 또 새로운 공부거리가 생긴 느낌입니다.

저도 그래서 Git을 처음 접하는 분들에게는 명령어부터 외우라고 하고 싶지 않습니다.

Git이 왜 필요한지만 이해하고, 실제 작업은 AI 에이전트에게 맡겨도 됩니다.

진짜 초보자를 위한 글입니다.

Git을 이미 잘 사용하고 계신 고수님들은 편하게 패스해주세요. ㅎㅎ

Git이란 무엇일까?

Git을 검색하면 보통 이런 설명이 나옵니다.

분산 버전 관리 시스템

예전에는 형상관리라는 표현도 많이 사용했습니다.

쉽게 설명한다면서 벌써 어려워집니다. ㅋㅋ

그냥 이렇게 생각하면 됩니다.

Git = 내가 만든 소스코드의 세이브 포인트

회사에서 사용하는 사내 규정.docx라는 문서가 있다고 해보겠습니다.

처음 만든 문서가 v1입니다.

규정이 바뀔 때마다 수정해서

• v1
• v2
• v3
• v4
• ...
• v10

이렇게 계속 버전이 올라갔다고 해보죠.

그런데 최신 버전 하나만 김대리 노트북에 저장되어 있다면 문제가 생길 수 있습니다.

실수로 파일을 삭제할 수도 있고, 누군가 내용을 잘못 수정한 상태로 저장할 수도 있습니다.

그러다 갑자기 이런 이야기가 나옵니다.

지난주 내용이 맞았는데 그때 버전으로 돌려주세요.

이미 파일을 덮어썼다면 난감하겠죠.

그래서 중요한 시점마다 당시 문서의 상태를 기록해두는 겁니다.

소스코드에서 이 역할을 해주는 것이 Git이라고 생각하면 됩니다.

Git과 GitHub는 뭐가 다를까?

Git과 GitHub를 같은 것으로 생각하는 경우도 많은데 역할이 조금 다릅니다.

아주 쉽게 구분하면 됩니다.

Git = 버전을 기록하는 도구

GitHub = 그 기록을 보관하는 온라인 창고

GitLab 역시 비슷한 역할을 합니다.

내 PC가 고장 나더라도 GitHub에 소스가 정상적으로 올라가 있다면 다른 컴퓨터에서 다시 받아 작업을 시작할 수 있습니다.

여러 사람이 같은 프로젝트를 개발할 때도 이 창고를 중심으로 서로의 변경사항을 공유할 수 있습니다.

그럼 프로젝트 폴더를 전부 GitHub에 넣으면 될까?

아닙니다.

여기서 초보자가 꼭 알아야 할 게 하나 있습니다.

다시 사내 규정 문서로 돌아가보겠습니다.

문서를 만들면서 관련 법령이 들어있는 두꺼운 PDF도 참고하고, 인터넷에서 받은 자료도 보고, 개인적으로 정리해둔 노트도 꺼내볼 수 있습니다.

그렇다고 이 자료들을 전부 회사 창고에 넣을 필요는 없겠죠.

개발도 똑같습니다.

다시 다운로드할 수 있는 파일, 명령어로 다시 생성할 수 있는 파일, 자동으로 만들어지는 파일, 용량만 엄청나게 큰 파일 등은 굳이 Git에 넣지 않습니다.

이것만은 꼭 기억하세요

비밀번호, API Key, 인증정보, .env 같은 민감한 정보는 GitHub에 올리면 안 됩니다.

특히 공개 저장소라면 당연히 위험합니다.

비공개 저장소라고 해도 비밀번호나 API Key를 무작정 커밋하는 습관은 좋지 않습니다.

초보자라면 일단 이렇게 생각하면 됩니다.

새 컴퓨터에서 이 저장소를 받아 다시 서비스를 만들 때 필요한 것은 보관한다.

다시 만들 수 있는 것과 비밀정보는 제외한다.

세부적인 내용은 나중에 하나씩 익혀도 됩니다.

그런데 Git은 왜 이렇게 어려워 보일까?

막상 Git을 사용하려고 검색하면 갑자기 이상한 단어들이 쏟아집니다.

commit, push, pull, branch, merge, rebase, checkout...

코드 저장한다면서 왜 공부할 게 이렇게 많아? ㅋㅋ

Git이 복잡해지는 가장 큰 이유 중 하나는 여러 사람이 하나의 프로젝트를 동시에 수정하기 때문입니다.

다시 회사로 돌아가보겠습니다.

김대리에게 사내 규정의 복리후생 부분을 수정하라고 했습니다.

그런데 이대리도 동시에 같은 부분을 자기 스타일대로 수정했습니다.

Git 입장에서는 난감합니다.

그래서 누구 걸 최종본으로 할 건데?

이게 흔히 말하는 충돌(Conflict)입니다.

결국 부장님이 김대리 문서와 이대리 문서를 모두 보고 필요한 내용을 합쳐서 최종본에 반영해야겠죠.

Git도 비슷합니다.

원리를 알고 보면 그렇게 무서운 놈은 아닙니다.

자, 이제 진짜 바이브코더용 팁입니다

여기부터가 제가 이 글에서 정말 이야기하고 싶은 부분입니다.

바이브코딩을 막 시작한 사람이 Git 명령어를 전부 외우고 브랜치 전략까지 공부한 다음 개발을 시작할 필요는 없다고 생각합니다.

요즘 AI 코딩 에이전트는 Git 작업도 상당 부분 대신 처리할 수 있습니다.

대신 왜 Git을 사용하는지는 사람이 알고 있어야 합니다.

초보라면 우선 딱 두 가지만 기억하세요.

1. 소스가 날아가도 다시 서비스를 살릴 수 있어야 한다

내 PC가 고장 나거나 프로젝트 폴더를 실수로 삭제해도 GitHub에서 소스를 다시 받아 개발을 계속할 수 있어야 합니다.

2. AI가 사고를 쳐도 정상 버전으로 돌아갈 수 있어야 한다

저는 바이브코딩에서는 이게 정말 중요하다고 생각합니다.

AI에게 이렇게 요청했다고 해보겠습니다.

로그인 부분 좀 개선해줘.

그런데 AI가 생각보다 많은 파일을 수정해버릴 수 있습니다.

처음에는 잘 되는 것 같았는데 다른 기능이 망가질 수도 있습니다.

그때 Git 기록이 제대로 남아 있다면 이렇게 말하면 됩니다.

이 작업하기 전까지는 정상이었으니까 그 상태로 돌려줘.

그래서 저는 Git을 이렇게 이해하는 게 가장 쉽다고 생각합니다.

Git = 바이브코딩의 세이브 포인트

GitHub CLI, gh를 설치해봅시다

이제 실제로 사용할 준비를 해보겠습니다.

GitHub를 사용한다면 저는 GitHub 공식 CLI인 gh도 같이 설치하는 걸 추천합니다.

여기서 하나만 구분하면 됩니다.

git은 버전을 관리하는 프로그램입니다.

gh는 GitHub를 터미널에서 사용할 수 있게 해주는 공식 도구입니다.

AI 에이전트 입장에서도 gh가 설치되어 있고 인증까지 되어 있으면 GitHub 저장소나 Pull Request 등 GitHub 관련 작업을 처리하기 훨씬 편해집니다.

Windows

PowerShell 또는 Windows Terminal을 열고 실행합니다.

winget install --id GitHub.cli

설치가 되었는지 확인합니다.

gh --version

macOS

Homebrew가 설치되어 있다면 터미널에서 실행합니다.

brew install gh

설치 확인:

gh --version

Linux - Ubuntu / Debian

sudo apt update
sudo apt install -y gh

설치 확인:

gh --version

Linux - Fedora / RHEL 계열

sudo dnf install -y gh

설치 확인:

gh --version

GitHub 계정까지 연결해봅시다

gh를 설치했으면 이제 GitHub 계정을 연결합니다.

운영체제와 상관없이 터미널에서 실행하면 됩니다.

gh auth login

화면에 선택지가 나오면 GitHub.com을 선택하고 안내에 따라 인증하면 됩니다.

브라우저 로그인을 선택하면 조금 더 편합니다.

인증이 끝났다면 다음 명령어로 확인합니다.

gh auth status

내 GitHub 계정 정보가 정상적으로 나오면 준비 끝입니다.

이제 Git 작업은 AI에게 시키세요

여기까지 했다면 이제 바이브스럽게 가면 됩니다. ㅋㅋ

Cursor, Claude Code, Codex 같은 AI 코딩 에이전트를 사용한다면 프로젝트의 에이전트 지침에 아래 내용을 넣어두세요.

앞으로 이 프로젝트는 GitHub를 통해 소스를 관리한다.

소스를 수정하기 전에 현재 Git 상태와 브랜치를 확인한다.

새로운 작업을 시작할 때는 작업 내용을 알아볼 수 있는 이름으로 브랜치를 만들고 작업한다.

의미 있는 작업 단위가 끝나면 변경사항을 정리해서 알려주고 GitHub에 반영할지 나에게 확인한다.

내가 반영하라고 하면 필요한 commit, push, merge 등의 작업을 진행하고 다음 개발을 시작할 수 있는 깨끗한 상태로 정리한다.

비밀번호, API Key, 인증정보, .env 등 민감한 정보는 절대 Git에 올리지 않는다.

Git 작업 중 충돌이나 기존 작업을 덮어쓸 가능성이 있다면 임의로 처리하지 말고 먼저 나에게 알려준다.

이 내용을 프로젝트의 에이전트 지침에 넣고 이렇게 요청하면 됩니다.

앞으로 이 프로젝트에서는 이 지침을 항상 지켜줘.

요즘 에이전트들은 웬만한 Git 작업은 알아서 처리해줍니다.

물론 AI가 한다고 해서 아무것도 확인하지 않아도 된다는 뜻은 아닙니다.

Git을 사용하는 목적과 현재 상태는 사람이 이해하고, 반복적인 실행은 AI에게 맡기는 방식에 가깝습니다.

개념은 내가, 실행은 AI가

Git을 제대로 배우면 당연히 좋습니다.

branch가 무엇인지, merge가 어떻게 동작하는지, commit을 어떻게 관리해야 하는지 알면 더 안전하게 사용할 수 있습니다.

하지만 Git 때문에 바이브코딩 시작부터 포기할 필요는 없습니다.

처음에는 원리만 이해하면 됩니다.

개념은 내가 이해하고, 실행은 AI에게 맡기기.

그러다가 어느 날 사고가 납니다. ㅋㅋ

AI가 코드를 이상하게 고쳤습니다.

어제까지 잘 되던 서비스가 갑자기 안 됩니다.

그때 쌓아둔 Git 기록을 보면서 말하면 됩니다.

여기까지는 잘 됐었는데?

이 버전으로 돌려줘.

Git = 내가 만든 프로젝트의 세이브 포인트

게임하면서 세이브 포인트 하나도 없이 보스전에 들어가진 않잖아요.

바이브코딩도 똑같습니다.

오히려 AI는 사람이 직접 코딩할 때보다 훨씬 빠른 속도로 많은 파일을 수정합니다.

개발 속도가 빨라진 만큼 망가지는 속도도 빨라졌습니다.

그래서 저는 바이브코딩에서는 Git이 더 중요할 수도 있다고 생각합니다.

잘 돌아가는 순간마다 세이브 포인트를 만들어두고 다음 작업으로 넘어가세요.

AI가 사고를 치면?

마지막 정상 세이브 포인트로 돌아가서 다시 시작하면 됩니다.

마지막으로 이것 하나만 기억하세요

Git = 내가 만든 프로젝트의 세이브 포인트

명령어를 전부 외울 필요는 없습니다.

개념은 내가 이해하고, 실행은 에이전트에게 맡긴다.

그리고 개발하다가 Git이 필요한 상황을 하나씩 경험하면서 그때 필요한 개념을 추가로 배우면 됩니다.

아마 어느 날 AI가 잘 돌아가던 코드를 제대로 한번 망가뜨리고 나면 ㅋㅋ

그동안 쌓아둔 Git 기록을 보면서

어제 정상 버전으로 돌려줘.

라고 말하게 될 겁니다.

그리고 정상적으로 돌아온 화면을 보는 순간,

왜 개발자들이 그렇게 Git, Git 하는지 바로 이해하게 될 겁니다.