많은 팀이 그렇듯 지금 일하는 팀 역시 소스 관리를 위해 Git을 사용한다. 난 커밋 메시지를 중요하게 생각한다. 코드는 쓰는 것보다 읽는 것이 중요하다. 코드 자체에 의도를 담는 것이 최선이지만 코드를 통해 동작을 표현하기는 쉬운 반면 코드의 작성과 변경의 이유는 표현하기 어려운데 커밋 메시지는 좋은 대안이다. GitHub의 Blame이나 Visual Studio의 CodeLens는 코드 읽기를 도와주는 강력한 도구이지만 이 역시 충실히 작성된 커밋 메시지가 뒷받침되어야 한다. 우리 팀은 양질의 커밋 메시지를 작성하려는 노력의 일환으로 ’50/72 규칙’을 사용한다. 그런데 우리는 한글과 관련된 문제를 발견했다.

 

’50/72 규칙’의 가장 중요한 내용만 설명하면 이렇다. 첫 줄에 50자 이내로 커밋 내용을 요약한다. 이것은 매우 유용하다. git log --oneline, git rebase --interactive, Blame, CodeLens 등의 도구를 사용할 때 한 줄의 짧은 요약이나 제목은 거의 필수다. 50자의 유래는 Linux 커널 커밋 메시지 길이의 산술평균 근사치라고 한다.

50자 요약으로 커밋을 설명하기에 부족하면 두번째 줄을 비우고 세번째 줄부터 상세 내용을 적는다. 세번째 줄부터는 한 줄을 72자 이내로 제한한다. 72자는 Git이 커밋 메시지를 보여줄 때 4자 들여쓰기를 하기 때문에 80자 출력을 기준으로 커밋 메시지를 중앙에 위치시키는 것이 목적이다.

사실 난 50과 72에 큰 의미를 두지는 않는다. 단지 Git을 사용하면서 커밋 메시지 줄 길이를 적정 수준에서 제한할 필요를 분명히 느껴왔기 때문에 잘 알려진 규칙을 선택한 것이다. 다른 팀원(프로그래머)들 모두 커밋 메시지 작성 규칙이 필요하다고 말한다. 우리는 Pull Request를 작성할 때에도 제목과 본문에 ’50/72 규칙’을 적용한다. Pull Request가 완료되면 병합 커밋을 만드는 것이 정책이고 이때 Pull Request의 제목과 본문이 그대로 커밋 메시지가 되기 때문이다. 다음은 커밋 메시지의 한 사례다.

UserCommand 추상 기반 클래스를 추가한다

다음 명령 클래스가 UserCommand 클래스를 상속하도록 변경한다.
- CreateUserWithEmail
- ChangeUsername
- ChangeEmail

그런데 커밋 메시지를 작성할 때마다 각 줄의 글자 수를 세는 것은 괴로운 일이다. 현실적으로 불가능하다. 50과 72는 모두 반각 모양(halfwidth form) 기준이라는 것도 중요하다. 한글은 항상 전각 모양(fullwidth form)으로 출력되기 때문에 한글로 커밋 메시지를 작성할 때 ’50/72 규칙’은 글자 수 기준이 아니게 된다. 더 심각한 문제는 한글을 고려해서 만들어진 글꼴이 아닌 경우 한글 문자의 너비가 정확히 반각 모양 너비의 두 배가 사용됨을 보장하지 않는다는 것이다.

halfwidth-vs-fullwidth

왼쪽 상단부터 시계 방향으로 Git Bash, 메모장, Visual Studio Code, Visual Studio에서 한글 문자의 너비를 확인한 그림이다. 모두 글꼴은 Consolas, 9pt로 동일한데 한글 문자 너비는 제각각이다. 오직 Git Bash만 한글 문자 하나에 반각 모양 두 배의 너비를 할애한다.

진심으로 고맙게도 네이버가 만든 D2 Coding 글꼴은 한글을 고려해 만든 고정폭 글꼴이며 누구나 자유롭게 사용할 수 있도록 배포하고 있다. 우리 팀은 이 글꼴이 한글 문자를 반각 모양의 정확히 두 배 너비로 그리는 것을 다양한 환경에서 확인했다. 안타까운 사실이 있다면 우리 중 누구도 이 글꼴을 좋아하지 않는다는 것이다. 보기 싫은 글꼴을 사용해 코딩하는 것은 많은 프로그래머에게 고문과 같다.

다행히 Visual Studio Code는 우리가 가진 모든 문제를 해결한다. 우선 다음 명령을 사용해 Git의 편집기를 Visual Studio Code로 설정한다.

$ git config --global core.editor "code --wait"

이제 -m 인자를 생략하고 git commit 명령을 입력하면 Visual Studio Code 창이 열리고 커밋 메시지를 작성할 수 있다. 커밋 메시지 작성이 완료하고 파일을 저장한 후 탭이나 창을 닫으면 커밋이 완료된다. 이 때 Visual Studio Code는 편집기 언어 모드를 Git Commit Message로 선택한다.

Visual Studio Code는 편집기 언어 모드 별 설정을 제공한다. Git Commit Message 언어에 대해 다음과 같이 설정하면 편집기의 언어 모드가 Git Commit Message일 때만 D2 Coding 글꼴을 사용하고 반각 모양 기준 50자 눈금자와 72자 눈금자를 보여준다. D2 Coding 글꼴을 좋아하지 않는 프로그래머도 커밋 메시지를 작성하는 잠깐 동안은 견딜 수 있을 것이다.

{
    "[git-commit]": {
        "editor.fontFamily": "D2Coding",
        "editor.rulers": [
            50,
            72
        ]
    }
}

다음 그림의 왼쪽 편집기 언어 모드는 Plain Text이고 오른쪽 편집기 언어 모드는 Git Commit Message다. 왼쪽 편집기의 글꼴은 Consolas임에 반해 오른쪽 편집기의 글꼴은 D2 Coding이고 50자 눈금자와 72자 눈금자가 그려진다.

plaintext-vs-gitcommitmessage

이제 한글이 포함된 커밋 메시지를 작성할 때 D2 Coding 글꼴과 눈금자의 도움을 받아 ’50/72 규칙’을 쉽게 지킬 수 있다.

이렇게 우리 팀은 ’50/72 규칙’과 Visual Studio Code를 사용해 Git 커밋 메시지를 관리한다. 한 번 더 얘기하지만 코드는 쓰는 것보다 읽는 것이 중요하다. 커밋 역시 마찬가지다. 좋은 커밋 메시지를 작성하기 위해 들이는 노력은 품질 낮은 메시지를 가진 커밋들을 읽는 수고스러움에 비해면 아주 저렴하다. 커밋 메시지 관리를 위해 반드시 ’50/72 규칙’을 채택할 필요는 없다. 각 팀 실정에 맞는 규칙을 선택해 지켜나가면 된다. 기본적인 규칙들을 기억하고 준수하는 것이 좋은 코드베이스를 확보하는 유일한 방법임을 잊지말자.