I Asked AI to Write My Commit Messages It Was Embarrassing.
I asked AI to write a commit message for me last week The code change was simple. A bug fix One line,...
개요 #
간단한 버그 수정 하나. 한 줄짜리 변경이라 십 초만 고민하면 한 문장으로 설명할 수 있는 그런 작업이었다. 한 개발자가 이 커밋의 메시지를 AI에게 맡겼다. 돌아온 답은 이랬다.
Updated stuff. Fixed things. Improved performance.
네 단어짜리 완벽한 무의미. 기술적으로 틀린 건 아니었다. 다만 영혼이 없었다. 무엇이, 왜 바뀌었는지, 그게 중요한지 아닌지 미래의 독자에게 아무것도 말해주지 않았다. 그는 이 메시지를 끝내 커밋하지 못했고, 일주일간 AI에게 커밋 메시지를 맡긴 실험을 다시는 하지 않기로 했다. 흥미로운 건 그가 내린 결론이다. 문제는 AI가 아니라 자신이었다.
커밋 메시지는 원래 무엇이었나 #
예전엔 커밋 메시지에 시간을 들였다고 그는 말한다. 몇 시간씩은 아니다. 그래도 무엇을 했는지가 아니라 왜 했는지를 설명하는 한 문장 정도. 고민하다 버린 트레이드오프에 대한 짧은 메모, 가끔은 티켓 링크, 가끔은 나중의 내가 봐도 어리둥절할 기묘한 엣지 케이스에 대한 한 줄 설명.
메시지는 코드 자체를 위한 게 아니었다. 코드는 꼼꼼히 읽으면 결국 스스로 말한다. 메시지는 다음 사람을 위한 것이었다. 반년 뒤 디버깅 도중 이 커밋을 발견하고 "대체 왜 이렇게 했지" 하고 의아해할 그 사람. 좋은 커밋 메시지는 미래의 나, 혹은 이 코드를 물려받을 누군가에게 건네는 작고 구체적인 선물이다.
그는 자기가 그 선물 주기를 그만뒀다는 걸 몰랐다고 한다. AI에게 일을 넘기고, 자신이 그동안 얼마나 성의 없었는지를 거울처럼 비추는 결과물을 받아 들기 전까지는.
부끄러움의 전시장 #
AI가 그의 최근 커밋 세 개에 붙인 메시지를 보자. 직접 본 적 없어도 어떤 종류인지 단번에 알아볼 것이다.
1. Fixed stuff. (뭔가 고침) 세 단어. 맥락 제로. 무엇을 고쳤는지, 왜 고쳐야 했는지, 누가 신경이나 써야 하는지 전혀 알 수 없다.
2. Improved performance. (성능 개선) 얼마나? 코드 어디서? 어떤 방식으로? 무엇과 비교해서? 메시지는 그 어떤 것에도 답하지 않으면서, 묘하게 자신만만하다.
3. Bug fixes and other improvements. (버그 수정 및 기타 개선) 영어 역사상 가장 일반적인 문장일지도 모른다. 누가 만든 거의 모든 커밋에 기술적으로 참인 말이니까.
AI는 실제 diff에 접근할 수 있었다. 무엇이 줄 단위로 바뀌었는지 정확히 봤다. 그 모든 정보를 가지고도, 본질적으로 아무것도 전달하지 않기를 택했다.
그를 정말로 찌른 건 이 부분이다. 이 메시지들은 다른 AI에게조차 쓸모가 없다. 반년 뒤 다른 모델이 이 파일의 히스토리를 이해하려고 "fixed stuff"를 읽는다면, 사람이 받는 만큼의 신호 — 즉 아무것도 — 를 받는다.
왜 이게 진짜 문제인가 #
커밋 메시지는 Git 히스토리 위에 얹은 장식이 아니다. 잡일도 아니다.
반년 뒤 이 코드를 발견하고 손대기 전에 왜 그런 결정이 내려졌는지 알아야 하는 동료를 위한 것이다. 변경이 합리적인지 평가하려는 리뷰어를 위한 것이다. 그리고 새벽 두 시에 스택 트레이스를 노려보며 이걸 짤 때 무슨 생각이었는지 떠올리려 애쓰는 바로 당신을 위한 것이다.
좋은 커밋 메시지는 한 가지 질문에 또렷이 답한다. 우리는 왜 이걸 했는가. 나쁜 메시지는 아무것도 답하지 않으면서, 좋은 메시지가 차지했을 만큼의 공간을 똑같이 차지한다.
여기서 불편한 진실이 나온다. AI가 일반적이고 공허한 커밋 메시지를 준 이유는, 그가 AI에게 일을 넘기기 한참 전부터 이미 일반적이고 공허한 메시지를 쓰고 있었기 때문이다. AI는 그의 최근 히스토리에서 그 패턴을 학습했다. 그의 게으름을, 완벽한 충실도와 제로의 판단으로 그대로 되비췄다.
그를 부끄럽게 한 건 AI의 출력물이 아니었다. 자기 자신이었다. AI는 문제가 아니었다. 문제는 그였고, AI는 그걸 그저 눈에 보이게 만들었을 뿐이다.
그래서 얻은 교훈 #
그는 다시 자기 손으로 커밋 메시지를 쓴다.
AI 활용 전반에 반대하는 어떤 규칙이 있어서가 아니다. 다른 일에는 여전히 잘 쓴다. 다만 이 과정 어딘가에서 깨달았다고 한다. 커밋 메시지는 애초에 컴퓨터가 생성하라고 있는 게 아니었다. 사람이 읽으라고 있는 것이고, 주의를 기울이던 사람이 쓴 것처럼 들려야 한다.
AI는 코드를 쓸 수 있다. 리팩터링하고, 제안하고, 생성하고, 자동완성한다. 그런데 적어도 그가 먼저 진심으로 신경 쓰지 않는 한 못 하는 게 하나 있다. 변경이 왜 일어났는지에 대한 이야기를 쓰는 것. 그리고 그 이야기야말로 다음 리뷰어에게, 다음 유지보수자에게, 굳이 시간을 밝히고 싶지 않은 시각에 뭔가를 디버깅하는 미래의 나에게 진짜로 중요한 부분이다.
커밋 한 번에 십오 초. 직접 쓸 만큼만 신경 쓰면 되는 일이었다.
마지막 질문 #
원문 글쓴이는 독자에게 묻는다. 당신이 본 — 혹은 솔직해지자면, 당신이 직접 쓴 — 최악의 커밋 메시지는 무엇인가. 그가 먼저 답한다. "Fixed stuff." 자랑스럽진 않지만, 공유한 것은 후회하지 않는다고.
이 글은 위 출처를 바탕으로 한국 독자를 위해 재작성한 기사입니다. 원문의 사실과 수치에 근거하며, 별도의 견해를 포함하지 않습니다.