[비정기 태블릿 챕터] Gitmoji, 빠르고 명확한 소통의 시발점

일정을 지키기 위해 정신없이 달린 경험이 있으신가요?
일정 압박이 없더라도 개발자가 자발적으로 일정을 지키려는 경우까지 고려한다면, 라이브 서비스를 하고 있는 개발팀이라면 어디든 있다고 봐도 될 것 같습니다.

빡세게 달려서 일정을 맞추고 나면 해냈다 라는 뿌듯함과 기쁨도 있지만, 그 반대편에는 현실적인 이유로 포기한 코드 퀄리티와 기술 부채, 그리고 내가 짠 코드를 리뷰해줄 동료들의 고통스러운 시간이 남습니다.

이런 비극적인 상황을 방지하기 위해 지난 글에선 원활한 PR 리뷰를 위한 300/500 규칙을 소개드렸습니다.
이번 글에선 더 깊이 들어가서, 빠르고 잘하는 개발조직이 되기 위해 더 나은 커밋 메세지를 쓰는 방법인 깃모지(Gitmoji) 대해 얘기해보려고 합니다.

항상 따라야 하는 규칙은 없다

이전 글에서 300/500 규칙을 말씀드렸지만 다음과 같은 경우에는 규칙을 따르지 않기도 합니다.

1. 복잡한 레이아웃을 만들기 위한 UI 코드 작업: 이런 경우엔 UI를 만드는 방식에 대해선 논의를 할 수 있지만, 500줄이 넘더라도 여러 개의 PR로 쪼개기 애매한 경우가 많기 때문에 규칙을 적용하지 않는 경우도 많습니다.
2. 단순 코드 이동: 리팩토링이나 모듈 추출 등의 이유로 많은 코드가 대이동을 하는 경우가 있는데요, 이런 경우에도 굳이 자세히 리뷰하지 않습니다.
3. 이미 구두로 얘기한 내용 또한 따로 자세히 리뷰하진 않습니다.

이렇게 PR에도 예외 케이스가 많이 생기는데요, 해당 PR이 레이아웃만 담고 있다, 단순 코드 이동이다, 이미 구두로 얘기한 내용이다와 같은 정보는 어떻게 알 수 있을까요?

저희는 그러한 정보를 커밋으로 표현하는 편이고, 특히 깃모지(Gitmoji)라는 것을 적극 활용하고 있습니다!

위에서 설명드린 예외 케이스 외에도, 복잡한 PR의 경우에도 잘 쓴 커밋 메세지만 있다면 이해하는 것도 어렵지 않습니다.

Gitmoji?

깃모지(Gitmoji)는 git + emoji를 합친 단어로, 모든 커밋 메세지 앞에 이모지를 붙이는 행위입니다.

깃모지를 사용하면 커밋의 목적이나 의도를 아주 쉽고 명확하게 알 수 있어서 코드 리뷰를 포함한 커밋을 봐야 하는 모든 경우에 도움이 됩니다.

슬링 태블릿 챕터에선 스쿼시 머지를 선호하는 편이기 때문에 머지를 하고 나면 커밋은 사라지는데요, 그래서 커밋은 “내가 무슨 일을 했는지 동료에게 보여줄 수 있는 방식”이라고 생각하고, 빠르고 명확한 소통을 위한 핵심이며 깃모지는 더 좋은 커밋을 만들기 위한 Syntatic Sugar라고 생각합니다.

깃모지의 특징

장점

1. 브랜치에서 무슨 작업을 했는지 시각적으로 확인 가능합니다.

위 이미지는 실제로 이번 주에 나간 버전인 오르조 아이패드 3.29.0의 커밋 로그인데요, 이모지만 봐도 3.29.0(1) 버전을 올린 뒤(🔖) 피드백을 받고 버그 픽스(🐛) 및 레이아웃 수정(💄)을 하고, 다시 3.29.0(2) 버전을 올렸다는 것(🔖)을 굳이 뒤에 글을 읽지 않아도 이해할 수 있습니다.

