[Git 기초] AI가 만든 코드, 어디까지 믿고 저장할까?

코드가 멀쩡할 때는 Git이 제일 귀찮습니다.

AI에게 화면 하나를 맡겼는데 잘 돌아가면, git add와 commit은 공연 끝난 뒤 출석부 쓰는 일처럼 느껴지죠. 그런데 다음 프롬프트가 로그인 화면까지 건드리고, 어디서부터 이상해졌는지 못 찾는 순간이 옵니다. 그때 필요한 건 더 좋은 프롬프트가 아니라, 마지막으로 괜찮았던 상태입니다.

Git은 그 상태를 이름 붙여 남기는 도구예요. 이 글은 Git을 처음 쓰는 사람이 작업 중인 파일, 내 컴퓨터의 기록, 원격 저장소가 어떻게 이어지는지만 잡는 데 집중합니다. 2026년 9월 공식 Git·GitHub 문서를 기준으로 확인했습니다.

Git은 저장 버튼보다 경계선에 가깝다

Git은 모든 변경을 자동으로 믿어 주지 않습니다. 내가 이번 기록에 넣겠다고 고른 변경만 커밋에 담기죠. 바이브코딩할수록 이 한 단계가 더 중요해집니다.

파일을 고치면 먼저 작업 폴더에 바뀐 내용이 남습니다. git status는 그중 무엇이 수정됐고, 무엇이 아직 기록 대상이 아닌지 보여 줍니다. 그다음 git add 파일명으로 이번 스냅샷에 넣을 파일을 고르고, git commit -m "..."으로 그 선택을 기록합니다. Git 공식 책도 이 과정을 수정 → stage → commit의 반복으로 설명합니다.

그럼 git add . 한 번이면 편하지 않나요? 편합니다. 하지만 저는 처음 배우는 단계에서는 이 방법을 권하지 않아요. AI가 여러 파일을 한꺼번에 바꿨을 때 설정 파일이나 실험용 파일까지 같이 담길 수 있기 때문입니다. git status를 보고 파일명을 찍는 몇 초가 나중에 비교할 기준을 만들어 줍니다.

여러분이 남기는 커밋 메시지도 거창할 필요는 없습니다. feat: 로그인 버튼 추가처럼 “이 시점에 무엇이 정상이어야 하는지”만 알아보게 쓰면 됩니다. 커밋은 파일 저장보다, 나중의 내가 되돌아올 좌표를 찍는 일에 가깝네요.

GitHub는 Git의 다른 이름이 아니다

Git은 내 컴퓨터에서도 기록을 남길 수 있습니다. GitHub는 그 기록을 온라인에 두고 공유하기 편한 서비스예요. 둘을 같은 말로 외우면 commit과 push가 늘 헷갈립니다.

내 컴퓨터의 Git 기록을 원격 저장소에 보내고 다른 컴퓨터에서 받아오는 흐름

내 컴퓨터에서 commit하면 기록은 우선 내 저장소에 생깁니다. push는 그 기록을 GitHub 같은 원격 저장소로 보내는 동작입니다. 반대로 다른 컴퓨터에서 작업을 이어 가려면 원격 저장소의 기록을 받아와야 하고, 보통 pull이 그 역할을 합니다. Git 문서는 원격 저장소가 인터넷이나 네트워크에 있는 프로젝트의 버전이라고 설명합니다.

원격이 정말 클라우드인가요? GitHub를 쓴다면 보통 그렇게 이해해도 됩니다. 다만 Git에서 remote라는 말은 꼭 인터넷 너머를 뜻하지는 않아요. 다른 위치에 있는 저장소를 가리키는 이름입니다. 처음엔 “온라인 복사본”이라고 생각하면 충분합니다.

여러분이 노트북을 바꾸거나 데스크톱에서 이어 작업할 때, 원격 저장소가 그 사이의 전달 지점이 됩니다. 다만 push를 백업 버튼으로만 보면 아쉬워요. GitHub의 저장소는 파일과 변경 이력을 함께 두고 협업할 수 있는 공간이기도 합니다.

처음에는 네 줄만 반복하면 된다

명령어를 한꺼번에 외울 필요 없습니다. 아래 흐름이 손에 붙으면 브랜치와 충돌 해결은 그다음에 배워도 됩니다.

# 지금 무엇이 바뀌었는지 확인
git status

# 이번 기록에 넣을 파일을 선택
git add src/app/page.tsx

# 선택한 변경에 이름 붙여 기록
git commit -m "feat: add landing page hero"

# 원격 저장소로 보내기
git push

여기서 가장 자주 먼저 칠 명령은 무엇일까요? git status입니다. 새 명령을 찾기 전에 현재 상태부터 보는 습관이 실수를 줄여 줍니다. Git은 수정된 파일과 stage된 파일을 구분해서 보여 주므로, “이번 커밋에 뭐가 들어가지?”라는 질문에 바로 답할 수 있어요.

pull은 언제 쓰나요? 다른 컴퓨터에서 작업했거나 다른 사람이 원격 저장소에 새 기록을 보냈을 때입니다. git pull은 원격 변경을 가져온 뒤 현재 작업과 합치려 시도합니다. 그래서 막연히 매번 누르기보다, 먼저 현재 변경이 있는지 git status로 보는 쪽이 저는 편합니다.

AI가 빠를수록 커밋은 더 작게 남긴다

AI가 한 번에 열 파일을 바꿔 줬다고 열 파일을 무조건 한 커밋에 넣을 이유는 없습니다. 화면 수정, 설정 변경, 실험 코드는 나누는 편이 나중에 훨씬 읽기 쉽습니다.

저라면 화면이 정상 동작하는 작은 순간마다 커밋을 남깁니다. “완벽하게 끝난 기능”을 기다리다 보면 바뀐 파일만 쌓이고, 어떤 변경이 문제를 만들었는지 비교하기 어려워지거든요. 이 부분은 저도 명령어보다 작업 단위가 먼저라고 봅니다.

특히 .env처럼 비밀값이 들어갈 수 있는 파일은 습관적으로 git add .에 섞지 않는 편이 좋습니다. 공개 저장소에 한번 올라간 기록은 단순히 파일을 지운다고 완전히 사라지는 문제가 아니기 때문이죠. GitHub도 저장소를 코드·파일·수정 이력이 함께 있는 단위로 설명합니다.

AI가 코드를 만들었으니 Git은 나중에 해도 될까요? 오히려 반대예요. 생성 속도가 빨라질수록 사람이 검토하고 책임질 수 있는 경계도 더 자주 만들어야 합니다. Git은 그 경계를 작게 자를 수 있게 해주는 도구입니다.

오늘 남길 것은 거대한 프로젝트가 아니라 커밋 하나

처음부터 브랜치 전략을 설계하지 않아도 됩니다. 오늘 바꾼 파일을 git status로 보고, 의도한 것만 git add로 고른 뒤, 한 줄 메시지로 커밋해 보세요. 그 한 번이 쌓이면 Git은 낯선 명령어 모음이 아니라 작업을 다시 시작할 수 있게 해 주는 기록이 됩니다.

AI가 바꾼 코드를 그대로 믿지 말자는 뜻은 아닙니다. 빠르게 만든 뒤, 어느 상태까지는 내가 확인했다는 표시를 남기자는 뜻이에요. 개발 방식이 바뀌면서 평가 방식도 달라지는 흐름은 넥토리얼의 AI 평가 변화에서도 볼 수 있습니다.

참고 자료

이 글은 2026년 9월 10일 기준입니다. 실제 협업 저장소에서는 팀의 브랜치·리뷰 규칙을 먼저 확인하세요.