솔직히 말해서, 오늘 아침 해커뉴스(Hacker News)에서 이 도구를 발견하고는 커피를 뿜을 뻔했습니다. 삼성전자 시절부터 온갖 기상천외한 사이드 프로젝트를 봐왔지만, 이건 정말 다른 차원의 '광기'입니다. 이름부터 범상치 않은 git-prime. 말 그대로 Git 커밋의 SHA-1 해시값이 '소수(Prime Number)'가 될 때까지 커밋 메시지를 변조하는 도구입니다. 비즈니스 로직과는 하등 상관없는, 오로지 수학적 심미성만을 위한 이 잉여로운 도구를 보며 저는 폭소를 터뜨렸다가, 이내 등골이 서늘해졌습니다. 만약 우리 팀 주니어가 이걸 프로덕션 배포 파이프라인에 태운다면? 생각만 해도 아찔합니다.
이 도구의 작동 방식은 개발자 특유의 집요함을 적나라하게 보여줍니다. 우리가 흔히 쓰는 git commit 명령어 뒤에 이 도구를 붙이면, 멀쩡한 커밋 메시지 뒤에 의미 없는 'nonce' 값을 붙여가며 해시를 다시 계산합니다. 160비트 정수로 변환했을 때 소수가 나올 때까지 말이죠. 밀러-라빈(Miller-Rabin) 소수성 검사까지 동원해서 평균 30초에서 120초가 걸린다고 합니다. 바쁜 배포 날, 오타 하나 수정하고 커밋하는데 2분을 기다려야 한다니요. 효율성을 최우선으로 여기는 제 입장에서는 "도대체 왜?"라는 말이 절로 나옵니다. 심지어 제작자는 이걸 "수학적으로는 무의미하지만 미학적으로 만족스러운 목표를 위한 분산 컴퓨팅"이라고 포장합니다.
하지만 한편으로는 짠한 마음이 듭니다. 저도 한때는 리소스 최적화에 미쳐 있던 엔지니어였으니까요. 예전에 SK텔레콤에서 AI 플랫폼을 구축할 때, 성능에 0.1%도 영향을 주지 않는 로그 포맷을 맞추겠다고 밤을 새우던 후배가 있었습니다. 그때는 "야, 그거 할 시간에 API 문서나 다듬어"라고 핀잔을 줬지만, 사실 그 마음을 모르는 건 아닙니다. 매일같이 쏟아지는 기획 변경, 위에서 내려오는 무리한 일정, 스파게티처럼 꼬인 레거시 코드 속에서 개발자가 통제할 수 있는 건 오직 자신의 '커밋' 뿐이라는 걸 뼈저리게 느끼기 때문입니다. git-prime은 어쩌면 그런 혼돈 속에서 질서를 찾고 싶은 개발자들의 처절한 비명일지도 모릅니다.
물론, 현실은 냉혹합니다. 만약 여러분이 스타트업의 CTO거나 팀 리더라면, 팀원이 이런 도구에 관심을 갖는 순간을 경계해야 합니다. 이는 단순히 장난감에 대한 호기심이 아닙니다. 프로젝트가 지나치게 지루하거나, 반대로 감당할 수 없을 만큼 망가져서 현실 도피를 하고 있다는 신호일 수 있습니다. 커밋 메시지 규칙(Convention)을 정하는 회의가 지겨워서 차라리 소수나 찾겠다는 그들의 농담은 꽤나 뼈아픈 현실 풍자입니다. 비즈니스의 가치를 창출해야 하는 업무 시간에 CPU 사이클을 태워가며 소수를 찾는 행위는, 회사의 전기세와 개발자의 시간을 동시에 하수구에 버리는 짓이니까요.
아이러니한 것은 우리가 사는 지금이 AI의 시대라는 점입니다. Cursor나 GitHub Copilot 같은 도구들이 코드를 1초 만에 쏟아내는 세상에서, 인간은 고작 커밋 해시를 예쁘게 만들기 위해 2분을 허비하고 있습니다. AI는 절대 이런 비효율적인 짓을 제안하지 않습니다. 오직 인간만이 이런 '낭만적인 낭비'를 할 수 있죠. 저는 여기서 묘한 안도감을 느낍니다. 모든 것이 최적화되고 자동화되는 세상에서, 여전히 쓸데없는 것에 집착하는 인간의 비합리성이야말로 우리가 기계로 대체되지 않을 마지막 보루일지도 모른다는 생각 때문입니다.
형으로서 조언 하나 하겠습니다. 이 도구를 회사 리포지토리에 적용하지는 마십시오. PR 리뷰 시간에 제가 커밋 해시가 소수인지 검증하고 있는 꼴을 보고 싶지 않다면 말이죠. 하지만 주말에 혼자 토이 프로젝트를 할 때는 한 번쯤 써보셔도 좋습니다. 우리가 코딩을 처음 시작했을 때 느꼈던 그 순수한 즐거움, 화면에 찍히는 텍스트 한 줄에 희열을 느꼈던 그 초심을 되찾는 데는 꽤 괜찮은 장난감이 될 겁니다. 물론, 월요일 출근해서는 다시 냉철한 프로로 돌아와야겠지만요. 우리가 싸워야 할 대상은 소수가 아니라 버그와 마감일이니까요.
