아직도 커밋 메시지를 직접 작성하는 이유

LLM이 커밋 메시지를 대신 쓸 수 있어도, 직접 작성하는 과정은 변경의 이유와 맥락을 기록하고 개발자가 내용을 제대로 이해했는지 확인하는 데 가치가 있음 diff에서 대체로 확인할 수 있는 ‘무엇’보다 선행 작업, 버그 사례, 구현 실수, 선택지 사이의 트레이드오프처럼 ‘왜’를 남기는 것이 중요함 변경 이유를 자기 말로 풀어 쓰면 잘못된 선택이나 더 나은 방안을 발견할 수 있으며, Also나 Additionally의 반복은 한 커밋이 너무 많은 일을 하는지 점검하는 신호가 됨 AI 보조 코드를 직접 설명하고 커밋하면 변경에 대한 책임과 소유권을 확보할 수 있고, 원자적 커밋마다 AI가 관여한 영역과 사용 모델을 명시할 수 있음 AI가 최근 커밋 100개를 참고해 비슷한 메시지를 만들도록 해도 고유한 문체까지 재현하지는 못했으며, 중요도가 낮은 프로젝트의 초안으로는 유용하지만 모든 사람에게 직접 작성을 강제할 필요는 없음 ‘무엇’보다 ‘왜’를 기록하기 좋은 커밋 메시지는 diff에서 확인할 수 있는 변경 내용을 되풀이하기보다 변경이 필요했던 이유를 담아야 함 코드가 언제나 스스로 설명되지는 않지만, 일반적으로 ‘무엇이 바뀌었는가’는 커밋 diff에서 파악할 수 있음 ‘왜’를 기록하지 않으면 변경에 이른 중요한 맥락이 사라짐 커밋 메시지에는 다음과 같은 맥락을 남길 수 있음 후속 변경을 위한 선행 작업이나 리팩터링인지 여부 해결하려는 버그의 이슈나 JIRA 티켓뿐 아니라 구체적인 사례와 오류 메시지 자신의 리뷰나 구현 누락으로 문제가 들어왔는지 여부와 관련 커밋 SHA 외부 명령 실행과 TypeScript 파서 구현 같은 선택지 사이의 트레이드오프 Chris Beams의 커밋 메시지 작성 글에서 이런 원칙과 커밋 작성 시 기억할 사항을 살펴볼 수 있음 쓰면서 이해도를 검증하기 커밋 메시지를 작성하는 일은 방금 만든 변경을 실제로 이해하는지 확인하는 자기 검증 과정이 됨 2014년 연구에 따르면 다른 사람에게 가르칠 것으로 예상할 때 지식을 기억할 가능성이 더 높아짐 변경이 필요한 이유를 자기 말로 설명하다 보면 직접 작성한 코드에서도 기존 선택에 동의하기 어렵거나 더 나은 방안을 발견할 수 있음 문서를 쓸 때도 기능 내부를 모르는 사용자의 입장에서 한 걸음 물러나면, 암묵적으로 전제했던 이해를 찾아내 다시 풀어낼 수 있음 메시지에 Also, ... 또는 Additionally, ...가 나타나는지도 살펴봄 항상 ...