커밋 분류 습관: Git 히스토리에 숨은 미완성 아이디어를 구해내는 가장 단순한 방법

당신의 Git 히스토리에는 아마 수많은 ‘유령’이 떠다니고 있을 겁니다.

절반만 구현된 기능. 실험적인 리팩터링. “나중에 다시 보자”고 다짐했던 스파이크(spike) 코드들. 이 모든 것들이 몇 달째 손도 대지 않은 브랜치 안에서 조용히 방치되어 있습니다.

대부분의 팀은 이런 브랜치를 그냥 잡동사니 취급합니다. 하지만 그 안에는 재사용 가능한 패턴, 지금 구현보다 더 나은 아이디어, 미래의 나에게 큰 도움이 될 지름길이 숨어 있습니다.

여기서 등장하는 개념이 바로 커밋 분류(commit triage) 입니다.

커밋 분류는 아주 단순한 정기 습관입니다. 브랜치를 주기적으로 훑어보면서, 각 브랜치에 대해 할 일을 결정하고, 쓸만한 것은 뽑아내고, 나머지는 정리하는 것. 제대로만 하면, Git 히스토리를 감당 안 되는 묘지가 아니라 재사용 가능한 아이디어 광산으로 바꿀 수 있습니다.

이 글에서 다룰 내용은 다음과 같습니다.

가장 가능성 높은 미완성 작업들을 빠르게 찾아내는 방법
각 브랜치를 분류(triage)하기 위한 실용적인 프로세스
정말 쓸모있는 실험만 남기고 소음 같은 히스토리를 정리하는 법
오래된 브랜치에서 재사용 가능한 패턴과 유틸리티를 캐내는 방법
분류 결과를 문서화해 로드맵과 기술 부채가 눈에 보이게 만드는 방법

왜 당신의 Git 히스토리는 생각보다 훨씬 더 가치가 클까

개발자들은 보통 방치된 브랜치의 가치를 과소평가합니다. “오래된(old)”, “묵은(stale)”, “실험용(experimental)”이라고 해서 쓸모없다는 뜻은 아닙니다. 보통은 이런 의미에 가깝습니다.

아이디어가 당시엔 너무 앞서 있었거나, 어떤 의존성 때문에 막혀 있었다
뭔가 배운 것은 있지만, 재사용 가능한 코드로 제대로 다듬지 못했다
실제로 나쁘지 않았지만, 마감 압박 때문에 덮어 두고 떠났다

이 브랜치들은 사실상 R&D 저장소에 가깝습니다.

대체 설계안들
부분적으로 수행된 리팩터링
성능 실험
아직(또는 결국) 채택되지 않은 기능의 빠른 프로토타입

Git 히스토리를 “다시 꺼내 쓸 수 있는 아이디어 아카이브”로 보기 시작하면 목표가 달라집니다. 단순히 브랜치를 치우는 게 아니라, 그 안에서 재사용할 수 있는 패턴을 캐내는 작업이 됩니다.

1단계: 한 줄 명령으로 가장 최근 작업부터 표면으로 끌어올리기

수십 개의 브랜치를 하나씩 스크롤하며 볼 필요는 없습니다. 가장 가치 있을 가능성이 높은 곳, 즉 최근에 손댄 브랜치들부터 시작하면 됩니다.

다음 명령을 사용해 보세요.

git branch --sort=-committerdate

이 명령은 마지막 커밋 날짜 기준으로 브랜치를 정렬하고, 그중 가장 최근 작업을 맨 위에 올려줍니다.

이게 중요한 이유는 다음과 같습니다.

최근 브랜치는 현재 아키텍처와 더 잘 맞을 가능성이 크다
맥락(context)을 더 잘 기억하고 있을 때다
‘뭘 하다 말았는지’ 아직 머릿속에 남아 있을 확률이 높다

이 목록에서 한 번에 처리할 적당한 개수(예: 3–5개) 의 브랜치를 골라 분류 세션을 시작하세요. 이걸 습관으로 만들려면, 규모를 작게 유지하고 반복 가능하게 만드는 게 핵심입니다.

2단계: 커밋 분류 의사결정 트리

브랜치 하나를 살펴볼 때마다, 딱 하나의 결론을 명시적으로 내립니다.

마저 완성할지, 다시 다듬을지, 머지할지, 깔끔하게 닫을지.

아래는 그대로 따라 할 수 있는 간단한 워크플로입니다.

1. 지금 브랜치에 뭐가 있는지 확인하기

각 브랜치에 대해:

git checkout your-branch-name
git log --oneline --graph --decorate | head

변경 사항을 대략 훑어보며 생각해 봅니다.

이 브랜치는 어떤 문제를 풀려고 했나?
그 문제가 지금도 여전히 유효한가?
해결은 어느 정도까지 진행됐나?

2. 브랜치의 운명을 정한다

옵션 A: 마저 완성하기 (Finish It)

다음과 같은 경우에 사용합니다.

