[생각] 커밋 단위 및 주기에 관한 고민

Intro

최근 우테코 6기의 프리코스를 진행하게 되면서, 본격적인 개발 전에 먼저 구현할 기능 목록을 작성해보고, 작성한 기능 단위로 커밋하는 것을 연습해보고 있다. 그런데 이렇게 하다보니 커밋 단위나, 주기에 관해서 약간의 고민이 생겨서 우테코 디스코드 채널에서 다른 사람들의 의견을 들어보았다.

고민

예를 들어 사용자로부터 입력값을 입력받기라는 기능이 있다면, 입력 시스템을 통해 입력받기, 입력받은 값을 검증하기, 입력받은 값을 변수에 저장하기 등 많은 세부기능들이 존재한다.

1. 여기서 첫 번째로 생기는 고민은 이 메소드들을 어느 시점에 커밋해야 하는지에 대한 것이다. 좀 사이즈가 큰 기능을 만들다 보면 그에 대한 하위, 보조 메소드들도 많이 생기곤 한다. 이러면 사실 초기 단계에서 거의 완벽하게 설계를 하지 않는 한, 기능 하나를 제대로 완성하기 까지는 코드가 어디까지 늘어날 지가 감이 안 잡히게 된다.

2. 두 번째로 생기는 고민은 어느 정도의 단위로 커밋을 해야 하는지에 대한 것이다. 복잡한 로직을 짜다 보면 처음에는 옳다고 생각했던 코드들이 계속해서 바뀌게 되고, 때로는 잘못된 결과를 반환하는 메소드들이 그대로 커밋으로 올라가곤 한다. 이렇게 되면, 내 머릿속에서는 에러 없이 완벽한 코드를 짜고 커밋을 할 지, 아니면 그냥 만들고 곧바로 해야할 지에 대한 고민이 생긴다.

전부터 Git을 자주 사용하긴 했었지만, 그건 사실 팀원들끼리 어느 정도 변경사항을 알아보려는 용도였지 이런 식의 체계적인 방식이 아니었기 때문에 우테코를 계기로 처음으로 깊은 고민을 해보게 되었다.

나의 생각

일단 1번, 커밋 주기에 대해서는 일단은 정석적으로 짧게 가져가는 방식이 옳다고 생각하고 있었다. 기능을 설계할 때는 최대한 나눌 수 있는 만큼 나누고, 이에 따라 커밋도 할 수 있는 한 작은 단위로 쪼개야 한다는 말을 어디선가 들었어서, 무의식 속에서 이렇게 생각하고 있었던 것 같다.

그리고 2번, 커밋 단위에 대해서는 사실 메소드 하나하나를 곧바로 커밋하는 게 아닌, 어느 정도의 기능이 완성되고 나서 커밋하는 것이 낫다고 생각했다. 일단은 내가 생각하기에 불완전한 코드가 깃허브 상에 올라가는 것이 꺼림칙하기도 했고, 일단 푸시를 해버리면 원격 저장소의 기록을 수정하는 것이 상당히 귀찮기 때문에 최소한의 완성을 하고 올려야겠다고 생각했다.

커뮤니티의 의견

일단 커뮤니티 다른 사람들이 남겨준 의견들은 대체적으로 비슷했는데, 최대한 잘게 쪼갠 커밋을 최대한 자주 올려야 한다는 의견이 주류를 이루었다.

1. 일단 내가 처음으로 걱정했던 "코드의 사이즈가 어디까지 늘어날 지 알 수 없다."라는 생각은, 사실 초기 단계에서 설계를 철저하게 해놓는다면 이후에 큰 변경이 거의 없기 때문에 그다지 걱정할 일은 아니었다. 사실 알고리즘 풀 때를 제외하고 거의 초기 설계를 스킵했던 나의 습관이 걱정에 한 몫했다.

2. 이어서 "완벽하지 못한 코드를 커밋하는 것이 망설여진다."라는 생각에도 어떤 분이 전혀 생각치 못했던 답변을 달아주셨다. 사실 완성된 코드라는 기준이 사람마다 다 다르고 굉장히 모호하다는 것이다.

   아무리 기능이 정상적으로 작동하는 코드일지라도 구조적 문제로 나중에 리팩토링될 수도 있는 거고, 추후 에 요구 사항이 변경되는 일이 있다면 그 때도 코드는 바뀐다. 결국 코드라는 것은 어쩔 수 없이 변경될 운명이기 때문에 오히려 커밋을 잘게 쪼개서 그때그때의 수정을 기록하는 편이 낫다는 의견이었다.

3. 마지막으로 "설계의 오류나 잦은 수정으로 불필요한 커밋이 포함된다."라는 걱정 역시 Merge 단계에서 조율할 수 있는 문제였다. Squash Merge 등을 하면 여러 개의 커밋들이 하나로 합쳐지기에, 의미 있는 정보만 남겨놓을 수 있는 좋은 방법인 것 같았다.

이러한 의견들에 힘 입어 결론적으로 나 역시 최대한 작은 단위와 주기로 커밋을 하는 것이 옳다는 생각을 정립하게 되었다.

마무리

본격적으로 현업에 가까운 커밋과 깃 사용을 연습하게 되면서, 어떻게 해야 옳은 커밋일 지에 대해 많은 고민을 해보았던 것 같다.

더 나은 깃의 활용에 대해서도 고민을 해보았는데, 우테코 같은 경우는 "숫자 야구 게임" 등을 전부 만들게 한 후에 수십 개의 커밋을 하나의 PR로 보내도록 하지만, 사실 이렇게 했을 때는 변경사항이 너무 많아서 코드 리뷰 시에도 힘들고 커밋 하나하나가 눈에 잘 보이지 않는 고충이 있었다.

물론 프리코스이고 연습하는 단계니까 그럴 거라 생각은 했지만, 나중에 실제 상황에서는 버전 관리나 협업 등 여러 관점에 대해 생각해보면서 유연하게 활용해보면 좋을 것 같다고 생각헀다. 끗!