클로드 코드 깃허브 사용법, 커밋·브랜치·.gitignore 3가지

클로드 코드 같은 AI 에이전트로 코딩한다면 깃(Git)과 깃허브(GitHub) 명령어를 외울 필요가 없다. 이 글은 커밋, 브랜치, .gitignore 세 가지만으로 망가진 작업을 되돌리고, 원본을 지키고, 비밀 키 유출을 막는 클로드 코드 깃허브 사용법을 설치부터 정리한다. 에이전트 채팅창에 그대로 넣을 문장도 함께 담았다.

커밋해줘? 물으면 그냥 "해줘"라고만 답했다면

바이브 코딩(AI 에이전트에게 텍스트로 지시해 코딩하는 방식)을 하다 보면 다들 비슷한 순서를 겪는다. AI 에이전트는 시키면 파일을 직접 고치고 명령까지 실행하는 AI 도구이고, 클로드 코드가 대표적이다. Git과 GitHub를 같은 것으로 오해한다. 에이전트가 "커밋할까요? 푸시할까요?"라고 물어도 그냥 "해줘"라고만 답한다. 아예 그런 질문을 받아본 적이 없는 경우는 더 심각하다. 이력 관리가 시작조차 안 된 상태다. 그러다 신규 기능을 추가한 뒤 품질이 나빠져도 수정 전으로 되돌릴 수 없는 상황을 맞는다. 영상을 만든 사람도 같은 순서를 그대로 겪었다고 한다.

Git 공식 문서에는 명령어가 100개 넘게 있다. 손으로 코딩하던 개발자들은 이걸 외워서 썼다. 하지만 바이브 코딩에서는 커밋·브랜치·.gitignore 세 단어만 알아도 텍스트 지시로 대부분 관리된다. 커밋은 망가진 것을 되돌리게 해주고, 브랜치는 원본이 망가지는 것을 막고, .gitignore는 올라가면 안 되는 것이 올라가는 것을 막는다. 6개월 넘게 쌓은 에이전트가 망가지기 전에 이 셋으로 대부분의 사고를 막을 수 있다.

Git과 GitHub는 뭐가 다른가

Git은 내 컴퓨터 안에서 도는 기록 프로그램이다. 파일이 어떻게 바뀌어 왔는지 스크린샷 찍듯 남기는 버전 관리 시스템이다. GitHub는 그 기록을 올려두는 인터넷 공간, 구글 드라이브와 비슷한 개념이다. 이름이 비슷해서 그렇지 하는 일은 완전히 다르다.

"최종본_진짜최종본_V3_V4" 식으로 파일을 복사·개명해온 습관 자체가 버전 관리를 손으로 해온 셈이다. 복사본이 쌓일수록 어디가 바뀌었는지 알기 어려운데, Git은 내가 언제 뭘 바꿨는지까지 기록해 두기 때문에 나중에 아무 시점이나 골라 롤백(예전 상태로 되돌리기)할 수 있다.

서류 봉투로 바꿔 생각하면 쉽다. 서류를 봉투에 담는 과정이 스테이징, 봉투를 봉인하고 메모를 붙이는 게 커밋, 봉투를 회사 공용 캐비닛에 넣는 게 푸시다. 캐비닛이 곧 GitHub다. Git 안에는 워킹 디렉토리(작업 중) → 스테이징(저장할 것만 골라 담음) → 레포지토리(확정 기록이 쌓이는 곳) 3영역이 있고, 커밋은 스테이징에서 레포지토리로 넘기는 동작이다. 디렉토리는 폴더, 레포지토리는 저장소와 같은 말이다. 봉투 작업까지는 내 컴퓨터 안에서 Git이 하는 일이고, 캐비닛에 들어간 순간부터 GitHub다. 그때부터 다른 사람과 함께 작업하거나 프로그램을 공유할 수 있다. 누군가 GitHub에 올려둔 오픈소스(코드가 공개된 프로그램)를 내려받아 본 적이 있다면 이미 이 캐비닛에서 파일을 꺼내온 셈이다.

VS Code나 Antigravity, Cursor의 소스 컨트롤 패널(동그라미 세 개 버튼)을 열면 커밋 이력이 시간순으로 쌓여 있다. 세 프로그램은 모두 코드를 쓰고 고치는 편집기이고, 채팅창에서 AI 에이전트에게 일을 시킬 수 있다. 이 패널이 비어 있다면 이력 관리를 아직 시작하지 않은 것이다. 각 줄이 하나의 "세이브 포인트"라서 아무 시점이나 눌러 과거로 돌아갈 수 있다. 화자의 화면에는 2주 전 날씨 하위 프로젝트를 독립 저장소로 등록한 것, 어드민 콘솔을 만든 것, 전국 주요 10개 도시 날씨 앱을 추가한 것이 순서대로 남아 있고, 각 커밋마다 그때 수정한 파일 목록이 함께 붙어 있다.

