commit은 언제 해요? 작업을 안전하게 나누는 기준

수강생들이 Git을 배우면서 많이 묻는 질문이 있습니다.

commit은 언제 해요?
파일을 고칠 때마다 해야 하나요?
기능을 전부 만든 뒤 한 번만 하면 되나요?

정답부터 말하면 하나의 의미 있는 작업을 끝내고 결과를 확인했을 때 commit하면 됩니다.

시간을 기준으로 “10분마다” 또는 “하루에 한 번” commit하는 것이 아니에요. 작업의 경계를 기준으로 나눕니다.

한 가지 목적의 작업
→ 결과 확인
→ commit
→ 다음 작업 시작

commit과 push의 차이가 아직 낯설다면 commit, push, pull 기본 개념을 먼저 읽어도 좋습니다.

commit은 저장 버튼이 아니에요

코드 파일은 수정할 때마다 저장할 수 있습니다. 자동 저장을 켜두면 몇 초마다 파일이 저장되기도 해요.

commit은 저장과 역할이 다릅니다. 현재까지 바꾼 내용을 나중에 이해할 수 있는 하나의 작업 기록으로 묶습니다.

저장
→ 파일의 최신 내용을 유지

commit
→ 작업의 목적과 변경 내용을 기록

따라서 글자 하나를 바꿀 때마다 commit할 필요는 없습니다. 반대로 여러 기능을 며칠 동안 만든 뒤 한 번에 commit하면 기록이 너무 커져요.

좋은 commit은 나중에 봤을 때 다음 질문에 답할 수 있어야 합니다.

무엇을 바꿨나요?
왜 바꿨나요?
어디까지 잘 작동하나요?

가장 좋은 기준은 “작동하는 작은 단위”예요

회원가입 화면을 만든다고 해볼게요. “회원가입 완성”까지 기다렸다가 한 번만 commit할 수도 있습니다. 하지만 회원가입에는 여러 작업이 들어가요.

입력 화면 만들기
→ 이메일 형식 확인
→ 비밀번호 조건 확인
→ 가입 정보를 서버에 보내기
→ 성공과 실패 메시지 보여주기

각 단계는 따로 만들고 확인할 수 있습니다.

입력 화면이 원하는 모습으로 나옴
→ commit

잘못된 이메일을 막는 기능이 작동함
→ commit

가입 정보를 서버에 저장하는 기능이 작동함
→ commit

이렇게 나누면 문제가 생겼을 때 어느 작업에서 시작됐는지 찾기 쉬워집니다. 잘 작동하던 시점과 현재 상태를 비교하기도 편해요.

핵심은 commit의 크기가 아니라 하나의 목적을 설명할 수 있는가입니다.

작은 기능이 작동하면 commit하세요

사용자가 확인할 수 있는 작은 변화가 완성됐다면 commit하기 좋은 순간입니다.

예를 들면 다음과 같아요.

• 신청 버튼을 누르면 신청 정보를 저장한다.
• 필수 항목을 비우면 안내 문구를 보여준다.
• 관리자 화면에서 신청자 목록을 볼 수 있다.
• 모바일 화면에서 메뉴가 정상적으로 열린다.

“페이지 전체 완성”처럼 큰 단위가 아니어도 괜찮습니다. 한 문장으로 설명할 수 있고 직접 확인할 수 있다면 충분해요.

신청 버튼 연결
→ 직접 신청해봄
→ 데이터 저장 확인
→ commit

버그 수정을 확인하면 commit하세요

오류를 고친 뒤에는 문제 상황을 다시 실행해봐야 합니다.

문제 재현
→ 원인 수정
→ 같은 상황에서 다시 확인
→ 오류가 사라짐
→ commit

코드를 바꿨다는 이유만으로 바로 commit하지 마세요. 수정한 코드가 실제 문제를 해결했는지 확인한 뒤 기록해야 합니다.

예를 들어 전화번호를 입력하면 신청이 실패하던 문제를 고쳤다면 다음 내용을 확인할 수 있어요.

• 정상 전화번호로 신청이 완료되는가?
• 잘못된 번호에는 안내 문구가 나오는가?
• 기존 신청 기능은 계속 작동하는가?

확인까지 마치면 “전화번호 입력 오류 수정”처럼 목적이 분명한 commit을 만들 수 있습니다.

