오래된 프로젝트의 코드베이스를 분석할 때, 왜 특정 코드가 그렇게 작성되었는지 알 수 없어 어려움을 겪는 경우가 많습니다. 이는 마치 '체스터턴의 울타리(Chesterton's fence)' 비유처럼, 이유를 모르는 코드를 함부로 건드리지 못하게 하는 상황을 만듭니다. 하지만 더 큰 문제는 그 이유를 전혀 알 수 없도록 기록조차 남기지 않는 행위, 즉 '체스터턴의 가운데손가락(Chesterton's middle finger)'이 후임 개발자에게 막대한 부담을 전가한다는 점입니다.
실제로 한 저장소의 지난 13년간 커밋 본문은 명령어 기준 295줄에 불과했으며, 'dependabot', 'revert', 'typo' 관련 내용을 제외하면 167줄로 줄어듭니다. 이는 한 달에 한 줄 정도의 기록만 남은 셈입니다. 'fix page A'와 같은 모호한 커밋 제목, 부족한 코드 주석, 별도 문서의 부재는 코드 변경의 배경과 의도를 파악하기 어렵게 만듭니다. 이로 인해 끝나지 않은 리팩터링, 제거된 기능의 잔재, 사용되지 않는 코드 등이 방치되어 코드베이스의 복잡성을 가중시키고, 결국 새로운 개발자가 시스템을 이해하는 데 엄청난 시간과 노력을 들이게 됩니다.
이러한 문제는 단순히 개발자의 게으름을 넘어, 소프트웨어 개발의 본질적인 부분인 '지식 공유'와 '협업' 실패를 의미합니다. 커밋 메시지나 문서화는 최소한 '무엇을 바꾸는지(What)', '왜 바꾸는지(Why)', 그리고 '왜 이 해결책이 좋은지(How)'에 대한 답을 담아야 합니다. 이는 미래의 동료 개발자뿐만 아니라, 몇 년 뒤 같은 코드를 다시 보게 될 '미래의 나 자신'을 위한 투자이기도 합니다. 명확한 기록은 의사결정 과정을 추적 가능하게 하고, 불필요한 시행착오를 줄여 개발 생산성을 높이며, 궁극적으로는 소프트웨어의 장기적인 유지보수성과 안정성에 기여합니다.