나만의 GitHub를 만든다면? 커밋 전 피드백의 중요성

만약 나만의 GitHub를 만든다면 어떤 기능을 넣을까? 이 질문은 개발자라면 한 번쯤 해봤을 법한데, GeekNews에 올라온 글에서 꽤 흥미로운 아이디어가 나왔다. 핵심은 우리가 GitHub나 GitLab 같은 현대 코드 포지(forge)에서 쓰는 기능들이 사실 git 자체보다 PR(Pull Request), Actions, Issues, Releases 같은 부가 기능들 위주로 돌아간다는 통찰이다. 그리고 여기에서 한 발 더 나아가, 코드 리뷰의 타이밍을 훨씬 앞당길 수 있다는 제안을 한다.

커밋 이후가 아닌 푸시 전 피드백

기존 GitHub 모델은 코드를 커밋하고 푸시한 다음, PR을 열어 다른 사람이 리뷰하는 방식이다. 하지만 이 글의 저자는 이 과정에서 비효율이 발생한다고 지적한다. 이미 코드가 저장소에 올라간 뒤에야 피드백을 받고 수정하는 과정이 반복된다는 것이다.

그 대신, 새로운 코드 포지는 **푸시 전에 강제로 피드백을 주는 ‘pre-commit hook’**을 도입해야 한다고 주장한다. 즉, 개발자가 코드를 커밋하고 푸시하기 전에, 잠재적인 문제나 스타일 가이드 위반 등을 자동으로 검사하고 피드백을 줘서 개발자가 즉시 수정하도록 유도하는 방식이다. 이건 마치 요리사가 음식을 손님에게 내기 전에 미리 맛을 보고 간을 맞추는 것과 비슷하다. 문제가 있는 음식을 내고 나서 피드백을 받아 다시 만드는 것보다 훨씬 효율적이지 않겠는가.

CI/CD의 시작점을 개발자 워크스테이션으로

이 아이디어의 진짜 의미는 CI/CD(지속적 통합/지속적 배포) 파이프라인의 시작점을 개발자 워크스테이션으로 앞당기는 데 있다. 보통 CI는 코드가 중앙 저장소에 푸시된 후에 실행되지만, pre-commit hook은 개발자의 로컬 환경에서 코드가 커밋되기 전, 또는 푸시되기 전에 이미 기본적인 검사를 수행한다.

이렇게 되면, 잘못된 코드가 저장소에 올라가는 것을 원천적으로 방지하고, 코드 리뷰어는 더 깔끔하고 완성도 높은 코드를 받게 된다. 이는 전반적인 개발 생산성을 높이고, 불필요한 커뮤니케이션 비용을 줄이는 데 크게 기여할 수 있다. 물론 모든 검사를 pre-commit hook으로 옮기는 것은 무리겠지만, 중요한 기본적인 검사들을 미리 처리함으로써 개발 워크플로우를 훨씬 더 매끄럽게 만들 수 있다는 점이 매력적이다. 결국, ‘나만의 GitHub’는 개발자 개개인의 생산성 향상에 초점을 맞춘, 더 능동적인 코드 관리 시스템이 될 것이라는 이야기다.