솔직히 고백하자면, 저는 화려한 GUI 기반의 Git 클라이언트를 믿지 않습니다. 소스코드 관리 도구(SourceTree, GitKraken 등)가 예쁘장한 UI 뒤에서 제멋대로 `merge` 옵션을 섞어버리거나, 엉뚱한 브랜치에 `rebase`를 걸어버려 팀 전체의 커밋 히스토리를 꼬아놓는 꼴을 너무 많이 봤기 때문입니다. 그래서 저는 10년째 터미널 창을 벗어나지 않고 Git 명령어를 직접 타이핑하는 것을 고집해왔습니다. 그게 가장 확실하고 안전하니까요. 하지만 여기에도 치명적인 단점이 하나 있습니다. 바로 `git log --graph` 명령어가 뱉어내는, 마치 취객이 그린 지하철 노선도 같은 아스키(ASCII) 아트입니다.
장애 상황을 가정해 봅시다. 운영 서버에서 `NPE(Null Pointer Exception)`가 터졌고, 급하게 롤백 지점을 찾아야 합니다. 터미널에 `git log --graph --all --oneline`을 쳤는데, 수십 명의 개발자가 동시에 머지해대는 통에 터미널 화면은 형형색색의 국수 가닥으로 뒤덮입니다. 어디가 `main` 브랜치인지, 지금 배포된 코드가 어떤 커밋에서 파생된 건지 눈으로 따라가다가 놓치기 일쑤입니다. 이런 상황에서 '텍스트 기반'을 고집하는 건 뚝심이 아니라 아집이 되어버립니다. 시인성은 생존과 직결됩니다. 그래서 오늘은 터미널 환경을 떠나지 않으면서도, 이 지옥 같은 커밋 그래프를 명쾌하게 시각화해 주는 도구 하나를 소개하려 합니다. 바로 Rust로 작성된 TUI(Terminal User Interface) 도구, 'Keifu'입니다.
Keifu는 제가 도구에 바라는 철학을 정확히 관통합니다. "가벼울 것, 빠를 것, 그리고 본질에 집중할 것." 이 도구는 거창한 Git 클라이언트가 아닙니다. `add`, `commit`, `push` 같은 건 그냥 CLI로 하세요. Keifu는 오직 '탐색(Navigation)'과 '흐름 파악'에 목숨을 건 도구입니다. 기존 `git log`가 텍스트 문자로 억지로 선을 그렸다면, Keifu는 유니코드(Unicode) 박스 드로잉 문자를 사용해 커밋 간의 연결 관계를 매우 매끄럽고 직관적으로 보여줍니다. 색상 구분도 명확해서, 수십 개의 브랜치가 얽혀 있어도 지금 내가 보고 있는 커밋이 어느 줄기에서 나왔는지 0.1초 만에 파악할 수 있습니다.
특히 인상적인 건 '속도'와 '단순함'입니다. 요즘 개발 환경은 MSA(Microservices Architecture)다 뭐다 해서 리포지토리도 많고 브랜치 전환도 잦습니다. Keifu는 Rust 기반이라 실행 속도가 즉각적입니다. `j/k` 키로 커밋 사이를 오가고, `h/l` 키로 브랜치 부모/자식을 추적합니다. 마우스를 잡으려고 키보드에서 손을 떼는 낭비조차 허용하지 않습니다. 복잡한 설정도 필요 없습니다. 그냥 바이너리 하나 설치하면 끝입니다. 좁은 터미널 창이나 `tmux`로 분할된 화면에서도 레이아웃이 깨지지 않고 정보를 우겨넣어 보여줍니다. 이는 서버에서 직접 문제 상황을 디버깅해야 할 때 빛을 발합니다.
물론 만능은 아닙니다. 한번에 500개 커밋까지만 로드한다거나, 복잡한 리베이스 작업은 지원하지 않는 등의 제약이 있습니다. 하지만 저는 이게 단점이 아니라 '안전장치'라고 봅니다. 도구가 너무 많은 기능을 가지면 사용자는 실수를 하게 됩니다. 복잡한 조작은 신중하게 명령어로 치고, Keifu로는 "지금 우리 코드가 어디로 가고 있는가"를 확인하는 용도로만 쓰는 겁니다. 스테이징된 변경 사항이 있는지, 지금 내가 `checkout` 하려는 브랜치가 원격과 얼마나 벌어져 있는지 시각적으로 확인하고 이동(`Enter`)하는 것만으로도, 배포 실수라는 끔끔한 사고를 절반은 예방할 수 있습니다.
주니어 개발자 여러분, 화려한 IDE 플러그인에 의존하지 마십시오. 하지만 그렇다고 80년대 스타일의 텍스트 뭉치와 씨름하며 눈을 혹사시킬 필요도 없습니다. 도구는 여러분의 시간을 아껴주고, 실수를 줄여주는 '자산'이어야 합니다. 관리하기 힘든 도구는 그 자체로 '부채'입니다. 오늘 당장 터미널에 Keifu를 설치(`cargo install keifu` 혹은 `mise` 사용)해 보세요. 그리고 팀장이 "지난주에 병합된 그 기능, 어느 커밋인지 찾아봐"라고 할 때, 당황하지 말고 3초 만에 찾아서 보여주십시오. 그게 바로 '일 잘하는 개발자'의 생존 방식입니다.
