커밋 메시지를 생성 AI에 맡겼다가 실제로 하지 않은 변경까지 적힌 초안을 받았다. 이후 diff에서 무엇을 왜 바꿨는지는 내가 정리하고, AI는 문장만 다듬게 했다. 그 과정에서 커밋 기록의 신뢰를 지키려면 무엇을 직접 확인해야 하는지 배웠다.
그럴듯한 AI 초안에 없던 변경까지 들어갔다
처음에는 AI한테 "커밋 메시지 줘"만 던지면 될 줄 알았다. 문장도 그럴듯하고 형식도 깔끔해 보였다.
그런데 막상 보면 핵심 변경보다 파일 나열에 가깝거나, 안 한 일까지 넣어 놓은 경우가 있었다. 그대로 쓰면 커밋 히스토리가 이상해진다. 그럴듯한 문장이 사실 확인을 가리고 있었다.
diff를 먼저 정리하고 표현만 맡겼다
그래서 diff(변경 내역)를 내가 먼저 짧게 정리했다. "무엇을 왜 바꿨는지"는 내가 고정하고, AI에는 표현만 다듬게 했다. 변경 내용까지 AI가 추측하지 않도록 역할을 나눈 것이다.
이렇게 하니까 체감상 커밋 메시지를 다듬는 속도가 빨라졌다. 다만 실제 작성 시간이나 품질 개선 정도를 따로 측정하지는 않았다. 다음에는 작성 시간을 비교해 볼 생각이다.
특히 긴 리팩터링 설명은 내 경험상 사람이 직접 정리하는 편이 나았다. AI는 내용을 대신 결정하기보다 글쓰기 보조로 활용하는 게 더 쓸 만했다.
추측 금지 프롬프트만으로는 부족했다
프롬프트에는 추측하지 말 것, diff에 없는 파일이나 기능을 쓰지 말 것을 명시했다. 그래도 가끔 "완전히", "전면" 같은 과장된 표현이 나왔다.
이런 표현은 실제 변경 범위를 부풀릴 수 있었다. 그래서 AI가 작성한 내용을 실제 diff와 대조하면서 사실과 다른 설명을 걸러내고, 과장된 동사도 직접 고쳤다.
프롬프트를 구체적으로 작성하는 것만으로는 충분하지 않았다. 최종 문장이 실제 변경 내용과 일치하는지는 내가 다시 확인해야 했다.
squash merge 전 최종 메시지를 다시 확인했다
스쿼시 머지(squash merge)로 커밋을 합칠 때는 최종 메시지를 다시 살폈다. 머지 전 실제 diff와 메시지를 대조하면서 빠진 내용이나 하지 않은 작업이 적혀 있지 않은지 확인했다.
이때도 문장을 보기 좋게 만드는 것보다 실제 변경 사항을 정확히 설명하는 것을 우선했다. 커밋 메시지는 나중에 변경 이유를 확인할 때 참고하는 기록이기 때문이다.
자동화보다 역할 분담을 배웠다
팀에 공유하는 커밋 메시지에 AI를 사용했다고 따로 표시하지는 않았다. 다만 팀이나 회사에 AI 사용 공개 정책이 있다면 그 정책을 따른다. 결국 최종 내용에 대한 책임은 커밋 작성자인 내게 있었다.
이번에 정한 원칙은 단순했다.
- 변경한 내용과 이유는 내가 먼저 정리했다.
- AI가 만든 문장은 실제 diff와 대조하고 과장된 표현을 고쳤다.
- squash merge 전 최종 커밋 메시지를 다시 확인했다.
이날은 자동화보다 역할 분담을 정한 날에 가까웠다. 내 경험에서 생성 AI는 초안과 표현 정리에 유용했지만, 사실 확인은 여전히 내 몫이었다.