비개발자도 Git을 쓰는 AI 시대
요즘은 개발자가 아니어도 Git과 GitHub를 쓰는 경우가 많다.
(나도 기획자다..ㅎ)
자동화(n8n), 문서, 스크립트, 심지어 기획 산출물까지도 버전 관리가 필요한 순간이 계속 늘어나고 있다.
나 역시 로컬에서 마음대로 쓰다가 어느 순간부터 한계를 느꼈고,
이전으로 돌리고 수정하는데 토큰을 많이 낭비하게 되었다.
파일은 쌓이는데, 무엇을 왜 수정했는지 알 수 없었다.
되돌리고 싶어도 기준이 없었고, 협업에서는 더 큰 문제가 됐다.
Git을 잘 쓰는 것보다 더 중요한 건 ‘커밋 규칙’이라는 것을 느끼고
쉽게 쉽게 비개발자도 이해할 수 있는 커밋에 대한 이야기를 써보려 한다.
많은 사람들이 커밋을 이렇게 생각한다.
“작업 끝났으니까 저장”
“파일 바뀌었으니까 업로드”
틀린 말은 아니다.
하지만 실무에서는 이 정의로는 부족하다.
커밋은 단순 저장이 아니라
“의미 있는 변경 단위”를 남기는 기록이다.
이 기준이 없으면 이런 일이 생긴다.
한 커밋에 여러 작업이 섞인다
수정 이유를 알 수 없다
롤백이 불가능해진다
협업 시 충돌이 늘어난다
결국 커밋은 기록이 아니라 잡음이 된다.
복잡하게 생각할 필요 없다.
“한 가지 이유로 변경된 코드만 담는다”
이게 전부다.
이 기준을 적용하면 자연스럽게 커밋 단위가 정리된다.
예를 들어보자.
[ 나쁜 커밋 ]
로그인 UI 수정 + API 연결 + 오타 수정
→ 문제: 나중에 UI만 되돌리고 싶어도 불가능하다
[ 좋은 커밋 ]
로그인 버튼 UI 수정
로그인 API 연결
텍스트 오타 수정
→ 변경 이유가 각각 명확하다
비개발자도 쉽게 적용할 수 있는 기준으로 정리해 보면 다음과 같다.
새로운 기능이 추가될 때
회원가입 기능 추가
알림톡 발송 로직 추가
자동화 워크플로우 생성
가장 기본적인 커밋 단위다.
버그나 오류를 고칠 때
결제 실패 오류 수정
API 응답 파싱 오류 수정
잘못된 데이터 매핑 수정
“문제가 있었고 → 해결했다”가 명확해야 한다.
기능은 그대로, 구조만 개선할 때
함수 분리
변수명 변경
코드 정리
결과는 같지만 “더 좋게 만든 변경”
개발 환경이나 설정 변경
환경 변수 추가
API URL 변경
배포 설정 수정
실제 기능과 분리해서 관리하는 것이 중요하다.
기획자나 비개발자가 많이 쓰는 영역이다
README 수정
기획 문서 업데이트
텍스트/카피 수정
코드가 아니어도 충분히 커밋 대상이다.
커밋 규칙에서 메시지는 생각보다 중요하다.
하지만 어렵게 쓸 필요는 없다.
이 구조만 지켜도 80%는 해결된다.
[타입] 무엇을 왜 변경했는지
예시
feat: 알림톡 자동 발송 기능 추가
fix: 결제 실패 시 재시도 로직 오류 수정
docs: 기획서 API 흐름도 업데이트
여기서 중요한 건 하나다.
“왜 변경했는지 드러나는가”
개발자는 어느 정도 감각적으로 나눈다.
하지만 기획자나 운영자는 그렇지 않다.
그래서 더 쉽게 무너진다.
한 번에 몰아서 커밋
파일만 던져놓기
메시지 없이 업로드
이게 반복되면 Git은 그냥 “파일 저장소”가 된다.
하지만 커밋 규칙이 잡히면 상황이 달라진다.
작업 이력이 곧 문서가 된다
변경 이유를 추적할 수 있다
협업 시 커뮤니케이션 비용이 줄어든다
처음부터 완벽하게 만들 필요 없다.
이 3가지만 지켜도 충분하다.
한 커밋에는 한 가지 작업만 담는다
커밋 메시지에 “이유”를 포함한다
기능 / 수정 / 문서 정도로만이라도 구분한다
이 정도만 해도
Git은 단순 저장소가 아니라 업무 기록 시스템이 된다.
Git을 쓰기 시작하면 보통 이렇게 생각한다.
“버전 관리 도구를 쓴다”
하지만 실제로는 다르다.
“업무를 기록하는 방식이 바뀐다”
커밋 규칙은 그 중심에 있다.
혼자 쓰더라도 반드시 필요하고,
협업이라면 더더욱 필수다.
Git 기초 개념이나 명령어는 따로 정리해 두었다.
처음이라면 아래 글을 먼저 보는 것을 추천한다.
https://tamisandbox.tistory.com/16
커밋을 잘 남기는 사람은
결국 일을 잘 정리하는 사람이다.
그리고 그 차이는
시간이 지날수록 크게 벌어진다.