큰 변경을 시작하기 전에 commit하세요

AI에게 큰 수정을 맡기기 전에도 commit이 필요합니다.

현재 상태는 잘 작동함
→ commit으로 안전한 지점 기록
→ 화면 전체 개편 시작

예를 들어 다음 요청은 많은 파일을 바꿀 수 있어요.

회원가입 구조를 전부 바꿔줘.
데이터베이스를 새 구조로 옮겨줘.
결제 기능을 다른 서비스로 교체해줘.

큰 변경을 시작하기 전에 현재 상태를 commit하면 작업 전후를 비교하기 쉽습니다. 새 작업에서 문제가 생겨도 어디서부터 달라졌는지 찾을 수 있어요.

AI에게 다음처럼 요청해보세요.

큰 수정을 시작하기 전에 현재 변경 내용을 확인해줘.
지금 상태가 정상 작동한다면 안전한 지점으로 commit할 내용을 먼저 설명해줘.
내가 확인하기 전에는 commit하거나 새 작업을 시작하지 마.

다른 작업으로 넘어가기 전에 commit하세요

한 작업을 하다가 갑자기 다른 아이디어가 떠오를 수 있습니다.

신청 폼 오류를 수정하는 중
→ 관리자 화면 디자인도 바꾸고 싶음

두 작업을 섞으면 하나의 commit에 서로 관계없는 변경이 들어갑니다. 먼저 신청 폼 수정을 끝내고 확인한 뒤 commit하세요. 이후 관리자 화면 작업을 시작하면 기록이 깔끔하게 나뉩니다.

commit 설명에 “그리고”가 계속 들어간다면 작업을 너무 많이 묶었을 가능성이 큽니다.

신청 오류를 고치고
버튼 색상을 바꾸고
관리자 목록을 정리하고
이메일 문구도 수정함

각 변경의 목적이 다르다면 여러 commit으로 나누는 편이 좋습니다.

잠시 작업을 멈출 때는 어떻게 할까요?

작업을 끝내지 못했는데 자리를 비워야 할 수도 있습니다. commit은 완벽하게 완성한 기능에만 사용할 수 있는 것은 아니에요. 다만 작업 중인 상태라는 사실을 분명히 남겨야 합니다.

가능하면 오류가 나는 중간 상태보다, 작게라도 정상 작동하는 지점까지 정리한 뒤 commit하세요.

좋은 중단 지점
→ 화면은 열리고 지금까지 만든 부분은 작동함

피하고 싶은 중단 지점
→ 앱이 열리지 않고 무엇이 깨졌는지 모름

중간 상태를 꼭 기록해야 한다면 AI에게 아직 완성하지 않은 부분과 현재 문제를 commit 설명에 분명히 남겨달라고 하세요. 다음 작업을 시작할 때 무엇부터 이어야 하는지 함께 기록하면 좋습니다.

commit하기 전에 세 가지만 확인하세요

1. 한 가지 목적의 변경인가요?

“무엇을 바꿨는지” 한 문장으로 설명해보세요. 설명이 너무 길거나 여러 주제가 섞이면 나눌 수 있는지 확인합니다.

2. 직접 결과를 확인했나요?

화면을 열어보고 버튼을 눌러보거나, 저장한 데이터가 들어갔는지 확인하세요. AI가 “완료했습니다”라고 말한 것과 실제 기능이 작동하는 것은 다를 수 있습니다.

3. 비밀값이나 관계없는 파일이 들어가지 않았나요?

환경변수 파일, API 키, 개인정보가 든 파일을 commit하면 안 됩니다. 이번 작업과 관계없는 수정도 함께 들어가지 않았는지 확인하세요.

이 확인도 AI에게 맡길 수 있습니다.

commit하기 전에 확인해줘.

1. 이번 작업과 관련된 변경만 들어가는지
2. 기능을 실제로 확인했는지
3. 비밀값이나 개인정보가 포함되지 않았는지

확인 결과와 commit에 넣을 파일을 쉬운 말로 설명해줘.
아직 commit하지 마.

commit과 push는 시점이 다를 수 있어요

commit은 내 컴퓨터에 작업 기록을 만듭니다. push는 기록을 GitHub에 올려요.

작은 작업을 마칠 때마다 commit하고, 여러 commit을 확인한 뒤 GitHub에 push할 수도 있습니다.

