2년 걸린 프로젝트가 있다고 해볼게요.
새벽 두 시에 푸시한 날도 있고, 몇 주 동안 저장소가 조용했던 시기도 있고, 벽에 머리 박다가 겨우 뚫은 스프린트도 있었어요.
그래서 그 2년의 결과물이 뭐냐면요.
초록색 네모 몇 개.
git log는 정직합니다. 빠진 것도 없어요. 근데 읽어보면 서사가 없습니다. 물류 송장 같아요. 언제 뭐가 들어왔는지는 나오는데, 무슨 일이 있었는지는 안 나옵니다.
여기에 반응한 개발자가 도구를 하나 만들었습니다.
저장소를 챕터로 나눠서 읽어준다
Commit Canvas라는 오픈소스입니다.
하는 일은 단순해요. 깃 저장소를 읽어서 HTML 파일 한 장을 뱉습니다. 그 안에 챕터, 시간 이동 슬라이더, 프로젝트 지문(fingerprint) 같은 게 들어 있고요.
만든 사람이 파이썬 웹 프레임워크 Flask 저장소에 돌려봤더니 챕터가 여섯 개 나왔대요. 다섯 개는 예상 가능한 것들이었는데, 여섯 번째가 좀 달랐습니다.
"침묵: 31일 동안 아무 일도 없었음."
2024년 11월 28일부터 2025년 1월 1일까지.
여기가 이 도구의 핵심입니다.
변경 이력은 그 구간을 없음으로 처리해요. 기록할 게 없으니까요. 그런데 이야기로 읽으면 그건 없음이 아니라 한 장면입니다. 소설에서 아무 말 없는 페이지가 의미를 갖는 것처럼요.
근데 여기서 반전이 있어요
2026년에 이런 도구가 나왔다고 하면 뭘 떠올리세요?
저는 당연히 LLM을 붙였을 거라고 생각했습니다. 커밋 메시지를 읽혀서 요약시키고, "이 시기 팀은 인증 리팩터링에 집중했습니다" 같은 문장을 뽑아냈겠거니 했죠.
AI가 하나도 안 들어갔습니다.
커밋 메시지 파싱도 안 해요. 모델 호출도 없고요. 파이프라인 전체가 그냥 날짜 산술입니다.
git log 한 번, git for-each-ref 한 번. 이 두 개 돌려서 월별 시계열을 만들고, 나머지는 전부 순수 파이썬 계산이에요. 외부 라이브러리 의존성도 0입니다.
왜 이렇게 만들었을까요.
방어 가능해서입니다.
"왜 내 저장소가 'The Sprint'로 나왔죠?"라고 물으면, 규칙을 열어서 한 화면에 보여줄 수 있어요. 피크가 있던 달이 중앙값의 4배 이상이고 동시에 커밋 15개 이상. 끝입니다.
모델한테 물어서 나온 문장이면 이 질문에 답을 못 하잖아요.
일곱 가지 형태
모든 프로젝트가 일곱 개 중 하나로 분류됩니다.
커밋 5개 미만이거나 60일 안 된 저장소는 Fresh Start. 60일 이상 비었다가 진짜로 돌아온 경우는 The Return. 특정 달이 폭발한 경우는 The Sprint. 후반이 전반보다 1.8배 이상 빨라졌으면 The Climb, 반대면 The Slow Fade. 6개월 이상인데 튀는 구간 없이 꾸준하면 The Marathon. 나머지는 전부 The Journey입니다.
기준이 전부 자기 저장소의 중앙값 대비라는 게 포인트예요. 그래야 큰 프로젝트든 취미 저장소든 같은 잣대가 적용되니까요.
다만 절대 하한선도 같이 걸었습니다. 중앙값이 0.4커밋인 저장소가 갑자기 스프린트를 했다고 나오면 이상하잖아요. 그래서 15커밋 미만이면 아예 후보에서 빠집니다.
21일이라는 숫자
"침묵" 챕터가 붙는 기준이 21일입니다.
만든 사람 설명이 재밌었어요. 3주가 무슨 의미가 있어서가 아니라, 그보다 짧으면 그냥 주말 더하기 감기라서 그렇답니다.
이 숫자를 정하는 데 저장소 다섯 개랑, 본인 프로젝트 시연에서 한 번 민망한 일을 겪고 나서야 자리를 잡았대요.
그리고 자막은 딱 "31일 동안 아무 일도 없었음"에서 멈춥니다. 그 이상 안 나가요.
메인테이너가 번아웃이었다는 말도 안 하고, 프로젝트가 죽어가던 중이라고도 안 합니다. 도구는 그걸 모르니까요. 공백이 있었다는 것까지가 데이터고, 의미는 읽는 사람이 붙이는 겁니다.
저는 이 선 긋기가 이 도구에서 제일 좋았습니다.
만들면서 걸렸다는 것들
여기부터가 실무에 바로 쓸 만한 이야기입니다.
어느 시계가 진짜냐. 처음엔 연속 커밋 기록을 커미터 날짜로 계산했대요. 근데 리베이스를 하거나 며칠 묵혔다 푸시하는 저장소에서는, 화요일에 작성한 작업이 일요일에 커밋된 걸로 찍힙니다.
깃에서 %at는 작업한 시각, %ct는 객체가 기록된 시각입니다. 이 둘은 같지 않아요. 대부분의 도구가 조용히 하나를 고르고 그걸 밝히지 않는다는 지적이 있었는데, 저도 뜨끔했습니다. 커밋 데이터로 뭔가 계산해보신 분이면 한 번 확인해보실 만합니다.
테스트가 거짓말한 사례. 테스트용 커밋을 같은 초에 여러 개 만들어뒀더니, 연속 기록 테스트가 엉뚱한 이유로 통과했다고 해요. 날짜를 흩뜨려놓고 나서야 테스트가 제대로 실패하기 시작했답니다.
여기 붙은 한 줄이 좋았어요. 실패할 수 없는 테스트는 그냥 문서에 단계만 더한 것이라고요.
안 넣은 기능들. 커밋 메시지 감성 분석, 생산성 점수, 번아웃 경고. 다 넣을 수 있었고 눈에도 잘 띄었을 거예요.
근데 전부 뺐답니다. 시연용 저장소 중 최소 하나에서는 틀릴 게 확실했으니까요. 내 히스토리를 재료로 쓰는 도구가 틀리면, 그 순간 신뢰가 끝나거든요.
멋있는데 정직하지 않은 기능을 지우는 게 설계 작업의 절반이었다는 말이 오래 남았습니다.
직접 돌려보기
파이썬 3.8 이상과 git CLI만 있으면 됩니다.
git clone https://github.com/ahmadrrrtx/commit-canvas
cd commit-canvas
./run.sh ~/code/your-project --theme sunset --open
저장소가 크면 옵션을 하나 붙이는 걸 권합니다.
./run.sh ~/code/your-project --max-commits 5000 --open
결과는 HTML 파일 하나, 160KB 정도입니다. 서버로 아무것도 안 보내니까 사내 비공개 저장소에 돌려도 됩니다. 이게 은근히 중요한 조건이에요. 회사 코드 히스토리를 외부 서비스에 올리는 건 보통 안 되니까요.
참고로 README에 적힌 pip install은 아직 준비 중이라고 합니다. 지금은 위 방식이 유일한 경로예요.
마무리 생각
한 줄로 정리하면 이겁니다.
데이터가 보여주는 것 이상을 주장하지 않는다.
요즘 도구 대부분이 반대로 가잖아요. 모델 하나 붙여서 그럴듯한 해석을 얹고, 그게 기능이 됩니다. 근데 그 해석이 틀렸을 때 책임질 방법이 없어요.
이 도구는 "31일 비었음"에서 멈춥니다. 그게 오히려 신뢰를 만듭니다.
한번 해보실 거면, 오래 붙잡고 있었던 저장소에 돌려보세요. 남의 프로젝트는 그냥 그래프인데, 내 프로젝트의 침묵 구간은 좀 다르게 읽히거든요. 그 31일에 뭐가 있었는지는 본인만 아는 거고요.
다음 글에서는 깃 로그에서 실제로 쓸 만한 통계를 뽑는 명령어들을 정리해볼게요.