어느 날 밤, 팀 채팅방에 내 GitHub 잔디가 올라왔다.
“어케 하루에 평균 20 commit을 하죠?”
“컨트리뷰션 기계”, “GOAT” 같은 반응이 달렸다. 재밌게 봤는데, 문득 궁금해졌다. 진짜 그때가 가장 생산적인 시기였을까?
직감적으로 “요즘이 오히려 더 잘 되는 것 같은데”라는 느낌이 있었다. 근거 없는 착각일 수도 있으니, 실제 데이터를 까봤다.
6개월치 git 로그를 분석해봤다
작업일지 77건, git 커밋 로그 전체를 주 단위로 집계했다.
10~11월에는 하루에 50커밋 가까이 찍었다.
3월에는 22커밋도 안 된다.
커밋만 보면 생산성이 반토막 난 것처럼 보인다.
그런데 올해 2월부터 도입한 Feature 추적 시스템으로 “완료된 기능 단위”를 세보면 이야기가 달라진다.
3월에는 일평균 7.0개 Feature를 완료했다. 최대 11개/일. Feature당 커밋은 약 3개.
10~11월에는 Feature 단위 추적이 없어서 정확한 비교는 불가능하다. 다만 작업일지를 분석해보면, 하나의 기능에 커밋이 15~20개씩 들어간 흔적이 많았다. 커밋 → 버그 발견 → 수정 커밋 → 또 발견 → 또 수정의 반복.
즉, 10~11월은 커밋을 많이 “쳐야만 했던” 시기였다.
결정적 지표: post-commit hotfix
커밋 수나 Feature 수보다 더 직관적인 효율 지표가 있다. “커밋 후 즉시 수정한 횟수”.
10~11월에는 일 2~3건. 3월에는 3일간 총 2건.
10월 30일의 실제 기록이다:
06:18 기능 커밋
06:25 버그 수정 (user.id vs user.data.id 타입 불일치)
06:33 추가 수정 (다이얼로그 중복)
15분 안에 같은 기능을 3번 커밋했다. 이게 당시에는 일상이었다.
3월에는 이 패턴이 거의 사라졌다. 물론 여전히 실수는 하지만, 빈도가 확연히 다르다.
뭐가 달라졌나
1. 시스템이 쌓였다
6개월 전에는 프로젝트 규칙을 하나의 파일에 담고, AI에게 매번 수동으로 컨텍스트를 설명했다.
지금은 208개 Feature가 ID로 관리되고, 백엔드 파일을 열면 Spring Boot 규칙이 자동 로딩되고, 커밋 시 자동 검증이 걸려 있고, /inspect나 /test 같은 반복 워크플로가 한 명령으로 실행된다.
이 시스템들을 만드는 데 들인 시간이, 이후의 모든 작업에서 복리로 돌아오는 구조다. 커밋 전에 /inspect가 문제를 잡아주니, “커밋 → 7분 후 버그 수정” 사이클이 사라졌다.
2. 삽질이 경험이 됐다
10~11월에 많이 부딪혔기 때문에 지금이 가능하다.
10월에 가장 비효율적이었던 날은 리팩토링 후폭풍으로 하루 종일 수습만 한 날이었다. 하나의 구조 변경이 7개 쿼리를 파손시키고 100개 이상의 컴파일 에러를 만들었다. 208개 Feature를 거치면서 코드베이스의 멘탈 모델이 완성됐고, LazyInitException이나 N+1 같은 패턴은 설계 단계에서 감이 온다.
이건 시스템이 아니라 순수하게 시간과 경험의 결과다. 지름길은 없었다.
3. 코드베이스가 성숙했다
그 경험 덕분에 2월에 기술 부채를 체계적으로 정리할 수 있었다. dead code 5,156줄 삭제, campus 인증 체계 31개 endpoint 마이그레이션, ErrorCode 표준화.
기반이 깨끗해지니 새 기능을 얹어도 기존 코드가 부서지지 않는다. “오늘 백엔드, 내일 프론트”로 나누던 것도, 이제는 서버 + 프론트엔드 + 문서를 한 단위로 끝낸다. 하루 안에서 Feature들이 자연스럽게 연결되니 워밍업 시간도 거의 없다.
숫자로 보면
10~11월:
- 일평균 48.5커밋
- post-commit hotfix 일 2~3건
- 새벽 4시까지 작업 빈번
- 주 2~6일 불규칙
3월:
- 일평균 21.6커밋
- post-commit hotfix 일 0.3건
- 심야 작업 없음
- 주 5일 안정
커밋은 55% 줄었지만, Feature 산출은 늘었다.
10~11월 데이터에는 Feature 추적이 없어서 일부 비교는 추정이다. 정확한 동일 조건 비교는 아니라는 점은 감안해야 한다.
배운 것
커밋이 많다는 건 “많이 고쳤다”는 뜻일 수도 있다.
내 6개월 데이터에서 보이는 패턴은 이거다:
10~11월의 대량 커밋은 “노력의 시기”였고, 3월의 적은 커밋은 그 노력 위에 시스템이 얹어진 결과다.
차이를 만든 건 크게 두 가지였다. 반복 비용을 줄여주는 시스템, 그리고 10~11월에 부딪힌 모든 문제가 만들어준 경험. 둘 다 시간이 필요했다. 10~11월의 삽질 없이 3월의 효율은 없었을 거다.
커밋 수는 활동을 측정한다.
하지만 진짜 중요한 지표는 한 커밋당 얼마나 많은 가치를 전달하고 있는가일 것이다.
그 숫자가 시간이 갈수록 커지고 있다면, 아마 엔지니어로서 성장하고 있는 거다.
Comments