AI 에이전트가 코드를 고치다 어제까지 되던 게 안 되는 상황이 반복되는 이유도 여기 있다. "저거 해줘", "이렇게 하지 마" 같은 단발성 지시들이 CLAUDE.md 같은 지침 파일에 계속 쌓이면서 기존 중요 규칙의 우선순위가 밀린다. CLAUDE.md는 클로드 코드가 작업할 때마다 먼저 읽는 규칙 메모 파일이다. 커밋이 있으면 언제든 변경 전으로 돌아갈 수 있으니, AI에게 무언가 시키기 전에 "작업 시작 전에 지금 상태를 커밋해줘"라고 먼저 요청하는 습관을 들인다.

깃 설치부터 깃허브 연결까지, 클로드 코드로 따라 하기

Git 설치

1. 구글에 "깃 배쉬"를 검색하면 Git 공식 사이트(git-scm.com)의 다운로드 페이지로 들어간다. 깃 배쉬(Git Bash)는 윈도우용 Git에 함께 들어 있는 명령 입력 창이다.
2. 윈도우는 수동으로 받아야 한다. 내려받은 파일을 실행하고, 설치 창이 여러 개 뜨면 옵션은 전부 기본값 그대로 두고 진행한다.
3. 맥은 컴퓨터 구매 시 이미 설치돼 있는 경우가 많다. 터미널(응용 프로그램 > 유틸리티 > 터미널)을 열고 git --version을 쳐서 버전이 나오면 깔려 있는 것이고, 없으면 설치 안내 창이 뜬다.

이력 관리 시작

1. VS Code(또는 Antigravity, Cursor)에서 평소 작업하던 메인 디렉토리를 연다. 파일 메뉴의 폴더 열기로 고르면 된다. 새 폴더를 따로 만들 필요는 없다. 영상에서는 시연을 위해 "깃 배쉬"라는 빈 폴더를 만들고 경로를 지정했지만, 이미 다른 디렉토리가 Git 관리 중이라 그런 것이다.
2. 에이전트 채팅창에 이렇게 입력한다.

이력 관리 시작해줘

1. 한글 응답을 원하면 이어서 아래 문장도 넣는다.

이력 관리는 한글로 진행할게

에이전트는 "이력 관리를 시작했습니다"라고 답하면서 독립된 Git 저장소를 만들고, 폴더의 목적과 구조를 적은 README 파일과 .gitignore 파일까지 자동으로 만들어 준다. README는 폴더 첫머리에 두는 안내문 파일이다. 맥에서는 Command + Shift + 마침표(.)를 누르면 숨김 파일이 보이면서 회색으로 흐린 .git 폴더가 나타난다. 이 폴더가 있는 디렉토리 안의 변경은 전부 롤백할 수 있다. 아직 추가로 고친 게 없으면 소스 컨트롤 패널에 변경점이 없고, 커밋을 할 때마다 키워드별로 기록이 쌓인다.

GitHub 저장소 만들고 올리기

1. GitHub 사이트에서 회원가입한다(구글 계정 권장).
2. 처음 들어가면 빈 화면이 뜨는데, "Create repository" 버튼을 누른다.
3. 저장소 이름을 입력하고, Public 대신 Private을 선택한다. Public으로 두면 전체 공개된다. 구글 드라이브에 새 폴더를 만드는 것과 같은 일이다.
4. 생성된 저장소 주소를 복사해 AI 편집기 채팅창에 붙여넣고 이렇게 지시한다.

깃허브에 푸시해줘

1. 처음 푸시할 때 GitHub 로그인 창이나 토큰 입력을 요구하면 브라우저에서 승인하면 된다. 여기서 토큰은 비밀번호 대신 쓰는 긴 인증 문자열이다. GitHub CLI(gh, 명령어로 GitHub를 다루는 공식 도구)가 설치돼 있다면 "gh auth login 실행해줘"라고 시켜 브라우저 로그인 절차를 띄우는 방법이 가장 간단하다.
2. GitHub 저장소 페이지로 돌아가 새로고침하면 방금 만든 파일들이 올라와 있다.

브랜치 - 실패해도 원본은 안전하게

브랜치는 사전적으로 나뭇가지다. 줄기에서 가지가 뻗어나가는 그림 그대로, 원본 코드에 영향을 주지 않고 따로 작업하는 독립된 공간이다. 잘 돌아가는 프로젝트에 성공 여부가 불확실한 큰 기능을 추가할 때 새 브랜치를 파서 그 안에서 작업하면, 실패해도 원래 작업 디렉토리는 그대로 남는다.

커밋은 "망가진 다음 되돌리는" 과정이고, 브랜치는 "아예 망가지지 않게 따로 떼어놓는" 것이다. 커밋만 있어도 되긴 하지만, 되돌리는 동안 프로젝트가 멈추고 토큰과 시간이 계속 소모된다. 이때 토큰은 AI가 글을 읽고 쓰는 양을 세는 사용량 단위다. 클로드 코드처럼 파일 10~20개를 한 번에 고치는 도구를 쓸 때는 이 차이가 특히 크다. 일부만 잘못돼도 되돌리기가 애매해지기 때문이다. 브랜치라면 실패한 가지를 통째로 버려도 아무 문제가 없다.