기능이나 리팩터링이 여전히 유효한 경우
작업이 대략 60–90%까지 진행되어 있는 경우
가까운 시일 안에 현실적으로 마무리할 수 있는 경우

실제 액션:

남은 작업을 설명하는 티켓/이슈를 새로 만들거나 업데이트한다
필요하다면 main(또는 trunk 브랜치) 기준으로 리베이스한다
다가오는 스프린트나 개인 계획에 이 작업을 명시적으로 넣는다

옵션 B: 다시 다듬기 (Refactor It)

다음과 같은 경우에 사용합니다.

아이디어 자체는 괜찮지만, 구현이 현재 코드베이스와 맞지 않는 경우
브랜치가 꼬여 있거나, 노이즈가 많거나, 서로 상관없는 변경들이 섞여 있는 경우

실제 액션:

중요한 커밋만 새 브랜치로 체리픽(cherry-pick)한다
현재 아키텍처에 맞게 코드를 다시 작성한다
새 브랜치가 기존 브랜치를 대체하면, 원래 브랜치를 닫는다

옵션 C: 머지하기 (Merge It)

다음과 같은 경우에 사용합니다.

사실상 작업이 끝났는데, 머지만 안 된 상태였던 브랜치
약간의 수정이나 컨플릭트 해결만 하면 되는 브랜치

실제 액션:

테스트를 돌리고, 충돌을 해결한 뒤 머지한다
머지 커밋이나 PR 설명에 짧게 요약을 남긴다:
- 이 브랜치에서 시도한 것
- 트레이드오프나 후속 작업 필요 여부

옵션 D: 명시적으로 닫기 (Explicitly Close It)

다음과 같은 경우에 사용합니다.

해당 기능이 이제 더 이상 필요하지 않은 경우
접근 방식이 이미 구식이 된 경우
이 브랜치를 살려내는 비용이 기대 효과보다 더 큰 경우

실제 액션:

GitHub/GitLab 같은 리모트를 쓰고 있다면:

git branch -d your-branch-name        # 로컬 브랜치 삭제
git push origin --delete your-branch-name  # 리모트 브랜치 삭제

이슈 트래커에 메모를 남깁니다: “브랜치 X 종료: 접근 방식 노후화, Y로 대체됨.”

여기서 핵심은 명확성입니다. 브랜치를 그냥 방치해서 썩게 두는 게 아니라, 의도적으로 운명을 결정하는 것입니다.

3단계: 진짜로 필요 없는 것들 깨끗이 치우기

어떤 브랜치는 아이디어라기보다는 그냥 소음 덩어리일 때도 있습니다.

실수로 커밋된 거대한 바이너리 파일
로컬 테스트용으로 쓰던 대용량 데이터 덤프
원래는 버전 관리에 들어오면 안 됐던 생성물(generated files)

이런 것들이 한 번 쓰고 버릴 브랜치 안에만 있다면, 브랜치를 삭제하는 것만으로 충분히 정리될 수 있습니다.

하지만 이런 불필요한 파일이 메인 히스토리까지 오염시켰다면, git-filter-repo 같은 도구로 깨끗이 제거하고, 히스토리를 다시 쓰는 게 좋습니다.

git-filter-repo가 유용한 상황 예시:

실수로 커밋된 시크릿/비밀번호 제거
모든 히스토리에서 대용량 미디어나 빌드 산출물 삭제
최상위 디렉터리 구조를 깔끔하게 옮기거나 이름을 바꾸고 싶을 때

이렇게 정말 필요 없는 아티팩트들을 치워두면, Git 히스토리에 남는 것들은 다음과 같이 바뀝니다.

클론 속도가 충분히 빠를 정도로 가벼운 저장소
민감 정보나 쓸모없는 쓰레기 파일이 없는 히스토리
가치 있는 실험과 실제 작업에 집중된 기록

4단계: 브랜치에서 재사용 가능한 패턴 캐내기

브랜치 하나가 전체적으로는 마무리하거나 머지할 가치가 없더라도, 부분적으로는 충분히 쓸만한 코드가 들어 있는 경우가 많습니다.

이런 질문을 습관처럼 스스로에게 던져 보세요.

“여기서 내가 나중에 또 쓰고 싶을 만한 패턴이 있나?”

구체적으로는 이런 것들을 찾아볼 수 있습니다.

매번 새로 쓰게 되는 유틸 함수들
반복해서 등장하는 공통 셋업/보일러플레이트 코드
디버깅에 유용했던 로깅, 트레이싱, 진단 코드 조각들
재사용 가능한 UI 컴포넌트나 레이아웃 패턴

조각들을 공유 유틸로 승격시키기

재사용 가능성이 보이는 코드가 있다면, 과감히 뽑아서 올리세요.

유틸 함수는 레포 내 공용 모듈이나 라이브러리로 옮긴다
반복되는 코드는 템플릿이나 프로젝트 생성기(generator)로 만든다
자주 쓰일 패턴은 에디터 스니펫으로 등록해 둔다

