AI가 쓴 코드, 커밋 설명은 내가 직접 써야 하는 이유
Commit Description as a Thinking Tool
AI가 코드와 커밋 메시지를 대신 작성하는 시대에, 저자는 커밋 설명을 직접 쓰는 습관을 고수한다. AI는 코드에 드러나지 않은 '왜'를 알지 못해 그럴듯한 이유를 지어내기 쉽고, 그 설명을 나중에 읽으면 실제 의도와 맞지 않아 위험하다. 직접 쓰는 과정에서 AI가 만든 변경을 되돌아보고, 이해하지 못한 채 배포하는 일을 막을 수 있다. 커밋 설명은 단순 기록이 아니라 사고 도구다.
에이전트는 코드와 설명을 작성할 수 있다. 하지만 '왜'를 쓰는 일은 네가 배포하는 것을 이해하고 있는지 스스로 확인하는 과정이다.
HN 토론
61- WD-42
글을 쓰는 것은 커밋 메시지에만 국한되지 않고 모든 상황에서 사고하는 행위다. 사람들이 이 사실을 잊고 있거나, 더 나쁘게는 애초에 이해하지 못했던 게 아닌가 걱정된다.
- dkarl
나는 AI 훨씬 전부터 커밋 메시지를 포기할 수밖에 없었다. 다른 사람들이 커밋 메시지를 너무 못 써서 모든 PR에서 커밋을 squash하는 데 흔쾌히 동의했기 때문이다.
적어도 그때는 squash된 메시지가 대체로 괜찮았다. 그런데 사람들이 AI를 사용하기 시작하면서(혹은 AI가 사람을 사용하기 시작하면서) git blame에서 훑어보기도 불가능하고 인간이 소비하기에는 전반적으로 매우 나쁜, 엄청나게 방대한 커밋 메시지를 만들어내기 시작했다.
AI는 거의 모든 다른 면에서 엄청난 발전을 이뤘다. 그런데 왜 계속 낭비적이고 인간에게 적대적인 방식으로 글을 쓰는 걸까?
이게 의도적이라고 의심하지 않는다면 우리는 굉장히 순진한 것이다. AI 기업들은 소프트웨어 개발 과정에서 인간을 대체하겠다는 목표를 공개적으로 밝혔고, 그 과정 자체를 인간에게 불모지로 만들고 있다.
그들은 고객의 개발 과정에 엄청난 양의 텍스트를 주입하고, 그 텍스트는 고객이 다시 반복해서 처리하는 데 돈을 내야 하는 토큰이 된다. 마치 CO2를 배출하는 CO2 흡수기 같다.
- kccqzy
오래전에 나는 커밋 메시지 기본 형식에 "Why?"와 "How?"라는 헤더를 넣도록 바꿨다. 변경이 왜 이루어졌는지(이 글에서 초점을 맞추는 부분), 그리고 어떻게 이루어졌는지(고려한 다른 구현 방식)를 설명해야 한다는 걸 스스로 상기시키기 위해서다. 나는 이 형식을 오랫동안 따랐다. 회사에서 커밋 메시지 길이 기준 상위 1%에 들 정도였다.
곁다리로: 커밋 메시지가 너무 길어지면 뭔가 깨질까 걱정한 적이 있었다. 아주 긴 커밋 메시지를 시도해봤지만 아무것도 깨지지 않았다: https://github.com/kccqzy/long-commit-messages/commit/ccfda4...
- arialdomartini
게다가, 코드보다 커밋 메시지를 먼저 쓰면 이득이 있다
https://arialdomartini.github.io/pre-emptive-commit-comments
- evnp
> AI가 '왜' 부분을 모를 때는 스스로 추론을 만들어낸다. 나는 그것이 위험하다고 본다. 나중에 그걸 읽으면 말이 안 될 수 있다. 실제 이유는 완전히 달랐을 테니까.
더 위험한 경우: 그 텍스트가 현실과 동떨어져 있음에도 불구하고 _말이 될 때_.