AI가 코드를 써주지만 이제 비개발자도 Git을 알아야해요

AI에게 "로그인 화면 만들어줘"라고 맡겼더니 파일 여러 개가 한꺼번에 바뀌는 순간이 있습니다. 화면은 바뀐 것 같은데, 정확히 어떤 파일이 바뀌었는지, 기존 코드가 지워졌는지, 설정 파일까지 건드렸는지 바로 보이지 않으면 불안해집니다.

이때 필요한 게 바로 Git입니다. 개발자들만 쓰는 어려운 기술처럼 보이지만, AI 코딩을 시작하는 사람에게 Git은 단순 명료합니다. AI가 바꾼 내용을 기록하고, 비교하고, 필요하면 되돌리기 위한 '안전장치'입니다.

Git과 GitHub의 차이점

Git은 내 컴퓨터 안에서 코드 변경 이력을 기록하는 도구예요. 어떤 파일이 언제 바뀌었는지, 어떤 줄이 추가됐고 삭제됐는지, 어느 시점으로 되돌아갈 수 있는지를 저장합니다. 문서 작업으로 비유하면 "저장 기록이 아주 촘촘하게 남는 버전 관리"에 가깝습니다.

GitHub는 Git으로 기록한 프로젝트를 온라인에 올려두는 서비스예요. 내 컴퓨터 안에만 있던 변경 이력을 인터넷 공간에 올려 백업하고, 다른 사람이나 AI 도구와 함께 확인할 수 있게 해줍니다. Git이 기록 도구라면, GitHub는 그 기록을 올려두고 검토하는 작업 공간입니다.

Git 공식 문서는 Git을 버전 관리 시스템으로 설명하고, GitHub Docs는 Git과 GitHub의 관계를 처음 시작하는 사람 기준으로 정리해둡니다. 처음에는 이 차이만 잡아도 충분해요. Git은 내 컴퓨터의 변경 기록, GitHub는 그 기록을 온라인에서 보고 공유하는 곳입니다.

repository는 저장소에요

repository는 줄여서 repo, 한국어로는 저장소라고 부릅니다. 어렵게 들리지만 프로젝트 폴더라고 생각하면 됩니다. 다만 그냥 파일만 담는 폴더가 아니라, 그 파일들이 어떻게 바뀌었는지 기록까지 함께 담는 폴더예요.

내 컴퓨터에 있는 저장소는 로컬 저장소라고 부릅니다. GitHub에 올라간 저장소는 원격 저장소라고 부릅니다. 로컬은 내 작업실, 원격은 온라인 백업 공간이라고 보면 됩니다.

AI 코딩 도구로 프로젝트를 만들다 보면 폴더 안에 `.git`이라는 숨김 폴더가 생기는 경우가 있어요. 이 폴더 안에 Git의 변경 기록이 들어갑니다. 이걸 지우면 기록도 함께 사라질 수 있으니, 뭔지 모르는 상태에서 삭제하지 않는 게 좋아요.

작업이 마무리 되면 꼭 해야하는 commit

commit은 현재 프로젝트 상태를 하나의 저장 지점으로 남기는 행동이에요. "여기까지는 괜찮았다"라고 표시해두는 순간입니다.

AI에게 코드를 맡기기 전에는 특히 이 저장 지점이 중요합니다. 예를 들어 지금 사이트가 정상적으로 돌아가고 있다면, 먼저 커밋을 만들어둡니다. 그다음 AI에게 기능 추가를 맡겨요. 만약 AI가 만든 코드가 문제를 일으키면, 방금 만들어둔 커밋으로 돌아갈 수 있습니다.

커밋 메시지는 거창할 필요 없어요. "로그인 화면 수정", "결제 버튼 추가 전 상태", "AI가 만든 회원가입 폼 확인"처럼 나중에 봤을 때 무슨 작업이었는지만 알면 됩니다. 중요한 건 저장 지점을 자주 남기는 습관입니다.

branch는 언제 필요할까요?

branch는 본 작업을 망치지 않고 실험하기 위한 작업 줄기예요. 보통 `main`이라는 기본 줄기에 안정적인 코드를 두고, 새 기능을 만들 때 별도 branch를 만들어 작업합니다.

혼자 작업한다면 처음부터 branch를 매번 쓸 필요는 없어요. 하지만 AI에게 큰 변경을 맡길 때는 branch가 꽤 유용합니다. 예를 들어 "결제 기능 실험" branch를 만들고 AI에게 작업을 맡기면, 실패했을 때 그 branch만 버리면 됩니다. 안정적인 `main`은 그대로 남아 있어요.

이 감각이 중요합니다. AI 코딩은 빠르기 때문에 한 번에 많은 파일이 바뀌기 쉽습니다. branch는 그 빠른 실험을 안전한 공간 안에 가둬두는 장치입니다.

pull request가 뭐고 왜 필요할까요?