이걸 Godot 같은 게임 엔진을 쓸 때를 떠올리며 생각해 볼 수 있습니다.

게임 개발자는 재사용 가능한 씬(scene), 스크립트, 패턴을 쌓아간다
시간이 지나면서, 믿고 가져다 쓸 수 있는 툴박스가 완성된다

Git 히스토리도 똑같은 역할을 할 수 있습니다. 오래된 브랜치들은, 나중에 표준화해서 재사용할 수 있는 패턴의 프로토타입이라고 볼 수 있습니다.

5단계: 각 분류 세션을 기록으로 남기기

마지막 단계이자, 자주 건너뛰어지는 단계가 바로 무슨 일이 있었는지 적어 두는 것입니다.

분류 세션을 한 번 진행할 때마다, 다음을 간단히 정리해 두세요.

어떤 브랜치들을 건드렸는지
각 브랜치에 대해 내린 결정(완성, 리팩터, 머지, 종료)
뭐를 추출했는지 (새 유틸, 패턴, 템플릿 등)
생성된 후속 작업 (새 이슈, 티켓 등)

이 기록은 다음과 같은 곳에 남길 수 있습니다.

프로젝트 트래커(Jira, Linear, GitHub Projects 등)
레포 안의 간단한 docs/triage-log.md 파일
팀 위키에 “브랜치 분류 – YYYY-MM” 같은 페이지

왜 문서화해야 할까요?

로드맵이 더 선명해집니다: 남은 작업과 버린 경로가 구분돼 보입니다.
기술 부채가 ‘느낌’이 아니라 눈에 보이고 추적 가능한 것이 됩니다.
나중에 합류한 팀원이 “왜 이 브랜치가 사라졌는지, 왜 방향이 바뀌었는지” 이해하기 쉬워집니다.

간단한 로그 예시는 다음과 같습니다.

### Triage session – 2025-01-12

- `feature/async-refactor` – **Finish**
  - 여전히 유효, 약 70% 진행 상태
  - 남은 작업에 대해 티켓 #482 생성

- `spike/new-cache-strategy` – **Extract + Close**
  - `cache_utils.py`를 `shared/cache/`로 추출
  - 브랜치 종료; 접근 방식은 #451로 대체됨

- `experiment/ui-theme-v2` – **Close**
  - 새로운 브랜딩 이후 디자인 방향이 무의미해짐

이런 기록은 미래의 내가 똑같은 판단을 또 반복하지 않게 막아주고, 다른 사람도 과거 결정을 더 빨리 이해할 수 있게 해 줍니다.

커밋 분류를 습관으로 만드는 방법

커밋 분류의 진짜 가치는 반복할 때 생깁니다.

부담 없이 습관화하는 방법 몇 가지를 소개하면:

주 1회, 15–30분짜리 분류 세션을 캘린더에 고정 일정으로 넣는다
주간 체크리스트에 “git branch --sort=-committerdate 한 번 돌려 보기”를 추가한다
동료 한 명과 페어로 분류 작업을 해서 서로 맥락을 공유한다
스프린트 끝, 릴리스 직후, 월말 같은 자연스러운 마일스톤에 맞춰 진행한다

한 번에 모든 브랜치를 비우는 것이 목표가 아닙니다. 목표는 점진적이고 꾸준한 개선입니다.

더 많은 아이디어를 구조화해서 되살려 쓰게 되고
레포는 덜 지저분해지고, 덜 헷갈리게 되며
저장소는 점점 더 건강하고 이해하기 쉬운 상태가 됩니다.

결론: Git 히스토리는 쓰레기장이 아니라 설계 자산이다

Git 저장소는 단순한 코드 아카이브를 넘어섭니다. 실험, 포기한 방향, 거의 다 했던 아이디어까지 포함한 당신의 사고 과정 히스토리입니다.

단순한 커밋 분류 습관을 들이면—

git branch --sort=-committerdate로 최근 브랜치를 리스트업하고
각 브랜치에 대해 완성(마저 하기), 리팩터, 머지, 종료를 명시적으로 결정하고
git-filter-repo 같은 도구로 진짜 필요 없는 파일은 히스토리에서 제거하고
브랜치에서 재사용 가능한 패턴과 유틸리티를 캐내고
각 분류 세션의 결과를 기록으로 남기는 것만으로도

—그 히스토리는 부담이 아닌 자산이 됩니다.

이 작업을 ‘청소’가 아니라 **채굴(mining)**이라고 생각해 보세요. 미래의 작업을 더 빠르고 더 좋게 만들어 줄 패턴, 지름길, 통찰을 캐내는 작업입니다.

아마 지금 이 순간에도 당신의 Git 히스토리 어딘가에는 가치 있는 아이디어들이 숨어 있을 겁니다. 필요한 건 그저, 작지만 반복 가능한 하나의 습관뿐입니다. 그 아이디어들을 다시 꺼내 생명을 불어넣기 위한.