새 브랜치 만들어서 거기서 작업해줘

결과가 마음에 들면 아래처럼 지시해 메인과 합친다. 메인은 원본 코드가 있는 기본 브랜치의 이름이다. 합치는 것을 머지, 합쳐 달라고 요청하는 것을 풀 리퀘스트라고 부르지만 용어를 외울 필요는 없다.

원본 메인 파일에 합쳐줘

마음에 안 들면 그냥 브랜치를 버리면 된다. 에이전트는 "메인은 건드리지 않았다"고 답하고, 원본에는 영향이 없다.

.gitignore - 한 번 새면 되돌릴 수 없다

커밋과 브랜치는 둘 다 되돌리거나 버릴 수 있다. .gitignore는 성격이 다르다. 처음부터 민감 정보가 나가지 않도록 자물쇠를 채우는 과정이다. .gitignore는 Git이 기록하지 말고 무시할 파일 목록을 적어두는 파일이다.

API 키나 보안 시크릿 키가 파일에 적힌 채로 커밋되고 GitHub에 공개되면, 다른 사람이 코드를 내려받을 때 그 키까지 함께 유출된다. API 키와 시크릿 키는 외부 서비스가 "이 사람 계정으로 쓰는 요청"이라고 알아보게 해주는 비밀 문자열이다. 카드나 결제 정보를 등록해 둔 데이터베이스나 사이트의 키가 새면 남이 쓴 비용을 내가 계속 물 수도 있다. 커밋은 되돌리면 되고 브랜치는 버리면 되지만, 한 번 유출된 키는 되돌릴 수 없다.

.gitignore에 들어가는 것은 키나 비밀번호가 적힌 파일, 그리고 용량만 크고 올릴 이유가 없는 더미 문서나 로그 파일이다. 여기 적힌 확장자와 파일은 커밋에도 포함되지 않고 GitHub에 푸시되지도 않는다. 프로젝트를 시작할 때 가장 먼저 이렇게 지시한다.

새 프로젝트니까 이그노어부터 만들어줘. 키나 비밀번호 들어가는 파일은 미리 넣어줘.

에이전트는 ".gitignore를 새로 작성했습니다"라며 환경 변수 파일, 설정값 파일, 개인키·인증서, 구글 OAuth 서버 인증 파일 등을 목록에 넣어 대폭 강화해 준다. 환경 변수 파일은 보통 .env라는 이름으로, 키 같은 비밀값을 코드와 따로 모아두는 파일이다. OAuth는 "구글로 로그인"처럼 다른 서비스 계정으로 인증하는 방식이다. 이미 올라간 뒤에 .gitignore를 적으면 늦다. 남들이 키를 이미 내려받은 상태라면 무시 목록에 넣어도 의미가 없다. 다만 AI가 키를 100% 걸러준다는 보장은 없다. 프로젝트 안 모든 파일을 전수 조사할 뿐이라서, 정말 중요한 키가 있다면 .gitignore 파일을 직접 열어 크로스체크하는 편이 안전하다. 이후 "커밋할까요?"라는 메시지가 뜨면 "커밋해줘"라고 답하면 된다.

클로드 코드에 그대로 복사해 쓰는 깃 지시 5문장

커밋·브랜치·레포지토리·푸시·.gitignore 다섯 단어로 만든 문장이다.

1. "깃 관리 시작할게. 한글로 이력 관리해줘"
2. "작업 시작 전에 지금 상태 커밋해줘"
3. "신규 기능을 추가하기 전에, 무게감 있는 프로젝트를 진행할 때 새 브랜치 만들어서 거기서 작업해줘"
4. "새 프로젝트니까 (키) 이그노어부터 만들어줘"
5. "작업 끝났으면 커밋해줘 또는 푸시해줘"

새롭고 어려운 단어는 없다. 이 정도만 알아도 클로드 코드가 "커밋할까요?"라고 물었을 때 그 의미를 알고 답할 수 있다.

# "이력 관리 시작해줘"
git init
git add .
git commit -m "초기 커밋"

# "깃허브에 푸시해줘" (저장소 주소를 붙여넣은 뒤)
git remote add origin https://github.com/계정명/저장소명.git
git push -u origin main

# "새 브랜치 만들어서 거기서 작업해줘"
git checkout -b feature/새기능

# "원본 메인 파일에 합쳐줘"
git checkout main
git merge feature/새기능

# "지난 커밋으로 되돌려줘"
git log --oneline
git revert <커밋ID>

.env
.env.*
*.key
*.pem
credentials.json
service-account*.json
node_modules/
__pycache__/
*.log
.DS_Store

출처: youtu.be/…