2. 더 빠른 PR 리뷰가 가능합니다.

잘 쓴 커밋 10개에 걸쳐서 300줄이 바뀌는 PR과 200줄 짜리 대충 쓴 커밋 한 번에 바뀌는 PR이 있다면 어느 쪽의 리뷰를 하고 싶으신가요? 저는 당연히 전자라고 생각합니다.

이건 태블릿 챕터에서 실제로 작성한 PR인데요, 깃모지로 작성 후 이렇게 커밋별로 설명이 들어간다면 리뷰하는 입장에서 명확하게 이해하고 빠른 리뷰가 가능합니다.

3. 일정 산정 능력을 키울 수 있습니다.

저는 만들어야 하는 기능에 대한 에픽을 받으면 이슈를 쪼개는 것부터 시작하는데요, 그 과정에서 아래처럼 필요한 일을 커밋 단위로 쪼개서 생각합니다.

커밋 단위로 생각할 수 있게 된다면 기능 완성을 위해 어떤 작업이 필요한지, 어떤 종류 위주로 진행되는지 그리고 작업별 선후관계까지 예상이 가능해지기 때문에 일정 산정 능력에 도움이 많이 됩니다.

4. 개발에만 집중할 수 있는 시간이 늘어납니다.

3번과 이어지는 이야기인데요, 일정 산정이나 무슨 일을 해야하는지 갈피를 못 잡고 어영부영할 시간에 정리하고 개발 시작할 수 있으니 결론적으로 개발에만 집중할 수 있는 시간이 늘어납니다.

이건 제 매니저로서의 모토가 “개발에만 집중할 수 있는 환경 만들기”라서 더 장점이라고 느껴지는 것 같기도 하네요.

단점

깃모지가 장점만 있었다면 전세계 사람들이 썼을텐데 아쉽게도 단점이 있습니다. 간단히 살펴보시죠.

깃모지의 가장 큰 단점이라고 한다면 역시 “익숙하지 않으면 쓰기가 어렵다”입니다. 깃모지는 각 이모지별로 약속된 용도가 있기 때문에 익숙하지 않다면 쓰기가 어렵습니다.

자주🎨 쓰는✨ 이모지라면🔥 당연히🐛 외우겠지만🔖, 저는 그게 쉽지 않아서 항상 깃모지 사이트를 고정탭으로 띄워놓고 쓰고 있습니다.

그 외에도 Rocket이나 gitmoji-cli를 사용하면 각자 git을 사용하는 환경에서도 편하게 사용하실 수 있으니 커버 가능한 단점이라고 할 수 있겠습니다.

깃모지의 다른 용도

예전에 다녔던 회사에선 명확한 커뮤니케이션을 위해 이모지로 코드 리뷰의 종류를 표현하기도 했었습니다.

느낌표 이모지(❗️)는 변경이 필요함, 물음표 이모지(❓)는 질문, 셔츠 이모지(👕)는 코드 스타일에 관한 리뷰였었네요.

그래서 모두가 써야 하나요?

저는 저렇게까지 쓰고나니 더는 이모지 없이 커밋하기 어려운 상태가 되었지만, 깃모지가 모두에게 정답은 아니라고 생각합니다.

그렇기 때문에 슬링 태블릿 챕터에서도 필수나 강요 사항이 아닙니다.

물론, “좋은 커밋 메세지”와 “이해하기 쉬운 PR 설명”을 써야 하는 것은 변하지 않는 사항입니다.

그렇지만 이전 글인 300/500 규칙의 이유와 맥락에 대해 공감하셨다면 깃모지의 필요성도 충분히 이해하셨을거라 생각합니다.

더 빠르고 잘하는 팀을 위해 깃모지 한 스푼 어떠신가요? ⚡️
저희와 함께하는 선택을 해주셔도 좋습니다 🚚
오늘도 읽어주셔서 감사합니다. 🚀