사이드 프로젝트를 하면서 항상 같은 문제가 있었다. 커밋 로그는 열심히 쌓이는데 블로그는 텅 비어 있다.
코드는 짰다. README도 썼다. 근데 블로그 글? 다음에 써야지 하다가 영영 안 쓴다.
그래서 만들었다. 커밋 로그를 분석해서 블로그 글로 바꿔주는 자동화 워크플로우를.
git2blog 탄생 배경
매번 반복되는 패턴이 있었다.
프로젝트 끝나고 "이거 블로그에 정리해야지" 생각한다. 며칠 지나고 까먹는다. 한 달 뒤에 커밋 로그 보면서 "아 맞다, 이거 했었지" 한다. 근데 이미 맥락을 잊어버린 상태라 글을 못 쓴다.
커밋 로그는 이미 있다. 변경사항, 날짜, 맥락이 다 들어있다. 이걸 그대로 블로그로 옮기면 되는데, 그 사이의 간극이 너무 크다.
그 간극을 없애고 싶었다.
어떻게 작동하나
git2blog는 GitHub 리포지토리 URL만 있으면 된다.
- GitHub API로 커밋 로그를 가져온다
- Claude가 커밋 메시지, 날짜, 변경사항을 분석한다
- 블로그 글 제목과 요약을 제안한다
- 승인하면 한영 동시에 글을 작성한다
- Hashnode로 바로 발행한다
핵심은 승인 단계다. AI가 알아서 다 하면 안 된다. 제목과 방향을 먼저 보여주고, 내가 OK하면 그때 글을 쓴다.
여기서 2시간 정도 삽질했다. 처음엔 승인 없이 바로 쓰게 했는데, 엉뚱한 각도로 글을 써버리더라. "이 프로젝트의 아키텍처를 분석해보겠습니다" 같은 학술적 글이 나와서 당황했다.
내 블로그는 삽질 일기지 논문이 아니다. 그래서 제안-승인 프로세스를 넣었다.
실제 사용 경험
git2blog를 만들고 나서 바로 이 글을 쓰고 있다.
이전이면 절대 안 썼을 글이다. "Initial commit 하나로 블로그 글을 쓴다고?" 했을 거다. 근데 커밋 로그를 보니까 내가 왜 이걸 만들었는지, 어떤 문제를 해결하려고 했는지 명확하게 보인다.
커밋 로그는 이미 글의 재료다. 그냥 담아내기만 하면 된다.
기술 스택
Claude Code를 베이스로 했다. 별도의 CLI 도구가 아니라, 자연어로 대화하면서 작동하는 방식이다.
.env 파일에 Hashnode 토큰이랑 GitHub 토큰만 넣어두면 된다. 나머지는 Claude가 알아서 처리한다.
발행 스크립트는 Bash로 짰다. frontmatter 파싱해서 GraphQL API 호출하는 건 100줄도 안 된다. 간단한 게 최고다.
앞으로의 계획
지금은 수동으로 "이 리포 블로그 글로 만들어줘"라고 해야 한다. 나중엔 GitHub webhook으로 새 커밋 들어오면 자동으로 제안하게 만들고 싶다.
또 여러 리포를 동시에 모니터링해서, 정기적으로 "이번 주에 이 프로젝트에서 이만큼 했습니다" 같은 주간 회고 글도 자동 생성해볼 수 있을 것 같다.
커밋 로그는 이미 다 써 있다. 우리는 그걸 모를 뿐이다.
"코드를 짜는 순간, 블로그도 함께 쓰고 있었다."