Commit은 어느 시점, 어느 단위로 쪼개는 게 좋을까?

커밋, 언제 하고 어떻게 해야 할까?

요즘 프로젝트를 진행하다 보면 자연스럽게 커밋을 하게 되는데, 문득 "도대체 어떤 시점에, 어느 정도 단위로 커밋을 해야 하는 걸까?"라는 고민이 들었다. 그래서 이 기회에 한 번 정리도 해보고, 다른 개발자들의 의견도 참고해서 나만의 기준을 잡아보고자 한다.

---

내가 했던 커밋 방식

나는 프로젝트마다 커밋 방식이 제각각이었다. 어느 프로젝트에서는 하루 작업이 끝난 후 기능별로 쪼개서 커밋했고, 또 다른 프로젝트에서는 그냥 큰 덩어리 단위로 묶어서 올린 적도 있다.예를 들어 User 도메인 작업을 할 땐 이런 식이었다:

chore: User 엔티티 및 기본 설정
feat: 회원가입 요청/응답 객체 추가
feat: 회원가입 서비스 로직 작성

그 당시에는 ‘기능 단위로 잘 나눴다’고 생각했지만, 시간이 지나서 보니 커밋 시점이나 내용에 대한 명확한 기준 없이 일단 작업이 끝났으니까 커밋했던 것 같기도 하다.

---

🤔 나의 고민들

이번에 다시 커밋에 대해 고민하게 된 계기는 아래 두 가지 이유 때문이다:

1. 언제 커밋해야 할까?
2. 기능 하나를 만들다 보면, 메소드 하나로 끝나는 게 아니라 연관된 클래스나 로직이 계속 생긴다. 설계를 완벽하게 하지 않으면 코드가 어디까지 퍼질지 모르는데, 중간에 끊어서 커밋해도 되는 건지 늘 고민이다.
3. 어느 단위로 커밋해야 할까?
4. 너무 작게 나누면 불완전한 코드가 올라가 버리고, 너무 크면 추적이 어려워진다. 그래서 머릿속에선 늘 "이게 지금 커밋해도 되는 타이밍일까?"를 떠올리게 된다.

---

🙋‍♂️ 내 생각

나는 원래 커밋은 "작고 자주" 하는 게 좋다고 생각은 해왔다. 하지만 막상 기능을 만들다 보면 어느 정도 완성된 다음에야 안심이 돼서 커밋하게 되는 경우가 많았다.

 

특히 "불완전한 코드"를 커밋하고 싶지 않은 심리가 컸다. 푸시하면 GitHub에 흔적이 남고, 나중에 지우거나 정리하기도 번거롭기 때문이다. 그래서 ‘최소한 테스트 통과는 시켜놓고 커밋하자’는 나름의 기준을 세워두고 있었다.

---

다른 개발자들의 의견

이런 고민을 많이 찾아보고, 개발자들에게 물어보니 공통된 조언이 많았다.

• 작게 쪼개서 자주 커밋하라는 의견이 많았고,
• 불완전한 커밋을 두려워할 필요는 없다는 말도 공감됐다.

준섭이의 의견

예를 들어 어떤 분은 이런 말을 했다:

완성된 코드라는 건 존재하지 않는다. 기능이 돌아간다고 해도 리팩토링 대상이 될 수도 있고, 요구사항이 바뀌면 어차피 고치게 된다.

 

이 말을 듣고 나니 ‘지금 기준의 완성’보다는 변경의 흐름을 잘 기록하는 게 더 중요하겠다는 생각이 들었다.

또한 불필요한 커밋이 많아질 거라는 걱정에 대해선 Squash Merge나 Rebase를 통해 정리하는 방안을 생각해봐야겠다.
결국 커밋은 ‘작업의 단위’로 잘게 쪼개되, 최종적으로는 정리해서 의미 있는 히스토리를 만드는 게 핵심이란 생각이 든다.

---

앞으로의 나만의 커밋 기준

1. 기능 단위가 아닌, 의미 단위로 쪼개서 커밋하기
   • 메소드 하나라도 명확한 역할이 분리된다면 커밋 타이밍
2. 불완전해도 작업 흐름을 남긴다는 관점으로 커밋하기
   • 단, 테스트가 통과하지 않는 상태라면 WIP 태그로 명시.
3. 최종 Merge 시점에 커밋 히스토리는 정리한다는 전제 하에 작업하기

---

🙇‍♂️ 마무리

사실 커밋 하나에도 이렇게 고민하게 될 줄은 몰랐다.
하지만 막상 글로 정리해보니 지금까지 내가 얼마나 무의식적으로 커밋했는지 알게 됐고, 앞으로 어떻게 더 잘 관리할 수 있을지도 조금씩 보이기 시작했다. 커밋은 단순한 저장이 아니라, "협업과 유지보수의 흐름을 기록하는 것" 라는 생각이 든다.
앞으로는 의미 있는 커밋을 남길 수 있는 개발자가 되고 싶다.

 

위스키 먹게 돈 많이 벌자!!