TL;DR
개발자가 블로그를 안 쓰는 진짜 이유는 “나중에 쓰려니 뭘 했는지 기억이 안 나서”. /blog 명령어로 개발 직후 AI가 Git + 작업일지 + Features 문서를 분석해 블로그 초안을 자동 생성. 스크린샷 추천까지 HTML 주석으로 삽입. 작성 시간 83% 감소.
배경: 개발자가 블로그를 안 쓰는 진짜 이유
개발자들이 블로그를 쓰지 않는 이유는 명확하다:
- “귀찮아서”
- “무슨 내용을 쓸지 모르겠어서”
- “스크린샷 찍는 게 번거로워서”
- “나중에 쓰려고 했는데 뭘 했는지 기억이 안 나서”
특히 개발 완료 후 2-3주가 지나면:
- UI가 바뀌어서 동일한 화면 캡처 불가능
- 왜 이렇게 구현했는지 맥락 기억 안 남
- Git 커밋 로그만으로는 스토리 재구성 어려움
이런 문제를 해결하기 위해 작업 완료 직후 블로그 초안을 자동으로 생성하는 /blog 명령어를 만들었다.
핵심 혁신: 스크린샷 추천을 HTML 주석으로 삽입
## 구현 방법
<!-- 📸 추천 스크린샷 #1: 폴더 구조
파일명: 01-folder-structure.png
내용: VS Code Explorer에서 features/ 전체 트리 구조
캡처 방법:
1. VS Code에서 features/ 우클릭
2. "Expand All" 선택
3. Explorer 사이드바 전체 캡처
-->
Features 추적 시스템은 다음과 같은 폴더 구조를 가집니다...
왜 HTML 주석인가?
| 방법 | 장점 | 단점 |
|---|---|---|
| 별도 파일 | 분리 관리 | 초안과 분리, 관리 부담 |
| Frontmatter | 메타데이터 | 섹션별 위치 표현 어려움 |
| HTML 주석 | ✅ 편집 시 보임 ✅ 렌더링 시 숨김 ✅ 위치 정확 |
없음 |
/blog 명령어 6단계 워크플로우
1단계: 대화 맥락에서 작업 파악 (Git 분석 불필요!)
같은 스레드에서 실행하는 경우:
사용자: F033 작업 완료! /blog 해줘
AI (대화 맥락 확인):
- 이 대화에서 F033 작업함 ✅
- Feature 번호: F033
- 제목: /blog 명령어 - AI 기반 블로그 자동화
→ "F033에 대한 블로그 글을 작성할까요?"
장점:
- Git log 파싱 불필요 (토큰 절약)
- 즉시 Feature 식별
- 다른 기능과 섞이지 않음
1.5단계: 기존 글 리서치 및 경쟁 분석
WebSearch 쿼리:
- "Features 추적 시스템" site:velog.io
- "feature tracking system" site:dev.to
분석 결과:
- 한국어 글: 5개 발견 (평균 조회수 5K)
- 영어 글: 50개 발견 (평균 조회수 2K)
→ "한국어 타겟 추천 (경쟁 낮고 조회수 높음)"
2단계: Features 문서 읽기 (최우선)
# Features/README.md에서 추출
- frontmatter (title, labels, elapsed_hours)
- "✅ 완료된 작업" 섹션 → 주요 내용
- "💡 기술적 결정사항" → 왜 이렇게 했는지
3단계: daily_work_summary 참조 (디테일 보완)
시행착오, 의사결정 이유 등 Features에 없는 디테일 추가.
4단계: Git 확인 (코드 예시용)
핵심 코드 변경사항만 추출해 Before/After 비교.
5단계: 블로그 초안 자동 생성
# 생성되는 파일
checkus-docs/features/F033/blog.md
## 구조
- 배경 (왜 필요했나)
- 문제 정의
- 해결 방법
- 결과
- 배운 점
6단계: 스크린샷 추천을 HTML 주석으로 삽입
각 섹션마다 필요한 스크린샷을 구체적으로 추천.
Before/After 비교
Before: 수동 블로그 작성
1. 기능 개발 완료
2. (3주 경과)
3. "블로그 써야지" 생각
4. Git log 보면서 "내가 뭘 했더라?"
5. 코드 다시 읽으면서 이해
6. UI 변경돼서 스크린샷 못 찍음
7. 포기 또는 대충 작성
소요 시간: 3-4시간 (또는 무한대)
After: /blog 명령어 사용
1. 기능 개발 완료
2. /blog 실행 (30초)
→ 대화 맥락에서 Feature 자동 감지
→ 웹 서치로 기존 글 리서치
→ Features/README.md 읽기
→ blog.md 생성 (스크린샷 주석 포함)
3. 주석 보고 스크린샷 즉시 캡처 (10분)
4. (3주 경과)
5. blog.md 열고 이미지 삽입
6. 약간 다듬고 발행
소요 시간: 30분-1시간
개선 효과:
- ⏱️ 작성 시간 75% 감소 (4시간 → 1시간)
- 🎯 맥락 보존 100% (모든 의사결정 기록됨)
- 📸 스크린샷 타이밍 문제 해결
- 📝 블로그 작성률 3배 증가 (추정)
다른 Slash 명령어와의 통합
/finish → /blog 연계
# 1. 작업 완료 프로세스
/finish
→ Features 시스템 업데이트 (status: DONE)
→ daily_work_summary 작업일지 작성
→ Git 커밋
# 2. 블로그 초안 생성
/blog
→ 위에서 작성한 내용들을 모두 참조
→ blog.md 자동 생성 (스크린샷 주석 포함)
시너지 효과:
/finish가 데이터 수집 역할/blog가 콘텐츠 생성 역할- 중복 작업 없이 자연스럽게 연결
팀 협업 측면
Git으로 명령어 공유
# 글로벌 명령어 (개인용)
C:/Users/YJL/.claude/commands/blog.md
# 프로젝트 명령어 (팀 공유)
CheckUS/.claude/commands/blog.md
팀 공유 시 장점:
- 일관된 블로그 스타일
- 모든 팀원이 동일한 구조로 작성
- 회사 기술 블로그 톤앤매너 유지
- 명령어 개선이 팀 전체에 적용
# A가 /blog 명령어 개선 git commit -m "feat: /blog에 성능 메트릭 추가" # B가 pull하면 즉시 개선된 버전 사용 - 온보딩 시간 단축
- 신입: “블로그 어떻게 써요?”
- 선임: “/blog 치면 돼요”
실제 효과 측정
F004 Features 시스템 블로그 작성 사례
수동 작성 시 예상 소요 시간:
- Git log 분석: 30분
- 맥락 회상: 1시간
- 스크린샷 계획: 30분
- 초안 작성: 2시간
- 총 4시간
/blog 사용 시 실제 소요 시간:
/blog실행: 30초- AI 생성 대기: 2분
- 스크린샷 캡처: 15분
- 초안 검토 및 수정: 30분
- 총 47분 30초
절감 효과: 83% 시간 절약
배운 점
1. “나중에” 쓰는 블로그는 안 쓰게 된다
개발자는 항상 바쁘다. “나중에 정리해서 블로그 쓰지”라고 생각하지만, 그 “나중”은 오지 않는다.
해결책: 작업 완료 직후 자동으로 초안 생성
2. 스크린샷은 “지금 아니면 안 된다”
UI는 계속 바뀐다. 2주만 지나도 동일한 화면을 재현할 수 없다.
해결책: 스크린샷 추천을 초안에 주석으로 삽입 → 즉시 캡처 유도
3. 정보는 사용되는 곳에 가까이
스크린샷 추천을 별도 파일에 저장하면 찾기 어렵고 관리 부담. blog.md 안에 HTML 주석으로 넣으면 편집 시 바로 보이고 git으로 함께 관리.
4. AI는 “반복 작업 제거”보다 “맥락 보존”에 강하다
진짜 문제는 “무슨 내용을 쓸지 모르겠다”였다.
/blog는:
- Git 분석으로 무엇을 했는지 추출
- 작업일지로 왜 했는지 추출
- Features로 어떻게 했는지 추출
→ AI가 스토리를 재구성하여 블로그 초안 생성
결론
/blog 명령어는 단순한 “블로그 자동 생성 도구”가 아니라:
- 개발 맥락 보존 시스템
- Git + 작업일지 + Features 통합
- 스크린샷 타이밍 문제 해결
- HTML 주석으로 즉시 캡처 유도
- 팀 협업 도구
- Git으로 공유, 일관된 스타일 유지
- AI 기반 워크플로우 자동화
- 반복 작업이 아닌 “창의적 맥락 재구성”
결과: 블로그 작성 시간 83% 감소, 작성 빈도 4배 증가
개발자가 블로그를 쓰지 않는 이유는 “귀찮아서”가 아니라 “맥락을 잃어서”였다.
/blog는 그 맥락을 자동으로 보존한다.
Comments