pull request는 줄여서 PR이라고 부릅니다. GitHub에서 쓰는 기능이고, "이 변경을 main에 합쳐도 될까요?"라고 확인하는 과정이에요.

팀 개발에서 PR은 다른 사람에게 리뷰를 받는 절차입니다. 하지만 혼자 작업할 때도 쓸모가 있어요. PR 화면에서는 어떤 파일이 바뀌었는지, 어떤 줄이 추가됐는지, 테스트가 통과했는지 한 화면에서 볼 수 있습니다.

특히 AI가 만든 변경을 확인할 때 PR은 좋은 검토대가 됩니다. GitHub의 pull request 문서도 PR을 변경 제안과 검토를 위한 기능으로 설명합니다. 초보라면 "남에게 보여주는 절차"보다 "내가 AI 변경을 한 번 더 확인하는 화면"으로 먼저 이해해도 됩니다.

AI 코딩에서 Git은 왜 중요한가요

AI 코딩에서 가장 무서운 순간은 코드가 바뀌었다는 사실이 아니라, 어디가 왜 바뀌었는지 모르는 상태입니다.

Git은 이 문제를 줄여줍니다. `diff`는 차이를 보여주는 기능이에요. AI가 파일을 고친 뒤 `git diff`를 보면 초록색으로 추가된 줄, 빨간색으로 삭제된 줄을 확인할 수 있습니다. 파일 전체를 처음부터 끝까지 다시 읽지 않아도, 바뀐 부분부터 볼 수 있어요.

이건 단순한 편의 기능이 아닙니다. AI가 실수로 설정 파일을 바꿨는지, 기존 함수를 지웠는지, 필요 없는 코드를 추가했는지 확인하는 기본 절차예요. AI에게 코드를 맡길수록 Git은 더 중요해집니다. 코드를 직접 한 줄씩 쓰는 시간은 줄어도, 바뀐 결과를 검토하고 책임지는 일은 사라지지 않기 때문입니다.

코딩을 못하는 비개발자가 Cursor를 선택한 진짜 이유는?에서 말한 것처럼 AI 코딩 도구는 시작 장벽을 낮춰줍니다. 다만 시작이 쉬워질수록, 변경을 확인하는 습관은 더 빨리 익혀야 합니다.

먼저 익힐 명령어는 무엇인가요

처음부터 Git 명령어를 많이 외울 필요는 없어요. AI에게 코드를 맡기는 사람이라면 아래 다섯 개부터 익히면 됩니다.

루틴은 간단합니다. AI에게 일을 맡기기 전에 `git status`로 현재 상태가 깨끗한지 봅니다. 작업이 끝나면 `git diff`로 변경 내용을 확인합니다. 괜찮으면 `git add`와 `git commit`으로 저장 지점을 남깁니다.

명령어를 외우는 것보다 이 순서가 더 중요합니다. 확인하고, 비교하고, 저장한다. Git 초보는 이 세 단계부터 시작하면 됩니다.

GitHub에서는 어디를 봐야 하나요

GitHub 화면에서 처음부터 모든 탭을 볼 필요는 없어요. AI 코딩 초보라면 네 군데만 먼저 보면 됩니다.

첫째, changed files입니다. 바뀐 파일과 줄을 보여주는 화면이에요. AI가 만든 변경을 확인할 때 가장 먼저 봐야 합니다.

둘째, commits입니다. 저장 지점 목록이에요. 언제 어떤 작업을 저장했는지 확인할 수 있습니다.

셋째, pull request입니다. 변경을 합치기 전에 한 번 검토하는 공간이에요. 혼자 작업해도 PR을 만들면 변경 범위를 차분히 볼 수 있습니다.

넷째, checks 또는 actions입니다. 테스트나 배포 자동화가 통과했는지 보는 곳이에요. 처음에는 어려워 보여도, "초록색이면 통과, 빨간색이면 확인 필요" 정도로만 봐도 도움이 됩니다.

방금 발행한 AI가 코드를 빨리 만들어주는데, 왜 GitHub에서 병목이 터질까는 이 다음 단계 글입니다. Git과 GitHub의 기본 역할을 이해한 뒤 읽으면, 왜 AI 시대에 PR과 checks가 더 중요해지는지 훨씬 선명하게 보입니다.

AI에게 코드를 맡기기 전에는 무엇을 확인하나요

AI에게 일을 맡기기 전에는 먼저 지금 상태를 저장해야 합니다. 작업이 이미 꼬인 상태에서 AI에게 새 일을 맡기면, 어디서부터 문제가 생겼는지 추적하기 어려워집니다.

가장 간단한 순서는 이렇습니다.

1. `git status`로 바뀐 파일이 있는지 본다.

2. 이전 작업이 남아 있으면 먼저 확인하고 커밋한다.

3. AI에게 맡길 일을 작게 쪼갠다.

4. 한 번에 하나의 기능만 요청한다.