기능을 어떤 크기의 작업으로 나눌지 정하지 않았다면 PRD를 개발 계획으로 바꾸는 방법에서 작업별 완료 기준과 순서를 먼저 정리해보세요.

입력 화면 완성 → commit
입력값 확인 완성 → commit
서버 저장 연결 → commit
전체 흐름 확인 → push

다만 프로젝트 설정에 따라 push가 실제 배포를 시작할 수 있습니다. 아직 고객에게 보여주면 안 되는 기능이라면 AI에게 push가 배포로 이어지는지 먼저 확인해달라고 하세요.

이 프로젝트에서 GitHub에 push하면 실제 사이트까지 바로 배포되는지 확인해줘.
배포가 시작된다면 아직 push하지 말고 commit까지만 진행해줘.

commit은 기록을 남기는 일이고, push는 기록을 온라인으로 보내는 일이며, 배포는 실제 서비스를 새 버전으로 바꾸는 일입니다. 세 작업을 따로 이해해야 안전하게 결정할 수 있어요.

너무 자주 해도, 너무 늦게 해도 불편해요

파일을 저장할 때마다 commit하면 기록이 지나치게 잘게 나뉩니다.

버튼 글자 수정
→ commit
버튼 여백 2px 수정
→ commit
문장 부호 수정
→ commit

반대로 하루 동안 만든 모든 기능을 한 번에 commit하면 문제가 생긴 지점을 찾기 어렵습니다.

로그인 + 결제 + 관리자 + 디자인
→ commit 하나

적당한 기준은 “작동하는 작은 단위”입니다.

너무 작음
→ 무엇을 완성했는지 의미가 없음

적당함
→ 한 가지 목적을 완료하고 결과를 확인함

너무 큼
→ 여러 목적과 기능이 섞임

AI에게 commit 지점을 먼저 계획시켜보세요

기능을 만들기 전에 AI에게 작업을 어떻게 나눌지 물어볼 수 있습니다.

회원가입 기능을 만들려고 해.
작업을 작동하는 작은 단위로 나누고, 언제 확인하고 commit하면 좋을지 계획해줘.
각 commit은 한 가지 목적만 갖게 해줘.
아직 코드를 수정하지 마.

AI가 다음처럼 계획할 수 있어요.

1. 회원가입 입력 화면 만들기 → 확인 → commit
2. 입력값 검사 추가하기 → 확인 → commit
3. 서버 저장 연결하기 → 확인 → commit
4. 성공·실패 안내 추가하기 → 확인 → commit
5. 전체 회원가입 흐름 확인하기 → push 검토

이렇게 시작하면 AI가 많은 파일을 한꺼번에 바꾼 뒤 마지막에 거대한 commit 하나를 만드는 일을 줄일 수 있습니다.

가장 간단한 기준

commit할지 고민될 때 다음 문장을 채워보세요.

나는 방금 __________을 끝냈고,
__________을 직접 확인했다.

두 칸을 구체적으로 채울 수 있다면 commit하기 좋은 순간입니다.

나는 방금 신청 버튼 연결을 끝냈고,
테스트 신청이 저장되는지 직접 확인했다.

반대로 “여러 가지를 조금씩 바꿨는데 아직 잘 모르겠다”면 변경을 정리하고 확인할 일이 남아 있습니다.

정리

• commit은 정해진 시간이 아니라 작업의 경계에서 합니다.
• 한 가지 목적의 작은 기능이 작동하면 commit하세요.
• 버그를 고치고 같은 상황에서 문제가 사라졌는지 확인한 뒤 commit하세요.
• 큰 변경을 시작하거나 다른 작업으로 넘어가기 전에 안전한 지점을 commit하세요.
• commit하기 전에 작업 범위, 작동 여부, 비밀값 포함 여부를 확인하세요.
• commit과 push, 배포는 서로 다른 일이므로 각각의 시점을 결정하세요.
• AI에게 기능 구현뿐 아니라 commit 지점도 미리 계획시킬 수 있습니다.

가장 중요한 기준은 하나예요.

한 가지 작업을 끝내고, 잘 작동하는지 확인했다면 commit할 때입니다.

프로젝트를 처음 만들고 GitHub에 올리는 전체 과정 안에서 커밋을 연습하려면 바이브코딩 가이드 7장을 따라 해보세요.