TL;DR
Git을 “개발자들이 쓰는 저장 도구” 정도로만 알고 있었습니다.
그런데 AI 코딩 에이전트와 같이 일하다 보니, Git은 단순한 저장 도구가 아니었습니다. 특히 commit, push, PR, merge는 각각 전혀 다른 의미를 갖고 있었습니다.
이번에 제가 정리한 핵심은 이렇습니다.
- 커밋은 내 컴퓨터 안에 남기는 의미 있는 작업 기록입니다.
- GitHub 업로드는 커밋을 원격 저장소에 올리는 push입니다.
- PR은 “이 변경을 공식 반영해도 되는지 검토해 주세요”라는 요청입니다.
- merge는 검토된 변경을 공식 흐름에 합치는 일입니다.
- AI 에이전트와 일할수록 작은 단위의 커밋은 더 중요해집니다.
저는 Git을 대충 알고 있었습니다
솔직히 말하면 Git을 완전히 처음 듣는 것은 아니었습니다.
커밋이라는 말도 들어봤고, GitHub도 알고 있었고, PR이나 merge라는 단어도 어디선가 본 적이 있었습니다. 다만 제 머릿속에서는 이것들이 한 덩어리로 뭉쳐 있었습니다.
“코드 고치고 GitHub에 올리는 과정 아닌가?”
비개발자인 제 입장에서는 이 정도 이해만으로도 한동안 큰 문제가 없었습니다. 제가 직접 개발팀의 작업 흐름을 운영하거나, AI 에이전트에게 코드를 고치게 하거나, 여러 변경을 안전하게 나눠야 하는 상황이 자주 없었기 때문입니다.
그런데 AI와 같이 실제 작업을 하다 보니 헷갈림이 바로 비용이 되었습니다.
무엇을 고쳤는지, 어디까지 내 컴퓨터에만 있는지, 무엇이 GitHub에 올라갔는지, 무엇이 실제 서비스에 반영될 수 있는 상태인지 구분하지 못하면 작업을 통제하기 어렵습니다.
커밋은 저장 버튼이 아니라 “작업의 의미”를 남기는 일입니다
제가 가장 먼저 정리한 개념은 커밋입니다.
커밋은 그냥 저장이 아니었습니다. 저장은 파일의 현재 상태를 보존하는 일에 가깝습니다. 커밋은 그보다 한 단계 더 나아가 “이 변경은 어떤 의미를 가진 작업입니다”라고 기록하는 행위입니다.
예를 들어 AI 에이전트가 Hermes의 Discord /status 응답 문제를 고쳤다고 해보겠습니다. 이때 파일 몇 개가 바뀌었다는 사실만 남기면 나중에 다시 추적하기 어렵습니다.
반대로 커밋을 잘 남기면 이렇게 기록할 수 있습니다.
“Discord gateway status command response path fix”
이 기록은 단순한 메모가 아닙니다. 나중에 문제가 생겼을 때 되돌아갈 기준점이 되고, 다른 사람이 변경 의도를 이해하는 설명서가 되고, 내가 AI와 함께 어떤 시행착오를 거쳤는지 남기는 학습 자산이 됩니다.
비개발자 입장에서 커밋을 이해하는 가장 쉬운 비유는 “작업 단위별 영수증”입니다. 무엇을 했는지, 언제 했는지, 왜 했는지를 남기는 증빙입니다.
로컬 커밋과 GitHub 업로드는 다릅니다
두 번째로 중요했던 구분은 로컬과 GitHub입니다.
로컬 커밋은 내 컴퓨터 안에 남는 기록입니다. 아직 GitHub에 올라간 것이 아닙니다. 그래서 로컬 커밋만 해두면 내 컴퓨터에서는 작업 이력이 정리되어 있지만, 다른 사람이나 원격 저장소는 그 변경을 모릅니다.
GitHub에 올리는 행위는 보통 push라고 부릅니다.
즉 흐름은 이렇게 나뉩니다.
내 컴퓨터에서 파일을 고칩니다. 그 변경을 커밋으로 기록합니다. 그다음 push를 해야 GitHub에 올라갑니다.
이 구분을 알고 나니 질문이 명확해졌습니다.
“지금 이 변경은 내 컴퓨터에만 있는가?”
“GitHub에도 올라갔는가?”
“다른 사람이 검토할 수 있는 상태인가?”
이 세 질문은 비개발자에게도 중요합니다. 특히 AI 에이전트에게 여러 작업을 맡기는 사람이라면 더 그렇습니다. AI가 뭔가를 고쳤다고 말하는 것과, 그 변경이 안전하게 기록되고 공유 가능한 상태가 되는 것은 다릅니다.
PR은 검수 요청이고, merge는 공식 반영입니다
PR은 Pull Request의 줄임말입니다. 이름만 보면 어렵지만, 실제 의미는 비교적 단순합니다.
“제가 이렇게 바꿨습니다. 공식 코드에 반영해도 될지 검토해 주세요.”
이것이 PR입니다.
PR에는 보통 변경 내용, 이유, 테스트 결과, 리뷰 코멘트가 함께 남습니다. 그래서 PR은 단순히 코드를 올리는 기능이 아니라 협업과 검수의 공간입니다.
merge는 PR로 올라온 변경을 공식 흐름에 합치는 일입니다. 보통 main 브랜치에 합친다고 표현합니다. main은 제품이나 프로젝트의 기준선처럼 취급되는 경우가 많습니다.
그래서 PR과 merge는 역할이 다릅니다.
- PR은 검토 요청입니다.
- merge는 공식 반영입니다.
이 둘을 구분하지 못하면 “GitHub에 올렸다”와 “서비스에 반영될 수 있는 흐름에 들어갔다”를 혼동하기 쉽습니다.
AI 에이전트와 일할수록 커밋은 더 중요해집니다
AI 에이전트는 빠르게 많은 것을 바꿀 수 있습니다. 이것은 장점이지만 동시에 위험이기도 합니다.
사람이 한 줄씩 천천히 바꾸는 것보다, AI는 여러 파일을 한 번에 수정하고, 설정을 바꾸고, 스크립트를 만들고, 테스트를 실행합니다. 이때 커밋 단위가 엉망이면 나중에 무엇이 왜 바뀌었는지 복원하기 어렵습니다.
제가 이번에 배운 실전 레슨은 단순합니다.
작업이 의미 있는 단위로 끝날 때마다 커밋해야 합니다.
예를 들어 다음 작업들은 한 커밋에 뭉뚱그리기보다 나누는 것이 좋습니다.
- Discord
/status무응답 수정 - gateway 재시작 락 처리 개선
- Codex sandbox 권한 안내 문서 수정
- Tally hidden fields 생성 스크립트 추가
- 블로그/뉴스레터 원고 생성
이렇게 나누면 나중에 특정 변경만 되돌리거나, 어떤 변경이 문제를 만들었는지 확인하기 쉬워집니다.
Compound engineering 관점에서 커밋은 지식 자산입니다
저는 요즘 “compound engineering”이라는 관점으로 AI와 일하는 방식을 보고 있습니다.
한 번의 작업이 그 자리에서 끝나는 것이 아니라, 다음 작업의 기반이 되어야 합니다. 오늘의 수정이 내일의 문서가 되고, 내일의 문서가 다음 자동화의 기준이 되고, 그 기준이 다시 더 좋은 시스템을 만드는 식입니다.
그 관점에서 커밋은 단순한 개발 기록이 아닙니다.
커밋은 축적되는 의사결정 로그입니다. AI가 어떤 파일을 왜 바꿨는지, 사람이 어떤 단위로 승인했는지, 어떤 테스트를 통과했는지 남기는 구조입니다.
비개발자가 AI 에이전트와 일할 때도 이 기록은 중요합니다. 오히려 더 중요할 수 있습니다. 코드 자체를 완전히 읽지 못하더라도, 커밋 메시지와 PR 설명을 보면 작업의 흐름을 이해할 수 있기 때문입니다.
좋은 커밋은 비개발자에게도 “이 시스템이 어떻게 변해왔는지”를 읽을 수 있게 해줍니다.
오늘부터 적용할 기준
제가 이번에 정리한 기준은 아주 실용적인 수준입니다.
첫째, 작업이 끝났다고 바로 GitHub에 올렸다고 생각하지 않습니다. 먼저 로컬 커밋인지, push까지 됐는지, PR이 만들어졌는지 구분합니다.
둘째, 커밋은 너무 크게 만들지 않습니다. “여러 가지 고침”보다는 “Discord status 응답 경로 수정”처럼 한 문장으로 설명 가능한 단위가 좋습니다.
셋째, AI 에이전트가 수정한 파일을 그냥 믿지 않습니다. 커밋 전에 변경 파일을 보고, 테스트나 로그 같은 확인 근거를 남깁니다.
넷째, GitHub에 올리는 시점은 협업이나 백업이 필요할 때입니다. 로컬에서 실험 중인 변경은 로컬 커밋으로 묶어둘 수 있고, 팀 검토가 필요하거나 원격 백업이 필요하면 push와 PR로 넘어갑니다.
다섯째, merge는 더 조심합니다. merge는 “이제 공식 흐름에 들어간다”는 의미이기 때문입니다.
마무리
비개발자로서 Git을 배운다는 것은 개발자가 되기 위한 공부만은 아니었습니다.
AI와 함께 일하는 시대에는 비개발자도 작업의 흐름을 알아야 합니다. 무엇이 내 컴퓨터에만 있는지, 무엇이 GitHub에 올라갔는지, 무엇이 검토 중인지, 무엇이 공식 반영됐는지 알아야 AI를 더 안전하게 쓸 수 있습니다.
이번에 제가 배운 가장 큰 레슨은 이것입니다.
고친 일은 기록해야 남습니다.
그리고 그 기록이 쌓여야, AI와의 작업도 단발성 실행이 아니라 복리처럼 쌓이는 엔지니어링이 됩니다.
FAQ
커밋하면 바로 GitHub에 올라가나요?
아닙니다. 커밋은 보통 내 컴퓨터의 로컬 저장소에 남는 기록입니다. GitHub에 올리려면 push가 필요합니다.
PR을 만들면 바로 서비스에 반영되나요?
아닙니다. PR은 검토 요청입니다. 리뷰와 테스트를 거쳐 merge되어야 공식 흐름에 반영됩니다.
비개발자도 커밋 단위를 신경 써야 하나요?
AI 에이전트에게 실제 파일 수정이나 자동화 작업을 맡긴다면 신경 쓰는 편이 좋습니다. 커밋 단위가 좋아야 나중에 추적, 검토, 되돌리기가 쉬워집니다.
언제 GitHub에 push하면 되나요?
팀과 공유해야 하거나, 원격 백업이 필요하거나, PR 리뷰를 받아야 할 때 push하면 됩니다. 아직 실험 중이라면 로컬 커밋으로만 정리해둘 수도 있습니다.