"로그인, 결제, 관리자 페이지까지 한 번에 만들어줘"라고 맡기면 변경 파일이 너무 많아집니다. "로그인 버튼 위치만 바꿔줘", "회원가입 폼에 이메일 검증만 추가해줘"처럼 작게 맡겨야 나중에 확인할 수 있습니다.

AI가 똑똑해질수록 요청을 크게 던지고 싶어집니다. 하지만 초보일수록 작업은 작게 쪼개야 합니다. 그래야 Git이 보여주는 변경 내용도 읽을 수 있어요.

AI가 작업한 뒤에는 무엇을 확인하나요

AI가 작업을 끝냈다면 바로 배포하지 말고 세 가지를 봅니다.

첫째, 어떤 파일이 바뀌었는지 봅니다. `git status`로 파일 목록을 확인하세요. 예상하지 못한 파일이 바뀌었다면 그 이유를 AI에게 다시 물어봐야 합니다.

둘째, 어떤 줄이 바뀌었는지 봅니다. `git diff`로 추가된 줄과 삭제된 줄을 확인하세요. 특히 설정 파일, 결제 관련 파일, 데이터베이스 관련 파일은 더 조심해서 봐야 합니다.

셋째, 실행해봅니다. 화면이 열리는지, 버튼이 눌리는지, 에러가 뜨지 않는지 확인합니다. 테스트 명령어가 있다면 테스트도 돌립니다.

이 세 가지를 통과하면 그때 커밋합니다. 커밋은 "대충 저장"이 아니라 "내가 확인한 상태"를 남기는 일입니다.

Git을 모르면 어떤 문제가 생기나요

Git 없이 AI 코딩을 하면 변경이 전부 한 덩어리로 섞입니다. 로그인 수정, 디자인 변경, 설정 파일 수정이 한꺼번에 들어가면 나중에 특정 작업만 되돌리기 어렵습니다.

AI가 실수로 코드를 지워도 바로 알아차리기 어렵습니다. diff가 없으면 무엇이 사라졌는지 파일 전체를 뒤져야 합니다.

배포 후 문제가 생겼을 때도 곤란합니다. 되돌아갈 커밋이 없으면 "어제는 됐는데 오늘은 왜 안 되지?" 상태가 됩니다. 반대로 커밋이 잘 남아 있으면 정상 동작하던 지점을 찾아 돌아갈 수 있습니다.

GitHub에 올린 코드와 내 컴퓨터 코드가 달라지는 문제도 생깁니다. 여러 컴퓨터에서 작업하거나 배포 서버와 연결할 때는 GitHub의 원격 저장소가 기준점이 됩니다. 이 흐름을 모르면 "내 컴퓨터에서는 되는데 배포하면 안 되는" 상황을 해결하기가 훨씬 어려워집니다.

Git은 AI 코딩의 안전장치예요

Git은 개발자 자격증 같은 것이 아닙니다. AI가 만든 변경을 내가 확인하고 통제하기 위한 최소한의 안전장치입니다.

AI가 코드를 빠르게 써줄수록 Git은 더 필요합니다. 변경 속도가 빨라지면 실수도 빠르게 섞일 수 있기 때문이에요. 중요한 건 AI를 덜 쓰는 게 아니라, AI가 만든 결과를 확인할 수 있는 구조를 갖추는 일입니다.

오늘 당장 다 배울 필요는 없습니다. `git status`, `git diff`, `git commit` 세 가지부터 시작해도 됩니다. 작업 전 상태를 보고, 작업 후 차이를 확인하고, 괜찮은 상태를 저장하는 것. 이 루틴이 생기면 AI 코딩은 훨씬 덜 무서워집니다.

한 번 더, 빠르게 짚고 갈게요

Q. Git과 GitHub는 같은 건가요? A. 아니요. Git은 내 컴퓨터에서 변경 이력을 기록하는 도구이고, GitHub는 그 기록을 온라인에 올려두는 서비스입니다.

Q. Git을 꼭 명령어로 써야 하나요? A. 아니요. Cursor, VS Code, GitHub Desktop 같은 GUI 도구로 써도 됩니다. 다만 commit, diff, branch가 무엇인지는 알아야 버튼을 눌렀을 때 무슨 일이 일어나는지 이해할 수 있어요.

Q. AI에게 맡길 때마다 커밋해야 하나요? A. 큰 작업 전에는 커밋하는 게 안전합니다. 작업이 작다면 몇 번 확인한 뒤 하나의 커밋으로 묶어도 됩니다. 기준은 "나중에 이 상태로 돌아가고 싶은가"예요.

Q. branch는 초보도 써야 하나요? A. 처음에는 main 하나로 시작해도 됩니다. 다만 AI에게 실험적인 기능을 맡길 때는 branch를 쓰면 훨씬 안전합니다.

Q. 지금 하나만 익힌다면 뭘 해야 하나요? A. `git status`와 `git diff`부터 익히세요. AI가 바꾼 파일 목록과 실제 변경 줄을 보는 습관이 가장 먼저입니다.